[00:10] <veebers> thumper, wallyworld (anyone) Tests are passing, ready for another review: https://github.com/juju/juju/pull/8498 Have been doing some manual testing as well
[00:44] <wallyworld> veebers: awesome, just got out f all my meetings for a bit (until next one), will look
[00:45] <wallyworld> 181 files! close to a record :-)
[00:45] <wallyworld> i think babbageclunk has the recent record with his raft one
[00:47] <wallyworld> veebers: remind me - the utlimate plan is to go to macaroon.v2 rather than unstable right, but we need to do this in stages
[00:52] <thumper> wallyworld: there is no macaroon.v2
[00:52] <thumper> it is all unstable
[00:53] <thumper> my brain is almost exploding
[00:53] <thumper> threading the presence stuff through hit model migrations
[00:53] <veebers> wallyworld: initially we wanted to up deps but stopped short of macaroon v2-us, then we decided to get in line with what charmstore.v5 had (hence the macaroon-bakery.v2-us parts)
[01:18] <wallyworld> veebers: review done, a few small things only
[01:24] <veebers> wallyworld: awesome, I'll get them sorted posthaste
[01:25] <wallyworld> let me know if anything is unclear
[01:39] <thumper> babbageclunk: got a few minutes?
[01:41] <wallyworld> babbageclunk: are you looking at thumper's comments?
[01:41] <babbageclunk> wallyworld: yup
[01:41] <babbageclunk> also thumper: yup
[01:42] <babbageclunk> thumper: in 1:1?
[01:42] <wallyworld> ok, i'll look at thumper's PR next
[01:42] <thumper> babbageclunk: ack
[01:43] <thumper> babbageclunk: waiting
[01:48] <veebers> wallyworld: re: the comments, er, comment. Is the expectation something like "RootKey implements bakery.Storage.RootKey" or more: "RootKey returns the rootkey found in the bakery storage, used for making new macaroons." (same for Get)
[01:48] <wallyworld> if the method comes from an interface we typically use the former
[01:49] <veebers> wallyworld: cool, does it make sense to have the package in there? (i.e. bakery.) or is <inteface>.<method> the done thing? (i.e. Storage.Get)
[01:50] <wallyworld> i think we mostly do not include the package name'
[02:01] <thumper> babbageclunk: not too big, just 900 lines or so
[02:02] <babbageclunk> thumper: hey you tricked me!
[02:11] <wallyworld> thumper: review done
[02:13] <thumper> wallyworld: awesome, thanks
[02:28] <babbageclunk> Is anyone else running the pre-push git hook?
[02:33] <veebers> wallyworld: can you clarify your comment "These need to operate on both the embedded suites"?
[02:33] <veebers> babbageclunk: oh, no I'm not but I should be. Its just a matter of symlinking something isn't it?
[02:35] <wallyworld> babbageclunk: i normally run it
[02:36] <wallyworld> veebers: if a suite embeds > 1 other suite, you need to call the SetUp/TearDown funcs on all the embedded suites or else only one will get run
[02:36] <wallyworld> the other embedded suites will not get setup/torndown
[02:38] <babbageclunk> veebers: yup - see here https://github.com/juju/juju/blob/master/CONTRIBUTING.md#local-clone
[02:38] <veebers> wallyworld: ah I see, I was only matching any setups with a teardown.
[02:39] <veebers> wallyworld: does that mean I need to add a loggingsuite setuptest too? (or are it's setupsuites enough
[02:39] <wallyworld> veebers: the embedded suites may not explicitly define a SetUp (for example) *today*, but if one were to be added....
[02:39] <wallyworld> if loggingsuite doesn't have one at all, then no needed
[02:40] <wallyworld> but if there's one by virute of an embedded suite in loggingsuite
[02:40] <veebers> wallyworld: loggingsuite has a setuptest, so I'll add it too
[02:40] <wallyworld> great, yup
[02:41] <wallyworld> and order of teardown should be opposite of setup
[02:41] <veebers> ack
[02:42] <veebers> wallyworld: does the same count for setup/teardown suite? (i.e. I have the looging one there, should I add the mgo)
[02:43] <wallyworld> any embedded suite that has a setup/teardown needs to have those called by the outer suite
[02:43] <wallyworld> otherwise go will be a single, arbitrary one to call and not call the others
[02:43] <wallyworld> s/be/pick
[02:44] <veebers> ah ok, gotcha
[02:44] <wallyworld> same even goes for if you add logic to the outer setup and there's only one embedded suite
[02:44] <wallyworld> still need to then call the embedded suite setup
[02:59] <babbageclunk> thumper: are you happy with https://github.com/juju/juju/pull/8571 or do you want wallyworld to look at it too?
[03:00] <veebers> wallyworld: re: the macaroon.New wrapper, would the function be New or NewMacaroon() to be clearer?
[03:01] <wallyworld> veebers: NewMacaroon works i think as it will be in a testing package
[03:02] <veebers> sweet, makes sense
[04:02] <thumper> babbageclunk: all good
[04:02] <babbageclunk> thumper: cool, thanks!
[04:03] <thumper> jam: in our 1:1
[04:03] <veebers> wallyworld: FYI have pushed pr review changes. Also I had a go at getting a failure when using a charm with resources, but couldn't. It's possible I don't fully understand the process required.
[04:03] <jam> thumper: omw
[04:04] <veebers> I published a charm to the store, I've deployed it (it got me to auth), I upgraded the controller +  model to the 2.4-b1 and attached a new resource to teh application but it all worked
[04:05] <veebers> ah man, failling tests. I should have caught that locally :-\
[04:06] <veebers> ah, I see why.
[04:08] <veebers> babbageclunk: is there a nice way to "go test" but just build the test not run them (i.e. so I can catch compile errors)
[04:09] <babbageclunk> veebers: go test -c
[04:09] <babbageclunk> But I haven't really worked out a nice way to do that across all packages.
[04:09] <veebers> babbageclunk: cool thanks. Huh that succeeds, but there are errors to be found :0\
[04:10] <veebers> ah, just in juju/juju won't do much will it
[04:10] <babbageclunk> It only builds the tests for the package you're in.
[04:10] <veebers> aye :-)
[05:26] <kelvinliu> sorry, got a quesiton about current supported golang version, `make install-dependencies` will install golang-1.10 from snap but README.md shows it should be 1.9.  I am currently on `develop` branch
[05:26] <kelvinliu> seems README needs to be updated.
[05:26] <thumper> kelvinliu: yes
[05:26] <wallyworld> it was 1.9 until recently
[05:27] <kelvinliu> thx :)
[05:27] <wallyworld> we should tell folks just to use Go from the snap
[05:28] <kelvinliu> yes, snap is handy rather than installing manually
[05:28] <wallyworld> it is, and it's easy to try rc of next go version etc
[05:28] <wallyworld> so we can be sure juju will continue to work when next version is out
[05:29] <kelvinliu> yes, agreed
[05:29] <kelvinliu> wondering if I wanna update the README, how  do we manage branchs?
[05:30] <wallyworld> sure, feel free to propose a change. vino had the same thought but i've given her a bug to work on so you could look at a readme change
[05:32] <babbageclunk> jam: ping?
[05:38] <thumper> night all
[05:38]  * thumper goes to make dinner and have a glass of wine
[05:39] <kelvinliu> yup thx
[05:40] <kelvinliu> night thumper
[05:40] <babbageclunk> kelvinliu: he never waits for responses. I was going to say it too. :(
[05:46] <kelvinliu> haha
[06:28] <anastasiamac> a very quick and easy review plz: https://github.com/juju/juju/pull/8584
[06:58] <wallyworld> anastasiamac: looking
[06:59] <anastasiamac> wallyworld: thnx
[06:59] <wallyworld> anastasiamac: nice
[07:00] <anastasiamac> m thinking it should mayb (!) say 'odel cannot be upgraded to x.x.x while the controller is y.y.y: upgrade 'controller' model first'...
[07:00] <anastasiamac> does it read better to u^^
[07:01] <anastasiamac> wallyworld: ^^
[07:01] <wallyworld> sure, sounds good to me
[07:01] <anastasiamac> \o/
[07:01] <anastasiamac> i'll re-phrase in a sec... m just a breath (or a few) away from proposign worker/maniforld for cred check...
[07:02] <wallyworld> jam: i had to make a fix to a recent juju/description commit which added some stuff for caas support, any chance of a review before you EOD? i need this to be able to add support for model import/export in juju itself https://github.com/juju/description/pull/37
[07:27] <vino_> hi kelvin
[07:33] <kelvinliu> hi vino
[07:34] <vino_> hi.. did u manage to get details abt branches ? i closed freenode.
[07:38] <kelvinliu> yes, https://github.com/juju/juju/blob/develop/CONTRIBUTING.md
[07:39] <kelvinliu> just have a check CONTRIBUTING.md
[07:41] <wallyworld> jam: thanks for review, i responded to comments if you are interested. i'll test with model export in juju before landing
[07:44] <wallyworld> kelvinliu: i left a comment - let's change the readme to tell people ot use the snap
[07:45] <kelvinliu> yes, go point, I m updating it now
[07:54] <vino_> snap install of go ?
[07:56] <kelvinliu> yes
[07:57] <vino_> i had issue installing snap version by default installed 1.6 and that had issues with juju installation
[08:01] <wallyworld> kelvinliu: lgtm
[08:01] <wallyworld> vino_: it should have installed the latest stable go release, not sure why it installed 1.6
[08:02] <wallyworld> juju won't compile with go < 1.10
[08:02] <vino_> yes. in 16.04
[08:03] <wallyworld> hmm, no idea why off hand. i'm running bionic
[08:04] <kelvinliu> i am running bionic as well
[08:04] <kelvinliu> `make install-dependencies` will install all for u, vino
[08:04] <vino_> so i tried upgrading it to 1.10 and eventually it allowed me to do it only with longsleep/golang-backports
[08:05] <vino_> maybe i can recheck
[08:05] <vino_> https://bugs.launchpad.net/juju/+bug/1763201
[08:05] <mup> Bug #1763201: Build juju from source documentation requires update <usability> <juju:Triaged> <https://launchpad.net/bugs/1763201>
[08:05] <wallyworld> vino_: you sure you used the snap?
[08:05] <wallyworld> rather than the one from the archive?
[08:05] <wallyworld> i'd expect 1.6 to be in the archive
[08:05] <vino_> i did. but i can recheck again.
[08:06] <wallyworld> the reference to backports implies archive
[08:14] <vino_> i rechecked and snap installs 1.10 - i was wrong here.
[08:15] <vino_> wallyworld : i reachecked and i couldnt reproduce how i got 1.62 where i faced issues to upgrade and referred to link :  https://github.com/golang/go/wiki/Ubuntu
[08:17] <wallyworld> no worries. we should update that wiki page to refer to snap also
[08:18] <vino_> It already does.
[08:18] <vino_> https://github.com/juju/juju/blob/develop/README.md
[08:18] <vino_> snap also or snap only ?
[08:21] <wallyworld> vino_: i meant this one https://github.com/golang/go/wiki/Ubuntu
[08:22] <wallyworld> oh never mind
[08:22] <wallyworld> i didn't scroll down far enough
[08:22] <wallyworld> it already mentions snaps
[08:22] <vino_> I am not clear.
[08:22] <vino_> apologise
[08:23] <vino_> did u mean that juju README.md should also mention snap ?
[08:23] <wallyworld> for the juju readme, IMO it should be snap ony
[08:23] <wallyworld> since people on xenial etc would otherwise get an older version of go that won't ork with juju
[08:23] <vino_> ok snap only is correct. apt install info can be removed
[08:23] <vino_> ok.
[08:24] <wallyworld> yeah i think so
[08:41] <anastasiamac> wallyworld: if u plan more insomnia or r just looking for bedtime reading, PTAL https://github.com/juju/juju/pull/8586 - cred worker/manifold... :D
[08:42] <wallyworld> ok, will try and get to it after i finish this current PR
[08:42] <anastasiamac> wallyworld: was kind of hoping u'd look at it at the earliest tomorrow :)
[08:42] <wallyworld> can do
[08:52] <vino_> wallyworld : i will update the bug i opened this morning https://bugs.launchpad.net/juju/+bug/1763201
[08:52] <mup> Bug #1763201: Build juju from source documentation requires update <usability> <juju:Triaged> <https://launchpad.net/bugs/1763201>
[08:53] <vino_> but just to update : both snap and apt-get install go install 1.10 and works fine for me to build juju and installing.
[08:54] <vino_> i will detail in the bug report
[08:57] <vino_> snap install go --classic is fine
[08:58] <vino_> only the next option needs to be updated with - sudo apt-get install golang-go
[09:02] <vino_> hi Kelvin.. Can i assign that bug to you  as you are updating it ?
[09:36] <kelvinliu> sure, just give it to me. I v already got a PR for it.  Vino
[09:47] <vino_> i just saw that.
[09:47] <vino_> i felt u can add apt-get as it works fine for me
[09:48] <vino_> it installs latest go version.
[09:49] <vino_> i have assigned it to u
[09:52] <vino_> get u get mail notification kelvin ?
[10:00] <vino_> https://bugs.launchpad.net/juju/+bug/1763201
[10:01] <mup> Bug #1763201: Build juju from source documentation requires update <usability> <juju:Triaged by kelvinliu1976> <https://launchpad.net/bugs/1763201>
[10:35] <jam> manadart: if its possible while you're in the area, bug #1753418 is one reason why our ci run isn't clear.
[10:35] <mup> Bug #1753418: intermittent failure in kvmProvisionerSuite.TestKVMProvisionerObservesConfigChanges <intermittent-failure> <test-failure> <juju:Triaged> <https://launchpad.net/bugs/1753418>
[10:36] <manadart> jam: Yep. Will take a look.
[10:36] <jam> manadart: lower priority than finishing the work, but since you're working with KVM right now
[13:47] <balloons> externalreality, are you ok with doing the change for the runtime panics on that bug to start?
[13:47] <balloons> externalreality, I'll look quickly for ovh account
[14:55] <externalreality> ballons, sounds good, will do.
[18:13] <hml> balloons: subprocess.check_output is working… but have to change a lot of things over to use it…
[18:13] <hml> unhappy it’s not clear why yet
[18:18] <balloons> OK, so you are unblocked?
[18:40] <hml> balloons: currently -
[20:17] <thumper> morning team
[20:19] <rick_h_> thumper: morning and +1000 on the collapse of the juju vs -dev list/channels
[20:19] <rick_h_> in case you were looking for votes. I've been saving up my paper ballots :P
[20:19] <thumper> balloons: where are we with 1.25.14 build needs - go/1.8 etc
[20:20] <thumper> rick_h_: heh, ack
[20:20] <balloons> good morning thumper
[20:24] <thumper> also status for 2.3.6?
[20:25] <thumper> since we are co-opting the release call for whole team meeting :)
[20:25] <balloons> thumper, yea.. We have 3 releases we need to do. 1.25, 2.3, and 2.4
[20:25] <thumper> yeah
[20:25] <thumper> 2.3.6 first, then 2.4 then 1.25
[20:26] <balloons> thumper, 2.3.6 has to have a call on if we wait for the container-image-metadata or not
[20:26] <thumper> we've waited long enough for the 1.25 build, another week or two won't kill them
[20:26] <thumper> I don't think we need to wait
[20:26] <thumper> I'm happy enough that going into 2.4
[20:26] <thumper> field are working around the issue now
[20:26] <thumper> it isn't critical
[20:26] <thumper> 2.3.6 is
[20:26] <balloons> this needs to land then, and we should be good https://github.com/juju/juju/pull/8589
[20:27] <thumper> balloons: is mongo 3.6 in bionic yet?
[20:27] <balloons> thumper, it went into the queue a few hours ago. Needs approval, then it will land in proposed
[20:29]  * thumper nods
[20:29]  * thumper jumps in call 1 of 3
[20:35] <veebers> Morning all o/
[20:38]  * balloons tips hat
[21:31] <wallyworld> kelvinliu: if you're online, come to team meeting?
[21:40] <babbageclunk> morning everyone
[21:58] <hml> veebers: if you would, i updated the pr from yesterday with the change
[21:59] <veebers> hml: mean, you have a link?
[21:59] <veebers> hah I have a Link, I hear him crying right now :-P
[21:59] <hml> veebers: https://github.com/juju/juju/pull/8582
[22:09] <hml> feeling paranoid - i manually did the upgrade series setups on a 2.3.6 config - then did juju upgrade-juju to get to 2.4-beta1 and the unit was still happy.  :-)
[22:13] <veebers> hml: what's the difference to what the script used to be doing (with the .tmp that's different to using --output-file) don't both write a 'tmp' file and then mv it in place at the last second?
[22:14] <hml> veebers: there are shades of “last second”
[22:15] <hml> veebers: i could have just removed the os.rename and done the mv after ifdown
[22:15] <hml> veebers: but since we can specify the input file, it’s “nicer” to specify an output file too?
[22:16] <veebers> hml: perhaps I don't fully understand the script . . . ah I see, right *that's* the important part here, not moving the interfaces file to bak before it's time
[22:16] <veebers> I was focusing on the wrong part :-)
[22:17] <hml> veebers: i changed so it was a copy to .bak - then the replacement was done very last we could
[22:17] <veebers> hml: ack, that makes sense and obvious now that I see it
[22:18] <veebers> hml: LGTM
[22:18] <hml> veebers: TY!  :-)
[22:22] <veebers> thumper: Seems it's really easy to add gometalinter to emacs (using spacemacs too): https://github.com/syl20bnr/spacemacs/tree/master/layers/%2Blang/go#pre-requisites
[22:23] <babbageclunk> veebers: Also really CPU hungry
[22:24] <babbageclunk> (Probably because of the size of the codebase)
[22:25] <veebers> babbageclunk: ah right, I'm not so keen to add more CPU load to my emacs usage ^_^
[22:28] <vino> C, c++
[22:28] <vino> and python scripting
[22:29] <vino> in cloud i used JAVA RestApi
[22:29] <veebers> vino: might be wrong channel :-)
[22:30] <vino> yes yes.
[22:30] <veebers> vino, kelvinliu: Where you making changes to CONTRIBUTING.md? I think I want to make some updates too
[22:30] <vino> i am still sleepy
[22:31] <veebers> ^_^
[22:31] <vino> i already generated a PR
[22:31] <vino> in the Local Clone section.
[22:31] <veebers> Is master even a branch we really care about now? I think CONTRIBUTING.md should mention develop, not master.
[22:32] <vino> https://github.com/juju/juju/pull/8588
[22:32] <veebers> vino: lol that's exactly the change I was going to make
[22:33] <vino> Oh sorry.
[22:33] <vino> i missed something and Kelvin did it yesterday in README>md
[22:33] <veebers> vino: hah no it's good, you got to it first.
[22:33] <vino> the go version
[22:34] <veebers> vino: note, there is a typo in the PR typo, it's a little long too (will be truncated in the git log)
[22:38] <vino> done.
[22:38] <vino> corrected it
[22:40] <veebers> vino: you'll need to update the summary part too, it still has "…ection with correct path" as the first line
[22:41] <vino> good eyes.
[22:46] <hml> has anyone tried to bootstrap from a mac recently?  (i’m using a remote openstack cloud)
[22:48] <wallyworld> babbageclunk: i might be a minute late for standup, so tell some jokes if i'm not there on time :-)
[22:48] <babbageclunk> wallyworld: I'll do my best man, but if the audience are expecting you they'll still be disappointed
[22:57] <hml> how do you build agents for a different processor?  trying to bootstrap 2.4-beta1 (develop) it complains about not having agent binaries, even if they are built during bootstrap.  Wrong OS?  and the 2.4beta1 binaries are not online yet
[23:03] <babbageclunk> veebers: review plz? https://github.com/juju/juju/pull/8590
[23:04] <veebers> babbageclunk: sure thing!
[23:04] <babbageclunk> hml: Don't know, sorry! anastasiamac/balloons/thumper?
[23:05] <babbageclunk> veebers: fanks
[23:05] <hml> i was able to bootstrap with 2.3.5 at least?
[23:07] <babbageclunk> I think once you have a controller you could build the binaries for the different arch and then use sync-tools to push them up, then upgrade?
[23:08] <hml> hrm
[23:08] <hml> get juju to build the binaries?
[23:09] <hml> babbageclunk: how would you get the controller to build the binaries?
[23:10] <babbageclunk> no, build them locally - I think by setting GOOS and GOARCH?
[23:11] <babbageclunk> hml: Something like this https://dave.cheney.net/2015/08/22/cross-compilation-with-go-1-5
[23:11] <hml> haven’t played with those before
[23:11] <veebers> babbageclunk: "Thanks ants, Thants". lgtm
[23:12] <babbageclunk> veebers: Just... look around you!
[23:12] <veebers> hml: with 2.3.5 it would have pulled agent from streams, for 2.4-b1 you'll need to use the testing streams to do that
[23:12] <veebers> babbageclunk: ^_^ that's the one
[23:12] <hml> veebers: there’s a testing streams?
[23:13] <veebers> hml: for each build we generate a stream entry and put it in s3.
[23:13] <hml> veebers: though that won’t allow me to test my code easily?
[23:13] <hml> veebers: how do you use it?
[23:14] <veebers> hml: not if you're needing an agent you've just built :-\
[23:14] <hml> veebers: sounds like i need to learn to use GOOS and GOARCH?
[23:15] <hml> veebers: i was just courious
[23:31] <veebers> hml: if you have a log of the upgrade series test too that would be useful
[23:38] <hml> veebers: not sure if the logs i have now are useful?
[23:38] <hml> veebers: i know where they are failing now…
[23:38] <hml> veebers: if i find a new one, i’ll forward along :-)
[23:39] <veebers> hml: sweet :-)
[23:40] <hml> veebers: eventually i’d be curious as to what broke which lead me to using subprocess.check_output to run remote commands
[23:40] <hml> some juju some not
[23:40] <hml> veebers: it’s not warm fuzzy that this is needed
[23:40] <hml> but i want it done too :-)
[23:41]  * hml waves goodnight!
[23:41] <veebers> o/
[23:53] <babbageclunk> bye hml