| mup | Bug #1594211 opened: creating hosted model: model already exists <juju-core:New> <https://launchpad.net/bugs/1594211> | 01:14 |
|---|---|---|
| menn0 | thumper: client side api for the previous PR: http://reviews.vapour.ws/r/5106/ | 02:26 |
| menn0 | thumper: SortStringsNaturally does exactly what I need without modification | 03:03 |
| thumper | cool | 03:03 |
| menn0 | thumper: move it to juju/utils? | 03:03 |
| thumper | sure | 03:03 |
| wallyworld | menn0: not sure if you care, i left a comment or two on the pr | 03:04 |
| wallyworld | i do disagree with declaring the domain object in the api layer | 03:04 |
| menn0 | wallyworld: ok cheers. i'll take a look. | 03:04 |
| mup | Bug #1594232 opened: Inconsistent capitalization in juju command help <juju-core:In Progress by cherylj> <https://launchpad.net/bugs/1594232> | 03:05 |
| cherylj | wallyworld: did you and / or axw see bug 1593761 ? | 03:08 |
| mup | Bug #1593761: Cannot bootstrap in gce using jsonfile in credentials <add-credential> <blocker> <bootstrap> <ci> <gce-provider> <regression> <juju-core:Triaged> <https://launchpad.net/bugs/1593761> | 03:08 |
| wallyworld | saw it float past yeah, will need to fix it | 03:08 |
| menn0 | thumper, wallyworld: the reason that diff is messed up is that I forgot to switch branches when doing this work | 03:08 |
| menn0 | thumper, wallyworld: that's why the PR description doesn't match the work | 03:09 |
| wallyworld | \o/ | 03:09 |
| menn0 | wallyworld: thanks for your comments. I'll address them after I fix something else. | 03:10 |
| wallyworld | ok, if you agree | 03:10 |
| menn0 | wallyworld: in most cases yes. I'm not sure of the value of moving those structs in this case. would you be ok with them being in core/migration? | 03:11 |
| cherylj | ok, thanks wallyworld - just wanted to make sure it was on your radar | 03:11 |
| wallyworld | menn0: that's where i think they should be yes | 03:11 |
| menn0 | wallyworld: ok will do that | 03:11 |
| wallyworld | cherylj: yeah, not sure when it broke exactly | 03:11 |
| wallyworld | menn0: thanks, hopefully you agree with the benefit of managing that domain logic outside of the api layer | 03:12 |
| cherylj | wallyworld: ok, I'll take a look tomorrow if it's still needing attention | 03:12 |
| wallyworld | cherylj: it probably is broken still, just need to get a minute to look at it | 03:12 |
| menn0 | wallyworld: well there's no domain "logic" per se, just data. | 03:13 |
| wallyworld | but that data is consumed elsewhere | 03:13 |
| wallyworld | by other business logic | 03:13 |
| menn0 | wallyworld: sure | 03:13 |
| wallyworld | and the data is migration specific and generally not related to any api concerns | 03:14 |
| wallyworld | thumper: the diff is a bit messed up - it claims manifold.go files have been deleted - i'm guessing that's due to cherry picking from master? | 04:22 |
| mup | Bug #1570791 changed: ERROR wait: no child processes with juju run on ppc64el <run> <juju-core:Expired> <https://launchpad.net/bugs/1570791> | 04:24 |
| thumper | wallyworld: um.. no | 04:30 |
| thumper | which manifold? | 04:30 |
| thumper | I have just pushed some extra test fixes | 04:30 |
| thumper | wallyworld: machinelock worker is entirely deleted | 04:31 |
| thumper | as it isn't needed | 04:31 |
| wallyworld | ok | 04:31 |
| thumper | wallyworld: my machine is currently just taking its time on state and uniter tests | 04:32 |
| thumper | but all else now good | 04:32 |
| wallyworld | ok, all loos good so far, there will be a lot of happy people with this fix | 04:32 |
| thumper | sometimes you forget how far we have come since 1.25 | 04:33 |
| thumper | geez | 04:33 |
| wallyworld | yeah, i can't use 1.25 now :-) | 04:33 |
| thumper | hmm 1 failure in worker/uniter | 04:36 |
| thumper | looks intermittent | 04:36 |
| thumper | trying again | 04:36 |
| wallyworld | thumper: lgtm | 04:38 |
| thumper | hmm... seems like it might be real | 04:42 |
| * thumper digs some | 04:42 | |
| thumper | ah crap | 04:46 |
| thumper | there is a race in this test... I'm sure of it | 04:46 |
| thumper | but not one I've added | 04:46 |
| menn0 | babbageclunk: would you mind taking a look at this? http://reviews.vapour.ws/r/5108/ | 08:19 |
| babbageclunk | menn0: sure | 08:19 |
| menn0 | babbageclunk: no rush, just some time during your day | 08:19 |
| * menn0 is about to stop again | 08:19 | |
| * fwereade passes by briefly to say: please, someone, look at http://reviews.vapour.ws/r/5042/ -- it's almost all s/common/facade/ and the only tricky bit is the facade.Factory interface change, which is transparent to almost all the actual facade registrations | 08:37 | |
| dimitern | frobware: ping | 08:51 |
| frobware | dimitern: hi | 08:51 |
| dimitern | frobware: hey, so I'm adding tests for --keep-source-stanzas to the bridge script | 08:51 |
| dimitern | frobware: and I've realized the TestBridgeScriptWithUndefinedArgs might be wrong | 08:52 |
| dimitern | frobware: it looks like we're expecting an error without arguments, but assuming the configFile exists, it actually passes ok | 08:53 |
| frobware | dimitern: ahh :( | 08:54 |
| dimitern | frobware: and passing "# no config" as config file path doesn't work | 08:54 |
| dimitern | frobware: I suggest we drop that test, as we're already testing the 'default prefix' and 'explicit prefix' cases | 08:55 |
| frobware | dimitern: ok | 08:56 |
| dimitern | frobware: alternatively, we can just fold the 'no prefix' tests into one of the others | 08:56 |
| frobware | dimitern: it was always an odd-ball test anyway - you can see that as it's really the only one that doesn't follow the existing pattern | 08:56 |
| dimitern | frobware: yeah.. I've refactored runScript to take args struct | 08:57 |
| dimitern | frobware: and discovered that | 08:57 |
| dimitern | frobware: and it seems the 'default prefix' cases are already testing the 'no prefix' (no args) case | 08:57 |
| dimitern | frobware: so dropping the 'undefined args' test is ok | 08:58 |
| dimitern | babbageclunk: standup? | 09:02 |
| babbageclunk | oops, sorry! | 09:02 |
| mup | Bug #1594290 opened: Duplicate key error on juju.txns.stash creating model <juju-core:New> <https://launchpad.net/bugs/1594290> | 09:12 |
| dimitern | frobware: updated http://reviews.vapour.ws/r/5087/ | 09:32 |
| dimitern | frobware: do you think it's ok to land now? | 09:32 |
| frobware | dimitern: I was just updating my images to daily and was going to try again | 09:32 |
| dimitern | frobware: ok | 09:32 |
| frobware | dimitern: the issue with --keep-source-stanzas is that this is now fixed in cloud-init | 09:33 |
| frobware | dimitern: can we HO briefly? | 09:34 |
| dimitern | frobware: ok | 09:34 |
| dimitern | frobware: standup HO? | 09:34 |
| frobware | yep | 09:34 |
| dimitern | i'm in | 09:35 |
| dimitern | frobware: which curtin version was supposed to have the fix? | 10:24 |
| frobware | dimitern: 389 | 10:24 |
| dimitern | frobware: I see curtin/trusty 0.1.0~bzr385-0ubuntu1 all | 10:24 |
| frobware | dimitern: yep, you'll need -proposed | 10:24 |
| frobware | aim@maas19:~$ dpkg -l |grep curtin | 10:24 |
| frobware | ii curtin 0.1.0~bzr389-0ubuntu1~14.04.1 all Library and tools for the curtin installer | 10:24 |
| frobware | ii curtin-common 0.1.0~bzr389-0ubuntu1~14.04.1 all Library and tools for curtin installer | 10:24 |
| frobware | ii python-curtin 0.1.0~bzr389-0ubuntu1~14.04.1 all Library and tools for curtin installer | 10:24 |
| dimitern | frobware: after apt update & full-upgrade, xenial-proposed is enabled | 10:24 |
| dimitern | frobware: ooh, sorry this is on my maas 1.9.3 / trusty actually | 10:25 |
| frobware | dimitern: I also added http://pastebin.ubuntu.com/17587166/ | 10:26 |
| frobware | dimitern: and then explicitly installed with -t trusty-proposed to limit the damage | 10:27 |
| dimitern | frobware: yeah, just enabled trusty-backports and trusty-proposed, that got me curtin 389 | 10:28 |
| dimitern | frobware: now updating the images to the dailies, rebooting, then bootstrapping trusty and xenial | 10:29 |
| frobware | dimitern: I didn't need dailies | 10:30 |
| dimitern | frobware: wanted to make sure everything is up-to-date | 10:31 |
| frobware | dimitern: seems like adding to the entropy pool | 10:31 |
| dimitern | frobware: well, we'll see :) | 10:31 |
| dimitern | frobware: fyi, I'm using commit https://github.com/juju/juju/commit/605940de5f0311a23080bb7ceaad51b370bca4bd#diff-37e8df194cdfac21c9809d60711b5b26 (the equivalent to the one you pasted, but for 1.25) | 10:43 |
| frobware | dimitern: yep, good. | 10:43 |
| dimitern | frobware: so far I managed to bootstrap on a node with a bond (using balance-alb) and 1 vlan on it, on both trusty and xenial | 11:01 |
| frobware | dimitern: so maybe needs real h/w | 11:02 |
| dimitern | frobware: however, I wasn't able to bootstrap with mode balance-tlb on xenial, just trusty | 11:02 |
| frobware | dimitern: heh, so the other way around. :/ | 11:03 |
| frobware | wow | 11:03 |
| frobware | what a mess | 11:03 |
| dimitern | frobware: also in after bootstrap there's no dhclient in sight | 11:03 |
| frobware | dimitern: because of curtin 389 | 11:03 |
| dimitern | frobware: yeah, I think so | 11:03 |
| frobware | dimitern: well, you're also using ifdown which will DTRT | 11:04 |
| dimitern | frobware: so now what - deploy trusty & xenial without juju on those same nodes, then try running the bridge script manually? | 11:04 |
| frobware | dimitern: the interesting case has not arisen (i.e., LACP) | 11:04 |
| frobware | dimitern: though the balance-tlb failure on xenial was unexpected | 11:05 |
| dimitern | frobware: it did deploy fine (according to maas ui), but no connectivity | 11:06 |
| dimitern | frobware: I don't have a 1.9 hw maas anymore, only 2.0 | 11:06 |
| frobware | dimitern: want to use mine? | 11:07 |
| dimitern | frobware: I could, but not sure what that will prove - you can do it more easily anyway.. | 11:07 |
| frobware | dimitern: true | 11:07 |
| frobware | dimitern: I was trying to avoid working on the same issue | 11:08 |
| dimitern | frobware: should I try without juju on t & x, then apply the patches to ifenslave / ifupdown, then run the bridge script manually? | 11:09 |
| frobware | dimitern: for the balanace-tlb issue? I would say yes | 11:09 |
| dimitern | frobware: ok, I'll change the modes to be balance-tlb on both nodes | 11:10 |
| dimitern | frobware: but I need to know what patches to apply | 11:10 |
| === cargonza is now known as cargonza-holiday | ||
| frobware | dimitern: pick the difs out of https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=742410 and https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=791906 | 11:11 |
| dimitern | frobware: ok, looking | 11:12 |
| dimitern | frobware: it looks like those two: http://anonscm.debian.org/cgit/collab-maint/ifenslave.git/diff/?id=c4ce52c and http://anonscm.debian.org/cgit/collab-maint/ifenslave.git/diff/?id=d97b18d | 11:14 |
| dimitern | frobware: anything else? | 11:14 |
| rogpeppe | dimitern: ping | 11:14 |
| dimitern | rogpeppe: pong | 11:15 |
| rogpeppe | dimitern: hiya | 11:15 |
| rogpeppe | dimitern: have you got a moment for a chat, by any chance? | 11:15 |
| frobware | dimitern: don't think so | 11:15 |
| dimitern | rogpeppe: is it ok if we do it in ~1h? | 11:16 |
| rogpeppe | dimitern: sure np | 11:16 |
| dimitern | rogpeppe: I'm kinda in the middle of something | 11:16 |
| rogpeppe | dimitern: that's fine | 11:16 |
| dimitern | rogpeppe: thanks, will ping you then | 11:16 |
| rogpeppe | dimitern: ta | 11:17 |
| dimitern | frobware: which patches then should I use? | 11:17 |
| dimitern | frobware: ah, sorry | 11:17 |
| dimitern | frobware: got it, doing it now | 11:17 |
| mup | Bug #1594332 opened: Unit reports status about agent before machine is available <juju-core:New> <https://launchpad.net/bugs/1594332> | 11:27 |
| frobware | dimitern: actually, given that you do have a failure it would be worthwhile verifying/understanding/experimenting with --no-scripts | 11:28 |
| dimitern | frobware: it's worth noting that even though trusty deployment with mode=balance-tlb succeeded, I can see issues | 11:29 |
| frobware | dimitern: is that with those patches applied? | 11:29 |
| dimitern | frobware: unlike with xenial, where I see no issues, with the trusty node I see considerable lag on the ssh connection | 11:30 |
| frobware | dimitern: I thought xenial failed | 11:30 |
| dimitern | frobware: no patches yet, but every few keystrokes it appears frozen for a few secondes, then it's ok, then again lagging.. | 11:30 |
| dimitern | frobware: it failed with juju | 11:30 |
| frobware | dimitern: ah, ok | 11:31 |
| dimitern | frobware: I'm applying the patches now and trying the bridge script | 11:31 |
| babbageclunk | dimitern: What's the apiserver/client package all about? It seems oddly named. | 11:34 |
| dimitern | babbageclunk: it's the server-side implementation of the client api facade (i.e. the one used by CLI commands, not using another client api facade, like application) | 11:35 |
| babbageclunk | dimitern: Ok, thanks - it seems like that's where I need to add my field to the unit status info. | 11:36 |
| dimitern | babbageclunk: unless it's in the status facade? | 11:36 |
| dimitern | babbageclunk: well, see what gets used for cmd/juju/commands/status? | 11:37 |
| frobware | dimitern: lockfile-create /var/lock/ntpdate --< this is what I seen on trusty and deadlocked/locked/stopped/broken/the-end. | 11:37 |
| frobware | dimitern: let me retract that.... ^^ | 11:37 |
| frobware | dimitern: do you have a version of the script from March but with the reduced iface options? | 11:38 |
| babbageclunk | dimitern: ooh, good idea. | 11:38 |
| dimitern | frobware: yeah, I was seeing that as well, with more than 1 vlan | 11:38 |
| frobware | dimitern: it does eventually go away | 11:38 |
| babbageclunk | dimitern: also, another random question - trying to bootstrap against aws, I get this error: ERROR failed to bootstrap model: cannot start bootstrap instance: missing controller UUID | 11:38 |
| dimitern | babbageclunk: that's a known bug introduced recently - not sure if it's fixed | 11:39 |
| frobware | babbageclunk: this was mentioned on friday. I went back a few commit to make local progress | 11:39 |
| dimitern | frobware: what do you mean 'reduced iface options' ? | 11:39 |
| dimitern | frobware: the changes moving addresses to the bridge? | 11:40 |
| babbageclunk | dimitern: Ah, ok, thanks. Thought it might have been something I'd broken in my config. | 11:40 |
| dimitern | frobware: I don't have such version yet | 11:40 |
| frobware | dimitern: ok, np | 11:43 |
| dimitern | frobware: slightly modified patches with fixed paths: http://paste.ubuntu.com/17589198/ (ifenslave-2.5.patch), and http://paste.ubuntu.com/17589204/ (ifenslave-2.7.patch) | 11:44 |
| dimitern | applying now | 11:44 |
| frobware | dimitern: dang! Just forget (again!) my 1.9 h/w maas is NOT using curtin 389 | 11:45 |
| dimitern | frobware: that's why it breaks for trusty w/o juju I guess | 11:45 |
| frobware | dimitern: yep | 11:45 |
| mup | Bug #1594335 opened: Juju possibly confuses account with credential in add-model <juju-core:New> <https://launchpad.net/bugs/1594335> | 11:46 |
| dimitern | frobware: bad news.. | 12:13 |
| frobware | dimitern: it works? :) | 12:13 |
| dimitern | frobware: just the opposite :) | 12:13 |
| dimitern | frobware: applying those 2 patches on xenial wasn't quite clean (only 2 hunk out of 6 hunks succeeded, the others were already applied) | 12:14 |
| dimitern | frobware: pretty much the same on trusty as well | 12:14 |
| dimitern | frobware: however, I rebooted the xenial node and now it never gets out of "Started Raise network interfaces." | 12:15 |
| dimitern | frobware: now rebooted the trusty node to see if it will be the same.. | 12:16 |
| dimitern | frobware: well, I can (barely) ssh after the reboot into the trusty node | 12:17 |
| frobware | dimitern: the trouble is we don't know if your really laggy connection is because of an ethernet USB dongle... not acting like a real h/w nuc | 12:18 |
| frobware | nic | 12:18 |
| dimitern | frobware: the lag I was describing earlier got a lot worse even before the reboot, and it's still there (freezes for about ~10s constantly, ssh feels like on a 300 baud serial link) | 12:18 |
| dimitern | frobware: this is purely on kvm - 2 nics on each node, connected to the same bridge (maas internal network) | 12:19 |
| frobware | dimitern: oh | 12:19 |
| dimitern | frobware: so if anything the patches made things unusable on xenial, and made no difference on trusty | 12:20 |
| frobware | dimitern: round and round and round ... :/ | 12:20 |
| dimitern | frobware: I can try using balance-alb on both an see.. | 12:20 |
| dimitern | frobware: at this point I don't think running the bridge script will make any difference.. | 12:20 |
| frobware | dimitern: agreed | 12:20 |
| dimitern | frobware: trying with balance-alb on both nodes | 12:23 |
| * dimitern steps out for ~30m | 12:24 | |
| * frobware too - 389 and daily images gives me an eth0.cfg still... | 12:30 | |
| voidspace | dimitern: frobware: babbageclunk: an easy one - http://reviews.vapour.ws/r/5110/ | 12:30 |
| babbageclunk | voidspace, dimitern, frobware: review board's being weird for me - slow requests and losing comments. Anyone else seeing that? | 12:59 |
| dimitern | babbageclunk: not today, but I've just started reviewing voidspace's PR now | 13:02 |
| babbageclunk | dimitern: Seems to have come right now. | 13:02 |
| dimitern | voidspace: reviewed | 13:05 |
| dimitern | frobware: so with balance-alb there's no lag on trusty like before, xenial is the same | 13:08 |
| dimitern | frobware: however I manged to break everything by running the bridge script after applying both ifenslave patches and rebooting (hug at 'ifdown -a --exclude=lo'); reboot didn't help | 13:09 |
| dimitern | frobware: now redeploying and will run the script in a tmux session to let if finish | 13:10 |
| dimitern | s/if/it/ | 13:11 |
| dimitern | rogpeppe: hey, I have some time now if you wanna chat? | 13:11 |
| rogpeppe | dimitern: yeah, please | 13:12 |
| dimitern | rogpeppe: HO or IRC ? | 13:12 |
| rogpeppe | dimitern: i'm in https://hangouts.google.com/hangouts/_/canonical.com/gogogo?authuser=1 | 13:12 |
| dimitern | rogpeppe: omw | 13:12 |
| mup | Bug #1588143 changed: cmd/juju/controller: send on a closed channel panic <blocker> <race-condition> <juju-core:Fix Released by dave-cheney> <https://launchpad.net/bugs/1588143> | 13:43 |
| dimitern | frobware: ping | 13:47 |
| frobware | dimitern: pong | 13:47 |
| dimitern | frobware: so with the patches the bridge script seems to hang on ifdown --exclude-lo on both xenial and trusty | 13:47 |
| frobware | dimitern: :( | 13:48 |
| dimitern | frobware: and even though it shouldn't have made any changes, rebooting does not restore connectivity | 13:48 |
| dimitern | frobware: instead it gets into 'waiting 120 seconds for network device' | 13:49 |
| dimitern | frobware: so I guess the patches are not sufficient (rebooting after applying them causes the same issue, so not related to the bridge script) | 13:50 |
| frobware | dimitern: seems so | 13:50 |
| dimitern | frobware: perhaps we need to patch more than just ifenslave (and its scripts) | 13:51 |
| dimitern | frobware: on xenial, there are /sbin/ifenslave and /sbin/ifenslave-2.6; apt list reports ifenslave is 2.7 (on trusty, as expected - 2.4) | 13:52 |
| dimitern | frobware: retrying again, but this time I'll enable console login with 'ubuntu' before I reboot | 13:55 |
| dimitern | frobware: so running the bridge script from the console on xenial, after installing bridge-utils (which was missing) worked, connectivity ok, incl. after a reboot | 14:10 |
| frobware | dimitern: yeah, the lack of brctl is a pain if you forget | 14:10 |
| dimitern | frobware: on trusty (as I didn't install bridge-utils first), no connectivity | 14:10 |
| frobware | dimitern: so to be expected | 14:11 |
| dimitern | frobware: oops, sorry - so trusty is fine, xenial isn't | 14:11 |
| dimitern | frobware: to restore connectivity on xenial, I replace /e/n/i with /e/n/i-before-add-juju-bridge and rebooted | 14:13 |
| dimitern | frobware: now it was ok, installed bridge-utils, then ran the script - it was ok, incl. after reboot | 14:15 |
| frobware | dimitern: so both t & x == OK? | 14:15 |
| dimitern | frobware: interestingly, I see no address on bond0, just on juju-br0 (xenial and trusty both) | 14:15 |
| frobware | dimitern: and that's without us removing all the options (e.g., "address") from ENI? | 14:16 |
| dimitern | frobware: yeah, now both are working, and no duped addresses | 14:16 |
| dimitern | frobware: correct, using the bridge script from https://github.com/juju/juju/blob/605940de5f0311a23080bb7ceaad51b370bca4bd/provider/maas/add-juju-bridge.py | 14:16 |
| frobware | dimitern: or is the lack of duplication because you know have curtin doing the right thing? | 14:17 |
| dimitern | frobware: the only thing I needed to fix is to use #!/usr/bin/env python3 (on xenial) | 14:17 |
| frobware | dimitern: so it's all good -- as in around March Xth it was all good anyway? | 14:17 |
| dimitern | frobware: yeah, March, 7th | 14:18 |
| frobware | dimitern: we beat release date then :-) | 14:18 |
| dimitern | frobware: I'll try now to restore /e/n/i before the script, reboot, then run it with --bridge-prefix=br- to see how it works for the multi-bridge case | 14:18 |
| frobware | dimitern: this is my observation too - the only screw up seems to be if you have a LACP bond | 14:19 |
| dimitern | frobware: no issues with the multi-bridge case, both t & x | 14:24 |
| natefinch | gsamfira: got a a few minutes? I want to talk about that npipe bug again | 14:24 |
| gsamfira | natefinch: sure :) | 14:25 |
| dimitern | frobware: so to recap: we need bridge-utils installed (we do that in juju), either apply those patches to ifenslave or install 2.7 or later from ppa, run the script; optionally reboot | 14:26 |
| frobware | dimitern: ahh... so I missed the "the patches help" - they do? | 14:26 |
| dimitern | frobware: I still think it's good to apply the changes to the script so it renders a cleaner /e/n/i, but no need for fancy dynamic reconfiguring | 14:26 |
| frobware | dimitern: so want me to try locally with my LACP config? | 14:27 |
| frobware | dimitern: (before we celebrate) | 14:27 |
| dimitern | frobware: yes, let's do that | 14:27 |
| frobware | dimitern: ok, let's HO to ensure I do this right | 14:27 |
| dimitern | frobware: meanwhile I'll try the same, without the patches to see if it's different | 14:27 |
| dimitern | frobware: joining standup HO | 14:28 |
| natefinch | gsamfira: so here's my thoughts... there's an obvious race condition in the code... that's easily fixable by being more broad with how we use the mutex in the pipelistener. However, it seems like there may also be the problem we talked about last week, where the pipe gets closed in the middle of an accept from another process or another goroutine that happens to use the same fd but different in-memory pipelistener. it would | 14:28 |
| natefinch | gsamfira: it would seem like the answer to that latter problem might best be described as "don't do that" | 14:28 |
| natefinch | gsamfira: as in - maybe the problem is that we're doing that in a test and should not | 14:29 |
| gsamfira | natefinch: its not only a matter of doing that in a test. A named pipe can be closed by anyone that has a handle on it. We need a better way to test if the pipe is still open before doing a Connect/WaitForSingleObject on it | 14:30 |
| natefinch | gsamfira: there's no way to do that without a race condition | 14:32 |
| gsamfira | silly named pipes | 14:32 |
| natefinch | gsamfira: silly windows api... it's the waitforcomlpetion call that doesn't have a way to ensure that you're waiting on what you expect you're waiting on. | 14:33 |
| gsamfira | natefinch: yeah...unfortunately. We may have to resort to polling...which sucks | 14:34 |
| marcoceppi | need help, getting some macaroon error on deploy? http://paste.ubuntu.com/17595425/ | 14:50 |
| marcoceppi | rick_h_: ^? | 14:51 |
| rick_h_ | marcoceppi: looking | 14:52 |
| rick_h_ | marcoceppi: sec, let me ask a couple of questions please | 14:52 |
| marcoceppi | rick_h_: ask away | 14:52 |
| rick_h_ | marcoceppi: sorry, asking the other folks that run the macaroon index of the world | 14:53 |
| marcoceppi | cool | 14:53 |
| marcoceppi | this is on gmaas if it helps | 14:53 |
| rick_h_ | marcoceppi: hmmm, shouldn't that I can think of. Shouldn't be unique that is. | 14:54 |
| mup | Bug #1594415 opened: Juju register should offer a name for the controller <juju-core:New> <https://launchpad.net/bugs/1594415> | 14:58 |
| redir | katco: yt? | 15:08 |
| babbageclunk | dimitern: do you know if there's a util somewhere for picking the most common from a set of values? | 15:11 |
| dimitern | babbageclunk: most common like how ? | 15:23 |
| babbageclunk | dimitern: If I've got 20 units, and 15 of them say they have version 1.2.3, I want to use that as the value (with a * indicating mixed) at the application level. | 15:24 |
| mup | Bug #1555815 changed: register allows for controller name confusion <2.0-count> <juju-release-support> <usability> <juju-core:Triaged> <https://launchpad.net/bugs/1555815> | 15:28 |
| dimitern | babbageclunk: is this for upgrade-juju --upload-tools? | 15:31 |
| dimitern | babbageclunk: or upgrade-charm ? | 15:31 |
| babbageclunk | dimitern: no, for status - adding workload version | 15:31 |
| dimitern | babbageclunk: I'm not aware of an existing tool you could use.. it should be easy to script it though.. | 15:33 |
| babbageclunk | dimitern: ok - I've coded it up now. | 15:34 |
| babbageclunk | dimitern: It ended up being fairly specific anyway. | 15:38 |
| babbageclunk | dimitern, frobware: sorry, can't make it to the network hangout today | 16:02 |
| frobware | babbageclunk: ok | 16:03 |
| dimitern | babbageclunk: np | 16:04 |
| marcoceppi | rick_h_ https://bugs.launchpad.net/juju-core/+bug/1594440 | 16:06 |
| mup | Bug #1594440: juju gives weird errors about macaroons when a read-only user <juju-core:New> <https://launchpad.net/bugs/1594440> | 16:06 |
| mup | Bug #1594440 opened: juju gives weird errors about macaroons when a read-only user <juju-core:New> <https://launchpad.net/bugs/1594440> | 16:07 |
| natefinch | cmars: you around? | 16:13 |
| katco | redir: here now, what's up? | 16:43 |
| bdx | hey whats up guys, is openstack provider currently broken for 2.0? | 17:10 |
| bdx | I am finding a bunch of bugs revolving around bootstrapping the openstack provider .... none of them are resolved ... I seem to be hitting the "index file has no data for cloud" no matter what I do .... can anyone give some insight on this? thx | 17:14 |
| alexisb | bdx, that we are aware of | 17:14 |
| alexisb | bdx, are you working off beta9?? | 17:15 |
| bdx | alexisb: I haven't gotten a successfull bootstrap of an openstack cloud using any 2.0 yet ... | 17:16 |
| bdx | alexisb: yes | 17:16 |
| alexisb | :( | 17:16 |
| bdx | alexisb: have you personally bootstrapped to openstack provider using 2.0? | 17:17 |
| alexisb | bdx, not openstack (I use mostly maas and lxd providers), but we do have passes in testing | 17:18 |
| alexisb | not sure if someone else on the channel has personal experience with openstack recently on 2.0 | 17:18 |
| bdx | alexisb: nice, ok. ... I feel like it must be operator error seeing as no one else is causing a stink about it ... | 17:20 |
| bdx | I mean ... pretty straight forward though ..... I get my openstack cloud and credentials added, but get the "index file" error no matter what | 17:21 |
| balloons | bdx, are you attempting to bootstrap a charm or bundle on an existing openstack? | 17:22 |
| balloons | I want to make clear if you are attempting to deploy openstack itself, or are attempting to use an openstack with juju 2 and deploying applications on it | 17:23 |
| bdx | balloons: I have a grizzly stack, liberty stack, and mitaka stack. I have the same issue trying to bootstrap any of them | 17:23 |
| bdx | balloons: bootstrap to existing private openstack(s) | 17:24 |
| balloons | bdx, can you provide a log of your attempted deployment? | 17:27 |
| natefinch | bdx: what's the word after "index file has no data for cloud" ? That error seems like it's failing to find the cloud in the simplestreams data | 17:27 |
| bdx | natefinch, balloons: http://paste.ubuntu.com/17603992/ | 17:29 |
| natefinch | bdx: seems like a simplestreams issue. Can you manually verify that http://cloud-images.ubuntu.com/releases/streams/v1/index.sjson has a region called RegionOne with that endpoint URL? | 17:30 |
| bdx | natefinch: the region is not my openstack "OS_REGION_NAME" ? | 17:31 |
| bdx | operator error | 17:31 |
| natefinch | bdx: I am not super familiar with openstack setup... so I'm not sure | 17:31 |
| natefinch | heh, well I fixed this test hang... evidently it never happens if you just enable verbose output :/ | 17:33 |
| bdx | natefinch, alexisb, balloons: I think I see what I'm doing wrong, the region specified in clouds.yaml should be a simplestreams region, not an "OS_REGION_NAME" | 17:34 |
| bdx | testing this now | 17:34 |
| bdx | thanks for your help you guys | 17:34 |
| alexisb | bdx, keep us posted if it works | 17:34 |
| * natefinch is happy to be a rubber duck whenever needed. :) | 17:34 | |
| balloons | bdx, :-) | 17:35 |
| bdx | aaawwwe | 17:35 |
| bdx | it so is not what I thought | 17:35 |
| bdx | http://cloud-images.ubuntu.com/releases/streams/v1/index.sjson | 17:35 |
| bdx | there is no "openstack" cloud there | 17:35 |
| bdx | thats why I think the region must be "OS_REGION_NAME" | 17:36 |
| bdx | so, the reason I think the region should be os-region-name is carried over from the region type in 1.x -> http://paste.ubuntu.com/17604538/ | 17:38 |
| bdx | thats why I think the region must be "OS_REGION_NAME" | 17:41 |
| mup | Bug #1593812 changed: Failed to bootstrap: missing controller UUID <blocker> <bootstrap> <juju-gui> <juju-core:Fix Released by wallyworld> <https://launchpad.net/bugs/1593812> | 18:08 |
| mup | Bug #1593838 changed: juju beta9 does not support "lxc" notation in bundles <blocker> <bundles> <cdo-qa> <cdo-qa-blocker> <ci> <regression> <juju-core:Fix Released by natefinch> <https://launchpad.net/bugs/1593838> | 18:08 |
| natefinch | bdx: sounds like it's a documentation and/or naming problem? | 18:10 |
| natefinch | (combined with a changed definition from 1.x, without a change to the name)? | 18:11 |
| bdx | natefinch: I guess .... | 19:02 |
| alexisb | redir, redir_, ping | 19:13 |
| cherylj | bdx: there was some bug recently about metadata-source not working | 19:24 |
| cherylj | let me see if I can pull it up | 19:24 |
| cherylj | bdx: bug 1591488 | 19:25 |
| mup | Bug #1591488: remove deprecated option --metadata-source <cpe-sa> <juju-core:Triaged> <https://launchpad.net/bugs/1591488> | 19:25 |
| cherylj | though, I'm not sure what conversation happened to lead to the conclusion in comment #2 | 19:25 |
| coreycb | I can't seem to get credentials right for openstack provider with beta9. anyone have some tips? http://paste.ubuntu.com/17612374/ | 19:59 |
| cherylj | coreycb: you'll need to put in some auth-type into your cloud definition in order to add-credential for it. | 20:12 |
| cherylj | coreycb: something like this: http://paste.ubuntu.com/17613239/ | 20:12 |
| cherylj | lmk if that doesn't work for you | 20:12 |
| === redir is now known as redir_lunch | ||
| mup | Bug #1172814 changed: Need a way to run an end-to-end test on a juju environment. <testing> <juju-core:Opinion> <https://launchpad.net/bugs/1172814> | 20:56 |
| mup | Bug #1172814 opened: Need a way to run an end-to-end test on a juju environment. <testing> <juju-core:Opinion> <https://launchpad.net/bugs/1172814> | 21:03 |
| mup | Bug #1172814 changed: Need a way to run an end-to-end test on a juju environment. <testing> <juju-core:Opinion> <https://launchpad.net/bugs/1172814> | 21:06 |
| === redir_lunch is now known as redir | ||
| davechen1y | thumper: of all the failed test runs I looked at this morning | 21:27 |
| davechen1y | 90% of the are caused by mongo shitting the bed | 21:27 |
| thumper | hmm | 21:28 |
| davechen1y | http://data.vapour.ws/juju-ci/products/version-4076/run-unit-tests-xenial-arm64/build-1021/consoleText | 21:29 |
| davechen1y | http://data.vapour.ws/juju-ci/products/version-4076/run-unit-tests-trusty-ppc64el-go1-6/build-793/consoleText | 21:29 |
| davechen1y | http://data.vapour.ws/juju-ci/products/version-4076/run-unit-tests-precise-amd64/build-4397/consoleText | 21:29 |
| alexisb | thumper, ping | 21:32 |
| thumper | coming | 21:32 |
| mup | Bug #1594578 opened: state: test failure in race build <juju-core:New> <https://launchpad.net/bugs/1594578> | 21:36 |
| mup | Bug #1594580 opened: lxd container invalid parent device name <blocker> <bundles> <ci> <lxd> <regression> <juju-core:Triaged> <https://launchpad.net/bugs/1594580> | 21:36 |
| alexisb | natefinch, ping | 21:38 |
| katco | natefinch: he usually leaves for dinner pretty sharply -46m ago | 21:47 |
| marcoceppi | dear core team: http://paste.ubuntu.com/17620137/ this is amazing, thank you! | 22:35 |
| anastasiamac | marcoceppi: :) | 22:38 |
| anastasiamac | marcoceppi: thank you for feedback \o/ | 22:39 |
| === bradm_ is now known as bradm | ||
| wallyworld | axw: perrito666: you guys around for standup? | 23:19 |
| perrito666 | Sorry didn't see that, it's a holiday here | 23:22 |
| perrito666 | Wallyworld: but if you really need it I can dig up my laptop (and you can explain to my wife next week) | 23:23 |
| wallyworld | perrito666: ah, no worries, it's not on the calendar :-) | 23:24 |
| perrito666 | From your perspective I presume the calendar says the holiday was yesterday | 23:25 |
| perrito666 | It's still yesterday here | 23:25 |
| wallyworld | perrito666: it's not on the juju team calendar | 23:27 |
| perrito666 | Strange, I'll check before next, now I'll go back to doing nothing | 23:28 |
| wallyworld | have fun | 23:32 |
| menn0 | thumper: easy one: http://reviews.vapour.ws/r/5111/ | 23:40 |
| menn0 | thumper: swapping out the natural sorting implementation in juju for the one in juju/utils | 23:41 |
| thumper | looks fine | 23:41 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!