[00:24] <waigani> thumper, menn0: trunk also kills network. I've filed a bug: https://bugs.launchpad.net/juju-core/+bug/1349635
[00:24] <_mup_> Bug #1349635: Destroying a manually provisioned lxc container breaks network configuration on host computer. <juju-core:Triaged> <https://launchpad.net/bugs/1349635>
[00:42] <axw> waigani: agh, I got that too. I think worker/networker may be screwing with things that it shouldn't.
[00:43] <axw> waigani: did you bootstrap your host?
[00:43] <axw> I think that's what caused it for me.
[00:43] <axw> pretty sure destroying a container has nothing to do with it
[00:43] <waigani> axw: oh really?
[00:43] <waigani> axw: so just "juju bootstrap" ?
[00:44] <axw> waigani: bootstrapping the manual provider, yeah
[00:44] <waigani> ha
[00:44] <waigani> that's even worse
[00:44] <axw> not entirely sure tho
[00:45] <axw> I haven't attempted to narrow it down
[00:45] <waigani> I have to put digging into it on hold for now
[00:59] <wallyworld> thumper: can you mark bug 1349312 as in progress and assign it to someone so we can see it's being looked at?
[00:59] <_mup_> Bug #1349312: Machine stuck in "down" state because "an upgrade is in progress" <cloud-installer> <landscape> <juju-core:Triaged> <juju-core 1.20:Triaged> <https://launchpad.net/bugs/1349312>
[01:01]  * wallyworld bbiab
[01:21] <davecheney> thumper: i've been trying to carve up my names change
[01:21] <davecheney> but it's hard
[01:21] <davecheney> state.FindEntity requires that we parse the tag to a Tag
[01:21] <davecheney> and that needs to happen in every api call
[01:22] <davecheney> and also every api call also calls a common.AuthFunc
[01:22] <davecheney> so I can carve my change up into just the change to state.FindEntity which requires parsing in every api endpoint
[01:22] <davecheney> or I can carve it up into a change to common.AuthFunc to take a Tag
[01:23] <davecheney> there is a lot of crossover in each PR
[01:23] <davecheney> maybe I should just keep it together in one
[01:23] <davecheney> i'm down to a few failing tests in the ./apiserver/... packages
[01:23] <davecheney> which are all symtoms of the same thing; returning an error that isnt common.ErrPerm
[01:23] <davecheney> and I've mostly got those fixed
[01:46] <wallyworld> katco: i moved you lxc card back to review until the merge to master is also done
[01:46] <wallyworld> ie until both branches of the bug are marked fix committed
[02:07] <davecheney> wallyworld: thumper axw https://github.com/juju/juju/pull/411
[02:07] <davecheney> ^ this one is blocking my names branch
[02:08] <axw> looking
[02:09] <wallyworld> davecheney: i don't have enough context - are you going to add real authenticators later?
[02:09] <axw> likewise
[02:09] <axw> davecheney: is the intention not to assign something meaningful to getCanWrite/getCanRead?
[02:10] <davecheney> axw: no idea
[02:10] <davecheney> but that logic was a time bomb
[02:10] <wallyworld> generally our api server endpoints need authenticators
[02:11] <wallyworld> the ones there were placeholders for sure
[02:11] <wallyworld> pending the real ones being added
[02:11] <wallyworld> i'm not sure it's valid to remove them and all the associated logic
[02:12] <wallyworld> maybe that's a question thumper needs to answer as you guys know the roadmap better than us
[02:12] <davecheney> wallyworld: those checks are noops
[02:12] <davecheney> when they are removed the code still passes
[02:12] <wallyworld> sure, now they are
[02:12] <davecheney> when they are not noop's someone can add them back
[02:12] <davecheney> but right now they are actively doing the wrong thing
[02:13] <davecheney> like authenticating invalid tags
[02:13] <wallyworld> right now, they are saying "we do not offer authentication"
[02:13] <davecheney> worse
[02:13] <davecheney> "we say YES to anyone"
[02:13] <davecheney> or anything
[02:13] <davecheney> or ""
[02:13] <davecheney> IMO they are worse than useless
[02:15] <wallyworld> isn't this wip though?
[02:15] <wallyworld> no one is using this yet
[02:15] <davecheney> wallyworld: right, when they do we can revert this change
[02:15] <davecheney> that is what source control is for
[02:15] <davecheney> but given how much time we generall have to go back and clean up messes
[02:16] <davecheney> i'd say the chances of that happening anytime this cycle are pretty low
[02:16] <wallyworld> i guess i'm just not across the roadmap/plans for usermanager so can't really offer an authorative comment
[02:17] <wallyworld> where's thumper when you need him
[02:17] <davecheney> wallyworld: after a week in NZ with thumper
[02:17] <davecheney> it'll be onxy doing the work
[02:17] <davecheney> matty and green are moving back to the other thing they normally do
[02:18] <wallyworld> sure, but maybe he plans to add authentication for usermanager next week
[02:18] <wallyworld> that's the sort of planning i hav no visibility to
[02:18] <davecheney> wallyworld: then we can revert this change then
[02:18] <davecheney> but after spending a week in NZ with thumper
[02:18] <wallyworld> if the code is removed, the behaviour is the same as now right, everything gets through?
[02:19] <davecheney> i an pretty confident that we're not working on that next week
[02:19] <davecheney> wallyworld: yes, the athentuication logic is currently hard coded to accept any string and give it the thumbs up
[02:19] <wallyworld> so, why remove it? there's no change in behaviour after the removal, ahd the dummy auth is clearly labeled
[02:20] <wallyworld> and avoids code churn
[02:20] <davecheney> wallyworld: because the logic only athenticates tags, not username strings
[02:20] <davecheney> the tag commonly passed by the api is invalid
[02:21] <davecheney> but the logic doesn't check that
[02:21] <davecheney> the dummy auth code is wrong
[02:21] <davecheney> because it always says true to anything
[02:21] <davecheney> even when it is an invalid tag
[02:21] <davecheney> but agian, there are no tests to even check this
[02:21] <davecheney> I want to remove this code, it was a mistake
[02:22] <wallyworld> ok. so with the stuff removed, we will still allow invalid tags though just like now. why not jusy fix the dummy auth code?
[02:22] <wallyworld> then everything that uses it will benefit
[02:22] <davecheney> wallyworld: i am fixing it
[02:22] <davecheney> this is pulled out of my larger strings -> names.Tag branch
[02:22] <davecheney> do you want to review a 40 line change, or a 3,000 line change :)
[02:22] <wallyworld> ah ok, sorry, as ai said, i have no contest for this
[02:23] <wallyworld> context
[02:23] <davecheney> s'ok
[02:23] <davecheney> the problem is that an invlida tag shouldn't even make it this far into the api
[02:23] <wallyworld> so long as "you" promise to fix it later, i'll got and +1 :-)
[02:23] <davecheney> it's also complicated by the fact that the usermanager accepts both a username string and a tag
[02:23] <davecheney> (a tag as a string that is)
[02:24] <davecheney> yet, canRead/canWrite only validate the tag
[02:24] <davecheney> which is completely broken
[02:24] <davecheney> and only works currently because canRead("") returns true
[02:24] <davecheney> even though "" is not a valid tag
[02:24] <wallyworld> yeah, sounds messy
[02:24] <davecheney> in summary, the logic is all fucked up and these dummy functions are actively not helping
[02:24] <davecheney> so, out they go
[02:24] <wallyworld> ok :-)
[02:25] <davecheney> ta
[02:25] <davecheney> anyone else for a second look ?
[02:25] <davecheney> (i'll wait for thumper, he won't be far away)
[02:29] <wallyworld> axw: got time to talk?
[02:30] <axw> wallyworld: sure
[02:30] <axw> tanzanite hangout?
[02:30] <wallyworld> standup hangout
[02:30] <wallyworld> yup
[02:31] <thumper> davecheney: sup?
[02:31] <davecheney> thumper: https://github.com/juju/juju/pull/411
[02:32] <davecheney> ^ from my larger names change
[02:32] <davecheney> see the pasionate discussion I put forth in the backscroll
[02:32] <thumper> kk
[02:34] <thumper> davecheney: in other words, it is big and very hard to break apart, so please review the big one?
[02:35] <davecheney> no, bertter than that, please review this https://github.com/juju/juju/pull/411
[02:35] <davecheney> which is a smaller one
[02:35] <davecheney> which unblocks my larger one
[02:36] <thumper> ack, will get food and look while munching
[02:44]  * davecheney steps away from the keyboard
[02:44] <wallyworld> thumper: after munching can we have a chat
[02:48] <thumper> davecheney: I'm not sure about that change
[02:48] <thumper> davecheney: sure, right now the authenticators do nothing
[02:48] <thumper> but there is logic there for when we change them
[02:49] <wallyworld> that's what wallyworld said :-)
[02:49] <thumper> how does this unblock other work?
[02:49]  * thumper reads more of the scrollback
[02:51] <thumper> wallyworld: real authentication isn't slated for this cycle
[02:51] <thumper> but will likely be the start of next
[02:51] <wallyworld> ok, but i would have though we'd want *some* validity checks
[02:53] <wallyworld> thumper: do you have time to talk now?
[02:53] <thumper> wallyworld: sure
[02:54]  * wallyworld creates hangout
[02:54] <wallyworld> https://plus.google.com/hangouts/_/g5aavwaio7thqbiatwjbdtsdrma
[02:54] <thumper> wallyworld: it says the party is over
[02:55] <wallyworld> ffs
[02:55] <wallyworld> https://plus.google.com/hangouts/_/canonical.com/tanzanite-stand
[03:33] <davecheney> thumper: 1. the authenticators are wrong
[03:33] <davecheney> they authenticate INVALID data
[03:34] <davecheney> not just say yes to VALID users
[03:34] <davecheney> 2. they arent' tested
[03:34] <davecheney> this code passes 100% without them
[03:34] <davecheney> that alone is reason to remove them
[04:19] <waigani> thumper: can we do a hangout when you have a mo?
[04:19] <davecheney> wallyworld: jcw4 just told me that the bot isn't runing gofmt checks anymore
[04:31] <davecheney> jcw4: just pushed a branch to fix the problem
[04:32] <thumper> waigani: sure...
[04:32] <jcw4> davecheney: tx!
[04:36] <waigani> thumper: https://plus.google.com/hangouts/_/gyvhagf6dafbd3piihpd5jtt5ia?hl=en
[04:45] <wallyworld> davecheney: might not be, i'll check with martin
[04:47] <davecheney> wallyworld: it used to do this
[04:47] <davecheney> i wonder where that check was lost
[04:47]  * davecheney ponders on the parable about the elephant and the piece of string
[04:47] <wallyworld> totally different scripts
[04:48] <wallyworld> we should be able to add it back in
[04:48] <davecheney> wallyworld: eh ? the bot has nack'd changes before 'cos they aren't goformatted
[04:49] <wallyworld> github lander or tarmac?
[04:50] <davecheney> wallyworld: github
[04:51] <wallyworld> hmmm, in that case i have no idea, i didn't realise it had changed
[04:51] <wallyworld> seems like a mistake
[04:51] <wallyworld> i'll get it fixed
[06:02] <hazmat> is trunk broken?
[06:03] <hazmat> hmm.. maybe a wierd cycle around updates, tags, and godeps
[06:04] <voidspace> morning all
[06:05] <hazmat> hmmm.. can't build 1.20.2 -> src/launchpad.net/gnuflag": bzr: ERROR: branch has no revision roger.peppe@canonical.com-20140716064605-pk32dnmfust02yab
[06:06] <voidspace> I just did a pull and build ok
[06:43] <axw> wallyworld: you're not planning on just changing the fslock code are you? I think you can only change the template management call site to use flock
[06:43] <wallyworld> axw: yep, not changing fslock at all
[06:43] <axw> cool
[06:43] <wallyworld> just the template stuff
[06:44] <axw> I think the charm locks need to outlive processes, but not entirely sure
[06:44] <wallyworld> yep, just making minimal changes for 1.20
[06:49] <fwereade> good mornings
[06:49] <axw> morning
[07:28] <TheMue> morning
[07:34] <voidspace> fwereade: morning (from Romania)
[07:34] <voidspace> TheMue: morning
[07:35] <TheMue> voidspace: Romania?
[07:35] <voidspace> TheMue: I'm in Romania for the next month
[07:35] <voidspace> TheMue: it's where my wife is from
[07:36] <voidspace> so I'm currently working from the balcony of a flat in the town where her parents live
[07:36] <voidspace> Nice and sunny
[07:36] <voidspace> TheMue: are you working on ipv6 container addressability?
[07:36] <TheMue> voidspace: yep, I’m getting closer
[07:37] <voidspace> TheMue: can I help or should I pick something else up?>
[07:37] <voidspace> either way I need coffee first
[07:37] <TheMue> voidspace: in my scenario two hosts see each other, see the containers they run, those containers can see each other, but a container on one host doesn’t reach a container on another host
[07:38] <voidspace> ah, interesting
[07:38] <voidspace> and confusing...
[07:38] <TheMue> voidspace: hehe, yes
[07:39] <TheMue> voidspace: will just update my doc with the latest scenario and share it with you then
[07:41] <voidspace> TheMue: cool
[07:41] <voidspace> I'm grabbing coffee - back in a bit
[07:41] <TheMue> ok
[07:41] <fwereade> voidspace, ah, nice
[07:42] <fwereade> TheMue, would you describe your scenario a little more?
[07:42] <fwereade> TheMue, AFAIK we haven't done the container-addressability work we'd need to get that working
[07:42] <fwereade> TheMue, in MAAS it should work but not anywhere else
[07:44] <TheMue> fwereade: currently it’s no development stuff, it’s simply the evaluation how an IPv6 network has to be configured to enable IPv6 traffic to/from/between containers
[07:46] <fwereade> TheMue, what are you working against?
[07:49] <TheMue> fwereade: in a first step against pure LXC. IPv6 is pretty new to me and I’m reading/trying a lot. next step has to be discussed with jam then
[07:50] <fwereade> TheMue, yeah, to me too :)
[07:50] <TheMue> fwereade: sure ;)
[07:50] <fwereade> TheMue, what's the end goal of what you're doing?
[07:50] <TheMue> fwereade: currently a proof of concept for IPv6 and LXC
[07:51] <fwereade> TheMue, because I thought that the first ipv6 use case we were targeting was about just managing ipv6 *and* ipv4 addresses in dual-stack networks
[07:51] <TheMue> fwereade: later, as I understood jam, the active setting of addresses on any kind of nodes (hosts and containers)
[07:52] <fwereade> TheMue, sorry, cannot quite parse, restate please?
[07:52] <TheMue> fwereade: hehe, yip
[07:54] <TheMue> fwereade: if I understood jam right he talked about a change where at least containers don’t work with the address the infrastructure passes them (which is link-local) but ask the API for a public adress and use it
[07:54] <TheMue> fwereade: hope I phrased it better now
[07:55] <fwereade> TheMue, certainly, we will want that -- that's what I think of as "container addressability" and I agree it's important
[07:56] <TheMue> fwereade: yep, that’s how I understood it
[07:56] <fwereade> TheMue, I'm not sure that doing it for ipv6 alone is quite what we're looking for at the moment though -- I thought we were aiming at working with dual-stack networks in situations that already work first of all
[07:57] <TheMue> fwereade: detailed task planning is still open, as we’re only have been us two the last week
[07:57] <fwereade> TheMue, I'm not trying to seagull you, don't let me stop you -- but... ah ofc dimitern is on holiday in malta, probably on a boat, can't ask him right now
[07:58] <TheMue> fwereade: hehe, yeah, diving. he worked on the topic too before he left
[07:59] <TheMue> fwereade: but jam will be back tomorrow, so you can talk to him then
[07:59] <fwereade> TheMue, cool, thanks
[08:00] <TheMue> fwereade: yw
[08:00] <TheMue> fwereade: how has your trip been? stressful?
[08:02] <fwereade> TheMue, new zealand is lovely, travelling there not so much
[08:02] <fwereade> TheMue, not so stressful really
[08:02] <fwereade> TheMue, I actually wrote some code which made a nice change
[08:02] <TheMue> fwereade: but surely a very long flight
[08:03] <fwereade> TheMue, yeah, pretty much all weekend both ways
[08:03] <TheMue> fwereade: would like to visit NZ once too
[08:03] <fwereade> TheMue, 2 full working weeks of travel in 1 week :/
[08:04] <TheMue> fwereade: hard. with a stop in Hongkong or Singapure?
[08:05] <fwereade> TheMue, dubai, bangkok, sydney, christchurch, dunedin
[08:05] <TheMue> fwereade: ouch! so many? uuugh
[08:06] <fwereade> TheMue, yeah, was a bit much :)
[08:06] <fwereade> TheMue, at least I didn't have to stop in tripoli, which the original tickets had
[08:06] <fwereade> TheMue, but emirates was kind enough to not send me through there while the airport was being actively bombarded
[08:06] <axw> :o
[08:07] <axw> stop over in libya, via ukraine
[08:07] <TheMue> fwereade: eh, hey, it has been planned as a business trip, no adventure tour
[08:07] <TheMue> axw: you forgot syria
[08:08] <fwereade> haha
[08:23] <voidspace> fwereade: you're in NZ now?
[08:23] <voidspace> a sprint?
[08:23] <voidspace> I understood the ipv6 work was to support our telco customer who required it
[08:24] <voidspace> NZ is lovely, I was there last year. But I only explored the North Island.
[08:25] <fwereade> voidspace, back now
[08:25] <fwereade> voidspace, bit scrambled mentally still
[08:25] <voidspace> fwereade: ah
[08:25] <voidspace> fwereade: yeah, long journey. About as far as you can go in fact.
[08:25] <fwereade> voidspace, yeah, which is why I raised a bit of an eyebrow at what TheMue was doing
[08:25] <fwereade> voidspace, indeed :)
[08:26] <voidspace> fwereade: ah right - because for that we need ipv6 support, but we don't yet need nested container support
[08:26] <voidspace> hmmm
[08:26] <fwereade> voidspace, I'd kinda expected that the ipv6 work that'd actually be delivering value is the stuff we talked about with jamespage and rbasak -- private-address and private-address-ipv6, and setting the right ones in the right situations
[08:27] <voidspace> fwereade: that sounds right, although in an ipv6-only scenario I'd hope that juju would "just work"
[08:28] <voidspace> if machines/providers report ipv6 addresses we use those without problem
[08:28] <voidspace> and we've fixed some issues around that
[08:28] <fwereade> voidspace, yeah, it turns out that what we actually need is dual-stack support for the relation addresses
[08:29] <voidspace> (e.g. no longer explicitly dropping ipv6 addresses, passing the right flags to mongo)
[08:29] <voidspace> fwereade: ok
[08:29] <voidspace> and as you say, dimiterm is our real expert here
[08:29] <voidspace> although I'd expect jam to be pretty clued up as to the roadmap
[08:30] <fwereade> voidspace, yeah, mongo on ipv6is another of the details I keep forgetting about ;)
[08:30] <voidspace> fwereade: that should be done
[08:30] <fwereade> voidspace, brilliant
[08:30] <voidspace> barring horrible mongo bugs - like the fact that mongo can't parse ipv6 addresses
[08:30] <voidspace> :-)
[08:31] <voidspace> so long as you stick to the format they don't manage to internally screw up you're alright though
[08:31] <voidspace> (you must use ::1:port format, and not [::1]:port nor a bare address without a port)
[08:34] <fwereade> eww :)
[08:38] <bodie_> if anyone has a few minutes to rip up my code so I can make a semblance of usefulness tomorrow, would be much appreciated! https://github.com/juju/juju/pull/415
[08:38] <bodie_> (4:30am est right now -- I need to sleep the sleep of the dead)
[08:53] <voidspace> TheMue: you got the link to your doc?
[08:55] <TheMue> voidspace: one moment
[08:58] <voidspace> sure
[09:36] <mattyw> morning folks
[09:40] <voidspace> brb, back soon
[09:40] <voidspace> TheMue: I may be a couple of minutes late to standup
[09:40] <voidspace> TheMue: not long though
[09:43] <TheMue> voidspace: we’re only we both ;)
[09:43] <voidspace> TheMue: oh!
[09:43] <voidspace> TheMue: where is jam ?
[09:46] <TheMue> voidspace: national holiday
[09:46] <voidspace> ah
[10:04] <perrito666> good morning
[10:07] <voidspace> perrito666: morning
[10:36] <wallyworld> hazmat: you around?
[10:37] <natefinch> whelp, it's gonna be another long day.  Had totally reinstall the OS this morning... recopying my home directory now, but hello reinstalling everything.
[10:47] <perrito666> natefinch: ouch
[10:48] <perrito666> for next time this happens, there is a dpkg invocation that might be of help there
[10:48] <natefinch> in theory you should be able to reinstall on top of the old installation and it'll keep your home directory, but the installer said there was no OS installed, which is.... interesting
[10:50] <natefinch> I think my OS was f'ed up somehow. No idea how, but if the installer can't even tell there's an OS there... something is pretty screwy
[10:51] <natefinch> now I have to figure out if I overwrite all my dot files, if it'll muck up this install
[11:20] <natefinch> current status: restoring my backed up trash folder.  Sigh.  I wonder how much of my backed up data is just filecaches, trash, and downloaded installers
[11:29] <axw> wallyworld: running late again tonight. if you can hold off for 30 mins I can probably make the standup
[11:29] <axw> otherwise: I did more mongo 2.6 stuff
[11:29] <axw> couple of PRs in the queue
[11:30] <wallyworld> axw: it's my wife's birthday today so i want finish the stand up and have a drink
[11:30] <wallyworld> but any other time i could delay
[11:31] <mgz> is katco on yet? we could do it early instead
[11:31] <wallyworld> might be too early
[11:31] <axw> wallyworld: fair enough :)
[11:42] <natefinch> hey, reinstalling made workspaces work on my machine finally
[11:45] <perrito666> lol
[12:04] <natefinch> hopefully copying over all my dotfiles will mean I don't have to reconfigure everything to work the way it used to.... but I'm not too optimistic
[12:04] <hazmat> wallyworld, am now
[12:05] <wallyworld> hazmat: could you reply to the email about the api endpoint changes as per the bug you want backported?
[12:05] <natefinch> like... how the hell do you turn off sound effects on Ubuntu?  That's always my first stop when installing Windows... turn off all the damn sounds.  Computers should be seen and not heard
[12:05] <wallyworld> hazmat: i'm not 100% across the exact changes as i didn't do the work
[12:06] <hazmat> wallyworld, sure
[12:06] <wallyworld> ty
[12:14] <perrito666> natefinch: which sounds?
[12:15] <perrito666> natefinch: I think you installed the wrong OS :p
[12:23] <wwitzel3> natefinch: dconf-editor will let you disable most sounds that annoy you.
[12:23] <perrito666> wwitzel3: natefinch also there is a mute button :p
[12:24] <natefinch> perrito666: the startup sound, for one.... there's also an annoy ploink sound that happens occasionally and I don't exactly know what causes it.
[12:24] <natefinch> perrito666: mute only works so long as I don't actually want to hear music or videos or hangouts
[12:25] <perrito666> you said you did not want to hear your computer :p
[12:25] <wwitzel3> natefinch: /usr/share/sounds/ubuntu is where the files are, you can always just rename the ones you don't want with .mute
[12:25] <voidspace> TheMue: I'd still love a link to your doc
[12:25] <voidspace> TheMue: plus any suggestions as to what I might usefully work on
[12:25] <natefinch> that's not the computer, that's media.  Things ploinking is hearing my *computer*
[12:26] <voidspace> TheMue: none of the things in the kanban queue looked plausible for me to start
[12:26] <TheMue> voidspace: you should have get a mail
[12:26] <voidspace> wwitzel3: natefinch: morning from Romania
[12:26] <voidspace> wwitzel3: natefinch: actualy 3:30pm more or less
[12:26] <voidspace> TheMue: ah, ok - I'll check
[12:26] <TheMue> voidspace: when I shared the doc with you
[12:26] <voidspace> TheMue: thanks
[12:26] <perrito666> hi voidspace, seems that moonstone in romania is becoming a trend :p
[12:26] <wwitzel3> voidspace: o/
[12:26] <natefinch> voidspace: howdy.... how was your vacation?
[12:26] <voidspace> TheMue: hmmm... no
[12:26] <voidspace> natefinch: EuroPython, it was cool
[12:27] <TheMue> voidspace: currently I changed the setup below a bit
[12:27] <voidspace> natefinch: lots of love for logstash backed by Elasticsearch for distributed logging
[12:27] <wwitzel3> yeah, people love some ELK
[12:31] <hazmat> wallyworld, also the fix in trunk for that issue is broken.. it turned a list into a scalar.
[12:32] <hazmat> wallyworld, http://pastebin.ubuntu.com/7894639/
[12:35] <katco> wallyworld: happy birthday to your wife!
[12:36] <perrito666> katco: in my country that is practically an insult :p
[12:36] <katco> perrito666: lol
[12:36] <katco> all things are impermanent. no use in fighting it :)
[12:49]  * perrito666 's chair armrest breaks apart while he was using it to get up and now he has 2 hurting fingers bc his hand landed on a very hard 5mm steel piece
[12:50] <perrito666> that hurts
[12:51] <katco> ouch =/
[12:51]  * perrito666 tries to shop online for a chair not made of plastic
[12:51]  * perrito666 fails
[12:57] <perrito666> wallyworld: https://pbs.twimg.com/media/BtQnfw2CYAIh123.jpg
[13:04] <katco> TheMue: you around?
[13:04] <TheMue> katco: yep
[13:05] <katco> TheMue: i've been tasked with backporting https://bugs.launchpad.net/juju-core/+bug/1311227
[13:05] <_mup_> Bug #1311227: juju api-endpoints has no way to distinguish public and private addresses <api> <regression> <juju-core:Triaged by themue> <juju-core 1.20:Triaged> <https://launchpad.net/bugs/1311227>
[13:05] <katco> just want to double-check; this looks like the PR for that? https://github.com/juju/juju/pull/208
[13:05] <TheMue> katco: yes, exactly
[13:06] <katco> TheMue: great, i'll cherry that and be on my way :) thank you!
[13:06] <TheMue> katco: yw, it’s a small change
[13:12] <TheMue> katco: it seems to need a change
[13:13] <katco> TheMue: ?
[13:13] <TheMue> katco: if I understand hazmat correct (see last comment), we have to return [0:1] instead of [0]
[13:14] <TheMue> katco: so that the rendering as JSON or YAML would have the correct format
[13:14] <TheMue> katco: see http://pastebin.ubuntu.com/7894639/
[13:15] <katco> TheMue: ah. not sure what the thing to do is. wallyworld pretty urgently wanted this backported so we could cut 1.20.3
[13:16] <katco> do we usually fix further bugs before backporting?
[13:16] <TheMue> katco: the current change only returns one string, the former one returned a slice with one string
[13:16] <TheMue> katco: in this case the renderings are different
[13:17] <katco> TheMue: yeah i see that. so i guess you're saying we wouldn't want to backport before fixing this issue?
[13:18] <TheMue> katco: I would change the backport in a way that it returns the slice and change the current trunk to it in a second issue for the 1.21 again
[13:19] <katco> TheMue: gotcha. i'll see what i can do. thanks for the guidance :)
[13:20] <TheMue> katco: has been an interesting feedback by hazmat for me too
[13:21] <TheMue> katco: absolutely missed that beside the data we also changed the type and that this influences the rendering
[13:24] <TheMue> katco: shall I quickly do the change on trunk?
[13:30] <katco> TheMue: sure, if you feel like it! i'm still getting going (still earlyish here)
[13:31] <TheMue> katco: ok
[13:31] <katco> TheMue: sounds like it should be a 2-char change?
[13:33] <TheMue> katco: exactly ;)
[13:36] <hazmat> TheMue, correct
[13:37] <hazmat> TheMue, katco as long as your doing that per state server
[13:37] <hazmat> and extending the result slice
[13:38] <TheMue> yep
[13:59] <natefinch> sinzui: want to go to Romania?
[14:00] <voidspace> I have somewhere to stay if you do...
[14:01] <perrito666> sinzui: http://i1.kym-cdn.com/photos/images/facebook/000/001/384/Atrapitis.gif
[14:02] <voidspace> hah :-)
[14:02] <natefinch> perrito666: haha
[14:02] <perrito666> sinzui: natefinch says you have to go see this guy http://upload.wikimedia.org/wikipedia/en/0/00/CountDracula6.jpg
[14:02] <voidspace> TheMue: I *just* got an email saying you shared the doc with me :-)
[14:03] <TheMue> voidspace: heya, only hours later
[14:03] <voidspace> right :-)
[14:03] <sinzui> perrito666, I understand Dracula's Castle is for sale. It could be a new Disney attraction
[14:03] <TheMue> who is OCR today?
[14:03] <perrito666> TheMue: fwereade
[14:04] <voidspace> there are lots of "dracula's castle"
[14:04] <TheMue> I’ve got https://github.com/juju/juju/pull/417, a quick change.
[14:04] <TheMue> fwereade: ^^^
[14:04] <perrito666> sinzui: if disney keeps buying things we will soon see a crossover of avengers + jedis vs vampires
[14:05] <perrito666> natefinch: standup
[14:05] <sinzui> :)
[14:05] <voidspace> sounds fun
[14:06] <natefinch> perrito666: thanks, one sec
[14:06] <voidspace> although jedis plus vampires versus avengers maybe
[14:11] <fwereade> TheMue, is that really addressing the bug? I'm not convinced it should be throwing away all the addresses
[14:11] <fwereade> TheMue, it's definitely good that it's a list again, true
[14:12] <fwereade> TheMue, but don't we want the public addresses for all the state servers?
[14:13] <TheMue> fwereade: if I remember correctly we decided to do it this way because of the problems to determine which address is public and which not
[14:14] <TheMue> fwereade: depending on the environment and its address range (e.g. in private clouds)
[14:15] <fwereade> TheMue, dammit, do we still have addresses in state that don't know their scope?
[14:16] <TheMue> fwereade: apiendpoint.Addresses simply is a string slice :(
[14:17] <fwereade> TheMue, grar, ok
[14:19] <katco> fwereade: TheMue: it sounds like there may be a larger issue here. just some context to try and represent wallyworld's request: i think he wanted this backported ASAP so we can do a cut on v1.20.3, so i think whatever is safe, but quick would be preferred.
[14:19] <fwereade> katco, yeah, agreed, I just LGTMed it slightly grudgingly
[14:19] <katco> fwereade: i know that pain! :) ty!
[14:20] <fwereade> katco, we evidently should be storing addresses with a sensible scope in the first place, and I *think* that should be possible now
[14:20] <TheMue> fwereade: yeah, I once started with a kind of filtering: https://github.com/TheMue/juju/commit/9dce055bac4eb3fa275a007584894eace0d82841
[14:20] <fwereade> katco, modulo all the tedium of dealing with old API versions etc etc
[14:20] <TheMue> fwereade: but then we had the discussion about it
[14:22] <TheMue> fwereade: but storing the socpe directly with the address is better, yep
[14:22] <fwereade> TheMue, we might not even need to do that client-side -- we could plausibly just make sure we only return addresses with a sensible scopein the first place
[14:23] <perrito666> query fwereade
[14:23] <perrito666> lol
[14:23] <perrito666> that was /query
[14:23] <TheMue> fwereade: sounds good, yes. are there cases a client could be interested in private addresses too?
[14:25] <fwereade> TheMue, I fear that's not impossible -- in general I think we only know what addresses make sense if we know where people want to connect *from*
[14:25] <TheMue> hmm, yeah
[14:28] <rogpeppe1> fwereade: gentle ping re: my last suggestion for charm.URL vs charm.Reference in the juju-dev thread. We'd quite like to move forward with some solution.
[14:29]  * fwereade looks back fretfully
[14:32]  * TheMue just fetched a Ben & Jerry’s Chocolate Fudge Brownie against the warm weather
[14:34] <fwereade> rogpeppe1, ah, hmm: I sorta see where you're coming from, but it also feels like most places should be parsing urls and only falling back to parsing references where that fails -- and that having a reference implies a separate code path that needs to better qualify the reference?
[14:34] <fwereade> rogpeppe1, although, heh, a URL may itself want to be further qualified by looking up the best revision
[14:35] <rogpeppe1> fwereade: anything that's a URL is also a Reference
[14:35] <rogpeppe1> fwereade: but not vice versa
[14:36] <rogpeppe1> fwereade: the case i'm specifically needing to deal with here is that we need to marshal and unmarshal series-agnostic URLs and there's no decent way of doing that currently
[14:37] <fwereade> rogpeppe1, ok, that makes sense, I think
[14:38] <rogpeppe1> fwereade: cool, thanks
[14:38] <fwereade> rogpeppe1, I still feel there's something a bit off about having the same type underneath -- would it make sense to you to define them separately?
[14:38] <rogpeppe1> fwereade: i don't really see why that's useful
[14:40] <fwereade> rogpeppe1, I'm more concerned that reusing the same structure for two different purposes is turning a coincidental similarity into something more
[14:40] <rogpeppe1> fwereade: it's surely not a coincidental similarity
[14:40] <fwereade> rogpeppe1, "coincidental" is slightly too strong a word, true...
[14:40] <rogpeppe1> fwereade: and in fact redefining the fields is exactly equivalent
[14:41] <fwereade> rogpeppe1, I'm mostly nervous I'll see people casting between them
[14:41] <rogpeppe1> fwereade: they can do that even if the fields are separately defined
[14:43] <fwereade> rogpeppe1, so they can
[14:43]  * fwereade shudders gently
[14:43] <fwereade> rogpeppe1, ok, consider objections withdrawn
[14:43] <perrito666> fwereade: can I get a moment of you in hangout?
[14:43]  * perrito666 irq's
[14:43] <rogpeppe1> fwereade: thanks
[14:43] <katco> rogpeppe1: hey you maintain godeps, right?
[14:43] <rogpeppe1> katco: i do
[14:43] <fwereade> perrito666, yeah, set one up, with you in 3-4 mins
[14:44] <rogpeppe1> katco: and i'm aware it has a rather annoying bug with godeps -u currently :-)
[14:44] <katco> rogpeppe1: could i request that in the event of an error, it return an error code to the shell? :)
[14:44] <rogpeppe1> katco: it *should* do :-)
[14:44] <rogpeppe1> katco: can you provide a repro case?
[14:44] <katco> rogpeppe1: hm let me see
[14:45] <perrito666> fwereade: https://plus.google.com/hangouts/_/g4hpll6qr6xz4jfhqotbeap4dua
[14:46] <rogpeppe1> katco: it looks to me at a quick scan that it's doing it ok
[14:46] <katco> rogpeppe1: same here. i ran into something last night... i'll let you know if it's repro or not :p thanks :)
[14:46] <rogpeppe1> katco: np
[15:00] <perrito666> ericsnow: ill go back to restore, let me know if you need anything else from me
[15:00] <ericsnow> perrito666: will do
[15:04] <katco> TheMue: ty for landing that so quickly! backporting now :)
[15:04] <TheMue> katco: yw, you’ve seen it’s only a quick and dirty fix
[15:05] <katco> TheMue: i think that actually might be best case in this situation.
[15:05] <katco> TheMue: just b/c of the urgency of cutting v1.20.3
[15:05] <TheMue> katco: yes, here a better solution would last too long
[15:06] <katco> TheMue: (putting 3 years of german class to work): danke!
[15:06] <TheMue> katco: wunderbar :D
[15:06] <katco> TheMue: haha
[15:07] <TheMue> h5
[15:10] <bodie_> good morning #juju-dev :)
[15:10] <katco> good morning bodie_
[15:13] <katco> TheMue: i'm still relatively new to backporting w/ git.. do i cherry all the commits in your PR in order? or can i just do the last one in the original PR?
[15:15] <TheMue> katco: I have to admit, I’ve so far never tried it.
[15:15] <TheMue> katco: surely somebody else has more experience here
[15:15] <katco> TheMue: ok, thanks :) i'll see what google has to say in addition
[15:16] <katco> TheMue: i suppose this is a use-case for squashing
[15:21] <perrito666> ok, question to all:
[15:22] <perrito666> I have a file on a client machine and want to get it into environ storage, what is the preferred way to get there
[15:22] <perrito666> ?
[15:26] <gsamfira> katco: here's a great article about cherry-picking: http://wiki.koha-community.org/wiki/Using_Git_Cherry_Pick
[15:27] <katco> gsamfira: ty! i'll give it a read
[15:27] <gsamfira> my pleasure :)
[15:39] <katco> mgz: not entirely sure this CI failure is b/c of my code. can you have a look? http://juju-ci.vapour.ws:8080/job/github-merge-juju/154/console
[15:45] <katco> i'm going to resubmit in the meantime...
[15:48] <bodie_> katco, something I like to do is just rebase on master to get my commits to the top of the pile, then merge to the branch I'm trying to land
[15:48] <bodie_> then rebase -i against master, and fixup all but the top commit, reword that one
[15:49] <bodie_> not sure if that's what you're looking for, but it's pretty clean
[15:49] <bodie_> that's something I've learned since working on this project, I always used to simply merge, but I think it makes for a very usable log
[15:50] <bodie_> of course, you might be talking about a completely different use-case for git, in which case feel free to pipe this to /dev/null
[15:51] <katco> bodie_: thanks for the tip! in this case i'm trying to go from master -> backport branch.
[15:52] <katco> bodie_: cherrypick works just fine for me, the thing i'm wondering about is if there's a way to grab an entire PR instead of cherry picking all the discrete commits in PRs
[15:53] <bodie_> I imagine the best way would be to cherry-pick <old hash>..<new hash> assuming the ones you want are in a continuous range
[15:53] <bodie_> if they're not, perhaps do it anyway and rebase -i simply deleting the undesired entries
[15:53] <bodie_> although
[15:53] <bodie_> you can checkout pr's
[15:54] <bodie_> but that's kind of hacky and ugly and makes your fetches enormous
[15:54] <bodie_> at least, the way I have it set up
[15:54] <bodie_> ymmv
[15:54] <bodie_> https://gist.github.com/piscisaureus/3342247
[15:55] <bodie_> apparently there's also this
[15:55] <bodie_> https://help.github.com/articles/checking-out-pull-requests-locally
[15:55] <bodie_> if you don't want to permanently add the ability
[15:58] <katco> hey cool :)
[16:21] <katco> bugger... CI is going to fail again looks like. mgz are you there?
[16:45] <mgz> katco: am now, but it's not the end of the world to let a failing run just complete
[16:45] <katco> mgz: yeah, just wondering why it failed. i do see some kvm stuff in there now i'll have to look at after i land this backport
[16:46] <katco> initially i saw a bunch of mongo stuff: PANIC: action_test.go:1: MachineSuite.TearDownTest
[16:46] <katco>  
[16:46] <katco> ... Panic: Cannot drop MongoDB database juju: local error: bad record MAC (PC=0x4144D6)
[16:46] <katco> http://juju-ci.vapour.ws:8080/job/github-merge-juju/154/console
[16:48] <mgz> that's a know intermittent thing, but there's also a nill deref in kvm BrokerSuite?
[16:49] <katco> yeah, have to look at that. i didn't touch the brokers, but it's probably related to my changes somehow
[16:53] <mgz> katco: just see if you can repo locally first, you also have the second run to compare with
[16:54] <katco> mgz: will do, thanks. working on some other test failures in this backport =/
[17:17] <fwereade> katco, we're pretty sure the "bad record mac" stuff is a mongo 2.4 bug -- if you're seeing it against 2.6 that's worth making noise about
[17:18]  * fwereade supper
[17:18]  * perrito666 supra 
[17:18] <perrito666> man, that was a better joke in my head
[17:19] <jcw4> perrito666: lol
[18:07] <perrito666> sinzui: I submitted a fix for https://bugs.launchpad.net/juju-core/+bug/1342937 and its merged :(
[18:07] <_mup_> Bug #1342937: Juju restore  fails Could not get lock /var/lib/dpkg/lock <backup-restore> <ci> <regression> <juju-core:Triaged by hduran-8> <https://launchpad.net/bugs/1342937>
[18:07] <sinzui> perrito666, update the bug to fix committed
[18:08] <perrito666> ah apologize, I forgot that does not happen anymore
[18:08] <sinzui> perrito666: I miss that feature too
[18:09] <perrito666> there, changed and sent a mail in response
[18:14] <katco> how do i connect to juju's mongo instance using the mongo shell? i do mongo localhost:37017, but i receive "Error: DBClientBase::findN: transport error: localhost:37017 ns: admin.$cmd query: { whatsmyuri: 1 } at src/mongo/shell/mongo.js:147
[18:14] <katco> exception: connect failed"
[18:15] <sinzui> katco, juju-db doesn't have js support
[18:16] <jcw4> katco: one thing I've found is that to connect you need to specify --ssl
[18:16] <katco> jcw4: that worked, thank you :)
[18:17] <jcw4> but I actually haven't figured out how to connect to juju mongo and actually poke around in the collections... did you get that far?
[18:17] <jcw4> I always get authentication issues and I haven't figured out the incantation yet
[18:17] <katco> sinzui: so how do i explore juju's mongo instance? are you saying it doesn't support the mongo frontend? sorry, i'm pretty unfamiliar with mongo
[18:18] <natefinch> perrito666: ^^
[18:18] <katco> jcw4: obviously not :p
[18:18] <jcw4> katco: lol
[18:18] <natefinch> perrito666: didn't you document how to log into mongo somewhere?
[18:18] <katco> i try to issue show dbs and get "listDatabases failed:{ "ok" : 0, "errmsg" : "unauthorized" } at src/mongo/shell/mongo.js:46"
[18:19] <katco> i mean it looks like mongo is a js shell, so i surmise that it won't work at all b/c of sinzui's statement, but i thought that was the canonical way to talk to a mongo instance...
[18:19] <katco> i didn't know there was another way
[18:20] <jcw4> katco: that's what I would expect too... I'm hoping perrito666 did indeed document the right way
[18:21] <jcw4> sinzui: do you mean that connecting to juju mongo using the standard mongo cli doesn't work?
[18:25] <sinzui> jcw4, that's right. I think the "mongo" command is crippled because it is backed by webkit js engine that wasn't compiled with juju-mongo
[18:26] <jcw4> sinzui: oh, very interesting.  Is there a 'right' way to poke around in mongo then or do you have to write code to do that always?
[18:27] <sinzui> jcw4, I think it is code. I don't have any experience hacking a working juju-db.
[18:27] <jcw4> sinzui: tx
[18:27] <katco> ugh
[18:27]  * katco wonders how she's going to debug this test failure
[18:28] <katco> ... Panic: watcher iteration error: not authorized for query on juju.txns.log (PC=0x40EF8D)
[18:28] <jcw4> katco do you have the link to the full log? Is it a recent build in jenkins?
[18:30] <katco> jcw4: https://pastebin.canonical.com/114411/
[18:30] <katco> jcw4: it's a local test failure; trying to backport a modification
[18:31] <natefinch> friggin' a.... backing up my home directory removed the execute bit from all any applications that happened to be in there
[18:32] <natefinch> well, backing up and restoring
[18:32] <jcw4> katco: I'm an external contractor, I don't think I have access to that pastebin
[18:32] <katco> natefinch: i think you could write a very short script to do a "file"
[18:32] <jcw4> I'm just wondering if it's a transient issue or a consistently reproducable issue
[18:33] <katco> natefinch: and chmod +x to any ELF binaries
[18:34] <katco> jcw4: try this: http://pastebin.com/4S4mwBzE
[18:34] <katco> jcw4: i'm pretty sure it's not transient given these changes are in the stack of the panics
[18:35] <katco> jcw4: but i'm new, so i'm also pretty sure i'm wrong often :)
[18:35] <jcw4> katco, i see :)
[18:36] <jcw4> katco: Panic: cannot share a state between two dummy environs; old "dummyenv"; new "dummyenv" (PC=0x40EF8D)
[18:36] <jcw4> katco: is it possible you're inadvertently spinning up two instances of the dummy environment?
[18:37] <katco> jcw4: you know i forgot, i think it's recommended to run on only 1 cpu
[18:37] <jcw4> katco: oooh... maybe two tests are running concurrently and stepping on each other
[18:37] <katco> jcw4: right
[18:37] <katco> attempting again!
[18:38] <katco> jcw4: however, that first error doesn't seem to be related to that, does it?
[18:38] <katco> "not authorized"?
[18:39] <jcw4> katco: I wonder if the authorization was for one env, and failed against the other
[18:39] <jcw4> dunno if auth is generated per-env
[18:39] <katco> jcw4: well, i suppose i'll just see what running on 1 cpu does for me.
[18:39] <jcw4> fun
[18:39] <katco> i completely forgot about that
[18:40] <katco> curse my extra cores! curse them!
[18:40] <jcw4> haha
[18:44] <perrito666> natefinch: I documented many things but not how to log into mongo
[18:44] <perrito666> yet
[18:45] <perrito666> mongo -u <machine-tag> -p <statepassword> host:port/juju
[18:45] <perrito666> is simple enough to remember
[18:46] <perrito666> or mongo -u admin -p <oldpassword> host:port/admin
[18:46] <jcw4> perrito666: I think the <machine-tag> was the part I was missing
[18:46] <perrito666> which might or might not work
[18:46] <jcw4> I don't think the -u admin works, but I may have been using the wrong <oldpassword>
[18:46] <perrito666> you might, that changes
[18:46] <perrito666> anyway, bike time, bbl
[18:46] <jcw4> perrito666: have fun
[18:49] <katco> jcw4: fyi, this run seems to be going _quite_ a bit more smoothly.
[18:50]  * jcw4 crosses his fingers
[18:51] <katco> what is <machine-tag> in the above example?
[18:53] <jcw4> katco: not sure... I've tried "0", "machine-0", "machine/0" to no avail, but I might be using the wrong password too... I
[18:53] <jcw4> I'm grepping the password from the local.jenv file
[18:55] <jcw4> I got those id's by taking the output of 'juju status', and inferring possible tag prefixes for the 0th machine
[18:56] <katco> https://github.com/juju/juju/pull/419 for backport to v1.20
[18:56] <katco> jcw4: same.
[18:59] <jcw4> ah!
[19:00] <jcw4> katco: maybe ~/.juju/local/agents/machine-0/agent.conf
[19:00] <katco> jcw4: checking...
[19:01] <jcw4> katco: bingo!
[19:02] <jcw4> grr... show collections gets the next error: not authorized for query on juju.system.namespaces
[19:02] <jcw4> :)
[19:06] <katco> huh, so this is still failing for me: "mongo -u=machine-0 -p=<statepassword> localhost:37017/juju
[19:06] <katco> oh shoot forgot ss
[19:06] <katco> ssl
[19:07] <jcw4> katco: I also just used spaces instead of =
[19:07] <jcw4> dunno if that makes a difference
[19:07] <jcw4> brb
[19:07] <katco> well now i get login failed. hm
[19:10] <katco> there we go!
[19:10] <katco> jcw4: but yes, get same error
[19:39] <katco> so it looks like my changes are failing because machineConfig did not have a environs/config/Config... will that ever occur? should i fix the tests, or change my code to account for possible nil Config values?
[19:41] <natefinch> I think that should be impossible
[19:42] <katco> natefinch: ty, nate. so fix the test(s)?
[19:42] <natefinch> yeah.... are these tests you wrote?  if not, why are they failing now, just you using a value that wasn't used before?
[19:43] <katco> they are not. worker/provisioner/kvm-broker_test.go
[19:43] <katco> they are failing now b/c i introduced a change in kvm.go to look at machineConfig.Config.ImageStream()
[19:43] <katco> and apparently these tests don't set up machineConfig.Config
[19:44] <natefinch> Yeah, that's kind of the problem with our tests... we mock out enough to get the code to pass, but if you deviate from what's mocked out, things explode
[19:44] <natefinch> so, yeah, need to set up a machine config
[19:44] <katco> natefinch: mocking more than 1 level is a smell i think. you end up with tests that are very tightly coupled to your exact implementation which defeats the purpose of mocking =/
[19:46] <natefinch> yeah..... a *lot* of our tests are that way, unfortunately
[19:46] <katco> i would like to have this very interesting discussion with juju-dev, but i need to be less new.
[19:47] <natefinch> heh yeah
[19:47] <natefinch> me too ;)
[19:48] <katco> right now i'm just breaking all the things :) and drinking from the firehouse, and using a bunch of colloquialisms
[19:50] <natefinch> heh... and typoing them in interesting ways
[19:51] <katco> natefinch! a hacker never typos. she types exactly what she means, when she means to say it! (name that movie)
[19:51] <sinzui> katco, I am sorry https://bugs.launchpad.net/juju-core/+bug/1350011
[19:51] <_mup_> Bug #1350011: lxc deploys broken on precise <ci> <local-provider> <lxc> <precise> <regression> <juju-core:Triaged> <juju-core 1.20:Triaged> <https://launchpad.net/bugs/1350011>
[19:52] <jcw4> katco: a wizard?  I dont' know why I heard Morgan Freemans voice, even though it was Gandalf's face
[19:53] <natefinch> gandalf sounds right
[19:53] <natefinch> never late
[19:53] <natefinch> that's what it is
[19:53] <jcw4> that's it
[19:53] <katco> sinzui: i see from the error message that this contains the fix i put in last night. how would i tell that from the meta data?
[19:54] <sinzui> katco, which metadata? the jenkins tests?
[19:55] <katco> sinzui: well, from the launchpad bug. is there a way i would know that this was tested on the latest trunk?
[19:55] <sinzui> katco, no, since trunk changes many times a day
[19:55] <katco> sinzui: ah ok. how did you tell?
[19:56] <katco> sinzui: where the break occurred?
[19:56] <sinzui> katco, I forgot to include the links to the test and the specific runs, which include the branch and commit hashes
[19:56]  * sinzui adds them
[19:57] <katco> sinzui: ah ok. sorry, trying to generalize on how i would troubleshoot if the comments weren't so good.
[19:58] <sinzui> katco, on day I will have time to make reports.vapour.ws show all the interesting logs, artefacts, and results for each run against stable and devel
[19:59] <katco> sinzui: :)
[19:59] <natefinch> sinzui: what's up with the domain name vapour.ws anyway?
[20:00] <sinzui> natefinch, I could afford it :)
[20:00] <natefinch> sinzui: my guess was actually going to be "it was cheap"
[20:00] <sinzui> natefinch, clouds are made from vapour.
[20:01] <natefinch> ahh yes
[20:02] <perrito666> katco: machine tag is, in the case of machine 0 machine-0
[20:02] <katco> perrito666: ty, sir. jcw4 and i figured it out, but were unable to do anything useful once connected.
[20:02] <katco> perrito666: turns out my errors were due to running tests in parallel anyway.
[20:03] <ericsnow> what would be a better place to store JSON metadata for backup archives (themselves stored in env storage): state or env storage?
[20:03] <perrito666> katco: you need to do db.GetDatabase("juju") iirc
[20:07] <katco> sinzui: what's the easiest way to get a man page on that version of lxc-start?
[20:11] <katco> sinzui: nm got it
[20:12] <katco> this version of lxc-start doesn't have a --version tag. hm.
[20:13] <katco> * flag
[20:14] <katco> need an opinion here. would it be stupid to query dpkg for the version of lxc?
[20:18] <natefinch> yes
[20:18] <natefinch> but also might be the only way
[20:18] <natefinch> unless we can do one of those "if it doesn't have --version, then we know what version that is"
[20:19] <katco> natefinch: blech
[20:19] <katco> natefinch: why is querying dpkg bad?
[20:20] <natefinch> just adds a dependency.... it's not really that bad
[20:21] <katco> do we run on other nixes w/o dpkg?
[20:22] <katco> natefinch: ^^^
[20:23] <katco> natefinch: being that this is specifically for lxc
[20:25] <natefinch> back up a sec... why do we care about the version?
[20:25] <katco> natefinch: started with this  https://bugs.launchpad.net/juju-core/+bug/1348386
[20:25] <_mup_> Bug #1348386: lxc template fails to stop <clone> <lxc> <juju-core:Fix Committed by cox-katherine-e> <juju-core 1.20:Fix Committed by cox-katherine-e> <https://launchpad.net/bugs/1348386>
[20:26] <katco> natefinch: tanzanite had the idea to sniff the version to change what flag we use to pass a console-file
[20:27] <natefinch> how about trying -L and if it fails, try -c?
[20:28] <natefinch> and I agree with Tim, using the long flags in code is better than the short flags... less possibility for confusion
[20:28] <katco> that idea came up too. i think the downsides were: 1) there's no way to distinguish between -L not existing and something else going wrong, and 2) conditionals by error = bad
[20:29] <katco> natefinch: also, the long-names are different b/t versions as well
[20:30] <natefinch> I think conditionals by error = good a lot of the time.  Instead of guessing if something will work, just try it.
[20:30] <katco> natefinch: that is so expensive
[20:30] <natefinch> katco: right, but --console is much less likely to get reused as something else than -c
[20:30] <natefinch> katco: sometimes, and sometimes it's just the flag parser that'll bail early :)
[20:30] <katco> natefinch: ah, no what i meant is: what if the file isn't there, what if the shell couldn't fork a process
[20:31] <katco> natefinch: we don't know if it failed for that specific reason, or one in the set of all possible reasons
[20:31] <natefinch> katco: yes, it's true... due to the nature of command line applications, it's hard to determine if the error is the one we think it is
[20:31] <natefinch> katco: grep the help text? :)
[20:31] <katco> natefinch: exit codes are supposed to solve that
[20:31] <natefinch> katco: if anyone ever returned something other than 0 or 1 :)
[20:37] <katco> natefinch: https://yourlogicalfallacyis.com/bandwagon
[20:42] <natefinch> haha
[20:43] <ericsnow> natefinch: you have an opinion on my question about backup metadata?
[20:43] <katco> i love that webpage :)
[20:43] <perrito666> natefinch: review backup?
[20:43] <perrito666> :)\
[20:43] <katco> bringing in dpkg does seem heavy, maybe failing is the way to go here
[20:43] <katco> have to get wallyworld's opinion when he gets on
[20:44] <natefinch> ericsnow: putting the metadata in state is the whole point, isn't it?
[20:44] <ericsnow> natefinch: the names at least
[20:44] <ericsnow> natefinch: is there any advantage to storing the metadata in env storage?
[20:45] <natefinch> ericsnow: not really... env storage is just a place for blobs we don't want to burden the database with.... I think
[20:45] <ericsnow> natefinch: yeah, I guess that is my big question :)
[20:46] <natefinch> perrito666: I can review tomorrow, trying to get the windows nonce bug fixed... but there's tendrils of the code friggin everywhere
[20:55] <sinzui> katco, sorry, I was in a meeting. I have an precise lxc that I often use to lookup what precise uses.
[20:55] <katco> sinzui: no worries, thanks for getting back. i ended up downloading the deb and extracting the man page.
[20:55] <natefinch> I have a precise vm for that, too
[20:59] <katco> sinzui: so another question: did an official build go out w/ that change in place, or was someone just testing trunk?
[21:01] <sinzui> katco, every change to devel or stable is tested at juju-cu.vapour.ws. It does both integration testing, and unit testing against all supported architectures and series
[21:02] <katco> sinzui: ah ok. good to know that wasn't actively affecting anyone.
[21:02] <sinzui> katco, CI just saw the changes to 1.20 then master, ran the tests, and sent me email to investigate
[21:02] <katco> sinzui: very nice. glad our process caught this :) thank you for your efforts
[21:03] <thumper> alexisb: morning, got a few minutes?
[21:43] <wallyworld> katco: hiya, just read backscroll. well this sucks. i don't want to use dpkg because centos etc. imo best choice (out of a bad bunch) is to run --version and if that fails, we know version < 0.7 or whatever. we really do want to sniff the version and make a decision on that, cleanest approach. so all we're doing is tweaking the current implementation to makde the version detection more robust; all we care about is the binary choice
[21:43] <wallyworld> whether version > 0.8. a single call to lx-start --version gets us that knowledge even when that call fails because --version doesn't exist
[21:44] <katco> wallyworld: sounds good, almost ready for a review (i implemented the dpkg version first just in case)
[21:44] <wallyworld> sorry :-(
[21:44] <wallyworld> katco: also, is there an update on the backport of the api endpoints fic from master?
[21:44] <katco> wallyworld: no worries. that was the harder of the 2; wanted it ready in case you wanted to go that route. the failure version is easy
[21:45] <wallyworld> katco: do you agree with my reasoning?
[21:45] <katco> wallyworld: yes, https://github.com/juju/juju/pull/419
[21:45] <wallyworld> great thanks, looking
[21:45] <katco> wallyworld: yeah absolutely. i didn't know if we were on any non dpkg systems
[21:45] <wallyworld> not yet but real soon now
[21:45]  * katco cheers
[21:46] <waigani> morning all
[21:47] <wallyworld> katco: we may need to tweak it, did you see the extra emails in canonical-juju? seems we need to output the address as a list
[21:48] <wallyworld> katco: if you're at EOD, I can pick it up
[21:48] <waigani> menn0, when you have a mo, can we do a hangout?
[21:48] <katco> wallyworld: i still don't think i'm on canonical-juju :(
[21:48] <menn0> waigani: yep. give me a few minutes - I'm in the middle of something
[21:48] <wallyworld> katco: ah, bollocks, ok. i did ask. i'll follow up, sorry
[21:49] <waigani> menn0: all good. Just ping me.
[21:49] <wallyworld> katco: i forwarded the email
[21:49] <katco> wallyworld: err... only flaw in that proposal is that the absence of --version does not correlate with the change in -c to -L. e.g.: 1.0.0~alpha1-0ubuntu14.1~ubuntu12.04.1~juju1 does not have --version, but does have -L
[21:49] <katco> wallyworld: ty, sir
[21:50] <wallyworld> katco: ah, ok, i was assuming not having --version was an early version thing
[21:50] <katco> wallyworld: apparently not =/
[21:50] <katco> wallyworld: you may as well pick this up, i am at EOD and need to eat etc.
[21:50] <wallyworld> katco: so do we know if 1.0.0 alpha has an equivalent flag to --version?
[21:50] <wallyworld> sure
[21:50] <katco> wallyworld: no it does not. i'll post the man for easy reference
[21:51] <thumper> wallyworld: katco: lxc doesn't have a version
[21:51] <menn0> thumper: since I'm looking at bug 1349312 already should I assign it to me or would you prefer someone else looks at it?
[21:51] <_mup_> Bug #1349312: Machine stuck in "down" state because "an upgrade is in progress" <cloud-installer> <landscape> <juju-core:Triaged> <juju-core 1.20:Triaged> <https://launchpad.net/bugs/1349312>
[21:51] <wallyworld> wot
[21:51] <wallyworld> lxc-start --version
[21:51] <wallyworld> 1.0.4
[21:51] <thumper> wallyworld, katco: I was talking with hallyn about this, and the easiest thing for us to do would be to try with "--console-log" and if lxc errors with rc=1, try with "--console"
[21:51] <katco> wallyworld: i just emailed you the manpage from precise
[21:52] <wallyworld> thumper: out thinking was rc=1 sucks because that could be any error
[21:52] <thumper> could be
[21:52] <menn0> wallyworld: older versions didn't support --version
[21:53] <wallyworld> menn0: yes, but sadly it doesn't correspond to the switch to use -L which we were hoping for
[21:53] <wallyworld> thumper: also, if rc=1, does that guarantee that lxc-start hasn't actually start something
[21:53] <wallyworld> because i think the container is actually started
[21:54] <wallyworld> otherwise local provider would be totally broken
[21:54] <thumper> nah...
[21:54] <thumper> here is what is happening
[21:54] <wallyworld> so we can't just call it twice
[21:54] <thumper> we say: -c path/to/file
[21:54] <menn0> wallyworld, katco, thumper: I'm beginning to doubt myself about --version. It's not mentioned on the man page for the 1.0.4 but does work.
[21:54] <menn0> maybe it works for the older versions too but isn't documented
[21:54] <thumper> lxc goes, "that isn't a device, I'll ignore it"
[21:54] <thumper> and continues
[21:54] <thumper> that is different to say "--console-log=path/to/file"
[21:55] <thumper> as old lxc goes "I dunno what you mean there"
[21:55] <thumper> immediately
[21:55] <thumper> and doesn't try to start
[21:55] <wallyworld> ah, good
[21:55] <thumper> I tested that locally
[21:55] <wallyworld> thumper: and that would be the same for -L
[21:55] <thumper> yes
[21:55] <thumper> but please use long opts
[21:55] <thumper> I should have originally
[21:55] <wallyworld> ok
[21:56] <wallyworld> katco: sounds like we have our solution
[21:56] <katco> menn0: i did not test it empirically, but this error wouldn't have occurred if it was supported (unless it's some other error that is rc=1 per wallyworld's earlier comment)
[21:56] <katco> wallyworld: just try it 2x?
[21:56] <wallyworld> katco: yeah, try --console-log first
[21:56] <thumper> katco: I'd say "try with --console-log first"
[21:56] <thumper> and if that fails, just try with "--console"
[21:56] <wallyworld> and if rc=1, fallback to --console
[21:56] <katco> will do
[21:56] <thumper> wallyworld: good to see we agree
[21:56] <thumper> :)
[21:57] <wallyworld> yep :-)
[21:57] <wallyworld> thanks for clarifying
[21:57] <katco> wallyworld: thumper: the both of you are wrong! wrong i say!
[21:57] <wallyworld> :-P
[21:57] <thumper> I have another lxc based message coming to -dev soon
[21:57] <thumper> katco: wrong why?
[21:57] <katco> i hope that makes you two feel better ;)
[21:57] <katco> thumper: i'm just joking
[21:57] <thumper> ok
[21:57]  * katco has an odd sense of humor
[21:57] <thumper> I've already copped a lot of wrong this morning
[21:57] <wallyworld> katco: you need to eat - are you ok to fix the lxc thing or did you want to EOD?
[21:58] <menn0> but wait: has anyone tried --version with an older lxc-start
[21:58] <menn0> ?
[21:58] <wallyworld> thumper: i knew she was joking :-)
[21:58] <menn0> it might just work despite not being on the man page
[21:58] <katco> wallyworld: i can probably get this in rq... easy fix
[21:58] <thumper> menn0: I bet --version came in at a different time to --console-log
[21:58] <katco> wallyworld: actually... might take longer to push to launchpad lol. maybe you should do this to get it out
[21:58] <wallyworld> menn0: i think thumper is right
[21:58] <thumper> menn0: I don't know, but guessing
[21:58] <wallyworld> katco: ok
[21:58] <menn0> but if --version has always been there then we can just use that right?
[21:59]  * thumper looks in precise
[21:59] <wallyworld> katco: i've not heard anything from mgz about the flock stuff, have you?
[21:59] <katco> wallyworld: i have not
[21:59] <wallyworld> ok
[21:59] <katco> menn0: i did not test it empirically, but this error wouldn't have occurred if it was supported (unless it's some other error that is rc=1 per wallyworld's earlier comment)
[22:00] <katco> menn0: the --version flag i mean
[22:00] <katco> menn0: here is the entirity of the function that's failing: // Returns the lxc-start version
[22:00] <katco> func lxcStartVersion() (string, error) {
[22:00] <katco> 	version, err := exec.Command("lxc-start", "--version").Output()
[22:00] <katco> 	return string(version), err
[22:00] <katco> }
[22:01] <katco> ok have to EOD... wallyworld email if you need anything; i have my phone
[22:01] <wallyworld> np, thank you
[22:01] <katco> wallyworld: ty
[22:01] <thumper> so at least lxc in default precise (0.7.5) has no --version on lxc-start
[22:02] <wallyworld> thumper: since we can't conclusively correlate addition of version with support for console-log, seems easiest just to check rc value
[22:02]  * thumper nods
[22:02] <thumper> seems reasonable for now
[22:02] <menn0> wallyworld, thumper, katco: yep that sounds right
[22:02] <menn0> sorry for the noise
[22:03] <wallyworld> menn0: no problem at all, appreciate the input
[22:03] <menn0> better to check for the actual functionality
[22:03] <wallyworld> menn0: *if* --version were universally supported, we could have version sniffed
[22:04] <wallyworld> since we know the version where --console-log was introduced
[22:05] <menn0> now thumper what about bug 1349312? who do you want to own that? I've started looking at it but I'm pretty sure it's a dup of bug 1318366 which looks serious and horrible.
[22:05] <_mup_> Bug #1349312: Machine stuck in "down" state because "an upgrade is in progress" <cloud-installer> <landscape> <juju-core:Triaged> <juju-core 1.20:Triaged> <https://launchpad.net/bugs/1349312>
[22:05] <_mup_> Bug #1318366: jujud on state server panic misses transaction in queue <cloud-installer> <landscape> <orange-box> <panic> <performance> <sm15k> <juju-core:Triaged> <juju-core (Ubuntu):Triaged> <https://launchpad.net/bugs/1318366>
[22:05] <menn0> I'm happy to keep looking to make sure it's a dup (should know with 20 more minutes of investigation) and mark it as such.
[22:06] <wallyworld> menn0: thumper: can i assume you guys are focusing on working that bug to completion?
[22:06] <wallyworld> its critical we get 1.20 shipped
[22:07] <thumper> wallyworld: let me look first
[22:07] <wallyworld> ok, let me know
[22:07] <thumper> menn0: hangout to chat through this?
[22:07] <menn0> thumper: yep
[22:08] <menn0> waigani: will catch you after this hangout with thumper
[22:08] <waigani> menn0: no rush, I've ventured down another rabbit hole in the mean time...
[22:08] <thumper> menn0: https://plus.google.com/hangouts/_/gxnmnjsipg4yzjyqf5hat2iogqa?authuser=1&hl=en
[22:11] <perrito666> menn0: hey, have a sec
[22:11] <perrito666> ?
[22:12] <menn0> perrito666: otp
[22:14] <waigani> menn0: don't worry about catching up with me anymore
[22:15] <perrito666> wallyworld: I am supposed to tell you something as per what I talked to fwereade this afternoon but I forgot
[22:15] <wallyworld> perrito666: o/
[22:15] <wallyworld> \o/
[22:15] <perrito666> and I actually began taking notes whith a pen like the the red one here http://image.made-in-china.com/2f0j00ICetapBdaMuT/Finger-Pen-BKST08-.jpg which usually means I will remember
[22:15] <perrito666> it was something about envstorage
[22:16] <perrito666> and restore
[22:16] <ericsnow> perrito666: how to upload an archive into env storage?
[22:17] <perrito666> ericsnow: no, I pretty much figured that out
[22:17] <ericsnow> perrito666: oh, cool
[22:27] <waigani> thumper: hangout when you have a mo?
[22:29] <waigani> thumper: tests fail with this: http://pastebin.ubuntu.com/7898958/ because  provider/dummy/environs.go:711 says environ is not bootstrapped
[22:31] <waigani> thumper: even though we are calling environs.APIInfo() at the end on cmd/juju/bootstrap.go.Run
[22:32] <waigani> thumper: note that live testing works, this is just a problem with the dummy provider
[22:34] <waigani> thumper: so my question is, when does provider/dummy/environs.go.Bootstrap() get called? It needs to be executed before we can call environs.APIInfo()
[22:43] <bodie_> hey guys -- quick question.  can you point us in the right direction to demo a custom charm with some bits and pieces we've added?
[22:43] <bodie_> it should be as simple as adding a subdir and a couple of files
[23:01] <waigani> thumper, menn0 standup?
[23:01] <thumper> waigani: coming
[23:13] <jcw4> marcoceppi: is charm-tools on github the correct repo to get charm-tools from?
[23:14] <jcw4> marcoceppi: https://github.com/juju/charm-tools
[23:18] <alexisb> thumper, I am here now
[23:18] <alexisb> if you are available
[23:18] <thumper> alexisb: can we chat after the standup?
[23:18] <alexisb> sure
[23:18] <alexisb> ping me when you are done
[23:35] <marcoceppi> jcw4: no. Lp is the source
[23:35] <jcw4> marcoceppi: tx
[23:36] <marcoceppi> jcw4: I'll start mirroring again
[23:37] <waigani> davecheney: what is the 'race runtime'?
[23:41] <davecheney> waigani: http://blog.golang.org/race-detector
[23:41] <waigani> davecheney: cool, thanks
[23:57] <jcw4> marcoceppi: on a related note - https://github.com/juju/docs/pull/134