[00:07] <ericsnow_> davechen1y: PTAL http://reviews.vapour.ws/r/1163/ and http://reviews.vapour.ws/r/1164/
[00:10]  * perrito666 hears a kid receiving express education on the house next door
[00:12] <perrito666> sitting in my office during the night makes for the most interesting show
[00:12] <jw4> perrito666: is that Argentenian for FastMath (tm) ?
[00:16] <jw4> s/FastMath/FasttMath/
[00:21] <perrito666> jw4: I dont know what FastMat ™ is, but I was referring at hand against kids bottom
[00:21] <jw4> perrito666: :-p
[00:22] <jw4> I figured as much - I was trying too hard to be funny
[00:22] <perrito666> and of course kids screaming reply
[00:24] <ericsnow_> perrito666: did http://reviews.vapour.ws/r/1172/ look okay now?
[00:26] <perrito666> ericsnow_: yup, you need a senior rubber stamp though
[00:28] <ericsnow_> perrito666: thanks
[00:40] <menn0> thumper, waigani, davechen1y, wallyworld : refactoring of api.Open: http://reviews.vapour.ws/r/1179/
[00:40]  * thumper looks
[00:44] <thumper> menn0: done
[00:44] <menn0> thumper: thanks
[01:01] <perrito666> thumper: hey, you owe me an emails answer :) could I collect on that?
[01:02] <thumper> perrito666: um... sure
[01:02] <perrito666> thumper: the one about the mongo admin user
[01:02] <thumper> yeah, I know the one
[01:03] <thumper> just busy right ow
[01:03] <thumper> will get to it shortly
[01:03] <perrito666> thumper: well you have a lot of time, I am going to sleep
[01:18] <davechen1y> can anyone else get to the ppc vm's ?
[01:20] <davechen1y> sinzu, can you get to your ppc vm's anymore ?
[01:20] <davechen1y> looks like batuan has lost all our keys
[01:22] <wallyworld> axw_: reviewed, just a few questions
[01:23] <axw_> wallyworld: cheers
[01:38] <axw_> wallyworld: PTAL
[01:38] <wallyworld> looking
[01:40] <wallyworld> axw_: lgtm
[01:40] <axw_> thanks
[01:59] <redelmann> Hi, I have a noob question about hooks
[02:00] <redelmann> somebody can give me a hand?
[02:00] <jw4> redelmann: what's your question - we'll try :)
[02:01] <redelmann> want to prevent django migration when new unit is add
[02:01] <redelmann> jw4, want to prevent django migration when new unit is add
[02:02] <redelmann> jw4, can i set a variable inside the charms?
[02:02] <jw4> redelmann: hmm; that's fairly specific to the charm you're using I think
[02:02] <redelmann> jw4, im making a custom charm
[02:02] <jw4> ah, I see
[02:03] <redelmann> jw4, can i change a charm config variable from inside the charm?
[02:03] <jw4> redelmann: yes you should be able to - I'll need to dig a bit to see exactly how
[02:03] <redelmann> jw4, something like migrate: true?
[02:04] <redelmann> jw4, charmhelper does not have something to do that?
[02:05] <jw4> redelmann: it's outside my experience, but I can see if I can find more info in the source
[02:05] <redelmann> jw4, could use a file, but it is not the most elegant solution
[02:07] <redelmann> jw4, ok dont worry. i was asking because i thought there were a direct solution
[02:08] <jw4> redelmann: okay - someone else on this channel or on #juju may know off the top of their head
[02:09] <mup> Bug #1373236 changed: apiserver/backups: backups must be migrated off legacy provider storage <backup-restore> <juju-core:Fix Released by ericsnowcurrently> <https://launchpad.net/bugs/1373236>
[02:09] <redelmann> jw4, with direct solution i meant implemened solution in juju
[02:10] <redelmann> jw4, thank
[02:10] <jw4> :)
[02:13] <jw4> redelmann: '$ juju help set' if you haven't tried that yet
[02:15] <wallyworld> axw_: RE persistent attribute, we could use the provider ValidateConfig() to reject attempts to set persistent for providers which don't support it?
[02:15] <redelmann> jw4, but i cant run "juju set" inside charm hooks. or i can?
[02:15] <jw4> redelmann: that's what I don't know
[02:16] <redelmann> jw4, i will try tomorrow at work
[02:17] <jw4> kk
[02:20] <redelmann> jw4, i'm seeing postgresql charm, i think they use some "state file". Maybe that's the elegant solution
[02:20] <redelmann> jw4, thank you.
[02:22] <jw4> cool
[02:22] <jw4> good luck redelmann
[03:07] <wallyworld> axw_: i've updated the pr to add extra provider validation
[03:11] <thumper> gah...
[03:11] <thumper> trying to work out why my test wasn't working
[03:11] <thumper> hadn't set the feature flag
[03:12] <thumper> ...
[03:12] <thumper> yay?
[03:21] <jw4> thumper: at least you know they work
[03:21] <thumper> yeah :)
[03:41] <menn0> thumper: it is not my day. due to other branches landing db-log now has merge conflicts again.
[03:41] <thumper> :(
[03:41] <menn0> thumper: prepare for another PR for you to merge
[03:41]  * thumper braces himself
[03:59]  * thumper is still braced
[04:02] <alexisb> thumper, menn0 is helping you with your gym routine ;)
[04:02] <thumper> alexisb: heh... kinda
[04:09] <menn0> ha :)
[04:09] <menn0> thumper: https://github.com/juju/juju/pull/1857
[04:10] <thumper> menn0: merged
[04:10] <thumper> menn0: I don't see much point actaully looking at the diff
[04:11] <thumper> it isn't like I'd be able to spot anything :)
[04:11] <menn0> thumper: there was a conflict due to waigani's most recent change
[04:12]  * thumper nods wisely
[04:13] <menn0> thumper: I guess this is one downside of big feature branches. you end up with a much larger "conflict surface" :)
[04:13] <thumper> true
[04:14] <menn0> thumper: not a showstopper (they're still worth it) but something to be aware of
[04:35]  * thumper sighs
[04:35] <thumper> my magic branch to stop serving the initial environment at the root of the api now breaks a shed ton of tests
[04:36] <thumper> because guess where all the tests connect to...
[04:42] <waigani> :(
[04:48] <menn0> thumper: woot! db-log branch merged
[04:49] <thumper> \o/
[04:50] <menn0> thumper: and I have a fix for the intermittent upgrade test failure
[04:50] <thumper> double \o/
[04:50] <thumper> \o/\o/
[04:51] <thumper> a ':' bites me again
[04:52] <thumper> ok, down to four test failures, and I'm sure at least one of them is about logging
[04:53] <thumper> FARK!!!
[04:53] <thumper> shitty shitty shitt tests
[04:53]  * thumper stabs it through the heart
[04:53] <thumper> I'll work out how to write it properly tomorrow
[04:54] <menn0> thumper: new logging stuff, or old?
[04:54] <thumper> well, I'm working around the 'response redacted' bti
[04:54] <thumper> implementing it (I think) a little better
[04:55] <thumper> but also, we have tests that assert that we call version 1 of Login
[04:55] <thumper> now I have version 2
[04:55] <thumper> I want to rewrite the test
[04:55] <thumper> not just change 1 to 2
[04:55] <thumper> the test is broken
[04:55] <thumper> and testing the wrong behaviour
[04:55] <thumper> it obviously don't care that I'm logging in with v1 or v2
[04:55] <thumper> it actually cares about ipv4 vs ipv6
[04:55] <thumper> so it should be testing that
[04:56] <thumper> not the version of the login
[04:56] <thumper> bah humbug
[04:56] <menn0> totally. understood.
[04:56] <thumper> ok, I'm done
[04:56] <thumper> laters peeps
[04:59] <axw_> wallyworld: just got back. will take a look now
[04:59] <wallyworld> sure, had to rebase as well
[05:01] <menn0> wallyworld: if you have a moment: http://reviews.vapour.ws/r/1184/
[05:01] <wallyworld> sure
[05:02] <menn0> wallyworld: thanks
[05:04] <axw_> wallyworld: still feels a little fragile, as it's opt-out rather than opt-in, so default behaviour would be to "support" the persistent attribute but ignore it. we can iterate on it, what you did with the scope checking is a good step
[05:04] <axw_> wallyworld: shipit
[05:05] <wallyworld> axw_: yeah, we need to improve validation a bit, plus add schema support etc
[05:07] <menn0> wallyworld: i'm done for the day. if you're happy with that PR would you mind attempting a $$merge$$ on it?
[05:07] <wallyworld> menn0: looks good, did you change the api call for any reason?
[05:07] <wallyworld> menn0: just did a +1
[05:07] <wallyworld> i can merge
[05:07] <menn0> wallyworld: cool thanks... i'll do the merge
[05:07] <wallyworld> ok
[05:08] <menn0> wallyworld: i changed the API because it seemed silly to trigger a possible environment destruction when we still need the env for the test
[05:08] <wallyworld> fair point
[05:08] <menn0> wallyworld: so I chose a non-destructive yet restricted API call
[05:08] <wallyworld> +1
[05:08] <menn0> wallyworld: cheers
[06:40] <axw_> wallyworld: FYI, https://github.com/axw/juju/tree/worker-mounter
[06:40] <axw_> need to do some more testing before I propose it
[06:41] <axw_> it appears that "storage list" is broken, looking into it atm
[06:45] <wallyworld> ok
[08:06] <axw_> wallyworld: still around? http://reviews.vapour.ws/r/1185/
[08:29] <mattyw> morning all
[08:50] <voidspace> grrr... someone else landed an upgrade step
[08:50] <voidspace> now I have conflicts to resolve
[08:50] <voidspace> *really easy* conflicts, but still...
[09:19] <voidspace> dimitern: "addresser"?
[09:20] <voidspace> dimitern: or networker/addresses ?
[09:21] <dimitern> voidspace, you mean the name of the worker?
[09:21] <voidspace> dimitern: yep
[09:21] <dimitern> voidspace, addresser I think - not in networker though - top level
[09:22] <voidspace> dimitern: yep, cool - thanks
[09:51] <TheMue> Hi folks, greetings from the CeBIT
[09:52] <dimitern> TheMue, hey! how's it going there?
[09:58] <TheMue> First informational talks for me, so far few interested people
[09:58] <TheMue> But this area optically more looks like for recreation instead of a real booth
[09:58] <voidspace> dimitern: just you and me for standup I think :-)
[09:58] <TheMue> Not well designed
[09:58] <dimitern> TheMue, it will pick up as it goes
[09:59] <dimitern> voidspace, omw
[09:59] <TheMue> I hope so
[10:07] <natefinch> Anyone seen a message like this before?  I'm getting this when destroying a local environment: ERROR while stopping mongod: exec ["stop" "--system" "juju-db-nate-local"]: exit status 1 (stop: Method "Get" with signature "ss" on interface "org.freedesktop.DBus.Properties" doesn't exist)
[10:19] <dimitern> natefinch, I've seen this
[10:20] <dimitern> natefinch, is this on vivid?
[10:20] <natefinch> dimitern: utopic
[10:21] <dimitern> natefinch,  inside a container?
[10:23] <dimitern> natefinch, perhaps this is relevant - http://ubuntuforums.org/showthread.php?t=1594566
[10:24] <dimitern> I have seen this error recently, but can't quite recall the circumstances - what I remember is that it has nothing to do with dbus missing or otherwise
[10:26] <natefinch> it's just the local provider on my laptop.  Laptop is utopic.  *shrug*
[10:26] <natefinch> connman is not installed, so that link is evidently not applicable
[10:38] <voidspace> natefinch: my laptop arrives today, it will have windows on it
[10:38] <voidspace> natefinch: is installing ubuntu straightforward?
[10:39] <natefinch> voidspace: IIRC it's just a matter of making an ubuntu USB stick and booting with it in
[10:39] <natefinch> voidspace: I don't remember having to twiddle with the bios or anything
[10:39] <voidspace> natefinch: cool, that's what I'm hoping :-)
[10:49] <perrito666> morning everyone
[10:49] <voidspace> perrito666: morning
[10:49] <perrito666> natefinch: fell off the bed?
[11:01] <natefinch> perrito666: nah, I been getting up at 5am for a couple weeks now, trying to get this HA stuff done.. my day is pretty broken up with kids stuff, though, so I'm usually AFK from 7-9:30
[11:04] <voidspace> dimitern: do you think "juju add-machine lxc:0" should be sufficient to allocate an IP address?
[11:04] <voidspace> dimitern: 1.22, maas
[11:05] <dimitern> voidspace, in 1.22 it won't allocate anything
[11:06] <voidspace> dimitern: gah, dammit
[11:06] <dimitern> voidspace, you need 1.23 - then it will work
[11:06] <voidspace> dimitern: I should have done 1.23
[11:06] <voidspace> yep
[11:06] <dimitern> :)
[11:06] <voidspace> heh, ah well - at least I've got maas working
[11:06] <voidspace> dimitern: took a bit of effort - it has a dependency on python-apt that isn't automatically installed
[11:06] <voidspace> so everything was broken until I worked it out
[11:07] <dimitern> voidspace, which one? maas?
[11:08] <natefinch> Anyone have an idea of why this worker, when started in MachineAgent.Run() would cause juju to simply not run?  https://github.com/natefinch/juju/blob/ha-to/cmd/jujud/agent/converter.go
[11:08] <voidspace> dimitern: yep, maas
[11:10] <voidspace> dammit, screwed up my git checkout and now have juju 1.22 local branch named juju-1.23.0
[11:10] <dimitern> voidspace, weird.. I haven't seen this with maas before
[11:10] <voidspace> I guessed the tag wrong - should have remembered it wasn't released yet
[11:10] <voidspace> dimitern: maybe you had python-apt already installed?
[11:11] <dimitern> voidspace, ah :/
[11:11] <voidspace> it's quite common
[11:11] <voidspace> I just have a kvm image *just* for the maas controller - so only maas dependencies installed
[11:11] <dimitern> voidspace, I've installed what maas packages from the ppa brought over I guess
[11:11] <perrito666> natefinch: without any ouput?
[11:11] <voidspace> dimitern: me too
[11:13] <wallyworld> axw_: was at soccer, will look soon
[11:19] <wwitzel3> that was weird
[11:19] <perrito666> wwitzel3: ?
[11:19] <wwitzel3> my bnc acted up, can't tell if what I typed was actually sending
[11:19] <wwitzel3> did you guys see my comments about using the termination work as a reference piece?
[11:20] <perrito666> nope
[11:20] <perrito666> I havent seen any comment from you
[11:20] <wwitzel3> natefinch: I ran into the same issue
[11:20] <wwitzel3> natefinch: I am currently making a barebones working using the termination worker as a reference
[11:21] <wwitzel3> natefinch: then I was going to make it watch the jobs collection
[11:21] <wwitzel3> natefinch: and just get that starting without hanging
[11:21] <natefinch> perrito666: yeah, no output, no logs at all
[11:22] <wwitzel3> natefinch: I'll let you know if that works in a second
[11:22] <natefinch> perrito666: like, /var/log/juju/ is empty
[11:22] <natefinch> wwitzel3: cool
[11:22] <natefinch> I gotta go afk for a couple hours.  Kids are up.
[11:22] <voidspace> dimitern: how long should it take for a new container to switch from "instance-id: pending" ?
[11:24] <dimitern> voidspace, if it's the first one, a few minutes until it downloads the image
[11:24] <voidspace> dimitern: ah
[11:24] <voidspace> dimitern: ok
[11:24] <perrito666> wallyworld: if you are still around I have answered you on the review and would appreciate an answer to that
[11:24] <wallyworld> perrito666: ok, looking
[11:24] <dimitern> voidspace, you could ssh into the host, sudo su -, then look in /var/lib/juju/containers/*/*.log and /var/lib/lxc/*
[11:26] <voidspace> dimitern: it's started :-)
[11:26] <voidspace> dimitern: and has a dns-name
[11:28] <dimitern> voidspace, it's a great feeling when it works, isn't it? :)
[11:28] <perrito666> dimitern: only if you know why
[11:28] <wallyworld> perrito666: hmmmm, i think we might want to retain the Stopped state
[11:29] <wallyworld> for that legacy agent-state
[11:29] <voidspace> dimitern: upgrade worked fine
[11:29] <voidspace> dimitern: and I appear to be able to deploy into the container
[11:29] <voidspace> dimitern: so the upgrade didn't break the container
[11:29] <dimitern> perrito666, :)
[11:29] <perrito666> wallyworld: works for me
[11:30] <dimitern> voidspace, so what was your scenario pre-upgrade?
[11:30] <wallyworld> perrito666: let's do it and we'll validate the decision
[11:30] <voidspace> dimitern: I just added the container
[11:30] <voidspace> dimitern: bootstrap then add container, wait for that to complete, upgrade
[11:31] <voidspace> dimitern: I have to go!
[11:31] <voidspace> dimitern: see you in a bit
[11:31] <dimitern> voidspace, ok, that's great - need to check with a destroyed container as well
[11:32] <perrito666> wallyworld: I believe Ill go with Unknown->Error and Terminated->Terminated
[11:32] <dimitern> voidspace, ping me when you're back
[11:33] <wallyworld> perrito666: i don't think Unknown->Error is quite right. we know if start hook has run
[11:33] <wallyworld> so unknown maps to pending or started
[11:33] <wallyworld> also, Terminated should ->Stopped
[11:33] <wallyworld> to keep using the legacy terminology
[11:52] <axw_> wallyworld: I'm thinking of simplifying storage provisioning a bit. I'm thinking of extending the storage.Provider interface to indicate whether or not it supports dynamic provisioning. If it does, provisioning will be done by the storage provisioner, and if it doesn't it'll be done by the machine provisioner
[11:52] <axw_> wallyworld: so then there'll be exactly one thing responsible for provisioning a volume
[11:53] <axw_> wallyworld: atm there's a race between storage provisioner and machine provisioner, and it's manifesting in the storage provisioner in my testing
[11:53] <wallyworld> axw_: that aspect was starting to occupy my thoughts also
[11:53] <wallyworld> not from anything concrete
[11:53] <wallyworld> but just to eliminate unnecessary complexity
[11:54] <axw_> wallyworld: the other thing I was thinking was removing Attachment from VolumeParams and FilesystemParams
[11:54] <wallyworld> that i hadn't been thinking about
[11:54] <axw_> wallyworld: so they're always created separately, rather than "maybe with the volume, maybe later on"
[11:55] <wallyworld> ok
[11:55] <axw_> wallyworld: we'd still do both at the same time in the machine provisioner
[11:55] <axw_> so there'd be a different type for that
[11:55] <wallyworld> ok, let's see how it plays out
[11:56] <axw_> I'll spike on it tonight/tomorrow, I think I can get something in that makes the storage provisioner more reliable
[11:57] <wallyworld> \o/
[11:59] <wallyworld> axw_: i also ran into that attached vs pending bug
[11:59] <wallyworld> in this http://reviews.vapour.ws/r/1186/
[12:00] <wallyworld> added a todo
[12:00] <wallyworld> could you look when you get a chance, no hurry
[12:01] <axw_> wallyworld: will do
[12:01] <wallyworld> ta
[12:32] <mattyw> fwereade, got a moment - irc is fine
[12:32] <fwereade> mattyw, sure
[12:42] <jw4> perrito666: thanks for the review - I think those issues can be dropped... thoughts?
[12:43] <perrito666> jw4: if you can say why :p I can certainly agree (but i was meaning to add them as comments not issues)
[12:43] <axw_> wallyworld: reviewed
[12:43] <wallyworld> ty
[12:44] <jw4> perrito666: sure - see if my responses make sense and if not we can keep them as issues
[12:45] <perrito666> jw4: ill answer in rb so its easier to follow up
[12:46] <jw4> perrito666: cool, tx!
[13:08] <jw4> thanks perrito666 I'll update the PR with your feedback :)
[13:08] <perrito666> jw4: the ones where I said nothing i am fine with dropping
[13:08] <jw4> perrito666: cool
[13:11] <wwitzel3> natefinch: well I got past juju just out right hanging, now I at least am getting "unknow object type Converter"
[13:11] <wwitzel3> natefinch: with an error of not implemented .. but it doesn't tell me what is not implemented
[13:12] <wwitzel3> natefinch: but getting closer :)
[13:13] <wwitzel3> THere is a way to tell logging not to redact responses right?
[13:21] <natefinch> wwitzel3: dunno about redacting responses
[13:22] <wwitzel3> natefinch: ok, well I'm trying to figure out what is "not implemented"
[13:23] <wwitzel3> natefinch: right now I've got it starting from the machine agent with StartWorker but it is just in a restart loop with that error
[13:23] <wwitzel3> natefinch: but again, that is better than hanging completely
[13:23] <wwitzel3> natefinch: I can push what I have if you want to look
[13:23] <natefinch> wwitzel3: sure
[13:24] <natefinch> fwereade: got any time to give us a hand?  We're trying to wire up a watcher, and it's causing the whole of jujud to blow up for some reason.
[13:25] <wwitzel3> natefinch: ok, pushed
[13:26] <wwitzel3> natefinch: well it isn't blowing up anymore, not it is just in an isolated restart loop :)
[13:26] <wwitzel3> improvement!
[13:27] <natefinch> wwitzel3: repeated smaller explosions better than one big one?  I guess so :)
[13:30] <alexisb> perrito666, you available for cloudbase call?
[13:31] <fwereade> natefinch, go on
[13:31] <fwereade> natefinch, fist guess is that it's returning an error that is somehow triggering the isFatal check in its runner or something?
[13:32] <natefinch> fwereade: could be, I'm just surprised that it would kill jujud before it could even write a log file
[13:32] <natefinch> fwereade: https://github.com/natefinch/juju/blob/ha-to/cmd/jujud/agent/converter.go
[13:33] <fwereade> natefinch, that ErrTerminateAgent looks to me like the problem
[13:33] <natefinch> fwereade: this is a worker for machine agent for when we convert a normal server to a state server
[13:34] <fwereade> natefinch, ErrTerminateAgent means "ok clean yourself up and never run again"
[13:34] <fwereade> natefinch, returning just-some-error will exit nonzero and put ourselves in the hands of the init system, which should then bounce us
[13:35] <fwereade> natefinch, so (assuming you do want to restart jujud, which seems sane) create some error that triggers isFatal, but don't use ErrTerminateAgent
[13:35] <natefinch> ahh ok
[13:36] <wwitzel3> oh well that's my fault
[13:36] <wwitzel3> reading the code it sure does look like ErrTerminateAgent is handled like the other IsFatal errors
[13:37] <wwitzel3> right along side the upgrade error
[13:37] <fwereade> wwitzel3, and it is, at the runner level -- but cmd/jujud/agent/machine.go:360
[13:38] <fwereade>     case worker.ErrTerminateAgent:
[13:38] <fwereade>         err = a.uninstallAgent(agentConfig)
[13:38] <wwitzel3> ahh
[13:38] <wwitzel3> yeah, we don't want that
[13:38] <fwereade> natefinch, wwitzel3: and FWIW it's my fault for not fixing ErrTerminateAgent when it became clear it was a problem waiting to happen
[13:40] <fwereade> natefinch, wwitzel3: it's a Very Bad Thing that we return it from the Uniter, for example
[13:40] <fwereade> natefinch, wwitzel3: it's not the uniter's job to decide whether the whole process should die
[13:40] <fwereade> natefinch, wwitzel3: it's the uniter's job to inform whatever started it that the unit doesn't need/want to exist any more
[13:41] <fwereade> natefinch, wwitzel3: and that code can then itself make a sober judgement as to whether uninstalling itself is really justified
[13:41] <fwereade> natefinch, wwitzel3: and, if so, itself return ErrTerminateAgent to the top level directly
[13:41] <fwereade> natefinch, wwitzel3: sane?
[13:43] <wwitzel3> fwereade: I'm working on a bit of a different problem than natefinch .. I'm refactoring the worker to it properly uses api facade instead of calling state directly as in the proof of concept.
[13:44] <wwitzel3> fwereade: but I'm running in to a restart loop with the new converter work, getting back not implemented, but all the params and responses are redacted, so it is a bit hard to tell what's happening
[13:45] <wwitzel3> fwereade: peppering logging bits throughout now :)
[13:50] <fwereade> wwitzel3, ha
[13:50] <fwereade> wwitzel3, that's a good thing in general
[13:52] <wwitzel3> fwereade: yeah, well we wanted to get a proof of concept working first, make sure we were on the right path
[13:52] <fwereade> wwitzel3, yeah, indeed
[13:52] <fwereade> wwitzel3, I don't have any immediate insight there, though, I'm afraid
[13:53] <wwitzel3> fwereade: think I found the problem
[13:53] <wwitzel3> fwereade: it helps if you declare the facadeVersion in api/facadeversions.go when using a facade
[13:53] <wwitzel3> :P
[13:54] <fwereade> wwitzel3, haha
[13:54] <wwitzel3> I could of sworn I did that
[13:55] <mup> Bug #1420049 changed: ppc64el - jujud: Syntax error: word unexpected (expecting ")") <deploy> <openstack> <regression> <uosci> <juju-core:Fix Released by axwalk> <juju-core 1.22:Fix Released by axwalk> <https://launchpad.net/bugs/1420049>
[13:55] <mup> Bug #1428692 changed: cannot boostrap vivid: Operation failed: No such file or directory <ci> <local-provider> <regression> <vivid> <juju-core:Fix Released by ericsnowcurrently> <https://launchpad.net/bugs/1428692>
[14:09] <perrito666> natefinch: ?
[14:10] <fwereade> by the way, can I trouble someone for another review of http://reviews.vapour.ws/r/1165/ please?
[14:11] <fwereade> ideally someone who's worked in the uniter, but if not I can answer questions
[14:12] <fwereade> wwitzel3, perhaps :) ^^
[14:14] <dimitern> fwereade, I'll have a look
[14:14] <fwereade> dimitern, tyvm
[14:15]  * dimitern learned a new word today - "impending" :)
[14:17] <fwereade> dimitern, that word goes very well with "doom" :)
[14:17] <wwitzel3> haha
[14:17] <dimitern> fwereade, I bet it does :D
[14:22] <dimitern> fwereade, in the comment starting at line 56 in modes.go, you mention we shouldn't try to accept leadership if we already did, but the code below doesn't seem to check for that
[14:23] <fwereade> dimitern, canAcceptLeader := !opState.Leader
[14:23] <fwereade> dimitern, the ordering of the statements in the comment is misleading though
[14:23] <dimitern> fwereade, also the check for Kind != Continue looks like we won't try if we're in any hook currently, not just pending hook
[14:24] <fwereade> dimitern, hence "eg (= for example) pending hook" not "ie (= that is specifically) pending hook"
[14:24] <dimitern> fwereade, right, I'll leave a comment to rephrase the comment a bit to match the impending code below it :)
[14:24] <fwereade> dimitern, haha, thanks
[14:24] <dimitern> fwereade, ok, fair enough
[14:25] <fwereade> dimitern, I should rephrase that too though
[14:25] <fwereade> dimitern, "if we're busy doing anything else at all, don't try to accept leadership"
[14:25] <dimitern> fwereade, yeah, that'll be much better, cheers
[14:38] <mup> Bug #1433116 was opened: 386 compilation error: dblogpruner/worker.go:32: constant 4294967296 overflows int <i386> <test-failure> <juju-core:Triaged> <https://launchpad.net/bugs/1433116>
[14:39] <sinzui> dimitern, natefinch We need someone to fix this critical ^. CI aborted testing because it cannot build all the packages. I am going to remove 386 from building to allow other tests to run
[14:41] <dimitern> sinzui, natefinch, I'll have a look, but unfortunately won't be able to help much about it today
[14:47] <jw4> sinzui: can you remind me how to run the tests using the gccgo compiler again?
[14:48] <dimitern> jw4, add -compile gccgo
[14:48] <jw4> dimitern: ta
[14:48] <dimitern> jw4, sorry, -compiler gccgo
[14:48] <jw4> kk
[14:50] <mup> Bug #1433116 changed: 386 compilation error: dblogpruner/worker.go:32: constant 4294967296 overflows int <i386> <test-failure> <juju-core:Triaged> <https://launchpad.net/bugs/1433116>
[14:53] <jw4> fwiw, go 1.4 seems incompatible with gccgo
[14:56] <natefinch> jw4: yeah, I ran into that.... brought it up as a problem on golang-dev, and they weren't really interested in fixing it
[14:56] <jw4> natefinch: lol, yeah, just noticed you were the reporter :)
[14:56] <natefinch> jw4: heh
[14:58] <natefinch> jw4: you can install go 1.2 side by side with 1.4 and use 1.2 as needed with gccgo... it's a little annoying, but not the end of the world
[14:58] <jw4> natefinch: yeah - I just switched to my laptop with 1.2.1 installed
[14:59] <dimitern> perrito666, natefinch, trivial review http://reviews.vapour.ws/r/1187/ - please take a look
[15:02] <mup> Bug #1433116 was opened: 386 compilation error: dblogpruner/worker.go:32: constant 4294967296 overflows int <i386> <test-failure> <juju-core:Triaged> <https://launchpad.net/bugs/1433116>
[15:02] <natefinch> dimitern: ship it!
[15:02] <dimitern> natefinch, cheers!
[15:02] <natefinch> also: good god gomaasAPI is a horrible cluster of a go package
[15:03] <dimitern> it really is
[15:03] <dimitern> it's written like a c library
[15:10] <natefinch> it's written like they just translated the REST API directly into Go calls, so you have to understand the REST API in order to use the package, rather than making the package abstract away the REST API.
[15:19] <dimitern> natefinch, another review - hopefully fixing bug 1433116 - http://reviews.vapour.ws/r/1188/
[15:19] <mup> Bug #1433116: 386 compilation error: dblogpruner/worker.go:32: constant 4294967296 overflows int <i386> <test-failure> <juju-core:Triaged> <https://launchpad.net/bugs/1433116>
[15:21] <perrito666> dimitern: add a comment there, looks like one of those things one would remove upon first sight thinking is a noob error
[15:22] <dimitern> perrito666, good point, will do
[15:24] <dimitern> perrito666, updated
[15:29] <dimitern> perrito666, and I have another one for you - http://reviews.vapour.ws/r/1189/ :) - last one for today I promise
[15:30] <perrito666> dimitern: looking
[15:31] <dimitern> perrito666, thanks!
[15:35] <perrito666> dimitern: btw, int in i386 is int32?
[15:37] <perrito666> somehow now I am not sure that your fix fixes the fix as you intend it to be fixed
[15:37] <dimitern> perrito666, it is
[15:38] <dimitern> perrito666, you mean because it will be negative perhaps?
[15:38] <perrito666> dimitern: https://play.golang.org/p/2LEwN2pZ9X
[15:39] <perrito666> dimitern: it blows
[15:39] <perrito666> at least there
[15:39] <perrito666> i wold expect the value to become math.MaxInt32
[15:40] <perrito666> actually I dont see a good reason for that value not being uint32 all the way (or in any case, explicit int size)
[15:41] <natefinch> dimitern, perrito666 : is there a reason it needs to be typed?
[15:41] <dimitern> perrito666, good point - we could constrain it to math.MaxInt32 for i386 or use the 4GB default otherwise
[15:42] <natefinch> +1 for using a math.Maxsomething
[15:42] <dimitern> natefinch, not that I can think of
[15:42] <perrito666> natefinch: yes, I believe its a good practice when the code is going to run in different int size archs to be explicit
[15:42] <perrito666> or you are just moving the overflow to the next guy
[15:43] <dimitern> perrito666, natefinch, ok, I'll tweak it a bit by initializing the default depending on the arch
[15:43] <natefinch> perrito666: constants never overflow, though
[15:43] <perrito666> there is explicit information in the type "this number needs a box this big to fit"
[15:44] <perrito666> natefinch: so says the doc
[15:45] <perrito666> natefinch: you cannot guarantee the use of that constant is going to be given
[15:45]  * perrito666 loves typing things
[15:46] <voidspace> dimitern: back
[15:46] <voidspace> dimitern: took longer than expected, sorry
[15:46] <voidspace> dimitern: I'll have to work tonight
[15:46] <voidspace> my new laptop arrived
[15:46] <voidspace> have to set that up later :-)
[15:46] <perrito666> voidspace: congrats, what did you get?
[15:48] <voidspace> perrito666: Dell XPS 15
[15:48] <voidspace> perrito666: it's basically as powerful as my desktop
[15:48] <perrito666> nice
[15:48] <voidspace> quad-core i7, 16gb ram
[15:48] <dimitern> voidspace, hey, no problem
[15:49] <dimitern> voidspace, I've discovered a nasty bug in our address allocation for maas - see http://reviews.vapour.ws/r/1189/
[15:49] <voidspace> dimitern: ah, ok
[15:49] <dimitern> voidspace, can you approve that btw?
[15:49] <voidspace> dimitern: was it our bug then, and not theres?
[15:49] <voidspace> dimitern: will look
[15:49] <voidspace> dimitern: hah, ouch
[15:49] <dimitern> voidspace, yeah, it was - but not because their API docs where clear enough to follow :)
[15:50] <voidspace> dimitern: LGTM
[15:50] <dimitern> voidspace, thanks, setting to land
[15:52] <voidspace> dimitern: ah, requested_address is actually the param name for claimstickyaddress op
[15:52] <dimitern> voidspace, and for ipaddresses op=reserve as well apparently
[15:52] <voidspace> dimitern: ah, I see
[15:52] <voidspace> it's that way round
[15:52] <voidspace> dimitern: ip is for release
[15:53] <jw4> OCR PTAL http://reviews.vapour.ws/r/1181 (got a round of reviews from perrito666 already, just need graduated reviewer approval)
[15:53] <dimitern> jw4, will look shortly
[15:53] <dimitern> voidspace, yeah :)
[15:53] <jw4> tx dimitern
[15:56] <dimitern> perrito666, natefinch, voidspace - this should be a better fix for bug 1433116 I guess - http://reviews.vapour.ws/r/1188/
[15:56] <mup> Bug #1433116: 386 compilation error: dblogpruner/worker.go:32: constant 4294967296 overflows int <i386> <test-failure> <juju-core:In Progress by dimitern> <https://launchpad.net/bugs/1433116>
[16:00] <dimitern> natefinch, perrito666, voidspace, no sorry, that's not good enough still - updated http://reviews.vapour.ws/r/1188/ again
[16:02] <natefinch> dimitern: I wonder how much we care about the one extra byte on amd64 :/
[16:02] <mup> Bug #1433161 was opened: feature request: support virtual services <cloud-installer> <juju-core:New> <https://launchpad.net/bugs/1433161>
[16:02] <dimitern> natefinch, you mean 2 bytes I guess?
[16:03] <dimitern> if not actually four
[16:03] <dimitern> natefinch, re int vs int32?
[16:07] <natefinch> dimitern: nevermind, I was thinking MaxUint32... actually it's a factor of 2
[16:08] <dimitern> natefinch, ah, well 4GB limit for logs seems too much to me even on x86_64
[16:08] <natefinch> #1433116
[16:08] <mup> Bug #1433116: 386 compilation error: dblogpruner/worker.go:32: constant 4294967296 overflows int <i386> <test-failure> <juju-core:In Progress by dimitern> <https://launchpad.net/bugs/1433116>
[16:09] <voidspace> dimitern: LGTM
[16:10] <dimitern> voidspace, thanks!
[16:10] <natefinch> dimitern: is there a reason we couldn't change whatever is using int to int64?  I mean...  seems like what we intend, anyway
[16:11] <dimitern> natefinch, that's not for me to say - I intend to fix the build failure on i386, not to change the assumptions
[16:11] <natefinch> dimitern: the assumption is that we wqanted 4GB
[16:11] <natefinch> dimitern: the architecture problem just shows why using "int" was a bad idea
[16:12] <natefinch> dimitern: having the log half as big because you're on a different architecture does not seem like a design decision anyone would intentionally make
[16:12] <perrito666> natefinch: we are punishing users for actually still use i386
[16:12] <natefinch> perrito666: heh
[16:12] <voidspace> perrito666: yep, that sounds reasonable
[16:13] <natefinch> dimitern: seriously, though.  The fix to just change LogPruneParams to int64 seems way more simple and obvious
[16:13] <voidspace> dimitern: you wanted me to repeat the upgrade test with a destroyed container
[16:13] <voidspace> dimitern: and then see if the IPAddress is marked as Dead?
[16:14] <perrito666> voidspace: off course it is, no savvy user should use archs older than the ony my mom uses, and she has x86_64
[16:14] <dimitern> natefinch, ok, can I ask you to comment on the proposal then and I won't land it as is, will leave it for thumper or menn0 to decide
[16:14] <dimitern> voidspace, yes please
[16:15] <voidspace> dimitern: I'll have to use direct mongo access to see I guess...
[16:15] <voidspace> dimitern: unless you have a better idea
[16:15] <dimitern> voidspace, not really
[16:15] <dimitern> voidspace, you could just add more logging :)
[16:15] <voidspace> dimitern: hah, well if we're going to trust *code* to tell us
[16:15] <voidspace> dimitern: we could just trust the test
[16:16] <voidspace> dimitern: but that's not a bad idea
[16:16] <dimitern> voidspace, I forgot to mention that earlier actually - it's good to have logs during upgrade steps lest it goes wrong
[16:16] <voidspace> dimitern: I'll create a new branch and add logging
[16:16] <dimitern> natefinch, thanks!
[16:16] <dimitern> voidspace, sounds good
[16:16] <natefinch> dimitern: welcome, sorry to be a pain in the butt :)
[16:22] <dimitern> natefinch, not at all - I prefer a better solution than a quick and dirty fix :)
[16:25] <dimitern> jw4, reviewed
[16:25] <jw4> dimitern: gratzie
[16:26] <perrito666> ok ill be OoO for a moment, be back later
[16:30] <jw4> dimitern: I think the first two issues can be dropped?  I'll work on the third.
[16:30] <jw4> dimitern: and yes, I'm also waiting for a sanity check from fwereade
[16:31] <dimitern> jw4, let me have another look
[16:31] <jw4> dimitern: ta
[16:31] <dimitern> jw4, yeah, sounds good re the first two issues
[16:31] <jw4> dimitern: cool
[16:32] <dimitern> jw4, sorry, so do you intend to keep the second assert there?
[16:33] <jw4> dimitern: it seems reasonable to me - it's asserting a subtly different thing than the first assert
[16:33] <dimitern> jw4, if you need to verify the cause as well and there's a specific error you can check for, better use jc.Satisfies
[16:33] <jw4> dimitern: oh, interesting
[16:33] <jw4> dimitern: since I only touched this because wording changed elsewhere, I'm not keen to change the tests too much.
[16:34] <jw4> dimitern: but I'm willing if you feel strongly about it
[16:34] <dimitern> jw4, not that strong :)
[16:34] <jw4> dimitern: k
[16:35] <dimitern> voidspace, I guess you're afk now
[16:37] <voidspace> dimitern: no, here
[16:37] <dimitern> voidspace, ah, ok :)
[16:48] <frankban> ocr could you please take a look at https://github.com/juju/charm/pull/94 when you have time? thanks!
[17:32] <voidspace> hmmm... so the bad news is that maas seems to have crapped out pretty badly and looks like I need to reinstall
[17:32] <voidspace> the good news is that I've started the ubuntu install on the xps 15...
[17:32] <voidspace> hah, although looks like I need a mouse as the trackpad isn't working
[17:33] <voidspace> or maybe I can proceed without it
[17:34] <mattyw> voidspace, any idea if dimitern has gone for good?
[17:34] <mattyw> (for good meaning - today)
[17:34] <voidspace> screen is lovely
[17:34] <voidspace> mattyw: yes, gone for the day
[17:35] <mattyw> voidspace, ok thanks - screen as in < tmux?
[17:35] <mattyw> perrito666, you available to do a review for me?
[17:35] <perrito666> mattyw: sure
[17:35] <perrito666> mattyw: shoot
[17:35] <mattyw> perrito666, http://reviews.vapour.ws/r/1005/
[17:35] <mattyw> perrito666, thanks very much
[17:36] <mattyw> perrito666, it has an LGTM but I made some largeish changes since
[17:36] <perrito666> mattyw: it has a ship it
[17:36] <perrito666> ah ok
[17:37]  * perrito666 wonders how mattyw did large changes in such a short patch
[17:37] <mattyw> perrito666, I try to keep my patches short and focused
[17:37] <mattyw> perrito666, it was largish in that it was > 60% of the patch changed
[17:37] <perrito666> so to make a change large you add a lot and then remove it? :p
[17:38] <voidspace> mattyw: screen as in - the physical screen on my new laptop (Dell XPS 15 - currently installing ubuntu on it)
[17:38] <mattyw> voidspace, oh right, I saw you twittering about that I think
[17:38] <mattyw> voidspace, be interested to see how you get on, I like dells - and I think I'm due a new one at the end of the year
[17:40] <ericsnow_> voidspace, mattyw: natefinch and I have that same laptop, I believe
[17:41] <ericsnow_> voidspace, mattyw: and axw too
[17:41] <mattyw> ericsnow_, is that the one you had in brussels?
[17:41] <ericsnow_> mattyw: yep
[17:42] <mattyw> ericsnow_, ah yes - on the laptop with the insane resolution :)
[17:42] <ericsnow_> mattyw: to which I forgot the power cord and had to beg hits off the other two guys :)
[17:49] <perrito666> mattyw: I have some concerns I reviewed it
[17:50] <mattyw> perrito666, ok thanks
[17:51] <mattyw> perrito666, yeah - that type thing is the thing that's keeping me from landing this branch - everyone has a different idea for how it should look - and it started off not being part of my change :)
[17:51] <mattyw> perrito666, good shout about the maps - I'd forgotten about that
[17:52] <perrito666> mattyw: in my pov this opens the possibility of garbage strings comming down the line, the speciffic type sends a message of what you are expecting to come down the line
[17:52] <perrito666> mattyw: that is the justification for my objection , in case it helps
[17:52] <mattyw> perrito666, that's right, but so does type MeterStatusCode string
[17:53] <mattyw> perrito666, I don't disagree with you at all
[17:53] <mattyw> perrito666, I'm just trying to find a way of fixing it
[17:53] <perrito666> mattyw: well a function expecting to receive (or return) a string is much less useful in terms of information than one expecting MeterStatusCode
[17:54] <perrito666> you are making a statement in terms of the content of that string :)
[17:54] <perrito666> natefinch: you can break the tie?
[17:54] <perrito666> anyway, i need to get afk for a moment, bbl
[17:54] <mattyw> perrito666, no problem
[18:07] <natefinch> perrito666:  reading scrollback
[18:28] <natefinch> wwitzel3: any luck?
[18:32] <mup> Bug #1433254 was opened: manual provider on trusty/precise syntax error near unexpected token `then' <manual-provider> <ppc64el> <systemd> <juju-core:In Progress by ericsnowcurrently> <juju-core 1.23:In Progress by ericsnowcurrently> <https://launchpad.net/bugs/1433254>
[18:47] <marcoceppi> I've got a general golang question
[18:48] <marcoceppi> I want to get the http status code of a URL, I'm guessing this is the http library but I'm not sure how to check response code
[18:51] <jw4> marcoceppi: golang.org/pkg/net/http/#Get
[18:52] <jw4> when you issue the Get on the url you get back a *Response
[18:52] <jw4> which has Status among other things
[18:52] <marcoceppi> jw4: awesome, thanks! I'll give that a /go/
[18:52] <marcoceppi> bwhahah
[18:52] <jw4> lol
[19:00] <natefinch> you can tell a newbie gopher by all the bad jokes
[19:01] <jw4> natefinch: lq - marcoceppi is a ninja so I'm going to lq (laugh quietly) instead of lol
[19:42] <mup> Bug #1433244 was opened: MAAS should handle RAM upgrades without decommissioning / recommissioning existing nodes <openstack> <uosci> <juju-core:New> <MAAS:Won't Fix> <https://launchpad.net/bugs/1433244>
[19:48] <mup> Bug #1433244 changed: MAAS should handle RAM upgrades without decommissioning / recommissioning existing nodes <openstack> <uosci> <juju-core:New> <MAAS:Won't Fix> <https://launchpad.net/bugs/1433244>
[19:57] <ericsnow_> OCR: PTAL http://reviews.vapour.ws/r/1190/
[19:58] <ericsnow_> perrito666: ^^^
[20:00] <ericsnow_> good morning, thumper
[20:00] <thumper> o/
[20:00] <ericsnow_> thumper: when you get settled, I have a quick question for you
[20:00] <thumper> better be quick
[20:00] <thumper> stand up is now
[20:02] <ericsnow_> thumper: I can wait
[20:03] <mup> Bug #1433244 was opened: MAAS should handle RAM upgrades without decommissioning / recommissioning existing nodes <openstack> <uosci> <juju-core:New> <MAAS:Won't Fix> <https://launchpad.net/bugs/1433244>
[20:47] <ericsnow> menn0, perrito666: PTAL http://reviews.vapour.ws/r/1190/
[20:49] <menn0> ericsnow: i'll take a look after i've finished with the review i'm currently looking at
[20:49] <ericsnow> menn0: thanks!
[20:57] <perrito666> ericsnow: I added one comment to the bash stuff but my brain is jello I cannot in good concience review embedded bash and produce useful output
[20:57] <ericsnow> perrito666: np :)
[21:01] <thumper> cmars: chat today?
[21:03] <rick_h_> thumper: he's out this week
[21:03] <thumper> rick_h_: cheers, I guess that is a no then :)
[21:04] <thumper> rick_h_: my daughter is wanting me to help with a school thing on Friday
[21:04] <thumper> rick_h_: any chance we can reschedule our meeting?
[21:05] <rick_h_> thumper: we can try tomorrow but have to ask urulama|afk as it's late late his time
[21:05] <thumper> rick_h_: ok
[21:05] <thumper> rick_h_: alternatively I could try to make it earlier
[21:05] <thumper> rick_h_: say... if I got up at 6am for the call
[21:06] <thumper> rick_h_: it would make it earlier for urulama|afk and you
[21:06] <thumper> as long as it doesn't clash with other calls you may have
[21:06] <thumper> rick_h_: so... 3 or 3.5 hours earier than currently specified
[21:06] <rick_h_> thumper: well I'm booked honestly. You can see if there's a slot that works for you but my wed/thurs are call days
[21:06] <thumper> ah
[21:06]  * thumper tries to see rick_h_'s calendar
[21:07] <rick_h_> thumper: if you can find a slot happy to move it around
[21:07] <thumper> rick_h_: I see a slot there...
[21:07]  * thumper calculates timezones
[21:07] <thumper> rick_h_: are you EDT?
[21:08] <rick_h_> thumper: yep
[21:08] <rick_h_> feel free to take it then
[21:08] <thumper> 1pm? your time
[21:08] <rick_h_> thumper: wfm
[21:08] <rick_h_> and urulama|afk looks open
[21:08] <thumper> I think that would be 6 or 7pm for ubuntulog2
[21:08] <rick_h_> so happy to move it earlier then
[21:08] <rick_h_> lol
[21:08] <thumper> ok, lets do it for this week
[21:08]  * thumper moves
[21:08]  * thumper sighs
[21:08] <thumper> perhaps ubuntulog2 doesn't want to come
[21:09] <thumper> unless it can automatically minute our meeting
[21:10] <thumper> rick_h_: moved
[21:10] <rick_h_> thumper: yay, I can't wait :)
[21:20] <thumper> heh
[21:38] <menn0> ericsnow: done. lots of problems with the bash code unfortunately.
[21:38] <ericsnow> menn0: k, thanks
[21:54] <mup> Bug #1433336 was opened: juju deploy tags are persistent accross juju deploys <cts> <juju-core:New> <https://launchpad.net/bugs/1433336>
[21:55] <ericsnow> menn0: are you sure about `[[ ! $? ]]` ?
[21:56] <ericsnow> menn0: I'm pretty sure you're right in the case of a single bracket, but the double bracket works
[21:56] <menn0> ericsnow: yep. I just included an example in reply to your comment.
[22:08] <ericsnow> menn0: weird. your example works for me
[22:09] <ericsnow> menn0: ah, it's the ! that is messing things up
[22:09] <thumper> ericsnow: thing I found with bash is always use -ne or -eq
[22:10] <thumper> never test unaddorned
[22:10] <thumper> also, I always quote args, "$1"
[22:10] <thumper> never just $1
[22:10] <ericsnow> thumper: yep
[22:10] <thumper> in [[ ]] at least
[22:10] <ericsnow> bash is a minefield
[22:10] <thumper> also... I hate bash scripts
[22:10] <thumper> true that
[22:10] <ericsnow> menn0's got my back :)
[22:11] <alexisb> wallyworld, ping
[22:11] <wallyworld> alexisb: hey
[22:11] <alexisb> heya
[22:11] <alexisb> I just sent you a mail
[22:12] <wallyworld> ok, looking
[22:12] <alexisb> the error looks familiar
[22:12] <alexisb> does it to you as well?
[22:12] <menn0> ericsnow: strange that it works differently for you
[22:13] <menn0> ericsnow: could be a bash version thing or a shopt thing
[22:13] <menn0> ericsnow: i'd still play it safe and use the more conventional check
[22:13] <ericsnow> menn0: no, it was only without ! that it worked the way I expected
[22:13] <ericsnow> menn0: agreed
[22:14] <wallyworld> alexisb: the series string is missing from the binary version
[22:14] <wallyworld> what are they running juju on?
[22:14] <alexisb> a maas setup on a VM
[22:15] <alexisb> and I cant repo in on my env
[22:15] <ericsnow> menn0: all fixed
[22:15] <wallyworld> alexisb:  no, not surprised, it's a setup issue of some sort, but i'll need to dig a little to find root cause
[22:16] <alexisb> I dont want to bother youm but can you give me some pointers on what to look at?  It is on a partners test setup in class and it is bugging me that I cant figure out what he has done different
[22:16] <menn0> ericsnow: looking again
[22:16] <ericsnow> menn0: ta
[22:17] <wallyworld> alexisb: no problem at all. can we run sync-tools with --debug
[22:18] <wallyworld> so we can see where it's looking for the tools tarballs
[22:18] <wallyworld> it could be a badly named file
[22:19] <thumper> ericsnow, menn0: what is the first line of the discovour script?
[22:19] <thumper> by default, it runs through /bin/sh right?
[22:19] <thumper> which is dash on some servers
[22:19] <thumper> not bash
[22:19] <menn0> #!/usr/bin/env bash
[22:20] <thumper> just a query, but I do wonder if bash is really bash on some servers
[22:20] <thumper> it may not be
[22:20] <menn0> it would be pretty awful if it wasn't
[22:20] <thumper> yes
[22:20] <thumper> perhaps it was changing sh for dash not bash
[22:20] <thumper> that I recall
[22:21] <ericsnow> thumper: that sounds plausible
[22:21]  * menn0 nods
[22:21] <menn0> what you get with /bin/sh is a little "flexible"
[22:21] <alexisb> wallyworld, getting logs for you
[22:21] <menn0> but is supposed to be posix compatible sh
[22:21]  * thumper sighs
[22:22] <thumper> apiserver tests take over two minutes
[22:22] <wallyworld> alexisb: ty, and then pastebin please
[22:22] <thumper> I wish this was faster
[22:22] <menn0> directly asking for bash should be safe enough though
[22:23] <alexisb> o crap wallyworld I just emailed
[22:25] <wallyworld> alexisb: never minds, email works :-)
[22:26]  * thumper swears at the tests
[22:29] <ericsnow> davecheney: could you take another look at http://reviews.vapour.ws/r/1172/?
[22:29] <wallyworld> alexisb: just for kicks, can you please try "sudo apt-get install distro-info-data" \
[22:29] <wallyworld> on the machine running ysnc-tools
[22:30] <alexisb> yep one sec
[22:30] <wallyworld> i suspect the machine doesn't know about vivid
[22:32] <alexisb> wallyworld, already installed
[22:32] <alexisb> didn't make a difference
[22:32] <menn0> ericsnow: done. just one question but ship it otherwise.
[22:32] <ericsnow> menn0: thanks
[22:32] <wallyworld> alexisb: ok, i'll dig into the code and get back to you
[22:33] <wallyworld> alexisb: also, bug 1433336 - it's working as designed, constraints used at bootstrap time become default constraints from then on
[22:33] <mup> Bug #1433336: juju deploy tags are persistent accross juju deploys <cts> <juju-core:New> <https://launchpad.net/bugs/1433336>
[22:34] <alexisb> wallyworld, thanks, not urgent, just bugging us :)
[22:34] <wallyworld> so if you want to bootstrap to a machine using tags, you'll need to set the constraints again afterwards
[22:34] <alexisb> wallyworld, can you add a note to bug 143336
[22:34] <mup> Bug #143336: __bobo_traverse__ and ftp/webdav <bug> <zope> <Zope 2:Invalid> <https://launchpad.net/bugs/143336>
[22:34] <wallyworld> yep
[22:34] <alexisb> thanks
[22:34] <wallyworld> i'l find this current issue first
[22:35] <alexisb> wallyworld, I know you guys are busy, so really not urgent stuff, but we got lots of feedback from classmates on juju stuff (from core to gui) so I was trying to get info back to the team
[22:35] <wallyworld> alexisb: that sort of feedback is very much desired
[22:36] <wallyworld> was just giving you a heads up on the reason for the bug
[22:36] <wallyworld> i agree the usability kinda sucks in that case
[22:40] <thumper> oh for the love of <insert deity>
[22:40]  * thumper headdesks
[22:41] <wallyworld> alexisb: i think that the maas machine needs to have that distro info package installed as well
[22:41] <wallyworld> alexisb: i suspect the standard maas images don't have it
[22:48] <alexisb> wallyworld, I installed distro info on both the maas machine and the bootstrapped machine that has the maas image, and it makes no difference.
[22:49] <wallyworld> alexisb: trouble is, juju will now have cached it's knowledge of the distro info, so you will need to bounce the agent
[22:50] <wallyworld> sudo service juju-agent restart   <-- i can't recall OTTOMH what the exact service name is
[22:50] <wallyworld> look in /etc/init
[23:05] <menn0> ericsnow: I just added one more comment. Summary: you should use utils.ShQuote instead of %q or "%s"
[23:07] <wallyworld> alexisb: how'd you get on? ping if you're still stuck
[23:16] <alexisb> still not working
[23:16] <alexisb> but they are going to kick us out soon
[23:16] <alexisb> wallyworld, I will try to repo tomorrow
[23:17] <wallyworld> alexisb: ok, let me know how you go etc
[23:26] <ericsnow> menn0: would you mind also taking a look at http://reviews.vapour.ws/r/1172/
[23:46] <wallyworld> thumper: perrito666 says you owe him an email?
[23:46] <thumper> yeah...
[23:46]  * thumper has been distracted
[23:47] <thumper> ohh... shiney
[23:47] <menn0> ericsnow: will do. i just have to take care of a few other things first.
[23:47] <ericsnow> menn0: no worries :)