[00:29] <alexisb> anyone else seeing new unit test failures on master?
[00:29] <alexisb> something changed for me over the past hour or so
[00:51] <thumper> fuck...
[00:52] <thumper> cherylj: I'm going to beg forgiveness
[00:52] <thumper> I'm doing a drive by
[00:52] <thumper> during a bug fix
[00:53] <thumper> because what I found is unneeded code
[00:58] <thumper> wallyworld: ping
[00:58] <wallyworld> wot
[00:58] <wallyworld> it wasn't me
[00:58] <thumper> wallyworld: do you recall how to have a JujuConnSuite test use a different user?
[00:58] <wallyworld> it was someone else
[00:58] <thumper> it was
[00:58] <thumper> I've not even bothered to look who
[00:58] <wallyworld> hmmm
[00:58] <thumper> I don't care
[00:58] <thumper> in particular
[00:58] <wallyworld> was just messing with you
[00:58] <thumper> I'm wanting to add a test for bug 1570594
[00:58] <mup> Bug #1570594: read access to admin model allows grant <docteam> <juju-release-support> <juju-core:Triaged by thumper> <https://launchpad.net/bugs/1570594>
[00:58] <wallyworld> i don't recall offhand, but i can look
[00:58] <thumper> there are feature tests that the command is hooked up
[00:59] <thumper> but I want to say "run this command as this user"
[00:59] <thumper> seems like something we would want to do
[00:59] <thumper> and I thought you may have done something like this (or axw)
[00:59] <wallyworld> yeah. you can log in from the CLI. but for a test, i'd have to look
[01:01] <thumper> wallyworld: in particular, I was thinking around the new local user / cred storage story
[01:02] <wallyworld> thumper: i see another feature test that invokes "logout" and then "login", which will work,but there's a way to manipulate the suite directly i'm sure
[01:02] <thumper> if I wanted to add somthing that would say "use this user / pwd combo" for the CLI command, how do we do it
[01:02] <wallyworld> there's a current user in the yaml
[01:02] <thumper> ew
[01:02] <wallyworld> current-account
[01:02] <thumper> we want a repo suite method that says "set this user as current"
[01:03] <wallyworld> yes, i'm looking for that
[01:03] <wallyworld> the other ways invoke setting up yaml that the cli would use
[01:04] <thumper> that's gross
[01:04] <thumper> we can do better
[01:04] <wallyworld> eg create > 1 account on a controller with different access and set up one as current
[01:04] <wallyworld> yes
[01:04] <thumper> how about...
[01:04] <thumper> ...
[01:04]  * thumper thinks
[01:04]  * thumper looks at the code some more
[01:05] <wallyworld> thumper: i can't see any feature tests for grant/revoke even. so it may be something we've not added to the suite before
[01:05] <thumper> it appears that the JujuConnSuite uses the default config storage (ie disk)
[01:05] <wallyworld> thumper: what about OpenAPIAs()
[01:06] <wallyworld> you get a client connection as the user you want
[01:06] <thumper> featuretests/cmd_juju_model_test.go
[01:06] <thumper> that is where the grant and revoke feature tests are
[01:06] <thumper> it calls the cli
[01:06] <thumper> from the outside
[01:06] <thumper> so I need to set up the "current user"
[01:06] <wallyworld> thumper: see TestCanPostWithLocalLogin
[01:07] <thumper> wallyworld: wrong level of interaction
[01:08] <wallyworld> so you want to set up the current user for a CLI call?
[01:08] <thumper> yep
[01:08] <wallyworld> juju switch-user i think
[01:08] <wallyworld> ah that's gone
[01:08] <thumper> nah... again wrong level
[01:09] <thumper> I just want to set using the config manager bits
[01:09] <thumper> as in: start of test create read only user, set that user as the current one
[01:09] <wallyworld> you can set up an in memory config
[01:09] <thumper> then invoke the cli
[01:09] <wallyworld> one sec
[01:10] <thumper> I'm sure we do this shit elsewhere
[01:10] <thumper> just with all the changes around user cred storage, I'm not sure where to look any more
[01:10] <thumper> it isn't where I last looked
[01:11] <wallyworld> thumper: see createmodel_test
[01:11] <wallyworld> in cmd/juju/controller
[01:11] <wallyworld> the setuptest sets up an in memory config
[01:12] <thumper> I don't want a memory config
[01:12] <thumper> but at least I can see part of what I want there
[01:12] <wallyworld> you want an on disk one in a fake home?
[01:13] <thumper> where is the disk config?
[01:13] <thumper> that is what the test currently uses
[01:13] <wallyworld> jujuclient package
[01:14] <thumper> because we don't have enough things with the name juju in it?
[01:14] <thumper> geez
[01:14] <wallyworld> NewFileClientStore()
[01:14] <wallyworld> well that's what it is
[01:14] <wallyworld> functionality for the Juju Client
[01:14] <wallyworld> we could have called the package George
[01:15] <thumper> heh
[01:16] <thumper> it seeme the JujuConnSute has one already in ControllerStore
[01:17] <thumper> so... what are the minimal steps I need to add a user/pwd pair to the current model for the store?
[01:19] <wallyworld> thumper: controllerStore.UpdateAccount()
[01:19] <wallyworld> that will create / update a named account (user)
[01:19] <wallyworld> for a given controller
[01:20] <thumper> k
[01:20] <wallyworld> the AccountDetails struct has user/password plus a macaroon which is optional
[01:21] <wallyworld> well, i think you can leave it off when testing
[01:22] <wallyworld> thumper: the controllerStore on JujuConnSuite is right now just used to hold controller info when testing CLI command structs directly. if you want to add users etc it may be best to rename it
[01:23] <wallyworld> thumper: although TestAddUserAndRegister uses the account bits
[01:24] <wallyworld> in cmd_juju_register_test
[01:24] <thumper> I think I have what I need...
[01:25] <wallyworld> thumper: ok, np. if you get stuck, the above test shows how to setup NewAPIConnectionParams to create an api connection
[01:25]  * thumper nods
[01:25] <wallyworld> using the account details you added to the store
[01:33] <cherylj> and so it was foretold
[01:33] <cherylj> that tests would fail
[01:33] <cherylj> on this, the 21st day of April
[01:33] <cherylj> when thine distro-info revealed
[01:33] <cherylj> that the lts
[01:33] <cherylj> is
[01:33] <cherylj> xenial
[01:33] <cherylj> http://juju-ci.vapour.ws:8080/job/github-merge-juju/7506/console
[01:34] <cherylj> and no merges shall merge
[01:35] <mup> Bug #1572798 opened: list-clouds or show-cloud does not show default region <juju-core:New> <https://launchpad.net/bugs/1572798>
[01:37]  * thumper headdesks
[01:38] <cherylj> mgz, sinzui ping?
[01:38] <sinzui> hi cherylj
[01:38] <cherylj> hey hey sinzui
[01:38] <cherylj> happy release day
[01:38] <cherylj> nothing can merge now
[01:38] <cherylj> :D
[01:39] <cherylj> what can we do to get things to merge so we can fix the failing tests incrementally?
[01:40] <sinzui> cherylj: 1. I open the lst cherry soda.
[01:40] <cherylj> can we hack the distro-info on whatever instance we provision?
[01:40] <sinzui> cherylj: 2. Just after the test script injects angsty Antelope, We change Xenial to supported or devel
[01:41] <cherylj> sinzui: 3 - we assign these bugs POST HASTE!
[01:42] <cherylj> alright wallyworld and thumper, time to pony up some bodies to fix unit tests :)
[01:42] <thumper> wallyworld: how do I set the newly added user as the default user?
[01:42] <sinzui> cherylj: I thnk merges/*ix unit tests are fixable in 30 minutes. I hope the window's unit tests don't need sucha a hack. I cannot think how they would think xenial is lts
[01:42] <wallyworld> cherylj: redir is already doing a whole bunch :-)
[01:42] <wallyworld> cherylj: and perrito666 fixes the windows ones
[01:43] <cherylj> sinzui: that would probably be the fallback default series, which has not been updated to be xenial yet
[01:43] <sinzui> cherylj: , No, first open soda and order child to bring ice cream, then fix test
[01:43] <cherylj> check for shellfish
[01:43] <wallyworld> thumper: SetCurrentAccount()
[01:43] <cherylj> since your kids seem bent on killing you
[01:43] <thumper> wallyworld: yeah... that didn't work
[01:43] <cherylj> wallyworld: there are 7 bugs for different packages with failing tests
[01:43] <cherylj> and that's just in juju/juju
[01:43] <cherylj> I didn't test the other repos
[01:45] <thumper> wallyworld: perhaps a quick hangout for a screenshare and you can tell me what I'm doing wrong
[01:45] <wallyworld> cherylj: the guys have been told to pick stuff from the board and/or ask you, i'll ask them to prioritise unit test fixes
[01:45] <wallyworld> thumper: ok
[01:45] <thumper> cherylj: it seems like the no matching tools one should be a quick fix
[01:46] <thumper> TBH I'm surprised there weren't xenial tools added to the tests before
[01:46] <cherylj> thumper: some might be solved by changing testing/environ.go:const FakeDefaultSeries = "trusty" to "xenial"
[01:46]  * thumper nods
[01:46] <cherylj> but not all
[01:46] <thumper> wallyworld: I'm in the hangout
[01:47] <wallyworld> cherylj: can we tag the cards with "unit test" so they are easily identified?
[01:47] <wallyworld> there's a lot of cards on that board
[01:47] <cherylj> wallyworld: sure.  These are the only critical cards in tech-debt
[01:47] <mup> Bug #1572798 changed: list-clouds or show-cloud does not show default region <juju-core:Invalid> <https://launchpad.net/bugs/1572798>
[01:48] <wallyworld> cherylj: they are the ones i've already asked redir to look at
[01:48] <wallyworld> the LTS ones
[01:48] <sinzui> cherylj: I think changing the born date to 2016-05-21 will work. DO you agree
[01:48]  * cherylj checks locally
[01:49] <cherylj> sinzui: yes that works
[01:49] <sinzui> :)
[01:49] <cherylj> if by "born date" you mean "release"
[01:50] <cherylj> same thing
[01:59] <mup> Bug #1572798 opened: list-clouds or show-cloud does not show default region <juju-core:Invalid> <https://launchpad.net/bugs/1572798>
[02:00] <sinzui> cherylj: I will send an update to all the slaves. It will take about 20 minutes. We might se everything start to work then
[02:00] <cherylj> tyvm, sinzui
[02:01]  * redir is eod
[02:01]  * thumper read that initially as redir is dead
[02:01] <redir> hehe
[02:02] <wallyworld> redir: i was just letting cherylj know we did assign  resources to fixing the LTS test issues and weren't ignoring her :-)
[02:03] <wallyworld> redir: didn't expect you to do any more work past EOD
[02:03] <redir> cherylj: wallyworld I'll have a qq about those tomorrow. I modified stuff to work with xenial and got all but 2 passing in cmd/jj/service
[02:03] <redir> wallyworld: I'm not
[02:03] <redir> :)
[02:03] <cherylj> redir: I'll be here, just ping me
[02:03] <redir> cool
[02:04] <cherylj> redir: we should make sure it works with trusty too (as we're updating the merge bot to forget about xenial for now)
[02:04] <cherylj> and hopefully we'll save ourselves pain for the next lts
[02:04] <wallyworld> cherylj: it can't really work with both at once
[02:04] <wallyworld> we need to choose
[02:05] <redir> cherylj: I modified environs/config/config.go to say xenial
[02:05] <cherylj> wallyworld: I think it would be a case of checking not against a hard coded series, but rather against the default series
[02:05] <mup> Bug #1572798 changed: list-clouds or show-cloud does not show default region <juju-core:Invalid> <https://launchpad.net/bugs/1572798>
[02:05] <redir> and updated tests. THey worked (execpt 2) then reverted environs... and they still passed.
[02:05] <wallyworld> cherylj: that's where is disagree - tests should use hard coded values
[02:05] <wallyworld> cherylj: so that when stuff changes, we are forced to fix the tests
[02:06] <cherylj> and we do this every two years
[02:06] <cherylj> ok
[02:06] <wallyworld> that's just IMHO
[02:06] <wallyworld> others may disagree
[02:06] <redir> but I think the multi series test charm code is looking for precise or trusty.
[02:07] <wallyworld> redir: that's because the test charm data contains precise and trustyu
[02:07] <wallyworld> that data doesn't come from lts
[02:07] <redir> I think it should use the value of the system the tests are running on, wallyworld, cherylj $.02:)
[02:07] <wallyworld> from from the metadata.yaml for the test charm
[02:07] <redir> wallyworld: I figured that but hadn't found where yet.
[02:08] <redir> wallyworld: of course:|
[02:08] <wallyworld> redir: testcharms/charm-repo
[02:08] <redir> wallyworld: thanks
[02:09] <wallyworld> redir: that charm metadata doesn't necessarily need to include xenial - it could, but not strictly necessary to get the current tests passing as that's not a root cause issue IIANM
[02:11] <thumper> wallyworld: this is so terrible
[02:11] <thumper> wallyworld: dumped the yaml, and there is "kontroller" and "local.kontroller"
[02:13] <redir> wallyworld: if you have a minute i wouldn't mind you vetting what I am doing, before I do it all over the place...
[02:13] <wallyworld> redir: sure, jump in to https://plus.google.com/hangouts/_/canonical.com/juju-core-team
[02:18] <thumper> axw: it is your fault
[02:19] <thumper> jujuclient/file.go line 541
[02:19] <thumper> apparently we shouldn't have multiple users using one controller
[02:20] <axw> thumper: you can have multiple users, just not logged in at once
[02:20] <axw> thumper: from the same client
[02:20] <sinzui> cherylj: The update is in place and I have requeued alexis's and mgz's merges
[02:20] <cherylj> thanks, sinzui!
[02:20] <thumper> axw: the code says no
[02:20] <thumper> see comment on line 533
[02:20] <axw> thumper: this is client-side. you can logout and login
[02:21] <axw> thumper: the reason for the change was to avoid accidentally leaving your client logged into a controller
[02:22] <thumper> all our juju conn suite tests use the admin model...
[02:23] <axw> thumper: can you just remove the admin user and then add your new user?
[02:23] <thumper> how?
[02:23] <thumper> how do I programatically logout?
[02:23] <sinzui> axw: you have accidentally voluneered to prove we can delay xenial's release by one month in the tests. I will replay your lp1571832-tools-layered merge if needed
[02:23] <axw> thumper: RemoveAccount(controller, "admin@local")
[02:24] <axw> sinzui: wat?
[02:24] <mwhudson> how do you guys stop goimports deleting "gopkg.in/mgo.v2" all the time?
[02:24] <cherylj> axw: nothing is merging because unit tests are failing now that xenial is the lts
[02:25] <cherylj> axw: so we're hacking the merge bot to think that it's not release day for xenial
[02:25] <sinzui> axw: the juju test suite fails if xenial is released, and it is in some timezones. I have a hack in place to prevent the tests from seeing xenial's release. Your branch got in before mgz's
[02:26] <axw> cherylj sinzui: I'm confused, did I do something wrong? cancel my job if you need to
[02:26] <cherylj> axw: no :)
[02:26] <axw> okey dokey
[02:26] <cherylj> axw: you're just our first victim to see if sinzui's hack is working
[02:26] <sinzui> axw, you did nothing wrong, you just got into the queue first
[02:26] <axw> ah, heh :)
[02:26]  * axw squeaks like a guinea pig
[02:27] <cherylj> sinzui: so are the i386 tests gone now?
[02:27] <sinzui> cherylj: yes they are :)
[02:27] <cherylj> yay!
[02:27] <cherylj> because I'm fixing the arm64 tests at the expense of i386
[02:27] <cherylj> :)
[02:27] <axw> mwhudson: I've been meaning to hack goimports to be aware of context. there's a TODO in the code to prefer import paths that are used in other files in the same package IIRC
[02:28] <axw> mwhudson: it's a PITA
[02:28] <mwhudson> axw: grumble
[02:36] <natefinch> mwhudson: is there a different mgo package that it's choosing?  What I do is just remove the incorrect package from my gopath
[02:37] <mwhudson> natefinch: i don't think so
[02:38] <natefinch> mwhudson: when is it deleting the import?  I sometimes get the problem where I manually add the import before I add the code, and then save, and goimports runs and removes the unused import. :/
[02:38] <mwhudson> natefinch: on any save
[02:39] <mwhudson> natefinch: i think it's because the package name is different from the last component of the import path
[02:39] <mwhudson> but it's also possible i'm holding it wrong
[02:39] <natefinch> mwhudson: hmm.. weird.  I've done a lot of work using gopkg.in import paths, and it seems to work ok
[02:39] <mwhudson> hmm
[02:41] <natefinch> mwhudson: just double checked and it adds the right import for mgo.v2 if it's missing, and won't remove it if it's there (and used).
[02:41] <mwhudson> natefinch: huh, ok, good to know
[02:41] <mwhudson> now why is it not working for me ? :(
[02:42] <natefinch> is it an old version of goimports?  maybe there was a bug fix at some point
[02:42] <mwhudson> i just rebuilt it
[02:42] <mwhudson> although let's rebuild again just to be sure
[02:43] <mwhudson> ok works now, my rebuild must not have actually rebuilt it ?!
[02:43] <mwhudson> anyway
[02:43] <mwhudson> sorry for the noise
[02:43] <natefinch> glad it's working :)
[02:43] <mwhudson> no wait, no it's not :(
[02:43] <natefinch> aww crap
[02:45] <mwhudson> natefinch: aah works outside of emacs
[02:47]  * mwhudson updates things
[02:50] <mwhudson> bah doesn't help
[02:54] <thumper> fuck fuck fuckity fuck
[02:54]  * thumper bitches some more
[02:58] <cherylj> can I get a review?  http://reviews.vapour.ws/r/4669/
[03:00] <natefinch> cherylj: can you slap a comment about the i386 about the fact that we don't support it anymore?  I wouldn't know that by looking at that code.
[03:00] <natefinch> above the i386 that is
[03:01] <natefinch> cherylj: otherwise, ship it :)
[03:06] <sinzui> sorry axw my fix worked, but your merge had one failure in cloudinitSuite.TestWindowsCloudInit
[03:06] <axw> sinzui: yeah, I forgot to update a test, just rescheduled it
[03:07] <axw> sinzui: sorry for holding up your fix
[03:07] <thumper> hmm...
[03:08] <mwhudson> cherylj, natefinch: powerpc seems a pretty safe "juju will never ever support" arch
[03:10] <thumper> oh fark...
[03:10]  * thumper headdesks again
[03:12]  * thumper headdesks again
[03:12]  * thumper headdesks again
[03:16] <natefinch> mwhudson: it's really just a string.  If we want, we could use arch=abcdef ... but I'm guessing that might fail elsewhere.... i386 is something we can parse as a valid arch that we don't support.
[03:20] <cherylj> natefinch: yeah, that's the thing.  It has to be a valid arch to juju (as defined in juju/utils/arch), but not one we support
[03:21] <cherylj> and it was decreed yesterday that we are not building for i386 anymore
[03:21] <cherylj> yay
[03:21] <natefinch> cherylj: it's honestly kind of funny that we even have arches defined that we don't support.  You'd think we could just remove those and then... problem solved.
[03:30] <natefinch> weird, somehow half the tests in this suite aren't getting run
[03:37]  * thumper headdesks
[03:37]  * thumper headdesks
[03:37]  * thumper headdesks
[03:37]  * thumper headdesks
[03:37]  * thumper headdesks
[03:43] <mwhudson> thumper: having fun?
[03:44] <thumper> mwhudson: no, why?
[03:44] <mwhudson> thumper: just a suspicion i had
[03:44] <thumper> mwhudson: you must be very astute
[03:45] <natefinch> lol
[03:45] <mwhudson> thumper: well i'm running juju tests so i have lots of time to be observant
[03:46] <mwhudson> oh um, this doesn't seem like good news
[03:46] <mwhudson> with juju-mongodb (i.e. 2.4):
[03:47] <mwhudson> PASS: allwatcher_internal_test.go:421: allWatcherStateSuite.TestChangeAnnotations	0.309s
[03:47] <mwhudson> with 3.2:
[03:47] <mwhudson> PASS: allwatcher_internal_test.go:421: allWatcherStateSuite.TestChangeAnnotations	24.110s
[03:47] <thumper> FARK!!!
[03:47] <thumper> wow
[03:47] <thumper> shit
[03:47]  * thumper passes that to wallyworld
[03:47] <natefinch> told you
[03:48] <wallyworld> yep, horatio has highlighted that
[03:48] <mwhudson> ah ok cool
[03:48] <wallyworld> it sucks, we need to figure out why exactly
[03:49] <thumper> wallyworld: http://reviews.vapour.ws/r/4670/
[03:49] <wallyworld> ok
[03:50] <thumper> wallyworld: it has a drive by cleanup I couldn't let lie
[03:51] <thumper> wallyworld: the important bit was that sharing models currently only done by controller admins
[03:51] <thumper> which is crazy
[03:51] <thumper> but that's what we have
[03:52] <thumper> but read only access to the controller model made you a controller admin
[03:52] <thumper> which I've fixed
[03:52] <thumper> in this branch
[03:52] <wallyworld> good :-)
[03:55] <wallyworld> thumper: so what happened to all that angst that the grant/revoke methods were on the wrong facade?
[03:55] <thumper> that is a different issue
[03:55] <thumper> that's still fucked
[03:55] <thumper> but we are no more fucked than before
[03:55] <thumper> but more unfucking needed
[03:55]  * thumper is emailing...
[03:55] <wallyworld> so the root issue here was a Find() was missing a condition
[03:57] <thumper> wallyworld: for admins, yes
[03:57] <thumper> we didn't have readonly before
[04:08] <natefinch> oh FFS
[06:53] <axw> wallyworld: https://github.com/juju/juju/pull/5244  -- fixes critical issue
[06:53] <wallyworld> sure
[06:54] <wallyworld> axw: oh, i thought we had that filtering where needed
[06:54] <axw> wallyworld: so did I ...
[06:54] <wallyworld> is this a regression?
[06:54] <axw> wallyworld: apparently only for LXC
[06:54] <axw> I don't know
[06:54] <wallyworld> right ok, lxc in 1.25/2.0 worked
[06:54] <wallyworld> but not lxd
[06:54] <axw> wallyworld: not sure if we were ever doing the right thing for KVM, seems unlikely that we'd have changed it
[06:55] <wallyworld> kvm never got much love
[06:55] <wallyworld> on non amd64
[07:04] <wallyworld> axw: i just asked for an extra test
[07:15] <axw> wallyworld: ok, thanks
[08:15] <dimitern> mgz: ping
[08:24] <dimitern> frobware: ping
[08:41] <TheMue> morning
[08:42] <dimitern> TheMue: o/
[08:52] <TheMue> voidspace: twittering about management experiences ;)
[08:54] <voidspace> TheMue: :-)
[09:01] <dooferlad> dimitern, frobware, voidspace: standup?
[09:01] <voidspace> dooferlad: omw
[09:31] <voidspace> dimitern: so on a maas controller with extra interfaces juju bootstrap fails due to a schema error in gomaasapi
[09:32] <voidspace> dimitern: the way networks are returned fails thumper's json validation code :-)
[09:32] <voidspace> dimitern: so a fix in gomaasapi needed
[09:32] <voidspace> I'm looking :-)
[09:32] <voidspace> good to find these things out I guess
[09:32] <dimitern> voidspace: oh, what's the error?
[09:33] <voidspace> dimitern: ERROR failed to bootstrap model: cannot start bootstrap instance: cannot run instances: cannot run instance: space 0: subnet 3: subnet 2.0 schema check failed: dns_servers: expected list, got nothing
[09:34] <voidspace> dimitern: it looks like it can't get all the subnet info - which is possibly a problem on the configuration
[09:34] <voidspace> dimitern: but the controller is running fine, so gomaasapi shouldn't refuse to talk to it
[09:35] <dimitern> voidspace: ah! it already is so much better at figuring out how exactly maas api changed
[09:35] <dimitern> voidspace: yeah, the dns_servers should be optional
[09:37] <voidspace> dimitern: yeah, but the old approach was tolerant against schema changes like that ;-)
[09:37] <voidspace> oh the good old days
[09:38] <dimitern> :D
[09:41] <frobware> dimitern, voidspace, dooferlad: morning - running late today :/
[09:42] <dimitern> frobware: morning o/
[09:42] <dimitern> fwereade: are you around?
[09:42] <fwereade> dimitern, o/
[09:42] <frobware> dimitern: have you commissioned a node in MAAS with xenial recently?
[09:43] <dimitern> frobware: not since BOW IIRC
[09:44] <dimitern> fwereade: do you have 10m or so for a quick HO?
[09:44] <frobware> dimitern: I have no working nodes this morning... :(
[09:45] <dimitern> fwereade: context: I'm almost done with refactoring state ports to associate them with subnets, rather than networks
[09:45] <dimitern> frobware: I'll try recommissioning one of the nucs now, as I've upgraded to 2.0 beta3 this morning
[09:46] <fwereade> dimitern, sure, joining juju-sapphire
[09:46] <dimitern> fwereade: omw
[10:20] <axw> frobware: thanks for the review. I don't think there's much point in tacking on the type to the name, since you'll never see the name out of the context of the type anyway
[10:20] <axw> frobware: unless space awareness would change that ...
[10:20] <axw> frobware: would private networks like these be exposed to the user?
[10:21] <frobware> axw: my comment was more from a debugging standpoint should you want to identify these "things" separately.
[10:22] <axw> frobware: ok then, I guess I can buy that. I'll change it tomorrow
[10:22] <axw> thanks
[10:25] <babbageclunk> voidspace: after all the twitter harrassment, you got the day wrong again ;)
[10:26] <babbageclunk> voidspace: anything I can do to help with the bootstrap issue?
[10:26] <voidspace> babbageclunk: I just haven't corrected it yet :-p
[10:26] <voidspace> babbageclunk: I'm on it, thanks
[10:27] <babbageclunk> voidspace: ok, I'll keep going through the tests <sigh>
[10:27] <voidspace> babbageclunk: hah
[10:27] <voidspace> babbageclunk: you could test my branch deploying a container in the standard case
[10:27] <voidspace> babbageclunk: I can't test due to fixing gomaasapi
[10:27] <babbageclunk> ok
[10:27] <babbageclunk> voidspace: what's the standard case/
[10:28] <babbageclunk> ?
[10:28] <voidspace> babbageclunk: add a machine (used to be juju add-machine)
[10:28] <voidspace> babbageclunk: then juju deploy wordpress --to lxc:1
[10:28] <voidspace> or whatever the number of the new machine is
[10:28] <voidspace> might be 0 if you've not switched to admin, not sure
[10:28] <babbageclunk> voidspace: ok cool - trying that now
[10:28] <voidspace> babbageclunk: standard case is without extra subnets / nics which is what I was attemptin
[10:28] <voidspace> *attemptin
[10:30] <voidspace> what the hell
[10:30] <babbageclunk> voidspace: nice correction
[10:30] <voidspace> *attempting
[10:30] <voidspace> a failed attemp
[10:37] <dimitern> frobware: that nuc I tried to recommission failed\
[10:38] <dimitern> frobware: telltale sign from the rackd.log: http://paste.ubuntu.com/15962619/
[10:39] <frobware> dimitern: I'm totally broken too...
[10:41] <dimitern> frobware: it's even reported: https://bugs.launchpad.net/maas/+bug/1389811
[10:41] <mup> Bug #1389811: tgtadm: out of memory crash <crash> <oil> <MAAS:Triaged> <https://launchpad.net/bugs/1389811>
[10:41] <babbageclunk> Man that is really annoying - sometimes my machine just freezes for about 2 minutes.
[10:42] <babbageclunk> I think it's journald freezing.
[10:43] <dimitern> babbageclunk: that used to happen quite often with all of my vmaas setups in lxc, all of which also bind-mount my $HOME inside the container
[10:43] <frobware> dimitern: so I see another error to: 'sh initctl - not found'
[10:44] <babbageclunk> dimitern: encrypted home?
[10:44] <frobware> dimitern: I cannot persuade the UI to use trusty for commissioning
[10:44] <dimitern> babbageclunk: what was observable is ssh starting to fail to connect; sudo systemctl restart logind resolves this for a while; haven't see in happen recently though
[10:47] <frobware> dimitern: does commissioning in 1.9 work?
[10:47] <frobware> dimitern: should you have the inclination and bandwidth...
[10:48] <dimitern> frobware: have you tried changing the release used for commissioning in the UI Settings tab?
[10:49] <frobware> dimitern: yep, it won't let me. :/
[10:49] <frobware> dimitern: I tried fiddling with maas $PROFILE boot-sources ...
[10:50] <dimitern> frobware: perhaps it's by design - i.e. not allowing commissioning with earlier releases than the controller
[10:51] <frobware> dimitern: and I removed 16.04 from my images, leaving 14.04 but I still cannot select 14.04
[10:53] <babbageclunk> frobware, voidspace, dimitern: sometimes when I start my maas controller KVM the maas admin isn't accessible - apache's running but going to /MAAS just spins
[10:56] <babbageclunk> frobware, voidspace, dimitern: any suggestions?
[10:56] <frobware> babbageclunk: how much ram did you allocate for the maas server?
[10:56] <babbageclunk> frobware: 1G
[10:56] <frobware> babbageclunk: also, cd /var/log/maas and take a look
[10:57] <frobware> babbageclunk: I did that for a while, but I think it needs a little more, particularly when re-importing the images
[10:57] <dimitern> frobware: no idea why it doesn't allow you :/ - anything in /var/log/maas/ ?
[10:58] <dimitern> frobware: 2GB seems to be recommended
[10:58] <babbageclunk> frobware, dimitern: "Can't update service statuses, no RPC connection to region."
[10:59] <babbageclunk> I can ping google, for example, so there's network connection out.
[11:01] <voidspace> babbageclunk: check the log?
[11:01] <babbageclunk> dimitern, frobware: ok, can I just bump it up in VMM, or do I need to recreate.
[11:02] <babbageclunk> ?
[11:02] <voidspace> babbageclunk: 1G may not be enough
[11:02] <voidspace> babbageclunk: bumping it in the VM should be fine
[11:02] <frobware> babbageclunk: power it down, bump the value via the virt-manager interface for the node
[11:02] <babbageclunk> Found a promising sounding bug from the log messages.
[11:03] <dimitern> babbageclunk: try sudo dpkg-reconfigure maas-region-controller, then maas-region-api, then maas-rack-controller (in that order)
[11:04] <babbageclunk> ok, I can see messages in the rack controller log complaining the region isn't responding.
[11:04] <babbageclunk> dimitern: ok, will do
[11:06] <frobware> dimitern: so I reinstalled maas (gah!) and just added 14.04 images but that is not enough. the "deploy" dropdown is populated with 14.04 but the commissioning dropdown is empty. looks like 16.04 or bust.
[11:09] <dimitern> frobware: I suspect you need to wipe /var/lib/maas/boot-resources/* and re-import the images to be sure it's clean
[11:09] <frobware> dimitern: I did a clean VM install. :)
[11:10] <dimitern> frobware: oh :/ I see
[11:11]  * frobware productively heads for lunch :/
[11:11] <babbageclunk> Ok, poking those helped - not sure which bit, presumably the reconfigures restarted things - thanks guys!
[11:16] <frobware> dimitern: yep, import 16.04 gives me the only boot image.
[11:18] <dimitern> frobware: fwiw I can see both trusty and xenial in the dropdown to choose release for commissioning
[11:18] <frobware> dimitern: 1.9.1?
[11:18] <dimitern> maybe upgrading from 1.9 works better than fresh installation
[11:19] <dimitern> frobware: no, 2.0.0 (beta3+bzr4941)
[11:25]  * frobware really heads for lunch
[11:27] <babbageclunk> voidspace: still bootstrapping, haven't had a chance to add a container yet.
[11:28] <voidspace> babbageclunk: heh, ok
[11:29] <voidspace> babbageclunk: good news about your oyster card (etc)
[11:29] <voidspace> babbageclunk: gives you hope for humanity
[11:35] <babbageclunk> voidspace: yeah! And such a nice postcard as well"
[11:35] <babbageclunk> !
[11:36] <babbageclunk> voidspace: please no monitoring of typing speed
[11:36] <voidspace> babbageclunk: ah, I missed that. Nice.
[11:36] <voidspace> babbageclunk: I'll email you the keylogger
[11:36] <voidspace> ;-)
[11:37] <babbageclunk> voidspace: bootstrap seemed to have hung after "installing package: tmux"
[11:37] <babbageclunk> voidspace: killed it and kicked it off again
[11:37] <babbageclunk> voidspace: any way to get debug logging before the controller is bootstrapped?
[11:37] <voidspace> babbageclunk: anything in the logs?
[11:38] <voidspace> babbageclunk: installing to container or machine?
[11:38] <babbageclunk> voidspace: locally or on the node?
[11:38] <voidspace> babbageclunk: on the node
[11:38] <voidspace> babbageclunk: installing directly to the node, or to a container on the node?
[11:38] <babbageclunk> voidspace: I couldn't ssh in - where's the key?
[11:39] <babbageclunk> voidspace: still bootstrapping, haven't gotten to the add-machine part.
[11:39] <voidspace> babbageclunk: oh I see - as part of the bootstrap, I'd forgotten it installed tmux
[11:40] <voidspace> babbageclunk: uhm, not sure - dimitern ^^^ (where's the key to ssh in)
[11:40] <babbageclunk> voidspace: yeah, what's that about - just so it's there?
[11:40] <dimitern> voidspace, babbageclunk: juju ssh keys are in ~/.local/share/juju/ssh/
[11:41] <babbageclunk> dimitern: ah, ok - will try using those to snoop around if it gets "stuck" again.
[11:41] <dimitern> you could try ssh -i <juju_rsa> ubuntu@<what-maas-shows-as-ip>
[11:41] <dimitern> while it's still bootstrapping
[11:42] <dimitern> and if it appears hung, might be just slow to upd / inst the packages; i.e. tail -f /var/log/cloud-init-output.log once in
[11:42] <dimitern> babbageclunk: ^^
[11:43] <babbageclunk> dimitern: awse, thanks
[11:45] <babbageclunk> ok, looks like it's actually doing things with tools.
[11:46] <babbageclunk> voidspace, dimitern: was there some breakage around upload-tools recently?
[11:46] <voidspace> babbageclunk: there
[11:47] <dimitern> babbageclunk: oh yeah - but it's fixed now (2 days ago sometime)
[11:47] <voidspace> babbageclunk: oops, there was - but it should be fixed
[11:49] <dimitern> babbageclunk: bootstrap --upload-tools failed almost right away for me before the fix
[11:50] <dimitern> babbageclunk: or you mean the tools info mismatch (new thing since yesterday IIRC) ?
[11:53] <dimitern> that happens for lxd containers due to some arch mismatch between host and container
[11:53] <babbageclunk> dimitern: no, I was thinking of the one earlier this week.
[11:54] <babbageclunk> dimitern, voidspace: nothing happening in the cloud-init output log after this:
[11:54] <babbageclunk> 454a97ab1b6bc43e28bb149813edfeec31eceda09b86b5474cca31712528f163  /var/lib/juju/tools/2.0-rc1.1-xenial-amd64/tools.tar.gz
[11:55] <dimitern> babbageclunk: anything in /v/l/syslog?
[11:55] <babbageclunk> bootstrap still seems stalled after installing tmux (log says that was successful/already installed)
[11:55] <voidspace> I'll try
[11:56] <voidspace> babbageclunk: is this master or my branch
[11:56] <babbageclunk> dimitern: nothing suspicious looking. last message is: Apr 21 11:54:06 undisabled-miya systemd[1]: Started Cleanup of Temporary Directories.
[11:57] <babbageclunk> dimitern: (I presume that's in UTC)
[11:57] <babbageclunk> voidspace: yours
[11:57] <dimitern> babbageclunk: any zombie processes?
[11:57] <voidspace> dammit, I can't bootstrap because of my maas configuration issue
[11:57] <voidspace> will leave it for the moment, sorry
[11:59] <babbageclunk> dimitern: not that I can see
[12:00] <babbageclunk> dimitern: any other logs I should look for?
[12:01] <dimitern> babbageclunk: can you paste the current /v/l/c-i-output.log ?
[12:01] <ashipika> can anybody help? i'm getting: WARNING cannot delete default security group: cannot retrieve default security group: "juju-3884d5ab-1317-420a-8acc-fb8bceb7d70a": The security group 'juju-3884d5ab-1317-420a-8acc-fb8bceb7d70a' does not exist in default VPC 'vpc-f34a3496' (InvalidGroup.NotFound)
[12:01] <ashipika> ERROR failed to bootstrap model: cannot start bootstrap instance: no "xenial" images in us-east-1 with arches [amd64]
[12:04] <babbageclunk> dimitern: http://pastebin.ubuntu.com/15964229/
[12:04] <babbageclunk> dimitern: hey, it just finished!
[12:07] <voidspace> dimitern: babbageclunk: confirmed to work https://github.com/juju/gomaasapi/pull/44
[12:08] <dimitern> babbageclunk: yeah, it looks like it's just slow - a lot of published upgrades to apply
[12:08] <dimitern> voidspace: looking
[12:11] <voidspace> dimitern: the error was "got nothing"
[12:11] <dimitern> voidspace: on my maas 2 I can see `"dns_servers": []` for some of the subnets
[12:11] <voidspace> dimitern: that was the case that was already tested and worked
[12:13] <voidspace> dimitern: ah, indeed - it is null
[12:13] <mup> Bug #1567296 changed: Plugin API fails with multiple juju binaries <juju-core:Fix Released> <https://launchpad.net/bugs/1567296>
[12:13] <voidspace> dimitern: I will update and change to null instead
[12:13] <voidspace> dimitern: test still passes
[12:13] <dimitern> voidspace: thanks!
[12:14] <voidspace> dimitern: pushed
[12:14] <dimitern> voidspace: it passes because go's json package allows that :)
[12:14] <voidspace> dimitern: the test uses the schema - so we're testing the schema not the json package
[12:15] <voidspace> dimitern: unless you meant something else
[12:15] <voidspace> the problem was the over strict schema
[12:15] <voidspace> without my change to the schema the test fails
[12:16] <voidspace> dimitern: thaanks
[12:16] <dimitern> voidspace: yeah, layers upon layers.. now LGTM though :)
[12:16] <voidspace> lunch
[13:16] <mup> Bug #1573020 opened: upgrade-charm --path does not recognize dot <juju-core:New> <https://launchpad.net/bugs/1573020>
[13:36] <dimitern> frobware: I managed to fix my nucs and now commissioning passes ok
[13:37] <frobware> dimitern: see my conversation on #maas
[13:43] <dimitern> frobware: fwiw I struggled about with this bug 1389811 until now, added comment how managed to resolve it
[13:43] <mup> Bug #1389811: tgtadm: out of memory crash <crash> <oil> <MAAS:Triaged> <https://launchpad.net/bugs/1389811>
[13:44] <dimitern> frobware: (reading #maas) - nice! good catch
[14:17] <babbageclunk> voidspace, dimitern - trying to deploy to a container I get this error;
[14:18] <babbageclunk> ERROR storing charm for URL "cs:trusty/ubuntu-7": cannot retrieve charm "cs:trusty/ubuntu-7": cannot get archive: Get https://api.jujucharms.com/charmstore/v5/trusty/ubuntu-7/archive?channel=stable: dial tcp: lookup api.jujucharms.com on 192.168.150.2:53: read udp 192.168.150.4:37104->192.168.150.2:53: i/o timeout
[14:18] <dimitern> babbageclunk: yeah, no xenial versions of the charm yet
[14:19] <dimitern> babbageclunk: but never worry :) try e.g. juju deploy ubuntu --series xenial --force --to lxd:0
[14:19] <babbageclunk> Ok - trying that, thanks
[14:20] <babbageclunk> dimitern: nope, same error.
[14:20] <voidspace> babbageclunk: try deploying wordpress instead
[14:20] <voidspace> maybe the same problem
[14:20] <dimitern> yeah
[14:20] <babbageclunk> dimitern: hmm, maybe it can't get to t'internet?
[14:21] <babbageclunk> dimitern, voidspace: ok, trying that
[14:21] <dimitern> babbageclunk: try with --debug?
[14:21] <babbageclunk> all these fun new options I'm learning"
[14:21] <babbageclunk> !
[14:22] <dimitern> babbageclunk: well, I'd first try just add-machine lxd:0 to make sure that works, comes up with expected NICs, dns works, egress to internet works
[14:22] <mup> Bug #1573055 opened: Latest modification to https://streams.canonical.com/juju/tools/streams/v1/com.ubuntu.juju-released-tools.json  makes juju bootstrap fail <bootstrap> <juju-core:New> <https://launchpad.net/bugs/1573055>
[14:22] <dimitern> babbageclunk: once all the above works (at least a couple of times :), you're almost there
[14:22] <babbageclunk> dimitern: looks like DNS from that machine isn't working.
[14:23] <voidspace> This VLAN is the default VLAN in the fabric, can't delete. Can't delete this fabric it has VLANs attached.
[14:23] <dimitern> babbageclunk: ah, well - what's in /etc/resolv.conf on the host and the container?
[14:23] <dimitern> voidspace: first delete the vlans
[14:24] <babbageclunk> dimitern: resolv.conf looks right, points to the maas controller
[14:24] <dimitern> babbageclunk: can you ping the dns IP from the container?
[14:26] <babbageclunk> Hang on, I'm not in the container yet - only have a machine.
[14:26] <voidspace> dimitern: can't delete the VLAN it's the default in the fabric.
[14:28] <dimitern> voidspace: what are you trying to do? get rid of extraneous fabric?
[14:28] <dimitern> babbageclunk: what does sudo lxc list show?
[14:28] <babbageclunk> Hmm, didn't have DNS forwarding turned on in my MAAS 2 controller. Added that and now pinging things on the internet works.
[14:28] <voidspace> dimitern: to see if I can bootstrap if I go back to the previous configuration :-/
[14:28] <voidspace> because right now it won't bootstrap
[14:28] <babbageclunk> Don't quite understand how the bootstrap worked given that.
[14:29] <voidspace> deleting the NICs from the VM worked
[14:29] <voidspace> well, got rid of the fabrics anyway
[14:29] <dimitern> good :)
[14:29] <voidspace> no, they're still there - but not listed on the controller any more - which may be enough
[14:31] <mup> Bug #1573055 changed: Latest modification to https://streams.canonical.com/juju/tools/streams/v1/com.ubuntu.juju-released-tools.json  makes juju bootstrap fail <bootstrap> <juju-core:Invalid> <https://launchpad.net/bugs/1573055>
[14:34] <babbageclunk> voidspace, dimitern: Ok, from juju debug-log, I'm getting this error:
[14:35] <babbageclunk> voidspace, dimitern: actually, these errors: http://pastebin.ubuntu.com/15966208/
[14:35] <voidspace> babbageclunk: try lxc instead of lxd - I don't trust lxd :-)
[14:35] <voidspace> (yet)
[14:35] <babbageclunk> voidspace: ok
[14:35] <voidspace> babbageclunk: ah, there's an interesting error though
[14:36] <voidspace> schema check failed
[14:36] <babbageclunk> voidspace: also, this bit seems cromulent: device 2.0 schema check failed: interface_set
[14:36] <voidspace> looks like interface_set needs to be optional too
[14:36] <babbageclunk> voidspace: snap
[14:36] <babbageclunk> ok, trying lxc instead
[14:36] <voidspace> babbageclunk: see this PR and do the same for interface set in gomaasapi https://github.com/juju/gomaasapi/pull/44
[14:37] <dimitern> babbageclunk: it can be useful to try what juju does from the maas cli?
[14:37] <voidspace> to look at interface_set, "machines read" should be enough
[14:37] <voidspace> and find the place with null :-/
[14:37] <babbageclunk> dimitern: yeah, that sounds good
[14:38] <mup> Bug #1573055 opened: Latest modification to https://streams.canonical.com/juju/tools/streams/v1/com.ubuntu.juju-released-tools.json  makes juju bootstrap fail <bootstrap> <juju-core:Invalid> <https://launchpad.net/bugs/1573055>
[14:38] <dimitern> babbageclunk: see here (if you haven't) http://paste.ubuntu.com/15966260/
[14:38] <voidspace> *phew* bootstrap is slow but it worked this time
[14:39] <voidspace> well, is getting further anyway
[14:39] <babbageclunk> dimitern: I haven't - what is that?
[14:40] <dimitern> babbageclunk: that's my test-bed script which I used as PoC how to do the multi-nic devices
[14:41] <dimitern> it's fairly messy, opinionated, and not portable I'm afraid
[14:41] <dimitern> but it implements the necessary API calls in the right order
[14:42] <babbageclunk> dimitern: useful as a starting point, thanks!
[14:42] <babbageclunk> voidspace: deploying to lxc is working well.
[14:43] <voidspace> babbageclunk: cool, that means AllocateContainerAddresses maybe basically works...
[14:43] <babbageclunk> although I still see the same schema error in the logs.
[14:43] <babbageclunk> kind of neat that it keeps going in spite of that.
[14:44] <babbageclunk> Ok, I'll fix that in the gomaasapi schema
[14:44] <dimitern> babbageclunk, voidspace: the schema error like any other issues during PrepareContainerInterfaceInfo() are simply ignored
[14:45] <babbageclunk> dimitern: nice
[14:45] <dimitern> so to truly verify whether it worked, you need at minimum: 1) be able to ssh to the host, 2) sudo lxc exec juju-machine-0-lxd-0 bash, 3) ping bbc.co.uk, 4) ip route show, 5) cat /e/n/i.d/00-juju.cfg
[14:46] <dimitern> also helps to check sudo lxc list - it should show multiple NICs there
[14:47] <mup> Bug #1573055 changed: Latest modification to https://streams.canonical.com/juju/tools/streams/v1/com.ubuntu.juju-released-tools.json  makes juju bootstrap fail <bootstrap> <juju-core:New> <https://launchpad.net/bugs/1573055>
[14:47] <babbageclunk> dimitern: is that to me?
[14:48] <dimitern> babbageclunk: yeah - just sharing how I verify usually
[14:48] <babbageclunk> I couldn't deploy to an lxd - it failed with the simplestreams error.
[14:48] <babbageclunk> What would the equivalent be for lxc?
[14:49] <dimitern> babbageclunk: ah, sorry - well, lxc should work just the same (only slower to come up due to the initial cloning, etc.)
[14:49] <dimitern> babbageclunk: so juju add-machine lxc:0
[14:50] <babbageclunk> dimitern: How do I list LXC containers? The container doesn't show up on the host node under lxc list.
[14:50] <dimitern> babbageclunk: sudo lxc-ls -f
[14:50] <babbageclunk> dimitern: thanks
[14:51] <voidspace> deploying to lxc I get this in the logs (i.e. it doesn't work):
[14:51] <voidspace> machine-0: 2016-04-21 14:50:24 WARNING juju.provisioner lxc-broker.go:115 failed to prepare container "0/lxc/0" network config: unexpected: ServerError: 500 INTERNAL SERVER ERROR (Subnet matching query does not exist.)
[14:54] <dimitern> voidspace: it might help setting the logging-config to '<root>=TRACE' to get (a lot more) context
[14:54] <voidspace> yeah
[14:55] <babbageclunk> dimitern: ok, and using lxc-attach bash I can get into the container. I can ping bbc, and there are routes (not exactly sure what they should be). There's no 00-juju.cfg in /e/n/i.d (which will henceforth be known as enid).
[14:55] <voidspace> enid :-)
[14:55] <babbageclunk> But this isn't a multi-nic situation, so maybe that's to be expected.
[14:56] <dimitern> babbageclunk: lxc-attach might be misleading btw
[14:57] <dimitern> babbageclunk: I'd use 'sudo lxc-attach -n juju-machine-0-lxc-0 -e bash' to be sure you're in the container ns and not the host
[14:58] <dimitern> babbageclunk: check /var/log/cloud-init-output.log while inside the container for any issues
[15:01] <katco> ericsnow: standup time
[15:01] <babbageclunk> dimitern: all looks pretty good - at least, there's a nice looking finished message
[15:07] <dimitern> babbageclunk: from cloud-init?
[15:08] <babbageclunk> dimitern: yup
[15:08] <babbageclunk> Cloud-init v. 0.7.5 finished at Thu, 21 Apr 2016 14:40:19 +0000. Datasource DataSourceNoCloudNet [seed=/var/lib/cloud/seed/nocloud-net][dsmode=net].  Up 12.0 seconds
[15:15] <dimitern> babbageclunk: so it seems to be working inside the lxc?
[15:16] <dimitern> babbageclunk, voidspace, fwereade: updated http://reviews.vapour.ws/r/4656/ and I'd appreciate one last look
[15:19] <dimitern> I suppose it's to be expected to start seeing "expected series 'trusty', obtained 'xenial'" test failures on master now
[15:21] <dimitern> more of those: adding new machine to host unit "django/0": cannot assign unit "django/0" to machine 0: series does not match
[15:32] <mup> Bug #1573099 opened: Juju Register not test / script friendly; requires console interaction <juju-core:New> <https://launchpad.net/bugs/1573099>
[15:35] <dimitern> babbageclunk, voidspace, fwereade: any objections to land http://reviews.vapour.ws/r/4656/ ?
[15:35] <fwereade> dimitern, I'm afraid I can't devote proper attention to it today :(
[15:36] <babbageclunk> dimitern: I've already said I love it! Unfortunately I'm not valid yet. :(
[15:36] <dimitern> fwereade: np
[15:37] <dimitern> babbageclunk: cheers - so we're waiting on voidspace and/or frobware :)
[15:37] <frobware> dimitern: looking now
[15:37] <dimitern> frobware: thanks!
[15:38] <frobware> dimitern: if you are using spaces don't charms implicitly express which subnet they refer to? (I was reading the commit message)
[15:40] <dimitern> frobware: yeah, but charms see addresses as well
[15:40] <dimitern> frobware: and they're more important for opening ports than spaces (if the charm even cares)
[15:42] <dimitern> frobware: did that make sense ? :)
[15:43] <frobware> dimitern: I got sidetracked with the diff
[15:43] <dimitern> frobware: ah, yeah it's a bit big, but at least makes things more consistent around migrations
[15:44] <frobware> dimitern: why did we go from s/0:juju-public/0:/ ?
[15:45] <dimitern> frobware: juju-public was the hardcoded name of the supposedly default public network, now it's an empty subnet CIDR instead
[15:46] <frobware> dimitern: so 0: represents the CIDR?
[15:46] <dimitern> frobware: it can be also non-empty (tests verify that), but no user(charmer)-facing way to do it
[15:46] <babbageclunk> voidspace, frobware, dimitern: review please? https://github.com/juju/gomaasapi/pull/45
[15:46] <dimitern> frobware: the colon separates machine ids and subnet cidrs, so the 0 is the machine id
[15:49] <dimitern> babbageclunk: looking
[15:49] <frobware> dimitern: ok... wasn't obvious to me
[15:50] <dimitern> frobware: it's explained in the doc comment of state.WatchOpenedPorts
[15:50] <dimitern> oops, now I see that comment needs updating as well
[15:51] <dimitern> babbageclunk: actually, when can we have a device without interface_set ?
[15:51] <babbageclunk> dimitern: That's what I see in my MAAS now
[15:52] <dimitern> babbageclunk: I can't see that happening using the maas cli manually: http://paste.ubuntu.com/15967504/
[15:53] <dimitern> babbageclunk: can you try that on your maas (the parent needs to match one of your nodes ofc)
[15:53] <babbageclunk> http://pastebin.ubuntu.com/15967528/
[15:54] <babbageclunk> oh, sorry - I didn't do the create
[15:54] <babbageclunk> hang on
[15:54] <dimitern> babbageclunk: ah! the warning might be causing that
[15:54] <dimitern> babbageclunk: try 'maas refresh' to update the api spec cached by the maas cli client
[15:55] <babbageclunk> dimitern: ok, did that - still no interface_set
[15:55] <dimitern> babbageclunk: try 'devices create' instead of 'devices read'
[15:55] <dimitern> might be different
[15:56] <babbageclunk> dimitern: just tried that, still the same.
[15:56] <babbageclunk> man, I love the name generator: frondescent-rosalie
[15:56] <dimitern> :)
[15:57] <dimitern> babbageclunk: hmm - what does 'maas maas2 version read -d' return?
[15:57] <babbageclunk> although, I'm still getting the warning
[15:59] <babbageclunk> http://paste.ubuntu.com/15967646/
[15:59] <dimitern> babbageclunk: 'maas refresh' won't work (at least used to) if any of the profiles' urls you have ('maas list') are unaccessible
[15:59] <babbageclunk> dimitern: only the one in there
[15:59] <dimitern> babbageclunk: uuh - rather old
[16:00] <dimitern> babbageclunk: 2.0.0 alpha3+bzr4810
[16:00] <babbageclunk> dimitern: true - shall I upgrade and try again?
[16:00] <dimitern> babbageclunk: please do, at least we've confirmed the response format between alpha3 and beta3 is different
[16:01] <babbageclunk> dimitern: okeydoke, running now
[16:01] <dimitern> babbageclunk: are you using the packages in the experimental3 ppa?
[16:01] <babbageclunk> dimitern: I don't remember adding that - how'd I check - look in sources?
[16:02] <dimitern> babbageclunk: apt-cache madison maas
[16:02] <dimitern> it what I use
[16:03] <babbageclunk> dimitern: madison is a weird subcommand name
[16:03] <dimitern> babbageclunk: it had some good story behind it as well, but can't remember now :)
[16:04] <dimitern> babbageclunk: you can: sudo add-apt-repository ppa:maas-maintainers/experimental3, then update and dist-upgrade
[16:10] <dimitern> frobware: review poke (sorry to be a pest)
[16:10] <frobware> dimitern: still looking at it
[16:10] <dimitern> frobware: ok, take your time
[16:11] <dimitern> frobware: I'll rebase the follow-up onto it and keep going for now
[16:12] <frobware> dimitern: I'm almost done
[16:12] <dimitern> frobware: sweet!
[16:14] <babbageclunk> dimitern - my maas version still reports the old version - is there a command to restart the various daemons at one fell swoop?
[16:14] <frobware> babbageclunk: reboot
[16:14] <frobware> babbageclunk: it's all virtual, it's all quick
[16:14] <babbageclunk> frobware: yeah - I guess that would work just as well
[16:14] <babbageclunk> frobware: just feels a bit windowsy
[16:14]  * frobware blushes
[16:15] <babbageclunk> :(
[16:15] <babbageclunk> Oops :)
[16:15] <dimitern> babbageclunk: yeah, I usually reboot to ensure kernel updates etc. take effect
[16:15] <dimitern> (with dist-upgrade esp.)
[16:18] <frobware> dimitern: ah, always with dist-upgrade. always.
[16:18] <frobware> dimitern: reviewed
[16:19] <dimitern> frobware: thanks!
[16:24] <babbageclunk> dimitern: now maas-cli is back to hanging. Do I need to do the dpkg-reconfigure every time?
[16:26] <babbageclunk> Or is that because of the upgrade?
[16:28] <frobware> dimitern, voidspace, babbageclunk: hopefully an easy one: http://reviews.vapour.ws/r/4673/
[16:28] <dimitern> babbageclunk: what do you mean? it doesn't terminate?
[16:28] <babbageclunk> dimitern: yeah - I run maas maas2 version read -d and have to ^C it
[16:29] <babbageclunk> service maas-rackd status complains about the region controller being missing.
[16:29] <dimitern> babbageclunk: that's not a good sign :/ how about the web ui?
[16:29] <frobware> babbageclunk: re 'madison' - http://unix.stackexchange.com/questions/276037/why-apt-madison
[16:30] <babbageclunk> service maas-regiond status says active (exited) with nothing in the log.
[16:30] <dimitern> babbageclunk: hmm yeah - it seems dpkg-reconf might be in order
[16:30] <babbageclunk> dimitern: Already tried, no dice
[16:31] <babbageclunk> dimitern: I'mma reboot again
[16:31] <dimitern> frobware: LGTM
[16:32] <dimitern> babbageclunk: which package did you reconf?
[16:35] <babbageclunk> dimitern: maas-region-controller and maas-rack-controller
[16:35] <frobware> dimitern, babbageclunk, voidspace: need to drop early today...
[16:36] <babbageclunk> Is there a way to make review board ignore any whitespace changes? gofmt changing the gaps for blocks of assignments makes it really hard to see what changed.
[16:36] <voidspace> ericsnow: ^^^
[16:37] <babbageclunk> Ooh, release drinks
[16:38] <ericsnow> babbageclunk: there's a "Hide whitespace changes" toggle in the diff view, on the right below the list of files at the top
[16:38] <ericsnow> babbageclunk: is that what you're talking about?
[16:42] <mgz> weeelll... I now have a new lxd container failure
[16:42] <mgz> working through them
[16:43] <dimitern> babbageclunk: maas-region-api IIRC is the new name of the maas-region-controller? anyway - try reconf'g that
[16:44] <dimitern> babbageclunk: :/ release issues I guess - sorry for suggesting the upgrade :(
[16:46] <dimitern> babbageclunk: in anycase at least I verified on a working beta3 MAAS we have interface_set, and on your alpha3 we don't, so it's good to be flexible about that in gomaasapi for the time being; so lgtm on your https://github.com/juju/gomaasapi/pull/45
[16:47] <bogdanteleaga> do we have the custom signed image stream thing merged?
[16:53] <mup> Bug #1565044 changed: s390x unit tests fail because not tools for arch <ci> <jujuqa> <s390x> <test-failure> <juju-core:Fix Released by reedobrien> <https://launchpad.net/bugs/1565044>
[16:53] <mup> Bug #1573136 opened: kill-controller is stuck <juju-core:New> <https://launchpad.net/bugs/1573136>
[16:55] <dimitern> alexisb: ping
[16:56] <alexisb> dimitern, pong
[16:56] <alexisb> whats up?
[17:23] <mup> Bug #1573148 opened: Juju terms language confusing for locally-deployed charms <juju-core:New> <https://launchpad.net/bugs/1573148>
[17:23] <mup> Bug #1573149 opened: 'failed to ensure LXD image' creating LXD container <ci> <lxd> <juju-core:In Progress by tycho-s> <https://launchpad.net/bugs/1573149>
[17:33] <perrito666> Going afk for a moment
[18:24] <voidspace> how do I set the log level in juju 2, now there's no set-env
[18:25] <natefinch> voidspace: set-model-config
[18:25] <natefinch> voidspace: took me a while to figure that out too
[18:26] <voidspace> natefinch: ok, thanks. set-model-config *what*?
[18:27] <voidspace> ah, no
[18:27] <voidspace> natefinch: never mind
[18:27] <voidspace> thanks :-)
[18:27] <natefinch> welcome :)
[18:42] <ericsnow> natefinch: PTAL: http://reviews.vapour.ws/r/4675/
[18:45] <natefinch> ericsnow: will do
[18:45] <ericsnow> natefinch: ta
[18:50] <natefinch> ericsnow: http://reviews.vapour.ws/r/4676/
[18:50] <ericsnow> natefinch: k
[19:02]  * perrito666 tries to discover why tomb is sudenly not working in go1.6 in windows
[19:20] <natefinch> ericsnow: btw, an example of using the functionality added in that PR is here: http://reviews.vapour.ws/r/4677/
[19:23] <mup> Bug #1557052 changed: Can't bootstrap a trusty controller: no registered provider for "lxd" <2.0-count> <go1.2> <lxd> <trusty> <juju-core:Fix Released> <https://launchpad.net/bugs/1557052>
[19:33] <mup> Bug #1571131 changed: juju add-ssh-key $(cat ~/.ssh/a-key.pub) needs quoting in helptext <helpdocs> <juju-core:Fix Released by reedobrien> <https://launchpad.net/bugs/1571131>
[20:16] <ericsnow> natefinch: FYI, I left a review of your core patch
[20:17] <ericsnow> natefinch: I don't think we need that testing patch if we change the approach in core
[20:17] <ericsnow> natefinch: (though it probably stands on its own merits)
[20:22] <natefinch> ericsnow: cool, thanks
[20:24] <ericsnow> natefinch: np
[21:23] <perrito666> rogpeppe1: have a moment?
[21:42] <mup> Bug #1573259 opened: Non-admin users unable to share models <regression> <juju-core:In Progress by thumper> <https://launchpad.net/bugs/1573259>
[21:42]  * thumper sighs
[21:42] <thumper> I'm going to have to work out how to get the lxd provider working again...
[21:44] <thumper> abentley: do you know of the git command that relates to the bzr one of merge-preview?
[21:46] <abentley> thumper: No, sorry.  Still a noob with git.
[21:46] <thumper> hmm..
[21:46] <thumper> I want to see the diff of what my merge would be against master
[21:46] <thumper> so not what is on master that isn't on mine
[21:46] <thumper> just what is unmerged
[21:46] <thumper> should be easy right?
[21:52] <ericsnow> thumper: make sure you apt-get lxd to get the latest and then run "sudo dpkg-reconfigure -p medium lxd" to set up the LXD bridge
[21:54] <ericsnow> thumper: see https://github.com/juju/docs/pull/998/files
[21:54] <thumper> ericsnow: ta
[21:54] <ericsnow> thumper: np :)
[21:55]  * thumper is looking at code and getting a sinking feeling
[21:55] <ericsnow> thumper: had to do it today so it was fresh in my mind
[21:56]  * thumper breathes a sigh of relief
[21:56] <thumper> seems I don't need to worry about that...
[21:56]  * thumper goes back to details
[21:57]  * thumper chuckles
[21:57] <thumper> "lxc finger"
[21:57] <thumper> I'll give it the finger
[21:59] <perrito666> axw_: ping me when you are awake and around?
[22:02] <abentley> thumper: So merge --preview actually does the merge, so it'll show conflicts and stuff.  The equivalent git command, if it exists, would also need to do the merge.  "diff -r submit:" just performs a diff against well-chosen revisions and is more likely to have a git analogue.
[22:04] <abentley> thumper: I think you can do the equivalent of "diff -r submit:" with "git diff $(git merge-base)"
[22:05] <thumper> hmm...
[22:05] <thumper> ta
[22:13] <redir> ericsnow: got a minute?
[22:13] <ericsnow> redir: sure
[22:13] <redir> HO?
[22:38]  * perrito666 no longer has a webcam but still waves when finishing a conversation......
[22:38] <wallyworld> redir: i was just going to ping you about eric's PR? can i join the hangout too?
[22:39] <axw_> perrito666: I'm awake and around
[22:44] <wallyworld> ericsnow: redir: are you guys hanging out somewhere?
[22:45] <ericsnow> wallyworld: moonstone
[22:46] <thumper> BOOM!!!
[22:46] <thumper> that was my head-cannon
[22:47]  * thumper cries in the corner
[22:48] <mup> Bug #1573286 opened: juju/mongo: oplog tests fail with mongod 3.2 <juju-core:New> <https://launchpad.net/bugs/1573286>
[22:51] <perrito666> axw_: nevermind, I sorted it out
[22:51] <perrito666> tx a lot
[22:52] <axw_> perrito666: okey dokey
[22:52] <thumper> bugger....
[22:52] <thumper> I really should do this in two branches
[22:53] <thumper> but I won't
[22:53] <thumper> poo
[23:02] <mwhudson> is there some funky way i can jack up the mgo logging when running juju tests? menn0?
[23:04] <menn0> mwhudson: I don't know off the top of my head but I know approximately where the change would need to be made
[23:04]  * menn0 looks
[23:04] <mwhudson> close enough
[23:05] <menn0> mwhudson: the base suite which manages the mongo instances used in tests is in here: github.com/juju/testing/mgo.go
[23:05] <mwhudson> i have found some time.Sleep(100 * time.Millisecond)s in mgo and i am suspicious
[23:06] <menn0> mwhudson: you'll probably want to mess with the args passed to mongo in MgoInstance.run()
[23:06] <mwhudson> menn0: ah no i mean mgo's own logging, mgo.SetOutput and stuff
[23:06] <menn0> ahhh
[23:06]  * menn0 confused mgo and mongo
[23:06] <mwhudson> i guess i can jam something in there as well
[23:06] <menn0> right
[23:07] <menn0> mwhudson: all the tests that use mongodb (and therefore mgo) are based on that suite
[23:07] <menn0> mwhudson: so that suite is probably still the place to mess with mgo's logging
[23:07]  * menn0 looks at those sleeps
[23:09] <mup> Bug #1573294 opened: state tests run 100x slower with mongodb3.2 <juju-core:New> <https://launchpad.net/bugs/1573294>
[23:11] <menn0> mwhudson: wow there are a bunch of sleeps throughout mgo
[23:12] <mwhudson> menn0: enterprissssssssssssssssssssssssssse
[23:27] <mwhudson> hm no doesn't seem to be a sleep in mgo
[23:27] <mwhudson> menn0: so now i guess i am interested in jacking up mongo's logging :-)
[23:27] <mwhudson> menn0: and actually seeing it, i guess
[23:28] <menn0> mwhudson: pass --logpath /some/where and --logappend I guess?
[23:29] <menn0> in MgoInstance.run()
[23:34] <mwhudson> menn0: ah haha MgoInstance.run() waits for a log message though :(
[23:34] <menn0> mwhudson: ah crap...
[23:34] <menn0> mwhudson: then you might have to monkey with the log capture stuff in the suite
[23:34] <mwhudson> yeah
[23:36] <mwhudson> oh but it looks like the mongo log output is Tracef-ed
[23:36] <mwhudson> menn0: so can i set the log level to trace when running the tests somehow?
[23:37] <menn0> mwhudson: which logs? juju's?
[23:37] <mwhudson> yea
[23:39] <mwhudson> i guess i can just jam a logger.SetLevel(loggo.TRACE) in