#juju-dev 2012-02-27
<rog> morning!
<TheMue> rog: hiya
<rog> TheMue: yo!
<rog> weird problem: i'm changing a time.Sleep statement. if it's 0.1 seconds, the test runs for 6.749s. if it's 1 second, the test runs for 9.375s.
<rog> i wonder if time is moving wrongly on this machine
<rog> ah, easy answer! the test is run three times...
<TheMue> hehe, so no wonder
<TheMue> fwereade: morning
<fwereade> TheMue, heyhey
<rog> fwereade: i've just submitted the long-time-pending branch of gnuflag that adds SetOutput, amongst other things
<rog> fwereade: i was waiting for a review from niemeyer, but it never came
<fwereade> rog, awesome, tyvm
<fwereade> rog, I have a trivial here to get a very few tests passing again with the new gocheck: http://paste.ubuntu.com/858896/
<rog> fwereade: LGTM
<rog> fwereade: i'm just about to have a look at your new persistence branch BTW
<rog> fwereade: and thanks for the review of go-ec2-robustness
<fwereade> rog, a pleasure :)
<rog> fwereade: glad you liked the attempt type :-)
 * fwereade tries to remember what branches he has queued up
<rog> (i thought it was quite neat)
<fwereade> rog, yes indeed, that branch made me happy :)
<rog> fwereade: a previous branch had a version of this code in, which made quite a nice pair with attempt, but it became unnecessary, so i deleted it, with slight regret. http://code.google.com/p/rog-go/source/browse/parallel/parallel.go
<fwereade> rog, nice :)
<fwereade> TheMue: I have some trivial changes to make state work with the new gocheck: http://paste.ubuntu.com/858916/
<TheMue> fwereade: yep, i'm just doing it
<fwereade> TheMue, ah sorry, I should have coordinated
<fwereade> TheMue, rog: is there a part of juju/go whose test failures are *not* being looked at by one of you, that I can pop in and fix quickly?
<TheMue> fwereade: I'll do everything below state
<fwereade> TheMue, cool
<fwereade> rog, is any of what remains under your aegis or shall I just work through them?
<fwereade> TheMue, do you mean to include store in what you said or not?
<TheMue> fwereade: no, only state. i don't know what gustavo already did there
<fwereade> TheMue, rog: ok, I'll pick something not in state at random and go from there
<TheMue> fwereade: sounds reasonable
<rog> fwereade: i'm happy to do everything under environs
<fwereade> TheMue, btw, the patch above seems to fix all the actual failures; it doesn't deal with switching to HasLen where appropriate
<fwereade> rog, cool
<rog> fwereade: i'll just go and update gocheck
<TheMue> fwereade: i'll take a look
<rog> fwereade: i'm slightly concerned about tests that do: c.Assert(x, Not(Equals), y)
<rog> fwereade: because they won't necessarily fail though they'll be wrong
<rog> fwereade: worth looking for, i think
<fwereade> rog, hmm; I haven't seen many of those thankfully, but I'll try to give every Equals at least a quick glance ;)
<fwereade> rog, TheMue: would one of you cast an eye over http://paste.ubuntu.com/858930/ please?
<rog> on it
 * TheMue too (and I would like a neat diff visualizer)
<rog> fwereade: bug := Commentf("ParseURL(%q)", t.s)
<rog> fwereade: seems wrong
<rog> fwereade: shouldn't be named "bug" any more...
<fwereade> rog, good point, ty
<rog> TheMue: bzr qdiff works well
<rog> TheMue: also we've got codereview.com :-)
<TheMue> rog: I meant in web instead of using pasteâ¦ here
<rog> TheMue: yeah, well that's why we've got rietveld...
<fwereade> TheMue, ah, sorry, I was thinking most of these were quite well suited to plain-ol-diff format
<rog> fwereade: they were
<rog> fwereade: LGTM modulo s/bug/com(ent)?/
<rog> s/ent/ment/ :-)
<fwereade> rog, cool, I called it comment
<TheMue> rog, fwereade: like many pastes provide syntax highlighting i just would like a better visualization of a pasted diff. good uis are nothing bad.
<fwereade> TheMue, rog: do we want double-reviews for these or are we ok with a single LGTM?
<rog> fwereade: i think we're fine with single LGTMs for these
<fwereade> TheMue, sorry, I didn't intend any unnecessary cognitive load
<TheMue> rog, fwereade: ack
<fwereade> TheMue, I'll lbox propose the next one, doesn't cost me much ;)
<TheMue> fwereade: no, that's not your problem, no need to excuse. only a feature wish to pasting-plattforms
<TheMue> fwereade: even w/o lbox it should be possible to create more readable diff vizualizations
<TheMue> fwereade: at least coloring - in red and + in green
<fwereade> TheMue, quite so, syntax highlighting on paste.ubuntu.com would be nice (as long as I didn't have to think about it at all ;))
<TheMue> fwereade: yep, just paste, the system guesses (or you set a lang or diff) and done
<fwereade> rog, TheMue: first one to ack gets the glory of reviewing this not-really-very-complex-but-nonetheless-unhighlighted diff: http://paste.ubuntu.com/858944/
<rog> ack
<TheMue> ack
<rog> fwereade: LGTM
<rog> fwereade: BTW i think these should probably go through lbox propose anyway, just for the annotations
<fwereade> rog, I planned to do that, and then cloudinit seemed so trivial as to be mocking me ;)
<fwereade> rog, will do though
<rog> fwereade: do 'em all in one branch
<fwereade> rog, as you like it :)
<rog> fwereade: (i can't see any reason to do a separate branch for each package - they're all fixes relating to the same thing)
<fwereade> rog, optimal triviality of reviewing :)
<rog> amortised anyway...
<fwereade> rog, or at least "perceived" ;)
<rog> fwereade: what's a good way to "un-diverge" a branch when it says it's diverged?
<rog> (i only forked it earlier this morning)
<rog> fwereade: i did merge with trunk
<rog> fwereade: still diverged
<fwereade> rog, not really sure I'm afraid :(
<fwereade> rog, I have on occasion got myself out of such holes with voodoo and magic that I don't recall
<rog> ah, i've discovered the problem!
<fwereade> rog, but last time I think I went straight to diff, fresh branch, patch
<rog> fwereade: lbox was trying to push to lp:juju/go
<fwereade> rog, oh yes?
<rog> fwereade: i forgot to do the manual push
<fwereade> rog, cool
<rog> fwereade: would be nice if it mentioned the name of the branch it failed to push to...
<fwereade> rog, ha, yeah
<rog> fwereade, TheMue: first to ack gets it: https://codereview.appspot.com/5699085/
<fwereade> rog, ack
<fwereade> rog, TheMue: https://codereview.appspot.com/5701056
<rog> fwereade: LGTM
<fwereade> rog, LGTM also
<fwereade> rog, get yours in first and I'll merge and submit afterwards
<rog> fwereade: submitted
<rog> fwereade: thanks
<fwereade> rog, and likewise and likewise :)
<TheMue> So, https://codereview.appspot.com/5671055/ and https://codereview.appspot.com/5690051/ urgently need their LGTM to move into the trunk.
<rog> TheMue: the second one can't be reviewed until the first one is submitted
<rog> TheMue: and the first one is waiting for a LGTM from niemeyer, so i can't help, sorry.
<TheMue> rog: yep, i already asked gustavo for it.
<rog> TheMue: you'll just have to wait until he's ready, i'm afraid.
<rog> TheMue: (you can do the gocheck fixes before submitting those branches, of course)
<TheMue> rog: the last both proposes now contain the gecheck fixes
<rog> TheMue: you should do the gocheck fixes as a separate propose, i think.
<rog> TheMue: that way we can get a working state without the necessity to submit both of those branches
<rog> TheMue: (you can do the fixes as a branch from the current trunk, then merge it into your upcoming branches)
<TheMue> rog: yeah, could do, but i dislike this juggling. the reviews are really almost ready since now almost 4 days
<rog> TheMue: yes, i know the feeling very well. it's frustrating, but we have to live with it...
<TheMue> rog: yep
<TheMue> lunchtime
<rog> fwereade: review delivered
<fwereade> rog, cheers
<rog> fwereade: trivial matters only...
<fwereade> rog, sweet :)
<rog> fwereade: what's with "iNstance" ?
<fwereade> rog, er, it looks a bit more like an instance id. I totally should have called it "instance-id"
 * fwereade looks a bit shamefaced
<rog> fwereade: i've been using i-aaaaaaaa
<rog> fwereade: (or similar)
<rog> (which is actually a valid ec2 instance id)
<fwereade> rog, yeah, seems smarter
<rog> fwereade: i thought there was some cross check i hadn't seen
<TheMue> so, https://codereview.appspot.com/5695073/ is for the current trunk
<fwereade> rog, no, I'm afraid it does nothing whatsoever
<rog> fwereade: ok, cool. maybe worth changing though
<fwereade> rog, definitely
<rog> TheMue:        c.Assert(keys, Equals, []string{"m-0", "m-1"})
<fwereade> TheMue, I'm 99% sure I spotted some Assert(len(blah), s
<rog> TheMue: i can't see how this is guaranteed to work
<rog> oops, sorry
<rog> TheMue: didn't see the sort.Sot
<rog> Sort
<rog> Strings, even
<TheMue> ;)
<TheMue> fwereade: tests are green. what problem do you expect?
<fwereade> TheMue, no failures expected; just that not using HasLen leads to more opaque failures if and when they do happen
<TheMue> fwereade: oh, will take a look
<TheMue> rog: what do you mean with "no ItemChange"?
<rog> TheMue: you could write it as []ItemChange{{....}}
<rog> er, i think, hold on
<rog> yeah
<rog> TheMue: within a slice initialiser, you can omit the type names if they're implied
<TheMue> rog: ah, yes, one of the g1 changes
<rog> TheMue: that change has been around for months actually
<TheMue> rog: yep, missed to use it
<rog> TheMue: in fact it was in r60
<rog> (assuming play.golang.org still uses r60)
<TheMue> rog: anything else?
<rog> TheMue: nope
<rog> just gonna reboot and try and get my system working again
<TheMue> fwereade, rog: fixed it
<fwereade> TheMue, LGTM
<rog> niemeyer: hiya
<niemeyer> rog: Yo
<rog> niemeyer: i think most of the gocheck changes have been done, BTW
<rog> niemeyer: just state to be submitted
<niemeyer> rog: neat, I was just checking them out, thanks for that
<TheMue> niemeyer: hiya from Germany too
<niemeyer> TheMue: Hey man
<niemeyer> fwereade_: You've got a review on the presence node
<fwereade_> niemeyer, thanks
<niemeyer> fwereade_: Let me know if you wanna talk about any of the points
<niemeyer> fwereade_: The whole thing looks very good
<fwereade_> niemeyer, will do :)
<fwereade_> niemeyer, sweet :D
<niemeyer> fwereade_: Mostly details
<niemeyer> fwereade_: There's a single actual issue in the implementation
<fwereade_> niemeyer, bother
<niemeyer> fwereade_: https://codereview.appspot.com/5672067/diff/16001/state/presence/presence.go#newcode133
<niemeyer> fwereade_: I think this is the only one that will require a bit of fiddling
<fwereade_> niemeyer, hmm, that was largely inspired by worries of "what if for some reason the remote node starts up with a different timeout?"
<niemeyer> fwereade_: I don't understand how that changes the point
<niemeyer> fwereade_: Can you describe further.. ok, what if..?
<fwereade_> niemeyer, it's a possible reason to pay the costs you point out
<fwereade_> niemeyer, then we might see it "die" because we're expecting it to update more often than it does
<niemeyer> fwereade_: I mean I'm still missing the problem.. what if it starts with a different timeout.. why do we have to read clock on every ping?
<fwereade_> niemeyer, ha, good point, sorry misunderstoof
<fwereade_> niemeyer, thanks for that, I'll figure something out :)
<niemeyer> fwereade_: Thank you
<niemeyer> fwereade_: Btw, please ignore the first two comments.. they were left-overs from a previous review not delivered
<fwereade_> niemeyer, ok
<rog> fwereade_: wasn't this the same point we discussed before?
<rog> fwereade_: i thought you were concerned about clock skew
<fwereade_> rog, I was, and for some reason that didn't seem relevant just now
 * fwereade_ tries to switch mental gears properly
<fwereade_> rog, got it, it no longer feels like an issue because the watches are no longer expecting to live through multiple liveness changes
<rog> fwereade_: actually, i think the real reason it seems ok is that you've got a notion of "now" from the just-changed node...
<fwereade_> rog, or alternatively that I know the node has just changed *before* my timeout fired, and so I don't really care when "now" is any more
<rog> fwereade_: good point
<TheMue> niemeyer: had a chance to look into https://codereview.appspot.com/5671055/?
<niemeyer> rog: https://codereview.appspot.com/5698073 is done
<niemeyer> TheMue: Will look next
<TheMue> niemeyer: fine, thx
<rog> niemeyer: that was quick! thanks a lot.
<niemeyer> rog: np
<niemeyer> TheMue: done
<TheMue> niemeyer: ah, fine
<niemeyer> TheMue: The last comment is wrong.. the one about s/anyone/it/
<niemeyer> TheMue: It should be "any other charm" rather than "anyone"
<TheMue> niemeyer: ok, will take care
<niemeyer> TheMue: Cheers
<TheMue> niemeyer: regarding the bundle url, shall it be a charm.URL too? so far it has been just a string
<niemeyer> TheMue: No, that's not a charm URL.. it's a real URL
<niemeyer> TheMue: http, https, whtaever
<TheMue> niemeyer: got it, will take net/url.URL
<niemeyer> TheMue: That'd be fine, yeah
<rog> niemeyer: changes made. you might want to take a brief look before i submit as i've made the gocheck changes too.
<niemeyer> rog: Nice, thanks
<niemeyer> rog: LGTM
<rog> niemeyer: thanks
 * niemeyer => lunch!
<niemeyer> rog: np
<rog> niemeyer: enjoy
<rog> niemeyer: (submitted BTW)
<rog> fwereade_, niemeyer: this is my current test for zk concurrent close. it's fairly complex and not a little fragile. i'm thinking perhaps i should chuck it in and do something that does a much more simple verification of a single non-zk-read-lock-taking operation, because the read lock code is so simple to verify by eye. what do you think?
<rog> http://paste.ubuntu.com/859386/
<rog> fwereade_: (you might recognise your proxy code, in heavily mutated form...)
<fwereade_> rog, heh; when you say "fragile" do you mean "sometimes breaks in practice", or just "assumes more than it should to be a nice black box test"?
<rog> fwereade_: i mean "might break in practice on a heavily loaded machine"
<rog> fwereade_: because it has to do a sleep to ensure that the right piece of code takes the lock at the right time
<rog> fwereade_: there's no guarantee that it works
<fwereade_> rog, ah, I missed that, hmm
<rog> fwereade_: of course 1/20th of a second *should* be perfectly sufficient, but...
<fwereade_> rog, indeed
<rog> fwereade_: i can't think of another way to do it, as we need to test the two operations concurrently and there's no way to "get inside" either of them
<rog> fwereade_: unless we just do that and have an operation (in export_test.go) whose raison d'etre is to test the locking logic.
<rog> fwereade_: but that can't be used to directly test all the operations.
<fwereade_> rog, I am inclined to go with the "50ms should be enough for anybody" approach, but expand please: what would you put in export_test to get around this?
<rog> fwereade_: i'd add a fake test operation to zk.Conn which took the read lock, then waited for notification, then relinquished it.
<rog> fwereade_: so then at least we could test the Close behaviour
<rog> fwereade_: and all the operations are tested "by analogy". not great. but can you think of a better way?
<fwereade_> rog, afraid not
<fwereade_> rog, I think I'd prefer theoretically-unsound tests of the actual behaviour
<rog> fwereade_: it seems like a lot of code to test something which is really quite simple. (as you saw it only took about 5 minutes to implement, and it's quite easy to verify by hand)
<rog> fwereade_: and it can't test all of the operations either
<rog> fwereade_: (it has to omit the ones that don't interact with the zk server)
<fwereade_> rog, if I think of anything better I'll let you know ;)
<fwereade_> rog, afk a sec
<rog> fwereade_: afk?
<jimbaker> rog, away from keyboard
<rog> jimbaker: ah, thanks. hadn't seen that one before.
<rog> jimbaker: good morning, BTW!
<jimbaker> rog, thanks! and hopefully a nice evening to you! :)
<rog> jimbaker: more like afternoon. evening approaches though.
<rog> jimbaker: pretty grey day, to be honest.
<jimbaker> rog, my impressions of newcastle, formed purely by literature, are always of a gray day, lashed by the winds of the north sea :)
<jimbaker> this may or may not have a basis in truth
<rog> jimbaker: well, north sea about 20 east of here, but it can be gray. although it can be beautifully sunny too!
<rog> s/20/20 miles/
<jimbaker> rog, glad to hear that. probably my mind is fixated on wind, we just went through about 5 days of strong winds here. at my house, gusts of approx 150 km/hr. enough to see grassfires, trucks lying on their sides, bicyclists blown over... now that's some imagery
<rog> jimbaker: that is strong. we've had some fairly good winds here this season (our house faces the prevailing westerlies) but nothing like that
<jimbaker> rog, same with us in terms of exposure to westerlies, which are the strongest winds here. anyway, it's the worst in the 11 years i have lived here
<jimbaker> but it's back to calm and sunny skies. the mountains made us aware of their presence, they are now back to quiet brooding
<TheMue> niemeyer: https://codereview.appspot.com/5671055/ is in again
<niemeyer> TheMue: cheers!
<niemeyer> TheMue: TestCharm still needs dropping
<niemeyer> TheMue: It's fully redundant with the test followin git
<niemeyer> TheMue: Otherwise, LGTM
<TheMue> niemeyer: oh, did i missed it? shit.
<TheMue> niemeyer: ok, will propose it in a few minutes again. btw, rog reminded me that i can remove ItemChange inside of []ItemChange{}. Could do it quickly too.
<rog> TheMue: why not leave that for the next one?
<TheMue> rog: could do so too. only because it's a quick one.
<rog> TheMue: your call
<TheMue> niemeyer: what do you say?
<niemeyer> TheMue: Works either way for me, as long as that's the end of it
<TheMue> Gna! Connection lost.
<TheMue> niemeyer: so, hopefully last try
<rog> pwd
<rog> oops
<niemeyer> TheMue: TestCharm is *still* there!?
<rog> i'm off for the day, see y'all tomorrow
<niemeyer> rog: Have a good one
<TheMue> niemeyer: arg, sorry, got you wrong. though you meant the url comparison and the last assert should be removed, not the whole test. *sigh*
<TheMue> niemeyer: my fault.
<niemeyer> TheMue: All of the lines in TestCharm may be found in that precise shape in the test following it
<niemeyer> TheMue: So there's no point in having it
<TheMue> niemeyer: yep, i understand, only understood your review wrong
<TheMue> niemeyer: i have been too much focused on the url
<niemeyer> TheMue: Cool, np
<TheMue> niemeyer: so one last propose ...
<niemeyer> TheMue: Please just drop the test and submit
<TheMue> niemeyer: ok, that's shorter ;)
<TheMue> niemeyer: sadly you stole me some test methods today, so my high watermark is lower now :(
<TheMue> niemeyer: i'm still not secure with lbox submit, i updated my trunk, merged it into my change and now wanted to submit it. but it says the branch is not clean. do i have to do a commit before lbox submit?
<niemeyer> TheMue: If you have changes in your branch, you necessarily must commit them, or revert if you don't want them in the final merge
<TheMue> niemeyer: i committed my changes before the merge (it's the removing of AddCharm() )
<niemeyer> TheMue: submit will deliver the changes that you did in your branch onto the target branch.. it will not do changes behind your back
<niemeyer> TheMue: So why is the branch dirty?
<TheMue> niemeyer: after my commit i've done a bzr pull in my go-trunk (the base of this propose), then i changed back to my go-state-â¦ and do a bzr merge ../go-trunk there
<TheMue> niemeyer: here i got no conflicts and a final go test in state worked fine
<niemeyer> TheMue: Sure.. and then you have to commit that.. the merge will not be committed automatically
<TheMue> niemeyer: ah, ok, that's missing. lbox help also states a commit, so i thought it's done automatically.
<niemeyer> TheMue: It will commit the merge of your branch onto the target branch
<niemeyer> TheMue: It will not fiddle with unfinished states in your own branch
<TheMue> niemeyer: still not absolutely safe in the world of dvcs.
<TheMue> niemeyer: thx for your help
<TheMue> niemeyer: it's in
<niemeyer> TheMue: Woohay!
<hazmat> niemeyer, does lbox -cr support prerequisite branches?
<jimbaker> hazmat, use the -req option
<hazmat> jimbaker, thanks
<niemeyer> hazmat: Kind of
<niemeyer> hazmat: THis is my first TODO after the store work
<niemeyer> hazmat: It won't diff the branches properly, so all but the first branch in the pipeline will contain data for the previous entries too
<niemeyer> hazmat: So, in practice, it doesn't work very well yet
<niemeyer> hazmat: I didn't want to fix that before submit was working, though, to prevent people mistakingly submitting follow up branches thinking that this was _just_ what they were changing
<hazmat> niemeyer, thanks for clarifying, i was noticing that problem but wasn't sure if -req was obmitted or would help.
<niemeyer> hazmat: Now submit works, so I'll make submitting check to see if the pre-req is in
<niemeyer> hazmat: and will make propose diff against the previous branch in the pipeline
<niemeyer> hazmat: Will work on this as soon as store is out of the way
<hazmat> niemeyer, sounds good
<niemeyer> andrewsmedina: How're things going there?
<andrewsmedina> niemeyer: hi
<niemeyer> andrewsmedina: Heya
<andrewsmedina> niemeyer: I started the local provider
<niemeyer> andrewsmedina: Sweet!
<andrewsmedina> niemeyer: inspired by ec2 provider
<niemeyer> andrewsmedina: Super
<andrewsmedina> niemeyer: but I had some problems with gocheck
<niemeyer> andrewsmedina: Hmmm.. when did you do that?
<hazmat> bcsaller1, is the subordinate spec ready for niemeyer to have another look?
<niemeyer> andrewsmedina: Do you want an introduction to the development process via a low-hanging fruit?
<bcsaller1> hazmat: yeah, thought it was in the queue, I'll check again
<andrewsmedina> niemeyer: low-hanging fruit?
<hazmat> bcsaller1, it was proposed again to reitveld afaics
<niemeyer> bcsaller1: Maybe it was and I just overlooked it.. please let me know of the URL and I'll check it out
<hazmat> er. wasn't
<niemeyer> andrewsmedina: A simpler change that allows to see how things work
<niemeyer> andrewsmedina: It's probably better than doing a lot of work without touching base as your first task
<andrewsmedina> niemeyer: It would be amazing :D
<hazmat> bcsaller1, it looks like it was just pushed again to lp, lbox propose again should do the trick
<niemeyer> andrewsmedina: This is a good candidate: https://codereview.appspot.com/5532098/diff/4001/juju/charm/metadata.py
<bcsaller1> niemeyer, hazmat: it doesn't appear to upload the new push, I'll try it now
<bcsaller1> must have gotten an error before I didn't see
<niemeyer> bcsaller1, hazmat: Was that original spec merged already?
<bcsaller1> no
<niemeyer> bcsaller1: Ouch
<niemeyer> bcsaller1: What happened?
<bcsaller1> kapil had to +1 it as well and then there were the changes you'll be looking at now
<andrewsmedina> niemeyer: what needs to be done?
<niemeyer> andrewsmedina: We need to port that change onto the Go side
<niemeyer> andrewsmedina: Should be a pretty comfortable ride
<andrewsmedina> ok
<niemeyer> andrewsmedina: This will affect charm/meta.go
<niemeyer> andrewsmedina: and the respective tests, of course
<andrewsmedina> niemeyer: how you set your dev enviroment and run the tests?
<niemeyer> andrewsmedina: I do: export GOPATH=$HOME
<andrewsmedina> niemeyer: I did checkout in gopath
<niemeyer> andrewsmedina: and "go get launchpad.net/juju/go/charm", for example
<andrewsmedina> niemeyer: and I run, tests module by module
<niemeyer> andrewsmedina: This will set up all dependencies
<andrewsmedina> niemeyer: yes
<niemeyer> bcsaller1: :-(
<niemeyer> bcsaller1: We spent a lot of energy to agree on that state
<andrewsmedina> niemeyer I'm on the right way
<bcsaller1> niemeyer: we talked about this at the call on Thursday
<niemeyer> bcsaller1: If Kapil had comments on it, they should be applied on the original state.. now we have an unrelated new change that is piled up together with the whole spec, and we've got no agreement committed yet
<bcsaller1> niemeyer: I saw them as related changes from the needed second +1
<niemeyer> bcsaller1: I know, but I thougth you were talking about a _new_ branch.. I had no idea that this change that we agreed on is still floating around uncommitted
<bcsaller1> I have the full revision history. This is getting merged into the docs branch anyway, we can build whatever history you want there
<niemeyer> bcsaller1: Do you have the link at hand?
<bcsaller1> niemeyer: https://codereview.appspot.com/5541054/
<niemeyer> bcsaller1: All I see in that link is "Thanks a lot for the extensive spec, and for keeping up with it Ben. Just a few
<niemeyer> last minute trivials."
<niemeyer> bcsaller1: and hten "Please take another look."
<niemeyer> bcsaller1: Where are the comments from Kapil that you are addressing?
<bcsaller1> niemeyer: prior G+ talks , there are the changes brought up in the last meeting reflected in subordinate-internals
<niemeyer> This is really bad..
<niemeyer> This is a spec from several months ago.. that was approved more than 2 weeks ago, and now it revives.
 * niemeyer looks..
<niemeyer> bcsaller1, hazmat:
<niemeyer> 	  49          global/
<niemeyer>   50               global/
<niemeyer> !?
<bcsaller1> niemeyer: thats so that the path structure is the same for all types
<bcsaller1> container/unit-0001/... or global/global/...
<bcsaller1> the same path construction logic can then be used
<niemeyer> bcsaller1: Sorry, I don't get..
<hazmat> that feels a little strange
<hazmat> also for containers the settings node should be under the container
<bcsaller1> one is relation_scope_type/relation_scope/value
<bcsaller1> err... one is relation_scope_type/relation_scope_value
<hazmat> bcsaller1, but its redundant
<hazmat> bcsaller1, global should suffice for scope and value
<bcsaller1> hazmat: not really, it looks that way to a human, but its a uniform structure to the apis
<hazmat> bcsaller1, the api can interpret global scope however it chooses
<hazmat> bcsaller1, and settings should always be under scope, else the additional containment serves little purpose imo.. effectively this is reuse of the existing relation work/watchers, with a prefix to the base path
<bcsaller1> hazmat: agreed, I guess I didn't juggle it properly
<niemeyer> bcsaller1: I don't understand.. you have to special case it anyway to pick global.. in fact why don't we even have any "global" in there at all?
<niemeyer> s/don't we/do we/
<niemeyer> bcsaller1: I assume we can tell whether a relation is a container relation or not based on the topology information, right?
<bcsaller1> niemeyer: it mirrors container/unit-0001, container/unit-00002 etc. the path is relations/relation_id/relation_scope_type/relation_scope_value/relation_role/... where things under relation_scope_value are the previous structure
<bcsaller1> niemeyer: yes, that has to be the case
<niemeyer> bcsaller1: So why do we even have "container" or "global" nodes?
<niemeyer> bcsaller1: What problem are these solving?
<niemeyer> bcsaller1: In fact, what problem is the change from the original spec that was last reviewing solving?
<niemeyer> last reviewed, sorry.. I can't write anymore
<bcsaller1> niemeyer: I think it helps with a number of things. It helps address the case of principal service A with subs B and C, where B/0 and C/0 have a relation contained by A/0
<niemeyer> bcsaller1: Ok, I guess it enables watching more specifically..
<bcsaller1> that as well
<niemeyer> bcsaller1: as well? What else?
<bcsaller1> it was very hard to understand container relations between services where neither of them was the container before
<niemeyer> bcsaller1: How is that related to the structure of the nodes?
<hazmat> it solves having to do some dereferencing when establishing what sort of watch to establish, else the filtering has to do quite a few lookups to establish a filter, it also effectively preserves reuse of the existing watch logic, just with a prefix path for existing relation types.. ie. effectively it encodes the additional axis of scope as part of the physical structure
<bcsaller1> hazmat: thanks, yes
<hazmat> ugh.. too much 'effectively'.. is that like a double negative ;-)
<niemeyer> hazmat: I see, cheers
<hazmat> bcsaller1, even given that.. the global/global can just be 'global', and settings should be moved under the scope
<niemeyer> bcsaller1: So just s,global/global/,global/, please
<bcsaller1> I can but it makes the handling code non-uniform, I don't know that its really better but I'm willing to add branch code in there
<niemeyer> bcsaller1, hazmat: Hmm..
<niemeyer> bcsaller1, hazmat: Can an individual principal have more than one subordinate under the same relation?
<niemeyer> bcsaller1, hazmat: And vice-versa?
<bcsaller1> container/unit-id/ will exist once for each container in the relationship
<bcsaller1> subordinates can still only have once principal
<hazmat> niemeyer, no.. they'd be different relations, relations are pair-wise service 2 service
<niemeyer> hazmat: How many units may a given relation have?
<hazmat> niemeyer, arbitrary
<hazmat> er. infinite
<bcsaller1> limited by ZK memory ;)
<niemeyer> hazmat: how might that happen when we're talking about container relations?
<hazmat> niemeyer, it wont .. for container relations, its basically pair wise on unit 2 unit basis
<niemeyer> hazmat: So you're saying that a given relation rel-000000042, will only ever have two units?
<hazmat> niemeyer, no.. it will have n units.. where n is the number of primary/principal service units
<hazmat> er.. 2n
<hazmat> with the additional count coming from subordinates
<hazmat> but a given container scope for that relation will have two units
<niemeyer> hazmat: Aha, ok
<niemeyer> hazmat: That structure still feels a bit overblown
<niemeyer> hazmat: Have you had a chance to see the branch that has the code reuse etc?
<bcsaller1> niemeyer: he hasn't
<hazmat> niemeyer, i have not, but i can envision it fairly easily
<niemeyer> hazmat: Ok.. why do you want to move settings again?
<hazmat> niemeyer, two reasons, it preserves the watch semantics with the use of the prefix, and it keeps the information about scope within the context of that scope.
<niemeyer> hazmat: Sounds good
<hazmat> cool
<niemeyer> hazmat: This means we can take both "global" keys out
<niemeyer> hazmat: and that we can take the "container" keyword out as well
<niemeyer> hazmat: So that relation-0000N has either:
<niemeyer> 1) A list of unit names, when it's a container relation
<niemeyer> or
<niemeyer> 2) server, client, settings
<niemeyer> The latter, (2), happens to be exactly what one would find inside the unit name of (1).
<niemeyer> So global/global/, and container/, can both go away
<niemeyer> hazmat: WDYT?
<hazmat> niemeyer, yeah.. i had hoped for that earlier as well during a g+ discussion.. i'm fine witht hat, bcsaller1 had raised a question regarding that still leaving a question of where to find the scope, but i still think that comes out/falls out from retrieving the unit relation state
<hazmat> iotw, works for me
<hazmat> bcsaller1, what do you think?
<niemeyer> hazmat: The scope comes out of the topology, IMO
<niemeyer> hazmat: No matter what, the implementation shouldn't be _listing_ relation-0000N to know what to do
<hazmat> niemeyer, agreed, topology is probably the right place
<bcsaller1> I'm fine with that as well
<niemeyer> hazmat: and it should already be there anyway right now..
<niemeyer> bcsaller1: Super
<hazmat> cool, sounds like agreement
<hazmat> let's ship it ;-)
<bcsaller1> I'll make some revisions and push it again :-/
<niemeyer> bcsaller1: Sent these notes onto the review
<bcsaller1> niemeyer: thanks
<niemeyer> bcsaller1: np
<niemeyer> I'm stepping out for some exercising outside.. will be back later today
<hazmat> i'm gonna do the same, bbiab
 * hazmat yawns
#juju-dev 2012-02-28
<TheMue> rog: morning
<rog> TheMue: hiya
<niemeyer> Alow
<TheMue> niemeyer: hiya
<TheMue> niemeyer: my propose of the continued machines based on yesterdays charms (has been a branch of that) is in
<niemeyer> TheMue: Thanks
<niemeyer> TheMue: I may only get to it tomorrow
<niemeyer> TheMue: I'll try to stick to store work today, since I've been clearly failing at it
<TheMue> niemeyer: ok, no prob, better keep concentration
<TheMue> niemeyer: would part of state should I take next?
<rog> lunch
<rog> (outside in the sun!)
<niemeyer> TheMue: Not sure..
<TheMue> rog: enjoy. sun? (envy) here it is grey and wet
<niemeyer> TheMue: Actually, wasn't there something to be done as a left over from the current work?
<niemeyer> I recall something like that, but can't remind of it now
<niemeyer> TheMue: Ah, yes.. zk => st
<TheMue> niemeyer: state into all entities, but that's only very small
<niemeyer> TheMue: Yeah, but has to be done
<TheMue> niemeyer: yep, exactly
<niemeyer> TheMue: Besides that, just pick something that moves the state forward
<TheMue> niemeyer: ok, will do so
<niemeyer> TheMue: Preferably in areas that do not conflict with changes going on in Python (relations)
<niemeyer> andrewsmedina: Any progress there?
<andrewsmedina> niemeyer: yes
<niemeyer> andrewsmedina: Nice
<TheMue> niemeyer: yep, no relations
<andrewsmedina> niemeyer: I'm finishing the tests for port charm metadata subordinate to Go
<niemeyer> andrewsmedina: Very neat
<niemeyer> andrewsmedina: Thanks for working on that
<andrewsmedina> niemeyer: :D
<rog> wondering if anyone is up for sanity-checking a possible approach to making my ec2test fake ec2 server simulate eventual consistency issues
<rog> fwereade, jimbaker?
<fwereade> rog, I'm trying to finish something off atm, I'll ping you when I'm free
<rog> fwereade: thanks
<niemeyer> Lunch time here..
<fwereade> rog, sorry that took so long; can I be of service?
<rog> fwereade: yes, thanks. gimme 1 minute.
<rog> fwereade: bakc
<rog> ck
<rog> fwereade: so...
<rog> fwereade: the object is to simulate the "eventual consistency" semantics of the ec2 server.
<rog> fwereade: to that end, the idea is that all operations operate on an out-of-date version of the server data.
<rog> fwereade: when a client makes a call, if it's a read-only request, we return the results from the out-of-date version.
<rog> fwereade: if it's a modification request, we allocate any unique ids (instance ids, group ids etc) from the current version. then we queue up the operation to be executed later.
<rog> fwereade: after every call, we execute one operation from the queue.
<rog> fwereade: does that sound reasonable to you?
<fwereade> rog, yes, I think so
<rog> fwereade: i can't help feeling that there might be a large bear lurking in the room somewhere
<rog> guess i can only try and see
<fwereade> rog, I'm wondering though whether it might be good to have some way of varying the behaviour -- sometimes immediate consistency, sometimes irritatingly delayed
<rog> fwereade: the idea is to allow the length of the queue to be specified when the server starts
<rog> fwereade: i don't think having random behaviour is going to be good for reproducing failed tests
<fwereade> rog, the trouble is you don't *really* want to do that *randomly*, or you're on a miserable path to unreproducible test failures
<fwereade> snap :p
<rog> fwereade: so i think we'd try all tests with "totally consistent" and "very delayed" behaviour
<rog> fwereade: one question i can't quite decide on is if there are significant tests that might fail with random consistency but neither of the above scenarios
<fwereade> rog, that's what's bugging me
<fwereade> rog, I can see a plausible route towards repeatable random tests
<jimbaker> rog, this sounds like what we do in the testing in the python code. not uniformly mind you
<jimbaker> in terms of delays
<rog> fwereade: what about concurrency?
<fwereade> rog, where we store the seed that generated the queue-frobbing and can attach that
<rog> fwereade: that assumes we generate requests deterministically.
<fwereade> rog, ok, close-enough-to-repeatable to probably be a bit easier to reproduce
<rog> fwereade: hence my question "what about concurrency"?
<fwereade> rog, quite so; it may very well be that the difference is slight
<rog> fwereade: i dunno.
<fwereade> rog, and doesn't justify the effort
<rog> fwereade: the other thing is that the above approach doesn't work if you can jump backwards and forwards in time.
<fwereade> rog, in what sense?
<rog> fwereade: because you need to keep several versions of the server state
<rog> fwereade: with this approach we just keep one version and apply deltas
<fwereade> rog, ah got you
<rog> fwereade: hmm
<rog> fwereade: although
<rog> fwereade: if delta application is deterministic
<rog> fwereade: then we can keep several versions and apply deltas to each of them as appropriate
<fwereade> rog, sorry, I think I'm lost...
<rog> fwereade: we could have several versions of the state, each representing the state at some point within the queue of pending operations
<rog> fwereade: as deltas move through the queue, they get applied to each state in turn. or maybe not in turn... to simulate the random ordering
<rog> fwereade: assuming s1+delta1+delta2 == s1+delta2+delta1 it should be ok
<fwereade> rog, yes, I understand that bit; ah, yes, ok, we can have a separate queue of operations for each... er, time-slice of the server
<rog> fwereade: unfortunately that last isn't quite true, although it is for most things AFAICS
<fwereade> rog, thinking more though; it might be good to propose it with just the discussed boundary-condition checks, which will be useful if not complete
<rog> fwereade: for instance, if the user does AddSecurityGroupAuth followed by RevokeSecurityGroupAuth, what's the result if the ops get reordered?
<fwereade> rog, finding some happy medium between randomness and repeatability can wait
<fwereade> rog, I have no idea, and that worries me
<rog> fwereade: yeah, i think so. and that probably makes it easier to do something more sophisticated later on if we deem it useful
<rog> fwereade: i *wish* there was some documentation on what semantics you can expect from ec2
<fwereade> rog, hopefully
<rog> fwereade: i can't find anything at all. even discussions.
<rog> fwereade: (which i find hard to believe - surely people encounter this stuff all the time?)
<fwereade> rog, I think the semantics are "you'll get what you're given, and you'll like it"
<jimbaker> rog, maybe take a look at http://www.allthingsdistributed.com/ ?
<jimbaker> also there is some docs on expected semantics for s3, fwiw
<rog> jimbaker: did you have any particular blog post in mind?
<fwereade> rog, heh, what if it's just that it's a *really* rare and unreproducible occurrence, so nobody ever hears about it or quite believes it when it happens?
<rog> fwereade: it's not rare!
 * fwereade dons tinfoil hat
<jimbaker> rog, unfortunately no, but it is the sort of thing werner discusses on his blog
<rog> fwereade: it happens a lot of the time in my tests
<rog> jimbaker: ok, thanks.
<fwereade> rog, ah, ok, I didn't realise
<rog> fwereade: otherwise i don't think i'd've know
<rog> n
<rog> fwereade: one minor comment on https://codereview.appspot.com/5672067/
<fwereade> rog, not convinced by that; how about a "checkedClock" (or something) field on the type, as a compromise?
<rog> fwereade: i'm not sure that's right. if the file did not at first exist, you never need to check the clock.
<fwereade> rog, hm, good point
<fwereade> rog, Idon;t really like the idea of threading it through all those calls though :/
<rog> fwereade: i think that the calls in Alive and AliveW are in the unique position of knowing that the clock needs to be checked, hence my suggestion.
<rog> fwereade: it's only two levels...
 * fwereade looks at the code again
<fwereade> rog, yeah, it turns out ok
<rog> fwereade: cool
<fwereade> rog, how about calling setAlive setState instead? it now always sets both .alive and .timeout
 * rog has a look
<rog> fwereade: seems reasonable. (although i think it always has set both alive and timeout)
<fwereade> rog, it went through a brief recent incarnation in which it didn't even bother to read the timeout more than once
<rog> fwereade: ah
<fwereade> rog, changing it back made the name change seem like a good idea
<rog> fwereade: yeah, i think setState is a better name for what it does
<fwereade> rog, cheers, reproposed ;)
<fwereade> rog, EOD I'm afraid; if you have a spare moment I would appreciate it if you would have a little look at https://codereview.appspot.com/5695082 and let me know the perceived crackfulness of the general idea
<rog> fwereade: cool!
<rog> fwereade: yes, i'll do that
<fwereade> rog, er, expect another one in a sec, I appear to have ballsed up a bit
<rog> fwereade: looks better with firstTime, to my mind - that logic becomes a bit more obvious.
<rog> fwereade: thanks for changing it.
<fwereade> rog, a pleasure :)
<fwereade> rog, huh, no I didn't balls it up; somehow I was trying to link against something stale, I guess
<fwereade> rog, so don't expect an update soon
<rog> fwereade: ok. i'll try to ignore the extraneous diffs
<rog> fwereade: where's the implementation of relation-get etc again?
<fwereade> rog, in python?
 * fwereade racks brains
<fwereade> rog, juju.hooks.commands
<rog> fwereade: no, that wasn't the question.
<rog> fwereade: i was wondering what files the new code for " Rough proposal for implementation of relation-get and similar commands." was in
<rog> fwereade: presuming it's somewhere in that CL
<fwereade> rog, ah sorry: none of them are *implemented* yet
<rog> fwereade: server/protocol looks new
<fwereade> rog, but it provides a mechanism by which a command like relation-get can get the unit agent (which knows all the appropriate state) to execute the command for it and pipe back the results
<rog> fwereade: yeah, that's what i was looking for. that's in cmd/server, right?
<fwereade> rog, yeah
<rog> fwereade: instant initial reaction: why not use the rpc package?
<rog> fwereade: rather than doing our own marshalling etc
<fwereade> rog, huh, because I ballsed up on due diligence :p
<rog> fwereade: i think this code can be really really small
<fwereade> rog, then that's doubly awesome
<fwereade> rog, it was very instructive writing it all but less code is always better than more code ;)
<rog> fwereade: the unix socket stuff will stay :-)
<fwereade> rog, cool
<rog> fwereade: but yeah, i think a few methods exported on a relation type and passed to rpc.Server.Register will probably do the job
<rog> fwereade: the only thing that won't give you will be commands that stream.
<rog> fwereade: are there any like that?
<fwereade> fwereade, some certainly dump data back on stdout
<fwereade> er, *rog*, ^^
<rog> fwereade: lots and lots of data? or don't-care-too-much-if-it's-all-in-memory data?
<fwereade> rog, and in general I'd expect/hope that --verbose and --debug should work (and thereby potentially generate monster stderrs too)
<fwereade> rog, not sure how big it could get
<rog> fwereade: i've an idea for how that could work ok with rpc
<fwereade> rog, well, we could do exactly the same in terms of how we pipe stuff back
<rog> fwereade: yeah
<fwereade> rog, the streams feel to me like a good thing
<rog> fwereade: if you're around for a minute or so more, i'll paste a little example
<fwereade> rog, please do
<rog> fwereade: http://paste.ubuntu.com/860798/
<rog> fwereade: slightly contorted by the necessary form of rpc methods
<rog> fwereade: but the idea is that you call New which gives you a handle on a running command. then you can call other methods to get info on that command, including reading from its output streams
<rog> fwereade: Cmd is the type that would be registered as an rpc handler
<rog> fwereade: maybe Cmd.Result might be better named Cmd.Wait
<rog> fwereade: and if we were concerned about malicious clients, we could put a random capability string in the Running id.
<fwereade> rog, seems less clear to me but that's probably a matter of familiarity; I shall meditate upon it
<rog> fwereade: i'll quickly sketch an implementation
<rog> fwereade: i think it'll be pretty small.
<fwereade> rog, don't rush, it has been noticed by others that it's my eod
<rog> fwereade: no probs.
<rog> fwereade: i've only got 20 minutes myself...
<rog> fwereade: see ya tomorrow morning
<fwereade> rog, and you :)
<andrewsmedina> niemeyer: hi
<niemeyer> andrewsmedina: yo
<andrewsmedina> niemeyer: for port this test (http://dpaste.org/9MrTY/) I need create another dummy charm?
<niemeyer> andrewsmedina: You can copy and change an existing one.. some tests already have the needed utilities to do that easily
<niemeyer> andrewsmedina: Hold on.. I'll find an example
<andrewsmedina> niemeyer: dont have yet in Go a equivalent for change_sample
<niemeyer> andrewsmedina: We actually do
<niemeyer> andrewsmedina: Check charm_test.go
<niemeyer> andrewsmedina: If you have a reader r, you can do something like
<niemeyer> hackYaml := ReadYaml(r)
<niemeyer> hackYaml["subordiate"] = true
<niemeyer> newr := hackYaml.Reader()
<andrewsmedina> niemeyer: I will try this
<niemeyer> andrewsmedina: It's not as practical as change_sample yet, but feel free to implement a function so that it is
<niemeyer> andrewsmedina: For example: changeSample(func(yh *yamlHacker) { yh["subordinate"] = true })
<andrewsmedina> niemeyer: is missing only this use case
<niemeyer> Booom!
<niemeyer> Summer storm..
<andrewsmedina> niemeyer: can you help me?
<niemeyer> andrewsmedina: Maybe.. :) What's up?
<andrewsmedina> niemeyer: All tests are ok
<andrewsmedina> niemeyer: but
<andrewsmedina> niemeyer: in python (http://dpaste.org/9MrTY/) when a charm is not a proper subordinate, is returned the charm path in the excetion
<hazmat> andrewsmedina, and?
<hazmat> this is problematic because?
<andrewsmedina> hazmat: I dont have path in go implementation
<niemeyer> andrewsmedina: Sounds fine.. just don't return it
<andrewsmedina> niemeyer: I return a simple error message?
<niemeyer> andrewsmedina: Simplicity FTW
<andrewsmedina> niemeyer: I will send the commit in minutes :p
<niemeyer> andrewsmedina: Superb :)
<andrewsmedina> niemeyer: sorry for my noob questions
<niemeyer> andrewsmedina: Totally fine
<andrewsmedina> Im a noob in go =/
<niemeyer> andrewsmedina: Not to worry.. there are a handful of people only that know Go for more than a couple of years, so you're not too far behind :)
#juju-dev 2012-02-29
<andrewsmedina> its done
<andrewsmedina> niemeyer, hazmat https://codereview.appspot.com/5702055
<niemeyer> andrewsmedina: Woohay!
<andrewsmedina> niemeyer: :)
<niemeyer> andrewsmedina: You should have a review by the morning tomorrow
<andrewsmedina> niemeyer: ok :D
<andrewsmedina> niemeyer: I will continue to work on local provider (lxc)
<hazmat> andrewsmedina, nice
<hazmat> i thought that gofmt removed formatting concerns
<hazmat> besides subordinates i see alot of formatting/spacing diffs in there
<andrewsmedina> hazmat: how I update a issue with other patch using lbox ?
<hazmat> andrewsmedina, just lbox propose -cr  again.. it will update in place
<andrewsmedina> hazmat: ok, I will fix the format
<niemeyer> andrewsmedina: Just run "go fmt"
<niemeyer> andrewsmedina: It will auto-format for you
<andrewsmedina> niemeyer: I know :p
<andrewsmedina> hazmat, niemeyer done :D https://codereview.appspot.com/5702055/
<hazmat> andrewsmedina, thanks much nicer
<niemeyer> andrewsmedina: How long have you been coding with Go?
<andrewsmedina> niemeyer: since carnaval
<andrewsmedina> niemeyer: why?
<niemeyer> andrewsmedina: Just happy to see how fast you've produced a nice change set for integration
<andrewsmedina> niemeyer: I contribute with several projects
<niemeyer> andrewsmedina: From a quick look over it, looks very reasonable
<andrewsmedina> niemeyer: Most projects that use python
<andrewsmedina> niemeyer: I want do more for this project
<niemeyer> andrewsmedina: From what I can see so far, you're very welcome to stay
<niemeyer> andrewsmedina: make sure you're subscribed to the mailing list too, so that you can also participate in design decisions etc
<niemeyer> Woohay.. just cut down the store tests timing by half.. was overlooking a silly setup/teardown cycle
<andrewsmedina> niemeyer: If you have more small issues to let me know
<niemeyer> andrewsmedina: Thanks, they'll certainly show up, and I'll make sure to ping you to see if you're interested
<andrewsmedina> niemeyer: I'm waiting for you :D
<andrewsmedina> niemeyer: Now, I will try install c client for zookeper on mac os ou centos
<andrewsmedina> =/
<niemeyer> andrewsmedina: Hmmm.. there's a chance that gozk can actually work if you compile the C client of gozk from source
<niemeyer> Sorry
<niemeyer> andrewsmedina: Hmmm.. there's a chance that gozk can actually work if you compile the C client of *zookeeper* from source
<niemeyer> andrewsmedina: It's not too painful..
<andrewsmedina> niemeyer: I'm not found the c client .tar.gz
<niemeyer> andrewsmedina: It's the same source
<niemeyer> andrewsmedina: The C client lives under src/c
<niemeyer> andrewsmedina: ./configure && make
<andrewsmedina> niemeyer: I know, I found this in svn repo, but not in tar.gz package
<andrewsmedina> I will try again
<andrewsmedina> niemeyer: you were right
<niemeyer> andrewsmedina: You'll have to tweak the source of gozk so that the CFLAGS line in zk.go has something like -I/path/to/your/src/c/include
<niemeyer> andrewsmedina: We should have a default entry like that pointing to /usr/local/include so that you could just make install it
<niemeyer> andrewsmedina: Not there yet, though
<andrewsmedina> niemeyer: your project lpad, it's broken with the last weekly version
<andrewsmedina> niemeyer: because contains two packages
<niemeyer> andrewsmedina: I've already fixed it, but it's lacking the tag I suppose
<niemeyer> andrewsmedina: Let me tag it
<niemeyer> andrewsmedina: Please try again
<andrewsmedina> I have fixed this in my machine :p
<andrewsmedina> removing the example.go
<niemeyer> andrewsmedina: That works too :)
<andrewsmedina> niemeyer: Can I change zk.go to point to /usr/local/include ?
<niemeyer> andrewsmedina: Yeah, we can certainly add that in the stock package
<niemeyer> andrewsmedina: Just add it at the end, please
<niemeyer> Okay.. I really ought to have some sleep now
<niemeyer> Have a good night all
<niemeyer> Or at least those that approach their bed time ;
<niemeyer> )
<fwereade> niemeyer, hazmat: will you be free for a chat about constraints in ~90 minutes? (I need to collect Laura and eat lunch pretty soon)
<niemeyer> fwereade: I will, but I believe hazmat must be asleep by now
<niemeyer> fwereade: Morning, btw
<fwereade> niemeyer, heyhey :)
<fwereade> niemeyer, ah, ok, he was up late? I often seem to see him come on at about this time
<niemeyer> fwereade: Ah, maybe he's changed his working hours
<niemeyer> fwereade: I was assuming that just based on his TZ
<fwereade> niemeyer, I couldn't swear that's been normal recently, though, it's more a general impression that I developed at some stage
<rog> fwereade: so... i did a test implementation of the relation-get thing the way i suggested, and it seemed over complex
<fwereade> rog, yeah, I peered through the docs a little and wasn't sure it'd save me much
<rog> fwereade: but...
<rog> fwereade: i thought this was better: http://paste.ubuntu.com/861798/
<rog> fwereade: i think the streaming stuff is overkill
<rog> fwereade: for the primitives we're implementing, i don't think there's any need to see output as it's produced.
<rog> fwereade: the client side would look like this: http://paste.ubuntu.com/861802/
<fwereade_> rog, I'll think about that, but I have to run to collect laura -- sorry
<rog> fwereade_: np
<rog> lunch
<andrewsmedina> morning
<andrewsmedina> niemeyer: https://codereview.appspot.com/5702055/
<rog> fwereade_: any thoughts about that suggestion?
<fwereade_> rog, well, it'd surely work, but it still feels more correct to stream the output back, and I don't really think the setup is that onerous
<rog> fwereade_: won't this always be used in a scripting situation where it won't make any difference?
<rog> fwereade_: apart from anything else it means that we can rely on a well tested RPC framework rather than rolling our own
<fwereade_> rog, well, it seems that it won;t make any difference only if we guarantee that output never grows too irritatingly large to prefer streaming over copying
<fwereade_> rog, I think the protocol is independent of the streaming question
<fwereade_> rog, we can still stream stuff back with rpc
<rog> fwereade_: yeah, but it's a fair amount of complexity. i'm questioning whether that complexity is worth it for some log messages.
<rog> fwereade_: the streaming is what makes things more complex, AFAICS
<fwereade_> rog, well,and the important output too
<rog> fwereade_: but the output is relatively small, right?
<rog> fwereade_: no more than 1MB, say
<fwereade_> rog, indeed, probably not
<rog> fwereade_: (do people put enormous things in relations?)
<fwereade_> rog, and, indeed, the stderr output will probably not be ruinously big either
<rog> fwereade_: i guess i'm just suggesting an "as simple as possible" approach. the client API looked identical for the streaming RPC version i did
<fwereade_> rog, mainly it just feels like packing complete output streams into strings is the Wrong Thing To Do
<fwereade_> rog, and I strongly favour implementing all our commands as Commands
<rog> fwereade_: it's trivial to make it so there's a single entry that invokes the correct command if that's what we want
<rog> fwereade_: (actually i had that before, but thought it might be better with several entry points)
<fwereade_> rog, ok, I think we agree here, there's no sense hand-rolling the protocol
<rog> fwereade_: even with multiple entry points, i don't think there's a reason we couldn't use Command
<fwereade_> rog, out point of disagreement seems to be whether stdout and stderr socket paths should be passed as part of the remote procedure call
<fwereade_> our point^^
<rog> fwereade_: yeah.
<rog> fwereade_: i think that we should just go the ultra-simple route until we encounter a command that actually produces lots of output
<rog> YAGNI...
<fwereade_> rog, most of my arguments come back to my feeling that it's truer to the nature of a stream to let it be a stream; and that I'm not convinced that it's an unreasonable burden for the codeto bear
<rog> fwereade_: if in doubt i'd delete 120 lines of code...
<rog> fwereade_: i know what you mean about streams wanting to be streams, but i don't think it's worth it here.
<fwereade_> rog, I'm not sure exactly where you're getting that number... we can certainly lose the protocol, this much is agreed
<fwereade_> rog, that it feels inelegant and lumpen to convert a stream to a []byte to send it to another process so it can output it again as a stream
<rog> fwereade_: i don't mind so much. it takes 0 lines of code to do that.
<rog> fwereade_: and it's not going to make any practical difference
<rog> fwereade_: i can't think of a way that the difference is going to be observable.
<fwereade_> rog, hm;someone running them with --debug would like to see output more-or-less as it happens, maybe?
<rog> fwereade_: BTW for reference, here's the server implementation using streaming with RPC: http://paste.ubuntu.com/861987/
<rog> fwereade_: is it possible to run them at an interactive shell prompt?
<rog> fwereade_: i thought they needed to be run within the context of a hook
<fwereade_> rog, (1) I think hook-debug might enable something like that, but that may be FUD because Idon't recall using it
<rog> fwereade_: (... and the client: http://paste.ubuntu.com/861989/)
<fwereade_> (2) I'm sure there has been talk of allowing the commands to actually work outside of the hook context, but I'm not sure where to look for it
<fwereade_> rog, or, hmm, wait; was that just getting access to relation context in non-relation hooks?
<fwereade_> rog, sorry, that one makes more sense
<rog> fwereade_: no, i think you were right: https://juju.ubuntu.com/docs/hook-debugging.html
<fwereade_> rog, cool
<rog> fwereade_: i didn't know about that
<rog> fwereade_: but i still don't think it's sufficient justification
<rog> fwereade_: all the in-hook commands are going to be short lived
<rog> fwereade_: they essentially do a single zk transaction, right?
<fwereade_> rog, I'll look through your code again, my cursory look suggested you were doing more than I was; is it that I missed significant functionality?
<rog> fwereade_: what would happen with your code if two things executed relation-get in parallel?
<fwereade_> rog, probably, yes, in the working-correctly case
<fwereade_> rog, nothing too much with a moderate amount of care taken in dealing with the different client contexts' caches
<rog> heh, most people using relation get will be doing x=$(relation-get) anyway...
<rog> fwereade_: it seemed to dial the same socket several times. i couldn't see how the different streams were separated.
<rog> fwereade_: (if there were concurrent calls)
<rog> i haven't looked too closely though.
<fwereade_> rog, ah, yes, I would appear to be on crack :/
 * rog has another look
<niemeyer> rog, fwereade_: That should be the end of the importer: https://codereview.appspot.com/5704056
<rog> fwereade_: i did really like my stream-over-RPC code, BTW. the possibility has been in my head for ages. i'll save the code. but i think it's more complexity than we need.
<fwereade_> niemeyer, cheers
<niemeyer> Will just submit a command to run that in another CL
<fwereade_> cool
<rog> niemeyer: i'll have a look
<niemeyer> fwereade_: Then, at least as far as I recall, the HTTP API we need is trivial
<niemeyer> Which means we _migth_ have it ready by tomorrow
<niemeyer> jcastro: ^
<fwereade_> niemeyer, according to my fuzzy memories, that's right
<fwereade_> niemeyer, awesome!
<jcastro> niemeyer: woo!
<rog> niemeyer: i'm not entirely happy about the trend towards multi-line error messages. i quite liked the approach taken by go/parser, where the error says "some error (and 27 more)" and the underlying error type provides a way to get all of them if desired.
<niemeyer> jcastro: This doesn't mean it will be live tomorrow, by any means :)
<niemeyer> jcastro: But you can start planning
<niemeyer> rog: That means even the first error message may not be relevant
<rog> niemeyer: all the error messages are relevant, no?
<niemeyer> rog: So we end up with "branch errors" as a message
<niemeyer> rog: Not if you strip their content :-)
<jcastro> niemeyer: yeah this will be Good Enough
<rog> niemeyer: i'm suggesting keeping the first error message encountered (and indicating that there are more)
<niemeyer> rog: and I'm saying the first error message may have multiple lines
<niemeyer> rog: Because it comes from bzr
 * rog isn't too happy about that either
<rog> niemeyer: messages are often written to log files, and it's useful that log file lines are consistently prefixed
<niemeyer> rog: Heh
<niemeyer> rog: The actual error is several orders of magnitude more interesting in a log file than its prefix
<niemeyer> rog: If you're suggesting stripping the errors from the log file to keep it pretty, that's a big no-no
<rog> niemeyer: agreed.  but prefixes are often used to extract relevant info.
<niemeyer> rog: Please let's be realisitc
<niemeyer> rog: We're not dropping the error message out of the log file.. I'm happy to have solutions, but that by itself is not one of them
<rog> niemeyer: it looks like all the errors are logged anyway
<niemeyer> rog: So what you are suggesting is ... ?
<rog> niemeyer: i'm not exactly sure. i just don't like Error() returning a multi-line error :-)
<rog> sorry
<niemeyer> rog: The only reasonable thing I can think of is to make BranchErrors string return a "one or more branches failed to be published" message from Error
<rog> niemeyer: as i said, i think the approach taken here (see ErrorList.Error) is a reasonable one: http://weekly.golang.org/src/pkg/go/scanner/errors.go
<niemeyer> rog: That doesn't work in this case for the reason I explained
<rog> niemeyer: but it won't work if some of the errors are already multi-line. perhaps bzr errors could be joined into a single line or something.
<niemeyer> rog: Heh
<niemeyer> rog: Let's stay on the reasonable side.. joining 10 lines in 1 won't improve the situation at all
<rog> bzr errors are that big?
<niemeyer> rog: Any command line tool can print an arbitrary amount of content in their standard error stream
<rog> niemeyer: and we're treating that as "the" error message. i'm not keen. (not that i see a better approach yet though)
<niemeyer> rog: Yeah, repeating that you're not keen isn't helpful.. I provided a suggestion. Does that help?
<niemeyer> rog: Do you have a better one?
<rog> niemeyer: try to work out the actual error line in the bzr output? (saving the rest for callers that want to see the whole thing)
<rog> niemeyer: perhaps just finding the first line beginning "bzr: ERROR: " would be sufficient
<niemeyer> rog: We still have to fall back in case we don't find it, and we still have to log the whole error message
<niemeyer> rog: I think I'll just stick a static error message in there for now. That solves your main concern, and doesn't really change the overall behavior in any way.
<niemeyer> We can improve that later as we find the need to
<niemeyer> rog: Sounds good?
<rog> niemeyer: yeah, it's better.
<niemeyer> Cool
<rog> niemeyer: was just looking in the bzr source to see how errors are dealt with
<niemeyer> rog: It doesn't matter, really.. whatever heuristics we put to find an error message is still heuristics, and needs to have a fallback
<rog> niemeyer: yeah, but the fallback for bzr could be easy - just use the first line regardless.
<niemeyer> rog: It's human oriented text.. not a protocol, unfortunately
<rog> niemeyer: (or all the lines joined, or whatever)
<rog> niemeyer: but it's rare enough that it wouldn't matter, i think.
<rog> niemeyer: it seems to me that the first line has all the relevant info - the rest is just suggestions like "However, you can get around this by doing this"
<niemeyer> rog: See above..
<niemeyer> rog: It's not clear what you're trying to achieve.
<niemeyer> rog: We'll be logging the whole message to aid in solving problems..
<niemeyer> rog: What's the problem you're trying to solve?
<rog> niemeyer: sometimes verbosity can hide problems. to my mind, looking at the possible bzr errors, (http://paste.ubuntu.com/862070/) they look like Go errors. that's what the first line would give you. but i guess it's possible you can get several errors in a row.
<niemeyer> rog: There are several errors in there that have \n in them.. what are you trying to show me?
<rog> niemeyer: hmm. yeah, there are some problems.
<rog>     _fmt = "%(target)s\n" \
<rog>             "is not compatible with\n" \
<rog> bah humbug
<rog> oh well
<niemeyer> I'll have some quick lunch.. back in a bit
<rog> just strip out \n...
<rog> niemeyer: ok
<rog> niemeyer: enjoy
<niemeyer> rog: Stripping out \n == huge message == what is rog trying to do?
 * niemeyer steps out for real
<rog> niemeyer: yeah, it's a difficult call. but on balance i think i'd prefer an error message that conformed to the usual one-line convention, even if the one line was very long, to one that didn't.
<hazmat> do we log this channel?
<hazmat> jcastro, i thought we had that setup.. but i don't see the logger/mup around
<rog> hazmat: if we don't, we should...
<hazmat> i don't really have any insight into getting _mup_ on here.. niemeyer ?
<jcastro> hazmat: we did, it must have gone missing, I'll check
<niemeyer> rog: I'd rather have something that is readable instead. Let's keep it as-is until we find a better scheme.
<rog> niemeyer: fair enough.
<fwereade__> bother it's 7, bbl if I can
<niemeyer> The world is falling!
<niemeyer> I mean.. it's raining..
<niemeyer> The volume of water falling here is amazing..
<jimbaker> niemeyer, sounds like the snowstorms we sometimes get here. best appreciated when it comes suddenly during a 22 deg C day in the spring, while wearing shorts
<rog> i like rainstorms
<rog> i'm off for the night, BTW. i smell spag boll!
<rog> see ya tomorrow
<niemeyer> rog: Cheers! Enjoy!
<andrewsmedina> why Go port dont have providers module?
<niemeyer_> andrewsmedina: It's called environs
<niemeyer> andrewsmedina: After some back and forth we ended up renaming it
<niemeyer> andrewsmedina: Well.. consolidating might be a better way to put it
<niemeyer> andrewsmedina: Python has both environments and providers
<niemeyer> andrewsmedina: Go has only environments
<andrewsmedina> niemeyer: hmm
<andrewsmedina> niemeyer: I updated gozk to use the last gocheck version
<niemeyer> andrewsmedina: Ah, nice.. do you want to propose it?
<andrewsmedina> niemeyer: I'm at work now
<niemeyer> andrewsmedina: Ah, super
<andrewsmedina> niemeyer: tonight I propose
<niemeyer> andrewsmedina: Super
<niemeyer> andrewsmedina: What's you daily project, btw?
<andrewsmedina> niemeyer: I work at globo.com
<niemeyer> andrewsmedina: Ah, right.. what project there?
<niemeyer> andrewsmedina: (if that's public info)
<andrewsmedina> niemeyer: now, I'm in working in a private PaaS using Openstack + juju + cloudfoundry
<niemeyer> andrewsmedina: Hah, nice.. I heard about those. ;-)
<andrewsmedina> niemeyer: I work with flaviamissi
<flaviamissi> :)
<niemeyer> flaviamissi: Buenas :)
<andrewsmedina> niemeyer: I met you at pyconbrasil 2007 in joenvile
<flaviamissi> niemeyer: hi!
<niemeyer> andrewsmedina: Wow.. really? My memory sucks..
<andrewsmedina> niemeyer: I'm a django guy
<niemeyer> I miss Dorneles..
<andrewsmedina> niemeyer: me too =/
<andrewsmedina> niemeyer: In 2007 I was a only brazilian django guy at pycon
<flaviamissi> andrewsmedina: y u no work?!
<flaviamissi> andrewsmedina: HAEUheauhEAhAEAE
<niemeyer> flaviamissi: Let me know if you need anything.. happy to see you guys using juju there
<andrewsmedina> flaviamissi: oO
<flaviamissi> niemeyer: sure! you'll hear a lot from us, or read... whatever
<hazmat> hmm.. adding the alias expansion to the scheduler is harder than i thought, it really wants to reduce redundant events.. and the expansion is redundant.
<niemeyer> hazmat: It's the machine raising against us!
<niemeyer> Time for some outsiding.. back later
<hazmat> niemeyer, i'm thinking its time to revisit the notion that hook errors on relation events, drop the event. i'm starting to think we should keep/replay the event post resolved
<hazmat> it doesn't feel quite sane otherwise
<hazmat> sigh.. feels like there are a couple of bugs here
<hazmat> jimbaker, what's the rationale for juju do
<hazmat> on its face it seems highly suspect to me
<jimbaker> hazmat, i do have some use cases in the proposal that are derived from it
<jimbaker> hazmat, i certainly would entertain any suggestions for alternatives that enable out-of-band hook exec
<hazmat> jimbaker, your confusing the client with hooks calling other hooks
<hazmat> ie. the bugs wasn't about the user invoking arbitrary hooks
<jimbaker> hazmat, i address that in a separate section
<hazmat> k
<jimbaker> it is certainly ok with me if we don't implement. to quote, i'm not absolutely sure of anything...
<jimbaker> except perhaps the well-ordered principle ;)
<hazmat> yeah.. its not on the table.. imo.. its insane.. but i haven't finished reading.. so i'll defer discussion till then
<jimbaker> hazmat, please certainly put that feedback in the email
<jimbaker> then we can definitively capture that it's a bad idea
<hazmat> i'm just reviewing in reitveld
<jimbaker> hazmat, sure, that's a good place to review, but the high-level feedback needs to be on the mailing list
<jimbaker> otherwise juju stakeholders are unlikely to see it
<hazmat> i think you've lost most of the relevant stake holders.. outside of the first paragraph
<hazmat> the rest is effectively spec merge review
<jimbaker> hazmat, ok, i'm just trying to follow the process in https://lists.ubuntu.com/archives/juju/2011-November/000931.html
<hazmat> jimbaker, fair enough
<hazmat> jimbaker, and thanks for doing so
<jimbaker> hazmat, no
<jimbaker> problem
#juju-dev 2012-03-01
<jimbaker> hazmat, thanks for the review. just one point: in https://lists.ubuntu.com/archives/juju/2012-February/001259.html, niemeyer mentions "This is the key problem we have to fix, and it's been on our TODO since inception: commands such as relation-get and relation-set must work out of band, outside of any hooks."
<jimbaker> now it's possible this doesn't mean outside of juju machines... but juju do was formulated in response to this discussion
<rog> mornin' all
<rog> TheMue: hiya
<TheMue> rog: morning
<TheMue> lunchtime
<hazmat> jimbaker,  niemeyer only meant outside of relation hooks
<hazmat> its not sane other wise ;-)
<rog> lunch
<hazmat> jimbaker, well more specifically any of the juju hook cli api can be invoked at any time on a unit if the appropriate args are passed
<hazmat> niemeyer, oddly right after i talked up the relative bug free-ness of the scheduler i find a bug :-(
<niemeyer> hazmat: :(
<niemeyer> hazmat: Glad you found it, though
<hazmat> and another one in the invoker
<hazmat> indeed, me too
<hazmat> niemeyer, fwereade_ do you guys have time to do that g+ meeting?
<hazmat> on constraints?
<fwereade_> hazmat, sure
<niemeyer> hazmat: Oh, indeed
<niemeyer> Yep, I'm glad to have it now
<hazmat> niemeyer, fwereade_ invites out
<niemeyer> I'min
 * niemeyer observes hazmat speaking to himself
<niemeyer> ROTFL
<fwereade_> hazmat, niemeyer, noone here, retrying
<TheMue> niemeyer: could you pls take a look at  http://paste.ubuntu.com/863536/
<niemeyer> TheMue: On the call now, but what about this code?
<TheMue> niemeyer: after i created a fresh unit Resolved() has a ZNONODE, e'thing fine
<TheMue> niemeyer: then i do a SetResolved() first time => ok
<TheMue> niemeyer: then a second time => i get the right error returned
<TheMue> niemeyer: but then, when i do a Resolved() i again have a ZNONODE
<hazmat> https://code.launchpad.net/~fwereade/juju/constraint-types/+merge/85637
<TheMue> niemeyer: after the internal ZNODEEXISTS of SetResolved() i didn't expected this
<TheMue> niemeyer: aaaargh, got it, used a wrong path function internally. gna, layer 8 error! :(
<TheMue> niemeyer: yeah, that's it. once doing it right it works. next test passed
<jimbaker> hazmat, niemeyer - weekly meeting?
<hazmat> jimbaker, sounds good
<jimbaker> hazmat, cool
<hazmat> jimbaker, niemeyer, fwereade_, SpamapS, bcsaller, jcastro, TheMue, m_3  invites out
<hazmat> incidentally if anyone else wants to watch these meetings please just let me know
<jcastro> I'll be there!
<m_3> hazmat: thanks, won't try to make this week
<hazmat> m_3, no worries
<niemeyer> hazmat: Sorry
<niemeyer> hazmat: Was out for lunch
<niemeyer> hazmat: I'm in now.. is it rolling?
<hazmat> niemeyer, just waiting for you
<niemeyer_> Clearly, my network felt down just now
<niemeyer_> :/
<niemeyer_> TheMue: Did you resolve all the issues there?
<niemeyer_> TheMue: Or still need some info?
<rog> off the night. see y'all tomorrow
<TheMue> niemeyer_: everything resolved, has been a simple fault (once you found it *smile*)
<niemeyer_> TheMue: Isn't it always :)
<niemeyer_> rog: Night!
<TheMue> niemeyer: yep, in my case i simply took the wrong zk path
#juju-dev 2012-03-02
<andrewsmedina> niemeyer: good morning
<niemeyer> andrewsmedina: Morning!
<niemeyer> Morning all!
<andrewsmedina> niemeyer: Yesterday I started my work with juju local provider
<andrewsmedina> niemeyer: I started creating the lxc lib
<niemeyer> andrewsmedina: Ok, I have a very critical recommendation on this area, for everybody's sanity :)
<niemeyer> andrewsmedina: Please don't wait until you have a *ton* of code before pushing
<niemeyer> andrewsmedina: No branch is small enough..
<niemeyer> andrewsmedina: You can push even single-liners for review, and we'll be happy to review and integrate
<niemeyer> andrewsmedina: So whenever you feel you got something nice working, just push for review and we'll comment/integrate
<niemeyer> andrewsmedina: This may be half a library.. a function.. a line.. whatever.
<andrewsmedina> niemeyer: do you prefer LXC as an internal juju lib or independent lib?
<niemeyer> andrewsmedina: It's fine to have it internal for now
<niemeyer> andrewsmedina: Makes both your and our lives easier right now
<niemeyer> andrewsmedina: We can move it out eventually
<andrewsmedina> niemeyer: ok, I have started as a independent lib
<andrewsmedina> niemeyer: I put it in juju/go/lib ?
<niemeyer> andrewsmedina: I'd say juju/go/lxc for now
<niemeyer> andrewsmedina: lib is a dangerous "bag of things"
<niemeyer> andrewsmedina: The Python module is actually lib.lxc, which keeps some isolation.. but Go would make it "lib" only
<rog> niemeyer, andrewsmedina: wouldn't juju/go/environs/lxc be more appropriate?
<andrewsmedina> rog: +1 for now
<niemeyer> rog: Sounds good
<niemeyer_> Heading to lunch.. biab
<fwereade_> happy weekends all :)
<rog> fwereade_: and to you!
<niemeyer_> fwereade_: have a nice one
<niemeyer_> Hmm.. why is my IRC client only partially connected?
<niemeyer_> brb
<rog> off the the weekend. see y'all monday
<rog> s/the/for/...
<TheMue> ah, test for open port passes too. will propose it later, when i'm back from my daughters sports.
<niemeyer> bbiab
<hazmat> jcastro, any luck with mup?
<TheMue> niemeyer: so, sports of my daughter is over, has been her first softball training. done some bats too, made fun. here's my next branch for review: https://codereview.appspot.com/5727045.
<TheMue> niemeyer: i'm off for the weekend now.
<jcastro> hazmat: bah it fell of my plate, thanks for the reminder
<hazmat> niemeyer, is there a way to pass lbox the file it needs from the cli instead of getting popped  into an editor
#juju-dev 2012-03-03
<hazmat> jimbaker, thanks for the review
<jimbaker> hazmat, np, it was a very easy review to do since i was so familiar with that bit of code. nice solution!
<hazmat> jimbaker, its a transient solution..
<hazmat> jimbaker, there's some more work to be done on the scheduler
<jimbaker> hazmat, oh sure, i know you want to avoid label exp
<hazmat> jimbaker, right now its dropping events on the floor on error
<hazmat> i still want to do late expansion.. but at the point of consumption
<jimbaker> hazmat, right
<hazmat> within the scheduler... its too hard to rewire it to not reduce things.. but perhaps at the point of consumption..
<hazmat> right now the scheduler feeding into the hook execution, is destructive.. so its possible to miss events on a hook error..
<hazmat> sigh
<hazmat> much to do
<hazmat> thanks again
<jimbaker> hazmat, so reduce at consumption time?
<hazmat> jimbaker, i'm not sure yet.. i was thinking expanding inline to the scheduler run method..
<hazmat> reducing at consumption time turns it from O(1) to O(n)
<hazmat> the problem with expanding inline, is that if the join hook fails, we want the change hook queued up..
<jimbaker> hazmat, i don't think i understand your point re O(1) vs O(n)
<jimbaker> is it always going to look at every subsequent event in that case? once reduced, it's gone
<hazmat> jimbaker, when we reduce as we pickup events, we have at most 1 previous event
<hazmat> if we reduce as we feed to the executor, we can have n events
<jimbaker> hazmat, i still don't see the arg unfortunately
<jimbaker> also we are not exactly dealing with a large number of events even if this were true
<hazmat> jimbaker, its not a very good arg, the numbers here make it rather irrelevant
<jimbaker> hazmat, agreed
#juju-dev 2012-03-04
<fwereade_> niemeyer_, so, it emerges, I am on crack; sorry about that :(
<fwereade_> niemeyer_, but if you're around it would be good to discuss the direction of the whole pipeline, lest I inadvertently do something else wholly crackful tomorrow
<niemeyer_> fwereade_: Yo, just getting back from dinner
<niemeyer_> fwereade_: If you're still around, glad to sync up
#juju-dev 2013-02-25
<davecheney> ping thumper
<fwereade__> davecheney, thumper, whoops, I should sleep
<thumper> fwereade__: I guess so :)
<davecheney> thumper: are your tests still broken ?
<fwereade__> davecheney, thumper: if either of you is inclined to go on a trawl through my +activereviews I have a whole bunch and they should all be relatively easy
<davecheney> i have some suggestions that you can apply from my experiences making the tests work under Q
<thumper> davecheney: I'm running a quantal virtual box
<thumper> I've not tried today with raring
<fwereade__> davecheney, thumper: they're all in a pipeline because they're all things I need to do to connect constraints up to environs
 * fwereade__ waves and departs
<thumper> fwereade__: ok
<thumper> davecheney: do you know where lbox stores the google auth token?
<davecheney> ~/.lpad_oauth
<thumper> ta
<thumper> davecheney: it seems that a whole bunch of ubuntu pastebins were deleted over the weekend
<thumper> no idea why
<thumper> davecheney: also, ~/.lpad_oauth seems to only be the launchpad credentials
<thumper> davecheney: I deleted it and tried lbox propose
<davecheney> thumper: good point
<thumper> davecheney: but it used the google credentials I was trying to change
<davecheney> let me look again
<davecheney> thumper: ~/.goetveld_*
<thumper> davecheney: ta
<davecheney> one per host
<davecheney> should only be one
 * thumper nods
 * thumper deletes it
<thumper> and tries again
<thumper> wow: error: Failed to load data for project "juju-core": use of closed network connection
<thumper> tried again... and it does something
<davecheney> yup, nobody is sure if that is LP, or something weird in the go http client
<davecheney> 2013/02/25 11:28:41 JUJU environs: searching for tools compatible with version: 1.9.10-quantal-amd64
<davecheney> 2013/02/25 11:28:45 JUJU juju bootstrap command failed: cannot start bootstrap instance: cannot allocate a public IP as needed
<davecheney> and the public IP shortage continues to make it impossible to test canonistack
<thumper> davecheney: I'm tempted to just leave the raring test issues until atlanta, as I expect the round-tripping will be a lot faster
<davecheney> thumper: i'll propse a branch
<davecheney> i know most of the places that are broke
<thumper> oh, ok
<thumper> I am happy to test
<davecheney> from memory it is the test mocks
<davecheney> /s/mock/fixtures
<davecheney>         <h1>Please try again</h1>
<davecheney>         <p>
<davecheney>           Sorry, there was a problem connecting to the Launchpad server.
<davecheney>         </p>
<davecheney>         <p>
<davecheney>           Try reloading this page in a minute or two.
<davecheney>           If the problem persists, let us know in
<davecheney>           <a href="irc://chat.freenode.net/#launchpad"
<davecheney>           >the #launchpad IRC channel on Freenode</a>.
<davecheney>         </p>
<davecheney>         <p>Thanks for your patience.</p>
<davecheney> love this
<davecheney> thumper: Proposal: https://code.launchpad.net/~dave-cheney/juju-core/097-environs-raring-fixtures/+merge/150254
<davecheney> Rietveld: https://codereview.appspot.com/7380047
<thumper> davecheney: what's with the 097 branch prefix?
<davecheney> dunno, just something we all started doing
<davecheney> personally, i got lost in all the open branchs I had
<davecheney> numbering them at least let me know where they were temporarlly
<thumper> davecheney: hmm, still fails a lot, I'll pastebin the errors
<davecheney> ta
<davecheney> gonna have to do this blind, i'm not upgrading to raring
<thumper> :)
<davecheney> sorry, i need my machine to work
<thumper> davecheney: http://paste.ubuntu.com/5563524/
<thumper> davecheney: I've managed to keep working using a quantal VM I had lying around :)
<davecheney> you need to do the git dance
<davecheney> arguably we should pass a faux gitconfig
<thumper> I have done that...
<davecheney> dance harder, monkey boy
<thumper> how to I get git to tell me what it has configured for user and email?
<davecheney> cat ~/.gotconfig
<davecheney> cat ~/.gitconfig
<thumper> $ cat ~/.gitconfig
<thumper> [user]
<thumper> 	email = tim@penhey.net
<thumper> 	name = Tim Penhey
<thumper> and it still fails
<davecheney> le sigh
<thumper> so I'm wondering what else has changed
<davecheney> either way, the test shouldn't assumed you've done the git dance
<thumper> agree there 100%
<davecheney> thumper: am fixing now
<davecheney> can you be a sport and raise an issue
<thumper> davecheney: for juju-core?
<davecheney> sure
<thumper> for the entire test failure, or just the git dance?
<davecheney> either
<thumper> sure
<davecheney> raise as many or as few as you like
<thumper> the tests pass with quantal
<thumper> and I hadn't done the git dance there (at least I don't think I had)
<thumper> or if I had, something else has changed between quantal and raring about where git looks
<davecheney> yeah, they didn't used too, which is why i'm wary of upgrading to raring
 * thumper files a bug about tests failing on raring
<davecheney> ok, raise an issue about the git parts failing
<davecheney> that is the biggest part of the failure atm
<thumper> hmm...
<thumper> filed bug 1132585 just now
<_mup_> Bug #1132585: Tests fail on raring <juju-core:New> < https://launchpad.net/bugs/1132585 >
<davecheney> ta muchly
<thumper> davecheney: boo...
<thumper> I thought I was going to be so clever
<thumper> but go didn't like it
<thumper> I was thinking I'd be able to inject a couple of methods into the cmd.Context function set from a testing module
<thumper> but it ddn't work
<thumper> was wanting something like:  func (c *cmd.Context) StdoutString() string
<thumper> but go said no
 * thumper decides to use testing.stdout(c *cmd.Context) instead
<thumper> with a capital S
<thumper> I think that is nicer than bufferString(c.Stdout)
<thumper> testing.Stdout(c) instead
<thumper> davecheney: what do you think?
 * davecheney doesn't really follow
<davecheney> paste ?
<thumper> davecheney: the guts of it is: we have two identical bufferString implementations
<thumper> and I was wanting to not
<thumper> also considered changing the names somewhat
<thumper> as I thought it read better
<thumper> am I being too anal?
 * davecheney doesn't really follow, has three people talking to him at the moment
<thumper> :)
 * davecheney is confused, i've hacked the uniter tests to supply a completely impossible value for GIT_CONFIG, and the tests still pass
 * thumper shelves the change for an anal day
<davecheney> u gonna submit your cmd aliases branch, or what ?
<thumper> I did
<thumper> I thought I did it last week
<thumper> but for some reason it didn't go through
<thumper> fixed and resubmitted today
<thumper> ugh
<thumper> gnuflag FTL
 * thumper realises that a bunch of refactoring wasn't needed
 * thumper relocates
<davecheney> thumper: i can't figure it out, i've removed my own .gitconfig and the tests still pass
<davecheney> thumper: def a version change for git in raring
<davecheney> https://launchpad.net/ubuntu/+source/git
<davecheney> NFI what has changed
<davecheney> can you post the source for goroutine 10 [select]:
<davecheney> github.com/wharf/tuplespace.(*TupleSpaceImpl).run(0xc20015f000) /Users/alec/.go/src/github.com/wharf/tuplespace/tuplespace.go:164 +0xb88
<davecheney> created by github.com/wharf/tuplespace.NewTupleSpaceImpl /Users/alec/.go/src/github.com/wharf/tuplespace/tuplespace.go:58 +0x142 ?
<jam> wallyworld_: poke
<wallyworld_> hi
<wallyworld_> mumble?
<jam> yep
<jam> just got on
<dimitern> fwereade__: ping
<rogpeppe> dimitern, fwereade__: morning!
<dimitern> rogpeppe: morning!
<dimitern> rogpeppe: how was your holiday?
<rogpeppe> dimitern: very good, thanks. nice weather, made it to the top of a few hills, had some nice food.
<dimitern> rogpeppe: cool :)
<jam> fwereade__, rogpeppe: Maybe one of you guys know. How do you compile just the test binary? I want to profile it, and I can run "go test -cpuprofile" but "go tool pprof" needs the build binary as a reference to interpret the profile output
<rogpeppe> jam: hiya
<jam> But I can't find a flag for "build just the test binary"
<rogpeppe> jam: go test -c
<jam> rogpeppe: anyway to actually find the documentation for that?
<rogpeppe> jam: go help test
<jam> go help testflag doesn't seem to have it
<rogpeppe> jam: testflag gives help on the flags for the test binary itself
<jam> rogpeppe: there are 4-different ways to get help, and I missed that one... :(
<jam> go test -h no good
<jam> go help
<jam> go help testflag
<jam> grep around online for a while
<jam> rogpeppe: thanks for at least pointing it to me. I really expected to find it somewhere else
<rogpeppe> jam: go help <command> should be your first stop
<rogpeppe> jam: the testflag documentation is unusual
<rogpeppe> jam: because it's not really documentation on a go subcommand
<rogpeppe> jam: but it is referred to by the go test help
<rogpeppe> jam: (how else did you know about testflag?)
<jam> rogpeppe: well 'go <command> -h' is my natural first stop, but that ==> 'go help' which is, unhelpful IMO
<jam> why would 'go help <subcommand>' not match 'go <subcommand> -h'
<jam> rogpeppe: note that "go tool command -h" *is* the way to get help for individual commands as part of tools.
<rogpeppe> jam: i dunno. but to be fair that (and go help) both say "Use "go help [command]" for more information about a command."
<jam> Though "go help tool" *doesn't* show you what tools are available.
<rogpeppe> jam: they might well accept a patch making go command -h work
<jam> rogpeppe: and "go tool -h" also == "go help tool" which is a bit inconsistent.
<jam> rogpeppe: as is 'go build -h'
<jam> (I'm not planning on trying all of them, though)
<rogpeppe> jam: oh yes, so it is
<rogpeppe> jam: that's definitely an inconsistency i'd never noticed
<rogpeppe> jam: (because i've always used "go help x" - as i do in bzr and hg etc)
<jam> rogpeppe: also, there is no way to get the flags for the test command, you have to do some weird invocation of "go test -invalidflag" and then the binary fails and reports its options
<rogpeppe> jam: (but not juju!)
<jam> though those *don't* include the ones to 'go test' itself, because it is a different binary that interprets them.
<rogpeppe> jam: go help testflag, no?
<jam> rogpeppe: And I've generally always used "bzr command -h" :)
<rogpeppe> jam: ah, except not quite
<jam> rogpeppe: go help testflag doesn't do the -gocheck.* etc.
<jam> I tried reporting an issue on it
<jam> that there was no way to get the flags for the test suite
<jam> and it was sort of punted.
<rogpeppe> jam: you might be able to do "go test . -help"
<jam> rogpeppe: nope, that '-help' gets interpreted by 'go test' and just get 'go help' output
<rogpeppe> jam: yeah, that seems wrong
<jam> rogpeppe: anyway thanks, -c helped me get what I wanted, and I can use the 'go help foo' style
<rogpeppe> jam: np
<rogpeppe> jam: it'd be worth raising an issue i think. now's the time if we want it fixed by go 1.1
<jam> rogpeppe: care to raise it? Might get more attention from you or dave
<rogpeppe> jam: i'd appreciate a review of https://codereview.appspot.com/7390043 if you have some time at some point, BTW.
<rogpeppe> jam: ok
<rogpeppe> jam: FWIW, go test is the *only* subcommand for which -h doesn't work
<rogpeppe> jam: it's probably something to do with the fact that it mixes flags between top level and compiled-binary level
<TheMue> Morning all.
<dimitern> TheMue: morning
<fwereade__> TheMue, dimitern, rogpeppe, jam: mornings
<rogpeppe> fwereade__: yo!
<rogpeppe> fwereade__: i'm angling for reviews of https://codereview.appspot.com/7390043, but you're probably aware of that :-)
<dimitern> fwereade__, jam: morning
<dimitern> mgz: hey
<mgz> hey dimitern
<fwereade__> rogpeppe, just sent a slightly bewildered one :)
<rogpeppe> fwereade__: ok
<fwereade__> rogpeppe, can you think of any reason for the ec2 tests to depend on the dummy provider?
<rogpeppe> fwereade__: i don't *think* so
<rogpeppe> fwereade__: do they?
<fwereade__> rogpeppe, can't run them without fixing the dummy provider, it seems, but I can't quite figure out the connection
<rogpeppe> fwereade__: ah, i know
<rogpeppe> fwereade__: the tests build the tools when testing PutTools
<fwereade__> rogpeppe, oh, ffs, ofc
<rogpeppe> fwereade__: and i guess the tools depend... hmm, they shouldn't
<fwereade__> rogpeppe, ah!
<fwereade__> rogpeppe, juju/testing uses the dummy provider
<rogpeppe> fwereade__: ah, of course
<fwereade__> rogpeppe, btw: why does StartInstance take apiinfo/stateinfo?
 * rogpeppe tries to remember
<fwereade__> rogpeppe, fwiw I'm also planning to drop the tools param
<rogpeppe> fwereade__: oh yes, the idea was that the new instance needs to know how to contact the state server
<fwereade__> rogpeppe, yeah, but the environment already knows that
<fwereade__> rogpeppe, the only thing that's actually needed is the password
<fwereade__> rogpeppe, (btw are passwords for stateinfos or just for apiinfos? it's not clear why we save them for both when bootstrapping and only for state when startinstanceing)
<rogpeppe> fwereade__: i'm not sure what you're referring to by that last sentence
<fwereade__> rogpeppe, when you start a machine with a api info, what uses that API info?
<rogpeppe> fwereade__: i think i was trying to avoid making the assumption that the environment always knows where the state server is.
<fwereade__> rogpeppe, why?
<fwereade__> rogpeppe, that's the one core thing we depend on the environment being able to do for us ;p
<rogpeppe> fwereade__: we might want to store the current set of state server addresses in the state itself.
<rogpeppe> fwereade__: in fact for the state server (as opposed to the API server) i think that's going to be the case
<rogpeppe> fwereade__: hmm, but actually
<rogpeppe> fwereade__: we're going to be able to drop state.Info eventually
<rogpeppe> fwereade__: when you start a machine with an api info, the api info is used by the agents on that machine to connect to the API server.
<rogpeppe> fwereade__: one advantage of passing a state info into StartInstance is that the environ doesn't have to query the bucket and resolve the DNS name each time. but perhaps that's a trivial cost.
<rogpeppe> fwereade__: and it could be cached.
<jam> rogpeppe: so I'd like to ask a bit about possibly caching the 'bundleTools' output during the test suite. Right now it takes about 2.5s for it to compile jujud and then tarball.gz it, and it happens far more times than I would expect.
<jam> (eg, "BootstrapMultiple" test actually rebuilds the tools at least 2 times for that one test, but it also happens between tests.)
<rogpeppe> jam: yeah, it would be nice to get rid of that overhead
<dimitern> fwereade__: I think waitHooks{} is not working correctly
<dimitern> fwereade__: or maybe I'm not using it right
<rogpeppe> jam: i could never think of a sufficiently clean way of doing it, but i didn't think about it that hard.
<fwereade__> rogpeppe, ok, long-term, I agree that the state info will probably be stored elsewhere and distributed separately, but for now it seems that the state info is the one we use and the api info is just kinda hanging on alongside without any agent actually using it yet -- is this correct?
<fwereade__> dimitern, hmm, ok... would you paste me your output again and I'll see if any inspiration strikes?
<rogpeppe> fwereade__: agents will use it very soon. they do actually connect to it, i believe, currently, even if they don't actually use it.
<rogpeppe> fwereade__: actually... maybe they won't use it so soon.
<rogpeppe> fwereade__: hmm.
<dimitern> fwereade__: I'm augmenting the logging to see what's going on, just a moment
<rogpeppe> fwereade__: yes, the API info isn't currently used. but it will be - it's a placeholder for what's to come.
<dimitern> fwereade__: I found it!
 * fwereade__ cheers at dimitern
<fwereade__> dimitern, go on
<dimitern> fwereade__: matchLogHooks does not accept u/0 db2:0
<fwereade__> dimitern, grar, sorry
<dimitern> fwereade__:  	`u/0(| [a-z-]+:[0-9]+)` that's the hook pattern
<fwereade__> dimitern, yeah, all  makes sense
<dimitern> fwereade__: I'll change it to `u/0(| [a-z0-9-]+:[0-9]+)`
<fwereade__> dimitern, sgtm
<dimitern> fwereade__: now the db2-relation-joined mysql/0 db2:0 is matched, but still somehow ignored
<fwereade__> dimitern, discraded by test id badge checking?
<dimitern> fwereade__: still checking..
<dimitern> fwereade__: :) the other regexp - donePattern needs changing as well
<fwereade__> dimitern, ah, ok
<dimitern> fwereade__: now it works :) yay!
<fwereade__> dimitern, w00t!
<dimitern> fwereade__: well, it fails, but for a different reason
<dimitern> fwereade__: matching seems to pick up all hooks now
<dimitern> fwereade__: this is what I got before the failure: [LOG] 0.53984 JUJU actual: []string{"install", "config-changed", "start", "upgrade-charm", "config-changed", "db2-relation-joined mysql/0 db2:0"}, ctx.hooks: []string{"install", "config-changed", "start", "db2-relation-joined mysql/0 db2:0"}
<dimitern> [LOG] 0.54002 JUJU expected []string{"install", "config-changed", "start", "db2-relation-joined mysql/0 db2:0"}; never got anything
<dimitern> fwereade__: upgrade-charm hook is missingm hence the failure
<fwereade__> dimitern, yeah, I think you should specify the exact sequence of hooks
<fwereade__> dimitern, I think if anything it makes the test clearer actually
<fwereade__> dimitern, "do these things as close together as possible; check everything happens in the correct order"
<dimitern> fwereade__: yeah, I commented out the waitHooks{"upgrade-charm", "config-changed"} before the db2-r-j one, now I uncommented that and run it again
<dimitern> fwereade__: and guess what - OK: 1 passed
<dimitern> fwereade__: cool! I'll propose it now
<dimitern> fwereade__: I could debug it effectively by replacing c.Logf() with log.Printf() - we should think about this probably (otherwise these are 2 separate logs and are out of sync)
<fwereade__> dimitern, expand please... I'm pretty sure that log.Printf is the one that produces apparent sequence breaks
<dimitern> fwereade__: well juju uses log.Printf/Debugf and all lines are in a nice, expected order when printed
<fwereade__> dimitern, gaah sorry I totally misread you
<dimitern> fwereade__: c.Logf on the other hand is a separate log, so the combined output is not sequential
<fwereade__> dimitern, they're happening on different goroutines anyway, though...
<dimitern> fwereade__: yes, and we you look at the output it's not helpful (smth happened here and before or after is happened this other thing in the other log)
<dimitern> s/we//
<dimitern> s/is//
<dimitern> :) I'm too fast to be readable today
<fwereade__> :)
<dimitern> fwereade__: running a couple of times without the log hacks, to make sure the timing wasn't screwed somehow
<fwereade__> dimitern, well, you can see the two streams of independent events going on, right, they're just interspersed -- how would that change if they used the same log?
<dimitern> fwereade__: well, you can tell that all lines after X happened after X happened, while now some things before X also happened after X
<dimitern> fwereade__: X = juju log
<dimitern> fwereade__: it'll be really nice if we separated parts of the uniter tests in smaller chunks (they can still use the same table format) - maybe on logical boundaries ("// XYZ tests" + NL)
<fwereade__> dimitern, yeah, I think that'd be a definite win
<dimitern> fwereade__: there it is https://codereview.appspot.com/7385049
<fwereade__> dimitern, cool, will take a look shortly
<fwereade__> dimitern, thanks :)
<dimitern> fwereade__: cheers, I left some questions in comments
<fwereade__> dimitern, reviewed, LGTM, some comments
<dimitern> fwereade__: thanks!
<fwereade__> rogpeppe, dimitern, jam: I would very much appreciate your thoughts on https://codereview.appspot.com/7394048 which is still WIP
<dimitern> fwereade__: I'll take a look in 2m
<rogpeppe> fwereade__: chunk mismatch. please reupload.
<fwereade__> rogpeppe, what does that complaint actually imply? what will change if I repropose?
<rogpeppe> fwereade__: i've no idea, but reproposing usually seems to fix the problem.
<fwereade__> rogpeppe, haha, ok :)
<fwereade__> rogpeppe, better?
<rogpeppe> fwereade__: yup
<rogpeppe> fwereade__: thanks
<fwereade__> rogpeppe, cool, wish I understood what was up there
<rogpeppe> fwereade__: me too. let me know if you find out!
<rogpeppe> fwereade__, dimitern: i've responded to your comments on this, and made some changes: https://codereview.appspot.com/7390043
<rogpeppe> fwereade__: (i've also identified one significant omission, which i will be addressing shortly)
<fwereade__> rogpeppe, sorry, it was clearly monday morning... I think I read the goroutine as a defer or something
<rogpeppe> fwereade__: ah, i wondered where the comments were coming from :-)
<dimitern> rogpeppe: cheers, I'll take a look
<dimitern> fwereade__: can we assume my CL closes bug 1101140 ?
<_mup_> Bug #1101140: uniter does not skip unimplemented relations <upgrade-charm> <juju-core:In Progress by dimitern> < https://launchpad.net/bugs/1101140 >
<fwereade__> dimitern, yep
<dimitern> fwereade__: sweet!
<fwereade__> :D
<dimitern> fwereade__: one down, 7 to go (wrt upgrade-charm bugs)
<fwereade__> dimitern, yay :)
<fwereade__> dimitern, SetCharm is the next goal, but I'm not sure whether you should be handling the config changes first or the sanity checks first
<dimitern> fwereade__: I'll revisit the notes and we may need to have a g+ later perhaps?
<fwereade__> dimitern, I suspect doing the config changes is your best bet... maybe go with that, not worrying about the refcounting for now
<fwereade__> dimitern, but, yeah, reread the notes and let me know
<fwereade__> dimitern, I'd really appreciate thoughts on the Environ change first though :)
<dimitern> fwereade__: I'm on it now
<fwereade__> dimitern, <3
<dimitern> btw i'll need one more LGTM on this guys https://codereview.appspot.com/7385049/ - anyone willing?
<fwereade__> rogpeppe, what's the other oversight? can't spot it, so LGTM, but you've made me nervous ;p
<rogpeppe> fwereade__: i never tear down the watchers when the connection is dropped
<fwereade__> rogpeppe, ha! I remember that thought crossing my mind and then flitting away before I captured it in the first read
<fwereade__> rogpeppe, ty, good catch
<rogpeppe> fwereade__: it requires a little more more mechanism, and i'm not quite sure of the best method yet
<rogpeppe> fwereade__: am reviewing your bootstrap refactoring branch BTW
<fwereade__> rogpeppe, comments always welcome but it's far from complete
<fwereade__> rogpeppe, it's totally focused on getting ec2 working, nothing else
<rogpeppe> fwereade__: i'm trying to think about implications for future providers
<fwereade__> rogpeppe, I have made an effort to consider that but am glad for the backup scrutiny
<fwereade__> rogpeppe, LaunchInstance might actually be something more like RunMachineAgentOnInstance if you're bothered by the local provider
<rogpeppe> fwereade__: how does the new environs.Bootstrap square with the local provider?
<fwereade__> rogpeppe, what does it use that any provider doesn't provide?
<rogpeppe> fwereade__: i'm not sure that the local provider provides a working StartInstance, does it?
<fwereade__> rogpeppe, no reason it can't do it, though, is there? the "instance" is always the local machine, but it gets "launched" when the machine agent is started
<fwereade__> rogpeppe, same deal as the SSH provider
<rogpeppe> fwereade__: and what about future environments that have no bootstrap instance?
<fwereade__> rogpeppe, I don't see that you'd use bootstrap at all in that case
<fwereade__> rogpeppe, there's no actual bootstrapping going on there, is there?
<rogpeppe> fwereade__: yeah - you'd tell some other machine to create an environment for you.
<rogpeppe> fwereade__: that's still "bootstrapping" even though it doesn't require a new machine
<rogpeppe> fwereade__: in general, i like the way that the refactoring looks (and it's necessary) but i'm not sure about its exact positioning
<fwereade__> rogpeppe, well, it performs tasks that have *some* degree of overlap with those in Bootstrap
<TheMue> dimitern: You've got a review.
<dimitern> TheMue: thanks!
<fwereade__> rogpeppe, go on
<TheMue> dimitern: yw
<rogpeppe> fwereade__: i'm still mulling it over
<dimitern> fwereade__: reviewed
<fwereade__> dimitern, cheers
<rogpeppe> fwereade__: i'm wondering about leaving environs.Bootstrap as it is, but providing another function, say environs.BootstrapInstance, that contains the bulk of what ec2.Bootstrap does now (the tools uploading and the instance starting). then ec2.Bootstrap (and other similar providers) would just call that, but stranger providers would be free to do as they wished.
<fwereade__> rogpeppe, is your concern specifically about starting instances? because that feels to me like the only behaviour that should differ
<rogpeppe> fwereade__: it's not just about starting instances. it's also about the way that your proposal makes Bootstrap into a fundamentally racy thing when called concurrently.
<rogpeppe> fwereade__: perhaps i should publish my current comments on the CL
<fwereade__> rogpeppe, was it not so beforehand?
<fwereade__> rogpeppe, sgtm
<rogpeppe> fwereade__: (they're superceded by the above thought, but still pertinent to the CL)
<dimitern> mgz: standup?
<mgz> dimitern: yup
<rogpeppe> fwereade__: no, Bootstrap was only racy because its implementations were racy, not because the operation is fundamentally racy, i think.
<rogpeppe> fwereade__: as a trivial example, dummy.Bootstrap isn't racy
<rogpeppe> fwereade__: i published my comments  BTW
<allenap> Hi. In Python Juju, how does Juju get onto a machine that I'm deploying to? It is fetched from Launchpad? I'll put it another way. I make some code changes to a machine provider in my local branch of lp:juju. I then deploy a charm using this code. Does the allocated machine use my updated code? Does a machine need the machine provider code? (MAAS in this instance.)
 * TheMue enjoys lunch, biab
<fwereade__> rogpeppe, cheers
<fwereade__> allenap, depends on juju-origin in the config
<fwereade__> allenap, IIRC you can set it to your own lp: branch
<rvba> juju-origin: ppa
<rvba> allenap: ^
<fwereade__> allenap, you'll need to push before it'll use it though
<fwereade__> allenap, btw, I have a maas question
<fwereade__> allenap, can a process on a maas node easily find out the maas instance id?
<allenap> fwereade__: Cool, thank you, I think that'll be useful.
<allenap> fwereade__: rvba is checking that for you.
<fwereade__> allenap, rvba, cheers
<allenap> fwereade__: Doesn't look like it. What's the use case?
<fwereade__> allenap, there's this foul InstanceIdAccessor hack that's persisted all the way back since orchestra and is uglying up every provider
 * allenap looks it up
<rvba> fwereade__: I think the only thing you have is the 'name' of the node.
<fwereade__> allenap, the bootstrap node needs to know its own instance id and set it before its provisioning agent starts trying to provision an instance for itself
<fwereade__> rvba, and that's not the same as the instance id, I guess?
<rvba> No
<rvba> The 'name' is just the node's hostname.
<fwereade__> rvba, ok, thanks, no worries
<fwereade__> allenap, it's not a big deal, I can certainly make it less evil regardless
<allenap> fwereade__: The MAAS provider (Python) does call `cloud_init.set_instance_id_accessor(instance_uri)` so I assume it's getting over to the machine somehow.
<rvba> I'll check that it's there as soon as my node comes upâ¦
<rvba> (I've just destroyed my environment in the lab)
<rvba> fwereade__: actually, allenap was right, the instance id is in /var/lib/cloud/instances/
<rvba> $ ls lib/cloud/instances/
<fwereade__> allenap, rvba, wow, really? cool
<rvba> node-74c10d5c-7f34-11e2-9a9a-525400123456
<allenap> Right, so the directory names is the instance ID?
<rvba> Yes
<allenap> s/names/name/
<rvba> Contains cloud-init stuff.
<allenap> Is it also in a file within?
<fwereade__> rvba, allenap: in that case I think we can just straight-up drop InstanceIdAccessor and ask providers to implement InstanceId just as they do PrivateAddress/PublicAddress
<fwereade__> rvba, allenap: we can always hack it in via provider-specific machine config for functionality-challenged clouds in the future
<mgz> fwereade__: that would make more sense than the chunk of bash method used currently
<fwereade__> mgz, yeah, it's total crack
<fwereade__> mgz, it's only there for orchestra
<allenap> fwereade__: I haven't got my head around what InstanceIdAccessor does yet, so I'm not confident to say, but if all we need is the instance ID on the node then I guess we're okay.
<fwereade__> allenap, that is all it does
<allenap> Cool.
<fwereade__> rogpeppe, repsonded
<rogpeppe> fwereade__: looking
<rogpeppe> fwereade__: there's something about the new structure that doesn't feel quite right to me. a combination of a few things, i think
<rogpeppe> fwereade__: for instance, why does LaunchInstance now depend on a cloudinit data structure, when cloudinit is really just an artifact of one particular way of starting instances?
<fwereade__> rogpeppe, that data structure *defines* how we configure an instance -- AFAICT it's only in cloudinit because we don't have a more general place for it yet
<fwereade__> rogpeppe, the important bit is the "MachineConfig", not the "cloudinit.", I think
<rogpeppe> fwereade__: i don't think so. it defines the information that the generated cloudinit script needs to start stuff up, but that's a slightly different thing.
<fwereade__> rogpeppe, please expand upon the distinction
<fwereade__> rogpeppe, AFAICT MachineConfig is a representation of what needs to be done to get a machine agent running, and the other stuff in cloudinit is resposible for transforming that into  cloudinit data
<fwereade__> rogpeppe, I anticipate that other providers will maybe have different ways of transforming fundamentally the same data
<rogpeppe> fwereade__: it's got other stuff too. AuthorizedKeys isn't about getting a machine agent running, for example.
<jam> mgz: poke
<rogpeppe> fwereade__: i think that using cloudinit.MachineConfig is just fine as part of the bootstrap process, but i don't see it as fundamental to the Environ interface
<fwereade__> rogpeppe, surely that's only there because nobody bothered to do it properly? :)
<rogpeppe> fwereade__: which i still think is a reasonable abstraction
<fwereade__> rogpeppe, what if MachineConfig were to be defined somewhere else?
<rogpeppe> fwereade__: and i think that taking the guts of ec2.environ.Bootstrap and putting into a new function in environs, specialised for starting a cloudinit-oriented environ, is a reasonable way forward
<rogpeppe> fwereade__: rather than making Environ.Bootstrap more specific and meaning that providers that don't fit the mould will need to simulate stuff in order to "pretend" to start instances etc
<mgz> jam: hey, you're back?
<jam> mgz: yep
<jam> care to do a 1:1 mumbling?
<fwereade__> rogpeppe, why do you think MachineConfig is connected with cloudinit? is there anything other than the simple accident of placement?
<rogpeppe> fwereade__: because it was fashioned entirely to hold the things that cloudinit needs to do its job.
<fwereade__> rogpeppe, that job being..?
<rogpeppe> fwereade__: there's no point in passing half of that stuff into the Environ, because it already knows it
<rogpeppe> fwereade__: the fact that the data dir is in /usr/lib/juju is something that the Environ should decide, not the caller of the environ.
<rogpeppe> fwereade__: (for example)
<fwereade__> rogpeppe, yes... some fields are filled in by provider-specific code, and some by non-provider-specific code
<dimitern> fwereade__: just to double check - in order to handle config stuff properly in SetCharm, these are all related: http://paste.ubuntu.com/5564588/
<rogpeppe> fwereade__: i would expect every parameter to Environ methods to be filled in a non-provider-specific code
<rogpeppe> s/in a non/in by non/
<fwereade__> rogpeppe, like yuo did with stateinfo and tools, eh?
<rogpeppe> fwereade__: those types *are* filled in by code external to the environ, no?
<fwereade__> rogpeppe, they're a crazy frankenstein patchwork of could-come-from-anywhere AFAICT
<rogpeppe> fwereade__: at least they each represent a coherent resource (the state we need to connect to; the tools we want to use)
<fwereade__> rogpeppe, both of which are totally meaningless and inappropriate from the caller's POV
<fwereade__> rogpeppe, how did tools get into the interface in the first place?
<rogpeppe> fwereade__: i thought the process of finding the tools could be portable.
<rogpeppe> fwereade__: but i think you're right that it should probably be internal to Environ
<rogpeppe> fwereade__: and perhaps the same with state.Info as passed to Environ.StartInstance
<fwereade__> rogpeppe, it could never be portable
<rogpeppe> fwereade__: no?
<rogpeppe> fwereade__: perhaps not, but it seemed not too far from a possibility to me
<dimitern> fwereade__: have a look pls when you have time
 * dimitern lunch
<fwereade__> rogpeppe, it always depended on the arch, which could only ever be determined after contrsint handling
<fwereade__> dimitern, will do, cheers
<rogpeppe> fwereade__: anyway, all of that is making the Environ interface less, not more, specific. but your proposal makes it much *more* specific.
<rogpeppe> fwereade__: yeah, all of this stuff was always going to change with the advent of constraints.
<fwereade__> rogpeppe, it makes explicit the fact that you need to run a machine agent on an instance, and it takes the non-provider-related job of configuring that machine agent out of the hands of the environ
<rogpeppe> fwereade__: there's nothing explicitly mentioned about a machine agent in MachineConfig, is there?
<fwereade__> rogpeppe, ISTM pretty clear that a MachineConfig holds exactly the information necessary to get a machine agent running
<fwereade__> rogpeppe, please explain again the distinction you are seeing between a machine config and a ...MachineConfig ;)
<rogpeppe> fwereade__: there's lots more in there - StateServerCert/Key, StateServer, MongoPort, APIPort, ProviderType, MongoURL, AuthorizedKeys, Config
<fwereade__> rogpeppe, how do you propose to run a machine agent without state to run it against?
<rogpeppe> fwereade__: maybe the state is available elsewhere
<rogpeppe> fwereade__: that's up to the provider, surely?
<fwereade__> rogpeppe, in that case it doesn't need to be specified... and indeed it is not specified
<rogpeppe> fwereade__: what if someone passes a MachineConfig to the local provider's LaunchInstance with StateServer=true ?
<fwereade__> rogpeppe, what it they do?
<rogpeppe> fwereade__: i'm interested though: what objection do you have to factoring out the ec2-like bootstrap stuff in a similar way to how the cloudinit stuff was factored out before?
<fwereade__> rogpeppe, who's going to be doing that in the first place?
<rogpeppe> fwereade__: the (new) Environ interface looks like it's a viable possibility
<rogpeppe> fwereade__: i'd like to keep environs.Environ as simple as possible, and i think we can do that without loss of generality
<rogpeppe> fwereade__: and as a bonus that means that simpler providers don't need to mess with any of that stuff.
<fwereade__> rogpeppe, so what of the stuff that I do in bootstrap do you believe to be optional?
<rogpeppe> fwereade__: LaunchInstance, for one
<fwereade__> rogpeppe, it's basically RunMachineAgent, though, right?
<rogpeppe> fwereade__: upload tools also
<rogpeppe> fwereade__: no, it's more than that. running a machine agent is considerably more simple.
<fwereade__> rogpeppe, er, you made upload-tools a command line param, and part of the interface of environ in the first place
<fwereade__> rogpeppe, how do you imagine that to be optional?
<rogpeppe> fwereade__: there's nothing that states that the tools need to be uploaded to the environ's Storage AFAICS. the local provider could simply copy the binaries to the new container, for example.
<fwereade__> rogpeppe, running a machine agents *once you have all the requirements in place* is simple
<fwereade__> rogpeppe, why would we fuck up the local provider like that? because more code paths are a Good Thing?
<fwereade__> rogpeppe, because it's Fun to implement providers that randomly break when you want to upgrade?
<rogpeppe> fwereade__: because copying something to the storage just to copy it out again in the next line isn't very useful?
<rogpeppe> fwereade__: the only code path that depends on the tools being available in the storage is the shell script in cloudinit
<rogpeppe> fwereade__: apart from later when we upgrade
<rogpeppe> fwereade__: which is different.
<fwereade__> rogpeppe, oh really?
<rogpeppe> fwereade__: yeah, i think so
<rogpeppe> fwereade__: istm that this might be better in G+
<fwereade__> rogpeppe, yeah, maybe, just a mo, not sure if lunch is coming
<jam> mgz: apparently hdmi really is needed :)
<fwereade__> rogpeppe, https://plus.google.com/hangouts/_/f13861a7f65b5a679aa07c1d94088d17c4e8330b?authuser=0&hl=en
<benji> bac: let me know when you have a minute to sync up
<bac> benji: ok, how about in 5 minutes?
<benji> bac: sounds great
<bac> benji: i'll make a hangout
<benji> rogpeppe: I am getting test failures running "go test ./state/api/" on trunk; is that a know issue?
<benji> in fact, trunk doesn't look like it even builds: worker/firewaller/firewaller.go:319: undefined: state.IsNotAssigned
<rogpeppe> benji: on a call, sorry, will be with you in a bit
<benji> rogpeppe: thanks
<rogpeppe> benji: out of call finally. trunk at least compiles all tests for me currently. just checking that all tests run ok.
<benji> rogpeppe: I blew away my entire launchpad.net tree and re-got it and it works now <shrug>
<benji> perhaps I am missing some part of the dev process; is there some sort of re-fetch-and-build-all-dependencies command that people use?
<rogpeppe> benji: hmm, i wonder what the problem was. in future, you might try blowing away just $GOPATH/pkg instead and see if that makes a difference
<benji> k
<rogpeppe> benji: not really. the only thing i usually have to update is launchpad.net/goose
<benji> how do you go about doing that?
<rogpeppe> benji: other than that, all dependency management *should* be done by the go tool
<rogpeppe> benji: go get -u launchpad.net/goose
<benji> k, thanks
<rogpeppe> benji: i update it only when some openstack stuff starts failing
<benji> k
<fwereade__> dimitern, ping
<dimitern> fwereade__: pong
<dimitern> fwereade__: I decided to propose what we discussed in the mean time - split the uniter tests
<dimitern> fwereade__: will be ready shortly
<fwereade__> dimitern, awesome, just going t have a really quick piece of toast
<fwereade__> dimitern, hey, sorry, actually here now
<dimitern> fwereade__: np
<fwereade__> dimitern, starting a hangout
<dimitern> fwereade__: cool
<fwereade__> dimitern, https://plus.google.com/hangouts/_/4e9d42088fdb90f3cdce77923346ef9c1a62a89e?authuser=0&hl=en
<fwereade__> rogpeppe, don;t suppose I can interest you in a quick review of https://codereview.appspot.com/7396056/ ?
<rogpeppe> fwereade__: looking
<dimitern> fwereade__: there it is https://codereview.appspot.com/7378066/
<dimitern> :)
<fwereade__> dimitern, cheers
<fwereade__> dimitern, that's awesome, LGTM
<fwereade__> dimitern, do they get any faster? :)
<dimitern> fwereade__: thanks!
<dimitern> fwereade__: haven't check, but if they did is not much noticeable
<dimitern> fwereade__: I'll run them now to compare with older times
<fwereade__> dimitern, I think it ought to save a couple of seconds at least, but maybe that's all eaten up in extra test setup/teardown
<rogpeppe> fwereade__: reviewed
<dimitern> fwereade__: nah.. probably they're *slightly* slower due to extra call overhead
<dimitern> fwereade__: WOW they're actually faster!
<fwereade__> dimitern, wanna know why?
<dimitern> fwereade__: old time: 149.123 s, new time: 102.571s
<fwereade__> dimitern, waitHooks is O(len(testlog))
<dimitern> fwereade__: yes!
<dimitern> fwereade__: oh, I see
<fwereade__> dimitern, my money's on that, anyway
<dimitern> :)
<dimitern> fwereade__: can we consider this trivial with one LGTM
<fwereade__> dimitern, if they're all passing, yeah, I think so -- no logic changes, so go for it :)
<dimitern> fwereade__: yeah, all passing
<dimitern> fwereade__: cheers
<rogpeppe> fwereade__: if len(testlog) is a significant contributor to the test runtime, we should fix it. it surely wouldn't be hard.
<dimitern> TheMue: ty
<fwereade__> rogpeppe, it only became so gradually as the test table got seriously long
<rogpeppe> fwereade__: yeah, maybe it's insignifant again.
<rogpeppe> icant
<fwereade__> rogpeppe, I'm not sayng it *shouldn't* be fixed, but I think the bulk of its contribution has been wiped out
<fwereade__> rogpeppe, btw, good catch on init-time version.Current; ty
<rogpeppe> fwereade__: np
<rogpeppe> fwereade__: i thought uniter spent all its time making changes to mongo and waiting for changes.
<rogpeppe> fwereade__: (the uniter tests, that is)
<fwereade__> rogpeppe, I had a closer look the other day and only then spotted that the testlog-scanning had become significant
<fwereade__> rogpeppe, and was starting to consider rewriting the whole lot as separate test cases but didn't quite have the energy ;p
<rogpeppe> fwereade__: you could easily avoid using the whole test log by pre-filtering for particular log messages, no?
<rogpeppe> fwereade__: (i remember doing something similar once)
<fwereade__> rogpeppe, a target that collects the ones I care about and stashes them somewhere? yeah, might be nice
<rogpeppe> fwereade__: yeah. a simple prefix regexp worked ok for me.
<fwereade__> rogpeppe, so long as I don;t disturb the rest of the log, which does actually contain useful stuff sometimes
<rogpeppe> fwereade__: yeah - i logged as well as stashing
<fwereade__> rogpeppe, cool, didn't think of that at the time
<rogpeppe> fwereade__: for our copious spare time :-)
<fwereade__> rogpeppe, indeed :)
<dimitern> i'm off guys
<dimitern> have a good evening
<fwereade__> dimitern, gn, take care
<rogpeppe> fwereade__: a small CL that enables cleaning up of watchers in the other one: https://codereview.appspot.com/7398050
<rogpeppe> fwereade__: perhaps "Abort" might be better than Kill, but i thought it's similar enough to tomb's Kill that the same name is probably appropriate.
<rogpeppe> right, that's me for the day. see y'all tomorrow.
 * thumper stabs go in the face
<thumper> go not having any form of real inheritance sucks monkey balls
<thumper> morning davecheney
<thumper> davecheney: why does go make it so hard to do something like virtual dispatch?
<davecheney> thumper: do you want the long answer or the short answer
<thumper> davecheney: I want to know how to do what I want to do
<thumper> as each thing I try, I get stuck by go's limitations
<davecheney> thumper: not limitations, design decisions
<thumper> :)
<thumper> davecheney: so... lets see if you can help me out
<thumper> right now in the cmd package, there is a help method on the Info object
<thumper> s/object/struct
<davecheney> mmm
<thumper> and a hard coded function call when needing help that takes (c *Command) -> c.Info().Help(f) where f aresome flags
<thumper> what I want however is to override that behaviour when c is a SuperCommand
<thumper> and I feel that looking at the underlying type is a horrible crutch
<thumper> and was trying to find a better way
<thumper> including having a "Base struct member" like CommandBase
<thumper> however that doesn't work
<thumper> as it can't call something it doesn't know about
<davecheney> i think the problem is we're trying to make SuperCommand a subclass of Command
<thumper> hmm...
<thumper> perhaps
<davecheney> the first thing that comes to mind is makeing Command an interface that both
<davecheney> subcommand and supercommand satisfy
<thumper> right... I started down that path
<thumper> actually, that is how it works right now
<thumper> but there is no concept of a "subcommand" as an entity in its own right
<thumper> and I don't want to have to implement default behaviour in every subcommand
<thumper> what I really want is some equivalent to the "pure virtual method" issue with an intermediate default implementation
<thumper> surely go has some answer to that design problem
<thumper> I just don't know what it is
<davecheney> embedding
<davecheney> it is also that go does not have an answer for this
<davecheney> the authors made some deliberate decisions to not include type inheritence or function polymorphism
<davecheney> so sometimes it isn't possible to directly transpose from one language to another
<thumper> davecheney: I tried embedding, but it fails in one critical aspect
<thumper> davecheney: there isn't a way to define a method that doesn't yet exist
<thumper> davecheney: where you can get the result from a more-derived class
<thumper> davecheney: and you can't have a method on an interface, nor can you have function overloading
<davecheney> yeah, there is only composition, not virtual dispatch
<thumper> do I'm stuck trying to work out a solution for the problem in go
<davecheney> wut "you can't have a method on an interface" ?
<thumper> that is trivial in several other languages
<thumper> and I'm venting
<thumper> as the target of the method
<thumper> like
 * davecheney pats thumper on the shoulder
<thumper> func (i *SomeInterface) Foo() {}
<thumper> which would work fine if it worked
<davecheney> nup, can't do that, intefaces only define the contract, not satisfy them
<thumper> right
<thumper> hmm... time to collect my daughter for lunch
<thumper> bbl
<davecheney> thumper: or, you could use the type assertion and move on with your life :)
<thumper> I may just do that, bit it feels horrible!
<thumper> goes against a whole lot of my professional life
<thumper> it is like saying, "just shoot that person, and get on with your life"
<thumper> I've spent 20 years learning not to do that
<davecheney> sure
<davecheney> then lets fix it properly
#juju-dev 2013-02-26
 * thumper is back
<thumper> davecheney: I have an idea, but it is a little icky
<davecheney> shoot
<thumper> davecheney: I'll see if I can make it owrk
<thumper> parameterise from above
<thumper> if I can't use a dynamic way of getting the param, pass it in
 * thumper bangs on the keyboard for a bit
 * thumper sighs
<thumper> tests in cmd depend on classes in ../worker
<thumper> seems wrong IMO
<davecheney> test helpers ?
<davecheney> cards on the table
<davecheney> i'm here to help make Juju better in any way that you think it should be
<davecheney> but I can't change the language
<davecheney> it isn't object oriented in the way that most of the textbooks say
<davecheney> so some things just won't work
<thumper> davecheney: more just testing other parts
<thumper> I've got it working
<thumper> isn't as fugly as some methods
<thumper> :)
<thumper> davecheney: ok, question time...
<davecheney> shoot
<thumper> if I have a composed element, and I want to provide specialised implementation of a function also defined by the composed element
<thumper> and I want the derived function to call the composed function
<thumper> what is the way to do it?
 * davecheney translates
<davecheney> two secs, lemmie do a paste
<davecheney> thumper: is this of any use ? http://play.golang.org/p/NbcP2zklaj
 * thumper clicks
<thumper> b.A.Get()
<thumper> yes
<davecheney> so, embedding A into B allows you to call B.A.Get as B.Get
<davecheney> the compiler doesn't actually create a forwarding method
<davecheney> ie, there isn't a synthetic method on B called Get that returns B.A.Get()
 * thumper nods
<davecheney> _but_ if you want to interpose in that
<thumper> just convenience
<davecheney> you can
<thumper> sweet sweet sugar
<davecheney> and sometimes it is necessary if you embed two types that have the same method sig
<davecheney> you need to break the deadlock
<davecheney> TBH, go's application of syntactic sugar is inconsistent
 * thumper nods
<davecheney> automatic pointer deferending for method dispatch +1
<davecheney> no obvious type converstions -1
<davecheney> there is a reason for all of it
<davecheney> but the reason is generally 'this is my opinion, - rob pike'
<thumper> :)
<davecheney> as long as you can make peace with that fact, life can be good
<davecheney> thumper: i am going to put the completion of commands back on the agenda for tonight
<davecheney> i (personally) do not feel I understand the work that is remaining
<thumper> as in "which need to be done?"
 * thumper nods
<davecheney> and, without disrepect to your gap analysis, we now have yet another 80% complete document that doesn't capture actionable work
<davecheney> paying my strata fees 3 days early, like a boss
<thumper> strata?
<davecheney> what we call the rates for the apartment block
<davecheney> pays for the common area, power, cleaning , that shit
<thumper> ah
 * thumper nods
<thumper> every time I feel like I have a good grip on this, the stick becomes a slippery eel
<davecheney> the commands work ?
<thumper> making help work nicely
<davecheney> oh
<davecheney> ok
<thumper> because ideally: juju deploy --help
<thumper> should be the same as: juju help deploy
<davecheney> yes
<thumper> but the mechanism for getting there are differrent
<thumper> davecheney: ok, I think I almost have this working properly now
<thumper> just some tests to fix, tests to write etc
<davecheney> sweet
<davecheney> nearly lunch time here (i can hear my SO stiring in the next room)
<thumper> davecheney: do you think people would complain that I've changed help output from stderr to stdout?
<davecheney> no idea about the others, but I would no object
<davecheney> not
<thumper> ok, lets see :)
<thumper> I think it makes more sense to have help output on stdout
<thumper> not stderr
<thumper> as it isn't an error
<davecheney> thumper: can you describe your views on stdout/stderr ?
<thumper> call me pedantic
<thumper> davecheney: sure...
<davecheney> (to see if they mesh with mine)
<thumper> expected output should go to stdout, which is "normal"
<thumper> exceptional or error text should to to stderr
<davecheney> and if you ask for help, you should expect it on stdout
<davecheney> makes sense
<davecheney> thumper: what about verbose or debug information ? stdout as well ?
<thumper> there are occasions where you want different information streams on stdout vs stderr, but they should really be rationalised
<thumper> verbose output should go to stdout
<thumper> because you asked for verbose
<thumper> and it is output
<davecheney> SGTM
<thumper> debug info is a fluffy situation
<thumper> normally I'd say stdout
<thumper> unless you've configured your logging to go to stderr
<davecheney> one reason for the prediliction to stderr is, by default the Go log package sends everything to stderr
<thumper> which should always be an option
<davecheney> so that default tends to drive other decisions
<thumper> command output isn't logging
<thumper> sending logging to stderr by default can be argued to allow 2>some_file
<davecheney> i guess it depends on what your program does
<davecheney> if it is piping data, that limits your options
<davecheney> but if it commincates on other fd's, ie, networking
<davecheney> then you have more choice
<thumper> sure, but we're not
<thumper> davecheney: oh, don't suppose you want to add me to ~juju ?
<thumper> davecheney: you are an admin
<thumper> davecheney: one thing I'd like to change is "bufferString(ctx.Stdout)" -> "testing.Stdout(ctx)"
<thumper> davecheney: what do you think?
<thumper> davecheney: I think it reads a little better
<thumper> obviously another one for "testing.Stderr(ctx)"
<thumper> and then delete both instances of bufferString
<davecheney> thumper: are you still not in that group
<davecheney> two secs
<thumper> davecheney: not that one
<thumper> added to the gophers
<davecheney> thumper: which group are you missing ?
<thumper> ~juju
<thumper> https://launchpad.net/~juju
<davecheney> thumper: done
<davecheney> re: "bufferString(ctx.Stdout)" -> "testing.Stdout(ctx)"
<davecheney> sure
<thumper> ta
<davecheney> maybe do it as a separate branch
<davecheney> smaller branches == less latency
<thumper> yep, agreed
<davecheney> I think i had a change that did exactly that
<davecheney> but it was blocked on a stack of prereqs that went nowhere
<davecheney> i tried to remerge it yesterday
<davecheney> but gave up as it was fucked
<thumper> :(
<thumper> interesting that we think along very similar lines
 * thumper does the relocation dance
<thumper> davecheney: ping
<thumper> well that's dumb
<wallyworld_> anyone know how/where to configure the mongo admin password so that juju state works after a bootstrap?
<davecheney> wallyworld_: i have no idea how any of that works
<davecheney> i know it's a bit fragile
<wallyworld_> thanks anyway, i'll look into it
<davecheney> i think all agents share a password, but they use a per client certificate
<wallyworld_> all i did was "juju bootstrap" and then "jujustatus" and the status failed
<davecheney> paste
<davecheney> ?
<davecheney> that is seroius
<davecheney> what does the log on the bootstrap node say ?
<wallyworld_> i had to hack the stupid error code to get real info out of it
<wallyworld_> i haven't logged into the bootstrap node
<wallyworld_> i guess i can just ssh in
<wallyworld_> but on my client, i get a screenfull of this
<wallyworld_> 2013/02/26 14:01:16 JUJU state: opening state; mongo addresses: ["15.185.100.10:37017"]; entity ""
<wallyworld_> 2013/02/26 14:01:16 JUJU state: connecting to 15.185.100.10:37017
<wallyworld_> 2013/02/26 14:01:17 JUJU state: connection established
<wallyworld_> 2013/02/26 14:01:17 JUJU state: opening state; mongo addresses: ["15.185.100.10:37017"]; entity ""
<wallyworld_> 2013/02/26 14:01:17 JUJU state: connecting to 15.185.100.10:37017
<wallyworld_> 2013/02/26 14:01:18 JUJU state: connection established
<wallyworld_> 2013/02/26 14:01:19 JUJU juju status command failed: cannot log in to admin database: auth fails
<wallyworld_> error: cannot log in to admin database: auth fails
<wallyworld_> it finally ends with an error
<davecheney> what about on the bootstrap node ?
<davecheney> /var/log/juju/*log
<davecheney> or /var/log/cloudinit-output.log
<wallyworld_> before it just used to say "unauthorized access" without telling me what
 * wallyworld_ looks
<wallyworld_> hmmm. nova list returns a few servers. i think some were running already before i did the juju bootstrap
<davecheney> i wonder if it picked up the wrong bootstrap node
<wallyworld_> is "juju-hpcloud-machine-0" supposed to be the bootstrap node?
<wallyworld_> there's also "juju hpcloud instance 0"
<wallyworld_> i'll try and log into them
<davecheney> wallyworld_: not sure, i've only been able to bootstrap ec2 nodes
<davecheney> so i'm used to their line noise names
<wallyworld_> except ssh fails
<davecheney> maybe the machine is fucked
<davecheney> boot'd the wrong ami
<wallyworld_> maybe i'll just kill them all and try again
<wallyworld_> except it's a shared account so maybe not
<davecheney> meh, blow em away
<davecheney> and say it was a bug :)
<wallyworld_> wcpgw
<wallyworld_> davecheney: got ssh access finally. but nothing i can see in the juju log nor the clound-init log. will keep poking around
<davecheney> ps aux
<davecheney> is jujud running ?
<davecheney> sounds like it was stillborn
<wallyworld_> jujud running
<wallyworld_> i'll try it all again. i'd love to know where the admin password comes from
<davecheney> from what I understand it is generated on bootstrap and is essentially opaque
<davecheney> i'm not quite sure why we use both a password and tls client certs
<wallyworld_> i have no idea either
<wallyworld_> i realised one issue - i'm running Q and the image is i specified was for P. so perhaps there's an issue there
<davecheney> that will be a big problem
<wallyworld_> cause i specified --upload-tools and so the tools would be wrong
<davecheney> if you use upload tools, it will always use the series of your machine
<davecheney> that was a battle I was unable to win
<davecheney> wallyworld_: maybe add your question to the agenda, https://docs.google.com/a/canonical.com/document/d/19bpZCZNWDYuRMVGvq66YcPThpirQAz1MRYnOMV6QHxo/edit#heading=h.3hs0dshzcf8k
<wallyworld_> but it calls them "..qantal....tar.gz" doesn't it
<wallyworld_> and so findToold would fail
<wallyworld_> findTools
<davecheney> yeah, pass --debug or -v for the gorey details
<wallyworld_> doesn't explain why mongo login fail though
<davecheney> i think the ssl cert provides the tunnel, but you still need a username/password
<davecheney> for mongo
<davecheney> the debug data should be on the bootstrap node in /var/log/juju/
<wallyworld_> davecheney: yeah, -v or logs unhelpful, just lots of this
<wallyworld_> 2013/02/26 15:01:50 JUJU state: opening state; mongo addresses: ["15.185.101.250:37017"]; entity ""
<wallyworld_> 2013/02/26 15:01:50 JUJU state: connecting to 15.185.101.250:37017
<wallyworld_> 2013/02/26 15:01:50 JUJU state: connection established
<wallyworld_> 2013/02/26 15:01:51 JUJU juju status command failed: cannot log in to admin database: auth fails
<wallyworld_> error: cannot log in to admin database: auth fails
<wallyworld_> i'll dig further and see what i can find
<davecheney> ok, that is fatal
<davecheney> once that happens
<davecheney> nobody has the password
<davecheney> and it's game over
<wallyworld_> hmmm. the password ran away then. sneaky
<rogpeppe> mornin' lal
<rogpeppe> "all" even!
<jam> rogpeppe: I just found something even more interesting for the bootstrap case. It would appear that we are calling 'putFakeTools' which actually only uploads 1-2bytes of garbage data, but we *still* call go install to build jujud, even though we aren't actually uploading it. At least, that is what I get if I understand how to 'Tell()' on a file.
<rogpeppe> jam: putFakeTools only works for some cases
<jam> rogpeppe: so for 'go test -gocheck.f BootstrapMultiple' it spends 5s in 'building stuff', and the .tgz is 2 bytes long
<rogpeppe> jam: putFakeTools won't work if someone calls Bootstrap with uploadTools=true
<jam> rogpeppe: so I'm not sure if it is putFake or not, it doesn't really matter. The point is that it spends 2+s to end up with 2 bytes in a .tgz
<jam> Though the fact that we are spending time in flate means I could be wrong, and I'm trying to sort those things out.
<rogpeppe> jam: actually, it ends up with all the tools in a tgz too
<rogpeppe> jam: the fake tools are put into the public bucket AFAIR
<jam> rogpeppe: I'm just putting print statements into "buildTools" and see it takes 2.1s, however, statting the file shows far more space than 'Seek(1, 0)' did, because I had the order of parameters wrong
<jam> I needed Seek(0, 1)
<jam> anyway, there is more content, which at least means we have content.
<jam> so that part is good
<jam> We aren't compiling and then not actually using it.
<rogpeppe> jam: you can use os.SEEK_END, BTW
<rogpeppe> jam: right
<rogpeppe> jam: well, we *aren't* actually using it, 'cos we never actually call the executable for real (actually, we do, in PutTools, but that's just a sanity check)
<jam> rogpeppe: sure, but Seek takes ints, so you can do Seek(os.SEEK_END, 0) just as easily as Seek(2, ))
<rogpeppe> jam: nope.
<rogpeppe> jam: (try it)
<jam> rogpeppe: interesting, I was thinking int was the typeless const, but I see it is the typed value. Is there a way to get untyped or you just have to use "const Foo = 1234"
<jam> ?
<rogpeppe> jam: yeah, an unadorned constant is untyped
<rogpeppe> jam: it still has some type-like information though (floats are different from ints are different from strings)
<rogpeppe> dimitern, mramm: meeting?
<jam> mgz doesn't seem to be here yet, though he mentioned he had to run on Chromebook which doesn't have an arm binary for Hangouts? So we probably shouldn't wait for him.
<davecheney> https://docs.google.com/a/canonical.com/spreadsheet/ccc?key=0AoQnpJ43nBkJdEFIZVg0dnN0SXNNREpTMTd6X1FMS1E#gid=1
<wallyworld_> FAIL: current_test.go:56: CurrentSuite.TestCurrentSeries
<wallyworld_> current_test.go:65:
<wallyworld_>     // If the command fails (for instance if we're running on some other
<wallyworld_>     // platform) then CurrentSeries should be unknown.
<wallyworld_>     c.Assert(s, Equals, "n/a")
<wallyworld_> ... obtained string =
<wallyworld_> ----------------------------------------------------------------------
<wallyworld_> FAIL: current_test.go:56: CurrentSuite.TestCurrentSeries
<wallyworld_> current_test.go:65:
<wallyworld_>     // If the command fails (for instance if we're running on some other
<wallyworld_>     // platform) then CurrentSeries should be unknown.
<wallyworld_>     c.Assert(s, Equals, "n/a")
<wallyworld_> ... obtained string = "quantal"
<wallyworld_> ... expected string = "n/a"
<wallyworld_> OOPS: 6 passed, 1 FAILED
<jam> wallyworld_: what does "lsb_release" do, and "lsb_release -c" ?
<jam> wallyworld_: it looks like the command 'lsb_release' is failing for you, but /etc/lsb-release has the right content so Juju knows what release it should be, and the test is faulty.
<wallyworld_> jam:
<wallyworld_> ian@wallyworld:~/juju/go/src/launchpad.net/juju-core$ lsb_release
<wallyworld_> Traceback (most recent call last):
<wallyworld_>   File "/usr/bin/lsb_release", line 26, in <module>
<wallyworld_>     import lsb_release
<wallyworld_> EOFError: EOF read where not expected
<wallyworld_> so my system is screwed somehow
<jam> wallyworld_: right, so that is why the test is failing (lsb_release is failing incorrectly), I don't know yet why 'import lsb_release' is failing
<wallyworld_> ok, np.
<jam> wallyworld_: ls /usr/lib/python2.7/dist-packages/lsb_release.py
<wallyworld_> ian@wallyworld:~/juju/go/src/launchpad.net/juju-core$ ls -l /usr/lib/python2.7/dist-packages/lsb_release.py
<wallyworld_> lrwxrwxrwx 1 root root 38 Oct 24 10:34 /usr/lib/python2.7/dist-packages/lsb_release.py -> ../../../share/pyshared/lsb_release.py
<wallyworld_> ian@wallyworld:~/juju/go/src/launchpad.net/juju-core$
<wallyworld_> jam:
<wallyworld_> ian@wallyworld:~/juju/go/src/launchpad.net/juju-core$ python /usr/share/pyshared/lsb_release.py
<wallyworld_> {'RELEASE': '12.10', 'CODENAME': 'quantal', 'ID': 'Ubuntu', 'DESCRIPTION': 'Ubuntu 12.10'}
<wallyworld_> ['core-2.0-amd64', 'core-2.0-noarch', 'core-3.0-amd64', 'core-3.0-noarch', 'core-3.1-amd64', 'core-3.1-noarch', 'core-3.2-amd64', 'core-3.2-noarch', 'core-4.0-amd64', 'core-4.0-noarch']
<wallyworld_> so it sort of works
<wallyworld_> i'm hungry and it's way past dinner time here, so let's chat later about it
<jam> wallyworld_: np
<jam> morning mgz
<mgz> hey jam
<jam> mgz: so did you take the opportunity of not having G+ to sleep in, or were you outside feeding the chix?
<mgz> both :D
<mgz> four eggs this morning
<jam> that sounds small, but I don't know how many chix they have
<mgz> five, so only one was slacking
<jam> though if you think about it, having a body that produces a whole egg that often is pretty crazy
<fwereade__> bbiab, popping over to dimiter's
<dimitern> hey, fwereade is here, if anyone needs him
<mgz> give the guy an internet connection dimitern :)
<bac> thanks for the review rogpeppe
<rogpeppe> bac: np. i should go back and look at the ones that happened when i was away. from my mobile phone they looked fine :-)
<rogpeppe> dimitern: if fwereade's with you, perhaps you could mention that it'd be much appreciated if he passed his canny eye over https://codereview.appspot.com/7398050/
<rogpeppe> or reviews anyone else for that matter - it's a later-comer prereq for another CL
<bac> rogpeppe: i've made the changes you requested.
<rogpeppe> bac: thanks
 * bac out for 1.5 hours or so
<rogpeppe> bac: replied
 * TheMue is at lunch
 * rogpeppe passes TheMue some slices of delicious ham.
<jam> mgz: we can hear you type, but not you talk
<mramm> jam, mgz, TheMue, wallyworld_, thumper, rogpeppe, fwereade, dimitern:  Sorry I missed the meeting.  My laptop met an untimely end yesterday due to close contact with some coffee.
<fwereade> mramm, we heard... bad luck :(
<mramm> jam, mgz, TheMue, wallyworld_, thumper, rogpeppe, fwereade, dimitern:  After which I spent about 8 hours getting things restored to an old machine, and then it was an hour before the meeting and I was going to stay up
<wallyworld_> it could at least have been alcohol
<dimitern> mramm: lol, that's bad
<rogpeppe> wallyworld_: well, no wasted booze at any rate. there's a silver lining to every cloud.
<wallyworld_> true :-)
<mramm> rogpeppe: wallyworld_: very true
<TheMue> mramm: That sound hard. Coffee as pure energy for the developer is still bad for computers.Something's wrong here. ;)
<mramm> yea
<TheMue> rogpeppe: Thx for the ham, had put it on my flatbread.
<mramm> so, I have my old mac working, and while I don't have dual boot on it yet I do at least have ubuntu on it in a VM with *almost* all my settings and documents back from git repo's
<mramm> but it made me realize that my backup strategy on ubuntu was a bit of manual kludgery
<mramm> but it worked mostly
<TheMue> mramm: Not everything in the cloud? ;)
<mramm> well, it there was a bit of stuff in the cloud, a bit of stuff in git repositories, and then a "copy the home folder" to an external drive bit
<mramm> all of which provided some "backup"
<mramm> and all of which actually worked out fine
<mramm> but there were a lot of manual steps to restore
<TheMue> Yep
<mramm> anyway, I'm back.
<mramm> my intention was to get everything fixed before the meeting and have no work related downtime because of the laptop death
<mramm> but my intention was foiled by a comfy chair in my office!
 * TheMue just tries to imagine this picture
<rogpeppe> fairly trivial CL if anyone wants to take a look:  https://codereview.appspot.com/7391051
<rogpeppe> also, i'm still looking for another review of https://codereview.appspot.com/7398050/ so i can propose the branch that uses it as a prereq
<TheMue> rogpeppe: Will take a look at both.
<rogpeppe> TheMue: thanks
<TheMue> rogpeppe: First review done, now the next.
<fwereade> mgz, ping
<TheMue> rogpeppe: 2nd one done too.
<rogpeppe> TheMue: tyvm
<fwereade> mgz, am I right in thinking that the openstack metadata service does not expose instance-id until version 2012-08-10 ?
<mgz> fwereade: folsom or later
<mgz> so yup.
<fwereade> mgz, this seems to suggest otherwise: http://docs.openstack.org/essex/openstack-compute/install/apt/content/running-an-instance.html
<fwereade> mgz: cloud-setup: checking http://169.254.169.254/2009-04-04/meta-data/instance-id
<fwereade> mgz, I guess that's just a lie? :)
<mgz> fwereade: that gives you the i-0000000 form, which is no good to man nor beast
<mgz> (in the context of trying to do openstack operations)
 * dimitern lunch
<fwereade> mgz, wait, what's wrong with that? is that form not used in the API?
<mgz> there's no correlation between the uuid you need to do operations via the openstack api, and the integer id used the in ec2 compat api, and there's no api call to map between them, it's all hidden in the backend db
<fwereade> mgz, oh ffs
<fwereade> mgz, ok, thanks
<mgz> folsom adds openstack specific data to the metadata service, which we can use
<fwereade> mgz, so we currently can't work pre-folsom regardless?
 * fwereade lunches, thanks mgz
<TheMue> fwereade: Enjoy.
<rogpeppe> can someone other than me have a look at this CL please, so that Brad can submit: https://codereview.appspot.com/7384058/
<benji> m_3: hi, I have a small branch charmhelpers branch up for review; I hear you are the guy to see about that: https://code.launchpad.net/~benji/charm-tools/bug-1130793-add-log-option-escaping/+merge/150442
<TheMue> rogpeppe: Done
<rogpeppe> TheMue: thanks
<niemeyer> Yo!
<mgz> fwereade: whoops, missed the last question. so, gojuju doesn't work on pre-folsom currently, as the pyjuju code predates folsom, it has a cunning workaround, that gojuju could also adopt as needed (it stashes the uuid in storage)
<rogpeppe> niemeyer: hiya!
<rogpeppe> niemeyer: i've just run across a couple of weirdnesses in goyaml - i wonder if you can tell me if they're expected behaviour or bugs
<rogpeppe> a fairly small review anyone? https://codereview.appspot.com/7399054
<rogpeppe> fwereade: it contains two things that should please you
<fwereade> rogpeppe, cool, need to kanban too
<rogpeppe> fwereade: just going there
<rogpeppe> mramm: kanban meeting?
<benji> m_3: ping
<m_3> benji: pong
<benji> m_3: hi, I have a small branch charmhelpers branch up for review; I hear you are the guy to see about that: https://code.launchpad.net/~benji/charm-tools/bug-1130793-add-log-option-escaping/+merge/150442
<dimitern> rogpeppe: reviewed
<niemeyer> rogpeppe: Sure
<m_3> benji: yikes... tomorrow's first chance for me (see juju-gui)... I'm prepping for two talks later today
<benji> m_3: apparently you and Gary are discussing this in juju-gui, so nevermind
<m_3> benji: ack.... ping me tomorrow if you haven't gotten it through
<niemeyer> m_3: Way to go
<niemeyer> m_3: The amount of activity around charms is looking great, btw
<rogpeppe> niemeyer: i filed a bug report (that may or may not be spurious) https://bugs.launchpad.net/goyaml/+bug/1133337
<_mup_> Bug #1133337: unmarshalling map into *string has odd behaviour  <goyaml:New> < https://launchpad.net/bugs/1133337 >
<niemeyer> rogpeppe: Thanks!
<m_3> niemeyer: thanks!  we're doing a lot of talking :)... still need to do more charm cleaning though
<rogpeppe> niemeyer: i encountered these issues when trying to deal with service configuration in a moderately sane way, BTW.
<niemeyer> rogpeppe: Cool
<niemeyer> rogpeppe: I'll put that in the queue and see what would be a reasonable answer
<rogpeppe> niemeyer: thanks. for the time being, i'm just treating null as the string "null"
<niemeyer> rogpeppe: What does that mean?
<niemeyer> rogpeppe: This is certainly wrong, if it means what I think it menas
<niemeyer> rogpeppe: People should be able to set a configuration value to the string "null"
<rogpeppe> niemeyer: they can do that. they can't use null as to delete an attribute though.
<niemeyer> rogpeppe: That's fine.. we don't have that semantic defined yet
<rogpeppe> niemeyer: yeah. we chatted about it though, so i was considering doing it.
<rogpeppe> niemeyer: i'm not sure what user expectations are tbh
<niemeyer> rogpeppe: Sure, and I hope we can implement it
<niemeyer> rogpeppe: I don't think that's a typical case people think about
<niemeyer> rogpeppe: So much so that the whole fixup didn't come from a user request
<rogpeppe> niemeyer: yeah. i suspect that deleting a attribute is a pretty rare operation, so i'm not too concerned
<rogpeppe> niemeyer: ha, perhaps you were talking about goyaml semantics.
<niemeyer> rogpeppe: No, the former
<rogpeppe> TheMue: any chance of that promised review? https://codereview.appspot.com/7399054/
<TheMue> rogpeppe: Will be in in a few seconds. Mostly LGTM, only one "feeling". ;)
<TheMue> rogpeppe: It's in.
<rogpeppe> TheMue: thanks!
<TheMue> rogpeppe: yw
<dimitern> a small review anyone? https://codereview.appspot.com/7405049
<rogpeppe> dimitern: looking
<dimitern> rogpeppe: cheers
<rogpeppe> dimitern: reviewed
<dimitern> i'm seeing an error running go test ./... on state/statecmd/ServiceGet
<dimitern> rogpeppe: tyvm
<dimitern> that's the error I'm getting - running on just pulled trunk: https://codereview.appspot.com/7405049
<dimitern> oops - this is it - http://paste.ubuntu.com/5568327/
<dimitern> so william proposed CLs which are a direct result of pair programming to need one LGTM
<dimitern> what do you think about it?
<rogpeppe> dimitern: hmm, that looks bad. might be my fault, but i'm already running really late and have to go.
<dimitern> rogpeppe: no worries
<rogpeppe> dimitern: it's a trivial fix if you wanna do it
<dimitern> rogpeppe: sure?
<rogpeppe> dimitern: (in the test only, i think)
<dimitern> rogpeppe: ok, I'll propose it later
<rogpeppe> dimitern, all: see ya tomorrow
<dimitern> rogpeppe: g'night
<jcastro> davecheney: Is this a charm problem or a juju problem: http://paste.ubuntu.com/5569147/
<jcastro> davecheney: ah, does juju-log exist in the go version?
#juju-dev 2013-02-27
<davecheney> jcastro: no it does not
<davecheney> this is probably a problem
<davecheney> it is both one of the remaining command line things to do
<davecheney> and also not super simple as in zk we used to tail a zk key
<davecheney> which isn't as straight forward in mongo
<davecheney> two secs
 * davecheney search documents
<jcastro> on top of that we have a few charms using it
<jcastro> I can sub to a bug or whatever it is
<davecheney> jcastro: ahh, is this on the charm side (what we call the hook commands) ?
<jcastro> davecheney: so it deployed the other charm too
<jcastro> man, it's visibly faster, that's the first thing I noticed
<davecheney> you're not talking about debug-log ?
<davecheney> jcastro: about speed
<jcastro> http://jujucharms.com/charms/precise/postgresql/hooks/install
<jcastro> line 40, is what breaks there
<davecheney> i had a report from the folks who can't be named in this channel
<davecheney> that the charmers who were charming their things were suffering from 10min round trip times
<davecheney> can you tell me more about that
<davecheney> (maybe we should get back on the phone)
<jcastro> so like, status, etc is much faster
<jcastro> from hitting enter to getting a prompt
<davecheney> jcastro: if you pass -v
<davecheney> you'll see we don't use an ssh tunnel
<davecheney> which really improved speed
<davecheney> and reliability
<jcastro> yeah so that's pretty awesome
<davecheney> for small envs
<davecheney> status is great
<davecheney> i'm concerned about large envs
<davecheney> which is one place where _not_ having the topology node isn't great
<jcastro> Can we hop on tomorrow? I'm pushing my EOD++ limits and it's affecting my wife's ability to want to punch me right now. :)
<davecheney> jcastro: understood
<davecheney> please raise bugs, we'll take it from there
<davecheney> jcastro: the line 40 issue is the path to juju-log is hard coded
<davecheney> raise an issue anyway
<jcastro> nod
<davecheney> this is a good case to explain how it is both different, and the same
<davecheney> if you get my meaning
<davecheney> jcastro: please _please_ raise this with the charmers tomorrow in the call
<davecheney> if nobody else, i'm here to traige bugs
<jcastro> nod
<davecheney> jcastro: it may be that too many charms use /usr/bin/juju-* for their tools
<davecheney> and we have to support that as legacy
<jcastro> I can file and fix those, I'll see how many we have
<davecheney> or maybe that is just a mistake, and was never actually how you were supposed to interface with charms
<jcastro> if it's like a handful, nbd
<davecheney> charm-hooks
<davecheney> either way, maybe charm-lint can help
<davecheney> but this is why I want to get with m_3 and abuse his charm testing harness
<wallyworld_> anyone seen long delays in mails to juju-dev coming through before?
<davecheney> wallyworld_: rog complains a lot that he doesn't get the mesasges at all
<davecheney> have seen some weird shit this morning
<wallyworld_> :-(
<wallyworld_> ok, thans, not just me then
<wallyworld_> i sent a message over an hour ago and nothing received yet
<wallyworld_> the is guys say they are moving to a new mailing list server this morning, so that probably explains it
<davecheney> the mail queues on LP are probably massive
<davecheney> that thing sends lots of mail
<wallyworld_> yeah, you noticed :-
<wallyworld_> )
<wallyworld_> jam: g'day, got time for a quick catch up?
<jam> wallyworld_: certainly, mumble, or IRC?
<wallyworld_> mumble
<wallyworld_> jam: http://169.254.169.254/1.0/meta-data/instance-id
<jam> wallyworld_: http://docs.openstack.org/trunk/openstack-compute/admin/content/metadata-service.html
<jam> http://169.254.169.254/openstack
<jam> http://169.254.169.254/openstack/2012-08-10/meta_data.json
<jam> http://169.254.169.254/openstack/latest/meta_data.json
<wallyworld_> curl http://169.254.169.254/openstack/2009-04-04/meta_data.json
<wallyworld_> status-error: instance i-000d85a9 for machine 0 not found
<wallyworld_> https://pastebin.canonical.com/85724/
<bigjools> people still use mumble?
<wallyworld_> why not?
<wallyworld_> bigjools: why you not like mumble?
<wallyworld_> jam: btw, i apt updated today and lsb_release just started working, go figure
<jam> bigjools: it tends to work better with high-latency low-bandwidth situations than G+
<bigjools> mumble is far worse every time I use it
<bigjools> far far worse
<bigjools> now that g+ has a bandwidth slider, it's very usable with slower links
<dimitern> fwereade: ping
<rogpeppe> mornin' all
<dimitern> rogpeppe: morning
<dimitern> rogpeppe: is there a way to get into a mongo shell while some test is running to see what's getting set in the db?
<dimitern> rogpeppe: maybe pause it for a while, so i can inspect the collection
<rogpeppe> dimitern: not AFAIK
<rogpeppe> dimitern: there are probably a few ways you could hack it if you wanted to do that
<dimitern> rogpeppe: hmm... maybe if I put a time.Sleep in the test just after the change and try to connect to the mongo shell?
<rogpeppe> dimitern: that's definitely a possibility
<rogpeppe> dimitern: you'll probably want to print out the port number that mongo's listening on (or you could get it from the mongo command line args from ps i suppose too)
<dimitern> rogpeppe: i'll try that
<jam> rogpeppe: I'm trying to write some code that uses a function pointer, and I'd like to assert that it points to what I think it should.
<jam> However, if I do: c.Assert(myPointer, Equals, TheFunc)
<jam> I get "comparing uncomparable type"
<rogpeppe> jam: you can't compare function pointers
<rogpeppe> jam: (what does it mean to compare closures?)
<jam> rogpeppe: but (a) Why not? and (b) what is the workaround so that you know what you are actually pointing to
<jam> rogpeppe: It is an instance of a function
<jam> which would have a unique value (IMO)
<jam> but regardless, there are *lots* of funcs which are not closures
<rogpeppe> jam: originally you could compare func pointers, but the functionality was removed
<rogpeppe> jam: because it leaves the implementation free to do different things
<jam> rogpeppe: so, what is a sane way to ensure that "after doing X, my function pointer is pointing at Y" ?
<rogpeppe> jam: in particular, if i have: func foo() func() {return func(){}}, does foo() == foo() ?
<rogpeppe> jam: you could call it and check it does the expected thing
<jam> rogpeppe: well generally I would say no, but I'm fine with that being implementation defined.
<rogpeppe> jam: i think they wanted to avoid implementation-defined equality
<jam> but for "var myFunc func() = goose.Func" I'd like to actually assert what it points to.
<rogpeppe> jam: you can actually do it with reflect
<jam> rogpeppe: not allowing comparison of closures (because they are pointers + state) is diff than not being able to inspect this pointer I have.
<jam> rogpeppe: reflect.?
<jam> http://stackoverflow.com/questions/9643205/how-do-i-compare-two-functions-for-pointer-equality-in-the-latest-go-weekly I guess
<rogpeppe> jam: comparing reflect.ValueOf(f).Pointer() will probably work
<rogpeppe> jam: the representation of function pointers has just changed in tip, BTW
<rogpeppe> jam: closures are a lot more efficient now
<rogpeppe> jam: https://groups.google.com/forum/#!searchin/golang-dev/plan$20for$20two-word$20funcs/golang-dev/x328N8hiN5k/YSzpv2DxPiIJ
<rogpeppe> jam: FWIW i was a bit disappointed we lost function equality, but i can see their point too.
<dimitern> I have a review of medium complexity about upgrade-charm stuff, which I'd appreciate your comments about https://codereview.appspot.com/7363060/ (my first dealings with state/, although with a lot of help from fwereade - tyvm!)
<rogpeppe> fwereade: any chance you could take a look at https://codereview.appspot.com/7390043 ? its prereqs are now merged - i think it should be ready to go.
<fwereade> rogpeppe, ok, looking now
 * TheMue today has early lunch
<dimitern> fwereade: ping
<fwereade> rogpeppe, LGTM
<fwereade> dimitern, pong
<dimitern> fwereade: hey, can you take a look at this please? especially the tests for refcounts https://codereview.appspot.com/7363060/
<fwereade> dimitern, sure
<rogpeppe> fwereade: thanks!
<rogpeppe> fwereade: i wouldn't mind a chat about some of the stuff i'm planning for the gui folks, perhaps sometime later this morning?
<fwereade> rogpeppe, might end up being this afternoon... grab me at 2 if I haven't pinged you before then
<rogpeppe> fwereade: k
<fwereade> dimitern, LGTM with some things to address
<fwereade> dimitern, I like the refcount tests but I don't like the ServiceSettingsRefCount func itself, I think it can be simpler
<fwereade> dimitern, tyvm for that
<dimitern> fwereade: cheers
<dimitern> fwereade: i'm open to advice how to simplify it :)
<fwereade> dimitern, I think just treat mgo.ErrNotFound as 0, and pass all other errors through directly
<fwereade> dimitern, the looping in only necessary when writing, reading should Just Work
<dimitern> mgz, jam, wallyworld_: i'll be 10m late for the standup
<dimitern> fwereade: yeah, I did that because it failed for some reason unknown (until I saw the svcName was wrong :)), i'll remove the loop
<fwereade> dimitern, cool
<dimitern> fwereade: in the process i learned a lot about mongo's QL and some internals :)
<dimitern> fwereade: am I right to assume this CL fixes bug 1063621 ?
<_mup_> Bug #1063621: upgrade-charm should handle config changes <upgrade-charm> <juju-core:In Progress by dimitern> < https://launchpad.net/bugs/1063621 >
<mgz> jam, wallyworld_: around yet for standup?
<dimitern> fwereade: I addressed the issues
<dimitern> anyone else for a review of https://codereview.appspot.com/7363060/ ?
<jam> mgz: wallyworld_ is at his conference today
<rogpeppe> jam: reviewed https://codereview.appspot.com/7406054/
<rogpeppe> dimitern: i'll have a look
<dimitern> rogpeppe: cheers
<rogpeppe> dimitern: just a quick question: why do the settings ref counts need to be in a separate collection from the settings themselves?
<rogpeppe> dimitern: reviewed
<dimitern> rogpeppe: tyvm
<dimitern> rogpeppe: well, that was fwereade's suggestion
<rogpeppe> dimitern: i'm interested in the reasoning behind it (i'm not saying it's wrong, just wondering)
<fwereade> dimitern, rogpeppe: I'm not sure that it's a good idea to have refcount changes counted as config changes
<dimitern> rogpeppe: can't recall the exact reasoning, but it was something to do with the settings being used in more places than just for the services
<rogpeppe> fwereade: ah, i see
<dimitern> fwereade: right :) sorry
<fwereade> dimitern, rogpeppe: also, I don't really love the existing field-stripping magic , and don't really want to do more of it especially when there are multiple settings users but only one case where we need refcounting
<rogpeppe> fwereade: mind you, the changes are so rare it probably makes no difference (and we have to deal with the case of a change with nothing actually changed anyway, right?)
<rogpeppe> fwereade: where's the field-stripping magic?
<fwereade> rogpeppe, we certainly do, but I thnk an extra config-changed for every unit in a service adds up to quite a lot of unnecessary churn
<fwereade> rogpeppe, the _id, txn-revno stuff
<fwereade> rogpeppe, we unmarshal the doc into a dict and strip out the magic keys
<rogpeppe> fwereade: hmm, does this mean we can't have a charm config with a setting called "txn-revno"?
<fwereade> rogpeppe, I think you are probably right about that
<rogpeppe> fwereade: hmm, seems wrong. we should probably prefix all the config map keys
 * fwereade adds another line to his "why I hate Settings" list
<rogpeppe> dimitern: might be good to add a comment somewhere explaining the reasoning behind having the refcounts separate from the things they're refcounting
<rogpeppe> dimitern: LGTM overall
<dimitern> rogpeppe: will do, thanks
<dimitern> rogpeppe: so txn.Op{..., Insert: map[string]interface{}(nil), ...} should be fine you think?
<rogpeppe> dimitern: i don't see why not.
<dimitern> rogpeppe: ok then
<rogpeppe> dimitern: if it doesn't work then i'd consider it an mgo bug
<dimitern> :) indeed
<rogpeppe> dimitern: for read only purposes, a nil map is usually considered the same as an empty map
<dimitern> rogpeppe: even if you access a key inside?
<rogpeppe> dimitern: yeah
<rogpeppe> dimitern: it just returns the zero value for the key
<dimitern> rogpeppe: cool!
<rogpeppe> dimitern: and you can range over a nil map just fine too
<dimitern> rogpeppe: yeah, i knew that, just wasn't sure m[k] would
<rogpeppe> dimitern: from http://golang.org/ref/spec#Map_types: "A nil map is equivalent to an empty map except that no elements may be added."
<dimitern> rogpeppe: right! so append and set will fail, other stuff works
<rogpeppe> dimitern: no append on maps, but yeah
<dimitern> rogpeppe: ofc :) multi-tasking..
<fwereade> dimitern, rogpeppe: https://codereview.appspot.com/7375059 should be simple, and I've checked it actually works
<dimitern> fwereade: looking
<dimitern> rogpeppe: I addressed you suggestions wrt https://codereview.appspot.com/7375059 , so I'm submitting it, unless you want to take one last look?
<rogpeppe> dimitern: looking
<rogpeppe> dimitern: i presume you meant https://codereview.appspot.com/7363060/
<dimitern> rogpeppe:  :) oops, yeah - sure
<rogpeppe> dimitern: replied (LGTM with one trivial)
<dimitern> rogpeppe: thanks
<dimitern> fwereade: btw, am I right to assume my CL fixes bug 1063621 ?
<_mup_> Bug #1063621: upgrade-charm should handle config changes <upgrade-charm> <juju-core:In Progress by dimitern> < https://launchpad.net/bugs/1063621 >
<fwereade> dimitern, you, know, I think it does :) nice
<dimitern> fwereade: cheers :)
<rogpeppe> fwereade: reviewed
<rogpeppe> fwereade: any chance of a chat?
<fwereade> rogpeppe, yeah, sgtm
<rogpeppe> fwereade: https://plus.google.com/hangouts/_/0b304dec0f851f247e957bc221cae25bb5a5d8e4?authuser=0&hl=en-GB
<fwereade> rogpeppe, cheers, there in a sec
<rogpeppe> fwereade: i'll juju pop downstairs for a sec too
<dimitern> fwereade: nice one, reviewed
<mgz> wait, what does `juju pop downstairs` do? :)
<dimitern> mgz: pretty cool, eh? that's the new command :D
<dimitern> it has to have --force as well
<rogpeppe> mgz: good question. things are getting quite sad when "just" becomes "juju"
<mramm> joining meeting, computer just slow...
<dimitern> fwereade: when you have some time, can you take a look at https://codereview.appspot.com/7363061
<dimitern> fwereade: this should cover all the relation compatibility checks and, combined with the previous CL should resolve bug 1032557 (part of the bug was actually fixed with the prev CL I think)
<_mup_> Bug #1032557: upgrade-charm should handle relation changes <upgrade-charm> <juju-core:In Progress by dimitern> < https://launchpad.net/bugs/1032557 >
<fwereade> dimitern, sorry, it's a bit trickier than that -- you need to check the endpoints for all relations the service is in, rather than *all* the endpoints that *might* be being used
<dimitern> fwereade: hmm I wasn't sure Endpoints() includes only active ones
<dimitern> fwereade: but this is a good start, no?
<fwereade> dimitern, I'm not 100% sure it's leading in the right direction, let me think a mo
<fwereade> dimitern, g+ maybe?
<dimitern> fwereade: ok
<fwereade> dimitern, https://plus.google.com/hangouts/_/818eb5f2e744d376413650e8413f1865123d1e27?authuser=0&hl=en
<rogpeppe> fwereade: oh yes, i've remembered the reason for having the key generation in environs.Bootstrap rather than in the command itself
<fwereade> rogpeppe, oh yes?
<rogpeppe> fwereade: it's because we want people to be able to bootstrap easily even if they're using the juju Go interface rather than the command line
<rogpeppe> fwereade: although to be honest, i wouldn't mind an extra step there to generate the certs
<fwereade> rogpeppe, yeah, I probably wasn't clear -- I didn't think the actual functionality should be in the bootstrap command, just its onvocation
<rogpeppe> fwereade: the important thing is that nothing in the environs package *needs* to be able to access the user's home directory.
<fwereade> rogpeppe, yes, indeed
<rogpeppe> fwereade: at least, that was a significant consideration in the current design
<fwereade> rogpeppe, I agree that assuming access to home is not sensible
<fwereade> rogpeppe, btw, I submit for your consideration without comment: http://paste.ubuntu.com/5571065/
<fwereade> rogpeppe, does that look crazy to you?
<fwereade> rogpeppe, I'm thinking of Environ.Servers rather than StateInfo
<rogpeppe> fwereade: i'll be interested to see the design you end up with. i'm sure it's possible to do better than the current one.
<rogpeppe> fwereade: looking
<fwereade> rogpeppe, it's a matter of figuring out what I can do step by step
<rogpeppe> fwereade: i'm not really sure that it's worth separating the port from the addresses
<rogpeppe> fwereade: we might want the ability to serve on different ports
<rogpeppe> fwereade: and the usual "host:port" syntax works ok
<fwereade> rogpeppe, hmm... I'm not sure it's worth passing the port around separately, either
<fwereade> rogpeppe, I wouldn't feel too bad about making an environment pick ports at startup time
<rogpeppe> fwereade: so we add Environ.Servers() Servers ?
<fwereade> rogpeppe, yeah
<rogpeppe> fwereade: that sgtm
<fwereade> rogpeppe, it seems like the clients won;t be bothered -- it'll actually be more convenient to pass in entityName, password, rather than futz with the returned *Infos
<fwereade> rogpeppe, and it also makes it much more convenient as an input when generating machine config
<rogpeppe> fwereade: yeah, i think the Servers idea works well. i like the distinction between entity-less Servers and entity+password Info
<fwereade> rogpeppe, ok, I'll explore that a little more... I have something on the tip of my brain, iykwim, but the whole thing's not quite there yet
<fwereade> rogpeppe, but that feels like it'll eliminate some of the accidental complexity that is slowing me donw
<rogpeppe> fwereade: i'd stick to the usual APIHosts []string with port numbers as part of the string though.
<fwereade> rogpeppe, I kinda want the struct to still be meaningful with "localhost" tacked on
<rogpeppe> fwereade: i'm not sure i understand. what's wrong with localhost:17007 ?
<rogpeppe> fwereade: ah, i see
<fwereade> rogpeppe, I can pass a Servers, with or without addresses, into some sort of machine-configgy thing, and it will work when setting up (1) a bootstrap state server, add localhost to [], (2) a normal machine, don't add anything, and (3) a state server with others already existing, add localhost to [other,servers]
<rogpeppe> fwereade: isn't that up to the thing managing bootstrap - it should know what port it's starting the server on, and therefore be able to attach the right port number to localhost
<rogpeppe> fwereade: the machine-configgy thing is responsible for starting the server, right?
<fwereade> rogpeppe, it's really just about how we pass that information around
<fwereade> rogpeppe, indeed -- so knowing the ports and not always keeping them bound up inside addresses is kinda convenient
<rogpeppe> fwereade: i think there's a significant difference between "these servers are listening on these ports" and "i want to start this server listening on this port"
<rogpeppe> fwereade: that's why APIPort is a separate field in agent.Config
<fwereade> rogpeppe, what's your use case for varying ports within an environ?
<rogpeppe> fwereade: i have a vague thought in my head about running a dynamic number of API servers on the same box
<rogpeppe> fwereade: particularly when stress testing
<fwereade> rogpeppe, not quite sure what case that simulates
<fwereade> rogpeppe, wait a sec... agent.Config? need to check that
<rogpeppe> fwereade: i'm not sure either currently. perhaps that particular use case is bogus. it just seems to me that it's trivial to get this generality at this point, and might be hard to get it back later.
<rogpeppe> fwereade: sorry, agent.Conf
<rogpeppe> fwereade: (not really sure why i chose Conf rather than Config as a name there :-])
<fwereade> rogpeppe, hmm... so we squish *all* the fields that *might* be used for an agent into the same file?
<rogpeppe> fwereade: yeah. beats having lots of different files.
<fwereade> rogpeppe, not quite convinced there, but I need to go to the shops
<rogpeppe> fwereade: ok
<fwereade> rogpeppe, have a good night, might be off for a while
<rogpeppe> fwereade: you too
<rogpeppe> fwereade: i'll be around until about 8pm your time
<niemeyer> fwereade: Any chance of a review on this today: https://codereview.appspot.com/7387054
<niemeyer> Oh,  I guess William is the one leaving
<niemeyer> rogpeppe: ^
<rogpeppe> niemeyer: looking
<rogpeppe> niemeyer: ping
<niemeyer> rogpeppe: Yo
<rogpeppe> niemeyer: just looking at sortableCounters.Less
<niemeyer> rogpeppe: yep
<rogpeppe> niemeyer: i'm not sure i understand your Key logic - can't you just do if ki != kj { return ki < kj } ?
<niemeyer> rogpeppe: []string
<rogpeppe> niemeyer: doh!
<rogpeppe> niemeyer: the ordering isn't fully done though, istm, if len(kj) > len(ki)
<rogpeppe> niemeyer: or don't you care about that?
<niemeyer> rogpeppe: No, you're right.. if there are pending items there it can return
<rogpeppe> niemeyer: cool. worth fixing.
<niemeyer> rogpeppe: +1
<rogpeppe> niemeyer: reviewed
<niemeyer> rogpeppe: Thanks!
<niemeyer> rogpeppe: Responded
<rogpeppe> g'night all
<thumper> night rogpeppe
<thumper> hi mramm
<mramm> hi
<thumper> mramm: want to get started early?
<mramm> sorry was in a meeting
<mramm> done now, so we can start a little early
<benji> I /think/ my mongodb has become dirtied.  I have a test failure on a clean trunk branch that I'm pretty sure I didn't have before.  Is that a reasonable hypothesis?
<benji> any suggestions as to what could be going wrong here: http://paste.ubuntu.com/5571811/
<niemeyer> benji: Pointer vs. non-pointer?
 * thumper sighs
<bac> benji: that has been fixed in trunk i think
<thumper> davecheney, mramm:  Question: I'm wanting to merge my branch, but when I run the tests locally (just prior to merging) I get an unrelated test failure in openstack storage, should I fix that separately first, or merge my code in then fix it?
 * thumper sighs more
<thumper> I get multiple test failures on trunk in quantal
<thumper> does anyone else get them?
<thumper> one obvious one is environs/openstack/storage.go where the List interface says the results are in alphabetical order, but the method doesn't sort the results
<thumper> and the test fails
<thumper> and 9 failures for worker/uniter
 * thumper unmerges trunk so he can continue to work with confidence
<benji> yay! the tests pass on a freshened trunk; one thing that threw me off was that "bzr pull" didn't work without a "from"; I wonder if that is a cobzr thing
<thumper> benji: I just pulled trunk, and I get test failures :(
<niemeyer> Anyone up for a quick review?
<niemeyer> https://codereview.appspot.com/7407052
<thumper> niemeyer: let me say how much I hate bool flags to change the functionality
<thumper> especially in a public api
<niemeyer> thumper: You feel like it obscures the call?
<thumper> it means you see things like: SumCounter(true) or SumCounter(false) and have NFI what it means
<thumper> well, with extra strings
<thumper> it is something I've been trying to avoid since reading Clean Code
<niemeyer> thumper: Yeah, that's a fair point
<thumper> niemeyer: have you read it?
<niemeyer> thumper: It's not what the CL is about, though
<thumper> it is a very good book
<thumper> no, I can see that
<niemeyer> thumper: I've read a few of the articles there
<niemeyer> thumper: Haven't read it all
<niemeyer> thumper: I should
<thumper> but I don't have enough context to know if the change is a good thing or not
<thumper> I can say the code looks fine, but can't approve the functionality
<niemeyer> thumper: Cool, you can kind of trust me on the functionality side
<thumper> haha
 * thumper trusts no one
<thumper> no one I tell you
<niemeyer> thumper: The property on the CL description is sensible is what I mean
<thumper> niemeyer: do I read this right, we are creating javascript functions to pass to mgo to do stuff?
<niemeyer> thumper: ATM counting mysql:* includes mysql itself, which means we don't get the count for the user branches only
<niemeyer> thumper: Which isn't very useful
<davecheney> thumper: short version to get your trunk passing
<davecheney> rm -rf $GOPATH/src/launchpad.net/goose
<niemeyer> thumper: and makes listing and summing uneven
<davecheney> go get launchpad.net/goose/...
<thumper> again?
<niemeyer> thumper: If fixing that isn't a good idea I'll be surprised at least :)
<davecheney> goose and whatever openstack expects are out of sync
<niemeyer> thumper: and yes, you read it right.. map reduce is MongoDB is done like that
<davecheney> probably because your branck contains an older openstack
<niemeyer> davecheney: Hey Dave
<davecheney> niemeyer: hey mate, long time no talk
<niemeyer> davecheney: Indeed!
<davecheney> congratulations btw
<niemeyer> davecheney: On? :)
<davecheney> oh, sorry, never mind
<davecheney> forget i said anything
<niemeyer> davecheney: Ok, can I keep the congrats at least? ;-D
<davecheney> always
<davecheney> never turn down praise
<niemeyer> davecheney: Btw, any chance of a review on https://codereview.appspot.com/7407052/?
<niemeyer> davecheney: LOL
<davecheney> just smile and look humble :)
 * davecheney looks
 * thumper will beat the secret out of davecheney later
<niemeyer> davecheney: This is just a smoothing out change.. nobody will even care much, I think
<davecheney> niemeyer: i'll keep my gob shut until it's announced then
<thumper> davecheney: even with latest goose, trunk fails 9 tests in worker/uniter
<niemeyer> davecheney: I was talking about the branch.. LOL
<davecheney> niemeyer: branch LGTM, i'll leave it to you to argue about the bool with thumper
<niemeyer> davecheney: Cool, thank you
<davecheney> i take the position that it was there before ths CL, so you can argue about it out of context with this change
<niemeyer> davecheney: I agree with him that bools aren't great as an interface
<niemeyer> davecheney: But that's not part of this CL
<niemeyer> fwereade: Heya
<thumper> what do you guys mean when you say "CL"
<niemeyer> davecheney: Good idea, I'll add it
<niemeyer> davecheney: I mean, a:b:c
<niemeyer> thumper: Change List.. It's a historical name for the issues in Rietveld that, to be honest, I don't even know where it comes from.
<thumper> davecheney: I don't suppose I could get you to pull trunk and see if the tests pass for you could I?
<thumper> ah...
 * thumper goes to look for food in the kitchen
<davecheney> thumper: doing so now
<davecheney> thumper: i'm moderatly confident that trunk isn't broke
<davecheney> as my daily build has not broken
<davecheney> but that still means we need to find the right versions of goose to match environs/openstack in your branch
<thumper> well, I pulled trunk of both
<thumper> so they should work, right?
<davecheney> testing now
<davecheney> hmm, two build failures in worker/uniter/charm
<thumper> davecheney: I'll pastebin my errors
<davecheney> thumper try to up to rev 942
<davecheney> jacuse rev 943
<thumper> jacuse?
<davecheney> http://en.wikipedia.org/wiki/J'accuse
<davecheney> thumper: got that paste ?
<thumper> http://paste.ubuntu.com/5572091/
<thumper> heh
<thumper> oops
<davecheney> hmm, that error may be spurious @ 943
<thumper> http://paste.ubuntu.com/5572096/
<davecheney> thumper: i think those are genreal test flakeyness errors
<davecheney> there are a few similar errors logged on LP
<thumper> I get them consistently
<thumper> like, every time
<thumper> didn't get them before
<davecheney> yeah, they are very timing related
<davecheney> get a slower machine (not helpful)
<thumper> davecheney: this is running in a vm...
<davecheney> that explains why sleeps don't work properly
<davecheney> there is some other weird shit in that paste
<davecheney> value *os.PathError = &os.PathError{Op:"open", Path:"/tmp/gocheck-63205844/0/agents/unit-u-0/state", Err:0x15} ("open /tmp/gocheck-63205844/0/agents/unit-u-0/state: is a directory")
<davecheney> it is possible the test isn't stopping properly at that error
<davecheney> thumper: please raise a critical on LP
<thumper> saying what exactly?
<thumper> on juju-core?
<davecheney> yes
<davecheney> worker/uniter: multiple test failures
<davecheney> desc: can't run tests reliably, fail every time (see attached)
<thumper> well... just ran the worker tests without everything else, and they passed FFS
<thumper> running all again to see what happens
<thumper> oh FFS, all pass now
<wallyworld_> davecheney: hi, a quick clarification on your concern about returning an unexported error
<wallyworld_> i coped the pattern used already in the state package for notFoundError
<wallyworld_> i guess the original author didn't want people to access anything other than Error() ?
<wallyworld_> that fact that we don't need the error exported (it's not used anywhere) - does that imply it can stay as is for now?
<davecheney> wallyworld_: on da phone, two secs
<wallyworld_> np
<wallyworld_> my preference is for consistency, so it i change one, the other should be changed to match
#juju-dev 2013-02-28
<thumper> davecheney: bug 1134959
<_mup_> Bug #1134959: worker/uniter: multiple test failures <juju-core:Triaged> < https://launchpad.net/bugs/1134959 >
<arosales> davecheney: aroun?
<arosales> around, that is :-)
<davecheney> arosales: two secs
<davecheney> still on the phone
<davecheney> thumper: thanks
<arosales> davecheney: thanks
<arosales> davecheney: when you are free I am using a the following for hpcloud in the environments.yaml file: http://pastebin.ubuntu.com/5572190/
<arosales> and I am getting the error error: secret-key: expected nothing, got "<redacted>"
<arosales> davecheney: I have tried variations of adding in "tenant-name" and "region" with no sucess
<arosales> *success, that is.
<arosales> I did get AWS to bootstrap though and deploy wordpress/mysql
<davecheney> arosales: just finishing up
<davecheney> arosales: tip: remove secret key
<davecheney> it isn't used in our juju
<davecheney> i think it was optional in 0.6
<arosales> access key too?
<davecheney> arosales: I usually let those flow through from sourceing .novarc
<arosales> davecheney: I am not sourcing a novarc file
<arosales> so I think I need them somewhere
<arosales> davecheney: aws set up worked, with the keypair access set up. Specifically putting in my access-key and secret-key embedded in the environments.yaml file.
<arosales> its just hpcloud environments.yaml file that is giving me guff.
<davecheney> arosales: ok, you have my complete attention :)
<arosales> :-)
<arosales> tldr I can't get hpcloud environment.yaml to work with go-juju
<davecheney> i've only tested against canonistack, and I let the valyes flow throught from sourceing my .novarc
<arosales> my env.yaml for hpcloud is @ http://pastebin.ubuntu.com/5572190/
<davecheney> lets see what I am missing
<wallyworld_> arosales: if you have the latest go juju you can run "juju generate-config" and it will give you a boilerplate file
<arosales> wallyworld_: thanks, I also tried using that template
<davecheney> ^ what wallyworld said
<arosales> but no go
<wallyworld_> you should just havve needed to change the auth url
<wallyworld_> worked for me anyway
<arosales> wallyworld_: and add in my credentials
<wallyworld_> what version of juj you running?
<arosales> wallyworld_: I agree, but alas no bootstrap
<wallyworld_> arosales: i just source a nova rc for that so they come from env vars
<arosales> wallyworld_: 1.9.9-2~923~quantal1
<wallyworld_> ok, latest version then
<arosales> wallyworld_: davecheney: so it is a requiment to source a novarc then?
<arosales> and if not get breakage?
<wallyworld_> no, but if not, you need to have env vars set or edit the yaml
<davecheney> arosales: sorry, you've probably done this already, can you paste the output when you do
<davecheney> juju bootstrap --debug -e '$YOURENV'
<arosales> wallyworld_: I got those creds in the yaml directly
<wallyworld_> ok
<davecheney> you can use paste.canonical.com for more private stuff
<wallyworld_> incl region and tenant etc?
<arosales> let me sanitize the output real quick
<arosales> davecheney:
<arosales> $ juju --debug bootstrap -e hpcloud
<arosales> 2013/02/27 18:53:59 JUJU environs/openstack: opening environment "hpcloud"
<arosales> 2013/02/27 18:53:59 JUJU juju bootstrap command failed: secret-key: expected nothing, got "<redacted>"
<arosales> error: secret-key: expected nothing, got "<redacted>"
<davecheney> remove the secret-key line from your enviornment.yaml
<davecheney> you may have to remove others
<wallyworld_> arosales: can you pastebin your yaml - it seems out of date
<davecheney> did generate-config generate this config ?
<davecheney> or is this an old one that used to work with 0.6
<arosales> davecheney: if I remove the secret key how do I authenticate?
<davecheney> secret-key is a noop in our juju
<arosales> wallyworld_: http://pastebin.ubuntu.com/5572190/ is my latest env.yaml I made from the boilerplate
<wallyworld_> arosales: you sure?
<arosales> davecheney: I tried my config from juju-py and it didn't work so I tried with the boilerplate
<arosales> wallyworld_:  yes :-)
<wallyworld_> ah ok, did you replace the admin-secrect with redacted?
<arosales> wallyworld_:  I am crazy most the time, but I just did this ;-)
<wallyworld_> it should have been a random nmber of sorts
<arosales> wallyworld_: correct, I don't want to post my keys in the public ;-)
<arosales> wallyworld_: I did get aws bootstraped, just hp giving me issues.
<wallyworld_> auth mode should be userpass i think
<davecheney> arosales: go juju does not use the secret-key configuration item
<davecheney> you have to remove it
<arosales> wallyworld_: for authmod = keypass ?
<davecheney> arosales: i don't thikn goose supports that either
<davecheney> the only methods it supports is legacy and userpadd
<davecheney> userpass
<wallyworld_> arosales: what i meant before was that i think an earlier version of the boilerplate did have "redacted" in it
<arosales> davecheney: so this is a bug then
<arosales> davecheney: I think what you are telling me is I need to have my keys in a novarc, and it _can't_ be embedded in the env.yaml
<wallyworld_> arosales: authmode should be userpass
<arosales> correct?
<wallyworld_> keypair is not supported yet
<wallyworld_> for openstack
<arosales> really?
<arosales> :-(
<wallyworld_> not a bug, just not supported
<arosales> most folks use keys
<arosales> bug for 13.04 by default
<arosales> at lest in my opinion
<davecheney> arosales: I will raise a bug
<davecheney> you are correct
<davecheney> the way the configuration works is
<davecheney> most items in ~/.juju/environments.yaml
<arosales> davecheney: I can open the bug, I just wan't sure if it was pilot error
<wallyworld_> arosales: its just that we have not ad the resources to get to it yet
<davecheney> will take values from ENV values if they are missing from the yaml file
<arosales> wallyworld_: understood, I just wanted to ask more folks to use go-juju and ran into this
<arosales> should be noted in the release notes.
<arosales> under known bugs
<davecheney> arosales: I will make sure it is noted in the next release notes
<wallyworld_> userpass works ok with hpcloud :-)
<arosales> wallyworld_: ok, I"ll give that a try later tonight
<arosales> wallyworld_: davecheney thanks for the help
<arosales> davecheney: would you like me to open the bug
<wallyworld_> hence we needed to get other stuff working first :-)
<davecheney> arosales: yes please
<arosales> davecheney: will do
<arosales> I'll get that logged later tonight.
 * arosales needs to attend to some daddy duty
<wallyworld_> arosales: also, i found a showstopper yesterday which we are fixing asap - go juju won't be able to deploy to hp clound until fixed, even once you get your env sorted
<arosales> ah, ok
 * davecheney thinks he knows what that one is :)
<arosales> wallyworld_: could you give me a ping when that lands in the ppa?
<arosales> or even to the juju list would be better
<wallyworld_> arosales: sorry :-( still a work in progress, trying to get it done asap
<wallyworld_> arosales: sure, no problem. aiming for next release hopefully
<davecheney> arosales: there is a juju-core-daily ppa
<arosales> wallyworld_: thanks
<davecheney> which you can use if you're super keen
<wallyworld_> arosales: thanks for your patience also, and sorry for the issues
<arosales> davecheney: I may have to use that to get the fix
<arosales> wallyworld_: no worries part of trying out bleeding edge :-)
<arosales> thats part of the fun right?
<wallyworld_> oh yes, very bleeding right now
 * arosales has to run
<arosales> later fellas
<arosales> be back online later tonight though
<arosales> thanks again
<wallyworld_> ok, see ya
<davecheney> arosales: thanks for being a beta tester, i'll buy you a chocolate or a teddy bear in Altanta as a boobie prize
<wallyworld_> davecheney: so about that mp....
<davecheney> wallyworld_: sorry, a lot has scrolled off the screen
<wallyworld_> yeah :-) np
<wallyworld_> [09:53:17] <wallyworld_> davecheney: hi, a quick clarification on your concern about returning an unexported error
<wallyworld_> [09:53:38] <wallyworld_> i coped the pattern used already in the state package for notFoundError
<wallyworld_> [09:54:25] <wallyworld_> i guess the original author didn't want people to access anything other than Error() ?
<wallyworld_> [09:55:24] <wallyworld_> that fact that we don't need the error exported (it's not used anywhere) - does that imply it can stay as is for now?
<davecheney> ahh,yes
<davecheney> sorry
<wallyworld_> np
<davecheney> ok, as I understand it
<davecheney> if you return a private type, with a public Error method
<davecheney> that satisfied the error interface
<davecheney> but callers may not be able to use a type asserting to tell what kind of error it is
<wallyworld_> davecheney: there's a helper mthod for that
<wallyworld_> IsNotFound()
<wallyworld_> IsUNauthorised()
<davecheney> having said that, it looks like the method was doing the wrong thing
<davecheney> in which case, it does not help to comment that the type of the error will be x (little x, not exported) becuase there is nothing that can be done with that information
<davecheney> maybe in return you could replace the text with a hint to pass the error to IsNotFound(err)
<davecheney> that was all I ways saying in that comment
<davecheney> returning unexported errors is something that gets on peoples' goat in the stdlibrary
<davecheney> for example, errClosing
<wallyworld_> davecheney: yeah, understood. i have no firm opinion being a Go noob. i was just being consistent with what was already done by someone else for notFounfError
<wallyworld_> so i was going for consistency
<davecheney> ok, lemmie review again, if you've already got 2 LGTM, then don't wait for me
<wallyworld_> davecheney: i don't mind waiting - if there's an idiomatic issue like htis, i'd rather get it sorted instead of having the wrong thing cargo culted. as it is, i copied what was there before
<wallyworld_> i assumed that it was done the right way previously for notFound
<davecheney> ok, bio break, then review
<wallyworld_> davecheney: ok, i have to run an errand, back in a bit and will look
<davecheney> wallyworld_: re your CL
<davecheney> the previous type, ErrUnauthorized was exported
<davecheney> i'll put my comments in the review
<wallyworld_> davecheney: it was, but only because it was a var. the other error commonly used in state package, notFoundError, was not exported.
<wallyworld_> the implementation has changed from a var to a type, and there's a helper method used to discriminate the error type
<wallyworld_> there already is a helper method in the MP too - IsUnauthorised()
<wallyworld_> so, i'll add the comment as requested. thanks for looking
<davecheney> wallyworld_: SGTM, either of those choices is fine
<wallyworld_> ok, np. thanks. i just wanted to be 100% sure you were happy
<davecheney> no, thakn you
<davecheney> this isn't the end of the world
<davecheney> but its nice to go the extra mile
<wallyworld_> there's a fair bit of inconsistency in places
<wallyworld_> and then it gets cargo culted
<davecheney> do you want to raise an issue for the worst offenders
<davecheney> otherwise i fear they may never be addressed
 * davecheney appologises for sounding like a issue whoring broken record
<davecheney> i used to work for an issue tracker company
<wallyworld_> i have no real concrete examples - but as i find them again i should keep a list
<wallyworld_> it's just a general perception
<davecheney> and it was beaten into me that if there was no issue, it didn't happen
<wallyworld_> yeah agreed
<davecheney> i'd like it if you kept that list in an issue
<davecheney> or at a minimum google docs
<wallyworld_> sure.
<davecheney> on your own workstation isn't helpful
<wallyworld_> some of it could be contentious eg error handling
<wallyworld_> i have a philosophical difference in opinion with a few others i think
<davecheney> even more reason to flush it out into the open
<wallyworld_> a list also would determine if my perceptions are real
<wallyworld_> perhaps there's not much to it
 * davecheney shrugs
<davecheney> i dunno how much there is
<davecheney> but setting a precident now is important
<davechen1y> thumper: excellent proposal
<davechen1y> i was going to propose something like that myself
<thumper> davechen1y: I was just about to ping you about it :)
<thumper> just a little editing and the help one is following
<davechen1y> thumper https://bugs.launchpad.net/juju-core/+bug/1134959
<_mup_> Bug #1134959: worker/uniter: multiple test failures <juju-core:Triaged> < https://launchpad.net/bugs/1134959 >
<davechen1y> how come I didn't get a notification about this one ?
<davechen1y> i'm listed as the bugmaster on this project
<davechen1y> or, to put it another way
<davechen1y> how can I change things so I get all notificatoins for all bugs on juju-core
<thumper> I'm not sure...
<thumper> you should have
<thumper> sure you don't have some weird ass email rules?
<davechen1y> i have no email rules
<davechen1y> i hate thunderbird so much
<davechen1y> i'm not going to give it the satisfactoin of asking it to take on more responsibility
<davechen1y> ok, think I fixed it
<davechen1y> i was sure the entire gophers team was subscribed
<wallyworld_> thumper: do you have a copy of juju tools for precise compiled from tip you can share with me?
<wallyworld_> actually, never mind, found some i think
<arosales> wallyworld_: question for you if you are free
<wallyworld_> sure
<arosales> wallyworld_: are there any other package requirements for running go-juju other than juju-core?
<arosales> I retract that question I was able to get AWS deployed, so I think I have the requirements meet
<wallyworld_> \o/
<arosales> hp still giving me some issues
<wallyworld_> yeah, i found problems with jujud and other things, working on fixing now. sadly, hp cloud runs a different version to canonistack = problems
<arosales> wallyworld_: any idea what this error means
<arosales> 2013/02/27 23:29:06 JUJU juju bootstrap command failed: cannot find tools: no compatible tools found
<wallyworld_> arosales:  you need to specify --upload-tools when using bootstrap as there is no well defined public bucket yet like for ec2
<wallyworld_> so for now, when testing, we just upload our own copy
<wallyworld_> there will ultimately need to be a public place where the tools tarball lives which everyone shares
<arosales> wallyworld_: is there a test bucket I can use?
<arosales> I am thinking I need to state something to the effect "juju --upload-tools <something> bootstrap -e hpcloud"
<wallyworld_> not that has been setup. if you use --upload-tools, it just puts a copy in your control bucket, around 2Mb i think
<wallyworld_> just "juju bootstrap --upload-tools -e hpcloud"
<wallyworld_> if you specify a public bucket url in your yaml, it will use that
<wallyworld_> but that implies the tools have been pre-uploaded separately
<wallyworld_> which we will do at some point
<wallyworld_> and publicise the public bucket url, like for ec2
<wallyworld_> but for now, the above bootstrap command does the job
<wallyworld_> bear in mind, bootstrap will fail for other reasons, currently being fixed
<arosales> gotcha
<arosales> interesting how this didn't parse
<arosales> $ juju --debug --upload-tools bootstrap -e hpcloud
<arosales> error: flag provided but not defined: --upload-tools
<arosales> but you way did
<wallyworld_> maybe that neds to go at the end
<wallyworld_> ?
<arosales> yup, worked when I did it your way, odd it parsed it correctly when at the end
<wallyworld_> yeah, odd i agree
<arosales> so it looks like I need have Go in my path?
<arosales> error: cannot upload tools: build command "go" failed: exec: "go": executable file not found in $PATH;
<wallyworld_> ah, you need the juju-core source and go to build the tools. hang on, i'll give you a url from which yo can download the tools tarball and upload manually to your hp cloudcontrol bucket
<wallyworld_> you running precise or qantal?
<arosales> quantal
<wallyworld_> http://juju-dist.s3.amazonaws.com/tools/juju-1.9.9-precise-amd64.tgz
<wallyworld_> sorry, subst quantal in there
<wallyworld_> upload the tarball to a tools dir in your control bucket
<arosales> in the gophers ppa I see "golang-stable" and "cobzr" do I need those?
<wallyworld_> cobzr is for if you are doing devel work
<wallyworld_> golang is Go itself
 * arosales looking for hp cloudcontrol bucket   . . .
<wallyworld_> arosales: i think i had to create mine manually, using the yaml control bucket vaue as the name
<wallyworld_> if you tried bootstrap once, it may have made it for you already though
<arosales> wallyworld_: I should see that in the object store for region 1, correct?
<wallyworld_> depends on the region in your yaml but yes
<wallyworld_> it is for me
<arosales> ah yes, given I am trying to work in region 1
<arosales> I don't see one there so sounds like I need to make one with the name in my env.yaml
<wallyworld_> arosales: fyi, my control bucket is juju-e802cb1c2e3ab47e3e4a1071cef25a9c
<wallyworld_> you may be able to see that one
<wallyworld_> depending on your credentials
 * arosales uploading . . .
<arosales> hrm, still getting the cannot upload tools error
<arosales> http://pastebin.ubuntu.com/5572611/
 * wallyworld_ looks
<wallyworld_> arosales: unless you have the dev stuff installed locally, you need to upload manually the tarball and bootstrap without the upload tools flag
<wallyworld_> upload-tools is more of a dev option
<arosales> ok, I uploaded manually so I'll drop the upload-tools option
<arosales> wallyworld_: closer, but still not finding the tools
<arosales> http://pastebin.ubuntu.com/5572619/
<wallyworld_> arosales: you uploaded quantal tools right? check you yaml and see if there is a default-series value in there
<wallyworld_> if it says precise, you need to comment it out
<wallyworld_> you also need to change the image id to a quantal one
<arosales> and I do have a object store container in az1 matching my control bucket in my env.yaml with juju-1.9.9-precise-amd64.tgz in it
<wallyworld_> 75839 from memory
<wallyworld_> oh, so you have uploaded a precise tarball?
<wallyworld_> i thought you were running quantal?
<arosales> I do have     default-series: precise in my env.yaml but my client is quantal
<arosales> do they need to match
<wallyworld_> no
<wallyworld_> as long as default-series = tools tarball = image type you should be ok
<arosales> correct I uploaded the precise tar file when I noticed my yaml had the default series for precise
<wallyworld_> hmmm. not sure why it is complaining. did you upload tarbal to a tools container in the bucket?
<arosales> ah I don't have it under a tools dir
<wallyworld_> that would do it
<arosales> wallyworld_: nice catch on the missing tools dir, my bad.  That does get me closer
<arosales> http://pastebin.ubuntu.com/5572624/
<arosales> looks like it has m1.small
<arosales> I think for HP that needs to be standard.small, right?
<wallyworld_> arosales: yeah, that has been changed, but may have missed the 1.9.9 release
<wallyworld_> you now specify the flavour in the yaml
<wallyworld_> using default-instance-type
<arosales> via     default-instance-type: standard.small
<arosales> ok
<wallyworld_> but it may not be in the 1.9.9 release
<wallyworld_> that is deprecated btw, until we get constrainst further progressed
<arosales> seem it didn't like that yaml parameter
<arosales> http://pastebin.ubuntu.com/5572629/
<arosales> I can untar the precise yaml and correct
<wallyworld_> arosales: the code to process it may not have made the 1.9.9 release
<wallyworld_> so you might be out of luck until the next drop
<arosales> ah there is just an executable in that tar file
<wallyworld_> yes, jujud
<arosales> ya looks to be that way
<arosales> :-(
<wallyworld_> sorry
<arosales> so close but yet so far
<wallyworld_> go juju works for ec2
<arosales> we wanted to try some scale testing on HP
<wallyworld_> close for openstack, but we only *just* finished the core code and are sorting out the final bits and oieces
<wallyworld_> i'm really hopeful we'll be there for next release
<arosales>  Looks like 1.9.10 is expected on march 9 if all goes well
<arosales> wallyworld_: thanks for your time and help. I was going to write this up and send it out to folks wanting to deploy on HP cloud.  But I'll wait for that once the control tools are ready
<arosales> wallyworld_: would you suggest I use the daily ppa?
<wallyworld_> arosales: no problem, i'm just sorry we're not quite there yet. the daily ppa would have all the latest fixes in it (and maybe also bugs). but i can't be worse than now right
<wallyworld_> s/i/it
<wallyworld_> you still won't be able to get a system fully working though
<wallyworld_> still some more things to sort out
<arosales> ok, perhaps it is best to wait for 1.9.10 then
<arosales> btw, do you have a pointer to the daily?
<wallyworld_> not handy but i can find it
<wallyworld_> arosales: https://code.launchpad.net/~dave-cheney/+recipe/juju-core-daily
<wallyworld_> from there you can grab the one you want
<arosales> wallyworld_: thanks for link, and thanks again for your time to help me step through the openstack setup for HP. Much appreciated
<wallyworld_> no problem at all, please to help.
<wallyworld_> hopefully next time we talk thiings will be working :-)
<arosales> wallyworld_: do you want me to open up a bug on the control file needing updated to have standard.small?
<wallyworld_> arosales: no, already fixed :-)
<wallyworld_> just not in the release yet
<arosales> ok
<arosales> gotcha, enjoy the rest of your day.
<wallyworld_> you too, almost wine o'clock here :-D
<arosales> nice
<arosales> I guess if I were to try the daily on HP I would need a matching control bucket tar file, which probably isn't available just yet . . .
<wallyworld_> correct
<wallyworld_> but you can get one from ec2
<wallyworld_> no
<wallyworld_> i don't think we upload the daily tarballs
<arosales> yup, I didn't see one on ec2 with the urls I tried. have a good evening wallyworld_ ttyl
<fwereade> morning gents
<fwereade> I am reverting to r942, because r943 and all following were committed with failing tests
<dimitern> fwereade: morning
<fwereade> dimitern, heyhey
<fwereade> dimitern, I has a grumpy: please run the full test suite before you submit
<dimitern> fwereade: I saw that bug report about failing uniter tests
<dimitern> fwereade: I *did* several times!
<fwereade> dimitern, frankly, please run it before yu even propose
<fwereade> dimitern, hm, that is odd then
<dimitern> fwereade: I always do
<dimitern> really odd
<fwereade> dimitern, sadly they're failing consistently for me in r943, and ok in r942, so I'm backing everything out until we can figure out what went wrong
<dimitern> fwereade: ok, I'll investigate what went wrong
<rogpeppe> mornin' all
<dimitern> rogpeppe: hiya
<rogpeppe> fwereade: yeah, i get a compilation failure in trunk
<fwereade> rogpeppe, a *compilation* failure? goose maybe?
<dimitern> rogpeppe: where?
<rogpeppe> fwereade, dimitern: it's pretty weird actually:
<rogpeppe> state/assign_test.go:5: cannot use &txn.Op literal (type *txn.Op) as type txn.Op in return argument
<rogpeppe> but that's on an import statement
<dimitern> rogpeppe: hmm
<rogpeppe> i'll blow away $GOPATH/pkg and see if it still happens
<fwereade> rogpeppe, huh, I didn't see that myself :/
<dimitern> rogpeppe: what did you run?
<rogpeppe> dimitern: go test ./...
<rogpeppe> dimitern: in juju-core root
<fwereade> dimitern, rogpeppe: for form's sake, can I get a quick check of https://codereview.appspot.com/7422044
<dimitern> fwereade: I run go test -i ./... && go test ./... in worker/uniter several times when I was changing the uniter tests (to compare timings) - all was fine
<dimitern> fwereade: I'm on it
<fwereade> dimitern, you didn't change the uniter tests in r943 -- that was the SetCharm branch
<dimitern> fwereade: hmm
<dimitern> fwereade: well, yes I confess i didn't run the uniter tests when I did setcharm stuff, because it was only in state/ and all tests there run fine
<fwereade> dimitern, IMO we should *always* be running the full test suite before we commit (really, before we propose)
<rogpeppe> fwereade: +1
<dimitern> fwereade: go test ./... in juju-core/ you mean?
<fwereade> dimitern, we changed behavior in state -- anything that uses state *might* have been depending on something we changed
<fwereade> dimitern, yeah
<rogpeppe> fwereade: we should probably be running the live tests actually.
<dimitern> fwereade: ok, sorry, I promise I'll do that from now on
<fwereade> dimitern, thanks :)
<fwereade> rogpeppe, hmm, what's the point of the double then?
<dimitern> fwereade: i guess all my changes before were isolated enough so running the tests for what I changed was good enough
<fwereade> rogpeppe, if the double can't tell us when we've broken things I question its value
<rogpeppe> fwereade: it means that you get *some* confidence. but it doesn't run all the agents.
<fwereade> dimitern, it's a tempting idea, but it has a tendency to bite one in the ass ;)
<dimitern> rogpeppe: I have this failure in rpc: http://paste.ubuntu.com/5572797/
<rogpeppe> dimitern: can you reproduce it (it works ok for me)
<rogpeppe> ?
<dimitern> rogpeppe: I just ran all tests (still running)
<rogpeppe> fwereade: that compilation failure only happens against go tip. something weird's up.
<rogpeppe> fwereade: i suspect a inlining bug
<fwereade> rogpeppe, grar
<rogpeppe> fwereade: i have an idea where it might lurk actually.
<dimitern> fwereade: instead of reverting everything, can't we just revert my setcharm stuff?
<dimitern> rogpeppe: running all tests again rpc was a PASS
<rogpeppe> dimitern: hmm, i'll have a look at it
<rogpeppe> some days, everything seems broken
<dimitern> but this time I have a build failure in store
<dimitern> # launchpad.net/juju-core/store
<dimitern> store/lpad.go:7: import /home/dimitern/work/go/pkg/linux_amd64/launchpad.net/lpad.a: not a package file
<rogpeppe> dimitern: that does seem weird
<rogpeppe> dimitern: it might be because you interrupted a compilation in an odd place, i suppose
<rogpeppe> dimitern: try blowing away that file and trying again
<dimitern> rogpeppe: that solved it
<dimitern> fwereade: before you revert all that, let me just check if reverting the setcharm cl will solve the issues
<rogpeppe> hmm, i think i've found where my compilation error comes from: 	func (@"".sÂ·2 *@"".Settings "esc:0x0") @"".assertUnchangedOp () (? @"labix.org/v2/mgo/txn".Op) { return &@"labix.org/v2/mgo/txn".Op{ C:@"".sÂ·2.@"".st.@"".settings.Name, Id:@"".sÂ·2.@"".key, Assert:(@"".D{ 0x0:{ Name:"txn-revno", Value:@"".sÂ·2.@"".txnRevno } }) } }
<rogpeppe> there's a spurious & in there
<dimitern> rogpeppe: that seems like the same cl
<dimitern> rogpeppe: my bad again :(
<rogpeppe> dimitern: the code looks fine though
<fwereade> dimitern, I kinda want to roll back to before that point
<fwereade> dimitern, I don't know wtf tim/ian/gustavo were doing committing their changes without running the test suite
<dimitern> fwereade: and after that we selectively reapply each CL to see were it failed?
<fwereade> dimitern, after that it's up to RUN THE TESTS and then maybe resumbit their code
<fwereade> dimitern, I am not exclusively grumpy with you, I am grumpy with everyone who committed to a broken trunk without reverting it
<dimitern> fwereade: fair enough, although I don't think it's fair for other people to suffer if i'm the one to blame (probably)
<fwereade> dimitern, you're the ultimate cause of the failures, but they're responsible for running the tests as well -- if something like this slips through again (which it will, someone will make some series-specific assumption) it should be the detector's responsibility to unbreak, notify the perpetrator, and submit on top of a *clean* trunk
<dimitern> fwereade: yes, you're right - they should've run the tests before landing after it was broken
<dimitern> fwereade: it might be even a good thing to put in the channel topic: RUN juju-core/$ go test ./... BEFORE EVEN PROPOSING A CHANGE :)
<dimitern> fwereade: hmm, it seems maybe I'm not the only one to blame, because reverting the setcharm CL and running the tests they failed in state/watcher/
<rogpeppe> fwereade: FWIW proposing does a merge, so really you should merge trunk, *then* test everything
<fwereade> rogpeppe, what, people aren't already doing this?
<fwereade> rogpeppe, I guess not
<rogpeppe> fwereade: not necessarily before very propose. the problem is it can muddy the diffs
<rogpeppe> s/very/every
<fwereade> rogpeppe, if the diffs are muddied it's because the change to trunk has actually muddied the proposal
<dimitern> fwereade: I merge trunk before proposing ever since I had issues with MPs in LP with MAAS
<fwereade> dimitern, +1
<rogpeppe> fwereade: i always merge before submitting, but not always before every re-propose
<rogpeppe> fwereade: otherwise you see big diffs between the different revisions in codereview, so people can't easily see what you've changed in response to their review
<fwereade> rogpeppe, first propose and final sumbit are the points at which I think there's no excuse
<dimitern> after reverting 943 I have this failure:
<dimitern> FAIL: watcher_test.go:285: WatcherSuite.TestDoubleUpdate
<dimitern> watcher_test.go:295:
<dimitern>     assertNoChange(c, s.ch)
<dimitern> watcher_test.go:82:
<dimitern>     c.Fatalf("watch reported %v, want nothing", got)
<dimitern> ... Error: watch reported {test a 4}, want nothing
<fwereade> rogpeppe, being a bit casual about midstream proposes is probably ok :)
<dimitern> all others pass
<fwereade> dimitern, would you have a quick look in the juju-core bugs? I suspect that is known but intermittent and rare enough that we haven't managed to track it down yet
<dimitern> fwereade: looking
<dimitern> fwereade: I cannot find anything similar, I'll file a bug
<fwereade> TheMue, https://bugs.launchpad.net/juju-core/+bug/1135442
<_mup_> Bug #1135442: local storage test intermittent failure <juju-core:New for themue> < https://launchpad.net/bugs/1135442 >
<dimitern> there it is bug 1135444
<_mup_> Bug #1135444: state/watcher intermittent test failure <juju-core:New> < https://launchpad.net/bugs/1135444 >
<fwereade> TheRealMue, https://bugs.launchpad.net/juju-core/+bug/1135442
<_mup_> Bug #1135442: local storage test intermittent failure <juju-core:New for themue> < https://launchpad.net/bugs/1135442 >
<fwereade> dimitern, rogpeppe, TheRealMue: I'm about to submit https://codereview.appspot.com/7422044
<rogpeppe> fwereade: how much history does it unwind?
<dimitern> fwereade: go for it
<fwereade> rogpeppe, about 5 revs
<rogpeppe> fwereade: i was wondering if it might be better just to unwind dimiter's change
<fwereade> rogpeppe, tim, gustavo and ian *all* committed with broken code
<rogpeppe> fwereade: but was it their code that was broken, or just the one merge that they committed on top of?
<fwereade> rogpeppe, if trunk is broken and you commit to it, you broke trunk too
<rogpeppe> fwereade: i guess so
<dimitern> there is the other rpc bug 1135452
<_mup_> Bug #1135452: rpc: intermittent test failure <juju-core:New> < https://launchpad.net/bugs/1135452 >
<fwereade_> rogpeppe, am I insane? I know I am pissed off but I *think* my judgment is clear here
<fwereade_> rogpeppe, if the tests don't pass, it's not ok to commit
<rogpeppe> fwereade_: i'd probably just unwind the commit that causes the problem, but i know that's more hassle
<fwereade_> rogpeppe, if someone else broke it, you don't get to say "meh, not my problem" and compound the issue
<dimitern> fwereade_: +1
 * fwereade_ submits
<dimitern> now on to making things right again :)
<fwereade> dimitern, cheers :)
<TheMue> fwereade: Oh, thx, will investigate. Have missed your notification.
<fwereade> TheMue, I think you just need to let the system pick the port for each test
<TheMue> fwereade: Yep, no constant value.
<TheMue> fwereade: To avoid the current troubles which rev shall I take? 942?
<fwereade> TheMue, I've reverted everything since r942 so yu should be good to go with tip
<TheMue> fwereade: OK, will do so.
<fwereade> rogpeppe, a thought re running live tests
<fwereade> rogpeppe, we do at least have tests for the userdata we send up with a new instance, right?
<rogpeppe> fwereade: well, some basic sanity checking, yeah.
<rogpeppe> fwereade: but it doesn't actually run anything
<fwereade> rogpeppe, if those checks are not sufficient to guarantee that the userdata still works, I don't think that's enough
<fwereade> rogpeppe, I understand we don't want to run things
<fwereade> rogpeppe, but is it not possible to figure out which bits can change (and how) and which bits can't?
<rogpeppe> fwereade: in the end, how can you test it properly without actually running it on the target machine?
<fwereade> rogpeppe, well, how much actually changes in the userdata from one machine to another?
<fwereade> rogpeppe, AIUI the bulk of it is identical; the bits that change surely do so in a predictable way, right?
<rogpeppe> fwereade: it's not the user data, it's the environment that the user data runs in. the *combination* needs to be tested, no?
<rogpeppe> fwereade: i'm not quite sure where you're going here
<fwereade> rogpeppe, I'm saying that if the userdata changes in a way we don't have good reason to believe to be sane, tests should fail
<rogpeppe> fwereade: i'm not quite sure what kind of check you're thinking of here.
<rogpeppe> fwereade: and if it such a check would actually have caught any of the actual failures we've seen in the past
<fwereade> rogpeppe, it appears that the only testing we actually have is as follows: http://paste.ubuntu.com/5572927/
<fwereade> rogpeppe, do you consider this to be adequate?
<fwereade> rogpeppe, if yu said anything, I didn't see it
<rogpeppe> fwereade: i didn't - sorry, i didn't see your reply earlier.
<rogpeppe> fwereade: those tests should certainly be better
<fwereade> rogpeppe, I haven't seen anything since:
<fwereade>  <fwereade> rogpeppe, it appears that the only testing we actually have is as follows: http://paste.ubuntu.com/5572927/
<fwereade>  rogpeppe, do you consider this to be adequate?
<rogpeppe> fwereade: i haven't said anything since then
<fwereade> rogpeppe, ok, cool, just wondered if stuff got stuck
<fwereade> rogpeppe, o you see my point, though? that we could do *much* better here
<fwereade> rogpeppe, and that the local tests ought if anything to be an over-sensitive canary for the live tests
<rogpeppe> fwereade: i'm sure that's true. however, would better tests there have caught any of the problems we've actually seen?
<fwereade> rogpeppe, they should fail so people know to run the live tests for verification
<fwereade> rogpeppe, are yu telling me that you have never written code which passes the local test suite but doesn't work in reality?
<rogpeppe> fwereade: i'm saying that the reason it failed would not have been caught by a simple script test.
<rogpeppe> fwereade: the important script tests are in cloudinit, which *does* check the scripts in detail.
<rogpeppe> fwereade: the idea of the tests in the individual providers is that they check that the right params were passed to cloudinit. they should definitely do better in that respect
<fwereade> rogpeppe, so you've written code that broke juju without changing the scripts... but have never written code that changed the scripts that didn't break juju?
<fwereade> rogpeppe, even if that is the case I don't think we can assume that everyone has so complete an internal ubuntu simulator
<rogpeppe> fwereade: when i wrote code that changed the scripts, the only way to tell if it will break juju is by running them live.
<fwereade> rogpeppe, how do you know when you write code that changed the scripts?
<rogpeppe> fwereade: when changing the actual scripts generation in cloudinit
<fwereade> rogpeppe, that's not the only time
<rogpeppe> fwereade: the other way is by changing the parameters in MachineConfig
<fwereade> rogpeppe, or changing config.Config
<fwereade> rogpeppe, or changing upstart, or cloudinit, or agent, or...
<rogpeppe> fwereade: all of those are tested by the environs/cloudinit tests, no?
<fwereade> rogpeppe, some of them may be
<rogpeppe> fwereade: which should test for the range of possible MachineConfig configurations
<fwereade> rogpeppe, is it not the case that individual providers construct their own MachineConfigs from scratch?
<fwereade> rogpeppe, and that any one of the could, say, forget to strip secrets?
<rogpeppe> fwereade: yup. i think perhaps the check in the provider should be check(userData, Equals, expectedMachineConfig.Render())
<fwereade> rogpeppe, that sounds reasonable, I think, it closes the loop quite neatly
<rogpeppe> fwereade: that *still* won't find out real world problems though. we'd still need to run live tests before submitting, really.
<TheMue> fwereade: Got my fix done, but I've got 3 fails testing all. See http://paste.ubuntu.com/5572965/.
<fwereade> rogpeppe, although I think it would probably be even better if you did a MachineConfig-style output check on the stuff passed up to the instance though
<fwereade> rogpeppe, that way the test that fails will be at least close to the tests you need to run for verification
<rogpeppe> fwereade: you mean have the scripts literally in each provider?
<fwereade> TheMue, would you please: (1) verify they're intermittent (2) add bugs, mark them high (3) assign to likely people?
<fwereade> TheMue, I can take the filter test
<TheMue> fwereade: Will do so, yep.
<fwereade> TheMue, I suspect ian is a good candidate for TestPersistence in openstack
<TheMue> fwereade: OK
<fwereade> rogpeppe, is OpPutFile is your stuff?
<rogpeppe> fwereade: it was originally, though it's changed a bit since i last touched it i think.
 * TheMue has to do a short break, bringing daughter to work. BIAB
<fwereade> rogpeppe, yeah, I think so
<rogpeppe> fwereade: it's enough of a pain changing the literal scripts inside cloudinit that i'm not sure doing it in many other places is a great idea.
<fwereade> rogpeppe, surely it is dwarfed by the effort of running each set of live tests?
<rogpeppe> fwereade: i'm not sure how it helps particularly. rather than check(userData, Equals, expectedMachineConfig.Render()), we've got check(userData Equals, someLiteralStringWhichWeNeedToChangeEveryTimeCloudinitChanges)
<rogpeppe> fwereade: if there's a bug in the generated scripts, it's in environs/cloudinit, not the providers themselves.
<fwereade> rogpeppe, nonsense
<rogpeppe> fwereade: assuming that the correct args are passed into MachineConfig
<fwereade> rogpeppe, the environs create the input data
<rogpeppe> fwereade: (which is checked by the suggested userdata test)
<rogpeppe> fwereade: surely it's cloudinit's job to turn the MachineConfig spec into an actual script? the important thing in each provider is not the exact form of the script but the spec that's passed to cloudinit AFAICS.
<rogpeppe> fwereade: if we find that cloudinit is generating the wrong script given some set of input params, we should add that set of input params to the cloudinit script tests.
<fwereade> rogpeppe, we should, yes; but we should also have some reason to believe that those scripts will run live
<fwereade> rogpeppe, the number of things that change the cloudinit output is potentially high
<fwereade> rogpeppe, if someone causes a change there, they should be running those actual changes live
<fwereade> rogpeppe, ...shouldn't they?
<rogpeppe> fwereade: any time the cloudinit tests need adjusting, we should run all live tests. in fact, anytime *anything* changes, we should run all live tests. the scripts are a very minor part of it.
<fwereade> rogpeppe, I agree that live tests should run regularly, but I don't think it's sane to impose that requirement in all cases... how long do the live tests take?
<rogpeppe> fwereade: about 17 minutes currently
<rogpeppe> fwereade: i do kinda see the point though - having the literal string as a "if it's different from this, you need to run the live tests".
<fwereade> rogpeppe, ok, could have sworn it was longer :)
<rogpeppe> fwereade: we could even use a hash of the output
<rogpeppe> fwereade: it feels like it takes forever :-)
<fwereade> rogpeppe, I think we need to be a bit smarter -- eg server certs/keys will change each time -- but in that case I'd check validity wrt the CA cert and leave it at that
<rogpeppe> fwereade: it would mean that noone could submit any branch that changed the cloudinit output without it first being checked live against all providers
<rogpeppe> fwereade: it's not that easy
<fwereade> rogpeppe, hmm, go on?
<fwereade> rogpeppe, my position is predicated on the idea that the few bits of the scripts that do change do so in predictable and checkable ways
<rogpeppe> fwereade: if you want to check cloudinit output *without* the certs, you have to break up the cloudinit in exactly the same way that environs/cloudinit does. that's a frikking pain
<fwereade> rogpeppe, nobody said good testing was easy
<rogpeppe> fwereade: it's not just a pain, it's an *ongoing* pain.
<rogpeppe> fwereade: because you need to search out the right bits to change every time the cloudinit output changes.
<fwereade> rogpeppe, I think that's better than an ongoing situation in which "go test ./..." doesn't take a position on whether or not the providers actually work
<rogpeppe> fwereade: this wouldn't either.
<fwereade> rogpeppe, ISTM that it would fail any time there's a risk of the live tests failing
<rogpeppe> fwereade: there's always a risk of the live tests failing
<fwereade> rogpeppe, ...and it being a direct result of changes just made
<rogpeppe> fwereade: can you give an example of a live test failure that this would have caught?
<yolanda> hi, i'm having a problem creating juju instances in openstack, i have to run /var/lib/cloud/instance/scripts/runcmd on each machine to make it work
<rogpeppe> fwereade: if we made the testing certs unchangable, things would be easier perhaps.
<fwereade> rogpeppe, let me turn that around: if secrets are in the environ config, a test should fail. if the state server certs does not match the key, or cannot be verified by the ca cert, a test should fail. if the machine agent is not invoked with the correct machine id, a test should fail
<fwereade> rogpeppe, the fact that we happen not to have broken any of these yet, as far as I am aware, does not impact the fact that they should actually be tested
<rogpeppe> fwereade: all those things sound like tests on the MachineConfig input itself rather than than on the generated script.
<rogpeppe> fwereade: perhaps there's a case for intercepting the render step to see what actually gets passed to cloudinit rather than trying the reverse-engineer the output
<fwereade> rogpeppe, if use of cloudinit is optional in the providers -- which it is -- I think we must resign ourselves to checking what the providers actually produce
<rogpeppe> fwereade: surely each provider can decide how best to check its user data? this is very much a provider-specific test.
<mgz> optional in what sense?
<fwereade> mgz, in the sense that we don't necessarily have cloudinit available
<mgz> that's... not the case?
<fwereade> mgz, maybe it's working in lxc now? it certainly wasn't a while ago
<mgz> nothing functions at all unless cloudinit is present and runs
<mgz> ah, lxc is special, and doesn't exist for go yet
<rogpeppe> mgz: it will soon :-)
<fwereade> mgz, anyway, rogpeppe just blocked a change of mine on the basis that cloudinit wasn't special
<mgz> just using cloudinit for lxc too is probably simpliest
<fwereade> mgz, he's right about this, I think
<rogpeppe> mgz: at some point in the future we'll probably want juju to work under other systems without cloudinit (windows, for example)
<fwereade> mgz, it would be a bit weird to explicitly pass cloudinit-specific stuff into an environ when launching an instance
<mgz> I'm not sure about that.
<mgz> I have two thoughts: we have too much junk in the cloudconfig that shouldn't really be there right now
<fwereade> mgz, +1 on that, I think
<mgz> but the generic stuff we'd just end up duplicating in something that looked very much like cloudinit if we didn't use it in a provider
<rogpeppe> mgz: +1 too (i'd be interested to know which bits you're thinking of particularly though)
<fwereade> mgz, this is why I'm so pissed off by MachineConfig in the first place
<fwereade> mgz, it takes all the totally generic scripts-we-must-run stuff and smooshes it into a cloudinit-specific form
<rogpeppe> fwereade: those scripts are generic enough to run under Windows? :-)
<mgz> well, what do we mean by windows?
<fwereade> rogpeppe, at the moment we can't run the version of ubuntu we wanr
<mgz> we're a long, long way away from being able to use windows as a machine type in juju
<mgz> but that's not what we're talkinga about with azure
<rogpeppe> mgz: i though people were talking about "juju deploy activedirectory" as a possibility at some point
<mgz> for azure, we basically don't control boot, but can get our ubuntu machine, then access it and do stuff, which can still be cloudinit
<rogpeppe> s/though/thought/
<mgz> I think "some point" should be clarified to not worrying about with detail design like this right now, it would entail changing... a great deal more than just this
<mgz> fwereade: what's your branch, so I can catch up on the earlier discussion in the mp?
<fwereade> mgz, it's just a sketch, up at https://codereview.appspot.com/7396055/
<fwereade> mgz, sadly the discussion happened live
<mgz> live here, or live hangout? :)
<fwereade> mgz, hangout, I'm afraid
<mgz> ah well, add to the list for next week :)
<fwereade> mgz, as someone who came to the environs package cold, though, I would be very interested on your thoughts on that change
<rogpeppe> fwereade: i don't think that was the CL i had an issue with
<mgz> hm, "error: old chunk mismatch"
<fwereade> rogpeppe, crap, you're right
<fwereade> mgz, sorry, I have too many recent branches :/
 * fwereade goes digging
<rogpeppe> mgz: yeah, that happens. you can see the diffs though.
<rogpeppe> mgz: it'll be fixed if fwereade re-proposes
<mgz> launchpad will save me
<fwereade> mgz, https://codereview.appspot.com/7394048/ -- and it does have some discussion
<rogpeppe> mgz: https://codereview.appspot.com/7396055/patch/1/6
<fwereade> mgz, it is just a sketch, only proposed -wip
<mgz> ta
<rogpeppe> mgz: the thrust of my argument AFAIR was that factoring out this stuff was a good idea, but i think it would be better to take place under the umbrella of Bootstrap, rather than adding lots of cloudinit-related stuff to the environs.Environ interface.
 * rogpeppe goes back to trying to find that compiler bug
<davecheney> rogpeppe: is this in 1.0.3 or tip ?
<rogpeppe> davecheney: tip
<davecheney> rogpeppe: already reported
<rogpeppe> davecheney: have you narrowed it down?
<davecheney> https://code.google.com/p/go/issues/detail?id=4932
<davecheney> https://code.google.com/p/go/source/detail?r=e73800eb2b00
<davecheney> stay below this revision for the moment
<davecheney> or use hg revert
<davecheney> i'm setting up a jenkins build against tip to ensure we catch this faster
<davecheney> sorry, hg undo
<rogpeppe> davecheney: ah, cool. i was trying to reproduce by trial and error.
<rogpeppe> davecheney: i'd found this:
<rogpeppe> func (@"".sÂ·2 *@"".Settings "esc:0x0") @"".assertUnchangedOp () (? @"labix.org/v2/mgo/txn".Op) { return &@"labix.org/v2/mgo/txn".Op{ C:@"".sÂ·2.@"".st.@"".settings.Name, Id:@"".sÂ·2.@"".key, Assert:(@"".D{ 0x0:{ Name:"txn-revno", Value:@"".sÂ·2.@"".txnRevno } }) } }
<rogpeppe> davecheney: but couldn't reliably reproduce it in a small program
<davecheney> rogpeppe: ironically, the fix was for an issue which was almost identical https://code.google.com/p/go/issues/detail?id=4879
<davecheney> rogpeppe: nah, we use almost every conceivable style and permutation allowed by the language
<rogpeppe> davecheney: i narrowed it down quite a bit
<davecheney> try https://codereview.appspot.com/7437043
<davecheney> ok, jenkins biuld is setup
<davecheney> but is currently passing because r943 was rolled back
<rogpeppe> davecheney: trying that CL
<rogpeppe> davecheney: it sounds like they'd still benefit from a small test case
<davecheney> yeah, i agree, have a look at the 4879
<davecheney> the test case for that might be some of the way there
<rogpeppe> davecheney: that CL fixed the problem
<davecheney> rogpeppe: a test case would be useful
<davecheney> Dmorsing was saying that the way composite literals work, stretches the meaning of work
<rogpeppe> davecheney: how so?
<davecheney> 20:21 < DMorsing> davecheney, the biggest problem is that the compiler does a lot of work on the ast
<davecheney> 20:21 -!- fzzbt [~jahman@melkinpaasi.cs.helsinki.fi] has quit [Client Quit]
<davecheney> 20:22 -!- AnybodyElse [uid10067@gateway/web/irccloud.com/x-yvlsbbaerwtfivkb] has joined #go-nuts
<davecheney> 20:22 -!- fzzy [~jahman@melkinpaasi.cs.helsinki.fi] has joined #go-nuts
<davecheney> 20:22 -!- gsamat [~gsamat@broadband-188-32-17-124.nationalcablenetworks.ru] has quit [Quit: Computer has gone to sleep.]
<davecheney> 20:22 < DMorsing> and that either messes up later passes, or it messes up inlining because there isn't a proper representation of the post-processing AST
<fwereade> davecheney, tyvm
<davecheney> no worries
<davecheney> i've got a build setup now that watches juju tip and go tip for breakages
<davecheney> note: i am not running the tests (yet), just checking it compiles
<jam> mgz: poke
<mgz> jam, a, hey
<jam> mgz: care to join us for mmubemboeumob ?
<mgz> too many things going on, have fled to the conservatory
<wallyworld_> ian@wallyworld:~/.hpopenstack$ juju deploy mysql
<wallyworld_> error: cannot get latest charm revision: charm info errors for "cs:quantal/mysql": entry not found
<rogpeppe> fwereade: have you looked at tim's latest CL? i'm not sure what i think - i'm interested in your reaction. https://codereview.appspot.com/7375053
<fwereade> rogpeppe, looking
<dimitern> fwereade: done with standup, shall we g+?
<fwereade> dimitern, ok, would you start one please?
<dimitern> fwereade: https://plus.google.com/hangouts/_/5fb9c8fa96a6d9bc74de7a5f5cf171a04aeb0a40?authuser=0&hl=en
<jam> mgz, wallyworld_: https://code.launchpad.net/~jameinel/juju-core/only-943/+merge/151005
<wallyworld_> jam: my rev's changes look like they're all there. thanks for doing that
<jam> wallyworld_: np, if you can merge it and run the test suite quickly, it would help
<wallyworld_> jam: hmmm. a failure, haven't looked yet.... PANIC: local_test.go:132: localServerSuite.SetUpTest
<jam> wallyworld_: is it related to not enough bytes ?
<wallyworld_> not sure, looking now
<jam> wallyworld_: if you get a chance to paste the full traceback, please do so.
<wallyworld_> jam: https://pastebin.canonical.com/85834/
<jam> wallyworld_: that is the failure I'm working on in goose
<jam> interesting we've only seen it a couple times recently
<wallyworld_> ah ok
<jam> we must be using a lot more random data.
<wallyworld_> i'll rerun
<wallyworld_> jam: all good this time
<fwereade> jam, tyvm for reapplying those changes, if it's all passing it LGTM
<jam> fwereade: thanks
<jam> I've confirmed they pass here and for wallyworld_
<fwereade> jam, <3
<fwereade> jam, btw, I have a vague recollection mramm was going to talk to you about tarmac for juju-core at one stage, but I never followed up on it
<jam> fwereade: I actually have it set up as lp:~goose-bot/juju-core/trunk, but I wasn't sure how we wanted to actually coordinate the deployment.
<jam> I wasn't going to push for it until I updated 'lbox submit --tarmac'
<jam> (And it would currently be out of date)
<dimitern> wallyworld_: I think such intermittent failures deserve a bug report
<fwereade> dimitern, +1
<jam> dimitern: I have a patch submitted that you've reviewed for it, which is waiting for roger to approve
<jam> so yes, we could have a bug, but we do have a fix
<dimitern> jam: ah, that's your fix? ok
<dimitern> jam: I though it's a new random thing
<jam> wallyworld_: https://codereview.appspot.com/7375059/ is the one where fwereade is removing instanceid from being stored.
<jam> dimitern: the panic is because random isn't giving enough data, and we end up with a nil somewhere.
<jam> the fix should prevent that.
<fwereade> jam, what are your current priorities? is there anything we can downgrade in favour of getting reliable builds set up?
<wallyworld_> jam: that's great. i'll look tomorrow
<jam> fwereade: well next week is sprinting :).
<jam> And it depends if you want to require lbox submit --tarmac, if you can live with the manual steps we do for goose, I can get it set up quite quickly.
<jam> The only remaining stuff is policy stuff
<jam> do we want trunk to be only accessible by the bot
<jam> or should the bot just be in the group that can commit to it.
<fwereade> jam, I'm pretty comfortable declaring anything with a pulse to be untrustworthy
<fwereade> jam, it'd be a shame not to have submit --tarmac, but I guess the answer depends more on how many manual steps there are and how onerous they are
<jam> fwereade: you need to copy the description in Launchpad to the commit message, and then mark the proposal approved.
<jam> (tarmac uses Commit Message rather than description)
<fwereade> jam, that feels like it could be pretty easily scriptable, right? so even if there's trouble getting it into lbox, we should still be able to reap the benefits
<fwereade> jam, the other big thing IMO is that with tarmac, we could actually get away with running likley subsets of the tests
<fwereade> jam, and *that* then means we could put the deps in the source tree and get repeatable builds
<fwereade> jam, (nobody's thought of an alternative route to get that without dropping the go tools, right?)
 * rogpeppe goes for some lunch
 * fwereade pops out for 5 mins in the sun, then over to dimitern's place for state talks; see you all soon
<TheMue> cu
<benji___> There appears to be a sort-order test bug on trunk (http://paste.ubuntu.com/5573328/); is that something you guys want a bug filed for?
 * benji snipps off his tail.
<dimitern> benji: can you file a quick bug report about it please?
<benji> dimitern: will do
<dimitern> benji: today everything breaks it seems
<benji> :)
<benji> dimitern: https://bugs.launchpad.net/juju-core/+bug/1135757
<_mup_> Bug #1135757: List order test bug in launchpad.net/juju-core/environs/openstack <juju-core:New> < https://launchpad.net/bugs/1135757 >
<dimitern> benji: cheers!
<dimitern> benji: yeah, it seems that's related to ian's list prefix change
<dimitern> benji: strange, I'm not getting it on tip - are you sure you've updated goose before?
<dimitern> fwereade is here now
<benji> dimitern: nope, I have not, let me try that real quick
<jam> dimitern: did you manage to countersign your objectives? HR is asking me to do the final signoff.
<jam> dimitern: https://allhands.canonical.com/hra-space/portal/root/employee
<dimitern> jam: oh, you wrote here - yes I did
<jam> I know you did the submission, there is a countersign step that has to happen after mine.
<jam> I'm guessing you did it, but I want to make sure before I tell them.
<jam> dimitern: ^
<dimitern> jam: I double checked - there's no more to do on that page, tell me if I missed something. I just selected I agree + submit
<dimitern> benji: did you manage to get the test pass?\
<jam> if there aren't any tasks, then I don't see anything to do either.
<benji> dimitern: let me check the test run...
<dimitern> jam: yeah, i had to go to the archives page to see the countersign task
<benji> it worked!  I guess that's something I need to internaize.
 * benji writes "go get -u when you see test failures" 100 times on the blackboard
<benji> It would be really nice if there were dependency management in place so a human didn't have to do that sort of thing.
<dimitern> benji: cheers! please update the bug
<benji> dimitern: done
 * rogpeppe is back
<TheMue> rogpeppe: Do you know if we meet in 10 minutes? Or only this evening? I have to step out now to fetch my daughter. Today I'm the driver. ;)
<rogpeppe> TheMue: i'm not sure. i *presume* only this evening. mramm?
<niemeyer> Yo all!
<niemeyer> mthaddon: ping
<rogpeppe> niemeyer: hiya!
<TheMue> niemeyer: Hi.
<mthaddon> niemeyer: pings with content save time :)
<niemeyer> mthaddon: https://portal.admin.canonical.com/59712
<mthaddon> niemeyer: cool, thx, we'll get it done soon - is there a particular deadline for it, or just "sooner the better"?
<niemeyer> mthaddon: I generally like to say "Hi, how's life been since we last deployed it?", but alright :)
<mthaddon> heh
 * TheMue is AFK, BIAB
<niemeyer> mthaddon: There's no deadline, but sooner the better indeed
<niemeyer> mthaddon: There's a new stats feature
<niemeyer> mthaddon: Can't see that data while it doesn't land
<mthaddon> niemeyer: ok, thx
<niemeyer> rogpeppe, TheMue: Yos
<mramm> rogpeppe: TheMue: yea, just the evening meeting is fine
<mthaddon> niemeyer: the RT mentions revno 945 - is 949 okay (our scripts pull tip by default)?
<niemeyer> mthaddon: Yeah, it's okay
<mthaddon> thx
<mthaddon> niemeyer: done
<niemeyer> mthaddon: Sweet! Let me test it
<niemeyer> mthaddon: WORKS!
<mthaddon> good good
<niemeyer> mthaddon: Thanks much
<mthaddon> np
<fwereade> mramm, TheMue, rogpeppe: kanban?
<mramm> fwereade: we decided to only do the one this evening
<fwereade> mramm, ah!
<fwereade> mramm, good point
<fwereade> mramm, ok then :)
<fwereade> knocking off now, we've got the call later
<niemeyer> fss: ping
<bac> hi rogpeppe, would you time to do a second review for me?
<rogpeppe> bac: sure
<rogpeppe> bac: link?
<bac> cool, i hope you're not EOD
<bac> rogpeppe: https://codereview.appspot.com/7369058/
<rogpeppe> bac: normally yes, but today i'm working later
<rogpeppe> bac: reviewed
<bac> rogpeppe: thank.  looking at it now
<niemeyer> fss: pingous?
<fss> niemeyer: hi
<niemeyer> fss: Heya.. you've got reviews
<niemeyer> fss: Great stuff.. just trivial comments
<fss> niemeyer: I'm lbox proposing group changes right now :-)
<niemeyer> fss: Sweet
<fss> niemeyer: regarding the message returned by amazon, that's the message
<fss> niemeyer: should I use %q anyway?
<rogpeppe> right, i'm off for the night. see y'all tomorrow.
<niemeyer> fss: Does it include quotes around the name or not?
<jcastro> mramm: around?
<mramm> jcastro: I am now
<jcastro> got time for a quick G+?
<jcastro> 2 minutes, I promise!
<jcastro> mramm: https://plus.google.com/hangouts/_/097d689c217f97e00665bff91bac17fd9b78e439?authuser=0&hl=en
<mramm> jcastro, sorry I missed you...
<jcastro> no worries
<jcastro> next time
#juju-dev 2013-03-01
<thumper> jcastro: 2 minutes... funny man
<fss> niemeyer: ping
<niemeyer> fss: Heya
<fss> niemeyer: just finished mergin the patch
<fss> niemeyer: I noticed that you guys moved testServer, and renamed PrepareResponse to Response, so my patch now breaks the build, should I fix it or send another patch?
<fss> niemeyer: I prefer to get it right in this patch, but I'd like to know what you think about it
<niemeyer> fss: You're right
<niemeyer> fss: It should be fixed before going in indeed
<niemeyer> fss: I did the change.. we now have a single http test suite instead of one per package
<niemeyer> fss: Together with a few other fixups
<fss> ops
<fss> looks like I broke iamtest in the merging process
<fss> and there we go
<fss> niemeyer: ready for merging https://codereview.appspot.com/6855104/
<fss> time to sleep
<fss> niemeyer: tomorrow I will address your points in the user policy cl (https://codereview.appspot.com/6858081/)
<fss> niemeyer: good night :-)
<niemeyer> fss: Awesome, thanks a lot
<niemeyer> fss: I'll merge this in the morning tomorrow
<fss> niemeyer: thank you
<fwereade> wallyworld, ping
<wallyworld> fwereade: hi
<fwereade> wallyworld, heyhey
<wallyworld> w'zap?
<fwereade> wallyworld, would you expand briefly on the impact of the instance-id metadata thing you proposed?
<wallyworld> sure, what do i need to clarify?
<wallyworld> sorry about the codereview diff, no idea what happened there
<wallyworld> lp got it correct
<fwereade> wallyworld, am I right in thinking that the ec2-style instance-id data itself is useless, because we can't use it in the api... but it's better than ""?
<fwereade> wallyworld, proposing again will sometimes fix that apparently
<wallyworld> that's my understanding - the numeric id seems to be used in the API for specifying the server etc
<wallyworld> and old openstacks do not give us uuid
<wallyworld> eg hp cloud
<fwereade> wallyworld, ey up, there are *three* identifiers? crap
<wallyworld> yeah - ec2 style, nymeric id, uuid
<wallyworld> but numeric id deprecated afaik
<wallyworld> fwereade: maybe you can help me with somethong
<fwereade> wallyworld, so numeric is always available but deprecated, ec2 style is just useless, and uuid is what we want but not always available
<wallyworld> yes
<wallyworld> afaik
<fwereade> wallyworld, ouch -- ok, go on, how can I help?
<wallyworld> i had to use quantal image on hp cloud cause i was uploading self compiled tools
<wallyworld> and when i did a deploy mysql after a bootstrap went ok, i got
<wallyworld> error: cannot get latest charm revision: charm info errors for "cs:quantal/mysql": entry not found
<wallyworld> yet with precise it did not complain
<fwereade> wallyworld, quick g+? quicker than typing I think
<wallyworld> sure, sec, gotta get headphones
<fwereade> wallyworld, https://plus.google.com/hangouts/_/b9cd7e78738e463f4299770d1f17a3ffece7c960?authuser=0&hl=en
<rogpeppe> mornin' all
<fwereade> rogpeppe, heyhey
<wallyworld> morning
<wallyworld> fwereade: just checked the code - provider instance id returns ServerDetails.Id, which will be wrong on Canonistack
<wallyworld> since fetchInstanceId uses UUID on Canonistack
<fwereade> wallyworld, ah balls :(
<wallyworld> but it will work on HP Cloud :-)
<fwereade> haha
<wallyworld> i think i should land as is and then follow up with a branch to sort it out
<wallyworld> oh look at the time. beer o'clock :-D
<fwereade> wallyworld, I think I'd prefer holding off a little, see if we can figure something out at the sprint that doesn't regress
<fwereade> wallyworld, I think the python workaround for weird instance ids could still come into play here in a generally useful way
<wallyworld> ok
<wallyworld> we already cater for int ids vs string ids (not the uuid, id can be string or int)
<wallyworld> so a bit more logic won't hurt
<dimitern> anyone fancy a quick review? https://codereview.appspot.com/7438044/
<dimitern> fwereade: ping
<dimitern> fwereade: https://codereview.appspot.com/7425044/ - the wip branch about config changes (added a bunch of TODOs at key points)
<TheMue> dimitern: Will look in a few moments.
<dimitern> TheMue: cheers
<fwereade> dimitern, heyhey, I think I'm going to get an early lunch, I'm kinda tired today, so I might do that a bit later
<dimitern> fwereade: no worries
<dimitern> fwereade: just a quick look on the charmurl CL perhaps?
<fwereade> dimitern, doing that already, was planning to surprise you with it
<fwereade> dimitern, underpromise, overdeliver ;p
<dimitern> fwereade: :D cool
<fwereade> dimitern, https://codereview.appspot.com/7438044/ LGTM
<dimitern> fwereade: tyvm
 * fwereade decides he can't properly follow the filter changes without more food inside him, bbiab
<teknico> rogpeppe, good morning, remember that API design doc you wrote? where is it? can't find it anymore
<rogpeppe> teknico: one mo
<rogpeppe> teknico: https://codereview.appspot.com/7314085/
<teknico> rogpeppe, great, thanks. when is it going to land? :-)
<rogpeppe> teknico: when i get some reviews. i still need to do the watcher part, but i can probably land it before that.
<dimitern> TheMue: thanks for reviewing https://codereview.appspot.com/7425044/, but since it's WIP still, I'll really like a review on the other CL, which is ready for integration - https://codereview.appspot.com/7438044/
<TheMue> dimitern: OK
<dimitern> TheMue: :) cheers
<rogpeppe> fwereade: ping
<TheMue> dimitern: LGTM
<dimitern> TheMue: tyvm
<TheMue> dimitern: YQ
<TheMue> s/YQ/YW/
<fwereade> rogpeppe, pong
<rogpeppe> fwereade: is there a good reason the API needs to provide Expose and Unexpose rather than SetExposed? i can't think of one right now.
<rogpeppe> fwereade: (just seeing an opportunity to lose some boilerplate code)
<dimitern> I have an intermittent failure again while running the tests: http://paste.ubuntu.com/5576020/ - there's a bug about it, I updated and tagged it.
<fwereade> rogpeppe, IIRC niemeyer's reasoning is that if/when flags are added to control styles of exposure/unexposure it'll be nasty if we have to share the method
<rogpeppe> fwereade: ah, ok, that's a good enough reason.
<fwereade> dimitern, thanks for that
<rogpeppe> fwereade: thanks.
<fwereade> rogpeppe, np -- I'm not sure we're actually consistent about that but I think it does hold water
<dimitern> i'm getting: dimitern@kubrik:~/work/juju-core$ lbox submit
<dimitern> error: Failed to load data for branch .bzr/cobzr/009-uniter-use-charmurl: resource not found
<dimitern> anyone knows how to fix that? when proposing it was ok, and the branch is there in lp, trying to push the branch says no revisions or tags to push
<dimitern> i just merged trunk before trying to submit
 * dimitern lunch
<mgz> not sure, cobzr weirdness by the look of it
<mgz> you can always work around by not using lbox submit
<fwereade> dimitern, reviewed, ping me if anything's unclear
<bac> hi all, i've got a 'go get' vs 'cobzr pull' question:
<bac> i am using cobzr, am in the 'master' checkout of juju-core, and see it is on rev 949.  i do a 'go get -u -v launchpad.net/juju-core/...' and it does stuff.  however, juju-core is still shown to be rev 949.  i then do a 'bzr pull lp:juju-core' and it fetches rev 950.  what's going on?  why didn't 'go get' go get it?
<dimitern> fwereade: cheers, will do
<rogpeppe> bac: hmm, i dunno. i haven't seen that issue (but then again i always use bzr pull to get juju-core; i usually use go get -u for goose though)
<rogpeppe> bac: what does the go get command print?
<bac> rogpeppe: .../bac/work/src/launchpad.net/juju-core> go get -u -v launchpad.net/juju-core/...
<bac> launchpad.net/juju-core (download)
<bac> ... (other dependent packages)
<rogpeppe> bac: ha, that's not very useful is it?!
<bac> nope
<dimitern> mgz: help!
<mgz> hey dimitern :)
<dimitern> mgz: I'm still adding changes to the branch and both bzr and cobzr refuse to push them
<dimitern> mgz: bzr info says something weird: http://paste.ubuntu.com/5576144/
<rogpeppe> bac: you could try go get -u -x -v and see what it prints then
<dimitern> mgz: while previous branches say submit branch: (the same as the push one, not master)
<rogpeppe> dimitern: i've seen that before. try bzr push --remember
<rogpeppe> dimitern: (istr that didn't work before, but worth trying)
<dimitern> rogpeppe: tried that - both with --remember, then with that + --overwrite - still the same
<mgz> yeah, you can always respecify where you're trying to push
<mgz> ah, I see...
<mgz> the launchpad side branch is borked
<dimitern> the result still is No new revisions or tags to push.
<rogpeppe> ah, that was it!
<bac> rogpeppe: i see the problem.  it is just doing a 'bzr pull' but the parent branch is itself, so it doesn't do anything
<dimitern> hmm ?!
<dimitern> how to fix this? recreate the branch anew?
<rogpeppe> dimitern: i think so
<dimitern> rogpeppe: ok, i'll try that, bugger...
<rogpeppe> dimitern: but mgz will *know* rather than think :-)
<dimitern> mgz: :) ?
<mgz> `bzr info lp:~dimitern/juju-core/009-uniter-use-charmurl`
<mgz> you've accidentally made it a checkout of a branch on your machine
<dimitern> mgz: exactly the same result as without the lp:...
<rogpeppe> bac: hmm, it's odd that "bzr pull" worked when you tried it... ah, you probably used bzr pull from an explicit target
<dimitern> mgz: except Repository branch (format: unnamed)
<bac> rogpeppe: yes, manually i did 'bzr pull lp:juju-core'
<mgz> the point is, you never want a checkout on a remote box, that refers to a local branch, how does launchpad know to get revisions from your local machine? :)
<rogpeppe> bac: if you do bzr pull --remember lp:juju-core/trunk, it might fix the issue
<bac> rogpeppe: i'm recreating my workspace as i'm in-between tasks now
<dimitern> mgz: I always did this - with cobzr - bzr checkout -b branchname - and it does a lightweight checkout from the local master (or whatever other branch i'm on)
<mgz> dimitern: I suggest, with 009 checked out in your local branch, you push to lp:~dimitern/+junk/009 so I can get a copy
<rogpeppe> dimitern: i think the problem i had might've been caused by interrupting a push.
<mgz> then we can fix what exists in your local repo and on launchpad
<dimitern> rogpeppe: I *might* have done that
<dimitern> mgz: it's getting pushed now
<dimitern> rogpeppe: in fact I remember merging trunk and running lbox  submit, then remembered to run the tests and ^C it
<dimitern> to run them
<dimitern> so that's what might have happened
<rogpeppe> dimitern: seems plausible. i often get a bzr crash popup when i ^C.
<dimitern> rogpeppe: I also did every time, until I forbade it from showing these
<dimitern> mgz: it's there
<mgz> ta, branched
<mgz> okay, that looks okay
<dimitern> so what now?
<mgz> the easiest thing to do is probably just delete the existing branch via the web ui and repush to the same location
<dimitern> mgz: ok, I'll do it
<mgz> we could fixup the dangingness over sftp but it's in your namespace so I can't do it for you
<dimitern> mgz: pushed, just running tests and will try to submit again
<mgz> yup, that looks good
<dimitern> so the push was incomplete and that's why lp shows "this branch have not been pushed yet"
<mgz> nope
<mgz> cobzr had somehow screwed up the actual remote branch, it was a broken checkout, not a branch at all
<dimitern> mgz: aah
<dimitern> mgz: arcane stuff.. so in the future if this happens i'll just delete the branch and push it again
<mgz> presumably it has some messed up logic when it gets interrupted, bzr itself gets this stuff right
<mgz> unless you explictly tell it to mess around with remote branches
<dimitern> which --overwrite does?
<mgz> nope
<dimitern> btw I noticed a bug on the LP Code page
<mgz> you'd need to do something like `bzr switch -d lp:~/+junk/break ~/localbranch` or something
<dimitern> when the branch was shown as not pushed yet it said "use bzr --use-existing lp:~..." but there's no such bzr option
<mgz> huh, file a bug! https://bugs.launchpad.net/launchpad/+filebug
<mgz> I guess it means the --use-existing-dir flag on the branch command?
<mgz> hm, and bzr doesn't let you abuse switch to break remote branches, because we require a remote working tree. wonder what fun cobzr does to break that.
<dimitern> mgz: I copied it as it was suggested, filed bug 1137716
<dimitern> where is the mup?
<dimitern> https://bugs.launchpad.net/launchpad/+bug/1137716
<mgz> hm, I think mup just logs, and ubot talks bugs?
<dimitern> well, before _mup_ it responded when you say bug something
<dimitern> _mup_: hey :P
<mgz> maybe mup is just on a tea break...
<dimitern> maybe if we kick it it'll come to senses and rejoin
<fwereade> rogpeppe, would you remind me of your reasoning for wanting to arbitrarily vary mongo/api ports across state servers within the same environment?
<dimitern> mgz: who controls these bots anyway? webops?
<rogpeppe> fwereade: a) i think it's trivial to allow b) it's just possible we might want to allow hosting of several different API servers or mongo servers on the same machine.
<rogpeppe> fwereade: i think it's reasonable to leave the door open
<fwereade> rogpeppe, where are you planning to store this info? I am curently not seeing the triviality at all
<fwereade> rogpeppe, and I really don't see the use case for multiple mongo/api servers *for the same env* on the same machine
<fwereade> rogpeppe, not that we could do that now anyway, because it seems to be hardcoded in the environs anyway
<rogpeppe> fwereade: the info can be stored alongside the server addresses; i don't think there's much difficulty there.
<fwereade> rogpeppe, and where does it come from?
<rogpeppe> fwereade: machine agents can publish their own addresses in the state. at least, that was my plan for the HA stuff.
<fwereade> rogpeppe, sure, that bit makes sense -- but it also needs to be stored in bootstrap state, and stored on (?) the machines in state as we create them, and threaded though the environ interface, etc etc
<rogpeppe> fwereade: as do the server addresses, no? i'm not sure that adding a port makes much difference.
<fwereade> rogpeppe, well, at the moment we have a one-element list of instances stored in bootstrap state and a hardcoded port in each environ
<rogpeppe> fwereade: except the actual state.Info takes a list of (address, port) pairs. and that seems to work ok, and provides flexibility for the future.
<fwereade> rogpeppe, at the moment there is sham flexibility in state.Info, and absolutely no accommodation for all the hard work of actually making it flexible
<rogpeppe> fwereade: the flexibility in state.Info is genuine. without that we *can't* make anything else flexible. i think of state.Info as the low level thing - individual environments can be (are currently) less flexible.
<fwereade> rogpeppe, I'mnot proposing a change to state.info
<rogpeppe> fwereade: ok. i thought you were proposing a data structure from which state.Info was always derived that was less flexible.
<rogpeppe> fwereade: perhaps i'm not getting your drift at all, in fact...
<fwereade> rogpeppe, I don;t even care about the Servers struct
<rogpeppe> fwereade: ok, so where are you coming from?
 * TheMue enjoys now lunch
<fwereade> rogpeppe, basically, I'm confused and frustrated because ISTM that you have hardcoded ports across the board and are now telling me it needs to be fixed and it's "trivial" to do so
<fwereade> rogpeppe, when, actually, it is not trivial to do so because unpicking environs is melting my brain badly enough already
<rogpeppe> fwereade: i don't think i've hardcoded ports across the board, have i?
<rogpeppe> fwereade: they're hardcoded in the two providers only
<rogpeppe> fwereade: because currently there is only one server
<fwereade> rogpeppe, and in each of those providers you use the magic hardcoded ports in two very different places -- bootstrap and StateInfo -- without considering how we're meant to get from one to the other
<rogpeppe> fwereade: yes, we definitely do need a better scheme for storing bootstrap info. that's been on the cards for a long time. but it's not something that needs to be fixed right now, is it?
<rogpeppe> fwereade: in my head, bootstrap is responsible for a) making sure a server is started and b) letting any clients know how to get to that server. the fact that the port is hardcoded doesn't mean that logic doesn't still apply, or that future changes won't mean that a given provider might not give itself more flexibility.
<fwereade> rogpeppe, ISTM that starting a new state server on a non-standard port requires work that hits state, environs, and the provisioner
<fwereade> rogpeppe, just as does being able to pick the frickin' series we start a machine with
<fwereade> rogpeppe, and I am not inclined to react positively to "we'll figure it out later" sorts of proposals that appear to share the thinking that got us into this situation in the first place
<rogpeppe> fwereade: starting a new state server requires work on all those things. the "non-standard" port part isn't much of the problem at all, is it?
<rogpeppe> fwereade: i'm not sure i see where your current problem is.... hold on, shall we G+ this?
<fwereade> rogpeppe, hm, I need to eat something else -- can we say 20 mins from now?
<rogpeppe> fwereade: ok, cool. i'll have a bite too
<rogpeppe> fwereade: ready when you are
<fwereade> rogpeppe, https://plus.google.com/hangouts/_/44a57aa5ead51164a91eef9e4fac5ac528a8dfe1?authuser=0&hl=en
<fwereade> rogpeppe, oh yeah, one other thing: the "state" server cert/key are used for state *and* the api, and this is fine, but that means they're not so much *State*ServerCert as ServerCert -- right?
<rogpeppe> fwereade: yeah
<rogpeppe> fwereade: i think i am tending towards the idea that the environment should be given the CA and generate its own certificates, BTW
<fwereade> rogpeppe, offhand, that makes sense to me
<rogpeppe> fwereade: that way we can potentially have certficates that actually reflect the DNS name of the server, which is how they're usually used.
<rogpeppe> fwereade: also, having a unique identity for each server enables certain interesting architectural possibilities, i think.
<fwereade> rogpeppe, +1 to that
<dimitern> I have a nasty 1000 lines panic in cmd/juju on tip
<dimitern> jujud actually
<dimitern> http://paste.ubuntu.com/5576401/
<fwereade> dimitern, what's line 226 of your filter.go?
<dimitern>                 case _, ok = <-configw.Changes():
<fwereade> dimitern, I think I suggested enough to fix all that with my `var configChanges <-chan state.Settings` lines
<dimitern> yep, I reproduced it again
<dimitern> fwereade: no, no - I haven't even started my changes yet
<dimitern> fwereade: that's fresh trunk at tip
<dimitern> I'm filing a bug
<fwereade> dimitern, are you totally sure you're running the right code?
<dimitern> fwereade: actually, it's not trunk, it's my 010 branch, but i merged trunk just now
<dimitern> fwereade: the error is not due to my changes - it's in cmd/jujud
<dimitern> fwereade: or is it?.. I'll try trunk
<fwereade> dimitern, the error is precisely due to your changes
<fwereade> dimitern, make the configChanges suggestion
<fwereade> s/make/try/
<dimitern> fwereade: oh :) sorry then for the noise, but i'm getting jumpy and running the tests all the time now :)
<mgz> :)
<fwereade> dimitern, understood, np, better to be jumpy than complacent ;)
<fss> niemeyer: morning :)
<niemeyer> fss: Yo!
<niemeyer> Morning all
<rogpeppe> niemeyer: hiya!
<niemeyer> rogpeppe: Yo
<rogpeppe> niemeyer: scheduler changes just landed... exciting!
<niemeyer> rogpeppe: How're things going?
<rogpeppe> niemeyer: pretty good
<niemeyer> rogpeppe: Wow, seriously?
<rogpeppe> niemeyer: yup
<niemeyer> rogpeppe: I was afraid that was going to slip past
<rogpeppe> niemeyer: various platforms broken, but should be fixed in time
<rogpeppe> negronjl: me too
<dimitern> niemeyer: hey!
<fss> niemeyer: i've updated the user policy CL
<rogpeppe> niemeyer: just about to see if the juju tests pass ok with tip
<dimitern> fwereade: ping
<rogpeppe> niemeyer: all tests pass, which is good
<niemeyer> fss: Superb, I'll do a round and merge them
<niemeyer> rogpeppe: I should do a test with mgo
<rogpeppe> niemeyer: definitely
<niemeyer> rogpeppe: There was visible contention impact in massive workloads
<niemeyer> rogpeppe: and the underlying logic was actually coded to benefit of parallelism
<rogpeppe> niemeyer: have you got any benchmarks?
<fss> niemeyer: thanks
<niemeyer> rogpeppe: I had one submitted by a user long ago.. I'll see if I can find it
<fss> niemeyer: lunch time, brb :)
<rogpeppe> niemeyer: the scheduler looks like a *huge* improvement - lots of web servers will benefit
<niemeyer> rogpeppe: Just doing GOMAXPROCS=4 already bumped performance in a relevant way.. I'm excited about what this can mean now
<niemeyer> fss: enjoy!
<dimitern> fwereade: not sure what you meant by f.SetCharm() should only return after the charm is stored in state - it's just selecting on channels, it's not doing the actual setting of the charm
<dimitern> fwereade: should I make another ->chan to notify f.SetCharm the deed is done and return?
 * TheMue steps out for some time, final tasks to do during office time before leaving tomorrow morning
<fwereade> dimitern, if it's not setting the charm then we're definitely racy
<fwereade> dimitern, +1
<fwereade> dimitern, the alternative is to watch the unit until it gets the right charm url
<fwereade> dimitern, don't really have a position on which is better
<fwereade> dimitern, regardless, we should not store local uniter state referencing a charm until we have increffed it remotely
<dimitern> fwereade: I have a preliminary solution: (not tested yet) http://paste.ubuntu.com/5576623/
<dimitern> fwereade: and charmChanged is written to whatever SetCharmURL returns
<fwereade> dimitern, feels a bit iffy but I can't quite say why... I might be leaning towards a watch on the unit in deploy, actually
<dimitern> fwereade: well, the for loop is ugly obviously
<fwereade> dimitern, I'd definitely prefer two selects in series
<dimitern> fwereade: but not sure how to do the watch you suggested
<dimitern> fwereade: just a loop doing u.Refresh and comparing the curl?
<fwereade> dimitern, pretty much -- just refresh the unit every time you get a change, and stop when it matches
<fwereade> dimitern, I'm not wild about that either
<fwereade> dimitern, hmm
<dimitern> fwereade: how about adding a watcher on state.unit?
<dimitern> even worse maybe..
<fwereade> dimitern, ah, that was what I meant by watching the unit
<fwereade> dimitern, it'd be a selct loop, refreshing the unit when we got a change notification for it
<fwereade> dimitern, it might be smarter to keep it in the filter
<dimitern> fwereade: i hear you, but probably it's best to see this hands on and discuss it in person :)
<dimitern> fwereade: even though I have a some idea how watchers work, I'm yet to dig in their internals
<fwereade> dimitern, stick with the filter approach for now
<fwereade> dimitern, just be sure that you can't deadlock
<dimitern> fwereade: so for + 2 selects in SetCharm? otherwise fine for now?
<dimitern> fwereade: the filter and uniter run in separate go routines, right? so long we didn't call SetCharm from the filter it should be fine I think
<fwereade> dimitern, yeah, I think it'll be ok
<fwereade> dimitern, sorry, not concentrating very well today
<dimitern> fwereade: I understand completely :) I'm a bit worried I need to stop soon to get my luggage ready
<dimitern> fwereade: so one select for tomb+<-setCharm; one for <-charmChanged ?
<fwereade> dimitern, I think you want the tomb in the second one too
<dimitern> :) just saw that and was about to say it!
<fwereade> dimitern, cool :)
<dimitern> off to pack and get ready
<dimitern> see some of you in person on monday :)
<dimitern> have a nice flights guys
<mgz> see you soon dimitern!
<niemeyer> fss: ping
<niemeyer> fss: First branch is in, waiting for conflict resolution on second
<rogpeppe> i'm just off now. see y'all in Atlanta!
<rogpeppe> niemeyer: except you... first sprint with no gustavo. :-(
<bac> has anyone seen this error before:
<bac> juju status
<bac> error: cannot log in to admin database: auth fails
<bac> this is against a bootstrapped instance on ec2
<niemeyer> rogpeppe: Yeah, I didn't even know there was going to be a sprint
#juju-dev 2013-03-02
<fss> niemeyer: ping
<niemeyer> fss: Hey
<niemeyer> fss: I've seen the branch.. it's in
<fss> niemeyer: thanks
<fss> niemeyer: time to sleep
<fss> niemeyer: good night, have a nice weekend :-)
#juju-dev 2013-03-03
<rogpeppe> on my way!
#juju-dev 2014-02-24
<wallyworld> thumper: lachie is sick and i have to go get him from school. i should be back in time for standup but if not i won't be far away
<thumper> ack
<axw> thumper, wallyworld: would it be terrible if rsyslog configuration weren't set up during machine init, but by the machine agent? that would mean losing logging for failed agent startup, but would mean simpler code
<wallyworld> hmmm
<wallyworld> i'd perhaps need to see the rationale, pros, cons etc
<wallyworld> i think logging failed agent startup is important
<wallyworld> s/is/is potentially
<axw> well, to start with we'll probably need to support changing syslog protocols, from udp to tls/tcp
<axw> that could be done as an upgrade step, but would be cleaner if we handle it as a worker
<axw> so then if we have a worker, we *can* ditch the code that initialises the logging during machine init - threading attributes through API server and provisioner
<axw> but it does mean losing that logging
<axw> we could have a jujud invocation that connects to state and does one-shot configuration, but I doubt that's any more useful than just relying on a working machine agent
<wallyworld> could we do both? still log agent startup?
<axw> yes we can do both still, this is just a question of usefulness vs. code complexity
<axw> to support TLS, I've had to add additional fields to several structs in the API to support env and container provisioners
<wallyworld> i'm very hesitant to want to throw away logging, especially for startup of services where key errors might be logged
<axw> that'll only grow if we continue on this path
<axw> well, the other thing is, the logs will still be there on the machine
<axw> just not in debug-log
<axw> but... not ideal
<wallyworld> yeah
<wallyworld> i'd email the list - there's sure to be a range of opinions :-)
<axw> okey dokey
<wallyworld> cause i can see arguments either way
<wallyworld> and potential changes to the api deserve wider input
<waigani> axw: thanks for the review. All makes sense. I'm just stuck on one bug. I've emailed you the details.
 * axw looks
<axw> waigani: the bad code is "return s.configValidator, configValidatorErr"
<axw> you should be returning a pointer.
<waigani> ahhhhh
<waigani> dur
<axw> if the receiver is *T, then you must assign a *T
<waigani> axw: yep. Thank you.
<waigani> axw: I now get: invalid indirect of s.configValidator (type mockConfigValidator)
<axw> eh?
<axw> sounds like you're doing * instead of &
<waigani> ah, got you now
<thumper> axw: interestingly, we shouldn't actually lose anything, as when you first start up the reader, it would read and transmit the entire file
<thumper> axw: however the ordering of the events in the all-machines.log will be out of whack
<thumper> axw: will respond to the email in more detail later
 * thumper is done for the day, but back for a meeting at 8:30pm
<axw> thumper-afk: I meant if the machine agent never comes up at all. Thanks, will await you  reply :)
<waigani> axw: sent you an email
<waigani> axw: just ran TestSetEnvironAgentVersionExcessiveContention by itself, same failure
<axw> waigani: ok. best to go back to trunk before your changes and see if it's any different
<waigani> axw: hmmmm, trunk passes. no panics, no fails.
<waigani> I've screwed something up...
<wrtp> mornin' all
<axw> morning rogpeppe
<rogpeppe> axw: hiya
<axw> rogpeppe: would you mind taking a look at this? I have a LGTM, but it's a sensitive area so I'd like two :)   https://codereview.appspot.com/66920043/
<axw> I find the config defaults code a bit confusing
<rogpeppe> axw: will do
<rogpeppe> axw: what was the specific motivation behind the change?
<axw> rogpeppe: to have a default of Omit for existing environments, and a non-Omit default for new environments
<rogpeppe> axw: that is, it seems reasonable, but i'm trying to think of an example where the default value isn't the same as the "always-optional" default value
<rogpeppe> axw: just trying to understand further: what attribute do we want that for?
<axw> rogpeppe: if you don't use Omit in alwaysOptional (or "" for strings), then New will fail if the attribute doesn't exist in the old config
<axw> rogpeppe: for a new attr, syslog-tls
<axw> which is a bool
<axw> rogpeppe: also, I don't think the bootstrap timeout options were doing anything. the defaults were all being overwritten with Omit
<dimitern> hey jam, sorry my alarm clock betrayed me :/
 * rogpeppe wishes this IRC client had decent notification functionality
<jam> dimitern: I was wondering about that. I hope you enjoyed your trip back to Malta
<rogpeppe> axw: i'm not sure why the bootstrap timeout options were Omit anyway
<jam> rogpeppe: I'm in the 1:1 whenever you're available
<dimitern> jam, oh, it was good yes
<rogpeppe> jam: just joining
<axw> rogpeppe: because they were never specified before, so lack of attr fails the config schema checker
<axw> (unless Omit)
<jam> dimitern: can you ping me to check my notification settings
<dimitern> axw, thanks for the review, I'll propose a follow-up with your suggestions as I already landed that one
<dimitern> jam, ping?
<jam> thanks
<axw> dimitern: okey dokey
<waigani> hi fwereade, when you have a moment can you take a look at https://codereview.appspot.com/64580044. I'll add the mongo txn stuff to SetEnvironConfig in a separate branch.
<fwereade> waigani, will do, I'm kinda pitifully trying to write some actual code but I know I have to circle round on reviews again today too
<waigani> fwereade: no rush, I'm off to bed now. Thanks
<rogpeppe> axw: i still don't quite see - why couldn't the value for bootstrap-timeout not be DefaultBootstrapSSHTimeout, similar to state-port, for example?
<axw> rogpeppe: my understanding is that if it's not schema.Omit, then you can't have the attribute missing from the config
 * axw looks at state-port
<axw> maybe I'm full of crap
<rogpeppe> axw: i don't think that's true - "alwaysOptional" implies the attr is always optional, regardless of what the value is
<rogpeppe> axw: i can't currently think of a situation where it makes sense to have an entry in both alwaysOptional and in the initial schema.Defaults map created by allDefaults
<axw> rogpeppe: do the default values in alwaysOptional get added to a config that specifies NoDefaults?
 * axw is looking at noDefaultsChecker
<rogpeppe> axw: yes
<mgz> hey all
<rogpeppe> mgz: yo!
<axw> rogpeppe: ok, then that's a problem. I want an old environment to continue on with either no syslog-tls or syslog-tls=false
<axw> rogpeppe: but all new config's should have syslog-tls=true
<axw> hey mgz
<rogpeppe> axw: ah, ok, that's a good specific case
<axw> rogpeppe: I think I had tested that originally, then confused myself with the bootstrap timeout params which shouldn't be like that anyway
<rogpeppe> axw: why do we want to do that, BTW?
<axw> rogpeppe: can't upgrade to TLS because our certs have Key Usage set incorrectly
<axw> rogpeppe: sorry, obtuse - there's a mail thread, one sec
<rogpeppe> axw: couldn't we just ignore the attribute if the cert doesn't support TLS?
<axw> rogpeppe: can't tell from the client side
<axw> rogpeppe: the client just has the CA cert
<rogpeppe> axw: ah, which only signs the root cert, not the actual server cert, right?
<axw> rogpeppe: the CA cert signs the server cert, but the server cert is the one with the invalid Key Usage
<rogpeppe> axw: erm
<rogpeppe> axw: isn't the CA cert the thing that specifies the allowed key usage?
<axw> rogpeppe: they all have key usages. my understanding is the CA can just choose not to sign a request with specific key usages
<axw> rogpeppe: https://codereview.appspot.com/66930043/ fixes the problem
<axw> for new environments only of course
<rogpeppe> interesting. i hadn't seen ExtKeyUsage before.
 * rogpeppe looks at the docs
<fwereade> rogpeppe, axw: hey, also, in the cert package, I note we have `SerialNumber: new(big.Int)` which looks like a violation of the spec
<fwereade> rogpeppe, axw: I'm pretty sure SerialNumber is meant to be unique
<rogpeppe> fwereade: quite probable, although i'm not sure it's a security hole
<fwereade> rogpeppe, I think it's quite likely to be a problem all the same, as soon as something that *does* care about the spec sees two different certs from the same CA with the same serial number
<fwereade> rogpeppe, it's not so much  security hole as an indication that we're being funky and should not be trusted
 * fwereade wonders if there's a good complement to "security hole" that implies false positive rather than false negative
<fwereade> er, I guess you could read it either way
<rogpeppe> fwereade: we should probably just make it a 128-bit random number
<fwereade> rogpeppe, +1
<jam> rogpeppe: standup ?
<hazmat> axw, fwiw.. the rsyslog priv separation thing has been fixed for 2 years.. debian and ubuntu have been carrying around old versions.. trusty gets things back to a current version, another workaround is to install the updated rsyslog pkg.
<hazmat> which also gives tls on relp (reliable store forward).. probably more than juju cares about.
<hazmat> rogpeppe, its pretty common re extended key usage.. clientauth, serverauth..
 * hazmat has been knee deep in x509 the last week
 * rogpeppe doesn't like x509
<hazmat> rogpeppe, ping.. i've been hearing reports about issues with the state watcher stopped issue recurring
<hazmat> rogpeppe, what's interesting is that its not just the admin api client, but all clients watches that go belly up
<hazmat> rogpeppe, this is on 1.17.3.. cjohnston 's machine-0.log when it happens.. http://paste.ubuntu.com/6986643/
<hazmat> cjohnston, this is on canonistack? which region?
<hazmat> cjohnston, and what instance type is the state server?
<hazmat> oh.. nm. ic lyc01
<cjohnston> cpu1-ram1-disk10-ephemeral20 | 1GB RAM | 1 VCPU | 10.0GB Disk
<rogpeppe> hazmat: interesting.
<hazmat> rogpeppe, anything else he could get off that env before he shuts it down that would be helpful for debugging?
<rogpeppe> hazmat: does his environment recover from the issue?
<hazmat> cjohnston, ^ can you run status or deployer again and it works?
<rogpeppe> hazmat, cjohnston: it looks like it might be a problem with mongo - the port it's getting a timeout error from is mongod's port
<rogpeppe> hmm, but that's somewhat odd
<cjohnston> hazmat: 'status' meaning 'juju status' ?
<rogpeppe> cjohnston: yes
<cjohnston> juju status works
<rogpeppe> cjohnston: ok, so it seems like this is only a transient error, which is something
<cjohnston> http://paste.ubuntu.com/6986741/
<rogpeppe> cjohnston: thanks. that all looks healthy.
<rogpeppe> cjohnston: did you find out about the issue from a GUI error?
<hazmat> rogpeppe, from a deployer error, he's been reproducing this consistently for a week
<cjohnston> http://paste.ubuntu.com/6986666/
<rogpeppe> cjohnston: you can reliably repro the issue?
<cjohnston> rogpeppe: yesterday I it took 3 tries to reproduce
<rogpeppe> cjohnston: you're running the released version of 1.17.3, right?
<cjohnston> 1.17.3-0ubuntu1
<cjohnston> rogpeppe: do you want anything else from this deployment before I tear it down?
<rogpeppe> cjohnston: i don't think so, thanks
<cjohnston> rogpeppe: someone else on my team just got the same error
<cjohnston> rogpeppe: would anything from psivaa's deployment help?
<rogpeppe> cjohnston: how have you been reproducing the error?
<cjohnston> rogpeppe: just deploying
<cjohnston> we have a deployment script that deploys our entire setup
<hazmat> cjohnston, i'd be curious if you beef up your state server instance size if its still reproducible
<axw> fwereade: yeah I noticed the serial, but frankly I don't know what the right thing to do there is. since we only generate one server cert, it doesn't matter at the moment (until we do HA...)
 * fwereade starts counting down in a meaningful sort of way
<axw> hazmat: thanks for the tip about rsyslog updates
<hazmat> axw, np. thanks for turning around the ssl support there.. i'll still need to chat about the incantations for a manual upgrade are
<cjohnston> psivaa: what size if your bootstrap node
<psivaa> cjohnston: i dint specify any constraints. so it's the default size. let me confirm
<axw> hazmat: no worries, I'll send you an email with what needs to happen.
<hazmat> axw, thanks
<psivaa> cjohnston:  hardware: arch=amd64 cpu-cores=1 mem=512M
<cjohnston> even smaller
<axw> wallyworld: how does passing data-dir to syslog config help? data-dir and log-dir are independent
<rogpeppe> hazmat: i wondered about that, but it seems odd that a localhost connection would be timing out
<rogpeppe> hazmat: even if the machine is heavily loaded
<rogpeppe> cjohnston: please file a bug (if you have not done so already) and attach, if possible, instructions for the most reliable way you can find for reproducing the issue
<cjohnston> rogpeppe: do you want a new bug I'm guessing and not re-open the already existing one?
<rogpeppe> cjohnston: yes - this seems like a different issue to me
<cjohnston> ack
<chris38> hi is there any technical doc explaining how juju bootstrap is performed, i'm a bit lost digging in the code ?
<chris38> I tried --debug flag, bug things stay unclear
<mattyw> fwereade, ping?
<psivaa> cjohnston: rogpeppe: the issue occurs even with 2G memory of the bootstrap node. (arch=amd64 cpu-cores=1 mem=2048M root-disk=10240M)
<rogpeppe> psivaa: if you could post a reliable way that we can reproduce the issue to the bug, that would help greatly, thanks (i haven't checked - maybe someone's done that already)
<psivaa> cjohnston: ^ would you add that also pls?
<rogpeppe> niemeyer: ping
<niemeyer> rogpeppe: Heya
<rogpeppe> niemeyer: hiya
<rogpeppe> niemeyer: just wondering if there's a chance you could have another look at https://codereview.appspot.com/5874049/ ?
<rogpeppe> niemeyer: it un-breaks the currently broken time stamp behaviour of gocheck
<rogpeppe> niemeyer: (currently gocheck always prints the same time stamp on every line because the time calculation overflows)
<rogpeppe> niemeyer: and the output format is as we agreed some time agi
<rogpeppe> ago
<niemeyer> rogpeppe: Thanks, will have a look
<cjohnston> rogpeppe: should the bug be against -core or -deployer ?
<rogpeppe> cjohnston: -core
<cjohnston> ty
<cjohnston> rogpeppe: hazmat bug #1284183
<_mup_> Bug #1284183: jujuclient.EnvError: <Env Error - Details:  {   u'Error': u'watcher was stopped', u'RequestId': 9, u'Response': {   }} <juju-core:New> <https://launchpad.net/bugs/1284183>
<rogpeppe> cjohnston: thanks!
<hazmat> rogpeppe, any ideas to cause..  re client level workarounds.. auto-reconnect and ignore?
<rogpeppe> hazmat: client level workaround is probably just to reconnect
<rogpeppe> hazmat: which is probably something that you should be prepared to do anyway, as it's always possible the ws connection may be terminated
<rogpeppe> hazmat: i haven't had time to investigate cause yet, i'm afraid
<rogpeppe> hazmat: i have a suspicion or two, but nothing worth mentioning
<hazmat> rogpeppe, sure.. at a high level i'm trying to move deployer to be delta based,  so just rerun.. wrapping every api interaction with auto-retry seems less than idael
<hazmat> i mean its not a normal occurance imo.. and lacking transactions... auto retry of arbitrary partial seems questionable.
<hazmat> robbiew,  cjohnston, it might be useful to pickup some mongodb logs from an instance when this occurs
<robbiew> hazmat: huh?
<rogpeppe> hazmat: it's not a normal occurrence, except that failure kinda is normal. you'll see this behaviour with HA if there's a server failure, for example
<robbiew> oh...nevermind ;)
<hazmat> robbiew, sorry
<rogpeppe> robbiew: not the first time :-)
<rogpeppe> hazmat: i don't know of a smooth way of coping with server failure here. we should really be making all our ops idempotent.
<rogpeppe> hazmat: many of them are in fact, i think.
<hazmat> rogpeppe, not really.. deploy twice.. error for transmission, error for duplicate service on second.. add-machine twice.. two new machines.
<hazmat> rogpeppe, that second case is why gui needed a set number of units api.. add-unit/remove-unit are delta ops not target goal  ops
<rogpeppe> hazmat: add-machine is a good example of one that's not. but error for duplicate service still gives you an idempotent op
<rogpeppe> hazmat: it would be nice if the error message distinguished "duplicate service with all the same attributes" and "duplicate service with some different attributes"
<rogpeppe> hazmat: or perhaps even if add-service just succeeded if the service already exists with all the same attrs, but that's definitely more arguable.
<hazmat>  rogpeppe, so basically .. do the go thing.. and attach specific error handling and retry logic to every api op... that's fair although burdensome imo (my end goal as i stated is to just be able to do the right thing if people rerun, because i want them to know when the backend turns up errors) ... anyways given the frequency i'd be a bit more inclined to say we should fix the server to be a bit more reliable.
<rogpeppe> hazmat: i'm definitely not saying that this isn't a bug - it does sound like it, and it shouldn't be happening
<hazmat> rogpeppe,  which still means getting to root cause there.... i'm hoping the mongo logs might turn up something.
<rogpeppe> hazmat: i'm just saying that in the general case, this kind of thing will be able to happen, and can't think of a decent way around it.
<rogpeppe> hazmat: definitely
<hazmat> cjohnston, mongo is logging to syslog it looks like.. if you can reproduce, could you grab a copy to chinstrap
<cjohnston> ack.. psivaa ^
<rogpeppe> hazmat: unfortunately i don't have much time to spend on it currently
<hazmat> rogpeppe, no worries.. neither do i, but i'm hoping/looking to get a better understanding of root cause, and hopefully at least be able to instruct workarounds.
<hazmat> actually doing the retry/reconnect for watchers is probably the safest bet atm
<rogpeppe> hazmat: yes
<rogpeppe> hazmat: FWIW my strongest suspicion is on the mgo package - that's the only place that's setting up tcp timeouts AFAIK.
<rogpeppe> pwd
<psivaa> cjohnston: hazmat: https://launchpadlibrarian.net/167465339/syslog
<hazmat> rogpeppe, yeah.. possibly ^ Feb 24 13:48:41 juju-ci-oxide-machine-0 mongod.37017[5150]: Mon Feb 24 13:48:41.067 [conn2] SocketException handling request, closing client connection: 9001 socket exception [SEND_ERROR] server [127.0.0.1:49239]
<rogpeppe> hazmat: yeah - looks like it might not be keeping its deadlines up to date
<dimitern> quick and easy review anyone? https://codereview.appspot.com/67820048 << rogpeppe, mgz, natefinch, fwereade ?
<natefinch> dimitern: looking
<dimitern> natefinch, ta!
<mgz> dimitern: quick (unrelated) query
<mgz> you say add tests under api/client for the state compat branch
<dimitern> mgz, yeah?
<mgz> but all I see in state/api/client_test.go is a ref back to the tests under state/apiserver/client/
<mgz> unlike the other sections which have dedicated client tests inside their package
<dimitern> is it now.. let me check
<mgz> we have bug 1217282
<_mup_> Bug #1217282: api.Client tests should be in api not state/apiserver/client/ <tech-debt> <juju-core:Triaged> <https://launchpad.net/bugs/1217282>
<dimitern> hmm.. ok, so i must've been thinking of the agent api client tests
<mgz> okay, I'll commit my current fixups for now
<dimitern> then forget what I said :)
<dimitern> the bug is one of these "let's fix the world when we have time"
<mgz> dimitern: thanks. have pushed up the last changes the branch needs, addresses some of your points and fixes a silly error in the reintroduced legacy api
<natefinch> dimitern: reviewed
<dimitern> natefinch, thanks
<dimitern> mgz, i've lgtmed it
<mgz> ta!
<dimitern> blast! i've just realized i'm the ocr today - on to the review queue
<natefinch> rogpeppe: extracting out simpleworker as requested: https://codereview.appspot.com/67080043/
<rogpeppe> natefinch: reviewed
<cjohnston> rogpeppe: fwiw, I downgraded to 1.16.6 and was able to do a full deployment. not sure if it is related to the downgrade or not
<rogpeppe> cjohnston: my suspicion is that it's something to do with changes to a juju-core dependency
<rogpeppe> cjohnston: that's a very useful data point, BTW, thanks.
<cjohnston> :-)
<hazmat> umm. does related-list return self in a peer relation?
<rogpeppe> hazmat: good question. i don't know i'm afraid.
 * rogpeppe is done for the day
<rogpeppe> g'night all
<hazmat> rogpeppe, g'night
<thumper> natefinch: hey
<natefinch> thumper: hoiwdy
<thumper> natefinch: was looking through Dimiter's branch that you just reviewed
<thumper> and I saw a few things that concerned me
<thumper> especially around the arg passing
<thumper> the tests for the extra args aren't written how they will be actually executed
<thumper> testing "-r -o foo" isn't the same as "-r", "-o", "foo" which is how they are passed into init
<thumper> I have a gut feeling that the code is broken
<thumper> but that could just be because I see the tests being wrong
<natefinch> thumper: hmmm... you may be right.  I know that exec doesn't handle that case in the way one might think (where "-o -r" is not the same as "-o", "-r" but I figured we ewre doing some of our own parsing here. I might be wrong
<thumper> I know that the gnuflag library barfs if it gets options it doesn't know about
<thumper> so I was expecting to see either custom arg handling
<thumper> or some errors
<thumper> and saw neither
<natefinch> thumper: yeah, it looks like we're just passing the args as-is, so multiple flags in the same string won't work
<Guest70848> natefinch: why do i get a mongo not supported error message when i'm just trying to bootstrap?
<natefinch> wallyworld: what does mongod --version return for you?
<wallyworld> it is only 2.2.0, but i'm not running services locally to bootstrap an aws env
<wallyworld> although it has worked for local provider till now :-)
<natefinch> wallyworld: hmm... it should only check when you bootstrap local provider. And yeah, it's going to complain if you don't have at least 2.2.2 I think
<wallyworld> natefinch: ah, i'm a idiot
<wallyworld> i forgot to switch to aws provider
<wallyworld> ignore my drivel, sorry
<natefinch> wallyworld: haha ok
<wallyworld> but the version check is new?
<natefinch> yep
<wallyworld> cool :-)
<wallyworld> time to upgrade mongo
<wallyworld> but i've been updating from the repos
<wallyworld> i'll have to see why i'm still on 2.2.0
<natefinch> wallyworld: yeah, that's odd
<wallyworld> i'll figure it out. at least we check
<natefinch> wallyworld: yeah, I added it, figuring it's better to fail early and visibly than to maybe fail further down the road in some random way when an old mongo doesn't work the way we expect.
<natefinch> wallyworld: I should add in a check for TLS support, too, since we require that.
<wallyworld> yep, indeed. a good thing for sure
<wallyworld> that would be good
<wallyworld> i wonder when that mac address bug will be fixed
<wallyworld> hopefully before trusty
#juju-dev 2014-02-25
<thumper> waigani: no real idea what is wrong with your clone
 * thumper goes to make fud
<waigani> thumper: do you have the link to the prototype code for the btrfs stuff?
 * fwereade out for a bit
<jam> dimitern: I'm going to miss the standup today, I have a management training course, can you keep everyone on track?
<dimitern> jam, sure, no worries
<hazmat> g'morning
<natefinch> dimitern:  standup
<natefinch> mgz: ^
<ahasenack> guys, can someone look at these two bugs (dupes): lxc doesn't work with the maas provider
<ahasenack> https://bugs.launchpad.net/juju-core/+bug/1274210
<_mup_> Bug #1274210: Creation of LXC bridge in 1.17.0 fails <micro-cluster> <juju-core:Fix Released by rogpeppe> <juju-core (Ubuntu):Fix Released> <https://launchpad.net/bugs/1274210>
<ahasenack> https://bugs.launchpad.net/juju-core/+bug/1271144
<_mup_> Bug #1271144: br0 not brought up by cloud-init script with MAAS provider <landscape> <local-provider> <lxc> <juju-core:Triaged> <https://launchpad.net/bugs/1271144>
<ahasenack> it's because bridge-utils is installed *after* the bridge is configured and networking is restarted
<ahasenack> so br0 never comes up
<ahasenack> a) configure bridge
<ahasenack> b) restart networking (does nothing useful)
<ahasenack> c) install bridge-utils
<ahasenack> either brigde-utils should be installed before (b), or (b) should happen after (c)
<ahasenack> oh, only happens with the 1.17 series
<ahasenack> 1.16.6 works fine
<hazmat> ahasenack, bridge utils gets installed early in the 1.17.3
<ahasenack> hazmat: not in the bootstrap node
<hazmat> hmm
<ahasenack> hazmat: the above happens in the bootstrap node, for some reason it's provisioned differently
<hazmat> ahasenack, quite possible.. could you pastebin /var/lib/cloud/instance/user-data.txt
<hazmat> on the bootstrap node
<ahasenack> I don't have it anymore
<ahasenack> but it's easy to reproduce
<hazmat> yup
<hazmat> no worries.
 * hazmat connects to a maas env
<ahasenack> hazmat: I have a bootstrap node on maas almost up, if you're interested
<hazmat> i've got one
<hazmat> ahasenack, sure.. re pastebin of its that user-data on the bootstrap node
<ahasenack> hazmat: http://pastebin.ubuntu.com/6994263/
<hazmat> ahasenack, oh.. i forgot.. synchronous bootstrap
<ahasenack> hazmat: here is a bootstrap --debug from sparkiegeek: http://paste.ubuntu.com/6994260/
<hazmat> cool
<hazmat> debugged in the other channel.. bridge only setup on nodes using userdata
<hazmat> which doesn't include the bootstrap node.. for those following along
<mattyw> dimitern, thanks for the reviews - I'll take a look at them and see what I can sort out
<hazmat> well more specifically bridge-utils not installled on bootstrap node till after network create/restart.
<hazmat> which is basically what you diagnosed ahasenack .. just a circle to find out how.
<dimitern> mattyw, cheers
<hazmat> fwereade, ping
<fwereade> hazmat, pong
 * fwereade bbiab again
<wrtp> fwereade, dimitern, natefinch: a review of this would be very much appreciated: https://codereview.appspot.com/68650044
 * wrtp is done for the day
<dimitern> wrtp, looking
<fwereade> wrtp, enjoy your evening
<wrtp> dimitern: thanks
<wrtp> fwereade: will do!
<wrtp> dimitern: there are a couple of drive-by fixes in there that could perhaps be factored out (the testing/mgo.go one prevents a race detector complaint)
<dimitern> wrtp, ha! i was just wondering just about that
<wrtp> dimitern: the change in voyeur just makes it more convenient to use
<dimitern> wrtp, ok istm those are small enough to have them in the same cl
<wrtp> dimitern: thanks; i thought so, but opinions differ...
<natefinch> wrtp: looking, too
<stokachu> in juju 1.16 the bootstrap command didnt block but in 1.17 bootstrap runs synchronously and we are seeing it block for 10m
<stokachu> b/c of the way are scripts work during the cloud installation
<stokachu> should this be considered a bug?
<stokachu> our*
<wrtp> stokachu: most people consider it a feature
<stokachu> wrtp: hah
<stokachu> wrtp: did that behavior change between those versions?
<natefinch> stokachu: yes, behavior changed recently.  I believe it was between those two releases that it went from async to sync.  It's not a bug, it's intended, because otherwise it's hard to know when bootstrap succeeds, without spamming juju status.
<natefinch> stokachu: you can get previous behavior by simply running bootstrap asynchronously yourself
<stokachu> just push to the bg?
<stokachu> i thought there were talks on a switch
<stokachu> even though its intended is it not a bug since that is a breaking change from 1.16 to 1.17
<natefinch> stokachu: it really shouldn't break anything unless you were counting on being able to get stuff done before the bootstrap node comes up, which is essentially purposely creating a race condition
<natefinch> stokachu: at worst it should make your script take longer, but it shouldn't *fail*
<natefinch> stokachu: there's a bootstrap-timeout value you can set in your provider to customize how long it'll wait for bootstrap to finish.  It defaults to 10 minutes, which sounds like is not long enough for you.
<natefinch> stokachu: there's no switch because you can just do juju bootstrap&  ... so no real need for a switch
<stokachu> ok
<stokachu> bbcmicrocomputer: ^
<natefinch> stokachu: juju help bootstrap gives more details about customizing the timeout etc
<stokachu> natefinch: yea we'll probably incrase the timeout and background it
<stokachu> i think that'll work, thanks
<natefinch> stokachu: welcome
<thumper> fwereade: ping
<fwereade> thumper, pong, I'm *finally* looking properly at that doc
<thumper> fwereade: ok, could talk through a few ideas, may be helpful
<fwereade> thumper, sure, give me 5 mins to grab a drink
<thumper> kk
<wallyworld> thumper: do you have time for a hangout?
<wallyworld> sinzui: hi, you still around?
<sinzui> I am
<wallyworld> i found a problem with the metadata on https://juju-dist.s3.amazonaws.com/testing/tools/
<sinzui> really!
<sinzui> well I shouldn
<wallyworld> can you pull up https://juju-dist.s3.amazonaws.com/testing/tools/streams/v1/com.ubuntu.juju:released:tools.json
<sinzui> t question you.
<wallyworld> see line 4
<wallyworld> "version": "1.17.2
<wallyworld> the version attr at that top level overrides the version at the item level
<wallyworld> so it masks the various versions
<sinzui> waigani, so why did juju metadata do that?
<wallyworld> and the 1.17.4 tools metadata records are hidden
<sinzui> wallyworld, , so why did juju metadata do that?
<wallyworld> that i don't know - so you get juju metadata generate-tools ?
<wallyworld> used
<sinzui> wallyworld, this looks the same, but it works. https://juju-ci.s3.amazonaws.com/tools/streams/v1/com.ubuntu.juju:released:tools.json
<sinzui> wallyworld, remember the logs show that the tools url was not used!
<sinzui> wallyworld, while we entered /testing/tools, juju used /tools
<wallyworld> sinzui: what i did just now - i hacked juju so that it only uses tools-url, and then i did a juju metadata validate-tools
<wallyworld> the debug shows tools-url is used
<wallyworld> and shows that only 1.17.2 tools can be found
<wallyworld> since that's the version at that top level
<wallyworld> ah
<wallyworld> 2014-02-25 23:21:03 DEBUG juju.environs.simplestreams simplestreams.go:535 using mirrored products path: https:/juju-dist.s3.amazonaws.com/tools/streams/v1/com.ubuntu.juju:released:tools.json
<wallyworld> seems like it is getting the /tools from the mirrors file
<wallyworld> let me check
<sinzui> wallyworld, slow down you are trying to solve a hack, not the actual problem
<sinzui> wallyworld, I am about to update juju-ci to use the proper url, you can watch the out and see that the tool-url is wrong, it is not what we entered
<wallyworld> ok, but my debug shows tools-url is being used
<wallyworld> and that it seems like mirrors processing then causes /tools to be used
<sinzui> There are no mirror files on aws
<sinzui> I set this tools-url: http://juju-dist.s3.amazonaws.com/testing/tools
<sinzui> wallyworld, the log has started http://162.213.35.54:8080/job/aws-deploy/860/console
<sinzui> and I see this
<sinzui> tools-metadata-url: http://juju-dist.s3.amazonaws.com/testing/tools.
<sinzui> and maybe to your point, the wrong juju was found
<wallyworld> sinzui: while we wait, the cpc-mirros.json file on testing/tools has this
<wallyworld>         "mirror": "https://juju-dist.s3.amazonaws.com/tools",
<wallyworld>         "path": "streams/v1/com.ubuntu.juju:released:tools.json",
<wallyworld> so my debug shows testing/tools is being used
<sinzui> well not you your point, to my point, the wrong url was used, so it looked at what I released last week and used it
<wallyworld> but that then the mirrors file causes it to redirect to /tools
<sinzui> oh!
<sinzui> we don't permit mirrors files on the CPCs
<wallyworld> huh?
<sinzui> only streams gets the file
<wallyworld> i thought we did, so that the CPCs loaded tools locally
<sinzui> streams.canonical.com get it, and any site I choose to use as a proxy
<wallyworld> so you saying that testing/tools should not have a mirror file?
<sinzui> waigani, but you are correct, that file got put there.
<waigani> wallyworld: ^
<sinzui> wallyworld, I am say that, nor should any CPC. why put a mirror file to the site you are on
<sinzui> sorry waigani
<waigani> sinzui: no problem ;)
 * sinzui starts purging
<wallyworld> sinzui: if that console output had --debug that would show more info to help diagnose the issue and the search path used by simplestreams
<sinzui> wallyworld, I know, abentley doesn't care for that level of detail in the log
<wallyworld> sure, normally i would agree. but it would have helped here :-)
<sinzui> wallyworld, new run http://162.213.35.54:8080/job/aws-deploy/861/console
<wallyworld> maybe we can turn it on when there's an issue
<sinzui> the version is correct
<wallyworld> sinzui: my validate-tools now passes
<wallyworld> now that  the mirros file is removed
<wallyworld> $ juju metadata validate-tools
<wallyworld> matching tools versions:
<wallyworld> 1.17.4-precise-amd64
<wallyworld> it failed just before but works now
<abentley> sinzui: It's not the level of detail that's the problem, it's the fact that it contain credentials.
<sinzui> wallyworld, in testing_to_aws in http://bazaar.launchpad.net/~juju-qa/juju-core/ci-cd-scripts2/view/head:/publish-public-tools.bash  we do filter *mirror*. it has always been that way, but If someone put one there, it will not be removed by the sync op
<sinzui> does --debug contain credentials? Oh is the config output?
<wallyworld> i would hope --debug doesn't contain credentials but if it does that sucks and should be fixed
<wallyworld> sinzui: i've been thinking for a while i should add extra output to validate-tools to not only print the tools found but also the path from which they were got incl whether from tools-url vs cloud storage etc and whether a mirror was used
<abentley> wallyworld: That's what I remember.
<wallyworld> abentley: it may have been that way previously. i seem to have a vague, perhaps incorrect, recollection "someone" fixed it
<wallyworld> i can verify that
<wallyworld> s/can/will
<sinzui> wallyworld, that would be a lovely diagnostic. When I report bugs like this, I do test manually with --debug, I saw the urls switch, but did not notice the mirror use
<abentley> wallyworld: I believe it was printing out the config, as sinzui suggested.
<wallyworld> abentley: i think config is now sanitised to exclude credentials, but am not 100%
<wallyworld> sinzui: if i add the extra output, the ci scripts could do a validate-tools at the state and check the output is as expected before bootstrapping and failing
<wallyworld> s/state/start
<sinzui> wallyworld, they certainly can
<wallyworld> same for image metadata
<sinzui> success
<wallyworld> \o/
 * sinzui starts the upgrade job
 * wallyworld crosses fingers
<sinzui> Finland has police raindeer. I bet the have fairy lights and bells instead of sirens
<wallyworld> lol
 * sinzui restores the url for the trusty tests
<sinzui> I am the likely person who put the mirror file there. I can't think how, but I will take the blame
<wallyworld> sinzui: i do also want to get to the bottom of how we got those top level version attrs in the json. i'll check the ci scripts and metadata generation cmd in juju to see what might be going on
<wallyworld> i'm just glad we found what was happening
<wallyworld> and it gives me an excuse to spend the time to do better diagnostics
<sinzui> fab, all works, now that all the mirror files are deleted. Thank you very much wallyworld
<wallyworld> no problem. pleased to help. i'm so grateful for the CI stuff you guys have done
#juju-dev 2014-02-26
<wallyworld> thumper: you around?
<bradm> anyone know much about neutron?  having issues with a juju deployed openstack
<wallyworld> bradm, mgz knows most about neutron but he's probably asleep
<bradm> wallyworld: I seem to be on the wrong side of the world to be dealing with neutron, everyone who seems to know it is asleep
<wallyworld> yeah :-(
<thumper> wallyworld: hi
<wallyworld> gday
<wallyworld> got time for a chat?
<thumper> yup
<thumper> ish
<wallyworld> it will be quick, just a heads up from the standup last night
<wallyworld> https://plus.google.com/hangouts/_/calendar/bWFyay5yYW1tLWNocmlzdGVuc2VuQGNhbm9uaWNhbC5jb20.sbtpoheo4q7i7atbvk9gtnb3cc?authuser=1
<davecheney> 2014-02-26 01:11:42 ERROR juju runner.go:220 worker: exited "environ-provisioner": failed to process updated machines: error executing "lxc-ls": wait: no child processes
<davecheney> 2014-02-26 01:11:43 ERROR juju.container.lxc lxc.go:166 failed getting all instances: error executing "lxc-ls": wait: no child processes
<davecheney> ^ local provider peeps
<davecheney> any ideas ?
<axw> can't say I've seen that. busted packages again? :(
<davecheney> is lxc-ls bailing before the wait occurs ?
<axw> ah, I read it as an error coming back from lxc-ls
<davecheney> ubuntu@winton-02:~$ lxc-ls
<davecheney> ubuntu@winton-02:~$ echo $?
<davecheney> 0
<axw> not sure.
<davecheney> weird
<axw> try lxc-ls -1
<axw> (one, not ell)
<axw> and again as root
<davecheney> ubuntu@winton-02:~$ sudo lxc-ls
<davecheney> dave  foo   ken   ryu
<davecheney> interesting
<davecheney> ubuntu@winton-02:~$ ps auxww | grep jujud
<davecheney> root     24736  3.0  7.5 8262756 621576 ?      Ssl  Feb22 174:19 /home/ubuntu/.juju/local/tools/machine-0/jujud machine --data-dir /home/ubuntu/.juju/local --machine-id 0 --debug
<davecheney> but the machine agent is running as root
<axw> does "sudo lxc-ls -1" do anything different?
<axw> doubtful..
<axw> davecheney: the golxc code is just doing exec.Command("lxc-ls", "-1").CombinedOutput()
<axw> so... *shrug*
<davecheney> ubuntu@winton-02:~$ sudo lxc-ls -1
<davecheney> dave
<davecheney> foo
<davecheney> ken
<davecheney> ryu
<davecheney> same, but different
<davecheney> screw it
<axw> yeah -1 just means one per line, didn't think it'd matter
<davecheney> gonna destroy and start again
<thumper> waigani: ping - standup
<davecheney> + /home/ubuntu/bin/juju destroy-environment -y local
<davecheney> + /home/ubuntu/bin/juju bootstrap
<davecheney> ERROR cannot use 37017 as state port, already in use
<davecheney> sigh
<davecheney> bloody hell
<davecheney> what ?
<davecheney> there is nothing listening on that port ....
<davecheney> ERROR cannot use 37017 as state port, already in use
<davecheney> ubuntu@winton-02:~$ ss | grep 37017
<davecheney> ubuntu@winton-02:~$
<mwhudson> davecheney: i don't think that's a good way to check
<mwhudson> you want ss -nl i think?
<davecheney> oh
<davecheney> serves me right for using hipster tools
<davecheney> i'll go back netstat -anp next time
<davecheney> ubuntu@winton-02:~$ sudo !!
<davecheney> sudo netstat -anp | grep 37
<davecheney> tcp        0      0 0.0.0.0:37017           0.0.0.0:*               LISTEN      24711/mongod
<davecheney> intersting
<davecheney> i wonder why it didn't die
<thumper> axw, wallyworld, waigani: we'll just use this one... https://plus.google.com/hangouts/_/calendar/dGltLnBlbmhleUBjYW5vbmljYWwuY29t.kieq2g96khnegtjsretb0l4clo
<wallyworld> thumper: says not allowed to join
<thumper> pfft
<axw> same
 * thumper sighs
<thumper> this was the one from the package review
<thumper> you are now invited
<jam> thumper: poke, are you still online?
<thumper> jam: yes, am with the team talking timings :)
<jam> thumper: I'm available for video chat for a bit if you want
<thumper> jam: available now
<jam> thumper: starting up G+ hangout now
<thumper> kk
<jam> thumper: https://plus.google.com/hangouts/_/7ecpikfgr7oi6hsg74ds6jdcl0
<bigjools> thumper: seriously lol-ing at your twitter conversation this morning
<axw> oh wtf
 * axw stops wtf'ing
<axw> the bot marked the wrong MP as merged
<jam> axw: where?
<jam> I can't say that I've seen that before
<jam> the bot doesn't actually do it
<jam> Launchpad detects when the tip revision has been merged into trunk
<jam> so it is generally accurate
<axw> jam: https://code.launchpad.net/~axwalk/juju-core/lp1281071-rsyslog-tls/+merge/207889
<axw> what I did was I created another branch, merged that one in but removed all the stuff I didn't care about
<axw> so LP saw the merged revisions
<jam> axw: the above branch is "andrew.wilkins@canonical.com-20140225140210-4206fc8pbnfkpb46" which is rev 2349.2.5 in trunk
<jam> so that MP was *merged*, just from something else
<axw> yeah, makes sense - I just haven't done that before and was a bit surprised
<jam> be careful when clicking near tabs :)
<axw> :)
<axw> <axw> yeah, makes sense - I just haven't done that before and was a bit surprised
<axw> jam: yes, the rev is there, I just took out most of what's in that MP
<dimitern> fwereade, wrtp, i'd appreciate a review and some direction on https://codereview.appspot.com/66540044
<wrtp> dimitern: looking
<wrtp> dimitern: reviewed
<dimitern> wrtp, ta!
<mattyw> dimitern, your review here: https://codereview.appspot.com/67870043/ do you mean I need to implement the new status code in FullStatus only - and not in Status?
<dimitern> mattyw, FullStatus only - Status uses FS internally, when needed (1.16 compat mode)
<dimitern> fwereade, wrtp, so, it seems we'll need to define the next agent conf version - should it be 1.17 or 1.18? I'm thinking of adding Version, DataDir, LogDir, possibly Jobs as fields
<rogpeppe> dimitern: i don't think it makes sense to define formats for dev versions
<mattyw> dimitern, ok thanks
<rogpeppe> dimitern: so i'd suggest 1.18
<dimitern> rogpeppe, ok, and in that version we'll use a single file + version, no format separately
<rogpeppe> dimitern: yeah
<dimitern> rogpeppe, can you think of any other fields we might need to define except the ones above?
<rogpeppe> dimitern: what is "Version" there? the agent configuration version?
<dimitern> rogpeppe, ok Format then
<rogpeppe> dimitern: what does it hold?
<dimitern> rogpeppe, the agent conf format version
<rogpeppe> dimitern: i'm not sure we want to expose that outside of the agent package
<rogpeppe> dimitern: and i don't think it should be a regular field
<rogpeppe> dimitern: i suggest that we store the version on a line of its own before any of the other conf data
<dimitern> rogpeppe, expand?
<rogpeppe> dimitern: then we can read the version and use it to decide how to parse the rest of the config data
<rogpeppe> dimitern: which gives us freedom to change file formats in the future if we want (for example to move away from YAML)
 * rogpeppe has just got his laptop back through the post
<rogpeppe> and they've cleaned it all up - it doesn't look like my scruffy laptop any more :-)
<rogpeppe> let's see if it works...
<rogpeppe> ha, they replaced the keyboard!
<jam> rogpeppe: I'm glad you got it back in time, congrats
<dimitern> rogpeppe, \o/
<dimitern> rogpeppe, ok, that sgtm
<rogpeppe1> jam: yay! back on the thinkpad!
<jam> rogpeppe: fwereade, dimitern: standup?
<jam> fwereade: poke ?
<fwereade> jam, sorry, couple of mins
<jam> mgz: poke ?
<mgz> jam: ta
<jam> fwereade: one more quick standup ping?
<rogpeppe> fwereade: https://codereview.appspot.com/68650044
<jam> rogpeppe: https://bugs.launchpad.net/juju-core/+bug/1254577 is still marked Critical and not Fix Committed. I thought you landed code related to that?
<rogpeppe> jam: marked as "fix committed"
<jam> rogpeppe: do you know if that got released in 1.17.3
<jam> ?
<rogpeppe> jam: i certainly hope so. let me check.
<rogpeppe> jam: well, the fix was merged 3 weeks ago, so i should certainly hope so
<jam> does anyone have the link to the current CI runs? I seem to have an old IP address that is no longer valid
<jam> sinzui: ^^
<natefinch> jam: FYI I have an old IP too, not sure what happened.  Sinzui is likely still asleep, but when he responds, I'll email out the new IP.
<fwereade> frankban, dimitern: does charm get handle symlinks at all?
<dimitern> fwereade, because it uses a zip reader internally, i guess it should
<fwereade> frankban, dimitern: it looks like it's just sending the target path and I'm not convinced that's useful
<frankban> fwereade: I guess it depends on how they are handled by zip.ReadCloser
<dimitern> frankban, fwereade, but a test with a zip + symlinks is definitely useful
<fwereade> frankban, dimitern: ok, what do you think we should be doing? sending the actual content of the target?
<frankban> fwereade: makes sense
<dimitern> fwereade, frankban, that sounds reasonable
<frankban> fwereade, dimitern: trying with a symlink
<fwereade> dimitern, frankban: ok, cheers, I'll see what I can do
<fwereade> dimitern, frankban: also, would it be *really* annoying if I changed the filelist stuff to return directories as well? I freely admit this is more rooted in convenience than any solid design principles
<fwereade> dimitern, frankban: hmm, I think we may need special handling for the revision file too
<frankban> fwereade: not annoying for me
<fwereade> frankban, cool, basically I'd like to just return the result of the imminently-available Bundle.Manifest method
<frankban> fwereade: re: revision file, is it special?
<fwereade> frankban, its presence is not guaranteed in the zip file, but it is always returned by Manifest because we do always write one out
<frankban> fwereade: oh, so you'll instantiate a bundle and it will have a Manifest returning the file list?
<fwereade> frankban, it'll *almost* certainly always be there, but it's that "almost" that's the issue ;)
<fwereade> frankban, yeah, I think so -- is a ReadBundle unreasonable at that point?
<frankban> fwereade: OIC, if it's not there there is no problem from our perspective, AFAICT we are not interested in the revision file for that API. but I agree, if it's in the list, we must also return its contents
<frankban> fwereade: in my previous impl (before requirements changes) I used ReadBundle to and ExpandTo to extract the files, so, it makes sense. I wonder if at that point a bundle.GetFile would be reasonable too.
 * fwereade starts wondering about a Content(path) method
<fwereade> frankban, yeah, I'm just having trouble integrating the symlink-resolution stuff in my current model
<fwereade> frankban, how do we currently behave if you ask for a path to a dir?
<fwereade> frankban, ah 403 cool
<frankban> fwereade: forbidden
<frankban> yeah
<fwereade> frankban, ok, I think that works for me
<fwereade> frankban, dimitern: can we do a really quick hangout?
<frankban> fwereade: sure
<dimitern> fwereade, frankban, sure
<fwereade> dimitern, frankban: https://plus.google.com/hangouts/_/7ecpjumv8629dqrig0jdegier8?hl=en
<rogpeppe> fwereade: you've got a review: https://codereview.appspot.com/69110043/
<sinzui> jam, natefinch http://162.213.35.54:8080/ and it appears ill (and we stood it up 2 days ago too)
<sinzui> oh, no route to host
<jam> sinzui: k, so that I can't get to it is probably because it isn't there :)
<natefinch> heh
<rogpeppe> dimitern: i've responded to your review
<rogpeppe> dimitern: i'd appreciate the rest, if you have some time
<dimitern> rogpeppe, thanks, i'll look into it a bit later
<rogpeppe> dimitern: ta
<rogpeppe> natefinch, fwereade: your reviews appreciated too
<niemeyer> rogpeppe: Hey, just a ping to let you know your branch got merged, and the tests that were failing due to the panic formatting changes in recent Go versions have also been fixed
<rogpeppe> niemeyer: great, thanks. i was planning to get around to merging it, but my laptop died which was a distraction
<rogpeppe> niemeyer: i'll update the juju-core deps file
<niemeyer> rogpeppe: Thanks
<dimitern> rogpeppe, what are these cryptic 0v 1p in member definitions
<rogpeppe> dimitern: see the definition of mkMembers and mkStatuses
<dimitern> rogpeppe, right, thanks
<niemeyer> mramm, fwereade: Are we having that call today?
<mramm> I'm in the hangout
<mramm> if you want to have it
<mramm> but I don't have any items for today's agenda
<mramm> so I am also fine with skipping today
<niemeyer> mramm: I'm joining
<natefinch> rogpeppe: resuming the review now
<rogpeppe> natefinch: thanks!
<rogpeppe> lunch
<sinzui> natefinch, rogpeppe , is someone adding support to install juju-mongodb when it is available?
<rogpeppe> sinzui: i think that's the plan, but i don't know its current status
<sinzui> rogpeppe, thank you
<dimitern> rogpeppe, reviewed
<rogpeppe> dimitern: ta!
<natefinch> sinzui: it is planned but I don't think anyone is assigned. I did the other part, but someone else should probably do this part, since I am way behind on HA stuff.
<sinzui> natefinch, fab. I think I will work to release juju 1.17.4 as it is for people working on trusty and other archs
<dimitern> rogpeppe, fwereade, so with the introduction of agent conf format 1.18 we should drop 1.12 format support, right?
<fwereade> rogpeppe, would you explain the windows 022 thing a bit more?
<rogpeppe> fwereade: i think so
<rogpeppe> dimitern: i think so
<dimitern> ok :)
<fwereade> dimitern, hmm, I have a nasty feeling that 1.12 might try to upgrade arbitrarily far
<rogpeppe> fwereade: so, i'm not convinced that we'll get sane-looking perms from windows-generated zip files
<dimitern> fwereade, so?
<dimitern> fwereade, it will fail
<rogpeppe> fwereade: from previous experience with unix-like perms on windows
<rogpeppe> fwereade: natefinch may know more of the expected behaviour
<fwereade> dimitern, so I'm not sure that we can guarantee that 1.18 won't start up with a 1.12 conf
<fwereade> dimitern, it may just be a matter of shouting about it in the release notes though
<fwereade> rogpeppe, natefinch: in particular I don't quite get what `&=022` would do, maybe because I'm not sure where you mean me to apply it
<dimitern> fwereade, well, we can't guarantee compatibility 16 releases back anyway, so it should just fail in some sensible way
<rogpeppe> fwereade: it would clear group and other write permissions from all files and directories
<rogpeppe> fwereade: sorry, it should have been &^022
<rogpeppe> fwereade: another possibility is to use ((p&7) | (p&7)<<3 | (p&7)<<6)) & ^022
<rogpeppe> fwereade: i.e. ignore group and other modes, don't allow any group/user write perms, and use r and x bits from user perms for group and other
<rogpeppe> fwereade: but that means it's not possible to make a non-group or other -readable file
<natefinch> fwereade, rogpeppe:  catching up....   perms on windows are way different.  Not 100% sure on how Go translates permission bits to windows
<rogpeppe> natefinch: yeah.
<rogpeppe> natefinch: what do you think windows-created zip files will report for permissions?
<rogpeppe> natefinch: perhaps you could create a zip file under windows, with a variety of permissions, and we could find out
<natefinch> rogpeppe: yeah, that';s what I was thinking.  I don't know what linux defaults to when it sees a windows file that doesn't have permissions like that set.  I'll try it out, easy enough
<rogpeppe> fwereade: one thought is that if we're unpacking the charm under unix, it's pretty unlikely that the charm was zipped under windows
<rogpeppe> natefinch: i did some of the go zip perms code, ages ago, but i can't remember much about it and it's probably changed since i did it
<rogpeppe> natefinch: i think the trauma of reading the zip spec must've blanked my memory :-]
<natefinch> rogpeppe: hahah
<fwereade> natefinch, rogpeppe: sorry, multitasking fail
<natefinch> rogpeppe: by default it's 0664
<rogpeppe> natefinch: which default?
<natefinch> -rw-rw-r--  for those of us less binarily inclined
<natefinch> rogpeppe: if I just create a zip without specifying permissions
<rogpeppe> natefinch: is that Go's behaviour or windows' ?
<natefinch> rogpeppe: windows, sorry
<rogpeppe> natefinch: have you tried unpacking that using Go, to make sure
<natefinch> rogpeppe: not yet, I'll do that
<natefinch> rogpeppe: unpacking on linux, I presume?
<rogpeppe> natefinch: it shouldn't make any difference
<rogpeppe> natefinch: you don't actually need to create the file
<fwereade> rogpeppe, natefinch: fwiw we *do* make sure that hooks are executable when we unpack *anyway* and I suspect this hits most of the cases -- 644/744 should be enough for anyone, right?
<rogpeppe> natefinch: just see what perms are reported
<fwereade> rogpeppe, natefinch: indeed assuming that *is* what's reported
<rogpeppe> fwereade: i'd go for 755 rather than 744
<rogpeppe> fwereade: but yeah, i don't think there's a huge issue here
<rogpeppe> fwereade: it's worth going into it with our eyes open though
<rogpeppe> fwereade: (i have definitely hit problems in this area in a previous lifetime)
<fwereade> rogpeppe, natefinch: I'm not *really* expecting we'll get a lot of people writing charms on windows anyway tbh
<fwereade> rogpeppe, natefinch: drag a charm archive into a browser on windows? plausible
<fwereade> rogpeppe, natefinch: zip up a subtly wrong dir and drag it into a browser on linux? also plausible
<fwereade> rogpeppe, natefinch: "develop" a charm sight unseen on windows, and deploy it to a real ubuntu cloud straight off? seems less likely
<rogpeppe> fwereade: it's possible but i think that the resulting issues probably won't be *too* bad
<rogpeppe> fwereade: exactly
<rogpeppe> fwereade:  one other thing occurs to me: the perms you'll get when creating a file with os.OpenFile may well be different from the perms you get when doing a chmod
<rogpeppe> fwereade: because of umask
<rogpeppe> fwereade: to be consistent, perhaps we should AND all the perms with the current umask before doing anything
<fwereade> &^umask, right?
<natefinch> rogpeppe, fwereade: btw the unzipped files w/ go are created with 0664, too.
<rogpeppe> fwereade: yeah
<rogpeppe> natefinch: that's not a great default, but umask should sort it out
<fwereade> natefinch, ok, that seems probably good enough to me?
<fwereade> rogpeppe, added v brief notes on https://codereview.appspot.com/68650044/ -- I'll be looking at it some more
<fwereade> rogpeppe, but it is explicitly *not* nlgtmed, so please do not take my need to convince myself further as a roadblock
<rogpeppe> fwereade: i'd be interested to know what kind of thing you're thinking about when you suggest a "simpler and dumber model"
<rogpeppe> fwereade: i agree that the current mocking setup is somewhat experimental, but i *think* it beats trying to get the real State to jump through all those hoops
<fwereade> rogpeppe, yeah, definitely agreed
<rogpeppe> fwereade: the IsNotFound cases are the only place in the code we don't have 100% coverage. that's mainly because i haven't yet thought of a decent way to "wait for nothing to happen"
<rogpeppe> fwereade: i'd also be interested to know where you found it difficult to follow the code, so i can add an appropriate comment or two
<fwereade> rogpeppe, I'll hopefully have some better comments later today
<rogpeppe> fwereade: i've just approved the MP BTW, but i'll take on board any further comments and integrate them into the next branch
<fwereade> rogpeppe, I do find myself wondering whether we actually kinda want to unpack charms with the permissions in the zip file, umask be damned
<fwereade> rogpeppe, thanks
<rogpeppe> fwereade: i'm not sure
<rogpeppe> fwereade: an easy way to do that is to set umask to 0
<rogpeppe> fwereade: umask is kinda dumb anyway
<rogpeppe> fwereade: i preferred the plan 9 way of doing things, where the default perms were taken from the parent dir
<fwereade> rogpeppe, heh, but then we do want to keep using the default umask for hook execution I think
 * fwereade rather agrees tere
<rogpeppe> fwereade: i don't know. what do you think the expectation of umask is for charm authors?
<fwereade> rogpeppe, there were bugs about it in the past
<fwereade> rogpeppe, iirc the expectation is "execute hooks with the system umask"
<rogpeppe> fwereade: the other thing that i didn't remark on in the review, is what happens if you have a directory with non-writable permissions, but it contains some files?
<rogpeppe> fwereade: i *think* that in general it's a moot point because zip files don't usually mention directories explicitly
<rogpeppe> fwereade: but it can be an issue
<fwereade> rogpeppe, yeah, my thinking was mainly that unwritable things are unlikely to come up in practice, and when they do we have ErrConflict
<fwereade> rogpeppe, because I certainly don't know what the point of having such things would be
<rogpeppe> fwereade: alternatively, make sure that all directories are at least 700
<rogpeppe> fwereade: me neither, but it's difficult to pre-guess
<fwereade> rogpeppe, and thus am unqualified to impose expectations
<ev> hiya. Is ssh forwarding broken? http://paste.ubuntu.com/7000920/
<ev> that's on 1.17.3-saucy-amd64
<rogpeppe> ev: hmm, it would be interesting to find out what actual command line is being executed there
<ev> rogpeppe: hm? Isn't that in the pastebin?
<mgz> is that just bug 1281577
<_mup_> Bug #1281577: juju 1.17.2 doesn't pass command line options to ssh <docs> <landscape> <regression> <ui> <juju-core:Fix Committed by dimitern> <https://launchpad.net/bugs/1281577>
<ev> ah, that's the badger
<ev> thanks guys
<rogpeppe> ev: no, sorry, i mean the ssh comment
<rogpeppe> mgz: thanks
<mgz> ev: sinzui is doing 11.17.4 today which has the fix
<mgz> -1
<ev> whoop!
<natefinch> rogpeppe, fwereade: btw, it looks like zip files don't actually include the directory information, just implicitly through paths on files (at least the ones I created on windows 7).
<fwereade> natefinch, would you mail me one please?
<rogpeppe> natefinch: that's what i meant by "zip files don't usually mention directories explicitly"
<rogpeppe> natefinch: i think it's possible for them to do so though
<rogpeppe> natefinch: i *think* it's possible to have empty dirs in a zip file
<natefinch> rogpeppe: windows won't let you do it : [Window Title]
<natefinch> Compressed (zipped) Folders
<natefinch> [Content]
<natefinch> Windows was unable to add one or more empty directories to the Compressed (zipped) Folder.
<natefinch> [OK]
<rogpeppe> natefinch: ha ha
<rogpeppe> natefinch: no one likes those poor empty directories
<natefinch> rogpeppe: I'd just been testing that
<rogpeppe> natefinch: apart from bzr, which is being phased out
<natefinch> rogpeppe: yeah, it's kinda sad, because they can have value.
<rogpeppe> natefinch: they're really important sometimes
<natefinch> rogpeppe: if for nothing else than "here's where you should put X stuff"
<mgz> natefinch: certainly tools *exist* on windows that let you add empty dirs to zips...
<mgz> whether they're what people use is another matter
<natefinch> mgz: yeah, probably 7zip etc would allow it.  Certainly we should support it if it's possible.
<mgz> 7zip does, just tested
<natefinch> mgz: good to know.
<natefinch> rogpeppe: we should probably talk HA next steps before your EOD, or jam will have my head for not putting up some tasks on kanban
<rogpeppe> natefinch: i'm just working on that, but let's have a chat about it
<rogpeppe> natefinch: in fact, give me 10 mins to finish my thoughts here
<natefinch> rogpeppe: sure thing'
<sinzui> mgz, ev : I hope to do a 1.17.4 release tomorrow. nova/canonistack lost the ci machine abotu 12 hours. We had to stand up another one as our first priority
<mgz> sinzui: eck... we need a less overcommitted region probably :0
<sinzui> mgz, It happened last week too. We will move to another region or cloud
<ev> sinzui: *nods* I've just sent instructions to my team on using juju from trunk for this
<rogpeppe> natefinch: https://plus.google.com/hangouts/_/calendar/am9obi5tZWluZWxAY2Fub25pY2FsLmNvbQ.mf0d8r5pfb44m16v9b2n5i29ig?authuser=1
<ev> HP has hilariously set really low limits on not only security groups, but security group rules
<ev> so wooo tunnels
<ev> I don't suppose I could convince someone to update the simplestreams stuff to use the new US/West HP Cloud region?
<ev> we've uploaded the right thing to a public bucket on one of our HPCloud accounts for now
<sinzui> ev, Juju-CI just built UNRELASED debs for trusty, saucy, and precise. This is the release candidate we are testing: http://162.213.35.54:8080/job/publish-revision/
<sinzui> if ev, this is the actual release tarball we will use on success: http://162.213.35.54:8080/job/build-revision/
<ev> ( https://region-a.geo-1.objects.hpcloudsvc.com/v1/11289530460295/images and https://region-a.geo-1.objects.hpcloudsvc.com/v1/11289530460295/tools )
<ev> sinzui: *nods* thanks!
 * rogpeppe is done for the day
<rogpeppe> g'night all
<rogpeppe> fwereade: there are now some kanban cards for HA, BTW
<thumper> o/
<thumper> waigani: https://bugs.launchpad.net/juju-core/+bug/1281394
<_mup_> Bug #1281394: uniter failed to run non-existant config-changed hook <regression> <juju-core:Triaged by thumper> <https://launchpad.net/bugs/1281394>
<thumper> wallyworld: just for you: http://pastebin.ubuntu.com/7002116/
<wallyworld> looking
<wallyworld> is this trunk?
<thumper> aye
<thumper> pulled trunk, started a local provider
<wallyworld> hmmm. worked for me before :-(
<wallyworld> and CI
<wallyworld> ok, i'll have to look
<thumper> and also deployed ubuntu charm
<thumper> that is all
<thumper> well, it is up and running
<thumper> but the worker is bouncing
<wallyworld> sigh, yeah will look
<wallyworld> but i'm in a good mood - got support for IDE based debugging :-)
<wallyworld> niiiiiice
<wallyworld> no more fmt.Printf() to see wtf is going on
<thumper> haha
<thumper> nice
<waigani> Tim just shot me
<thumper> nerf
<wallyworld> thumper: what juju version were you upgrading local provider env from?
<thumper> I wasn't upgrading
<thumper> I was just starting it
<wallyworld> hmmm. ok
<wallyworld> thumper: since you're ocr :-) could you +1 this one roger looked at - i've responded to changes but he didn't get to +1 yesterday. there's also https://codereview.appspot.com/68990043/ :-D
<thumper> i'm ocr?
<wallyworld> it says so on the calendar :-)
 * thumper sighs
<thumper> suppose I am then...
<thumper> yes, I'll look soonish
<wallyworld> yep :-)
<wallyworld> no hurry
<wallyworld> i have 4 branches stacked up i need to land
<wallyworld> so just keen to clear the queue sometime today or whenever
<thumper> yeah yeah
 * thumper puts wallyworld on the TODO soonish stack
<wallyworld> no hurry
#juju-dev 2014-02-27
<marcoceppi> What would it take to make region a constraint rather than an environments.yaml key?
<marcoceppi> Would that even be a worthwhile endevor?
<thumper-gym> marcoceppi: not worthwhile IMO
<wallyworld_> thumper: https://codereview.appspot.com/68250046/
<thumper> ta
<thumper> wallyworld_: I feel much more comfortable now that the existing tests failed :) and it is just that you didn't run them
<wallyworld_> yep
<wallyworld_> i did say that also in my reply to roger :-)
<thumper> davecheney: hey, not sure why hp was failing deploying ubuntu charm
<thumper> wallyworld_: ah, missed that
<wallyworld_> np :-)
<thumper> davecheney: works on amazon and local
<thumper> davecheney: what is hp doing different?
<thumper> has me very confused
 * thumper pats wallyworld_ on the back for implementing something that I need
<wallyworld_> which iiis?
<wallyworld_> thumper: what did i implement?
<thumper> --description for the supercommand so it works nice with plugins
<wallyworld_> ah, that was a while ago
<thumper> yeah
<thumper> when you did the metadata one I think
<wallyworld_> thumper: if you get a chance at some point, i've updated the system key updater to use keymanager https://codereview.appspot.com/68990043
<thumper> kk
 * thumper is getting sidetracked by other issues...
 * thumper must get back on track
 * thumper files bugs
<marcoceppi> thumper: I guess it's best to just wait for cross environment relations?
<thumper> marcoceppi: ENOCONTEXT
<marcoceppi> thumper: re: regions as constraints
<thumper> marcoceppi: yes
<wallyworld_> thumper: ffs. found the local provider tools issue. host machine is trusty, charm is precise, so looks for different tools
<wallyworld_> gotta think about the least invasive way to fix
<thumper> wallyworld_: ah...
<thumper> wallyworld_: interesting
<thumper> wallyworld_: hang on
<thumper> wallyworld_: trusty is only the machine 0
<thumper> machine 1 which has the charm is precise
<wallyworld_> yep
<wallyworld_> the wrong location is being used somehow
<thumper> ok
<wallyworld_> the UA on machine 1 talks to state server on machine 0
<wallyworld_> the state server looks in its data dir for tools
<wallyworld_> and only finds trusty
<axw_> wallyworld_, thumper: I merged trunk into a branch and reproposed... now the changes from trunk are coming through in Rietveld. LP has the correct diff. Anyway to fix Rietveld's diff?
<wallyworld_> axw_: nope :-(
<wallyworld_> shiteveld sucks
<thumper> axw_: delete the merge proposal in LP
<wallyworld_> launchpad rocks
<axw_> hrm, I may have been impatient anyway
<thumper> and start again
<axw_> it might be okay. yeah I thought that'd be the answer :\
<wallyworld_> same thing happened to me today
<wallyworld_> with my system ssh key upgrader branch
<axw_> ah it's okay, I was looking at diff-from-previous which adds things as expected... PEBKAC
 * thumper looks at https://code.launchpad.net/~wallyworld/juju-core/system-sshkey-upgrader/+merge/208277 because reitveld is dumb at trunk merges
<wallyworld_> yes it is :-(
<thumper> wallyworld_: can't see the trivial test I wanted...
<wallyworld_> oh, did i forget
<wallyworld_> let me check the comment again
<wallyworld_> thumper: all i did in auth keys was to add 2 constants
 * thumper demands tests
<thumper> that's all it does now
<thumper> what about later?
<thumper> the test is trivial to write
<wallyworld_> sigh. the code was already in trunk
<thumper> I know...
<thumper> but you made it public
<thumper> public functions should have tests
 * thumper pays wallyworld_ back for demanding tests
 * thumper is just helping really
<wallyworld_> thumper: i didn't write any of that code
<wallyworld_> but ok
<thumper> call it review creep
<thumper> it earns you brownies
 * wallyworld_ sighs again 
<wallyworld_> yeah yeah
<axw_> thumper: finally got the tests done... new CL for worker/rsyslog: https://codereview.appspot.com/68930045/
 * thumper-afk back for meeting later
<axw_> wallyworld_: I now have an LGTM for https://codereview.appspot.com/68930045/, but not for its prereq. If you have a spare few minutes, would you mind taking a look at https://codereview.appspot.com/69000043/?
<axw_> basically just deleting a whole lot of code :)
<axw_> if you're too busy it can wait till tomorrow
<wallyworld_> looking
<rogpeppe1> mornin' all
<ev> hazmat: how's your super sexy juju lxc fast provisioning coming along?
<mattyw> dimitern, do you have a moment?
<dimitern> mattyw, sure
<dimitern> about 15m to the weekly meeting
<thumper> ev: o/
<thumper> ev: I'm takeing hazmat's fast lxc and putting it in trunk
<thumper> expect some good stuff over the next few weeks
<ev> thumper: you're my hero
<dimitern> fwereade, mgz, meeting?
<mgz> dstroppa: around again, poke me if you have more StopInstances questions
<dstroppa> thanks mgz, I've made some changes, running tests now
<dstroppa> back to the other issue: I've update goose, but now get this http://paste.ubuntu.com/7004730/
<dstroppa> running on precise
<mgz> dstroppa: but `go build ./...` is clean?
<dstroppa> mgz: same error
<mgz> dstroppa: but no more details? if the branch doesn't build you want to get a proper error out of the go compiler
<dstroppa> mgz: this is the only output I get http://paste.ubuntu.com/7004758/
<mgz> dstroppa: as a first check, you can run `godeps -u dependencies.tsv` using lp:godeps which will tell you about other goosey problems
<mgz> dstroppa: ugh, I can't actually remember what the cause of things like that is
<mgz> rogpeppe: ^if go build just dies with a kill signal, what's going on?
<mgz> OOM I think was one of them
<dstroppa> mgz: updated all dependencies, still same error
<dstroppa> I'm running in a vagrant box with 512MB
<mgz> ...it could be the OOM then
<mgz> give it another 512
<dstroppa> mgz: yup, it was OOM
<mgz> bot was down it should now be up again
<mgz> (if people have things they need to land)
<mgz> looked like a mongo wedge
<mgz> dstroppa: ace
<mgz> dstroppa: the other thing we should do today is land the storage branch
<dstroppa> mgz: cool
<mgz> it probably wants a bump in dependencies.tsv for the latest gojoyent, retesting, then we can go
<hazmat> ev, its not polished for end-users, entirely undocumented, and requiring some manual setup.. http://github.com/kapilt/juju-lxc  its what i'm using daily... the improvements will land into core though
<ev> hazmat: wooohoo!
<mattyw> rogpeppe, time for a quick question?
<rogpeppe> mattyw: sure
<mattyw> rogpeppe, my add/remove user branch - https://codereview.appspot.com/61620043/ - I hadn't actually checked that the caller had permission to add/remove the user (using a common.GetAuthFunc)
<mattyw> now that I am - what should the rules be? I'm tempted for now to just let everyone add/remove
<mattyw> (for now basically meaning until we start implementing roles in the next couple of weeks)
<rogpeppe> mattyw: i think that's fine for the time being - we don't have any roles yet
<mattyw> rogpeppe, cool! so I'll just always return true in my auth func
<rogpeppe> mattyw: seems fine (i think there's a helper function for that actually - it might be called AuthAlways or something)
<mattyw> rogpeppe, I'll take a look - thanks again
<dstroppa> mgz: storage branch updated, retested and ready to go
<mgz> dstroppa: then, set commit message and I can mark approved (or just use `bzr rv-submit` yourself)
<dstroppa> mgz: set a commit message, got an "unknown command" when running bzr rv-submit
<mgz> anyone know what "bad record MAC" is about as a failure on the bot?
<mgz> I didn't find an lp bug
<mgz> 's mongo related
<rogpeppe> mgz: i *think* that's a mongo bug
<rogpeppe> mgz: and might be fixed in the next mongo version
<mgz> rogpeppe: ta, I think I'll file a juju-core bug for refernce
<sinzui> rogpeppe, mgz, does juju reject unsigned image json? Can devs build their own os images, generate the streams, and juju will accept them?
<rogpeppe> sinzui: i'm not sure, but i think it should do
<rogpeppe> sinzui: but i'm not sure what we use for the root key
<rogpeppe> sinzui: for checking the sig validity
<mgz> sinzui: they can provide their own image and streams, we have places where they can set alternatives to streams.canonical.com
<sinzui> I think there is one implementation of simplestreams, so the behaviour of os images should match the tool behaviour
<rogpeppe> mgz: do you know how it verifies self-generated streams?
<sinzui> mgz, that is exactly what some canonical people are testing. They think they need sjson
<mgz> there's a difference between unsigned .json (which we just accept) and .sjson - I'm not how we'd verify self-signed .sjson
<rogpeppe> mgz: isn't that a security hole?
<mgz> not really, if you're uploading your own simplestreams data to a personal container in the cloud storage,
<rogpeppe> mgz: or... i suppose whether it's signed or not is encoded in whether the configured URL ends in ".sjson" or not
<mgz> you're just relying on the cloud and secure conections to make sure what you put there is what you end up using
<mgz> rogpeppe: it's a little more involved that that
<mgz> the code has a flag that enables a fallback url lookup if the .sjson at a given location doesn't exist
<mgz> which is not set in all cases
<rogpeppe> mgz: is that in the environ config ?
<mgz> so, it goes something like, .sjson at configured location, .json at configured location, .sjson at cloud default, .sjson at streams.canonical.com I believe
<mgz> ..but probably with even more steps
<rogpeppe> mgz: where does the "configured location" come from?
<rogpeppe> mgz: is it tools-metadata-url ?
<mgz> tools-metadata-url in environments.yaml for instance
<rogpeppe> mgz: ah, so we're rely on DNS being secure?
<rogpeppe> s/rely/relying/
<mgz> yeah, and https, and the cloud itself, if the user sets that as config
<sinzui> mgz, rogpeppe We allow people to setup their private clouds...they should know how to make their cloud secure
<rogpeppe> mgz, sinzui: i was actually thinking of the default case, not the custom-cloud case
<mgz> I would not swear by it, but the true default case shouldn't do the fallback to looking for .json in any of our base locations
<sinzui> own image in public cloud? I think that is push to bucket with acls for yourself and friends
<rogpeppe> mgz: ah, so the only way to have it actually secure is to use our default?
<mgz> I think so, I'm not sure how we'd add a new trusted signing key for self-signed simplestreams at present
<mgz> wallyworld may actually have a way though
<mgz> dstroppa: ah, you're back on
<mgz> dstroppa: you need to merge trunk to resolve conflicts
<dstroppa> mgz: doing it now
<mgz> dstroppa: one more thing, you're still using loggo from launchpad.net
<mgz> you need to switch to the github import
<dstroppa> mgz: I can see the github import http://bazaar.launchpad.net/~dstroppa/juju-core/joyent-provider-storage/view/head:/provider/joyent/provider.go
<mgz> dstroppa: oh, I probably forgot to pull gojoyent
<mgz> dstroppa: flagged for the bot to land
<dstroppa> mgz: cool
<mgz> dstroppa: you need to send a message to juju-dev mailing list telling everyone to get the gojoyent library as a new dep
<dstroppa> mgz: will do
<mgz> dstroppa: though, the bot hates me at the moment, so it may not land straight away
 * fwereade is going to be back for most of the evening, but needs to stop for a bit now; I have a couple of reviews up that I'd greatly appreciate opinions on
<rogpeppe> natefinch: ping
<natefinch> rogpeppe: pong
<rogpeppe> natefinch: i was looking at the replicaset tests, and it seems they assume that replSetGetStatus always returns the members in id order
<rogpeppe> natefinch: do you know that's guaranteed?
<natefinch> rogpeppe:  I don't remember
<rogpeppe> natefinch: i wonder if it might be worth sorting it just to make sure
<natefinch> rogpeppe: certainly couldn't hurt in the tests, and I don't think anywhere else relies on the order
<rogpeppe> natefinch: actually, looking at the mongo server code, it does seem to sort it
<rogpeppe> natefinch: but i agree, i won't do any harm
<rogpeppe> s/i wo/it wo/
<mattyw> fwereade, do you want to schedule a hangout to discuss the owner-tag juju status branch - or shall we just do it on irc?
<natefinch> rogpeppe: do you have some time to talk about ensure mongo server?  I'm kinda thrashing because I don't quite understand what I'm supposed to be writing.
<rogpeppe> natefinch: sure. give me a moment to make this test pass again and we'll chat
<natefinch> rogpeppe: cool
<rogpeppe> natefinch: https://plus.google.com/hangouts/_/calendar/am9obi5tZWluZWxAY2Fub25pY2FsLmNvbQ.mf0d8r5pfb44m16v9b2n5i29ig?authuser=1
<fwereade> mattyw, I think I'll be meeting with casey about charm store stuff tomorrow -- if you'll be there, can we maybe piggyback it on that?
<dstroppa> arosales: https://bugs.launchpad.net/juju-core/+bug/1285803
<_mup_> Bug #1285803: [Joyent Provider] metadata mismatch when testing again Joyent Public Cloud <juju-core:New> <https://launchpad.net/bugs/1285803>
<arosales> dstroppa: thanks. I'll confirm this is not the image or the stream data
<mgz> dstroppa: your added dependencies.tsv file has spaces rather than tabs, fix that and I can try landing again
<dstroppa> mgz: just pushed r1983
<mgz> dstroppa: reflagged
<sinzui> Hi devs, I see we are again announcing the juju-restore plugin. It says it restores a juju backup. How would someone make a backup? there is no juju-backup installed
<mgz> sinzui: juju-backup does *exist*...
<mgz> sinzui: where's your packaging branch live atm?
<sinzui> but no one added it to be installed. I see the restore is there
<sinzui> I can add that and james can pickup my changes
<mgz> that sounds like the right thing.
<sinzui> Do I want to do that now and delay the release?
<sinzui> well I have some release notes to write so as long and I an writing , I can let CI tell me it works
<mgz> I think so.
<mgz> *** Test killed: ran too long (10m0s).
<mgz> FAIL launchpad.net/juju-core/worker/upgrader 600.014s
<mgz> bot hates me, one more time as I go...
<rogpeppe> g'night all
<natefinch> g/night rogpeppe
<sinzui> hmm, since juju-backup is not a go plugin, installing it is more difficult than I imagined
<natefinch> sinzui: sorry, I actually haven't ever used juju plugins.
<sinzui> natefinch, np. I just assumed it was a go plugin like juju-restore and juju-metadata. The installation is simple but different from everything else in the rules file
<sinzui> I was stressing because I want this packaging change included in the build and test that just started
<ahasenack> marcoceppi: around?
<marcoceppi> ahasenack: otp
<ahasenack> ok
<ahasenack> marcoceppi: for posterity: http://pastebin.ubuntu.com/7006888/
<ahasenack>     def setup(self, timeout=600):
<ahasenack> (...)
<ahasenack>             with timeout(timeout):
<ahasenack> that can't work, right? :)
<thumper> fwereade: you up?
<thumper> ahasenack: no, I don't think so
<thumper> ahasenack: lookup confusion
<natefinch> thumper: he said he was going to be away in the afternoon and around in the evening.  It's evening there, but not sure exactly what hours he was going to be around
<thumper> natefinch: thanks
<thumper> I'm about to go mobile and head into town
<thumper> will work from there while the car gets serviced
<ahasenack> marcoceppi: fixed in 1.3.1, nm
<marcoceppi> ahasenack: yeah, that was patched really quickly
<ahasenack> marcoceppi: :)
<marcoceppi> unfortunately not before it was released :\
<thumper> fwereade: around now?
#juju-dev 2014-02-28
<hazmat> davecheney, false
<hazmat> tags are project specific
<hazmat> albeit guess work
<davecheney> hazmat: hmm, i found a way I can search across projects via tag
<davecheney> go to the main page of lp
<davecheney> search for your tag there
<davecheney> sort of works
<wallyworld_> projects can have official tags defined to remove the guesswork. you get auto completion and stuff like that then
<davecheney> i'm trying to build a report for PM who need to know how much work is left on a project
<davecheney> whenever I see them maintaing their own list in a google doc
<davecheney> I cry inside
<wallyworld_> wonder why they do that
<davecheney> launchpad is hard, let's go shopping
<wallyworld_> davecheney: launchpad is not that hard when a) you know how to use it b) you use it for which it was intended
<davecheney> sorry, i missed the <sarcasm /> tag
<wallyworld_> ah :-)
<wallyworld_> there's also a Canonical developed project tracking tool they could have used
<wallyworld_> can't recall the url right now
<wallyworld_> thumper: do you know why it's proposed to change managerConfig from a struct to a map?
<thumper> yes
<thumper> I'll review that one
<thumper> it is part of the policy stuff
<thumper> a pre-req refactoring to make it easier
<wallyworld_> ok
<thumper> will also be using it for the fast-lxc clone mechanism
<wallyworld_> thumper: also, here's a fix for local provider upgrader bounce https://codereview.appspot.com/69690043
<thumper> also, side note
<thumper> I have a physio appt at 2pm
<thumper> may not be back for the standup
<wallyworld_> ok, we can delay it
<thumper> either that or do it without me :-)
 * thumper doesn't feel that special
<thumper> we can see though
<wallyworld_> could do, we did it last week
<wallyworld_> just didn't want you to miss out :-)
<thumper> :)
<thumper> the description on that branch doesn't indiate that it fixes the local provider upgrade stuff
<wallyworld_> thumper: cause it describes the root cause issue
<thumper> kk
<wallyworld_> which is DesiredTools() failed
<wallyworld_> may have had more impact that just local provider
<wallyworld_> i tested local provider by hand and it fixed the issue
<wallyworld_> i want to run a 1.16 to 1.18 upgrade test also to check the lock dir and system key stuff gets sorted out properly
<thumper> kk
<wallyworld_> thumper: do you think we can finally re-purpose --verbose for 1.18? or wait till 1.20? it's been deprecated for ages now. needs to happen before 2.0 though.
<thumper> a problem we have is that we don't get verbose feedback from the api...
<thumper> general output would be "calling api foo"
<thumper> some result
<thumper> not sure how good verbose will be there...
<thumper> however, I think we should change it RSN
<wallyworld_> we can use to log request response and stuff like that perhaps
<wallyworld_> we can think of something to use it for
<wallyworld_> but yeah, the change needs to happen
<wallyworld_> we can always improve the verbose output
<wallyworld_> over time
<wallyworld_> sigh, bot hung again. stabby, stabby
<wallyworld_> wow, bot is soooo slooooow today
<axw> wallyworld_: is there any reason not to include *state.State in the upgrade Context for state servers?
<axw> (it would be nil for non-state servers)
<wallyworld_> um
<wallyworld_> guess not
<wallyworld_> i was thinking it best to go via api
<axw> the reason I ask is if there's not one, I have to add an API that will only ever be used for upgrades
<axw> (updating syslog port)
<wallyworld_> i see
<wallyworld_> there's pros and cons both ways i guess
<axw> I
<wallyworld_> i think it could work out ok to do it
<axw> I will propose adding it for now, we can reassess later if it's a bad idea
<axw> wallyworld_: technically you can get it already through the agent.Config... but it'd probably be better to not open again
<wallyworld_> yeah, prefer not to open a 2nd one
<wallyworld_> axw: tim will be late for standup - physio. he said we could do it without him but i don't mind waiting till he gets back
<axw> wallyworld_: no worries, let's wait
<waigani_> _thumper_, axw, wallyworld_ standup?
<axw> waigani_: waiting for thumper to return
<waigani_> ah sorry just saw above
 * _thumper_ is back
<axw> wallyworld_, waigani_ let's do it
<thumper> davecheney: I managed to run gocheck tests with gccgo... what is the problem you are seeing?
 * thumper wanders into the kitchen to make that coffee now that the machine is hot
<davecheney> thumper: last time I tried they don't pass on any arch
 * davecheney goes to find the bug report
<davecheney> https://bugs.launchpad.net/gocheck/+bug/1250253
<_mup_> Bug #1250253: many tests fail with gccgo <gccgo> <ppc64el> <Gocheck:New> <juju-core:Triaged by dave-cheney> <https://launchpad.net/bugs/1250253>
<davecheney> thumper: gocheck tests don't appear to pass with golang-go either
<thumper> ah...
 * thumper sadface
<davecheney> it fails really badly under gccgo
<davecheney> because gccgo has a different format for stack traces
 * thumper is looking at bug 1276909
<_mup_> Bug #1276909: error detecting hardware characteristics: unrecognised architecture: aarch64 <arm64> <hs-arm64> <patch> <juju-core:Triaged> <juju-core (Ubuntu):Triaged> <https://launchpad.net/bugs/1276909>
<thumper> davecheney: yeah I noticed that too
<thumper> wallyworld_: any idea why hpcloud metadata simplestream search is just "amd64" and "arm" while ec2 is "amd64", "i386" and "arm" ?
<wallyworld_> thumper: i'd guess that hp cloud doesn't have i386 images?
<thumper> any idea if it has arm64 images?
<wallyworld_> no idea
<thumper> wallyworld_: if we searched for them and they aren
 * thumper sighs
<thumper> and they aren't there, should be fine though right?
<wallyworld_> yeah, will be fine
<davecheney> wallyworld_: can you do something like nova list-images [sic] against HP cloud ?
<wallyworld_> i think so yes
<wallyworld_> let me check
<wallyworld_> i only see 64 bit
<thumper> wallyworld_: I'm just applying patches from the bug mentioned above
<thumper> and I hit my repetition threshold
<thumper> was wondering if we could refactor and combine known architectures
<wallyworld_> sure, whatever works :-)
<wallyworld_> not all providers support all arches
<thumper> sure
<thumper> but we can ask for what we know about though right?
<wallyworld_> i would think so
<davecheney> ok      launchpad.net/juju-core/cmd/jujud       578.049s
<davecheney> mmm, speedy
<davecheney> 12 more seconds and test watchdog would have nixed it
<wallyworld_> axw__: i think i might need a state reference in the upgrade context also - well, it will make it easier anyway
<axw__> wallyworld_: I started doing it, but it's a pain in the arse to to get the state.State object where the upgrader is created...
<axw__> I can go back to it if you need it though
<wallyworld_> hmmmm
<wallyworld_> what i need to do is delete some obsolete config entries
<wallyworld_> and EnvironmentSet() is only on clients
<axw> wallyworld_: ok, I will just do it
<wallyworld_> but only when on a state server, right?
<axw> I figured I'd leave it till it was needed by someone else, so there we go :)
<axw> yep
<wallyworld_> i wonder if it really is the right thing to do
<thumper> wallyworld_: bot still fubared?
<wallyworld_> or if we should just do it via an api endpoint
<wallyworld_> yep :-(
 * thumper sighs
<wallyworld_> it just keeps restarting my mp
<axw> wallyworld_: seems to me that the state server shouldn't need to go through the API.
<wallyworld_> cause it can't get enough cpu cycles to run the tests in time
<davecheney> thumper: did errgo move to juju/errgo ?
<wallyworld_> axw: yeah, i can see that argument, although there are worker on the state server that do go via the api
<davecheney> or am i smoking cheap crack ?
<thumper> davecheney: no, juju/errgo is rog's one
<thumper> davecheney: errgo/errgo will die
<wallyworld_> i think all workers should, but for one off upgrade tasks...
<davecheney> thumper: i noticed that some packages in juju-core still pull the latter
<thumper> aye, they should change
<davecheney> m'kay
<davecheney> just fiddling with my spreadsheet
<thumper> davecheney: yes it does give me hives
<davecheney> well, i'm going to double down and s/arm64/ppc64/
<thumper> davecheney: thought you might, but shouldn't it be ppc64le?
<axw> el? (to match dpkg arch?)
<thumper> yeah
<davecheney> thumper: it's ppc64 for the same reason that it's arm64, not aarch64
<davecheney> i really hope there is no requirement to handle the aliasing
<davecheney> thumper: oh man, I think this is going to be harder
<davecheney> actually no
<davecheney> ignore
<davecheney> oh, who was saying that they couldn't bootstrap 386 images on hp cloud
<davecheney> https://codereview.appspot.com/69850043/diff/1/provider/openstack/provider.go?column_width=80
<davecheney> ^ there is your answer
<axw_> wallyworld_: sorry, took me a little while to figure out a cleanish way to do it, CL incoming now
<wallyworld_> axw_: awesome, thanks. i've got my branch ready to go as soon as your lands
<thumper> is anything landing?
<wallyworld_> thumper: i've upped the timeout to 45 minutes to see if that is enough
<thumper> kk
<wallyworld_> axw_: you you have the shiteveld link?
<axw_> wallyworld_: still uploading, will let you know
<wallyworld_> ok
<axw_> wallyworld_: https://codereview.appspot.com/69890043/
<wallyworld_> looking
<davecheney> surely this one is fixed https://bugs.launchpad.net/juju-core/+bug/1240260
<_mup_> Bug #1240260: juju bootstrap does not honor https_proxy in environment when fetching tools <amd64> <apport-bug> <cts-cloud-review> <saucy> <juju-core:Triaged> <juju-core (Ubuntu):Triaged> <https://launchpad.net/bugs/1240260>
<wallyworld_> davecheney: i'm pretty sure that's now fixed with tim's recent proxy changes
<wallyworld_> axw_: reviewed, but there are missing tests
<axw_> okey dokey
<wallyworld_> i'm doing the same get config, set config dance in my branch also
<davecheney> wallyworld_: wanna close it and we'll pretend it never happened
<axw_> ok
<axw_> (to ian)
<wallyworld_> davecheney: i think it can be closed yeah
<axw_> wallyworld_: I need to have lunch, so won't have it done for a little while yet
<wallyworld_> no proble, i can still merge your branch
<wallyworld_> problem
<axw_> wallyworld_: what do you mean "machine agent upgrade in cmd/jujud/upgrade_test.go" ?
<axw_> you mean something that tests whether state.State is available?
<wallyworld_> axw_: in cmd.jujud, there's tests which set up an env, start machine agent, and check that the upgrades are done
<wallyworld_> you just need to add somes lines to (wallyworld checks method name)
<wallyworld_> assertStateServerUpgrades
<axw_> ah I see
<axw_> thanks
<wallyworld_> np. also a unit test for the rsyslog upgrade method itself
<wallyworld_> in rsyslogupgrade_test.go
<axw_> yep got it
<axw_> wallyworld_: I didn't actually record a.st, so ... bear that in mind when you merge :)
<axw_> I just live tested and it blew up
<wallyworld_> i'm just running the test now :-)
<axw_> so, these upgrade tests are going to install rsyslog-gnutls on the test machine aren't they... I'd better fix that
<wallyworld_> um yeah :-)
<wallyworld_> i think we have stubs for apt for testing
<wallyworld_> somehwere in utils
<axw_> yep
 * axw_ crosses fingers and restarts
<axw> oh joy, compiz is crashing
<wallyworld_> \o/
<rogpeppe> mornin' all
<fwereade> rogpeppe, heyhey
<rogpeppe> fwereade: hiya
<fwereade> rogpeppe, guess what I forgot to do in the zip package?
<rogpeppe> fwereade: what was that then?
<fwereade> rogpeppe, close the files I write to :/
<rogpeppe> fwereade: doh!
 * rogpeppe feels stupid for missing that
<fwereade> rogpeppe, I was totally baffled by ETXTBSY for a disturbingly long time
<rogpeppe> fwereade: good thing you got that really
<rogpeppe> fwereade: otherwise we'd just have had a leak
<fwereade> rogpeppe, yeah, absolutely
<dimitern> fwereade, rogpeppe, wallyworld_ , standup?
<ev_> hi guys. Anyone know who's responsible for uploading the partner os images to HP Cloud's glance?
<ev_> they're still using Ubuntu 12.04.2 on region-a.geo-1
<fwereade> ev_, I think you'll want to talk to utlemming about that
<ev_> thanks
<dimitern> fwereade, i've added a few bits, but all in all the document lgtm
<fwereade> dimitern, great, tyvm
<cjohnston> rogpeppe: any updates on the api watcher issue at all?
<rogpeppe> cjohnston: i'm sorry, i've been trying to make progress on HA, so haven't been spending much time on bugs recently.
<cjohnston> ack
<cjohnston> is that node 0 HA?
<rogpeppe> cjohnston: yes
<cjohnston> very cool
<rogpeppe> cjohnston: hopefully :-)
<mattyw> is anyone available to help me work out what's going wrong with one of my cmd/juju tests?
<rogpeppe> lunch
<rogpeppe> mattyw: will have a look later if you haven't solved the issue
<mattyw> rogpeppe, if you could spare 10 minutes I'd appreciate it - I'm sure I'm being an idiot somewhere - but I'd love to know where :)
<mattyw> rogpeppe, I have a meeting in 30 mins so there's no hurry - enjoy your lunch
<sinzui> mgz, rogpeppe Do either of you have a few minutes to review https://codereview.appspot.com/70100043
<adeuring> TheMue: could you please have a look here: https://codereview.appspot.com/68000045 ?
<TheMue> adeuring: yep *click*
<mgz> sinzui: sure thing
<mgz> sinzui: lgtm
<sinzui> oh bugger. mgz, I see this MP that makes me think I should wait an hour for CI to bless. Is lander stuck? https://code.launchpad.net/~wallyworld/juju-core/unitupgrader-desired-tools/+merge/208710
<mgz> sinzui: yeah, the bot is kinda screwed
<mgz> I can, if needed, manually land things
<mgz> it's had load of >3 all day, for no obvious reason
<sinzui> mgz, I don't want to rush things. I am assuming that CI will bless the revision if it merges.
<mgz> pretty sure nothing will land unless I bash something hard
<mgz> the current one has been going... very slowly... since 9:30 this morning
<sinzui> wow
<sinzui> mgz, this is canonistack?
<mgz> yep.
<mgz> lcy02
<sinzui> It is dying.
<jcastro> Do we have docs for writing your own provider?
<sinzui> We just moved juju-ci off of it
<mgz> I've not seen any "this is totally screwed" annoncement yet, but it does seem that way
<sinzui> mgz ^ I recommend setting up the lander in another cloud.
<mgz> jcastro: we have a branch from fwereade with docs and a template provider
<mgz> it's somewhat out of date with trunk, but is a good start for a capable coder
<fwereade> jcastro, mgz: sorry, I never actually landed that, roger had some good comments that I never addressed
<sinzui> mgz We saw performance degradation and nova lost two machines, and was shuting other down
<fwereade> jcastro, mgz: it's what the joyent provider started out as
<jcastro> ok so for the docs I'll just say "contact us" for now
<mgz> sinzui: that's more than an end-of-fraiday task, and jam wants to move us to a jenkins thing anyway
<mgz> jcastro: I can forward you a mail I sent with the details
<jcastro> I am renaming the null->manual in the docs, and I wanted to say something like "obviouslly adding machines by hand is not ideal, if you're a provider and want to natively support juju go here."
<mgz> ...actually, you were probably cced on it
<sinzui> mgz, understood. We have stood up enough CIs that it is a could of hours for us to move
<jcastro> ok, I just wanted something for 1.18, this is Good Enough
<jcastro> we should at some point have a proper page though
<mgz> jcastro: yeah, see the "Juju on Digital Ocean" mail from 2014-02-04
 * jcastro nods
<mgz> links william's branch
<TheMue> adeuring: done
<adeuring> Thethanks!
<adeuring> TheMue: Thanks
 * rogpeppe is back after a rather extended lunchtime think'n'stomp.
<natefinch> Damn, I bought an external battery for my laptop for the flight, and none of the adapters fits my plug :/
<rogpeppe> natefinch: something that would have been worth verifying in advance, i guess :-)
<rogpeppe> mattyw: what's the problem, then?
<natefinch> rogpeppe: heh yeah.  I guess I'll have to run to radioshack and see if they have an adapter from the "big" dell plug to the mini one my laptop has
<mattyw> rogpeppe, quick hangout?
<rogpeppe> mattyw: sure
<natefinch> man, I wish there was a way to expose functionality in *other* packages during test.   Can't tell you how much easier that would make so many tests, and how many "this is only public for testing, please don't change" we could remove.
<natefinch> rogpeppe: is there a trick we're missing to do this?  Sort of a way for a package to say "hey, here's some stuff you might want to mock out during tests" that other packages could then twiddle with, but only during testing?
<rogpeppe> natefinch: nope
<rogpeppe> fwereade: ping
<natefinch> rogpeppe: dang.  I thought that was the case, but was hoping I was wrong
<fwereade> rogpeppe, pong
<rogpeppe> fwereade: i was just in a call with mattyw, and thought i should run an idea past you
<rogpeppe> fwereade: matty's problem was that in his Cmd implementation, he was doing a store.ReadInfo(c.EnvName)
<rogpeppe> fwereade: but c.EnvName can be blank
<rogpeppe> fwereade: because it can be specified as a default in environments.yaml, which isn't read by then
<rogpeppe> fwereade: so my suggestion was that we can make EnvCommandBase read environments.yaml in that case, so c.EnvName will always be non-empty when possible
<rogpeppe> fwereade: which means we could lose the "" special case in a fair few places
<rogpeppe> fwereade: and it means it's easier for people to write plugins too (and easier to move away from environments.yaml when the time comes)
<fwereade> rogpeppe, don't we have a standard set of fallbacks? ie the JUJU_ENV, wherever juju switch stores, etc
<fwereade> rogpeppe, but yeah, it certainly seems like a good idea to do all that logic OAOO and expose it nicely for these situations
<rogpeppe> fwereade: yeah, most of them are already dealt with by EnvCommandBase
<fwereade> rogpeppe, and start requiring actual env names at all lower levels
<rogpeppe> fwereade: except the default-from-environments.yaml case
<fwereade> rogpeppe, cool, if it's just a matter of extracting a method from there then all the better
<fwereade> rogpeppe, bah
<fwereade> rogpeppe, probably still worth the ickiness of reading envs.yaml twice to put that logic in one place and drop the ""->default stuff inside environs
<rogpeppe> fwereade: that was my thought too
<fwereade> rogpeppe, done and done, then :)
<rogpeppe> fwereade: i think the best thing is just to put the logic inside getDefaultEnvironment, and possibly make it ignore any error if it fails to read the environments.yaml file.
<rogpeppe> fwereade: although the latter is more arguable
<rogpeppe> fwereade: but AFAICS the worst that can happen is that we get an empty default
<fwereade> rogpeppe, yeah, "no environment specified" doesn't seem unreasonable
<fwereade> rogpeppe, I guess we ultimately want to fall back to "the only jenv that exists" if *nothing* else is specified (and there is only one)
<rogpeppe> fwereade: i'm not sure about that
<rogpeppe> fwereade: i think juju switch works pretty well in general
<rogpeppe> fwereade: (much as i wasn't keen on the idea to start with :-])
<fwereade> rogpeppe, eh, it's arguable I guess
<fwereade> rogpeppe, putting the existing logic in one place is enough of a win for me :)
<rogpeppe> fwereade: if i've just deleted an environment, i don't really want it to suddenly switch to another environment just because it's the only one left
<rogpeppe> fwereade: yeah
<fwereade> rogpeppe, yeah, fair point -- you'd probably have  that earlier env switched in, but I agree you might not, and the impact of a surprising change could be significant
<rogpeppe> fwereade: actually, a possibly better idea is to change EnvName to be a method that returns (string, error)
<fwereade> rogpeppe, +1
<rogpeppe> fwereade: it's more invasive, unfortunatly
<rogpeppe> fwereade: but probably worth it
<rogpeppe> mattyw: could you do that, please?
<rogpeppe> fwereade: actually, another, possibly slightly less invasive option is to add an Init method to EnvCommandBase
<rogpeppe> fwereade: and leave the EnvName field as it is
<rogpeppe> fwereade: that actually feels more in keeping with the other command stuff
<rogpeppe> mattyw: pending fwereade's reply, i think that's a nicer option
<rogpeppe> fwereade: one other thing: there's an import cycle if EnvCommandBase calls environs, because environs indirectly uses juju-core/cmd
<rogpeppe> fwereade: cmd has always seemed to me to be a somewhat dubious place to have EnvCommandBase, tbh
<rogpeppe> fwereade: i think maybe it could live in its own package, along with other environment-related cmd stuff
<fwereade> rogpeppe, +1 to that as well, thanks
<rogpeppe> fwereade: like... wtf is IsMachineOrNewContainer doing in cmd ?
<fwereade> rogpeppe, sounds like "loitering with intent" to me
<rogpeppe> fwereade: i gave it a sharp word
<fwereade> rogpeppe, IIRC is is subtly misnamed as well
<fwereade> rogpeppe, ah no maybe it's accurately named but insane
<fwereade> rogpeppe, we ought to be either detecting an explicit machine name or dispatching a placement directive to a (pseudo-)provider
<sinzui> I suspect that the bug fix that wallyworld_ has for machine agents is broader that local-provider. my 1.17.4 release from trusty cannot bootstrap precise
<rogpeppe> fwereade: anyway, it's only used in two places, and should probably be in cmd/juju until more widespread
<rogpeppe> fwereade: how about juju-core/cmd/juju/envcmd as a package name for EnvCommandBase?
<rogpeppe> fwereade: cmd/envcmd is also a possibility, i guess
<dimitern> i'd appreciate if someone takes a look at my agent conf 1.18 CL https://codereview.appspot.com/70010045
<dimitern> it was truly painful to merge all trunk changes
<rogpeppe> fwereade: except that would pollute the cmd/* name space
<rogpeppe> dimitern: you've still got some .THIS files in there
<dimitern> rogpeppe, man! seriously.. :/ I'll repropose
<dimitern> it's good they're only 2 and both are now gone
<dimitern> rogpeppe, updated
<rogpeppe> dimitern: thanks
<natefinch> rogpeppe, mgz, fwereade: anyone know why gocheck would suddenly not be able to create temporary directories?  Panic: Couldn't create temporary directory /tmp/gocheck-5577006791947779410/1: mkdir /tmp/gocheck-5577006791947779410/1: no such file or directory (PC=0x413FC6)
<rogpeppe> natefinch: how many directories have you got in /tmp?
<natefinch> rogpeppe: one
<rogpeppe> natefinch: does this happen every time?
<mgz> mystery
<natefinch> rogpeppe: currently, yes.  Let me try removing this mkdir and see if another one elsewhere succeeds, maybe I'm hitting some weird race condition somehow
<natefinch> rogpeppe: it seems to not fail in other packages I test
<natefinch> rogpeppe: nevermind, I see what I did... misunderstanding of what os.TempDir returns....  looks like I was actually deleting /tmp in one of my tests
<rogpeppe> natefinch: oops :-
<rogpeppe> )
<rogpeppe> natefinch: good thing it wasn't $HOME, eh?
<natefinch> rogpeppe: ahh yeah.  I've done that before too, though not in code, just by being in the wrong place when I did rm -rf *
<natefinch> ....and this is why man invented offsite backups.
<sinzui> natefinch, when I see this
<sinzui> Starting MongoDB server (juju-db)
<sinzui> is this mongodb-server and juju-mongodb?
<natefinch> sinzui: that's the mongod upstart service that juju creates when it installs itself.
<sinzui> natefinch, and since mongodb-server is the only thing juju knows how to install, we know it is mongodb-server
<sinzui> natefinch, fwereade, jam1, This bug aborted the 1.17.4 release. https://bugs.launchpad.net/juju-core/+bug/1286279
<_mup_> Bug #1286279: juju 1.17.4 trusty client cannot bootstrap 1.17.x precise <precise> <trusty> <juju-core:Triaged> <https://launchpad.net/bugs/1286279>
 * sinzui needs to think about how to not let 1.17.4 get into the hands of ubuntu trusty users
 * rogpeppe is done for the week
<rogpeppe> g'night all
<mgz> night rog
<mgz> see you next week!
<rogpeppe> mgz: yeah!
<natefinch> rogpeppe: see you next week :)
<sinzui> natefinch, Do you have any insights into this bug. https://bugs.launchpad.net/juju-core/+bug/1286279
<_mup_> Bug #1286279: juju-mongodb breaks 1.17.4 trusty client bootstrap in CPC <bootstrap> <mongodb> <precise> <regression> <trusty> <juju-core:Triaged> <https://launchpad.net/bugs/1286279>
#juju-dev 2014-03-01
<hazmat> anyone around?
 * hazmat goes src diving
#juju-dev 2015-02-23
<waigani> thumper: http://reviews.vapour.ws/r/955/, thanks
<katco> wallyworld_: fyi i plan on attending the stand up tonight
<wallyworld_> wot? it's the weekend :-)
<katco> wallyworld_: WHAT! no one told me! ;p
<thumper> anastasiamac_: review done on your mega branch
<thumper> anastasiamac_: I didn't go through all of it as I wanted some response on what I had suggested first
<axw> katco: we lost you
<katco> axw: doh
<anastasiamac_> thumper: it's amazing! thnx :D i wasn't expecting u to have a chance to look but really appreciate u did!
<anastasiamac_> thumper: sendError() on httpHandler only takes an error message
<thumper> I know
<anastasiamac_> thumper: i need both coe and message :D hence an additional sendError method that taeks and error instead of string
<thumper> anastasiamac_: read my answer again, and if you still have questions, we should talk
<thumper> but OTP right now
<axw> wallyworld_: I forget if I already sent you this link before, this is my WIP for the storage provisioner: https://github.com/axw/juju/tree/worker-storage
<wallyworld_> thanks, will look after i finishing looking at the storage lifecycle branch
<axw> wallyworld_: thanks. it doesn't need review, just an FYI
<wallyworld_> kk
<wallyworld_> axw: in type VolumeParams struct, should the Attachment field be of type *VolumeAttachmentParams rather than *AttachmentParams?
<axw> wallyworld_: yeah, I think so
<wallyworld_> ta, will fix
<axw> I was thinking not before, but there may be volume-specific attachment params
<wallyworld_> yeah
<wallyworld_> axw: the path == "" check in rootfs createfilesystem - you say that the path value in FilesystemAttachmentParams should be set by the caller - that would imply it's up to the storage provisioner to set it. But the storage provisioner would then need to keep track of the ConfigStorageDir param. It is not easier to keep the code as is and let rootfs provider use a default path?
<axw> wallyworld_: hold up, need to refresh my memory
<wallyworld_> http://reviews.vapour.ws/r/956/
<axw> wallyworld_: do you mean location==""?
<wallyworld_> axw: i've change location to path
<axw> wallyworld_: hmmm. so, this is a provider-independent thing. I think it's unnecessarily onerous to make it the responsibility of the provider to come up with a unique path to mount at
<axw> wallyworld_: I think I'
<axw> d prefer if we just had the storage provider set location to /var/lib/juju/storage/<source>/tag
<wallyworld_> axw: that's what storageDir is for
<wallyworld_> it's the only thing it is used for atm
<wallyworld_> i guess it can be the absoluet tpath
<wallyworld_> but then we'd not need the attachment params path attr
<axw> wallyworld_: I don't see why the provisioner having to track ConfigStorageDir is a problem. in fact, it doesn't track it, it specifies it based on the agent's data-dir
<axw> wallyworld_: yes we do, because the user can specify path
<axw> wallyworld_: this storage-dir path should only be used if the user didn't specify one
<axw> s/user/charm author/
<wallyworld_> right, ok. then perhaps the config attr should be called DefaultStorageDir
<axw> wallyworld_: actually I don't think that config attr should come into it
<axw> wallyworld_: that directory was meant to be for storing info about volumes and filesystems
<axw> wallyworld_: not for where the mount points end up
<axw> wallyworld_: e.g. in the loop provider, we should create the file in ConfigStorageDir, but then mount it at "location"
<wallyworld_> ok, so we need to ensure then that Path is always set, and the provider needs to choose a sensible location if the user doesn't specify one
<wallyworld_> provisioner
<axw> right
<wallyworld_> np. the way i've had it till now is how we had id in the feature branch
<wallyworld_> but that was all done for the demo
<menn0> axw: hiya. in environs/cloudinit/cloudinit.go:AddAptCommands, do you know why required packages aren't being installed when enable-os-refresh-update is false
<menn0> ?
<menn0> axw: it means that rsyslogd is completely broken when enable-os-refresh-update is turned off.
<axw> menn0: I think it's because some of the packages may not be found, because they're in cloud-tools
<menn0> axw: i feared that there might be some complication like that.
<axw> menn0: rsyslogd-gnutls should always be found I think ... we could be more selective there
<menn0> axw: yeah rsyslog-gnutls is needed in order for logging to work
<axw> wallyworld_: were there specific tests you found missing in my branch, apart from the existing tests you mentioned?
<axw> wallyworld_: I've identified a problem with the RemoteStorageInstance test, and I ended up removing that method
<axw> since I don't think it should be possible to remove a storage instance directly, only destroy & remove attachments which will do the job
<wallyworld_> axw: mainly just tests to check that the business logic rules that cause the txns to retry when things are done concurrently
<axw> wallyworld_: ok
<wallyworld_> do you know the bits i mean?
<wallyworld_> around checking for attachment count > 0 (or = 0) etc
<wallyworld_> can't recall specifics
<axw> wallyworld_: yup
<wallyworld_> menn0: if you set refresh to false, you are promising to juju that your image has everything needed
<wallyworld_> that's why it's true by default
<menn0> wallyworld_: i'm doing scale tests with just the ubuntu charm so I figured it would be safe to turn off to speed things up
<menn0> wallyworld_: i'll turn it back on for now
<wallyworld_> ah, i see
<wallyworld_> menn0: what series are you using? precise? trusty?
<menn0> wallyworld_: this is trusty on EC2
<wallyworld_> hmmm, i would have hoped trusty would be ok with false
<wallyworld_> :-(
<menn0> wallyworld_: i'm not convinced the logic in juju is quite right. as axw also indicates, there are probably some package that should always get installed even if an apt-get update isn't being done.
<wallyworld_> yeah, that is true
<wallyworld_> it's a blunt instrument right at the moment
<axw> wallyworld_: most of these tests can't be done concurrently, because of lack of support for shared storage. e.g. in theory you could add unit, then concurrently add another unit and remove the first one's attachment, ensuring the instance isn't removed
<axw> but we can't do the in theory bit yet
<axw> I'll do what I can, but I don't think it's much
<wallyworld_> ok, just wanted to be really sure that if itwere possible to test the bad cases, we could
<wallyworld_> axw: there's 2 choices with the Path passed to rootfs provider already existing - 1. be really paranoid and assume that another storage is already using that path and return an error (will revisit later when shared storage supported), or 2. see if dir is empty and return an error if not
<wallyworld_> or 3. - something else?
<wallyworld_> eg just let it slide, but i don't think we should do that
<axw> wallyworld_: we should be guaranteeing #1 is not a possibility, I think
<axw> in which case, #2
<wallyworld_> axw: that's the provisioner's job yeah
<wallyworld_> hence i was also leaning to#2
<axw> wallyworld_: partially, we also need to prevent multiple storage instances with the same path
<axw> storage attachments*
<axw> i.e. explicitly specified path in the charm metadata
<wallyworld_> yes, but not inside rootfs
<axw> yep
<axw> I mean at a level higher than the provisioner, and also in the provisioner
<wallyworld_> yeah
<wallyworld_> i'll add the empty check to rootfs
<wallyworld_> axw: you going to land the disktag rename pr?
<axw> wallyworld_: I'll do it later, I'd like to get the state one fixed first
<wallyworld_> ok
<axw> wallyworld_: it's just a sed to fix up
<wallyworld_> my rootfs one depends on it also, but it can wait
<axw> wallyworld_: it depends on my branch?
<axw> wallyworld_: can you just land using DiskTag, and I'll fix up later?
<wallyworld_> axw: i added filesystemtag on top of your volumetag branch in juju/names
<axw> ah, right
<axw> wallyworld_: I'll land it now then
<wallyworld_> it's no biggies, i can wait
<wallyworld_> i'm still fixing the rootfs branch
<axw> wallyworld_: merged
<wallyworld_> axw: awesome, ty
<wallyworld_> axw: http://reviews.vapour.ws/r/956/ has been updated; once you are free from your other stuff, would be great if you could look. i have to duck out to do school pickup, so bbiab
<axw> wallyworld_: thanks, just pushing changes to http://reviews.vapour.ws/r/969/ too
<wallyworld_> ok, will look as soon as i'm back
<jam> thumper: did you manage to get the rework from executive summary through the rest of the JES CLI document?
<thumper> jam: yes
 * thumper shouldn't be here
<axw> wallyworld_: ;) I can rename it to "TestCDSIRSARI" ? ;)
<wallyworld_> yeah, why not :-)   .... kidding :-)
<dimitern> hey wallyworld_, thanks for that cloud-image-utils fix for precise
<wallyworld_> dimitern: hi there, and thanks for landing
<wallyworld_> dimitern: did you see the little govet issue in provisioner.gp?
<dimitern> wallyworld_, np
<dimitern> wallyworld_, mm no?
<wallyworld_> checking: go vet ...
<wallyworld_> apiserver/provisioner/provisioner.go:1028: arg addr for printf verb %q of wrong type: *github.com/juju/juju/state.IPAddress
<wallyworld_> was introduced yesterday i think
<dimitern> wallyworld_, cheers, I'll have a look
<wallyworld_> there's about 6 of them
<jam> wallyworld_: sabdfl just gave a +1 on storage CLI
<jam> and liked your layout
<wallyworld_> i hope we can release 1.22 finally :-)
<wallyworld_> jam: that's awesome news, ty
<wallyworld_> none of us liked the CLI n the spec
<jam> he really liked using the "juju status --help" syntax to understand how it all looks
<wallyworld_> yeah, that approach was done with the juju metadata stuff for tools and images
<jam> wallyworld_: can you do the edits to the actual Storage Spec ?
<wallyworld_> jam: yep, can do, just need to check i have dit permissions
<wallyworld_> edit
<jam> I think I gave you edit for the last round
<wallyworld_> yep, just checked
<dimitern> wallyworld_, where have you seen these go vet warnings? I've run go vet ./... on trunk now and 99% of what I get is "using unkeyed fields"
<anastasiamac> jam, wallyworld_: thnx for nice storage CLI approval :D
<wallyworld_> dimitern: i basically saw it when i pushed my branch, after rebasing. it is a legit error - %q expects a string
<jam> anastasiamac: wallyworld_: thanks for a nice proposal :)
<dimitern> wallyworld_, and in that case you've mentioned "%q" for a *state.IPAddress is fine, because it has String() method
<anastasiamac> jam: wallyworld_and axw proposed:D i just had fun with 3 level commands :)
<dimitern> so it's not a string but it's a Stringer
<wallyworld_> dimitern: so, it's the pre push hook that is invoking go vet - perhaps there's a warning level that's different?
<dimitern> wallyworld_, I'm not sure I have that pre-push hook configured locally - what should I do?
<wallyworld_> dimitern: the pre-push hook should be in VCS
<wallyworld_> in the scripts dir
<dimitern> wallyworld_, ok, but do you enabled it somehow?
<dimitern> enable*
<axw> anastasiamac: cool :)
<jam> dimitern: you have to edit .git/config
<wallyworld_> yeah, i can't remember exactly - it should be on the contributing page
<anastasiamac> wallyworld_: u know how i could not get my PR to have RB request?
<dimitern> jam, wallyworld_ , ok, will do
<anastasiamac> wallyworld_: and i had to resolve conflicts and re-propose?
<wallyworld_> which branch?
<anastasiamac> wallyworld_: well, i have just pushed to the same PR and found that there are conflicts again... The RB is not updated tho :(
<anastasiamac> wallyworld_: block-cmd-update...
<wallyworld_> 967?
<anastasiamac> wallyworld_: https://github.com/juju/juju/pull/1638
<anastasiamac> yes
<wallyworld_> if rb isnot updating, let eric know and he might be able to help fix it
<anastasiamac> wallyworld_: and btw, u r no longer on PM
<wallyworld_> i am on free node
<wallyworld_> i can also see channels on canonical server
<anastasiamac> wallyworld_: couple of minutes ago, i was told u were not ;D
<axw> jam: thanks for fixing my blunder in liveSource
<wallyworld_> anastasiamac: go figure, i have no idea wtf is happening with my stupid network
<anastasiamac> wallyworld_: u r putting it under a lot of pressure? :D
<wallyworld_> not that i know of :-)
<wallyworld_> anastasiamac: so i'd fix your merge conflicts and repush to GH and see if that then allows rb to updates
<anastasiamac> wallyworld_: thnx :D will try, just one more push... :D
<jam> menn0: scale testing sometime ?
<TheMue> morning
<menn0> jam: i've been doing exactly that
<jam> menn0: k, I don't think I'd seen anything back from you, so just figured I'd give you a poke and see how its goin
<menn0> jam: i
<menn0> jam: i was going to contact you when I had some numbers. I have numbers for the logging to mongodb case but logging via rsyslog has been giving me problems.
* ChanServ changed the topic of #juju-dev to: https://juju.ubuntu.com | On-call reviewer: see calendar | Open critical bugs: none
<perrito666> restore is finally landed
 * perrito666 cries
<dimitern> perrito666, \o/
<perrito666> now its no longer just my problem :p
<axw> perrito666: epic :)
<anastasiamac> dimitern: o/
<dimitern> anastasiamac, hey there
<anastasiamac> dimitern: got trunk to resolve my conflicts and am getting test failures in apiserver/provisioner/prepare_test.go
<anastasiamac> dimitern: how r u?
<dimitern> anastasiamac, oh, let me have a look?
<dimitern> anastasiamac, I'm better than last week :) - no blockers
<anastasiamac> dimitern: ""cannot allocate addresses: dummy.NetworkInterfaces is broken"
<anastasiamac> line138/288
<anastasiamac> :D
<dimitern> anastasiamac, hmm I mean can you paste the failures?
<dimitern> anastasiamac, to see the context
<anastasiamac> dimitern: http://pastebin.ubuntu.com/10370778/
<anastasiamac> dimitern: really appreiate ur help :D
<anastasiamac> appreciate even
<dimitern> anastasiamac, right, have you merged the changes to the dummy provider?
<anastasiamac> dimitern: ?
<anastasiamac> dimitern: i got the trunk, created my branch and applied my changes
<anastasiamac> dimitern: running tests, gives me this error :D
<anastasiamac> dimitern: what m i missing?
<anastasiamac> dimitern: :)
<dimitern> anastasiamac, let me have a look..
<anastasiamac> dimitern: do u want the link to PR?
<dimitern> anastasiamac, my tests on trunk are passing, so maybe you haven't merged all changes?
<dimitern> anastasiamac, yes please
<anastasiamac> dimitern: https://github.com/juju/juju/pull/1652
<anastasiamac> dimitern: RB http://reviews.vapour.ws/r/979/
<dimitern> anastasiamac, looking
<anastasiamac> dimitern: tyvm
<TheMue> dimitern: ping
<dimitern> anastasiamac, well, istm you haven't pulled everything in there from master - e.g. the apiserver/provisioner changes I made recently (#1646) require some changes in state (#1631) and the dummy provider (#1632)
<dimitern> anastasiamac, these are probably missing (the last one for sure), hence the error
<dimitern> TheMue, pong
<anastasiamac> dimitern: k. thnx :D i'll double check!
<dimitern> anastasiamac, i suspect you've merged master partially
<TheMue> dimitern: stumbled over the usage of network.Address in state. once we use it directly, so w/o any tags, the other time we have already a local substitute with a tag giving the Scope field the name networkscope
<dimitern> TheMue, can you give me examples?
<dooferlad> dimitern: hangout?
<dimitern> dooferlad, in 5m pls
<TheMue> dimitern: yep, look at addmachine.go:45 and address.go:183
<dooferlad> dimitern: sure.
<TheMue> dimitern: similar with hostPort in address.go few line later too
<dimitern> TheMue, I'll get back to you after my 1:1 with dooferlad, if that's ok
<TheMue> dimitern: sure, thx
<anastasiamac> dimitern: contacted on PM
<dimitern> anastasiamac, sure, in a meeting will get back to you shortly
 * TheMue is out for lunch
<jam> dimitern: have you seen fwereade today?
<dimitern> jam, no, but I've heard he's having connection issues
<jam> k
<jw4> OCR PTAL http://reviews.vapour.ws/r/981/  <-- fixes ./scripts/verify.bash pre-push hook warnings when using newer versions of go
<perrito666> jw4: I would have expected the formatting function to call strig
<perrito666> string
<jw4> perrito666: agreed, but it seems %q isn't handled quite the same as %s
<perrito666> jw4: wellI would assume it is, since the output of calling that actually works
<jw4> perrito666: and I think it works, it's just that newer versions of go vet warn about it
<perrito666> It sounds to me that govet is broken
<jw4> perrito666: possibly
<perrito666> ma windows takes a lot to download
<perrito666> man*
<perrito666> sinzui: ping me when you have a moment :) I am about to make you the happiest QA person in the world
<sinzui> perrito666, really? you can tell me my our maas 1.5, 1.7, and 1.8  hate juju 1.22 and 1.23
<perrito666> sinzui: no but, I just merged the last bit of restore :)
<sinzui> perrito666, NOoooooo......
<sinzui> perrito666, the restore tests have been very reliable this year. Why complete a feature to risk a failure?
<sinzui> perrito666, sorry about the sarcasm
<perrito666> sinzui: I have not nuked the old restore
<perrito666> :p
<dimitern> jw4, ping
<perrito666> sinzui: I need to discuss with you how to do this, I could just make the old restore call the new one with parameters that make it do the same, but output might change
<dimitern> jw4, yeah - go vet seems amiss here
<jw4> dimitern: pong
<sinzui> perrito666, we do need old restore to call new restore because enterprises may have scripted juju 1.18 restore.
<jw4> dimitern: from previous experience I doubt we'll get go vet fixed if it is a bug in go vet, and anyone using go1.4+ won't be able to get past the pre-push hook
<sinzui> perrito666, as for the output change, I don't think there is a contract for the output.
<perrito666> sinzui: ack, btw, there are a couple of new test cases to add :p sorry
<sinzui> perrito666, if CI fails because it scanned output, then we will change ci
<jw4> dimitern: fwiw I'm about to propose a tweak to verify.bash that allows ignoring go vet with an envar
<sinzui> perrito666, old restore only need to work its way. New cases can require the new restore
<perrito666> sinzui: yes, the new cases are for the new restore, just sending a heads up
<perrito666> will send you an email with details
<dimitern> jw4, sure, sgtm, I'll have a look at your PR as well
<jw4> dimitern: ta
 * dimitern needs to start using go1.4
<perrito666> dimitern: I am
<sinzui> thank you very much perrito666 . the email will be helpful as I am not fully caffeinated.
<perrito666> sinzui: I am on that process, I assisted a wedding on saturday and my liver seems to be off for repairs
<sinzui> :)
<jw4> dimitern: http://reviews.vapour.ws/r/982/ <-- allows environment variable to bypass go vet failing the pre-push hook
<jw4> perrito666, OCR ^
<dimitern> jw4, already approved :)
<jw4> dimitern: thanks!
<jw4> :)
<dimitern> jw4, hmmm you know what? looking at your last PR gave me an idea
<jw4> dimitern: yeah?
<dimitern> jw4, it seems we're not adding Logf to the list of printfuncs in verify.bash, and it does seem 1.4 go vet reports only them, but not e.g. logger.Tracef one, which have %q as well
<jw4> dimitern: I think Logf is automatically included and we have to explicitly add the others...
<dimitern> jw4, ah, no - my mistake, go vet did report logger.Infof("assigned address %q to container %q", addr, container) for example
<dimitern> jw4, so it's that
<dimitern> it's not that even
<dimitern> jw4, LGTM on the other one
<jw4> tx dimitern
<dimitern> np
* ChanServ changed the topic of #juju-dev to: https://juju.ubuntu.com | On-call reviewer: see calendar | Open critical bugs:  1424669
<sinzui> dimitern, natefinch can you find someone to look into a gccgo problem in bug 1424669
<mup> Bug #1424669: ppc64el fail multiple definitions of juju_juju_api_networker.NewState <ci> <gccgo> <ppc64el> <regression> <test-failure> <juju-core:Triaged> <https://launchpad.net/bugs/1424669>
<dimitern> sinzui, I was looking at this since saturday
<dimitern> sinzui, it's another random ppc64 gccgo compiler issue
<dimitern> sinzui, like the last blocker
<dimitern> sinzui, I've requested access to a ppc64 machine to all me to run tests and analyze whether building a more recent version of gccgo will resolve this
<sinzui> dimitern, It is consistent since those the commits, the ppc suite are not unreliable
<sinzui> dimitern, I will get you access to stilson-09 in a few minutes
<dimitern> sinzui, yes, but it only happens on ppc64, right?
<dimitern> sinzui, ah, great!
<sinzui> dimitern, yes, but the duplicate definition issue was identified to be a gccgo problem. Test need to be written a certain way to ensure the real impl isn't seen by the compiler
<dimitern> sinzui, I can usually reproduce such gccgo issues easily on my trusty amd64 machine with gccgo, but not this one
<dimitern> sinzui, hmm is there some document or instructions on this?
<sinzui> dimitern, I don't know, jam and wallyworld fixed the bugs in the past
<sinzui> dimitern, I think the issue related to passing interfaces vs passing strings
<dimitern> sinzui, ok, I'll look into that
<aisrael> natefinch: Have you had a chance to look more into bug 1424069?
<mup> Bug #1424069: juju resolve doesn't recognize error state <juju-core:New> <https://launchpad.net/bugs/1424069>
<natefinch> aisrael: no, sorry, haven't put any more time into it.  I'll spend some time trying to figure it out today.
<aisrael> natefinch: much appreciated. It's a bit of a blocker for me, unfortunately
<sinzui> natefinch, dimitern : The QA team are looking for advice regarding bug 1424695. We don't know if this issue is juju or CI. We are happy to change CI to make juju pass
<mup> Bug #1424695: cloud-init cannot download agent from state-server <ci> <maas-provider> <network> <regression> <trusty> <juju-core:Triaged> <https://launchpad.net/bugs/1424695>
<dimitern> sinzui, I'll look into it
<sinzui> dimitern, we are working on getting logs, so the bug is reported from my memory
<dimitern> sinzui, yeah logs will be good to have - I've been monitoring those failing maas jobs on 1.22 for a few days
<sinzui> dimitern, if John's fix isn't ready for the next run, we will intercept machine-1 before it is destroyed
<dimitern> sinzui, great, please let me know
<alexisb> natefinch, do you think that https://bugs.launchpad.net/juju-core/+bug/1424069 may be a result of current LE work?
<mup> Bug #1424069: juju resolve doesn't recognize error state <juju-core:New> <https://launchpad.net/bugs/1424069>
<ericsnow> wwitzel3: http://reviews.vapour.ws/r/983/
<natefinch> alexisb: no idea, I'm working on investigating it now.  At least it's easily reproducible
<alexisb> natefinch, ack
<wwitzel3> ericsnow: will take a look
<ericsnow> wwitzel3: ta
<TheMue> dimitern: beside the types to move we also have methods on State responsible those types (would be nice to move them too) and which use the package private network related docs, like ipaddressDoc
<dimitern> TheMue, that sounds like a good idea, but can it be done?
<dimitern> TheMue, i.e. state.State can't have methods defined on it in a subpackage
<TheMue> dimitern: I'm currently checking, many depending places
<TheMue> dimitern: yes, otherwise the new sub-package has to provide functionality used by those functions
<TheMue> dimitern: like e.g. State.AddIPAddress()
<TheMue> dimitern: a wonderful candidate
<TheMue> :)
<dimitern> TheMue, yeah :)
<TheMue> dimitern: thinking of a NetworkState type in the network package, returned by State and containing all needed data
<TheMue> dimitern: and then move the methods to this type
<dimitern> TheMue, experiment a bit and I'll see what you've pushed later
<TheMue> dimitern: so nwst := st.NetworkState() and nwst.AddIPAddress()
<TheMue> dimitern: will do
<dimitern> TheMue, can I get an LGTM on this fix for the blocker bug please? http://reviews.vapour.ws/r/986/
<dimitern> natefinch, perrito666, ^^
<dimitern> katco, ^^
<dooferlad> TheMue / dimitern: could you take a look at this monster diff? https://github.com/juju/juju/pull/1657 Two whole lines!
<dimitern> dooferlad, looking :)
<dimitern> dooferlad, reviewed
<dooferlad> dimitern: thanks!
<dooferlad> dimitern: Doh! Good point!
<dimitern> dooferlad, ;) np
<dimitern> ericsnow, ping
<ericsnow> dimitern: hey
<dimitern> ericsnow, hey :) I'm glad someone is around - can I get an LGTM on this fix for the blocker bug please? http://reviews.vapour.ws/r/986/
 * ericsnow takes a look
<dimitern> ericsnow, thanks!
<ericsnow> dimitern: done
<dimitern> ericsnow, cheers
<mbruzek> ahoy abentley!  We are seeing an error on the automated testing system.  Can you take a look?  http://juju-ci.vapour.ws:8080/job/charm-bundle-test-azure/46/console
<mbruzek> abentley: I see a few error messages in there that I don't know how to resolve.
<mbruzek> ERROR cannot assign unit "kubernetes/0" to machine 2: unit placement is not supported with availability-sets-enabled
<dimitern> mbruzek, AFAIK azure does not support --to for deployments
<mbruzek> dimitern: OK I thought it was just a setting in the azure setup that we could change.
<dimitern> mbruzek, when you have "availabiliy-sets-enabled: true" set
<mbruzek> dimitern: could we set that to false?
<mbruzek> or do we need that?
<dimitern> mbruzek, I suppose if you haven't heard of it you don't need it :)
<dimitern> mbruzek, it's an env.yaml setting
<dimitern> mbruzek, but it's enabled by default for azure
<mbruzek> dimitern: We want to be able to pass on Azure, and our bundle needs some co-located charms for it to work.
<mbruzek> dimitern: So are you saying that if we set that to false, Azure will not honor the --to command?
<dimitern> mbruzek, so then try adding "availability-sets-enabled: false" in your env.yaml for that environment and bootstrap again (it can't be changed after bootstrap)
<dimitern> mbruzek, I'm saying the opposite :)
<mbruzek> dimitern: OK.  This is the automated CI system I need abentley or sinzui to help with that.
<dimitern> mbruzek, if it's false --to is supported
<dimitern> mbruzek, +1
<mbruzek> dimitern: thanks for your help
<dimitern> mbruzek, np
<dimitern> sinzui, one blocker down, one to go - but I'm at eod for some time now, so somebody else perhaps; getting logs from the machine (1,2) will definitely help there
<sinzui> dimitern, I am almost to it.
<dimitern> sinzui, great! I hope it works
<sinzui> natefinch, abentley : we need to discuss bug 1424777
<mup> Bug #1424777: local-provider precise failed to upgrade <ci> <local-provider> <precise> <regression> <upgrade-juju> <juju-ci-tools:New> <juju-core:Triaged> <https://launchpad.net/bugs/1424777>
<abentley> sinzui: sure thing.  The usual hangout?
<sinzui> abentley, sure
<natefinch> sinzui: sure, the release meeting hangout?
<thumper> rick_h_: around?
<rick_h_> thumper: yep
<rick_h_> for a bit, what's up?
<alexisb> wallyworld, I will be back after bed time if you need to talk with me re releases
<wallyworld> thumper: got 5?
<wallyworld> sinzui: apt fix merged into 1.22
<beisner> curious - is juju bootstrapping an enviro with   default-series:  vivid   defined in the environments.yaml expected to work at this point in the cycle?  i keep getting bootstrap timeouts attempting to do so.
<sinzui> thank you wallyworld
<beisner> ^ ERROR failed to bootstrap environment: waited for 10m0s without being able to connect: Permission denied (publickey).
<beisner> ^ setting to default-series:  utopic   or  trusty succeeds.
<beisner> if it's a no-op atm, please tell me to stop trying for now  ;-)
<wallyworld> beisner: i thought it worked. sinzui, you have seen vivid work?
<sinzui> beisner, it certainly work in our local provider tests.
<beisner> sinzui, wallyworld - fyi that's using the openstack provider and the maas provider.
<sinzui> beisner, are you using ppc openstack and vivid?
<beisner> all amd64 here
<beisner> for this one
<sinzui> beisner, from my experience new ubuntu series do work, but you make need to create the images. We have built and published the agents (except for ppc64el)
#juju-dev 2015-02-24
<beisner> sinzui, so in the openstack provider attempt, juju fires up a vivid instance, and i can see the nova console log that it's booted and ready with whatever userdata was passed to it.  but there is a key mismatch.
<beisner> sinzui, with the maas deploy, i get the same symptom (key issue), and it's much harder to get console output.
<beisner> er rather, maybe not a key mismatch, but definitely a key issue.
<sinzui> beisner, I don't think key issues are series issues
<beisner> sinzui, all those woes go away when I set  default-series:  utopic   or  trusty   in the environments.yaml.
<sinzui> beisner, I think you found a bug :)
<beisner> sinzui, ok, what can i do/collect to raise a helpful/meaningful bug on this?
<beisner> ie.  is there a way to get more verbosity from juju bootstrap?
<sinzui> beisner, the cloud-init-output log and maybe a machine-0 log if it gets that far
<beisner> sinzui, unit 0 never comes alive according to juju
<beisner> and juju debug-log is no help at that stage
<sinzui> beisner, I often ssh into the machine the moment I see the ip is open and tail the /var/log/cloud-init-output.log
<beisner> sinzui, ah cool.  i'll dive in a bit more.  appreciate the guidance.
<wwitzel3> ericsnow: just realized I forgot to hit publish on that review, you have a review from me now.
<ericsnow> wwitzel3: thanks
<wwitzel3> ericsnow: mostly minor, I found it all easy to follow, no comments about the service stuff since it is pretty generic boiler platey and we talkeda bout it before
<ericsnow> wwitzel3: cool
<wallyworld> thumper: you around?
<wallyworld> sinzui: so we should be able to get 1.22 out now right? since the precise upgrade issue is only 1.23?
<sinzui> wallyworld, no, because we never got a pass for 1.22
<wallyworld> sinzui: assuming ci becomes happy
<sinzui> wallyworld, 1.22-beta4 has NEVER passed CI
<wallyworld> :-(
<sinzui> wallyworld, if it does pass, then I release
<wallyworld> let's hope this one works
<davecheney> thumper: ping
 * thumper is here now
<wallyworld> thumper: can i grab 5 when you are free?
<thumper> wallyworld: sure, I'll be done chugging lunch in about 5 minutes
<wallyworld> np
<thumper> it's a banana protein smoothy
<wallyworld> mmmmm
<anastasiamac> 5min for smoothie?
<anastasiamac> thy*
<davecheney> thumper: shall we meet in the 1:1 hangout ?
<thumper> davecheney: yep, how about in 11 minutes?
<davecheney> thumper: go talk to wallyworld first
<thumper> ta
<davecheney> i'll see ou in the hangout in whenever
<thumper> wallyworld: our 1:1?
<wallyworld> yup
<wallyworld> sinzui: i just looked at the dashboard and the latest 1.23 run had local-upgrade-precise-amd64 passing
<wallyworld> have you upped the timeout already?
<sinzui> wallyworld, I did, that was my proof
<wallyworld> sinzui: logs are needed to help see where the time is going
<wallyworld> i can't see any linekd to the dashboard
<sinzui> wallyworld, I can give you the failures, but the passes might be more informative since I also gave the slaves more time to collect
<sinzui> s/slave/services
<wallyworld> sinzui: could you attach both to the bug for me?
<sinzui> wallyworld, I will see what I can do. I don't want to make them public if the contain credentials
<wallyworld> sinzui: make the bug private?
<sinzui> wallyworld, I cannot because that will hide the critical blockers
<wallyworld> sinzui: oh, maybe send privately?
<sinzui> wallyworld, this wouldn't be awkward if the credentials for reports.vapour.ws had not also failed this weekend too
<sinzui> wallyworld, did you see smoser's ruling on apt-get dist-upgrade
<wallyworld> sinzui: one sec, just finishing standup
<wallyworld> sinzui: read scott's bug comments, we should be ok - we don't use proposed pocket with precise
<wallyworld> that i know of
<alexisb> menn0, thumper is this doc up to day??:
<alexisb> https://docs.google.com/a/canonical.com/document/d/1jsuoTbXZbj3wtoXCpc5MGFVvwuofYx3hLw2eNoXEmE0/edit#heading=h.aby6yid7wq2d
 * menn0 looks
<menn0> alexisb: yes, except that now we have a working proof of concept of logging to MongoDB and have run scaling tests (see your email)
<sinzui> wallyworld, we never use proposed
<menn0> alexisb: I have been working on turning the POC into production code but whether it gets merged is somewhat dependent on whether the performance hit is deemed ok
<alexisb> menn0, yep understood, I just need a way to capture the work for logging that can be shared with those that are interested
<sinzui> wallyworld, but juju does do apt-get upgrade, which didn't give us an updated cloud-utils. apt-get install  then did a remove
<menn0> alexisb: ok. let me know if you need to know more.
<alexisb> ie answer the question for "why is logging for JES important and requires work"
<alexisb> nope I think that gets me what i need
<alexisb> thanks
<wallyworld> sinzui: so maybe the fix to put cloud-utils and cloud-image-utils on the one line is not required anymore
<sinzui> wallyworld, it is required because we haven't changed anything else to ensure removals cannot happen
<wallyworld> ok
<menn0> wallyworld, sinzui: you guys seem to be discussing the same part of the code that I just filed a bug about. (bug 1424892)
<mup> Bug #1424892: rsyslog-gnutls is not installed when enable-os-refresh-update is false <cloud-init> <juju-core:New> <https://launchpad.net/bugs/1424892>
<wallyworld> menn0: nah, different
<sinzui> menn0, yes
<wallyworld> this is the deb packaging issue whcich affected cloud-utils
 * thumper sees that menn0 has answered all of alexisb's questions
<thumper> coffee time then...
<wallyworld> menn0: your issue is the behaviour of the flags to disable apt
<sinzui> menn0, apt-get update finds the new packages (in cloud-* example) but apt-get update will not install them because update is not permitted to install new deps!
<sinzui> menn0, but apt-get dist-upgrade can install new deps
<wallyworld> menn0: when upgrading, do you recall if the state server rejects connections until all nodes in the env are deemed to have upgraded?
<menn0> wallyworld: not quite ... let me quickly look at the code
<menn0> wallyworld: a state server will accept API connections once it itself has upgraded
<menn0> wallyworld: but state servers always upgrade first, before other nodes
<wallyworld> menn0: ok, ta. i'm looking into the CI blocker where precise upgrades tie out
<wallyworld> there's a bucket load of mongo connection failures that go on and on
<wallyworld> but state server probably not at fault if it accepts connections after it has finished
<menn0> wallyworld: do you have some logs handy?
<wallyworld> menn0: i'll forward an email. sinzui had to increase timeout from 10 mins to 20 to make CI local precise upgrades pass. but just precise
<menn0> wallyworld: that is certainly odd.
<wallyworld> indeed
<wallyworld> precise runs a slightly different mgo version
<wallyworld> that's all i can think of off hand
<sinzui> wallyworld, hp's swift isn't publish failed. I am getting out the hammers
<wallyworld> what's that about hp?
<sinzui> wallyworld, timouts uploading
<wallyworld> oh joy
<sinzui> wallyworld, I switch the job to not rebuild. just try to publish what the previous job made
<wallyworld> ok
<beisner> wallyworld, sinzui - back for a bit, raised a bug on that vivid thing.   should be readily reproducible but holler if there are any ?s.    https://bugs.launchpad.net/juju-core/+bug/1424900
<mup> Bug #1424900: Bootstrapping Vivid:  ERROR failed to bootstrap environment, Permission denied (publickey), ci-info: no authorized ssh keys fingerprints found for user ubuntu <openstack> <uosci> <juju-core:New> <https://launchpad.net/bugs/1424900>
<wallyworld> thank you
<wallyworld> sinzui: menn0: with those logs, i see the 1st 4 minutes spinning up the state server and machines 1,2, then the state server upgrade completes in about  minute, then we see a tonne of connection terminated errors lasting several mintes, so it seems there's an issue wit the worker nodes upgrading
<menn0> wallyworld: yep, i'm looking at those logs now
<menn0> wallyworld: the machine-0 logs are all perfectly normal
<menn0> wallyworld: but the machine-1 logs indicate that the agent never restarted into the new version
<wallyworld> menn0: in machine 1 lo, i see a 3 minute gap fetching tools
<menn0> wallyworld: it sees the need to upgrade but never seems to reboot
<wallyworld> menn0: the test may have timed out before machine 1 could restart
<wallyworld> take off the 3 minutes to fetch tools
<sinzui> menn0, its about timing. I was on the machine when machine 1 was shutdown because of a timeout. it was upgrading. so I hacked the job on the precise slave to give it 20 minutes to see a pass.
<wallyworld> and it probably would have been ok
<menn0> but 20 mins is just crazy
<sinzui> menn0, all machines normally upgrade in less that 60 seconds. so 18 minutes is scarry
<wallyworld> sinzui: this is what i see as the issue
<wallyworld> 2015-02-23 18:36:07 INFO juju.worker.upgrader upgrader.go:201 fetching tools from "https://10.0.0.191:17070/environment/329350b1-edf2-4d62-8156-7338a12d3808/tools/1.23-alpha1.1-precise-amd64"
<wallyworld> 2015-02-23 18:39:52 INFO juju.utils http.go:66 hostname SSL verification disabled
<wallyworld> that almost 4 minute gap
<menn0> looking at the timestamps, the machine was going VERY slowly
<menn0> 30s between seeing the need to upgrade and then /starting/ to download the tools
<sinzui> menn0, yep. I rebooted the machine too. It is fast when I use it
<menn0> sinzui, wallyworld: the agent is still starting up when it sees the need to upgrade. the timings between the various workers starting up is rather wide, like the system was crawling.
<wallyworld> yes
<wallyworld> it just seems machine 1 is very, very slow
<sinzui> menn0, it wasn't/isn't
<menn0> sinzui: it might not be, but it just looks that way based on the logs
<sinzui> menn0, I also cleared /var/cache/lxc/cloud-precise
<wallyworld> i'm not sure what to do now to diagnose further - if it really is just precise, that makes it very hard to reason about
<sinzui> we are still waiting for the same job to run with 1.22 to compare
<wallyworld> i guess we see how 1.22comes out
<menn0> wallyworld: we could spin up a precise instance on ec2
<wallyworld> we could, i might do that
<menn0> wallyworld, sinzui: as an example, you can see the difference the "slow down" when you look at the deployer worker in the logs
<menn0> wallyworld, sinzui: before the API disconnection (due to the state server upgrading itself), the deployer worker starts 1s after it's parent worker (api-post-upgrade)
<menn0> wallyworld, sinzui: at the bottom of the logs it starts 5.5 mins after it's parent worker
<sinzui> wow
<menn0> wallyworld, sinzui: that's pretty strange
<sinzui> that is indeed the difference we feel watching it
<sinzui> menn0, the upgrade jub just ran with 1.22.
<wallyworld> hmmm. maybe something is trashing the disk? or eating to cpu?
<menn0> wallyworld: that's what i'm thinking. and that thing could even be something in Juju itself.
<sinzui> 2015-02-24 02:35:45 INFO juju.cmd.juju upgradejuju.go:214 started upgrade to 1.22-beta4.1
<sinzui> and status shows it complete at
<sinzui> 2015-02-24 02:36:09
<menn0> sinzui: what instance spec is being used for the precise tests?
<menn0> sinzui: that's the kind of timing I would have expected
<wallyworld> but is the above for the state server? or a machine?
<wallyworld> ah
<wallyworld> the cmd
<sinzui> menn0, the precise slave has 8G ram with 4 vcpu
<sinzui> menn0, at this moment it has lots of resources free, but it was busy last hour building and testing
<sinzui> menn0, there was nothing for us to cleanup when we started investigating. the machine was fast for us
<wallyworld> sinzui: the precise slave is dedicated to running the juju test in question?
<sinzui> wallyworld, it is
<menn0> sinzui: i'm looking at jenkins. are the latest successes because of the extended timeout?
<sinzui> menn0, the 2 master ones are
<menn0> sinzui: kk
<sinzui> menn0, the 1.22 passed normally
<menn0> sinzui: 18mins is just nuts
<sinzui> menn0, sure, but not for maas. I wondered if recent changes needs a new deps and extra work for precise
<menn0> wallyworld: are you spinning up a precise instance? i'd like to poke around as the upgrade happens
<wallyworld> menn0: just resetting by source tree
<wallyworld> my
<menn0> sinzui: perhaps bit I can't imagine what would cause this
<menn0> but
<menn0> sinzui: one thing that could be helpful is if the env had debug logging turned on.
<menn0> sinzui: it starts of in debug but switches to info for the root logger
<menn0> 2015-02-23 18:32:05 DEBUG juju.worker.logger logger.go:45 reconfiguring logging from "<root>=DEBUG" to "<root>=INFO;unit=DEBUG"
<sinzui> menn0,  I can do that now that ci is locked down
<sinzui> menn0, I can switch it now, then we wait for 1.23 to test
<menn0> wallyworld: meant to say... all those API disconnect messages in the machine-0 logs are just due to the repeated "juju status" polling that the test script does. that's fairly normal.
<sinzui> menn0, debug is in place
<menn0> sinzui: awesome
<wallyworld> menn0: i have a bootstrapped precise instance - did you want me to add your ssh public key?
<menn0> wallyworld: please
 * thumper tries for focus for an hour
<thumper> if it is urgent, text me
 * thumper doesn't expect anything urgent
<wallyworld> menn0: 54.82.35.127  i'll start a precise worker machine
<wallyworld> menn0: i'm a tool - i bootstrapped 1.23 not 1.21
<wallyworld> ffs
<menn0> it's so hard to get good help these days...
<wallyworld> forgot to type /usr/bin/juju
<wallyworld> sigh
<menn0> wallyworld: has that host gone away? I can't connect to it now.
<wallyworld> menn0: yeah, almost done starting a 1.21 host, sorry
<wallyworld> it's been slow to come up
<wallyworld> menn0: machine 0 is 54.158.193.40
<wallyworld> machine 1 is 54.204.193.53
<menn0> wallyworld: I thought you were just going to test with the local provider on a single precise machine
<wallyworld> menn0: i was curious to see how precise in general went
<wallyworld> but we can do both
<menn0> wallyworld: is my key there?
<wallyworld> yep
<wallyworld> do you want to use machine as host for a local env
<wallyworld> machine 0
<wallyworld> mongo would need to be stopped
<wallyworld> i should just fire up a new machine
<menn0> wallyworld: I was using the wrong key... i have a personal one and a canonical one. fixed now
<menn0> wallyworld: how about I fire up the machine for the local test
<wallyworld> ok
<wallyworld> menn0: upgrade on aws precise was fast, so it has to be a resource contention issue
<menn0> wallyworld: ok. a useful data point. i'm just setting up this other instance now.
<menn0> sinzui: SSD or magentic storage?
<sinzui> menn0, I think the latter. the machine is in Hp
<menn0> sinzui: cool. i'll go with that.
<menn0> wallyworld: it's 54.190.88.226. installing 1.21 now.
<wallyworld> ok, does it have my ssh key imported?
<sinzui> wallyworld, all the mass deploy jobs are still failing.
<wallyworld> hmmm
<wallyworld> i wonder what's different compared with clouds
<wallyworld> the same scripts should work on both
<wallyworld> is there a url with logs?
<sinzui> wallyworld, no, we cannot get logs for maas because they have unresolvable dns
<wallyworld> oh joy, this will be fun to solve
<sinzui> wallyworld, I am attempting it get into the maas to find the names, for the unit, them use virt-viewer to connect directly to the console
<sinzui> I dont' have creds though for maas 1.7 and 1.8 though
<menn0> wallyworld: well i'm seeing a problem with the upgrade on precise but it doesn't look the same as what happen in the logs from sinzui
<menn0> wallyworld: machine-0 fails to upgrade because of:
<menn0> "set AvailZone in instanceData" failed: failed verification of local provider prerequisites:
<menn0> cloud-image-utils must be installed to enable the local provider:
<menn0>     sudo apt-get install cloud-image-utils
<menn0> wallyworld: shouldn't the upgrade step handle that itself?
<wallyworld> that's expected
<wallyworld> that package has to be on the host machine
<wallyworld> as do one or two others
<wallyworld> hmmm, maybe
<wallyworld> but in general
<wallyworld> the local provider checks for needed packages and prints those messages if they are not there
<menn0> I installed juju-local so shouldn't this already have been taken care of
<menn0> ?
<menn0> wallyworld: maybe it got uninstalled by another operation?
<wallyworld> cloud-image-utils isn't a prereq of juju local, maybe it should be?
<menn0> wallyworld: i'll work around this for now so that I can get to the actual problem that CI is seeing
<wallyworld> i think in trusty cloud-utils includes cloud-image-utils
<wallyworld> i can't wait for precise to go away, but still 2 years keft
<sinzui> wallyworld, I cannot copy this crap gui's cloud-init-output
<wallyworld> sigh
<wallyworld> is there an obvious error?
<sinzui> wallyworld, I can say it is the same error as before where the apt-line is garbled
<wallyworld> i'm trying to spin up maas locally but the bootstrap node refuses to transition from Deploying
<wallyworld> that doesn't make sense as there should be no quotes there now
<wallyworld> and why just maas and now AWS or HP etc
<sinzui> and it died as I almost got the log
<sinzui> wallyworld, as per the bug
<sinzui> util.py[WARNING]: Failed to install packages: ['bridge-utils', 'curl cpu-checker bridge-utils rsyslog-gnutls cloud-utils cloud-image-utils']
<wallyworld> sigh
 * sinzui double checks commit 
<wallyworld> seems bridge-utils is added twice which is messing it up
<sinzui> wallyworld, are are testing your commit
<wallyworld> yes on aws
<wallyworld> works perfectly
<sinzui> wallyworld, apt doesn't care about duplicates on the command line
<wallyworld> sure, but adding twice seems to mess up juju's rendering of the cmd line
<wallyworld> sinzui: can i get access to your maas?
<wallyworld> if i can't reproduce, i can't fix
<sinzui> wallyworld, sure but it so poorly documented I cannot offer much
<wallyworld> maybe pm or email the ip of the controller and auth key
<menn0> wallyworld, sinzui: i haven't been able to repro this precise upgrade timeout issue yet but I still have a few ideas
<wallyworld> sinzui: ah, i see where bridge-utils is added twice - it's hard coded in the maas provider
<wallyworld> that's why it is failing on maas
<sinzui> wallyworld, really>
<sinzui> wallyworld, jog hack the local machine to capture logs from machine-0. This isn't too helpful since the failures are machines 1 and 3
<wallyworld> sinzui: yes, on machine 0 we run the scripts ourselves, not cloud init
<menn0> sinzui, wallyworld: ok, i'm stumped on how to reproduce this precise issue
<wallyworld> sinzui: it may be the quickest thing to do is to go back to installing one package at a time now that cloud-image has been moved into the correct repo
<menn0> sinzui, wallyworld: every upgrade works quickly for me
<sinzui> wallyworld, yes, with the caveat that we must also install clout-utils to force the upgrade
<wallyworld> sinzui: yep, i'll install cloud-utils along with the other ones we expect
<sinzui> wallyworld, or we do dist-upgrade (but I think that is risky for today)
<wallyworld> yeah, i'll keep it simple
<wallyworld> menn0: i think juju might be ruled out - something must be thrashing the machine though
<menn0> wallyworld: either that or i'm missing some aspect of the test setup
<menn0> i'm about to EOD
<wallyworld> ok, thanks for looking
<wallyworld> sinzui: do i need to do apt-get install --target-release precise-updates/cloud-tools cloud-utils   ?
<wallyworld> or can i leave off the --target-release bit
<wallyworld> i think i need it right? for precise?
<menn0> sinzui, wallyworld: of course I just realised that I was testing with a 1.23 that was a little behind the times and didn't include some of the recent commits that might be contributing to the issue
 * menn0 facepalms
<menn0> sinzui, wallyworld: it might be worth repeating what i've done...
<wallyworld> hard to get good help :-)
<menn0> touche
<wallyworld> i gotta fix this other one first :-(
<menn0> but I really need to EOD or my wife is going to get pissed
<wallyworld> np, leave it to us
<jog> hi wallyworld
<jog> wallyworld, I was just looking at the MaaS test results for 1.22 revision 79e5ea8a and still see the failure mentioned in bug 1424695.
<mup> Bug #1424695: maas cloud-init cannot download agent from state-server <ci> <maas-provider> <network> <regression> <trusty> <juju-core:In Progress by wallyworld> <juju-core 1.22:In Progress by wallyworld> <https://launchpad.net/bugs/1424695>
<jog> wallyworld, it's looks like you through that commit should have fixed that bug?
<jog> thought even
<jog> wallyworld, looks like maybe you dropped for a bit, did you see my comment above?
<wallyworld> jog: no
<jog> wallyworld, I was just looking at the MaaS test results for 1.22 revision 79e5ea8a and still see the failure mentioned in bug 1424695.
<mup> Bug #1424695: maas cloud-init cannot download agent from state-server <ci> <maas-provider> <network> <regression> <trusty> <juju-core:In Progress by wallyworld> <juju-core 1.22:In Progress by wallyworld> <https://launchpad.net/bugs/1424695>
<jog> looks like you expected that commit to resolve that quoted package string issue?
<wallyworld> jog: yes, sadly maas fails where the other clouds are ok, so i've marked bug as in progress again. i don't have a working maas to test with
<jog> wallyworld, you have access to finfolk.internal ?
<wallyworld> no, i tried and couldn't get in
 * jog wonders what happened to core vmaas setup on gremlin.internal that was setup during the Brussels sprint.
<dimitern> jog, well, we were supposed to use it for ipv6 work of maas and juju, but we didn't need to
<dimitern> jog, IIRC the maas guys used it for qa stuff (or was it finfolk?)
<jog> dimitern, finfolk is used by juju-qa but I have an extra env setup for debugging for anyone on core that needs it
<dimitern> jog, right, that's good to know then :)
<wallyworld> dimitern: hi, i'm a little concerned that the vet warnings can be suppressed. shouldn't we be fixing the warnings? those provisioner ones are annoying :-)
<dimitern> wallyworld, they should've been fixed yesterday by jw4
<dimitern> wallyworld, but maybe it bounced due to the blocker
<dimitern> wallyworld, nope - it did bounce - https://github.com/juju/juju/pull/1654
<dimitern> wallyworld, and these appear for go1.4 only, which we don't officially support yet ;)
<dimitern> wallyworld, go vet in 1.4 is dumber than 1.2 - "%q" is reported for a type with String() method
<dimitern> wallyworld, I'm not sure how much you've seen of my comments
<wallyworld> dimitern: my stupid connection to free node keeps dropping, so none sorry :-(
<dimitern> wallyworld, I thought so :)
<dimitern> wallyworld, basically go vet 1.4 is dumber than go vet 1.2 (which is still the official go version we're using) - "%q" for a type with String() is reported
<dimitern> wallyworld, and there's this PR which bounced due to the blocker - https://github.com/juju/juju/pull/1654 which fixes the warnings
<wallyworld> wtf, go vet go dumber
<wallyworld> what are they thinking
<wallyworld> i'm on go 1.3.x
<dimitern> they were *not* thinking :)
<wallyworld> dimitern: with the blockers - we tried and couldn't reproduce the precise uprade one today
<wallyworld> we contend it's a machine thrashing issue on the test vm
<dimitern> wallyworld, the slowdown or the quoted packages?
<wallyworld> slowdown'
<wallyworld> with the packages one, i changed the behaviour but maas still failed (only maas, not aw etc)
<wallyworld> so i'm looking to revert the apt behaviour to be as per 1.21 since as of today or yesterday the cloud archive has been updated
<dimitern> wallyworld, hmm.. maas took longer than usual to upgrade according to the bug reports
<wallyworld> and we don't need to install cloud-utils and cloud-image-utils together
<wallyworld> oh, we were working on the assumption of local taking too long, that's what cutis told us
<dimitern> one thing occurred to me - for precise, are we making sure we add the cloud-tools pocket?
<wallyworld> dimitern: yeah, that's added
<dimitern> there's the MaybeAddCloudToolsWhatever in cloudinit that gets called for a given series - but IIRC it was put in an if block with enableAotUpdate
<wallyworld> dimitern: and i just confirmed, doing apt-get install cloud-utils by itself breaks
<wallyworld> but apt-get install cloud-utils cloud-image-utils works
<wallyworld> but setting that up breaks on maas
<dimitern> wallyworld, due to cloud-init getting removed?
<wallyworld> yeah
<dimitern> can you confirm cloud-image-utils comes from the cloud-tools pocket on precise?
<dimitern> it has to be fixed there
<wallyworld> dimitern: actually, it may be that we are only adding the cloud-tools pocket when bootstrapping
<wallyworld> that would explain things
<dimitern> wallyworld, that's wrong if we do
<dimitern> wallyworld, I'll have a look what triggers it
<wallyworld> dimitern:  i have a branch which i was going to propose pn gh to revert the apt behaviour to be more like 1.21, but with cloud-utils added (it needs to be installed to get the right version). bootstrap is fine, but adding a new machine fails.  it may be fue to cloud-tools pcoket not being added except for at bootstrap. but i have to go out to a Foo Fighters concert, will be back later. here's the branch. https://github.
<wallyworld> com/wallyworld/juju/tree/revert-apt-install-method
<dimitern> wallyworld, sure, I'll look into it
<wallyworld> the above branch reverts the behaviour of multiple packags on the one apt-get line
<dimitern> wallyworld, enjoy the concert ;)
<wallyworld> ty
<wallyworld> dimitern: if you run up a machine, apt-cache policy cloud-utils should show 0.27
<wallyworld> on bootstrap and a worer node
<wallyworld> worker
<wallyworld> and cloud-image-utils should be there too
<dimitern> wallyworld, ok, will check both
<wallyworld> i'll check back later in a few ours
<wallyworld> tyvm
<dimitern> np
<hazmat> is gwacl's primary project site still launchpad.net/gwacl?
<jam> dimitern: did you see william today?
<dimitern> jam, not yet
<jam> wallyworld: did you want to discuss ensure-ha --to ?
<jam> natefinch: /wave
<natefinch> jam: howdy
<natefinch> jam: gimme 2 minutes to go get my coffee?
<jam> k
<jam> natefinch: I don't hear you
<perrito666> morning
<perrito666> natefinch_: still up?
<natefinch_> perrito666: I am here... got up for an early meeting
<natefinch_> perrito666:  probably will have to go soon as the kids are stirring
<perrito666> natefinch_: I cannot help but notice you are OCR today and I have a very small change here http://reviews.vapour.ws/r/995/
<natefinch_> perrito666: ship it!
<perrito666> tx
<perrito666> I should have known that the trick was to find you half asleep
<perrito666> 3 blocking bugs? oh what have I done to deserve this
<natefinch_> doh
 * dimitern nailed the cause of the blocker
 * dimitern hates cloud-init more than before now
<jam> fwereade: greetings
<fwereade> jam, heyhey
<jam> perrito666: doesn't removing restore break compat with older servers?
<jam> fwereade: so I commented on your last request. I was wondering if we would still want the server to give the official time.
<fwereade> jam, so the server would always return what you asked for?
<fwereade> jam, I'm open to being convinced, but I can't see what we'd use it for today
<fwereade> jam, and if we need it in the future it's a new api version anyway surely?
<jam> fwereade: the client could request an amount, the server may upgrade that to a longer amount and replies with the actual amount
<jam> fwereade: has better future compat if we change the minimum timeout, clients that were asking for something short still work
<fwereade> jam, surely even if we're just changing that behaviour we'd be adding a version anyway?
<jam> fwereade: then why worry about it at all? I thought the point of client requests was to allow flexing it
<jam> I don't think we'd *have* to change the version just because the boundary ranges change, if we make it clear
<jam> that said, we don't need to spend hours on this
<fwereade> jam, because 30s was a magic number embedded deep inside the server that I suspect is more than usually vulnerable to changes without proper foresight
<fwereade> jam, it's the client that needs 30s, and it will still be the client who needs more or less time in future, I think?
<fwereade> jam, boundary values perhaps, so long as we're making them looser, I suppose, but that's still a bit risky for my tastes
<perrito666> jam: mm, you have a good point I think I can make it use both ways according to the server version
<fwereade> jam, "may I be leader for the next X seconds [yes|no]" STM to be simple and not simplistic -- and, hmm, does not actually preclude creating a longer lease internaly -- it just means that the client couldn't take advantage of that knowledge to space out its requests more
<jam> fwereade: so I don't think any client is going to make hard time constraints. They might be able to say "it will take approx X" but I doubt anyone can guarantee that they won't take longer than that
<fwereade> jam, sorry, what won't take longer?
<fwereade> jam, time to renew the lease?
<jam> fwereade: whatever thing they are running that they are expecting to hold the lease
<fwereade> jam, hence putting it in the client's control, and having them request a 60s and renew it in 30s, independent of what else is happening
<fwereade> jam, based on user feedback what is desired/required is a guarantee that a successful is-leader call give you 30s grace in which you're sure you're the leader
<fwereade> jam, worst-case you request *just* before a failing renew, and you *still* get 30s of grace from that success
<jam> fwereade: as in we won't nominate a new leader for 30s after the last one expired ?
<fwereade> jam, no? we won't nominate a new one until immediately afterthe last one expires
<fwereade> jam, that's why I ask for 60s and guarantee 30
<fwereade> jam, and refresh every 30
<fwereade> jam, even when you fail your nth request, your n-1th one is still good, leaving you time to react
<fwereade> jam, while you are still leader and nobody else is stepping on your toes
<jam> fwereade: what is triggering this polling ?
<jam> if it's juju calling a leader hook, can't we easily be blocked waiting for some other hook to finish?
<jam> is it *while* running a given hook we expect them to split off a thread/process to call back into us to ensure that they're still active?
<fwereade> jam, the leadership tracker will be running anyway, independently of anything else -- the hook tool asks the context which asks the tracker if it can be leader
<fwereade> jam, nobody seems to want that
<fwereade> jam, best-effort leader-deposed execution once we're outside the reported grace period seems sufficient
<jam> fwereade: it *feels* to me like someone would write "ok, I need to reconfigure my workload, ask for leader for X seconds, start reconfiguring, oh reconfiguring took too long, but I'm stuck in that process"
<jam> who/what would actually refresh the leadership request
<fwereade> jam, the refreshing is continuous anyway while you're leader whether you're running a hook or not
<jam> fwereade: k, then I don't see any need to set any time, Juju refreshes at an interval of X
<fwereade> jam, I'm not so certain that we'll never need to tweak that...
<jam> fwereade: you just said that if we need to tweak it, it would be a version bump (IMO)
<jam> my point was, if we want to make it variable, make it easy to be variable and still compatible
<fwereade> jam, I thought that was what I was doing :)
<jam> or just make it fixed and we bump the API version when we need to change ti
<jam> it
<jam> fwereade: you made it variable from one side, but not the other
<jam> fwereade: if this is being confusing or feeling like I'm antagonizing you, I'm not trying to, I'm happy with a JFDI here.
<jam> but it seemed odd to say that only one side would get to change without an API version bump
<jam> when it isn't hard to make it graceful either way
<fwereade> jam, I know you're not, but I must admit I am a little confused so there's probably something worth figuring out
<jam> fwereade: I think my gut reaction is "why is this an error, and why can't we just request 0s and get told what the lease time is"
<fwereade> jam, my contention is that it is hard to make it graceful if we allow the server any more than a yes/no :)
<jam> asking for too long I could accept, asking for too short seems like "nope, just take this longer one"
<jam> fwereade: but I was thinking it was being exposed to the charm itself
<jam> and that charmers were going to have to say "I'm goingto run this op, I think it will take 3 minutes, give me a 3min lease"
<jam> which lead to the other problems
<fwereade> jam, if I ask to be leader for 60s and the server makes me leader for 300s, I'm still definitely leader for 60s
<jam> (who can actually refresh, etc)
<fwereade> jam, as far as I'm aware that was never on the table
<fwereade> jam, nobody asked for it, and it adds complexity and temptation to ask for infuriatingly long lease times that then lead to poor experiences when those units fail
<jam> fwereade: that and missed guestimates that then lead to a need to have a separate process that is refreshing. I think the point is Juju is doing all the refreshing (which actually has its own problem of Juju being up and happy, but the charm code stuck in an infinite loop)
<jam> fwereade: but that's probably still a decent place to be.
<wallyworld> dimitern: looks like you found a fix for the cloud-utils issue. i didn't think to set apt-get update = true in cloud init for precise. how does that interact with the apt disable update settings? did you use GetPreparePackages() to selectively include target-series for precise?
<dimitern> wallyworld, it overrides the apt-get update disable flag
<dimitern> wallyworld, it has to otherwise it won't work
<wallyworld> dimitern: ah ok, and we can't add the cloud-tools repo without updating i assume
<dimitern> wallyworld, I'm using your approach with GetPreparePackages from utils/apt, but rather than joining all with " ", I'm calling AddPackage for each one
<wallyworld> dimitern: yeah, that's exactly what i did in my latest branch i pushed before i left
<dimitern> wallyworld, yes - it update is off, no apt-sources or packages are installed
<dimitern> wallyworld, there's a quirk though due to cloud-init
<wallyworld> dimitern: i discovered you had to do the packages one by one otherwise it would be sad
<wallyworld> Foo Fifgters were farking awesome btw, bloody excellent concert
<wallyworld> gad, can't type
<wallyworld> Foo Fighters
<dimitern> wallyworld, sweet! :)
<wallyworld> by ears are ringing :-)
<wallyworld> my
<dimitern> wallyworld, btw - this is the meat of my patch http://paste.ubuntu.com/10389087/ (apart from a similar if (in the beginning) in the templateUserData func in the lxc-broker)
<wallyworld> looking
<wallyworld> dimitern: yeah, that matches my understanding also
<wallyworld> dimitern: i can review once you propose
<dimitern> wallyworld, sure, I'll propose soon, but I wanted to test on a precise host just to be sure
<wallyworld> np
<dooferlad> dimitern: hangout?
<dooferlad> dimitern: MAAS+Juju Network interlock
<dimitern> dooferlad, uh, yeah - omw, thanks!
* ChanServ changed the topic of #juju-dev to: https://juju.ubuntu.com | On-call reviewer: see calendar | Open critical bugs:  1424695 1424777
<mgz> gsamfira: are you around? I've got a fix for windows testing stuff I'd like you to look at
<dimitern> mgz, hey
<dimitern> mgz, you'd probably guess what I'll ask about :)
<mgz> dimitern: I hope to have an update, various things are borked
<mgz> dimitern: who's ocrs today?
<dimitern> mgz, natefinch_ and anastasiamac according to the calendar
<dimitern> mgz, ok, thanks
<mgz> hm, I wonder if I'm in the middle of those two
<mgz> natefinch_: can I have a review plz? https://github.com/juju/testing/pull/52
<natefinch_> mgz: looking
<alexisb> dimitern, howdy, sorry I was late for our 1x1 but I am on the hangout now whenever you are ready
<dimitern> alexisb, oh, omw
<natefinch> mgz: this is a lot more complex than it seems to need to be.  If we know we don't need a whitelist on anything other than windows, why not just put a if runtime.GOOS != "windows" { return }  at the top, and let the rest of the function be windows only?
<mgz> look at the context above, there's also a JUJU_MONGOD variable that's whitelisted everywhere
<mgz> (and potential for more I guess)
<natefinch> mgz: oops, missed the append of the testingVariables, sorry
<mgz> I could make it shorter by just checking that, but it's written in such as way as it wanted to be extensible
<natefinch> yeah... it would probably be a lot easier if I weren't looking at it in a diff
<katco> dimitern: ping
<dimitern> katco, pong
<katco> dimitern: it looks like v2 S3 signing is slightly different than standard v2 signing
<katco> dimitern: amazon states: "Amazon S3 now supports the latest Signature Version 4. This latest signature version is supported in all regions and any new regions after January 30, 2014 will support only Signature Version 4."
<ericsnow> natefinch: 1-on-1?
<katco> dimitern: are you ok with shifting s3 to only using v4? porting the special v2 signing stuff into our standard v2 signing method would be a bit of a pain
<dimitern> katco, let me assimilate this for a moment :)
<katco> dimitern: not a problem, please take your time :)
<dimitern> katco, so for v2 we can do that later I guess (drop the special signing and leave the post-jan-2014 one only)
<dimitern> katco, for v3 we need to make it work as needed, because we'll be switching to v3 pretty soon
<katco> dimitern: you're talking goose versions now?
<dimitern> katco, no - about goamz
<katco> dimitern: ack sorry... wires crossed. that's what i meant :)
<dimitern> katco, ok, sgtm then
<dimitern> katco, what's your immediate plan?
<katco> dimitern: so some clarification
<katco> dimitern: we want v3 of goamz in juju by this friday for the feature freeze
<katco> dimitern: this is to support efforts in the china region
<katco> dimitern: so goamz v3 would drop s3 signing v2 in favor of standard v4, and we would put that into juju by friday
<katco> dimitern: are we on the same page?
<dimitern> katco, sgtm, however I have one request
<katco> dimitern: sure thing
<dimitern> katco, I've already ported what was sensible to port from v1 to v2
<dimitern> katco, would you be so kind to do the same for v2 to v3?
<katco> dimitern: with some guidance, sure. are the change-sets fairly self contained?
<dimitern> katco, it shouldn't be a lot anyway, and I can help
<dimitern> katco, I think so
<katco> dimitern: yeah sure thing then. let me get the live tests working and then i'll work on that
<dimitern> katco, cheers!
<katco> dimitern: same to you! tyvm o/
<katco> dimitern: i would like to buy you a beer in nuremberg :)
<dimitern> katco, \o/ I'll hold you on to this though :P
<katco> dimitern: it will be my pleasure! :D
<dimitern> ;)
<katco> i have a stein that my mom got me... i'm wondering if i should bring it
<jw4> dimitern, wallyworld ; fwiw it seems that go vet in 1.4.2 is saner than 1.4.1
<jw4> dimitern, wallyworld but in any case the PR that *did* land allows you to set the environment variable IGNORE_VET_WARNINGS="some non-zero string" which will cause the pre-push hook to report but not fail on go vet warnings
<dimitern> jw4, that's fine - I'd prefer the flexibility of being able to ignore it, if needed
<jw4> dimitern: yep
<natefinch> ericsnow: yeah, we can pop into moonstone
<ericsnow> natefinch: k
<stokachu> if I wanted to change the hostname during juju kvm creation do i need to modify the cloud-init config for that or is there an easier way
<jw4> fwereade: still working on upgrade steps, but I wanted to get this wip in front of you sooner rather than later: http://reviews.vapour.ws/r/997/
<dimitern> sinzui, I've marked bug 1424695 as duplicate of bug 1424777 as it's caused by the same issue
<mup> Bug #1424695: maas cloud-init cannot download agent from state-server <ci> <maas-provider> <network> <regression> <trusty> <juju-core:In Progress by wallyworld> <juju-core 1.22:In Progress by wallyworld> <https://launchpad.net/bugs/1424695>
<mup> Bug #1424777: local-provider precise failed to upgrade <ci> <local-provider> <precise> <regression> <upgrade-juju> <juju-core:In Progress by dimitern> <juju-core 1.22:In Progress by dimitern> <https://launchpad.net/bugs/1424777>
<sinzui> dimitern, hurray of sorts
* ChanServ changed the topic of #juju-dev to: https://juju.ubuntu.com | On-call reviewer: see calendar | Open critical bugs:  1424695
<dimitern> sinzui, indeed :)
<dimitern> it's like this I believe
* ChanServ changed the topic of #juju-dev to: https://juju.ubuntu.com | On-call reviewer: see calendar | Open critical bugs: 1424777
<stokachu> dimitern: is there a way to customize the hostname during a kvm CreateMachine?
<dimitern> stokachu, I don't know for sure, but I doubt it
<dimitern> stokachu, we're not setting anything specific in cloud-init for hostname
<stokachu> dimitern: is that file generated dynamically?
<stokachu> the cloud-init file
<dimitern> stokachu, well, yes
<dimitern> stokachu, before provisioning a machine
<stokachu> problem is all KVM creations have a hostname of 'ubuntu'
<dimitern> stokachu, that comes from the ubuntu-cloud image IIRC
<stokachu> yea i was hoping there was a way to change that prior to provisioning
<dimitern> stokachu, that's the first time I've heard someone wanting this btw - it's good you've filed a bug for it
<stokachu> it only affects local provider, trying to deploy ceph units, it fails b/c all 3 units have same hostname
<natefinch> mgz: gave you a review, just one minor tweak requested, but otherwise LGTM
<stokachu> dimitern: https://bugs.launchpad.net/juju-core/+bug/1326091
<mup> Bug #1326091: deploying into kvm with local provider, hostnames are not unique <kvm> <local-provider> <juju-core:Triaged> <https://launchpad.net/bugs/1326091>
<dimitern> stokachu, cheers, if it's a blocker for you guys, I'd suggest pinging alexisb
<alexisb> yes stokachu can you plese send me mail
<mgz> natefinch: thanks! I'll adjust and land
<stokachu> alexisb: will do thanks
<stokachu> dimitern: thank you too
<dimitern> stokachu, no worries
<dimitern> wallyworld, if you're still here - http://reviews.vapour.ws/r/998/
<dimitern> ^ fixes the blocker bug
<dimitern> natefinch, axw, others? ^^
<cmars> hi dimitern, updated http://reviews.vapour.ws/r/974/, does it still look good to land?
<natefinch> dimitern: looking
<dimitern> cmars, hey! yes indeed - I've checked it already yesterday
<dimitern> natefinch, thanks
<cmars> dimitern, awesome, thanks for the review!
<dimitern> cmars, np
<perrito666> brb
<natefinch> dimitern: is it possible to have --target-release series package1 package2 package3?   And if so, will that still do the right thing with this code (i.e., they'll be joined by a space as the package name)?
<dimitern> natefinch, no it's not
<dimitern> natefinch, as far as I could understand from apt-get docs
<dimitern> natefinch, and even if it was, it still won't work due to the way cloud-init 0.6.3 passes them to apt-get
<dimitern> natefinch, e.g. "--target-release rel pkg1 pkg2 pkg3"
<dimitern> natefinch, well, actually - sorry, it *is* possible
<dimitern> natefinch, apt-get accepts that, but not cloud-init
<natefinch> dimitern: gah, what a pain in the ass.
<dimitern> natefinch, in reality, --target-release is just a hint to the apt policy engine to decide which candidates to prefer
<dimitern> natefinch, oh tell me about it :) I've been on it since 8 am
<natefinch> dimitern:  I wonder if we should be checking to make sure that they don't do --target-release series pkg1 pkg2  ... but maybe that's being too smart?
<dimitern> natefinch, I have a couple of panics in place if for that reason
<dimitern> s/if//
<dimitern> natefinch, all tests pass - both make check and the live ones I've described
<dimitern> natefinch, I suppose you could argue if 99% of the existing tests pass, it's a bad thing and we need better ones
<dimitern> natefinch, but I'd rather land this and unblock everyone in a few hours, then I'm happy to improve the tests as a follow-up
<dimitern> natefinch, I'm porting the same fix to trunk and fully intend to retry the same live tests before proposing it
 * dimitern is sick of blockers already - let's not add to that :)
<dimitern> katco, still around?
<dimitern> katco, is this ready to land https://github.com/go-amz/amz/pull/27/ ? it looks so to me - if it is, i'll go ahead and merge it
<katco> dimitern: no not quite yet
<dimitern> katco, ok, np
<katco> dimitern: almost there
 * dimitern steps out for a while - will be back soon
<natefinch> dimitern: gave you a ship it
<alexisb> natefinch, can you edit the HA doc now?
<dimitern> natefinch, thanks!
<mgz> man, I got review 999?
<mgz> one off, one off
<jw4> mgz: quick think of something else to PR
<mgz> review please: reviews.vapour.ws/r/999/
<mgz> natefinch: ^
<cmars> is landing still blocked?
<cmars> ok, nvm
<natefinch> alexisb: still view only
<natefinch> mgz: ship it
<alexisb> natefinch, ack, I dont have permission to give you write access we will have to bug wallyworld
<natefinch> alexisb: yeah, figured.  No problem. I meant to ask for write access from him last night and forgot.
<dimitern> cmars, it is, I'm still testing the port of the fix for trunk, but 1.22 should get unblocked at least (not that it matters I guess)
<cmars> dimitern, got it, thanks for fixing!
<dimitern> cmars, np
<dimitern> natefinch, FYI, there's the tech-debt bug 1425245 I filed for your suggestion
<mup> Bug #1425245: improve cloud-init tests after the fix for bug #1424777 unblocks CI <tech-debt> <juju-core:Triaged by dimitern> <juju-core 1.22:Triaged by dimitern> <https://launchpad.net/bugs/1425245>
<natefinch> dimitern: thanks :)
<dimitern> :)
<hazmat> axw: llgoi ever get announced?
 * hazmat switches to pm
<natefinch> thumper: do you have a link to the doc about CLI 2.0?
<natefinch> (asking for a friend)
<thumper> natefinch: it isn't written yet :)
<natefinch> thumper: heh
<natefinch> thumper: thought it was already being worked on
<natefinch> (ish)
<dimitern> natefinch, PTAL http://reviews.vapour.ws/r/1001/ - fix for the blocker for trunk
<dimitern> thumper, ^^
<thumper> dimitern: ack
<dimitern> thumper, I'm waay pas EOD, so I'm going - please add $$fixes-1424777$$ if it's ok
<thumper> dimitern: do you have the link for the 1.22 version?
<thumper> dimitern: and thanks for the fix
<dimitern> thumper, https://github.com/juju/juju/pull/1670/
<thumper> ta
<dimitern> thumper, np
<perrito666> every time I unplug my external monitor my computer hangs... how sad
<thumper> perrito666: tell Trevinho in #ubuntu-desktop
<thumper> perrito666: tell him I sent you :-)
<thumper> perrito666: although I'm not sure he'd be on right now as he lives in Italy
<thumper> perrito666: but is is known to work weird hours
<perrito666> thumper: why that makes me think that I will get something thrown over my head
<thumper> :-)
<thumper> he's a good guy, and one of the current maintainers of unity 7
<perrito666> thumper: anyway I am using vivid,so that is most likely my fault
<thumper> perrito666: assuming you're using unity
<perrito666> thumper: it is unity, version is a mistery, whatever is shipped with vivid
<cmars> why am I still getting "Build failed: Does not match ['fixes-1424777']"
<perrito666> cmars: can I be a smartass?
<perrito666> :p
<perrito666> cmars: jokes aside, that bug must be marked as critical and not fix commited?
<cmars> perrito666, it's fix committed though
<cmars> https://bugs.launchpad.net/juju-core/+bug/1424777
<mup> Bug #1424777: local-provider precise failed to upgrade <ci> <local-provider> <precise> <regression> <upgrade-juju> <juju-core:Fix Committed by dimitern> <juju-core 1.22:Fix Committed by dimitern> <https://launchpad.net/bugs/1424777>
<ericsnow> cmars: it has to be "fixed released" before it's unblocked
<jw4> marcoceppi made this recently: http://juju.fail/status.json
<thumper> cmars: we need to make sure the ci test that it is supposed to fix is actually fixed
<thumper> sinzui: ping
<thumper> sinzui: can we see if dimiter's patch has fixed the precise upgrade?
<cmars> jw4, marcoceppi that's pretty neat
<jw4> cmars: I believe it actually uses the same mechanism the CI bot uses
<marcoceppi> cmars: yeah, I was just about to put a small webpage in front of it, but status.json will always be available for consumption
<marcoceppi> jw4: it does, about to push the code up which generates this page
<jw4> marcoceppi: cool
<sinzui> thumper, it does, but aws is ill, preventing an official blessing, but we are switching everything we can off of aws
<thumper> sinzui: cool
<katco> wallyworld: you around yet?
<wallyworld> yup
<katco> wallyworld: got time for a quick hangout? have a series of s3 questions
<wallyworld> sure
<katco> wallyworld: sweet... 1:1?
<wallyworld> yup
<perrito666> ahaa I believe it chrome that goes crazy when x is resized
#juju-dev 2015-02-25
<wallyworld> sinzui: how soon before we can unblock master by resolving bug 1424777? i think you said dimiter's fix for the cloud-init issue also will address this too
<mup> Bug #1424777: local-provider precise failed to upgrade <ci> <local-provider> <precise> <regression> <upgrade-juju> <juju-core:Fix Committed by dimitern> <juju-core 1.22:Fix Committed by dimitern> <https://launchpad.net/bugs/1424777>
<marcoceppi> jw4: http://juju.fail
<jw4> marcoceppi: beyootiful
<sinzui> wallyworld, I can unblock 1.22 now. we are waiting for master to test, and it is waiting on this to complete and pass http://juju-ci.vapour.ws:8080/view/Juju%20Revisions/job/run-unit-tests-precise-i386/1474/console
<wallyworld> i get a 404 from that url
<sinzui> wallyworld, log in as a developer or admin
<jw4> sinzui: internal canonical developers only?
<sinzui> jw4, yes, sorry
<jw4> sinzui: n/m :)   I think I already asked you so sorry if it feels harassing :-p
<sinzui> jw4, we are just counting down the i386 tests. the aws failure required us to retest the slowest test in the suite 7 times
<jw4> sinzui: eeesh.  out of curiousity where are you moving the bulk of the CI infrastructure?
<jw4> sinzui: I thought I saw you say we were leaving aws for more stuff
<sinzui> jw4, we aren't moving it. the lxcbr0 bug in 1.21.1 killed our old state server. We had to rebuild
<jw4> sinzui: oh, I see
<anastasiamac> katco: thnx for review!
<sinzui> and we have a real vivid machine
<mattyw> thumper, ping?
<thumper> mattyw: hey, whazzup?
<axw> anastasiamac: not sure what you mean by performance of regexp being "not as heavy"? it's a general purpose hammer, it's *definitely* going to be heavier than searching backwards for the last non-digit.
<anastasiamac> axw: i would have thought that go is sufficiently mature that performance will be noticably degraded for lasrger volumes of string comparisons... surely comparing 100 strings with regexp split is not a big deal?..
<axw> anastasiamac: it is not. I pointed out that it's not *currently* a problem, but it could easily become one if someone decides to extract this function. If you can easily (literally the same number of LOC) do it more performantly without loss of readability (I don't think there is any), then I don't see why you wouldn't
<axw> I won't belabor the point, I just don't like seeing regexps used when there's a much simpler (algorithmically) way of solving the problem
<anastasiamac> axw: i have no problem changing the implmentation but m not convinced that there will be any gain as earlier implmentation was written with isdigit logic
<anastasiamac> axw: for ur suggestion to work, there would be a additional if- to cater for empty input string
<anastasiamac> axw: then traversing the string backwards
<anastasiamac> axw: if- last element is digit
<anastasiamac> axw: until non-digit is encountered
<anastasiamac> axw: then extracting first part of input as prefix
<anastasiamac> axw: and then parsing suffix into a number
<anastasiamac> axw: logically
<anastasiamac> axw: it's easier to read - get this 2 parts from string using regex
<anastasiamac> axw: :P
<anastasiamac> s/this/these
<axw> and then check if the number is missing... and then parse to a number.. it's almost identical.
<anastasiamac> axw: :D except for les lines of code :D
<axw> anastasiamac: http://paste.ubuntu.com/10400349/
<axw> anastasiamac: as I said, literally the same # LOC :)
 * axw goes back to reviewing tmpfs
<anastasiamac> axw: :D
<axw> wallyworld: reviewed your tmpfs branch
<wallyworld> ty
<wallyworld> axw: anastasiamac: i did a benchmark and on 20000 splits, regexp takes 0.06s longer. i'm ok with that :-)
<wallyworld> im the regexp code is easier to read, but ymmv
<anastasiamac> wallyworld: i agreee - reg exp is easier to read
<anastasiamac> wallyworld: howver i have detected a regexp allergy in most go programmers towards regexp on other occasions too
<wallyworld> them there is fighting words
<anastasiamac> wallyworld: since most likely skillset of maintaince (and current dev) team is go, mayb idiomatic go is "the path of less resisitance"?
<wallyworld> regexp is nit not idiotmatic Go is it?
<wallyworld> not not i mean
<anastasiamac> no, but the snippet axw pasted above is idiomatic
<axw> anastasiamac: before working with Go, I spent a lot of time working with Java, C, C++ and Python both professionally and non-professionally. this has nothing to do with language choice
<anastasiamac> wallyworld: m on the fence on that but "when in Rome...", sorry "when in Go.."
<axw> it may be that there's some correlation :)
<axw> *I* don't find my version any more difficult to read, but if I'm outnumbered then feel free to revert.
<anastasiamac> axw: i personaly have a thing against string examinations, so will always vote for regexp use in complex cases
<anastasiamac> axw: hwever, here m not feeling the need to come heavy on either side :D
<axw> anastasiamac: sure, I agree. I don't think this is a complex case - I guess we have different cutoff points
<anastasiamac> axw: it's so trivial that m happy to follow either u or wallyworld
<anastasiamac> axw: since u've gone as far as writting a snippet, I thought I;d concur
<wallyworld> i don't mind either way
<anastasiamac> axw: but then wallyworldwen and benchmarked..
<wallyworld> just leave it as whatever is there now
<anastasiamac> axw: wallyworld now i just need a 3rd party, opinion i think :D
<wallyworld> opinion is go with the current diff, it works, and there's bigger things to worry about. i only did the benchmark to satisfy my assumption that regexp doesn't cost that much to use
<anastasiamac> axw: wallyworld: k... :D since neither of u want to **really*** put ur foot down (m having fun here)...
<anastasiamac> axw: wallyworld: and there is more important things to do (thnx ian for executive directive)
<anastasiamac> axw: wallyworld: and this PR has my name on it and I like regexp approach
<anastasiamac> axw: wallyworld: i'll revert
<axw> anastasiamac: ok.
<anastasiamac> axw: tyvm for showing me a way to do awesome string examination tho :D
<wallyworld> gawd, we really need to do this over a beer or 6
<anastasiamac> wallyworld: or a cider...? :D
<wallyworld> i wouldn't revert now, andrew's solution is fine
<wallyworld> yeah, or a cider
<anastasiamac> wallyworld: why not? CI is blocked anyway
<anastasiamac> wallyworld: and looking for flights is killing my buzz - there is no simple route from a ot b
<wallyworld> you decide :-)
<axw> wallyworld: out of interest, what was the input you used to benchmark? :)
<axw> regexp will be slower with a longer prefix
<wallyworld> axw: a shortish string, eg "myservice/12345"
<anastasiamac> axw: wallyworld: i think mayb we should upgrade beer and cider to harder liquor (menn0's scotch?)
<wallyworld> i agree regexp will always be more expensive
<wallyworld> with an approx 30 char string and up to a 6 digit number, it's twice as slow, taking 0.6s total for 20000 strings
<anastasiamac> wallyworld: is this realistic for juju names 30 char string and up to a 6 digit number (m guessing numeric suffix here)
<anastasiamac> wallyworld: ?
<wallyworld> i can't recall if there's a length limit on service/unit names
<wallyworld> most are shorter than that
<wallyworld> sinzui: given the i386 test issues/failures are independent of the precise apt issue fix committed to master, should be unblock master if everything else besides the 386 tests is ok?
<sinzui> wallyworld, We don't know it is independent. I think I need to report a regression in 1.22 or find a way to mak a test that always passed in 1.22 pass again
<sinzui> wallyworld, and master doesn't get unblocked until master passed
<sinzui> passed
<sinzui> wallyworld, I can start master teasting now, but then I don't release 1.22
<wallyworld> ok, 1.22 is more important. but they are independent as far as i can see. the 386 are failing for the same reasons as always, no new failures
<wallyworld> i wish we could just drop i386, it's 2015 after all
<wallyworld> i also wish we had hardware to do more than one series test at a time
<wallyworld> or i guess we'd need another jenkins set up
<beisner> hi wallyworld, ? for ya:   is there a way to destroy an environment but keep the bootstrap node?
<wallyworld> not that I know of right now, but that's coming soon
<wallyworld> thumper: the above will be in 1.23 right?
<sinzui> wallyworld, ec2 healed 4 hours ago
<wallyworld> good :-)
 * thumper looks up
<thumper> wat?
<wallyworld> thumper: destroy env but keep state server
<beisner> wallyworld,  ack, ty.   i thought i had seen someone somewhere in somescript do it a while back, but maybe that was actually a dream ;-)
<sinzui> and the test results for 386 in trusty and precise on other machines also fail
<thumper> wallyworld: not with the current way things work
<thumper> wallyworld, beisner: when we have multiple environments, yes
<sinzui> wallyworld, so unless I can cheat juju shitty test suite, someone needs to change it
<wallyworld> thumper: yeah, that's what i meant
<thumper> wallyworld: not in a nice friendly way
<thumper> it'll be possible but a little awkward
<sinzui> wallyworld, in summary, the 386 tests fail on precise and trusty, and in Hp and aws. that is very bad
<thumper> until we get the new CLI working nicely with it
<wallyworld> sinzui: i may have forgotten, but why do we support 386? would be nice if tests could be non voting tll we can fix
<wallyworld> beisner: see thumper's answer above
<sinzui> wallyworld, ubuntu makes it, and I understand we want to allow 386 clients and many developers wan 386 images to develop with because they are small
<beisner> ok tyvm
<thumper> wallyworld: I fully expect to have multiple environment creation landed in the next day or so
<sinzui> wallyworld, I am fine to drop 386...and we can stop make windows clients which are 386 too
<thumper> under a feature flag
<wallyworld> sinzui: fair enough, 386 clients is one thing, but images, bleah, that is so last century. and what's small in 2015 anyway
<sinzui> wallyworld, take it to alexis so that she goes to ramm. when management says we don't need to support it we are done
<wallyworld> sinzui: yeah, didn't mean to whinge to you, just venting
<sinzui> wallyworld, or as I have said in other bug reports, aws is dropping 386, joyent and hp don't support it so we need to make a decision about the windows case eventually
<wallyworld> who still runs windows on i386? anyone?
<wallyworld> you can't even buy a 386 version of windows since how long ago?
<sinzui> wallyworld, the os is 386
<sinzui> wallyworld, and windows developers don't upgrade often
<wallyworld> really? i thought win 7 was 64 bit
<sinzui> so the reasoning is windows developers need 386
<sinzui> wallyworld, it didn't sell that well
<wallyworld> at least that's what my last 2 laptops shipped with since 6 years ago
<wallyworld> 64 bit
<wallyworld> no 386 to be seen
<sinzui> wallyworld, just change the test suite to only test the client when 386 is involved. or as I suggested in that bug, just skip the two ping tests and we wouls have had a pass 9 hours ago
<wallyworld> rightio, i'll skip those ping tests. the current pinger implementation is flwed anyway
<wallyworld> and we want to replace it
<sinzui> wallyworld, I am rerunning the hp precise 386 test. It had only one failure and the suite is 40 minutes faster than the aws version
<wallyworld> ok, hope it passes
<wallyworld> wow 40 minutes
<wallyworld> how long do the 386 tests take
<sinzui> 140minutes to 2h5m
<sinzui> yeah, it is that bad
<wallyworld> and the and64 ones?
<sinzui> 20-40 minutes depending on the host. ec2 is slower that the slaves or the ppc64el hardware
<sinzui> wallyworld, but consider the arm64 tests, they take 18 hours
<wallyworld> serious, so say 30mins for amd64 and > 4x that for i386
<wallyworld> wft
<wallyworld> sinzui: and you are still trying to get these tests to pass to bless 1.22 right?
<sinzui> wallyworld, aws wont allow you to deploy 386 on a large instance, which is why we built our own
<sinzui> wallyworld, yes to bless 1.22
<wallyworld> sigh
<wallyworld> sinzui: i will ask alexis about dropping support for i386; in the meantime, i will skip the pinger tests in trunk.
<sinzui> +1
<wallyworld> if i need to skip the pinger tests in 1.22 let me know
<wallyworld> man, master should have been unblocked by now
<sinzui> wallyworld, use __jfdi__ to land that
<wallyworld> yep
<wallyworld> sinzui: i'll only skip on i386, vivid will still fail, we need to fix the tests
<sinzui> wallyworld, we don't unblock unitil the whole suite passes. remember that 1.22-beta3 did pass many time on about 2.5 hours. beta4 has NEVER passed and we have retested for hours
<sinzui> wallyworld, you will need to fix those for 1.23 since we know vivid will be in beta
<wallyworld> bug is currently medium, should be high or critical then if vivid is blocked
<sinzui> wallyworld, vivid was a moving target. IT is now close to stable
<wallyworld> i know whole suite needs to pass, but sad that i386 failures block landings
<wallyworld> sinzui: as soon as we add vivid voting tests, the bug can become critical?
<sinzui> wallyworld, yep
<wallyworld> axw: can i please have a trivial review to help unbock master
<wallyworld> http://reviews.vapour.ws/r/1003/
<axw> wallyworld: looking
<axw> wallyworld: done
<wallyworld> ty
 * jam goes to get his car serviced for a while
<wallyworld> sinzui: that pinger test suite is now disabled for i386 on trunk
<sinzui> thank you wallyworld
<wallyworld> sinzui: so, i think it's now about 4 hours or so till trunk is blessed by CI?
<sinzui> wallyworld, I think http://juju-ci.vapour.ws:8080/view/Juju%20Revisions/job/run-unit-tests-precise-i386/1476/console is hung like the 8 previous attempts
<sinzui> wallyworld, I will let this revision fail so that master can start testing
<wallyworld> sinzui: i can backport to 1.22 if that helps unblock the 1.22 release
<sinzui> wallyworld, or someone before you wake
<wallyworld> i'll do it now
<thumper> jam: hey, you around yet?
<thumper> fwereade: ping goes for you too?
 * thumper will try to remember to pop in later tonight to poke jam and fwereade
<wallyworld> sinzui: 1.22 fixed also now
<sinzui> wallyworld, fab. My last test run I setup is at its hanging spot. I don't have a lot of hope to a last minute pass
<wallyworld> let's hope it passes now
<anastasiamac> axw: wallyworld:jam: m tak n hammer to my solution for status sort and re-writting it in a proper string-walking-full-proper-natural-sorting way to avoid concerns :D
<anastasiamac> axw: wallyworld:jam: i'll poke u when it's ready :) tyvm for ur points and interest :P
<jam> anastasiamac: k
<jam> I'm actually playing around with a strnatcmp go library
<jam> cause I like the function
<jam> and I found a bug in the C implementation
<anastasiamac> jam: :D sorting is fun and finding bugs is just a s much fun as finding solutions
* ChanServ changed the topic of #juju-dev to: https://juju.ubuntu.com | On-call reviewer: see calendar | Open critical bugs: None
* ChanServ changed the topic of #juju-dev to: https://juju.ubuntu.com | On-call reviewer: see calendar | Open critical bugs: 1424777
<dimitern> wallyworld, ping
<dimitern> waigani, I doubt you're here, but if you are PTAL: http://reviews.vapour.ws/r/1006/
<dimitern> fwereade, and you? :)
<dimitern> dooferlad, hey there
<dimitern> dooferlad, how goes the port of the fix for bug 1420049 to trunk?
<mup> Bug #1420049: ppc64el - jujud: Syntax error: word unexpected (expecting ")") <deploy> <openstack> <regression> <uosci> <juju-core:In Progress by dooferlad> <juju-core 1.22:Fix Committed by axwalk> <https://launchpad.net/bugs/1420049>
<dooferlad> dimitern: a bit slow. Have some tests failing that I wasn't expecting.
<dooferlad> dimitern: Hopefully not much longer
<dimitern> dooferlad, if you paste some logs I might be able to help
<dooferlad> dimitern: Hasn't come to that yet, but I will do if I feel stuck.
<dimitern> dooferlad, ok, np
<wallyworld> dimitern: i, just got back from soccer
<wallyworld> hi
<dimitern> wallyworld, hi, it's ok I wanted you to have a look at http://reviews.vapour.ws/r/1006/ if you're around, but decided to land it
<dimitern> wallyworld, it just disables some openstack tests on ppc64el
<wallyworld> dimitern: ok, i did the same thing with some pinger tests on i386
<dimitern> wallyworld, and btw that branch you landed to disable pinger tests
<wallyworld> to try and get trunk unblocked
<dimitern> wallyworld, I think you disabled the wrong one
<wallyworld> oh :-(
<dimitern> wallyworld, most of the failures I've seen are in rootSuite.TestPingTimeout (root_test.go) - not in pinger_test.go
<wallyworld> i thought i went by what the bug mentioned
<dimitern> wallyworld, however, surprisingly after your change that test also started passing :)
<wallyworld> good :-)
<wallyworld> dimitern: i just cecked the bug, and it did mentioned pinger_test. it also mentionedroot_test
<wallyworld> but i tried just the pinger_test first
<dimitern> wallyworld, yeah, it's ok - if some other pinger tests start failing on i386 I'll submit another PR to disable them
<wallyworld> these openstack tests, are they new failures?
<wallyworld> they seem like old tests which have been there for a while
<dimitern> wallyworld, no, they're there since the beginning
<wallyworld> so why the issues now all of a sudden
<dimitern> wallyworld, and also reproducible on gccgo/amd64
<dimitern> wallyworld, well, they were not happening on the "deploy" ppc64 jobs, just the run-unit-tests-trusty-ppc64el-lxc
<wallyworld> oh, ok, failed inside lxc
<dimitern> wallyworld, which is non-voting; and looking at the build history this job never ever passed
<wallyworld> dimitern: is there are bug with the correct label so we can track the work to fix those tests?
<dimitern> wallyworld, I've tagged them with ppc64el and gccgo among others
<dimitern> bug 1425242
<mup> Bug #1425242: disable failing provider/openstack tests on ppc64 until we can fix them <gccgo> <papercut> <ppc64el> <reliability> <test-failure> <juju-core:Fix Committed by dimitern> <juju-core 1.22:Fix Committed by dimitern> <https://launchpad.net/bugs/1425242>
<wallyworld> dimitern: we need a bug that's not fix committed
<dimitern> the underlying issue is in goose, i filed an issue there and have a fix in mind
<wallyworld> dinner ready, bbiab
<dimitern> wallyworld, yes - bug 1411818
<mup> Bug #1411818: ppc64el in lxc failure: github.com_juju_juju_provider_openstack_test.localServerSuite <ci> <intermittent-failure> <ppc64el> <test-failure> <juju-core:Triaged by dimitern> <https://launchpad.net/bugs/1411818>
<voidspace> morning everyone
<voidspace> dimitern: TheMue: dooferlad: be with you in standup in a minute
<TheMue> voidspace: heya
<voidspace> laptop issues :-
<voidspace> :-/
<voidspace> TheMue: o/
<dimitern> voidspace, o/
<voidspace> dimitern: TheMue: dooferlad: now I'm installing the hangout plugin!
<dimitern> dooferlad, since michael is here, I'd suggest finishing the bug fix you're working on and putting the other one I've assigned to you on hold for now
<dooferlad> dimitern: will do
<dimitern> dooferlad, ta!
<perrito666> and now, for something completely different, working in a car
<dooferlad> dimitern: http://reviews.vapour.ws/r/985/
<dimitern> dooferlad, looking
<dooferlad> dimitern: thanks!
<dimitern> dooferlad, so the tests now pass - gc and gccgo?
<dooferlad> dimitern: go, yes. I have compiled with gccgo
<dooferlad> dimitern: testing with gccgo now
<dimitern> dooferlad, ok, nice
<dooferlad> dimitern: lots of "error: reference to undefined identifier âtesting.MainStartâ" showing up
<dooferlad> dimitern: I did make clean; go test -compiler gccgo -test.timeout=1200s github.com/juju/juju/...
<dimitern> dooferlad, check if go env -compiler gccgo reports the same as go env
<dimitern> nope that doesn't work
<dooferlad> :-)
<dimitern> dooferlad, try go test -check.v -compiler gccgo inside the worker/provisioner
<dimitern> :)
<jamespage> dimitern, can i get your opinion on https://bugs.launchpad.net/juju-core/+bug/1425435
<mup> Bug #1425435: juju-deployer/jujuclient incompatibility with 1.21.3 <juju-core:New> <https://launchpad.net/bugs/1425435>
<dooferlad> dimitern: same problem
<dimitern> jamespage, I've looked at it, but can't quite tell where is that coming from - is it an api breakage (like the ports not getting populated by the megawatcher I had recently)
<dimitern> dooferlad, ok, I'll pull your branch and run the tests here
<dooferlad> dimitern: is my setup broken?
<dimitern> dooferlad, well, considering I can run them - most likely :)
<dooferlad> dimitern: :p
<dimitern> dooferlad, however, I haven't specifically installed gccgo or configured it
<dooferlad> dimitern: I don't think I have either
<dimitern> dooferlad, what's your golang-go package coming from?
<jam> fwereade: just checking in to see how you and leader elections are going
<dooferlad> dimitern: https://golang.org/dl/
<dooferlad> dimitern: though I am on 1.4.1 and 1.4.2 is out
<dimitern> dooferlad, ah, that's probably it
<fwereade> jam, just figured out how to deal with potentially abusive tracker clients, hopefully pushing that for review in a mo; would you give http://reviews.vapour.ws/r/987 another pass please?
<dimitern> dooferlad, I'm using golang-go from the trusty archive (1.2.1 - same as the CI jobs use)
<jamespage> dimitern, maybe - but that's breaking all our automated testing right now
<dimitern> jamespage, any idea what jujuclient is trying to iterate over that happens to be None?
<fwereade> jam, just added a couple of comments to http://reviews.vapour.ws/r/987/ -- will be adding a bug# for the open issue and would like to land after that?
<jam> looking through it now
<jam> fwereade: lgtm
<fwereade> jam, <3
<fwereade> jam, had to change around the Tracker interface a bit -- it now issues its own Tickets which you Wait() for, rather than letting people pass their own channels in, because that eliminates a whole class of abusive client behaviour of the sort that has always bugged me about watcher
<jam> fwereade: because you may not listen on your own channel and get the Tracker stuck?
<fwereade> jam, essentially yes -- I think it's possible to work around that, but annoyingly complex
<fwereade> jam, I was trying to write a TestAbusiveClient and not having a very good time ;)
<jam> fwereade: or too good a time.... :)
<fwereade> jam, haha
<dimitern> dooferlad, reviewd
<dimitern> reviewed*
<voidspace> dimitern: ping
<voidspace> dimitern: I need to understand what you mean by "Clean up MAAS container addressability methods"
<dimitern> voidspace, hey
<mgz_> dimitern: can I get you to take a look at bug 1425435
<mup> Bug #1425435: juju-deployer/jujuclient incompatibility with 1.21.3 <api> <network> <regression> <juju-core:Triaged> <https://launchpad.net/bugs/1425435>
<voidspace> dimitern: note that as I'm working from my laptop I don't have MaaS setup here. (Back to desktop next week - but Delia will probably have the baby by then)
<mgz_> (deal with voidspace first :)
<voidspace> dimitern: ok, sure - np
<voidspace> oh, that was mgz_ to dimitern not dimitern to me :-)
<dimitern> voidspace, I'll go back to you in a bit
<voidspace> dimitern: ok, np
<voidspace> dimitern: ah, having read the card properly I understand better anyway
<dimitern> mgz_, I've asked jamespage for details -  any idea what jujuclient is trying to iterate over that happens to be None?
<dimitern> voidspace, cheers :)
<voidspace> dimitern: I'll just get on with it and complain if I get stuck
<dimitern> voidspace, thanks!
<mgz_> dimitern: I'll pastebin you the code
<mgz_> it's in lp:python-jujuclient
<mgz_> basically, using the allwatcher
<dimitern> mgz_, is it about ports then?
<dimitern> mgz_, it is - I can see it now at the end
<mgz_> dimitern: http://paste.ubuntu.com/10406919/
<mgz_> the d argument there comes from the watcher
<dimitern> mgz_, so first off, the client needs to change and start using the port ranges instead
<mgz_> so, would be trivial to fix there in the python
<mgz_> but we should *not* be breaking apis in stable releases
<dimitern> mgz_, then second, looking at the code - why it's not iterating over tports if it cares to setdefault on them
<mgz_> and both your branch and franks seemed to attempt not to do that
<mgz_> tports is the output
<mgz_> ports is the input from the watcher
<dimitern> mgz_, that's the third point :) yeah - that was a backwards incompatible api change, but IIRC frankban fixed it even in 1.21
<mgz_> dimitern: right, one of those branches did not in fact work
<dimitern> mgz_, ah, ok
<dimitern> mgz_, I'll look into what landed etc.
<mgz_> or we released the wrong thing, or something
<dimitern> mgz_, jamespage, where did you get the 1.21.3 binary from? is it definitely 1.21.3?
<jamespage> yes
<jamespage> ppa
<mgz_> allwatcher is named megawatcher now right? I'm not up to date on watcher terminology
<dimitern> mgz_, jamespage, well the fix for that landed in 1.21 almost 2 weeks ago - https://github.com/juju/juju/pull/1595, and it was confirmed to work with the GUI after the fix
 * dimitern doesn't get it
<mgz_> dimitern: my assumption is the gui does in fact work, but this use of python-jujuclient doesn't
<mgz_> it could also be we're not actually on the right version somehow
<dimitern> mgz_, well, part of the reason why this was discovered in the first place is that the gui started throwing exceptions like that (I think it was juju-quickstart actually)
<mgz_> that change is certainly in 1.21.3 as far as I can see
<dimitern> mgz_, and after the fix it worked - without changing quickstart AIUI
<dimitern> jamespage, mgz_, I'm asking in #juju-gui for clarification
<mgz_> dimitern: thanks!
<mgz_> I agree it looks like frankban's change was aimed at covering all this
<mgz_> and I didn't see anything obviously wrong eyeballing the backport diff
<dimitern> mgz_, yeah - and python-jujuclient didn't have to change after the fix landed
<TheMue> dimitern: I wonderfully found three different ways of bson names: lowercase, lowerCamelCase, and dash-case. :) in our portsDoc we e.g. use dash-case opposite to the other network types :/
<dimitern> TheMue, well :) we have to live with what already has bson tags, but for new ones let's use the first case
<TheMue> dimitern: yes, that's what I've done. it's only funny when you grep "type .*Doc struct" on state and scan those types
<dimitern> :)
<dimitern> people keep hitting issues with the 1.21 series, most of which are already resolved with 1.22 and later
<dimitern> we need to release 1.22.0 already and call that stable
<dimitern> jamespage, I think I may have found the issue - are you upgrading to 1.21.3 or you're bootstrapping a new environment with 1.21.3?
<anastasiamac> jam, axw, wallyworld: updated natural order sort (catering a lot beta, i think even floating points vs IPs)
<wallyworld> wow ok, did we need all that extra?
<anastasiamac> jam: axw:wallyworld: not catering for scientific notations :D not negative numbers
<wallyworld> was just for a quick status sort fix right?
<anastasiamac> wallyworld: well, we wanted natural sort for any string not just by numeric suffix
<anastasiamac> wallyworld: any string containing numbers...
<wallyworld> ok, np, if we need it. i was thinking we'd wait till needed before expending the effort
<dooferlad> dimitern:  jujubot isn't landing my code because it doesn't fix https://bugs.launchpad.net/juju-core/+bug/1424777 which you already did (https://github.com/juju/juju/pull/1673)
<mup> Bug #1424777: local-provider precise failed to upgrade <ci> <local-provider> <precise> <regression> <upgrade-juju> <juju-core:Fix Committed by dimitern> <juju-core 1.22:Fix Released by dimitern> <https://launchpad.net/bugs/1424777>
<jam> anastasiamac: https://github.com/jameinel/strnatcmp/tree/master/src/strnatcmp
<dooferlad> dimitern: who can assist jujubot in understanding?
<mgz_> dimitern: it was an upgrade to 1.21.3
<jam> anastasiamac: where is your version, I seem to be missing it in reviews.vapour.ws
<mgz_> I think
<jam> ah, just at the end
<mgz_> but he just tried with a fresh deploy and it got the same error
<mgz_> 1.21.3 client and 1.21.3 server
<rick_h_> jam: morning, did the guys get you the macaroon info you needed for that spec review for the new CS api spec and did that make sense?
<anastasiamac> jam: i kind of disagree with skipping spaces... i think that "1 a" and "1a" may need to b treated differently..?
<jam> anastasiamac: my one concern about unicode.IsDigit() is that what do we do about numbers that aren't 0-9, is it actually valid to mix non-latin chars
<dimitern> dooferlad, it's fine - the blocker will be lifted when the bug is Fix Released
<dooferlad> dimitern: ah, OK.
<jam> anastasiamac: you also don't check how "foo01" sorts compared to "foo2"
<dooferlad> dimitern, voidspace: So, about this MAAS code cleanup. There was talk of pairing. I am available now for a little over an hour.
<dimitern> dooferlad, ok, voidspace how about you?
<mgz_> dooferlad: wanted a clean run with dimitern's fix but the maas jobs are failing atm: <http://reports.vapour.ws/releases/2380>
<jam> anastasiamac: I kind of like the idea of 'foo 1' and 'foo    2' and 'foo 3' sorting accordingly
<mgz_> dooferlad: I'm reasonably sure that's our problem, not a regression on trunk, but want to check
<jam> I don't think *humans* think of number of spaces as significant for sorting most times
<dooferlad> mgz_: thanks for that info.
<anastasiamac> jam: just did a test for []string{"foo2", "foo01"} and got []string{"foo01", "foo2"}
<anastasiamac> jam: is it not right?
<perrito666> hey, still locked? :(
<jam> anastasiamac: I didn't say anything about your correctness, just that it wasn't tested. :)
<anastasiamac> jam:jam oh :D i'll add testnaturallyfoo :D
<jam> anastasiamac: probably the big difference implementation-wise is that mine does a single pass, though yours might do only 2 passes
<jam> it definitely does 2, and it chops the string up (though in go that could be a cheap splicing implementation, though I *think* it actually allocates a new array?)
<anastasiamac> jam: sounds gr8 :D plz propose and let's plug it before feature freeze :)
<anastasiamac> jam: r u goingt to propose it to utils?
<dimitern> mgz_, from what I can see - all of the listed failing jobs haven't tried my fix (6742f589e738eb94b514463438893f7a90a75939), but are struggling on the previous one (a1a088dd000ae742c4bf70f95a2b942068b41be5)
<dimitern> (that's for 1.23 - for 1.22 is better)
<mgz_> yeah, 1.22 went through
<sinzui> dimitern, natefinch 1.22 is failing because unit-tests time out. I don't even know what to put in the bug report yest
<sinzui> dimitern, natefinch : I have lowered the number of retests for i386 so that 1.22 can quickly fail so that we can test and unblock 1.23 (master)
<dimitern> sinzui, I vote to skip these failing tests in cmd/juju/ for i386
<jam> anastasiamac: ... well one difficulty with yours and a 10000 digit string is that ParseFloat aborts :)
<jam> I don't know whether that actually matters
<sinzui> dimitern, natefinch I am fine with skipping tests in 386. The failures are different in hp/aws precise/trusty too.
<anastasiamac> jam: m very happy with urs :D r u plan n to propose it? :P
<jam> anastasiamac: well, I was trying to figure out if the performance actually is different, main problem comparing them is that yours is only defined in terms of sort, vs a compare
<jam> at least your big O for lots of parts should be ok
<jam> anastasiamac: anyway, not today, as I'm way past EOD and need to make dinner
<jam> anastasiamac: I would say that at the least your natural sort code shouldn't live in "cmd/juju"
<anastasiamac> jam: m not comfortable with mine being a util for any purpose (besides performance, I can think of cases that rn't catered 4...)
<TheMue> dimitern: the cleaning is in for review at http://reviews.vapour.ws/r/1009/
<dimitern> TheMue, thanks, will look in a bit
<TheMue> dimitern: ta
<perrito666> natefinch: ericsnow I am caught with other things, Ill be missing standup today
<natefinch> perrito666: ok
<sinzui> dimitern, your ppc64el+lxc fix works. we have a pass for run-unit-tests-trusty-ppc64el-lxc
<dimitern> sinzui, for the first time ever! :)
<perrito666> sweeet
<voidspace> dooferlad: just missed you before, I'd just gone on lunch!
<alexisb> voidspace, heya
<alexisb> voidspace, what is the baby status?
<voidspace> alexisb: hi
<beisner> dimitern, fyi, also affected by this, added workaround to https://bugs.launchpad.net/juju-core/+bug/1425435
<mup> Bug #1425435: juju-deployer/jujuclient incompatibility with 1.21.3 <api> <network> <regression> <juju-core:Triaged> <https://launchpad.net/bugs/1425435>
<voidspace> alexisb: baby still in womb
<voidspace> alexisb: due for final release tomorrow...
<alexisb> exciting
<voidspace> alexisb: maybe delayed for last minute bug fixing, we'll see
<voidspace> alexisb: yeah, really looking forward to meeting the new creature. To the actual birth itself not so much...
<ericsnow>  voidspace \o/
<voidspace> ericsnow: hi
<ericsnow> voidspace: I'm so happy for you!
<dimitern> beisner, thanks!
<alexisb> voidspace, totally understand, but it is soooo worth it
<voidspace> ericsnow: thanks
<voidspace> alexisb: yep
<alexisb> dimitern, beisner does that mean 1425435 is a deployer bug?
<alexisb> I should say a result of a deployer bug?
<ericsnow> if anyone has a spare few minutes, I could use a review on http://reviews.vapour.ws/r/1002/
<beisner> alexisb, i'd call it a python-jujuclient bug since that's where a 1-liner fix can be made.
<alexisb> beisner, ack
<alexisb> mgz_, where does that leave us with trunk being blocked?
<beisner> alexisb, but i'll defer to dimitern & co. who are more familiar with these things ;-)
<dimitern> alexisb, I don't know what it is anymore - it's the same issue as bug 1420403 which was fixed (confirmed and released)
<mup> Bug #1420403: juju-quickstart: bad API server response: 'NoneType' object is not iterable <api> <ci> <network> <regression> <juju-core:Fix Released by frankban>
<mup> <juju-core 1.21:Fix Released by frankban> <juju-core 1.22:Fix Committed by frankban> <juju-quickstart:Invalid by frankban> <https://launchpad.net/bugs/1420403>
<dimitern> beisner, the root cause was a backwards-incompatible api change in juju
<mgz_> alexisb: hoping to unblock shortly - getting a ci run against master is pending, have been tied up on 1.22 and slow i386 test job
<dimitern> but that bug ^^ fixes it, and it's not reproducible anymore with juju-quickstart, which also uses python-jujuclient
<alexisb> mgz_, thanks and please reach out asap if things are still blocked
* ChanServ changed the topic of #juju-dev to: https://juju.ubuntu.com | On-call reviewer: see calendar | Open critical bugs: 1424777 1425569
<sinzui> dimitern, and we test quickstart with every revision on maas, hp, joyent, and aws. We get passes
<dimitern> sinzui, yeah - I've verified everything I can think of, even rebuilding 1.21.3 from the tag and comparing the md5sum in the stable ppa for amd64/trusty - they don't match, but that might be because my setup is different
<dimitern> I'm still not convinced despite the version is 1.21.3, but I'm experimenting now to see what I get out of the megawatcher as UnitInfo changes
<sinzui> dimitern, natefinch : I reluctantly reported a regression in the 386 test suite. I gathered a lot of logs both the official tests and the test we prefer to run. bug 1425569
<mup> Bug #1425569: i386 unit-tests fail <ci> <i386> <precise> <regression> <test-failure> <trusty> <juju-core:Triaged> <juju-core 1.22:Triaged> <https://launchpad.net/bugs/1425569>
<dimitern> sinzui, I have an almost ready solution for this - disabling a few tests on 386
<sinzui> +1
<dooferlad> voidspace: time to hack on MAAS stuff?
<voidspace> dooferlad: I think I still need some clarification from dimitern
<voidspace> dimitern: I've read through your changes to EC2 a couple of times
<voidspace> dimitern: whilst updating my vm etc, etc, etc *sigh*
<voidspace> dimitern: I've added the environs.NetworkingEnviron interface check to the maasEnviron as that looks good
<voidspace> dimitern: the rest of your changes are just logging improvements and general improvements, right?
<voidspace> dimitern: no actual api changes
<voidspace> dooferlad: did you manage to get container addressability working with MaaS?
<voidspace> dooferlad: or alternatively, work out why it doesn't work
<voidspace> dooferlad: because that's even more important than the cleanup I would think
<voidspace> dooferlad: we can pair on that
<dimitern> voidspace, right
<voidspace> dooferlad: you can "drive" as I don't have maas on this machine
<voidspace> dimitern: ok, cool
<voidspace> dimitern: just checking I wasn't missing something important
<dimitern> voidspace, most of them are logging/error messages reporting, however the important bits are in the tests
<voidspace> ah
<voidspace> I didn't read the tests thoroughly, they looked mostly like consequences of error message changes
<voidspace> and who cares about tests anyway...
<dimitern> voidspace, maas should return 95% the same result of NetworkInterfaces() as EC2 (same fields set)
<voidspace> ah right
<voidspace> dimitern: ok, so that's worth double checking and we can pair on that
<dimitern> voidspace, e.g. ConfigType: Config.DHCP, Address is set to the first NIC's address, ExtraConfig: nil, GatewayAddress - nil
<voidspace> I did see those changes
<voidspace> in the tests
<voidspace> cool
<voidspace> dooferlad: ^^ you get all that?
<voidspace> dooferlad: have you seen dimitern's branch?
<voidspace> dimitern: thanks
<dooferlad> voidspace: I have seen his branch. I had a similar impression to you :-)
<dimitern> voidspace, well, maas can actually set both the interfaceName and vlanTag fields of InterfaceInfo / SubnetInfo
<voidspace> yep
<voidspace> dimitern: it should have what EC2 has as a minimum
<dooferlad> voidspace: Seems like there are only minor changes in tests as well.
<voidspace> dooferlad: the important thing to check is that the maasEnviron fills in the fields in the same way as EC2
<voidspace> dooferlad: and those are now checked explicitly in the tests
<dimitern> voidspace, but otherwise, think about how are the networkingEnviron methods in maas behaving - i.e. same(or similar) errors returned for same/similar things, etc.
<voidspace> (and ConfigType.DHCP is actually a change for EC2 - we'll need to check for MaaS)
<voidspace>  e.g. ConfigType: Config.DHCP, Address is set to the first NIC's address, ExtraConfig: nil, GatewayAddress - nil
<dooferlad> voidspace: Are we talking about https://github.com/dimitern/juju/compare/ec2-cleanup-addressability ?
<voidspace> dimitern: I think we're good on that front, worth checking though
<voidspace> dooferlad: yep
<dimitern> voidspace, cheers, I'll go back to chasing bugs then :)
<voidspace> dooferlad: so in terms of pairing, I have just under two hours left before I EOD (after I get coffee)
 * TheMue is afk for a moment, bbiab
<dooferlad> voidspace: OK. See you in a moment. I need to reboot so I can enable virtualisation in my BIOS
<voidspace> dooferlad: one of us should have the EC2 code (dimitern's branch) open and the other the MaaS code and then we can go through both and check that behaviour is the same for both
<voidspace> dooferlad: cool
<dooferlad> voidspace: ready when you are
<voidspace> dooferlad: ok, team hangout?
<dooferlad> voidspace: sounds good
<voidspace> dimitern: ping
<voidspace> dimitern: you said, for MaaS NetworkInterfaces method (InterfaceInfo) "Address is set to the first NIC's address"
<dimitern> voidspace, ah, right you got me
<dimitern> :)
<voidspace> dimitern: I assume you meant "Address is set to the NIC's first address"
<dimitern> voidspace, correct
<voidspace> :-)
<voidspace> dimitern: so parse the CIDR and just return the IP part of the cidr?
<voidspace> dimitern: is that adequate?
<voidspace> ParseCIDR(...).IP.String()
<voidspace> with appropriate error checking
<dimitern> voidspace, I think so
<voidspace> dimitern: cool
<voidspace> dimitern: is it ok to skip ProviderID on MaaS?
<dimitern> voidspace, if the result is a valid address
<voidspace> dimitern: we don't have it currently
<voidspace> dimitern: it must be a valid address
<dimitern> voidspace, for the NIC you mean?
<voidspace> dimitern: yes
<dimitern> voidspace, yes - it's not available on maas, but ProviderSubnetId is
<voidspace> dimitern: right, we fill that in
<dimitern> voidspace, +1
<alexisb> so folks what do we need to do to no longer be blocked by 1424777?
<dimitern> alexisb, first 1.22 needs to pass, and a few tests were failing or hanging on i386 since yesterday
<dimitern> alexisb, I've talked with sinzui about access to a i386 to test, and I'm about to propose a PR to skip certain tests on i386 so 1.22 can pass and then 1.23 can pass and get unblocked
<dimitern> at least that's the plan
<sinzui> dimitern, and I endorse the plan
<dimitern> sinzui, I'm waiting for the full suite to pass on the i386 machine and then proposing
<sinzui> dimitern, sorry, that takes so long. As for CI we are also waiting for the last two tests to complete, then we can test master
<dimitern> sinzui, ok, I'm proposing then
 * perrito666 is surprised that most big cities of his province are flooded, including his, and he still has power and internet... I feel so 1st world :p
<sinzui> perrito666, meanwhile abentley is not in his house because Toronto wasn't as first world as he hoped
<perrito666> sinzui: amazing
<sinzui> Once the glaciers melt and London and New York are flooded, we will all be equal
<perrito666> oh no, I live in high ground in the middle of the continent, mi city just floods because of improper sewage
<alexisb> dimitern, sinzui thank you
<dimitern> alexisb, np
<dimitern> sinzui, fix proposed and set to land https://github.com/juju/juju/pull/1683
<sinzui> dimitern, let's not add $$merge$$ until we see master start testing
<dimitern> sinzui, :( I already did btw
<dimitern> sinzui, but feel free to stop the merge job
 * dimitern hates fixes in a hurry
 * dimitern steps out for 30m
<sinzui> dimitern, I am going to cheat and that 1.22 out of list of branches to test for a few minutes
<sinzui> dimitern, natefinch : we have new information about deployer bug https://bugs.launchpad.net/juju-core/+bug/1425435/comments/5
<mup> Bug #1425435: juju-deployer/jujuclient incompatibility with 1.21.3 <api> <cts> <network> <oil> <openstack> <regression> <uosci> <juju-core:New> <https://launchpad.net/bugs/1425435>
<thumper> fwereade: ping
<thumper> sinzui: what's the reason the bot is still blocked?
<sinzui> thumper, master has not passed
<thumper> that particular issue? or other ones?
<thumper> where that particular one is the critical bug still there
<thumper> precise local upgrade
<sinzui> thumper, We are testing dimitern 's fixes now. 1.22 took forever to test because of the i386 regression
<sinzui> thumper, I hope to see a bless in 3 hours
<thumper> ok...
<thumper> cheers
 * dimitern is back
<mbruzek> jog ping
<jog> mbruzek, pong
<thumper-afk> davecheney: hey, I have a number of trivail patches this morning: http://reviews.vapour.ws/r/1012/
<thumper-afk> gah
<thumper> I always forget to change that back
<mbruzek> jog I need some help with the test results for kubernetes.
<mbruzek> jog do you know why the page does not show the past 12 results?
<jog> mbruzek, looking
<mbruzek> jog 8 from yesterday and 4 more from today.
<perrito666> thumper: isnt davecheney out in some gophercon?
<thumper> perrito666: not now
<thumper> perrito666: davecheney was at the india gophercon at the end of last week
<perrito666> ah it was until mon
<jog> mbruzek, do you know the Jenkins job for one of the missing tests?
<mbruzek> jog in the note I sent yesterday
<mbruzek> there were 8 of them.
<mbruzek> http://juju-ci.vapour.ws:8080/job/charm-bundle-test-azure/49/console
<dimitern> and we have a blessed master
<thumper> dimitern: ah finally
<thumper> awesome
<dimitern> it was a marathon ;)
<thumper> davecheney: (or anyone) http://reviews.vapour.ws/r/1013/
<dimitern> the last 3 days
<thumper> dimitern: thanks for all your work on that
<thumper> dimitern: I really appreciate it
<dimitern> thumper, cheers, I'm just glad *now* I can land my stuff as well :)
<jog> mbruzek, the results.json on S3 for all those tests is empty...
<mbruzek> jog can you help me figure out why?
<jog> mbruzek, looking
<dimitern> some of them are still pending I think
<dimitern> but revision-results #2078 passed
<jog> mbruzek, still looking but I suspect bug 1425435, since deployer is being used by bundletester
<mup> Bug #1425435: juju-deployer/jujuclient incompatibility with 1.21.3 <api> <cts> <network> <oil> <openstack> <regression> <uosci> <juju-core:Triaged> <juju-core 1.22:New> <juju-core 1.23:New> <https://launchpad.net/bugs/1425435>
<jog> mbruzek, I'm trying to find what version of Juju these tests run with.
<mbruzek> jog according to the console text  JUJU_VERSION=1.21.1
<dimitern> sinzui, re that deployer bug
<sinzui> why are you awake?
<dimitern> sinzui, is it worth doing a 1.21.4 point release for a fix
<dimitern> sinzui, I'm wired by the blessed master :)
<dimitern> so much to land..
<sinzui> dimitern, I think we need to discuss further. a fixed python-jujuclient is being built now
<alexisb> sinzui, we will get to talk abou tit in 2 minutes :)
<dimitern> sinzui, that will definitely alleviate the issue for the users of python-jujuclient, however juju gui might still have issues (well, provided it's quick enough while deploying things and checking status)
<alexisb> rick_h_, have you looked at this ^^^
<dimitern> anyway,  I have a solid plan about a fix if it comes to that, and for 1.22 and 1.23 there will be a fix
<sinzui> thumper, wallyworld dimitern: I confidently predict a bless for master. I am removing the block queue the mad rush to merge and crash
<dimitern> oh happy days! :)
<dimitern> 68 PRs await
<thumper> 68?
<thumper> holy crap
<dimitern> well, 67 in reality
 * dimitern goes to do some *damn* programming as fwereade would say
<jog> mbruzek, charm-bundle-test-azure/50 certainly is the bug I mentioned above
<mbruzek> jog yeah there are different bugs
<jog> mbruzek, several others such as joyent 45 have "ERROR connection is shut down"... that something we've seen intermittently
<mbruzek> jog that bug reports things are ok with 1.21.1 and that seems to be the version in the log
<jog> charm-bundle-test-azure-50-all-machines-log shows an upgrade occurred from 1.21.1-trusty-amd64 to 1.21.3
<mbruzek> jog good spot.
<mbruzek> dimitern: whit had looked into fixing this in the jujuclient,
<dimitern> mbruzek, that's great, but I think it should also be fixed in juju (at least 1.23) - for the sake of any other client of the api
<whit> +1
<waigani> thumper, cherylj, davecheney: http://reviews.vapour.ws/r/1014/ thanks
<mbruzek> dimitern: looks good
<mbruzek> dimitern: thanks for the information, I look forward to the fix
<dimitern> mbruzek, np
<sinzui> wallyworld, http://reports.vapour.ws/releases show the ugly truth of failures looking at a specific release we know exactly which voting test failed http://reports.vapour.ws/releases/2383
<wallyworld> sinzui: so the failures there are the 386 and vivid issues we know about
<sinzui> wallyworld, well sort of good news for viviid
<sinzui> wallyworld, the lxc based unit tests and vivid machine test don't vote because they aren't reliable...
<sinzui> but vivid machine and ppc64el lxc passed for the first time today
<wallyworld> i wish the 386 tests didn't vote :-)
<wallyworld> that's good news
<wallyworld> i think they were fixing some cloud init issues for vivid?
<sinzui> wallyworld, ubuntu needs to stop making clients agents that people can run in local host....
<sinzui> wallyworld, change juju to refuse to deploy a 386 agent locally
<wallyworld> yeah, i think there needs to be a 386 discussion
<perrito666> hey just back, still locked?
<anastasiamac> perrito666: CI? no:D
<perrito666> anastasiamac: happiness
<anastasiamac> perrito666: dunno... looks more like a mad rush to land to me :D
 * perrito666 tries to color juju's tests output and is completely unsuccesful
<perrito666> anastasiamac: could be :p
<perrito666> anastasiamac: lets say its a long day and still not over
<anastasiamac> perrito666: my merge is queed up and the one that is currently running (if it lands) will conflict with mien :(
<anastasiamac> mine*
<anastasiamac> perrito666: tomorrow is another day :D
<perrito666> anastasiamac: dont remind me :p, tomorrow will start waaaay too close to the end of today
<anastasiamac> perrito666: wait unitl u'd get kids :d there will be no today/tomorrow - just "awake" and "not quiet awake" :D
<perrito666> sinzui: my restore change is queued for landing :)
<sinzui> perrito666, given the mad  rush to merge, there are good odds your change isn't the one that breaks master
<perrito666> sinzui: are you kidding? restore always breaks master
<sinzui> perrito666, but now we have four substrates to test in. In fact I am not convinced restore work in Azure. Well I think it work 1 in 5 tries
#juju-dev 2015-02-26
<anastasiamac> sinzui: considering extended block of ci, is there any word on extension to feature freeze date?
<perrito666> sinzui: can I bail out blaming azure?
<perrito666> sinzui: the good news is, the new restore runs a couple of times faster than the previous one
<sinzui> perrito666, ci will retest with another substrate and it might blame you
<perrito666> something in the order of 4 to 5 times in my machine
<sinzui> anastasiamac, no there are no plans to extend the deadline
<perrito666> sinzui: oh no no, we have to blame the test inorrectly looking for the output and THEN you can blame me
<anastasiamac> sinzui: thnx :D
<rick_h_> alexisb: not looked yet looking
<rick_h_> sinzui: dimitern so we have a plan for the juju-client stuff then? Our guys hit this today and we were just starting to look into it but hadn't nailed down it was the latest release
<sinzui> rick_h_, alexisb and xwwt aren't keen to work on 1.21 given than 1.22 is supposed to be stable.
<rick_h_> sinzui: ok
<rick_h_> I think that's what I told Makyo today was that he should be running the latest 1.22 release
<rick_h_> so we didn't file anything until he upgraded and checked it out
<sinzui> rick_h_, there is a patch for jujuclient and I know a build is circulating. we can put that version in the stable ppa
<rick_h_> sinzui: rgr ok we'll have to vendor that into the GUI/quickstart then. Will add a card.
<rick_h_> sinzui: do you know who's got that build going and where I can watch it?
<sinzui> rick_h_, It would be nice is more stakeholders used the proposed streams since they demanded something inbetween devel and stable
<dimitern> rick_h_, AIUI a patch for python-jujuclient was done- https://bugs.launchpad.net/juju-core/+bug/1425435/comments/11
<mup> Bug #1425435: juju-deployer/jujuclient incompatibility with 1.21.3 <api> <cts> <network> <oil> <openstack> <regression> <uosci> <juju-core:Triaged> <juju-core 1.22:Triaged> <juju-core 1.23:Triaged> <https://launchpad.net/bugs/1425435>
<sinzui> rick_h_, https://launchpad.net/~ahasenack/+archive/ubuntu/python-jujuclient
<rick_h_> sinzui: understand. I think the big thing is that we're running the dev stuff in progress and not the older versions.
<rick_h_> and have been wanting to get our tools into the Juju cross version testing on the QA end vs implementing cross juju version testing on our end
<sinzui> rick_h_, well, we have 3 versions of juju. that is mad. we are months behind in releases, so we never release betas from trunk
<rick_h_> sinzui: understood and agreed
<rick_h_> sinzui: ok, well we've got giu and quickstart releases planned for tomorrow so we'll make sure this dep update gets into them and should have fixes on our ends tomorrow. Thanks for the info/heads up
<sinzui> rick_h_, we deploy the landscape bundle with quickstart with every juju revision we test. Ans we do it on 3 maases, aws, hp, and joyent. We know the current juju liked quickstart
<rick_h_> sinzui: right, the issue here is that it was the older juju that would/shoud have broken correct?
<rick_h_> sinzui: basically the orange boxes lag behind stable a bit and they got bit by it it seems to me
<sinzui> rick_h_, we tested 1.20, 1.21, 1.22 and 1.23 after the issue was reported, but packaging assumes that the set of packages are consistent. Er. juju/stable packages work together, but ubuntu take one package doesn't mean ubuntu has a stable set
<rick_h_> sinzui: ah gotcha
<sinzui> wallyworld, the voting 386 unit-test job passed. The non-voting unit tests jobs did not. We are still good for a release
<wallyworld> great
<perrito666> sinzui: restore merged
<sinzui> noted
 * perrito666 braces
<perrito666> I feel as if we should go celebrate this
<axw> wallyworld: thanks for merging my branch
<wallyworld> axw: no, wanted to get in before the rsh :-)
<wallyworld> np
<jw4> menn0: thanks for merging my branch too :) - I was waiting for all the important ones to land first
<sinzui> wallyworld, in a few minutes, this page will show we have all blesses http://reports.vapour.ws/releases
<wallyworld> \o/
<sinzui> CI is testing 31ca67f now
<perrito666> sinzui: how can i see http://juju-ci.vapour.ws:8080/job/functional-ha-backup-restore now?
<sinzui> perrito666, developers get their own login now to see all and even retest
<perrito666> was there a mail about that?
<menn0> jw4: I merged your branch?
<menn0> jw4: I thought all I did was comment on the PR
<sinzui> perrito666, there wasn't because I don't know how to distribute the password. I am telling everyone who asks
<jw4> menn0, really? Interesting
<jw4> menn0, well it merged
<menn0> jw4: sweet :)
<menn0> jw4: I think I know what happened
<jw4> menn0, interesting discovery...
<menn0> there was already a $$merge$$ somewhere in the comment thread and my comment triggered the bot to look at the PR again. it saw the earlier $$merge$$ and decided to send it off again.
<jw4> yep, that makes sense
<menn0> that's a little bit silly I guess but oh well
<jw4> menn0, not sure if it's a bug or a feature
<jw4> probably the first
<jw4> :)
<menn0> jw4: i can understand why it works that way. otherwise the bot would have to keep state about each PR.
<jw4> menn0, makes sense - if it only looked at the *last* message it may miss the $$merge$$ if someone comments again, and if it looks at 'n' last messages.... where do you draw the line?
<wallyworld> axw: you saw the maas meeting tonight?
<axw> wallyworld: yep
<perrito666> uff I am far down the queue
<menn0> jw4: exactly
<dimitern> jw4, I added the last $$merge$$ btw :)
<perrito666> lol cherylj did you see what reviewboard added to your rev 1000?
<wallyworld> axw: for later when you have a moment http://reviews.vapour.ws/r/1017/
<jw4> dimitern, oh yeah - thanks :)
<cherylj> perrito666: yeah, I did!
<perrito666> cherylj: you got the prize, I wonder if those pop at other numbers :p ill be standind by
<cherylj> perrito666: I was joking with katco when I submitted that review, asking if I get a trophy and it turns out that I do!
 * perrito666 frantically hits refresh on the backup restore jenkins test
<axw> wallyworld: getting a cup of tea, will review your branch when I return
<wallyworld> sure, np
<perrito666> wallyworld: I managed to fix the tests for the uniter in uas_new_statuses branch so if no other tests are broken tomorrow I might add the compatibility layer
<wallyworld> perrito666: awesome, ty
<perrito666> Its near midnight for me so Ill just go to sleep knowing that restore is finally merged
<perrito666> :p
<wallyworld> perrito666: yeah, well done on restore
<perrito666> I have been working on that since vegas :p
<perrito666> that is almost a year
<perrito666> lol
<wallyworld> but now it's done
<perrito666> restore is never done muhahahah
<perrito666> anyhow, good night all
 * thumper needs to go make a coffee
<alexisb> perrito666, well done man!  sleep well
<alexisb> jam, leads call?
<sinzui> wallyworld, thumper looks like gcc/ppc compilation errors quickly merged into master
<wallyworld> sinzui: you mean people had issues in their queued up branches?
<sinzui> yep
<sinzui> we are already broken
<sinzui> I am gathering the log before the curse is revealed in 45 minutes
<sinzui> wallyworld, sort of good news, It is the multiple definition error again
<alexisb> sinzui, we should not be blocking on known gccgo bugs
<sinzui> alexisb, this isn't a known gcc bug the test passed, now it does not
<alexisb> thumper, davecheney we will want to be prepared to triage this asap ^^^
<thumper> sinzui: I thought we were going to have ppc not block?
<thumper> sinzui: the branch that cherylj had reverted before triggers a bug in ppc, but it is a bug in gcc on power
<sinzui> thumper, how can I tell you haven't broken ppc64el again if I cannot use a test suite
<thumper> well... it fails to compile, and it is a gcc issue
<davecheney> alexisb: there is no point in triage
<davecheney> we'll never get the fix merged back into T and V in time
<sinzui> thumper, As Angry as I am I will say nothing triage it as you will
<sinzui> thumper, bug 1425788
<mup> Bug #1425788: multiple definition of http.HandlerFunc <ci> <gccgo> <regression> <test-failure> <juju-core:Triaged> <https://launchpad.net/bugs/1425788>
<sinzui> oops, even my fingers make it critical when I say I wont.
<sinzui> thumper, lower it if you wish
<alexisb> thumper, lower it, sinzui we should revisit this with xwwt and team in the morning
<thumper> alexisb: lowered to high, comment added
<sinzui> good new the bogus link to get windows installer for juju has quadrupled the number of win beta testers, but I doubt they know that version wont work with release streams
<sinzui> thumper, wallyworld axw: Do either of you have a moment to review http://reviews.vapour.ws/r/1018/
<axw> sinzui: done
<sinzui> thank you axw
<mattyw> jam, are you about yet?
<jam> hey mattyw, what's up?
<anastasiamac> wallyworld: r u here?
<lazyPower> o/
<lazyPower> is it possible to disable juju's AZ spread after deployment? running 1.21.3 wgrant is seeing weird behavior out of a havana env when using juju deploy --to zone=foobar
<bradm> its an icehouse environment
<lazyPower> oh right, sorry
<wgrant> Hm, I suppose patching my local juju to ignore the forbidden AZ won't really work, will it.
<wgrant> https://bugs.launchpad.net/juju-core/+bug/1311976 looks relevant
<mup> Bug #1311976: Support environment-specific placement directives in deploy/add-unit <add-unit> <deploy> <maas> <juju-core:Triaged> <https://launchpad.net/bugs/1311976>
<wgrant> Though being able to set the possible AZs would be handy.
<lazyPower> wgrant: and you found the magic answer. so you were right based on our soundboarding
<axw> wgrant: fraid not. you can add a machine to a specific zone and then deploy --to that
<wgrant> Yeah, that's what it seems like I'll have to do.
<wgrant> Thanks.
<bradm> that doesn't seem like a great answer though, you'll end up manually ahving to distribute across the AZ
<axw> bradm: I agree, it's just a workaround
<bradm> is there an existing bug to fix this?  or should we file one?
<bradm> and by we, I mean wgrant. ;)
<axw> bradm: we do have support for failing over to another AZ, so I guess it's just not checking errors well enough.
<axw> bradm: not that I'm aware of
<axw> bradm wgrant: if you would file a bug that'd be good. in particular, I'd like to see machine-0.log, which should have the error we need to check to fail over properly
<wgrant> axw: In this case the instance gets created but the scheduler fails to find a host for it. I'll set up a clean example and attach the log.
<wgrant> Inter-AZ latency is usually multiple milliseconds though, so automatic distribution without a very easy to way to override it on a per-service basis seems like a nasty trap.
<axw> wgrant: oh, if nova isn't erroring then that's unhelpful. we currently check for an error saying that no hosts could be found in the specified zone
<wgrant> axw: Ah, yeah, the nova boot succeeds, but a second or so later nova-scheduler places it into ERROR saying no hosts were valid or something.
<wgrant> "No valid host was found."
<axw> I see, perhaps we should be waiting until the scheduler picks it up.
<axw> thanks
<wgrant> (eg. we couldn't run LP on AWS without manually assigning AZs, because 200 queries to a DB server that was randomly assigned 5ms away is a full extra second on your page load times)
<axw> wgrant: there is an outstanding bug to support AZ service constraints - that would solve that issue, right?
<axw> oh I see, you want LP and the DB in the same AZ?
<axw> there was some work done to allow charms to query AZ properties of remote units, to allow them to self organise
<wgrant> Yeah
<axw> I'm not sure if it's done, or if it's helpful here
<wgrant> Well, I guess eventually I want a DB service and a webapp service with units in both, that prefer to talk to the local units of the other service, but that's more complicated than having one DB service and one webapp service in each AZ and handling the interconnections with relations.
<axw> wallyworld: do you remember what happened with service-level AZ constraints?
<wgrant> (in the specific case that caused confusion here, one AZ isn't usable by my dev tenant at all. but there are more general issues.)
<wallyworld> axw: i think they got dropped? i think we decided placement directives would have to suffice. but can't recall for sure
<axw> wallyworld: mk
<wallyworld> axw: so just skimming, would the behaviour to skip unsuitable az and try another not suffice?
<axw> wallyworld: in this particular case, yes
<wgrant> It would solve today's specific issue.
<axw> wallyworld: but that leaves the performance issue
<wallyworld> and we ave that in aws and openstack now
<wallyworld> right
<axw> wallyworld: yeah, looks like what's in openstack is insufficient
<axw> wallyworld: sounds like we need to wait until the scheduler picks up the node before claiming success
<wgrant> So it's reasonable to file a bug asking juju to detect this and fall back to another AZ?
<wallyworld> i think so
<axw> wgrant: yes, we should be doing it already - just seems to be a bug in the implementation
<wgrant> "nonce":"user-admin:bootstrap"
<wgrant> That doesn't sound very noncey.
<wgrant> axw: https://bugs.launchpad.net/juju-core/+bug/1425808
<mup> Bug #1425808: OpenStack provider doesn't try another AZ if the scheduler fails to find a valid host <juju-core:New> <https://launchpad.net/bugs/1425808>
<axw> wgrant: thanks
<axw> wallyworld: does that belong on 1.23?
<wallyworld> um
<wallyworld> i guess we could say that as it's a bug in an existing feature
<wallyworld> we modelled te implementation om what was done for AWS I think
<wgrant> AWS clients seem to traditionally wait until the instance is started before returning success.
<wallyworld> whereas ours accepts a successful call to run the instance
<wallyworld> which you are saying might transition later to error
<wgrant> Right. I don't know how your EC2 client works.
<thumper> sometimes our code make me weep
<wgrant> Or indeed if EC2's API doesn't bother returning until it's starting.
<wallyworld> we are triaging 1.23 bugs for the first milestone next week
<wallyworld> how important is this?
<wgrant> We're redeploying our cloud in a different way soon to avoid this, partly because it's not really possible to effectively use a recent juju in our existing design.
<wallyworld> gotta go get kid, bbiab
 * thumper is done for the day
<thumper> see ya all tomorrow
<perrito666> sinzui: I am guessing you did not sleep :( is it possible that aws is misbehaving?
<dooferlad> voidspace: hangout time!
<voidspace> dooferlad: yeah, my laptop isn't cooperating
<voidspace> dooferlad: maybe it needs coffee...
<voidspace> dooferlad: with you in a minute
<voidspace> TheMue:  dooferlad: hangout plugin keeps crashing on firefox and safari won't start
<voidspace> TheMue: dooferlad: looks like it's reboot time
<axw> wallyworld: didn't take long for trunk to become blocked again :~(
<wallyworld> indeed :-(
 * anastasiamac crying
<anastasiamac> axw: and juts sorted my PR and got like a 3rd shipit on it :D
<axw> lol
<wallyworld> perrito666: you going to look at restore issue?
<wallyworld> poor anastasiamac is crying
<wallyworld> she wants to land her branch so badly
<anastasiamac> wallyworld: mayb tears of joy?..
<wallyworld> yeah, that's it
<anastasiamac> wallyworld: but yes, landing will be euphoric!
<voidspace> Anyone want me to buy an Ubuntu Phone to bring to the April sprint for them?
<axw> if I hadn't just bought a phone...
<voidspace> :-)
<axw> voidspace: getting yourself one I guess?
<voidspace> axw: yeah, about to order
<axw> cool
<anastasiamac> voidspace: i think i mite want on :D
<anastasiamac> one*
<voidspace> anastasiamac: shall I order you one?
<voidspace> or do you want to think about it
<voidspace> we can share shipping cost if I order now...]
 * axw goes to rescue wife from crying baby
<anastasiamac> voidspace: i was told that we r waiting for them to b legally sold in oz
<anastasiamac> voidspace: i'll skip this time ;D
<voidspace> anastasiamac: cool
<anastasiamac> voidspace: isn't ur new addition due today?
<voidspace> anastasiamac: yep :-)
<anastasiamac> voidspace: \o/ u must b very anxious - why r u not with her?
<anastasiamac> voidspace: ur wife?..
<voidspace> anastasiamac: she's at home 300 metres away. We have no internet at the new house (moved last week) so I'm working from a friend's house.
<voidspace> anastasiamac: no sign of the baby yet...
<voidspace> anastasiamac: she'll ring me if there's any news and I'm less than five minutes away
<mgz> the pile-on after block does have the downside of often reblocking :)
<anastasiamac> voidspace: congratulations on the move! what a busy season for u :)
<voidspace> anastasiamac: yeah, we were hoping to get the move done at least a week earlier but lots of last minute delays on buying the house
<voidspace> a really nice house though, so it's worth it
<voidspace> anastasiamac: and thanks :-)
<voidspace> phone
<anastasiamac> voidspace: !
<anastasiamac> mgz: but ci gets unblocked so rarely - it becomes a md rush to land :P
<mgz> not sure what the plan ob bug 1425788 is
<mup> Bug #1425788: multiple definition of http.HandlerFunc <ci> <gccgo> <regression> <test-failure> <juju-core:Triaged> <https://launchpad.net/bugs/1425788>
<wallyworld> mgz: gccgo bugs are not to be blockers
<wallyworld> a recent gccgo works fine
<wallyworld> bug CI is using an old gccgo
<wallyworld> but
<mgz> well, we're using the pacakged one, but sure, the plan then is backport a newer gccgo
<wallyworld> yeah, but the politics there is huge :-(
<mgz> :)
<mgz> so, it's just backup-restore blocking
<wallyworld> i think so
<mgz> that can probably get fixed today, so should be less of a painful block than the last
<wallyworld> we need perrito666 to look at it, will hopefully be unblocked for tomorrow so we can finish work for 1.23 feature freeze
<mgz> right.
<mgz> worst case, we revert the depraction I suspect
<wallyworld> yep
<wallyworld> we'll have to do that tomorrow if not fixed, but i think there were a couple of commits in that area, will nee dto check
<voidspace> dooferlad: I left some comments on your review
<voidspace> dooferlad: we can't change the subnetSet to a String Set
<voidspace> dooferlad: as the bool value has significance, but map[string]bool is good
<voidspace> dooferlad: I think that's what I did in EC2 but forgot to change EC2 - it means one less cast
* ChanServ changed the topic of #juju-dev to: https://juju.ubuntu.com | On-call reviewer: see calendar | Open critical bugs: 1425807
<sinzui> mgz, can you report a bug about the consistent failure in run-unit-tests-precise-i386 in master
<sinzui> mgz, I retested the vivid job and it passed. The machine was clean too. I cannot explain why it failed repeatedly hours ago
<sinzui> perrito666, While we have consistent failures over two builds, I am retesting the job. I am willing to force it to something like HP or joyent too
<mgz> sinzui: sure
<sinzui> perrito666, also, as ci is locked down, I think we can enable --debug if that will help you.
<mgz> the changes I made to the windows test seemed to have helped
<sinzui> mgz fab. I haven't had time to look yet. I queued the release last night and am now releasing
<perrito666> sinzui: I am doing a backup and restore by hand and getting success, Ill try t run the CI job here
<sinzui> perrito666, well that is good news. are you using aws?
<perrito666> sinzui: yup
<sinzui> perrito666, okay. I just switch the job to be hp.
<perrito666> sinzui: tx
<perrito666> sinzui: a requierements.txt would be a much appreciated asset in the ci tools :)
<sinzui> perrito666, ah, well I have a work-in-progress that will address that
<perrito666> sinzui: :) tx a lot
<perrito666> sinzui: familiar with http://pastebin.ubuntu.com/10429862/ ?
<sinzui> perrito666, no, but I also know that that function changed a few hours ago.
<perrito666> I just bzr pulled and bzr revert-ed
<sinzui> perrito666, I am going to revert that change
<sinzui> perrito666, tip is reverted
<perrito666> tx
<ahasenack> hazmat: around?
<sinzui> perrito666, Looking at http://juju-ci.vapour.ws:8080/view/Juju%20Revisions/job/functional-ha-backup-restore/1538/console, there is a different error
<sinzui> perrito666, do you want me to retry hp?
<perrito666> sinzui: yes, odd one, that means, basically that the bootstrap went wrong
<Muntaner> good morning, devs
<ericsnow> jam: ping
<ericsnow> jam: un-ping
<Muntaner> having problems in running windows-boilerplate with juju, anyone can help me?
<perrito666> this testing suite is going to kill me euca-terminate-instances: error: missing access key ID; please supply one with -I
<perrito666> sinzui:  ^ did I miss something in my test call?
<perrito666> Muntaner: good morning, tell me more
<Muntaner> hi perrito666, I simply downloaded the windows-boilerplate charm
<perrito666> Muntaner: point me to it please
<sinzui> perrito666, I cannot remember if you need to source ec2 creds first. I suppose so since the the key is definitely in the yaml
<perrito666> that is new :)
<Muntaner> perrito666, chatted you in query
<perrito666> natefinch: ericsnow I seem to have forgot standup
<perrito666> ok, if this run does not pass (assuming I didnt forget to set up things) Ill revert the patch
<natefinch> perrito666: heh sorry, thought you were out
<perrito666> nah, dentist was fast and bad, Ill change dentist for the next one :p I was absorbed trying to fix the restore bug
<perrito666> agrjaslkdjaslkjds I hate euca
<sinzui> perrito666, hp failed again, *before* setup. I am going to try another provider since hp doesn't appear to be suitable
<perrito666> I am being frustrated by this euca issue, i just exported EC2_ACCESS_KEY and EC2_SECRET_KEY
<voidspace> ah, I thought it was quiet
<voidspace> I wasn't connected
<alexisb> voidspace, aren't you suppose to be in the delivery room??
<voidspace> alexisb: we're having the baby in a pool at home
<voidspace> alexisb: I'm down the road at a friend's house where we have internet
<voidspace> alexisb: and the baby hasn't made any signs of appearing yet... :-)
<perrito666> voidspace: you have a pool? sweeeet
<voidspace> perrito666: yeah, it will double as a great paddling pool after the birth (and after we've thrown away the lining - it will look like the remnants of a shark attack immediately after!)
<hazmat> ahasenack: i am.. sorry didn't get to it last night was 5hrs on a bus yesterday
<hazmat> ahasenack: or something new?
<ahasenack> hazmat: new
<hazmat> ahasenack: all ears
<ahasenack> let me fetch the pastebin
<ahasenack> hazmat: http://pastebin.ubuntu.com/10430000/
<ahasenack> that with r53 of jujuclient
<hazmat> that looks like an error
<hazmat> in code
 * hazmat checks
<ahasenack> hazmat: it's also a bit confusing where python-jujuclient is hosted. There is a project and branch in launchpad, and another one in github
<hazmat> ahasenack: interesting, its a by product of the py3 support. base class for self there is an interator
<ahasenack> ok
<hazmat> ahasenack: i was hoping to move it to github, but wanted to try and coordinate with the recipes, and setup the foreign branch import
<ahasenack> ok, another issue for another day
<hazmat> yeah
<ahasenack> I switched my builds from lp:~hazmat/python-jujuclient/trunk to lp:python-jujuclient
<hazmat> cool
<ahasenack> I think you had setup the former to be a mirror
<ahasenack> but doesn't matter now
<rick_h_> hazmat: ahasenack so we're working on trying to test and QA the latest python jujuclient and to QA it against quickstart/gui charm so we can update the juju stable ppa
<rick_h_> do we know who has pypi permissions?
<hazmat> sinzui: when you adding a deployer test to qa for core?
<ahasenack> rick_h_: hazmat I suppose, no? He owns it
<sinzui> hazmat not yet
<hazmat> rick_h_: i do
<sinzui> hazmat, we do juju-quickstart with ever revision test against maas 1.7, aws, hp, and joyent
<rick_h_> hazmat: k, we'll QA and then hit you up for a release then? Can we get permission for someone else to help handle uploads due to your network fun?
<hazmat> sinzui: thats a good start, but given the amount of real world production workflows we have with deployer, it needs to be in the qa tests for core..
<hazmat> rick_h_: qa what?
<sinzui> hazmat, I don't disagree, jog was taken off deployer to work on kubernetes
<hazmat> rick_h_: so latest releases should always be on pypi
<hazmat> rick_h_: i'll add one of the lp juju-deployers to pypi perms..
<hazmat> probably tvan
<rick_h_> hazmat: well so there's a ppa with a patch and we're chasing does that patch exist in trunk and is his .19 PPA build from trunk and ok to be in the juju stable ppa
<dimitern> sinzui, are you around?
<hazmat> rick_h_: well gui team doesn't have any extant merges ...
<rick_h_> hazmat: right, this patch came from andreas is my understanding
<dimitern> mgz, or you?
<mgz> dimitern: hey
<dimitern> xwwt, mgz, sinzui, i might have the reason why the restore job fails
<ahasenack> rick_h_: dpb1 merged that patch, I don't know the author. I just rebuilt the packages
<mgz> dimitern: what's your theory?
<xwwt> dimitern: What is your thought?
<rick_h_> ahasenack: ok, so the patch is in trunk then and you're doing a fresh build for juju stable?
<sinzui> dimitern, oh goody. I haven't a clue and gathering evidence is hard
<hazmat> rick_h_: for deployer or client?
<dimitern> xwwt, mgz, sinzui, so I was looking at the logs of the last successful and first failed jobs
<rick_h_> hazmat: python-jujuclient
<ahasenack> rick_h_: no, I don't touch juju stable. it's in my ppa, a daily one for jujuclient. It uses LP recipes
<dimitern> xwwt, sinzui, mgz, and so far I can see at least 3 separate issues
<rick_h_> ahasenack: ok, but that should be good to copy to juju stable then if it qa's ok against quickstart/gui/deployer in there
<rick_h_> ahasenack: as it's an 'official python-jujuclient release'?
<hazmat> rick_h_: yeah..  that patch was outstanding for not a long time.. like two days
<hazmat> afaics
<rick_h_> hazmat: right cool. I'm just trying to unblock us releasing the gui/quickstart with the patched python-jujuclient
<dimitern> xwwt, mgz, sinzui, 1) the mentioned PR https://github.com/juju/juju/pull/1667/ *did* in fact break the job's expectations and as it is it won't be able to ever pass
<rick_h_> hazmat: and to keep people on the juju stable ppa vs the personal ppa of andreas
<dpb1> yes, beisner is the author.  but it's straightforward, just an if clause added to deal with the missing data
<hazmat> rick_h_: yes.. that's great
<hazmat> rick_h_: deployer & client needs help on packaging both for stable ppa and distro
<hazmat> in general
<rick_h_>  hazmat yea, I'm trying to see what we can do with that as we depend on it :)
<sinzui> hurray, dimitern. I can fix a test script, probably quickly
<dimitern> xwwt, mgz, sinzui, that's because the job internally calls "juju restore --show-log [--constraints mem=2G]" etc., while after the patch #1667 landed it doesn't matter how you call it - it internally calls
<dimitern> cmd := exec.Command("juju", "backups", "restore", "-b", "--file", c.backupFile)
<dimitern> which obviously ignores the arguments; 2) issue - https://github.com/juju/juju/pull/1596/ which landed some time ago actually triggers the "/mnt/jenkinshome/jobs/functional-ha-backup-restore/workspace/extracted-bin/usr/lib/juju-1.23-alpha1/bin/juju-backup: line 5: [: ==: unary operator expected"
<dimitern> errors, which in turn (AIUI due to the set -xeu) always fail the job when first run
<ahasenack> rick_h_: with all that said, I'm still seeing an issue with current jujuclient from trunk, r53: http://pastebin.ubuntu.com/10430000/
<rick_h_> ahasenack: ugh ok so trunk isn't ready for release atm
<ahasenack> I think not, I had to downgrade jujuclient and juju-core to get some deploys working today
<rick_h_> ahasenack: ok, is there a bug for this?
<dimitern> that in turn causes the 3) issue - which might be the most minor one - the restore_present_state_server method in assess_recovery incorrectly assumes restore failed early (due to the exit 1)
<ahasenack> right now I'm with jujuclient 0.18.4-5 from juju-stable and core 1.20.11-trusty-amd64 from trusty updates
<ahasenack> rick_h_: not yet, just pasted it to hazmat a few minutes ago looking for confirmation it's something in jujuclient itself
<rick_h_> ahasenack: ok
<dimitern> sinzui, that's the other option - fixing the job to call "juju backups whatever" (new style) instead of "juju restore ..." (old style, before the restore plugin was deprecated)
<rick_h_> ahasenack: please file a bug and we'll start looking into it
<ahasenack> ok
<rick_h_> ahasenack: we need to release the python-jujuclient and so will look into the bug/fix to unblock all this then.
<rick_h_> jcsackett: will look into it hazmat ahasenack ^
<dimitern> sinzui, and *the* better option long term I believe; otherwise we might just apply a hot fix for the stuff landed in #1596 (quote the "$1" in the two ifs there) and #1667 (to properly pass arguments to juju backups, rather than ignoring them)
<jcsackett> ahasenack: hi; when you file a bug on this with steps to repro, can you ping me with it?
<dimitern> xwwt, mgz ^^
<ahasenack> jcsackett: ok
<jcsackett> ahasenack: thanks :)
<sinzui> dimitern, mgz: I am an uncertain. We want to ensure 1.18 compatibility. anyone who scripted the restore will fail as we did
<dimitern> sinzui, that's true - so I would've already proposed the "hot fix" option, but I'm not quite certain about the implications of converting old-style juju restore args to the new-style juju backups - perrito666 might tell if that's sane
<sinzui> dimitern, exactly my conundrum
<dimitern> sinzui, however, I'm not excluding this - because 1.23 *does* deprecate juju restore as plugin, you're expected to see your script job start failing and see why
<dimitern> (as a customer - a bit too presumptuous perhaps)
<perrito666> dimitern: sorry I was paying attention to my terminal
<perrito666> dimitern: have you slept since we last spoke?
<sinzui> dimitern, the problem with deprecation is that Ubuntu wont let you obsolete it. The contract must remain consistent for trusty
<hazmat> rick_h_: yeah.. it something about the super and iterators i did for py3 compat.. investigating
<perrito666> dimitern: that should work ootb
<perrito666> I mean sending the params to new restore
<perrito666> brb, dimitern if yo have said patch push it
<dimitern> perrito666, oh yes, I got a good 10h thanks :)
<dimitern> perrito666, not yet, wanted to check with sinzui and you first
<rick_h_> hazmat: k, jcsackett is tasked to look into it today so we can try to unblock a formal release.
<dimitern> perrito666, but it's should be trivial - I'll get on it now, and ask you for a review
<dimitern> sinzui, as for the i386 tests failing and the ppc64 one - easily skip-able
<hazmat> rick_h_: ok.. in future a little more heads up would be good. i'll work on it some this evening.
<rick_h_> hazmat: I'd love more heads up. We just found all this out last night while watching irc tbh. :)
<rick_h_> hazmat: so trying to respond today
<sinzui> dimitern, +1 for the 386 timeout
<ahasenack> jcsackett: reproduced it with this yaml: http://pastebin.ubuntu.com/10432117/
<ahasenack> jcsackett: bug has the details: https://bugs.launchpad.net/python-jujuclient/+bug/1426020
<mup> Bug #1426020: TypeError: super object is not an iterator <python-jujuclient:New> <https://launchpad.net/bugs/1426020>
<ahasenack> local env, but happened also with maas
<ahasenack> these are the two I tried
<Muntaner> hey guys
<Muntaner> a good guide to get started with writing charms?
<hazmat> ahasenack: thanks
<natefinch> Muntaner: https://jujucharms.com/docs/authors-intro
<natefinch> Muntaner: the navigation on the page is not very obvious, but if you collapse the "User Guide" section of the menu on the left side, you'll see the section for "Charm Authors" and you should just go down that list of links in order.
<natefinch> rick_h_: ^^ Are we going to make navigating these pages easier for people"  They're supposed to be kind of serial, but there's still no way to just go to the "next" page... so for anyone that doesn't already know the layout, actually reading through them can be really frustrating.
<abentley> dimitern, sinzui: Because we are expected to maintain compatibility with 1.18+, I think that the "hot fix" option is the only viable option.  We could test "backups restore" in addition to "restore" if we wanted to, but one doesn't replace the other.
<dimitern> abentley, indeed
<dimitern> abentley, sinzui, in fact after a few tests replicating what the job does the fix turned out to be much smaller than I expected
<abentley> dimitern: Excellent!
<dimitern> 4 characters to be exact :)
 * sinzui awards dimitern  with 4 gold stars ââââ
<dimitern> :D
<mgz> :)
<dimitern> sinzui, let's see if it'll work on CI - http://reviews.vapour.ws/r/1021/ << perrito666
<rick_h_> natefinch: we've nothing on the roadmap for docs other than supporting multiple versions which is in progress. We rely on the docs folks to manage that at this time.
<dimitern> perrito666, sinzui, abentley, should we try landing this? ^^ it least ISTM won't cause more harm if it doesn't work
<natefinch> rick_h_: ok, then, where do I file a bug against the docs? :)
<sinzui> dimitern +1  from me
<rick_h_> natefinch: github.com/juju/docs
<rick_h_> ?
<dimitern> cool, let's roll then :)
<natefinch> rick_h_: ahh, cool, I didn't think to look there... assumed they were using launchpad.  This is much easier
<perrito666> dimitern: but that patches backup not restore :p
<perrito666> dimitern: i think your patch cant harm
<dimitern> perrito666, these missing quotes are the reason for: "juju-backup: line 14: [: ==: unary operator expected: exit 1"
<dimitern> AIUI at least
<perrito666> dimitern: mm, i am not sure, but will take some clutter of the errors so for me go
<coreycb> jw4, hi, what's the status of juju actions these days?  I'm getting hits for "actions" in the git log so I'm getting a good feeling. :)
<jw4> coreycb: they're pink and freshly scrubbed
<jw4> coreycb: we're actually hoping to get the feature flag removed for the code freeze tomorrow
<perrito666> oh ffs, whatever version of euca i am using requires -I and -S
<jw4> coreycb: at which point actions will include a functional basic command line
<coreycb> jw4, awesome!
<jw4> coreycb: and a good set of basic features
<jw4> coreycb: let me see if I can find some documentation on the state of the union. bodie_ do you have any quick doc links handy?
<coreycb> jw4, that's great.  I'll be trying it out soon.   yeah I could use some usage/dev examples or doc if you have them
<perrito666> dimitern: i am about to hit merge in your behalf
<dimitern> perrito666, +1
<dimitern> I thought I already did though :)
<bodie_> jw4, coreycb eh, one sec
<perrito666> you did
<bodie_> coreycb, take a look here https://jujucharms.com/docs/actions
<coreycb> bodie_, awesome, ty
<bodie_> coreycb, you might want to start with the doc for Charm authors, since it explains more about how they work and about the schemas
<bodie_> link on the first line of the Action users doc
<bodie_> coreycb, also, you CAN use them now in juju trunk as long as you export JUJU_DEV_FEATURE_FLAG=actions
<coreycb> bodie_, very good, thanks!
<bodie_> :)
<bodie_> let us know if you have any questions or issues... #jujuskunkworks
<perrito666> sinzui: ok, apparently my credentials are not good for euca :s
<perrito666> sinzui: at this point I would really like to see a run in debug mode, if dimiterns patch does not fix the issue
<mgz> perrito666: are you using the right envvar names?
<perrito666> https://www.eucalyptus.com/docs/eucalyptus/3.2/cli/setting_vars_euca2ools.html
<perrito666> mgz: I actually hacked the parameters into the eua call in the code
<perrito666> hey nice, when its a timeout it gets noticed by jenkins
<dimitern> perrito666, I think I found a deeper issue and that fix won't harm, but not fix the failure
<dimitern> perrito666, look at this: "ERROR could not exit restoring status: cannot complete restore: <nil>: Restore did not finish succesfuly"
<dimitern> perrito666, this nil there is because of the way your api/backups client is calling the apiserver/backups facade methods
<dimitern> perrito666, when you have e.g. func (a *API) Method() error { } defined on the facade, the *correct* way to call it is like func (c *Client) Method() error { return c.facade.FacadeCall("Method", nil, nil) }
<perrito666> dimitern: again?
<dimitern> perrito666, and not: err := client.facade.FacadeCall("Method", nil, &remoteError) \n return err, remoteError << that will always be nil
<dimitern> rogpeppe2 can confirm this ^^
<rogpeppe2> dimitern: sorry, facades were invented after i left juju-core
<dimitern> perrito666, so the signature the apiserver expects from facade methods is listed on rpc.Conn.Serve()'s doc comment
<dimitern> rogpeppe2, yes, but it still holds I think
<perrito666> dimitern: iirc, err is an error in the calling process and remoteError is an error from the facade Method
<dimitern> perrito666, I don't think so - there is only 1 error - the one returned by the remote method
<perrito666> not exactly true, you can have an error in facadecall
<perrito666> dimitern: btw, where did you get that error/
<perrito666> ?
<dimitern> perrito666, compare with apiserver/client.go - DestroyMachines(args) error and api/client.go - calling return c.facade.FacadeCall("DestroyMachines, args, nil)
<rogpeppe2> perrito666, dimitern: if it's anything like it was, the error returned from an API method comes out in the error returned from the client call
<dimitern> perrito666, it's in the log of most failing jobs - e.g. http://juju-ci.vapour.ws:8080/job/functional-ha-backup-restore/1530/console
<dimitern> rogpeppe2, perrito666, considering apiserver/client and api/client are both fairly well tested and we have cases in there where a method returns just 1 error (not results, error)
<perrito666> ah I see it, it is something we need to address eventually but in this case, its a red herring
<perrito666> dimitern: that error is triggered by trying to salvage the machine after a failed restore
<dimitern> rogpeppe2, perrito666, and since I can't see a test for FinishRestore anywhere
<dimitern> that might be the issue - it's just not getting called correctly (or the response is not interpreted correctly on the client)
<perrito666> ffs i cant believe this thing is so hard to run in a local machine
<perrito666> dimitern: I am worried about the:  open /var/lib/juju/agents/machine-0/agent.conf: no such file or directory
<perrito666> error
<perrito666> I cannot find a good reason for that not to exist
<dimitern> perrito666, it comes most likely from state/backups/backups_linux.go:66
<dimitern> perrito666, which leads to updateBackupMachineTag switching dataDirs
<perrito666> dimitern: but the thing is, that IS the right path
<perrito666> Starting Juju machine agent (jujud-machine-0)
<perrito666> so that IS machine 0
<dimitern> perrito666, yeah. newTag and oldTag match
<perrito666> dimitern: yup, that is a workaround so we can deploy backups in ha envs
<dimitern> perrito666, but PrepareMachineForRestore earlier recreated the paths
<perrito666> dimitern: the process is roughly: machine is bootstraped, dirs are nuked, files are uncompressed, files might be moved to match new tag, config is read
<dimitern> perrito666, I think at this point you might consider reverting the removal of juju-restore plugin (#1667)
<perrito666> and t'is driving me crazy, i can do it by hand and for some reason i cannot get this awful ci script to run
<perrito666> agjhaskdjasld
<perrito666> I will
<perrito666> dimitern: on it
<dimitern> perrito666, do what I do in such frustrating moments - ad TONS of logger.Tracef *everywhere*, just in case :)
<dimitern> perrito666, cheers
<perrito666> dimitern: Ill roll down and cry and then do that
<dimitern> :/
<perrito666> and when you cant be frustrated enough... the computer freezes due to lack of ram fml
<perrito666> dimitern: http://reviews.vapour.ws/r/1022/
<perrito666> I really need to move to a country with more upload and amazon shipping
<dimitern> perrito666, :ship it:
<perrito666> dimitern: shipping
<dimitern> perrito666, sweet!
<dimitern> sinzui, ^^ it might get green soon on restore after all
 * dimitern is off again
<perrito666> fix committed
<perrito666> I think I found the issue :D
<perrito666> ericsnow: around?
<ericsnow> perrito666: sure
<perrito666> ericsnow: is it possible that either I took what meta.Origin.BackupMachine is or its returning wrong value
<perrito666> ericsnow: state/backups/backups_linux.go
<perrito666> line 43
<ericsnow> perrito666: what's the error?
<perrito666> sorry I meant meta.Origin.Machine
<perrito666> ericsnow: well, I am assuming that it is the machine where the backup was made, and from that asking restore to update the paths accordingly (from machine-N to machine-M)
<perrito666> buuuut, i am getting the wrong N
<ericsnow> perrito666: it is supposed to the machine where the backup was made
<ericsnow> perrito666: it comes from the API server
<perrito666> ericsnow: is it possible that its not? :p
<ericsnow> perrito666: I'm looking at apiserver/backups/backups.go to see :)
<perrito666> thanks, a second set of eyes are really apreciated
<bodie_> am I confused or has 'fixes-1425807' already been merged yet CI is still blocking? https://github.com/juju/juju/pull/1693
<bodie_> the PR to get Actions exposed for 1.23 is waiting to land before the freeze and I'm sweating... just a tiny bit... maybe two drops of sweat
<perrito666> bodie_: ci running the tests
<ericsnow> perrito666: so the machine ID comes from the apiserver/common.Resources (the "machineID" key) that got passed in to NewAPI by the request handler
<ericsnow> perrito666: so it should match the machine ID of the API server
<perrito666> ericsnow: mmmmmmm
<perrito666> I wonder what that does under HA?
<ericsnow> perrito666: either the resource is incorrect or it did not get serialized properly into the metadata file
<perrito666> do you get the principal one's id?
<perrito666> let  me cut open this tarball
<ericsnow> perrito666: yeah, take a look at the metadata.json file
<ericsnow> perrito666: re: HA, I expect the machine ID is strictly that of the current API server and unrelated to the replicaset
 * ericsnow looks
<perrito666> ericsnow: it is the right ID.. I wonder if I am getting the right one when I ask
 * perrito666 found the error to be there and now chases it
<ericsnow> perrito666: oh, good, I'll stop digging through the tangle of API code :)
<perrito666> ericsnow: thanks a lot
<ericsnow> perrito666: np
<perrito666> ok, and now for something completely different, this bug is not deterministic
 * perrito666 crafts a backup by hand and converts the bug in deterministic
<ericsnow> if anyone care spare some time, I could really use a review on http://reviews.vapour.ws/r/1002
 * thumper tries to ignore the world for 30 minutes and write some tests
<alexisb> abentley, perrito666 are we still blocked due to 1425807?
<abentley> alexisb: We don't have a blessed revision yet.  The last tested was 0872c2cb
<abentley> alexisb: 43bbcb6 is currently being tested.  That is likely to have the fix shown.
<alexisb> abentley, ok
<perrito666> alexisb: I reverted the offending commit and its the ommit after 0872
 * perrito666 is invited to a dinner in 1.5 hour, and wonders if the other people there would have a problem with him running tests while he eats
<thumper> hahaha
<jw4> ericsnow_afk, ungraduated review complete... 1002 LGTM :)
<ericsnow_afk> jw4: thanks!!!
<jw4> ericsnow_afk: I'm afraid all my feedback is trivial and nitpicky
#juju-dev 2015-02-27
<thumper> wallyworld: I'm in our hangout if you are ready early
<wallyworld> ok
<ericsnow> davecheney: I have a question about a review comment you left on our GCE patch
<ericsnow> davecheney: do we have a uniform mechanism for getting a string representation of a machine ID (and not by using a machine tag)?
<ericsnow> davecheney: given the strong correllation between instances and juju machines, using the machine ID in the instance name is valuable
<davecheney> ericsnow: a name for a machine id that isn't a tag ('cos this isn't the api) ?
<davecheney> honestly, not sure
<davecheney> state.Machine.String() ?
<davecheney> ^ total guess
<ericsnow> davecheney: k
<davecheney> menn0: waigani any ideas ?
<menn0> hmm
<ericsnow> davecheney: the alternative is to pick a suitable format to use in the one bit of code (losing any benefits of code reuse)
<menn0> davecheney, ericsnow: don't you just want Machine.Id()?
<menn0> i'm probably not understanding what you're after
<ericsnow> menn0: all I have is the ID as a string (e.g. "0")
<menn0> ericsnow: right
<menn0> ericsnow: and what would you like?
<ericsnow> menn0: currently I'm using names.NewMachineTag and then String() on the result, all to get a standardized representation to use in an instance name
<ericsnow> menn0: I was trying to keep naming consistent with the rest of juju, but it sounds like we don't have another way to get that uniform repr from a machine ID
<menn0> ericsnow: why I don't think there's anything else. A shorter route to the same thing would be someMachine.Tag().String().
<menn0> s/why//
<menn0> if you have a machine instance
<ericsnow> menn0: this code is provider-related, so pretty much it's unrelated (directly) to state
<menn0> ericsnow: ok then, I've got nothing :)
<ericsnow> menn0: no worries :)
<cherylj> ericsnow: I added the function names.ReadableString a while back to do what I think you're looking for
<cherylj> oh wait, that takes a tag too
<cherylj> but I added that in to not print machine tags out on the CLI
<axw> wallyworld: forgot to talk about storage info in 1:1. did you understand what I was getting at in the standup about translating volume/filesystem info to storage info on-the-fly?
<hazmat> ahasenack, dpb1, rick_h_ pushed new py j client w/ iterator fix .. version incr math fixed as well (0.50.1)
<wallyworld> axw: yeah, sounded "ok" at a high level, could you shoot through a tl;dr; email with a quick summary of the implementation?
<axw> wallyworld: sure
<wallyworld> ty
<rick_h_> hazmat: <3 ty kindly. jcsackett should have finished QA and we'll get it into the juju stable ppa tomorrow.
<axw> wallyworld: sent
<wallyworld> ty
<axw> wallyworld: once again without gpg please
<wallyworld> oh ffs
<wallyworld> i gotta find out why thunderbird does that
<dpb1> hazmat: https://bugs.launchpad.net/python-jujuclient/+bug/1426020 need that one too, I'll be landing it soon, but could use your eyes on that patch if it was something you intended another way
<mup> Bug #1426020: TypeError: super object is not an iterator <python-jujuclient:New> <https://launchpad.net/bugs/1426020>
<rick_h_> dpb1: got that in http://bazaar.launchpad.net/~juju-deployers/python-jujuclient/trunk/revision/54
<rick_h_> dpb1: so think the release done should be good to QA and move forward.
<axw> wallyworld: I just thought of a probably better alternative. instead of watching individual storage attachments, the apiserver can return watchers for filesystem or volume attachments depending on the kind
<axw> then there's no need to bump the other doc at all
<wallyworld> axw: i do prefer to have fewer/no individual watchers - that's sort of what I was questioning (poorly) in that other review
<axw> wallyworld: can't really get away without individual watchers. the other one only responds to lifecycle state. also, with only a single watcher, we'd be forced into having everything in the one collection
<wallyworld> yeah, given the current implementation, that is true. i wish for a proper pubsub implementation
<axw> so I'm thinking a watcher that watches all of a unit's storage attachments' lifecycle states, and then the uniter will watch volumes/filesystems individually
<wallyworld> sounds good
 * dpb1 checks
<dpb1> rick_h_: thx -- closing out the bug
<rick_h_> dpb1: ty
<axw> wallyworld: I might move this normalisation code out of state too, into apiserver/common. client and uniter can use that, makes state a bit leaner.
<wallyworld> yep
<wallyworld> i thinkit belongs in a service layer
<wallyworld> i sorta think we need it elsewhere, not apiserver
<wallyworld> another new storage service layer
<wallyworld> apiserver is for network marshalling etc
<wallyworld> state is for persistence
<wallyworld> a (new) storage service layer is for service business logic
<wallyworld> i would love to move methods off the domain objects into that layer
<wallyworld> move towards a proper SOA
<ericsnow> davecheney: if you have any time to spare, I'd love it if you could follow up on your reviews for the 3 patches I have up. thanks
<davecheney> ericsnow: sure
<davecheney> will do
<ericsnow> davecheney: much appreciated
<ericsnow> davecheney: on that note, I'm going to bed :)
<axw> wallyworld: argh :(  can't make that change, at least not the way things currently are. for a filesystem-kind storage backed by a volume, it wouldn't be enough to watch a volume attachment
<axw> since it is affected by block devices also
<axw> (that's where filesystem information comes from)
<wallyworld> ah yeah, doh
<wallyworld> axw: i've proposed the default block provider stuff http://reviews.vapour.ws/r/1024/, gotta go do pickup so no hurry
<axw> wallyworld: ok, thanks
<axw> wallyworld: I'm investigating a small-ish model change which I think will simplify things; being adding an optional VolumeTag to Filesystem, identifying the volume that backs the filesystem
<dimitern> hmm cursed but not blocked?
<dimitern> morning
<axw> morning dimitern
<axw> wallyworld: so IOW, there will be a Filesystem for filesystem-kind storage, regardless of whether it's first-class
<axw> if it's not, that storage will have both a Volume and a Filesystem
<TheMue> morning
<TheMue> dimitern: did a test from 1.22 fail on your system? I took 1.21.3.
<dimitern> TheMue, I should've said 1.21.3, not 1.22
<dimitern> TheMue, morning :)
<TheMue> dimitern: o/
<dimitern> TheMue, so the upgrade did work?
<TheMue> dimitern: yep. only message in log has been by the metering
<dimitern> TheMue, great! I just wanted to double check
<TheMue> dimitern: and I've just seen that the CI is unblocked now, fine
<TheMue> dimitern: did you know http://juju.fail?
<dimitern> TheMue, yes :) I've heard about it, but have forgotten - will bookmark it now :)
<TheMue> dimitern: yes, I've bookmarked it too. better than all those $$please-let-me-in-now$$
<dimitern> TheMue, for sure :)
<TheMue> dimitern: the bug I'm on now need a bit more for understanding. missing knowledge about juju-deployer
<dimitern> TheMue, juju-deployer is irrelevant for the fix itself
<bodie_> coreycb, Actions are now out from behind the feature flag in trunk
<dimitern> TheMue, I've explained in the email - we need to make sure Ports and PortRanges fields on UnitInfo in the megawatcher are never set to nil but empty slices instead
<TheMue> dimitern: yes, seen it. it's only to get a better feeling for the situation which leaded to this error and maybe reproduce it
<dimitern> TheMue, you can test it using juju-gui and the ubuntu charm in a local env, as described in the steps
<dimitern> TheMue, and looking at the machine-0.log at TRACE level for "Deltas" (which is part of the changes reported by the AllWatcher)
<TheMue> ok
<dimitern> TheMue, read through it and try it out, if still unclear - let's chat on the standup
<TheMue> dimitern: yep, will do
<dimitern> TheMue, cheers - and please add a card for it and move your other one once merged
<dimitern> (but edit it a bit to reflect what you did in state - it's not a sub-package change as it says)
<TheMue> dimitern: cards are created/changed, only waiting for merging now
<dimitern> TheMue, +1, cool
<Muntaner> good morning o/
<Muntaner> guys, I'm using Juju with my laptop on a cloud private OpenStack server. Another laptop now wants to bootstrap the same environment: is this possible?
<Muntaner> solved :)
<voidspace> dimitern: http://reviews.vapour.ws/r/1025/
<dimitern> voidspace, LGTM
<voidspace> dimitern: great :-)
<voidspace> dimitern: although it looks like we're blocked at the moment
<dimitern> voidspace, really? I can't see any blockers
<dimitern> hmm topic needs updating
* ChanServ changed the topic of #juju-dev to: https://juju.ubuntu.com | On-call reviewer: see calendar | Open critical bugs: none
<dimitern> voidspace, http://juju.fail/ - all green
<TheMue> voidspace: dimitern: I added a review too, only regarding the logging format
 * TheMue is OCR today ;)
<dimitern> TheMue, thanks, I've replied
<TheMue> dimitern: ah, ok, misinterpreted the output. thanks
<dimitern> TheMue, np  :)
<voidspace> yeah, I think the (...) format to distinguish method calls is good
<TheMue> voidspace: yes, reading it this way sounds logical in traces
<voidspace> TheMue: cool, thanks for looking at the PR
<TheMue> yw
<voidspace> dimitern: you should close your old review (and PR probably)
<dimitern> voidspace, will do, cheers
<dimitern> TheMue, as OCR have a look at this please http://reviews.vapour.ws/r/1026/
 * TheMue looks ;)
<natefinch> ahh my god, my country for a relational DB
<natefinch> yes, let's duplicate the same information in 20 places, that sounds like a fantastic idea
<TheMue> dimitern: you've got a review
<dimitern> TheMue, tyvm
<TheMue> natefinch: morning natefinch
<natefinch> good morning :)
<TheMue> natefinch: some wishes for a new persistency layer? ;)
<natefinch> TheMue: honestly, I think if we just didn't duplicate data in our current one, it would be a lot better.  As it is, I'm surprised we don't have more problems with inconsistencies
<natefinch> for example, in our list of machines, we say what jobs each machine has... cool, ok... but then we also have a separate list in the stateServers collection of which machines are state servers.... why don't we just calculate that from the machines that have JobManageEnviron?
<TheMue> e.g. always available in a view, or even a materialized view
<TheMue> *sigh*
<dimitern> dooferlad, LGTM on http://reviews.vapour.ws/r/1010/ - thanks!
<dooferlad> dimitern: thanks!
<hazmat> just got a jujuclient bug that looks like a serious core issue imo..  allwatcher blows up in the middle of consuming the event stream.. bug 1425669
<mup> Bug #1425669: AllWatcher next internal failure for previously removed service. <canonical-bootstack> <is> <juju-core:New> <python-jujuclient:New> <https://launchpad.net/bugs/1425669>
<natefinch> hazmat: reading the bug,  I can't really tell what the repro steps are... it looks like "deploy a (subordinate) service, destroy the service" ... then what?
<hazmat> natefinch: then do an allwatcher and consume
<hazmat> s/consume/next on the allwatcher
<Muntaner> guys
<Muntaner> I'm writing my first charm
<Muntaner> and have some questions
<wallyworld> axw: i think it makes sense to model a volume backed filesystem using a volume tag attr, since ten as you say, there will always be a FileSystem object for filesystem storages. we can model it and see how it evolves
<dimitern> hazmat, I've commented on that bug to ask for clarification
<dimitern> hazmat, is the failure that Next returns an error or that the changes it returned have errors in them?
<hazmat> dimitern: next returns error
<hazmat> dimitern: that EnvError exception only triggers if the Error flag is set in the response, else its an app exception
<hazmat> dimitern: natefinch: unrelated, but similiar to an end user.. i've also seen issues where the subordinates services are not in the watches as well bug 1421315
<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> hazmat, subordinates won't appear unless there's a relation to their principal
<hazmat> noted
<hazmat> dimitern:  so a definied service won't appear in the watch output?
<hazmat> dimitern: thats a regression btw
<hazmat> 0 units, but service def should be in  results returned in the watch
<dimitern> hazmat, a subordinate service AIUI it's not really defined until there's a relation to a principal
<dimitern> hazmat, I have to double check though
<hazmat> dimitern: of course it is
<hazmat> dimitern: it has state
<hazmat> its a service with no units, there are is subordinate checks on add-unit/remove-unit
<dimitern> hazmat, ok, that's correct yes
<dimitern> hazmat, no units, but the subordinate service exists
<hazmat> anyways.. the point is more that a change in behavior on the watch here (if thats what is) is a serious regression.. but of course it could just be a bug.
<dimitern> hazmat, I'm looking into that Next() issue now with AllWatcher
<dimitern> we *really* need tests for the AllWatcher in core
<dimitern> dooferlad, the trunk port of the fix for bug 1415961 becomes more important with the failing maas ci jobs
<mup> Bug #1415961: juju gives up on bootstrapping with 'bootstrap instance started but did not change to Deployed state' <bootstrap> <maas-provider> <oil> <juju-core:Triaged by dooferlad> <juju-core 1.22:Fix Released by wallyworld> <https://launchpad.net/bugs/1415961>
<rick_h_> dimitern: as things like the gui rely on the allwatcher to know when services are added/etc a subordinate with no units should still go across the watcher so we can show it and allow a GUI user to relate it to an existing service in the environment. Just my .02 as a consumer of things.
<rick_h_> morning and all that as /me looks at scrollback
<dimitern> rick_h_, morning, and yes - I agree; I've narrowed down a few possible places that could be causing this
<dooferlad> dimitern: On it now.
<dimitern> dooferlad, thanks!
<rick_h_> dimitern: ty, adding my feedback to the bug and let me know if there's anything we can do to help.
<dimitern> rick_h_, cheers; it will be useful to know how far back this issue goes - is it a 1.22 and 1.23 (or just the latter), is it older
<rick_h_> dimitern: hmm, do you all have a good pattern for git bisecting things now that juju is in git and such?
<dimitern> rick_h_, not that I know of
<dimitern> TheMue, hey, I'm 99% sure now the bug you're working on is caused by state/megawatcher.go:116 (since the unit is not yet assigned)
<dimitern> TheMue, however, since you're on it anyway, the original fix I proposed will still fix that and possibly other cases where the slices can be nil
<perrito666> ericsnow: ping
<TheMue> great, will look at it. just came back from lunch and now reviewing an other PR
<dimitern> TheMue, thanks
<dooferlad> TheMue: One for your review queue http://reviews.vapour.ws/r/1028/ :-)
<TheMue> dooferlad: *click*
<TheMue> dooferlad: where do I find those 600s?
<coreycb> bodie_, awesome, thanks
<dooferlad> TheMue: I just ported this to trunk, didn't actually check the original commit messages!
<TheMue> dimitern: so in case we've got this IsNotAssigned, we return no error. should we then retry until we get them or we've got a timeout?
<dimitern> TheMue, no, we can't retry there - we're being called inside the multiwatcher loop
<dimitern> TheMue, however, when we get NotAssignedError, it's ok to return []network.PortRange{}, []network.Port{}, nil
<TheMue> dimitern: ah, fine, this would have been my solution otherwise to avoid those nils ;)
<dimitern> TheMue, the watcher will call us again if the unit gets assigned, but we don't know when (or if)
<TheMue> dimitern: we cannot know exactly when, but if in case of an assignment should be clear, shouldn't it?
<dimitern> TheMue, yes :) I meant "when or even if ever"
<TheMue> ;)
<dimitern> TheMue, also, as I was just investigating the possible cause for bug 1425669
<mup> Bug #1425669: AllWatcher next internal failure for previously removed service. <canonical-bootstack> <is> <juju-core:New> <python-jujuclient:New> <https://launchpad.net/bugs/1425669>
<TheMue> dimitern: of 1.20?
<dimitern> TheMue, what?
<TheMue> dimitern: only seen versions: juju-core 1.20.14
<dimitern> TheMue, my point was - can you add to your fix a couple of checks right after we call st.Unit(name) and to do the right thing if it returns NotFoundError - there are only 2 places in state/megawatcher.go -  line 107 and 187
<dimitern> TheMue, ah, that's where they're seeing this
<dimitern> TheMue, so about those checks - if errors.IsNotError(err) { return "", "", nil } in getUnitAddresses, and the same as above for getUnitPortRangesAndPorts - two empty slices and nil error
<TheMue> dimitern: ok, will add it there
<dimitern> TheMue, thanks
<TheMue> dimitern: got to thank you for your investigation
<dimitern> TheMue, np, I'm on the watch for new blockers hehe
<TheMue> dimitern: *bg*
<jw4> trivial fmt string fix: http://reviews.vapour.ws/r/1029/ PTAL
<dimitern> jw4, this is already fixed
<jw4> dimitern, cool, tx - I didn't see it in the lastest master... must still be merging
<dimitern> jw4, ah, sorry I might be wrong
<hazmat> dimitern: what about  1425669 is it incomplete? the client interaction api calls are known .. unless your asking for all api calls ever against that env.
<dimitern> jw4, indeed - there was a similar % instead of %v in allocate address
<dimitern> jw4, LGTM then
<jw4> dimitern, ta
<dimitern> hazmat, I'm asking for more logs
<hazmat> k
<perrito666> natefinch: brt
<dimitern> hazmat, it's not obvious what led to that issue, so it's important to be able to follow the API calls through the logs
<dimitern> hazmat, since we don't even have the juju status output or more than a few words describing the deployment
<rick_h_> dimitern: jrwren is working on checking the subordinate thing againts the versions of juju and should have notes back shortly
<rick_h_> dimitern: just fyi
<beisner> hi all.  in test driving juju/devel, i'm still getting beta3 tools.  (WARNING failed to find 1.22-beta4 tools, will attempt to use 1.22-beta3)   why is that?
<mgz> beisner: can you look at the simplestreams junk, add --debug and retry
<beisner> mgz, yep will do, thx
<dimitern> rick_h_, awesome, tyvm
<Muntaner> hi developers o/
<Muntaner> I'm writing my first charm and wanted to ask some questions
<Muntaner> I have a web application that needs apache2 and mysql
<Muntaner> When it's prompted the first time, in wordpress style, there is a web page installation
<Muntaner> and it asks me the mysql server ip
<Muntaner> how should I integrate this with the existing charms?
<Muntaner> should I install mysql and apache2 "inside" my web application charm?
<Muntaner> (dunno if I explained myself)
<dimitern> Muntaner, hey, for charm questions, #juju is a better place to ask << lazyPower, mbruzek, marcoceppi, jcastro, can any of you guys help here? ^^
<jcastro> yeah sure, come on over to #juju!
<Muntaner> ok dimitern so, sorry :)
<mattyw> dimitern, ping?
<dimitern> Muntaner, no worries at all :)
<dimitern> mattyw, hey
<jrwren> beisner: you get anywhere looking for 1.22-beta4 tools?
<jrwren> dimitern: I can't repro this subordinate allwatcher issue with juju 1.21.3 or 1.22-beta3. I do not have a good way to test any other versions.
<dimitern> jrwren, ok, thanks for the update - will you comment on the bug as well please?
<jrwren> dimitern: yes.
<beisner> jrwren, mgz - fyi debugging sstreams on serverstack.   it seems juju is trying to query a "index2.sjson" which is the current mystery.  http://paste.ubuntu.com/10449788/
<dimitern> jrwren, cheers
<beisner> as that initial query url doesn't match what is defined in keystone catalog (where we expect juju to first ask)
<jrwren> beisner: ah, private cloud, a bit different than I'm trying. I just happened to get the same issue when I wanted to test something with 1.22-beta4
<beisner> jrwren, it could be that our private stuff is all fine, and that that the beta4 tools really are awol, but i don't know how to confirm that.
<ericsnow> sinzui: when will we have a milestone in lp for 1.24?
<sinzui> ericsnow, I can create one now
<ericsnow> sinzui: thanks!
<sinzui> ericsnow, reload to see the milestone
<ericsnow> sinzui: perfect!
<ericsnow> cmars: could you give me a review on http://reviews.vapour.ws/r/1002/?
<ericsnow> cmars: http://reviews.vapour.ws/r/983/ could you some extra eyes too if you can :)
<ericsnow> frankban: ^^^ I suppose my plea applies to you too :)
<cmars> ericsnow, will do, currently in standup
<ericsnow> cmars: thanks!
<frankban> ericsnow: I think I am missing some context
<ericsnow> frankban: on the patches or on my request?
<ericsnow> frankban: the patches will add systemd support to juju
<frankban> ericsnow: on everything, I was offline I guess
<ericsnow> frankban: the request is because you are OCR :)
<ericsnow> frankban: ah
<ericsnow> frankban: I was asking for a review of http://reviews.vapour.ws/r/1002/ and http://reviews.vapour.ws/r/983/
<frankban> ericsnow: I am not aware of being a juju-core reviewer
<ericsnow> frankban: oops, wrong Frank ;P
<frankban> ericsnow: np ;-)
<ericsnow> TheMue: ^^^
<TheMue> ericsnow: lokking
<ericsnow> TheMue: thanks!
<sinzui> dimitern, the i386 test suite will be reported as a failure in the next hour. There are errors in logs, but the test didn't get all its retries because of aws didn't provide instances. I elected to let us start testing new revision then wait 2 more for 386
<dimitern> sinzui, ok, my fix that disables flaky tests (and the new ppc64 build failure) has landed
<TheMue> ericsnow: in #1002, do you have the same troubles with dependencies.tsv as me in the last change?
<ericsnow> ericsnow: I didn't have any trouble updating it, if that's what you mean
<ericsnow> TheMue: ^^^
<ericsnow> TheMue: though reviewboard is having some kind of trouble
<TheMue> ericsnow: take a look at the review board in the diff from 3 to 4
<ericsnow> TheMue: you mean between 2 and 3?
<TheMue> ericsnow: oh, there already, yes. I started from the end. ;)
<ericsnow> The it's just showing up because I rebased :)
<cmars> ericsnow, looking at 1002 now. weird error in reviewboard on the dependencies.tsv, is that due to a conflict?
<sinzui> dimitern, your new revisions just started testing
<dimitern> sinzui, great! I'll check the progress
<ericsnow> cmars: the patch doesn't touch dependencies.tsv (it shows up due to a rebase)
<ericsnow> cmars, TheMue: actually that's not true
<ericsnow> I pulled in the latest testing repo
<TheMue> ericsnow: #983 has a similar problem
<ericsnow> TheMue: weird, I'll fix that
<TheMue> ericsnow: thx
<ericsnow> TheMue: (983 adds a dep on the go systemd bindings)
<ericsnow> TheMue: glad you noticed that
<TheMue> :)
<cmars> ericsnow, there's also an error displaying service/common/common.go in 1002 (on page 2)
<ericsnow> cmars: notice on the right of the file list that it says "deleted" :)
<cmars> ericsnow, oh yeah, up at the top. ok
<cmars> weird
<ericsnow> cmars: reviewboard isn't super helpful on that
<alexisb> voidspace, have you met your son yet?
<voidspace> oops, wrong channel
<voidspace> alexisb: not yet
<voidspace> still waiting
 * ericsnow was just wondering that too
<beisner> mgz, jrwren -  interesting, even when i set     tools-metadata-url: https://streams.canonical.com/tools  i still get "failed to find 1.22-beta4 tools, will attempt to use 1.22-beta3"
<jrwren> beisner: right. that is what I was using.
<beisner> but local provider bootstrap builds and uploads tools ok of course
<jrwren> beisner: hrm... really?!?!
<mgz> beisner: you ahve the right devel setting in your envrionments.yaml yeah? (just checking the obvious)
<beisner> yep just install devel on my home laptop.
<beisner> mgz yep, on the private cloud enviro:  http://paste.ubuntu.com/10450285/    have tried with and without  tools-metadata-url: https://streams.canonical.com/tools
<beisner> ahh but i can --upload-tools to beta4 ok on the private cloud
<mgz> beisner: I can't see anything obviously wrong with the streams, did you pastebin a failing bootstrap with --debug set?
<beisner> mgz, debug:  http://paste.ubuntu.com/10449788/
<beisner> mgz, it seems juju is trying to query a "index2.sjson" which is the current mystery.   not sure where juju is getting that url.  keystone catalog doesn't show it afaict.
<beisner> mgz, L33 is where we expect juju to ask.   http://paste.ubuntu.com/10449937/
<perrito666> is any of you running a vmaas?
<mbruzek> jog: I see the tests PASSed for kubernetes http://reports.vapour.ws/charm-tests-by-charm/kubernetes .
<mbruzek> Thanks for your help jog.
<mbruzek> jog, or abentley It looks like the HP tests passed as well, but they do not show up in the results.  http://juju-ci.vapour.ws:8080/job/charm-bundle-test-hp/49/console  Do either of you know why?
<abentley> mbruzek: otp
<mbruzek> abentley: ack.
<mbruzek> I see the upload to s3 succeeded.  My understanding is if that step fails no report, so I am confused what is going on.
<mbruzek> ping me when available
<dimitern> perrito666, I am
<perrito666> 2 things 1) requirements in terms of hardware? 2) have a script to create it? :p
<katco> dimitern: hey just to let you know, i ran into a ton of issues with goamz's v4 signing support, and this is what's been taking a long time
<katco> dimitern: i'm planning on working until it's complete, but i wanted to let you know.
<dimitern> katco, ok, do you intend to land it today?
<katco> dimitern: if i can, yes. it's my primary focus.
<katco> dimitern: would you mind sending me an email or something regarding the changes we need to forward-port?
<katco> dimitern: that way if you're not around i can start on that?
<dimitern> perrito666, so I'm running vmaas on my laptop, so you'll need lots of RAM (1 GB preferred for the cluster controller kvm - the kvm 4  VMs  I have commissioned use 512 MB only), SSD is helpful as well,
<dimitern> katco, ok, I'm making a note to do that
<dimitern> perrito666, as for a script I don't think so - however dooferlad recently installed one and used some scripts to automate adding vms
<katco> dimitern: ty
<perrito666> dimitern: I have a laptop with 8G which I use only for that (i work in another)
<dimitern> perrito666, it should work fine - if it's not using a really old CPU
<perrito666> dimitern: mmm its an i5 2xxx I wonder what you call old
<dooferlad> perrito666: that will be fine.
 * perrito666 debates if he should not go buy a cheap desktop for this
<ericsnow> TheMue, cmars: Thanks for the reviews.
<dooferlad> perrito666: as long as you have virtualisation support, which that CPU does, you can use KVM and run a few VMs.
<TheMue> ericsnow: yw, still have #1002 open while fighting with own troubles in parallel
<ericsnow> TheMue: no worries
<perrito666> dimitern: tx, In fact I do run a windows vm there for windows tests with kvm
<dimitern> perrito666, that's fine - mine is actually a puny i3 M 350
<ericsnow> TheMue, cmars: note that davecheney's ship-it on rb #983 was inadvertent
<perrito666> oh spock died
<TheMue> ericsnow: yep, seen his later comment
<perrito666> :(
<TheMue> perrito666: what? haven't seen. :'(
<perrito666> TheMue: just  learned, very sad moment... I clearly am a nerd
<TheMue> perrito666: he has been part of my youth *sigh*
 * perrito666 announces a star trek marathon to his whife and gets an "are you insane?" look
<TheMue> perrito666: hehe, you'll need some time for it, indeed
<dooferlad> dimitern: my goodness, that took a lot of test prodding!
<dimitern> dooferlad, what did?
<dimitern> dooferlad, ah, yeah :/
<dooferlad> dimitern: that change that you just updated the bug on
<dimitern> dooferlad, I'm thinking of proposing a PR to skip TestAddRemoveSet and TestConfigEvents
<dimitern> sinzui, what do you think? ^^
<dooferlad> dimitern: I certainly would like to see the replicaset tests run faster. At least one of those fails was EC2 losing its Ubuntu archive mirror though, so updating the test script to retry the apt-get steps would help in that case
<sinzui> dimitern, I know the first is unreliable and if You believe  it is not trusty worthy, then please skip it.
<dimitern> dooferlad, actually juju should be doing the retry - we retry apt-get install but not apt-get update or upgrade
<sinzui> dimitern, in general if the test cannot be trusted, it isn't worthy of failing the entire test suite. I don't think tests can print warning to the log though
<mgz> dimitern: I would not mind TestAddRemoveSet dying
<dimitern> dooferlad, sinzui even has failure cause for that
<jog> mbruzek, I just got out of a meeting, I'll have a look at the charm reporting
<mbruzek> jog thank you
<dimitern> sinzui, mgz, I'm not saying we should forget about fixing them, but skipping them temporarily (under a high tech dept bug) will definitely speed up merges
<mbruzek> jog I saw the hp one pass
<dooferlad> dimitern: I am talking about this script, lines 140 - 143 http://bazaar.launchpad.net/~juju-qa/juju-ci-tools/trunk/view/head:/run-unit-tests
<dooferlad> dimitern: that has no retry that I can see
<sinzui> dooferlad, we can fix that in a few minutes
<sinzui> and 141 too
<sinzui> dooferlad, also note the call to $FIXUP_SOURCES which switch to true ubuntu archives which are much more reliable than cloud mirrors
<sinzui> dooferlad, I think I can have the reties in place in 1 hours
<dooferlad> sinzui: I can submit a patch if you want
<sinzui> you sure can, just using OR "|" will suffice
<dimitern> dooferlad, I know what you're talking about :) but in all fairness failing on apt-get update is a juju issue, not a CI job one
<dooferlad> sinzui: http://juju-ci.vapour.ws:8080/job/github-merge-juju/2318/console isn't using archive.ubuntu.com. Looks like we don't use --force-archive, though looking at the sed command, it would break the job completely (I think).
<sinzui> dooferlad, ah...
<sinzui> dooferlad, I will fix now
<ericsnow> alexisb: ping
<dooferlad> dimitern: The failure I an talking about is pre-juju in the test. EC2 dropped a net connection while we were setting up the VM.
<sinzui> dooferlad, retry
<sinzui> dooferlad, mgz, I know that git-merge-juju once used --force-archive I think we dropped it by accident
<dooferlad> sinzui: Oh, that change has landed now. It just took three attempts.
<alexisb> ericsnow, omw
<ericsnow> alexisb: k
<dimitern> dooferlad, oh, good catch then, my bad :)
<dooferlad> sinzui: don't enable --force-archive with "sudo sed s/ec2.archive.ubuntu.com/archive.ubuntu.com/ /etc/apt/sources.list -i" in the script. The EC2 mirror could be http://us-east-1.ec2.archive.ubuntu.com/ubuntu/, which would result in us-east.archive.ubuntu.com...
<mgz> sinzui: I don't remember any reason not to have --force-archive
<dooferlad> mgz ^^
<mgz> we can fix the sed if we want the effect of always using archive.ubuntu.com
<dooferlad> indeed. We just need to not just enable the flag :-)
<sinzui> mgz, maybe we do want to do that. No cloud has proven to have mirrors as reliable as ubuntu
<sinzui> dooferlad, retying the update and upgrade is also a good addition
<dooferlad> I think sed s/http:\\/\\/.*.archive.ubuntu.com/http:\\/\\/archive.ubuntu.com/ /etc/apt/sources.list is what we want.
<dooferlad> so many backslashes
<dooferlad> In fact, more backslashes are probably good: sed s/http:\\/\\/\\.*.archive\\.ubuntu\\.com/http:\\/\\/archive.ubuntu.com/ /etc/apt/sources.list :-)
<sinzui> dooferlad, sed can use commas as delimiters. s,bad,good,g
<sinzui> I don't use / since I work with urls all the time
<dooferlad> sinzui: ah, I tend to avoid sed completely myself. Good tip!
<sinzui> dooferlad, yeah, and avoiding sed is a plus. mgz and I want to switch to python. we have something that runs the test, but not provision the instance
<dooferlad> sinzui: sounds like a good plan
<mgz> one of those jobs we'll get to at a sprint or something
<perrito666> dooferlad: dimitern says you have some scripts to help automate vmaas?
<dooferlad> perrito666: yep, just installing nodes. PM me your email address and i will forward the instructions
<ericsnow> cmars: thanks for the reviews; I've addressed nearly all your comments
<ericsnow> TheMue: you EOD?  regardless, thanks for the review :)
<perrito666> dooferlad: did you have issues with the vnc display after installing maas?
<dimitern> perrito666, what issues?
<dimitern> natefinch, cmars, can I get a review on this please? http://reviews.vapour.ws/r/1031/ - this is the penultimate step towards landing container addressability
<cmars> dimitern, taking a look
<jw4> dimitern: do folks use the word penultimate in casual conversation where you live?
<dimitern> jw4, no
<dimitern> :)
<jw4> :)
<perrito666> dimitern: well vnc shows a black screen with a couple of white garbage dots at the top
<dimitern> jw4, but I like it as it's shorter than "second to last" or something
<perrito666> dimitern: I use ssh, but still
<jw4> dimitern: +1
<dimitern> perrito666, why vnc? can't you use the virt-manager's vm consoles?
<dimitern> cmars, cheers
<perrito666> dimitern: my virt manager uses vnc by default, I changed it to use another one next reboot
<dimitern> perrito666, ha! mine uses vnc as well - now that I've actually checked :)
<perrito666> dimitern: lol
<dimitern> perrito666, is that the maas server vm or one of the maas vm nodes?
<perrito666> the maas server vm
<perrito666> still not have nodes :=
<perrito666> :)
<perrito666> aghh wrong kb distribution
<dimitern> perrito666, right, so you've installed it - that's the first boot after?
<perrito666> dimitern: yup
<natefinch> man, I wish reviewboard would show me the changes in the area where a comment was resolved, so I can see *how* the comment was resolved.
<ericsnow> cmars: you made some good points in your reviews (thanks!)
<cmars> ericsnow, sure
<natefinch> ericsnow: you have a ship it on GCE
<ericsnow> natefinch: thanks!
 * natefinch goes back to doing terrible things to the HA code
<katco> ericsnow: wwitzel3: grats on all the hard work on GCE
<ericsnow> katco: thanks!
<natefinch> ^^ x100
<ericsnow> katco: I'm happy with where it ended up
<katco> that's awesome :)
<ericsnow> katco: perhaps the largest patch I may ever land in my life :)
<katco> ericsnow: lol
<perrito666> natefinch: remember you hve to do terrible things to hr too :p
<natefinch> ericsnow: oh, I don't know, you can do better ;)
<ericsnow> natefinch: don't push me!
<perrito666> dooferlad: wheneer you are around I found a couple of bugs :p but nothing big, your script is useful
<dimitern> katco, ping
<katco> dimitern: pong!
<dimitern> katco, hey, before I go, have a look at this https://github.com/go-amz/amz/compare/v2...v3-unstable
<katco> dimitern: all looks fairly mechanical
<katco> dimitern: i didn't realize the putwithheaders was a forward-port. my pr has that as well, so that's good :)
<dimitern> katco, so it turns out the changes are very few - s3/s3.go, s3/s3_test.go, ec2/ec2t_test (one sort.Strings added), README.md (you might leave this), and AUTHORS.md
<katco> dimitern: yeah
<dimitern> katco, yeah - that's all apart from the import paths and travis CI script config, eg.
<dimitern> katco, for easy migration of the import paths check rogpeppe's govers tool - really cool
<katco> dimitern: it's looking like i'll probably be able to propose this a little after my EoD (fingers crossed). will you be able to look at it any time this weekend (sorry)
<dimitern> katco, ok, I'll have a look at some point, np
<dimitern> katco, but I need to get going now
<natefinch> ericsnow: looks like there's something missing for one of the tests for providerRegistrySuite.TestSupportedEnvironCommonProviders
<dimitern> katco, I'm sure you'll take care of it nicely :)
<katco> dimitern: ok, i'll be checking in. i'll try and land it into juju this weekend
<katco> dimitern: i hope so, but gosh it could use another pair of eyes :)
<dimitern> katco, sweet! no worries
<katco> dimitern: ty for all of your hard work/overtime
<dimitern> katco, np, we're all in the same boat after all :)
<ericsnow> natefinch: (â¯Â°â¡Â°)â¯ï¸µ â»ââ»
<katco> dimitern: that we are! heave! ho! :p
<dimitern> ;) happy weekends y'all
<katco> dimitern: tc
<marcoceppi> perrito666: you around, we're having fun with windows!
<perrito666> marcoceppi: did I miss the fun?
<jw4> perrito666 sounds hopeful
<perrito666> marcoceppi: I am about to vanish unless you tell me not to
<marcoceppi> perrito666: got like 5 mins to hangout?
<lazyPower> perrito666: did you deploy the drupal6 charm during testing or just the nova-hyperv charm?
<perrito666> sure, pass the url
<lazyPower> oh, if you join the hangout - i'll hit you up there :D
<marcoceppi> perrito666: see pm
<lazyPower> lots of juju core questions and whats been tested questions
<perrito666> marcoceppi: trying to get in
<marcoceppi> perrito666: we'll sync with you on Monday, nothing vital for today anymore
<perrito666> marcoceppi: Ill reboot the computer
<perrito666> and get in, no trouble
#juju-dev 2015-02-28
<jw4> another trivial go vet fix http://reviews.vapour.ws/r/1034/
<jw4> OCR or any graduated reviewer PTAL ^
<perrito666> jw4: idont think you will find any of those here on a saturday
<jw4> perrito666 eh.. I don't have any heart burn over it... I just keep finding these trivial go vet warnings... makes me think that few people use the latest go and have the pre-push hook set up
<jw4> another long shot review request :)  http://reviews.vapour.ws/r/997/
<mup> Bug #1426728 was filed: Windows Charms are unable to raise error state <juju-agent> <windows> <juju-core:New> <https://launchpad.net/bugs/1426728>
<mup> Bug #1426729 was filed: juju-run does not work on windows hosts <juju-agent> <windows> <juju-core:New> <https://launchpad.net/bugs/1426729>
<mup> Bug #1426730 was filed: juju debug-hooks does not work on windows <juju-agent> <windows> <juju-core:New> <https://launchpad.net/bugs/1426730>
#juju-dev 2015-03-01
<jw4> another review request for OCR, or whenever some graduated reviewer gets a chance and is willing: http://reviews.vapour.ws/r/1035/
<katco> wallyworld: ping?
<dimitern> katco, o/
<dimitern> katco, I've decided it's easier to chat on irc than send tons of mails like that :)
<katco> dimitern: lol yeah!
<katco> dimitern: so, i don't have access to an ec2 console with these credentials
<katco> dimitern: wallyworld gave them to me
<dimitern> katco, are these the shared ones?
<katco> dimitern: i think so
 * dimitern scans through emails to find those
<katco> dimitern: lmk if you want me to pm you
<katco> dimitern: so i ran the s3 tests again using the same methodology you do, and they all pass
<dimitern> katco, sure
<katco> dimitern: i was going to ask you if maybe using the symlink methodology, the s3 code was possible using v1/v2 signing on accident?
<dimitern> katco, as I've replied to one of the mails - I'm not using symlinks in my gopath for goamz
<katco> dimitern: ah sorry, i must have misunderstood
<katco> dimitern: well the tests have consistently passed for me. we'd have to start picking apart the signing pieces to figure out what's going wrong on your end. is it possible to run TravisCI again?
<dimitern> katco, it's configured to run on every commit or PR, but I guess we could try to re-run it
<katco> dimitern: i think we need a 3rd data point
<katco> dimitern: because me saying, "works for me!" isn't very helpful :)
<dimitern> katco, I've just re-run the travis tests and they passed again
<dimitern> katco, I'll retry on my machine with maximum debugging
<katco> dimitern: i guess it can't run the live tests
 * katco getting more tea
<dimitern> katco, it *could*, but that'll mean adding some ec2 creds somewhere
<dimitern> katco, so running s3 tests on v3-unstable worked, on your branch failed the same way
<katco> dimitern: we will have to pick apart the signing pieces to troubleshoot this
<katco> dimitern: amazon returns what it expects for all the signing pieces, we can compare those to the debug output from aws/sign.go
<katco> dimitern: can you pick one test that's failing and pick out the equivalent pieces from debug and response?
<dimitern> katco, https://github.com/go-amz/amz/pull/27/files#diff-db02e2f1c976d269194375e02b0d62a4R73 << this is a bit worrying
<dimitern> katco, why append there?
<katco> dimitern: virtual domain buckets don't work with SSL since the cert is registered for the domain
<katco> dimitern: http://shlomoswidler.com/2009/08/amazon-s3-gotcha-using-virtual-host.html
<dimitern> katco, I believe the lowercasing might be the issue for us-east-1
<katco> dimitern: mm? how so?
<dimitern> katco, because USEast is defined as S3LowercaseBucker: false
<dimitern> katco, and ResolveS3BucketEndpoint unconditionally lowercases
<dimitern> katco, does this look ok to you: !!!! url="/goamz-faux-region-1--20150301t185544.220574391+0200/index.html"; b=s3test.bucketResource{name:"goamz-faux-region-1--20150301t185544.220574391+0200", bucket:(*s3test.bucket)(nil)}
<katco> dimitern: yes
<katco> dimitern: the test suite had races, so i had to make the test bucket names more unique
<katco> dimitern: i corrected the casing locally and i'm re-running tests
<dimitern> katco, that's the problem I think
<katco> dimitern: the casing?
<dimitern> katco, because the timestamp is not escaped
<katco> dimitern: why would it work for me?
<dimitern> katco, can you please add this: defer func() { fmt.Printf("!!! url=%q\n", u) }()
<dimitern> katco, in the beginning of s3test/server.go - resourceForURL() and run the tests, paste the output
<katco> dimitern: with the casing, 3 tests now fail
<katco> dimitern: all because the returned bucket name is cased differently than the one we sent (returned is lowercase)
<dimitern> katco, ok, that's an improvement
<katco> dimitern: lol it is?
<dimitern> katco, I still think adding the timestamp to the bucket name will cause more trouble than solve
<dimitern> katco, if you have seen failures I mean :)
<dimitern> katco, which ones?
<katco> dimitern: i could not get anything to pass without. it just ensures a unique bucket for each test
<katco> dimitern: i can inject failures very easily. whether that's progress is a different question :)
<katco> FAIL: <autogenerated>:8: AmazonClientSuite.TestBucketList
<katco> test 0
<katco> s3i_test.go:367:
<katco>     c.Check(resp.Name, Equals, b.Name)
<katco> ... obtained string = "goamz-us-east-1-akiajilh-20150301t105734.322973375-0600"
<katco> ... expected string = "goamz-us-east-1-AKIAJILH-20150301T105734.322973375-0600"
<katco> all the failures are this
<dimitern> katco, :)
<dimitern> katco, I think the problem is you TZ
<dimitern> katco, + in the url in my case translates to %20
<katco> dimitern: i modified the test to check the region's casing and lowercase it if applicable
<katco> dimitern: ah ok, so you're getting a + for +to UTC?
<dimitern> katco, yes
<katco> there's our environmental difference :D
<katco> i'll remove that portion of the timestamp
<dimitern> katco, have you tried that thing with the defer?
<katco> dimitern: yes it's running now
<dimitern> katco, 	looking at the generated /goamz-faux-region-1--20150301t191139.281063565+0200/ name
<katco> !!! url="/goamz-faux-region-1--20150301t111233.411561549/"
<katco> !!! url="/goamz-faux-region-1--20150301t111233.411561549/"
<katco> !!! url="/goamz-faux-region-1--20150301t111233.412200038/"
<katco> !!! url="/goamz-/non-existent"
<katco> !!! url="/goamz-faux-region-1--20150301t111233.412956978/"
<dimitern> katco, ok
<katco> even with this i'm getting casing failures now:
<katco> 		expectedBucketName := b.Name
<katco> 		if b.Region.S3LowercaseBucket {
<katco> 			expectedBucketName = strings.ToLower(expectedBucketName)
<katco> 		}
<katco> 		c.Check(resp.Name, Equals, expectedBucketName)
<dimitern> katco, so just removing the timestamp from the urls made ALL the tests pass on your branch
<katco> dimitern: i found the tests to pass/fail randomly without that
<dimitern> katco, the local ones I mean
<dimitern> katco, I'll run them a few times just to be sure
<katco> dimitern: the local ones always worked for me
<katco> dimitern: the live ones were much more volatile
<katco> dimitern: the failures would move around randomly
<dimitern> katco, so the problem is finding out what's breaking in live tests
<katco> dimitern: race conditions
<katco> dimitern: it's non-deterministic
<dimitern> katco, well :) I found while fixing ec2 live tests a lot of these random issues could be fixed with retrying on cleanup
<katco> dimitern: i did that :)
<katco> dimitern: i fought with this issue for a long time, and making the buckets unique per test was the thing which finally got everything to pass.
<dimitern> katco, that's understandable, but they should be unique per suite run I think not changing each time you call testBucket
<dimitern> katco, like it is I bet there are tons of leftover undeleted buckets from the account
<katco> dimitern: well, as the failures were jumping tests, and not suites, i think that's the resolution we would need to be unique
<katco> dimitern: yes there are, i have to delete them after each run
<dimitern> katco, that's not a solution then
<katco> dimitern: i think we can probably accept that drawback for now given the deadline
<katco> dimitern: it's only an issue with the tests after all
<dimitern> katco, ah, right - but even then it should be fixed eventually
<dimitern> katco, so I think the issue is the region name is inconsistent for all tests
<katco> dimitern: definitely agreed
<dimitern> katco, so far with only this change to your branch http://paste.ubuntu.com/10489714/
<dimitern> katco, all (local and live) tests except 5 in multi_test pass
<katco> dimitern: sorry irc client crashed
<dimitern> katco, np
<katco> dimitern: i'm running tests now with that change. how many times have they passed for you with that patch?
<dimitern> katco, just the removal of the timestamp?
<katco> dimitern: yeah
<dimitern> katco, completely - none, there are always some failures
<katco> dimitern: i believe those are the race conditions... if you run the failures alone, they will pass.
<dimitern> FAIL: multi_test.go:1: AmazonClientSuite.TestBucketList
<dimitern> this one always fails so far
<katco> dimitern: because it's a loop
<katco> dimitern: (essentially separate tests)
<dimitern> katco, I'm trying a few more things
<katco> dimitern: with this patch, they pass: http://pastebin.ubuntu.com/10490009/
<katco> dimitern: i think they should for you as well
<dimitern> katco, I'll try it out in a bit
<dimitern> katco, why do you register AmazonClientSuite twice btw?
<katco> dimitern: i didn't think i messed with suite registration
<katco> dimitern: let me look
<katco> dimitern: yeah i think that was existing
<katco> dimitern: it's not in my diff
<dimitern> katco, you added the next one? AmazonDomainClientSuite?
<katco> dimitern: can you point me at the line? i don't recall adding that
<dimitern> katco, nope, just checked - you didn't
<dimitern> katco, but that's the most likely reason for the races
<katco> dimitern: it looks like they're attempting to test different regions
<dimitern> katco, yeah, but us-east-1 is tested twice
<katco> dimitern: i see this
<katco> var _ = Suite(&AmazonClientSuite{Region: aws.EUWest})
<katco> var _ = Suite(&AmazonDomainClientSuite{Region: aws.USEast})
<katco> oops and USEast for the AmazonClientSuite
<dimitern> katco, no var _ = Suite(&AmazonClientSuite{Region: aws.USEast}) before that?
<katco> no you're right, it's there
<dimitern> katco, so I've changed this to USWest and now testing
<katco> so yeah it looks like there will be overlap b/t AmazonClientSuite and AmazonDomainClientSuite
<katco> dimitern: are you testing with the shared credentials? i don't want to mess up your run
<dimitern> katco, no with mine
<mup> Bug #1426940 was filed: Juju-Windows upgrade-charm --force does not in place force an upgrade <juju-agent> <windows> <juju-core:New> <https://launchpad.net/bugs/1426940>
<katco> dimitern: i get failures when switching one of the tests to USWest
<katco> dimitern: i still have to land this into juju. what do you think about this:
<katco> dimitern: we received reports that ec2 was working in china with the last version of juju
<katco> dimitern: so maybe we clone the sign.go file and put it into s3 for now
<katco> dimitern: apply the datetime fix for the live tests
<katco> dimitern: and we can fix both those things when we have more time
<dimitern> katco, let me finish this first and I'll come back - 5m
<katco> dimitern: ok
<alexisb> dimitern, katco everything ok?
<dimitern> alexisb, yeah, just helping out katco with goamz stuff
<alexisb> ack,
<katco> alexisb: yeah we're just trying to get that landed into juju before the 1.23 cut
<dimitern> katco, ok, so my changes didn't seem to improve the failure rate; i'll try your patch with the date
<katco> dimitern: ok
<dimitern> katco, wow!
<katco> dimitern: ?
<dimitern> katco, still running, but nothing failed so far
<katco> dimitern: yay :)
<katco> dimitern: i am nervous about introducing this large a change right before we cut for v1.23, will there be time to correct any mistakes?
<dimitern> katco, there's always time :)
<katco> dimitern: lol
<dimitern> katco, so the v4 signing for ec2 won't be done, right?
<katco> dimitern: well, let me dig up the bug report. supposedly that was working fine
<katco> https://bugs.launchpad.net/juju-core/+bug/1415693
<mup> Bug #1415693: Unable to bootstrap on cn-north-1 <bootstrap> <ec2-provider> <online-services> <juju-core:In Progress by cox-katherine-e> <https://launchpad.net/bugs/1415693>
<katco> https://github.com/go-amz/amz/issues/22
<dimitern> katco, all passed!
<katco> woohoo!
<dimitern> katco, however, there are a bunch of leftover buckets I can see
<katco> dimitern: yeah
<dimitern> katco, ah, ok - let's add an issue for this as well
<katco> dimitern: ok i can add that later
<dimitern> katco, so one issue for the skipped v4 sign tests and one for cleaning up after live tests pass (or fail for that matter)
<dimitern> katco, ok, cheers
<dimitern> katco, I'll comment on the PR
<katco> dimitern: regarding the skipped v4 tests... looking at the original bug, i actually don't know if ec2 was ever working with v4
<katco> dimitern: and i have no way of testing china
<katco> dimitern: i think the best i can do for now is to check to see if the region is china, and use v4. it may not work, and we'd have to try to backport fixes for it i think
<dimitern> katco, I haven't seen it working at least
<katco> dimitern: but you have more context on what's acceptable, any thoughts on how to proceed?
<dimitern> katco, if it's not testable, it's not fixable
<katco> dimitern: do you have access to china testing?
<dimitern> katco, so I'd comment on the bug about providing you with a cn-north account
<dimitern> katco, no
<katco> dimitern: PR is up with changes, Travis CI passes
<dimitern> katco, cool, I'm having a look
<cherylj> davecheney: Could you re-review my ensure-availability changes?  http://reviews.vapour.ws/r/1015/
<cherylj> It seems to have also picked up some of the changes that anastasiamac did for a separate PR
<davecheney> cherylj: ok
#juju-dev 2016-02-29
<davecheney> q: how long does it take to run zero juju tests
<davecheney> real    26m57.934s
<davecheney> user    76m59.990s
<davecheney> sys     9m22.711s
<davecheney> 26 minutes to test nothing!!
<davecheney> go test -i ./... && time go test ./...
<perrito666> davecheney: that cannot be the build time of the test suite
<davecheney> that is the time to run all the tests, excluding actually running tests
<davecheney> sorry, hang on
<davecheney> i posted the rwong numbers
 * perrito666 is expectant
<anastasiamac> blahdeblah: \o/ thank yuo. I saw :D
<blahdeblah> Looks like it's some sort of leadership election strangeness
<anastasiamac> blahdeblah: m working on 1.25 and the bug 's on the radar. cannot tell u right now when it'll get some love but should happen \o/
<davecheney> real    15m30.976s
<davecheney> user    56m52.867s
<davecheney> sys     2m50.591s
<davecheney> lucky(~/src/github.com/juju/juju) % go test -i ./... && time go test ./... -run=XXX
<blahdeblah> anastasiamac: cool - thanks
<davecheney> 15:30 to build and run zero tests
<blahdeblah> I should document my workaround on that bug
<anastasiamac> blahdeblah: tha would b fantastic!
<blahdeblah> anastasiamac: Not really; it's just "restart all the things" :-\
<anastasiamac> blahdeblah: :D
<wallyworld> thumper: it seems that the share model functionality does not support setting readonly = true. there is a read only flag but it's always false. is that your recollection? and we never access the flag anyway
<anastasiamac> blahdeblah: it would be great to isolate the bug, i.e. minimum setup and steps to reproduce :D
<thumper> wallyworld: hey
<thumper> wallyworld: yes, very much so, but cmars's team is taking that on
<thumper> I wrote the bit that made read only possible
<wallyworld> ah, righto, thanks
<thumper> but we don't yet support it at the cli, or client api
<blahdeblah> anastasiamac: I just deployed my env & waited.  Yesterday morning I was working on it just fine; came back yesterday evening and it was broken.
<thumper> to set / get / list
<wallyworld> yep
<thumper> wallyworld: was there another question about that?
<wallyworld> thumper: there's been discussion about create-model and who should be allowed to do it etc, as if i can create a model in your controller using your creds, i can cost you money. so i'm just seeing what's been done in that area
<thumper> nothing
<thumper> the current expectations are that creds are passed up explicitly
<thumper> since that is to change
<wallyworld> yes, in a --config file
<thumper> there needs to be discussion
<wallyworld> yup. i think it should be if you are the admin user of a controller you can create a model  using teh saem creds
<wallyworld> otherwise you need to supply them
<mup> Bug #1544847 changed: configSuite.TestNewModelConfig test failure lxd <ci> <lxd> <regression> <test-failure> <unit-tests> <juju-core:Fix Released> <juju-core lxd-container-type:Fix Released> <https://launchpad.net/bugs/1544847>
<mup> Bug #1548799 changed: bootstrap from windows fails with no such file <ci> <regression> <windows> <juju-core:Fix Released by axwalk> <https://launchpad.net/bugs/1548799>
<mup> Bug #1550810 changed: TestDetectCredentialsKnownLocationWindows missing region <ci> <regression> <test-failure> <windows> <juju-core:Fix Released by wallyworld> <https://launchpad.net/bugs/1550810>
<mup> Bug #1544847 opened: configSuite.TestNewModelConfig test failure lxd <ci> <lxd> <regression> <test-failure> <unit-tests> <juju-core:Fix Released> <juju-core lxd-container-type:Fix Released> <https://launchpad.net/bugs/1544847>
<mup> Bug #1548799 opened: bootstrap from windows fails with no such file <ci> <regression> <windows> <juju-core:Fix Released by axwalk> <https://launchpad.net/bugs/1548799>
<mup> Bug #1550810 opened: TestDetectCredentialsKnownLocationWindows missing region <ci> <regression> <test-failure> <windows> <juju-core:Fix Released by wallyworld> <https://launchpad.net/bugs/1550810>
<mup> Bug #1544847 changed: configSuite.TestNewModelConfig test failure lxd <ci> <lxd> <regression> <test-failure> <unit-tests> <juju-core:Fix Released> <juju-core lxd-container-type:Fix Released> <https://launchpad.net/bugs/1544847>
<mup> Bug #1548799 changed: bootstrap from windows fails with no such file <ci> <regression> <windows> <juju-core:Fix Released by axwalk> <https://launchpad.net/bugs/1548799>
<mup> Bug #1550810 changed: TestDetectCredentialsKnownLocationWindows missing region <ci> <regression> <test-failure> <windows> <juju-core:Fix Released by wallyworld> <https://launchpad.net/bugs/1550810>
<davecheney> thumper: the apiserver/client package imports juju/agent just to get one constant, which brings in the entire api client ...
<thumper> what's the constant?
<davecheney> const SystemIdentity = "system-identity"
<thumper> why does the apiserver want that constant?
<davecheney> for reasons that I do not understand
<davecheney> the apiserver has a client
<davecheney> and that client does things, on remote machines ?!?!
<davecheney> i have NFI why the apiserver has a client
<davecheney> and why that client is juju/api
<davecheney> https://github.com/davecheney/prdeps
<davecheney> wrote a simple tool to print out dep graphs
<davecheney> the shit it's turning up is making my hair turn white
<thumper> the server has a client???
<davecheney> yes
<davecheney> apiserver/client
<thumper> um...
<thumper> that is the implementation of the client facade is it not?
<thumper> it isn't an api client
<davecheney> but it imports the api client
<davecheney> and then uses the api client to do stuff
<davecheney> O_o!
<thumper> oof
<wallyworld> anastasiamac: if you get a moment sometime, could you please look at http://reviews.vapour.ws/r/3999/
<anastasiamac> wallyworld:
<anastasiamac> looking :D
<frobware> jam: ping, 1:1 today?
<jam> frobware: sorry. I'm omw
<dimitern> frobware, morning
<frobware> dimitern: morning
<dimitern> frobware, I have figured out how to do the multi-nic containers backed by devices
<dimitern> frobware, I have 2 machines running - each with 2 nics, first disabled, the other one with 4 vlans
<dimitern> frobware, and on each of these nodes, I have 2 containers running with 5 nics each, using the respective br-eth1[.xx] bridges
<dimitern> pinging works, connecting with nc shows correct source and destination addresses
<dimitern> so we need to make devices with physical nics, generated macs, and linked to the correct maas vlan and subnet
<dimitern> can't do vlan interfaces on devices, but it wasn't necessary
<mup> Bug #1551141 opened: Juju bootstrap local - cannot get replset config: not authorized for query on local.system.replset <juju-core:New> <https://launchpad.net/bugs/1551141>
<mup> Bug #1551141 changed: Juju bootstrap local - cannot get replset config: not authorized for query on local.system.replset <juju-core:New> <https://launchpad.net/bugs/1551141>
<dimitern> frobware, FYI, I've updated the spike card assigned to me with all the relevant info
<mup> Bug #1551141 opened: Juju bootstrap local - cannot get replset config: not authorized for query on local.system.replset <juju-core:New> <https://launchpad.net/bugs/1551141>
<dooferlad_> frobware: hangout time
<voidspace> dooferlad: frobware: dimitern: http://reviews.vapour.ws/r/4000/
<voidspace> all tests pass and manual testing works
<dimitern> voidspace, reviewed
<frobware> voidspace: I had one question
<voidspace> frobware: we still do name translation because maas can still use names with spaces (etc)
<voidspace> frobware: once maas is fixed we can remove name translation
<voidspace> dimitern: thanks
<voidspace> frobware: we will kill it with fire as soon as possible :-)
<frobware> voidspace: ok, gotcha
<voidspace> frobware: ping
<frobware> voidspace: pong
 * dimitern whew ... ok vlans work across hosts and containers - tagged traffic gets untagged before reaching the container
<voidspace> dimitern: :-)
<perrito666> morning
<dooferlad> voidspace, dimitern, frobware: http://reviews.vapour.ws/r/4002 -- The API server + mongo space change is ready for review.
<natefinch> ericsnow: you around?
<frobware> dooferlad: will look in a bit, just finishing up a review too.
<dimitern> dooferlad, cheers, will look at it soon
<dooferlad> frobware, dimitern: thanks. It looks big, but there is a huge name change in one of the test files that takes up a big chunk of it - don't be put off!
<mup> Bug #1551276 opened: 2.0-beta2 stabilization <blocker> <juju-core:Triaged> <https://launchpad.net/bugs/1551276>
<mup> Bug #1551276 changed: 2.0-beta2 stabilization <blocker> <juju-core:Triaged> <https://launchpad.net/bugs/1551276>
<mup> Bug #1551276 opened: 2.0-beta2 stabilization <blocker> <juju-core:Triaged> <https://launchpad.net/bugs/1551276>
<natefinch> ericsnow: ping?
<ericsnow> natefinch: hey
<natefinch> ericsnow: hey... I'm working on that upgrade charm, pull metadata from charmstore card
<natefinch> ericsnow: there's a task that says "Set available field in resource doc."  ... is that out of date?
<ericsnow> natefinch: yep
<ericsnow> natefinch: really, I'd expect that we'd be doing exactly the same thing as deploy for this
<ericsnow> natefinch: along with an extra step to release the stored resource blob, if necessary
<natefinch> ericsnow: well, serverside, I don't think we added anything for deploy about the charmstore at all
<natefinch> ericsnow: there's just NewResolvePendingResourcesOps
<ericsnow> natefinch: that's what I'm talking about
<natefinch> ericsnow: ok, so we're relying on the client to push up the new resource metadata?
<ericsnow> natefinch: ah
<ericsnow> natefinch: given that we now have --resources (like deploy), we should follow suit
<natefinch> ericsnow: ok, that's easy enough (and in fact I've already done that part).  The talk about hooking into the same machinery as resource poller threw me off
<natefinch> ericsnow: I'm worried that this will break if you upgrade using the GUI, though
<ericsnow> natefinch: yeah, this was before --resources
<ericsnow> natefinch: we have the same problem with deploy though, no?
<natefinch> ericsnow: then we should fix it for both, right? :)
<natefinch> ericsnow: I was thinking of just adding a charmstore.ListResources and Resources.SetCharmStoreResources in the state code that does deploy and upgrade-charm
<natefinch> ericsnow: (for charmstore charms)
<ericsnow> natefinch: if I recall correctly, for resources we chose to follow the precedent of charm handling for deploy
<ericsnow> natefinch: ergo, pull info on client-side
<ericsnow> (from charm store)
<natefinch> ok.. maybe we can discuss with katherine when she gets back later... we obviously need clientside support for --resources, but it would be nice to also have serverside support for clients that don't do that.
<ericsnow> natefinch: k, though I expect we'll punt on it for 2.0 :)
<voidspace> frobware: dimitern: note that Jay is out today and the networking hangout is not on (according to the calendar anyway)
<frobware> voidspace: ack
<voidspace> frobware: I've completed my self review (written it anyway)
<voidspace> frobware: would you like to see it and comment before I submit it, or shall I just submit?
<natefinch> katco: let ericsnow and I know when you're back. We need to discuss some scope issues around my current task
<natefinch> ericsnow: I was going to skip uploading metadata for resources whose revision hasn't changed... but that requires an extra round trip to the charmstore... do you think it's worth it?
<ericsnow> natefinch: nope
<natefinch> ericsnow: well, good :)
<katco> natefinch: ericsnow: o/
<natefinch> katco, ericsnow: moonstone?  Just want to clarify some questions
<katco> natefinch: sure
<katco> natefinch: standup
<cmars`> should i be able to bootstrap lxd on xenial now, with juju built from master?
<rick_h__> cmars`: Makyo mentioned that he got it running today
<Makyo> Wellll.
<Makyo> It wiped out my /etc/sudoers and now I can't do anything.
<rick_h__> ohhh
<cmars`> what?!! that sounds bad. for me, it seems to hang during bootstrap, and i wondered if anyone else had seen it
<cmars`> hangs after this: https://paste.ubuntu.com/15247197/
<rick_h__> rumor is master + lxd stable ppa is supposed to work?
<Makyo> cmars`: same problem, then times out after 10 minutes
<cmars`> which is weird, i can lxc exec into the container and it's just run cloud-init
<cmars`> Makyo: you're more patient than me :)
<cmars`> but good to know
<cmars`> Makyo: using lxd with zfs?
<cmars`> i almost wondered if it was so fast, we hit a race? :)
<Makyo> cmars`: ext4
<Makyo> + encrypted home
<Makyo> Er... whole disk encryped, I guess.
<cmars`> Makyo: same here (LVM, ecryptfs), but i'm using the zfs block storage for lxd, just a big file, I think. it really does help -- though i bet it'd be even faster if it was native
<cmars`> well, i'm going to open a bug then
<Makyo> I'll add my head
<rick_h__> cmars`: that sounds like the image problem that serge is working with Tom Barber on in the list
<rick_h__> cmars`: have a chance to poke at this ? https://lists.ubuntu.com/archives/juju/2016-February/006699.html
<rick_h__> or Makyo it soudns like?
<Makyo> Sure
<mup> Bug #1551440 opened: Can't bootstrap LXD on Xenial <juju-core:New> <https://launchpad.net/bugs/1551440>
<cmars`> rick_h__: yep, i think that explains it
<cmars`> thanks
<mup> Bug #1551440 changed: Can't bootstrap LXD on Xenial <juju-core:New> <https://launchpad.net/bugs/1551440>
<ericsnow> katco: FYI, the new cards are up
<katco> ericsnow: tyvm
<Makyo> rick_h__: cmars` the problem I ran into with sudoers was due to permissions installing lxd images. Disregard it.
#juju-dev 2016-03-01
<davecheney> software http://paste.ubuntu.com/15248178/
<perrito666> beautiful
<thumper> davecheney: ping
<thumper> davecheney: I have []someDocType, and a method Insert(docs ...interface{})
<thumper> is there an easy way to squich the former into the latter?
<thumper>  cannot use docs (type []historicalStatusDoc) as type []interface {} in argument to statusHistory.Writeable().Insert
<thumper> menn0: ^^ any ideas?
<thumper> nm
<thumper> found an easy soluntion
<menn0> thumper: sorry i'm on my way out to run an errand
<thumper> don't worry
<thumper> all sorted
<sinzui> katco: cherylj as a formality, can you approve we want to merge feature-resources into master http://reviews.vapour.ws/r/4007/
<thumper>     c.Check(importedHistory[i].Since, gc.Equals, exportedHistory[i].Since)
<thumper> ... obtained *time.Time = &time.Time{sec:63592390248, nsec:901470923, loc:(*time.Location)(0x3fc4ec0)} ("2016-03-01 13:50:48.901470923 +1300 NZDT")
<thumper> ... expected *time.Time = &time.Time{sec:63592390248, nsec:901470923, loc:(*time.Location)(0x3fc4ec0)} ("2016-03-01 13:50:48.901470923 +1300 NZDT")
<thumper> who can spot the difference?
<thumper> deepequals necessary?
<thumper> yep
<thumper> need jc.DeepEquals
<cherylj> sinzui: shipit!
<sinzui> thank you cherylj
<sinzui> ouch cherylj I cannot merge, sorry katco, feature-resources now conflicts with master https://github.com/juju/juju/pull/4569
<cherylj> :(
<davecheney> thumper: http://reviews.vapour.ws/r/4009/
<thumper> davecheney: shipit
<davecheney> thumper: thanks
<thumper> np
<davecheney> thumper: http://reviews.vapour.ws/r/4013/
<davecheney> another one for you
<davecheney> thumper: http://reviews.vapour.ws/r/4014/
 * thumper is out now
<thumper> probably back later tonight, because, you know, busy...
<davecheney> Hey thumper, look what we get noe
<davecheney> 	local error: bad record MAC
<davecheney> 	github.com/juju/juju/state/open.go:208: cannot create index
<davecheney> 	github.com/juju/juju/state/open.go:239:
<davecheney> 	github.com/juju/juju/state/open.go:83:
<davecheney> 	github.com/juju/juju/state/open.go:114:
<jam> mgz: bug 1549545 would be good to discuss when you're around
<mup> Bug #1549545: Bundle deploys fail at lxc-start when bridge br-eth1 is created <ci> <deploy> <maas-provider> <test-failure> <juju-core:Triaged by dimitern> <https://launchpad.net/bugs/1549545>
<mgz> jam, sure thing
<mgz> jam: I thought from the previius chatter dimitern had a pretty good idea what was up
<mgz> ...what is that... 'previius'? jesu
<jam> I think it is the Previous Prius
<jam> mgz: so, dimitern is working on making sure Juju 2.0 supports multiple nics, but since it doesn't yet, it seems that we shouldn't have the lab set up to require it.
<mgz> ehehe
<jam> I thought bug #1549545 was preventing us from getting a blessed release
<mup> Bug #1549545: Bundle deploys fail at lxc-start when bridge br-eth1 is created <ci> <deploy> <maas-provider> <test-failure> <juju-core:Triaged by dimitern> <https://launchpad.net/bugs/1549545>
<jam> and while it is a configuration we want to support, it wasn't supported in the past.
<jam> OR did we actually break a mode that was working previously?
<mgz> so, the reason we do is that it was a bug in 1.x to pick the wrong nic and fail, and the extra interfaces (and ordering of them) was to catch regressions to the handlign there
<jam> so we did regress vs 1.x behavior
<mgz> we can release with the bug and put it in release notes, so it's not blocking as such
<jam> where we only supported 1, but we detected which was the default gateway
<mgz> jam: yeah, see the history of the maas-1_9-deployer job say, 1.25 passes
<jam> mgz: so in CI, is any particular job always run on the same hardware in the same configuration? and it is just the Juju version that is changing?
<mgz> we try to do that. there are obviously a few exceptions
<mgz> maas can randomly pick different things to deploy on. here we have to use different bundles due to the format change, but they are roughly equivalent
<mgz> so, what we talked about yesterday in our standup,
<mgz> was making at least one of these deployer jobs have constraints so it only deploys on maas nodes with simple nic setup
<mgz> so we don't lose all coverage of bundle deployment on maas due to this issue for now
<jam> well ultimately it would suck to not support more than one network card as we roll out our big "network model" release.
<jam> but we may have to do that in the short term.
<jam> mgz: my concern is that we want to enable it as soon as we do have support
<jam> adding workarounds tend to end up left there
<dimitern> I'd appreciate a review on this really short and simple PR: http://reviews.vapour.ws/r/4019/
<dimitern> mgz, hey, can we have a chat about that br-eth1 bug?
<mgz> dimitern: see backscroll :)
<dimitern> jam, exactly my point fwiw - too early to depend on br-eth1 will work
<jam> dimitern: yeah, the shame is that "default-gateway" from 1.25 was sufficient for this, so we are regressing
<dimitern> mgz, jam, there is a regression with 1.25 vs master with more than one container bridge, sure - but it's being worked on
<jam> dimitern: what is "Empty" vs "IsNil" ?
<dimitern> and since I'm practically the only one working on it, it will take a few days
<dimitern> jam, well, I needed a schema.StringMap() that doesn't allow empty keys, and doesn't allow non-nil values as well.. so this came abotu
<jam> dimitern: your coerce makes it look like the error you get is that if something isn't empty it tells you it is empty
<jam> am I reading that correctly?
<perrito666> morning
<dimitern> jam, which test are you referring to?
<jam> morning perrito666
<jam> dimitern: I was just reading it wrong. Seems label is what goes in "expected".
<dimitern> perrito666, morning fellow OCR ;)
<dimitern> jam, ah, well - comments / suggestions are welcome :)
<jam> dimitern: commented
<frobware> dimitern, mgz, jam: once possibility for the br-ethX bug is that we don't bridge all interfaces until we land dimiter's changes.
 * frobware continues that possibility in standup
<voidspace> frobware: dimitern: dooferlad: dealing with son - be a few minutes late to standup
<dimitern> jam, thanks!
<dimitern> jam, thanks for the review, replied to all issues
<dimitern> frobware, got latest master and did go instal ghc/j/j/... now waiting for make check to finish and will see how bad's the merge
<frobware> dimitern: any conflicts?
<dimitern> perrito666, can you have a look at http://reviews.vapour.ws/r/4019/ while jam's back please?
<dimitern> frobware, will know in a few minutes, but a cursory diff against maas-spaces2 seems clean enough
<frobware> dimitern, voidspace: http://reviews.vapour.ws/r/4021/
<dimitern> frobware, looking
<dimitern> frobware, no conflicts btw \o/
<frobware> dimitern: great
<dimitern> frobware, as soon as make check is done I'm proposing it
<frobware> dimitern: thanks for the review
<dimitern> frobware, LGTM
<dimitern> :)
<frobware> dimitern: I think we should take that into maas-spaces2, want to wait for it to merge in master?
<mgz> $ ~/go/bin/juju version
<mgz> 2.0-beta2-vivid-armhf
<mgz> well, that was a pain
<dimitern> frobware, let's not merge it into maas-spaces2 yet I think
<frobware> dimitern: fair enough, but if xenial deployment is gating in CI then maas-spaces2 will fail.
<dimitern> frobware, that's ok for the time being I guess, if it's the only thing remaining even better :)
<perrito666> dimitern: hey, just came to the computer, lemme see
<dimitern> perrito666, tyvm! I've said I'll rename Empty to Nil, but haven't pushed that yet - will do in a few minutes
 * dimitern haven't seen 2 make check runs in a row to both succeed in quite some time now..
<dimitern> voidspace, frobware, here's the merge - since there were neither test failures nor conflicts, I vote to just $$merge$$ it
<dimitern> https://github.com/juju/juju/pull/4583
<frobware> dimitern: agreed.
<frobware> dimitern: go for the hat-trick :)
 * dimitern types $$merge$$ and hits comment
<voidspace> cool
<dimitern> :)
<perrito666> dimitern: ship it
<jam> mgz: so what is going to be the best way to fix things for platforms I don't have (ppc, arm64, etc)
 * perrito666 tries to ingest some sort of caffeine
<dimitern> perrito666, jam, cheers!
<mgz> jam: ppc64 and arm64 is probably easiest using the machines CI has
<mgz> there are credentials for the stilsons and the new arm bits in cloud-city
<jam> mgz: so is that grabbing cloud-city and going to town? or what's the handshake around that?
<mgz> and yeah, say on irc that you're using a machine for informational purposes
<mgz> you're unlikely to clash with active CI runs/the release process anyway
<mgz> but can ask if unsure
<frobware> jam: curious as to why you think we'd move to only bridging a single NIC as the default -- assuming I read that (email) correctly.
<dimitern> perrito666, frobware, voidspace, jam, please have a look when you can at the next PR in line: https://github.com/juju/charm/pull/191 - extra-bindings in metadata
<jam> frobware: that we're moving to bridging *all* NICs as default
<jam> was what I was intending to say.
<jam> frobware: I thought that was what you were proposing as a "fix"
<jam> was it not?
<jam> dimitern: the extra-bindings names should *not* be the same as peer relations
<jam> we went with option 1
<jam> which is all relations implicitly have bindings.
<dimitern> jam, how about provides/requires ?
<jam> dimitern: btw, my original confusion with "Empty" was because I thought it was a GoCheck Checker not a Schema one.
<jam> dimitern: right all relations have a binding
<frobware> jam: my proposed fix was to bridge 1 nic (agreed). but the way I read your email implied that would be our ongoing fix. perhaps I just misinterpreted that.
<dimitern> jam, I suspected as much :)
<jam> if we went with plain "bindings" then it would be you could list matching ones, but since we are doing "extra-bindings" you really should only specify ones that aren't listed elsewhere, I think.
<dimitern> jam, ah, got you
<jam> frobware: ah, it is "Reverting all" I missed the word reverting.
<jam> frobware: do we know why it breaks if all of the containers are bridged? That seems odd.
<jam> is it that the containers don't get the right default gateways to match the host?
<dimitern> jam, that makes sense, so the PR should include tests ensuring extra bindings names do not match relation names?
<jam> dimitern: yes. I think it is a charm schema failure if you duplicate the names.
<frobware> jam: don't know. was trying to reproduce to understand and validate the proposal to revert to just one bridged nic.
<jam> frobware: sure
<dimitern> jam, that wasn't clear to me from the spec, but now it is, thanks - will adapt the PR accordingly
<jam> mgz: just to confirm with you, is it ok if I create a development directory on stilson-05 to try to reproduce some of the test failures on ppc ?
<jam> cherylj: I believe that tych0's patch does help with the CI regressions: github.com/juju/juju/pull/4564
<jam> I'm just hesitant to land it myself since I broke stuff the last time I did that.
<perrito666> my first OCR day without coffee is hell
<dimitern> jam, frobware, updated https://github.com/juju/charm/pull/191 as discussed earlier
<frobware> dimitern: any chance you could drop on to the standup HO?
<dimitern> frobware, yeah, omw in 2m
<jam> perrito666: well clearly you should get coffee then
<marcoceppi> cherylj katco are resources in beta1?
<mgz> jam: sorry, was out for lunch, yeah, create a new dir in home, set GOPATH to it, is what I normally do, pull tarball from reports.vapour.ws as needed
<jam> mgz: it has limited network connectivity, right?
<mgz> jam: it should be able to reach out to streams.canonical.com etc
<rick_h__> marcoceppi: yes asked ger yesterday and it's there
<rick_h__> marcoceppi: uogrwde i think will be in beta2
<rick_h__> upgrade that is
<marcoceppi> kk
<urulama> resources in local only, that is.
<rick_h__> marcoceppi: we want to see if there's a good charm to enable resources in with beta2 and get a joint blog/email to the list between her folks and someone on your team marcoceppi
<rick_h__> marcoceppi: not sure if any good targets are in flight
<rick_h__> urulama: yes, local only atm
<marcoceppi> rick_h__: well I have a usecase for it for 2.0
<marcoceppi> and want to be able to test it out
<rick_h__> marcoceppi: cool
<marcoceppi> local is fine
<rick_h__> marcoceppi: i've asked them.to reach out to get a good real world.use case put together in the next couple of weeks so awesome
<marcoceppi> rick_h__: how about dtag, that a good enough use case ;)
<rick_h__> marcoceppi: :)
<dimitern> jam, frobware, voidspace, guys, sorry to be a pest, but I need to land this in order to continue with the last 2 remaining PRs for extra-bindings: https://github.com/juju/charm/pull/191
<frobware> dimitern: looking
<frobware> dimitern: is there a RB for this? I'm happy to comment in the PR, just asking as I didn't see one.
<jam> dimitern: responded
<jam> frobware: I thought the same, but it is vs "charm" not vs "juju" so no RB
<dimitern> frobware, no, it didn't create a RB diff for it again for some reason
<dimitern> jam, thanks!
<frobware> jam: ah, was on autopilot. thx.
<mup> Bug #1551743 opened: juju <command> --format {yaml,json} should be more verbose <juju-core:New> <https://launchpad.net/bugs/1551743>
<frobware> dimitern: reviewed. only concerns are about the type assertions
<dimitern> frobware, I've updated the comment with my original reply to jam's question - does it make better sense now?
<dimitern> frobware, and thanks!
<frobware> dimitern: yep, comment helps. thx.
<mup> Bug #1551779 opened: New azure provider ignores agent mirrors <azure-provider> <regression> <streams> <juju-core:Triaged> <https://launchpad.net/bugs/1551779>
<alexisb> frobware, I am on the hangout when you are ready
<frobware> alexisb: omw
<katco> sinzui: fyi: https://github.com/juju/juju/pull/4585
<katco> sinzui: will we be able to merge after, or do we need another bless?
<sinzui> katco: I not certain, was the merge simple?
<katco> sinzui: very. 1 line conflict
<katco> sinzui: and it was very obvious that feature-resources should have had the preferred change
<sinzui> katco: great. let's merge once your feature branch is current
<katco> sinzui: awesome, i'll let you know
<natefinch> gah, what the heck?  gopkg.in/juju/charmrepo.v1/csclient/params/params.go:37: undefined: charm.Reference
<ericsnow> natefinch: don't you mean charmrepo.v2-unstable?
<natefinch> ericsnow: ahh.. that's probably goimports
<ericsnow> natefinch: yeah, the default branch is v1...
<natefinch> ericsnow: thanks for catching that.. would have taken me forever to notice that
<ericsnow> natefinch: I've got my mind on the charm store and the charm store on my mind
<katco> ericsnow: lol
<natefinch> man, we have way too many packages called "testing"
<ericsnow> natefinch: I've starting switching to the XXXtest naming convention (a la the stdlib)
<katco> we really need a meta testing package to test for the number of testing packages present... like github.com/juju/juju/juju/testing/testing/tests_test.go
<natefinch> lol
<ericsnow> katco: I wish!
 * natefinch shudders and adds code to export_test.go :/
<mup> Bug #1551842 opened: Juju 2.0 Trunk launches disconnected nodes <juju-core:New> <https://launchpad.net/bugs/1551842>
<cherylj> hey frobware, are you going to backport a fix for bug 1550306 to 1.25?
<mup> Bug #1550306: 1.25.3 can't bootstrap xenial environments <landscape> <juju-core:Fix Committed by frobware> <juju-core 1.25:Triaged by frobware> <https://launchpad.net/bugs/1550306>
<voidspace> dimitern: ping
<natefinch> lol assertCharmsUplodaded
<dimitern> voidspace, pong
<voidspace> dimitern: never mind, scratch that
<voidspace> dimitern: following a different trail
<dimitern> voidspace, ok :)
<mup> Bug #1551842 changed: Juju 2.0 Trunk launches disconnected nodes <juju-core:New> <https://launchpad.net/bugs/1551842>
<katco> sinzui: https://github.com/juju/juju/pull/4585 there are no conflicts with master now
<katco> ericsnow: natefinch: merged master into feature-resources again. consider rebasing.
<sinzui> thank you katco
<ericsnow> katco: thanks
<natefinch> katco: huzzah, thanks for that
<frobware> cherylj: yes, but was looking at a fix for bug #1549545 first
<mup> Bug #1549545: Bundle deploys fail at lxc-start when bridge br-eth1 is created <ci> <deploy> <maas-provider> <test-failure> <juju-core:Triaged by frobware> <https://launchpad.net/bugs/1549545>
<dimitern> natefinch, ericsnow, juju/charm.v6-unstable is broken since https://github.com/juju/charm/pull/189 due to not updating juju/utils deps I believe
<cherylj> frobware: is it an easy backport?
<frobware> cherylj: yes
<cherylj> frobware: I'll give it a try
<frobware> it's not a straight cherry pick
<ericsnow> dimitern: k
<mup> Bug #1551842 opened: Juju 2.0 Trunk launches disconnected nodes <juju-core:New> <https://launchpad.net/bugs/1551842>
<katco> sinzui: please lmk when we're merged into master
<frobware> cherylj: let me look at 1.25 - shouldn't take me too long.
<cherylj> frobware: is the problem specific to xenial on maas?
<frobware> cherylj: yes
<frobware> cherylj: backport done - needs follow-up live testing on precise, trusty, wily and xenial. bbiab.
<katco> natefinch: how difficult are those tests turning out to be?
<natefinch> katco: blech.  I'm having to cargo cult a bunch of stuff from the deploy tests.  Those tests are internal and mine have to be external, due to circular imports, so I'm having to copy & paste a bunch (or edit hundreds of lines of test code to export the existing test infrastructure that was written non-exported).
<cherylj> frobware: I can help with testing
<natefinch> katco: that being said, I have the infrastructure working and can deploy starsay during tests with full charmstore support
<katco> natefinch: well at least there's that :)
<natefinch> katco: so, the hard part is mostly done, now I just have to write the actual tests, which shouldn't be too bad
<katco> natefinch: yippee :D
<mup> Bug #1551857 opened: juju 2.0 Beta1: ERROR zip: not a valid zip file while deploying invalid yaml bundle <oil> <juju-core:New> <https://launchpad.net/bugs/1551857>
<natefinch> ug... the empty charmstore stuff is failing validation, so it kills my tests...feh.
<natefinch> ericsnow: booooooo... was looking for the resource persistence stuff... remembered it lives in juju/state now :/
<ericsnow> natefinch: gee, thanks for reminding me :P
<natefinch> ericsnow: lol
<ericsnow> natefinch: puzzling through the charmstore full-stack tests right now, so you got me at a cheerful moment <wink>
<natefinch> ericsnow: hmm... this produces zero-value resources: https://github.com/juju/juju/blob/master/state/resources_persistence.go#L88
<natefinch> ericsnow: (since there's no resources being returned from the store)
<natefinch> ericsnow: which results in empty resources being put in the CharmStoreResources, which fail validation
<ericsnow> natefinch: ah, crappy
<ericsnow> natefinch: I was going to fix that and forgot
<natefinch> ericsnow: this whole "write the client before the server exists" is kind of a giant PITA
<ericsnow> natefinch: agreed
<ericsnow> natefinch: as far as that bug goes, we need to be sure that we set the "store" resource at the same time we set the resource during deploy/upgrade-charm
<perrito666> uff, I am tired of deprecating code
<natefinch> ericsnow: I was pretty sure we're doing that... sure seems like it, but maybe I'm missing something
<katco> ericsnow: natefinch: are you 2 able to do the standup half an hour earlier? wallyworld and i have a conflict
<natefinch> katco: yep
<ericsnow> katco: fine with me
<katco> natefinch: ericsnow: ta
<ericsnow> natefinch, katco: I'm so glad I have to run an actual elasticsearch server in order to run the charm store test suites! :P
<wwitzel3> lol
<katco> ericsnow: ....... ...
<katco> ericsnow: i don't know what to say to that. it's obvious to at least me that this is non-optimal
<natefinch> lol
<ericsnow> katco: I'd better not say anything else
<natefinch> obviously, elasticsearch has been finely tuned and optimized, so running any kind of a mock would be slower
<wwitzel3> plus the format elasticsearch returns is just hard to mock
<katco> wwitzel3: did you notice how we all just casually ignored you?
<wwitzel3> pesky json
<natefinch> katco: so, just like old times? ;)
<katco> zing!
<wwitzel3> yeah, natefinch nailed it, how is that any different :P
<wwitzel3> I have a NLP plugin for my client that detects when ericsnow is being sarcastic and automatically sends a lol
<perrito666> it is different in the fact that wwitzel3 does not have to deal with these tests :p
<katco> wwitzel3: lol
<natefinch> Must have a bug, since we haven't been spammed by lols ;)
<ericsnow> wwitzel3: you need to tune it because I've been a lot more sarcastic lately and haven't see your lol <wink>
<wwitzel3> hah, well there is consensus on that at least :)
<katco> wwitzel3: i have been seriously concerned with the dangerously low level of tattoos on our team since you left. i'm trying to convince ericsnow to get a python facial tatt.
<wwitzel3> neck is better
<ericsnow> katco: forehead
<katco> ericsnow: we can start calling you snake
<katco> ericsnow: "snake, the gopher eater"
<natefinch> really, after eric shaved his head and got the eyebrow piercing, I think all bets are off
<natefinch> katco: these tests are going slower than expected... I think there's some bugs in the code that they're finding, but figuring out exactly where it is, is kinda slow going (since they're full stack tests.....)
<katco> natefinch: want to hop in a hangout and pair?
<natefinch> katco: sure thing
<katco> natefinch: i'm just in moonstone. putting some water to boil on
<katco> natefinch: rather, water on to boil
<perrito666> katco: clearly moonstone hangout has better features than tanzanite, ours is only good for chatting
<perrito666> :p
<natefinch> katco: coming
<katco> ericsnow: moonstone if you have a moment
<thumper> menn0: http://reviews.vapour.ws/r/4008/ updated
<thumper> menn0: also http://reviews.vapour.ws/r/4015/
<thumper> menn0: would also like to talk about this new package for managing migration, and where to put it and what to call it
<menn0> thumper: will look first
<menn0> at reviews
<menn0> and then talk?
<thumper> sur
<thumper> e
<menn0> thumper: ship it (with 2 non-issues) for http://reviews.vapour.ws/r/4008/
<thumper> menn0: cheers
<menn0> thumper: ship it on the other one too
<mup> Bug #1551959 opened: juju-tools 1.25.0 with juju-agent 1.25.3 has networking issues <juju-core:New> <https://launchpad.net/bugs/1551959>
<mup> Bug #1465307 changed: 1.24.0: Lots of "agent is lost, sorry!" messages <landscape> <regression> <juju-core:New> <https://launchpad.net/bugs/1465307>
#juju-dev 2016-03-02
<mup> Bug #1552021 opened: lxd not enough arguments in call to manager.CreateContainer <centos> <ci> <lxd> <regression> <test-failure> <wily> <xenial> <juju-core:Incomplete> <juju-core machine-provisioning-status:Triaged> <https://launchpad.net/bugs/1552021>
<perrito666> Sso login is really painful on a cell phone
<davecheney> thumper: menn0, a small driveby https://github.com/juju/juju/pull/4591
<menn0> davecheney: will look in a sec once I've finished the other review I'm doing
<menn0> davecheney: ship it
<cherylj> Can I get a super quick review?  http://reviews.vapour.ws/r/4032/
<menn0> cherylj: looking
<menn0> cherylj: ship it
<cherylj> thanks, menn0!
<thumper> I desperately want someone to write a new test provider
<thumper> to replace dummy
<thumper> one that doesn't try to be too special
<thumper> just an in memory db of machines etc...
<wallyworld> thumper: friday afternoon job :-)
<thumper> ha
<wallyworld> menn0: not sure if you have time, this pr changes create-model. you may have backgroud jes knowledge that may be useful http://reviews.vapour.ws/r/4033
<wallyworld> it works live on ec2
<thumper> I want a base suite that has a db, with an environment, but no apiserver etc...
<thumper> is there one such base suite?
<menn0> thumper: state/testing.StateSuite
<thumper> menn0: cheers
<thumper> menn0: heh, that doesn't actually give me a valid provider...
<thumper> hmm...
<menn0> wallyworld: looking now (I'm OCR anyway)
<wallyworld> thats's why i picked on you :-)
<menn0> wallyworld: I thought it was because of my JES super powers :)
<wallyworld> that too - i was sucking up
<menn0> wallyworld: "--credential" refers to an entry in credentials.yaml?
<wallyworld> yep
<wallyworld> same as for bootdttrap
<wallyworld> same arg name
<menn0> nice
<menn0> and bootstrap too :-p
<wallyworld> nice because as admins testing stuff on aws, we don't need to supply credentials at all anymore for create-model
<wallyworld> qa folks were very happy
<menn0> wallyworld: no major issues, just minor stuff
<wallyworld> menn0: you rock, tyvm
<wallyworld> menn0: i did improve the credential handling to account for different types of credentials being passed in. if the user has specified any valid set of credential values for a given auth type, they will be used in preference to the controller ones
<wallyworld> we won't copy across controller values to result in different values all smooshed together
<menn0> wallyworld: awesome that sounds great.
<wallyworld> yeah, thanks for raising it
<menn0> wallyworld: could you take a quick look at this one: http://reviews.vapour.ws/r/4035/
<menn0> wallyworld: it's a mechanical only change
<wallyworld> sure
<wallyworld> menn0: much nicer
<menn0> wallyworld: thanks
<davecheney> menn0: here's a small one for you https://github.com/juju/juju/pull/4596
<wallyworld> davecheney: +1
<wallyworld> anastasiamac: if you get a chance, i'd love a review of http://reviews.vapour.ws/r/4037/ which adds detail to list-controller, plus a driveby fix of old env names
<anastasiamac> wallyworld: sure
<anastasiamac> looking \o/
<wallyworld> ty :-)
<wallyworld> bbiab, school pickup
<anastasiamac> wallyworld: have fun :D
<voidspace> dimitern: ping
<dimitern> voidspace, pong
<voidspace> dimitern: I'm moving ConvertSpaceNames out of the discoverspaces worker so that the provider can use it for constraints
<voidspace> dimitern: is it ok for it to live in apiserver/networkingcommon and for the maas provider to depend on the apiserver
<voidspace> dimitern: ?
<voidspace> dimitern: I can't see why not but I thought I'd check
<dimitern> voidspace, I'd prefer to put it in network/
<voidspace> dimitern: d'oh
<voidspace> dimitern: yeah, that's better
<voidspace> thanks
<dimitern> voidspace, to minimize the import loop / possible such issues
<frobware> dimitern, voidspace, dooferlad: please could we meet at 10past the hour for standup.
<frobware> jam: ^^
<dooferlad> frobware: +1
<dimitern> sgtm
<voidspace> sure :-)
<dimitern> voidspace, jam, standup?
<voidspace> dimitern: oops, sorry
<dimitern> dooferlad, frobware, I look how CI just proved me wrong - we have a #3689 curse on maas-spaces2
<dimitern> s/I/now/
<jam> Who do we ping for APT details?
<jam> I'm trying to understand why "apt-get install lxc/trusty-backports" can find "liblxc1/trusty-backports" but "apt-get install lxd/trusty-backports" can't find "lxc/trusty-backports"
<frobware> voidspace, dimitern: meeting
<dimitern> coming
<voidspace> frobware: dimitern: omw, sorry *again*
<Mmike> Hi, lads. When jujud (one that's running on the state servers) connects to mongodb replicaset (assuming i'm running juju-ha), is it always connecting to PRIMARY mongodb only, or sometimes reads can go from the SECONDARYes too? That is, what is the readPreference that juju uses when reading from mongo?
<Mmike> If I'm reading the code correctly it seems it's using .SetMode(mgo.Monotonic), which means sometimes reads can go from the SECONDARYes, but I'd like a confirmation, if possible :)
<jam> mgz: if you're around, what machine would be running "run-unit-tests-xenial-ppc64el" because it has a test failing that I can't reproduce on stilson-05
<jam> mgz: also, do we have any problems with clock skew on stilsons? I just saw a test fail in 400ms when it should have been waiting for LongWait to expire, which is 10s.
<frobware> dimitern, voidspace, dooferlad: I think we should cherry-pick the "can't bootstrap on xenial" change into maas-spaces2. We talked about this yesterday but this would help remove one of the voting failure we see in the maas-spaces2 CI results.
<jam> mgz: looks like the time thing was a red herring. it took 400ms to setup the assert, but the assert did fail after 10s
<dimitern> frobware, sounds good, yeah let's do it
<alexisb> frobware, ping
<mgz> jam: ppc64-slave is stilson-06 at present
<mgz> jam: are you running the tests throught the same run-unit-tests script when trying on -05? the specific setup of the lxc etc seems more likely to influence results than the  (generally minor) difference between the machines
<dimitern> dooferlad, fwiw "defaultsMap" in state.mergeBindings is no in any way related to network.DefaultSpace
<dimitern> not anymore that is
<jam> mgz: I'm just doing "go test -check.v" in a given subdir.
<jam> currently investigating a test that is flaky
<jam> passes about 9 in 10 times
<jam> but when it fails it was waiting 10s when it fails
<mgz> if you can do the subset like that it is the best way
<jamespage> jam, frobware, dimitern, alexisb: hey can we postpone or catchup by 1hr? I have a conflict I can't miss...
<alexisb> jamespage, yep I can make that happen, jam can you make that?
<dimitern> jamespage, ok, sure
<dimitern> jamespage, we have good news though ;)
 * jamespage is a bit excited...
<dooferlad> dimitern: since that change of mine is quite big and you had plenty of comments, would you like to have a hangout to discuss it? I expect it would move things along more quickly. If so, what time works for you?
<dimitern> dooferlad, sure, how about in an hour, after the openstack call?
<jam> jamespage: dimitern: frobware: does 3.5hrs from now work for you guys? Its getting into dinner-and-family time for me.
<dooferlad> dimitern: Sure. I don't have an invite to the OpenStack call so I can get on with another card until then.
<jamespage> jam: I could do right now if that's helpful?
<jam> works for me
<alexisb> sure
<jamespage> dimitern, frobware, alexisb? ^^
<jam> jamespage: alexis and I are in the hangout
<dimitern> jamespage, jam, alexisb, a bit late, but I can manage
<frobware> dimitern: it's on now
<jamespage> dimitern, can you do now?
<dimitern> sure
<jam> dimitern: we're there now
<dimitern> jam, frobware, http://reviews.vapour.ws/r/4038/
<mup> Bug #1552237 opened: socket.error: [Errno 110] Connection timed out while calling status() <oil> <juju-core:New> <juju-deployer:New> <https://launchpad.net/bugs/1552237>
<frobware> dimitern: reviewed
<dimitern> frobware, sweet! thanks
<dimitern> frobware, and I've just confirmed network-get works live with extra-bindings
<frobware> dimitern: \o/
<frobware> dimitern: so this (https://github.com/juju/charm/pull/192) has landed too. anything else right now to review?
<dimitern> frobware, there's one more, which I can propose now for preliminary review until I sort out it's prereq
<frobware> dimitern: point me at it before I hunker down with the bridge (br-eth1) problem.
<dimitern> frobware, proposing now, just a sec
<dimitern> frobware, http://reviews.vapour.ws/r/4042/
<frobware> dimitern: wow, that touched a lot of files.
<dimitern> frobware, it includes the PR you've reviewed already, so looking at individual commits might be useful
<frobware> dimitern: is it worth changing dooferlad's demo script and verifying this...?
<dimitern> frobware, definitely - the changes should be simple to add
<frobware> dimitern: do you have a branch that I could use that has all of this in one place?
<dimitern> frobware, I can paste the charms and bundle I used in case you want to give it a go later?
<dimitern> frobware, yeah, the maas-spaces2-extra-bindings2 includes all
<frobware> dimitern: I just thought a different (and existing) test scenario may help
<dimitern> dooferlad, hey, should we do the HO now?
<frobware> dimitern: can you paste the charms/bundle anyway
<dimitern> frobware, give me a sec
<dimitern> frobware, http://paste.ubuntu.com/15267040/ this is the bundle
<dooferlad> dimitern: 10 mins?
<dimitern> frobware, this is the client-nc metadata: http://paste.ubuntu.com/15267060/, tree: http://paste.ubuntu.com/15267048/, and hooks: http://paste.ubuntu.com/15267071/
<dimitern> frobware, and here's the same for server-nc: http://paste.ubuntu.com/15267062/ (metadata.yaml), http://paste.ubuntu.com/15267049/ (tree), http://paste.ubuntu.com/15267081/ (hooks)
<frobware> dimitern: could you dump all that in a github repo? seems like the nc would be another useful demo.
<dimitern> frobware, can do yeah - later tonight
<frobware> dimitern: thx, appreciated.
<dooferlad> dimitern: still doing some debug, but can stop if now is a good time.
<dimitern> dooferlad, well, now is as good a time as any :)
<dooferlad> dimitern: ring ring...
<dimitern> dooferlad, ah, let's use the standup HO as that invite came to my phone :)
<dooferlad> dimitern: doh!
<dooferlad> dimitern: there now
<natefinch> I love it when I find exactly the right function that I need in the standard library
<mgz> natefinch: oh, you're writing python?
<natefinch> mgz: lol
<mgz> :P
<natefinch> mgz: does python have a mime.FormatMediaType / ParseMediaType in the standard library?
<natefinch> FormatMediaType serializes mediatype t and the parameters param as a media type conforming to RFC 2045 and RFC 2616.
<mgz> yeah, I think it's hidden in email though
<natefinch> nice
<frobware> voidspace: ping. Please could you help out with a review of http://reviews.vapour.ws/r/4042/ - bug #1549545 is critical for master atm.
<mup> Bug #1549545: Bundle deploys fail at lxc-start when bridge br-eth1 is created <ci> <deploy> <maas-provider> <test-failure> <juju-core:Triaged by frobware> <https://launchpad.net/bugs/1549545>
<frobware> voidspace: the review and bug are not related. I'm just trying to make progress with the bug and that is a large PR.
<mup> Bug #1552274 opened: juju list-credentials inconsistencies between format output <juju-core:New> <https://launchpad.net/bugs/1552274>
<frobware> dimitern: can you jump into sapphire HO regarding your extra-bindings changes...
<dimitern> frobware, sure
<natefinch> dammit.... I hate it when I inevitably use a stdlib function that doesn't exist in our version of go :/
<katco> natefinch: hey, never got that estimate for the current card you're working on
<natefinch> katco: oh, sorry
<katco> natefinch: gj landing the last card btw
<natefinch> katco: thanks
<natefinch> katco: tomorrow for the new card, I think. Hopefully early tomorrow.. doesn't seem to bad.   It sucks, go 1.5 has a bunch of improvements in exactly the area this card needs.
<natefinch> katco: (mime type stuff for setting http headers etc)
<katco> natefinch: we don't need mime stuff do we?
<katco> natefinch: this is just comparing the name specified with the name in the metadata?
<natefinch> katco: there's functions for formatting the content-disposition, which is how you should set the filename
<natefinch> katco: we could set the filename some other way, but it would be non-standard
<katco> natefinch: ericsnow: moonstone plx, need to chat anyway
<natefinch> kk
<voidspace> frobware: dammit, missed that - sorry
<voidspace> frobware: looking now
<katco> ericsnow: natefinch: oh, also forgot to mention. urulama has an open invitation to our standup while this collaboration is going on
<katco> ericsnow: natefinch: so it will be fun to see him from time to time :)
<ericsnow> katco: cool
<cherylj> frobware: I'm seeing that I cannot deploy to a node with wily on 1.25.4 with or without your patch.  I can't get the cloud-init-output.log file from the node because networking doesn't seem to be working.
<cherylj> I'm trying it with 1.25.0 now to see if it's just a problem in  my env
<frobware> cherylj: ack
<frobware> cherylj: so I /think/ I had the same problems, but with precise. It was late last night when I tried so I assumed it was finger trouble. I did have success with trusty and xenial.
<cherylj> frobware: I was in the same boat last night :)  Had issues with precise, but not trusty
<frobware> cherylj: I'm also using daily images, not sure if that's a factor.
<frobware> cherylj: I didn't see an obvious way in MAAS in having released and daily. Removing daily is a pain because it has to reimport all images again.
<cherylj> frobware: I don't even know which I'm using.  I just used the gui to import precise and wily (no option for xenial)
<frobware> cherylj: so that sounds like you're using released. It's in "Settings" -> "Boot Images". Mine says: http://maas.ubuntu.com/images/ephemeral-v2/daily/
<cherylj> frobware: ah, yeah, I see:  http://maas.ubuntu.com/images/ephemeral-v2/releases/
<cherylj> thanks!
<cherylj> frobware: I was able to deploy with 1.25.0, so seems to be a problem with 1.25.4
<frobware> :(
<cherylj> I'm not sure how I can grab the cloud-init as the console I get with the libvirt tools doesn't seem to provide a way to capture the output
<frobware> cherylj: do you fancy bisecting at .minor releases?
<cherylj> and there's no password set
<cherylj> frobware: sure, I can do that
<cherylj> I'll try 1.25.2 now
<frobware> cherylj: so when I run into these problems during development I change the bridge script so that the first thing it does is 'passwd -d ubuntu'
<cherylj> oh nice
<frobware> cherylj: ... don't forget if you change add-juju-bridge.py you need to run make in provider/maas, then rebuild.
<frobware> cherylj: this particular light bulb went off once I tried to guess 1 to many times what butchering I had done to /e/n/i... :)
<cherylj> hehe
 * katco lunches
<frobware> cherylj: so with these same changes that I landed on master I am able to bootstrap precise
<cherylj> frobware: I was able to bootstrap wily too, the problem came when I tried to deploy
<frobware> cherylj: do you still have wily deployed? care to HO if so?
<cherylj> frobware: I just destroyed the environment and I'm trying out a deploy with 1.25.2
<frobware> ok
<voidspace> dimitern: LGTM (modulo that one logging tweak)
<frobware> voidspace: many thanks!!!
<voidspace> dimitern: although it looked big it's mostly tweaking stuff
<dimitern> voidspace, thanks!
<cherylj> frobware: not that this helps much, but I saw that it couldn't download tools because of no route to host:  https://private-fileshare.canonical.com/~cherylj/images/node-deploy-output-2.jpg
<frobware> cherylj: as a first pass I would verify that MAAS can deploy a precise node. let's take juju out of the equation.
<cherylj> I'm working on wily right now
<cherylj> But I was able to deploy wily with 1.25.0
<cherylj> and it also works with 1.25.2
<cherylj> wait, might've spoken too soon
<roryschramm> im having problems deploying via juju to openstack compute nodes. Im having to use juju-core 1.25.4 due to bug 1532167. However, the orchestration node has the x86 code installed and cant push that to ibm power... so doing juju add-machine fails for the power nodes
<mup> Bug #1532167: maas bridge script handles VLAN NICs incorrectly <addressability> <maas-provider> <network> <juju-core:Fix Released by frobware> <juju-core 1.25:Fix Committed by frobware> <https://launchpad.net/bugs/1532167>
<frobware> cherylj: why it it trying to download 1.25.99.1?
<cherylj> frobware: I changed the version number to distinguish that it was running with your patch
<dimitern> frobware, updated http://reviews.vapour.ws/r/4038/ it should be ready to land so the follow-up can as well
<frobware> aha
<frobware> dimitern: is this post voidspace's LGTM?
<frobware> dimitern: ah, no. Was my review comments. :)
<cherylj> frobware: well this is interesting.  with 1.25.2, I was able to ssh into the node, but then networking died as it was finishing cloud init
<dimitern> :)
<dimitern> I like how much simple the parseBind tests have become
<dimitern> simpler even
<dimitern> ok, time to go celebrate ;)
<cherylj> neato!  the passwd -d ubuntu worked and I can see the cloud init output log
<frobware> cherylj: try again, it's possible the ifdown -a; ifup -a was running
<cherylj> frobware: I saw as the cloud init log was scrolling by that it failed to download tools
<frobware> cherylj: what's the state of /e/n/i?
<cherylj> frobware: https://private-fileshare.canonical.com/~cherylj/images/eni.jpg
<frobware> cherylj: looks innocuous
<frobware> cherylj: ip route?
<frobware> cherylj: but this is dead without my changes, correct?
<cherylj> frobware: right, this is on 1.25.2
<frobware> cherylj: you're still testing 1.25.2?
<frobware> ack
 * frobware wonders why he doesn't have a jenkins instance that continually validates the simples
<cherylj> frobware: https://private-fileshare.canonical.com/~cherylj/images/ip-route.jpg
<frobware> cherylj: so don't see anything wrong
<frobware> cherylj: and your virbX is NAT'd?
<cherylj> frobware: yes
<frobware> cherylj: easier to HO maybe
<cherylj> frobware: sure, give me just a minute
<frobware> cherylj: I would still deploy via MAAS, validate that that deployed node can see the internet
<cherylj> frobware: okay, let me kick that off
<frobware> cherylj: at least it helps separate juju specific issues
<frobware> cherylj: I have a fix for bug #1549545 too, but could do with some 3rd party validation (hint hint) :)
<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>
<cherylj> frobware: haha  :P  let's figure out this one first
<frobware> cherylj: sure. but I got bored with that one. :P
<cherylj> heh
<cherylj> frobware: the node deployed in maas seems to be fine
<frobware> cherylj: so just to confirm 1.25.2 cannot deploy wily, from MAAS 1.9.0
<cherylj> frobware: seems to be the case
<cherylj> although surprising that we wouldn't have a test for this in CI
<frobware> cherylj: now that I pushed my branch ^^ let me try as well
<frobware> cherylj: yeah, this was my "simples" case above. Just a smoke test that you can bootstrap and fetch http://kernel.org/
<perrito666> toolstorage lacks a way to delete the tools?
<cherylj> frobware: I think bug 1551959 is the same issue I'm running into
<mup> Bug #1551959: juju-tools 1.25.0 with juju-agent 1.25.3 has networking issues <juju-core:New> <https://launchpad.net/bugs/1551959>
<frobware> cherylj: ahhh
<frobware> cherylj: without looking I'm guessing this is how we parse lines like dns-nameservers...'
<frobware> cherylj: yep
<frobware> cherylj: can reproduce. :( :( :(
<frobware> cherylj: so a known and fixed issue: https://bugs.launchpad.net/juju-core/+bug/1534795
<mup> Bug #1534795: unit loses network connectivity during bootstrap: juju 1.25.2 + maas 1.9 <maas-provider> <uosci> <juju-core:Fix Released by frobware> <juju-core 1.25:Fix Released by frobware> <https://launchpad.net/bugs/1534795>
<frobware> cherylj: I think we will have upgrade problems with the script.
<cherylj> frobware: how so?
<frobware> cherylj: so if I understood the bug you just referenced then 1.25.3 will come along and try to bridge something that may well be bridged already. We did discuss this one writing the script but ... :(
<cherylj> frobware: ah, I see.  However, in my case, I was not doing an upgrade
<frobware> cherylj: we talked about putting a sentinel in there but there's no guarantee that something else doesn't remove it.
<frobware> cherylj: I think we're gonna have to be a lot smarter...
<frobware> cherylj: no, 1.25.2 is busted because of 1534795
<frobware> cherylj: but 1551959 is something we should address for maas-spaces2, master and 1.25...
<frobware> cherylj: we should really really get MAAS to model bridges. we're endlessly futzing.
<frobware> cherylj: patch upon patch
<cherylj> frobware: :(
<frobware> cherylj: let's talk about some priorities.
<cherylj> frobware: in a call now, let me ping you
<frobware> ok
 * frobware sulks off as far as his teapot
<cherylj> heh
<roryschramm> is there a way to upload juju tools for multiple arches when bootstraping ie juju bootstrap --upload-tools?
<natefinch> who writes a decoder that can't handle all the outputs of the corresponding encoder?  Sheesh
<perrito666> natefinch: you do realize that we work in a project that had a set that did not take the output of get until recently :p
<natefinch> heh... yeah, and that's terrible
<natefinch> here's the context to my rant: https://groups.google.com/forum/#!topic/golang-nuts/ovxD01JNoBQ
<frobware> cherylj: I just bootstrapped precise on my change (1.25.4)
<frobware> cherylj: I changed two/three things:
<frobware> 1) add the passwd -d ubuntu in anticipation ...
<frobware> 2) changed enable-os-refresh-update from true to false
<frobware> 3) ditto for enable-os-upgrade
<natefinch> sigh
<natefinch> there's no juju destroy-controller --force?
<natefinch> ....so I guess we changed bootstrap and/or destroy-controller such that we can't destroy old controllers anymore (and by old, I mean like, a couple days old)?
<natefinch> http://pastebin.ubuntu.com/15269548/
<natefinch> ERROR invalid config: can't connect to the local LXD server: json: cannot unmarshal number into Go value of type string     .... dude, UX, geez.
<natefinch> wait wiat wait... it's bootstrap <controller-name> <cloud>? really?
<natefinch> not <cloud> <controllername>?  So someday when we want to improve the UX, we can make controllername optional?
<natefinch> also, that's the opposite of deploy
<natefinch> rick_h__: ^^
<rick_h__> natefinch: reading backlog
<cherylj> natefinch: kill-controller is the new destroy-controller --force
<natefinch> cherylj: ahh
<rick_h__> natefinch: right, it's controller-name cloud because you can do controller-name cloud/region
<rick_h__> natefinch: or just leave off cloud I think if you have a default, plus the credential and such
<natefinch> rick_h__: why couldn't you do bootstrap cloud/region controllername?
<rick_h__> natefinch: but controller-name is always required
<natefinch> rick_h__: will there ever be an option to just default to the same name as the cloud?  Seems like a lot of people will only have one controller
<rick_h__> natefinch: no, because we don't want that to happen
<rick_h__> natefinch: it makes the UI confusing when the cloud name and controller name are the same
<rick_h__> natefinch: it's why we're making the default model "admin"
<rick_h__> natefinch: because seeing the controller name the same as a model name is confusing
<rick_h__> natefinch: we want to shoot for more meaningful names vs shallow ones like that
<natefinch> rick_h__: I'm pretty sure everyone who has ever used juju before is going to be doing juju bootstrap amazon amazon
<natefinch> (or whatever)
<rick_h__> natefinch: we'll see, but I'd like to discourage that.
<natefinch> if you only have one, the name is meaningly
<natefinch> meaningless
<rick_h__> natefinch: it's not, the cloud name is meaningless :) You never interact with it other than bootstrap
<natefinch> I still think it's unfortunate that the order is backwards from deploy
<rick_h__> natefinch: the controller one is very meaningful as it's the thing you talk to all day
<rick_h__> natefinch: understand, but it's back to the optional arg is at the end
<natefinch> rick_h__: I hope never to have to type either except during bootstrap
<rick_h__> natefinch: well one turns into two turns into ... if we do this well at all
<rick_h__> natefinch: so I do hope you end up typing it as you move between controllers in different areas with different purposes
<rick_h__> that means we're successful in making juju essential to your use of things out there
<natefinch> rick_h__:  you say cloud is optional... what does it pick if I don't specify a cloud?  How can I see what the default is?
<rick_h__> natefinch: see PM
<rick_h__> natefinch: there's work we need to do that if you only have one credential setup that it just uses that
<rick_h__> natefinch: not setup that way currently
<rick_h__> natefinch: as you say, no sense asking you to tell me what cloud if I only know credentials for one
<natefinch> yeah
<rick_h__> natefinch: I completely see your point and there are times it feels backwards to me as well
<rick_h__> but we did think through a bit farther out and so have $reasons which may or may not turn out to be ideal
<natefinch> really, the mismatch with deploy is my biggest concern. I just know I'm going to get the args backwards all the time
<perrito666> rick_h__: did you just give reasons in php, not cool mate
<rick_h__> natefinch: understand, thanks for the feedback
<rick_h__> perrito666: oh come on...maybe it was...crap
<natefinch> ahh crap.... were there fixes landed in master to work with the new LXD?
<rick_h__> natefinch: yes
<rick_h__> natefinch: there's a bug folks are hitting that's getting chased down, but there's a work around in the bug I believe
<natefinch> rick_h__: I had reverted my version of LXD from the ppa to wily stable when they broke the ppa... nwo I guess they broke wily stable :/
<rick_h__> natefinch: yea, wily won't work because it's got to work with lxd betas
<natefinch> anyone have the name of the ppa handy?
<rick_h__> natefinch: https://launchpad.net/~ubuntu-lxc/+archive/ubuntu/lxd-stable
<natefinch> rick_h__: yeah, just found that with google, was going to ask if stable was the right one. Cool.
<cherylj> rick_h__: are you going to grace the onyx standup?
<rick_h__> cherylj: I can, linky?
<cherylj> rick_h__: n/m everyone left :)
<rick_h__> oh, then nope
<natefinch> rick_h__: just wrapped up the matching extension check on resource uploads, and it occurs to me, do we also enforce lack-of-extension?
<rick_h__> natefinch: thinking
<rick_h__> natefinch: I think so.
<natefinch> rick_h__: good, that requires no extra work :)
<rick_h__> natefinch: e.g. an extension might mean a compressed file being sent where an uncompressed was expected
<natefinch> rick_h__: yep
<katco> natefinch: moonstone
<katco> natefinch: sorry that sounded rude... moonstone when you have a sec
<katco> please
<katco> :)
<natefinch> katco: coming... sorry, was getting a snack
<menn0> thumper: just looking at your migration package PR
<menn0> thumper: I get how the import works but remind me how th export works. what would you call?
<menn0> thumper: never mind. I see it now. state.Export()
<menn0> thumper: ship it with one question
<perrito666> I really dislike juju conn suite
<cmars> anyone seeing machines/units get assigned "127.0.0.1" as their public address lately?
<mbruzek> Who worked on the juju deploy bundle.yaml ?
<mbruzek> So juju core deploying bundles/
<rick_h__> mbruzek: frankban
<rick_h__> mbruzek: and the team there
<mbruzek> Thanks rick_h__ and thank you frankban.
<mbruzek> I really like using it instead of deployer, but I think I found a small bug, which I just opened. frankban is on GMT timezone?
<cmars> close, UTC+1
<mbruzek> OK. Well I am not getting charms "exposed" when I set them like that in the bundle.
<mbruzek> That is still supposed to work right?
<mbruzek> I will talk with frankban about this more. Thanks for the info cmars
<thumper> menn0: cheers
 * thumper goes to look for the question
<thumper> menn0: I also would expect that the state connection was connected to the controller model, but it was pretty trivial to write it explicitly
<thumper> so better to show obviously getting the controller model, than just the model that state happened to be looking at
<thumper> explicit is better than implicit :)
<menn0> yep :)
 * thumper feels peckish
<thumper> but not sure if it is just a carb craving or not
<thumper> ...
<thumper> probably is
<mup> Bug #1552408 opened: list-credentials vs list-clouds key inconsistencies <juju-core:Triaged> <https://launchpad.net/bugs/1552408>
<mup> Bug #1552414 opened: juju deploy bundle.yaml does not honor exposed <juju-core:New> <https://launchpad.net/bugs/1552414>
<mup> Bug #1552414 changed: juju deploy bundle.yaml does not honor exposed <juju-core:New> <https://launchpad.net/bugs/1552414>
<mup> Bug #1552423 opened: Machines getting 127.0.0.1 for DNS / PUBLIC_ADDRESS <juju-core:New> <https://launchpad.net/bugs/1552423>
<mup> Bug #1552423 changed: Machines getting 127.0.0.1 for DNS / PUBLIC_ADDRESS <juju-core:New> <https://launchpad.net/bugs/1552423>
<thumper> ugh
<thumper> done it again
<thumper> developed on a local copy of my feature branch
<thumper> now I need to remember how to reset it back to upstream
 * thumper looks at the git man pages again
<menn0> thumper: you mean resync it with the upstream feature branch?
<thumper> yeah,
<thumper> was going to go 'git reset hard <hash>'
<thumper> is there an easier way?
<menn0> thumper: git pull --rebase upstream <branch name>
<thumper> I don't want to rebase it
<menn0> thumper:  you don't want your local changes?
<thumper> no
<thumper> I've branched off it into another one
<menn0> thumper: ok then git reset --hard upstream/<branch name>
<thumper> ah
<thumper> ta
<menn0> thumper: a branch name is just a reference to a commit hash so it can be used whereever you can use a hash
<thumper> menn0: http://reviews.vapour.ws/r/4048/
<thumper> menn0: and ta
<thumper> menn0: now I need to work out what next...
<perrito666> thumper: change your prompt to tell you what branch you are on
<thumper> perrito666: yeah... I should
#juju-dev 2016-03-03
<davecheney> ping, anyone OCR today ? http://reviews.vapour.ws/r/4040/
<davecheney> thumper: i'm currently seeing 1 in 3 landing attempts fail because mongo crashes with the usual bad mac error
<anastasiamac> davecheney: OCRs today according to Juju Team calendar r Andrew and Eric
<davecheney> cmars: thanks
<thumper> davecheney: I'm hoping that RSN we will just have mongo 3 where they have fixed that
<mup> Bug #1552469 opened: Credentials are not utilised when creating a hosted model <docteam> <juju-core:New> <https://launchpad.net/bugs/1552469>
<davecheney> thumper: menn0 https://github.com/juju/juju/pull/4611
<davecheney> as we talked about yesterday
<davecheney> this is part 1 of 2
<davecheney> to make sure that the apiserver knows all the ways we say that we're in upgrade state
<davecheney> and can convert all of them to the right ErrorCode
<thumper> done
<menn0> davecheney: your PR makes me cringe
<menn0> davecheney: can we not have a well defined "upgrade in progress" error in state
<menn0> davecheney: which the apiserver knows how to convert to it's "upgrade in progress" error?
<menn0> davecheney: the reason for state returning "upgrade in progress" are quite different from the error returned by the apiserver.
<menn0> davecheney: the upgrade in progress error from state is about an attempt to start an upgrade failing because an upgrade is already in progress
<menn0> davecheney: maybe it should just be a different error?
<davecheney> menn0: i agree
<davecheney> it's a disaster
<davecheney> to be clear, I'm not going to pass state.errUpgradeInProgreess up
<davecheney> but there are a bunch of "helper" (using that term very loosely) methods in apiserver/common/errors.go that translate one to the other
<perrito666> Uh big +1 to that
<thumper> wallyworld: hey
<wallyworld> hi
<thumper> wallyworld: got 5 min for a quick chat?
<wallyworld> sure
<thumper> 1:1
<mup> Bug #1552523 opened: Unable to deploy a wily or precise service with MAAS <maas> <network> <juju-core:Triaged> <juju-core 1.25:Triaged> <https://launchpad.net/bugs/1552523>
<wallyworld> anastasiamac: you'll hate me, but i'd love a review when you get a moment  http://reviews.vapour.ws/r/4052/
<anastasiamac> wallyworld: i won't hate u fo asking so nicely :D
<wallyworld> wait till you see the code :-)
<wallyworld> anastasiamac: sorry :-( another one if you have time http://reviews.vapour.ws/r/4053/
<anastasiamac> wallyworld: sure, m hald way thru the 1st... then will look at this one \o/
<wallyworld> yay, ty
<mup> Bug #1552589 opened: TestProvisionerObservesMachineJobs fails intermittently <intermittent-failure> <juju-core:Triaged by jameinel> <https://launchpad.net/bugs/1552589>
<fwereade> anyone free to talk me through the space-discovery login synchronisation a bit?
<fwereade> frobware, dooferlad_?
<fwereade> actually brb but ping me if you know it
<jam> quick review: https://github.com/juju/juju/pull/4614
<fwereade> jam, ship it -- the notification is yucky in the first place but it's not worth a rewrite to fix
<fwereade> frobware, dooferlad_ : in particular, ISTM that: it runs per-model but limits logins for everything; but works around that by only limiting logins until the first one that runs reports completion; but subverts *that* by always marking completion even when there's an error
<fwereade> frobware, dooferlad_ : any insights?
<fwereade> frobware, dooferlad_ : in particular my understanding is that this *is* only critical for the controller model (especially given that it's ineffective for later ones): can you think of a reason for me not to move it to the per-controller bit rather than the per-model bit?
<fwereade> frobware, dooferlad_ : ah, I'll ask voidspace
<voidspace> fwereade: ask me what... :-)
<fwereade> voidspace, huh, thought I'd PMed you to avoid spam
<voidspace> ah, you have I just didn't notice
<dooferlad> voidspace, fwereade, jam: standup?
<voidspace> dooferlad: frobware: just finishing a chat with fwereade - be right there
<frobware> voidspace: dooferlad: http://reviews.vapour.ws/r/4055/
<perrito666> morning all
<voidspace> frobware: you still need that review?
<frobware> voidspace: yes please
<voidspace> frobware: can you explain to me the change in provider/maas/environ.go
<voidspace> frobware: it's relatively esoteric
<frobware> voidspace: when the container starts it has no gateway, so it can start but can't do anything real.
<voidspace> frobware: doesn't setting juju_bridge_all_interfaces=0 make the code immediately following unroutable
<voidspace> frobware: yeah, that's the bug - I mean what do the changes do specifically?
<frobware> voidspace: we know the bridge-device the container is connected to (the param in the call) so we find the IP address for that specific device and make it the gateway
<voidspace> (I may have interrupted - sorry if so)
<voidspace> what does this do? uju_networking_preferred_python_binary %[1]q --bridge-prefix=%[2]q --one-time-backup --activate %[4]q
<voidspace> and:
<voidspace> juju_ipv4_interface_to_bridge=$(ip -4 route list exact default | head -n1 | cut -d' ' -f5)
<voidspace> dammit
<frobware> voidspace: ah, sorry. I was talking about the wrong file. :)
<frobware> voidspace: first bit, bridges all interfaces with the specified bridge prefix, in our case 'br-'
<voidspace> frobware: line 1046 in provider/maas/environ.go
<voidspace> frobware: won't juju_bridge_all_interfaces always be 0?
<frobware> voidspace: yes, I did that deliberately because if we merge this back from master into maas-spaces2 we should make that 1 in our branch. So, rather than continuously futzing with the changes we can choose the behaviour we want by specifiying 0 or 1.
<voidspace> frobware: ah... cool
<frobware> voidspace: the 0 behaviour is what we want on 1.25 too
<frobware> voidspace: so the if .. else ... serves as an example of how to drive the script for bridging all interfaces or just a specific interface.
<frobware> voidspace: I can add a comment for this behaviour.
<voidspace> frobware: yeah, that would be cool
<voidspace> frobware: not possible to test?
<frobware> voidspace: in terms of bridging all or a specific one?
<voidspace> frobware: the change has no test
<frobware> voidspace: there are existing tests cases that exercise the all or one behaviour.
<frobware> voidspace: this is a runtime thing... which I think is difficult to test in any meaningful way. Where & how would we bring interfaes up/down?
<voidspace> frobware: well, the finding of the ipv4 address should be testable with some mocking (the discoveryIPv4InterfaceAddress path)
<frobware> voidspace: ah, that one.
<frobware> voidspace: true.
<frobware> voidspace: it's a tradeoff though. this would disappear once we merge maas-spaces2.
<voidspace> frobware: you want to land it untested?
<frobware> voidspace: it's been live tested
<voidspace> frobware: heh, ok
<frobware> voidspace: let me think about it a bit...
<voidspace> frobware: it will live on in 1.25
<frobware> voidspace: nope, master only.
<voidspace> ah, ok
<frobware> voidspace: and, again, only for as long as we don't merge maas-spaces2
<voidspace> frobware: you have my LGTM with a comment about the missing test
<frobware> voidspace: ironically, the unit tests did not highlight that there would be a live failure.
<frobware> voidspace: https://bugs.launchpad.net/juju-core/+bug/1549545/comments/8
<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> yeah, I saw
<voidspace> :-/
<voidspace> basically impossible to unit test all possible networking scenarios
<voidspace> frobware: I found out why my tests were failing in a weird way
<voidspace> frobware: the maas provider caches the result of checking if spaces are supported on creation
<voidspace> frobware: so setting the capabilities after creating the provider has no effect - you have to do it first
<voidspace> down to 3 failures now
<frobware> heh
<fwereade> voidspace, hmm, how does discoverspaces work in an HA environment?
<fwereade> voidspace, it's in the singular runner, so... will logins ever be unblocked for non-master controllers?
<fwereade> voidspace, ah, ok, it will, but only because it's not blocked until we start the worker... which surely implies that logging in after that point is a matter of luck?
<fwereade> voidspace, I'm starting to think it's impossible without a persistent flag..? and I was really hoping not to have to change the apiserver. ah well
<voidspace> fwereade: :-(
<voidspace> back shortly, picking up the daughter from school
<voidspace> fwereade: (not a matter of luck as you bootstrap one machine - which does discovery and is blocked - and then you go HA.)
<fwereade> voidspace, what ensures that the client won't connect after the apiserver starts but before the discoverspaces worker starts?
<frobware> dooferlad: ping
<dooferlad> frobware: pong
<frobware> dooferlad: can you junp into sapphire HO?
<dooferlad> frobware: sure
<voidspace> fwereade: so, nothing stops login before the discoverspaces worker has startedc
<voidspace> fwereade: the intention of blocking logins was that bootstrap be synchronous so that spaces are available immediately after bootstrap completes
<voidspace> fwereade: non-master HA controllers never unblocking sounds scary
<voidspace> fwereade: although it shouldn't happen - as it's in a singular runner the worker shouldn't be started on non-master
<voidspace> fwereade: and login is only blocked if the worker is started (the channel is set the first time the worker is started)
<fwereade> voidspace, right; so, how do we prevent the bootstrapping client from logging in before the discoverspaces worker is started?
<voidspace> fwereade: hmm... that might explain a bug that frobware has seen that I haven't (bootstrap completing and *then* login being blocked)
<voidspace> fwereade: I've never seen it, but it's obviously timing related
<fwereade> voidspace, yeah, there's nothing stopping that afaict
<voidspace> there isn't, setting the channel before the worker is started would be problematic for non-master HA
<voidspace> fwereade: are you sure you don't want me to own fixing this?
<fwereade> voidspace, yeah; and I'm not entirely willing to be certain that we can't have problems if we manage to bring up extra controllers without waiting
<voidspace> we need a different way of doing this
<fwereade> voidspace, still think it's my problem really -- I'm trying to get my dependency-engine update of startEnvWorkers in
<voidspace> fwereade: maybe remove the blocking altogether until menno's work is done and then re-introduce
<voidspace> fwereade: that's only nearly as bad as just doing it for the controller and not per-model
<fwereade> voidspace, ...that's terribly tempting actually
<voidspace> fwereade: if it has to be fixed anyway
<fwereade> voidspace, ok, I will try just dropping the notification for now and see where it takes me
<fwereade> voidspace, thanks
<fwereade> voidspace, I'll let you know where I end up
<voidspace> fwereade: cool
<perrito666> bbl
<katco> natefinch: hey can you join us in moonstone rq?
<mup> Bug #1552804 opened: worker/metrics: intermittent data race <ci> <intermittent-failure> <juju-core:Triaged> <https://launchpad.net/bugs/1552804>
<frobware> cherylj: is bootstrapping xenial a gating issue for 1.25.4?
<cherylj> frobware: yes, I would say so.  It came up in the cross team call today
<cherylj> frobware: what are you finding?
<frobware> cherylj: that seems odd to me as you have to use daily images (i think) and there's a lot of shifting sand if you do that.
<frobware> cherylj: I've possibly spent a large part of the day looking at a non problem but last comment in bug #1550306 shows a correlation of xenial cloud-init failing and bootstrap failing
<mup> Bug #1550306: 1.25.3 can't bootstrap xenial environments <landscape> <juju-core:Fix Committed by frobware> <juju-core 1.25:In Progress by frobware> <https://launchpad.net/bugs/1550306>
<cherylj> :(
<cherylj> frobware: I'm still trying to get xenial images on my vmaas to test.  The controller ran out of disk space
<frobware> cherylj: the issues I saw with /e/n/i yesterday have definitely gone with today's images as /e/n/i is rendered differently. bad timing perhaps. or the curse of shifting sand.
<frobware> cherylj: I'm still surprised we would consider 1.25.4 x a-daily-build-of-xenial something that is gating.
<frobware> cherylj: as I've seen in the last 24 hours, daily images change...
<cherylj> frobware: If we can confirm that it is a problem with xenial, I think we could release and point to whatever bug we've opened against xenial cloud images
<bogdanteleaga> how do I get rid of all the params redacted thingie in logs?
<cherylj> bogdanteleaga: to see the redacted params?
<bogdanteleaga> yeah
<cherylj> bogdanteleaga: set logging level to trace
<cherylj> it will show you the contents
<frobware> cherylj: I haven't gone beyond bootstrapping today, but with the bridge script fix for xenial (1550306) I can still bootstrap with precise, trusty and wily.
<cherylj> frobware: can you deploy?
<frobware> cherylj: kinda run out of time now... :(
<bogdanteleaga> cherylj, thanks that did it :)
<natefinch> rick_h__: I assume the charmstore should have the same contract about push-resource matching the extension?
<katco> natefinch: ping?
<natefinch> katco: yo
<katco> natefinch: must have missed my previous ping ;p
<katco> natefinch: join us in moonstone?
<natefinch> katco: oh, crap, sorry
<katco> natefinch: lol nw
<natefinch> katco: new IRC client is totally screwing me up
<rick_h__> natefinch: yes
<mup> Bug #1552815 opened: ability to apply profile/config modifications to lxd containers <juju-core:New> <https://launchpad.net/bugs/1552815>
<mattyw> katco, ping?
<katco> mattyw: pong
<mattyw> katco, hey hey, pinging you as I thought you might have good intuition on this: when I come to destroy controllers I normally forget the name I've given them. I reckon juju status should tell you the name of the controller (and also maybe the model) it's displaying the status of. What do you think?
<katco> mattyw: hm
<katco> mattyw: that seems reasonable to me... maybe like a header at the beginning of status?
<katco> mattyw: especially in a world where you might be flipping between models very often
<mattyw> katco, yeah, what more or less exactly what I was thinking
<katco> mattyw: the name of the controller may not carry it's weight since there will likely only ever be 1? what do you think?
<mattyw> katco, I don't know, I think it would be useful to display it, even if it's only one, since the user has named it
<katco> mattyw: i mean i'd be fine with it. it's not like it would take up a lot of space
<mattyw> katco, I'll do it, and see how it looks
<katco> mattyw: cool
<mattyw> katco, wanted to get some initial feedback to check it wasn't a totally insane idea
<mattyw> katco, so thanks
<katco> mattyw: hth
<perrito666> back
<natefinch> ericsnow: wondering if ListResources in the charmstore should be ResourceMeta, to match Meta about charms
<ericsnow> natefinch: we need all the info about the resources, not just the meta portion
<natefinch> ericsnow: it's all meta, except the bytes
<ericsnow> natefinch: "meta" means the resource info from the charm metadata
<ericsnow> natefinch: a la resource.Resource vs. resource.Meta
<natefinch> ericsnow: in the charm package, sure.  It could have a different meaning in the charmstore...
<natefinch> ericsnow: we are calling id/meta/resources after all
<ericsnow> natefinch: naming conflicts aside, ListResources() needs to return the full resource.Resource from the charm store
<natefinch> ericsnow: resource.Resource is all the metadata about the resource :)  (metadata -> everything except the data-data, i.e. the bytes)
<ericsnow> natefinch: okay
<natefinch> ericsnow: anyway, I was just trying to keep with the conventions already there.  It's fine by me if we use ListResources
<ericsnow> natefinch: oh, this is not a match to charm Meta
<ericsnow> natefinch: it is the resource "meta" plus the other things that resource.Resource adds
<natefinch> ericsnow: I'm just talking about the function name to wrap the call to id/meta/resources
<ericsnow> natefinch: so more like the charm store's "entity"
<natefinch> ericsnow: as an aside, I think the charm/resource.Meta name was a mistake, since it's all metadata... that's possible more accurately called the resource definition (as defined in the metadata.yaml)...
<ericsnow> natefinch: there isn't an equivalent ListCharms on the client; I'd say let's stick with ListResources()
<natefinch> ericsnow: that's fine
<ericsnow> natefinch: hmm, I believe I originally called it Definition and someone pushed for Meta instead
<ericsnow> natefinch: (maybe remembering something else)
<natefinch> ericsnow: I remember something about definition too... not sure if that was this or payloads or what
<jcastro> jam: you're currently working on lxd/juju right?
<alexisb> jcastro, he is but is out for the day
<jcastro> ok so maybe you can help
<jcastro> the new lxd landed in ubuntu, so now I need to update the instructions: https://jujucharms.com/docs/master/config-LXD
<jcastro> since lxd-images is being deprecated
<jcastro> the nice bit is that lxd now includes the remotes for the images built in, so doing like `lxc launch ubuntu:14.04 my-test-container` Just works ootb.
<jcastro> my question is, will we need this step at all in our instructions or if the lxd provider will just snag the image and pipe the output to the user
<katco> jcastro: hey
<katco> jcastro: so the provider could certainly do that; however, one nice side-effect is that the provider will use any image named ubuntu-trusty
<katco> jcastro: so it's kind of nice that you can pre-build an image and the provider will just use it
<katco> jcastro: or use alternative images (i.e. not trusty)
<jcastro> ok so I should just change the import command to making an alias
<jcastro> oh wait
<jcastro> I just thought about what you said
<jcastro> so I can premake an image
<katco> jcastro: yep :)
<jcastro> and as long as it's aliased as ubuntu-trusty that just works?
<katco> jcastro: i expect we'll refine this if jam and tych0 haven't begun doing so already
<katco> jcastro: you may have to twiddle with where tools are pulled from
<pmatulis> jcastro: kindly open an informative docs bug and i'll jump on it
<jcastro> wait a minute
<jcastro> did you guys just give us image based workflows?
<katco> jcastro: but what i've done is bootstrapped a xenial host (i think), snapshotted it
<natefinch> jcastro: for local only, sure
<katco> jcastro: and then just alias that, and standup time is super quick
<katco> jcastro: shhhhhh
<jcastro> pmatulis: I think I can submit a PR, quick fix once I sort the command
<katco> jcastro: don't use the i word!
<natefinch> heh
<jcastro> marcoceppi: ^^ look what just happened!
<katco> no! nothing to see here. ignore the images behind the alias
<jcastro> right, I can see how that would be bad and unsupported
<katco> jcastro: more like off-brand. i'm sure solid workflows could be built off it
<marcoceppi> jcastro: oh, yeah, I knew about that ;)
<jcastro> hmm ok, so really the only thing we need to update is figure out how to make the ubuntu:14.04 remote image aliased to ubuntu-trusty on my local machine
<katco> jcastro: yeah
<alexisb> so jcastro I was chatting with jam about this this morning
<alexisb> we will be making some updates to the user experience on this
<alexisb> and I would love your input
<alexisb> I might schedule some time to chat
<jcastro> yeah, I kind of feel like, since LXD has remote images available already
<alexisb> pmatulis, the workflow for using lxd provider is in the release notes
<jcastro> and I do juju bootstrap, just spawn it, one less step for us
<alexisb> jcastro, yep
<alexisb> jcastro, we agree
<alexisb> but I dont want to loose the ability to tag an image and use it
<katco> alexisb: keep in mind mark's requirement that we be able to specify the image to use
<katco> alexisb: yep
<pmatulis> alexisb: jcastro is all over it. i'm on standby
<alexisb> katco, yep
<katco> alexisb: (goes into muppet mode) yep yep yep yep
<katco> uhhuh uhhhuh
<alexisb> :)
<katco> https://www.youtube.com/watch?v=vh3tuL_DVsE
<mup> Bug #1552523 changed: Unable to deploy a wily or precise service with MAAS <maas> <network> <juju-core:Invalid> <juju-core 1.25:Invalid> <https://launchpad.net/bugs/1552523>
<katco> ericsnow: standup time!
<marcoceppi> help! juju init doesn't work in beta1
<rick_h__> marcoceppi: there's nothing to init
<marcoceppi> rick_h__: dude
<marcoceppi> read the help output
<marcoceppi> now I hav to create the XDG_DATA path and stuff
<rick_h__> marcoceppi: it should be there with install for the cloud list
<rick_h__> marcoceppi: and the add-credential command is coming to esit that file
<mup> Bug #1456717 opened: TestUpgradeStepsStateServer fails <ci> <test-failure> <juju-core:Incomplete> <juju-core 1.25:Triaged> <https://launchpad.net/bugs/1456717>
<mup> Bug #1552948 opened: metricsmanager DB collection shouldn't be "global" <juju-core:New> <https://launchpad.net/bugs/1552948>
<marcoceppi> rick_h__: I need help, azure 2.0-beta1
<marcoceppi> demo in 45 mins
<marcoceppi>  it's asking for an auth-type
<marcoceppi> userpass
<cmars> marcoceppi, LP:#1544890
<mup> Bug #1544890: "ERROR the name of the model must be specified" when 'juju init' required <bootstrap> <juju-release-support> <juju-core:Triaged> <https://launchpad.net/bugs/1544890>
<cmars> i opened this before i realized juju init was going away, but still
<rick_h__> marcoceppi: heading toncomputer onw sec
<marcoceppi> rick_h__: I got it sorted
<marcoceppi> it's bootstrapping
<rick_h__> marcoceppi: k
<marcoceppi> was just getting a little tight, since it takes 20 mins to deploy and I couldn't get 2.0 to bootstrap
<marcoceppi> <3 the error messages, they were helpful
<rick_h__> marcoceppi: k, email sent with all the details I sent to another perosn as well
<rick_h__> marcoceppi: has sample file in it and such
<rick_h__> marcoceppi: in case it's giving you any grief
<marcoceppi> rick_h__: I used beta1 release notes to find what I needed to copy from environments.yaml
<rick_h__> marcoceppi: k
<marcoceppi> I already had ARM setup in alpha3 when it landed, thankfully
<marcoceppi> tried to use 1.25 though, and realized my mistake
<rick_h__> ah cool
<marcoceppi> so have to plow through with 2.0 for the demo
<rick_h__> you have the alpha gui?
<rick_h__> https://jujucharms.com/u/juju/juju-gui
<rick_h__> marcoceppi: ^ is the beta to work on top of juju 2.0
<rick_h__> marcoceppi: some bugs, but supposed to work
<marcoceppi> rick_h__: ack, no more ~yellow?
<marcoceppi> I just need it to show the model, everything else is cabs cabs cabs
<marcoceppi> thanks for the mail, looking forward to beta2!
<rick_h__> marcoceppi: it's still in ~yellow but wanted to move to a more 'public' space if we're going ot hand out a beta widely
<rick_h__> marcoceppi: so we'll put betas under ~juju from now on as it's more meaningful than yellow
<marcoceppi> rick_h__: cool beans
<cmars> i need to parse a user-facing string into an apiserver/params type in a couple of different api client packages. where is the best place to put such a ParseXYZ() function?
<cmars> wallyworld ^^ any suggestion?
<alexisb> wallyworld, I want you to know that marcoceppi reads release nots:
<alexisb> <marcoceppi> rick_h__: I used beta1 release notes to find what I needed to copy from environments.yaml
<wallyworld> cmars: one sec, just finishing standup
<alexisb> marcoceppi, I am sure that line just made wallyworld's day
<marcoceppi> alexisb: read the release notes? I live by them. esp for the 2.0 releases
<marcoceppi> it's like a little gift from core every few weeks
<alexisb> lol
<marcoceppi> fuck, I can't get rid of an errored unit
<marcoceppi> rick_h__: I found a fun gui bug
<wallyworld> alexisb: marcoceppi: you did just make my day :-) we put a lot of effort into those notes
<wallyworld> cmars: what sort of parsing?
<rick_h__> hatch: ^
<rick_h__> marcoceppi: what's up?
<marcoceppi> rick_h__: in the ~juju/juju-gui, if I got to remove units for a service, it just creates a new machine instead of removing the unit
<rick_h__> marcoceppi: i think they're on that one
<marcoceppi> cool
<marcoceppi> i just realized this whole demo is borked because cabs can't speak 2.0 api
<rick_h__> oh no!
<davecheney> oh uh
#juju-dev 2016-03-04
<anastasiamac> davecheney: r u moaning or is it exclamation?
 * hatch pokes his head in
<hatch> marcoceppi: that sounds very odd, can you file an issue with steps to reproduce?
<davecheney> anastasiamac: 10:52 < marcoceppi> i just realized this whole demo is borked because cabs can't speak 2.0 api
<hatch> marcoceppi: is this with juju 2.0 or 1.2x?
<marcoceppi> it's okay, i've become a reluctant expert at demo magic, all is well rick_h__ davecheney
<marcoceppi> hatch: I can actually reproduce it in 1.25 and released juju gui
<marcoceppi> as well as 2.0 and ~juju/juju-gui
<hatch> marcoceppi: yay a repruducable bug :D
<davecheney> huzzah!
<hatch> marcoceppi: if you are able to create an issue for it now, I can probably get someone on it tonight
<hatch> (which would be my preference) :D
<marcoceppi> hatch: I have to deploy another service
<hatch> marcoceppi: I just mean file an issue on github with steps for us to reproduce it
<rick_h__> marcoceppi: glad to hear it
<rick_h__> marcoceppi: how did it go?
<marcoceppi> rick_h__: great
<rick_h__> marcoceppi: <3
<mup> Bug #1553059 opened: Help output when killing a `shared model` is incorrect <juju-core:New> <https://launchpad.net/bugs/1553059>
<voidspace> dimitern: frobware: dooferlad: grabbing coffee
<voidspace> didn't see the time
<voidspace> be there in 5, sorry
<dimitern> voidspace, np, omw as well
<voidspace> right, omw
<fwereade> voidspace, would particularly appreciate your thoughts on http://reviews.vapour.ws/r/4060/
<dimitern> fwereade, cheers btw! I'm having a look and so far it looks great
<dimitern> fwereade, you've got a review
<voidspace> fwereade: ok
<voidspace> fwereade: you've added discoverSpacesComplete as a gate.Lock, but it doesn't appear to be used
<voidspace> fwereade: is it just there as a reminder, or can it be removed
<fwereade> voidspace, ...well spotted, that was left over from before
<fwereade> voidspace, thanks
<voidspace> fwereade: and TestSpaceDiscoveryRuns is not yet written I assume...
<fwereade> voidspace, yeah, the trouble there is that the existing tests use patched constructors which don't really work for dep engine workers
<voidspace> fwereade: will you leave the unlocker in the discoverspaces.Config definition
<fwereade> voidspace, I should probably just hack a quick patched-ctor test back in and move on, and worry about integrating everything together
<fwereade> voidspace, I thought I would, since I have tests both with and without it -- easy to drop if we don't need it, but I'd already written the code
<voidspace> yep
<voidspace> cool
<voidspace> fwereade: worker changes look good to me
<voidspace> fwereade: heh, moving ConvertSpaceName will conflict with my current branch that moves it to network package
<voidspace> fwereade: ah well...
<voidspace> it's going away altogether soon as well.
<fwereade> voidspace, cool
<voidspace> fwereade: yeah, all LGTM except the unwritten test and the left over gate
<voidspace> fwereade: thanks for your work here
<fwereade> voidspace, np, thanks
<rogpeppe2> mgz: yo!
<rogpeppe> mgz: why can't I copy a bzr repo from one place to another and have it work?
<mgz> rogpeppe: hey
<rogpeppe> mgz: i get "No repository present"
<mgz> did yoy not take the .bzr dir with the repo?
<rogpeppe> mgz: i did
<rogpeppe> mgz: there's no difference between the dirs (according to diff -r)
<mgz> do `bzr info -v` will tell you where it is
<rogpeppe> bzr: bzr: ERROR: No repository present: "file:///home/rog/tomb/"
<mgz> right, so where was the original?
<rogpeppe> mgz: in ~/src/go/launchpad.net/tomb
<rogpeppe> mgz: ah!
<mgz> the other thing is, you can bzr push from the original location to... more things than you'd expect from other vscs, works to filesystem at least
<rogpeppe> mgz: i think it must be a cobzr artifact
<rogpeppe> mgz: i don't have the problem if i branch directly from lp
<rogpeppe> mgz: odd
<mgz> rogpeppe: yeah, and you can copy the whole dir structure without needing bzr and that will work too
<rogpeppe> mgz: that's what i did
<rogpeppe> mgz: and was expecting to work
<rogpeppe> mgz: but i needed to run bzr on the result
<rogpeppe> mgz: (to update deps)
<mgz> rogpeppe: but if the repo is at say, ~/src/go and the branch is at ~/src/go/launchpad.net/tomb you didn't take the actualy revision history
<rogpeppe> mgz: no, the repo is in the tomb dir
<mgz> but I'm not sure how cobzr confuses things exactly
<rogpeppe> mgz: neither me
<rogpeppe> mgz: i'm assuming it has an abs path somewhere
<rogpeppe> mgz: hmm, no, i'm still seeing the issue
<rogpeppe> mgz: have you got a moment or two to join a hangout?
<rogpeppe> mgz: 'cos i'm probably being totally stupid
<mgz> rogpeppe: sure
<mgz> hm, though if you can just suse a fresh branch that would be fine
<dimitern> frobware, dooferlad, voidspace, please have a look at http://reviews.vapour.ws/r/4064/ when you can
<dooferlad> dimitern: swap: http://reviews.vapour.ws/r/4002/
<dimitern> dooferlad, looking
<dooferlad> dimitern: thanks :-)
<dooferlad> dimitern: were you trying to find out the maximum length of a go function name?
<natefinch> lol
<dooferlad> TestAddLinkLayerDevicesRefusesToAddContainerChildDeviceWithNonBridgeParent seems to be winning.
<katco> ericsnow: natefinch: don't forget to complete your self-reviews + 360s by today
<alexisb> lol
<dimitern> dooferlad, yeah, that's the 3rd edition of the name, used to be longer :)
<dooferlad> dimitern: well, if we didn't use CamelCase it wouldn't fit on a screen
<natefinch> TestAddLinkLayerDevicesParentNameAsGlobalKeyFailsForContainerIfParentMissing
<ericsnow> k
<natefinch> katco: yep
<cherylj> frobware: ping?
<natefinch> ericsnow, katco: so, all the helpers for uploading bytes are in the csclient code, probably because UploadCharm etc exist only in csclient.  For now I'm just going to put the meat of UploadResource in csclient and lightly wrap it in CharmStore, unless you have another suggestion?
<katco> natefinch: i think that's fine, but want ericsnow to weigh in as he and wallyworld continued discussing after i had EOD.
<katco> natefinch: i think wallyworld's main point was just to use the same wrapper that the rest of core code was using
<katco> natefinch: annnd i think ericsnow just answered your question in email :)
<ericsnow> natefinch: Ian and I never actually got back together; I had to go before he had time
<natefinch> ericsnow: ok
<natefinch> ericsnow: I think we have to include the filename is resource POST (UploadResource), since the charmstore is going to do the same extension matching as the controller
<natefinch> ericsnow: I presume that'll just be another query parameter
<ericsnow> natefinch: we'll want to check with the UI team on that; they may not feel the need to be as careful about matching the file types
<natefinch> ericsnow: I asked rick_h__ yesterday and he said we want to do it :)
<ericsnow> natefinch: regarding code in charmrepo/csclient that we may need, we'll need to wrap those in the charmrepo package
<ericsnow> natefinch: k
<ericsnow> natefinch: I just sent a reply to that email about charmrepo.CharmStore vs. csclient.Client, explaining the intended design a bit more clearly (hopefully :))
<natefinch> ericsnow: btw, just edited your Resources in the Charm Store doc... upload charm uses hash=foo for the has, so I changed our hash param name to match
<dooferlad> frobware, dimitern: https://plus.google.com/hangouts/_/canonical.com/juju-spaces
<ericsnow> natefinch: thanks for syncing that up with prior art :)
<voidspace> dimitern: frobware: spaces meeting?
<dimitern> voidspace, uh sorry, omw
<dooferlad> dimitern: we stopped.
<dimitern> dooferlad, why so?
<dooferlad> dimitern: you and frobware weren't there. voidspace and I didn't have anything to report.
<dimitern> thedac, ping
<thedac> dimitern: hey
<dimitern> thedac, hey, sorry I got distracted - we should do a quick sync up though, if you don't mind
<thedac> dimitern: Would you be available at the bottom of the hour?
<thedac> I jumped into another meeting :)
<dimitern> thedac, yes, let's do it then
<thedac> sounds good. See you then.
<dimitern> cheers
<natefinch> ericsnow: what should upload resource return? The revision?
<ericsnow> natefinch: yep
<dimitern> dooferlad, you have a review
<dooferlad> dimitern: thanks. Nearly done with yours.
<thedac> dimitern: I am on the hangout now, whenever you are free.
<dimitern> dooferlad, quite a few issues I'm afraid, but let me know what you think
<dimitern> thedac, omw
<ericsnow> natefinch: did that make sense about charmrepo.Client vs. csclient.Client?
 * natefinch rereads
<frobware> dimitern, thedac: apologies for missing the call - I have water pouring out of my ceiling(s). :(
<natefinch> ericsnow: yeah, that's pretty much how I was thinking of it... though sometimes there's not much high level logic to put in charmstore :)
<frobware> dimitern, thedac: scrolling back - is the meeting on now?
<dimitern> frobware, yep
<thedac> frobware: it is
<ericsnow> natefinch: yeah, that was my objection...which would perhaps be more relevant if we were writing this new :)
<dimitern> frobware, are you coming as we're about to wrap up?
<frobware> dimitern: yes, omw.
<natefinch> ericsnow: the spec has PUT  /id/resources/name/?hash=foo&filename=bar ... just checking that the slash after name is intentional
<ericsnow> natefinch: not intentional
<natefinch> ericsnow: ok
<natefinch> ericsnow: good to know :)
<ericsnow> natefinch: (copy and paste error) :)
<natefinch> ericsnow: I'm not exactly sure how much it matters, but since I have to either type it or not, I might as well ask :)
<ericsnow> natefinch: note that I also added size as a query arg
<natefinch> ericsnow: do we need size?  we have the hash, so we can verify the contents
<katco> natefinch: ericsnow: was just thinking the same thing
<natefinch> oh, and we already put size in Content-Length
<ericsnow> natefinch: ah okay
<cherylj> frobware: you around?
<frobware> cherylj: yes
<mup> Bug #1553272 opened: help text for destroy-model needs improving <helpdocs> <juju-core:Triaged by cherylj> <https://launchpad.net/bugs/1553272>
<cherylj> frobware: I opened up bug 1553017 for the xenial deployment issues
<mup> Bug #1553017: Unable to deploy xenial on MAAS / resolv.conf not populated <open-iscsi (Ubuntu):In Progress by smoser> <https://launchpad.net/bugs/1553017>
<frobware> cherylj: yes, noticed this morning, thx.
<cherylj> smoser put in a workaround that I will try with your patch for bug 1550306
<mup> Bug #1550306: 1.25.3 can't bootstrap xenial environments <landscape> <juju-core:Fix Committed by frobware> <juju-core 1.25:In Progress by frobware> <https://launchpad.net/bugs/1550306>
<cherylj> frobware: one thing I did see, though, that seems to be unique to your patch for that bug ^^
<cherylj> When I deployed to that node that had 2 NICs set up for testing 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>
<cherylj> I couldn't juju ssh into it
<cherylj> I could ssh directly to the IP
<cherylj> and all the agents were running fime
<cherylj> fine
<cherylj> but just running juju ssh 1 didn't work
<cherylj> (i'm rebootstrapping after verifying that it worked properly with 1.25 tip, and will get you the error message then)
<frobware> cherylj: and the one thing is?
<cherylj> I can't juju ssh into the node
<cherylj> seems to only happen when I run with your patch for bug  1550306
<cherylj> juju ssh 1
<cherylj> Warning: Permanently added '192.168.100.150' (ECDSA) to the list of known hosts.
<cherylj> ssh_exchange_identification: Connection closed by remote host
<frobware> cherylj: dns issue.
<frobware> possibly
<frobware> cherylj: did you just apt-get update to get smosers changes?
<cherylj> from machine 0?
<frobware> cherylj: can we HO - might go a bit quicker.
<cherylj> on the maas-controller?
<cherylj> sure
<cherylj> https://plus.google.com/hangouts/_/canonical.com/cheryl-jennings?authuser=0
<mup> Bug #1553272 changed: help text for destroy-model needs improving <helpdocs> <juju-core:Triaged by cherylj> <https://launchpad.net/bugs/1553272>
<mup> Bug #1553272 opened: help text for destroy-model needs improving <helpdocs> <juju-core:Triaged by cherylj> <https://launchpad.net/bugs/1553272>
<natefinch> ericsnow: if you have a little time, sanity check my function signatures?  don't need a full review yet, just want to make sure we're on the same page. https://github.com/juju/charmrepo/pull/65/files
<ericsnow> natefinch: k
<katco> ericsnow: natefinch-lunch: rogpeppe is going to give us some reviews on our 1-pager
<ericsnow> katco: k
<ericsnow> natefinch-lunch: I left a few comments on that PR.
 * katco lunches
<rogpeppe> ericsnow: if you upload a new charm revision, does it have any resources by default, or do you have to put all the resources every time you upload a new charm?
<rogpeppe> katco: ^
<ericsnow> rogpeppe: they get associated when you publish
<rogpeppe> ericsnow: so resources aren't associated with a particular charm revision when you upload them?
<ericsnow> rogpeppe: correct
<rogpeppe> ericsnow: it might be worth mentioning that in the API docs
<ericsnow> rogpeppe: a resource revision may be associated with more than one charm revision
<rogpeppe> ericsnow: so unpublished charms can't have any resources?
<ericsnow> katco: ^^^
<ericsnow> rogpeppe: I don't see why not, but the only mechanism we have to tie resource revisions to a charm revision is publishing
<rogpeppe> ericsnow: that's my point
<rogpeppe> ericsnow: just checking
<rogpeppe> ericsnow: and can you "re-publish" the same charm revision several times with different resources?
<ericsnow> rogpeppe: yep
<rogpeppe> ericsnow: so that means that if you deploy (say) wordpress-4, you won't necessarily get the same thing each time?
<rogpeppe> ericsnow: even though you've specified the revision exactly
<ericsnow> rogpeppe: unfortunately yeah (this is a discussion we've had a bunch of times :/ )
<rogpeppe> ericsnow: that does seem bad
<ericsnow> rogpeppe: there's now a problematic implicit charm revision tuple (rev, res 1 rev, ...)
<rogpeppe> ericsnow: that skuppers reproducible charm deployment
<ericsnow> rogpeppe: we could discuss this with rick_h__ again...
<ericsnow> rogpeppe: I agree that it is a potential problem for that use case
<rogpeppe> ericsnow: that's really important, i think
<rogpeppe> jcastro: you got opinions on this jorge?
<ericsnow> rick_h__: we should make sure this is settled ^^^
<rick_h__> ericsnow: looking, otp atm but we'll see
<ericsnow> rick_h__: np
<ericsnow> rogpeppe: thanks for taking a look, BTW
<rogpeppe> ericsnow: np. i've been meaning to do it for ages, sorry.
<ericsnow> rogpeppe: it seems like the alternative is to make that implicit charm revision explicit: i.e. introduce a charm super-revision that maps to the revision tuple and use that to identify a charm "configuration" (poor name, I know)
<rogpeppe> ericsnow: yes
<jcastro> I am firmly in the reproduceability camp. marcoceppi ^^ wdyt
<ericsnow> rogpeppe: but then we'd have 2 different charm revisions, which is confusing
<rogpeppe> ericsnow: well, they're really different charms
<rogpeppe> ericsnow: if you consider that a charm is really that tuple of stuff
<marcoceppi> wait
<ericsnow> rogpeppe: depends on if by "charm" you mean the archive or the archive + resources
<rogpeppe> ericsnow: well, for the purposes of deployment it's gotta mean the latter
<ericsnow> rogpeppe: unless we have clear and distinct language for the two, this is going to confuse people
<ericsnow> rogpeppe: oh, I agree
<rogpeppe> ericsnow: as the resources influence the behaviour of the charm
<marcoceppi> ericsnow rogpeppe I agree with jcastro - the entire point of that revision is it's a moment in time that can be reproduced. If we're breaking that now it's not a good thing for the ecosystem
<ericsnow> rogpeppe: so "charm revision" would mean different things in different contexts
<rogpeppe> marcoceppi: i thought you'd say that :)
<rogpeppe> ericsnow: well, it's a good question
<rogpeppe> ericsnow: are resources specified in the charm metadata?
<ericsnow> rogpeppe: yep
<rogpeppe> ericsnow: so really, like bundles, it should be an error to upload a charm without some resources in place
<jcastro> ok so when the resource needs to be revved the charm metadata needs to change right?
<rogpeppe> jcastro: i hope not
<marcoceppi> jcastro: no
<marcoceppi> jcastro: resource revision is tracked in the store not in the charm
<jcastro> ack
<mup> Bug #1553292 opened: TestGoroutineProfile dial unix : no such file or directory <go1.5> <go1.6> <intermittent-failure> <juju-core:Triaged> <https://launchpad.net/bugs/1553292>
<ericsnow> jcastro: the *definition*  of the resource is provided in the charm metadata
<marcoceppi> jcastro: the problem is, you can rev charms and resources independantly of each other. So you could have resource+1 assocated to an existing charm which is technically a different experience
<ericsnow> jcastro: the resource file is on top of that
<rogpeppe> so in a way, it might make sense to specify a charm's associated resources at charm archive upload time
<ericsnow> rogpeppe: there's a chicken-and-egg problem though, no?
<rogpeppe> ericsnow: well yeah
<ericsnow> rogpeppe: resources should not exist without the related charm
<rogpeppe> ericsnow: :)
<marcoceppi> rogpeppe ericsnow it seems to me, if you rev a resource version, it should artificially rev the charm version. Since "resource-upgrades" invoke a charm-upgrade it would solidify that story.
<ericsnow> marcoceppi: we had discussed that, but I don't recall why we didn't pursue it
<rogpeppe> here's another possibility: a POST to /$id/bindresources will create a new charm id with some specified resources associated with the given charm id
<rogpeppe> and you ensure that you can't publish a charm to any channel unless all its resources have been bound
<marcoceppi> ericsnow rogpeppe we could track the charm version as `cs:[~user]/series/charm-ver+resource_ver` cs:~marcoceppi/trusty/wordpress-12+2`
<marcoceppi> or with a hash, I feel they're underutilized in the charm url schema wordpress-12#2 ;)
<rogpeppe> marcoceppi: wouldn't it have to be wordpress-32+resource1:4+resource2:3 ?
<ericsnow> rogpeppe: requiring all resources be there is already a requirement
<marcoceppi> oh, yeah :\
<rogpeppe> ericsnow: ok, but currently publishing doesn't create a new revno
<marcoceppi> rogpeppe: unless you considering a bundling of resources a version of that charm's resources
<ericsnow> marcoceppi, rogpeppe: yeah, this is a hairy mess
<rogpeppe> ericsnow: i'm proposing a primitive separate from publishing that makes a new revno
<ericsnow> rogpeppe: right, that is one of the sticky points
<rogpeppe> ericsnow: and you can then publish that
<rogpeppe> ericsnow: so any revno always specifies an exact (charm, resources) tuple
<ericsnow> rogpeppe: the question is, how to charmers and admins communicate about charm revisions?
<ericsnow> rogpeppe: you'd still want to talk about the revision of a charm archive, right?
<rogpeppe> ericsnow: i dunno
<rogpeppe> ericsnow: maybe; although a hash is just as useful tbh
<ericsnow> rogpeppe: agreed
<rogpeppe> ericsnow: or a commit number
<rogpeppe> ericsnow: charm revisions are pretty arbitrary tbh
<ericsnow> rogpeppe: but then we're changing the meaning of "charm revision" in a way that may confuse users
<rogpeppe> ericsnow: welcome to the brave new world of resources :)
<ericsnow> rogpeppe: exactly
<rogpeppe> ericsnow: but in other ways, we're keeping the important thing about charm revisions - if you specify a charm revision, you know what you're getting
<ericsnow> rogpeppe: this is why we've had this same discussion several times already. :/
<ericsnow> rogpeppe: right, I agree that is the important part
<ericsnow> rogpeppe: also, for charms without resources the meaning of "charm revision" will be the same
<rogpeppe> ericsnow: i think that this is less confusing to the real users, and charm authors won't take long to catch up
<rogpeppe> ericsnow: yes it will
<rogpeppe> ericsnow: it just means that the second part of the tuple is always constant
<rogpeppe> s/second/resources/
<ericsnow> rogpeppe: how about we always tie resources to a charm [archive] revision when we upload them, then other charm revisions may use existing resource revisions
<ericsnow> rogpeppe: the we don't need to add another API endpoint
<rogpeppe> ericsnow: how do you make a new charm revision with a different set of resources without uploading the archive again?
<ericsnow> rogpeppe: publish will require that the charm entity have all it's resources set
<rogpeppe> ericsnow: that doesn't answer the question AFAICS
<rogpeppe> ericsnow: if i've uploaded a charm and specified the resources to associate with it, and then i want to make a new revision associated with new resources, without uploading the same archive again, how can I do that?
<ericsnow> rogpeppe: hmm, you specify the resource revision explicitly during "upload"?  "publish" will support associating them, but that doesn't help with development charms, etc.
<ericsnow> rogpeppe: Perhaps you're right then about having an explicit endpoint  for tying charm to resource revs
<rogpeppe> ericsnow, marcoceppi, jcastro: unfortunately i have to go now
<rogpeppe> it's been a useful discussion, thanks
<ericsnow> rogpeppe: also, upload should be smart enough that it doesn't actually upload a resource blob that it already has (it should re-use the matching resource revision)
<ericsnow> rogpeppe: thanks for bringing it up!
<mup> Bug #1553298 opened: TestCloudInitWithGUI cannot fetch Juju GUI: cannot read Juju GUI archive: open \\gui.tar.bz2 on windows <ci> <regression> <test-failure> <windows> <juju-core:Incomplete> <juju-core embedded-gui:Triaged> <https://launchpad.net/bugs/1553298>
<mup> Bug #1553299 opened: TestCloudInitWithGUI cannot open posix paths on windows <ci> <regression> <test-failure> <windows> <juju-core:Incomplete> <juju-core embedded-gui:Triaged> <https://launchpad.net/bugs/1553299>
<mup> Bug #1553303 opened: TestCloudInitWithGUIError cannot open posix path on windows <ci> <regression> <test-failure> <windows> <juju-core:Incomplete> <juju-core embedded-gui:Triaged> <https://launchpad.net/bugs/1553303>
<mup> Bug #1553308 opened: Windows and Centos: Panic: unknown OS for series: "wily" <centos> <ci> <panic> <regression> <test-failure> <windows> <juju-core:Incomplete> <juju-core embedded-gui:Triaged> <https://launchpad.net/bugs/1553308>
<voidspace> bye all
<voidspace> have a good weekend
<natefinch> ericsnow: did you get a chance to peek at my PR?  Like I said I don't need a detailed review, as long as I'm basically in the right ballpark
<ericsnow> natefinch: yeah, I left comments
<natefinch> ericsnow: oh, huh, I expected it to refresh when I went from code to comments, but I guess it doesn't.  Thanks
<natefinch> ericsnow: in your comment, you say I'm missing the resoucre revision... do you mean on the arguments to upload?  Can you specify the revision number when you upload a resource?
<natefinch> re: https://github.com/juju/charmrepo/pull/65#discussion_r55062391
<ericsnow> natefinch: the comment relates to the last line in the snippet, not the first :)
<ericsnow> natefinch: GH code review, FTW
<natefinch> ericsnow: oh, yeah, that makes much more sense
<natefinch> ericsnow: yeah, GH code reviews, huzzah
<mup> Bug #1553320 opened: TestBootstrapGUIErrorInvalidVersion os.ProcessState exit status 2 <centos> <ci> <regression> <test-failure> <juju-core:Incomplete> <juju-core embedded-gui:Triaged> <https://launchpad.net/bugs/1553320>
<mup> Bug #1553322 opened: TestBootstrapGUIErrorUnexpectedArchive os.ProcessState exit status 2 on centos <centos> <ci> <regression> <test-failure> <juju-core:Incomplete> <juju-core embedded-gui:Triaged> <https://launchpad.net/bugs/1553322>
<rick_h__> ericsnow: natefinch katco did you all want to chat?
<katco> rick_h__: sure
<katco> https://plus.google.com/hangouts/_/canonical.com/moonstone?authuser=1
<natefinch> brt
<katco> marcoceppi: jcastro: want to join us? ^^^
<jcastro> marcoceppi: we need you ^^
<katco> jcastro: marcoceppi: ty for your input
<jcastro> <3
<mup> Bug #1553347 opened: juju bootstrap currently taking longer than 30mins <maas> <juju-core:New> <https://launchpad.net/bugs/1553347>
<alexisb> jcastro, what are you loving?  I missed it?
<rick_h__> alexisb: just some love passing between teams
<mup> Bug #1553347 changed: juju bootstrap currently taking longer than 30mins <maas> <juju-core:New> <https://launchpad.net/bugs/1553347>
<rick_h__> katco: around when you get time. Can you also link me to the kanban board you use please so I can prep?
<natefinch>  rick_h__ https://canonical.leankit.com/Boards/View/114568542#workflow-view
<rick_h__> ty natefinch
<mup> Bug #1553347 opened: juju bootstrap currently taking longer than 30mins <maas> <juju-core:New> <https://launchpad.net/bugs/1553347>
<katco> rick_h__: hey sorry, was talking things through with the team. available now if you are
<rick_h__> katco: np, otp atm but will ping when off
<katco> rick_h__: ok sounds good. give me a chance to make more tea :)
<rick_h__> katco: free now
<rick_h__> how bout your tea?
<katco> rick_h__: going to get it now :)
<katco> rick_h__: meet in moonstone?
<rick_h__> katco: link me please?
<rick_h__> google chrome won't autocomplete on moonstone for me yet, must not have used it enough times :)
<katco> rick_h__: haha https://plus.google.com/hangouts/_/canonical.com/moonstone?authuser=1
#juju-dev 2016-03-05
<mup> Bug #1460683 opened: TestEnvironProvisionerObservesConfigChanges fails <ci> <intermittent-failure> <test-failure> <juju-core:Triaged> <juju-core 1.22:Triaged> <https://launchpad.net/bugs/1460683>
<mup> Bug #1553539 opened: Win client cannot exec bash <bootstrap> <ci> <regression> <windows> <juju-core:Incomplete> <juju-core made-model-workers:Triaged> <https://launchpad.net/bugs/1553539>
#juju-dev 2016-03-06
<mup> Bug #1502314 changed: juju-deployer never completes landscape deployment to vmLDS <landscape> <falkor:Invalid> <juju-core:Triaged> <https://launchpad.net/bugs/1502314>
 * thumper heads out to go and choke someone
#juju-dev 2017-02-27
<wallyworld> that's a stock juju bug
<anastasiamac> wallyworld: ha, i clunged to "remote" :)
<wallyworld> :-)
<anastasiamac> wallyworld: do u recall if interactive bootstrap should work with builtin or personal clouds as well? I thought there was a limitation where we supported public clouds only...
<wallyworld> hmmm, not sure
<wallyworld> i didn't know of such a limitation
<anastasiamac> wallyworld: well, considering it doesn't work right now, we probably have a bug
<wallyworld> could be, the work was sort of half finished
<anastasiamac> wallyworld: i mean it works with both public and personal but not builtin.. i *think* i know where the problem is... will propose soon...
<rick_h> anastasiamac: wallyworld yea the rest of interactive bootstrap was meant to tie into the add-cloud work
<rick_h> The next step was to tie add-credential to the end of add-cloud and then update bootstrap to tie into add-cloud
<wallyworld> one day.....
<rick_h> Best laid plans...
<babbageclunk> wallyworld: quick review? https://github.com/juju/juju/pull/7037
<wallyworld> sure
<babbageclunk> wallyworld: thanks
<wallyworld> lgtm
<babbageclunk> wallyworld: cool cool
<mup> Bug #1667419 changed: Juju 1.25.10 non-HA cpu/ram usage spike (can't apply changes to env) <canonical-bootstack> <juju-core:Won't Fix> <https://launchpad.net/bugs/1667419>
<mup> Bug #1663633 changed: Juju 1.25.10: Conversation scope is missing sometimes - causes relation hook failure <juju-core:Won't Fix> <https://launchpad.net/bugs/1663633>
<mup> Bug #1663633 opened: Juju 1.25.10: Conversation scope is missing sometimes - causes relation hook failure <juju-core:Won't Fix> <https://launchpad.net/bugs/1663633>
<menn0> thumper: no joy replicating with juju 1.25.6 and mongo 2.4
<mup> Bug #1663633 changed: Juju 1.25.10: Conversation scope is missing sometimes - causes relation hook failure <juju-core:Won't Fix> <https://launchpad.net/bugs/1663633>
<thumper> menn0: hmm...
<menn0> thumper: yes?
<thumper> menn0: more the no joy
<menn0> thumper: I've been poking at it a bit more but I'm not seeing the problem
<thumper> not an interested hmm
<thumper> yeha
<thumper> yeah
<thumper> it sucks
<anastasiamac> menn0: thumper: is it possible that there was no env-uuid when the charm was deployed? so when it was upgraded, some transacations got *lost*? since there was no envuuid we could group them by?...
<thumper> no, there was clearly an env-uuid
<menn0> anastasiamac: I don't *think* so. transactions aren't being lost, just the txn-revno field
<jam1> menn0: joining us?
<babbageclunk> anastasiamac: Could you review https://github.com/juju/juju/pull/7038 plz?
<anastasiamac> axw: PTAL https://github.com/juju/juju/pull/7039
<anastasiamac> babbageclunk: sure \o/
<anastasiamac> babbageclunk: or we can swap :D and u could PTAL mine too...
<anastasiamac> babbageclunk: u make me swoon - u even updated a bug \o/
<babbageclunk> anastasiamac: I'm looking at yours now!
<axw> anastasiamac: reviewed
<anastasiamac> babbageclunk: axwawesome \o/
 * babbageclunk is too slow
<axw> veebers: to run CI, do I still need an environments.yaml for juju 2.x? seems like it, just wondering if I'm missing something
<anastasiamac> babbageclunk: u could break a tie - do u think that the method name should b the same as the other pkg but with different behavior... m not fussed either way :)
<axw> anastasiamac: I see where you're coming from, but the "Any" qualifier is pretty meaningless. If it were meaningful I'd have no problem with it
<veebers> axw this is with a juju-ci-tools test?
<axw> veebers: yup
<veebers> axw: yeah you'll want to use cloud city and set JUJU_HOME to it's path
<axw> veebers: ok, thanks. seems unnecessary
<veebers> axw it's how we enable being able to test 1.25.* and 2.* across any cloud using the same test code
<veebers> (it's grown out from testing just 1.25 and evolved from there)
<babbageclunk> anastasiamac: I think I'm with axw - the Any- prefix suggests some randomness or nondeterminism to me. CloudByName is better in this case.
<veebers> axw: is there (good) docs re: the difference between storage-unit, volume and filesystem?
<thumper> babbageclunk: where is our new proxy funcs?
<babbageclunk> thumper: where is your new proxy funcs more like
<babbageclunk> uh, I mean it lives in juju/juju/utils/proxy
<babbageclunk> thumper: with stuff to update the settings in proxyupdater and installing it as the default proxy in juju/juju/cmd/jujud/main.go
<thumper> looking at utils/proxy stuff now
<babbageclunk> thumper: not juju/utils/proxy though.
<thumper> right
<babbageclunk> thumper: I have seen some complaining about juju/juju/utils/proxy vs juju/utils/proxy and I am not unsympathetic to those complaints.
<thumper> babbageclunk: is there a reason we aren't moving one to the other
<thumper> ?
<babbageclunk> thumper: It didn't occur to me - it seems like the j/j/u/p stuff is specific to juju, while the j/u/p bit isn't? But maybe I should have just put everything in j/u/p?
 * thumper shrugs...
<axw> veebers: sorry was afk. I don't think so
<veebers> axw: nw, are you able to one-liner the difference? You did mention yesterday but obviously it didn't gel for me :-(
<axw> veebers: storage-instance is an instance of a charm-declared store. a volume is just a disk/logical volume, and a filesystem is... a filesystem. a storage instance will have an associated volume and/or a filesystem
<axw> veebers: so a storage instance is the association between a volume/filesystem and an unit (or application, when we have shared storage)
<veebers> axw: ack, thanks :-)
<anastasiamac> axw: PR for auth type in add credential: https://github.com/juju/juju/pull/7040 PTAL :D
<axw> anastasiamac: I think we should probably call cloud.CredentialSchema.Finalize on the input? there are other things in there that we should validate too
<axw> anastasiamac: Finalize will interpret the file attrs and replace them tho, so don't want that bit...
<anastasiamac> axw: oooh. k. did not know wbaout that :) i'll check after school pickup :D tyvm!
<axw> anastasiamac: maybe introduce a Validate method to CredentialSchema, which does what Finalize does from Coerce up
<anastasiamac> axw: that'd b neat coz it'll answer validation in other places too! great idea. i'll look into it further
<jam> axw: any chance you could review https://github.com/juju/juju/pull/7034
<axw> jam: looking
<jam> its not particularly small
<axw> jam: if I have subnet 10.0.0.0/8, can I have a static route for source=10.0.0.0/16?
<axw> jam: in MAAS I mean
<axw> jam: just wondering about the bit that looks up static routes based on the interface's subnet CIDR
<jam> axw: I believe so.
<jam> axw: that's actually how ante-et-al are using it
<jam> ceph-data is the 10.100.0.0/16 group of subnets
<jam> and each rack gets, say 10.100.1.0/24
<jam> and has a static route that says
<jam> "for anything in 10.100.0.0/16 use 10.100.1.1"
<axw> jam: so how does this work then? https://github.com/juju/juju/pull/7034/files#diff-e48e1166d15f27c5c7356ca4ee7000c0R282
<jam> axw: so a given device will be in a registered subnet, which may have static routes pointing at other listed subnets
<jam> but there isn't anything that says subnets don't overlap
<jam> axw: https://github.com/juju/juju/pull/7034/files#diff-9f2d224cfe3d5b5450772b51d95b625aR2176 is where we build up the map by listing all of the register static routes
<jam> each one has a "Source" subnet that states where it should apply
<axw> jam: but won't that end up with a key of 10.100.0.0/16, and the NIC is in subnet 10.100.0.0/24?
<jam> axw: so that's not how it works. In the config for Subnet 10.100.0.0/24 you set a destination of 10.100.0.0/16
<jam> and a magic gateway
<jam> axw: you always exactly match a 'local' subnet in the config
<jam> axw: IOW, you can't say "all machines in 10.100.0.0/16 use gateway 10.100.1.1" because not all of them have direct routes *to* that machine
<jam> so *each* /24 subnet needs to be told the preferred (generally the local) gateway to get to the rest of /16
<jam> axw: does that make sense?
<jam> 10.100.1.0/24 probably points to 10.100.1.1, 10.100.2.0/24 points to 10.100.2.1, etc.
<axw> jam: it makes sense, but that seems to be the opposite of <axw> jam: if I have subnet 10.0.0.0/8, can I have a static route for source=10.0.0.0/16?
<axw> jam: so multiple static routes: one per source subnet, each going to the same destination CIDR but via different gateways
<jam> axw: if you want to *reach* 10.0.0.0/8 you can create a static route with source=10.0.0.0/16
<jam> destination=10.0.0.0/8 but the gateway IP needs to be in your source range (I believe)
<axw> jam: sorry, I had that back to front :)
<axw> ok, all good
<jam> source is 'who I am' and destination is "who I want to talk to" and gateway "who do I send my letter to that will deliver it"
<axw> yeah, I just had my CIDRs back to front in my question
<jam> axw: if you can think of ways that I can document things to make it easier to pick up. I did add comments to network.Route https://github.com/juju/juju/pull/7034/files#diff-24ce41f044a5d947051b85bb10734d91R264
<jam> but if I can tweak that to make it more understandable, I'm certainly willing to.
<axw> jam: it's pretty clear. I think it might be helpful to add a comment that for the static routes coming back from MAAS, source is expected to exactly match the subnet on the device
<jam> axw: thanks for the review
<axw> np
<thumper> babbageclunk: ping-a-ling https://hangouts.google.com/hangouts/_/canonical.com/websocket-mania
<thumper> babbageclunk: can you join us please
<thumper> ?
<babbageclunk> thumper: sure
<jam> sinzui: thanks for pushing up a new bug
<jam> It seems the MAAS 2.0 *docs* say it supports an API that isn't actually there.
<sinzui> jam: oops
<jam> sinzui: oddly enough axw caught that I would have treated static-routes missing as being ok, and thought it would be poor to suppress the error
<jam> sinzui: seems I was right to be paranoid the first time.
<jam> sinzui: btw, I hopefully stopped my merge of 2.1 into develop cleanly, but I haven't clicked the "X" very often in case anything bad happens when you do it
<jam> sinzui: I'd like to add a targetted error trap for that error, is it possible to get access to the 2.0 MAAS so I can confirm the error code, etc?
<sinzui> jam: I will send you the ssh info. You may already have info for finfolk. but I have additional for the maas 2.0 itself
<jam> sinzui: thx
<jam> sinzui: I don't think I need to actually start anything, I just want to track the error messages, etc.
<jam> redir: ping
<jam> redir: Looking at your libvirt changes for KVM containers, it looks like we are trying to set guest device names for network interfaces. Did you see that actually working? Because my quick Xenial + Juju 2.2 test doesn't show it working.
<jam> redir: is there some place we can see the XML that was used to launch the container?
<jam> sinzui: I need to go to sleep (1am here). Any chance you could check if https://github.com/juju/juju/pull/7045 fixes this?
<jam> I think it will, but I don't really want to land it without testing it.
<sinzui> jam: I will follow the merrge
<babbageclunk> jam: are you ok with me merging 2.1 into develop now?
<babbageclunk> jam: or have you got something in flight that you want to include?
<jam> babbageclunk: actually its something we don't want to merge.
<jam> babbageclunk: my latest patch has a regression against maas 2.0. The above patch should fix that regression and then we'd be good to merge up.
<jam> babbageclunk: there is also a conflict in dependencies.tsv because of different gomaasapi versions, use the one in 2.1
 * jam sleeps
<babbageclunk> jam: yeah, I guessed that one - was going to check on the commit to be sure. So, I should hold off until 7045 lands?
<jam> babbageclunk: I'll merge up once 7045 lands, but if curtis approve it and it lands while I'm asleep, you're welcome to merge up
<babbageclunk> jam, ok cool - night!
<redir> jam pong HO?
<redir> do misse dyou
<redir> we cna HO tomorrow jam
<redir> easy review: https://github.com/juju/juju/pull/7035
<redir> PTAL
 * anastasiamac looking
<redir> tx anastasiamac
#juju-dev 2017-02-28
<rick_h> axw: howdy
<axw> rick_h: heya!
<rick_h> axw: question for you, I've gotten your prometheus work going on a controller and I'm pairing it with my repeated/parallel deploy thing I'm hacking on
<rick_h> axw: and I'm looking to put together a kind of "ootb stuff to watch" setup and curious if you have feedback on the most important/basic items to track out of the available prometheus data points
<rick_h> axw: especially stuff that might cause things to go boom? or things to keep an eye on?
 * axw thinking
<rick_h> axw: all good, and maybe I should do this over email and such
<rick_h> axw: but was sitting here and figured I'd try to catch you
<axw> rick_h: I guess I don't really know, because if I knew what to look for we wouldn't have the problem :)  I'd probably focus on mongo-related metrics to start
<axw> rick_h: so you might want to set up the mongodb exporter on your controller as well, if you haven't already
<axw> rick_h: we do show the txn ops executed by juju, but that doesn't tell you about growth of mem/cpu etc. in mongo
<rick_h> axw: no, haven't set that up. Didn't run across that in any of the emails/notes/docs
<rick_h> axw: is that baked in or something extra to install/setup?
<axw> rick_h: it's a separate thing altogether
<axw> rick_h: https://github.com/dcu/mongodb_exporter
<rick_h> axw: ok cool ty. I'll take a look at that
<axw> rick_h: another thing that would be helpful is periodic CPU and memory profiles
<axw> rick_h: have you done that before?
<rick_h> axw: yea, in my first test I setup munin and used that to generate graphs across the testing time. https://goo.gl/photos/7Cj1FuSRgQeAt79Y8
<axw> rick_h: sorry, I mean pprof profiles
<rick_h> axw: but not done that with prometheus. This was my first foray into it
<axw> rick_h: pprof will give us source-code level information
<rick_h> oic, pprof no, but recall some notes/docs around those in the past
 * rick_h has to go for boy reading time
<rick_h> ty axw, lots to think over there
<axw> rick_h: on the controller machine, just use the command "juju-heap-profile" to get a heap profile
<axw> rick_h: periodically. that'll be good enough to start with
<axw> rick_h: enjoy :)
<wallyworld_> menn0: have you seen an issue where after running upa juju model with squid-deb-proxy in place, the squid process sits on 6-10% CPU and you need to restart squid-deb-proxy to reset it? happens everytime for me
<menn0> wallyworld_: no I haven't seen that and I use squid-deb-proxy
<menn0> wallyworld_: have you checked the squid-deb-proxy logs?
<wallyworld_> nothing obvious
<wallyworld_> menn0: do you use an apt proxy at all then?
<wallyworld_> oh
<wallyworld_> never mind
<wallyworld_> i see your answer
<menn0> wallyworld_: strace of the squid process?
<menn0> something is obviously keeping it busy
<wallyworld_> yeah, i'll look into it
<wallyworld_> after another deployment blows it up
<anastasiamac> wallyworld_: the work to bring in new aws regions on 2.1, did it include brining in new instance types as sizes too? do we pull it from AWS file or have our "copy" still?
<wallyworld_> we doesnload the aws json file and process it
<wallyworld_> we should have used the latest info
<wallyworld_> at the time
<wallyworld_> are there any instances types that are missing?
<anastasiamac> wallyworld_: https://bugs.launchpad.net/juju/+bug/1668307
<mup> Bug #1668307: support latest AWS instance sizes and types <juju:Incomplete> <https://launchpad.net/bugs/1668307>
<anastasiamac> wallyworld_: just checking what to say
<anastasiamac> wallyworld_: thnx
<anastasiamac> wallyworld_: and since u've already answered, ty x2
<wallyworld_> anastasiamac: i don't see that we support i3 as he wants
<wallyworld_> maybe those were a very recent additon to aws, would need to check
<wallyworld_> yeah, 4 days ago
<wallyworld_> according to google
<wallyworld_> we should aim to fix that for 2.1.1
<anastasiamac> wallyworld_: u blow my mind \o/ I should not ask u anything at release call :D must b lack of coffee - ur answer back then was 2.2
<anastasiamac> wallyworld_: if u can take it on for 2.1.1, feel free to update the bug and milestone plz
<wallyworld_> when?
<wallyworld_> today?
<anastasiamac> wallyworld_: this morning. it's even in the minutes! :D
<wallyworld_> lol, i don't even recall
<anastasiamac> wallyworld_: yep, m blaming it on coffee :D
<wallyworld_> did we really discuss that? i guess we must have
<axw> jam: I am here, but need to eat, so will not be at the standup
<jam> axw: how goes?
<jam> You're right that we can create the test, I just have to understand how to plug all the test stuff together. It can give errors so I'll give it a go
<jam> unfortunately, while most attributes of ServerError are public the actual *error* attribute is private..
<axw> jam: sorry was afk. goes ok, still working on tests for the storage regression
<babbageclunk> wallyworld_: sorry, never got back to you. Finding the deserialization stuff pretty slow going - will hit you up for next tasks tomorrow.
<wallyworld_> sgtm
<jam> axw: ping about checking the error
<jam> If we're going to check, 404 seems a very generic error
<axw> jam: it means not found, isn't that what we care about? that the resource does not exist?
<axw> jam: I'm not *too* fussed, I just feel that looking into the message is a bit brittle. do we have a guarantee that that won't change? I guess it's unlikely to, since it's only for old versions of MAAS
<jam> so, we may start calling a different api, and an old server would give us a new URL that it doesn't support
<jam> axw: what about "Unknown API Endpoint ... /static-routes/" ?
<jam> just check for those two strings?
<jam> at this point, I don't really care, mostly thinking about "what should our error checking actually look like"
<jam> and not really wanting to treat 'any error' as the error we think we might get
<jam> and how specific should we be around that
<axw> jam: I'm probably being overly optimistic about what URLs we would try and how well services adhere to HTTP status code meanings. "Unknown API Endpoint ... /static-routes/" sounds fine
<jam> I can hypothetically see us getting a 404 from not having a *specific* route, rather than not implementing the API at all, for example
<axw> jam: sure, but that should be a different URL though? /static-routes/<foo>, rather than /static-routes/
<jam> axw: hence my point of checking the URL rather than just the 404
<axw> though to be fair, lack of an endpoint resulting in 404...
<axw> jam: anyway, I don't really care that much. your proposal is fine
<jam> axw: sure. it feels like the typo of tech-board weigh in, more from a "how specific should we be about errors from outside"
<axw> jam: sure, we can discuss tomorrow
<axw> jam: btw why did the meeting move?
<axw> bit of a crappy time for you?
<jam> sorry, I meant to chat with you specifically, but yeah. I talked to tim/ian/menno on Monday
<axw> jam: no worries, just curious
<jam> I can't ever make exactly 7:00 cause that's when I'm downstairs taking my son to the bus
<jam> so 30min later means I won't be late every week
 * axw nods
<rick_h> jam: want to chat today?
<jam> rick_h: sure, brt
<redir> jam: yt?
<redir> jam: lemme know if you want to chat about kvm at all
<jam> hi redir.. not really :)
<jam> sure
<redir> jam: at your leisure
<jam> give me a few to post this
<redir> jam no worries I'm here all day
<redir> well your night
<jam> though only just today, right?
<redir> jam: correct
<jam> sinzui: https://github.com/juju/juju/pull/7048 tested on finfolk
<sinzui> thank you jam
<cholcombe> Is aws bootstrapping having issues currently?  https://juju-dist.s3.amazonaws.com/tools/streams/v1/com.ubuntu.juju-released-tools.sjson not found
<rick_h> cholcombe: aws is having s3 outages in us-east atm
<rick_h> cholcombe: twitter screams in outrage when us-east is effected by something heh
<cholcombe> rick_h: ok
<cholcombe> rick_h: that's odd because i'm trying to bootstrap us-west-2.  does it always pull from us-east?
<rick_h> cholcombe: not sure, just noticed your s3 url and I've just been looking into the outage notes so far
<cholcombe> ok i'll hold off
 * redir lunches
<babbageclunk> Morning thumper - could you take another look at https://github.com/juju/description/pull/1
<thumper> babbageclunk: morning, and yes
<babbageclunk> thumper: thanks!
<thumper> babbageclunk: all good
<babbageclunk> thumper: cool cool, thanks
 * thumper dives into code for 35 minutes before first call
<babbageclunk> thumper: ooh, does $$merge$$ work on that repo?
<thumper> probably not...
<thumper> hmm...
<thumper> babbageclunk: do you have merge access?
<thumper> babbageclunk: I'm assuming all the tests pass :)
<thumper> if so, I can just click the merge button
<babbageclunk> thumper: no merge access - yes, all the tests pass :)
<thumper> babbageclunk: I've merged it, and I'll look to get automated landing setup
<babbageclunk> thumper: cheers
<babbageclunk> wallyworld_: review plz? https://github.com/juju/juju/pull/7049
<wallyworld_> sure
<babbageclunk> wallyworld_: I'm looking at 7041 now
<wallyworld_> ty
<thumper> what is that github git helper folk use?
<babbageclunk> thumper hub
<babbageclunk> thumper: it's annoyingly underdocumented
<babbageclunk> https://github.com/github/hub
<thumper> babbageclunk: found it
<thumper> babbageclunk: how do I set up my creds for it?
<babbageclunk> thumper: huh, they have a man page for it, but I guess that doesn't get installed when you `go get` it.
<babbageclunk> https://github.com/github/hub/blob/master/share/man/man1/hub.1.ronn
 * redir has trouble focusing today
<anastasiamac> redir: :(
<thumper> redir: don't blame you
#juju-dev 2017-03-01
<menn0> axw, thumper-dogwalk, wallyworld_, babbageclunk, anastasiamac: review please: https://github.com/juju/juju/pull/7050
<menn0> axw, thumper-dogwalk, wallyworld_, babbageclunk, anastasiamac: this one is hairy enough that it probably needs 2 reviewers
<wallyworld_> ok, will look soon, just finishing something
<anastasiamac> menn0: m not able to review today. i trust u'd get reviews from others \o/
<menn0> anastasiamac: thanks anyway :)
<anastasiamac> menn0: no worries :0
<thumper> keep forgetting to reset that
<thumper> menn0: I'm looking now
<menn0> thumper: thank you
<thumper> menn0: lgtm - you can await another if you choose
<menn0> thumper: thanks. I think wallyworld_ offered to have a look too
<wallyworld_> looking now
<wallyworld_> menn0: at first glance, it seems not all occurrences of st.getCollection() have been ported across?
<menn0> wallyworld_: that's right... I wasn't aiming to change everything to go via the Database
<menn0> wallyworld_: just to get watchers and settings working with modelBackend instead of State
<wallyworld_> ok
<menn0> wallyworld_: I'm happy to do another PR which goes further
<wallyworld_> no worries, just checking the scope
<menn0> wallyworld_: I started doing that but it got huge and I didn't want to make this PR too hard to follow
 * menn0 has to go
<menn0> biab
<wallyworld_> menn0: lgtm too. been wanting progess is ths area for a while, so is great
<anastasiamac> babbageclunk: in menn0's absence, any advise on https://bugs.launchpad.net/juju/+bug/1668646?
<mup> Bug #1668646: Model migration fails <juju:New> <https://launchpad.net/bugs/1668646>
<babbageclunk> anastasiamac: looking
<babbageclunk> anastasiamac: ok, I know what that's about. apparently we're not using the index on status history when exporting.
<anastasiamac> babbageclunk: ah!
<babbageclunk> anastasiamac: The index is {"model-uuid", "globalkey", "updated"}
<babbageclunk> anastasiamac: just looking in the code to see how we're getting the history in the model
<babbageclunk> anastasiamac: do you know whether there's a way to purge old status history?
<anastasiamac> babbageclunk: i thought that we r. wallyworld_ might even know how often :)
<wallyworld_> the history is capped
<wallyworld_> there's a worker to purge
<babbageclunk> anastasiamac: we're sorting by -updated, -_id in the model code
<thumper> ugh
 * thumper is having a WTF moment
<thumper> ugh
<thumper> got it now
<thumper> FFS
<anastasiamac> thumper: glad we could help \o/
 * redir eojs
<babbageclunk> hyperlol
<anastasiamac> redir: o/
<redir> \o
<babbageclunk> redir: o/
<redir> babbageclunk: o/
<redir> my nick will likely still be hanging out here....
<redir> so reach out if you have questions
<thumper> o/ redir
<thumper> redir: so long and thanks for all the fish
<menn0> wallyworld_: do you think I should take this modelBackend change further and get rid of getCollection etc now?
<wallyworld_> would be nice if you had time
<wallyworld_> but other stuff more important
<wallyworld_> imo
<menn0> wallyworld_: yeah fair enough
<wallyworld_> i really want to get rid of ForModel()
<menn0> wallyworld_: I think ForModel could be made a lot cheaper with a bit of restructuring
<wallyworld_> yes it could
<wallyworld_> we don't want the workers
<wallyworld_> just access to state
<menn0> wallyworld_: for example there's no need to do all the DB setup work again and the workers need to move out
<wallyworld_> yep
<menn0> for another time though
<wallyworld_> sadly yes
<sinzui> wallyworld_: axw : QA needs to test the controller running with a valid cert. I have DNS pointing to a machine, but I need a --to or --constraint to incantation to bootstrap on the machine jimm-a.vapour.ws. The aws provider does not like --to ssh:ubuntu@jimm-a.vapour.ws
<wallyworld_> no, only the manual provider supports that
<axw> sinzui: you can do "juju bootstrap manual/ubuntu@jimm-a.vapour.ws"
<wallyworld_> that's the syntax i was looking for
<sinzui> axw: Doesn't that undermine subsequent deployments in aws?
<axw> sinzui: I don't understand your question
<sinzui> axw once the controller is up, we expect to deploy applications into many models. The machine is in aws so I expcect to use the aws provider
<axw> sinzui: ok. you cannot bootstrap aws to an existing instance
<sinzui> axw wallyworld_ I want to bootstrap with --config autocert-dns-name=jimm-a.vapour.ws which should trigger juju to install a cert *if* the hosts ip matches DNS. So I think I need the machine up *before* I bootstrap
 * wallyworld_ hasn't used the autocert functionality before, so not sure tbh
<axw> sinzui: I don't think you do though? you should be able to bootstrap with autocert-dns-name, then set up your DNS, then use the DNS name from your client
<axw> sinzui: the autocert stuff only kicks in for clients that attempt to connect via the DNS name
 * thumper sighs
<thumper> wow this is tedious work
 * thumper is adding state.Export to 1.25 branch
<sinzui> axw :( That is awkward. Bootstrap, the  fallback to another tool to associate an elatic IP. That is better I suppose than trying to register DNS for a random IP several times an hour
<sinzui> s/the fallback/then fallback
<axw> sinzui: ideally we'd have bootstrap just register with route53 I think, but we don't have that atm
<axw> or use an elastic IP I guess
<sinzui> axw, oh, maybe I missed something you wrote? how do I tell the client to use the dns name if I didn't boostrap with the name?
<axw> but yeah, that's the current state of affairs
<axw> sinzui: you have to modify your controllers.yaml, replace the IPs with the DNS name
<sinzui> axw, associating an elastic IP is jsut a nusancec and just a single line in a script before starting the hard work of the test
<axw> sinzui: or use "juju register domain.name"
<sinzui> axw, okay, thank you!
<axw> sinzui: np
<rick_h> sinzui: axw I was just talking to urulama about that today
<rick_h> We've got it on the list of topics for next week
<rick_h> Because it almost does the right thing but needs the s/IP/DNS name tweaks
<axw> rick_h: I'd like to hear the outcome. I won't be at the sprint
<rick_h> axw: will do.
<blahdeblah> thumper: ping; just trying to get you up-to-date info for my 2.1 controllers - is there anything that needs to change in terms of agent streams & stuff in upgrading from 2.1-rc2 to 2.1 stable?
<thumper> blahdeblah: um... not sure to be honest
<thumper> sinzui: ^^
<thumper> blahdeblah: 2.1-rc2 info is fine
<thumper> blahdeblah: what I'm looking at hasn't changed in there
<menn0> thumper, wallyworld_: i'm not going to be able to make tech board today due to a thing at my son's preschool
<menn0> it's one of those days
<blahdeblah> thumper: It's not fine with me :-)
<thumper> blahdeblah: ah
<thumper> :)
<wallyworld_> pk
<thumper> menn0: that's fine, I had completely forgotten about it
<blahdeblah> thumper: I'll just try a 2.1 upgrade and see how it goes
<thumper> blahdeblah: can't hurt, right?
<blahdeblah> How do I show what the current version of tools is in my running controller/models?
<blahdeblah> sorry - source, not version
<blahdeblah> Version is easily seen in the status output; I want to know where they came from
<axw> wallyworld_: it's a big-un, but PTAL when you can: https://github.com/juju/juju/pull/7052
<wallyworld_> sure, will do. just finishing something, will look soon
<axw> menn0: ^^ if you are doing OCR
<menn0> axw: thanks for the reminder :) looking
<axw> blahdeblah: source? as in, whether it came from streams.c.c or uploaded or whatever?
<sinzui> blahdeblah: upgrades from 2.1-rc2 is fine, tested, is is just a version string change
<blahdeblah> axw: yes - as in, did I mangle some config to pull devel tools at some point in the past, and do I need to change them back to stable now?
<thumper> blahdeblah: juju status will show what is currently in use
<thumper> blahdeblah: if you add --format yaml, there are more details
<thumper> by default status now only shows the version for the model, rather than every agent
<blahdeblah> thumper: no indication in there about which stream the agents came from
<thumper> blahdeblah: ah... model-config?
<sinzui> blahdeblah: ther rc1 was only in devel streams. but regardless, if you didn't force agent-stream=devel, juju will select released
<axw> blahdeblah: I think the only place we store that info is on disk. there's a file caled downloaded-tools.txt
<axw> I think we also have it in the DB actually, but don't think we expose it to the CLI anywhere
<sinzui> blahdeblah: "juju upgrade-juju --agent-version 2.1.0 --dry-run" will tell you if the upgrade can happen
<axw> blahdeblah: it'll only tell you the URL we grabbed the agent from tho, not the stream. the stream name is just in model config as per ^^
<blahdeblah> OK, looks like I never changed from released stream, so I think we're all good.
<blahdeblah> Thanks everyone
 * thumper headdesks
<menn0> axw: done. looks good
<jam> menn0: axw: thumper: tech board?
<axw> menn0: thanks!
<axw> jam: still 1 minute! ;)  omw
<blahdeblah> Gah; "juju sync-tools" == "juju destroy-my-uplink"
<blahdeblah> Is there a way to get this thing to sync from the streams rather than from my client?
<sinzui> blahdeblah: sync-tools does that by default it only uses disk if you pass extra args
<sinzui> blahdeblah: you want to sync 2.1 from released into your controller?
<blahdeblah> sinzui: yes - direct from streams rather than via my client, which is halfway around the world from the controller
<sinzui> blahdeblah: yeah, that sucks, though there are only 6 agents instread of 27 now
<sinzui> blahdeblah: juju sync-tools --version 2.1 --dry-run
<blahdeblah> sinzui: Are you saying that the above will cause it to sync directly from streams?
<sinzui> blahdeblah: yes
<blahdeblah> Is it supposed to tell me anything?
<sinzui> blahdeblah: It doesn't? what have a dry run if if it sin't verbose
<blahdeblah> Unless I give --debug, it says nothing
<blahdeblah> also, should it be 2.1.0 rather than 2.1?
<sinzui> blahdeblah: it only accepts major.minor, the looks for the newest version in streams.
<blahdeblah> according to --debug, there are still 27 agents to sync:
<blahdeblah> 13:43:22 INFO  juju.environs.sync sync.go:136 found 176 tools in target; 27 tools to be copied
<blahdeblah> This is not downloading directly from streams to the controller; it's definitely coming via my connection.
<sinzui> blahdeblah:oh, juju if a fuckwit. there are 27 names, but exactly 6 agents. 4 for ubuntu series by arch, 1 for centos, and 1 for all 10 windows series
<sinzui> :/
<sinzui> blahdeblah: do you need to sync? Juju usually gets agents from streams.canonical.com as needed. 99% of the time that is just the ubuntu amd64 agent
<sinzui> blahdeblah: what I am asking is, can the controller see streams.canonical.com? if so, just run upgrade-juju --version 2.1.0
<blahdeblah> sinzui: I have no idea whether I need to sync.  What would determine that?  I'm following our existing upgrade procedure, possibly naively: https://wiki.canonical.com/InformationInfrastructure/IS/JujuUpgrades
<blahdeblah> The controller should be able to see streams.c.c
<sinzui> blahdeblah: I see. there is a history of prodstack and friends from stay away from live streams
<blahdeblah> I wouldn't think that's a hard requirement any more
<sinzui> blahdeblah: probably not. the sync-tools command is actually *less* precise than  juju-upgrade --agent-version 2.1.0
<blahdeblah> Thanks sinzui - juju upgrade-juju --agent-version="2.1.0" --debug worked a lot faster for me
<sinzui> blahdeblah: yes, it is much faster in 2.x and it will abort if 2.1.0 is not available. Juju will not select an alter alternat agent behind you back.
<blahdeblah> cool - thanks very much
<jam> axw: did you want to chat? I don't think I have much more than a quick recap of "working on 2.1.1 bugs"
<axw> jam: happy to skip. my update is same as yesterday
<axw> wallyworld_: AFAICR, filesystem and volume IDs are not exposed to charms, only to users via "juju storage". so I'm thinking we could probably change the ID format to be unambiguous
<wallyworld_> yeah, that would be sweet I think, certainly easier for users
<axw> wallyworld_: ah, except old agents wouldn't be able to understand a new format
<axw> hm
<wallyworld_> doh, yeah
<axw> wallyworld_: so I've had another thought, still a bit loose: I don't think it's helpful to users to distinguish between "storage instance" and "volume/filesystem". to them, they're one and the same (I think). so we could perhaps have the storage instance remain in the model, and have that be the thing you attach/detach
<wallyworld_> axw: yeah, the distinction between volume/filesystem and storage instance has (to end users) been murky and I think an exposing of the internal model which we could/should abstract over
<axw> wallyworld_: I'll play with that a bit, and leave the remove-storage command alone for now
<wallyworld_> sgtm
<axw> wallyworld_: I can't see us having anything interesting to demo next week
<axw> for storage I mean
<wallyworld_> such is life. i told folks we would be pushing it
<jam> anyone for reviewing my update to perrito666's patch: https://github.com/juju/juju/pull/7054 ?
<anastasiamac> jam: lgtm'ed
<jam> anastasiamac: we have TestFindAvailableSubnetWithExisting10xNetworks
<jam> is that not the collision test you were looking for?
<jam> (that's the test I updated and confirmed it failed from before, suceeeds with my cahnge)
<anastasiamac> jam: u answered my one and wallyworld_ the other questions :D so +1 as per review
<jam> wallyworld_: did you have review feedback as well? or LGTM
<wallyworld_> jam: still looking, was thinking we could use a map[net.IP]bool instead of separate set and slice
<wallyworld_> in getKnowmIps()
<wallyworld_> but meh, whatever works
<jam> wallyworld_: so we can, but we still iterate over the slice in the end. I'm fine tweaking it, but in reality we'll have at most like 10
<wallyworld_> yeah, hence the meh. but the logic is a bit simpler and exlicit
<wallyworld_> let me just finish reading the rest
<jam> I like elicit logic
<wallyworld_> lol
<wallyworld_> jam: seems ok to  me, testing steps seem to verify it works. anastasiamac asked for an additional test so whatver make you guys happy, i'm happy
<wallyworld_> i like that we defer to lxd in > 2.3
<jam> well, aside from bug #1668547 where we defer to LXD but it doesn't actually work :)
<mup> Bug #1668547: juju doesn't configure lxdbr0 properly with new LXD (>2.3) <bridge> <lxd> <network> <juju:Triaged by jameinel> <https://launchpad.net/bugs/1668547>
<jam> I think I made the bot unhappy, has anyone else been able to land branches?
<jam> Both this one and https://github.com/juju/juju/pull/7044 have a "$$merge$$" but the bot hasn't responded for 30 minutes
<anastasiamac> jam: axw landed some today but that was almost 5hr ago
<jam> and there it just woke up
<jam> 'a minute ago' on both of them
<anastasiamac> jam: \o/
<jam> ah, sorry, it still hasn't noticed 2.1-into-develop. I think it is because I stopped the request last time
<jam> because it had a bug
<jam> so probably I need sinzui's help to unblock that branch again.
<jam> (I had 2 tabs open on the same pr)
<anastasiamac> jam:  as far as I know for bot to pick it up again, pr has to have a 'merge failed' msg
<anastasiamac> jam: something like "Build failed: Generating tarball failed"
<anastasiamac> then re-enter merge command and it should get picked up again
<perrito666> morning all
<anastasiamac> perrito666: \o/
<jam> hey perrito666. I wasn't sure if you were back in today or tomorrow
<jam> good to see you
<perrito666> jam: given that we live in different days I believe both are true :p
<perrito666> jam: mm no, wit its tue for you
<jam> its late Wed for me
<perrito666> yes, wed sorry, its early wed for me
<jam> same day as you, just a bit later
<perrito666> jam: since yesterday we are the only two living in the past
<jam> perrito666: you live further in the past than I. but there is Eric as well
<perrito666> jam: does this mean you obsoleted/merged my pr? https://github.com/juju/juju/pull/7054
<perrito666> jam: ah true, I forgot about eric, he lives in the past too
<jam> perrito666: merged
<perrito666> jam: tx, its amazig to have someone take care of the boring parts of my PRs
<perrito666> :p
<jam> heh. exteralreality is his IRC nick. I don't think I've seen him on IRC yet. I guess he's starting late for Tim?
<perrito666> I have seen him on irc and also "in person" a.k.a in a hangout
<jam> in theory, we get to see 'in the flesh' next week
 * perrito666 tries to figure out what time does his plane leaves
<perrito666> Sun 1:50 which translates to Sat night
<menn0> jam: did you want to talk at all?
<jam> menn0: sure
<menn0> jam: now is literally the first moment I've had since we last talked
<jam> https://hangouts.google.com/hangouts/_/canonical.com/john-menno?authuser=1
<kjackal> hi juju-devs, there is a problem with the juju bootstrap dialog and localhost:  http://pastebin.ubuntu.com/24090147/
<kjackal> Is this a known issue?
<zeestrat> kjackal: I ran into the same issue. Not sure if there's a bug in launchpad. If you do not use the dialog, you can just say juju bootstrap lxd <name-of-controller>
<rick_h> kjackal: not seen a bug on that but :/ at it oops
<kjackal> zeestrat: rick_h: opened this ticket: https://bugs.launchpad.net/juju/+bug/1669003
<mup> Bug #1669003: "juju bootstrap" dialog failing for localhost <juju:New> <https://launchpad.net/bugs/1669003>
<rick_h> kjackal: ty much
<perrito666> jam: any clue on where the interfaces checking/renaming happens in code? this should be cloudinit right?
<perrito666> ayway, re-locating again
<perrito666> nevermind
 * thumper running dog down for her haircut
<perrito666> thumper: just hack a roomba with some scisors
<veebers> thumper: short back and sides, or a perm this time?
<thumper> her ears often look like she has had a perm
<thumper> but something like a number 4 over most of the body :)
<babbageclunk> I really want an introspection worker that dumps out a dot representation of the dependency dag. <waggles eyebrows at thumper>
<thumper> babbageclunk: sounds interesting
<babbageclunk> thumper: currently trying to do the same with the "dependency not available" lines from the log
<thumper> hmm... I now wish we were using Go 1.8
<thumper> it would make some of what I'm doing easier...
<babbageclunk> thumper: what are you doing?
<thumper> assigning structs for different packages
<thumper> where refactoring has happened
<thumper> and things moved
<thumper> adding state.Export to the 1.25 codebase
<babbageclunk> thumper: I mean, what 1.8 feature do you need? (Just curious.)
<babbageclunk> thumper: Oh, the tag differences?
 * wallyworld uses 1.8, it's glorious
<wallyworld> so fast
#juju-dev 2017-03-02
<babbageclunk> wallyworld: The subnets I add when the provider doesn't support spaces should have a space of "", right?
<wallyworld> yup
<wallyworld> "" is considered the default space
<babbageclunk> wallyworld: at the moment the AddSubnets api method doesn't accept "", I'll change it to now.
<wallyworld> ah, ok
<babbageclunk> wallyworld: The AddSubnets method is shared between the Subnets and DiscoverSpaces facades - do you think I should allow space="" in both places?
<wallyworld> babbageclunk: yeah because "" is universally the default space
 * wallyworld says without looking at code
<babbageclunk> wallyworld: yay, that's easier!
<wallyworld> thumper: i fixed the race https://github.com/juju/juju/pull/7056
<thumper> wallyworld: awesome
<wallyworld> race was one line, drive bys a few more :-)
<thumper> wallyworld: lgtm
<wallyworld> ty
<thumper> I wish we had someone around that understood the 1.25 networking model and the changes for 2.0
 * thumper sighs
<thumper> blahdeblah: hey...
<thumper> blahdeblah: didn't you say that you had some 1.25 environments and 2.0 models with similar capabilities?
<thumper> blahdeblah: are they maas or openstack?
<blahdeblah> thumper: yes; openstack - all in canonistacks
<thumper> well... that is a start at least
<blahdeblah> thumper: they're not identical, but similar
<thumper> blahdeblah: what's the chance you can get me a mongo dump of both?
<thumper> sure.
<blahdeblah> thumper: Did you get my email about that yesterday?
<thumper> probably...
 * thumper looks
<thumper> blahdeblah: well that sucks
<blahdeblah> sorry :-)
<thumper> blahdeblah: how conversant are you with the mongo shell?
<blahdeblah> thumper: I can share my screen with you via hangout and monkey-type whatever you tell me like an absolute pro! :-P
<thumper> :)
<thumper> blahdeblah: what we could do is add the index on the fly to test
<thumper> and if that works, which it should, get it in to 2.1.1
<babbageclunk> thumper: while you're in there maybe check how many rows there are in the collection?
<blahdeblah> thumper: sure - just need to step away for a minute, but we can work on it after that
<thumper> babbageclunk: yeah
<thumper> blahdeblah: sure, ping when back
<blahdeblah> will do
<babbageclunk> thumper: There's a comment in MachineAgent.startModelWorkers saying "we should try to find the right values for these numbers".
<thumper> haha
 * thumper goes to make coffee
<blahdeblah> thumper: I'm back - can look at this index when you're ready
<thumper> blahdeblah: ok, just eating a muffin
<blahdeblah> thumper: you want to try hangouts for this again?
<thumper> blahdeblah: yeah
<thumper> blahdeblah: just on another call, with you shortly
<blahdeblah> thumper: I'm gonna have to run for lunch appointment in 10 mins, and I'm guessing you'll be EOD-ish by the time I get back.  Can you pastebin or email what you want me to do?
<thumper> blahdeblah: yeah... can do
 * babbageclunk goes for a run
<blahdeblah> thumper: still around
<blahdeblah> ?
<blahdeblah> thumper: just want to confirm that I'm doing this indexing stuff on 2.1.0
<blahdeblah> (not 1.25.10)
<thumper> blahdeblah: yeah 2.1
<blahdeblah> thumper: Just created a ticket to track and added your email; the index thing worked perfectly and I'm moving on to getting the dumps
<thumper> blahdeblah: which index, first or second?
<blahdeblah> first
<blahdeblah> https://pastebin.canonical.com/181228/
<thumper> blahdeblah: sweet
<thumper> I'm a little surprised that the first one worked, but kinda happy
<thumper> babbageclunk: ^^ index without _id worked
<thumper> blahdeblah: that is very helpful, would still like a mongo dump of 1.25 if you can :)
<blahdeblah> On its way
<thumper> blahdeblah: awesome, thanks
<thumper> Now I'm on the hunt for some maas 1.25 environments to get a dump from
<thumper> and some maas 2.1 models to do equivalent queries against
<blahdeblah> bradm: ^
<babbageclunk> thumper: oh, nice!
<babbageclunk> thumper: well, I guess I should have had more faith in mongo
<thumper> babbageclunk: https://github.com/juju/juju/pull/7058
<thumper> babbageclunk: not sure why you should have more faith, I didn't
<thumper> well, I had ~25% faith
<thumper> does that count?
<babbageclunk> thumper: lgtm'd
<thumper> babbageclunk: https://github.com/juju/juju/pull/7059 another
<thumper> babbageclunk: indices are ensured whenever state gets opened
<babbageclunk> thumper: This is the one I thought the other one was going to be - you got me with a classic bait-and-switch!
<babbageclunk> thumper: lgtmd
<anastasiamac> axw: added revert to the same PR. still +1? happy to merge?
<axw> anastasiamac: yes, thanks
<anastasiamac> axw: awesome! shiping..
<axw> jam: will be 5-10 mins late, I'll ping you. I'd like to chat about storage spec revision today
<jam> k
<axw> jam: I'm in
<jam> axw: do we have a bug about "not able to open /dev/loop" spamming the log files with the lxd provider?
<jam> (it might be fixed in 2.2, I'm just seeing it testing out 2.1)
<axw> jam: not that I know of
<axw> jam: I don't think it's fixed in 2.2
<jam> bug #1669297
<mup> Bug #1669297: diskmanager log spam about /dev/loop <lxd> <lxd-provider> <storage> <juju:Triaged> <https://launchpad.net/bugs/1669297>
<jam> (just filed)
<axw> wallyworld: did you see my response?
<jam> axw: did we break "juju upgrade-juju" with development tools in 2.1.1/
<jam> ?
<jam> I swear it always worked for me to just keep running that command
<jam> now I'm getting "newer version found"
<jam> 2.1.1.1
<jam> but it should be creating 2.1.1.2
<jam> ah.. just a bad error
<jam> running 'upgrade-juju' in not-the-controller-model gives a bad error
<perrito666> jam: --build-agent ?
<jam> perrito666: no, I just needed to "-m controller"
<perrito666> yes
<jam> build-agent told me that "you can only do that in the controller model" which pointed me in the right direction
<perrito666> its a bit dumb though that if you --build-agent it fails to upgrade because not on the controller instead of upgrading the controller... I used --build-agent I know what I want
<wallyworld> axw: yeah, saw it but had to go to soccer. i realise the tests are faulty because the before hook reuses the app object instead of getting a new one, so will fix
<jam> perrito666: math.rand is returning deterministic results... was that intentional?
<jam> I've bootstrapped 2x, and both got "10.0.18.0" for lxdbr0
<perrito666> jam: I would definitely not expect that, the docs dont mention it
<jam> perrito666: its standard for C libs
<jam> 'rand' is deterministic so you have to call srand first
<jam> perrito666: crypto/rand is properly always random but probably doesn't have Perm
<jam> usually its srand(time())
<jam> perrito666: care to poke at that?
<jam> maybe we could open a bug on 2.1.1 so that we know its being fixed
<perrito666> jam: at all, Ill fix it, so much for a high level languaje
<jam> https://golang.org/pkg/math/rand/
<jam> says: use a default shared Source that produces a deterministic sequence of values each time a program is run.
<jam> perrito666: ^^
<jam> 'use the Seed function'
<perrito666> jam: yup, I read the doc for Perm only, my bad
<jam> using Seed seems fine for our use case
<perrito666> yup, Seed with timenano should fix it
 * perrito666 writes a lib that sends an email to a bunch of D&D nerds to throw dice and reply with an int slice
<perrito666> jam: did you merge this with 2.2 or 2.1?
<jam> perrito666: heh
<jam> perrito666: its in 2.1
<perrito666> jam: you did some nassty things there
<perrito666> jam: look https://github.com/juju/juju/compare/2.1...perrito666:use_random_seed_for_lxd_ips?expand=1
<jam> something doesn't look right with that
<jam> did I target the wrong version?
<perrito666> jam: well for once the test diff is not there
<perrito666> :p
<perrito666> so it is even weirder
<jam> https://github.com/juju/juju/pull/7054
<jam> perrito666: did you "git update remote" first?
<jam> sorry git remote update
<perrito666> jam: mmm I git fetched
<perrito666> but the reset might not have taken
 * perrito666 goes again
 * perrito666 pulls -r
<perrito666> jam: btw, put a linter in your editor ffs :p
<perrito666> jam: there you go, I had messed my own repo https://github.com/juju/juju/pull/7061
<axw> wallyworld: LGTM, thanks
<jam> lgtm
<SimonKLB> perrito666: I see you're working on the container networking, does this have anything to do with bundles being forced to specify spaces?
<SimonKLB> recently I've started to see: juju.provisioner failed to prepare container "20/lxd/1" network config: unable to find host bridge for space(s) "" for container "20/lxd/1"
<jam> http://github.com/juju/juju/pull/7062
<perrito666> SimonKLB: I am not sure
<perrito666> jam: plese do some cleanup on that pr, your commit tree is a mess, do some squashing
<jam> I'm morally opposed to push --force, but I'll squash it a bit before $$merge$$
<wallyworld> axw: ty for review
<SimonKLB> jam: perhaps you could shed some light on it? im trying to run my bundle on the lxd provider, but spaces dont seem to be supported there yet? are the warnings nothing to worry about?
<jam> SimonKLB: as a quick question, are these running trusty?
<jam> I believe I have a fix in flight that should improve that case with 2.1.1 so you won't get a warning
<SimonKLB> jam: nope they are all xenial
<perrito666> jam: ship it
<jam> perrito666: so 'git log upstream/2.1...HEAD' shows the extra commits but "git rebase -i upstream/2.1" won't show me anything since the last time I merged 2.1
<jam> perrito666: I tried --no-fork point which seemed hinted by the readme
<jam> but haven't found anything that will actually let me squash the 2 merges into a single one
<perrito666> jam: git rebase -i <thecommitbefore the last one you want to squash>
<niedbalski> sinzui, ping
<sinzui> hi niedbalski
<niedbalski> sinzui, hey curtis :) , I am having issues while trying to set the apt-mirror config option in the model, I don't see this sed replacement (https://github.com/juju/juju/blob/eb98521dc187927bebe390e0172136033f80487e/cloudconfig/cloudinit/cloudinit_ubuntu.go#L157) appended on the cloud-init userdata. (https://pastebin.canonical.com/181281/) , are you aware on a similar issue?
<sinzui> niedbalski: This is new to me. I recall there are are a few issues related to security updates only come from ubuntu.com
<jam> perrito666: I was able to cleanup one or 2 of the commits, but the others were actual conflict resolution/bringing in changes from 2.1 that I actually need.
<niedbalski> sinzui, yes, the security updates are part of the issues I am tracking, do you know any lp bug related to it?
<perrito666> jam: ok, I forgive you :p
<sinzui> niedbalski: Bug 1606487 bug 1599886
<mup> Bug #1606487: apt-mirror does not override security.ubuntu.com for controller <juju:Triaged> <https://launchpad.net/bugs/1606487>
<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>
<perrito666> jam: I am usually only dense when I see things like "went to lunch" "changing computers" or "typo"
<perrito666> jam: ideally each commit you send should compile
<niedbalski> sinzui, thanks
<SimonKLB> do I have to do anything special when deploying a bundle with lxd containers when running on an lxd provider?
<SimonKLB> im getting: juju.provisioner cannot start instance for machine "0/lxd/0": Failed to change ownership of: /var/lib/lxd/containers/juju-51d4de-0-lxd-0/rootfs
<SimonKLB> seem to be a problem with nested lxd?
<SimonKLB> fixed it by adding 'security.privileged: "true"' in the juju-default lxd profile
<thumper> well.... shit.
<perrito666> thumper: that triggers an automated response by me to go and check the mail
<thumper> perrito666: no... no email about this yet
<thumper> I'm just wrapping my brain around 1.25 -> 2.x issues
<thumper> and I think what I need to do is to effectively have both codebases vendored (effectively) into my upgrade app
<thumper> rather than dealing with external repos
<thumper> due to needing both versions
<thumper> I need to be able to use 1.25 state
<thumper> and 2.0 api
<thumper> and both client disk formats
<perrito666> heh, well fuck is a strong understatement
<thumper> so...
<thumper> hmm
<thumper> fun...
<thumper> oh good
<thumper> menn0: got a minute
<thumper> I need to discuss something / get a sanity check
<perrito666> can I deploy a kvm container in an lxd provider?
<thumper> perrito666: no
<thumper> at least I don't think so
<thumper> we used to explicitly stop any container in lxc containers
<thumper> I assume that lxd also stops kvm
<menn0> thumper: hi, yep, 1:1?
<thumper> menn0: ack
<babbageclunk> wallyworld: ping?
<wallyworld> yo
<babbageclunk> wallyworld: I got a bit confused yesterday when I redid the tests for the discover spaces worker and realised it never sends the CIDRs of the subnets to the API?
<wallyworld> correct, there's a backend cache which does it
<wallyworld> when the first api call is made
<babbageclunk> wallyworld: seems weird
<wallyworld> it does
<wallyworld> did you want a quick HO?
<babbageclunk> wallyworld: sure! I mean, I don't think I need one - the tests are working now, just threw me for a bit.
<wallyworld> babbageclunk: let's chat quickly just make make sure we are on the same page
<babbageclunk> wallyworld: sounds good
<wallyworld> babbageclunk: in 1:1
<axw> thumper: can you please merge https://github.com/juju/description/pull/2?
<axw> seems I do not have rights
<thumper> axw: yep
<thumper> axw: done
<axw> thumper: cheers
#juju-dev 2017-03-03
<thumper> veebers: what do we need to do to add another repo into the bot landing?
<veebers> thumper: as in a dep?
<thumper> veebers: no, as in github.com/juju/description
<veebers> thumper: I would have to find out
<veebers> thumper: I believe we would need a new jenkins job and to update some scripts/cron for that. I would have to dig further to get a full answer
<blahdeblah> thumper: Re: lp:1669046 - we have tickets in already to update all of our standalone controllers to 2.1.0.
<blahdeblah> I'll create one shortly to get our HA controller env upgraded, but it may take a little longer - are there any special precautions/procedures for an HA upgrade?
<blahdeblah> thumper: Also, if you need anything more on that 1.x to 2.x upgrade preparation, a reply to the ticket I created would be appreciated; gives me a place to log time worked on it.
<thumper> blahdeblah: ack
<thumper> hmm...
<thumper> sublime not doing well with this global rename
<thumper> doing save all on 5000 different go files causes it's plugins to work overtime
 * thumper twiddles fingers waiting
<thumper> oh bollocks
<wallyworld> babbageclunk: i just noticed we have remoteApplicationsC in the ignored collections in migration_internal_test.go
<thumper> managed to somehow end up with submodules
<babbageclunk> wallyworld: oh, whoops - I'll fix that
<wallyworld> babbageclunk: no wuckers. i noticed because i'm about to delete an entire collection and associated data model we won't be using anymore
<wallyworld> no rush on it - get the spaces worker stuff done so i can test it out :-)
<babbageclunk> wallyworld: ok - still trying to track down what I've broken.
<wallyworld> joy
<thumper> 11000 changes across 2800 files
<thumper> yeah... do it
<babbageclunk> wallyworld: I mean, I've worked out the line that's done it, but I don't understand why. Trying it again now
<wallyworld> let me know if you need a 2nd set of eyes
<babbageclunk> wallyworld: will do, thanks
<blahdeblah> thumper: So, re: the precautions/procedures for HA upgrade question?
<axw> wallyworld: sorry, https://github.com/juju/juju/pull/7047 should have been closed. I have another branch which supersedes it
<wallyworld> no worries, i thought that was the case but then i second guessed myself and reviewed anyway. but yeah, it didn't seem to match the latest discussion
<babbageclunk> wallyworld: ok, worked it out - the connection's dropping because of a panic - nil pointer dereference. :( fixing!
<wallyworld> i hate those
<wallyworld> babbageclunk: what that in a unit test?
<wallyworld> that's why i added the stacktrace to catacomg errors
<wallyworld> cause i had a similar issue that was hard to diagnse where it was happening
<axw> wallyworld: well actually it's the same branch but updated. pushing now, will address comments and ping you later
<wallyworld> np
<axw> bleh nope, I'm wrong. closing and will create a new one
<thumper> blahdeblah: shouldn't be any different
<blahdeblah> thumper: Cool - so we don't need to upgrade each node separately or anything like that?
<thumper> nope
<blahdeblah> sweet
<blahdeblah> thanks
<axw> wallyworld: https://github.com/juju/juju/pull/7066. I'm running QA now
<wallyworld> ok, otp with tim
<babbageclunk> wallyworld: Oops, ListSubnets doesn't like blank space names either - I think there are going to be a few of these.
<wallyworld> yeah
<veebers> did something in 2.2 change for Azure? I see a _bunch_ of test failures in azure with errors like "'Failed': Code="AuthenticationFailed" Message="Authentication failed.""
<babbageclunk> veebers: Sounds like authentication failed.
<babbageclunk> :)
<veebers> babbageclunk: ah an interesting take on an error message :-\
<babbageclunk> veebers: In non-Friday-afternoon-japes mode, not that I know of.
<veebers> babbageclunk: thing is this is happening during a bootstrap
<veebers> babbageclunk: ack. I still need to pack for the sprint, leaving the house early tomorrow :-*(
<babbageclunk> veebers: ouch, I'm not leaving until Sunday afternoon.
<veebers> babbageclunk: ah, and arriving Sun evening right? I'm hoping that arriving Sat evening I lessen jetlag and hit the ground running on Monday
<babbageclunk> veebers: yeah, shake off some of that jetlag on Bourbon St, I hear you.
<babbageclunk> ;)
<veebers> babbageclunk: ^_^
<babbageclunk> wallyworld: ugh, segfault whackamole
<babbageclunk> wallyworld: actually, this one isn't a segfault, just the subnets command (calling ListSubnets which I just fixed) now complains about blank spaces.
<babbageclunk> wallyworld: rather than giving subnets a blank space, maybe we should be giving them a special space name? I feel like we're going to encounter knock-on effects from this.
<babbageclunk> wallyworld: Although I'm not sure about what the special space name would be.
<wallyworld> babbageclunk: sorry have been otp till now
<babbageclunk> wallyworld: no worries, mostly thinking out loud.
<wallyworld> babbageclunk: IIANM it is the intent to use "" as the default space rather than a const "default" or whatever
<wallyworld> we will just have to solve the whack a mole sadly
<wallyworld> babbageclunk: i need food, will be biab
<babbageclunk> wallyworld: ok, lucky I hate those pesky moles.
<babbageclunk> wallyworld: given that ListSubnets might now return a blank space tag, should I make a new facade version?
<babbageclunk> wallyworld: review plz? https://github.com/juju/juju/pull/7067
<wallyworld> babbageclunk: reviewed
<wallyworld> axw: reviewed - IMO we need to include Type in list storage output
<axw> wallyworld: should be obvious from the pool?
<axw> and/or provider ID?
<wallyworld> perhaps, but not guaranteed to be obvious? the pool name might not reflect the type so well? same with provider id which could well be opaque
<wallyworld> pool names  can be defined by the user
<axw> wallyworld: true, but I would think the operator would know what they've set up
<wallyworld> but it is not the operator who always runs list-storage
<axw> wallyworld: I'm reluctant because it's going to add a fair bit to the width
<wallyworld> think of a support person or other user who did not do the original deploy
<wallyworld> the width of the table?
<axw> wallyworld: yeah
<wallyworld> juju status is not exactly un-wide
<axw> wallyworld: indeed, but one of the things we did in 2.0 was to cut it down
<axw> cut down size of instance IDs, etc.
<axw> to avoid overflowing terminal width by default
<wallyworld> sure. but "volume" or "fiesystem" is not that much extra
<axw> wallyworld: actually you can't tell from the pool alone anyway, since you couldh ave a filesystem on EBS or whatever
<wallyworld> true
<axw> I'll look at adding it in
<wallyworld> I do think we need it TBH. ty
<wallyworld> we can always remove if people complain, but i honestly don't think they will
<axw> wallyworld: https://github.com/juju/juju/pull/7066/commits/fa75bb44923f8aafaf70a8c7615d64dafb494ea0
<wallyworld> looking
<wallyworld> axw: awesome, thanks
<axw> np
<blahdeblah> Anyone who's worked on the juju2 user permissions subsystem around?  Just want to ask some questions before I log some seemingly rather silly bugs.
<blahdeblah> Asking anyway... :-)
<anastasiamac> blahdeblah: 2.0.x or 2.1.x?
<anastasiamac> there were some changes...
<blahdeblah> anastasiamac: 2.1.0 stable!
<anastasiamac> blahdeblah: ask away.. there may not b answers that make ur day :)
<blahdeblah> So, Q1: is it expected that superusers are exempt from being disabled?  (Because in my testing, they are.)
<blahdeblah> To me this is rather unexpected.
<anastasiamac> blahdeblah: yes. i believe it's so tat someone can destroy and kill
<anastasiamac> blahdeblah: maybe that logic needs to be adjusted to not disable if it's the last one
<anastasiamac> blahdeblah: we have a discussion at sprint next week about user mngmt... so i can bring it up, especially if it's bugged up :)
<blahdeblah> OK, so then the bug I will logging is that when you disable a superuser, it gives no indication that your command did absolutely nothing.
<blahdeblah> (although it doesn't do nothing; it does actually mark the user as disabled, and it shows this way in list-users --all)
<blahdeblah> anastasiamac: Q2: Is it expected that non-superusers which are disabled and then re-enabled lose all of their grants to various models?  To me this is also rather unexpected.
<blahdeblah> When I disable a user and then re-enable that same user immediately (say, because I typoed the user name and disabled the wrong one), I don't want to have to work out which models were affected.
<anastasiamac> blahdeblah: i *think* this is expected as you want to b explcit about ur grants when re-enabling a user
<anastasiamac> blahdeblah: but again, it something to discuss
<blahdeblah> No, I don't.  I want them to go back exactly as they were. :-)
<anastasiamac> k \o/ file it and i'll see what we do
<blahdeblah> OK - thanks
<axw> wallyworld: do you recall if CI/builders are using go 1.7 to build already? or still on 1.6?
<wallyworld> axw: still 1.6 AFAIK
<axw> bugger
<wallyworld> i could be wrong but i think it's 1.6
<wallyworld> is there a 1.7 feature you want to use?
<axw> wallyworld: yeah, http request context
<axw> wallyworld: 1.8 would be better, since that has graceful shutdown/close methods on server
<wallyworld> is 1.8 officially out yet? last i heard it was still rc?
<axw> wallyworld: https://blog.golang.org/go1.8
<wallyworld> i/m 2 weeks out of date
<axw> wallyworld: also I suspect sort.Slice could be useful in a few parts of the codebase...
<wallyworld> indeed
<wallyworld> we'll have the right people necxt week to discuss
<wallyworld> i'll add it to the agenda
<axw> wallyworld: cool, thanks
<axw> IIANM we can use whatever we like now, and are not dependent on archives
<wallyworld> yeah, i think so too
<mup> Bug #1669729 opened: Cannot update machine data <canonical-bootstack> <juju-core:New> <https://launchpad.net/bugs/1669729>
<SimonKLB> any idea why i can't switch to a model that i have never connected to using a new user in juju?
<SimonKLB> i can see the model in `juju models`
<SimonKLB> but `juju switch aws:default` just spits out 'ERROR "aws:default" is not the name of a model or controller'
<SimonKLB> looks like there is some problem at the controller level even
<babbageclunk> SimonKLB: is your controller called aws?
<SimonKLB> babbageclunk: yea
<SimonKLB> added a new user, got the register base64 string, added it to the new user and named the controller aws
<babbageclunk> SimonKLB: maybe something's getting confused between that and the aws provider
<SimonKLB> ill retry with a more unique name
<babbageclunk> SimonKLB: It's a guess, sorry.
<babbageclunk> SimonKLB: Could also try passing --debug to  `juju switch`
<SimonKLB> babbageclunk: do you have to re-do the add-user process, because now the second time i use the register string i get 'ERROR secret key for user "X" not found'
<SimonKLB> or can i genenrate the string again without having to do add-user?
<babbageclunk> SimonKLB: I don't think you can reuse the register string (I'm not certain of that though) - try adding another user?
<SimonKLB> yea will do
<SimonKLB> babbageclunk: same thing using "mycontroller" as the name
<SimonKLB> nothing stands out in the --debug output
<babbageclunk> SimonKLB: you can see the model in `juju models`?
<babbageclunk> SimonKLB: did you grant access to the user?
<SimonKLB> babbageclunk: yea i granted access
<SimonKLB> http://paste.ubuntu.com/24101356/
<babbageclunk> SimonKLB: Try `juju switch mycontroller:admin/default`?
<SimonKLB> doh...
<SimonKLB> thanks man haha
<babbageclunk> SimonKLB: hmm, I don't think the admin/ should be necessary, since just default is not ambiguous.
<SimonKLB> any idea why its named admin/default there and not elsewhere?
<SimonKLB> well it worked using admin/ but not without :O
<babbageclunk> SimonKLB: It's admin/default because it's owned by admin.
<SimonKLB> aaah
<SimonKLB> make sense
<babbageclunk> SimonKLB: It's still pretty confusing though - can you file a bug? Or I will.
<SimonKLB> launchpad or github?
<perrito666> morning
<SimonKLB> nvm launchpad it is!
<babbageclunk> SimonKLB: yes launchpad please!
<babbageclunk> morning perrito666!
<perrito666> babbageclunk: coming to the sprint?
<babbageclunk> perrito666: yup yup, assuming I get into the country
<perrito666> babbageclunk: yes, we are all under the same assumption, I dont thing the place for the sprint was very wisely chosen :p
<perrito666> we go to uk after the brexit and now to the US, who is pickig the destinatios?
<babbageclunk> perrito666: political storm-chasing
<perrito666> heh
<SimonKLB> babbageclunk: https://bugs.launchpad.net/juju/+bug/1669745
<mup> Bug #1669745: Model name different for model owner and non-owner might confuse new users <juju:New> <https://launchpad.net/bugs/1669745>
<babbageclunk> SimonKLB: Nice write-up, thanks! I've tagged it with usability.
<rogpeppe1> if anyone cares to take a look, i've just put a PR up for review of a change to gopkg.in/juju/worker.v1. my aim is to use it to replace a bunch of the state/workers.RestartWorker stuff: https://github.com/juju/worker/pull/2
<redir> i saw perrito666 new ride today: https://goo.gl/NDtqUN
#juju-dev 2018-02-26
<wallyworld> babbageclunk: for whenever, here's that PR to handle app removal https://github.com/juju/juju/pull/8423
<babbageclunk> wallyworld: ok, having a look now
<wallyworld> yay, ty
<jam> wallyworld: thumper: hangout?
<thumper> we are there
<jam> k, I'll try reconnecting
<jam> thumper: it seems stuck at "requesting to join the video call." very strange, trying to figure out what's up
<thumper> yeah, we both had that
<thumper> ctrl-f5
<thumper> until it stops
<babbageclunk> wallyworld: reviewed
<jam> elmo: ping if you're around
<bdx> https://bugs.launchpad.net/juju/+bug/1751849 - wtf is this
<mup> Bug #1751849: ERROR secret key for user "<username>" not found <juju:New> <https://launchpad.net/bugs/1751849>
<bdx> its juju demo week for my team here, not off to a good start with whatever ^ is - would appreciate some coverage there, thx thx
<kwmonroe> bdx: wag here, but can you try adding another user and setting a controller name that doesn't already exist?  maybe the token is being expired after the first prompt for a controller name.
<bdx> ahh
<kwmonroe> i'm not saying that's the right behavior, but may be enough to get you going.
<bdx> kwmonroe: sending register command per dm
<bdx> go for it
<kwmonroe> thumper: do you know off hand when registration strings from add-user get expired? re: bdx bug above
<thumper> kwmonroe: single use I believe
<thumper> but I don't think it is time based
<kwmonroe> bdx: worked for me:
<kwmonroe> Enter a name for this controller [pdl-aws]: mycloud
<kwmonroe> Initial password successfully set for myuser.
<bdx> no way
<bdx> cool! now I feel silly
<kwmonroe> thumper: could it be the case that the secret is thrown away before a valid controller name is accepted? bug 1751849
<mup> Bug #1751849: ERROR secret key for user "<username>" not found <juju:New> <https://launchpad.net/bugs/1751849>
<bdx> well check out what my user posted
<thumper> I wouldn't think so
<thumper> but I'm on a call just now
<thumper> so not responsive
<kwmonroe> roger that
<kwmonroe> bdx: fyi i unregisterred myself from your controller.
<bdx> https://imgur.com/a/Vt2nf
<bdx> cool, thanks
<kwmonroe> oof that image is weird bdx.  DM me another register command and i'll accept the default pdl-aws controller name.
<bdx> possibly I should give you the perms like I did for the other user too
<kwmonroe> ok, fwiw, the last one was for 'myuser' with 'login' access:
<kwmonroe> mycloud*      -          myuser             login                          -         -     -  2.3.3
<bdx> ok
<bdx> here's another, not sure if it will be any better https://imgur.com/a/u07W3
<kwmonroe> bdx: lgtm https://paste.ubuntu.com/p/pTycc7W35K/
<bdx> kwmonroe: thanks for verifying
<kwmonroe> np bdx, fyi i'm on 2.3.3-highsierra-amd64 as well.
<bdx> man
<bdx> idk then
<kwmonroe> are you sure your user didn't run the register command twice?  or someone else ran it with his/her token?
<kwmonroe> maybe ask them to do "juju register --debug XXXXX" to make sure the client is getting over to the controller.
<kwmonroe> and fyi, i unregisterred pdl-aws from my client.  can't have you blaming me for insane cloud bills ;)
<bdx> aha
<bdx> thank you
<bdx> well, I cant replicate the issue anymore either
<bdx> I guess its fixed now
<bdx> sorry about the noise
<bdx> "are you sure your user didn't run the register command twice?  or someone else ran it with his/her token?" - this very well could have happened
<bdx> possibly 5-10 minutes passed between the time when I registered the user and the time that the user actually ran the register command
<kwmonroe> get your people in check bdx
<kwmonroe> bdx: is bug 1751849 cool to be closed as user's user error?
<mup> Bug #1751849: ERROR secret key for user "<username>" not found <juju:New> <https://launchpad.net/bugs/1751849>
<kwmonroe> happy to try other things, but i don't know what else we can do given the inability to repro on my side.
<anastasiamac> kwmonroe: hi o/
<anastasiamac> kwmonroe: i'll mark it as incomplete.. without repro would be hard to fix :)
<kwmonroe> anastasiamac: the fix would be to mine bitcoin on all the controllers that bdx shared with me, and then being like "it's fixed", but secretly we'd be having steak tonight.
<anastasiamac> kwmonroe: :D
<kwmonroe> or, what actually happened, i unregisterred all bdx's secrets and hope it's just working as designed ;)
<anastasiamac> kwmonroe: the only thing i could think of is that this juju register string has already been used on another client... it's a one-time-only thing...
<anastasiamac> to use it on a different client, you'd need to re-issue the token (the argument to register command)...
<kwmonroe> yeah, +1 anastasiamac, i think that's what we concluded with bdx earlier.  there was a 5-10m window where he wasn't watching his people type that could have resulted in 2 ppl running that.  the 1st invalidating the registration key for the 2nd.
<anastasiamac> kwmonroe: ack
#juju-dev 2018-02-27
<anastasiamac> wallyworld: show-credential cmd \o/ PTAL when u get a chance?...  https://github.com/juju/juju/pull/8429
<mup> Bug #1488245 changed: Recurring lxc issue: failed to retrieve the template to clone  <canonical-bootstack> <landscape> <lxc> <oil> <juju-core:Won't Fix> <https://launchpad.net/bugs/1488245>
<thumper> anyone... https://github.com/juju/juju/pull/8430
<thumper> it is an intermittent test fix
<anastasiamac> thumper: lgtm
<thumper> ta
<anastasiamac> another simple review plz, duplicate warning msg on blocked operations...  https://github.com/juju/juju/pull/8431
 * thumper looks
<wallyworld> anastasiamac: i reviewed - have a question about yaml output
<wallyworld> IMO we should try and stay consistent with list-credentials
<wallyworld> people don't want to have to re-parse stuff when running different commands
<wallyworld> when it's essentially the same info
<anastasiamac> wallyworld: so I am k with re-ordering output... say, cloud 1st etc... however, personally, i do not think that how we display credentials in list-credentials is helpful, in particularly because there is no distinction btw hidden fields (secrets), etc...
<wallyworld> that's the bit i like about it :-)
<wallyworld> easier to look at the complete set of attrs in one map
<anastasiamac> wallyworld: also do not forget that attributes are stored as maps so while u can kind of re-order some attributes to certain degree when u r reading them from a file (locally stored credential case), there is no guarantee what would be pulled from a controller (especially, say a year down the track form an original bootstrap)
<anastasiamac> trying to find consistency sometimes can be an insane pursuit..
<wallyworld> yaml can give you ordered maps
<anastasiamac> wallyworld: without separating secrets into a separate collection, the user will not immediately know whther they got a complete content or not
<wallyworld> they will know if they typed --show-secrets :-)
<wallyworld> but this is just IMO
<wallyworld> happy to get input from someone else
<wallyworld> i may well be on my on here
<wallyworld> maybe thumper can be a tie breaker :-)
<anastasiamac> wallyworld: k
<wallyworld> if we agree on field ordering, it comes down to whether to group gred attrs and whether to be consistent with list-credentials
 * thumper looks
<wallyworld> which means we avoid showing the same info in different ways
<wallyworld> deoending only on what command was run
<anastasiamac> wallyworld: bleh :-P how do i preserve formatting in github comments?
<thumper> triple quotes
<anastasiamac> no ;(
<thumper> triple single quotes
<thumper> sorry
<thumper> triple backticks
<thumper> ```
<thumper> foo
<thumper> bar
<thumper> ```
<anastasiamac> \o/ hooray \o/ thnx
<thumper> anastasiamac, wallyworld: what is the issue with formatting? formatting what and where?
<anastasiamac> thumper: pr 8429 - show-credential command output
<wallyworld> thumper: the output is different to list-credentials (which ostensibly shows the same info) and the splitting of attrs into differnet buckets rather than one map like elsewhere
<thumper> isn't it just showing one credential rather than multiple?
<anastasiamac> wallyworld: there is also additional info like models...
<anastasiamac> thumper: it can show more than one
<anastasiamac> the command shows controller-stored credential(s)
<wallyworld> sure, models will be a new block
<anastasiamac> i would have prefered to b explicit tha the credentials are coming from different places.. one way is t diplay /format output differently
<wallyworld> or we could have local-credentrials: vs controller-credenrials:
<wallyworld> as the top level field name
<wallyworld> the content though is essentillt the same
<wallyworld> one will have a models block, one won't
<wallyworld> all imo
<thumper> actually I quite like the local-credentials vs. controller-credentials top level idea
<thumper> I was leaning the other way until you mentioned this
<thumper> I like consistency,
<anastasiamac> wallyworld: controller-credentials is awesome at the top here
<thumper> we shouldn't make the users think too much
<thumper> so having similar output would be ideal
<anastasiamac> credentials: for locallly stored comes from a file... to change it to local-credentials is a bit more work ...
<thumper> anastasiamac: I think you can use struct embedding with a special tag so it doesn't get an extra level of indentation in yaml
<thumper> anastasiamac: we don't have to make it look like a file
<wallyworld> and there's map ordering support as well
<thumper> just show what the controller has
<thumper> but showing generally similar structure helps with the general cohesiveness
<anastasiamac> thumper: yes, so for controller, i.e. this command output, i can have a header of controller-credentials
<wallyworld> to order a map, have a slice of MapValue (I think) and it wil render as a map
<thumper> we should change list-credentails to say "local-credentials" too
<wallyworld> +1
<anastasiamac> thumper: for local credentials, i.e.e the output of list-credential, the header is what we have in credentils.yaml file which is "crednetials"
<anastasiamac> k
<thumper> yeah, but we should be able to override that for the output
<thumper> we don't have to change the file format
<thumper> just the output
<anastasiamac> thumper: we dont? we usually try to output what can be put into the file... if we change the output, we'd need to change the file content too...
<thumper> no... we don't
<thumper> most people should never edit the file
<thumper> I'm happy for it to be different
<anastasiamac> thumper: k
<thumper> the only reason we had that early was because we were missing commands
<wallyworld> the other reason perhaps is that the file is quite simple in structure so the output naturally looks similar
<anastasiamac> thumper: re: no-access, there is a bit of thorn that wallyworld and i discussed yesterday.. it'll b related to further work... for now, only tests have that... in real life, credential owner will always have some (in fact, probably only) admin access to the model that uses the cred
<anastasiamac> thumper: there will beother re-work (happy to discuss) that will fix the no-access in a few places.. ;D
<anastasiamac> wallyworld: as part my testing, added a comment...
<anastasiamac> i'd need to separate "content" from "models", see the sample on the PR...
<wallyworld> anastasiamac: lgtm, thank you. did you have plans be asking stakeholders if it meets their expectations in case we need to iterate a bit on the output?
<anastasiamac> wallyworld: there have been a lot of conversations when cred UX re-design came up. None of it eneded up being definitive. we r in the position now where we need to do it and iterate if needed
<wallyworld> exactly. i think we are saying the same thing.
<anastasiamac> :D
<jam> veebers: I don't know if you've noticed but the merge description that you have is repeating the first line a bit: https://github.com/juju/juju/commit/29f2a73c702fdacb20eaa231b4db7bcd417b75f1
<jam> (hard to tell from github, because one is the subject field, and then the first line is repeated)
<jam> I think just dropping it to the URL would be ok
<jam> its a bit more obvious in 'git log'
<jam> veebers: https://paste.ubuntu.com/p/p8jrHnHR5k/
<jam> my suggestion is to change it to: https://paste.ubuntu.com/p/wTzvdqh9j9/
<jam> thoughts?
<jam> wallyworld: ^^ do you agree on the alternative merge message?
<wallyworld> looking
<jam> (I also don't think we need 2 blank lines)
<wallyworld> yeah, there has been whitespace there
<wallyworld> lgtm to remove the dupes
<wallyworld> dupe messages
<veebers> jam: hey just passing through, yeah makes sense. Seems my reading of the (almost no) docs was wrong and it would always include that header text anyway
<veebers> jam: Have you deployed any of the jenkins jobs before?
<jam> veebers: so I tried to update jobs/github/github-merge-juju-description.yml
<jam> veebers: but jenkins-jobs ...
<jam> says that its doing something
<jam> but I don't see it actually changing the ci page
<jam> .../configure still has the old text in it.
<veebers> jam: What's the output of jenkins-job, also have you refreshed the configure page? :-)
<jam> veebers: refreshed and loaded on another machine
<veebers> ack
<jam> veebers: https://pastebin.canonical.com/p/nTkNw2GyjN/
<jam> veebers: I pushed the change to github, so it should be in the master branch
<jam> veebers: I can certainly edit the live site, but I'm pretty sure that's the wrong way about it.
<veebers> jam: github-merge-juju-description has updated. Not sure if your pastebin was cut short but it doesn't seem right
<jam> veebers: ah, nm, I updated only 1 of them, probably my fault.
<jam> veebers: it was intentionally cut short
<veebers> jam: oh you only  . . . hah yeah what you just sai
<veebers> said*
<jam> veebers: but I don't see that text in the other one
<jam> am I just missing it
<jam> veebers: looks like it had folded off the screen
<veebers> jam right down the bottom, in the Post Build Action section
<veebers> jam: there is github-merge-goose too :-)
<veebers> Sorry about that, I'm surprised it will always have that header text in the merge.
<jam> veebers: np. I was just being blind searching for it
<jam> balloons: when you're around, I had some questions about interpreting CI
<jam> for example, http://10.125.0.203:8080/job/ci-run/393/ seems to be saying that it has been in the "BuildJuju" stage for 7hrs
<jam> but if I go to BuildJuju, all of them are not blinking and are 'green'
<jam> though green vs blue is odd to me
<jam> I assumed it meant active
<jam> also, the console output has lots of: "java.lang.NullPointerExceptionFinished Build :"
<jam> which looks buggy to me
<jam> but it is the same content as http://10.125.0.203:8080/job/BuildJuju/323/console
<jam> balloons: hm. looks like the arm64 slave is down, thus it never built the arm64 content
<jam> which is why it got hung
<jam> balloons: also, http://10.125.0.203:8080/computer/arm64-slave/ seems to say its both offline and has low disk space
<jam> are there obvious tricks for how to clean them up?
<balloons> Good morning
<balloons> jam, green and blue are the same. Tim wanted green, but it's cached so your browser might be mixing them
<jam> balloons: morning. I think it was just that yesterday or so they were blue, today they're green, and I didn't know why
<jam> hope nobody is red/green color blind :)
<jam> lifeless was, IIRC
<balloons> Indeed :)
<rogpeppe> jam, wpk: hiya. just wondering if you remember if there's any portability problem with doing: l, _ := net.Listen("tcp", "localhost:0"); net.Dial("tcp", l.Addr().String) ?
<balloons> so jam, on the arm64-slave, /tmp is full of artifacts from unit test runs
<balloons> a bunch of juju-store-locks, test-mgo, etc. Why aren't those being cleaned up I wonder?
<balloons> I'm just rebooting the slave which will clear /tmp
<jam> rogpeppe: I don't think there is a problem, testing now, though.
<rogpeppe> jam: it definitely works in most cases, but i have a nagging feeling that it might not in some cases.
<jam> rogpeppe: AFAICT, its valid on all platforms
<rogpeppe> jam: there's a comment that worries me: // A net.TCPAddr cannot be directly stringified into a valid hostname.
<jam> it might give you an IPv6 or an IPv4
<jam> rogpeppe: sure, but that's "valid hostname"
<jam> TCPAddr is likely an IP address, and Addr() would have a port on it, as well
<rogpeppe> jam: yeah, but it's not being used there in a place that actually needs a hostname AFAICS
<rogpeppe> jam: i *think* the comment is bogus, but i thought you might remember more
<jam> rogpeppe: if you could link me to context, but AFAIK its valid
<rogpeppe> jam: the code i'm looking at right now is (in apiserver) func (s *serverSuite) TestStop(c *gc.C) {
<rogpeppe> jam: unfortunately we've lost the reviews for that period of juju's history so context is difficult to know
<rogpeppe> jam: but the commit says: http://paste.ubuntu.com/p/ppcXVQF5pW/
<jam> rogpeppe: my best guess on that test is that it wants to allow for either ::1 or 127.0.0.1
<rogpeppe> jam: ah! i see why
<rogpeppe> jam: it's a bug in newServerWithConfig
<rogpeppe> jam: oh... except
<rogpeppe> jam: it can't explicitly listen on localhost there
<rogpeppe> jam: ok, it's all starting to come back now
<rogpeppe> jam: if you listen on ":0", you're not guaranteed that Addr returns a valid dialable address
<balloons> jam, slave is online again. But it will fill /tmp again until we figure out why those tmp files aren't going way
<jam> rogpeppe: why is listen :0 not valid?
<rogpeppe> jam: listen :0 is valid, but the address you get from the listener after that doesn't necessarily provide a dialable address
<rogpeppe> jam: on Linux, it gives me an address like [::]:36758
<jam> hm. my testing says it works, but it does tend to give an IPv6 vs an IPv4
<rogpeppe> jam: which is OK under linux as a dialable address but probably not under all platforms
<jam> rogpeppe: oddly, Dial worked fine for that, but shouldn't it be ::1 to dial it?
<rogpeppe> jam: i think it's an oddspecial case in the network stack
<jam> (tested on Win10 Dial succeeded, though I don't know if it would allow packets)
<balloons> manadart, externalreality have you guys started the release at all?
<rogpeppe> jam: so this code works for you on Windows? http://paste.ubuntu.com/p/QV3BYJGv9v/
<manadart> balloons: Hi, yes. Sent the release notes to Nick and Peter. 2.3 branch is bumped. Working through now.
<jam> rogpeppe: I get "some traffic" before it exits. That said, will it work on all versions of all Windows?
<jam> This is Win10, the server tests are on 2012
<balloons> which hash are you using?
<manadart> 0303e52
<manadart> 10.13.0.0/16 via 10.172.192.1 dev tun0  metric 500
<manadart> 10.18.0.0/20 via 10.172.192.1 dev tun0  metric 500
<manadart> 10.20.0.0/16 via 10.172.192.1 dev tun0  metric 500
<manadart> 10.22.96.0/21 via 10.172.192.1 dev tun0  metric 500
<manadart> 10.22.112.0/21 via 10.172.192.1 dev tun0  metric 500
<manadart> 10.24.0.0/15 via 10.172.192.1 dev tun0  metric 500
<manadart> 10.26.0.0/16 via 10.172.192.1 dev tun0  metric 500
<manadart> 10.33.0.0/19 via 10.172.192.1 dev tun0  metric 500
<manadart> 10.34.0.0/15 via 10.172.192.1 dev tun0  metric 500
<manadart> 10.35.64.0/22 via 10.172.192.1 dev tun0  metric 500
<manadart> 10.38.0.0/16 via 10.172.192.1 dev tun0  metric 500
<manadart> 10.40.0.0/19 via 10.172.192.1 dev tun0  metric 500
<manadart> 10.48.0.0/15 via 10.172.192.1 dev tun0  metric 500
<manadart> 10.50.0.0/16 via 10.172.192.1 dev tun0  metric 500
<manadart> 10.55.0.0/17 via 10.172.192.1 dev tun0  metric 500
<manadart> 10.55.160.0/24 via 10.172.192.1 dev tun0  metric 500
<manadart> 10.70.0.0/24 via 10.172.192.1 dev tun0  metric 500
<manadart> 10.74.0.0/16 via 10.172.192.1 dev tun0  metric 1000
<manadart> 10.76.0.0/16 via 10.172.192.1 dev tun0  metric 1000
<manadart> 10.80.0.0/24 via 10.172.192.1 dev tun0  metric 500
<manadart> 10.85.48.0/24 via 10.172.192.1 dev tun0  metric 500
<manadart> 10.88.0.0/15 via 10.172.192.1 dev tun0  metric 500
<manadart> 10.96.0.0/16 via 10.172.192.1 dev tun0  metric 1000
<manadart> 10.98.0.0/16 via 10.172.192.1 dev tun0  metric 500
<manadart> 10.100.0.0/21 via 10.172.192.1 dev tun0  metric 1000
<manadart> 10.101.52.0/23 via 10.172.192.1 dev tun0  metric 1000
<manadart> 10.105.0.0/24 via 10.172.192.1 dev tun0  metric 500
<manadart> 10.110.0.0/16 via 10.172.192.1 dev tun0  metric 1000
<manadart> 10.122.36.0/22 via 10.172.192.1 dev tun0  metric 500
<manadart> 10.124.0.0/21 via 10.172.192.1 dev tun0  metric 500
<manadart> 10.125.0.0/21 via 10.172.192.1 dev tun0  metric 500
<manadart> 10.172.0.0/16 via 10.172.192.1 dev tun0  metric 500
<manadart> 10.172.192.0/18 dev tun0  proto kernel  scope link  src 10.172.193.84
<manadart> 10.189.0.0/18 via 10.172.192.1 dev tun0  metric 1000
<manadart> 10.189.64.0/24 via 10.172.192.1 dev tun0  metric 1000
<manadart> 10.189.72.0/23 via 10.172.192.1 dev tun0  metric 1000
<manadart> 10.189.74.0/24 via 10.172.192.1 dev tun0  metric 1000
<manadart> 10.189.75.0/24 via 10.172.192.1 dev tun0  metric 1000
<manadart> 10.189.84.0/24 via 10.172.192.1 dev tun0  metric 1000
<manadart> 10.189.90.0/24 via 10.172.192.1 dev tun0  metric 500
<manadart> 10.189.128.0/18 via 10.172.192.1 dev tun0  metric 1000
<manadart> 10.193.0.0/16 via 10.172.192.1 dev tun0  metric 1000
<manadart> 10.198.200.0/21 via 10.172.192.1 dev tun0  metric 1000
<manadart> 10.211.37.0/24 via 10.172.192.1 dev tun0  metric 500
<manadart> 10.222.36.0/22 via 10.172.192.1 dev tun0  metric 500
<manadart> 10.222.64.0/20 via 10.172.192.1 dev tun0  metric 500
<manadart> 10.222.128.0/18 via 10.172.192.1 dev tun0  metric 500
<manadart> 10.227.32.0/20 via 10.172.192.1 dev tun0  metric 1000
<manadart> 10.227.240.0/21 via 10.172.192.1 dev tun0  metric 1000
<manadart> 10.228.0.0/16 via 10.172.192.1 dev tun0  metric 1000
<manadart> 10.229.0.0/16 via 10.172.192.1 dev tun0  metric 1000
<manadart> 10.230.0.0/16 via 10.172.192.1 dev tun0  metric 1000
<manadart> 10.231.64.0/21 via 10.172.192.1 dev tun0  metric 500
<manadart> 10.231.96.0/21 via 10.172.192.1 dev tun0  metric 500
<manadart> 10.231.128.0/21 via 10.172.192.1 dev tun0  metric 500
<manadart> 10.231.144.0/21 via 10.172.192.1 dev tun0  metric 500
<manadart> 10.232.0.0/16 via 10.172.192.1 dev tun0  metric 1000
<manadart> 10.235.64.0/22 via 10.172.192.1 dev tun0  metric 500
<manadart> 10.244.0.0/18 via 10.172.192.1 dev tun0  metric 1000
<manadart> 10.244.128.0/18 via 10.172.192.1 dev tun0  metric 1000
<manadart> 10.244.192.0/18 via 10.172.192.1 dev tun0  metric 1000
<manadart> 10.245.0.0/16 via 10.172.192.1 dev tun0  metric 1000
<manadart> 10.245.80.0/22 via 10.172.192.1 dev tun0  metric 500
<manadart> 10.245.128.0/21 via 10.172.192.1 dev tun0  metric 500
<manadart> 10.245.136.0/21 via 10.172.192.1 dev tun0  metric 500
<manadart> 10.245.160.0/19 via 10.172.192.1 dev tun0  metric 500
<manadart> 10.246.0.0/19 via 10.172.192.1 dev tun0  metric 1000
<manadart> 10.246.40.0/21 via 10.172.192.1 dev tun0  metric 1000
<manadart> 10.246.48.0/21 via 10.172.192.1 dev tun0  metric 1000
<manadart> 10.246.56.0/21 via 10.172.192.1 dev tun0  metric 1000
<manadart> 10.246.64.0/21 via 10.172.192.1 dev tun0  metric 1000
<manadart> 10.246.72.0/21 via 10.172.192.1 dev tun0  metric 1000
<manadart> 10.246.80.0/21 via 10.172.192.1 dev tun0  metric 1000
<manadart> 10.246.88.0/21 via 10.172.192.1 dev tun0  metric 1000
<manadart> 10.246.96.0/20 via 10.172.192.1 dev tun0  metric 1000
<manadart> 10.246.112.0/21 via 10.172.192.1 dev tun0  metric 1000
<manadart> 10.247.0.0/21 via 10.172.192.1 dev tun0  metric 500
<manadart> 10.247.0.0/16 via 10.172.192.1 dev tun0  metric 1000
<manadart> 10.248.0.0/16 via 10.172.192.1 dev tun0  metric 1000
<manadart> 91.189.88.0/21 via 10.172.192.1 dev tun0  metric 500
<manadart> 91.189.91.0/24 via 10.172.192.1 dev tun0  metric 1000
<manadart> 162.213.32.0/22 via 10.172.192.1 dev tun0  metric 500
<manadart> 185.125.188.0/22 via 10.172.192.1 dev tun0  metric 500
<manadart> 192.168.64.0/23 via 10.172.192.1 dev tun0  metric 500
<manadart> 192.168.89.0/24 via 10.172.192.1 dev tun0  metric 500
<manadart> 192.168.211.0/24 via 10.172.192.1 dev tun0  metric 500
<manadart> 192.168.220.0/24 via 10.172.192.1 dev tun0  metric 1000
<manadart> 192.168.224.0/22 via 10.172.192.1 dev tun0  metric 1000
<manadart> 192.168.228.0/23 via 10.172.192.1 dev tun0  metric 1000
<manadart> 192.168.230.0/23 via 10.172.192.1 dev tun0  metric 500
<manadart> 192.168.233.0/24 via 10.172.192.1 dev tun0  metric 500
<manadart> 192.168.236.0/22 via 10.172.192.1 dev tun0  metric 1000
<manadart> 192.168.240.0/24 via 10.172.192.1 dev tun0  metric 500
<manadart> 192.168.246.0/23 via 10.172.192.1 dev tun0  metric 1000
<manadart> 192.168.248.0/22 via 10.172.192.1 dev tun0  metric 1000
<manadart> Oops.
<balloons> surprised you weren't flood kicked
<balloons> jam, do you know why juju-store-lock files stick around in /tmp?
<jam> balloons: not explicitly
<jam> balloons: I'm blaming charmstore, but I'm actually digging into it
<balloons> jam, it's odd because we're building and testing in containers, but the host machine ends up being filled with those files in /tmp
<balloons> ahh, well, actually we're using tmpfs, so that does make sense
<jam> balloons: yay, 'juju-store-lock' doesn't exist anywhere in the code base, so its clearly a built-up string and I'm sure its using 'juju' 'store' and/or 'lock' to build it up... ugh
<balloons> ohh jam, well it comes from jujuclient/file.go:	return fmt.Sprintf("store-lock-%x", fullHash[:8]) ?
<jam> balloons: presumably we're supposed to be putting those into $JUJU_HOME ?
<balloons> jam, I'm not sure. I'm just noticing we setup tmpfs for the unit tests, but not the builds. And it seems we clean it, probably for that reason. Still, a testrun really shouldn't leave things behind
<jam> balloons: this has the smell of someone escaping our IsolationSuite (which is supposed to set things like JUJU_HOME to invalid values so it doesn't accidentally leak)
<balloons> jam, perhaps a card to have a look?
<jam> balloons: looks like all of our on-disk lock objects don't have a Cleanup function, which sort of makes sense, as if it is a shared lock, you don't want to clean it up on process exit, but we *should* be cleaning them up for testst
<jam> balloons: is it actually a lot of disk-space in them?
<jam> that part should be quite small
<jam> but potentially lots of them
<balloons> jam, yes. it adds up quickly surprisingly. the filelist is too long to run rm juju-store-lock* :-) So eventually it burns all the disk space up
<balloons> jam, 20g was burned in about 3 days, which is the size of that slaves /tmp
<balloons> the other slaves all have massive disks, so we wouldn't know for a long time
<jam> balloons: wow. k. I would have thought each juju-store-lock would be tiny, but I can see it still burns inodes, etc.
<jam> balloons: so *an* option is to set TMPDIR for a test run, and then 'rm -rf TMPDIR' when its done
<balloons> jam, yea I'm updating things now to clean out /tmp. We were cleaning up test-mgo* files, so I'm adding juju-*.
<jam> balloons: you *might* need to check for gobuild as well
<jam> not sure whether thats 'go-build' or 'gobuild'
<jam> but I've seen bogus stuff there
<jam> that said, I'd like us to have a way to not leave cruftn.
<jam> though the mechanism flock uses makes it hard.
<balloons> jam.. ohh, ok, I'll add a check for that too
<thumper> morning
#juju-dev 2018-02-28
<thumper> wallyworld: would like a quick chat re: intermittent failing provisioner test when you have a moment
<thumper> veebers, wallyworld: https://github.com/juju/juju/pull/8434
<thumper> or anyone really
<anastasiamac> thumper: lgtm
<thumper> thanks
<thumper> anastasiamac: I have another good bug for you
<thumper> I'm just writing a comment
<anastasiamac> :( i was goign to keep going with cred ux (my bug-meter was appeased with 2 for the day) \o/
<anastasiamac> thumper: but i'll look (curiosity and the cats as u know...)
<thumper> https://bugs.launchpad.net/juju/+bug/1638714
<mup> Bug #1638714: Upgrading a juju model before the controller gives unhelpful error message <usability> <juju:Triaged> <https://launchpad.net/bugs/1638714>
<thumper> anastasiamac: this relates to the issue someone brought to the mailing list earlier today as well
<thumper> we aren't good at helping people when they do the wrong thing
<thumper> anastasiamac: btw, the setting to trace gives more output from the actual provisioner worker
<thumper> it says more about what it is doing
<thumper> the info in the test was just for extra logging
<thumper> and yes, it works :)
<thumper> I did test it
<thumper> oh ffs
 * thumper doesn't know vi
<anastasiamac> thumper: looked and commented... since it's coming from state, the re-phrasing may not be as simple... i think that this is the case of where we are lacking some guidance as the user confusion is because they need to upgrade 'controller' model first
<thumper> anastasiamac: but we can do extra checks... it isn't that hard, it just may be a few more api calls, but a better user experience
<thumper> anastasiamac: did you want to have a quick chat before I EOD?
<jam> just checking that other people are failing to connect to canonical IRC, right?
<jam> (I'm assuming it is the restart-for-spectre issue)
<veebers> jam: I am
<veebers> wgrant: I imagine related to a firewall reboot? (I saw a comment to that affect just before connection dropped :-))
<thumper> jam: yes IS is rebooting machines
 * thumper EODs
<jam> veebers: just reconnected
<wgrant> Also see your email :)
<wgrant> An announcement of utter chaos was sent last night.
<jam> can I get a review on https://github.com/juju/juju/pull/8432 ?
<jam> anastasiamac: https://github.com/juju/juju/pull/8436 reviewed
<anastasiamac> jam: thnx but i believe it's not ready - tim and i will talk tomorrow. whilst re-phrasing the message is good, the UX needs to b slightly adjusted for better experience.... fwiw, the wording was almost verbatum to what was in the bug
<jam> anastasiamac: I'd argue that your fix is still better than no fix, even if we ultimately want to do more
<frankban> jam: re your comment at https://github.com/juju/juju/pull/8427 (which is ready for review) develop will be 2.4?
<jam> frankban: yes. develop == 2.4
<frankban> jam: I guess we can backport the patch later when required?
<jam> frankban: IME its usually easier to start at the older code base, but its up to you.
<jam> frankban: and since you guys are the ones that want the patch, its more a question of whether you're ok waiting until we do a 2.4 release
<jam> which 2.4 final is at least a month away
<frankban> jam: well, the patch against develop is already there, I;ll talk with uros about that. who could I ping to get a review of that part of the code?
<thumper> babbageclunk: ping
<thumper> https://github.com/juju/juju/pull/8438
<babbageclunk> thumper: yeah, saw that - looking at it now
<thumper> babbageclunk: did you want to talk through it or are you happy?
<babbageclunk> thumper: Oh, I thought you'd put in a skip and I'd need to fix it. No, that seems good to me!
<thumper> no... I fixed it
<thumper> :)
<babbageclunk> Thanks! Sorry!
<thumper> that's fine
<thumper> babbageclunk: want to approve the pr? and I'll land it
<thumper> babbageclunk: got 5 minutes?
<thumper> babbageclunk: hangout?
<babbageclunk> thumper: done. Ah, I had seen 8434 but not the fix
<babbageclunk> yup
<babbageclunk> 1:1
<thumper> omw
<thumper> ugh...
<thumper> I'm sure my local test failures are probably due to me running go 1.10, and the merge and test bots using 1.9
<thumper> anyone https://github.com/juju/juju/pull/8439
<thumper> thanks wpk
<thumper> gym time
 * thumper heads off
<kurt_> Do you guys know if anyone watches the maas channel anymore?
<kurt_> Seems like they don't
#juju-dev 2018-03-01
<wallyworld> babbageclunk: a few small comments
<babbageclunk> wallyworld: thanks
<frankban> wallyworld: hey, do you have time for taking a look at https://github.com/juju/juju/pull/8427 ?\
<wallyworld> frankban: sure, but it's not an area i know much about
<frankban> wallyworld: ty I already got suggestions from roger in the apiserver area
<wallyworld> i need to make dinner etc first but will look as soon as ai can
<frankban> wallyworld: ty!
<rogpeppe> anyone know what Go version is being used for Juju CI tests?
<externalreality> Question: I am using go version 1.9.4 - I pulled develop - gofmt was beside itself with grief (or just sad) when I ran it. What version of Go is Juju being built with now (Github says 1.9)?
<rogpeppe> externalreality: are you using a recent version of gofmt?
<externalreality> rogpeppe: which gofmt yields '/snap/bin/gofmt'
<rogpeppe> externalreality: what does "which go" print?
<externalreality> rogpeppe: the snap - it yields /snap/bin/go
<rogpeppe> externalreality: hmm, so they *should* be consistent :)
<externalreality> I get:
<externalreality> gofmt is sad:
<externalreality>   cmd/juju/commands/helptool.go
<externalreality> error: failed to push some refs to
<externalreality> rogpeppe so it is just the one file
<rogpeppe> externalreality: looks like that file is just wrong
<rogpeppe> externalreality: it's got an extra newline at the end
<rogpeppe> externalreality: i wonder how that got through CI
<rogpeppe> externalreality: looks like https://github.com/juju/juju/pull/8428 is at fault
<rogpeppe> externalreality: maybe CI is no longer checking for gofmt exact output
<rogpeppe> externalreality: (which would be sensible, tbh, as the output can vary between go releases)
<rogpeppe> externalreality: it's changed a fair number of files in go1.10 for example
<rogpeppe> externalreality: BTW the -l (list files that would be changed) and the -d (show diffs) flags to gofmt can be useful
<externalreality> Wondeful! Thank you rogpeppe.
<rogpeppe> externalreality: np :)
<rogpeppe> externalreality: will see you at the budapest sprint, i hope :)
<rogpeppe> assuming my airport hasn't closed from all the snow...
<externalreality> rogpeppe, :-D
<kwmonroe> hey anastasiamac, do we have a point-person for the juju vsphere provider? i'm looking for a triage on bug 1751858.
<mup> Bug #1751858: support vsphere disk.enableUUID model config <juju:New> <https://launchpad.net/bugs/1751858>
<mup> Bug #1752662 opened: ssh-proxy does not work as expected on AWS <juju-core:New> <https://launchpad.net/bugs/1752662>
<mup> Bug #1752662 changed: ssh-proxy does not work as expected on AWS <juju-core:New> <https://launchpad.net/bugs/1752662>
<mup> Bug #1752662 opened: ssh-proxy does not work as expected on AWS <juju-core:New> <https://launchpad.net/bugs/1752662>
<anastasiamac> kwmonroe: afaik, no (sorry for delay in answering - was 3am my time) but m following it up to ensure u get answers re vsphere :D
<kwmonroe> np anastasiamac - thanks for the followup!
<hml> exit
<hml> :-) wrong window
<wallyworld> babbageclunk: sometime today if i could land this would be most awesome. a bit of boilerplate as is usual when adding a facade https://github.com/juju/juju/pull/8441
<babbageclunk> wallyworld: ok, will take a look after the meeting
<wallyworld> yay
<rick_h> thumper: how did the webinar go?
#juju-dev 2018-03-02
<thumper> good, as in it went
<thumper> pretty happy
<thumper> but off now,
<thumper> errands and packing
<thumper> flying out early tomorrow
<babbageclunk> wallyworld: approved
<wallyworld> tyvm
<wallyworld> babbageclunk: it took lines of code because the facade for the broker tracker worker didn't have the model method. other facades do but they are for different workers
<babbageclunk> yeah, I know - sorry, wasn't really a criticism of your change.
<wallyworld> babbageclunk: oh no worries, didn't think it was :-)
<wallyworld> there's a lot of boilerplate in doing api facades
<wallyworld> would be great to code gen the boilerplate
<babbageclunk> true that
