[04:02] <menn0> anastasiamac: gah. just found in nasty bug with resources (not migrations but resources themselves).
[04:02] <menn0> anastasiamac: should be easy enough to fix
[04:18] <veebers> menn0: (eavesdropping) what's the bug? Might be a candidate for EDA
[04:18] <menn0> veebers: EDA?
[04:19] <menn0> veebers: the problem is with "placeholder" resources. A placeholder resource is where a charm has defined a resource but no unit has retrieved it yet.
[04:19] <veebers> menn0: escaped defect analysis that qa does i.e. why did this bug git hit outside our testing
[04:20] <veebers> git/get
[04:20] <menn0> veebers: when the application is removed a cleanup operation is scheduled for the placeholder resource to remove it from gridfs
[04:20] <menn0> veebers: but there's nothing to remove, so the cleanup fails
[04:21] <menn0> veebers: it's only visible from the logs (and also prevents a migration from starting, which is how I noticed)
[04:21] <veebers> menn0: ah I see, nice catch :-)
[04:22] <menn0> veebers: there's no unit test coverage for this (which I will fix)
[04:22] <menn0> veebers: not sure if it makes sense to cover in functional tests - it's a corner case
[04:24] <veebers> menn0: ack, cheers
[04:43] <blahdeblah> axw: Around, or still on a sprint?
[04:47] <blahdeblah> Or anyone else around familiar enough with https://bugs.launchpad.net/juju-core/+bug/1645729 to help me work out a problem with testing it?
[04:47] <mup> Bug #1645729: environment unstable after 1.25.8 upgrade <juju:Fix Committed by axwalk> <juju 2.1:Fix Committed by axwalk> <juju-core:Fix Committed by axwalk> <juju-core 1.25:Fix Released by axwalk> <https://launchpad.net/bugs/1645729>
[05:00] <blahdeblah> Well, I'll throw my questions here and hope someone sees them:
[05:00] <blahdeblah> I've added the proposed ppa and upgraded my local package such that "juju version" reports 1.25.9. I've also added agent-stream: proposed to environments.yaml for the environments I want to upgrade.
[05:00] <blahdeblah> But when I try an upgrade-juju --dry-run, it tells me no upgrades are available.
[05:06] <blahdeblah> Tried once with --upload-tools and it didn't work, but looks like it might be working now. o.O
[05:46] <anastasiamac> menn0: this is brilliant \o/ thank you for finiding it and for fixing it \o/
[05:47]  * anastasiamac wonders if nay part of HA would require migration.. menn0could fix it as drive-by
[05:47] <anastasiamac> any*
[05:47] <anastasiamac> blahdeblah: axw is on holiday until mid-Jan. how is ur upgrade?
[05:48] <blahdeblah> anastasiamac: I'm not sure
[05:48] <blahdeblah> Still waiting for sync-tools to finish
[05:48] <blahdeblah> yay ADSL 1Mbps upload
[05:50] <anastasiamac> blahdeblah: *\o/*
[05:51] <anastasiamac> blahdeblah: i need to go afk - **sigh** kids... - but will check backscroll later.. alternatively, feel free to email ;D
[05:52] <blahdeblah> anastasiamac: Is there anything that explains the process of upgrading a stable environment to proposed other than the paragraph on the PPA?
[05:53] <anastasiamac> blahdeblah: as far as I kow, u need to upgrade you tools stream value to 'proposed' and that's it
[05:54] <blahdeblah> I don't suppose there's a way to get the bootstrap node to pull the tools directly from streams?
[05:54] <blahdeblah> Or should that be the default
[05:54] <blahdeblah> ?
[05:55] <anastasiamac> blahdeblah: i think setting agent-metadata-url could do it...
[05:55]  * blahdeblah gives up on letting sync-tools trash his ADSL link
[05:55] <blahdeblah> setting it to what?
[05:56] <anastasiamac> blahdeblah: i need to go but for Juju 1.x, you could ...
[05:56] <anastasiamac> juju set-env agent-metadata-url=https://streams.canonical.com/juju/tools
[05:56] <anastasiamac> juju upgrade-juju --version 1.25.6
[05:56] <anastasiamac> blahdeblah: u might b able to do equivalent for Juju 2.x
[05:56] <blahdeblah> This is 1.25.8
[05:57] <anastasiamac> blahdeblah: sorry, I'll b back in cuple of hrs ... promise :)
[05:57] <blahdeblah> no worries - thanks anastasiamac
[05:57] <anastasiamac> blahdeblah: yes, so it should work as long as --version set to ur next desired..
[05:59] <anastasiamac> blahdeblah: u'd still need agent-stream value to b set to proposed tho
[05:59] <blahdeblah> yep
[08:31] <blahdeblah> anastasiamac: Thanks for the help; I seemed to need juju sync-tools before things would work.
[08:31] <blahdeblah> I'll update the bug shortly
[09:44] <voidspace> frobware: ping
[09:45] <frobware> voidspace: pong
[09:45] <voidspace> frobware: morning :-)
[09:46] <voidspace> frobware: I'm having a chat with Ante about his network issues at noon
[09:46] <frobware> voidspace: ok, can join.
[09:46] <voidspace> frobware: I added you to the meeting if you'll be available
[09:46] <frankban> hey, I need a review for the quick fix at https://github.com/juju/juju/pull/6694, anyone available?
[09:46] <voidspace> frobware: cool, thanks
[09:49] <voidspace> frankban: not possible to test it I guess
[09:50] <frankban> voidspace: just bootstrap a controller, and run "juju gui"
[09:50] <voidspace> frankban: I mean an automated test
[09:50] <voidspace> frankban: but that sounds like a good thing to do too
[09:50] <frankban> voidspace: unit tests are already there, and they keep passing
[10:02] <anastasiamac> blahdeblah: ack
[10:03] <voidspace> frankban: so if we're specifying the target directory there's no difference (except signature of function) between ioutil.TempDir and os.MkDir
[10:03] <voidspace> frankban: I know it's a trivial change, just want to ensure I *actually* understand it
[10:03] <voidspace> frankban: "juju gui" didn't fail with lxd, trying it with maas to watch it fail
[10:05] <frankban> voidspace: the difference is that os.MkDir receives the dir name, while TempDir creates a temporary dir (therefore with an available random name) in the given directory, with the given prefix
[10:06] <voidspace> frankban: ah yes, it's still a random name in the specified directory
[10:06] <voidspace> frankban: thanks
[10:07] <voidspace> frankban: I'm pretty sure your one line change is fine, I'm just trying it out
[10:07] <voidspace> frankban: :-)
[10:07] <frankban> voidspace: cool, and thanks!
[10:17] <voidspace> frankban: so I can't repro the original problem without multiple storage devices on my maas nodes
[10:17] <voidspace> frankban: but the new branch at least works fine, so LGTM
[10:17] <frankban> voidspace: ty!
[11:53] <mattyw> hey folks, is it possible to force juju to change the leader, so I can test leadership election in charms?
[12:00] <voidspace> frobware: ping for networking
[12:00] <frobware> voidspace: omw
[15:05] <kjackal> Hey rick_h got a question you might be able to help me with or route me to the right person. When I "juju register" a controller the password field inside the ~/.local/share/juju/accounts.yaml is not set. The python jujuclient we have is failing to parse the environment.
[15:05] <kjackal> rick_h: Is this a problem with the "juju register" command or with the jujuclient lib?
[15:09] <rick_h> kjackal: thinking
[15:09] <kjackal> rick_h: http://pastebin.ubuntu.com/23619350/
[15:10] <kjackal> rick_h: Here is cwr failing because of this problem
[15:11] <voidspace> frobware: ping
[15:15] <rick_h> kjackal: so, what client is doing the register?
[15:15] <rick_h> kjackal: so when you normally cli register you get a chance to set a password
[15:15] <rick_h> kjackal: but if not set, there's a cookie I think that gets set
[15:15] <rick_h> kjackal: so it could be client issue in registering, reading the cookie, etc
[15:15] <rick_h> kjackal: but hard to say from the pastebin as that's after the fact so not sure what got up to there
[15:16] <kjackal> rick_h: you "juju register" the controller and you provide a password. After that the controller is operational. Bundle tester works fine with it. No problem there.
[15:17] <kjackal> rick_h: The registration process does not add the password field in the accounts.yaml so the jujuclient library is failing
[15:18] <rick_h> kjackal: right so what's bundle tester using that jujuclient isn't then. I'm guessing it's not able to read the cookie data?
[15:19] <kjackal> rick_h: from your answer I gather that the password field in accounts.yaml is optional
[15:19] <rick_h> kjackal: yea, though I'm trying to think about that.
[15:19] <rick_h> kjackal: I mean the only real 'permanent' password is the credentials.yaml
[15:20] <rick_h> kjackal: that's persistent, so I'm curious if there's something that we should be doing in credentials.yaml that's correct or not
[15:20] <rick_h> kjackal: that one I need to chat with some other folks on and see why we don't. I guess because that's for a cloud and not a controller that's already running...
[15:21] <kjackal> rick_h: is password is optional then this line here seems wrong: http://bazaar.launchpad.net/~juju-deployers/python-jujuclient/trunk/view/head:/jujuclient/juju2/connector.py#L64
[15:22] <kjackal> *if
[15:22] <rick_h> kjackal: yea, I just can't think of a great reason not to fill it in if the user has entered it. Maybe worth an email to juju-dev email list.
[15:23] <rick_h> kjackal: can you do full repro steps and bring it up and I'll chime in and see if we can get some feedback from the folks that did it if there was some reason I'm blanking on atm?
[15:24] <kjackal> ok, will do that. thanks rick_h
[15:35] <frobware> voidspace: pong
[15:48] <voidspace> frobware: tycho's patch uses the constraints off the instanceConfig
[15:48] <voidspace> frobware: however the CreateContainer method it is in takes a parameter called cons, which is a constraints.Value
[15:49] <frobware> voidspace: the patch is quite old. :/
[15:49] <voidspace> frobware: obviously kvm needs to specify these constraints differently from within the CreateContainer call
[15:49] <voidspace> frobware: ah, ok - so it may just be out of date
[15:49] <voidspace> frobware: I'm trying to see how it's used
[15:50] <frobware> voidspace: pretty sure this was done at the austin sprint, so march/april this year.
[15:50] <voidspace> frobware: that's no *soooo* olld
[15:50] <voidspace> *old even
[15:51] <frobware> voidspace: 2016 still. :)
[15:51] <voidspace> frobware: right
[15:52] <voidspace> frobware: so StartInstanceParams dows have Constraints, which is also a constraints.Value
[15:52] <voidspace> I wonder if it's just the same stuff duplicated or different
[15:52] <voidspace> time for some instrumentation I think
[19:33] <mup> Bug #1649379 opened: bootstrap failed sigabrt when installing services <bootstrap> <intermittent-failure> <juju-core:Triaged> <https://launchpad.net/bugs/1649379>
[22:32] <alexisb> ping anastasiamac
[23:17] <cmars> hey, does the GCE provider support exposing port ranges?
[23:17] <cmars> i may have found a bug..
[23:24] <mup> Bug #1510689 changed: juju upgrade --upload-tools tries to upload tools agents that are not permitted by the state server <bug-squad> <simplestreams> <upgrade-juju> <upload-tools> <juju:Triaged> <juju-core:Won't Fix> <https://launchpad.net/bugs/1510689>
[23:33] <mup> Bug #1510689 opened: juju upgrade --upload-tools tries to upload tools agents that are not permitted by the state server <bug-squad> <simplestreams> <upgrade-juju> <upload-tools> <juju:Triaged> <juju-core:Won't Fix> <https://launchpad.net/bugs/1510689>
[23:36] <mup> Bug #1510689 changed: juju upgrade --upload-tools tries to upload tools agents that are not permitted by the state server <bug-squad> <simplestreams> <upgrade-juju> <upload-tools> <juju:Triaged> <juju-core:Won't Fix> <https://launchpad.net/bugs/1510689>
[23:48] <mup> Bug #1649379 changed: bootstrap failed sigabrt when installing services <bootstrap> <intermittent-failure> <juju-core:Won't Fix> <https://launchpad.net/bugs/1649379>