[00:01] wallyworld thumper menn0 anastasiamac: could someone please review http://reviews.vapour.ws/r/5572/, fixes the blocker [00:01] if it looks good, please land - I need to go help with kids [00:01] axw: ack [00:01] two in a row perrito666! [00:01] ~warp speed~ [00:01] axw: looking [00:11] menn0: axw: sorry, just got off a call, menn0 i can look at your PR in a minute [00:19] anastasiamac, ping [00:23] wallyworld: cheers [00:26] alexisb: pong :) [00:26] alexisb: a-team standup? [00:26] sure [00:31] menn0: in the PR, it looks like the "lost" processing has been omitted for machines? [00:31] wallyworld: it was never there [00:32] wallyworld: there should be no functional change in this PR [00:33] ah, right, looks like there was some dumb no-op code there for mchine status [00:33] wallyworld: yep there was some dead code there. I meant to mention it in the PR description, sorry. [00:33] no worries, i just had a reading comprehension problem [00:36] menn0: +1, nice to see that refactoring [01:12] wallyworld: can you please look at http://reviews.vapour.ws/r/5572/ also [01:12] ok [01:16] axw: was the main issue adding back the EnableHTTPSListener call? [01:16] wallyworld: yes [01:17] 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] wallyworld: I reproduced the issue by wiping out the core.https_address config from my lxd [01:17] awesome, ok [01:17] lgym [01:18] wallyworld: sorry, should have included that in QA [01:18] no worries [01:39] 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] damn [01:43] doh [01:49] wallyworld: thanks for the review [01:49] np [02:24] gosh darn it... github.com/juju/charm/hooks has moved/gone [03:57] thumper: so the migration export format only stores the charm URL against the application [03:57] thumper: but a particular unit might running a different charm version [03:58] thumper: if a charm upgrade is in progress [03:58] thumper: axw picked up that the prechecks don't prevent a migration if a charm upgrade is in progress [04:00] thumper: we either need to extend the export format to store charm URL per unit [04:00] thumper: (which is probably needed when the migration format gets used for backup and restore) [04:00] thumper: or we block migrations during charm upgrade [04:00] thumper: thoughts? [04:02] 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] Bug #1453805: Juju takes more than 20 minutes to enable voting

[04:02] anastasiamac: yeah, snowed under ... retarget please [04:03] menn0: \o/ [04:08] menn0: precheck for charms [04:08] menn0: we will have to update the format though I think [04:08] thumper: ok, easy enough [04:08] 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] Bug #1555808: Cannot deploy a dense openstack bundle with native deploy <2.0> <2.0-count>

[04:09] * wallyworld doesn't know [04:09] likewise - I missed that [04:09] 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] but it wasn't the specific fix [04:10] thumper: \o/ i'll get ppl to re-test :D tyvm! [04:11] veebers: do u know if there is a functional test for this ^^ bug? [04:11] CI doesn't yet deploy openstack bundles [04:12] to the best of my knowledge; it's a gap that needs to be filled [04:12] we tend to rely on OIL [04:12] 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] i'd love to know how far away such movements are from something concrete [04:17] anastasiamac: sorry missed the ping, seems wallyworld answered for me :-) [04:26] wallyworld: axw: i thought bug 1582021 was addressed :D [04:26] Bug #1582021: Juju loses track of current controller when destroying model <2.0>

[04:26] so did i, it could be a dupe [04:27] wallyworld: i love those \o/ i'll mark as fix committed :D [05:26] 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] axw: yeah, sorry, i didn't know how to split it up [05:27] it's used in the ec2 provider (and hopefully soon openstack) to construct the firewaller component [05:27] the controller uuid is needed to manipulate security groups [05:28] remmeber how in openstack we didn;t have the controller uuid avaiable and had to make that api call? [05:28] we can now revert that change [05:29] wallyworld: why would we need controller-wide security groups? shouldn't they be model specific? [05:29] wallyworld: which API call? [05:30] let me check the exact one [05:32] axw: before i do that, here's a call that's made in the ec2 provider in current master: controllerSecurityGroups(controllerUUID) [05:33] maybe the intent was for controller model uuid [05:34] ah, no, i think controller uuid is to filter on tag [05:34] we tag ec2 security groups with model and controller uuid [05:34] 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] it already has the controller UUID there anyway... [05:35] that me be a very valid point [05:35] i can look at that and revert the controller uuid in open params [05:35] thanks [05:36] wallyworld: but before you do, what was the openstack case? [05:36] maybe it's needed there [05:36] axw: i think with openstack, we can tag security groups, so need to construct the name as juju-controlleruuid-modeluuid [05:37] let me check hte code [05:38] wallyworld: assuming you mean s/can/can't/ -- yeah I think that's the case. probably same deal then, move to Create [05:40] 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] cool, sounds good [05:40] at least it will make the pr smaller [05:51] axw: i even now see the todo in ec2 environ create, sigh, forgot about that before [05:51] wallyworld: :) is it even necessary at the moment though? the code that's there already has access to controller UUIDs AFAICS [05:52] 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] 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] 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] and i can call it later when needed using the current code [05:53] wallyworld: they're not necessarily called on the same Environ [05:53] in fact, s/necessarily// :) [06:03] axw: do u know if bug 1607347 is related to some credential change? [06:03] Bug #1607347: Password for juju-gui not showing up after a change [06:03] axw: damn, a bit more to do - appears ec2 tests don't call Create() [06:04] which is kinda important :-) [06:06] axw: huh, looks like only prod code for all the providers calls create [06:07] wallyworld: axw: also was bug 1614010 addressed as part of recent works in he area? [06:07] the* [06:08] anastasiamac: that one is invalid [06:09] wallyworld: could u plz update the bug and explain why it's invalid as part of the comment? ;D [06:09] i may not have all the exact reasoning to hand; would be better to ask rick whose team did the work [06:10] something along the lines of needing a separate juju home for each user [06:10] i'm not sure i agree with it [06:10] mick did the work i believe [06:21] wallyworld: axw: and what about bug 1607347? [06:21] Bug #1607347: Password for juju-gui not showing up after a change === petevg_ is now known as petevg [06:22] anastasiamac: we wipe the password off disk when you call change-user-password [06:23] axw: \o/ could you please adda comment to the bug? [06:25] wallyworld: do u know if ur recent work addressed bug 1617046 as a drive-by? [06:25] Bug #1617046: WARNING cannot read current model: current model for controller not found

[06:29] anastasiamac: possibly, not sure off hand, there's been activity in that area [06:34] 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] you agree that i need to add a create call at bootstrap? [06:35] 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] 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] i.e. in the StartInstances method [06:36] 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] axw: i'll chedk the code again - there were places where we did not have controller uuid [06:38] 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] axw: that's fine - other environs are opened and created a sneeded [06:39] and those other ones have the create called to set up things [06:39] 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] wallyworld: right, Create is only called for hosted models [06:40] i'll take another look to confirm that we always have controller uuid where needed [06:48] 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] except i left in a create call, need to remove it [06:52] done [07:06] Bug #1616832 changed: manual environment juju-db timeout

[07:06] Bug #1618798 changed: endpoint not used in lxd provider === frankban|afk is now known as frankban [07:33] Bug # changed: 1492000, 1566414, 1584616, 1596597, 1612645, 1614364, 1614633 [08:22] 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] wallyworld: seeing as you don't need to know it before hand, I think it's best to keep it [08:23] ok, will revert [08:26] fwereade: ping - got a minute [08:26] fwereade: ? [08:26] voidspace, sure [08:26] fwereade: working on migration for cloudimagemetadata [08:27] fwereade: cloud image metadata stuff is in a sub-package of state [08:27] fwereade: the migration internal test checks migrated fields so needs access to cloudimagemetadataDoc [08:27] fwereade: but this isn't exported and the test is in the state package [08:28] 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] fwereade: can you think of another option? [08:28] exporting the doc seems like a bad idea [08:30] voidspace, thinking/spooling [08:32] wallyworld: I'm looking to see if we can fix the dummy provider now [08:32] looks diable [08:32] doable* [08:32] axw: econtext switch, which bit? [08:33] wallyworld: getting rid of references to controller UUID from dummy provider's PrepareConfig [08:33] ah ok. did you want me to land this current work first once i fix the comments? [08:33] 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] wallyworld: no, I don't want PrepareConfigParams getting worse than it is already [08:34] ok [08:35] voidspace, is the test machinery at all suitable for extraction and reuse rather than copying? [08:35] fwereade: it's a pretty simple function (and a method) [08:36] fwereade: so could easily be movedd [08:36] *moved [08:36] fwereade: the heavy lifting is a 15 line reflection function getting the exported fields [08:37] voidspace, I'm gently leaning that way at the moment then [08:37] fwereade: I'll do that [08:37] fwereade: just need to find the right place for it to live [08:38] 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] fwereade: thanks [08:41] voidspace, cheers [09:05] Hi. How can I set bugs-url and homepage for my newly developed charm? Please anyone respond to this. [09:42] marcoceppi: ^^^^^^ you around to help? [09:43] axw: i've pushed some changes, will retest, i can wait till you propose and land yours and then rebase [09:43] wallyworld: thanks, just gotta pull in your restore changes [09:44] ok, will go feed dog etc [10:00] Morning [10:03] 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] ok [10:06] 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] Bug #1616832: manual environment juju-db timeout

[10:42] 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] 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] 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] frobware, babbageclunk: hey guys, I've updated http://reviews.vapour.ws/r/5559/ and still need +1 to land it [11:21] jam: ^^ based on our current discussion we may want to look at this again [11:22] 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] wallyworld: red herring it seems, I had the same failure on master. running tests again and then will propose [12:17] ok [12:17] looked good from what i saw [12:22] wallyworld: if you're happy with https://github.com/juju/juju/pull/6137, please land and rebase off that [12:22] ok [12:24] axw: let me know if you're happy with the latest version of mine; i've alredy fixed the controller uuid thing [12:26] wallyworld: looking [12:48] wallyworld: LGTM with that field removed [12:48] axw: awesome, ta. yours is almost dome landing hopefully [12:49] Bug #1484105 opened: juju upgrade-charm returns ERROR state changing too quickly; try again soon

[13:07] Bug #1573136 changed: kill-controller is stuck, lots of "lease manager stopped" errors

[13:11] alexisb, wallyworld - Everyone cool for me to pause trying to reproduce bug 1611159 and work on maas2 instance tagging instead? [13:11] Bug #1611159: model not successfully destroyed, and error on "juju list-models"

[13:11] babbageclunk: big +1 from me :-) [13:11] that bug is a rabbit hole [13:12] you can come back to it [13:12] wallyworld: I'm definitely feeling that too. [13:13] wallyworld: Ok, I'll start on that unless alexisb says otherwise in the meantime. [13:13] sgtm [13:13] we discussed it briefly [13:13] and it's good to reset your brain a bit as well [13:14] yeah, absolutely - letting your subconscious have a go at it in the background wh [13:15] rogue wh [13:16] Bug #1573136 opened: kill-controller is stuck, lots of "lease manager stopped" errors

[13:17] babbageclunk, see priv chat [13:17] jam, are you around? [13:19] Bug # changed: 1573136, 1595617, 1597318, 1598329, 1604988 [13:21] babbageclunk: if you can have a look at http://reviews.vapour.ws/r/5559/ again, I'd appreciate a +1 :) [13:28] Bug # opened: 1595617, 1597318, 1598329, 1604988 [13:35] dimitern: yup, lookin now [13:35] g === natefinch-afk is now known as natefinch [13:37] Bug # changed: 1595617, 1597318, 1598329, 1604988 [13:46] babbageclunk: ta! [13:54] dimitern: LGTM! [13:57] babbageclunk: tyvm [14:01] voidspace: natefinch: standup time [14:29] so, go 1.6 [14:29] I thought I'd consistently get random ordering in maps [14:29] is that not actually the case? [14:30] in specific, [14:30] iterate over a map of three objects [14:30] I'd expect a test expecting a specific order to fail most of the time [14:31] is is not actually that random? [14:31] mgz: make your map content bigger [14:31] katco: booger! [14:31] katco: I caught up and didn't notice the time, sorry [14:31] mgz: MOAR [14:31] I'm going to start setting an alarm [14:31] frobware: so, there's special handling for small maps? or something? [14:32] mgz: yes there is [14:32] mgz: Just the hashing of your object may yield the same result each time [14:32] mgz: I can remember the size, but it was ~10 entries [14:32] mgz: s/object/keys [14:32] aha, thanks guys [14:33] (from what I remember from gophercon, maps are internally implemented as linked arrays of fixed size - buckets, + overflow space [14:33] natefinch: do you want to set aside some time to install MAAS before I EOD in a few hours? [14:33] that's why using a map lookup vs slice iteration for small number of elements is not worth the overhead [14:34] frobware: yeah, will you have time in like 15 minutes? [14:34] dimitern: let's do 30 - would that work? [14:34] natefinch: ^^ (sorry!) [14:34] ha! :) [14:34] dimitern: habits... [14:35] frobware: sounds good [14:35] mgz: randomish - https://play.golang.org/p/lzGvkm9VxC [14:39] mgz: it appears as though small maps are just occasionally randomized [14:43] that is interesting, and pretty odd [14:44] mgz: pretty sure small maps are implemented as slices [14:44] 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] I am getting the same issue. juju status pasted info http://paste.openstack.org/show/565721/ [14:45] 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] dimitern: So I am thinking it might be a juju-gui bug. [14:50] natefinch: you'll need a server ISO before we start [14:51] frobware: I can get that [14:51] natefinch: xenial if you want MAAS 2.x [14:52] frobware: I wouldn't get anything else :) [14:52] natefinch: it depends if you need to repro against MAAS 1.9 though - that's trusty only [14:52] well that's a PITA [14:52] rock: hey! did you also deploy your biarca charm with specified --series ? [14:53] 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] 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] it's a journey of fun discovery :) [14:55] okay, I'm going to go ahead and change this delete implemtation to preserve order [14:56] natefinch: frobware: andreas has offered up help in reproducing bug 1614635 simply [14:56] Bug #1614635: Deploy sometimes fails behind a proxy [14:57] natefinch: frobware: please ping him if you run into trouble getting the environment set up [14:57] looks like almost exactly 75% of the time, iterating a small map will do so in order [14:58] dimitern: Yes. [14:59] natefinch: iirc express randomization was added to that [14:59] perrito666: yep.... I just thought it was interesting that it wasn't just always random [15:00] 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] natefinch: well that is the definition of random [15:01] perrito666: well, no... sometimes it decides to be random, and a lot of the time it decides not to be [15:02] its random [15:03] 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] 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] natefinch: I recall a random implementation in turbo C that would spit the same number sequence each time [15:04] it is random at random, how meta [15:04] yes... that probably helps keep the average runtime near constant [15:07] 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] ...those numbers still being hugely higher than pure random would indicate [15:08] natefinch, katco: do we still want to setup locally? [15:09] frobware: natefinch: andreas said the setup is easy; maass in vmware, add 1 node, boom [15:09] frobware: natefinch: so if it starts sounding any more complicated than that, i would say ping him [15:10] uh... well, maas in vmware is still ¯\_(ツ)_/¯ to me [15:10] natefinch: want to start now? [15:10] frobware: yes :) Thank you :) [15:11] natefinch: https://hangouts.google.com/hangouts/_/canonical.com/andrew-mcdermot?authuser=0 [15:18] rock, right and your charm - was it showing xenial as well? [15:30] voidspace: sorry for delay, meetings... np about standup. how goes migrations? [15:31] katco: there's progress - it compiles, so mostly fixing tests, so not far off now. Probably tomorrow though. [15:32] voidspace: cool [15:32] 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] katco: plus I did a grand rename to get rid of the abomination "cloudimagemetadatas" I originally used :-) [15:32] haha [15:32] what's it named now? [15:33] katco: some places I could simply use CloudImageMetadata, even though it returns a slice of Metadata [15:33] katco: and the places I couldn't I used cloudimagemetadataset [15:33] katco: which is not ideal (it's not a set) but still better [15:39] frobware: all installed [15:40] natefinch: ok let's jump back in to the HO [16:00] morning [16:04] heya redir [16:04] :) [16:05] g'day redir [16:19] katco, natefinch: all done. working maas setup. \o/ [16:19] frobware: ya! thanks a lot frobware [16:20] \o/ [16:50] bbiab, going for a haircut. === frankban is now known as frankban|afk [17:06] Hey core devs o/ do juju-gui bugs get targeted against http://launchpad.net/juju now that its moved into core? [17:09] lazyPower: no idea [17:10] hatch, do you know? ^^ [17:10] * hatch looks [17:11] i thought we just used github issues, but wasn't sure [17:11] 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] well, i filed it here: https://bugs.launchpad.net/juju/+bug/1619389 [17:11] Bug #1619389: juju-gui fails to parse exported bundle in beta-16 [17:11] i'll xpost to juju-gui repo [17:11] lazyPower, thanks [17:11] lazyPower: it's a known bug [17:12] and it's fixed in gui tip [17:12] lazyPower: https://github.com/juju/juju-gui/issues/1937 [17:13] https://github.com/juju/juju-gui/issues/1966 [17:14] 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]