[00:04] <anastasiamac> wallyworld: thumper:axw:babbageclunk: PTAL https://github.com/juju/juju/pull/7143, fixes a bug :D
[00:04] <anastasiamac> more like a gap than a broken functionaility...
[00:06] <babbageclunk> anastasiamac: just having lunch, but I'll take a look afterwards (if someone else doesn't!)
[00:07] <anastasiamac> babbageclunk: \o/
[00:17] <wallyworld> anastasiamac: babbageclunk: i'm not sure we've agreed to the approach yet. it's under discussion via email
[00:18] <wallyworld> we need to get agreement what they want to do is supported and correct first
[00:18] <anastasiamac> wallyworld: obviously not parties are on this email trail.... maybe discussing it in the bug will be better/more effective means as communication
[00:19] <axw> anastasiamac: reviewing
[00:19] <wallyworld> anastasiamac: agreed in principal. but we don't want to polluate the bug with lots of back and forth. the summarised outcomes can be added though
[00:19] <axw> wallyworld: this change is unintrusive, I don't think we need to have any more discussion before landing this particular change
[00:20] <axw> wallyworld: this is an alternative to what was being proposed, which was adding pre-populated relation settings
[00:21] <wallyworld> axw: that is true. but i was concerned it is a solution to a problem they didn't need to have if things were deployed the recommended way. i'd have to re-read the email trail
[00:23] <axw> wallyworld: ehh except there's some weirdness in the PR, so maybe I'm still misunderstanding the issue.
[00:23] <wallyworld> right
[00:23] <wallyworld> i'm hesitant because i'm not sure w'ere all on the same page
[00:26] <axw> wallyworld: yeah I'll continue discussions.
[00:28] <anastasiamac> wallyworld: sure but now that the PR is up, email communication is not best, especially if it excludes ppl that r blocked byy the bug and r proposing solutions
[00:31] <wallyworld> anastasiamac: the bug is not the place to have detail design discussions. status updates etc sure
[00:32] <wallyworld> or steps to repro etc etc
[00:41] <axw> anastasiamac wallyworld: I'm taking the discussion to the PR.
[00:41] <wallyworld> yup, +1
[00:41] <axw> and will take it back to email if that becomes unwieldy
[02:44] <wallyworld> axw: FYI, as discussed, this is the CDO vsphere bug https://bugs.launchpad.net/juju/+bug/1669483
[02:44] <mup> Bug #1669483: [2.1] juju bootstrap fails when there is no VM in vsphere datacenter or all VMs are in folders <cdo-qa-blocker> <oil> <oil-2.0> <vsphere> <juju:Triaged> <https://launchpad.net/bugs/1669483>
[02:45] <axw> wallyworld: okey dokey
[02:46] <axw> wallyworld: might be hard to test, since larry is away
[02:46] <axw> I don't think I should be deleting existing VMs
[02:46] <wallyworld> yeah, best effort and all that
[03:52] <cmars> hi, i have a fix for LP:#1675214. can i get a review? https://github.com/juju/juju/pull/7147
[03:52] <mup> Bug #1675214: destroy-model failed because could not determine model SLA level <ci> <destroy-model> <regression> <juju:In Progress by cmars> <https://launchpad.net/bugs/1675214>
[03:56] <thumper> jam: to be honest, I think we don't care for the use case you mentioned
[03:56] <thumper> not really, not now
[03:57] <thumper> however, if you think we do, I could add a txn-revno assert back in
[03:57] <thumper> jam: we do do a txn-revno assert in 2.x
[04:07] <wallyworld> cmars: looking
[04:07] <cmars> wallyworld, thanks!
[04:09] <wallyworld> cmars: yeah, or account for the facade version for each model - won't be too hard to do that
[04:09] <wallyworld> lgtm for the temp fix - just code deletion really
[04:10] <cmars> wallyworld, ok thanks!
[04:11] <wallyworld> babbageclunk: not sure if you are able to squeeze in a review before your EOD https://github.com/juju/juju/pull/7144
[04:13] <stokachu> first cut of conjure-up on macOS done \o/
[04:13] <babbageclunk> wallyworld: that's a tiny one! looking now
[04:13] <wallyworld> babbageclunk: that's what all the girls say too :-)
[04:14] <wallyworld> stokachu: well done!
[04:14] <stokachu> wallyworld: hopefully that'll increase our userbase by a lot
[04:15] <stokachu> i need to look into xhyve though for localhost deployments
[04:15] <stokachu> like docker does
[04:15] <wallyworld> stokachu: maybe? how many of our target audience  ueses macs? i personally hate them
[04:15] <stokachu> wallyworld: good question, im not sure
[04:15] <stokachu> word is though all the conferences people use macs
[04:15] <stokachu> kubecon etc
[04:15] <wallyworld> interesting
[04:16] <wallyworld> we should collect stats on that
[04:16] <stokachu> we do
[04:16] <babbageclunk> definitely true at Python conferences I've been to
[04:16] <stokachu> nice, yea i think having a localhost deployment mechanism will be handy
[04:16] <stokachu> basically xhyve to boot ubuntu
[04:17] <stokachu> then do some magic there to wire it up
[04:18] <stokachu> or vsphere would be nice here too i think
[04:37] <babbageclunk> wallyworld: reviewed
[04:38] <jam> babbageclunk: so I think we do need to have a better primary key than CIDR for subnets, but probably not worth you fixing right now. (you can't fix all the bugs in networking on your own :)
[04:41] <babbageclunk> jam: :) fair enough!
[04:44] <wallyworld> jam: that's exactly what i sid too :-)
[04:44] <wallyworld> babbageclunk: thanks for review
[04:45] <jam> babbageclunk: and my other point was "we won't really know if we have the right data until we actually go to *use* the data", (we're only recording it with your patch)
[04:45] <jam> but rough glance looks like its the right thing, and we can iterate from here.
[04:46]  * jam takes the dog out
[04:50] <wallyworld> babbageclunk: i replied to one of you comments, see if if makes sense?
[05:02] <axw> jam: 1:1? wallyworld is here too
[07:36] <mup> Bug #1468752 changed: "juju ssh" adds an additional strings to all commands when used on Windows, in interactive mode <ssh> <windows> <juju:Fix Released by
[07:36] <mup> gz> <juju 2.0:Fix Released by gz> <juju 2.1:Fix Released by gz> <juju-core:Won't Fix> <juju-core 1.25:Won't Fix> <https://launchpad.net/bugs/1468752>
[07:36] <mup> Bug #1616149 changed: Incompatible protocol between older client and candidate server <ci> <regression> <test-failure> <juju-core:Won't Fix> <juju-core 1.25:Won't Fix> <https://launchpad.net/bugs/1616149>
[07:36] <mup> Bug #1637267 changed: Juju fails to restore state-server on xenial <ci> <juju-core:Won't Fix> <juju-core 1.25:Won't Fix> <https://launchpad.net/bugs/1637267>
[07:48] <mup> Bug #1616832 changed: stuck rsyslogd causes mongodb to block <eda> <needs-ci-test> <sts> <juju:Triaged> <juju-ci-tools:Triaged> <juju-core:Won't Fix> <juju-core 1.25:Won't Fix> <https://launchpad.net/bugs/1616832>
[09:07] <wallyworld> axw: you happy to go with "not supported" initially for nova networks and subnets in heather's PR ?
[09:11]  * axw looks
[09:13] <axw> wallyworld: hm. not sure, I'll need to check the behaviour of the code that calls Subnets
[09:13] <wallyworld> axw: yeah, if the interface claims support and then the other methods error, might not be good
[09:26] <axw> wallyworld: have the changes to discover subnets already been made
[09:26] <axw> ?
[09:27] <wallyworld> axw: in the worker, yeah
[09:27] <axw> oh yeah
[09:29] <axw> wallyworld: we at least need to look for NotSupported in the discoverspaces worker, in discoverSubnetsOnly
[09:29] <wallyworld> axw: yeah, i'd rather the provider not lie to the worker though
[09:31] <axw> wallyworld: welp, the only other option I guess is to return separate Environ implementations when nova and neutron are supported. I'm not sure if that's feasible though, because opening an an Environ is not supposed to make any API calls
[09:32] <wallyworld> yeah, also true. maybe handle not supported in the worker with a todo to fix the openstack provider to return subnets for nova
[09:32] <axw> wallyworld: yep
[09:33] <axw> wallyworld: FWIW, I'd prefer if we had an Environ.Networker method, which every Environ was required to implement. it would return an Environ or a NotSupported error
[09:33] <wallyworld> no argument from me there
[09:33] <axw> wallyworld: and then Networker would have methods for checking support for subnets, spaces, etc.
[09:33] <wallyworld> yep
[09:33] <wallyworld> i don't like the current implementation
[12:30] <jam> wpk: ping
[12:32] <wpk> jam: pong
[12:39] <jam> hi wpk, I wanted to go over some of the key bugs, though if you want it can wait until standup I suppose
[12:39] <jam> I'm going to be gone over the weekend, so I was hoping to chat with you about some next steps
[12:43] <wpk> I'm ready, should we talk here or maybe just join standup hangout now?
[12:46] <jam> sure, brt
[12:47] <jam> wpk: i'm there now
[13:21] <jam> wpk: https://github.com/juju/juju/pull/7119 reviewed
[13:38] <jam> sinzui: what triggers someone to get an "affiliated" icon in Launchpad?
[13:39] <jam> I'd like to get WPK a Juju sticker so that I don't accidentally pick some other Witold
[13:39] <sinzui> wow you challenge me
[13:40] <sinzui> jam: I think it is show when the user is a member of the owner or driver teams.
[13:40] <jam> well, he's in '~juju-core' afaict
[13:41] <sinzui> jam, we forgot to add him to ~juju
[13:41] <jam> but it looks like there is ~juju-hackers he wasn't part of
[13:41] <jam> I just did
[13:41] <jam> "Juju Hackers" aka ~juju
[13:41] <jam> sinzui: thanks for the pointer
[13:42] <jam> sinzui: btw wpk's current branch https://github.com/juju/juju/pull/7119 is likely to want a feature tests
[13:42] <jam> or an update to whatever we currently have that 'apt-proxy' works
[13:42] <jam> anyway I'm out for a bit
[13:43] <sinzui> jam, yep, that was the one I was curious about. I reported bug 1635633 and am eager to close it
[13:43] <mup> Bug #1635633: assess_proxy does not test apt proxies <gap> <proxy> <juju-ci-tools:Triaged> <https://launchpad.net/bugs/1635633>
[20:51] <wallyworld> babbageclunk: did you see bug 1675546?
[20:51] <mup> Bug #1675546: container networking broken in GCE <ci> <gce-provider> <lxd> <network> <regression> <juju:Triaged by 2-xtian> <https://launchpad.net/bugs/1675546>
[22:02] <rick_h> wallyworld: anything to chat on today?
[22:02] <wallyworld> rick_h: not as such. very happy about the latest memory profile
[22:16] <rick_h> wallyworld: +1
[22:17] <babbageclunk> wallyworld: yup, chasing it, but had to rush off to the doctor - back now.
[22:17] <wallyworld> ty
[22:18] <wallyworld> we will release beta1 regardless
[22:25] <wpk> I'm having problems with bootstraping on maas, I'm constantly getting
[22:25] <wpk> /var/lib/juju/nonce.txt does not exist
[22:25] <wpk> 23:23:13 DEBUG juju.utils.ssh ssh.go:292 using OpenSSH ssh client
[22:25] <wpk> packet_write_wait: Connection to 10.2.15.254 port 22: Broken pipe
[22:28] <wpk> any ideas on what might I be doing wrong?
[22:41] <menn0> wpk: can you give a bit more context? is this with real hardware or vmaas?
[22:41] <babbageclunk> wallyworld: the bug is because the juju-qa env is a legacy network, so network interfaces are returned with no subnet. It looks like I can get everything I need off the network in that case - doing that.
[22:44] <sinzui> babbageclunk: interesting. We/me also has an ancient aws account
[22:45] <wpk> menn0: real hardware, PC + 2 NUCs with AMT as nodes. I'm doing juju bootstrap maastiff, and as I understand it SSHs to the node, installs all the stuff, reboots it, and then SSHs to it again just to fail on the above, then decomissions it
[22:45] <babbageclunk> sinzui: yeah, that's part of the problem - new accounts wouldn't have this kind of network as the default
[22:46] <babbageclunk> wpk: can you deploy a node in maas without juju?
[22:46] <menn0> wpk: seems something is up with SSH on the host causing it to drop the SSH connection attempt. is it possible to get the sshd logs on that host?
[22:47] <wpk> babbageclunk: yes, no problem with that
[22:47] <wpk> menn0: it gets decomissioned before I have a chance to get to it :/
[22:48] <menn0> wpk: try adding --keep-broken to the juju bootstrap command
[22:48] <menn0> wpk: that should keep the system around
[22:48] <wpk> menn0: ok
[22:48] <wpk> https://pastebin.canonical.com/183603/ that's the whole log
[22:52] <sinzui> wpk: your localhost cannot ssh to that address. As menn0 says try --keep-broken to keep it up
[22:53] <sinzui> wpk: while juju is bootstrapping, you *should* be able to ssh in as ubuntu@<ip>
[22:54] <wpk> I am
[22:54] <sinzui> wpk: you are sshed in?
[22:54] <sinzui> if so, use -v to see what key works.
[22:55] <sinzui> you can force the juju key using -i $JUJU_DATA/ssh/juju_id_rsa
[23:26] <wallyworld> wpk: there's a bug or 2 where this issue is discussed; usually the cause is a set up issue, see last comment or 2 on https://bugs.launchpad.net/juju-core/+bug/1314682
[23:26] <mup> Bug #1314682: Bootstrap fails, missing /var/lib/juju/nonce.txt (containing 'user-admin:bootstrap') <bootstrap> <juju> <maas-provider> <juju:Expired> <juju-core:Won't Fix> <https://launchpad.net/bugs/1314682>
[23:27] <wallyworld> wpk: also https://ask.openstack.org/en/question/59760/juju-bootstrap-failed/
[23:29] <wpk> sinzui: I was able to ssh in, using /home/wpk/.local/share/juju/ssh/juju_id_rsa key, and /var/lib/juju/nonce.txt exists on this node
[23:31] <wpk> sinzui: the nide has Internet access and dns resolution working
[23:43] <wpk> wallyworld: nothing worrying in cloud-init.log
[23:44] <wpk> hm, except for this:
[23:44] <wpk> 2017-03-23 23:28:12,171 - util.py[DEBUG]: Running module apt-configure (<module 'cloudinit.config.cc_apt_configure' from '/usr/lib/python3/dist-packages/cloudinit/config/
[23:44] <wpk> cc_apt_configure.py'>) failed
[23:44] <wpk> (...)
[23:44] <wpk> ValueError: Old and New apt format defined with unequal values True vs False @ apt_preserve_sources_list
[23:45] <wallyworld> that would do it
[23:48] <wpk> wallyworld: and what's the cause and how to fix it?
[23:49] <wallyworld> wpk: i have no idea off hand - it's an issue outside of juju and maas from whay i can see. you'd need to google the error and fix your apt config
[23:50] <wallyworld> but if cloud init doesn't complete, you'll see the nonce error
[23:50] <wallyworld> so you need to fix whatever is stopping cloud init from running properly
[23:53] <wpk> wallyworld: but why there's the nonce error if the file is there?
[23:53] <wpk> https://bugs.launchpad.net/cloud-init/+bug/1646571
[23:53] <mup> Bug #1646571: apt failures non fatal, but cloud the log <landscape> <cloud-init:Incomplete> <MAAS:Confirmed> <https://launchpad.net/bugs/1646571>
[23:54] <wpk> (and as it says - it's not fatal, cloud-init continues after that)
[23:55] <wallyworld> without digging into the code and analysing logs etc, there's no way to tell. we'll need to devote time to looking into it
[23:55] <wallyworld> the bug you link above indicates a maas issue
[23:56] <wallyworld> can you add extra info from your sitution to the bug?
[23:57] <wpk> wallyworld: I will, tomorrow (1AM here)
[23:57] <wallyworld> thanks