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:01 |
wallyworld | menn0: axw: sorry, just got off a call, menn0 i can look at your PR in a minute | 00:11 |
alexisb | anastasiamac, ping | 00:19 |
menn0 | wallyworld: cheers | 00:23 |
anastasiamac | alexisb: pong :) | 00:26 |
anastasiamac | alexisb: a-team standup? | 00:26 |
alexisb | sure | 00:26 |
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:31 |
menn0 | wallyworld: there should be no functional change in this PR | 00:32 |
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:33 |
wallyworld | menn0: +1, nice to see that refactoring | 00:36 |
axw | wallyworld: can you please look at http://reviews.vapour.ws/r/5572/ also | 01:12 |
wallyworld | ok | 01:12 |
wallyworld | axw: was the main issue adding back the EnableHTTPSListener call? | 01:16 |
axw | wallyworld: yes | 01:16 |
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:17 |
axw | wallyworld: sorry, should have included that in QA | 01:18 |
wallyworld | no worries | 01:18 |
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:39 |
redir | doh | 01:43 |
menn0 | wallyworld: thanks for the review | 01:49 |
wallyworld | np | 01:49 |
menn0 | gosh darn it... github.com/juju/charm/hooks has moved/gone | 02:24 |
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:57 |
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 | 03:58 |
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:00 |
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:02 |
anastasiamac | menn0: \o/ | 04:03 |
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:08 |
* 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:09 |
anastasiamac | thumper: \o/ i'll get ppl to re-test :D tyvm! | 04:10 |
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:11 |
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:12 |
wallyworld | i'd love to know how far away such movements are from something concrete | 04:13 |
veebers | anastasiamac: sorry missed the ping, seems wallyworld answered for me :-) | 04:17 |
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:26 |
anastasiamac | wallyworld: i love those \o/ i'll mark as fix committed :D | 04:27 |
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:26 |
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:27 |
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:28 |
axw | wallyworld: why would we need controller-wide security groups? shouldn't they be model specific? | 05:29 |
axw | wallyworld: which API call? | 05:29 |
wallyworld | let me check the exact one | 05:30 |
wallyworld | axw: before i do that, here's a call that's made in the ec2 provider in current master: controllerSecurityGroups(controllerUUID) | 05:32 |
wallyworld | maybe the intent was for controller model uuid | 05:33 |
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:34 |
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:35 |
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:36 |
wallyworld | let me check hte code | 05:37 |
axw | wallyworld: assuming you mean s/can/can't/ -- yeah I think that's the case. probably same deal then, move to Create | 05:38 |
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:40 |
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:51 |
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:52 |
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// :) | 05:53 |
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:03 |
wallyworld | which is kinda important :-) | 06:04 |
wallyworld | axw: huh, looks like only prod code for all the providers calls create | 06:06 |
anastasiamac | wallyworld: axw: also was bug 1614010 addressed as part of recent works in he area? | 06:07 |
anastasiamac | the* | 06:07 |
wallyworld | anastasiamac: that one is invalid | 06:08 |
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:09 |
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:10 |
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:21 |
=== petevg_ is now known as petevg | ||
axw | anastasiamac: we wipe the password off disk when you call change-user-password | 06:22 |
anastasiamac | axw: \o/ could you please adda comment to the bug? | 06:23 |
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:25 |
wallyworld | anastasiamac: possibly, not sure off hand, there's been activity in that area | 06:29 |
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:34 |
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:35 |
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:36 |
wallyworld | axw: i'll chedk the code again - there were places where we did not have controller uuid | 06:37 |
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:38 |
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:39 |
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:40 |
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:48 |
wallyworld | except i left in a create call, need to remove it | 06:51 |
wallyworld | done | 06:52 |
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:06 |
=== frankban|afk is now known as frankban | ||
mup | Bug # changed: 1492000, 1566414, 1584616, 1596597, 1612645, 1614364, 1614633 | 07:33 |
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:22 |
wallyworld | ok, will revert | 08:23 |
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:26 |
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:27 |
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:28 |
fwereade | voidspace, thinking/spooling | 08:30 |
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:32 |
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:33 |
axw | wallyworld: no, I don't want PrepareConfigParams getting worse than it is already | 08:34 |
wallyworld | ok | 08:34 |
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:35 |
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:36 |
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:37 |
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:38 |
fwereade | voidspace, cheers | 08:41 |
rock_ | Hi. How can I set bugs-url and homepage for my newly developed charm? Please anyone respond to this. | 09:05 |
wallyworld | marcoceppi: ^^^^^^ you around to help? | 09:42 |
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:43 |
wallyworld | ok, will go feed dog etc | 09:44 |
perrito666 | Morning | 10:00 |
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:03 |
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:06 |
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:42 |
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:47 |
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 | 10:48 |
dimitern | frobware, babbageclunk: hey guys, I've updated http://reviews.vapour.ws/r/5559/ and still need +1 to land it | 11:12 |
frobware | jam: ^^ based on our current discussion we may want to look at this again | 11:21 |
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:22 |
* dimitern steps out for ~45m | 11:55 | |
axw | wallyworld: red herring it seems, I had the same failure on master. running tests again and then will propose | 12:16 |
wallyworld | ok | 12:17 |
wallyworld | looked good from what i saw | 12:17 |
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:22 |
wallyworld | axw: let me know if you're happy with the latest version of mine; i've alredy fixed the controller uuid thing | 12:24 |
axw | wallyworld: looking | 12:26 |
axw | wallyworld: LGTM with that field removed | 12:48 |
wallyworld | axw: awesome, ta. yours is almost dome landing hopefully | 12:48 |
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> | 12:49 |
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:07 |
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:11 |
wallyworld | you can come back to it | 13:12 |
babbageclunk | wallyworld: I'm definitely feeling that too. | 13:12 |
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:13 |
babbageclunk | yeah, absolutely - letting your subconscious have a go at it in the background wh | 13:14 |
babbageclunk | rogue wh | 13:15 |
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:16 |
alexisb | babbageclunk, see priv chat | 13:17 |
dimitern | jam, are you around? | 13:17 |
mup | Bug # changed: 1573136, 1595617, 1597318, 1598329, 1604988 | 13:19 |
dimitern | babbageclunk: if you can have a look at http://reviews.vapour.ws/r/5559/ again, I'd appreciate a +1 :) | 13:21 |
mup | Bug # opened: 1595617, 1597318, 1598329, 1604988 | 13:28 |
babbageclunk | dimitern: yup, lookin now | 13:35 |
babbageclunk | g | 13:35 |
=== natefinch-afk is now known as natefinch | ||
mup | Bug # changed: 1595617, 1597318, 1598329, 1604988 | 13:37 |
dimitern | babbageclunk: ta! | 13:46 |
babbageclunk | dimitern: LGTM! | 13:54 |
dimitern | babbageclunk: tyvm | 13:57 |
katco | voidspace: natefinch: standup time | 14:01 |
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:29 |
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:30 |
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:31 |
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:32 |
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:33 |
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:34 |
natefinch | frobware: sounds good | 14:35 |
natefinch | mgz: randomish - https://play.golang.org/p/lzGvkm9VxC | 14:35 |
natefinch | mgz: it appears as though small maps are just occasionally randomized | 14:39 |
mgz | that is interesting, and pretty odd | 14:43 |
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:44 |
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:45 |
rock | dimitern: So I am thinking it might be a juju-gui bug. | 14:46 |
frobware | natefinch: you'll need a server ISO before we start | 14:50 |
natefinch | frobware: I can get that | 14:51 |
frobware | natefinch: xenial if you want MAAS 2.x | 14:51 |
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:52 |
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:53 | |
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:54 |
mgz | okay, I'm going to go ahead and change this delete implemtation to preserve order | 14:55 |
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:56 |
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:57 |
rock | dimitern: Yes. | 14:58 |
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 | 14:59 |
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:00 |
natefinch | perrito666: well, no... sometimes it decides to be random, and a lot of the time it decides not to be | 15:01 |
perrito666 | its random | 15:02 |
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:03 |
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:04 |
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:07 |
frobware | natefinch, katco: do we still want to setup locally? | 15:08 |
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:09 |
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:10 |
frobware | natefinch: https://hangouts.google.com/hangouts/_/canonical.com/andrew-mcdermot?authuser=0 | 15:11 |
dimitern | rock, right and your charm - was it showing xenial as well? | 15:18 |
katco | voidspace: sorry for delay, meetings... np about standup. how goes migrations? | 15:30 |
voidspace | katco: there's progress - it compiles, so mostly fixing tests, so not far off now. Probably tomorrow though. | 15:31 |
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:32 |
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:33 |
natefinch | frobware: all installed | 15:39 |
frobware | natefinch: ok let's jump back in to the HO | 15:40 |
redir | morning | 16:00 |
mgz | heya redir | 16:04 |
redir | :) | 16:04 |
macgreagoir | g'day redir | 16:05 |
frobware | katco, natefinch: all done. working maas setup. \o/ | 16:19 |
katco | frobware: ya! thanks a lot frobware | 16:19 |
redir | \o/ | 16:20 |
redir | bbiab, going for a haircut. | 16:50 |
=== frankban is now known as frankban|afk | ||
lazyPower | Hey core devs o/ do juju-gui bugs get targeted against http://launchpad.net/juju now that its moved into core? | 17:06 |
natefinch | lazyPower: no idea | 17:09 |
cmars | hatch, do you know? ^^ | 17:10 |
* hatch looks | 17:10 | |
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:11 |
hatch | and it's fixed in gui tip | 17:12 |
hatch | lazyPower: https://github.com/juju/juju-gui/issues/1937 | 17:12 |
lazyPower | https://github.com/juju/juju-gui/issues/1966 | 17:13 |
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:14 |
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:15 |
=== bcsaller_ is now known as bcsaller | ||
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:21 |
hatch | lol definitely not | 17:22 |
hatch | or maybe I have been and I just don't know it yet! | 17:22 |
tvansteenburgh | can anyone give me an example of the 'directive' and 'scope' portions of a placement | 17:46 |
tvansteenburgh | like if i have lxc:7, is that all directive, and the default scope is the model? | 17:47 |
tvansteenburgh | basically trying to figure out how to convert a placement string into a Placement map | 17:48 |
katco | tvansteenburgh: try: https://github.com/juju/charm/blob/aece7b0e56c298641968239a7fa0b3466afa6ef5/bundledata.go#L626-L629 | 17:49 |
tvansteenburgh | katco: thanks! | 17:59 |
katco | tvansteenburgh: np, happy hacking | 18:00 |
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:01 |
mgz | natefinch: around still? | 18:03 |
natefinch | mgz: I exist in this reality. | 18:03 |
mgz | :D | 18:03 |
perrito666 | ok, apparently its impossible to bootstrap juju from my ISP | 18:04 |
perrito666 | in aws | 18:04 |
* perrito666 goes a bit closer | 18:05 | |
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:08 |
mgz | natefinch: so, I'd appreciate an eye on that part | 18:09 |
natefinch | mgz: looking | 18:17 |
natefinch | god I hate significant whitespace | 18:39 |
natefinch | whats the opposite of deploy in maas? | 18:40 |
natefinch | (unrelated to my previous statement) | 18:40 |
mgz | natefinch: I was wondering | 18:41 |
mgz | natefinch: `maas ENV machine delete` for 2, I think it's `... node delete` in 1 | 18:42 |
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 | 18:43 |
mgz | natefinch: repoke about review | 19:48 |
natefinch | mgz: oops, sorry, had started looking at it then got distracted by maas stuff | 19:50 |
natefinch | mgz: reviewde | 20:20 |
mgz | natefinch: ta! | 20:22 |
cmars | how do i connect to juju's mongodb on xenial? | 21:38 |
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:41 |
thumper | menn0: ^^ | 21:44 |
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:45 |
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:46 |
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:48 |
menn0 | cmars: https://gist.github.com/mjs/0d0b89356654de04adf4935860642c5f | 21:51 |
menn0 | cmars: run it from your machine like this: juju-db <controller:model> | 21:52 |
menn0 | where "model" is the controller model name | 21:52 |
menn0 | thinking about it, it should probably just assume the name "controller" | 21:53 |
cmars | menn0, thanks! | 21:54 |
cmars | this is going in my tools repo.. | 21:54 |
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:56 |
cmars | menn0, perfect, even better | 21:57 |
wallyworld | thumper: menn0: you free for a chat? in s.o. h.o.? | 22:33 |
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:35 |
katco | that feeling when you can iterate through a change because it has an actual unit test | 22:51 |
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:53 |
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:55 |
katco | wallyworld: yes, but it would have taken significantly longer to run | 22:56 |
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:57 |
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:58 |
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 :) | 22:59 |
wallyworld | cmars: yeah, i blame thumper :-) | 23:00 |
thumper | wallyworld: http://reviews.vapour.ws/r/5580/ | 23:04 |
menn0 | wallyworld: sorry, I've been AFK | 23:09 |
menn0 | wallyworld: still want to talk? | 23:10 |
perrito666 | I am late for standup sorry ill be 10 late | 23:14 |
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:15 |
katco | perrito666: if you're late by 10 years i'll buy you a beer in 5 | 23:21 |
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:27 |
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 | 23:28 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!