#juju-dev 2012-03-05
<rog> morning!
<rog> fwereade_: i wonder if we should think about logging a little deeper
<rog> fwereade_: when i played with juju, it seemed to me that it didn't do logging very well, and perhaps we can do better.
<fwereade_> rog, heh, I won't disagree, but I think I've surgically removed my credibility on all logging-related issues for a little while :p
<rog> fwereade_: :-)
<fwereade_> rog, what were you thinking of though?
<rog> fwereade_: i was wondering about a way to amalgamate many (distributed) logs into a unified view, so one can see what's happening throughout the system in a moderately timely way
<fwereade_> rog, how would that differ from `juju debug-log`?
<rog> fwereade_: well, current debug-log goes through zk, right? which isn't great.
<rog> fwereade_: and debug-log only includes juju log messages
<rog> fwereade_: but it would be good to be able to see other logs too (preferably in a unified view), e.g. stuff in /var/log
<fwereade_> rog, hmm, interesting -- I think we kinda expect to hand that level of detail off to a subordinate charm if it's wanted
<fwereade_> rog, I agree that zk is not really the ideal log server :p
<fwereade_> rog, I do think that it would actually be pretty cool if we *did* basically have rsyslog integrated somehow
<rog> fwereade_: i'm not sure that i want to go to the trouble of deploying a subordinate charm in order to see log messages without ssh'ing to a node. but maybe it's ok.
<rog> fwereade_: part of the problem is that you don't want to shove log messages into the system unless you want them - there's a lot of potential wasted bandwidth if you do
<fwereade_> rog, this use case immediately makes me think that it might make sense to have "env-level" subordinate charms, but I haven't really kept up on that so maybe someone already thought of it
<rog> fwereade_: maybe could think of the whole env as one "service"...
<fwereade_> rog, (that is, that it might be nice to be able to auto-add a particular subordinate (say, a logging one) to *all* services)
<rog> yeah
<fwereade_> rog, yeah, something like that
<rog> except that means that services can overlap so maybe not great
<fwereade_> rog, yeah, we'd have to be careful
<fwereade_> rog, and I guess it's a bit speculative at this stage
<fwereade_> rog, worth keeping in mind though
<rog> fwereade_: yeah. i think it's really really important to have good logging support in a distributed system.
<fwereade_> rog, no argument here :0
<niemeyer> Greetings!
<rog> niemeyer: hiya
<niemeyer> Oops.. will need to give some attention downstairs.. biab
<niemeyer> Woohay
<TheMue> niemeyer: ??? What happened?
<niemeyer> TheMue: https://plus.google.com/u/0/107994348420168435683/posts/PZmwXqzbyGi
<TheMue> niemeyer: ah, great. our older daughter has an e-piano. she's learning it autodidactic.
<niemeyer> TheMue: Very nice!
<niemeyer> TheMue: I'm half and half.. I have some great friends which are amazing piano players/teachers.. that's what motivated me to get into it
<niemeyer> TheMue: So I've been having some classes in addition to studying by myself
<TheMue> niemeyer: sounds good. i wanted to learn it too. but i never started with it. insted i'm drifted into writing (and a bit into drawing again).
<niemeyer> TheMue: I've started to learn music itself, rather than the instrument, but I slowly got to appreciate the instrument itself
<TheMue> niemeyer: fantastic
<niemeyer> fwereade_: ping
<fwereade_> niemeyer, pong, how are you?
<niemeyer> fwereade_: Heya
<niemeyer> fwereade_: Excellent.. great Monday so far :)
<niemeyer> fwereade_: How about yourself?
<fwereade_> niemeyer, pretty good thanks
<fwereade_> niemeyer, so, what can I do for you?
<niemeyer> fwereade_: Just wanted to see if there's anything you'd like to catch up on regarding the pipeline/branch/conversation/whatever
<fwereade_> niemeyer, ah, yeah, let me think a mo
<fwereade_> niemeyer, just an am-i-on-crack check really
<niemeyer> fwereade_: I don't think you are, but go on
<fwereade_> niemeyer, the motivation is that the python hook commands are kinda nasty, because there are far too many layers of plumbing
<fwereade_> niemeyer, and that we'll get a much simpler situation if we make the client as thin as possible
<niemeyer> fwereade_: Motivation for ... (just to make sure I get what you're really saying)
<niemeyer> fwereade_: Ah, no need, I see already
<fwereade_> niemeyer, basically, implementing a single jujup command which we specialise purely by symlink
<niemeyer> fwereade_: That sounds fine for sure
<niemeyer> fwereade_: I'd just prefer to name it as something else of your choice
<fwereade_> niemeyer, not jujup?
<niemeyer> fwereade_: jujud and jujup are graphically extremely close
<fwereade_> niemeyer, well, I wouldn't expect anyone to ever call jujup directly, but good point nonetheless
<niemeyer> fwereade_: And also in the way we pronounce it
<niemeyer> fwereade_: Naming it something else could avoid it
<fwereade_> niemeyer, yeah, another good point
<niemeyer> fwereade_: jujut (tools?)
<niemeyer> fwereade_: ?
<fwereade_> niemeyer, jujut sounds good to me
<fwereade_> niemeyer, although, hah, pronunciation vs jujud
<niemeyer> Hmm.. even though I guess my pronounciation argument falls short
<niemeyer> Yeah :)
<rog> i wouldn't mind a longer name
<niemeyer> fwereade_: jujuh?
<rog> noone's ever going to type it...
<niemeyer> hooks
<niemeyer> rog: That goes both ways..
<fwereade_> niemeyer, pronunciation again :p
<niemeyer> fwereade_: jujuc?
<rog> jujud is good because there's an existing convention
<niemeyer> fwereade_: (from client)
<fwereade_> niemeyer, I was thinking that and liking it just-about-enough
<fwereade_> niemeyer, yeah, same reasoning
<rog> jujucallback :-)
<niemeyer> fwereade_: Cool, +1..
<fwereade_> rog, we're just extending the noble and hallowed 1-char extension
<fwereade_> ...tradition
<rog> hmm
<niemeyer> rog: 1 char is fine, IMO, precisely because no one has to remember the command name.. we can deal with a short name for ourselves
<rog> fwereade_: for me, jujud means juju daemon. jujuc means... nothing.
<niemeyer> rog: client.. that's what it means
<rog> jujuice
<TheMue> juice *scnr*
<niemeyer> rog: Oh man.. shhhh
<niemeyer> rog: Let's reserve that one for something nice :)
<TheMue> rog: h5
<rog> yeah, jujuc's ok.
<fwereade_> motion carried :)
 * TheMue likes jujuc too
<rog> only thing is, it's not really the juju client. it's part of the juju infrastructure. the client is really the one doing juju deploy etc.
<TheMue> niemeyer: I'm now doing the Agent stuff. So I need an idea on how you wonne have watches implemented.
<fwereade_> rog, but nobody will ever know c is short for client unless we tell them, and it can be out little secret :p
<rog> jujuhook might be a little better, but it's not the hook itself, it's something inside the hook
<rog> TheMue: i'll paste you what we wrote down in the lobby that time
<TheMue> rog: great, thx
<niemeyer> rog: Cheers
<rog> http://paste.ubuntu.com/869964/
<rog> it's just the client code, but i think that was the important bit
<rog> i'm wondering why Stop isn't just a close of the event channel, but there's probably a good reason
<rog> ah yes
<TheMue> rog: yep, most stuff is clear. Changed delivers just a bool?
<rog> TheMue: changed delivers anything you like
<rog> TheMue: the idea is it can deliver deltas
<rog> TheMue: unlike the usual zk channels
<rog> TheMue: each watcher might have a different event type
<TheMue> rog: ok, so the watch isn't one type, they are individual types depending on what the watch
<TheMue> rog: yep
<rog> TheMue: yeah, i think so
<TheMue> rog: so i need to start a goroutine reading the zk-watcher events, transform then, and once it closes i'll send the Stop and end the goroutine
<TheMue> rog: pretty simple
<rog> TheMue: i don't think Close should send on Stop.
<rog> TheMue: i *think* that Stop will be global to the state.
<rog> TheMue: so when the state itself is closed, it closes the Stop channel, which then propagates through to all watchers
<TheMue> rog: ok, so far the state doesn't knows a Stop(). and I've got to think about dependencies.
<rog> TheMue: so far State doesn't have Close AFAIK
<TheMue> rog: yep, that's what I meant
<rog> ah yes
<niemeyer> TheMue: Note that the watch method will generally be on *State or some more specific type
<TheMue> niemeyer: yep
<niemeyer> rog: Why do we need two channels again?
<rog> niemeyer: i'm just trying to remember why
<niemeyer> rog: We need a way to notify the goroutine itself that it's being stopped
<rog> niemeyer: it depends how we want to propagate the state close
<TheMue> so, have to leave until this evening, have to drive my older daughter to a workshop. thankfully she's making her driver license soon.
<niemeyer> rog: But I can't see why we'd make that public
<TheMue> niemeyer, rog : please keep on discussing, will read it later
<rog> TheMue: ok, see you tomorrow
<niemeyer> TheMue: LOL
<niemeyer> TheMue, rog, fwereade_: http://paste.ubuntu.com/870023/
<niemeyer> Erm.. type is misnamed
<niemeyer> Fixed: http://paste.ubuntu.com/870026/
<fwereade_> niemeyer, looks good to me
<rog> niemeyer: does FooWatcher.Change get closed?
<niemeyer> rog: Ah, it should.. at the bottom of break.. fixing it
<niemeyer> s/break/for
<niemeyer> TheMue: With rog's point: http://paste.ubuntu.com/870029/
<rog> niemeyer: ah, that break should break two levels too
<niemeyer> rog: Hmm.. could have to indeed
<rog> niemeyer: might as well defer(close(w.Change)) and return
<niemeyer> rog: I'll fix in a better way
<niemeyer> rog: http://paste.ubuntu.com/870030/
<niemeyer> Hard to get it wrong like that
<niemeyer> Argh.. Unity is driving me nuts with the latest ALT-<anything> sequence bringing up the hud at all times
<rog> niemeyer: i'd like to see it filled out. for instance, what if  the zk watch case is sending on FooWatcher.Change when FooWatcher is stopped?
<niemeyer> rog: What's the problem with that?
<niemeyer> rog: In fact, how can it possibly happen? Nothing sends on Change if FooWatcher is stopped
<rog> niemeyer: there's a potential deadlock if the thing reading on FooWatcher.Change is the one calling Stop
<niemeyer> rog: Sorry, still don't get it.. a) Only one of these may be done at a time.. b) Change is closed on Stop
<rog> niemeyer: ok, here's the scenario:
<rog> niemeyer: watcher is started. it quickly generates a few events and blocks trying to send on FooWatcher.Change
<rog> niemeyer: the thing that started the watcher decides it doesn't need it any more and calls Stop on it
<rog> niemeyer: the watcher will block forever
<niemeyer> rog: Definitely not
<niemeyer> 		case <-w.tomb.Dying:
<niemeyer> 			return
<niemeyer> 		case <zk watch>:
<niemeyer> 			...
<niemeyer> 		}
<rog> niemeyer: because the thing that started the watcher never received the events it's blocking on
<rog> niemeyer: what's inside the <zk watch> case?
<rog> niemeyer: you'll have to guard the send to FooWatcher.Change too, i think
<niemeyer> rog: <-w.tomb.Dying is all that's necessry
<niemeyer> necessary
<niemeyer> rog: If there are other selects, the same must be done of course
<niemeyer> rog: Check out the blog post for a detailed explanation: http://blog.labix.org/2011/10/09/death-of-goroutines-under-control
<rog> niemeyer: it's not just in the case of selects, it's any channel operation.
<niemeyer> rog: Which are done inside selects? :-)
<rog> niemeyer: but that's why i wanted you to fill out the example
<rog> niemeyer: not necessarily...
<rog> niemeyer: but in this case, they'll have to be.
<niemeyer> rog: LOL
<niemeyer> rog: Yeah.. they have to be if we don't want to consciously introduce bugs
<rog> niemeyer: one thing this example doesn't address is what we do when State itself is closed
<niemeyer> rog: Indeed.. it must Stop too
<niemeyer> rog: Actually, not really
<niemeyer> rog: That was the idea I had, but you correctly pointed out that this is a job for the loop
<niemeyer> If the state is closed, zk is closed, and the loop will error out..
<niemeyer> If we use tomb.Fatal, as per the post, it will eventually reach the guy calling Stop() too
<niemeyer> Hmm.. I'll have to break out to pick up Ale for lunch..
<niemeyer> rog: biab, in case you want to continue on that, but I think we have a reasonable plan
<rog> niemeyer: any chance you might be able to review some of my merge requests this week BTW?
<niemeyer> rog: Yep, good chances ;)
<rog> niemeyer: that would be nice
<rog> niemeyer: (i've been trying not to badger you :-])
<niemeyer> rog: That's appreciated, as I've been reviewing tons of branches pretty much every day
<niemeyer> I'll give some priority to the store early this week still, though
<niemeyer> biab
<rog> ok
<rog> niemeyer: are you back yet?
<robbiew> niemeyer: around for juju call?
<niemeyer> robbiew: Here
<niemeyer> robbiew: Is it happening?
<robbiew> niemeyer: yes
<robbiew> on with sabdfl now :)
<robbiew> just us
<niemeyer> robbiew: Sorry, will be on in a sec
<niemeyer> rog: I am, kind of :)
<robbiew> hazmat: of course you're welcome too ;)
<rog> niemeyer: ok, when you have a moment, wouldn't mind a chat about tomb
<niemeyer> rog: Sounds good
<hazmat> sigh
<hazmat> think i missed it
<hazmat> lunch'd out
<rog> i'm off for the evening. see you tomorrow.
<niemeyer> rog: I'm off the call, but I guess you're gone
<niemeyer> Alright.. skeleton in place, HTTP server works.. need to implement the actual actions.. maybe today still!
<niemeyer> But now it's time for some outsiding
<niemeyer> Laters
<rog> niemeyer: yes, sorry. tomorrow...
#juju-dev 2012-03-06
<andrewsmedina> anyone can help me with lbox?
<hazmat> andrewsmedina, what do you need?
<andrewsmedina> hazmat: I need create a new proposal
<hazmat> andrewsmedina, lbox propose -cr from within a branch should do it
<hazmat> andrewsmedina, that will create a proposal (if one doesn't exist) or update an existing one
<andrewsmedina> hazmat: but "lbox propose -cr" are updated a closed issue =/
<hazmat> andrewsmedina, i don't parse that
<hazmat> what closed issue?
<andrewsmedina> hazmat: how lbox knows if a proposal exist
<hazmat> andrewsmedina, it looks at the branch in lp and look for an attached merge proposal
<hazmat> with an expected syntax
<hazmat> andrewsmedina, if you need to create an entirely new proposal, you should delete the existing merge proposal attached to the branch
<hazmat> but you'll lose existing comments
<andrewsmedina> hazmat: I updated the goetveld to works with the last weekly version
<hazmat> typically you just propose it again, and lbox will update the existing proposal to let reviewers know theirs something new
<hazmat> andrewsmedina, yeah.. i don't play the go monkey dance version game
<andrewsmedina> hazmat but lbox are appending it with another proposal
<andrewsmedina> hazmat: what?
<hazmat> andrewsmedina, ;-) just a general comment on 3rd party go libs.. pls ignore
<hazmat> andrewsmedina, what does lbox appending it to another proposal mean?
<hazmat> andrewsmedina, what are you trying to do?
<andrewsmedina> hazmat: https://codereview.appspot.com/5683064/
<hazmat> andrewsmedina, just run lbox propose -cr in the branch again
<andrewsmedina> hazmat: a week ago I sent a proposal
<hazmat> it will append to the existing merge proposal and notify reviewers that there are changes
<andrewsmedina> hazmat and today and now I sent another proposal
 * hazmat nods
<hazmat> oh.. its already there
<hazmat> 16m ago..
<andrewsmedina> hazmat: lbox unified both, but are different proposals
<hazmat> andrewsmedina, lbox uses the branch diff
<hazmat> if you want two different proposals, you'd have two different branches
<hazmat> but in this case, your responding to feedback from the original proposal
<hazmat> and you've made an update, so that's fine imo being attached to the existing proposal
<andrewsmedina> hazmat: ty
<hazmat> np
<andrewsmedina> hazmat: You dont sleep?
<hazmat> andrewsmedina, nah.. i find it distracting ;-)
<andrewsmedina> hazmat: :)
<fsouza> is hazmat 24/7?
<niemeyer> Hello everybody
<rogpeppe> niemeyer: hiya
<hazmat> niemeyer, g'morning
<rogpeppe> niemeyer: let me know when you're up for that chat
<niemeyer> rogpeppe: Sure, let's go
<rogpeppe> niemeyer: there's something about tomb.Fatal(tomb.Stop) that seems odd to me
<rogpeppe> niemeyer: it's a common path, and we already have a way of expressing "no error" - just use nil.
<rogpeppe> niemeyer: so i'm thinking tomb.Stop(nil)
<rogpeppe> niemeyer: then tomb.Err() would return ErrStillRunning if the tomb hadn't died.
<rogpeppe> niemeyer: which means the user wouldn't have to mess with particular error values at all in the usual case
<niemeyer> rogpeppe: I've designed that interface while using it.. the Fatal(nil) is odd, and may easily hide a bug
<rogpeppe> niemeyer: how's that?
<niemeyer> think Fatal(err) when err is nil
<rogpeppe> that's fine
<rogpeppe> just like return nl
<rogpeppe> nil
<rogpeppe> another thing: i'm not keen on the "Fatal" name. it's not fatal to anything - it just signals the tomb to die in the future. Stop feels better to me.
<niemeyer> rogpeppe: Sorry, we already went over that one..
<niemeyer> rogpeppe: It's fatal for the goroutine
<rogpeppe> niemeyer: only if there's only one goroutine
<niemeyer> rogpeppe: Besides, the analogy there is sane.. dying, fatal, etc
<rogpeppe> niemeyer: it's explicitly documented that it may be called multiple times
<niemeyer> rogpeppe: Yep
<rogpeppe> niemeyer: the only other instances of Fatal do not return
<niemeyer> rogpeppe: Yep
<rogpeppe> niemeyer: but this one does
<niemeyer> rogpeppe: Yep
<niemeyer> rogpeppe: The analogy there is strong enough that I'm comfortable with that
<niemeyer> rogpeppe: tomb, dying, fatal, etc
<rogpeppe> Die might be better
<rogpeppe> or even Kill
<niemeyer> rogpeppe: Yeah, kill might work
<niemeyer> rogpeppe: Yeah, I guess the ErrStillAlive might be a nice improvement
<rogpeppe> niemeyer: thanks.
<rogpeppe> niemeyer: i've got a branch that i could propose
<niemeyer> rogpeppe: I'm still a bit sad about losing the error check in Fatal/Kill/Whatever, but you're right that this is no different than returning an err by mistake
<niemeyer> rogpeppe: Sure, please do, thank you
<rogpeppe> niemeyer: one other thing
<niemeyer> and I guess I'll have to update the blog post again
<rogpeppe> (sorry 'bout that)
<niemeyer> np
<rogpeppe> niemeyer: i wonder about how much Stopf (or whatever) will be used.
<rogpeppe> niemeyer: i wonder about just providing Kill
<rogpeppe> sorry, Killf
<niemeyer> rogpeppe: No, please preserve it..
<rogpeppe> niemeyer: ok. i was going by the return analogy
<niemeyer> rogpeppe: This isn't return.. this is Fatal/Fatalf
<rogpeppe> niemeyer: you can always use fmt.Errorf (there's no need for tomb to depend on fmt)
<niemeyer> rogpeppe: You can, just like you could always do errors.New(fmt.Sprintf(...)) all the time
<niemeyer> rogpeppe: That's not what we do, though
<rogpeppe> niemeyer: i'm thinking that almost all the time you'll be doing Kill(err) anyway
<niemeyer> rogpeppe: Please..
<rogpeppe> ok
<rogpeppe> niemeyer: oh, yes one other thing :-)
<rogpeppe> niemeyer: it would be nice if we could embed tomb.Tomb in the same way we can embed sync.Mutex
<rogpeppe> niemeyer: i.e. if the zero'd form was good to go
<niemeyer> rogpeppe: Yeah, it would be nice indeed
<rogpeppe> niemeyer: it's doable, but it means Dying and Dead have to be functions rather than fields.
<niemeyer> rogpeppe: Yeah, not an option
<rogpeppe> niemeyer: no? it works ok like that (and saves space too)
<niemeyer> rogpeppe: It'll incur in a function call for absolutely no reason every single loop
<rogpeppe> niemeyer: no it wouldn't.
<rogpeppe> niemeyer: they'd be inlined
<niemeyer> rogpeppe: Not really
<rogpeppe> niemeyer: sure they would. it's a single statement function. it's inlined by default.
<niemeyer> rogpeppe: If it's a single statement you're not doing anything within the function
<rogpeppe> niemeyer: ah, good point. yeah, it needs a mutex too.
<niemeyer> rogpeppe: and make(), and if, and ...
<rogpeppe> niemeyer: yeah
<rogpeppe> (i added Tomb.init function when i tried it)
<rogpeppe> i still think it might be worth it though.
<niemeyer> rogpeppe: Maybe.. New bothers me in that case too
<rogpeppe> New?
<niemeyer> rogpeppe: tomb.New
<rogpeppe> niemeyer: why? i just deleted that function.
<niemeyer> rogpeppe: Which means it bothered you as well, right? :-)
<rogpeppe> niemeyer: ah, i see
<rogpeppe> niemeyer: i thought there was maybe something more subtle
<niemeyer> rogpeppe: Hmm.. I guess we can always have a variable when speed actually matters
<niemeyer> rogpeppe: +1 on trying that
<rogpeppe> niemeyer: ok, cool.
<rogpeppe> niemeyer: actually...
<rogpeppe> oh yeah,
<rogpeppe> you mean the client code can have a variable
<rogpeppe> +1
<TheMue> niemeyer: when i created a watch with ExistsW() on a not yet existing path and the path later will be created i should expect an EVENT_CREATED, shouldn't i?
<niemeyer> rogpeppe: Thanks for these suggestions... feel like good improvement
<rogpeppe> niemeyer: thanks for going with me on this. if we're going to be using this a lot, i think it's good that we try to get it right.
<rogpeppe> niemeyer: cool, as above
<niemeyer> rogpeppe: Indeed
<niemeyer> TheMue: Yep, sounds snae
<niemeyer> sane
<TheMue> niemeyer: hmm, i'm trying here my agent watch test, e'thing fine until the point where i'm waiting for the event. funnily i get none.
<TheMue> niemeyer: btw, i've got two proposals open. when can i expect your review?
<niemeyer> TheMue: This week still
<niemeyer> rogpeppe: When you have a moment, would you mind to have a look at the review that is pending?
<niemeyer> rogpeppe: I want to close the store work today still
<rogpeppe> niemeyer: will do
<niemeyer> rogpeppe: It's a pretty small one
<TheMue> niemeyer: ok, will continue work on the agent.
<niemeyer> TheMue: Thanks.. I'll just finish that store work before moving back onto reviews, or we'll never have that
<TheMue> niemeyer: yep, the store is important
<niemeyer> rogpeppe: Cheers
<rogpeppe> TheMue, niemeyer: here's a little working example of how watchers might work: http://paste.ubuntu.com/871544/
<rogpeppe> (using the changed tomb API, BTW)
<niemeyer> Sorry.. connection dropped
<niemeyer> <rogpeppe> (using the changed tomb API, BTW)
<niemeyer> <niemeyer> rogpeppe: FooWatcher.Err should be using tomb.Err
<niemeyer> <niemeyer> rogpeppe: Looks good, otherwise
<rogpeppe> niemeyer: what's wrong with using tomb.Wait?
<niemeyer> rogpeppe: It waits.. :-)
<rogpeppe> hmm, yeah, probably don't want Err to wait, you're right.
<rogpeppe> niemeyer: the order of the defers in FooWatcher.run is crucial then...
<niemeyer> rogpeppe: Why?
<niemeyer> rogpeppe: I think it is reversed indeed, FWIW, but why do you think it is crucial?
<rogpeppe> niemeyer: otherwise a watcher might see that Change is closed and call err, but before tomb.Done is called, so it'll see the tomb still running.
<rogpeppe> s/call err/call Err/
<niemeyer> rogpeppe: Good point..
<niemeyer> rogpeppe: It is good practice to always have defer tomb.Done() as the first thing in the goroutine, since it's supposed to flag "nothing else will happen"
<rogpeppe> niemeyer: this is perhaps why it might be reasonable to make Err block...
<niemeyer> rogpeppe: Sorry, I think I lost the reasoning why what we just said above is invalid
<rogpeppe> niemeyer: i can't see Err being useful to get an error during the watcher run
<niemeyer> rogpeppe: So remove Err..
<niemeyer> rogpeppe: Err must not block.
<rogpeppe> niemeyer: why's that?
<niemeyer> rogpeppe: Because it's a question about what was the error, rather than a question "please block for as long as necessary"
<niemeyer> rogpeppe: That's the convention
<rogpeppe> niemeyer: but perhaps we don't know if there was or wasn't an error yet
<niemeyer> rogpeppe: And ... ?
<rogpeppe> niemeyer: using Err before Done has been called is inherently racy, i think
<rogpeppe> niemeyer: i'm not sure we want to support that
<niemeyer> rogpeppe: Indeed. Please remove Err.
<rogpeppe> niemeyer: ok. from tomb as well?
<niemeyer> rogpeppe: Nope.. tomb is fine as ti is
<rogpeppe> niemeyer: tomb has the same issue
<niemeyer> rogpeppe: Nope.. it's a fine question, with a fine error in case it is running. There's no race.
<rogpeppe> niemeyer: ah, i'd preserved some of the old semantic - if there'd been a non-nil error, it returned it. but i think ErrStillRunning is better.
<niemeyer> rogpeppe: That's what I understood you were going to propose in the branch
<niemeyer> rogpeppe: Otherwise Kill(nil) is a no-go
<rogpeppe> niemeyer: yeah, my thinking was fuzzy
<rogpeppe> niemeyer: but there's still an issue (maybe a non-issue actually)
<rogpeppe> niemeyer: that if the Err method is removed from FooWatcher, there's no way for the watcher to fail with an error that isn't discarded.
<rogpeppe> niemeyer: so maybe just returning ErrStillRunning is fine there too.
<niemeyer> rogpeppe: Sure, but I suggest waiting until we have the use case
<rogpeppe> niemeyer: yeah, maybe a simple closed channel is enough. any errors could be logged.
<niemeyer> rogpeppe: The error comes out of the Stop too
<rogpeppe> niemeyer: that only works if you Stop it, of course, which you won't if you see EOF on the Change channel.
<niemeyer> rogpeppe: Why not?
<niemeyer> rogpeppe: Stop should always be called for all of them
<rogpeppe> niemeyer: why would you? you know it's already stopped.
<rogpeppe> niemeyer: ah.
<niemeyer> rogpeppe: Because the logic is cleaner that way
<niemeyer> rogpeppe: Which channel was closed? Etc
<rogpeppe> hmm, not sure about that as reasoning. you'll always know which channel is closed, no?
<niemeyer> rogpeppe: Either way, a bit premature for that discussion.. let's have the branch implementing a watch for review first
<rogpeppe> ok
<rogpeppe> niemeyer: https://codereview.appspot.com/5755055
<rogpeppe> niemeyer: just on your review now, BTW
<niemeyer> rogpeppe: Cool, I'm proposing the second one with a trivial runner for the Server just now
<niemeyer> After that, just need to implement /charm support, and I guess it's done
<fwereade__> niemeyer, sudden thought: JUJU_CLIENT_ID might be better named JUJU_CONTEXT_ID; opinion?
<fwereade__> niemeyer, given that it's at least in theory the key used to look up a particular context in which to execute hook commands
<niemeyer> fwereade__: How's it set?
<niemeyer> fwereade__: Sorry, what's its value
<fwereade__> niemeyer, heh, well, in python it's always set to "client"
<niemeyer> fwereade__: I think this is supposed to differentiate which process is running
<fwereade__> niemeyer, sorry, expand please
<niemeyer> fwereade__: How to find the relevant jujud process, more specifically
<niemeyer> fwereade__: Or, I don't see how it is relevant at all..
<fwereade__> niemeyer, hmm, not sure, JUJU_AGENT_SOCKET should handle that
<niemeyer> fwereade__: Hmm.. indeed
<niemeyer> fwereade__: Why is that used at all?  I suggest we don't add that variable until we can figure the answer that tricky question! ;-)
<fwereade__> niemeyer, I think it's useful so that the hosted commands can be executed directly with the aid of a looked-up hook context that holds relevant data
<fwereade__> niemeyer, this may be excessive given that ATM there's only one possible active hook context
<niemeyer> fwereade__: Sorry, I don't get it.. how is that variable useful at all if it's always set to "client"?
<fwereade__> niemeyer, it's not currently useful, because the python HookExecutor knows that it only ever has one active context
<fwereade__> niemeyer, but that doesn't IMO actually improve simplicity or sanity
<niemeyer> rogpeppe: You got a review
<fwereade__> niemeyer, apart from anything else it means that anyone can execute a hook command at any time a context is active
<niemeyer> fwereade__: How's that a problem?
<fwereade__> niemeyer, I dunno, it just seems like a possible way for things to get screwed up
<rogpeppe> niemeyer: thanks
<niemeyer> fwereade__: FWIW, I think JUJU_CONTEXT_ID, and using it as you describe is fine.. I'm just suggesting we don't introduce the variable before it is actually being use
<niemeyer> d
<niemeyer> fwereade__: IOW, if you
<niemeyer> 're just going to reproduce the Python logic and have client as a constant, drop it
<niemeyer> fwereade__: If you have plans to improve it and have it as an _actual_ context specifier, than sure, let's see how it loosk
<niemeyer> looks
<niemeyer> I can't type
<fwereade__> niemeyer, I have every intention of using it as a context specifier ;)
<fwereade__> niemeyer, cheers
<niemeyer> Lunch time here!
 * niemeyer is hungry today..
<rogpeppe> niemeyer: enjoy. you've got a review too.
<jcastro> oh hey hazmat
<jcastro> meetingology: is here
<meetingology> jcastro: Error: "is" is not a valid command.
<jcastro> hazmat: do you know how to use it?
<hazmat> jcastro, huhu?
<hazmat> meetingology help
<meetingology> hazmat: (help [<plugin>] [<command>]) -- This command gives a useful description of what <command> does. <plugin> is only necessary if the command is in more than one plugin.
<jcastro> hazmat: for logging meetings and stuff if you want
<hazmat> meetingology help plugins
<meetingology> hazmat: Error: There is no command "plugins".
<jcastro> https://wiki.ubuntu.com/meetingology
<hazmat> jcastro, its been a while since i've used it but sounds good, we do most of our meetings off irc these days
<hazmat> in g+
<jcastro> right, I was doing the irc bot stuff and just put him in here just in case.
<hazmat> jcastro, sounds good
<hazmat> thanks
<jcastro> anyway you've got your logging back and stuff
<jcastro> so you should be all set.
<niemeyer> rogpeppe: Re-reviewed
<niemeyer> rogpeppe: Just a few trivials and I'll submit
<rogpeppe> niemeyer: you caught my global search and replace!
<rogpeppe> niemeyer: all done.
<rogpeppe> niemeyer: not so sure about "csapi" as a command name. possible alternatives: i wonder if "charmserve" or "charmsrv" or even "charmd"
<rogpeppe> oops
<rogpeppe> niemeyer: not so sure about "csapi" as a command name. possible alternatives: charmserve, charmsrv, charmd, charmstored
<niemeyer> rogpeppe: cs is from the charmstore
<niemeyer> rogpeppe: But it's a bit more specific in that this will work with what we call as "cs:" only
<rogpeppe> niemeyer: i know. but cs can stand for all kinds of things.
<niemeyer> rogpeppe: Not for us
<niemeyer> rogpeppe: Note that this is relevant only for IS for now
<rogpeppe> i guess i tend to prefer names that aren't entirely acronyms
<niemeyer> rogpeppe: charmd sounds good
<niemeyer> rogpeppe: charmload and charmd.. ok
<rogpeppe> sounds good to me
<niemeyer> rogpeppe: I'll change that
<rogpeppe> niemeyer: cool, thanks
<rogpeppe> niemeyer: other LGTM
<rogpeppe> otherwise
<niemeyer> rogpeppe: Haven't pushed the changes yet, but responded to your review on https://codereview.appspot.com/5755047/
<niemeyer> rogpeppe: Please see if it makes sense to you or if you need anything else
<rogpeppe> niemeyer: if you're using ServeMux, then you'll want to check the URL anyway. i still think that http://charmserver.com/charm-info/fooey should give a 404
<niemeyer> rogpeppe: Yes, I agree with that
<niemeyer> rogpeppe: Will fix it
<niemeyer> rogpeppe: But will keep the mux, as I don't want to do the basic multiplexing by hand
<rogpeppe> niemeyer: that's fine.
<niemeyer> rogpeppe: Really like how the tomb changes turned out, cheers
<rog> what is it with my network currently?
<rog> i think it might be to do with my network driver rather than the ISP connection.
<rog> (this morning i was seeing many missed packets and >500ms ping times to my local router, where another adjacent computer was getting consistently getting <5ms
<rog> )
<rog> niemeyer: did you manage to sort out your network problems?
<rog> fwereade_: i think it's not worth proposing more than one branch at once, unless the changes are independent. it's confusing trying to work out if the changes shown in codereview are to do with the proposed branch or not.
<rog> off for the night. see yous tomorrow.
<niemeyer> rog: Nope..
<niemeyer> rog: I've been using a cable meanwhile
<rog> niemeyer: i'm moving to cable, as soon as i get the tool that enables me to wire an RJ45 jack, on order now.
<niemeyer> rog: Are you finding issues too?
<niemeyer> rog: Or is it just package losing?
<niemeyer> s/package/packet/
#juju-dev 2012-03-07
<rog> fwereade: mornin'
<fwereade> rog, heyhey
<fwereade> rog, about the pipeline requests, feel free to ignore anything with a prereq
<rog> fwereade: ok.
<fwereade> rog, or I guess I could try to remember to always -prep -req
<rog> fwereade: yeah, that's what i try to do
<rog> fwereade: (but you have to remember to manually move the branch state out of "work in progress" when you finally do propose)
<TheMue> rog, fwereade: morning
<fwereade> rog, oh! really? "-unprep" is not implicit?
<fwereade> heya TheMue
<rog> fwereade: no. it's a bug, and i've reported it...
<rog> TheMue: hiya
<fwereade> rog, ok, cool, I'll try to remember :)
<rog> fwereade: i've been thinking about your command context stuff
<rog> fwereade: i'm not sure about it
<fwereade> rog, hm, ok, go on
<rog> fwereade: the motivation is so that the hook commands can run the commands inside the agent, right?
<fwereade> rog, maybe, sort of
<fwereade> rog, let's say yes for now
<rog> fwereade: if it's not, then my concern is orthogonal
<rog> fwereade: anyway
<rog> fwereade: i think we should provide a "hook" API so that Go programs can use relation-get etc without invoking the command line commands
<rog> fwereade: then jujuc can layer onto that
<rog> fwereade: 5 second sketch: http://paste.ubuntu.com/872668/
<fwereade> rog, I think I need a bit more context for why you think that's necessary or desirable
<fwereade> rog, IMO invoking a command-line command is not a big deal
<rog> fwereade: it would be useful (IMO) to be able to write hooks in Go
<fwereade> rog, it would be cool but it's pretty niche really
<rog> fwereade: i think it makes sense from a modularity perspective, just like the juju command
<rog> fwereade: (it's certainly niche now, but not necessarily in the future)
<rog> sorry, just like the juju package
<rog> we can think of the Hook type as the primary API. the command line is just an interface to it.
<fwereade> rog, what will be the increased costs of implementing it at the time it turns out to be needed?
<rog> fwereade: what are the increased costs of implementing it now?
<rog> fwereade: i think it makes things simpler if anything
<fwereade> rog, I haven't implemented a single hook command yet
<fwereade> rog, we know they need to be invoked via the command line
<fwereade> rog, we have this idea that it might be nice to write hooks in Go
<fwereade> rog, but os/exec doesn't feel like such a lame horse that we should devote dev effort to privileging go hooks over other languages by giving them their own API
<rog> fwereade: it would enable other languages to write their own API if they want.
<rog> fwereade: Go is privileged here because it's the implementation language.
<fwereade> rog, IMO the *lack* of privilege is an important feature
<rog> fwereade: if we provide exactly the same capabilities, there's no real privilege, just convenience (and type safety)
<rog> fwereade: IMO it's a better separation of concerns
<rog> fwereade: and you don't need the command context :-)
<fwereade> rog, but it's additional convenience for a language that is unlikely to be a normal user's first choice for hook implementation, and doing so carries a subtle implication that you "should" write hooks in go
<rog> fwereade: i really don't think so. it's just that we can easily provide a nice API and layer onto that with the command line stuff
<fwereade> rog, the context is a replacement for far too many layers of plumbing in python
<rog> fwereade: i think it's only needed because the innards of the code is printing to stdout and stderr.
<rog> fwereade: if there's an API, there's no need for that.
<fwereade> rog, it's not necessarily even the innards
<fwereade> rog, really it shouldn't/won't be the innards
<fwereade> rog, ok, I think there's something I'm missing: the intent of the Context is entirely to simplify what strikes me as an unnecessarily convoluted architecture in python
<fwereade> rog, if "native" hook command execution were a priority, we would have exposed it in python
<rog> fwereade: i'm not sure we need it though, if we're not doing remote execution of arbitrary commands.
<rog> fwereade: it's not a priority, but i think it would work well as a way of structuring the system.
<rog> sending command line commands across the pipe seems like it's making things more abstract than they need to be
<fwereade> rog, can we take a step back because I'm not sure of the extent of your proposal
<rog> fwereade: ok.
<fwereade> rog, are you suggesting that we should basically have an RPC server implementing N methods, and N executables each calling one of those methods?
<rog> not quite
<hazmat> g'morning
<rog> fwereade: i'm proposing that we have an RPC server implementing N methods, yes, but that the jujuc command calls one of those methods depending on the command line args
<fwereade> hazmat, heyhey
<rog> hazmat: yo!
<hazmat> greetings
<rog> hazmat: i guess it's not morning for you...
<hazmat> fwereade, did you have a a chance to look at the review on service constraints?
<hazmat> rog, the birds are chirping ;-)
<fwereade> hazmat, yeah, I rote you an essay
<rog> hazmat: tell 'em to shut up and go back to sleep :-)
<fwereade> hazmat, it may be filled with crack but I'd be interested to hear your views
<hazmat> fwereade, sounds good.. waiting for the intertubes to catch up..
<rog> fwereade: the point is that all the awkward command-line stuff is inside jujuc, and the unit agent only deals with nice fluffy typed abstractions.
<fwereade> rog, IMO that is itself a significant increase in complexity -- N request types, N response types, N methods -- just to avoid one layer of abstraction that doesn't affect any other code
<fwereade> rog, what makes you think the unit agent won't have nice fluffy typed abstractions to work with?
<fwereade> rog, the command line needs to be dealt with *somewhere*
<rog> fwereade: sure. i'd just prefer to deal with it as close to the metal as possible.
<hazmat> fwereade, ah.. re (4) it was about the storage (dict) but about the choice of names (layer_data) which implied it was a layer in some lookup that's not germane to the entity, to the given entity that data are its serializable constraints.
<fwereade> hazmat, sorry, having trouble parsing that
<hazmat> er.. it wasn't about the storage, just the naming
<fwereade> hazmat, ha, ok; sorry I completely missed that
<hazmat> fwereade, no worries, thanks for keeping up with it
<fwereade> rog, ok, but a cmd.Context is all-the-complexity-we-need, right here, right now, and done; and it lets us add accessible commands to a hook context in one place only (the hook context itself)
<fwereade> rog, your proposal implies we need to change jujuc, and the server, every time we implement a new hook command
<rog> fwereade: one other consideration is that doing it this way constrains our future implementation options. all hook commands must run as RPCs to the unit agent, which isn't necessarily always going to be the case.
<rog> fwereade: yeah, that's true. jujuc would need to know what commands it's implementing
<fwereade> rog, if we do end up with hook commands that don't depend on their execution context, we can just expose those as standalone commands
<fwereade> rog, jujuc is solving the very specific problem of hook commands that need to know an unhealthy amount of stuff controlled by the unit agent
<hazmat> fwereade, if a service is deployed with no constraints, the service state will end up storing a copy of the environment constraints as the actualized constraints for the service?
<fwereade> hazmat, hmm, tbh I forget exactly when things are collapsed
<rog> fwereade: agreed
<fwereade> hazmat, but I'm pretty sure my intent was to defer collapse until we have an actual unit that needs them
<rog> fwereade: but that stuff might vary according to the command.
<fwereade> rog, indeed it could; but I don;t see where you're going with this
<rog> fwereade: i just have a strong feeling that a hook API would be a Good Thing. perhaps i'm on crack.
<rog> apart from anything, it would provide a nice documentation of the hook capabilities.
<fwereade> rog, I'm not saying it would automatically be a *bad* thing, but I think that it's (1) premature and (2) perfectly easy to add at a later stage assuming I implement the commands themselves with some sanity
<rog> fwereade: FWIW i think the code would be almost as simple with an API. there's no need to define N request types and N response types - existing types will do the job.
<fwereade> rog, that is to say that the true meat of the code will still be "call some hook context method"
<fwereade> rog, the Commands we expose will be responsible purely for parg parsing, and transforming the result for stdout
<rog> fwereade: yeah. the question is: does that code happen inside jujuc or inside the unit agent
<rog> ?
<rog> the difference is: (commandline -> RPC -> demux -> call) vs (commandline -> demux -> RPC -> call)
<rog> i'm contending that the latter is nicer, and gives us a Go hook API for free.
<fwereade> rog, I'm contending that the former is, because it allows us to keep all the knowledge about what commands we want to expose in one place
<fwereade> rog, and that a go hook API will still be cheap if and when we need it
<rog> fwereade: we've still got to make the symlinks from jujuc to the various commands, so that information's not *quite* in one place :-)
<fwereade> rog, but that's utterly trivial
<fwereade> rog, and we can do that for each execution context
<fwereade> rog, it's a simple transformation of a list of Commands; the very same list of Commands that we use in the server
<rog> hmm. would we prefer "command not found" or "command not appropriate for hook context"?
<fwereade> rog, IMO command not found, if for no other reason that it implies less wanton shitting in my command space
<fwereade> rog, as a user, I don;t really appreciate having relation-get on my path ;)
<fwereade> rog, alternate conception: relation-get is not a right, it's a privilege ;)
<rog> fwereade: the question is not whether you've got relation-get in your path, but whether relation-get is in the path for hook executions where it's not allowed
<fwereade> rog, it feels to me like fundamentally the same question; what's the point of exposing commands whose only purpose is to error out?
<rog> fwereade: i *think* i prefer it to be in the path - that way there's the possibility of getting it to log a debug message saying "inappropriate hook call" when a charm gets it wrong
<rog> fwereade: as above - because the error can be more informative that way.
<rog> fwereade: also we wouldn't have to muck around having a directory with a different set of symlinks for each possible context.
<fwereade> rog, "command not found" seems pretty informative to me
<fwereade> rog, intent is that the symlinks dir lives only as long as the hook does
<rog> fwereade: so we create the symlinks dir on every hook execution?
<fwereade> rog, the dir is trivial to create -- list of commands
<rog> fwereade: seems a bit unnecessary, but i suppose all this is very slow anyway
<fwereade> rog, it seems fine to me to spend a couple of ms per hook execution creating a directory that gives us exactly the interface exposed by the hook context -- again letting us keep all the interface info on the hook context itself, and growing seamlessly as we implement the commands one by one
<rog> fwereade: i think that updating jujuc at the same time as the juju agent would be just as simple as updating just the agent.
<fwereade> rog, isn't "if you change X, you have to change Y" rather the hallmark of inappropriate factoring?
<rog> fwereade: you'd have to change two files anyway. whether those two files end up in two separate commands seems fairly by the by.
<fwereade> rog, ok, we have to implement a Command in some way regardless, assume that's a sunk cost
<rog> agreed
<fwereade> rog, in my case, once we have a command, it's a matter of adding a line reading `&FooCommand{Context: ctx},` to the appropriate contexts
<rog> fwereade: and, presumable, the actual call that FooCommand makes to get or set the information?
<rog> presumably
<fwereade> rog, yes, FooCommand will indeed be talking to ctx
<fwereade> rog, I think that's a sunk cost as well...?
<fwereade> rog,  the ctx needs to know what to do in either case
<rog> fwereade: the question is simply whether the FooCommand does a local or a remote call, i think.
<rog> fwereade: and, yes, if it's a remote call, there would be one additional layer of indirection, to hide the remote method invocation.
<fwereade> rog, quite so; and it's an indirection layer that we need to keep updating as the exposed commands change
<rog> fwereade: true. but i see that as a good thing. the API would mirror the capabilities of the hook.
<fwereade> rog, as it is the exposed environment already does that
<rog> fwereade: BTW, just out of interest, does this API reasonably represent the capabilities of the current hook execution environment? http://paste.ubuntu.com/872742/
<fwereade> rog, and it does it dynamically rather than forcing us to manually mirror the same information in multiple places
<rog> fwereade: the exposed environment gives the names of the commands, but not the interface to those commands
<fwereade> rog, there's juju-log as well and possibly one or two others
<fwereade> rog, 8 in total
<fwereade> rog: relation-get, relation-set, relation-list, juju-log, config-get, unit-get, open-port, close-port
<rog> fwereade: like this, then: http://paste.ubuntu.com/872750/
<fwereade> rog, yes, we'll end up with hook contexts implementing something very much like that regardless
<fwereade> rog, we can expose them in another way if it ever turns out to be necessary
<fwereade> rog, and in the meantime we don't need a layer of redundant code for dealing with remote calls with all the different types and results
<fwereade> rog, eg, what happens when we need to add a flag to something? we can: fix the Command and the HookContext method; or, fix the Command, fix the HookContext method, fix the RPC server and fix the RPC client
<fwereade> rog, not forgetting the Request type
<rog> fwereade: the Request type?
<fwereade> rog, assuming we use net/rpc, that is
<rog> fwereade: i was assuming that. but what do you mean by the request type?
<fwereade> rog, call(req, &resp)
<rog> fwereade: ah, yeah if you add options, you might need a new request type.
<fwereade> rog, if we add another flag that affects what we want to send... we need to send it
<rog> fwereade: i agree it's a little more work. but i still think it would be worth it.
<fwereade> rog, tbh I'm still not seeing the benefits
<fwereade> rog, apart from this speculative hook API that would still be easy to implement if we ever needed it
<fwereade> rog, (and I have my doubts about the hook API's utility *anyway* -- I really think that any hint of a "preferred" implementation for hooks is a pretty fundamentally bad thing)
<fwereade> rog, and I think that a golang hook API *would* be seen that way
<rog> fwereade: isn't there a python API to the hook context?
<rog> fwereade: (layered onto the command line)
<fwereade> rog, well, technically yes; but I don't think we've ever suggested that anyone use it
<rog> fwereade: i thought some people write hooks in python
<fwereade> rog, maybe they do, but I don;t think they have any business whatsoever importing code from juju itself and interacting directly with the unit agent
<rog> i  wasn't suggesting that they did
<fwereade> rog, if they were they're be Doing It Wrong IMO
<fwereade> rog, ok... I missed your point then
<fwereade> rog, people can write hooks in python or go right now
<rog> fwereade: if i was writing a hook in python, i'd probably write an API so i could do relation_get() rather than calling exec and getting its piped output.
<rog> (obviously relation_get would do exec under the covers)
<fwereade> rog, ok, and that'd be a good thing for charm-tools or whatever
<fwereade> rog, but to me the exec-under-the-covers is the important thing
<rog> fwereade: so, i see the Go hook API in the same way as that, except because we're implementing it in Go, it can be a little more efficient, and synced more directly with the core
<fwereade> rog, because it means you're *actually* using the same interface everyone else is, as you should be
<rog> fwereade: the inefficiency is important?
<fwereade> rog, why would it be a bad thing to use the python API but not the go one?
<rog> fwereade: it wouldn't. just a little slower.
<fwereade> rog, hell yes it would be a bad thing to use the python API
<fwereade> rog, eithet your charm doesn't work in the go implementation, or we're stuck reimplementing the backend of the python api in go
<rog> fwereade: that's what we're doing... relation-get will be implemented in Go
<fwereade> rog, we have a perfectly good way of calling hook commands
<fwereade> rog, what benefit do we get from introducing another?
<fwereade> rog, especially when it makes development more inconvenient
<fwereade> rog, and the only people who'll feel the benefits will be those writing charms in go
<rog> that is indeed true
<rog> fwereade: i had this idea that all the user-scriptable functionality in juju would be nicely exposed in a Go package (the juju package, in fact)
<rog> maybe it's a silly idea
<fwereade> rog, I think the distinction is between user-scriptable and charmer-scriptable
<rog> i see charmers as users
<rog> (just a different category from someone that just types "juju deploy")
<fwereade> rog, fair enough, but we're still talking about two classes of users with very distinct needs
<rog> fwereade: they both benefit from a nice API, AFAICS
<rog> fwereade: if we *do* provide a Go hook API, the code in it would look remarkably similar to the code we'd write if we did a hook API to start with... except more inefficient. perhaps that's where my reluctance comes from. maybe it's the usual premature optimisation "but... i can see how it can be more efficient!"
<fwereade> rog, well, to be generally useful to either class we need an API that can be consumed from more languages than just go, surely?
<rog> fwereade: if we used json as the rpc transport, that would be quite straightforward actually.
<fwereade> rog, and that's all well and good, but it's still an additional api, and I don't think we can currently  justify taking on the cost and hassle of maintaining two when we have a perfectly serviceable one already
<fwereade> rog, "exec" is kinda lowest-common-denominator but that's the point
 * rog 's premature-optimisation head is screaming "but we can do better!"
<rog> but i'm ok to go your route
<fwereade> rog, by introducing another we're implicitly saying "you shouldn't be writing bash scripts, it's better to do it in go" ;)
<fwereade> rog, I hope I've at least half-convinced you rather than just talked you to death ;p
<rog> fwereade: i still have a strong intuition that keeping the command-line parsing in jujuc is somehow more "right". but i'm working hard to try to suppress it.
<fwereade> rog, my intuition that it's "wrong" largely comes from the feeling that the python code takes on a disturbing amount of complexity (apparently) to accommodate that very feeling
<rog> fwereade: which complexity are you talking about there, BTW?
<fwereade> rog, juju/hooks/protocol.py (and all the associated stuff)
<fwereade>     @defer.inlineCallbacks
<fwereade>     def open_port(self, client_id, port, proto):
<fwereade>         """Open `port` for `proto` for this unit identified by `client_id`."""
<fwereade>         yield self.callRemote(
<fwereade>             OpenPortCommand, client_id=client_id, port=port, proto=proto)
<fwereade>         defer.returnValue(None)
<fwereade> etc etc
<rog> i don't mind that file too much. it's fairly naive (in a good way), and it documents the capabilities quite nicely. the Go source would be quite a bit shorter too, i think.
<rog> fwereade: i do see where you're coming from now though. i'm suggesting exactly what's in the current python implementation!
<fwereade> rog, yeah :)
<rog> fwereade: so, for the record, i still think that's the right approach. but i appreciate your arguments in favour of a "command line across the pipe" too.
<fwereade> rog, and it's not just that file -- if's relation-set which calls relation_set which constructs a RelationSetCli which calls the client which calls the server whcih calls the context
<rog> the "client" being the code in protocol.py, yes?
<fwereade> rog, the client/server both being in protocol.py, yes
<fwereade> rog, at some point the ravioli code got to me and I rejected the whole aproach ;)
<fwereade> rog, (lots of tiny little things with hardly any meat in them)
<rog> fwereade: yeah, i appreciate that feeling very well
<rog> fwereade: so in go, it would be command RelationSetCommand which invokes Hook.SetRelation which does rpc.Call("Hook.SetRelation") which invokes unitAgent.SetRelation.
<rog> the ravioli would be in Hook.SetRelation which wouldn't do much more than marshal its arguments and make the call.
<fwereade> rog, all the marshalling is busywork that forces us to touch at least extra two places in the code any time we make a change
<rog> fwereade: yes, i agree. but it's only three lines per call. and we've only got 8 calls, and no prospect of significant numbers of incomers.
<fwereade> rog, but it's still taking on repetitive extra code in exchange for speculated future benefits
<rog> fwereade: i think that having the API laid out in one place (the Hook type) is a benefit in itself.
<fwereade> rog, won't the HookContext interface have all that, without the marshalling busywork?
<fwereade> rog, can't we just add marshalling that talks directly to that when we turn out to need it?
<fwereade> rog, which I again consider to be a somewhat remote prospect
<fwereade> rog, IMO even if you want to write hooks in go you can damn well wrap os/exec like everybody else does :p
<fwereade> rog, well, I guess it'll be Context, RelationContext, DepartedContext interfaces, but details details
<rog> fwereade: hmm, not quite sure how that would work
<fwereade> rog, hm, no need for a separate Departed *interface*, just another implementation of it
<fwereade> rog, sorry brb
<fwereade> rog, b
<rog> fwereade: just thinking about how the unit agent's hook execution would work
<fwereade> rog, take a look at juju.state.hook
<rog> fwereade: from a Go perspective, that is.
<fwereade> rog, understood, but I think there'd be some similarities
<rog> fwereade: here's a sketch: http://paste.ubuntu.com/872817/
<rog> so startHookServer interprets the command line and invokes the appropriate HookContext method (which might return an error if a function was called in an inappropriate context)
<rog> (if the wrong symlink was made, for example)
<fwereade> rog, I think I want to step further away from that idea actually
<rog> so, yeah, the hook context capabilities would be nicely exposed there
<rog> fwereade: which idea?
<fwereade> rog, hook contexts shouldn't be implementing the *commands* themselves; they should just be exposing capabilities made use of by the commands
<fwereade> rog, eg in python, context.get_value(unit_name, key)
<rog> fwereade: so you'd just pass a bitmask of available capabilities?
<fwereade> rog, no, I'd define an interface of available capabilities
<rog> fwereade: isn't that what the HookContext is?
<fwereade> rog, two in particular; one which knows about relations and one which doesn't
<rog> so you'd do a dynamic type check to see if the given interface is implemented?
<fwereade> rog, no...?
<fwereade> rog, take juju-log
<fwereade> rog, the juju-log Command would just have a `ctx PlainContext`; where the relation-set one would have a `ctx RelationContext`
<fwereade> rog, the departed/non-departed implementations of RelationContext would act diferently but there's no reason for the commands to see a difference
<fwereade> rog, where the RelationContext interface includes the PlainContext one
<rog> fwereade: but where does the ctx argument to juju-log come from?
<rog> fwereade: the rpc server can't know in advance that the juju-log command is going to be run
<fwereade> rog, JUJU_CONTEXT_ID
<rog> huh?
<rog> that's not my question.
<rog> i'm talking about within the unit agent
<rog> fwereade: referring back to my code, how would you write RunHook?
<fwereade> rog, pretty much like this: https://codereview.appspot.com/5753057/
<fwereade> rog, so the ultra-minimal Context interface there is all that's necessary to exec a hook in a context
<fwereade> rog, you'd need actual context struct types to implement more fleshed-out interfaces to be useful to their commands
<rog> [10:37] <fwereade> rog, won't the HookContext interface have all that, without the marshalling busywork?
<rog> it seems not
<fwereade> rog, yep, that was horseshit
<fwereade> sorry :)
<fwereade> rog, on that point I fall back to the "we shouldn't be implementing an alternative interface until we know we need it" argument
<fwereade> rog, that said there's nothing stopping us from implementing those methods on HookContext
<fwereade> rog, I'm just not sure it'd be very neat in practice
<rog> fwereade: i think it would be quite neat actually. i think the command-line stuff is clunky, and it's nice to isolate it.
<rog> fwereade: here's what i'd do: http://paste.ubuntu.com/872832/
<rog> then each context just passes a value that exactly implements its needs, and all the command line stuff is confined to startHookServer
<fwereade> rog, tbh it doesn't seem strange to me that an execution context should provide Commands
<rog> it's also potentially easier to test, because you can test the context independently of the command parsing
<fwereade> rog, that's already perfectly possible isn't it?
<rog> fwereade: to my mind the callbacks within the hook execution are fundamentally operations, not commands.
<rog> fwereade: they happen to implemented with commands (currently) but conceptually i think an interface containing the operations to be made available makes better sense to me
<fwereade> rog, in which case IMO they should still be `func RelationSet(ctx RelationContext, blah blah)`
<rog> fwereade: why not an interface containing the set of possible operations, as in my example?
<fwereade> rog, because it includes impossible operations
<rog> fwereade: that's fine. impossible operations return an error.
<fwereade> rog, and because DepartedContext and RelationContext will be disgustingly similar ;)
<rog> fwereade: really? what's the difference between them?
<fwereade> rog, this may come down to the "should we expose meaningless commands" question, and I still think "no"
<rog> fwereade: i think that operationally there's no difference
<fwereade> rog, RelationContext and DepartedContext make different information available
<rog> fwereade: we can always use embedding to remove duplication.
<rog> fwereade: different information available through which operation, BTW?
<fwereade> rog,  departed relations only make the local unit's settings accessible
<fwereade> rog, and should IMO not even expose relation-set etc
<rog> fwereade: i don't have a problem if relation-set runs but returns an error. i don't see that as an issue.
<fwereade> rog, it's not exactly an advantage, though
<rog> fwereade: plus i think there *is* an advantage to avoiding the need to create and populate a directory of symlinks on every hook execution
<rog> fwereade: it means there's no need to write that code...
<fwereade> rog, that 30 lines?
<rog> yeah! 30 lines gone, hurray!
<rog> and one less moving part, also good.
<fwereade> rog, you did just dismiss 24 lines of marshalling, plus all the types and so forth, as insignificant :p
<fwereade> rog, and those aren't exactly non-moving parts either
<rog> fwereade: nah, worth it for the benefits i saw...
<rog> fwereade: but i don't see any particular benefit to creating the command set dynamically.
<fwereade> rog, one moving part in one place vs 8+ distributed here and there?
<fwereade> rog, the benefit is that it allows us to do the rest of our work without worrying about the plumbing
<rog> fwereade: ?
<rog> fwereade: i'm not sure what you mean by "worrying about the plumbing"
<rog> BTW of course i think that some moving parts are worth it... just not this one :-)
<fwereade> rog, I mean that the symlinks need to come from somewhere (or even the individual executables); we can do it manually for each command -- adding types, changing the server, changing jujuc, worrying about how we expose them at deploy time
<fwereade> rog, or we can have the execution context know how to create itself
<fwereade> rog, by just implementing another Command
<fwereade> rog, for, y'know, command-line parsing
<fwereade> rog, which can then interact with the actual context however appears to make sense (I think this in particular is orthogonal)
<rog> i'd thought that the symlinks would just be part of the package. the hook execution code would just add the directory to $PATH and that's it
<rog> the apt-get package, that is
<fwereade> rog, that's still extra packaging work
<rog> fwereade: can't the symlinks simply be in the VCS?
<rog> fwereade: i.e. we create them once and then commit them
<rog> (i admit i know nothing at all about the workings of apt-get)
<fwereade> rog, that's *still* an extra step along with the stuff I was just complaining about
<rog> fwereade: a step that one person has to make once, with no code involved. i don't see that as an issue.
<rog> someone has to install the jujuc command too...
<fwereade> rog, once per command, along with all the other once-per-command steps...
<fwereade> rog, and still the only benefit to all the extra work is that it *might* become easier to implement a speculative feature at some point in the future...
<rog> fwereade: no, not at all
<rog> fwereade: i've moved on from there
<rog> fwereade: i've accepted that the RPC interface is command-line-centric
<fwereade> rog, ok, sorry -- we're purely talking complexity distribution now then?
<fwereade> rog, consider the argument for making agents implement Command
<rog> fwereade: i'm arguing for the use of a Go interface to provide the callback interface rather than a set of Commands
<fwereade> rog, and I'm arguing that we need the Commands for parsing command lines, because we're exposing them to the execution context as command-line tools
<rog> fwereade: i.e. hide the fact that the hook callbacks are implemented with commands, because it's cleaner to do so
<fwereade> rog, and that whether or not Context has that interface, or a different one, is not material
<fwereade> rog, the Commands themselves can talk back to the context over whatever interface makes sense
<fwereade> rog, it may be yours, it may look more like the python ones
<rog> fwereade: i think the Commands can be hidden inside Exec.
<fwereade> rog, then what does all the command-specific command-line parsing?
<rog> fwereade: i think things would be nice if the agent code itself never had to know about Commands
<fwereade> rog, you're saying *Exec* should now know about all the different possible commands and how they should be handled?
<rog> fwereade: that's inside startHookServer (or whatever you might call it) which maps from the command line stuff to calls on the hook context.
<rog> fwereade: yeah, i'm saying that, yes.
<rog> fwereade: it would know about the HookContext interface (which encapsulates all possible hook operations)
<fwereade> rog, the knowledge of the commands is entirely within the context itself; I don't see why the agent should care
<fwereade> rog, seriously: we have a hook execution context that needs to provide env vars and executables; what is the possible benefit of pretending, at this level, that the executables are not really executables?
<fwereade> rog, the actual implementation of RelationSetCommand.Run will either be `c.ctx.RelationSet(c.foo, c.bar)` or `RelationSet(c.ctx, c.foo, c,bar)`
<fwereade> rog,  plus some transformation of the result for stdout, where necessary
<rog> the env vars are for the hook context, not necessarily for the callback operations.
<fwereade> rog, ie it's doing exactly what's needed at this level and not forcing anything on how we implement the operations themselves
<fwereade> rog, yes, exactly so
<fwereade> rog, so are the executables for the hook context
<fwereade> rog, and they're responsible for parsing command lines, running the operations (which can be independent) and returning the results
<rog> i see that your hook package is very general. i think i'm just thinking that something with a little less abstraction would be easier to understand.
<rog> so a Context would be an interface containing the actual operations, rather than a set of arbitrary commands.
<rog> and the environment would be an argument to Exec rather than something returned from the context.
<fwereade> rog, a given Context will expose [1] .Commands() and .Env() for use by Exec and [2] RelationSet, or GetValue, or whatever, for use by the Commands themselves
<rog> [2]
<fwereade> rog, passing the env to exec doesn't alter the fact that it still comes from the context in the first place...
<fwereade> rog, I'm less and less sure that RelationSet should be on the hook context
<fwereade> rog, I think the capabilities exposed by the python hook contexts are at the right level
<fwereade> rog, a RelationSet operation that takes a RelationContext and uses its SetValue method seems pretty reasonable to me
<fwereade> rog, when seen in the context of the total number of ways we need to interact with a context anyway
<fwereade> rog, ie what's implemented in juju.state.hooks
<rog> fwereade: i see a context containing all the operations as a nice reflection of the way that the charm author will see things
<rog> fwereade: i don't see a need to have one type for each operation
<fwereade> rog, in practice a charm author will see the operations-that-don't-always-return-errors as the real interface she has available
<fwereade> rog, RelationSet isn't a type, it's a function
<rog> fwereade: sure. that's what they get in practice
<fwereade> rog, ...so if you're arguing from conceptual integrity, exposing only the operations an author cares about seems sensible to me
<rog> fwereade: Go works better when there's a known set of operations, even if some return errors.
<rog> fwereade: i like the idea of mapping the set of command line callback operations onto a single go interface that encapsulates all those calls.
<fwereade_> rog, what was the last thing you saw me say?
<fwereade_> rog, that I saw from you was:
<fwereade_> <rog> fwereade: sure. that's what they get in practice
<rog> fwereade_: in practice, a charm won't tell the difference between a command that returns an error and a command that doesn't exist
<rog> fwereade_: hence my comment
<rog> fwereade_: even though we can actually implement all the calls all the time
<rog> fwereade_: BTW does the unit agent write to disk for any other reason?
<fwereade_> rog, it does
<rog> ah, the socket
<fwereade_> rog, also stuff like remembering state in case of unexpected process death etc
<rog> fwereade_: the zk reconnection id?
<fwereade_> rog, nah -- what hooks have been queued and not executed, what relations we're currently part of, etc
<rog> interesting
<fwereade_> rog, stuff like that is not appropriate for ZK -- nothing else needs to know about it
<fwereade_> rog, basically just local state that needs to be persisted for one reason or another
<fwereade_> rog, also stuff like upgrading the charm itself :p
<rog> fwereade_: is there an operation log or something? (i'm wondering how it deals with atomicity of writes)
<fwereade_> rog, I'm not sure exactly what context we're talking about
<rog> fwereade_: so, if you've just queued a hook, you need to write to disk that you've queued it, right, in case you die there and then?
<fwereade_> rog, that's the general idea yes
<rog> fwereade_: so i was wondering how it managed that data such that it doesn't grow without bound but it's ok whenever the process dies unexpectedly.
<fwereade_> rog, whenever we've executed something we rewrite the queue without the executed thing
<rog> fwereade_: so if it dies half way through rewriting the queue?
<fwereade_> rog, mv is atomic, right?
<rog> fwereade_: ah, so we create a new file each time we queue an operation. makes sense.
<fwereade_> rog, if it dies after executing but before rewriting, no big deal, we execute that hook again
<fwereade_> rog, the danger is executing a hook 0 times; sometimes executing one twice is not a major issue
<fwereade_> rog, anyway, I suspect the does-the-agent-write-to-disk question fed back into the original discussion in some way
<rog> fwereade_: yeah, but only if it didn't write to disk :-)
<fwereade_> rog, haha :)
<rog> fwereade_: in the end perhaps it comes down to this: i really like the look of this type (http://paste.ubuntu.com/872911/) and i like the directness of passing that as an argument rather than passing a context that can return a list of Commands that when Run can excecute the relevant operations.
<rog> fwereade_: but i understand your approach, i think, and it will work fine too
<rog> fwereade_: thanks for going round the garden path with me :-)
<fwereade_> rog, a pleasure :)
<TheMue> HOLY SH...
<TheMue> i'm trying to find out why my watcher isn't firing. and what did i missed? starting the goroutine which listens to the watch.
<TheMue> so stupid, aaargh
<rog> TheMue: i did exactly that when writing the example code!
<rog> TheMue: (did you see it, BTW?)
<TheMue> rog: opened several pastes regarding this topic. which one you're referencing?
<TheMue> HA! great, now it fires. you only have to do it right. *smile*
<rog> TheMue: this one: http://paste.ubuntu.com/871544/
<TheMue> rog: oh, no, will study it. tom tom.Tomb is a funny declaration. ;)
<rog> tomb tomb Tomb TOMB!
<TheMue> rog: and i have to update my Tomb, i have still Fata instead of Kill
<TheMue> Fatal
<rog> TheMue: there was one thing wrong in that example: FooWatcher.Err should return w.tomb.Err not w.tomb.Wait
<TheMue> rog: yep, sounds reasonable
<rog> other than that, i think it represents pretty well the structure we were talking about.
<rog> TheMue: oh yes, that example won't work without my tiny local/testzk package
<rog> TheMue: ... the implementation of which is here: http://paste.ubuntu.com/872945/
<TheMue> rog: mine is now working and needs only some last adjustments and more tests
<rog> TheMue: cool
<rog> TheMue: i wonder how similar it is...
<TheMue> rog: so far very similar. only that my watcher is only observing the creation and deletion of a node
<TheMue> rog: and i retrieve the agent key out of the path
<rog> TheMue: yeah. i chose the children example because it can be used to demonstrate delta events, but it could've been anything
<TheMue> rog: it's a good example, more complex than mine
<rog> TheMue: i hope you find it useful :-)
<TheMue> rog: for sure, gives more security
<niemeyer> Greeetings
<hazmat> greetings
<hazmat> niemeyer, its alive!
 * hazmat points at the soon to be deployed store
<niemeyer> hazmat: Almost there! :-)
<niemeyer> fwereade_, rog: https://codereview.appspot.com/5758061
<niemeyer> Should be a trivial one given previous reviews
<niemeyer> Hmm.. how do specify cross-PPA dependencies again..
<rog> niemeyer: review delivered
<niemeyer> rog: Cheers!
<andrewsmedina> niemeyer: I sent two reviews, one for initial lxc port to Go
<andrewsmedina> niemeyer: and another to goetveld
<niemeyer> andrewsmedina: Thanks a lot.. I'll finish sorting out the store details and will get back on track in review land
<andrewsmedina> niemeyer: ty
<fwereade_> hmm, I guess I should eat something, bbiab
<TheMue> niemeyer: what can cause zk to close a connection after a Delete() of a node?
<TheMue> niemeyer: i create my agent node => watch fires correctly; now i delete it => next event is "zk connection closed"
<niemeyer> TheMue: a connection closed event is unrelated to deletions
<niemeyer> TheMue: You just happen to be seeing that event because that's when you asked about it, but that's not what the event is being caused by
<niemeyer> Has it ever happen to anyone that some kind of white rectangle shows at the top of the screen, on the left-hand side?
<niemeyer> It's a bug in some app and I can't spot which one it is because xwininfo shows the underlying window rather than the float
<TheMue> niemeyer: i know that it isn't related and hadn't it ever before. so i'm wondering this time.
<niemeyer> TheMue: It's something else.. the delete is a red-herring
<TheMue> niemeyer: i know - but still have no clue
<TheMue> niemeyer: will try something to gather more infos
<rog> "That's what Russ said, but besides the point above, this is definitely not ok to ignore. There's both a read and a write side."
<rog> niemeyer: not quite sure what you mean by that
<rog> niemeyer: this is just the write side, yes?
<niemeyer> rog: Copy reads and writes
<rog> niemeyer: ah, good point. that's fine then.
<rog> niemeyer: (i was thinking about the http client reading)
<niemeyer> rog: Cool
 * rog wishes it was possible to easily distinguish read and write errors when returned from io.Copy
<niemeyer> "not entirely convinced, but fair enough."
<niemeyer> rog: People log 200 results from web sites on a regular basis
<niemeyer> rog: Logging errors sounds like an extremely natural thing to me, FWIW
<rog> niemeyer: ok. i guess i was just extrapolating from russ's remark.
<niemeyer> rog: Russ pointed out that there's no reason to *return* an error
<rog> niemeyer: it sounds like they're not really errors, because they'll happen whenever the client is aborted
<niemeyer> rog: And I agree with him on that
<niemeyer> Knowing about errors in an app we care about is a different story, though
<rog> niemeyer: huh? it's ok to ignore write errors but only sometimes?
<niemeyer> rog: Not sure how you got to that conclusion
<rog> [15:46] <niemeyer> rog: Russ pointed out that there's no reason to *return* an error
<rog> that's ignoring the error AFAICS
<niemeyer> rog: Are we ignoring the error in that handler, even though we're not returning it!?
<rog> niemeyer: yes
<niemeyer> rog: No, we're not ignoring it.. we're logging the error, and we're reporting to the client that errors happened
<rog> sorry
<rog> yes, but if the write error happens in Flush or WriteHeader then we have to ignore it
<rog> because it's not returned for us to log
<niemeyer> rog: Ok, nevermind.. are you happy with the current branch content or do you want something else there?
<rog> obviously the handler can't return the error - it has no return value
<rog> niemeyer: LGTM. you might want to consider StripPrefix to remove the /charm repetition and the need for a panic check, as i just mentioned in my reply.
<rog> niemeyer: but i don't mind either way.
<niemeyer> rog: I still want a panic if it doesn't match..
<rog> niemeyer: you won't see /charm in the URL if you use StripPrefix
<rog> niemeyer: so there's nothing to check.
<rog> niemeyer: (and nothing to strip off either)
<niemeyer> rog: Exactly.. I want to check if the prefix being stripped is wrong, and panic so that when someone changes /charm to whatever else and forget to update that code, it blows up rather than failing silently
<rog> there's only one occurrence of /charm needed, AFAICS
<rog> so there'd be nothing to update
<niemeyer> rog: Which prefix is being stripped?
<rog> niemeyer: the /charm prefix.
<rog> niemeyer: i'd write a tiny helper function that added the mux handler and put a strip prefix handler on it
<niemeyer> rog: Sounds good.. I'll move on with what's there though, as it seems to be safe and work well as far as I can see.
<rog> niemeyer: yeah, that's fine. when you have more handlers you might want to move in that direction though.
<rog> niemeyer: if there are ever more handlers :-)
<niemeyer> There will be.. by then I worry about it
<niemeyer> Lunch time.. biab to sort out deployment details..
<TheMue> robbiew: i:m ready when are
<robbiew> TheMue: ack...need 5min
<TheMue> robbiew: ok
<TheMue> rog: followed your concept of using new watches in each loop run. now it works fine.
<robbiew> TheMue: 5 more minutes...waiting on an update to complete :/
<TheMue> robbiew: :D
<robbiew> TheMue: https://talkgadget.google.com/hangouts/extras/canonical.com/the-hulk-hideout
<rog> TheMue: not sure what you mean by that, but i'm glad you've got it working...
<TheMue> rog: in my first approach i tried to use only one watch. now i'm creaing a new one like you inside the loop each time. you do it with a GetW, i with an existsW
<rog> TheMue: ah - you hadn't appreciated that a watch fires only once...
<rog> TheMue: i was confused by that initially too
<TheMue> rog:exactly
<hazmat> jimbaker, could you have a final look over the maas provider branch, i think its good to go, i'm planning on landing it today, but wanted to make sure you had a chance to look over it first.
<TheMue> back again
<jimbaker> hazmat, sounds good. i looked at last night and i think it's fine, but i'll do one more pass
<jimbaker> hazmat, also i have a new version of the spec on the relation support changes ready for review; it's about half the size of the original
<hazmat> jimbaker, awesome
 * niemeyer waves
<hazmat> bcsaller, any updates on subordinates, i saw the subordinate-relation-types is in for review, i'm curious what's next/left, is it just the status support branch?
<bcsaller> hazmat: no no, working on the changes to unit lifecycle now
<bcsaller> actually triggering the deploy and all that
<bcsaller> hazmat: its starting to come together I think
<hazmat> bcsaller, ah.. right jim's deploy refactor wired into the unit rel watcher
<hazmat> bcsaller, cool
<bcsaller> hazmat: yeah in unit/lifecycle, I had to merge it into this branch by hand as it wasn't on trunk yet
<hazmat> bcsaller, luckily its your review day, so you can help move it along  ;-)
<bcsaller> hazmat: looks likes its already approved, but point taken
<hazmat> yeah.. i'm going to be spending most of the day merging extant approved branches
<hazmat> i've been refactoring the scheduler to have some better behavior (at least once wrt to events, instead of at most once)
<hazmat> niemeyer, i believe we had some discussions on the last meeting wrt to this. I believe the conclusion was on failure for hook execution on an event we should keep the event around, and if resolved --retry rexecute the hook, or if not pop it off the queue.
<hazmat> s/on/in
<niemeyer> hazmat: Yeah, unless there's some bad idea, doing the same we do for other cases sounds sane at least
<hazmat> niemeyer, indeed it does
<jimbaker> bcsaller, hazmat, sounds good about getting refactor-machine-agent into trunk
<niemeyer> hazmat: s/bad/better/, sorry
<niemeyer> hazmat: But I guess you go tit
<hazmat> lol
<niemeyer> :-)
<hazmat> must be a golang thing ;-)
<niemeyer> hazmat: If it was go tit(), it might be.. but that's just a very funny typo.. :D
<jimbaker> there's also a minor branch depending on that, robust-test-removed-service-unit
<hazmat> jimbaker, cool, it looks like it still needs a review though.
<jimbaker> hazmat, btw, when do you go out to pycon? i arrive pretty late tomorrow night
<jimbaker> hazmat, re refactor-machine-agent, yes, just comments so far
<hazmat> jimbaker, i arrive to sfo tomorrow at 6pm, i should be at the hotel by 8pm
<jimbaker> hazmat, i should be at the hotel by 11p, so i guess i'll see you fri
<jimbaker> unless i happen to catch you in the bar ;)
<hazmat> jimbaker, sounds plausible ;-)
<hazmat> sigh.. i'm starting to think it might just be simpler to rewrite the scheduler
<hazmat> if starting to feel like there's too many edge cases with the current data structures
<hazmat> if/its
 * rog is off for the evening. until tomorrow.
<hazmat> although even with a simplified list we have versions and memberships to track, but i hope we can fold those into the list
 * hazmat lunches
<hazmat> niemeyer, SpamapS so agent-state for machines sound good, for consistency that also means turning the unit's 'state' key to an agent-state key
<niemeyer> hazmat: +1
<niemeyer> hazmat: Even though that's a little bit more subtle
<niemeyer> hazmat: Since the "unit" is actually represented by the agent itself
<hazmat> niemeyer, yeah. its quite a bit richer wrt to semantics
<niemeyer> hazmat: While the "machine" has an independent life
<niemeyer> hazmat: I'm happy with the change, though..won't hurt to be clear
<hazmat> niemeyer, i'm happy either way re unit 'state' to 'agent-state'.. i can banish the hobgoblin of consistency.. even though there both agents, as you say the state reported there is the unit's not really the agents.
<niemeyer> hazmat: What are the values we have for the unit's state?
<niemeyer> hazmat: not-started and .>?
<niemeyer> started? anything else?
<niemeyer> hazmat: Also, I wonder about what happens if the agent dies.. is that state updated? :-)
<niemeyer> State is hard..
<hazmat> niemeyer, started, start_error, install_error, stop_error, stopped
<niemeyer> hazmat: What about for the machine agent?
<hazmat> niemeyer, just running or pending
<hazmat> there is no state machine for  the machine agent
<niemeyer> hazmat: Hmm.. that's instance-state.. I mean the current "state" that we're talking about chnaging
<niemeyer> The go tool+conventions and launchpad's daily builds were made for one another
<niemeyer> hazmat: Just check that out: https://code.launchpad.net/~niemeyer/+recipe/charmstore
<niemeyer> hazmat: You've hacked around with PPAs before, right?
<hazmat> niemeyer, very nice
<niemeyer> hazmat: The whole build is "go install launchpad.net/go/store"
<hazmat> niemeyer, so re the unit's state.... the machine agent state is really just running, pending, or down. the machine instance state has pending or running.
<niemeyer> hazmat: I got not-started, so this must be at least not reflecting the actual names
<hazmat> down is basically the same as pending, ie the agent isn't connected, we just infer that it must have been running if it has an assigned unit with a state.
<hazmat> niemeyer, yeah.. pending == 'not-started'
<niemeyer> hazmat: Ok
<hazmat> actually that's not true
<niemeyer> hazmat: Does running => down happen automatically based on ephemerals?
<hazmat> not-started means no machine id.. so provisioning agent hasn't acted, pending means its got an id, but no address
<hazmat> niemeyer, yes
<niemeyer> hazmat: Ok, that's nice.. what about the unit's state.. does it shift automatically to down based on ephemerals as well?
<hazmat> hmm.. interesting.. we actually stick 'pending' into the instance-id field of the machine instead of the state.. hrm.
<hazmat> niemeyer, it does
<hazmat> for status display, a unit is 'down' if its agent is not connected
<hazmat> and the unit workflow state is shown if its connected
<niemeyer> hazmat: The pending in the instance-id sounds reasonable I guess?
<niemeyer> hazmat: Hmm.. or maybe not..
<niemeyer> hazmat: We're supposed to have the id from the moment we request.. so I'm not sure about why we'd show pending
<niemeyer> hazmat: Or do you mean instance-state rather than instance-id?
<hazmat> niemeyer, we might not have processed the zk state into a provider request and instance-id
<hazmat> ie. the provisioning agent hasn't caught up yet
<niemeyer> hazmat: Ah, bingo
<niemeyer> make: dh_clean: Command not found
<niemeyer> WTF?
<niemeyer> hazmat: So, yeah.. I'm happy with changing both to agent-state if you'd like that
<niemeyer> hazmat: Btw, is it start_error or start-error that we show?
<hazmat> niemeyer, underscore
<hazmat> niemeyer, i'm starting to feel like it should remain 'state' for unit.. because its not really the agent's state, its the charm and unit's state that's being represented.. the unit agent by itself is either running or its not, if its running we report the unit state, if its not we report the unit is down.
<niemeyer> hazmat: bummer re. the underscore :(
<hazmat> niemeyer, we could change it to display.replace("_", "-")
<niemeyer> hazmat: It's actually the agent.. the software in the unit might be running even if the agent is down
<niemeyer> hazmat: For consistency, I'd find that quite adequate.. I think we've managed to stick to dashes in pretty much every other option
<hazmat> right.. but its not really the agent's state.. its the unit aka charm instance's state. the underling service is of course independent
<niemeyer> hazmat: It's the agent really.. start-error means the *agent* is in a start error state
<niemeyer> hazmat: Because the hook failed, true.. but it's the agent that is locked in that state
<hazmat> okay.. its good to have the consistency of key and to distinguish service vs agent.
<hazmat> agent-state for both
<hazmat> niemeyer, sorry that got long winded.
 * hazmat looks for some caffeine
<niemeyer> hazmat: No worries, thanks for explaining.. I had vague memories about it
<niemeyer> Found the dh_clean error.. for some reason it was setup to upload to the wrong ppa
<niemeyer> Which didn't have the proper dep
<niemeyer> Awwwwww
<niemeyer> 3h estimated build time for the charmstore
<niemeyer> Suddenly the Go build time was severely downgraded by Launchpad :-(
<niemeyer> Folks, I'll have a shorter day today as we have a family gathering tonight..
<niemeyer> See you all tomorrow
<hazmat> wtf tests seem to have stalled out a few weeks ago
#juju-dev 2012-03-08
 * hazmat wonders if he needs to send a mother may i email to the list
<fwereade> rog, hopefully trivial: https://codereview.appspot.com/5786051
<fwereade> rog, and, blast, I just realised you've got that gozk review still up (right?)
<fwereade> rog, I checked for *juju* reviews and completely forgot the rest  :/
<rog> fwereade: yeah, i've been waiting for almost 2 weeks now. sigh.
<fwereade> rog, I know the feeling
<fwereade> rog, I think I've passed some sort of milestone now, though: I have more go branches stacked up than I do python ones
<rog> fwereade: :-)
<rog> fwereade: i wonder if instead of a new package, whether we might expand the jujutest package a bit to add testing code.
<rog> fwereade: it could be moved out of environs, and maybe just renamed "test", perhaps.
<fwereade> rog, doesn't sound like a bad idea, I could follow up with a branch that does that perhaps?
<fwereade> rog, for some reason I expect things called "test" to contain actual tests
<fwereade> rog, but I'm not seriously opposed to that name
<rog> fwereade: given that testutil is new, why not add ZkSetUpEnvironment to jujutest now?
<rog> fwereade: we could call it "testing"
<rog> fwereade: i know it matches the name of the std testing package, but i don't think that's a problem
<rog> import "launchpad.net/juju/go/testing" sounds reasonable to me
<rog> fwereade: it's a pity that zookeeper won't work unless it makes its own directory. then ZkSetUpEnvironment could just return a zk.Server.
<TheMue> rog:  +1
<rog> TheMue: nothing we can do about that though...
<TheMue> rog: the testing package or the directory part?
<rog> TheMue: the directory part. were you referring to the testing package?
<fwereade> rog, so we'd do `import jtesting "launchpad.net/juju/go/testing"` or something?
<TheMue> rog: yep
<rog> fwereade: yeah, but the identifier would only be necessary if you were already importing "testing". (probably true most of the time in the zk scenarion)
<rog> i quite like "scenarion"
<TheMue> rog, fwereade : as long as our functions in the package have a clean naming it also could be imported with _.
<rog> TheMue: huh? surely we can't if we want to use it...
<rog> ?
<TheMue> rog: eh, i meant . like with gocheck
<rog> TheMue: no no no! no more import "."s! gocheck is one too many as it is!
<TheMue> rog: what troubles do you have with it?
<rog> TheMue: namespace pollution
<rog> TheMue: why don't we import many things with "."?
<rog> TheMue: answer: because it's nice to see a name and know where it comes from.
<rog> TheMue: import "." is only there because of it was conventional to write tests as if they were part of the same package as they're testing.
<rog> TheMue: and sometimes there's a cyclic dependency
<TheMue> rog:  definitely, but then we need a different package naming then testing. otherwise aliases also can difer over different sources and you get a bad maintenance aspect
<rog> TheMue: but IMHO it should never be used
<rog> TheMue: i don't think that's a problem.
<rog> TheMue: the compiler knows and will tell you very quickly
<rog> TheMue: we already have two packages with the identifier "ec2" for example
<rog> TheMue: and it's not a problem.
<TheMue> rog: i don't talk about the compiler, i talk about people who maintain different sources where the same testing package is imported with different aliases
<TheMue> rog: and i our tests we would need to import both, so one always has to be aliased
<rog> TheMue: it's not uncommon to rename a package with a different alias when you import it
<rog> TheMue: if we have a standard alias in that case, i don't think there's a problem
<rog> TheMue: for example, when i import "launchpad.net/goamz/ec2" and "launchpad.net/juju/go/environs/ec2", i name the former "amzec2".
<rog> TheMue: similarly we can import "juju/go/testing" as jujutesting when there's a clash.
<TheMue> rog: and i talk about this "standard". i've seen enough projects where standards changed with the changing team members. while we are few and fresh there's no prob, but in longer terms
<rog> TheMue: it doesn't matter too much. it's a variable name - we have preferences but not strict rules.
<TheMue> rog: that's one of the problems
<TheMue> rog: it will differ over time
<rog> TheMue: the package identifier?
<TheMue> rog: and new code maintainers will stumble about it
<TheMue> rog:the aliases for the same package in different tests
<rog> TheMue: i don't think it'll cause more than a moment's pause.
<rog> TheMue: most of our packages don't use the standard "testing" package.
<TheMue> rog: the tests do, and they often will import both, the standard and our testiing package
<rog> TheMue: and it can't give rise to any more problems than a failed compile AFAICS
<TheMue> rog: the problem is not the compiler run, the problem are the 70% maintenance part of software costs when new people in a few years sit in front of the software and try to understand it
<rog> TheMue: i don't see that as a problem in this case - a quick glance at the top of the file will immediately resolve any queries
<TheMue> rog: this look here, that look there, another look at a different time - that sums
<TheMue> rog: just again, 70% of software costs are maintenance costs
<rog> TheMue: also, which one you're using will be obvious from the context.
<rog> TheMue: remember, you were suggesting importing as ".". that's much worse!
<TheMue> rog: yep, i've got to admit that this has been a bad idea. a reason why i wonna look for a better one
<rog> TheMue: if i see "testing.Something" i know that it's got to be one of only two packages with that identifier. and the Something will be something juju-related or not.
<rog> TheMue: all that said, have you got another suggestion for a name?
<TheMue> rog: not yet, im trying to find one.
<TheMue> rog: hmm, opposit to testing or gocheck it doesn't provide a testing itself
<rog> TheMue: no, but it's about testing juju, and that seems ok to me
<TheMue> rog: it's more that it will contain tools for testing juju
<rog> TheMue: the other suggestion was "test", which might be ok too
<rog> TheMue: as it does contain some tests as well as utils
<TheMue> rog: my ideas are testtools or testenv so far
<rog> TheMue: it's more than just tools - it has tests. and it's more than testing the environment.
<TheMue> rog: shall it DO tests or only SUPPORT tests? and i didn't meant to test the environment but to provide an environment for juju testing
<rog> TheMue: currently it *does* tests. i'm suggesting that it be a catch-all package for common stuff to do with testing juju, including tests and test tools
<TheMue> rog: how does it relate to the tests inside the packages?
<TheMue> rog: i would like a package providing the environment and tools but to keep the individual tests inside the packages
<rog> TheMue: it currently implements provider-independent tests to test an Environ
<rog> TheMue: the whole point is that those tests are independent of a particular provider, so they can't live in a single package.
<rog> fwereade: i've just discovered that the current zk behaviour (can't create a server on an existing directory) is entirely my fault. if i fix that, then we don't need a TearDownEnvironment, just srv.Destroy.
<TheMue> rog: don't the provider packages have a superior pckage for those tests?
<rog> TheMue: sorry, i don't understand.
<fwereade> rog, ah, cool
<TheMue> rog: a package one level above.
<rog> TheMue: do you mean launchpad.net/juju/go/environs ?
<TheMue> rog: yes
<rog> TheMue: i don't want to pollute its exported namespace with testing code
<TheMue> rog: won't that testing package be exported too?
<rog> TheMue: hence i use a different package (currently launchpad.net/juju/go/environs/jujutest)
<rog> TheMue: yes, but that testing package is *just* about testing.
<rog> TheMue: i don't want to mix testing code and production code - it'll just confuse people.
<TheMue> rog: yep, that's right
<TheMue> rog: so far in my case the testing stuff is invisible
<rog> TheMue: so i was proposing to fwereade that the jujutest package becomes launchpad.net/juju/go/testing
<rog> TheMue: because i'm not sure we need a proliferation of packages to do with juju testing.
<TheMue> rog: the movement makes sense, still i've got a naming problem
<rog> TheMue: ok, well perhaps we'll keep the existing name ("jujutest") for the time being, pending discussion.
<TheMue> rog:it's that the standard "testing" is a test framework/library while our "testing" would be tests
<TheMue> rog: "juju" would be redundant there, how simply "tests"
<rog> i kind of agree with fwereade's earlier comment:
<rog> [10:58] <fwereade> rog, for some reason I expect things called "test" to contain actual tests
<rog> TheMue: i don't mind that we're not implementing a testing framework. it's still all about testing, and that's the main thing IMHO.
<fwereade> rog, the thing is I do see the proposal as creating the very rudimentary beginnings of a testing framework
<rog> fwereade: +1
<TheMue> fwereade: in this case we should not put this framework and the tests themself into one package
<fwereade> rog, ok, running a zookeeper server isn't much, but I also expect that we'll want to make it easy to get access to a temporary charm repo we can write to without messing with source control for example
<fwereade> rog, my perspective is that the proposal moves a small step in a good direction that I can then use to start testing hook contexts
<rog> TheMue: i don't mind too much if they're in the same package. it's not going to be a large package, and it has reasonable conceptual integrity IMHO
<rog> fwereade: i'm not entirely sure about the ZkTestingT etc functions. i think we can go simpler without sacrificing much convenience. how about this? http://paste.ubuntu.com/874476/
<rog> fwereade: i'm assuming a couple of changes to the zk package
<rog> fwereade: 1) that the server type gets an Addr function that can be used to find out an address for the server
<rog> fwereade: 2) that the server can be created on an existing directory, as long as it's empty
<rog> fwereade: then we can potentially combine other similar utils, rather than relying on a single thing to call TestingT for us with the right resources.
<rog> fwereade: here's another idea, that saves us the error checking each time: http://paste.ubuntu.com/874481/
<rog> fwereade: (TestingT is implemented both by *testing.T and *gocheck.C)
 * hazmat yawns
<fwereade> rog,sorry, Iwasat lunch, give me a sec to catch up
<fwereade> rog, tbh I'm entirely unattached to any specific interface
<fwereade> rog, what I suggested I suggested purely because it looked like it'd work both for state and for my needs
<wrtp> fwereade: cool. what do you think of, say, my last suggestion?
<fwereade> wrtp, that looks fine to me
<fwereade> wrtp, I like the idea of having Addr on Server too
<wrtp> fwereade: good.
<fwereade> wrtp, btw, re the zk locking:
<fwereade> wrtp, I'm comfortable with tests that can theoretically fail under enough load
<fwereade> wrtp, but that's kinda hard to quantify
<wrtp> fwereade: yeah, i kind of am too, but it's that creeping "i'm adding just that little bit more flakiness" feeling that concerns me
<fwereade> wrtp, for example, how low does the tiemout have to be on your machine before you start to see semi-regular failures?
<wrtp> fwereade: i don't know. wait until we're running the tests on ARM :-)
<fwereade> wrtp, heh
<wrtp> niemeyer: yo!
<fwereade> wrtp, ok, what if you run them 100 times now?
<niemeyer> Good morning jujuers!
<fwereade> niemeyer, heyhey
<niemeyer> wrtp: Heya
<niemeyer> fwereade: Alow
<fwereade> wrtp, what would be the expected failure count?
<wrtp> fwereade: i'll have a try. am just writing a test for CreateServer currently.
<wrtp> niemeyer: after discussion this morning, i'm changing zookeeper.CreateServer so that it will succeed if the server directory exists and is empty.
<wrtp> niemeyer: which means that Server.Destroy is sufficient to delete the tmp directory.
<niemeyer> wrtp: Hmm.. why is it necessary?
<niemeyer> (awww... charmstore build broke in the PPA)
<wrtp> niemeyer: darn. hope you get good logs...
<wrtp> niemeyer: because fwereade proposed this: https://codereview.appspot.com/5786051/diff/1/testutil/zk.go
<wrtp> niemeyer: and i thought the complexity is unecessary
<wrtp> niemeyer: it seems silly that you can create a temp directory and run a zookeeper server in it.
<wrtp> s/can/can't/
<wrtp> niemeyer: so this was my counter-suggestion: http://paste.ubuntu.com/874481/
<wrtp> niemeyer: assuming also an Addr method on Server.
<niemeyer> wrtp: Looks good. Don't we have Addr?
<wrtp> niemeyer: nope, i don't think so.
<wrtp> niemeyer: it would just return 127.0.0.1:port
<niemeyer> wrtp: Yeah, it sounds fine.. how do we even connect to the test server nowadays then/
<niemeyer> ?
<wrtp> niemeyer: we just assume localhost
<wrtp> niemeyer: and we specify the port, so we know the address.
<niemeyer> wrtp: Ah, gotcha
<niemeyer> wrtp: Yep, +1 on Addr too
<wrtp> niemeyer: there was also a discussion about where to put this kind of helper function.
<wrtp> niemeyer: i wondered if it might make sense to make environs/jujutest more general.
<wrtp> niemeyer: and perhaps rename it to launchpad.net/juju/go/testing
<wrtp> niemeyer: TheMue wasn't so happy about that name though, because of the clash with the standard testing package
<hazmat> niemeyer, http://wtf.labix.org has been mia for a few weeks.
<hazmat> niemeyer, also the enhanced relation support spec is ready for a review (its been revised and scoped appropriately)
<hazmat> niemeyer, and g'morning
<niemeyer> hazmat: Morning :-)
<niemeyer> hazmat: Will check it out
<niemeyer> s/it/them
<niemeyer> wrtp: Hmm
<niemeyer> wrtp: jujutest doesn't feel entirely generic
<wrtp> niemeyer: the name or the stuff in it?
<niemeyer> wrtp: The stuff in it
<wrtp> niemeyer: it's only two types. if renamed EnvironTests and EnvironLiveTests, i think they'd live quite happily alongside other more generic testing-related functions
<fwereade> wrtp, I guess the question is, how many other packages will be using them?
<wrtp> fwereade: all the environs implementations. that's it, probably.
<fwereade> wrtp, that does suggest to me that it might live more happily under environs tbh
<niemeyer> wrtp: Maybe rename go/environs/jujutest as go/environs/envtest, and create a new go/jujutest/?
<wrtp> niemeyer: yeah, that would work, although i quite like go/testing as a name
<niemeyer> wrtp: envtesting and testing then?
<wrtp> niemeyer: sounds good
<niemeyer> wrtp: I don't mind "testing".. we don't use the stock testing package except for hooking gocheck in anyway
<wrtp> niemeyer: i agree.
<wrtp> niemeyer: although, to play devil's advocate, the function to create a new zk server will be used in a context where both "testing" packages are imported.
<wrtp> niemeyer: i'm happy to import "launchpad.net/juju/go/testing" as gotesting, or "testing" as stdtesting though.
<niemeyer> wrtp: The latter, please
<wrtp> niemeyer: yeah. internal gets preference.
<niemeyer> wrtp: Yeah
<wrtp> fwereade: do you want to mutate your CL accordingly while i'll make the changes to zk.
<wrtp> s/\./?/
<wrtp> fwereade: (assuming it sounds good to you, of course)
<fwereade> wrtp, sure, sounds great
<fwereade> wrtp, except, sorry, I'm slow
<fwereade> wrtp, we surely don't actually want to leave the temp dir hanging around, do we?
<wrtp> fwereade: srv.Destroy removes the zk directory and its contents.
<fwereade> wrtp, doh sorry
<wrtp> np
<niemeyer> OMG..
<niemeyer> The charmstore package is biult
<niemeyer> built
<niemeyer> Woohay!
<niemeyer> "You can now launch 64-bit operating systems on the m1.small and c1.medium instances."
<wrtp> niemeyer: congrats!
<niemeyer> wrtp: 8)
<niemeyer> wrtp: Thanks
<fwereade> niemeyer, respectively: cool!; grar, constraints change
<wrtp> fwereade: i was going to make the zk.CreateServer changes independent of the safe-close branch, but the safe-close branch also did all the changes for the gocheck changes, so i think i'll have to wait until that's ready.
<wrtp> fwereade: sorry.
<fwereade> wrtp, no worries, I'll just duplicate the setup stuff for now, it's not too much to carry for a limited time
<wrtp> fwereade: sounds good
<fwereade> wrtp, although one note I decided not to bother with was "shouldn't the gocheck changes be independent?"
<wrtp> fwereade: yes, they should.
<niemeyer> Getting no-deps binaries out of "dpkg -L <go app>" never gets old
<wrtp> fwereade: but it takes so long to turn around one branch, i thought it better to do them in the same one. bitten!
<fwereade> wrtp, yeah, it's a self-reinforcing problem
<niemeyer> robbiew: ping
<wrtp> niemeyer: i don't understand one bit of that remark :-)
<fwereade> wrtp, slow turnaround -> bigger diffs -> yet slower turnaround
<niemeyer> wrtp: This command lists the files in a package
<wrtp> fwereade: yeah. well, the diffs were fairly small for the gocheck changes, hence my merging.
<fwereade> wrtp, indeed, not an irrational response
<wrtp> niemeyer: still in the dark "Getting no-deps binaries"? you don't need to explain, BTW :-)
<niemeyer> wrtp: binaries without dependencies
<wrtp> ah, i understand now. no dynamic library dependencies...
<niemeyer> wrtp: No additional package dependencies, at least.. it does link against some dynamic libraries
<wrtp> niemeyer: can you tell that from the output of dpkg -L ?
 * wrtp is not versed in the lore of dpkg and friends :-)
<robbiew> niemeyer: pong
<niemeyer> robbiew: Heya
<niemeyer> robbiew: I could use that RT push :)
<robbiew> :)
<robbiew> niemeyer: ticket #?
<niemeyer> wrtp: I can tell there are only two binaries
<niemeyer> robbiew: 51351.. a pretty number!
<robbiew> lol
<robbiew> ack
<niemeyer> robbiew: I've contacted #is first, but given the silence filed this RT yesterday with the IRC questioning
<niemeyer> robbiew: and then enhanced to include more details such as the PPA, package name, etc
<niemeyer> robbiew: It'd be great if we managed to find someone in IS that would be indeed interested on mongodb
<niemeyer> robbiew: But I suspect it won't be easy, given previous conversations with James
<robbiew> heh...my powers of influence only expand but so far
<niemeyer> robbiew: Yeah, not a matter of power in this case.. I was only expressing a desire to find someone there that would be interested, which of course can't be forced in any way
<robbiew> right
 * robbiew will begin his Jedi mind trick training next week :P
<niemeyer> robbiew: LOL
<niemeyer> and that's lunch time
<TheMue> So, agent with watcher is ready for review: https://codereview.appspot.com/5782053
<niemeyer> TheMue: WOOHAY
<niemeyer> I'm now actually blocked on the store since I depend on IS, so I'm moving back onto reviewing mode
<wrtp> TheMue: i'm having a look now
<wrtp> niemeyer: any chance you could start with the oldest ones? :-)
<niemeyer> wrtp: Sounds like  a plan ;)
<niemeyer> wrtp: Do you have a preference of ordering to make better use of your remaining time today?
<TheMue> wrtp: *lol*
<wrtp> niemeyer: jeeze. let me think.
<wrtp> niemeyer: go-ec2-robustness is the major one that i'd love to see
<niemeyer> fwereade_: Btw, can you help me out a bit by providing a map for your branches?
<niemeyer> fwereade_: I'd prefer to review the tip and then ask you to repropose the ones that have pre-req once the pre-req is merged, so that we have a clean diff to work on
<fwereade_> niemeyer, go-add-cmd-context and go-add-hook-package are the independent ones
<niemeyer> fwereade_: Ok.. would you mind to put the rest of them as Work In Progress at https://code.launchpad.net/juju/+activereviews until their diff in Rietveld is clean for review?
<fwereade_> niemeyer, and kinda go-testutil, but that depends on gozk changes which themselves depend on other gozk changes I think
<fwereade_> niemeyer, sounds good
<niemeyer> fwereade_: That's fine.. go-testutil can stay since, even though it has dependencies, they are not polluting the diff itself, right?
<fwereade_> niemeyer, they're not polluting the diff but they are preventing it fromcompiling, I think it's better to WIP that as well
<niemeyer> fwereade_: It's fine to keep it in review then, IMO.. but please just don't merge while the pre-req isn't there
<fwereade_> niemeyer, ok,sounds good :)
<wrtp> fwereade_: heads up: the zk.Server.Addr method returns (string, error) not just string. just so you know.
<fwereade_> wrtp, cool, thanks
<fwereade_> TheMue, btw, I'm a bit concerned that the agent state branch overlaps uncomfortably with the presence-nodes work I was doing a couple of weeks ago
<TheMue> fwereade_: in which way?
<fwereade_> TheMue, AIUI the intent was to move away from using ephemeral nodes to signal presence and use presence nodes instead
<TheMue> fwereade_: didn't know that, sorry. so far i'm doing an almost 1:1 port of the py code.
<fwereade_> TheMue, I haven't looked too closely at everything in that branch yet so I'mnot sure how widespread the impact will be
<fwereade_> TheMue, hopefully it will at least make your code a bit smaller
<fwereade_> TheMue, but I think we've hit a bit of a communications snafu
<fwereade_> niemeyer, ^^
<TheMue> fwereade_: do you have something written about it, to help me understanding your idea?
<fwereade_> TheMue, the CL is here: https://codereview.appspot.com/5672067/
<fwereade_> TheMue, the description is a little terse but a quick scan of the inline docs should be helpful
<TheMue> fwereade_: will take a look
<fwereade_> TheMue, cheers
<wrtp> TheMue, fwereade_: i think you're right. it seems it was an unfortunate place to start... :-)
<niemeyer> fwereade_, TheMue: Agreed
<niemeyer> TheMue: Please check out the IRC logs
<wrtp> niemeyer: are there any logs of this channel?
<niemeyer> wrtp, TheMue: http://irclogs.ubuntu.com/2012/03/08/%23juju-dev.html
<wrtp> niemeyer: cool. which user is doing the logging?
<wrtp> we've got a meeting now, right?
<niemeyer> wrtp: ubuntulog2 sounds suspect
<wrtp> lol
<TheMue> niemeyer: thx, will do so, but scanning a lot of fluent and overlapping discussions is sometimes painful. don't we have a better way to discuss larger technical changes in a threaded way?
<wrtp> ah, logs have only been for the last two weeks
<fwereade_> niemeyer, btw, wrtp's gozk locking change is a bit of a heavyweight blocker: rog has one stacked behind it, I have one stacked behind each of those, and TheMue's agent work will likely want to change based on one of *those*
<niemeyer> TheMue: Sorry, but that's how the discussion took place.. fwereade_, rog and myself have been punching that idea for several days here in this channel
<TheMue> niemeyer: yes, it can't be changed for the past, no pro. but i'm looking for an idea for the future.
<wrtp> TheMue: your best bet is to look at fwereade_'s current proposal, i think
<TheMue> wrtp: as i already wrote i'll do this
<fwereade_> niemeyer, TheMue: I think we're at the point where we're only going to have more conflicts if we're not aware of exactly what we're working on
<niemeyer> TheMue: Even in the future, this channel will continue to be the best place to discuss ideas like that live
<fwereade_> TheMue, for example, I had some vague idea you were working on relation state
<wrtp> TheMue: and the comments on that proposal are moderately coherent, i think
<niemeyer> TheMue: Major features will have associated specs and whatnot
<niemeyer> TheMue: But this one, specifically, was developed very organically..
<TheMue> niemeyer: for a quick discussion irc is ok, but i'm missing a proper way to gather the conclusions out of thos multiple discussions in different time zones
<TheMue> fwereade_: i've got to wait with relations. we'll discuss it then.
<niemeyer> TheMue: Even better than gathering conclusions, in such an area that affects you directly, is paying attention to the channel and participating in it so that you're part of the team solidifying the idea
<niemeyer> TheMue: The conclusion, though, is available. fwereade_ has a branch, with a short and nice implementation of everything that was debated.
<niemeyer> TheMue: Please let us know what you think about it.
<TheMue> niemeyer: yep
<wrtp> hazmat, niemeyer, jimbaker, bcsaller, TheMue, fwereade_, niemeyer: are we doing a meeting, or defer it for a week?
<bcsaller> wrtp: I'm listening to the charm school webcast still
<jimbaker> wrtp, i'm good either way
<niemeyer> wrtp: I'm game to defer it, if no one has important needs to be discussed
<niemeyer> I'd rather focus on reviews..
<wrtp> niemeyer: sounds good to me :-)
<TheMue> wrtp: thx for review
<wrtp> TheMue: np
<niemeyer> fwereade_: I'll review the gozk locking now, then
<niemeyer> I wish Rietveld had a handy "Diff since my last comment" button
<niemeyer> wrtp: LGTM on safe-close
<niemeyer> fwereade_: ^
<fwereade_> niemeyer, sweet
<wrtp> niemeyer: i usually click on the comment, then adjust the view manually to show that revision and the latest one.
<wrtp> niemeyer: cool, thanks.
<niemeyer> wrtp: That's what I do as well.. still boring, though
<niemeyer> wrtp: Certainly better than anything else I used to do, OTOH
<wrtp> niemeyer: i was happy when i discovered that using the keyboard shortcuts keeps the revisions intact.
<wrtp> niemeyer: IMHO clicking "next" and "prev" should do too.
<niemeyer> wrtp: It does for me.. ?
<wrtp> niemeyer: hmm, it does for me too now. maybe it didn't work before. or more likely it's that crack again.
<niemeyer> :-)
 * wrtp got the tool to wire the RJ45 jacks today... goodbye flaky wireless connection!
<wrtp> (assuming i actually manage to use it properly.)
<niemeyer> wrtp: :-(
<niemeyer> wrtp: Welcome to my reality too..
<niemeyer> wrtp: I think the "attempt" stuff is obscuring the actual logic going on in these functions, for little practical benefit
<niemeyer> wrtp: I'd be curious to see a "for" versions that used a couple of constants.. I suspect it might be shorter, or of the same length at most
<niemeyer> wrtp: and will be a lot more readable
<niemeyer> wrtp: In the end, all of the logic around attempt is an abstraction for a for loop with a sleep, which somewhat of a trivial construct
<wrtp> niemeyer: i appreciate that point of view
<wrtp> niemeyer: but that logic in attempt.do is actually a little more complex than that (it's two for loops) and it's nice to have the policy centralised (for instance we might do exponential backoff or random delays)
<niemeyer> wrtp: We might make it more complex, but we might also not, if the simpler version tends to work.
<niemeyer> wrtp:
<niemeyer>  72 Â»       err := longAttempt.do(
<niemeyer>   73 Â»       Â»       func(err error) bool {
<niemeyer>   74 Â»       Â»       Â»       return err == noDNS || err == environs.ErrMissingInstanc
<niemeyer>      e
<niemeyer>   75 Â»       Â»       },
<niemeyer>   76 Â»       Â»       func() error {
<niemeyer> wrtp: This is completely unreadable by itself
<niemeyer> wrtp: I suspect the for version of this same function would be trivial
<wrtp> niemeyer: obviously i'm biased, but if it you read it as "while transient() {body}" then i think it's ok to read
<niemeyer> wrtp: Let me write the for version then..
<wrtp> niemeyer: that is the most complex example, of course.
<niemeyer> The Unity in precise right now is disturbingly broken.. :(
<wrtp> niemeyer: if we only need one loop then you're probably right. the two loop thing (one fast, for eventual consistency) and one slow (for other stuff) came out of discussion on this channel.
<fwereade_> goodnight all, see you tomorrow :)
<niemeyer> fwereade_: Have a good one!
<wrtp> fwereade_: nighty night
<wrtp> niemeyer: here's one example as a loop: http://paste.ubuntu.com/874880/
<TheMue> fwereade_: bye
<wrtp> niemeyer: or, a slightly alternative phrasing: http://paste.ubuntu.com/874882/
<wrtp> niemeyer: but both of those would make it hard to move to a less naive way of timing out.
<wrtp> actually, i have another idea
<niemeyer> wrtp: http://paste.ubuntu.com/874887/
<wrtp> niemeyer: there are two retrySleep constants, of course.
<niemeyer> wrtp: Why?
<wrtp> niemeyer: short and long.
<niemeyer> wrtp: Why?
<wrtp> niemeyer: short for pure eventual consistency issues
<wrtp> niemeyer: long for stuff that takes ages
<niemeyer> wrtp: Why do we need two constants, still?
<wrtp> niemeyer: the DNS stuff can take 2 or 3 minutes.
<wrtp> niemeyer: other stuff is good within 5 seconds
<niemeyer> wrtp: and it may also not..
<niemeyer> wrtp: I'd say let's have a single constant that feels enough a delay to not burn CPU/network to a noticeable level, and use it in both circumstances
<wrtp> niemeyer: well, neither might the DNS name be ready in 3 minutes. we've got to choose a limit somewhere
<andrewsmedina> niemeyer: hi
<niemeyer> andrewsmedina: Hi
<wrtp> niemeyer: the problem is sometimes we *expect* an error. and we don't want to time out the whole three minutes when 5 seconds is enough.
<niemeyer> wrtp: Sure, let's use 5 seconds for both then
<niemeyer> wrtp: In computational time, 5 seconds is an eternity
<wrtp> niemeyer: we can't. then users of the ec2 environ need to know about the constants themselves.
<wrtp> [17:53] <wrtp> niemeyer: the DNS stuff can take 2 or 3 minutes.
<niemeyer> wrtp: Huh?
<niemeyer> <niemeyer> wrtp: and it may also not..
<niemeyer> <niemeyer> wrtp: I'd say let's have a single constant that feels enough a delay to not burn CPU/network to a noticeable level, and use it in both circumstances
<wrtp> niemeyer: yeah, but it *always* takes more than a minute
<niemeyer> wrtp: Not necessarily..
<wrtp> niemeyer: whereas the other stuff *always* takes less than 5 seconds
<niemeyer> wrtp: Please complete the sentence: "Using 5 seconds for both will be *really* bad because ..."
<wrtp> niemeyer: ... because we'll always return an error for the DNS name when booting up and trying to connect.
<niemeyer> wrtp: Why?
<wrtp> niemeyer: because the DNS name takes longer than 5 seconds to be set.
<niemeyer> wrtp: This is the *sleep*, not the limit
<wrtp> niemeyer: i'm sure i discussed this with you before.
<wrtp> niemeyer: oh, sorry, i was talking about the limit
<wrtp> niemeyer: (which is the important thing IMHO)
<wrtp> ah, i see now
<wrtp> i mentioned retrySleep
<niemeyer> Right
<wrtp> the same applies to retryCount.
<niemeyer> wrtp: The same doesn't apply to retrySleep, though
<niemeyer> :-)
<wrtp> niemeyer: 5s is too long for the short wait, i think
<wrtp> niemeyer: currently i'm using 200ms
<wrtp> niemeyer: and usually it's good on the second attempt
<niemeyer> wrtp: Sounds good then.. we can have retryShortLimit and retryLongLimit
<niemeyer> wrtp: and the same for retrySleep if needed
<niemeyer> wrtp: It's still two constants in a for
<niemeyer> All of that amounts to the following four lines:
<niemeyer> 	for i := 0; i < retryLimit; i++ {
<niemeyer> 		if i > 0 {
<niemeyer> 			
<niemeyer> Hmm.. copy & paste broken
<niemeyer> Again:
<niemeyer> 	for i := 0; i < retryLimit; i++ {
<niemeyer> 		if i > 0 {
<niemeyer> 			time.Sleep(retrySleep)
<niemeyer> 		}
<wrtp> niemeyer: i still like the idea of centralising the policy somewhere. i have an idea, one mo.
<niemeyer> This is "attempt"
<niemeyer> wrtp: The policy is centralized.. retryLimit and retrySleep are central
<niemeyer> wrtp: The overhead of reinventing for and if in those 4 lines is not really buying us anything, and is making the logic unreadable
<wrtp> niemeyer: as i said, i have an idea that you *might* like.
 * wrtp is just putting a paste together
<wrtp> niemeyer: how does this look to you for usage: http://paste.ubuntu.com/874912/
<wrtp> niemeyer: (this is the implementation: http://paste.ubuntu.com/874913/)
<wrtp> not compiled or tested, of course
<niemeyer> wrtp: That might work, but I suggest a small tweak as:
<niemeyer> wrtp: l := retryLoop(delay); for l.next() {
<niemeyer> wrtp: Well, I guess you still two variables.. l := retryLong() and l := retryShort() then
<niemeyer> still need
<niemeyer> wrtp: and have the loop as "for l.next() {".. resembles vaguely the use in the sql package
<wrtp> niemeyer: actually, i started off by calling next, but thought you'd prefer waitNext :-)
<wrtp> s/calling/calling it/
<niemeyer> wrtp: it's rows.Next() in database/sql, and it's iter.Next(&foo) in mgo, so we have some precedents there
<niemeyer> wrtp: +1 on the approach, either way.. much better
<wrtp> niemeyer: agreed. i thought it was perhaps different because it slept. i like next though.
<wrtp> niemeyer: cool.
<wrtp> niemeyer: are you ok with the names i chose?
<wrtp> (attempt, start and next, in particular)
<wrtp> i think they work quite well
<niemeyer> wrtp: I'd prefer retry rather than attempt, since it makes more obvious that the goal is to try again while attempt does not
<niemeyer> wrtp: But this is minor.. won't fight over it if you have a strong preference for attempt
<wrtp> the idea behind "attempt" is that this all makes up one larger attempt to do something, although we try several times.
<wrtp> "retry" could work too though. i'll try both and see how they look.
<niemeyer> wrtp: Cheers
<wrtp> niemeyer: i think the difficulty i have with "retry" is that to me it implies a single try, whereas "attempt" hints at more sustained activity.
<niemeyer> wrtp: You can retry 100 times too
<niemeyer> wrtp: no connotation of singularity there
<wrtp> niemeyer: indeed, but i want the name of the type to imply the whole thing, rather than one part of it.
<niemeyer> wrtp: Please name as you please :)
<wrtp> thanks
<niemeyer> hazmat: wtf was hung on bzr pull somehow.
<wrtp> niemeyer: here's what DNSName now looks like BTW. (untested) http://paste.ubuntu.com/874994/
<wrtp> definite improvement from my previous version, i think. thanks for pushing me in this direction.
<niemeyer> wrtp: Much better indeed, thanks!
<niemeyer> wrtp: noDNS can die, btw
<wrtp> niemeyer: it's gone already
<niemeyer> wrtp: Cool, it was in the paste
<wrtp> niemeyer: yeah, i noticed it just afterwards
<wrtp> niemeyer: wouldn't've got through the compiler anyway
<wrtp> 80 lines of test code disappear, mmmm
<niemeyer> wrtp: 8)
<wrtp> niemeyer: hmm, goyaml seems to have broken
<niemeyer> wrtp: How so? charmstore depends on it, and apparently it compiled a few hours ago fine
<wrtp> niemeyer: i'll try updating
<niemeyer> wrtp: What's the error you got?
<wrtp> niemeyer: it's not unmarshalling correctly
<niemeyer> wrtp: Uh oh
<wrtp> niemeyer: http://paste.ubuntu.com/875062/
<wrtp> niemeyer: lots of contents lost
<wrtp> niemeyer: seems like it's true of the latest revision (33) too.
<wrtp> niemeyer: i'll push go-ec2-robustness anyway, as this seems like an unrelated bug.
<niemeyer> wrtp: This doesn't even look like valid yaml
<niemeyer> wrtp: I'm surprised it doesn't return an error
<wrtp> niemeyer: oh. it was produced as output from goyaml itself
<wrtp> niemeyer: what's the problem with it?
<niemeyer> wrtp: Wait, my copy & paste is what's broken (at least)
<wrtp> :-)
<wrtp> sheesh, indentation-based nesting
<niemeyer> wrtp: Broken indeed.. checking it out
<wrtp>  niemeyer: yeah, goyaml doesn't pass its tests
<niemeyer> wrtp, rogpeppe: goyaml was unintendedly exploring the mutability of interfaces
<niemeyer> Broke up after Russ fixed the bug
<rogpeppe> niemeyer: interesting
<rogpeppe> niemeyer: easy to fix?
<niemeyer> robbiew: Yeah
<niemeyer> Argh
<niemeyer> rog: Yeah
<robbiew> lol
 * robbiew was confused at first
<rog> niemeyer: cool.
<rog> nie
<niemeyer> wrtp: Still facing network issues?
<niemeyer> rogpeppe: https://codereview.appspot.com/5784060
<rogpeppe> niemeyer: LGTM
<fwereade_> niemeyer, ignore my PTAL of a few minutes ago, nothing you mentioned has been addressed (I came back to the machine to see a half-complete propose from fixing rog's previous and merging trunk)
<niemeyer> fwereade_: Ah, no worries
<niemeyer> rogpeppe: Cheers, submitting
<niemeyer> Quite surprising how much goyaml has resisted without changing, given how much everything else broke in the Go 1 rush
<rogpeppe> niemeyer: have you done the goyaml tagging?
<niemeyer> rogpeppe: Just doing it
<rogpeppe> niemeyer: BTW before you LGTM it, i think the lxc environ should keep the Container type private. i've been meaning to review that branch for a bit.
<niemeyer> rogpeppe: Done
<niemeyer> rogpeppe: Hmm, not sure I see why.. seems like a thin wrapper on the lxc command line
<rogpeppe> niemeyer: isn't the point of the package to implement an environs.Environ?
<rogpeppe> niemeyer: Container is just an implementation detail, i think
<niemeyer> rogpeppe: No, that's go/lxc
<niemeyer> rogpeppe: What you have in mind is go/environs/lxc
<niemeyer> Not even that, actually
<niemeyer> rogpeppe: it's go/environs/local
<niemeyer> lxc is a thing wrapper for management of lxc, independent from juju
<rogpeppe> niemeyer: oh. i think i misundersood originally. the current package path being reviewed is environs/lxc
<rogpeppe> niemeyer: (and given how small it is, i'm not sure if it needs its own package)
<niemeyer> rogpeppe: Ok, that's the problem then
<niemeyer> rogpeppe: Maybe..
<niemeyer> rogpeppe: My plan was actually to move that out onto its own package
<niemeyer> rogpeppe: That said, you're right..
<rogpeppe> niemeyer: depends how much more of it there is to come, i guess, but the code to run the lxc commands is less than that to call the ec2 functions...
<niemeyer> rogpeppe: We can keep that internal for the moment, and then make it public when/if we ever move it out
<rogpeppe> niemeyer: that seems good to me
<niemeyer> rogpeppe: goamz is its own package ;)
<rogpeppe> niemeyer: i meant to call the goamz/ec2 functions...
<niemeyer> rogpeppe: goamz/ec2 is its own package too.. the point is that there's an external wrapper that handles the bits that do not depend on juju
<niemeyer> rogpeppe: You're right that what we have there is small, though
<niemeyer> rogpeppe: So we can keep it internal for the moment
<rogpeppe> niemeyer: sure. but in the goamz/ec2 case it's doing real work. here it's almost trivial.
<rogpeppe> yeah
<rogpeppe> well, if it gets bigger, i'd be happy to factor it out
<niemeyer> rogpeppe: Can you please make the point in the review so that andrewsmedina can address it before we merge?
<rogpeppe> niemeyer: ok, i'm about to go to bed, but i'll write a brief reply.
<andrewsmedina> niemeyer: hi
<niemeyer> andrewsmedina: Heya
<niemeyer> andrewsmedina: You got a review
<andrewsmedina> niemeyer: yes
<andrewsmedina> niemeyer: 2 reviews
<niemeyer> andrewsmedina: and rog was just suggesting the Container type stay as "container" for the moment
<andrewsmedina> niemeyer: one for initial work with lxc in juju
<andrewsmedina> niemeyer: and another in goetveld https://codereview.appspot.com/5683064/
<andrewsmedina> niemeyer: I just read your review
<niemeyer> andrewsmedina: This goetveld branch has been submitted two weeks ago.. ?
<niemeyer> andrewsmedina: Maybe I'm just missing the tag
<andrewsmedina> niemeyer: I can skip the tests if sudo isn't acessible
<niemeyer> andrewsmedina: That's what was suggested there
<andrewsmedina> niemeyer: I've updated the old review in goetveld
<niemeyer> andrewsmedina: But skip it at all times please, unless -lxc is provided
<niemeyer> andrewsmedina: Updated the old review!?
<andrewsmedina> niemeyer: I got issues to memorize the "goetveld" name
<niemeyer> andrewsmedina: This branch and CL in Rietveld have been submitted, which means they are effectively dead now
<niemeyer> andrewsmedina: If you have more changes, they must be proposed in a different branch/CL
<andrewsmedina> niemeyer: I will create another branch then
<rogpeppe> andrewsmedina: you've got another review
<niemeyer> andrewsmedina: Thanks!
<andrewsmedina> rogpeppe: thanks
<rogpeppe> off to bed now. 'night all.
<andrewsmedina> I'm very happy to contribute with juju and others projects in go
<andrewsmedina> rogpeppe: night
<rogpeppe> andrewsmedina: it's much appreciated!
<fwereade_> niemeyer, https://codereview.appspot.com/5672067 may actually be done now :)
<niemeyer> fwereade_: Cheers :)
<niemeyer> fwereade_: I may only get to it in the morning as well, though
<niemeyer> It's getting late here
#juju-dev 2012-03-09
<niemeyer> fwereade: Morning
<fwereade> heya niemeyer
<niemeyer> rogpeppe: Morning
<rogpeppe> niemeyer: hiya, up early...
<niemeyer> rogpeppe: Yeah, lost sleep and decided to push some pending tasks forward
<rogpeppe> niemeyer: i've been up about 2 hours myself, but went for a nice long bike ride.
<niemeyer> rogpeppe: Oh, that sounds very nice
<niemeyer> rogpeppe: Haven't been biking in a long while
<niemeyer> rogpeppe: I'm a one-sport man.. squash took over.. ;-)
<rogpeppe> niemeyer: i've been going out in the mornings 'cos i realised that moving from bedroom to desk wasn't getting me much exercise!
<niemeyer> rogpeppe: Nice that you've handled that quickly.. indeed it's an amazing recipe for couch potatoing :)
<rogpeppe> niemeyer: rock climbing was always my big thing, but it's harder to get out these days...
<rogpeppe> been going out on the bike most days for 2 weeks now, and i haven't repeated a route once...
<niemeyer> Wow
<niemeyer> rogpeppe: Just submitted a review for the robustness branch
<niemeyer> Will step out to have coffee with Ale
<niemeyer> Back soonish
<rogpeppe> niemeyer: thanks
<fwereade> popping out for a coffee myself, might kickstart my brain
 * niemeyer returns
<niemeyer> TheMue: Morning
<TheMue> niemeyer: morning, back again
<fwereade> TheMue, btw, you mentioned a blocker on relation state; do you have a mo to fill me in on that?
<TheMue> fwereade: niemeyer told me that there are some open discussions and i should defer it and continue with other open parts meanwhile
<fwereade> TheMue, ah yeah, cool, that makes sense
<niemeyer> fwereade: Subordinates are on going in Python.. I suggested waiting for that so that the implementation may be done once
<TheMue> fwereade: right now i'm going through presence package. should be difficult to switch my agent code to use it.
<fwereade> TheMue, should be? :(
<TheMue> fwereade: oh, sorry, typo
<fwereade> TheMue, phew :)
<TheMue> fwereade: ahoulsn't ;)
<fwereade> TheMue, now *that's* a typo :p
<TheMue> fwereade: hehe
<fwereade> TheMue, what's next on your roadmap?
<fwereade> TheMue, just want to make sure we don't collide again ;)
<TheMue> fwereade: no, indeed, your package looks good. maybe an integration of tomb for save goroutine handling would make sense
<fwereade> TheMue, the intent was to have as much as possible the same semantics as normal ZK watches
<TheMue> fwereade: i've got three reviews in the pipe, one is the agent proposal. once that one is ready for integration i would extend the entities i already have and which shall have agents with it
<TheMue> fwereade: beside that i've got to compare what's still open in state
<fwereade> TheMue, cool; I'm looking into hook execution so I don't think we'll cause each other too much trouble ;)
<TheMue> fwereade: i'll post here what i'll start next
<TheMue> fwereade: did you took a look into my agent code?
<fwereade> TheMue, one thing I noticed is that we don't seem to have state.Unit.OpenPort yet
<fwereade> TheMue, I started; I have a couple of draft comments, I'll try to get them finished for you now
<TheMue> fwereade: OpenPort() is one of the proposals
<fwereade> TheMue, oh, fantastic, sorry I missed that one
<TheMue> fwereade: the code is submitted for review
<fwereade> TheMue, I'll take another look at +activereviews
<fwereade> TheMue, hasn't go-state-continued-machine been merged already?
<fwereade> TheMue, and go-state-gocheck-change too?
<TheMue> fwereade: all they are missing an LGTM
<TheMue> fwereade: the latter is also needless, it's also part of the others. rog and i thought it had to be done earlier, so i made an extra branch. but the changes have been so few that another brach already had them
<fwereade> TheMue, ah cool, maybe reject that one then?
<TheMue> fwereade: how to do that?
<fwereade> TheMue, go to the LP merge proposal and click the status field at the top
<TheMue> fwereade: important are the two go-state-continued-â¦ and the go-state-first-agent-draft
<fwereade> TheMue, cool, I'll get up to date on those then
<fwereade> TheMue, thanks
<TheMue> fwereade: hmm, i'm somehow lost and don't find the mentioned status field at the top
<fwereade> TheMue, it's currently an orange "needs review"
<TheMue> fwereade: ah, have not gone far enough in lp
<fwereade> TheMue, ah sorry you were looking at the branch?
<TheMue> fwereade: yep, i still have my troubles with the usability of lp
<fwereade> TheMue, haha, LP seemed like sweetness and light to me after the rubbish we were using at my last place
<fwereade> TheMue, the tool was *worse* than doing bug/iteration tracking with google docs spreadsheets
<TheMue> fwereade: i've worked with JIRA. it's not as powerful as LP, but the UI is more clear
<TheMue> fwereade: uh, sounds horrible
<fwereade> TheMue, (I know that to be true because that was what we were using before)
 * fwereade cries quietly in a corner
 * TheMue dcc's fwereade a tissue
<fwereade> :)
<TheMue> fwereade: so, it's rejected but still with status "Development". can i now change this to "Abandoned"?
<fwereade> TheMue, sounds good to me (I usually forget to do that myself)
<TheMue> fwereade: ok, i like a clean workplace ;)
<TheMue> niemeyer: oh, i just rejected go-state-gocheck-change after discussion with fwereade, those changes have already been in a former branch and are merged into state
<TheMue> niemeyer: this overlapped, sorry
<fwereade> TheMue, review on https://codereview.appspot.com/5690051/
<TheMue> fwereade: thx, take a look
<niemeyer> TheMue: That's cool, no worries
<TheMue> fwereade: in your review you say that in todays code the only caller of RemoveMachine() care's if it doisn't exist?
<fwereade> TheMue, seems so to me
<TheMue> fwereade: do you know the reason behind it? from states perspective it's ok if there's nothing to remove.
<TheMue> fwereade: but state has online a very limited view.
<fwereade> TheMue, tbh I'd be just as happy if it silently ignored nonexistent machines
<fwereade> TheMue, it's just the mismatch between the state's view of what's acceptable and the single client's view
<fwereade> TheMue, I'd rather just return an error than return a value (false) that's always turned into an error
<TheMue> fwereade: hmm, it's just todays code only ported to go
<TheMue> fwereade: should ask niemeyer
<fwereade> TheMue, understood; and there may be reasons for it that I've missed; but I'm not sure that we should feel too bound by python implementation details
<TheMue> fwereade: if i got it right we first shall catch the current status and later optimize it for go
<fwereade> TheMue, my view is that that particular implementation detail is either a misprediction of future needs, or an appendix left over after the removal of some pre-existing need
<TheMue> fwereade: maybe, you are more safe than me i the existing code.
<fwereade> TheMue, that hadn't been my perception -- while we should maintain externally observable characteristics wherever possible, I'd prefer to strip ickiness where possible
<fwereade> TheMue, for example, presence nodes vs ephemeral nodes
<fwereade> niemeyer, opinion?
<niemeyer> fwereade++
<niemeyer> TheMue: If the only use of this method actually does what fwereade suggests, turning around and saying "Hah! Actually, that's an error!", then it feels like the API was mispredicted when first written
<niemeyer> I didn't even know that was the case, FWIW
<TheMue> niemeyer: yep, i do code scans to see where a meth/func is used to se how it is intended when it's unclear to me
<TheMue> niemeyer: in this particular case i felt no need so i ported it 1:1
<TheMue> niemeyer: maybe scanning for each func is useful
<rogpeppe> niemeyer: wanna talk about DNS name timeouts?
<niemeyer> TheMue: It may be hard in some cases without further context
<niemeyer> TheMue: Reviews help with that too
<niemeyer> rogpeppe: Sure
<TheMue> niemeyer: definitely
<rogpeppe> niemeyer: i don't quite understand this: "
<rogpeppe> There's an application running somewhere, we shutdown a
<rogpeppe> machine, and then that app hangs for 3 minutes just because it asked for a DNS
<rogpeppe> address?
<rogpeppe> "
<rogpeppe> niemeyer: what's the "application" in this context?
<niemeyer> rogpeppe: A binary
<niemeyer> rogpeppe: Any binary that links against this library of code
<rogpeppe> niemeyer: ok.
<fwereade> TheMue, reviewed https://codereview.appspot.com/5727045/
<rogpeppe> niemeyer: i think there are two scenarios
<rogpeppe> niemeyer: one is when you really need the address
<rogpeppe> niemeyer: the other you don't care too much
<TheMue> fwereade: already seen an interesting comment regarding retryTopologyChange()
<rogpeppe> niemeyer: for instance, when we ask for the DNS address of the bootstrap machine, we really need it
<rogpeppe> niemeyer: but, as you point out, in StateInfo we don't care too much
<rogpeppe> niemeyer: i'm wondering about a "wait as long as necessary" bool flag on Environ.DNSName
<rogpeppe> niemeyer: i'm trying to resist forcing clients of Environ to do their own polling.
<rogpeppe> niemeyer: because i think the strategy might be quite different for different providers.
<rogpeppe> niemeyer: (some providers will always have a DNS name instantly available, for example)
<niemeyer> rogpeppe: Hmm
<niemeyer> rogpeppe: I don't think so, to be honest
<niemeyer> rogpeppe: The case where you say "give me a machine" to an IaaS and you have an address immediately may not be so common
<niemeyer> rogpeppe: I'm happy to experiment with a waiting API, but let's please keep an eye on this rather than taking it as a general approach from now on
<niemeyer> rogpeppe: I suggest we introduce WaitDNSName() returning (addr, error)
<rogpeppe> niemeyer: immediately, perhaps not. but a 3 minute wait? many DHCP clients give an address in < 1s
<fwereade> TheMue, I definitely don't think that's something to be addressed in this branch
<niemeyer> rogpeppe: And keep DNSName() returning the already known address only
<rogpeppe> niemeyer: i'm wondering if it should be the other way around.
<fwereade> TheMue, but State "feels" like the right place for it to me
<niemeyer> rogpeppe: The three minute wait is completely unrelated to DHCP
<rogpeppe> niemeyer: DNSNameNoWait
<rogpeppe> so DNSName always gives you a valid DNS name if it can
<niemeyer> rogpeppe: This is waiting for a machine to be booted
<niemeyer> rogpeppe: Which is why it's wrong to be holding on DNSName specifically
<rogpeppe> niemeyer: why can't the DNS name be allocated before the machine boots?
<niemeyer> rogpeppe: The machine is off.. the DNS name isn't special
<rogpeppe> niemeyer: doesn't the infrastructure allocate the DNS name?
<niemeyer> rogpeppe: It's not under our control why people do this or not
<rogpeppe> niemeyer: not the machine itself?
<niemeyer> rogpeppe: The fact is that the most well known IaaS doesn't do that
<rogpeppe> niemeyer: ok. seems a bit weird to me, but i'm sure there's a good reason.
<niemeyer> rogpeppe: Likely because they're still working out where to allocate the machine by the time it's answered
<niemeyer> rogpeppe: But, again, there's no point for us
<TheMue> fwereade: will comment your review, most of it sounds got. the one with the goto had a problem with a break, but i've got to look again which kind it was
<rogpeppe> niemeyer: anyway, i'd prefer the default to be to wait, if that's ok.
<niemeyer> rogpeppe: WaitDNSName please.. this is the special case that will yield misbehaving code if we forget that it can take *several minutes* to return
<niemeyer> rogpeppe: and let's have DNSName() returning (attr, error) too, so that it's clear that we may not have a DNS address at that time
<niemeyer> Erm, (addr, error)
<rogpeppe> niemeyer: it does that currently
<niemeyer> rogpeppe: It didn't do before your branch, and I'm suggesting both WaitDNSName and DNSName do that
<niemeyer> rogpeppe: If that's what you had in mind already, great.. :)
<rogpeppe> niemeyer: sure, that's unavoidable
<niemeyer> rogpeppe: It's not unavoidable.. what we have in trunk today is not like that
<rogpeppe> niemeyer: that's because it doesn't work :-)
<niemeyer> Heh
<fwereade> TheMue, cool, thanks; https://codereview.appspot.com/5782053/ reviewed as well
<rogpeppe> "
<rogpeppe> This logic is error prone. When we get ErrMissingInstance, we'll have to
<rogpeppe> *always* check len(insts) to see if it's 0 or not before iterating
<rogpeppe> "
<rogpeppe> niemeyer: the logic was deliberate
<niemeyer> rogpeppe: Cool, let's fix it then
<rogpeppe> niemeyer: it means that if you've asked for some instances, you can easily check (len != 0) if at least some instances have been returned
<niemeyer> rogpeppe: That's error prone, as described
<rogpeppe> niemeyer: if you're iterating, you don't need to check len(insts) for 0
<rogpeppe> niemeyer: because the iteration will never go anywhere
<niemeyer> insts, err := e.Instances([]ec2.Instance{a, b, c})
<niemeyer> if err == ec2.ErrMissingInstance && len(insts) != 0 && insts[0] == nil { ... }
<niemeyer> rogpeppe: Please don't force me to remember to do that every time
<rogpeppe> niemeyer: most of the time you just check the error, in which case it doesn't matter. the other way around (and probably the more common one) is that if you ask for some instances and get some, but not all of them, you have to scan the list to see if you've got any.
<rogpeppe> niemeyer: whereas the way it is currently, you can just check the length - you'll never return a slice with no non-nil instances in.
<rogpeppe> niemeyer: i started off always returning a slice, but changed it because it was easier to use this way
<rogpeppe> s/you'll never return a slice/you'll never get a slice/
<niemeyer> rogpeppe: Easy and error prone.. there are two different cases to handle
<niemeyer> rogpeppe: and we have to remember them when using this method to avoid a panic
<niemeyer> rogpeppe: Please, either return the slice at all times, or let's have two different error types
<niemeyer> rogpeppe: No gotchas
<rogpeppe> niemeyer: ok, i'll do two error types.
<niemeyer> rogpeppe: Thanks
<rogpeppe> niemeyer:
<rogpeppe> 	// Instances returns a slice of instances corresponding to the
<rogpeppe> 	// given instance ids.  If no instances were found, but there
<rogpeppe> 	// was no other error, it will return ErrInstanceNotFound.  If
<rogpeppe> 	// some but not all the instances were found, the returned slice
<rogpeppe> 	// will have some nil slots, and an ErrInstancesIncomplete error
<rogpeppe> 	// will be returned.
<rogpeppe> 	Instances(ids []string) ([]Instance, error)
<niemeyer> rogpeppe: Looks good, thanks. Just plural for ErrInstancesNotFound too, please
<rogpeppe> niemeyer: oh yeah, that was a typo - the actual error was spelled that way in fact.
<niemeyer> rogpeppe: Sweet.. "Partial" might also be a shorter term for Incomplete
<niemeyer> rogpeppe: Up to you, though
<rogpeppe> niemeyer: ErrInstancesPartial doesn't sound great, and neither does ErrNotFoundInstances IMHO.
<rogpeppe> niemeyer: but ErrInstancesNotFound and ErrPartialInstances seem inconsistent
<niemeyer> rogpeppe: PartialInstances + NoInstances?
<rogpeppe> +1
<niemeyer> Super, thanks
<TheMue> lunchtime
<rogpeppe> niemeyer: i'm slightly concerned about doing this: "
<rogpeppe> It should wait, but stop on the first batch that has
<rogpeppe> at least one valid DNSName.
<rogpeppe> "
<rogpeppe> (of StateInfo)
<rogpeppe> it means that if we call StateInfo when, say, only one zk instance has been allocated, and that instance later goes down, we won't have the redundancy that we should.
<niemeyer> rogpeppe: I don't understand.. if the only instance that was allocated goes down, there's no redundancy
<rogpeppe> niemeyer: sorry, i was ambiguous
<rogpeppe> niemeyer: when i said "only one zk instance has been allocated" i meant "the DNS name of only one of several zk instances has been allocated".
<niemeyer> rogpeppe: The scenario is this: we have three intances, one is terminated for whatever reason.. it shouldn't wait for 3 minutes when it knows about other instances.
<rogpeppe> niemeyer: i don't think that scenario would make it wait
<rogpeppe> niemeyer: the scenario i'm concerned about is: we start 3 instances. the DNS name for only one of them is used, because it boots fractionally faster than the others.
<niemeyer> rogpeppe: I don't see how it would not wait.. you're picking the first entry in the list and calling DNSName on it.. with the logic in the branch, it will wait for as long as it takes for that one machine to have an address, no matter how many machines are there.
<niemeyer> rogpeppe: Is this the DNSName catching you already? :-)
<rogpeppe> niemeyer: so we get *one* machine from the three possible zk machines. then that zk machine goes down. if we'd waited for the names of the others, the zk client could redial one of them, but as it is, it can't because it doesn't know about them
<niemeyer> rogpeppe: I don't see what you mean..
<niemeyer> for i, inst := range insts {
<niemeyer>     addr, err := inst.DNSName()
<niemeyer> *BOOM*.. three minutes..
<niemeyer> That can't happen..
<rogpeppe> niemeyer: ok, so you're suggesting we wait for them all in parallel, presumably, and then return the first one that has a DNS name?
<rogpeppe> niemeyer: (assuming none of them have DNS names to start with)
<niemeyer> rogpeppe: I'm saying that the problem above can't happen, so far.
<rogpeppe> niemeyer: because we only have one zk server, right?
<niemeyer> rogpeppe: If you understand the problem, we can talk about a solution
<rogpeppe> i'm not sure i do understand the problem. is it that we might be launching one zk machine much later than the others?
<rogpeppe> so we don't want to wait for that while the others are available anyway?
<rogpeppe> niemeyer: we've got to wait for at least one DNS name, right?
<niemeyer> rogpeppe: Yes..
<niemeyer> rogpeppe: You have N machines.. waiting for several minutes for a random one to be alive == BAD
<rogpeppe> niemeyer: so we don't mind if the zk client doesn't know about the other zk servers?
<niemeyer> rogpeppe: I don't know what you're talking about
<niemeyer> rogpeppe: I'm saying that if we know about N machines, waiting for several minutes for a single arbitrary machine == REALLY BAD
<rogpeppe> it's not waiting for a single arbitrary machine, it's waiting for all of the zk machines.
<niemeyer> rogpeppe: Yes.. that's equally bad
<niemeyer> rogpeppe: It's pointless to have three machines for redundancy if the application waits for several minutes for all of them to be available
<rogpeppe> niemeyer: the problem is that there's no way of telling the zk client when another zk machine *does* become available
<rogpeppe> niemeyer: which means that if the only machine that we found does go down, we haven't got any redundancy any more.
<niemeyer> rogpeppe: That's a completely independent problem
<rogpeppe> oh?
<niemeyer> rogpeppe: Yep.. dynamic member sets is a different problem
<niemeyer> rogpeppe: We can't hold on forever waiting for everybody to be available or the redundancy is over
<rogpeppe> niemeyer: it's not a dynamic member set though - we know we've started 3 zk machines, we just want to wait for them to be up
<niemeyer> rogpeppe: A single machine terminated would kill juju
<niemeyer> rogpeppe: If a single one of them terminates, it will never be up
<rogpeppe> niemeyer: we're not waiting for the *machine* to be available, we're waiting for its DNS name. isn't that different?
<rogpeppe> niemeyer: the DNS name is still available if a machine is terminated, i think.
<niemeyer> rogpeppe: If a machine is terminated the entire instance record will go away in a bit
<rogpeppe> niemeyer: that takes hours. and we can guard against that easily too.
<rogpeppe> niemeyer: by only doing a short timeout when calling Instances in WaitDNSName
<niemeyer> rogpeppe: I'm sure there are many workarounds for the problem. I was just describing it, and wishing that we didn't introduce it
<rogpeppe> niemeyer: i think we *should* wait for all the zk addresses. but i think we shouldn't do a 3 minute timeout if the instances aren't there.
<niemeyer> rogpeppe: The Instances call above is equally problematic, btw.. it's aborting if any of the instances are not found
<niemeyer> rogpeppe: Uh oh.. :(
<rogpeppe> niemeyer: good point. that *is* a bug.
<niemeyer> rogpeppe: Man.. the issue is trivial: if a machine in a set of three never starts, we can't block *all of juju* because of that..
<niemeyer> rogpeppe: Same thing if it terminates
<niemeyer> rogpeppe: It simply makes no sense to have multiple machines if that's what we're doing
<rogpeppe> niemeyer: terminating isn't a problem.
<niemeyer> rogpeppe: The logic in your branch breaks if one terminates.
<niemeyer> rogpeppe: That is a problem.
<niemeyer> rogpeppe: Let's please fix that.
<rogpeppe> niemeyer: agreed. but that's a different problem.
<rogpeppe> niemeyer: that doesn't mean we shouldn't try to wait for all the DNS names while the instances are still around.
<rogpeppe> niemeyer: (and running)
<niemeyer> rogpeppe: The logic in your branch breaks if a machine never gets allocated.
<niemeyer> rogpeppe: This is a bug. Let's fix it.
<rogpeppe> niemeyer: yes, i've agreed about that.
<niemeyer> rogpeppe: No, you just said otherwise.
<niemeyer> <rogpeppe> niemeyer: that doesn't mean we shouldn't try to wait for all the DNS names while the instances are still around.
<rogpeppe> niemeyer: if a machine never gets allocated, the instance won't be around
<rogpeppe> niemeyer: so we won't wait for its DNS name
<niemeyer> rogpeppe: It will stay in "pending" mode..
<niemeyer> rogpeppe: What happens then?
<rogpeppe> niemeyer: so a machine can stay in pending mode forever?
<niemeyer> rogpeppe: Bad things happen.. machines go from pending to terminated.. stay in pending for a very long time, etc
<rogpeppe> niemeyer: if that's so, i agree it's an issue. but...
<rogpeppe> niemeyer: if we go the other way, even if we have 3 zk instances, all the initial agents will only ever talk to one of them.
<niemeyer> rogpeppe: The logic you're introducing is trying to handle the unfriendliness of EC2.. we must not go overboard with it. Having an application that hangs for several minutes in edge cases is not nice.
<rogpeppe> niemeyer: so if that one goes down, the initial agents are stuffed
<niemeyer> rogpeppe: If there are known machines in a set of zk instances, let's not block waiting forever we *know* about *good working machines*
<rogpeppe> niemeyer: ... which means we'll stop when we have exactly *one* machine, right?
<niemeyer> rogpeppe: That's fine!  If we have to reconnect, well.. we have to reconnect!
<niemeyer> rogpeppe: Purposefully introducing a resilience bug to fix resilience is.. hmm.. interesting.
<rogpeppe> niemeyer: ok, so it's important for the state client to know that it should always re-get the StateInfo when it reconnects, right?
<rogpeppe> actually, no this won't work
<niemeyer> rogpeppe: I don't know.. but whatever we do, there's a bug locallly, in that small subworld we're handling.
<rogpeppe> because the zk client carries on redialling the set of known machines regardless of whether they're up or down
<niemeyer> rogpeppe: Up to us.. we get the disconnection events, and as far as I understood, our approach was going to be reestablishing the connection.
<rogpeppe> niemeyer: we don't get the disconnection events AFAIK
<niemeyer> rogpeppe: ZooKeeper notifies about disconnections.
<rogpeppe> ah, maybe it's just the initial connection attempt that goes on forever
<niemeyer> rogpeppe: and our last agreement was that we were going to handle any connection issues as fatal.
<niemeyer> rogpeppe: We might even be smarter at some point, and wait for longer if we knew that we had *just* bootstrapped
<niemeyer> rogpeppe: Having that as a general rule over the lifetime of the environment is not reasonable, though
<niemeyer> rogpeppe: ZooKeeper certainly tries to reestablish the connection.. that's not the same as not having notification of disconnections.
<rogpeppe> niemeyer: yeah, given that it makes no difference if we pass 1 or 3 addresses to the zk client, there's no point in waiting for more than one.
<niemeyer> rogpeppe: Arguably, we're doing more work on our side, but as far as I could perceive so far, that sounds like a good idea anyway
<niemeyer> rogpeppe: Trusting on the internals of zk to achieve long term reliability hasn't been fruitful
<rogpeppe> niemeyer: yeah. and it makes it easier to move to something else if we want to, perhaps.
<niemeyer> rogpeppe: I guess we do have the instance start time, right?
 * rogpeppe goes to have a look
<niemeyer> rogpeppe: I'd be happy to wait in that loop as you suggest if we take that into consideration
<rogpeppe> niemeyer: yeah, there's LaunchTime although it's not in goamz/ec2 yet
<niemeyer> rogpeppe: Maybe let's just keep simple then, and return the first good set of machines we have
<rogpeppe> niemeyer: i'll wait in parallel and return the first address we get. that's easiest i think.
<rogpeppe> niemeyer: i could wait for a short time after the first one, in case there are several arrive together.
<niemeyer> rogpeppe: I don't think it needs to be parallel
<rogpeppe> niemeyer: oh, just poll DNSName on all of them?
<niemeyer> rogpeppe: Put Instances itself in a loop.. once we have a batch with good DNSNames, return all of the ones that have an address assigned
<niemeyer> rogpeppe: Instinctively, I believe there are good chances that we'll get multiple entries at once
<niemeyer> rogpeppe: Since reservations are grouped
<rogpeppe> yeah, that's better. i was going to call WaitDNSName in parallel.
<rogpeppe> but that way is better
<rogpeppe> niemeyer: all our instances are in separate reservations.
<niemeyer> rogpeppe: Hmm, good point..
<niemeyer> rogpeppe: Even then, there must be a queue in the server side
<rogpeppe> niemeyer: who knows? given that we're waiting for a second before polling, we'll get any within that second.
<niemeyer> rogpeppe: Btw, I'm also working a bit on a quick clean up of goamz this morning.. I'll put all the packages in a single branch
<rogpeppe> niemeyer: yay!
<rogpeppe> niemeyer: (i'm glad you got that fix in before go 1)
<niemeyer> rogpeppe: Yeah, it'd be tricky later
<rogpeppe> niemeyer: thanks for the discussion BTW. i found it very useful.
<niemeyer> rogpeppe: I'm also including all the pending crack around mturk, sns, and sdb onto an exp/ subdir
<rogpeppe> good plan.
<niemeyer> They're not in a great state, but I want to make them into official branches since I've been doing a poor job reviewing/improving them
<niemeyer> rogpeppe: Yeah, it was instructional for me too, thanks as well
<fwereade> lunch,bbiab
<rogpeppe> niemeyer: all done, i think
<niemeyer> rogpeppe: Cheers
<rogpeppe> TheMue: i just added my review to fwereade's.
<TheMue> rogpeppe: yep, got the notification
<TheMue> rogpeppe: thx
<rogpeppe> TheMue: np
<TheMue> rogpeppe: maybe rietveld should add a +1 or Like button ;)
<rogpeppe> TheMue: +1 :-)
<rogpeppe> lol "
<rogpeppe> Don't worry.. I can't feel my toes anymore. They're already crushed
<rogpeppe> from fixing code with bad error handling.
<rogpeppe> "
<TheMue> fwereade: thx, will change it from map to the value. but do you validate every data you retrieve from a backend (here zk) before returning it?
<fwereade> TheMue, it just strikes me as sensibly paranoid ;)
<TheMue> fwereade: :D
<niemeyer> rogpeppe: You may want to delete this branch: https://code.launchpad.net/~rogpeppe/goamz/s3
<niemeyer> rogpeppe: Has no content
<fwereade> TheMue, there's certainly a case to be made that it's excessively paranoid ;)
<rogpeppe> fwereade, TheMue: personally i treat all data that comes from outside the program itself as suspect.
<rogpeppe> niemeyer: done
<fwereade> rogpeppe, indeed, the additional cost is minimal
<niemeyer> rogpeppe: Cheers
<niemeyer> rogpeppe, fwereade, TheMue: goamz is now a single branch
<fwereade> niemeyer, cool
<niemeyer> You'll have to rm -rf $GOPATH/launchpad.net/goamz
<rogpeppe> niemeyer: cool
<niemeyer> and then
<rogpeppe> go get -u won't work, presumably...
<niemeyer> go get launchpad.net/goamz/aws
<rogpeppe> that's a pity
<niemeyer> rogpeppe: Yeah, unfortunate but necessary
<rogpeppe> hmm, i'll just check i've got no outstanding branches before i rm -r...
<TheMue> rogpeppe: so you validate all data you read from ZooKeeper too?
<rogpeppe> TheMue: definitely. who knows what other dodgy programs have been at work there.
<rogpeppe> TheMue: i'd only validate as necessary though. no need to fail if you don't need to.
<TheMue> rogpeppe: how far goes your validation? how do you take care that the whole topology stored in one node is valid? or the combination of all nodes including their contents we use in state?
<rogpeppe> TheMue: depends what i'm doing with it. i'd check the error with it's parsed. and i'd check that any expectations i have of it are true. but i wouldn't check what i don't need to.
<TheMue> btw, do other applications write into our ZK instance?
<rogpeppe> s/with it's/when it's/
<niemeyer> rogpeppe: There's at least nothing in review
<rogpeppe> niemeyer:
<rogpeppe> % go get -u launchpad.net/goamz/aws
<rogpeppe> package launchpad.net/goamz/aws: directory "/home/rog/src/go/src" is not using a known version control system
<rogpeppe> hmm
<rogpeppe> TheMue: "other applications" might be just a buggy old version of our own code...
<niemeyer> rogpeppe: Try again please
<rogpeppe> niemeyer: same result.  but no delay - it seems like it's decided already...
<niemeyer> rogpeppe: Remove your local stuff
<rogpeppe> niemeyer: which local stuff? you mean change my GOPATH?
<niemeyer> rogpeppe: rm -rf $GOPATH/launchpad.net/goamz
<rogpeppe> niemeyer: i did that
<rogpeppe> niemeyer: there's no goamz directory
<rogpeppe> niemeyer: but i changed my GOPATH and it works
<niemeyer> rogpeppe: I've just installed it locally, and it works
<niemeyer> rogpeppe: So you probably have left over data
<niemeyer> Lunch time
<niemeyer> biab
<TheMue> rogpeppe: that surely maybe. so i would like you and fwereade do a walkthrough of the state code and take a look where further verification of informations retrieved out of ZK is needed.
<rogpeppe> niemeyer: it's worked now. bizarre.
<rogpeppe> TheMue: i've been looking out for it, so you're probably ok.
<TheMue> rogpeppe: ok, thx
<rogpeppe> niemeyer: http://paste.ubuntu.com/876199/
<TheMue> rogpeppe: how would you call the type for the Resolvedâ¦ values?
 * rogpeppe has a look
<rogpeppe> TheMue: i can't say i really understand what they're about, but perhaps ResolvedKind?
<TheMue> rogpeppe: inside the nodes content they are stored as "retry = 1000" or "retry = 1001". so maybe RetryKind is better.
<rogpeppe> TheMue: seems ok to me. fwereade should ok it though - he knows what's going on much better than i!
<TheMue> fwereade: what do you say?
<fwereade> TheMue, rogpeppe: I guess I'd say RetryKind or maybe RetryMode
<rogpeppe> fwereade: out of interest, what do these values mean?
<fwereade> rogpeppe, just jump to the next state, or try rerunning the hook and go back to error state if it fails
<rogpeppe> fwereade: ok thanks
<TheMue> rogpeppe, fwereade: thx, so i'll take RetryMode, looks best
<rogpeppe> TheMue: sounds good
<rogpeppe> this is weird. i've got one branch that's definitely different from another one, but running bzr diff between the two branches gives me no output.
<rogpeppe> how can that happen?
<rogpeppe> there must be some subtlety about "diff" that i don't get.
<rogpeppe> fwereade: any idea?
<fwereade> rogpeppe, no idea... I know "bzr diff" for uncommitted changes and "bzr diff --old lp:somewhere" and that's about it
<niemeyer> rogpeppe: How are you sure that there are differences?
<rogpeppe> niemeyer: i did md5sum on the files
<rogpeppe> ah, i forgot the --old flag
<rogpeppe> ah that worked!
<rogpeppe> i wonder what it was doing when i didn't give it the --old flag.
<rogpeppe> fwereade, niemeyer: thanks. i'm stupid.
<niemeyer> Man, I just got the strongest espresso I can remember
<rogpeppe> niemeyer: do those changes to go-ec2-robustness look ok, BTW?
<niemeyer> rogpeppe: Haven't re-reviewed yet
<rogpeppe> ok
<niemeyer> rogpeppe: Just finishing the goamz stuff and will go back
<niemeyer> rogpeppe, fwereade_, TheMue: FYI, https://groups.google.com/d/msg/goamz/cTZ5xmQeLQI/gFjSMMVrMbEJ
<rogpeppe> niemeyer: pity all that history has gone
<fwereade_> niemeyer, cheers
<fwereade_> and I think I'm done for the week -- happy weekends all :)
<niemeyer> fwereade_: Cheers
<niemeyer> fwereade_, rogpeppe, TheMue: Early next week, it'd be nice to have a call with the four of us
<niemeyer> To discuss a bit about how things are going in the port and align
<rogpeppe> niemeyer: sounds good
<niemeyer> rogpeppe: On the branch
<rogpeppe>  niemeyer: thanks
<niemeyer> rogpeppe: Nice reuse among DNSName and Wait&
<rogpeppe> niemeyer: thanks. i was pleased how that turned out.
<niemeyer> rogpeppe: Need to check for NoInstances too in StateInfo
<rogpeppe> niemeyer: i think that's ok - it'll just return the error
<niemeyer> rogpeppe: Sure, but that's not what we want, is it?
<rogpeppe> niemeyer: i think it is - if the instances don't exist (remember we've already timed out for eventual consistency) then we don't want to wait for them
<niemeyer> rogpeppe: Ah, you're right, thanks
<niemeyer> rogpeppe: Need to check nil within the loop, though, right?
<rogpeppe> niemeyer: oops yes, good catch!
<niemeyer> rogpeppe: We'll have to pay special attention when coding/reviewing logic with ErrPartialInstances.. feels easy to miss indeed
<rogpeppe> niemeyer: that's the hazard of returning incomplete data, i think. i'm not sure we can get around it.
<rogpeppe> niemeyer: pushed a fix.
<niemeyer> rogpeppe: Using ShortAttempt in live_test.go feels a bit like abusing private details of the implementation
<niemeyer> rogpeppe: It'd be nice to have a trivial Sleep there, and remove all the hacking from export_test.go
<rogpeppe> niemeyer: not sure. it's important that the local tests have a short sleep because otherwise the tests take much longer
<rogpeppe> niemeyer: but maybe i should just have a variable and be done with it
<niemeyer> rogpeppe: Only if they are broken, right?
<rogpeppe> niemeyer: no. quite a few of the tests test stuff that's deliberately broken.
<rogpeppe> niemeyer: so the timeout is exercised quite a bit
<niemeyer> rogpeppe: No, I mean it will only take a while if the test is broken
<rogpeppe> niemeyer: it makes the tests run for 20 or 30 seconds rather than 5.
<rogpeppe> niemeyer: i'm not sure i understand
<niemeyer> rogpeppe: I don't understand why..
<rogpeppe> niemeyer: because if you're testing that getting a non-existent instance (for instance) actually returns an error, then the code has to time out
<niemeyer> rogpeppe: There's a single use of ShortAttempt
<niemeyer> rogpeppe: and it repeats until it breaks
<rogpeppe> niemeyer: yes, but that test is run multiple times.
<rogpeppe> niemeyer: one time for each scenario
<niemeyer> rogpeppe: If it is run 10 times, and it takes 1 second to break on each, it's still 10 seconds
<niemeyer> rogpeppe: How many times is it repeating, and why does it take so long?
<rogpeppe> niemeyer: the timeout is 5 seconds not one second
<niemeyer> rogpeppe: It doesn't reach the timeout, unless the test is broken!
<rogpeppe> [18:15] <rogpeppe> niemeyer: because if you're testing that getting a non-existent instance (for instance) actually returns an error, then the code has to time out
<niemeyer> <niemeyer> rogpeppe: There's a single use of ShortAttempt
<niemeyer> <niemeyer> rogpeppe: and it repeats until it breaks
<rogpeppe> niemeyer: oh! sorry, i'd forgotten the real reason. the timeouts *inside* the ec2 package are exercised.
<rogpeppe> niemeyer: the ShortAttempt inside TestStopInstances isn't a problem. it could be hardwired as you suggest.
<rogpeppe> niemeyer: (which would cut out some of the hackery in export_test)
<niemeyer> rogpeppe: Ah, cool, we were talking about different things then
<rogpeppe> niemeyer: but we'd still need SetShortTimeouts
<niemeyer> rogpeppe: Yes, I was referring to those
<niemeyer> rogpeppe: That's fine
<rogpeppe> niemeyer: fix pushed.
<rogpeppe> niemeyer: i'm going to have to go very shortly, BTW
<niemeyer> rogpeppe: Cool, let me check that quickly so that hopefully you can get away with a pleasant submission :)
<rogpeppe> niemeyer: that would be marvellous
<rogpeppe> niemeyer: next two branches before actually running zookeeper and connecting to it are very small BTW. we're nearly there!
<rogpeppe> s/before actually running/getting/
<niemeyer> rogpeppe: Oh, that's great to hear.. I'm feeling so much behind on reviews
<niemeyer> rogpeppe: AWESOME!
<niemeyer> rogpeppe: LGTM
<rogpeppe> niemeyer: brilliant, thanks a lot. i've gotta go and do a gig now!
<rogpeppe> niemeyer: see ya monday.
<niemeyer> rogpeppe: Have a great weekend!
<rogpeppe> niemeyer: toi aussi
<niemeyer> rogpeppe: Cheers :)
 * TheMue has changed https://codereview.appspot.com/5727045. now i can go. have a good weekand, niemeyer 
<TheMue> niemeyer: bye, c u monday
<niemeyer> TheMue: Have a good one.. will try to unblock you for next week
<TheMue> niemeyer: getting good feedback by rog and fwereade, so it's ok
<niemeyer> TheMue: Sweet, good to see team work playing there
<TheMue> niemeyer: yep, absolutely
<TheMue> niemeyer: so have a good weekend
<niemeyer> TheMue: Thanks, a great one to you too!
<TheMue> niemeyer: thx
 * niemeyer breaks..
#juju-dev 2012-03-11
<antono> hello all
<antono> how can i configure EC2 image size?
<antono> is it possible to install 2 services on 1 machine
<antono>          with juju?
#juju-dev 2013-03-04
<rogpeppe> wallyworld: ping
<wallyworld> hello
<rogpeppe> wallyworld: i've just arrived
<rogpeppe> wallyworld: what's up?
<wallyworld> i'm tired, been awake for 28 hrs, about to go to bed :-)
<wallyworld> couldn't sleep on planes
<wallyworld> you fly in from heathrow?
<rogpeppe> wallyworld: cool. sleep well. see ya in da mornin'
<rogpeppe> wallyworld: no, paris
<wallyworld> yeah, sorry, too tired to do much now
<rogpeppe> wallyworld: couple of guys from yellow team on the same flight
<rogpeppe> wallyworld: have you seen anyone else?
<wallyworld> i saw benji on the lobby earlier
<wallyworld> he had just finished dinner and was heading up
<wallyworld> no one else though
<rogpeppe> wallyworld: k, thanks
<wallyworld> talk tomorrow
<rogpeppe> ttfn
<mgz> wallyworld: sleep well!
<mgz> rogpeppe: I'm just hanging around in room, not feeling the need to sleep quite yet but no particular plans
<rogpeppe> mgz: you eaten?
<mgz> did my message get through before dropping? :)
<mgz> rogpeppe: not since arriving, haven't worked out if I need another meal not not, but would be happy to go out somewhere and see
<mgz> rogpeppe: and you?
<rogpeppe> mgz: i'm in the same boat. but... actually, maybe i *should* grab some sleep while i can.
<rogpeppe> mgz: only got about 4h last night
<mgz> yeah, likewise
<mgz> but for less good reasons that you :)
<rogpeppe> mgz: how do you know :-)
<rogpeppe> mgz: anyway, think i might just crash. see you tomorrow...
<mgz> you said you had a gig, I was just doing things last minute :)
<rogpeppe> mgz: ah
<mgz> see you in the morning!
<rogpeppe> mgz: yeah, i did have a gig actually
<rogpeppe> mgz: it was cancelled
<rogpeppe> mgz: and the un-cancelled at the last moment
<rogpeppe> s/the/then/
<rogpeppe> mgz: finished playing at 4am
<mgz> did it go well?
<rogpeppe> mgz: yeah. knackering though. 5 solid hours of playing.
<mgz> you're just too hardcore :)
<rogpeppe> mgz: less so with every passing year!
<rogpeppe> sleep oh sleep, where are thou?
<niemeyer> benji: ping
<niemeyer> LOL
<niemeyer> Anyone else from the Yellow team here?
<niemeyer> Hmm
<fwereade> TheMue, https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1049908
<_mup_> Bug #1049908: Upstart control of lxc container instances <lxc (Ubuntu):Fix Released by serge-hallyn> <lxc (Ubuntu Quantal):Won't Fix> <lxc (Ubuntu Raring):Fix Released by serge-hallyn> < https://launchpad.net/bugs/1049908 >
<davecheney> https://bugs.launchpad.net/juju-core/+bug/1144704
<_mup_> Bug #1144704: environs/openstack: tests fail unless the user running the tests has ~/.ssh keys <juju-core:New> < https://launchpad.net/bugs/1144704 >
<jamespage> davecheney, any update on the mongodb packages I pushed to PPA?
#juju-dev 2013-03-05
<davecheney> m_3: https://launchpad.net/~gophers/+archive/go
<davecheney> $GOROOT/src/cmd/go
<mattyw> which is the best channel to use for general help using juju-core? this one or #juju? Specifically, I can't seem to get access to any debug-log (the command doesn't exist in juju-core) and my charm which deploys under pyjuju fails to install under juju-core. There's no /var/lib/juju/unit directory on the machine it deployed to for me to be able to find debug logs there
<mgz> mattyw: probably in here, though you might have more luck asking on the mailing list over irc this week
<mattyw> mgz, the juju dev list?
<mgz> mattyw: or the juju list is fine too
<mgz> m_3: ^is there anywhere we can point people wanting to debug their py-developed charms on go- currently?
<fss> niemeyer: ping
<niemeyer> fss: Hi
<fss> niemeyer: have you seem my email? (devincachu)
<niemeyer> fss: I did, sorry for not getting back yet.. a *lot* happening in the last couple of days
<niemeyer> fss: I'll ponder properly on the dates and how could try to help, and will let you know
<fss> niemeyer: sure, thank you!
<niemeyer> fss: Thanks for inviting!
<fss> niemeyer: I hope you'll be able to make it :)
<mgz> big swift upload maybe issue, bug 1110607
<_mup_> Bug #1110607: Deploying a large charm times out with 'openstack' provider <juju:New> < https://launchpad.net/bugs/1110607 >
<m_3> mgz: dunno
<m_3> mgz: (re: where peeps should go to debug pycharms in goju)
<mgz> m_3: from the mailing list post, seemed mostly getting-started issues with getting any charm running at all with gojuju
<m_3> mgz: ack... I'll see if I can get jorge on an askubuntu question
<jcastro> mgz: do you have a link to the post?
#juju-dev 2013-03-06
<bigjools> hello - can anyone give me an example of anything in the Go system libs that returns a channel?
<mgz> wallyworld: `ssh-import-id gz` on the hp wordpress machine please :)
<davecheney> thumper: speaking of ocd
<davecheney> flag.stringVar, the description is only respected on the first flag defined on a var
<davecheney> but the default value is only respected on the _last_!!
#juju-dev 2013-03-07
<thumper> davecheney: https://codereview.appspot.com/7573043/ please?
<niemeyer> Is the HA meeting happening?
<niemeyer> I'm in the hangout, alone ATM
<niemeyer> <niemeyer> Is the HA meeting happening?
<niemeyer> <niemeyer> I'm in the hangout, alone ATM
<niemeyer> mramm: ^^^
<gil_> I'm taking a look at graphite charm: http://jujucharms.com/~james-w/precise/graphite
<gil_> but to activity in it later
<gil_> what is need it to fix this charm ?
<sidnei> gil_: this channel is about development of juju itself, #juju is where the charms are discussed
<sidnei> gil_: that said, i made some attempts at using the packaged version instead http://jujucharms.com/~sidnei/precise/graphite
<gil_> sidnei: thanks I'll check out the other channel
<bac> rogpeppe3: when you have a moment could you come over?
<rogpeppe3> bac: yes. will come over soon, hopefully (planning poker in progress currently...)
<bac> o
<bac> k
<rogpeppe3> bac: this isn't going to finish any time soon. ask a question here...
<bac> rogpeppe3: i think you'll really need to see the code.  test infrastructure problems.
<dimitern> bac: can you paste it?
<bac> rogpeppe3, dimitern: i have added a new test for juju/conn.go.  it seems the old tests aren't cleaning up properly wrt to dummy environments: http://paste.ubuntu.com/5594254/
<dimitern> bac: right! we had the same issue yesterday - you'll need to call dummy.Reset() in TearDownSuite()
<bac> dimitern: thanks, rog and i just figured that out
<niemeyer> mramm:
#juju-dev 2013-03-08
<jtv> Is anyone here familiar with environs/jujutest?  I think it may be what I need to write integration tests for our own provider.
<dimitern> we have a test failure on trunk right now
<dimitern> http://paste.ubuntu.com/5596073/
<dimitern> TheMue: http://paste.ubuntu.com/5596073/
<TheMue> dimitern: thx
<dimitern> TheMue: well, running the test suite again it seems it passes
<dimitern> I'll file a intermittent test failure bug
<TheMue> dimitern: This is the already known and in LP entered bug. The fix is already in review, see the kanban board.
<TheMue> dimitern: No, don't file it again.
<TheMue> dimitern: You already added the intermittent flag to this bug. :D
<dimitern> TheMue: Ok, I'll just update it then
<dimitern> TheMue: can you send me a link to the CL with the fix/
<TheMue> dimitern: https://codereview.appspot.com/7423045/
<dimitern> TheMue: yeah :) just looking at it
<TheMue> dimitern: ;)
<dimitern> no worries then, it's known and has a fix pending
<TheMue> dimitern: Yes, only need a 2nd review.
<dimitern> mgz: ^^ ?
<dimitern> davecheney: can you explain please what builddb does and why does it need only the ec2 provider?
<davecheney> dimitern: it is a command that runs a charm in ec2 that builds mongodb
<davecheney> it will go away when we get mongodb 2.2.0 in a pacakge
<dimitern> davecheney: I see, thanks
<TheMue> dimitern: https://codereview.appspot.com/7423045 is in again
<dimitern> TheMue: you've got LGTM on the ports fix from me already
<dimitern> can I get a really quick trivial review on https://codereview.appspot.com/7616044/ ?
<davecheney> who wants to write release notes ?
<davecheney> https://docs.google.com/a/canonical.com/document/d/1KpSMl8GcW52W43TBb0f4utd9xk9zz18SomB4J8cEJQs/edit#heading=h.h7wry0fbg197
<davecheney> i know, everyone is dying to help
<rogpeppe> davecheney: http://paste.ubuntu.com/5596677/
<TheMue> dimitern: Thx
<dimitern> i filed a bug 1152717, found with the help of the gui guys
<_mup_> Bug #1152717: state/service.Destroy() may not remove the service with no units due to stale s.doc.UnitCount <state> <juju-core:New> < https://launchpad.net/bugs/1152717 >
<dimitern> rogpeppe: https://codereview.appspot.com/7616044/ please?
<davecheney> nag, https://code.launchpad.net/~dave-cheney/juju-core/101-lp-1152202/+merge/152192
<davecheney> looking for 2nd reviewer on, https://codereview.appspot.com/7650043/
<davecheney> https://codereview.appspot.com/7644045/
<davecheney> https://codereview.appspot.com/7551046/
<robbiew> davecheney: I'm flattered you think I could even do that kanban task. LOL
<robbiew> the awesomeness of autocomplete
<robbiew> robbiew vs rogpeppe
<rogpeppe> robbiew: ha ha
<rogpeppe> robbiew: it's all yours now
<robbiew> yeah....so that probably wouldn't be good for you all
<robbiew> lol
<davecheney> i'm just rolling the 1.9.10 release now
<davecheney> does anyone want to be a tester before we all bugger off to the pub ?
<davecheney> ok, debs are pushed, who wants to test ?
<davecheney> rogpeppe: https://codereview.appspot.com/7481048/
<davecheney> mgz: https://codereview.appspot.com/7481048/
<davecheney> ok, new ppa building now
<davecheney> will check back in an hour or so
#juju-dev 2013-03-09
<andrewsmedina> fss: oie
<davecheney> boring airport lounge is boring
<andrewsmedina> hi davecheney
<davecheney> hello everyone
<andrewsmedina> davecheney: I'm thinking of returning to contribute to the local provider
<andrewsmedina> what is the best way?
<andrewsmedina> to send small code to review? or work in a branch?
<davecheney> andrewsmedina: we always do work on an lp branch
<davecheney> andrewsmedina: how is your bzr fu ?
<davecheney> andrewsmedina: http://bazaar.launchpad.net/~juju/juju-core/trunk/view/head:/CONTRIBUTING
<davecheney> should be a first step to get you going
<andrewsmedina> davecheney: I already contributed with juju
<davecheney> andrewsmedina: the new Go port ?
<andrewsmedina> I wanted to know the best approach (small or big patches)
<andrewsmedina> davecheney: yes
<davecheney> andrewsmedina: I would say small patches is always a good start
<davecheney> but a better start is to discuss your idea first on the mailing list
<davecheney> to save time and rework
<andrewsmedina> davecheney: some times ago I started the local provisioner for juju-core
<andrewsmedina> davecheney: now I have time to continue this work
<andrewsmedina> for OpenStack provisioner is being kept a branch?
<davecheney> that is great, frank (themue) has been doing some work on the local provider during this sprint we had this week
<davecheney> so i would email him via the juju-dev mailing list to see where the gaps are
<andrewsmedina> its nice
<davecheney> the openstack provider is done in two parts
<davecheney> the first is the goose package, which is like goamz, it is a general, go based, openstack library
<davecheney> the second part, the openstack provisioner lives in environs/openstack
<davecheney> and uses goose as its backend, in the same way the ec2 provider uses the goamz pacakge
<andrewsmedina> ah, ok
<davecheney> i have heard there is a large Maas provider branch which is being developed
<andrewsmedina> I will send a email to juju-dev
<davecheney> and we're hoping those guys will merge their branch soon, as the merge process will prbably be a bit large
<davecheney> andrewsmedina: excellent, i'll watch for it and be sure to chase folks up when I get back to australia in a few days
<andrewsmedina> davecheney: thanks :)
#juju-dev 2013-03-10
<hazmat> what's the client's mongodb user/password? is it based off admin secret?
<hazmat> ah.. got it.
#juju-dev 2014-03-03
<thumper> wallyworld: checked the bot recently?
<wallyworld> thumper: yep and it's farked. i deleted 100000000 old test processes and restarted and it's been running tests for the 1.17.5 upgrade branch for ages now
<wallyworld> so it's still broken
<thumper> :-(
<wallyworld> thumper: my next step was to beg in #is for more resources to be allocated to that instance?
<thumper> wallyworld: we can try, right?
<wallyworld> yeah
<waigani> thumper: are we standing up?
<thumper> yes
<thumper> wallyworld: coming?
<mgz> morning all
<dimitern> morning from blue fin ;)
<dimitern> natefinch, \o
<natefinch> fwereade, dimitern, mgz, rogpeppe: morning
<dimitern> natefinch, we have a camera setup for you
<natefinch> dimitern: that is awesome, thanks guys.
<mgz> hey nate!
<dimitern> natefinch, i've sent you a g+ link as a pm
<natefinch> dimitern: oh, thanks, sorry
<natefinch> dimitern: one sec, having trouble getting G+ to use my canonical account instead of my gmail
<dimitern> natefinch, sure, join when you can, just to check it out and say hi, we're about to have a little break
<natefinch> dimitern:  ok
<dimitern> natefinch, you're frozen
<dimitern> natefinch, can you hear us well?
<natefinch> it froze for a while seems better now
<natefinch> the sound is pretty soft and somewhat choppy
<natefinch> dimitern: seems the connection is not very good
<natefinch> dim that's a bit better
<natefinch> dimitern: ^
<mgz> how mean nate
<natefinch> mgz: ug, stupid hangouts
<mgz> I have a coffee grinding story for you nate
<natefinch> mgz: heh, a story? :)
<rogpeppe> natefinch: lp:~rogpeppe/juju-core/507-peergrouper-integration
<rogpeppe> natefinch: in worker/peergrouper, go test -gocheck.vv -gocheck.f TestEnsureAvailability
<wallyworld> jam: mgz: landing bot is broken. i found it was cpu starved and the on aloja where it was running, there was a high load average. i tried resizing the landing instance to m1.large but that failed. so now the only option is to redeploy with a constraint to force it to use a larger instance. is the landing bot fully charmed or do we still have manual steps?
<mgz> yeah, I'm not sure that resize attempt was wise
<mgz> I tried sorting it at the end of friday, but the machine was pretty borked
<mgz> we probably need to redeploy, which does have several manual steps
<Beret> hi
<Beret> is there an add-machine API call?
<Beret> note I said add machine, not add machines
<natefinch> Beret: not sure what the difference is?
<wallyworld> mgz: yeah, the resize was a last resort to avoid redeploying
<wallyworld> mgz: today, it took about 12 hours for a test run which eventually failed
<wallyworld> totally cpu bound
<wallyworld> i reckon it needs to be on prodstack
<dimitern> wallyworld, so you're sprinting as well this week?
<wallyworld> dimitern: no?
<mgz> he's just doing the normal wallyworld week, which is sprinting by everyone else's standard
<dimitern> ah :)
<dimitern> wallyworld, we're told au/nz guys are doing a sprint at the same time
<wallyworld> dimitern: nah, we did get together a few weeks back though
<wallyworld> i would have preferred london to dunedin :-)
<wallyworld> the maas guys are in brisbane this week also
<mattyw> dimitern, ping?
<natefinch> mattyw: he's in a sprint, only partly paying attention
<mattyw> natefinch, ah ok, thanks
<mgz> natefinch: we're back! will get on the hangout again shortly, yell when you're around
<frankban> hi core devs: am I right assuming the API ServiceDeploy, when called without a ToMachineSpec, uses the following unit placement policy? if clean and empty machines/containers are available, use those, otherwise create a new top level machine for each unit
<natefinch> frankban: should be, yes
<frankban> natefinch: thanks
<rogpeppe> natefinch: a little review for you :-) https://codereview.appspot.com/70770043
<rogpeppe> natefinch: hmm, i think you're frozen
<rogpeppe> natefinch: oh, no, just immobile :-)
<natefinch> rogpeppe: haha
<rogpeppe> natefinch: took you a while to see that :)
<rogpeppe> natefinch: i'm serious though - a review would be appreciated
<natefinch> rogpeppe: sure thing
<natefinch> rogpeppe: why is errgo github.com/juju/errgo/errors and not just github.com/juju/errgo ?  Seems like errgo would never clash with anything, and it makes it more clear that it's errgo, not the std errors package
<rogpeppe> natefinch: because i think "errors" is a better name for the identifier, and it's a strict superset of the standard errors package
<rogpeppe> natefinch: links to your reviews?
<natefinch> rogpeppe: https://codereview.appspot.com/69600043/
<tasdomas`> I'm having problems constructing a manual environment from lxc containers
<tasdomas`> the error I get is:
<tasdomas`> Fetching tools: curl -o $bin/tools.tar.gz 'http://10.0.3.40:8040/tools/releases/juju-1.17.4.1-saucy-amd64.tgz'
<tasdomas`> 2014-03-03 15:50:01 ERROR juju.environs.manual provisioner.go:78 provisioning failed, removing machine 5: rc: 1
<tasdomas`> 2014-03-03 15:50:01 ERROR juju.cmd supercommand.go:293 rc: 1
<mgz> sinzui: thanks for resolving bug 1286885 - it is indeed deliberate to restore 1.16 compat
<_mup_> Bug #1286885: juju 1.17.3 incompatible with tools in canonistack bucket <compatibility> <regression> <juju-core:Won't Fix> <https://launchpad.net/bugs/1286885>
<sinzui> mgz, no
<sinzui> mgz, I mean NP
<marcoceppi> uh, so how do you remove a subordinate?
<coreycb> has anyone seen this with juju-core 1.17.4?  https://pastebin.canonical.com/105803/
<rick_h_> coreycb: is that with lxc?
<coreycb> rick_h_, no it's using kvm
<rick_h_> coreycb: ok, but local provider? The local provider doesn't support debug-log yet. I think that's still in progress
<coreycb> rick_h_, I'm using openstack
<coreycb> rick_h_, I think that means I'm not using a local provider
<rick_h_> coreycb: ah ok then not sure.
<coreycb> rick_h_, btw this worked last week on 1.17.3
<rick_h_> coreycb: k, yea sorry. Can you file a bug with your error and environment details?
<coreycb> rick_h_, sure and not a problem.  do you know how I can get back to 1.17.3?  it doesn't appear to be available in ppa:juju/devel
<rick_h_> coreycb: no, I'm not sure. sinzui is that possible without going compiling it custom?
<sinzui> coreycb, I think the error means the log is not where juju expects it to be. I understand the machine can be configured to put the logs else where...but I think you would remember doing that
<sinzui> coreycb, is the env your talking too 1.17.3? If so I think you need to exec "juju upgrade-juju" to bring the server and agents in line with your client
<sinzui> coreycb, 1.17.[0-3] were not backwards compatible with 1.16.x, the fix for 1.17.4 made it not work so well with previous devel versions of Juju.
<coreycb> sinzui, good question.. I'm not sure what the server is at
<coreycb> sinzui, juju upgrade-juju didn't change anything, but I'll look into what the server is at
<sinzui> coreycb, juju status will report the server and agent machine versions...and since 1.7.4 shows empty info for 1.17.x, you will know you will need to upgrade-juju
<coreycb> sinzui, thanks.  juju status shows 1.17.3.
<sinzui> and you are using juju 1.17.4 your local machine?
<coreycb> sinzui, yes
<sinzui> coreycb, I am surprised you can get that much info out of status. If you upgrade, you will get better debug and logging
<coreycb> sinzui, ok.  I'll try to get them both to the same version.  I think I need to do more than juju upgrade-juju to upgrade.
<sinzui> coreycb, 1.17.x looks for public versions of the tools...
<sinzui> coreycb, oh, I didn't see streams.canonical.com get the new tools. you may be right. I will look into this now
<coreycb> sinzui, appreciate it
<bodie_> Go newbie here, any recommendations for getting my feet wet?
<bodie_> in terms of bugfixes or tasks that need taking a whack at
<marcoceppi> bodie_: you can find a list of the bugs here: https://bugs.launchpad.net/juju-core/
<marcoceppi> bodie_: and "small" bugs are typically tagged "papercut" https://bugs.launchpad.net/juju-core/+bugs?field.tag=papercut
<bodie_> Okay, cool.
<thumper> o/ bodie_ marcoceppi
<thumper> good luck finding a simple bug
<thumper> juju is quite a complicated system
<bodie_> heh... I noticed that.  I'm taking a look over a few things on Github before taking the plunge, I think.  :)
<thumper> bodie_: what is your background?
<sinzui> coreycb, juju-upgrade will work with an open network now. streams.canonical.com has the new tools
<bodie_> undergrad CS analysis, math, etc, graduated last year, self taught in a bunch of languages.  Good w/ python, perl, C, java
<bodie_> I know my way around linux and such
 * thumper nods
 * thumper takes a quick look to see if he can find a simple bug
<bodie_> Juju, because I was actually thinking about making a similar service and discovered this
<thumper> bodie_: nice
<bodie_> yeah, the one thing I see as problematic here is being tied to openstack
<bodie_> if i read it right
<thumper> bodie_: I have found that often a good place to start with new projects is to look at low priority bugs (which the main dev team seldom get to) or tech-debt type bugs
<thumper> ?!
<thumper> juju isn't tied to open stack
<bodie_> ahhh
<thumper> open stack is just one provider
<bodie_> I must have misread the site then
<bodie_> i was at digitalocean for a while and a couple of us were talking about making a platform agnostic cluster deploy tool
<bloodearnest> bodie_: I think you just found it :)
<thumper> hazmat has a plugin for dealing with digital ocean
<bodie_> i'll have to get my head adjusted and re-read ;)
<thumper> also first class ec2, azure, soon joyent
<bodie_> nice!
<thumper> also maas, and a local provider
<thumper> local uses LXC containers on the host machine
<thumper> we also have manual provisioning
<thumper> do work with any machine you happen to have
<thumper> bodie_:  this could be a simple(ish) intro bug https://bugs.launchpad.net/juju-core/+bug/1197365
<_mup_> Bug #1197365: instance.Instance.WaitDNSName() no longer needed <tech-debt> <juju-core:Triaged> <https://launchpad.net/bugs/1197365>
<bodie_> right on
<thumper> bodie_: or this one: https://bugs.launchpad.net/juju-core/+bug/1217868
<_mup_> Bug #1217868: move from state.D to bson.D <hours> <tech-debt> <juju-core:Triaged> <https://launchpad.net/bugs/1217868>
<thumper> both are easy(ish) tasks that are just refactoring
<thumper> and noone else is looking at them
<bodie_> good deal, I'll take a look
<hazmat> bodie_, http://github.com/kapilt/juju-digitalocean
<coreycb> sinzui, I should be able to get that with ppa:juju/devel
<coreycb> right?
<coreycb> sinzui, upgrade still isn't working for some reason
<sinzui> coreycb, no. Ubuntu and the PPA provide command line and local deploy tools. They provide what goes on your computer.
<sinzui> coreycb, "juju --show-log upgrade-juju" tells the server and agents to find newer tools in the the current cloud or on streams.canonical.com
<sinzui> coreycb, you can also use your local installation to put the tools in the environment...
<sinzui> coreycb, "juju --show-log upgrade-juju --upload-tools"
<sinzui> coreycb, while the later always works, I prefer letting juju choose the correct origin so that it never think I have to provide more tools
<coreycb> sinzui, ok so the good news is that the latter worked.   but the former got "INFO juju upgradejuju.go:120 no upgrades available"
<sinzui> coreycb, okay. That means juju isn't finding tools
<bloodearnest> hazmat: about to have a play with jlxc
<sinzui> in the list of places to work
<hazmat> bloodearnest, that one isn't end user polished.. lots of undocumented setup.. i'm doing a talk on thursday.. i'm hoping to polish it up before then
<sinzui> coreycb, you are in a private cloud? Someone, perhaps you placed juju-*.tgz into a container?
<bloodearnest> hazmat: sure, np, I'm just gonna see if I can get it working, if not no worries
<hazmat> bloodearnest, actually with the aufs option, its reasonably straight-forward.. i've had some minor issues with aufs though and some software.
<hazmat> nfs in particular
<coreycb> sinzui, it's private.. this is on the server team's openstack on openstack deployment (serverstack)
<coreycb> sinzui, but anyway not sure.. I'll have to check into that
<hazmat> sinzui, if you don't provide tools you have no idea what tools juju will select, and no dry-run mode.. that's terrifying for prod
<sinzui> coreycb, okay. they probably seeded the tools. does the cloud have an open network? eg, can you deploy any charm whithout needing to fork and repackage its deps
<coreycb> sinzui, hmm, now juju destroy-environment gets "error: no environment specified"
<coreycb> sinzui, ah, it may not be open
<sinzui> coreycb, I would have thought the "--upload-tools" arg would have works from your 1.17.4 host. The feature works too well
<sinzui> coreycb, juju 1.17.x changed the destroy-environment args. You must specify the environment name to be clear you know what you are doing...
<sinzui> juju destroy-environment my-env
<coreycb> sinzui, I think I'm good to go.  --upload-tools did work, and debug-log works after I successfully upgrade-juju to 1.17.14.  and destroy-environment works as you said.
<sinzui> coreycb, great
<coreycb> sinzui, oh and there is a juju-1.17.3-precise-amd64.tgz getting pulled down in the bootstrap
<coreycb> sinzui, anyway, thanks!
<bloodearnest> hazmat: Great success! :)
<bloodearnest> hmm, maybe I spoke too early
<bloodearnest> but progress, anyway
<hazmat> bloodearnest, what's the hangup.. its pretty instaneous if its working.
<hazmat> bloodearnest, if you dont have btrfs.. you need a code mod (its already commented) to enable the aufs support... i should toss that into a cli param.
<hazmat> bloodearnest, oh.. that install.sh.. i was going to yank it.. doh.
<hazmat> i haven't actually used it, its an old artifact from some previous exploration.
#juju-dev 2014-03-04
<waigani> wallyworld_: I forgot to grab that example before leaving the standup. Can I grab it again please?
<wallyworld_> for loop starts at line 548 in state.go
<waigani> wallyworld_: cheers
<wallyworld_> np
<axw> wallyworld_: you did a fix to the unit upgrader... did it fix https://bugs.launchpad.net/juju-core/+bug/1284502?
<_mup_> Bug #1284502: upgrader: cannot read tools metadata (in unit agent) <local-provider> <juju-core:Triaged> <https://launchpad.net/bugs/1284502>
<wallyworld_> axw: i think so
<wallyworld_> yes
<wallyworld_> that branch is in the queue to land
<axw> ok
<wallyworld_> thumper: so i can't push to lp:~go-bot/juju-core/trunk. says it's read only
<thumper> ah...
 * thumper thinks
<thumper> wallyworld_: you need to do this:
<thumper> bzr push bzr+ssh://go-bot@bazaar.launchpad.net/~go-bot/juju-core/trunk
<thumper> your ssh key is loaded against the go-bot user
<wallyworld_> ah ffs. i tried that but forgot the go-bot@ bit
<thumper> :)
<thumper> wallyworld_: are you setting the author on the merge?
<wallyworld_> what's the way to do that?
<thumper> when you have a merge
<thumper> run the tests
<wallyworld_> yep
<thumper> bzr commit -m "blah blah" --author "Firsrt Last <email addr>"
<wallyworld_> ah --author, ok
<axw> thumper: https://codereview.appspot.com/67870045/    -- the change in AddScripts fixes the log dir permissions. Did this as a drive-by in a larger fix
<thumper> ok
<thumper> hmm...
<thumper> axw: actually I ment to ask you earlier today
<thumper> how the juju-db upstart job was getting removed
<axw> thumper: the machine agent removes it on tear down
<axw> pkill -SIGABRT kills the machine agent, which stops and removes the jobs
<thumper> axw: so the machine agent also brings down the mongo job?
<axw> thumper: yep, that bit is now shared between local and manual providers.
<axw> thumper: see uninstallAgent in cmd/jujud/machine.go if you care to see where
<thumper> ok
<thumper> wallyworld_: I don't want to see the asserts removed
<thumper> wallyworld_: just moved to an explicit test
<wallyworld_> thumper: but it's part of the setup
<wallyworld_> not prt of what is being tested
<thumper> wallyworld_: if something from setup is tested in one test, you don't need to do it in every test
<thumper> I disagree
<thumper> the setup it the setup
<thumper> the test checks the setup did it right
<thumper> what you have
<wallyworld_> it is to ensure the setup does what we think
<thumper> is the test that it worked every time done every time
<thumper> IMO this is overkill
<wallyworld_> i've seen tests before where setup was faulty and we didn't know it
<thumper> just what I was brought up with, blame mwhudson
<thumper> wallyworld_: I'm not saying don't test that setup did it right
<thumper> what I am saying is don't do that assertion *in* setup
<wallyworld_> so you want a TestSetuptest()
<thumper> have a test for the purpose of making sure that setup did it right
<thumper> FFS, do what you like
 * thumper gives up
<wallyworld_> no, it's ok, i'll change it
<wallyworld_> just trying to understand yout pov
<axw> I don't know the context, but that sounds like a recipe for difficult to debug test errors when TestSetuptest doesn't run before the other tests
<wallyworld_> there isn't a TestSetuptest yet
<wallyworld_> i was doing asserts in Setup() to ensure that the test setup was done right
<wallyworld_> or more to the point, did what we thought it did so that subsequent tests could be assured of testing the right thing
<wallyworld_> but i can add an explicit test to check the behaviour of SetUp()
 * wallyworld_ -> lunch
<thumper> I guess this is why having lots of setup in setup is not good
<thumper> wallyworld_: look, the overhead of running it every time is insignificant
<axw> hmm, I don't see the need for the assertions at all really. this is testing that SetEnvironConfig does its job
<thumper> just keep them in setup
<axw> that should be done in state
 * axw shrugs
<thumper> axw: what was the failure here: https://code.launchpad.net/~axwalk/juju-core/local-prereq-rsyslog-gnutls/+merge/208545
<thumper> intermittant?
<axw> thumper: pretty sure it's because the bot was in a bad way
 * thumper nods
<mwhudson> thumper: wat
<wallyworld_> axw: the assertions were not to check that SetEnvironConfig did it's job, but that there weren't typos in hgow it was invoked such the the expected config attrs were set, since the test checks for their removal
<axw> wallyworld_: if you're making assertions about how the tests work, then when do you stop?
<wallyworld_> i only do it for selected cases
<wallyworld_> on a subjectively as needed basis where there's some risk
<thumper> mwhudson: oh hai
<thumper> mwhudson: just taking your name in vain
<mwhudson> thumper: cool
<mwhudson> :)
<thumper> mwhudson: for teaching me about tests
<thumper> in a good way
<wallyworld_> waigani: tests on your branch fail so i can't land it for you:  policy-based-config-validation
<waigani> wallyworld_: doh
<waigani> okay, I'll check
<wallyworld_> ok, ta
<wallyworld_> axw: i get test failures in ~axwalk/juju-core/local-prereq-rsyslog-gnutls
<wallyworld_> ah
<wallyworld_> cause i don't have syslog-gnutls installed
<wallyworld_> let me install that and retry
<wallyworld_> right, that's much better
<axw> wallyworld_: hrm, that's actually a problem :)
<axw> tests shouldn't rely on the package being there
<wallyworld_> i guess we need to add it to the packaging stuff
<wallyworld_> i think it's reasonable the deps are expected
<wallyworld_> eg tests will fail if no mongo
<axw> true
<wallyworld_> i'd send an email to the list to let people know they need to install it
<axw> wallyworld_: I actually thought I had isolated this one, so I'll see if it's easy to fix... otherwise I will email the list
<wallyworld_> and let curtis know so he can get the ppa sorted
<axw> juju-local should be updated tho, there's a bug for that
<wallyworld_> regardless for the next release the packaging needs to be changed
<axw> wallyworld_: what do you mean by the packaging?
<wallyworld_> that fact that juju-core depends on this new package
<axw> wallyworld_: the client doesn't need rsyslog-gnutls, and it will be installed by bootstrap
<axw> no, only local requires it to be pre-existing
<wallyworld_> oh ok
<wallyworld_> but that's still juju-core
<axw> there's a meta package for the prereqs
<wallyworld_> so if one installs juju-core, it should pull down this new dep
<wallyworld_> sure, the dependencies need to be updated
<axw> yep, there's a bug for it against 1.18
<wallyworld_> ok, that's great
<wallyworld_> just wanted to double check
<axw> wallyworld_: when you have a moment, can you please review https://codereview.appspot.com/71050043?
<wallyworld_> sure
<wallyworld_> just landing the rsyslog port branch
<wallyworld_> axw: all approved mps landed \o/
<axw> thanks wallyworld_  :)
<wallyworld_> i'm pleased too
<bloodearnest> hazmat: re install.sh, sure, I didn't exec it, but it was useful as a crib sheet for set up steps
<natefinch> mgz, rogpeppe, dimitern: o/
<dimitern> natefinch, morning!
<natefinch> dimitern:  morning :)
<mgz> natefinch: we're getting wwitzel3 to g+ you now for the hangout
<natefinch> mgz: cool
<natefinch> jam: https://plus.google.com/hangouts/_/76cpirbanp35boic60gobgfltc?authuser=1&hl=en
<mgz> http://en.wikipedia.org/wiki/Shrove_Tuesday
<natefinch> mgz: I didn't know they had a whole week of this stuff.
<mgz> the feasting bit is only today, the following period is fasting
<wallyworld_> mgz: from what i can tell, juju trunk  canonistack don't like each other because port 17070 can't get routed via chinstrap like port 22 can for ssh
<wallyworld_> or am i missing something?
<wallyworld_> i was hoping to try and get the landing bot running
<wallyworld_> but i ended up testing a bunch of branches and landing manually
<wallyworld_> at least the backlog of approved mps is now in trunk
<mgz> wallyworld_: you can always route via sshuttle to the bootstrap node, but I think going via chinstrap should be fine
<mgz> wallyworld_: I saw you'd landed a bunch of branches, thanks
<wallyworld_> mgz: i tried using shuttle, no good
<wallyworld_> i must have been doing it wrong
<mgz> the main issue is lcy02 is just hosed, but I will probably try bring up a new bot on lcy01
<wallyworld_> ok
<mgz> or fall back to ec2 if needed
<wallyworld_> previously lyc02 was better
<dimitern> LXC is now fixed on trusty for me - local provider works again! \o/
<wallyworld_> dimitern: yeah, i landed a fix today
<wallyworld_> it was broken for trusty host and precise charms
<wallyworld_> but worked if host and charms were the same
<wallyworld_> well, the upgrader bounced anyway
<bloodearnest> wallyworld_: huh, that explains this mornings issues, thanks :)
<wallyworld_> bloodearnest: ah, sorry about that. fixed now :-) a fix for one problem broken something else so needed a second fix :-/
<bloodearnest> wallyworld_: no worries, seems good now. I thought I'd broken things by having 4 active local envs at once
<wallyworld_> nah :-)
<bloodearnest> I get warnings for shared-storage-port env config - can I just drop that now?
<wallyworld_> not sure about that one off hand, let me check
<wallyworld_> bloodearnest: i think you can delete that one
<bloodearnest> wallyworld_: great - the warnings interfere with my bash auto-completion
<dimitern> wallyworld_, awesome! 10x
<ahasenack> does anyone know what the hook behavior is when a unit is rebooted?
<ahasenack> I'm seeing that in 1.16.6 the config-changed hook is run, for example. Is that expected?
<natefinch> dimitern, rogpeppe:  I think john dropped out of the hangout btw
<ev> hi guys. Is anyone working on https://bugs.launchpad.net/juju-core/+bug/1284183? It's causing us a lot of pain as we try to deliver some customer work and we've got a big deadline coming up in a couple of weeks
<_mup_> Bug #1284183: jujuclient.EnvError: <Env Error - Details:  {   u'Error': u'watcher was stopped', u'RequestId': 9, u'Response': {   }} <api> <status> <juju-core:Triaged> <https://launchpad.net/bugs/1284183>
<natefinch> ev: we're actually triaging bugs today, so we can look at that one and see what's up with it. Roger knows the most about it, but is out to lunch, he should be back shortly, however
<ev> cool, thanks natefinch
<mgz> bug 1287147 for the FFE
<_mup_> Bug #1287147: [FFe] juju-core 1.18/2.0 <juju-core (Ubuntu):New> <https://launchpad.net/bugs/1287147>
<natefinch> rogpeppe: when you get a chance, I committed fixes for the issues you brought up in the code review: https://codereview.appspot.com/69600043/
<rogpeppe> natefinch: will look in a mo
<ev> rogpeppe: also if you could have a look at bug 1284183 whenever you get a chance, I'd greatly appreciate it. My team at Canonical keeps hitting it and its killing our velocity as we try to deliver a contract over the next two weeks
<_mup_> Bug #1284183: jujuclient.EnvError: <Env Error - Details:  {   u'Error': u'watcher was stopped', u'RequestId': 9, u'Response': {   }} <api> <status> <juju-core:Triaged> <https://launchpad.net/bugs/1284183>
<natefinch> jam: https://plus.google.com/hangouts/_/76cpirbanp35boic60gobgfltc?authuser=1&hl=en
<rogpeppe> ev: i've just been looking at that bug with a view to trying to repro it
<ev> rogpeppe: yay! cjohnston can probably help get logs and things if you need them
<rogpeppe> ev: the repro instructions don't seem to work for me
<ev> he experiences it quite often
<ev> doanac and urshina as well, who I'll tell to join this channel
<rogpeppe> cjohnston: you've got a bare "sshuttle" line there, but sshuttle just gives me a usage message there
<cjohnston> rogpeppe: you will need to do sshuttle for an instance you have.. I couldn't give you the exact command I use because it wont work for you
<rogpeppe> cjohnston: a sample command line? (i haven't used sshuttle before)
<rogpeppe> cjohnston: (and i'm not sure what you wanted it to do here)
<ev> Ursinha: just reproduced it
<cjohnston> rogpeppe: sshuttle -r ubuntu@10.55.60.216 10.55.0.0/16
<cjohnston> rogpeppe: when using something like HP cloud you don't need it.. but you need it to use canonistack
<rogpeppe> cjohnston: i'm using ec2
<cjohnston> rogpeppe: we dont use ec2 because of the api
<rogpeppe> cjohnston: or the local provider
<rogpeppe> cjohnston: which api?
<cjohnston> the ec2 api is different from hp/canonistack
<ev> (openstack API - we use glance and swift)
<Ursinha> ev: it seems I hit the watcher bug every time I try to deploy using a fresh bootstrapped environment
<natefinch> mgz, jam1, fwereade: is the bot working yet?  Just realized I marked stuff for merge, but there may be no bot to merge it
<mgz> natefinch: nope
<mgz> was going to fix today but have been under the weather
<natefinch> mgz: ok, no problem, just wanted to know what the plan was.
<mgz> you can manually land things if needed urgently
<hazmat> ahasenack, no config-changed hook was being executed gratitiously.. there's a bug against that, i think its fixed in trunk
<hazmat> er. 1.17
<natefinch> mgz: nothing's terribly urgent, it just would be nice, since I have other stuff that depends on it.
<hazmat> bloodearnest, the other crib sheet item is using the lxc stable ppa if not on trusty for aufs
<bloodearnest> hazmat: yeah, am on trusty so skipped
<hazmat> bloodearnest, so it worked out for you?
<bloodearnest> hazmat: I needed jujuclient 0.17 from PyPI (0.15 in trusty seems to have bug)
<bloodearnest> hazmat: and I could jlxc-add machines, buit the didn't come up properly - I think I may have encountered an issue in trust with local provider that was fixed today
<bloodearnest> hazmat: I will try again tomorrow sometime
<hazmat> bloodearnest, this doesn't use local provider
<hazmat> bloodearnest, jlxc that is
<bloodearnest> hazmat: good point, not sure why it didn't work then
<hazmat> bloodearnest, probably missing packages in your base snapshot
<hazmat> bloodearnest, needs git, cpu-checker at min
<ahasenack> hazmat: it highlighted a bug in our charm anyway, someone rebooted a node and config-changed ran and highlighted an issue
<ahasenack> same thing happens with a juju set, just turns out a reboot triggered it :)
<hazmat> fuzz testing
<mgz> http://godoc.org/github.com/loggo/loggo#Formatter
<bloodearnest> hazmat - makes sense - will try again later
<hazmat> half of all open bugs marked high
<hazmat> hmm
<natefinch> hazmat: if they weren't important bugs, they wouldn't have bothered to log them
<natefinch> hazmat: I wonder what portion of the non-high bugs were created as high
<hazmat> natefinch, almost zero
<hazmat> sinzui, https://bugs.launchpad.net/juju-core/+bug/1219441 is fix committed or released (dev version) afaik
<_mup_> Bug #1219441: juju cli should cache api endpoint, saves up to 75% of run time <papercut> <performance> <juju-core:Triaged by rogpeppe> <https://launchpad.net/bugs/1219441>
 * hazmat goes bug weeding
<sinzui> hazmat, thank you very much! I too and looking for fixed or now wint fix bugs
<hazmat> sinzui, re high philosophy. are you abiding by lp severity help/description guidelines? or something else
<hazmat> ie. high for next release?
<sinzui> high is fix in the next 6 months
<sinzui> hazmat, If we want it fixed for 14.04, we should target to 2.0
<ev> does juju work on rackspace? I can't find any documentation for it
<ev> or are my options HP and AWS
<hazmat> ev no
<hazmat> ev or digitalocean ;-) .. ie manual provider works everywhere.
<ev> hazmat: we need openstack APIs as we use glance and swift as part of this project
<ev> otherwise I'd be all over the AWS goodness
<hazmat> ev, there are some issues with rackspace and openstack provider due to lack of images, lack of security groups, etc.
<ev> ick, I'll cancel the account then
<ev> I wonder why there are other accounts inside canonical then?
 * hazmat draws blanks
<hazmat> they gave some freebie accounts for ostack devs
<ev> ^ cjohnston don't bother with rackspace
<cjohnston> ev: I saw
<ev> cool
<waigani> wallyworld_: thanks for landing the branches yesterday
<thumper> gah
<thumper> niemeyer: do you know why this fails? args = append(args, "--", templateArgs...)
<thumper> both args and templateArgs are []string
<niemeyer> thumper: The variadic parameter must match the variadic parameter of the function
<thumper> I would have thought that would work
<thumper> so it isn't unpacking and repacking
<thumper> just passing throughj
<niemeyer> thumper: Right
<thumper> hmm...
<thumper> ok
<niemeyer> thumper: I'm not sure if that's a good thing or not, or if eventually it'll just be more flexible
<niemeyer> thumper: I suspect it's one of these "let's see how it goes" cases
<thumper> it is just one of those "I would expect this to work and it doesn't" moments
<niemeyer> thumper: I agree
 * thumper falls foul of the fix bug and try again without rebuilding issue
<thumper> ok, that isn't too crazy
<waigani> thumper: go newbie question?
<thumper> shoot
<waigani> http://paste.ubuntu.com/7035472/ I'm getting the error: newConfig declared and not used on line 16
<waigani> At first, I thought block scope was stopping me from conditionally setting the variable.
<waigani> But as long as I declare the var in the parent scope, it should work. I did a simple test in the playground: http://play.golang.org/p/rhxBZjqexA
<waigani> So I'm stumped.
 * thumper thinks he knows without looking
<thumper> but looks anyway
<thumper> right
<thumper> you hit the same issue as wallyworld yesterday
<waigani> newConfig should be used on line 38?
<thumper> since you are using := it creates a new one
<thumper> in that scope
<thumper> you need to use =
<waigani> aahhh
<thumper> which may mean you need to declare
<waigani> thanks
<thumper> var err error
<waigani> yep
<waigani> cheers
<thumper> np
<waigani> wallyworld: I'm getting the following test failure:
<waigani> # launchpad.net/juju-core/worker/rsyslog
<waigani> worker/rsyslog/worker.go:19: import ...go/pkg/linux_amd64/launchpad.net/juju-core/log/syslog.a: object is [linux amd64 go1.1.2 X:none] expected [linux amd64 go1.2 X:none]
<waigani> yet go version returns: go version go1.2 linux/amd64
<waigani> Any hints, off the top of your head?
<wallyworld> try deleting your pkg directory to force it to recompile everything. i think you must have upgraded your go version and have old compiled artefacts hanging around
<waigani> wallyworld: will do, thanks
<waigani> wallyworld: 5min hangout?
<wallyworld> waigani: i'm sitting in the tyre shop getting some tyres fitted. so i can't really do it now sorry
<waigani> np
<wallyworld> hopefully it will be finished soon
<waigani> so I rm -rf pkg
<wallyworld> it's quite an open office so i can't reslly talk
<waigani> sure
<waigani> now when I make check I get a LOT of those wrong go version errors
<wallyworld> which pkg dir did you remove
<waigani> ~/go/pkg
<wallyworld> so your juju src lives under ~/go/src
<waigani> yep
<wallyworld> and if you go build ./... it fails?
<wallyworld> did you recently install a new version of go
<waigani> yes
<waigani> well, a few weeks ago
<waigani> this is the first time I've seen this error though
<wallyworld> hmmm. it should have shown up immediately so there's something else at play
<wallyworld> what else has changed?
<waigani> hmmm...
<waigani> wallyworld: go build ./... throws a whole bunch of the same errors
<waigani> http://pastebin.ubuntu.com/7035788/
<waigani> a path problem maybe?
<waigani> i.e. two different go excs running?
<wallyworld> seems like it what does "which go" say
<waigani> /home/jesse/go/src/code.google.com/p/go/bin/go
<wallyworld> and that's where you installed go 1.2 to?
<waigani> i think so, go I'll retrace my steps
<wallyworld> what version does that report?
<waigani> 1.2
<wallyworld> cause there will also be a /usr/bin/go
<waigani> ah
<wallyworld> why didn't you install to /usr/bin?
<waigani> /usr/bin/go = 1.1.2
<waigani> wallyworld: good question!
<wallyworld> there should be a ubuntu package for it
<waigani> I'll do that now and see if it fixes it
<wallyworld> there's something hppening i don't fully understand
<wallyworld> but yeah, try and get only one version installed and see if tha helps
<wallyworld> "go build -a" could also be tried
<waigani> what does that do?
<waigani> it just returned without output
<wallyworld> you still need to tell it what to build
<wallyworld> i was just saying use the -a param to force a rebuild of everything even if it thinks it's not out of date
<wallyworld> iow go build -a ./...
#juju-dev 2014-03-05
<thumper> coffee time...
<hazmat> thumper, wallyworld_, waigani  if any of you are up for user support.. there's a guy having trouble getting started with charm authoring #juju
 * wallyworld_ hasn't written any charms :-(
<waigani> waigani: sorry hazmat I don't think I'd be much help yet - still a newbie :/
<hazmat> waigani, no worries.. we all start somewhere
<hazmat> waigani, and welcome aboard
<wallyworld_> maybe davecheney is around?
<waigani> hazmat: thanks :)
<davecheney> ping, can anyone review this CL ? https://codereview.appspot.com/69980044/
<davecheney> is the landing bot working at the moment ?
<waigani> davecheney:  wallyworld_ has been wrestling with it, he would be the one to ask
<wallyworld_> davecheney: sadly not working, i've been landing stuff manually
<wallyworld_> i can do your review and land
<davecheney> wallyworld_: ta
<wallyworld_> davecheney: there's a guy in #juju talking to hazmat about a charm problem, are you able to guess what the issue might be?
<davecheney> i'm in that channel
<davecheney> i've asked the guy for more information
<hazmat> davecheney, thanks
 * hazmat returns to customer work...
<wallyworld_> davecheney: does azure or joyent or maas support the new arches from your branch?
<davecheney> wallyworld_: maas yes
<davecheney> joyent and azure, no
<davecheney> this CL is a clone of thumper s
<davecheney> s/arm64/ppc64/g
<davecheney> basically
<wallyworld_> do we need to update the maas provider?
<wallyworld_> ah ok
<davecheney> wallyworld_: in a perfect world yes
<davecheney> but we don't have ppc64 maas machines to test on
<wallyworld_> we really need to fix the "amd64", "i386", "arm", "arm64 ", "ppc64" thing
<davecheney> so lets cross that bridge when we get to it
<wallyworld_> ok
<davecheney> wallyworld_: i agree, too many constants
<wallyworld_> it's also a little disconcerting or something that no tests needed to be updated
<davecheney> indeed
<davecheney> i have no idea how thumper got away with it
<wallyworld_> i'll file a bug
<wallyworld_> we can fix the consts and tests all in one go
<wallyworld_> davecheney: actually I think I modified a lot of that code at some point. i don't think we ever had tests for which arches various providers supported
<waigani> wallyworld_: Reset in upgradejuju_test sets the agent-version. This throws  an "agent-version cannot be changed" error with my new code.
<waigani> show agent-version be allowed to be changed?
<waigani> *should
<wallyworld_> yes
<waigani> wallyworld_: okay, that check was brought over from apiserver
<wallyworld_> it's how an upgrade is triggered
<wallyworld_> let me check
<waigani> wallyworld_: https://codereview.appspot.com/63790045/diff/40001/state/apiserver/client/client.go#newcode791
<waigani> I brought that agent-version check over into state.
<waigani> so I can just delete it?
<wallyworld_> waigani: the check from the apiserver client is to stop people changing the agent version manually without going via upgrade
<waigani> wallyworld_: right, so it only makes sense in apiserver?
<wallyworld_> the SetEnvironAgentVersion() methof is used to change the agent version in state for ugrades
<wallyworld_> only makes sense in client.SetEnvironment()
<waigani> wallyworld_: yep. no problem, I'll get it out of state.
<wallyworld_> but, we want to ensure only thing that can change agent version in state is the proper upgrade path
<waigani> okay ...
<wallyworld_> the check in client.EnvironmentSet() is all we do now i think
<thumper> oh ffs
 * thumper stabs something
<waigani> wallyworld_: I'll make a todo and come back to that
<wallyworld_> waigani: if needed. i'm not 100% across the finer detail
<waigani> sure, we will revisit it at a later date
<wallyworld_> thumper: i'm not sure i fully agree with our current upgrade logic. now, if you juju upgrade and don't specify anything, it gets the current agent version and increments the minor version number. i would have thought we would use the version of the CLI used to do the upgrade to determine the desired version to which to upgrade
<thumper> wallyworld_: sounds reasonable
<thumper> perhaps we do the following:
<wallyworld_> if you use --upload-tools or --version, that sets things exlicitly
<thumper> * if nothing is specified, use version.Current
<thumper> * if version.Current == the version deployed, info, and call it success
<thumper> if version.Current < deployed version, error ??
<wallyworld_> effectively we do all that and more now
 * thumper is trying to work out how to mock something out...
<wallyworld_> excet for the case where nothing exlicit is secified
<wallyworld_> a function?
<wallyworld_> davecheney: can you merge latest trunk into your branch and resolve conflicts? i've got trunk r2375 (tip) and when I merge your branch to get conflicts cause "arm64" changes have already landed
<wallyworld_> I wanted to run tests and then land it for you
<thumper> davecheney: is there a signal to kill go test with to figure out where it has hung?
<thumper> axw: ^^ do you know?
<axw> thumper: umm, I think there is... I forget which
 * axw looks
<axw> thumper: according to a rather old post (2009), killing with SIGSEGV will do
<davecheney> thumper: axw SIGQUIT
<thumper> hmm
<davecheney> or ^\
<thumper> davecheney: is the a ctrl+ key for that?
<axw> ah, SIGQUIT works for Go? ok
<davecheney> the go command ignores that signal and passed it through to the child process
<davecheney> SIGQUIT
<davecheney> kill -QUIT
<davecheney> cntl+\
<davecheney> ^ all da same
<thumper> ta
<thumper> that worked
 * thumper goes to figure out what he did wrong
<davecheney> wallyworld_: thanks for landig that commit
<davecheney> much appreacited
<wallyworld_> davecheney: i haven't yet - i merged into my local trunk tip and got conflicts cause the "arm64" bit has already landed
<wallyworld_> once I can merge and run the tests, then I can land
<davecheney> wallyworld_: the bot said it was landed
<wallyworld_> oh?
<wallyworld_> is the bot running
<wallyworld_> it wasn't last night
<thumper> ah found it
<wallyworld_> i thought it was still broken
 * thumper stabs it in the face
<wallyworld_> hence my offer to land the branch for you
<davecheney> whelp, that is just weird
<thumper> yep, that was it
<wallyworld_> davecheney: i just checked juju-core - your branch isn't landed from what i can see
<wallyworld_> mp still says aroved
<wallyworld_> approved
<wallyworld_> recent revisions on https://code.launchpad.net/~go-bot/juju-core/trunk doesn't list it
<davecheney> ok
<davecheney> maybe I was mistaken
<wallyworld_> davecheney: i did approve the mp in preparation for testing and landing though
<wallyworld_> maybe thats what you saw
<wallyworld_> so the conflict i see is because your branch added "arm64" and "ppc" but "arm64" is already added
<wallyworld_> hence conflict
<davecheney> yeah, thumpers branch is a prereq
<davecheney> if you can land that one first
<davecheney> i'll redo mine
<wallyworld_> davecheney: thumpers is already landed
<davecheney> wallyworld_: ok, i'll redo my branch
<wallyworld_> ok, i'll look at it after the school run
<arosales> wallyworld_: any ideas on this bug https://bugs.launchpad.net/juju-core/+bug/1285803
<_mup_> Bug #1285803: [Joyent Provider] metadata mismatch when testing again Joyent Public Cloud <joyent-provider> <test-failure> <juju-core:Triaged> <https://launchpad.net/bugs/1285803>
<wallyworld_> arosales: i'll take a look and see what I can find
<arosales> wallyworld_: thanks.  I had utlemming and curtis take a look and it didn't look related to the streams set up so I thought I would check with you.
<wallyworld_> sure, i've got a meeting now but will get to it asap
<arosales> wallyworld_: thanks
<wallyworld_> np
<dimitern> jamespage, hey, axw recently added rsyslog-gnutls as a required package and juju-local should have it in its list of dependencies
<jamespage> dimitern, *$!Â£$%
<jamespage> its in universe
<jamespage> I'll look in a bit
<dimitern> jamespage, cheers!
<hazmat> jamespage, its in universe because of gnutls?
<jamespage> hazmat, not sure - looking atm
<jamespage> hazmat, nah - I don't think this is hard
<jamespage> rsyslog source is in main
<jamespage> just not the -gnutls binary package
<mgz> and gnutls is in main
<rogpeppe> cjohnston: ping
<mgz> so, it doesn't seem *that* outlandish to promote the rsyslog-gnutls package to main
<jamespage> mgz, indeed
<jamespage> binary re-promotions are not normally that bad
<hazmat> cool
<jamespage> dimitern, hazmat: is there a bug I can reference please?
<hazmat> jamespage, https://bugs.launchpad.net/juju-core/+bug/1285550
<_mup_> Bug #1285550: juju-local must install rsyslog-gnutls <local-provider> <juju-core:In Progress by sinzui> <https://launchpad.net/bugs/1285550>
<natefinch> dimitern, mgz, jam, rogpeppe: morning
<mgz> mornin' nate, we'll set you up
<natefinch> mgz: thanks
<jam> morning nate: https://plus.google.com/hangouts/_/76cpjntt2l1bgmremihhnd1pko
<jam> natefinch: ^^
<jamespage> dimitern, hazmat: added and in trusty
<dimitern> jamespage, thanks
<jamespage> hazmat, urgh - just hit what might be a bug
<jamespage> maas environment, doing some weird stuff but...
 * hazmat waits for it
<jamespage> the machine agent is installing LXC
<jamespage> at the same time as hooks for the deployed service are trying to install update stuff
<jamespage> resulting in #bag
<jamespage> bang rather
<jamespage> hazmat, lxc gets installed late now
<hazmat> jamespage, hmm.. that shouldn't happen.. lxc should be getting installed if a container is being deployed..
<hazmat> jamespage, this with 1.16.6
<hazmat> ?
<jamespage> hazmat, no 1.17.4
<jamespage> it was OK on 1.16.6
<jamespage> I'm using a mix of lxc containers and stuff running directly on host
<hazmat> jamespage, ah.. so you do have container scheduled but its executing/being created at the same time as hooks, runtime pkg install needs to be serialized with hook execution to avoid blow up.
<jamespage> hazmat, yah
<jamespage> hazmat, its actually just the install install of lxc that's conflicting
<jamespage> hazmat, I'll raise a bug
<cjohnston> rogpeppe: pong
<rogpeppe> cjohnston: apparently canonistack is in a bad way currently - do you think it might be possible to reproduce the bug (#1284183) on some other provider?
<_mup_> Bug #1284183: jujuclient.EnvError: <Env Error - Details:  {   u'Error': u'watcher was stopped', u'RequestId': 9, u'Response': {   }} <api> <status> <juju-core:Triaged> <https://launchpad.net/bugs/1284183>
<cjohnston> rogpeppe: I can reproduce in HP
<rogpeppe> cjohnston: would the repro instructions be the same for HP ?
<cjohnston> rogpeppe: skip the sshuttle part...
<rogpeppe> cjohnston: thanks
<cjohnston> and we pinned jujuclient yesterday, so you will need a slightly older code base
<cjohnston> let me figure out which revno
<cjohnston> rogpeppe: -r 311 should give it to you...
<rogpeppe> cjohnston: thanks
<jam> cjohnston: I'm trying to test your reproduction for bug #1284183, but it would seem I need a bit of config
<_mup_> Bug #1284183: jujuclient.EnvError: <Env Error - Details:  {   u'Error': u'watcher was stopped', u'RequestId': 9, u'Response': {   }} <api> <status> <juju-core:Triaged> <https://launchpad.net/bugs/1284183>
<jam> cjohnston: ERROR: Missing required environment variables:
<jam>   CI_LAUNCHPAD_USER
<jam>   CI_OAUTH_TOKEN
<jam>   OS_USERNAME
<jam>   CI_OAUTH_TOKEN_SECRET
<jam>   CI_OAUTH_CONSUMER_KEY
<jam> Please ensure the novarc file has been sourced.
<cjohnston> jam: ./create_lp_creds.py
<jam> cjohnston: how much access does it need?
<jam> change anything ?
<jam> (a bit scary to run your random scripts with full access to my LP account :)
<cjohnston> jam: we use it for uploading to a pa
<cjohnston> ppa
<cjohnston> you probably won't need much access since I doubt you are going to be actually playing with the system itself
<cjohnston> You may even be able to put in dummy info, I'm not sure.
<cjohnston> ev: ^
<cjohnston> OS_USERNAME would need to be valid tho
<jam> cjohnston: it also needs locally installed cheetah ?
<cjohnston> ack
<cjohnston> yes
<mattyw> rogpeppe, do you have a moment - just need you to double check a test for me
<rogpeppe> mattyw: np
<jam> cjohnston: apparently it also wants the rest of OS_AUTH_* stuff (is it running nova/swift directly)? but it doesn't preflight check them
<ev> jam: you can get away with feeding it largely bogus Launchpad credentials as the bug you'll hit happens during deployment - it doesn't validate the LP data until you try to do something with the instances.
<mattyw> rogpeppe, I made those changes we discussed with william on friday - including moving that error to the juju-core/errors package. now I get this error: http://paste.ubuntu.com/7038224/
<mattyw> I'm guessing that's expected and I just need to add errors to that list to make it pass - but thought I should check
<rogpeppe> mattyw: which package is failing there?
<mattyw> rogpeppe, juju-core/cmd
<rogpeppe> mattyw: ok, yeah, just add errors there
<jam> ev, cjohnston: you also need "import yaml" is this just "python-yaml" ?
<cjohnston> yes
<mattyw> rogpeppe, thanks very much
<rogpeppe> mattyw: np
<jam> cjohnston: and now websocket
<jam> cjohnston: well, python-websocket-client, but right now it has been running and seems to be happy on HP clound
<jam> cloud
<jam> cjohnston:  Service 'ci-juju-gui' does not need any more units added.
<cjohnston> that should be on 0
<jam> I do see:     agent-state-info: '(error: cannot get started instance: failed to get details
<jam>       for serverId: 3681019
<jam>       caused by: Maximum number of attempts (3) reached sending request to https://az-1.region-a.geo-1.compute.hpcloudsvc.com/v1.1/17031369947864/servers/3681019)'
<jam> in "juju status" though the script hasn't finished yte
<jam> cjohnston: I do see: "Connection Timeout: disconnecting client after 300.0 seconds" which IIRC is the message Bazaar gives when you've connected to Launchpad for more than 5 minutes without any actual requests (internally the bzr client *should* reconnect after that)
<cjohnston> ack
<jam> cjohnston: presumably we're stuck at " Waiting for units before adding relations" but that won't ever complete because of failures in provisioning due to rate limiting
<cjohnston> jam: which limiting
<jam> cjohnston: sorry, was out for lunch. HP cloud rate limiting how many requests you can send to Openstack (describe instances, start instance, etc)
<cjohnston> hrm. interesting
<ev> hazmat: shouldn't conn.connect take arguments in jujuclient? http://paste.ubuntu.com/7038687/
<ev> seems like that was always the case for websocket-client: https://github.com/liris/websocket-client/blame/master/websocket.py#L422
<sinzui> Hi natefinch I would like you to review my branch that changed the deps in the makefile.  https://codereview.appspot.com/71540043
<natefinch> sinzui: sure
<natefinch> sinzui: uh... looks good to me.  I'm going to trust that your regexes work correctly :)
<sinzui> natefinch, yeah, they were nasty to write. well it was the finding which packages are available that was hard. the regex was easy
<natefinch> sinzui: yeah, that's generally my experience with regexes too
<rogpeppe> cjohnston: i think i might have a solution to the issue
<hazmat> ev.. ugh
<hazmat> k
<hazmat> ev.. got a new toy to show..
<ev> yay!
<ev> what is it?
<hazmat> ev, introspection
<hazmat> ev, okay back to the fubar
<ev> oooh, nice!
<natefinch> mgz: not rushing you, just planning next steps - how's the bot looking?
<mgz> natefinch: I'm deploying some things now
<natefinch> mgz: cool
<sinzui> mgz, you are replacing the lander?
<mgz> mgz: our current one got screwed, I'm just putting it back up as a stopgap
<natefinch> sinzui: yeah, the last one blew up
<mgz> *sinzui
<mgz> I don't need to be telling myself...
<sinzui> I saw. jcsackett confirmed that the charmworld lander is fully operational. I can offer you that jenkin's based lander if canonistack has issues
<sinzui> mgz, the juju qa team can always add a developer branch to Juju CI. We can add a separate job that does the proper merge too.
<sinzui> mgz, also, I shutdown all the Juju-CI instances in canonistack and stopped canonistack testing. I hope nova is happy that we left
<mgz> sinzui: ooo
<mgz> sinzui: I think for now I'll try this, as I want to do some experimenting with how our tests get run to deal with flakiness/isolation
<mgz> but moving to jenkins sounds like a good plan
<sinzui> mgz okay, since we are moving to git, I can help setup a jenkins instance when you are ready
<rogpeppe> natefinch: i think you need to push the changes to https://codereview.appspot.com/69600043/
<natefinch> rogpeppe: they were pushed but not proposed. I'm proposing
<voidspace> https://codereview.appspot.com/71490045
<rogpeppe> voidspace, wwitzel3: code.google.com/p/go.tools/cmd/oracle
<rogpeppe> oops
<rogpeppe> voidspace, wwitzel3: http://godoc.org/github.com/fzipp/pythia
<voidspace> thanks
<rogpeppe> voidspace: lp:~rogpeppe/juju-core/511-instancepoller-aggregate
<mgz> soooo.... the bot was up briefly, but is no longer
<mgz> I shall redo later
<natefinch> mgz: dang.  Good luck.
<thumper> o/ natefinch
<waigani> thumper: https://btrfs.wiki.kernel.org/index.php/FAQ#Why_does_df_show_incorrect_free_space_for_my_RAID_volume.3F
<thumper> o/ wallyworld_
<wallyworld_> hi
 * wallyworld_ is inhaling caffeine
<waigani> morning all :)
<cjohnston> hazmat: any idea about: http://paste.ubuntu.com/7040757/ ?
<davecheney> thumper: ping
<davecheney> is now a good time for a chat ?
<thumper> I have waigani here, but other than that, yes
<davecheney> this is about the gccgo stuff
<davecheney> i don't think it's private
<davecheney> i'd like to strike while the iron is hot
<thumper> kk
 * thumper just did "juju add-unit -n50 ubuntu"
<thumper> on the local provider
<thumper> cpu approaching 100%
<davecheney> nice computer you had there
<davecheney> shame if anything happened to it
<thumper> I'm testing btrfs cloning
<davecheney> thumper: just emailed you a url
<davecheney> see if that works
<thumper> almost all up
<davecheney> otherwise send me a hangout invite
<hazmat> cjohnston, yeah.. a foobar compounded by a ci branch with merge from ev that didn't fix the issue
<cjohnston> hazmat: I see.. any workaround?
<hazmat> cjohnston, yes.. in 3hrs.. post call and post customer check-in
<stokachu> hazmat: do you know when/if the decision has been made about the manual provider?
<hazmat> stokachu, no word.. the thread stopped, probably gotten taken to team hangouts..
<stokachu> ok ill bring it up tomorrow during cross team
<stokachu> we rely on it as well
<hazmat> stokachu, yeah.. that's a good spot for it.
<cjohnston> hazmat: ack
<bigjools> thumper: is there a bug anywhere about juju's LXCs in maas not having DNS entries?
<hazmat> thumper, do you know if axw's revno 2373 completes the automatic upgrade for rsyslog to tls when upgrading juju?
<hazmat> sinzui, are there any automated upgrade tests for stable (1.16) to dev (1.17)?
<sinzui> hazmat, yes, for each environment
<hazmat> sinzui, awesome
<wallyworld_> hazmat: yes, the rsyslog upgrade will do the tls stuff
<hazmat> wallyworld_, thanks
<wallyworld_> np
#juju-dev 2014-03-06
<davecheney> thumper: wallyworld_ axwalk (absent): trying to get you ppc testing resources asap
<wallyworld_> oh?
<wallyworld_> we doing some ppc work?
<davecheney> wallyworld_: yes, it turns out I know things that you don't know (yet)
<wallyworld_> that wouldn't be hard to do
<thumper> wallyworld_: oh hai
<wallyworld_> yello
 * thumper is munching
<thumper> wallyworld_: you'll get all the goss at our meeting
<waigani> wallyworld_: can I pick your brain? I'm finding it hard to understand TestWatchEnvironConfig in state_test.go
<wallyworld_> ok
<waigani> might be easier via a hangout, but I'll try via irc first
<waigani> It sets "default-series" to "another-series" and then uses s.State.WatchEnvironConfig to grab the config object.
 * wallyworld_ looks
<waigani> then it tests to that the change DID NOT take effect
<waigani> this fails as it did take effect, as would be expected
<wallyworld_> WatchEnvironConfig doesn't get the config, it gets a watchr
<waigani> so then, I changed the test to assert that the change did take place and that failed too
<wallyworld_> s.State.EnvironConfig() gets the config
<waigani> yep
<wallyworld_> you said above it got a config object
<wallyworld_> i just wanted to clarify :-)
<waigani> so WatchEnvironConfig returns 'got'
<waigani> which is the (changed?) config
<waigani> it then compairs that against state:
<waigani> c.Assert(got.AllAttrs(), gc.DeepEquals, cfg.AllAttrs())
<wallyworld_> no, w.Changes() returns goy
<wallyworld_> got
<wallyworld_> w := s.State.WatchEnvironConfig() returns a watcher
<waigani> sorry, yes the point is the same though
<wallyworld_> sort of
<waigani> so Changes returns a changed config object right?
<waigani> *w.Changes()
<wallyworld_> yes, in this case i think so. it doesn;t always, it depends on the watcher. sometimes it returns an empty struct. let me check
<waigani> so why would the test want to assert that there was no change by compairing the changed cfg with state cfg?!?
<wallyworld_> it doesn't
<wallyworld_> the assertNoChange method is different
<wallyworld_> 		case got := <-w.Changes():
<wallyworld_> 			c.Fatalf("got unexpected change: %#v", got)
<waigani> I'm talking about the c.Assert(got.AllAttrs(), gc.DeepEquals, cfg.AllAttrs()) line
<wallyworld_> is the no change check
<wallyworld_> that's for testing changes, not no changes
<wallyworld_> you said "no change"
<waigani> it fails because the changed cfg != state cfg
<wallyworld_> in which case the changes haven't been applied
<waigani> but they have and it fails
<wallyworld_> and/or sent in the event
<wallyworld_> you have some code I can look at?
<waigani> yep
<waigani> umm, should I put a comment next to this test, finish my branch and propose it (even though it has failing tests?)
<wallyworld_> you can create a wip merge  proposal
<wallyworld_> and ask me to look at that
<waigani> oh, okay
<wallyworld_> use the -wip option for lbox i think
<wallyworld_> don't worry about finishing anything, just propose
<wallyworld_> and i can easily see the current state of it
<waigani> yeah? Okay
<wallyworld_> although i have a meeting in 8 minutes
<waigani> oh, well, shall we aim for after our standup?
<wallyworld_> because it is wip, it won't be marked as ready for review
<wallyworld_> after standup works
<waigani> great, thanks :)
<wallyworld_> propose whenever though and i might get to see if before standup
<waigani> wallyworld_: could you please take a look at TestEnvironConfigWithoutAgentVersion ( you can now set an agent version - to allow upgrades) and TestWatchEnvironConfig.
<wallyworld_> ok
<waigani> wallyworld_: thank you :)
<wallyworld_> waigani: i can't see TestEnvironConfigWithoutAgentVersion in the diff
<wallyworld_> what file is it in?
<wallyworld_> waigani: hi, you back? i can't see TestEnvironConfigWithoutAgentVersion in the diff. what file is it in?
<waigani> wallyworld_: go/src/launchpad.net/juju-core/state/initialize_test.go
<wallyworld_> oh, i was looking in the diff
<wallyworld_> so that is an existing test. does it fail?
<waigani> wallyworld_: yep - I was just writing that
<wallyworld_> where does it fail?
<waigani> wallyworld_:
<waigani> initialize_test.go:142:
<waigani>     c.Assert(err, gc.ErrorMatches, "agent-version must always be set in state")
<waigani> ... value = nil
<waigani> ... regex string = "agent-version must always be set in state"
<waigani> ... Error value is nil
<waigani> i.e. you can no set the agent-version
<wallyworld_> that test is checking that there's an error if agent-version attempts to be deleted
<wallyworld_> so i would expect the test to still pass?
<wallyworld_> ie that it is failing is a problem
<waigani> there are two parts arn't there? I think just the second part fails
<waigani> where it says something about setting a bad version
<waigani> line 138
<axw> there's two tests in there: initialise with missing agent-version should fail, initialise with agent-version and try to delete it should fail
<wallyworld_> the line numbers are different for you vs me, but i think i see where you mean now
<axw> waigani: link to the CL please?
<waigani> axw: ah thanks
<wallyworld_> waigani: i'm not seeing what your question is
<wallyworld_> the test as written is fine
<axw> waigani: if I were a guessing man, I'd say something happened to checkEnvironConfig in your CL
<waigani> axw: https://codereview.appspot.com/70190050/
<waigani> wallyworld_: axw's outline of the intention of the tests is what I was after
<wallyworld_> oh
<wallyworld_> sorry
<wallyworld_> i thought you were asking something else
<waigani> np, they are failing, so I just needed to understand what the expected / correct behaviour was
<wallyworld_> in that case what andrew says is correct
<waigani> so I can see if 1. tests need to change or 2. my code needs to change
<waigani> and it looks like it is no. 2
<wallyworld_> yeah, in this case
<wallyworld_> i misunderstood what you were after
<waigani> no no, all good. Thanks for taking the time :)
<wallyworld_> well, i didn't help, so no need to thank me :-)
<wallyworld_> i think you should ave said "thanks for nothing" :-)
<waigani> lol
<waigani> axw: the main business logic is in state/state.go
<axw> yep, looking now
<waigani> I'm still polishing tests etc but the general gist is there
<waigani> ah, my girl just jumped off the ice - I'll be back online tonight
<axw> eep. later
<bigjools> wallyworld_: ping
<bigjools> wallyworld_: unping
<waigani> axw: thanks for the review. It all makes sense and I agree.
<axw> waigani: cool, no worries
<waigani> thumper and I looked at ChangeEnvironConfig today and we both thought it could go
<rogpeppe> fwereade:  https://codereview.appspot.com/69600043/
<voidspace> https://codereview.appspot.com/71490045
<dimitern> voidspace, description please?
<natefinch> morning all
<mgz> morning nate!
<mgz> join the weekly hangout?
<natefinch> mgz: thanks
<axw> wallyworld_: joining?
<mgz> https://bugs.launchpad.net/juju-core/+bugs?field.tag=regression
<mgz> https://launchpad.net/juju-core/+milestone/1.17.5
<mgz> https://launchpad.net/juju-core/+milestone/1.18.0
<wallyworld_> fwereade: i'd like you to look at these because there's a subtle assumption about how major upgrade version is determined https://codereview.appspot.com/69890053/ https://codereview.appspot.com/71920043/
<voidspace> dimitern: do you mean on the code review or somewhere else?
<dimitern> voidspace, on the code review yeah (or CL as it's usually referred to)
<voidspace> dimitern: what does CL stand for?
<dimitern> voidspace, that's a good question - commit .. something change log perhaps?
<voidspace> dimitern: heh, ok - thanks
<wallyworld_> axw: i forgot to ask - i think there may be some deprecated config options now that the storage stuff has been removed? eg share-storage-port?
<waigani> axw: can I run something past you?
<jam> axw: did you get a chance to look at https://bugs.launchpad.net/ubuntu/+source/juju-core/+bug/1284127 ?
<rogpeppe> voidspace: http://godoc.org/github.com/juju/ratelimit
<voidspace> rogpeppe: thanks
<voidspace> dimitern: https://codereview.appspot.com/71490045
<dimitern> voidspace, you've got a review
<axw> wallyworld_: shared-storage-port can be deleted
<axw> waigani: you can, but I'm making and about to eat dinner
<axw> jam: was just about to
<wallyworld_> axw: ok, i'll add it to the upgrader. anything else?
<axw> wallyworld_: not that I can think of
<wallyworld_> ok, ta
<waigani> axw: ok, feel free to answer tomorrow but here is the question
<waigani> in firewaller_test.go setGlobalMode rog (rogpeppe?) has a TODO that it should not be possible to set the firewalling mode after an environment has been bootstrapped
<waigani> that TODO is now done. The validation in State does not allow it.
<waigani> now, there are a bunch of tests in firewaller_test.go that start by calling setGlobalMode
<waigani> so is there a valid way to setGlobalMode or do I delete all the tests that relied on that setting? The latter seems drastic and I don't understand the details of the tests to feel confident doing so.
<natefinch> rogpeppe: you need to update the readme on ratelimit
<waigani> axw: ^ (and enjoy your dinner)
<axw> waigani: thanks, will take a look after dinner.
<waigani> Good luck 1.8 sprinters!
<axw> jam: I've updated the bug, we can just close it. not sure what status to give it... can you please take a look when you have a moment?
<axw> jam: re sshstorage, we don't necessarily need to create the temp dir the same, but it should ideally ignore the .tmp that filestorage creates
<natefinch> rogpeppe: ratelimit also needs a license file
<jam> axw: so the list get/put stuff is pretty superfluous to be honest. List() doesn't list dirs anyway, so we don't accidentally walk there
<jam> axw: so, I'm pretty sure my trapping of .tmp is pretty "we don't actually need to do this because it isn't exposed already". Do you feel its really worth following up on?
<jam> (as in, someone knowing the secrets might be able to see a file that was in progress before it finished the atomic put, but it doesn't seem to actually leak anything)
<axw> jam: yeah I suppose so, I'm being a bit anal. ignore that then - I will have a look at your updates after dinner
<jam> axw: thanks
<dimitern> rogpeppe, https://codereview.appspot.com/70010045/
<bloodearnest> hazmat: playing again wuth juju-lxc, installed git and cpu-checker on the base img, but still fail to come up, get this in the lxc logs:
<bloodearnest> lxc-start 1393886691.822 ERROR    lxc_cgfs - Device or resource busy - failed to set memory.use_hierarchy to 1; continuing
<cjohnston> rogpeppe: mornin.. what ever happened with the solution you thought that you had for the watcher bug?
<rogpeppe> cjohnston: i hope to have something done today - it requires setting up something to poll the connection, so it's not totally trivial
<cjohnston> rogpeppe: ack
<hazmat> bloodearnest, haven't seen that before
<bloodearnest> hazmat: ack, will keep digging
<hazmat> bloodearnest, i'd raise that hallyn or stgraber on #ubuntu-server
<hazmat> raise that to
<bloodearnest> hazmat: yep, digging a little more first
<jam> natefinch: sorry if I DC'd, I accidentally hit the turn-off-wireless when looking for the "turn-on-monitor" button
<natefinch> jam: heh no problem
<natefinch> mgz: lp:~natefinch/juju-core/037-EnsureMongo
<natefinch> mgz: I need to push up one more change.... evidently missed updating a test.  won't take long.
<dimitern> fwereade, https://codereview.appspot.com/70010045/diff/20001/worker/deployer/simple.go?column_width=80
<natefinch> mgz: fixed the test.  My test run looks pretty good, just mongo tests that are failing that always fail for me, so it's probably fine to merge.
<mgz> natefinch: ta
<natefinch> mgz: no, thank you.
<dimitern> rogpeppe, https://codereview.appspot.com/70010045/
<fwereade> voidspace, would you take a look at https://codereview.appspot.com/71920043/ please? looks like it may conflict
<voidspace> fwereade: looking
<mramm2> anybody from core available for the cross team meeting?
<fwereade> mramm2, arrgh, might be tricky to find a room
<fwereade> natefinch, would you represent us please?
<natefinch> fwereade: was just going to offer
<mramm2> I need answers from you guys
<mramm2> like when will we get 1.18
<natefinch> mramm2, fwereade:  not sure I'll have all the answers
<mramm2> natefinch: can you join anyway?
<natefinch> mramm2: certainly
<natefinch> mramm2: link?
<natefinch> fwereade: I can just ask you to feed me answers ;)
<fwereade> mramm2, natefinch: I *think* we're on track for 1.18 tomorrow
<fwereade> mramm2, natefinch: it remains our highest priority
<mramm2> fwereade: awesome
<mramm2> fwereade: are you planning to break manual bootstrap for 1.18?
<fwereade> mramm2, we are not
<mramm2> cool!
<mramm2> great!
<fwereade> mramm2, agreed with abentley that a warning when we bootstrap using config from a .jenv is sufficient mitigation
<mramm2> cool!
<mgz> https://projects.puppetlabs.com/issues/1848 go \n
<voidspace> anyone able to give [yet another] final look over at: https://codereview.appspot.com/71490045/
<jam> mramm2: did you seem my request for wwitzel3 to get a Kanban account? mfoord already has one, but we'll need to plan some capacity around new hires
<mramm2> I added wayne to kanban
<mramm2> but for some reason haven't been able to get the add users to board screen to load
<mramm2> so have not yet given him permissions on the core board
<mramm2> and now he has board access
<mramm2> also RE steve gorge's query LKK is managed by Nick Tait
<mramm2> can you make sure jam sees that the LeanKitKanban admin is Nick Tait?
<mramm2> (in the main juju channel)
<natefinch> mramm2: I'll make sure he sees it
<mramm2> cool
<mramm2> I meant to type that in another window...
<mramm2> talking to too many people at once!
<dimitern> rogpeppe, updated https://codereview.appspot.com/70010045
<rogpeppe> dimitern: https://bugs.launchpad.net/juju-core/+bug/1284183
<_mup_> Bug #1284183: jujuclient.EnvError: <Env Error - Details:  {   u'Error': u'watcher was stopped', u'RequestId': 9, u'Response': {   }} <api> <status> <juju-core:Triaged> <https://launchpad.net/bugs/1284183>
<mgz> natefinch: you appear to have a text conflict in your branch, otherwise you'd be my guinea pig
<natefinch> mgz: I saw, working on it.  Getting test failures after I fix the conflict and trying to figure out why
<sinzui> Hi natefinch . I have a branch that addresses some of my incompetence and naivety. Do you have an few minutes to review it and check my thinking? https://codereview.appspot.com/72100043
<natefinch> sinzui: I didn't realize you could fix that with code ;)
<fwereade> dimitern, frankban, if you have a moment would you please take a quick look at https://codereview.appspot.com/49960047/ ? most has already been reviewed, but I hit some of the api server stuff
<dimitern> fwereade, looking
<sinzui> oh dear. natefinch I think I need to understand this bug. https://bugs.launchpad.net/juju-core/+bug/1288873 . We compile a 32bit juju client on a 64bit 2012 Windows server. We install it on the same machine. Is win7+64bit unable to install 32bit?
<_mup_> Bug #1288873: Installing juju windows binarys fails on windows 7 <windows> <juju-core:New> <https://launchpad.net/bugs/1288873>
<natefinch> sinzui: looking
<natefinch> sinzui: 32 bit binaries should work regardless of the bitness of the OS they're built on
<natefinch> sinzui: and 32 bit will work on 32 or 64 bit windows
<sinzui> It certainly does on win 2012 server
<sinzui> I will start a win7 64 bit instance and try the install.
<natefinch> sinzui: the error message could be a red herring.  Windows isn't exactly known for being terribly accurate with its messages
<frankban> fwereade: looking
<natefinch> sinzui: makefile changes reviewed btw
<sinzui> thank you natefinch
<mgz> sinzui: I killed the bot merge, am still playing
<sinzui> mgz, understood
<dimitern> fwereade, reviewed
<mgz> natefinch: I want to land you branch, but it still seems to have conflicts
<mgz> (possibly not your fault, things have been landing)
<mgz> natefinch: either way, the bot is up so you should be able to just set the approved bit when ready
<wallyworld> sinzui: hiya
<sinzui> hi wallyworld
<wallyworld> sinzui: do you have joyent creds you can share with me so i can help diagnose a live test failure?
<natefinch> just take it, you stupid bot
 * thumper is now confused as to how to add a dependency to the bot
<wallyworld_> thumper: for now, the bot doesn't read the dependencies file - you need to do it by hand
<wallyworld_> if i recall correctly
<thumper> the email from mgz said that it can be done by config
<thumper> but I didn't find it clear
<wallyworld_> oh, i haven't read that fully yet - you used to have to do it by hand
<thumper> gah...
<thumper> I need to start landing shit
 * thumper just racks up some dependent branches
<waigani> thanks for nothing
<thumper> waigani: eh?
<waigani> thumper: I was trying to find a conversation between wallyworld_axw and I yesterday. My keyword search was "thanks for nothing", but I put it into the wrong box!
<thumper> haha
<waigani> yeah, lol
<waigani> just randomly being rude on IRC, you know me (sigh)
<waigani> thumper: do you know what time axw comes on? I've got a few questions for him.
<thumper> waigani: normally around 2pm our time
<waigani> oh, that late. Can I run the question past you?
<thumper> sure
<waigani> http://pastebin.ubuntu.com/7046704/
<waigani> line 13
<waigani> as there is no policy, there is no validation and agent-version can be reset
<waigani> ah no, ignore me. It should be deleting the agent-version that fails. I'll update test.
<thumper> pleased to be of service :)
<waigani> thanks for nothing ;)
<thumper> waigani: sorry, no idea on your stuckness
<waigani> thumper: :(
<waigani> thumper: I've got a bunch of other tests to fix while I wait for axw, thanks for taking a look
 * thumper nods
#juju-dev 2014-03-07
 * thumper sighs
<thumper> why oh why is the bot fubared
<davecheney> wallyworld_: thumper sinzui axw https://docs.google.com/a/canonical.com/document/d/1m9R2n6LPLNLGjdopcNkQYVG8D5V4FTyvc1vvn-9ZifM/edit#
<wallyworld_> davecheney: thanks, will look
<thumper> davecheney: ta
<wallyworld_> thumper: bot is farked because or a tarmac issue
<wallyworld_> i think
<thumper> :(
<wallyworld_> it has merged 4 branches to it's local tree but not pushed to lp
<wallyworld_> i'm trying to see if those branches actually passed the tests
<thumper> haha
<wallyworld_> if so, i can push manually
<wallyworld_> thumper: ffs.
<wallyworld_> 2014-03-06 18:39:30 WARNING  ConnectionReset calling 'Branch.last_revision_info', retrying
<wallyworld_> 2014-03-06 18:39:32 WARNING  ConnectionReset calling 'Branch.last_revision_info', retrying
<wallyworld_> 2014-03-06 18:39:35 INFO     Committing to: /home/tarmac/trees/src/launchpad.net/juju-core/
<wallyworld_> so if it can't push to lp, it gives up and just merges locally
<wallyworld_> which results in complaining ever after
<thumper> can the machine see launchpad?
<thumper> hang on
<thumper> it must be able to
<wallyworld_> it can and has - i think those are transient
<thumper> otherwise it wouldn't merge...
<wallyworld_> yep
<wallyworld_> so transient errors = it's all broken
<thumper> gah
<wallyworld_> i'll look for the branches that have passed testing in the log file and push those manually
<thumper> wallyworld_: while you're in there
<wallyworld_> that's what she said
<thumper> wallyworld_: want to 'go get github.com/juju/loggo' ?
<wallyworld_> sure
<thumper> ta
<thumper> wallyworld_: so since it failed once, it no longer tried to push to lp?
<wallyworld_> yep :-(
<wallyworld_> i had to push manually
<wallyworld_> there were 5 i think
<bodie_> trying to take a crack at fixing a few small bugs to get my head in the game with Go -- one problem, i'm not sure which part of the codebase this refers to on Github
<bodie_> https://bugs.launchpad.net/juju-core/+bug/1217868
<_mup_> Bug #1217868: move from state.D to bson.D <hours> <tech-debt> <juju-core:Triaged> <https://launchpad.net/bugs/1217868>
<bodie_> it says juju-core, but i'm not seeing a juju-core repo
<thumper> bodie_: juju-core is still on launchpad
<bodie_> is there a doc that explains how things are put together?
<bodie_> ah
<thumper> go get launchpad.net/juju-core/...
<bodie_> alrighty
<thumper> wallyworld_: I have a physio appt during our standup
<thumper> wallyworld_: when do you need to finish today?
<wallyworld_> around 3pm
<wallyworld_> thumper: when does your appt finish? we can just delay the standup
<thumper> I should be back just after 3pm my time
<thumper> noon your time
<waigani> that suits me, I've got a school thing at 2pm
<wallyworld_> ok, so let's delay by 30 mins then
<waigani> wallyworld_: sent you an email.
<wallyworld_> waigani: changing writeSampleConfig by itself is not sufficient - i was just point out where the config is used
<wallyworld_> you need to add a method to optionally add to the sample config
<wallyworld_> do this during set up
<waigani> wallyworld_: right, thought so
<wallyworld_> and have writeSampleConfig use that
<thumper> wallyworld_: perhaps by 45 minutes
<thumper> as I need to get home
<wallyworld_> sure
<waigani> axw: man of the moment! Sorry for spamming your inbox
 * axw opens inbox
<wallyworld_> thumper: btw, i can see the bot landing your latest branch
<wallyworld_> running tests i mean
<wallyworld_> axw: waigani: standup will be delayed while thumper gets repaired. approx 45 minutes
<axw> hehe. no worries
<thumper> wallyworld_: ok, cool
<thumper> wallyworld_: we'll see if it pushes when done
<wallyworld_> yeah
<axw> waigani: re "do you think it is worth while making the validation optional but on by default in UpdateEnvironConfig" -- yes, it is already optional, by opening state with a nil policy
<waigani> axw: haha, point taken
<waigani> wallyworld_: okay 3:15. My girl asked me to watch her at assembly which is on now. So that works well.
<wallyworld_> cool :-)
<axw> waigani: first, when reopening don't use Initialize, use "Open". second, if you follow through to JujuConnSuite you can see how it opens a state connection. It uses juju.NewConn, passing in the environ
<axw> waigani: take a look in juju/conn.go to see what NewConn does, and how it opens a state conn
<axw> waigani: you can then do something similar in your test, but pass nil in as the policy
<thumper> wallyworld_: is the bot finished?
 * thumper doesn't see a push
 * wallyworld_ looks
<wallyworld_> thumper: looks like push to lp has failed again
<thumper> :(
<wallyworld_> thumper: i'll mention to martin
<thumper> does the bot have a ssh key that lp knows about?
<wallyworld_> don't know, seems not i guess
<wallyworld_> actually
<thumper> wallyworld_: how are you pushing to lp from there?
<wallyworld_> it must have
<wallyworld_> cause i'm pushing from the bot
<wallyworld_> so it just may be a small setup issue
 * thumper joined standup hangout
<waigani_> axw: http://pastebin.ubuntu.com/7047615
<wallyworld_> axw: standup time :-)
<voidspace> https://code.launchpad.net/~rogpeppe/juju-core/511-instancepoller-aggregate/+merge/209505
<voidspace> wwitzel3: https://code.launchpad.net/~rogpeppe/juju-core/511-instancepoller-aggregate/+merge/209505
<voidspace> one time special offer
<voidspace> review our branch, again!
<voidspace> https://codereview.appspot.com/71490045/
<mgz> wwitzel3: https://code.google.com/p/irssi-libnotify/
<mgz> wwitzel3: it's a trap!
<natefinch> morning all
<wwitzel3> Morning natefinch
<wwitzel3> should we get the video online?
<natefinch> wwitzel3: yes please
<jam> natefinch: https://plus.google.com/hangouts/_/7acpj3k2j7gc114cifi39l6sf0
<rogpeppe> wwitzel3:  lp:~rogpeppe/juju-core/512-maas-bootstrap-bridge-utils
<rogpeppe> wwitzel3:  lp:~rogpeppe/juju-core/512-maas-bootstrap-bridge-utils
<voidspace> A long and difficult CL for someone
<voidspace> https://codereview.appspot.com/72450043
<jamespage> mgz, does this look familiar @ 1.17.4
<jamespage> unit-percona-cluster-6: 2014-03-07 11:51:52 ERROR juju runner.go:220 worker: exited "upgrader": cannot read tools metadata in tools directory: open /var/lib/juju/tools/1.17.4-trusty-amd64/downloaded-tools.txt: no such file or directory
<jamespage> I get that continually from all of my service units
<mgz> jamespage: bug 1285901
<_mup_> Bug #1285901: error starting unit upgrader on local provider <local-provider> <lxc> <regression> <juju-core:Fix Committed by wallyworld> <https://launchpad.net/bugs/1285901>
<jamespage> mgz,good oh
<jamespage> I'll stop making noise
<rogpeppe> voidspace: https://github.com/golang/lint
<fwereade> adeuring, basically LGTM, ping me if any of my suggestions are unclear
<fwereade> adeuring, oh! did we want handling for JUJU_TEST_MODE as well?
<adeuring> fwereade: what do you mean with "handling for JUJU_TEST_MODE"?
<fwereade> adeuring, actually forget I said anything
<adeuring> ;)
<fwereade> adeuring, it'll cause more problems than it solves
<cjohnston> dimitern: what version of jujuclient were you using yesterday when you deployed trying to reproduce our issue? I'm wondering if you had the newest version which I guess has a workaround for the issue
<dimitern> cjohnston, i'm using juju-core from trunk
<cjohnston> dimitern: client... jujuclient
<dimitern> cjohnston, i don't quite know what's jujuclient
<cjohnston> python-jujuclient ?
<dimitern> cjohnston, didn't have to install that
<cjohnston> we also started pinning a specific revno from trunk a couple days ago as a work around for this
<mgz> cjohnston: wat?
<mgz> why not just use one of the released 1.17 ones
<mgz> or are you talking about kapil's thing?
<cjohnston> not sure what kapil's thing is, but he has been helping us with this issue
<mgz> cjohnston: specifically, what do you mean by "jujuclient"?
<cjohnston> python-jujuclient
<cjohnston> AIUI it has a workaround for the api watcher issue we are hitting..
<cjohnston> ev, hazmat ^
<mgz> okay, so you are talking about kapil's thing
<hazmat> mgz, i had a workaround for the api server going awol and disconnecting all clients
<hazmat> in python jujuclient  so that it recovered for extant watches and reconnected and restablished the watch
<hazmat> mgz, i think the question is if the underlying issue of the api server going awol is addressed
<cjohnston> mgz: so I am trying to figure out how dimitern tested it, and it appears as though it would need to be retested without hazmat's workaround in order to try to reproduce..
<mgz> they've only given us steps to repo that include spinning up 15 manchines
<cjohnston> however we have a number of people on our team who have been hitting it
<mgz> so, dimitern has been struggling to actually get traction on it
<cjohnston> mgz: that's how we produce the error
<hazmat> mgz, specifically there's a log entry in syslog showing mongodb with no clients
<cjohnston> we don't have time right now to go look for other ways to produce it.. we have a deadline that we have to meet
<hazmat> cause of a client error from the api server, which then restarts the api server worker
<hazmat> mgz, cjohnston i also have no idea how to reproduce this.. it does seem more prevalent on canonistack..
<mgz> cjohnston: sure, I know you guys are pretty limited in what you can put in here
<jam> sinzui: bug #1289376   conversation should be here when you're around
<_mup_> Bug #1289376: Cannot build r2379 on amd64+precise <ci> <regression> <test-failure> <juju-core:Triaged> <https://launchpad.net/bugs/1289376>
<jam> sinzui: so certainly you should have been using newer golang
<jam> but the failures in that bug look exactly what I would expect if you tried to compile juju-core with go 1.0
<jam> (the default in precise)
<jam> sinzui: I'd be willing to help debug it with you
<sinzui> jam, I will look further...oh the makefile didn't exec and add the deps...
<sinzui> jam, I switched the rules to run tests since I saw failures everywhere...but I didn't switch back the to the makefile tests.
<sinzui> sorry
<jam> sinzui: no problem, I'm happy it was easy to fix :)
<jam> we'd love to get 1.17.5 today (as a potential 1.18 candidate) though things are looking pretty slim at this ponit
<jam> point
<jam> bug #1289316 is serious
<_mup_> Bug #1289316: lxc not installed from ubuntu-cloud.archive on precise <lxc> <maas> <precise> <regression> <juju-core:Triaged by wwitzel3> <https://launchpad.net/bugs/1289316>
<sinzui> jam, I will release 1.17.5 when CI blesses a recent rev. It is 7 revs behind as we did rapid landings.
<sinzui> jam, I will release over the weekend if I need to
<jam> sinzui: sure, just that if we don't have fixes like bug #1289316 landed, we can't make it 1.18 as it is regressed from 1.16, and arguably we shoudln't make it 1.17.5 either
<_mup_> Bug #1289316: lxc not installed from ubuntu-cloud.archive on precise <lxc> <maas> <precise> <regression> <juju-core:Triaged by wwitzel3> <https://launchpad.net/bugs/1289316>
<sinzui> jam, noted
<jam> sinzui: I'll hopefully have a short list for you as I uncover things, and target them to 1.17.5 as Critical, will that help you ?
<jam> sinzui: or would you prefer a different way of indicating blockers
<jam> ?
<sinzui> jam, sorry, distracted by meeting. I would love a list of blockers. we can target the bugs to 1.17.5 to be clear they need to be fixed in it
<sinzui> jam, https://launchpad.net/juju-core/+milestone/1.17.5 has a few bugs that stakeholders care about. We can push the off to the next release though since I can release every week
<mgz> jam: https://bugs.launchpad.net/juju-core/+bug/1288141
<jam> sinzui: did you start duping the bugs against https://bugs.launchpad.net/juju-core/+bug/1227450 ?
<jam> we have probably ~3 bugs I think that are related enough to be a dupe
<_mup_> Bug #1288141: Errors when a 1.17.4 unit is rebooted <landscape> <reboot> <regression> <juju-core:Triaged> <https://launchpad.net/bugs/1288141>
<_mup_> Bug #1227450: juju does not retry provisioning against transient provider errors <charmers> <landscape> <juju-core:Triaged> <https://launchpad.net/bugs/1227450>
<sinzui> jam, hazmat did with my blessing.
<sinzui> jam, looks like CI is catching up I see r2390 has started testing
<mgz> fwereade_, natefinch, jam: https://codereview.appspot.com/72310044
<natefinch> mgz LGTM'd.  Thanks.
<wwitzel3> mgz: https://codereview.appspot.com/72270044
<wwitzel3> also dimitern ^
#juju-dev 2014-03-08
<ev> is the local provider meant to respect default-series? I can't seem to get it to pick anything but what I'm running in the host
<ev> ah, just caught that the bootstrap node stays on the host series in the local provider (https://launchpad.net/juju-core/trunk/1.11.3). Can that get added to the docs?
<ev> https://juju.ubuntu.com/docs/config-LXC.html that is
#juju-dev 2014-03-09
<thumper> fwereade: hey there
<fwereade> thumper, hey dude
<thumper> fwereade: miss our chat time?
<fwereade> thumper, sorry, I had a phone alarm in the wrong timezone
<thumper> haha
<thumper> want to catch up now?
<fwereade> thumper, I'm in the hangout
<fwereade> brb irc
<thumper> fwereade: if you get bored: https://code.launchpad.net/~thumper/golxc/clone/+merge/209790
#juju-dev 2015-03-02
<cherylj> davecheney: thanks!
<waigani> thumper: do you also not want the username quoted in the error returned by the apiserver?
<thumper> I think quoted is fine from the api server as it is developer facing
<waigani> thumper: yep, wrote too quickly - I see we use %q in the rest of the errors in that package
<thumper> wine time
<waigani> wallyworld: thanks for the review. I've responded to your comments, but can't seem to update my diff.
<wallyworld> waigani: i saw the replies, so marked at +1
<waigani> wallyworld: okay thanks
<wallyworld> np
<wallyworld> dimitern: heya
<dimitern> wallyworld, morning
<wallyworld> god weekend? i hope you gots sleep :-)
<wallyworld> good
<dimitern> wallyworld, :) ~18h in total
<wallyworld> wow
<wallyworld> i have a question - kat finished some goamz signing work, and it's now merged. but it looks like stuff is missing in the v3 branch, i've done a pr  https://github.com/go-amz/amz/pull/33
<wallyworld> i'm testing the storage stuff live, but was wondering if you could test the network stuff as i don't have enough to go on with what to test
<dimitern> wallyworld, yeah - I was just looking at your two PRs in amz.v3 after v3-unstable was promoted to v3
<wallyworld> i've pull her juju-core branch to test juju live katco-:goamz-v3-support
<dimitern> wallyworld, I thought I *did* compare v2 to v3 to see if something was missing but apparently I missed something
<wallyworld> dimitern: stupid irc dropped out, not sure if i missed any reply
<dimitern> wallyworld, I was looking at https://github.com/go-amz/amz/compare/v1...v2 and https://github.com/go-amz/amz/compare/v2...v3
<wallyworld> yeah, the v2..v3 diff what what i based the pr on
<dimitern> wallyworld, but I can't see the changes in the PR to be missing from v3?
<wallyworld> hmm, maybe i had an out of date local copy
<wallyworld> let me check
<dimitern> wallyworld, that's might be - esp. if you're using symlinks in your gopath
<wallyworld> hmm, i just git pulled in my v3 master and no updates
<wallyworld> i'll look around a bit
<wallyworld> dimitern: so as an example, in https://github.com/go-amz/amz/tree/v3/ec2 there's no blockdevicemappings_test.go
<wallyworld> that file should be there and is in v2
<dimitern> wallyworld, thats true, but why it doesn't show up on the v2..v3 diff?
<dimitern> weird
<wallyworld> yeah, and there's a bunch of network stuff missing too
<dimitern> wallyworld, ok, I'll do the diff locally to be sure
<wallyworld> ok
<dimitern> wallyworld, apparently github compare lies
<wallyworld> there must be a logical reason you'd think
 * dimitern keeps digging 
<dimitern> wallyworld, for some reason even though v3 was branched off v2 some commits in v2 are missing
<wallyworld> dimitern: fwiw, with the go-amz branch in pr 33, the new juju storage stuff works live, and the unit tests pass. the networking stuff fails live for me because of vpc limits
<wallyworld> hmm
<dimitern> wallyworld, can connect to the ec2 web ui with the shared creds or you just have the api keys?
<wallyworld> i never use the web ui, just ElasticFox
<wallyworld> i have the api keys also for juju
<dimitern> wallyworld, you can clean up the stale vpc from there
<dimitern> wallyworld, if you have the account to login to the web ui can you send them to me by mail along with the api keys?
<wallyworld> ok, i'll see if i have it
<dimitern> wallyworld, in the PR #33 there are still some things missing from v2 btw
<wallyworld> ah, ok
<dimitern> wallyworld, but not much, so if you go ahead and merge that, I'll propose a follow-up to add the missing
<wallyworld> dimitern: ok. i have access to a web ui, using my canonical.com email as the user name, but it appears to be a different account to that controlled using the api keys i have and which i use with elastic fox
<wallyworld> dimitern: ok, that's merged
<dimitern> wallyworld, ok, I'll ask jam if he has them
<dimitern> wallyworld, thanks!
<wallyworld> dimitern: once your stuff lands, i'll update a fork of kath's branch i have and land that in core
<dimitern> wallyworld, ok, will let you know
<wallyworld> ok, i might duck off to have dinner
<Muntaner> good morning devs o/
<Muntaner> I'm writing my first charm and having some problems, can anybody help me?
<dimitern> Muntaner, morning! try asking in #juju
<dimitern> for all your charming needs :)
<Muntaner> dimitern, ty ;)
<TheMue> morning
<dooferlad> dimitern, TheMue: morning
<dimitern> TheMue, dooferlad, morning folks!
<TheMue> dooferlad: dimitern: o/
<dooferlad> dimitern: heard anything from voidspace?
<dimitern> dooferlad, he become a dad over the weekend
<dimitern> :)
<dooferlad> dimitern: awesome!
<TheMue> aaah, fantastic news
<dimitern> so I guess he won't be here today
<dimitern> yeah indeed :)
<dooferlad> indeed
<dimitern> I've seen pics on FB
<TheMue> oh, dedn't know he's on FB, so far only G+. while have a look
<TheMue> found and added him ;)
<jam> dimitern: sorry I misesd you earlier, just missed the schedule. what's up with ec2?
<jam> wallyworld: maybe you know?
<dimitern> jam, minor mishap with some missing commits from amz.v2 into amz.v3, but wallyworld sorted that out
<jam> dimitern: k, I thought there was something you needed w VPC
<dimitern> jam, I'm now manually comparing amz.v2 to the updated amz.v3 to make sure all is good, then I'll do a live test
<jam> dimitern: I do see a spare network interface in us-east-1
<dimitern> TheMue, sorry, I'll be 10m late for our 1:1
<TheMue> dimitern: ok
<dimitern> wallyworld, jam, I'm happy to report after that PR #33 landed amz.v3 has everything is needs wrt storage and networking
<dimitern> I'll still need to do a live test later though
<dimitern> TheMue, I'm in the hangout
<TheMue> dimitern: coming
<dimitern> axw, katco, jam, wallyworld, is anyone using the shared aws account for testing now?
<dimitern> I'm thinking of cleaning up the stale VPCs, subnets, security groups, etc.
<dimitern> unless anyone responds in the next half hour, I'll go ahead and do it
<perrito666> dimitern: for me go for it
<dimitern> perrito666, +1
<jam> dimitern: I'm using eu-west-1 for a live service
<jam> (my IRC proxy)
<jam> but nothing in US-east-1
<dimitern> jam, ok
<wallyworld> dimitern: sorry, had to go down to soccer at short notice
<dimitern> wallyworld, np. s'all good :)
<wallyworld> dimitern: once you're happy with goaws, I'll land a branch to update core
<dimitern> wallyworld, I still need to do a live test, so I'll let you know; but looking at the code it should work
<wallyworld> ok, sounds good
<wallyworld> i did a storage live test and it was good too
<dimitern> wallyworld, cool!
<perrito666> morning
<dimitern> FYI all leftovers in the shared aws account where cleaned up for all regions (jam's instance is unaffected ofc)
<dimitern> we should have a script to do that
<TheMue> perrito666: o/
<dooferlad> dimitern: hangout?
<dimitern> dooferlad, omw, sorry
<dooferlad> dimitern: no worries!
<dimitern> dooferlad, i'm in the hangout btw
<mup> Bug #1427204 was filed: systemd service tests map ordering failures <ci> <regression> <test-failure> <juju-core:Triaged> <https://launchpad.net/bugs/1427204>
<mup> Bug #1427210 was filed: 'relative path in ExecStart not valid' vivid local deploy failure <ci> <regression> <juju-core:Triaged> <https://launchpad.net/bugs/1427210>
<mgz> I have filed that one as a blocker, not the map ordering test failures though
<mgz> will poke eric when he's on about 'em
<dimitern> dooferlad, ping
<dooferlad> dimitern: hi
<dimitern> dooferlad, I knew it there will be a ci bug reported for that map ordering thing ^^
<dimitern> dooferlad, how's that going ?
<dooferlad> dimitern: it is happening...
<dimitern> dooferlad, did you file a bug? that 1427204 one above should be a duplicate of yours
<dooferlad> dimitern: I did.
<dooferlad> https://bugs.launchpad.net/juju/+bug/1427149
<mup> Bug #1427149: Tests require predictable map ordering <pyjuju:New for dooferlad> <https://launchpad.net/bugs/1427149>
<dooferlad> bother, wrong project
<mup> Bug #1427149 was filed: Tests require predictable map ordering <juju-core:New for dooferlad> <https://launchpad.net/bugs/1427149>
<dimitern> dooferlad, it's the right one I think
<dooferlad> dimitern: it is now.
<mup> Bug #1427204 changed: systemd service tests map ordering failures <ci> <regression> <test-failure> <juju-core:Triaged> <https://launchpad.net/bugs/1427204>
<dimitern> dooferlad, ah, ok
<dimitern> mgz, dooferlad is already on the map ordering one, so I'll mark the 1427204 as dupe
<dooferlad> dimitern: already have
<dimitern> dooferlad, yeah, I was just about to say that :)
<mgz> ah, pyjuju, is why I didn't see it
<dimitern> TheMue, you have a review btw
<TheMue> dimitern: great, thank you
<mgz> dooferlad: forgot to check with you, you also get the four failures in service/systemd right? the StubCall one is a bit hard to parse but I assume is also map-related rather than something else
<dooferlad> mgz: yes
<dimitern> axw, are you there by any chance?
<dimitern> wallyworld__, ping
<wallyworld__> yo
<dimitern> wallyworld__, so the goamz live tests pass (so far) except for this - http://paste.ubuntu.com/10501880/
<dimitern> wallyworld__, which looks like the check needs .* before and after
<wallyworld__> hmmm, ok, i thought it passed before, maybe not
<dimitern> wallyworld__, but the networking stuff seems unbroken
<wallyworld__> so do you have any pending changes to commit to goamz?
<dimitern> wallyworld__, not right now (I have some I'll do later, but not code related)
<wallyworld__> ok, i'll fix that test
<dimitern> wallyworld__, cheers
<wallyworld__> dimitern: i just ran that test with --amazon and it passed for me
<wallyworld__> maybe it fails when run with other tests
<dimitern> wallyworld__, "--" instead of "-" ?
<wallyworld__> it complained tht it wanted ec creds
<wallyworld__> let me try again
<dimitern> wallyworld__, it should take a few minutes - if it passes in a few seconds only the local live tests were run
<wallyworld__> even for one test
<wallyworld__> maybe gocheck.f messes with the flag
<dimitern> depends on the test
<dimitern> it shouldn't
<wallyworld__> i ran go test -gocheck.f TestBlockDeviceMappings  -amazon
<wallyworld__> maybe -amazon needs to be first
<wallyworld__> still passes
<dimitern> I run go test -check.v -check.f TestBlockDeviceMappings -amazon and it passed
<wallyworld__> ok, trying ./...
<dimitern> so it could be flaky
<wallyworld__> dimitern: i got 5 vpc related failures but no block ones
<wallyworld__> so yeah, looks flakey
<dimitern> wallyworld__, I'll have a look
<wallyworld__> dimitern: i think though the latest goamz rev is good to use with juju core
<dimitern> wallyworld__, I agree
<wallyworld__> dimitern: this should do it - it's what i've tested live juju deployments with http://reviews.vapour.ws/r/1046/
<rick_h_> dimitern: just heads up https://bugs.launchpad.net/juju-deployer/+bug/1421315 confirms it's between beta 3 and 4
<mup> Bug #1421315: subordinate service not appearing in watch output <oil> <juju-core:Triaged> <juju-deployer:Triaged by hazmat> <https://launchpad.net/bugs/1421315>
<dimitern> rick_h_, good to know - it makes it easier to track, thanks
<rick_h_> sinzui: can we get ^ marked as a beta regression then and a blocker for release?
<sinzui> rick_h_, you mean 1.22-beta4 is broken and we need a 1.22-beta5
<hazmat> sinzui: yes
<sinzui> thank you
<rick_h_> sinzui: yes please
<rick_h_> sinzui: and we can help QA and verify that beta5 fixes the issue before release
<rick_h_> sinzui: vs the current medium status on the bug
<hazmat> sinzui: any public info i can watch to track the status of deployer in core qa?
<sinzui> hazmat, no, sorry, but after my meeting, I will be able to report where we are with deployer revision testing
<hazmat> sinzui: thanks
<wallyworld__> dimitern: i need sleep, if you are happy with the goamz update to core, can you $$merge$$ it for me?
<dimitern> wallyworld__, will do, np
<wallyworld__> ty
<dimitern> ericsnow, hey
<dimitern> ericsnow, can you take care of this bug please? https://bugs.launchpad.net/juju-core/+bug/1427210
<mup> Bug #1427210: 'relative path in ExecStart not valid' vivid local deploy failure <ci> <local-provider> <lxc> <regression> <juju-core:Triaged> <https://launchpad.net/bugs/1427210>
<ericsnow> dimitern: yep
<ericsnow> dimitern: first on my list :)
<dimitern> ericsnow, cheers :)
<ericsnow> perrito666: standup?
<dimitern> ericsnow, the other one - with the map ordering dooferlad is already fixing and I asked him to check in with you when done
<rick_h_> jrwren: can you help dimitern https://bugs.launchpad.net/bugs/1421315 with the steps you used to reproduce please?
<mup> Bug #1421315: subordinate service not appearing in watch output <api> <juju-gui> <oil> <regression> <juju-core:Triaged> <juju-core 1.22:Triaged> <juju-deployer:Triaged by hazmat> <https://launchpad.net/bugs/1421315>
<rick_h_> jrwren: if you have the websocket frames in a pastebin/etc even sweeter
<jrwren> rick_h_: I have the websocket frames in a screenshot. I'll share doc.
<rick_h_> jrwren: ty
<dimitern> jrwren, rick_h_, thanks for sharing the document, but this still doesn't show the issue
<rick_h_> jrwren: I'm not seeing the beta4 screenshot
<rick_h_> dimitern: basically the images highlight how the allwatcher sent the info about the nrpe charm in the watcher output
<rick_h_> dimitern: and in beta4 that is no longer sent
<dimitern> rick_h_, sorry, but I'd rather have logs I can search in than a screenshot of half a log
<rick_h_> dimitern: right, understand. It was the easiest way I could mention jrwren to QA it as I know how to watch the allwatcher from the websocket the gui manages so this is from a browser session of watcher events
<dimitern> rick_h_, ok, it will be great if those dumps are available somewhere as well
<dimitern> jrwren, ^^
<perrito666> ericsnow: I assumed standup was postponed
<ericsnow> perrito666: k
<ericsnow> perrito666: ah, I missed Nate's email :)
<jrwren> rick_h_: I didn't add beta4 screenshot as it is identical to the others.
<jrwren> dimitern: Yes, doesn't show the issue. Still trying to repro.
<dimitern> jrwren, ah, sorry I though you already did
<jrwren> dimitern: No, I'm guessing this regression is only in master. I've not built master yet, so I cannot confirm.
<jrwren> dimitern: It is not in any released version that I've tested, and I've tested all current released versions AFAIK
<dimitern> jrwren, not even in 1.22-beta4? that was proposed for release
<jrwren> dimitern: this morning i confirmed it is not in 1.22-beta4
<dimitern> jrwren, ok
<dimitern> rick_h_, ^^
<jrwren> dimitern: ugh. Typo in my lp comment. I added another comment.
<dimitern> jrwren, no worries, thanks for clarifying
<rick_h_> jrwren: oh, important typo lol
<rick_h_> jrwren: dimitern ok, so we need to check with the original bug author and confirm what juju he's using
<rick_h_> jrwren: dimitern because I'm doubting he's building trunk?
<rick_h_> hazmat: did you replicate the subordinate bug and if so on which version of juju? ^
<TheMue> dimitern: have you done the live testing? I now have an interesting race condition in state/action_test.go:374
<hazmat> rick_h_: i didn't, i just read the log output of deployer, its deployed a subordinate, service waited 5s, and does a watch, and the sub isn't in the output
<rick_h_> hazmat: ok, ty.
<mup> Bug #1427257 was filed: Juju backup doesn't contain .juju files <juju-core:New> <https://launchpad.net/bugs/1427257>
<rick_h_> so might be more a race/timing issue where we didn't replicate that with the gui because we weren't checking the time there.
<TheMue> dimitern: if I run the state tests directly in my VM they pass, but when doing it via ssh this test above fails
<dimitern> TheMue, I'm doing it now
<dimitern> TheMue, what do you mean via ssh?
<TheMue> dimitern: I've got a VM running my test system in. when I go in directly it passes. but from inside the editor on the host system I can do a "ssh themue@192.168.2.210 '~/bin/jdt test state'"
<TheMue> dimitern: here jdt is the script I told you about
<TheMue> dimitern: inside the VM I'm simply doing a "jdt test state", so that's not the reason
<TheMue> dimitern: I think the output via SSH back to the editor slows the tests a bit down and that's why the behavior here is different from doing it directly
<dimitern> TheMue, could be something ssh-related - try using -v
<TheMue> dimitern: will do
<TheMue> dimitern: same result. so would be interesting how testing state passed for you
<TheMue> dimitern: the latest changes here only have been the comments like in the review
<alexisb> rick_h_, I am confused by the comments in lp 1421315
<alexisb> it is marked as critical but is not broken in 1.22-beta4?
<rick_h_> alexisb: heh you and me both. Sorry, our guy said he confirmed it but then found out it was not true
<alexisb> dimitern, rick_h_ am I reading something wrong?
<rick_h_> alexisb: so in between we had it run up the flag pole as a breakage in beta4
<alexisb> in the lsat 15 minutes :)
<rick_h_> alexisb: yep
<alexisb> it is going to be a fun monday
<rick_h_> alexisb: so now we're working it out and reevaluating atm
<alexisb> hazmat, as always thanks for your help
<dimitern> alexisb, not more than I am I guess :)
<alexisb> rick_h_, ack, just keep the bug updated and we will stay on it
<alexisb> but at this point I am not sure what our next step is given the information :)
<rick_h_> alexisb: will do, standup atm and will bring it up and update
<alexisb> thnx
<hazmat> rick_h_: yeah.. if it its not reconfirmed, then not sure.. i'm basically booked for the next 36 hrs re trying to reproduce myself, might want to reach out to the oil guys
<dimitern> TheMue, good news
<dimitern> TheMue, so far I couldn't manage to reproduce the issue with your fix
<TheMue> dimitern: aaaaaah
<TheMue> dimitern: \o/
<dimitern> TheMue, yep, so far so good, now I'm retrying the same steps without your fix
<TheMue> dimitern: interested in the results
<dooferlad> dimitern / TheMue: I need some inspiration with how to fix a test. Can either of you jump in a hangout for a while?
<perrito666> mm, these automated travel services would be so much better if you could specify an arrival date instead of departure
<dimitern> dooferlad, sure, just give me 2m
<TheMue> dooferlad: sure
<dooferlad> dimitern, TheMue: Thanks guys.
<dooferlad> dimitern, TheMue: The usual one that we use for the standup?
<TheMue> dooferlad: would say so
<dimitern> TheMue, confirmed!
<dimitern> TheMue, I managed to reproduce the issue on 1.22 without your fix
<TheMue> dimitern: fantastic
<dimitern> TheMue, you have LGTM
<TheMue> dimitern: great, thx, port it to 1.23 then
<dimitern> TheMue, +1
<perrito666> so natefinch back?
<natefinch> perrito666: yep
<perrito666> so ericsnow natefinch wwitzel3  do we staandup or that already happened?
<natefinch> perrito666: we can do that now if they're available
<ericsnow> natefinch: sure
 * perrito666 took the 2 hs thing literally
<natefinch> perrito666: haha
<natefinch> perrito666: I'm rarely that exact :)
<mup> Bug #1427302 was filed: failed to retrieve the template to clone: lxc container 1.21.3 <oil> <juju-core:New> <https://launchpad.net/bugs/1427302>
<dooferlad> dimitern: https://github.com/juju/juju/compare/master...dooferlad:master-map-ordering-tests?expand=1
<dimitern> dooferlad, this looks good to me - go ahead and propose it and ask ericsnow to have a look please
<dooferlad> dimitern: I need to stop for the day in a moment, so I will propose, but if it needs to land today someone else may have to $$prod$$ on github
<dimitern> dooferlad, sure, that's ok
<dooferlad> dimitern: I am seeing some failures in environs/manual, but I don't know if they are related.
<dimitern> dooferlad, paste?
<dooferlad> dimitern: http://pastebin.ubuntu.com/10503991/
<dimitern> dooferlad, no I don't believe these are related
<dooferlad> dimitern, ericsnow: http://reviews.vapour.ws/r/1048/ (should) fix bug #1427149
<mup> Bug #1427149: Tests require predictable map ordering <ci> <regression> <test-failure> <juju-core:In Progress by dooferlad> <https://launchpad.net/bugs/1427149>
 * ericsnow is looking
<dooferlad> dimitern: I will keep an eye on my email, but assume no fast response until tomorrow. Have a good evening!
<dimitern> dooferlad, cheers, same to you!
<lazyPower> !QUESTION: Why does the local.jenv file have multiple entries for the state server "localhost" and "10.0.3.1" (by default) - why not just use the 10.0.3.1 address? is this something to work around the snowflakeness of the local provider?
<mup> lazyPower: In-com-pre-hen-si-ble-ness.
<lazyPower> mup: botsnack
<mup> lazyPower: Roses are red, violets are blue, and I don't understand what you just said.
<TheMue> Would like a review of http://reviews.vapour.ws/r/1050/. It's the port of fix #1425435 from 1.22 to master.
<mup> Bug #1425435: juju-deployer/jujuclient incompatibility with 1.21.3 <api> <cts> <network> <oil> <openstack> <orange-box> <regression> <uosci> <juju-core:Triaged> <juju-core 1.22:Triaged by themue> <juju-core 1.23:Triaged> <https://launchpad.net/bugs/1425435>
<ericsnow> dooferlad: done
<dimitern> lazyPower, 1) it is; 2) because localhost is special in case of ipv4 vs ipv6
<lazyPower> aahhh ok ty for the explanation
<dimitern> :)
<ericsnow> dimitern: I have a patch up for lp-1427210: http://reviews.vapour.ws/r/1047/
<dimitern> ericsnow, looking
<ericsnow> dimitern: thanks
<cory_fu> dimitern: Fair enough about localhost working across IPv4 and IPv6, but couldn't that be handled when the .jenv file is created?  Or is there some other specialness that I'm unaware of?
<dimitern> cory_fu, I suppose it can
<cory_fu> dimitern: The use-case I'm investigating is attempting to connect to an already bootstrapped local provider from within a container, for review and CI.  I was able to get juju status to work (briefly) by removing the localhost entry, but the .jenv file gets re-written periodically which re-adds the localhost entry
<dimitern> ericsnow, reviewed
<ericsnow> dimitern: thanks
<dimitern> cory_fu, that's because the local provider insists on reporting localhost as one of its endpoints
<TheMue> dimitern: the ported fix is available for review too
<dimitern> cory_fu, I can't quite recall why, but there was some other good reason - ask thumper
<dimitern> TheMue, cheers, will have a look
<TheMue> dimitern: great, thanks
<mup> Bug #1427302 changed: failed to retrieve the template to clone: lxc container 1.21.3 <oil> <juju-core:New> <https://launchpad.net/bugs/1427302>
<mup> Bug #1427302 was filed: failed to retrieve the template to clone: lxc container 1.21.3 <oil> <juju-core:New> <https://launchpad.net/bugs/1427302>
<mup> Bug #1427302 changed: failed to retrieve the template to clone: lxc container 1.21.3 <oil> <juju-core:New> <https://launchpad.net/bugs/1427302>
<TheMue> dimitern: seen your review, thx already
<dimitern> TheMue, np :)
<mup> Bug #1427342 was filed: juju package should have strict version dep with juju-core <juju-core:New> <https://launchpad.net/bugs/1427342>
<sinzui> natefinch, dimitern, someone landed a change to 1.22 without first landing 1.22-beta5 version. CI knows the version is released
<sinzui> natefinch, dimitern I am trying to merge the 1.22-beta5 branch to satisfy CI
<natefinch> sinzui: are you saying no code should have been landed before the 1.22-beta5 tag was created?
<sinzui> natefinch, CI will not test a version of juju that tries to mutate the agents that are released.
<sinzui> natefinch, The branch that incremented juju to beta5 hadn't merged, so CI blocked testing of the last merge to 1.22
<natefinch> sinzui: oh, I see what you mean - we have to change the actual files to create a new release number, as well as creating the tag in git... and we hadn't made the change to the files yet.
<sinzui> natefinch, dimitern : I am bringing this up because it isn't clear from the failure email sent to the list why publish-revision failed
<sinzui> I am fixing it. nothing for your team o do
<natefinch> sinzui: ok
<sinzui> we will retest in about 15 minutes
<natefinch> TheMue: you around?
<TheMue> natefinch: yep
<natefinch> TheMue: how's the train from Munich to Nuremberg?  I'm considering just flying into Munich, since most of my flights go through there anyway
<TheMue> natefinch: should be very good, it's near and Nuremberg-Munich are on the ICE route. the ICE is the fastest train in Germany.
<TheMue> natefinch: I'll take it too, but from north. ;)
<natefinch> TheMue: nice.  Do you know if you have to book ahead of time, or can you basically walk up and buy a ticket?
<TheMue> natefinch: normally you can buy directly at the railway station. only if you want to make sure getting a good seat you'll have to book ahead of time
<natefinch> TheMue: cool.
<TheMue> natefinch: time is between 2 and 2:30, depending on the exact trains
<TheMue> natefinch: sadly Munich Central Station is 40 mins away from the airport
<natefinch> TheMue: oh, hmm
<natefinch> TheMue: that's unfortunate
<natefinch> TheMue: that might make my decision for me, then
<TheMue> natefinch: yep
<sinzui> hazmat, we expect CI to test deployer along with quickstart starting Thursday
<TheMue> natefinch: is their a flight from Amsterdam to Nuremberg? or Heathrow? then this may be better.
<hazmat> sinzui: cool, thanks for the update
<natefinch> TheMue: looks like most flights want to take me to munich or frankfurt, and then a tiny airplane to nuremberg...   amsterdam or zurich are other possible stops... but they end up being a little longer
<natefinch> dang, I was happy with the 8 hour direct flight to Munich :)
<TheMue> natefinch: yes, I know, puzzling together the optimal connection isn't very easy.
<alexisb> natefinch, ping
<thumper> urulama: are you still around?
<urulama> thumper: hey. just about to have dinner. will ping you when i'm done :)
<thumper> ok
<davecheney> thumper:
<davecheney> i forgot to ask
<davecheney> at the standup
<davecheney> what is next with power ?
<thumper> davecheney: I need to talk with alexisb about that in my call this morning
<davecheney> ok
<davecheney> i have the fix as a replacement .deb we can deploy on ppc64 ci machines to get them going
<urulama> thumper: back
<thumper> urulama: that was quick
<thumper> urulama: I'm free for the next 20 minutes
<ericsnow> mgz: how do I kick off a run of "local-deploy-vivid-amd64"?
<mgz> ericsnow: you mean for a specific branch? or just rerun the last job?
<ericsnow> mgz: trying to verify 1427210 is fixed (so job 144)
<mgz> ericsnow: it seems to be reliably (twince in the same way) failing with a new error
<ericsnow> mgz: k
<mgz> conf.Output value "/var/log/juju-jenkins-localdeploy-vivid-amd64/machine-0.log" (Options are syslog) is not valid
<ericsnow> mgz: how do I look at the logs?
<mgz> ericsnow: it's not yet up on juju-reports so I'm just looking at the job in jenkins, which requires admin/password which can be found is cloud-city
<ericsnow> mgz: k
 * urulama makes a note to self ... don't talk to thumper :P
<thumper> urulama: oh, c'mon
<thumper> it wasn't that bad
<urulama> you were laughing a lot, yes :D
<perrito666> urulama: really? you need a note? I got it in my induction manual
<urulama> perrito666: :D
<rick_h_> urulama: don't take that from thumper!
<rick_h_> urulama: just bring up UX issues until he calls off the phone call
<urulama> thumper: fyi, you have +1++ on JES CLI
<thumper> awesome
<rick_h_> lol
<alexisb> thumper, ping
<thumper> hey
<thumper> coming
<ericsnow> could someone take a look at a small patch: http://reviews.vapour.ws/r/1051/
<ericsnow> it should unblock CI
<menn0> ericsnow: looking
<alexisb> wallyworld__, ping
<menn0> ericsnow: i'm probably just missing context but why is a command simple when it contains one of the those characters?
<ericsnow> menn0: yeah, the condition is reversed (so all those are *not* simple) :)
<ericsnow> menn0: I'll fix that
<menn0> ericsnow: right, that makes more sense then!
<menn0> ericsnow: while you're in there, consider using strings.ContainsAny()
<menn0> ericsnow: that would simplify the function somewhat (and make it more efficient)
<ericsnow> menn0: sounds good
<menn0> ericsnow: initial review done
<ericsnow> menn0: thanks
<ericsnow> menn0: I've updated the patch
<mup> Bug #1403084 changed: Tests that need to be fixed on windows <ci> <tech-debt> <testing> <windows> <juju-core:Fix Released> <https://launchpad.net/bugs/1403084>
<sinzui> ericsnow, do you want to claim this bug as in progress or fix committed https://bugs.launchpad.net/juju-core/+bug/1409639
<mup> Bug #1409639: juju needs to support systemd for >= vivid <systemd-boot> <juju-core:Triaged> <juju-core (Ubuntu):Triaged> <juju-core (Ubuntu Vivid):Triaged> <https://launchpad.net/bugs/1409639>
<ericsnow> sinzui: good point
<menn0> ericsnow: re the comment about the error check TODO. where I commented there's no UpdateConfig call. Looks like a copy and paste problem? That TODO appears twice in the PR.
<ericsnow> sinzui: I'll updated it
<ericsnow> menn0: ah, you're right
<menn0> ericsnow: sorry, a couple more little things
<ericsnow> menn0: no worries
<ericsnow> menn0: fixed
<menn0> ericsnow: ship it
<ericsnow> menn0: thanks
<ericsnow> abentley: are you looking at local-deploy-vivid-amd64?
#juju-dev 2015-03-03
<wallyworld_> ericsnow: given we have stuff that needs to be landed for 1.23, would it be worth reverting the commit that is blocking landings
<ericsnow> wallyworld_: it (systemd support) needs to be in 1.23 too, but otherwise yeah
<wallyworld_> ok
<ericsnow> wallyworld_: I'm hopeful I can find the problem in the next bit
<wallyworld_> rightio
<ericsnow> wallyworld_: it's a matter of trying to decipher the CI logs
<wallyworld_> fun
<davecheney> thumper: sinzu I have a replacement gccgo-go package that fixes the test problems with 1.23
<davecheney> how/when do you want it ?
<davecheney> a/win10
<thumper> davecheney: alexisb has passed on the power patch to wes and they are dealing with the foundations (or whatever team) to get it landed
<davecheney> right o
<davecheney> just to repeat
<davecheney> i have a replacement deb that we can install on the ci machines to get the tests passing
<jw4> ericsnow: I think there is another presentation of the map-ordering bug in systemd service_test.go : http://paste.ubuntu.com/10508907/
<jw4> ericsnow: I'll file an LP bug for it, but thought you'd like to know
<ericsnow> jw4: is that different from https://bugs.launchpad.net/juju-core/+bug/1427149
<mup> Bug #1427149: Tests require predictable map ordering <ci> <regression> <test-failure> <juju-core:In Progress by dooferlad> <https://launchpad.net/bugs/1427149>
<ericsnow> jw4: ?
<jw4> ericsnow: it's different presentation
<jw4> ericsnow: not sure if it's different root cause
<ericsnow> jw4: pretty sure it's the same cause
<jw4> ericsnow: I think it is different because the other one seems to be related to listing services and this seems to be related to order of an emitted config file
<ericsnow> jw4: k
<jw4> ericsnow: but yeah, same issue with map ordering being unpredictable in newer versions of go
<mup> Bug #1427454 was filed: systemd tests depend on map-ordering <juju-core:New> <https://launchpad.net/bugs/1427454>
<jw4> nice new feature mup... who taught you that trick?  I started noticing it this past weekend
<ericsnow> could I get a review on http://reviews.vapour.ws/r/1053/?
<ericsnow> it is for unblocking CI
<jw4> ericsnow: ungraduated, but LGTM
<ericsnow> jw4: thanks
<ericsnow> wallyworld_: could you take a quick look?
 * wallyworld_ looks up
<thumper> ericsnow: done
<ericsnow> thumper: thanks
<wallyworld_> ericsnow: i asked for a todo for better test coverage
<ericsnow> wallyworld_: k
<wallyworld_> there's a few corner cases and logic in there that would be good to test
<wallyworld_> transient, desc == "" etc
<ericsnow> wallyworld_: good point
<waigani> perrito666: you're oncall reviewer right? Could you take a look please: http://reviews.vapour.ws/r/1054/
<wallyworld_> waigani: perrito666 is or should be asleep
<waigani> wallyworld_: well that's no excuse!
<wallyworld_> indeed
<ericsnow> I'll be AFK for a bit, but the merge job is running and if it lands the local-deploy-vivid-amd64 job should kick off (with hopefully successful results)
<perrito666> waigani: thanks to the magic of timezones I am not OCR for a couple of hours more
<waigani> perrito666: you're awake! but you shouldn't be
<perrito666> waigani: but, I am a nice enough person and Ill review it, although you will have to explain to my wife why I am reviewing code in bed
<waigani> perrito666: no don't seriously it's okay
<davecheney> open question
<davecheney> there is a page, i think somewhere on cdimages.u.c that gives you links to amazon to try any cloud image
<davecheney> does anyone know what I am talking about
<davecheney> does anyone remember the page
<davecheney> https://cloud-images.ubuntu.com/vivid/current/
<davecheney> it's this one
<perrito666> waigani: reviewed
<perrito666> davecheney: btw, I reviewed waigani's :p
<waigani> perrito666: thank you, now sleep
<perrito666> waigani: I need to wait that the soap opera my wife is watching ends (I want to know the ending now that I saw the beginning)
<davecheney> Get:24 http://ap-southeast-2.ec2.archive.ubuntu.com/ubuntu/ vivid/main gcc-4.9 amd64 4.9.2-10ubuntu7 [5,656 kB]
<davecheney> 35% [24 gcc-4.9 5,647 kB/5,656 kB 100%]                                                                                                                                                98.3 kB/s 8min 7s
<davecheney> go cloud images
<davecheney> go ... slow
<davecheney> i've let mr howard know
 * thumper disconnects to focus on finishing this branch by the EOD
<ericsnow> the CI test is queued up that will verify the blocker bug is resolved
<axw> wallyworld_: just noticed something weird in validateVolumeParams: it's setting params.Pool to the default internally. why is it doing that? that value won't surface, since the params are by-value
<axw> the Pool should be != "" by the time validation occurs
<wallyworld_> let me look
<wallyworld_> axw: yeah, that looks like a mistake
<axw> wallyworld_: nps, I'll need to make updates in this area in my branch \
<axw> so I can fix it
<wallyworld_> ty
<mup> Bug #1427501 was filed: api/networker: test failure due to map ordering <juju-core:New> <https://launchpad.net/bugs/1427501>
<mup> Bug #1427505 was filed: apiserver/networker: test failure due to map ordering <juju-core:New> <https://launchpad.net/bugs/1427505>
<wallyworld_> axw: that maas doc, we need to provide feedback on the storage API result data at the bottom of the doc
<axw> wallyworld_: ok
<wallyworld_> we can take a day or so to do it
<wallyworld_> i'll look tomorrow
<mup> Bug #1427508 was filed: cmd/jujud/agent: test failure <juju-core:New> <https://launchpad.net/bugs/1427508>
<mup> Bug #1346597 was filed: cannot get replset config: not authorized for query on local.system.replset <cloud-installer> <landscape> <oil> <juju-core:New> <https://launchpad.net/bugs/1346597>
<mup> Bug #1427510 was filed: version: tests do not parse on a fresh machine <juju-core:New> <https://launchpad.net/bugs/1427510>
<wallyworld_> axw: i've put up a charm.v4 pull request https://github.com/juju/charm/pull/88
<axw> looking
<axw> wallyworld_: I just proposed a rather larger change: https://github.com/juju/juju/pull/1725
<wallyworld_> ok, np, i have to go to soccer soonish, but will look either now or when i get back
<beisner> o/ hi, good evening!
<beisner> fyi bug 1420049 updated
<mup> Bug #1420049: ppc64el - jujud: Syntax error: word unexpected (expecting ")") <deploy> <openstack> <regression> <uosci> <juju-core:Fix Committed by dooferlad> <juju-core 1.22:Fix Released by axwalk> <https://launchpad.net/bugs/1420049>
<wallyworld_> axw: i kinda think we should have storage properties - the spec does seem to discuss expected behaviour - perhaps jam has a view? easy to ignore if we don't need them
<wallyworld_> s/ignore/omit
<axw> wallyworld_: it "kinda" does, but it's not very clear. see my unanswered question in the doc
<axw> wallyworld_: the main problem is that once they're in there, we can't easily change it
<axw> wallyworld_: is it possible to just have the attribute ignored but not error if it's supplied ?
<wallyworld_> yeah, i know the question. i think it's a more of a charm author hint - "i don't care if this data disappears as it's just a cache".
<wallyworld_> sure, i=we can set the attribute but the stroage provider doesn't need to act on it if that's what yu mean
<axw> wallyworld_: I mean, don't even expose it in the output, or define any kind of structure for it
<axw> wallyworld_: I really can't see us using it until after phase 1
<wallyworld_> ok, let's discuss with jam
<jam> wallyworld_: no
<axw> no, don't discuss with jam? ;)
<wallyworld_> no what?
<jam> wallyworld_: I won't discuss it. I came in late to the discussion. what's up ?
<jam> sorry, needed a :)
<wallyworld_> jam: the concept of torage properties eg transient
<axw> jam: we're discussing the merits of "properties" in storage metadata
<wallyworld_> the spec isn't 100% clear
<wallyworld_> eg are they hints or reuirements
<axw> jam: context: https://github.com/juju/charm/pull/88
<wallyworld_> we're not sure whether to add support in charm metadata for them
<wallyworld_> do we need to support transient storages for phase 1
<jam> wallyworld_: I'm pretty sure transient was meant to be a hint, rather than a requirement
<jam> "which providers may take to mean"
<jam> "may" is pretty clear there
<wallyworld_> jam: that's my take on it as well
<axw> can the name be changed to reflect this?
<axw> e.g. hints
<wallyworld_> you mean the name "Properties"?
<axw> right
 * wallyworld_ has no opinion either way
<jam> wallyworld_: axw: so I'd like to avoid revising the charm metadata multiple times. And while 'transient' is just a hint, others may be less of a hint. Do we need to rev the charm metadata format if we allow more entries?
<jam> I suppose we don't if we only put hints in there.
<jam> I don't like the word "hints" per se
<jam> maybe its ok in a storage block
<wallyworld_> i'm not sure about the need to revise and the new values or totally optional
<wallyworld_> are
<wallyworld_> so old metadata will parse just fine
<axw> jam: we won't need to rev for additional property/hint names, I just don't think "properties" really reflects that it's optional
<axw> and charm authors may be surprised that it doesn't do what they think it does
<jam> axw: I believe the discussion was always around hinting, with some other ideas like fast etc. So the provider could know about high-iops storage and map the request over to that storage.
<axw> I guess whether or not it's a hint is on the actual value, then
<axw> okay
<axw> wallyworld_: leave it
<axw> I rescind
<wallyworld_> ok
<jam> axw: so I'm happy to bring up hints vs properties. I don't feel like I have final call, but if you want I can bring it up to Mark.
<axw> jam: I think it's fine, as long as we're clear when describing specific properties
<wallyworld_> jam: one other thing - trunk is blocked due to a vivid systemd issue. IMHO that's not a regression since we've never supported vivid yet and systemd work is WIP. what's your view on that?
<wallyworld_> it will be at least 16 hours before trunk could be unblocked and we got goamz and leader eections work to land
<wallyworld_> for 1.23
<jam> wallyworld_: It depends. if it is a platform thing (like the gccgo bug) then I hesitate to let it block trunk (not something we can just fix)
<jam> wallyworld_: if it is something we did that doesn't work on V then we need to fix it
<jam> V is high priority to support
<jam> wallyworld_: because until it is in V it won't be backported to T
<jam> (standard Ubuntu rule is to be in the latest release and then backport it to the LTS)
<wallyworld_> jam: well, upstart always worked on vivid with juju. but we are targetting systemd i believe, and that's what in't uire rught yet
<wallyworld_> it seems silly to block on a new juju feature being developed for an unreleased series
<wallyworld_> it's just something that needs fixing for sure, but to block everything on that?
<jam> wallyworld_: blocking trunk because it is unreleasable helps us prevent adding more bugs into the system. We have a *very* bad track record here
<jam> so I'm definitely biased towards blocking
<jam> cause we keep breaking shit
<jam> and then break something else by the time we fixed the last one
<wallyworld_> sure. we block on regressions. IMO this isn't a regression
<wallyworld_> it's a new feature that is broken
<jam> wallyworld_: we can't release trunk because a key platform we want to support is broken
<jam> wallyworld_: then revert it
<wallyworld_> we may have to
<jam> or we can't because we have to use systemd for vivid
<wallyworld_> if we want to change the block policy to a key unreleased platform being broken, that's fine, but we need to make that clear
<wallyworld_> since strictly speaking it's not a regression
<jam> wallyworld_: I'm pretty sure supporting V is a must for 1.23 since it is targetted to V
<wallyworld_> yes, agreed, but thst something is broken is not a regression
<wallyworld_> it's a new feature that has a bug
<wallyworld_> therefore trunk should not be blocked
<jam> wallyworld_: support for a critical platform is enough to be a critical blocker even if it isn't a regression
<jam> wallyworld_: if 1.23 was split of trunk already then yes, don't block trunk
<jam> I don't think that split has been done yet
<wallyworld_> that's a new policy decision then
<wallyworld_> no, 1.23 not branched yet
<wallyworld_> waiting on leader elections and goamz but these are now queued
<jam> wallyworld_: if CI tests can't pass, then we risk breaking it for a new reason if we continue to land code.
<jam> wallyworld_: are we *not* waiting on V support
<wallyworld_> it's CI on one test only - vivid
<jam> that seems like it would fall into that bucket of blocking 1.223
<jam> 1.23
<wallyworld_> we are waiting on it yes
<wallyworld_> but systemd being broken seems unfortunate to block unrelated landings on
<jam> wallyworld_: I'm certainly willing to be pragmatic, our track record has just been so bad in this area
<wallyworld_> agreed about track record
<jam> wallyworld_: all last december we could not release trunk because we would break Y while X was getting fixed
<wallyworld_> here it's one CI test (vivid)
<wallyworld_> if anything else breaks, stop the line for sure
<wallyworld_> but it's a vivid specific (new) feature
<TheMue> morning o/
<dooferlad> morning o/
 * fwereade has an old old laptop whose hdd has started making happy fun clicky noises; going out to get another; might be a little while
<axw> :(  hdds should be seen and not heard
<perrito666> axw: hdds should be on a hidden place of the house onnected to a storage server :p
<perrito666> which is what I did with al the hdd I gradually replaced
<axw> perrito666: :)
 * axw pats his NAS
<perrito666> axw: I actually have a thinkpad with a lot of usb adapters :p I could not get a decent nas here for less money than what a cheap car costs :p
<TheMue> hdds shouldn't be needed, large and fast flash as ram replacement instead, non-volatile and networked
<perrito666> minihdmi is  really bad idea
<perrito666> mm why do we have structs that take pointers to ints?
<TheMue> perrito666: if you want to have the possibility that they are nil
<TheMue> perrito666: to indicate they are unset
<TheMue> perrito666: while 0 or any other value may be valid
<perrito666> TheMue: ah that makes sense, perhaps they are values where 0 is meaningful and cannot be used as empty
<mgz> yeah, what themue said
<TheMue> perrito666: exactly
<mgz> sometimes there may actually be a better way of doing the same thing, but there are also compat issues
<perrito666> I am seeing a rather creative solution in a review which strikes me as a bit strange but I guess there is no other way
<fwereade> perrito666, mgz, TheMue: the general principle is "avoid in-band signalling", it's the same as the motivation for returning `, bool` even when a nil return would theoretically convey the same information
<perrito666> fwereade: hey, wb, how was the laptop hunting?
<fwereade> perrito666, pretty good, it even had ubuntu preinstalled
<perrito666> fwereade: sweeet
<TheMue> fwereade: then a struct { myInt int; myIntOK bool } could do the same ;)
<perrito666> might I inquire what did you get?
<fwereade> perrito666, dell latitude e6540
 * TheMue thinks of structs with many of those fields
<fwereade> perrito666, yay certified hardware :)
<fwereade> TheMue, yeah, that's true, and might even be the way to go sometimes
<fwereade> TheMue, it's a bloody hassle constructing test data with points to ints/strings
<perrito666> this case has a function that returns an int pointer
<TheMue> imho swift has a way to signal if a value is unset
<fwereade> perrito666, it is hard to think of a good reason for that
 * fwereade wonders if he wrote it himself
<mgz> perrito666: you need to link the review now, we've been talking about it for 5 minutes
<perrito666> http://reviews.vapour.ws/r/1049/diff/#
<perrito666> look for uint64p
<mgz> okay, I think that falls under the compat requirements heading
<mgz> we could change the constraints struct to seperately record which constraints are actually set, but that's not how it's currently done
 * fwereade is obscurely pleased to note that it is indeed all his fault
<mgz> :)
<ericsnow> could I get a review on http://reviews.vapour.ws/r/1056/
<ericsnow> it unblocks CI
<perrito666> yes you can
<perrito666> ericsnow: may I suggest a different path of action?
<ericsnow> perrito666: I'm all ears :)
<perrito666> ericsnow: delete the code and before committing make a patch to revet that and save it for quick usage, but dont comment out code
<ericsnow> perrito666: I'm fine with that
<perrito666> ericsnow: sorry I am a pruit sometimes
<natefinch> +1 for not committing commented-out code
<natefinch> though if it's a very small amount with a very clear comment as to when it'll be un-commented, that's ok
<ericsnow> natefinch: it is :)
<ericsnow> natefinch: but that's fine
<natefinch> ericsnow: the nice thing about that is that the diffs are easier to read than delete/readd
<perrito666> well its not like you cannot revert that commit lateron with git
<natefinch> ericsnow: want to do our 1 on 1, or do you want to keep cranking?  I know you've been pushing hard to get this stuff done, and I don't want to break your stride
<ericsnow> natefinch: we can meet
<mgz> ericsnow: do the unit tests pass with that change? I'd expect commenting out some of the linuxExecutables to fail that test that checks 'em
<mgz> ericsnow: I do think a revert at this point to unblock is sensible - if you need help testing before landing an un-revert I'll be happy to help
<ericsnow> mgz: the patch includes updating the test that is impacted
<mgz> ericsnow: so it does
<evilnickveitch> I have a painfully specific question about hook tools. As open-port can now specify a range, what if there is a conflict on _part_ of the range? i.e. I try and open 80-100 but 80 is already open: do I get 81-100 or nothing?
<natefinch> evilnickveitch: my guess is that a conflict will mean it does nothing.
<natefinch> evilnickveitch: but I can look at the code to know for sure
<evilnickveitch> natefinch, if you could, that would help - i do like to be as precise as possible (its for the docs)
<natefinch> evilnickveitch: sorry, got disconnected, did you see my last message about any overlap being a conflict?
<evilnickveitch> natefinch, I did not, but now I know - thanks so much, it would have taken me far longer to work it out!
<mup> Bug #1427454 changed: systemd tests depend on map-ordering <intermittent-failure> <tech-debt> <test-failure> <juju-core:Incomplete> <https://launchpad.net/bugs/1427454>
<mup> Bug #1427454 was filed: systemd tests depend on map-ordering <intermittent-failure> <tech-debt> <test-failure> <juju-core:Incomplete> <https://launchpad.net/bugs/1427454>
<mup> Bug #1427454 changed: systemd tests depend on map-ordering <intermittent-failure> <tech-debt> <test-failure> <juju-core:Incomplete> <https://launchpad.net/bugs/1427454>
<mup> Bug #1427454 was filed: systemd tests depend on map-ordering <intermittent-failure> <tech-debt> <test-failure> <juju-core:Incomplete> <https://launchpad.net/bugs/1427454>
<mup> Bug #1427454 changed: systemd tests depend on map-ordering <intermittent-failure> <tech-debt> <test-failure> <juju-core:Incomplete> <https://launchpad.net/bugs/1427454>
<mup> Bug #1427454 was filed: systemd tests depend on map-ordering <intermittent-failure> <tech-debt> <test-failure> <juju-core:Incomplete> <https://launchpad.net/bugs/1427454>
<mup> Bug #1427454 changed: systemd tests depend on map-ordering <intermittent-failure> <tech-debt> <test-failure> <juju-core:Incomplete> <https://launchpad.net/bugs/1427454>
<mup> Bug #1427454 was filed: systemd tests depend on map-ordering <intermittent-failure> <tech-debt> <test-failure> <juju-core:Incomplete> <https://launchpad.net/bugs/1427454>
<mgz> what are you up to mup...
<mgz> naughty bot.
<TheMue> mgz: it has a hiccup, or better, a muppup
<mup> Bug #1427454 changed: systemd tests depend on map-ordering <intermittent-failure> <tech-debt> <test-failure> <juju-core:Incomplete> <https://launchpad.net/bugs/1427454>
<mup> Bug #1427770 was filed: opened-ports doesn't include ports opened by other charms <juju-core:New> <https://launchpad.net/bugs/1427770>
<ericsnow> mgz: how do I force local-deploy-vivid-amd64 to re-run?
<mgz> on the same revision, rebuild will work
<mgz> logged in as admin, select latest build of job, rebuild on the left
<ericsnow> mgz: k
<mup> Bug #1427770 changed: opened-ports doesn't include ports opened by other charms <juju-core:New> <https://launchpad.net/bugs/1427770>
<mup> Bug #1427770 was filed: opened-ports doesn't include ports opened by other charms <juju-core:New> <https://launchpad.net/bugs/1427770>
<niedbalski> ericsnow, i am consternated with https://github.com/juju/juju/pull/1727, just a comment
<niedbalski> ericsnow, i was under the same impression
<ericsnow> niedbalski: yeah, sounds like they are switching over in the next week or so
<natefinch> ericsnow: re-stamped
<ericsnow> natefinch: thanks
<mup> Bug #1427814 was filed: juju bootstrap fails on maas with when the node has empty lshw output from commissioning <bootstrap> <maas> <maas-provider> <network> <juju-core:Triaged> <https://launchpad.net/bugs/1427814>
<mup> Bug #1427814 changed: juju bootstrap fails on maas with when the node has empty lshw output from commissioning <bootstrap> <maas> <maas-provider> <network> <juju-core:Triaged> <https://launchpad.net/bugs/1427814>
<mup> Bug #1427814 was filed: juju bootstrap fails on maas with when the node has empty lshw output from commissioning <bootstrap> <maas> <maas-provider> <network> <juju-core:Triaged> <https://launchpad.net/bugs/1427814>
<mup> Bug #1427814 changed: juju bootstrap fails on maas with when the node has empty lshw output from commissioning <bootstrap> <maas> <maas-provider> <network> <juju-core:Triaged> <https://launchpad.net/bugs/1427814>
<mup> Bug #1427814 was filed: juju bootstrap fails on maas with when the node has empty lshw output from commissioning <bootstrap> <maas> <maas-provider> <network> <juju-core:Triaged> <https://launchpad.net/bugs/1427814>
<mup> Bug #1427814 changed: juju bootstrap fails on maas with when the node has empty lshw output from commissioning <bootstrap> <maas> <maas-provider> <network> <juju-core:Triaged> <https://launchpad.net/bugs/1427814>
<mup> Bug #1427814 was filed: juju bootstrap fails on maas with when the node has empty lshw output from commissioning <bootstrap> <maas> <maas-provider> <network> <juju-core:Triaged> <https://launchpad.net/bugs/1427814>
<mup> Bug #1427814 changed: juju bootstrap fails on maas with when the node has empty lshw output from commissioning <bootstrap> <maas> <maas-provider> <network> <juju-core:Triaged> <https://launchpad.net/bugs/1427814>
<perrito666> sounds like mup could use a burst detection function
<mup> Bug #1427814 was filed: juju bootstrap fails on maas with when the node has empty lshw output from commissioning <bootstrap> <maas> <maas-provider> <network> <juju-core:Triaged> <https://launchpad.net/bugs/1427814>
<mup> Bug #1427814 changed: juju bootstrap fails on maas with when the node has empty lshw output from commissioning <bootstrap> <maas> <maas-provider> <network> <juju-core:Triaged> <https://launchpad.net/bugs/1427814>
<mup> Bug #1427814 was filed: juju bootstrap fails on maas with when the node has empty lshw output from commissioning <bootstrap> <maas> <maas-provider> <network> <juju-core:Triaged> <https://launchpad.net/bugs/1427814>
<perrito666> really?
<mbruzek> abentley: jog: I noticed that the reporting stuff has changed.
<mbruzek> +1
<jog> mbruzek, yes, URLs should still be the same.
<mbruzek> jog: We got an AWS failure, looks like an infrastructure problem that you fixed last week.
<mbruzek> jog: http://reports.vapour.ws/charm-tests/charm-bundle-test-parent-138/charm/charm-testing-aws/10
<mbruzek> jog: is that the same error?
 * jog looks
<jog> mbruzek, looking at the consoleText log deployer appears to have run fine while installing the bundle (I applied a patch for deployer last week). This looks like an error from 'juju terminate-machine'
<jog> mbruzek, hmm... maybe not, there's more to this log.
<jog> mbruzek, we saw this 'watcher was stopped' Error last week but I think it's different from the issue that was patched.
<mbruzek> jog: OK
<mbruzek> jog Is there a way to terminate the machines?  (clean up aws) before I try again?
<jog> mbruzek, yes I can log into the AWS console and see what's still running.
<mbruzek> jog: I kicked off amazon again to see if it works, but then I thought to ask my question.  Feel free to kill that process if you think it will fail.
<ericsnow> mgz: so how do I kick off local-deploy-vivid-amd64 against the latest revision?
<jog> mbruzek, tvansteenburgh, also once bundle configs start getting uploaded to S3 we should see links in the reports (I just sent you an email on that topic).
<tvansteenburgh> mbruzek: the env is destroyed at the start of every test, so you can just rerun - no need to manually cleanup
<mbruzek> tvansteenburgh: OK.
<mbruzek> tvansteenburgh: http://reports.vapour.ws/charm-tests/charm-bundle-test-parent-138/charm/charm-testing-aws/10
<mbruzek> tvansteenburgh: Have you seen this error before
<tvansteenburgh> this falls into the "my cloud broke, guess i'll try again" category
 * mbruzek *sighs*
<mbruzek> Thanks for taking a look.  next test is running, hoping that one passes
<tvansteenburgh> it's most likely b/c we are competing for resources with the charm-bundle-test job
<tvansteenburgh> your env probably got destroyed out from under you
<tvansteenburgh> this will be fixed once we get RevQ using the new jobs
<mbruzek> tvansteenburgh: ack.
<mbruzek> tvansteenburgh: thank you
<tvansteenburgh> planning to sort that out in CO
<perrito666> local provider hates me
<mup> Bug #1427840 was filed: ec2 provider unaware of c3 types in sa-east-1 <juju-core:New> <https://launchpad.net/bugs/1427840>
<wallyworld_> katco: in another meeting, a few minutes late
<katco> wallyworld_: k ty
<mup> Bug #1427879 was filed: juju cannot deploy when distro-info-data gets a new series <deploy> <series> <juju-core:New> <https://launchpad.net/bugs/1427879>
<mup> Bug #1427210 changed: 'relative path in ExecStart not valid' vivid local deploy failure <ci> <local-provider> <lxc> <regression> <juju-core:Fix Released by ericsnowcurrently> <https://launchpad.net/bugs/1427210>
#juju-dev 2015-03-04
<thumper> I'm finally happy with the tests around create environment now
<thumper> on to manual testing
 * thumper crosses fingers
<mattyw> menn0, ping?
<menn0> mattyw: pong
<thumper> menn0: https://github.com/juju/juju/pull/1731
<thumper> menn0: waiting for RB to pick it up
<menn0> thumper: RB doesn't seem to want to
<thumper> no...
<menn0> thumper: shall I just review on GH
<menn0> ?
<thumper> sure
<davecheney> mwhudson: the output from 7g -g is a total dogs breakfast
<davecheney> it also appears this particular dog has barfed up the response, twice
<davecheney> for good effect
<mwhudson> is 6g -g any better?
<davecheney> probaly not
<davecheney> i've narrow the current crapping out
<davecheney> to a nil check
<davecheney> x := *y
<davecheney> will generate a nil check
<davecheney> and the encoding on that is screwed
<mattyw> menn0, http://reviews.vapour.ws/r/1063/ when you have a moment
<menn0> mattyw: looking
<menn0> mattyw: ship it!
<mattyw> menn0, thanks very much
<axw> wallyworld: https://bugs.launchpad.net/juju-core/+bug/1420049 -- can you please see my latest comments on this
<mup> Bug #1420049: ppc64el - jujud: Syntax error: word unexpected (expecting ")") <deploy> <openstack> <regression> <uosci> <juju-core:Fix Committed by dooferlad> <juju-core 1.22:In Progress by axwalk> <https://launchpad.net/bugs/1420049>
<wallyworld> sure
<wallyworld> axw: i think it might be reasonable to say that when deploying containers, we match the machine arch. even if they bootstrap with an env arch, and start a machine with a different explicitly set arch for that machine, it doesn't seem useful to go and use the env constraint when deploying a container without an arch when what we really want is just to match the host arch for lxc
<wallyworld> deploying containers = lxc containers
<axw> wallyworld: I suppose they only get into this scenario when using placement, so in that sense it's okay
<wallyworld> yeah, i think so
<axw> wallyworld: I'm worried about cornering ourselves though, where we might want to start adding containers to non-empty machines
<axw> hmmm
<axw> in that case it would be up to the placement code to match the constraint...
<wallyworld> even in that case, add lxc container - arch should match host
<axw> okay
<wallyworld> if they explicitly speify an arch when deploying that is incompatible, then we error
<wallyworld> but if we are just falling back to env arch, then we should "do the right thing"
<wallyworld> eg, for kvm thy can specify different arch
<beisner> o/  howdy
<beisner> + addl response on bug 1420049
<mup> Bug #1420049: ppc64el - jujud: Syntax error: word unexpected (expecting ")") <deploy> <openstack> <regression> <uosci> <juju-core:Triaged by axwalk> <juju-core 1.22:In Progress by axwalk> <https://launchpad.net/bugs/1420049>
<axw> beisner: thanks. sorry, I glanced over the repro the first time (I can't easily repro since I don't have a multi-arch MAAS)
<beisner> axw, np.  understandable.  the attached file count is growing on that bug ;-)
<beisner> axw, feel free to ping me if we should try something different.  also, if/when you have a build to test, please point me at whatever ppa or CI/jenkins job has the debs?
<axw> beisner: will do, thanks. the package building is a black box to me, but I'll keep an eye out for when they're available
<beisner> axw, could also set up access for you, though that would take an RT -> vpn acl addition.   from there, we could coordinate access/creds.
<beisner> axw, wallyworld & co., appreciate your work on this bug.
<wallyworld> mainly axw :-)
<axw> beisner: no worries, sorry it didn't get fixed the first time
<wallyworld> it's been interesting because we don't normally deploy the same way
<wallyworld> but it's a good use case to know about
<beisner> axw - well actually it appears to really be 2 different bugs.  you got the 2-for-1 special.   i think one bug was fixed, revealing another.  but go is a blackbox to me.  ;-)
<beisner> first issue being:   that funky syntax error
<axw> I just shifted the bug :)
<beisner> that was fixed
<beisner> 2nd issue:  juju doesn't wanna use the same tools it just used to successfully deploy a unit onto the same dang box.  ;-)
<beisner> wallyworld, yeah this is also an edge case for us.  normally everything is 1 arch.
<wallyworld> for sure a customer will ht the issue too at some point
<wallyworld> better we find it than them
<beisner> yep indeed
<wallyworld> axw: remind me, what's that lib for printing human readable volume sizes
<axw> wallyworld: github.com/dustin/go-humanize
<wallyworld> axw: ta, doesn't look like we use that in master?
<axw> wallyworld: nope, I added it in the feature branch
<wallyworld> ok, i'll look to add it
<mattyw> menn0, still around?
<menn0> mattyw: yep
<axw> wallyworld: how would we surface an error like that? in the provisioner, we don't know the origin of the constraints
<wallyworld> axw: at add-machine or deploy time we have the info
<axw> wallyworld: placement explicitly overrides constraints though, so I don't think it makes sense?
<wallyworld> so we can return the error from apiserver layer
<wallyworld> ah
<wallyworld> yes, i forgot that
<wallyworld> what abut add machine
<wallyworld> will placement override constraints there too
<axw> wallyworld: I'm under the impression that placement always overrides constraints
<wallyworld> so juju add-machine --constraints mem=2G lxc
<wallyworld> will ignore the constraints?
<wallyworld> i guess there it doesn't matter
<wallyworld> as a new machine will be created
<wallyworld> so arch will not skew
<wallyworld> i'll revert my comment
<axw> wallyworld: ignore is too strong a word I guess. it may override aspects of them, or all of them
<axw> wallyworld: e.g. add-machine ssh:... will ignore the env constraints (or should)
<wallyworld> ok, i was just concerned about surprising behaviour
<thumper> axw: thanks for fixing the lxc tools selection
<wallyworld> ie if the user specifies an arch constraint of one thing and the lxc container comes up on another arch
<axw> thumper: no worries
<axw> wallyworld: that was my complaint before. I'm not sure how to resolve it
<wallyworld> yeah
<axw> you could prevent "deploy --constraints=<incompatible> --to lxc:N"
<axw> doesn't seem worthwhile though
<wallyworld> maybe something to fix to improve UI, but not for now
<wallyworld> axw: at first read the TestLxcContainerUsesConstraintsArch() seems wrong? host arch set to ppc64, expect arch amd64?
<axw> wallyworld: I just named the tests back-to-front
<axw> will fix
<wallyworld> ta, i thought i was going mad
<wallyworld> i misse dthe mrthod param
<wallyworld> thumper: cmd/juju/environment/create.go:128: no formatting directive in Errorf call
<axw> wallyworld: have you pulled master today? are the tests in environs/manual failing for you?
<axw> looks upstart/systemd-related
<wallyworld> axw: i'll check
<wallyworld> axw: this? FAIL: provisioner_test.go:47: provisionerSuite.TestProvisionMachine
<axw> wallyworld: yes
<axw> le sigh
<axw> thanks
<wallyworld> how the fark did that get past the bot
<jw4> wallyworld: do you know why the build didn't fail when the verify.bash script got the "no formatting directive in Errorf call" ?
<jw4> wallyworld: I'm nervous it was due to my IGNORE_VET_WARNINGS change from a couple weeks ago
<wallyworld> jw4: i don't think we run vet on the bot
<wallyworld> or i seem to recall we used not to
<jw4> wallyworld: hmm - I see the warning in the last build output
<jw4> http://juju-ci.vapour.ws:8080/job/github-merge-juju/2372/console
<jw4> maybe we just don't fail if it exits non-zero
<wallyworld> yes, i think that may be what we do :-(
<jw4> wallyworld: well I feel better if I didn't break it :)
<wallyworld> i don't think you did
<jw4> FWIW, I've been getting a lot of provisioner test failures too
<wallyworld> which package?
<wallyworld> manual?
<jw4> yeah
<wallyworld> seems they started today
<jw4> for me it seems to be related to OpenSSH and ubuntu@lxc
<jw4> I've been getting it for at least a week
<wallyworld> NFI how the bot let any breakage through
<wallyworld> oh i see
<axw> wallyworld: there's a map
<axw> linuxExecutables in service/service.go
<wallyworld> well that would explain it
<wallyworld> i'm on go 1.3
<wallyworld> the bot runs 1.2
<wallyworld> le sigh indeed
<axw> I'm on 1.4 :)
<axw> I'll fix
<jw4> yeah, I'm on 1.4 too
<jw4> my first recorded error there was on 2/28 fwiw
<axw> wallyworld: small one please: https://github.com/juju/juju/pull/1738
<wallyworld> sure
<wallyworld> axw: LGTM. i have to go get kid, could you please send email to juju-dev highlighting what happened and cc curtis and wes. We need to change how we land to stop this happening again
<wallyworld> we will likely gate landings on gccgo tests passing
<wallyworld> this will add another reason for doing that
<axw> wallyworld: ok
<wallyworld> tyvm
<axw> jw4: what was the problem that let to IGNORE_VET_WARNINGS again?
<jw4> axw: I've brought up go vet warnings from newer versions of go several times
<jw4> axw: most times the answer is... go 1.2.1 is the official version
<jw4> axw: to make it easy for folks to use newer versions of go and still have the pre-push hook
<jw4> axw: I added that envar so that at least bypassing it is explicit rather than implicit
<axw> jw4: I see. and we can't modify the rules to work with both 1.2 and 1.4?
<jw4> axw: I'm not sure I understand - as I understand it the vet rules are largely determined by the version of go you're using
<jw4> axw: we have flags we pass in but those don't seem to be useful for this sort of thing
<axw> jw4: you can customise the functions that are considered printf-style, as in scripts/verify.bash
<axw> ok
<jw4> axw: yeah - tweaking those hasn't addressed the issue in the past
<axw> jw4: I don't see any vet warnings/errors, I'm on 1.4. do you still need to do this at the moment?
<axw> or was the source changed?
<jw4> axw: the source was changed
<jw4> axw: I think it makes sense to have that guard in there anyway
<axw> jw4: yep, it's fine since it's explicit - just wanted to understand
<axw> thanks
<jw4> yw, thank you
<mattyw> menn0, are you done for the day?
<wallyworld> axw: thanks for email, was well written
<axw> wallyworld: cool, nps
<jam> fwereade: when you're around say hi
<tasdomas> dimitern, ping?
<dimitern> tasdomas, hey
<tasdomas> dimitern, mattyw is afk at the moment, but he asked me to ask you to take a look at http://reviews.vapour.ws/r/994/
<dimitern> tasdomas, yes, I know - will get to it at some point
<tasdomas> dimitern, ok - no problem
<dimitern> tasdomas, cheers
<tasdomas> dimitern, another question - with the laster master of juju, I'm getting test failures in api/networker and apiserver/networker
<tasdomas> is this a known issue?
<dimitern> tasdomas, oh - can you paste them?
<tasdomas> dimitern, sure, one sec
<dooferlad> Morning! o/
<dimitern> dooferlad, morning!
<dimitern> dooferlad, did you know that it's valid in go to do: x, y = y,x ?
<dooferlad> dimitern: I had forgotten. Not a language feature I am used to.
<tasdomas> by the way, is there a recommendation as to which version of go should be used for juju development ?
<dimitern> tasdomas, 1.2.1 - the version in precise and trusty
<dimitern> tasdomas, we need to make sure it works on 1.2.1 that is, it's fine if you use a more recent version otherwise
<dimitern> dooferlad, yeah, I was looking at that PR of yours and noticed a place where you swap two volume items in a deeply nested set of slices
<dooferlad> dimitern: I think other than rebasing it to the head of trunk the code is OK now. Just need to get code.google.com/p/gcfg ok as a dependency.
<dimitern> jam, I know we discussed a policy about having 2 team leads at least approve adding a new external dependency, but how about if it's only used for tests?
<TheMue> morning o/
<TheMue> dimitern: thanks for retry my merge. just wanted to do it and wondered where it is. :D
<dimitern> TheMue, morning, np :)
<jam> dimitern: probably the biggest thing for me is that if it is just for testing, then it can't be a strong enough dependency that we should actually need it
<jam> dimitern: in this case, we have a pretty strong preference for YAML in our codebase (or possibly JSON)
<dimitern> jam, it's just for testing
<dimitern> jam, and it's a about parsing INI-style files (like systemd uses)
<dimitern> jam, the alternative is to implement an INI parser ourselves
<jam> dimitern: that's definitely something I see creeping past "just testing" very quickly
<jam> I'm not saying we don't want it, just that it should follow the normal review for dependencies
<dimitern> jam, this is the dependency in question - code.google.com/p/gcfg and the PR that uses it is this https://github.com/juju/juju/pull/1718
<jam> dimitern: "some tests don't generate valid ini files" doesn't sound like a good mix with nondeterministic ordering
<jam> at best it feels like the test is "more likely to pass" but it doesn't actually get us to determinism
<dooferlad> jam: it isn't about generating the files, it is parsing them. The order of items in those files isn't deterministic.
<jam> dooferlad: I fully understand that part.
<jam> but your fix is that "sometimes we'll parse them because sometimes the data can't be parsed"
<jam> and what happens when the "data that can't be parsed" ends up the one that is non-deterministic order
<dimitern> dooferlad, yeah, that statement is a bit worrying
<jam> dooferlad: offhand I'd rather we just made the way config files are *written* deterministic
<jam> even if it means sorting the map keys before iterating them
<dooferlad> jam: it compares the strings because sometimes we don't output an ini file during the test. Sometimes we have "a\nb\nc" for example.
<jam> dooferlad: put another way. It sounds like a problem if our config writer is iterating over maps as much as it is a problem if our tests do
<tasdomas> dimitern, http://paste.ubuntu.com/10524916/ and http://paste.ubuntu.com/10524897/
<dimitern> tasdomas, this looks like a map ordering issue - which version of go are you using?
<tasdomas> dimitern, 1.4
<tasdomas> dimitern, I can try switching to 1.2
<dimitern> tasdomas, yeah, it will pass with 1.2, but the test needs to be fixed nevertheless
<dooferlad> jam: agreed. I would rather that the configs were outputted with sorted keys just from a user POV - I would rather we could diff our ini files to see what changed.
<dimitern> tasdomas, would you do me a favor and file a bug for it if it doesn't exist yet?
<TheMue> dimitern: where to investigate next regarding networking?
<tasdomas> dimitern, sure
<dimitern> TheMue, I'll have a review for you shortly
<dimitern> tasdomas, thanks!
<TheMue> dimitern: great, pressing refresh in dashboard every second now *lol*
<jam> dimitern: dooferlad: so aside from the specifics of these tests, being able to easily parse the files we're writing sounds useful, and reasonable to have as a dependency so we don't have to reimplement it ourselves
<jam> one small concern
<jam> is that gcfg doesn't have any sort of guarantee that it parses the way systemd does. does it?
<dooferlad> jam: No, ini files are not standardised.
<dimitern> TheMue, :) it's a long one let me warn you, but it does 99% of what's left around container addressability
<TheMue> dimitern: it's ok, can imagine what to expect
<dimitern> TheMue, I was live testing it (and fixing some places as a result) on both EC2 and MAAS for the past 2 days
 * dimitern well now! isn't this just beautiful: http://paste.ubuntu.com/10525017/
<dooferlad> dimitern: :-D
<TheMue> dimitern: ouch, neat, that looks cool
<dimitern> TheMue, dooferlad, there it is http://reviews.vapour.ws/r/1072/
<TheMue> *click*
 * dimitern looks at the diff, which is slightly shy of 1000 lines 
<dooferlad> jam, dimitern: Oops. We already have go-systemd, which has a unit Deserialise function. Will switch to that. I will still need to work around unparsable strings, but it won't add a dependency.
<dimitern> dooferlad, oh, that sgtm then
<dooferlad> dimitern: you are the reason why http://www.internetslang.com/ exists :-)
<dimitern> dooferlad, I knew it :)
<axw> dimitern: FYI there were some changes to worker/provisioner for LXC today, may need a minor merge if you haven't already done so
<axw> the pastebin looks nice :)
<dimitern> axw, I did - fortunately small conflict
<dimitern> axw, it does, doesn't it? :) and here's the one for maas: http://paste.ubuntu.com/10525174/
<dimitern> (some stuff needs ironing out it seems)
<axw> very cool, glad to see it come to fruition
<dimitern> :) thanks axw
<dimitern> dooferlad, TheMue, I'm omw in ~2m
<TheMue> kk
<gnuoy> Hi, I'd like to start prodding at the leadership election function. I had thought it was in 1.23-alpha1.1 but it seems not. Is there anywhere I can grab an alpha version of juju that has it in ? Failing that is there a bug I can track?
<wallyworld> natefinch: is there anyone on your team who knows about mongo replica sets who can look at bug 1346597? the relevant error seems to be "not authorized for query on local.system.replset"
<mup> Bug #1346597: cannot get replset config: not authorized for query on local.system.replset <cloud-installer> <landscape> <oil> <juju-core:Triaged> <juju-core 1.22:Triaged> <https://launchpad.net/bugs/1346597>
<wallyworld> this is currently blocking 1.22 and 1.23
<natefinch> wallyworld: sure
<wallyworld> tyvm
<natefinch> wallyworld: usually it's just that we'
<natefinch> we're not running as admin somehow
<wallyworld> we've fixed or are fixing the other 2 so are close to being able to release 1.22
<wallyworld> natefinch: it's on oil so maybe a deployment or setup issue?
<perrito666> hey, there is not much worth of me as I am about to go back to bed and feel bad, but https://bugs.launchpad.net/juju-core/+bug/1346597 after comment 4 looks all kinds of invalid to me
<mup> Bug #1346597: cannot get replset config: not authorized for query on local.system.replset <cloud-installer> <landscape> <oil> <juju-core:Triaged> <juju-core 1.22:Triaged> <https://launchpad.net/bugs/1346597>
<natefinch> wallyworld: it could be a bug... looking at the logs now
<wallyworld> ok
<natefinch> 862473
<wallyworld> perrito666: get well soon :-)
<perrito666> wallyworld: tx, I think soup and wather should get me on my feet soon and in the mean time getting some more sleep could help
<wallyworld> indeed.
<perrito666> anyway, comment 4 on taht bug says that the mongo was a leftover from a dirty machine
<wallyworld> perrito666: i could run your status-get hook tool to poll your health :-)
 * perrito666 imagines getting paper notes with rpc calls every couple of seconds
<wallyworld> perrito666: i *think* they said the latest occurrence was on a fresh instance, but am not sure
<perrito666> wallyworld: that bug means you are neither admin nor the machine-0 tag user (which is odd)
<wallyworld> perrito666: yeah, it may pay to ping jason on irc to ask some questions about their set up
<natefinch> I'm assuming any comments on that bug from earlier than this month are unrelated
<perrito666> you might notice in the logs that all credentials are empty in the dial info
<perrito666> anyway, I would ask for the agent.conf as it might shed some light, ill go to sleep before I die on my laptop bbl
<mup> Bug #1428074 was filed: api/networker and apiserver/networker tests fail <juju-core:New> <https://launchpad.net/bugs/1428074>
<mup> Bug #1428074 changed: api/networker and apiserver/networker tests fail <juju-core:New> <https://launchpad.net/bugs/1428074>
<mup> Bug #1428074 was filed: api/networker and apiserver/networker tests fail <juju-core:New> <https://launchpad.net/bugs/1428074>
<dimitern> dooferlad, btw I've discovered that (for maas at least) in addition to enabling ip forwarding we need to enable proxy_arp as well, otherwise containers on another host cannot resolve the state server's ip
<TheMue> dimitern: you've got a review
<dimitern> TheMue, thanks!
<TheMue> dimitern: yw
<TheMue> aaargh, once again a map ordering issue
<tasdomas> dimitern, re the bug I filed - I can still reproduce it using go 1.2.1 (built from source)
<dimitern> tasdomas, oh really? that's worse than I though then
<tasdomas> dimitern, the fact that nobody else has reproduced this makes me think that I'm doing something wrong
<dimitern> tasdomas, let me try
<wallyworld> dimitern: bug 1428074 - IMHO any test failure related to map ordering should be no lower than high, even critical
<mup> Bug #1428074: api/networker and apiserver/networker tests fail <juju-core:Triaged> <https://launchpad.net/bugs/1428074>
<dimitern> tasdomas, why don't you try using golang-go package from the trusty main archive?
<tasdomas> dimitern, that's what Im about to do
<wallyworld> they will fail on gccgo and for those of us running go > 1.2 (there are many)
<wallyworld> and they are easy to fix
<dimitern> wallyworld, I'm investigating
<wallyworld> ok
<wallyworld> ty
<dimitern> wallyworld, will change as needed
<wallyworld> i just saw the triage to medium :-)
<dimitern> wallyworld, I was not aware of that decision (about map ordering issues needing to be no less than high)
<dimitern> tasdomas, I can't reproduce it with 1.2.1 gccgo, which means it's not a map ordering issue then
<tasdomas> dimitern, it is or it isn't ?
<wallyworld> dimitern: it's my opinion - i think it's a fundamental code flaw that shold be fixed as it is almost guaranteed to fail unit tests
<dimitern> tasdomas, :) sorry - it is not
<dooferlad> dimitern: I have a fix without a new library. It does involve a change to juju/testing/checkers/checker.go though.
<dimitern> dooferlad, I'll have a look shortly
<wallyworld> deterministically failing tests are critical, especially those we can fix
<dimitern> dooferlad, why the change to checkers?
<dimitern> wallyworld, fair enough
<dooferlad> dimitern: so I can optionally dereference pointers in checkSameContents
<wallyworld> dimitern: ty. it means that gccgo and those of us running > 1.2 can get clean test runs
<dooferlad> dimitern: created a new check: SameContentsDeref
<wallyworld> and avoid nasty tech debt for later
<wallyworld> when we upgrade go toolchain
<dimitern> wallyworld, +1 that sgtm
<dimitern> tasdomas, bad news - I can't reproduce it with 1.4.2 either
<tasdomas> dimitern, great, thanks
<dimitern> tasdomas, I'll comment on the bug
<tasdomas> dimitern, ack
<dimitern> dooferlad, have you pushed the changes?
<dooferlad> dimitern: just doing so now
<dimitern> ok
<dooferlad> dimitern: pushed
<dooferlad> dimitern: https://github.com/juju/testing/compare/master...dooferlad:master-deref is the testing branch change
<dooferlad> dimitern: Oh, and I need to remove the change to dependencies.tsv. That will arrive shortly.
<dimitern> dooferlad, can you expand a bit why the Indirect was needed?
<dooferlad> dimitern: because comparing pointers wasn't useful :-) Basically, we were comparing two lists of pointers and reflect.DeepEqual wasn't following them, only examining their value.
<dooferlad> dimitern: or at least that seemed to be the case.
<dooferlad> dimitern: without the change, the test failed. With the change it passed 100 times in a row.
<mup> Bug #1428074 changed: api/networker and apiserver/networker tests fail <juju-core:Triaged> <https://launchpad.net/bugs/1428074>
<dimitern> dooferlad, ok, great
<dimitern> dooferlad, this change seems useful enough to be unconditionally applied to SameContents checker I think
<dooferlad> dimitern: do I propose the juju/testing branch in the same way as juju/juju?
<dimitern> dooferlad, but it needs more tests as well in juju/testing
<dooferlad> dimitern: seems reasonable
<dimitern> dooferlad, however, I'd like you to scan our juju/* repos for places SameContents is used and see if making the change will break anything
<dimitern> dooferlad, there should be a very few places indeed
<dimitern> dooferlad, as for how to propose it - the usual way - fork juju/testing to your account, wipe out your $GOPATH/src/github.com/juju/testing/ repo, clone your fork in the same place, add upstream remote to the master repo, etc.
<anastasiamac> dimitern: goamz v3 regions is missing 2 that i can see... is it possible or m i looking in the wrong place?
<dimitern> anastasiamac, which ones?
<anastasiamac> dimitern: EU (Frankfurt)	eu-central-1
<dimitern> anastasiamac, that one was never added
<dimitern> IIRC
<anastasiamac> dimitern: i was looking at prices and there is a price for it...
<anastasiamac> dimitern: another one that comes up is AWS GovCloud in US
<anastasiamac> dimitern: shall i just ignore these 2 then?...
<dimitern> anastasiamac, prices?
<dimitern> anastasiamac, you mean in juju source?
<anastasiamac> dimitern: http://aws.amazon.com/ec2/pricing/
<anastasiamac> dimitern: and putting updating them in juju for bug 1427840
<mup> Bug #1427840: ec2 provider unaware of c3 types in sa-east-1 <juju-core:In Progress by anastasia-macmood> <https://launchpad.net/bugs/1427840>
<dimitern> anastasiamac, oh, of course - they are indeed available and used (not sure about the gov one - you should be working for the us gov perhaps)
<dimitern> anastasiamac, but since both are fairly new goamz doesn't yet have them
<dimitern> anastasiamac, there was even a bug  filed somewhere that eu-central-1 is missing
<anastasiamac> dimitern: k, so m put n them in on our side intoec2/instancetype
<dimitern> anastasiamac, yes, unless you need them I think you can safely ignore them :)
<dimitern> anastasiamac, that was too concise for me to understand, sorry :)
<anastasiamac> dimitern: i think that i could get away with putting them into struct as string... and then goamz will need to be updated...
<anastasiamac> dimitern: m adding the prices for these 2 regions into ec2/instancetype as they are specified by string :D
<anastasiamac> dimitern: but on goamz side they r still missing as regions :D
<dimitern> anastasiamac, ah, so you do need them?
<anastasiamac> dimitern: if the pricing is on aws website, do i need to have it in juju?... I would have thought that the answer is "yes"
<anastasiamac> dimitern: unless our point of truth is goamz and not aws source...
<anastasiamac> dimitern: no?
<dimitern> anastasiamac, well, think about it this way: we only support what we have tested, so unless you need to test stuff on those regions and need the pricing for them
<dimitern> anastasiamac, then yes, add them but also update goamz and test it works on the new regions
<anastasiamac> dimitern: k. considering that we are close to 1.23, I'd rather file a bug and deal with these 2 rgions once we branch :D
<dimitern> anastasiamac, in any case I'd suggest posting a message to juju-dev first
<dimitern> anastasiamac, sgtm
<anastasiamac> dimitern: tyvm :D
<dimitern> TheMue, btw here's the PR with megawatcher tests I was talking about - https://github.com/juju/juju/pull/1588/files
<TheMue> dimitern: ah, great, just creating a card for it
<dimitern> TheMue, cheers!
<mup> Bug #1428117 was filed: EC2 eu-central-1 region not in provider <juju-core:New> <https://launchpad.net/bugs/1428117>
<mup> Bug #1428119 was filed: EC2 provider does not include C4 instance family <juju-core:New> <https://launchpad.net/bugs/1428119>
<wallyworld> natefinch: forgot to ask, you still working on bug 1415671 as it is assigned to 1.23 beta1?
<mup> Bug #1415671: Joyent provider uploads user's private ssh key by default <joyent-provider> <juju-core:Triaged by natefinch> <https://launchpad.net/bugs/1415671>
<natefinch> wallyworld: oh, sorry, I dropped the ball on that one.  I'll send an email to the list and maybe we can discuss at the team lead meeting if there's no resolution on it - it's kind of tricky.
<wallyworld> sure, ok
<natefinch> wallyworld: basically... the thought had been to generate an SSH key, but we can't just upload a new key for someone to their joyent account
<wallyworld> may need to do something that's less automatic but secure
<wallyworld> document the process
<natefinch> yep
<natefinch> I think the right answer might just be "you have to specify the SSH key in the config, and if you don't, we'll complain about it"
<natefinch> That's basically the way the rest of the providers work - you have to provide the auth, we don't make it for you
 * dimitern steps out for ~30m
<ericsnow> natefinch, wwitzel3: standup?
<ericsnow> dooferlad: I've followed up on your review request
<ericsnow> dooferlad: thanks for tackling that
<ericsnow> dooferlad: what can I do to help get that landed today?
<dooferlad> ericsnow: I just landed a change to juju/testing, which should be all I need now.
<dooferlad> ericsnow: just updating dependencies.tsv and re-testing
<ericsnow> dooferlad: you've already rebased/merged against master?
<dooferlad> ericsnow: yes, it is now ready to land once I have confirmed my change to juju/testing is being picked up correctly.
<ericsnow> dooferlad: sweet!
<katco> 0/?pli=1#inbox/who
<katco> lol oops
<mgz> #blameemacs
<katco> lol
<dimitern> mgz, hey there
<mgz> dimitern: I will have good news for you shortly
<dimitern> mgz, :) awesome
<mgz> dimitern: we may was to add a dependecy.tsv to goose at some point though, atm I've passing through at the merge level which is annoying if deps change
<dimitern> mgz,
<dimitern> mgz, sorry, could you rephrase that a bit? :)
<mgz> dimitern: we don't manage dependencies of goose currently (it only has a few) - if we get to adding more we may want something explicit like a dependencies.tsv otherwise a dep change means a jenkins job change
<mgz> any clearer?
<dimitern> mgz, yes, thanks
<dimitern> mgz, that sounds good to me - we'll add dependencies.tsv then
<mgz> don't need it quite yet, but worth it later I think
<dimitern> mgz, is that also the main obstacle to adding other sub-repos under the merge bot?
<mgz> nah, there are a few minor differences that mean it's some extra each time but it gets easier to add new jobs every time
<mgz> like, some of them down't pass their own test suites currently
<dimitern> ok, great
<mgz> so, it's just stuff to get fixed
<dimitern> really? that's pretty bad
<dimitern> mgz, I'd really appreciate if you can send me a list of these failures, if you have it
<ericsnow> fwereade: you free to meet?
<alexisb> dimitern, ping
<dimitern> alexisb, pong
<alexisb> hey there
<dimitern> hey, what's up?
<alexisb> for that mailing list thread "unit-get and ipv6 addresses"
<alexisb> we should have jake open a bug
<dimitern> yes, i've looked at it briefly, but still couldn't find a reason why it's happening
<dimitern> I'll respond and ask for a bug report
<alexisb> thanks
<dimitern> np
<dimitern> tasdomas, 994 is reviewed
<dimitern> alexisb, replied
<alexisb> dimitern, saw it and thank you
<ericsnow> dooferlad: thanks for landing that!
<dooferlad> ericsnow: no worries!
<tasdomas> dimitern, thanks
 * thumper sadface
<thumper> / The config generate here will be store in a config file and in the state DB.
<thumper> does not make grammatical sense
<thumper> it is like someone doesn't like 'd's
<perrito666> thumper: that is almost not politically correct
<natefinch> not everyone speaks english as a first language... I tend to give people a pass if they make minor grammatical errors (I do correct them, but don't make a big deal of it)
<natefinch> people that write unit tests which start web servers should be flogged
<perrito666> natefinch: not everyone speaks unit tests as a first testing choice... :p
<natefinch> :p
<thumper> lol
<natefinch> http: panic serving 127.0.0.1:52936: runtime error: slice bounds out of range
 * perrito666 had to google flogged, in Argentina is an anglicism meaning "added an entry in his/hers foto log"
 * thumper frowns
<thumper> I'm sure this code exists elsewhere
 * thumper hunts
<natefinch> joyent tests evidently run not one but two http servers
<perrito666> adding fields to status is a royal pain in the rear
<ericsnow> menn0: FYI, I addressed your comments in and added tests to http://reviews.vapour.ws/r/1059/
<menn0> ericsnow: looking
<mwhudson> thumper: i bet you know this, is there a way when using flag.FlagStr to tell the difference between the arg being passed with the default value and the arg not being passed?
<mwhudson> flag.StringVar rather
<menn0> ericsnow: ship it with tiny fixes
<ericsnow> menn0: cool, thanks
<mup> Bug #1428345 was filed: unit-get private-address returns ipv6 address <juju-core:New> <https://launchpad.net/bugs/1428345>
<mup> Bug #1428345 changed: unit-get private-address returns ipv6 address <juju-core:New> <https://launchpad.net/bugs/1428345>
<mup> Bug #1428345 was filed: unit-get private-address returns ipv6 address <juju-core:New> <https://launchpad.net/bugs/1428345>
<mup> Bug #1428345 changed: unit-get private-address returns ipv6 address <juju-core:New> <https://launchpad.net/bugs/1428345>
<mup> Bug #1428345 was filed: unit-get private-address returns ipv6 address <juju-core:New> <https://launchpad.net/bugs/1428345>
<perrito666> here I was trying to fix my 4 broken tests... now I have 15 ... how did that happened
<cherylj> mwhudson: I'm curious why you ask?  I think you could not set a default value (use ""), and then in the Init set that value if it's not specified
<mwhudson> cherylj: wanted to have a flag use a computed default value, but have -r "" be different
<mwhudson> it's probably a bad idea :)
<mwhudson> (it's also for something that's only going to be invoked by the go tool in practice so something more explicit can be done instead)
<cherylj> mwhudson:  ah, I was just curious.  I've been digging through the gnuflag docs to determine if there's a way to say you can only specify a flag once.
<thumper> anyone up for a quick review? http://reviews.vapour.ws/r/1076/diff/#
<ericsnow> thumper: I'll look
<thumper> ericsnow: cheers
<ericsnow> thumper: was it very hard adding that to GCE?
<thumper> nope
<ericsnow> thumper: oh good
<thumper> just moved functions around
<ericsnow> thumper: I've posted a review (just 1 issue to resolve)
#juju-dev 2015-03-05
<alexisb> anastasiamac, wallyworld is holding me up ;)
<alexisb> I will be there soon
<anastasiamac> alexisb: np - gives me more time to get ready
<katco> thumper: wow, i am never visiting NZ. bleck: http://www.buzzfeed.com/nicholaswray/nz-sux#.lweRbQN7Zl
<thumper> katco: yeah, it is terrible here
<sinzui> fwereade, et al, the run-unit-test script will now retry tagging ec2 instances so that you will see fewer failures setting up in git-merge-juju
<thumper> fwereade: the bot hates you
<fwereade> thumper, doesn't it just
<thumper> fwereade: wanna chat?
<fwereade> thumper, although I love it, because one time it was doing its job and preventing me from checking in shite
<fwereade> thumper, just a quick one, don't want to distract myself too much ;)
<alexisb> thumper, you beat me too it
<alexisb> fwereade, I think you need to send the bot some flowers and chocolates
<alexisb> or maybe some scotch??
<fwereade> alexisb, for sure :)
<alexisb> alrighty all, I am off to pick-up kiddo will be back tonight
<thumper> fwereade: I see it merged
<fwereade> thumper, one of them :)
<wallyworld> axw: one thing i forgot to mention in standup - tests on windows are broken because of various reasons, one of which is the loop stuff
<axw> wallyworld: ah, doh :(
<axw> I have no Windows machine ...
<wallyworld> i thought about it ages ago and then forgot
<wallyworld> yeah, i'll add a build directive
<wallyworld> axw: actually, looking at the code again, i recall we abstracted out all the *nix specific stuff in tests behind stubs/mocks, i think it's just filepath stuff that breaks things
<axw> wallyworld: is there a windows build job whose output I can look at?
<wallyworld> yeah, that's where i'm heading now, i believe there is
<mup> Bug #1428430 was filed: AllWatcher does not remove last closed port for a unit, last removed service config <api> <juju-core:Triaged> <https://launchpad.net/bugs/1428430>
<ericsnow_> menn0: would you mind taking another look at http://reviews.vapour.ws/r/1060/
<menn0> ericsnow_: looking
<ericsnow> menn0: thanks!
<wallyworld> axw: only 2 failing tests :-) trivial http://pastebin.ubuntu.com/10534173/
<axw> wallyworld: cool
<wallyworld> i'll fix (without windows machine but should be ok :-)
<alexisb> wallyworld, there is detailed instructions on the cloudbase site for testing windows workloads with juju
<alexisb> let me get the link
<alexisb> http://wiki.cloudbase.it/juju-testing
<alexisb> cmars, jam leads call?
<menn0> ericsnow: looking good to me. have you done some manual tests against actual systems with different init systems to make sure this all works?
<ericsnow> menn0: my local system (upstart) and a vm running systemd
<menn0> ericsnow: ok cool. then ship it.
<menn0> ericsnow: there's just one thing I raised (more an idea than an issue)
<ericsnow> menn0: I had considered it (reusing identifyExecutable), but wasn't convinced it would always be the same
<mup> Bug #1428439 was filed: retry-provisioning launches instances for containers; cannot retry containers at all <juju-core:Triaged> <https://launchpad.net/bugs/1428439>
<menn0> ericsnow: yeah, that's why I suggested it with some uncertaintity
<menn0> ericsnow: just leave it
<ericsnow> menn0: k
<ericsnow> menn0: thanks for the reviews
<menn0> ericsnow: np
<anastasiamac> axw: wallyworld: https://github.com/go-amz/amz/pull/34
<axw> anastasiamac: looking
<dimitern> now that's much better - from 58 PRs down to 38
 * thumper is done
<thumper> laters
<anastasiamac> axw: wallyworld: tyvm for review :D all updated but I do not have merge rights on goamz...
<wallyworld> np, i can do it
<wallyworld> anastasiamac: merged
<wallyworld> one more branch to go
<wallyworld> axw: did you have anything to say wrt that maas doc the other day?
<axw> wallyworld: I added comments already
<wallyworld> ah, ty. i need to learn how to use refreah i think
<axw> wallyworld: essentially, LGTM.
<wallyworld> great
<anastasiamac> wallyworld:  when u say "1 more branch",  which one u have in mind? ec2 pricing?
<wallyworld> anastasiamac: updating the current juju core branch to add instance types, depes, and pricing yeah
<anastasiamac> wallyworld: k :D
<anastasiamac> axw: wallyworld: pricing branch http://reviews.vapour.ws/r/1073/
<wallyworld> already looking
<anastasiamac> wallyworld: i *think* i've fixed bad formatting ...
<anastasiamac> wallyworld: tabs vs spaces, etc...
<wallyworld> yep, looks much beter
<wallyworld> anastasiamac: and there's no cost info for chinese regions?
<anastasiamac> wallyworld: i could not find any chines prices... maybe they r on chinese site but I do not read chines :(
<anastasiamac> wallyworld: i have looked at chines site in english but nothing...
<anastasiamac> chinese*
<wallyworld> hmmm, i can't see how juju would work in china then as instance selection is broken without cost info from what i can see
<anastasiamac> do we have any means of testing ?..
<wallyworld> not easily
<anastasiamac> wallyworld: unless we put 0 for everything?...
<wallyworld> it's mor ethan just cost, it's also knowing what instance types are available
<anastasiamac> wallyworld: would it be a separate bug tho? so this PR added frankfurt for bug 1428117 and c4+others for bug 1427840
<mup> Bug #1428117: EC2 eu-central-1 region not in provider <juju-core:In Progress by anastasia-macmood> <https://launchpad.net/bugs/1428117>
<mup> Bug #1427840: ec2 provider unaware of c3 types in sa-east-1 <juju-core:In Progress by anastasia-macmood> <https://launchpad.net/bugs/1427840>
<wallyworld> yeah
<wallyworld> anastasiamac: fix axw's issue and then ship
<wallyworld> anastasiamac: chinese instance types http://www.amazonaws.cn/en/ec2/details/
<wallyworld> so we can add those before shipping
<wallyworld> set all costs to 0 or something if no cost info can be found
<anastasiamac> wallyworld: k but what shall i add for price? 0...?
<anastasiamac> wallyworld: k
<wallyworld> anastasiamac: school pickup time back later, andrew can check the final branch before landing
<anastasiamac> wallyworld: school pickup but will try to repropose for axw :D
<anastasiamac> axw:wallyworld: btw, i'll try to do the same with USGov region as with  China - just add instance types with 0 cost
<jw4> per special request by marcoceppi for 1.23 - juju action status now returns multiple matches or all if no prefix is given: OCR PTAL http://reviews.vapour.ws/r/1085/
<axw> jw4: added some comments
<axw> wallyworld: responded to your comments on my branch, would appreciate another look when you've got time
<anastasiamac> axw: wallyworld is delayed - car broke down :(
<axw> doh
<anastasiamac> axw: yep :( dunno what's with the car but it's realllly hot here today
<mup> Bug #1425788 changed: multiple definition of http.HandlerFunc <ci> <gccgo> <regression> <test-failure> <juju-core:Fix Released by dimitern> <https://launchpad.net/bugs/1425788>
<mup> Bug #1292536 changed: maas provider apt-get install bridge-utils should  be better <maas-provider> <network> <tech-debt> <juju-core:Fix Released> <https://launchpad.net/bugs/1292536>
<mup> Bug #1377262 changed: please expose network-bridge to manual provider also <cts> <cts-cloud-review> <maas-provider> <network> <juju-core:Won't Fix> <https://launchpad.net/bugs/1377262>
<mup> Bug #1314442 changed: MAAS non-deterministic private-address with non-ethN interfaces <addressability> <canonical-is> <maas-provider> <network> <production> <juju-core:Fix Released> <https://launchpad.net/bugs/1314442>
<wallyworld> axw: sorry about delay, car broke, heavy traffic, waited ages for tow truck
<axw> wallyworld: no worries. that sucks :(
<wallyworld> yeah, clutch cylinder i think
<axw> wallyworld: doh, I think anastasiamac may have forgotten to upload her changes before merging
<axw> other things weren't updated either
<wallyworld> axw: yeah, i figured that after seeing another issue that was unresolved
<axw> anastasiamac: I'm definitely looking at the latest diff on RB
<axw> I'll check GitHub
<anastasiamac> wallyworld: axw: my bad - did not push :D
<anastasiamac> fixing it noww...
<anastasiamac> axw: wallyworld: probably cleaner as separate pr?.. :D http://reviews.vapour.ws/r/1087/
<axw> anastasiamac: LGTM
<anastasiamac> axw: :P
<anastasiamac> axw: brain-numbing experience over :D tyvm for urs and wallyworld attention to detail!!
<axw> anastasiamac: :)
<axw> jam: team meeting, if you want to join
<dimitern> TheMue, dooferlad_, guys let's do our standup now?
<dooferlad_> dimitern: sure
<TheMue> dimitern: omw
<dimitern> I'm in the hangout
<axw> katco: I'd appreciate another look over my branch in your day, I've responded to your comments - thanks
<jw4> axw: I assume you're off now, but thanks for the review
<jw4> TheMue: thanks for your review - do you want to give it one last pass before merging? http://reviews.vapour.ws/r/1085
<TheMue> jw4: sure
<TheMue> jw4: looks good now
<jw4> TheMue, ta
<TheMue> jw4: yw
<marcoceppi> is the environment UUID per .jenv file or is it per bootstrap?
<marcoceppi> if i create an environment, bootstrap, destroy, bootstrap again does it have the same UUID?
<perrito666> natefinch: standup?
<natefinch> perrito666: oops, lost track of time, thanks
* ChanServ changed the topic of #juju-dev to: https://juju.ubuntu.com | On-call reviewer: see calendar | Open critical bugs: 1428692
<sinzui> natefinch, dimitern (and ericsnow) I reported bug 1428692 about a vivid regression
<mup> Bug #1428692: cannot boostrap vivid: Operation failed: No such file or directory <ci> <local-provider> <regression> <vivid> <juju-core:Triaged> <https://launchpad.net/bugs/1428692>
<ericsnow> sinzui: yep, saw that :(
<ericsnow> sinzui: BTW, sounds like the systemd cutover is scheduled for today
<sinzui> ericsnow, I did a dist-upgrade on the machine and cleared containers hoping the issue was a stale machine
<ericsnow> sinzui: so that test would be failing either way
<sinzui> ericsnow, the test now runs with --debug to get more info too
<ericsnow> sinzui: unfortunately the logs for the failed job aren't too informative
<ericsnow> sinzui: --debug will help
<ericsnow> sinzui: so thanks
<perrito666> ericsnow: wallyworld natefinch http://ftp.osuosl.org/pub/fosdem//2015/devroom-go/
<ericsnow> perrito666: cool
<perrito666> word of advice, your wife will scold you if you try to watch those on the big tv during dinner
<sinzui> dimitern, you made bug 1428345 high. Which milestone does it go to? 1.23-beta1 or 1.24?
<mup> Bug #1428345: unit-get private-address returns ipv6 address <addressability> <ipv6> <manual-provider> <network> <juju-core:Triaged> <https://launchpad.net/bugs/1428345>
<mup> Bug #1428692 was filed: cannot boostrap vivid: Operation failed: No such file or directory <ci> <local-provider> <regression> <vivid> <juju-core:Triaged> <https://launchpad.net/bugs/1428692>
<mup> Bug #1428692 changed: cannot boostrap vivid: Operation failed: No such file or directory <ci> <local-provider> <regression> <vivid> <juju-core:Triaged> <https://launchpad.net/bugs/1428692>
<mup> Bug #1428692 was filed: cannot boostrap vivid: Operation failed: No such file or directory <ci> <local-provider> <regression> <vivid> <juju-core:Triaged> <https://launchpad.net/bugs/1428692>
<jw4> mup, bad boy
<mup> jw4: Roses are red, violets are blue, and I don't understand what you just said.
<dimitern> sinzui, hey, yes I did, but it's still getting investigated - so 1.24 I guess
<mup> Bug #1428692 changed: cannot boostrap vivid: Operation failed: No such file or directory <ci> <local-provider> <regression> <vivid> <juju-core:Triaged> <https://launchpad.net/bugs/1428692>
<mup> Bug #1428692 was filed: cannot boostrap vivid: Operation failed: No such file or directory <ci> <local-provider> <regression> <vivid> <juju-core:Triaged> <https://launchpad.net/bugs/1428692>
<sinzui> thank you dimitern
<mup> Bug #1428692 changed: cannot boostrap vivid: Operation failed: No such file or directory <ci> <local-provider> <regression> <vivid> <juju-core:Triaged> <https://launchpad.net/bugs/1428692>
<mup> Bug #1428692 was filed: cannot boostrap vivid: Operation failed: No such file or directory <ci> <local-provider> <regression> <vivid> <juju-core:Triaged> <https://launchpad.net/bugs/1428692>
<dimitern> mup is heading for an excessive flood quit message
<mup> Bug #1428692 changed: cannot boostrap vivid: Operation failed: No such file or directory <ci> <local-provider> <regression> <vivid> <juju-core:Triaged> <https://launchpad.net/bugs/1428692>
<mup> Bug #1428692 was filed: cannot boostrap vivid: Operation failed: No such file or directory <ci> <local-provider> <regression> <vivid> <juju-core:Triaged> <https://launchpad.net/bugs/1428692>
<mup> Bug #1428692 changed: cannot boostrap vivid: Operation failed: No such file or directory <ci> <local-provider> <regression> <vivid> <juju-core:Triaged> <https://launchpad.net/bugs/1428692>
<mup> Bug #1428692 was filed: cannot boostrap vivid: Operation failed: No such file or directory <ci> <local-provider> <regression> <vivid> <juju-core:Triaged> <https://launchpad.net/bugs/1428692>
<mup> Bug #1428692 changed: cannot boostrap vivid: Operation failed: No such file or directory <ci> <local-provider> <regression> <vivid> <juju-core:Triaged> <https://launchpad.net/bugs/1428692>
<mup> Bug #1428692 was filed: cannot boostrap vivid: Operation failed: No such file or directory <ci> <local-provider> <regression> <vivid> <juju-core:Triaged> <https://launchpad.net/bugs/1428692>
<mup> Bug #1428692 changed: cannot boostrap vivid: Operation failed: No such file or directory <ci> <local-provider> <regression> <vivid> <juju-core:Triaged> <https://launchpad.net/bugs/1428692>
<mup> Bug #1428692 was filed: cannot boostrap vivid: Operation failed: No such file or directory <ci> <local-provider> <regression> <vivid> <juju-core:Triaged> <https://launchpad.net/bugs/1428692>
<perrito666> dimitern: mup is heading for a kick in the head
<perrito666> I am not sure what is triggering those, when I see the bug there seems to be no changes
<dimitern> mup, shut up
<mup> dimitern: I really wish I understood what you're trying to do.
<dimitern> perrito666, it's seeing somebody (itself) mentioning bug # and goes
<dimitern> bug 1428692
<mup> Bug #1428692: cannot boostrap vivid: Operation failed: No such file or directory <ci> <local-provider> <regression> <vivid> <juju-core:Triaged> <https://launchpad.net/bugs/1428692>
<ericsnow> mup is taunting me
<dimitern> lol
<ericsnow> mup, sit
<mup> ericsnow: Unknown commands are unknown.
<ericsnow> mup, stay
<mup> ericsnow: In-com-pre-hen-si-ble-ness.
<perrito666> dimitern: most bots have a feat not to listen to themselves
<dimitern> perrito666, yeah, but this one is written in erlang ;)
<perrito666> dimitern: I thought this thing was written in go
<perrito666> or I missed a joke there
<dimitern> perrito666, https://launchpad.net/mup
<dimitern> :) no joke - it's a dead serious language lol
 * TheMue reads Erlang?
<TheMue> didn't know that it's written in a cool language
<perrito666> dimitern: https://github.com/go-mup/mup
<perrito666> TheMue: erlang is a fine language, if you are an ericsson telephone central
<katco> mup used to be written in erlang, niemeyer ported it to go
<TheMue> perrito666: or a couchdb or rabbitmq or ejabberd develoepr (and many more)
<Spads> no, couchdb developers did not really know erlang
<dimitern> :D
<TheMue> maybe, never looked into the couch details
<perrito666> TheMue: I agree there are many things written in erlang, yet its not cool in all contexts :p
<TheMue> perrito666: would write a mobile game app with it, yes
<TheMue> perrito666: but for something like juju it would be fine
<niemeyer> perrito666, dimitern, TheMue, katco, ericsnow: Sorry for the trouble.. Launchpad seems to be giving inconsistent results, likely as a side effect of caching+balancing
<niemeyer> It's not listening to itself, though.. note the filed/changed/filed/changed/etc
<TheMue> niemeyer: mup simply has been lonely and wanted to talk to us
<perrito666> niemeyer: you took the trouble to write the thing, no need to apologize, we are just curious on what was the cause
<dimitern> niemeyer, ah, I thought something more sinister was happening :)
<katco> TheMue: i like that explanation :)
<niemeyer> I will increase the delay between updates, to give time for Launchpad to update its internal cache
<perrito666> I see you are hitting the same change in different caches each time, that is  an odd thing for launchpad to do
<dimitern> sinzui, is it possible to change http://bazaar.launchpad.net/~juju-qa/juju-ci-tools/trunk/view/head:/jujupy.py#L284 so it calls subprocess.check_output(args, env=env) instead of check_call ?
<sinzui> dimitern, no because we already have get_juju_output() whcih does that. what callsite needs to look at the output?
<dimitern> sinzui, well, looking at that vivid failure it's hard to understand whether "Operation failed: No such file or directory" comes from juju bootstrap's output or something else
<dimitern> sinzui, for example, it could be coming from dump_env_logs in the except BaseException as e: block below
<dimitern> sinzui, no, actually not that block, but the previous try that ends with a raise
<sinzui> dimitern, I don't think your going to see more information by switching which method we call. We are seeing the stdout and stderr in the console log already. The output captured would be the same as we are seeing now
<dimitern> sinzui, I guess so
<sinzui> dimitern, I am going to run this my hand on the machine to see if I get something more
<dimitern> sinzui, thanks!
<dimitern> sinzui, while you're there can you check if it runs out of disk space (or mongo runs out of the prealloc block)?
<dimitern> sinzui, it just *smells* like a mongo issue - i've just noticed juju-mongodb in vivid is /usr/lib/juju/bin/mongod --version: "db version v2.4.10\nThu Mar  5 15:00:16.736 git version: nogitversion\n"
<dimitern> sinzui, while in the cloud-tools, in trusty and pretty much everywhere we run and test with officially it's 2.4.9-0ubuntu3
<aisrael> sinzui: FYI, this bug doesn't seem to be fixed: https://bugs.launchpad.net/juju-core/+bug/1424069
<mup> Bug #1424069: juju resolve doesn't recognize error state <resolved> <juju-core:Fix Released> <https://launchpad.net/bugs/1424069>
<sinzui> dimitern, sorry this is taking longer. I just verified other juju do work on the machine. Mongo doesn't seem to be a factor with 1.21 and 1.22
<dimitern> sinzui, is it the same version?
<sinzui> dimitern, yes, there is only one mongod on the host
<dimitern> sinzui, and where is that one ("gitnorevision"?) coming from
<sinzui> dimitern, I don't know.
<sinzui> dimitern, we are testing a package we built else where on the vivid machine. the machine was dist-upgraded to get the current packages, of which juju-db will be selected
<dimitern> sinzui, ok, so this is the first time we're actually testing with that version of mongo?
<sinzui> dimitern, I think so. I see juju-mongodb at 2.4.10-0ubuntu1
<sinzui> dimitern, this is the log from the manual run https://bugs.launchpad.net/juju-core/+bug/1428692/+attachment/4335369/+files/vivid-bootstrap.log
<mup> Bug #1428692: cannot boostrap vivid: Operation failed: No such file or directory <ci> <local-provider> <regression> <vivid> <juju-core:Triaged> <https://launchpad.net/bugs/1428692>
<dimitern> sinzui, ok, looking - thanks!
<sinzui> dimitern, though the bootstrap failed, the mongod is still up. Is there anything you want me to do to interrogate it?
<dimitern> sinzui, I'd appreciate you can paste cloud-init-output.log and /var/log/syslog where mongo logs a lot
<dimitern> sinzui, or if there's nothing mongo related in syslog, then /var/log/mongodb/mongod.log if it exists
<sinzui> dimitern, this is the cloud-init-output.log https://pastebin.canonical.com/127005/
<dimitern> ok, thanks again
<dimitern> sinzui, that's how it ends? well, we'll need to look at /var/log/cloud-init.log then just in case - it should say "cloud-init ver finished" etc.
<sinzui> dimitern, I don't see that. remember that this is a localhost
<dimitern> sinzui, ah, right
<dimitern> sinzui, so then it's not strange
<dimitern> sinzui, and you can confirm the machine is not out of disk space, right?
<sinzui> dimitern, 26G free
<dimitern> sinzui, ok, good
<sinzui> dimitern, there are no logs for the mongo in the juju home dir or in /var/log
<dimitern> sinzui, and you said it's still running?
<dimitern> sinzui, is it listening on 37017?
<sinzui> dimitern, I see the pid
<sinzui> dimitern, I think this is just a zombie left behind from a failed destroy. Juju removed itself from the system, but left the juju-db behind
<dimitern> sinzui, and there's nothing you say in /var/log/syslog or /var/log/* about mongo?
<sinzui> dimitern, There are lines in the syslog. I am collecting them
<dimitern> sinzui, good
<sinzui> dimitern, this is from my run bootstrapped https://pastebin.canonical.com/127008/
<cmars> anyone see map ordering-type failure in firewallerSuite.TestWatchOpenedPorts ?
<cmars> go1.4 here
<sinzui> aisrael, okay, I will reopen the bug
<mup> Bug #1424069 was filed: juju resolve doesn't recognize error state <resolved> <juju-core:Triaged> <https://launchpad.net/bugs/1424069>
<mup> Bug #1424069 changed: juju resolve doesn't recognize error state <resolved> <juju-core:Triaged> <https://launchpad.net/bugs/1424069>
<mup> Bug #1424069 was filed: juju resolve doesn't recognize error state <resolved> <juju-core:Triaged> <https://launchpad.net/bugs/1424069>
<mup> Bug #1424069 changed: juju resolve doesn't recognize error state <resolved> <juju-core:Triaged> <https://launchpad.net/bugs/1424069>
<mup> Bug #1424069 was filed: juju resolve doesn't recognize error state <resolved> <juju-core:Triaged> <https://launchpad.net/bugs/1424069>
<sinzui> cmars, that test doesn't fail on vivid which is using go1.3
<dimitern> sinzui, looking
<dimitern> cmars, haven't checked recently with 1.4
<dimitern> sinzui, ok so now that's some error in there
<dimitern> sinzui, did you stop mongod manually?
<cmars> dimitern, sinzui should i open a bug? http://paste.ubuntu.com/10541924/
<cmars> sinzui, here it is: https://bugs.launchpad.net/juju-core/+bug/1428788
<mup> Bug #1428788: Probabilistic test failure in firewallerSuite.TestWatchOpenedPorts <juju-core:New> <https://launchpad.net/bugs/1428788>
<mup> Bug #1428788 was filed: Probabilistic test failure in firewallerSuite.TestWatchOpenedPorts <juju-core:New> <https://launchpad.net/bugs/1428788>
<dimitern> cmars, I seem to recall a bug about this or similarly named test - can you check if there is one already?
<cmars> dimitern, looking
<cmars> dimitern, i see no obvious matches
<sinzui> cmars, you can at medium tagged intermittent-failure. CI only saw 1 failure with that test a few days ago on ppc64el gccgo. It was a panic, not an assert failure
<cmars> sinzui, idk if that's the same thing. does gccgo even scramble map ordering? I forget..
<sinzui> cmars, it does. it behaves like go1.3's spec
<sinzui> cmars, but vivid is go 1.3 and we haven't seen tht failure
<cmars> sinzui, not yet :)
<perrito666> sinzui: well its a non deterministic failure, I presume that if you constraint enough the memory you will see it
<dimitern> sinzui, so were there 2 mongod running on that machine? one from juju and another one?
<sinzui> dimitern, I didn't see one. I only terminated the single pid
<sinzui> dimitern, remember that we run other jujus that they don't fail
<sinzui> dimitern, The machine is very idle right now I can run the job again
<sinzui> dimitern, only one job can use the machine at a time. so it is unlikely for another to be up. if one was, the call to destroy-environment --force would remove it. That is what I called to ensure the mongo was removed
 * sinzui rebuilds and inspects which procs are left behind
<dimitern> sinzui, ok, seems all in order then
<dimitern> sinzui, I mean it's not mongo most likely, but I was really suspicious due to the version and some bug reports for 2.4.10 I've read :)
<sinzui> dimitern, we got the expected failure and I can see a mongo was left behind
<dimitern> sinzui, was that mongo there before the bootstrap?
<sinzui> no
<sinzui> i dimitern it was just created and left behind by the juju. it claims to have destroyed the env, but it did not
<sinzui> dimitern, all tests start with destroy-environment --force to be sure the env is clean
<sinzui> dimitern, I am setting up an upgrade test on the machine that will show you that other jujus are happy
<dimitern> sinzui, ok, sounds good
<niemeyer> perrito666, dimitern, TheMue, katco, ericsnow: The delay was updated.. please let me know if you see any other issues
<ericsnow> niemeyer: k, thanks
<katco> niemeyer: ty!
<perrito666> niemeyer: thanks a lot, sorry for the complaining
<niemeyer> perrito666: No worries, and totally justified
<TheMue> niemeyer: thanks for update, and never has been meant as complain
<ericsnow> anyone PTAL (revert vivid-breaking merge): http://reviews.vapour.ws/r/1090/
<sinzui> dimitern, good news of sorts. http://juju-ci.vapour.ws:8080/job/local-upgrade-vivid-amd64/3/ shows other juju bootstrap, but we cannot upgrade. Since we had a server running. we got logs
<natefinch> ericsnow: ship it
<ericsnow> natefinch: thanks
<natefinch> ericsnow: I just skimmed it... it 's just a revert, so I trust that there shouldn't be much to go wrong.  .... which makes me wish there was a tool that could just look at this and say "yep, this is just a revert of that other change".
<dimitern> sinzui, great!
<dimitern> sinzui, I'll have a look tomorrow though - it was a rather long day
<sinzui> thank you for your time dimitern
<dimitern> not at all :)
<perrito666> natefinch: it would be nice if we could get the bot to trigger reverts from github
<perrito666> with a $$unmerge$$ or smth like that
<natefinch> perrito666: that's brilliant
<natefinch> Btw, for those interested, Brian Kernighan (the K in K&R's C Programming) is writing a book on Go: http://www.amazon.com/Programming-Language-Addison-Wesley-Professional-Computing/dp/0134190440/
<mgz> perrito666: revert isn't an entirely automatic process, the merge can need manual resolution
<perrito666> dunno K&D does not soound as cool as K&R :p
<mgz> (could be done in the common case though)
<perrito666> mgz: I believe that github only offers it after doing the same analisys that it does for merge
<perrito666> man, processAgent is an elussive piece of code
<ericsnow> sinzui: I've landed a revert of what I believe is the merge that broke the vivid test
<sinzui> thank you ericsnow
<ericsnow> sinzui: I expect that it will also clear up the issue of the zombie mongod
<jw4> natefinch, per davecheney command I've pre-ordered the book
<perrito666> jw4: wow he has such commands? how does it work? is it something like davecheney order book?
<jw4> perrito666, hahah
<natefinch> jw4: it'll be good.  K&R's C influenced a generation of programmers.
<perrito666> natefinch: you do need to bear in mind that is that generation that coded the pieces of code we hate the most :p
<natefinch> ericsnow: you around?
<ericsnow> natefinch: yep
<natefinch> "there was an error displaying this diff": http://reviews.vapour.ws/r/861/diff/#
<natefinch> It says to please try again... does that mean like rbt post or something?
 * natefinch forgets how to do this stuff manually
 * TheMue has to refresh his Go book, it's already 4 years old
<natefinch> TheMue: there aren't many good choices right now.  There's this upcoming Kernighan one, plus some of the Gophercon people are working on one
<jw4> TheMue, that's the problem with being an early adopter - all the investment into books when the technology is really young
<jw4> natefinch, agree about K&$
<jw4> K&R too
<perrito666> I wonder if it comes for kindle
<natefinch> The Gophercon guys are writing this one: http://www.manning.com/ketelsen/
<TheMue> jw4: funnily Go hasn't changed a lot since then, only details. but more experience about common patterns
<TheMue> jw4: and surely the packages
<ericsnow> natefinch: I've been seeing that more frequently of late
<jw4> TheMue, yeah
<TheMue> jw4: and mine is sadly only available in German
<ericsnow> natefinch: it may be that unicode characters are starting to leak into commits (I've seen RB struggle with unicode)
<ericsnow> natefinch: but it's probably not that
<ericsnow> natefinch: did you do a rebase in there somewhere?  that can confuse RB
<natefinch> ericsnow: yes. :/
 * natefinch loves teh rebase
<ericsnow> natefinch: I expect that's it
<natefinch> I didn't realize reviewboard didn't like it
<ericsnow> natefinch: it's hit and miss
<ericsnow> natefinch: I haven't looked into it too hard
<jw4> I use rebase all the time and haven't had an issue yet...:(
<jw4> I wonder what the secret ingredient is that triggers RB
<ericsnow> natefinch: try using rbt -u to update the review request
<natefinch> ericsnow: rbt is asking for authorization... remind me how to do that?
<ericsnow> I think it's when you rebase and have a conflict that you have to resolve (so history changes)
<ericsnow> natefinch: it's in docs/contributing/reviewboard...
<ericsnow> natefinch: I'll look it up
<ericsnow> natefinch: "username: <github username> password: oauth:<github username>@github"
<natefinch> ericsnow: ok, thanks... I could have looked it up, just forgot where itwas
<ericsnow> natefinch: no worries
<natefinch> ericsnow: that did it, thanks
<ericsnow> natefinch: cool, thanks
<ericsnow> natefinch: I think RB stores the base revision when you first create the request (or the hook does for you)
<ericsnow> natefinch: I probably just need to fix the hook to be cognizant of changes to the base revision
<jw4> ericsnow, ah, that sounds like a plausible root cause for the display conflicts after rebasing when the base revision changes significantly
<natefinch> conflicts?  Son of a....
<ericsnow> yeah, he said conflicts :)
<jw4> haha
<ericsnow> jw4: if it gets to be much of a problem I'll look into fixing the hook
<jw4> ericsnow, you've done a lot of work to give us nice review tools, thanks
<natefinch> no no.. sorry, my branch has conflicts with master... in that file that was having problems. That may have been what caused RBT to puke
<natefinch> ericsnow, jw4: +1
<ericsnow> natefinch: ah hah
<perrito666> go test github.com/juju/juju/cmd/juju/... takes too long
<ericsnow> perrito666: right up there with replicaset
<natefinch> man yaml is terrible
<perrito666> anyone knows where the filtering happens for juju status comand?
<perrito666> I think I found it
<perrito666> there is a LOT of unhappy poorly documented unclear code in the filtering
<ericsnow> sinzui, natefinch: Monday is D-Day: https://lists.ubuntu.com/archives/ubuntu-devel-announce/2015-March/001130.html
<sinzui> thank you eric
<sinzui> ls  /var/lib/mongodb/
<sinzui> ls  /var/log/mongodb/
<sinzui> ls /etc/default/mongodb
<jw4> sinzui, wrong window?
<sinzui> jw4, yes, thank you
<jw4> lol :)
<jw4> I thought a ping might help
<thumper> perrito666: filtering of what?
<perrito666> thumper: nevermind, tx, I was trying to make sure I had all the right pieces added to BuildPredicate and surounding code
<perrito666> I did
<perrito666> that could really benefit from a couple of comments
<perrito666> ok EOD
<perrito666> cheers
<jw4> cheers perrito666
<ericsnow> cmars: any reason why you have 2 review requests up for mongo logs?
<cmars> ericsnow, rbt freaked out on me. deleted the first one
<ericsnow> cmars: I've reviewed your mongod log patch
<cmars> ericsnow, thanks
<ericsnow> cmars: np :)
<cmars> ericsnow, i'm thinking of adding --quiet as well. you could always turn that on with the mongo setParameter command if you needed the replication info
<cmars> currently bootstrapping with that option enabled
<ericsnow> cmars: or a feature flag <wink>
<cmars> ericsnow, ooh good point
<ericsnow> cmars: it could also key of juju's debug level
<cmars> ericsnow, interesting.. how would I read that?
<ericsnow> cmars: no clue :)
 * ericsnow takes off on an errand for a bit
<mup> Bug #1428893 was opened: agent-state-info: no matching tools available <oil> <juju-core:New> <https://launchpad.net/bugs/1428893>
<cmars> ericsnow, updated 1093
<ericsnow> cmars: LGTM (but I'm not a senior reviewer)
<cmars> ericsnow, thanks!
#juju-dev 2015-03-06
<wallyworld_> thumper: ?
<thumper> wallyworld_: sorry
<wallyworld_> thumper: np, chat now?
<thumper> sure
<axw> anastasiamac: re http://aws.amazon.com/ec2/pricing/, I was looking at spot instances - I see it says unspecified in the on-demand section as you said
<axw> weird
<anastasiamac> axw: yes, if you look at sao paolo region, it shriks the list of supported instances
<anastasiamac> axw: i deduced that frankfurt *could* have the types marked as **unspecified**
<anastasiamac> axw: but m happy to let it rest for now
<anastasiamac> axw: :D it's amazing what an effect a small change can have :))
<axw> :)
<ericsnow> could someone spare me a review on http://reviews.vapour.ws/r/1094/
<ericsnow> it un-reverts an earlier patch and adds logging
<ericsnow> it will help me sort out the vivid issues
<anastasiamac> ericsnow: *un-reverts*? u must b having soo much fun :D
<ericsnow> anastasiamac: imagine bamboo and fingernails
<axw> katco: are you still around? did you have anything more to say on the remaining open points on http://reviews.vapour.ws/r/1071/ ?
<wallyworld_> axw: free whenever you are
<axw> wallyworld_: omw
<mattyw> axw, ping?
<axw> mattyw: pong
<TheMue> morning o/
<menn0> dimitern: ping
<dimitern> menn0, pong
<menn0> dimitern: did you see that email about issues with using MongoDB unique indexes with mgo/txn?
<dimitern> menn0, probably, but can you remind me the gist?
<menn0> dimitern: basically you can't really use mgo/txn with a unique index
<menn0> dimitern: if there's a unique index collision, the txn will appear to have worked (no error returned)
<dimitern> menn0, because it returns nil on violation?
<menn0> dimitern: but the insert into the collection with index fails, and any other ops succeed
<menn0> dimitern: so you end up with partial application
<dimitern> menn0, yeah, nasty
<menn0> dimitern: I mention it to you because there's a bunch of networking related collections in Juju with unique indexes
<menn0> dimitern: there's 2 ways around it
<menn0> dimitern: 1. check for the failed insert afterwards and clean up any docs in other collections that shouldn't have been inserted
<dimitern> menn0, have you looked at the code that handles the nil result?
<menn0> dimitern: 2. introduce another collection which has docs which have the index key as the _id and Assert on that as part of the txn (instead of using a unique index)
<menn0> dimitern: the code where?
<dimitern> menn0, ok, these pointers are good to know, thank you
<menn0> dimitern: there's a simple example linked to from the email (see the quoted bit at the bottom of Gustavo's reply)
<dimitern> menn0, but so far I think the only place we're using unique indexes are for networks
<dimitern> menn0, and they are handled correctly - check AddNetwork and AddNetworkInterface
<menn0> dimitern: I hadn't checked the networking code. I just saw the indexes there and figured that this situation might not have been handled.
<menn0> dimitern: looks like you guys already knew about this.
<menn0> dimitern: we're probably going to go with option 2 for the case where Jesse ran into this today (not allowing multiple envs with the same name for a single owner)
<menn0> dimitern: (a separate collection which tracks the uniqueness constraint)
<dimitern> menn0, what I wasn't quite aware of is that just the insert fails, and to watch out for partially succeeded ops in other collections
<menn0> dimitern: yeah, it's pretty subtle
<menn0> dimitern: i've looked at the mgo/txn code in question and see why this happens.
<menn0> dimitern: mongodb doesn't return specific enough error codes for it to be able to handle this any better
<dimitern> menn0, even more recent versions of mongo?
<menn0> dimitern: yeah. i don't think this has been fixed. basically "document already exists" and "index unique violation" are returned as the same error (and they kind of are if you think about it). but mgo/txn needs to know the difference.
<menn0> brb
<dimitern> I see :/
<menn0> dimitern: so anyway, now you know :)
<menn0> dimitern: AddNetworkInterface is fine because although it involves several collections, it only inserts into one
<menn0> dimitern: AddNetowork is fine too because it only involves one collection.
<dimitern> menn0, ok, thanks for checking, and I'll keep that in mind for other of our cases - should we need unique indexes
<menn0> dimitern: kk
* ChanServ changed the topic of #juju-dev to: https://juju.ubuntu.com | On-call reviewer: see calendar | Open critical bugs: none
<TheMue> dimitern: dooferlad: thx, test works now
<dimitern> TheMue, o/o
<dimitern> TheMue, \o/ even :)
<TheMue> dimitern: *lol*
<mattyw> davecheney, ping?
<dimitern> mattyw, hey there - have you seen my review of 994?
<mattyw> dimitern, I have - thank you very much, I'm mid changes at the moment, will be pinging when I'm done
<dimitern> mattyw, cheers
<mattyw> dimitern, thanks for taking a look - and thanks for the comments, all good stuff
<dimitern> mattyw, no worries - I'm happy to see the proposal improved considerably
<mattyw> dimitern, +1k
<dimitern> dooferlad, here's my branch - https://github.com/dimitern/juju/tree/container-addressability-fixes I've just confirmed with those changes and lxc-clone: false I successfully deployed 2 nodes with 2 containers each, and was able to do juju ssh x/lxc/y where x and y are [0,1] on EC2
 * dimitern steps out for ~1h
 * TheMue -> lunch
<dimitern> dooferlad, ping
<dooferlad> dimitern: hi
<dimitern> dooferlad, I've discovered a disturbing issue
<dooferlad> dimitern: ?
<dimitern> dooferlad, both with lxc-clone: true and false and the changes in my branch I sent you earlier, I successfully live tested a scenario on EC2
<dooferlad> and that is bad?
<dimitern> dooferlad, and was able to do juju ssh 0/lxc/0 (or any other container for that matter)
<perrito666> morning
<dimitern> dooferlad, the bad part is, I left the lxc-clone: true env sitting around while I was out and now trying juju ssh 0/lxc/0 fails
<dooferlad> dimitern: so it did work, you left it alone, it didn't
<dimitern> dooferlad, so something happened in the mean time - juju status shows all units are running, no issues
<dooferlad> dimitern: so it did work, you left it alone, now it doesn't?
<dimitern> dooferlad, yes
<dimitern> dooferlad, I'm investigating
<dimitern> dooferlad, I think the issue comes from dnsmasq configured by lxc to issue dhcp addresses for containers and renew them hourly
<dimitern> in the 10.0.3.0/24 range
<perrito666> natefinch: ?
<ericsnow> could someone spare me a review on http://reviews.vapour.ws/r/1094/
<ericsnow> ericsnow: it's pretty basic
<jw4> talking to yourself again ericsnow ?
<ericsnow> jw4: hey, you're not part of this conversation <wink>
<jw4> hqhq
<jw4> haha even
 * ericsnow goes back to using his quiet voice
<natefinch> perrito666: sorry, gotta fix a dumb bug I introduced
<perrito666> np
<jw4> ericsnow, presumably that PR has been reviewed a few times? Are you just looking for a graduated approver to say shipit?
<ericsnow> jw4: noone has looked at it :(
<jw4> ericsnow, it *is* a little daunting
<ericsnow> jw4: regardless, I'll need some authority to get it landed :)
<ericsnow> jw4: the un-revert part was already reviewed and merged last week
<jw4> bamboo? fingernails?
<ericsnow> ericsnow: I suppose it would be simpler if I split the patch in two
 * ericsnow mumbles to self
<ericsnow> jw4: ^^^
<jw4> hehehe
<ericsnow> jw4: the torture reference was about getting the vivid stuff sorted out
<jw4> oh, I thought it was related to un-reverting and assumed it was the same one
<ericsnow> jw4: it's been a real pain because I don't have a local vivd host with which to test
<jw4> Yeah, I got a utopic vm, but no vivid yet
<ericsnow> jw4: oh, just a VM isn't sufficient :(
<ericsnow> jw4: vivid and containers still have issues when the host isn't vivid
<jw4> ericsnow, really?  That's interesting
<ericsnow> jw4: that's one word for it :P
 * jw4 whispers - I do all my development in a hyper-v instance 
<ericsnow> jw4: you have all the answers, don't you? <wink>
<jw4> hehe
<ericsnow> jw4: is the performance of hyper-v good?
<ericsnow> jw4: LXC is pretty fast and light
<jw4> It seems pretty fast to me
<ericsnow> jw4: cool
<ericsnow> jw4: I'll have to look into that
<jw4> it's hard to compare across hardware, but it handily outperforms native ubuntu on my early 2011 macbook pro with SSD and 16GB ram
<jw4> the full test suite runs in about 15 minutes for me, and it's on a i7 dell optiplex from 2011 too
<wwitzel3> ericsnow: ping
<ericsnow> wwitzel3: coming
<mbruzek> davecheney: ping
<TheMue> Anybody interested in doing a review? http://reviews.vapour.ws/r/1096/
<dimitern> TheMue, I'm on it, but keep getting distracted; should finish it soon though
<alexisb> mbruzek, davecheney is probably sleeping
<TheMue> dimitern: fine, thanks
<alexisb> is there something someone else on the team can help with?
<TheMue> dimitern: doesn't hurry, I'm on the next one. ;)
<dimitern> alexisb, well, dooferlad is actually OCR today
<dimitern> dooferlad, it wouldn't hurt to have a look as well
<dooferlad> dimitern: on it
<dimitern> dooferlad, cheers!
<dooferlad> TheMue: My non-expert opinion is that it looks fine!
<TheMue> dooferlad: thanks, and don't hide your light under a bushel
<mbruzek> alexisb: I need some go help was davecheney is the person to talk with about that.  I have an email out to natefinch and katco about my question.
<natefinch> mbruzek: yeah, sorry, meant to respond to you last night
<alexisb> mbruzek, dave is our resident gccgo expert
<alexisb> mbruzek, you can send him mail if it is not urgent, but he will be out for his weekend atm
<mbruzek> alexisb:  it is not urgent.   I am sure Nate or Katherine can help
<alexisb> mbruzek, natefinch is currently on a critical task
<alexisb> mbruzek, can you forward me th email so I can help facilitate
<mbruzek> alexisb: OK stand down natefinch, I will email davecheney and you
<alexisb> thanks mbruzek
<natefinch> mbruzek: my off the cuff response is - don't install go, just deploy a binary, but I doubt you'll like that answer :)
<natefinch> (but it's sort of the whole point of writing anything in Go in the first place)
<mbruzek> natefinch: It doesn't matter if I like it or not if that is your answer.  I don't know how that would survive bit rot, but yeah don't worry about it, do you critical task
<natefinch> Oh wow, this joyent test is totally fubared
<natefinch> (sorry alexisb, this is also a critical fix)
<alexisb> natefinch, yep I see it
<natefinch> who sets environment variables in table driven tests and then doesn't clear them out before the next test in the table? :/
<natefinch> Evidently wallyworld_ , that's who :)
<natefinch> ericsnow, perrito666, TheMue, wwitzel3:  can someone review this fix to a critical regression? http://reviews.vapour.ws/r/1098/diff/#
<ericsnow> natefinch: ah, my old enemy, table-driven tests
<natefinch> very small fix
<natefinch> ericsnow: yeah.... I like them, but they're easy to abuse
<ericsnow> natefinch: I just used them for systemd to great effect (because they were a good fit)
<TheMue> natefinch: done
<ericsnow> natefinch: done
<TheMue> ericsnow: h5
<ericsnow> TheMue: :)
<dimitern> TheMue, you have a review
<dooferlad> TheMue / dimitern: could you point me to where we construct the libvirt domain XML? We seem to have no network defined for kvm
<TheMue> dimitern: thanks and good hint, I like it
<natefinch> whoever told me to write a test that fails before I write a bugfix was a genius.  I would have wasted so much time over my career if I didn't do that.
<ericsnow> natefinch: :)
<dimitern> TheMue, np :)
<natefinch> that's how I found that missing defer os.SetEnv(k, "").  I wrote a test that should have failed... and it didn't.
<dimitern> dooferlad, we use uvt-kvm for that, which I believe creates the XML for us (or uses virsh underneath or something)
<TheMue> natefinch: hehe, currently doing the same with my actual fix. first a test to simulate the failure and then change to remove it again
<dooferlad> dimitern: just found that :-)
<dooferlad> dimitern: typical, spend 10 minutes looking, go for tea, come back, ask on IRC and it just pops up in front of me.
<dimitern> :D
<perrito666> meh non capturin groups are not something to be found in grep regexes?
<mgz> you can always use grep -P
<perrito666> mgz: I am actually using supercat
<perrito666> to color my tests output so I can make more sense of them
<perrito666> but I try to use a non capturing group to make a match of json dicts
<perrito666> and it tells me that its not a valid syntax
<mgz> well, generic answer then is yeah, not all regexp dialects support non-capturing groups
 * perrito666 cries
<natefinch> perrito666: http://stackoverflow.com/questions/27242652/colorizing-golang-test-run-output
<natefinch> perrito666: also: http://bit.ly/1A4eY7v
<perrito666> natefinch: trust me youll like what I am doing
<perrito666> :D, it mostly colorizes the output of the logs between test failures
<perrito666> I donr really care for tsts when they pass
<natefinch> perrito666: also: https://github.com/natefinch/nolog
<marcoceppi> xwwt__: abentley: why isn't this marked as a regression? https://bugs.launchpad.net/juju-core/+bug/1424069
<mup> Bug #1424069: juju resolve doesn't recognize error state <resolved> <juju-core:Triaged> <https://launchpad.net/bugs/1424069>
<marcoceppi> alexisb: ^
 * marcoceppi is trying to figure out what constitutes a critcal bug vs a high bug
<perrito666> natefinch: mgz this is the kind of output I am getting http://www.webdevout.net/test?01MH
<abentley> marcoceppi: I agree, it looks like a regression to me.  Curtis did the triage, but unfortunately, he's out today.
<marcoceppi> abentley: cool, it's making our testing of actions in trunk a bit difficult
<xwwt__> abentley: Looks like the inline comments issues are important, but were deprioritized to work on git.  Sounds like they will be added back to the list.
<abentley> marcoceppi: We don't have any functional tests of "resolve", but maybe we should.
<natefinch> perrito666: you could modify the code in my nolog application to change the output to include color
<marcoceppi> abentley: O
<marcoceppi> abentley: I'd argue there should be, but I'm biased ;)
<mgz> marcoceppi: the bug was just confused by the report/unreport/report cycle
<marcoceppi> it's still an issue in trunk fwiw
<perrito666> natefinch: you have a severe case of NIH
<perrito666> natefinch: although I might
<natefinch> perrito666: I have a severe case of wanting to use a real programming language to write applications
<abentley> marcoceppi: We (Juju QA) only functionally test a few commands: bootstrap, deploy, upgrade-juju, add-relation, backup, restore, ensure-ha.  The bulk of tests are juju-core's unit tests.
<marcoceppi> abentley: makes sense
<marcoceppi> abentley: is there liek a repo of the functional tests?
<abentley> marcoceppi: All our testing stuff is in lp:juju-ci-tools
<marcoceppi> abentley: cool
<perrito666> natefinch: I am pretty sure supercat is written in a real programming language, I just configured it
<perrito666> natefinch: its in C, which beats go in what refers to "real programming language" ;)
<ericsnow> cmars: thanks for your help
<cmars> ericsnow, de nada
<jw4> perrito666, the first few pages of google on 'supercat' don't seem relevant ...
<perrito666> jw4: yes, anything with cat on the name sucks for googling
<perrito666> jw4: man supercat
<perrito666> no man spc
<jw4> ah
<jw4> apt search supercat wasn't helpful either - I should have thought of the actual command name in your snippet
<perrito666> jw4: seems to be a rather old tool
<jw4> hmm apt-get install supercat worked now cool
<perrito666> well it seems supercat was too much for him :p
<natefinch> crap, how did I manage to disable my scroll wheel in my editor? :/
<perrito666> you are a talented person
 * natefinch reboots... can't function w/o scroll wheel in editor.
<ericsnow> could I get a review on a tiny patch I have up: http://reviews.vapour.ws/r/1100/
<ericsnow> and on an only slightly bigger one: http://reviews.vapour.ws/r/1099/
<natefinch> gah, I hate it when err == nil means something is wrong... it just makes the code so hard to follow.
<natefinch> dammit... that feeling when you realize you waited forever for amazon to bootstrap only to realize you forgot --upload-tools
<perrito666> natefinch: lool
<perrito666> natefinch: I upload my own stream
<perrito666> and its all in the ctrl+r :p
<marcoceppi> I'm getting a weird error trying to deploy behind a proxy
<marcoceppi> http://paste.ubuntu.com/10552644/
<natefinch> marcoceppi: I think that's the 409 error code "Conflict"  no idea why you'd be getting that
<natefinch> http 409 error code that is
<marcoceppi> right, not idea why I'm getting it or how to get more information
<natefinch> try with curl?  It sounds like there's a problem with the proxy
<marcoceppi> natefinch: it works on teh local system using wget
<marcoceppi> http://paste.ubuntu.com/10552661/
<marcoceppi> ah, there we go
<marcoceppi> apparently you have to put the /right/ proxy in the configuration
<marcoceppi> when running wget from the bootstrap node, I got this "Proxy tunneling failed: ConflictUnable to establish SSL connection."
<marcoceppi> well, now it just hangs, which I guess is progress
<natefinch> haha
<marcoceppi> blarg
<marcoceppi> it's not respecting my proxy port
<marcoceppi> http://paste.ubuntu.com/10552707/
<marcoceppi> how have we made it this far without hitting this in other canonical infrastructures
<marcoceppi> any suggestions :/
<natefinch> marcoceppi: so your proxy is trying to redirect to a different port, too?
<marcoceppi> natefinch: it looks like Juju is trying to use port 443
<marcoceppi> on the bootstrap node just doing a curl works
<natefinch> marcoceppi: it's using 443 because it's HTTPS
<marcoceppi> natefinch: but the proxy isn't running on 443, just because 443 is a common convention does not mean it's the sole port that HTTPS traffic operates on
<marcoceppi> my https_proxy line defines a port
<marcoceppi> natefinch: looking at the unit tests, for config.go, it never tests aproxy address with a port
 * marcoceppi tries to patch
<marcoceppi> actually Ihave no idea what I'm doing
<natefinch> lol
<marcoceppi> I didn't think grep "proxy" * would return so many hits
<natefinch> I honestly don't know if we're supposed to support changing the port or not.... I mean, it sounds like we don't, obviously
<marcoceppi> well everything else does
<natefinch> I understand that, and it does seem completely reasonable
<marcoceppi> I mean, in canonical we use squid.internal:3128 for http and https, which is why I'm hitting this
<marcoceppi> but I'm not sure if that's the acutal issue or if I'm just doing something wrong
<natefinch> I don't see anything in the proxy code about ports, so it's likely they just weren't considered
<marcoceppi> well it's setting it properly on the host machine, just when consuming it, it seems to do something odd
<marcoceppi> I'll report a bug for now
<marcoceppi> hum, actually
<marcoceppi> that's my bad, the IP address is actually for store.juju.ubuntu.com and not the proxy address
<marcoceppi> so something else seems broken
<marcoceppi> nvm, it works now
 * marcoceppi hangs head in shame
<marcoceppi> this is probably a good time to just EOW
<natefinch> hasha
<natefinch> haha
<natefinch> have a good weekend :)
<marcoceppi> thanks for entertaining my crazy natefinch o/
<ericsnow> natefinch: the releases page updated with your joyent fix: http://reports.vapour.ws/releases/2420
<ericsnow> natefinch: it isn't "blessed" because of unstable joyent substrate
<ericsnow> natefinch: coincidence?
<natefinch> ericsnow: actually t he joyent tests are passing there, looks like
<ericsnow> natefinch: ah, nevermind; looks like it just didn't identify the failing voting test at the top of the page
#juju-dev 2015-03-07
<mup> Bug #1429353 was opened: Failed to write relation settings after hook completed <juju-core:New> <https://launchpad.net/bugs/1429353>
#juju-dev 2015-03-08
 * thumper just marked the critical bug as incomplete
#juju-dev 2016-03-07
<davecheney> https://github.com/juju/juju/pull/4629
<davecheney> can someone please run go test github.com/juju/testing
<davecheney> and tell me if it passes/fails on their machine
<davecheney> thanks
<davecheney> i'm trying to figure out of I broke tings
<davecheney> or if they were already broken
<davecheney> https://github.com/juju/testing/pull/91
<davecheney> fails for me
<davecheney> but the tests don't pass before this change
<davecheney> so :shrug:
<davecheney> thumper: you're OCR, http://reviews.vapour.ws/r/4071/
<davecheney> 2016-03-07 02:10:25 ERROR juju.cmd.jujud upgrade_mongo.go:714 cannot restore a generic error: this failed
<davecheney> WHAT!
<thumper> davecheney: let me check juju/testin
<thumper> ../utils/tls_transport_go13.go:25:3: error: unknown field âTLSHandshakeTimeoutâ in âhttp.Transportâ
<thumper>  
<davecheney> smells like that needs go 1.3
<davecheney> based on the name
<thumper> that is gccgo
<thumper> test failure
<thumper> but master passes with go 1.5 here
<davecheney> thumper: are you using gccgo ?
<thumper> davecheney: not normally
<davecheney> best not to :)
<thumper> make check on the testing repo still calls out to it though
<davecheney> we have a makefile there ?
<davecheney> TIL
<davecheney> 2016-03-07 02:39:01 ERROR juju.cmd.jujud upgrade_mongo.go:238 could not rollback the upgrade: cannot rollback mongo database: lstat /fake/temp/dir/24/db: no such file or directory
<davecheney> WAT!
<davecheney> thumper: https://github.com/juju/juju/pull/4632
<davecheney> followup
<thumper> davecheney: while I agree that these are good changes
<thumper> is this a big distraction? is it really necessary righ tnow?
<davecheney> every time I get a test failure trying to make my F'n tests pass
<davecheney> I fix it
<davecheney> otherwise I have to hold one hand over my eye trying to debug my test failures
<davecheney> thumper: every one of these are a test failure I've hit
<davecheney> i'm not going fishing
<thumper> :)
<thumper> what is the upgrade error above?
<thumper> seems werid
<davecheney> everything is fucking fucked
<davecheney> and the the tear down suite panics
<davecheney> and that just makes it harder to figure out
 * thumper nods
<natefinch> ug, godeps ./... in charmrepo.v2 produces a different list of dependent repos than exist in dependencies.tsv
<thumper> \o/
<thumper> not!!
<natefinch> somebody copypastaed.... charmrepo definitely does not import lumberjack, for example :/
<thumper> :(
<natefinch> nope, I'm wrong... forgot the -t flag, for getting test dependencies too.... the tests import charmstore which in turn imports a whole buttload of stuff
<natefinch> heh, but juju/juju imports blobstore and blobstore.v2
<wallyworld> both blobstores required because charm stuff uses old blobtore
<thumper> hazaah
<thumper> we are *so* organised
<thumper> wallyworld: got a few minutes to talk blobstore?
<wallyworld> sure
<thumper> 1:1 hangout
<mup> Bug #1553915 opened: provider/maas bridge script is not idempotent <juju-core:New for frobware> <juju-core 1.25:New for frobware> <https://launchpad.net/bugs/1553915>
<voidspace> dimitern: frobware: dooferlad: http://reviews.vapour.ws/r/4067/
<dooferlad> voidspace: *click*
<dimitern> voidspace, looking as well
<voidspace> thanks both of you
<voidspace> dimitern: dooferlad: what laptop do you use? Christian is asking which ones are good and which to avoid.
<voidspace> I use a Dell XPS 15, I know a bunch of folk on the team use that as well.
<dimitern> voidspace, dell precision mobile workstation m4800
<dooferlad> voidspace: I mostly use a desktop and use a Mac on the road. XPS 15 would be my goto for a native box.
<dooferlad> voidspace: also http://www.notebookcheck.net/ is a great resource
<dooferlad> voidspace: in terms of compatibility, Intel graphics and wireless tend to give fewer problems.
<voidspace> dooferlad: thanks, I'll point him to that
<dimitern> frobware, voidspace, dooferlad, I have 2 PRs up for review, the second one includes the first, so might be better to just have a look at: http://reviews.vapour.ws/r/4077/
<dooferlad> dimitern: sure. I am OCR today so I will be doing a lot of this reviewing stuff.
<dooferlad> dimitern: just finishing voidspace's code, gettting coffee, hangout. After that I would appreciate going over my PR.
<dimitern> dooferlad, sure, we can do a pairing session later
<dooferlad> dimitern: great.
<voidspace> dimitern: reporting space name instead of id requires the change to passing round SpaceInfo instead of just id
<voidspace> dimitern: want me to make that change in this PR?
<dooferlad> dimitern: hangout?
<dimitern> voidspace, it could be a follow-up I guess
<jamespage> dimitern, dooferlad, voidspace: I have a ceph deployment up and running using extra-bindings!
<jamespage> nice work guys...
<jamespage> took my longer to figure out how to boostrap the maas environment with 2.0 than it did to make the changes...
<dimitern> jamespage, awesome!!
<dimitern> jamespage, so no issues encountered?
<jamespage> dimitern, not yet...
<dimitern> jamespage, good :)
<frobware> jamespage: I like the start of this week... :)
<jamespage> yup
<jamespage> me too
<jamespage> dimitern, frobware: https://github.com/javacruft/charm-ceph/commit/f41254a65a0f77a19e1566b51324484cd7ec3576
<jamespage> charm-helpers bit needs trimming still
<jam> dimitern: voidspace: frobware: can you confirm what I should be putting into NetworkName for a new network.Address? I'm guessing that a Provider should not be filling in that field, is that correct?
<jam> I believe it was getting the network device in the code tych-0 had put together, but I don't think we actually set it from Providers because they don't know
<jam> (I'm guessing NetworkName was pre-space stuff, for Private vs public, etc, but we're probably moving away from it)
<jam> Looking through the code, we do sometimes set it to "juju-public" or "juju-private", but lots of other times it seems to get random values
<dimitern> jam, NetworkName of a network.Address is usually hardcoded and doesn't matter
<jam> dimitern: is it better to leave it blank, set it to "lo" and "eth0" or set it to NetworkPrivate always ?
<frobware> dimitern, voidspace, dooferlad: http://reviews.vapour.ws/r/4078/
 * frobware back in ~1 hour
<dimitern> jam, it will be dropped entirely soon, along with the obsolete networking code, so if leaving it blank works, ok if not I suspect it needs to be juju-private
<jam> dimitern: so surprisingly if I return Scope = ScopeLinkLocal from Instance.Addresses() we will still try to ssh into 127.0.0.1
<jam> apparently we just trust that Providers won't give us LinkLocal or MachineLocal addresses
<jam> we only handle them from SetMachineAddresses
<jamespage> dimitern, what does the bundle syntax look like?
<jamespage> trying that now
<dimitern> jamespage, no changes there
<jamespage> with xenial...
<jamespage> dimitern, not used them before
<jamespage> dimitern, http://paste.ubuntu.com/15320246/ look OK?
<dimitern> jamespage, the "bindings" section does not support "service-default" binding like deploy --bind foo does
<jamespage> juju deploy did not complain
<dimitern> jamespage, have a look here: https://github.com/dimitern/testcharms
<dimitern> jamespage, does it make sense?
<jamespage> dimitern, so more like - http://paste.ubuntu.com/15320259/
<dimitern> jamespage, yeah, exactly
<jamespage> dimitern, makes sense
<jamespage> frobware, urgh - just hit https://bugs.launchpad.net/juju-core/+bug/1550306
<mup> Bug #1550306: 1.25.3 can't bootstrap xenial environments <landscape> <juju-core:Fix Committed by frobware> <juju-core 1.25:Fix Committed by frobware> <https://launchpad.net/bugs/1550306>
<jamespage> no python...
<bogdanteleaga> do we still have a destroy-controller --force kind of a thing?
<dimitern> bogdanteleaga, try kill-controller instead
<bogdanteleaga> dimitern, that sounds like it might work ty
<jamespage> dimitern, is network-get still going to be valid with a -r for context in relations?
<jamespage> so network-get -r shared-db:0 --primary-address and network-get mon --primary-address would both be valid
<dimitern> jamespage, no - just the name
<jamespage> network-get shared-db --primary-address
<dimitern> jamespage, which can be a relation or extra-binding name
<jamespage> ok
<jam> tych0: cmars: dooferlad: I have a proposal up for bug #1551842
<mup> Bug #1551842: Juju 2.0 Trunk launches disconnected nodes <juju-core:Triaged by jameinel> <https://launchpad.net/bugs/1551842>
<jam> can you look at https://reviews.vapour.ws/r/4079
<voidspace> dimitern: I updated my PR - I'll do passing SpaceInfo instead of id in a follow up
<voidspace> dimitern: can I have a ShipIt?
<cmars> jam, awesome
<voidspace> dimitern: manual testing in progress
<voidspace> hmmmm
<voidspace> dimitern: ping
<voidspace> jam: you might know, are you around?
<magicaltrout> jam: ping
<jam> magicaltrout: ?
<jam> voidspace: ?
<magicaltrout> ah just saw your patch and wanted to clarify something in the commit message
<magicaltrout> you say
<magicaltrout> We know that these addresses won't be accessible outside of the local
<voidspace> jam: I attempted to bootstrap to maas without the maas controller running, so naturally bootstrap failed
<magicaltrout> machine
<voidspace> jam: after the failed bootstrap I can't re-bootstrap as it says model info already exists
<jam> magicaltrout: I mean from inside the container
<magicaltrout> ah!
<magicaltrout> got ya
<voidspace> jam: but destroy-controller and kill-controller both say that the model can't be found so they can't do anything
<jam> magicaltrout: they are LinkLocal or MachineLocal (eg 127.0.0.1 or fe80:)
<voidspace> jam: I assume this is a bug
<jam> voidspace: sounds very much like a bug.
<magicaltrout> I've not tested it yet, but as long as it keeps dishing out 10.x addresses to the host then its cool
<jam> magicaltrout: so I tried it and saw that during "juju bootstrap" we no longer try the 127.* addresses and we do still try the 10.* address.
<jam> Which should be enough
<jam> voidspace: I would talk to wallyworld about that bug. Sounds like some of our code to cleanup on ^C of bootstrap isn't quite there.
<magicaltrout> yup thats fine, i just got worried you were giving everything a 127 address which would make me sad :)
<magicaltrout> thanks for the patch!
<voidspace> jam: it was just a failed bootstrap - not ^C
<voidspace> jam: I've filed a bug
<voidspace> jam: deleting models/cache.yaml
<voidspace> jam: deleting models/cache.yaml fixes it
<jam> voidspace: sure, "teardown after failure" then
<jam> but still cleanup when bootstrap is not completed successfully
<voidspace> right
<voidspace> jam: I'll ping wallyworld about it if he does see the bug
<jam> voidspace: certainly you don't want to destroy cache.yaml in practice, as it holds all your other controllers as well.
<voidspace> jam: yep
<mup> Bug #1554042 opened: Bootstrap, destroy-controller and kill-controller all fail after a failed bootstrap <juju-core:New> <https://launchpad.net/bugs/1554042>
<mup> Bug #1554044 opened: juju help still suggests juju init <juju-core:New> <https://launchpad.net/bugs/1554044>
<mup> Bug #1554042 changed: Bootstrap, destroy-controller and kill-controller all fail after a failed bootstrap <juju-core:New> <https://launchpad.net/bugs/1554042>
<mup> Bug #1554044 changed: juju help still suggests juju init <juju-core:New> <https://launchpad.net/bugs/1554044>
<dooferlad> dimitern: hangout?
<dimitern> dooferlad, omw
<frobware> jamespage: ahh. yes, I need to cherry-pick the no python change onto maas-spaces2
<frobware> cherylj: any objections for landing bug #1553915 into 1.25?
<mup> Bug #1553915: provider/maas bridge script is not idempotent <juju-core:New for frobware> <juju-core 1.25:New for frobware> <https://launchpad.net/bugs/1553915>
<mup> Bug #1554042 opened: Bootstrap, destroy-controller and kill-controller all fail after a failed bootstrap <juju-core:New> <https://launchpad.net/bugs/1554042>
<mup> Bug #1554044 opened: juju help still suggests juju init <juju-core:New> <https://launchpad.net/bugs/1554044>
<frobware> voidspace: for reference: http://pastebin.ubuntu.com/15320733/
<frobware> dimitern, voidspace, dooferlad: http://reviews.vapour.ws/r/4081/ - cherry-pick xenial python change into maas-spaces2
<dooferlad> frobware: already on it :-)
<dimitern> frobware, LGTM
<voidspace> frobware: if we merge master that problem will be gone
<voidspace> frobware: because the locking code is gone :-/
<voidspace> frobware: it needs doing right
<mup> Bug #1554060 opened: juju import-ssh-key fails silently <docteam> <juju-core:New> <https://launchpad.net/bugs/1554060>
<cherylj> frobware: no objections!
<frobware> cherylj: atm, I don't believe it's entirely responsible for the bug where 1.25.3 fails as an upgrade from 1.25.0.
<cherylj> frobware: I've got to step out for a bit for a commitment, but want to get back to this when I return.  Can you email me or put a comment in the bug with your thoughts?
<frobware> cherylj: yep, will do.
<cherylj> thanks!
 * dooferlad steps out for 30 minutes
<tych0> jam: btw, you may be interested in, https://github.com/tych0/juju/commits/draft-of-lxd-image-fix
<tych0> jam: i'm waiting for a PR of mine to land, but it looks like we may be overlapping, so just a heads up :)
<jam> tych0: k. I'll take a look at that tomorrow. Thanks for the heads up. I have: https://github.com/juju/juju/pull/4639 and https://github.com/lxc/lxd/pull/1709 as my WIP
<jam> tych0: btw, we want to preserve using local aliases for 'ubuntu-trusty'
<katco> morning everyone
<jam> rather than always going to "ubuntu:t/*"
<jam> morning katco
<tych0> jam: oh?
<jam> tych0: yeah, one of the things we want to let people do is override what image gets used.
<jam> aliases let us do that
<jam> so we'll want to copy the image if no alias exists
<jam> but then switch to whatever they have aliased
<tych0> jam: i see, ok.
<jam> tych0: that helps the "superfast local iteration" where you preseed your image with all the libs/dependencies you need
<tych0> yep
<tych0> makes sense
<jam> tych0: anyway, looks like we did overlap a bit, but if you want to take what I played around with and what you're working on, I'll happily look it over tomorrow.
<jam> tych0: btw: http://reviews.vapour.ws/r/4079/ if you want to look over the fix for "connecting to 127.0.0.1"
<frobware> dimitern, voidspace, dooferlad: forward port from 1.25, http://reviews.vapour.ws/r/4083/
<tych0> jam: sure, i've got some other stuff going on this week, i just did that at the end of friday. anyway, i'll try to get to it at some point this week
<tych0> jam: yeah, i saw that, looks good to me
<tych0> jam: another one of those "i don't know what i'm doing" moments :)
<frobware> jamespage: python bug fix is now in maas-spaces2 if you still want to try xenial there
<jamespage> frobware, \o/
<jamespage> awesome
<jamespage> dimitern, frobware: does network-get always required the binding name, or does it dtrt in a hook context?
<jamespage> as in a relation hook context
<jamespage> network-get --primary-address in shared-db-relation-changed for example
<frobware> jamespage: always the name
<jamespage> frobware, ack just checking
<frobware> (well, last time I tried.)
<dimitern> jamespage, always - as per the agreed spec
<jamespage> dimitern, okay just checking
<jamespage> doing the charm-helpers change - it may as well land now
<jamespage> dimitern, https://code.launchpad.net/~james-page/charm-helpers/network-spaces/+merge/288285 if you want to check for me
<dimitern> jamespage, looking
<dimitern> jamespage, LGTM
<mup> Bug #1554088 opened: TestResumeTransactionsFailure crazy timing call <ci> <intermittent-failure> <juju-core:Triaged> <https://launchpad.net/bugs/1554088>
<mup> Bug #1554088 changed: TestResumeTransactionsFailure crazy timing call <ci> <intermittent-failure> <juju-core:Triaged> <https://launchpad.net/bugs/1554088>
<jamespage> frobware, +1 works with xenial now as well - thanks for picking that patch
<frobware> jamespage: great!
<mup> Bug #1554088 opened: TestResumeTransactionsFailure crazy timing call <ci> <intermittent-failure> <juju-core:Triaged> <https://launchpad.net/bugs/1554088>
<katco> ericsnow: natefinch: i know that meeting re channels has been moving around a lot. i think it's at its final time. can you make it?
<natefinch> katco: It
<natefinch> katco: it's a good time for me
<katco> kk
<katco> ericsnow: ? you around?
<dimitern> voidspace, thanks for the changes to your PR - LGTM
 * natefinch does some surgery on charmrepo to enable writing some actual unit tests.
<natefinch> (actually very minor... probably only needs a local anesthetic)
<voidspace> dimitern: thanks
<voidspace> dimitern: manual test with a specified constraint worked by the way
<marcoceppi> katco: I've compiled the latest master, and juju help-tools resource-get doesn't exist.
<katco> ericsnow: ping?
<katco> marcoceppi: k, can you please file a bug?
<marcoceppi> katco: sure
<natefinch> I didn't even know help-tools was a thing
<katco> marcoceppi: and link it here: https://blueprints.launchpad.net/juju-core/+spec/juju-server-and-model-resources
<marcoceppi> natefinch: it saves my ass more times than not
<marcoceppi> esp since the tools aren't in normal path, so people always go poking with sharp sticks via ssh, help-tool is like juju man for hook tools <3
<natefinch> marcoceppi: yeah, that's awesome, just didn't realize it existed.  Very glad it does.
<marcoceppi> trying to write the charm-helpers implementation for resource-get, natefinch katco is there a charm with resources as an example in the mean time
<katco> marcoceppi: https://github.com/juju/juju/tree/master/testcharms/charm-repo/quantal/starsay
<natefinch> dang, katco is faster than me
<marcoceppi> quantal :|
<natefinch> marcoceppi: not really
<katco> marcoceppi: i know. that doesn't actually mean anything
<marcoceppi> haha, I know, I just love seeing oneiric and quantal series hanging about
<natefinch> marcoceppi: the story I heard was that we picked quantal on purpose to make them obviously fake charms, since no one would actually write a charm for quantal
<marcoceppi> katco natefinch is there a possibility that a charm could be deployed without a resource associated with it?
<katco> marcoceppi: no... all charms will have "default" resources defined in the store, even if they're just example resources
<katco> marcoceppi: the 1 exception i can think of is maybe local charms
<marcoceppi> katco: cool, so for a local charm
<marcoceppi> katco: haha, that's where my mind was heading
<marcoceppi> I was wondering if juju deploy ./charm would fail if you didn't also supply resources with it
<natefinch> nope
<katco> marcoceppi: yeeep. i believe resource-get will block until you do a juju push-resource
<marcoceppi> block?
<natefinch> katco: it doesn't block for local charms, just returns an error
<katco> marcoceppi: it's a blocking call... e.g. it won't return until the resource is on disk
<katco> natefinch: marcoceppi: ah, ok. well there you go
 * marcoceppi spins up a 2.0-beta2 bootstrap
<katco> natefinch: so that's interesting. users have to do the whole resolve dance?
<natefinch> katco: or just write the hook expecting that the resource might not exist
<katco> ericsnow: are you around yet?
<ericsnow> katco: yeah
<katco> ericsnow: meeting in 5 re. channels
<katco> ericsnow: will you make that?
<natefinch> marcoceppi: btw, in the metadata.yaml... Type under each resource should be type, and comment should be description... the one in master is out of date
<marcoceppi> katco ericsnow natefinch erroring isn't a bad thing, just need ot write good code
<ericsnow> katco: yep, perfect timing :)
<natefinch> marcoceppi: exactly my thought
<marcoceppi> natefinch: I have this http://paste.ubuntu.com/15321739/
<natefinch> marcoceppi: looks good
<natefinch> marcoceppi: note that push-resource will fire upgrade-charm, so you can just put your "when a new resource is available" code there... though if you deploy --resource foo=./bar.zip then it'll be available even before the install hook
<marcoceppi> katco: created and linked
<katco> marcoceppi: thx dude
 * dimitern needs to go and will miss the sync call unfortunately :/
<frobware> voidspace, rick_h__: sync meeting folks
<rick_h__> frobware: ty
<mup> Bug #1554116 opened: resource-get doesn't show in help-tool <juju-core:New> <https://launchpad.net/bugs/1554116>
<mup> Bug #1554120 opened: juju 2.0 bundle support: Missing constraint support for maas names to support bundle placement <oil> <juju-core:New> <https://launchpad.net/bugs/1554120>
<marcoceppi> katco: is there resource stuff in beta1 or only beta2?
<katco> marcoceppi: both
<cherylj> frobware: ping?
<marcoceppi> aisrael: ^^ beta1 should be fine
<frobware> cherylj: pong
<katco> marcoceppi: aisrael: beta1 won't automatically call upgrade-charm, beta2 will
<cherylj> hey frobware - have you merged your fix for 1549545 yet?
<cherylj> 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 frobware> <https://launchpad.net/bugs/1549545>
<voidspace> frobware: dammit, I can only install maas 2.0 from next-proposed on xenial
<voidspace> frobware: lucky this is just a clone
<frobware> cherylj: nope, I have unit tests to finish.
<cherylj> ah yes
<cherylj> okay
<cherylj> frobware: I was worried there was a regression because we hit that test in master...  I guess I was confused since I tested it locally building from  your branch
<frobware> cherylj: I will finish those tests tomorrow
<cherylj> sweet, thanks!
<katco> ericsnow: natefinch: ok, recap time in moonstone
<voidspace> frobware: and I can't upgrade from trusty to xenial due to this "critical" bug
<voidspace> frobware: https://bugs.launchpad.net/ubuntu/+source/ubuntu-release-upgrader/+bug/1550741
<mup> Bug #1550741: Upgrade failed - unauthenticated package (module-init-tools) <apport-bug> <dist-upgrade> <i386> <iso-testing> <trusty> <module-init-tools (Ubuntu):Confirmed> <ubuntu-release-upgrader (Ubuntu):Confirmed> <https://launchpad.net/bugs/1550741>
<frobware> cherylj: I'm struggling to repro bug #1551959
<mup> Bug #1551959: juju-tools 1.25.0 with juju-agent 1.25.3 has networking issues <juju-core:Triaged by frobware> <https://launchpad.net/bugs/1551959>
<voidspace> frobware: I can reinstall xenial over the top of this clone which should keep the network config (the reason I cloned)
<ericsnow> katco: brt
<frobware> cherylj: I need to have another MAAS 1.9 install - one for released images, another for daily.
<cherylj> frobware: I'll see if I can.  Do you see that it upgrades with no issues?
<frobware> cherylj: the /e/n/i you get with daily looks to be different from released and in that bug ^
<frobware> cherylj: and it's not clear whether this makes things worse, better or no different.
<frobware> voidspace: why not create a new VM for xenial + MAAS 2.0?
<mup> Bug #1554136 opened: too many alias commands complicate help <juju-core:New> <https://launchpad.net/bugs/1554136>
<frobware> cherylj: I see that my 1.25.0 was upgraded to .3 without issue: http://pastebin.ubuntu.com/15322183/
<frobware> cherylj: thay deployment ^^ started off as 1.25.0
<frobware> cherylj: 1.25.0 status: http://pastebin.ubuntu.com/15322192/
<cherylj> frobware: want me to test with 'released'?
<frobware> cherylj: please, though I'm doing a new MAAS install so will be able to do this soon...ish.
<frobware> cherylj: ok to land Bug #1553915 into master as well?
<mup> Bug #1553915: provider/maas bridge script is not idempotent <juju-core:New for frobware> <juju-core 1.25:Fix Committed by frobware> <https://launchpad.net/bugs/1553915>
<cherylj> frobware: yes, please
<cherylj> frobware: okay, I'll need to sync released images.
<cherylj> frobware: btw, I "sort of" figured out what was going on with not being able to juju ssh into a node with two NICs
<frobware> cherylj: this is why I'm heading to 2 MAAS installs; with images checked it took about 2 hours for me on Friday to switch
<frobware> s/with images/with ALL images/
<cherylj> frobware: I have a second MAAS, I guess I can update it to 1.9.1.  It's currently on 1.8
<frobware> cherylj: MOAR!
<frobware> :)
<cherylj> hehe
<frobware> cherylj: it wasn't clear which MAAS he was using
 * frobware wonders why we allow bugs to be registered that doesn't collect logs that stop us going around the houses.
<frobware> alexisb, cherylj: what's the story of KVM, because we need to do multi-NIC rendering there too and it's not really on our radar atm
<voidspace> frobware: to keep the network definition of the current one
<cherylj> frobware: if we need more logs, ask for them and mark the bug as incomplete until we get them
<voidspace> frobware: I could create a new one and then copy it, cloning *seemed* easier
<voidspace> frobware: apparently not...
<frobware> cherylj: my point more about automation; run juju-bug-report(1) and $STUFF gets attached automatically.
<cherylj> frobware: it is a wishlist item of mine to get some sort of tool that would grab info
<cherylj> like that
<frobware> cherylj: what was your issue / resolution to ssh and two NICs?
<cherylj> frobware: on a call now, will catch up later
<frobware> ack
<marcoceppi> natefinch: does this seem sane for an implementation of resource-get in Python? https://code.launchpad.net/~marcoceppi/charm-helpers/resource-get/+merge/288328
<natefinch> marcoceppi: LGTM
<mup> Bug #1533742 changed: lxd provider fails to setup ssh keys during bootstrap <lxd> <juju-core:Invalid> <https://launchpad.net/bugs/1533742>
<cherylj> frobware: What I was seeing with the two nics is that the IP returned for the dns lookup for the node by name doesn't actually match what it has configured for its eth1.
<cherylj> frobware: I'm guessing that eth0 was assigned some IP during PXE boot
<cherylj> and that IP is being returned for dns queries
<cherylj> frobware: are you still having issues with MAAS taking a long time to bootstrap?
<mup> Bug #1554193 opened: deploying local charm twice only deploys first version <juju-core:New> <https://launchpad.net/bugs/1554193>
<jcastro> does anyone know where we configure apt proxies in the 2.0 world?
<jcastro> https://jujucharms.com/docs/1.22/howto-proxies doesn't apply
<icey> jcastro: looks like I can pass it as a config to juju bootstrap, eg: juju bootstrap lxd lxd --upload-tools --config="apt-http-proxy=10.0.4.1:3142"
<mup> Bug #1492868 changed: panic on destroy-environment with local provider <destroy-environment> <intermittent-failure> <local-provider> <juju-core:Invalid> <juju-core 1.25:Triaged> <https://launchpad.net/bugs/1492868>
<mup> Bug #1492868 opened: panic on destroy-environment with local provider <destroy-environment> <intermittent-failure> <local-provider> <juju-core:Invalid> <juju-core 1.25:Triaged> <https://launchpad.net/bugs/1492868>
<mup> Bug #1492868 changed: panic on destroy-environment with local provider <destroy-environment> <intermittent-failure> <local-provider> <juju-core:Invalid> <juju-core 1.25:Triaged> <https://launchpad.net/bugs/1492868>
<mup> Bug #1554251 opened: concurent map access in joyent <ci> <intermittent-failure> <joyent-provider> <regression> <juju-core:Triaged> <juju-core 1.25:Triaged> <https://launchpad.net/bugs/1554251>
<wallyworld> perrito666: standup?
#juju-dev 2016-03-08
<davecheney> thumper: good news, we're now getting much better tear down suite errors
<davecheney> http://paste.ubuntu.com/15324360/
<davecheney> bad news, tests still fail on my machine
<davecheney> seems to be load related
<davecheney> has someone done somethign dumb and mongo always listens on the same port or somethign
<thumper> davecheney: I don't think so
<thumper> because I can still have multiple test runs running in parallel
<davecheney> still trying to figure out it
<davecheney> welp, at least people are talking about Juju :)
<davecheney> https://groups.google.com/forum/#!topic/golang-dev/DpMyPbclI3o
<davecheney> if it's one thing I know how to do, it's start a nerd slap fight
<thumper> heh
 * thumper goes to look
<natefinch> davecheney: good times, juju breaking teh toolz
<davecheney> thumper: https://github.com/juju/juju/pull/4629
<davecheney> PTAL
<davecheney> i have removed every single use of the words 'upgrade in progress' from juju
<davecheney> they all come from the params.CodeUpgradeInProgress constant now
<davecheney> i still need to test this manually
<davecheney> with bootstrap, and the backup/restore dance
<katco> natefinch: quick review? https://github.com/juju/charm/pull/194
<natefinch> katco: sure
<natefinch> katco: see now, how can I make a miraculous save at the last minute if you get there first? :)
<katco> natefinch: by staying focused on resources ;)
<natefinch> katco: I
<natefinch> katco: i've been thinking about ways to make the merge easier, since the changes to juju/juju necessarily touch ~170 files
<natefinch> katco: well, not necessarily, given my idea
<natefinch> katco: the main problem is that I moved version to an external repo, which changes friggin' everything.  But all the charm package *really* needs it for, is to verify that the string someone put in metadata.yaml is a valid version string
<katco> natefinch: yeah wallyworld and i were just discussing that
<natefinch> katco: if instead of making charm.minjuversion a "version.binary" struct, we just kept it as a string and shared the regex that verifies it... that suffices, and reduces the changelist by about 98% in juju/juju
<natefinch> s/version.Binary/version.Number
<katco> natefinch: let me see how the merging goes, but a little copy/paste sounds like a great trade-off for that dep
<natefinch> katco: ok.  easy enough to give it a try.  I'd prefer the version stuff were out in its own repo, but the churn is ouchy.
<natefinch> katco: thanks for taking that on.  I had planned to burn some sleep time tonight seeing if I could come up with a fix, 'cause I really wanted min-juju-version in 2.0
<katco> natefinch: thanks for the thought, but getting resources all buttoned up is way more important
<katco> natefinch: happy to take this on for the team
<natefinch> katco: you got a LGTM from me... feels kinda weird reviewing what is mostly my own code ;)
<katco> natefinch: well, you're the sanity-check for the merges. wallyworld also gave a review, so we're covered :)
<wallyworld> i do like the idea of having the min version as a string in charm meta though
<wallyworld> greatly simplifies everything
<natefinch> I love the way it simplifies the change.... though I think it is far superior to have it as a struct... it's hard to justify the sheer volume of churn that produces.
<natefinch> one other possibility is to have charm use the external repo just to verify with Parse(), then store it as a string... then after 2.0 we can make the change to switch everything over to the external repo (if we think it's worth it at that point).
<natefinch> I guess that doesn't really buy us anything different than just stealing the regex for 2.0
 * natefinch stops thinking about versions and goes back to resources.
<katco> natefinch: did you have a test script to test this manually?
<natefinch> katco:  you can just add juju-min-version: 1.25 to any metadata.yaml, verify it deploys ok, then change it to 99.99 and verify it tells you it can't be deployed
<katco> natefinch: cool, ty
<katco> wallyworld: natefinch: https://github.com/juju/juju/pull/4648 not showing on RB for some reason
<wallyworld> yay rb
<natefinch> well, not like rb would make it any easier to review 2281 changed files
<natefinch> omg, it's all the model stuff, no wonder
<natefinch> LOL: commits 250+
<natefinch> "I dunno.. more than 250"
<katco> wallyworld: natefinch: i listed the merge conflicts in the commit if you just want to review those. CI will catch most everything else
<natefinch> katco: that would be very much handy
<katco> wallyworld: natefinch: ah there's RB: http://reviews.vapour.ws/r/4091/
<wallyworld> just took a while to digest
<katco> wallyworld: probably b/c it's python. /troll
<natefinch> lol
<wallyworld> sigh
<katco> wallyworld: natefinch: updated conflicts in RB
<natefinch> This diff has been split across 114 pages
<natefinch> katco: I don't know tht reviewing the merge from master is terribly useful.  I think looking at the PR from this branch to master after this merges would be a lot more instructive
<katco> natefinch: i'll have CI try and merge it. i'm sure a test will fail
<mup> Bug #1532063 changed: Unit seems unable to proceed after watcher died in the middle of hook execution <juju-core:Expired> <https://launchpad.net/bugs/1532063>
<davecheney> 15:20 < natefinch> This diff has been split across 114 pages
<davecheney> ^ that's going straight to the quotes page
<natefinch> davecheney: to be fair, it's 3 months of updates to master getting merged into a feature branch
<mup> Bug #1550770 changed: TestContainerStartedAndStopped cannot create mock container on ppc64el/arm64 xenial/wily <arm64> <centos> <ci> <lxc> <ppc64el> <test-failure> <juju-core:Fix Released by cherylj> <juju-core 1.25:Fix Released by cherylj> <https://launchpad.net/bugs/1550770>
<davecheney> TheMue:         // cannot import apiserver to get access to apiserver.UpgradeInProgress
<davecheney>         // because that creates and import loop.
<davecheney> thumper        // cannot import apiserver to get access to apiserver.UpgradeInProgress
<davecheney>         // because that creates and import loop.
<davecheney> ^ i'm crying
<natefinch> :/
<natefinch> davecheney: where is that?
<katco> davecheney: please watch over us while i sleep
<katco> wallyworld: natefinch: missed juju/version in dependencies.tsv. kicked off another merge into feature branch. calling it a night. tc
<katco> o/
<wallyworld> see ya
<davecheney> no, i wrote that comment
<natefinch> katco: thanks!
<natefinch> davecheney: oh
<davecheney> once I get this branch landed and the pressure is off
<davecheney> i'm merging apiserver and apiserver/common
<natefinch> davecheney: in that case s/and import loop/an import loop
<natefinch> :D
 * natefinch focuses on the important bits.
<davecheney> they are actually the same the package, but have been split by a londitudinal fissure for reasons that don't make sense any more
<natefinch> ahh yes, I'm working in one of those myself
<mup> Bug #1536587 changed: juju's MAAS bridge script is echoed to the console by cloud-init during bootstrap <bootstrap> <network> <juju-core:Fix Released by frobware> <https://launchpad.net/bugs/1536587>
<davecheney> commit 33438a26ed2b98438bc881a20fd14032bff56093
<davecheney> Author: Dave Cheney <dave@cheney.net>
<davecheney> Date:   Tue Mar 8 15:55:00 2016 +1100
<davecheney> Angry rant time!
<davecheney> UpgradeInProgressError used to be defined in apiserver/admin.go and used in apiserver/upgrading_root.go. __BUT__, the logic that turns errors into rpc messages is inside apiserver/common/error.go. This creates a potential import loop as apiserver already imports common, so common cannot import apiserver to get a type.
<davecheney> So, to ~~solve~~ workaround this clusterfuck, we move UpgradeInProgressError to apiserver/params, which everyone imports and solve the import loop.
<davecheney> This is _SHIT_. apiserver and apiserver/common are clearly the same package, thay cannot function without each other and have been bifurcated for reasons that no longer make sense.
<davecheney> Once this PR is landed, I will merge the two packages and then we can define, and use UpgradeInProgressError in _one_ place, and then we can also unexport it because things should not be checking for it explicitly on that apiserver side of the blood/brain RPC layer.
<wallyworld> davecheney: -1 from me that apiserver and apiserver/common are rge same package
<wallyworld> apiserver/common contains shared server side implementation that is embedded in several facades
<davecheney> that's fair
<wallyworld> apiserver is other stuff
<davecheney> but some parts of the apiserver/common package belong to apiserver itself
<davecheney> specfically apiserver/common/error.go
<wallyworld> that may well be true :-)
<jam> wallyworld: did you see the "failed bootstrap leaves stuff in cache.yaml" bug?
<wallyworld> jam: i did see it float passed, have not looked closely
<wallyworld> jam: is it this one? bug 1554042
<mup> Bug #1554042: Bootstrap, destroy-controller and kill-controller all fail after a failed bootstrap <juju-core:New> <https://launchpad.net/bugs/1554042>
<jam> wallyworld: np. just wanted you to be aware. It seems if something gets into cache.yaml then we don't have a way via kill-controller, etc to get rid of it
<jam> wallyworld: yep
<wallyworld> jam: cache.yaml is almost gone, will need to check what the story is with the other yaml files to see if we are cleaning up
<wallyworld> thanks for the heads up
<wallyworld> on my big long todo list
<jam> just wanted to add an entry, I don't think it is very high priority
<davecheney> why does cmd/juju import cmd/jujud/agent ... ?
<wallyworld> davecheney: it does? i had a quick look but didn't see where, but i could be blind
<davecheney> it imports it transitively via components/all
<natefinch> components/all imports a lot of stuff... forget why agent
<jam> natefinch: presumably because "component" work implements front end and backend stuff in the same package
<jam> because it is grouped by topic instead of by layer
<davecheney> wallyworld: http://paste.ubuntu.com/15325996/
<natefinch> jam: well, the component stuff is grouped by topic inside the component code itself (payloads, resource)... but the component package wires it all up from the same place. That's a mistake, and actually pretty easily fixed. The code is already separated into functions for server vs. client, they could easily be put in different pacakges.
<wallyworld> oh, transitively, ok
<natefinch> jam: sorry, I meant it's grouped by layer inside the component folders (payloads, resources)
<natefinch> jam: FWIW, the components/all stuff is basically unrelated to the component setup. It exists for dependency injection purposes.... which I don't entirely agree with.
<davecheney> "dependency injection"
<davecheney> ^ taht's the most creative use of that word i've ever seen
<davecheney> that should have got Leonardo's Oscar
<natefinch> it's not the way that I would have done it.... but I can only provide so many dissenting opinions
<natefinch> davecheney: is there an easy way to fill out a fake http.Response?
<davecheney> maybe, which fields do you want to fake ?
<natefinch> davecheney: all I really need is the body and statuscode... which I guess I can just set to whatever... luckily out code seems not to look at much else
<natefinch> davecheney: which is to say, nevermind, I think I'm fine :)
<davecheney> \o/ best support issue
<davecheney> one that solves itself
<mup> Bug #1554417 opened: Juju 2.0:  ERROR cannot deploy bundle: machine "0" is not referred to by a placement directive (and 4 more errors) <oil> <juju-core:New> <https://launchpad.net/bugs/1554417>
<frobware> dimitern: sync?
<dimitern> frobware, hey, sorry got carried away while testing :)
<dimitern> omw - 2m
<mup> Bug #1554436 opened: Juju adds any RFC1918 address it finds on any state servers to the apiaddresses list in agent.conf <canonical-bootstack> <juju-core:New> <https://launchpad.net/bugs/1554436>
<frobware> jam: you doing standup?
<jam> sure
<jam> brt
<frobware> dimitern: I saw you review comments - they are useful but questioning the value if this code will be deleted as soon as we land maas-spaces2
<frobware> dimitern: if this code lives on, then sure
<dimitern> frobware, np, feel free to drop them
<dimitern> frobware, just as I'm writing tests as well now those just crossed my mind :)
<frobware> dimitern: if we don't feel this code is going away then I can address them
<dimitern> frobware, it should, yeah - this is temporary
<TheMue> morning juju-ers o/
<perrito666> morning TheMue
<voidspace> frobware: dimitern: dooferlad: passing SpaceInfo rather than just id turned out to be really easy
<voidspace> frobware: dimitern: dooferlad: http://reviews.vapour.ws/r/4096/
<voidspace> and bindings already have a name, so nothing to do there
<dimitern> voidspace, cheers, looking
<dimitern> TheMue, hey ;)
<TheMue> found a way to run irc here too (ok, not here, but ssh to my server and irssi there) ;)
<TheMue> still missing our team
<jam> hi TheMue
<jam> good to see you around
<frobware> dimitern: MAAS meeting
<frobware> voidspace: ^^
<voidspace> oh yeah
<voidspace> brt
<jam> tych0: I did a bit more work on my branch to further the "grab images via ImageCopy instead of lxd-images import"
<dimitern> omw
<jam> tych0: but that made me look deeper into what our "caching" story is going to be, because that really changes where we search for images.
<jam> tych0: I hope I wrote that up nicely in my email. But I think we can take my branch and quickly turn that into just CopyImage from cloud-images.ubuntu.com if we want stepping stones along that path.
<tych0> jam: oh, did you see my PR?
<tych0> jam: i did all that already :\
<jam> tych0: np. I'll look at it now. I didn't see it earlier. But what I did doesn't really overlap with what you're doing.
<tych0> jam: oh, ok. sounds very similar :)
<jam> tych0: I was trying to go via ConnectInfo rather than DefaultConfig, "ubuntu". I was also looking at wiring up "daily" streams vs "released" streams, etc.
<TheMue> jam: yeah, always following Canonical, and here especially Juju news
<tych0> jam: sure, it's not intended to be feature complete. mostly we want to deprecated lxd-images, so i'm trying to get you guys off of it before we do
<tych0> jam: the lxd provider patch is a complaint from danwest, though
<jam> tych0: reviewed http://reviews.vapour.ws/r/4086/
<jam> tych0: the thing I proposed?
<jam> The comment isn't on the github PR, can you elaborate?
<jam> tych0: anyway, I'm EOD now. if you want to send me an email, or maybe I can come back to chat in a couple hours.
<tych0> jam: no, sorry, just one of the patches in the series about "lxd provider". nothing to do with what you proposed
<jam> tych0: k, I seem to be missing the context for that. I think I've heard some rumors about it, but I don't think I have any direct info.
<tych0> jam: np. just wanted to clarify the seemingly unrelated patch
<tych0> jam: i can switch it to have all the testing indirection. just seemed unecessarily complicated ot me when there aren't any actual tests :)
<jam> tych0: well, I've been slowly changing that
<jam> tych0: "seemingly unrelated patch", I haven't been able to find another patch
<jam> have a link?
<tych0> https://github.com/tych0/juju/commit/3e13edaad7fd199d50b0f3f0b4b38a95c7c280ec
<jam> tych0: so we were certainly intending to go there, so I wouldn't consider it arbitrary
<jam> I appreciated that you did it.
<jam> I'm not 100% sure if that is the right time to do it, but it is certainly what we want.
<tych0> jam: oh. what's the right itme?
<jam> tych0: I just haven't analyzed it
<jam> that may be the right time
<tych0> the other option i suppose would be to do it when you launch an instance
<tych0> vs. having two seperate call point sin the provider and the container type
<jam> tych0: well "bootstrap" *is* launching an instance
<jam> tych0: the very first one that we are putting teh agent into
<tych0> yep
<jam> tych0: so eventually Juju will need to get much more nuanced in the cloud case about how it gets images, but for Local I think that's just fine.
<tych0> jam: well, it's not local but lxd, but yeah, i think so.
<jam> tych0: IMO calling it "LXD provider" is not very good, because there are LXD instances in all clouds as well. but it is what it got called.
 * tych0 closes the can of worms :)
<tych0> jam: ok, just pushed a fix for your review comments
<jam> tych0: reviewed
<natefinch> man I wish we gave our db entries UUIDs.
<TheMue> natefinch: +1
<perrito666> I wish we gave our db entries a relational db :p
<natefinch> that too :)
<tych0> jam: r.e. the CopyImage thing
<TheMue> natefinch: don't have to be always v4, v3 or v5 are nice to have value based uuids
<tych0> jam: i thought you wanted it there since it was supposed to be a complete interface?
<tych0> jam: i've been deleting the unused ones as i come across them, happy to delete this one too
<frobware> dimitern: I would appreciate if you could take another look over http://reviews.vapour.ws/r/4055/
<tych0> jam: but then i misunderstood the review request :)
<TheMue> perrito666: postgresql, can also handle json nicely
<natefinch> TheMue: I don't really care so long as I don't have to ever worry about duplication
<TheMue> natefinch: we needed ids based on namespace and input values, but still uuids.
<natefinch> TheMue: and we needed that because of the watchers, right? because all we get is the id
<jam> tych0: the point is to keep all of them, AIUI
<jam> tych0: we seem to be talking past eachother
<tych0> jam: :)
<tych0> jam: i just pushed a commit to delete CopyImage then, but i can revert it if you want
<tych0> jam: just let me know what to do.
<dimitern> frobware, looking
<jam> tych0: Keep CopyImage in the interface
<jam> tych0: sorry
<jam> keep CopyImage in the client_raw interface, but I don't think we need it in the ListAliases interface
<tych0> jam: ok, will do
<tych0> jam: ah, i see
<TheMue> natefinch: hmm, always had my troubles with watchers. would like to see message queues here. but thats a big step.
<dimitern> frobware, one optional simplification, otherwise looks great
<natefinch> ericsnow, katco: https://github.com/juju/charmrepo/pull/65
<frobware> dimitern: done
<tych0> jam: ok, i put the one back in client_raw
<natefinch> ericsnow, katco: I still need reviews on this: http://reviews.vapour.ws/r/4006/
<TheMue> natefinch: like your argument. it's the cleaner interface
<katco> ericsnow: i know. so help me i will get to reviews today
<natefinch> lol "HEAD is now at b12bd10... aaaaahhhhhh godeps"
<katco> natefinch: laughing at your own commit message. classy. ;)
<natefinch> katco: haha... not exactly, laughing at how it looks when printed out in CI.
<katco> sinzui: abentley: why do we sed the version.go file in CI?
<natefinch> katco: they read the version of juju out of it
<natefinch> katco: I had renamed the version folder to jujuversion... then put it back, but it looks like it's not back in that branch
<sinzui> katco: We cannot test a release version. also packges need to know the version of the release tarfile.
<katco> sinzui: abentley: isn't there a better way to check the version than introspecting the code? seems like we're relying on an implementation detail
<sinzui> katco: we get code and need to make a tarfile form the source. we read files. This is also how ubuntu makes packages
<sinzui> You cannot build without first knowing the version
<katco> sinzui: oh, chicken and egg problem?
<natefinch> katco: I think you're running off the wrong branch... there's two branches... you want nate-minver from github.com/natefinch/juju
<sinzui> katco: yeah. it is awkward
<katco> sinzui: i'm sure, thanks for the pointers :)
<natefinch> katco: nate-minver has the version code back in /version fir exactly this reason
<sinzui> katco: once we know where to find the version, we can teach ci to look there and also update Ubuntu packaging to do the same.
<katco> natefinch: is that the only diff?
<natefinch> katco: mainly, yeah.  Sorry... I forget why there are two minver branches... but definitely the one with /version is correct, specifically because it breaks CI otherwise.
<natefinch> katco: sorry.. this is all three months old in my head, so it's kinda dusty and full of cobwebs
<katco> natefinch: np we'll get it straightened out
<natefinch> katco: just to double check, creating the resources commands off the charm command is what I'm supposed to be working on, right?
<katco> natefinch: yeah, should be able to complete 2 of those cards today?
<katco> natefinch: doesn't matter which 2
<natefinch> katco: I think so.  just checking out the code now
<katco> natefinch: ?
<natefinch> katco: sorry, already off and running.  it looks good.
<katco> natefinch: k, so 2 of the 1-point cards today?
<katco> natefinch: well, by tomorrow i mean
<natefinch> katco: yeah
<katco> natefinch: cool, ty! good work
<natefinch> katco: I haven't done it yet ;)
<katco> natefinch: on getting the previous card done despite bumps along the way :)
<katco> natefinch: also, eric needs a lot of reviews
<natefinch> katco: ahh, welcome :)
<natefinch> katco: oh... you know what, I've been watching reviewboard, but I forgot most of his now are elsewhere.... if nothing else, reviewboard is nice in that it makes it easy to keep tabs on what needs reviewing.
<katco> natefinch: yeah. i'd use our "under review" column as the index for this iteration
<natefinch> katco, ericsnow: can I make a suggestion?  That we put links to the reviews right on the cards, so we don't have to go looking for them?  In the main window of the card, in the lower right, there's a place for a link and a title for the link.  You can then get to that link from the dropdown menu on the card under the "Link To" section. See my Validate file extension card for an example.
<ericsnow> natefinch: fine with me
<katco> natefinch: yeah fine with me
<natefinch> katco: heh, it's Tuesday and we already have 13 points in the review queue
<natefinch> ..plus a bunch of unpointed stuff
<katco> natefinch: i know =| we're definitely not doing a great job of getting those things through.
<natefinch> ericsnow: hit me with some review links and I'll get to work.
<natefinch> katco: if there's a lot of code to review, it could cut into my coding time, but I'll try to get through it quickly.
<ericsnow> natefinch: https://github.com/juju/charmrepo/pull/68 and https://github.com/juju/charmstore/pull/563
<ericsnow> natefinch: also http://reviews.vapour.ws/r/4090/
<katco> about the only time i regret selecting an ultra-portable as my main work machine is when i deal with our tests.
<natefinch> ericsnow: looks like we duplicated some work on the resource data in the csclient API... essentially the same code though
<katco> the 8-core desktop it's sitting on is looking very tempting right now
<natefinch> katco: yep, that's why I went for a beastly machine
<natefinch> katco: ha, yeah
<katco> i'm just *compiling* our tests, not even running them
<ericsnow> natefinch: hmm, the part in my PR wasn't on the list until last night
<natefinch> katco: ouch
<natefinch> ericsnow: for "Add an API data type for resources" ... you commented on my implementation of the same stuff a few days ago ;)
<ericsnow> natefinch: classic
<natefinch> ericsnow: we're moving fast, I'm not surprised we'd get confused.
<natefinch> ericsnow: I like my implementation 10% better, but yours has standalone tests (mine is tested implicitly when testing the code that uses it)... tough call.
<ericsnow> natefinch: I just copied and pasted from our API code :)
<natefinch> ericsnow: btw, my PR with similar code: https://github.com/juju/charmrepo/pull/65
<cherylj> katco, ericsnow, natefinch is there a way to specify a different bridge for the lxd provider?
<katco> cherylj: probably in the lxd config for juju. tych0?
<tych0> i think it's hardcoded maybe
<cherylj> katco: how do you specify the lxd config?
<katco> cherylj: it's created for you, it's specific to juju
<tych0> oh
<tych0> right, no, it's not hard coded
<katco> cherylj: i don't think you can specify which config
<tych0> there's no way to set it from juju, you can change the default lxd profile, though
<cherylj> thanks, katco, tych0!
<alexisb> cherylj, this is work that overlaps with what sapphire is doing on multi-nic support for lxd I believe
<alexisb> for future reference
<cherylj> ok, thanks alexisb
<frobware> cherylj: you can do this by editing the profile, or creating a new "bridged" profile and applying that to the container.
<cherylj> thanks, frobware!
<frobware> cherylj: I'm uncomfortable landing the change for bug# 1549545 tonight - needs some live testing post my changes today.
<cherylj> frobware: want me to help out?
<frobware> cherylj: if you're happy to test my branch again, that would certainly help.
<cherylj> frobware: okay, I can give it a go.  Is everything in the PR?  Could I just apply that patch?
<frobware> cherylj: there's potentially additional unit testing that can be done, but trying to weight the effort up because this will be a temporary change until we land maas-spaces2
<cherylj> frobware: understood.  It's also the last fix we're waiting on to ship beta2
<frobware> cherylj: yep
<frobware> cherylj: the new function is tested, there's no unit test case for the case where an instance does not have a Gateway address - that change is much larger.
<frobware> cherylj: so it has been reviewed, and live tested by you. A further confirmation would help to ensure that the small changes to the core functionality have broken its liveness. At that point you could choose to $$merge$$
<frobware> s/have broken/have NOT broken/ Gah!
<cherylj> frobware: okay, I will test it with bootstrap / deploy node / deploy container on multi-NIC node on trusty, wily and xenial (daily) today
<frobware> cherylj: thanks. I have to run soon.
<cherylj> frobware: np.  If my testing is good, I'll plan to $$merge$$ it for you.  Good?
<frobware> cherylj: I'm guessing that if you're trying xenial you'll also be using daily images for trusty and wily.
<cherylj> frobware: yes
<frobware> cherylj: yep, good!
<cherylj> but I do have my 2nd maas on 1.9.1 now, so I could do concurrent testing with daily and released
<frobware> cherylj: you're ahead of the curve. :)
<cherylj> sweet
<ericsnow> natefinch: FYI, I've reviewed all your patches
<natefinch> ericsnow: thanks!
<natefinch> katco: ug... the charm command has its own wrapper for the csclient.Client type
<katco> natefinch: >.<
<katco> natefinch: what does the wrapper do?
<natefinch> katco: auth stuff..
<katco> natefinch: ah, so that's the stuff we talked about pulling into charmrepo.CharmClient?
<natefinch> katco: yes... didn't really think about that as part of this card
<katco> natefinch: i think we talked about you doing a follow-up overhead card to the card you just completed
<katco> natefinch: but if you need it now, just go ahead and do it and leave a comment in the card you're working on
<ericsnow> natefinch: so how would you like to proceed on our two patches that have params.Resource?
<ericsnow> natefinch: FYI, it's a blocker for my charmstore PR
<natefinch> katco: yeah. I have to do it first. I have push resource 2/3rds done, except it can't call the charmrepo.CharmStore since everything here is set up to use this csClient type.
<natefinch> ericsnow: yeah, everything blocks everything else :)
<natefinch> ericsnow: at least the non juju/juju repos build and test super fast
<ericsnow> natefinch: (â¯Â°â¡Â°)â¯ï¸µ â»ââ»
<katco> i dream of a day when core is like that
<natefinch> katco: yep
<katco> it would be so amazing if we had a complete suite of unit tests
<katco> run in a few seconds
<katco> le'sigh
<natefinch> katco: have you seen this? https://groups.google.com/forum/#!topic/golang-dev/DpMyPbclI3o
<natefinch> ericsnow: just land yours, it's fine. I'll tweak mine to comlpy
<natefinch> comply
<katco> natefinch: yeah i have
<mup> Bug #1554675 opened: Unable to bootstrap lxd provider on s390x <lxd> <s390x> <juju-core:Triaged> <https://launchpad.net/bugs/1554675>
<katco> natefinch: that took 10s to load bc my machine is under load from compiling. irony +1
<natefinch> katco: lol  try running a hangout at the same tine. you'll basically be reduced to smoke signals
<ericsnow> natefinch: can't land without LGTM from uiteam and they're all EOD
<natefinch> katco: luckily, your CPU will be producing plenty of that ;)
<natefinch> ericsnow: boo
<rick_h__> ericsnow: you get +1 from this side of the ocean?
<ericsnow> rick_h__: from natefinch
<rick_h__> ericsnow: k, so should have code fairy in the AM then hopefully
<ericsnow> natefinch: could you throw a LGTM on that PR just so folks can see it?  https://github.com/juju/charmrepo/pull/68
<ericsnow> natefinch: thanks
<katco> ericsnow: natefinch: hey so just talked with rick_h__
<katco> natefinch: you don't have to support the publish flag on charm push
<katco> natefinch: further, where we were previously planning on erroring out if you try and push without all resources defined, we should allow that, but on the charm publish command, error out if not all resources are a) provided with the resource flag or b) have any revision avail
<katco> natefinch: i'll update the user stories so that's crystal clear
<katco> ericsnow: natefinch: questions?
<ericsnow> katco: funny, that's the way I thought we were going to do it already :)
<katco> ericsnow: :( it is my mission in life to help everyone get better at being on the same page. that's certainly not what the spec/user stories have said up until now
<natefinch> katco: makes perfect sense.  I think it's a better user experience to be able to do it piecemeal
<katco> natefinch: me too
<mup> Bug #1554677 opened: Provider help topics need to be updated for 2.0 <docteam> <juju-release-support> <juju-core:Triaged> <https://launchpad.net/bugs/1554677>
<natefinch> katco, ericsnow: I just noticed... the struct they created in charmstore-client doesn't actually have any methods...
<natefinch> katco, ericsnow: which means it's just a dumb databag... and I can just pass the csclient.Client it produces into charmrepo.CharmStore....
<ericsnow> natefinch: correcto
<mup> Bug #1554677 changed: Provider help topics need to be updated for 2.0 <docteam> <juju-release-support> <juju-core:Triaged> <https://launchpad.net/bugs/1554677>
<natefinch> katco: so that means I don't have to move anything to charmrepo before I can do my other cards... so... false alarm.
<natefinch> man, I love having golint and govet run on save with squiggly lines to tell me where things are failing and mouseovers to tell me what the error is.
<mup> Bug #1554677 opened: Provider help topics need to be updated for 2.0 <docteam> <juju-release-support> <juju-core:Triaged> <https://launchpad.net/bugs/1554677>
<mup> Bug #1554687 opened: help text for juju remove-service needs improving <docteam> <juju-core:New> <https://launchpad.net/bugs/1554687>
<mup> Bug #1554687 changed: help text for juju remove-service needs improving <docteam> <juju-core:New> <https://launchpad.net/bugs/1554687>
 * natefinch plays dependency ping pong
<mup> Bug #1554687 opened: help text for juju remove-service needs improving <docteam> <juju-core:New> <https://launchpad.net/bugs/1554687>
<katco> rick_h__: actually, regarding publish erroring if not all resources are specified. shouldn't it just pick the highest revision of the missing resource(s)?
<mup> Bug #1554700 opened: help text for juju import-ssh-keys needs improving <docteam> <helpdocs> <juju-core:New> <https://launchpad.net/bugs/1554700>
<mup> Bug #1554705 opened: help text for juju list-ssh-keys needs improving <docteam> <helpdocs> <juju-core:New> <https://launchpad.net/bugs/1554705>
<roryschramm> is the juju-1.25.4 release available in a repository? I saw that it was released today but i don't see it in either the stable or devel repositories
<roryschramm> https://launchpad.net/juju-core/+milestone/1.25.4
<rick_h__> katco: they may have never been supploed
<mup> Bug #1554700 changed: help text for juju import-ssh-keys needs improving <docteam> <helpdocs> <juju-core:New> <https://launchpad.net/bugs/1554700>
<mup> Bug #1554705 changed: help text for juju list-ssh-keys needs improving <docteam> <helpdocs> <juju-core:New> <https://launchpad.net/bugs/1554705>
<katco> rick_h__: true, in which case it should error. but if they have, we should run through our selection algo. and pick the highest rev.?
<rick_h__> roryschramm: i know they were workong to grt it out but not seen any annoincement its done atm
<rick_h__> katco: so they should be either manuallybspecified as part of yhe publish command
<rick_h__> katco: or maybe 'assumed' based on whatbthe charm is doing
<roryschramm> ah okay, thanks
<katco> rick_h__: i don't understand that last bit.
<rick_h__> katco: /me is waiting for boy at school, biab
<mup> Bug #1554700 opened: help text for juju import-ssh-keys needs improving <docteam> <helpdocs> <juju-core:New> <https://launchpad.net/bugs/1554700>
<mup> Bug #1554705 opened: help text for juju list-ssh-keys needs improving <docteam> <helpdocs> <juju-core:New> <https://launchpad.net/bugs/1554705>
<katco> rick_h__: no worries, ty ^.^
<rick_h__> katco: so what I was trying to say on a phone keyboard was that:
<katco> :)
<rick_h__> katco: we should take a cue from the rest of the channels spec. If you can publish a charm without specifying the revision and it grabs the latest one, resources should behave likewise
<rick_h__> katco: since I didn't have the doc in front of me I was trying to suggest taking a peek and comparing the charm experience to mirror.
<rick_h__> katco: it looks like, from the spec, that <id> is always required but it's not clear if version is a required part of id. I'm guessing no.
<rick_h__> katco: but worth a sanity check email
<katco> rick_h__: actually it looks like the resources spec addresses this: "The third resource, baz, was at revision 12 for the previous stable charm revision, and that is carried forward."
<rick_h__> katco: right, but the thing is that spec was written before details of the channels implementation was known. So there will be differences to check on between the two
<mup> Bug #1554721 opened: juju list-controllers --format yaml to include provider type and properties <juju-release-support> <juju-core:Triaged> <https://launchpad.net/bugs/1554721>
<katco> rick_h__: ok, i'll try to keep with the spirit of the channels work/charm spec
<katco> rick_h__: ty
<rick_h__> katco: ty for thinking on it and asking.
<katco> ericsnow: standup
<menn0> davecheney: race detector CI job FTW: http://reports.vapour.ws/releases/3718/job/run-unit-tests-race/attempt/1074
<menn0> thumper: reviews please: http://reviews.vapour.ws/r/4095/
<menn0> thumper: and http://reviews.vapour.ws/r/4092/
<thumper> ack
<menn0> thumper: they're small
<thumper> done
<menn0> thumper: cheers
<menn0> thumper: I hadn't forgotten about that rename. i'll take care of that rename in a separate PR today.
<thumper> kk
<menn0> thumper: do you why is gopkg.in/errgo.v1 is mentioned in dependencies.tsv? It's not directly imported by github.com/juju/juju. Is it b/c juju/errors relies on it?
<menn0> thumper: actually... juju/errors doesn't depend on it but juju/utils does others do
<davecheney> menn0: looking
<davecheney> menn0: yup, you cannot call assert unless you're in the test goroutine
<davecheney> ie functest(something) { go func() { c.Assert(fail) } } << that's a no no
<menn0> davecheney: actually, that's not the problem in this case
<menn0> davecheney: here it's a boolean being set in one goroutine and checked in another without synchronisation
<menn0> davecheney: I know that you can't assert outside of  the non-main-test goroutine
<menn0> davecheney: when switching between branches where the name of a field in a particular struct has changed "go build" gives the following api/testing/apiaddresser.go:12: inconsistent definition for type modelmigration.TargetInfo during import
<menn0> 	struct { ControllerTag names.ModelTag; Addrs []string; CACert string; EntityTag names.Tag; Password string } (in "github.com/juju/juju/state")
<menn0> 	struct { ControllerTag names.ModelTag; Addrs []string; CACert string; AuthTag names.UserTag; Password string } (in "github.com/juju/juju/watcher")
<menn0> # github.com/juju/juju/worker/provisioner
<menn0> davecheney: I have to do go clean to resolve it
<menn0> davecheney: have you seen that before (Go 1.3)
<davecheney> booh
<davecheney> menn0: i've noticed that git is a little bit thingy about changing the mtime on files when switching branches
<davecheney> sometimes it will, sometimes it won't and that messes up conditional compilation sometimes
<menn0> davecheney: i figured it might be something like that, which makes things hard for go build
<davecheney> fwiw, go 1.5 and later get this right 100% of the time
<menn0> davecheney: PTAL http://reviews.vapour.ws/r/4098/
<davecheney> looking
<davecheney> menn0: shipit
<wallyworld> anastasiamac: perrito666: just finishing with rick, be right there
<anastasiamac> wallyworld: k. just ping when ;
<wallyworld> anastasiamac: perrito666: there now
<davecheney> % juju bootstrap testing aws
<davecheney> Creating Juju controller "local.testing" on aws/us-east-1
<davecheney> local ?
<anastasiamac> davecheney: as per cloud credentials spec :D
<davecheney> i have no .local/cache/juju
<davecheney> nothing
<davecheney> i deleted it all
<anastasiamac> "local" does not refer to your .local
<davecheney> as a user, I asked for aws, why is it talking about local ?
<davecheney> this is a UX paper cut
<anastasiamac> awss is a cloud
<anastasiamac> testing is a controller which is local
<davecheney> local to whom
<anastasiamac> (as in not from soemehere else)
<davecheney> my machine ?
<anastasiamac> to your juju model
<davecheney> so, not someone elses' juju model ?
<anastasiamac> wallyworld: ^^
<anastasiamac> davecheney: yes :D
<anastasiamac> wallyworld: maybe some details can be added to bootstrap help to avoid confusion :P
<wallyworld> davecheney: it's deleiberate to distinguish from a hosted controller bootstrapped by someone else
<davecheney> wallyworld: but I'm bootstrapping
<wallyworld> it's a locally bootstrapped controller
<davecheney> I cannot bootstrap someone elses' controller
<davecheney> by definition
<wallyworld> no but you can use it
<davecheney> so it's name is testing.local ?
<wallyworld> list-controllers will show both local and non-local controllers
<davecheney> so when someone elses uses it they call it testing.local ?
<wallyworld> local.testing
<wallyworld> davecheney: pop into the #juju channel on canonical if you want a better explanation
<davecheney> sure
<mup> Bug #1554797 opened: juju 2.0 bootstrap should explain what was missing <juju-core:New> <https://launchpad.net/bugs/1554797>
<davecheney> wallyworld: anastasiamac apart from that
<davecheney> bootstrap with zero .juju settings worked like a charm
<anastasiamac> \o/
<davecheney> great imprveoemnt over environements.yaml head trauma
<anastasiamac> :D
<davecheney> somehow it picked up my AWS env vars, so I'm happy
<wallyworld> davecheney: yes, it auto discovers a lot of stuff. you can $juju autoload-credentials and it will interactively allow you to save those to the credentials.yaml file. Handy if you have aws credentials in ~/.aws for more than one user and you want to have those available when bootstrapping via the --credential argument
<davecheney> neat
<wallyworld> and environments.yaml is dead, at long last
<davecheney> so, what happens if you use juju backups NNN
<davecheney> while a deploy is running :)
<davecheney> lets fine out ...
<mup> Bug #1554797 changed: juju 2.0 bootstrap should explain what was missing <juju-core:New> <https://launchpad.net/bugs/1554797>
#juju-dev 2016-03-09
<mup> Bug #1554797 opened: juju 2.0 bootstrap should explain what was missing <juju-core:New> <https://launchpad.net/bugs/1554797>
<mup> Bug #1554802 opened: juju deploy should give more information, or less <juju-core:New> <https://launchpad.net/bugs/1554802>
<mup> Bug #1554807 opened: juju backups restore makes no sense <juju-core:New> <https://launchpad.net/bugs/1554807>
<alexisb> so a noob go question what exactly does the "..." do
<alexisb> so for example you have "...string" instead of "string"
<davecheney> it's the varargs operator
<davecheney> so in a function declaration
<davecheney> func f (args ...string) lets you write
<mup> Bug #1554802 changed: juju deploy should give more information, or less <juju-core:New> <https://launchpad.net/bugs/1554802>
<mup> Bug #1554807 changed: juju backups restore makes no sense <juju-core:New> <https://launchpad.net/bugs/1554807>
<davecheney> f("a", "b", "c")
<davecheney> inside f args will be of type []string
<alexisb> ok thanks davecheney
<davecheney> alexisb: https://golang.org/ref/spec#Passing_arguments_to_..._parameters
<menn0> alexisb: also: https://gobyexample.com/variadic-functions
<davecheney> it's slightly confusing when using f if you aready have a []string
<davecheney> in that case you have to use the ... as a suffix
<davecheney> var s []string
<menn0> alexisb: ... can also be used during a function call to expand a slice into separate arguments
<davecheney> f(s...) // don't treat s, []string as a single argument, treat it as the arguments
<alexisb> o! davecheney that last bit is very helpful
<mup> Bug #1554802 opened: juju deploy should give more information, or less <juju-core:New> <https://launchpad.net/bugs/1554802>
<mup> Bug #1554807 opened: juju backups restore makes no sense <juju-core:New> <https://launchpad.net/bugs/1554807>
<davecheney> alexisb: we have both styles inside juju
<davecheney> if you have a fn that already uses a []string (or another slice) then it can be a little more work to pass it down to something else with the ... suffix
<davecheney> OTOH we have many APIs that take a []slice of things, but almost always are called with just one thing
<davecheney> so there is a lot of typing to declare a literal slice of just one thing, in which case changing those APIs to be variadic can make them more pleasant to use
<alexisb> thank you davecheney; that explanation gave me the insight I needed to figure out how to update the func call
<alexisb> geeze I wasted too much time on that :)
<davecheney> wallyworld: everything was going so well
<davecheney> lucky(~/src/github.com/juju/juju) % juju create-model testing2
<davecheney> ERROR provider validation failed: invalid EC2 provider config: model has no access-key or secret-key
<davecheney> create model the right thing ?
<davecheney> a controller has many models ?
<davecheney> so if I have the local.testing controller
<davecheney> i should be able to create a new model in that ?
<wallyworld> davecheney: currently, as of forever, each time you create a new model, you need to supply credentials
<wallyworld> but
<wallyworld> there's a feature branch which relaxes that requirement
<davecheney> so, i dn't need credentials to create the first model
<wallyworld> if you are controller admin, you don't need to re-suipply
<wallyworld> correct
<davecheney> but every subsiquent one I do ?
<davecheney> wat ?
<wallyworld> yes, that was the jes design
<wallyworld> you were on that team :-)
<davecheney> so much for avoiding head trauma
<davecheney> wallyworld: I blame tim
<davecheney> by default
<wallyworld> we are fixing it for 2.0. there was a valid reason at the time
<arosales> Hello juju-core!
<arosales> should I see juju 2.0 in the Xenial archive when I apt-cache search or apt-get install juju?
<arosales> I am currently only seeing 1.25, but could be pilot error
<arosales> scratch that I see 2.0-beta1-0ubuntu1~16.04.1~juju1  in the archive
<arosales> keep up the good work. Looking forward to beta2
<axw> wallyworld: hey sorry I missed standup, didn't get home till 1:30am, so slept in a bit
<davecheney> wallyworld: is the format of creds.yaml document ?
<wallyworld> davecheney: it's in the release notes
<wallyworld> axw: no worries :-) did you want a chat now?
<davecheney> wallyworld: ta
<axw> wallyworld: sure, will be in tanzanite in a minute
<wallyworld> davecheney: the tooling is improving around managing creds, not quite there yet
<alexisb> wow, first experience of existing unit test catching an actual error I introduced into the code
<alexisb> nice
<wallyworld> davecheney: https://docs.google.com/document/d/1ID-r22-UIjl00UY_URXQo_vJNdRPqmSNv7vP8HI_E5U
<wallyworld> alexisb: yay tests :-)
<alexisb> btw davecheney I always blame tim by default as well ;)
<axw> wallyworld: there now
<mup> Bug #1554819 opened: juju help create-model is misleading <juju-core:New> <https://launchpad.net/bugs/1554819>
<perrito666> wallyworld: are you around?
<wallyworld> perrito666: in standup hangout with andrew
<perrito666> jam: you dont have the pre push script in your git
<perrito666> wallyworld: that is an invitation?
<wallyworld> we are talking work stuff so feel free
<katco> wallyworld: natefinch: fyi: https://github.com/juju/juju/compare/nate-minver#files_bucket
<wallyworld> katco: ty, will look after meeting
<katco> wallyworld: natefinch: nate-minver has master merged in; can merge into master with a bless
<thumper> well that took longer than I was expecting...
<thumper> but I guess I should expect that
<thumper> menn0: http://reviews.vapour.ws/r/4100/
<menn0> thumper: looking
<thumper> menn0: I'm just preparing a branch to merge master into model-migration
<thumper> menn0: and I'm thinking we should merge model-migration-control into model-migration
<menn0> thumper: I was thinking the same thing
<thumper> menn0: because you are going to want these functions RSN
<menn0> thumper: indeed
<thumper> cool
<thumper> let's get model-migration synced up with master first
<thumper> because I think model-migration-control is ahead of it there
<menn0> thumper: CI has picked up a timing problem with one of the tests which I'm working on now
<menn0> thumper: and we can merge afterwards
<thumper> sounds good
 * thumper has make check running on merge master
<thumper> good time to go make a coffee
<thumper> yep
<thumper> tests still running
<davecheney> thumper: that's how you know your change is good :)
<davecheney> thumper: how long do the tests ttake on your machine ?
<davecheney> mine are the best part of 30 mins
<thumper> I don't think I have timed a full run recently
<thumper> it used to be around 23 minutes
<davecheney> it takes 25 mins in CI
<davecheney> my times are 30-40 mins locally
<thumper> hmm...
<thumper> my machine has going suspiciously quiet
<davecheney> time.Sleep(60 * time.Minute)
<thumper> github.com/juju/juju/cmd/jujud/dumplogs	
<thumper> last pass
<davecheney> somethings' waiting for monog to time out
<davecheney> then you will receive _ALL_ the stack traces
<thumper> \o/
<davecheney> lucky(~/src/github.com/juju/juju) % juju list-models
<davecheney> NAME     OWNER        LAST CONNECTION
<davecheney> testing  admin@local  20 seconds ago
<davecheney> lucky(~/src/github.com/juju/juju) % juju destroy-model testing
<davecheney> ERROR "testing" is a controller; use 'juju destroy-controller' to destroy it
<davecheney> so, is "testing" a model or not !?!
<thumper> davecheney: cmd/jujud/reboot timed out
<davecheney> rup row
<thumper> davecheney: testing is probably the controller model
<thumper> ah poo
<thumper> someone has added another exported field to serviceDoc
 * thumper goes to see what it is
<thumper> CharmModifiedVersion
<thumper> wallyworld: do you know about this? ^^
<thumper> maybe?
<wallyworld> thumper: that i believe is from the resources work
<thumper> hmm..
<thumper> yeah
<thumper> nate did it
<wallyworld> it is used to track whether a chanr for a service has changed at all
<wallyworld> and fires a hook if needed
<thumper> for what purpose?
<wallyworld> if resources change
<wallyworld> a hook is fired
<wallyworld> it uses the same pattern as we use for config-changed hooks
<wallyworld> thumper: although why that is on the serviceDoc i am not sure
<wallyworld> i guess for config we always fire an initial config changed hook
<wallyworld> whereas for charm-upgrade we don't want to do that
<davecheney> menn0: 2016-03-09 00:08:41 INFO juju.worker runner.go:281 stopped "engine", err: cannot open api: agent should be terminated
<davecheney> is this a dependency engine thing ?
<davecheney> i've never seen that final error message
<menn0> davecheney: that's something fwereade's been working on I believe although I didn't realise it was in master
<menn0> davecheney: when are you seeing it?
<davecheney> in master
<menn0> davecheney: I under conditions I meant?
<davecheney> oh, bootstrap worked but the rest of the agents in the deploy just went to sleep and never woke
<davecheney> i'll have to redeploy to figure out what happened
<davecheney> to be fair, I did a backup while units were deploying
<davecheney> then restored the backup over the top
<menn0> davecheney: that would do it
<davecheney> I didn't expect that to be a good result
<davecheney> i just wanted to see how many pieces broke off
<menn0> davecheney: i believe that you get that error when a machine or entity can't be found at login (or is no longer in the Alive state)
<menn0> davecheney: they thing that connects to the API returns that error in that case, which has special meaning: stop the agent and uninstall from the init system so it doesn't get restarted
<menn0> davecheney: that behaviour has been there forever
<menn0> davecheney: but Will has been fixing and improving that functionality
<davecheney> and that is indeed what it did
<davecheney> agent stoped and the upstart job went away
<menn0> davecheney: i'm not sure if you're dealing with the old or the new version of it (not sure where fwereade is at with merging)
<menn0> davecheney: I have no idea how restore is actually supposed to be used - i.e. what are the expected preconditions
<davecheney> me neither
<davecheney> which makes it a bit hard to tell if I broke it
<menn0> thumper: review done
<thumper> menn0: ta
<menn0> davecheney: really though you shouldn't be able to hose things like this using it
<thumper> davecheney: can I get you to try cmd/jujud/reboot tests?
<thumper> even running by themselves, they are timing out
<thumper> menn0: re Backend
<thumper> menn0: was talking to fwereade this morning
<thumper> before that it was stateMethods
<thumper> he suggested using backend
<thumper> so I went for consistency
<thumper> happy to be more descriptive
<menn0> thumper: I was thinking something like BinariesUploadBackend, or just UploadBackend
<thumper> hmm...
<menn0> thumper: given that there's other stuff in migration.go that's not related to tools/charms upload
<menn0> thumper: I don't feel too strongly about it if you disagree
<thumper> hmm...
<thumper> sounds fine
 * thumper makes changes
<thumper> tools/lxdclient/client_instance.go:331: wrong number of args for format in Tracef call: 1 needed but 2 args
<thumper> how did this even get into master?
<menn0> thumper: yeah, I saw that too
<thumper> I thought we caught that shit
<davecheney> % juju deploy wordpress -n 3 && juju deploy mysql -n 2 && juju add-relation wordpress mysql
<davecheney> [Units]
<davecheney> ID          WORKLOAD-STATE AGENT-STATE VERSION     MACHINE PORTS    PUBLIC-ADDRESS MESSAGE
<davecheney> mysql/0     error          idle        2.0-beta2.1 4       3306/tcp 54.160.80.170  hook failed: "db-relation-joined" for wordpress:db
<davecheney> mysql/1     unknown        idle        2.0-beta2.1 5       3306/tcp 54.205.17.37
<davecheney> wordpress/0 unknown        executing   2.0-beta2.1 1       80/tcp   54.226.146.198
<davecheney> wordpress/1 maintenance    executing   2.0-beta2.1 2                54.204.148.132 (config-changed) installing charm software
<davecheney> wordpress/2 unknown        executing   2.0-beta2.1 3       80/tcp   54.159.101.133
<davecheney> \o/ reproducable builds
<natefinch> thumper: I'm around if you want to talk about CharmModifiedVersion
<natefinch> actually, brb
<natefinch> back
<thumper> menn0: http://reviews.vapour.ws/r/4100/ updated
<thumper> hi natefinch
<thumper> natefinch: what is the purpose of the number?
<natefinch> thumper: we needed to update the service doc such that it would trigger charm-upgrade for something other than changing its charm url
<natefinch> thumper: this is because charm-upgrade is supposed to fire when resources change
<natefinch> thumper: so when resources change, we increment CharmModifiedVersion (we also increment it when the charm url changes, just in case)
<thumper> ok
<natefinch> thumper: the PR review, if you're curious: http://reviews.vapour.ws/r/3910/
<mup> Bug #1554863 opened: juju bootstrap does not error on unknown or incorrect config values <juju-core:New> <https://launchpad.net/bugs/1554863>
<thumper> menn0: my update to model-migrations landed (master)
<thumper> menn0: I'll propose one that merges model-migration-control
<thumper> and look
<mup> Bug #1554863 changed: juju bootstrap does not error on unknown or incorrect config values <juju-core:New> <https://launchpad.net/bugs/1554863>
<mup> Bug #1554863 opened: juju bootstrap does not error on unknown or incorrect config values <juju-core:New> <https://launchpad.net/bugs/1554863>
<thumper> menn0: http://reviews.vapour.ws/r/4102/
<thumper> if you are happy to merge that branch in, lets do it
<menn0> thumper: yep, I have that test fix ready
<menn0> thumper: 2 secs
<thumper> menn0: so.. you are going to merge one final thing into the model-migratiion-control branch first?
<thumper> menn0: when it has the right commits, I'll let you get the bot to merge the two
<menn0> thumper: yep, just this: http://reviews.vapour.ws/r/4103/ (review pls)
<menn0> thumper: yep, I can handle the merge
<natefinch> wallyworld: you around?
<menn0> thumper: mm-control into mm right?
<wallyworld> yup
<thumper> menn0: yeah, this one: https://github.com/juju/juju/pull/4662
<menn0> thumper: ah right, you've already done the merge
<thumper> menn0: well, I clicked on a github button
<thumper> not a lot to do really :)
<wallyworld> natefinch: did you have a q?
<menn0> thumper: so that PR should update if I get further changes into model-migration-control I guess
<thumper> menn0: why add the wait?
 * thumper actually reads the comment
<natefinch> wallyworld: yes, so... I was going to write those tests for charm push-resource by mocking out the http Client... however, it occurs to me, that it's pretty damn fragile to do it that way.  I mean, it requires the tests to know what exact responses some package two layers away is expecting.. totally breaks encapsulation and relies on internal implementation details.
<thumper> menn0: to be honest, still not sure why it waits
<menn0> thumper: yeah, it took me a while of looking at the shared api watcher loop code to figure it out
<menn0> thumper: there's a goroutine which calls Stop as the client side loop exits. it's outside of the main loop monitored by the tomb and can run *after* the worker loop exits
<menn0> thumper: it never happens on my machine but it does in CI, especially on i386, ppc and arm
<wallyworld> natefinch: yeah, for unit tests that's not very useful. that's where the CharmStore strcu can help. but then we need tests to ensure CharmStore does the right thing. and we do at some point need to next the calling of the csclient
<thumper> menn0: but what does that do?
<thumper> menn0: so are we saying that sometimes on other architectures, the results don't come as fast?
<menn0> thumper: yep, on slower or different archs that cleanup goroutine runs a bit later and so the test wasn't seeing the Stop call
<menn0> thumper: https://github.com/juju/juju/blob/master/api/watcher/watcher.go#L73-L86
<thumper> menn0: shipit
<menn0> thumper: ship it for http://reviews.vapour.ws/r/4100/
<menn0> 2 little suggestions
<natefinch> wallyworld: well, I have tests to test that charmstore works and I have tests that test that csclient works... we should also have some full stack CI and/or feature tests, but if those fail, it really just means we have some assumptions that aren't well communicated in our APIs and not covered in our unit tests, which could be fixed easily.
<natefinch> s/charmstore/charmrepo.CharmStore
<thumper> menn0: ta
<wallyworld> natefinch: yep, a feature test to round it all out sounds like is all we need now
<natefinch> wallyworld: ok
<thumper> menn0: ah... yeah, sould have fixed those
<natefinch> my kingdom for people to use an interface, once in a while, somewhere.
<mup> Bug #1507867 changed: juju upgrade failures <canonical-bootstack> <upgrade-juju> <juju-core:Expired> <https://launchpad.net/bugs/1507867>
<mup> Bug #1507867 opened: juju upgrade failures <canonical-bootstack> <upgrade-juju> <juju-core:Expired> <https://launchpad.net/bugs/1507867>
<mup> Bug #1507867 changed: juju upgrade failures <canonical-bootstack> <upgrade-juju> <juju-core:Expired> <https://launchpad.net/bugs/1507867>
<mup> Bug #1546561 changed: juju sets wrong default gateway for lxc containers when using JUJU_DEV_FEATURE_FLAGS=address-allocation <lxc> <maas-provider> <network> <juju-core:Invalid> <juju-core 1.25:Triaged> <https://launchpad.net/bugs/1546561>
<natefinch> ug.... I can't believe the charm command depends on code inside github.com/juju/juju  .... and of course it's now broken
<mup> Bug #1546561 opened: juju sets wrong default gateway for lxc containers when using JUJU_DEV_FEATURE_FLAGS=address-allocation <lxc> <maas-provider> <network> <juju-core:Invalid> <juju-core 1.25:Triaged> <https://launchpad.net/bugs/1546561>
<mup> Bug #1546561 changed: juju sets wrong default gateway for lxc containers when using JUJU_DEV_FEATURE_FLAGS=address-allocation <lxc> <maas-provider> <network> <juju-core:Invalid> <juju-core 1.25:Triaged> <https://launchpad.net/bugs/1546561>
<wallyworld> axw: could i get a small review? https://github.com/juju/charm/pull/196
<axw> wallyworld: ok, looking
<axw> wallyworld: VerifyLocal isn't used anywhere except in a test. where will it be used?
<axw> wallyworld: oh, this is just the charm package. it'll be used in juju... never mind
<wallyworld> axw: i'm doing a core branch that will use it - wehn we deploy bundles with local charm paths
<axw> wallyworld: LGTM
<wallyworld> i almost have that branch ready
<wallyworld> ty
<davecheney> dummy is the only provider that imports the apiserver
<davecheney> and it doesn't do anything with the api
<davecheney> if I delete the call to the apiserver from Dummy's bootstrap method
<davecheney> millions of tests fail
<TheMue> morning o/
<jam> davecheney: fundamentally after bootstrap completes we should have an API server running. Its just that all other bootstraps do it via "jujud bootsrap-???".
<fwereade> davecheney, the main thing is that the dummy provider is basically evil -- but I'm pretty sure it *does* do things with the api? in that it exposes the info necessary to connect to the api, which comes from the apiserver it actually runs
<fwereade> davecheney, the fact that a "dummy" provider goes so far as to actually run an apiserver is the heart of the problem
<fwereade> davecheney, life would be better if dummy were dumber
<fwereade> davecheney, jam: is there a name for that style of test double, that attempts to *simulate* some external component, and invariably ends up hideously complex and brittle?
<dooferlad> frobware: hangout?
<davecheney> fwereade: i want to find out what dummy is doing and move it into a test suite
<davecheney> the interesting thing is not all of the tests fail, only some packages, albeit spectularly
<davecheney> so I suspect that a byproduct of importing dummy is the get a sort of kind of working api server, which we helpfully advertise via a package singleton, and have logic that avoids reinitalising it if it is already present
<fwereade> davecheney, yeah, and we have that happy fun Reset lark as well :(
<fwereade> davecheney, fwiw, tests that *don't* fail when you break dummy would be excellent candidates for disentangling from JujuConnSuite, I think
<fwereade> davecheney, easier bits to carve off the edges, hopefully makes it easier to see what the pleftover problematic tests are depending on, maybe?
<davecheney> the sadface was I wasn't trying to eviscerate dummy
<davecheney> i was actually doing some refactoring of th apiserver
<davecheney> and found a bonkers circular dependency from juju/testing to dummy to the apiserver
<frobware> dimitern, jam: standup?
<rogpeppe> i need a second review on this simple change to the charm package; anyone care to take a look? https://github.com/juju/charm/pull/195
<dimitern> rogpeppe, isn't it better to switch to yaml.v2 throughout?
<rogpeppe> dimitern: i'm not going to be responsible for changing juju-core to use yaml.v2 throughout
<dimitern> rogpeppe, I meant the charm package
<rogpeppe> dimitern: and it's kinda reasonable to be compatible with both, i think
<rogpeppe> dimitern: it does use yaml.v2 only
<rogpeppe> dimitern: but clients can use yaml.v1 to marshal a Meta value
<rogpeppe> dimitern: and i don't want to break that
<dimitern> rogpeppe, any important differences between v1 and v2 wrt behavior ?
<rogpeppe> dimitern: there are a few differences - i think they were documented somewhere
<rogpeppe> dimitern: *most* of juju-core seems to use v2 now
<dimitern> rogpeppe, so marshaling with v1 and unmarshaling with v2 works as well as vice versa?
<rogpeppe> dimitern: it's possible that the only two places in core which use v1 are doing so by mistake
<rogpeppe> dimitern: yeah
<rogpeppe> dimitern: it's still YAML
<dimitern> rogpeppe, btw I had some issues recently with changes spanning multiple subrepos with slightly different dependencies.tsv
<rogpeppe> dimitern: yeah, it can be awkward
<rogpeppe> dimitern: i've found the new -N flag to godeps very useful
<dimitern> rogpeppe, it turned out we don't have a good way of enforcing same revs across multiple related projects
<rogpeppe> dimitern: for converging on an agreed set of deps
<dimitern> rogpeppe, what does it do?
<rogpeppe> dimitern: it updates dependencies only if the deps are newer than what's already there
<dimitern> rogpeppe, that's useful indeed
<rogpeppe> dimitern: i think there is fundamentally no way of enforcing revs across projects
<rogpeppe> dimitern: separate projects are independent
<dimitern> rogpeppe, there should be a way to declare nested deps for juju/juju/ at least and other standalone projects
<dimitern> rogpeppe, that PR LGTM btw
<rogpeppe> dimitern: what do you mean by "nested deps"?
<dimitern> rogpeppe, i.e. dependencies.tsv or juju/juju "including" other .tsvs per import path
<rogpeppe> dimitern: what would it do if those tsvs conflicted?
<dimitern> rogpeppe, some way to verify revisions in juju/juju/deps.tsv for repo X matches the rev used by repo Y that depends on X, and juju/juju depends on both X and U
<dimitern> s/U/Y/
<rogpeppe> dimitern: that sounds like it's going to produce conflicts more often than not
<dimitern> rogpeppe, if they conflicted, you can know and do something about it, rather than get random build failures for subrepos (like I had for charm.v6 recently)
<rogpeppe> dimitern: what I tend to do now is something like: for repo in $(awk '{print $1' < dependencies.tsv}); godeps -N -u $(godir $repo)/dependencies.tsv; done
<dimitern> because charm.v6 needs bundlechanges, which in turn needs revX of yaml.v1 (and charm.v6 uses revY of yaml.v2), effectively refusing to build charm.v6 unless it also depends on yaml.v1 with same revX
<rogpeppe> dimitern: you got a build failure in charm.v6 because of a juju/juju tsv file?
<rogpeppe> dimitern: if in doubt, choose the latest version of all dependencies
<rogpeppe> dimitern: because it's fairly unusual for something to depend on being *earlier* than a certain revision
<dimitern> rogpeppe, yeah, that's what I usually do - and that works well for repos with merge gating that uses godeps -u as part of testing the merge
<rogpeppe> dimitern: one problem is that it's allowed to have cyclic dependencies between repos
<rogpeppe> dimitern: at least you had a build failure rather than a bug later on
<dimitern> rogpeppe, yeah, that's causing some of the issues I suppose
<rogpeppe> dimitern: i found that godeps -N eased my pain quite a bit
<dimitern> rogpeppe, this is the issue I was talking about: https://github.com/juju/bundlechanges/pull/16
<rogpeppe> dimitern: 'cos you can just run it without worrying too much
<dimitern> rogpeppe, bundlechanges thus far didn't have to depend on yaml.v2, but without it it won't build as charm.v6 needs it
<rogpeppe> dimitern: charm.v6 doesn't need it
<rogpeppe> dimitern: only its tests do
<rogpeppe> dimitern: if you run godeps, it'll tell you that
<dimitern> rogpeppe, so you're saying that gating job for bundlechanges should've called godeps -u -t dependencies.tsv instead?
<rogpeppe> dimitern: i don't understand. that's an invalid godeps command.
<rogpeppe> dimitern: the gating job for bundlechanges should always call godeps -u dependencies.tsv as usual
<dimitern> rogpeppe, the "-t" according to "godeps -h" updates tests deps as well
<rogpeppe> dimitern: ah, that's an ambiguity in the help. -t is a no-op with -u.
<rogpeppe> dimitern: it only influences whether testing deps are printed without the -u flag.
<rogpeppe> dimitern: -u always updates all the deps mentioned
<dimitern> rogpeppe, ah, didn't know that detail :) thanks
<rogpeppe> dimitern: i should probably make the docs clearer
<dimitern> +1 :)
 * dimitern steps out for ~1h
<xnox> who is on-call reviewer?
<xnox> =) please review
<xnox> https://github.com/juju/utils/pull/199
<TheMue> xnox: S390? Mainframe?
<TheMue> xnox: neat
<dooferlad> dimitern: http://reviews.vapour.ws/r/4002/ should, I hope, be ready.
 * dooferlad goes for lunch
<dimitern> dooferlad, cheers, will look shortly
<mup> Bug #1555083 opened: Certificate error when visiting the embedded Juju GUI <juju-core:New> <https://launchpad.net/bugs/1555083>
<dimitern> dooferlad, we should have a quick chat when you're back
<perrito666> I am not sure you people saw this since its the sort of stuff that happens during the night :p
<perrito666> https://docs.google.com/spreadsheets/d/1mczKWp3DUuQvIAwZiORD29j5LRb96QZC4mZDn72gAE4/edit#gid=0
<perrito666> quite interesting
<perrito666> comes from https://github.com/davecheney/benchjuju
<natefinch> ...and this is why I still build with 1.4
<natefinch> btw, the discussion among the Go devs: https://groups.google.com/forum/#!topic/golang-dev/DpMyPbclI3o
<natefinch> also, looks like the govmomi code is a SIGNIFICANT addition to our compile times
<natefinch> and this is probably why: https://github.com/juju/govmomi/blob/master/vim25/types/types.go
<perrito666> natefinch: curious name :p
<natefinch> perrito666: it's the vmware cloud api wrapper
<perrito666> I was talking about the vim part :p
<natefinch> yeah, dunno
<perrito666> the whole juju takes 1m3.982s here
<perrito666> 55s of that are jujud
<natefinch> perrito666: what go version are you using, and did you remove $GOPATH/pkg first?
<perrito666> 1.5
<perrito666> natefinch: yep
<perrito666> on my desktop
<perrito666> if I tried this on my laptop I would get significantly higher numbers
<TheMue> simply imagine juju would be written in C++ making high usage of boost.
<TheMue> heya btw
<natefinch> perrito666: is that real time or user time?
<perrito666> natefinch: real
<perrito666> natefinch: do you know how can I run the test build step without running the actual tests?
<natefinch> perrito666: go test -run=xxx
<natefinch> perrito666: it's still slow as hell, since it builds a binary per package
<perrito666> natefinch: that is what I want
<natefinch> perrito666: but obviously faster than actually running tests
 * perrito666 times the test build times
<dooferlad> perrito666: to speed up subsequent runs go test -i will install deps rather than using them as a one-off build.
<dooferlad> dimitern: did you want to jump in a hangout?
<perrito666> dooferlad: tx
<natefinch> perrito666: 28s building with go 1.4.2, 1m5s building with go 1.5.3
 * natefinch goes back to 1.4
<dimitern> dooferlad, sure, is top of the hour ok?
<perrito666> time go test  --run=xxx github.com/juju/juju/... <--- 7m16.197
<dooferlad> dimitern: yep
<dimitern> frobware, voidspace, dooferlad, please have a look at http://reviews.vapour.ws/r/4104/
<dooferlad> dimitern: *click*
<ericsnow> natefinch: PTAL http://reviews.vapour.ws/r/4099/
<dimitern> the diff got messed up somewhat - ipaddresses_test.go is entirely new, while the legacy_ipaddresses_test.go is unchanged
<ericsnow> natefinch: also, I responded in http://reviews.vapour.ws/r/4090/
<TheMue> natefinch: buy a faster computer *lol*
<natefinch> TheMue: the fastest computer in the world isn't going to make 1.5 compile faster than 1.4 ;)
<natefinch> ericsnow: thanks
<perrito666> interesting, when timing it some tests fail
<ericsnow> natefinch: no, thank you!
<katco> ericsnow: natefinch: o/
<ericsnow> katco: \o
<natefinch> ericsnow: I think I'd prefer that service-exists check on the way out... so we are sure we don't get into a race condition
<katco> ericsnow: natefinch: got master merged into minver... i think if we get a bless it will be in 2.0!
<natefinch> katco: amazing, thanks so much!
<TheMue> natefinch: that's right, I only described typical behavior needing always more faster computers to do the same as before
<natefinch> TheMue: yep
<ericsnow> katco: sweet
<katco> natefinch: thanks for coding it up. just wish it wasn't a rushed blitz at the end to land features
<ericsnow> natefinch: that's a good idea, I'll try it out
<natefinch> ericsnow: i.e. try the DB op, see that it failed, check if the service exists, if not, then we have a good idea why it failed ;)
<ericsnow> katco: the mad rush is really making it hard to collaborate with others in the same situation :(
<katco> ericsnow: i know... there are many, many, negatives
<natefinch> ericsnow, katco: working on reviews and getting my stuff landed this morning. See if we can drain that under review column some
<ericsnow> natefinch: +1
<katco> yeah nk
<dooferlad> dimitern: https://plus.google.com/hangouts/_/canonical.com/juju-sapphire ?
<katco> i'm very sorry i haven't been able to perform reviews... i just have 1 last thing in my backlog
<natefinch> esp since we don't actually have any points landed yet :/
<dimitern> dooferlad, omw
<ericsnow> natefinch: I could land this one with re-review from katco (hint, hint): http://reviews.vapour.ws/r/3975/
<ericsnow> katco: :)
<katco> ericsnow: ok ok you just popped to the head of the queue
<perrito666> natefinch: the almost full test run on my desktop 16m58.859s
<natefinch> perrito666: yeah.... *shudder*
<katco> cherylj: did you say the lxd instance with no ssh issue had a fix, or some progress had been made?
 * TheMue remembers the times when juju has been so small running build and tests in a few seconds
<natefinch> TheMue: must have been long before I got here :)
<katco> ericsnow: you have a review, sir
<cherylj> katco: the outstanding issues that I know about with lxd have been addressed.
<ericsnow> katco: (ã^_^)ãâ»ââ» â¬ââ¬ ã( ^_^ã)
<katco> cherylj: hm, ok. i think jrwren was having some issues
 * ericsnow puts table back
<katco> lol
<cherylj> heh
<katco> ericsnow: you've been hanging around wwitzel3 too long
<katco> cherylj: sounds like it may have been a lxd issue though... cmars is chatting with jrwren
<katco> cherylj: hey, when can we expect a bless on the nate-minver branch?
<cherylj> katco: I think that depends on the content of that branch ;)
<cherylj> katco: are you asking when to expect a CI run?
<katco> cherylj: yes :)
<TheMue> natefinch: yep, and we've been a small team too. porting juju from python to go, later exchanging zookeeper with mongo
<TheMue> natefinch: and in a pre-api era, only direct access to the database
<katco> cherylj: ping, have an answer for me yet? :)
<cherylj> katco: sorry, was on a call.
<natefinch> ericsnow: ug.. in that check extension patch... you were right to wonder where the definition for formatMediaType was.... it was in files that didn't get added to git... and unfortunately subsequently got deleted as I switched between branches.
<katco> cherylj: no worries
<cherylj> sinzui or abentley would know better than I
<ericsnow> natefinch: :(
<cherylj> about what the queue looks like
<katco> natefinch: switching branches shouldn't delete files i don't think?
<ericsnow> natefinch: you don't need it if you use a query arg <wink>
<natefinch> katco: no, but when you look and see a resources directory that shouldn't exist and so you delete it.... they do :/
<katco> ...
 * natefinch clutches his foot where he shot it.
<natefinch> luckily this was just the code to copy the FormatMediaType code from 1.6, so it's pretty trivial to replace.
<natefinch> ericsnow: IETF says it should be in the filename param of the content-disposition.
<ericsnow> natefinch: for server responses (not requests), no?
<abentley> katco: it appears to be 6th in the order.
<perrito666> oh please, dont pass content metadata in query parameters, that is a sin in several major religions
<katco> abentley: cool, ty! any eta?
<natefinch> ericsnow: UNder the section called "Form-based File Upload in HTML" :  "The original local file name may be supplied as well, either as a 'filename' parameter either of the 'content-disposition: form-data' header or in the case of multiple files in a 'content-disposition: file' header of the subpart."
<abentley> katco: roughly a day, everything going smoothly.
<katco> abentley: great, thanks :)
<natefinch> ericsnow: http://tools.ietf.org/html/rfc1867
<natefinch> ericsnow: search for filename
<abentley> katco: Less if any of the branches ahead of it have failed to update their version number :-)
<katco> lol
<ericsnow> natefinch: that's for form-based upload
<ericsnow> natefinch: I suppose you could interpret this that way
<natefinch> ericsnow: yes, and the GUI guys will thank me when they want to write a form to let people upload resources :)
<ericsnow> natefinch: I still think it makes more sense as a query arg
<ericsnow> natefinch: good point, though they will still have to supply the other query arg
<katco> abentley: i'm glad you said something... it looks like the version is wrong in the nate-minver branch b/c we were fiddling with that file
<katco> abentley: master has what it's supposed to be set at?
<abentley> katco: Right.
<abentley> katco: We actually tried to test it earlier today: http://reports.vapour.ws/releases/3724
<rick_h__> ericsnow: natefinch +1 to gui wanting to upload resources down the road
<natefinch> rick_h__: is content-disposition:  "formdata; filename=foo.zip" the correct place for a filename for a file we're uploading?  I'd like to make sure we're using a standard place
<katco> abentley: looks like this was the issue? "[description-setter] Could not determine description."
<abentley> katco: No, the issue was that get_git_version failed to determine the version.  Description-setter tries to include the version so that's why *it* failed.
<katco> abentley: 1-line review? http://reviews.vapour.ws/r/4106/
<katco> abentley: gah actually hold on. totally screwed that up
<katco> abentley: ok, corrected
<rick_h__> natefinch: the filename comes up from the browser, I'd defer to hatch on it since it's been a while since I tinkered with it.
 * hatch pokes head in
<natefinch> hatch: file upload via http... we want to include the filename... Content-Disposition: form-data; filename=foo.zip  ... or just pass it as a query param?
<natefinch> hatch: note this is in Go code, so we can make it do wahtever we want... but I want it to stick to standards so no one is surprised down the road
<hatch> this is for resources I see from the backscroll?
<natefinch> yeah, uploading resource files to the controller
<natefinch> from your local machine
<hatch> do we want to allow people to upload multiple files or are we saying it needs to be in an archive(zip)
<katco> ericsnow: can you give me a 1-line review? http://reviews.vapour.ws/r/4106/
<natefinch> filename was a stand-in.  It'll be one at a time
<ericsnow> katco: sure
<natefinch> filename=foo.somedata :)
<ericsnow> katco: LGTM
<katco> ericsnow: ty
<hatch> natefinch: ahh ok so one at a time....sounds good to me
<hatch> natefinch: so sorry I don't understand the question - you want to know what information we will be sending? I suppose that depends on what resources requires, I'm not really familiar with it
<mup> Bug #1555211 opened: Model name that "destroy-model" accepts doesn't match "list-models" output <juju-core:New> <https://launchpad.net/bugs/1555211>
<natefinch> hatch: sorry, no... I'm wondering what the standard way is to include the filename for an HTTP upload of a file
<natefinch> hatch: my googling suggests a header with Content-Disposition: form-data; filename=foo.something   ... but just wanted to make sure that was correct
<hatch> ohh NOW i understand what you're asking
<hatch> ;D
<hatch> sorry
<hatch> yes that is good
<hatch> :)
<natefinch> no, my fault for not describing it more clearly
<natefinch> coo
<natefinch> cool
<natefinch> ericsnow: FWIW, that's what chrome produces when you do a file upload, too (granted, that's explicitly from a webpage not a raw API call... but it seems like a good idea to mimic a browser when doing http calls, to make our lives easier later)
<ericsnow> natefinch: okeedokee :)
<perrito666> natefinch: http cares little about if you are using a web form or just making the request by hand
<cory_fu> Anyone have any idea what "agent-status: failed" means?  http://pastebin.ubuntu.com/15335596/
<perrito666> cory_fu: that juju failed (workload being the charm)
<perrito666> I would guess juju failed to run the relation-changed hook?
<cory_fu> perrito666: The workload status doesn't show any error
<perrito666> cory_fu: unless its a bug, agent status shows errors from juju itself and workload errors in the charm, (agent is being renamed to juju-status in 2.0 to make this more clear)
<perrito666> cory_fu: so this might mean that the workload itself is ok but juju could not run the hook
<perrito666> cory_fu: I am not sure I am explaining this clearly :(
<cory_fu> No, I understand.  This seems to be the error that caused it: http://pastebin.ubuntu.com/15335783/
<cory_fu> After that, the log is just filled with "failed to start "uniter" manifold worker: dependency not available" messages
<perrito666> cory_fu: using master?
<cory_fu> 1.25
<perrito666> cory_fu: could you submit a dmesg on that machine?
<perrito666> that should be trying to write in /var/lib/juju/.../agent.conf
<perrito666> I am a bit worried that you get an io timeout
<cory_fu> perrito666: Where should I submit that?
<ericsnow> uiteam: the resources endpoints shouldn't be in the v4 API, right?
<ericsnow> rogpeppe, rick_h__: ^^^
<rogpeppe> ericsnow: that's right
<ericsnow> rogpeppe: the v4 ReqHandler embeds the v5 one, so the endpoints get pulled along for the ride :(
<rogpeppe> ericsnow: delete 'em from the map
<ericsnow> rogpeppe: k
<mup> Bug #1555248 opened: help text for juju destroy-controller needs improving <helpdocs> <juju-core:New> <https://launchpad.net/bugs/1555248>
<mup> Bug #1555260 opened: (1.25.3) agent-status: failed (could not write settings ... timeout) <juju-core:New> <https://launchpad.net/bugs/1555260>
<bogdanteleaga> any reason wily isn't here? https://github.com/juju/utils/blob/master/series/supportedseries.go#L92
<rogpeppe> uiteam: migration tests (still not for the new channels model though): https://github.com/juju/charmstore/pull/567/files
<natefinch> ericsnow: what do you think for the "filename" constant name? FilenameParam?  pretty much every combination of words I can think of is confusing in some way
<ericsnow> natefinch: if possible, I'd not use a constant (or declare the constant right next to where you use it); I'd expect it to be used in 1 place inside a helper
<natefinch> ericsnow: well, 2 places, one for setting and one for getting
<natefinch> ericsnow: which is why I made it a constant.... 2 places in the same file, I could almost just swing making it a raw string... it just makes me twitch
<ericsnow> natefinch: really the string should be hidden away in some library helper; beyond that I'd say just use some ridiculous (non-exported) name that explicitly declares it
<natefinch> ericsnow: filenameParamForContentDispositionHeader... got it
<ericsnow> natefinch: the tricky thing is that the value is dependent part of a "standard" and should be hidden away in something that couples it to handling that RFC
<ericsnow> natefinch: fine with me :)
<natefinch> ericsnow: I agree, believe me.  I hate implementing standards ad-hoc in the middle of the rest of my code.
<ericsnow> natefinch: yeah, no joke :(
<mup> Bug #1555291 opened: TestStartInstancePopulatesNetworkInfoWithoutAddressAllocation fails on centos <centos> <ci> <regression> <test-failure> <juju-core:Triaged> <https://launchpad.net/bugs/1555291>
<natefinch> ericsnow: the build tag means only build if go 1.6 is not defined.... I was calling this _go15 to indicate it's go 1.5 (and below)... I just didn't know how to indicate "and below".  open to suggestions.
<ericsnow> natefinch: just drop _go15 bit; given the existence of a _go16.go file, that implies the alternative covers everything else
<natefinch> ericsnow: good point.   I was using them as placemarkers, too, hoping to delete all of those files once we move to 1.6 for everything.. but I think the TODOs are ok
<ericsnow> natefinch: it may also make sense to reverse that, using XXX.go for the 1.6+ code and XXX_pre-go16.go for the rest
<natefinch> ericsnow: I think I like that better, since in theory we should be able to just delete all the go15 files at some point
<ericsnow> natefinch: exactly
<mup> Bug #1555291 changed: TestStartInstancePopulatesNetworkInfoWithoutAddressAllocation fails on centos <centos> <ci> <regression> <test-failure> <juju-core:Triaged> <https://launchpad.net/bugs/1555291>
<ericsnow> natefinch: make the exceptional case stand out
<natefinch> ericsnow: nice, thanks
<ericsnow> natefinch: np
<ericsnow> natefinch: also, I left a few more comments on that review request
<ericsnow> natefinch: but that should be about it for me :)
<natefinch> ericsnow: at least filenames are trivial to change
<thumper> o/
<mup> Bug #1555291 opened: TestStartInstancePopulatesNetworkInfoWithoutAddressAllocation fails on centos <centos> <ci> <regression> <test-failure> <juju-core:Triaged> <https://launchpad.net/bugs/1555291>
<katco> ericsnow: natefinch: new version of the architectural doc up. relevant section on the charm command pasted into https://docs.google.com/document/d/1T_7XQ-pmE4gFiD2SSaZnQUqlcLkA7dk0c0PB_ebEkrI/edit# for discussion
<ericsnow> katco: thanks
<katco> ericsnow: natefinch: and now i'm free for reviews! what can i do?
<natefinch> katco: https://github.com/juju/charmrepo/pull/65  http://reviews.vapour.ws/r/4047/  http://reviews.vapour.ws/r/4006/  https://github.com/CanonicalLtd/charmstore-client/pull/181
<katco> natefinch: ty
<ericsnow> natefinch: I have http://reviews.vapour.ws/r/4090/ and http://reviews.vapour.ws/r/4099/, but natefinch's 4006 should take priority
<natefinch> ericsnow: ship it on the file extension stuff?
<ericsnow> natefinch: I'd still like to see that copied code in a separate package (like we've done in the past for code copied from the stdlib, etc.)
<natefinch> ericsnow: bah, ok... yes, that's probably for the best
<deanman> I'm interested on writing a new provider for a cloud infra not currently supported. Do i have to write it in Go or can i use other programming lanugages?
<ericsnow> natefinch: I explained a little more in a comment on my review
<katco> deanman: at the moment, you'll have to write it in go
<katco> deanman: all providers live in the main repo here: https://github.com/juju/juju/tree/master/provider
<katco> deanman: we've tried to push for a plug-in model in the past so that you can write providers in any language, but that has been met with resistance. if that's something you'd like to see, please do reach out on the mailing list
<deanman> Can i wrap an already provided CLI tool in a Go provider or do i have to implement REST calls in Go from scratch?
<katco> deanman: i think the implementation doesn't matter so much. juju just needs to know how to interop with your provider
<ericsnow> deanman: adding dependencies on some CLI may also be a harder sell (harder than depending on some 3rd party Go library)
<deanman> katco: Is there any guide on how to start about on such a project?
<katco> deanman: https://github.com/juju/juju/wiki/Implementing-environment-providers
<katco> deanman: i also have some diagrams that aren't on the wiki (my fault) if you're interested
<deanman> I wanted to be able to manage eucalyptus infrastructure and did try to use the AWS one but it seems Euca was returning something extra (although claiming close to 100% AWS compatibility) so i decided whether it is reasonable to implement it from scratch...
<katco> deanman: we do have some precedent for similar providers
<katco> deanman: the recommendation is that you find the commonality, split that out into modules of responsibility (e.g. authenticator, instanceCreator, whatever), and then pass those into each provider which would receive interfaces
<deanman> katco: What do you mean? (yeah i would be interested in any material i can get to start researching and hacking)
<katco> deanman: architectural diagrams. here's probably the most helpful one: https://www.dropbox.com/s/kxlg150cjm3sggl/drivers-class.eps?dl=0
<katco> deanman: it may be a bit out of date, but combined with the wiki that should get you going
<deanman> katco: thank you for your help...
<natefinch> deanman: hopefully it would be a matter of tweaking the AWS provider so it can work with Eucalyptus as-is (without harming AWS compatibility)... if that's not feasible, refactor it so you can swap out the parts that need to be different between the two
<katco> deanman: hth, and welcome to the juju community ^.^
<katco> natefinch: that would add cyclomatic complexity... best not to have several if statements in the body of the provider
<deanman> natefinch: Yeah, i believe so, some first tests showed that euca was returning a "timestamp" field which aws provider didn't expect or something like that..
<natefinch> katco: hopefully it wouldn't just be if statements... I was thinking more like being slightly more flexible about the expected responses etc
<katco> natefinch: and how would you implement that flexibility? ... :)
<natefinch> katco: depends on how you need to be flexible... ignoring fields you don't understand, rather than erroring out, for example.
<katco> natefinch: and how would you make that decision to ignore the field?
<katco> natefinch: tldr; at some point you're talking about a branching conditional, i.e. cyclomatic complexity
<ericsnow> natefinch: thanks for addressing all my concerns! :)
<ericsnow> natefinch: LGTM
<natefinch> ericsnow: thanks for helping making the code better :)
<ericsnow> natefinch: teamwork! :)
 * natefinch sings kumbaya
<mup> Bug #1555325 opened: Active model determination is weak <docteam> <juju-core:New> <https://launchpad.net/bugs/1555325>
<mup> Bug #1555325 changed: Active model determination is weak <docteam> <juju-core:New> <https://launchpad.net/bugs/1555325>
<mup> Bug #1555325 opened: Active model determination is weak <docteam> <juju-core:New> <https://launchpad.net/bugs/1555325>
<natefinch> dammit godeps
<katco> ericsnow: natefinch: standup time
<thumper> :-(
<thumper> just found that doing /o\ on my rigged standing desk is double fail
<thumper> all tilts
<menn0> thumper: http://reviews.vapour.ws/r/4107/ please (boring one)
 * thumper looks
<thumper> shipit
 * thumper is poking around with service leadership...
<thumper> oh FFS
 * thumper headdesks
<thumper> sometimes I think we do things hard just for the hell of it
<mup> Bug #1555355 opened: MachineSerializationSuite.TestAnnotations unit test failure (Go 1.6) <ci> <go1.6> <test-failure> <unit-tests> <juju-core:Triaged> <https://launchpad.net/bugs/1555355>
<natefinch> thumper: lol yep
<alexisb> thumper, you sound like you are having a fun morning
<thumper> yeah... *fun*
<thumper> today is a crazy day just with home stuff
<thumper> don't need crazy work stuff too
<alexisb> is there work that exists without crazy?
<thumper> heh, yeah
 * thumper goes and pokes code with a stick while thinking about making a coffee
<menn0> thumper: easy one: http://reviews.vapour.ws/r/4108/
<thumper> shipit
<menn0> thumper: cheers
<thumper> I still struggle with simple go integer for loops
<thumper> I always want to write:
<thumper> for i := 0; i < n; ++i {
<alexisb> thumper, those of us on the release call will be late to the leads call
<thumper> alexisb: ok
<mup> Bug #1555368 opened: Panic due to sending on closed channel <ci> <intermittent-failure> <test-failure> <juju-core:Triaged> <https://launchpad.net/bugs/1555368>
<mup> Bug #1555368 changed: Panic due to sending on closed channel <ci> <intermittent-failure> <test-failure> <juju-core:Triaged> <https://launchpad.net/bugs/1555368>
<thumper> alexisb: ETA?
<perrito666> wallyworld: standup not happening?
<wallyworld> perrito666: not on thursdays, stuck in meetings :-(
<perrito666> wallyworld: I know, but since sometimes it happens I ask
<wallyworld> perrito666: we can catch up a bit later maybe
<perrito666> better safe
<wallyworld> ty
<perrito666> I ve been wanting to write a blog post for days, this is my chance
<mup> Bug #1555368 opened: Panic due to sending on closed channel <ci> <intermittent-failure> <test-failure> <juju-core:Triaged> <https://launchpad.net/bugs/1555368>
<katco> ericsnow: can you move the resources tech debt cards to the tech debt board?
<ericsnow> katco: sure
<katco> ericsnow: also, we have past 3/22 to fix bugs. ~4/12. so we should figure out what's most important to work on next
<ericsnow> katco: k
<katco> ericsnow: imo, it's definitely supporting revisions of resources in the resource flag. wallyworld ?
<ericsnow> katco: fine with me
<wallyworld> ericsnow: katco: yeah, i think we do the resource flag work
<katco> wallyworld: k
<katco> ericsnow: we should point this
<katco> ericsnow: can you create a user story card with tasks defined so we can point first thing tomorrow?
<katco> ericsnow: sorry otp
<ericsnow> katco: sure
<katco> ericsnow: ta
<wallyworld> perrito666: wanna do standup now? too late?
#juju-dev 2016-03-10
<fwereade> I think I need someone to explain the TestSystemKillCallsEnvironDestroyOnHostedEnviron test in featuretests
<fwereade> because it looks like it (1) adds a hosted model (2) blocks that model's destruction (3) creates an undertaker that can't connect and silently fails in the background (4) checks that some dummy environment was destroyed... and I really can't see how it all fits together
<fwereade> ...yeah, it all works fine if I just delete the code that starts the undertaker
<fwereade> ohhhhh
<fwereade> wait
<fwereade> are we still running an undertaker in JujuConnSuite or something?
<fwereade> ...apparently not
<fwereade> waigani_, does TestSystemKillCallsEnvironDestroyOnHostedEnviron ring a bell?
<fwereade> waigani_, ISTM that it runs an undertaker that doesn't do anything
<fwereade> waigani_, because it still passes if I don't run it
<mup> Bug #1555391 opened: MachineSuite failed during unit test <ci> <intermittent-failure> <test-failure> <unit-tests> <juju-core:Triaged> <https://launchpad.net/bugs/1555391>
<thumper> fwereade: waigani_ is not around for a while due to paternity leave
<thumper> fwereade: so he won't answer :)
<fwereade> waigani_, ignore me, you have important things to do
<waigani_> fwereade, thumper: it's true, I'm not working - had a quick look though. Yes I wrote it, it did fail when not called. I see it has changed a bit, also there is the dep engine work? Sorry, nothing jumps out :(
<thumper> Is anyone else seeing the tests from  github.com/juju/juju/cmd/jujud/reboot timeout all the time?
<fwereade> thumper, I haven't, fwiw
<fwereade> if anyone's will to live is inconveniently strong: http://reviews.vapour.ws/r/4110/
 * thumper peeks
<thumper> fwereade: looks pretty freaking big to me
<davecheney> thumper: wat>  import cycle detected: github.com/juju/juju/api/backups -> github.com/juju/juju/apiserver
<thumper> ??
<davecheney> nm
<davecheney> i found the problem
<davecheney> the amount of coupling between the api server and client is facepalm
<davecheney> thumper: here is the fix
<davecheney> https://github.com/juju/juju/pull/4673
<davecheney> it's tiny
<thumper> how did we get an import cycle?
<davecheney> see yesterdays rant about dummy importing the apiserver
<davecheney> in doing some other refactoring I hit this
<davecheney> have a look at the branch
<thumper> shipit
<davecheney> thanks
<wallyworld> axw: tiny if you have a sec https://github.com/juju/bundlechanges/pull/17
<axw> wallyworld: LGTM
<wallyworld> ty
<menn0> wallyworld, axw: is it a known issue that if you bootstrap 2 local (lxd) controllers at the same time, one of the them will fail?
<axw> menn0: don't think I've tried it, not sure if it's known by others. what happens?
<menn0> wallyworld, axw: there seems to be some reliance on the controller being bootstrapped being the "current" controller
 * menn0 pastebins
<menn0> axw: here: http://paste.ubuntu.com/15339061/
<menn0> axw: the 2 bootstraps were running at the same time
<wallyworld> well looks like a bug there :-(
<axw> menn0: thanks, looks like a bug in the client code. can you please file a bug?
<wallyworld> menn0: why can't you go get a cup of coffee while waiting like everyone else :-P
<axw> I'll take a look after I finish this up
<menn0> wallyworld: when trying out migration functionality it's super nice being able to quickly spin up 2 controllers at once :)
<wallyworld> i know, just yanking your chain :-)
<menn0> wallyworld: i'm just happy it's even possible now with the LXD provider
<wallyworld> yep, it is so much better
<menn0> otherwise i'd be using AWS or something all the time
<davecheney> lucky(~/src/github.com/juju/juju/apiserver) % pt api/private
<davecheney> resource.go:
<davecheney> 14:     internalserver "github.com/juju/juju/resource/api/private/server"
<davecheney> the apiserver depends on a private type (if there is such a thing) from the resource api
<davecheney> wat
<wallyworld> axw: here's the charm repo update https://github.com/juju/charm/pull/197
<axw> wallyworld: done
<wallyworld> ta
<menn0> wallyworld, axw: the ticket for that lxd provider, concurrent bootstrap issue is here: https://bugs.launchpad.net/juju-core/+bug/1555430
<mup> Bug #1555430: LXD bootstrap fails current controller is switched during bootstrap <lxd> <juju-core:New> <https://launchpad.net/bugs/1555430>
<wallyworld> ta
<axw> menn0: thanks
<menn0> wallyworld, axw: it also happens if you use switch while a lxd bootstrap is in progress
<menn0> (same root cause I suspect)
<axw> menn0: yeah, I think we just need to set the current model name using the canonical form, so it doesn't try to resolve the current controller
<menn0> axw: sounds feasible
<mup> Bug #1555430 opened: LXD bootstrap fails current controller is switched during bootstrap <lxd> <juju-core:New> <https://launchpad.net/bugs/1555430>
<mup> Bug #1555430 changed: LXD bootstrap fails current controller is switched during bootstrap <lxd> <juju-core:New> <https://launchpad.net/bugs/1555430>
<wallyworld> axw: last one, no rush, can't land yet anyway http://reviews.vapour.ws/r/4114/
<mup> Bug #1555430 opened: LXD bootstrap fails current controller is switched during bootstrap <lxd> <juju-core:New> <https://launchpad.net/bugs/1555430>
<wallyworld> axw: will i double up with you if i implement bootstrap maas/<server-ip>
<axw> wallyworld: nope
<wallyworld> ok, i'll do that
<axw> wallyworld: I'm probably going to have to add CredentialsStore to ClientStore after all... all model commands will need it to pass to juju/api.go
<wallyworld> ok
<axw> wallyworld: sorry for the extra work before, didn't see that coming
<wallyworld> np, i thought i did but wasn't sure
<wallyworld> worth trying to keep it separate
<axw> wallyworld: it's still possible, but more trouble than it's worth I think. all the command tests would then need to provide multiple mocks. if it was just bootstrap and a couple of commands, it would be okay
<axw> but since it's all of them...
<wallyworld> yeah
<wallyworld> axw: a small one http://reviews.vapour.ws/r/4115/
<axw> wallyworld: I don't think this is useful without the MAAS client profile reading code? you'll still need to record the credentials, so you haven't really gained much
<wallyworld> axw: agreed, but what you have gained is not having to manually edit *two* yaml files
<wallyworld> and in our getting started, we talk about credentials
<wallyworld> so being able to bootstrap maas right after that is a win
<wallyworld> the getting started was just added to the release notes
<axw> wallyworld: sure, I suppose so. it'd be nice if we could just use the CLI profiles, but I guess that can still be done later.
<wallyworld> axw: yeah, i don't even know what the CLI profile format or locaton is tbh
<axw> wallyworld: it would appear to be an sqlite3 database
<axw> ~/.maascli.db
<wallyworld> hmmm, ok. i have asked them about providing a .json file
<axw> wallyworld: we may just be able to use the "maas" CLI directly, ther eis a command to list
<axw> not sure if it has the right details tho
<wallyworld> we need the 3 parts to the apikey - token key, token secret, client key
<axw> looks like it does
<axw> it'll print out the profile name, URL and creds
<wallyworld> axw: wow, ok, i didn't realise we had that. what generates that sql db?
<axw> wallyworld: "maas login"
<wallyworld> because i've only ever logged in to the web ui
<wallyworld> axw: how hard woud it be to whip up a credential detector for maas then?
<axw> wallyworld: shouldn't be hard at all, but I don't have a MAAS set up to test with atm
<wallyworld> damn, ok
<wallyworld> was thinking it would be nice to sneak into the beta
<axw> wallyworld: just FYI, I'm changing the interface of EnvironProvider again, so this may take a little while yet.
<axw> "this" being the bootstrap config changes
<wallyworld> ok, np
<wallyworld> axw: i pushed fixes to your review, there's a couple of issues i've commented on and/or dropped, feel free to query. bbiab, school pickup
<axw> wallyworld: ok, thanks. will look a little bit later
<mup> Bug #1555475 opened: "juju bootstrap ... lxd" fails if lxd listening to some but not all addresses <lxd> <juju-core:Triaged> <https://launchpad.net/bugs/1555475>
<TheMue> morning
<frobware> dimitern: nope, /e/n/i/ does not get additional iface stanzas created if you apply a profile during lxc init.
<dimitern> frobware, right, that's not so surprising actually, as lxc typically ignores /e/n/i when configuring networking on boot
<frobware> dimitern: I was just merging master. You recently changed github.com/juju/schema and github.com/juju/testing, we want the maas-spaces2 version in depds.tsv, correct?
<dimitern> frobware, yeah, unless in master those are using more recent revs
<dimitern> frobware, dooferlad, sorry guys, I'll be 5m late for standup
<mattyw> fwereade, ping?
<dimitern> frobware, voidspace, dooferlad, http://reviews.vapour.ws/r/4117/ - fixes bug 1554584, please have a look
<mup> Bug #1554584: TestAddLinkLayerDevicesInvalidParentName in maas-spaces2 fails on windows <ci> <test-failure> <windows> <juju-core:Incomplete> <juju-core maas-spaces:In Progress by dimitern> <https://launchpad.net/bugs/1554584>
<voidspace> dimitern: looking
<dimitern> managed to get the state tests to pass on windows
<frobware> dimitern: that's great. thx
<voidspace> dimitern: what was the problem with ".." on windows?
<voidspace> dimitern: anyway, the change LGTM
<voidspace> dimitern: frobware: dooferlad: reinstalled maas 2 with controller with only one nic - looks like the same issue commisioning nodes so trying reconfiguring the world
<dimitern> voidspace, thanks
<mup> Bug #1554584 opened: TestAddLinkLayerDevicesInvalidParentName in maas-spaces2 fails on windows <ci> <test-failure> <windows> <juju-core:Incomplete> <juju-core maas-spaces:In Progress by dimitern> <https://launchpad.net/bugs/1554584>
<dimitern> voidspace, the problem is linux and windows consider different NIC names as valid - in linux's case "." and ".." are not allowed
<voidspace> dimitern: right
<voidspace> rack controller had wrong address, region controller had the right one it seems
<voidspace> still 400 error on commission
<frobware> dimitern, voidspace, dooferlad: merge master into maas-spaces2, http://reviews.vapour.ws/r/4118/
<dimitern> frobware, looking
<frobware> dimitern, voidspace, dooferlad: unit tests passed on my machine
<dimitern> frobware, how did you update the dependencies.tsv?
<dimitern> frobware, plese use godeps github.com/juju/juju/... instead of just replacing revs
<frobware> dimitern: ah... so that's how I've done it in the past.
<voidspace> frobware: looks like that doesn't have discoverspaces worker changes - so they haven't landed on master
<voidspace> fwereade must have done them in a branch then, rather than on master
<voidspace> so it's fine
<voidspace> (from my perspective)
<dimitern> frobware, so which files had conflicts?
<frobware> dimitern: listed in the commit: dependencies.tsv, provider/maas/bridgescript_test.go and provider/maas/environ.go
<dimitern> frobware, ah, sorry - navigating a giant merge is not well supported on github ui
<fwereade> voidspace, yeah, it's on MADE-model-workers
<dimitern> frobware, LGTM
<frobware> dimitern: since I did the godeps update and rebuild make check, unit tests now fail.
<dimitern> frobware, oh - what failed?
<voidspace> fwereade: cool, thanks
<frobware> dimitern: FAIL: client_macaroon_test.go:58: clientMacaroonSuite.TestAddLocalCharmSuccess
<dimitern> frobware, hmm.. I've pulled your branch and trying the same
<frobware> dimitern: the branch you're pulling doesn't have the update to deps...tsv
<dimitern> frobware, ok, so I might have mislead you
<dimitern> frobware, just a sec..
<frobware> dimitern: why is using godeps better than selectively choosing between A and B during a merge conflict?
<dimitern> frobware, so, this is what I did:
<dimitern> frobware, git checkout frobware/maas-space2-merge-master-at-0582881f (I have rev 193...)
<dimitern> frobware, godeps -u dependencies.tsv & go install -v github.com/juju/juju/...
<dimitern> frobware, then godeps -N github.com/juju/juju > new-dependencies.tsv && diff -u dependencies.tsv new-dependencies.tsv - revs are the same, but a few dates got updated, while some probably no longer used repos got dropped
<dimitern> frobware, finally, rm -fr $GOPATH/pkg ; mv new-dependencies.tsv dependencies.tsv ; godeps -u dependencies.tsv (passed ok) ; go install -v github.com/juju/juju/... (all ok still) - now running make check
<dimitern> frobware, this is the diff - http://paste.ubuntu.com/15340794/
<dimitern> so far I test failure, flaky as re-runs pass: http://paste.ubuntu.com/15340800/
<dimitern> s/far I/far 1/
<frobware> dimitern: let's HO, I get different results to your diff
<dimitern> frobware, so I guess the steps above yielded the same set of deps more or less as in your case, but with the added benefit of also having the correct timestamps and sort order
<dimitern> frobware, ok, omw to standup HO in a moment
<frobware> dimitern: I pushed the updated deps
<dimitern> frobware, cheers
<dimitern> frobware, apparently virsh have changed and now "list" does not show inactive domains, unless you pass --all
<dimitern> frobware, so not sure if maas is broken due to that or what.. doing dist-upgrade on the maas machine just to be sure
<mup> Bug #1555585 opened: Master dumps a "client.crt" and "client.key" file in CWD when copying images <lxd> <juju-core:Triaged by jameinel> <https://launchpad.net/bugs/1555585>
<frobware> dimitern: that 'virsh list --all' was always a thing for me
<dimitern> frobware, I'm unable to start any kvm even manually on my machine - hitting https://bugzilla.redhat.com/show_bug.cgi?id=680821 apparently :/
<frobware> dimitern: that's an old bug and kernel
<dimitern> frobware, yeah, this is more recent: http://stackoverflow.com/questions/6307950/virt-install-error
<dimitern> although uncommenting `user="root"` and `group="root"` in /etc/libvirt/qemu.conf and restarting libvirt-bin didn't help
<frobware> voidspace: did I misunderstand your recent change around space id vis-a-vis names: I get this from status: ... interfaces=peer:space=1;reverseproxy:space=1;website:space=2 zone=default
<dimitern> frobware, interesting.. I learned something today: http://www.agix.com.au/kvm-error-ioctlkvm_create_vm-failed-16-device-or-resource-busy/
<frobware> dimitern: aha, yes. :)
<dimitern> frobware, apparently you can't run a virtualbox vm at the same time as a kvm machine
<dimitern> :)
<frobware> dimitern: in that scenario what does kvm-ok report?
<frobware> dimitern: you want lxd anyway. :-D
<dimitern> frobware, reports as expected
<dimitern> frobware, INFO: /dev/kvm exists
<dimitern> KVM acceleration can be used
<dimitern> frobware, bootstrap is now going
<dimitern> frobware, it still takes ~4-5m for the bridge script to complete (on a node with 2 phys nics and 3 vlan nics each)
<dimitern> frobware, I can see that with ps xawwf after ssh-ing into the node as bootstrap still goes
<dimitern> frobware, so we might need to add a shorter maxwait stanza (or whatever it is)
<dimitern> frobware, alternatively, this slowdown can be due to this: https://bugs.launchpad.net/ubuntu/+source/ntp/+bug/246203 (or something like this, still related to ntpdate dead-locking)
<mup> Bug #246203: ntp init script started multiple times - causing 180 seconds wait on boot <ntp (Ubuntu):Fix Released> <https://launchpad.net/bugs/246203>
<dimitern> frobware, I can confirm the bundle deployment worked as expected, so let's merge it
<voidspace> frobware: that sounds right
<voidspace> frobware: oh, from *status*
<voidspace> frobware: status should report name
<voidspace> frobware: looks like there's somewhere still using ProviderId instead of name then
<voidspace> frobware: I'll look into it
<frobware> voidspace: thanks
<jam> tych0: dooferlad: if you want to do a followup review of the LXD patches: http://reviews.vapour.ws/r/4082/
<jam> should handle bug #1555585
<mup> Bug #1555585: Master dumps a "client.crt" and "client.key" file in CWD when copying images <lxd> <juju-core:Triaged by jameinel> <https://launchpad.net/bugs/1555585>
<jam> as well let us set "image-stream: daily" so when you bootstrap you get the current daily image
<jam> frobware: ^^ looks like you are OCR for today.
<frobware> jam: yep
<frobware> jam: releases vs released. isn't the stream releases?
<jam> the string is cloud-images.ubuntu.com/releases, but we use "ImageStream: released" internally
<jam> If you look at environs/config/config.go the default is "released"
<jam> frobware: https://github.com/jameinel/juju/blob/master/environs/config/config.go#L1103
<frobware> jam: was asking because I set up a local mirror yesterday and somewhat intuitively did `mkdir images/released' only to notice the URL used releases.
<jam> frobware: yeah. We have a bit of code for other providers that does "val = stream; if val == released: val = "releases" somwhere in the code
<jam> frobware: I believe in the simplestream metadata itself it is "released"
<jam> frobware: http://cloud-images.ubuntu.com/releases/streams/v1/com.ubuntu.cloud:released:aws.sjson
<jam> noticed the "released" in the URL
<jam> and "released" is part of the content, as well.
<jam> Yay for consistency.
<jam> frobware: anyway, review appreciated, will be walking the dog for 30 min or so.
<tych0> jam: looks good to me
<jam> frobware: I think I addressed your comments, but I had some questions, can you clarify?
<voidspace> frobware: how were you getting that status line?
<voidspace> frobware: is that from a deployed service - and was it deployed with constraints/bindings ?
<frobware> jam: looking
<TheMue> jam: 15 min downstairs, 15 min upstairs? ;)
<frobware> voidspace: I was using the dooferlad's maas-spaces.py mediawiki demo, so yes to constraints.
<jam> TheMue: 5 min down, walk the dog for ~20, 5 min back
<frobware> jam: I'm impressed there's no diff between down and up. :)
<TheMue> jam: which floor? photos always seem to be very high
<jam> frobware: elevators. I don't usually walk 61 flights.
<TheMue> ouch, 61
<jam> TheMue: I've walked it down when there was smoke once. About 20 min down
<TheMue> jam: good for physics, but no must have for each day
<jam> TheMue: would be better for me if I did :)
<perrito666> Jam stairs are a great exercise
<jam> perrito666: I've been tempted to try it up once, but I don't think it would go super well.
<TheMue> jam: oh yeah, in my case too. but already sharpening myself a bit.
<perrito666> You get used to :p
<TheMue> perrito666: I had it for some time with 6 floors for parking and then 4 into the office, has been fine, but please not more than these
<perrito666> Lol i think i could try it once a day for cardio
<voidspace> frobware: if it's just showing constraints then that's "correct"
<voidspace> frobware: as in, that's what we pass through to maas
<perrito666> The thing is , i have fear of heights so i might not like to go 61 floors up
<TheMue> perrito666: currently I have to admit I'm sitting in the fourth floor and take the elevators. so it's a good hint, will take the stairs down later.
<TheMue> perrito666: fear of heights in buildings or also when flying?
<frobware> voidspace: let me scrollback to see if I can find the output...
<voidspace> frobware: anand what format are you using for status
<voidspace> frobware: I'm not seeing anything like that in default status
<perrito666> Themue just buildings
<frobware> voidspace: http://paste.ubuntu.com/15341413/
<voidspace> frobware: that's not "status"...
<TheMue> perrito666: Always insteresting how different we react on buildings or flights.
<frobware> voidspace: fair enough. using old terminology.
<voidspace> frobware: those constraints are being returned by maas
<voidspace> frobware: so that is the constraints we passed to maas - it is "correct"
<voidspace> frobware: that doesn't explain the 409 conflict though
<voidspace> frobware: to fix it we'd have to parse the error strings
<TheMue> btw, how has the last sprint been? afaik in Oakland?
<voidspace> (i.e. to replace space ids with space names)
<jam> thanks for the reviews dooferlad and frobware
<frobware> voidspace: and that's why I ... yep, exactly.
<perrito666> Themue: my current theory is that I only have this issue with bing windows
<voidspace> frobware: the change I made recently was to report the space name if we discover a conflict *before* we pass it to maas
<TheMue> perrito666: some do have it when standing outside on high towers or bridges
<voidspace> frobware: this conflict error from maas indicates that it doesn't have a node matching those constraints
<voidspace> frobware: which we can't detect in advance
<frobware> voidspace: which is odd because the script goes and makes everything the same...
<voidspace> frobware: but for example if you had a binding to space "foo" and specified a constraint "^foo" then you'd have a conflict we can detect
<frobware> voidspace: "before we pass it to mass" <- thanks
<voidspace> frobware: right, I've not used jame's script so I don't really know what it's trying to do
<voidspace> np
<voidspace> we still detect the conflicts using provider id - we just change them to names in the error messages
<frobware> voidspace: was just trying to understand the bits and pieces that go whizzing by
<frobware> voidspace: however, as an end-user how do I understand and resolve the error message I got back
<voidspace> frobware: well - the error is that maas has no machine available that meets your requirements
<voidspace> frobware: hopefully as an end user you understand your requirements
<frobware> voidspace: :) but UX.
<voidspace> frobware: the error message is relatively clear "No available node matches constraints"
<voidspace> frobware: we're directly surfacing a provider error though
<frobware> voidspace: and "space=2" means... ?
<voidspace> frobware: if you really don't know what spaces you asked for then "juju list-spaces" does tell you ids
<voidspace> frobware: but this is an error direct from maas and we *can't* depend on the error format (i.e. parse it)
<frobware> voidspace: all I'm really questioning is the user experience. and whether we can have names
<voidspace> frobware: not in the errors that maas gives us back, no
<frobware> voidspace: our only option would be to parse the string and interpolate as we can. true?
<voidspace> frobware: that would require the error string from maas to be of a fixed format - and the format of error strings is *not* part of the api
<voidspace> we *should not* start to depend on it
<voidspace> IMO
<frobware> voidspace: understood. Just wary that we also create a problem for ourselves with bug triage, explaining to customers, et al.
<voidspace> frobware: I'm confident it will be less effort explaining this to users than it will be fixing it (and then refixing it every time the error message format changes)
<voidspace> frobware: we *could* catch 409 errors specifically and build a pretty-printed constraints string ourselves as well as showing the maas error (we don't want to mask the underlying error - the error may have nothing to do with spaces)
<voidspace> frobware: that wouldn't be too much work I guess
<frobware> voidspace: I think this is still "status" though. You can still get show-machines output using juju status --format=yaml
<voidspace> heh
<voidspace> fair enough
<frobware> voidspace: I like your suggestion ^^
<frobware> dimitern: still want to sync today?
<katco> ericsnow: morning. natefinch will be out today... your reviews will take precedent!
<dimitern> frobware, about the devices creation?
<voidspace> ericsnow: ping
<mattyw> cherylj, ping?
<cherylj> mattyw: what up?
<frobware> dimitern: yep
<dimitern> frobware, well, I'm quite deep in code changes now, and it will be better to do it tomorrow I guess
<dimitern> frobware, as I've already changed twice what I though we need :)
<frobware> dimitern: ok, I'll continue to look at the LXD side
<dimitern> frobware, sounds good
<frobware> cherylj: I looked at the master failure today, seems like containers are created OK since I landed my change, but didn't really draw any conclusions about the timeout
<cherylj> frobware: the os deployer test?
<mup> Bug #1555585 changed: Master dumps a "client.crt" and "client.key" file in CWD when copying images <lxd> <juju-core:Fix Released by jameinel> <https://launchpad.net/bugs/1555585>
<dooferlad> dimitern: http://reviews.vapour.ws/r/4002/ is ready for another review
<dimitern> dooferlad, cheers, looking
 * dooferlad goes to refresh his coffee
<voidspace> frobware: ping
<frobware> voidspace: pong
<frobware> dooferlad: looking
<mup> Bug #1555694 opened: help text for juju remove-relation needs improving <docteam> <helpdocs> <juju-core:Triaged> <https://launchpad.net/bugs/1555694>
<dimitern> dooferlad, reviewed
<frobware> cherylj: yes
<frobware> dooferlad: reviewed
<cherylj> ha, I was like "yes what?"
<dooferlad> frobware, dimitern: thanks!
<cherylj> I had completely forgotten what we were talking about
<cherylj> frobware: I don't think the os deployer tests are related to your change
<frobware> cherylj: it's been the same test (maas-1_9-OS-deployer) for a while though. but as you say, might be the same test but a different issue
<cherylj> frobware: we actually disabled that test for a while, and just recently introduced it again
<cherylj> frobware: it was using juju deployer and mgz had to do some work to get the bundle to work with the native deployer
<cherylj> frobware: so it really hasn't been run on 2.0 before
<cherylj> and was just blocked by that one multi-nic bug before
<mgz_> frobware: the test wasn't working for a while while we had the nic bug you just fixed
<voidspace> frobware: dimitern: dooferlad: is the spaces sync on?
<dooferlad> voidspace: I thought I was optional, which is why I haven't joined.
<dimitern> jamespage, thedac, sync call?
<thedac> yep :)
<frobware> oops yep, omw
<frobware> dimitern: on you 2 nic, 3 vlan setup, are they configured as dhcp or static?
<dimitern> frobware, all static
<mattyw> fwereade__, ping?
<frobware> dimitern: whoa, the boot time is a bit sucky when we bridge the world.
<dimitern> frobware, yeah
<frobware> dimitern: it's quicker to bounce the machine than wait
<dimitern> frobware, how? just restart it while it's bootstrapping?
<frobware> dimitern: yep. need to see if cloud-init allows you to do that.
<frobware> dimitern: do you see the same delay on subsequent boots?
<dimitern> frobware, I haven't tried, but will do
<frobware> dimitern: does for me
<fwereade__> mattyw, o/
<mup> Bug #1555727 opened: juju remove-ssh-key can remove Juju's own keys <docteam> <juju-core:New> <https://launchpad.net/bugs/1555727>
<mup> Bug #1555744 opened: kill-controller prevents reuse of controller name <docteam> <juju-core:New> <https://launchpad.net/bugs/1555744>
<xnox> ping
<xnox> https://github.com/juju/juju/pull/4670
<dimitern> frobware, still there?
<mup> Bug #1555585 opened: Master dumps a "client.crt" and "client.key" file in CWD when copying images <lxd> <juju-core:Fix Committed by jameinel> <https://launchpad.net/bugs/1555585>
<mup> Bug #1555801 opened: show-user does not show shared models <juju-core:New> <https://launchpad.net/bugs/1555801>
<mup> Bug #1555808 opened: Cannot deploy a dense openstack bundle with native deploy <bundles> <ci> <deployer> <maas-provider> <juju-core:Triaged> <https://launchpad.net/bugs/1555808>
<rick_h__> ty wallyworld, sorry about the emails there. Too much hard thining too late in the evening
<wallyworld> rick_h__: no problem at all. i was leaning towards option 2 myself but wasn't sure how aggressive we wanted to be in encouraging cs:series/charm to be dropped
<natefinch> katco: online for a little bit to catch up on what's going on.  Thanks for the help getting those branches landed... sorry for the terrible timing with everyone getting the plague.
<katco> natefinch: can't be helped
<katco> natefinch: if you have any time at all, could you work on landing your 3 pointer?
<rick_h__> wallyworld: yea, not a clear 100% slam winner there but think that's the 'right' way.
<wallyworld> rick_h__: it's still only a beta, we can tune if needed depending on feedback :-)
<natefinch> katco: I'll try. I have a little time now and will have more later.
<rick_h__> wallyworld: :)
<katco> ericsnow: standup time
<mup> Bug # changed: 1320312, 1534643, 1545046, 1546043, 1550306, 1552469, 1552589
<mup> Bug #1555815 opened: register allows for controller name confusion <juju-core:New> <https://launchpad.net/bugs/1555815>
<alexisb> wallyworld, when you are available ping me please
<wallyworld> sure, in meetings till after release standup :-( will try and squeeze 5 minutes
<alexisb> please do
<thumper> menn0:  http://reviews.vapour.ws/r/4123/diff/#
<TheMue> heya thumper
<thumper> o/ TheMue
<thumper> TheMue: how's tricks?
 * TheMue lurks a bit into the channel while coding his hierachical loops (like Gustavos tomb) in the hotel room
<TheMue> thumper: feeling good, working on a cloud security software in Erlang
<TheMue> thumper: but also like to stay in contact with my juju-ers
<thumper> :)
<perrito666> of course you do, we are charming people... (bad pun, sorry)
<TheMue> thumper: learned in a very bad project how good we're working at Canonical
<TheMue> perrito666: hehe
<menn0> thumper: looking
<menn0> thumper: review done. one question.
<thumper> menn0: ta
<thumper> menn0: and the other we talked about http://reviews.vapour.ws/r/4125/diff/#
<thumper> menn0: for peer relations there is only one relation endpoint
<thumper> so no double counting
<thumper> however, I really do want to do some manual comparison with a mongo dump of a big system, and an export
<thumper> just to make sure what we think is there is what is there
<menn0> thumper: yep for sure
<menn0> thumper: you've got 2 ship its
<thumper> ta
<mup> Bug # changed: 1478983, 1520623, 1536025, 1539428, 1540437, 1543388, 1543517, 1546790, 1546826, 1547268, 1547887, 1547966, 1548028, 1548076, 1548333, 1549545, 1551743, 1551842, 1552408, 1555325
#juju-dev 2016-03-11
<wallyworld> axw: when you get a chance, no rush, a small tweak to series validation. i'll then update dep in the master pr https://github.com/juju/charm/pull/198
<davecheney> thumper: https://github.com/juju/juju/pull/4688
 * thumper looks
<davecheney> i tried a few ways yesterday to merge these two handlers into one
<davecheney> but as the one from api/private/server comes with a compelte implementation of a python mocking framework
<davecheney> it was infeasable
<davecheney> this is a smaller change which does the same thing
<davecheney> and the author of the original code will have to figure out how to merge the two types
<thumper> davecheney: change looks good +1
<davecheney> thumper: ta
<thumper> hmm... third time today I've hit bad record mac trying to land things
<thumper> wallyworld: can you meet early?
<wallyworld> thumper: sure, give me a couple of minutes
<thumper> ok
<natefinch> evening all
<alexisb> evening natefinch
<katco> natefinch: kiddo feeling any better?
<natefinch> katco: not really... she's only had water & pedialyte since 6pm last night, and threw up even the water just before bed tonight.  But that's only #3 since 8am, so I'll take it over last night, for sure.
<katco> natefinch: jees :(
<natefinch> katco: my wife is slightly better off... she's managed to have, I think, two crackers, besides various liquids since around 8pm last night.   Crazy bad virus.
<alexisb> natefinch, that sounds terrible :(
<natefinch> alexisb: OMG, it was horrible.  We had to call our babysitter at 10pm to come help with the baby until about 3am when my wife was finally able to get off the bathroom floor and be in the bedroom.
<alexisb> :(
<natefinch> worst ever, and we've had some bad ones.
 * alexisb wishes she had gofmt for 'c' in her kernel days
<natefinch> tiotally... man, I remember having autoformat wars at my last job... if you didn't configure your autoformatter exactly right, every time you commit your stuff, you reformatted the code to be slightly differently.  Another guy on my team kept doing that... the aggravating thing was that he didn't notice, which made me really wonder if he even looked at what he was checking in.
<natefinch> katco: ericsnow left a comment on my charmrepo PR about this needing to get merged into the new-channels-model branch.  Should I just PR this against that branch as well?  ref: https://github.com/juju/charmrepo/pull/65
<natefinch> katco: just landed that 3 pointer in charmrepo.v2 (master)
<davecheney> thumper, menn0: https://github.com/juju/juju/pull/4691
<davecheney> followup from previous CL
<menn0> davecheney: thumper is about to drive up to Christchurch so i'll do it
<davecheney> ta
<davecheney> this is more refactoring to remove the apisever/common dependency from the resource/api
<davecheney> because apiserver imports resource/api
<davecheney> so if I want to move apiserver/common.ServerError to apiserver
<davecheney> i need to break that import loop
<davecheney> and i want to move apiserver/common.ServerErr to apiserver to pay down the technical debt from the UpgradeInProgress refactor
<cherylj> menn0: ping?
<menn0> cherylj: howdy
<cherylj> menn0: hey there, wanted to pick your brain on this mongo problem
<cherylj> so we had mario run mgopurge
<cherylj> and we told it to skip objects with an invalid token
<cherylj> but I was wondering...  do those need to get cleaned up anyhow?
<cherylj> some how?
<menn0> cherylj: yeah, i was going to reply to that email thread today but have been flat out
<cherylj> we're panicking in the same sort of way now in jujud - the token is invalid
<menn0> cherylj: are the bad txn tokens in the txn-queue field?
<menn0> cherylj: if so, yes they'll need to be removed. I kind thought that's what we were getting mgopurge to do but I could be misremembering
<cherylj> menn0: that's what I'm wondering / thinking.  I haven't downloaded the db yet to look
<menn0> cherylj: seems likely if that's the case
<menn0> cherylj: mgo/txn will be trying to look up those txns, failing to find them and panicking
<cherylj> menn0: but what I added in to prevent mgopurge from panicking was just to skip those transactions
<menn0> cherylj: I was going to say on the email that they should get the replicaset healthy *before* trying to fix anything else
<cherylj> maybe there's something else I need to add which removes them from the queue
<cherylj> menn0: it sounds like they've done that
<menn0> cherylj: he said that 2 out of the 3 nodes are ok
<menn0> cherylj: that's not healthy
<menn0> cherylj: they should get that 3rd node happy again first
<cherylj> menn0: ah, gotcha
<cherylj> menn0: I can ask Mario to do that
<menn0> cherylj: and it sounds like making mgopurge remove the bad txn tokens needs to happen too
<menn0> cherylj: a bad/empty token should just be treated the same as a missing txn
<cherylj> menn0: yeah, that's what I was thinking.  I'll take a closer look at the PurgeMissing code
<menn0> cherylj: the same logic that removes missing txns from the txn-queue field can then be used to remove the bad ones too
<cherylj> bleh this mgo stuff is hard to read
<katco> natefinch: i'd say just master and they an bug us if the merge conflicts are too bad
<axw> wallyworld: charm change LGTM
<wallyworld> tyvm
<axw> wallyworld: adding cloud name, etc. to controllers.yaml doesn't really work :/   if you did "juju register", we've got nowhere to pull that information from
<axw> wallyworld: so I think it goes back into bootstrap-config.yaml, and we cross-reference that in list-controllers
<wallyworld> axw: ok, let's go with that; we can be clear about the limitations. the only other option i guess it to make an api call
<rick_h__> axw: is this for the provider type info?
<axw> wallyworld: IMO that's out of the question
<wallyworld> yeah, agreed, was just making sure we covered all options
<axw> rick_h__: sorta. it's for that, plus the bits we need to kill-controller if the controller is dead
<axw> rick_h__: we could store the provider type easily, but the other information not so much
<rick_h__> axw: ah ok, for the provider type user query I'd hope we could put that in the show-controller metadata
<rick_h__> axw: gotcha
<rick_h__> axw: yea, /me didn't catch the rest of the convo for the kill-controller link
<axw> rick_h__: two birds, one stone :)
<rick_h__> axw: yea, but let's make sure they're both birds and not one moose and one bird
<axw> ;)
<rick_h__> no thumper? curses
<menn0> rick_h__: thumper is driving up to christchurch (where I live). he's taking his kids to a convention up here.
<menn0> rick_h__: can I help at all?
<axw> wallyworld: just thinking out loud... we could forget about storing the credential label/origin, and just auto-detect and use whatever it returns, like at bootstrap
<axw> wallyworld: and if none auto-detected, say something like "no credentials detected". I guess the origin is still useful though...
<axw> wallyworld: (just trying to minimise surface for such a corner case)
<wallyworld> axw: sorry, was out with anastasia talking lxd image caching. yeah, we went around and around on minimising the serface for the corner case didn't we. but the idea of storing the label/origin is so that if we autodetected the wrong credentials, we could prompt for the correct ones
<wallyworld> but is the effort worth it
<axw> wallyworld: yeah, I suppose so. I'll add it later, doing the minimal work for now to support lxd
<wallyworld> sgtm. i don't think it's that much extra to store the label/origin, let's take a view once things have settled a bit
<TheMue> morning o/
<mup> Bug #1555969 opened: API server stops responding after juju add-unit <juju-core:Triaged> <https://launchpad.net/bugs/1555969>
<axw> wallyworld: if you're around later and feel like looking, here's the WIP: https://github.com/juju/juju/compare/admin-controller-model...axw:bootstrapconfig-partial-ondemand
<axw> wallyworld: all working, lots of tests to update now.
<frobware> voidspace: did this (http://reviews.vapour.ws/r/3955/) get back into master?
<voidspace> frobware: well, the code it was changing wasn't on master I don't think
<voidspace> frobware: I can have a look
<voidspace> frobware: the subnetToSpaceIds function it changes doesn't exist on current master
<dimitern> frobware, hey, I've realized I gave you bad advice yesterday wrt dependencies.tsv :/
<frobware> dimitern: so let's fix it before we merge to master
<dimitern> frobware, those imports which were removed with the master merge caused issues on windows
<frobware> dimitern: I was looking at the report
<dimitern> frobware, yeah, I suppose just adding back the missing ones will fix 3 of the curses
<frobware> dimitern: can I just merge in what I had done?
<frobware> originally
<menn0> fwereade__: i'm aiming to review your model agent integration PR soon
<dimitern> frobware, I'd try to use GOOS=windows godeps -N ... as suggested in the linked bug report
<frobware> voidspace: if we're going to get maas-spaces2 into master next week we can wait till then
<frobware> voidspace: I was just curious if you ported that single fix into master. I guess not because it was only broken on maas-spaces2
<voidspace> frobware: right, it *couldn't* be ported to master...
<dimitern> dooferlad, hey, I see getMongoSpace changes caused a data race in the last CI run
<dooferlad> dimitern: really? Grr.
<dimitern> dooferlad, can you have a look at that? http://reports.vapour.ws/releases/3735/job/run-unit-tests-race/attempt/1095#highlight
<dooferlad> dimitern: on it
<dimitern> dooferlad, cheers
<fwereade__> menn0, <3
<fwereade__> menn0, I recommend ignoring everything under worker/dependendency; core/life; and all the */lifeflag bits
<fwereade__> menn0, because I can and will extract those
<menn0> fwereade__: ok will do
<dimitern> frobware, in my experiments yesterday I found this quick hack significantly reduces the initial boot time: http://paste.ubuntu.com/15346394/
<dimitern> frobware, ~2m (average) from allocated to deployed
<frobware> dimitern: the bridge wait I understand, the ntp is a step too far...
<dimitern> frobware, that's because of the race I was telling you about when trying to ifup a lot of static interfaces
<dimitern> frobware, I was seeing 4-5 bash instances trying to run ntpdata and getting blocked on trying to create a lockfile
<frobware> dimitern: I'm going to try an experiment with a one-time reboot post our butchering of eni
<frobware> dimitern: but somewhat secondary to getting the devices work done
<dimitern> frobware, I tried that as well - depending on when you reboot, it might not work at all - e.g. before installing bridge-utils
<dimitern> frobware, agreed
<frobware> dimitern: the bridge-utils is a pre-req so is already present before we run the script
<dimitern> frobware, yeah, that's assuming we got the chance to even run apt-get install bridge-utils
<dimitern> frobware, which will happen after the bridge script completes
<frobware> dimitern: it happens the other way round.
<frobware> dimitern: our script would fail catastrophically if it wasn't present
<frobware> dimitern: you can see this if you deploy from MAAS, cp the script, and run it. the whole thing fails because there is no brctl
<dimitern> frobware, that's what I'm talking about :)
<dimitern> frobware, since the script runs as a bootcmd, it will run before any packages listed in the generated userdata are installed..
<frobware> dimitern: I was confused. you said "after the bridge script completes"
<dimitern> frobware, hmm.. I might be wrong - just observed something like that
<frobware> dimitern: there is no way we could bring the interface up without bridge-utils being there
<frobware> dimitern, voidspace, dooferlad: standup/planning
<voidspace> frobware: omw
<menn0> fwereade__: review done. lots of great stuff. thank you. it will be great to get this landed.
<dimitern> frobware, this is the gist of what's needed: http://paste.ubuntu.com/15346665/, and those API calls follow the pattern in http://paste.ubuntu.com/15241590/
 * menn0 bed
<dimitern> frobware, so if we agree on the interface, I can use a stub for now, and later we integrate
<dimitern> frobware, let me know what you think
<frobware> dimitern: will look in a bit
<frobware> dimitern: I don't see a great deal of diff with your godeps incantation; https://pastebin.canonical.com/151643/
<dimitern> frobware, that's exactly the missing import causing the curse
<frobware> dimitern: :) yes, just read the bug.
<dimitern> frobware, well, now we know what this package is for :)
<frobware> dimitern: so another alternative is that we merge from master again this morning
<frobware> dimitern: we would get that ^^ for free
<dimitern> frobware, also works, and will give us updated lxd stuff as a benefit
<frobware> dimitern: right, I'll do that instead.
<dimitern> frobware, however, that should be followed up by dooferlad's fix not long after the merge lands in order not to waste a CI run
<frobware> dimitern: good point
<frobware> dimitern: can we HO re: the godeps stuff again. as in what's the best way to merge and or update it
<dimitern> frobware, ok
<dimitern> frobware, I'm in the sapphire HO (last one we used)
<dooferlad> dimitern / frobware / voidspace: http://reviews.vapour.ws/r/4132/ fixes those races.
<dimitern> dooferlad, looking
<dimitern> dooferlad, did you run the test with -race?
<dooferlad> yes
<dimitern> dooferlad, so the issue is easy to reproduce and verify the fix
<dimitern> dooferlad, LGTM, thanks that was quick :)
<dooferlad> dimitern: yea, just running the tests with -race showed it and then it was just a moment of "oh crumbs, that was dumb"
<dimitern> :)
<frobware> dooferlad: we should try and land the changes close together; just running make check on my merge from master and will propose
<dooferlad> frobware: I hit $$merge$$ about two seconds before you said that.
<frobware> c'est la view
<frobware> vie...
<dooferlad> frobware: it will take some time to test, so as long as we get to reviewing your code soon we will be fine.
<frobware> dimitern, voidspace, dooferlad: http://reviews.vapour.ws/r/4133/ -- merge master into maas-spaces2
<voidspace> frobware: did you land one yesterday?
<frobware> voidspace: yes
<voidspace> frobware: ah yes, this one isn't as huge
<voidspace> frobware: go for it
<frobware> voidspace: that commit was also a blessed build.
<frobware> voidspace: if there's one thing to look at its dependencies.txt
<frobware> voidspace: I meant dependencies.tsv
<voidspace> frobware: yeah, I looked - LGTM
<voidspace> frobware: although we seem to be depending on stuff in people's own github repositories now
<dimitern> frobware, looks good
<dimitern> dooferlad, your fix should merge cleanly onto frobware's merge PR right?
<frobware> dimitern: going to grab some lunch and then let's do devices... \o/
<dimitern> frobware, sweet!
<frobware> dimitern, voidspace, dooferlad: both merged. we should, in theory, get a blessed CI run now.
<dimitern> frobware, let's hope we do :)
<rogpeppe2> natefinch: ping
<frobware> dimitern: whenever works for you let's sync
<dimitern> frobware, in 15m ?
<frobware> yep
<dimitern> frobware, let's use the standup HO?
<dimitern> frobware, well, last one we used anyway
<frobware> ok
<natefinch> rogpeppe: pong
<mattyw> fwereade__, ping?
<mup> Bug #1556113 opened: TestCleaner should have fired by now <ci> <go1.5> <go1.6> <intermittent-failure> <juju-core:Triaged> <https://launchpad.net/bugs/1556113>
<mup> Bug #1556116 opened: TestDeployBundleMachinesUnitsPlacement mismatch <ci> <gccgo> <ppc64el> <regression> <test-failure> <unit-tests> <juju-core:Incomplete> <juju-core maas-spaces2:Triaged> <https://launchpad.net/bugs/1556116>
<fwereade__> mattyw, heyhey
<mup> Bug #1556137 opened: Juju 2.0: cannot connect to LXC container when deploying bundle with LXC container placement <oil> <juju-core:New> <https://launchpad.net/bugs/1556137>
<natefinch> ericsnow: let me know if you need help with that cards you took over from me
<mup> Bug #1556137 changed: Juju 2.0: cannot connect to LXC container when deploying bundle with LXC container placement <oil> <juju-core:New> <https://launchpad.net/bugs/1556137>
<mup> Bug #1556137 opened: Juju 2.0: cannot connect to LXC container when deploying bundle with LXC container placement <oil> <juju-core:New> <https://launchpad.net/bugs/1556137>
<mattyw> ericsnow, ping?
<mattyw> ericsnow, do you know if the todo comment at the top of this file is currently being worked on? https://github.com/juju/juju/blob/master/cmd/juju/charmcmd/store.go
 * ericsnow takes a look
<ericsnow> mattyw: not really
<mattyw> ericsnow, ok that's fine, I might have to end up doing some of it for the stuff I'm working on, wanted to make sure I wasn't going to be duplicating work
<ericsnow> mattyw: I have a patch that accomplishes that but haven't had a chance to pursue landing it
<mattyw> ericsnow, i'd be interested in seeing that if possible
<ericsnow> mattyw: k, thanks for the heads up
<ericsnow> mattyw: looking it up as we speak
<mattyw> ericsnow, many thanks
<ericsnow> mattyw: pretty sure this is the branch: https://github.com/ericsnowcurrently/juju/tree/resources-charmstore-client
<ericsnow> mattyw: it isn't quite right at this point, but the key thing is the httpcontext package
<ericsnow> mattyw: however, it looks like the new "charm" command would use it too, so it may make more sense in some other common repo
<ericsnow> natefinch: #1556146
<mup> Bug #1556146: github.com/juju/juju/resource/api undefined: parseMediaType <ci> <go1.6> <regression> <xenial> <juju-core:Incomplete> <juju-core feature-resources:Triaged> <https://launchpad.net/bugs/1556146>
<ericsnow> natefinch: bug #1556146
<mup> Bug #1497801 changed: provider/joyent: data races <race-condition> <juju-core:Triaged> <https://launchpad.net/bugs/1497801>
<mup> Bug #1461961 opened: UniterSuite teardown fails <ci> <intermittent-failure> <test-failure> <juju-core:Triaged> <https://launchpad.net/bugs/1461961>
<mup> Bug #1556146 opened: github.com/juju/juju/resource/api undefined: parseMediaType <ci> <go1.6> <regression> <xenial> <juju-core:Incomplete> <juju-core feature-resources:Triaged> <https://launchpad.net/bugs/1556146>
<katco> ericsnow: natefinch: planning time
<mattyw> ericsnow, thanks, I'll take a look
<mup> Bug #1556152 opened: data race peergrouper.(*pgWorker).getMongoSpace() <race-condition> <juju-core:Triaged> <https://launchpad.net/bugs/1556152>
<mup> Bug #1556155 opened: worker/periodicworker data race <race-condition> <juju-core:Triaged> <https://launchpad.net/bugs/1556155>
<mup> Bug #1556152 changed: data race peergrouper.(*pgWorker).getMongoSpace() <race-condition> <juju-core:Triaged> <https://launchpad.net/bugs/1556152>
<mup> Bug #1556155 changed: worker/periodicworker data race <race-condition> <juju-core:Triaged> <https://launchpad.net/bugs/1556155>
<mup> Bug #1556152 opened: data race peergrouper.(*pgWorker).getMongoSpace() <race-condition> <juju-core:Triaged> <https://launchpad.net/bugs/1556152>
<mup> Bug #1556155 opened: worker/periodicworker data race <race-condition> <juju-core:Triaged> <https://launchpad.net/bugs/1556155>
<natefinch> ericsnow: review a single character bug fix? http://reviews.vapour.ws/r/4135/diff/#
<mup> Bug #1556152 changed: data race peergrouper.(*pgWorker).getMongoSpace() <race-condition> <juju-core:Invalid> <juju-core maas-spaces2:Fix Committed by dooferlad> <https://launchpad.net/bugs/1556152>
<mup> Bug # opened: 1556153, 1556157, 1556161, 1556167, 1556171
<HollyRain> does the Juju license is going to change? the issue is that at using a library like "juju/service", it does that all my code been AGPL
<natefinch> HollyRain: very doubtful that the license will change
<HollyRain> natefinch, well, at least there is an alternative to handle services: kardianos/service
<HollyRain> in github.com
<natefinch> HollyRain: if you mean github.com/juju/juju/service - anything under github.com/juju/juju is not really intended to be used as a general library
<HollyRain> ok
<mup> Bug #1556176 opened: TestCmdLine dial unix no such file or directory <ci> <go1.5> <intermittent-failure> <unit-tests> <juju-core:Triaged> <https://launchpad.net/bugs/1556176>
<mup> Bug #1556180 opened: MachineSuite.TestManageModelRunsRegisteredWorkers mismatch <go1.5> <go1.6> <intermittent-failure> <unit-tests> <juju-core:Triaged> <https://launchpad.net/bugs/1556180>
<mup> Bug #1556183 opened: help text for list-controllers needs improving <helpdocs> <juju-core:New> <https://launchpad.net/bugs/1556183>
<frobware> cherylj: ping
<cherylj> frobware: in stand up, responses will be slow :)
<frobware> voidspace: you still about?
<voidspace> frobware: yup
<frobware> voidspace: any joy with MAAS 2.0? I didn't get around to installing...
<voidspace> frobware: not yet, recloning my vm and installing xenial - about to install a newer version of maas (different ppa) that may fix the bug
<voidspace> frobware: did some diagnostic work with roaksoax and he thinks it might be fixed in this version
<mup> Bug #1556207 opened: 1.25.4: "tomb: dying" in all units <kanban-cross-team> <landscape> <juju-core:New> <https://launchpad.net/bugs/1556207>
<mup> Bug #1556207 changed: 1.25.4: "tomb: dying" in all units <kanban-cross-team> <landscape> <juju-core:New> <https://launchpad.net/bugs/1556207>
<frobware> cherylj: we've made sure that maas-spaces2 is up to date w.r.t to master. if we get a clean CI build on maas-spaces2 we'd like to merge into master and continue the multi-NIC and MAAS 2.0 work elsewhere. Is master still locked down?
<cherylj> frobware: yes, we want to merge perrito666's machine-provisioning-status before we unblock
<cherylj> frobware: if your branch is ready, we can put it on the list to get shepherded in next
<frobware> cherylj: waiting to see if the couple of fixes we did today give us a blessed CI run; should find out a bit later.
<cherylj> frobware: okay, cool.  I'll keep an eye on it
<mup> Bug #1556207 opened: 1.25.4: "tomb: dying" in all units <kanban-cross-team> <landscape> <juju-core:New> <https://launchpad.net/bugs/1556207>
<katco> sinzui: hey, is this a spurious curse? http://reports.vapour.ws/releases#nate-minver
<sinzui> katco: maybe. The lack of bless might be because the branch makes juju less reliable. The azure arm-bundle looks interesting. I can retest it
<natefinch> spurious curse is the name of my goth metal band
<katco> sinzui: thanks, i would appreciate it. i don't think there should be anything in there that would cause it to be less reliable
<katco> sinzui: but appreciate your more informed opinion
<mup> Bug #1556238 opened: Missing a Juju shell <juju-core:New> <https://launchpad.net/bugs/1556238>
<mup> Bug #1556249 opened: help text for juju list-models needs improving <helpdocs> <juju-core:New> <https://launchpad.net/bugs/1556249>
<mup> Bug #1556252 opened: help text for juju show-user needs improving <helpdocs> <juju-core:New> <https://launchpad.net/bugs/1556252>
<marcoceppi> sinzui: is juju2 the name of the binary going forward?
<marcoceppi> I noticed juju-core and juju are no longer listed and installing juju2 removes them
<natefinch> marcoceppi: it's a vast underworld conspiracy
<marcoceppi> well, it breaks the new charm and charm-tools command
<marcoceppi> so I'd just like to align those packages
<marcoceppi> it also means we can't install 1.25 and 2.0 sidebyside which completely kills this blog post from last week
<marcoceppi> http://marcoceppi.com/2016/03/testing-juju-without-wrecking-juju/
<marcoceppi> oh, jk, it doesn't break juju-core, just juju-core2
<natefinch> marcoceppi: I'm 99% sure that we are supposed to be able to run them side by side.  WE've done a lot of work to enable that.
<marcoceppi> I'm actually okay with that
<marcoceppi> I'll jus tneed to update the packaging for charm and charm-tools
<natefinch> marcoceppi: I think it's juju-core and juju (the latter being juju 2)
<natefinch> marcoceppi: but I am certainly not the authority on these things
<marcoceppi> natefinch: I upgraded and both versions are still there, I jus tneed to update the other packaging
<natefinch> rick_h__, katco: charm publish --channel=stable cs:rabbit-22 --resources "foo-6 bar-3" ... this command seems to require that resource names not have spaces in them, in order to parse them in a single string like that.  Do we want to start to enforce that, or should we change this to be --resource foo-3 --resource bar-6?  or some third way?
<katco> natefinch: yes, separate flags to mirror deploy
<katco> natefinch: check out rick_h__ 's comment in the 1-pager
<natefinch> katco: awesome.  I love consistency
<katco> +1
<marcoceppi> omg I just bootstrapped lxd \o/
<natefinch> marcoceppi: huzzah
<natefinch> katco: I kinda wish that for publish, it was --resource foo=3 --resource foo=5 ... but I understand that we're trying to make them like charm revisions, where it's part of the name
<natefinch> s/foo=5/bar=5
<katco> natefinch: yeah, i prefer = as well
<katco> natefinch: but, precedent and all
<katco> natefinch: ericsnow_afk: we don't need to do a standup
<ericsnow> katco: k
<sinzui> marco yes, juju2 is the package name. juju2 is also the name of binary.
<sinzui> marcoceppi: if you havw juju-core and juju2 installed, you can use alternates to switch which Juju is /usr/bin/juju
<marcoceppi> sinzui: right, it's just that juju2 removes some packages, including charm and charm-tools
<sinzui> marcoceppi: it does? how?
<natefinch> marcoceppi: hmm, that seems wrong.  It definitely shouldn't *remove* anything
<sinzui> marcoceppi: a package cannot remove another package and it is intended to be co-installable.
<perrito666> sinzui: cant a deb remove another if it is marked as conflicts or replaces?
<marcoceppi> perrito666: yes
<sinzui> perrito666: yes, replaces, but we don't use that. conflicts blocks and lets a user choose
<marcoceppi> sinzui: juju2 removed juju which are depends on charm and charm-tools
<perrito666> sinzui: I would re-check the package definition given what marcoceppi says
<sinzui> marcoceppi: oh, I can remove that metapackage. we don't need it
<marcoceppi> sinzui: which metapackage?
<sinzui> juju is a metapackage marcoceppi. It hasn't been a real package in 4 years
<natefinch> marcoceppi: welcome.... to the real world
<perrito666> oh that is right, juju is to pull juju-core and juju-local right?
<marcoceppi> sinzui: I know. but charm-tools, amulet, etc, depend on Juju
<sinzui> right, and juju2 is really just juju2 now. no other deps
<sinzui> marcoceppi: I think we need to drop the juju metapackage from the juju2 package. two source packages cannot provide it an be co-installable
<natefinch> marcoceppi: what do charm-tools and amulet etc need from the juju package that isn't in core?
<sinzui> marcoceppi: juju2 source package coul provide juju2-all or juju2-dev to get the authoring tools
 * sinzui likes juju2-authors more than juju2-dev
<marcoceppi> we just need juju installed whenever a user installs these tools
<sinzui> marcoceppi: which juju needs to be install when someone installs those tools? if so, then shouldn't those package depend on juju-core or juju2?
<marcoceppi> well either juju is fine
<marcoceppi> just a juju
<natefinch> marcoceppi: why do those tools need juju?
<marcoceppi> hence the metapackage
<marcoceppi> well, it's not a depends
<marcoceppi> it's a Recommends
<marcoceppi> the idea being that multiple things can provide a juju, so I'm just going to have it Recommend: juju2 || juju
<sinzui> marcoceppi: the juju-core package we put in the ppa:juju/stable doesn't have a recommends or depends on amulet charm-tools. maybe the Ubuntu version of the package does
<marcoceppi> sinzui:
<marcoceppi> no amulet and charm-tools and charm recommends juju
<marcoceppi> that way if you install them, you
<marcoceppi> 'll get juju
<marcoceppi> well, amulet depends on juju, the rest recommend it
<sinzui> marcoceppi: okay, so amulet could "Depends: juju2 | juju-local"
<marcoceppi> why juju-local? you mean juju-core?
<sinzui> marcoceppi: yes, juju-core is fine for 1.x. I just assumed that a charm author would want local-provider
<natefinch> OMG, so glad we dumped local provider for 2.0
<sinzui> marcoceppi: I can add a metapackage to the new juju2 source package to install everything you think a charm-author needs.
<sinzui> natefinch: \o/
<sinzui> We can take half a day and close 200 bugs
<sinzui> marcoceppi: also, we don't need to wait for the next release to remake the juju2 package to provide a metapackage for authors
<ericsnow> natefinch: http://reviews.vapour.ws/r/4138/
<marcoceppi> sinzui: well, I think juju2 should recommend the charm command
<marcoceppi> sinzui: and charm depends on charm-tools
<marcoceppi> and that'll all work
<sinzui> marcoceppi: as in the charm package I see sitting in ppa:juju/devel... "Recommends: charm"
<natefinch> what's the user-experience for "recommended" packages?
<sinzui> natefinch: it will be installed, if it exists
<natefinch> sinzui: so we're forcing every user of juju to install charm authorship tools?
<sinzui> natefinch: the user can specify not to install recommends
<sinzui> natefinch: I most often use recommends for cases where we know older ubuntu series don't have the optional package
<natefinch> sinzui: I don't really see why juju would ever recommend charm authorship tools.  charm authors, in theory, should be like .1% or less of juju users
<sinzui> natefinch: yeah, that is why I suggested a metapackage names charm-authors to be clear who wants the extra packages
<natefinch> sinzui: agreed
<natefinch> ericsnow: looking
<natefinch> ericsnow: btw, thanks for tackling that..sorry you got burdened with the result of my misunderstanding.
<ericsnow> natefinch: glad to do it
<ericsnow> natefinch: it's all complicated by our usual high-coupling/low-encapsulation
<natefinch> ericsnow: seems like we could use an AuthorizedCharm struct or something, that holds a CharmURL + macaroom
<ericsnow> natefinch: I was totally thinking that the whole time :/
<natefinch> ericsnow: or even slap a macaroom on the charm.URL struct
<ericsnow> natefinch: yep
<natefinch> blah
<sinzui> perrito666: machine-provisioning-staus branch is merge
<perrito666> sinzui: oh, you just made my weekend
<natefinch> ericsnow: only had time for a half a review, sorry.  I'll finish up the rest later tonight.
<natefinch> ericsnow: mostly looks good, just didn't get through it all.
<ericsnow> natefinch: np
<ericsnow> natefinch: thanks
<mup> Bug #1556293 opened: Invalid volume ID <ci> <destroy-environment> <test-failure> <juju-core:New> <https://launchpad.net/bugs/1556293>
<alexisb> anyone know how I make this go away:
<alexisb> checking: go vet ...
<alexisb> tools/lxdclient/client_instance.go:329: wrong number of args for format in Tracef call: 1 needed but 2 args
<alexisb> I can build and run locally on my machine
<katco> alexisb: what version of go are you compiling with locally?
<alexisb> 1.6rc2
<katco> alexisb: and CI is giving you this error?
<perrito666> katco: I had the same
<perrito666> alexisb: its a vet issue introduced by jam
<alexisb> so I can build locally but the "go vet" check in the prepush script is failing
<alexisb> perrito666, ah ok
<alexisb> I will follow-up with him
<perrito666> alexisb: just go to that line and delete the second argument to the Tracef
<katco> alexisb: ah... yeah vet is separate than building, but it's probably because CI is using a different version of go than you
<perrito666> katco: is CI running vet?
<katco> alexisb: they change how vet works between versions sometimes
<katco> perrito666: it should be
<katco> perrito666: that should be blocking imo
<katco> perrito666: and i thought it was
<perrito666> katco: me too
<perrito666> but apparently it isnt
<katco> perrito666: i think it is, and CI is just using an older version of go
<katco> perrito666: thus, the change jam made is fine
<perrito666> katco: I thought go vet was catching that before
<perrito666> odd
<perrito666> in any case, it breaks with go 1.5
<katco> perrito666: ci is building with 1.2.1 still
<katco> alexisb: perrito666: lots o' things have changed between 1.2.1 and 1.5, let alone 1.6r2
<alexisb> katco, not for 2.0
<perrito666> that explains
<alexisb> for trusty we build with 1.2.1, until 1.6 is officially in updates
<alexisb> that did it perrito666
<katco> alexisb: i think our CI workers are still using 1.2.1. sinzui can you comment?
<katco> alexisb: i.e. the workers that $$merge$$ changes
<sinzui> katco: oh, the merge job is using a trusty ami, so it is using go 1.2.1
<perrito666> sinzui: mm, that is wrong for 2.0
<katco> alexisb: ^^^ hence, go vet change made it in, but is incompatible with go1.6-r2
<sinzui> katco: The release agreed to switch to ggo 1.6 nexgt week
<sinzui> and that that time, we expect master to be blocked as we fix bugs
<sinzui> katco: the merge job nor Juju's one Makefile does not specific how to install a version of go on a temporary instance in AWS. It gets the version from the Ubuntu release. so switching to xenial images will select golang (2:1.6-0ubuntu3)
<katco> sinzui: understood, and that sounds correct. just trying to inform alexisb
<katco> sinzui: by the by, how goes the retest of nate-minver?
<sinzui> katco: it failed? but I am looking to it still as a substrate issue the same bundle passed on other substrates
<katco> sinzui: oh, i thought you were going to retest with a higher timeout? does this mean we can merge into master?
<sinzui> katco: I did  and we still timeout
<katco> sinzui: ah ok. what do i need to do to get it landed into master? just wait for you guys to work your magic?
<sinzui> katco: If am hoping to retest and provide good results, or find some reason why the banch fails
<katco> sinzui: ok, when will you know more?
<sinzui> maybe by morning. katco.
<katco> ok ta sinzui
<alexisb> sinzui, thanks for pushing hard to get releases out this week, have a great weekend!
<sinzui> thank you alexis. you too
<mup> Bug #1551276 changed: 2.0-beta2 stabilization <juju-core:Invalid> <https://launchpad.net/bugs/1551276>
#juju-dev 2016-03-12
<mup> Bug #1556349 opened: Juju 2.0: Plenty of duplicates after re-deploying  (juju deploy) a bundle following an error <oil> <juju-core:New> <https://launchpad.net/bugs/1556349>
<fwereade__> just proposed RB4141 and 4142, extracting the cleanly-separable bits from the monster that is 4110; if anyone's bored over the weekend, take a look :)
<mup> Bug #1556442 opened: juju quickstart looks for network-bridge: "lxcbr0" in local environment <bootstrap> <quickstart> <juju-core:New> <https://launchpad.net/bugs/1556442>
<mup> Bug #1556442 changed: juju quickstart looks for network-bridge: "lxcbr0" in local environment <bootstrap> <quickstart> <juju-core:New> <https://launchpad.net/bugs/1556442>
<mup> Bug #1556442 opened: juju quickstart looks for network-bridge: "lxcbr0" in local environment <bootstrap> <quickstart> <juju-core:New> <https://launchpad.net/bugs/1556442>
<ahasenack> hi guys, just installed juju2 beta2
<ahasenack> juju2 bootstrap  lxd lxd
<ahasenack> ERROR invalid config: no addresses match
<ahasenack> is that supposed to work, out of the box, no further config?
<ahasenack> hm, I think my image name needs to change in lxd
<ahasenack> hm, no
<mup> Bug #1556483 opened: ERROR invalid config: no addresses match <juju-core:New> <https://launchpad.net/bugs/1556483>
#juju-dev 2016-03-13
<mup> Bug #1556514 opened: Juju bootstrap does not assign and use floating IP on openstack <floating> <ip> <juju-core> <network> <openstack> <juju-core:New> <https://launchpad.net/bugs/1556514>
<mup> Bug #1556514 changed: Juju bootstrap does not assign and use floating IP on openstack <floating> <ip> <juju-core> <network> <openstack> <juju-core:New> <https://launchpad.net/bugs/1556514>
<mup> Bug #1556514 opened: Juju bootstrap does not assign and use floating IP on openstack <floating> <ip> <juju-core> <network> <openstack> <juju-core:New> <https://launchpad.net/bugs/1556514>
<mup> Bug #1532841 changed: cannot add charm to storage <charm> <ci> <juju-core:Expired> <juju-core structured-metadata:Invalid> <https://launchpad.net/bugs/1532841>
<mup> Bug #1532841 opened: cannot add charm to storage <charm> <ci> <juju-core:Expired> <juju-core structured-metadata:Invalid> <https://launchpad.net/bugs/1532841>
<mup> Bug #1532841 changed: cannot add charm to storage <charm> <ci> <juju-core:Expired> <juju-core structured-metadata:Invalid> <https://launchpad.net/bugs/1532841>
<mup> Bug #1556630 opened: Timeout github.com/juju/juju/cmd/jujud/reboot <ci> <go1.5> <regression> <test-failure> <wily> <juju-core:Triaged> <https://launchpad.net/bugs/1556630>
<mup> Bug #1555291 changed: TestStartInstancePopulatesNetworkInfoWithoutAddressAllocation fails on centos <centos> <ci> <regression> <test-failure> <juju-core:Fix Released by sinzui> <https://launchpad.net/bugs/1555291>
<davecheney> thumper: https://github.com/juju/juju/pull/4706
<davecheney> two things
<davecheney> 1, do you have lxc installed ?
<davecheney> i don't and the tests always pass reliably
<davecheney> but the test was ignoring basically all the error handling
<davecheney> so I added it back in
<davecheney> at least the test won't hang now
<thumper> yes I have lxc installed
<davecheney> thumper: PTAL https://github.com/juju/juju/pull/4706
<davecheney> it reduced the test run time from 10s of seconds to milliseconds
<davecheney> i cannot get it to fail on my machine
<davecheney> ask you have the failing sample, can ypu try please
<thumper> I'll try
<thumper> tests pass here now
<thumper> davecheney: but I'm not sure why
<thumper> how does your branch fix it?
<davecheney> thumper: i don't believe that this change will make the test pass where they previously failed
<davecheney> but previously the test didn't fail, it hung
<davecheney> with this change
<davecheney> you'll get an immediate error
<davecheney> which is better than the test hanging
<davecheney> then the test runner being killed and we get zero output
<thumper> right
<thumper> why did they hang?
<thumper> it isn't clear to me
<davecheney> no idea
<davecheney> i cannot reproduce the problem on my machine
<davecheney> and when we do it in CI
<davecheney> the test runner kills the job before we get any output
<thumper> well, even with your stress.sh it passes every time ow
<thumper> now
<davecheney> thumper: if you can make it hang on your machine without that CL
<davecheney> can you run the test with debug turned up to 11 pls
 * thumper tries
<thumper> hmm...
<thumper> without your changes...
<thumper> it hangs first time
<davecheney> what output do yo get
<davecheney> are any of those log lines firing ?
 * thumper looks
 * thumper added -check.vv
<thumper> [LOG] 0:15.878 WARNING juju.cmd.jujud.reboot Waiting for containers to shutdown: [lxd:juju-c0518c0b-97b5-47ab-8c1b-541906fb2c73-machine-0]
<thumper> juju-c0518c0b-97b5-47ab-8c1b-541906fb2c73-machine-0 | STOPPED |      |      | PERSISTENT | 0         |
<davecheney> hmm, lxc-ls is being *ahem* patched
<davecheney> you should not see that
<thumper> this is lxd
<thumper> not lxc
<thumper> lxc list
<davecheney> we'd that would explain it
<davecheney> welp
<thumper> why did it pass with your patch then?
 * thumper is confused
<davecheney> i don't know
<davecheney> i cannot get it to fail on my machine
<thumper> got any lxd containes?
<davecheney> i have to do this surgery via remote
<davecheney> nope, don't have lxd installed
<thumper> ah...
<thumper> that'll be why it is fine on your machine
<thumper> because lxd isn't initialized
<davecheney> that's some great test isolation we have
<thumper> fricken amazing
 * thumper heads to lunch
<davecheney> cherylj: I don't have permission to close this bug https://github.com/juju/juju/issues/4705#issuecomment-195956659
<davecheney> may I please have that permission
#juju-dev 2017-03-06
<mup> Bug #1670430 opened: /etc/mysql/my.cnf has incorrect ownership <juju-core:New> <https://launchpad.net/bugs/1670430>
<mup> Bug #1670431 opened: myisam-recover invalid parameter in /etc/mysql/my.cnf file <juju-core:New> <https://launchpad.net/bugs/1670431>
<mup> Bug #1670431 changed: myisam-recover invalid parameter in /etc/mysql/my.cnf file <juju-core:New> <https://launchpad.net/bugs/1670431>
<mup> Bug #1670431 opened: myisam-recover invalid parameter in /etc/mysql/my.cnf file <juju-core:New> <https://launchpad.net/bugs/1670431>
<babbageclunk> hml: hi!
<hml> babbageclunk: hi!
<rogpeppe> anyone wanna give a nod to this totally trivial (but large) PR ? https://github.com/juju/juju/pull/7069
<thumper> done
<thumper> and thanks
<rogpeppe> thumper: ta!
<rogpeppe> thumper: if you have time for reviews, you might want to take a look at https://github.com/juju/worker/pull/2 which is planned to be a replacement for the custom logic implemented by state/workers
<rogpeppe> thumper: (i have a branch-in-waiting that does that)
<thumper> rogpeppe: I took a quick look yesterday, but felt it needed much more detailed review
<rogpeppe> thumper: BTW, sad not to see you here
<thumper> rogpeppe: I was thinking it might be better to pair with someone at the sprint
<thumper> rogpeppe: yeah, I miss catching up, but had things booked here already
<rogpeppe> thumper: yeah, i've chatted with menn0 about it and he approves in principle, but it might be good to pair up a bit
<thumper> rogpeppe: and my daughter when she found out I was around booked me in for school camp dad (wed-fri)
<rogpeppe> This PR changes juju to use the external worker package. Reviews appreciated, thanks: https://github.com/juju/juju/pull/7070
#juju-dev 2017-03-07
<seyeongkim> juju can support cloud-config like this? https://bugs.launchpad.net/juju/+bug/1599886/comments/9 or it is already supporting? or plan?
<mup> Bug #1599886: apt-mirror does not override security.ubuntu.com for containers on trusty <cpec> <juju:Incomplete> <juju-core:Won't Fix> <juju-core 1.25:Won't Fix> <cloud-init (Ubuntu):Fix Released> <cloud-init (Ubuntu Trusty):Confirmed> <cloud-init (Ubuntu Xenial):Fix Released> <cloud-init (Ubuntu
<mup> Yakkety):Fix Released> <https://launchpad.net/bugs/1599886>
<mup> Bug #1670708 opened: [docs] Release notes don't have 1.25.10 <docs> <juju-core:New> <https://launchpad.net/bugs/1670708>
<mup> Bug #1670708 changed: [docs] Release notes don't have 1.25.10 <docs> <juju-core:New> <https://launchpad.net/bugs/1670708>
<mup> Bug #1670708 opened: [docs] Release notes don't have 1.25.10 <docs> <juju-core:New> <https://launchpad.net/bugs/1670708>
<mup> Bug #1466951 opened: juju incorrectly mixes http-proxy with apt-http-proxy and doesn't mix no-proxy <docs> <proxy> <juju-core:Triaged> <https://launchpad.net/bugs/1466951>
<mup> Bug #1670708 changed: [docs] Release notes don't have 1.25.10 <docs> <sts> <juju-core:Fix Released by matthelmke> <https://launchpad.net/bugs/1670708>
<axw> hml: welcome to the team :)
<hml> axw: thank you!
#juju-dev 2017-03-08
<jam> axw: are you still interested meeting to discuss storage?
 * perrito666 sees jam running to the airport to meet axw
<axw> jam: I'm here. I don't have anything specific to talk about, but happy to talk
<axw> heh :)
<perrito666> axw: we miss you
<axw> perrito666: me too, wish I was there but I had a holiday booked
<perrito666> axw: smart man
 * chrisw watches the tumbleweed
<perrito666> chrisw: we are on a sprint, that makes this channel silent for about 5 days
<chrisw> perrito666 - interesting, I thought a sprint would make this place much busier :-) Where can sprints be tracked?
<perrito666> chrisw: a sprint means most developers are in the same room which causes us to be out of irc most of the time :) we dont have a public tracking of it since its mostly team organization, you will see announcements next week for sure
<mup> Bug #1670430 changed: /etc/mysql/my.cnf has incorrect ownership <mysql (Juju Charms Collection):New> <https://launchpad.net/bugs/1670430>
<mup> Bug #1670431 changed: myisam-recover invalid parameter in /etc/mysql/my.cnf file <mysql (Juju Charms Collection):New> <https://launchpad.net/bugs/1670431>
<mup> Bug #1671201 opened: juju bootstrap maas maas-controller: No available machine matches constraints <juju-core:New> <https://launchpad.net/bugs/1671201>
<mup> Bug #1671201 changed: juju bootstrap maas maas-controller: No available machine matches constraints <juju-core:Invalid> <MAAS:New> <https://launchpad.net/bugs/1671201>
<mup> Bug #1671265 opened: Allowing duplicate secgroups via neutron breaks 2.0.3 models with 2.1 controllers <juju-core:New> <https://launchpad.net/bugs/1671265>
<mup> Bug #1671265 changed: Allowing duplicate secgroups via neutron breaks 2.0.3 models with 2.1 controllers <juju-core:New> <https://launchpad.net/bugs/1671265>
<mup> Bug #1671265 opened: Allowing duplicate secgroups via neutron breaks 2.0.3 models with 2.1 controllers <juju-core:New for hmlanigan> <https://launchpad.net/bugs/1671265>
<mup> Bug #1671265 changed: Allowing duplicate secgroups via neutron breaks 2.0.3 models with 2.1 controllers <juju-core:New for hmlanigan> <https://launchpad.net/bugs/1671265>
#juju-dev 2017-03-09
<hoenir> new oracle client lives unde the juju umbrella https://github.com/juju/go-oracle-cloud
<mup> Bug #1454661 opened: presence collection grows without bound <canonical-is> <performance> <tech-debt> <juju-core:New> <https://launchpad.net/bugs/1454661>
<mup> Bug #1454661 changed: presence collection grows without bound <canonical-is> <performance> <tech-debt> <juju-core:New> <https://launchpad.net/bugs/1454661>
<mup> Bug #1454661 opened: presence collection grows without bound <canonical-is> <performance> <tech-debt> <juju-core:New> <https://launchpad.net/bugs/1454661>
<mup> Bug #1454661 changed: presence collection grows without bound <canonical-is> <performance> <tech-debt> <juju:New> <juju-core:Won't Fix> <https://launchpad.net/bugs/1454661>
<mup> Bug #1454661 opened: presence collection grows without bound <canonical-is> <performance> <tech-debt> <juju:New> <juju-core:Won't Fix> <https://launchpad.net/bugs/1454661>
<mup> Bug #1454661 changed: presence collection grows without bound <canonical-is> <performance> <tech-debt> <juju:New> <juju-core:Won't Fix> <https://launchpad.net/bugs/1454661>
<SimonKLB> something broke lxd container deployment on aws between juju 2.1.1 and 2.2-alpha1
<SimonKLB> i started a machine and deployed the ubuntu charm with `--to lxd:0`, in 2.2 the lxd is pending forever and not getting an ip address while on 2.1.1 it works fine
<rogpeppe1> perrito666: http://pastebin.ubuntu.com/24146583/
<rogpeppe1> perrito666: i call it "mismatch"
<perrito666> rogpeppe: and now, for an even cheaper version http://pastebin.ubuntu.com/24147234/
<perrito666> jam: http://pastebin.ubuntu.com/24147234/  <-- the lenghts this test takes me to
<perrito666> hml: hey, do you have a moment, there are a few tasks I need to pass to you
<perrito666> I am horacio btw :p
<hml> perrito666: ha.
#juju-dev 2017-03-10
<mup> Bug #1671733 opened: harvest mode setting not honoured by destroy-model <juju:New> <juju-core:New> <https://launchpad.net/bugs/1671733>
<mup> Bug #1671733 changed: harvest mode setting not honoured by destroy-model <juju:New> <juju-core:New> <https://launchpad.net/bugs/1671733>
<mup> Bug #1671733 opened: harvest mode setting not honoured by destroy-model <juju:New> <juju-core:New> <https://launchpad.net/bugs/1671733>
<mup> Bug #1670499 opened: maas 2.1.3 kvm nodes do not deploy, Juju reports 'started but not deployed'  <cdo-qa-blocker> <juju-core:New> <MAAS:New> <https://launchpad.net/bugs/1670499>
<mup> Bug #1670499 changed: maas 2.1.3 kvm nodes do not deploy, Juju reports 'started but not deployed'  <cdo-qa-blocker> <juju-core:New> <MAAS:New> <https://launchpad.net/bugs/1670499>
<rogpeppe1> if anyone is around, I'd appreciate a review of this PR (targetting a feature branch): https://github.com/juju/juju/pull/7087/files
<perrito666> jam: ship it
<perrito666> rogpeppe1: ill review
<rogpeppe1> perrito666: ta
<perrito666> rogpeppe1: tx for the idea yesterday btw, I wrote a dirty version for what I was doing and fixed most of the tests
<rogpeppe1> perrito666: cool, np
<perrito666> rogpeppe1: shipit
<rogpeppe1> perrito666: ta!
<mup> Bug #1670499 opened: maas 2.1.3 kvm nodes do not deploy, Juju reports 'started but not deployed'  <cdo-qa-blocker> <juju-core:New> <MAAS:New> <https://launchpad.net/bugs/1670499>
<jam> hml: I think your fix for https://bugs.launchpad.net/juju/+bug/1671265 should go into the 2.1 series, given the regression of support for Openstack I think it is a proper Critical blocker bug
<mup> Bug #1671265: Allowing duplicate secgroups via neutron breaks 2.0.3 models with 2.1 controllers <juju:In Progress by hmlanigan> <juju 2.1:In Progress by hmlanigan> <https://launchpad.net/bugs/1671265>
<hml> jam: there was a question of whether 2.1.2 would release before i could get the fix out
<jam> hml: sure. Mostly a 2.1.x
<jam> vs just 2.2
<jam> they won't move to an alpha to get openstack fixed
<elmo> hey - Juju folks, does Juju need the 'ubuntu' user once the agent is up and running?
<elmo> jam: ^- if you know
<perrito666> elmo: afaik at least juju ssh will depend on the ubuntu user being there, I cant tell you out of the top of my head but I am pretty sure more things deppend on it (backup and restore come to mind)
<perrito666> elmo: we are on a sprint right now so jam might not be near his computer, ill ping him as soon as I find him to see if he has more input
<elmo> ah, maybe actions and/or juju-run?
<perrito666> debug hooks seems to deppend on it too
<perrito666> elmo:  I believe actions might be free of that dependency but not in every version of juju, only after we changed the way they are executed, cant say which version that happened  though
<jam> wpk: https://github.com/juju/juju/wiki/Code-Review-Checklists
<jam> elmo: actions are likely to run as root, and juju-run should be moving over to triggering via the actions stuff, but "juju ssh/scp" need a user and we don't want to give root an ssh key
<jam> perrito666: elmo: 'run' is supposed to not use ssh for 2.0 (and possibly not even 1.25)
<elmo> jam: there's no ssh key as root though; do they login as ubuntu  and su to ubuntu?
<jam> elmo: so "juju ssh" doesn't su unless you ask it to. "juju-run" was supposed to be fixed to just run as root without ssh first
<jam> (as in we have something watching for run requests that spawns the request directly)
<elmo> ah, interesting
<elmo> jam: so the unit agent kicks off both run requests and actions?
<jam> elmo: as I understand it, yes.
<elmo> jam: OK, thanks
<jam> elmo: I just confirmed. I blocked port 22 and "juju ssh" doesn't work but "juju run 'echo hello'" works
<abentley> jam, elmo: In fact, I filed a bug about this, as the behaviour changed in 2.x and no longer matches the docs: https://bugs.launchpad.net/juju/+bug/1628593
<mup> Bug #1628593: Juju run runs as root, not 'ubuntu' <jujuqa> <run> <juju:Triaged> <juju 2.0:Won't Fix> <https://launchpad.net/bugs/1628593>
<elmo> https://pastebin.canonical.com/182159/
<elmo> so, yeah - debug hooks and restore
<elmo> it looks l;ike
<elmo> actions are definitely api/agent driven
#juju-dev 2017-03-11
<mup> Bug #1654136 changed: Removing relationship didn't remove subordinate unit <canonical-bootstack> <juju-core:Expired> <https://launchpad.net/bugs/1654136>
#juju-dev 2018-03-06
<mup> Bug #1662272 opened: Agents stop running hooks and are hung <canonical-bootstack> <canonical-is> <juju-core:Confirmed> <https://launchpad.net/bugs/1662272>
<mup> Bug #1662272 changed: Agents stop running hooks and are hung <canonical-bootstack> <canonical-is> <juju-core:Won't Fix> <https://launchpad.net/bugs/1662272>
#juju-dev 2018-03-07
<ejat> build: Unable to locate layers/charm-prometheus-openstack-exporter. Do you need to set LAYER_PATH?
<ejat> what should i do?
<thumper> https://github.com/juju/juju/pull/8460 someone
<thumper> https://github.com/juju/juju/pull/8461
<thumper> next
<thumper> wallyworld: ^^^
#juju-dev 2018-03-08
<babbageclunk> externalreality: http://www.sciencemag.org/news/2016/07/how-colorblind-cuttlefish-may-see-living-color
#juju-dev 2018-03-09
<bdx> https://bugs.launchpad.net/juju/+bug/1754735
<mup> Bug #1754735: Juju does not support current AWS instance types <juju:New> <https://launchpad.net/bugs/1754735>
<bdx> user facing nonesense https://bugs.launchpad.net/juju/+bug/1754748
<mup> Bug #1754748: `juju offers` pushes cryptic and broken user facing message <juju:New> <https://launchpad.net/bugs/1754748>
