[00:07] <anastasiamac> wallyworld: thumper: if u get a chance, PTAL https://github.com/juju/juju/pull/8586 - that's worker/manifold for cred watching
[00:08] <wallyworld> anastasiamac: yeah, just finished meetings, starting my reviews now
[00:08] <anastasiamac> wallyworld: \o/
[00:09] <anastasiamac> babbageclunk: i haven't :D
[00:09] <anastasiamac> babbageclunk: but i wonder if rick_h_ has :D
[00:12] <rick_h_> What has Rick done now?
[00:13] <rick_h_> I bootstrapped from a Mac today hml
[00:24] <anastasiamac> rick_h_: \o/ i think hml eod'ed but it's good to know :) thnx !!
[00:25] <rick_h_> anastasiamac: is that what you wanted to know? It wasn't babbageclunk  but seemed only question
[00:25] <anastasiamac> rick_h_: yes, i think so :)
[00:39] <wallyworld> anastasiamac: review done, a few little things to look at
[00:55] <anastasiamac> ta
[01:47] <thumper> babbageclunk, wallyworld: small(er) branch https://github.com/juju/juju/pull/8591 ??
[01:52]  * thumper walks up to physio
[01:54] <babbageclunk> thumper: looking
[02:24] <vino> we follow gnu style flag parsing correct  for all the juju commands
[02:24] <vino> some options doesnt work that way like model.
[02:25] <vino> --model="default" or -m="default"
[02:25] <vino> both should work
[02:27] <vino> i do see the first one works fine but not the second
[02:28] <vino> sorry -m "default"
[02:28] <vino> my fault i didnt notice the '=' there
[02:29] <vino> has anyone has idea abt the --output option ?
[02:29] <vino> it is supposed to write the output to file
[02:30] <babbageclunk> vino: on which command?
[02:32] <vino> juju run
[02:32] <vino> this output option doesnt write to any file that i specify. not sure if i am missing something
[02:32] <babbageclunk> I've never tried it, tbh
[02:33] <vino> mmm... i will raise this a bug.
[02:34] <babbageclunk> yeah, I think you're right - doesn't work for me either
[02:35] <thumper> what's this?
[02:35] <vino> juju run command
[02:35] <thumper> --model default, --model=default and -m default should all work
[02:36] <vino> yes yes. i missed the'=' by mistake
[02:36] <vino> i identified it myself
[02:36] <vino> but we are talking abt the outout option
[02:36] <vino> output*
[02:37] <thumper> juju run --machine 0,1,2 juju-presence-report -o ~/sandbox/foo.yaml
[02:37] <thumper> juju run --machine 0,1,2 juju-presence-report --output ~/sandbox/foo2.yaml
[02:37] <thumper> both work for me
[02:38] <thumper> what is your command line?
[02:39] <babbageclunk> thumper: it looks like if you only specify one target (or specify --all and only have one machine, frex) it writes to stdout rather than writing through c.out
[02:39] <thumper> ah...
[02:39] <thumper> yeah...
[02:39]  * thumper nods
[02:39] <thumper> I remember writing that
[02:40] <thumper> that should be fixed I guess
[02:40] <vino> yes.
[02:40] <thumper> vino: lucky you, you have found yourself another bug to fix :)
[02:41] <thumper> vino: that one should be quite simple
[02:41] <vino> yup.
[03:00] <thumper> babbageclunk: did you want to talk about presence?
[03:00] <babbageclunk> Oh no - sorry, got distracted and went back to my own stuff.
[03:01] <babbageclunk> thumper: I read through it, looked good - I'm approving it now
[03:01] <veebers> wallyworld: if we can get a +1 on this we can finally get it landed :-) https://github.com/juju/juju/pull/8498
[03:01] <thumper> babbageclunk: sweet, I've just fixed the manifold tests, where I hadn't added the names
[03:01] <babbageclunk> oh yeah, those ones always get me too.
[03:02] <thumper> I'm not going back to the threading the presence code through the apiserver
[03:02] <thumper> fun for the friday afternoon
[03:42] <babbageclunk> oh man, it's annoying when you accidentally upgrade a controller to a version of jujud that runs but fails to start the API server
[03:56] <wallyworld> thumper: i replied to your comment about the worker loop, see what you thunk
[04:05] <thumper> wallyworld: how is it less LOC?
[04:05] <wallyworld> no worker attributes to have to declare and assign to etc
[04:06] <thumper> wallyworld: quick HO?
[04:06] <wallyworld> the initial model cred is just a var in the loop
[04:06] <wallyworld> sure
[04:46] <wallyworld> veebers: i can't see the comment on the legacy index? do you agree we need it still?
[04:48] <veebers> wallyworld: ah what, seems I was attempting to comment on the PR as a review, not in response to your question.
[04:48] <veebers> wallyworld: have commented properly now
[04:49] <veebers> but to save you a webpage reload: legacy macaroons will exist in a collection setup by a previous version of juju, so wouldn't those indices remain? Im pretty sure they aren't removed by this change, and there is no need for it to exist from this point onwards as we're just using new Juju.
[04:51] <wallyworld> veebers: i wasn't sure about the MongoIndices() behaviour - whether we wiped the existing indices and applied just the ones specified
[04:51] <wallyworld> make check an upgraded system?
[04:51] <wallyworld> to be sure?
[04:51] <wallyworld> i'd hate for the index to get wiped
[04:52] <veebers> wallyworld: I'm 99.9% certain it reamins, as I tested things expiring yesterday. That being said it wasn't a specific test for that, I'll re-do now to move to 100% certainty
[04:53] <wallyworld> veebers: maybe just a visual inspection of the indices
[04:53] <wallyworld> then land that sucker
[04:53] <wallyworld> then have a beer or six
[04:53] <veebers> wallyworld: hah yep Ill spinup a current and upgrade to this branch ver checking the indices as I go
[04:54] <wallyworld> great ty
[05:00] <veebers> Reading mgo.session suggests that what I saw was expected, only creates new ones and doesn't remove them. Also doesn't update an existing index of the same name. Will do the check though, won't take long
[05:01] <veebers> luckily we used expire-at previously and v2 uses expires, so there is no upgrade step required there ^_^
[05:15] <veebers> wallyworld: FYI before and after upgrade: https://paste.ubuntu.com/p/Yx5kzHnfr7/
[05:16] <wallyworld> looking
[05:16] <wallyworld> veebers: great!
[05:16]  * veebers $$merge$$s
[05:26] <wallyworld> babbageclunk: first thing monday, can you look at this one? i need to land it before we ship 2.4 beta1 https://github.com/juju/juju/pull/8592
[05:27] <babbageclunk> wallyworld: ok, will do
[05:27] <wallyworld> ty
[05:27] <wallyworld> it contains a data model change
[05:27] <wallyworld> don't want to have to worry about upgrades
[05:27]  * wallyworld afk to go buy coffee
[05:28] <babbageclunk> oh bugger, just realised I landed that raft branch without squashing it
[05:35] <veebers> https://github.com/juju/juju/pull/8498 -> Merge \o/
[05:35] <veebers> oh bums, same here babbageclunk :-\
[05:54]  * babbageclunk commiserates
[06:09] <babbageclunk> hmm, wallyworld - if I want to make apiserver depend on raft, it can't start because the peergrouper (which raft depends on for apiserver addresses) depends on the upgrader which depends on the api-caller.
[06:10] <wallyworld> joy
[06:11] <wallyworld> i'm not sure how to solve that off hand
[06:12] <babbageclunk> Neither. For this I technically don't need to... But to make the leadership API use it I will.
[06:15] <babbageclunk> Ok, what about a new worker that both raft and API depend on that has methods to set and get the raft. If raft hasn't been set yet, get returns an error. Then the raft worker sets it when it finishes starting up.
[06:15] <babbageclunk> Feels a bit baroque, but I think that would work?
[06:15] <babbageclunk> wallyworld: ^
[06:16]  * wallyworld ponders
[06:17] <wallyworld> that could work i think
[06:17] <wallyworld> worth spiking on in the absence of a better idea
[06:17] <babbageclunk> The key thing is that although it kind of depends on it, the API server won't need the raft until someone actually calls an API that uses it?
[06:18] <babbageclunk> yeah, I think so
[06:20] <babbageclunk> wallyworld: is the reason the upgrade steps need to be idempotent because the different controllers could each try to run them?
[06:21] <wallyworld> they are run every time aby upgrade is done
[06:21] <wallyworld> or they may half run and then the agent restarts etc
[06:22] <babbageclunk> ok - but it looks like there's also no ifPrimaryController around them either. (This is good for me - otherwise asking for leadership would be needed straight away.)
[06:22] <wallyworld> with your thought, i think only the master controller runs them
[06:22] <wallyworld> oh
[06:22] <wallyworld> maybe not then
[06:23] <babbageclunk> oops - need to go feed the animals! Will check back later to see if you have any other brainwaves!
[06:26] <wallyworld> coffee migh thelp
[06:45] <vino> the --output option works with --format specified.
[06:45] <vino> so its not a bug :)
[06:49] <vino> I am talking about juju run --output option
[06:51] <anastasiamac> vino: wallyworld: the PRs need to have reviews before landing... no?
[06:51] <vino> yes. he is doing it.
[06:51] <vino> wallyworld is reviewing.
[06:51] <anastasiamac> vino: ? m seeing $$merge$$ without a review. that's a landing...:D
[06:52] <vino> sure.
[06:52] <wallyworld> which PR?
[06:52] <wallyworld> the contributing one?
[06:52] <wallyworld> i thought chris reviewed it
[06:53] <anastasiamac> m seeing it on 8593
[06:54] <wallyworld> oops, ok, i'll stop the job thanks for picking that up :-)
[06:55] <anastasiamac> nws
[06:56] <anastasiamac> vino: very nice to see PRs up, btw :D
[06:57] <wallyworld> yeah, 3rd day and already a couple of PRs :-)
[06:57] <anastasiamac> \o/
[06:59] <vino> Thanks everyone :) :)
[07:41]  * wallyworld off to soccer, have a good weekend
[09:56] <manadart> Just pushed what I think are the last changes to https://github.com/juju/juju/pull/8578.
[11:48] <admcleod_> is it possible that the cloud-init juju use for lxd containers was updated in the last 24 hours?
[12:00] <admcleod_> hmm nvm
[12:43] <hml> morning
[12:49] <balloons> manadart, KVM done as well, interesting
[12:51] <balloons> Good morning HNL
[12:51] <balloons> lol, I'm terrible at typing
[12:52] <hml> ha
[12:52] <manadart> balloons: Yes; we can discuss in 8 mins.
[12:52] <hml> tab complete :-)
[13:33] <frankban> jam: ping, do you have a minute?
[15:00] <hml> juju devel version bootstrap from mac: if you specify —bootstrap-series xenial and —build-agent… juju builds an agent for the mac, but not for the bootstrap series of xenial.  interesting
[16:22] <hml> cross compiling juju for linux/amd64 from mac is not as easy as it should be… some dependencies of dependencies are missing.  :-/
[16:23] <balloons> hml, ugh. We used to do the oppposite easily enough
[16:23] <balloons> anyone want to have a quick look https://github.com/juju/juju/pull/8596?
[16:23] <hml> balloons: blows up in LXD… trying to find a way forward now
[16:23]  * hml looking
[16:24] <hml> balloons: lgtm
[16:45] <hml> something is definately weird with cross compiling juju from mac - it’s failing on a wrong version issue (mismatch of arguments) of a package not required in ubuntu juju build environment
[16:48] <balloons> hml.. wow. Did you hit a wall?
[16:48] <hml> yup
[16:48] <hml> balloons: i can’t build the lxc client either… which i should be able to do on mac per the github
[16:49] <hml> so perhaps i there is something else wrong or not right yet
[16:49] <hml> ???
[16:49] <balloons> hml, gotcha. Well the answer is to use ubuntu :-) Always the right answer
[16:50] <hml> it’s odd where it’s failing though…
[16:55] <hml> balloons: at least the reverse works?  i can cross compile on ubuntu for mac.. .and without the package that’s failing the otherway.  :-)
[16:55] <balloons> hml, yea, reverse is easy. But we build natively now on mac
[17:02] <hml> https://pastebin.ubuntu.com/p/GFtYqH5jdK/  <— this is where i’m at
[17:28] <hml> holy crap balloons, I think I just had a good complete total run with the new ci test!.
[17:28] <balloons> WHA!?
[17:28] <hml> I KNOW!  right
[17:28] <balloons> hml, that is awesome
[17:29] <balloons> Your thoughts on writing a test would be most appreciated as usual :-)
[17:29] <hml> balloons: here’s the log: http://paste.ubuntu.com/p/Qp2Nzxf2rM/
[17:30] <hml> balloons: sure… will ponder things for the new folks
[17:30] <hml> it took 1h45 to run at home.  bleh
[17:30] <balloons> hml, a good feeling though to see it do all that work eh?
[17:30] <hml> balloons: almost…
[17:31] <balloons> hml, yea.. that's amazingly long.  But perfect for something that clearly isn't trivial to do yourself
[17:31] <hml> balloons:  it wasn’t the whole thing…  but the long part that i’d been having trouble with
[17:31] <hml> :-(
[17:31] <hml> but the other part is already working
[17:32] <hml> so stil a happy day
[17:32] <balloons> hml, yea.. somehow despite my efforts is I always give folks some real doozey's to start with
[17:32] <balloons> I guess all the easy stuff already has tests eh?
[17:32] <hml> perhaps.. it shouldn’t have been this hard to write
[17:33] <balloons> I will agree on that
[17:33] <hml> i’d stil like to understand what is going on in the ci test “libraries” such that i couldn’t get juju run or juju ssh working consistently
[17:34] <balloons> hml, believe it or not the library used to be 3 or 4 times bigger than it is now. It's still way too big
[17:34] <hml> wow
[17:34] <balloons> as always.. it's MUCH better than it was. Ask chris if you don't believe me :-)
[17:37] <hml> doing one last run with the other two parts while i clean up the commented out code and comment other stuff….
[17:37] <hml> crossing fingers for real PR by EOD - if i didn’t get jinx myself
[18:32] <balloons> I'm having fun making the release process better. Always something low-hanging to automate
[18:34] <balloons> and of course everything works fine for me
[18:40] <hml> of course
[19:26] <hml> balloons: for your reviewing pleasure: https://github.com/juju/juju/pull/8563
[19:26] <balloons> hml, yay
[19:26] <hml> now to figure out how to get the job created
[19:32] <balloons> thanks hml. I actually edited that file today when I was doing it myself
[19:32] <balloons> that is, the readme on how to add a job
[19:32] <hml> balloons: can you give me the link again?  i lost it :-(
[19:33] <balloons> hml, feel free to tweak the document in general. It could use it I think. It kind of runs on
[19:35] <hml> balloons: ack
[19:36] <hml> always fun when a new person uses the docs. :-)
[19:37] <balloons> hml, first glance is this looks really nice, especially for your first effort
[19:51] <hml> balloons: what does “artifacts the job results” mean?
[19:56] <balloons> hml, in the yaml or in general?
[19:56] <hml> it’s mentioned in the readme for creating a new test yaml
[19:56] <balloons> it means it will retain copies of whatever build artifacts you specify. Otherwise they'll be gone
[19:57] <hml> ack
[20:06] <hml> balloons: running jenkins-jobs test locally to test the yaml, should a job be generated?
[20:06] <balloons> I think it spits it out on the console
[20:06] <balloons> I never really run test -- just push and try it
[20:06] <hml> ah
[20:07] <balloons> if it fails to parse, it will fail to create the job
[20:07] <balloons> no harm in pushing it several times, running, and tweaking
[20:07] <hml> it passed parsing
[20:07] <balloons> make sense?
[20:07] <hml> yup
[20:18] <balloons> hml, reviewed, again very nice
[20:18] <hml> balloons: ty
[20:19] <balloons> hml, ready for another? :p
[20:19] <hml> balloons: i’ll take a small break for now.. but i have a feeling the backup restore test is in my future
[20:20] <balloons> hml, I think that was a great warmup to it. To be fair, the test for backup / restore exists. Though, it's unclear if I'd advise you to use much, if any , of it
[20:20] <hml> :-)
[20:31] <balloons> a quicky for anyone https://github.com/juju/juju/pull/8597
[20:32] <hml> balloons: how do those work?  i’m not sure what i’m looking at with the pr
[20:32] <hml> :-)
[20:32] <balloons> hml, I discovered one of the patches (look at the Makefile for reference on when we use it, and the README in patches folder for context) isn't being applied because it's .patch, not .diff
[20:33] <hml> ah
[20:34] <hml> how did we get away with “forgetting” that patch?
[20:37] <balloons> hml, it's another reason I'm not a fan of them. Easy to not include them