[00:53] <menn0> thumper: SSHClient facade. Review pls. http://reviews.vapour.ws/r/4713/
[01:14] <mwhudson> menn0: i have a couple of simple PRs https://github.com/juju/juju/pull/5252 https://github.com/juju/juju/pull/5241
[01:14] <mwhudson> menn0: reviewboard doesn't seem to have picked them up
[01:21]  * redir is eod. See you tomorrow juju-dev
[01:46] <mup> Bug #1575448 opened: trusty juju 1.25.5 HA availability issues <canonical-bootstack> <juju-core:New> <https://launchpad.net/bugs/1575448>
[02:00] <menn0> mwhudson: looking
[02:00] <mwhudson> menn0: looks like tim merged them
[02:00] <menn0> mwhudson: ok cool. I was having lunch.
[02:01] <mwhudson> or well
[02:01] <mwhudson> menn0: https://github.com/juju/juju/pull/5252 hasn't merged, can you tell why?
[02:01] <mwhudson> oh still processing
[02:01] <menn0> mwhudson: yep, still merging
[02:02] <cherylj> hey perrito666 - your window tests PR fixed this bug, right?  bug 1571783
[02:02] <mup> Bug #1571783: Windows unit tests cannot setup under go 1.6 <ci> <go1.6> <jujuqa> <regression> <test-failure> <unit-tests> <windows> <juju-core:In Progress by hduran-8> <https://launchpad.net/bugs/1571783>
[02:03]  * perrito666 checks
[02:03] <perrito666> yes
[02:03] <cherylj> cool, thanks
[02:06] <a123> having trouble building juju(cb347bb7). Following the README.md results in: cannot find package "github.com/Azure/azure-sdk-for-go/Godeps/_workspace/src/github.com/Azure/go-autorest/autorest/mocks"
[02:06] <davecheney> a123: did you run godeps first ?
[02:07] <davecheney> cd $GOPATH/github.com/juju/juju && godeps -u dependencies.tsv
[02:08] <a123> no I did not. The README.md only says to run 'make install-dependencies'
[02:08] <davecheney> that should do the same thing
[02:08] <davecheney> did that process work ?
[02:08] <davecheney> it might be easier to run the command I suggested
[02:08] <davecheney> and raise a bug if our install docs are out of date
[02:09] <a123> hmm. godeps: command not found.    I'm using: go version go1.6.1 linux/amd64
[02:09] <a123> I'm new to go, if that's not obvious.
[02:10] <davecheney> please raise a bug that make install-dependencies does not install godeps, which is a dependency :)
[02:11] <davecheney> for the momement
[02:11] <davecheney> go get launchpad.net/godep
[02:11] <davecheney> go get launchpad.net/godeps
[02:11] <davecheney> you will need to install bzr, sorry
[02:12] <a123> ha. yep.
[02:12] <davecheney> that may have been while make isntall-deps failed
[02:13] <perrito666> odd, I thought make install installed bzr
[02:13] <a123> hmm. odd. bzr already installed. here's the output of get get launchpad.net/godeps
[02:13] <a123> # cd .; bzr branch https://launchpad.net/godep /home/ubuntu/proj/gojuju/src/launchpad.net/godep bzr: ERROR: Not a branch: "https://launchpad.net/godep/". package launchpad.net/godep: exit status 3
[02:13] <perrito666> a123: its godeps
[02:13] <perrito666> go get launchpad.net/godeps
[02:13] <a123> yep.
[02:13] <perrito666> with an s at the end
[02:13] <perrito666> you are missing it
[02:14] <davecheney> yes, sorry, i typed it incorrectly the first time
[02:14] <a123> working....
[02:14] <davecheney> there is a related tool with a very similar name
[02:16] <a123> godeps -u dependencies.tsv looks like it did its thing.
[02:19] <a123> now running go install -v github.com/juju/juju/... and that looks like it's doing its thing. Thanks for the help.
[02:20] <davecheney> no worries
[02:21] <a123> BTW, anyone get juju bootstrap to work from behind a proxy? At home, no issues at all. Different story behind a proxy.
[02:21] <davecheney> juju _should_ pickup the various http_proxy variables if they are defined in your shell
[02:22] <blahdeblah> a123: 1.25, or 2.x?
[02:22] <blahdeblah> 1.25 works for me
[02:22] <a123> yes. It does look like it does that at first.... Yes, 1.25 worked for me too, now trying 2.0
[02:24] <a123> don't know if this is related to our proxy or not, but doing lxc remote list produced a table where images url looked like:
[02:24] <a123>  https://images.linuxcontainers.org
[02:25] <a123> I could not download any images from there. but when I redefined that url to include the port(8443) the image download was successful.
[02:28] <davecheney> if you've change something (i'm not sure what you've changed) then you'll need to be explicit
[02:28] <davecheney> it sounds like the thing your downloading from expects 443 as the default
[02:29] <a123> right. I ran: lxc remote set-url images https://images.linuxcontainers.org:8443
[02:29] <a123> this redefined the remote images url. I then ran: lxc image copy images:ubuntu/xenial/amd64 local: --alias ubuntu-xenial
[02:30] <a123> w/out changing the URL, the lxc image copy command would not work behind our proxy
[02:30] <davecheney> umm, juju 2.0 doesn't support lxc
[02:30] <davecheney> only lxd
[02:30] <davecheney> i hope this statement is helpful, not frustating
[02:31] <a123> laughing... I thought lxd2.0 was built on top of lxc. Your point is taken though.
[02:32] <davecheney> well it is
[02:32] <davecheney> so your point is technically correct, which is the best kind of correctness
[02:34] <a123> before changing the image url and running: juju bootstrap --config default-series=xenial lxd-test lxd --debug produced:
[02:42] <a123> sorry guys. I'm seeing different debug output now than earlier. lots of connection refused to the 10.0.3.0/24 network. Does the no_proxy setting take CIDR?
[02:44] <a123> that network is attached to lxdbr0
[02:47] <a123> What I should ask is, does juju understand CIDR if used in the no_proxy env var?  ie. export no_proxy=10.0.3.0/24
[02:48] <mgz> a123: no, no_proxy doesn't take a cidr
[02:49] <a123> thanks.
[02:49] <davecheney> i _think_ no_proxy is just a sort of match string
[02:49] <davecheney> export no_proxy=10.
[02:49] <davecheney> ^ not tested
[02:50] <mgz> just a comma seperated list of "domain extensions"
[02:50] <mgz> so, it's suffixes, not prefixes
[02:51] <mgz> valid: no_proxy=.com
[02:51] <mgz> no_proxy=.255
[02:51] <a123> I've found this to be application dependent in the past.
[02:52] <a123> ah. nice.
[02:52] <mgz> not valid: no_proxy=10. no_proxy=10.* etc etc
[02:52] <mgz> we plug this stuff into wget in some places so are limited by what wget supports
[02:52] <a123> oh. It wasn't clear to me if wildcards would work.
[02:54] <a123> ok. wget is the driver. I think I know why my debug is different now. I used the --keep-broken flag when running the bootstrap in hopes of finding answers. How do you destroy the model?
[02:54] <davecheney> juju kill-controller $controller
[02:54] <davecheney> from memory
[02:55] <davecheney> kill is the more finite form of destroy
[02:55] <davecheney> which tends to not actually destroy things 'cos it's a wimp
[02:58] <a123> so much I don't know. Is the controller a different concept than a model? It looks like a controller never got created when using the --keep-broken flag.
[03:02] <a123> so. juju list-controllers returns an empty table. When I then run: juju list-models I get: error: controller local.lxd-test not found. What exactly does --keep-broken do?
[03:08] <a123> thanks for the help everyone. I'm not confident my environment is in a good state. I'm going to tear down the VM, bring up a fresh one and try again tomorrow.
[03:21] <thumper> menn0: a few questions on your review
[03:21]  * thumper goes to make coffee
[03:21] <menn0> thumper: ok, looking
[03:24] <menn0> thumper: good point... these APIs copy the existing APIs used by juju ssh/scp exactly but it's probably worth making sure they at least work for IPv6 too
[03:28] <menn0> thumper: hangout to discuss?
[03:31] <thumper> menn0: sure, gimmie 5?
[03:31] <menn0> yep
[03:32]  * thumper wants to enjoy his coffee first
[03:55] <mup> Bug #1575463 opened: buildSuite.TestGetVersion* CryptAcquireContext: Provider DLL failed to initialize <blocker> <ci> <regression> <test-failure> <unit-tests> <windows> <juju-core:Triaged> <https://launchpad.net/bugs/1575463>
[04:09] <davecheney> menn0: are you looking at this bug https://bugs.launchpad.net/juju-core/+bug/1458585
[04:09] <mup> Bug #1458585: SSHGoCryptoCommandSuite.TestCommand fails <ci> <go1.6> <intermittent-failure> <regression> <test-failure> <wily> <xenial> <juju-core:Incomplete> <juju-core 1.23:Won't Fix> <juju-core 1.25:Triaged> <https://launchpad.net/bugs/1458585>
[04:09] <davecheney> or a duplicate of it ?
[04:09] <menn0> davecheney: no and no
[04:11] <menn0> davecheney: I'm working on making juju ssh/scp use the actual SSH host keys of the machine being connected to
[04:11] <menn0> davecheney: close to being done
[04:14] <davecheney> ok, related, but not the same issue
[04:14] <davecheney> thanks
[04:21] <thumper> wallyworld: when do we add things into the cloud metadata storage?
[04:21] <thumper> wallyworld: is it "normal" behaviour for clouds
[04:21] <thumper> or more used for custom openstack stuff?
[04:21] <wallyworld> thumper: you mean keystone?
[04:21] <wallyworld> or the metadata url
[04:22] <wallyworld> will still allow the use keystone for simplestreams
[04:22] <wallyworld> but i don't think we've used the metadtaa url for ages
[04:22] <wallyworld> we now bootstrap differently
[04:23] <wallyworld> it used to be a way to pass bootstrap instance info across
[04:25] <mup> Bug #1575469 opened: liveSuite.TestBootstrapMultiple invalid character \"\\\\\" in host name <ci> <go1.6> <regression> <test-failure> <unit-tests> <windows> <juju-core:Triaged> <https://launchpad.net/bugs/1575469>
[04:25] <mup> Bug #1575472 opened: Data Race github.com/juju/juju/environs/tools/build.g <ci> <race-condition> <regression> <test-failure> <unit-tests> <juju-core:Triaged> <https://launchpad.net/bugs/1575472>
[04:32] <thumper> wallyworld: I mean the state cloudmetadataC collection
[04:34] <wallyworld> thumper: we cache the simplestreams metadata there at bootstrap and whenever we poll cloud-images
[04:42] <thumper> k
[04:59] <davecheney> menn0: https://github.com/juju/juju/pull/5289
[04:59] <davecheney> i heard u were on call review
[06:09] <menn0> davecheney: looking
[06:11] <menn0> davecheney: looks fine. what's changed in x/crypto that fixes the isssue?
[06:19] <davecheney> menn0: who knows it's been a year since we updated that dependency
[06:19] <davecheney> and there have been heaps of bug fixes to the crypto repo
[06:19] <davecheney> i'm deliberately phrasing it like this because I don't want to backport anything
[06:19] <menn0> davecheney: ah right... so you didn't find a specific upstream change that fixed the issue
[06:19] <davecheney> i didn't even look
[06:19] <davecheney> upgrading to tip fixed the problem
[06:19] <menn0> davecheney: well you have a ship it
[06:45] <davecheney> Do we need to maintain comptabilty with Go 1.2 ?
[06:45] <davecheney> the build bot just failed to land a branch 'cos it tried to build with Go 1.2
[07:42] <dimitern> axw: are you around by any chance?
[07:43] <dimitern> or wallyworld ?
[07:43] <wallyworld> hey, otp
[07:43] <axw> dimitern: yo, I am
[07:43] <dimitern> axw, wallyworld: hey, just a quick question, if you happen know
[07:44] <dimitern> in provider/ec2 can we now only filter instances by model tags rather than secgroups ?
[07:44] <dimitern> axw: I know you did something around that lately
[07:44] <axw> dimitern: not yet, tried to land today but master is blocked
[07:45] <dimitern> I'm working on bug 1321442 and it will be a lot easier not to have to make group filters work with explicit VPC ID
[07:45] <mup> Bug #1321442: Juju does not support EC2 with no default VPC <ec2-provider> <network> <juju-core:In Progress by dimitern> <https://launchpad.net/bugs/1321442>
[07:46] <dimitern> axw: I see, ok - I'll look into your changes
[07:46] <axw> dimitern: hmm you know, I just remembered a reason why we may not want to do away with the group filtering.
[07:46] <axw> dimitern: tags aren't added immediately after creating an instance...
[07:46] <dimitern> axw: ah, bummer
[07:46] <axw> sorry
[07:47] <axw> dimitern: I mean, they're not added until after they're created
[07:47] <axw> dimitern: so there's a window where they could leak
[07:47] <dimitern> axw: np, it makes sense in an AWS world I guess
[07:48] <dimitern> axw: ok, cheers, I'll do group filtering then as well
[07:48] <axw> dimitern: and I'll revert that bit in my PR :)
[07:48] <axw> cheers
[07:51] <dimitern> you gotta love how inconsistent AWS API is at times :[
[07:53] <dimitern> lol `deleteSecurityGroupInsistently`
[08:03] <fwereade> jam, tech board?
[08:32] <voidspace> dimitern: ping
[08:32] <dimitern> voidspace: pong
[08:33] <voidspace> dimitern: I've addressed two of your comments from your review of the devices branch
[08:33] <voidspace> dimitern: you suggest just adding a test for the multi nic case as it's basically done
[08:33] <voidspace> dimitern: however, adding a test means some test infrastructure work as the multi-nic path calls additional provider methods
[08:34] <voidspace> dimitern: not difficult but not nothing
[08:34] <dimitern> voidspace: it looked like that, but yeah - can be a follow up
[08:34] <voidspace> dimitern: in addition there is the known bug with the multi-nic case
[08:34] <voidspace> dimitern: I'd rather land as is - with working and tested single nic containers
[08:34] <dimitern> voidspace: what did you find about the missing subnet?
[08:34] <voidspace> dimitern: not uncovered it yet - still digging
[08:34] <voidspace> dimitern: should be done and dusted today though, can't be *that* hard to find :-)
[08:35] <voidspace> dimitern: so I'll land as is and land multi-nic tests along with the bug fix (assuming it's not a maas bug)
[08:35] <voidspace> dimitern: ok?
[08:35] <dimitern> voidspace: you know what occurred to me yesterday: it might be due to unchecked 0 ids for fabrics or vlans
[08:35] <voidspace> dimitern: possibly
[08:36] <voidspace> dimitern: I'm going to try always setting VLAN ID even if it isn't changing in that update call
[08:36] <dimitern> voidspace: e.g. fabric-0 is always there, but we might not have meant that
[08:36] <voidspace> yeah
[08:36] <dimitern> voidspace: ok, if you don't mind let me do a quick bootstrap with your branch now
[08:37] <voidspace> dimitern: sure
[08:37] <voidspace> I'm doing the same, with modified gomaasapi
[08:39] <dimitern> ok
[08:43] <voidspace> forcing the VLAN to be specified didn't help
[08:44] <voidspace> adding more debugging
[08:44] <voidspace> dimitern: anyway, I'm on it
[08:45] <dimitern> voidspace: can you paste the outputs of 'maas <profile> subnets read', 'fabrics read', and 'machines read' for your maas2?
[08:47] <voidspace> dimitern: http://pastebin.ubuntu.com/16076113/
[08:49] <dimitern> voidspace: thanks, here's mine for comparison: http://paste.ubuntu.com/16076129/
[08:50] <voidspace> dimitern: I'm going to try allocating the machines and making the maas calls manually
[08:51] <voidspace> dimitern: after this bootstrap to confirm it's the CreateDevice call that fails
[08:51] <dimitern> voidspace: sgtm, I'm bootstrapping now
[08:51] <voidspace> dimitern: I'd still like to land single nic support
[08:53] <dimitern> voidspace: I don't disagree with that :)
[08:53] <voidspace> cool
[08:54] <dimitern> voidspace: are both of your first 2 fabrics managed? (0 and 1)
[08:55] <dimitern> i.e. subnets 172.16 and 172.17
[08:55] <voidspace> dimitern: gah, master blocked
[08:55] <voidspace> dimitern: subnets are managed if that's what you mean
[08:55] <voidspace> I don't know what a managed fabric is
[08:56] <voidspace> both subnets
[08:56] <voidspace> dimitern: ok, I was wrong it gets past CreateDevice and UpdateInterface
[08:57] <voidspace> dimitern: so I need to add more instrumentation and redo
[08:57] <voidspace> dimitern: I've got this anyway
[08:57] <voidspace> dimitern: I'll ping you when I've made progress
[08:57] <dimitern> voidspace: ok, your maas2 setup looks fine - so the issue must be related to how we're calling the api
[08:58] <voidspace> yep
[09:00] <dimitern> voidspace: still the same thing - no params (with vlan) passed to update the primary NIC of the device
[09:02] <voidspace> dimitern: standup old boy
[09:21] <TheMue> morning
[09:34] <axw> babbageclunk: it would appear you're the luck OCR today, would you please take a look at http://reviews.vapour.ws/r/4718/diff/#?
[09:34] <axw> fixes master blocker
[09:39] <voidspace> dimitern: I see vlan=5001 in the params of the PUT
[09:40] <dimitern> voidspace: and I can't :/
[09:41] <dimitern> voidspace: and with the vlan set do you still get 500 ?
[09:42] <voidspace> dimitern: wait, that's the wrong vlan though
[09:42] <axw> dimitern voidspace: can either of you take a look at the tiny PR above? it should unblock master
[09:42] <axw> well, with the juju/juju change coming after
[09:42] <voidspace> dimitern: I do get 500
[09:42] <voidspace> dimitern: but I think that's the wrong vlan
[09:42] <voidspace> dimitern: interesting
[09:42] <dimitern> axw: LGTM
[09:42] <axw> ta
[09:43] <dimitern> voidspace: aha!
[09:43] <dimitern> voidspace: 5001 should be the untagged vlan of your fabric-0
[09:43] <dimitern> voidspace: and it should be the same as the host's first NIC's VLAN
[09:44] <voidspace> dimitern: however this subnet comes straight from MAAS
[09:44] <voidspace> but "spaces read" seems to give the right thing
[09:46] <voidspace> dimitern: so in gomaasapi it should be args.Subnet.VLAN() not iface.VLAN()
[09:47] <voidspace> dimitern: and in the single NIC case it works because there's only one
[09:47] <voidspace> dimitern: trying that
[09:47] <dimitern> voidspace: exactly!
[09:48] <voidspace> I think that's it
[09:48] <voidspace> trying it now
[09:48] <dimitern> voidspace: the iface is the device interface, while args.Subnet.VLAN is the one we want on iface
[09:48] <voidspace> yep
[09:48] <voidspace> gaah, that took a long time
[09:48] <voidspace> at least we get to blame Tim
[09:48] <dimitern> :)
[09:48] <voidspace> and a chunk of the time was getting a multi-nic MAAS setup which is worthwhile work
[09:49] <dimitern> voidspace: \o.
[09:49] <dimitern> \o/ even
[09:50] <dimitern> voidspace: and it also helped your maas2 setup is a bit different than mine
[09:50] <voidspace> yep
[09:51] <dimitern> voidspace: are you using 2.0.0 beta4 more recent than bzr 4936 ?
[09:52] <voidspace> dimitern: 4941
[09:52] <voidspace> dimitern: beta3 though!
[09:53] <voidspace> dimitern: I've got past that point with no error
[09:53] <voidspace> dimitern: and I see a device with two nics and two IP addresses
[09:54] <dimitern> voidspace: hmm, well you *might* hit this bug 1572070
[09:54] <mup> Bug #1572070: MAAS 2.0 cannot link physical device interfaces to tagged vlans, breaking juju 2.0 multi-NIC containers <juju> <MAAS:Fix Committed by blake-rouse> <MAAS 1.9:Fix Committed by blake-rouse> <https://launchpad.net/bugs/1572070>
[09:54] <babbageclunk> axw: Sure - sorry, missed this until now.
[09:54] <dimitern> voidspace: sweet! then it should work the rest of the way
[09:54] <voidspace> dimitern: yep, so I'll propose a fix for gomaasapi and then tests for multi-nic
[09:55] <voidspace> frobware: babbageclunk: it turned out to be a bug in gomaasapi
[09:55] <dimitern> voidspace: but that bug will be relevant with mult-nic only
[09:55] <voidspace> dimitern: ok, thanks
[09:55] <voidspace> dimitern: the linking is already done (my vlans are untagged)
[09:55] <voidspace> dimitern: so I think I've got past that
[09:55] <babbageclunk> voidspace: nice
[09:57] <dimitern> voidspace: well since the physical nics of the host are on untagged VLANs it only will become an issue trying to create a second physical NIC of the device linked to a tagged VLAN
[09:57] <voidspace> dimitern: container is running fine
[09:57] <dimitern> voidspace: no WARNINGs in the log around provisioning / PrepareContainerInterfaceInfo ?
[09:58] <voidspace> dimitern: only about no DNS settings found
[09:58] <voidspace> dimitern: nothing else
[09:58] <babbageclunk> axw: dimitern: d'oh, should've reloaded
[09:58] <voidspace> dimitern: and I can ssh fine
[09:58] <voidspace> dimitern: case closed on that one
[09:59] <dimitern> voidspace: awesome! so the device has eth0 and eth1 linked to br-eth0 and br-eth1 on the host?
[10:00] <voidspace> dimitern: this is e/n/i on the container http://pastebin.ubuntu.com/16076575/
[10:02] <dimitern> voidspace: slightly odd to see `dns-nameservers 172.16.0.2` on eth0 which has address 172.17.0.4/24
[10:02] <voidspace> dimitern: it adds the nameservers to the first stanza
[10:02] <dimitern> but otherwise looks solid
[10:02] <voidspace> yeah
[10:02] <dimitern> voidspace: yeah - and only the .16 subnet has dns_servers set?
[10:02] <voidspace> dimitern: this is the host http://pastebin.ubuntu.com/16076591/
[10:03] <voidspace> dimitern: you only need one nameserver entry
[10:03] <voidspace> they're global
[10:04] <voidspace> neither dns is set in maas (both 0.0.0.0) and both are managed
[10:04] <dimitern> voidspace: I see, ok - does 'ping bbc.co.uk' work while inside the container?
[10:05] <voidspace> dimitern: yep
[10:06] <dimitern> voidspace: we're nearly done then :)
[10:09] <voidspace> dimitern: can't test that change easily in gomaasapi - you can specify responses in the test server it uses but not verify requests it seems
[10:10] <voidspace> you can fetch the last request, but it makes another after the update
[10:10] <voidspace> looking to see if I can get at the one before last :-)
[10:11] <voidspace> hah, no
[10:11] <voidspace> ah, I can check the VLAN
[10:11] <voidspace> should be ok
[10:12] <dimitern> voidspace: sure, on it
[10:18] <voidspace> dimitern: are you doing it?
[10:18] <voidspace> dimitern: I have a branch with a fix
[10:18] <dimitern> voidspace: haven't started
[10:18] <dimitern> doing a few things at once as usual
[10:19] <voidspace> dimitern: a proper test involves a lot of json (new interface, vlan and subnet in json)
[10:19] <voidspace> dimitern: I have this though https://github.com/juju/gomaasapi/compare/master...voidspace:maas2-create-device-vlan
[10:19] <voidspace> as there's only one interface on the test machine the test doesn't fail without the fix
[10:20] <voidspace> I suggest we land this, I'll work on juju and come back for a multi-nic test for gomaasapi later
[10:20] <dimitern> voidspace: looks good
[10:20] <voidspace> babbageclunk: https://github.com/juju/gomaasapi/pull/47
[10:22] <voidspace> coffee
[10:34] <babbageclunk> voidspace: I like it
[10:34] <babbageclunk> voidspace: !
[11:26] <babbageclunk> voidspace: ahh, missed your discussion about the test above.
[11:48] <voidspace> babbageclunk: yeah, it needs a better test - but creating a machine with multiple interfaces, subnets and vlans for the gomaasapi test harness is a pain
[11:48] <voidspace> babbageclunk: I'll do it later
[11:48] <voidspace> babbageclunk: it's no worse tested than it was before ;-)
[12:37] <voidspace> dimitern: I've updated http://reviews.vapour.ws/r/4700/
[12:37] <voidspace> dimitern: includes gomaasapi revision bump and a happy path test for multi-nic
[12:37] <voidspace> is master unblocked yet
[12:37] <voidspace> dimitern: still more tests needed
[12:39] <dimitern> voidspace: still looks good to land, and I'll do another quick live test with it
[12:39] <voidspace> dimitern: that would be good, see if it works for you
[12:46] <voidspace> master is still blocked
[13:08] <alexisb> voidspace, dimitern, frobware, babbageclunk please JFDI any maas2 related PRs
[13:09] <alexisb> master is blocked but maas2 stuff is an exception here
[13:36] <dimitern> alexisb: thanks!
[13:37] <dimitern> voidspace: it looks a lot better: bootstrap ok, switch to admin, add-machine, then add-machine lxd, lxc, kvm to both :0 and :1
[13:38] <dimitern> voidspace: but only machine-1 containers all came up ok and have expected addresses, the ones on machine failed with host machine device "br-eno2" has no address, and I was digging into the logs to figure out why
[13:56] <mup> Bug #1575676 opened: Hard to use non-default LXD bridge <landscape> <juju-core:New> <https://launchpad.net/bugs/1575676>
[13:57] <alexisb> thank you katco !
[13:57] <katco> alexisb: np... happy that we're giving capacity planning a little more attention
[13:57] <katco> alexisb: also revealing future targets :)
[13:58]  * katco begins her morning routine
[14:17] <voidspace> alexisb: ok
[14:18] <voidspace> dimitern: machine-0 ones didn't work?
[14:18] <voidspace> picking up daughter from school
[14:18] <voidspace> back in 15mins
[14:20] <dimitern> voidspace: nope, something's odd, still investigating and adding more logging
[15:00] <voidspace> dimitern: alexisb: frobware: babbageclunk: container support has landed on master
[15:01] <frobware> voidspace: nice work!
[15:01] <babbageclunk> voidspace: awesome!
[15:03] <dimitern> voidspace: great!
[15:03] <dimitern> I'm still debugging the issue on machine-0
[15:03] <voidspace> dimitern: ok
[15:03] <voidspace> dimitern: I'll try adding a node to my maas with two nics and try that
[15:04] <voidspace> dimitern: I've *only* deployed to machine-0
[15:06] <dimitern> voidspace: in the admin model?
[15:06] <voidspace> dimitern: yep
[15:08] <voidspace> dimitern: commissioning an additional node now
[15:09] <alexisb> \o/
[15:12] <voidspace> dimitern: when I commission a node with two nics the second nic comes up as "unconfigured" (no address) whereas the primary nic is "auto assign"
[15:12] <voidspace> dimitern: I can manually change it to auto assign
[15:12] <voidspace> dimitern: if I don't do that then I think I only get a single nic on the container
[15:13] <dimitern> voidspace: otp
[15:17] <voidspace> successfully created a container with two nics on a new machine not in the admin model
[15:24] <mup> Bug #1574809 changed: "to: lxc:0" ignored in bundle <bundles> <juju-release-support> <kanban-cross-team> <landscape> <juju-core:Invalid> <https://launchpad.net/bugs/1574809>
[15:31] <dimitern> voidspace: yeah, you can set them to auto or static (unconfigured physical + auto/static VLAN children won't work though)
[15:31] <dimitern> voidspace: nice! I added more logging and now trying again
[15:47] <babbageclunk> dimitern, voidspace - hmm, trying to add a machine with a space constraint gives a schema error - it looks like the maas response might have changed since we put the constraint matching code in.
[15:48] <babbageclunk> It's returning an array of interface/device ids, not just one.
[15:49] <babbageclunk> I'm going to fix gomaasapi - do you think that just taking the first is the right thing to do? I guess I should ask the MAAS people what it would mean for the result to have more than one value.
[15:50] <dimitern> babbageclunk: can you point me to the code you're talking about (causing the issue)?
[15:52] <babbageclunk> dimitern: https://github.com/juju/gomaasapi/blob/master/controller.go#L810
[15:53] <babbageclunk> dimitern: compared to this response: http://pastebin.ubuntu.com/16083467/
[15:54] <mgz> voidspace: where is the gomaasapi/bootresource.go stuff meant to come from? bootstrapping complains about missing kflavor schema
[15:57] <babbageclunk> mgz - if you do "maas <session> boot-resources read" can you see kflavor in the items that come back/
[15:57] <babbageclunk> ?
[15:58] <mgz> babbageclunk: a bunch of them do, some do not (centos ones)
[15:59] <dimitern> babbageclunk: hmm
[15:59] <dimitern> babbageclunk: so looking at the response you pasted, the schema seems correct
[16:00] <babbageclunk> mgz: that makes it sound like it's an optional field that we didn't know was optional.
[16:00] <mgz> babbageclunk: it does indeed, I'll file a bug?
[16:01] <babbageclunk> mgz: yes please!
[16:01] <babbageclunk> dimitern: will ForceInt accept an array?
[16:03] <dimitern> babbageclunk: I think the ForceInt applies to the values of the StringMap
[16:03] <babbageclunk> dimitern: sure, but the values are lists, right?
[16:04] <babbageclunk> dimitern: I'm going to write a little test to check
[16:04] <dimitern> babbageclunk: i.e. given a {"constraints_by_type":{"storage":{"foo":1,"bar":2}},"interfaces":{"aa":1,"bb:2}} it should parse it
[16:06] <mup> Bug #1575760 opened: Juju switch returns confusing error message <juju-core:New> <https://launchpad.net/bugs/1575760>
[16:06] <babbageclunk> dimitern: but the one coming from maas has "interfaces": {"default": [24]}
[16:07] <dimitern> babbageclunk: you're correct! so specifying "interfaces=foo:space=0" gives me multiple items in the list for "foo"
[16:08] <babbageclunk> dimitern: is that because any of those interfaces are in the right space?
[16:08] <babbageclunk> dimitern: I mean, all
[16:08] <dimitern> babbageclunk: yeah - if you have 1 space only (space-0 a.k.a. default) and you pass that to interfaces, you'll get all nodes back
[16:10] <dimitern> babbageclunk: so I guess it needs to be something like "interfaces": schema.StringMap(schema.List(schema.ForceInt()))
[16:10] <babbageclunk> dimitern: yeah, I think so.
[16:11] <babbageclunk> dimitern: And I think we need to change gomaasapi.ConstraintMatches to have slices of BlockDevice and Interface as well then.
[16:11] <dimitern> babbageclunk: indeed
[16:11] <babbageclunk> dimitern: once it gets into the provider, can we just pick any one of them?
[16:12]  * babbageclunk looks in environ.go for how we use the matches.
[16:12] <dimitern> babbageclunk: and the way ids are handled in the loops below (id := value.(int) -> ids := value.([]int) and range over it)
[16:13] <dimitern> babbageclunk: you mean, if you have more than one interface ID per label?
[16:14] <dimitern> babbageclunk: does not matter if we only want a given space to be accessible on the allocated machine
[16:14] <babbageclunk> dimitern: yeah, actually we only use the constraint matches for storage information.
[16:15] <dimitern> babbageclunk: but why do you need those results from constraintsMap ? the 1.0 code path ignores them as we don't care (i.e. we read all interfaces along with which subnets and spaces they're linked to each time we call NetworkInterfaces())
[16:15] <dimitern> babbageclunk: :) yep
[16:16] <dimitern> we probably should at some point, but so far we don't need it
[16:19] <babbageclunk> dimitern: ok, in the storage case should that just be another loop over the block devices that come back
[16:19] <babbageclunk> ?
[16:20] <dimitern> babbageclunk: I suspect so, but have a look how 1.0 code path does it (and its tests)
[16:20] <babbageclunk> dimitern: context: https://github.com/juju/juju/blob/master/provider/maas/volumes.go#L295
[16:22] <mgz> voidspace, babbageclunk: filed bug 1575768
[16:22] <mup> Bug #1575768: boot resource 2.0 schema check failed: kflavor: expected string, got nothing <bootstrap> <ci> <maas-provider> <juju-core:Triaged> <https://launchpad.net/bugs/1575768>
[16:23] <babbageclunk> dimitern: It was structured differently in the v1 API - looks like it was id -> label, so you could have multiple ids going to the same label
[16:24] <dimitern> babbageclunk: it doesn't look like the 2.0 code path is using physicalblockdevice_set at all
[16:24] <babbageclunk> thanks mgz - I'll start on that now.
[16:24] <babbageclunk> dimitern: no - gomaasapi handles that lookup
[16:28] <babbageclunk> dimitern: in controller.go: parseAllocateConstraintsResponse
[16:30] <babbageclunk> mgz: do you know what MAAS version that is?
[16:31] <mgz> babbageclunk: beta3+bzr4941
[16:32] <babbageclunk> mgz: Thanks.
[16:33] <mgz> it's upgraded from 1.9, which would have done the original image imports
[16:33] <dimitern> babbageclunk: I need to go, but in case it might help, here's a couple of outputs with a set storage constraint on 2.0 (http://paste.ubuntu.com/16084450/) and 1.0 (http://paste.ubuntu.com/16084458/)
[16:34] <babbageclunk> dimitern: thanks! I'm not going to get to fixing it tonight, should fix mgz's issue first
[16:34] <dimitern> mgz: that's a bit too old can't you upgrade to the latest beta4 from the experimental3 ppa?
[16:34] <dimitern> babbageclunk: sounds good, cheers!
[16:35] <babbageclunk> dimitern: mgz: I wasn't sure whether that was something I could demand. :)
[16:35] <dimitern> aw c'mon mgz's a pal :)
[16:35] <babbageclunk> mgz: the version we're working against is beta4+bzr4944
[16:36] <mgz> dimitern: I can, I didn't see an announcement from roaksoax about it
[16:36] <mup> Bug #1575764 opened: Juju doesn't detect lxd container IP address changes <juju-core:New> <https://launchpad.net/bugs/1575764>
[16:36] <mup> Bug #1575768 opened: boot resource 2.0 schema check failed: kflavor: expected string, got nothing <bootstrap> <ci> <maas-provider> <juju-core:Triaged by 2-xtian> <https://launchpad.net/bugs/1575768>
[16:36] <mup> Bug #1575769 opened: Can't "forget" a controller that I've lost access to <juju-core:New> <https://launchpad.net/bugs/1575769>
[16:36] <dimitern> mgz: they don't always mail when they do a point release I think
[16:37] <dimitern> anyway, I'm outta here
[16:37] <babbageclunk> mgz: it has a few bugfixes we need, so I guess you'll need to upgrade anyway.
[16:39] <mup> Bug #1575769 changed: Can't "forget" a controller that I've lost access to <juju-core:New> <https://launchpad.net/bugs/1575769>
[16:39] <mgz> babbageclunk: dist-upgrading first
[16:40] <babbageclunk> mgz: I'll try uploading a centos image to my local MAAS and see if that also leaves out kflavor.
[16:42] <mup> Bug #1575769 opened: Can't "forget" a controller that I've lost access to <juju-core:New> <https://launchpad.net/bugs/1575769>
[16:48] <babbageclunk> mgz: yup, it still leaves out kflavor on my local beta4 one
[16:50] <voidspace> babbageclunk: have you got a fix for that issue?
[16:51] <mup> Bug #1575769 changed: Can't "forget" a controller that I've lost access to <juju-core:New> <https://launchpad.net/bugs/1575769>
[16:51] <babbageclunk> voidspace: I think we just need to mark it optional in the schema.
[16:52] <voidspace> babbageclunk: do you have a branch with that?
[16:52] <babbageclunk> voidspace: The provider doesn't use it - we only care about architectures
[16:52] <babbageclunk> voidspace: not with the change yet - just reproducing the bug.
[16:52] <voidspace> babbageclunk: cool
[16:53] <redir> cherylj: looking
[16:53] <cherylj> redir: at what?
[16:53] <cherylj> what did I say?
[16:53]  * babbageclunk lols
[16:54] <redir> cherylj: at your PR
[16:54] <cherylj> haha
[16:54] <redir> :p
[16:56] <voidspace> babbageclunk: reading scrollback - weird about the device id array
[16:56] <voidspace> babbageclunk: did you ask in the maas folk about that?
[16:57] <voidspace> I've just upgraded to beta4 - was using next-proposed instead of experimental3
[16:58] <mgz> there are too damn many maas ppas
[16:59] <babbageclunk> voidspace: no, haven't yet
[17:00] <babbageclunk> voidspace: but the new way is right - if the mapping's gone from {id: label} to being keyed by label, the values need to be lists
[17:01] <mgz> babbageclunk: I don't see a beta4 in any of the ~maas ppas
[17:01] <mgz> it's in someones private one?
[17:03] <mup> Bug #1575769 opened: Can't "forget" a controller that I've lost access to <juju-core:New> <https://launchpad.net/bugs/1575769>
[17:05] <babbageclunk> mgz: I think it's this one: ppa:maas-maintainers/experimental3
[17:05] <frobware> jam, tych0: PTAL @ http://reviews.vapour.ws/r/4722/
[17:05] <tych0> frobware: oh, derp :)
[17:06] <frobware> tych0: you were doing the same thing?
[17:06] <tych0> no, just that it's a dumb bug on my part
[17:06] <mup> Bug #1575769 changed: Can't "forget" a controller that I've lost access to <juju-core:New> <https://launchpad.net/bugs/1575769>
[17:06] <tych0> i didn't realize Initialize was called more than once, actually
[17:06] <tych0> but it makes sense that it is
[17:08] <tych0> frobware: looks good to me
[17:08] <frobware> tych0: ok, will do some testing tomorrow morning (as master is blocked).
[17:08] <frobware> tych0: thx
[17:09] <tych0> frobware: np, thanks for the fix
[17:12] <mup> Bug #1575794 opened: Agent config format version should be changed for 2.0 <juju-release-support> <tech-debt> <juju-core:Triaged> <https://launchpad.net/bugs/1575794>
[17:15] <voidspace> babbageclunk: mgz: that's the right one - I just had to switch to it
[17:16] <voidspace> babbageclunk: ok, the kflavor ones sounds easier
[17:16] <voidspace> babbageclunk: I can propose that
[17:19] <mgz> babbageclunk, voidspace: similar issue with 'mount_point'
[17:20] <mgz> on filesystem2_0
[17:21] <babbageclunk> voidspace: https://github.com/juju/gomaasapi/pull/48
[17:21] <babbageclunk> voidspace: can you do the mount_point one?
[17:23] <voidspace> babbageclunk: gah, you beat me to it
[17:23] <babbageclunk> sorry!
[17:23] <voidspace> babbageclunk: mount_point needs to be optional?
[17:23] <mgz> what command is this coming from?
[17:23] <voidspace> babbageclunk: I fixed it by supplying a default instead
[17:24] <babbageclunk> voidspace: oh, that's nicer
[17:24] <mup> Bug #1575794 changed: Agent config format version should be changed for 2.0 <juju-release-support> <tech-debt> <juju-core:Triaged> <https://launchpad.net/bugs/1575794>
[17:24] <mgz> hm, block-device, which needs a machine
[17:25] <voidspace> babbageclunk: https://github.com/juju/gomaasapi/compare/master...voidspace:maas2-kflavor-optional
[17:25] <voidspace> babbageclunk: and then you always get a value even if it's missing
[17:26] <voidspace> mgz: I can make mount_point optional in filesystem
[17:26] <babbageclunk> voidspace: yeah - do that instead
[17:26] <voidspace>  babbageclunk ok, I'll add making mount_point optional in the same branch
[17:26] <mgz> voidspace: some of my filesystems are null
[17:27] <babbageclunk> mgz: you should be able to see it with machines read
[17:27] <voidspace> the whole filesystem?
[17:28] <voidspace> mgz: what should we default to for mount_point: "/" ?
[17:28] <mgz> voidspace: http://paste.ubuntu.com/16085749
[17:28] <babbageclunk> voidspace, mgz: sorry, I have to head home
[17:29] <voidspace> I have to go in five minutes too
[17:29] <voidspace> mgz: when you say "some of my filesystems are null" you mean mount_point, label and mount_options being null
[17:29] <voidspace> ah no
[17:29] <voidspace> the whole filesystem is null
[17:29] <voidspace> geez
[17:29] <mgz> :)
[17:29] <voidspace> mgz: this is now a tomorrow problem, sorry
[17:30] <voidspace> wife is calling me to dinner
[17:30] <mgz> voidspace: I'll file you a bug son
[17:30] <voidspace> mgz: can you link to this pastebin on it please
[17:30] <mgz> will also put up a non-voting job for maas 2.0
[17:30] <mup> Bug #1575794 opened: Agent config format version should be changed for 2.0 <juju-release-support> <tech-debt> <juju-core:Triaged> <https://launchpad.net/bugs/1575794>
[17:30] <mgz> to avoid cursing on this stuff
[17:30] <voidspace> mgz: much appreciated - thanks
[17:30] <voidspace> mgz: yeah
[17:31] <voidspace> weird-ass maas configuration
[17:32] <voidspace> right, dinner
[17:32] <voidspace> sorry
[17:36] <mup> Bug #1575797 opened: AddressableContainerSetupSuite.TestContainerInitialised lxc-net: no such file or directory <arm64> <centos> <ci> <regression> <test-failure> <unit-tests> <juju-core:Triaged> <https://launchpad.net/bugs/1575797>
[18:00] <mup> Bug #1575808 opened: filesystem 2.0 schema check failed: mount_point: expected string, got nothing <bootstrap> <ci> <maas-provider> <juju-core:Triaged> <https://launchpad.net/bugs/1575808>
[18:03] <mup> Bug #1575808 changed: filesystem 2.0 schema check failed: mount_point: expected string, got nothing <bootstrap> <ci> <maas-provider> <juju-core:Triaged> <https://launchpad.net/bugs/1575808>
[18:06] <mup> Bug #1575808 opened: filesystem 2.0 schema check failed: mount_point: expected string, got nothing <bootstrap> <ci> <maas-provider> <juju-core:Triaged> <https://launchpad.net/bugs/1575808>
[18:31] <redir> ericsnow: you around?
[18:31] <ericsnow> redir: yep
[18:31] <redir> can I borrow your eyes for a minute?
[18:32] <redir> ericsnow: ^^
[18:33] <ericsnow> redir: sure
[18:33] <redir> ericsnow: am in moonstone
[19:56] <natefinch> uhh... redir, cherylj, are the tests supposed to pass on xenial?
[19:57] <natefinch> I'm getting a lot of this:  obtained string = "xenial"... expected string = "trusty"
[19:59] <natefinch> katco, ericsnow ^ ?   This is just running tests on master
[19:59] <katco> natefinch: what does dist-info --lts return for you?
[20:00] <ericsnow> natefinch: I don't believe we've landed any fixes for that yet
[20:00] <katco> natefinch: sorry distro-info --lts
[20:00] <ericsnow> natefinch: redir is working on a comprehensive patch
[20:00] <natefinch> ahh ok
[20:00] <natefinch> katco: xenial
[20:01] <mup> Bug #1575895 opened: juju loses apt-http/s-proxy information if a model is deleted and a new one created <juju-core:New> <https://launchpad.net/bugs/1575895>
[20:04] <redir> natefinch: getting close with some help from ericsnow just now. Making sure it works then reviewing previous commits to see if this works on those and reverting them to keep things uniform.
[20:04] <redir> Hopefully done RSN(tm)
[20:04] <natefinch> redir: \o/
[20:05] <redir>  /o\
[20:38] <cmars> ah, resources are awesome
[20:39] <natefinch> cmars: glad you like them.  I do think they're pretty great
[20:39] <cmars> natefinch, updating my mattermost charm to use them
[20:39] <natefinch> cmars: nice!
[20:40] <natefinch> cmars: let us know if there's any problems or unexpected behavior
[20:40] <katco> cmars: :D
[21:18] <perrito666> wallyworld: ping me when you are around please
[21:28] <wallyworld> perrito666: hey. just about to go into a meeting
[21:29] <perrito666> k
[21:37] <mup> Bug #1575940 opened: LXC containers under MAAS get no "search <domain>" entry in resolv.conf when deployed with juju2 <juju-core:New> <https://launchpad.net/bugs/1575940>
[22:04] <alexisb> menn0, ping
[22:04] <menn0> alexisb: hey hey
[22:05] <alexisb> are you available to join the leads call
[22:06] <menn0> alexisb: ah crap... sorry
[22:10] <cherylj> davecheney: ping?
[22:19] <perrito666> wallyworld: lemme know if you have a spot before the standup
[22:20] <wallyworld> perrito666: stuck in meetings, will let you know. may have to move standup depending on how meetings go
[22:20] <perrito666> k
[23:04] <wallyworld> perrito666: axw: anastasiamac_: redir: quick standup between meetings?
[23:06] <cherylj> redir: will you need to coordinate with CI to not hack distro-info for your PR?
[23:07] <redir> cherylj: If I have this right it should pass as the bots are, and when they unhack them as well.
[23:07] <cherylj> redir: sweet!
[23:57] <redir> so master is blocked
[23:57] <redir> should I target something else for a PR?