[00:28] <wallyworld> veebers: reviewed, a couple of questions, see what you think
[00:56]  * veebers looks
[01:02] <veebers> wallyworld: have responded, essentially they're all good points I'll make the change. I did respond re: the status-log question though as it needs further comment.
[01:05] <babbageclunk> wallyworld: that seems to work fine for the ifPrimaryController! Unfortunately the other use of the singular worker is in the model manifolds - it's not so simple to get rid of that one without actually implementing leases, or else running a set of raft workers in each model. :(
[01:27] <wallyworld> veebers: sorry, was eating, looking now
[01:30] <wallyworld> babbageclunk: well that sucks. those model workers ultimately run on a controller. i wonder if there's a way to gate their startup in the engine definition somehow. not sure off hand
[01:34] <wallyworld> veebers: makes sense, thank you, left a couple of comments
[01:38] <babbageclunk> wallyworld: Yeah, I think we could feed the state of the raft-leadership flag from the machine manifolds into the model manifolds, but then that would have the effect of making all those workers run on the machine that was the raft leader, which I don't know that we'd want.
[01:39] <wallyworld> babbageclunk: that may be true. i guess we want them spread around a bit
[01:40] <wallyworld> babbageclunk: maybe use a separate named raft fsm for that :-)
[01:40] <wallyworld> or just use the lease fsm or something
[01:48] <babbageclunk> Yeah, it seems like just exposing the lease store would do it.
[01:53] <veebers> wallyworld: hah no worries; eating is way more important than my PR ^_^ have made the suggested changes and all pushed up.
[01:54] <veebers> wallyworld: you mentioned a site that had details re: tomb.v2 -> tomb.v3, is that just github and release notes or is there something more substantial?
[01:55] <wallyworld> veebers: v1->v2. not sure off hand, i know there's a home page somewhere
[01:55] <wallyworld> maybe just gh
[01:56] <veebers> wallyworld: ack, I'll have a look. cheers
[02:00] <wallyworld> veebers: bug 1745031 is fix committed now right?
[02:00] <mup> Bug #1745031: gce add credentials "Enter file" absolute path msg improvment <juju:In Progress by veebers> <https://launchpad.net/bugs/1745031>
[02:04] <veebers> wallyworld: aye it is, I'll update status
[02:05] <wallyworld> ta, and move card
[02:05] <veebers> card is done, forgot to update bug :0
[02:20] <wallyworld> veebers: tiny one https://github.com/juju/juju/pull/8623
[02:20]  * veebers looks
[02:23] <veebers> wallyworld: LGMT, have made a suggestion on it
[02:23] <wallyworld> ok, ty
[02:23] <wallyworld> veebers: would $PROJECT_DIR work?
[02:24] <wallyworld> i should just try it
[02:27] <veebers> wallyworld: I don't think so, because it's using PROJECT which is a relative path, really just the project name
[02:28] <wallyworld> veebers: i just tried it and it seemed to work.       $make -C /home/ian/juju/go/src/github.com/juju/juju pre-check
[02:28] <wallyworld> where i was in some other dir
[02:28] <thumper> wallyworld: have you confirmed that make check fails if go vet isn't happy?
[02:28] <wallyworld> yes of course!
[02:28] <veebers> wallyworld: oh cool, ah right go list is probably smart about what the project is and knows GOPATH etc.
[02:28]  * thumper is now in the coffee shop up the road
[02:29] <wallyworld> veebers: yeah i think so
[02:29] <veebers> thumper: if the house wasn't a total madhouse I would invite you up so you could consume our power and internet
[02:29] <thumper> wallyworld: have you got a link to the release notes for 2.4?
[02:29] <thumper> veebers: that's fine, getting coffee while I'm here, have the kids too
[02:29] <wallyworld> thumper: https://docs.google.com/document/d/1kz1NGMEeHdmSMs3PSxsDVej_tR4bjyAIcRWyx0UwohE/edit
[02:32] <vino> wallyworld: have a min
[02:32] <wallyworld> sure
[02:32] <wallyworld> standup ho
[02:32] <vino> hangout
[02:32] <vino> ok.
[02:35] <veebers> babbageclunk: you seen or used magithub? (https://github.com/vermiculus/magithub)
[02:38] <veebers> wallyworld: to confirm, for the resolve test do you still want to use show-status-log to confirm hook execution?
[02:48] <wallyworld> veebers: i reckon that could maybe be overkill?
[02:48] <wallyworld> seems the charm behaviour helps verify it's all correct
[02:50] <veebers> wallyworld: agreed, sorry was a bit confused by PR comments. It seems you where asking that again. I'll leave as is using charm, no log check
[02:50] <wallyworld> veebers: i  may not have been clear
[02:51] <wallyworld> +1 to using charm
[02:52] <veebers> mean, I'll merge now then :-)
[02:55] <babbageclunk> veebers: ooh, no I have not
[02:57] <kelvinliu_> wallyworld: I think bug  https://bugs.launchpad.net/juju/+bug/1764649 is not a juju bug but a `interface-mysql` bug
[02:57] <mup> Bug #1764649: juju caas remove-relation does not work <juju:New for wallyworld> <https://launchpad.net/bugs/1764649>
[02:57] <thumper> wallyworld: there was something we were talking about recently that we wanted to add to charms metadata.yaml, do you recall what it was?
[02:58] <thumper> we have a request to add some charm-version info
[02:58] <thumper> but if we were going to modify metadata.yaml I'd like to get both changes in at once
[02:59] <wallyworld> thumper: hmmm, yeah i do recall something, i think it was a version field for when charms supported application level data bags
[03:00] <thumper> what would that version be used for?
[03:00] <wallyworld> kelvinliu_: i don't think the mysql charm for IAAS clouds has the same issue? or does it?
[03:00] <thumper> the charm-version I'm thinking about relates to charm releases
[03:00] <thumper> like adding "pike" for keystone
[03:00] <thumper> or something
[03:01] <wallyworld> thumper: so a v2 charm would support X whereas V1 would not. that's different to your version
[03:01] <wallyworld> maybe we need a capabilities list
[03:01] <wallyworld> like series
[03:01] <wallyworld> a charm supports "app data bags" and ....
[03:01] <thumper> hmm...
[03:02] <thumper> I know there was one where we wanted to add lxd devices to pass through etc
[03:02] <kelvinliu_> wallyworld: remoteUnitName will be empty for non relation hook or relation-broken hook from juju side. So in `relation-broken hook` handler, we can't access `self.conversation()` unless the `scope` of the `Relation class in provides.py` set to `scopes.GLOBAL`
[03:02] <wallyworld> thumper: yeah, that rings a bell too
[03:02] <thumper> wallyworld: I'm going to make a quick doc for charm metadata updates
[03:03] <thumper> so we can have one place...
[03:03] <wallyworld> kelvinliu_: oh, i see, i didn't realise remote unit name was empty for relation-departed
[03:03] <kelvinliu_> wallyworld: but the scope of `interface-mysql` is set to `scopes.SERVICE`
[03:03] <wallyworld> thumper: yup
[03:04] <wallyworld> kelvinliu_: i wasn't sure what it was set to. i think service scope has different behaviour in getting the conversation
[03:04] <kelvinliu_> kelvinliu_: `remoteUnitName` is empty for `relation-broken`, `relation-departed` is fine.
[03:05] <kelvinliu_> wallyworld:`remoteUnitName` is empty for `relation-broken`, `relation-departed` is fine.
[03:05] <wallyworld> hmmm, i wonder why that is. i might need to go and read the uniter code
[03:05] <wallyworld> there must be a reason that someone had, but it seems the mysql charm expects it
[03:05] <wallyworld> to not be empty
[03:10] <kelvinliu_> wallyworld: i guess, when we got `relation-broken` event triggered, we may lose the remote unit context in this case. So the context of remote unit will be not guaranteed to be there.
[03:10] <wallyworld> kelvinliu_: just saw this in some doc: The "relation-broken" hook is not specific to any unit, and always runs once when the local unit is ready to depart the relation itself
[03:11] <wallyworld> i have to check code, but it does seem relation-broken hook does not set remote unit
[03:11] <wallyworld> hence the charm interface layer is wrong
[03:11] <wallyworld> i'm quickly testing on an iaas model to confirm
[03:12] <kelvinliu_> wallyworld: yes, I changed `'{provides:mysql}-relation-{broken,departed}'`  to `'{provides:mysql}-relation-departed'`, and `juju resolved mysql/0` is resolved successfully
[03:13] <wallyworld> kelvinliu_: so it seems we don't even want to run the relation broken hook
[03:15] <wallyworld> we would look to do a PR against the mysql interface layer if we 100% confirm the right thing is to skip the broken hook
[03:20] <kelvinliu_> wallyworld: if do need to run `relation-broken`, we have to parse `scope` manually to get the `correct conversation`.
[03:24] <wallyworld> kelvinliu_: so i checked the standard mysql charm. it is not a reactive charm. it uses relation broken to revoke all privileges for the user
[03:25] <wallyworld> we should check bugs filed against the reactive interface layer to see if its a known issue
[03:26] <kelvinliu_> wallyworld: yes, I am looking
[05:34] <wallyworld> jam: forgot - you and manadart need to update 2.4 beta1 release notes for tomorrow's release
[05:34] <jam> wallyworld: ack
[05:44] <wallyworld> kelvinliu_: how goes it with mysql interface layer. do you think we could do a patch and fork the code?
[05:52] <manadart> wallyworld: Ack.
[06:16] <kelvinliu_> wallyworld: to make it working, we will just make the handler to listen `departed` event. I just read all the other interface repos, I only see `relation-broken` handlers if the scope sets to `GLOBAL`. from what I read from the code, `remote unit name` is required for non `GLOBAL scope.`
[06:18] <kelvinliu_> wallyworld: we probably should set the scope to `GLOBAL` to handle the `relation-broken`.
[06:19] <wallyworld> kelvinliu_: sounds right i think
[06:21] <wallyworld> kelvinliu_: the author of the layer is cory who works for canonical. if you could do a patch and put up a PR, we can get him to look at it
[06:21] <wallyworld> raise a bug and link the PR to the bug
[06:22] <wallyworld> https://github.com/johnsca/juju-relation-mysql
[06:22] <kelvinliu_> wallyworld: I saw you set the scope to `GLOBAL` actually. But it seems the interface includes in `layer.yaml` did not use the local interface version at `./deps/interface/juju-relation-mysql`. I am reading to the docs to see how to fix this
[06:23] <wallyworld> i'm not overly familiar with the detail of the reactive layers here
[06:24] <wallyworld> at EOD today, you could raise a bug with as much detail as has been discovered in the bug and cory should see that when he starts
[06:24] <wallyworld> he's in US timezone
[06:26] <kelvinliu_> wallyworld: i was reading this https://github.com/juju-solutions/interface-mysql-root    not sure how did `charm` know which one to download 'interface:juju-relation-mysql'
[06:26] <kelvinliu_> wallyworld: yes, I will do that, thx
[06:26] <wallyworld> kelvinliu_: yeah, that's not the one the charm uses. maybe that one is more suitable
[06:27] <wallyworld> i'd need to look
[06:27] <wallyworld> the charm knows which one to use because it's in a layers file, i'll look it up
[06:27] <wallyworld> kelvinliu_: see layes.yaml
[06:27] <kelvinliu_> where did u get this ./deps/interface/juju-relation-mysql from?
[06:27] <wallyworld> layers.yaml
[06:28] <wallyworld> in the root dir of the mysql charm
[06:28] <wallyworld> charm build uses this layers file
[06:28] <wallyworld>  ./deps/interface/juju-relation-mysql is put there by charm build
[06:28] <wallyworld> based on layers.yaml
[06:30] <kelvinliu_> ic
[06:30] <wallyworld> kelvinliu_: that mysql-root one is not what we want
[06:30] <wallyworld> it's for the admin db
[06:31] <kelvinliu_> wallyworld: in the r`equires.py`, the scope is set to `GLOBAL`. donot know why they are different.
[06:32] <wallyworld> kelvinliu_: that's for the requires side
[06:40] <wallyworld> kelvinliu_: sorry, had someone at door. the bit that is failing here is on the providers side, the mysql end
[06:44] <kelvinliu_> wallyworld: would you give more details?
[06:45] <wallyworld> relations have a requires end and a provides end
[06:45] <wallyworld> mysql defines an interface that is the provides end
[06:46] <wallyworld> the logic for that is in provides.py
[06:46] <wallyworld> you can look at the charm metadata.yaml file to see the endpoints
[06:46] <kelvinliu_> ah, ic. so the requires.py -> gitlab, provides.py -> mysql, in this case
[06:46] <wallyworld> yup, that's it
[06:47] <kelvinliu_> more clear now, thx
[06:47] <wallyworld> and the reactive framework plugs in the requires vs provides bit of that mysql interface layer
[06:50] <kelvinliu_> ic. so the problem is provides/mysql can't get the remote name(`gitlab`) to get the correct conversation when the scope sets to `service` for event `relation-broken`.
[07:04] <kelvinliu_> wallyworld: created this issue here, https://github.com/johnsca/juju-relation-mysql/issues/3   plz let me know if you have more questions, thx
[07:07] <wallyworld> kelvinliu_: bug report looks ok, i'll just make a small correction - "operator" is a caas specific term which is not widely in use
[07:07] <wallyworld> kelvinliu_: i can't edit, can you change operator to "uniter hook runner"
[07:09] <kelvinliu_> wallyworld: updated, thx for the correction.
[07:09] <wallyworld> great ty
[07:11] <wallyworld> kelvinliu_: next steps include adding CI test coverage for caas deployments
[07:16] <kelvinliu_> wallyworld: yup, should I create a card on A team board for this?
[07:23] <wallyworld> kelvinliu_: yes please
[07:24] <wallyworld> kelvinliu_: we can talk more tomorrow with chris on how to get started. all the CI code is in the source tree
[07:25] <wallyworld> in the acceptancetests dir
[07:27] <kelvinliu_> wallyworld: ok, thx. let's talk this tmr morning
[07:27] <wallyworld> kelvinliu_: sounds good
[07:37] <manadart> I have added release notes for the new controller config options for spaces. Subject to editorial intervention :)
[20:38] <veebers> Morning o/