#juju-dev 2012-02-23
<fo0bar> ubuntulog test
<TheMue> rog: morning
<rog> TheMue: hiya!
<rog> TheMue: feeling better, i hope
<TheMue> rog: yep, yesterday already almost through with it, today feeling fine. thx.
<rog> TheMue: cool
<rog> TheMue: glad to hear it!
<TheMue> rog: already proposed the next charm changes also containing your _ wishes. ;)
<rog> TheMue: thanks
<rog> TheMue: saw that
<TheMue> rog: my pleasure
<TheMue> rog: btw, got another 'infect'.
<rog> TheMue: infect?
<TheMue> rog: during studies i've learned scheme, but now i' trying lisp. ;)
<rog> ah. CL?
<rog> SBCL is the one to use
<rog> baroque but interesting with it
<TheMue> rog: yep, choosen sbcl as a start.
<rog> TheMue: the hyperspec is the invaluable reference - i used it all the time
<TheMue> rog: and i want to play a bit with actors in lisp, found some docs and a lib.
<rog> TheMue: for your amusement, here was a little library i did in CL some time back: http://common-lisp.net/project/cl-xmlspam/
<TheMue> rog: ah <click>
<rog> TheMue: i ported russ's
<rog> oops
<rog> i ported russ's C channel communications code to CL too.
<rog> TheMue: never entirely satisfactory - it really needs lightweight threads, like Go.
<TheMue> rog: i'll see if i can do something like actors running based on thread pools
<wrtp> TheMue: so no first-class channels - sending messages to processes like in erlang?
<TheMue> wrtp: yep, more like that
<TheMue> wrtp: and like scala
<wrtp> TheMue: right.
<wrtp> TheMue: (i haven't looked at scala much)
<TheMue> wrtp: i only for a short article i wrote more than a year ago, not very deep
<wrtp> TheMue: the book to buy for getting into CL is "Practical Common Lisp", if you haven't already got it.
<TheMue> wrtp: i dislike all those langs based on the jvm, they tend to be too weak due to the (wished) interaction with the java libs.
<wrtp> TheMue: it's great. and doesn't try to hide the dubious bits
<wrtp> TheMue: yeah. same with .net languages
<wrtp> TheMue: i played with F# for a bit
<TheMue> wrtp: full ack
<TheMue> wrtp: i got "Land Of Lisp" for a review. but if the infect gets deeper i'll buy your book. ;)
<TheMue> wrtp: i only read about f#, but it looked interesting too
<TheMue> wrtp: and i still like erlang (used it for two years).
<wrtp> TheMue: it's a classic. and extremely useful for finding out how to get around the bizarre file path handling for example
<TheMue> wrtp: so, have to leave for a few minutes, banking. biab
<wrtp> TheMue: c u
<wrtp> something odd is going on with this machine: http://paste.ubuntu.com/853732/
<TheMue> back again
<wrtp> TheMue: are you seeing codereview.com being slow currently?
<TheMue> wrtp: no, today they have been fine. but had the too last week.
 * wrtp really doesn't like it when he makes lots of changes in response to a review... and then finds out they were made in the wrong branch.
<niemeyer> yo!
<wrtp> niemeyer: yoyo!
<wrtp> niemeyer: responses made to both reviews, BTW.
<wrtp> i hope you don't mind, i went for "k" rather than "pk" :-)
<niemeyer> wrtp: Thanks!
<niemeyer> wrtp: That's fine too
<wrtp> cool
<niemeyer> wrtp: Was just trying to make them consistent and distinct among themselves
<wrtp> niemeyer: yeah, thought so.
<wrtp> niemeyer: i like permKey BTW
<niemeyer> wrtp: Sweet
<TheMue> niemeyer: Already took a first look into https://codereview.appspot.com/5671055/?
<TheMue> niemeyer: hiya btw
<niemeyer> TheMue: Heya!
<niemeyer> TheMue: Not yet, but you're my first priority today.. I'll just finish a meeting with Dave Cheney, and will be in your reviews
<TheMue> niemeyer: great, thx
<TheMue> niemeyer: just for info, weekly update leeds to zookeeper compiling troubles
<TheMue> oh, wife calls for lunchtime
<TheMue> biab
<niemeyer> TheMue: The fix is already up for review
<niemeyer> TheMue: and you'll have to upgrade to Go tip as well
<niemeyer> TheMue: There's a bug in cgo itself that I fixed yesterday
<TheMue> niemeyer: ok, thix, will switch to tip
<wrtp> TheMue: actualy the fix is in weekly
<wrtp> TheMue: (the newest weekly)
<TheMue> wrtp: so tip should contin it too, shouldn't it?
<wrtp> TheMue: sure. but i think we generally use weekly if it works.
<TheMue> wrtp: hmm, if i recall it right, somebody named rog told me we use tip.
<TheMue> wrtp: ;)
<wrtp> TheMue: only occasionally, when things are broken with weekly :-)
<wrtp> TheMue: ...as was the case on that previous occasion
<TheMue> wrtp: thankfully an update-golang release|weekly|tip is enough for a full reinstall including the external packages
<wrtp> TheMue: yeah, the go tool makes things much much easier. bliss.
<wrtp> TheMue: i usually run all.bash though just in case the compilers have changed
<TheMue> wrtp: me too, but it's inside the script above, together with the go get's
<wrtp> TheMue: ah, it's your script. i though you just meant "hg update weekly"
<wrtp> TheMue: (which does work usually in fact)
<wrtp> s/though/thought/
<TheMue> wrtp: no, the script does the hg update, the all.bash and some clean go get
<TheMue> wrtp: i'm lazy, ol' admin. ;)
<TheMue> wrtp: doing something more than two, three times needs automation
<wrtp> TheMue: what's the go get for?
<wrtp> TheMue: to update to the required package versions?
<TheMue> wrtp: yep, I earlier had troubles that once fatched code is only recompiled, not fetched again after release changes
<wrtp> TheMue: yeah, i can see that. i don't usually have that problem though - i'll do get -u when a package stops working :-)
<TheMue> wrtp: is a go build of own sources now intelligent enough to do a go get on 3rd party packages?
<wrtp> TheMue: ... which makes it faster to switch versions.
<wrtp> TheMue: a "go get -u" you mean?
<TheMue> wrtp: yep, my script does a go get -u too
<wrtp> TheMue: i don't think it's possible for it to know if the appropriate version has changed.
<wrtp> TheMue: (of a given package, with respect to the current Go version, i mean)
<TheMue> wrtp: would be nice. "hey, i'm building with rel 1 and import 3rd party pkg a. let's check if it has the according rel, otherwise update it on the fly."
<wrtp> TheMue: i think if you do 'go get -u .' it should work
<wrtp> lunchtime
<TheMue> wrtp: yeah, it does, but you have to do it manually.
<TheMue> wrtp: inside of a go build it would be nice
<TheMue> wrtp: enjoy
<niemeyer> Okay
<niemeyer> TheMue: So, let me see your branch
 * niemeyer browses the review list
<TheMue> fwereade_: thx for the review, the other branch with your comment is in https://codereview.appspot.com/5690051/
<fwereade_> TheMue, thanks; but I'm not clear which order they're meant to be merged in
<fwereade_> TheMue, I'm sure I could figure it out but I'm lazy -- it would be good to set prereqs even if we don't yet get nice diffs out of it
<TheMue> fwereade_: while point 1 is related to the testing dir question what exact problem do you have with .. in path?
<fwereade_> TheMue, just that I'm suspicious that things will move :p
<TheMue> fwereade_: yeah, understand, would be nice if the order/dependency could be seen easily
<niemeyer> TheMue: Review sent
<TheMue> niemeyer: thx for review. you get a compiling error? which kind?
<niemeyer> TheMue: I don't think I said that
<TheMue> niemeyer: ok, than i misinterpreted a comment
<TheMue> niemeyer: so the state.Charm should implement the charm.Charm interface?
<niemeyer> TheMue: Yes, and I think it already does
<TheMue> niemeyer: hehe, maybe by accident
<TheMue> niemeyer: it's the first time in state we're implementing an external interface, so i wondered
<niemeyer> TheMue: Yeah, that's fine.. charm is kind of special in that we have several implementations of the interface
<niemeyer> We have another one in the store as well
<niemeyer> So 4 implementations right now
 * TheMue likes interfaces
<niemeyer> TheMue: I like _Go_ interfaces.. specifically.. :-)
<niemeyer> I've had not-so-great experiences before with other kinds of interfaces
<niemeyer> Zope interfaces comes to mind, for instance..
<TheMue> niemeyer: never played with zope
<niemeyer> I'll head to lunch, biab
<rogpeppe> network has been playing up all day
<rogpeppe> fwereade_: you gotta review
<fwereade_> rogpeppe, tyvm
<rogpeppe> fwereade_: you might not when you see all the comments!
<rogpeppe> fwereade_: looking good though, in general
<fwereade_> rogpeppe, heh, lots of comments beat just one saying "utterly hopeless; rejected, and shame on you" or equivalent :p
<rogpeppe> fwereade_: lol
<rog> right, i'm gonna reboot.
<rog> well, ubuntu boot is quick, but shutdown...
<fwereade_> rog, just a thought... if pstate were called pinfo, would you be happier about keeping path in there?
<rog> fwereade_: i don't see why you want path in there really. it just saves a parameter in two functions.
<rog> fwereade_: i'd be happier with a watcher type to gather together more params - i think things would look cleaner then.
<fwereade_> rog, I admit that I originally put it in there because I was getting annoyed about the number of params ;)
<fwereade_> rog, I'll experiment a bit
<rog> fwereade_: if you pass watcher by value, you won't even need to incur an allocation - it'll be exactly to equivalent to passing the values as arguments.
<fwereade_> rog, the tyvm holds, nice review
<fwereade_> rog, I'm not so sure about the loop/goroutine question though
<rog> fwereade_: no?
<rog> fwereade_: i don't see why you need to start a new goroutine each time through
<fwereade_> rog, forces are that (1) there are far more cases in which I want to break out of the loop than to continue looping, and (2) it seems to me that if I just recurse I'll eventually use an impolite amount of stack
<fwereade_> rog, (1) hence not-quite-right as a loop, (2) hence goroutine
<fwereade_> rog, sane or crackful? :p
<rog> fwereade_: one mo, i'll paste the kind of thing i'm thinking of
<rog> fwereade_: http://paste.ubuntu.com/854172/
<fwereade_> rog, that's basically what I had before I decided the loop was ugly (without the break loop, which doesn't feel to me like it really improves clarity)
<rog> fwereade_: yeah, it looks better without the loop label: http://paste.ubuntu.com/854177/
<rog> fwereade_: but i think the loop is good - you're wanting to loop, so why not use one?
<fwereade_> rog, hm, with for p.alive, that's definitely nicer
<rog> fwereade_: oops, needs a p.alive=false in the DELETED case
<fwereade_> rog, details details :)
<rog> :-)
<fwereade_> rog, what about awaitAlive though? the looping is definitely exceptional in that case
 * rog has a look
<fwereade_> rog, hm, still, for consistency's sake I might change that one anyway
<rog> fwereade_: i think you can use exactly the same structure to good effect: http://paste.ubuntu.com/854183/
<rog> fwereade_: they're both less lines of code, easier to read (IMHO) and more efficient... what's not to like? :-)
<fwereade_> rog, yeah, exactly, with the loop conditions they are much nicer
<fwereade_> rog, thanks :)
<rog> fwereade_: np. (writing this kind of code with channels is nice, ain't it?)
<fwereade_> rog, yeah, I'm really enjoying it :)
<rog> fwereade_: good. that's what we want to hear :-)
<rog> fwereade_: the main issue that probably needs discussion is whether unoccupying a node should delete it.
<fwereade_> rog, ah yeah, I meant to mention that
<rog> fwereade_: i'm tending towards the point of view that it shouldn't
<fwereade_> rog, the raciness you sadly note has nothing to do with node clearing
<fwereade_> rog, I don;t think it's sensible to assume that a presence node we want to watch will automatically exist
<rog> fwereade_: if you were guaranteed that node existed, then you could just do GetW - no need for the ExistW call
<fwereade_> rog, who says the Pinger even got started?
<rog> fwereade_: i think the node should be created before the Pinger is started.
<rog> fwereade_: so when some structure is created, a node is created for the watch node. and then a pinger and a watcher can rendezvous on it.
<fwereade_> rog, well, it is, first thing on pinger creation, before run (so we can get any errors out quickly and easily, if they're going to happen)
<fwereade_> rog, but... doesn't this just shuffle the raciness around?
<rog> fwereade_: yeah, but there's no error if a watcher is watching a bad path
<fwereade_> rog, who's responsible for creating that node?
<rog> fwereade_: i don't think so.
<rog> fwereade_: the state code.
<rog> fwereade_: so if you're an agent, you can do an ExistsW if you like to determine when some structure comes into place (same way we watch the init node), and then run a pinger or a watcher on a node within the structure
<rog> fwereade_: it's a slightly different approach i know, but i think it might make sense
<rog> fwereade_: one mo, i've got to go and help carmen turn over the contents of a compost bin. back in 5.
<fwereade_> rog, np, thinking
<niemeyer> fwereade_: Can't awaitDead and awaitAlive be a single loop?
<niemeyer> fwereade_: I don't have anything concrete yet, but my gut feeling about all those helper functions is that the problem itself shouldn't be so complex
<fwereade_> niemeyer, hm, maybe, rog's suggested changes might make me able to do that clearly
<niemeyer> fwereade_: I may be on crack.. so don't bother too much.. I'll do a more careful review on the logic once you're happy with it
<fwereade_> niemeyer, still worth a look
<fwereade_> niemeyer, cheers
<fwereade_> niemeyer, I'm not sure that'd work tbh -- the timeout in awaitDead wouldn't really play nicely with everything else
<fwereade_> niemeyer, or maybe I just can't see it :)
<niemeyer> fwereade_: How's that any different from the timeout on awaitAlive?
<fwereade_> niemeyer, what timeout?
<niemeyer> fwereade_: The same that exists on awaitDead.. why is there a timeout on one and not the other?
<fwereade_> niemeyer, the timeout is ony useful for detecting the case when updates have stopped
<niemeyer> fwereade_: Why?
<niemeyer> fwereade_: This isn't rhetorical, btw.. you may be right.. I'm brainstorming.
<fwereade_> niemeyer, there's no timeout on awaitAlive because we don't need to do anything weird to support getting back a create/change at somepoint in the future
<fwereade_> niemeyer, there's a timeout on awaitDead because that's the only way I could see to tell when a watch *hasn't* fired
<niemeyer> fwereade_: How do I wait for an agent to come live?
<fwereade_> niemeyer, ...call AliveW and wait for the channel to fire if it wasn't already alive?
<niemeyer> fwereade_: Ok, sorry, I misunderstood what you meant by timeout then
<fwereade_> niemeyer, ah, sorry :)
<rog> back
<rog> niemeyer: i'm thinking that all the logic becomes simpler if we assume that the node exists before starting.
<rog> niemeyer: so rather than deleting the node at the end, we'd just set it to empty
<niemeyer> rog: How can we assume it exists?
<fwereade_> rog, even if we did, who would delete the node in the end?
<rog> niemeyer, fwereade_: the node doesn't exist in isolation, surely? it's part of a larger zk structure that represents something, no?
<niemeyer> rog: Sorry, I'm out of context and don't know what you're trying to say
<niemeyer> rog: The node is within zookeeper.. it's not part of any structure
<rog> niemeyer: i'm talking about a directory structure within zk
<fwereade_> rog, I can see how it could work for machine nodes, but making it work for unit relation nodes is giving me a headache
<niemeyer> rog: The node is within zookeeper.. it's not part of anything else, as far as the presence package is concerned
<fwereade_> rog, and besides, I'd far prefer to make foo responsible for communicating foo's status without anyone else's help
<niemeyer> fwereade_: It shouldn't make a difference
<rog> niemeyer: that's fine. i'm just thinking that the initial waiting for the node to come into being can be done outside the presence package.
<fwereade_> niemeyer, it's not creation that makes my head hurt so much as it is deletion
<niemeyer> fwereade_: The presence node is context-less.. the package needs to know a path where it's supposed to exist, and it can assume that the parent exists, but nothing else.
<niemeyer> fwereade_: What's the issue with creation?
<fwereade_> niemeyer, there isn't one
<niemeyer> fwereade_: There isn't one what?
<fwereade_> niemeyer, an issue with creation
<niemeyer> <fwereade_> niemeyer, it's not creation that makes my head hurt so much as it is deletion
<niemeyer> fwereade_: Ah, I inverted the sentence
<rog> fwereade_: why's deletion an issue? deletion would mean the node becomes dead as now.
<niemeyer> fwereade_: You mean deletion is the problem.. what's the issue with deletion?
<rog> fwereade_: (for instance when the containing directory and its children is deleted)
<fwereade_> rog, niemeyer: who is responsible for it, and how do they arrange it with the unit agent, which may be behind schedule and have a bunch of other hook queued up before it can actually process a departure
<rog> fwereade_: responsible for what?
<fwereade_> rog, deleting the node
<fwereade_> rog, I presume we don't want to keep nodes around forever just because something once used it
<rog> fwereade_: the caller of the presence package. the idea is that responsibility for the node's creation and deletion is up to the caller.
<rog> fwereade_: the presence package would purely manage pings on an existing node.
<rog> fwereade_: i may be smoking more crack than usual, of course.
<niemeyer> fwereade_: You only have to worry about it in the sane cases.. e.g. if Kill() is called
<niemeyer> fwereade_: If there's a hard crash and the agent dies, there will be a bunch of trash around those nodes that has to be collected
<niemeyer> fwereade_: The original code is obviously unable to do with it, since it may have gone forever
<niemeyer> rog: The presence package should delete the node in the case where the call site is requesting the pinger to die in a way that notifies watchers
<fwereade_> niemeyer, ok, unstated assumption: without a good reason, the same thing should handle creation and deletion. sane?
<rog> fwereade_: yes
<TheMue> niemeyer: i've got no prob dropping readCharm() and let Service use State directly. but in this case to keep it consistent i would like to change all entities from getting the ZK conn from state now to getting the State itself.
<rog> niemeyer: i'd just set the contents to empty to do that
<niemeyer> rog: No reason, I believe.. removal is a pretty good way to flag it
<rog> niemeyer: rather than deleting the node.
<TheMue> niemeyer: so i would change it in Machine, Unit and the now comming new ones too
<fwereade_> rog, ok, but you're saying that (1) *something* unstated should create the node in the first place, and that other *something* should delete it at the end, and we shouldn't have a Kill (or at least not one that deletes the node)
<fwereade_> rog, what would that something be?
<niemeyer> TheMue: Yes, that's a good idea, but please do it in a follow up tiny branch that does just that
<niemeyer> TheMue: Rather than piling up the unrelated change
<rog> niemeyer: the nice thing about assuming that the node already exists is that you have some sanity check on whether it might ever change in the future, which we don't for a non-existent path.
<TheMue> niemeyer: ok, this will be only the first step with Charm
<TheMue> niemeyer: and Service ;)
<niemeyer> rog: I don't understand what's the advantage. I agree with fwereade_.
<niemeyer> rog: You seem to be saying that the nice thing about having someone else creating the node is that someone else has to do exactly the same logic that would otherwise be done inside the presence node, which to me makes no sense.
<fwereade_> rog, yeah, niemeyer put it better than I managed
<rog> i think i'm saying that other things know how to wait for existence (and that can imply other things too), but the pinger is the place that does keepalives.
<rog> but i don't mind too much. it was just an idea.
<niemeyer> rog: Still don't see what you mean.. the pinger is the thing that knows how to deal with a presence node to ping it, and that includes creation.
<niemeyer> fwereade_: Btw, let's call StartPing as StartPinger os StartPinging.. StartPing feels weird
<rog> niemeyer: it *can* include creation, but i don't think it has to.
<rog> niemeyer: NewPinger seems ok to me...
<niemeyer> rog: No, we can have a better interface as well and move things out of it
<niemeyer> rog: and then we have a pinger that doesn't know how to ping.
<niemeyer> fwereade_: Ok.. let's please have creation within the pinger.. there's no real argument that I can see to not do it.
<rog> fair enough
<fwereade_> niemeyer, I'm happy with that :)
<niemeyer> fwereade_: And StartPinger, please..
<fwereade_> niemeyer, possible convention counterargument: time.NewTimer, time.NewTicker
<rog> fwereade_: given that this is the presence package, i was just wondering if the "p" prefix is useful in pstate? just type state might be fine. and it makes the capitalisation less awkward.
<niemeyer> fwereade_: Let's please use Start.. New lacks the idea that this is going to be alive doing something rather than just creating an object
<rog> niemeyer: NewTicker??
<niemeyer> rog: I didn't name this one
<fwereade_> niemeyer, fair enough
<rog> niemeyer: it's seems a fine precedent to me, but there y'go. lots of New* functions create active things.
<niemeyer> rog: I'm comfortable enough to improve existing conventions
<jimbaker> hazmat, g+ mtg?
<rog> niemeyer: i really don't think that's a great improvement. it's easier to remember when things stick to existing conventions.
<niemeyer> rog: Sorry, let's move on
<fwereade_> rog, I'm about to poke at pstate with a view to possible removal anyway :)
<rog> do we have to use StartX for anything that invokes a goroutine?
<rog> sorry, i'll stop
<niemeyer> rog: When the next case shows up, we'll talk.
<hazmat> jimbaker, sounds good
<jimbaker>  hazmat, cool, just invite jim.baker@canonical.com
<hazmat> hmm.. invites out
<hazmat> niemeyer, fwereade_, rog meeting time?
<niemeyer> hazmat: Already joining
<fwereade_> hazmat, noone here, I'll try again
<wrtp> total failure
<wrtp> niemeyer: i'm back online (on my apple, cos my laptop seems to have forgotten it can connect to a wireless network) and the hangout is full
<wrtp> niemeyer, fwereade_, TheMue: so i guess you can tell me what went on :-)
<niemeyer> wrtp: Oops :(
<wrtp> niemeyer: i've no idea what's up with the laptop. it keeps on asking me for passwords (it should have them stored in the keyring) and doesn't connect anyway
<wrtp> niemeyer: it's been funny all day in fact. rebooting didn't help.
<wrtp> anyone got a handy hint for diagnosing ubuntu wireless connectivity problems?
<Aram> you use network manager?
<rog> it seems to be working again, woo
 * robbiew had to bail
<hazmat> niemeyer, fwiw.. no bugs i can see log of hooks/scheduler.py http://pastebin.ubuntu.com/854310/
<niemeyer> hazmat: http://paste.ubuntu.com/854315/
<niemeyer> 111 looks like a fix
<niemeyer> 127 too
<niemeyer> 157 too
<hazmat> niemeyer, what's that a log of?
<niemeyer> hazmat: juju/hooks/
<hazmat> niemeyer, that's quite a bit more than the scheduler we where speaking of
<niemeyer> hazmat: If you touch just scheduler.py, you won't get anywhere close to cleaning things up in the way I was talking about
<niemeyer> hazmat: scheduler.py is a very particular interface that only makes sense with everything else in there
<niemeyer> 202 is a fix too
<niemeyer> 286 also
<niemeyer> 312, 315, and 451..
<niemeyer> Yeah.. all of that is a side effect of a new code base being polished.. change the code base significantly, and these may not show up again, but others will..
<rog> right guys, i'm off now
<rog> see ya tomorrow!
<niemeyer> rog: Have a good evening
<rog> niemeyer: and you
<niemeyer> Cheers
<hazmat> niemeyer, its clear we where talking about two different things, risk from a change, vs rewriting an implementation
<niemeyer> hazmat: risk from (...) rewriting an implementation
<niemeyer> hazmat: This is a gut suggestion.. I wouldn't rewrite one of the trickiest parts of an application that is working two months before a release that is supposed to be rock solid
<niemeyer> hazmat: Your take
<TheMue> back again
<hazmat> niemeyer, its not clear you have the context on the problem or the solution that's under consideration.. your just pointing out an entire package of code, saying its had so many fixes and its tricky, be careful and don't touch it, while your saying how a rewrite will simplify things.  yes change is a risk for stability, and in some cases not fixing a bug is the right call, but this is a fairly straight small forward change... and the change as i exampled i
<hazmat> s to a part of the code that has been fine since day one... effectively its fixing a bug in a completely different package by adding a feature to the correct place.
<niemeyer> hazmat: We're talking across each other indeed..
<niemeyer> hazmat: In the call, I pointed out what I'd like to do in Go, and you said it might be doable in Python too. I said it was a significant change for this point in time. That's what I'm talking about still.
<niemeyer> hazmat: I'm not suggesting you don't fix a bug.
<niemeyer> hazmat: In fact, I don't think I ever said anything close to "not fixing a bug is the right call".
<niemeyer> In this context, of course.. in some cases it is the right call, surely.
<hazmat> niemeyer, yeah.. i'm not considering rewriting that package, just fixing the bug.. the only rewrite at this point that's worth considering is the relation ephermal node watches via  a backport of the pinger
<niemeyer> hazmat: Phew.. we agree, after all :)
<TheMue> niemeyer_: when can i expect the zookeeper fix? or is it just again a tag problem?
<niemeyer_> TheMue: Tip is fixing, and the branch just has to be merged
<niemeyer_> TheMue: I can do that right after the current meeting
<TheMue> niemeyer_: great, thx
<niemeyer_> TheMue: Submitting
<TheMue> niemeyer_: wonderful, appreciate it
<niemeyer_> TheMue: Done
<niemeyer_> I'm heading out for some exercising.. probably back later
#juju-dev 2012-02-24
<TheMue> re
<niemeyer> Good morning all!
<TheMue> niemeyer: hiya
<fwereade__> heya niemeyer, you're on early :)
<niemeyer> fwereade__: Yeah, a bit :)
 * rog finally makes his network connection work again
<niemeyer> rog: Welcome back
<rog> niemeyer: hi!
<rog> niemeyer: you're up earlier than usual...
<TheMue> rog: hiya
<rog> TheMue: morning!
<niemeyer> rog: Yeah, a bit
<rog> niemeyer: any chance you could have another look at those CLs? i'm hoping to get something pushed this week.
<niemeyer> rog: Not right now
<rog> niemeyer: k
<fwereade__> niemeyer, btw, there was a conversation the other day I think you missed about gozk panicing in C when a Conn is closed (and something else is busy in C code)
<niemeyer> fwereade__: Ugh, that's not good
<fwereade__> niemeyer, would fixing this just be a matter of a RWMutex on handle accesses, or is it more subtle?
<niemeyer> fwereade__: Well.. I'd need some more information about the crash
<fwereade__> niemeyer, I've seen it in a couple of cases, but the common feature is that some goroutine is always somewhere like: launchpad.net/gozk/zookeeper._C2func_zoo_wexists(0x36edf80, 0x36ef380)
<niemeyer> fwereade__: Ok, do you have a full traceback?
<fwereade__> niemeyer, here's the one I just saw
<rog> niemeyer: i had a brief look at this - it just happens when zk derefs the nil handle, because handle access isn't mutexed, as fwereade__ suggestes
<fwereade__> niemeyer, http://paste.ubuntu.com/855178/
<rog> suggests
<fwereade__> niemeyer, the set line shouldn't be the problem, because that conn is not closed
<niemeyer> fwereade__: Is this looping while you're calling Close on the zk Conn?
<fwereade__> niemeyer, yes
<niemeyer> fwereade__: That's going back to the point we talked about
<niemeyer> fwereade__: We shouldn't do that
<niemeyer> fwereade__: We shouldn't ever close a connection behind the back of logic that we're managing ourselves
<fwereade__> niemeyer, ok, maybe I'm missing something
<niemeyer> fwereade__: That's true for tests, and also for real logic
<niemeyer> fwereade__: We can even implement locking to prevent the nil pointer reference at some point, but that's not the most critical issue
<niemeyer> fwereade__: Ok, but do you recall that conversation?
<fwereade__> niemeyer, ok, in that case I guess the tests I was trying to write are not actually relevant, because I'm really trying to test deal-with-session-event handling that doesn't exist yet
<niemeyer> Feb 22 12:09:11 <niemeyer>      fwereade_: We should never, ever, ever, leave background logic unattended while we're messing around with the  system state in disruptive ways
<niemeyer> fwereade__: Hmm, can you expand on that?
<fwereade__> niemeyer, yes, I do; the reason I saw this one just now is because all I *thought* I had active on that conn was a watch
<fwereade__> niemeyer, I was trying to verify that the watch channel got closed when the underlying ZK connection got yanked out from underneath
<niemeyer> fwereade__: Ok, that's an interesting case.. maybe we have something to fix then
<niemeyer> fwereade__: Can you please paste waitFor?
<fwereade__> niemeyer, http://paste.ubuntu.com/855189/
<niemeyer> fwereade__: Sorry, I thought that was where the loop was.. TestDisconnectAliveWatch then, I guess
<niemeyer> Ah, this is the guy blowing up: launchpad.net/gozk/zookeeper._C2func_zoo_set2(0x0, 0x36ef360)
<fwereade__> niemeyer, yep
<niemeyer> fwereade__: Please paste the test and (*Pinger).run
<fwereade__> niemeyer, before I paste this: I know the stuff in the goroutine comment is wrong :p
<fwereade__> niemeyer,
<fwereade__> http://paste.ubuntu.com/855193/
<niemeyer> fwereade__: Cool :)
<fwereade__> niemeyer, http://paste.ubuntu.com/855195/
<fwereade__> niemeyer, wait, you're right, it is set and not exists, bugger, I'm at least partially on crack (in a way that I was not hitherto aware of)
<niemeyer> fwereade__: You know it's wrong in which way?
<fwereade__> niemeyer, "this should be equivalent"
<fwereade__> niemeyer, ie, what we should actually be doing is *not* just closing the conn until we've dealt with everything
<fwereade__> niemeyer, but if it is indeed the set that's blowing up, anmd it looks like it is, then I'm completely confused because that's using a different conn to the one that gets closed
<niemeyer> fwereade__: Not really
<niemeyer> fwereade__: Oh, wait.. yes
<fwereade__> niemeyer, so I would appear to be crackful in an entirely fascinating and original way :/
<niemeyer> fwereade__: But!
<niemeyer> fwereade__: Please paste Close
<niemeyer> fwereade__: I bet you have a race
<fwereade__> niemeyer, oh balls, I try to hit the target node again
<fwereade__> niemeyer, (to give clients as long a time as possible before they see a timeout)
<fwereade__> niemeyer, (naively trusting that if the connection is borked it'll just error and I can ignore it)
<niemeyer> fwereade__: That's fine
<niemeyer> fwereade__: But a race is not fine.. please paste Close
<TheMue> Interesting, http://cocode.io/beta/ will provide collaborative coding. It's written in Go knows Go as a highlighted lang. Sadly yet only GitHub, no Bazaar (or others).
<niemeyer> <niemeyer> fwereade_: That's fine
<niemeyer> <niemeyer> fwereade_: But a race is not fine.. please paste Close
<niemeyer> fwereade_, fwereade__: Are you having wifi issues too?
<niemeyer> fwereade_, fwereade__, fwereade: Are you having wifi issues too? :-)
<fwereade> niemeyer, seems so :p
<fwereade> niemeyer, http://paste.ubuntu.com/855206/
<fwereade> niemeyer, if you didn't see above
<niemeyer> fwereade_, fwereade__, fwereade: I always knew you were not a single person..
<niemeyer> fwereade: Yeah, you have a race indeed
<niemeyer> fwereade: Can you please have a look at this post: http://blog.labix.org/2011/10/09/death-of-goroutines-under-control
<fwereade> niemeyer, I'm a globally distributed collection of outsourced drones, but don't tell anyone
<niemeyer> fwereade: I'll highlight a few things afterwards, if they're not obvious
<fwereade> niemeyer, cool, thanks
 * fwereade reads
<rog> niemeyer: where's the race?
<fwereade> niemeyer, I remember reading that when you wrote it, and totally forgot about it until now
<fwereade> niemeyer, it seems clear, but I'd appreciate the highlighting all the same
<rog> oh yeah, in TestDisconnectAliveWatch. i was looking in the pinger methods
<fwereade_> grar
<niemeyer> fwereade_: Are you here? :)
<fwereade_> niemeyer, er, probably
<niemeyer> fwereade_: Ok :)
<niemeyer> fwereade_: So, quicklY! :-)
<niemeyer> fwereade_: Observe the way Stop is implemented in the blog post
<niemeyer> fwereade_: It sends a fatal error, and *waits*
<TheMue> niemeyer: next round of https://codereview.appspot.com/5671055/
<niemeyer> TheMue: Thanks, I'll have a look at that next to rog's
<TheMue> niemeyer: yep, thx
<niemeyer> fwereade_: You're sending a stop signal, and ignoring the fact that, naturally, stopping isn't instantaneous
<fwereade_> niemeyer, yeah; I had a "closed" channel I was waiting on originally, but it was pointed out that since closing was unbuffered I wasn't getting any benefit from waiting on closed after sending to closing
<niemeyer> fwereade_: Uh.. this is bogus
<niemeyer> fwereade_: Oh, or maybe not.. let me see again
<rog> niemeyer: it looked ok to me :-)
<fwereade_> niemeyer, I'm not saying there weren't subtle bugs in what I was doing, or in what I am doing ;)
<rog> niemeyer: i *hope* it's not bogus otherwise my understanding of channels is fundamentally flawed...
<niemeyer> rog: No, you're right.. as long it's unbuffered, that's fine
<rog> phew
<niemeyer> fwereade_: The race is in the test itself
<rog> yup
<niemeyer> fwereade_: No, sorry.. crack again..
<niemeyer> altConn is in a different end
<niemeyer> Hmm
<rog> niemeyer: isn't is a race that waitFor(c, altConn, path) is called concurrently with altConn.Close() ?
<rog> (not that i've looked at waitFor)
<niemeyer> rog: No.. the pinger is blowing up with a nil handle
<niemeyer> Despite anything else, there's a race here in that the handle is being cleaned up underneath its feet
<rog> niemeyer: that still looks like a race to me
<niemeyer> rog: :-)
<rog> niemeyer: even if it's not the thing that's blowing up
<niemeyer> rog: If the logic in the test is sane, the Close won't happen before the kill
<niemeyer> rog: if..
<rog> niemeyer: oh yes, i hadn't seen connect - i was assuming that the session event was the connection event, not the teardown event.
<rog> but presumably connect waits for the first session event
<fwereade_> rog, yes
<niemeyer> rog: That's what I'm assuming too
<rog> fwereade_: how reproducible is this?
<fwereade_> rog, not very :(
<fwereade_> rog, it'll happen eventually
<rog> fwereade_, niemeyer: AliveW is busy on altConn at the same time that altConn is closed, right?
<rog> so that looks like a race to me
<fwereade_> rog, yes; so that Close could happen at any time, and that's definitely a problem
<rog> i.e. the server gets killed, the goroutine receives the session event and closes altConn, at the same time AliveW happens to do a Change
<fwereade_> rog, there are similar tests that really are *only* watching when the conn gets closed, and they're fine; yes
<niemeyer> rog: If that's the case, then the connection is being Closed before kill()
<rog> niemeyer: i don't think so
<rog> niemeyer: the kill happens, then the close happens, then AliveW does something
<niemeyer> rog: AliveW is run before kill..
<rog> niemeyer: AliveW has a goroutine
<fwereade_> niemeyer, I guess it's not impossible that there's another session event confusing me
<niemeyer> rog: OH, does it?
<niemeyer> Why?
<niemeyer> To transform the event, I guess
<rog> niemeyer: yup
<niemeyer> But it should be listening only
<niemeyer> On a channel.. that's not supposed to blow up
<niemeyer> fwereade_: Can you please paste the whole file, or just push the branch?
<rog> yeah
<fwereade_> niemeyer, sure
<fwereade_> niemeyer, ~fwereade/juju/go-presence-nodes
<fwereade_> niemeyer, when we're watching for aliveness we can't just dumbly watch a channel
<fwereade_> niemeyer, we need to keep rewatching when we get changes before timeouts
<niemeyer> fwereade_: Ho ho ho
<fwereade_> niemeyer, technically, above, when we're watching for *deadness*
<fwereade_> niemeyer, have I misunderstood something fundamental?
<niemeyer> fwereade_: I'm just curious about the rewatching.. that may explain it
<fwereade_> niemeyer, (also we may need to rewatch when waiting for liveness too, it's a bit of an edge case, but...)
<niemeyer> fwereade_: Yeah, there's a race there..
<niemeyer> fwereade_: You're firing goroutines that use zk in a way that closing the connection will ignore completely
<fwereade_> niemeyer, huh, I thought that closing the conn would close all the watches, and I'd see that
<rog> niemeyer: i don't think there's a way to do it without either having a way to Close an AliveW or by making zk.Close concurrent-safe
<rog> niemeyer: personally, i think i'd opt for the latter
<rog> niemeyer: (after all, all the other routines are ok to call concurrently)
<rog> s/routines/zk methods/
<niemeyer> rog: Yes, there may be something to change in gozk, but there's something to be handled in presence itself that I'm trying to understand
<rog> niemeyer: presence seems ok to me, but i'm probably missing something
<niemeyer> fwereade_: Why do we need awaitDead and awaitAlive to loop?
<fwereade_> niemeyer, awaitDead to refresh the data watch until I get a timeout without the data watch having fired
<niemeyer> fwereade_: Ah, right.. it's the opposite.. it fires when it doesn't get a watch
<niemeyer> Hmm
<fwereade_> niemeyer, awaitAlive to handle the case where a known-unresponsive node is deleted -- it's still dead but not in the same way and IMO I shouldn't really alert the client to say "yeah, nothing changed"
<niemeyer> Well, looks like we need our Watcher type back..
<rog> niemeyer: if zk Close was concurrent-safe, everything would be fine
<niemeyer> So that we can stop this logic in a sane way
<rog> niemeyer: just like closing a net.Conn
<rog> niemeyer: then the logic just stops as a matter of course
<niemeyer> rog: What do you mean by concurrency safe?
<rog> niemeyer: i mean that you could Close a zk conn concurrently with executing some other operation on the conn
<fwereade_> niemeyer, it feels like one of the advantages of gozk is that the watches can just get auto-closed, and it would be really nice if we could follow the same convention here
<fwereade_> rog, nitpick, technically it's all the other methods that aren't concurrent-safe ;)
<niemeyer> rog: That's not enough
<rog> fwereade_: they're concurrent-safe with each other...
<rog> niemeyer: no?
<niemeyer> fwereade_: Exactly
<niemeyer> rog: What fwereade_ said
<rog> niemeyer: i don't understand. wouldn't a mutex around the handle access be acceptable?
<fwereade_> niemeyer, it still seems to me that a RWMutex on handle around C calls would be enough; what am I missing?
<rog> niemeyer: (every method would have to respect it, of course)
<niemeyer> rog: This is something else, not what you originally said
<rog> niemeyer: that's what is necessary to make it ok to call Close concurrently, AFAICS
<rog> niemeyer: which is what i was suggesting
<niemeyer> rog: You're still missing the point..
<fwereade_> niemeyer, so am I I think
<niemeyer> rog: It's not just about concurrency
 * rog usually does
<niemeyer> rog: Close(); Set(foo).. BOOM!
<rog> niemeyer: no.
<rog> niemeyer: not if Set checks to see if handle is nil and then returns an error
<niemeyer> rog: Dude.. please make up your mind
<fwereade_> niemeyer, wouldn't we just grab a read lock, check for nil, and error back cleanly?
<rog> fwereade_: exactly
<niemeyer> fwereade_: YES!
<niemeyer> fwereade_: We'd just do that.. that's not what was being said so far!
<fwereade_> niemeyer, ha, I thought it was
<niemeyer> <niemeyer> rog: What do you mean by concurrency safe?
<niemeyer> <rog> niemeyer: i mean that you could Close a zk conn concurrently with executing some other operation on the conn
<rog> niemeyer: i just said "make Close concurrent-safe". that doesn't imply that Close is the only method that needs to change.
<niemeyer> rog: This is not about concurrency! Serial operations blow up!
<rog> niemeyer: well, that's a different (although related) issue.
<fwereade_> niemeyer, Close might block for a while (or *possibly for ever if enough is going on...) but that seems preferable to unrecoverable panics in C if if a hamfisted amateur like myself is trying to use the library
<niemeyer> rog: Yes, it's the issue we're seeing
<rog> niemeyer: i think we're seeing an issue because of concurrency, no?
<niemeyer> <niemeyer> rog: This is not about concurrency! Serial operations blow up!
<rog> niemeyer: is that the case in this example? i thought we were doing things in two separate goroutines
<niemeyer> <niemeyer> rog: This is not about concurrency! Serial operations blow up!
<niemeyer> rog: You can inline.. Close(); Set(); BOM!
<fwereade_> rog, niemeyer: sorry, lamb chops are hot on the table, back shortly :)
<rog> niemeyer: that's not what's happening in this issue though, right?
<niemeyer> rog: Yes, it is
<rog> niemeyer: in the same goroutine?
<niemeyer> rog: No.. the fact there are two goroutines is completely irrelevant
<rog> niemeyer: to my mind, it's not. if we were in a single goroutine it would be easy to avoid doing an operation after Close.
<rog> niemeyer: it's the concurrency issue that makes it harder
<niemeyer> rog: Sorry, but a "concurrency issue" is something else than what you have in mind
<rog> niemeyer: ok, fair enough
<rog> niemeyer: so...
<niemeyer> rog: You can put a lock across every single function in gozk, and it will still blow up
<rog> niemeyer: only if they don't check that handle is not nil before calling into C, no?
<niemeyer> rog: Yes, and that's not a concurrency issue.. this is about using a connection after it's been closed.
<niemeyer> rog: and make that not panic
<rog> niemeyer: agreed. but just doing that won't fix our problem either.
<rog> niemeyer: because then there would be a race.
<niemeyer> rog: Sure, because you can't trust on the test for the handle to be valid without a lock
<rog> niemeyer: exactly
<niemeyer> fwereade_: So..
<rog> niemeyer: i think a RWMutex would probably do the job just fine
<rog> on zk.Conn, that is
<niemeyer> fwereade_: You're right, we must definitely fix gozk itself so that we protect from that kind of issue
<niemeyer> fwereade_: I'm just still wondering if we should change the interface for that
<niemeyer> fwereade_: I guess it's fine to keep it running it in background, and simply error out, given that this is purely a read operation without any side effects
<rog> niemeyer: that was my thought.
<niemeyer> fwereade_: Btw, I'd prefer to not have the  (s state) as a parameter to the await functions
<niemeyer> fwereade_: There's actually a bug in that regard in the current logic
<niemeyer> fwereade_: No, there isn't, sorry
<niemeyer> fwereade_: You're passing the parameter as a copy, which is safe
<niemeyer> fwereade_: Still, I don't see why the parameter is necessary
<rog> niemeyer: it saves passing the path and timeout parameters as separate arguments
<rog> niemeyer: but i'm with you
<niemeyer> rog: Yeah, I think the organization there needs some tweaking for clarification
<rog> niemeyer: i wondered if things might be clearer if there was an internal watcher type which held the params that are being passed around.
<niemeyer> rog: I was wondering about that too, but this is makes it seem like there wouldn't be much benefit compared to what is there now:
<niemeyer>                                 s, zkWatch, err = newStateW(conn, s.path)
<rog> niemeyer: s, err := w.getStateW() ?
<niemeyer> rog: The only bit that is actually constant is the path
<rog> yeah
<niemeyer> rog: Right, w is the path..
<niemeyer> rog: Which renders fwereade_ design elegant
<rog> it was the other methods i was really thinking about (waitAlive and waitDead)
<niemeyer> rog: Right.. as methods, they would have to live on a type that is simply the path
<niemeyer> rog: Because timeout and aliveness changes
<rog> niemeyer: that's fine. they can still be fields in the waiter type. it will change when they change.
<rog> niemeyer: (it's not used concurrently)
<niemeyer> rog: There's no point in having them as fields.. it's only used in that one function
<rog> maybe "node" might be a better name for the type
<niemeyer> rog: Yeah, path :)
<niemeyer> rog: type node string, where node is the path
<niemeyer> rog: That won't improve much what fwereade_ has there now, though. The design feels sound on that level
 * rog is thinking about it
<niemeyer> rog: Well.. I guess we could have the connection on it too
<niemeyer> Which would make it more interesting
<rog> niemeyer: yeah
<niemeyer> type node string
<rog> niemeyer: and the watch channel to send to
<niemeyer> func (n node) readState() (alive, timeout, error)
<niemeyer> func (n node) readStateW() (alive, timeout, watch, error)
<rog> func (n node) get() error
<rog> sorry
<rog> func (n *node) get() error
<niemeyer> func (n node) awaitAlive
<niemeyer> func (n node) awaitDead
<rog> func (n *node) getW() error
<niemeyer> rog: What's get?
<niemeyer> rog: get error? :)
<rog> niemeyer: gets the current state of the node. stores it in n.
<rog> niemeyer: getW also gets a wait channel and stores that in n too.
<niemeyer> rog: That's a bad name then.. update() maybe
<rog> sure
<niemeyer> and updateW()
<niemeyer> rog: Yeah, that should improve things indeed, +1
<rog> cool
 * fwereade_ reads back...
<niemeyer> rog, fwereade_: So.. I'd just like to take an eagles view on the whole issue to close it down, if that's ok
<niemeyer> We have one bug, and one design approach we're agreeing that breaks a prior rule
 * rog feels those sharp eyes on him from far far above.
<niemeyer> :)
<niemeyer> The bug is, as we discussed at length, the fact closing and using a connection is a blow up in gozk for sure. We must fix that.
<niemeyer> The design decision is a more subtle one
<niemeyer> The prior goal I was personally attempting to ensure is that we never have background logic under our control running in parallel with other stuff that will break down the concurrently executing logic
<niemeyer> Under that design approach, we'd need a Stop() method on the watcher
<niemeyer> So that we can stop it.. that would avoid the gozk bug too
<niemeyer> But, we're agreeing to not do that, and instead fix gozk, and establish a new condition:
<niemeyer> If the background logic is entirely innocuous, it's fine to allow it to die a cold death
<rog> sounds good to me. as long as the logic *will* die, and not be left around as garbage
<fwereade_> niemeyer, that sounds sensible to me personally, but then I would say that
<niemeyer> AliveW is one example of that.. by itself, it's doing nothing. If it blows up in the background, there are zero side effects, _as long as the logic that is using the watch does nothing_!!
<fwereade_> niemeyer, this feels consistent with every other ZK watch
<niemeyer> It's _NOT_ ok to have someone waiting on the watch resulting from AliveW, and doing further actions like changing the FS or whatever else, despite the fact the connection has been closed
<rog> and the logic using the watch will just see a close on the channel, which means an error, so hopefully this kind of logic can cascade
<niemeyer> fwereade_: Agreed
<fwereade_> niemeyer, excellent
<rog> fwereade_: agreed
<niemeyer> rog: No, that's exactly what we don't want
<niemeyer> rog: We'd have to reevaluate the use of the watch, if it's also in background
<rog> niemeyer: no? i'm imagining some other innocuous logic layered on top of AliveW
<niemeyer> rog: For it to be alright, it'd have to be innocuous too
<rog> niemeyer: yes, definitely
<niemeyer> rog: Cool, we're in agreement then
<rog> yup
<niemeyer> So, those are the relevant decisions
<niemeyer> Glad we're in agreement, phew :)
<niemeyer> fwereade_: In addition to that, we were nitpicking over the interface around the state type
<niemeyer> fwereade_: Which is not terribly important, but that might be interesting to sort out if you still have the energy
<fwereade_> niemeyer, I saw that and I'm not strongly invested in what I currently have; the fields seemed to go well together, and to stop the function signatures breaking lines, and so I decided it was good :)
<niemeyer> fwereade_: rog was suggesting a node type, which feels nice to clarify the state handling
<niemeyer> fwereade_: Something like this is the status quo of the discussion:
<niemeyer> type node struct { conn, path, timeout, alive }
<niemeyer> func (node) update() error
<niemeyer> func (node) updateW() (watch, error)
<rog> *node
<niemeyer> Sorry, yes
<niemeyer> func (*node) waitAlive()
<niemeyer> func (*node) waitDead()
<niemeyer> (the last two with the necessary return types and parameters)
<fwereade_> niemeyer, LGTM
<fwereade_> thanks guys, productive discussion :-)
<niemeyer> fwereade_: waitAlive and waitDead would be implemented on top of the former two
<niemeyer> fwereade_: Likewise!
<rog> i keep on wondering if waitAlive and waitDead might not be better named as deadWait and liveWait respectively
<rog> i.e. name them after the state they start in rather than the state they're waiting for.
<rog> dunno
<niemeyer> rog: -1.. these are nouns
<niemeyer> we need verbs
<rog> yeah
<rog> i want to call waitDead waitDeath
<rog> but can't think of an appropriate name for the other one
<fwereade_> rog, I considered similar but "waitBirth" wasn't right
<fwereade_> rog, indeed
<niemeyer> waitAlive and waitDead feels great to me
<rog> yeah
<niemeyer> And on that node, I'll do some reviews..
<rog> that's fine. just thought i'd mention it in case others has similar thoughts.
<fwereade_> niemeyer, would you like me to take a look at gozk as well?
<niemeyer> Actually, let me finish answering emails first
<fwereade_> niemeyer, I don't want to overload you :)
<rog> i could do gozk
<niemeyer> fwereade_: Yes, please
<niemeyer> or rog.. whatever works
<rog> or fwereade_ sure
<rog> i'm a bit ahead of myself anyway currently
 * fwereade_ bows out gracefully
<rog> fwereade_: how about you refactor presence (again!) and i'll do zk.
<fwereade_> rog, give me a shout if it becomes a hassle in any way and I can grab it
<fwereade_> rog, but that sounds good to me
 * rog thinks is shouldn't be too much problem.
<rog> s/is/it/
<andrewsmedina> niemeyer: hi
<niemeyer> andrewsmedina: Hey
<rog> fwereade_, niemeyer: ok, zk changes made. now for the harder bit... the testing.
<fwereade_> rog, good luck :)
 * rog thinks of a devious way of forcing a zk request to take a long time.
<andrewsmedina> niemeyer: in the last weekly version Go isn't  work with two packages in same project
<andrewsmedina> andrewsmedina: in some of your projects you put a example.go which is a different package.
<fwereade_> rog, just a thought; I have a couple of `switch event.Type`s without defaults; if I get totally unexpected events, it would probably be sensible to `close(watch)`, right?
<rog> fwereade_: you could probably panic
<rog> fwereade_: it's part of the contract that the correct event types should be returned
<rog> fwereade_: if they're not, then something's very broken
<rog> the contract with zk, that is
<fwereade_> rog, in that case I think explicitly panicking may be excessively defensive
<rog> fwereade_: i'd prefer to see a panic rather than a silent failure in that case
<fwereade_> rog, ok, just `panic(event)` then?
<rog> fwereade_: panic(fmt.Errorf("unexpected event %v", event))
<rog> or something like that
<fwereade_> rog, ok then :)
<rog> it's nice to see the thing that caused the panic
<fwereade_> rog, sounds good
<fwereade_> rog, hm, I guess I can lose the forward() stuff once we have a Close-safe gozk
<rog> fwereade_: yeah. that'll be good.
<rog> fwereade_: i could push a version that you could use until i've done the tests, if you like.
<fwereade_> rog, a good thing but also sort of a shame, that stuff made me very happy :)
<fwereade_> rog, I guess that would be useful
<rog> fwereade_: it's still there for when you need it again...
<rog> fwereade_: in fact i think i might be using that technique in the zk tests... (my "devious way")
<fwereade_> rog, indeed, the pleasure of deleting code still outweighs the pleasure I took in the code to begin with
<fwereade_> rog, nice :)
<rog> fwereade_: i'm gonna have a forwarder and stop all incoming traffic. then i know that the reply can't come back quickly...
<rog> fwereade_: in fact i might steal your code directly, since it's still there...
<fwereade_> rog, go for it :)
<TheMue> So, solved a merging prob, 76 tests passed
<rog> TheMue: nice
<TheMue> rog: yeah, it goes on, piece by piece
<rog> TheMue: i bet you're glad you speeded up the tests now :-)
<TheMue> rog: definitely
<TheMue> rog: when zk is cold (first start) about 11 sec, then about 6.3 sec.
<rog> TheMue: how long if you run just one test?
<TheMue> not yet tested
<fwereade_> rog, TheMue, IME live-zookeeper tests have a 5s overhead
<fwereade_> (when hot)
<rog> so about 1.3 seconds to run the tests. that's not bad
<rog> TheMue: try go gotest -gocheck.run patternMatchingOneTest :-)
<TheMue> rog: with a lot i/o
<rog> oh, i think it might be gocheck.f actually
<fwereade_> rog, it is
<rog> fwereade_: i'm going to change that soon - it should be the same as the equivalent test option
<rog> fwereade_: i just haven't pushed the change yet
<rog> well, the merge request
<fwereade_> rog, fine with me; I'll discover it, swear, check the options and be happy :)
<TheMue> rog: a single test is 5.11 vc 6.36 for all tests
<rog> ain't java wonderful?
<TheMue> fwereade_: your guess with 5 sec seems good
<TheMue> rog: haha
<fwereade_> niemeyer, should ExpectFailure (gocheck) possibly output something in test runs? as it is, its "don't forget this test exists" value seems a touch limited
<niemeyer> fwereade_: The purpose is precisely to not forget that there are broken tests without having a failure that we'll learn to ignore
<fwereade_> niemeyer, agree that ignored-by-convention failures are poisonous; I just don't see how it stops us forgetting any better than renaming the methods to DontTest* would
<niemeyer> fwereade_: It mentions that there are expected failures at the end of the run, doesn't it?
<fwereade_> niemeyer, perhaps I'm Doing It Wrong, but not afaics
<fwereade_> william@diz:~/code/go/src/launchpad.net/juju/go$ go test launchpad.net/juju/go/state/presence
<fwereade_> ok  	launchpad.net/juju/go/state/presence	5.890s
<niemeyer> Hmm
<niemeyer> fwereade_: Run it without the package name
<niemeyer> fwereade_: Within the directory
<niemeyer> fwereade_: Or with -v
<niemeyer> fwereade_: go test is eating the output
<fwereade_> niemeyer, no dice either way
<fwereade_> niemeyer, ah, somehow run it without using "go test"?
<niemeyer> No
<niemeyer> fwereade_: There's something wrng indeed
<fwereade_> niemeyer, it's not critical, shall I just open a bug?
<fwereade_> niemeyer, (srry, I feel bad distracting you all the time while the store's still in progress)
<niemeyer> fwereade_: No worries really
<niemeyer> fwereade_: I haven't even managed to get to that yet
<fwereade_> niemeyer, heh, that's a large part of why I feel bad about it ;)
<niemeyer> fwereade_: Yes, please file a bug.. it's supposed to print it
<niemeyer> Hey cliff-hm
<niemeyer> cliff-hm: How're things going in the RedHat side of the world?
<cliff-hm> Pretty OK thanks. :)
<cliff-hm> Just trying to understand and play with Juju a bit to see how it fits itself together.
<niemeyer> cliff-hm: Nice, please let us know what you think
<cliff-hm> (I prefer not to hide away) :)
<cliff-hm> Sure
<cliff-hm> I may try to do that contest, not sure yet.
<cliff-hm> (In my spare, non-company time)
<niemeyer> cliff-hm: That'd be great
<niemeyer> cliff-hm: When can we expect juju to be integrated into RedHat's products? :)
<niemeyer> rog: Can you please sort out this branch so we can take it out of the review list: https://code.launchpad.net/~rogpeppe/juju/fix-tutorial-with-expose-2/+merge/75379
<rog> niemeyer: jeeze, i thought i did that months ago :-)
<niemeyer> rog: and this one too: https://codereview.appspot.com/5674051/
<rog> niemeyer: TheMue wanted to do something different there, so i was thinking of abandoning it
<niemeyer> rog: That's a fine solution, but we need to reject it so that that it goes out of the review list
<rog> niemeyer: ok. i'll reject it.
<niemeyer> rog: Thanks
<cliff-hm> niemeyer, I don't know ;) I'm doing this on personal time ... out of my own interests.
<niemeyer> cliff-hm: Ah, understood. I thought it was related to you being a managed of the Spacewalk/Satellite/RHN/etc team
<niemeyer> cliff-hm: Please drop us a note if you have any suggestions then
<cliff-hm> My interests stem from that background, yes. But I'm not under company orders to spy and look at what others do :) My day job is too busy for those tasks.
<cliff-hm> And yeap. I will try to give feedback. Though likely to have more questions :)
<cliff-hm> (been reading so far, hoping tonight and weekend to stay hands-on)
<niemeyer> cliff-hm: Sweet
<niemeyer> cliff-hm: I have good friends at RH, btw..
<rog> niemeyer: both rejected - the earlier was submitted in some other form sometime.
<niemeyer> cliff-hm: Probably not very close to you, though
<cliff-hm> we have a lot of employees now. I know a bunch of people in my time here, but there is a lot more people that I do not know, than know.
<niemeyer> cliff-hm: Can imagine.. most of the people I know are around kernel development, I believe
<niemeyer> Rietveld cross-changes diffing is such a huuuge aid
<niemeyer> cliff-hm: Do you work close to the Openshift guys?
<niemeyer> Suddenly rietveld is crawling
<niemeyer> Which makes this a good time to have lunch
<niemeyer> rog: I did manage to LGTM one of hte pending branches, though
<rog> niemeyer: magic, thanks
<niemeyer> Will finish pending reviews when I'm back, and then will step out to do store work
<cliff-hm> I know several, but not close with them. Closer to the Aoelous and Katello, pulp project guys.
<rog> niemeyer, fwereade_: https://codereview.appspot.com/5694068/
<rog> probably the most significant one yet.
<rog> fwereade_: if you wanna have a look, probably the best place to start is in util.go, which has the basic robustness primitive.
<rog> fwereade__: just checking: did you see my CL above?
<rog> fwereade__: or is your network playing up?
<rog> hmm, can anyone see this?
<niemeyer> It's funny that every time Mark starts a rant in canonical-tech, there's a bunch of people asking to subscribe to the list
<rog> niemeyer: i hadn't looked at that list recently
<fwereade__> rog, sorry, I keep not seeing notifications
<rog> fwereade__: that's fine. this is what i said:
<fwereade__> rog, I did, and thank you for the advice to start looking in util, would have been a little mystifying otherwise ;)
<rog> 15:18] <rog> niemeyer, fwereade_: https://codereview.appspot.com/5694068/
<rog> [15:18] <rog> probably the most significant one yet.
<rog> [15:19] <rog> fwereade_: if you wanna have a look, probably the best place to start is in util.go, which has the basic robustness primitive.
<rog> fwereade__: np
<niemeyer> rog: Yeah, I'm on reviews
<rog> niemeyer: brill!
<niemeyer> Man.. why is codereview *so slow*
<niemeyer> rog: "there's deliberately only one securityGroup instance for each security group."
<niemeyer> rog: Where's that enforced?
<rog> niemeyer: there's only one occurrence of "&securityGroup" in the file, which is in newSecurityGroup, which is only called when group() has returned nil
<rog> niemeyer: actually, i think the newSecurityGroup call in NewInstances (even though it conforms to that rule) might be ananachronism
<rog> an anachronism
<niemeyer> rog: There are two different calls to newSecurityGroup
<rog> niemeyer: they're both called only when group() has returned nil
<rog> niemeyer: i.e. they never create a group with the same contents twice
<rog> niemeyer: but see above too
<rog> i think the occurrence in NewInstances might be from before i implemented CreateSecurityGroup
<niemeyer> rog: Still, this is a problem.. the current design is error prone, and there's a design not documented anywhere and scattered across the code
<rog> niemeyer: if i deleted it from NewInstances (which i think i probably should) then it would not be scattered.
<niemeyer> rog: It would still not be documented, and it would still be error prone
<niemeyer> rog: All it takes is a single line: &securityGroup{}.. BOOM, bug.
<rog> niemeyer: so you don't like comparing pointers?
<rog> niemeyer: or are you asking for a comment?
<niemeyer> rog: I like comparing pointers.. I don't like error prone code that will break behind our back in hard to notice ways
<niemeyer> rog: I'm asking to make the code not error prone
<niemeyer> rog: I don't want to remind everybody that touches that file that they can't create security groups
<rog> niemeyer: if i put a comment next to the securityGroup type saying "only create this through newSecurityGroup", would that be ok?
<rog> niemeyer: (and have newSecurityGroup do the check)
<niemeyer> rog: The comment + the latter sounds good
<rog> niemeyer: cool, will do.
<niemeyer> rog: This will prevent people from making silly but reasonable mistakes, I hope
<niemeyer> rog: Thanks, and sorry for the trouble
<rog> niemeyer: np. it was worth it to find the bug in NewInstances
<rog> well, not precisely a bug
<niemeyer> rog: Please also add a short note in the permKey struct, next to the pointer definition
<fwereade__> EOD, and I'm exhausted :). happy weekends all!
<niemeyer> rog: Nice comments, btw, thanks
<niemeyer> fwereade__: have a good time man :)
<rog> fwereade__: happy weekend to you to
<rog> o
<rog> niemeyer: something like this?
<rog> // permKey represents permission for a given security
<rog> // group or IP address (but not both) to access a given range of
<rog> // ports. Equality of permKeys is used in the implementation of
<rog> // permission sets, relying on the uniqueness of securityGroup
<rog> // instances.
<niemeyer> rog: Sounds great, thanks
<rog> niemeyer: cool.
<rog> with those changes, does it LGTY?
<rog> niemeyer: here's the other comment, BTW:
<rog> // securityGroup holds a simulated ec2 security group.
<rog> // Instances of securityGroup should only be created through
<rog> // Server.newSecurityGroup to ensure that groups can be
<rog> // compared by pointer value.
<rog> niemeyer: PTAL
<niemeyer> rog: // It returns nil if a security group with the given name already exists.
<niemeyer> rog: Feels like a trap
<rog> niemeyer: really?
<rog> niemeyer: do you want it to return an error?
<rog> niemeyer: i considered that, but i haven't got an error type yet
<rog> niemeyer: and the caller needs to call fatalf with an appropriate error code
<rog> niemeyer: i could just delete the newSecurityGroup function
<niemeyer> rog: Yeah, an error sounds good.. or make it panic internally and delegate the responsibility of checking to the call site
<rog> niemeyer: what about my last suggestion?
<rog> niemeyer: just inline it inside CreateSecurityGroup
<niemeyer> rog: The abstraction is fine.. just make it panic internally if the group already exists
<niemeyer> rog: We just want to make the error visible rather than a hidden issue
<rog> niemeyer: it won't be hidden for long... anything that tries to use the returned group will panic.
<rog> niemeyer: but ok
<niemeyer> rog: Not really. Returning a nil group means people could get away with setting a permKey.group to it, for instance.
<rog> given that it's only called in one place, i don't really see why the creation needs its own function.
<niemeyer> rog: Sure, inline then..
<rog> something in me slightly balks at doing two linear searches of the group list... (i know that's a ridiculous concern, too!)
<niemeyer> rog: Keep a comment about the problem, please
<rog> niemeyer: will do
<rog> niemeyer: done.
<rog> weird
<rog> my irc client appears to have logged me in twice
<rog> ah! that must've been carmen opening my laptop
<rog> niemeyer, TheMue: i'm off now. have a good weekend.
<niemeyer> rog: LGTM.. thanks
<TheMue> rohave a good weekend too
<niemeyer> rog: Have a good weekend
<rog> niemeyer: thanks for the reviews.
<rog> niemeyer: always nice to finish with a submit. thanks.
<niemeyer> rog: Indeed! :-)
<niemeyer> rog: and np
#juju-dev 2013-02-18
<davecheney> var m = make(map[string]int)
<davecheney> type T struct { name string }
 * thumper is beginning to want proper inheritance in go...
 * thumper sighs
 * thumper has another thought...
<thumper> gah, must finish something before starting another
 * thumper puts head down again
<thumper> davecheney: by splitting out the SetFlags from the Init, a bunch of tests are failing...
<thumper> davecheney: as they are testing Init
<thumper> davecheney: is there a place where we put helper test functions?
<thumper> davecheney: for example, jujud/agent_test.go has a method called initCmd
<thumper> which creates some flags, and calls init
<thumper> I added the setflags to it, and I'd like to make the function more generally useful in other tests
 * thumper guesses davecheney is at lunch
<davecheney> thumper: generally suite_test.go is a good start
<davecheney> but i think you have to leiway to create your own tradition
<thumper> whoever thought that "c *C" were good params for tests should be given a very stern look
 * thumper jumps through hoops
 * thumper wonders if 1000 lines of diff are enough for first change to juju
<davecheney> thumper: i'd say most things are up for grabs if you are prepared to argue your case
<thumper> hmm...
<thumper> davecheney: are there dependencies between the juju-core packages that I have to make sure I don't screw up?
<davecheney> thumper: not sure i parsed that correctly
<thumper> davecheney: there are tests lying around...
<thumper> davecheney: and I want to put some common command test helper methods into juju-core/testing
<davecheney> kk
<thumper> which would add a depencency on juju-core/cmd
<thumper> which I don't think is there yet
<thumper> likely to be fine?
<davecheney> sure
<thumper> kk
<davecheney> I'm sure there is alreayd a dep between cmd/juju and cmd
<davecheney> thumper: go list -f '{{ .Imports }}' launchpad.net/juju-core/cmd/juju
<davecheney> ^ direct imports of cmd/juju
<davecheney> go list -f '{{ .Deps }}' launchpad.net/juju-core/cmd/juj
<davecheney> ^ all transitive deps
<thumper> ah...
<thumper> handy
<thumper> I may try that shortly
<thumper> holy shit
<wallyworld_> thumper: you got your rietveld account all set up for your mp?
<thumper> realised that my tollerance for duplication in tests is way below some others
<thumper> wallyworld_: no
<wallyworld_> thumper: it's not just tests - i'm finding Go to be very verbose
<thumper> wallyworld_: this isn't go
<thumper> it is just code
<wallyworld_> yeah agreed, it's also elsewhere
<thumper> davecheney: umm... if I Ctrl-C the tests while running, have I left things behind that might cause further tests to hang?
<davecheney> thumper: in theory no
<davecheney> in practice
<davecheney> yes, you'll eventyualy leak enough mongo processes to run out of swap
<davecheney> if you put /tmpfs on swap, then you ahve to be doubly careful
<davecheney> as each mongo will write 200mb of journal files on startup
<thumper> hmm...
<thumper> ok, something to watch for then :)
<thumper> I'm almost at the state of making all these tests pass again...
<davecheney> neat
<thumper> hmm...
<thumper> $ bzr diff | wc -l
<thumper> 1467
<thumper> although, not quite that bad:  58 files changed, 223 insertions(+), 188 deletions(-)
<thumper> and much of that is duplicated
<thumper> ok, I hear the kids home
<thumper> tests are running, pretty confident
<thumper> tomorrow lets get this reviewed and landed
<thumper> night all
<davecheney> night
<davecheney> got a branch ?
<thumper> work  up at  lp:~thumper/juju-core/command-set-flags if you are curious
 * thumper signs off
<davecheney> kk
<thumper> and all tests passed \o/
<wallyworld_> davecheney: hi, thanks for finding that data race. what tool did you use?
<TheMue> Morning
<dimitern> TheMue: morning!
<fwereade> dimitern, TheMue, heyhey
<dimitern> fwereade: hiya
<TheMue> fwereade, dimitern: Hi
<fwereade> dimitern, TheMue: fwiw I have a few constraints branches from last night up
<dimitern> fwereade: yeah, already on these
<fwereade> dimitern, you rock
<fwereade> TheMue, you have a trivial LGTM on the deletes branch
<TheMue> fwereade: Yep, thx, just doing the final merging and test.
<rogpeppe> mornin' all
<TheMue> rogpeppe: Hiya
<rogpeppe> TheMue: yo!
<dimitern> rogpeppe: morning
<rogpeppe> dimitern: hi!
<dimitern> fwereade: you've got 2 reviews
<fwereade> dimitern, tyvm
<fwereade> rogpeppe, ping
<rogpeppe> fwereade: pong
<fwereade> rogpeppe, last weekend, I had a thought related to the api
<rogpeppe> fwereade: ok
<fwereade> rogpeppe, would you agree that the following is a valid perspective: a machine agent can be defined to be trusted, or not, dependent on whether it has a state.Info and can hence connect directly to mongo
<fwereade> rogpeppe, and that we thus always require that at least one trusted machine exists
<rogpeppe> fwereade: given that the state.Info contains a valid password, yeah
<fwereade> rogpeppe, because we need it to run the API server, through which untrusted machine/unit agents will connect
<rogpeppe> fwereade: yup
<rogpeppe> fwereade: there must always be at least one API server running
<fwereade> rogpeppe, ok, so, if we keep the Provisioner and Firewaller just as they are, and only allow them to run on trusted machines -- against a state.Conn, I think you get to cut down the API surface quite pleasingly (and not need to even *touch* the code for the pro/fw)
<rogpeppe> fwereade: hmm, i'm not sure
<fwereade> rogpeppe, that way we don't even expose an EnvironConfig API call that returns the user's credentials
<rogpeppe> fwereade: how does a trusted machine get the credentials in the first place?
<fwereade> rogpeppe, however it does as it is? sorry, I'm not sure of the impact, can you expand?
<fwereade> rogpeppe, machine 0 would have it magically; subsequent machine agents that need to run trusted tasks would, I presume, get the state info published to them
<rogpeppe> fwereade: i'd envisaged that we'd be able to repurpose an existing machine to run any job
<fwereade> rogpeppe, I had a vague feeling that was in line with the approx plans?
<fwereade> rogpeppe, yeah, I think we still can
<rogpeppe> fwereade: so how do we publish the state info to an existing machine?
<fwereade> rogpeppe, you had the plans for a Publisher of API info, right? why not analogously for state info, but with more restrictions in the API?
<rogpeppe> fwereade: sure. but surely the place to publish it is in the state, no?
<fwereade> rogpeppe, yeah, via the API... right?
<rogpeppe> fwereade: bingo
<rogpeppe> [10:40:12] <fwereade> rogpeppe, that way we don't even expose an EnvironConfig API call that returns the user's credentials
<fwereade> rogpeppe, ok, but the attack surface is limited to that one call... much like Login
<rogpeppe> fwereade: ah, no i see
<fwereade> rogpeppe, and I *think* the savings form not having to implement the API bits that are only used by trusted workers will be handy
<rogpeppe> fwereade: yeah, i think that certainly for an interim period, your suggestion is good
<fwereade> rogpeppe, yeah, we can evaluate how well it works :)
<rogpeppe> fwereade: rather than having an EnvironConfig call, we have a MongoStateInfo call (or something) which gives untrammelled access to the underlying state
<fwereade> rogpeppe, btw, ISTM that the tools param to Environ.StartInstance is used very rarely indeed
<fwereade> rogpeppe, yeah, exactly
<fwereade> rogpeppe, that information feels like the stuff we also have to give to a machine running another Stater to connect them all up
<rogpeppe> fwereade: i'm not sure long term though
<rogpeppe> fwereade: having direct access to the state feels a bit like granting root access
<fwereade> rogpeppe, don't worry, I'm not laying down cathedral plans ;)
<fwereade> rogpeppe, sure, agreed
<rogpeppe> fwereade: and actually neither provisioner or firewaller need that level of access
<rogpeppe> fwereade: only the API server does
<fwereade> rogpeppe, agreed -- I am not laying down cathedral plans
<rogpeppe> fwereade: ok
<fwereade> rogpeppe, I'm suggesting that it's a good interim goal because it looks like the quickest way to get all our code running with *a* security boundary in place
<rogpeppe> fwereade: the only difficulty is that the logic in the machiner becomes more complex
<rogpeppe> fwereade: but that's probably a reasonable tradeoff
<fwereade> rogpeppe, it feels tolerable, yeah
<rogpeppe> fwereade: yeah, it looks like we could get rid of the tools arg to StartInstance without losing anything significant
<rogpeppe> fwereade: trivial CL: https://codereview.appspot.com/7317050
<fwereade> rogpeppe, well, I think the tools interact very closely, I'm still trying to figure out the right way to go
<rogpeppe> fwereade: i managed to reproduce that mongodb "--format provided but not defined error" BTW. i'm not entirely sure which command is drawing that error, hence my trivial CL above.
<rogpeppe> fwereade: that's the bug i found w.r.t. the mongodb charm, BTW
<fwereade> rogpeppe, LGTM trivial
<rogpeppe> fwereade: thank
<fwereade> rogpeppe, but it's not reliably reproducible?
<rogpeppe> s
<rogpeppe> fwereade: yeah, it is
<fwereade> rogpeppe, ah, fantastic
<rogpeppe> fwereade: it just takes a while to do it
<fwereade> rogpeppe, heh
<fwereade> rogpeppe, I'm thinking of --upload-tools, which I think at the moment just uses version.Current, which is probably right (given an absence of cross-compiling)
<rogpeppe> fwereade: it can't do anything else, yeah
<fwereade> rogpeppe, in which case we have to check that the series and arch of the image/instance we start actually match what we're uploading
<rogpeppe> fwereade: hmm, i have to think about that a bit
<rogpeppe> fwereade: currently upload-tools is just an argument to bootstrap
<rogpeppe> fwereade: and there's nothing stopping you from provisioning more instances that don't use the originally uploaded tools
<fwereade> rogpeppe, yeah, and vice versa
<fwereade> rogpeppe, ok then, cool
<rogpeppe> fwereade: i'm not sure what you mean by "vice versa" there actually.
<rogpeppe> fwereade: you can't upload tools later
<fwereade> rogpeppe, we *just* upload the tools we can, and the user is responsible for starting instances on which they will actually run
<fwereade> rogpeppe, oh, I thought upgrade-juju could do that?
<rogpeppe> fwereade: oh yeah, so it does!
<fwereade> rogpeppe, :D
<rogpeppe> [11:16:00] <fwereade> rogpeppe, we *just* upload the tools we can, and the user is responsible for starting instances on which they will actually run
<rogpeppe> +1
<fwereade> rogpeppe, ok, sweet
<fwereade> rogpeppe, I am also eyeing environs.FindTools
<fwereade> rogpeppe, I am suspecting that it should somehow give me a list of available tools matching certain criteria (filter on series and arches, I think)
<rogpeppe> fwereade: yeah. the significant issue around this is that currently we choose what tools an instance will run before we actually ask the provider to start the instance
<fwereade> rogpeppe, that is I think ok
<rogpeppe> fwereade: but if the provider itself can decide on an architecture, for example, then that might be a problem
<rogpeppe> fwereade: perhaps FindTools should take a Constraints as an argument?
<rogpeppe> [11:20:10] <rogpeppe> fwereade: perhaps FindTools should take a Constraints as an argument?
<rogpeppe> although series isn't really a constraint
<fwereade> rogpeppe, perhaps -- yeah, I'm eyeing (series string, cons Constraints) args
<fwereade> rogpeppe, that said... it would be *really* convenient if Series was a constraint
<rogpeppe> fwereade: yeah, and... why shouldn't it be?
<fwereade> rogpeppe, because it's not something amenable to direct control like the others
<fwereade> rogpeppe, the series is determined by the service's charm, which itself may be determined by the environ's default-series
<rogpeppe> fwereade: isn't it actually in a way *more* amenable to direct control (we can start different series on a given piece of hardware)
<fwereade> rogpeppe, from the juju level, it is -- juju deploy cs:precise/foobar -- bam, there's precise
<fwereade> rogpeppe, and there's the distinct setting of constraints, in which series does not play a part
<rogpeppe> fwereade: i'm not intrinsicaly opposed to the idea that a charm might influence the constraints of the machine that's started to deploy it
<fwereade> rogpeppe, it *must*
<fwereade> rogpeppe, precise charms run on precise
<fwereade> rogpeppe, quantal charms run on quantal
<fwereade> rogpeppe, etc
<rogpeppe> fwereade: ok, so how can the series *not* be part of the constraints?
<rogpeppe> fwereade: BTW how does getting a list of available tools from FindTools help you?
<fwereade> rogpeppe, it is not entirely clear that the internal representation of a Constraints should *necessarily* carry with it the series information which is specified in a different way and could I think be inferred where necessary
<rogpeppe> fwereade: all constraints are optional, no? so there's no "necessary" there.
<fwereade> rogpeppe, series is not optional
<fwereade> rogpeppe, which is another way in which it is different to the other constraints
<rogpeppe> fwereade: no constraint is optional when the machine is actually instantiated :-)
<fwereade> rogpeppe, that's information about a running instance, which we do want to match against constraints in future; but they are not themselves constraints
<fwereade> rogpeppe, they represent a solution to the constraints, if you like
<rogpeppe> fwereade: yeah, and the form of the solution might look exactly like a Constraint :-)
<fwereade> rogpeppe, they do indeed look very similar
<fwereade> rogpeppe, but actually not exactly the same :)
<rogpeppe> fwereade: anyway, i'm not sure i see the advantage to passing the series around as an extra parameter to the constraints.
<rogpeppe> rather, a parameter extra to the constraints
<rogpeppe> fwereade: and i definitely see simplicity advantages to including it with the constraints
<fwereade> rogpeppe, I'm not sure the case is overwhelming either way, is all; it could easily be stored on state.Machine when a unit is assigned -- you always have a series, because the unit has a service has a charm -- as well as the service having constraints
<rogpeppe> fwereade: in fact, if series was part of the constraints, we perhaps wouldn't need default-series
<fwereade> rogpeppe, I don't think it's the same thing, quite
<rogpeppe> fwereade: because it could be specified by the environment's series constraint.
<fwereade> rogpeppe, that's where the default would come from -- but then you override that constraint in a different and magical way when you deploy, and you can't even set it from the UI
<rogpeppe> fwereade: i'm not sure it's "magical" - every charm comes with an implied series constraint.
<rogpeppe> fwereade: maybe you would want some special case code to prevent you setting a service's series constraint to something other than the charm's series though.
<fwereade> rogpeppe, I am weighing up the costs and benefits of that special casing
<fwereade> rogpeppe, I don;t feel entirely in favour of it: I think that doing that in the python was a bit of a mistake
<rogpeppe> fwereade: but tbh, "series" doesn't seem like something that should be so special. it's special now because everything's ubuntu-only.
<fwereade> rogpeppe, I don;t suppose you know if there's a wiki page for the sprint yet?
<rogpeppe> fwereade: not afaik
 * rogpeppe must book flights
<fwereade> rogpeppe, it's gonna be very special one day, I just hope it can bear the load that's put on its shoulders
<fwereade> rogpeppe, it's in charms, it's in juju, and it's our one way of specifying a target os
<rogpeppe> fwereade: i could see it becoming a (os, os-version) tuple
<fwereade> rogpeppe, indeed it might
<rogpeppe> fwereade: but maybe that's just a compound name
<fwereade> rogpeppe, plausibly
<dimitern> anyone seen mramm ?
<rogpeppe> fwereade: i'd prefer it to be two attributes as part of the constraints though,
<fwereade> dimitern, we can all dogpile him when he gets on :)
<dimitern> fwereade: :D sure
<rogpeppe> fwereade: to put it another way, what *wouldn't* work well (or be more complex) if series was part of the constraints?
<fwereade> rogpeppe, environ-level series constraints would be weird -- they'd work a bit like default-series and a bit like the other constraints
<rogpeppe> fwereade: say we took default-series to be just the seed for setting the environ-level series constraint? would that cause problems?
<rogpeppe> fwereade: (we've already got to segregate default series from the other environment config params)
<rogpeppe> fwereade: (mind you, that's true of the agent version field too, and probably others)
<fwereade> rogpeppe, yeah -- I think that it is tempting to put lots of stuff into constraints but I want to grow it prudently
<rogpeppe> fwereade: i would *not* put the agent version into constraints
<fwereade> rogpeppe, quite so
<rogpeppe> fwereade: but i think series does work well as a constraint
<fwereade> rogpeppe, a constraint that can't be set like the other constraints, can't be changed like the other constraints, and affects parts of the codebase that no other constraints impact?
<fwereade> rogpeppe, it *may* indeed be a good place for it
<fwereade> rogpeppe, but it will take some pretty seriously ugliness on the other side to balance that out
<fwereade> rogpeppe, so, anyway, as I solve the constraints I will eliminate various images and instance-types from consideration, but I will still probably end up with multiple candidates
<fwereade> rogpeppe, of those that the provider offers, there may not be tools available
<fwereade> rogpeppe, gaah, sorry
<rogpeppe> fwereade: np
<fwereade> rogpeppe, what was the last thing you saw?
<rogpeppe> [11:49:26] <fwereade> rogpeppe, of those that the provider offers, there may not be tools available
<fwereade> rogpeppe, cool, that was all I'd said
<rogpeppe> fwereade: yeah, i see where you're coming from
<fwereade> rogpeppe, but still I will end up with a bunch of possible instance/image pairs, and appropriate tools for each, and then have to try to pick the "best" according to whatever soft constraints we have
<fwereade> rogpeppe, that's a separate problem though
<rogpeppe> fwereade: the thing to be careful of is that you always want to pick from Storage over PublicStorage where possible.
<fwereade> rogpeppe, hmm, if you want to use your own storage you're surely using it for higher-than-public versions..?
<rogpeppe> fwereade: "where possible" might just mean "where the difference is just in version  number"
<rogpeppe> fwereade: no, not necessarily
<rogpeppe> fwereade: it's important that you be able to upload lower-than-public versions too
<rogpeppe> fwereade: and have them used
<rogpeppe> fwereade: that was a significant part of the current design
<fwereade> rogpeppe, ok, sgtm, thank you for pointing that out
<rogpeppe> fwereade: it means that if you use upload-tools, you rely on the fact that you're going to run the uploaded tools (assuming that you deploy to the same architecture)
<fwereade> rogpeppe, but wait
 * rogpeppe waits with baited breath
<rogpeppe> or is it "bated bread"?
<rogpeppe> breath
<rogpeppe> ah, it is
<fwereade> rogpeppe, the latter -- and fwereade is not sure
 * fwereade has just been reminded that he has to visit the shops for cath's lunch; bbiab
<rogpeppe> fwereade: ok
<fwereade> rogpeppe, heyhey
<rogpeppe> fwereade: hihi
<fwereade> rogpeppe, can we explore the public/private use cases a little more? I think I need a little refresher
<rogpeppe> fwereade: ok
<rogpeppe> fwereade: motivating example #1: we want to be able to run the local dev version of the tools without worrying about what might be in a public bucket
<rogpeppe> fwereade: what in particular are you interested in finding out?
<fwereade> rogpeppe, hum, ok, so: does FindTools currently return the latest compatible tools in private, or if that's not there the latest compatible tools in public?
<rogpeppe> fwereade: yup
<fwereade> rogpeppe, ok, so, I think the FindTools variant wants to return all latest matching private toolses, followed by all latest matching public toolses?
 * rogpeppe likes "toolses"
<fwereade> :)
<rogpeppe> fwereade: i'd like to see a sketch of your algorithm for constraints solving before i commit to whether that's the right approach or not
<fwereade> rogpeppe, 1) eliminate non-matching instance types
<fwereade> rogpeppe, 2) eliminate non-matching images
<fwereade> rogpeppe, discard bad combinations in (1) x (2)
<fwereade> rogpeppe, (that may not come exactly there, but will be somewhere)
<fwereade> rogpeppe, 3) eliminate images for which no tools can be found
<fwereade> rogpeppe, 4) discard bad combinations
<fwereade> 5) magic happens here to nail down exactly which one we pick
<rogpeppe> fwereade: i've been wondering about the possibility of *starting* with the available tools
<rogpeppe> fwereade: but i'm not quite sure how that would look, or whether it would be better or worse. i suppose anything that eliminates more possibilities earlier is to be preferred.
<fwereade> rogpeppe, yeah, it shouldn't be too hard to reorder stages if we need to
<rogpeppe> fwereade: that depends if each stage is dealing with a list of the same things
<fwereade> rogpeppe, well, yes: we were I think talking about two stages of image-filtering
<rogpeppe> fwereade: {instance-type} -> {(instance-type, image)} -> {(instance-type, image, tools)}
<rogpeppe> fwereade: is that a reasonable summary of what the data types might look like through each stage?
<rogpeppe> fwereade: where {a} represents a set of a, and (a, b) represents a tuple of a and b.
<fwereade> rogpeppe, yeah, roughly like that
<rogpeppe> fwereade: got lunch. back in a short while.
 * dimitern lunch
<rogpeppe> niemeyer: yo!
<fwereade> niemeyer, heyhey
<niemeyer> Heya
 * fwereade goes to eat the other half of lunch that he neglected before
<rogpeppe> fwereade: from the mongodb charm uniter log: http://paste.ubuntu.com/1676994/
<fwereade> rogpeppe, what's --format json meant to do for relation-set?
<rogpeppe> fwereade: ha, good question, i'd missed that
<rogpeppe> fwereade: i'm surprised the python version allows it
<fwereade> rogpeppe, (that is to say: grar, I guess to match python we need to implement the --format stuff on every hook tool, whether or not it makes sense
<fwereade> )
<rogpeppe> fwereade: we can just ignore it i suppose, mostly
<fwereade> rogpeppe, yeah, I think so
<fwereade> rogpeppe, but tyvm, good catch
<rogpeppe> fwereade: np
<fwereade> rogpeppe, do yu have the bug number handy? I can jot in an explanation
<rogpeppe> fwereade: sorry, i hadn't yet made a bug - i wanted to replicate it first
<fwereade> rogpeppe, np -- then just note that we should add it for everything
<rogpeppe> fwereade: yea
<rogpeppe> h
<fwereade> rogpeppe, (every hook tool that is)
<rogpeppe> fwereade: https://bugs.launchpad.net/juju-core/+bug/1129130
<_mup_> Bug #1129130: all hook tools should support --format <juju-core:New> < https://launchpad.net/bugs/1129130 >
<fwereade> rogpeppe, cool, tyvm
<hazmat> bigjools, thanks for that mongo ppa, btw.
<dimitern> fwereade: ping
<mgz> thanks for the review hazmat
<hazmat> mgz, np
<mgz> hazmat: also, missed the review on the last change landed on lp:juju, have left a comment there now
<hazmat> ack
<mgz> the design for that changed too many times, and ended up in a confused state...
<hazmat> mgz, r597 was pure breakage it appears
<hazmat> mgz, the value returned by constraints convert is used for comparison and validation, the tests weren't previously getting to a real comparison because the constraints lacked series
<mgz> the issue is maas needs the original string, not something that juju constraints have mangled
<hazmat> mgz, folks using it in practice would hit the issue that the string was being returned but the compare method was issubset
<mgz> the previous bug was from passing str(set(['tag-a', 'tag-b'])) which maas didn't understand because it doesn't parse python sets
<mgz> so, that's fixable(ish) elsewhere, I just wonder if we've regressed the other bug...
<hazmat> mgz, hmm.. the original string is preserved and serialized, noted thoug
<hazmat> mgz, yeah.. not having a maas instance to test against makes this a bit of wackamole
<mgz> provided the convert method is only used for juju, and not in the api call, I think we're fine
<mgz> but I can't remember what exactly is the case there...
<hazmat> mgz, the convert  call is also used against __getitem__ implicitly so the constraint acquisition for sending to maas may indeed have issue
<hazmat> checking
<mgz> uses constraints.get... which I have a nasty feeling does convert
<mgz> argh, and the maas client tests use dicts not real constraint objects because those are a pain to construst outside of a provider context
<hazmat> not clear that it does
<hazmat> yeah..
<hazmat> mgz, i'll have a look and try to do a proper constraints test with that api
<hazmat> mgz, thanks
<hazmat> mgz, digging through the tags stuff last  week, i did run into a concern of  tags that where valid at the time of service definition that are no longer valid cause issues
<mgz> yeah, it's troublesome
<mgz> this is generally true for non-trivial constraints, just because it once resolved to something sane, doesn't mean it always will
<mgz> so the provisioner needs to handle having a constraint that fails
<mgz> rather than just going into a retry loop as it does at present...
<rogpeppe> fwereade: you'll like this one. noisy but trivial: https://codereview.appspot.com/7327050
<fwereade> rogpeppe, w00t!
<rogpeppe> fwereade: :-)
<rogpeppe> fwereade: i'm going to unexport state.NotFoundError and export state.NotFoundf
<rogpeppe> fwereade: because i want to be able to create a not-found error for testing purposes
<rogpeppe> fwereade: and there's no point really in exporting the type when we've got IsNotFound
<fwereade> rogpeppe, yeah, as long as we have api.IsNotFound I'm not bothered by the precise gubbins
<TheRealMue> fwereade: Just for info, I put the backend branch into work in progress again. I discovered a missing capability during the storage testing.
<rogpeppe> fwereade: cool
<fwereade> TheRealMue, ah, thanks
<rogpeppe> fwereade: i'm leaning towards something a bit more general actually: api.ErrCode(err) == api.CodeNotFound
<rogpeppe> fwereade: although we could have IsNotFound as a short cut for that
<fwereade> rogpeppe, sgtm
<fwereade> rogpeppe, clear and close enough ;)
<rogpeppe> hmm, typing this was not a good idea:
<rogpeppe> bzr switch  lp:~rogpeppe/juju-core/221-instanceid-bool
<rogpeppe> now: how to get myself out of it!
<mgz> heh
<mgz> what was the location before? just a plain branch, or something fancier?
<mgz> rogpeppe: what do `bzr info` and `bzr branches` say?
<rogpeppe> mgz: it's ok, i've fixed it
<rogpeppe> mgz: i just edited the "location" file
<rogpeppe> mgz: i was using cobzr, so the location before was a file: branch
<mgz> ..that's okay for checkouts, if you also have sane tree state, switching back to the previous location is safer
<rogpeppe> mgz: i couldn't use "cobzr switch" because it complained at me
<mgz> plain bzr switch, with the magic cobzr location, would work (with --force at least), but that does mean you need to know how cobzr maps names
<rogpeppe> mgz: ah, i didn't know that plain bzr had a "switch" command
<rogpeppe> here's a dilemma: is it ethical to ask the company to pay 400 quid more for a flight so that i can get 4 hours sleep rather than none... ?
<rogpeppe> right, time to stop, see y'all tomorrow
<thumper> poos
<thumper> davecheney: ping
<davecheney> thumper: ack
<thumper> davecheney: I have a slight problem
<davecheney> shoot
<thumper> I've managed to cut out a lot of code duplication
<thumper> with one small problem
<thumper> in all cases we want to parse the command line flags with "allowIntersperse=true"
<thumper> except for the case of a supercommand
<thumper> the code is cmd.Main
 * davecheney looks
<thumper> and I want to say "if this Command is a SuperCommand, then use false, otherwise use true"
<thumper> Command is an interface and SuperCommand just a struct
<thumper> what is the best way to ask
<thumper> davecheney: the parsing used to be in the Init methods of *every* command
<thumper> I'm wanting to remove that duplication
<davecheney> +1 to that
<davecheney> thumper: try a type switch
<thumper> the code is nice and simple
<thumper> davecheney: got an example?
<davecheney> c is of type cmd.Command
<davecheney> switch c := c.(type) {
<davecheney> case *cmd.SuperCommand: // guess
<davecheney>  // do something
<davecheney> default:
<thumper> hmm... lemmie test
<davecheney>  // you are something else that conforms to cmd.Command
<davecheney> }
<thumper> sweet
<thumper> works in my small test prog
<thumper> will test in main code
<thumper> davecheney: I think I have it now, but I have to go collect daughter for lunch
<thumper> back online after lunch
<davecheney> thumper: no worries, i have to pop to the shops for breakfast stuffs
<bigjools> hazmat: the pleasure was all mine, believe me :)
#juju-dev 2013-02-19
<thumper> hi davecheney
<davecheney> thumper: ack
<thumper> davecheney: unsurprisingly I suppose my branch has conflicts with trunk
<thumper> just fixing now
<thumper> then it may be worth proposing
<davecheney> kk
<davecheney> +1
 * thumper sighs
<thumper> go get lbox thingy still running
<davecheney> you may find those improvements also apply to jujuc, the hooks
<thumper> I'm so going to prepare some slides for the sprint about this
 * thumper nods
<davecheney> thumper: GTFO, you're going to prepare an agenda
<davecheney> that is rocket surgery shit
<thumper> it is the merging of jujuc and jujud that conflicts mostly
<davecheney> yeah, that doesn't surprise me
<thumper> davecheney: we fly by the seat of our pants?
 * davecheney has no comment
<davecheney> thumper: also got word by the grape vine, book your tickets to ATL
<thumper> ack
<thumper> waiting for them to get back to me about flights
<davecheney> mine were much cheeper than I thought
<davecheney> 1200 EUR
<davecheney> I was expecting to have my pants pulled down
<thumper> :)
<davecheney> no word on where we are staying
<davecheney> but _that_ is par for the course
<thumper> mine are around 1800 - 1900
<davecheney> flying delta, which is unfortunate
<thumper> DL is delta?
<davecheney> yup
<thumper> me too, at least for one part
<davecheney> DL16/17
<thumper> I'm going to be arriving late saturday night
<thumper> that was one of my options
<thumper> but nope
<thumper> it's funny
<thumper> but if I go "go test ./..."
<thumper> go tells me to run "go test -i ./..." to make stuff go faster
<thumper> but when I try that
<thumper> it barfs
<davecheney> paste ?
<thumper> it is way off the screen
<thumper> something about there being no files there
<thumper> davecheney: so... how does lbox propose work then?
<davecheney> it creates the merge proposal on LP, the makes a call to rietveld and sends the diff there
<davecheney> I don't really know how it works under the hood apart from automating a few bits and duplicate the code under review
<thumper> davecheney: here is a work in progress proposal I created already https://code.launchpad.net/~thumper/juju-core/command-set-flags/+merge/149183
<thumper> (using normal LP tools)
<thumper> mainly so I could get a good look at the diff
<davecheney> thumper: understood, a diff -u is the most useful thing for me
<thumper> also, it seems that lbox gets the description and commit message all bungled up
<thumper> for me, the description should describe the what and why you did something
<thumper> the commit message is normally much more terse
<thumper> ok, lets manage the hoop jumping then...
<thumper> I can delete that merge proposal now I know it looks ok
<thumper> and 'lbox propose'... what other bits to I need there?
<davecheney> thumper: make sure you do a go fmt ./... before proposing
<davecheney> or people will freak out
<thumper> davecheney: I have go fmt as a pre-save hook in emacs
<davecheney> noice
<davecheney> if you like you can run the .lbox.check precommit hook
<davecheney> it might work
<davecheney> probably needs environment vars from BZR
<thumper> work for what?
<davecheney> that is the checks that lbox runs
<thumper> it seems that lbox tries to do too much
<thumper> I already push my work
<thumper> with a default location as defined by ~/.bazaar/locations.conf
<thumper> so I just go "bzr push"
<thumper> on a new branch, and it just worksâ¢
 * thumper tries to understand lbox
<davecheney> thumper: i wrote the README and CONTRIBUTINGs
<davecheney> please let me know what is missing or unclear
<thumper> davecheney: how does lbox infer the branch source?
<thumper> I don't like blindly running things I don't understand
<davecheney> it probably assumes cobzr was used
<davecheney> thumper: when you say source, do you mean -for=lp:juju-core
<thumper> davecheney: that is what I'm checking, because I don't do that
<thumper> it seems to run 'bzr info' in a shell, and looks for push location
<thumper> which will work for me
<thumper> gah, parent is going to be an issue though...
<thumper> unless I use -for
<thumper> well... lets see what happens
 * thumper goes for it
 * davecheney checks. water still wet, world, still turning
<thumper> it seemed to infer the correct branches
<thumper> so that is good
<thumper> edited a nice description (or at least I thought so)
<thumper> davecheney: why is this command wanting me to type in my google credentials?
<thumper> and what does it do with them?
<thumper> how can I be sure it isn't being stupid with my password?
<davecheney> because rietveld is a google app engine product
<davecheney> it is probably using some form of oauth
<thumper> I don't feel comfortable typing that into a terminal there
<thumper> :((
<davecheney> thumper: then I thikn you need to stop and escalate at this point
<davecheney> or make a throw away google account
<thumper> I did type in the pwd
<thumper> but wasn't happy doing it
<thumper> will bitch more later
 * thumper is saving it all up
<davecheney> oh, if you use 2FA
<thumper> davecheney: https://codereview.appspot.com/7338048
<davecheney> it'll probably be a complete pain in the arse
<davecheney> from what I hear, not even googlers use rietveld with their 2FA accounts
<thumper> davecheney: why does the appspot thing say (do not edit description out of merge proposal)
<thumper> ?
<davecheney> because it's a one way transfer, LP -> Rietveld
<davecheney> the MP is on the reciepient list, so as you make comments in rietveld, they get cc'ed to the MP
<thumper> davecheney: how the hell does this tool work?
<davecheney> thumper: lots of rest calls
<davecheney> go get -v launchpad.net/lbox
<davecheney> ^ get source
<thumper> I have it
<davecheney> ok
<thumper> how do I see the whole diff through rietveld?
<davecheney> i suspect it does it client side, then rams the whole thing into rietveld
<davecheney> i haven't looked
<davecheney> maybe rietveld takes the who before and after, and doe sthe diff itself
<davecheney> it appears to work at a file level, not a diff level (if that matters)
<sidnei> iirc it submits the diff to rietveld
<thumper> so, can you see the whole diff in one go?
<thumper> hi sidnei
<thumper> sidnei: long time, no talk
<thumper> sidnei: at least I think we have talked before
<sidnei> indeed
<thumper> good, at least I'm not that crazy yet
<sidnei> probably when complete-fail sinzui a couple times *wink*
<thumper> sidnei: what are you doing these days?
<sidnei> thumper: untangling ubuntuone oopses, and polishing tu^H charms. lots of fun.
<sidnei> we're pretty close of moving all (well, like 80% of) the frontends for u1 into juju-managed services
<thumper> nice
<thumper> davecheney: I have noticed that my tollerance for repeated code seems to be a lot less than others
<sidnei> thumper: you? squading away?
<thumper> davecheney: if something is repeated more than twice, refactor
<thumper> sidnei: moved from product strategy -> juju-core a few weeks back
<thumper> sidnei: was unity engineering manager
<thumper> sidnei: and other manager type things for a while
<thumper> back to real coding now
<sidnei> thumper: oh, yeah, last comment from you i recall you were enjoying your c++ i think
<thumper> sidnei: yeah, was hacking on unity, then managed it for a while
<davecheney> thumper: +1
<sidnei> alright. /me goes back to sip some mate. cheers
<thumper> sidnei: caio
<thumper> davecheney: with all that proposed, I suppose I should go back to my help command :)
<davecheney> thumper: just reviewing now
<davecheney> looks pretty good too me
<thumper> davecheney: cool
<davecheney> just a few style comments
<thumper> how many +1's do we need?
<davecheney> 2
 * thumper nods
<davecheney> thumper: I think there is a little more refactoring that can be done for some of the simpler commands
<davecheney> but that should be done in a followup branch
<thumper> I'm sure there is
<thumper> but I tried to limit it for my first branch :)
<thumper> still came in at almost 2k lines
<davecheney> thumper: ignore the ping, that wasn't intended for you
 * thumper didn't get a ping
<davecheney> via email
<thumper> ah
<davecheney> gonna keep pinging till something goes pong
<thumper> :)
<thumper> davecheney: I'm off briefly to get the daughter and move home
<davecheney> thumper: understood, nearly lunch time here
<thumper> damn you python and your acceptance of both ' and " for strings
<thumper> davecheney: how do I store a pointer to a function in a struct?
<thumper> davecheney: Also, can I stick a closure in there?
 * thumper thinks some more...
 * thumper goes to read the language spec part again
 * thumper thinks some more...
<wallyworld> thumper: i think you can declare a variable of type func()
<thumper> wallyworld: yeah got that bit
<wallyworld> eg var f func()
<thumper> but I now want to have a bound method
<thumper> so object.Method
<thumper> perhaps I need to make a closure?
<thumper> that seems stupid
<thumper> but perhaps needed
<wallyworld> i think you *may* need to pass it a closure which calls that method?
<wallyworld> that's how i'd currently do it in my ignorance
<wallyworld> not knowing any better
<thumper> yeah...
<thumper> it is
 * thumper goes to rewrite some code
<davecheney> thumper: yeah, type S struct { f func() }
<davecheney> where func() can be anything, so func(bool, bool, bool) int
<davecheney> etc
<thumper> davecheney: however I can't assign obj.Method to the func
<thumper> without a closure
<davecheney> no, that may be resolved by 1.1, but you currently cannot do that
 * thumper nods
<thumper> found that out :)
<davecheney> passing a closure would essentially be what the compiler would do behind your back
<thumper> it would be nice if a closure was created automagically for you
<thumper> right
 * thumper is using magic for help topics
<thumper> FSVO magic
<davecheney> thumper: that will probably be done for 1.1
<davecheney> function types will become a two word structure, so we can stash the receiver there
<thumper> davecheney: obviously I'm not the only one wanting to do this then :)
<davecheney> https://groups.google.com/d/topic/golang-dev/x328N8hiN5k/discussion
<wallyworld> thumper: there's lots in Go I'm finding is lacking :-) maybe by 2.0.....
<davecheney> wallyworld: 2.0 is a long way off
<davecheney> a long, long, long way off
 * thumper smacks wallyworld around a bit
<wallyworld> i was attemptinh humour
<wallyworld> ouch!
<wallyworld> thumper: why smack me around?
<thumper> wallyworld: why not?
<wallyworld> fair point
<thumper> is the easiest way to create a long string to use a bytes.Buffer?
<thumper> how to I get a string from that?
<wallyworld> buffer.String()
<davecheney> bytes.Buffer is both an io.Reader and an io.Writer
<davecheney> you can write to it with fmt.Fprintf
<davecheney> and copy it to stdout/stderr with io.Copy
<davecheney> if that is of use
<thumper> ta
<davecheney> probably a few ways to skin that cat
 * thumper nods
<thumper> hmm... now I'm causing a panic...
<thumper> found it...
 * thumper goes swimming
<rogpeppe> morning all
<fwereade> rogpeppe, heyhey
<TheMue> Morning
<jam> TheMue: good morning
<TheMue> jam: Hiya
<jam> TheMue, fwereade, rogpeppe, dimitern, wallyworld, mgz, w7z: https://plus.google.com/hangouts/_/3054ca9e05632bb677f4a136cc956486d9aac90f
<dimitern> jam: cheers
<TheMue> jam: Thx
<wallyworld> different from the invite?
<jam> wallyworld: should be the same
<jam> but often the direct link helps people
<rogpeppe> fwereade: ping
<jam> mgz: poke
<mgz> was just doing the hangout dance :)
<jam> mgz: just some chewing noises from you
<jam> dimitern: your non-headset mic is picking up the surrounding noise
<fwereade> none of us can hear anything, I think
<mgz> "The hangout ended because of a server error"
<rogpeppe> i should have mentioned that i'll be on holiday thurs and fri this week
<jam> dimitern: poke about some tests in environs/openstack/local_test.go
<rogpeppe> i'd much appreciate a review or two of the following branches, if possible: https://codereview.appspot.com/7354044/ https://codereview.appspot.com/7327050/ https://codereview.appspot.com/7314116/
<mariusko> Hi
<mariusko> I wrote a quick blueprint about git based deployment of user applications: https://blueprints.launchpad.net/juju/+spec/juju-charm-app-git-deployment
<mariusko> Does anyone have any comments?
<dimitern>  jam: sorry, just saw that
<jam> rogpeppe: review up on the first one
<rogpeppe> jam: thanks
<jam> dimitern: np, so TestInstancesGathering fails if you run it by itself.
<jam> cd environs/openstack; go test -gocheck.v -gocheck.f InstancesGathering
<jam> I think the issue is that it doesn't call s.BootstrapOnce() and it relied on other tests doing that step.
<dimitern> jam: i suspect it' because of the need to bootstrap first in the local tests
<dimitern> jam: oh, this could be it yeah
<jam> It is also the test that has failed for me a couple of times with http://past.ubuntu.com/1681193/
<rogpeppe> jam: you're correct about your supposition about that CL. it's so that i could generate a not-found error for the third branch in that series.
<jam> dimitern: which the error message is a bit hard to parse, but it looks to be the "Server "185" alreayd
<jam> already belongs to group "1""
<dimitern> jam: the problem is a bit more obscure i think
<rogpeppe> jam: stupidly, i posted those links in the wrong order - the second is actually a prereq for the first
<dimitern> jam: we're creating more than one environ it seems
<jam> rogpeppe: https://codereview.appspot.com/7327050/patch/2001/3009 I don't see other ones that return a bool. PasswordValid does, because it is answering a question, similarly AgentAlive but AgentAlive returns both a bool and an error.
<dimitern> jam: who's the head of our business unit? robbiew? I'm asked by the travel agent
<jam> dimitern: Deryck is above me, then probably Robbie above that, yes.
<rogpeppe> jam: examples: Unit.DeployerName, Unit.PublicAddress, Unit.PrivateAddress
<jam> rogpeppe: none of which are on Machine, but I'll go look
<jam> rogpeppe: my immediate feeling is that you lose the ability to describe what the problem is by just having a bool
<jam> so an err is actually better.
<rogpeppe> jam: the thing is that there is only one possible problem here
<rogpeppe> jam: and lots of the other code was testing specifically for NotFound, and then another test for other errors (in some cases buggily) which could never happen
<jam> rogpeppe: but instead of having the code that is checking what the problem is generating the error, you have the code that is asking for the info creating the error.
<rogpeppe> jam: there are only two places that create an error as a result, AFAIR
<rogpeppe> jam: FWIW me and fwereade have been wanting to make this change for ages
<jam> rogpeppe: so in the first location cmd/juju/ssh.go it seems to always silently ignore failures, which seems odd.
<jam> (I can't say it is *wrong* because I don't really know the code, but it seems strange)
<mariusko> See https://bugs.launchpad.net/juju/+bug/891868 for a blocker to accomplish it
<_mup_> Bug #891868: juju cli api should be invokable outside of units/hooks <juju:Confirmed> < https://launchpad.net/bugs/891868 >
<rogpeppe> jam: it waits for the instance id to become available
<rogpeppe> jam: actually though, i think that code *is* probably wrong (and was wrong before)
<rogpeppe> jam: because InstanceId only looks at the local machine state, which isn't changing in that loop
<jam> rogpeppe: is Changes() a channel? Or is it just a slice of changes that its found?
<rogpeppe> jam: it's a channel
<jam> (Is that loop "while things are still changing, handle the next change"?
<rogpeppe> jam: all watchers return a channel from the Changes method
<rogpeppe> jam: it should be fixed, but it's unlikely to be a problem in practice as no-one wants to ssh to a machine to which no units have ever been assigned.
<jam> rogpeppe: so you do explicitly trade one place for 2 places having the same formatting string of  "instance id for machine %v not found"
<jam> in https://codereview.appspot.com/7327050/patch/2001/3013
<jam> but the rest do all treat the error as essentially a boolean
<rogpeppe> jam: yeah, as suggested by dave cheney, i'll change it to return state.NotFoundf(...)
<rogpeppe> jam: (i can't do it in this CL because it's dependent on this one)
<jam> rogpeppe: you still have to have 2 copies of the error string, and make sure you don't mess up the formatting, and deal with updating both if you decide to change the message to users, etc.
<jam> rogpeppe: anyway, I won't block it, but it seems like you're pushing the "this is an error" up a level, when really it was at the correct level to start with.
<rogpeppe> jam: it's not really an error. it's more an indicator of availability.
<rogpeppe> jam: an error return says to me "anything can happen here"
<rogpeppe> jam: but that's not the case here
<rogpeppe> jam: to be honest, i'd be happy if it just returned a blank string when the instance id isn't assigned
<jam> rogpeppe: when you pointed me at the other examples where 'bool' is used, it did seem to make a lot more sense to just return the empty string, rather than having the callers check that the bool really does say the empty string is invalid.
<jam> (bool wasn't adding any information that the caller didn't already know)
<jam> unless there are other situations where the value could be invalid, that we just hadn't codified yet.
<rogpeppe> jam: yeah. niemeyer didn't like it though, so we added the extra return value.
<jam> rogpeppe: did you understand his rationale at the time?
<rogpeppe> jam: not really :-)
<rogpeppe> jam: but i come from a place where it's ok to use -1 to signal an error :)
<jam> rogpeppe: well that all depends if -1 is in the valid set :)
<rogpeppe> jam: indeed. assume it's not.
<jam> dimitern: so any idea about how we would still have a Server attached to a group at the time the test is starting up?
<dimitern> jam: not at the moment, have to think about it a bit - it's been a while
<dimitern> jam:
<jam> ?
<dimitern> oops :) I found it
<dimitern> so indeed, bootstrapping once before is enough
<dimitern> but not for the other tests
<dimitern> I'll propose a patch that fixes that now
<dimitern> jam: PTAL https://codereview.appspot.com/7303101
<jam> dimitern: right, I have that change in the queue, but I was trying to find the isolation stuff. But I'll go ahead and approve it.
<dimitern> jam: the issue was a clash between the test bootstrap fails without public ip and test instance gathering
<jam> dimitern: LGTM trivial, though I don't think you want the extra whitespace.
<dimitern> jam: ok, i'll remove it
<dimitern> I wish bzr was more clever wrt command aliases, like hg
<jam> dimitern: in what sense?
<dimitern> i'm used to have things like "pul" or "sw", etc.
<dimitern> unambiguous prefixes
<jam> dimitern: you can 'bzr alias' them, but it does have a few (bzr di, bzr st, etc)
<dimitern> yeah, st and ci i use all the time - didn't even check - it just worked
<dimitern> ok cool, I'll set some aliases myself then :)
<dimitern> jam: are there global bazaar.conf, used by /usr/bin/bzr ? in addition to ~/.bazaar/bazaar.conf i mean
<jam> dimitern: no
<jam> no /etc conf
<dimitern> hmm cobzr doesn't play nicely with bzr aliases it seems
<dimitern> jam: standup?
<jam> dimitern: ah, I think cobzr re-implements the front-end and has to re-implement all the commands.
<rogpeppe> small branch to change the api to be able to log messages: https://codereview.appspot.com/7358045
<jam> mgz: http://paste.ubuntu.com/1681193/
<TheMue> rogpeppe: You've got a review.
<dimitern> rogpeppe: another review
<rogpeppe> TheMue, dimitern: thanks
<rogpeppe> TheMue: i started by using "read" and "write" but actually the -> and <- stand out much better in the log.
<dimitern> TheMue: you've got a review too
<TheMue> rogpeppe: ok, can live with it. ;)
<TheMue> dimitern: Great, thx.
<TheMue> dimitern: The storage test is so far a copy of the according part of environ/jujutest.
<TheMue> dimitern: It is intended to be later removed, when everything is integrated.
<dimitern> TheMue: yeah, i was wondering why copy that instead of just use it?
<TheMue> dimitern: This way I had a chance to check the behavior before the rest is done.
<dimitern> TheMue: ah, ok
<TheMue> dimitern: So I'll remove it later. ;)
<dimitern> TheMue: cool, so comment about it please, that there'll be a follow-up
<TheMue> dimitern: Detected a not expected behavior that way, when listing files.
<dimitern> TheMue: with ordering?
<TheMue> dimitern: Will do it, when I cover the rest of your hints.
<TheMue> dimitern: No, the handling of directories when the passed pattern matches.
<dimitern> TheMue: i see
<rogpeppe> lunch
<rogpeppe> looks like the "juju set" tests are crack *sigh*
<rogpeppe> as is juju get *deeper sigh*
<rogpeppe> https://bugs.launchpad.net/juju-core/+bug/1130149
<_mup_> Bug #1130149: juju get does not print default values correctly <juju-core:New> < https://launchpad.net/bugs/1130149 >
<TheMue> rogpeppe: Hangout?
<rogpeppe> TheMue: ah thanks
<benji> Hi all.  I am trying to bootstrap using EC2 and it apparently works (the instance shows up in the EC2 console) but when I run "juju status"
<benji> ... I get this error: "panic: runtime error: invalid memory address or nil pointer dereference" plus a lot more. (I'm using go juju.)
<bac> and i am seeing the same using r908 of juju-core
<rogpeppe> benji: was that with bootstrap --upload-tools ?
<benji> rogpeppe: yep
<rogpeppe> benji: hmm, can you paste the "lot more", please?
<benji> heh, sure
<rogpeppe> benji: (i haven't ever seen that problem, FWIW)
<benji> rogpeppe: http://paste.ubuntu.com/1682852/
<benji> rogpeppe: another data point: the api server doesn't seem to have started on the EC2 instance because if I point a websocket client at it I get connection refused
<rogpeppe> benji: i'll see if i can replicate the problem
<rogpeppe> benji: what do you see if you do juju status --debug ?
<rogpeppe> benji: (i think it's likely that the original bootstrap failed for some reason, and the dial has timed out after 10 minutes, and there's a bug which means that error isn't checked so ends up panicing)
<rogpeppe> benji: in fact, it might be useful to see what went on on the bootstrap machine.
<benji> rogpeppe: it looks that way
<benji> lots and lots of "2013/02/19 15:37:05 JUJU state: connection failed: dial tcp 50.19.23.159:37017: connection refused"
<rogpeppe> benji: you can do that by ssh'ing to it and catting the log file
<rogpeppe> benji: the log file in question being /var/log/cloud-init-output.log
<rogpeppe> benji: i use the PEM file from $HOME/.ec2 to do the ssh - presumably you have something similar
<benji> rogpeppe: let me try that...
<rogpeppe> benji: my "ec2ssh" script is something like this: ssh -i $HOME/.ec2/rog.pem ubuntu@$1
<rogpeppe> benji: and you can find the dns name from the aws console
<benji> rogpeppe: no .pem files there for me; is that something I need to get from EC2?
<rogpeppe> benji: hmm, i can't remember at all!
<rogpeppe> benji: ah, i think i probably added the key to my aws account
<rogpeppe> benji: yeah, here: https://portal.aws.amazon.com/gp/aws/securityCredentials#access_credentials
<rogpeppe> benji: that might mean you can't get ssh access
<rogpeppe> benji: although... you could just try ssh'ing in and see what happens
<benji> rogpeppe: I tried, it refuses me
<rogpeppe> benji: as ubuntu@ ?
<benji> rogpeppe: oh! nope, let me try that
<benji> rogpeppe: it worked!
<rogpeppe> benji: yay
<benji> rogpeppe: I'm on a call at the moment, but I will dig into this in a couple of minutes.
<rogpeppe> benji: ok, cool. i suspect it's an amazon transient failure that we should work harder to be more resilient to.
<rogpeppe> benji: in particular, the metadata service doesn't work reliably
<rogpeppe> trivial CL to review anyone? https://codereview.appspot.com/7359044
<rogpeppe> benji: that fixes the panic you saw, at any rate
<benji> rogpeppe: /var/log/juju/machine-0.log on the bootstrap node contains lots of "2013/02/19 15:07:57 JUJU state: connection failed: dial tcp 127.0.0.1:37017: connection refused"
<rogpeppe> benji: what does the cloud-init log say?
<rogpeppe> benji: (that one has all the messages printed by the commands run when bootstrapping)
<benji> rogpeppe: no obvious errors and it ends with "cloud-init[DEBUG]: Ran 9 modules with 0 failures"
<rogpeppe> benji: hmm. could you paste the last 100 lines or so of it?
<rogpeppe> benji: it looks like mongodb isn't running, but i'm not sure why
<benji> rogpeppe: http://paste.ubuntu.com/1683016/
<rogpeppe> benji: ah, sorry, wrong log
<rogpeppe> benji: you want cloud-init-output.log
<rogpeppe> benji: that's the one that juju produces
<benji> rogpeppe: lots of "2013/02/19 15:07:53 JUJU state: connection failed: dial tcp 127.0.0.1:37017: connection refused" and then a panic
<rogpeppe> benji: could you paste the 50 lines *before* it started printing "connection failed" ?
<benji> "ps aux | grep mongo" does not show any mongo process running
<benji> k
<rogpeppe> benji: yeah, i'm pretty sure mongo never started - probably the download failed, but i'm interested to find out why, to add to the collection of transient errors we've seen
<benji> rogpeppe: yep:
<benji> http://juju-dist.s3.amazonaws.com/tools/mongo-2.2.0-quantal-i386.tgz:
<benji> 2013-02-19 14:57:53 ERROR 404: Not Found.
<rogpeppe> benji: ah!
<benji> should I be using something other than quantal?
<rogpeppe> benji: you should be using amd64
<benji> mmm
<rogpeppe> benji: i don't think anyone's build the mongo version we need for 386
<rogpeppe> s/build/built/
<benji> how do I specify that in .juju/environments.yaml?
<rogpeppe> benji: it's a pity that the failure mode is so darned obtuse. we'll have to think how to make that better.
<rogpeppe> benji: if you're using --upload-tools, you can only use your current architecture
<rogpeppe> benji: because that's the arch that the tools are built for
<benji> hmm, so step 1) upgrade my development machine
<rogpeppe> benji: yeah. sorry we don't have a better story here. step 1 could be "compile mongo db with ssl enabled for i386"...
<rogpeppe> benji: hmm, maybe i'll have a go at doing that. it might have finished by morning.
<benji> it would be good, but realistically it won't be smart for me to be an outlier here, I need to match as closely as possible how you guys work so we don't continually run into these kinds of issues
<rogpeppe> benji: hmm, maybe it's too much distraction for now, sorry.
<benji> no worries
<rogpeppe> benji: somewhat surprisingly, there wasn't an outstanding bug, so here it is: https://bugs.launchpad.net/juju-core/+bug/1130209
<_mup_> Bug #1130209: we need a mongodb compiled for i386 <juju-core:New> < https://launchpad.net/bugs/1130209 >
<niemeyer> A bit late, but hello all! :)
<rogpeppe> niemeyer: hiya
<rogpeppe> niemeyer: william's sick today - can i bend your ear for a sanity check, by any chance?
<niemeyer> rogpeppe: Yeah, I'm just busy sorting something out ATM
<rogpeppe> niemeyer: np
<niemeyer> rogpeppe: and have to had to lunch in a second
<niemeyer> rogpeppe: Meeting at 16, in 3h.. I think we can do something between lunch and that
<rogpeppe> niemeyer: give us a ping when you have a mo, thanks!
<rogpeppe> review anyone? https://codereview.appspot.com/7326052
<dimitern> rogpeppe: i got it
<rogpeppe> dimitern: thanks!
<bac> rogpeppe: i'm using this build of mongo+ssl from julian's PPA:  https://launchpad.net/~julian-edwards/+archive/mongodb
<rogpeppe> bac: ok. presumably that doesn't help with bootstrap, because that binary isn't in the public bucket
<bac> ah
<rogpeppe> bac: i did have the credentials once.... i'll have a look and see if i kept them.
<rogpeppe> bac: ha, i think i might just be able to do it
<dimitern> rogpeppe: reviewed
<rogpeppe> dimitern: tyvm
<dimitern> rogpeppe: ym
<dimitern> i'm off, good night guys
<rogpeppe> dimitern: g'night
<bac> rogpeppe: that would be great if you could
<rogpeppe> bac: i'm just trying to work out which of those packages has the files i'm after
<rogpeppe> bac: and fumbling my way through unarchiving .deb files (i've managed to avoid delving into all the ppa stuff before)
<niemeyer> rogpeppe: Hey, what's up?
<rogpeppe> niemeyer: yo!
<rogpeppe> niemeyer: just came across severe crackness in juju set/get and just wanted to make sure it *is* crack and that i'm going to do the right thing
<niemeyer> rogpeppe: Ok
<rogpeppe> niemeyer: currently, the code in juju set does an explicit remove when a value is set to ""
<rogpeppe> niemeyer: but if you set it with a yaml file, the value just gets set to "" (and probably fails as a result)
<rogpeppe> niemeyer: i *think* that we probably want to have the two things be equivalent
<niemeyer> rogpeppe: how would it fail?
<rogpeppe> niemeyer: it would fail, i think, because the config validation would expect an integer, but see a blank string
<niemeyer> rogpeppe: Agreed, they should be the same
<niemeyer> rogpeppe: An empty value should mean removal
<rogpeppe> niemeyer: so i'm thinking that juju set service --config config-file where  config-file contains {foo=""} should be the same as juju set service 'foo='
<rogpeppe> niemeyer: yeah
<rogpeppe> niemeyer: good
<rogpeppe> niemeyer: the other crackful thing (i think) is that juju get never shows default values unless they've been explicitly set
<rogpeppe> niemeyer: it shows 'em all as null
<niemeyer> rogpeppe: OTOH, it seems awkward to have a setting in a configuration file
<niemeyer> rogpeppe: with an empty string, on an integer field
 * rogpeppe swithers
<rogpeppe> niemeyer: perhaps we shouldn't allow settings to be reset to their default from a conf file without explicitly setting them to their default values.
<rogpeppe> niemeyer: i dunno
<rogpeppe> niemeyer: i like the simplicity of having the yaml exactly equivalent to the command line
<niemeyer> rogpeppe: I actually think failing in that case is fine
<rogpeppe> niemeyer: and i did quick probe into #juju and found general agreement.
<niemeyer> rogpeppe: Actually.. hmm
<niemeyer> rogpeppe: There is no integer type..
<niemeyer> rogpeppe: It can't fail
<niemeyer> rogpeppe: Oh, nevermind
<niemeyer> rogpeppe: I was thinking of relation-set
<rogpeppe> niemeyer: ah yes
<niemeyer> rogpeppe: Yeah
<niemeyer> rogpeppe: I'd prefer to see "" checked, and null meaning remove
<niemeyer> rogpeppe: They are inherently different formats.. we can't make them match precisely
<rogpeppe> niemeyer: the issue was brought home to me particular because the API provides access to yaml-format setting (to allow GUI clients to type in yaml settings and avoid js yaml parsing), and the difference seemed odd.
<rogpeppe> niemeyer: random opinion from #juju:
<rogpeppe> [12:24:03] <Daviey> null = None = "" = nonexistent IMO :_
<rogpeppe> niemeyer: hmm, you're probably right about null being the right thing in yaml. but that means the yaml is strictly more expressive than setting string options (it can make a blank string explictly override a default), and i'm not sure that's right either.
<niemeyer> rogpeppe: Random opinions without reasoning are hard to evaluate
<niemeyer> rogpeppe: yaml *is* more expressive
<rogpeppe> niemeyer: here's the context: http://paste.ubuntu.com/1683371/
<rogpeppe> niemeyer: yeah, but do we want it to be in this case?
<rogpeppe> niemeyer: thanks for the input anyway, it's very helpful
<niemeyer> rogpeppe: np
<rogpeppe>  i'm off for the day now, have a good r.o.d. all
<rogpeppe> a new CL in case anyone fancies it: https://codereview.appspot.com/7305101 (and its prereq)
<rogpeppe> fwereade: hope you're feeling a bit better
<rogpeppe> fwereade: see ya tomorrow if so :-)
<fwereade> rogpeppe, somewhat iffy tbh
<rogpeppe> fwereade: well, don't push it
<rogpeppe> fwereade: i've got a fair few reviews out, nothing too taxing, if you want something not too hard to do :-)
<fwereade> rogpeppe, don't count on it, I'm afraid, I'm only on for a call
<rogpeppe> fwereade: np
<rogpeppe> fwereade: see ya when i see ya :-)
<fwereade> rogpeppe, cheers, enjoy your evening
<thumper> morning
<bac> hi thumper
<thumper> hi bac
<thumper> bac: I see that I'll see you in Atlanta
<thumper> and more ex-launchpadders
<thumper> I'm looking forward to it
<bac> thumper: oh, good.  hadn't seen you on the list
<thumper> bac: just added myself
<thumper> bac: and my OCD took over
<thumper> bac: I had to put the attendees in alphabetical order
<thumper> it drove me spare
<bac> oh, i did that yesterday
<bac> :)
<thumper> it was partially sorted
<bac> yes, the top is where i left off
<thumper> but people were obviously just appending to the end
<bac> or CDO as jeff-blue-hair-guy said
 * bac is sure that made no sense to anyone
<bac> i've just brought up a new VM and am trying to get juju-core installed and working again.  i get this when trying to install:
<bac> bac@quantal64:~$ go install -v launchpad.net/juju-core/...
<bac> work/src/launchpad.net/juju-core/state/api/apiserver.go:4:2: import "code.google.com/p/go.net/websocket": cannot find package
<bac> that appears to be the right way to import websocket, and i'm working with a fresh copy of trunk...
<bac> fwereade: any ideas about ^^^ ?
<fwereade> bac, sorry, that is new to me
 * fwereade pokes around
<fwereade> bac, yeah, happen for me as well when I move the installed one out of the way
<bac> fwereade: this is a fresh vm.  did i forget to grab something?
<fwereade> bac, hey, wait, did you go get it?
<fwereade> bac, if you go getted juju-core it would have done it I think
<bac> fwereade: i did
<bac> i go got it and then i tried to go install it
<bac> fwereade: i assume the imports from google get installed locally somewhere.  should they be in my GOPATH too?
<fwereade> bac, yeah, they should have been
<bac> yeah i have GOPATH/src/code.google.com/p but it is empty
<bac> hmm
<bac> fwereade: i think i found it.  i didn't install hg...
<fwereade> bac, ah!
<bac> or git
<fwereade> bac, it's a bit crap that they don't warn clearly about that though
<bac> that's what i get for working from memory
<fwereade> bac, that should surely be an error on go get
<bac> yeah
 * thumper was getting confused by the review dates shown
<thumper> as the review comments were from before it was sumbitted
<thumper> or submitted even
 * thumper is pleased he ran the tests first...
<thumper> fwereade: to update the diff in the special review tool, to I have to lbox propose again?
<thumper> normally I just push
 * thumper takes a stab that unary negation is !
<fwereade> thumper, yeah, lbox propose again -- it will take the opportunity to publish all your review responses at the same time
<thumper> I already did that
<fwereade> thumper, sorry, is it not working?
<thumper> fwereade: style question
<thumper> fwereade: is_super_command or isSuperCommand (for a variable)
<thumper> fwereade: what I meant was that I had already published my review responses
<thumper> and then I ran the tests before committing
<fwereade> thumper, underscores don't seem to be popular anywhere really except maybe ALL_CAPS_CONSTANTS
<thumper> and found I had a backwards bool expression
 * thumper has been doing python forever
<thumper> and they are PEP8
<thumper> I notice most local variables are not multiple words though
<thumper> I prefer to show intent
<thumper> to me, isSuperCommand is harder to read than is_super_command
<thumper> but that's just me
<davecheney> thumper: yeah, go style is camelCase
<thumper> or issupercommand
<davecheney> it is what it is
 * thumper understands
 * thumper kicks the camel
<davecheney> it sort of falls out of the export rules
<thumper> why?
<thumper> that's fine for functions
<thumper> but what about variables, why the same?
<davecheney> the export rule applies to all symbols
<fwereade> thumper, I do know where you're coming from but I guess I was lucky -- I found it relatively easy to dust off the camelCaseReading part of my brain
<thumper> I can get used to anything
<thumper> I was just wondering on the rationale
 * fwereade had never thought of it that way but it makes sense, thanks davecheney
<thumper> fwereade: I find it hard to work out what the state of the review is...
<thumper> fwereade: https://codereview.appspot.com/7338048/
<thumper> fwereade: had two people look
<thumper> I've replied to the comments, making changes
<thumper> one bit was a non-trivial change
<thumper> what's the situation now?
<thumper> also, if I set the commit message on the merge proposal, will lbox merge use it?
<fwereade> thumper, you've replied to the stuff in patch set 1 and it's now waiting for further review if required
<thumper> fwereade: but how do I know when it's all good?
<thumper> There were two lots of comments on rietveld, but only one on the merge proposal
<thumper> since I tend to drive from email, it is confusing
<fwereade> thumper, you have already got two LGTMs, indicating that the reviewers trust your taste/judgment enough to handle the suggestions appropriately and land it
<fwereade> thumper, yeah, launchpad rather fades into the background with lbox
<thumper> wow, trust on the first merge proposal
<thumper> that is something new to me :)
<davecheney> thumper: try something more audatious next time
<thumper> davecheney: heh
<thumper> hmm...
<thumper> just merged trunk
<thumper> and getting failures with openstack environ tests
<thumper> local_test.go line 271
<thumper> I may hit timing issues differently to others
<thumper> I have a fast newish i7 with a fast SSD
<thumper> I hit issues booting the damn machine
<thumper> hitting a race condition in X initialisation
<thumper> the test seems to pass the second time through
<thumper> fwereade: so lbox merge is the way to go?
 * thumper takes a stab
<thumper> the answer to the "does it use the commit message" is no, no it doesn't
<fwereade> thumper, sorry, lbox submit
<thumper> fwereade: I've dont it already :)
<thumper> and it says done.
<thumper> so I guess it is done
 * thumper looks at the trunk branch on lp
<thumper> yep
<thumper> \o/
<thumper> first commit into trunk
 * thumper does a little dance
 * fwereade cheers at thumper
<fwereade> thumper, I thought it was a really nice change btw, thank you
<thumper> fwereade: np, I have the help command lined up next
<fwereade> thumper, it seems to have the log message from the description?
<thumper> it is coming along really nicely
<fwereade> thumper, excellent
 * davecheney loves how 'software updater' doesn't actually update softeware, just segfaults
<thumper> fwereade: I overrode the message that the 'lbox submit' popped up with what I had typed into the commit message
<thumper> that is why it looks the same
<thumper> davecheney: for the Assert methods...
<thumper> is there an AssertTrue and AssertFalse?
<thumper> and does Assert(value, IsNotNil) work?
<davecheney> thumper: no, there is no AssertTrue or AssertFalse in gocheck
<thumper> davecheney: so Assert(value, Equals, true) ?
<davecheney> thumper: that is correct
<davecheney> also
<davecheney> c.Assert(err, NotNil)
<thumper> so, can we add it?
<thumper> ta
<davecheney> there is also the more verbose
<davecheney> c.Assert(err, Not(Equal), nil)
<thumper> have you seen the matchers concept?
<davecheney> whihc problably won't work first time
<davecheney> i just guessed
<thumper> this is used by testtools (the python module)
<thumper> so...
<davecheney> can we add it
<davecheney> the project is owned by niemeyer on his private brnch
<thumper> <python>  assertThat(some_value, Equals(10))
<davecheney> i have a few patches waiting in the queue to land there that fix some data races
<thumper> assertThat(some_value, IsNil())
<thumper> etc
<thumper> I always found the matchers a really nice way to write readable tests
<bigjools> matchers are awesome
<bigjools> porting testtools to Go would make Go a lot nicer to use
<thumper> agreed
<niemeyer> davecheney: Still on my queue, and shouldn't take long now. Sorry for the delay.
<niemeyer> NotNil exists, btw
<niemeyer> Ah, you said so
<niemeyer> AssertTrue vs. Equals, true is pretty much the same.. we don't need aliases to that, IMO
#juju-dev 2013-02-20
<davecheney> niemeyer: OT, i met Benny Siegert last night
<davecheney> he now works for google as an SRE
<davecheney> and was visiting Sydney
<niemeyer> davecheney: Benny.. hmm
<niemeyer> davecheney: I think I had a couple of interactions with him only in golang-nuts@
<niemeyer> davecheney: There was an event yesterday, right? How was it?
<davecheney> excellent
<davecheney> numbers are improving every time
<davecheney> we had 50 people
<davecheney> more maybe
<davecheney> the room was packed
<thumper> davecheney: a go meetup?
<davecheney> yup
<davecheney> that was why I couldn't make the meeting last night
<davecheney> I run the sydney golang meetup group
<thumper> ah
<thumper> I think I've just found a real use of the struct composition with methods...
<thumper> the alias struct in supercommand.go
<thumper> it overrides Info
<thumper> but not the other methods
<thumper> those get resolved to Command?
<thumper> I do have to be honest in thinking that this looks like bastardised inheritance
<davecheney> thumper: it's much less than that
<davecheney> it is no inheritence at all
<thumper> so how does it resolve the correct function calls?
<davecheney> always at compilation time
<thumper> sure, how
<davecheney> embedded fields are just syntactic sugar
<davecheney> type S struct { io.Reader }
<davecheney> var s S
<davecheney> s.Read is just sugar for s.Reader.Read
<davecheney> ^ one example
<thumper> only if s.Read doesn't exist?
<davecheney> yup
<thumper> hmm
 * thumper pokes supercommand internals some mroe
 * thumper gets hit by python vs. go differences again
<thumper> hmm...
<thumper> davecheney: how clever is go in matching similar names
<thumper> eg. I have: type A struct {val Foo}
<thumper> and a method
<thumper> func bar() {
<thumper> no...
<thumper> func bar(val Foo) {
<thumper> a = A{val: val}
<thumper> will it match those properly?
<thumper> or do I have to rename something
<davecheney> thumper: o_O
<thumper> davecheney: this is relatively normal python and c++
<davecheney> didn't undestand your example
<davecheney> say again, over
<thumper> davecheney: I have a function parameter that matches the name inside a structure
<thumper> that I'm trying to initialise
<thumper> so I'm trying to create an A
<thumper> where A.val == parameter val
<davecheney> yup, no problem there, they are different names
<thumper> so A{val: val} is fine?
<davecheney> sure
<thumper> coolio
<davecheney> val: isn't a symbol
<davecheney> it's the name of a struct member
 * thumper nods
<davecheney> s/symbol/identifier
<davecheney> when embedding you always have to disambiguate
<davecheney> ie
<davecheney> type S struct { io.Reader }
<thumper> does go have a set type?
 * thumper wants an ordered set
<davecheney> actually, that is a crap example
<davecheney> no, no set type
<davecheney> you can use a map
<thumper> :(
<davecheney> maps are not ordered
<davecheney> map iteration is random
<thumper> no, but I want one
<thumper> plz add to go 1.1
<thumper> set + ordered_set
<thumper> and ordered_map
<thumper> :)
<davecheney> the standard way is to extract the keys of a map
<davecheney> sort them
<davecheney> then using that sorted slice
<davecheney> you get the picture
 * thumper loves python
<thumper> for key, val in sorted(some_dict):
<davecheney> it is what it is
<thumper> hmm.. missed the .items()
 * thumper nods
 * thumper will work around it
<thumper> davecheney: so... if a second parameter is passed to make([]string, size)
<thumper> davecheney: is the underlying array that size?
<thumper> so meaning make([]string, 4) -> {"","","",""} ?
<thumper> or is it actually empty with just enough space for 4 elements?
 * thumper feels like he needs to read the language spec again
<thumper> hmm. found it
<thumper> make([]T, length)
<thumper> make([]T, length, capacity)
<thumper> hmm
<thumper> is foo := []string
<thumper> an array or a slice?
<thumper> actually: foo := []string{}
<davecheney> []slice
<davecheney> [1234]array
<davecheney> var foo []string -> nil slice, len and cap are 0
<davecheney> foo := []string{} -> non nil slice, len and cap are 0
<davecheney> foo := make([]string, 0) -> non nil slice, len and cap are 0
<davecheney> if you are using reflect there is a difference between the 1st, and second and third arguments
<davecheney> otherwise there is no difference
<thumper> so... what I want is foo := make([]string, 0, len(otherthing))
<thumper> as I don't want anything initially in foo
<thumper> but I want to avoid unnecessary allocations
<thumper> and I know at max there will be len(otherthing) elements
<thumper> sound reasonable?
<davecheney> sure
<thumper> kk
<davecheney> most times we don't bother setting a capacity
<davecheney> just
<davecheney> var foo []string ; for _, v := range thing { foo = append(foo, v) }
<davecheney> ^ as an example
<thumper> why?
<thumper> how often would the underlying array resize?
<thumper> it just seems like good manners to me
<thumper> perhaps I'm over thinking
<davecheney> i forget the exact mthod
<davecheney> doubling up to 1000 elements then +1000 I think
<davecheney> i can find out
<thumper> so, adding 20 items causes how many allocations to an empty slice?
<thumper> with a default capacity of zero
<thumper> it means initially you are getting quite a few, unless the 0 -> next is something like 10
<thumper> the default capacity specified for C++ std::vectors is 10 (by most implementations) for this exact reason
<thumper> hmm...
<thumper> not doubling all the time was a cause of a bug I hit with solaris c++ std::stringstreams a long while back
<thumper> it was iterative
<thumper> and not expecting the amount of data I was throwing at it
<davecheney> I can check, i think it might start at 8
<davecheney> but I am guessing
<davecheney> if you think it is important, then set the capacity when known
<davecheney> but avoid getting distracted by all the other places in the code where we do not do so
<thumper> I only think it is important because I want to avoid unnecessary allocations
<thumper> however
<thumper> there will likely be absolutely zero notice by a user
<thumper> so I'll keep the code simple
 * thumper on the move again
<thumper> bollocks, bollocks, bollocks
 * thumper hacks and slashes recent changes
<thumper> davecheney: back?
<thumper> if I have a type of []string, and a method that takes (args ...string)
<thumper> how to I pass the former into the latter?
<thumper> found it
<davecheney> yup, varags syntax
<davecheney> func F(args ...string)
<davecheney> var s []string
<davecheney> F(s...)
<thumper> davecheney: found it in the spec
<thumper> quite a handy doc that
<thumper> I'm liking how fast go compiles
<davecheney> yeah, that is nice
<thumper> davecheney: am I right in thinking that len(nil) == 0?
<davecheney> thumper: depends on the type of nil
<davecheney> that is capital T type
<davecheney> i'm not really sure
<davecheney> len of a nil slice or map is 0
<thumper> ok, it is for a nil slice
<davecheney> in that case, yes, it len of a nil slice of map is 0
<davecheney> the of map is new in 1.1
<davecheney> no, sorry
<davecheney> it in 1.0
<davecheney> there is another simplification for map in 1.1
<thumper> davecheney: I have another branch, this one changes the way aliases for supercommands are handed
<thumper> handled
<davecheney> nice
<thumper> just running all the tests now prior to proposing
<davecheney> propose!!
<davecheney> screw that, proposing takes minutes
<thumper> now we get aliases shown in the generated help
<davecheney> tests will be done by then
<thumper> :)
<thumper> it takes about 90s to run all the tests here
<thumper> actually, I should time it again
<thumper> I found myself after lunch futsing around too much with the aliases in the supercommand
<davecheney> the work stealing algo for running multiple tests packages could be better
<thumper> in order to provide the right help
<thumper> ended up reverting it all
<davecheney> but butter still would not be taking 90 seconds for a test
<thumper> then changing the way it was done in a different branch
<thumper> if you ask for help on an alias, now it will give you help on the actual command and say at the bottom it lists all the aliases
<thumper> hmm lbox died on a launchpad api error
<davecheney> yeah, it does that
<davecheney> just do it again
<davecheney> i've learnt to keep my commit messages
<davecheney> in a text file
<thumper> lbox is proposing...
<thumper> https://code.launchpad.net/~thumper/juju-core/command-aliases/+merge/149461
<thumper> so... I'm on dinner tonight
 * thumper thinks
<thumper> I think we decided to go out for my daughter's birthday
<thumper> that makes it easy
<thumper> https://codereview.appspot.com/7370043
<davecheney> have a good one
<thumper> I will
<thumper> it is at my favourite resturant here
<thumper> soooo... good
<davecheney> how fortuitus
<rogpeppe> morning all
<rogpeppe> evening davecheney :-)
<dimitern> rogpeppe: morning
<davecheney> evening all
<dimitern> davecheney: hiya
<davecheney> rogpeppe: do you think we have the same set of issues that we had with bootstrapping precise from quantal
<davecheney> that we do for ppl wanting to do 386 -> amd64, and all the other permutations
<rogpeppe> davecheney: in this case, we just want to use 386 all down the line
<rogpeppe> davecheney: so i don't think the same problems arise
<rogpeppe> davecheney: although there may well be things i don't know about
<davecheney> rogpeppe: i think there are wrinkles
<davecheney> for example
<davecheney> _most_ ec2 instances are amd64
<davecheney> except for standard (?) and micro
<davecheney> so i think it is more compliated than saying 'i want this environment to have amd64 quantal machines'
<fwereade> davecheney, rogpeppe: this question is uppermost in my mind
<fwereade> davecheney, rogpeppe: and I *think* it's ok
<davecheney> fwereade: my initial response is to say 'juju only makes amd64 machines'
<davecheney> and ignore the arch on the host machine
<fwereade> davecheney, certainly we must ignore the arch on the host
<davecheney> so bootstraping from anything, osx runing on arm produces amd64 machines
<davecheney> fwereade: then that might solve rogpeppe 's question
<fwereade> davecheney, I think that the tighest constraint we have is what arches we have the tools built for
<davecheney> fwereade: i'd be relieved to say, for the future that we can predict, amd64 is all we do
<rogpeppe> davecheney: what about --upload-tools ?
<davecheney> rogpeppe: fuk
<davecheney> double shit
<rogpeppe> davecheney: that's my motivating case at the moment
<rogpeppe> fwereade: mornin' BTW. hope you're feeling a little better.
<fwereade> davecheney, I don't think there's a compelling reason to drop i386 support on ec2
<fwereade> rogpeppe, heyhey, pretty crappy tbh, I will be off and on
<davecheney> fwereade: apart from it being a wrinkle we don't need
<rogpeppe> davecheney: i'm not sure i see the problem.
<rogpeppe> davecheney: currently the logic chooses the image based on the arch and series of the tools found.
<davecheney> rogpeppe: it's just more perumutations that we don't need righ tnow
<rogpeppe> davecheney: i *think* all we need to do is provide a mongo db binary and it'll just work
<davecheney> rogpeppe: i don't think we need to do that
<davecheney> we should always request an amd64 image
<davecheney> if it happens that the development tools are 386
<rogpeppe> davecheney: not if the caller wants to upload tools
<davecheney> that isn't a problem on linux
<rogpeppe> davecheney: and have them run on the bootstrap machine
<davecheney> yeah, that works fine
<davecheney> just clamp the AMI request to amd64, job done
<rogpeppe> davecheney: ah, because you can always run 386 binaries ok
 * dimitern rebooting
<davecheney> yeah
<davecheney> going the other way, amd64 tools on a t1.micro will be sadface
<davecheney> but that is a bridge to cross at another time
<fwereade> davecheney, is that any worse than *anything* on a t1.micro? ;p
<davecheney> exactly
<davecheney> it's not the way the market is heading
<rogpeppe> davecheney: i'm not really sure i see the motivation though. we're going to need different mongo binaries sooner or later. why not just upload 'em now and avoid the special-case hacks in the code?
<davecheney> rogpeppe: --upload-tools is the hack
<davecheney> i'm fine with hackig it some more
<davecheney> rogpeppe: is there an issue for this work ?
<rogpeppe> davecheney: yeah, wait a mo
<rogpeppe> davecheney: https://bugs.launchpad.net/juju-core/+bug/1130209
<_mup_> Bug #1130209: we need a mongodb compiled for i386 <juju-core:New> < https://launchpad.net/bugs/1130209 >
<rogpeppe> davecheney: but that's fairly specific - i assumed it was the right solution
<davecheney> rogpeppe: mind if I rename that issue to what I see is the problem ?
<rogpeppe> davecheney: ok
<rogpeppe> davecheney: which is?
<davecheney> "juju should always request an amd64 AMI image"
<davecheney> actually, that will probably mean we can't boot t1.micros
<davecheney> but whatever
<fwereade> davecheney, I *think* that we can start any ec2 instance with AMD64
<fwereade> davecheney, but I'm not quite convinced this is an ok shortcut
<davecheney> fwereade: why not ?
<fwereade> davecheney, haven't people already used juju on ARM machines? even if they don't run the state server?
<rogpeppe> fwereade: i've made some replies to https://codereview.appspot.com/7326052/
<davecheney> fwereade: only as a client
<davecheney> my view of the crystal ball shows only environments containing amd64 machines
<davecheney> when highbank or calexeda come asking, we fix the problem then
<fwereade> davecheney, what about the arm stuff that had to be added to python juju for maas?
<rogpeppe> fwereade: i'm not sure what to do. i really don't have time to fix all the bugs currently - i can abandon the CL and just leave as an example for the GUI folks if you'd prefer.
<davecheney> fwereade: in the spirit of delivering 13.04, we have to leave the goal posts in the ground
<fwereade> davecheney, I do not believe I am the person trying to move them...
<rogpeppe> davecheney: what *is* the problem with just uploading 386 mongo binaries, BTW?
<davecheney> rogpeppe: well, 1, we don't have those binaries, so that is work
<rogpeppe> davecheney: i pointed you at some
<davecheney> 2, getting the deps in the archive is going to be an amazing ballache, so i'd rather no x2 it
<rogpeppe> davecheney: i don't understand - which deps in which archive?
<davecheney> rogpeppe: with respect, I have proposed a solution that has a low cost now, and a known cost in the future
<davecheney> we don't have to gold plate this
<davecheney> we just have to make it work on jam's dev machine, right ?
<rogpeppe> davecheney: if i'd had the credentials, i could have fixed this with a single s3 upload last night
<davecheney> rogpeppe: how can I send them too you ?
<davecheney> i'm more than happy for someone else to fix this
<rogpeppe> davecheney: i have the ones you gave me before, but they don't seem to work any more
<davecheney> yeah, niemeyer reset them a few times trying to get the permission junk working
<rogpeppe> davecheney: ah
<davecheney> rogpeppe: email me your public key
<davecheney> i'll bootstrap a machine
<davecheney> and leave them there for you
<fwereade> rogpeppe, the issue with that CL is that moving code from one wrong place to a different wrong place is of limited utility... is there some other command that is a bit more robust and doesn't need to be reimplemented inside state?
<rogpeppe> fwereade: well, surely the *place* is right - it's just the code is wrong?
<fwereade> rogpeppe, the code cannot be correct while it's in that place, though, can it?
<rogpeppe> fwereade: the code cannot be correct in any place!
<rogpeppe> fwereade: 'cos it's buggy
<fwereade> rogpeppe, yeah, but the bugs are intractable while it's outside the state package
<rogpeppe> fwereade: do you think we should just delete set and get support because they're currently wrong?
<fwereade> rogpeppe, I think that picking something that's wrong as a demonstration of how to do something right is problematic
<rogpeppe> fwereade: i agree that stuff needs to move into the state package, but i don't think i want to say to the gui folks - "yes you can make access to the command functionality through the API but you have to fix all our current bugs as you do so"
<fwereade> rogpeppe, ok, but... what will statecmd be, then, if not just a holding area for buggy code, soon to be replaced by better state API calls?
<fwereade> rogpeppe, this feels like inserting an extra step... you don't have to fix the bugs, but I don't see what the benefit is of adding another layer
<rogpeppe> fwereade: the benefit of the extra layer is at least we're not duplicating the buggy code
<rogpeppe> fwereade: because it needs to be called from two places now
<fwereade> rogpeppe, er, what? why would we be duplicating it if we put it in one place, ie in state?
<fwereade> rogpeppe, both those places use the state API though, right?
<rogpeppe> fwereade: the idea is that the functions in statecmd are *directly* equivalent to the command line commands, with all the parameter checking that implies.
<rogpeppe> fwereade: i thought about putting them in state too
<rogpeppe> fwereade: it depends whether we feel that almost all the code in juju/cmd should actually be done in state.
<rogpeppe> cmd/juju
<fwereade> rogpeppe, well that case obviously has to be; and offhand I can't think of one that shouldn't, can you?
<rogpeppe> fwereade: so what should i say to the GUI folks? hold off while we refactor cmd/juju ?
<fwereade> rogpeppe, I would say "put it in state, like this"... maybe I'm not understanding some of the constraints?
<fwereade> rogpeppe, blast, sorry, need a quick break, can we pick this up a bit later?
<rogpeppe> fwereade: ok
<fwereade> rogpeppe, hey, sorry to abandon you; I think I might be returning to bed for a while again soon, but we should finish this
<rogpeppe> fwereade: shall we G+?
<fwereade> rogpeppe, sgtm, will you start?
<rogpeppe> fwereade: ok
<rogpeppe> fwereade: ha, i've made a hangout, but the window has disappeared
 * fwereade tries
<fwereade> jam, ping: https://codereview.appspot.com/7307128/patch/1/6
<fwereade> jam, for your first comment, I thought it was covered by "// Environ constraints are not available before initialization." just above?
<fwereade> jam, and for the second: yes to the first bit, clarify please to the seconds
<fwereade> jam, I'm still pretty flaky today so am appearing and disappearing at random, just answer whenever and I'll see it when I see it
<dimitern> jam, mgz: standp
<rogpeppe> fwereade: i already have two LGTMs on this, but i'd really like your input too, as you've been following this stuff: https://codereview.appspot.com/7314116/
<fwereade> rogpeppe, am I right in thinking there's no api.IsNotFound?
<fwereade> rogpeppe, also, who should I be talking to to figure out the deal with yaml-in-the-gui?
<fwereade> rogpeppe, because I'm still pretty strongly -1 on the two-parallel-paths-not-checked-on-the server bit
<fwereade> dimitern, rogpeppe, TheMue: would one of you do a quick review on https://codereview.appspot.com/7331053/ please? it's near-as-dammit trivial and already has one LGTM
<rogpeppe> fwereade: hmm, sorry missed your remarks above
<rogpeppe> fwereade: from the top:
<rogpeppe> fwereade: yes, there's no api.IsNotFound - it's spelt api.ErrCode() == api.CodeNotFound instead
<fwereade> rogpeppe, how about something more like api.ErrHasCode(err, api.CodeNotFound), perhaps?
<fwereade> rogpeppe, just bikeshedding really, but I thought that IsNotFound was pretty handy
<rogpeppe> fwereade: in #juju-gui, bac or gary_poster are two possibilities
<fwereade> rogpeppe, cool, ty
<rogpeppe> fwereade: in ec2, i started with HasCode, but it turns out it's nicer to have a function that returns the error code.
<fwereade> rogpeppe, ok, fair enough on that, not sure I really like my suggestion
<rogpeppe> fwereade: for one thing, in tests, c.Assert(api.ErrCode(err), Equals, api.CodeNotFound) gives a nicer error message on failure
<rogpeppe> fwereade: also, you can do switch code := api.ErrCode(err); code {
<fwereade> rogpeppe, ok, sgtm, thanks :)
<rogpeppe> fwereade: np
<rogpeppe> fwereade: FWIW i don't think the two parallel paths thing is really a problem - i just documented that Config overrides Options.
<rogpeppe> fwereade: but there's an issue around that that i was discussing with niemeyer yesterday (in your absence)
<rogpeppe> fwereade: which is that yaml is strictly more expressive than the options in this context, because yaml can express null, but options cannot, only an empty string.
<fwereade> rogpeppe, feels like unnecessary nastiness with no real benefit to me... if we *have* to have the yaml path I think it's better to convert to yaml at the CLI end than to overload the params
<fwereade> rogpeppe, isn't an empty string "fall back to the default" in this context?
<rogpeppe> fwereade: if only js had decent yaml support... (if only yaml wasn't insane...)
<fwereade> rogpeppe, ha, yeah
<rogpeppe> fwereade: yes, but it could also be "set this to the empty string"
<rogpeppe> fwereade: and in yaml you can express that difference
<rogpeppe> fwereade: my inclination is to always make an empty string equivalent to null
<rogpeppe> fwereade: then the two paths are equivalent
<fwereade> rogpeppe, yeah, I think we kinda decided that a while ago, but that might just be in informal inference I made
<rogpeppe> fwereade: FWIW niemeyer thought that it was reasonable to have yaml be more expressive.
<TheMue> fwereade: You've got a +1.
<rogpeppe> fwereade: BTW if it wasn't for the js stuff, i would have no hesitation at all about dropping the yaml path
<TheMue> fwereade: And thx for your review, the change is proposed again.
<fwereade> rogpeppe, in that case I think we should drop Options -- it is more important to me that we drop one of them rather than it sepcifically be the yaml
<fwereade> TheMue, tyvm, I'll take a look in a bit
<rogpeppe> fwereade: i just had a little chat in #juju-gui - here's the result: http://paste.ubuntu.com/1690301/
<rogpeppe> fwereade: the thing is that if we drop Options, then, when they're not doing file upload, the gui will have to create well-formed yaml from the given options. perhaps that's not a problem, but i don't have an issue with there being two ways to specify the same thing, as long as the interaction between the two is well defined.
<rogpeppe> fwereade: alternatively, we could have two entry points: ServiceSet and ServiceSetYAML
<rogpeppe> fwereade: under the surface they'd invoke the same thing
<fwereade> rogpeppe, I think I'd rather separate them like that if nothing else
<rogpeppe> fwereade: ok, although i still don't really understand the problem
<fwereade> rogpeppe, or... they could just JSON it in the GUI, and that's still valid YAML, right?
<fwereade> rogpeppe, so long as we handle ""/null consistently
<rogpeppe> fwereade: true. i suppose my ickiness head goes "json-in-json-string, yeuch"
<fwereade> rogpeppe, I think that with the YAML requirement we're already way over that line
<rogpeppe> fwereade: that's only required if you want to upload yaml. i'd prefer not to pollute the clean path because of that requirement
<fwereade> rogpeppe, can you live with two separate calls?
<fwereade> rogpeppe, that seems to me like the least polluting approach possible ;)
<rogpeppe> fwereade: yeah, i'll do two separate calls.
<fwereade> rogpeppe, cool, tyvm
<fwereade> TheMue, I'm wondering about the 301s on paths with ..
<fwereade> TheMue, surely if anything's a 403, it's attempts to read/write outside the path?
<fwereade> TheMue, and a prefix of "../" acting the same as no prefix is a bit weird as well I think
<fwereade> TheMue, when listing I mean
<TheMue> fwereade: I've wondered too and it took me some time to discover it.
<TheMue> fwereade: It's a feature of the http daemon of Go.
<TheMue> fwereade: It resolves relative paths and sends a redirect to the client.
<TheMue> fwereade: And I also wondered about why using it with a pattern doesn't lead to a 301. Strange.
<fwereade> TheMue, hmm, where does it redirect to?
<TheMue> fwereade: I have to check now that the URL doesn't contain the environ name anymore.
<TheMue> fwereade: Before it has been from /environname/../foo to /foo
<TheMue> fwereade: But only a redirect, I client has to interpret it itself.
<fwereade> TheMue, hmm, would you look into that please? it should not have been doing that, that gets access to the files in the foo environment
<TheMue> fwereade: Now as it is change (w/o the environment as part of the URL) this can't happen. But the access when knowing a path or the port has already been open before.
<TheMue> fwereade: Right now we don't do any authentication on the storage.
<fwereade> TheMue, so where does localhost:60006/../foo redirect to?
<TheMue> fwereade: I have to look. But as I said: the redirect is no access. It's only a transformation of the URL (w/o validation if a path exists) and sending it to a possible client).
<TheMue> fwereade: If that does then react on it and does a request and the file doesn't exists it gets a 404.
<fwereade> TheMue, fwiw I think you'll find the cli will probably be losing direct environ access in the near future, so the security point may be moot
<TheMue> fwereade: But give me some minutes, now I'm interested in that redirect too.
<fwereade> TheMue, but nonetheless I would rather have a PUT to ../wherever/blah *fail* rather than just put *somewhere* ;)
<fwereade> TheMue, thanks
<TheMue> fwereade: Sorry, the Go server works differently. I have to look if it provides a kind of hook to get involved in the resolving.
<TheMue> fwereade: And security has nothing to do with the generated redirect, here we should introduce a real authentication feature.
<TheMue> fwereade: At least basic auth.
<fwereade> TheMue, what scenarios are we protecting against here?
<TheMue> fwereade: One moment, testing.
<fwereade> TheMue, I guess multiple users running local jujus on the same machine... but even then, each of them must be able to become root in order to start an env, right?
<fwereade> TheMue, but then people who can't start an env could still look inside and/or write to it, so, I guess, yeah: we should have some auth
<TheMue> fwereade: GET /../* is directly delivered (no redirect, as I said) as /*
<fwereade> TheMue, ok, that's fair enough I suppose; but GET /../foo redirects?
<TheMue> fwereade: Yeah, the storage backend is totally open right now, so beside using our own tool any wget/curl/scripting can simply access it in any way. And that's not good in the long run.
<fwereade> TheMue, it *is* a dev tool, not a production system... and, hold on, can we not restrict it to connections from localhost?
<TheMue> fwereade: /../foo* to /foo*
<fwereade> TheMue, so that one's a redirect?
<TheMue> fwereade: But as said, it is NO redirect. The redirect is in PUT (funnily) and has also been when we used the environ name in the path.
<fwereade> TheMue, ok, sorry: GET never redirects, but PUT and DELETE do?
<TheMue> fwereade: Restriction by IP should be possible, but not localhost, but the IP of the LXC containers.
<fwereade> TheMue, it's not clear that we ever want something in a container to use it as a Storage
<TheMue> fwereade: Hehe, ok, step by step.
<mgz> right, I was wondering about access control on the local provider storage too
<rogpeppe> fwereade: any chance of a review of https://codereview.appspot.com/7314116/ ? (it sounded like you were looking at it earlier - perhaps you just didn't publish your comments?)
<fwereade> TheMue, when should a container be able to get a Storage to work with?
<TheMue> fwereade, mgz: Please seperate those discussions, first redirect, later security.
<TheMue> fwereade: Once again, step by step.
<mgz> TheMue: I'll try to leave comments on the review
<rogpeppe> mgz: eventually, we could probably use admin-secret for security, if we cared much.
<mgz> rogpeppe: it's probably less security and more accidental clashing you care about for local
<TheMue> fwereade: First approach has been to use a URL like host:1234/<<environ>>/<<name>>.
<TheMue> fwereade: In that case a ".." leads to a redirect.
<rogpeppe> mgz: i don't think accidental clashing is a problem necessarily - we can store the address of the storage in the environ's directory.
<TheMue> fwereade: Now we use host:1234/<<name>>.
<TheMue> fwereade: Here /../<<name>> doesn't lead to a redirect, but the ".." vanishes.
<fwereade> TheMue, ok, with all verbs?
<TheMue> fwereade: But in case of a PUT, the Go HTTP daemon returns a 301.
<fwereade> TheMue, ah, ok, sorry
<TheMue> fwereade: Needed some time to get behind it as it screwed up my expectations and tests. :D
<fwereade> TheMue, ...and *that* redirects to..?
<fwereade> TheMue, /<<name>> ?
<TheRealMue> fwereade: But again, it doesn't deliver ata, it does no existence check, nothing.
<fwereade> TheRealMue, sure, that wasn't really on my mind -- I just wanted to know *what* it was doing :) maybe it would be good to document the details of what's going on under the hood, in the tests?
<TheRealMue> fwereade: Yeah, PUT /../foo redirects to /foo.
<TheRealMue> fwereade: I'll document it, yip.
<fwereade> TheRealMue, tyvm
<TheRealMue> fwereade: It's simply a "if contains("..") { transformAndRedirect(url) }. ;)
 * rogpeppe goes to lunch
<niemeyer> Yo
<dimitern> niemeyer: hey
<fwereade> niemeyer, heyhey
<fwereade> rogpeppe, mramm, TheMue: kanban?
<rogpeppe> fwereade: in 2 mins, no?
<TheMue> fwereade: Yep, in 2 mins.
<fwereade> rogpeppe, what's the deal with 208-simplify-config-tests? did that go anywhere, or was another variant chosen, or what?
<rogpeppe> fwereade: ah, i was reminded of that this morning. i haven't yet addressed jtv's final comment on that CL
<bac> rogpeppe: there are naming differences between what you landed as your first branch and the second branch that is under review, e.g. ServiceSetParams vs. SetConfigParams.  which is the one you'll be using?
<fwereade> rogpeppe, I would favour longer but more painfully explicit names, if possible
<fwereade> rogpeppe, sorry, my comments on the second don't apply so well in the light of the decusuins re the first
<rogpeppe> fwereade: i thought ServiceSet was ok
<rogpeppe> fwereade: (given that we've got "juju set")
<rogpeppe> fwereade: but you'd prefer ServiceSetConfigParams?
<fwereade> rogpeppe, ah, hmm, I think consistency there is actually quite good
<rogpeppe> fwereade: well, sure, but i'd have ServiceSetConfig to match
<rogpeppe> fwereade: i just thought that was on the verge of unnecessarily verbose
<fwereade> rogpeppe, yeah, indeed, I am newly taken with the benefits of ServiceSetParams/EnvironSetParams(?)
<rogpeppe> fwereade: great, thanks
<rogpeppe> bac: i changed the names as suggested in the review
<rogpeppe> bac: the second branch will change to match - i still need to do some work on it as per discussions before landing it
<bac> rogpeppe: ok, so the names in the landed branch are preferred.  thanks.
 * TheMue has a late lunch today, biab
<fwereade> rogpeppe, btw, is there a bug in LP for that `juju-log "--lol screw you"` issue?
<rogpeppe> fwereade: no, gimme 30s
<fwereade> rogpeppe, would you assign it to tim please, and suggest the SetFlags tweak we discussed?
<rogpeppe> fwereade: k
<rogpeppe> fwereade: hmm, do you know where the implementation of the jujuc commands is in the python?
<rogpeppe> fwereade: oh, found it
<fwereade> rogpeppe, sorry I missed you
<rogpeppe> fwereade: i can't see how the "we don't interpret flags" thing is consistent with the fact that there's a -l flag to juju-log
<rogpeppe> fwereade: i can't see how that works in the python
<rogpeppe> fwereade: (i'm looking in juju/hooks/commands.py, BTW)
<fwereade> rogpeppe, I would guess that the parser just ignores the stuff it doesn't recognise and passes it on in the args
<fwereade> rogpeppe, what does it use: optparse?
<rogpeppe> fwereade: argparse
<fwereade> rogpeppe, yeah, I think that has parse_known_args?
<rogpeppe> fwereade: it doesn't use that method
<rogpeppe> fwereade: it just uses parse_args
 * rogpeppe manages to see through *some* of the python magic
<fwereade> rogpeppe, ah, wait, it gets a bunch of stuff from juju/hooks/cli.py as well I think
<rogpeppe> fwereade: yeah, that's the place that calls parse_args
<rogpeppe> fwereade: in the __call__ magic method
<mramm> anybody have a link to tim's gap analysis doc?  I can't seem to find it in my google drive.
<rogpeppe> fwereade: hmm, i think this might be magic too:         self.parser.add_argument("message", nargs="+")
<rogpeppe> fwereade: perhaps that "+" signifies "anything remaining"
<fwereade> rogpeppe, very probably
<rogpeppe> fwereade: so "juju-log -l INFO foo" will send a "foo" message at info level, but "juju-log -z foo" will log "-z foo" at normal level
<rogpeppe> fwereade: if that's true, it's really not very nice and breaks all our arg parsing rules.
<fwereade> rogpeppe, sorry, my dad just arrived from england, was saying hello
<rogpeppe> fwereade: np
<fwereade> rogpeppe, I agree that that is not very nice
<rogpeppe> fwereade: am just trying to understand argparse
<rogpeppe> fwereade: "+" just says any remaining args - it still seems to give an error when a flag isn't recognised
<fwereade> rogpeppe, hmm, maybe it has special handling for "--" followed by "something weird"
<rogpeppe> fwereade: maybe - i'll try that next
<rogpeppe> fwereade: yup, that's right. yulk
<rogpeppe> fwereade: here's my testbed: http://paste.ubuntu.com/1691047/
<rogpeppe> fwereade: sample: http://paste.ubuntu.com/1691052/
<rogpeppe> fwereade: looks like if you've got a space in the arg it's treated as if it can't be a flag
<fwereade> rogpeppe, ok, I guess that makes sense, but still, eww :)
<rogpeppe> fwereade: no, that's not true either
<rogpeppe> fwereade: if there's a space in the arg, it's treated as a flag *only* if the prefix doesn't match a flag
<fwereade> rogpeppe, wait what? I don;t think that fits with what you showed me
<fwereade> rogpeppe, treated as an arg?
<rogpeppe> fwereade: so "tst.py '-z arg'" goes through ok but "tst.py -z ' arg' fails
<rogpeppe> fwereade: which seems so so wrong to me
<fwereade> rogpeppe, I dunno, it actually seems pretty sane... but it's annoying to have to replicate all the magic
<fwereade> rogpeppe, it's not *nice* but it is making an effort to do the Right Thing even in the face of crazy args like "--> roflcopter"
<rogpeppe> fwereade: it seems wrong to me because in general i'd think that -z$arg and -z "$arg" should be handled exactly the same
<fwereade> rogpeppe, yeah, reasonable perspective
<rogpeppe> fwereade: what if the create arg as "-lINFO" ?
<rogpeppe> s/create/crazy/ s/as/was/
<fwereade> rogpeppe, well it *is* meaningless anyway because we dropped all the logging levels :/
<rogpeppe> fwereade: ha
<fwereade> rogpeppe, gtg for a bit, back later
<rogpeppe> fwereade: ok
<rogpeppe> fwereade: https://bugs.launchpad.net/juju-core/+bug/1130771
<_mup_> Bug #1130771: juju-log is not compatible with python version <juju-core:New> < https://launchpad.net/bugs/1130771 >
<fwereade> rogpeppe, responded
<TheMue> niemeyer: Your ubuntufinder.com is quite cool.
<rogpeppe> fwereade: i wonder if the argparse semantics are actually documented anywhere
<dimitern> niemeyer: yeah, pretty cool UI with these rolling radio buttons / shelves :)
<rogpeppe> fwereade: i had a go at fixing that live test failure yesterday, and got some way, but it still fails. does this look reasonable to you? http://paste.ubuntu.com/1691273/
<fwereade> rogpeppe, hmm, that looks like it ought to work
<rogpeppe> fwereade: unfortunately the provisioner never actually shuts down the instance. i'm wondering if i should remove the machine too.
<fwereade> rogpeppe, no, that's the provisioner's job... does it really not do it? I could have sworn it did
<rogpeppe> fwereade: yeah, i thought so too
<fwereade> rogpeppe, if not then, well, this is why it was bad to invent our own shutdown process in those tests ;p
<rogpeppe> fwereade: BTW, i *think* that Machine.Destroy should not require a Refresh if the last view of the machine had assigned units.
<rogpeppe> fwereade: agreed
<fwereade> rogpeppe, we should try regardless of the latest known state? not convinced, but go on
<rogpeppe> fwereade: yeah, because it's what's actually out there in the state that's important AFAICS
<rogpeppe> fwereade: in the above loop, there's no real reason we need to keep on refreshing while trying Destroy periodically
<fwereade> rogpeppe, I would think it more usual to watch, refresh on change, and then use that -- recent -- state as a basis for making further decisions on what to do
<rogpeppe> fwereade: in this case, there's nothing to watch
<rogpeppe> fwereade: or... maybe there is
<rogpeppe> fwereade: well, anyway, the in-memory state has no bearing on whether we can or can't call Destroy
<fwereade> rogpeppe, a machine watch will observe those changes
<rogpeppe> fwereade: yeah
<fwereade> rogpeppe, it has plenty of bearing -- once we've figured out whether it's a sane request, we decide whether or not to even call anything, all based on in-memory state
<rogpeppe> fwereade: why should we? the in-memory state doesn't tell us anything about whether the machine has units *now*, no?
<mgz> bah, why did I type images, I meant instance-types
<mgz> terminology is hard
<rogpeppe> fwereade: hmm, except, i guess, when there are *no* units and the machine is dying
<fwereade> rogpeppe, no, but if you're interested we'll tell you when it changes... why accommodate impatient hammering of the API
<rogpeppe> fwereade: i'm not sure why {wait for change; refresh; destroy} is better than {wait for change; destroy}
<rogpeppe> fwereade: it certainly surprised me when i discovered it was necessary.
<fwereade> rogpeppe, because if you didn't refresh then you obviously have no basis for assuming it's destroyable ;p
<rogpeppe> fwereade: i know it changed :-)
<rogpeppe> fwereade: the overhead of calling destroy is probably not far off that of calling refresh. or... maybe it is actually much cheaper in fact.
<fwereade> rogpeppe, define cheap... destroy will potentially lock the service document, won't it?
<rogpeppe> fwereade: yeah, i guess so
<fwereade> rogpeppe, ah wait that's only for a unit, doesn't apply
<rogpeppe> fwereade: oh yes, not for a machine
<fwereade> rogpeppe, I somehow switched to thinking about units
<rogpeppe> fwereade: anyway, i think of mutating operations on the state as write-through. i found it strange that one failed only because of in-memory state.
<rogpeppe> fwereade: (even though the actual state would have allowed the operation)
<fwereade> rogpeppe, I've been thinking of mutating operations on the state as scary, and preferring to avoid them unless I'm as sure as I can be that they'll go through
<fwereade> rogpeppe, because it is not easy to determine by inspection just what docs will be involved in a given txn, and how many other txns get clipped by it
<rogpeppe> fwereade: it's a pity we can't even set a machine to Dying when it has units - then having no units with a dying machine would be definitive
<fwereade> rogpeppe, that's a known bug that we officially do not care enough about to fix by 13.04
<fwereade> rogpeppe, if the provisioner's not actually cleaning up the machine, that is an issue of vastly greater magnitude ;)
<rogpeppe> fwereade: true 'nuff
<frankban> hi all, does the current juju-core trunk support default-series? I have precise in my env configuration, but nodes are created using quantal.
<rogpeppe> fwereade: do you know about the above question?
<niemeyer> TheMue, dimitern: Cheers!
<rogpeppe> fwereade: first watcher in the API implemented: https://codereview.appspot.com/7390043/
<fwereade> rogpeppe, heh, you would have been the person I asked
<fwereade> frankban, so the charm you're using is definitely a precise one?
<rogpeppe> fwereade: darn. i should really know :-)
<fwereade> rogpeppe, I am up to my elbos in that stuff at the moment so the behaviour will doubtless change somewhat over the next couple of says
<fwereade> rogpeppe, but it does *kinda* look like every machine is started with the series/arch of the machine that launches it :/
<rogpeppe> fwereade: it's started with the series/arch of whatever tools it can find, i think
<frankban> fwereade: yes, it's the juju gui charm (deployed from local repository). however, the bootstrap node is also quantal
<rogpeppe> fwereade: anyway, gotta go. we're packing the car up, off to the Lakes for some snowy hills
<fwereade> rogpeppe, enjoy
<bac> bye rogpeppe.  you around tomorrow?
<rogpeppe> fwereade: will do. have a great rest of week. should be in contact sporadically by email
<rogpeppe> bac: no, sorry. away for rest of week.
<bac> rogpeppe: have fun!
<rogpeppe> bac: will try me best :-
<rogpeppe> )
<fwereade> frankban, ok, that just sucks profoundly... but, yeah, I don't see how that's meant to actually work
<fwereade> frankban, it seems that the machine we start is to all intents and purposes random
<fwereade> frankban, good thing I am working on that right now
<frankban> fwereade: cool, thanks
<rogpeppe> see y'all monday!
<bac> hi, i've put a small branch up for review at https://codereview.appspot.com/7401043/
<thumper> bac: looks good to me, but I have no confidence in my ability to review it yet
<thumper> bac: particularly to know if it works or is even right :)
<thumper> Q) an uninitialized string in a struct has a value of "" ?
<bac> thumper: yes
<thumper> cool...
<bac> thumper: thanks for looking.  since it is just code reorg and the previously existing tests still pass that says something (though the tests aren't much)
<thumper> hopefully within a week or so I'll feel happier commenting on merge proposals
<bac> thumper: is the requirement two reviews?
<thumper> yeah
<davecheney> thumper: will review your CL in two secs
<thumper> sure
 * thumper afk for lunch
#juju-dev 2013-02-21
<thumper> davecheney: what would your recommendation be around wanting a max that works with ints?
<davecheney> thumper: what is the question ?
<thumper> davecheney: well, math.max works on float64
<thumper> but I'm trying to find the longest int
<davecheney> you'll find lots of
<davecheney> func max(a, b int) int { if a > b { return a } return b } 's
<davecheney> in the codebase
<davecheney> that is the current standard
<thumper> I just realized that codereview.appspot was sending email to my gmail account (that I don't actually read)
<thumper> and I can't configure it to send email to my normal address
 * thumper chalks up another mark against rietveld
<thumper> davecheney: so why did your last comment not go to the merge proposal?
<davecheney> thumper: i have no idea
<davecheney> to be honest, when I joined, the attitude was to ignore the MP and use Rietveld
<davecheney> the comment should arrive on the MP evnetually, it was cc'd on the review
<davecheney> so you should have got the comments via the route of
<davecheney> rietveld -> mp -> gophers group -> you
<thumper> it is faster...
<thumper> rietveld -> mp -> me (as I proposed the merge)
<thumper> but it doesn't arrive on the mp
<thumper> since I wrote all that email shit with abentley, I know how it works
<thumper> oh I know what it is
<thumper> the email address that it is coming from is not linked to any known launchpad user
<thumper> so it drops them on the floor
<thumper> since my gmail account isn't linked to my LP user, LP ignores all email from it
<davecheney> bzzt
<thumper> obviously roger has linked his gmail to LP user
<thumper> his default email address for the LP user is his canonical one
<thumper> which is what the outgoing MP email is sent as
<davecheney> maybe, he was winging for months that he wasn't getting any updates
<thumper> that is what it is
 * thumper knows it
<thumper> so what I have to do is to add my google mail address to LP
<thumper> and so does every other user
<thumper> which sounds crackful
<thumper> would be better if rietveld would allow me to configure my email address
<davecheney> hmm, that might be unpossible
<davecheney> canonical.com is a gapps domain
<davecheney> but the email portion is disabled
<davecheney> to send/recieve as your canonical identity you would need a google identity on canonical.com
<thumper> davecheney: OK, my question around this latest MP is that I have four different LGTM calls, but there is still a little contention around the init command AFAICS
<davecheney> fuckem
<davecheney> it's called source control
<davecheney> you can always propose another change
<thumper> heh
 * thumper emails juju-dev with this email revalation
<thumper> davecheney: so you reckon submit this alias branch for merging now?
<davecheney> thumper: +1
<thumper> kk
<davecheney> what is the worse people can do ?
<davecheney> they are miles away
<thumper> well... from past experience, the worst they can do is revert the merge, and yell publicly on the mailing list at how shit you are
 * thumper says mostly in jest
<davecheney> you don't need to commit code for that
<davecheney> :P
<thumper> fucking conflicts...
 * thumper fixes
 * thumper goes to find his child
 * thumper is confused
<thumper> davecheney: ping
<davecheney> ack
<davecheney> thumper: ack
<thumper> davecheney: nm, found that go build doesn't report all the errors
<thumper> which is why  I was confused
<thumper> go test found them
<davecheney> ok
<davecheney> offline for 5-10 mins
<davecheney> rebooting + MOAR RAM!
<davecheney> mmm, 8gb
<davecheney> i had forgotten that I had donated some to my other machine a while back
<davecheney> and only remembereed that when the said donated ram failed
<TheMue> Morning
<fwereade> TheMue, morning
<fwereade> TheMue, can you think of any reason we have the --upload-tools flag on bootstrap/upgrade, instead of just an upload-tools command that puts stuff into the appropriate "public-bucket" (wtf? why not "tools-bucket"?) for the environment?
<TheMue> fwereade: First, yeah, tools-bucket is more clear than public bucket. +1 on that. ;)
<fwereade> TheMue, do you recall anything else that it's used for?
<TheMue> fwereade: I think the basic idea has been to upload the tools "on the fly", but I don't know if it's really better than having an explicit command for it.
<TheMue> fwereade: Can't remember the discussion which led to this decision.
<fwereade> TheMue, I think it's way back before I even started on go
<TheMue> fwereade: Yip, it's in there for a long time. Is our IRC archive searchable?
<fwereade> TheMue, I think it's just cargo-culting from python tbh :(
<fwereade> TheMue, (the public/private buckets, anyway)
<TheMue> fwereade: Think so too. In the beginning we've ported much 1:1.
<fwereade> TheMue, the tools stuff was done round about lisbon 1 but I wasn't closely involved... guess I should talk to niemeyer this pm, see if he has context I lack
<TheMue> fwereade: I'm sure he can answer your question.
<TheMue> fwereade: http://irclogs.ubuntu.com/2012/05/01/%23juju-dev.txt
<frankban> hi fwereade: is there a bug for the default-series problem?
<fwereade> frankban, not yet, I'm looking into it more closely just now
<frankban> fwereade: ack thanks
<fwereade> frankban, quick check: were you using --upload-tools? because that seems to work in quite a surprising way
<frankban> fwereade: yes
<fwereade> frankban, right, yeah, ISTM that upload-tools is crack, because it just forces everything to run with the tools that have been uploaded regardless
<frankban> fwereade: so it takes the series I am running in the local machine?
<fwereade> frankban, yeah, and it looks like it's totally infectious
<frankban> fwereade: so, in theory, if I compile and run juju in a precise lxc it should work...
<fwereade> frankban, I have a nasty suspicion that even without upload-tools it will force the series/arch of the bootstrap node onto everything it provisions, but I'm still verifying that
<fwereade> frankban, hmm, yes, worth a try
<frankban> fwereade: I will
<fwereade> frankban, you will still be stuck with whatever you uploaded for absolutely everything you deploy, but at least you should be able to progress
<mariusko> Hi, where should charm settings be saved?
<fwereade> mariusko, I'd expect charm settings to be declared in the charm's config and set individually for each service running the charm
<fwereade> mariusko, what sort of settings are you thinking of?
<mariusko> fwereade: these are more locally cached ones
<mariusko> actually, they are from the relation to mongodb, but they needs to be reused in config-changed hook
<mariusko> I could not find an easy way to find it there without knowing the unit number
<mariusko> When there is just one relation possible to mongodb, I would expect to be ablo te get those relation config options easily
<fwereade> mariusko, there's a relation-list tool that will tell you what units are on the other side of the relation
<mariusko> I.e. in this case I would expect to write the example "user=`relation-get -r db:42 user mysql/0`" as "user=`relation-get -r db user mysql`" if there is a one-to-many relationship from mysql
<fwereade> mariusko, there's `relation-ids <name>` to tell you what relations exist; `relation-list <id>` to tell you what units are in each relation; and then you can `relation-get <id> <unit>`
<fwereade> mariusko, except I've done the syntax completely wrong, sorry
<mariusko> fwereade: ok, let me see if it can solve the problem. Is there a way to debug these commands interactively?
<fwereade> mariusko, what version of juju are you using?
<mariusko> They did not work in "juju debug-hooks"
<fwereade> mariusko, ok, you're using python... and that would have been what I suggested next
<mariusko> 0.6.0.1+bzr616-0juju2 from the ppa
<fwereade> mariusko, do you have a transcript of what didn't work by any chance?
<mariusko> fwereade: "juju debug-hooks testapp4/0", then "relation-ids" gives "No JUJU_AGENT_SOCKET/-s option found"
<fwereade> mariusko, does any hook tools work at all?
<fwereade> mariusko, eg juju-log?
<mariusko> nope, just when run automatically
<fwereade> mariusko, huh, that rather sounds like debug-hooks is just plain broken
 * fwereade tries to think who might be up to date with the python and awake at this hour
<fwereade> mariusko, you might be able to iterate *reasonably* quickly if you keep upgrading your config-changed hook from a local repo
<mariusko> fwereade: pushed the current code: https://code.launchpad.net/~mariusko/charms/precise/node-app/lp1123939_procfile_support
<mariusko> Caching now happens in "/etc/juju_nodejs_app_${app_name}_mongodb.env"
<fwereade> mariusko, I'm not quite sure how well that will work when there are multiple mongodbs
<fwereade> mariusko, it seems like every unit of node_app will just store the most-recently-changed mongodb server?
<mariusko> I think there only could be one associated with one node app
<fwereade> mariusko, I'd better go take a look at the mongodb charm ;)
<mariusko> Hmm japp, "app_name" is set by the user, so it could be other charm instances with the same app_name...
<mariusko> Maybe service name should have been included
<mariusko> That would also break some of the existing stuff in the charm too
<mariusko> Maybe "$JUJU_SERVICE" should have been used instead
<fwereade> mariusko, that should definitely be unique, yeah
<fwereade> mariusko, and it does rather look as though it is just storing the most-recently-changed info
<fwereade> mariusko, which I think might be a problem is the most-recently-changed on ever goes offline
<mariusko> there are a lot of issues in the charm japp
 * TheMue is at lunch
<mariusko> it looks more like in a demo state now
<mariusko> Anyway, there should just run one instance on each machine anyway
<fwereade> mariusko, yeah, I'm not too bothered by the machine-sharing issue right now
<fwereade> mariusko, I think it would be noticeably better if it maintained an up-to-date seed list (I'm pretty sure the node.js drivers can work with replicasets, right?)
<mariusko> but if the mongodb dies, I hope that juju fires up a new one and then run the relation hook again to set the new info?
<fwereade> mariusko, if you've got 3 in a replicaset and the last one to change goes down, I fear that the node apps will only try to connect to that one and fail ignominiously
<mariusko> Seems it reads it: "replset=`relation-get replset`"
<fwereade> mariusko, that's just a string
<fwereade> mariusko, taken straing from the config
<fwereade> mariusko, AFAICT, anyway
<fwereade> s/straing/straight/
<mariusko> haven't started playing with mongo yet, so I don't know much about it
<mariusko> It is now set to ""myset"
<fwereade> mariusko, I'm having some trouble spelunking through the mongodb charm -- it is certainly doing sane things in the replset relation hooks
<mariusko> I thought the relationship was many nodeapp->one mongodb->many mongodb nodes
<fwereade> mariusko, building up host:post,host:port lists... but I haven't figured out if/how they pass them on to database clients
<mariusko> I have a replica-set relation from mongodb
<fwereade> mariusko, that relation looks like it's being sensible -- ie it's causing the individual mongos to keep track of their replica sets, which is good
<fwereade> mariusko, so if you successfully connect to any one, your driver should be able to figure out the current rs state and go from there
<fwereade> mariusko, but if a node app only has one mongo address stored, and that address stops working for any reason, I don't think it'll be able to connect
<mariusko> fwereade: firing up one more mongo unit now to see what happens
<mariusko> But it was like that before my hacking too :)
<mariusko> Japp, the mongodb IP changed to the last added mongodb node
<fwereade> mariusko, sure, sorry, I think I've derailed you quite badly :(
<mariusko> fwereade: japp, it seems like the client should list all nodes when connecting: "MongoClient.connect("mongodb://localhost:30000,localhost:30001/integration_test_?w=0&readPreference=secondary", function(err, db) {"
<mariusko> At least more than one
<fwereade> mariusko, re uniqueness, incidentally, it's more-or-less ok to store that sort of cached information inside the charm dir
<fwereade> mariusko, the important bit is that if it's stored in the charm dir, it's for the consumption of the *charm* (which can then use it to write config files in /etc or wherever, in response to hooks)
<mariusko> If all should be listed, it is maybe easier to try to do it properly and fetch all of them
<fwereade> mariusko, if it's for the consumption of the service in any way -- eg an actual config.js, definitely don't store it in the charm dir
<fwereade> mariusko, +1 to that, I think
<fwereade> mariusko, no sure how to handle connections to multiple mongodb *services* though... that might be a case where the "limit" setting on the charm would be helpful
<fwereade> mariusko, if only limit restrictions were actually implemented :/
<mariusko> Hehe, juju looks a bit in alpha state at this time
<mariusko> But seems to work in simple cases for test/development purposes
<mariusko> Hope it will change for Raring
<fwereade> mariusko, hopefully we'll have something solid for you... but I'm not sure limit will make the cut
<fwereade> mariusko, on the plus side, I think that it's reasonably clear that the tools to get node_app doing the right thing are in place
<fwereade> mariusko, it takes a little while to get used to charm-writing though
<mariusko> fwereade: tried to describe the problem here: https://bugs.launchpad.net/charms/+source/node-app/+bug/1131188
<_mup_> Bug #1131188: Does not support multiple mongodb units <node-app (Juju Charms Collection):New> < https://launchpad.net/bugs/1131188 >
<fwereade> mariusko, thank yu, that's extremely helpful
<mariusko> Japp, Heroku etc. seems to have a more complete service just now, but AFAIK it does not allow hacking on it like Juju :)
<fwereade> mariusko, I don't want to bash those at all, they do what they do just as they should, but we're not trying to do quite the same things :)
<mariusko> Sure, those services also have their own proprietary tools so it is harder to change cloud providers. Sent a merge requst
 * dimitern lunch
<bac> hi jam, thanks for the review.
<bac> i don't understand your comment in the README about --upload-tools
<bac> even if you use --upload-tools, i think it will complain if it sees a juju-origin
<jam> bac: for juju-core you can do 'juju bootstrap --upload-tools' which is how you get the 'current' version of tools available for things to use.
<jam> With Python juju
<bac> so for people coming from pyjuju with a pre-existing environments.yaml they will see that complaint
<jam> you had to specify a source
<jam> like ppa
<jam> bac: sure, my point is, if someone was *using* a custom source for juju (like juju-origin: ppa) they most likely want "juju bootstrap --upload-tools".
<bac> jam: gotcha
<jam> I was mentioning it as "do we want to include a side reference so people can figure out where to get similar functionality"
<jam> though I imagine people tend to have that line because it was the magic voodoo that made things work
<jam> (because precise has an old version of juju that is incompatible with lots of python-juju clients)
<bac> jam: with the two positive reviews am i free to make the changes requested and then submit or do i need to re-propose?
<bac> for this one i will definitely re-propose.  just asking about the expectation for this project.
<jam> If you have 2 LGTM, then submit (though you should respond to make it clear that you've done the requested actions, etc.)
<fwereade> bac, generally we take the string "LGTM" to be the indicator of sufficient positivity, so I'm not quite sure dfc's counts
<fwereade> bac, I think his "weird API" comment has some legs... not because the API is weird, IMO it's a perfectly sensible one, but I'm not sure how nicely it will play with rog's RPC magic
<fwereade> bac, jam: I'm also a little bit reluctant to recommend --upload-tools too loudly, but I have not yet figured out whether it breaks juju *enough* worse than it already is re series/arch selection
<fwereade> bac, jam: and I am afraid I've just been called to lunch
<fwereade> niemeyer, heyhey
<niemeyer> fwereade: Heya
<fwereade> niemeyer, I liked your ubuntu finder sketch :)
<dimitern> niemeyer: hey
<niemeyer> fwereade: Neat :)
<niemeyer> dimitern: Heya
<bac> dimitern: hi, thanks for the review.  i removed the 'cobzr branch -b' part b/c i found it did not work.  does it work for you?
<dimitern> bac: yw, actually I never used it like that, I always use bzr checkout -b branchname (that's with cobzr)
<dimitern> that's maybe worth mentioning (if it's not there already)
<bac> dimitern: i'll try that
<TheMue> re
<TheMue> Argh, my system crashed. *grmpf*
<dimitern> fwereade: ping
<fwereade> dimitern, pong
<dimitern> fwereade: i couldn't find anywhere Service.SetCharm is used, except for a few tests
<fwereade> dimitern, it will be used by upgrade-charm
<dimitern> fwereade: but a lot of the things it has to do are uniter operations
<fwereade> dimitern, its current total lack of safety is the primary reason for the lack of upgrade-charm
<fwereade> dimitern, sorry, restate?
<dimitern> fwereade: e.g. downloading a charm to see what it implements, its config, etc.
<fwereade> dimitern, the uniter should already handle those changes once they've happened
<fwereade> dimitern, the upgrade-charm story is all about making sure those changes are sane
<fwereade> dimitern, so that the uniter will itself respond sanely ;)
<dimitern> fwereade: so all the things you described about changes to Service.SetCharm (well, most of them) will in fact happen in the uniter, before calling it
<fwereade> dimitern, I don;t think so -- can I talk properly in a mo?
<dimitern> fwereade: what, hangout?
<mgz> dimitern: if you're not hanging out yet, can you hop on mumble quickly and tell me if my settings on this box are working okay?
<dimitern> mgz: sure
<fwereade> dimitern, ping
<fwereade> dimitern, sorry
<dimitern> fwereade: pong
<fwereade> dimitern, quick hangout?
<dimitern> fwereade: ok, i'll send you a link
<fwereade> dimitern, with you in 2 mins
<jtv> Is anyone else having trouble running "make check" in pyjuju?
<jtv> And "make review" etc?
<dimitern> fwereade: it seems there's no clean way to stop a watcher without a panic :(
<dimitern> fwereade: am I to expect that? and check for a panic in the tests?
<fwereade> dimitern, hmm, sorry good point: that's a line saying watcher.MustErr(relationsw) or something?
<fwereade> dimitern, change that bit
<dimitern> fwereade: yeah, that one
<fwereade> dimitern, that's checking that no sneaky git stops the watcher underneath us; now that we're deliberately stopping it you should be fine with an err or nil
<fwereade> dimitern, maybe only start the new watcher once the old one has stopped? that might actually be neatest
<dimitern> fwereade: :)
<fwereade> dimitern, to be clearer: if there's an err, return it; if it's nil, start a new one
<dimitern> fwereade: hmm
<fwereade> dimitern, that could probably use a comment though, it's a bit subtle, and don't forget to fix up the defer stop (or defer a new one)
<dimitern> fwereade: yeah, ok
<dimitern> fwereade: i was thinking exactly of the defer
<dimitern> fwereade: so it'll call MustErr instead
<fwereade> dimitern, hmm, no, I don;t think you want MustErr at all for relationsw
<fwereade> dimitern, I think you probably want a defer that stops the current value of relationsw, rather than snapshotting it
<dimitern> fwereade: ISTM the only place MustErr is called on relationsw is in the <-Changes() case
<fwereade> defer func() {relationsw.Stop()}() rather than defer relationsw.Stop()
<dimitern> fwereade: ah! got you - yeah, it'll be different
<dimitern> fwereade: so filter.go: 223 that if should be gone
<dimitern> oops 213
<dimitern> no
<dimitern> sorry, finally 221 :)
<dimitern> on the relationsw
<fwereade> dimitern, yeah, around 222: if err == nil { relationsw = service.WatchRelations() } else { return err }
<fwereade> dimitern, something like that
<dimitern> fwereade: won't that screw up the defer above?
<dimitern> fwereade: ah, no - because we'll be out already!
<fwereade> dimitern, depends if relationsw is naked or only evaluated inside the deferred func
<fwereade> dimitern, if it's `defer relationsw.Stop()` then it's *that* specific relationsw that will be stopped; if it's inside a func it'll take the value of relationsw at the time it's finally executed
<dimitern> fwereade: no, I mean I though I saw a inf loop there, but then I realized <-Changes() and the restarting won't happen again while in the defer
<fwereade> dimitern, yeah, exactly, once we're in the defer we can't go back :)
<dimitern> fwereade: neat :)
<dimitern> fwereade: and I can get the err from relationsw.Err(), right?
<dimitern> fwereade: right, so to test the watcher was restarted, I should stick a change just before the upgrade is fired
<dimitern> fwereade: or you don't think this needs testing?
<dimitern> fwereade: sorry it seems you dropped off
<jtv> Could anyone give me a review for these Makefile changes?  https://code.launchpad.net/~jtv/juju/makefile-fixups/+merge/149907
<bac> .
<bac> fwereade: when you have a moment could you do a second pass on my branch?  if you think it is ok do i need to wait for dfc to re-review too?
<bac> fwereade:  https://codereview.appspot.com/7401043/
<fwereade> bac, sure, just a mo
<fwereade> bac, LGTM, couple of trivial typos
<fwereade> bac, I think you're fine re dfc, you did address his point
<bac> fwereade: thanks
<_thumper_> mramm: ok, at home now, hangout?
<_thumper_> mramm: needs to be personal one though
<_thumper_> as the laptop is upgrading :)
<mramm> ok
<mramm> shoot me an invite?
<_thumper_> I'll try...
<BradCrittenden> fwereade: i have made the final changes.  i cannot submit the branch b/c i'm not in ~gophers.  can you merge it for me?
<_thumper_> mramm: the ipad app won't let me add you :(
<_thumper_> don't know why
<mramm> ok
<mramm> let me try inviting you
<_thumper_> ok
 * _thumper_ tries to recall which image is the personal one
<mramm> invite sent
<_thumper_> which did you use?
<_thumper_> I don't see it
<mramm> though perhaps to your canonical acount
<_thumper_> perhaps invite the other me :)
<mramm> looking for your personal...
<gary_poster> Hey mramm, could you please add ~juju-gui to ~gophers so we can propose?
<gary_poster> mramm alternatvely I can give you individual people, as you wish
<mramm> _thumper_: trying again, seems that I lost google hangout
<_thumper_> ack
<_thumper_> mramm: you disappeared again
<mramm> hmm
<mramm> google hangout is not my friend today
<mramm> trying again with another browser
<mramm> yea, nothing working, trying a reboot
<mramm> be back in 2 min
<thumper> I home mramm isn
<thumper> isn't having shell issues too
<thumper> s/home/hope
<thumper> I have a horrible feeling that this day is going to be a write-off
<thumper> I hope not...
<hatch> arrrrgggggggg
 * hatch smashes things in hope that it solves his problem
<thumper> hi mramm
<thumper> mramm: long two minutes :)
<mramm> yea
<mramm> computer hung on reboot
<mramm> :(
<thumper> :(
<thumper> but you got a shell ok?
<mramm> eventually
<mramm> not sure why but it just took forever to get there
<mramm> but then all is good
<thumper> mramm: are you going to try a hangout again?
<mramm> thumper: I'm in a hangout with dave at the moment
<thumper> mramm: ok
<mramm> thumper: you still around?
<davecheney> thumper: when you get done with mramm, can we have a chat ?
#juju-dev 2013-02-22
<thumper> hi davecheney
<thumper> laptop is still upgrading, but I am around
<thumper> and have skype available to me
<davecheney> thumper: you said you had a race when X was starting
<davecheney> I think my machine has developed that as well
<thumper> what do you get?
<davecheney> bootup
<davecheney> some text on the screen
<davecheney> have to alt-f1 and restart lightdm to get a login
 * thumper nods
<thumper> that's it
<davecheney> wonderful
<thumper> do you have an ssd?
<davecheney> yeah
<davecheney> wasn't a problem with 4gb
<davecheney> but with 8gb
<davecheney> i must be slightlt faster
<thumper> ah... I have 16
<davecheney> is there a bug that I can whine on ?
<thumper> damn those high spec laptops
<thumper> davecheney: poke robert_ancell in #ubuntu-desktop
<davecheney> thumper: ok, can I say you told me to talk to him ?
<thumper> sure
<davecheney> kk
<davecheney> thumper: i flashed my n7 to the phablet this morning
<davecheney> that is why I was calling
<thumper> oh?
<davecheney> i wanted to get your feedback on it
<thumper> I have some thoughts
<thumper> but I haven't played with the tablet build
<davecheney> lets try skype
<thumper> kk
<davecheney> hello
<davecheney> i am still here
<davecheney> i can hear you
<davecheney> you cannot hear me
<thumper> no
<thumper> did you bump mute?
<davecheney> this is becoming farcical
<davecheney> lets call it a day
<thumper> ok
<thumper> I'm tempted to throw in the towel completely and get a beer
<davecheney> ok, lets retire hurt to our respective corners
<davecheney> nearly time for lunch in AU
<thumper> heh
<davecheney> i shall continue to watch you troll #ubunut-desktop
<davecheney> thumper-afk: i'm going to be working remotely from the city for the rest of the day
<davecheney> meeting up with a bloke who is over here from Zurich
<davecheney> if there is wifi in their offices, i'll be online
<davecheney> if not, i won't
<davecheney> i'll be online tomorrow for the usual release hoopla
<thumper-afk> ok
<thumper> davecheney: have fun
<thumper> poos
<jtv> Anybody available to review some Makefile changes in pyjuju?  MP is at https://code.launchpad.net/~jtv/juju/makefile-fixups/+merge/149907
<jtv> Thanks wallyworld_!
<jtv> Your review seems to count as "(community)" for some reason.
<jtv> Nobody else who can review https://code.launchpad.net/~jtv/juju/makefile-fixups/+merge/149907 ?
<jtv> Also, nobody who knows how to get the test suite passing, or at least not hanging?
<wallyworld_> jtv: which test suite? py juju or go juju?
<jtv> wallyworld_: py juju
<wallyworld_> i've not run those tests, only the juju-core ones
<jtv> At least on Precise & Quantal, we get test errors and then things just lock up (and ctrl-C won't work).
<wallyworld_> that's not good :-(
<wallyworld_> with your review, mgz should be able to do it when he comes online
<jtv> Our thoughts precisely.
<fwereade> frankban, heyhey -- I presume the lxc compile got you unblocked for now?
<fwereade> frankban, the bug remains somewhat rough but is at https://bugs.launchpad.net/juju-core/+bug/1131608
<_mup_> Bug #1131608: deployed series is arbitrary <juju-core:New for fwereade> < https://launchpad.net/bugs/1131608 >
<frankban> fwereade: hi, I switched to another, more urgent, card. I've seen the bug you filed, thank you. lxc should workaround that issue
<frankban> fwereade: how many reviews are required for juju-core? and does "LGTM with changes" means we can just follow suggestions and the "lbox submit"? it's re https://codereview.appspot.com/7398044
<frankban> s/and the/and then/
<mgz> jtv: you want test suite run on that branch?
<fwereade> frankban, please wait for two of those without dissenting opinions
<frankban> fwereade: ack, thanks
<fwereade> frankban, the second of which has just arrived, LGTM
<frankban> fwereade: :-) great!
<frankban> fwereade: submitted
<fwereade> frankban, cheers
<fwereade> dimitern, heyhey
<dimitern> fwereade: hiya
<dimitern> fwereade: I have 2 CLs for you :)
<fwereade> dimitern, cool
<dimitern> fwereade:  https://codereview.appspot.com/7373046/ and https://codereview.appspot.com/7385049/ (WIP still, tests fail and I'm not sure what i'm doing wrong)
<fwereade> dimitern, I have one too I'm about to push, then I need to finish up TheMue's (hmm, he has one that you could look at too)
<dimitern> fwereade: I'll take a look
<TheMue> fwereade: Thx for the +1 btw. Even if I'm after our talk yesterday not sure if we really should use it.
<fwereade> TheMue, we've already paid for it, and there's no compelling reason not to use it IMO
<TheMue> fwereade: Yeah, that's reasonable.
<fwereade> TheMue, I hope we will be able to swap it out before too long, but I don't think it's a serious enough issue to be worth blocking on
<fwereade> TheMue, dimitern: https://codereview.appspot.com/7399049
<TheMue> fwereade: *click*
<dimitern> fwereade: on it, as soon as i finish with TheMue's
<fwereade> TheMue, storage LGTM
<TheMue> fwereade: Thx
<fwereade> dimitern, dude, tests ;p
<fwereade> dimitern, but I have a suggestion that might make the first a bit simpler
<TheMue> fwereade: You've got a review.
<dimitern> fwereade: that's what I was asking about yesterday before it was too late i guess
<fwereade> dimitern, if we add an explicit WantAllRelationsEvents method to filter, that directly restarts relationsw, I think that maybe everything is easier to express
<dimitern> fwereade: not sure how to check if the watcher is restarted (or better still, how to check if we handle the changes before/after the upgrade)
<fwereade> dimitern, sorry, I must have been very unclear, I thought I was handwaving at the existing ones in a helpful way :)
<dimitern> fwereade: :) still at a loss though.. how to inject a change in the chan and check i get it after the restart of the watcher
<fwereade> dimitern, start a filter; add a couple of relations; check you get events for them; receive an upgrade event (or call WanttAllRelationsEvents or whatever we do); check we get the same relations again
<fwereade> dimitern, I'm not sure what we need to inject
<fwereade> dimitern, at the moment it's written so that when someone reads an upgrade event the magic happens; so, to test it, read an upgrade event and check the magic
<dimitern> fwereade: aah - so we'll still get the same changes before/after restarting
<fwereade> dimitern, I would favour decoupling the magic, though, so you can just tack a trivial WantAllRelationsEvents on
<fwereade> dimitern, yeah, I think that's enough
<dimitern> fwereade: ok, i'll look into it some more before bugging you :)
<fwereade> dimitern, sure, but I am always happy to be bugged :)
<fwereade> dimitern, I *think* the second one has failing tests because you do the wrong thing when handling events from relationsw... consider what happens when the chan is *not* closed
<dimitern> fwereade: hmm.. I wasn't sure I'm handling the "does this rel implement the endpoint of the charm of this service" right
<dimitern> TheMue: reviewed
<TheMue> dimitern: Thx
<dimitern> fwereade: reviewed yours
<fwereade> dimitern, TheMue: thanks for the reviews
<TheMue> fwereade: yw
<fwereade> dimitern, "series" is a fundamental concept in juju that it seems like we didn't really bother to implement
<fwereade> dimitern, charms are specific to series: they are tuned to run on particular operating systems
<fwereade> dimitern, we are meant to guarantee that we run (say) precise charms on precise systems, and quantal charms on quantal systems
<fwereade> dimitern, in practice, not so much
<dimitern> I've never been called "Dear Constituent" before :D
<fwereade> dimitern, our current approach is "force everything to run on the same arch/series as the provisioner"
<fwereade> dimitern, I am not especially pleased by this discovery ;)
<dimitern> fwereade: ok, got it, 10x :)
<fwereade> dimitern, np, dear constituent
<dimitern> fwereade: :) i got one of the junk election papers just now, before I threw it away I saw that
<dimitern> fwereade: so, instead of restarting the watcher on outUpgrade <-, implement and call WantAllRelationsEvents as needed (not there) ?
<fwereade> dimitern, yeah, I think so
<fwereade> dimitern, use a want channel as we do for the other control methods
<dimitern> fwereade: but still keep the restarting when x, ok <-Changes; !ok, right?
<fwereade> dimitern, nah, just do the stop/start in response to the want channel I think -- you can keep the MustErr
<dimitern> fwereade: ok
<dimitern> fwereade: am I getting this right: (assuming WantAllRelationsEvents and wantAllRelations chan), when we get <-f.wantAllRelations, we log and restart relationsw ?
<fwereade> dimitern, yeah, I think that gets us what we need
<fwereade> dimitern, then you can just tack a couple of extra lines onto TestRelationsEvents and you're good
<dimitern> fwereade: so we still need the modified defer and don't want MustErr
<fwereade> dimitern, hmm, I think we keep the modified defer
<fwereade> dimitern, but I'm not so sure about MustErr
<fwereade> dimitern, when will we see it?
<dimitern> fwereade: but MustErr will fire once we stop relationsw
<fwereade> dimitern, only if we don't start them again
<dimitern> fwereade: ah, I'll try it
<dimitern> fwereade: got it :) because the MustErr and the restart happen in the same select, they won't interfere
<dimitern> fwereade: fixed https://codereview.appspot.com/7373046/
<fwereade> dimitern, lovely, LGTM
<dimitern> fwereade: tyvm
<dimitern> fwereade: so I need one more LGTM to submit it now..\
<fwereade> TheMue, dimitern's got an easy review up
<TheMue> *click*
<dimitern> fwereade: wrt the other CL - u.charm is the currently installed charm or the charm just deployed and about to have its relations added?
<TheMue> dimitern: 2nd LGTM is in.
<fwereade> dimitern, u.charm is a uniter/charm.GitDir, but it has a Path() you can use to construct an actual *corecharm.Dir to pass into ImplementedBy
<dimitern> fwereade: but how is this charm different from u.unit.Service().Charm() ?
<fwereade> dimitern, that's the state charm we'd be upgrading to, which definitely always implements those endpoints, otherwise the relation couldn't have been created in the first place
<fwereade> dimitern, the charm a unit is running is not necessarily the same as the charm the service wants it to run ;)
<dimitern> fwereade: ah, so the u.charm is not yet in state?
<fwereade> dimitern, mu
<fwereade> dimitern, g+?
<dimitern> fwereade: ok, just a sec
<fwereade> dimitern, starting one now
<fwereade> dimitern, https://plus.google.com/hangouts/_/b4c971e8d459c1b323cf87a088c920c785acb054?authuser=0&hl=en
<dimitern> TheMue: thanks for the review, btw - is your comment about proper capitalization of the comment?
<TheMue> dimitern: That and punctuation, yes. ;)
<dimitern> TheMue: cheers
<dimitern> fwereade: moving the dir.Ensure into PrepareHook seems to cause problems with not finding the dir
<fwereade> dimitern, what's looking for it?
<dimitern> fwereade: i'm having trouble pasting the log
<fwereade> dimitern, interpretive dance? ;p
<dimitern> fwereade: :) just a sec
<fwereade> dimitern, brb
<dimitern> fwereade:  http://pastebin.com/1XfyiMFk
<dimitern> fwereade: both p.u.c and pb.c.c do not work
<fwereade> dimitern, ok here now
<dimitern> fwereade: did you see it?
<dimitern> fwereade: i'm trying to figure out why it happens
<fwereade> dimitern, it doesn't look all that bad -- just that it's not following the path it takes when called by the uniter, so we don't get the PrepareHook calls
<fwereade> dimitern, I'd probably be fine with Ensure()ing the dirs directly in the test
<dimitern> fwereade: that somehow seems wrong
<dimitern> fwereade: maybe because the test is doing things out of sequence as a shortcut?
<fwereade> dimitern, Relationer is a weird type, it's the nexus that connects all the various representations of relations
<fwereade> dimitern, the only reason it's doing a Write there in the first place is so that the Validate on write works -- it's a hack to maintain correct dir state anyway afair
<dimitern> fwereade: i see, ok then I'll add Ensure in these 3 failing tests
<dimitern> fwereade: 2 simple fixes really - in assertHook and the one that checks Join creates the dir (no longer so)
<fwereade> dimitern, great
<fwereade> dimitern, tyvm
<fwereade> dimitern, I guess you're somewhat familiar with the whole livetests gubbins?
<dimitern> fwereade: somewhat yes
<fwereade> dimitern, is there some magic happening re bootstrap in those tests? like, we're running them without bootstrapping, or something? this is ec2 in particular...
<dimitern> fwereade: i think most of them do BootstrapOnce and go with it
<dimitern> fwereade: anyone in particular you have in mind?
<fwereade> dimitern, TestGlobalPorts looks like it doesn't bother
<dimitern> fwereade: lemme see
<fwereade> dimitern, there are 4 calls in total to BootstrapOnce AFAICS
<fwereade> oh what the FUCK
<fwereade> who wrote TestGlobalPorts?
<dimitern> fwereade: no idea :)
 * fwereade sighs dramatically
<dimitern> fwereade: it seems TestGlobalPorts is one of those which do not bother bootstrapping - just uses the config
 * fwereade does not approve of writing tests that depend on obvious bugs
<dimitern> fwereade: +1 :)
<fwereade> dimitern, ok, it looks like I can probably just make all the tests bootstrap
 * fwereade remains baffled as to how a test against an environment that doesn't exist is meaningful
<dimitern> fwereade: not all, some of them test behaviour at or before bootstrap
<fwereade> dimitern, yeah, just the ones that start instances
<fwereade> dimitern, I'm trying to hack as little as possible here ;p
<dimitern> fwereade: yeah, makes sense
<dimitern> fwereade: try openstack's after
<fwereade> dimitern, I would avoid it if I could, but I can't
<fwereade> dimitern, I'm having to change Environ :/
<fwereade> dimitern, apart from machineId, Environ.StartInstance's params are -- I think -- total crack
<dimitern> fwereade: which ones?
<fwereade> dimitern, tools, api info, state info
<fwereade> dimitern, the env should choose the tools
<fwereade> dimitern, and it already knows -- or should -- the state/api info
<fwereade> dimitern, Environ has a frickin' `StateInfo() (*state.Info, *api.Info, error)` method
<dimitern> fwereade: yeah it does
<dimitern> fwereade: hmm seems a bit crackful indeed
<fwereade> dimitern, behold the fruits of detailed academic discussion: the perfect API
<dimitern> :)
<dimitern> fwereade: assuming i check relationer.Join does not create the dir, I should check also PrepareHook does it, right?
<fwereade> dimitern, +1
<fwereade> dimitern, after validating please :)
<dimitern> fwereade: the problem is I have no access to the actual path from the uniter module (it's in uniter/relation)
<dimitern> fwereade: preparehook already validates
<fwereade> dimitern, yep, I'm just saying create the dir after the validation
<dimitern> fwereade: yeah, sure - done that
<fwereade> dimitern, you know the relations dir, though, and you know the relation id, you can probably figure something out ;p
<dimitern> fwereade: but i need a way to access the private path of statedir
<fwereade> dimitern, you had to create a state dir with a known id in a known relations dir to begin with, though, right?
<dimitern> fwereade: or add a method on statedir Exists() or something?
<fwereade> dimitern, -1 unless you can think of a non-test use case for it
<dimitern> fwereade: ah, you mean in the suite, sure i can export that to the suite
<fwereade> dimitern, sgtm
<niemeyer> Hi all
<TheMue> niemeyer: Heyhey
<dimitern> niemeyer: hey
<niemeyer> TheMue, dimitern: Hey folks!
<niemeyer> Huh.. so wikimedia runs a public ganglia server.. that's quite awesome
<niemeyer> http://ganglia.wikimedia.org/
<dimitern> niemeyer: really cool :) you can see the whole infrastructure
<dimitern> fwereade: a bit of help with uniter tests? not sure where to test the changes to updateRelations - it's in the modeAbideAliveLoop only, and I suppose the test has to go somewhere around "steady state changes" steps
<fwereade> dimitern, hmm, that is an interesting one
<dimitern> fwereade: maybe even in upgrade scenarios
<fwereade> dimitern, for now, I think it is sufficient to check that the uniter does not respond to relations it can't handle
<dimitern> fwereade: like: quickstart, createcharm, upgradecharm(to a different, faulty one), wait the log message for ignoring the non implemented relation
<fwereade> dimitern, please, no log checking
<dimitern> fwereade: ok, how then?
<fwereade> dimitern, the fact that we indulged it out of desperation does not mean the bar for it should be lowered ;)
<dimitern> fwereade: :) sure
<fwereade> dimitern, but, yeah, it is a tricky question, and I am still thinking
<dimitern> fwereade: we can check the relation is not added
<dimitern> fwereade: like no relationer for that relation or something?
<fwereade> dimitern, yeah, we certainly can check that the unit doesn't enter scope in that relation
<fwereade> dimitern, and that's something we can do now
<fwereade> dimitern, g+ quickly?
<dimitern> fwereade: ok, i'll send you a link this time\
<fwereade> dimitern, cheers :)
<dimitern> fwereade: https://plus.google.com/hangouts/_/b8e9e83fe6e47838019383106994c2dcca14363f?authuser=0&hl=en
<dimitern> fwereade: in order to add the incompatible relation to the wp charm, i have to overwrite the metadata, right?
<dimitern> fwereade: in createCharm{customize:..}
<fwereade> dimitern, yeah, think so
<fwereade> dimitern, sorry I missed you
<fwereade> dimitern, did you do bootstrappy stuff in openstack?
<dimitern> fwereade: I'm half way there already - will paste what I got
<dimitern> fwereade: yes
<fwereade> dimitern, do you know if there's any distinction between the CACert in the environ config and the (cert, key) passed into Bootstrap>
<fwereade> dimitern, sorry, the *cert* passed into bootstrap
<dimitern> fwereade: not really
<fwereade> dimitern, ah, wait, I think there is
<fwereade> dimitern, the ones passed in are generated from the one in the config
<dimitern> fwereade: I mean I don't really know :)
<fwereade> dimitern, indeed, sorry, just thinking out loud
<dimitern> fwereade: does this look ok to you http://paste.ubuntu.com/5555566/
<dimitern> fwereade: it works, i did a small test
<fwereade> dimitern, nice, much neater than I would have done it :)
<dimitern> fwereade: :) ty
<dimitern> fwereade: not sure if i should use only quickStart{} or quickStartRelation{} to setup the test case initial conditions
<fwereade> dimitern, quickStart I think
<fwereade> dimitern, you want your own funky relation setup using the service's new charm
<dimitern> fwereade: and add relation later, immediately after upgradeCharm (or before)
<fwereade> dimitern, immediately after
<dimitern> fwereade: ok. the funky setup will happen after quickstart in createcharm{customized}
<dimitern> fwereade: I need a charm running already ok, then try the upgrade
<fwereade> dimitern, yeah; create, add, serve, service.SetCharm()
<fwereade> dimitern, and immediately addRelation{}
<dimitern> fwereade: yeah, that's it
<fwereade> dimitern, in the hope that the scheduler happens to handle the relation change before it does the upgrade
<dimitern> fwereade: yeah
<dimitern> fwereade: in addition to renameRelation (instead of replace*), I'll need something to call ctx.svc.SetCharm
<fwereade> dimitern, I'm sure that already exists, there are other upgrade tests
<dimitern> fwereade: yeah, upgradeCharm{} does that in fact
<fwereade> dimitern, cool -- and if you need to slice and dice the available primitives, go for it, they arenot meant to be set in stone
<dimitern> fwereade: ok, although as I get to know more what each one does they're pretty comprehensive already
<fwereade> dimitern, cool
<arosales> gary_poster: is there a " Juju GUI user guide" that briefly explains how to work with the GUI (ie what yellow circles on a service in the canvase mean. How to deploy, relate, etc. ?
<arosales> perhaps that is all pretty straight forward though
<dimitern> fwereade: hmm.. how to wait for a hook which shouldn't happen?
<fwereade> dimitern, waitHooks{}
<fwereade> dimitern,  :)
<fwereade> dimitern, but... when do you need to do that?
<dimitern> fwereade: this is a positive check, i think I need a negative one
<dimitern> fwereade: http://paste.ubuntu.com/5555636/ that's the test case so far
<fwereade> dimitern, I *think* you need a single positive check for the appropriate joined hook running, don't you?
<dimitern> fwereade: and it fails with "never got expected hooks"
<fwereade> dimitern, I think verifyRunning may have tripped you up -- don;t think you need that one
<dimitern> fwereade: ah, waitHooks{} (empty) ensures no hooks run
<fwereade> dimitern, what happens if you just check the one hook and verifyCharm{revision:2} immediately afterwards?
<dimitern> fwereade: i'm trying this now
<dimitern> fwereade: so the new charm is created with rev 2, and then upgradeCharm{rev 2} as well, verifyCharm{rev 2} at the end
<fwereade> dimitern, +1
<fwereade> dimitern, hey, even better
<dimitern> fwereade: still fails with never got expected hooks, this time only with: 	waitHooks{"db-relation-joined mysql/1 db:0"}
<fwereade> dimitern, add some stuff to the db2-relation-joined hook created by the charm to write something unambiguous to the charm dir
<fwereade> dimitern, interesting, what's the actual?
<fwereade> dimitern, actually paste me the log please
<dimitern> fwereade: aw fuck - it should be wait for db2, right?
<fwereade> dimitern, lol yes
<dimitern> :D
<fwereade> dimitern, well spotted
<dimitern> fwereade: running now
<dimitern> fwereade: even if it passes, would it be enough?
<dimitern> fwereade: i mean that scheduler cases..
<fwereade> dimitern, well, the trouble is, I don't see a way to goose the scheduler into jumping the wrong way even if I were convinced I could force that particular loop to be in that particular state at a particular time
<fwereade> dimitern, I think the best we can do is write the test that has the best possible change of inducing the race
<fwereade> dimitern, and maybe tweak the summary so it's clear that failures here are to be taken v seriously
<dimitern> fwereade: it didn't pass, but now I see the db2-relation-joined happens in the log before
<dimitern> fwereade: the trouble with fmt.Printf and log.Printf is they're out of sync
<fwereade> dimitern, use c.Logf() in tests
<dimitern> fwereade: yeah, just did
<dimitern> fwereade: wanna see the log?
<fwereade> dimitern, yeah, please
<dimitern> fwereade: running cleanly one more time, just a sec
<dimitern> fwereade: http://paste.ubuntu.com/5555673/
<dimitern> fwereade: i suspect something might be wrong here again: waitHooks{"db2-relation-joined mysql/1 db:0"},
<fwereade> dimitern, ah-ha
<fwereade> dimitern, db2:0
<dimitern> :) yeah
<dimitern> it's getting late and I'm getting sloppy
<dimitern> sorry
<fwereade> dimitern, sorry, createCharm is more subtle than I made clear
<dimitern> fwereade: how?
<fwereade> dimitern, actually not that
<fwereade> dimitern, well kinda
<fwereade> dimitern, it creates the hook files that dump to the log for detection later
<fwereade> dimitern, they're still called db-relation-joined
<dimitern> fwereade: aha!
<dimitern> fwereade: so var goodHook2 or something inline in customize?
<dimitern> fwereade: no, actually I just need to call writeHook again
<fwereade> dimitern, can yu just call writeHook in cus... yeah :)
<dimitern> :)
<gary_poster> arosales there is not
<dimitern> fwereade: to do that though, I have to change createCharm's customize to accept ctx *context instead of path string
<fwereade> dimitern, sounds sane
<arosales> gary_poster: ok, thanks
<dimitern> fwereade: btw it would be nice to have some extra \n\n between each ut() case in the verbose log somehow :)
<fwereade> dimitern, sorry, I should have said, ffs comment out the earlier tests when you're developing
<fwereade> dimitern, while the steps are quite nice it really should not be a table-based test IMO
<fwereade> dimitern, hindsight, eh
<dimitern> fwereade: or at least a bit more granular perhaps, while still benefiting from tbt
<dimitern> fwereade:  [LOG] 6.56912 JUJU u/0 db2:0: UniterSuite-29 db2-relation-joined mysql/0
 * fwereade cheers
<dimitern> fwereade: this tells me that I should probably wait for "db2-relation-joined mysql/0 db2:0"
<fwereade> dimitern, +1
<dimitern> fwereade: alright :) the logs now seem less cryptic indeed
<fwereade> dimitern, cool :)
<dimitern> fwereade: once I start understanding the state/watcher and collections stuff.. who knows :)
<fwereade> dimitern, heh, I really ought to turn of the logspam in the watchers
<dimitern> fwereade: still no cigar though
<dimitern> fwereade: same error
<fwereade> dimitern, bah
<fwereade> dimitern, paste again maybe?
<dimitern> fwereade: http://paste.ubuntu.com/5555744/ - tail of the log, and the test case http://paste.ubuntu.com/5555746/
<fwereade> dimitern, d'oh
<fwereade> dimitern, wait for upgrade-charm and config-changed before the relation one
<fwereade> dimitern, this makes the followup step redundant
<dimitern> fwereade: aha
<fwereade> dimitern, however it doesn't explain why the hook is apparantly not being found
<fwereade> dimitern, it's clearly being run, but it's not showing up in the log
<dimitern> fwereade: so 2 waitHooks in a row - there's also verifyWaiting but i think it's not related
<dimitern> fwereade: :) this time the earlier waitHooks bailed with error
<dimitern> fwereade: something's fishy here
<dimitern> fwereade: because upgrade-charm and config-changed definitely happened
<fwereade> dimitern, sorry, I'm confused
<dimitern> fwereade: I added waitHooks{"upgrade-charm", "config-changed"}, before waitHooks("db2-relation-changed mysql/0 db2:0"}, and it failed on the first one
<dimitern> fwereade: you know, i think it's best to leave it for now - i'll lbox propose -wip
<dimitern> fwereade: and start fresh on monday
<fwereade> dimitern, sgtm :)
<dimitern> fwereade: thanks for all the help, really
<dimitern> fwereade: learned a lot today :)
<fwereade> dimitern, a pleasure :)
<dimitern> i'm off then
<dimitern> have a good evening and weekend everyone
<TheMue> So, I'm off too. Have a nice weekend everyone.
<fwereade> TheMue, hapy weekend
<TheMue> fwereade: Thx, also for you.
<TheMue> fwereade: Environ w/o Bootstrap looks good so far, Monday morning I'll add the tests.
<fss> niemeyer: ping
<niemeyer> fss: Hey
<fss> niemeyer: can we get those iam patches merged? :-)
<niemeyer> fss: Definitely
<niemeyer> fss: It is in the queue, promisse
<niemeyer> promise
<fss> niemeyer: thanks
<niemeyer> fss: It isn't the only thing, unfortunately, but it is there
<fss> niemeyer: i'm just revisiting some code and noticed the github.com/fsouza/go-iam import path :-(
<niemeyer> fss: AW
<niemeyer> Aw, that is
<niemeyer> :)
<fss> niemeyer: regarding the queue, is there anything I could help? :-)
<niemeyer> fss: Thanks for the offer, but I'm afraid not.. it's just stuff on my plate
#juju-dev 2013-02-23
<fwereade_> morning dimitern :)
<dimitern> fwereade_: morning :)
<dimitern> for some reason whenever my net connection gets broken and re-established, empathy starts and joins all channels, even if I have stopped it deliberately
#juju-dev 2013-02-24
<fwereade__> niemeyer, ping
<thumper> fwereade__: you are working late
<fwereade__> thumper, everybody's asleep :)
<thumper> fwereade__: luckily it seems it was just my laptop that was screwed, not all raring
<thumper> due to an old staging ppa I had enabled
<thumper> which someone broke :(
<fwereade__> thumper, good and bad news then ;)
<thumper> fwereade__: so I now have a half functioning raring install, and I'm getting my quantal vm up to a state where I can run the go tests
<thumper> fwereade__: I am a little confused though...
<thumper> fwereade__: last week I was sure I merged one of my branches
<thumper> but it doesn't seem to be the case
<thumper> perhaps the lbox submit failed and I didn't notice
<fwereade__> thumper, huh, strange
<thumper> I'm just going to run all the tests again, make sure it has a recent trunk merged, and try again
<thumper> the juju-core tests seem to be running fine inside the virtualbox quantal image I have
<thumper> albiet slowly
<fwereade__> thumper, I definitely can shave a few seconds off the uniter tests, at least, but I still haven't got around to it :(
 * thumper shrugs
<thumper> it is what it is
<thumper> fwereade__: still around?
<thumper> fwereade__: https://codereview.appspot.com/7370043/diff/3007/cmd/juju/constraints.go#newcode21
<fwereade__> thumper, heyhey
<thumper> I think we need [<service> [<constraints> ...]]
<thumper> but does that make sense?
<thumper> the constraints are for the service
<fwereade__> thumper, I still think that environment constraints make sense, and I think the tool handles them..?
<thumper> [<service>] [<constraints> ...]
<thumper> is what you proposed
<thumper> I'm wondering which is more normal?
<fwereade__> thumper, wait, *get* constraints is just [<service>]
<thumper> fwereade__: for ones where we don't set a service?
<thumper> fwereade__: well... I'm pretty sure the command treats the first param as a service name only
 * thumper double checks
 * fwereade__ looks in bafflement at that code, and is sure it made sense when he wrote it
<thumper> yes, it seems that get is just <service>
<thumper> I should change that
<fwereade__> thumper, incidentally I vaguely recall being a bit wishy-washy in the review -- but I'm very much +1 on init
<thumper> fwereade__: yes, get takes zero or one params
<thumper> fwereade__: but we should change the params for set to be... different
<thumper> ah set requires --service
<thumper> fwereade__: which makes me think that we have a mis-fit here
<thumper> juju get wordpress
<thumper> but juju set --service=wordpress
<thumper> add -constraints to that if you like
<fwereade__> thumper, yeah, I think you're right
<thumper> but.. not for this branch
<thumper> I'll fix the help text
<thumper> but we should fix at some stage
<fwereade__> thumper, the only source of inertia is a vague desire to avoid churn against the python version when it's ...merely icky, as opposed to wrong, if you like
<thumper> fwereade__: oh, is this a direct copy of the python version?
<thumper> if so, lets just leave it for now
<thumper> and perhaps file a bug with a nice tag, like "cli-cleanup" :-)
 * fwereade__ knows another bug that could use a tag like that :/
<fwereade__> (the hook tools all accept --format, even if they aren't meant to produce output)
<thumper> fwereade__: so, I can at least run all the tests in an quantal environment to confirm prior to committing
<fwereade__> thumper, great
<thumper> fwereade__: with the thought of aiming for constency
<thumper> fwereade__: we have the args for "set-constratins" to be [key=[value] ....]
<fwereade__> thumper, yep, sgtm
<thumper> fwereade__: shoudl we change the args for "set" to be "<service> key=[value] ..." ?
<fwereade__> thumper, ah: sorry... yes, I think that makes sense
<thumper> kk
<thumper> gah
<thumper> typed lbox propose instead of submit
<thumper> fwereade__: I'm going to try to change the account that lbox is using... to the work one, so email gets through
<thumper> otherwise launchpad drops the email on the floow
<thumper> floor
<fwereade__> thumper, heh, unhelpful :(
<thumper> fwereade__: well, launchpad isn't going to trust just anyone :)
<fwereade__> thumper, quite so ;)
<thumper> how long does the submit normally take?
<thumper> fwereade__: it seems to be taking ages...
<fwereade__> thumper, I think it still does all the propose work of generating the diff for the final rietveld push
<thumper> hmm...
<thumper> it has been going for minutes and minutes
<thumper> with no feedback after the identification of the rietveld link
<thumper> oh just done
<thumper> geez
 * thumper double checks launchpad to check
<thumper> yep, in trunk now...
<thumper> ok, back to the next pipe
#juju-dev 2014-02-17
<wallyworld> axw: standup?
<axw> oops
<axw> wallyworld: brt
<waigani> wallyworld: doc/hacking-state.txt:49 talks about mgo/txn's "transactions"
<wallyworld> yeah, i read that way back when
<waigani> but they are not really transactions?
<waigani> just sets/slices of db opps ?
<wallyworld> yep
<wallyworld> that's how i see it
<waigani> okay, just double checking
<waigani> thanks
<wallyworld> i guess each slice of ops is a txn
<wallyworld> but there are limitations compared with what you might expect from using other dbs
<dimitern> morning all
<waigani> axw: can I bother you?
<axw> waigani: yep?
<axw> morning dimitern
<hatch> hello all, has anyone ever run into a situation where juju-core (1.17.2 precise( thinks an environment is bootstrapped but can't destroy it because there are no instances? I tried removing the environments/ folder but no luck
<axw> hatch: the provider-state file is probably in cloud storage
<axw> what provider?
<hatch> ec2, I'll take a look
<waigani> axw: sync-tools. quick hangout?
<axw> hatch: if it happens again, try destroy-environment --force
<axw> waigani: sure
<hatch> axw that was it! Thanks, I didn't know that it did that, I have been switching between trunk and devel a bunch so I wasn't sure if I broke something big :D
<axw> no worries
<axw> would be good to know why it happened, but that'd be difficult to figure out with no instances :)
<hatch> I'll keep an eye open to see if it happens again
<hatch> if the machines were destroyed out from under Juju (in the ec2 control panel) could that cause it?
<axw> hatch: that would cause it I think, but I can't tell if that's *the* cause
<hatch> well after I'm done doing what I'm doing I can give it a try...might not be until later int he week though :)
<axw> no problems, thanks
<hazmat> axw, fwiw filed some new manual provider issues over the weekend (https://bugs.launchpad.net/juju-core/+bugs?field.tag=manual-provider&orderby=-date_last_updated&start=0)
<axw> hazmat: thanks, will take a look
<hazmat> hatch, yanking the provider-state in control-bucket should do the trick, there's an outstanding bug for this issue. basically juju should sanity check the instance id in object storage.
<axw> oy, I thought the reverse lookup was fixed
<hazmat> hatch, https://bugs.launchpad.net/juju-core/+bug/1176961
<hatch> ahhh thanks
<hazmat> axw, hmm.. i was going back and forth from trunk to 1.17.2 .. that one might have been against 1.17.2
<hatch> I had used --force
<hatch> but good to know there is a known issue around this
<axw> hazmat: nah there's still a lookup in there, just in a different spot from before
<axw> hazmat: is https://bugs.launchpad.net/juju-core/+bug/1280432 on trunk?
<hazmat> axw, yes, but your pending branches may address
<axw> hazmat: https://bugs.launchpad.net/juju-core/+bug/1279259
<axw> yeah
<axw> ok
<hazmat> axw, it looked like on upload-tools it was hardcoded to use ubuntu user before user was setup
<hazmat> modifying it to use configured bootstrap-user resolved it for me.. your fixes look more comprehensive
<axw> hazmat: what should happen is the ubuntu user gets initialised before any other ssh attempts are made; then ubuntu@ is hard-coded for everything else
<axw> only the ubuntu user init should use bootstrap-user
<hazmat> axw, i saw the logic, just not the reasoning, ie say we support centos ;-)
<axw> heh
<axw> hazmat: fwiw, the reasoning is: limit the number of times we request passwords from the user to one time during bootstrap
<hazmat> axw, btw, i was able to use some of the recent manual feature api additions to give a slick demo, of creating 50 lxc containers as env machines in under a minute, all offline
<axw> (once for ssh, once for sudo)
<axw> nice :)
<axw> oh, without apt-get stuff... very cool
<hazmat> axw, it needs a little setup (base images, btrfs) but the core comes out to just being roughly 20 lines.. https://github.com/kapilt/juju-lxc/blob/master/juju_lxc/add.py#L29
<hazmat> axw, yeah.. it  is pretty awesome, thanks :-)
<axw> oo, I hadn't seen juju-lxc
<axw> this looks like it'd be useful for my testing
<hazmat> axw, yeah.. its what i do dev with.. its not really cleaned up for easy consumption though, hoping to push some of it to tim's push to make local provider moar awesome.
<axw> hazmat: ah right, hence the talk of a plugin rather than local-specific.
<hazmat> axw, yup.. burnt my free time hacking on making digital ocean manual plugin easily consumable.. curious where that goes... i'll clean up the lxc plugin next time around.. but back to client work for the next few weeks.
<axw> enjoy ;)
<rogpeppe> jam: standup?
<jam> rogpeppe: yeah, 1:1 I was just making some lunch
<dimitern> rogpeppe, it's a little early to be standing up :P
<rogpeppe> dimitern: you're right, i'm sitting down
<mattyw> rogpeppe, can you ping me when you're done? I've got questions/ need some help when you have a moment
<dimitern> jamespage, ping
<jamespage> dimitern, hello
<dimitern> jamespage, did you get my last few messages?
<dimitern> jamespage, hey
<fwereade> axw, waigani: just responded to https://codereview.appspot.com/61520045/ -- thoughts?
<waigani> fwereade: sorry dude, my only thought right now is that I can't keep my eyes open. I'll take a look in the morning.
<fwereade> waigani, np, sleep tight :)
<TheMue> fwereade: https://codereview.appspot.com/58510045/ is the current approach to debug-log, with support for local provider
<fwereade> TheMue, nice coincidence, I literally just got to that point in the review queue, probably won't do it until after standup though
<TheMue> fwereade: ok, have a new task where I have to read a lot first
<fwereade> TheMue, cool :)
<dimitern> rogpeppe, now's the time to stand up
<dimitern> ;)
<rogpeppe> wallyworld: are you coming back? we miss you!
 * dimitern is out for 2h
<rogpeppe> trivial code review anyone? https://codereview.appspot.com/65050043/
<rogpeppe> (it just sorts all imports consistently throughout the code base)
<rogpeppe> fwereade: ^
 * fwereade looks
<fwereade> rogpeppe, LGTM
<rogpeppe> fwereade: thanks
<fwereade> TheMue, half-reviewed https://codereview.appspot.com/58510045/ -- rogpeppe, would you take a look as well please?
<TheMue> fwereade: thx
<TheMue> fwereade: regarding the public or internal params if I ask two of you I get three opinions. :)
<TheMue> fwereade: and all are one package, only different files. maybe a more general conceptual problem?
<fwereade> TheMue, haha
<fwereade> TheMue, what's the case for calling them internal?
<fwereade> TheMue, IMO if we expose them over the public API they're, well, public
<fwereade> TheMue, re files -- yeah, it's just convention I guess, but I think there's some value to spreading things out by file even if it's not compiler-enforced
<TheMue> fwereade: I had it in public before
<TheMue> fwereade: see https://codereview.appspot.com/58510045/diff/60001/state/api/params/params.go#newcode570 :)
<fwereade> TheMue, cheers
<fwereade> TheMue, I read that a bit differently to you, I think -- both the debug bits and the charms response should be in params, because they're both public api
<TheMue> fwereade: So you mean it should be moved inside the internal.go file? Otherwise, what does "Also, please move this in internal.go, where ..." mean?
<fwereade> TheMue, I think there was agreement in dimitern's second comment that they should both go in params, not internal
<fwereade> TheMue, he said params is fine, but please more CharmResponse
<fwereade> s/more/move/
<TheMue> fwereade: OK, ic.
<TheMue> fwereade: But I won't move CharmResponse as the refactoring of those two extra handlers should be an extra CL. This one is already too large.
<rogpeppe> fwereade: i responded to some of your comments on  https://codereview.appspot.com/58510045/
<TheMue> rogpeppe: your way of letting all providers explicitly set the log location is less convenient but sounds logical and save
<dimitern> rogpeppe, hey, are you aware of the status of schema upgrades using the new upgrade framework?
<rogpeppe> dimitern: mongo schema upgrades?
<dimitern> rogpeppe, yep
<rogpeppe> dimitern: i think they're planned for, but i don't know when
<dimitern> rogpeppe, I know wallyworld did some work on upgrades in general, but is it usable?
<rogpeppe> dimitern: it only covers upgrades to stuff on a given machine
<dimitern> rogpeppe, hmm ok, so no schema upgrades yet
<rogpeppe> dimitern: the upgrades doc talks about mongo schema upgrades, but there's quite a bit of stuff yet to design
<dimitern> rogpeppe, i'm asking because of bug 1174610 which I've just fixed, but it involves some schema changes
<_mup_> Bug #1174610: unit ids should be unique <regression> <juju-core:In Progress by dimitern> <https://launchpad.net/bugs/1174610>
<rogpeppe> dimitern: schema changes are essentially major-version upgrades
<dimitern> rogpeppe, I'll propose it provisionally for now, pending what needs to be done re schema upgrades
<rogpeppe> dimitern: how are you proposing to fix the problem?
<dimitern> rogpeppe, by using the sequence collection for unit ids, as we do for pretty much all other ids (machines, containers, etc.)
<rogpeppe> dimitern: so if you deploy wordpress, then deploy mysql, the first mysql unit is mysql/1 ?
<dimitern> rogpeppe, no
<dimitern> rogpeppe, the sequence name is "s#servicename#unit", so any service named "mysql" will have its units starting from 0
<rogpeppe> dimitern: what happens now?
<dimitern> rogpeppe, e.g. if you deploy wordpress as mysql, then add a unit, it will be mysql/0, then destroy the service and deploy mysql with name "mysql", add a unit - it will be mysql/1
<dimitern> rogpeppe, now unit ids start from 0 for each service
<rogpeppe> dimitern: ok, that's a little better
<rogpeppe> dimitern: it feels a little bit like a hack to get around the fact that our *service* names aren't unique though
<dimitern> rogpeppe, and apparently that's a regression from before, and some charms depend on using unit ids and them being unique
<rogpeppe> dimitern: the problem is that some other charms might depend on having a unit 0.
<rogpeppe> dimitern: (not that they should, of course)
<dimitern> rogpeppe, if there are any, it's not mentioned
<dimitern> hazmat, you'd be happy to know a fix for bug 1174610 is land very soon
<_mup_> Bug #1174610: unit ids should be unique <regression> <juju-core:In Progress by dimitern> <https://launchpad.net/bugs/1174610>
<dimitern> rogpeppe, there it is https://codereview.appspot.com/64890044
<dimitern> hazmat, s/is land/will land/
<rogpeppe> dimitern: if it's not backwardly compatible without a schema change, i don't see how it can land
<dimitern> rogpeppe, it is compatible i think
<dimitern> rogpeppe, the problem is to update the sequences collection during the upgrade, so new units won't get ids starting from 0
<rogpeppe> dimitern: exactly
<rogpeppe> dimitern: it's a major-version issue
<rogpeppe> dimitern: i'm wondering if there's a way to do it without the schema change
<rogpeppe> dimitern: or, without needing to synchronously update the schema anyway
<hazmat> dimitern, woot!
<rogpeppe> dimitern: for example, when a service is created, you could mark it with a "uses global sequence numbering" flag
<dimitern> rogpeppe, yeah?
<rogpeppe> dimitern: when a service is destroyed that doesn't have that flag set, it could update the sequences collection with the most recent unit number for that service
<dimitern> rogpeppe, isn't that a schema change as well?
<rogpeppe> dimitern: when a unit is created, if allocates it from the service sequence number unless the "uses global sequence" flag is set
<dimitern> rogpeppe, ah, one of those flags where false is default
<rogpeppe> dimitern: yes
<rogpeppe> dimitern: in that way, you can remain compatible with the old schema but update to the new schema over time
<dimitern> rogpeppe, well, that could work, but how about service creation? we always create services with this flag=true
<rogpeppe> dimitern: yes
<dimitern> rogpeppe, ok, i'll look into it tomorrow, i'd appreciate these comments in the review please :)
<rogpeppe> dimitern: so only legacy services will have that flag==false
<rogpeppe> dimitern: ok, will do
<dimitern> rogpeppe, ta!
<jamespage> davecheney, btw a new gccgo-4.9 snapshot is working its way into trusty; I've rebuilt gccgo-go and juju-core using this new version
<jamespage> its the default (gccgo -> gccgo-4.9)
<rogpeppe> trivial code review, anyone? https://codereview.appspot.com/65160043/
<mgz> rogpeppe: will look in a sec
<rogpeppe> mgz: ta
#juju-dev 2014-02-18
<axw> wallyworld, waigani: standup
<davecheney> https://bugs.launchpad.net/juju-core/+bug/1281394
<_mup_> Bug #1281394: uniter failed to run non-existant config-changed hook <juju-core:New> <https://launchpad.net/bugs/1281394>
<davecheney> today's WTF
<axw> davecheney: is that plain old juju built with gc, or is it built with gccgo?
<davecheney> bog standard golang-go
<davecheney> axw: not really supposed to log public bugs about the other thing
<davecheney> yet
<axw> yah ok
<axw> hrm
<axw> weird, I dunno how this ever worked. seems to be looking for the complete wrong error type. I'll dig more later
<davecheney> axw: if you point me in the right direction
<davecheney> i can fix this one muself
<davecheney> it doens't sound that hard
<axw> davecheney: worker/uniter/context.go, runCharmHook
<axw> at the end of the function it's asserting the error is of type *os/exec.Error
<axw> AFAICT, that's only ever returned by os/exec.LookPath
<davecheney> that is stupid
<davecheney> axw: ummm ...
<davecheney> 2014-02-18 04:11:37 INFO juju.state.apiserver apiserver.go:135 [F] user-admin API connection terminated after 18m27.150333066s
<davecheney> 2014-02-18 04:11:42 INFO juju.state.apiserver apiserver.go:131 [10] API connection from 124.149.62.81:43651
<davecheney> 2014-02-18 04:13:51 INFO juju.state.apiserver apiserver.go:135 [10] user-admin API connection terminated after 2m8.222108526s
<davecheney> 2014-02-18 04:18:30 INFO juju.state.apiserver apiserver.go:131 [11] API connection from 124.149.62.81:43665
<davecheney> 2014-02-18 04:20:38 INFO juju.state.apiserver apiserver.go:135 [11] user-admin API connection terminated after 2m8.067538006s
<davecheney> 2014-02-18 04:21:34 INFO juju.state.apiserver apiserver.go:131 [12] API connection from 124.149.62.81:43671
<davecheney> 2014-02-18 04:21:41 INFO juju.state.apiserver apiserver.go:135 [12] user-admin API connection terminated after 6.261804724s
<davecheney> 2014-02-18 04:21:43 INFO juju.state.apiserver apiserver.go:131 [13] API connection from 124.149.62.81:43673
<davecheney> two things
<davecheney> and more importantly
<davecheney> why did someone decide to use %x there
<davecheney> ooooooooooooooooooooooooooooooh
<davecheney> i know what they are
<davecheney> those are juju ssh connections
<davecheney> why is it leaving the connection open while ssh is running
<davecheney> i thought that was fixed
 * axw shrugs
<hazmat> that config-changed hook error is odd
<rogpeppe> axw: yes, that import sorting change was made mechanically, but the program was just a quick hack - it's not really suitable for using in production
<axw> rogpeppe: ok
<rogpeppe> axw: in particular, it doesn't cope with comments well (the bugbear of go reformatting)
<axw> ah yes
<rogpeppe> axw: it doesn't actually use go/ast - it cheats
<rogpeppe> axw: did you see my question on golang-nuts, BTW?
<axw> well, we don't necessarily have to have something that makes source changes automated - just something to check they're wlel formatted
<axw> rogpeppe: I did not
 * axw looks
<rogpeppe> axw: subject was "gofix and comment consistency"
<axw> yup, reading now
<axw> I had this issue with gocov, just gotta dredge the old source code to see if I actually solved it :)
<rogpeppe> axw: BTW in case you might find it useful, the sortimports code is this: http://paste.ubuntu.com/6953264/
<axw> thanks :)
<axw> rogpeppe: https://github.com/axw/gocov/blob/1f9133a687283076e46f1fb56ad58a76bbd7392b/gocov/instrument.go#L273
<rogpeppe> axw: ah... i'll try that
<rogpeppe> axw: thanks!
<axw> but.. you said you're ot using go/ast?
<axw> not*
<rogpeppe> axw: not for sortimports, but i am for the errgo changes - i did a gofix module for that
<axw> oh in this case
<axw> right
<rogpeppe> axw: unfortunately that solution (clearing out the File comments) doesn't seem to work for me - it ends up deleting the comment
<axw> hrm
<rogpeppe> axw: the weird thing is that they must have encountered this issue in previous gofix modules
<rogpeppe> axw: i suppose it's just possible that there was no previous gofix that made the source code longer
<axw> entirely possible... not really sure why the comments would disappear tho
<TheMue> fwereade: Thx for your response to rogpeppe. The number of /var/log/juju in trunk is indeed high, the handling somewhat curious. Should be refactored, but in a different CL.
<fwereade> TheMue, I think that'd need to be a prereq for this one, thoug
<TheMue> fwereade: Could be, yes.
<fwereade> TheMue, rogpeppe: thoughts re direct regexp filtering?
<rogpeppe> fwereade: as far as apps knowing our log format:  we could just pick a format and stick to it - a prefix-based format should be reasonably future-proof. in a way, you can think of the format as the interface definition.
<rogpeppe> fwereade: i had thought that it would be nice if command-line clients didn't have to use regexps though - we could potentially map from tag-set to regexp on the client side
<fwereade> rogpeppe, it feels to me like tags are the language of the API, and if we want to filter by logging-entity we should darn well name it in the usual way over the API
<fwereade> rogpeppe, regexps feel useful as well, but for different reasons
<TheMue> rogpeppe: why the difference here? people would otherwise use it with a pipe to grep
<rogpeppe> fwereade: it seems to me that people are going to become dependent on the exact format of the log output whether we have explicit tag-level filtering or not
<fwereade> rogpeppe, dependingon the content of individual messages feels qualitatively different from depending on the format of all messages
<TheMue> rogpeppe, fwereade: remembering my own admin time I always took first an unfiltered look into the logs and then drilled down by the optimal greps
<rogpeppe> fwereade: i'm not sure i get that
<TheMue> rogpeppe, fwereade: because it isn't always one machine, one unit. errors can have different reasons, on a higher level
<TheMue> rogpeppe, fwereade: and I need easy ways to aggregate them
<rogpeppe> fwereade: the thing is that even if they filter by a few explicit units, the log output still needs to identify the message from each individual unit
<rogpeppe> fwereade: so the client-side code may well still need to know which line pertains to which unit in the filter
<fwereade> rogpeppe, that's easily solved by having a connection per entity ;p
<rogpeppe> fwereade: that's not a good idea
<rogpeppe> fwereade: it doesn't scale well
<TheMue> rogpeppe, fwereade: using tags how do I get the log entries of units 5, 7 and 9 of one service in one run to see the timeline and there how errors correlate, e.g. stablishing relations?
<fwereade> TheMue, how would you get that today?
<fwereade> TheMue, it seems very optimistic to assume you'll see perfect ordering once it's been through rsyslog
<TheMue> fwereade: passing it as regex so that I've got a server-side filtering and only those are delivered (regardless if cli or api)
<rogpeppe> fwereade: BTW there's nothing to say that this interface *is* dependent on the exact log file format - we can always transform the text before filtering and delivering to the client
<TheMue> fwereade: not a perfect one, but a nearer one than doing three individual calls
<fwereade> TheMue, I don't think that's a logically sound argument
<fwereade> TheMue, if it might be wrong, it might be wrong
<fwereade> TheMue, you either depend on it or you don't, and you can't with either aproach
<TheMue> fwereade: shure it might be wrong, but it's the practical approach by admins
<TheMue> fwereade: you wonna create a data warehouse
<TheMue> fwereade: in this case we have to create an entity with dedicated fields in the database
<fwereade> TheMue, kind of, yes -- at the very least I'd like this API to have a chance of continuing to work if and when we do use grown-up logging
<TheMue> fwereade: and an atomic tme sync on all nodes
<rogpeppe> fwereade: i think there's a lot to be said for providing some concrete definition of the log format here, because people *will* see it
<TheMue> fwereade: and a good dwh api
<rogpeppe> fwereade: this is perhaps a good moment to do that.
<TheMue> fwereade: but do we really want this? is this a requirement that currently exists or is it wishful thinking? who are the stakeholders for it and how do they work?
<fwereade> TheMue, I am one of the stakeholders because having juju be all amateur and flaky makes me sad
<TheMue> fwereade: hehe, nice argument
<rogpeppe> fwereade: if we move to moving JSON-based (or other "richer format") logging at some point, we can still provide the current interface, i think.
<fwereade> TheMue, rogpeppe: my judgment was, and remains, that we don't have enough time or enough need *in this cycle* to do a proper logging database
<TheMue> fwereade: sure it would be more powerful than flat files
<TheMue> fwereade: but then you talk about a feature which isn't really cheap
<fwereade> TheMue, rogpeppe: but I still think it's important to provide an API at a level of abstraction that maps to the entities we're actualy playing with
<fwereade> TheMue, which is why we're not doing it this sysle
<fwereade> er s/sysle/cycle/
<TheMue> fwereade: to define such a kind of api ask yourself what you really want to know from your environment
<TheMue> fwereade: make a list of all questions
<TheMue> fwereade: those define the constraints of the solution
<fwereade> TheMue, I know at the very least that I will sometimes want to see all the log output of a single tagged entity
<TheMue> fwereade: and you're right, to have a good solution it quickly gets larger than possible in this cycle
<rogpeppe> fwereade: i get that you're concerned that the level that we're specifying filtering doesn't map to some of the entities that we might want to filter on, but the problem is that the filtered output is also part of the API
<fwereade> TheMue, which is why I'm pushing back on doing everything via regexp
<TheMue> fwereade: how does using a regexp hindering you to get exactly that output?
<fwereade> rogpeppe, yeah, I rather liked the idea of us transforming the output so we can impose a format on the way out
<fwereade> TheMue, rogpeppe: it means that once a client is using a prefix regexp we can't (say) move the uniter into the machine agent without a load of extra hassle
<fwereade> TheMue, rogpeppe: there'll be hassle anyay
<fwereade> TheMue, rogpeppe: but that will make it worse, I think
<rogpeppe> fwereade: how will it make moving the uniter into the machine agent harder?
<TheMue> fwereade: if you talk about a "client", about what *exactly* do you talk? men, machines?
<fwereade> TheMue, rogpeppe: if we specify *what output we're interested in* rather than *certain coincidental features of that output* we get to change things freely internally and just need to fix them at the boundaries
<fwereade> TheMue, rogpeppe: both
<rogpeppe> fwereade: ah, each log entry is prefixed with the file it came from?
<fwereade> rogpeppe, yeah -- and while I think we will need to hack that about a bit regardless, having external clients seeing those details directly will just further constrain us
<TheMue> fwereade: as I said, admins are used to drill down. more problematic are hard coded machines to me. where are they and what exactly do they expect from the log output?
<fwereade> TheMue, you're writing one, aren't you? the CLI client...
<TheMue> fwereade: here our log output is more than often enough not machine readable
<TheMue> fwereade: the CLI is used by the admin who is drilling down
<TheMue> fwereade: he is used to do so, with all current log formats
<TheMue> fwereade: that's part of her job since years
<fwereade> TheMue, the admin who has to remember what version of juju is running on the server side to get the right messages? that seems unlikely to lead to general rejoicing
<TheMue> fwereade: to support error analysis and monitoring by machines we need an absolutely different way of logging informations
<fwereade> TheMue, in case it's not clear I am 100% opposed to making people type `filter=^machine-1` on the CLI
<TheMue> fwereade: tal /var/log/messages  | grep "something"
<fwereade> TheMue, I would much rather see it in juju language: `1 2 3/lxc/2 wordpress/7 mysql/3`
<TheMue> fwereade: but I'm interested in ... | grep ' ERROR '
<fwereade> TheMue, yeah, that's a completely different conversation
<rogpeppe> fwereade: so if they do that and then see the log output, how do they know which log line corresponds to which entity?
<TheMue> fwereade: or ... | grep failed
<fwereade> TheMue, you can and should be able to filter by regexp
<fwereade> TheMue, but regexp filtering is not appropriate for determining message source
<TheMue> fwereade: sorry, different opinion by own experience here
<TheMue> fwereade: often enough I start by "I don't know anything, so take a look."
<TheMue> fwereade: and then, by getting hints in larger logs, I take deeper looks
<rogpeppe> fwereade: for example, I have suggested to the GUI team that if they're monitoring the log output from several units (perhaps hundreds) that they should use only a single log stream, and then demultiplex it at the client side
<TheMue> fwereade: and those are not only single machines or units
<fwereade> TheMue, no objections there
<TheMue> rogpeppe: good idea too, didn't thought of it so far
<rogpeppe> fwereade: one possibility that came to mind earlier: we could provide an API call that returns a regexp suitable for filtering the log according to a set of specified entities
<fwereade> TheMue, rogpeppe, AFAICS it's still not an argument for making clients filter by prefix
<fwereade> rogpeppe, that's maybe interesting, but it feels like the time spent to implement it would be better spent on just writing the API at the appropriate level in the first place
<rogpeppe> fwereade: that would enable clients to demultiplex the log stream themselves, which just specifying the filter in terms of entities would not
<rogpeppe> fwereade: (assuming that's what you mean by "writing the API at the appropriate level")
<fwereade> rogpeppe, but transforming on the way out *would* I think allow demuxing
 * TheMue feels sad - having a now nicely working solution on API and CLI, with local provider and <= 1.16 support
<rogpeppe> fwereade: transforming into what format on the way out?
<TheMue> rogpeppe: some kind of entities where the tag is a field, like the timestamp, the logging class and the message
<rogpeppe> TheMue: it's not your fault - this is stuff that has not been thrashed out before
<fwereade> rogpeppe, possibly the one we have right now, just prefixing by entity tag -- but *officially* in that format, not just by conincidence
<rogpeppe> fwereade: agreed
<TheMue> rogpeppe: the solution, as it is, would already help people *today*, while changes later surely can be done
<rogpeppe> fwereade: i would like to take the time to define a format.
<rogpeppe> fwereade: but i agree with TheMue - what's there now is useful and better that what we already have
<rogpeppe> fwereade: (and also we want the regexp stuff too, so it's not like we'd be throwing anything away in the future)
<fwereade> TheMue, well, what we *originally* had was --include and --exclude by entity
<rogpeppe> fwereade: in pyjuju?
<fwereade> TheMue, rogpeppe: yes; was it not clear that we were still trying to go for feature parity here?
<fwereade> TheMue, rogpeppe: the existing implementation was known to be a filthy hack
<rogpeppe> fwereade: sure - i'd like that.
<fwereade> TheMue, rogpeppe: extending that hackery is less than ideal
<rogpeppe> fwereade: but i don't want to push TheMue's branch back by another couple of weeks while we sort all this out
<fwereade> TheMue, rogpeppe: especially since we'll be stuck with it for 5 years
<fwereade> TheMue, rogpeppe: IIRC TheMue's first implementation at least had include-by-tag, because I explicitly asked for it
<rogpeppe> fwereade: i *think* that the current branch could reasonably be the basis for something that *does* provide explicit tag-based filtering
<TheMue> fwereade: --include / --exclude? sorry, what do I miss?
<fwereade> rogpeppe, ok, but anything we land in the next couple of days is going to be in 1.18
<fwereade> TheMue, pyjuju
<TheMue> fwereade: ah, ok
<rogpeppe> fwereade: i think that's ok - we can explicitly state that the log file format will probably change
<fwereade> TheMue, rogpeppe: why even land it if it can't help the gui?
<TheMue> fwereade: using the current format it should be no problem to add a flag --tag that creates a filter
<fwereade> TheMue, the CLI shouldn't be using tags as input, should it?
<TheMue> fwereade: why doesn't it help the gui?
<TheMue> fwereade: the gui can pass filters too
<fwereade> TheMue, because if the format is going to change, the gui will need to change as well
<TheMue> fwereade: that's called change management, yes *scnr*
<fwereade> TheMue, this is *exactly why* I care about doing it by tag
<TheMue> fwereade: what do we do if the tag format changes?
<fwereade> TheMue, and why we had a couple of rounds on the original CL in which I tried to make sure you put the transformation from tag to prefix at the right layer
<fwereade> TheMue, I thought this *had* been hashed out
<rogpeppe> fwereade: blame me
<fwereade> TheMue, we don't change the tag format
<TheMue> fwereade: just found "A camel is a horse designed by committee.", maybe that matches here
<TheMue> fwereade: if we don't change the tag format, why aren't you sure that we don't change the log format?
<fwereade> rogpeppe, TheMue: I do not care about blaming anybody, we should all be fundamentally aligned here...
<TheMue> fwereade: my experience is that everything can change over time and the process has to handle it
<rogpeppe> fwereade: one possibility: we specify that, whatever format we decide on subsequently, we will define it so that the entity tag is at the start of the line
<fwereade> TheMue, the tag format is the language of the API, and we're stuck with it
<fwereade> TheMue, the log format has changed several times already
<rogpeppe> fwereade: but leave everything else unspecified for now
<rogpeppe> fwereade: that then makes the current scheme ok for future use
<TheMue> fwereade: sounds like plan, but I've seen often enough things changing in long running projects. typical maintenance troubles
<TheMue> fwereade: that's why I'm not as sure about it as you are
<fwereade> rogpeppe, except that we *still* have to figure out what regexps refer to entities and unpick them if//when we use a distributed log db
<TheMue> fwereade: and that's why I see no problem in change but I *very high* need in doing everything possible to enable changes
<fwereade> rogpeppe, if we at least separate the channels for entity specification and message filtering we're in a slightly better position
 * TheMue gets philosophical
<rogpeppe> fwereade: that's actually not hard to do
<rogpeppe> fwereade: http://golang.org/pkg/regexp/#Regexp.LiteralPrefix
<fwereade> rogpeppe, `|`?
<rogpeppe> fwereade: hmm, except that won't quite work
<rogpeppe> fwereade: yeah :-)
<fwereade> TheMue, I don't follow -- ISTM that having clients operate directly wrt an internal format detail makes change harder -- expand please?
<fwereade> TheMue, I am +1000 on designing for change where possible
<fwereade> TheMue, if I felt we were doing that to an adequate standard I would not be fussing like this
<rogpeppe> fwereade: that's an interesting point BTW
<rogpeppe> fwereade: (the possibility of a distributed-by-entity log file)
<fwereade> rogpeppe, ah I hadn't thought of it that way actually :)
 * fwereade had started feeling smug for a moment there
<fwereade> rogpeppe, TheMue: the heart of my argument is, I think, what I said a few lines back: entity specification and message filtering are different things, and we shouldn't conflate them
<rogpeppe> fwereade: ok, i think i'm sold
<rogpeppe> fwereade: but...
<rogpeppe> fwereade: i still think that this CL is a good foundation for putting entity specification in the API
<rogpeppe> fwereade: i think it's pretty much a strict subset of that
<rogpeppe> fwereade: so can i suggest we get it merged and then move on with adding explicit entity specification in the command line and the API?
<TheMue> fwereade: I'm still searching for the use case where specifying the entity tag would help me
<fwereade> rogpeppe, TheMue: I could live with that *if* we weren't just about to release 1.18 and have to carry what lands
<fwereade> TheMue, foo/1 is in an error state, I want to see the logs for foo/1
<TheMue> fwereade: yes, I can do so
<fwereade> TheMue, your *example* is "I want to see the logs for machine 1" ;p
<rogpeppe> fwereade: we can explicitly say that entity specification is not supported yet
<rogpeppe> fwereade: but it still gives people (and command-line clients in particular) a useful feature
<TheMue> fwereade: yes, I can filter for it, no problem, but I can even filter deeper or more flexible
<fwereade> TheMue, rogpeppe: entity filtering is honestly trivial to add afaics, compared to the issues with /var/log/juju
<rogpeppe> fwereade: you're probably right. but i'd still do it as a separate CL, and then maybe land them together
<fwereade> TheMue, and you could also do so with direct entity specification
<fwereade> TheMue, if you want complete flexibility you can still do it by watching the environment logs
<rogpeppe> fwereade: i think it's a bit tough to say that a single CL has to land a complete feature
<fwereade> TheMue, and filtering from there
<fwereade> rogpeppe, I'm not saying it does, necessarily, but if we release with this particular half-feature it encourages clients like the GUI to start depending on prefix filtering
<rogpeppe> fwereade: in that specific case it's easy - we tell them not to depend on it
<TheMue> fwereade: sure I can, but I don't see the advantage
<fwereade> TheMue, correct me if I'm wrong: the GUI use case is "show logs for X entity"
<TheMue> fwereade: operators simply grep through logs or use smnp with according monitoring applications (what even would be by far better)
<TheMue> fwereade: what they can do by passing the filter
<TheMue> fwereade: yes
<fwereade> TheMue, if the only way they can do that is by depending on implementation details, we have a problem, because we're suddenly unable to change those impl details without breaking clients
<TheMue> fwereade: isn't implementing an API with a specific "tag" argument some kind of changeable implementation detail too?
<fwereade> TheMue, so the GUI shouldn't have a "show logs" button on an entity? it should just have a logging pane where users type regexps?
 * TheMue things of the hard changes from zk to mongo, from state to api ...
<fwereade> TheMue, the tag format is *explicitly* the unambiguous entity identifier for use in the API
<fwereade> TheMue, if we have to change that then *everything* breaks
<TheMue> fwereade: "show logs" uses the regex for the current log format (could be changed when the log format ever changes) and "drill down" allows to enter a regex
<TheMue> fwereade: like the change from zk to mongo
<TheMue> fwereade: or the change from py to go
<fwereade> TheMue, so you'd rather add an API that converts from tag to reges, and make people use that, than just specifythe tag?
<TheMue> fwereade: once again, I've seen enough software changing during my life
<fwereade> TheMue, believe me, so have I
<TheMue> fwereade: users sees button, gui code in case of only one entity passes the correct filter for it (like it would pass the correct tag). additional ways provide more flexibility
<fwereade> TheMue, but I am somewhat baffled that you're advocating depending on an implementation detail, and pooh-poohing objections by saying that a defined and published external identifier ormat might also change
<fwereade> TheMue, *how does the gui know what the correct format is*?
<fwereade> TheMue, regexps good
<fwereade> TheMue, do not drop regexp support
<fwereade> TheMue, just, please, do not confuse it with entity specification
<TheMue> fwereade: how does entering tags *and* filters work?
<TheMue> fwereade: double grepping for tag first and then the regexp in there?
<fwereade> TheMue, given the current log format, yes, I think so
<TheMue> fwereade: and when the regexp contains a ^, is it the beginning of the rest of the message behind the tag?
<rogpeppe> [09:58:50] <TheMue> fwereade: double grepping for tag first and then the regexp in there?
<rogpeppe> that seems like the model i was thinking of
<rogpeppe> the tag is a first-level filter
<fwereade> TheMue, it *might* be nice if that were the case, yes, but I understand that's tedious
<rogpeppe> fwereade: i don't think that should be the case, FWIW
<TheMue> fwereade: I already have a time problem as Curtis asked Abel and me to support Dave
<rogpeppe> fwereade: i think the regexp should exactly match against the lines produced
<TheMue> fwereade: so no problem to enlarge the time problem :D
<fwereade> rogpeppe, TheMue: yeah, it's probably a slightly different thing -- messagefilter=
<fwereade> TheMue, haha
<fwereade> TheMue, rogpeppe: ISTM that adding a query arg and grepping by that is not a major burden
<rogpeppe> fwereade: i really think this CL could land though
<rogpeppe> fwereade: it's not hard to do, no
<fwereade> TheMue, rogpeppe: I remain much more worried about the log-location stuff
<rogpeppe> fwereade: i'm just replying to that
 * TheMue passes his branch to rogpeppe for doing the not so hard to do stuff ;)
<fwereade> TheMue, rogpeppe: ISTM that it's not hooked up to rsyslog at all, and that this is a problem
<TheMue> fwereade: yeah, the whole logging needs a rework
<TheMue> fwereade: especially that the part of the rsyslogd and all-machines.log is a fire-and-forget
<rogpeppe> fwereade: the idea is not that log-location is arbitrarily specifiable
<fwereade> TheMue, but adding log-location adds a whole new way to break it
<fwereade> rogpeppe, but this CL makes it so
<rogpeppe> fwereade: yes - i think that can be worked around though
 * fwereade frets but waits to read the response
<rogpeppe> fwereade: by, for instance, checking in Prepare
<TheMue> fwereade: the log-location has been needed to give information only available during bootstrap to the state server later
<TheMue> fwereade: but I'm not happy about it too
<TheMue> fwereade: it's only for the beast "local provider"
<TheMue> fwereade: we won't have that problem if machine-0 of the local provider would be a lxc container too
<TheMue> fwereade: but maybe enough other probs then ;)
<fwereade> TheMue, yeah, but nested lxc is a beast
<fwereade> TheMue, we need something running on the host to add more containers on the host
<rogpeppe> fwereade: why would it need to nest?
<rogpeppe> fwereade: that's true
<TheMue> rogpeppe: containers -to 0
<rogpeppe> TheMue: that doesn't need to work - you can't do that to *any* of the machines in the local provider
<fwereade> TheMue, not even that
<fwereade> TheMue, just adding machines 1, 2, 3
<TheMue> fwereade: hmm, a kind of extra daemon talking to the provisioner? no, too heavy
<rogpeppe> fwereade: but it could be a very limited-scope thing, rather than the whole shebang
<TheMue> fwereade: yep, just seen your note
<fwereade> TheMue, yeah, I've been round that argument a couple of times in my head :)
<TheMue> fwereade: come on, mr brain, you can do it in a couple of hours, can't you?
<fwereade> rogpeppe, we *could* implement a daemon that exposed a cloud-provider-like API and just run that on the host, it's true
<fwereade> TheMue, ;p
<fwereade> rogpeppe, but we didn't
<rogpeppe> fwereade: that would have been my inclination
<fwereade> rogpeppe, might even have been better in hindsight, but hey ho, it is what it is
<rogpeppe> fwereade: so, to get back to log-location, what's a decent way for the local provider to pass the location of the log file to the machine-0 API server?
<fwereade> rogpeppe, modulo upgrades, put it on the machine in state?
<fwereade> rogpeppe, given upgrades, break layering :/
<TheMue> rogpeppe, fwereade: I've chosen the config to not extent the environment entity
<rogpeppe> fwereade: one though i had was that it could go in the agent config file?
<rogpeppe> s/though/thought/
<fwereade> rogpeppe, that sounds plausible, keep going
<rogpeppe> fwereade: it would then be passed into the api server by the machine agent
<fwereade> rogpeppe, yeah, I think I like that
<rogpeppe> fwereade: and set up at bootstrap time by the provider
<rogpeppe> darn, i nearly suggested that, but thought that log-location was actually fine in practice
 * TheMue now even more thinks of passing the stuff to rogpeppe 
<rogpeppe> TheMue: i'm very sorry
<TheMue> rogpeppe: who demands changes has to do them ;P
<rogpeppe> TheMue: fwereade then :-)
<TheMue> rogpeppe: h5
<fwereade> $ juju deploy rogpeppe -n 5
<fwereade> ERROR: blah blah
<fwereade> dammit
<rogpeppe> ERROR: no units available
 * fwereade wonders if he can maybe get dimitern onto it -- jam?
<mgz> fwereade: no jam back quite yet
<TheMue> mgz: yep, finding pics from capetown in my fb timeline from time to time
<TheMue> s/from/og/
<TheMue> s/og/of/
<TheMue> aaargh
<mgz> TheMue: weel, he's back in dubai, but out right now
<TheMue> mgz: ah, ok
<fwereade> TheMue, what is it you'll be doing for davecheney
<fwereade> ?
<TheMue> fwereade: quickly forwarded you the mail by curtis. we not yet started, need still access to the according machines to use for development
<mattyw> any volunteers for helping me work out what's going on inside juju/api.go:212 (apiConfigConnect)
<mgz> mattyw: what's confusing you there?
<mgz> summary is we try to connect to more than one api server at once
<mgz> and if we get more than one error,
<jam> mgz: hey, I finally made it
<mgz> prefer displaying the more specific ones
<mgz> jam: just in time for standup - 1:1 after?
<jam> mgz: well, I'm meeting with nate after, but otherwise I would
<mattyw> mgz, ok - I'm struggling to see where the two connections happen - I'm implenting the id work - so you can add users and login at the command line-  and at the moment entering an invalid login doesn't fail - because it falls back to the user-admin
<mgz> mattyw: l156/l174
<mgz> and utils/parallel/try.go
<TheMue> rogpeppe: could you add a sketch of you log-location alternative to the CL comments?
<rogpeppe> fwereade: standup?
<mattyw> mgz, thanks very much - I think I can see the next thing I need to do
<jam> wallyworld: standup?
<rogpeppe> dimitern, fwereade, jam: this was the algorithm i had in mind: http://paste.ubuntu.com/6954172/
<dimitern> rogpeppe, looking
<rogpeppe> it's not easy to implement efficiently though if we're filtering many units
<rogpeppe> s/units/tags/
<rogpeppe> the filtering operation is O(number of tags)
<dimitern> looks reasonable in general
<rogpeppe> if we made the regexp match only the text following the tag, then we could be considerably more efficient (two regexp matches for any line, regardless of the number of units) but dealing with '^' in the regexp would be awkward
<jam> rogpeppe: couldn't you always just mix the regexes together with '|' ?
<jam> (^foo)|(^bar) should work fine
<rogpeppe> jam: not quite
<rogpeppe> jam: because the filter regexp starts from the beginning of the line, and that's also where the tag regexp starts
<jam> rogpeppe: also, I'm not sure if your tagFilter matching is *quite* right because "unit-1" ends up matching "unit-10" which I don't think is intentional
<rogpeppe> jam: you could do something like this though: http://paste.ubuntu.com/6954294/
<rogpeppe> jam: yeah, the prefix should include the final :
<rogpeppe> jam: the above code won't work with '^', but it's not too hard to make it work, i think, although it's slightly icky
<jam> rogpeppe: I also thought we wanted to support "service" as well, which would be a prefix without the :, but probably with the -
<rogpeppe> jam: yeah, definitely
<rogpeppe> jam: "service-wordpress" would turn into the prefix "unit-wordpress-" i think
<rogpeppe> jam: the same kind of thing applies to the second example
<rogpeppe> jam, dimitern: couldn't resist making it work: http://paste.ubuntu.com/6954469/
<dimitern> rogpeppe, nice!
<rogpeppe> dimitern: the icky bit is line 118
<dimitern> rogpeppe, and 123 i guess
<rogpeppe> dimitern: well, that's only a consequence of the other
<rogpeppe> dimitern: in practice this is not actually a problem
<rogpeppe> dimitern: it just feels a bit dubious
<dimitern> rogpeppe, i'll take that into account when i'm doing debug-log
<rogpeppe> dimitern, fwereade: one thing we didn't consider in this was what the command-line interface should look like
<dimitern> rogpeppe, --include (optional, assumed it is) and --exclude (if given), each having tag[=regexp] perhaps?
<fwereade> rogpeppe, list of entities by name-not-tag; empty implies environment; explicit --excludes; I like the name[=regexp] idea
<fwereade> ?
<rogpeppe> i also like the name[=regexp] idea
<rogpeppe> although perhaps ":" might seem more apt
<fwereade> rogpeppe, I think I have a slight preference for `=` but I'm aware that --exclude=foo-bar is a bit weird
<fwereade> --exclude=foo=bar
<rogpeppe> juju debug-log --exclude 0:API wordpress mysql/1
<rogpeppe> juju debug-log exclude :API
<rogpeppe> juju debug-log --exclude :API
<rogpeppe> rather
<rogpeppe> my preference for : is mainly from the fact that it's a very different kind of association from the other places = is used on the command line
<dimitern> what's the ":" in there?
<marcoceppi> any thoughts on this? https://bugs.launchpad.net/juju-core/+bug/1281583 I'm pretty sure I can hack it in, was wondering if there was any objections
<_mup_> Bug #1281583: Juju should NOT put a .git directory in $CHARM_DIR <juju-core:New> <https://launchpad.net/bugs/1281583>
<rogpeppe> dimitern: it's my preference instead of "="
<dimitern> rogpeppe, well, it's not entirely expected from a command-line argument formats
<rogpeppe> dimitern: is ":" special to the shell?
<dimitern> rogpeppe, not really, it's a path separator
<rogpeppe> dimitern: only under windows
<dimitern> rogpeppe, but it looks weird and non-*nix standard for CLI
<rogpeppe> dimitern: and that's not really relevant here, i think
 * rogpeppe tries to think of other places that use "=" as a separator like that
<dimitern> rogpeppe, --exclude=foo=bar is the same as --exclude foo=bar as far as parsing is involved
<rogpeppe> dimitern: most places use it to associate attributes with values, don't they? this isn't quite that
<rogpeppe> dimitern: i agree there
<dimitern> rogpeppe, the only places in a CLI where i think is common is to define host:port or ipv6 addresses
<dimitern> marcoceppi, fwereade is working on replacing the need for git entirely in the uniter
<rogpeppe> dimitern: usually the identifier on the lhs of an "=" is non-optional; i guess we could make that the case here though.
<rogpeppe> dimitern: so "juju debug-log =someregexp" becomes illegal and you have to do "juju debug-log environment=someregexp" instead
<rogpeppe> dimitern: somehow the equality sign seems slightly intuitively wrong, as there's no assignment or equality; we're saying "here's a tag and a filter that applies within that tag"/
<rogpeppe> another possibility might be to use square brackets: wordpress[regexp]
<marcoceppi> dimitern fwereade: will this land for 1.18?
<dimitern> marcoceppi, possibly
<dimitern> rogpeppe, how about pairs of --include/exclude name --filter regexp ?
<rogpeppe> dimitern: not keen - it would be pain to do, and it doesn't really fit well with standard flag parsing logic
<rogpeppe> s/pain/a pain/
<dimitern> marcoceppi, the initial step is proposed (in charm package), but the uniter changes are not yet
<dimitern> rogpeppe, [] will interfere with the regexp itself
<rogpeppe> dimitern: not really
<rogpeppe> dimitern: it's trivial to strip off before sending the regexp
<dimitern> rogpeppe, i mean from the ux perspective - is it part of it? is it not? should I escape it? pretty much the same questions I keep asking myself with the weird emacs grep regexps
<rogpeppe> dimitern: i agree that the plain string concat is simpler
<dimitern> rogpeppe, we can get even weirder --wordpress[=regexp] (i.e. --<name>[=regexp])
<rogpeppe> dimitern: no we can't :-)
<dimitern> rogpeppe, or configure-style --with-<name>[=regexp] and --without-<name>[=regexp]
<rogpeppe> dimitern: that's still bad :-) flags should have a small known set of names
<dimitern> rogpeppe, or just plain old -i (--include) name1[=regexp1] name2[=regexp2] -e (--exclude) name3[=regexp] ...
<dimitern> i.e. everything after -i (--include) [default] is name-regexp pairs, same for -e (--exclude)
<rogpeppe> dimitern: tbh, i think william's idea of having excludes mentioned explicitly seems reasonable.
<rogpeppe> dimitern: the only point i quibbled was whether to use "=" or ":" as a separator
<dimitern> rogpeppe, if it's just a *minor* quibble, then can you live with = ? :)
<rogpeppe> dimitern: i guess. still seems a bit wrong to me, but we'll see what people think.
<dimitern> rogpeppe, what other people? you want to discuss it on the ML ?
<rogpeppe> dimitern: well, we probably should. i was really thinking of peoples' reactions when they see the new feature
<dimitern> rogpeppe, right, that'll blow a minor implementation detail way out of proportion, but i guess it's worth at least announcing it :)
<rogpeppe> dimitern: how about writing the command docs as you'd get them from juju help debug-log
<rogpeppe> ?
<dimitern> rogpeppe, sgtm
<dimitern> rogpeppe, i'm about to write one about the environment/api urls/allwatcher, so I'll write about this one as well
<rogpeppe> dimitern: cool
<dimitern> rogpeppe, so how does the allwatcher report changes that include an environment tag?
<dimitern> rogpeppe, I couldn't see that in params.Delta
<rogpeppe> dimitern: good question - one mo, i'll have a look
<rogpeppe> dimitern: hmm, looks like it's the UUID-based environ tag
<rogpeppe> dimitern: the only place that does that is annotation changes
<dimitern> rogpeppe, can you point me to the code?
<rogpeppe> dimitern: the relevant piece is in the State.Environment method
<dimitern> rogpeppe, ta!
<rogpeppe> dimitern: where it initialises the annotator value with env.Tag()
<rogpeppe> dimitern: perhaps you could talk to the GUI guys about making their code compatible with both "environ" and "environ-343ab464"
<dimitern> rogpeppe, but how does the response to AW.Next() look like if there's a change to env's annotations?
<dimitern> rogpeppe, where's the actual tag included?
<rogpeppe> dimitern: the Delta.Entity field will be an AnnotationInfo containing the tag
<dimitern> rogpeppe, ah, I see, cheers
<fwereade> mgz, sorry to hassle you when I know you're doing bugs, but I was wondering about https://code.launchpad.net/~dstroppa/juju-core/joyent-provider-storage/+merge/200851 -- can this be landed now?
<fwereade> TheMue, btw, not sure we said explicitly: dimitern is taking over your debug-log branch, so you can go do hardware enablement with a clear conscience :)
<mgz> fwereade: I think so, but that does entail bringing in the gojoyent library
<fwereade> mgz, ahh... and I'm not sure I ever looked at that properly >_<
<fwereade> mgz, level of confidence?
<natefinch> man, we really need a --quiet or something for the tests... when a bunch of things fail I just get a billion lines of useless log messages that make it impossible to actually see what tests are failing.
<mgz> fwereade: I think we can do it would risking breaking anything else
<mgz> *without
<mgz> ...that was a confusing braino
<fwereade> mgz, I managed to parse it :)
<fwereade> mgz, ok, cool
<fwereade> mgz, the joyent provider doesn't get compiled in anyway, does it?
<mgz> we've not added it to the magic place yet, no
<fwereade> mgz, ok, cool, please do land it in your, uh, Copious Free Time...
 * fwereade has to go see laura doing rudimentary flamenco, later all
<natefinch> fwereade: sounds like fun :)
<mgz> okay, I shall queue it up
<TheMue> fwereade: thx for info, I already thought so following the discussions here
<sinzui> I anyone working  on bug 1271937
<_mup_> Bug #1271937: Use juju-mongodb when the package is available <arm64> <ci> <mongodb> <ppc64el> <trusty> <juju-core:Triaged> <https://launchpad.net/bugs/1271937>
<TheMue> fwereade: and if my branch so far, as well as the Tailer, will find their way into Juju I'm happy
<natefinch> sinzui: I'm working on landing it
<natefinch> sinzui: hitting a ton of spurious test failures
<sinzui> natefinch, oh good. CI ran out of disk space over the weekend. Once your branch is merged and CI passed it, I will release. Can you ping me when your branch is merged?
<natefinch> sinzui: sure thing
<sinzui> Thank you!
<natefinch> mgz, rogpeppe, dimitern: easy review?  https://codereview.appspot.com/65460043/
<dimitern> natefinch, looking
<natefinch> dimitern: ta
<mgz> dimitern wins
<rogpeppe> natefinch: reviewed
<natefinch> mgz: looks like rogpeppe wins where it counts ;)
<dimitern> natefinch, reviewed
<dimitern> it counts how thorough you review as well :P
<natefinch> rogpeppe, dimitern: thanks
<natefinch> dimitern: haha yes, definitely
<rogpeppe> dimitern, natefinch: not entirely sure about "PrependPath", as it doesn't indicate the "patch" nature of it
<dimitern> rogpeppe, natefinch, the thing that irks me a bit is that seeing s.PatchPath(blah) doesn't immediately tell me what happens to blah
<rogpeppe> dimitern: yeah, i definitely see that too
<dimitern> rogpeppe, but I'm +1 for ExecPath
<rogpeppe> dimitern: i'm trying to think of a better way
<natefinch> rogpeppe, dimitern:  I like PatchEnvPath better than PatchExecPath but I agree, getting some "prepend" in the name would be nice
<rogpeppe> natefinch: one possibility: s.PatchEnvPath(dir, testbase.Prepend)
<rogpeppe> vs s.PatchEnvPath(dir, testbase.Overwrite)
<dimitern> natefinch, rogpeppe, that sgtm
<rogpeppe> it makes it slightly longer, but the use is rare enough that i don't think it matters
<arosales> rogpeppe, fwereade, sinzui could you guys give me a very high level features targetted for 1.18
<rogpeppe> and i'm sure there are places where we actually want to overwrite rather than prepending
<natefinch> rogpeppe: except that almost everywhere (possibly 100% everywhere), we prepend, not overwrite
<sinzui> arosales, the 1.17.x release notes
<arosales> sure but I think we still have some in the queue correct?
<sinzui> arosales, https://launchpad.net/juju-core/+milestone/1.17.0 https://launchpad.net/juju-core/+milestone/1.17.1 https://launchpad.net/juju-core/+milestone/1.17.2
<rogpeppe> natefinch: yeah - but it reads nicely, and actually perhaps some of those places don't actually want to inherit the system path
<arosales> sinzui, thanks any major features targetted post 1.17.2?
<natefinch> rogpeppe: but I'm not going to spend time to figure out what tests really don't want to inherit the system path.  All I was trying to do was wrap up some common code to do things the right way.   Complicating the interface because sometime we might need to overwrite the path does not seem like a good idea.
<sinzui> arosales, juju-mongodb
<rogpeppe> natefinch: that's ok - i was only trying to think of a better name. PatchPrependEnvPath doesn't read so well.
<sinzui> arosales, juju-run, API-every-where is the hidden feature for developers.
<rogpeppe> natefinch: or maybe it's actually ok, i'll leave it to your judgement
<natefinch> rogpeppe: I know, it's terrible, that's why I was just going to do PatchEnvPath....  I dunno
<arosales> sinzui, thanks
<rogpeppe> natefinch: i think it reads quite nicely with the extra arg though
<rogpeppe> natefinch: which is why i suggested it
<natefinch> rogpeppe: yeah, if we could default it to prepending, that would be cool, but I hate adding a parameter when we're never actually going to set it differently (at least for now).
<rogpeppe> natefinch: PathEnvPathByPrependingDir ?
<rogpeppe> s/Path/Patch/
<natefinch> rogpeppe: can we somehow make it a FactoryBean, too? ;)
<natefinch> rogpeppe: PatchEnvPathPrepend seems ok
<rogpeppe> natefinch: i'd be ok with that
<natefinch> rogpeppe: cool.
<dimitern> i was going to suggest just that earlier in fact ;)
<hazmat> ugh.. regex
<hazmat> why
<hazmat> just multi-include multi-exclude
<hazmat> with machines/units/services
<hazmat> i thought that got resolved 12 hrs ago
<hazmat> dimitern, ^
<dimitern> hazmat, because that's what we discussed today and hence the mail to ask for comments :)
<hazmat> sent
 * rogpeppe is done for the day
<rogpeppe> g'night all
<wallyworld> fwereade: can i poke you to take another look at https://codereview.appspot.com/63730043/ when you next get a chance? i think all the issues have been fixed
<fwereade> wallyworld, looking
<fwereade> wallyworld, LGTM, tyvm
<wallyworld> awesome, thanks for looking
<fwereade> wallyworld, np
<fwereade> wallyworld, would you let waigani know that I'd really like to see something that builds on the axw's Policy stuff for in-state environ validation? and that I *think* that, with replaceSettingsOp, that can actually nail all the issues I'm currently aware of around environ config changes, and it would make me ever so happy ;)
<wallyworld> ok, we like to make you happy
 * fwereade approves of this :)
#juju-dev 2014-02-19
<davecheney> axw: http://paste.ubuntu.com/6957563/
<davecheney> can you assist with a local provider issue
<axw> buh
<axw> umm
<axw> what version of juju is that?
<axw> oh, 1.17.3.1 ...
<axw> this looks a lot like a bug that was fixed already
<axw> is trunk up to date?
<davecheney> that is a pull as of 60 minutes ago
<davecheney> axw: is it that juju doenst' know ppc64 is a valid arch ?
<axw> davecheney: so there's two problems
<axw> 1) can't bootstrap
<axw> 2) destroy is finding the wrong binary
<axw> local provider destroy now calls juju again with sudo under the covers
<axw> seems to be finding an old binary that doesn't have the -y flag
<axw> davecheney: as for why it can't find matching tools... I have no idea. could be because of the valid arches, as you say
<axw> davecheney: can you try with --debug please?
<axw> davecheney: you may need to update environs/tools/tools.go, makeToolsConstraint
<axw> toolsConstraint.Arches = ...
<axw> davecheney: and I've filed https://bugs.launchpad.net/juju-core/+bug/1281863 to fix the destroy issue
<_mup_> Bug #1281863: local: Destroy assumes it is called from "juju destroy-environment" <local-provider> <juju-core:Triaged> <https://launchpad.net/bugs/1281863>
<davecheney> axw: thanks
<davecheney> there is still some confusoin about the 'official' name for ppc64
<davecheney> go calls it ppc64, but uname -m and others append a suffix
<davecheney> axw: 2014-02-19 03:16:11 DEBUG juju.environs.simplestreams simplestreams.go:471 index file has no data for product name(s) ["com.ubuntu.juju:12.10:amd64" "com.ubuntu.jâÂ·Â·Â·Â·Â·Â·Â·
<davecheney> uju:12.10:i386" "com.ubuntu.juju:12.10:arm" "com.ubuntu.juju:12.04:amd64" "com.ubuntu.juju:12.04:i386" "com.ubuntu.juju:12.04:arm" "com.ubuntu.juju:13.10:amd64" "âÂ·Â·Â·Â·Â·Â·Â·
<davecheney> com.ubuntu.juju:13.10:i386" "com.ubuntu.juju:13.10:arm" "com.ubuntu.juju:14.04:amd64" "com.ubuntu.juju:14.04:i386" "com.ubuntu.juju:14.04:arm" "com.ubuntu.juju:13âÂ·Â·Â·Â·Â·Â·Â·
<davecheney> .04:amd64" "com.ubuntu.juju:13.04:i386" "com.ubuntu.juju:13.04:arm"]
<davecheney> basicallyt not ppc64 arch
<axw> davecheney: even with the change?
<axw> to tools.go
<davecheney> sorry, missed that bit
<davecheney> will bodge
<davecheney> axw: it worked!
<axw> swoit :)
<davecheney> patch incoming
<davecheney> axw: sonofabitch
<davecheney> but can't I get the environ/tools tests to recognose trusty as a series
<axw> umm
<axw> davecheney: does the csv file have the right thing in it?
<davecheney> i thought this was all table driven from ../envions/testing/tools.go
<axw> oh tests
<davecheney> yeah, just trying to add a test that shows we can find ppc tools
<axw> davecheney: not really sure sorry. I guess one of the tests is using version.Current, but uploading fake tools for only older series
<davecheney> i'll keep hacking on it
<davecheney> i can at least get to the next problem
<mwhudson> davecheney, axw: are you working on https://bugs.launchpad.net/juju-core/+bug/1274755 ?
<_mup_> Bug #1274755: simplestreams test metadata only lists tools for arm and amd64 <hs-arm64> <tech-debt> <juju-core:Triaged> <https://launchpad.net/bugs/1274755>
<axw> mwhudson: I'm not, but davecheney has been working in that vicinity...
<mwhudson> ok
<dimitern> rogpeppe, hey
<rogpeppe> dimitern: hiya
<chris38> hi, what 's the state of juju add-machine kvm ?
<dimitern> rogpeppe, is there a particular reason debug log is streamed through a websocket rather than https?
<rogpeppe> dimitern: because i consulted with the GUI folks and that's what they suggested
<rogpeppe> dimitern: websockets are designed for long-lived connections
<dimitern> chris38, it's done afaik
<rogpeppe> dimitern: which https connections aren't really
<dimitern> rogpeppe, they could be, but meh
<dimitern> rogpeppe, ok, and the log-location passing through the agent conf should be in StateMachineConfig perhaps?
<rogpeppe> dimitern: ah, there is a very good reason it's a websocket actually
<rogpeppe> dimitern: 'cos it's a bidirectional connection
<dimitern> rogpeppe, ah, that looks like a better reason :)
<rogpeppe> dimitern: yeah, StateMachineConfig looks like a good place for it
<chris38> I built juj from source the command is executed, but the server stay in pending mode, do I have to install some libvirt stuffs on the maas vm ?
<chris38> dimitern, any tip / doc on how to make juju add-machine kvm work ?
<dimitern> chris38, I think in order to be able to spin up kvm machines certain dependencies have to be met, libvirt included, let me browse through the commit log for clues
<dimitern> axw_, does add-machine support adding kvm containers?
<dimitern> axw_, it seems it should, but I can't see updated help docs or tests about it
<axw_> dimitern: I'm not sure sorry
<jam1> dimitern: thumper would be the one to ping about it. It was supposed to work, and the extra libs are supposed to be installed when a unit sees it needs a KVM target
<dimitern> jam, chris38, so if it doesn't work I think it deserves a bug then
<chris38> I'll check more with installing manually libvirt, and submit a bug
<chris38> what the magic command to update from source and rebuild juju ? after initial go install -v launchpad.net/juju-core/...
<dimitern> chris38, I'm using this handy bash script: http://paste.ubuntu.com/6959163/ - replace /home/dimitern/work/juju-core with the path to your source checkout
<chris38> dimitern, thx ;-)
<rogpeppe> dimitern, jam, fwereade: our standup time seems to have moved back an hour - is that correct?
<jam> rogpeppe: it is now, but that is the same time its been
<jam> did you have a TZ change?
<rogpeppe> jam: no
<rogpeppe> jam: it says an hour later than usual on the calendar
<mattyw> rogpeppe, when I come to submit those two mps for the id stuff - shall I make a bug report and link it to them, or just put all my explanation into the branch/review description?
<rogpeppe> mattyw: i'd just do the latter
<rogpeppe> natefinch: here's that change to the voyeur package i mentioned: https://codereview.appspot.com/66000043
<rogpeppe> a fairly small change - reviews appreciated
<natefinch> rogpeppe: looking
<rogpeppe> natefinch: ta
<hazmat> chris38, go get -u -v launchpad.net/juju-core/...
<hazmat> dimitern, your script doesn't update src
<hazmat> chris38, re kvm, its exactly like adding lxc containers .. but with 'lxc' replaced by 'kvm'
<natefinch> rogpeppe: reviewed
<rogpeppe> natefinch: thanks
<mattyw> rogpeppe, fwereade I've just submitted my first mp for the add|remove user stuff - just the internal stuff so far, the cli will follow shortly - I'm sure there's still work that needs done - but I thought I'd get the ball rolling: https://codereview.appspot.com/61620043/
<rogpeppe> mattyw: i think i've reviewed parts of that before, haven't I?
<chris38> hazmat, yep, https://bugs.launchpad.net/juju-core/+bug/1281994
<_mup_> Bug #1281994: juju add-machine kvm:0 not working with maas <kvm> <juju-core:New> <https://launchpad.net/bugs/1281994>
<dimitern> hazmat, no, it just rebuilds the binaries
 * rogpeppe goes for some lunch
<mattyw> rogpeppe, you've looked at it before but not gone as far as commenting on it
<mattyw> rogpeppe, as far as I remember there was some things that might get moved - but nothing was decided
<hazmat> chris38, could you attach the machine-0.log to that bug
<hazmat> chris38, /var/log/juju/machine-0.log
<chris38> hatch, yep
<hatch> hazmat ^
<hatch> :)
<chris38> oops
<chris38> hazmat, I update to last juju
<hazmat> chris38, ok.. but still need the log
<natef-snowblow> someday it'll stop snowing every 2 days
<mgz> natef-snowblow: warming willing
<fwereade> I'm enjoying the raft paper: "For example, if message exchanges take longer than the
<fwereade> typical time between server crashes, candidates will not
<fwereade> stay up long enough to win an election
<fwereade> "
<rogpeppe> fwereade: i enjoyed the raft paper too
<rogpeppe> fwereade: it made me think that it wouldn't be *too* hard to build something as a custom state server backing for juju
<fwereade> rogpeppe, yeah, that's the direction we're pondering
<rogpeppe> fwereade: my inclination was to start by severely cleaning up go-raft
<fwereade> rogpeppe, I haven't looked at that yet... is it a sorry sight?
<rogpeppe> fwereade: it's not *too* bad. but i'd like to see something with a much smaller interface, that doesn't depend directly on disk access
<fwereade> rogpeppe, isn't storage persistence necessary?
<rogpeppe> fwereade: sure, but persistence should be implemented by a pluggable interface, i think
<rogpeppe> fwereade: the package interface is about 20 times larger than i'd like to see
<fwereade> rogpeppe, heh, we often disagree on such issues, but I'll bear that in mind when I look ;)
<rogpeppe> oh jeeze, *that's* why i'm not seeing log messages - i've imported launchpad.net/loggo, not github.com/loggo/loggo
<rogpeppe> argh
 * rogpeppe is done for the day
<rogpeppe> g'night all
<chris38home__> hazmat, yippi juju add-machine kvm:0 mostly fixed, indeed it stay the same problem than lxc br0 is not brought up,
<hazmat> chris38home__, cool, glad you were able to resolve.. it would still be helpful to attach log to bug, .. is it just bridge-utils install early? that's fixed in trunk which it sounds like your using.[
<chris38home__> I add the interesting part of the lof
<chris38home__> I marked as a duplicate
<chris38home__> hazmat,  https://launchpadlibrarian.net/166797169/machine-0.log
<chris38home__> after ssh-ing on the server and sudo ifup br0, server went up
<chris38home__> concerning firewall, I have seen some gpg --recv-key in the code that don't set proxy, which make fail maas installs
<chris38home__> might only be in fast installer
<chris38home__> I build juju on a wheezy box, builds well but I have got
<chris38home__> 2014-02-19 19:37:16 ERROR juju.cmd supercommand.go:294 invalid series "unknown"
<chris38home__> I tried to dig in the code but couldn't find where is this unknown set ?
<hazmat> chris38home__, its a mapping to image and charm lookup
<hazmat> chris38home__, probably interpreted from lsb_release
<chris38home__> thanks, I was suspecting something like that
<chris38home__> If I just add a new Codename it should do the trick
<rogpeppe1> chris38home__: it's in the version package
<rogpeppe1> chris38home__: it's in the version package
<rogpeppe1> chris38home__: see the readSeries function
<sinzui> natefinch, hazmat: Is this bug legitimate. Is the use of manual provider wrong? https://bugs.launchpad.net/juju-core/+bug/1282235
<_mup_> Bug #1282235: manual provider: juju bootstrap fails with "102 bootstrapping failed, removing state file: exit status 1" <bootstrap> <ci> <manual-provider> <juju-core:Triaged> <https://launchpad.net/bugs/1282235>
<natefinch> sinzui: looking
<natefinch> sinzui: I'm not super familiar with the ins and outs of the manual provider, but that *looks* like it's doing the right thing.... until it fails, obviously.   Is there anything useful in the logs on the machine itself?  The end of the log in the bug description is unfortunately totally unhelpful
<sinzui> thank you for your time natefinch
<davecheney> mwhudson: axw yeah, i'm trying to fix that
<davecheney> as usual, i've fixed the code but can't make the tests pass
#juju-dev 2014-02-20
<mwhudson> davecheney: \o/
<davecheney> mwhudson: got local provider *almost* working yesterday
<mwhudson> davecheney: on ppc64el?
<davecheney> mwhudson: ya
<hazmat> what version of juju started using jenv file
<hazmat> sinzui, abentley there's a separate bug on manual provider trunk, that needs --uploads-tools
<hazmat> hmm.. although it looks like it found 1.17.0 there
<hazmat> sinzui, the traceback on that bug is the same as i reported previously in https://bugs.launchpad.net/juju-core/+bug/1280678
<_mup_> Bug #1280678: manual provider fails to get tools (1.17.2) <manual-provider> <juju-core:Triaged> <https://launchpad.net/bugs/1280678>
<hazmat> the first pastebin has the cli output with --debug
<wallyworld__> waigani: did you want to do the stand up now?
<waigani> wallyworld__: yep 1min
<wallyworld__> axw: it appears the reason local upgrade fails from 1.16 is because the /usr/lib/juju/tools directory is owned by root and so can't be read when running juju upgrade. do you know how we deal with 1.16->1.17 upgrades in other places where 1.16 stuff was written as root?
<axw> umm. why does it matter? the agents run as root?
<wallyworld__> i'm not sure, i can check
<wallyworld__> ha, 1.16 deploy fails error: symlink /var/lib/lxc/ian-local-machine-1/config /etc/lxc/auto/ian-local-machine-1.conf
<wallyworld__> yes, the local jujud for machine 0 does run as root. the required file is there, i'll look further to see why it can't be read
<wallyworld__> but gotta get a unit deployed first
<axw> hurm, that looks like something that might've changed to support trusty?
<axw> the auto thing
<wallyworld__> yeah, i had to manually make the auto directory
<wallyworld__> i thought we fixed that
<wallyworld__> sigh
<wallyworld__> local on trusty is buggered
<wallyworld__> "lxc-start": command get_cgroup failed
<axw> :\
<axw> ah, that's better. phone point was dodgy. bet the bloody ants have gotten into the wires... last time they made a home in our phone
<wallyworld__> axw: better bugs in your phone wires than your code
<axw> heh
<axw> it was pretty horrific. I picked up the phone, and they were swarming around under the screen
<wallyworld__> \o/
<wallyworld__> axw: i've given up getting the local provider working in trusty for now - i'll ask tim about it next week and/or raise it in the group meeting. but the root cause issue was that i was using the wrong data dir and so have a fix up for that
<axw> okey dokey
 * axw looks
<axw> wallyworld__: reviewed
<wallyworld__> thanks :-)
<axw> just writing a test for mine now... sorry, I was being lazy
<wallyworld__> np :-)
<wallyworld__> given the nature of the issue, i think a test is crucial
<dimitern> rogpeppe, https://codereview.appspot.com/66540044 - a relatively easy review?
<rogpeppe> dimitern: only 1200 lines, trivial :-)
<rogpeppe> dimitern: actually i'm on another review currently, will look after that
<hazmat> is thumper on vacation?
<dimitern> hazmat, yep, this week
<dimitern> rogpeppe, cheers :) it's not that bad really
<rogpeppe> wallyworld__: hiya
<rogpeppe> wallyworld__: i was just looking at https://codereview.appspot.com/66540044
<rogpeppe> oops, wrong URL!
<rogpeppe> https://codereview.appspot.com/65740048, of course
<jam> fwereade: just to let you know, I'm trying to get into the hangout, but the google talk plugin crashed, and Trusty wants to do a dist-upgrade that is about a hundred megs, so I should be there *soonish* but I can't guarantee when
<jam> rogpeppe: wallyworld__ ^^
<fwereade> jam, no worries :)
<wallyworld__> lol
<rogpeppe> jam: ok
<mgz> I'm having fun with 2fa/hangouts atm so may take some struggling to get into the meeting
<mgz> okay, backup otps generated, lets try
<rogpeppe> wallyworld__: here's the kind of thing i'm thinking about for the upgrade-waiter worker: http://paste.ubuntu.com/6965038/
<wallyworld__> thanks, will look
<rogpeppe> wallyworld__: the SimpleWorker implementation is in one of nate's in-progress branches
<wallyworld__> ok
<rogpeppe> natefinch: can you make that branch available, so wallyworld__ can use it? (it doesn't seem to be in https://launchpad.net/~natefinch/juju-core/030-MA-HA any more)
<natefinch> rogpeppe: launchpad's URL schema has to be the most inscrutable thing I've ever worked with.  I don't know what it's doing most of the time.  The code should still be there, I certainly didn't do anything to it.  This link works for the website at least: https://code.launchpad.net/~natefinch/juju-core/030-MA-HA
<rogpeppe> natefinch: oh yeah, *code*.launchpad.net
<rogpeppe> natefinch: thanks
<dimitern> rogpeppe, review poke?
<rogpeppe> dimitern: thanks, i needed it :-)
<sparkiegeek> hi guys. I'm having trouble bootstrapping a precise environment using MAAS provider on 1.17.2
<sparkiegeek> http://paste.ubuntu.com/6965180/
<sparkiegeek> if I manually run that wget command on the maas provider (same network/firewall etc. as bootstrap node) I get a certificate error
<sparkiegeek> http://paste.ubuntu.com/6965187/
<rogpeppe> this machine has become unusable
<rogpeppe> am rebooting to see if it helps
<natefinch> rogpeppe: time to upgrade
<rogpeppe> natefinch: to what?
<natefinch> rogpeppe: new laptop
<rogpeppe> natefinch: ha ha. it was fine before
<rogpeppe> natefinch: i'm not doing anything different
<natefinch> rogpeppe:  just take the excuse ;)
<rogpeppe> natefinch: i'm waiting until september...
<natefinch> rogpeppe: what's in sept?
<rogpeppe> three years at canonical = new laptop
<natefinch> rogpeppe: ahh nice
<wrtp> natefinch: so, it looks like my laptop has died
<rogpeppe> natefinch: when i tried to reboot it, i got a kernel panic (something about a thermal_notify call)
<rogpeppe> natefinch: and now it just says "Fan Error" when i try to switch it on
<rogpeppe> this is unfortunate
<rogpeppe> i'm going to let it cool down for a bit and cross my fingers
<natefinch> rogpeppe: ouch
<rogpeppe> it is very hot underneath
<natefinch> rogpeppe: that sounds really bad
<natefinch> rogpeppe: maybe it is time for a new laptop?  I think you get a payout at 3 years regardless of whether you actually purchase a laptop...
<rogpeppe> natefinch: i've only had this for two years. i can't believe that's the expected lifetime of a laptop
<rogpeppe> natefinch: i don't know whether to blame trusty for thrashing it, or the laptop for not coping
<rogpeppe> anyway, hopefully in a few minutes it will have cooled down and everything will be back to normal
<natefinch> rogpeppe: 2 years shouldn't kill any reasonable laptop
<rogpeppe> natefinch: indeed - and it was a decent one
<rogpeppe> anyway, i guess i can continue with dimitern's review, from this apple laptop that's been rock solid for 4.5 years :-)
<hazmat> rogpeppe, what kind of laptop?
<rogpeppe> hazmat: lenovo x21
<rogpeppe> hazmat: sorry, x220
<rogpeppe> dammit, it's cooled down a reasonable amount, and i still get "Fan Error"
<hazmat> rogpeppe, odd.. i've got the same model.. its held up pretty well for me.. i had one logic board replace (under warranty), i've tricked it out with an extra msata and 16gb of ram. .. what's the issue?
<hazmat> rogpeppe, hmm.. i had some thermal issues when i had the logic board replaced.. are you still under warranty?
<rogpeppe> hazmat: no, not for some time noe
<rogpeppe> now
<rogpeppe> hazmat: (it's 2.5 years old)
<hazmat> rogpeppe, bummer.. not sure you have many options.. the docking station helped me not sure why.. it only do the random shutdown on thermal when unplugged i'd recommend picking up a 2|3 year warranty your next go around.. laptop's get abused
<rogpeppe> hazmat: everything was running very jerkily, and the fan was coming on. i decided to reboot. i saw a kernel panic when i did so. did a hard power off. now i can't even get into the bios menu.
<rogpeppe> hazmat: seems like it might be bricked :-\
<hazmat> rogpeppe, hmmm.. you can still get service from lenovo its just pay as you go on labor parts.. might be cheaper to investigate a new laptop and yank the hd for an external enclosure to save data
<hazmat> rogpeppe, the xps 15 / m3800 looks pretty nice albeit a bit pricey.
<rogpeppe> hazmat: i really wanted to wait until my 3 years :-)
<hazmat> yeah.. understood and the x220 is the last lenovo with a real (non-chicklet) keyboard
<rogpeppe> hazmat: i do have a docking station. maybe i'll try that.
 * rogpeppe googles for chicklet keyboards
<hazmat> rogpeppe, if works at all with the docking station, its almost 100% a logic/motherboard replace..
<hazmat> rogpeppe, its what standard keyboards on new laptops look like..
<natefinch> hazmat, rogpeppe: the XPS 15 is pretty slick, btw
<hazmat> rogpeppe, you can order just about any part from lenovo if your up for diy, although on  motherboard replace i'd go for a service  tech.
<rogpeppe> hazmat: docking station (finally found it!) doesn't seem to make a difference, sadly
<rogpeppe> i suppose it might actually be that the fan has gone
<dimitern> natefinch, mgz, anyone? simple review https://codereview.appspot.com/66550044 to fix bug 1282553
<_mup_> Bug #1282553: maas provider can't bootstrap on precise with 1.17.2 <landscape> <juju-core:In Progress by dimitern> <https://launchpad.net/bugs/1282553>
<bac> hi jamespage, i was asked to check in with you regarding getting juju-quickstart into main rather than universe.  what's the status?
<rogpeppe> dimitern: i was reviewing that when my machine died
<rogpeppe> dimitern: i'm not sure about the agent config approach
<rogpeppe> dimitern: but i need to think about it some more
<rogpeppe> ha, actually my laptop *is* still under warranty
<mgz> dimitern: reviewed
<mgz> dimitern: I'm pretty sure curl has always been in the base cloud image, did you find you needed to install it?
<dimitern> rogpeppe, it's the least intrusive approach imo
<dimitern> thanks for the review mgz
<dimitern> sinzui, do you know about the cross-team meting? when does it start?
<dimitern> mgz, looking in #juju on canonical it seemed safer to add it
<sinzui> dimitern, in 15 mintutes
<dimitern> sinzui, ok, so because fwereade is not feeling well, i'd like to go in his place as he asked, can I have a g+ link in privmsg?
<mattyw> rogpeppe, got time for another quick question?
<sinzui> dimitern, https://plus.google.com/hangouts/_/calendar/bWFyay5yYW1tLWNocmlzdGVuc2VuQGNhbm9uaWNhbC5jb20.bbjh6akgumv8n4suee7li8mrfc?authuser=1
<dimitern> sinzui, thanks
<sparkiegeek> dimitern: if you were basing the need to install curl on my aptitude why trick then I think that's a mistake. http://cloud-images.ubuntu.com/precise/current/precise-server-cloudimg-amd64.manifest shows it's in the base image. I'm +1 on mgz's comment that you don't need to install it
<dimitern> sparkiegeek, ok, i can remove addpackage then
<mramm> hey, any juju core members available to join the cross team meeting?
<mramm> https://plus.google.com/hangouts/_/calendar/bWFyay5yYW1tLWNocmlzdGVuc2VuQGNhbm9uaWNhbC5jb20.bbjh6akgumv8n4suee7li8mrfc
<dimitern> mramm, i'm there :P
<mramm> ok
<mramm> cool
<rogpeppe> mattyw: sure
<rogpeppe> mattyw: sorry, didn't see your question - i'm on a different machine 'cos my laptop has died :-(
<mattyw> rogpeppe, no problem - I've just submitted my second part of the juju id stuff for review - there's definately more stuff to do - but I wanted to get it started - rather than finish everything and then have to redo parts...
<mattyw> one of the things I haven't done yet is the cacheAPIInfo stuff - taking out the user stuff and doing it only on bootstrap
<rogpeppe> mattyw: ok
<mattyw> rogpeppe, there's an example in the current code of how I think the function should look - but I don't think I can call it directly from the bootstrap command without jumping through some hoops (I don't have an apiInfo in the bootstrap command)
<mattyw> rogpeppe, also it breaks a few tests by not doing it - so I guess the cacheuser function will need to be called somewhere where the tests can invoke it as well
<rogpeppe> mattyw: i'm just downloading the code so i can have a look
<mattyw> rogpeppe, ok thanks - there's no particular hurry - but thanks :)
<dimitern> rogpeppe, another review poke? :)
<rogpeppe> dimitern: sorry, i've been busy trying to get my machine repair scheduled
<mattyw> rogpeppe, you're the 3rd person I know who's had to send a laptop for repair this week
<rogpeppe> mattyw: i wonder if it's anything to do with trusty thrashing things
<rogpeppe> mattyw: i know that the fan never *needed* to come on before today
<mattyw> fans always need to come on - it's their purpose in life
<rogpeppe> 6 working days until i get it back, darn it
 * rogpeppe wonders what he should do now. i guess i could get an enclosure for the SSD and try to access the disk drive from my macbook, and develop on that
<dimitern> rogpeppe, try sticking it in the fridge :)
<mgz> dimitern: got a mo to help me out?
<dimitern> mgz, sure
<mgz> I want to test a new (old) api command I've added in state/apiserver/client/status.go
<mgz> this isn't used in real code, but I want to exercise the function in a unit test
<mgz> where should I add that?
<mgz> the existing testing in that package is confusing me
<dimitern> is it one of these things where a CodeNotImplemented is involved?
<mgz> well, that too
<mgz> but this particular test isn't for that behaviour, though I should *also* have a test for that
<mgz> I just want to call the apiserver function from a sensible test to make sure it does things, on the off chance the old 1.16 code was being relied on
<dimitern> if you want to test the branch where a 1.16 fallback code should be run, what I usually do is go in api/client and change the name of the called method (in st.Call(...)) to something else, like adding "1" at the end, so the server will return not implemented
<dimitern> it's otherwise hard (if not impossible currently) to write a unit test for that
<mgz> moo, so, second test probably not possible
<dimitern> am I making sense?
<mgz> I'm sure the first is though
<mgz> it's just like I've added a new api call that's not used anywhere and want to write a test for the server side
<mgz> dimitern: I'll put up an mp so far, may be clearer
<dimitern> mgz, looking at the code will help me understand better
<rogpeppe> mgz: you can use Call directly if you need to
<dimitern> rogpeppe, that's a bit over the edge I think
<mgz> dimitern: https://codereview.appspot.com/66590043/
<dimitern> mgz, looking
<dimitern> mgz, reviewed
<mgz> merci
<mgz> dimitern: responded to comments will have another look at finding a sane test to emulate
<dimitern> mgz, cheers
<natefinch> dimitern, mgz: review please?  It's pretty small: https://codereview.appspot.com/66230043/
<dimitern> natefinch, looking
<wrtp> dimitern: i actually think that's ok - it's a public API. we're allowed to use it if others are.
 * rogpeppe has just sent his laptop off for repair
<natefinch> rogpeppe: boo.  That sucks.  good luck getting it back quickly
<dimitern> natefinch, reviewed
<dimitern> rogpeppe, what's that?
<rogpeppe> natefinch: yeah, it's a bummer. i've just got a 2.5" enclosure to see if i can talk to the hard drive from my macbook
<rogpeppe> natefinch: it may require me running an ubuntu VM, i guess
<rogpeppe> can't remember what fs type i was using
<hazmat> rogpeppe, ext4 if you have deafults
<rogpeppe> hazmat: probably
 * rogpeppe goes to look for an ext4 fs for macos
<hazmat> rogpeppe, i wouldn't  bother..  you'll need a linux machine.. a vm might do depending on enclosure type (usb3) and if you can pass it through to the vm.
<hazmat> rogpeppe, actually it does look like there are some commercial products for ext4 access from osx
<rogpeppe> hazmat: that's actually what i'm doing right now - just upgrading my VMWare installation
<rogpeppe> hazmat: perhaps i can boot the vmware directly off my laptop hard drive
<hazmat> rogpeppe, if you encrypted your home drive.... things get trickier..
<rogpeppe> hazmat: it's a usb2 enclosure, unencrypted
<rogpeppe> i'm not paranoid  :-)
<hazmat> i'm not either, but i encrypt ;-)
<mgz> dimitern: pushed up an attempt at some tests, are they sane enough?
<rogpeppe> hazmat: ok, let's just say i'm hopelessly naive :-)
<dimitern> mgz, will look in a moment
<rogpeppe> dimitern: i'm afraid i'm not going to finish your review today
<rogpeppe> dimitern: i've got to stop a little early today, unfortunately
<rogpeppe> dimitern: i was referring to your "member:rogpeppe, that's a bit over the edge I think" comment about my "just use Call directly" remark
<dimitern> rogpeppe, no worries
<dimitern> rogpeppe, i'll have to stop soon as well
 * dimitern needs to pack for a 5 am flight this morning
<rogpeppe> "You have MacÂ OSÂ X 10.6.8. The application requires MacÂ OSÂ X 10.7 or later."
<rogpeppe> bugger
<dimitern> mgz, I'm looking at your CL, could you look at mine? https://codereview.appspot.com/66340045
<mgz> dimitern: sure thing :)
<dimitern> cheers :)
<mgz> dimitern: just looking at Andrew's change that introduced it to see if we're going to be borking anything in reverse, change itself looks fine
<mgz> ah, eg:
<dimitern> mgz, I also looked and couldn't find a sane reason for the change - ssh does not support -- neither does --
<mgz> === modified file 'cmd/juju/debughooks.go'
<dimitern> s/does --/does scp/
<mgz> -       args := []string{"--", fmt.Sprintf("sudo /bin/bash -c '%s'", innercmd)}
<mgz> +       args := []string{fmt.Sprintf("sudo /bin/bash -c '%s'", innercmd)}
<mgz> does that then want reverting?
<mgz> (looking at `bzr diff -c2116`)
<dimitern> mgz, I'll try running debug-hooks with the test
<mgz> thinking about that bit, it's *probably* fine if we got our shell quoting correct
<mgz> one string, should be quoted and interpreted as a command regardless
<mgz> === modified file 'cmd/juju/ssh_test.go'
<mgz> -               sshArgs + "dummyenv-0.dns\n",
<mgz> +               sshArgs + "ubuntu@dummyenv-0.dns\n",
<mgz> er.. not that hunk
<mgz> but some later bits, changed to add --
<arosales1> mgz: fwereade_ you guys available for a sync on the joyent provider
<mgz> === modified file 'environs/sshstorage/storage.go'
<mgz> again, that change should be fine if we get our quoting right
<dimitern> arosales1, fwereade_ is not i'm afraid - a bit ill and resting
<mgz> arosales1: alas, I need to go get a bus in a sec
<arosales1> fwereade_: ?
<mgz> arosales1: you may need to rope in dimitern, it's his day of getting roped in :)
<arosales1> ah dimitern :-)
<mgz> have been doing a fair bit with daniele this week, he should be able to report most of it
<dimitern> arosales1, :) hmm
<dimitern> arosales1, I have no knowledge on joyent or its progress though
<mgz> dimitern: utils/ssh/ssh.go has an interesting bit
<mgz> -       args = append(args, host, "--", command)
<mgz> +       args = append(args, host)
<mgz> +       if len(command) > 0 {
<mgz> +               args = append(args, "--")
<mgz> +               args = append(args, command...)
<mgz> +       }
<hazmat> anyone know which version of juju started using jenv files?
 * hazmat thinks it was 1.16
<natefinch> hazmat: that sounds right, but I don't know for sure
<hazmat> is there any way in the api to tell which machines are 'dirty'?
<hazmat> afaicr.. no
<hazmat> filed a bug
<natefinch> hazmat: in the API?  Possibly not
<natefinch> hazmat: I know we have that information, but not sure if it's exposed.  It should be.
<hazmat> natefinch, doesn't appear to be any api for machines outside of create/destroy and sidecar via status
<hazmat> well and inject/provisioning  scriptfor manual
<natefinch> hazmat: I'd love a juju status <machine> that gives more details about the machine
<hazmat> natefinch, yeah.. i think that's the intended direction for extended info
<hazmat> chris38, btw that go get -u -v launchpad.net/juju-core/.... needs a go install launchpad.net/juju-core/... as well to get the latest binaries.
<sinzui> natefinch, do you think you will merge this by your morning tomorrow? https://code.launchpad.net/~natefinch/juju-core/034-juju-mongo/+merge/207320
#juju-dev 2014-02-21
<waigani> axw: quick question?
<waigani> why do you do this: var _ state.Policy = environStatePolicy{}
<axw> waigani: it's a convention in juju to ensure that the implementation continues to implement the interface
<axw> also, documentation as code
<waigani> ah right. I saw that before. The type assertion will fail if the struct's methods change.
<axw> the code won't actually compile, because the assertion can be proven at compile time
<axw> it's a static assertion
<waigani> axw: here is my first pass. https://codereview.appspot.com/63790045
<waigani> axw: No tests yet and I have not implemented ValidateEnvironConfig in any provider yet. I took a look at adding it to the manual provider, but I wanted to talk over how to rewire SetConfig with you first.
 * axw looks
<axw> waigani: you shouldn't need to implement it anywhere, just use the one on EnvironProvider
<axw> you can get the provider from the config
<davecheney> axw: http://paste.ubuntu.com/6969152/
<davecheney> ^ this error looks pretty terminal
<davecheney> any suggestions ?
<axw> wtf mate
<axw> umm
<axw> no
<axw> are you packages up to date?
<axw> wallyworld was having some problems with lxc on trusty
<davecheney> axw: can you tell me the commands that get exectued under the hood
<wallyworld> axw: the latest update an d areboot fixed it
<davecheney> i could try to do them manually to smoke test it
 * davecheney shrugs
<davecheney> i'll give it a go
<davecheney> oooh, i see lxc-templates
<davecheney> fingers crossed
<wallyworld> yeah you need lxc-templates installed as well as lxc
<wallyworld> lxc rc4 works for me now
<wallyworld> rc3 seemed to barf
<davecheney> yeah, i have the templates
<davecheney> just i guess not hte latest ones
<axw> davecheney: I'm not sure what the command is, but you want to create a container with the ubuntu-cloud template
<davecheney> mmm kay
<davecheney> which series does that assume ?
<davecheney> lots of shit just expects precise
<axw> you tell it which series
<axw> looks like you pass "-r trusty" to lxc-create
<davecheney> whoop whoop!
<davecheney> axw: wallyworld nope, no joy
<davecheney> still horribly broken
<wallyworld> hmmm
<wallyworld> it was broken for me until i updated everything yesterday
<davecheney> ubuntu@winton-02:~$ sudo lxc-create -t ubuntu-cloud -n dave
<davecheney> /usr/share/lxc/templates/lxc-ubuntu-cloud: line 276: type: ubuntu-cloudimg-query: not found
<davecheney> lxc_container: container creation template for dave failed
<wallyworld> and got lxc rc4 and rebooted
<davecheney> lxc_container: Error creating container dave
<davecheney> ^ this ?
<davecheney> ii  lxc                                    1.0.0~rc4-0ubuntu1            ppc64el      Linux Containers userspace tools
<wallyworld> i was getting a cgroups error
<axw> davecheney: do you have a "ubuntu-cloudimg-query" command on your system?
<davecheney> ii  lxc-templates                          1.0.0~rc4-0ubuntu1            ppc64el      Linux Containers userspace tools (templates)
<davecheney> axw: i guess not
<davecheney> does juju enforce this ?
<davecheney> ie, is there an install dep ?
<axw> hmm
<axw> not sure
<davecheney> ubuntu@winton-02:~$ sudo apt-get install ubuntu-cloudimg-query
<davecheney> Reading package lists... Done
<davecheney> Building dependency tree
<davecheney> Reading state information... Done
<davecheney> E: Unable to locate package ubuntu-cloudimg-query
<axw> not a package
<axw> just run the command
<axw> should tell you what you need...
<davecheney> not found
<davecheney> and no sugestion
<davecheney> do you have it ?
<axw> yeah, how do I figure out what provides it again..
<davecheney> dpkg -S $(which ubuntu-cloudimage-query)
<wallyworld> davecheney: i just thought - i'm running a trusty host but am deploying precise charms and that worked for me as of late yesterday
<davecheney> wallyworld: same
<davecheney> this is a trusty host
<wallyworld> ok, i was thinking you may have been trying trusy charms
<axw> davecheney: cloud-image-utils
<davecheney> well, i have to do that
<wallyworld> yeah my host is trusty also
<davecheney> but that is problem 2^17
<davecheney> axw: ta
<axw> and no, no check in the local provider
<davecheney> axw: cock http://paste.ubuntu.com/6969306/
<axw> bugger
<davecheney> ok, the tasty-taco's are on it
<axw> wallyworld: I think there may still be a problem with local upgrades, but not sure. Looks like a container in my local env is looking for downloaded-tools.txt in the host machine path
<wallyworld> data dir is used for the place to look
<axw> unit-axwtest-0: 2014-02-21 07:46:44 ERROR juju runner.go:220 worker: exited "upgrader": cannot read tools metadata in tools directory: open /home/andrew/.juju/local/tools/1.17.3.1-trusty-amd64/downloaded-tools.txt: no such file or directory
<axw> unit-axwtest-0: 2014-02-21 07:46:44 INFO juju runner.go:254 worker: restarting "upgrader" in 3s
<wallyworld> it comes from agent config file
<wallyworld> that location looks ok
<axw> no
<axw> that's on machine 0
<axw> the unit is in a container
<axw> I mean, that path would be ok if it were on machine 0
<wallyworld> what does the container agent conf file have
<wallyworld> for data dir
<axw> in upstart it has --data-dir /var/lib/juju as expected
<wallyworld> hmmm.
<wallyworld> that value is what is passed to the unit upgrader to use
<wallyworld> ah
<wallyworld> i mean machine agent
<wallyworld> um
<wallyworld> ffs
<axw> this is a unit agent if it matters
<wallyworld> there's a UnitUpgraderAPI
<wallyworld> which is paased the data dir
<wallyworld> which comes from the agent conf
<wallyworld> so off hand i'm not sure what is going wrong
<hazmat> g'morning
<wallyworld> but i have to run away now to go to soccer
<axw> nps, later
<axw> hey hazmat
<wallyworld> fwereade_: i have to go to soccer now and will miss stand up but want to talk about my latest machine agent upgrade work later, ok?
<wallyworld> tests pass but i'm unhappy with 2 bits of the implementation
<hazmat> axw, welcome to the world of picky certs :-) thanks for diving into that.
 * hazmat has been having the same sort of cert fun with mysql ssl enablement
<axw> no worries
<axw> it's kind of interesting, but I wish rsyslog had better logging and less horrible configuration format :(
<axw> it's all working now, just need to think about upgrades a bit
<hazmat> axw, there's a major version change of rsyslog from precise to trusty 5.8 to 7.6
<hazmat> might be worth verifying on both
<axw> I've been testing with a trusty container and saucy host, local provider
<axw> saucy is still 5.x
<axw> but thanks for hte heads up
<hazmat> axw, the notion of a worker seems like a sane path forward re syslog manage & upgrade. it also seems like it would be good on the road towards ha if there currently immutable.
<axw> yeah, I think I will finish up the basics and then do that. there's no decent way of upgrading this stuff at the moment
<wrtp> TheMue: ping
<TheMue> wrtp: one moment, people at the door
<TheMue> wrtp: so, back, we've got some troubles with our wastewater
<wrtp> TheMue: my laptop has just broken, so i need to revert back to using my old mac, and i know you use some kind of VM - i wondered what you use, and if you recommend it
<TheMue> wrtp: I'm using VMware Fusion and it works fine, only needs some RAM. At least 8 Gigs. Advantage is that you can do snapshot, e.g. before upgrading to new releases like trusty.
<TheMue> wrtp: But it costs. I got it cheaper when it has been released the first time.
<TheMue> wrtp: There are also Parallels and VirtualBox.
<dimitern> axw, hey are you around still?
<wrtp> TheMue: ok. i did have an old vmware version, but it suggested i upgrade it, but the upgraded version wasn't compatible with the old licence keys
<wrtp> TheMue: so i've just bought a new version
<wrtp> TheMue: and now i'm wondering how to get ubuntu running on it. ideally i'd like to be able to bootstrap from my laptop's hard drive, but i'm not sure that's possible
<axw> dimitern: yup?
<dimitern> axw, I saw your comments on my ssh fix
<axw> oh yeah
<dimitern> axw, if you have 10m I wanted to ask you to bring me up to speed with all the stuff around ssh
<axw> sure
<dimitern> axw, so we're using 2 different clients? why's that?
<axw> for Windows
<dimitern> ah
<axw> so, because bootstrap now requires ssh, we *need* an ssh client
<dimitern> right
<axw> whereas before we could just say meh you can't have juju ssh
<dimitern> how do you suggest i should test the fix to make sure i didn't introduce a regression?
<axw> so now if we don't find "ssh" in $PATH, then we fall back to an embedded go.crypt/ssh client
 * axw looks at the change again
<dimitern> i suppose: ssh + scp commands, manual bootstrap + manual add-machine ssh, possibly debug-hooks.. windows?
<axw> if ssh/scp aren't in your path, it'll behave like it would on Windows
<dimitern> i found out scp -- <args> does not work btw
<dimitern> ah, good point, I can fake it on ubuntu then
<TheMue> wrtp: afaik it's not possible, you have to create a new image. but then you should be able to mount the old drive
<axw> ah, so if we pass through -- then the embedded client will break
<dimitern> wrtp, why the change of nick? going clandestine? ;)
<dimitern> right!
<dimitern> so basically I should test both client paths everywhere :)
<axw> yeah, it's a pain in the bum but that's probably safest
<dimitern> ok, thanks a bunch, will do
<axw> so you'd probably want to compare what happens when you do "juju ssh 0 -- command" and "juju ssh 0 command"
<dimitern> when is the -- jobbie supposed to work?
<dimitern> with the embedded or the openssh client?
<axw> openssh
<dimitern> ok, i think that's all i need then
<axw> that's just to say that the args won't go to ssh, but to the command it execs
<dimitern> right
<TheMue> wrtp: sorry for the breaks between my answers, have also to answer the craftsmen some questions around our problems
<TheMue> s/wrtp/rogpeppe
<rogpeppe> dimitern: wrtp used to be my nick, and i'm on my mac laptop which has my old configuration set up
<dimitern> rogpeppe, i see
<rogpeppe> hmm, i've managed to mount my laptop drive in my NAS box, but i only see a grub partition
<rogpeppe> i wonder how i can get access to the main stuff
 * TheMue is reminded to do a backup of his VMs after rogs troubles
<TheMue> rogpeppe: the usage of VMs allows me to also have pure testing VMs, with no influence of the development VM
<dimitern> rogpeppe, standup?
<rogpeppe> dimitern: could you paste a link please?
<dimitern> https://plus.google.com/hangouts/_/calendar/am9obi5tZWluZWxAY2Fub25pY2FsLmNvbQ.mf0d8r5pfb44m16v9b2n5i29ig
<rogpeppe> "you are not allowed to join this video call"
<rogpeppe> one mo while i get my auth key
<rogpeppe> dimitern:  ^
<dimitern> you need to login to the canonical account
<rogpeppe> yeah
<wallyworld> fwereade_: hi, do you have a minute to talk about my upgrade branch? I think i really want roger but he isn't logged on
<fwereade_> wallyworld, I'm making an effort to program in the dark today but I'm actually already distracted, so let's
<wallyworld> sorry :-(
<wallyworld> https://plus.google.com/hangouts/_/calendar/am9obi5tZWluZWxAY2Fub25pY2FsLmNvbQ.mf0d8r5pfb44m16v9b2n5i29ig?authuser=1
<wrtp> mgz: ping
<wrtp> at long frickin' last!
<wrtp> i have finally managed to get my laptop drive mounted in a VM
<natefinch> wrtp: nice!
<wrtp> this was the final key: http://www.tuxradar.com/answers/296
<wrtp> but, honestly!
<dimitern> natefinch, how can I build a windows installer from trunk?
<natefinch> dimitern: you need innosetup (either in a windows VM or possibly Wine, I haven't tried Wine).  Build cmd/juju using cross compilation to make a windows binary, copy juju.exe to scripts/win-installer, then load scripts/win-installer/setup.iss into innosetup and build it
<natefinch> dimitern: I should put that into a doc somewhjere
<dimitern> natefinch, right, how to do the cross compilation?
<natefinch> dimitern: http://dave.cheney.net/2013/07/09/an-introduction-to-cross-compilation-with-go-1-1
<natefinch> dimitern: unfortunately, step 1 is: "install go from source"
<dimitern> natefinch, ok, tyvm
<natefinch> dimitern: welcom
<mgz> wrtp: yeay!
<mgz> can you work okay from the mac then?
<wrtp> mgz: we'll see. it looks ok so far.
<wrtp> mgz: much slower, but that's probably mostly the disk drive being spinning rust
<mgz> do you have a date idea on when the repair will be done? I'm thinking about london...
<wrtp> mgz: they said 6 working days
<wrtp> mgz: so i'm crossing my fingers
<wrtp> anyone remember how to get the required mongod when running under precise?
<wrtp> mgz: ^
<mgz> add the cloud-tools pocket and install from there
<mgz> you can probably use the new juju-mongodb even
<wrtp> mgz: how do you add the cloud-tools pocket?
<wrtp> mgz: apt-add-repository cloud-tools-pocket ? :-)
<mgz> `sudo add-apt-repository cloud-archive:tools`
<mgz> the apt-get update and install juju-mongodb
<wrtp> mgz: thanks
<wrtp> mgz: (i have the binaries, but of course i'm running precise and the binaries are trusty 'cos they're on my laptop drive)
<wrtp> mgz: i tried fiddling with LD_LIBRARY_PATH but no joy. i love shared libraries
<wrtp> mgz: hmm; http://paste.ubuntu.com/6971425/
<wrtp> and /etc/apt/sources.list doesn't even have 60 lines :-\
<mgz> well, that's amusing.
<mgz> look in /etc/apt/sources.liust
<mgz> *look in /etc/apt/sources.list.d/
<wrtp> cloudarchive-tools.list is there
<mgz> can you pastebin that?
<wrtp> mgz: does that mean it's actually worked, despite the error message?
<wrtp> deb http://ubuntu-cloud.archive.canonical.com/ubuntu precise-updates/cloud-tools main
<wrtp> deb-src http://ubuntu-cloud.archive.canonical.com/ubuntu precise-updates/cloud-tools main
<mgz> it does if apt-get update works, if it doesn't then presumable it borked
<mgz> that seems fine
<wrtp> well, apt-get update works, so i guess it worked :-)
<wrtp> mgz: except it doesn't seem to know about juju-mongodb
<mgz> bug 789859 it seems
<_mup_> Bug #789859: add-apt-repository adds invalid deb line if PPA contains a - <amd64> <apport-bug> <natty> <software-properties (Ubuntu):Fix Released> <software-properties (Ubuntu Precise):Triaged> <software-properties (Debian):Invalid> <https://launchpad.net/bugs/789859>
<sinzui> mgz, do you have a few minutes to review https://codereview.appspot.com/66780046
<mgz> sinzui: sure thing, but natefinch might be a better bet if he's around
<mgz> ..actually, that's trivial
<mgz> sinzui: lgtm
<mgz> I presume the version bump in the go code already happened?
<sinzui> wrtp, when this bug is fixed, we will release a new juju that is juju-mongodb aware: https://bugs.launchpad.net/juju-core/+bug/1271937
<_mup_> Bug #1271937: Use juju-mongodb when the package is available <arm64> <ci> <mongodb> <ppc64el> <trusty> <juju-core:In Progress by natefinch> <https://launchpad.net/bugs/1271937>
<mgz> wrtp: does `grep -r "^in" /etc/apt/sources.list*` give anything?
<wrtp> mgz: nope
<mgz> well, lets assume it was transient weirdness then
<wrtp> mgz: and the only entry in sources.list.d is the cloudarchives-tools.list file
<wrtp> mgz: except that... i can't apt-get juju-mongodb
<wrtp> mgz: apt-cache search juju doesn't print anything that looks reminiscent
<mgz> yeah, it seems it only has the normal mongdb packages at present
<mgz> so, just install mongodb (or just -server)
<wrtp> mgz: so if i apt-get install mongodb, will i get the cloud-tools mongodb
<wrtp> ?
<mgz> yup
<wrtp> mgz: ok, i'll try that
<mgz> it will also upgrade if you have the precise one
<wrtp> mgz: yeah, it looks like it's fetching from the right place, ta
<mgz> should be 1:2.4.6-0ubuntu5~ctools1
<wrtp> mgz: i see that
<wrtp> mgz: at last! i have juju tests passing under my VM
<wrtp> mgz: thanks for the help
<mgz> ace!
<Beret> sinzui, when do you expect .3?
<Beret> I can't remember
<sinzui> hmm, between 2 and 20 hours.
<sinzui> Beret, everything in in the Lp builders as of 5 minutes ago
<Beret> sinzui, awesome, thanks :)
 * wrtp uses chroot(1) for real for the first time ever
<mgz> rogpeppe: I've used it a fair bit from inside chromeos recently when I needed to restore my ubuntu partition :)
<rogpeppe> mgz: aw dammit, "no ptys"
<rogpeppe> mgz: i can't run a terminal emulator in it
<mgz> really? what's the underlying terminal?
<natefinch> sinzui: btw I am trying to land my "use juju-mongod" branch, but hit some spurious test failures.  Going to try again in a little bit, have to run to the store real quick.
<sinzui> thank you natefinch
<dimitern> sinzui, sorry, it seems I won't be able to land the fix for bug 1281577 in time for 1.17.3, as I said in the xteam doc
<_mup_> Bug #1281577: juju 1.17.2 doesn't pass command line options to ssh <docs> <landscape> <regression> <ui> <juju-core:In Progress by dimitern> <https://launchpad.net/bugs/1281577>
<mgz> sinzui: have you picked a trunk rev already, or will you go with what we have in a few hours?
<sinzui> dimitern, mgz, 1.17.3 tarball is released.
<sinzui> dimitern, I will release 1.17.4 when I see natefinch's branch land and CI confirms it works with the new packaging rules
<sinzui> dimitern, So I may release 1.17.4 tomorrow, certainly next week
<dimitern> sinzui, ok, great
<rogpeppe> oh bugger, my disk enclosure seems to have stopped working
<rogpeppe> i hope it hasn't killed the disk
<mgz> >_<
<rogpeppe> mgz: ah, it seems that the VMWare USB stuff is extremely sensitive to unplugging. when i unconfigured the usb, shut everything down, and started it all up in just the right order, it's working again
<rogpeppe> phew
<rogpeppe> but time to start a backup going, i think
<sinzui> natefinch, thank you. I will push the new packaging rules
<natefinch> rogpeppe: sounds like one of those things where, once you get it working you don't. touch. anything.
<rogpeppe> natefinch: yeah. the connectors seem dodgy... both s/w and h/w
<rogpeppe> right, i'm done
<rogpeppe> happy weekends all
<rogpeppe> question to ponder: anyone know why StatePort is no longer stored in the agent config?
<mgz> hm... nope
<mgz> is it just a constant now?
<natefinch> rogpeppe: I think stateport was something I added with the new machine agent  stuff and that it wasn't there before.... and since that code isn't merged yet, it's not in trunk
<natefinch> mgz: have time for a quick review?  https://codereview.appspot.com/67080043/
<mgz> natefinch: will do in a bit
<rick_h__> anyone able to give me hints on getting the error "ERROR empty image-stream in environment configuration" during a deploy command?
<rick_h__> this is on ec2 during a test of our charm and everything I see around image-stream seems based on azure
<rick_h__> my env config has no image-stream config in it for ec2 env
<rick_h__> http://paste.ubuntu.com/6972735/ is the command run and error returned
<rick_h__> trying it by hand I get "ERROR juju.cmd supercommand.go:294 empty image-stream in environment configuration"
<dpb1`> rick_h__: check .juju/environments/ec2.jenv
<rick_h__> dpb1`: ah, good call. Regenerating that and trying again
<dpb1`> dpb1`: k
<dpb1`> blah
<dpb1`> rick_h__: ok. :)
<rick_h__> dpb1`: ok, so I get that error on the juju deploy command. There's no image-stream set in the  environments.yaml or ec2.jenv
<rick_h__> if I try to set the image-stream to : or : "" I get errors on bootstrap about it being a bad value
<dpb1`> rick_h__: is it possible for you to paste your environments.yaml (sanitized)?
<dpb1`> just that section
<natefinch> rick_h__: setting it to "released" should work, though not set should be equivalent to "released"
<rick_h__> dpb1`: sure thing, sec
<rick_h__> natefinch: yea, that failed for me as well. I saw that in the azure stuff
<rick_h__> I'm on 1.17.2-trusty-amd64
<rick_h__> http://paste.ubuntu.com/6972856/ dpb1`
<rogpeppe> natefinch: stateport is in 1.12 serialization but not 1.16
<natefinch> rogpeppe: ok, I just know I added stateport to something in my changes, couldn't remember what.
<natefinch> rick_h__: add in a --show-log to the deploy command and it'll spit back a bigger log that may be helpful
<rick_h__> natefinch: http://paste.ubuntu.com/6973005/
<natefinch> rick_h__: well that's less than useful, huh? :/
<rick_h__> :)
<rick_h__> sinzui: is .3 in trusty or on the way? to test for #1277636
<_mup_> Bug #1277636: juju 1.17.x cannot destroy a 1.16.5 azure environment <azure-provider> <ci> <destroy-environment> <regression> <juju-core:Fix Released by axwalk> <https://launchpad.net/bugs/1277636>
<rick_h__> all of us hitting the bug are trusty users on .2 currently
<sinzui> rick_h__, It in the the public ppa. Ubuntu are responsible for putting it in trusty
<sinzui> rick_h__, I am sorry for trusty users being forced test unstable software. My plan was to never let it devel releases go into an LTS. You can find the new release in https://launchpad.net/~juju/+archive/devel/+packages for now
<rick_h__> sinzui: rgr, thanks
<sinzui> rick_h__, you may already know about this http://manage.jujucharms.com/heartbeat
<sinzui> jujucharms.com is not happy, looks like manage...is at fault
<rick_h__> sinzui: working with webops on it and running out of time to get a fix :/
<rick_h__> ES voted out all the shards again but the fix from last time is not working
<sinzui> rick_h__, The fix was to put the other values back...the 3 mintues later all was good
<sinzui> Is that the fix tried?
<rick_h__> sinzui: "values back"?
<rick_h__> sinzui: last time we removed /var/lib/elasticsearch and restarted it and then restarted charmworld and reran es-update and it rebuilt itself
<rick_h__> I'm trying to figure out how/what command to send to ES via the JSON api to get it to allocate a shard
<sinzui> rick_h__, the first time it happen, it was caused when the charm config value was changed. It didn't need to be, if you know what the old value was, setting the config back restored it
<rick_h__> sinzui: oh hmm, no config changed I'm aware of. Will see if we can get what's set and compare.
<rick_h__> sinzui: should be back now
<sinzui> thank you rick_h__
<rick_h__> sinzui: turns out they run mojo which runs CI and part of that brings up a new ES server. Which any other ES servers on the network try to join with and caused things to go badly.
<rick_h__> loves ES and it's auto scaling stuff
<sinzui> rick_h__, ha ha
<rick_h__> kind of funny that CI passes while production goes down
<sinzui> rick_h__, that was the reason we added the shard and names parts to charmworld, to ensure the names are always unique
<rick_h__> yep, the names in CI are getting updated now
<sinzui> Their CI, has to use different names or run on different networks per ES
<rick_h__> yep
<rick_h__> that's the great discovery of the day
#juju-dev 2014-02-22
<rick_h__> sinzui: verified that 1.17.3 fixes. Thanks for the heads up and devel update
<sinzui> np
#juju-dev 2014-02-23
<Tante> Santi Novianti Add FB me (sardewiayu@yahoo.com) / twitter (@santinovianti22) Butuh Teman cuhat :(
<Tante> Santi Novianti Add FB me (sardewiayu@yahoo.com) / twitter (@santinovianti22) Butuh Teman cuhat :(
<thumper> morning
<hazmat> thumper-afk, welcome back
<thumper> hazmat: hey, how's tricks?
<thumper> hazmat: any magic news from ODS?
<hazmat> thumper, ods.. isn't for a few bit.. scale is going on now..
<hazmat> and mwc
<hazmat> re scale .. jcastro and marcoceppi are out there.. https://www.socallinuxexpo.org/scale12x/presentations
 * thumper thinks
<thumper> wasn't there something last week?
<thumper> ah...
<thumper> I'm a sprint ahead of myself
<thumper> ODS is after the *next* sprint
<hazmat> thumper, yup
<hazmat> thumper, how was the vacation?
<thumper> hazmat: great, spent the whole time doing python and javascript :)
<thumper> was not really a do nothing holiday :)
<thumper> got a whole heap done
<hazmat> thumper,  right on.. still beats.. working crazy hrs on customer stuff...  what kind of js?
<thumper> webapp, backbone, jquery
<hazmat> cool
<thumper> committed a fix to bootstrap-datetimepicker
<thumper> found the bug and actually fixed it and submitted github pull request
<hazmat> the new sexy on js seems to be facebook react.js and .. angular has a lot of steam.
<thumper> made it into trunk in less than 24 hours
<hazmat> nice
<thumper> I'm less into sexy and more into functional that I can get my head around
<hazmat> but backbone.. is simple and functional
<thumper> if this idea pays off
<thumper> the company can hire someone to fix my shitty javascript
<hazmat> iterate.. early and often
<thumper> I figure that any sufficiently successful SaaS / webapp system will be rewritten at least two or three times
<thumper> I'm still trawling through my emails from the week not looking at them
<thumper> wallyworld: hi
<wallyworld> gday
<thumper> wallyworld: got a few minutes to chat?
<wallyworld> good break?
<wallyworld> sure
<thumper> gimmie a few minutes, then hangout
<wallyworld> ok
#juju-dev 2015-02-16
<axw> wallyworld_: reviewed, let me know what you think
<wallyworld_> sure ty
<wallyworld_> axw: i had to move providerregistry to avoid circular imports, from memory with LoopProviderType. i think adding a registry package is a good idea
<anastasiamac_> wallyworld_: thnx for env destroy and suggestions :D
<anastasiamac_> waigani: ^^ not wallyworld_
<waigani> anastasiamac_: welcome :)
<anastasiamac_> waigani: i'll put on my todo list
<anastasiamac_> waigani: but while tests pass with calling RemoveEnvironment
<anastasiamac_> waigani: probably not so high a priority to change :D
<waigani> anastasiamac_: absolutely. Nothing urgent. I just wanted to follow up from last week.
<anastasiamac_> waigani: it's awesome! thank u :D
<anastasiamac_> waigani: ur thoughtfulness is highly appreciated!
<waigani> :)
<wallyworld_> jam: hey, did you discuss with mark the storage CLI?
<wallyworld_> axw: ty for review, that branch now merged
<axw> wallyworld_: cool :)
<wallyworld_> axw: i'll now convert Pool to storage.Config etc
<jam> dimitern: poke?
<dimitern> jam, I've got kicked out
<dimitern> jam, and now I'm the only one in the hangout
<TheMue> morning
<dimitern> TheMue, o/
<TheMue> dimitern: o/
<dooferlad> dimitern, TheMue, voidspace: standup?
<TheMue> dooferlad: sure ;)
<dimitern> omw
<TheMue> phew, all those nested references to network parameters :/
<wallyworld> jam: hey there
<jam> wallyworld: hey
<wallyworld> jam: have you had a chance to talk to mark about the storage CLI changes we are proposing?
<jam> I have not, though I'd still advise you to make progress and I'll chat with him about it.
<wallyworld> ok, will do, thanks
<axw> wallyworld: which changes are those?
<wallyworld> axw: the ones where we use 3 levels
<wallyworld> juju storage pool create
<wallyworld> as oposed to
<wallyworld> juju storage create-pool
<axw> wallyworld: I thought nobody liked it?
<wallyworld> the spec says create-pool
<wallyworld> axw: i sent an email saying we were revisiting it (or at least i thought i did)
<axw> ok, I probably just forgot
<wallyworld> np, i thin storage pool create etc is better
<wallyworld> so want to try and get that approved
<wallyworld> axw: https://docs.google.com/a/canonical.com/document/d/1JMDDOPXHV6SPrTSA3SRb_qyyRUYcz7huo_tTIjD8UOc
<axw> wallyworld: ta
<axw> wallyworld: I think we'd still have "juju storage add", at the top level, allowing you to add storage instances to a unit or service
<axw> wallyworld: just saying since it's missing from the first "--help" output example .. not sure if that's meant to be complete
<anastasiamac_> wallyworld: axw: jam: thnx :D
<wallyworld> axw: yes, true. i was mainly focusing on what we had implemented so far
<wallyworld> axw: feel free to add to doc to make it more completed
<wallyworld> i just update dsharing
<wwitzel3> wallyworld: thanks for the review
<wallyworld> sure, np
<wallyworld> thanks for fix, will be good to get 1.21/1.22 out
<wallyworld> axw: oarsome, thanks for review
<axw> wallyworld: nps
<rogpeppe> where can i go to to find out whether juju-core updates are currently blocked?
<jw4> rogpeppe: http://goo.gl/4zd1e9
<rogpeppe> jw4: so, any critical bugs == blocked ?
<jw4> rogpeppe: yeah, that's basically the same query CI uses
<rogpeppe> jw4: ta
<jw4> rogpeppe: if you prefer json: https://api.launchpad.net/devel/juju-core?ws.op=searchTasks&status%3Alist=Triaged&status%3Alist=In+Progress&status%3Alist=Fix+Committed&importance%3Alist=Critical&tags%3Alist=regression&tags%3Alist=ci&tags_combinator=All
 * rogpeppe puts the PR on hold for a bit more
<rogpeppe> jw4: that json query doesn't give me any results
<jw4> rogpeppe: hmm; my JSON query shows zero though... yeag
<jw4> yeah
<rogpeppe> jw4: (JSON is indeed preferable for me in this case)
<jw4> rogpeppe: I personally use the JSON one :)
<rogpeppe> jw4: except it doesn't work :)
<jw4> rogpeppe: I wonder if the 'Incomplete' status is why it's not showing
<rogpeppe> jw4: this one also return empty: http 'https://api.launchpad.net/devel/juju-core?ws.op=searchTasks&status%3Alist=Fix+Committed&importance%3Alist=Critical&tags%3Alist=regression&tags%3Alist=ci&tags_combinator=All'
<anastasiamac_> jw4: this query is helpful in most cases... however, in this particular case, it's not right
<anastasiamac_> jw4: TRUNK IS NOT BLOCKED
<anastasiamac_> jw4: sorry for caps...
<rogpeppe> jw4: but removing the Fix+Committed qualification makes it work
<rogpeppe> anastasiamac_: that's useful to know!
<rogpeppe> anastasiamac_: thanks
<jw4> anastasiamac_, rogpeppe yeah - thanks!
<anastasiamac_> jw4: did not mean to cap :D
<jw4> anastasiamac_: lol
<rogpeppe> so it seems that it might be nice to have an indepdendent source of truth maintained so that we can actually see whether it's blocked or not
<anastasiamac_> jw4: but landing has been happening today :D
<anastasiamac_> rogpeppe: +1 this would be gr* and was the intention of jw4's query...
<rogpeppe> and so that the criteria can be changed without everyone needing to update their search query
<rogpeppe> perhaps someone can grab are-juju-core-commits-blocked.com :)
<anastasiamac_> rogpeppe: and make it branch specific too, so if u were curious about 1.21, u'd b able to "know" at a glance..
<rogpeppe> it would be even better if the 'bot automatically retried previously blocked commits after blocking is removed
<rogpeppe> anastasiamac_: yeah
<anastasiamac_> rogpeppe: not sure about automatically re-try but at least notifying the person that tried to merge :D
<anastasiamac_> rogpeppe: it's nice to dream... especially since it's midnight here :D m eod-ing
<rogpeppe> anastasiamac_: i think an automatic retry would be best, particularly if no further commits have been pushed or comments made since the block message
<rogpeppe> anastasiamac_: good night
<anastasiamac_> rogpeppe: nite
<rogpeppe> anastasiamac_: i had no idea you were that far east!
<anastasiamac_> rogpeppe: Surprise :D
<rogpeppe> anastasiamac_: eastern australia?
<TheMue> yummy, api/apiserver tests are passing again
<TheMue> dimitern: I'll keep the NetworkInfo. we've several other types and fields named based on it. so we (a) would get inconsistent or (b) change the wire protocol
<dimitern> TheMue, what are these cases?
<TheMue> dimitern: e.g. MachineNetworkInfoResult with the Info field and MachineNetworkInfoResults containing the former
<dimitern> TheMue, that's fine - the field can be called Info, but the internal type should be params.NetworkConfig
<TheMue> dimitern: and so don't change the name of the types too?
<dimitern> TheMue, I'd add a TODO comment there to change the field from Info to Config
<dimitern> TheMue, or even name the field Config but leave the json:"Info" tag on it
<dimitern> TheMue, which types?
<TheMue> dimitern: MachineNetworkInfoResult in MachineNetworkConfigResult, and ...Results too
<dimitern> TheMue, ah, ok - let's call them MachineNetworkConfigResult etc. as the type names don't matter
<TheMue> dimitern: also in the code we reference it as info :D
<TheMue> dimitern: but that's easy to change
<dimitern> TheMue, cheers :)
<rogpeppe> so can someone tell me a definitive query that lets me know whether juju-core commits are blocked, please?
<TheMue> dimitern: networks counterpart in one place is InterfaceInfo *lol* the trail of the info
<dimitern> TheMue, indeed, we'll likely change that at some point as well
<mgz> rogpeppe: `bzr branch lp:juju-ci-tools; cd juju-ci-tools; ./check-blockers.py master ${YOUR_PR}`
<dimitern> TheMue, but the params.NetworkConfig should correspond to network.InterfaceInfo for now
<rogpeppe> mgz: thank you
<TheMue> dimitern: I'll add TODOs
<dimitern> TheMue, +1
<rogpeppe> mgz: one tiny change - the "-" should actually be "_" there
<jw4> mgz: thanks, i've been looking this morning for that repo again, but I couldn't remember where it was
<mgz> ups yeah, underscores
<rogpeppe> mgz: it would probably be better overall if it was an online status, because if someone changes the criteria, i'll have to re-pull that repo
<mgz> we've talked about putting it on reports
<mgz> you could still have an out of date page, running the script is just what the lander does in practice
<mgz> I struggle to believe pull/run script is that complex for a bunch of elite programmers
<jw4> mgz: tsk tsk.. .snarkiness ill becomes you ;)
<mgz> hey, I struggle to get underscores vs hyphens right :)
<jw4> haha
 * dimitern eod-s
<rogpeppe> anyone know how to enable feature flags?
<jw4> rogpeppe: export JUJU_DEV_FEATURE_FLAGS="<flag name>"
<rogpeppe> jw4: i just managed to work that out...
<jw4> heh
<jw4> :)
<rogpeppe> jw4: if i set it when bootstrapping an environment, it'll be inherited by all that environment's instances, right?
<rogpeppe> jw4: (i *think* i saw that in the code, but just making sure)
<jw4> rogpeppe: that is beyond my ken
<jw4> rogpeppe: but that sounds plausible :)
<rogpeppe> jw4: well... we'll see what happens if/when this bootstrap works
<rogpeppe> jw4: it worked!
<jw4> rogpeppe: suhweet
<voidspace> ok, EOD
<voidspace> g'night
<waigani> wallyworld: thanks for the review
<waigani> wallyworld_: I've addressed your review, thanks: http://reviews.vapour.ws/r/928/
<wallyworld_> ok
<wallyworld_> waigani: reviewed, have to head to dentist in about 20 mins, will check as soon as i'm back if not before I go
<waigani> wallyworld_: thanks
#juju-dev 2015-02-17
<anastasiamac_> axw: wallyworld_: plz don't review yet :D m resolving merge conflicts
<axw> ok
<wallyworld_> k
<anastasiamac_> wallyworld_: someone has been very busy in the area
 * anastasiamac_ rolls eyes :D
<anastasiamac_> axw: wallyworld_: and resolved... PTAL http://reviews.vapour.ws/r/941/
<axw> looking
<anastasiamac_> axw: tyvm :D
<thumper> phew
<thumper> doc finished (for now)
<thumper> email sent
<thumper> I'm done
 * thumper looks for the wine
<TheMue> morning
<anastasiamac_> TheMue: morning
<TheMue> anastasiamac_: heya o/
<TheMue> anastasiamac_: still awake?
 * TheMue has to look at the time zones
<anastasiamac_> TheMue: it's 7pm, m about to take my son to soccer
<anastasiamac_> TheMue: but will be back again soon :D
<TheMue> anastasiamac_: ah, ok, not so late, but a good time to care for the son
<anastasiamac_> TheMue: u r not travelling very far in April ;(
<TheMue> anastasiamac_: absolutily not, and the city is IMHO quite boring (have been there twice)
<anastasiamac_> TheMue: yes, it's good time to care for one... unfortunately, i have 3 :(
<TheMue> anastasiamac_: there are others more interesting, like Hamburg or Berlin
<anastasiamac_> TheMue: but with us, it will feel like new :D
<TheMue> anastasiamac_: hehe, I've got 2, but the are now almost 19 and 21.
<anastasiamac_> TheMue: oh - so u know my dilemma
<TheMue> anastasiamac_: yep *lol*
<anastasiamac_> TheMue: ttyl
<TheMue> anastasiamac_: cu
<jam> fwereade: how's it going?
<fwereade> jam, heyhey
<fwereade> jam, actually decent again, how about you?
<fwereade> axw, thanks for moving those relation.Hook* things
<fwereade> axw, I was worried there'd be import hassle
<axw> fwereade: nps, I hope it looks okay?
<fwereade> axw, I haven't looked at the change, just the log,but it sounds absolutely sane
<axw> ok :)
<axw> fwereade: I'll have some more changes soon, but that'll all be about storage. probably will have to pick your brain again soon
<jam> fwereade: did you have a good weekend? Things are going ok here, though we should get back on Leader Election stuff
<jam> I did manage to land a couple patches there
<fwereade> jam, yeah, I saw, and I have one here with just a few review fixes to apply I think
<fwereade> jam, so we're getting perilously close to the actually-call-the-apis point
<jam> fwereade: I was thinking to go make some coffee and then jump on a hangout, does that sound decent to you?
<fwereade> jam, perfect, will do likewise
<voidspace> dooferlad: dimitern: TheMue: got kicked out! Need to reauthenticate, sorry
<dooferlad> dimitern, TheMue, voidspace: https://github.com/dooferlad/next_up
<TheMue> *click*
<dooferlad> TheMue: Would happily move the remaining Python stuff into Go, but can't justify the time spent at the moment. Suggestions welcome :-)
<dimitern> dooferlad, nice! :)
<voidspace> dooferlad: cool
<TheMue> dooferlad: will come automatically over the time
<TheMue> dooferlad: together with more commenting *scnr*
<dooferlad> TheMue: It has... evolved quickly.
 * fwereade lunch
<dooferlad> TheMue: I would classify it as "I don't like it, but it works"
<voidspace> dooferlad: for the JSON documents in Go you could use a generic (bad choice of word) JSONObject
<voidspace> dooferlad: with methods to fetch a map, an array or a string
<voidspace> dooferlad: and then just traverse the known structure
<voidspace> dooferlad: this is what we do for MaaS - you could nick the code from that
<voidspace> it's still a bit more tedious than Python, but you don't have to define a type for each document
<dooferlad> voidspace: cool!
<voidspace> so GetArray returns a JSONObject representing the array, or an error if the underlying JSON you've asked for isn't an array
<voidspace> so more than half your code is still error handling :-)
<voidspace> provider/maas/environ.go is a good place to look for examples
<voidspace> and by coincidence the place you'll need to be looking for the networking stuff
<voidspace> dooferlad: did you say you had a pact referral code?
<voidspace> dooferlad: I'm thinking of giving them a try
<voidspace> dooferlad: gomaasapi.JSONObject
<voidspace> which should probably be broken out into it's own little library
<dooferlad> voidspace: https://www.pactcoffee.com/spread/james-cmocka
<voidspace> dooferlad: thanks
<dooferlad> voidspace: that gomaasapi.JSONObject looks spot on!
<voidspace> dooferlad: coffee ordered :-)
<dooferlad> voidspace: hope you enjoy it :-)
<TheMue> aaaah, found it, go test dislikes the combination of -check.v or -gocheck.v with ./...
<dimitern> TheMue, yeah, it's either go test -v ./... or go test -check.v (in current dir)
<voidspace> dimitern: dooferlad: https://www.dropbox.com/s/ovdml6fs4u3n1wv/maas.txt?dl=0
<voidspace> dimitern: dooferlad: that's the document on the container addressability information for MaaS
<dimitern> voidspace, thanks, looking
<voidspace> it's just an overview, but hopefully detailed enough to be useful
<voidspace> feel free to point out errors, missing information or suggest clarification
<voidspace> it doesn't detail all the specific API calls as they should be clear from the code
<voidspace> it's meant as a guide to the code
<jam> fwereade: are you around to chat a bit about the Dying() stuff?
 * jam goes to walk the dog
<dimitern> hey guys, fwereade just texted me he's having issues with the internet connection
<dimitern> tasdomas, ^^
<jw4> plantuml state diagram of uniter modes : http://reviews.vapour.ws/r/944/
<jw4> still really basic; lots of room for improvement
<jw4> katco: fyi, you were interested in this ^^
* ChanServ changed the topic of #juju-dev to: https://juju.ubuntu.com | On-call reviewer: see calendar | Open critical bugs:  1416928
<marcoceppi> gsamfira aznashwan o/
<gsamfira> marcoceppi hey there :D
<katco> jw4: thanks, i'll have a look :)
 * katco is OCR today; covering for perrito666 who is on holiday today. Please send review requests my way!
<TheMue> katco: don't cry so loud, I'm currently finishing a larger one
<TheMue> katco: :D
<katco> TheMue: haha
<sinzui> wwitzel3, You can merge your fix for bug 1417875 and since your work is required for 1.21 and 1.22, you were permitted to to use the __JFDI__ to make it merge
<mup> Bug #1417875: ERROR juju.worker runner.go:219 exited "rsyslog": x509: certificate signed by unknown authority <canonical-bootstack> <logging> <regression> <juju-core:In
<mup> Progress by wwitzel3> <juju-core 1.21:In Progress by wwitzel3> <juju-core 1.22:In Progress by wwitzel3> <https://launchpad.net/bugs/1417875>
<wwitzel3> sinzui: thank you
<sinzui> dimitern, how goes your fix for bug 1416928
<mup> Bug #1416928: juju agent using lxcbr0 address as apiaddress instead of juju-br0 breaks agents <api> <lxc> <network> <juju-core:In Progress by dimitern> <juju-core 1.21:In Progress by dimitern> <juju-core 1.22:In Progress by dimitern> <https://launchpad.net/bugs/1416928>
<dimitern> sinzui, mostly done, testing various scenarios live now
<sinzui> rock, thank you dimitern  and wwitzel3
<bodie_> where can I find a picture of what's going on with Windows support?  We're looking to add an "action kill" worker behavior which we were planning to implement using syscall; do we need to implement windows support as well (I know we offer a few Windows charms?)
<bodie_> (the current plan is to implement it in a system agnostic way and add OS specific support, fwiw.)
<jw4> katco: tx
<katco> jw4: ty :)
<dimitern> mgz, ping
<mgz> dimitern: hey
<dimitern> mgz, hey, any update on goose? :)
<mgz> I have script for managing the pull/test, plan today is fork the existing gating job and add as experimental without the github actual landing part
<dimitern> mgz, sweet! please keep me updated
<katco> dimitern: would goose need a new branch for adding cinder support? technically it's not a breaking change
<dimitern> katco, it depends on the PR I guess
<katco> dimitern: picture a new package
<dimitern> katco, if you're only adding things, cindertest double subpackage included, then I guess it's backwards compatible
<mgz> katco: it shouldn't, but I think we never did the "cloud doesn't support this extention/module" code, so you may have compat issues
<katco> mgz: you mean instances of openstack that don't support cinder?
<mgz> or only expose it via the nova interfacs
<katco> mgz: i'm not touching the nova package, i think it's expected that users utilize the cinder API
<katco> mgz: but i might be missing the just of what you're saying
<mgz> right, which may not work on any given cloud
<mgz> because the older api was through nova
<katco> mgz: so wouldn't they then be able to fall back to the nova implementation? or is that not in goose?
<dimitern> katco, not the storage apis of nova
<katco> dimitern: mgz: ah i see
<dimitern> katco, but I'd vote to deal with this if we need to
<dimitern> cinder api is the way forward, if we need to also support nova legacy storage apis, we'll do it
<mgz> basically, I think we just want to make sure the code does something sensible if keystone doesn't give you a cinder endpoint
<mgz> because that's what would break existing uses
<katco> mgz: good point. i think that's more on the juju side though
<katco> dimitern: agreed. now that i can auto-generate api client's it can be trivial
<mgz> we only look at endpoints if you import and try to construct a cinder object?
<katco> mgz: it would fail upon making a cinder call most likely
<mgz> okay, that's late enough I guess
<katco> mgz: i haven't actually wrapped goose around the auto-generated client yet
<dimitern> katco, i'd like to have a look at your proposal when you're ready btw
<katco> dimitern: sure thing. that's what i'm working on today
<katco> dimitern: (i'll be getting back to amz after this, but i want to unblock my team)
<dimitern> katco, sgtm
<katco> dimitern: here's the autogenerated code: http://paste.ubuntu.com/10212665/
<dimitern> katco, cool, can I suggest to tweak the generation to follow Go style guide? e.g. no "_" in field names mostly and stripping <tags> from doc comments will be nicer
<katco> dimitern: yeah it needs a bit more cleanup. i'm not sure i'll be able to easily get rid of the "_", but will endeavor to
<katco> dimitern: within a reasonable amount of time
<dimitern> katco, cheers
<dimitern> katco, also, are these client-facing exports?
<katco> dimitern: the idea is that goose wraps this
<dimitern> katco, i.e. do I have to call DeleteSnapshot(request MakeRequestFn, args DeleteSnapshotParams) directly?
<dimitern> katco, ah, that's better
<katco> dimitern: so probably not; we'll see how the api evolves
<katco> dimitern: mostly i just didn't want to sit there and write a billion http requests :)
<dimitern> katco, do you even need them all?
<katco> dimitern: what do you mean?
<dimitern> katco, remember that everything we use in juju needs a corresponding support in its corresponding test double (e.g. testservices/novatestservice)
<dimitern> katco, so that live tests can be written against these and run (quickly) against them the same way as they would against live OS servers
<katco> dimitern: apologies; i'm not drawing the connection
<dimitern> katco, the test servers implement the same API as the real openstack servers (well, only a subset needed by juju)
<katco> dimitern: do http requests somehow preclude us from testing that manner?
<dimitern> katco, so that you can then write "local live" tests running against the test doubles or real openstack servers
<dimitern> katco, no, but if you implement the full cinder api just to save time writing each method individually, this won't help with the implementation of the test double
<katco> dimitern: i.e. the tests should be able to use this code to hit the test double
<voidspace> dimitern: ping
<dimitern> katco, juju (and its live tests) will use the generated code to talk to real OS API or the test double
<katco> dimitern: i might be missing something, but i still don't see an issue
<katco> dimitern: just pass in a MakeRequestFn that does what you want with the *http.Request
<dimitern> katco, it's not just about tweaking a request or response, it's about faking a sequence of calls, e.g. start a node, allocate an ip to it, list node's ips, set node state, etc.
<katco> dimitern: i'll have a look at nova and see if i can understand better what you're describing
<dimitern> katco, yeah, have a look at juju livetests as well and you the open stack test services are used in goose and in juju
<katco> dimitern: ok will do. thanks!
<dimitern> katco, np! after going through the code you'll probably understand better what I'm trying (and obviously failing :)) to explain
<katco> dimitern: no worries; i'm sure you're right :)
<aznashwan> hey, just another quick centos-userdata question for you guys: considering that cloudinit only has very marginal support for [serious] yum-related work, would anyone consider it bad to run all other the packaging-related operations as {boot,run}cmds?
<dimitern> I'd appreciate a review on http://reviews.vapour.ws/r/946/ which fixes the critical 1.21 release blocker bug 1416928
<mup> Bug #1416928: juju agent using lxcbr0 address as apiaddress instead of juju-br0 breaks agents <api> <lxc> <network> <juju-core:In Progress by dimitern> <juju-core 1.21:In Progress by dimitern> <juju-core 1.22:In Progress by dimitern> <https://launchpad.net/bugs/1416928>
<TheMue> gnah, my local git repo dislikes me. thankfully e'thing is pushed
<TheMue> dimitern: *click*
<dimitern> TheMue, ta!
<stokachu> if proxies are defined within juju are they exported to the charm's environment as well?
<stokachu> for things like wget to utilize
<TheMue> dimitern: you've got a review
<dimitern> TheMue, thanks!
<dimitern> stokachu, yes they are
<TheMue> dimitern: yw
<TheMue> dimitern: I'll push mine when I fixed my git troubles :D
<dimitern> TheMue, ok
<natefinch> sinzui: what's the bug situation?  Anything blocking us that I should be looking into?
<sinzui> natefinch, I think dimitern and wwitzel3 are finishing up.
<sinzui> natefinch, there is this issue been in 1.22 that needs someone to investigate and maybe fix bug 1420049
<mup> Bug #1420049: ppc64el - jujud: Syntax error: word unexpected (expecting ")") <deploy> <openstack> <regression> <uosci> <juju-core:Triaged> <juju-core 1.22:Triaged> <https://launchpad.net/bugs/1420049>
<dimitern> natefinch, my fix has a review and I'll be setting it to land before I go today
<natefinch> dimitern: cool
<katco> dimitern: i think i see what you're saying? auto-generating the client doesn't save any time because i have to write all the mock endpoints anyway?
<voidspace> right EOD
<katco> tc voidspace
<voidspace> dimitern: I'll post my self  evaluation later (nearly done) - and email you about my branch
<voidspace> dimitern: what's still to be done (not much - just one bit of code to be moved and maybe another test I think)
<voidspace> but later
<voidspace> gotta go now
<voidspace> katco: bye o/
<katco> voidspace: ciao
<dimitern> katco, yep
<dimitern> :)
<katco> dimitern: i might have to auto-generate those too :)
<dimitern> katco, now that will be awesome! :)
<wwitzel3> thumper: ping
<thumper> pong
<wwitzel3> thumper: quick hangout
<thumper> sure
<wwitzel3> thumper: https://plus.google.com/hangouts/_/canonical.com/moonstone?v=1423613698&clid=BF4AF0604617145E&authuser=0
<sinzui> wallyworld, xwwt good news of sorts. the job failed without lxc. Looks like an apt issue
<wallyworld> oh, interesting
<xwwt> sinzui, so this might not be the br0 error?
<sinzui> xwwt, yep
<sinzui> wallyworld, What is this
<sinzui> 2015-02-17 22:45:18 ERROR juju.cmd supercommand.go:323 failed to stop mongo: exec ["stop" "--system" "juju-db"]: exit status 1 (stop: Method "Get" with signature "ss" on interface "org.freedesktop.DBus.Properties" doesn't exist)
<sinzui> I think the dbus package got removed when I removed the lxc?
<sinzui> yep it was missing
<sinzui> retesting now
<wallyworld> fingers crossed
<sinzui> wallyworld, xwwt   The bug is fixed, we are unblocked. The false failure was cause by a mongod being left behind by the broken juju. I had to clean the machine to let the test run cleanly.
<wallyworld> sinzui: awesome
<sinzui> wallyworld, we have two passes in a row, so I an sure working juju cleans up
<sinzui> wallyworld, CI has blessed the 1.21 rev. I will send packages of to the builds now
<wallyworld> whiihii
<wallyworld> whoohoo
<sinzui> wallyworld, do you have a moment to review this formality http://reviews.vapour.ws/r/948/
<wallyworld> sure
<wallyworld> sinzui: i love your optimism :-)
#juju-dev 2015-02-18
<anastasiamac_> wallyworld: r u getting my msgs?...
<wallyworld> yes, but in the midle of something
<wallyworld> be with you in a sec
<anastasiamac_> wallyworld: k :D
<katco> anastasiamac_: 0/ how are you
<anastasiamac_> katco: o/ m good :D
<anastasiamac_> katco: u?
<katco> anastasiamac_: doing good!
<davecheney> thumper: did my performance review, with literally hours to spare
<davecheney> a new record
<thumper> davecheney: thanks
<thumper> davecheney: when are you off?
<davecheney> flight leaves at three
<davecheney> i need to get my ass in a cab
<thumper> :)
<thumper> have a good trip
<davecheney> will do
<beisner> sinzui & co. -  fi scenario does indeed succeed with 1.20.x - bug updated https://bugs.launchpad.net/juju-core/+bug/1420049
<mup> Bug #1420049: ppc64el - jujud: Syntax error: word unexpected (expecting ")") <deploy> <openstack> <regression> <uosci> <juju-core:Triaged> <juju-core 1.22:Triaged> <https://launchpad.net/bugs/1420049>
<sinzui> beisner, thank you very much.
<beisner> s/fi/fyi/
<beisner> sinzui, happy to test it.  holler if you need me to throw anything else against that hardware.
<sinzui> wallyworld, bug 1420049 is confirmed to be a regression from 1.20.x
<mup> Bug #1420049: ppc64el - jujud: Syntax error: word unexpected (expecting ")") <deploy> <openstack> <regression> <uosci> <juju-core:Triaged> <juju-core 1.22:Triaged> <https://launchpad.net/bugs/1420049>
<sinzui> wallyworld, bug 1407699 appears to be back. precise and aws and lxc are failing in CI for branch 1.22
<mup> Bug #1407699: Precise services cannot be deployed <ci> <deploy> <precise> <regression> <juju-core:Fix Released by wallyworld> <cloud-init (Ubuntu):New> <https://launchpad.net/bugs/1407699>
<waigani> wallyworld: http://reviews.vapour.ws/r/928/ - one issue unresolved, I've replied with a possible solution, see what you think
* ChanServ changed the topic of #juju-dev to: https://juju.ubuntu.com | On-call reviewer: see calendar | Open critical bugs:  1416928 1423036
<anastasiamac_> thumper: howdy? r u looking at bug 1421237?....
<mup> Bug #1421237: DEBUG messages show when only INFO was asked for <ci> <regression> <security> <juju-core:Triaged> <https://launchpad.net/bugs/1421237>
<anastasiamac_> thumper: it currently blocks CI :D
<thumper> anastasiamac_: I'm busy arguing about it - it isn't us
<anastasiamac_> thumper: \o/
<thumper> I've just commented again
<thumper> and moved it back to incomplete
<thumper> I'm guessing the problem is environmental
<anastasiamac_> thumper: :D
<thumper> wallyworld: you around?
<thumper> wallyworld: I'd like you to join waigani and me for a chat about destroy environment behaviour
 * thumper looks at the time and guesses wallyworld is having lunch
<thumper> waigani: probably best to wait for wallyworld
<thumper> so I'm not repeating myself
<thumper> we are going to need clear docs around this too :-)
<waigani> thumper: ah yep okay
<rick_h_> thumper: how goes?
<thumper> rick_h_: good
<thumper> rick_h_: I'm wanting more feedback on my spec BTW
<rick_h_> thumper: k, will see what I can do
<thumper> I'm going to chase up john too
<rick_h_> thumper: good plan
<thumper> rick_h_: I may take urulama off the approval list
<rick_h_> thumper: k
<thumper> as I've removed many references to other things out of the scope of the spec
<thumper> rick_h_: and I'm wanting to get moving on this ASAP
<rick_h_> thumper: understand
 * thumper is considering a flag called --dont-look
<thumper> or perhaps --jfdi
<thumper> nah
<rick_h_> what part needs jfdi'ing?
<thumper> perhaps it should be --i-know-there-are-no-other-environments
<thumper> juju destroy-environment --force
<thumper> when there are possibly multiple environments
<rick_h_> ugh
<thumper> it'll leave other environments running
<thumper> but in a deadish state
<rick_h_> gets back to new commands for 'server' vs environment
<rick_h_> this 'special' environment thing is going to kill us
<thumper> do you think it should be 'juju server destroy' ?
<rick_h_> juju destroy-environment --force ec2 does just that, juju destroy-server is what you need to kill a JES
<rick_h_> yep, no way to do it on accident
<thumper> but...
<thumper> there is no --force
<thumper> for a non-server environment
<thumper> we do that anyway
<thumper> provider, plz kill all these machines
<rick_h_> ok, so what?
<rick_h_> so there's not a flag --force on the new command for a JES
<thumper> so 'juju server login' ?
<rick_h_> big deal
<rick_h_> +1 from me
<thumper> juju server list?
<rick_h_> make it less magical to users
<thumper> what does that mean?
<rick_h_> list servers that I have cached local info about
<rick_h_> e.g. list the servers I've logged into
<thumper> not list me the environments on the current server?
<rick_h_> nope, that's juju login some-server
<rick_h_> juju environment list
<rick_h_> and I don't expect to see the JES in that list
<thumper> hmm...
<rick_h_> basically don't expose the implementation detail to user, make it a completely safe split
<rick_h_> in my opinion and all that
<rick_h_> otherwise there's too many 'oops' and 'doh' cases to think about
<thumper> now we are breaking history
<rick_h_> what history? JES is new :)
<thumper> because destroy-environment now isn't how you stop a local environment
<rick_h_> it's a new feature with new commands and ...
<thumper> bootstrap still starts and environment
<rick_h_> how does one stop a local environment then?
<rick_h_> bootstrap starts a JES
<rick_h_> don't call it an environment
<thumper> this is going to fuck so many people off
<rick_h_> again, implementation detail to the user
<rick_h_> why?
<rick_h_> I think if you list it out there's a whole lot less pain to deal with this way than trying to tell apart magic environments from non-magic environments across users/scripts/cli
<thumper> hmm...
<thumper> however...
<thumper> renaming the function doesn't stop the problem
<thumper> juju server destroy foo --force -y
<thumper> could still leave environments running but dead
<rick_h_> then it needs to clean them up before it dies or else block and stop and refuse to die
<thumper> juju server destroy foo --force -y --trust-me
<rick_h_> until those envs are gone
<thumper> --force doesn't fail if the API is broken
<rick_h_> ic
<thumper> not sure --force even tries
 * thumper looks
<thumper> 	// If --force is supplied, then don't attempt to use the API.
<thumper> 	// This is necessary to destroy broken environments, where the
<thumper> 	// API server is inaccessible or faulty.
<rick_h_> you know sabdfl will want it to be like his locking spec then.
<rick_h_> thumper: you'll have to have a code or something to enter with giant warnings like this block stuff getting implemented
<rick_h_> thumper: see https://docs.google.com/a/canonical.com/document/d/1oBZ2oIZOok64_QbWVPfY5Q2I053peESPZYtKSdF_L6E/edit for the original stuff on it
<thumper> rick_h_: that didn't make sense
<rick_h_> thumper: saying that if --force is going to potentially do bad things to running envs ^ document and https://docs.google.com/a/canonical.com/document/d/1XFYlNGmQH7-X68IXhdxsANwHN6DgAL_RMn7IDK7ZbJc/edit will come into play
<rick_h_> thumper: well, they should come into play
 * thumper is looking
<thumper> rick_h_: the problem with all these solutions is they don't take into account the --force option
<thumper> as it lives now
<thumper> perhaps we have to remove the --force option altogether
<rick_h_> thumper: right, but they're all trying to work in the space of your problem so whatever you do should take into account all of that
<thumper> rick_h_: really this behaviour is outside the scope of what we are doing
<thumper> and we have blocks now
<rick_h_> thumper: possibly, or provide --force via a third party tool like the stuff to remove juju now
<thumper> which anastasiamac_ has been doing
<thumper> I think her current work addresses some of this
<rick_h_> thumper: right, agree with that
<thumper> rick_h_: I think perhaps a developer plugin, like the juju-nuke plugin
<rick_h_> just saying it should fit whatever you end up doing as well. e.g. don't make it easy for users to accidentally make envs go boom that should not have
<rick_h_> thumper: +1
<thumper> fark...
<thumper> how to get all this done sanely and quickly...
<rick_h_> but get it right vs fixing it later :)
<thumper> yeah...
<thumper> fuck fuck fuck fuck fuck
<thumper> shit
<thumper> rick_h_: I was feeling pretty happy with this document before
<rick_h_> remeber, "I love my job I love my job"
<thumper> and now it is all screwed
<thumper> thanks
<rick_h_> sorry man, you asked for feedback. :/
<thumper> don't get me wrong, I appreciate the feedback
<thumper> it is just I'm getting real sick of speccing all this out
<rick_h_> thumper: let me know if there's anything I can do to help. I really care/want this to come out awesome and happy to help.
<rick_h_> thumper: but been on the road 12 hrs today so going to go to bed and crash.
<thumper> rick_h_: ack
 * thumper heads away from the laptop to think this over and reread the spec with fresh eyes
<wallyworld> sinzui: i saw the precise bug. i added some input. i suspect an out of date apt mirror, but could be wrong
<sinzui> wallyworld, aws, joyent, and hp?
<wallyworld> sinzui: before i committed the previous fix, i tested on aws. the bug refers to an aws CI test. i just now tested with AWS again
<wallyworld> so the CI run fails on AWS
<sinzui> wallyworld, yes
<wallyworld> but i have no trouble running up an aws env
<wallyworld> but theory about an apt mirror out of date is just a theory
<wallyworld> i could be totally off the mark
<sinzui> aws got
<sinzui> Unpacking cloud-image-utils (from .../cloud-image-utils_0.27-0ubuntu9~ctools0_all.deb) ..
<wallyworld> it's cloud-utils we are worried about
<wallyworld> https://launchpad.net/~ubuntu-cloud-archive/+archive/ubuntu/tools
<wallyworld> cloud-archive-utils 	0.1-0~35~ubuntu12.04.1 	Ubuntu Cloud Archive Team (2015-02-13)
<sinzui> waigani, Removing cloud-utils ...
<wallyworld> the metadata for cloud-utils was wrong, and the fix is in the above
<wallyworld> if an old cloud-utils is used, the issue as per the failed CI test occurs
<thumper> wallyworld: got a few minutes?
<wallyworld> the issue is that installed cloud-image-utils causes cloud-utils to be removed
<thumper> sinzui: RE: the debug logging bug, I'm pretty sure it is environmental
<thumper> sinzui: and "hai"
<thumper> wallyworld: I want to run some ideas past you
<sinzui> wallyworld, I just attached the cloud-init-output log to https://bugs.launchpad.net/juju-core/1.22/+bug/1423036
<mup> Bug #1423036: precise services cannot be deployed (again) <ci> <precise> <regression> <juju-core 1.22:Incomplete> <https://launchpad.net/bugs/1423036>
<wallyworld> i'm confused as to why i can run up an AWS env ok, but CI fails
<thumper> wallyworld: same region?
<thumper> sinzui, wallyworld: I have experienced differences in AWS over different regions before
<thumper> not sure if they still operate weirdly
<sinzui> thumper, good example. wallyworld I think this case is broader since the precise machine in Hp and precise tests in joyent also failed
<sinzui> wallyworld, I know mirrors should update every day, but some can be a week behind
<sinzui> but for all 3 to be behind? that is surprising
<sinzui> wallyworld, I also blew away the lxc cache on the precise lxc machine
<sinzui> wallyworld, https://launchpad.net/ubuntu/trusty/amd64/cloud-image-utils says the new cloud-image-utils is *proposed* not updates as cloud images require
<wwitzel3> thumper: https://bugs.launchpad.net/juju-core/+bug/1413052 feedback on my reply when you have a second
<mup> Bug #1413052: juju status hangs <status> <juju-core:Triaged> <https://launchpad.net/bugs/1413052>
<wallyworld> sinzui: your aws deployment is indeed pulling out of date cloud-utils. I added some info to bug. But I don't know enough packaging and the repos involved
<wallyworld> there's different data here http://ubuntu-cloud.archive.canonical.com/ubuntu/dists/precise-updates/cloud-tools/main/binary-amd64/Packages and here https://launchpad.net/~ubuntu-cloud-archive/+archive/ubuntu/tools
<wallyworld> the latter is up to date, the former is out of data
<wallyworld> date
<wallyworld> why my AWS deployment works I have no idea; I would have though it would be consistent
<sinzui> wallyworld, I can see the joyent pulled the old package from the real archive, but Lp does agree the new package arrived a few days ago
<sinzui> unless joyent, aws, and hp have proxies between ctools
<sinzui> wallyworld, I need to sleep. When I look at http://ubuntu-cloud.archive.canonical.com/ubuntu/dists/precise-updates/cloud-tools/ and everything below, all the data is from last year. no files mention the new packages
<sinzui> wallyworld, but I can see that proposed does know about the new packaged http://ubuntu-cloud.archive.canonical.com/ubuntu/dists/precise-proposed/cloud-tools/
<sinzui> Maybe the archive is not really at the state Lp thinks it is. This is true for releasing juju. I need to count the packages in the archive because Lp doesn't read the file systems
<wallyworld> sinzui: do you have any idea about the archive issues?
<thumper> wallyworld, waigani: we should hold off on the destroy-environment landing until we get some agreement on the spec
<thumper> wallyworld: please hold off any more reviewing until you, me and waigani have had a chat
<thumper> wallyworld: did you get either of those?
<wallyworld> those what?
<wallyworld> stupid freenode conection :-(
<thumper> wallyworld, waigani: we should hold off on the destroy-environment landing until we get some agreement on the spec
<thumper> wallyworld: please hold off any more reviewing until you, me and waigani have had a chat
<wallyworld> sure
<thumper> ta
<wallyworld> thumper: is that due to the conversation with rick?
<thumper> yup
<wallyworld> i was wondering about that
<anastasiamac_> wallyworld: dunno if u saw it  (with ur connection misbehaving and all)...
<anastasiamac_> wallyworld: re-proposed PTAL http://reviews.vapour.ws/r/941/
<wallyworld> ok, might have to be after soccer
<TheMue> morning
<jam> fwereade_: when you're around, give me a ping
<fwereade_> jam, heyhey, just finished with domas
<jam> fwereade_: hey, brb. I'll be in leader-election hangout when you're available just using the restroom quickly
<TheMue> dimitern: ping
<dimitern> TheMue, hey
<TheMue> dimitern: seen your comments on GH, some are already done in the PR
<TheMue> dimitern: regarding the MachinePortsResults, this type relies on MachinePorts which is older and looks different than our networking stuff
<TheMue> dimitern: but still move anything related to networks?
<TheMue> dimitern: at least it uses a NetworkTag
<TheMue> dimitern: in MachinePorts
<dimitern> TheMue, yeah, it's older but still networking related and used by the firewaller IIRC
<dimitern> dooferlad, ping
<TheMue> dimitern: it is, yes
<TheMue> dimitern: ok, so will move it too
<dooferlad> dimitern: Hi, was just looking at that bug
<dimitern> TheMue, cheers
<dimitern> dooferlad, hey! so the foreport to 1.22 should be easy, but let's talk about the fix during/after standup
<dooferlad> dimitern: will do
<dimitern> dooferlad, ta
<dimitern> TheMue, dooferlad, sorry, I'll be ~5m late for standup
<jam> fwereade_: http://reviews.vapour.ws/r/949/ for some of the cleanups that I've done so far.
<jam> fwereade_: ping
<fwereade_> jam, sorry, missed the review link
<jam> fwereade_: np. Not urgent. I wanted to check something else with you
<jam> specifically what we found with livesource.go
<fwereade_> jam, the for loop?
<jam> where it was using wg.Add() wg.Done() which means that the goroutine is blocked if you never call the func
<fwereade_> jam, ah yes
<jam> I have a test that fails, by observing that source.Changes() channel is never closed if you call source.Stop() but don't call the func.
<jam> I'm trying to figure out what we want instead of the for loop. Is it that we need to go to a full func loop() ?
<perrito666> morning all
<jam> hi perrito666
<jam> fwereade_: thoughts on what the correct fix is? I think we talked about NewLiveSource needing its own Tomb
<jam> or alternatively use a channel implementation
<jam> (create a channel, close it in the func(), rather than wg.Add, select over that channel and the tomb so we know when we need to clean up.)
<jam> I think with a channel we don't have to have a full "loop" but we probably need a Tomb, and if we have a tomb, going to a loop() is probably clearer code as it follows the model of similar code.
<fwereade_> jam, yes, I think we do in general just want our own tomb
<fwereade_> jam, hence for loop
<fwereade_> jam, and I think it's generally nice practice to pull the loop out into its own method, returning an error, for consistency's sake if nothing else
<jam> k
<fwereade_> jam, I think I remember how to do it "right"
<fwereade_> jam juju/state/watcher.Stop(Stopper, *tomb.Tomb)
<fwereade_> jam, so if it were in a less unhelpfully-samed package
<fwereade_> jam, it would be clear that goroutine-wrapping-some-resource is a common pattern
<fwereade_> jam, and that Stop and EnsureErr are both generally useful for any components that wrap one resource
<fwereade_> jam, so
<fwereade_> defer self.tomb.Done()
<fwereade_> defer resource.Stop(self.resource, &self.tomb)
<fwereade_> self.tomb.Kill(self.loop())
<fwereade_> jam, ...along with
<fwereade_> case _, ok := <-self.resource.Changes():
<fwereade_>  
<fwereade_>     if !ok {
<fwereade_>         return resource.EnsureErr(self.resource)
<fwereade_>     }
<jam> fwereade_: "resource" isn't in livesource.go, you just mean in general?
<fwereade_> jam, yeah, the current package is state/watcher
<fwereade_> jam, but Stop and EnsureErr aren't specific to watchers
<jam> fwereade_: RelationUnitsWatcher only has Stop Err and Changes
<fwereade_> jam, oh wait maybe watchers have Stop() methods where workers have Kill() and Wait()?
<fwereade_> jam, gaah
<fwereade_> jam, I think the worker interface is saner
<fwereade_> jam, but, see? these fixes become fractally tentacular if we'renot careful :(
<jam> :)
<jam> yak shaving
<fwereade_> jam, indeed
<fwereade> jam, (btw: LGTM as is, despite quibbling, progress not perfection)
 * TheMue is out for lunch
<TheMue> dimitern: updated PR is in, see review board
<dimitern> TheMue, cheers, will look soon
 * dimitern steps out for ~1h
<perrito666> why are we getting so many curses?
<jw4> perrito666: curses?
<perrito666> from CI
<jw4> i.e. blockers? lol
<marcoceppi> any chance I can get a senior reviewer to took at this? http://reviews.vapour.ws/r/926/
<mgz> marcoceppi: looks good to me too, is eric's stamp not okay?
<marcoceppi> mgz: I was told to wait for a more sneior reviewer
<TheMue> marcoceppi: done
<marcoceppi> ta
<perrito666> TheMue: i am not being an incredible fan of http://reviews.vapour.ws/r/947/diff/2 why is it that you are not adding a method to apihostportresults that returns  Servers as NetworkHostPorts ?
<TheMue> perrito666: could be a helper too, yes. so far concentrated on structs or nested slices of hostport
 * TheMue sees our already large params with lots of conversion helpers in the future ...
<perrito666> TheMue: well borrowing from python :p better explicit
<perrito666> TheMue: what botters me the most is that I see a lot of params.NetworkHostPorts(someparam.Servers)
<perrito666> which is a bit noisy
<TheMue> perrito666: yeah, you get network, want params, get params, want network
<perrito666> so basically what I mean is, you are using params.NetworkHostPorts to convert a member of params.APIHostPorts :)
<perrito666> sounds like that should be happening on params :p
 * perrito666 laughs because param is the sound used in spanish for tada
<TheMue> perrito666: could you point me to file and line
<perrito666> TheMue: gimme a sec, trying to beat some sense into reviewboard :p
<TheMue> hehe
<perrito666> ohh ffs http://reviews.vapour.ws/r/947/diff/# file: api/state.go line 80
<perrito666> sometimes I really hate that ui
<TheMue> perrito666: thx, yes, here it creates the network.HostPorts out of the params.HostPorts
<TheMue> perrito666: and those are [][]<mypackage>.HostPort which are struct, gna
<perrito666> gna?
<TheMue> inner sound of "excitement" about this construct
<TheMue> :D
<perrito666> wwitzel3: ?
<perrito666> TheMue: I added the comment in the code
<TheMue> perrito666: great, thx
<dimitern> TheMue, hey, did you see my review about the live tests?
<dimitern> dooferlad, ping
<TheMue> dimitern: yep, just doing it with local provider. looks good so far.
<dimitern> TheMue, cool!
<dimitern> TheMue, I'll double check it here as well
 * dimitern doesn't want more regressions :)
<TheMue> dimitern: great, thx
<TheMue> hehe
<TheMue> dimitern: yeah, and this change already went too large. not in the sense of structure, but changed places.
<dimitern> TheMue, yeah, but I'd rather get it landed :)
<sinzui> dooferlad, how goes the backport of bug 1416928 to 1.22?
<mup> Bug #1416928: juju agent using lxcbr0 address as apiaddress instead of juju-br0 breaks agents <api> <lxc> <network> <juju-core:Triaged by dooferlad> <juju-core 1.21:Fix Released by dimitern> <juju-core 1.22:Triaged by dooferlad> <https://launchpad.net/bugs/1416928>
<dimitern> sinzui, he mailed me a couple of branches with the backports for 1.22 and trunk; I'm checking them now
<dimitern> oops - s/backports/foreports/ that is
<sinzui> dimitern, bug 1420049 is now confirmed to be a regression with 1.20. We need someone to address it.
<mup> Bug #1420049: ppc64el - jujud: Syntax error: word unexpected (expecting ")") <deploy> <openstack> <regression> <uosci> <juju-core:Triaged> <juju-core 1.22:Triaged> <https://launchpad.net/bugs/1420049>
 * sinzui would also ask natefinch to make arrangements, but he might be lost in the snow
<dimitern> sinzui, I'll have a look
<dooferlad> dimitern: sinzui: Happy to apply the fix to 1.20 as well.
<dimitern> dooferlad, which fix?
<dooferlad> dimitern: Oh, hang on, I got my bug numbers muddled! Thought both comments were about 1416928
<dimitern> dooferlad, yeah :)
<dimitern> dooferlad, I've pulled your branches with the foreports and once I'm done with live testing TheMue's changes I'll look at yours
<dooferlad> dimitern: turns out tests run better when the heatsink isn't dangling off your northbridge. Top computer stability tip.
<sinzui> dooferlad, 1.20 is not broken and we aren't release it any more. just 1.22 and master need the love
<dimitern> dooferlad, LOL :)
<dooferlad> dimitern: are there instructions for live testing, or is it in your head?
<dimitern> dooferlad, in my head, but I can try to summarize them, good point
<dimitern> dooferlad, i'll send them by mail
<dooferlad> dimitern: thanks.
<TheMue> dimitern: just had 1:1 and during this time I've seen an error on EC2. have to look for the reason now.
<TheMue> dimitern: hmm, maybe already found it
<dimitern> TheMue, I'm testing on maas first
<TheMue> dimitern: ah, fine, so different providers
<TheMue> dimitern: thought I found it but cannot get the reason for my "environment uuid was not supplied"
<dimitern> TheMue, you can easily test if your changes caused this (but I doubt it) - switch to master, rebuild, bootstrap :)
<TheMue> dimitern: yes, will check it this way
<dimitern> dooferlad, please go ahead and propose a PR for the 1.22 foreport
<dooferlad> dimitern: will do
<dimitern> dooferlad, cheers
<dimitern> TheMue, live tests on maas pass ok
<dimitern> TheMue, trying manual now and then ec2 and local
<TheMue> dimitern: ah, great info, thanks. seems to be local
<TheMue> dimitern: local in the sense of "here", not the provider
<TheMue> ;)
<dimitern> :)
<cherylj> katco - can you take a quick look at my changes for featuretests: http://reviews.vapour.ws/r/945/
<katco> cherylj: sure thing
<katco> cherylj: just one minor thing, but it looks great! thank you!
<dimitern> dooferlad, thanks, but can you change the PR description to mention this is a foreport of the original PR #1616 ?
<dooferlad> dimitern: sure
<dimitern> ..for 1.22
<dimitern> dooferlad, ta!
<cherylj> thanks, katco.  While I'm in there, I guess I should update the name of the suite to match the new filename
<katco> cherylj: ah good idea, i missed that
<dimitern> dooferlad, have you tried live testing this by bootstraping a manual environment to a machine with and without the lxc package installed?
<dooferlad> dimitern: no, I just ran the built in tests
<dimitern> dooferlad, do you know how to do it?
<dooferlad> dimitern: think so. The bug report is quite clear.
<dimitern> dooferlad, sweet, please give it a try and let me know how it went
<dooferlad> dimitern: will do
<perrito666> the least flooded part of my way home https://pbs.twimg.com/media/B-JP1USIIAAmYjv.jpg:large
<TheMue> dimitern: it looks like you can slap me, the error seems to be in front of the screen
<TheMue> dimitern: it's nice to create new build but the path should be set to use them *facepalm*
<dimitern> TheMue, so what's the issue?
<TheMue> dimitern: none anymore, currently it's running find. but during the last try with the error above I used some old and it seems instable build from last year
<TheMue> dimitern: path had been set wrong, not using my fresh builds
<dimitern> TheMue, right :) that's why I have my rebuild-juju script always in $PATH
<TheMue> dimitern: yep, changed it too. dumb error
<dimitern> TheMue, manual bootstrap also works
<TheMue> dimitern: EC2 looks fine so far too, waiting for the latest steps to complete
 * TheMue has to add this in his tool too, "jdt live-test amazon" or "jdt live-test local" etc.
<TheMue> Interesting, just read, Lenovo creates super-computer based on ARM
<perrito666> TheMue: well its always good not having to drag all the baggage x86 has
<TheMue> perrito666: +1
<perrito666> I guess not before long laptops with ARMs will be decent enough to use as a laptop
 * perrito666 suddenly remembers when there was via cyrix against intel or even ppc as desktop options (I am getting old)
<TheMue> dimitern: so, EC2 works fine too
<dimitern> TheMue, what did you test?
 * TheMue remembers his time with his 12" PowerPC notebook
<TheMue> dimitern: standard scenario, wp and mysql *lol*
<perrito666> TheMue: g4?
<TheMue> perrito666: exact
<perrito666> yup, my favorite form factor to the day
<perrito666> I was really sad to part with that thing
<TheMue> perrito666: I liked it a lot, and felt special with all those intels around
<TheMue> perrito666: they will come with an ARM, lets wait
<perrito666> I used to win an argument against my university teacher on why visual basic on windows was not a reasonable requirement to ask for a student (they would supply a free licence) I just handed to him saying, ok, ill use it if you manage to install it on my coputer
<TheMue> hehe
<dimitern> TheMue, add-relation, waiting for them to start, exposing, trying to open wp from a browser? and checking machine logs for suspicious ERROR and WARNING, right?
<TheMue> dimitern: yep
<dimitern> TheMue, sweet!
<TheMue> dimitern: already started to setup a wp presence
<dimitern> TheMue, I'll stamp it then - all my live tests went fine
<TheMue> dimitern: cool
<dimitern> TheMue, some of the issues you've resolved already - just sync up with menn0 and perrito666
 * perrito666 diffs with TheMue 
<TheMue> dimitern: yes, mennos is already done, and I like perrito666s idea. that will go in and be tested befor I push
<perrito666> natefinch: this change for de defer of the readcloser you added is a nightmare :p
<thumper> sinzui: can we chat plz?
<sinzui> thumper, yes
 * thumper starts a hangout
<thumper> sinzui: pm'ed the link
<perrito666> natefinch: could you take another look?
<perrito666> k ppl EOD but will be back later
<anastasiamac_> perrito666: this street looks awful :( r u on higher ground?
<jw4> OCR PTAL : http://reviews.vapour.ws/r/951/  <--- Running Actions while unit is in hook error state, without clearing the hook error
#juju-dev 2015-02-19
<perrito666> anastasiamac_: I am about 500 m from that but yes, my house is in slight higher ground
<perrito666> jw4: sorry mate, I dont understand the implications of your change enough to review it
<jw4> perrito666: I'm quite disappointed
<jw4> perrito666: :)
<perrito666> s*** happens
<jw4> :)
<perrito666> ok, definitely I need a reset, see you all tomorrow
 * perrito666 pulls the plug from the back of his head and falls out of the matrix into his kindle
<jw4> lol
<thumper> axw: oh hai mr on call reviewer
<thumper> axw: http://reviews.vapour.ws/r/952/
<katco> thumper: i think he's on holiday
<thumper> :(
<katco> thumper: for the lunar new year
<thumper> ah, I see yes, that is on the calendar
<thumper> I was just looking for the reviewer
<thumper> wallyworld: this one is quick:
<anastasiamac_> thumper: for "the" reviewer or "a" reviewer?
<wallyworld> sure, that's what you always say
<thumper> wallyworld: helps out sinzui and abentley re bug https://bugs.launchpad.net/juju-core/+bug/1421237
<mup> Bug #1421237: DEBUG messages show when only INFO was asked for <ci> <security> <juju-core:In Progress by thumper> <https://launchpad.net/bugs/1421237>
<wallyworld> looking
<sinzui> thank you thumper
<thumper> sinzui: np
<lazyPower> New golang dev in #juju, if someone has a moment to stop in and greet them, potential contributor.
<lazyPower> name: hnix
<perrito666> thumper: I would say ship it, but it has little value :p
<thumper> perrito666: heh, but thanks anyway
<katco> perrito666: thumper: same here
<katco> perrito666: maybe collectively our vote adds up to 1?
<thumper> lazyPower: don't suppose that is 'hiro black sun' on google?
<lazyPower> Not sure, is there a correlation i should be aware of?
<thumper> only that someone requested access to a private canonical spec
<thumper> not even sure how they found it existed
<thumper> wallyworld: I have to run to the doctors shortly, if you approve, please attempt to merge
<thumper> wallyworld: and I'll forward port to master
<wallyworld> sure
<thumper> cheers
<wallyworld> thumper: i'm suggesting another test
<wallyworld> i'll add to commet
<thumper> wallyworld: for the default?
<wallyworld> yeah
<thumper> wallyworld: it is there already
<thumper> just not obviously
 * thumper finds it
<wallyworld> convert the new test to a help
<wallyworld> er
<wallyworld> ah ok
<thumper> line 277
<thumper> of the cloutinit_test
<thumper> those tests are horrible
<thumper> and should be rewritten fully
<thumper> I repeatedly want to gouge my own eyes out when I have do change them
<katco> thumper: hey, don't. we need those eyes.
<thumper> ok... really gotta run now, or I'll be late for appt
<wallyworld> thumper: ok, np, i'll +1
<anastasiamac_> wallyworld: standup?
<thumper-afk> sinzui: fix landed in 1.22, forward porting to 1.23
<sinzui> \o/
<jam> wallyworld: quick thing to pass by you. you were part of the "juju status --format=tabular" right ?
<jam> menn0: I sent you an email about my benchmarking script
<jam> well, scale testing script
<jam> I was putting it together for testing out different DB backends, but I think it would fit quite well with what you're trying to do
<jam> we might want to add something like "--debug-log" which makes us much more chatty
<wallyworld> jam: yes, eco floks had a fair bit of input on requirements, katherine did the work
<jam> wallyworld: sure. I just sent an email to juju-dev for what could be a nice improvement.
<jam> Specifically, use number sorted order rather than just string order.
<wallyworld> jam: ah yes, just saw it. the age old problem. yep, we can do that easily.
<jam> If you want, there is "natural sort" which handles mixing numbers inside the string, but just sorting alphabetically except for the unit number by number would be nice.
<wallyworld> i'll get that done next week
<wallyworld> so we make the cut off
<thumper> wallyworld: can we talk about destroy environment?
<wallyworld> sure
<thumper> wallyworld: use our 1:1 hangout
<thumper> night all
<jam> wallyworld: I'm running into problems with LXC stuff. Want me to just file an LP bug, or work on it with you
<wallyworld> jam: what sort of issues?
<jam> lxc is failing to create containers. Let me paste the error
<jam> wallyworld: http://paste.ubuntu.com/10302503/
<jam> I *think* the failure in that garble is:
<jam> Connecting to 10.102.0.39:17070... connected.; HTTP request sent, awaiting
<jam>           response... 500 Internal Server Error; 2015-02-19 05:19:33 ERROR 500: Internal
<jam>           Server Error.;
<jam> given the ports, that looks like something is trying to connect back to the API server, and getting a 500 ISE
<wallyworld> jam: looks like cloud-image-utils is not installed
<wallyworld> there should have been a check for that
<wallyworld> is this local provider?
<jam> wallyworld: ec2
<wallyworld> jam: what version of juju?
<jam> wallyworld: trunk
<wallyworld> precise image?
<jam> wallyworld: pretty sure trusty
<jam> yeah, trusty
<wallyworld> hmmm. let me check, there should have been apt-get cloud-image-utils added to init sctips
<jam> wallyworld: I was trying to do a scale test with containers
<jam> http://paste.ubuntu.com/10302530/
<jam> thats the full status output, which is a bit verbose
<jam> wallyworld: afaict cloud-image-utils is, indeed, not installed on machine-0
<wallyworld> jam: ah, i know. in cloudinit.go, c.AddPackage("cloud-image-utils") is missing
<wallyworld> that caused issues on precise till just recently
<wallyworld> trusty should have been ok; it worked for me
<wallyworld> i guess it depends on the image you get
<wallyworld> for now, you can add that line, and i will do a simple fix
<jam> wallyworld: I'm trying this out on us-wesw-1
<jam> us-west-1 maybe it has an older trusty image?
<wallyworld> could do, yeah, not sure
<jam> wallyworld: want an explicit bug?
<wallyworld> i can raise it
<jam> It feels like we need to understand this a bit more
<wallyworld> the issue is that cloud-image-utils needs to be installed
<wallyworld> otherwise juju can't determine the url to download the image from
<wallyworld> we were installing cloud-image-utils but a packaging bug broke precise
<wallyworld> that upstream deb fix got into cloud archie today i think
<wallyworld> so we can add back the apt install of that package
<jam> wallyworld: damned if you do, damned if you don't sounds like a bad place to be in
<wallyworld> yeah, bt it's all fixed now
<wallyworld> just got to add back the apt install
<wallyworld> i'm surprised it failed on trusty
<wallyworld> trusty onwards should have been ok; well, it has been for me
<wallyworld> we just had to get the deb packaging fixed on precise which has now been done to make precise good too
<jam> wallyworld: i'm trying to reproduce with a simple case
<jam> wow, juju bootstrap took 7m26s
<jam> hmm... this bootstrap seems to have cloud-image-utils available already...
<wallyworld> yeah, go figure
<jam> only thing I can think of is instance size, but that shouldn't affect it IMO
<wallyworld> i don't think so either
<wallyworld> jam: i've raised bug 1423454, it's a one line fix which i'll do now
<mup> Bug #1423454: cloud-image-utils needs to be installed <juju-core:In Progress by wallyworld> <https://launchpad.net/bugs/1423454>
<jam> thanks wallyworld
<jam> wallyworld: poke
<Murali> Hi
<Murali> I need some help in opensatck jujucharms
<Murali> we deployed the openstack-dash board and keystone in one node
<Murali> mysql and rabbtmq in other node
<Murali> but we able to launch the horizon dashboard but couldnt able to login
<Murali> ceadentails are not accepting
<Murali> credentials not accepted
<Murali> we added admin-password : openstack while deploying the keystone
<Murali> could someone help us to come out of this issue??
<Murali> or please redirect to right to conatct
<wallyworld> jam: hi
<wallyworld> jamespage: are you able to point Murali ^^^^^ to someone who can help
<jam> wallyworld: was just prepping if you had anything else for me to bring before mark
<jam> but it got moved to Monday
<wallyworld> ah, np, thanks for asking
<wallyworld> the storage CLI is the ot topic atm
<wallyworld> hot
<jamespage> Murali, hey
<jamespage> Murali, when you say " in one node" how exactly have you done that - not all charms support being placed in the same container
<jamespage> Murali: https://wiki.ubuntu.com/ServerTeam/OpenStackCharms/ProviderColocationSupport
<Murali> Hi Jamespage
<Murali> we are running the MAAS
<Murali> and we have multiple nodes connected
<Murali> in bootstrap node we deployed mysql and rabbitmq
<jamespage> Murali, are you using LXC containers?
<jamespage> (see the doc I referenced above)
<Murali> we are not using LXC containers jamespage
<jamespage> Murali, please do - basically if you deploy keystone and horizon in the same container, one or the other will not function correctly
<Murali> our juju env is MAAS
<jamespage> Murali, you can use LXC and KVM with MAAS
<jamespage> Murali,
<jamespage> juju deploy --to lxc:0 mysql
<jamespage> for example
<jamespage> Juju will create the container and deploy the charm to it
<jamespage> lxc:0 means an LXC container on machine 0
<Murali> ohh ok
<jamespage> Murali, you may find https://jujucharms.com/openstack/ useful as well - that's a 4 node MAAS deployment of openstack using containers where possible
<Murali> will go through this deployment and try thanks jamespage
<Murali> thanks a lot for your kind response
<jamespage> Murali, np
<jamespage> Murali, feel free to ping me or gnuoy with questions if you have them
<jamespage> Murali, better on #juju so we don't distract these busy juju developers :-)
<jamespage> thanks for the ping wallyworld
<Murali> ok wll move #juju
<wallyworld> sure, i wasn't sure who else to ask, thanks for looking
<wallyworld> fwereade: hey, tim made me promise i'd nag you until you looked at his JES document before tomorrow
<fwereade> wallyworld, cheers
<perrito666> morning
<TheMue> perrito666: o/
<dooferlad> TheMue, dimitern: https://nanosheep.org/Publicly-addressable-LXC/
<TheMue> dooferlad: *click*
<dimitern> dooferlad, sweet! thanks - will give it a try later today
<TheMue> dooferlad: cool stuff
<TheMue> dooferlad: just created site?
<dooferlad> TheMue: Yea, I used http://gohugo.io/ because now everything has to be related to go :-D
<TheMue> dooferlad: oh, never heard of it, will take a look here too. I'm not so happy with the software I use for my tideland blog
<dooferlad> TheMue: It basically converts markdown into HTML and applies a theme. After that it is a static site.
 * dooferlad gets lunch
<TheMue> dooferlad: that is fine for me. just seen that Dave is quoted *lol*
<perrito666> oh man, CI still blocked?
<wwitzel3> perrito666: it wasn't just a minute ago when I did a $$merge
<perrito666> oh, ok :p
<perrito666> our topic seems to be really out of sync with that
<wwitzel3> perrito666: yeah, we should make the bot do it
<TheMue> sounds like a good idea, block-sync-bot
<wwitzel3> pretty sure the source for our bot is in LP somewhere and I believe the blocking bugs are exposed via some HTTP resource
<wwitzel3> so assuming my assumptions are correct, should be pretty easy :P
<perrito666> wwitzel3: you are missing the key part, we are extremely lazy
<TheMue> *lol*
<wwitzel3> perrito666: I explictly said "should"
<wwitzel3> perrito666: I didn't say anyone actually would do it
<wwitzel3> haha
<perrito666> we need interns
<wwitzel3> we would just teach them to be lazy
<wwitzel3> vicious cycle
<perrito666> wwitzel3: nah, i usually teach the interns to be useful, they learn the lazy part all by themselves
<perrito666> last time I had training interns (i had to teach them python+django) I got the website for my wedding
<wwitzel3> perrito666: hah, nice
<wwitzel3> ericsnow: ping
<lazyPower> question regarding ssh key exchange during juju ssh - i redeployed a host and now i'm getting ssh-key-exchange errors when trying to juju ssh into that unit - its 100% likely that the host ssh key changed since its a new host - is there an authorized keys file i need to update?
<sinzui> dooferlad, how goes the port of bug 1416928 to master
<mup> Bug #1416928: juju agent using lxcbr0 address as apiaddress instead of juju-br0 breaks agents <api> <lxc> <network> <juju-core:In Progress by dooferlad> <juju-core 1.21:Fix Released by dimitern> <juju-core 1.22:Fix Released by dooferlad> <https://launchpad.net/bugs/1416928>
<dooferlad> sinzui: not long
<sinzui> thank you dooferlad
<perrito666> ericsnow: wwitzel3 ?
<ericsnow> perrito666: perhaps you have not *joined* the hangout <wink>
<ericsnow> perrito666: we are both here
<dooferlad> TheMue, dimitern: http://reviews.vapour.ws/r/960/diff should be familiar :-)
<TheMue> dooferlad: I'll take a look
<dimitern> dooferlad, cheers, looking
<dimitern> dooferlad, LGTM
<dimitern> dooferlad, + a quick test
<dooferlad> dimitern: Yea, I did manual and MAAS tests
<dimitern> dooferlad, cool - all ok then?
<dooferlad> yep
<dooferlad> dimitern: ^^
<dimitern> dooferlad, then $$great$$ :)
<jamespage> dimitern, does juju-br0 hardcode to eth0?
<jamespage> dimitern, helping someone in #juju who does not have ethX naming on their boxes
<jamespage> and the bridge is not wired properly
<dimitern> jamespage, no, it defaults to the "primary" nic
<jamespage> dimitern, ack - the user is using a 1.21.1 release of juju
<dimitern> jamespage, i.e. whatever we can see in lshw xml dump during machine commissioning
<dimitern> jamespage, that might be interesting.. I'll have a look if the fix to pick the "correct" primary nic was already in place in 1.21.1
<perrito666> ericsnow: tx for the review
<ericsnow> perrito666: hope it helps
<TheMue> dimitern: in the client API MachineNetworkInfo returns network.InterfaceInfo. so imho renaming Info to Config makes no sense here, or InterfaceInfo would have to be renamed too
<TheMue> dimitern: just thinking  about it
<dimitern> TheMue, we'll need to straighten those terms across the code base and make them consistent
<TheMue> dimitern: yeah, and here we have multiple possibilities
<dimitern> TheMue, as always :)
<TheMue> dimitern: renaming MachineNetworkInfo to MachineNetworkConfig (or better: add a second and call it) would make it consistent with the server side
<TheMue> dimitern: still it returns InterfaceInfo
<TheMue> dimitern: but this could be a third step ;)
<dimitern> TheMue, some of those API methods will need to either go away or be refactored anyway
<TheMue> dimitern: ok, so I'll start with a simple renaming. server now likes both names.
<alexisb> cmars, team meeting??
<perrito666> cmars: thank you, I was seconds away of being nominated to lead by alexisb
<cmars> perrito666, heh cool. just in time :) distracted by email.. so much of it today
<ericsnow> FYI, I copied out the 2013 and 2014 "agendas" into their own docs (and added links and a TOC to the 2015 doc)
<ericsnow> so the current doc is only 8 pages now
<ericsnow> hope that helps, perrito666 :)
<perrito666> ericsnow: by the time it gets to 40 again I hope Ill have managed to change computers
<perrito666> ericsnow: tx a  lot
<natefinch> ericsnow, wwitzel3: where are you guys on responding to the review comments of GCE?
<ericsnow> natefinch: yep
<natefinch> ericsnow: reread my question :)  Asking how it's going :)
<ericsnow> natefinch: ha, missed "where"
<ericsnow> natefinch: wwitzel3 has done a lot and I'm planning on tackling some today
<perrito666> natefinch: well you did not specify the type of your question, ericsnow just answered got casted to bool
<ericsnow> natefinch: none of them look like show stoppers
<natefinch> ericsnow: cool
<natefinch> perrito666: heh
<natefinch> func WhereAreYouOnGCE() string {}
<natefinch> I guess "yep" still qualifies ;)
<perrito666> troll python programmer is troll
<thumper> ericsnow: ping
<ericsnow> thumper: hey
<thumper> ericsnow: I hear you have some concerns around logging and mongo, wanna chat about it?
<thumper> wwitzel3: you around too?
<ericsnow> thumper: sure
<thumper> menn0: perhaps a logging hangout
 * thumper makes
<thumper> menn0, ericsnow, wwitzel3: https://plus.google.com/hangouts/_/canonical.com/logging
<ericsnow> thumper: wwitzel3 had some specific feedback and more familiarlity with the topic...
<thumper> ericsnow: I had a chat with wwitzel3 the other day
* ChanServ changed the topic of #juju-dev to: https://juju.ubuntu.com | On-call reviewer: see calendar | Open critical bugs:  1423036
<menn0> thumper: sorry I missed that hangout - was at swimming
<menn0> thumper: what did I miss?
<rick_h_> menn0: you've got to fix it all by EOD, that'll teach you to go swimming :)
<menn0> rick_h_: ha
<wallyworld> thumper: did william look atyour doc? i asked him to and he said he would
<thumper> wallyworld: don't know
<thumper> didn't see any comments
<wallyworld> bet he didn't :-)
<wallyworld> sinzui: i think this will work? "apt-get install --target-release precise-updates/cloud-tools cloud-utils" followed by "apt-get install --target-release precise-updates/cloud-tools cloud-image-utils"
<wallyworld> ie 2 individual commands but specifying where the packages are to come from
<wallyworld> axw: hey, can you ping me when you're on?
#juju-dev 2015-02-20
<thumper> wallyworld: I need an extra 10 minutes to kick out the in-laws
<thumper> wallyworld: chat after that?
<wallyworld> sure
<axw> wallyworld: ping
<wallyworld> axw: hey, just talking to tim, see you in standup hangout soon?
<axw> wallyworld: sure, I'll wait in there
<wallyworld> axw: could you take a look at http://reviews.vapour.ws/r/963/ for me?
<axw> looking
<wallyworld> ty
<wallyworld> axw: also, eric raised a point about the rootfs provider - it won't work as written on windows
<axw> wallyworld: yeah, storage in general is not expected to work on windows in the first iteration AFAIK
<axw> we will need to disable it in tests if they're going to break
<wallyworld> good yes, i couldn't quite recall if we agreed to that or not
<wallyworld> tests shouldn;t break as it's all stubbed out
<axw> 99% sure that Mark agreed to that
<wallyworld> yes i do recall that now
* ChanServ changed the topic of #juju-dev to: https://juju.ubuntu.com | On-call reviewer: see calendar | Open critical bugs:  1423036 1423782
<axw> wallyworld: reviewed
<wallyworld> ty
<axw> wallyworld: I don't think the error is to do with arch mismatch... I created an env on AWS and it's missing the tools symlink for the container
<wallyworld> axw: hmmm. that doesn't make sense based on the code
<wallyworld> the symlink might be missing
<axw> wallyworld: the container was started with the correct arch.
<wallyworld> but the tools selection si broken
<axw> wallyworld: where?
<wallyworld> yes, the container image itself will be correct
<wallyworld> in provisioner_task
<wallyworld> possibleTools, err := task.toolsFinder.FindTools(
<wallyworld> this used to use the HasTools interface implemented by the container provisioner to lok h tols
<wallyworld> lock the tools
<axw> HasTools was a hack. what's there will work if the constraints has the correct arch... which seems to be the case since it's picking the right arch
<wallyworld> but the constraints won't always have the correct arch
<wallyworld> they may be empty
<axw> wallyworld: perhaps there's two bugs, I'll keep looking
<wallyworld> axw: the constraints will be empty if you just bootstrap with nothing else
<wallyworld> then the new machine 1 will have m.Constraints() without an Arch
<axw> wallyworld: I thought Juju might add the host machine's arch as a constraint for LXC, doesn't look like it does tho
<wallyworld> yeah
<wallyworld> that's the issue I think
<wallyworld> and the HasTools thing hacked around that
<axw> wallyworld: sorry I got confused, thinking tools would be in the same location as the host, like in local
<wallyworld> ah right
<axw> just the one bug
<axw> wallyworld: so... rather than reinstating HasTools, I'd prefer to just set Constraints.Arch to the host's if it's not already set. IIRC there was a bug caused by HasTools, where you couldn't create, say, i386 containers on amd64 hosts
<axw> which is why it was removed in the first place
<wallyworld> that solution of setting Arch was what occurred to me also - but only for containers
<axw> wallyworld: actually... I think the LXC provisioner should just filter by the host arch. that's what we'd do for any other provider right?
<axw> give it all it we know about, and let it make the informed decision
<wallyworld> that would work, yeah
<wallyworld> i think setting the arch seemed ok because it would constraint the search
<wallyworld> but it's cleaner for sure to ket the provisioner decide
<axw> wallyworld: http://reviews.vapour.ws/r/965/
<wallyworld> looking
<wallyworld> axw: I've updated the apt review from before also
<axw> wallyworld: already LGTMd
<wallyworld> ah ty :-)
<wallyworld> axw: there's also a names one https://github.com/juju/names/pull/41 and one eric looked at but which i'd like your review of pretyy please
<axw> will do
<wallyworld> axw: done with a suggestio
<wallyworld> n
<axw> ta
<wallyworld> axw: the filesystem tag uses the datasource name as the tag id (seemed reasonable at the time). the broad definition was to accommodate the behaviour where the datasource name is used as the dir name if no location is specified. I did think about using a numeric sequence value but then there's the issue of how to generate the numbers. i'd have to use a mongo sequence or something, or just count the number of filesystem docs
<wallyworld> i can change to number though
<axw> wallyworld: datasource name?
<axw> as in ... the pool name?
<wallyworld> in the charm metadata
<wallyworld> storage name
<axw> wallyworld: I'm a little wary of that. volumes can be disassociated from a storage instance, it may end up being a requirement for filesystems too
<wallyworld> yeah, fair enough. i can make it like volume will be once your current branch lands (I didn't see it when I did this so didn;t appreciate the machine name aspect)
<wallyworld> i do prefer opaque identifiers
<anastasiamac_> wallyworld:
<wallyworld> yo
<anastasiamac_> wallyworld: looks like u've quit on PM
<wallyworld> sigh, stupid irc
<wallyworld> i'm here
<wallyworld> got to go get kid from train station in a few minutes
<wallyworld> axw: i've updated the juju/names branch to make fs tag more like volume tag
<axw> wallyworld: thanks, will take a look
<axw> wallyworld: LGTM
<wallyworld> axw: ty. btw, what did you think about eric's comment re: Path vs Location?
<axw> wallyworld: Path sounds fine for FilesystemAttachment. It really only needs to be Location on the StorageAttachment, which normalises volume/filesystem
<wallyworld> sounds good to me
<wallyworld> i sometime use location in conversation but path is better
<TheMue> morning
<dimitern> o/
<dooferlad> morning
<TheMue> dooferlad: o/
<dimitern> TheMue, dooferlad, o/
 * dimitern bbiab
<dimitern> TheMue, dooferlad omw - ~3m
<mattyw> fwereade, do you have 10 minutes?
<dimitern> TheMue, reviewed
<TheMue> dimitern: thx
<TheMue> dimitern: and regarding the reviewer please take a look at the calendar. today michael and william are (ok, michael isn't available)
<TheMue> dimitern: I for example have been last Friday and will be next Friday again
<dimitern> TheMue, ah! yeah - I was thinking about last friday
<dimitern> :)
<dimitern> TheMue, but james is today
<TheMue> dimitern: yep, our new ocr
<TheMue> dimitern: btw, you've got a review too ;)
<dimitern> TheMue, thanks you your review
<TheMue> dimitern: h5
 * dimitern h5s :)
<TheMue> dimitern: thanks for the name retry pattern hint, this is exactly what I've looked for
<dimitern> TheMue, yw, I had to look for it too, so decided to save you the trouble heh
<TheMue> dimitern: great :)
<dimitern> dooferlad, OCR PTAL: http://reviews.vapour.ws/r/961/
<dimitern> (as you might see sometimes)
<dooferlad> dimitern: looking
<dimitern> dooferlad, ta!
<dimitern> mgz, hey, are you around?
<dimitern> dooferlad, hey, thanks for the review - I've responded. Is this the only question you have, everything else is clear? :)
<dooferlad> dimitern: yep, everything else is fine.
<dimitern> dooferlad, awesome!
<dimitern> dooferlad, the state code is one of the gnarliest places btw - beware
<dooferlad> dimitern: Heh, it did look a bit... interesting.
<dooferlad> dimitern: not too scary though!
 * dooferlad goes for lunch
<dimitern> dooferlad, ;)
<perrito666> natefinch: around?
<jw4> sinzui: can I JFDI a backout merge?
<jw4> it's actually one of the suspects in blocking bug 1423782 (but I don't think it's the culprit in that case)
<mup> Bug #1423782: ppc64el /usr/bin/ld: error in $WORK/github.com/juju/juju/cmd/juju/_obj/exe/a.out <ci> <gccgo> <ppc64el> <regression> <test-failure> <juju-core:Triaged> <https://launchpad.net/bugs/1423782>
<sinzui> jw4 fixes-1423782 is what the lander is looking for. Use __JFDI__ when it is clear something has to merge to unblok other proitities
<jw4> sinzui: okay; I don't think this backout does fix that though
<jw4> sinzui: I just noticed it was referenced in the bug
<jw4> sinzui: I think in this case it is blocking other priorities... i.e. removing a wrong implementation to make way for the right one?
<sinzui> jw4, agreed, __JFDI__
<jw4> sinzui: ta
<stokachu> does anyone know what this error means: WARNING juju.replicaset replicaset.go:87 Initiate: fetching replication status failed: cannot get replica set status: can\'t get local.system.replset config from self or any seed (EMPTYCONFIG)
<aisrael> I seem to be running into a new (to me) issue in trunk. I have a service in an error state, but `juju resolved` doesn't see it being in an error state.
<aisrael> http://pastebin.ubuntu.com/10325205/
<perrito666> stokachu: your mong rs.config() is empty, there was most likely an error while creating the base replicaset
<stokachu> perrito666: so this happens randomly, whereas if i re-run the bootstrap it works the second time around
<stokachu> just prior to that error the logs shows several mongo connection failures due to connection refused but then the connection succeeds and thats when the above error is shown
<stokachu> this only happens when I bootstrap a bare metal from maas
<perrito666> stokachu: sounds to me that I already heard this story, I believe there is even a bug about it, if not perhaps there should be
<marcoceppi> is there any way to tell if trunk is blocked?
<jw4> marcoceppi: I use https://api.launchpad.net/devel/juju-core?ws.op=searchTasks&status%3Alist=Triaged&status%3Alist=In+Progress&status%3Alist=Fix+Committed&importance%3Alist=Critical&tags%3Alist=regression&tags%3Alist=ci&tags_combinator=All
 * marcoceppi registers isjujucoreblocked.com
<jw4> marcoceppi: if you do that then use the official blocker check script... I'll find that for you after my stand up
<marcoceppi> jw4: I found it in juju-ci-tools
<marcoceppi> http://bazaar.launchpad.net/~juju-qa/juju-ci-tools/trunk/view/head:/check_blockers.py
<jw4> yep
<marcoceppi> sweet
<ericsnow> marcoceppi: I just go here: https://bugs.launchpad.net/juju-core/+bugs?field.searchtext=&orderby=-importance&field.status%3Alist=NEW&field.status%3Alist=CONFIRMED&field.status%3Alist=TRIAGED&field.status%3Alist=INPROGRESS&field.status%3Alist=FIXCOMMITTED&field.status%3Alist=INCOMPLETE_WITH_RESPONSE&field.status%3Alist=INCOMPLETE_WITHOUT_RESPONSE&field.importance%3Alist=CRITICAL&field.tag=ci+regression+&field.tags_combinator=ALL
<dimitern> sinzui, I think we should try reverting https://github.com/juju/juju/commit/0621a1ad40ba15004ef6c3c5e4da22661243041f - since ppc64el tests started failing after it, and the other suspect commit jw4 already reverted
<sinzui> dimitern, I am just reviewing 1.22 results to verify the linker issue isn't present in 1.22
<dimitern> sinzui, sure
<dimitern> sinzui, I spend the last hour looking at various bugs for gccgo-ppc64 - in the gcc bug tracker, in lp, etc. as it does seem like a compiler issue
<sinzui> dimitern, no gcc/linker errors in 1.22, so I am sure the machine is good. Revert
<dimitern> sinzui, cool, I'll propose it then
<dimitern> sinzui, reverted and it's already getting tested - http://juju-ci.vapour.ws:8080/job/github-merge-juju/2210/console
<dimitern> sinzui, provided it lands ok, can you trigger the ppc64 job manually to see if it worked and save time?
<sinzui> dimitern, I cannot trigger manually.
<sinzui> dimitern, I think wallyworld's fix for ppc lxc has bad tests: http://juju-ci.vapour.ws:8080/job/run-unit-tests-trusty-ppc64el/2398/consoleText
<sinzui> ^ mgz, do you agree? I think we have another regression in 1.22, but one that is just a test
<dimitern> sinzui, looking
<mgz> sinzui: yup, failed across 3+ runs
<mgz> looks like it'll be trivial to fix though
<mgz> yeah, the startInstance helper on that test class just hardcodes some pretend tools and quantal-amd64
<mgz> *as
<dimitern> mgz, sinzui, actually the tests are bad, because with axw's patch all tests now take the current machine's arch
<dimitern> i.e. tests need better isolation
<sinzui> mgz, dimitern natefinch : I just reported bug 1423950 about the ppc64 test failures just added to 1.22
<mup> Bug #1423950: lxc-broker_test tests fail on ppc64el <ci> <ppc64el> <regression> <test-failure> <juju-core:Triaged> <juju-core 1.22:Triaged> <https://launchpad.net/bugs/1423950>
<mgz> worker/provisioner/lxc-broker_test.go l96
<mgz> either that also needs to take current arch or the test needs to mock/isolate the tool selection
<dimitern> mgz, the latter is better I think
<dimitern> sinzui, I commented on that bug, however I don't think 1.23 is affected as there's not such patch there
<sinzui> dimitern, good point. But note that 1.23 wasn't affected by the precise bug until someone ported it there. We need to stop the ppc fix from being ported without this fix also being present
<dimitern> sinzui, I agree and will add another comment for this
<sinzui> dimitern, I removed 1.23
<sinzui> dimitern, I don't see a pr/review of a port of the ppc fix, so I wont worry
<dimitern> sinzui, cheers - I've commented on both bugs - 1420049 and 1423950
<sinzui> dimitern, mgz: I think I want to cry: the joyent trusty deploy is failing. the units cannot contact the state server to download the agent
<sinzui> + printf Attempt 5 to download tools from %s...\n https://10.112.3.32:17070/tools/1.22-beta4-trusty-amd64
<sinzui> I can only think to try the test again to get a friendly network
<mgz> urk
<dimitern> sinzui, aw, that's the "i'll give you a machine on a random network" type of joyent issue
<sinzui> dimitern, exactly. we broadened the network we will accept, but joyent went broader
<sinzui> dimitern, I can see in recent days, 1 in 4 attempts pass (but different branches). I will try again for a 4th attempt in the sequence
<dimitern> sinzui, that's not a real solution, but if it makes the job pass more often, yeah
<dimitern> unfortunately the "real" solution is not something joyent seems to support via their api
<sinzui> dimitern, this isn't a juju regression, and I want to show there isn't one looking at the repeatability
<dimitern> sinzui, I agree
<sinzui> dimitern, joyent deploy precise passed the first time (with the new fix), quickstart passed for the last two revisions, and that test is pretty unreliable, and the upgrade trusty also passed. so I am sure juju is good
<dimitern> sinzui, the revert of #1615 landed - can you give me an eta when the ppc64 tests job will run?
<dimitern> sinzui, that's good news indeed
<sinzui> dimitern, with the hour. we are waiting for 1.22 to conclude
<dimitern> sinzui, ok, thanks
<sinzui> dimitern, and we get a pass for the statistically consistent 1 in 4 will get a good network
<sinzui> dimitern, natefinch : can you ask someone to fix the broken tests for bug 1423950?
<mup> Bug #1423950: lxc-broker_test tests fail on ppc64el <ci> <ppc64el> <regression> <test-failure> <juju-core 1.22:Triaged> <https://launchpad.net/bugs/1423950>
<dimitern> sinzui, sure
<marcoceppi> jw4 ericsnow: http://juju.fail/status.json ;)
<wwitzel3> hah I was right
<dimitern> sinzui, it seems the ppc64-slave is free - how does it decide to try a new master commit?
<aisrael> I'm running into an issue w/trunk. I have a service in an error state, but `juju resolved` reports it isn't in an error state. Seems like this change happened within the past week.
<sinzui> dimitern, when all tests for a revision have run, a new revision will be tested. we are waiting on maas
<aisrael> http://pastebin.ubuntu.com/10325205/
<dimitern> sinzui, I see, ok
 * dimitern steps out for a bit
<natefinch> dimitern, sinzui:  Sorry, was out this morning.  I can take a look at that bug, if you want?
<sinzui> natefinch, thank you
<perrito666> is there a way to run the whole test suite supressing logs? I just want to know which packages fail
<dooferlad> sinzui: https://github.com/juju/juju/pull/1645 should fix Bug #1423950 but needs a review
<mup> Bug #1423950: lxc-broker_test tests fail on ppc64el <ci> <ppc64el> <regression> <test-failure> <juju-core 1.22:In Progress by dooferlad> <https://launchpad.net/bugs/1423950>
<dooferlad> TheMue: Could you take a look? ^^
<sinzui> natefinch, ^
<TheMue> dooferlad: yep, will do
<TheMue> dooferlad: looks simple and ok, sadly don't know how to test it better than let it do by CI
<dooferlad> TheMue: indeed.
<TheMue> dooferlad: so I'll give it a ship-it
<dooferlad> TheMue: shipped!
<TheMue> dooferlad: :)
<dimitern> perrito666, there is
<dimitern> perrito666, I found out yesterday - export TEST_LOGGING_CONFIG=CRITICAL or something then run them; however some of them fail when the <root> logger is not at least at DEBUG
<perrito666> dimitern: tx
<dimitern> dooferlad, re that fix
<dooferlad> dimitern: yep
<dimitern> dooferlad, I think you should restore this change at some point - i.e. in the suite's TearDownTest
<dooferlad> can do
<dimitern> dooferlad, back to what version.Current.Arch was; otherwise other tests can fail
<dimitern> dooferlad, have you run make check?
<dooferlad> dimitern: yes
<dimitern> dooferlad, well if it passes, that's good news - nothing apparently broken, but I still think it should be restored - maybe in a follow-up?
<dimitern> dooferlad, also, instead of "amd64" I'd use the arch.AMD64 const
<dooferlad> dimitern: just testing restoring it in func (s *lxcProvisionerSuite) TearDownTest(c *gc.C)
<dooferlad> dimitern: OK, will change that.
<dimitern> dooferlad,despite that, great job for doing it so quickly! :)
<dimitern> dooferlad, cheers
<natefinch> dooferlad: agreed, great job
<dooferlad> dimitern, natefinch: thanks!
<dooferlad> dimitern: can the followup wait until Monday. It felt urgent to get a fix in, but I would like to finish promptly today.
<dooferlad> dimitern: (insert ? where needed in above)
<dimitern> sinzui, most jobs have disappeared from jenkins, which I presume is due to not being publicly visible; anyway any update on the ppc64 job?
<sinzui> dimitern, I sure can
<dimitern> dooferlad, it can wait, but please add a card and comment on the bug about it
<dooferlad> dimitern: cool. It isn't writing the code, it is waiting for the tests to run :-) I will leave it going and see if I can get checked in later.
<dimitern> dooferlad, you can then integrate axw's fix and yours + the follow up to port that fix to trunk
<dimitern> dooferlad, sure, np
<sinzui> dimitern, I is visible now
<dimitern> sinzui, I can see it - thanks
<sinzui> dimitern, We are using 10.0.40.x addresses in network we test mass kvm with.
<sinzui> dimitern, do we need to change that to avoid the lxcbr0 issue?
<dimitern> sinzui, the one I fixed recently?
<dimitern> (too many lxcbr0 issues in the past 2 months :/)
<sinzui> dimitern, yes, we aren;t using lxcbr0, but we are using that address range on an eth1
<sinzui> we can change the range
<dimitern> sinzui, the issue was that 10.0.3.* sorts before any 10.0.X.* where X > 3
<dimitern> sinzui, so if you're hitting that issue I'd suggest changing the range to 10.0.2.*
<dimitern> sinzui, what juju version is the ci environment using?
<marcoceppi> alexisb: aisrael and I are seeing a weird issue in trunk. We'd like to debug to see if it's a bug or not, anyone we can chat with?
<sinzui> dimitern, thank you. I think this means our address sis okay
<sinzui> juju.api api.go:273 connecting to API addresses: [10.0.80.120:17070]
<dimitern> sinzui,ah, now I got it - your lxcbr0 address is from 10.0.40.x ? yep, then it's fine
<alexisb> marcoceppi, any of the use based developers
<marcoceppi> natefinch: halp
<alexisb> natefinch, wwitzel3, cherylj, katco, ericsnow_afk
<natefinch> marcoceppi: heh
<marcoceppi> aisrael: ^
<natefinch> whazzup?
<marcoceppi> natefinch: "I seem to be running into a new (to me) issue in trunk. I have a service in an error state, but `juju resolved` doesn't see it being in an error state. http://pastebin.ubuntu.com/10325205/"
<natefinch> marcoceppi: wacky
<marcoceppi> natefinch: yeah, aisrael is experiencing it atm
<marcoceppi> with trunk from this am
<natefinch> marcoceppi: I'll do some poking around and see if I can repro
<marcoceppi> natefinch: ta
<dimitern> I'd appreciate a review on http://reviews.vapour.ws/r/973/
<TheMue> dimitern: already started ;)
<dimitern> TheMue, cheers!
<dimitern> TheMue, it's a long diff, but it should be easy to follow
<TheMue> dimitern: so far yes, otherwise I'll ping you here
<dimitern> ta!
<jw4> marcoceppi: cool!
<mbruzek> ping jog
<jog> hi mbruzek
<mbruzek> I can't get to http://reports.vapour.ws/charm-summary/kubernetes
<mbruzek> Is it just me or is that page down?
<jog> mbruzek, please use http://reports.vapour.ws/charm-tests-by-charm/kubernetes
<jog> mbruzek, I update the site this morning
<jog> mbruzek, the change was to merge the old charm reporting page with that we've recently been working on.
<mbruzek> OK
<TheMue> dimitern: you've got a review. really like this PR
<dimitern> TheMue, thank you! It *did* a week to get this good :)
<TheMue> dimitern: was worth it
<dimitern> TheMue, indeed!
<TheMue> dimitern: I'll now give my PR another merge kick and then enjoy my Glenrothes Single Malt :D
<dimitern> TheMue, trunk is still blocked though
<dimitern> TheMue, otherwise, enjoy! :)
<TheMue> dimitern: oh, ok, then I'll do it tomorrow and now only enjoy *hicks*
 * TheMue wishes the channel a nice weekend
<whit> mbruzek, https://raw.githubusercontent.com/whitmo/bundle-kubernetes/master/specs/cs-latest-release-v0.9.3.yaml
<mbruzek> jog I think pointing to the actual file in s3 would be better.
<whit> jog, ie grabbing the file when the tests run and sticking it in s3 to refer to later
<whit> tvansteenburgh mentioned doing this before
<whit> jog, when the bundle is in source control, there is no guarantee that the file you link to is actually the file from the test run
<jog> whit, agreed I'll like to what we archive in S3
<tvansteenburgh> jog, whit: i'm not uploading the bundle file to s3 yet but i'll try to get that done this afternoon
<whit> tvansteenburgh, thanks!
<natefinch> perrito666: you have a shipit
<perrito666> natefinch: you have $drink on my tab
 * perrito666 cries
<jog> mbruzek, whit, arosales, removing kubernetes test data older than Feb. 18, is A-OK with everyone?
<whit> jog +1
<mbruzek> jog that is my understanding yes
<arosales> jog, yes please do
<arosales> aisrael, did you get the help you were looking for on your development
<aisrael> arosales: natefinch was going to see if he could reproduce it; I rolled back to binaries from the end of Jan to get unblocked in the meantime
<arosales> natefinch, thanks for the help there, getting that moving forward will help us in our charm action development
<arosales> aisrael, if we don't have a resolution today lets open a bug so we can bring other folks in if necessary
<aisrael> arosales: ack
<arosales> aisrael, thanks
<natefinch> arosales, marcoceppi, aisrael: the good news is that I can reproduce it, so now it's just a matter of figuring out what's wrong, which I imagine will be pretty obvious.  Probably won't be able to entirely track it down before EOD, but most likely by early Monday.... either way, filing a bug would be appreciated
<marcoceppi> natefinch: thanks, are we excercising that mechanism in testing?
<jw4> natefinch, is this the error state bug that marcoceppi pastebinned earlier?
<natefinch> jw4: yes
<jw4> are you able to reproduce with the latest in master?
<aisrael> natefinch: ack, I'll file a bug report shortly
<natefinch> marcoceppi: probably?  I'll have to look at the tests.  But obviously there's a codepath that is not being tested.
<jw4> (I'm just afraid that it might incidentally touch a PR that I just reverted this morining)
<natefinch> jw4: tested it with latest master as of half hour ago-ish
<jw4> natefinch: whew (for me)
<arosales> natefinch, thanks
<aisrael> https://bugs.launchpad.net/juju-core/+bug/1424069
<mup> Bug #1424069: juju resolve doesn't recognize error state <juju-core:New> <https://launchpad.net/bugs/1424069>
<alexisb> perrito666, ping
<alexisb> if you are still around :)
<perrito666> alexisb: barely
<perrito666> tell me
 * perrito666 braces
<alexisb> perrito666, yeah I always come in with fun requests
<alexisb> perrito666, I need a volunteer to work with eco team on a windows workload demo
<alexisb> eco will be leading but we need a core dude to help if questions come up
<perrito666> I am interested
<perrito666> how urgent is this
<mbruzek> alexisb: windows?  What is that
<alexisb> well we have one week to get a working demo
<alexisb> but I want to get all the techie names lined up today so I can get the effort organized
<alexisb> mbruzek, it is for david duffey, just coming down the pipeline
<alexisb> perrito666, no need for work until monday, but I do want to get everyone identified that will be enlisted to help
<alexisb> and from the core front it should be mostly helping with questions and orchestrating getting gsamfira and team involved if needed
<alexisb> perrito666, you have been working closely with cloudbase so you are my first ask :)
<perrito666> alexisb: sure, whatever I dont know I will most likely know who to ask
<alexisb> perrito666, cool
 * alexisb goes to send email and get the ball rolling
<perrito666> Ill try to run the whole tutorial they sent to get a working workload at home for reference
<perrito666> well after not dodging that bullet I am EOW, see you all on monday
<perrito666> :p
<jw4> perrito666: o/
<alexisb> by perrito666 and thanks!
#juju-dev 2015-02-22
<waigani> thumper: http://reviews.vapour.ws/r/928/, thanks
#juju-dev 2016-02-22
<menn0> thumper: looking now
<menn0> thumper: ship it with some small fixes
<mup> Bug #1538241 changed: 2.0-beta1 stabilization <blocker> <juju-core:Invalid> <https://launchpad.net/bugs/1538241>
<mup> Bug #1538241 opened: 2.0-beta1 stabilization <blocker> <juju-core:Invalid> <https://launchpad.net/bugs/1538241>
<mup> Bug #1538241 changed: 2.0-beta1 stabilization <blocker> <juju-core:Invalid> <https://launchpad.net/bugs/1538241>
<thumper> menn0: ta
<axw> rick_h_: I'll test azure and see what's up
<rick_h_> axw: ok, there's some general "stuff left behind" i get every once in a while with kill-controller. I'm not sure if this is part of that or just how much is meant to get cleaned up.
<rick_h_> axw: ty for following up
<axw> rick_h_: you should expect there to be nothing at all left behind
<axw> rick_h_: everything is scoped by the resource group, each model gets a resource group
<rick_h_> axw: going to see if we can get a GSoC student to help automate that process of pulling the info for the credentials. Wow that's painful.
<axw> rick_h_: the azure creds?
<rick_h_> axw: ok, yea that's what I assumed, but I need to look more at what you create with the azure cli process vs resource group vs model
<rick_h_> axw: working through the whole nodejs cli to create the AD entries and such
<axw> rick_h_: sounds good. yes, very painful. amazingly, it's actually much better than when I started working on the provider :)
<rick_h_> ugh
 * rick_h_ can't imagine
<rick_h_> the fact that I have to install nodejs makes me cry much less the multi-step "run this command with this UUID, and this one with this UUID...and..."
<axw> rick_h_: I had envisaged a CLI tool to automate all the nodejs scripty bits
 * axw nods vigorously
<rick_h_> axw: right, it must be something that we can even build into juju/Go based on using the same api in the same way
<rick_h_> start out as a plugin and see how far we can get
<axw> sounds good
<axw> rick_h_: FWIW, MS have acknowledged that it sucks. I'm not sure what they're doing about it though.
<rick_h_> axw: yea, well I got pulled into a "juju sucks on AWS" meeting with our folks that work with them
<rick_h_> and I promised it'd get all better with the new ARM...and now I'm not so sure heh
<axw> the creds bit is worse, I think the rest is much better
<rick_h_> definitely
<rick_h_> hopefully just a scripting headache to hide from users
<thumper> hmm...
<thumper> we have this thing called annotations
<thumper> and it can be set on "anything"
<thumper> but in practice, it seems like it is only ever stored on services
<thumper> anyone know of other places it is used?
<anastasiamac> thumper: not on anything...
<anastasiamac> thum
<anastasiamac> thumper: on "gloab entities"... essentially, anything that has a global key and  a tag
<anastasiamac> thumper: machines, units, services, charms, models
<thumper> well... sure
<thumper> but in practice, I think it is just services
<anastasiamac> thumper: juju itself may not use all of these but clients might.. i believe GUI is a prime example
<thumper> yeah
 * thumper goes for the JFDI everything card
<anastasiamac> thumper: it would b lovely to know how customers are using Juju (as in feature-focused customer feedback)
<axw> rick_h_: I can't reproduce leftovers after kill-controller
 * anastasiamac dreaming 
<axw> rick_h_: sure they weren't there before you bootstrapped? can you delete manually and see if it happens again?
<rick_h_> axw: will see. I gave my creds to mark to try out so have to check if he's using it first
<rick_h_> axw: did you deploy anything into it?
<axw> rick_h_: no rush I guess. I think CI will notice if junk gets left behind
<axw> rick_h_: nope. did you?
<rick_h_> axw: yes, jenkins/haproxy, related them, exposed haproxy to get the public IP addr
<rick_h_> axw: hmm, maybe I was impatient, I don't see the resource group in the portal at all now
<axw> rick_h_: deleting resource groups is super duper slow
<rick_h_> axw: I might have caught it with no machines/etc but with the IP/availability set left or something
<rick_h_> axw: hmm, ok. I'll try again and see and report back
<rick_h_> axw: ty for attempting to reproduce
<axw> thanks, no worries
<menn0> thumper: here's the State reference counter: http://reviews.vapour.ws/r/3921/
<menn0> axw: ping
<axw> menn0: pong
<menn0> axw: I noticed something strange in master
 * menn0 digs out some links
<menn0> axw: https://github.com/juju/juju/blob/master/cmd/jujud/agent/machine.go#L1062-L1074
<menn0> axw: in master the stateworker has some logic to call unregisterSimplestreamsDataSource when the *state.State is closed (when the worker terminates)
<menn0> axw: but the related code to NewStorage and registerSimplestreamsDataSource is no longer present
<menn0> axw: openStateForUpgrade still has it though
<menn0> axw: and it's in the 1.25 branch
<menn0> axw: do you think this is an unintended deletion? or are the calls to NewStorage and registerSimplestreamsDataSource no longer required any more?
<axw> menn0: not actually sure. anastasiamac, ideas on above? ^^  I think this is related to the structured metadata changes
 * axw pokes around code
<anastasiamac> axw: m not sure why it was removed? an overzealous merge maybe?
<rick_h_> axw: wow, 6min at "All hosted models reclaimed, cleaning up controller machines
<rick_h_> and counting
<axw> rick_h_: heh, yeah :/
<axw> rick_h_: that's the cost of being 100% sure we're not leaking resources on azure, sadly
 * menn0 digs into the history a bit
<rick_h_> axw: but yes, all things look gone this time
<rick_h_> axw: so I'll chalk it up to impatience last time ty
<axw> rick_h_: cool, thanks for confirming
<anastasiamac> menn0: eyes of the eagle \o/
<anastasiamac> *an
<menn0> anastasiamac: well I'm completely changing how the state worker starts so I need to understand how this works :)
<axw> menn0: I *think* we don't need it anymore, because we asynchronously populate the state db with metadata, and then return those results to StartInstanceParams. anastasiamac, you did that work... does that sound right?
<axw> anastasiamac: that wasn't done for 1.25 was it? which would explain why it's different in the 1.25 branch?
<anastasiamac> axw: m not remembering it being asynch.... but i *hope* that it was in 1.25 rathern than not...
<menn0> anastasiamac, axw : except what's in master looks wrong... like someone half completed a change or messed up a merge
<axw> anastasiamac: asynchronous, as in we have an image metadata worker.
<menn0> 1.25 looks sensible
<axw> menn0: right, the unregister certainly shouldn't be there if we don't need to register it anymore. still looking..
<axw> menn0:  removed by wallyworld in https://github.com/juju/juju/commit/66a6121c6598b2de7d8ac3acec7afbeccdcd958a
<axw> wallyworld: do you recall why this change was made? https://github.com/juju/juju/commit/66a6121c6598b2de7d8ac3acec7afbeccdcd958a#diff-f5ec9ed405cc8f3a833355afdc629bd3L1110
<wallyworld> axw: otp, give me a few minutes
<menn0> axw, anastasiamac: thanks for the thinking and digging so far.
<anastasiamac> menn0: axw:wallyworld so the review for it http://reviews.vapour.ws/r/3459/
<anastasiamac> has comment
<wallyworld> still in meeting sorry
<anastasiamac> to my question of "why is this removed/no longer needed"
<anastasiamac> the response is
<anastasiamac> We only use simplestreams datasources are first searching in state database. Why add state database as a simplestreams datasource? What ends up happening is we search twice in the same location. And the logs show the search the second time errors anyway, so it's doublely evil.
<anastasiamac> .... as a consequence, the registration was removed (registerSimplestreamsDataSource)
<axw> so we just need to remove the unregister call
<anastasiamac> looks like \o/
<menn0> anastasiamac: ok, so that means that the openStateForUpgrade should be similarly updated too
<menn0> I might JFDI that into master now
<menn0> actually no, i'll do it in my feature branch
<menn0> it's relevant to the changes there and is almost done
<anastasiamac> menn0: i think so :D...
<anastasiamac> axw: the call to unregsiter is not doing anything, i think... removing it would be clean \o/
<wallyworld> axw: menn0: i think that change was because we were using the stream setting for tools to filter image metadata
<menn0> wallyworld, anastasiamac: http://reviews.vapour.ws/r/3922/
<wallyworld> looking
<wallyworld> menn0: awesome, ty
<axw> wallyworld: a handful of juju/api.go-related changes, when you have a moment: https://github.com/juju/juju/pull/4490
 * axw bbl
<marcoceppi> halp
<voidspace> frobware: you want to do 1:1?
<frobware> voidspace: yep
<voidspace> frobware: I'd like coffee first ~5mins?
<frobware> voidspace: ok
<voidspace> frobware: omw
<voidspace> frobware: uhm... I joined the wrong room. Really on my way now...
<perrito666> morning all
<frobware> dooferlad, dimitern, voidspace: http://reviews.vapour.ws/r/3914/ the very small master->maas-spaces2 merge we talked about this morning
<dimitern> frobware, why not bring in the latest master instead?
<frobware> dimitern: can do. I thought we said this morning we would just do this and then the next...
<frobware> dimitern: happy to drop and go for the bigger change.
<frobware> dimitern: btw, do you have a link to your PR from this morning?
<frobware> dimitern: if it doesn't turn up in RB my experience is that RB does not like much markdown formatting. Remove all that and it will probably turn up. This is why I have a bunch of discarded reviews - It took me a while to realise that it was the commit message formatting that was "objectionable".
<dimitern> frobware, I think it's better to keep tracking the latest master - i'll deal with merging stuff once my PRs are approved
<dimitern> frobware, here it is: https://github.com/juju/juju/pull/4481
<frobware> dimitern: <wild-speculation> looking at that I'm sure the bullet lists are "objectionable" for RB
<dimitern> frobware, I added those later; I suspect the issue is with PRs that have only first line but no description, so the RB bot fails to add the link to the description
<frobware> dimitern: I had problems where I had 4 spaces instead of 2 at the beginning of a line
<dimitern> weird..
 * dimitern will be back in about 1h
<mup> Bug #1548333 opened: 2.0 bootstrap error messages and help are not helpful <juju-core:New> <https://launchpad.net/bugs/1548333>
<mup> Bug #1548333 changed: 2.0 bootstrap error messages and help are not helpful <juju-core:New> <https://launchpad.net/bugs/1548333>
<mup> Bug #1548333 opened: 2.0 bootstrap error messages and help are not helpful <juju-core:New> <https://launchpad.net/bugs/1548333>
<mup> Bug #1548333 changed: 2.0 bootstrap error messages and help are not helpful <juju-core:New> <https://launchpad.net/bugs/1548333>
<mup> Bug #1548333 opened: 2.0 bootstrap error messages and help are not helpful <juju-core:New> <https://launchpad.net/bugs/1548333>
<natefinch> morning ericsnow
<ericsnow> natefinch: hey
<natefinch> ericsnow: almost got the uniter stuff in over the weekend, but adding a resource to the wordpress testcharm caused a lot of failures in tests that use that charm but didn't register resources :/
<ericsnow> natefinch: nice (and not so nice)
<natefinch> ericsnow: yeah, and trying to register resources caused import cycles.... so now I'm just changing all of the uniter tests to hardcode starsay rather than wordpress (after making starsay a duplicate of wordpress, with some resources added).
<ericsnow> natefinch: yeah, I ran into those same import cycles (remember the last time I was complaining about internal tests)
<natefinch> ericsnow: heh
<natefinch> ericsnow: yeah
<natefinch> ericsnow: (lack of) import cycles *are* a benefit of external tests :)
<ericsnow> natefinch: our future selves always thank us :)
<ericsnow> natefinch: anyway, I too ended up going a different route to avoid the circular imports, rather than fixing them (a too-large project)
<natefinch> ericsnow: yeah, kinda sucks.
<ericsnow> natefinch: regardless, let me know if there's anything I can do to help
<natefinch> ericsnow: I'm making a copy of the wordpress charm to use only in the uniter tests where we need wordpress+resources, and hopefully that'll isolate it so it doesn't break everything else that wanted the old wordpress charm.  I think that's the last thing to do for this.
<ericsnow> natefinch: sounds good
<natefinch> ericsnow: now to wait 5 minutes for the uniter tests to run
<ericsnow> natefinch: see my reply comment about adding the IncCharmModifiedVersionOps in Staged.Activate()
<natefinch> ericsnow: ok, thanks for pinging me about it.
<ericsnow> natefinch: yep
<natefinch> ericsnow: ahh, thanks for the note on what you were thinking.  I was overcomplicating it in my head.
<ericsnow> natefinch: yeah, I could tell what you are thinking
<ericsnow> natefinch: dealing with that *in* the transaction is indeed a pain, though not quite a nightmare :)
<natefinch> ericsnow: also, I just stumbled on a better way to test resources, I think: https://github.com/juju/juju/blob/master/worker/uniter/uniter_test.go#L1976
<natefinch> ericsnow: we can append resources to the existing metadata.yaml for just the tests we care about
<ericsnow> natefinch: smart!
<natefinch> ericsnow: figured it out because this test was failing with invalid yaml
<natefinch> ericsnow: sort of surprised this test works at all... it seems to assume there's already a newline at the end of the yaml
<voidspace> dimitern: heh, so I have to reimplement environ.Spaces() ...
<voidspace> dimitern: the assumption that SpaceProviderId is a name is built into the way we fetch subnets and spaces
<voidspace> dimitern: and so switching requires changing the way we fetch subnets, which means rewriting Spaces because it builds the spaces from the subnets...
<voidspace> dimitern: ah well
<dimitern> voidspace, in a call, sorry - will get back to you shortly
<voidspace> dimitern: no need, was just commenting
<dimitern> voidspace, ah, ok then
<natefinch> ericsnow: keeping error values and call names in sync in the stub tests is killing me
<ericsnow> natefinch: sorry
<natefinch> ericsnow: we might want to build in a test that makes sure the number of errors prepopulated is the same as the number of calls... I think I see a place where I had more errors than calls
<ericsnow> natefinch: maybe so
<cmars> dooferlad, can I trouble you with a couple of small reviews? just deps updates to fix LP:#1534643
<mup> Bug #1534643: cookies file locked for too long <ci> <intermittent-failure> <juju-core:In Progress by cmars> <https://launchpad.net/bugs/1534643>
<cmars> anyone up for some short & sweet reviews? http://reviews.vapour.ws/r/3931/ and http://reviews.vapour.ws/r/3932/
<natefinch-lunch> I think the unit tests just popped up a browser window :/
<natefinch-lunch> Juju Charms API -> log in with Ubuntu One
<perrito666> dang
<perrito666> that is new?
<natefinch> I dunno.. was just running a full juju-core test
<alexisb> cmars, if you havent gotten your reviews, tim should be on soon
 * perrito666 cuts storage bucket out of providers
<perrito666> I have been removing stuff for a month from juju :p
<natefinch> perrito666: you are doing god's work
<perrito666> lol
<perrito666> I wouldn't put ian so high :p
<natefinch> heh
<perrito666> natefinch: there is a mail talking about the browser issue
<natefinch> perrito666: yeah, cmars let me know it's fixed in latest master
<natefinch> neat, a new sporadic failure: /home/ubuntu/juju-core_2.0-beta1/src/github.com/juju/testing/mgo.go:489: &errors.errorString{s:"no reachable servers"} ("no reachable servers")
<alexisb> natefinch, we dont need more of those
<natefinch> alexisb: indeed
<alexisb> and with that I go to lunch :)
<lazyPower> is it common that i see this with a longer-running beta-2 model-controller? consistently when i creat-models and destroy them after about the third one i start seeing this plague my units http://paste.ubuntu.com/15173762/
<lazyPower> if i upgrade-charm it typically goes away and triggers the install
<natefinch> if user==lazypower && rand.Under(0.33) { return failwhale() }
<lazyPower> natefinch - git-blame schenanigans.go
<natefinch> lazyPower: it's weird that it's a sha hash mismatch... I wonder if it's a network problem screwing up the download
<natefinch> I'm hitting them all today: github.com/juju/juju/state/cloudimagemetadata/image.go:86: cannot save cloud image metadata
<natefinch> rick_h_, ericsnow: are charmers allowed to update a charm and add/remove resources from the metadata.yaml?  I presume yes.  I don't think that's something we've thought about
<ericsnow> natefinch: adding new ones should work fine as-is, removing old ones should be covered once we handle removal
<natefinch> ericsnow: your charmstore poller looks like it's just marking what resources are out of date, but not storing the data on what's in the charmstore anywhere... don't we need both?
<ericsnow> natefinch: yeah, I'm working on that right now
<natefinch> ericsnow: ok, no problem... wanted to make sure I wasn't misunderstanding either your code or the spec :)
<natefinch> ericsnow: heh, we're going to have like 4 or 5 representations of a resource in the DB, depending on its state... staged, pending, active, waiting to be updated from the store...  yeesh.
<ericsnow> yep
<natefinch> we should scrap it all and turn it into a state machine ;)
 * natefinch waits for eric to say he already did that ;)
<natefinch> OMG... third sporadic test failure... good old "bad record MAC"
<wallyworld> thumper: with the new manifold stuff, do you know how to conditionally start a worker? previously, you'd just use an if statement in jujud/machine.go
<fwereade> wallyworld, heyhey
 * thumper lets fwereade answer
<wallyworld> fwereade: hey, maybe you can answer :-)
<fwereade> wallyworld, an if statement in th start func should do the trick -- depending on how changeable the value you're depending on is
<wallyworld> fwereade: what do i return from the start func? can't be nil
<wallyworld> is there a specific error?
<fwereade> wallyworld, what people always used to do was return FinishedWorker IIRC
<fwereade> wallyworld, that squicks me out
<fwereade> wallyworld, dependency.ErrMissing would probably do the trick though
<fwereade> wallyworld, that means "I'm not going to do anything with my current set of dependencies"
<wallyworld> sounds good, i'll try that
<fwereade> wallyworld, but will try again if any dependency does come up or go doown
<wallyworld> yeah, that was sort of my issue
<wallyworld> i didn't want it to retry
<katco> cherylj: where can i see the last bless of master?
<cherylj> katco: http://reports.vapour.ws/releases#master
<katco> cherylj: duh ty
<cherylj> np :)
<rick_h_> natefinch: yes, they can add/remove. I'm not sure what removing will do. Since you're always upgrading ahead and can downgrade, it'd have to keep it around for a while just like the charms themselves?
<natefinch> rick_h_: yeah, I don't think removing will be a problem if we keep them around (which we do).
<rick_h_> natefinch: yea, I think we'll need some admin way to garden those out at some point, as the infinite charms has shown to be a problem in large production deploys
<thumper> alexisb: you have frozen for me
<alexisb> thumper, lost you on the hangout
<lazyPower> natefinch - looks like a repeat offender. i just hit again on my second model :(
<lazyPower> is there anything i can tail/append here to help other than shasum mismatch?
<cherylj> can I get a quick / easy review?  http://reviews.vapour.ws/r/3936/
<anastasiamac> cherylj: looking :D
<anastasiamac> cherylj: LGTM :D
<cherylj> thanks, anastasiamac!
#juju-dev 2016-02-23
<anastasiamac> cherylj: it looks like gopkg.in/yaml.v1 is missing from the dependencies.tsv
<kilty> with juju init deprecated in 2.0, how would one go about setting params for a private openstack cloud?
<kilty> the command-changess page links to https://jujucharms.com/docs/devel/juju-config.md as a referenc for the new method, which is a broken link
<mup> Bug #1548564 opened: restart failed upgrade <juju-core:In Progress by anastasia-macmood> <juju-core 2.0:In Progress by anastasia-macmood> <https://launchpad.net/bugs/1548564>
<kilty> alternatively, is there an another way to fix the "ERROR juju.cmd supercommand.go:429 cannot set initial environ constraints: index file has no data for cloud {RegionOne http://192.168.4.11:5000/v2.0} not found" error? (http://pastebin.com/RXKmg2gC)
<mup> Bug #1548564 changed: restart failed upgrade <juju-core:In Progress by anastasia-macmood> <juju-core 2.0:In Progress by anastasia-macmood> <https://launchpad.net/bugs/1548564>
<bogdanteleaga> kilty, by params you mean params that were previously set in environments.yaml?
<mup> Bug #1548564 opened: restart failed upgrade <juju-core:In Progress by anastasia-macmood> <juju-core 2.0:In Progress by anastasia-macmood> <https://launchpad.net/bugs/1548564>
<kilty> bogdanteleaga: trying to deploy juju on a private openstack cloud - when I install juju-core2, how do I set the auth url, user/pass, tenant name, etc?
<bogdanteleaga> kilty, https://paste.ubuntu.com/15127859/, just at the bottom
<bogdanteleaga> basically the whole configuration got split up amongst more files, or it can be specified from the cli
<kilty> awesome
<kilty> thank you - I'll give that a shot tomorrow morning
<cherylj> anastasiamac: yeah, I saw. Thanks!
<thumper> grrr
 * thumper deals with icky merge from trunk
<thumper> changes to code I have moderately attacked with a machette during refactoring
 * thumper makes a big sad face
<wallyworld> axw: whenever you have a chance https://github.com/juju/romulus/pull/11
<axw> wallyworld: sure, looking
<axw> wallyworld: hrm, can you hold off a bit? I'm updating the interface to take an account name as well as controller name
<axw> for ModelGetter and friends
<wallyworld> ok
<axw> wallyworld: won't be much more of a change
<wallyworld> np, i'll wait
<wallyworld> cherylj: i'd hardly class that "lxd" not being in list-clouds output as critical
<wallyworld> it's more a kin to a doc issue
<wallyworld> along the same lines as the bootstrap help bug
<thumper> is master currently blocked?
 * thumper wants to merge some useful changes
<thumper> particularly refactored code I'm using in migrations
<thumper> to avoid extra conflicts
<thumper> can people please stop changing code?
<thumper> that'd be swell
<natefinch> heh
<natefinch> I think my manager would get mad ;)
<natefinch> master is not blocked btw
<thumper> wallyworld: StopMongoUntilVersion
<thumper> wallyworld: what can you tell me about it?
<wallyworld> it's part of the mongo 2-> 3 migration implementation
<thumper> hmm...
<thumper> which will have happened by 2.0?
<thumper> or not?
<thumper> why do we need a worker?
<wallyworld> yes, we are waiting on the deb packaging
<thumper> can't we just say "2.0 needs mongo 3.0"
<wallyworld> that's what we are doing
<thumper> um...
<wallyworld> but mongo is not packaged and in the archives
<thumper> then why encode into state?
<thumper> I'm just unclear as to the process
<thumper> hangout?
<wallyworld> sure
<thumper> wallyworld: 1:1
 * thumper waits patiently for the local test run to complete before submitting for real muerge
<frobware> dimitern, dooferlad: http://reviews.vapour.ws/r/3942/ - choosing to merge blessed builds atm.
<dimitern> frobware, LGTM, thanks
<jam> fwereade: ping about a config location
<jam> specifically, the LXD provider has always used $HOME/.config/lxc/$NAMESPACE as the directory that holds the information we need for talking to the LXD daemon
<jam> however, our test suite seems to now be appropriately sanitizing $HOME
<jam> which means the lxdclient code is trying to create /.config/lxc/blah
<jam> and that is (correctly) failing
<jam> (note that in the actual providers once you bootstrap, the Juju machine agent was also always using /.config/... because $HOME wasn't set for the Juju agent)
<jam> I'd like to move those files to somewhere more appropriate, and just wanted to run it past you
<fwereade> jam, I agree they should not be there :)
<jam> fwereade: so far as I can tell none of our other Providers/Brokers need to write something to disk
<jam> so I don't have a lot to reference for where to get the information from and where to save it.
<fwereade> jam, nor do I really... an agent's datadir feels like the closest equivalent of $HOME?
<jam> fwereade: so there are 2 aspects. 1 is for the "local" LXD provider which is a provider all by itself
<jam> and the other is for the agents that then create LXD containers
<frobware> dimitern: standup
<mup> Bug #1548799 opened: bootstrap from windows fails with no such file <ci> <regression> <windows> <juju-core:Triaged> <https://launchpad.net/bugs/1548799>
<mup> Bug #1548809 opened: cmd/juju/action: FetchSuite.TestRun takes 18s to run <tech-debt> <juju-core:Triaged> <https://launchpad.net/bugs/1548809>
<evilnickveitch> so, juju2.0 doesn't set $JUJU_HOME ?
<frobware> voidspace: MAAS ho?
<natefinch> morning all
<natefinch> evilnickveitch: I believe JUJU_HOME is called something different in 2.0
<natefinch> evilnickveitch: to enable using it side by side w/ 1.25
<evilnickveitch> natefinch makes sense, but I can't find what it is :)
<evilnickveitch> I can't find any JUJU*
<natefinch> evilnickveitch: JUJU_DATA
<voidspace> frobware: oops, omw
<natefinch> evilnickveitch: https://github.com/juju/juju/blob/master/juju/osenv/vars.go#L21
<evilnickveitch> natefinch thanks! I will take your word for it. Currently running beta1 and it hasn't set any of those
<perrito666> evilnickveitch: it is called JUJU_DATA and it is by default $XDG_DATA_HOME/juju or ~/.local/share/juju if XDG_DATA_HOME is not defined
<natefinch> evilnickveitch: what do you mean by it hasn't set them?  These are what a user would set to control where juju stores its data
<perrito666> evilnickveitch: juju does not Set those
<perrito666> evilnickveitch: juju uses them if set
<perrito666> anyhow if neither of thise is set the path is ~/.local/share/juju
<evilnickveitch> perrito666, natefinch thanks, I will update the reference pages. I didn't think Juju had picked up my setting but i think it was a typo on my part
<natefinch> anyone know if there's a plan to remove the "unstable" from the charm.v6 repo?
<rick_h_> natefinch: only once the new publish process is signed off and as part of 2.0 changes that require updates like resources work
<rick_h_> natefinch: so "yes, there's a plan" but it's "not yet"
<natefinch> rick_h_: kk
<cherylj> frobware: ping?
<cherylj> natefinch: can you do a quick review for https://github.com/juju/juju/pull/4508 ?  It's backporting your proxy fix
<natefinch> cherylj: no problem
<frobware> cherylj: pong
<cherylj> frobware: hey, just wanted to check on what you guys are working on in the maas-spaces2 branch, and what milestone / release you were targeting
<natefinch> cherylj: have you run the tests locally?  I'm worried bumping the utls revision might have unintended side effects.  I mean, certainly we can let CI do the lifting, just curious
<cherylj> natefinch: yeah, I forked utils off for 1.25 so it didn't pull in the massive amount of changes that have gone in there since 1.25
<cherylj> natefinch: and just applied your proxy change to it
<frobware> cherylj: want to sync quickly? I have 15 mins
<natefinch> cherylj: ahh, ok.
<cherylj> frobware: yes - https://plus.google.com/hangouts/_/canonical.com/cheryl-andy?authuser=0
<natefinch> cherylj: in an ideal world we should really make that a separate import path, so there's no confusion, but I understand that's significantly more work than just letting godeps cheat for us.
<natefinch> cherylj: anyway, LGTM
<cherylj> thanks, natefinch!
<alexisb> frobware, ping
<cherylj> sorry alexisb, I was keeping him
<alexisb> ah nws, no rush
 * natefinch imagines cherylj with frobware in a curio cabinet.
<cherylj> natefinch: MRW I had to let him go:  http://goo.gl/blhJiO
<natefinch> cherylj: lol
<cherylj> I had to set it to wumbo
<natefinch> good lord someone really needs to write a stringdiff checker for gocheck
<natefinch> like, don't just tell me these two huge strings are different, show me where
<perrito666> natefinch: that and pprint for things
<natefinch> perrito666: yeah, I'd kill for a nicely indented %#v
<natefinch> perrito666: I think I remember there's a third party package out there that does it
<natefinch> perrito666: https://godoc.org/github.com/kr/pretty
<natefinch> there's a few others, but that one seems most like what I would want as output
<natefinch> there's go-spew as well, but it has ugly output IMO
<natefinch> https://github.com/davecgh/go-spew
<katco`> natefinch: ericsnow: could use a +1 on http://reviews.vapour.ws/r/3916/
<natefinch> katco`: I'll take a look
<katco`> natefinch: ty... very short review
<natefinch> katco`: ship it
<katco`> natefinch: ty
<katco`> ericsnow: are you with us today? :)
<ericsnow> katco`: yep, sorry, missed your message
<katco`> ericsnow: no worries, just hadn't seen you yet
<katco`> ericsnow: i said good morning, but then my bouncer booted me right away, so don't know if anyone responded
<natefinch> the perils of no morning standup
<natefinch> katco`: I think your good morning got swallowed by the internet
<katco`> booo internet
<katco`> what has it ever done for us
<natefinch> lol
<natefinch> smoke signals should be good enough for anyone
<ericsnow> internet: she didn't mean it
 * ericsnow hopes we haven't angered it
 * katco` has quit (Connection timeout and also she smells, ~<3 Internet)
<natefinch> lol
<natefinch> katco`, ericsnow: I may have overestimated the time to complete this card: http://reviews.vapour.ws/r/3945/
<ericsnow> katco`: I could use a quick re-review on both my patches
<katco`> natefinch: rock!
<ericsnow> natefinch: could you look over my responses to your comments on http://reviews.vapour.ws/r/3891/?
<ericsnow> natefinch: nice
<natefinch> ericsnow: sure thing.
<katco`> natefinch: ericsnow: i'll be getting to reviews here in a sec. wrapping up my PR for my card
<ericsnow> natefinch: ta
<ericsnow> katco`: np
<natefinch> actually, I'm on-call reviewer today, so I should spend some time on that anyway
<katco`> ericsnow: natefinch: furnace guy is here... will be in and out
<ericsnow> katco`: k
<ericsnow> katco`: good luck
<perrito666> everything suddenly went almost night dark, so if you dont see me respond is because power went away
<perrito666> https://pbs.twimg.com/media/Cb6jfLLWEAA_t7O.jpg:large https://pbs.twimg.com/media/Cb6f_tnW4AQySJd.jpg:large  <-- 2 PM on summer
<natefinch> yikes
<natefinch> katco`, ericsnow: I'll need another card after I do some reviews.  What about the extension validating one?
<ericsnow> natefinch: what about the overhead card in the iteration backlog?
<katco`> natefinch: i'd rather you pick up the other critical user story
<natefinch> ericsnow: good point, I was glazing over anything that wasn't a user story.  katco`, what do you think?  That one will fix multiple fairly ugly bugs.
<katco`> natefinch: that's fine too... need to know how long it's going to take
<ericsnow> natefinch: FYI, I've reviewed your patch
<natefinch> katco`: lemme go investigate for a few, IIRC it was a little annoying to get the left hand to talk to the right hand
<natefinch> ericsnow: thanks
<natefinch> ericsnow: good point about using FormattedCharmResource!
<natefinch> (resuing)
<natefinch> reusing... feg
<katco`> natefinch: np
<natefinch> feh
<natefinch> stupid fingers.
<natefinch> katco`: should be doable by tomorrow afternoon
<natefinch> katco`: hopefully earlier, but I'm inclined to be conservative at this point.
<katco`> natefinch: good deal... flag the card if you don't mind
<katco`> they probably have to replace my entire furnace T.T
<katco`> right before we move
<katco`> not cool, internet. not cool.
<perrito666> katco`: renting house?
<katco`> perrito666: no, we're relocating
<perrito666> so you have to fix the furnance for the new home?
<katco`> no the home we're going to be selling very soon
<perrito666> ah, it seems its easier to sell it like it is and just make a discount :p
<perrito666> although I am not entirely sure to what does furnance translate to
<katco`> perrito666: that's not really an option since it's not working at all
<natefinch> perrito666: furnace == heat
<katco`> ah yes, sorry
<katco`> it's what heats the house
<perrito666> just googled and I got an idea
<natefinch> perrito666: no one's going to buy a house without any heat :)
<perrito666> Ill assume it is not a 300 dollars to replace it as it is here
<katco`> perrito666: they just quoted me $2k
<natefinch> perrito666: depends on what you get, but often like $2500-5000
<perrito666> ouch :p
<natefinch> katco`: that blows, sorry.
<perrito666> mine just heats wather for the floor heating system, but it was cheap :)
<perrito666> this is my street after a few mins of rain http://i.imgur.com/CgSlkF3.jpg
<mup> Bug #1548921 opened: credentials.yaml file should have a stub <docteam> <juju-core:New> <https://launchpad.net/bugs/1548921>
<lazyPower> natefinch - i think if oudn the culprit
<lazyPower> natefinch - do you recall yesterday how i was having hashsum mismatches delivering the charm  from mc => unit?
<lazyPower> this appears linked to when i use juju upgrade-charm --force-units, with a couple of them deployed... i dont know if the hashes are getting out of sync between what the state server thinks should be there or what, but it doesn't barf if i dont upgrade-charm --force-units in the model.
<natefinch> lazyPower: interesting
<lazyPower> natefinch aside from anecdotal evidence, what could i gather to reproduce and file a bug?
<natefinch> lazyPower: can you repro with a simple case?
<lazyPower> Will work on it and get that + bug# at you then.
<lazyPower> cheers :)
<natefinch> lazyPower: cool, thanks
<natefinch> rick_h_: the spec for showing updates available on resources when running juju resources... should those be shown for all modes of juju resources, or just the generic juju resources servicename?  i.e. should it be shown for juju resources unitName or juju resources servicename --details?
<rick_h_> natefinch: i think like juju status for all commands. i don't want havevto write a bash for loop to check for updates available across my model.
<rick_h_> natefinch: thoughts?
<natefinch> rick_h_: what I mean is,  I already have it coded so that juju resources wordpress will show you warnings for any out-of-date resources for the service.  but my question would be, should we show the same warning if you do juju resources wordpress/0  or juju resources wordpress --details?
<natefinch> rick_h_: I don't think it's appropriate when you're just viewing a single unit... but not sure about when you're viewing the detailed output for a service.... probably
<mup> Bug #1548938 opened: list-credentials doesn't include 'discovered' creds <docteam> <juju-core:New> <https://launchpad.net/bugs/1548938>
<natefinch> rick_h_: we don't currently support just running "juju resources" without the service name
<natefinch> rick_h_: (because it's not in the spec ;)
<rick_h_> natefinch: ok, taking that one at a time. I definitely think that --details should show since it's about getting into the thorough details
<natefinch> agreed
<rick_h_> natefinch: agree that on a unit, only showing it's current revivsion vs expected revision makes sense
<rick_h_> natefinch: since you're not scoped to the "service as a whole" which an upgraded resource represents
<natefinch> exactly
<rick_h_> natefinch: and /me loads spec to see what we have/don't for "juju resources" as a lone command
<natefinch> I wouldn't be totally against it, though honestly, most commands run over the entire model lose usefulness once you have a realistically sized model
<natefinch> though if you only showed out of date resources for the entire model, that could be quite usefukl
<rick_h_> natefinch: well,it seems you'd be able to show your network map, storage pools created, etc.
<rick_h_> natefinch: but you're right, that never came up in the spec...
<natefinch> rick_h_: sure, sure
<rick_h_> natefinch: well any kind of audit function/debugging details would want a 'wtf is running'
<rick_h_> natefinch: so current resources that have been 'resource-get' and their revisions, along with any upgrades available seems useful
<rick_h_> natefinch: because if you go to file a bug, knowing which ones are there are important to duplicating. And without having to script a for loop for each service
<natefinch> yep
 * rick_h_ hangs head in shame that he missed this in the spec so far
<natefinch> rick_h_: we missed the existence of juju deploy --resource... I think you're in good company ;)
<natefinch> the only perfect spec is the code itself
<rick_h_> natefinch: ok, so you have what you need for the moment?
<natefinch> rick_h_: yes... we'll just do it for the service and service with --details
<rick_h_> natefinch: k, ty for the ping
<natefinch> rick_h_: and I leave it with you to arm wrestle katco` about listing resources across the model
<rick_h_> natefinch: heh, /me runs to protective tank
<rick_h_> natefinch: the good news is that it's not bad since Juju is just looping on myhalf? /me hopes :)
<natefinch> rick_h_: not the end of the world, but a few days' work, certainly
<natefinch> rick_h_: one more thing I thought of.... once you override a store resource by uploading a local resource with push-resource, I presume we won't upgrade that resource when you do a charm-upgrade, correct?
<rick_h_> natefinch: I think that's true. The key there will be indicating that to the user somehow.
<rick_h_> natefinch: though...if you upgrade-charm...
<rick_h_> natefinch: thinking
<natefinch> rick_h_: it seems logical to me to pin it... but then we have no way to un-oin it currently
<natefinch> un-pin that is
<rick_h_> natefinch: so since the only way to upgrade that is with upgrade-charm, and that is an explicit call to "get me the latest from the charmstore"
<rick_h_> (assuming it's not upgrade-charm ./localpath)
<rick_h_> natefinch: I don't think we pin, I think it's just doing what the user asks
<natefinch> rick_h_: so the problem is, I'm using a charm that has stub-resources in the charmstore... the charm code gets updated, and there are some minor tweaks to the stub resources, so they get updated too... charm-upgrade will now throw away my real resources and replace them with the stubs in the store
<rick_h_> natefinch: so but we don't tell 'stub' from 'non-stub'
<rick_h_> natefinch: you might need that resource for a bugfix and want to get back on 'stable' footing
<rick_h_> natefinch: I think the trick there is upgrade-charm supporting something...either manually specified resources or something that says "charm w/o new resources"? but then maybe you want one/not all
<rick_h_> natefinch: so ugh?
<natefinch> rick_h_: ug is right
<natefinch> rick_h_: I definitely think there will be times when users want one or the other behavior
<rick_h_> natefinch: I'm getting tempted to suggest a --without-new-resources flag to upgrade-charm
<natefinch> rick_h_: I was thinking it might be useful to have a command to revert an uploaded resource to the store-version
 * rick_h_ isn't sure on that one
<rick_h_> natefinch: hmm, actually I think this fits into the stuff I'm writing for the juju resources command.
<natefinch> rick_h_: I was just thinking that splitting it into two commands might give the most flexibility to the user.  have upgrade-charm keep uploaded resources as they are, but if someone wants to stop using an uploaded resource, they can juju unpush-resource (hopefully with a better name)
<rick_h_> natefinch: well, the idea would be you could push a resource with a charmstore url.
<rick_h_> natefinch: that indicates your interest in following the CS blessed paths perhaps
<natefinch> rick_h_: ooooh, I like that
<rick_h_> natefinch: though it might not be techincally blessed based on the revision you have...thinking more
<natefinch> rick_h_: I like that it's explicit about what exactly you'll get
<rick_h_> natefinch: right
<rick_h_> I think that falls under the normal charmstore rules of you can leave off the revision, it grabs the latest blessed revision
<rick_h_> and you'd track the charmstore from there on
<rick_h_> and if you provide a local file, you'd ignore the charmstore updates from then on, until you went back to a push-resource cs:xxxxx
<natefinch> yeah, I think that's what I would expect... if juju threw out the thing I uploaded and explicitly told it to use, I'd get mad
<rick_h_> hmm, this is working ok in my head at least
<rick_h_> yea...and if I deploy a service with local files, even if I upgrade the charm I've indicated I'm manually handling resources
<natefinch> yep
<rick_h_> ok, this falls into the lovely "handling upgrades" section.
<natefinch> might be worth having a flag on upgrade-charm that forces the use of the store resources... otherwise it might be impossible to upgrade, if the new resources and old resources are incompatible
<rick_h_> natefinch: how so?
<rick_h_> natefinch: if you have a new charm, and it wants different resources, it'll error and then you'll have to provide them, rerun hooks, and get from error to normal?
<rick_h_> natefinch: and there's an upgrade-charm flag with the --resources option
<rick_h_> natefinch: so you could do it in one swoop?
<natefinch> rick_h_: anything involving rerunning the hooks is bad.  But yes, --resources could work if you can specify charmstore urls.
<rick_h_> natefinch: right
<natefinch> except uh..... I think we missed upgrade-charm --resources.  AFAIK we don't have cards for that... ericsnow, katco` ... I think this is work we're missing
<ericsnow> natefinch, rick_h: correct me if I'm wrong, but "juju upgrade-charm --resources" is new to the spec
<rick_h_> ericsnow: well it was a "case" in the upgrade cases that was blank
<rick_h_> ericsnow: those weren't all filled out and natefinch has been asking about those cases right now
<natefinch> ericsnow: so... sort of :)
<ericsnow> rick_h_: I was looking for a "upgrade-charm --resources" in the spec yesterday but did not find one
<ericsnow> rick_h_: ah
<rick_h_> ericsnow: right, it was "Upgrade charm and use supplied resource at upgrade time" without a command in the following bullet point
<natefinch> ericsnow: the actually CLI command was just added, but there was a bullet point labelled "Upgrade charm and use supplied resource at upgrade time" under upgrades
<katco`> rick_h_: i apologize, i'm having to buy a new furnace so i'm not able to give this my full attention. can the new bullets under "handling upgrades" be pushed to a v2?
<rick_h_> ericsnow: and I think that logically fits into place there.
<rick_h_> katco`: understand, let's sync on it when you're free. I've given natefinch what he needs to unblock him for the moment and we'll go through the updates and see what can be bumped.
<rick_h_> katco`: take care of getting fire first, handy this time of year
<katco`> rick_h_: you're not kidding. we are getting pretty creative here with space heaters =|
<perrito666> I dont understand, its pretty warm this time of the year, after a decent rain temp got down to 25C
<perrito666> :p
<natefinch> lol
<natefinch> we don't all live in the jungle, perrito666
<katco`> perrito666: you shut your souther-hemisphere mouth!
 * perrito666 closes his mouth, around a straw, and zips a fruit juice
<katco`> perrito666: rofl
 * katco` enjoys the phone transfer tolken ring she seems to be on
<perrito666> katco`: you are on the infinite call center loop?
<ericsnow> katco`: do you mind if I land my 2 patches; natefinch has given ship-its and I've addressed all the open issues
<katco`> ericsnow: please go for it.
 * katco` is frustrated
<natefinch> ericsnow: I have one concern I just found
<katco`> i can't think of many worse times for this to happen (grumble)
<ericsnow> katco`: I left a few open to point out where we might discuss it a bit more, but I feel comfortable with where things are at
<natefinch> ericsnow: I was looking at the updates function
<ericsnow> natefinch: uh oh
<ericsnow> natefinch, katco`: FYI, I have a patch up for moving resources persistence to the state package
<natefinch> ericsnow: I don't liek that it assumes the two lists are the same length and in the same order.  I'd rather explicitly check the resource names
<ericsnow> natefinch: that's fine; I did make it clear in the doc comment that they are one-to-one
<natefinch> ericsnow: yeah, but that guarantee is really really really far removed from that code
<ericsnow> natefinch: I'll fix it up
<natefinch> ericsnow: thanks... sorry, the only reason I noticed was because I copied your code for doing my testing, and had weird behavior because my lists were out of order
<ericsnow> natefinch: sounds like a personal problem <wink>
<natefinch> ericsnow: lol
<thumper> ericsnow: thanks for the move, doing payloads too?
<ericsnow> thumper: wasn't planning on it
<ericsnow> thumper: I wouldn't mind but you'll have to win over katco` (and you shouldn't mess with her today!)
 * thumper keeps his distance
<ericsnow> thumper: (we're still scrambling with resources)
<katco`> thumper: :) we'll do it happily if we can get out ahead on resources
<ericsnow> thumper: (and katco` is dealing with a bad furnace)
<ericsnow> thumper: FWIW, moving payloads should look just like the patch for resources
<thumper> ericsnow: um... have you seen the size of that?
<thumper>  ï¿¼ 47 changed files  with 2,110 additions and 546 deletions.
<thumper> ericsnow: I'm pretty sure you aren't taking across what you think you are
<ericsnow> thumper: that's because it's based on other branches; in RB you'll see it is ~ +200, -200
<natefinch> rick_h_: the spec calls the section for updates "[Updates available]" (note the lowercase a in available).  Should that be a capital a for Available?"
<rick_h_> natefinch: no, it's only the first word caps. /me tries to remember the email/notes from jam on that
<natefinch> rick_h_: boo
<katco`> rick_h_: natefinch: i think we can do second word caps too
<katco`> rick_h_: natefinch: i think the real contention was b/t all caps and camel-case of sorts
<rick_h_> katco`: natefinch yea, foudn the email
<rick_h_> that's the rule
<rick_h_> title case
<katco`> rick_h_: title case, there we go
<rick_h_> natefinch: katco` so title case should be Updates Available
<natefinch> huzzah
<rick_h_> my bad
<rick_h_> :P
<katco`> ericsnow: natefinch: being on hold has it's advantages: http://reviews.vapour.ws/r/3948/
<ericsnow> katco`: nice
<natefinch> katco`: lol
<natefinch> ericsnow, katco`: gah, we need to implement FingerPrint.Equal :/
<natefinch> ericsnow, katco`:  that's the second place we'll be writing a custom comparison func
<ericsnow> natefinch: IIRC, I did in my original proposed patch and you shot it down :)
<natefinch> ericsnow: who, me?  Saying we shouldn't implement things before we need them?  Doesn't sound like me ;)
<ericsnow> ha
<natefinch> ericsnow: for that one though, if I did say that, I was definitely wrong. That was pretty inevitable that we'd need it... and it's outside juju/juju, so it's annoying to add later.
<ericsnow> natefinch: yep
<kilty> I'm able to successfully issue a 'juju bootstrap' on my openstack private cloud, but when the new instance starts up the service it returns: "index file has no data for cloud"  Any ideas?
<natefinch> doesn't sound familiar
<natefinch> thumper: ^
<mup> Bug #1548938 changed: list-credentials doesn't include 'discovered' creds <docteam> <juju-core:Invalid> <https://launchpad.net/bugs/1548938>
<natefinch> ericsnow: fixed up my pr for updates available, adding support for doing it during --details as well.  please re-review.  I wrote my own updates function, but I'll wait until your code is in and overwrite mine with yours.
<natefinch> ericsnow: http://reviews.vapour.ws/r/3945/
<ericsnow> natefinch: it's merging now, BTW
<natefinch> ericsnow: cool, I'll rebase once it's in.
<mup> Bug #1548938 opened: list-credentials doesn't include 'discovered' creds <docteam> <juju-core:Invalid> <https://launchpad.net/bugs/1548938>
<mup> Bug #1548938 changed: list-credentials doesn't include 'discovered' creds <docteam> <juju-core:Invalid> <https://launchpad.net/bugs/1548938>
<mup> Bug #1548938 opened: list-credentials doesn't include 'discovered' creds <docteam> <juju-core:Invalid> <https://launchpad.net/bugs/1548938>
<mup> Bug #1548938 changed: list-credentials doesn't include 'discovered' creds <docteam> <juju-core:Invalid> <https://launchpad.net/bugs/1548938>
<natefinch> ericsnow: here's my approach for returning unitresources for all units, would like your thoughts before I get too far into it: http://reviews.vapour.ws/r/3949/diff/#
<natefinch> (though obv standup now)
<lazyPower> if anyone has a minute to riff on this - https://github.com/juju/charm-tools/issues/91 - is there any explicit reason underscores are not accepted in action parameters/names?
<jw4> lazyPower: IIRC it's simply because that wasn't one of the characters allowed.  The 'allowed' characters were a pretty small subset in bodie's initial implementation.
<lazyPower> cool, thanks jw4
<perrito666> axw: when you are around, could you re-check https://github.com/go-amz/amz/pull/66 please?
<axw> perrito666: sorry, should have said LGTM with that in the first place. LGTM
 * axw disappears again
<axw> before I do...
<axw> wallyworld: FYI, still a bunch of tests to update for my branch :/   it's a bit of a monster
<perrito666> axw: tx
<wallyworld> axw: quick chat? in standup channel?
<axw> wallyworld: we were silently ignoring missing current-controller in controller commands. not ignoring == lots of errors
<axw> wallyworld: ok
<axw> perrito666: want me to merge?
#juju-dev 2016-02-24
<ericsnow> wallyworld: I'm becoming less convinced that merging the charm store call is worth trying before we've settled the charm store API with Uros and co.
<wallyworld> ericsnow: it's not settled? how is the new worker been done then?
<ericsnow> wallyworld: making it work will require touches in the charmrepo code that may not be desireable
<wallyworld> if there's no api?
<ericsnow> wallyworld: I'm talking about the call to the charm store (the worker part isn't a problem)
<wallyworld> so the worker doesn't do anything?
<ericsnow> wallyworld: it only runs the updater that got passed in to the worker's config
<wallyworld> and that is a stub then i guess?
<ericsnow> wallyworld: ultimately the worker triggers an API call and the charm store API call happens on the controller
<wallyworld> ok, i guess i was expecting the api to be sorted before starting on the worker
<ericsnow> wallyworld: I'm talking about the charm revision updater and I think you might be talking about the new resource poller :)
<wallyworld> we're talking about both i think?
<ericsnow> wallyworld: k
<wallyworld> anyways, if the api is not done, then yeah we need to sort that first
<ericsnow> wallyworld: anyway, the API server makes a call to charmrepo.CharmStore.Latest(), which gives back a slice of ints (for charm revisions)
<wallyworld> yes
<ericsnow> Latest, in turn, uses that "meta" GET to get that info
<wallyworld> yes
<ericsnow> and that does not support resources yet, AFAIK
<wallyworld> ok, that's what i wasn't sure of, i thought it would if we were polling for respource updates
<ericsnow> so that will have to happen plus the CharmStore.Latest() method will have to change its signature
<wallyworld> yep
<wallyworld> given a charm is now a tuple, it makes sense for Latest() to need updating
<ericsnow> I would not be surpised if the charm store API grew a more dedicated way to get the combined  info we want for the worker
<wallyworld> possibly
<ericsnow> I will still combine the workers, even if (for now) we are making multiple charm store API calls
<wallyworld> that would be good
<wallyworld> less moving parts
<cherylj> can I get a review?  https://github.com/juju/juju/pull/4514
<cherylj> It's a backport of a PR that's been merged into master
<cherylj> and is reviewboard not picking up PRs?
<wallyworld> cherylj: rb has been flakey this week
<wallyworld> looking
<ericsnow> wallyworld: and necessary once we consolidate the 2 charm store API calls
<wallyworld> yep
<wallyworld> fits the model better too
<alexisb> wallyworld, tab completion has stopped working for me also
<alexisb> with the latest master
<wallyworld> alexisb: damn, i thought there was something wrong
<wallyworld> not surprised
<alexisb> ug
<wallyworld> because cli has changed so radically
<wallyworld> hence i raised it :-)
<alexisb> I didnt remove any tab completion code though
<alexisb> and it was working with my last commit
<alexisb> this is new
<wallyworld> no, but the code uses the cli to figure out what to tab complete
<wallyworld> hmmm, ok
<wallyworld> maybe false alarm, i'll try running the make target
<natefinch> I filed a few bugs about our tab completion.. in many cases it just panics
<natefinch> or at least it did in 1.x
<wallyworld> alexisb: i just ran the make target "install-etc" and it seems to wrok again
<wallyworld> maybe that was all i was missing before
<wallyworld> cherylj: +1 on that pr
<alexisb> weird the only thing I changed in my setup was a new pull of master
<natefinch> alexisb: I had problems with tab completion barfing if the "current" environment (now, model) wasn't bootstrapped
<wallyworld> if any command returns an error, it won't work
<natefinch> wallyworld: the problem I had was that it would spew out garbage into the terminal in that case
<wallyworld> as it uses the CLI "juju help commands" to figure stuff out
<alexisb> natefinch, interesting
<alexisb> let me mess with that for a minute
<wallyworld> garbage on terminal would do it yeah
<natefinch> wallyworld: oh yeah, the ridiculous code that reads the stdout of a run of the command... good lord
<natefinch> wallyworld: I remember making a ton of tests fail by inserting a fmt.Printf() for some debugging code and BOOM all this code that reads stdout failed
<wallyworld> sometimes our tests look at what's written to the user but that makes them fragile
<alexisb> ok my issue was different
<alexisb> I had a conflict on the alias and it toasted the whole thing
<alexisb> sorry for the false alarm
<wallyworld> alexisb: this scares me
<wallyworld> # juju-core.bash_completion.sh: dynamic bash completion for juju cmdline,
<wallyworld> # from parsed (and cached) juju status output.
<natefinch> ahh, yeah, I've done that
<wallyworld> juju status output is now all different
<wallyworld> so completion will fail for machines, services etc
<alexisb> wallyworld, lovely
<wallyworld> i have no idea how the cli completion stuff works, just saw the comment in the file
<wallyworld> we'll need to fix that, yay
<alexisb> wallyworld, its magic ;)
<wallyworld> i think in this case it is
<alexisb> well for right now it is working for me
<alexisb> so I ill go back to storage, but put it on the list of to-dos
<axw> wallyworld: sorry had to cut you off before, was there anything else to discuss?
<wallyworld> axw: no problem at all, we covered it all. i have pushed changes to that beta1 cleanup pr
<axw> wallyworld: LGTM, thanks
<wallyworld> ta
<menn0> thumper: I think I've found out why the apiserver appears to be dying before the logsink request is done
<menn0> thumper: the waitgroup is only increment for "normal" api requests
<thumper> and...
<menn0> thumper: the "streaming" style requests don't appear to be counted
<thumper> ah..
<menn0> so /log, /tools, /charms etc all don't count
<menn0> interestingly, fwereade_ emailed me last night as he's seeing the same problem
<axw> wallyworld: teeny one https://github.com/juju/juju/pull/4515
<wallyworld> looking
<wallyworld> axw: ship it, thanks for fixing
<axw> wallyworld: ta
<wallyworld> axw: http://reviews.vapour.ws/r/3940 should be go for another look when you get a chance
<axw> wallyworld: sorry, had to go get jeremy. furiously trying to finish this branch, will look soon
<wallyworld> no hurry, all good
<natefinch> man I hate the new bootstrap.  The error messages are all horrible
<natefinch> error: controller name and cloud name are required
<natefinch> ...no, no they're not.  And actually, cloud name isn't even something you can specify
<natefinch> I wish we had a juju env command that would print out what directories juju thinks it's supposed to be using.
<natefinch> (among other environment variables... but right now I'm concerned that it's using some other JUJU_DATA directory... but I don't know what one it thinks it's supposed to be using
<natefinch> wallyworld. axw, menn0: did we break the lxd provider? I don't seem to be able to switch to it anymore (I'm on wily using go1.4, so it
<natefinch> it's definitely getting compiled etc)
<wallyworld> natefinch: we didn't, lxd did
<natefinch> wallyworld: ahh
<natefinch> wallyworld: well shit
<wallyworld> they changed stuff upstream without any regard for juju :-(
<wallyworld> john is working with them to fix
<natefinch> wallyworld: so uh... I guess I have to test on amazon, since there's no more local?
<wallyworld> for now yes :-(
<wallyworld> unless you pin lxd beta2
<natefinch> hmm, pinning is probably easier
<wallyworld> not sure if debs are still around somewhere
<wallyworld> google may help find them
<natefinch> wallyworld: oh, like lxd itself, not the API library. I see.  Well, crap
<wallyworld> yup
<natefinch> whelp, guess I'll mess with that in the morning
<axw> wallyworld: sorry  :(  https://github.com/juju/juju/pull/4517
<wallyworld> np :-)
<axw> wallyworld: I had to change the format of show-controllers/list-controllers, so something to look out for and see if you agree with
<wallyworld> ok
<axw> well I didn't *have* to, but I think it makes more sense this way
<axw> wallyworld: were you not able to move the LocalControllerByName into modelcmd?
<wallyworld> axw: ah, yeah, i kept it separate, i should have moved it
<wallyworld> i'll do that next
<axw> wallyworld: I think that would be good. keeps the policy away from storage
<axw> wallyworld: ok, thanks, will continue reading
<wallyworld> axw: lgtm, a lot is mechanical. i look forwar dto resolving all the conflicts :-)
<axw> wallyworld: I'll bet. thanks!
<axw> wallyworld: in case it wasn't obvious from my last PR, it should be possible to stop using configstore in most commands now. it's now only used for bootstrap config in juju/api.go
<wallyworld> axw: i noticed :-)
<wallyworld> just shitloads of tests to fix
<axw> wallyworld: indeed
<axw> wallyworld: sorry, mind's all over the place - did you tell me this morning what was next after this PR?
<wallyworld> axw: yes, but now i've forgotten, let me think
<axw> heh :)
<wallyworld> axw: that's right, we talked about doing the "admin" model thing, but i need to email qa. one quick fix - can we write to jujuclient store earlier in bootstrap process so we don't get a stupid error trying to run status before bootsttap has finished?
<wallyworld> so the "admin" work can be started, and i'll email qa overnight
<wallyworld> we also have login/logout
<axw> wallyworld: sure. yep, was intending to work on login next
<wallyworld> axw: the error i refer to is "no controller defined"
<axw> wallyworld: can't see it getting done before I leave tho
<axw> (login command that is)
<wallyworld> can make a start, keep the prs small
<axw> wallyworld: have you confirmed with cmars about storing macaroons in accounts.yaml? if not, I'll send an email now
<axw> sorry, probably asked and answered already
<wallyworld> axw: we discussed it verbally in capetown and it's in the spec so i haven't sent email but feel free to double check
<axw> wallyworld: I think we're going to have to prompt the user to set an admin password after bootstrap
<axw> wallyworld: or I suppose we could just print out the random string...
<axw> wallyworld: but anyway, if the user has to input their password to login, they need to know what it is :)
<wallyworld> axw: we now would store that admin password in accounts.yam right
<axw> wallyworld: indeed. do we want to continue supporting password as well as macaroon?
<wallyworld> i think so in order to not have them lose admin access
<axw> wallyworld: I was thinking macaroon exclusively. this will help for restoring a backup too: after restoring, you plug your password back in to authenticate
<wallyworld> ah, wait sorry, got that wrong
<wallyworld> macaroon replaces password till it expireds
<axw> wallyworld: at which point you type it in manually, right? otherwise why use a macaroon at all
<wallyworld> i think looing up password in yaml is better than what we have now, we can iterate on making it easier
<wallyworld> yes, you'd type it in
<wallyworld> axw: here's part 1 of autoload-credentials http://reviews.vapour.ws/r/3954/ i'm off to soccer soon so no rush
<axw> wallyworld: will take a look a bit later on
<wallyworld> np
<dimitern> jam, dooferlad, voidspace,
<dimitern> standup
<voidspace> dimitern: omw
<dimitern> frobware, dooferlad, voidspace, here it is: http://paste.ubuntu.com/15186527/
<perrito666> morning
<perrito666> dimitern: ping?
<dimitern> perrito666, morning :)
<perrito666> morning, have a question, are you a go-amz member?
<perrito666> in github I mean
<dimitern> I used to be at least... maybe I still am
<perrito666> I have a lgtm https://github.com/go-amz/amz/pull/66 could you merge please?
<dimitern> perrito666, merged
<perrito666> thank you
<dimitern> voidspace, bootstrap error is due to spaces discovery indeed: "GET /MAAS/api/1.0/spaces/?op=list HTTP/1.1" 400 276 "-" "Go-http-client/1.1"
<dimitern> here's the line causing it https://github.com/juju/juju/compare/maas-spaces2#diff-9f2d224cfe3d5b5450772b51d95b625aR67
<dimitern> that would've been caught by a simple live bootstrap
<dooferlad> dimitern: Are we returning to https://plus.google.com/hangouts/_/canonical.com/juju-sapphire ?
<dimitern> dooferlad, I guess so, omw
<dooferlad> voidspace: we are starting if you are interested
<voidspace> dimitern: ok, thanks
<voidspace> "juju help" lists "juju init" as a command, but it isn't...
<voidspace> dimitern: how do you set the oauth key?
<voidspace> dimitern: I've done "auth-types: AAAA...." using auth-types instead of maas-oauth from the doc you suggested
<voidspace> dimitern: but that gets me an "unmarshall error" when I add the cloud
<voidspace> dimitern: i.e. what does your yaml look like to add-cloud please
<dimitern> voidspace, here's what I have in ~/.local/share/juju/clouds.yaml: http://paste.ubuntu.com/15186890/
<voidspace> dimitern: ah, a *literal* [oauth1]
<dimitern> :) that seemed odd to me as well, but the previous example was using 2 types
<voidspace> dimitern: where do you add the key then?
<voidspace> dimitern: now when I bootstrap it says "credentials not found"
<dimitern> voidspace, in ~/.local/share/juju/credentials.yaml
<voidspace> dimitern: oh...
<voidspace> dimitern: can you pastebin me the format for that too please :-)
<voidspace> dimitern: never mind, found it
<dimitern> voidspace, :) ok, just a sec
<voidspace> dimitern: in that same email
<dimitern> voidspace, yeah
<dimitern> it's all in there
<voidspace> dimitern: I appear to be bootstrapping now
<voidspace> dimitern: now testing the fix for the discovery bug
<voidspace> dimitern: http://reviews.vapour.ws/r/3955/ (but testing this first)
<dimitern> voidspace, reviewed
<dimitern> dooferlad, frobware, voidspace, so interfaceDoc -> linkLayerDoc, state.Interface -> state.LinkLayer ? (what?)
<dimitern> state.LinkLayerLink ? LinkLayerDevice ?
<dooferlad> dimitern: state.LinkLayer
<dimitern> maybe LinkLayerConfig
<dimitern> dooferlad, link layer whay?
<dimitern> what
<dooferlad> if that is what it returns...
<dimitern> I need a sensible singular name
<dooferlad> oh, I see.
<dooferlad> LinkLayerConfig seems reasonable
<dimitern> ok, then the doc can be linkLayerConfigDoc and the collection - linkLayerConfigsC
<dooferlad> yes, that sounds good
<voidspace> dimitern: https://github.com/juju/gomaasapi/pull/6
<voidspace> dimitern: if we merge this then we don't need an additional test in juju because the current code will fail with this revision of gomaasapi
<voidspace> dimitern: I will verify that - and obviously the juju PR needs to switch gomaasapi revision
<natefinch> Good got, it took 7 minutes for xchat to start up
<natefinch> s/got/god
<natefinch> alexisb: do we have a timeline for when the lxd team will get in a fix so Juju can use lxd?
<alexisb> natefinch, we discussed this morning, there is about 2 more days of development work from jam
<frobware> voidspace: adding you as assignee for master (for your current PR). Would be good to get in today as next beta build will be cut this thursday.
<frobware> voidspace: ah, scrap that. I suspect this change isn't on master anyway, correct?
<natefinch> alexisb: ok, didn't realize we were the ones responsible for the fix. That's unfortunate.
<alexisb> well it is a team effort
<alexisb> tych0 has helped us on juju core things
<natefinch> alexisb: that's true
<alexisb> the teams are working together
<natefinch> alexisb: well good, I think we could use some collaboration
<mgz> collaboration is for the weak?
 * natefinch considers using manual provider for local work
<alexisb> natefinch, I have been using vmaas
<alexisb> but I also have the old lxd installed :)
<alexisb> vmaas is working well for me
<natefinch> I have tried setting up vmaas a couple times and could never get it to work right...
<natefinch> honestly, all I need is a single machine to test my stuff against.  Hell, I could almost use manual provider against local machine, if I wasn't afraid it would hose my machine
<tych0> natefinch: alexisb: as in the launchpad bug + the old PR, i can cherry pick just the API fix if you want and make a PR
<alexisb> tych0, that would be awesome if you have time
<tych0> i'm not sure that ever needed to get rolled into a feature branch
<tych0> but i don't really know how your guys' process works :)
<tych0> sure, i'll post it this morning.
<alexisb> tych0, yea we need to do a better job of educated community contributors
<tych0> or just make the contribution process less complicated :)
<alexisb> both really
<alexisb> tych0, please do use the latest master
<tych0> yes, of course
<alexisb> mgz, would you be available for tych0 if he has questions
<tych0> should be pretty simple. what i really need is reviewers :)
<alexisb> I will be out for a but this morning and cherylj is currently transporting kiddo
<mgz> yeah, I can review too
<alexisb> mgz, thanks!
<alexisb> what tych0 is working on would hopefully unblock master
<natefinch> do we still support the manual provider?
<natefinch> do we have docs about how to use bootstrap?  Because, seriously, the error messages and help text are infuriating
<alexisb> jam  you still around today?
<cherylj> natefinch: yes, we still support manual provider.  Are you trying to use it with the 2.0 cloud credentials stuff?  (I haven't tried it with the new changes yet)
<perrito666> natefinch: I use vmaas creating from instructions cherylj passed me with some modifications
<dimitern> voidspace, sorry, I've missed your message earlier, but you've got LGTM on the gomaasapi PR
<natefinch> cherylj: yeah... I added a "manual" provider to my environments.yaml in the new juju data directory and bootstrap just says ""
<natefinch> er
<natefinch> "error: controller name and cloud name are required"
<natefinch> which is hugely unhelpful
<natefinch> given that it doesn't actually give you a way to specify controller name or cloud name
<cherylj> yeah the help needs to be updated
<natefinch> unless the help docs are wong
<natefinch> wrong
<mup> Bug #1456757 opened: TestAddressChange fails <ci> <go1.5> <intermittent-failure> <test-failure> <wily> <juju-core:Triaged> <juju-core 1.25:Triaged> <https://launchpad.net/bugs/1456757>
<cherylj> natefinch: try juju bootstrap my-manual-controller manual/<ip of manual machine>
<natefinch> so, the help docs are completely wrong?
<cherylj> natefinch: yes.  it's going to be addressed
<cherylj> natefinch: check the release notes for some better info
<natefinch> cherylj: I'm pretty aghast that we let major changes to commands land without changes to the help docs
<cherylj> natefinch: the docs team is leading an effort to improve the help text for all the commands
<cherylj> which is nice
<natefinch> cherylj: there's no excuse for us not updating our CLI help docs.
<tych0> mgz: ok, false alarm on the fire drill. i'm guessing jam has already done all of this, so i'd say let's wait for him to update lxd-container-type
<cherylj> natefinch: I understand your concern, and it does make a poor user experience.  But, the command changes barely made it in to beta1 as it was
<cherylj> too much to do, not enough people :(
<natefinch> sorry, i gotta run and pick up my daughter from school, she's evidently sick
<cherylj> yikes!
<natefinch> back in a bit
<mgz> tych0: okay
<jam> alexisb: I'm in and out
<alexisb> tych0, had some questions on how he could help out
<alexisb> jam, ^^
<jam> tych0: my work towards it is in github.com:jameinel/juju lxd-container-type-no-disk if you want to give that a poke
<jam> tych0: unfortunately it isn't just API issues
<jam> we need to get rid of the disk files
<jam> because we fixed our test suite to not allow you to write to $HOME during a test
<tych0> jam: what do you mean "get rid of the disk files"?
<jam> and that's where the LXD code was writing files
<ericsnow> katco, natefinch-afk: FYI, my patches landed (in the feature branch)
<tych0> oh, right
<tych0> jam: is it updated to use your new APIs that you made for LXD?
<jam> tych0: we should be using the EnvironConfig structure that we already have
<jam> tych0: I'm working through that, yes.
<tych0> jam: ok, sounds good. should i just leave you to it?
<jam> tych0: well, I only have a couple hours left today if you could give it some time (right now is dinner, and soon bedtime for my son)
<jam> good/bad is that "go test' in tools/lxdclient is running but segfaulting
<jam> so you should have some hints what needs to be fixed
<tych0> :)
<jam> tych0: did you get the first branch merged? (NewClientFromInfo )?
<tych0> jam: well, i took out your merge commit and rebased it
<tych0> just waiting for stgraber to come online and hit merge (or if you want to do the same, i can close mine and do that)
<jam> that's fine, as long as the change is there
<tych0> yeah, i'm +1. if you want to rebase instead of merge then I can merge it myself :)
<jam> I'm not a big fan of rebase, so if you want to do that part for me, feel free.
<tych0> yep, i did
<tych0> just waiting on stgraber to merge, and then we'll have both in lxd master
<tych0> and we can use a "real" hash for the juju deps file
<tych0> anyway, let me try and sort out a make file issue for a different project, then i'll give your branch a look
<jam> tych0: so the things I'm aware off
<jam> 1) we want to use ENvironConfig and set the client cert in there and have it passed into the lxdclient code
<jam> instead of having it generated
<jam> 2) we need to fix Architecture (which I think I've done)
<tych0> and then the ClientStatus thing too, i suppose?
<jam> 3) We need to fix provider/lxd/instance.go so that Addresses() makes a call back into lxdclient to get the addresses
<jam> rather than having them cached
<jam> my thought was that since both provider/lxd and container/lxd are going to need Addresses
<jam> then we should have the code to convert ClientStatus => network.Addresses in lxdclient
<tych0> makes sense
<katco> ericsnow: awesome
<katco> ericsnow: natefinch-afk: morning
<ericsnow> katco: \o
<natefinch> katco: morning
<natefinch> katco: this not having lcd or local provider is kind of screwing my productivity btw
<natefinch> s/lcd/lxd
<katco> natefinch: lxd is borked in our branch?
<natefinch> katco: not the provider, lxd itself changed
<natefinch> katco: thus breaking our provider
<katco> natefinch: oh, right... yeah. can you pin an older version?
<katco> natefinch: probably worth it to get that functionality back
<natefinch> katco: probably, but I have no idea how to do that (get some older version of the lxd deb...?)
<katco> natefinch: haven't done this in quite some time, but check out 3.10: http://www.debian.org/doc/manuals/apt-howto/ch-apt-get.en.html
<katco> natefinch: this looks even easier: http://blog.andrewbeacock.com/2007/03/how-to-install-specific-version-of.html
<perrito666> natefinch: version of ubuntu?
<natefinch> perrito666: wily
<perrito666> you have lxd from the ppa?
<natefinch> I think installing the older version with apt-get is worker
<natefinch> I don't know how to tell that
<dimitern> dooferlad, frobware, voidspace, here's the giant rename PR: http://reviews.vapour.ws/r/3959/ - please focus on the second commit, as even though I tried not to miss something, a few doc comments might need fixing
<sinzui> natefinch: katco  the "=x.y.*" technique works with non-superdeded packages. Other wise you need to find a ppa with the old paackages or download them directly from Lp
<perrito666> natefinch: I presume you have the ppa, just removing the ppa and deinstall-reinstall should workI am pretty sure lxd provider works without the ppa in willy
<dimitern> dooferlad, frobware, voidspace, that PR needs to land before I can continue
<dimitern> or whichever version of it gets approved
<dooferlad> dimitern: looking
<dimitern> dooferlad, cheers
<frobware> dimitern: dooferlad: will look in a bit
<dimitern> thanks
<dooferlad> dimitern: could you remind me what linkLayerDeviceDoc.Index is used for and why we don't expect it to change over a reboot?
<dimitern> dooferlad, it can change, we don't expect it to be immutable
<dooferlad> dimitern: thats OK then :-)
<dimitern> dooferlad, :) ta
<dooferlad> dimitern: what do we use it for?
<dooferlad> dimitern: and, I guess, where does it come from? If we are looking at the output of 'ip link' then I think we can use names instead of indexes for commands to update stuff
<dimitern> dooferlad, I think it's nice to have it, as it can be used for as an extra thing use along with the MAC for matching observed devices to stored-in-state devices
<dooferlad> dimitern: If that is all, I would drop it.
<dimitern> dooferlad, why so?
<dimitern> dooferlad, that argument applies to any of those fields basically
<dooferlad> dimitern: the MAC shouldn't change. One thing is enough.
<dimitern> dooferlad, I'm not sure that's guaranteed, but yeah
<dooferlad> dimitern: personally I would make all commands that interact with the network to work with names, but always check that the name still matches the MAC.
<dimitern> dooferlad, the model at least does not presume the macs are immutable
<dooferlad> dimitern: the MAC isn't immutable (Intel cards for example will let you change it), but the idea is they are fixed and globally unique.
<dimitern> dooferlad, yeah, or at least locally unique depending on the format
<dimitern> dooferlad, for virtual interfaces or e.g. bonds macs can absolutely change
<dimitern> but that's ok
<dooferlad> dimitern: I think it is fine for us to break if it changes at runtime. From the point of view of Ethernet, if the MAC changes it is just a different device on the same bit of wire.
<dimitern> dooferlad, agreed - a changed mac can be handled as a new device appearing with the same name
<dooferlad> dimitern: absolutely what I was writing.
<dimitern> dooferlad, those cases will be handled by the update ops
<dimitern> dooferlad, i.e. "merge as best as you can what you already know's there on the machine with what we've just observed"
<dooferlad> dimitern: sounds good.
<voidspace> dimitern: maas space fetching PR updated, manually tested, plus tested that the tests fail without the new gomaasapi revision but pass with it
<voidspace> dimitern: http://reviews.vapour.ws/r/3955/diff/#
<dimitern> voidspace, ok, but I see no changes to add a test or bump dependencies.tsv ?
<voidspace> dimitern: dammit, there was
<voidspace> I don't see it either
<voidspace> think I reverted it
<dimitern> looks like it
<voidspace> dimitern: it's there now
<katco> natefinch: hey sorry, did you get it figured out?
<xnox> calendar: hi, could you please review https://github.com/juju/juju/pull/4480/files ?
<xnox> hm nick not found.
<dimitern> voidspace, yeah, I can see the deps bump, but please add a quick test as well
<xnox> dear "On-call reviewer" -> where is the calendar =)))))
<voidspace> dimitern: as I commented before - it doesn't need one
<voidspace> dimitern: if you run the tests with the old code but the new gomaasapi then tests fail with bad request
<voidspace> dimitern: there's a new test for that code path in gomaasapi though
<katco> ericsnow: hey got time for a quick chat?
<ericsnow> katco: sure
<dimitern> voidspace, hmm, ok then
<katco> ericsnow: moonstone
<dimitern> voidspace, makes sense, let's get it in
<voidspace> dimitern: cool, thanks
<dooferlad> xnox: the calendar is, I think, private to the Canonical Juju team. Todays reviewers are cherylj and mattyw.
<natefinch> katco: yeah pretty much.... perrito666 helped me clean out the PPA version, the regular version from wily seems to work fine
<voidspace> dimitern: if you need convincing, bump the gomaasapi revision on maas-spaces2 and run the maas provider tests
<dimitern> voidspace, yeah, I did that :)
<voidspace> :-)
<xnox> dooferlad, thanks!
<xnox> cherylj, mattyw: please review https://github.com/juju/juju/pull/4480/files
<mattyw> xnox, I'm around if you want me to take a look at something
<mattyw> xnox, will do
<katco> natefinch: hey can you hop into moonstone rq?
<natefinch> katco: sure
<natefinch> huzzah for having LXD back and working
<cherylj> hmm, I think tip of master is broken.
<cherylj> ah, it doesn't like it when I switch to a different controller while it's bootstrapping
<katco> cherylj: pushing the boundaries!
<cherylj> yeah
<cherylj> and finding bugs!
<cherylj> check out this error:  2016-02-24 16:08:28 ERROR cmd supercommand.go:448 getting model details: model maas:admin@local:amazon not found
<cherylj> I was bootstrapping amazon and switched to my already bootstrapped maas while it was working
<dimitern> dooferlad, thanks for the review - Index dropped as discussed
<dimitern> voidspace, frobware, any objections to landing http://reviews.vapour.ws/r/3959/ ?
<natefinch> katco: given that we have meetings scheduled for 5am-6am and 3:30pm-7pm tomorrow, do you think I could take a couple hours off before the 3:30 to spend with my kids?  I know the 3:30 might not run that long, but I can't guarantee that, and 7pm is the kids' bedtime.
<katco> natefinch: sec in a meeting
<voidspace> dimitern: no objections from me
<xnox> mattyw, also https://github.com/juju/xml/pull/5
<dimitern> voidspace, cheers
<natefinch> gonna go to lunch a little early today since the kids are all home sick
<natefinch> back in an hour
<voidspace> frobware: dooferlad: I need this fix in gomaasapi https://github.com/juju/gomaasapi/pull/7
<dooferlad> voidspace: +1
<voidspace> dooferlad: thanks
<katco> natefinch: hey
<kilty> I'm receiving the errors shown in this pastebin when bootstrapping from 2.0 beta1: http://pastebin.com/pCYg4YnE  Any ideas?
<katco> kilty: that looks like the new signed streams stuff by anastasiamac
<katco> cherylj: do you know much about this? ^^
<natefinch> katco: howdy
<katco> natefinch: hey
<katco> natefinch: re. tomorrow's schedule
<mgz> looks like an ugly variation on the normal private cloud thing?
<katco> natefinch: how have the core team meetings been going? what is discussed? i haven't attended in quite some time
<natefinch> katco: they're pretty hit or miss.  Sometimes almost no one shows up, or we only talk for 10 minutes, sometimes we talk the full hour, like what happened  last week.
<katco> natefinch: i'd say skip the one for that tz and aim to go to the one on the 3rd
<katco> natefinch: that way your day isn't terribly long
<natefinch> katco: sounds like a plan
<tych0> jam: hi, so i fixed the seg fault and implemented Addresses()
<tych0> (it's on my github gh:tych0/juju with the same branch name)
<tych0> as well as a few other little nits
<tych0> but i'm trying to understand what you mean by EnvironConfig generating the certs, and I'm a bit lost
<jam> tych0: hi. I'm about to head to bed, but I'll try to point you in the right way. Thanks for working on it, btw.
<tych0> jam: np. any pointers are good pointers, as long as they're not null :)
<jam> so every "Provider" has an EnvironConfig which is where we put things like authorized-keys/user/password/hostname/auth-url, etc.
<jam> There are a bunch of common items in https://github.com/jameinel/juju/blob/master/environs/config/config.go
<jam> the LXD one should be an extension of the base one: https://github.com/jameinel/juju/blob/master/provider/lxd/config.go
<jam> for comparison I tend to look at the openstack one https://github.com/jameinel/juju/blob/master/provider/openstack/config.go
<tych0> jam: oh, i see
<jam> tych0: but the general idea is that we generate the LXD client cert during bootstrap
<jam> and save it in the environ config under a particular key
<tych0> jam: right, i guess the config gets initialized during bootstrap?
<jam> and we'll keep passing that information in
<jam> right
<tych0> sounds good
<jam> the only bit I'm not 100% sure on is if we want to save the server's cert so that we can ensure the server hasn't changed.
<jam> for LXD provider, we can do that just fine
<jam> for container/LXD each machine is going to have a different one.
<jam> so we'll have to think a bit more carefully there.
<tych0> jam: well, i don't think we'll even have to bother for container
<tych0> jam: because we can always talk over the unix socket
<jam> ah right
<tych0> jam: which won't require cert auth at all
<jam> no certs,
<tych0> so i think just the server's cert, then?
<jam> and if it wants a cert for some weird nesting thing, it can get it out of the socket.
<tych0> yep
<tych0> but hopefully at least initially it won't :)
<jam> yeah, we shouldn't to start
<jam> tych0: thanks again for picking up the work, I'll grab your branch in the morning if it hasn't already been landed. :)
<tych0> jam: sure, sounds good. i should just pr this to lxd-container-type?
<jam> tych0: yes
<tych0> jam: will do, thanks
<jam> tych0: you'll also want to update dependencies.tsv
<jam> so that it includes the latest lxc/lxd code
<tych0> jam: yep, i did that already
<tych0> acutally i'm going to do it again though, and export a few more functions
<tych0> to share some more code with LXD
<jam> tych0: sgtm. I'd like to have less code on our wrapper when it makes sense.
<natefinch> I need a gofmt replacement that turns a.something := foo   into a.something = foo  ... you know what I mean, just fix it.
<cherylj> kilty, katco did you get an answer on the streams question yet?  Looks like not...
<cherylj> kilty, katco the index2.sjson message is a known issue where juju is looking in the wrong place for image streams first, but will fall back to the right place.
<cherylj> kilty: I saw a message similar to the "ERROR index file has no data for cloud" message you posted when messing with the rackspace provider
<cherylj> kilty: I was able to work around it in that case by setting the image-stream to "released" rather than "daily".
<cherylj> kilty: i.e.  juju bootstrap jujucontroller dr --config image-stream="released"
<katco> cherylj: sorry was otp, not did not get a definitive answer for kilty afaik
<katco> cherylj: i think mgz started to weigh in
<mgz> yeah, from the error it looked like a private openstack
<mgz> which isn't going to have image streams at our public locations anyway
<natefinch> katco, ericsnow: review up when you have time: http://reviews.vapour.ws/r/3949/
<cherylj> katco: ah, ok.  just ftr - the bug for that index2 message is bug #1547891
<mup> Bug #1547891: Juju searches for index2.sjson in image streams <streams> <juju-core:Triaged> <https://launchpad.net/bugs/1547891>
<ericsnow> natefinch: k
<cherylj> mgz: yeah, that's what I was thinking too.
<mgz> so I suspect some needed config didn't get brought over from 1.x to 2.0
<katco> natefinch: TAL
<katco> cherylj: ta
<kilty> cherylj: thanks for the suggestion, though I got the same error
<kilty> mgz: correct, it is a private openstack
<cherylj> kilty: I think that message may indicate that it cannot find an appropriate image to use.  What images do you have available?
<cherylj> (it's a pretty crummy message, though, doesn't tell you how to fix anything)
<kilty> image like like 14.04?
<cherylj> yes
<cherylj> and did this work with 1.x?
<kilty> yea I have 14.04 and 15.10
<kilty> no we couldn't get 1.x to work so we were hoping 2.0 would fix everything =)
<kilty> 1.x actually gave the same error: "ERROR index file has no data for cloud {RegionOne http://192.168.4.11:5000/v2.0} not found"
<natefinch> ericsnow: just saw your alignStoreResources method.... are you sure that's correct?  What happens when a new version of the charm gets pushed out and it has a different number of resources?
<cherylj> ah, ok.    How do you have your images indexed?
<cherylj> kilty ^^
<mgz> kilty: read https://jujucharms.com/docs/1.25/howto-privatecloud
<cherylj> hey, that's handy, mgz
<ericsnow> natefinch: for a given charm revision the same set of resource names will be associated, though the resource *details* (including revision) may be different, hence the number of resources will remain the same
<mgz> kilty: that gives the background, all you really need is to tell juju about the images you put in glance, which isn't too painful
<mgz> but I'm not quite sure how the config has changed in 2.0
<ericsnow> natefinch: and service's are tied to a charm revision
<natefinch> ericsnow: ahh, ok, yeah, so the number of resources can't change unless the charm revision changes, in which case, we'll download the new resource data... though I can imagine this breaking after a charm-upgrade, since we don't remove old resources (do we?)
<ericsnow> natefinch: if a service switches to use a different charm revision then the resources will be synced up
<ericsnow> natefinch: yep
<natefinch> ericsnow: ahh, awesome. Nevermind then :)
<kilty> mgz, cherylj: well I'll go through that page first and see where we end up, thanks!
<ericsnow> natefinch: glad you asked
<natefinch> ericsnow: still makes me sad that updates returns an error that will almost always be nil unless we have a bug, though
<mgz> kilty: all you should need is the `juju metadata generate-image` bits and set image-metadata-url
<ericsnow> natefinch: c'est la vie :)
<mgz> cherylj: how do we actually set image-metadata-url in a 2.0 world...
<kilty> mgz: i didn't do the metadata generation for the 2.0 setup (it wasn't in the wiki I found)
<natefinch> ericsnow: I don't know... that'll break the juju list-resources command entirely if you ever get into that state... I wonder if it's better to just log an error or something.. I dunno.
<ericsnow> natefinch: like you said, an error indicates something went unexpectedly wrong (e.g. data mangled across API), meaning the output from list-resources would likely be invalid anyway
<natefinch> ericsnow: yeah, I guess you're right...
<natefinch> ericsnow: damn your validation, now my test values need to actually be legitimate ;)
<ericsnow> natefinch: mwahaha
<natefinch> man I wish I didn't have to give a controller name... if I don't specify, just make it the same as the provider name, geez
<perrito666> I believe the spec had that
<kilty> cherylj: I do get some possibly prohibitive errors when generating metadata: http://pastebin.com/xzVwNLKV
<natefinch> I should really learn to just double whatever expected time it'll take for tasks that involve the uniter
<natefinch> katco: does work done on Friday count for this iteration, or are we now switching to iterations starting on Friday, given that our retros will likely always be Thursdays now?
<katco> natefinch: that's a good question. for this iteration let's count friday
<katco> natefinch: and then we can revisit tomorrow for the following iteration
<mgz> kilty: supply `-m NAME_OF_MODEL_CFG_THING`?
<kilty> mgz: I'm not entirely sure what model is, and googling 'juju model' shows me strange things
<mgz> it's what used to be an environment before we decided to confuse everyone
<kilty> oh so I still need the environment.cfg
<kilty> er .yaml
<natefinch> kilty: yeah, it lives under $XDG_DATA_HOME now... which ends up defaulting to ~/.local/share/juju
<katco> ericsnow: natefinch: meet in ~9 for testing discussions?
<ericsnow> katco: k
<natefinch> katco: yep
<katco> ericsnow: natefinch: in moonstone
<jose> rick_h_: hey, did you get to put your idea on the wiki?
<natefinch> katco: oops coming
<rick_h_> jose: sorry no, had wiki issues and meant to go back to it
<jose> no worries
<perrito666> mm github got issue templates, we should make one for our bugs since we cannot make a magic redirection to launchpad
<perrito666> or even better, we should make one that says "Please report this in launchpad"
<perrito666> table tests produce an excessive logging :(
<thumper> morning flks
<thumper> perrito666: that they do
<thumper> especially if they are uniter tests
 * thumper goes to make another coffee
<ericsnow> katco, wallyworld, natefinch: I remembered
<ericsnow> katco, wallyworld, natefinch: the revision updater polls the charm store unauthorized
<ericsnow> katco, wallyworld, natefinch: so charms that require authorization are ignored
<ericsnow> katco, wallyworld, natefinch: that surprised me
<wallyworld> ericsnow: when that was written, there were no private charms
<ericsnow> katco, wallyworld, natefinch: so does the revision updater need to be updated?
<wallyworld> ericsnow: yeah, think so
<ericsnow> wallyworld: yuck
<wallyworld> ericsnow: but we can leave it for now
<ericsnow> wallyworld: that means keeping a macaroon in state and having some way of keeping it alive (or reviving it if it expires)
<ericsnow> wallyworld: I'm glad to punt on it :)
<ericsnow> wallyworld: as long as that means doing the same for resources :)
<wallyworld> ericsnow: worth taking a look to see what's needed
<ericsnow> wallyworld: k
<ericsnow> wallyworld: who on core is most familiar with the support for private charms?
<wallyworld> ericsnow: but right now, probably not the most important thing
<wallyworld> ericsnow: casey etc
<ericsnow> wallyworld: k
<thumper> menn0: ping
<menn0> thumper: hi
<thumper> menn0: state/constraints.go, I was removing extra st.docId calls
<thumper> menn0: setConstraintsOp replaces the doc
<thumper> menn0: will the model-uuid get set automatically?
<menn0> maybe :)
 * menn0 checks the code
<thumper> ah poo...
<thumper> constraints doc is one of those documents that doesn't embed any form of key
<thumper> so you can't just read the entire collection using a slice of docs...
<thumper> f**xor
<menn0> thumper: the model-uuid will get set automatically
<thumper> need to do the same thing as settings and read as bson.M
<thumper> menn0: cool, I'm just removing them as I go
<menn0> see multiModelRunner.mungeBsonDUpdate() in state/txns.go
<thumper> k
<menn0> thumper: yeah, doc structs with the _id sucks
<thumper> you mean without?
<menn0> without :)
<menn0> thumper: I just found the source of those panics in the apiserver. it's basically what I thought it was yesterday but even more subtle
<thumper> oh
<thumper> fixable?
<menn0> yep I have a fix. there's a few parts to it.
<menn0> basically what was happening is that the goroutine that the server infrastructure had spun up to handle a /logsink API request was only just starting when the apiserver was told to shut down. even incrementing the apiserver's WaitGroup at the top of logsink request handler wasn't enough because the goroutine hadn't gotten to that part yet, so the apiserver still thought all requests were done even though one was about to start up.
<menn0> so the apiserver closed it's State and then the handler got to try and use it and boom
<menn0> i've got a clean fix
<menn0> but it can only be safely applied to API handlers that pay attention to the server's tomb. if they could run for a long time without checking the tomb then the fix could block the apiserver from shutting down.
<katco> ericsnow: ah yeah, that. cmars just sent me an email that i think assures us that he'll be keeping us in the loop
<ericsnow> katco: yeah, it's good because we'll have the same concerns with resources
<katco> ericsnow: just forwarded the email... haven't read through fully
<ericsnow> katco: thanks
<katco> natefinch: hey, went ahead and assigned the "upgrade-charm --resources" card to you. we should talk about expected completion. week from today sound ok? 3/2?
<katco> natefinch: i'll send an email in case you miss this ping
<thumper> menn0: but blocking the apiserver from shutting down is better than panicing no?
<menn0> thumper: not if it blocks the apiserver indefinitely
<thumper> menn0: well, true that
<menn0> thumper: the best solution is to not block *and* not panic
<menn0> thumper: and when I'm done that will be the case for the /log and /logsink endpoints
<menn0> thumper: there will still be the chance of panics in the charm and tools up/download etc
<menn0> thumper: but they've always been there
<menn0> thumper: and the panic is handled by the server infrastructure
<menn0> thumper: it doesn't take down the process
<thumper> k
 * perrito666 finishes addressing 50 comments on a commit and falls asleep on the kb
<perrito666> wallyworld: sorry I am pretty sure my last answer just blowed a vein in your forehead
<wallyworld> perrito666: already blown
<perrito666> wallyworld: https://dylansfilmandtv.files.wordpress.com/2013/07/149968-daria-mr-demartino.jpg
<wallyworld> yep
<perrito666> wallyworld: standup or no standup today?
<wallyworld> perrito666: in meeting, we can talk if this one finishes before next one
<perrito666> just asking to know if I can EOD or not
<mgz> no rest for the wkd
<perrito666> says the guy that lives on the country where its the middle of the night
<mgz> hey, it's not quite midnight yet
<wallyworld> axw: perrito666: anastasiamac: let's do standup
<axw> wallyworld: brt, can't stay too long tho
<perrito666> mgz: hey testing something I think I just created a joyent controller in CIs account but given that my test failed I cannot delete it, could you via web interface?
<mgz> perrito666: with what name?
<wallyworld> cmars: can i schedule a meeting with you for this time tomorrow regarding login?
<mgz> perrito666: consoles.txt in cloud-city has all our logins btw
<cmars> wallyworld, definitely
<wallyworld> cmars: ty, will do invite soon
<mgz> perrito666: I don't see anything recent, just cwr-joyent from yesterday?
<perrito666> mgz: great, then it doesnt even creates the thing
<mgz> axw: thanks for fixing the bootstrap ssh issue btw
<axw> mgz: nps
<anastasiamac> cmars: menn0: could u plz have a look at http://reviews.vapour.ws/r/3958/ and/or http://reviews.vapour.ws/r/3957/
#juju-dev 2016-02-25
<mup> Bug #1549545 opened: Bundle deploys fail at lxc-start when bridge br-eth1 is created <ci> <deploy> <maas-provider> <test-failure> <juju-core:New> <https://launchpad.net/bugs/1549545>
<natefinch> katco, ericsnow:  the PR for the missing API field: http://reviews.vapour.ws/r/3961/
<ericsnow> natefinch: LGTM
<natefinch> ericsnow: nice, thanks!
<mup> Bug #1549545 changed: Bundle deploys fail at lxc-start when bridge br-eth1 is created <ci> <deploy> <maas-provider> <test-failure> <juju-core:New> <https://launchpad.net/bugs/1549545>
<mup> Bug #1549545 opened: Bundle deploys fail at lxc-start when bridge br-eth1 is created <ci> <deploy> <maas-provider> <test-failure> <juju-core:New> <https://launchpad.net/bugs/1549545>
<natefinch> ericsnow: you still around?
<wallyworld> axw: adding the restriction that controller name must exist in SetController() causes a lot of test failures \o/ i'm going through and fixing those
<axw> wallyworld: hm :/  do you agree that it should fail though?
<wallyworld> axw: nope :-)
<wallyworld> yes
<wallyworld> sorry, i meant yes
<axw> lol
<axw> the other nope
<wallyworld> nope that we shound't fail
<axw> ok
<wallyworld> the fact that we never checked needs to be fixed
<tych0> jam: https://github.com/juju/juju/pull/4526 is what i've got for now
<tych0> it seems to bootstrap and deploy stuff
<tych0> jam: I think (?) it should fix most of your concerns
<menn0> wallyworld: is there any documentation on how to actually bootstrap at the moment
<menn0> wallyworld: with lxd not working i'm trying aws
<wallyworld> menn0: the release notes are very comprehensive :-)
<menn0> wallyworld: but it keeps trying to use the EC2 environment variables instead of what's in credentials.yaml
<wallyworld> where is credentials.yaml  located?
<wallyworld> can you pastebin it?
<menn0> wallyworld: I checked the release notes first. They only say that bootstrap and credentials has changed with no details
<menn0> juju help bootstrap is also no help
 * menn0 gets pastes 
 * menn0 pastes even
<wallyworld> menn0: the release notes have an example credentials.yaml file, what ones are you looking at?
<menn0> beta1
<wallyworld> let me check them
<menn0> wallyworld: ok I see
<menn0> it's further down
<wallyworld> yeah, there's a whole essay on the new bootstrap stuff
<wallyworld> i have had it confirmed that if you follow the directions it does all work :-)
<wallyworld> but maybe some more consice getting started docs would have helped
<menn0> wallyworld: http://paste.ubuntu.com/15193666/
<menn0> that's what I get
<menn0> the credentials.yaml looks right to me
<menn0> (I've redacted the secret bits obviously)
<wallyworld> looks ok at first glance, i'll dig in a bit
 * menn0 wonders if it works for wallyworld because he has $AWE_SECRET_ACCESS_KEY set
<menn0> $AWS... even
<wallyworld> maybe, but it was tested without i am almost sure, but not 100%
<wallyworld> menn0: you are missing the credentials:
<wallyworld> at the top of the yaml
<menn0> wallyworld: that would do it :)
<wallyworld> let me know if it still is broken
<menn0> wallyworld: looking better
<wallyworld> \o/
<menn0> wallyworld: thanks for your help
<wallyworld> np
<menn0> wallyworld: I think the client should emit a useful error when credentials.yaml doesn't start with a credentials section
<menn0> wallyworld: shall I file a bug about it?
<menn0> I suspect I won't be the only one making this mistake
<wallyworld> menn0: agree, but we also have several other yaml files we omit crappy errors for. i'd like to tackle that improvement wholistically
<wallyworld> and if it's not that error, there could be 100s of other syntactical issues
<wallyworld> on the whole, juju's error reporting has a lot to answer for
<menn0> wallyworld: in this case the YAML was syntactically correct. The first section just wasn't what the client expects.
<wallyworld> fair point. but the same could happen in any yaml file juju likes to read. the user should be editing such files. beta2/3/4 will gain CLI to do that work. go ahead and file a bug if you want though
<wallyworld> shouldn't
<menn0> ok, if the user won't be touching the file soon, then I won't bother with the bug
<wallyworld> "soon" :-)
<wallyworld> axw: could you ptal at http://reviews.vapour.ws/r/3954/
<axw> wallyworld: looking
<wallyworld> ta
<axw> wallyworld: done
<wallyworld> ta
<wallyworld> axw: damn, that plural is invisible to me :-/ will fix. need glasses
<wallyworld> part 2 will get into the workflow proper, multiple clouds etc
<wallyworld> just wanted to get the skelton for part 1
<axw> wallyworld: thanks. ok, sounds good
<menn0> axw: would you mind taking a look at this one please? http://reviews.vapour.ws/r/3964/
<axw> menn0: sure
<menn0> axw: thansk
<axw> menn0: done
<menn0> axw: thanks
<menn0> axw: good catch with the missing Done call
<wallyworld> menn0: where's thumper? anyways, why does juju create-model use creds/secrets for ec2 and openstack? i thought all hosted models were restricted to using the same creds as the original controller? is that not the case?
<wallyworld> is ec2 nd openstack special cased?
<menn0> wallyworld: thumper is on his way to christchurch. he's off tomorrow for a wedding up here.
<wallyworld> and i thought he was slackong off
<wallyworld> we're supposed to have a meeting, i wonder when he ws going to tell me
<menn0> wallyworld: I don't know about the create-model creds situation. thumper did that work.
<wallyworld> damn, ok
<menn0> such a slacker
<wallyworld> menn0: because if we do need to supply creds, we'll need to migrate that to crdentials.yaml etc
<menn0> wallyworld: off memory, I thought that it was possible to use different creds for different models on the same controller
<menn0> but i'm fairly vague about that
<wallyworld> ok, np, we'll need to look into it
<axw> we should surely default to the controller's creds though
<wallyworld> yes
<wallyworld> you'd hope so
<wallyworld> but the cli has a comment that we look in supplied config vars for new creds
<wallyworld> i didn't know we did that
<axw> wallyworld: yep. and some providers will fail if you don't supply them, some don't
<menn0> wallyworld, axw: think about the possibility of hosted envs being "owned" by completely unrelated parties
<menn0> you'd want different creds then
<wallyworld> ah yes. true
<wallyworld> same provider, different creds
<axw> menn0: sure, I think we should support it
<axw> menn0: just not require it
<menn0> it might even be "unsafe" to default to the controller's creds
<wallyworld> axw: i think we'd want this for next beta, i'll try and get to it tomorrow, should be small change
<menn0> not sure
<menn0> wallyworld, axw: could one of you look at this one please? http://reviews.vapour.ws/r/3965/
<axw> I'll look
<menn0> fixes to apiserver panics that several people have been observing during test runs
<wallyworld> sure
<menn0> (including me)
<menn0> axw, wallyworld: just one of you is fine :)
<axw> menn0: yes, me too - thank you!
<wallyworld> and me!
<menn0> axw, wallyworld: the novela at the top explains it, but the problem has been there forever I think
<menn0> axw, wallyworld: it's just that timings for worker startup and shutdown have changed due to the dep engine
<wallyworld> menn0: i think it has, i don't recalls those /charm or /tools or /backups etc endpoints being tracked
<menn0> axw, wallyworld: we're still not in good shape yet for the other streaming style APIs but at least /logsink and /log are fixed
<menn0>  /logsink is in use all the time
<wallyworld> got to start somewhere
<menn0> and now the pieces are there to do the others
 * menn0 spent most of yesterday and today on this one when he should have been doing other things
<menn0> thought it was due to my changes
<menn0> but it wasn't
 * menn0 creates a ticket about the others
<wallyworld> menn0: pr looks ok but my brain has not delved into any possible subtle breakages
<menn0> wallyworld: i've done quite a bit of manual testing and i'm pretty sure it's right, but I understand your concern
<menn0> axw: given wallyworld is a bit uncertain could you take a look too please?
<wallyworld> menn0: +1 from me fwiw if you've tested manually
<axw> menn0: was already looking
<axw> still looking
<menn0> axw, wallyworld: thanks both of you
<wallyworld> awesome that you fixed it
<axw> menn0: LGTM
<menn0> axw: cheers
<menn0> axw: your idea makes sense and is preferable to what i've done if I can make it work
<menn0> trying now
<axw> menn0: ok, thanks
<menn0> axw: yeah, that's heaps better
<menn0> axw: just making sure it works now
<axw> menn0: cool :)
<menn0> are
<menn0> wallyworld: is this error expected?
<menn0> $ juju bootstrap menn0 aws --config ~/canonical/juju-dev.yaml --upload-tools
<menn0> Creating Juju controller "local.menn0" on aws/us-west-2
<menn0> ERROR streams/v1/index2.sjson not accessed, actual error: invalid URL "https://streams.canonical.com/juju/images/releases/streams/v1/index2.sjson" not found
<wallyworld> menn0: yeah
<menn0> there's a few other similar ones
<wallyworld> it needs to be suppressed
<menn0> due to upload-tools?
<wallyworld> it's because simplestreams searches everywhere and logs what it can't find
<wallyworld> should be debug or trace
<wallyworld> axw: so far, aws and google both support different named credentials having their own default region rather than a single global default :-(
<wallyworld> might need to revisit the model
<axw> wallyworld: docs?
<wallyworld> axw: for aws, i'd have to look up docs again, i'm judt looking at what's in my ~/.aws directory. there's a config and a credentials file. config has region per user, credentials has credentials per user
<axw> wallyworld: isn't that just the default for each though?
<wallyworld> yes, but we don't model it that way
<wallyworld> we have map[string]Credential
<wallyworld> and region is a outside that map
<wallyworld> i'll leave it for now
<axw> wallyworld: so you're suggesting DefaultRegion should be part of Credential, rather than CloudCredential?
<wallyworld> axw: yeah i think so
<wallyworld> or at least an override
<wallyworld> like we do with endpoints in cloud.yaml
<axw> wallyworld: I'd wait until someone asks for it. I think for now we should take whatever's in [default] and use that where we have DefaultRegion today
<wallyworld> sgtm, but we can easily model it if needed
<axw> should be easy to have an override later
<axw> yep
<wallyworld> menn0: can you recall the help function to fix windows user names?
<axw> wallyworld: no rush since it can't land yet, but admin bootstrap model changes: https://github.com/juju/juju/pull/4530
<axw> wallyworld: I'll look at the next bit, creating the secondary model
<wallyworld> axw: awesome, ty, will look after soccer, finishing up part2 of detect credentials
<anastasiamac> dimitern: o/
<dimitern> anastasiamac, hey there
<fwereade_> dimitern, axw: do either of you have recent insight into the `if insideLXC` handling in MachineAgent.uninstallAgent?
<fwereade_> dimitern, axw: naively, ISTM that it's happening too late -- that we should do it before setting the machine to dead, not after
<fwereade_> dimitern, axw: thoughts?
<fwereade_> dimitern, axw: (because, once we're dead, it's a matter of luck whether or not that code gets to run before the responsible provisioner nukes the whole container)
<dimitern> fwereade_, I have to look at the code - after standup though
<dimitern> ah no standup today
<dooferlad> dimitern, anastasiamac, frobware, voidspace: (and others) meeting?
<dimitern> dooferlad, thanks for the review btw; voidspace, frobware - I'd appreciate if you have a look as well: http://reviews.vapour.ws/r/3969/
<axw> fwereade_: indeed, we should do it before setting Dead. pretty sure I wrote that - sorry
 * dimitern whew... refcounts finally working
<dimitern> note to self: $ge != $gte and bson.D{{"$gte", bson.D{{"field", 0}}}} != bson.D{{"field", bson.D{{"$gte", 0}}}}
<dimitern> dooferlad, ping
<dooferlad> dimitern: pong
<dimitern> dooferlad, I'm not quite sure what do you mean by this comment: I think if you are calling the above function addLink...AndEnsureAllAdded then you shouldn't need a check after it.
<dimitern> dooferlad, there's no check there
<dooferlad> dimitern: the line has c.Check(children, gc.HasLen, len(childrenNames))
<dimitern> dooferlad, ah
<dooferlad> dimitern: that one seems unnecessary if you have already ensured that all are added
<dimitern> dooferlad, I got you - yeah, it's not needed
<dooferlad> np
<dimitern> will drop it
<fwereade_> axw, no worries, just checking
<fwereade_> axw, I don't see how to address that in the near term but I'll leave a TODO
<axw> fwereade_: nobody has implemented storage support for the LXD provider yet, so it's not actually doing anything at the moment. hopefully someone will fix that soon though...
<axw> fix/implement
<axw> we had it for local, so there's a small gap there now
<fwereade_> axw, also, correct me if I'm wrong: ISTM that that code is the only reason we actually "need" to run the uninstall logic in non-manual-provider cases
<axw> fwereade_: that is correct
<fwereade_> axw, and hence the only reason for various workers to write the uninstall file when they're "sure" that ErrTerminateAgent is "really meant"
<fwereade_> axw, ...so, if the lxd bits are currently meaningless... can I maybe drop the uninstall-file-writing entirely, and leave it to the discretion of the manual provider?
<axw> fwereade_: it's almost certainly going to be needed again for lxd, so I'd prefer not to.. unless it's actively getting in your way?
<fwereade_> axw, I think I've come to understand what's going on well enough that it's not any more
<fwereade_> axw, so I'm quite happy not to take on ripping it out :)
<fwereade_> axw, but I must say it has sharp edges ;p
<dimitern> dooferlad, voidspace, here's the next PR in line: http://reviews.vapour.ws/r/3972/ please have a look when you can
 * dimitern lunches
<anastasiamac> dooferlad: sorry for missing team meeting. it falls at 8pm my time and with 3 kids, some days, it's the busiest time of the day \o/ i'll try next time but trust that u've had plenty gerat meeting :D
<anastasiamac> s/plenty gerat/pretty great
<mgz> gerat is less offensive than "u've" :P
<dimitern> the only similar word that comes to mind is german - Geraet
<mgz> anastasiamac: meeting was good, just us euros hangin' out
<anastasiamac> mgz: it's great to hear that it's such a tight group \o/
<anastasiamac> mgz: is there an awesome way to "predict" (=deduce?) what branch will run in CI next... ?..
<mgz> anastasiamac: generally not because we're always bumping things around on request
<mgz> atm, master will run next
<anastasiamac> k... so what incantation did u use to figure that out?
<mgz> in this case, `crontab -e` as jenkins on the master
<anastasiamac> :D
<dimitern> dooferlad, voidspace, rebased http://reviews.vapour.ws/r/3972/ onto maas-spaces2 after its prereq has landed to clean up the diff
<mgz> anastasiamac: when overrides are not in place, it picks the branch in the github.com/juju/juju repo which has oldest untested changes
<perrito666> bbl
<bogdanteleaga> do we have something that translates back and forth between unit-<x>-0 and <x>/0?
<dimitern> bogdanteleaga, check names.ParseUnitTag
<bogdanteleaga> dimitern, thanks, looks promising
<mup> Bug #1548813 opened: maas-spaces2 bootstrap failure unrecognised signature  <ci> <maas-provider> <juju-core:In Progress by dimitern> <juju-core maas-spaces:Fix Committed by mfoord> <https://launchpad.net/bugs/1548813>
<frobware> huzzah! I have an internet access again \?/
<dimitern> frobware, hey! :) welcome back then
<frobware> dimitern: it's weird to have a mobile either. I went to a local coffee shop - it worked there for about 20 mins
<frobware> s/to have/to not have
<dimitern> ah :)
<dimitern> frobware, I was wondering where did you go
<mup> Bug #1548813 changed: maas-spaces2 bootstrap failure unrecognised signature  <ci> <maas-provider> <juju-core:In Progress by dimitern> <juju-core maas-spaces:Fix Committed by mfoord> <https://launchpad.net/bugs/1548813>
<frobware> dimitern: generally it's considered a bad sign if you can't get to BBC Radio 4 - implies the world had ended...
<dimitern> :D
<mgz> isn't that one of the triggers for us launching nukes?
<frobware> mgz: that's the one. I was close this morning, just couldn't get a +1.
<mgz> no woman's hour? moscow is going down!
<frobware> dimitern: did I miss anything from standup?
<frobware> mgz: perhaps it was coincidental with ofcom ruling that BT did not have a monopoly.
<dimitern> frobware, we swapped standup for the weekly team call, which was almost the same thing as standup today
<dimitern> frobware, you missed nothing important
<dimitern> well, apart from the next few PRs of mine :)
<frobware> dimitern: I was surprised you cherry-picked voidspace's change into master if it's not actually broken there.
<dimitern> frobware, it's not but since master uses older gomaasapi, I can't reliably test the fix for the br-eth1 issue I picked upgodeps
<dimitern> ..while things got rather quiet
<frobware> dimitern: this still need review? lldb?
<frobware> dimitern: this still need review? http://reviews.vapour.ws/r/3969/
<dimitern> frobware, this does - http://reviews.vapour.ws/r/3972/
<frobware> nope, looks like I missed that by 48 mins too
<mup> Bug #1548813 opened: maas-spaces2 bootstrap failure unrecognised signature  <ci> <maas-provider> <juju-core:In Progress by dimitern> <juju-core maas-spaces:Fix Committed by mfoord> <https://launchpad.net/bugs/1548813>
<dimitern> frobware, ah, sorry about that :) I'm happy to do a follow-up after that last one, if you have concerns
<voidspace> frobware: dimitern: yeah, I didn't understand that - surely if the fix is on maas-spaces2 then the fix will land on master when maas-spaces2 is merged
<dimitern> voidspace, yeah, assuming the fix for br-eth1 lands in maas-spaces2 first
<dimitern> frobware, voidspace, but it affects master already, and it's critical to fix this to unblock multi-nic containers
<voidspace> ah, if it affects master already then fair enough
<voidspace> your comment on the bug implied it wouldn't affect master until maas-spaces2 was merged (at which point the fix would land as well)
<dimitern> initially it wasn't obvious it affects master, but I can confirm that now
<frobware> dimitern, voidspace: so could somebody explain to me how it affects master.
<frobware> dimitern: I'm missing some context arounf br-eth1
<dimitern> frobware, if you try what that CI job does, the effect is the same
<dimitern> frobware, i.e. deploying an lxc container on a machine with 2 nics, eth0 disabled, eth1 enabled
<frobware> dimitern: I see. thx.
<dimitern> frobware, so the issue is not with the bridge script this time :) - br-eth1 gets created OK, but then we don't render the correct lxc.conf and /e/n/i
<frobware> dimitern: yeah, I eventually got that when I read bug #1549545
<mup> Bug #1549545: Bundle deploys fail at lxc-start when bridge br-eth1 is created <ci> <deploy> <maas-provider> <test-failure> <juju-core:In Progress by dimitern> <https://launchpad.net/bugs/1549545>
<frobware> dimitern: reviewed http://reviews.vapour.ws/r/3972/
<dimitern> frobware, thanks! will have a look shortly
<dimitern> removing any IPv6 settings from my vmaas-19 made everything SOOO much faster!
<frobware> dimitern: be careful, when IPv4 has run out you'll have to switch back. :)
<dimitern> frobware, I kept the config commented out just for such a case :)
<frobware> dimitern: any decade now...
<dimitern> frobware, indeed :D
<perrito666> jam: can you try to reproduce that issue with master? if volumes are being deleted it means we might have broken something with tags
<jam> perrito666: I can't try to reproduce right now as I'm focused on the LXD stuff.
<jam> its an old envirenment that I forgot to teardown. Though now I can't tear it down at all.
<perrito666> jam: did you just deploy to ec2 and then dropped the machine?
<jam> perrito666: I would have bootstrapped a couple weeks ago. The machine was still up and running and happy returning "juju status" results.
<jam> cherylj: tych0: mgz: I took tycho0's update to mine and I have something that is passing the test suite and seems able to "juju bootstrap lxd lxd"
<jam> http://reviews.vapour.ws/r/3973/
<mgz> jam: thanks!
<jam> tych0: we still need to fix containers/lxd/lxd_test.go to not require you to have an "ubuntu-xenial" image.
<jam> mgz: so there are still some known limitations. Like LXD containers on OS other than Xenial need you to install "ppa:ubuntu-lxc/lxd-stable"
<jam> I thought it was supposed to be in trusty-backports
<jam> but suddenly 0.26 is the version in trusty-backports
<jam> which Juju happily installs and then immediately fails to work because of API incompatibilty.
<mgz> hm, yeah, this need some sanity in which versions we promote to ubuntu archive when
<mgz> which the juju team hasn't had much influence over so far
<jam> mgz: also this is *not* compatible with 2.0.0~beta3
<jam> they broke their api one more time for 2.0.0~beta4
<jam> I'm told they aren't likely to break it again.
<natefinch> ericsnow: you around?
<jam> mgz: can you give it a bit of a run around to make sure it isn't just my local stuff that is working?
<jam> I'm not sure who else is going to review that code.
<jam> maybe ericsnow or katco or natefinch would like to review the LXD updates?
<mgz> jam: if you like we can just send that branch through CI
<jam> http://reviews.vapour.ws/r/3973/
<jam> mgz: well, we could just land it on lxd-container-type couldn't we?
<jam> that is the target of that branch
<jam> I don't imagine it is going to be any more broken than the existing lxd-container-type. :)
<natefinch> katco`: I need to bring my daughter to the doctor at 11:30 today - she's had a fever since Sunday night, and spiked to 103.5 last night.  It'll probably take 90 minutes all told, but most of that can come out of my lunch time.
<mgz> yeah, that would be fine
<jam> mgz: can you confirm the version of Go that the landing bot uses?
<jam> mgz: I was pretty sure it was 1.2 but that means all the LXD tests get skipped.
<katco`> natefinch: ok, hope she feels better :(
<mgz> the gating uses 1.2, revision testing is go 1.2/gccgo/go 1.5/go 1.6
<jam> mgz: right. so there is no gating on LXD :(
<jam> but at least it will notice in CI
<jam> which is how I broke it last time, probably.
<jam> anyway I need to go walk the dog. I might try to stop by later to catch up to how things are going.
<natefinch> katco`: yeah, it's been a scary few days, and the fact it just keeps on going is cause for concern.  And this is our 2.5 year old, so she's still pretty little.
<katco`> natefinch: yeah, it's scary at that age
<jam> natefinch: I hope if its something it gets resolved quickly. Been through that as well. always hard.
<jam> mgz: so... I'm worried that we can't release because this is going to be "known broken" on Trusty because they no longer have 2.0.0~beta4 in backports
<jam> mgz: thoughts?
<natefinch> jam: thanks
<jam> bbiab
<mgz> jam: I agree, though what functionality are we promising on trusty with the beta?
<natefinch> mgz: it won't format your hard drive ;)
 * natefinch sets a low bar.
<natefinch> ericsnow, katco`: in other news, juju upgrade-charm --resource basically works right now.  THere's some probable undesired behavior, but hooking into the code that deploy used for --resource was really easy.
<frobware> jam: there was one printf-esque mismatch you might want to address now, my other comments were more benign.
<katco`> natefinch: \o/
<tych0> jam: do i count as a guy who can land that into lxd-container-type? i'd be happy to land it there so we can at least get more CI on it and start getting the +1s
<tych0> your changes on top of mine on top of yours look good :)
<natefinch> katco`, ericsnow: and by probable bad behavior, I mean that any resource you *don't* specify with --resource gets removed ;)
<natefinch> rick_h_: I presume that if you upgrade-charm --resource foo, any other resources you have uploaded should remain the same?
<frobware> tych0: just a heads-up, see my comment ^^ to jam about a printf-esque mismatch in the review and the one about limits.cpus vs limits.cpu.
<natefinch> jam: saw the ping on lxd review, maybe katco` can talk about scheduling... we're pretty slammed, but I know the lxd stuff is critical
<tych0> frobware: will take a look, thanks
<tych0> frobware: yeah, it is subtle but also correct. see the commit message for the commit in question
<tych0> (not sure how to link it on the review tool)
<frobware> tych0: ok, that's fine. it was more out of completeness
<katco`> natefinch: jam: we should assist with lxd support where possible
<katco`> natefinch: jam: in a meeting, where is this request?
<natefinch> katco`: http://reviews.vapour.ws/r/3973/
<tych0> frobware: sure, np. thanks for looking!
<katco`> ericsnow: when you're off this call, can you give this review a look?
<ericsnow> katco`, natefinch: sure
<katco`> jam: tych0: ^^^ we'll tal. ty for pr
<frobware> dimitern: regarding, http://reviews.vapour.ws/r/3967/, in general I think we should only merge blessed master builds unless we need specific fixes. thoughts?
<dimitern> frobware, wouldn't it be better to track master closely until 2.0 branch is cut?
<frobware> dimitern: I would rather have blessed builds as we don't have to chase ghosts.
<frobware> dimitern: as soon as anything on master is blessed, and we're behind, we merge. not opting out, just being choosy.
<dimitern> frobware, sounds reasonable
<dimitern> frobware, but there were a few useful fixes we picked up due to that merge
<frobware> dimitern: again, not a hard-and-fast-rule, just trying to ensure we don't chase CI bugs on maas-spaces2.
<mgz> master is in a rather unstable state atm unfortunately
<frobware> mgz: dimitern: no further questions your honour! :)
<dimitern> :)
<voidspace> dimitern: frobware: dooferlad: another gomaasapi fix https://github.com/juju/gomaasapi/pull/8
<frobware> voidspace: looking
<dimitern> voidspace, why should it matter whether the reserved ranges are nil vs empty slices ?
<voidspace> dimitern: because GetArray fails on nil
<voidspace> dimitern: and it isn't what the real server does, so I'd rather the test server behaved like maas
<voidspace> dimitern: instead of writing defensive code in production just for the gomaasapi test server
<frobware> voidspace: how did you discover this?
<voidspace> frobware: on my current branch a whole bunch of tests fail
<voidspace> frobware: I've changed the Spaces implementation and the existing tests fail
<frobware> voidspace: k
<katco`> ericsnow: getting some more coffee and then we can do our 1:1
<ericsnow> katco`: k
<voidspace> and fetching a subnet calls Spaces to get the space provider id, so all the existing tests fail
<voidspace> because the test server is now wrongly configured for the test
<dimitern> voidspace, I see
<dimitern> voidspace, yeah, that's a problem when using MAASObjects instead of structs with json serialization tags
<perrito666> meh, switch lost --list
<perrito666> aaand, I can no longer do a switch to my provider
<perrito666> :(
<katco`> ericsnow: k i'm in the hangout when you're ready
<ericsnow> k
<voidspace> frobware: what do you mean by 'can "1" ever return nil'?
<frobware> voidspace: heh, sorry it was ambiguous. The call to GetSubObject("1").
<voidspace> frobware: the answer is no
<voidspace> frobware: it's a gomaasapi object for making a call to the server
<voidspace> frobware: the subsequent call can fail, but GetSubObject can't return nil
<frobware> voidspace: ok. it was the only thing that stuck out for me. LGTM.
<voidspace> frobware: dimitern: thanks
<perrito666> bbl, bye
<kilty> natefinch, mgz, cherylj: Been trying to play around some more get this working. I'm still having problems with the metadata generation - I'm not sure what I'm missing
<kilty> http://pastebin.com/7JR198Az
<kilty> this is everything I'm working with - I'm not sure what information it's looking for with the -m. Is it just the name of the cloud? is it a file with config options?
<katco`> kilty: have you popped into #juju to see if anyone there has experienced similar issues?
<cherylj> kilty: the -m specifies the model (new term for environment) to operate in.      the command help looks like it hasn't been updated for the 2.0 conventions
<katco`> kilty: we may be able to help you, but this channel is more focused on development
<cherylj> I have a hard time wrapping my head around having to have a bootstrapped env / model in order to generate metadata
<cherylj> let me poke at that command
<kilty> katco`: I'll pop in there and ask as well
<kilty> cherylj: Yeah I'm not sure why I wouldn't be able to generate metadata regardless of a model - when I was working with 1.25 I could generate metadata regardless of what env I was going to deploy it to
<cherylj> kilty: the image metadata you generate with 1.25 should be usable with 2.0
<kilty> so we should generate it on a 1.25 instance and scp it over?
<cherylj> kilty: yeah, I'd give that a try
<kilty> cherylj: ok. I will give that a try and see what happens. Thanks
<frobware> jam: you about? I looked at the updates diffs for your review and it is now spread across 9 pages. Seems a lot. :)
<alexisb> frobware, jam is probably out but tych0 is around and may be able to answer qs
<tych0> yep, happy to answer any questions
<frobware> alexisb: yep - asking because I saw some follow up from him about 15 mins..
<frobware> tych0, jam: so looks like upstream/master was merged onto that review, hence the 9 pages. Just surprised me as I was looking at the diffs based on jam's comments.
<tych0> frobware: yes, i didn't do the merge unfortunately
<kilty> cherylj: So it looks like the metadata generation works, it's just throwing errors - it creates the same metadata that 1.25 does
<kilty> same thing with the tool generation
<natefinch> katco, ericsnow: can you guys TAL at this PR?  http://reviews.vapour.ws/r/3949/ It's the one from yesterday where we now return a unitresources value for every unit.
<ericsnow> natefinch: yeah, sorry, will do soon
<natefinch> katco, ericsnow: also, having push-resource call upgrade-charm is kind of amazing.  It makes everything just work the way you'd expect
<katco> natefinch: will do so when i get a chance. lots o' meetings today. speaking of... we still on for 10m from now?
<natefinch> er fire the upgrade-charm hook that is
<katco> natefinch: that's good to hear :)
<natefinch> katco: yep, back from the doctor. They tested and it's not strep or the flu... just some nasty virus.. said if she's not better in a couple days they'll have to do chest X-Rays, but we're hoping she'll just fight it off.
<katco> natefinch: :( well hope she feels better real soon
<natefinch> katco: yeah... she's a little better today... but she always seems a bit better morning/midday, so we'll see what happens tonight.
<perrito666> I know this is not a popular opinion but, I really dislike format tabular as a default
<voidspace> g'night all
<natefinch> perrito666: blasphemy
<natefinch> katco: btw, I think you can discard your api pass through review (http://reviews.vapour.ws/r/3948/) now, since my PR with that code landed last night
<katco> natefinch: yeah been meaning to
<perrito666> is master unlocked?
<natefinch> perrito666: http://juju.fail
<alexisb> katco, sorry, thats me
<alexisb> logging back on
<katco> alexisb: ah ok. lately i've been the one freezing :)
<perrito666> natefinch: sweet I completely forgot that thing
<natefinch> perrito666: best use of a non-standard TLD I've seen
<kilty> niedbalski: working through the same issues you were in this bug, and was hoping that I could pick your brain
<kilty> https://bugs.launchpad.net/juju-core/+bug/1452422
<mup> Bug #1452422: Cannot boostrap from custom image-metadata-url or by specifying metadata-source <sts> <juju-core:Fix Released by wallyworld> <juju-core 1.24:Fix Released by wallyworld> <https://launchpad.net/bugs/1452422>
<niedbalski> kilty, AFAIK that should be fixed, which juju-core version are you using?
<kilty> niedbalski: 1.25
<kilty> niedbalski: 1.25.3, to be exact
<kilty> installing from ppa:juju/stable
<niedbalski> kilty, can you pastebin the error you are seeing?
<kilty> If I generate the metadata locally and use the --metadata-source option on bootstrap, it creates the ost image, but the ost image defaults to looking back at cloud-ubuntu images
<kilty> niedbalski: sure thing
<mgz> kilty: you need to use image-metadata-url like I said previously
<kilty> mgz: when I use the image-metadata-url, it seems to completely ignore it
<mgz> kilty: if you bootstrap with --debug you can see what simplstreams are being selected
<kilty> mgz: I am running a bootstrap with --debug now, will pastebin the results
<kilty> niedbalski: http://pastebin.com/raw/VcYGhsFF
<kilty> that's with using the --metadata-source option
<mgz> kilty: that won't work. the local file never gets uploaded anywhere the state server can see it. I can see that the image-metadata-url is being looked at.
<kilty> mgz: http://pastebin.com/NnFH6jQj
<kilty> mgz: that's that happens when I just run with the agent-metadata-url and image-metadata-url set in the env file
<mgz> kilty: export JUJU_LOGGING_CONFIG="<root>=DEBUG; juju.environs.simplstreams=TRACE" and try that again?
<mgz> gah,tyop
<mgz> *juju.environs.simplestreams
<kilty> mgz: running now
<kilty> mgz: http://pastebin.com/zRnqWxZR
<mgz> kilty: no route to host
<mgz> line 11
<kilty> mgz: yeah sorry about that hold on - I need to re-run it
<mgz> you need to host the streams somewhere both your client and the machine you are deploying can see
<mgz> that needs to be higher than trace...
<kilty> mgz: http://pastebin.com/HfdYzspP
<kilty> I'm running this from an instance that I created in the same tenant to which I will deploy juju
<kilty> so the ost machine and the box I am on now are in the same network
<mgz> kilty: l17, 403
<mgz> can you actually resolve the path where you uploaded the json files, just in a browser?
<kilty> I can resolve thee parent directories - images/streams
<kilty> let me chmod the entire structure and try again
<kilty> ok - it's created the instance and is starting to provision - I'll let you know if it fails
<kilty> mgz: thank you so much for all your help..this has been bugging me for about a week now. I'm trying to set this up so that I can deploy about 400 juju environments on a private openstack cloud for internal developers
<mgz> no probs
<kilty> mgz: tools from http://192.168.111.20/tools/releases/juju-1.25.3-trusty-amd64.tgz downloaded: HTTP 404; time 0.002s; size 0 bytes; speed 0.000 bytes/s sha256sum: /var/lib/juju/tools/1.25.3-trusty-amd64/tools.tar.gz: No such file or directory
<kilty> 2016-02-25 20:29:30 ERROR juju.cmd supercommand.go:429 failed to bootstrap environment: subprocess encountered error code 1
<mgz> kilty: if you have outbound net access, I'd just delete the agent-metadata-url config and let the setup get the tools from our source
<mgz> otherwise, you'll need to get that tgz mirrored
<kilty> mgz: ok - that makes sense. Re-running w/o agent-metadata-url
<kilty> mgz: success!
<mgz> kilty: ace!
<kilty> mgz: now for the noob question of the hour - how to I deploy the gui frontend?
<kilty> is it not part of the bootstrap?
<mgz> `juju deploy cs:juju-gui --to 0` should do
<kilty> oh duh - it's a charm
<kilty> mgz: thanks
<mgz> they have plans for things in 2.0 which... I'm not completely up to speed with
<mgz> just to integrate the gui a little more closely I think
<perrito666> great, I cannot reproduce a bug even though I know its there
<kilty> mgz: well now that we have 1.25 up I think that solves the issues we were having with 2.0 as well
<mgz> yeah, should just be the same stuff
<perrito666> anyone here has been bit by the "status history full of update-status calls" ?
<axw> fwereade_: yep, it certainly has sharp edges. its raison d'etre is edge cases ;p   if we could find a nice way to confine it to manual and lxd that would be good. or maybe just manual, and do the loop-device detachment elsewhere...
<mup> Bug #1550033 opened: Streaming API handlers may panic when apiserver shuts down <juju-core:New> <https://launchpad.net/bugs/1550033>
<mup> Bug #1550033 changed: Streaming API handlers may panic when apiserver shuts down <juju-core:New> <https://launchpad.net/bugs/1550033>
<mup> Bug #1550033 opened: Streaming API handlers may panic when apiserver shuts down <juju-core:New> <https://launchpad.net/bugs/1550033>
#juju-dev 2016-02-26
<axw> wallyworld: can you please create the feature branch? I don't have permissions to
<wallyworld> ah, ok
<wallyworld> axw: there now
<axw> wallyworld: ta
<axw> wallyworld: I'll land the branch you LGTMd there, then propose the next one against it
<wallyworld> +1
<mup> Bug #1550074 opened: ec2/ebs: ListVolumes should not return root volumes <ec2-provider> <juju-core:Triaged> <https://launchpad.net/bugs/1550074>
<wallyworld> axw: when you're free could you look at http://reviews.vapour.ws/r/3971/
<axw> wallyworld: ok, looking
<menn0> axw: ping
<axw> menn0: pong
<menn0> axw: in b16d1e85879d1cccb38a860b04c65125b87567f1 you made ConnectionInfoForName private (in cmd/modelcmd)
<menn0> in a feature branch I'm using it
<menn0> for the "juju migrate" command
<menn0> any problems with exporting it again?
<axw> menn0: all those old things are going away. what're you using it for?
<axw> menn0: can you point me at the migrate code?
<menn0> axw: ok, if there's a better way
<menn0> axw: I need to get the API server and auth details for the controller to migrate a model to
 * menn0 digs up a link
<menn0> axw: https://github.com/juju/juju/blob/model-migration-control/cmd/juju/commands/migrate.go#L87
<axw> menn0: sorry got called downstairs, one moment
<axw> menn0: something like this: http://paste.ubuntu.com/15202778/
<axw> menn0: configstore will be going away, so best not to revive the old method
<menn0> axw: tyvm, this looks great
<menn0> axw: I'll update the migrate command
<menn0> axw: I knew this stuff was changing but it hadn't when I wrote it
<axw> menn0: yup, such is life with feature branches :)
<menn0> axw: yep, they are are a double edged sword
<menn0> axw: am I right in thinking that the store can be easily swapped out for testing? it looks that way from what I can see.
<axw> menn0: yes, c.SetClientStore before wrapping the command
<axw> menn0: the Init method will only set the default store if one hasn't been set already
<menn0> axw: that's what I was looking at. perfect.
<anastasiamac> yep, menn0. axw and wallyworld r pretty awesome \o/
<axw> menn0: also note that SetModelName and SetControllerName return an errors now, didn't before - in case you use that anywhere
<menn0> ok great
<axw> I should probably document how it works and send that out
<menn0> axw: looks like ModelByName doesn't need AccountName
<axw> menn0: you may need to rebase
<menn0> axw: I just rebased this branch to the latest blessed master
<menn0> has it changed since?
<axw> menn0: 3 days ago
<menn0> axw: probably just after then
<menn0> axw: this branch will be around for a while yet so I'll get right up to tip
<axw> wallyworld: my desktop keeps rebooting. need to run tests, will be off for a while
<wallyworld> ok
<menn0> axw: thanks for your help earlier, the migrate command is working again.
<axw> menn0: great, np
<menn0> axw: I wonder if MemStore should have some extra methods to make it easier to set up test configs.
<menn0> axw: I had to make about 6 calls to set up a workable config for the migrate command
<menn0> axw: and it took a while to figure out how to do it right
<axw> menn0: do you have something in mind? you can initialise the maps directly
<axw> menn0: I agree it's a bit tedious - initialising maps directly is a bit better, but still a bit verbose
<menn0> axw: I was thinking some sort of call which sets up a model, controller and account all at once
<davecheney> https://github.com/juju/juju/pull/4401
<davecheney> can I get a review on this one please
<menn0> axw: it's fine the way it is
<davecheney> for whatever reason the bot has decided to ignore it
<menn0> axw: just wondering if it could be better
<menn0> I didn't even consider fiddling with the maps directly so i'm not sure how that would have looked
<axw> menn0: yeah, I think it can. something along the lines of testing/factory might be nice
<menn0> axw: yeah, that style of helper might be nice
<menn0> axw: not urgent though
<menn0> davecheney: LGTM
<davecheney> ta
<wallyworld> axw: depending on how far you get before eod with the default host model, can you push up something even if wip so it can be landed into feature branch and i can take over when you're gone?
<axw> wallyworld: yup. just finished adding --default-model, still need to write tests
<wallyworld> awesome, ta
<axw> wallyworld: actually I think I'm going to have to rework things a bit, so we know what the UUID of the hosted model is up front
<axw> wallyworld: needed so I can set the current model from the CLI without waiting for completion
<wallyworld> that doesn't surprise me
<axw> anyway, will send you a link when I'm done
<wallyworld> axw: ok, i am off to meet anastasia for 1:1 and then to soccer but will be back later
<axw> wallyworld: I might reappropriate "uuid" in the initial config for the hosted model, and add a new "controller-uuid" attribute
<axw> wallyworld: later
<wallyworld> controller-uuid is more explicit
<jam> mgz: sinzui: If I accidentally submitted a merge request but the branch was targetting the wrong branch, I want to cancel the merge job so it doesn't waste time.
<jam> how do I determine which merge job it is?
<jam> When I go to the juju-ci page, I can see the pending request, but I can't see any of the details
<jam> like right now, there are 2 pending jobs, I have no way to distinguish them.
<davecheney> jam: best i know how to do is to open each of them
<davecheney> scroll down to the output
<davecheney> and then look at the branch
<davecheney> o
<davecheney> sory, that won't work if they haven't started to run yet
<jam> right
<jam> menn0: frobware: I updated my LXD branch to Skip() one of the tests that I know is not very nice (talks to LXD on your running machine and starts containers), and fixed newInstanceSummary to actually parse Mem correctly.
<jam> ericsnow: I also responded to your review feedback. Hopefully someone feels its good enough to at least land on the feature branch.
<jam> tych0: ^^ branch updated
<jam> http://reviews.vapour.ws/r/3973/diff/#
<frobware> jam: merging upstream/master was an intentional thing?
<jam> frobware: well, I do intend to keep up to date with master, yes.
<jam> frobware: just shouldn't have happened as part of the review.
<jam> So I landed master into the target branch directly, so now the diff is nice again.
<jam> frobware: I just misunderstood one of your comments. You said "this is missing a parameter" meaning the Print statement, but I read it as the network.Address()
<jam> so I thought I was out of date with master.
<jam> (which I was rather far behind)
<dooferlad> frobware, dimitern, voidspace: https://plus.google.com/hangouts/_/canonical.com/sapphire
<voidspace> dooferlad: sorry, got lost in code
<voidspace> dooferlad: omw
 * fwereade_ popping out for a bit, bbl
<mgz> jam: the only way to see which build is which that I know is by hover on *the main page* which is generally full of bundle test junk
<mgz> but you can see which job is which and cancel from there
<jam> mgz: the lines and lines of "charm-bundle-test-aws"
<mgz> yeah, it's joy
<jam> there appears to be about 100 lines there.
<jam> mgz: did you see my email about setting up a CI test from one of the current LXD tests?
<mgz> jam: yeah, it seems like a good idea
<voidspace> oh the irony: Test killed with quit: ran too long. github.com/juju/juju/worker/terminationworker
<voidspace> dimitern: frobware: dooferlad: http://reviews.vapour.ws/r/3981/
<dimitern> voidspace, looking
<dimitern> voidspace, reviewed
<voidspace> dimitern: I've fixed two of the issues and replied to the other two - I think we should drop the issue about providerId conversion and I am reluctant to include spaces with no subnets
<voidspace> dimitern: how about we skip them for now and revisit that if it becomes a practical issue anyone cares about
<voidspace> dimitern: I think including them is dangerous
<dimitern> voidspace, that's fine - added a comment
<voidspace> dimitern: thanks
<dimitern> voidspace, frobware, dooferlad, please have a look http://reviews.vapour.ws/r/3972/
<dimitern> voidspace, frobware, dooferlad, and this is the straw-man proposal for addresses - http://paste.ubuntu.com/15204914/ (we should decide on the doc / collection / state type names - singular and plural)
<dooferlad> dimitern: what is the urgency on having a discussion around that?
<dimitern> dooferlad, because that's what I'm about to start implementing
<dooferlad> dimitern: That clears that up :-)
<dimitern> :) cheers
<dimitern> if we don't reach consensus though, I can switch to doing the Machine.UpdateLinkLayerDevices() instead
<frobware> dimitern: ignore my comment about empty ops - just looked again and makes perfect sense.
<frobware> dimitern: rule 1, don't be blocked. :)
<dimitern> frobware, :) cheers, I still replied though, as it's a fair question
<dooferlad> dimitern: I can't think of any more information that we need for an ipAddressDoc. +1
<dimitern> dooferlad, sweet, thanks!
<frobware> dimitern: Did we settle on DNSSearchDomains for DNSDomains?
<frobware> dimitern: type 'IPAddressConfigMethod' is missing loopback.
<dimitern> frobware, good point - will rename DNSDomains to DNSSearchDomains
<dimitern> frobware, as for loopbacks.. the config type is still static I think (actually always static)
<frobware> dimitern: iface lo inet loopback
<dimitern> frobware, but the "loopback" part is the device type
<frobware> dimitern: don't believe so.
<frobware> dimitern: given the number of args in 'iface', it is the config method,
<dimitern> frobware, loopback devices have no options to set
<dimitern> frobware, so it can't have an address - it's always 127/8
<frobware> dimitern: but things like "address" are iface options. the way I read interfaces(5) loopback is the config method.
<dimitern> frobware, hmm.. well if we use config type loopback that actually solves the minor inconsistency with what SubnetID to use for 127.0.0.1
<frobware> dimitern: if you read through the manpage it talks about 'auto' method, then 'loopback', 'static', 'dhcp, 'manual' (in that order).
<dimitern> frobware, so, good idea - LoopbackIPAddress type does not accept a SubnetID or GatewayAddress
<dimitern> s/does not/won't/
<frobware> dimitern: ooh, and in the xenial manpage there is also 'v4tunnel' method.
<frobware> dimitern: and '6to4'.
<frobware> (I'll stop now.)
<dimitern> frobware, there are other methods I know - but we shouldn't worry about them yet I think
<frobware> dimitern: agreed. but if we wanted to faithfully generate /e/n/i then I think we should cover loopback. that's been around a while now. :)
<dimitern> frobware, I have a cunning plan to support pptp/tun devices at some point as devices with 2 parents or something like that
<dimitern> frobware, yeah, agreed - for completeness sake loopback devices and their addresses should be represented in the model
<dooferlad> dimitern: reviewed http://reviews.vapour.ws/r/3972/ - basically it is really close to being generic and I provide, what I think, is a simple suggestion to make it generic without having to change the rest of your code.
<frobware> dimitern: the 'ipAddressDoc' comment could also include an example; might clear up what we mean by link-layer network device.
<dimitern> dooferlad, thanks, I'll respond shortly
<dooferlad> dimitern: I am about to get some lunch. No big rush.
 * dooferlad goes for lunch
<frobware> dimitern: other than that, but dooferlad, voidspace should take a quick pass once these ^^ changes are done.
<mup> Bug #1550306 opened: 1.25.3 can't bootstrap xenial environments <kanban-cross-team> <landscape> <juju-core:New> <https://launchpad.net/bugs/1550306>
<frobware> dimitern: other than that LGTM
<dimitern> frobware, thanks! voidspace, dooferlad: here's an up-to-date paste  http://paste.ubuntu.com/15205049/
<frobware> dimitern: do we need to handle unknown?
<frobware> dimitern: if so, how and when do we get into that state?
<dimitern> frobware, no, like with devices it will be rejected if trying to add it
<frobware> dimitern: if that's the case why do we need the unknown type?
<dimitern> frobware, good question - it looks like we don't anymore (remember my earlier comments about possibly allowing unknown devices/addresses for containers before we know their real type? well I guess that's no longer relevant)
<dimitern> so I'll do a follow-up after finishing the addresses (without UnknowIPAddress ) to remove UnknownDevice as well
<frobware> dimitern: great, thx. removing code always a bonus.
 * frobware lunches
<perrito666> morning
<mup> Bug #1550338 opened: destroy-controller reports warning endlessly <juju-core:New> <https://launchpad.net/bugs/1550338>
<mup> Bug #1550338 changed: destroy-controller reports warning endlessly <juju-core:New> <juju-core 2.0:New> <https://launchpad.net/bugs/1550338>
<tych0> jam: cool. do you need anythingn from me right now?
<natefinch> ericsnow, katco: upgrade-charm --resources is ready for review
<ericsnow> natefinch: k
<natefinch> http://reviews.vapour.ws/r/3974/
<natefinch> ericsnow: is that poller merge PR ready for review? I could do that next
<ericsnow> natefinch: yes and that would be great
<voidspace> dimitern: ping
<dimitern> voidspace, pong
<voidspace> dimitern: so I'm looking at bindings in the provisioner
<voidspace> dimitern: EndpointBindings
<voidspace> dimitern: do they need to be names or ids?
<voidspace> dimitern:  they come from state and are supplied originally as space names
<voidspace> dimitern: so I'm hoping they'll just be stored as names, so there's no work to do there
<voidspace> unless we've translated into juju names and need to go back into maas names (which will be redundant once maas is fixed)
<voidspace> dimitern: I think bindings for startMachine needs to be names not ids, right? (that's the one place we use names - and they can be validated at the time they're specified)
<dimitern> voidspace, let's have a quick HO ?
<voidspace> dimitern: ok
<voidspace> dimitern: https://plus.google.com/hangouts/_/canonical.com/sapphire?authuser=0&hceid=Y2Fub25pY2FsLmNvbV9pYTY3ZTFhN2hqbTFlNnMzcjJsaWQ5bmhzNEBncm91cC5jYWxlbmRhci5nb29nbGUuY29t.cktt9qpgdt7im58l9qt9ianpag
<voidspace> https://plus.google.com/hangouts/_/canonical.com/sapphire
<natefinch> ericsnow: gah.... we really gotta get the charmstore stuff going... all this fake stuff and todos is wicked distracting during code review (not your fault).
<ericsnow> natefinch: agreed!
<katco> ericsnow: natefinch: this iteration! :)
<natefinch> katco: yeah :)
<dooferlad> dimitern: why do we expect bindings to be an empty string if unspecified? Don't we cope with the key/value pair not being populated?
<dooferlad> dimitern: ref: juju/deploy.go getEffectiveBindingsForCharmMeta
<katco> natefinch: you get a ship it!
<katco> ericsnow: and you ghet a ship it!
 * ericsnow is gonna cry
<ericsnow> katco: thanks
<dimitern> dooferlad, exactly because there were not specified - so we don't pretend they're not by storing a made-up default
<dimitern> s/there were/they were/
<dooferlad> dimitern: why not just store nothing
<dooferlad> ?
<dimitern> dooferlad, because the endpoints exist anyway - regardless whether we bound them or not
<dooferlad> dimitern: sure, the endpoints exist, but we have no need to store something. Not storing something makes as much sense as an empty string.
<dooferlad> dimitern: we still will be doing v, ok := binding[endpoint] style accesses, right?
<dimitern> dooferlad, well, it's also because storing them makes it easier to read them back for network-get
<dimitern> dooferlad, the list of all endpoints depends on the charm used by the service, same as for settings
<dooferlad> dimitern: But bindings aren't endpoints. Endpoints exist without them.
<dimitern> dooferlad, let me double take it then - why do you think storing them is wrong?
<natefinch> katco: thanks
<katco> natefinch: ty for getting that proposed so quickly. love how simple it is!
<dooferlad> dimitern: If we have to validate if a space is valid after we get it out of the binding map, that just adds work.
<natefinch> katco: yeah, I was super happy with how it went... other than having to change 1000 tests.. but now that the methods take configuration structs, that shouldn't need to happen again next time we add a parameter.
<natefinch> katco: I almost wish Go had optional arguments, just to avoid churn like this.
<katco> natefinch: it goes against their simplicity > ease philosophy, but i agree. i really miss optional args
<dimitern> dooferlad, it will be valid once stored, as it's validated beforehand; if it's empty - nothing to validate
<katco> natefinch: keyword args are even better
<katco> natefinch: but i suppose passing in a struct is roughly equivalent. just less syntactic sugar
<natefinch> katco: yeah, I loved it when C# added named arguments.  Just make function calls so much more clear... no more doSomething(true, true, false, 3)
<dooferlad> dimitern: you still have to check if it is empty. You can't just iterate over the map. You need to iterate and check for empty. Then you need to see if non-empty stuff is valid.
<katco> natefinch: i wish it could be smart enough to see that it takes a struct Foo, and then you could just do Bar({Baz: "whee"})
<dimitern> dooferlad, which part of the code are you talking about?
<katco> natefinch: that syntax doesn't look horrible
<katco> natefinch: but still boilerplate to create arg structs
<dimitern> dooferlad, deploy-time validation for bindings?
<dooferlad> juju/deploy.go getEffectiveBindingsForCharmMeta adds the spaces.
<ericsnow> natefinch, katco: I'm going to hold my tongue :P
<dooferlad> I bumped into this because tests had changed and I hadn't understood what was happening when I merged, so didn't pick up the expected empty strings.
<dooferlad> so failures happened.
<dooferlad> once I dug into it, it seemed reasonable to ask why we changed the behaviour.
<katco> ericsnow: ok, cool... btw, just totally off topic: python sucks!
<dooferlad> dimitern: ^^
<ericsnow> katco: apparently you *still* haven't tried it (just this once, everyone is doing it)
<katco> ericsnow: haha
<dimitern> dooferlad, well, the initial behavior which assumed they're never empty complicated the case where they were not specified by the user
<natefinch> katco: eliding the struct name in the function call would seem to be a pretty valid feature...
<dimitern> dooferlad, so instead of inventing a sane default, we not don't store them
<katco> ericsnow: honestly i have likely been ruined by CL. python is fine, but i've already gotten the "lightweight and flying feeling" from CL, and i prefer lispy syntax (my gawd it's full of parens!)
 * natefinch shudders
<dooferlad> dimitern: but we are storing an invalid value
<dimitern> dooferlad, it sounds reasonable to not store them unless they're explicitly specified by the user
<ericsnow> katco: yeah, but you use/live in emacs
<katco> ericsnow: (sheds a tear) i am more emacs now than not.
<dooferlad> dimitern: that is what I thought :-)
<dimitern> dooferlad, but to do that some refactoring is in order
<katco> ericsnow: but vim has a perfectly fine para-edit mode. makes editing sexps very easy
<dooferlad> dimitern: before I rebased on maas-space2 I was working quite happily not storing bindings that weren't specified.
<dimitern> dooferlad, the changes that made unspecified bindings stored as empty is on master as well
<dooferlad> dimitern: yea, I was working off a really old maas-spaces.
<dimitern> dooferlad, ah, well ;)
<natefinch> why do we pass UUIDs around as strings?
<dimitern> dooferlad, anyway, I'm happy to continue the discussion over the ML or something, but I really need to go out now
<dooferlad> dimitern: sure. Have a good weekend!
<dimitern> dooferlad, likewise ;)
<frobware> katco: did you ever dabble with Clojure?
<katco> frobware: dabbled *very* briefly
<frobware> katco: likewise, but circa 2009
<natefinch> I've heard horror stories about Clojure... where the smartest guy in the company can write code that no one but him understands....
<natefinch> (or her)
<katco> natefinch: really? i've never heard that... it's hard to think why that would be the case
<natefinch> katco: when I get some time I'll see if I can dredge up the article.... something about obscure parts of the language and complicated mathematical constructs.... I think it wasn't impossible for others to understand, it just took a lot of time to understand like one line of code.
<katco> natefinch: that sounds more like haskell
<frobware> katco: bingo!
 * katco admits haskel is on her list of languages to learn
<frobware> katco: talk to john wiegley, he does a lot of elisp/lisp/haskell.
<katco> frobware: of ledger-cli.org fame?
<frobware> katco: yep.
<frobware> katco: also now emacs maintainer
<katco> frobware: ah yes, forgot about that
<katco> frobware: what do you mean talk to him? "hey i'm random internet person #434562. i like lisp! hi!"
<mup> Bug #434562: phpmyadmin error <apport-package> <i386> <phpmyadmin (Ubuntu):New> <https://launchpad.net/bugs/434562>
<frobware> katco: for john that would work. :)
<katco> lol mup... that wasn't a bug number
<katco> frobware: i'm actually trying to migrate to ledger for personal finance
<katco> frobware: but stumbling a bit on getting the data out of my banks in a cron job
<frobware> katco: I signed up recently with yodlee to do it MY way... :)
<frobware> katco: yodlee provide a rest api to your bank account, complete with aggregation.
<katco> O.O
<katco> i am checking this out
<katco> frobware: i have to admit, part of the reason to switch to ledger was so that my financial life isn't aggregated into 1 spot on someone else's server
<frobware> katco: well, that was my weekend hack. I'll let you know if it a) actually happens and b) is really viable. I so so hope it is...
<katco> frobware: awesome... lmk for sure :)
<frobware> katco: burning bushes always gets in the way of real work. :-D
<katco> frobware: not aware of that phrase... what does it mean?
<frobware> katco: there's always something more important that the most important thing you're working on. and when you get there it wasn't the great fire of london, just some small incidental problem, hence the bush...
<ericsnow> natefinch: ship-it
<natefinch> ericsnow: thanks.  Almost done reviewing yours.
<natefinch> katco, ericsnow: we should have a conversation about returning interfaces at some point, since it has come up a few times.
<ericsnow> natefinch: +1
<katco> natefinch: ericsnow: agreed
<natefinch> ericsnow: good point about making the arg struct change separate from the functional change.... I was thinking that since I'd have to change each callsite anyway, I might as well do them at the same time... but if I did the arg struct change first, then the functional change wouldn't need to touch any of those lines.... ahh well, I'll do it next time.
<ericsnow> natefinch: no worries :)
 * natefinch lunches
<evilnickveitch> does anyone know what is replacing the 'upload-tools' command?
<evilnickveitch> it seems to be on the list of things to be deprecated, but it isn't clear to me how the functionality will be replaced
<evilnickveitch> sorry ^ i meant sync-tools
<katco> ericsnow: hey you know how yesterday you were saying the endpoints for getting a charm shouldn't include version/archo?
<ericsnow> katco: yep
<katco> ericsnow: i think it needs to include arch for sure since there may be different versions for arch (think jre)
<katco> ericsnow: and version... how will old versions of charms pull down their coupled resources?
<katco> ericsnow: we need a version concept i think
<ericsnow> katco: the mandate was that each arch would have its own resource name
<natefinch> katco: charms, AFAIK, have no concept of arch
<katco> ericsnow: ah ok, missed that one
<natefinch> katco: it's unfortunate, but that is the way they exist now... they only care about series, which is honestly backwards of the way I would have done it.
<katco> natefinch: yeah, i guess apt takes care of most of that, but seems like it should be a 1st-order concept
<katco> ericsnow: and version? i think we need that
<ericsnow> katco: as to version, that corresponds with resource revision (hence the "comment" info we have punted on)
<katco> ericsnow: right, so s/version/revision/g... w/e. i think the concept needs to be there
<ericsnow> katco: I thought it is
<katco> ericsnow: it is... but i thought yesterday you said it didn't need to be
<ericsnow> katco: no, we don't need "version", we still need revision
<natefinch> gah... if we can avoid having both version and revision, let's do that, because, geez that is confusing
<katco> ericsnow: i'm not sure what the diff. is lol, but at any rate it's called revision in the spec
<natefinch> ^^^^^ exactly
<katco> that's what i needed to know... revisions stays in
<ericsnow> katco: I thought there was a "version" field in the API stuff
<katco> ericsnow: not that i can see. the variable is revision, but when discussed it's called version
<ericsnow> katco: my point is that we can update the API spec to look like this: "GET id/resources/name" and "GET id/resources/name-2"
<katco> ericsnow: bc afaict that's the same damn concept
<ericsnow> katco: yeah, I was wrong :)
<katco> ericsnow: i think we still need revision
<katco> ericsnow: for reasons i highlighted prior
<ericsnow> katco: I agree
<ericsnow> katco: its the "-2" in the example I gave
<ericsnow> katco: in the current spec it's the "[-revision]" part
<katco> ericsnow: and actually... the current api spec says that id refers to the charm... does id represent a specific rev of the charm?
<ericsnow> katco: it must
<katco> ericsnow: if that's the case, then we don't need rev
<katco> ericsnow: because it will already narrow the scope of the resource to that rev of the charm, and thus use the correct rev of resource automatically
<ericsnow> katco: [-revision] is the resource revision, not the charm revision
<katco> ericsnow: but the two are coupled
<katco> ericsnow: new rev of resource implies new rev of charm
<ericsnow> katco: ah, right
<ericsnow> katco: the only catch is that you can change the resource revision for a given charm revision
<katco> ericsnow: can you? that contradicts the edict that charms and resources are coupled
<ericsnow> katco: my understanding is that the tuple of (charm rev, resource rev...) is the identifier
<natefinch> yeah, there's a line in the spec that mentioned you can change the revision of a resource for a revision of the charm
<natefinch> there is now a higher-order meta-revision for the charmRev+resourcesRev that we don't reallyhave a name for and doesn't have an identifier... which seems bad
<katco> yeah
<ericsnow> katco: BTW, if the API should support charm IDs that don't have a revision then [-revision] (for the resource) *is* necessary (a point you were making)
<ericsnow> katco: I have a feeling that we'll have to support that
<ericsnow> natefinch: yeah, that
<katco> is this confusing to anyone else?
<natefinch> katco: I had the exact same confusion which I brought up with Rick... because it seemed logical to increment the charmrev when we changed resources... but the charmrev is just for the charm code
<ericsnow> katco: uh, yeah :/
<natefinch> help us rick_h_, you're our only hope
<katco> ericsnow: natefinch: i mean i get it now that it's been explained... but man... i feel like we have this conversation *every* *time*
<natefinch> katco: yep
<ericsnow> katco: I was just thinking that
<natefinch> katco: and if the developers on the project have this confusion, what about users?
<katco> natefinch: yes, this.
<ericsnow> natefinch: they only need to know that they can change a resource revision for a given charm revision
<natefinch> ericsnow: right, but when Bill says "hey, my MySql charm seems broken" and Laura asks "Oh, what version are you running?" ... how is he going to answer that?
<ericsnow> natefinch: yep
<ericsnow> natefinch: not ideal
<katco> natefinch: it does seem broken to not rev the charm when you rev a resource
<katco> natefinch: effectively that's a new build
<ericsnow> katco: identifying your configuration
<katco> natefinch: unless you looks at it like a shared lib which -- as long as it's revving a minor version -- can be swapped out
<natefinch> katco: I think we just need the higher-order concept.  It's very useful to know that between these two charm revisions, nothing in the code of the charm has changed
<katco> natefinch: i agree
<ericsnow> natefinch: I'd say that revving the charm with a resource change would do it
<natefinch> katco: if we had a charm-overall-revision, which always got bumped if anything changed, then at least people could just say "I am running mysql v1.2" and that would relate to a single charm-code-rev and resources-revs
<ericsnow> katco: yeah, though it may make sense to call that the charm revision and call what that is currently something like "charm info revision"
<katco> natefinch: ericsnow: i dunno. why introduce a new concept? why not just have the charm version rev anytime anything with it changes?
<katco> natefinch: ericsnow: any time a piece changes, the whole has changed
<ericsnow> katco: to distinguish between the-charm-changed and a-resource-changed
<natefinch> we should discuss with jam and rick_h_ when they're available. I'm sure they have a reason why it is how it is.
<katco> natefinch: i think we're too close to change anything really, but would be interesting to discuss at any rate
<ericsnow> katco: we've definitely implemented the feature with the understanding that resource revisions are not fixed for a charm revision
<ericsnow> (though the resource names *are* by virtue of the metadata.yaml)
<natefinch> also, keep in mind, you can always upload different bytes for the resources... and then what?  Now you have mysql 1.2, except one of the resources is differnt.
<natefinch> given that, I think having an overall revision that makes any sense is not possible
<natefinch> which sucks... but also doesn't mean someone can't come up with a name for the concept of the tuple of charm-code-rev + resources-revs
<natefinch> preferably without using the word tuple
<ericsnow> natefinch: are you saying that the resource file for a given resource revision may change?
<natefinch> katco, ericsnow: BOOM! 5 more points for this iteration
<ericsnow> natefinch: sweet!!!
<katco> natefinch: duuuuuud! you rock!
<katco> natefinch: you just got us a high score on points for an iteration :D
<katco> natefinch: AND pushed our projected delivery to not just the xenial release, but the FFE deadline
<natefinch> katco, ericsnow: https://www.youtube.com/watch?v=l0e8ZMVqVCc&t=82
<katco> natefinch: wtg crash override
<natefinch> ericsnow: no no... I'm saying that we can't have an overall revision for a charm, because any time you upload a resource, it would invalidate that overall revision,and now you're just on some-custom-revision for your overall-revision of the charm
<natefinch> ericsnow: I was just thinking about the conversation between Bill and Laura... sure, if Bill hasn't uploaded anythnig, he could say he's on mysql 1.2, but as soon as he uploads a custom resource, he has to fall back to talking about charm-code-rev + resource-rev
<ericsnow> natefinch: right, it's a mess
 * natefinch puts on the Hackers soundtrack
<ericsnow> either way
<katco> natefinch: such a good soundtrack
<natefinch> katco: yeah, really awesome soundtrack
<natefinch> we should merge master if we can... the tests keep popping up that annoying browser thingy
<katco> natefinch: i can take care of that
<natefinch> cool
<natefinch> then we can get our latest goodness into peoples' hands
<natefinch> (after merging into master)
<katco> sinzui: will ci run on feature-resources this weekend?
<sinzui> katco: No. CI doesn't test branches on weekends because all resources are used for repeatability and reliability trests
<katco> sinzui: do you think we could get a bless before EoD? that way we can merge into master before EoD
<sinzui> katco: no, lxd is not testing that will take us to about the time branch testing will stop
<katco> sinzui: ah ok
<sinzui> katco: maybe I want to disable weakend tests.
<sinzui> katco: your branch and others might test if I can disable or jut run the minimum set of tests
<katco> sinzui: well, just lmk so i know when we can merge into master
<sinzui> okay katco.
<katco> ericsnow: natefinch: don't forget to email me your 360 picks
<ericsnow> katco: k
<perrito666> ohh picks
<natefinch> katco: oops
<perrito666> I read pics
<natefinch> that is a lot of pics
<natefinch> hope you like pics of my kids
<katco> perrito666: >.<
<natefinch> katco: I'm definitely not choosing ericsnow ;)
<ericsnow> natefinch: me either :)
<katco> natefinch: i've heard of this ericsnow guy. kind of a wild card? really loud? works out of a secret room?
<natefinch> katco: drinks like a fish, too
<katco> natefinch: yeah... that's the one
<perrito666> ericsnow: I prefer your previous background, looked more conspiracy theorist
<ericsnow> perrito666: sometimes I miss that closet, but I get over it a few seconds later :)
<natefinch> ericsnow: aren't you behind a secret door, now?
<katco> natefinch: ^^^ "secret room"
<ericsnow> natefinch: of course not, that's ridiculous!
<natefinch> katco: I just meant, secret door >> closet
<katco> his house is practically the size of a super-villain's secret island
<natefinch> ^ this is true
<katco> speaks parseltongue
<katco> it's legit. ericsnow is an evil character
<ericsnow> katco: I wish none of you had found out; was starting to like you
<perrito666> ericsnow: was definitely more evil character when we had standup in the mornings with wild hair and the creepy basement background
<katco> LOL
 * ericsnow flips some switches
 * natefinch would quit with some mysterious message... but sometimes it takes xchat 5+ minutes to log back in :/
<katco> natefinch: you need a bouncer my friend
<perrito666> or, to learn /leave or /part
<natefinch> aww... learning...
<perrito666> natefinch: btw, there is something wrong with your xchat, I presume it is the fact that you use xchat instead of hexchat
<natefinch> perrito666: it seems to slowly be getting better... maybe it was just a head cold
<perrito666> natefinch: but seriously, hexchat is a fork of xchat with better maintenance
<natefinch> perrito666: I'm all for that
<natefinch> perrito666: of course that requires me figuring out what my password is for the canonical servers
<perrito666> natefinch: xchat2 stores it in plaintext, obviously
<natefinch> perrito666: lol
<natefinch> perrito666: so it does.  Nice
<perrito666> well, I dont know if nice is the word I would use
<natefinch> perrito666, I was being sarcastic
<perrito666> natefinch: irc lacks sarcasm
<natefinch> well, seems to work, and logged right in
<natefinch> perrito666: I think irc lacks non-sarcasm
<natefinch> perrito666: thanks... that was pretty painless, and I'm happy to be on a better maintained product.
<perrito666> happy to help
<perrito666> while I was using it I found it to be very nice
<katco> ericsnow: standup time
<katco> ericsnow: ping?
<rick_h_> natefinch: just walked in from the airport
<rick_h_> natefinch: what's the fire?
<katco> rick_h_: no fire, just friday silliness
<rick_h_> ah then wheeeeee
<katco> rick_h_: you can travel in peace :)
<rick_h_> travel done, now for snow shoveling
#juju-dev 2016-02-27
<mup> Bug #1550579 opened:  model "local.functional-jes:functional-jes-env2" not found <ci> <destroy-model> <regression> <juju-core:Triaged> <https://launchpad.net/bugs/1550579>
<mup> Bug #1550580 opened:  model "local.functional-jes:functional-jes-env2" not found <ci> <destroy-model> <regression> <juju-core:Triaged> <https://launchpad.net/bugs/1550580>
<mup> Bug #1550579 changed:  model "local.functional-jes:functional-jes-env2" not found <ci> <destroy-model> <regression> <juju-core:Triaged> <https://launchpad.net/bugs/1550579>
<mup> Bug #1550586 opened: github.com/juju/juju/tools/lxdclient_test constant overflows int <ci> <i386> <lxd> <regression> <juju-core:Incomplete> <juju-core lxd-container-type:Triaged> <https://launchpad.net/bugs/1550586>
<mup> Bug #1550593 opened: TestAddMetricCredentials failed to register metrics: could not create budget allocation <ci> <go1.5> <go1.6> <ppc64el> <regression> <test-failure> <juju-core:Triaged> <https://launchpad.net/bugs/1550593>
<mup> Bug #1537082 changed: 2.0 cannot bootstrap in AWS, Azure, and Joyent <bootstrap> <streams> <juju-core:Fix Released by anastasia-macmood> <juju-release-tools:Fix Released by abentley> <https://launchpad.net/bugs/1537082>
<magicaltrout> hello, lxd help required ;)
<jam> hey magicaltrout
<jam> sorry about the delay
<jam> the last part seems very strange "bootstrap --upload-tools" saying that there are no tools available. Did you target trusty vs xenial?
<magicaltrout> hey jam no worries i'm trying to keep 2 kids happy whilst debugging lxd ;)
<magicaltrout> you'll have to excuse the quesions, I haven't a clue. Target?
<magicaltrout> i assumed it built tools for the platform it was built on (or all of them)
<rick_h_> jam: we hit that with someone because they were using upload-tools from a mac
<rick_h_> magicaltrout: any chance you're on a different series/os than what you're trying to bootstrap with upload-tools?
<rick_h_> actually series probably doesn't matter?
<magicaltrout> rick_h_: i installed wily, did an upgrade to xenial all before installing go and building juju
<magicaltrout> but i've got trusty and xenial images
<rick_h_> magicaltrout: ah ok, lxd so you have to be on ubuntu. Gotcha.
<rick_h_> sorry, error message triggered recent memory
<magicaltrout> trusty bootstraps but fails because for some reason sshd isn't running after the very first tasks
<magicaltrout> and xenial doesn't work due to missing tools
<rick_h_> magicaltrout: anything suspicious in the cloud-init logs?
<magicaltrout> nothing that fails
<magicaltrout> it does configure the keys and stuff
<magicaltrout> i can dump them to pastebin, 2 mins
<magicaltrout> sorry about the delay
<magicaltrout> addr:84.40.61.82
<magicaltrout> er
<magicaltrout> http://paste.ubuntu.com/15215668/
<magicaltrout> http://paste.ubuntu.com/15215678/
<rick_h_> magicaltrout: looking
<magicaltrout> sshd isn't running though when you log into the images
<magicaltrout> so it will never succeed in connecting :)
<rick_h_> magicaltrout: hmm yea I don't see it trying to install but I'm not familiar enough with cloud-init to see if it's part of some bigger step in there
 * rick_h_ had hoped to see openssh-server or something in the logs
<magicaltrout> well if i login and actually start sshd then it does connect
<magicaltrout> and at that point you get an error about missing nonce files et
<magicaltrout> c
<rick_h_> magicaltrout: did you try just creating an lxd container outside of juju and see if it had ssh?
<magicaltrout> yeah i did
<magicaltrout> it doesn't
<rick_h_> hmm, so it might be the lxd images are missing a step. /me looks where those are.
<rick_h_> magicaltrout: what series is the lxd image?
<rick_h_> that you bring up?
<magicaltrout>  lxc launch ubuntu-trusty my-test-image2 / lxc exec my-test-image2 /bin/bash / ps aux |grep ssh
<magicaltrout> retuns nothing
<rick_h_> magicaltrout: ok, so it's a trusty image?
<magicaltrout> http://pastebin.com/zMUSPT3J
<rick_h_> magicaltrout: can you bring up another series in lxd manaull?
<magicaltrout> ah well xenial has an sshd
<magicaltrout> but i can't run that currently due to missing tools
<rick_h_> magicaltrout: ok, so it's definitely something in the lxd images then
<magicaltrout> how do i generate tools for xenial? that way i can test it with a running sshd
<rick_h_> magicaltrout: looking, I'd have thought upload-tools would work but if you're asking how to create tools the wiki here under "Generating local tools" http://wiki.cloudbase.it/juju
<rick_h_> has some steps
<magicaltrout> juju bootstrap test-lxd lxd --debug --upload-tools --bootstrap-series xenial
<magicaltrout> well thats right, right?
<magicaltrout> like the series name
<rick_h_> the series name is xenial
<rick_h_> I've not used --bootstrap-series before so looking on that one
<magicaltrout> me neither but thats what jam mentioned
<magicaltrout> and without it it boots a trusty node
<rick_h_> yea, looking at old bugs/etc it used to just be --series but looking at the code it's bootstrap-series https://github.com/juju/juju/blob/5585f90a51acd581e154aeb0c638cc279bcc2415/cmd/juju/commands/bootstrap.go#L145
<rick_h_> and when you do that what's the output along side the 'cannot find tools'?
<magicaltrout> http://pastebin.com/iKJ3jt1h
<rick_h_> sorry phone calls and such, /me looks
<magicaltrout> no worries it is saturday :P
<rick_h_> magicaltrout: heh, so found the code for the error, but not enough context around it for me to be helpful unfortunately :/
<rick_h_> magicaltrout: you've definitely gone above and beyond on hoops to try to get it working, but you're in deeper waters now.
<magicaltrout> hehe i know, it was just a friday project to prevent me doing proper work, i had basically abandoned it until jam popped up today, but this seems to be something that might crop up for others as its not an api issue like the lxd beta 2 -> beta 3 issue
<magicaltrout> so i figure i'll keep prodding
<rick_h_> magicaltrout: yea, I definitely think a bug on the lxd precise image is in order for the ssh server
<rick_h_> magicaltrout: and I think the tools is probably some magic trick that folks know that work from trunk more than I do
 * rick_h_ is a lazy person that uses the debs in the PPAs usually
<magicaltrout> hehe
<magicaltrout> also in juju 1 there is juju set-env ... to override the streams and stuff
<magicaltrout> in juju2 juju init has gone
<magicaltrout> so I don't know where you're supposed to override the streams url and stuff
<magicaltrout> although I'm not sure it matters in this case
<rick_h_> magicaltrout: yea, so that stuff is moved to set-controller-config and set-model-cofig
<magicaltrout> okay so my post dinner task is figuring out how to get xenial tools working so that juju can bootstrap it ;)
<mup> Bug #1550770 opened: TestContainerStartedAndStopped cannot create mock container on ppc64el/arm64 xenial/wily <arm64> <centos> <ci> <lxc> <ppc64el> <test-failure> <juju-core:Triaged> <https://launchpad.net/bugs/1550770>
<magicaltrout> alrighty then its 8:45 I have a rum and soda, time to figure out how on earth tools get overridden
<magicaltrout> okay so here's a question for the no one crazy enough to be around on a saturday
<magicaltrout> --upload-tools
<magicaltrout> where doe it get the tools from?
<magicaltrout> rick_h__: fyi, i've just tried to launch a trusty bootstrap and right when it was initialising I told it to switch to init5 otherwise the init level is unknown
<magicaltrout> and juju bootstraps
<magicaltrout> this might be something networking or otherwise, probably cause from my distro upgrade from wily to xenial
<magicaltrout> should I dump it in launchpad if anyone cares to look at it
<mup> Bug #1550810 opened: TestDetectCredentialsKnownLocationWindows missing region <ci> <regression> <test-failure> <windows> <juju-core:Triaged> <https://launchpad.net/bugs/1550810>
<mup> Bug #1550817 opened: TestUniterStartHook: never reached desired status <ci> <i386> <intermittent-failure> <unit-tests> <juju-core:Triaged> <https://launchpad.net/bugs/1550817>
<magicaltrout> jeez louise
<magicaltrout> i figured it out
 * magicaltrout spins up a hadoop cluster to test that theory
<magicaltrout> omg
<magicaltrout> thats like the best $hit ever
<magicaltrout> oh nearly not quite
<mup> Bug #1550819 opened: TestAddLocalCharmUnauthorized mismatch <go1.5> <go1.6> <intermittent-failure> <wily> <xenial> <juju-core:Triaged> <https://launchpad.net/bugs/1550819>
<mup> Bug #1550821 opened: TestSetsAndUpdatesMembers timed out <ci> <go1.5> <regression> <trusty> <wily> <juju-core:Triaged> <https://launchpad.net/bugs/1550821>
#juju-dev 2016-02-28
<magicaltrout> boom most of realtime-syslog-analytics up and running inside lxd
<magicaltrout> thanks for the help today jam, you're lxd provider looks great.
<mup> Bug #1550580 changed:  model "local.functional-jes:functional-jes-env2" not found <ci> <destroy-model> <regression> <juju-core:Fix Released by wallyworld> <https://launchpad.net/bugs/1550580>
<thumper> davecheney: we have lost you
<davecheney> every two weeks
<menn0> master is going to be cursed again due to the race tests
<menn0> the 2 failures are probably quite easy ones
<menn0> http://data.vapour.ws/juju-ci/products/version-3677/run-unit-tests-race/build-1014/consoleText
 * menn0 is not allowed to work on them though
<menn0> but they're the only failures that are likely to curse master
<deanman> How does the aws endpoint gets resolved according to the specified region ? I'm trying to find the endpoint in the code but i can only see references in test files. Any hints?
<davecheney> anyone fancy a little review https://github.com/juju/juju/pull/4553
<blahdeblah> anastasiamac: I got a few minutes over the weekend, and updated that bug we were talking about last week.
#juju-dev 2017-02-20
<blahdeblah> Morning folks; any first guesses at possible workarounds for https://bugs.launchpad.net/python-jujuclient/+bug/1639104 ?  Seems like it might be some sort of mismatch between go & python APIs.
<mup> Bug #1639104: can no longer deploy to model: 'error': 'shared state watcher was stopped' <landscape> <python-jujuclient:New> <https://launchpad.net/bugs/1639104>
<axw> babbageclunk: is 15 minutes earlier ok for you?
<babbageclunk> axw: yup!
<axw> cool
<babbageclunk> axw, wallyworld: Hmm. Actually Ada's just about to start going to preschool at 12:30. So I can do 12:30, but if people were ok with 1pm or later my time then I could take her sometimes.
<babbageclunk> axw, wallyworld: no biggie though
<babbageclunk> axw, wallyworld: I can do picking her up instead
<axw> babbageclunk: we should change so you can take her
 * axw looks up timezones
<babbageclunk> axw: as long as that would still work for you guys
<axw> babbageclunk: 1pm your time wouldn't work for me half the week, as I take my kids to school then
<wallyworld> babbageclunk: yeah, we can change for sure
 * axw thinking
<axw> wallyworld babbageclunk: 9:30am my time, 11:30am BNE, 1:30pm NZ ?
<wallyworld> works for me, so long as you guys are happy with that
<axw> wait, that's not right
<axw> 2:30pm NZ
<wallyworld> until winter
<wallyworld> then it will be 1:30
<babbageclunk> axw, wallyworld: that sounds good to me, thanks guys!
 * wallyworld will adjust invites
<axw> bbs
<thumper> ick
<thumper> found a hard coded port number in the tetss
<thumper> 12344
<thumper> 12345
<thumper> geez
<anastasiamac> thumper: which test?
<thumper> apiserver logstream_Test
<thumper> I'm in there anyway
<thumper> will look to change
<anastasiamac> :( k thnx!
<anastasiamac> wallyworld: did we end up addressing this? related to our favourite --upload-tools :D https://bugs.launchpad.net/juju/+bug/1648752
<mup> Bug #1648752: Juju upgraded to 2.0.2.1 when it reported 2.0.2 was released <jujuqa> <upgrade-juju> <juju:Triaged> <https://launchpad.net/bugs/1648752>
<wallyworld> not yet
<wallyworld> on the 2.2 roadmap
<anastasiamac> yep. m reviewing 2.2 bugs
<anastasiamac> to filter fixed but not updated...
<thumper> bollocks
<anastasiamac> ?
<thumper> down to last few issues with gorilla/websocket
<thumper> there is a test around tls config
<thumper> and the way the different libraries deal with it makes this a challenge
 * thumper needs to work out how to get the right bits
<thumper> I can think of a horrible way...
<thumper> but trying to think of something nicer
<jam> thumper: i know menn0 is out, are you around today?
<thumper> jam: yeah, but just about to talk to babbageclunk
<thumper> jam: did you want to chat still?
<jam> thumper: just as a general "how are things going" nothing particular, though discussing the recent mark request would be good
<thumper> i'll ping you
<thumper> jam: got a few minutes?
<jam> certainly
<axw> jam: standup? or still talking to thumper?
<jam> still talking with tim
<wallyworld> jam: i have a question or two when you're free,maybe ping me?
<jam> axw: wallyworld: ping
<wallyworld> hey
<axw> jam: pong
<jam> axw: did you want to still have a quick catch-up?
<wallyworld> jam: did you want to talk to andrew first? and then me?
<jam> wallyworld: well, if you're closer to EOD, maybe it makes more sense to chat with you
<axw> jam: go ahead and chat with wallyworld
<wallyworld> ok, it that suits
<wallyworld> jam: https://hangouts.google.com/hangouts/_/canonical.com/a-team-standup?authuser=1
<jam> axw: want to chat?
<jam> https://hangouts.google.com/hangouts/_/canonical.com/jam-axw?authuser=1
<axw> jam: brt
<mup> Bug #1666069 changed: openstack provider: juju does not give any error if trusty instance forever in pending because of missing image metadata <juju:Incomplete> <https://launchpad.net/bugs/1666069>
<blahdeblah> Hi folks, how can I get the registration base64 blob for an existing user?
<perrito666> Jam morning I am still booting but wanted to ask you if your techleaderness is going to be manifested in some other way than the org chart, like if you need you Curtis, I and the nonexistent members of the team to standup at some especial time
<jam> perrito666: i had started an email to ask you guys what times would work for you
<jam> and get filled in a bit of what you guys are currently working on
<perrito666> I think we can overlap before your EOD :) I'll wait for the email
<perrito666> Jam are you going to the sprint? I am not sure if your country is among the ones affected by the special migration rules
<jam> perrito666: given my passport is USA, I guess I'm affected, but in a different way :)
<jam> but yes, I'm going to the sprint
<perrito666> They might ask you some extra questions :p I have a friend that went a couple of times to Israel for instance and since he never again entered the us without being randomly selected for questioning :p
<jam> perrito666: well, my wife is Syrian, and I've visited her country in the past. I've done the hour-wait for special interview before
<jam> perrito666: not sure how it will go this time, but I've got a pretty decent layover time
<perrito666> Perhaps we can finally make a case for sprints in Argentina :p
<perrito666> So it's equally far and annoying to everyone
<jam> perrito666: :)
<perrito666> jam: does this invalidate the other standup?
<jam> perrito666: potentially that is up to you. I'd be happy to have you be around for other people since I can't be there at that timezone, but I also wouldn't mandate that you have to be at both standups all the time
<jam> I'd also hope you'd be around a bit for Eric while he's learning the ropes.
<perrito666> jam: Ill be around for eric but if I am in both standups, given all other meeetings that are now in my list I might end up being here somewhere around 12 to 14 hs which is a bit much :p
<jam> perrito666: that's not even a full day. :)
<jam> perrito666: I certainly don't expect you to work extra, we'll try and find a way to keep the schedule manageable for you
<perrito666> jam: I am sure we will, have been working with APAC for the past 2 years, I think one of us should move to AUZ/NZ to fix this :p and bring urtis
<jam> perrito666: can I move during summer and come back for the nice months?
<perrito666> if it wasn't for the fact that I would never again speak on regular hours with the people I know I would already be living in AUS :p
<jam> perrito666: you know people in AUS :)
<perrito666> jam: fair, but I know more people in GMT-3
<jam> perrito666: but if you just want to speak to them in their evening, you still can, harder to go out for drinks, though.
<perrito666> jam: the proposed time for standup is in about 2 mins is that correct?
<jam> perrito666: that was my original thought
<jam> perrito666: is that a time that would work for you?
<perrito666> jam: greatly, but we wont know from curtis until tomorrow :)
<perrito666> jam: wanna catch up?
<jam> perrito666: https://hangouts.google.com/hangouts/_/canonical.com/afternoon-jam?authuser=1
<perrito666> afternoon jam? sounds like a muscal thing
<jam> perrito666: hence the pun
<perrito666> I am there
<jam> one could also pun it on afternoon tea
<jam> perrito666: I can hear you fine
 * perrito666 runs to a room with AC
<perrito666> jam: that was the nice standup setup, for future ones you will have to deal with the humming noise of the AC
<jam> :)
<babbageclunk> morning!
<thumper> menn0, babbageclunk: one of you should reply to the juju mailing list post about proxies
<menn0> thumper: one of us will
<thumper> :)
<perrito666> wow, whatever ubuntu is doing with my dns is really messing my life
<perrito666> all of the possible places that could have a reference to the dns server hold 127.0.1.1 leaving whatever has the actual dns really hiden so i really have a hard time diagnosing dns problems
<menn0> perrito666: yep, dnsmasq is listening on 127.0.1.1:53
<menn0> so that networkmanager has more direct control over DNS resolution
<mup> Bug #1333162 changed: cannot bootstrap on openstack provider:  Multiple security_group matches found for name 'XYZ', use an ID to be more specific. <bug-squad> <charmers> <openstack-provider> <repeatability> <security> <sts> <uosci> <OpenStack Charm Test Infra:Confirmed> <juju:Fix Committed>
<mup> <juju-core:Fix Released> <juju-core 1.25:Fix Released> <https://launchpad.net/bugs/1333162>
<thumper> :(*
<thumper> thought I was mostly done with test failures with this branch
<thumper> but apparently not
 * thumper sighs
<perrito666> menn0: I know, but networkmanager sucks at controlling the dns so when I want to step in I have 0 control since dnsmasq and resolver are configured in a very obscure way
<thumper> damn it
<menn0> perrito666: you can set your own DNS for a given connection in networkmanager
<menn0> not sure if that helps
<menn0> wallyworld, axw: as far I can see we don't pass HTTP/HTTPS/FTP proxy information to cloud-init. does that sound right to you?
<axw> menn0: that sounds wrong
<wallyworld> menn0: could be, it could be that we write instead ~/juju-proxy and rely and that, not sure
<wallyworld> i thought'd we did though
<axw> menn0 wallyworld: there's a ProxySettings in InstanceConfig that should be filled out
<wallyworld> that sounds right
<menn0> wallyworld, axw: ok thanks. i'll keep digging after I run an errand.
#juju-dev 2017-02-21
<babbageclunk> wallyworld, axw: review please? https://github.com/juju/juju/pull/7010
<wallyworld> ok
<babbageclunk> wallyworld: thanks - ended up being a bit stupid
<wallyworld> a one liner
<wallyworld> babbageclunk: lgtm
<babbageclunk> wallyworld: yup - the better fix is lots of lines across 3 packages
<babbageclunk> wallyworld: thanks
<wallyworld> for 2.1 this is fine IMO
<axw> babbageclunk: is that change safe for concurrent AddCharmWithAuthorization calls? will two calls to repo.Get end up getting the same bundle, and one will remove it from underneath the other?
<menn0> wallyworld, axw: during cloud-init, the proxy settings are only used to write out to ~ubuntu/.juju-proxy
<wallyworld> menn0: yeah, that's what i feared
<menn0> wallyworld, axw: which is dumb anyway
<axw> menn0: no, we do also set them for the cloud-init scripts
<menn0> wallyworld, axw: the proxy settings aren't used in any other way
<axw> menn0: see `exportedProxyEnv := w.icfg.ProxySettings.AsScriptEnvironment()`
<axw> menn0: in cloudconfig/userdata_unix.go
<axw> err, userdatacfg_unix.go
<menn0> axw: you're right. I missed that the proxy settings were executed
<menn0> axw, wallyworld: so the one thing we should fix is that the proxy settings should probably be written out to the global profile (which affects all users) instead of just the ubuntu user
<menn0> axw, wallyworld: do you agree?
<axw> menn0: seems reasonable
<wallyworld> i think so
<wallyworld> i wonder why we restricted to ~ubuntu in the first place
<menn0> axw, wallyworld: which is fine except maybe for the manual provider
<babbageclunk> axw: ugh, you're right. Ok, I'll have to go for the more invasive way.
<babbageclunk> axw: thanks though! Luckily the merge failed.
<axw> menn0: if you manually provision, you're handing over the reins. I think it's fine to do that. ideally we would be able to undo on agent uninstall tho
<axw> babbageclunk: nps
<menn0> axw: yep... which should be doable
<menn0> wallyworld, axw: it looks like we don't bother with the proxy settings on windows
 * menn0 files some bugs
<axw> wallyworld babbageclunk: I'm going to be out both standups tomorrow and thursday (dentist, then school assembly)
<wallyworld> no worries
<axw> wallyworld: seems you were right, LXD talks to the source directly
<wallyworld> axw: it was a guess rather than being right :-)
<axw> wallyworld: but the client does need to connect to the source and the LXD as well
<axw> wallyworld: so I think it's that initial bit where it's trying to get the info that's going to be the problem
<wallyworld> right, and that's something we can fix at our end
<wallyworld> albeit a bit hackish perhaps
<thumper> well... bollocks, and more bollocks
<thumper> somehow in my massive pile of changes, I seem to have broken some of the macaroon stuff
<thumper> seems that what used to end up having a successful post to /auth/discharge, now gets:
<thumper> cannot get discharge from \"https://localhost:35994/auth\": cannot acquire discharge: cannot http POST to \"https://localhost:35994/auth/discharge\": Post https://localhost:35994/auth/discharge: x509: certificate signed by unknown authority
<thumper> since this is a test... the tlsConfig should be set to use the CA cert... I think
<thumper> but this is in the http bakery code...
<thumper> so NIF
<thumper> NFI
 * thumper diggs through the code changes to see if I have inadvertantly deleted something important
<thumper> hmm...
 * thumper thinks some...
<thumper> hmm.... I have a cunning plan
<thumper> hopefully not too cunning...
<thumper> gah...
<thumper> I think this is another "localhost" != "127.0.0.1" issue with the bakery apiHost
 * thumper stretches his brain
<thumper> this may or may not work...
<thumper> I'm hoping it will
<thumper> it'll save a lot of pain
<thumper> yay, that fixed the macaroon issue
<thumper> phew
<thumper> now for the others...
<thumper> I may be able to revert some of these other shitty changes I have done
<thumper> reduce the diff size
<thumper> hazaah
 * thumper afk for a bit -- kid pickup
 * thumper-afk headdesks
<thumper-afk> oh
<thumper> FFS
 * thumper takes a deep breath
<thumper> was trying to work out why the mutex values I added weren'
<thumper> weren't stopping concurrent writes
<thumper> then I noticed the reciever wasn't a pointer
<thumper> so every method call got its own mutex
<thumper> awesome
<anastasiamac> nice :( what area r u in?
<thumper> rpc/jsoncodec
<thumper> it was my doing though, adding the mutex
<thumper> because gorilla/websocket has checks for concurrent writes / reads
<blahdeblah> thumper: still around?
<thumper> kinda
<thumper> whazzup
<thumper> ?
<blahdeblah> remember the "mad-hack" you guided me through when we had missing txn-revnos?
<thumper> ah... yeah
<blahdeblah> It's just happened to me for the 3rd time in a different environment, with the same charm.
<blahdeblah> Wondering if it's worth logging a bug
<blahdeblah> (given that it's 1.25.x)
<thumper> really? that is kinda batshit crazy
<blahdeblah> IKR!
<thumper> have you been doing any juju upgrades?
<blahdeblah> this is 1.25.6 and has been for quite a while
<thumper> hmm...
<thumper> is it an environment that is resistent to upgrading?
<blahdeblah> Well, between 1.25.7 and 1.25.9, we were quite resistent to upgrading... ;-)
<blahdeblah> I don't have a problem with upgrading to 1.25.10, but is that going to fix anything?
<thumper> not sure...
<thumper> I'd have to go look at the 1.25.6 codebase
<thumper> blahdeblah: file a bug with as much info as you have, and I'll take a look to diagnose tomorrow
<thumper> it is possible that 1.25.10 will fix, but it probably makes sense to look
<thumper> if I can't find a good answer, at least we can write that on the bug
<blahdeblah> thumper: I kept detailed notes about what we did and last time just stepped through and fixed it
<thumper> assign to me too
<blahdeblah> So I'm happy to go through again and do the same; or would you prefer I left it until we can dive in further?
<thumper> blahdeblah: no, don't wait to fix
<thumper> I'll just be reading code
 * thumper thrashes his computer some more with a full test run
<thumper> babbageclunk, menn0: I found a way around the whole "localhost" != "127.0.0.1" issue
<thumper> much cleaner
<thumper> thank god
<blahdeblah> thumper: OK - thanks
<wallyworld> jam: if you get a chance, i'd appreciate a look at the IngressNetworksForRelation() API implementation in https://github.com/juju/juju/pull/7012. For now I just get state.AllIPAddresses() and filter multicast and loopback. I also filter out IPv6 and AWS didn't like it when updating the security groups
<jam> wallyworld: looking
<wallyworld> thanks
<thumper> hey y'all, got a groovey review: https://github.com/juju/juju/pull/7013
<thumper> although babbageclunk did say he'd take it
<thumper> given that it is huge
<wallyworld> not thaaaaaat big
 * thumper is done
<thumper> laters folks
<mup> Bug #1666396 opened: Missing txn-revnos in mongodb leads to missing status updates <canonical-is> <juju-core:New for thumper> <https://launchpad.net/bugs/1666396>
<axw> anastasiamac: would you please review https://github.com/juju/juju/pull/7014?
<anastasiamac> axw: in a sec but will :D
<jam> axw: "the proxy should reject attempts to connect to its own lxdbr0 address"
<jam> axw: I'm not sure that should be "the proxy should"
<axw> jam: it should :)  what isn't clear?
<axw> jam: the idea is to show that no_proxy is working
<jam> axw: so you said the host's IP address on lxdbr0 is 10.250.243.1, and then you set the proxy as 10.250.243.1 if the proxy is rejecting attempts to connect to that address
<axw> jam: I did also test without no_proxy to show that it *does* fail
<jam> then nothing can talk to the proxy
<axw> jam: specifically, it should reject attempts to connect to 10.250.243.1 *through* the proxy
<axw> I'll reword
<jam> axw: k, that could be spelled a bit clearer
<jam> cause I'm pretty sure you're connecting *to* the proxy via that IP :)
<jam> axw: ugh, just spent 10 minutes searching for the right version, cause we have "github.com/juju/juju/utils/proxy" *and* "github.cqm/juju/utils/proxy"
<axw> jam: heh yeah :/
<jam> axw: we should probably update that code to support CIDR notation
<jam> I see a fair bit of stuff that plays games with the strings instead of using net.SplitHostPort, etc.
<jam> axw: hasPort() => strings.LastIndex(':') > strings.LastIndex(']')
<axw> jam: would be nice, but I don't think $no_proxy supports CIDR normally?
<jam> seems ... fishy
<axw> jam: it does a bit. I think it was lifted from net/http
<jam> axw: yeah, looking at docs it seems it is intended to support domain suffixes instead of IP prefxies
<jam> prefixes
<wallyworld> axw: your PR relies on having env vars for proxies to use in the CLI command. and uses model config for the agent related stuff. IIANM. Is that an issue that these 2 sources could be out of sync?
<menn0> axw, jam: the fishy string monkeying in the net/http proxy handling code has been fixed in recent versions of the Go stdlib
<jam> menn0: sounds like we should update our fork
<jam> wallyworld: I'm somewhat ok with that. "What are the PROXY settings *of my laptop* is not the same as what are the PROXY settings for my cloud"
<menn0> jam: our fork in gh/juju/juju/utils/proxy does the right thing I believe
<jam> menn0: hasPort still does strings.Find
<jam> sorry strings.LastIndex
<menn0> jam: ok right. well in Go 1.6 it's much worse :)
<wallyworld> jam: yeah, that does make sense, but it can lead to confusion for local lxd cloud where everything runs on same host
<menn0> jam: the code looks like current master
<menn0> (Go master)
<menn0> I believe
<jam> menn0: net.http.ResetCachedEnvironment()
<jam> seems to be a thing
<menn0> jam: only in an export_test.go
<jam> yeah
<jam> I just tracked that down
<jam> blah
<menn0> hence all the trickery
<jam> menn0: one of those "if its useful in tests, it would *probably* be useful in production for other people"
<menn0> jam: indeed :)
<jam> nobody would ever change proxy settings on the fly, right?
<axw> wallyworld: that's existing behaviour, didn't want to muck with it right now
<wallyworld> no worries, it does make sense that that's what it needs to be
<axw> wallyworld: i.e. we previously would have honoured $http_proxy in the client, but not used http-proxy from --config in the client
<wallyworld> we should make sure doc is clear
<wallyworld> and maybe print a message if there are differences when using local provider or something? maybe that's overkill
<axw> jam: thanks for the review
<axw> wallyworld: we could print out what proxy settings are detected, might be useful. but not in this PR
<perrito666> does anyone know if tim replicated https://bugs.launchpad.net/juju/+bug/1634178 ?
<mup> Bug #1634178: login doesn't prompt password <ci> <intermittent-failure> <jujuqa> <login> <juju:In Progress by thumper> <juju 2.0:Won't Fix> <juju 2.1:Triaged> <https://launchpad.net/bugs/1634178>
<wallyworld> jam: thanks for review, i've replied to comments etc. i'll take another look, but I could not see subnets being populated from the provider at all - the provider (the aws one I looked at) seemed to populate only the ipadresses collection
<jam> wallyworld: the provider isn't populating subnets, that's the discussion I had with you
<jam> wallyworld: the ipaddresses is only being populated in 2.1 by the JUju machiner watching the local ip devices
<wallyworld> jam: oh, i thought we said maas and aws did (via their NetworkInterface implementation
<jam> wallyworld: but you're missing a bunch of the information, like all the subnets that will be used in the next add-unit
<jam> wallyworld: they aren't?
<jam> aws and MAAS should be
<wallyworld> not that i saw - i traced the code and it all seemed to point to ipaddresses being poulated
<wallyworld> i'll need to look again
<wallyworld> i started using AllSubnets() and it never seemed to get populatred
<jam> wallyworld: all of the "juju deploy --bind space" stuff requires subnets to have values
<wallyworld> hence i looked at the code and saw ipaddresses
<wallyworld> ok, i'll take another look
<wallyworld> i may have misread something
<wallyworld> jam: i'm looking at the discover spaces worker. that seems to want to update the subnets collection, right?
<jam> wallyworld: yeah
<wallyworld> jam: but aws provider does not support spaces discovery
<wallyworld> so maybe it's only maas that will have subnets collection populated
<jam> wallyworld: so for AWS, you do manual "juju add-space" and "juju add-subnet" if you want to use "juju deploy --bind", because we don't know what subnet is in what space if you don't tell us.
<wallyworld> jam: right, so that screws up the firewaller and cmr
<wallyworld> we want cmr to work without adding spaces
<wallyworld> without requiring spaces
<jam> wallyworld: so update the discovery mechanic to record subnets without requiring spaces
<jam> wallyworld: its still *far* better
<jam> else you run into "what machines have I actually deployed so far"
<jam> instead of "what subnets could be in use as soon as I add-unit"
<wallyworld> right, i didn't didn;t think i needed to do that as i thought aws provider populated its stuff
<wallyworld> i'm just seeing a lot of this code for the first time
<wallyworld> not sure what's there already
<jam> wallyworld: to be fair, *it should have*
<jam> wallyworld: (I only saw concrete code a few months ago as well)
<wallyworld> and i'm getting my head across the model etc
<jam> wallyworld: well, I'm pretty solid on how things "should" be, and loosely aware of how things *are*. :)
<wallyworld> ok, so i'll rework the PR to use subnets; the fallabck to 0.0.0.0/0 will work, and then i'll need to add stuff to the providers
<wallyworld> everything is awesome
<wallyworld> "how things are" is interesting, a fair bit to do still
<wallyworld> it seems
<jam> indeed
<wallyworld> jam: so would it be reasonable to modify the discover spaces worker to say that is the provder doesn't support spaces discovery, just ask it for all subnets (if it supports that which i think aws does) and whack those in the subnets collection? my fear is that subnets appear to have a space name attribute and that if we record subnets with a blank space name, things will screw up later
<jam> wallyworld: we're currently treating "" as the "unknown" space elsewher, I think its fine
<wallyworld> jam: ok, i'll see how it goes. i'll look to land this PR after changing t subnets; do a followup which adds the subnet listener to the worker so that as subnets are added async the ingress rules are updated; start fixing the proivders starting with aws to populate subnets info. i wasn't budgeting to that that last bit, nor updating the other providers; hopefully it won't all blow out too much
<rogpeppe1> does anyone have strong feelings about removing colors from vanilla loggo and putting them into a separate package under utils?
<rogpeppe1> we've had problems with all our services producing unparsable logs because of the default behaviour
<rogpeppe> and i don't think it's right that a low level logging package should be pulling a bunch of special dependencies for that purpose
<perrito666> as long as you dont break juju default behavior
<rogpeppe> without colors, loggo has no external dependencies. with them, it depends on 6 large external repositories
<rogpeppe> perrito666: we'll change juju to use the colour writer
<rogpeppe> perrito666: its behaviour won't change until the loggo dep is updated in juju
<perrito666> rogpeppe: wel without colors I would not use juju logger :p so they make sense to me
<perrito666> rogpeppe: I dont have objections then
<rogpeppe> jam, wallyworld: ^ ?
<perrito666> rogpeppe: I would feel better if you enlisted the opinion of thumper since he implemented the colour fancines
 * perrito666 wrote color in brit english just for rogpeppe
<rogpeppe> perrito666: ok, i'll post a mail to the list
<wallyworld> rogpeppe: yeah, best tto ask thumper; i do see you have a point though
<rogpeppe> perrito666: i never see thumper in my time zone
<perrito666> rogpeppe: yes, he seems to be in the exact oposite, would you like for me to ping him so he answers your mail promptly?
<rogpeppe> perrito666: please
<perrito666> rogpeppe: noted
<rogpeppe> perrito666: ta
<rogpeppe> perrito666: i'm sure he'll see my mail to the list anyway
<perrito666> rogpeppe: certainly just making sure he answers asap
<rogpeppe> perrito666: i've sent a message to the list
<perrito666> rogpeppe: tx, I added an item to my todo to talk to thumper as soon as he says good mornig
<rogpeppe> perrito666: thanks!
<perrito666> jam: ping me if you are back around
<cmars> all right, i forget, if i'm going to propose a PR into juju, what should I clone off of / propose merging with? master? develop? staging? whaaa?
<perrito666> cmars: hard question
<cmars> lol
<perrito666> I believe it would be safe to branch staging and propose into develop
<cmars> perrito666, ok, thanks!
<perrito666> cmars: although you might want to ask someone else too, I can never recall if staging is up to date with 2.1
<perrito666> sinzui: ?
<sinzui> perrito666: cmars, for the last 10 days, staging and master have been getting develops blesses. staging is testing the bless develop got a few hours ago.
<sinzui> perrito666: cmars staging/master is NEVER a stable branch. 2.1 and 2.0 are their own histories...
<sinzui> which makes you wonder about the intent to always release off og master
<cmars> hmm
<cmars> i'll start with staging and cherrypick it wherever it needs to go
<babbageclunk> morning!
<perrito666> babbageclunk: morning
<babbageclunk> perrito666: feel like a fairly easy review? https://github.com/juju/charmrepo/pull/110
<thumper> well.... shit
<perrito666> thumper: ah, one of those mornings
<perrito666> thumper: btw, there is a rogpeppe mail that is pretty much just for you
<perrito666> babbageclunk: if you can hold until I return from the supermarket ill gladly review that
<perrito666> also if any of you is very familiar with how juju handled tools in 1.25 there is someone needing help in the private channel :)
<babbageclunk> perrito666: dude, if you don't want to just say so. ;)
<babbageclunk> thumper: feel like a fairly easy review? https://github.com/juju/charmrepo/pull/110
<thumper> perrito666: saw it
<thumper> babbageclunk: how about a call, you can explain you change, and I need a teddy bear
<babbageclunk> ok
<babbageclunk> thumper: ^
<thumper> babbageclunk: https://hangouts.google.com/hangouts/_/canonical.com/lol-wat
<perrito666> back
<wallyworld> menn0: re bug 1666660 - normally we remove the primary document (the model) before any satellite documents. I assume that will be the focus of your fix?
<mup> Bug #1666660: list-models sometimes errors after a migration (before model has been removed) <ci> <model-migration> <juju:New for menno.smits> <https://launchpad.net/bugs/1666660>
<menn0> wallyworld: I'm not working on that at the moment and haven't got a specific solution in mind
<wallyworld> menn0: no worries, was just curious based on the description
<menn0> wallyworld: looking at removeAllModelDocs, it removes the model doc last
<menn0> wallyworld: which will be the problem
<wallyworld> yep
<menn0> wallyworld: at the point it's called the model is marked Dead
<menn0> wallyworld: I suspect that model listing and lookup should avoid Dead models
<wallyworld> we've had similar issues in the past with other entity->subordinate object relationships
<wallyworld> yay mgo txns and not being atomic
<wallyworld> "txns"
<menn0> wallyworld: understood
<menn0> wallyworld: in this case I think it makes sense for removeAllModelDocs to remove the model last
<menn0> wallyworld: in case it fails, leaving the model doc behind makes it possible to retry
<menn0> wallyworld: I think GetModel should ignore Dead models
<blahdeblah> thumper-dogwalk: Did https://bugs.launchpad.net/juju-core/+bug/1666396 make sense?  Please let me know if you need any further information.
<mup> Bug #1666396: Missing txn-revnos in mongodb leads to missing status updates <canonical-is> <juju-core:New for thumper> <https://launchpad.net/bugs/1666396>
#juju-dev 2017-02-22
<thumper> blahdeblah: I'll let you know, thanks for filing it
<thumper> externalreality: Just making some toasted sandwiches, with you in about 15-20min
<externalreality> thumper: +1 for toasted sandwiches. Cya in 20
<thumper> blahdeblah: your comment one seems to be missing the results of the actual calls
<blahdeblah> thumper: That was intentional; mostly for anyone in the general public who runs into the problem but doesn't have access to the pastebins
<thumper> blahdeblah: ah
<thumper> ok
<mup> Bug #1662272 changed: Agents stuck with "dependency not available" <juju-core:Won't Fix> <https://launchpad.net/bugs/1662272>
<wallyworld> thumper: i have a question, got 2 minutes?
<thumper> gimmie 5?
<thumper> wallyworld: now is fine
<wallyworld> sure, HO?
<stokachu> anyone seen this yet: https://bugs.launchpad.net/juju/+bug/1666722
<mup> Bug #1666722: juju 2.1 fails to deploy machines in localhost with lxd 2.9.2 <conjure> <lxd-provider> <juju:New> <https://launchpad.net/bugs/1666722>
<stokachu> not sure why it was marked incomplete though
<anastasiamac> stokachu: i've marked incomplete coz i cannot read the pastebin with log, plz attach log as a file :D
<stokachu> uh
<stokachu> well i can read it just fine
<anastasiamac> :D
<stokachu> k added
<thumper> wallyworld: hangouts dropped you
<thumper> now I get "can't start call due to an error"
<thumper> hazaar
<wallyworld> thumper: yeah, trying to rejoin
<wallyworld> thumper: i'm bacl in join, waititng for people to join
<wallyworld> well i was
<wallyworld> dropped me again
<thumper> I'm still getting error
<thumper> wallyworld: oh well...
<thumper> let's not bother then
<wallyworld> ok
<wallyworld> you answered my question, ty
<anastasiamac> wallyworld: thumper: m looking at some logs from 2.1 today's tip and am seeing 2017-02-21 23:09:40 ERROR juju.state database.go:243 using unknown collection "remoteApplications"
<stokachu> think i figured it out
<anastasiamac> i thought we have dealt with "remoteApplications"?
<thumper> anastasiamac, wallyworld: all access should be behind a feature flag
<anastasiamac> stokachu: m seeing
<anastasiamac> Status:"provisioning error", Info:"A root disk device must have the \"pool\" property set."
<anastasiamac> stokachu: what did u figure? :D
<stokachu> anastasiamac, yea lxd 2.9 requires a pool defined
<stokachu>   root:
<stokachu>     path: /
<stokachu>     type: disk
<stokachu> so that needs to be set in the profile
<stokachu> which it does by default it looks like
<wallyworld> it all was behind a flag as far as i knew. there was an issue in 2.0
<wallyworld> in the megawacther but that was fixed
<stokachu> anyway anastasiamac you can close that issue
<anastasiamac> thumper: m fairly certain feature flag was not enabled on this environment
<stokachu> just requires "pool: default"
<anastasiamac> stokachu: could u plz add a note as to what u did for posterity :D
<stokachu> yea
<anastasiamac> stokachu: and just to confirm, u did not have any fature flags enabled?
<wallyworld> the alest juju 2.1 should set up the profile
<wallyworld> there's nothing that conjure up should need to do
<wallyworld> IIANM
<stokachu> nope no feature flags
<anastasiamac> wallyworld: stokachu is on the latest (from today) 2.1 :D
<stokachu> wallyworld, yea i need to update our spells now
<stokachu> to account for the new way lxd storage works
<stokachu> added a note to the bug
<anastasiamac> stokachu: thnx \o/
<anastasiamac> wallyworld: wallyworld: I am also seeing failures related to trying to config mongo... http://pastebin.ubuntu.com/24043782/
<stokachu> np
<wallyworld> that doesn't make sense, those kernel params do exist
<anastasiamac> wallyworld: Â¯\(ã)_/Â¯
<wallyworld> is this being done inside a container?
<anastasiamac> stokachu: ^^
<stokachu> anastasiamac, what is that from
<anastasiamac> stokachu: from reading the logs u've attached to the bug... were u inside the container?
<stokachu> yes
<wallyworld> those lone numbers don't match
<wallyworld> line
<stokachu> yea im not sure those error messages relate to what i was doing
<anastasiamac> wallyworld: the full log is in bug 1666722 ... m calling as I see it :D
<mup> Bug #1666722: juju 2.1 fails to deploy machines in localhost with lxd 2.9.2 <conjure> <lxd-provider> <juju:Invalid> <https://launchpad.net/bugs/1666722>
<wallyworld> but it implies the latest 2.1 is not being used
<stokachu> this is from my snap which i rebuilt several hours ago
<wallyworld> oh wait
<stokachu> to make sure i pulled in the 2.9 fixes
<wallyworld> sorry, i'm looking at thewrong branch
<wallyworld> sigh, too many tabs
<stokachu> wallyworld, :D
<wallyworld> ok, so just looked, those "errors" are poor debug messages
<wallyworld> sigh
<wallyworld> they can be ignored
<stokachu> wallyworld, all good :D
<anastasiamac> wallyworld: what about "remoteApplications" one?
<wallyworld> NFI. it's harmless. will need more context to track it down. what was the user doing, what commands were being run etc
<wallyworld> everything looks like it's behind the flag
<wallyworld> something is leaking though it seems
<stokachu> wallyworld, also keep in mind i bumped the logging way up
<wallyworld> stokachu: yeah, but here juju was logging this as an error
<stokachu> wallyworld, http://astokes.org/juju/2/api/debugging i do this everytime i need to investigate stuff
<wallyworld> and it should not have been
<stokachu> ah ok
<anastasiamac> wallyworld: i believe that stokachu was just bootstrapping at the time of that message
<stokachu> bootstrap actually worked
<stokachu> it was the deploying of applications
<wallyworld> yeah, that remote things is harmless
<wallyworld> if it showed up after a deploy was run that gives some context
<anastasiamac> stokachu: m not talking about what operation failed but what operation was run when that log message appeared.. it's in your log anyway
<stokachu> ok
<anastasiamac> but since wallyworld is happy there is no impact (and he would know)...
<wallyworld> or so i think
<wallyworld> it doesn't appear to from what i've seen
<wallyworld> just need to track it down and remove the noise
<anastasiamac> wallyworld: m not clear why this mesage would appear if everything is behind a feature flag (regardless of whether it was bootstrap or deploy)
<wallyworld> excactly
<anastasiamac> we have been bitten before by similar things :D
<wallyworld> that's my point
<anastasiamac> k. i'll leave it with u, master
<wallyworld> there's ben a leak somewhere
<wallyworld> it all should be behind a flag. i've looked through the code and it appears that's the case, but something somewhere is misconfigured
<jam> perrito666: pong
<menn0> thumper: tech board?
<axw> jam: still doing standup? do you have anything to discuss?
<jam> axw: brt
<anastasiamac> axw: when u get a chance, PTAL https://github.com/juju/juju/pull/7017
<blahdeblah> anastasiamac: How is 1662272 considered non-critical, if restarting machine-0 agent, juju-db, and unit agent doesn't fix it?
<blahdeblah> Seems like it's 1587644, only with more severe symptoms.
<axw> anastasiamac: LGTM
<anastasiamac> axw: \o/
<jam> axw: anastasiamac: wrt persistent storage, what happens if you destroy the model or even the controller?
<jam> axw: do we intend to leave *persistent* storage as above Model or Controller scope?
<jam> axw: or at least have a way to say "this disk outlives us all"
<jam> axw: (came up in a discussion with anastasiamac about 'destroy-controller' and how it interacts with disks)
<jam> specifically, if the storage is going to outlive the machines we are killing, we probably need to *try* to do a clean shutdown, so the content on the disks can be in a consistent state.
<axw> jam: eventually I want to give users a way of disowning storage, but for 2.2 it'll still be owned by the model
<jam> axw: what are your thoughts about fast-pathing tear-down. I believe right now we tell everything "I want you to die", and then wait for everything to tear themselves down and fire the Dead hooks
<axw> jam: indeed that is what we do. what's the problem?
<jam> axw: it takes 10 minutes to "juju destroy-controller" when you're throwing everything away
 * axw nods
<jam> axw: what value is there in triggering "relation-departed" on a machine that is being terminated
<axw> jam: so I think we want to at least wait for the units to be Dead, because they could interact with external things
<jam> axw: its different if you're just killing 1 machine
<jam> but you also know that you're killing all of its peers
<axw> jam: we also want to clean up manual machines, because their lifetime is not under our control
<axw> jam: we could probably fast-path cloud machines, though there is some interaction with storage at least (destroying an instance with cloud storage attached can have negative consequences)
<axw> IIRC on AWS, destroyin an instance with an EBS volume attached can make AWS sad
<jam> axw: how so? I thought terminating a machine is natural
<axw> jam: I just recall instances getting wedged in a state where they wouldn't cleanly terminate, and having to force-terminate them. pretty sure it's documented too
<jam> axw: so you have to do "umount" inside the instance before terminate?
<axw> jam: indeed. http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-detaching-volume.html
<axw> "You can detach an Amazon EBS volume from an instance explicitly or by terminating the instance. However, if the instance is running, you must first unmount the volume from the instance."
<jam> axw: perrito666: https://github.com/juju/testing/pull/121 is a small tweak to the testing/mgo startup code. On my Mac laptop it only has mongo3.4 and that seems to have changed the content of the "waiting for connections" line.
<jam> the tweak is to be slightly less strict, which I'm hoping is still sane. It seems odd that we would have a different 'waiting for connections' that we *shouldn't* treat as mongo being ready
<axw> jam: LGTM
<axw> jam: I suspect it's to do with how the logging works, it's probably not skipping a frame like on other platforms. not entirely sure tho
<axw> looking at blame in mongo, seems the code that logs that hasn't changed in a way that would explain the difference
<axw> anyway, it's a safe change
<jam> axw: I believe I responded to all of your review comments. Can you look at https://github.com/juju/juju/pull/6988 again?
<axw> jam: sure
<perrito666> It is too early to exist
<perrito666> Jam you have too much faith in me if you expected me to be up and reviewing code at 5:57 am
<mup> Bug #1662272 opened: Agents stuck with "dependency not available" <canonical-is> <juju-core:New> <https://launchpad.net/bugs/1662272>
<perrito666> jam: ping me when you are around please
<jam> perrito666: good morning. It was more of a "I don't know who might end up being around, so I'll leave a note for someone to handle in the future"
<jam> I'm around, just got done with the cloud town hall call
<perrito666> ill wait for the recorded
 * perrito666 started the day with an interesting headache
<perrito666> jam: I thought about the same you mail mentiones (re noproxy) last night but the code is confusing, when tracing where the NO_PROXY contents come from they seem to be ultimately lifted from the env, which makes no sense
<jam> perrito666: there's another one in a couple of hours that is the US based timezones
<jam> perrito666: so there are a couple of things about NO_PROXY, one is that the "proxyupdater" object actually sets the ENV variables
<jam> so that things we spawn have them set
<jam> and we've done some semi-bad things during 'init' times where we potentially race with the values that we're going to be setting in the future.
<jam> however, the concrete "what is in no-proxy" has an answer that I posted in the bug
<jam> where we had a bug about "API server addresses should be in no_proxy"
<jam> which led us to just iterating over APIHostPorts (which can include 127.0.0.1 I'm *pretty* sure)
<jam> we can just always add "localhost" to it, and we can consider if we want to add the target machine's known IP addresses as well.
<perrito666> it does include both localhost address and a third ip which I think is state serveer
<perrito666> duh, I was right next to that code looking for a clearner implementation of no proxy :p
<jam> perrito666: we have a loop of APIHostPorts which happens that all controller machines have a 127.0.0.1 address
<jam> so it isn't really by *intent* that we add 127.0.0.1, its more by accident because we are adding "all known addresses for Controllers"
<perrito666> yes, just landed there, I passed right through it expecting to find a place where we set default values for no proxy instead
<jam> we only set those values if you've set anything in no_proxy
<jam> arguably we should be setting those values either
<jam> a) always
<jam> b) when any of the *_proxy values are set
<jam> otherwise you might set http_proxy, but never set no_proxy, and then we're back to leaving the Controllers as being accessed via a proxy
<jam> to be fair, no_proxy as an env variable seems like a poorly thought out hack that has to be interpreted by every application we interact with
<jam> all which might have small variations on how they use it
<jam> and it seems *very* much focused on Domain names, and *not* on IPs
<jam> and we're pretty heavily abusing it with IPs
<perrito666> jam: I think no_proxy should be set as a default for config values
<perrito666> well, I believe proxying is rather a big hack
<jam> perrito666: we could. Its certainly arguable that what we're doing now is guessing that local traffic shouldn't be proxied, and thus we force our own addresses to not be proxied
<jam> some would say we should flag all IPs for all hosts in the model to not be proxed
<jam> proxied
<perrito666> jam: is there a limit to the size of no_proxy?
<jam> perrito666: I've heard of people doing 'export no_proxy=10.0.0.{1..255}' which means it expands to 255 values*10 chars or so, some have asked to do 'export no_proxy=10.0.{1..255}.{1..255}'
<jam> but I *think* the 65535 version wasn't working
<jam> we could certainly *inside juju* support
<jam> 10.0.0.0/8 sort of syntax
<jam> the problem there is that when we talk to 'wget' or 'curl' they don't do anything with it
<jam> (I should test again)
<perrito666> meh, what will they read?
<jam> perrito666: let me confirm, but I'm pretty sure they just ignore that one
<jam> perrito666: the default golang one says "either its a domain suffix, or its an exact IP match"
<jam> perrito666: curl, at least, doesn't listen to "export no_proxy=192.168.0." or "192.168.0.*" or "192.168.0.0/24"
<jam> I don't know if there *is* an IP based rule that it would respect
<jam> it does respect DNS suffixes
<perrito666> I am a bit worried that we are relying on something half the popular software ignore
<jam> perrito666: well, we aren't, we only support explicit IP addresses,which appears to be supported everywhere
<jam> perrito666: also, anastasia helpfully reminded me about https://bugs.launchpad.net/juju/+bug/1488139 https://bugs.launchpad.net/juju/+bug/1615719 https://bugs.launchpad.net/juju/+bug/1421650
<mup> Bug #1488139: juju should add nodes IPs to no-proxy list <landscape> <network> <oil> <proxy> <juju:Triaged> <https://launchpad.net/bugs/1488139>
<mup> Bug #1615719: [juju-2.0-beta15] during the bootstrap stage the no-proxy config is ignored <openstack-provider> <juju:Triaged> <https://launchpad.net/bugs/1615719>
<mup> Bug #1421650: allow cidr notation for no-proxy <ci> <cloud-installer> <jujuqa> <proxy> <uosci> <juju:Triaged> <https://launchpad.net/bugs/1421650>
<jam> which are things we should be aware of, but don't have to solve everything in one pass
<jam> on #1488139 I mentioned I'm worried about the fact that no_proxy then becomes an O(N^2) bug for everyone
<mup> Bug #1488139: juju should add nodes IPs to no-proxy list <landscape> <network> <oil> <proxy> <juju:Triaged> <https://launchpad.net/bugs/1488139>
<jam> I moved 1421650 to Won't Fix because I don't think we can deviate from interpreting it like the 'standard' that other tools do
<jam> and I'm tempted to mark 1615719 as Wont fix because I think he's just using it wrong, based on how people assume 'no_proxy' works, but doesn't actually work that way
<jam> maybe we should validate the value of no_proxy contains only domain suffixes and concrete IP addresses and fail if you pass a wildcard or CIDR notation?
<jam> that would probably be more helpful
<jam> it might make people unhappy with *us* but at least we're preventing them from setting something that won't actually work
<jam> perrito666: btw, if our fix is changing the model-default value, I think that's a 2.2 vs a 2.1
<perrito666> jam: I was going to target 2.2 actually :)
<perrito666> is a migration required for that? it isnt right?
<jam> perrito666: migration? probably not, upgrade-step ? Maybe
<jam> actually likely, since at the least we would have been putting 127.0.0.1 into the field and wouldn't anymore.
<perrito666> jam: that is what I meant, my django just crept into me :p
<perrito666> the current default is ""
<redir_holiday> morning juju-dev
<redir_holiday> me reboots for new kernel
<jam> evening perrito666, I hope everything is going well
<jam> hi redir
<perrito666> jam: yes, listening to CTH
<perrito666> jam: and also running tests for no_proxy
<redir> howdy jam
<redir> phew email mostly filtered
 * redir puts on OCR hat
<babbageclunk> wallyworld: hey, I'm updating the validation in the model description to know about remote applications.
<babbageclunk> wallyworld: at the moment it checks that there is a correspondence between the application units and the endpoint units.
<babbageclunk> wallyworld: There isn't really the same thing with the remote applications, is there? Are there unit settings for the remote units in the local db?
<babbageclunk> wallyworld: I think I've forgotten most of the Barcelona braindump
<wallyworld> babbageclunk: sorry, was in release call, just finished, did you want to chat now?
<babbageclunk> wallyworld: yes please!
<babbageclunk> wallyworld: standup HO?
<wallyworld> sure
<wallyworld> anastasiamac: 4:30pm is likely to be school pickup so i'll be a few minutes late to meeting
<anastasiamac> wallyworld: would 5pm b better?
<anastasiamac> wallyworld: i know there is soccer...
<wallyworld> yeah, i can squeeze in 5
<anastasiamac> i'd rather u ddi not squeeze ;) but i'llmove the meeting \o/
<redir> Oi, IDM rears its ugly head again
#juju-dev 2017-02-23
<wallyworld> axw: when you get back online, if you have a chance pretty please https://github.com/juju/juju/pull/7021
<axw> wallyworld: swap you? :) https://github.com/juju/juju/pull/7015
<wallyworld> sure
<axw> wallyworld: not a very fair trade, except that you've reviewed most of that PR before
<axw> might be long enough ago that you've forgotten it though
<axw> wallyworld: it can wait a bit if you're busy
<wallyworld> axw: tis ok, yours is +500/-200, mine is +700/-70, about the same really :-)
<axw> wallyworld: yeah, yours is a lot of boilerplate though :)
<wallyworld> it is, i wish we didn't need so much of that
<redir> at least it is sturdy if not reusable:)
<wallyworld> axw: yeah, i started to remember the code once i read the PR. LGTM, I'm just ducking out to get lunch
<axw> wallyworld: thanks
<thumper> anyone https://github.com/juju/juju/pull/7022
<babbageclunk> wallyworld - did offer-name just go away on remote applications?
<babbageclunk> wallyworld: (Where "just" = in the last day or so.) I have it on my description and now can't see why I added it.
<wallyworld> babbageclunk: nothing has changed in the last day or so
<wallyworld> babbageclunk: the state object still has it - but it may not always get set
<wallyworld> yet
<babbageclunk> wallyworld: but there's no offer-name field in the remoteApplicationDoc?
<wallyworld> babbageclunk: line 34 of remoteapplication.go
<wallyworld> in state
<babbageclunk> wallyworld: should I be working against 2.1 or develop?
<wallyworld> develop!
<wallyworld> 2.1 is for hosted juju beta and container networking only
<babbageclunk> wallyworld: gah, that'll be it. Sorry, was losing it there.
<wallyworld> no wuckers
<babbageclunk> hey veebers raised bug 1667172 for adoptresources on GCE - I'll jump on that once I finish this, ok?
<mup> Bug #1667172: Migrated model fails to be removed from list-models in GCE <ci> <gce-provider> <model-migration> <juju:Confirmed for 2-xtian> <https://launchpad.net/bugs/1667172>
<wallyworld> sure ty
<wallyworld> axw: i'm hopeless at names, but i sort of did have the same hesitation. Perhaps "networkmanager" or "networks"
<axw> wallyworld: remotenetworks? it's meant for access by a remote model only right?
<wallyworld> yeah
<wallyworld> but it could point to a local model also
<axw> wallyworld: local as in local to the controller?
<wallyworld> yeah, it could (nothing stops it). but the intended usage is to go to a remote model
<axw> wallyworld: I don't think we need to make a distinction there, as long as they can auth
<wallyworld> right, hence just "networks" rather than remotenetworeks
<wallyworld> "remoterelations" is so called because the objects are remote relations
<axw> wallyworld: I meant remote as in cross-model, rather than cross-controller
<wallyworld> i think we're in violent agreement?
<wallyworld> "networks" reflects the semantics of the facade, not where it might point to
<axw> wallyworld: I just want the name to convey the limited scope
<axw> wallyworld: I guess networs is OK. maybe get jam's opinion later
<axw> networks*
<wallyworld> ok. you can give the a facade any model api connection and it will operate against that model (in any given controller) regardless of the model against which the worker is running
<axw> wallyworld: yes, I know. but the name we give might suggest that you could do more than you should be able to. people have a tendency to chuck unrelated functionality together, and an uninformative name makes that more likely to happen
<wallyworld> in the remoterelations worker, we define an RemoteRelationChangePublisher interface - the semantics is that it publishes changes to a remote relation entity, and just so happens to do so to the model connection which it is given, which will be a different model to the worker
<wallyworld> i agree we can tend to lump stuff together
<wallyworld> i'll get confirmation on the name
<wallyworld> assume "networks" for now
<anastasiamac> axw: wallyworld: 1 line trivial :D https://github.com/juju/juju/pull/7023
<axw> anastasiamac: LGTM
<anastasiamac> axw: \o/
<wallyworld> axw: i'm relocating before next meeting, have pushed changes to that PR whenever you have a chance
<axw> wallyworld: thanks, looking
<wallyworld> ta
<wallyworld> bbiab
<wallyworld> jam: with a new facade to provide WatchSubnets(), and also IngressSubnetsForRelation() which I will be moving off the RemoteRelationFacade, do you like the name "Networks" for the facade?
<jam> wallyworld: hi. offhand "Networks" seems way to generic. I like having it have "Remote" in the name, to mean "these are the type of queries something that is not 'native' to this model can access"
<wallyworld> jam: but that's not the semantics offered by the facade
<jam> it wouldn't have to be Remote, but we certainly do consider CMR to have workers that think about their "own" model and a "different" model
<wallyworld> WatchSubnets() just watches subnets on a model
<wallyworld> any model
<wallyworld> the model it watches is defined by the connection it is given
<wallyworld> just like any other facadde
<wallyworld> we dure do have many other generic facade names too :-)
<wallyworld> "charms", "machine", "spaces"
<jam> wallyworld: but the *intent* is to offer a restricted subset
<jam> else we end up with lots of things piled into the facade
<jam> because the local stuff wants it
<jam> but we shouldn't let remote stuff see it
<wallyworld> that's what an authorizer is for
<jam> wallyworld: generally we try to group things on a Facade that act similarly
<wallyworld> sure
<jam> wallyworld: we have followed the pattern to date that a worker matches a facade
<wallyworld> many workers use > 1 facade
<jam> wallyworld: I'd worry about "these 2 methods are useful for this kind of thing, but these 4 are for other things"
<wallyworld> if we expect worker to facade to be 1:1 that is plain wrong IMO
<wallyworld> different layers
<jam> wallyworld: what workers concretely use >1 facade, we generally have merged 'common' functionality to provide facade groupings
<jam> that's why lots of facades embed some sort of "common.Lifer" etc
<wallyworld> remote relations worker is one
<wallyworld> enforcing worker to facade to be 1:1 romotes big ball of mud
<jam> wallyworld: so "remote" concretely *has* to use 2 facades because you're talking about 2 models
<wallyworld> facades should be cohesive. not kitchen sink
<jam> wallyworld: "this is the collection of APIs that are useful for X" is not a ball of mud
<wallyworld> no, it uses 2 facades because of semantics
<jam> it actually concretely splits things up for each worker
<wallyworld> not due to which models are connected to
<wallyworld> it is a ball of mud when the apis have no semantic grouping
<jam> wallyworld: the semantic grouping is the functionality of the worker they are providing
<wallyworld> i guess we differ on what the layering strategy is
<wallyworld> that's where i diagree
<jam> wallyworld: so, by all means we can discuss it at Tech Board level, but I *do* think its how we've done the code to date
<wallyworld> not me :-)
<wallyworld> i guess we've all gone down different roads
<wallyworld> with no common direction
<jam> so other than RemoteRelations, what other workers?
<wallyworld> i'd have to check, maybe i'm over estiating
<wallyworld> but I don't want to add these network apis to the firewaller facade
<wallyworld> they are for network related semantics
<jam> wallyworld: they don't belong there if they are talking about the remote side
<wallyworld> not opening api ports etc
<jam> because you *shouldn't* have access to all the other things firewaller needs from the remote side
<wallyworld> they don;t belong there if the semantics differnot due to the model they talk to
<wallyworld> those re orthogonsl concerns
<jam> wallyworld: IMO, there should be the group of things that you talk about to your local model, and a group of things that you talk about to the remote model
<jam> clustered by the worker that needs them
<jam> and shared via a "common" directory that can be embedded
<wallyworld> the remote relations facade is named after the domain object it operates on, not the type of model
<wallyworld> just a btw
<jam> wallyworld: we *definitely* moved away from having a Machine facade and a Unit facade and everything exposed by domain object
<wallyworld> not necessarily by domain object - IMo groupings are by semantics
<wallyworld> which sometimes but not always correlate somewhat with domain object
<wallyworld> deployer worker uses 2 facades
<wallyworld> as does machiner
<wallyworld> and upgradesteps
<wallyworld> jam: so i don't get blocked with arguing about names, if I used the name "remotenetworks" for now, I could land and also fix later if needed?
<wallyworld> i have work queued up behind this PR
<anastasiamac> axw: wallyworld: nice and easy one plz :D https://github.com/juju/juju/pull/7025
<axw> anastasiamac: looking
<axw> wallyworld: I'm getting a lot of noise in my logs from the firewaller saying that RemoteRelations is not implemented
<axw> wallyworld: the worker is bouncing because I don't have the feature flag set
<perrito666> morning all
<wallyworld> axw: damn, ok will fix in current pr as a driveby before landing
<jam> morning perrito666
<jam> (bit delayed :)
<redir> morning juju-dev
<redir> morning perrito666
<perrito666> redir: morning
<joedborg> hello all.  does anyone know if there's a juju command to monitor which set_states are being called in real time?
<jam> anyone feel comfortable reviewing a patch against gomaasapi?
<jam> https://github.com/juju/gomaasapi/pull/63
<redir> jam looking
<mup> Bug #1667419 opened: Juju 1.25.10 non-HA cpu/ram usage spike (can't apply changes to env) <canonical-bootstack> <juju-core:New> <https://launchpad.net/bugs/1667419>
<redir> jam done
<redir> perrito666: does this https://pastebin.canonical.com/169528/ look falmilar? Did you do something with that?
<perrito666> looking
<perrito666> I did not do anything about it, it is not a bug except for the bad error message
<perrito666> the error message shouhld say that the user used to be there but is no more
<redir> perrito666: the error on line 7?
<redir> and 43?
<redir> or one of the other error messages?
<perrito666> both
<redir> permission denied?
<perrito666> also that should perhaps not be permission denied but user deleted
<redir> OK
<redir> perrito666: or diabled if that is the case, yes?
<redir> s/disabled
<perrito666> no, its not disabled
<perrito666> because you cant re-enable it
<redir> hmm
<perrito666> redir: note that there is a disable command too
<jam> perrito666: btw, redir has been active working with KVM and might be another person who could investigate https://bugs.launchpad.net/juju/+bug/1666198
<mup> Bug #1666198: Juju doesn't disable dhclient in KVMs <juju:Triaged> <https://launchpad.net/bugs/1666198>
<jam> or at least give some advice
<jam> redir: for context, when we deploy a KVM container, we allocate a static address from maas, and get it configured for the interface in the container
<jam> but it appears that we still have dhclient running
<jam> meaning it only keeps its static address until the lease times out
<rick_h> jam: we had that issue with lxd in the path as well I thought
<jam> rick_h: we inject /e/n/i before lxd containers are up via the "push file" api
<jam> (assuming you mean past rather than path)
<rick_h> jam: ah, I might be thinking of https://bugs.launchpad.net/juju-core/+bug/1579148
<jam> rick_h: so they come up first time with the right settings (AFAIK), certainly ante concretely didn't have problems with lxd containers, and did with kvm
<mup> Bug #1579148: dhclient needs reconfiguring after bridge set up <network> <juju:Fix Released by dooferlad> <juju-core:Fix Released by dooferlad> <juju-core 1.25:Fix Released by dooferlad> <https://launchpad.net/bugs/1579148>
<redir> jam: tx for the details.
<redir> perrito666: yeah I'm aware of disable-user
<redir> perrito666 jam I never had to go too deep into the network bits, but I think that happens at container/kvm/kvm.go:CreateContainer where we call containerinit.WriteUserData
<redir> which eventually calls cloudconfig/containerinit/container_userdata.go containerinit.newCloudInitConfigWithNetworks
<thumper> morning
<redir> morning thumper
<redir> jam perrito666 http://paste.ubuntu.com/24055218/
<perrito666> redir: I am sure that makes sense to you
 * perrito666 reads backlog
<redir> perrito666: sorry that is the generated cloud-init for a kvm container
<redir> which is created in the above noted locations
<redir> hopefully that is helpful
<redir> :)
<perrito666> redir: tx man
<redir> np
<rick_h> perrito666: or wallyworld up for a hand?
<perrito666> rick_h: trapped in a call vortex
<rick_h> perrito666: understand
<redir> whatsup rick_h ?
<rick_h> redir: I'm trying to figure out some api-isms
<rick_h> redir: I've gotten part way but not happy with what I've got
<redir> rick_h: which api?
<rick_h> redir: things around the ModelManager apis
<rick_h> redir: especially around uuids vs model names and such
 * redir puts on his rubber duck hat
<rick_h> hah
<redir> and
<rick_h> I want to deal with model names but can't figure out how to get a uuid from that w/o making an api call that needs a model tag which is a uuid-based tag
<redir> so you have a model name and you want to get a uuid for it
<redir> ?
<rick_h> redir: yes
<redir> is this from the gui or in core?
<rick_h> redir: this is in python against the core ai
<rick_h> api
<rick_h> redir: e.g. atm I'm calling ModelList, looping through the results, and loading the uuid when the name matches something I found
<wallyworld> rick_h: hey, sorry, was making coffee
<rick_h> wallyworld: all good, very important coffee
<rick_h> wallyworld: want to have our chat today?
<wallyworld> sure
<wallyworld> now?
<rick_h> sure
 * redir wanders off
<babbageclunk> thumper, wallyworld: could you guys look at https://github.com/juju/description/pull/1 ?
<wallyworld> babbageclunk: in release call, will look soon
<babbageclunk> wallyworld: Oh, I guess you're both in there. Ok, thanks
<wallyworld> babbageclunk: thumper isn't here :-)
<babbageclunk> wallyworld: yay thanks, I'll chase thumper more assiduously
<babbageclunk> hmm, not quite the right word but fun to say
 * thumper ran to physio
<perrito666> ok, I completely forgot where upgrade steps live, someone?
<axw> perrito666: "upgrades"
<axw> github.com/juju/juju/upgrades
<perrito666> found it
<perrito666> its nice and clean, only 3 versions
<perrito666> meh, we are still calling the state functions, how sad
#juju-dev 2017-02-24
<axw> wallyworld: might be a tad late, 5 mins or so
<wallyworld> ok
<axw> wallyworld: I'm in
<wallyworld> axw: ok, be there in a minute
<babbageclunk> anastasiamac: any problem with me pushing a fix for bug 1667172 to the 2.1 branch now? I think we'd want it in 2.1.1 rather than 2.2.
<mup> Bug #1667172: Migrated model fails to be removed from list-models in GCE <ci> <gce-provider> <model-migration> <juju:Triaged by 2-xtian> <https://launchpad.net/bugs/1667172>
<wallyworld> babbageclunk: +1 from me
<babbageclunk> wallyworld: cool cool - feel like an easy review too? https://github.com/juju/juju/pull/7031
<wallyworld> sure
<babbageclunk> wallyworld: I'm on that other test failure now.
<wallyworld> \o/
<axw> babbageclunk: are you doing OCR today? or you busy on bugs?
<babbageclunk> axw: I can do a review
<axw> babbageclunk: can you please look at https://github.com/juju/juju/pull/7026?
<babbageclunk> axw: looking
<babbageclunk> axw: LGTM
<axw> babbageclunk: gracias
<babbageclunk> axw: Wah, I was going to go onto 7027 but it's very long!
<axw> babbageclunk: no worries
<babbageclunk> axw: queueing theory requires that I look at other ones first for best throughput.
 * babbageclunk has been neglecting OCR duties.
<axw> babbageclunk: btw: craven happens to be my middle name, but LXD storage is a feature we intend to implement anyway ;)
<axw> just not scoped for this cycle
<babbageclunk> axw: yeah - I figured it was something we wanted. Features that make it easier to test stuff have compounding value, makes sense to do them earlier.
 * axw nods
<babbageclunk> Can we change the default branch for PRs for juju/juju to develop?
<babbageclunk> Also, can someone with permission (thumper/axw/wallyworld?) change the target branch for https://github.com/juju/juju/pull/7028 to be develop?
<thumper> babbageclunk: can you not?
<thumper> babbageclunk: done
<babbageclunk> thumper: I don't think so
<babbageclunk> thumper: no, I tried again.
<thumper> babbageclunk: do you not see an "Edit" button to the right of the PR name?
<babbageclunk> thumper: nope - I don't think I have commit privs on juju/juju
<babbageclunk> thumper: Will there be any problem merging that with the merge commits in it? Shouldn't be, right?
<thumper> I don't think so
<axw> wallyworld: when you have some breathing room, can you please look at https://github.com/juju/juju/pull/7027
<wallyworld> sure
<thumper> OK, I think I have solved the backup / restore failures with gorilla/websocket
<thumper> will fix later...
<thumper> now dinner
<thumper> laters folks'
<wallyworld> axw: just a minor typo
<axw> wallyworld: thanks
<axw> wallyworld: this will most likely be the first storage provider that'll support shared filesystems
<wallyworld> \o/
<jam> perrito666: redir: google search for "ifdown doesn't stop dhclient" comes up with many bugs, we may just have to add a "dhclient --kill" or whatever the command is
<jam> looks like it is "dhclient -r"
<jam> (release the lease and die)
<jam> vs (-x) just die
<redir> hello juju-dev
<perrito666> hello redir
<redir> perrito666: still around?
 * redir goes for a run
<redir> bbiab
#juju-dev 2017-02-25
<redir> back
<perrito666> Redir eod eow and good bye man, see you online
<redir> have a great weekend perrito666
<redir> it's been great:)
#juju-dev 2017-02-26
<babbageclunk> morning!
<thumper> morning
<anastasiamac> thumper: o/
<babbageclunk> morning thumper and anastasiamac (and menn0)
<menn0> babbageclunk: morning
<babbageclunk> Anyone see this in the Go Newsletter? http://blog.zikes.me/post/how-i-ruined-office-productivity-with-a-slack-bot
<thumper> nope
<babbageclunk> well now you have
<menn0> babbageclunk: haha, that's awesome
<menn0> babbageclunk: are you going to create an irc bot which does the same?
<babbageclunk> menn0: I guess we should use photos of thumper? I could see wallyworld working pretty well too. Maybe just put photos of everyone in there.
<thumper> pfft
<wallyworld> i'll use one of my arse, will look better
<thumper> babbageclunk: remember last week there was a proxy bug
<thumper> babbageclunk: do you remember waht it was?
<thumper> I think the work you did initially had an issue quickly fixed
<babbageclunk> thumper: yeah... it wasn't getting the proxy settings from the environment on bootstrap
<babbageclunk> thumper: why?
<thumper> babbageclunk: would it be this issue? http://reports.vapour.ws/releases/issue/57d2b3c7749a563361b9ea25
<thumper> veebers: ^^
<thumper> babbageclunk: because I figured out the bug with gorilla/websockets and backup/restore
<thumper> and I was just about to repropose when I noticed that sinzui said that it also broke proxy bootstrapping
<thumper> which seemed weird
<babbageclunk> thumper: that does seem weird - I've got 1:1 with wallyworld but then I'll check it out.
<wallyworld> babbageclunk: i realised i forgot to add a video call
<wallyworld> added now
<babbageclunk> wallyworld: yeah, was just looking for that
<babbageclunk> thumper: actually, that sounds like one that axw was looking into - proxying in lxd
<rick_h> howdy wallyworld, was the leak from the syslog stuff in develop?
<wallyworld> econtext
<wallyworld> what leak from syslog?
<wallyworld> 2.0 doesn't use syslog anymore
<rick_h> wallyworld: wasn't there a memory leak that was related to syslog shipping of events or something?
<rick_h> wallyworld: sorry, remote log sending or something we talked about last week?
<rick_h> wallyworld: ok, a known memory leak?
<wallyworld> yeah, the log sink entity to receive log messages from agents
<rick_h> wallyworld: right, that one. Is there a fix for that in develop?
<wallyworld> it is fixed by the transition to gorilla websockets
<wallyworld> so yeah, in develop also
<rick_h> wallyworld: ok, cool
<wallyworld> will be fixed for 2.2 but not 2.1.1
<rick_h> wallyworld: ah ok
<wallyworld> adding in gorilla websocks is quite a big change
<rick_h> wallyworld: did some beating of 2.1 deploying 1k+ models of a three charm bundle over the weekend and want to make sure if I test develop I can get a diff https://goo.gl/photos/awTnNCA9TGn4LT6t9
<rick_h> wallyworld: k
<wallyworld> that graph should hopefully look different once gorilla is merged into develop
<rick_h> wallyworld: cool, will check it out later on. just wanted to prove out my scripts/etc were working out over the weekend
<rick_h> and that maas would stand up to 1k repeated deploys
<wallyworld> looks like they were
<wallyworld> the gorilla stuff did land but was reverted due to an issue with backup/restore
<thumper> rick_h, wallyworld: the gorilla/websockets work was reverted from devel due to failing backup/restore test
<thumper> I think I have fixed it, working with veebers now to check CI tests
<wallyworld> that's what i just said above :-)
<thumper> yeah
<thumper> sorry
<wallyworld> :-)
<thumper> didn't read the last line
<wallyworld> thumper: rick_h has some nice test scripts to hammer the controller, will be good to see results after your change lands
<thumper> yeah
<anastasiamac> wallyworld: in ur awesome cmr work, do u have an answer for bug 1667268 or is it future plans for like 2.3+?
<mup> Bug #1667268: Unable to tell if a remote unit has joined a relation <juju:New> <https://launchpad.net/bugs/1667268>
<wallyworld> "awesome" - you forgot the air quotes
<anastasiamac> no air quotes needed :) ur work, right?
<wallyworld> anastasiamac: that's not cmr
#juju-dev 2018-02-19
<wallyworld> thumper: meeting?
#juju-dev 2018-02-20
<anastasiamac> thumper: wallyworld: state layer in support of 'show-credential' command, PTAL :D https://github.com/juju/juju/pull/8399
<anastasiamac> i'll proposing by layer for readability since few ppl have context... i do have the whole stack in my prototype branch tho :) so the sooner this onelands, the sooner we can get the rest of it to have a new command out in the wild:)
<wallyworld> anastasiamac: sorry, missed ping, looking now
<wallyworld> anastasiamac: if you want, here's a 2.3 PR which fixes the simplestreams image metadata caching issue https://github.com/juju/juju/pull/8400
<anastasiamac> wallyworld: nice question.. do i want...
 * anastasiamac looking :)
<salmankhan> Does someone know how to update dns entries in LXD containers alreay deployed by JUJU
<salmankhan> *L X D
<salmankhan> if I change /etc/resolv.conf or network interfaces file manually, it gets reverted on container restart
#juju-dev 2018-02-21
<wallyworld> babbageclunk: would be awesome to get the caas containers PR looked at before your EOD if you get a chance
<babbageclunk> wallyworld: ok, pushing this and looking now
<wallyworld> awesome sauce
<babbageclunk> wallyworld: do you want to look at https://github.com/juju/juju/pull/8380 again before I try to merge it?
<wallyworld> babbageclunk: doing interview, should be ok though?
<babbageclunk> ok cool - I'm gonna kick it off now then.
<babbageclunk> wallyworld: approved
<wallyworld> yay, ty
<babbageclunk> wallyworld: yay, finally landed!
 * babbageclunk goes for a celebratory run
<wallyworld> whoohoo
<chrome0> Heya folks, do you have any ETA for a juju 1.25.14 release? Eagerly waiting for a release for bug #1729930
<mup> Bug #1729930: juju.state.leadership manager.go:72 stopping leadership manager with error: state changing too quickly; try again soon <sts> <juju-core:Fix Committed by axwalk> <https://launchpad.net/bugs/1729930>
<jam> anyone up for reviewing a patch that cleans up peergrouper logging: https://github.com/juju/juju/pull/8410
<jam> and the same patch into 2.4 https://github.com/juju/juju/pull/8411
<jam> well, bringing in Tim's work on 2.3 that actually fixes the intermittent test, and combining it with my cleanups to peergrouper, and resolving conflicts with manadart's network changes
<jam> manadart: ^^
<manadart> jam: I can look at #8411
<jam> manadart: 8410 has a bunch of "why am I changing this comments" that I made, so it might be easier to start there.
<manadart> jam: Ack.
<manadart> jam: Reviewed.
<veebers> Hi All, anyone have a juju/juju PR ready for merge? I want to make a fix to the merge job and want to monitor the run
<wallyworld> rogpeppe: looks like there's a jimm change needed. juju core itself is fine
<rogpeppe> wallyworld: what change is needed?
<rogpeppe> wallyworld: i'm a bit surprised because i'd've thought it was still serving the same API
<wallyworld> the api facade clients in core have been updated to fill in "iaas" where the ModelInfo structs returned from the api have an empty ModelType field
<wallyworld> i could also accept an empty model type further downstream and fill in iaas
<rogpeppe> wallyworld: i don't understand why the facade clients aren't filling in the empty model types received from jimm
<wallyworld> different code base
<wallyworld> doesn't jimm have it's own client facades?
<wallyworld> the api layer i mean
<rogpeppe> wallyworld: it does, but i don't see why the juju client isn't doing this
<wallyworld> it is for core
<rogpeppe> wallyworld: the juju client used with jimm is the same as for any juju server
<wallyworld> that doesn't make sense then, as core CLI works fine
<rogpeppe> wallyworld: it doesn't behave fine when it's talking to a jimm controller
<wallyworld> an older controller will return empty type value and the api client fills it in
<rogpeppe> wallyworld: isn't that what jimm is doing?
<wallyworld> there's3 places in the api layer that were changed
<rogpeppe> wallyworld: not filling it in, i mean, but returning an empty type value
<wallyworld> yes, and the api layer should be filling it in. core CLI works fine
<wallyworld> so i'm confused
<rogpeppe> wallyworld: it's the core CLI that i'm using
<rogpeppe> wallyworld: and i've pasted the full API interaction in the bug
<wallyworld> hmm, i tested with core CLI too
<wallyworld> against an old 2.3.3 controller
<wallyworld> worked fine
<rogpeppe> wallyworld: yes, but you didn't test with jimm
<rogpeppe> wallyworld: i.e. with a jimm controller
<wallyworld> what's the difference?
<rogpeppe> wallyworld: it fails to work :)
<rogpeppe> wallyworld: did you try my repo instructions?
<wallyworld> a jimm controller will return the ame thing - an empty type
<rogpeppe> repro
<rogpeppe> wallyworld: yup, but it fails
<rogpeppe> wallyworld: i don't understand the difference either
<wallyworld> right and it makes no sense why - an empty field is an empty field
<rogpeppe> wallyworld: well, first see if you can reproduce
<rogpeppe> wallyworld: then you can debug to see what's going on
<wallyworld> ok, guess i'll need to make a jaas account :-)
<rogpeppe> wallyworld: you don't need a jaas account
<rogpeppe> wallyworld: you just need to log in with usso
<rogpeppe> wallyworld: which you'll be prompted to do
<rogpeppe> wallyworld: what's your USSO id? i'll make sure you're granted access to a model
<wallyworld> rogpeppe: i found it - there is old legacy code that i missed when adding in the missing value
<wallyworld> it's a quick 3 line fix
<wallyworld> sigh, sorry
<rogpeppe> wallyworld: ok, thanks
<wallyworld> makes sens now
<rogpeppe> wallyworld: np
<rogpeppe> wallyworld: BTW you should use jaas - it's useful :) :)
<wallyworld> if i had a need to i would :-)
<wallyworld> but for development i need to run up bespoke cloud deployments
<babbageclunk> veebers: did you find a candidate for your job test?
<babbageclunk> cause there's one here: https://github.com/juju/juju/pull/8413
<babbageclunk> Feel free to approve it if you look at it. ;)
<veebers> babbageclunk: I haven't yet, I may have now :-)
<veebers> babbageclunk: Sweet, LGTM I'll update the job and $$merge$$ it
<babbageclunk> veebers: ta
<veebers> cool, I had to repeat myself but the merge process is in motion. I'll monitor it in case the change needs reverted :-\
#juju-dev 2018-02-22
<veebers> babbageclunk: you should do another simple PR ;-) I want to confirm my slight tweak has kept things happy
<babbageclunk> veebers: hmm, the one I'm working on at the moment is 6k lines and it's not quiiiite ready...
<veebers> hah ^_^
<mup> Bug #1751153 opened: juju 2.3.4: vsphere units automatically remove jujud across reboot when cloud-init /var/lib/cloud is removed  <juju-core:New> <https://launchpad.net/bugs/1751153>
<mup> Bug #1751153 changed: juju 2.3.4: vsphere units automatically remove jujud across reboot when cloud-init /var/lib/cloud is removed  <juju-core:New> <https://launchpad.net/bugs/1751153>
<mup> Bug #1751153 opened: juju 2.3.4: vsphere units automatically remove jujud across reboot when cloud-init /var/lib/cloud is removed  <juju-core:New> <https://launchpad.net/bugs/1751153>
#juju-dev 2018-02-23
<anastasiamac> thumper: wallyworld: get cred models and owner access, state layer... PTAL -  https://github.com/juju/juju/pull/8418
<wallyworld> i'll look soon
<wallyworld> anastasiamac: lgtm with a couple of small things, mainly a slightly enhanced test
 * anastasiamac lloking
<thumper> wallyworld: https://github.com/juju/juju/pull/8419
<wallyworld> sure. how was interview?
<thumper> wallyworld: quick HO
<wallyworld> ok
<elmo> jam: ping
#juju-dev 2018-02-25
<jam> elmo: pong
