[00:00] <ericsnow> anyone know if we are going to drop the legacy HTTP endpoints for 2.0?
[00:00] <ericsnow> see https://github.com/juju/juju/blob/master/apiserver/apiserver.go#L432
[00:09] <davecheney> perrito666: thanks, fingers crossed this time
[00:09] <perrito666> axw: quick question about cloud credentials schema, have a sec?
[00:10] <axw> perrito666: in 1:1, sorry
[00:10] <perrito666> no worrries
[00:51] <axw> perrito666: had to do school drop off, I'm back now if you're still around
[00:52] <perrito666> axw: solved it :)
[00:52] <perrito666> tx anyway
[00:52] <axw> perrito666: glad to be of service ;)
[00:52] <perrito666> autoload-credentials was ignoring my ~/.novarc but it works with my env variables, will file a bug later
[01:19] <wallyworld> perrito666: i did test it with ~/.novarc
[01:19] <wallyworld> i wonder what went wrong
[01:20] <perrito666> wallyworld: perhaps my novarc lacks the expected format?
[01:20] <wallyworld> you sure the contents are correct?
[01:20] <wallyworld> it looks for the same things as env vars
[01:21] <perrito666> is a bash file full of exports
[01:21] <perrito666> odd
[01:21] <wallyworld> maybe be a problem, not sure
[01:21] <wallyworld> weill have to retest
[01:21] <wallyworld> axw: i'm about to propose the interactive add-credentials with the CredentialSchema ordering fix. but i'm wondering if the password entry should echo * as characters are typed or pasted
[01:21] <perrito666> wallyworld: are you sure your env was clean when you tested?
[01:22] <wallyworld> prtetty sure
[01:22] <wallyworld> i'll have a look ina bit
[01:22]  * perrito666 finally gets a k3 bootstrap
[01:22] <perrito666> with magic auth_url auto discovery :)
[01:22] <wallyworld> yay
[01:23] <axw> wallyworld: no, I don't think so. knowing the length of the password isn't great
[01:23] <axw> wallyworld: you're using readpass, right?
[01:23] <wallyworld> axw: yep
[01:23] <wallyworld> is just a personal preference
[01:23] <wallyworld> i want feedback that i'm typing something
[01:23] <axw> wallyworld: it's nice for visual feedback, but it is a security flaw
[01:24] <wallyworld> a small one
[01:24] <wallyworld> hard to count * :-)
[01:24] <axw> wallyworld: not if it's a short password
[01:24] <wallyworld> and who uses short passwords?
[01:24] <wallyworld> surely everyone uses a pw manager
[01:24] <axw> wallyworld: lol :)
[01:24] <wallyworld> if not they deserve wgat they get
[01:25] <wallyworld> (half joking)
[01:37] <mup> Bug #1558333 opened: juju's logging the literal "$cmd" instead of value of $cmd <juju-log> <logging> <juju-core:New> <https://launchpad.net/bugs/1558333>
[01:45] <wallyworld> perrito666: the issue with .novarc is that juju doesn't strip the export bit. my tests didn't have that
[01:45] <perrito666> so the export bit is not valid? it sure seems
[01:46] <wallyworld> the export bit should be supported by juju
[01:46] <anastasiamac_> axw: since u r OCR, could u PTAL http://reviews.vapour.ws/r/4193/
[01:46] <wallyworld> ie juju should strip it out
[01:46] <anastasiamac_> axw: it's a critical for 1.25
[01:46] <axw> anastasiamac_: sure, looking
[01:46] <anastasiamac_> axw: thanks :D
[01:47] <perrito666> wallyworld: cant yout source the file into an env and read the env? sounds like you could save a lot of future pains with that
[01:47] <axw> anastasiamac_: were there any changes to the changes required?
[01:48] <wallyworld> perrito666: sourcing the file is a shellism
[01:48] <axw> anastasiamac_: (i.e. did you just cherry pick without having to modify?)
[01:48] <anastasiamac_> axw: ? no cherry-pick was not possible
[01:48] <axw> anastasiamac_: I see, you said re-work
[01:48] <axw> nps
[01:48] <anastasiamac_> axw: the commits have other stuff in them like lxd for eg..
[01:48] <wallyworld> perrito666: i was hoping to avoid execing shell command
[01:49] <axw> right, of course
[01:49] <anastasiamac_> axw: however, the related code is exactly as onmaster
[01:49] <axw> anastasiamac_: okey dokey
[01:49] <anastasiamac_> axw: except for renaming model stuff :P
[01:50] <perrito666> wallyworld: I would expect to be a way to wrap that into go by running a child env and do whatever that env supports as source (but then again, I am guessing, a lot)
[01:50] <wallyworld> i didn't see an obvious way, maybe there is
[01:51] <wallyworld> it's easy enough to tweaks what there already to work
[01:54] <axw> anastasiamac_: LGTM, thanks
[01:54] <anastasiamac_> axw: \o/
[01:58] <perrito666> wallyworld: axw credentials schema fields cannot be made optionals?
[01:59] <wallyworld> perrito666: they can as of recently
[01:59] <perrito666> wallyworld: is that on master?
[01:59] <wallyworld> Optional: true
[01:59] <wallyworld> yes
[01:59] <wallyworld> perrito666: i did it just for you
[02:00] <wallyworld> to support keystone 3
[02:00] <perrito666> you are wonderful, pint me to plz?
[02:00] <wallyworld> EPARSEERROR
[02:01] <wallyworld> if you grab master tip, you can use Optiona: true in credential schema
[02:01] <perrito666> grrrreat
[02:19] <wallyworld> axw: fyi, ignore the charm-minvers feature branch pr, that's s merge into master i'm landing now
[02:19] <axw> wallyworld: ok, thanks
[02:25] <perrito666> k I have it working and almost fixed the joyous openstack live tests to reflect that, my brain is out of order for the day, see you all tomorrow
[02:26] <perrito666> wallyworld: axw anastasiamac_ I would love  a review of https://github.com/go-goose/goose/pull/19 during the night
[02:26] <perrito666> cheers
[02:26] <wallyworld> our night or yours?
[02:27] <axw> perrito666: will see how I go, got lots to review today
[02:27] <wallyworld> i can look
[02:27] <anastasiamac_> perrito666: nite \o/
[02:28] <perrito666> wallyworld: yours I need to et all this merged tomorrow
[02:28] <perrito666> no sorry mine
[02:28] <perrito666> mybrain is dead
[02:28] <wallyworld> perrito666: i was being facecious :-)
[02:29] <wallyworld> i knew what you meant :-)
[03:38] <natefinch> axw: can I get one more quick review on the stringmap thing?  realized I was missing handling an error case: https://github.com/juju/cmd/pull/32
[03:40] <axw> natefinch: looking
[03:40] <natefinch> axw: thanks
[03:41] <axw> natefinch: done
[03:42] <natefinch> axw: thanks!
[04:05] <natefinch> and now to figure out how to finagle these full stack tests to succeed when the server doesn't actually support this endpoint...
[04:23] <davecheney>   /win12
[04:30] <menn0> axw: this is pretty horrible but necessary: https://github.com/juju/juju/pull/4766 PTAL
[04:31]  * axw braces
[04:33] <natefinch> menn0: is there a bug filed for that on go-yaml?
[04:34] <menn0> natefinch: not yet, but I've just created a card for myself on our board to do that
[04:34] <anastasiamac_> menn0: is it worthwhile back porting to 1.25... I think that the bug would be awesome too \o/
[04:34] <natefinch> anastasiamac_: are we supporting go 1.6 for 1.25?
[04:35] <mup> Bug # changed: 1499781, 1504578, 1526926, 1529126
[04:35] <menn0> natefinch: it's an involved bug report to write up so I'll do it next week
[04:35] <menn0> anastasiamac_: the code that was relying on private embedded types only exists in Juju 2.0
[04:35] <menn0> anastasiamac_: we'd know about it if we were relying on this elsewhere
[04:35] <anastasiamac_> menn0: then no need for 1.25 :D
[04:36]  * menn0 has lost hours on this
[04:36] <axw> menn0: what's the deal with all the trailing underscores?
[04:36] <anastasiamac_> menn0: but for reference, I can see CI tests that run against 1.25 with go 1.6
[04:36] <natefinch> axw: they give you a place to rest your mouse when your arm gets tired
[04:37] <axw> nani
[04:37] <menn0> axw: Tim came up with that as a way to avoid collisions between field names and the method names he wanted to use
[04:37] <anastasiamac_> natefinch: such small mouse tho :D
[04:37] <axw> menn0: ah, right, ok
[04:38] <menn0> axw: i've continued with the trend
[04:39] <axw> menn0: reviewed
[04:39] <menn0> axw: thanks
[04:40] <menn0> axw: I clearly didn't re-run the tests after removing that debugging Dump method :)
[04:40] <axw> :)
[05:59] <jam> axw: davecheney: I pushed a small update because of a case I found in Juju (we were calling AddCleanup during SetUpSuite()), can you give it one more quick look?
[06:02] <axw> jam: LGTM. there's a bug somewhere (I think rogpeppe filed it) suggesting that we should just have AddCleanup, and DTRT whether we're in SetUpSuite or in/after SetUpTest
[06:02] <axw> jam: probably need to change tests to do that tho
[06:02] <jam> axw: I could do that here, with just checking if s.testSuite is nil
[06:03] <jam> axw: does that sound sane?
[06:03] <axw> jam: yeah, I'm just not sure if anything is relying on current behaviour
[06:03] <jam> axw: if it is, its broken
[06:03] <jam> assuming AddCleanup during a Suite level operation will be cleaned up after the first test run...
[06:03] <jam> we could keep AddSuiteCleanup as an explicit thing
[06:04] <jam> but calling it in a Test context and assuming it will last the rest of the Suite is also broken behavior
[06:04] <jam> One test should not set global state for another test to expect
[06:04] <jam> axw: then again, if the Juju test suite *does* have those bugs, I don't know how many I can fix :)
[06:04] <axw> jam: indeed :)
[06:05] <axw> jam: I'd be happy to drop AddSuiteCleanup and have AddCleanup add suite-level things when called in SetUpSuite, and test-level things otherwise
[06:05] <axw> it's just a sed command to rename AddSuiteCleanup to AddCleanup after that
[06:06] <axw> jam: if you want to defer removing/renaming, that's fine though. we can do that later
[06:06] <jam> axw: trying to think how to write the tests for it.
[06:06] <jam> I think making it safe and easy to use is best
[06:07] <jam> so users don't have to think "Can I call it now"?
[06:07] <jam> (heirarchy of good API, "make the obvious thing correct" vs "make the wrong thing hard to do"
[06:07] <jam> )
[06:07] <jam> axw: it also leads to helpers like PatchValue where you can't control whether it is Suite level or Test level.
[06:07] <axw> jam: just read your latest email; the bug I was thinking of was actually about PatchValue. same sort of deal though
[06:08] <jam> axw: yeah, the fact that BaseSuite itself had this bug
[06:08] <jam> means we can *easily* have lots of tests that are actually doing Outbound tests
[06:08] <axw> :\
[06:08] <jam> and we didn't notice because we thought we were protected by BaseSUite
[06:18] <axw> wallyworld: we're still using CompatSalt in cloudconfig/instancecfg, and I don't think there's any reason to. The hash is a temporary, derived password - we shouldn't need to use a fixed salt
[06:19] <wallyworld> axw: yeah, i figured that change was a separate pr
[06:19] <axw> wallyworld: ok
[06:42] <jam> axw: can you look at the pull?
[06:42] <jam> http://github.com/juju/testing/pull/92
[06:42] <axw> jam: looking
[06:42] <jam> thx
[06:42] <jam> or davecheney^^
[06:44] <jam> axw: interestingly "home_test" was a case where we were setting up another test suite, and calling SetUpTest but not SetUpSuite
[06:50] <axw> jam: LGTM, thanks. there's a couple of odd SetUpTest calls in home_test, but just style issues really
[06:50] <axw> and preexisting at that
[06:51] <jam> home_test is trying to test the test itself by creating another test object.
[06:51] <jam> but it is calling SetUpTest without ever calling SetUpSuite
[06:51] <axw> jam: ah, I see.
[06:51] <jam> and we're now at... a whole lot of failures in Juju proper...
[06:51] <axw> :/
[06:52] <jam> FakeHomeSuite is doing something bad.
[06:52] <axw> jam: because they were swept under the rug?
[06:52] <jam> lots of tests use it
[06:52] <axw> lots of outbound connections? :)
[06:52] <axw> oh home suite
[06:53] <jam> investigating, because I don't see anything bad yet
[06:53] <jam> FakeJujuXDGDataHomeSuite calls SetUpTest during TearDownSuite ?
[06:54] <jam> axw: testing/environ.go line 107
[06:54] <jam> why is TearDownSuite calling Suite.SetUpTest() ?
[06:55] <jam> I think that's just a copy&paste typo
[06:55] <axw> jam: heh, yep, I'd say so
[06:56] <axw> jam: since 2014 :)
[06:56] <jam> axw: love it when our base infrastructure has some weird bugs in it.
[06:57] <jam> axw: SetUpSuite is *also* calling SetUpTest instead of SetUpSuite
[06:58] <axw> lol
[06:58] <jam> and JujuOSSuite doesn't implement either SetUpSuite or TearDownSuite, so we don't need to write our own anymay
[06:58] <jam> anyway
[06:59] <jam> axw: or is it better to have one and just a line that says "this other one doesn't need to be called cause it doesn't exist" ?
[07:00] <axw> jam: I've not found one way or the other to be much better
[07:00] <axw> leaving it out is probably OK
[07:00] <axw> jam: I'd love to write a static analyser one of these days to check that they're all wired up correctly
[07:00] <jam> axw: yeah, the main problem is that once someone does introduce a SetUpSuite then we should call it, but neither way is going to catch that on its own
[07:01]  * axw nods
[07:19] <jam> so it looks like we do have at least 1 failure in Provisioning suite
[07:19] <jam> where it is actually reading cloud-images somehow
[07:21] <jam> though it is failing in the opposite way I was expecting
[07:22] <jam> maybe FakeXDGHome was accidentally making it harder to get outside access by calling SetUpTest all the time?
[07:32] <wallyworld> axw: i'm off to soccer soonish, i've reposnded to some of the comments on the add credentials review. i'll finish the interactive prompt for replace when i get back
[07:33] <axw> wallyworld: thanks, I'm just responding now
[07:33] <axw> enjoy
[07:33] <wallyworld> leaving in 20 minutes r so
[07:33] <wallyworld> will do
[07:34] <jam> axw: ugh. we have test suites that want to call PatchValue before they call their Base type's SetUpTest because SetUp does work that they want to patch out
[07:36] <axw> jam: ugh indeed
[07:36] <axw> jam: example?
[07:36] <jam> provider/lxd/
[07:37] <jam> testing_test.go
[07:37] <jam> there is a BaseSuiteUnpatched and a BaseSuite
[07:37] <jam> and BaseSuite embeds BaseSuiteUnpatched which embeds IsolationSuite
[07:37] <jam> so BaseSuite patches an object, then calls BaseSuiteUnpatched.SetUp
[07:38] <jam> line 277
[07:38] <jam> axw: ^^
[07:39] <jam> provider/joyent/joyent_test.go calls envtesting.PatchAttemptStrategies() before calling base .SetUpSiet()
[07:39] <jam> SetUpSuite()
[07:39] <axw> jam: yup. I think in the lxd case it could be moved to BaseSuite.SetUpSuite
[07:40] <axw> jam: that one's a bit different, it's not involving the suite
[07:40] <jam> axw: provider/joyent/local_test.go line 155
[07:40] <jam> calls PatchValue for 2 things before calling providerSuite.SetUpSuite()
[07:42] <axw> jam: AFAICT, it doesn't need to
[07:42] <jam> that also looks like it was honestly broken because the lifetime of that PatchValue should be wrong
[07:42]  * axw digs
[07:42] <axw> true
[07:42] <jam> my "go test ./...." is 5000 lines with this change to AddCleanup...
[07:44] <axw> jam: yeah, those 2 patches can come after SetUpSuite
[07:44] <axw> jam: 5000 lines? huh?
[07:45] <jam> panic tends to create a fair bit of traceback
[07:45] <jam> and SetUp failures fail on all the associated tests
[07:45] <jam> so it is bigger than probably it seems
[07:45] <jam> but its a fair bit to dig through
[07:47] <jam> axw: provider/joyent/local_test.go adds a *AddSuiteCleanup* that patches the attempt strategies to ShortAttempt
[07:47] <jam> I don't see it patch them to something longer first.
[07:48] <jam> my rabbit hole has gotten too deep, I think
[07:48] <axw> :)
[07:49] <axw> jam: probably just cruft, but I don't know for sure
[07:50] <jam> axw: I *did* finally hit tests that are going to cloud-images
[07:50] <jam> and failing now because they can't
[07:50] <jam> localLiveSuite.TestStartStop for provider/ec2
[07:51] <jam> "signature made by unknown entity"
[07:52] <axw> jam: yep, SetUpSuite calls PatchOfficialDataSources which calls PatchValue
[07:53]  * axw has to go feed children
[07:54] <jam> axw: have a good evening
[07:55] <jam> need to get out a swear jar...
[08:57]  * frobware wakes up to find maas-spaces2 has merged. \o/
[09:31] <frobware> dimitern: about to push your branch as upstream/maas-spaces-multi-nic-containers
[09:33] <dimitern> frobware, great! and I've seen maas-spaces2 get merged! cheers
[09:33] <frobware> dimitern: if we don't do lxc then CI tests will fail. How do we not do this for the moment is not clear (to me at least).
[09:34] <dimitern> frobware, well lxc-broker is still there, so ..
[09:35] <frobware> dimitern: we need to bung this branch (@ 07693b816c207bc6e3fa9d7dd3f76784a695908e) to the OS folks for testing...
[09:36] <frobware> dimitern, voidspace: upstream/maas-spaces-multi-nic-containers is now soliciting commits... :)
[09:38] <frobware> mgz, sinzui: please can we add upstream/maas-spaces-multi-nic-containers to the CI jobs (assuming something explicitly needs to be setup). thanks!
[09:40] <voidspace> frobware: cool
[09:40] <dimitern> frobware, I have some commits in mind to add :)
[09:41] <dimitern> voidspace, frobware, we should also delete maas-spaces2 from upstream soon
[09:45] <mgz> frobware: pushing it into the juju namespace is all that's needed
[09:46] <frobware> mgz: thanks
[09:47] <dimitern> frobware, about that fancycheck - it was temporary, now it can be dropped
[09:47] <dimitern> frobware, and we should do that before the CI run right?
[09:48] <frobware> dimitern: submit a PR, we can now review, commit in the usual way. ;)
[09:49] <dimitern> frobware, on it
[09:52] <voidspace> dimitern: frobware: is maas-spaces2 landing on master today then?
[09:52] <dimitern> voidspace, it already landed yesterday
[09:53] <voidspace> dimitern: hah, cool
[09:58] <TheMue> morning saphires o/ *yawn*
[09:58] <dimitern> TheMue, hey o/ morning
[10:00] <voidspace> TheMue: 0/
[10:01] <dimitern> voidspace, frobware, http://reviews.vapour.ws/r/4210/
[10:03] <natefinch>  team meeting anyone?
[10:04]  * TheMue currently not *lol*
[10:10] <voidspace> dimitern: frobware: I'm down to 11 failures on my branch (from 33 yesterday) - several of them about to be fixed by a change to gomaasapi
[10:11] <voidspace> (gomaasapi test server)
[10:13] <perrito666> morning all
[10:14] <perrito666> natefinch: is there anyone in the tm?
[10:15] <natefinch> perrito666:  a efw people
[10:16] <natefinch> perrito666: me, william, michael, and dimiter
[10:17] <frobware> dimitern, voidspace: sorry, was otp. Want to do a quick standup?
[10:17] <voidspace> frobware: in team meeting
[10:28] <fwereade> jam, I would love to help you with IsolationSuite horrors, but... probably not today
[10:29] <voidspace> dimitern: want to drop back in for standup?
[10:29] <dimitern> voidspace, sure
[10:30] <dimitern> voidspace, frobware, I'm the only one there though
[10:31] <voidspace> dimitern: we stayed in the team meeting room...
[10:31] <voidspace> dimitern: as we were there already
[10:31] <dimitern> ah
[10:31] <voidspace> hence "drop back in"
[10:56] <TheMue> Btw, Happy St Patricks Day
[11:20] <voidspace> down to 7 failures and deleted more code
[11:21] <voidspace> some unused production code some unused test helpers
[11:37] <jam> thanks fwereade. I'm going to try and get some more of my LXD stuff done, but I did make a bit more progress on the Isolation stuff. Its actually closer than I was worried it would be.
[12:41] <fwereade> before I go spelunking... can anyone suggest a foolproof way of inducing a StartSync on... whatever *state.State in the background is *actually* driving events for a hosted model running under a jujud test?
[12:42] <fwereade> jam, dimitern, axw, wallyworld perhaps? ^^
[12:42] <icey> juju's PPA needs to be updated, currently throwing warnings on Xenial due to https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1558331
[12:42] <mup> Bug #1558331: After upgrading to apt 1.2.7 in Xenial, PPAs and most other third-party repositories become unusable with "The repository is insufficiently signed by key  (weak digest)" <xenial> <apt (Ubuntu):Confirmed> <https://launchpad.net/bugs/1558331>
[12:42] <wallyworld> fwereade: isn't there a StartSync() method or something to trigger a sync?
[12:44] <fwereade> wallyworld, yeah... but you need to call it on the right *State
[12:44] <wallyworld> that is correct, it can be confusing
[12:44] <fwereade> wallyworld, we have access to .BackingState
[12:45] <fwereade> wallyworld, but I have a horrible feeling that the state that's backing the apiserver we talk to is hidden away in a statepool somewhere out of reach
[12:45] <wallyworld> i haven't looked at that stuff in ages. i do recall it being somewhat funky. i have not good answer for you
[12:45] <fwereade> wallyworld, (.BackingState is the one for the controller model, but it doesn't cause hosted models to get events
[12:45] <fwereade> )
[12:46] <fwereade> wallyworld, no worries, looks like I need to go hunting
[12:46] <wallyworld> yeah, sorry
[13:30] <alexisb> frobware, ping
[13:38] <natefinch> I am sad that juju controllers is not an alias for juju show-controllers
[13:38] <rick_h__> natefinch: list-controllers?
[13:38] <natefinch> ty
[13:39] <natefinch> it's show-controllers
[13:39] <natefinch> oh, I guess it's both
[13:39] <rick_h__> show-controller is against once controller?
[13:39] <rick_h__> it gives metadata for one, the other is the listing
[13:39] <natefinch> oh that is confusing
[13:40] <rick_h__> show-X is "give me details of one" and list- "give me a table of them"
[13:40] <frobware> alexisb: pong
[13:40] <alexisb> heya frobware see private chat
[13:40] <natefinch> rick_h__: but then why is there a show-controllers (note plural)?
[13:40] <rick_h__> natefinch: not sure on that one
[13:41] <alexisb> natefinch, it may be that the alias still exists on that one
[13:41] <alexisb> I owuld have to go look
[13:41] <natefinch> rick_h__: looks like you can pass in multiple controller names and it'll show you details for all
[13:41] <alexisb> at first we were doing both the single and plural case for everything
[13:41] <natefinch> s/all/each
[13:42] <natefinch> if you pass in 0 controller names, it shows you details for just the current
[13:42] <natefinch> show vs. list is very confusing IMO.
[13:42] <natefinch> but it looks like we have a lot of each
[13:43] <rick_h__> yes, it's one of the base principles of it. Very common across all nouns can be shown or listed
[14:13] <dimitern> frobware, voidspace, http://reviews.vapour.ws/r/4212/ fixes an issue found with multi-nic support
[14:18] <natefinch> I swear I am never ever ever going to get used to bootstrap having the name first
[14:18] <rick_h__> natefinch: don't get used to it, branch changing that lands soon hopefully
[14:18] <natefinch> rick_h__: oh thank goodness
[14:19] <rick_h__> natefinch: oh, sorry you mean the cli
[14:19] <rick_h__> that's not changing, though tyou meant the name of the first model
[14:19] <rick_h__> lol, in which case sorry
[14:19] <natefinch> aww!
[14:20] <natefinch> how come when I juju bootstrap mylocal lxd ... it creates a juju controller named local.mylocal?
[14:21] <rick_h__> the local is for multi-user situation. You might add controllers from other users that already have that name
[14:22] <natefinch> rick_h__: but if I don't... then you've just munged my namespace for no reason
[14:22] <rick_h__> natefinch: you should be able to leave it off and we can visit ways of streamlining
[14:22] <rick_h__> but had to design for the big case and work backwards
[14:30] <dimitern> voidspace, frobware, we should get it in to have a chance of a blessed ci run
[14:30] <dimitern> ^^
[14:30] <frobware> dimitern: looking now
[14:30] <dimitern> frobware, cheers
[14:48] <frobware> dimitern: reviewed
[14:48] <dimitern> frobware, thanks - updated, pushed, and set to merge
[14:48] <frobware> dimitern: did you see the ci results of the first one?
[14:49]  * natefinch needs to make an auto-dependencies.tsv merge tool
[14:49] <dimitern> frobware, yeah - as expected pretty much - the fancycheck
[14:49] <dimitern> frobware, and most of the other issues should be resolved by the last fix
[14:50] <dimitern> frobware, btw I managed to repro the empty mac address at setInstanceInfo for containers, looking into it
[14:50] <frobware> dimitern: I was in 2 minds about whether to push the branch this morning; I didn't think the CI run would happen that quickly given all the other feature branches that are being tested.
[14:50] <frobware> dimitern: oooh. And, btw, the reason the attach <pid> failed is I didn't start the remote end as root.
[14:50] <dimitern> frobware, they made some changes recently - there was a mail about it
[14:51] <dimitern> frobware, ah! :)
[14:51] <frobware> dimitern: what was the macaddr issue?
[14:51] <dimitern> frobware, I have a suspicion why it might be happening
[14:52] <frobware> dimitern: ok, going to ignore that and look at profiles again
[14:52] <dimitern> frobware, the MACAddress coming from PrepareContainerInterfaceInfo gets lost when trying to set the container devices in state
[14:52] <dimitern> frobware, +1
[15:03] <mup> Bug #1558608 opened: maas-spaces-multi-nic-containers cannot bootstrap <block-ci-testing> <juju-core:Incomplete> <juju-core maas-spaces-multi-nic-containers:Triaged> <https://launchpad.net/bugs/1558608>
[15:06] <mup> Bug #1558608 changed: maas-spaces-multi-nic-containers cannot bootstrap <block-ci-testing> <juju-core:Incomplete> <juju-core maas-spaces-multi-nic-containers:Triaged> <https://launchpad.net/bugs/1558608>
[15:15] <mup> Bug #1558608 opened: maas-spaces-multi-nic-containers cannot bootstrap <block-ci-testing> <juju-core:Incomplete> <juju-core maas-spaces-multi-nic-containers:In Progress by dimitern> <https://launchpad.net/bugs/1558608>
[15:15] <mup> Bug #1558612 opened: creating hosted model config: maas-agent-name is already set; this should not be set by hand <bootstrap> <ci> <maas-provider> <test-failure> <juju-core:Incomplete> <juju-core admin-controller-model:Triaged> <https://launchpad.net/bugs/1558612>
[15:45] <mup> Bug #1558608 changed: maas-spaces-multi-nic-containers cannot bootstrap <block-ci-testing> <juju-core:Invalid> <juju-core maas-spaces-multi-nic-containers:Fix Released by dimitern> <https://launchpad.net/bugs/1558608>
[16:15] <mup> Bug #1558087 changed: TestInvalidFileFormat fails on windows because of / <blocker> <ci> <regression> <test-failure> <windows> <juju-core:Fix Released by cmars> <juju-core model-acls:Fix Released by cmars> <https://launchpad.net/bugs/1558087>
[16:31] <dimitern> voidspace, btw I've found out the main reason why discoverspaces worker seems to make a lot of calls
[16:31] <dimitern> voidspace, it does call CreateSpaces and AddSubnets once for each space / subnet
[16:32] <dimitern> voidspace, I'm testing a patch now which takes advantage of the bulk nature of both api methods, so calls each of them once per handleSubnets() call
[16:33] <dimitern> should make the discovery much quicker hopefully, and resolve some issues where subnets might be missing when trying to use them (e.g. for machine devices' addresses)
[16:38] <voidspace> frobware: that test passes"
[16:38] <voidspace> I meant !
[16:38] <voidspace> dimitern: I didn't know it seemed to make a lot of calls
[16:38] <voidspace> dimitern: but cool
[16:39] <voidspace> dimitern: I'm down to 1 failing test on drop-maas-1.8
[16:39] <dimitern> voidspace, great!
[16:42] <frobware> dimitern: is that "resolve some issues where subnets might be missing" at all related to the mac address we were looking at earlier? (surprised if so, but...)
[16:43] <dimitern> frobware, not clear yet
[16:43] <dimitern> frobware, I did discover an issue with that fix though
[16:43] <frobware> dimitern: from the is not alive?
[16:44] <frobware> dimitern: might want to make sure that bulk method is in 2.0 before getting too far
[16:44] <dimitern> frobware, because the machiner starts before discoverspaces, it will not set the subnetID for yet-undiscovered subnets
[16:44] <voidspace> dimitern: will the bulk calls take into account that discovery might have already run and some of the spaces / subnets might already exist? (but some might not)
[16:44] <dimitern> frobware, it's already bulk
[16:44] <dimitern> voidspace, it does I think - at least it works idempotently
[16:44] <voidspace> frobware: the bulk api calls are our code
[16:44] <frobware> voidspace: ok
[16:44] <voidspace> dimitern: there were some tests for that
[16:45] <mup> Bug #1558657 opened: many workers still don't use clocks <tech-debt> <juju-core:Triaged> <https://launchpad.net/bugs/1558657>
[16:45] <dimitern> voidspace, I didn't have to change the tests after changing CreateSpaces and AddSubnets calls to be done once in bulk
[16:45] <mup> Bug #1558668 opened: api_undertaker_test is not a feature test <tech-debt> <juju-core:Triaged> <https://launchpad.net/bugs/1558668>
[16:45] <dimitern> they still passed ok
[16:46] <dimitern> and a quick live tests showed the difference: in a few seconds the discovery was done (a lot less log spam around "caching subnets.." and also 2 vs 3 messages at bootstrap saying Spaces discovert still in progress)
[17:01] <dimitern> that wasn't enough apparently - the machiner manages to call SetObservedNetworkConfig a couple of seconds before spaces discovery completes :/
[17:01] <dimitern> so I'm thinking that we should block MA logins until discovery completes... testing this live now
[17:09] <fwereade> I'm pretty sure we shouldn't be blocking MA logins for anything, a huge amount of our functionality depends on it
[17:09] <fwereade> dimitern, ^^
[17:09] <fwereade> dimitern, I think this is another reason to set space-discovery-completed in state persistently
[17:10] <fwereade> dimitern, and expose getter/watcher for whatever things need to wait on it?
[17:10] <dimitern> fwereade, I know it shouldn't, I'm just trying to see if it might help as an experiment
[17:10] <voidspace> dimitern: hah, the repeated building of the subnet cache is still a bug in the cache code though right?
[17:10] <dimitern> fwereade, I agree it needs to be recored in state once done
[17:10] <fwereade> dimitern, fair enough
[17:11] <dimitern> voidspace, it is, but the cache was done with the assumption it will be used for bulk-style calls
[17:11] <voidspace> dimitern: so it's cache once per call by design
[17:11] <voidspace> dimitern: fwereade: yeah, I can't think of another reliable way other than storing in state when discovery is completed
[17:12] <voidspace> not an alternative that meets all the use cases we have (HA, multiple models etc)
[17:12] <dimitern> voidspace, fwereade, and we have another case already - the peergrouper needs to know the spaces discovery is done before deciding the common space all controllers are in
[17:13] <voidspace> dimitern: right
[17:14] <dimitern> voidspace, why did we decide not to block until the discovery has started? in case the worker does not start at all?
[17:14] <voidspace> dimitern: because it blocks access for all models when you start discovery for one model
[17:14] <mgz> dimitern: should container networking on master work with kvm on maas?
[17:14] <fwereade> dimitern, voidspace: I think we probably should block, it's just that you can't do it safely without a persistent flag
[17:15] <dimitern> mgz, not really
[17:15] <voidspace> fwereade: dimitern: agreed, we need to do it right
[17:15] <mup> Bug #1558678 opened: manual bootstrap: PrepareForCreateEnvironment not implemented <bootstrap> <ci> <manual-provider> <regression> <juju-core:Incomplete> <juju-core admin-controller-model:Triaged> <https://launchpad.net/bugs/1558678>
[17:15] <dimitern> mgz, is the the addressable containers job?
[17:15] <voidspace> fwereade: dimitern: we disabled it because it was broken in several ways
[17:15] <mgz> dimitern: yeah
[17:16] <voidspace> dimitern: it also didn't block access *until* discovery started - which meant bootstrap could complete before the block was in place
[17:16] <fwereade> voidspace, dimitern: see RB4110 for how the discoverspaces worker will shortly be invoked
[17:16] <dimitern> mgz, I wouldn't care too much about it - addressable containers are dying, just haven't died yet
[17:16] <dimitern> fwereade, will check that
[17:17] <dimitern> fwereade, what I'm currently seeing is that the machiner is consistently starting 2 seconds before discoverspaces
[17:17] <fwereade> dimitern, I would expect the machiner to start beforehand usually, yeah, that's top-level whereas discoverspaces is only triggered once we've got a modelworkermanager looking for models to manage
[17:18] <dimitern> fwereade, which messes up setting the observed network config - I guess that must be done in a periodic worker instead of the machiner
[17:18] <fwereade> dimitern, I can well believe it wants to be split out of the machiner, yeah
[17:18] <mgz> dimitern: well, the problem is we don't have a good working spaces/new networking functional test
[17:18] <dimitern> as it currently does not retry / update the observed config later
[17:18] <fwereade> dimitern, yeah, and running a worker with multiple watchers is generally painful, even with catacomb
[17:19] <dimitern> mgz, how about the bundle-based one?
[17:19] <fwereade> dimitern, far better to separate the responsibilities completely
[17:19] <dimitern> fwereade, indeed, I'll look into that
[17:20] <mgz> dimitern: point me at it!
[17:21] <dimitern> mgz, let me have a look
[17:22] <dimitern> mgz, this one for example http://reports.vapour.ws/releases/3771/job/maas-1_9-OS-deployer/attempt/496
[17:22] <mgz> right, we do exercise a bunch of stuff with that, but not kvm (or fancy subnet stuff)
[17:23] <perrito666> dimitern: could you $$merge$$ -> https://github.com/go-goose/goose/pull/19 and tell me who else is in the merge team so I dont pick on you all the time?
[17:23] <dimitern> mgz, kvm won't work with multi-nic, but it should still work with a single nic
[17:24] <dimitern> perrito666, done
[17:24] <perrito666> tx
[17:25]  * dimitern needs to step out for ~1h
[17:36] <frobware> dimitern: you still there.
[17:36] <frobware> ah ^^ - nope
[17:38] <mgz> frobware: are you capturable atm?
[17:45] <mup> Bug #1558703 opened: PatchValue unsafe for SetUpSuite <testing> <unit-tests> <juju-core:Triaged> <https://launchpad.net/bugs/1558703>
[18:06] <voidspace> frobware: dimitern: https://github.com/juju/gomaasapi/pull/10/files
[18:13] <voidspace> frobware: dimitern: all tests now pass on my branch
[18:13] <voidspace> all *maas* tests  - need to do a full test run
[18:13] <voidspace> frobware: dimitern: I need that gomaasapi branch to land so I can update dependencies.tsv
[18:18] <frobware> voidspace: looking
[18:18] <dimitern> voidspace, looks good
[18:20] <dimitern> frobware, hey, I just got back, but I'm thinking of declaring EOD
[18:20] <frobware> dimitern: ok, me too. too many distractions since our lxd investigation earlier.
[18:21] <dimitern> frobware, I've found out that last fix I did was not sufficient
[18:21] <frobware> voidspace: I'll hang around for your branch and push that upstream so we can get a CI run
[18:21] <frobware> dimitern: fresh thinking comes in the morning. :)
[18:21] <dimitern> frobware, i.e. it will likely cause most failing jobs to pass, but it will break network-get
[18:21] <dimitern> frobware, but I have a fix in mind that will take care of that - but as you said - morning :)
[18:21] <frobware> dimitern: that's ok isn't it? (apart from unit test failures)
[18:22] <dimitern> frobware, it's ok for tonight I guess
[18:25] <frobware> dimitern: push it - we wake up to a CI run
[18:26] <dimitern> frobware, will do - it'll take a couple of hours to implement and test, so that's my plan for tomorrow first thing
[18:27] <frobware> dimitern: sounds good
[18:40] <voidspace> frobware: I have a provisioner unit test failure on wrong number of network.InterfaceInfo returned
[18:40] <voidspace> frobware: I'll look at it in the morning, should be able to get it done first thing
[18:41] <voidspace> frobware: oh wait
[18:41] <voidspace> frobware: that fails due to missing lxcbr0, that may fail on master for me as well
[18:42] <voidspace> frobware: and indeed it does fail in the same way
[18:43] <voidspace> frobware: my gomaasapi branch has landed, I'll fix dependencies.tsv and push
[18:47] <voidspace> frobware: right branch pushed
[18:47] <voidspace> frobware: ready for a CI run
[18:47] <arosales> hello juju core folks :-)
[18:47] <voidspace> frobware: *requires* maas 1.9
[18:47] <voidspace> and that's me EOD
[18:47] <arosales> Need some help on a power8 stack trace
[18:47] <voidspace> g'night all
[18:47] <arosales> https://bugs.launchpad.net/juju-core/+bug/1558734
[18:47] <mup> Bug #1558734: POWER8 agent stacktraces and refuses to boot <juju-core:New> <https://launchpad.net/bugs/1558734>
[19:03] <rick_h__> natefinch: quick check, if I update my charm with a min-version, and I do attempt to deploy it on older Juju what happens?
[19:03] <natefinch> rick_h__: it deploys
[19:03] <rick_h__> natefinch: ok, so Juju doesn't freak about the unknown attribute?
[19:04] <natefinch> rick_h__: nope... one of the nice things about the way we deserialize the data in there... anything we don't recognize we ignore
[19:05] <natefinch> rick_h__: in this particular case, it would kind of be nice if we got a "error, can't deploy, unrecogized data in metadata: min-juju-version"  .... but, alas, it'll just ignore it and deploy.
[19:05] <rick_h__> natefinch: ok
[19:09] <mup> Bug #1558734 opened: POWER8 agent stacktraces and refuses to boot <juju-core:New> <https://launchpad.net/bugs/1558734>
[19:28] <frobware> mgz: still about?
[20:30] <mup> Bug #1558769 opened: unable to create-model in azure <juju-core:New> <https://launchpad.net/bugs/1558769>
[21:52] <perrito666> I broke restore? :( that  is ironic
[21:55] <mup> Bug #1558803 opened: Manual deploy on ppc64el wants wrong package and agents <ci> <manual-provider> <ppc64el> <regression> <juju-core:Incomplete> <juju-core admin-controller-model:Triaged> <https://launchpad.net/bugs/1558803>
[23:38] <arosales> mwhudson: marcoceppi still seeing juju peg the cpu on power8, any suggestions?
[23:38] <mwhudson> arosales: is this a power8 where c programs like dpkg actually work?
[23:38] <mwhudson> because debugging firmware issues via juju seems insane
[23:39] <arosales> they have been working, I am not sure if they have tested lately
[23:39] <arosales> mwhudson: ack I am not asking you to debug firmware via Juju
[23:39] <arosales> mwhudson: I am dumb, but not that dumb
[23:40] <arosales> mwhudson: just asking if you had any suggestion for marcoceppi given juju was pegging the cpu
[23:40] <mwhudson> arosales: basically, no
[23:40] <mwhudson> if you can give me access, i can poke around
[23:40] <mwhudson> but as i said in other mail, testing something built with golang-go rather than gccgo would probably be more useful overall
[23:41] <menn0> wallyworld: would you be able to look at http://reviews.vapour.ws/r/4218/ pls?
[23:41] <wallyworld> sure
[23:41] <arosales> mwhudson: marcoceppi may chime with access here in bit, but it is dinner time for him
[23:42] <arosales> mwhudson: juju 2.0 built any different than 1.25?
[23:42] <mwhudson> arosales: not entirely my department, but, gosh, i certainly hope so
[23:42] <mwhudson> arosales: you are testing trusty, i assume?
[23:42] <arosales> ok so perhaps we try juju 2.0 on that machine
[23:42] <arosales> mwhudson: yes trusty atm
[23:43] <wallyworld> arosales: we are moving to use golang 1.6 for building but afaik are not quite there yet
[23:45] <arosales> ah so testing 2.0 doesn't help there -- gotcha
[23:46] <arosales> mwhudson: fyi golang-go is indeed the problem and not recommended, and we build juju 2.0 GA with go-lang and we run into these issues we will be in a world of hurt
[23:46] <arosales> mwhudson: something to be aware of
[23:46] <arosales> wallyworld: thanks
[23:47] <mwhudson> arosales: i don't understand
[23:48] <arosales> mwhudson: there is no current juju (stable or dev) that is build with golang 1.6
[23:48] <arosales> if 2.0 ends up being built wiwth gcc-go 4.9 it seems like we would be in world of hurt for juju 2.0 ga
[23:48] <mwhudson> arosales: juju for xenial for amd64 is built with go 1.6
[23:50] <arosales> mwhudson: that is counter to wallyworld's statement
[23:50] <arosales> mwhudson: pehaps wallyworld was saying for ppc64el
[23:50] <wallyworld> arosales: mwhudson: the aim is we will be using golang 1.6 to build for all architectures for 2.0 is my understanding
[23:50] <arosales> mwhudson: which having amdb64 built with go 1.6 doesn't help much with the known issues on power8le
[23:52] <mwhudson> arosales: many axes of variation :/
[23:53] <arosales> indeed, but in the end power8le seems broken on 1.25 built with gcc-go 4.9