[01:14] <mup> Bug #1594211 opened: creating hosted model: model already exists <juju-core:New> <https://launchpad.net/bugs/1594211>
[02:26] <menn0> thumper: client side api for the previous PR: http://reviews.vapour.ws/r/5106/
[03:03] <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:04] <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:05] <mup> Bug #1594232 opened: Inconsistent capitalization in juju command help <juju-core:In Progress by cherylj> <https://launchpad.net/bugs/1594232>
[03:08] <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:09] <menn0> thumper, wallyworld: that's why the PR description doesn't match the work
[03:09] <wallyworld> \o/
[03:10] <menn0> wallyworld: thanks for your comments. I'll address them after I fix something else.
[03:10] <wallyworld> ok, if you agree
[03:11] <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:12] <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:13] <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:14] <wallyworld> and the data is migration specific and generally not related to any api concerns
[04:22] <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:24] <mup> Bug #1570791 changed: ERROR wait: no child processes with juju run on ppc64el <run> <juju-core:Expired> <https://launchpad.net/bugs/1570791>
[04:30] <thumper> wallyworld: um.. no
[04:30] <thumper> which manifold?
[04:30] <thumper> I have just pushed some extra test fixes
[04:31] <thumper> wallyworld: machinelock worker is entirely deleted
[04:31] <thumper> as it isn't needed
[04:31] <wallyworld> ok
[04:32] <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:33] <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:36] <thumper> hmm 1 failure in worker/uniter
[04:36] <thumper> looks intermittent
[04:36] <thumper> trying again
[04:38] <wallyworld> thumper: lgtm
[04:42] <thumper> hmm... seems like it might be real
[04:42]  * thumper digs some
[04:46] <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
[08:19] <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:37]  * 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:51] <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:52] <dimitern> frobware: and I've realized the TestBridgeScriptWithUndefinedArgs might be wrong
[08:53] <dimitern> frobware: it looks like we're expecting an error without arguments, but assuming the configFile exists, it actually passes ok
[08:54] <frobware> dimitern: ahh :(
[08:54] <dimitern> frobware: and passing "# no config" as config file path doesn't work
[08:55] <dimitern> frobware: I suggest we drop that test, as we're already testing the 'default prefix' and 'explicit prefix' cases
[08:56] <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:57] <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:58] <dimitern> frobware: so dropping the 'undefined args' test is ok
[09:02] <dimitern> babbageclunk: standup?
[09:02] <babbageclunk> oops, sorry!
[09:12] <mup> Bug #1594290 opened: Duplicate key error on juju.txns.stash creating model <juju-core:New> <https://launchpad.net/bugs/1594290>
[09:32] <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:33] <frobware> dimitern: the issue with --keep-source-stanzas is that this is now fixed in cloud-init
[09:34] <frobware> dimitern: can we HO briefly?
[09:34] <dimitern> frobware: ok
[09:34] <dimitern> frobware: standup HO?
[09:34] <frobware> yep
[09:35] <dimitern> i'm in
[10:24] <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:25] <dimitern> frobware: ooh, sorry this is on my maas 1.9.3 / trusty actually
[10:26] <frobware> dimitern: I also added http://pastebin.ubuntu.com/17587166/
[10:27] <frobware> dimitern: and then explicitly installed with -t trusty-proposed to limit the damage
[10:28] <dimitern> frobware: yeah, just enabled trusty-backports and trusty-proposed, that got me curtin 389
[10:29] <dimitern> frobware: now updating the images to the dailies, rebooting, then bootstrapping trusty and xenial
[10:30] <frobware> dimitern: I didn't need dailies
[10:31] <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:43] <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.
[11:01] <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:02] <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:03] <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:04] <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:05] <frobware> dimitern: though the balance-tlb failure on xenial was unexpected
[11:06] <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:07] <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:08] <frobware> dimitern: I was trying to avoid working on the same issue
[11:09] <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:10] <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:11] <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:12] <dimitern> frobware: ok, looking
[11:14] <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:15] <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:16] <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:17] <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:27] <mup> Bug #1594332 opened: Unit reports status about agent before machine is available <juju-core:New> <https://launchpad.net/bugs/1594332>
[11:28] <frobware> dimitern: actually, given that you do have a failure it would be worthwhile verifying/understanding/experimenting with --no-scripts
[11:29] <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:30] <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:31] <frobware> dimitern: ah, ok
[11:31] <dimitern> frobware: I'm applying the patches now and trying the bridge script
[11:34] <babbageclunk> dimitern: What's the apiserver/client package all about? It seems oddly named.
[11:35] <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:36] <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:37] <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:38] <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:39] <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:40] <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:43] <frobware> dimitern: ok, np
[11:44] <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:45] <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:46] <mup> Bug #1594335 opened: Juju possibly confuses account with credential in add-model <juju-core:New> <https://launchpad.net/bugs/1594335>
[12:13] <dimitern> frobware: bad news..
[12:13] <frobware> dimitern: it works? :)
[12:13] <dimitern> frobware: just the opposite :)
[12:14] <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:15] <dimitern> frobware: however, I rebooted the xenial node and now it never gets out of "Started Raise network interfaces."
[12:16] <dimitern> frobware: now rebooted the trusty node to see if it will be the same..
[12:17] <dimitern> frobware: well, I can (barely) ssh after the reboot into the trusty node
[12:18] <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:19] <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:20] <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:23] <dimitern> frobware: trying with balance-alb on both nodes
[12:24]  * dimitern steps out for ~30m
[12:30]  * 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:59] <babbageclunk> voidspace, dimitern, frobware: review board's being weird for me - slow requests and losing comments. Anyone else seeing that?
[13:02] <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:05] <dimitern> voidspace: reviewed
[13:08] <dimitern> frobware: so with balance-alb there's no lag on trusty like before, xenial is the same
[13:09] <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:10] <dimitern> frobware: now redeploying and will run the script in a tmux session to let if finish
[13:11] <dimitern> s/if/it/
[13:11] <dimitern> rogpeppe: hey, I have some time now if you wanna chat?
[13:12] <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:43] <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:47] <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:48] <frobware> dimitern: :(
[13:48] <dimitern> frobware: and even though it shouldn't have made any changes, rebooting does not restore connectivity
[13:49] <dimitern> frobware: instead it gets into 'waiting 120 seconds for network device'
[13:50] <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:51] <dimitern> frobware: perhaps we need to patch more than just ifenslave (and its scripts)
[13:52] <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:55] <dimitern> frobware: retrying again, but this time I'll enable console login with 'ubuntu' before I reboot
[14:10] <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:11] <frobware> dimitern: so to be expected
[14:11] <dimitern> frobware: oops, sorry - so trusty is fine, xenial isn't
[14:13] <dimitern> frobware: to restore connectivity on xenial, I replace /e/n/i with /e/n/i-before-add-juju-bridge and rebooted
[14:15] <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:16] <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:17] <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:18] <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:19] <frobware> dimitern: this is my observation too - the only screw up seems to be if you have a LACP bond
[14:24] <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:25] <gsamfira> natefinch: sure :)
[14:26] <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:27] <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:28] <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:29] <natefinch> gsamfira: as in - maybe the problem is that we're doing that in a test and should not
[14:30] <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:32] <natefinch> gsamfira: there's no way to do that without a race condition
[14:32] <gsamfira> silly named pipes
[14:33] <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:34] <gsamfira> natefinch: yeah...unfortunately. We may have to resort to polling...which sucks
[14:50] <marcoceppi> need help, getting some macaroon error on deploy? http://paste.ubuntu.com/17595425/
[14:51] <marcoceppi> rick_h_: ^?
[14:52] <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:53] <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:54] <rick_h_> marcoceppi: hmmm, shouldn't that I can think of. Shouldn't be unique that is.
[14:58] <mup> Bug #1594415 opened: Juju register should offer a name for the controller <juju-core:New> <https://launchpad.net/bugs/1594415>
[15:08] <redir> katco: yt?
[15:11] <babbageclunk> dimitern: do you know if there's a util somewhere for picking the most common from a set of values?
[15:23] <dimitern> babbageclunk: most common like how ?
[15:24] <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:28] <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:31] <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:33] <dimitern> babbageclunk: I'm not aware of an existing tool you could use.. it should be easy to script it though..
[15:34] <babbageclunk> dimitern: ok - I've coded it up now.
[15:38] <babbageclunk> dimitern: It ended up being fairly specific anyway.
[16:02] <babbageclunk> dimitern, frobware: sorry, can't make it to the network hangout today
[16:03] <frobware> babbageclunk: ok
[16:04] <dimitern> babbageclunk: np
[16:06] <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:07] <mup> Bug #1594440 opened: juju gives weird errors about macaroons when a read-only user <juju-core:New> <https://launchpad.net/bugs/1594440>
[16:13] <natefinch> cmars: you around?
[16:43] <katco> redir: here now, what's up?
[17:10] <bdx> hey whats up guys, is openstack provider currently broken for 2.0?
[17:14] <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:15] <alexisb> bdx, are you working off beta9??
[17:16] <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:17] <bdx> alexisb: have you personally bootstrapped to openstack provider using 2.0?
[17:18] <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:20] <bdx> alexisb: nice, ok. ... I feel like it must be operator error seeing as no one else is causing a stink about it ...
[17:21] <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:22] <balloons> bdx, are you attempting to bootstrap a charm or bundle on an existing openstack?
[17:23] <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:24] <bdx> balloons: bootstrap to existing private openstack(s)
[17:27] <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:29] <bdx> natefinch, balloons: http://paste.ubuntu.com/17603992/
[17:30] <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:31] <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:33] <natefinch> heh, well I fixed this test hang... evidently it never happens if you just enable verbose output :/
[17:34] <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:35] <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:36] <bdx> thats why I think the region must be "OS_REGION_NAME"
[17:38] <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:41] <bdx> thats why I think the region must be "OS_REGION_NAME"
[18:08] <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:10] <natefinch> bdx: sounds like it's a documentation and/or naming problem?
[18:11] <natefinch> (combined with a changed definition from 1.x, without a change to the name)?
[19:02] <bdx> natefinch: I guess ....
[19:13] <alexisb> redir, redir_, ping
[19:24] <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:25] <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:59] <coreycb> I can't seem to get credentials right for openstack provider with beta9.  anyone have some tips?  http://paste.ubuntu.com/17612374/
[20:12] <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:56] <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:03] <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:06] <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:27] <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:28] <thumper> hmm
[21:29] <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:32] <alexisb> thumper, ping
[21:32] <thumper> coming
[21:36] <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:38] <alexisb> natefinch, ping
[21:47] <katco> natefinch: he usually leaves for dinner pretty sharply -46m ago
[22:35] <marcoceppi> dear core team: http://paste.ubuntu.com/17620137/ this is amazing, thank you!
[22:38] <anastasiamac> marcoceppi: :)
[22:39] <anastasiamac> marcoceppi: thank you for feedback \o/
[23:19] <wallyworld> axw: perrito666: you guys around for standup?
[23:22] <perrito666> Sorry didn't see that, it's a holiday here
[23:23] <perrito666> Wallyworld: but if you really need it I can dig up my laptop (and you can explain to my wife next week)
[23:24] <wallyworld> perrito666: ah, no worries, it's not on the calendar :-)
[23:25] <perrito666> From your perspective I presume the calendar says the holiday was yesterday
[23:25] <perrito666> It's still yesterday here
[23:27] <wallyworld> perrito666: it's not on the juju team calendar
[23:28] <perrito666> Strange, I'll check before next, now I'll go back to doing nothing
[23:32] <wallyworld> have fun
[23:40] <menn0> thumper: easy one: http://reviews.vapour.ws/r/5111/
[23:41] <menn0> thumper: swapping out the natural sorting implementation in juju for the one in juju/utils
[23:41] <thumper> looks fine


[16:30] <asdfasdfsdf> ?
[16:32] <asdfasdfsdf> ?
[16:33] <asdfasdfsdf> hello
[19:17] <leftyfb> hello?
[19:18] <leftyfb> This is sort of important. We had to take down your website


[20:36] <niedbalski> Hello ubuntu-irc, I just got my Ubuntu membership and I read that I can now ask for a cloak.  My launchpad profile is here:  https://launchpad.net/~niedbalski
[20:38] <Unit193> 1. I don't see you in the group 'ubuntumembers', are you sure?  2. You'll have to identify to nickserv in order for any cloak to take effect.
[20:50] <niedbalski> Unit193, can you check now? just added me.
[20:50] <Unit193> Yep, #1 has been taken care of.
[20:51] <Fuchs> he is also identified with nickserv, so that's all fine
[20:51] <Fuchs> you just need a member of IRCC and a staffie now
[20:51] <Unit193> Hmm, wasn't a second ago. :3
[20:51] <Unit193> But, nice.  Now for the pinging of Pici, and Pici, and Pici. :D
[22:10] <hggdh> I will try
[22:11] <hggdh> staff: can we have a cloak ubuntu/member/Niedbalski for Niedbalski
[22:12]  * hggdh wonders about tomaw's availability
[22:14] <hggdh> why the hell I got niedbalski with an uppercase N?
[22:15] <hggdh> staff: can we have a cloak ubuntu/member/niedbalski for niedbalski <- corrected
[22:17] <Fuchs> (minor sidenote: uppercase would be allowed in project cloaks, in contrast to unaffiliated that are lower case indeed. But if you ubuntu people have a rule on that: sure)
[22:17] <Unit193> Usually Ubuntu cloaks are lower, yes.
[22:18] <hggdh> (to answer my own question: cuz I typed Nie<tab>)
[22:18] <hggdh> Fuchs: we tend to lower case, but it is not a hard rule
[22:18] <hggdh> I will try freenode
[22:19] <hggdh> niedbalski: now we wait for a freenode staffer to act. Usually not a long wait.
[22:19] <Unit193> Well this is getting later, so less of them around.  ni ko was the last active one in there.
[22:21] <hggdh> yes, more than 90 minutes ago


[00:09] <pwnguin> mermaidman: thats nice, but from wikipedia: The file system is currently marked as developmental and is titled "ext4dev".[5] It is considered unstable and so is not recommended for use in production environments, since data corruption is possible in this early stage of development."
[00:09] <pwnguin> im kinda thinking anyone interested in ext4 outta learn how to build kernels anyways
[00:10] <mermaidman> pwnguin: Umm you have to add some special test_fs code to ext3 in order to mount ext4 which the ubuntu devs dont understand
[00:12] <pwnguin> mermaidman: when you say "dont understand"
[00:12] <pwnguin> is there specific evidence?
[00:12] <mermaidman> they never respond to all my suggestions
[00:12] <pwnguin> im not sure those are equivilent
[00:13] <pwnguin> where can i read these suggestions?
[00:13] <mermaidman> forums
[00:13] <pwnguin> oh well duh
[00:14] <pwnguin> you'd get more attention from IRC or the mailing list
[00:14] <mermaidman> http://ubuntuforums.org/showthread.php?t=837589
[00:14] <mermaidman> went there to still no answer
[00:14] <pwnguin> on -kernel?
[00:15] <mermaidman> yup
[00:15] <pwnguin> gotta grab dinner
[00:15] <pwnguin> but i'll check the archive
[00:17] <pwnguin> john nelson?
[00:18] <mermaidman> yeah
[00:19] <pwnguin> We need to talk about effective writing
[00:21] <mermaidman> i was in a rush that day
[00:21] <pwnguin> https://lists.ubuntu.com/archives/kernel-team/2008-July/002793.html
[00:21] <pwnguin> well, then the little time you did spend was wasted =/
[00:22] <mermaidman> Since i have all the time of the night I will write another one right now
[00:22] <pwnguin> if you communicate intelligently, you may find people are more willing to talk with you
[00:24] <pwnguin> but I believe there's also some structural bias
[00:24] <pwnguin> from what ive seen many in the kernel team are paid canonical employees who work 9-5
[00:24] <mermaidman> just sent it its in the moderation queue now
[00:25] <pwnguin> being the weekend, there's probably a bit less attention to go around, if you know what i mean
[00:25] <mermaidman> Yeah
[00:29] <pwnguin> well pizza time
[00:29] <mermaidman> cool
[00:49] <pwnguin> you know what, if ted doesn't think it's ready, i don't think we should bother enabling it
[00:50] <mermaidman> ted Tso?
[00:50] <pwnguin> yes
[00:53] <mermaidman> finally finshed the annoying fsck on ext3
[17:16] <benje> hi there a bug in the se401 driver i get this [ 3335.080589] se401: probe of 3-1:1.0 failed with error -5
[17:16] <benje>  with a kensington webcam Bus 003 Device 004: ID 047d:5001 Kensington
[17:16] <benje> under hardy
[17:17] <sn9> benje: you're sure it's not bug 88746?
[17:18] <sn9> !bug 88746
[17:18] <sn9> where's ubottu?
[17:18] <benje> i go to see i just searching there
[17:19] <benje> shure sn9 it's about ehci but it using usb 3-1: new full speed USB device using uhci_hcd and address 4
[17:20] <sn9> any hub involved?
[17:20] <benje> since a long time this webcam not working
[17:20] <benje> no directly on face pc (dell 1800)
[17:20] <sn9> ok...
[17:20] <benje> it was working a day
[17:21] <benje> do you want full dmesg ?
[17:22] <benje> sn9, http://pastebin.com/m3d7c3f1e
[17:24] <sn9> 404
[17:25] <benje> sn9, :/
[17:25] <benje> this is working for me
[17:25] <benje> sn9, do you have an other paste
[17:25] <benje> prefered
[17:26] <sn9> i probably won't learn anything from it, anyway
[17:26] <benje> yes nothing particular
[17:26] <benje> detect w"ebcam firware format
[17:26] <benje> but [ 3335.080563] /build/buildd/linux-2.6.24/drivers/media/video/se401.c: Bayer format not supported!
[17:28] <benje> the light at webcam stay lighting
[17:29] <benje> sn9, what is it need for post bug about this ? i have even post bug
[17:29] <sn9> have you looked at upstream info about the driver?
[17:29] <benje> but what will be usefull
[17:30] <benje> there a patch for version http://members.chello.nl/~j.vreeken/se401/
[17:31] <benje> but only for epcam
[17:31] <benje> it's now in kernel tree
[17:31] <benje> no sn9
[17:31] <sn9> do you know whether this works in later kernels?
[17:31] <benje> sn9, here http://cateee.net/lkddb/web-lkddb/USB_SE401.html .
[17:32] <benje> no i don't know
[17:32] <benje> this was working in dapper and edgy at start
[17:32] <benje> at bigining
[17:32] <benje> begining
[17:33] <benje> but she is in all list as working :/
[17:33] <benje> http://lxr.linux.no/linux/Documentation/video4linux/se401.txt
[17:35] <sn9> so, it's a regression?
[17:35] <benje> yes
[17:36] <benje> it 's avery old webcam doesn't work in xp
[17:36] <benje> ;)
[17:37] <benje> no driver but it always working under linux
[17:37] <benje> sn9, where can i find upstream of ubuntu ?
[17:39] <sn9> if the driver is in the mainline kernel tree, the upstream is often the mainline kernel itself, unless patches are applied
[17:39] <sn9> ubuntu maintains local kernel trees for each version on kernel.org, too
[17:40] <benje> ok
[17:40] <benje> i haven't try with an other distrib
[17:40] <benje> i try under debian etch
[17:41] <sn9> under debian, you may need to use module-assistant
[17:41] <benje> same error
[17:42] <benje> :/
[17:43] <benje> not needed ;)
[17:43] <benje> thanks sn9
[17:43] <benje> sn9, do you know what is the problem ?
[17:44] <benje> or seems
[17:44] <sn9> it sounds like the upstream driver might be broken
[17:46] <benje> ok thanks sn9 i will post bug or do you think it s not necessary
[17:46] <sn9> search for existing bug reports first
[17:47] <benje> i found nothing about se401 and kensington webcam
[17:48] <sn9> no se401 bugs at all? file it, then
[17:49] <benje> no, oki
[17:49] <benje> no now i discution with friend but i will ;)
[18:27] <benje> thanks and bye
[21:07] <DHR> I reported this problem a few days ago.  IOCTL interface to MTRRs appears broken in 8.04.1.  Thoughts?  https://bugs.launchpad.net/ubuntu/+source/linux-meta/+bug/253204
[21:54] <pwnguin> who moderates mail to ubuntu-kernel?
[21:56] <sn9> it should say at the bottom of the listinfo page for that list
[21:57] <BenC> pwnguin: rtg does
[21:57] <BenC> DHR: looking at it now
[21:58] <pwnguin> ok thanks; a guy came by yesterday asking about ext4 and he said it was waiting moderation approval
[21:58] <pwnguin> probably it'll be taken care of on monday
[21:58] <pwnguin> a bit unfortunate for our weekend hackers
[21:59] <DHR> BenC: thanks!
[22:00] <BenC> DHR: it seems to be specific to the system, so the fact that it works on fedora9 is misleading
[22:01] <DHR> BenC: in what sense is it specific?
[22:01] <BenC> DHR: on my laptop, it prints all of them, but on my 8-way Core2 box, it only prints the first two
[22:02] <BenC> and they are running the exact same kernel
[22:02] <DHR> OK.
[22:03] <BenC> my laptop has 4 registers enabled, and it prints all 4...the workstation has 3 registers and it only prints the first 2
[22:03] <DHR> There seem to be some problems with MTRRs on Intel systems with >4G.
[22:03] <BenC> Nope
[22:03] <BenC> neither of these has > 4G
[22:03] <DHR> Sorry: not *this* problem, but it is the reason I care about MTRRs.
[22:03] <BenC> Ah
[22:04] <DHR> Some BIOSes set MTRRs with overlapping ranges.  X drivers cannot then change their frame buffer to Write Combining.
[22:04] <DHR> So: I wanted to write a C program to eliminate overlapping ranges.
[22:06] <BenC> isn't that something you can do in your BIOS?
[22:06] <DHR> There is a kernel patch to do this.  I'm trying to understand the code (right now).  I'm not convinced it is great code.
[22:06] <DHR> No, I cannot write a new BIOS easily :-)
[22:06] <BenC> No, I mean you can set it in your BIOS config :P
[22:07] <DHR> no.  Not normally.  The usual work-around is to remove memory!
[22:08] <DHR> You can also hack away with echos to /proc/mtrr.  I thought ioctl interface would be cleaner.  But it is broken, I think.
[22:10] <DHR> kernel patch as discussed on LKML: http://kerneltrap.org/mailarchive/linux-kernel/2008/5/1/1686464
[22:11] <DHR> example of the problems caused by overlapping MTRRs: https://bugs.launchpad.net/ubuntu/+source/linux-restricted-modules-2.6.24/+bug/224404
[22:13] <DHR> BenC: since you have observed to problem with the ioctl interface too, could you add to https://bugs.launchpad.net/ubuntu/+source/linux-meta/+bug/253204
[22:17] <BenC> DHR: ...
[22:17] <BenC>                 /* Hide entries that go above 4GB */
[22:17] <BenC>                 if (gentry.base + size - 1 >= (1UL << (8 * sizeof(gentry.size) - PAGE_SHIFT))
[22:17] <BenC>                     || size >= (1UL << (8 * sizeof(gentry.size) - PAGE_SHIFT)))
[22:17] <BenC>                         gentry.base = gentry.size = gentry.type = 0;
[22:17] <BenC> that's from the MTRRIOC_GET_ENTRY code in the kernel
[22:18] <DHR> interesting!
[22:18] <BenC> So it has nothing to do with > 4G of memory, just mapped to > 4G
[22:18] <DHR> what file is that in?
[22:18] <BenC> and sure enough, but 3rd entry on the workstation is mapped at 4G
[22:18] <BenC> arch/x86/kernel/cpu/mtrr/if.c
[22:19] <BenC> s/but/my/
[22:19] <DHR> Why would that be the correct thing to do?  Especialy on amd64 (which I'm on)?
[22:20] <mjg59> What's the size of the field in the structure that the address gets returned in?
[22:21] <BenC> mjg59: ah, it's unsigned int
[22:21] <DHR> "unsigned int size"
[22:21] <BenC> that's pretty stupid
[22:22] <mjg59> Yeah, so ABI concerns
[22:22] <BenC> well, that still shouldn't be a problem...the base is unsigned long, so it should still be able to print up to 4G size
[22:23] <mjg59> Probably best to add a new ioctl...
[22:23] <mjg59> (nngh ioctls)
[22:23] <BenC> yeah, best to just shove it in /sys somewhere and add something to X to use that
[22:23] <DHR> if you look at /usr/include/asm/mtrr.h, i386 differs from amd64.  So no excuse.
[22:24] <BenC> ioctl's are just ugly anyway, I don't blame them for not fixing it by now
[22:25] <BenC> plus they are working on something better for X to use, so focus is probably there
[22:25] <DHR>  /proc is ugly too: race conditions and all.
[22:27] <mjg59> You probably want to be using PAT on newer systems anyway
[22:28] <BenC> right, PAT is what I was thinking of
[22:29] <DHR> if the IOCTL cannot return the correct value, it ought to return an error.
[22:31] <DHR> EOVERFLOW       Value too large to be stored in data type (POSIX.1) ??
[22:32] <DHR> ERANGE          Result too large (POSIX.1, C99) ??
[22:34] <DHR> is a size >= 4G legal on i386?  It could well be, given PAE.