[10:14] jamespage: I just stumbled upon a weird neutron-api behavior on kilo [10:14] apuimedo, oh yes [10:14] for some reason, it was failing with an ml2 message [10:14] when the plugin configured was midonet [10:15] I did `sudo service neutron-server restart` and it worked [10:17] jamespage: http://paste.openstack.org/show/481451/ [10:17] also, the public network was not created [10:18] http://paste.openstack.org/show/481452/ [10:19] apuimedo, that first error normally indicates that the db was not syncs when the daemon was started [10:20] jamespage: is that a known issue when deploying with bundler? [10:20] apuimedo, no [10:20] I'm not running from master, it's backport from a month or two back [10:22] jamespage: do you envision any possibility of a race between mysql and neutron? [10:23] apuimedo, we have had issues with grants in HA configurations in the past but those where resolved issues - they materialized as db syncs failing, not failing daemons [10:24] jamespage: non-ha deployment [10:24] def not then [10:24] I'll try to reproduce it [10:24] on a clean env [11:01] thedac, gnuoy: landed the haproxy configuration and defaults bump [11:02] jamespage, tip top, ta === verterok is now known as verterok-away [12:58] https://aws.amazon.com/blogs/aws/new-aws-price-list-api/ [12:58] https://bugs.launchpad.net/juju-core/+bug/1524823 [12:58] Bug #1524823: Support AWS price API [12:58] FYI folks === Makyo is now known as Guest8307 === verterok-away is now known as verterok [14:32] cory_fu: I have a question about reactive [14:35] cory_fu: Going back to the peer situation where there are more than one unit of the service. If one peer sets a state X and have a method react to that state, and at the end remove state X. Will the other peers have a chance to react to the state X ? [14:38] mbruzek: States are entirely a local construct. [14:40] cory_fu: hrmm... So if a leader sets state X the followers will not see that right? [14:40] mbruzek: That is to say, states set on unit A are only ever visible on unit A, but they can be set on unit A "in respect to" unit B if they are set from a relation class in response to information coming over the relation [14:41] Correct [14:41] cory_fu: thank you for the explanation [14:43] mbruzek: Data comes in to the leader over the relation, and the leader says to itself, "Ok, from my perspective, unit B is now in state 'foo' which means it has sent me a CSR and is expecting me to sign it." The charm layer can then go, "Ok, for all followers that I consider to be in state 'foo', give me their CSR and I will sign it and send it back" [14:44] cory_fu: I was looking at a much more straight forward case. When the leader changes the CA I was looking at setting a state for the followers to react to, but it is not needed because I can handle this logic in leader_settings_changed() [14:44] mbruzek: This is confused somewhat in your case because the peer relation is *also* handling the follower case, so it also has to implement the follower saying to itself, "Ok, I now see a leader, so I'm in state 'connected' which means to me that I need to create a CSR to send to the (one) leader" [14:47] mbruzek: You know, leader settings is kind of like its own relation, that you could model as a GLOBAL scope pseudo-interface [15:02] hey jose, how would you feel about redoing the owncloud charm in reactive? It should be way simpler than what it currently is [15:03] jcastro_: I don't know reactive (but I guess I can learn soon), it may take a bit. I can work on it after finals maybe? [15:03] yeah no rush or anything [15:03] cool [15:03] * jose rushes to university [15:04] like, I just think the old charm fundamentally won't be interesting to owncloud [15:04] but with the new framework and attached CI, etc. it's way more compelling. [15:22] jamespage: could you take a look at https://code.launchpad.net/~celebdor/charm-helpers/midonet/+merge/274543 [15:31] jamespage: thanks for landing the haproxy timeout fixes [15:58] thedac, no problemo [15:59] apuimedo, took and initial glance - some unit tests for the new context and the kilo specific behaviour would be nice ;-) [16:00] jamespage: understood. Can you please put it on a review comment? [16:00] otherwise when I get to it I might forget :P [16:00] apuimedo, done [16:00] thanks a lot jamespage [16:29] o/ tvansteenburgh - ping re: pending tests for http://review.juju.solutions/review/2348 ... if it's just a wait-in-line thing, no prob. [16:29] tvansteenburgh, so if i intend to do that review, should i have the padlock locked? [16:32] beisner: yeah if you're working a review [16:32] sign into the RQ, and click the lock button next to the item so nobody else snipes it out form under you [16:33] i've done that to jose on more than 10 occcasions now [16:33] ha, thanks [16:33] lazypower, well, i'm re-running tests in uosci, and have the same pending in charm ci, so it'll prob be tomorrow before i revisit. should i still lock? [16:34] I would [16:34] ack, thx sir [16:34] if someone wants ot review it, they will ping ya asking if its ok [16:34] i tend to get these long drawn out reviews for new stack items, and the big data team always laps me on the RQ. so i get pings now and again asking if i'm actually reviewing something or if i'm playing the "lock the review and pretend" game [16:35] which i'm good at too [16:39] beisner: re pending tests, it's b/c the revq went offline last night and the celery jobs haven't brought things up-to-date yet. [16:42] tvansteenburgh, np at all. i'll revisit tomorrow. thx for the update. [16:45] beisner: here's the lxc jenkins log if you need it in the meantime http://juju-ci.vapour.ws:8080/job/charm-bundle-test-lxc/1757/console [16:46] woot DEBUG:runner:KeyError: 'rabbitmq-server/0' [16:46] tvansteenburgh, basicall all openstack charm tests will hit that, as we destry/bootstrap on every iter. [16:47] tvansteenburgh, i saw a bug with plans to parse that instead of returning key error. is that going forward? [16:47] https://github.com/juju/amulet/issues/111 [16:47] yeah that ;-) [16:47] yeah, just needs to get dove [16:47] done [16:48] wanna do it? :D [16:49] want > bandwidth [16:49] ok so, no expectation for that charm test to pass in charm ci, but should be expected to pass in uosci since each test gets a fresh bootstrap. [17:07] lazypower: Been awhile since I've been summoned to IRC. :) [17:08] cfx o/ [17:08] hey there [17:08] hola [17:08] Its a classic, thats for sure :) [17:08] Truthy statement. [17:09] I feel as though I've been a big, big nuisance through all this. [17:09] But you've been tremendously welcoming. [17:09] Not at all, you've been curious, and I just so happen to have some answers for you :) [17:10] :D [17:10] We appreciate the review on teh docs as well. big thumbs up on diving into that [17:10] Hello cfx [17:10] Plenty willing to keep going. I'm booked really solidly through Sunday but this is super high priority for me. [17:11] mbruzek: yo! [17:11] hey #juju [17:11] cfx It will take some time to action on the feedback you gave me, as I am working on something else right now, but we will get to it soon [17:11] Hello th [17:11] cfx: looking over that last correspondence, it looks like there's a lot of overlap between what we already have charmed up in the charm store, with some additional proxy charms for the CDN, and charming up wowza [17:11] should be pretty straight forward, I'm willing to bet we could get you moving in a month or less [17:11] hello TheJeff [17:11] TheJeff o/ [17:12] lil help? I've run through the openstack juju deploy guide (this has taken me quite some time over the past few days) [17:12] mbruzek: oh sure, take your time. I'm just playing the part of the highly-confused newbie. [17:12] TheJeff: please state the nature of your IT emergency :) [17:12] openstack-dashboard is up, seems my units are running (juju status) [17:12] i'm presented with a login, I log in using creds from my config yaml [17:12] and it boots me over to an error page [17:12] lazypower: I'm sure I can get a little extra leeway if my boss knows I'm engaging experts. :) [17:12] so far so good [17:13] `Something went wrong! [17:13] An unexpected error has occurred. Try refreshing the page. If that doesn't help, contact your local administrator.` [17:13] BUT THAT IS ME! [17:13] TheJeff: Hate it when that happens. :( [17:13] so, looked at the apache logs on the openstack-dashboard unit, looks fine - 302s and 200s flowing like fine wine [17:13] beisner ddellav: when logging into horizon, whats the best route to go debug login errors that are not 401 unauthorized? [17:14] but where do I find logs that can lead me with delicious bread crumbs to where my problem lies? [17:14] TheJeff: nice use of adjectives. I approve [17:14] some app level issue I assume, can't hit this or that [17:14] I'm not sure why, but i'll see if we cant get an openstack expert to lend some eyeballs [17:15] :( [17:15] I have to demo an openstack install via juju at 3. [17:15] ugh [17:15] Toronto time [17:15] I'm gonna head to lunch here in a sec. lazypower, you pretty much know the score. I'd like to have something to SAY by Sunday. I'd like to be UP by the beginning of the year if at all possible. Completely open to what to do next. [17:16] cfx: lets model your infra in juju :) [17:16] Right now I'm planning on continuing reading as I can, and continuing with the feedback. That seems like progress in itself. [17:16] cfx: i'm going to head to lunch. first step is figure out what we have provided that you'll need up front, and build a bundle with those services [17:16] we can do a planning session to fill in the gaps with services we dont yet have charmed [17:16] lazypower: lunch indeed. reconvene in a bit? [17:16] what's the first URL I'm going to stare crosseyed-at? [17:17] then we'll do a charm school, write those layer(s), and talk deploy strat :) [17:17] http://jujucharms.com/demo [17:17] iloveyousomuchrightnow [17:17] or just jujucharms.com and click over in teh store [17:17] O_O [17:17] and on that note, time to feed my face [17:17] lol [17:18] TheJeff: sorry i'm not much mor ehelp than pinging. but if they can they'll lend a hand [17:20] TheJeff: please start posting on juju@lists.ubuntu.com, that'll help get other eyeballs to bear if you're time constrained [17:21] lazypower, TheJeff - i'd start by checking `juju stat --format tabular` for sane "Unit is ready" extended workload status [17:21] that will be an indicator that all required relations are made [17:27] lazypower, TheJeff - horizon logs will be on the openstack-dashboard unit(s) in /var/log/apache2/ ... keep in mind that horizon heavily queries nova-cloud-controller, so logs on that unit in /var/log/nova may also be indicative. [17:56] Hi kwmonroe, I was referring azuls zulu8 java layer charm, apart from reactive directory which does actual installation of zulu8 i noticed that some additional directories and code files like hooks, wheelhouse, .build.manifest, .gitignore, Makefile, tox.ini, etc .... i was wondering should i include all these layered specific files even for ibm java charm also.. could you please explain about these files and advise on the same? [18:22] gents [18:23] I'm using my openstack installation and I want to bootstrap juju using that installation ... I made sure to put all required configs .. but when I run juju bootstrap it returns some error .. that it may looks familiar to you : [18:23] ERROR failed to bootstrap environment: index file has no data for cloud {RegionOne http://172.16.45.11:5000/v2.0} not found [18:23] do I need to modify something in my config ? [18:23] mgara: how did you tell it which image to use? [18:24] that's the thing .. i dont get where to put the image i want ... [18:24] mgara: you need to generate an image stream, and set image-metadata-url to point to it [18:24] ok cool ill try to digg more thanks mgz ! [18:25] marlinc: see `juju metadata help generate-image` [18:25] thank you ! [18:26] that creates a dir structure with some json, which you then need to host somewhere both your client and the openstack install can see [18:26] swift will do if you can expose over http or similar [18:26] mgara: see https://jujucharms.com/docs/1.25/howto-privatecloud for more [18:27] the tools you can just get from streams.canonical.com if you have a route out to it. === sarnold is now known as sarnold_ [18:44] hi i'm using juju 1.25.. i'm seeing that 'juju status ' is hanging forever [18:44] juju status used to work a few min ago.. [18:44] now only 'juju status' works [18:44] any ideas what might be wrong? [18:45] i've also noticed that when 'juju status ' does work, it is about 10 times longer responding than just running 'juju status', depending on how many units are deployed [18:45] weird [18:45] mattrae: is your model controller under high load? (eg: node 0) === hbaum_ is now known as hbaum [18:52] lazypower: we're using ensure-availability with 3 nodes. i checked at least 2 and didn't see a high load.. they're also 20 core machines [18:52] yeah that seems beefy enough to run a pretty sizeable infra [18:53] as i understand it, when you're querying an individual node, its just poking @ the mongo data store to return status data.... [18:53] mattrae: I would certainly file a bug about this, it may be a regression in our HA as of 1.25 [18:53] we may need to extend test coverage around that [18:53] i'm sure we have it but it could probably be perf tested as well [18:54] i tried restarting the juju machine agent and juju-db. now i'm redeploying and i'll see if i run into the same issue. i also collected the logs from /var/log in case that is helpful [18:54] lazypower: cool i'll collect some more information and file a bug [18:55] mattrae: thanks for the debug effort, sorry you ran into that :-/ [18:55] sure no problem :) [18:55] thanks for the help [19:06] lazypower: looks like the bug is reported in lp:1516989 and should be fixed in 1.25.2 [19:07] mattrae: nice work [19:07] thx :) [19:24] drac, boot, system setup, PXE, MAAS, drac, boot, system setup, PXE, MAAS... [19:26] mass maas commission! bwahaha [19:26] ahem. [19:57] lazypower: so, since a search on demo.jujucharms.com for the software package we were discussing before doesn't appear to exist... the most I was able to do was add hardware to the sandbox and sit here, confused :) [20:03] stub: You around? [20:03] Oh, nm, of course not [20:32] arosales allow me to introduce you to cfx [20:36] cfx: greetings! I was just commenting to lazypower on the great comments @ https://github.com/mbruzek/docs/issues/41 [20:36] cfx: thanks for taking some time to give feedback on making the docs better [20:47] arosales: Oh any time. Since the feedback has been so positive I plan on continuing. [20:48] Headed home to tackle the next section, actually! [20:49] cfx: excellent, I just wanted to thank you for your contributions to the community and working to make developing charms easier for everyone [20:49] * cfx salutes crisply! [20:49] My pleasure. [20:50] bbiab [21:04] in the ruby juju layer, any opposition to using https://github.com/postmodern/ruby-install instead of building from source? [21:06] Icey: i've used the brightbox ppa's, and rbenv - i'm not opposed to anything at this point wi th ruby to be completely honest [21:07] what may be a good idea is to kind of get a pulse with the ruby community by pinging their mailing list, and asking what they're using [21:07] I figure, with ruby-install, we can allow the user to choose a ruby version still and build as needed, but if there's a binary already out there, then we get to skip the 15 min compile time... [21:08] i'm + for that [21:08] and it doesn't mean leaving a lot of stuff around on prod boxes as much [21:12] i like how its senses the env and uses whatever native package manager is [21:13] yea :) [21:13] then uses build as a fail-safe fallback [21:13] i'm +1 to this [21:13] all the way [21:13] I'll take a look at it soon, build time for this charm is quickly getting annoying enough to give that a priority :) [21:13] * lazypower anoints Icey with the juju [21:13] * Icey ewwwww [21:14] so, what that translates to Icey since you went there with it, is I took the juju logo and beat you about the head and shoulders with it [21:14] * Icey collapses unconscious into the dust [21:26] lazypower lazier version, download the binary ourselves from https://rvm.io/binaries/ubuntu/14.04/x86_64/ ? [21:26] You've immediately lost compat on centos [21:26] well [21:26] which not a *Terrible* loss, but a loss all the same [21:26] https://rvm.io/binaries/ [21:26] i tend to favor cross platform solutions if they are avail [21:26] fair enough [21:35] it looks like ruby-install will still be building on the box [21:36] RVM will let us get premade binaries [21:37] blurg [21:59] cory_fu: you were looking to see if there's an easy way to discern over a relation if a unit is talking to the leader? [21:59] Any way, but yes [22:00] more eyeballs here :) thats all, migrating the topic [22:00] I suppose the leader could set a flag on the relation saying that it's the leader, but is there a way built in to Juju? [22:02] cory_fu: I think the only way would be `relation-set captian="i am, now"` [22:02] where the leader announced over peer, unit-get leader might be a good way around this [22:02] cory_fu: oh [22:02] cory_fu: leader-set unit="$JUJU_UNIT_NAME" [22:02] use leader settings to define it [22:03] marcoceppi: i'm guessing use that in tanem with $JUJU_REMOTE_UNIT [22:03] to determine if we are indeed talking to theleader [22:03] lazypower: yeah, so during leader-elected, have it set that, which should run before peer relations on first go [22:03] right [22:03] then you can do if [ `leader-get unit` == $JUJU_REMOTE_UNIT ] [22:04] not pretty, but it's better than peer setting the information [22:04] i agree 100% [22:04] peer setting the information seems like it could be messier in terms of when the leadership changes [22:06] marcoceppi: So you're saying that leader-settings-changed would be guaranteed to run before peer-relation-joined? [22:07] cory_fu: no, but leader-elected will most certainly run /the first time/ before any relation does [22:07] since it's part of the standard hook lineup [22:07] yeah, thats true [22:07] install -> leader-elected => confg-changed => relations if applicable => start [22:07] once that hook sets the unit, any other hook on any unit that run will see the new value [22:08] well, config-changed -> start -> other [22:08] no idea why i changed hashrocket symbol after the first, but i digress [22:08] not always marco [22:08] lazypower: i balk, really? [22:08] if you add-relation before its stood up, it seems to run relations before start. [22:08] rofl, funtastic. [22:08] ^_^ [22:08] seems legit [22:08] hook order is never garanteed *ice skates away* [22:08] I was under the impression `juju deploy` queued install -> leadership -> cfg -> start [22:09] yes, it's not, but I digress [22:09] to be 100% fair, i haven't tested that assertion since the 1.23 series [22:09] I feel like, in this case, it might actually make more sense to send it over the peer relation. In terms of the conversation flow, the leader would start the conversation by saying, "I need a CSR from you" to any peer that joined, to which the follower could reply. I think that's cleaner than every peer telling every other peer that it wants that peer to sign a cert [22:09] it may have been patched [22:09] lazypower, mbruzek: ^ [22:09] cory_fu: that makes sense, its not like the units are having a gpg key signing party [22:09] which i never get invited to ;_; [22:10] lazypower: fosdem! [22:10] marcoceppi: we gonna GPG key signing?! [22:10] cory_fu: what's the problem with every peer getting a copy of the CSR? [22:10] lazypower: there's one every year [22:10] schwing! [22:10] lazypower: https://fosdem.org/2016/keysigning/ [22:10] cory_fu: thanks, that will take a bit of refactoring but I think that could be done [22:11] mbruzek cory_fu I still don't see the problem with every unit sending it's CSR [22:11] other than a bit more noise [22:11] peer-relation-changed is basically "am I the leader? Nope, I don't care exit 0" [22:11] marcoceppi: Well, there's nothing really wrong with it, I suppose [22:11] and peer-relation-joined is basically BLAM BLAM BLAM HERE'S MY CSR [22:11] marcoceppi: but every peer will send a csr to ever other peer [22:11] marcoceppi: think of the children! [22:12] but every peer will already make a connection with every other peer [22:12] marcoceppi: Lets say there are 1000 peers [22:12] hide you kids, hide yo wife, we're generating tls certificates over hereeee [22:12] it's not really saving much more or less [22:12] data wills till be sent, hooks will still fire [22:12] if 1000 peers are sending certs to the 1000 other peers [22:12] because each charm has a relation-joined and changed [22:12] that is like 1000x100 [22:12] 0 [22:12] mbruzek: but the thing is, that /already/ happens [22:13] marcoceppi: i think part of the concern here, is to reduce noise whend ebugging [22:13] also, it's a factorial [22:13] the csr => leader should be a one shot for each node, not a one shot and then dancing with the rest of the group [22:13] while its not critical that its happening, it does make sense to reduce that noise on the wire [22:13] sure, it would cut down a bit, but each peer would still ahve their relation-joined and relation-changed fired because juju implicitly sets the private-address [22:13] so you're not really reducing much noise [22:14] eh, i guess thats fair too [22:14] where's my marco meme images... this needs to be a meme [22:14] my point is, this level of complexity isn't really much of a save [22:15] i'm seeing some weird behavior with my reactive charm. everytime the update-status hook runs, it also runs all my relation handling functions [22:16] which is kind of bad, because those functions basically rewrite the config and restart the service [22:16] any ideas what could be causing this? [22:16] cmars: this was recently changed, the update-status hook wasn't implemented in the previos editions of built charms [22:17] it was just added this week i do believe, so now its triggering all your state changes you haven't guarded against [22:17] cmars: because each hook runs the reactive bus [22:17] so those states match [22:17] cmars: you should create a state like "charm.done" where you can decorate @when_not('charm.done') to avoid it being processed multiple times [22:17] ah, got it [22:17] .ready is another, better name [22:17] thanks [22:18] cmars: the update-status hook was debated on being added, and ultimately incldued because it helps illuminate this problem. Your relation stuff willa ctually run on each hook after the states are matched sicne states and hooks are evaluated on each hook execution [22:19] * marcoceppi creates some docs on this point to help illuminate it more since it also caught me off guard [22:20] lazypower: about the keysigning, do you want to go? I didnt' go last time but kind of wanted to [22:20] web of trust, etc etc [22:20] Yeah man, i'm game [22:20] cool [22:20] * marcoceppi submits his key [22:21] marcoceppi: is there a list for the kesigning party? [22:21] mbruzek: https://fosdem.org/2016/keysigning/ [22:21] just follow the instructions [22:22] marcoceppi, i still don't see how I can tell the difference between an actual change in the relation data vs. update-status just calling my handler [22:22] also, we should all sign each others keys the next time we sprint, help build that web of trust [22:22] oh, hum [22:23] cory_fu: ^ [22:23] cmars: the relationship wont execute if the data is the same ;) [22:24] cmars: fire off a charm, relate it to something, then try to invoke a re-run using the same rel data, it wont happen [22:24] cmars: You shouldn't care if you're in a relation hook or update-status. If you need to know if the data changed, use the data_changed helper [22:24] cory_fu, how do I use data_changed? [22:25] cory_fu: the point cmars was making, is that on each hook he's getting the relation state evaluated as true [22:25] cmars: But, really, the interface layer should be managing the conversation flow and you should just be able to respond to the states it sets [22:25] i saw mention of that in the base layer README, but didn't see docs [22:25] so I recommended a .ready state for the charm, but that won't trigger if there's relation data changed [22:25] marcoceppi you could remove the .ready state if the rel data has changed [22:25] lazypower: but the interface should do that [22:25] I shouldn't have to [22:25] not necessarily [22:26] your interface is talking about relation data comms, the charm.ready state has zilcho to do with that [22:26] thats you as teh charm authors responsibility to listen to those states coming from the interface layer, to determine if you need to alter state in your charm layer. [22:26] right, but now my layer has to watch for changed_data on the relation, which the interface should be doing [22:26] cmars: https://pythonhosted.org/charms.reactive/charms.reactive.helpers.html#charms.reactive.helpers.data_changed [22:27] or, @when('interface.didsomething') [22:27] def destroy_state(): remove_state('things') [22:27] cmars: Basically, give it a unique ID and the data [22:28] cory_fu, ... and it'll track subsequent calls with that ID as a key into some lookup table? [22:28] cmars: Also, your charm layer can set states to tell itself that it's already done a task and then use @when_not [22:28] marcoceppi: with what i've proposed, your'e still using hte interface states to determine if your charm layer has to do something. its not listening to the data coming over the wire. [22:28] cmars: Yes [22:29] cory_fu, ok, that'll work [22:29] cmars: It computes a hash of the (serialized) data and stores that [22:29] cory_fu: ah, so you could just compute if the relation data has changed in your layer to take action, other wise just noop? [22:30] Ye [22:30] Yes [22:30] * marcoceppi likes [22:30] seems wrong if your charm layer is doing communication state alteration. just sayin [22:30] lazypower: What do you mean, communication state alteration? [22:30] data changing is related to the interface, not the charm layer. [22:30] if you're probing for data changed in teh charm layer, you're doing it wrong [22:31] lazypower: I disagree [22:31] the problem is, i have handlers triggered on @when states change. those states are set by relations. yet suddenly update-status started calling them too [22:31] lazypower: I'm not certain that I agree [22:31] i think that's wrong [22:31] cory_fu: this was prety specific to marco's question. and i may be misinterpreting what he was saying. [22:31] because those states aren't changing [22:32] marcoceppi: Ha. I told you people would get bitten by update-status calling their handlers. ;) [22:32] lazypower cmars right, states are set and persist beetween runs, teh interface says "all the data required to satisfy this are now here" [22:32] or are we supposed to be tolerant of bounces? i could see that.. "at least once" is a common thing you have to deal with [22:33] cmars: The states aren't changing, but they are active. As long as they remain active, the handlers will get called. So your handler needs to tell the interface class that it handled that state if it's not intended to be persistent [22:33] so, you're telling me that if in your charm layer, you're checking against data thats coming from, lets say the interface is a data-bag, - and you're altering a state that the interface sets from yoru harm layer, that you're doing it right? [22:33] cory_fu, and they'll get called on each hook execution? [22:33] you've broken encapsulation of what the interface is doing for your in the first place [22:33] Yeah, what marcoceppi said [22:34] they're states, not events. So you could/should probably just unset the state when you're done? [22:34] ah [22:34] i see [22:34] cory_fu: would it make sense to do something like remove_state('database.available') ? [22:34] The states from the interface are telling you that your relation conversation has progressed to a certain point. It's up to you what to do with this information, and to only do it once if you care about that [22:34] cory_fu: in the layer [22:35] i guess i was thinking "events", but its more like a handoff. you set a state, someone else has to clear it [22:35] ok [22:35] :) [22:35] marcoceppi: I don't think the charm layer should be removing interface layer states. Instead, it should tell the interface class that it's handled the state via a method which would then remove that state [22:35] cory_fu: that's what I figured [22:35] Because the state is actually associated with a conversation, of which there could be more than one [22:35] cory_fu: none of our itnerfaces do that currently [22:35] The one lazypower and mbruzek are working on does [22:36] And at least one other one I wrote did. Let me find it [22:36] cory_fu: that i agree with, as its a conversation exchange vbetween the charm layer, and the interface layer. Having the charm signal to the interface to remove a state is what i would say to be the correct way to do it. [22:36] cmars: which interface is this for? [22:36] Yep [22:36] mongodb [22:36] but just removing that state whollly during the charm layer execution, nah [22:36] thats wrong [22:36] you jsut took control of something that should be encapsulated and encouraging that behavior may have unintended side effects [22:37] such as data not being cleaned up, connections not closed cleanly, backups not made, etc. [22:37] right, I was trying to make that piont earlier [22:37] marcoceppi: https://github.com/johnsca/juju-relation-mysql/blob/master/provides.py#L50 [22:37] marcoceppi: yeah i thought i might be misinterpreting what you were saying, which is why i was making a case against it. <3 [22:37] but, tracking the relation data in the layer and asserting it has changed is not a mutation of the interface or the state [22:37] eh [22:37] ehhhhh [22:37] you in the charm layer, shouldn't give a fig about that tho should you? [22:38] cory_fu: but that's for provides, do you ahve the aternative? the requires side? [22:38] the interface should be responding to data changes and emitting states to that effect. [22:38] marcoceppi: It's the same pattern, though? [22:38] cory_fu: otherwise {mysql}.available is always set [22:38] cory_fu: and will always be true on each hook execution [22:38] marcoceppi: And that makes sense, because mysql has not gone away [22:38] cory_fu: yes, but then you'd have to do one of two things [22:39] cory_fu: either you create a new state, 'charm.done' and assert @when_not [22:39] hwoever, if MySQL updates the conversation there's no way to re-execute since it's still available [22:39] or you do what you said about asserting if the conversation data has changed in the method decorated with the @when {mysql}.available which lazypower doesn't agree with [22:40] * lazypower tries to look intimidating [22:40] its eems there is almost a need for an "event" of "oh, hey yo data changed" [22:41] so I could see the itnerface layer tracking data internally, using the method you shared earlier [22:41] what i think it should do, and feel free to tell me otehrwise - is as you jsut said set a state that the data has been changed, and your charm layer, should signal back ot the interface that the state has been handled and to remove it [22:41]