[00:11] <anastasiamac> thumper: wallyworld: PTAL https://github.com/juju/juju/pull/9125 - fix for critical
[00:11] <anastasiamac> i've proposed against 2.3 and will forward-port once landed.
[00:42] <anastasiamac> babbageclunk: veebers: any chance u could review ^^
[00:42] <babbageclunk> anastasiamac: sure
[00:43] <anastasiamac> babbageclunk: my hero \o/ tyvm
[00:45] <wallyworld> veebers: sorry, just got off the meeting. i don't know what the issue might be off hand
[00:45] <babbageclunk> anastasiamac: approved!
[00:46] <anastasiamac> \o/
[00:52] <veebers> anastasiamac: sorry was at lunch :-\
[00:52] <anastasiamac> veebers: how could u?
[00:52] <anastasiamac> :D
[00:52] <anastasiamac> nws
[00:53] <veebers> :-)
[01:20] <thumper> anastasiamac: I'm looking to forward port 2.3 into 2.4
[01:20] <anastasiamac> thumper: k but my stuff will be there shortly (and on develop)
[01:21] <anastasiamac> thumper: m happy to review, once u propose if u want
[01:21] <thumper> anastasiamac: it is in 2.3 now
[01:21] <thumper> I noticed it there
[01:22] <anastasiamac> yep. i've pr'ed against 2.3 originally, this morning
[01:22] <anastasiamac> 2.4 and develop landing is happening now
[01:22] <anastasiamac> gofmt against develop seems to be stricter?
[01:25] <anastasiamac> thumper: and merged into 2.4
[01:26] <veebers> wallyworld: I believe one of my issues re: cleanup is conditionally setting statusOps (i.e. if caas use cloudcontainer key, otherwise unit) so removeOps is dying (I haven't touched that yet).
[01:26] <thumper> anastasiamac: I've found a problem with your patch :(
[01:26] <thumper> anastasiamac: was QAing it
[01:26] <anastasiamac> :( what's it>
[01:26] <anastasiamac> ?
[01:26] <veebers> wallyworld: is that the way forward, or instead of having the absence of a status via key be the decider should the caas check happen at the GetStatus end?
[01:26] <thumper> anastasiamac: I deployed keystone like the bug did
[01:26] <thumper> then went "juju config keystone vip"
[01:26] <wallyworld> veebers: quick HO?
[01:26] <thumper> there used to be no value
[01:26] <thumper> now there is a blank line
[01:27] <veebers> wallyworld: sure thing
[01:27] <veebers> wallyworld: standup?
[01:27] <wallyworld> ok
[01:27] <veebers> wallyworld: one sec, I smell smoke . .
[01:27] <anastasiamac> thumper: ahhh, yes coz it's Println... should it not be? just Print..
[01:27] <thumper> anastasiamac: confirmed with 2.2.6 cli
[01:27] <thumper> anastasiamac: just nothing
[01:28] <thumper> anastasiamac: I'll pastebin
[01:28] <anastasiamac> thumper: k. no need... i understand
[01:28] <veebers> ;all good, no smoke or stroke
[01:28] <thumper> anastasiamac: always good to be explicit... https://paste.ubuntu.com/p/sgszfhQTpQ/
[01:29] <thumper> wallyworld: when do you want to talk watchers
[01:29] <thumper> ?
[01:29] <wallyworld> otp now, maybe soon
[01:29] <anastasiamac> thumper: k. so I have added a *Println as jam's recommendation was to append newline tot he value
[01:29] <thumper> anastasiamac: which we should do for non nil values
[01:30] <anastasiamac> i'll go back and remove the newline :D thumper
[01:30] <thumper> no...
[01:30] <anastasiamac> thumper: ack
[01:30] <anastasiamac> newline wihen there is value and none where nil value
[01:30]  * thumper nods
[01:30] <thumper> yep
[01:30] <anastasiamac> k. so hold off porting 2.3 into 2.4
[01:30] <thumper> yep will do
[01:30] <anastasiamac> i'll propose agaisnt 2.3 ifrst
[01:31]  * thumper nods
[01:35] <babbageclunk> wallyworld: trivial review for bumping up the timeout? https://github.com/juju/juju/pull/9128
[01:35] <wallyworld> ok
[01:37] <wallyworld> babbageclunk: i wonder why this change got include in the lock file gopkg.in/goose.v2/testservices/neutronmodel
[01:37] <wallyworld> doesn't seem related
[01:37] <babbageclunk> wallyworld: yeah, I was about to put a comment on the PR about that.
[01:38] <babbageclunk> I'm not sure. I was tempted to remove it, but presumably that would just mean that the next person to do a dep change would include it.
[01:38] <babbageclunk> kelvinliu: ^?
[01:38] <kelvinliu> babbageclunk, how's going
[01:40] <babbageclunk> kelvinliu: I got a weird change in Gopkg.lock when I updated an unrelated dependency, just wondering if you had any ideas about it.
[01:41] <babbageclunk> kelvinliu: https://github.com/juju/juju/pull/9128/files#diff-bd247e83efc3c45ae9e8c47233249f18R1820
[01:42] <kelvinliu> babbageclunk, i guess if it's a dep of github.com/juju/pubsub
[01:43] <babbageclunk> No, I don't think it's related.
[01:43] <babbageclunk> Maybe it's version differences between different people's dep binaries?
[01:44] <anastasiamac> thumper: so ha.. if the value is nil then we would not print a newline... if a value is '' (empty string), we would?... previously, say in 2.2.6, we did not... in fact, in 2.3- we have never had a newline...
[01:44] <anastasiamac> (unless it was included as the actual value for the setting)
[01:44] <thumper> anastasiamac: I'd say if the value is the empty string then yes to newline
[01:45] <thumper> nil or missing is no value
[01:45] <anastasiamac> k
[01:45]  * thumper thinks
[01:45] <thumper> this is a break in our behaviour
[01:45] <anastasiamac> adding newline? yes
[01:45] <thumper> we broke STSs scripts
[01:45] <thumper> I'm wondering if adding a new line will continue to break their scripts
[01:46] <anastasiamac> it could...
[01:46] <thumper> yeah...
[01:46] <kelvinliu> babbageclunk, https://github.com/juju/juju/blob/develop/provider/openstack/local_test.go#L37
[01:46] <anastasiamac> adding newline was not required for the original fix anyway...
[01:46] <thumper> anastasiamac: I think we shouldn't add the new line now
[01:46] <thumper> anastasiamac: perhaps leave a note for Juju 3.0
[01:46] <kelvinliu> babbageclunk, i think it's introduced before ur PR, but someone forgot to run make dep
[01:46] <thumper> to add a new line
[01:47] <kelvinliu> babbageclunk, sorry, it's make rebuild-dependencies
[01:47] <babbageclunk> kelvinliu: ahh, yeah, I think that makes sense.
[01:47] <anastasiamac> thumper: ack, i'll add the note, card in 3.0 list and a bug :)
[01:47] <babbageclunk> wallyworld: I think that's the explanation, I'm ok if you want me to pull it out of the PR.
[01:48] <wallyworld> babbageclunk: if it's to fix a previous error then that seems ok to me
[01:51] <babbageclunk> It seems like that section in Gopkg.lock is going to change in surprising/unrelated ways when someone changes a dependency, since anytime someone adds an import of a previously-unimported package from an existing dependency it's going to be added here.
[01:51] <babbageclunk> (and I don't think it would be reasonable to insist that people run rebuild-dependencies when they haven't really changed them)
[01:54] <anastasiamac> thumper: PTAL https://github.com/juju/juju/pull/9129
[02:01] <thumper> anastasiamac: a suggestion and a question
[02:02] <thumper> babbageclunk: I hit the session closed bug again in the lease manager
[02:02] <thumper> babbageclunk: https://paste.ubuntu.com/p/84rSqXGsjg/
[02:04]  * thumper goes to make coffee
[02:07] <babbageclunk> thumper: ah, thanks - looking now
[02:08] <anastasiamac> thumper: and updated PR
[02:08]  * anastasiamac crosses fingers and makes tea
[02:09] <babbageclunk> thumper: ok - I guess the fix is to add a waitgroup to the manager and make sure it waits for all of the goroutines to be finished before stopping. Sound right to you?
[02:09] <babbageclunk> thumper: how do I reproduce it - running state tests under stress?
[02:10]  * babbageclunk will assume that until further notice.
[02:12] <thumper> babbageclunk: it is fucking hard to reproduce
[02:13] <thumper> babbageclunk: re waitgroup, yeah I think something like that may be necesssary, I'm going to take a peek
[02:17] <thumper> babbageclunk: got time to talk this through?
[02:20] <babbageclunk> thumper: sure
[02:29] <wallyworld> thumper: here's a PR to address the charm version issue https://github.com/juju/charm/pull/258
[02:29] <veebers> wallyworld: I'm either confused or my plan won't work, the unit workload status is initiall set at unit start (allocating), the caas provisioner updates the details (i.e. started container), if the unit status goes to 'unknown' or maintenance  state (i.e. agent error) then the cloud container status will never hit the criteria to update the status (unless it errors).
[02:30] <wallyworld> or anastasiamac ^^^^^ :-)
[02:30] <veebers> resulting in a status of 'maintanence, message: Waiting for mysql container' while the cloud container status is 'Started container'
[02:30]  * anastasiamac looking
[02:30] <anastasiamac> wallyworld: could u ptal 9129, just in case?
[02:31] <wallyworld> veebers: right, remember this is a stop gap until we thread stuff through. if the charm sets status to maintenance, we won't show container status unless it's an error and we choose to use it
[02:31] <thumper> wallyworld: I thought the entire purpose of this was to not log a warning message
[02:32] <veebers> wallyworld: ack, but it also means that it'll never go to an 'active' status as that info is now piped though cloud container status (which won't overwrite any unit status)
[02:32] <wallyworld> thumper: 2 things 1. it was logging a warning unnecessarily due to a git issue, 2. IMO we do want to inform the user if the version generation fails, so i have improved the message
[02:32] <wallyworld> i think the bug was due to some bogus message wthout enough info
[02:32] <wallyworld> if there's a genuine error we should surface it
[02:32] <thumper> I would say it should be informational to the user, it isn't a warning
[02:33] <wallyworld> i can chabge it to INFO but that will be hiddn by default
[02:33] <wallyworld> it soimething fails surely that's a warning
[02:33] <thumper> so... if I understand this, if it is in revision control and it hits an error we get a warning
[02:33] <thumper> what was the problem they were seeing?
[02:33] <thumper> why was there an exit code of 128?
[02:34] <wallyworld> because "git describe" failed
[02:34] <wallyworld> it couldn't generate a version sha
[02:34] <wallyworld> and we were not surfacing the true error string
[02:34] <wallyworld> hence the changed cmd.exec code also
[02:35] <wallyworld> it was failing because there were no tags available for it to use in the output
[02:35] <wallyworld> so we needed to be passing in --always
[02:35] <wallyworld> so that it would at least print the sha (without tag)
[02:36] <wallyworld> and without complaining
[02:36] <wallyworld> make sense?
[02:37] <wallyworld> veebers: for now she should also special case "active"
[02:37] <wallyworld> *we
[02:37] <veebers> wallyworld: ack, have done so now :-)
[02:37] <veebers> if cloud container active use it, currently have && unit status == maintanence but I think that's a bit much
[02:38] <wallyworld> yeah it is
[02:38] <wallyworld> could have been error->active
[02:38] <wallyworld> eg if we fix the stroage claim it will come good
[02:38] <veebers> ack, thanks wallyworld!
[02:39] <thumper> wallyworld: can you jump into our 1:1?
[02:39] <wallyworld> ok
[03:09] <veebers> what did we ever do without colour log output :-)
[03:17] <babbageclunk> thumper: I ended up reimplementing the waitgroups fix so I could check my test passed with it. I might just push it as a PR if that's ok? :)
[03:18] <thumper> sure
[03:23] <anastasiamac> kelvinliu: veebers just got a 'recipe for target 'dep' failed'... m assuming it's not related to my change, so m !!build!!Ing but would love to know what's going on.. http://ci.jujucharms.com/job/github-check-merge-juju/3211/console
[03:25] <veebers> anastasiamac, kelvinliu I *think* that's a network connectivity thing, it couldn't hit golang.org for some reason, I suspect it's transient; lets see how the rerun goes
[03:25] <anastasiamac> thumper: newline saga landed in 2.3.. feel free to move 2.3 to 2.4 :D
[03:26] <thumper> anastasiamac: ack
[03:26] <anastasiamac> veebers: \o/ thank you :) let's hope...
[03:26] <kelvinliu> veebers, anastasiamac yeah, let's see the re-run.
[03:35] <wallyworld> kelvinliu: i had to make a change to charm.v6 to fix some version string issues. can you add to your todo list making a charm build PR with the same fixes https://github.com/juju/charm/pull/258
[03:35] <kelvinliu> wallyworld, sure
[03:35] <wallyworld> gr8 ty
[03:38] <kelvinliu> np
[03:52] <babbageclunk> thumper: review pls? I just extended the test to check for both claims and ticks. https://github.com/juju/juju/pull/9131
[03:52] <thumper> kk
[03:52]  * thumper looks
[03:52] <babbageclunk> thumper: oh hang on - still pushing that last bit.
[03:52] <thumper> k
[03:52] <babbageclunk> bally gometalinter
[03:54] <babbageclunk> thumper: ok done
[03:56] <thumper> ffs
[03:57]  * thumper has a failing test but I think it is a lxd test isolation bug
[03:57] <anastasiamac> thumper: fwiw, i'd rather forward-port my hcange manually.. there is a new test that was added in 2.4 that will fail so test needs to b adjusted too.
[03:57] <thumper> anastasiamac: ok, do you want to take my change as well?
[03:57] <thumper> if you do the 2.3 merge, it is just yours and mine
[03:58] <anastasiamac> thumper: honestly? no... but i can if u command ;)
[03:58] <thumper> mine is only 4 lines and clean mege :)
[03:58] <thumper> pretty please
[03:58] <anastasiamac> thumper: k
[03:58]  * anastasiamac saluts
[03:58] <anastasiamac> salutes even?*
[04:00] <thumper> anastasiamac: thank you
[04:07] <wallyworld> babbageclunk: were you going to join us in this meeting?
[04:07] <babbageclunk> oh yes - send me an invite?
[04:23] <anastasiamac> thumper: merge PR - https://github.com/juju/juju/pull/9134
[04:33] <thumper> anastasiamac: lgtm
[04:33] <anastasiamac> \o/
[04:45] <veebers> wallyworld: you have a moment to talk migration_export? Do I need to add to juju/description a SetCloudContainerWorkloadStatus or so (so I can export the #container status data) or should I finagle it in with the existing SetWorkloadStatus()?
[04:45] <wallyworld> on a call give me 5
[04:45] <anastasiamac> 'finagle' is totally a word too
[04:46] <veebers> ack
[04:46] <veebers> hmm, I didn't realise it meant in a devious manner, I thought it meant in a tricky manner :-)
[04:47] <anastasiamac> 'devious, dishonest' :( i did not know either ...
[04:49] <veebers> anastasiamac: I take it your 2nd build run went fine?
[04:49] <anastasiamac> veebers: yes, thnx :) must have ben connectivity like usaid...
[04:58] <wallyworld> babbageclunk: here's a small dep change https://github.com/juju/juju/pull/9135
[04:58] <wallyworld> veebers: free now
[04:59] <babbageclunk> wallyworld: looking
[04:59] <wallyworld> HO?
[04:59] <veebers> wallyworld: sweet, shall we HO ?
[04:59] <veebers> hah omw
[05:00] <babbageclunk> wallyworld: approved. You and veebers should hang out.
[05:00] <wallyworld> ty. we alrerady are :-)
[05:01] <babbageclunk> hey thumper are you happy with https://github.com/juju/juju/pull/9131?
[05:01] <veebers> lol babbageclunk the match maker ^_^
[05:02] <veebers> hey, I know a cool guy. You should hangout and talk migration exports some time
[05:02] <babbageclunk> you crazy kids
[05:27] <anastasiamac> noticed, i've introduced a test where ordering matters on develop... working on a fix now :(
[05:29] <veebers> wallyworld: FYI https://github.com/juju/juju/pull/9081 I'll need to add another test for the conditional cloudcontainer/unit status usage too
[05:29] <wallyworld> ok, ty
[05:29] <wallyworld> will look soon
[05:30] <veebers> ack, thanks
[05:41] <anastasiamac> trivial change, could someone review plz? https://github.com/juju/juju/pull/9136
[05:48] <wallyworld> anastasiamac: looking
[05:48] <wallyworld> anastasiamac: also, i'm an idiot https://github.com/juju/charm/pull/259
[05:48] <anastasiamac> wallyworld: ta :)
[05:48]  * anastasiamac looking too
[05:51] <anastasiamac> thumper: 2.4 branch is upto date as far as urs and my changes :) just wallyworld's one needs to come in and we r golden i *think*
[05:52] <wallyworld> ty
[05:52] <wallyworld> i'll have to wait for snap to build i think soi can copy across
[05:52] <anastasiamac> k
[05:55] <babbageclunk> wallyworld: can you take a look at this https://github.com/juju/juju/pull/9131, thumper has forsaken me.
[05:55] <wallyworld> ok
[06:01] <wallyworld> babbageclunk: i have some questions aboput the test
[06:02] <wallyworld> i think it may be racy and we need some extra selec/retry loops
[06:02] <wallyworld> we use retry loops in other tests with an attempt strategy
[06:43] <wallyworld> vinodhini: how goes the export bundle fix?
[06:44] <vinodhini> wallyworld: i pinged u this morning that i pushed the commit. in canonical #juju
[06:45] <wallyworld> vinodhini: ah, you said "wallyworld." not "wallyworld:"
[06:45] <wallyworld> so i didn;t get pinged
[06:45] <vinodhini> ok.
[06:45] <vinodhini> :)
[06:45] <wallyworld> i'll take a look
[06:46] <vinodhini> i am sorry wallyworld
[06:46] <wallyworld> tis ok :-)
[06:54] <vinodhini> wallyworld : do u need that to be changed ?
[06:54] <wallyworld> i'm leaving a few small comments
[06:54] <vinodhini> that check* - now it checks "instance"
[06:54] <vinodhini> oh ok.
[06:54] <vinodhini> sure
[06:59] <wallyworld> vinodhini: so yeah, just a few small things, but the relation scope test appears inadequate as written I think, but i could be wrong about that
[07:00] <vinodhini> wallyworld u mean the unit test for relationscopeskipping ?
[07:00] <wallyworld> yeah
[07:00] <wallyworld> we need to ensure that the would be an error if skiprelationscope were nnot true
[07:00] <wallyworld> i'm not sure that is the case but am not 100% sure
[07:05] <vinodhini> wallyworld : I agree it is in adequate. But can we look at it in a way that if the relation scope is missing it just skips that.
[07:05] <wallyworld> but we need to prove it in a test
[07:05] <wallyworld> it failed before, so we do a fix. but unless we test the fix, we are not doing the job
[07:06] <wallyworld> all bug fixes should have tests to catch the rror
[07:11] <vinodhini> wallyworld I get what u say. like how it is proven in other tests
[07:11] <vinodhini> this just going to hit the error : missing relation scope for wordpress:db mysql:server and mysql/0' if we comment that SkipRelationScope
[07:13] <wallyworld> vinodhini: if we can comment out the skip=true and the test fails and we add skip=true and it passes that is sufficient
[07:13] <vinodhini> there needs to be still be some entity to prove when we skip that check
[07:13] <vinodhini> yes it happens now.
[07:13] <wallyworld> vinodhini: also, FYI, i fixed an issue with charm version string. part of the issue was that there were more cases of errors being ignored https://github.com/juju/juju/pull/9135
[07:14] <wallyworld> ok, if the test fails that way then i think it is ok
[07:14] <wallyworld> i just wasn't sure it would
[07:15] <vinodhini> wallyworld i do that PR charm version fix u did with develop.
[07:15] <vinodhini> this timedelay issue i am working on 2.4.2
[07:16] <wallyworld> vinodhini: i already fixed it just now, just wanted to show you so you knew about the issue i had to fix for learning
[07:19] <vinodhini> ok wallyworld this is something i did in June - charm version
[07:20] <wallyworld> yeah. it was broken but no one uses it yet really so no one noticed
[07:20] <vinodhini> wallyworld :  so the unit test is for now ok. i can address the other 2 comments
[07:20] <wallyworld> i think so
[07:53] <vinodhini> wallyworld : can u chk again now the PR ?
[07:53] <vinodhini> so we can land it.
[07:53] <vinodhini> i have done state unit tests
=== alephnull_ is now known as alephnull
[09:02] <manadart> Need a review of https://github.com/juju/juju/pull/9139
[09:03] <manadart> jam, stickupkid ^ I am actually still doing the QA system testing steps, but some feedback in the interim...
[09:08] <stickupkid> "cmd/jujud/updateseries/updateseries_test.go:1::warning: file is not goimported (goimports)
[09:08] <stickupkid> service/systemd/service.go:1::warning: file is not goimported (goimports)"
[09:08] <stickupkid> manadart: you need to fix those files
[09:09] <manadart> stickupkid: Ack.
[09:10] <manadart> Pushed.
[09:11] <stickupkid> manadart: nice one
[09:22] <stickupkid> manadart: so 2.0.x LXD didn't send the server name, so when we're doing zone distribution the machine zone would be empty for all servers, even though there was one, it caused it to show the error message
[09:23] <manadart> Yes, I surmised this when I saw your patch yesterday.
[09:23] <stickupkid> manadart: the fix was easy enough, the issue is, now we've got the same issue as before, where by the it can't find the lxd-config file for the network setup
[09:23] <stickupkid> so i suspect something is amiss
[09:23]  * manadart sighs.
[10:36] <stickupkid> manadart: got a sec?
[10:37] <manadart> stickupkid: Yep. HO.
[11:38]  * rick_h_ grumbles about relogging into irc and such
[11:40] <rick_h_> manadart: do you have time to review https://github.com/juju/juju/pull/9122 today please?
[11:41] <manadart> rick_h_: Yes.
[11:41] <rick_h_> manadart: ty!
[11:43] <stickupkid> nice, that's an annoying message in the status output
[12:37] <manadart> hml: Any chance you can look at https://github.com/juju/juju/pull/9139?
[12:37] <hml> manadart: sure.
[12:38] <manadart> Ta.
[13:36] <cory_fu> Has anyone seen "could not get environ: Get https://10.105.194.1:8443/1.0: Unable to connect to: 10.105.194.1:8443" from Juju when provisioning machines on lxd before?  http://p.ip.fi/FWSs
[13:46] <stickupkid> cory_fu: edge or 2.4.x?
[13:47] <cory_fu> stickupkid: 2.4.1, it would seem.  Note: I'm asking this on behalf of someone in #conjure-up
[13:47] <stickupkid> cory_fu: i've never seen it, was just wondering what code base to at least look at
[13:48] <stickupkid> mandart: you see that?
[13:57] <rick_h_> cory_fu: that seems like a network issue to the lxd api server. Is this already bootstrapped and failing on provisioning new containers? Or is this during bootstrap?
[13:59] <cory_fu> rick_h_: Link is a full juju status.  It's late in a deployment of openstack (machines 15 and 16), and, while retry-provisioning did nothing, remove-unit + add-unit worked and got them moving.  Maybe all that's needed is a retry, or even just getting retry-provisioning to do the right thing
[14:00] <cory_fu> Obviously, there's not much juju can really do if it can't talk to lxd, but Juju does know that clouds are unreliable so should be able to recover more gracefully
[14:09] <rick_h_> cory_fu: yea, I wonder if retry-provisioning would work in this case to try again and pick up the machines?
[14:09] <cory_fu> rick_h_: It didn't
[14:09] <cory_fu> Seems like it should
[14:09] <rick_h_> cory_fu: :( then yea seems like it should
[15:14] <hml> manadart: unrelated to your pr, i found a false positive with the jujud-updateseries cmd
[15:14] <hml> manadart: just a heads up, not sure if it will impact the new work
[15:15] <hml> manadart: https://pastebin.ubuntu.com/p/hmfPPdgPMm/
[15:15] <hml> manadart: services are reported restarted when they weren’t
[15:20] <manadart> hml: I can't see the issue in the paste. They are loaded and active...
[15:21] <hml> manadart: they’ve been running for 5 min, but i ran the jujud-updateseries command 30sec before
[15:21] <manadart> Ah.
[15:22] <hml> manadart: i’m pretty sure they would have failed during the restart… if really a restart, because the series of the link to tools wouldn’t have matched the current versions
[15:22] <hml> manadart: since i ran the command without doing the upgrade to check the links
[15:25] <manadart> hml: Do you still have that environment up?
[15:25] <hml> manadart: yes
[15:25] <manadart> hml: Can we do a quick HO?
[15:25] <hml> manadart: sure - omw
[15:55] <aisrael> cory_fu: I just ran into a case where a charm's reactive flag was cleared before a second @when was invoked, leading me to discover register_trigger (which is very useful). I had a @when('config.changed') that wasn't running, presumably, because the flag was cleared. Was there a change in that behavior sometime recently, or did I just get lucky before?
[16:01] <jam> guild: if anyone is around, https://github.com/juju/juju/pull/9140 is a potential fix for the errors they are running into in bug #1789211 I still need to grab VMWare credentials and actually test that it fixes the problem
[16:01] <jam> but it does seem likely to fix it.
[16:01] <cory_fu> aisrael: You must have just gotten lucky.  It's been the case that clear_flag re-checks the queue for some time, though I think it's a mistake
[16:24] <rick_h_> kwmonroe: cory_fu magicaltrout zeestrat bdx 37min warning for juju show time. I've started up an agenda/notes doc https://discourse.jujucharms.com/t/juju-show-38-wed-aug-29th-17-00-utc/202
[16:24] <rick_h_> feel free to add anything
[16:25] <cory_fu> kwmonroe: You wanted me to mention the Azure integrator charm?
[16:26] <cory_fu> kwmonroe: It doesn't look like the support for that has been released in the k8s charms yet
[16:33] <kwmonroe> cory_fu: yeah, mention it anyway.  thataway, i can be like "and now, here's the vsphere integrator, which is totally functional and released in the k8s charms.
[16:34] <cory_fu> lol
[16:34] <cory_fu> kwmonroe: I'm happy to join, but it might flow better for you to just talk about both
[16:34] <kwmonroe> roger that cory_fu
[16:40] <cory_fu> kwmonroe: Added to the Discourse
[16:45] <rick_h_> cory_fu: kwmonroe put into the main notes linup
[16:45] <rick_h_> lineup
[16:49] <rick_h_> cory_fu: kwmonroe bdx magicaltrout zeestrat https://hangouts.google.com/hangouts/_/dp4hqk72ubd7bllbbvr3hj2xhae is the HO url
[16:49] <rick_h_> for folks that want to watch the stream at home without joining https://www.youtube.com/watch?v=i5TGTiwXrmc
[18:48] <kwmonroe> rick_h_: i have a problem making my discourse post about k8s/vsphere... the top K8s category is about deploying workloads on k8s (juju add-k8s).  where should posts about traditional k8s charms (like cdk) go?  perhaps Charming -> Kubernetes to follow the big data subcategory model?  i think we'll confuse people if we (read: you) don't get this right.
[18:50] <rick_h_> kwmonroe: bah, so I'm not a fan of all the k8s stuff in root ATM and all pinned. I agree there's some room for "best place".
[18:50] <rick_h_> Basically not sure for now. I'll have to get wallyworld on board with a better setup
[18:51] <kwmonroe> roger dodger
[20:12] <stickupkid> hml: thanks for QA'ing my PR :D
[20:14] <hml> stickupkid: np
[21:03] <bdx> excellent juju show - sorry I missed -  druid looks sweet!!
[21:05] <rick_h_> bdx: :) we missed you dude
[21:07] <bdx> im hustling trying to get this controller out the door
[21:09] <bdx> getting cut by the "I'm the only person to try and do it" knife I feel
[21:10] <bdx> trying to use jujucharms.com as identity for my own controller is not as straight forward as I was hoping
[21:10] <bdx> is there something I'm missing here ?
[21:10] <bdx> concerning using jujucharms.com for identity
[21:11] <rick_h_> bdx: honestly I'm not sure. I saw your reply about the 509 error and I'd not expect that but I know we put some magic in Juju for "juju login jaas" to work
[21:11] <rick_h_> bdx: the guys that work on that stuff are in the EU and EOD atma
[21:14] <bdx> got it
[21:23] <bdx> rick_h_: I think the problem is "no way to register external users on controller using jujucharms.com identity"
[21:24] <rick_h_> bdx: right, that's the issue to figure out. Juju knows about jaas baked in so any external users just login and they're off
[21:24] <bdx> I see
[21:24] <rick_h_> bdx: so I'm not sure if you can/need to preseed the controller info? Or if there's another tool/bit to it
[21:24] <bdx> ok
[21:25] <rick_h_> bdx: the good news is that mhilton that wrote the post for you wrote most of candid and works on that stuff
[21:25] <rick_h_> bdx: so you're on the right track there and just need to prod them for moving forward another couple of steps in the doc he started
[21:25] <bdx> ok perfect
[21:37] <babbageclunk> wallyworld: morning! Sorry I missed your qs about the test for that PR - I've put some answers in now. Alright for me to hit merge on it?
[22:06] <veebers> wallyworld: I'm looking for a better way, currently want to add something like "func (u *Unit) SetCloudContainerStatus(...)" so I can write this test (i.e. to mirror Unit.SetStatus() so I can prime statuses to then test the results
[22:09] <wallyworld> veebers: what do we do currently in the tests? i think we use UpdateUnitOps or something
[22:09] <veebers> wallyworld: ah good point I'll have a deeper look now
[22:10] <veebers> wallyworld: yeah that should do the job, thanks1
[22:13] <babbageclunk> wallyworld: mind if I land that pr given the answers?
[22:14] <wallyworld> babbageclunk: which PR? ECONTEXT
[22:14] <babbageclunk> wallyworld: sorry https://github.com/juju/juju/pull/9131
[22:14]  * babbageclunk lolles at ECONTEXT
[22:15] <wallyworld> babbageclunk: yes, go for it. thanks for clarifying. i should have looked at the content of those methods sorry
[22:16] <babbageclunk> wallyworld: thanks! No worries!
[22:17] <babbageclunk> What the... how does running a state test suite require building apiserver/facades/controller/migrationtarget?!
[22:33] <wallyworld> rick_h_: that export bundle branch compile error you had - it has to be something in your setup right?
[22:33] <wallyworld> did you run the make target which removes the vendor folder?
[22:33] <wallyworld> make godeps
[23:17] <wallyworld> veebers: veeeeeebeeeeers
[23:26] <rick_h_> wallyworld: I didn't get anchance to go back at it.
[23:30] <wallyworld> rick_h_: no worries
[23:34] <veebers> Only an agent can be status.Allocating right? A unit cannot?
[23:42] <thumper> wallyworld: any update on the firewaller test problems I see on my branch?
[23:43] <wallyworld> thumper: i'm still finishing all my morning meetings. almost ready to start
[23:43]  * thumper nods