[00:01] <axw> wallyworld thumper menn0 anastasiamac: could someone please review http://reviews.vapour.ws/r/5572/, fixes the blocker
[00:01] <axw> if it looks good, please land - I need to go help with kids
[00:01] <thumper> axw: ack
[00:01] <redir> two in a row perrito666!
[00:01] <redir> ~warp speed~
[00:01] <menn0> axw: looking
[00:11] <wallyworld> menn0: axw: sorry, just got off a call, menn0 i can look at your PR in a minute
[00:19] <alexisb> anastasiamac, ping
[00:23] <menn0> wallyworld: cheers
[00:26] <anastasiamac> alexisb: pong :)
[00:26] <anastasiamac> alexisb: a-team standup?
[00:26] <alexisb> sure
[00:31] <wallyworld> menn0: in the PR, it looks like the "lost" processing has been omitted for machines?
[00:31] <menn0> wallyworld: it was never there
[00:32] <menn0> wallyworld: there should be no functional change in this PR
[00:33] <wallyworld> ah, right, looks like there was some dumb no-op code there for mchine status
[00:33] <menn0> wallyworld: yep there was some dead code there. I meant to mention it in the PR description, sorry.
[00:33] <wallyworld> no worries, i just had a reading comprehension problem
[00:36] <wallyworld> menn0: +1, nice to see that refactoring
[01:12] <axw> wallyworld: can you please look at http://reviews.vapour.ws/r/5572/ also
[01:12] <wallyworld> ok
[01:16] <wallyworld> axw: was the main issue adding back the EnableHTTPSListener call?
[01:16] <axw> wallyworld: yes
[01:17] <wallyworld> axw: would be nice to test on a virgin system, to repro the scenario that lead to the bug, but maybe that's a bit difficult
[01:17] <axw> wallyworld: I reproduced the issue by wiping out the core.https_address config from my lxd
[01:17] <wallyworld> awesome, ok
[01:17] <wallyworld> lgym
[01:18] <axw> wallyworld: sorry, should have included that in QA
[01:18] <wallyworld> no worries
[01:39] <axw> wallyworld: the CI machine is out of disk, and I need to head out for a bit. can't land my branch just yet
[01:39] <wallyworld> damn
[01:43] <redir> doh
[01:49] <menn0> wallyworld: thanks for the review
[01:49] <wallyworld> np
[02:24] <menn0> gosh darn it... github.com/juju/charm/hooks has moved/gone
[03:57] <menn0> thumper: so the migration export format only stores the charm URL against the application
[03:57] <menn0> thumper: but a particular unit might running a different charm version
[03:58] <menn0> thumper: if a charm upgrade is in progress
[03:58] <menn0> thumper: axw picked up that the prechecks don't prevent a migration if a charm upgrade is in progress
[04:00] <menn0> thumper: we either need to extend the export format to store charm URL per unit
[04:00] <menn0> thumper: (which is probably needed when the migration format gets used for backup and restore)
[04:00] <menn0> thumper: or we block migrations during charm upgrade
[04:00] <menn0> thumper: thoughts?
[04:02] <anastasiamac> menn0: this bug has been assigned to u, but I suspect u were snowed under and haven't had a chance to look at.. bug 1453805... is it correct? m thinking to re-target it to next beta...
[04:02] <mup> Bug #1453805: Juju takes more than 20 minutes to enable voting <ci> <ensure-availability> <intermittent-failure> <regression> <juju:Triaged by menno.smits> <juju-core 1.23:Fix Released by menno.smits> <juju-core 1.24:Fix Released by menno.smits> <https://launchpad.net/bugs/1453805>
[04:02] <menn0> anastasiamac: yeah, snowed under ... retarget please
[04:03] <anastasiamac> menn0: \o/
[04:08] <thumper> menn0: precheck for charms
[04:08] <thumper> menn0: we will have to update the format though I think
[04:08] <menn0> thumper: ok, easy enough
[04:08] <anastasiamac> thumper: menn0: wallyworld: axw: i thought I heard someone say during standup that they were working on fixing bundle deployment.. has bug 1555808 been addressed as part of that work?
[04:08] <mup> Bug #1555808: Cannot deploy a dense openstack bundle with native deploy <2.0> <2.0-count> <bundles> <cdo-qa> <ci> <deployer> <juju-release-support> <jujuqa> <maas-provider> <juju:Triaged> <https://launchpad.net/bugs/1555808>
[04:09]  * wallyworld doesn't know
[04:09] <axw> likewise - I missed that
[04:09] <thumper> anastasiamac: my fix may have addressed that
[04:09]  * anastasiamac have troubles believing that there is something that wallyworld doesn't know :-P
[04:09] <thumper> but it wasn't the specific fix
[04:10] <anastasiamac> thumper: \o/ i'll get ppl to re-test :D tyvm!
[04:11] <anastasiamac> veebers: do u know if there is a functional test for this ^^ bug?
[04:11] <wallyworld> CI doesn't yet deploy openstack bundles
[04:12] <wallyworld> to the best of my knowledge; it's a gap that needs to be filled
[04:12] <wallyworld> we tend to rely on OIL
[04:12] <anastasiamac> wallyworld: in my converstaions with Torsten and Nicholas, there have been movements in this area... i'll confrim :D Thank you for answering Chris's question \o/
[04:13] <wallyworld> i'd love to know how far away such movements are from something concrete
[04:17] <veebers> anastasiamac: sorry missed the ping, seems wallyworld answered for me :-)
[04:26] <anastasiamac> wallyworld: axw: i thought bug 1582021 was addressed :D
[04:26] <mup> Bug #1582021: Juju loses track of current controller when destroying model <2.0> <bitesize> <destroy-model> <juju-release-support> <usability> <juju:Triaged> <https://launchpad.net/bugs/1582021>
[04:26] <wallyworld> so did i, it could be a dupe
[04:27] <anastasiamac> wallyworld: i love those \o/ i'll mark as fix committed :D
[05:26] <axw> wallyworld: your PR is obese, too hard to see what's going on. can you please point out where the OpenParams.ControllerUUID is used?
[05:26] <wallyworld> axw: yeah, sorry, i didn't know how to split it up
[05:27] <wallyworld> it's used in the ec2 provider (and hopefully soon openstack) to construct the firewaller component
[05:27] <wallyworld> the controller uuid is needed to manipulate security groups
[05:28] <wallyworld> remmeber how in openstack we didn;t have the controller uuid avaiable and had to make that api call?
[05:28] <wallyworld> we can now revert that change
[05:29] <axw> wallyworld: why would we need controller-wide security groups? shouldn't they be model specific?
[05:29] <axw> wallyworld: which API call?
[05:30] <wallyworld> let me check the exact one
[05:32] <wallyworld> axw: before i do that, here's a call that's made in the ec2 provider in current master: controllerSecurityGroups(controllerUUID)
[05:33] <wallyworld> maybe the intent was for controller model uuid
[05:34] <wallyworld> ah, no, i think controller uuid is to filter on tag
[05:34] <wallyworld> we tag ec2 security groups with model and controller uuid
[05:34] <axw> wallyworld: if we just move the security group creation to the Create method, like we were planning to, we don't need OpenParams.ControllerUUID
[05:35] <axw> it already has the controller UUID there anyway...
[05:35] <wallyworld> that me be a very valid point
[05:35] <wallyworld> i can look at that and revert the controller uuid in open params
[05:35] <axw> thanks
[05:36] <axw> wallyworld: but before you do, what was the openstack case?
[05:36] <axw> maybe it's needed there
[05:36] <wallyworld> axw: i think with openstack, we can tag security groups, so need to construct the name as juju-controlleruuid-modeluuid
[05:37] <wallyworld> let me check hte code
[05:38] <axw> wallyworld: assuming you mean s/can/can't/ -- yeah I think that's the case. probably same deal then, move to Create
[05:40] <wallyworld> axw: it's to get all the security groups for instances to be stopped; i just checked and ec2 also makes an api call - i think openstack didn't and then we had to so it's become no worse than ec2; so i think we are ok to revert that controller uuid in open params
[05:40] <axw> cool, sounds good
[05:40] <wallyworld> at least it will make the pr smaller
[05:51] <wallyworld> axw: i even now see the todo in ec2 environ create, sigh, forgot about that before
[05:51] <axw> wallyworld: :)  is it even necessary at the moment though? the code that's there already has access to controller UUIDs AFAICS
[05:52] <axw> wallyworld: I'd prefer to do that change in another PR if it's not necessary, because there are possible negative side effects
[05:52] <axw> wallyworld: Create is currently called synchronously, when adding a model. so if we do anything slow in there, it means add-model is going to be slow
[05:52] <wallyworld> axw: i found out that not all places had the controller uuid. but. all i need to do is create the firewaller struct in create
[05:53] <wallyworld> and i can call it later when needed using the current code
[05:53] <axw> wallyworld: they're not necessarily called on the same Environ
[05:53] <axw> in fact, s/necessarily// :)
[06:03] <anastasiamac> axw: do u know if bug 1607347 is related to some credential change?
[06:03] <mup> Bug #1607347: Password for juju-gui not showing up after a change <cpe-sa> <juju:Triaged> <https://launchpad.net/bugs/1607347>
[06:03] <wallyworld> axw: damn, a bit more to do - appears ec2 tests don't call Create()
[06:04] <wallyworld> which is kinda important :-)
[06:06] <wallyworld> axw: huh, looks like only prod code for all the providers calls create
[06:07] <anastasiamac> wallyworld: axw: also was bug 1614010 addressed as part of recent works in he area?
[06:07] <anastasiamac> the*
[06:08] <wallyworld> anastasiamac: that one is invalid
[06:09] <anastasiamac> wallyworld: could u plz update the bug and explain why it's invalid as part of the comment? ;D
[06:09] <wallyworld> i may not have all the exact reasoning to hand; would be better to ask rick whose team did the work
[06:10] <wallyworld> something along the lines of needing a separate juju home for each user
[06:10] <wallyworld> i'm not sure i agree with it
[06:10] <wallyworld> mick did the work i believe
[06:21] <anastasiamac> wallyworld: axw: and what about bug 1607347?
[06:21] <mup> Bug #1607347: Password for juju-gui not showing up after a change <cpe-sa> <juju:Triaged> <https://launchpad.net/bugs/1607347>
[06:22] <axw> anastasiamac: we wipe the password off disk when you call change-user-password
[06:23] <anastasiamac> axw: \o/ could you please adda  comment to the bug?
[06:25] <anastasiamac> wallyworld: do u know if ur recent work addressed bug 1617046 as a drive-by?
[06:25] <mup> Bug #1617046: WARNING cannot read current model: current model for controller <name> not found <oil> <oil-2.0> <juju:Triaged> <https://launchpad.net/bugs/1617046>
[06:29] <wallyworld> anastasiamac: possibly, not sure off hand, there's been activity in that area
[06:34] <wallyworld> axw: it appears we only call env.Create() during a new model operation; it is not called at bootstrap. and it needs to be for ec2 at least so that the new firewaller is set up
[06:35] <wallyworld> you agree that i need to add a create call at bootstrap?
[06:35] <axw> wallyworld: we do not call Create on the same Environ that other methods are called with. so setting up a firewaller in that method will be pointless. you can/should create *security groups* in that method
[06:36] <axw> wallyworld: but again: do we actually need to make that change in this PR? from what I could see, controllerUUID is *already* available where we were creating the security groups
[06:36] <axw> i.e. in the StartInstances method
[06:36] <wallyworld> axw: firewaller is misnamed perhaps (i copied off the openstack naming) - all it is is a component to do the securty group thing
[06:37] <wallyworld> axw: i'll chedk the code again - there were places where we did not have controller uuid
[06:38] <axw> wallyworld: my point is that Create should not modify the Environ object - or if it does, you should not *expect* that it has done so from any other Environ method
[06:38] <wallyworld> axw: that's fine - other environs are opened and created a sneeded
[06:39] <wallyworld> and those other ones have the create called to set up things
[06:39] <wallyworld> but for bootstrap, the bootstrap instance startup was failing because the security group bit had not been initialised because create wasn;t called
[06:40] <axw> wallyworld: right, Create is only called for hosted models
[06:40] <wallyworld> i'll take another look to confirm that we always have controller uuid where needed
[06:48] <wallyworld> axw: yeah, i think in an earlier incarnation i mixed up controller uuid and controller model uuid and so controller uuid is available where needed; i've reverted all the ec2 provider changes and and open params ones, diff is 1 page of files less
[06:51] <wallyworld> except i left in a create call, need to remove it
[06:52] <wallyworld> done
[07:06] <mup> Bug #1616832 changed: manual environment juju-db timeout <manual-provider> <juju:Triaged> <juju-core:Won't Fix> <juju-core 1.25:Incomplete> <https://launchpad.net/bugs/1616832>
[07:06] <mup> Bug #1618798 changed: endpoint not used in lxd provider <juju:Triaged> <https://launchpad.net/bugs/1618798>
[07:33] <mup> Bug # changed: 1492000, 1566414, 1584616, 1596597, 1612645, 1614364, 1614633
[08:22] <wallyworld> axw: thnks for review - i was 50/50 on dropping the controller uuid from the login result. i couldn't see anything that used it. but i guess some callers may want to
[08:22] <axw> wallyworld: seeing as you don't need to know it before hand, I think it's best to keep it
[08:23] <wallyworld> ok, will revert
[08:26] <voidspace> fwereade: ping - got a minute
[08:26] <voidspace> fwereade: ?
[08:26] <fwereade> voidspace, sure
[08:26] <voidspace> fwereade: working on migration for cloudimagemetadata
[08:27] <voidspace> fwereade: cloud image metadata stuff is in a sub-package of state
[08:27] <voidspace> fwereade: the migration internal test checks migrated fields so needs access to cloudimagemetadataDoc
[08:27] <voidspace> fwereade: but this isn't exported and the test is in the state package
[08:28] <voidspace> fwereade: so the two options I can see are either export the doc or copy the migration test infrastructure into the sub-package
[08:28] <voidspace> fwereade: can you think of another option?
[08:28] <voidspace> exporting the doc seems like a bad idea
[08:30] <fwereade> voidspace, thinking/spooling
[08:32] <axw> wallyworld: I'm looking to see if we can fix the dummy provider now
[08:32] <axw> looks diable
[08:32] <axw> doable*
[08:32] <wallyworld> axw: econtext switch, which bit?
[08:33] <axw> wallyworld: getting rid of references to controller UUID from dummy provider's PrepareConfig
[08:33] <wallyworld> ah ok. did you want me to land this current work first once i fix the comments?
[08:33] <fwereade> voidspace, I'm thinking that the package boundary should be firm enough that it *should* be sufficient to check the data that's exported -- but, yeah, I'm drawing a bit of a blank on how to do that with certainty that we're not missing fields as we evolve
[08:34] <axw> wallyworld: no, I don't want PrepareConfigParams getting worse than it is already
[08:34] <wallyworld> ok
[08:35] <fwereade> voidspace, is the test machinery at all suitable for extraction and reuse rather than copying?
[08:35] <voidspace> fwereade: it's a pretty simple function (and a method)
[08:36] <voidspace> fwereade: so could easily be movedd
[08:36] <voidspace> *moved
[08:36] <voidspace> fwereade: the heavy lifting is a 15 line reflection function getting the exported fields
[08:37] <fwereade> voidspace, I'm gently leaning that way at the moment then
[08:37] <voidspace> fwereade: I'll do that
[08:37] <voidspace> fwereade: just need to find the right place for it to live
[08:38] <voidspace> fwereade: and as it will be a single test in cloud image metadata I'll just inline the assert and move the reflection function somewhere resusable
[08:38] <voidspace> fwereade: thanks
[08:41] <fwereade> voidspace, cheers
[09:05] <rock_> Hi. How can I set bugs-url and homepage  for my newly developed charm? Please anyone respond to this.
[09:42] <wallyworld> marcoceppi: ^^^^^^ you around to help?
[09:43] <wallyworld> axw: i've pushed some changes, will retest, i can wait till you propose and land yours and then rebase
[09:43] <axw> wallyworld: thanks, just gotta pull in your restore changes
[09:44] <wallyworld> ok, will go feed dog etc
[10:00] <perrito666> Morning
[10:03] <axw> wallyworld: my WIP is here: https://github.com/juju/juju/pull/6137, seems to be an issue with leaking mongo. I need to go help with the kids, will try and be back later
[10:03] <wallyworld> ok
[10:06] <anastasiamac> babbageclunk: fwereade: do u have any idea what could be wrong in bug 1616832 or if there is a workaround for juju 1.x?
[10:06] <mup> Bug #1616832: manual environment juju-db timeout <manual-provider> <juju:Triaged> <juju-core:Won't Fix> <juju-core 1.25:Incomplete> <https://launchpad.net/bugs/1616832>
[10:42] <mup> Bug # changed: 1425808, 1468752, 1484105, 1496166, 1498642, 1500981, 1504602, 1506498, 1510651, 1510675, 1511103, 1511235, 1512875, 1513659, 1517474, 1517535, 1519403, 1519473, 1522409, 1525868, 1532085, 1534296, 1535678, 1539684, 1541228
[10:47] <fwereade> anastasiamac, nothing really springs to mind... at least not without stopping mongo, running it locally without auth, and seeing what's actually in the admin database
[10:48] <fwereade> anastasiamac, it does look like machine-0 has forgotten how to log in, but I don't have a mechanism for how that'd happen
[11:12] <dimitern> frobware, babbageclunk: hey guys, I've updated http://reviews.vapour.ws/r/5559/ and still need +1 to land it
[11:21] <frobware> jam: ^^ based on our current discussion we may want to look at this again
[11:22] <anastasiamac> fwereade: \o/ thank you. could u plz comment in the bug with these thoughts and i'll follow up with Menno in the morning ;D
[11:55]  * dimitern steps out for ~45m
[12:16] <axw> wallyworld: red herring it seems, I had the same failure on master. running tests again and then will propose
[12:17] <wallyworld> ok
[12:17] <wallyworld> looked good from what i saw
[12:22] <axw> wallyworld: if you're happy with https://github.com/juju/juju/pull/6137, please land and rebase off that
[12:22] <wallyworld> ok
[12:24] <wallyworld> axw: let me know if you're happy with the latest version of mine; i've alredy fixed the controller uuid thing
[12:26] <axw> wallyworld: looking
[12:48] <axw> wallyworld: LGTM with that field removed
[12:48] <wallyworld> axw: awesome, ta. yours is almost dome landing hopefully
[12:49] <mup> Bug #1484105 opened: juju upgrade-charm returns ERROR state changing too quickly; try again soon <bug-squad> <upgrade-charm> <upgrade-juju> <juju-core:Incomplete> <https://launchpad.net/bugs/1484105>
[13:07] <mup> Bug #1573136 changed: kill-controller is stuck, lots of "lease manager stopped" errors <juju:Fix Released by fwereade> <juju-core:Won't Fix> <juju-core 1.25:Triaged> <https://launchpad.net/bugs/1573136>
[13:11] <babbageclunk> alexisb, wallyworld - Everyone cool for me to pause trying to reproduce bug 1611159 and work on maas2 instance tagging instead?
[13:11] <mup> Bug #1611159: model not successfully destroyed, and error on "juju list-models" <oil> <oil-2.0> <juju:Triaged by 2-xtian> <https://launchpad.net/bugs/1611159>
[13:11] <wallyworld> babbageclunk: big +1 from me :-)
[13:11] <wallyworld> that bug is a rabbit hole
[13:12] <wallyworld> you can come back to it
[13:12] <babbageclunk> wallyworld: I'm definitely feeling that too.
[13:13] <babbageclunk> wallyworld: Ok, I'll start on that unless alexisb says otherwise in the meantime.
[13:13] <wallyworld> sgtm
[13:13] <wallyworld> we discussed it briefly
[13:13] <wallyworld> and it's good to reset your brain a bit as well
[13:14] <babbageclunk> yeah, absolutely - letting your subconscious have a go at it in the background wh
[13:15] <babbageclunk> rogue wh
[13:16] <mup> Bug #1573136 opened: kill-controller is stuck, lots of "lease manager stopped" errors <juju:Fix Released by fwereade> <juju-core:Won't Fix> <juju-core 1.25:Triaged> <https://launchpad.net/bugs/1573136>
[13:17] <alexisb> babbageclunk, see priv chat
[13:17] <dimitern> jam, are you around?
[13:19] <mup> Bug # changed: 1573136, 1595617, 1597318, 1598329, 1604988
[13:21] <dimitern> babbageclunk: if you can have a look at http://reviews.vapour.ws/r/5559/ again, I'd appreciate a +1 :)
[13:28] <mup> Bug # opened: 1595617, 1597318, 1598329, 1604988
[13:35] <babbageclunk> dimitern: yup, lookin now
[13:35] <babbageclunk> g
[13:37] <mup> Bug # changed: 1595617, 1597318, 1598329, 1604988
[13:46] <dimitern> babbageclunk: ta!
[13:54] <babbageclunk> dimitern: LGTM!
[13:57] <dimitern> babbageclunk: tyvm
[14:01] <katco> voidspace: natefinch: standup time
[14:29] <mgz> so, go 1.6
[14:29] <mgz> I thought I'd consistently get random ordering in maps
[14:29] <mgz> is that not actually the case?
[14:30] <mgz> in specific,
[14:30] <mgz> iterate over a map of three objects
[14:30] <mgz> I'd expect a test expecting a specific order to fail most of the time
[14:31] <mgz> is is not actually that random?
[14:31] <frobware> mgz: make your map content bigger
[14:31] <voidspace> katco: booger!
[14:31] <voidspace> katco: I caught up and didn't notice the time, sorry
[14:31] <frobware> mgz: MOAR
[14:31] <voidspace> I'm going to start setting an alarm
[14:31] <mgz> frobware: so, there's special handling for small maps? or something?
[14:32] <dimitern> mgz: yes there is
[14:32] <frobware> mgz: Just the hashing of your object may yield the same result each time
[14:32] <dimitern> mgz: I can remember the size, but it was ~10 entries
[14:32] <frobware> mgz: s/object/keys
[14:32] <mgz> aha, thanks guys
[14:33] <dimitern> (from what I remember from gophercon, maps are internally implemented as linked arrays of fixed size - buckets, + overflow space
[14:33] <frobware> natefinch: do you want to set aside some time to install MAAS before I EOD in a few hours?
[14:33] <dimitern> that's why using a map lookup vs slice iteration for small number of elements is not worth the overhead
[14:34] <natefinch> frobware: yeah, will you have time in like 15 minutes?
[14:34] <frobware> dimitern: let's do 30 - would that work?
[14:34] <frobware> natefinch: ^^ (sorry!)
[14:34] <dimitern> ha! :)
[14:34] <frobware> dimitern: habits...
[14:35] <natefinch> frobware: sounds good
[14:35] <natefinch> mgz: randomish - https://play.golang.org/p/lzGvkm9VxC
[14:39] <natefinch> mgz: it appears as though small maps are just occasionally randomized
[14:43] <mgz> that is interesting, and pretty odd
[14:44] <natefinch> mgz: pretty sure small maps are implemented as slices
[14:44] <rock>  dimitern: Hi. as you said yesterday I upgraded to juju version 2.0-beta16. And also I deployed juju gui manually $juju deploy cs:juju-gui-134 --series xenial. It was deployed. But from gui I am not able to add relation between mycharm to cinder.ERROR: Relation biarca-openstack:juju-info to cinder:juju-info: cannot add relation   "biarca-openstack:juju-info cinder:juju-info" : principal and subordinate applications' series must match
[14:45] <rock> I am getting the same issue. juju status pasted info http://paste.openstack.org/show/565721/
[14:45] <natefinch> mgz: they add in fake random access so that when you get to a larger map that isn't just a slice, you won't get screwed by having code that relies on ordered iteration
[14:46] <rock> dimitern: So I am thinking it might be a juju-gui bug.
[14:50] <frobware> natefinch: you'll need a server ISO before we start
[14:51] <natefinch> frobware: I can get that
[14:51] <frobware> natefinch: xenial if you want MAAS 2.x
[14:52] <natefinch> frobware: I wouldn't get anything else :)
[14:52] <frobware> natefinch: it depends if you need to repro against MAAS 1.9 though - that's trusty only
[14:52] <natefinch> well that's a PITA
[14:52] <dimitern> rock: hey! did you also deploy your biarca charm with specified --series ?
[14:53] <natefinch> frobware:This bug is 2.0, and that's likely to be where most bugs are in the future, I'd imagine
[14:53]  * frobware chuckles... :)
[14:54] <dimitern> natefinch, mgz: here's the gophercon talk that explains how maps are implemented, if you're interested :) https://github.com/gophercon/2016-talks/tree/master/KeithRandall-InsideTheMapImplementation
[14:54] <mgz> it's a journey of fun discovery :)
[14:55] <mgz> okay, I'm going to go ahead and change this delete implemtation to preserve order
[14:56] <katco> natefinch: frobware: andreas has offered up help in reproducing bug 1614635 simply
[14:56] <mup> Bug #1614635: Deploy sometimes fails behind a proxy <landscape> <juju:Triaged by natefinch> <https://launchpad.net/bugs/1614635>
[14:57] <katco> natefinch: frobware: please ping him if you run into trouble getting the environment set up
[14:57] <natefinch> looks like almost exactly 75% of the time, iterating a small map will do so in order
[14:58] <rock> dimitern: Yes.
[14:59] <perrito666> natefinch: iirc express randomization was added to that
[14:59] <natefinch> perrito666: yep.... I just thought it was interesting that it wasn't just always random
[15:00] <rock> dimitern: Manually, using juju CLI I deployed juju-gui by specifying series as xenial. It worked. It was showing juju-gui series as Xenial.
[15:00] <perrito666> natefinch: well that is the definition of random
[15:01] <natefinch> perrito666: well, no... sometimes it decides to be random, and a lot of the time it decides not to be
[15:02] <perrito666> its random
[15:03] <natefinch> 50% of the time I iterate over a map of 5 items, it's exactly 0 1 2 3 4.... that's not random.  If it was random, that order would only come up 1/120 times
[15:04] <natefinch> it's choosing to be random some of the time, and a bunch of the time it's choosing just to iterate in order
[15:04] <perrito666> natefinch: I recall a random implementation in turbo C that would spit the same number sequence each time
[15:04] <perrito666> it is random at random, how meta
[15:04] <natefinch> yes... that probably helps keep the average runtime near constant
[15:07] <natefinch> notably, the bigger the map, the less often it goes in order... 3 items it's 75% in order, 5 items, it's 50%  8 items it's 12%
[15:07] <natefinch> ...those numbers still being hugely higher than pure random would indicate
[15:08] <frobware> natefinch, katco: do we still want to setup locally?
[15:09] <katco> frobware: natefinch: andreas said the setup is easy; maass in vmware, add 1 node, boom
[15:09] <katco> frobware: natefinch: so if it starts sounding any more complicated than that, i would say ping him
[15:10] <natefinch> uh... well, maas in vmware is still ¯\_(ツ)_/¯ to me
[15:10] <frobware> natefinch: want to start now?
[15:10] <natefinch> frobware: yes :) Thank you :)
[15:11] <frobware> natefinch: https://hangouts.google.com/hangouts/_/canonical.com/andrew-mcdermot?authuser=0
[15:18] <dimitern> rock, right and your charm - was it showing xenial as well?
[15:30] <katco> voidspace: sorry for delay, meetings... np about standup. how goes migrations?
[15:31] <voidspace> katco: there's progress - it compiles, so mostly fixing tests, so not far off now. Probably tomorrow though.
[15:32] <katco> voidspace: cool
[15:32] <voidspace> katco: ran into trouble with packages - cloudimagemetadata doesn't live in the state package, so our usual import and test techniques don't work
[15:32] <voidspace> katco: plus I did a grand rename to get rid of the abomination "cloudimagemetadatas" I originally used :-)
[15:32] <katco> haha
[15:32] <katco> what's it named now?
[15:33] <voidspace> katco: some places I could simply use CloudImageMetadata, even though it returns a slice of Metadata
[15:33] <voidspace> katco: and the places I couldn't I used cloudimagemetadataset
[15:33] <voidspace> katco: which is not ideal (it's not a set) but still better
[15:39] <natefinch> frobware: all installed
[15:40] <frobware> natefinch: ok let's jump back in to the HO
[16:00] <redir> morning
[16:04] <mgz> heya redir
[16:04] <redir> :)
[16:05] <macgreagoir> g'day redir
[16:19] <frobware> katco, natefinch: all done. working maas setup. \o/
[16:19] <katco> frobware: ya! thanks a lot frobware
[16:20] <redir> \o/
[16:50] <redir> bbiab, going for a haircut.
[17:06] <lazyPower> Hey core devs o/  do juju-gui bugs get targeted against http://launchpad.net/juju now that its moved into core?
[17:09] <natefinch> lazyPower: no idea
[17:10] <cmars> hatch, do you know? ^^
[17:10]  * hatch looks
[17:11] <cmars> i thought we just used github issues, but wasn't sure
[17:11] <hatch> lazyPower: if it's a GUI bug it should be reported https://github.com/juju/juju-gui/issues unless it specifically has to do with the juju core cli
[17:11] <lazyPower> well, i filed it here: https://bugs.launchpad.net/juju/+bug/1619389
[17:11] <mup> Bug #1619389: juju-gui fails to parse exported bundle in beta-16 <juju:New> <https://launchpad.net/bugs/1619389>
[17:11] <lazyPower> i'll xpost to juju-gui repo
[17:11] <cmars> lazyPower, thanks
[17:11] <hatch> lazyPower: it's a known bug
[17:12] <hatch> and it's fixed in gui tip
[17:12] <hatch> lazyPower: https://github.com/juju/juju-gui/issues/1937
[17:13] <lazyPower> https://github.com/juju/juju-gui/issues/1966
[17:14] <hatch> thanks lazyPower we're working on getting the next GUI out but we have some bigger tasks we're just wrapping up first
[17:15] <lazyPower> no stress, magicaltrout found it so was just making sure we had it on the docket
[17:15] <hatch> yup, and been fixed :)
[17:21] <hatch> lazyPower: also to clarify, the GUI project has not been moved into core, only the ability to serve the GUI was added to core.
[17:21] <lazyPower> you're now part of core, tl;dr
[17:22] <hatch> lol definitely not
[17:22] <hatch> or maybe I have been and I just don't know it yet!
[17:46] <tvansteenburgh> can anyone give me an example of the 'directive' and 'scope' portions of a placement
[17:47] <tvansteenburgh> like if i have lxc:7, is that all directive, and the default scope is the model?
[17:48] <tvansteenburgh> basically trying to figure out how to convert a placement string into a Placement map
[17:49] <katco> tvansteenburgh: try: https://github.com/juju/charm/blob/aece7b0e56c298641968239a7fa0b3466afa6ef5/bundledata.go#L626-L629
[17:59] <tvansteenburgh> katco: thanks!
[18:00] <katco> tvansteenburgh: np, happy hacking
[18:01] <mgz> I had to add a bunch of refactoring to make one of my tests reliable, can I request a re-review in a sec?
[18:03] <mgz> natefinch: around still?
[18:03] <natefinch> mgz: I exist in this reality.
[18:03] <mgz> :D
[18:04] <perrito666> ok, apparently its impossible to bootstrap juju from my ISP
[18:04] <perrito666> in aws
[18:05]  * perrito666 goes a bit closer
[18:08] <mgz> natefinch: okay, I have pushed a new commit on http://reviews.vapour.ws/r/5545/
[18:08] <mgz> natefinch: the base fix has been reviewed, but I did some refactoring to make the new testing not subject to map ordering problems
[18:09] <mgz> natefinch: so, I'd appreciate an eye on that part
[18:17] <natefinch> mgz: looking
[18:39] <natefinch> god I hate significant whitespace
[18:40] <natefinch> whats the opposite of deploy in maas?
[18:40] <natefinch> (unrelated to my previous statement)
[18:41] <mgz> natefinch: I was wondering
[18:42] <mgz> natefinch: `maas ENV machine delete` for 2, I think it's `... node delete` in 1
[18:43] <natefinch> delete or release?  I was just looking at the UI... I had deployed a machine to test that my maas is working correctly.  And now I want to undo that....
[18:43] <natefinch> maybe release is the opposite of commission... not that I know what commission means
[19:48] <mgz> natefinch: repoke about review
[19:50] <natefinch> mgz: oops, sorry, had started looking at it then got distracted by maas stuff
[20:20] <natefinch> mgz: reviewde
[20:22] <mgz> natefinch: ta!
[21:38] <cmars> how do i connect to juju's mongodb on xenial?
[21:41] <cmars> tried: /usr/lib/juju/mongo3.2/bin/mongo --ssl --username admin --password <value of oldpassword> --sslAllowInvalidCertificates localhost:37017 admin
[21:41] <cmars> doesn't work
[21:44] <thumper> menn0: ^^
[21:45] <thumper> cmars: I think menn0 has a script somewhere
[21:45] <menn0> I thought the packaging was being fixed to include the mongo3.2 client
[21:45]  * menn0 checks
[21:45] <cmars> menn0, it's there
[21:45] <cmars> menn0, i just can't log in with it, maybe my cmdline is wrong?
[21:46] <menn0> could be... let me check my script
[21:46] <menn0> mongo 127.0.0.1:37017/juju --authenticationDatabase admin --ssl --sslAllowInvalidCertificates --username "admin" --password "$password"
[21:46] <cmars> ah
[21:46] <menn0> that's what my script uses
[21:48] <cmars> menn0, ok, that got me in, thanks
[21:48] <cmars> menn0, can I have a copy of that script?
[21:48] <menn0> cmars: I just confirmed that it still works.
[21:48] <cmars> just needed the --authenticationDatabase flag
[21:48] <menn0> cmars: sure... let me revise it first though. It goes and installs the client from the mongodb.org PPA b/c we didn't use to include the client.
[21:48] <menn0> that's unnecessary now
[21:51] <menn0> cmars: https://gist.github.com/mjs/0d0b89356654de04adf4935860642c5f
[21:52] <menn0> cmars: run it from your machine like this: juju-db <controller:model>
[21:52] <menn0> where "model" is the controller model name
[21:53] <menn0> thinking about it, it should probably just assume the name "controller"
[21:54] <cmars> menn0, thanks!
[21:54] <cmars> this is going in my tools repo..
[21:56] <menn0> cmars: i've just improved it
[21:56] <menn0> cmars: if you now run "juju-db" without args it assumes machine 0 in the "controller" model for the currently selected controller
[21:56] <menn0> which is usually what you want
[21:57] <cmars> menn0, perfect, even better
[22:33] <wallyworld> thumper: menn0: you free for a chat? in s.o. h.o.?
[22:35] <mup> Bug #1617602 changed: juju status <service-name> stuck <status> <juju:Triaged> <juju-core:Won't Fix> <juju-utils:New> <https://launchpad.net/bugs/1617602>
[22:51] <katco> that feeling when you can iterate through a change because it has an actual unit test
[22:53] <wallyworld> cmars: hey, fyi, thumper just landed a fix fo all the recent landing issues. you will want to rebase your kpi branch to fix all the things
[22:55] <wallyworld> katco: to be fair, there would have been a test wouldn't there? maybe more like an intergration test, but still a test to run?
[22:56] <katco> wallyworld: yes, but it would have taken significantly longer to run
[22:57] <cmars> wallyworld, if we've passed CI and there are no conflicts, i think we ought to be able to just land as-is
[22:58] <wallyworld> cmars: true. i was just letting you know in case you were doing any more development on that branch before landing
[22:58] <cmars> wallyworld, no, it's ready to go i think
[22:58] <cmars> just waiting for QA blessing
[22:58] <wallyworld> cmars: sweet, in that case it *will* land foirst time now :-)
[22:59] <cmars> awesome. i spent my afternoon retrying so many times..
[22:59] <wallyworld> cmars: i just noticed you guys had a bunch od landing bot failures yesterday
[22:59] <wallyworld> yeah
[22:59] <wallyworld> thought'd you like to know it was fixed
[22:59] <cmars> that's great. i was getting worried :)
[23:00] <wallyworld> cmars: yeah, i blame thumper :-)
[23:04] <thumper> wallyworld: http://reviews.vapour.ws/r/5580/
[23:09] <menn0> wallyworld: sorry, I've been AFK
[23:10] <menn0> wallyworld: still want to talk?
[23:14] <perrito666> I am late for standup sorry ill be 10 late
[23:15] <thumper> 10 what?
[23:15] <thumper> ms?
[23:15] <thumper> s
[23:15] <thumper> hours?
[23:15] <anastasiamac> years
[23:15] <anastasiamac> ?
[23:15] <perrito666> Ill ley you guess
[23:21] <katco> perrito666: if you're late by 10 years i'll buy you a beer in 5
[23:27] <perrito666> lets not tell katco that It was minutes so she buys me abeer in 5
[23:27] <katco> perrito666: i didn't specify the unit =|
[23:28] <perrito666> I feel  cheated :p
[23:28] <katco> perrito666: i have used your own logic against you! mua! muaha ha!
[23:28] <perrito666> It was just me typing on the phone, you attribute me too much inteligence