[00:20] <anastasiamac> menn0: wallyworld: txn-revno related bug 1484105
[00:20] <mup> Bug #1484105: juju upgrade-charm returns ERROR state changing too quickly; try again soon <bug-squad> <canonical-is> <upgrade-charm> <upgrade-juju> <juju-core:Fix Released> <https://launchpad.net/bugs/1484105>
[00:21] <wallyworld> that's the one
[00:25] <menn0> anastasiamac: thank you
[00:26] <anastasiamac> menn0: wallyworld: anytime \o/
[00:36] <menn0> wallyworld: i've assigned that maas apt proxy one to you
[00:40] <babbageclunk> menn0: review plz? https://github.com/juju/juju/pull/6974
[00:41] <wallyworld> babbageclunk: easiest review eva https://github.com/juju/juju/pull/6975
[00:41] <babbageclunk> wallyworld: looking
[00:42] <babbageclunk> wallyworld: I mean, I've seen shorter, but that was pretty easy. LGTM'd!
[00:43] <wallyworld> ty
[00:43] <wallyworld> you say that to all the boys
[00:43] <menn0> babbageclunk: looking
[00:46] <babbageclunk> menn0: ta
[00:48] <menn0> babbageclunk: great PR description! regarding your QA steps I would test with a charm that uses resources and ensure that those downloads go through the proxy
[00:48]  * menn0 tries to remember a good charm to test with
[00:49] <babbageclunk> menn0: ok - yeah, I was about to ask that
[00:49] <menn0> babbageclunk: there *is* a good one - I used it for testing migration of resources
[00:50] <wallyworld> menn0: tiny PR - prereq for maas apt proxy issue https://github.com/juju/utils/pull/267
[00:51] <menn0> wallyworld: nice. will look soon.
[00:51] <wallyworld> the juju one wil lalso be 2 lines :-)
[00:52] <menn0> babbageclunk: the mattermost charm uses resources
[00:52] <menn0> babbageclunk: that's a good one to test with
[00:52] <babbageclunk> menn0: Ah, great, thanks/
[00:53] <menn0> wallyworld: ship it
[00:53] <wallyworld> ty
[00:53] <babbageclunk> menn0: how can I get the download to happen a second time? Oh, I guess the first charm download should just not be mattermost.
[00:54] <wallyworld> menn0: there were no tests for those fie names
[00:54] <menn0> babbageclunk: yeah... once it's cached in the controller it'll keep using the cached version
[00:58]  * babbageclunk goes for a run
[01:05] <babbageclunk> anastasiamac: Thanks for updating the bug with the PR - just came back to do the same thing!
[01:06]  * babbageclunk really goes for a run
[01:06] <anastasiamac> babbageclunk: :)
[01:06] <blahdeblah> Really actually running is a lot better for you than just intending to run & then not doing it. :-)
[01:07] <wallyworld> menn0: another 2 liner https://github.com/juju/juju/pull/6976
[01:08] <menn0> wallyworld: ship it
[01:09] <wallyworld> ta
[01:09] <menn0> wallyworld: don't forget develop
[01:10] <menn0> babbageclunk: so much lovely copy pasta :)
[01:13] <thumper> should we just do a bigger merge of 2.1 into develop as we near release?
[01:13] <thumper> that way not everyone has to worry about every merge
[01:25] <anastasiamac> thumper: menn0: +1 on merge from 2.1 into develop. jam is doing it almost daily
[01:25] <anastasiamac> thumper: menn0: this also eliminates the need to add bugs to 2.2 series. it's noise! it is expected that whatever is addressed on 2.1 will go into 2.2
[01:26] <anastasiamac> addition of 2.2 series only makes sense if *implementation* will change btw 2.1 and 2.2
[01:30] <menn0> anastasiamac: sgtm
[01:44] <menn0> babbageclunk: review done. sorry for delay. lots of interrupts.
[01:45] <anastasiamac> thumper: wallyworld: menn0: for allocation... would be awesome to have snap bin in $PATH - originally triaged to 2.2 coz life... bug 1660273
[01:45] <menn0> babbageclunk: a few little things, depends on your QA as well of course
[01:45] <mup> Bug #1660273: `juju run` does not include /snap/bin in $PATH <juju:Triaged> <https://launchpad.net/bugs/1660273>
[01:49] <thumper> anastasiamac: seems like the host didn't have /snap/bin in the PATH
[01:49] <thumper> we don't do anything special with PATHs here
[01:49] <anastasiamac> thumper: it has been seen by different ppl. we need an answer
[01:49] <anastasiamac> thumper:  the most recent ne was from stub
[01:50] <anastasiamac> one*
[01:50] <thumper> my answer is that it isn't juju's job to manage the snap path
[01:50] <thumper> who knows about snaps?
[01:51] <anastasiamac> k. i guess balloons for us?...
[01:59] <stokachu> i do
[01:59] <stokachu> so xenial server contains /snap/bin in $PATH but the cloud images do not
[02:00] <stokachu> probably easier to go that route if you need it included
[02:00] <anastasiamac> stokachu: note on the bug would be awesome \o/ do we need to get CPC team involved?
[02:01] <stokachu> anastasiamac, yea probably talk to slangasek about getting it added
[02:01] <axw> wallyworld thumper menn0 anastasiamac: do any of you have access to any non-x86 machines that I can test manual provisioning on?
[02:01] <stokachu> anastasiamac, which bug?
[02:01] <stokachu> https://launchpad.net/bugs/1660273?
[02:01] <mup> Bug #1660273: `juju run` does not include /snap/bin in $PATH <juju:Triaged> <https://launchpad.net/bugs/1660273>
[02:01] <thumper> axw: sorry, no
[02:01] <menn0> axw: I do not
[02:02]  * axw looks at qemu with resignation
[02:02] <wallyworld> :-(
[02:02] <axw> that's a bad word isn't it
[02:04] <anastasiamac> stokachu: yes. (I *think* i marked all related to it as duplicates..  there shouldn't b others floating around)
[02:05] <anastasiamac> axw: no :( maybe QA team does?
[02:05] <axw> oh yes of course
[02:05] <axw> anastasiamac: thanks
[02:05] <anastasiamac> axw: \o/
[02:05] <axw> veebers: do you have a non-x86 machine I can test manual provisioning on?
[02:07] <veebers> axw: I don't, I'm not sure what hardware CI might have available for such a task either, I can find out for you
[02:08] <axw> veebers: if you would that'd be great, thanks
[02:09] <veebers> axw: can do, will probably be tomorrow before we get the info though
[02:09] <axw> veebers: okey dokey
[02:09] <axw> veebers: I'll look at using a public cloud provider for now, but will be good to know for future
[02:12] <veebers> axw: ack, sorry I didn't know off-hand :-P
[02:13] <axw> veebers: no problem, thank you
[02:37] <axw> whoa, develop is blessed
[02:47] <balloons> veebers, the jenkins slaves can be used as needed for non-x86 hardware. What does axw need?
[02:47] <axw> balloons: anything will do
[02:47] <axw> arm64?
[02:47] <balloons> anything? axw, there's also the porter's boxes
[02:47] <axw> balloons: the what now?
[02:47] <axw> oh OS porters?
[02:47] <balloons> right
[02:48] <axw> balloons: how does one get access? I want to run juju on the host, and provision a LXD container in it
[02:48] <menn0> babbageclunk: easy one: https://github.com/juju/juju/pull/6977
[02:48] <balloons> axw, anyways, what do you want to do on the machine?
[02:48] <babbageclunk> menn0: looking
[02:49] <balloons> axw, cloud-city is your ticket to getting in; look at the ssh config in that repo, along with the key you need to ssh in
[02:49] <axw> balloons: ok thanks. I already spun up a host on Packet, but will have a look there next time
[02:49] <balloons> axw, I was poking veebers since it would be useful for him to know this :-)
[02:50] <balloons> But it would be useful for the devs to know it as well
[02:50] <axw> okey dokey
[02:50] <veebers> balloons: indeed, thanks for that I'll make sure to remember for the future :-)
[02:50] <balloons> veebers, happy belated birthday.. must be almost 2 days late now eh? But it's your birthday here!
[02:51] <veebers> balloons: heh, only 1 day. Thanks! ^_^
[02:51] <anastasiamac> veebers: \o/ HB!!
[02:51] <veebers> anastasiamac: thanks :-)
[02:52] <axw> veebers: happy birthday :)
[02:52] <veebers> thanks axw
[02:56] <axw> so I have Juju running on a machine with 96 ARM64 cores, 128GB DDR4 ECC RAM. fun
[03:02] <babbageclunk> veebers: Happy birthday! For yesterday!
[03:12] <veebers> cheers babbageclunk
[03:16] <veebers> axw: just saw your email, 96 cores! nice
[03:19] <axw> veebers: I'll file the bug
[03:21] <veebers> axw: ah re: cores not showing the correct value. sweet
[03:47] <babbageclunk> menn0: yay, proxy stuff looks good - it's quite fun watching all the requests scroll past in the log
[03:47] <babbageclunk> menn0: What did you want me to look out for wrt resources?
[03:49] <menn0> babbageclunk: just that the resource download also goes through the proxy when you expect it to
[03:49] <menn0> babbageclunk: I guess if it's TLS, it's hard to tell?
[03:49] <menn0> babbageclunk: they come from the charm store
[03:51] <babbageclunk> menn0: but that wouldn't be installed until after the charm software?
[03:52] <menn0> babbageclunk: that's right. the resource gets pulled when the first unit requests it.
[03:53] <babbageclunk> menn0: oh, just saw some stuff for api.jujucharms.com - presumably that was it (since the charm code itself would have been downloaded before the deploy started).
[03:54] <babbageclunk> menn0: ok, I think that's right.
[03:57] <menn0> babbageclunk: sounds good! nice work.
[04:19] <axw> jam: I've updated https://github.com/juju/juju/pull/6970 with a fix for the arch thing, PTAL when you can
[04:19] <axw> (also responded to your other questions/comments)
[04:20] <axw> wallyworld: did you see my replies on https://github.com/juju/juju/pull/6970? are your concerns allayed?
[04:37] <jam> axw: we should probably just chat about it quickly
[04:37] <jam> as I don't think I conveyed my thoughts well, given your replies
[04:37] <axw> jam: ok
[04:38] <axw> jam: https://hangouts.google.com/hangouts/_/canonical.com/axw-jam?authuser=1
[04:38] <axw> jam: or we can IRC if you prefer
[04:38] <jam> ho, just give me a sec
[06:00] <axw> jam: just thinking about the Arch thing a bit more. it's possible for InstanceConfig to have tools for multiple arches, so we can't set an overall Arch on entry. the provider gets to choose which arch to start. for LXD, we filter it down to the host arch before passing the tools.List in
[06:00] <axw> jam: I'll leave a comment explaining that where I've used the AgentVersion method
[06:00] <axw> jam: alternatively I can just call HostArch, that might be clearer
[06:02] <jam> axw: I'm happy with HostArch, but a comment is probably useful as well
[06:02] <axw> jam: will do
[07:00] <axw> jam: ah, NewKvmBroker is the one you're going to delete. sorry for the noise
[07:00] <jam> axw: yhea
[07:01] <jam> yehaa? anyway, np
[07:12] <wallyworld> axw: sorry, missed your msg
[07:16] <axw> wallyworld: np, I merged it anyway :p
[07:16] <wallyworld> yeah i read the comments
[07:24] <mup> Bug #1664359 changed: Authentication fails for juju 1.25.6 on aws <juju-core:Invalid> <https://launchpad.net/bugs/1664359>
[07:43] <axw> anastasiamac_: I can't repro https://bugs.launchpad.net/juju/+bug/1539684 in 2.1. what's the protocol, mark as Invalid and say to reopen if it's still an issue?
[07:43] <mup> Bug #1539684: storage-get unable to access previously attached devices <canonical-bootstack> <storage> <juju:Triaged> <https://launchpad.net/bugs/1539684>
[08:33] <anastasiamac_> axw: no protocol - depends on the bug :) if the issues is suspected to b fixed, makr as Fixed Committed
[08:34] <axw> anastasiamac_: ok
[08:34] <anastasiamac_> axw: if noone touched the functionality, quirks in setup, etc, then Invalid (if we won't fix)
[08:34] <anastasiamac_> or incomplete if we need more info
[08:34] <axw> anastasiamac_: well the code was overhauled in 2.0 (actually 1.26)
[08:34] <axw> anastasiamac_: so could well be a fix fell out of that
[08:34] <anastasiamac_> axw: so most likely its Fixed :)
[08:34] <anastasiamac_> axw: yes
[08:34] <axw> anastasiamac_: I'll mark as Fix Committed with a comment to that effect
[08:35] <anastasiamac_> axw: my hero \o/
[08:46] <axw> jam: can you please take a look at https://github.com/juju/juju/pull/6980?
[08:48] <jam> axw: fwiw, I had submitted https://bugs.launchpad.net/juju/+bug/1654943 but it seems your bug predates mine
[08:48] <mup> Bug #1654943: cloud init script should have better preference for IP addresses for agent binaries <containers> <network> <spaces> <juju:Triaged> <https://launchpad.net/bugs/1654943>
[08:49] <axw> jam: ah, I'll reference that in the TODO then
[08:49] <axw> oh but you already made it a dup
[08:49] <axw> jam: I think we should leave that one open for the final fix
[08:50] <jam> axw: either way, I marked it a duplicate, but if we want to leave mine open as a "correct fix" vs yours as the "quick timeout" that's fine with me
[08:50] <axw> yeah, I'll make the change
[08:50] <jam> axw: we don't have a test anywhere of the command we create for curl? it seems like just getting the command string and asserting it, with annotations in the test as to why we want all the parts?
[08:51] <axw> jam: we do, but it's not checking all the flags
[08:51] <axw> I'll update before landing
[08:54] <axw> jam: pushed again with test updated
[09:36] <jam> btw, approved
[09:36] <jam> axw: ^^ forgot to ping you
[09:36] <axw> jam: thanks
[16:09] <rogpeppe> anyone around to give a review of this, please? https://github.com/juju/juju/pull/6964
[16:12] <rick_h> perrito666: ^
[16:30] <perrito666> rick_h: rogpeppe just returning from lunch, ill take a look
[23:05] <axw> thumper: can you please review https://github.com/juju/juju/pull/6982?
[23:09] <thumper> shipit
[23:09] <axw> gracias
[23:18] <menn0-busy> anastasiamac_: so bug 1664409 certainly looks like a networking issue
[23:18] <mup> Bug #1664409: juju 2.1-beta5 - juju 2.1rc2 - localhost failing to allocate a nested container with an ip <conjure> <regression> <juju:Triaged> <juju 2.1:Triaged> <https://launchpad.net/bugs/1664409>
[23:19] <menn0> anastasiamac_: jam's theory about conjure-up workarounds fighting what juju is doing (now that it does things better) seems plausible
[23:20] <menn0> anastasiamac_: aside from already having too much on his plate, jam is best placed to deal with it
[23:20] <anastasiamac_> menn0: the question is - do we fix it on our side or conjure-up? do we have a fix? is a  quick fix? r we going to fix it today?
[23:21] <anastasiamac_> menn0: questions r*... i guess :D
[23:43] <wallyworld> thumper: for standup, which I'll miss due to interview, I have 3 PRs needing review, 2 juju and 1 goose (linked from the juju openstack PR). i also fixed 2 other bugs, the maas apt proxy one and the status colour one
[23:45] <anastasiamac_> wallyworld: do u have a bug reference for colour one?
[23:46] <wallyworld> anastasiamac_: no, it was a direct request
[23:58] <stokachu> anastasiamac_, i dont have a fix yet
[23:58] <stokachu> anastasiamac_, one thing ive been thinking about is not allowing conjure-up to deploy things to nested lxd containers
[23:59] <stokachu> but that changes the deployment for just one provider since aws/gce allow this
[23:59] <stokachu> and we try to stay as close to the bundle spec as possible