#juju-dev 2013-07-29
<bigjools> wallyworld_, thumper: should have you a working maas in about an hour, need to download 300MB of updates and re-commission nodes
<wallyworld_> rightio
 * thumper noticed that the ubuntu edge igg has stalled just under 7m
<thumper> bigjools: if you could fling wallyworld_ and me the details for the environments.yaml file, that'd be swell (when it's ready)
<bigjools> I will
<davecheney> what is a MIR ? https://blueprints.launchpad.net/ubuntu/+spec/servercloud-s-mongodb
 * thumper looks
<thumper> davecheney: where is MIR mentioned?
<thumper> ah
<thumper> Main Inclusion Request
<thumper> AFAIK
<thumper> at least that is what I think it is
<davecheney> I only know MRE
<thumper> which is?
<davecheney> Meals Ready to Eat
<thumper> haha
<thumper> wallyworld_: I noticed today that when I started up a second machine on ec2, and it had two ccontainers on it
<thumper> wallyworld_: when the lxc provisioner task started, it didn't get told about the new containers
<thumper> so they never started
<thumper> the two containers on machine 0 started
<thumper> but their machine agent would have been running first
<bigjools> thumper: which ssh key of yours should I put on here?
<thumper> whereas the machine 1 would have been booted after the two containers in state
 * thumper looks
<wallyworld_> it should have queried state
<thumper> wallyworld_: I agree, it should have
<thumper> wallyworld_: but it does that by starting the watcher
<wallyworld_> you think this is a new bug?
<thumper> wallyworld_: what I'm saying is that something is screwy there
<thumper> probably
<thumper> may need some more poking
<wallyworld_> afaik the watcher returns the inital state of play
<thumper> yes it should
<thumper> but it seems in this case, it didn't
<thumper> I probably need some extra tracing...
<wallyworld_> so i wonder what has changed. i can't recall any of us touching this stuff
<thumper> no
<thumper> but the machine agent has had some messing around with the state -> api stuff recently
<wallyworld_> hmmmm
<thumper> also, general watchers have seen change since this worked before
<bigjools> thumper: ?
<thumper> bigjools: I dm'ed you the key
<bigjools> ah nm got it
<bigjools> was looking on LP  and you have loads
<thumper> yeah
<thumper> jake is the current machine
<thumper> elwood was the last one
<bigjools> jake is my eldest twin's name
<thumper> :)
<thumper> what did you call the other?
<bigjools> he's getting better, thank goodness
<bigjools> Harley
<thumper> you missed an opportunity there
<bigjools> s/missed/avoided/
<thumper> there was a funny facebook message the other day about nature names
<thumper> Dragonhunter FTW
<bigjools>  /o\
<thumper> luckily for the children, i can't have any more
<thumper> unless advances in stem cell research changes things
<jtv> thumper: any chance you could review this branch for me: https://codereview.appspot.com/11923043/ ?
<thumper> jtv: there is always a chance
 * jtv rolls dice
<jtv> davecheney: my information is that MRE stands not for Meal Ready to Eat, but Meal Rejected by Ethiopians.
 * thumper starts reviewing
<thumper> done, school pickup, back shortly
 * thumper considers a branch that allows setting log levels remotely
<axw> *sigh* gotta go see the neighbour, fence fell over
<axw> bbs
<thumper> :(
<rvba> Morning guysâ¦ I've got a tiny branch up for reviewâ¦ in case someone is free to review it: https://codereview.appspot.com/11913043/
<TheMue> morning
<axw> morning
<rogpeppe> rvba: reviewed
<rogpeppe> axw, TheMue: mornin'
<rvba> Thanks a lot rogpeppe.
<axw> hey rog
<rogpeppe> dimitern, fwereade: thanks for the reviews; responded. https://codereview.appspot.com/11932043/
<dimitern> rogpeppe: me too :) (replied to one of your comments)
<rogpeppe> dimitern: i like the idea of reusable constructs for writing tests, but not when using them is more work than doing the basic version.
<rogpeppe> dimitern: i don't think statetesting.AssertStop gains us anything at all
<dimitern> rogpeppe: how can it possibly be more work?
<dimitern> rogpeppe: don't you use code completion? :)
<rogpeppe> dimitern: is that why it's less work?
<rogpeppe> dimitern: it's also less obvious than the basic version
<rogpeppe> dimitern: and i like to keep test code as simple as possible
<rogpeppe> dimitern: it should really be called AssertThatStopSucceeds
<dimitern> rogpeppe: ohh..
<dimitern> rogpeppe: :) well, ignore me then, but my point was to enforce consistency when possible
<dimitern> rogpeppe: otherwise each module can be its own world because it makes sense there and then, rather than having a codebase-wide uniformity
<jtv> Hi folks â how's tarmac doing today?
<dimitern> jtv: still dead i think
 * jtv wipes away tear
<jtv> Did I hear mention of a workaround?
<rogpeppe> dimitern: Assert(x.Stop(), IsNil) seems about evenly balanced with AssertStop in the code base
<dimitern> jtv: manual landing
<jtv> I don't think I have privileges for landing.  :(
<dimitern> mgz: can you explain jtv about how can he land his code manually?
 * rvba listens
 * jtv turns on the water heater in anticipation
<dimitern> rogpeppe: and if it was s.AssertStop(c, w) would it be better?
<rogpeppe> dimitern: not really.
<rogpeppe> dimitern: i like to see the Stop call directly in the code.
<dimitern> rogpeppe: so you're not complaining about the length of the idents
<jtv> FWIW for me as an outsider, Assert(x.Stop(), IsNil) is a lot easier to understand.  Might I suggest a compromise of "AssertStopSucceeds"?
<rogpeppe> dimitern: not really. just the fact that it's a single line of code which i think is clearer written out each time than calling a function to do it
<dimitern> rogpeppe: how about statetesting.AssertCanStopWhenSending then?
<rogpeppe> jtv: exactly.
<rogpeppe> jtv: thanks
<fwereade> rogpeppe, dimitern: fwiw you can also defer AssertStop without dropping errors on the floor
<dimitern> fwereade: ah! very good point
<rogpeppe> fwereade: now *that* is a good reason for using it
<fwereade> rogpeppe, dimitern: and once you're using it in one place you may as well keep doing so IMO
<dimitern> exactly
<dimitern> jtv, rvba: well don't know if mgz is around, but basically the process goes as follows
<fwereade> rogpeppe, dimitern, jtv: and while we're bikeshedding -- AssertCleanStop?
<jtv> The hard part is expressing both the side effect and the assertion.
<rogpeppe> jtv: yeah
<dimitern> 1) switch to trunk, 2) pull, 3) bzr merge lp:~user/juju-core/yourbranch, 4) go build ./... && go test ./... (in juju-core/), 5) if all pass (and assuming no live testing is needed), 6) commit locally, setting the commit message as in LP, 7)bzr push bzr+ssh://go-bot@bazaar.launchpad.net/~go-bot/juju-core/trunk
<dimitern> jtv: rvba ^^
<dimitern> 8) set MP to Merged + set revision in LP
<mgz> dimitern: I odn;t think red squad have hte bot creds
<dimitern> step 7) requires you to have access to go-bot's branch
<mgz> or rather, red squad's ssh keys aren't on the launchpad bot accout
<dimitern> mgz: ah, right, but did i summarize it well?
<mgz> ypu
<jtv> dimitern: thanks, that push URL was the part I was missing of course.
<jtv> Should I give it a try anyway?
<mgz> you can bzr info i
<mgz> *it
<dimitern> jtv: perhaps after all is done, you could push it to lp:~user/juju-core/trunk and let me or mgz push it to trunk for you until the ssh keys are sorted
<mgz> running the test suite after merge and setting commit message in the mp will do
<mgz> I can land pretty easily after that
<jtv> mgz: "bzr info" says permission denied.  :(
<mgz> right.
<jtv> But yes, I guess I could just merge all my approved branches into a personal trunk for the time being.
<jtv> I think bzr has just implemented netsplits.
<mgz> oh, that would work too
<jtv> I thought that was what you meant when you said "push it to lp:~user/juju-core/trunk".. ?
<jtv> Sorry, what Dimiter meant.
<mgz> well bundling lots of changes up there saves some time
 * fwereade_ is going to try to find somewhere with coffee, bbiab
<dimitern> jtv: but please, get in line so we won't introduce conflicts/breakages
<dimitern> ideally, after bzr pull on trunk, run go build ./... && go test ./... before starting to merge to make sure trunk is sane
<rogpeppe> perhaps we could make lbox submit work again for the time being
<dimitern> rogpeppe: I don't think this is a good idea
<rogpeppe> dimitern: ok
<dimitern> rogpeppe: doing it manually will enforce some discipline and when the bot comes it'll be easier to switch
<rogpeppe> dimitern: at least lbox submit checks that the code builds and is gofmt'd
<jtv> dimitern: no need for that command line when just the age-old conventional "make check" will do.  :-)
<jtv> It has the added advantage of giving clear failure output at the end if the tests failed.
<jtv> With the manual command, any test failures may have scrolled out of view.
<jtv> Or "make build check format" to combine building, testing, and formatting.
<jtv> Anybody willing to review https://codereview.appspot.com/12018043 ?
<dimitern> jtv: i'll take a look
<jtv> Thanks
<TheMue> And another review from my side: https://codereview.appspot.com/11910043/ ?
<jtv> Looking
<jtv> Oh, I already approved that one so I don't qualify.  :)
<dimitern> TheMue: will take a look after jtv's review
<TheMue> dimitern: great, cheers
<wallyworld_> fwereade_: making a juju validate super command didn't work out very well. there were a number of dead ends, especially wrt flag processing for sub commands. the juju cmd infrastructure is really only designed for only one level of sub command off juju. so it will be easier just to land as is for now
<rogpeppe> dimitern: i got this error trying to push to trunk as suggested:
<rogpeppe> bzr: ERROR: Server sent an unexpected error: ('error', 'AppendRevisionsOnlyViolation', 'Operation denied because it would change the main history, which is not permitted by the append_revisions_only setting on branch "chroot-74851280:///~go-bot/juju-core/trunk/".')
<dimitern> jtv: reviewed
<rogpeppe> anyone got any idea what that error means?
<jtv> Thanks dimitern
<mgz> rogpeppe: you messed up the merge :)
<dimitern> rogpeppe: hmm, not really - perhaps mgz or some lp/bzr guys?
<rogpeppe> mgz: ok, so *how* did i mess up the merge?
<jtv> Might it mean that somebody pushed something during your pull/merge/commit/push?
<mgz> if for instance you merge trunk into your branch, then try pushing your branch over trunk, you get
<jtv> Which then wouldn't be in the revisions you were trying to push?
<rogpeppe> jtv: i'd have expected a "branch has diverged" error in that case
<mgz> you have all the revs, history hasn't diverged, but you rearranged it's order
<rogpeppe> ah, i know what i did wrong!
<axw> if anyone cares about debug-hooks, I've got it working now: https://code.launchpad.net/~axwalk/juju-core/lp1027876-implement-debug-hooks/+merge/177353
<axw> I'll add more tests tomorrow, and hopefully propose it
<jtv> Thanks for the review dimitern
<rogpeppe> i forgot to pull from trunk before merging
<dimitern> jtv: yw, tried to adhere to the way you prefer reading them :)
<rogpeppe> axw: nice one!
<jtv> dimitern: I noticed.  Thoughtful of you â it really helps.
<axw> gtg, night folks
<jtv> nn axw
<dimitern> jtv: it's strange that even though I put a blank line before every comment, not all of them appear like that in the mail
<jtv> No, Rietveld is sneaky and likes to remove them when you edit them.
<dimitern> jtv: aahh! good to know
<TheMue> dimitern: seen your s/.  Foo /. Foo/ statements in a review. it seems to be a convention for some of us to use two spaces after a point. i already wondered too.
<dimitern> TheMue: That's madness :)
<dimitern> TheMue: the only way I've seen this happen is when I use M-q in emacs to auto-format and align a comment block
<TheMue> dimitern: dunno, maybe it's normal in some countries. but not in Germany.
<TheMue> dimitern: ah, emacs, may be a reason.
<dimitern> TheMue: when you have // ...something.\n// something else. M-q will make it // ...something.  something else.
<dimitern> (2 spaces after the .)
<TheMue> dimitern: strange behavior, would like to know the reason
<dimitern> TheMue: perhaps, as with everything in emacs, it's configurable, but I don't know
<jtv> It's something I learned in my typing course.  I find it greatly helps legibility, especially with the weird stuff we type with lots of dots that aren't full stops.
<dimitern> ha! I found it
<dimitern> it's called "sentence-end-double-space", and if set to nil won't do it
<jtv> There is a rant on the internet that says it's nonsense, and people who oppose double-spacing invariable point to it with no more than the implication that since it's on the internet, it's the unassailable truth.
<jtv> The rant starts out with a few inobtrusive assumptions:
<jtv> (1) There is no such thing as monospace fonts, anywhere in the world, ever.
<dimitern> LOL
<TheMue> hehe
<dimitern> i'd stop reading after (1) :)
<dimitern> i know possibly only one person ever who used proportional fonts while editing code
<jtv> (2) Software such as LaTeX can reliably tell the difference between a dot and a full stop, despite the fact that it regularly needs help telling them apart.
<rogpeppe> dimitern: :-)
<rogpeppe> dimitern: i know quite a few :)
<jtv> So do I...  Never could quite bring myself to try it.
<jtv> Should I proceed with assumption (3)?
<dimitern> why try it - it's *evil*
<rogpeppe> dimitern: ha ha
<rogpeppe> dimitern: you get more legible text in less space. what's not to like?
<jtv> Sometimes I think I'd like an IDE to render unformatted block comments as flowing, proportionally-kerned text.
<TheMue> Funnily Smalltalk environments often use non-monospace fonts and still format their methods (because that's what you see in the code browser) in a very  aesthetic way.
<jtv> SmallTalk.  So far ahead the rest of the world will never catch up.  :)
<TheMue> jtv: Smalltalk, not SmallTalk :P
<dimitern> reading fiction and reading code is quite a different thing and requires different focus
<jtv> I believe it.
<TheMue> jtv: A wonderful language for some domains, sadly very bad regarding concurrency and distribution. *sigh*
<dimitern> when i'm reading code I notice characters, then words, in fiction, I rarely notice such things, because they won't induce a compile error :)
<TheMue> dimitern: NOT? *rofl*
<jtv> Maybe "fiction" is not quite the right word.
<jtv> Because some code is fictional, and much non-code writing is nonfiction.
<dimitern> ok then, natural text?
<jtv> Sure.
<jtv> Running text.  Human-readable text.  Prose.
<jtv> (Prose isn't so good because it raises the question: what about poetry?)
<TheMue> Isn't code pure ficction? The idea of something that happens? :D
<jtv> No, in code we oppose a sea of troubles and by opposing end them.
<jtv> Which I feel is nobler in the mind than suffering the guns and roses of outrageous fortune.
<TheMue> And introduce new troubles.
<jtv> I don't think the Bard mentioned secondary bugs.
<dimitern> reminds me of wordpress' moto "code is poetry" :)
<jtv> Then again, he didn't actually say "guns 'n' roses" either.
<jtv> All code should be in dactylic hexameter.  That'll stop idiots from knocking out crud without thinking.
<jtv> Quidquid id est timeo danaos et dona  ferentes.
<TheMue> Ouch
<dimitern> :D
<TheMue> Next round: Isn't LISP the pure incarnation of poetry?
<TheMue> *duck*
<dimitern> I prefer Scheme
<TheMue> dimitern: me too
<jtv> Common Lisp!  Variables!
<dimitern> why do you need variables when you have lambdas? :)
<jtv> Ich weiÃ nicht was soll es bedeuten / das ich so traurig bin / eine Routine aus ur-alten Zeiten...
<dimitern> even I got most of this
<TheMue> jtv: Hey, wow
<dimitern> it my poor german
<jtv> TheMue: sorry, didn't mean to insult your cultural heritage.  :-)
<dimitern> *with
<jtv> But I do feel like that sometimes when I read ancient functions.
<TheMue> jtv: no problem, only have been surprised
<rogpeppe> trivial CL (func rename and arg reorder) https://codereview.appspot.com/12021043/
<dimitern> TheMue: reviewed
<jtv> TheMue: what surprised me is that quite possibly the most beautiful German I've ever heard was an American reciting that poem off the cuff...
<TheMue> dimitern: cheers
<TheMue> rogpeppe: question about godoc
<rogpeppe> TheMue: go on
<TheMue> rogpeppe: the line break after // ...directory. (line 54 in upgrader.go).
<TheMue> rogpeppe: will it be visible in the godocs too? your intention seems to be a paragraph, isn't it?
<rogpeppe> TheMue: godoc will reformat the whole thing into one paragraph
<rogpeppe> TheMue: i should probably cfmt the comment
<jtv> rogpeppe: you have my vote.
<rogpeppe> jtv: thanks
<TheMue> rogpeppe: that's what I expected.
<TheMue> rogpeppe: won't an empty line render as a new paragraph?
<rogpeppe> TheMue: yes
<rogpeppe> TheMue: i didn't really intend them to be different paras
<TheMue> rogpeppe: ah, ok
<TheMue> rogpeppe: reviewd
<rogpeppe> TheMue: thanks
 * TheMue => lunch
<mgz> hm, no mail since friday, must be imapclean day
<rogpeppe> another pretty trivial CL: https://codereview.appspot.com/12025043
<dimitern> rogpeppe: does the upgrader now use the API?
<rogpeppe> dimitern: yes
<rogpeppe> dimitern: although cmd/jujud doesn't yet use worker/upgrader
<dimitern> rogpeppe: ok (updating the blueprint)
<dimitern> rogpeppe: also, you've got a review
<rogpeppe> dimitern: thanks
<natefinch> Hi all. In theory I am joining the juju dev team today, though HR/IT/whoever has not actually given me any login information. So I figured I'd just come here and say hi.
<dimitern> natefinch: hey! welcome aboard!
<dimitern> natefinch: so you'll be working on juju-core or on some related project, like the gui, etc. ?
<fwereade_> natefinch, welcome!
<natefinch> Hi, thanks.  You'll have to forgive me if I am not up on my IRC skills... it's been... oh god, like 15 years since I was last on irc, in college.
<natefinch> I'll be on juju-core, from what Mark Ramm said
<fwereade_> natefinch, not to worry :)
<fwereade_> dimitern, hey, did the last one we released actually use the api for the machiner? or did that not get in in time?
<dimitern> fwereade_: I think it did
<fwereade_> dimitern, oh bugger
<fwereade_> dimitern, ah well, not to worry
<natefinch> mramm:  Morning, Mark. This appears to be the only place I can access currently, FYI.
<mramm> ok
<dimitern> fwereade_, rogpeppe, wallyworld_: standup
<wallyworld_> i would if the stupid google plugin would upgrade
<TheMue> natefinch: heya, welcome here in the channel too
<dimitern> natefinch: if you want to join the daily standup: https://plus.google.com/hangouts/_/f497381ca4d154890227b3b35a85a985b894b471
<natefinch> awesome, thanks
<natefinch> TheMue: plugin installing... forgot I hadn't done that yet
<ehg> hope i'm not intruding, but is there anyway to do https://bugs.launchpad.net/juju-core/+bug/1089291 manually atm? like modifying the mongo db?
<_mup_> Bug #1089291: terminate-machine --force <juju-core:Triaged> <https://launchpad.net/bugs/1089291>
<mgz> mramm, natefinch: IS has the ticket for nate's new staff task, but it seems no one is on to get started with it yet.
<natefinch> alexlist is giving me a hand
<mramm> mgz: yea I see nobody is on vanguard yet
<mgz> ace, if alex is handling it that's fine.
<alexlist> Nobody around until deej starts working today ... looks very holiday-ish today ...
 * dimitern lunch
<mgz> dear go, have working juju on lcy02 finally
<mgz> that was painful
<rogpeppe> lunch
<mgz> warning all, the bot is up but not yet tweaked into happiness
<mgz> I'll mail the list when I get it rolling properly again
<TheMue> mgz: thanks for your effort already
<rogpeppe> fwereade_: how about this for an API in common to both the machine and unit agent? http://paste.ubuntu.com/5925443/
<fwereade_> rogpeppe, LGTM
<rogpeppe> fwereade_: thanks
<fwereade_> rogpeppe, are you likely to be implementing a state.Agent interface roughly matching that? because I find myself heading in a very similar dirction, I think
<rogpeppe> fwereade_: i've just done the front end bits. i'm just about to do the server side.
<rogpeppe> fwereade_: i'm not sure quite what you mean by the state.Agent interface
<fwereade_> rogpeppe, as Authenticator, Remover, Lifer, whatever
<fwereade_> rogpeppe, ISTM that making unit and machine's agenty methods accessible via a State.Agent() call using state.entity() would fit nicely
<rogpeppe> fwereade_: perhaps. i'm not sure.
<rogpeppe> fwereade_: i thought i might do Jobs as a special case
<rogpeppe> fwereade_: as it doesn't really make sense to implement Unit.Jobs
<rogpeppe> fwereade_: the other methods aren't really Agent - they're *used* by the agent API, which i think is a bit of a different thing
<fwereade_> rogpeppe, fwiw I think that "a unit is an agent with just one job" is quite a neat model
<rogpeppe> fwereade_: i considered it, but i don't think it helps much
<fwereade_> rogpeppe, and remeber this isn't about how the API looks, it's about how it's convenient to present state to the API layer for clarity/convenience
<rogpeppe> fwereade_: it makes the unit agent code more complex (what's the point of having a Jobs method that you don't consult?)
<fwereade_> rogpeppe, it eliminates the distinction between machine and unit agent
<rogpeppe> fwereade_: ah, is that your intention?
<fwereade_> rogpeppe, except we're talking about different things still
<fwereade_> rogpeppe, long-term, maybe
<fwereade_> rogpeppe, but the jobs thing seems like the biggest issue
<rogpeppe> fwereade_: it seems pretty trivial to me
<rogpeppe> fwereade_: i'd just put a dynamic type check in the Job API entry point
<fwereade_> rogpeppe, indeed, and so "an agent is a thing that runs jobs on behalf of some entity" becomes an nice clear accurate explanation
<rogpeppe> s/Job/Jobs
<rogpeppe> fwereade_: i like the fact that the unit agent code is simpler than the machine agent code
<rogpeppe> fwereade_: because it doesn't need to inspect dynamic jobs to run
<fwereade_> rogpeppe, but the thing I'm thinking about today is state.Agent, which would have a whole bunch of methods used by various bits of the api, eg uniter machiner upgrader
<fwereade_> rogpeppe, if that's not on your mind then all the better, we won't collide and you can see if you like it when I propose ;)
<rogpeppe> fwereade_: i think it's probably better to have separate interfaces for each piece of the API
<rogpeppe> fwereade_: rather than one agent interface to rule them all
<rogpeppe> fwereade_: tbh i'd prefer it if each of those interfaces was defined in the respective API server package
<rogpeppe> fwereade_: rather than in state
<rogpeppe> fwereade_: i think that matches Go's post-hoc interface definition idiom better
<fwereade_> rogpeppe, I am not talking about the interfaces exposed by the API, I am talking about the interfaces exposed *to* the API
<rogpeppe> fwereade_: that's what i'm talking about too
<rogpeppe> fwereade_: i don't think the state package should need to second-guess the interfaces needed by the APIs built on top of it
<fwereade_> rogpeppe, in my mind, it's not second-guess, it's responding to clear need
<rogpeppe> fwereade_: it's unnecessary - each of those API packages can define their own interface to abstract out the relevant parts of the state package
<rogpeppe> fwereade_: AFAICS
<rogpeppe> fwereade_: of course, state needs to define interfaces when it actually returns those interfaces (e.g. Lifer), but i'm not sure that it needs to know about Agent, for example. that seems like something built on top of it, at a different level.
<rogpeppe> fwereade_: but i'm interested to hear your take on it too
<fwereade_> rogpeppe, I dunno, I think that the agent concept is already more than a little embedded in state
<fwereade_> rogpeppe, AgentTools
<fwereade_> rogpeppe, SetAganetAlive
<fwereade_> er whatever
<rogpeppe> fwereade_: yes, there are bits and pieces
<fwereade_> rogpeppe, I think that collecting them together will actually be pretty clear
<rogpeppe> fwereade_: as is necessary - those are pieces of agent-specific state
<rogpeppe> fwereade_: calling the interface "Agent" is wrong though
<rogpeppe> fwereade_: perhaps AgentEntity
<rogpeppe> but i don't like that either
<fwereade_> rogpeppe, like LiferEntity and UAuthenticatorEntoty today, you mean ;p
<fwereade_> god my typing is shot today
<rogpeppe> fwereade_: you started to remind me of an ex-coworker who had notoriously bad typing :-)
<rogpeppe> fwereade_: Lifer defines an object with a Life method
<rogpeppe> fwereade_: Authenticator defines an object with authentication methods
<rogpeppe> fwereade_: Agent would *not* define an object with agent methods
<rogpeppe> fwereade_: but it would simply have some methods that happen to be used by agents
<rogpeppe> fwereade_: and i don't really see why that interface should be defined in state itself.
<rogpeppe> fwereade_: in general we don't predefine all possible interfaces in Go, but leave it up to the client code to do that.
<fwereade_> rogpeppe, the distinction between "agent methods" and "methods that happen to be used by agents" does not seem to me to present an overwhelming practical difference
<fwereade_> rogpeppe, ISTM that if we do that we end up with the funky downcasting we already have in apiserver
<rogpeppe> fwereade_: they're totally different. an agent method would be something like MachineAgent.Run.
<fwereade_> rogpeppe, "meh, everything we're calling here will have hat method, let's just use a Lifer"
<fwereade_> rogpeppe, what we're getting kinda needs to be defined at the state level
<fwereade_> rogpeppe, lots of little interfaces make sense where overlap is limited
<fwereade_> rogpeppe, bigger interfaces also make sense where there's a lot of overlap, I think
<fwereade_> rogpeppe, *even if* and given client of an Agent uses only one or two methods on it
<fwereade_> s/and/any/
<fwereade_> rogpeppe, anyway, I'm going to go and see if the plan comes off coherently anyway ;p
<fwereade_> rogpeppe, cheers
<dimitern> fwereade_, rogpeppe: https://codereview.appspot.com/12034043 - names package
<rogpeppe> fwereade_: ok
<dimitern> a lot of files are changed, but most changes are just renames
<rogpeppe> dimitern: i think i'd put all the code into one file in names - i don't think the sizes are big enough to justify the separate files, and i'd find it easier to read like that.
<dimitern> rogpeppe: i could do that, but I think separation is a good thing
<rogpeppe> dimitern: why so?
<rogpeppe> dimitern: i don't see that it helps anything really
<rogpeppe> dimitern: other than meaning i need to flip back and forth to see what things are referring to
<dimitern> rogpeppe: we could expand it later to include more stuff
<rogpeppe> dimitern: we could split it into multiple files as appropriate if that happens
<rogpeppe> dimitern: i find it much easier to see the whole lot on a single page
<dimitern> rogpeppe: then check LP's diff :)
<rogpeppe> dimitern: what about it?
<dimitern> rogpeppe: but seriously, I'm not insiting on it staying like this - fwereade_ what do you think?
<rogpeppe> dimitern: if nothing else, the related constants should go into the relevant files.
<dimitern> rogpeppe: this makes more sense to me, ok
<fwereade_> dimitern, rogpeppe: I rather liked the bite-size nature of those files
<fwereade_> dimitern, rogpeppe: well, maybe, having all the constants in one place also has its benefits
<rogpeppe> fwereade_: really?
<fwereade_> dimitern, rogpeppe: I found it very easy to absorb that package as it was
<dimitern> rogpeppe: once it lands, using godef to jump to each definition is trivial
<rogpeppe> fwereade_: i found myself flipping back and forth between constant and code
<fwereade_> dimitern, rogpeppe: the conceptual dividing lines are clear, and the simplicity of each chunk is also pretty clear IMO
<rogpeppe> fwereade_, dimitern: constants.go blurs the conceptual dividing line
<fwereade_> rogpeppe, dimitern: the question is kinda what to do about the bits that are common
<rogpeppe> fwereade_: what bits?
<fwereade_> rogpeppe, dimitern: numbers, service names
<dimitern> rogpeppe: having separate constants.go made sense when I did it, but as I said, I can move them into their relevent files instead
<fwereade_> dimitern, rogpeppe: I would be fine with that though
<dimitern> rogpeppe: not all of them are specific, some are common
<rogpeppe> fwereade_: if we're staying in separate files (which i can live with) then service.go seems like the right place for service names
<fwereade_> dimitern, rogpeppe: OTOH, unit.go will use it too, and one day perhaps relation.go
<dimitern> rogpeppe: how about NumberSnippet and others, which are used more than once?
<rogpeppe> although a whole file for a 3 line function does seem like overkill
<fwereade_> dimitern, rogpeppe: having one file that describes in a very compact way all the data, and one file per entity that handles the tedious manipulation of each kind, seems to me like a reasonable balance
<dimitern> rogpeppe: it's better so separate them early, rather than ending up with a monstrous module like state
<fwereade_> dimitern, rogpeppe: but I'm happy calling dealer's choice on this, this is the very definition of a bikeshed
<rogpeppe> i'd really like to see the whole lot in one place, but perhaps i'm old fashioned like that. i never programmed in java.
<rogpeppe> dimitern: for NumberSnippet, i'd just choose an arbitrary place
<dimitern> yeah, I forgot to say <bikeshed> earlier (until we reach an agreement </bikeshed> ) :)
<rogpeppe> dimitern: nicer to have the rest of the constants nearer to where they're used
<dimitern> rogpeppe: so compromise: having common bits in constants.go and entity-related stuff in their respective files?
<rogpeppe> dimitern: i guess.
<rogpeppe> dimitern: 115 lines doesn't seem like too much for a file though.
<rogpeppe> </bikeshed>
<dimitern> rogpeppe: "divide and conquer" wasn't invented for java
<dimitern> rogpeppe: it's generally a good practice for structuring code I think
 * rogpeppe prefers each file to be worth its weight
<dimitern> rogpeppe: how big a file should be at least?
<dimitern> rogpeppe: is less than 50 lines the limit? or 20?
<rogpeppe> dimitern: it totally depends
<dimitern> rogpeppe: of course
<rogpeppe> dimitern: in this case, i think everything would fit very neatly into one file, and the common patterns in the code would be more evident that way
<dimitern> rogpeppe: and mixing responsibilities in the same place is a bad idea for the sake of having less files imho
<rogpeppe> dimitern: all this code is doing a very similar thing. that for me is a good indicator that it belongs together.
<dimitern> rogpeppe: not really, the packge has very well defined goal, that's why it looks like that
<rogpeppe> dimitern: whatever
<rogpeppe> dimitern: i didn't mean this to turn into a bikeshed argument
<rogpeppe> dimitern: i've stated my preference
<dimitern> rogpeppe: ok
<dimitern> rogpeppe: let's agree to disagree on that one
<dimitern> rogpeppe: :) no need to argue about minor stuff like this
<rogpeppe> dimitern: yeah
<rogpeppe> dimitern: one thought: instead of returning (string, error), i'm wondering if (string, bool) might be better
<rogpeppe> dimitern: i dunno though
<dimitern> rogpeppe: I was thinking about it, but we already have Is*(string) bool, and most of the code that handles externally received strings is using it
<rogpeppe> dimitern: yeah
<dimitern> rogpeppe: only a few places expect to pass a tag and get and id/name, which is wrong I think - the tag should be checked before
<dimitern> rogpeppe: and moreover, not checking the format and getting an error allows you to "defer the responsibility" of deciding what to do to your caller
<rogpeppe> dimitern: yeah - it's just the single error thing - when there's only one kind of expected error, i wonder if a bool is more useful
<dimitern> rogpeppe: I could do that, but then in the few cases when there's a possible error, we have to define and return that error, so potentially it creates a bit of duplication
<dimitern> rogpeppe: in the place it was called
<rogpeppe> dimitern: yeah, that's true. i have mixed feelings.
<mgz> can I have some help working out what my last batch of test failures on the bot relate to?
<mgz> https://code.launchpad.net/~themue/juju-core/035-bootstrap-autosync/+merge/177119/comments/399419/+download
<mgz> one is obvious...
<mgz> I guess the others may be related?
<TheMue> mgz: that branch is not yet approved
<mgz> I've been approving it as a test
<mgz> ..is it not approved as in I should be approving it?
<mgz> I thought it was the one you wanted to land...
<mgz> no harm done if so, but I guess I should have used a less-real branch
<mgz> ^*shouldn't
<TheMue> mgz: I have to land changes first;)
<mgz> okay, I'll stop using that as a g-pig
<TheMue> mgz: the BootstrapSuite now show a failure it hadn't before :(
<mgz> I'm proposing a trivial branch I can test with instead
<mgz> took too long to find a comment change, darn william and rog being native english and not screwing up grammar enough
<rogpeppe> dimitern: reviewed
<dimitern> rogpeppe: cheers
<mgz> and bah, we've broken 1.0 compat again
 * mgz adds the ppa
<mgz> muh, and it doesn't pass go fmt
<mgz> rogpeppe: how did you manage that?
<rogpeppe> mgz: perhaps i ran a different gofmt on it
<mgz> I guess that's my trivial change to land
<rogpeppe> mgz: gofmt passes ok against trunk for me
<mgz> compalins about trailing whitesapce on a comment for me
<rogpeppe> mgz: what gofmt are we using as standard?
<rogpeppe> mgz: i've been using go-1.0.2's gofmt for ages now
<mgz> 1.0.2 is good, but not if we also break 1.0.2 compat >_<
<rogpeppe> mgz: but go 1.1's does indeed complain about trunk
<rogpeppe> mgz: i thought gwacl had already broken 1.0.2 compat
<dimitern> fwereade: ping
<rogpeppe> mgz: and yes, oops, i didn't test against 1.0.2 before submitting, and i missed a return statement
<fwereade_> dimitern, pong
<fwereade_> dimitern, blast, I should finish reviewing that
<dimitern> fwereade: thanks :)
<fwereade_> dimitern, quick question -- would dropping "Name" across the board lead to less stuttering? names.IsUnitName etc
<rogpeppe> fwereade_: i've made a bunch of comments which you might want to take in before you continue
<rogpeppe> fwereade_: that sounds good to me
<mgz> I'm self-approving my trivial bot testing branch
<dimitern> fwereade: makes sense
<dimitern> TheMue: I can't see the changes you said you did?
<mgz> okay, my one remaining test failure is commented by rogpeppe as bug 1163983
<_mup_> Bug #1163983: some tests take an unnecessarily long time waiting for the poll interval <tech-debt> <juju-core:Triaged> <https://launchpad.net/bugs/1163983>
<mgz> is there anything I can do to mitigate that on the bot?
<dimitern> mgz: what go version is the bot using?
<dimitern> mgz: I think that failure is intermittent
<mgz> from the ppa, 1.1.1
<mgz> bot has just hit it twice in a row...
 * mgz reapproves to see how consistent that is
<TheMue> dimitern: not yet pushed
<dimitern> mgz: it seems the issue is [LOG] 19.20390 ERROR juju worker: fatal "deployer": remove /etc/init/jujud-machine-3:unit-tarmac-0.conf: permission denied
<mgz> thanks
<mgz> that seems like an isolation issue...
<dimitern> mgz: seems likely, it the test should be creating /tmp/gocheck-*/etc/init or something
 * dimitern bbiab
<mgz> blame on that change is you? :P
<mgz> ...there's nothing obviously wrong...
<mgz> filed bug 1206195
<_mup_> Bug #1206195: TestDyingMachine fails when unit agent is running on machine <juju-core:Confirmed> <https://launchpad.net/bugs/1206195>
<dimitern> mgz: does it fail on your machine? on mine it doesn't
<mgz> are you on a juj-deployed machine with a running unit-agent?
<dimitern> well, obviously not :)
<mgz> I'd not expect it to break for you then :)
<dimitern> how does that matter?
<mgz> because that's what the error is saying
<mgz> the test is trying to talk to the bot's unit-agent, which obviously tells it to sod off, confusing the test
<dimitern> how can this happen?
<mgz> it really shouldn't :)
<mgz> (I have no idea)
<dimitern> is there a JUJU_* or ~/.juju/environments.yaml there?
<mgz> in good news, the bot is now live again
<mgz> dimitern: no.
<dimitern> alive, like working properly?
<mgz> yup.
<dimitern> except for that issue above
<mgz> I shall summarise to the list
<mgz> that issue is gone for now, I skipped out the test
<dimitern> great! thanks
<dimitern> hmm, ok, i guess for the time being that's acceptable
<TheMue> mgz: fantastic, thx
<dimitern> fwereade: sorry to bug you again
<rogpeppe1> dimitern, fwereade, anyone else interested: https://codereview.appspot.com/12038045
<rogpeppe1> and i need another review of https://codereview.appspot.com/12025043/ please
<dimitern> rogpeppe1: looking
<rogpeppe1> that's me for the night
<rogpeppe1> dimitern: ta!
<dimitern> rogpeppe1: nn then
<rogpeppe1> dimitern: it has the ChangeAgentTools CL mixed in unfortunately, but it's separate enough that i think it's ok for the time being
<rogpeppe1> dimitern: 'cos i'd prefer to avoid a prereq
<dimitern> rogpeppe1: no worries
<rogpeppe1> right, i really am off now, to pick some peas from the garden
<rogpeppe1> g'night all
<mgz> okay, I'm done for the day, email me if stuff blows up
<Beret> can someone bump the priority of https://bugs.launchpad.net/juju-core/+bug/1188126 please?
<_mup_> Bug #1188126: Juju unable to interact consistently with an openstack deployment where tenant has multiple networks configured <canonistack> <juju:New> <juju-core:Triaged> <https://launchpad.net/bugs/1188126>
<sidnei> uhm, anyone around that can take a look at https://bugs.launchpad.net/juju-core/+bug/1205112 ? it's blocking me :(
<_mup_> Bug #1205112: panic while setting a config value <juju-core:Triaged> <https://launchpad.net/bugs/1205112>
<thumper> hi sidnei
<thumper> sidnei: I don't suppose you have made it reproducable on the local provider?
 * thumper woners which nick nate is
<thumper> and I see he left 19 minutes ago
<thumper> oh well
<thumper> arosales: do you know how I can get access to the test MAAS?
<sidnei> thumper: well, i deployed a new service and got it again
<sidnei> thumper: i wonder if it's charm-specific
<thumper> sidnei: could be a good bug for us to give to axw
<thumper> he seems to be hammering through them
<thumper> I'll pass on the info when he gets on
 * thumper is attacking maas
<sidnei> thumper: i suppose there's nothing like pdb for golang?
<thumper> for a stack trace?
<thumper> or to just stop
<sidnei> thumper: no, to step through
<thumper> depends how hard core you are
<thumper> I have heard that there is a go part for gdb
<thumper> not tried it though
<sidnei> i've poked around gdb and pyframes once
<sidnei> i could just add some prints around the comparison line i guess
<thumper> when in the SFO go meetup, someone asked what people used for debugging
<thumper> print statements was the common answer
<thumper> :-(
<sidnei> its choking on:
<sidnei> 		if new == old {
<sidnei> 			continue
<sidnei> 		}
<sidnei> in settings.go
<thumper> it seems to me, having not looked at the code...
<thumper> that it is failing to coerse the command line strings into int values
<thumper> so comparing an int to a string representation of an int
<thumper> are you changing an int value?
<thumper> or numeric / bool
<thumper> ie. non-string
<sidnei> thumper: nope, it's a string
<sidnei> one of the commands was: juju set u1-stream host_environment_name=dc -e local
<sidnei> and the error is:
<sidnei> panic: runtime error: comparing uncomparable type map[string]interface {}
<sidnei> im suspecting it might be choking on a previously set value
<sidnei> the service was deployed with deploy --config <config.yaml>
<sidnei> there was no error during deploy (at least in the command line)
<sidnei> it seems only half of the values from the --config config.yaml got set
<andreas__> guys, I got a "panic" from juju-core, is this a low memory situation? http://pastebin.ubuntu.com/5926829/
<thumper> sidnei: sounds very suspect
<thumper> ahasenack: possibly
<ahasenack> 500Mb RAM, no swap
<ahasenack> 2013-07-29 21:48:21 ERROR juju uniter.go:352 worker/uniter: hook failed: fork/exec /var/lib/juju/agents/unit-nova-cloud-controller-0/charm/hooks/install: cannot allocate memory
<ahasenack> hah
<arosales> dpb1, looking at the bug 1205466
<_mup_> Bug #1205466: deploy charm uses cached copy even when all services are removed <papercut> <juju-core:Triaged> <https://launchpad.net/bugs/1205466>
<dpb1> arosales: yup, need something?
<arosales> dpb1, nope sorry I was catching up on backscroll
<arosales> looks like mramm already commented on this bug and discussed it here
<dpb1> arosales: cool
<wallyworld_> thumper: how's things?
<thumper> otp
<wallyworld_> ok
<thumper> wallyworld_: hangout?
<wallyworld_> sure
<wallyworld_> https://plus.google.com/hangouts/_/f497381ca4d154890227b3b35a85a985b894b471?v=1374717932
#juju-dev 2013-07-30
<wallyworld_> davecheney: normally, the name of a compiled Go executable takes after the package directory name. can i change this so that the binary is named something different? eg the directory is "metadata" but I want the binary to be called "juju-metadata" when i do a go install
<thumper> wallyworld_: you may have to rename or symlink after the fact maybe?
<wallyworld_> thumper: yeah, i was trying to avoid that since most devs just do a "go install" and it will be wrong
 * thumper nods
<thumper> package names can't have a - right?
<wallyworld_> right :-(
<thumper> in which case you are rightly fcuked
<wallyworld_> we can add rules to the deb packaging config etc but i want devs to be able to use it easily also
<wallyworld_> i can also add a make target
<wallyworld_> but most core devs don't like the makefile :-(
<wallyworld_> it's all working apart from that
<wallyworld_> thumper: what i've done for now is make the package name "jujumetadata" so at least the binary has a reasonable, juju specific name in the default case where no rename is done as part of a local go install
<thumper> wallyworld_: yes make a make-target
<thumper> wallyworld_: and seems reasonable to have the long package name
 * thumper looks for the default make target
<wallyworld_> will do. so between the make target and the juju* package name  we should be ok
<thumper> make all
<wallyworld_> and i'll look into how our release scripts work
<thumper> make install maybe
<wallyworld_> make install is good i think
 * thumper nods
<thumper> there isn't one now
<thumper> but should be easy enough
<thumper> I will review that change if you like
<thumper> I don't mind makefiles :)
<axw> what doesn't allow "-" in the package name?
<wallyworld_> Go
<axw> it does
<axw> "." isn't
<wallyworld_> it complained when i tried
<wallyworld_> let me try again
<axw> ah hang on
<axw> sorry, I'm thinking of commands
<axw> where the packagae name is "main"
<wallyworld_> axw: no, you are right. "-" is ok. not sure what i did the first time. thanks :-)
<axw> wallyworld_: nps
<wallyworld_> thumper: it seems i need to provide a --description argument to the plugin. what is the intent there? isn't description similar to purpose? or?
<thumper> wallyworld_: --description is shown when someone goes "juju help metadata"
<thumper> no, that's help isn't it
<wallyworld_> yeah
<thumper> --description is shown when someone goes "juju help plugins"
<thumper> should be a one liner
<wallyworld_> yes
<wallyworld_> right, but purpose does that doesn't it?
<thumper> what purpose?
<wallyworld_> ie cmd.Info.Purpose is the one liner
<thumper> plugins are defined to be language agnostic
<thumper> and entirely unrelated to our cmd stuff
<wallyworld_> ok. i'll just make the plugin print Purpose since it's in Go
<jtv> Yay!  The landing bot is running again then?
<thumper> should be
<jtv> Oh.  But nothing's landed, and all my pending branches failed because the build environment wasn't fully set up.
<jtv> Working now.  Mine could be the first branches in!
<thumper> jtv: you have a merge conflict
<jtv> Inevitable.  Thanks for the notice.
<jtv> But another one got in.  Two more to go.
<jtv> thumper: oh good, it's all imports!
<jtv> Wouldn't it be nice if we could automate that kind of resolution...
<jtv> Throw all imports from the conflicting branches together, split them up into the 3 categories and format, try a build, remove any imports that the compiler says aren't needed.
<wallyworld_> thumper: i've found an issue with the plugin command. it was incorrectly dropping arguments meant for the plugin. there's a simple one line fix. i'll add a test also
<thumper> wallyworld_: you need to pass --
<thumper> to stop the supercommand parsing the extra args
<thumper> so
<thumper> juju plug -for-juju  -- -for-plugin
<wallyworld_> hmmm. ok. i did this change
<wallyworld_> --- cmd/juju/plugin.go  2013-07-30 01:31:52 +0000
<wallyworld_> +++ cmd/juju/plugin.go  2013-07-30 02:57:22 +0000
<wallyworld_> @@ -26,7 +26,7 @@
<wallyworld_>         flags := gnuflag.NewFlagSet(subcommand, gnuflag.ContinueOnError)
<wallyworld_>         flags.SetOutput(ioutil.Discard)
<meetingology> wallyworld_: Error: "@" is not a valid command.
<wallyworld_>         plugin.SetFlags(flags)
<wallyworld_> -       cmd.ParseArgs(plugin, flags, args)
<wallyworld_> +       flags.Parse(false, args)
<wallyworld_>         plugin.Init(flags.Args())
<thumper> schoool run
<bigjools> afternoon
<wallyworld_> thumper: back?
<thumper> yep
<thumper> just had a coffee :)
<thumper> nice
<thumper> bigjools: how's tricks?
<bigjools> thumper: awake, just, but twin1 is home at least
<thumper> that must be a relief
<wallyworld_> thumper: with my change above, you no longer need the "--". without my change, the user can't run "juju metadata validate-image -r region" unless threy put in the "--" themselves which kinda sucks
<wallyworld_> with my change, the args just get flicked through to the plugin to handle
<thumper> but plugins are environmental commands
<thumper> so -e is valid
<thumper> and -e needs to be handled by juju
<thumper> to set the environment for the plugin
<wallyworld_> sure, -e works for me
<wallyworld_> as expected
<thumper> -e does what?
<wallyworld_> pciks the env to use
<wallyworld_> juju metadata -e openstack validate-image -r foo
<wallyworld_> works
<thumper> the tricky bit is where -e is parsed
<thumper> is it parsed by juju
<thumper> or the plugin?
<wallyworld_> hmmm. i think i made the plugin an env command
<thumper> yeah...
<wallyworld_> so will need to check
<thumper> so this would break other plugins
<thumper> I do think the -- is the better solution
<thumper> as sucky as it may be
<wallyworld_> i'll look into it a bit more. i really don't like the -- for built in plugins that are supposed to look like normal commands
<thumper> yeah I know
<thumper> but I'm not sure how to handle it better
<thumper> without too much manual fuckery
<thumper> will probably need work in gnuflag package
<wallyworld_> i'm hoping to avoid that
<wallyworld_> i'll see if i can insert the --
<wallyworld_> since we are writing the "built in" plugin code
<thumper> :)
<thumper> axw: do you have a gravatar?
<axw> thumper: umm yes
<axw> should be on axwalk@gmail.com
<axw> oh you mean for canonical.com?
 * thumper marvals at the number of errors he just generated
<thumper> axw: if you attach your canonical email address to your gravatar, it shows up in leankit
<axw> okey dokey
<thumper> BOOM!!!!
<thumper> that is what my tests say
 * thumper should really focus on MAAS and not the logging stuff
<thumper> OMG we have some awful tests
<bigjools> thumper: why are you surprised?
<thumper> bigjools: I'm not really
<bigjools> ah so that was more of an Oh Em Gee rather than a OMG
 * thumper nods
 * thumper shelves this work
<thumper> it needs more focus
 * thumper goes back to maas
<thumper> why does ssh use -p and scp use -P ?
 * thumper pushes 24mb to bigjools
<bigjools> thumper: thanks a bunch :)
<thumper> np
<thumper> you have 35G free
<thumper> sorry
<thumper> 181G free
<thumper> only 35 used
<thumper> heaps of space
<bigjools> yeah that machine can be happily destroyed
<bigjools> I suspect my downlink is better than your uplink
<thumper> bigjools: I bet it is too
<thumper> 114.6KB/s to push over the ditch
 * thumper bootstraps bigjools's maas
<thumper> I always get confused as whether to put the s in 's for something that ends with s
<thumper> is there a good rule?
<thumper> bigjools: how long until maas realises there is a bootstrap and updates the gui?
<bigjools> thumper: instant
<bigjools> but it looks fooked
<thumper> it didn't show anything
<bigjools> yeah not here either
<thumper> even though bootstrap supposedly succeeded
<bigjools> refresh
<thumper> ah, there we go
<bigjools> could be a timeout on rabbit etcetc
<thumper> kk
<thumper> so now wait 20 minutes?
<bigjools> yep
<bigjools> the node powered itself up so should be ok
<bigjools> you just deployed bare metal from 1500 miles away
<thumper> \o/
<thumper> kinda cool
<thumper> I'll come back later and poke the running instance
<rogpeppe1> mornin' all
<rogpeppe1> i'd love a second review of this, please, if anyone wants to have a look. it's very small: https://codereview.appspot.com/12025043/
<rogpeppe1> TheMue: ^
<TheMue> rogpeppe1: will look in a moment, my vm is just starting ;)
<rogpeppe1> TheRealMue: thanks
<axw> so I had a branch that failed tests on the bot... due to some missing imports in files I didn't change
<axw> I shouldn't need to manually merge from trunk first right?
<axw> https://code.launchpad.net/~axwalk/juju-core/lp1182898-add-version-flag/+merge/176849
<axw> (now I have manually merged, and I need another review...)
<TheMue> rogpeppe1: could you resend the link pls?
<rogpeppe1> TheMue:  https://codereview.appspot.com/12025043/
<TheMue> rogpeppe1: thx
<rogpeppe1> TheMue: and https://codereview.appspot.com/12038045/ too, if you have a little more time
<rogpeppe1> TheMue: (i accidentally incorporated the first one into it, so please ignore the upgrader package changes in the second one - they'll disappear when the first one gets merged into trunk)
<TheMue> rogpeppe1: first review done, looking at the second now ;)
<rogpeppe1> TheMue: thanks!
* ChanServ changed the topic of #juju-dev to: https://juju.ubuntu.com | On-call reviewer: TheMue | Bugs: 5 Critical, 80 High - https://bugs.launchpad.net/juju-core/
<axw> rogpeppe1: do you know what I need  to do to make Go Bot happy here?
<axw> https://code.launchpad.net/~axwalk/juju-core/lp1182898-add-version-flag/+merge/176849/comments/399702
<rogpeppe1> axw: looking
<rogpeppe1> axw: oh yes, it's poxy
<rogpeppe1> axw: you need to reload the launchpad page before marking it Approved
<rogpeppe1> axw: i *think* that's probably the reason
<axw> mmkay
<rogpeppe1> axw: it marks the mp as "approved at this particular revision"
<axw> rogpeppe1: thanks, I'll give it a shot
<axw> ah
<rogpeppe1> axw: it bites everyone
<axw> do you know why I would've got those test failures in the previous comment?
<axw> I didn't change any of that stuff in my branch
<axw> trunk should always be clean... and there would've been no merge conflicts
<TheMue> rogpeppe1: review is in
<rogpeppe1> TheMue: ta!
<rogpeppe1> axw: i'll have a look
<rogpeppe1> axw: i've no idea, sorry - i haven't seen anything like that before
<rogpeppe1> axw: i'd suspect mgz's bot setup
<rogpeppe1> axw: we'll see if my MP goes in ok
<rogpeppe1> axw: hmm, mine merged ok, so it looks like the bot *is* working
<axw> rogpeppe1: nps, thanks for checking
<rogpeppe1> axw: see if it happens again
<axw> rogpeppe1: I already merged manually and pushed, which is the wrong thing to do... I hope that doesn't screw anything up?
<rogpeppe1> axw: when the bot is working, that is frowned upon
<rogpeppe1> axw: but given that i'm sure you ran all the tests, it seems reasonable while the bot is flaky
<axw> rogpeppe1: ok, sorry. hopefully it just works next time...
<rogpeppe1> axw: yeah
<axw> rogpeppe1: when I say I merged manually, I mean I merged trunk into my branch and reapproved my MP
<axw> I didn't push to the trunk directly
<rogpeppe1> axw: oh, that's standard practice
<axw> rogpeppe1: phew :)
<TheMue> :)
<thumper> fwereade: ping
<thumper> fwereade_: ping?
<thumper> mgz: morning
<mgz> hey thumper!
<fwereade_> thumper, pong
<thumper> fwereade_: hey, was thinking we hadn't chatted in a while
<thumper> fwereade_: and was wondering if you wanted to catch up
 * thumper sits on the edge of his seat waiting for a response...
<thumper> mgz: did you want to catch up since I'm online anyway?
<mgz> sure
<thumper> mgz: skype, hangout, mumble?
<mgz> anything but skype works for me :)
<thumper> hangouts on my android phone really sucks the battery
<thumper> mgz: so hangout is ok?
<thumper> better than mumble normally
<mgz> yup
<mgz> axw, rogpeppe1: yeah, the bot doesn't want to resolve merge conflicts for you, it's not sentient
<axw> mgz: fair enough ;)  where can I see the merge conflicts?
<axw> there weren't any when I did a manual merge
<rogpeppe1> mgz: ah, that error message didn't look like a merge conflict
<mgz> axw: `bzr merge --preview -d trunk mybranch` or similar
<axw> mgz: I already merged from trunk into my branch, and there were no conflicts
<wallyworld> rogpeppe1: fwereade_: i've pushed changes to the validation branch. there's now built in plugin support, with the necessary changes to pass through args and help directives etc. so you can go 'juju help metadata' to get general plugin help listing the supported sub commands and 'juju help metadata validate-image' to get detailed help for that specifc command
<axw> not sure why, but I got this failure: https://code.launchpad.net/~axwalk/juju-core/lp1182898-add-version-flag/+merge/176849/comments/399279
<axw> (I didn't touch any of those files)
<fwereade_> wallyworld, cool, tyvm
<wallyworld> fwereade_: see what you think. but i'm quite happy with the ui and how it works
<mgz> axw: er, sorry, confusing things, looking at the right branch now (it's actually merged now)
<rogpeppe1> wallyworld: great, thanks
<wallyworld> btw, the binaries just get compiled and put in the normal bin directory
<axw> mgz: I'm not sure if it was necessary, but I merged from trunk after I got that failure, and then pushed back to LP and reapproved the MP
<mgz> axw: the message from the bot is complaining that you hit 'approve' in the merge proposal at r1541, then pushed (or launchpad didn't register the push until) the merge of trunk as r1542
<mgz> so, you had an extra rev that wasn't in the change that was 'approved'
<axw> mgz: yep thanks, I understand that last error now
<mgz> not really useful in this case as you're self landing
<axw> just not sure why the original test failure occurred
<axw> as there was never a merge conflict AFAICT
<axw> and I didn't change those files
<mgz> that mp also has a note from yesterday when the bot was all borked while I was fixing, that can be ignored
<wallyworld> thumper: we probs need to talk to fwereade_ about how/if we should try and record what containers a particular instance supports
<mgz> there was a general "don't approve things" in place, but you may not have realised as it was at the end of last week and I didn't restate yesterday
<axw> mgz: okey dokey, sorry about that. I thought it was lifted
<mgz> not until 6ish when I sent the email, but apart from confusing you did no harm :)
<axw> ;) cool
<rogpeppe1> wallyworld: if i type "juju help commands", should i expect to see information on plugins there too?
<wallyworld> rogpeppe1: no. you want to type juju help plugins
<wallyworld> plugins can be bash scripts, python, whatever
<rogpeppe1> wallyworld: ah, that needs to be documented somewhere
<wallyworld> rogpeppe1: it is isn't it? thumper did all that work
<rogpeppe1> wallyworld: oh yeah, it is
<rogpeppe1> wallyworld: hmm, i'm not sure that "juju help topics" should be separate from "juju help" but that's a matter for a different discussion
<rogpeppe1> wallyworld: BTW i'd expect "juju metadata generate-image --help" to work, but it doesn't
<rogpeppe1> wallyworld: what does it mean to be a "built-in plugin"
<rogpeppe1> ?
<rogpeppe1> wallyworld: i.e. why is the metadata plugin special like that?
<rogpeppe1> wallyworld__: what was the last thing you saw me say?
<rogpeppe1> wallyworld__: ping
<wallyworld__> rogpeppe1: hi, sorry was washing up after dinner. i saw you say "oh yeah"
<rogpeppe1> wallyworld__: ah, ok
<rogpeppe1> [10:23:09] <rogpeppe1> wallyworld: hmm, i'm not sure that "juju help topics" should be separate from "juju help" but that's a matter for a different discussion
<thumper> rogpeppe1: juju help topics shows it
<rogpeppe1> 10:24:03] <rogpeppe1> wallyworld: BTW i'd expect "juju metadata generate-image --help" to work, but it doesn't
<rogpeppe1> [10:26:23] <rogpeppe1> wallyworld: what does it mean to be a "built-in plugin"
<thumper> but the default help should have it shown too
<rogpeppe1> [10:26:24] <rogpeppe1> ?
<rogpeppe1> [10:26:49] <rogpeppe1> wallyworld: i.e. why is the metadata plugin special like that?
<rogpeppe1> thumper: i'd forgotten about help topics
<rogpeppe1> thumper: would it be unreasonable to merge "help topics" into "help" ?
<thumper> rogpeppe1: that shows a bit much
<thumper> especially as I'm trying to get more topics
<thumper> like constraints
<wallyworld__> rogpeppe1: the --help should work i think. i'd been testing with help. plugin arg handling is a little different
<thumper> and other...
<wallyworld__> rogpeppe1: built in just means it is shipped with juju
<rogpeppe1> thumper: i wouldn't mind seeing a few more lines in juju help
<wallyworld__> out of the box
<rogpeppe1> wallyworld__: why does "built-in" imply "doesn't allow interspersed flags" ?
<thumper> rogpeppe1: I'd ask jcastro and marco what they think
<rogpeppe1> thumper: +1
<rogpeppe1> wallyworld__: also, isn't the very point of a plugin that it's external to the main executable?
<wallyworld__> rogpeppe1: because that's what is needed to make the flag handling pass all the args to the next command invoked
<wallyworld__> rogpeppe1: it is external
<wallyworld__> it's a separate binary
<rogpeppe1> wallyworld__: so why are built-in plugins special in their flag-handling requirements?
<wallyworld__> rogpeppe1: all plugins are
<wallyworld__> but external plugins require --
<wallyworld__> and i'd rather make the built in ones look "native"
<wallyworld__> and not make the user type "--"
<rogpeppe1> wallyworld__: that seems like unreasonable special-casing to me
<rogpeppe1> wallyworld__: a plugin should be a plugin
<rogpeppe1> wallyworld__: line 30 of https://codereview.appspot.com/11566043/diff/54001/cmd/juju/plugin.go seems weird to me
<wallyworld__> i disagree in this case. we don't want the user having to know to type "--" just to use functionality shipped with thr system
<wallyworld__> i made it a plugin to get it out of the main juju help topic
<rogpeppe1> wallyworld__: if we want to make it a plugin, i think it should be a normal plugin.
<wallyworld__> i disagree
<rogpeppe1> wallyworld__: if normal plugins are hard to use, that's another issue
<wallyworld__> it needs to be integrated better than that
<rogpeppe1> wallyworld__: if we want it to be integrated, it should not be a plugin
<rogpeppe1> wallyworld__: this seems to me to be the worst of both worlds
<wallyworld__> well, it was integrated
<rogpeppe1> wallyworld__: i know, and we decided to make it a plugin
<wallyworld__> but then you guys wanted it a little more separated
<rogpeppe1> wallyworld__: so i think it should be just that. no special casing.
<wallyworld__> yes, to uncluter juju help commands
<wallyworld__> but i do not want to make it hard for the user
<rogpeppe1> wallyworld__: this just makes a *third* category of juju subcommand
<wallyworld__> users are not unix geeks
<rogpeppe1> wallyworld__: which actually makes it harder for the user, IMO
<rogpeppe1> wallyworld__: because they don't know what's going to happen (for example) to the -e flag
<wallyworld__> they do
<wallyworld__> -e behaves as expected
<wallyworld__> it selects an env to use
<rogpeppe1> wallyworld__: it doesn't for metadata generate-image
<wallyworld__> i'd have to check that command, i can't recall if it needs an env or not
<rogpeppe1> wallyworld__: it takes a -e flag that is *not* an environment
<wallyworld__> so that should change perhaps. should -e e reserved across all commands to only mean env?
<wallyworld__> be
<rogpeppe1> wallyworld__: it is reserved in that way for all normal commands (and normal plugins too, i think)
<rogpeppe1> wallyworld__: except when -- is used
<wallyworld__> ok. i'll change that arg name then
<wallyworld__> rogpeppe1: actually, that was supposed to be -u for that one
<rogpeppe1> wallyworld__: i'd be much happier if all the "built-in plugin" stuff was removed too. it's almost self contradictory, and very odd, i think.
<wallyworld__> why? i disagree
<rogpeppe1> wallyworld__: a plug-in is by definition not built-in, i think.
<wallyworld__> what? photoshop and other things ship with built in plug ins
<wallyworld__> lots of software does
<wallyworld__> the plugin mechanism is a framework
<wallyworld__> software can ship with built in tools that use the framework. and allow for external extension
<rogpeppe1> wallyworld__: it seems like we're giving this particular plug-in special privileges because it's awkward to use as a normal plug-in.  don't you think that other people providing plug-ins might have similar requirements? but they won't be able to switch on the "built-in" flag.
<rogpeppe1> wallyworld__: perhaps we should make all plugins parse all their own flags, including -e
<wallyworld__> with externally written plugins, my mental model is that they are bolted on type thing. hence one has slightly different expectations
<rogpeppe1> wallyworld__: how can the user possibly know which things are externally written and which are not?
<wallyworld__> the plugins do parse their own flags i think, even the built in ones
<rogpeppe1> wallyworld__: i don't think they should have to know
<rogpeppe1> wallyworld__: i think the standard flags are parsed before passing to the plugin
<rogpeppe1> wallyworld__: and that's why allowIntersperse is true
<rogpeppe1> wallyworld__: i agree that it's not a great user experience, because they need to know that -e is parsed by juju proper, and the other flags are parsed by the plugin itself
<wallyworld__> so the user types "juju help metadata validate-image" and they get told hoe to use the command. they don't really need to know it's a plugin
<rogpeppe1> wallyworld__: and hence require a "--" separator
<rogpeppe1> wallyworld__: the juju only *knows* about the metadata command because they typed "juju help plugins"
<wallyworld__> yes, that's how you wanted it!
<wallyworld__> otherwise i wouldn't have bothered with the work to make it a plugin
<rogpeppe1> wallyworld__: i defer to fwereade_
<wallyworld__> sorry. discussions on irc suck
<rogpeppe1> wallyworld__: personally, i was ok with it being either a fully fledged plugin, or a fully builtin (set of) command(s).
<rogpeppe1> wallyworld__: but this half-way house seems bad to me
<rogpeppe1> wallyworld__: it's like "it's a plugin but it's not really"
<wallyworld__> the only difference i think is the use of "--" or not
<rogpeppe1> wallyworld__: yes. and without that difference, would you actually *need* the concept of built-in plugins?
<fwereade_> wallyworld__, I suspect rogpeppe1 has a point here, but I'll have to look closer
<wallyworld__> as a user, i would HATE to type "--" just to validate some image metdata
<rogpeppe1> wallyworld__: then as a user you'll hate to use any juju plugin
<rogpeppe1> wallyworld__: which means that our plugin concept is broken
<wallyworld__> maybe. but external ones give different expectations
<wallyworld__> built in ones need to be more integrated
<rogpeppe1> wallyworld__: so let's fix that rather than providing a special-case hack because we don't like the way they work
<wallyworld__> since they ship with the system
<rogpeppe1> wallyworld__: i think all plugins should work well
<axw> good night all
<rogpeppe1> axw: cheerio
<rogpeppe1> wallyworld__: and if we can't make the ones that ship with the system work well without special-case hacks, then we're doing something wrong
<wallyworld__> why did we force people to use "--" in the first place? was that a limitation of the gnu flags package?
<rogpeppe1> wallyworld__: i agree with your motivation, BTW. i think it's nasty that the user has to add a "--" to pass flags to a plugin
<rogpeppe1> wallyworld__: in a way, yes
<rogpeppe1> wallyworld__: but actually it's a fundamental limitation of the gnu flag syntax
<rogpeppe1> wallyworld__: you can't parse flags without knowing what flags are expected
<rogpeppe1> wallyworld__: so what we'd like to do is parse *only* the standard flags and leave the rest for parsing by the plugin
<wallyworld__> sounds reasonable
<rogpeppe1> wallyworld__: but that's impossible in general
<wallyworld__> so if we are going to fix the "--" i'd really like to land this as is and follow up separately
<wallyworld__> we know if we are processing a "missing command". can't we be less strict on the flags processing in that case
<rogpeppe1> wallyworld__: i'd much prefer this to land with the command as a normal plugin, without the special-case built-in stuff. it makes the CL more huge than it needs to be
<wallyworld__> and just pass what we don;t know about through
<rogpeppe1> wallyworld__: that's what i was saying - that's actually impossible
<wallyworld__> i don't want to impose the "--" on our users
<wallyworld__> built in means we get to do a better job of integrating
<rogpeppe1> wallyworld__: if "better job of integrating" means "we don't need to pass --", and we're planning to fix that, then i don't see the point
<wallyworld__> like car accessories or whatever. stuff that comes with the vehicle out of the factory is alsways better than going to the auto shop and bolting on later
<rogpeppe1> wallyworld__: let's not design it like that, please
<wallyworld__> this is about getting much needed functionality into user's hands with the desired interface
<wallyworld__> the built in handling is behind the scenes and can be fixed later for any existing plugins
<wallyworld__> to remove the "--"
<rogpeppe1> wallyworld__: the functionality is much more important than the interface at this point
<wallyworld__> the ui is important too
<rogpeppe1> wallyworld__: and this is unnecessary cruft in our code base
<wallyworld__> i don't want to ship something only to change the interface latert
<wallyworld__> its a few lines to handle tie "--"
<wallyworld__> the bulk of the code is business logic
<wallyworld__> we need to deliver incrementally
<rogpeppe1> wallyworld__: speaking of delivering incrementally, that CL should really be split into about 3 or 4.
<rogpeppe1> wallyworld__: i appreciate that you want to deliver the result though
<wallyworld__> it was smallish but then it grew
<rogpeppe1> wallyworld__: but i'm sure you can deliver it and say "yes, the interface is currently provisional, but we're working on it"
<rogpeppe1> wallyworld__: yeah, i know the feeling very well
<wallyworld__> well, i'd like the interface not to be provisonal
<wallyworld__> i like not having the "--"
<rogpeppe1> i'd very much like not to put "temporary" hacks into the code base which may need to stay forever
<wallyworld__> i'd like to get this out there and then fix how existing external plugins work
<wallyworld__> sometimes we need to be pragmatic to be agile
<rogpeppe1> wallyworld__: how about fixing things by always passing "false" to flags.Parse ?
<wallyworld__> that will break external plugins
<rogpeppe1> wallyworld__: i think that might actually be a nicer solution actually
<rogpeppe1> wallyworld__: i don't think so
<rogpeppe1> wallyworld__: i don't think it will affect them at all
<wallyworld__> hmmm. i thought i tested it and it broke. tim seemed to think it would break stuff also. i can look again. i originally had it that way and tim had concerns
<rogpeppe1> wallyworld__: it just means that you won't be able to do "juju some-plugin -e my-env" unless the plugin actually implements the -e flag
<wallyworld__> perhaps what you say above was the issue. can't recall now
<rogpeppe1> wallyworld__: hmm, i'm not sure if "juju -e my-env some-plugin" will work actually
<wallyworld__> i'm not sure it would be wise to possibly break existing plugins
<rogpeppe1> wallyworld__: *are* there any existing plugins?
<wallyworld__> yes, because the guys in oakland were *really* keen for them, that's why plugins were written
<wallyworld__> mainly mark mimms and his group
<rogpeppe1> wallyworld__: i know they were keen for them, but have they actually written any yet?
<wallyworld__> i *think* so. i thought they wrote some while we were there
<wallyworld__> or re-purposed existing code as a plugin
<wallyworld__> rogpeppe1: let's finalise what we want to do with fwereade_after the standup maybe
<rogpeppe1> wallyworld__: sgtm
<wallyworld__> much easier than typing
 * wallyworld__ goes to open some more wine to prepare :-)
<rogpeppe1> wallyworld__: sorry for the bother
<wallyworld__> rogpeppe1: no problem. it's a necessary discussion. i'd love to get rid of the "--"
<wallyworld__> irc is so impersonal
<rogpeppe1> wallyworld__: BTW the fundamental difficulty with extracting the -e flags without disrupting the rest of the flags is that it can break command lines like: juju my-plugin --title $title
<rogpeppe1> wallyworld__: consider what happens if $title happens to be '-environment-'
<wallyworld__> wouldn't the flags know that -title requires a value
<wallyworld__> and hence -env- is the value
<wallyworld__> that goes with -title
<rogpeppe1> wallyworld__: no, because we're parsing them before my-plugin gets called
<wallyworld__> so maybe the flags that are typed after plugin are considered to belong to plugin are ignored by juju
<rogpeppe1> wallyworld__: that's the main (only?) advantage that plugins provide for you, other than that you can call them with "juju my-plugin"
<rogpeppe1> wallyworld__: i think that's a reasonable p.o.v.
<rogpeppe1> wallyworld__: but it means that there's not necessarily any standardisation on -e/--environment
<rogpeppe1> wallyworld__: it's what i was suggesting by passing allowIntersperse=false
<wallyworld__> so 'juju -e env -log debug my-plugin -t  $title'
<rogpeppe1> wallyworld__: yeah, i think allowing a -e flag to *any* juju command isn't a bad idea
<wallyworld__> well, -e would be for juju only i guess
<rogpeppe1> wallyworld__: currently plugins will work when called as "juju some-plugin -e my-env", same as other commands (and also currently, a plugin doesn't have to interpret the -e flag).
<rogpeppe1> wallyworld__: this would break that
<wallyworld__> hmmm. maybe we can live with that. not sure
<rogpeppe1> wallyworld__: i'm not sure that's that important. i think it actually simplies juju itself, at the expense of making plugins marginally harder to implement (you need to parse the -e flag)
<rogpeppe1> (rather than read the JUJU_ENV environment variable)
<wallyworld__> yeah. worth considering
<rogpeppe1> quick shell script question: easiest way to sort a Go traceback by goroutine id?
<mgz> rogpeppe1: I thought you were the one with all the fancy awk stuff for understanding go panics...
<rogpeppe1> mgz: not afair...
<rogpeppe1> mgz: though for tracebacks with hundreds of goroutines, i've been wondering about something to make them a bit more accessible
<mgz> indeed.
<rogpeppe1> mgz: something that would classify similar ones together, for example
<rogpeppe1> i thought that someone might have a two line piece of python magic :-)
<rogpeppe1> for the record: http://paste.ubuntu.com/5928595/
<TheMue> aaaaah, got it, tests are passing again *phew*
<dimitern> fwereade: https://codereview.appspot.com/12034043/
<fwereade_> dimitern, sorry, I haven't done that very well, I just had a couple of comments I forgot to send
<fwereade_> dimitern, I think rogpeppe1's comments generally made sense
<dimitern> fwereade: ok
<mgz> standup all
<dimitern> fwereade: will repropose with his suggestions after the standup
<fwereade_> dimitern, cool, cheers
<benji> gary_poster: nope; when I changed the source yesterday the web socket never would reconnect; I think I didn't do the self-signed cert acceptance dance right.
<benji> gggfddsfds; wrong chan
<rogpeppe1> fwereade_: when you have a moment, i wouldn't mind having that chat about EnsureAPIInfo
<fwereade_> rogpeppe1, one-on-one atm, then lunch I fear
<rogpeppe1> fwereade_: np
 * rogpeppe1 should have some lunch too
<rogpeppe1> fwereade_: i'm tempted to drop EnsureAPIInfo entirely
<rogpeppe1> fwereade_: anyone that needs to upgrade from 1.10 can upgrade to 1.12 first
<jcastro> hey guys
<jcastro> distro go this MP
<jcastro> https://code.launchpad.net/~tribaal/ubuntu/saucy/juju-core/add-bash-completion/+merge/177287
<jcastro> but they feel this should be upstream
<jcastro> anyone know how I can put this on your merge radar instead of distros?
<rogpeppe1> jcastro: interesting. i can't answer your question, but it makes me more convinced that "juju help commands" should print all commands, including plugins
<jcastro> so ... assign thumper
<jcastro> Is that what you meant? :)
<ahasenack> hm, I have my unit logs over on the unit full of these:
<ahasenack> error: --unit-name option expects "<service>/<n>" argument
<ahasenack> that's all it has
<ahasenack> any idea what command it was trying to run?
<ahasenack> aha
<ahasenack> exec /var/lib/juju/tools/unit-rabbitmq-server-0/jujud unit --data-dir /var/lib/juju --unit-name rabbitmq/server/0 --debug >> /var/log/juju/unit-rabbitmq-server-0.log 2>&1
<rogpeppe1> jcastro: quite possibly :-)
<rogpeppe1> ahasenack: can you reproduce the problem from scratch?
<ahasenack> rogpeppe1: I'm not sure, investigating still
<ahasenack> I don't see any obvious typos so far
<jtv> Any reviewers available for https://codereview.appspot.com/12103043 ?
<dimitern> jcastro: yeah, there are plugins as well
<ahasenack> guys, what do you think about an option to destroy-unit like this:
<ahasenack> juju destroy-unit foo/0 --terminate
<ahasenack> it would also terminate the machine
<ahasenack> or even for destroy-service too
<dimitern> ahasenack: you can try destroy-machine directly
<ahasenack> oh?
 * ahasenack checks that one out
<ahasenack> dimitern: doesn't work
<ahasenack> Machines that have assigned units, or are responsible for the environment, cannot be destroyed.
<ahasenack> dimitern: right now the sequence is
<ahasenack> dimitern: juju status, lookup machine id of the unit you are about to destroy
<ahasenack> dimitern: juju destroy-unit unit/0
<ahasenack> dimitern: wait a few seconds
<ahasenack> dimitern: juju terminate-machine <machiine-id-looked-up-earlier>
<dimitern> ahasenack: if you do terminate-machine you don't need to do destroy-unit before that i think
<ahasenack> dimitern: the help says it won't destroy the machine
<ahasenack> dimitern: and it's an alias to terminate-machine, which I can confirm doesn't do that. It stops if the machine still has a unit
<ahasenack> I mean, destroy-machine (what you said before) is an alias to terminate-machine, which is what I have been using
<dimitern> ahasenack: ah, you're right yes
<rogpeppe1> ahasenack: i think it should be possible to terminate any machine with destroy-machine, and it should do what's necessary to bring that about, but others (notably fwereade_) may have different opinions
<rogpeppe1> fwereade_: ping
<ahasenack> I would be happy with a --force option to destroy-machine, or --terminate option for destroy-unit
<ahasenack> more the latter
<ahasenack> just reading the --force docs would make me wonder if destroy-machine --force would also call destroy-unit, i.e., everything should happen in the right order
<mgz> the second doesn't really make sense in the multipl-units-per-machine case
<ahasenack> destroy-unit --terminate would mean 1) destroy-unit, run all the hooks that are needed; 2) terminate-machine
<ahasenack> ah, there is that now
<ahasenack> it could be so that --terminate would only terminate if the machine is vacant
<ahasenack> because this workflow I described is something I use a *lot*
<ahasenack> I destroy a unit or service, in preparation for a redeploy/add-unit, and I need the machine terminated, or else it will be used again as it was left
<mgz> well, and with containerisation, machine reuse will be... less undesirable
<ahasenack> what I'm doing now basically is looping over all machine ids and calling terminate, and letting juju decide if it can terminate the machine or not
<mgz> because destrying the unit can just blow away the container
<dpb1> ahasenack: I don't think machines are "recyled" anymore
<ahasenack> dpb1: still, the dangling machine builds up against my quota
<dpb1> ahasenack: yes, that is true
<rogpeppe1> mgz: wondering about your thoughts on this: i'm considering making a change that will mean we can't upgrade a juju environment from 1.10 to current, although you'll be able to upgrade via 1.12. do you think that's reasonable?
<rogpeppe1> mgz: basically, i'm trying to avoid one temporary hack spreading tentacles
<rogpeppe1> fwereade_: if you're around, i'm talking about the EnsureAPIInfo hack here
<mgz> personally, I don't care about upgrades at all, so maybe poke william :)
<mgz> I always blow all my stuff away and redeploy
<rogpeppe1> mgz: yeah, me too. but you might know of people that have stayed on 1.10 for whatever reason, peraps
<mgz> having random point in trunk borked is always fine I think, but by "current" do you also mean rolling forward to 1.14?
<rogpeppe1> mgz: yeah
<rogpeppe1> mgz: if you're running 1.10, you'd need to upgrade via 1.12
<mgz> that might be more of an issue, because we do probably need some kind of upgrade path for what we've shipped in raring to what we'll ship in saucy
<rogpeppe1> mgz: well, there *will* be an upgrade path
<rogpeppe1> mgz: just that it's via 1.12
<rogpeppe1> mgz: but i guess if people can't readily get access to that, then, yeah, it might be a problem
<rogpeppe1> mgz: darnit
<sidnei> hey folks, can i get some attention to https://bugs.launchpad.net/juju-core/+bug/1205112
<_mup_> Bug #1205112: panic while setting a config value <juju-core:Triaged> <https://launchpad.net/bugs/1205112>
<rogpeppe1> sidnei: i'd like to help, but i didn't see a description of how to reproduce the problem
<rogpeppe1> sidnei: i.e. have you got a way that i can reproduce it from scratch?
<rogpeppe1> sidnei: or, alternatively, can you reproduce it reliably on tip?
<rogpeppe1> sidnei: (in which case, i'd ask you to add a debug print in a particular place, which should help diagnose the problem)
<sidnei> rogpeppe1: i can look into that. im suspecting it may be charm specific even. i think it's reliably reproducible.
<rogpeppe1> sidnei: i took a look at the code and couldn't see how the crash is possible
<rogpeppe1> sidnei: thanks
<sidnei> rogpeppe1: i'm doing juju deploy --config, and only about half settings got set, and then trying to set any setting after that causes the panic. i think there might be some error during the deploy --config which is in the logs but i haven't looked there.
<rogpeppe1> sidnei: that's entirely possible
<rogpeppe1> sidnei: can you paste the config file, please?
<rogpeppe1> sidnei: i suspect that's the source of the problem
<sidnei> rogpeppe1: http://paste.ubuntu.com/5929199/
<sidnei> rogpeppe1: http://paste.ubuntu.com/5929208/ is the charms' config.yaml
<rogpeppe1> sidnei: u1-stream is the name of the service, presumably?
<sidnei> rogpeppe1: correct
<rogpeppe1> sidnei: is it significant that it's different from the service name in the bug report, or is that just a name change since then?
<sidnei> rogpeppe1: it's the same charm, different service name yes.
<sidnei> rogpeppe1: worth noting that the panic happens setting any config value, not just a specific one. my hunch is that there's something persisted from the --config that causes the comparison to blow up.
<rogpeppe1> sidnei: are you seeing this against juju tip?
<rogpeppe1> sidnei: (yes, that sounds very plausible)
<sidnei> rogpeppe1: tip-ish, revno 1544, i can update and try again.
<rogpeppe1> sidnei: no, it's ok. i'll just give you a debug statement to add, and perhaps you could try again?
<fwereade_> rogpeppe1, sidnei: gut suspicion: the dotted config names are treated specially by mongo, because santitizing our inputs? what's that?
<rogpeppe1> fwereade_: i think you might have a good point there
<sidnei> fwereade_: likely.
<fwereade_> rogpeppe1, sidnei: and they all get packed into $update foo.bar -> dict -> blam
<rogpeppe1> fwereade_: we just use the names directly
<sidnei> fwereade_: i've used dotted config names since pyjuju supported them, to map into the charm's service dotted names directly.
<rogpeppe1> fwereade_: yeah, and since there are several names for, say keystone, they'll be unmarshalled into a map perhaps
<fwereade_> rogpeppe1, man, that Settings type pisses me off in more ways than I can count at this point
<rogpeppe1> fwereade_: :-)
<rogpeppe1> fwereade_: this is another reason for having some charm name restrictions
<rogpeppe1> fwereade_: so at least we know the alphabet we're dealing with
<fwereade_> rogpeppe1, +100
<rogpeppe1> fwereade_: i suggest that for the time being, we can just sanitise settings names
<rogpeppe1> fwereade_: map . to... something
<fwereade_> rogpeppe1, yeah, mumble grumble compatibility grumble, but yeah
<rogpeppe1> fwereade_: we'll need to map back again too, of course
 * rogpeppe1 goes to read about mongo name syntax
<fwereade_> rogpeppe1, tbh all those keys should go in a subdict of the doc *anyway*, because one day someone is going to be baffled by the effect of trying to call a key txn-revno, or similar
<fwereade_> rogpeppe1, but yes also sanitised
<rogpeppe1> fwereade_: agreed
<rogpeppe1> fwereade_: looks like we need to sanitize (at least) : "$", "." and leading digits
<dimitern> rogpeppe1, fwereade: updated https://codereview.appspot.com/12034043
<fwereade_> rogpeppe1, ok, and now I come to think of it compatibility isn't an issue
<fwereade_> rogpeppe1, none of those will work anyway ;p
<rogpeppe1> fwereade_: indeed
<rogpeppe1> fwereade_: although we need to think carefully about our sanitisation
<dimitern> please take a look, i need to land this already - it's too huge to stay long, otherwise i'll run into some nasty conflicts
<fwereade_> dimitern, will do
<dimitern> cheers!
 * dimitern bbiab
<rogpeppe1> dimitern: reviewed
<rogpeppe1> fwereade_: chat about EnsureAPIInfo?
<fwereade_> rogpeppe1, sure, couple of mins, would you start one please?
<rogpeppe1> fwereade_: will do
<rogpeppe1> fwereade_: https://plus.google.com/hangouts/_/f497381ca4d154890227b3b35a85a985b894b471?authuser=1
<dimitern> rogpeppe1: thanks!
<fwereade_> dimitern, reviewed
<dimitern> fwereade: cheers
<jtv> Any reviewers in the house?  Looking for someone to take a look at https://codereview.appspot.com/12103043
<rogpeppe1> jtv: swap ya: https://codereview.appspot.com/12114043
<rogpeppe1> anyone else too - it's a trivial deletion-only CL
<dimitern> rogpeppe1: hey, you know initially I wanted to argue with some of your suggestions, but as I went all of them fit quite nicely :)
<rogpeppe1> dimitern:  :-)
<fwereade_> rogpeppe1, fwiw I think https://codereview.appspot.com/12097043/ is trivial; concur?
<fwereade_> rogpeppe1, State.pareTag
<rogpeppe1> fwereade_: yeah
<fwereade_> rogpeppe1, cheers
<rogpeppe1> fwereade_: oh, and i understand why you got weird linker errors too, i think
<fwereade_> rogpeppe1, o yes?
<rogpeppe1> fwereade_: it's because the tests fixtures themselves use State
<rogpeppe1> fwereade_: so, i think, external packages are linked against the non-test version of the code.
<fwereade_> rogpeppe1, hahaha, yes, that makes sense
<rogpeppe1> fwereade_: that's my current theory anyway - i haven't spent any time verifying it
<fwereade_> rogpeppe1, good enough for me, I resolved not to worry about it too much anyway ;)
<rogpeppe1> jtv: reviewed
<rogpeppe1> fwereade_: your review of https://codereview.appspot.com/12114043 appreciated too, please
<fwereade_> rogpeppe1, btw, https://codereview.appspot.com/11723043/
<rogpeppe1> fwereade_: ha, thanks, i'd totally forgotten about that
 * fwereade_ needs to be off, but will be back somewhat later to finish everybody's reviews
<sidnei> rogpeppe1: sorry, was out at lunch. was there any conclusion to what's the right fix?
<rogpeppe1> sidnei: your temporary workaround fix, i'm afraid, is to avoid using "." in attribute names
<rogpeppe1> sidnei: we need to sanitise the names used - the fix isn't hard, but we need to decide on an encoding scheme and actually do it
<rogpeppe1> sidnei: the issue, we're pretty certain, is because the names are used directly in mongo, which interprets the "." specially.
<dimitern> rogpeppe1: updated again; one last look before I submit it? https://codereview.appspot.com/12034043
<rogpeppe1> dimitern: looking
<sidnei> rogpeppe1: hum, tricky but workable. i'd rather help you guys with implementing the sanitization though.
<dimitern> rogpeppe1: btw had to merge trunk to resolve a conflict, but no other changes, despite the diff showing otherwise
<rogpeppe1> sidnei: you're welcome to propose a fix - the problem is in state/settings.go
<sidnei> rogpeppe1: just need a decision on the encoding scheme, and then i can work from there
<rogpeppe1> sidnei: well, it needs to be reversible, and it needs to translate at least ".", "$" and probably leading digits (although i think we can probably just do "." and define the latter two as disallowed
<rogpeppe1> )
<rogpeppe1> sidnei: "_"->"__"; "."->"_." ?
<rogpeppe1> sidnei: oh no, that's wrong
<sidnei> :)
<sidnei> what about we pick '.' -> ':', and disallow ':'
<rogpeppe1> sidnei: well, it depends if there are any current charms using "__" or "_." in attribute names
<rogpeppe1> sidnei: depends if : is allowed in mongo names
<rogpeppe1> sidnei: but that sounds like a good idea if it works
<rogpeppe1> sidnei: if you could do some investigation into that (and perhaps if any current charms define attributes with : in), that would be really useful
<sidnei> rogpeppe1: if i read this correctly, they suggest using the unicode full width character replacements: http://docs.mongodb.org/manual/faq/developers/#faq-dollar-sign-escaping
<rogpeppe1> sidnei: well found; i was looking for something like that
<rogpeppe1> sidnei: i kinda prefer : though
<sidnei> still need to escape the $ no?
<rogpeppe1> sidnei: i think i'd just disallow $
<sidnei> ok
<rogpeppe1> sidnei: although i'd like to do an audit of existing charms to check if anyone's using it
<rogpeppe1> sidnei: they might, of course, be using full-width $ and . :-)
<rogpeppe1> sidnei: i tell you what, let's just go with their suggestion.
<rogpeppe1> sidnei: it seems reasonable and it's easy to implement and quite intuitive
<sidnei> okidoki
<rogpeppe1> sidnei: if you want to make the change, you might want to know about http://golang.org/pkg/strings/#Replacer
<sidnei> was looking for that already :)
<sidnei> rogpeppe1: do you still want to reject '$' or just do the replacement?
<rogpeppe1> sidnei: let's just do the replacement for the time being - at least there's a high assurance of backward compatibility doing it that way
<rogpeppe1> sidnei: we can make charm config names more strict later
<sidnei> k
<dimitern> rogpeppe1: does it look ok?
<jtv> rogpeppe1: I see I'm too late to return the favour â not being very attentive late at night.  Hope I can make up another day!
<rogpeppe1> dimitern: sorry, just had to go away for a little bit. i've a few comments, one mo
<dimitern> rogpeppe1: sure, thanks
<rogpeppe1> dimitern: reviewed
<dimitern> rogpeppe1: cheers
 * rogpeppe1 has reached eod
<rogpeppe1> g'night all
<dimitern> rogpeppe1: night!
<ahasenack> guys, so I just deployed juju-core trunk on canonistack and then ran "juju deploy rabbitmq-server", straight from the store, no options
<ahasenack> got this in the rabbit's unit logs:
<ahasenack> error: --unit-name option expects "<service>/<n>" argument
<ahasenack> and look at the upstart job:
<ahasenack> exec /var/lib/juju/tools/unit-rabbitmq-server-0/jujud unit --data-dir /var/lib/juju --unit-name rabbitmq/server/0 --debug >> /var/log/juju/unit-rabbitmq-server-0.log 2>&1
<ahasenack> something mangled the rabbitmq-server/0 unit name to rabbitmq/server/0
<ahasenack> https://bugs.launchpad.net/juju-core/+bug/1206628 it is
<_mup_> Bug #1206628: Incorrect unit name in upstart job <juju-core:New> <https://launchpad.net/bugs/1206628>
<dimitern> ahasenack: that's indeed a bug, stemming from the tags-to-names conversion I think, replacing - with /, etc.
<ahasenack> dimitern: yeah, in state/api/deployer/unit.go there is such a conversion going on
<ahasenack> func UnitTag(unitName string) string {
<ahasenack>     return unitTagPrefix + strings.Replace(unitName, "/", "-", -1)
<dimitern> ahasenack: :) that's my doing actually, quite recent even
<ahasenack> I like living on the edge :)
<dimitern> ahasenack: i'll assign it to myself, thanks for the report
<ahasenack> dimitern: thanks for taking care of it :)
<dimitern> ahasenack: i will look into it tomorrow
<ahasenack> ok
 * dimitern reached eod as well
<dimitern> good night all!
<ahasenack> dimitern: g'night
<thumper> morning
<thumper> mgz: email update?
<thumper> mramm: hey
<mramm> hey
<davecheney> mramm: arosales i've got a call with one of y'all now, right ?
<arosales> davecheney, :-)
<mramm> I scheduled right after arosales
<arosales> davecheney, I think I have the privilege of being up first
<mramm> so it would be him
<davecheney> very well
<davecheney> fire at will
<davecheney> mramm: next please
<mramm> joining
<thumper> heh
<thumper> gym time
#juju-dev 2013-07-31
<bigjools> thumper: I've been enjoying watching my machines power themselves on and off
<sidnei> thumper: https://codereview.appspot.com/12136043
 * sidnei goes fetch dinner
<sidnei> or davecheney ^
<bigjools> davecheney: did you guys get your sprint sorted out yet? travel/hotel etc?
<davecheney> bigjools: no, i have not heard anything
<bigjools> marvellous
<davecheney> bigjools: mramm said that he had talked about it with robbie and it was approved
<davecheney> it sounded like he was in charge of arranging it
<davecheney> so, when I said 'not heard anything', i think i meant to say 'not heard anything actionable'
<bigjools> ok Dan is going to push it
<mramm> davecheney: bigjools: I don't need to be the one that submits the paperwork
<mramm> bigjools: I talked to dan today, and we agreed that it needed to happen
<mramm> but there was a bit of a loop thrown in the works today, which I think is now resolved, and we will get the ball rolling in the morning
<mramm> just talked to danwest, expect an update tomorrow on the sprint
<bigjools> roger
 * thumper has maas working properly
<thumper> just confirming
<thumper> but with no intervention from me
<thumper> we have addressable containers in maas
 * thumper hopes
<bigjools> thumper: \o/
<thumper> bigjools: well, the bootstrap now has the right bridge
<thumper> just hoping that the lxc container that I'm bringing up has the right setup
<thumper> it is looking hopeful
<thumper> now if we can just get that address into state
<thumper> ok, that worked
<bigjools> thumper: it just powered off
<thumper> bigjools: yep, just dstoryed the env
<thumper> yay maas
 * thumper wants one
<bigjools> woo
 * thumper submits second branch
<bigjools> if I had more boxes I'd deploy my personal stuff with it
<bigjools> thumper: is there any hook in bootstrap that runs only once before tools get uploaded?
<bigjools> azure provider needs to set up storage
<thumper> tools are uploaded by the bootstrap command
<thumper> so, no, not yet
<thumper> feel free to add one
<bigjools> arseburgers
<bigjools> thumper: when not uploading tools, is storage required before Bootstrap is called?
<thumper> bigjools: um... not before bootstrap
<thumper> at the start of bootstrap there is a check in storage for the file
<thumper> to see if already bootstrapped
<bigjools> thumper: can you point me to the code please?
<thumper> bigjools: -> lp:juju-core
<thumper> :P
 * thumper looks
 * bigjools revokes thumpers ssh access
<thumper> environs/bootstrap.go  VerifyBootstrapInit
<thumper> axw, davecheney: I really want to change the meaning of --verbose for commands
<thumper> with the equivalent --quiet
<thumper> to have nothing to do with actual logging
<thumper> but instead to refer to the amount of info output by the command
<axw> thumper: yeah, that would be the normal thing to do :)
<thumper> axw: I have a branch in progress that tweaks how logging is configured
<bigjools> thumper: ta
<axw> thumper: ah cool. should I just abandon my change then?
<thumper> axw: no
<thumper> they complement each other mostly
<thumper> may clash on one or two small areas
<thumper> but don't land your change until we've looked at both
<thumper> and discussed a better --verbose
<axw> sounds good
<thumper> mine is to store logging config in state
<thumper> and use 'juju set-environment' to dynamically change logging confg on the fly
<thumper> it is mostly done, but I've moved back to maas to make a groovey demo for next week
<bigjools> +1
<axw> ah that sounds nice
<thumper> trying to get containers working with maas
<axw> so then you can get jujud to change on the fly?
<axw> nps
<thumper> so we can demo HA openstack into < lots of machines
<thumper> axw: there is already an environment watcher that watches for config changes
<thumper> so using set-environment to update state
<thumper> all the agents can be notified
<thumper> they then reconfigure the logging based on that change
<thumper> pretty easy really
<thumper> all the bits are in place already
<thumper> just took one change to loggo
<thumper> so the validation of the config string can be done independently of the actual changing
<thumper> axw: please don't make any -v/-q changes to the logging branch
<thumper> I want to change their meaning
 * thumper needs to find a nice recipe for dinner - moroccan lamb or chicken
<thumper> have preserved lemons to use
<axw> oops, juju consumed all my memory, twice. buggered something up...
<thumper> haha, oops
<thumper> fwereade: yes, I'll look again at wallyworld_'s merge shortly
<sidnei> thumper: around?
<thumper> aye
<thumper> although about to go to the school to collect minions
<thumper> bbs
<sidnei> looking at sniffing the apt mirror configured in the host and putting apt_mirror into cloud-init for the container
<sidnei> as in $apt-config shell apt_mirror Acquire::http::Proxy
<sidnei> apt_mirror='http://10.0.3.1:3142'
<thumper> hmm...
<thumper> interesting
<sidnei> actually that should be apt_proxy not apt_mirror
<sidnei> but i remember there was an issue with https proxying, for which hazmat added Acquire::https::Proxy "false"; in pyjuju iirc
<thumper> I know less about apt caching and mirroring than I do about networking
<thumper> and that is saying something
<sidnei> thumper: so, would shelling out to apt-config in environs/cloudinit.go:Configure be the right place for this?
<thumper> sidnei: probably better to have it isolated inside the local provider
<thumper> sidnei: unless you think we should be looking for all containers
<thumper> in which case, perhaps containers/lxc would be a better place
<sidnei> thumper: around cloudinitUserData?
<thumper> something like that
<thumper> wallyworld_: you around?
<wallyworld_> yep
<thumper> wallyworld_: two branches up to give us addressable maas containers
<thumper> https://codereview.appspot.com/12005049
<thumper> and the one it depends on
<wallyworld_> cool, will look
<sidnei> thumper: in other news, the ubuntu-cloud lxc template sets up mirror properly if you don't provide a cloud-init config, but we unfortunately do. :(
<sidnei> (IFF you set up a mirror in /etc/default/lxc that is)
<thumper> wallyworld_: https://codereview.appspot.com/12005048/
<thumper> haha
<thumper> sidnei: which means it should be relatively easy to match, right?
<sidnei> thumper: more or less. it sources /etc/default/lxc
<sidnei> i guess we could do the same
<thumper> wallyworld_: got a few minutes for a hangout?
<thumper> wallyworld_: to talk through the simplestream changes?
<wallyworld_> ok, just give me a sec to complete some wor
<wallyworld_> k
<thumper> kk
 * thumper back in a minute
<wallyworld_> thumper: i can talk now
<thumper> kk
<thumper> boo
<thumper> for the first time in ages bzr is giving me trouble
<thumper> wallyworld_: hangout
<wallyworld_> sure
<thumper> wallyworld_: start one?
<wallyworld_> i'll start
<wallyworld_> https://plus.google.com/hangouts/_/d3f48db1cccf0d24b0573a02f3a46f709af109a6
<wallyworld_> thumper: ?
<thumper> sorry
<thumper> need the ping
<sidnei> thumper: https://codereview.appspot.com/12143043 wip, missing tests. will finish tomorrow.
<sidnei> 30s for add-machine now. yay.
<thumper> davecheney: any chance of a +1 ? https://codereview.appspot.com/12005048/
<thumper> jtv: or you?
<jtv> thumper: otp
<thumper> jtv: I've started using "make" and "make check"
<jtv> \o/
<thumper> jtv: wanna review something now?
<jtv> thumper: still otp
<thumper> :-|
 * thumper goes to do dinner
<thumper> and hopes for some reviews
<thumper> ciao
<rogpeppe> mornin' all
<axw> morning
<TheMue> morning
<TheMue> just watching http://vimeo.com/71278954, really good
<axw> note to self: don't try to run race detector on shitty laptop again
<TheMue> axw: *lol*
<axw> I wish Lenovo would just come out with their 4th gens already
<rogpeppe> fwereade: what's the decision about whether we can use go1.1 features yet?
<dimitern> man my laptop died on me again :( again issues with unity/compiz/amd video drivers
<axw> night folks
<allenap> Hi, can anyone see why https://code.launchpad.net/~allenap/juju-core/azure-open-machine-ports/+merge/177717 isn't landing? There are two LGTMs...
<allenap> Ah! Maybe it's the commit message. lbox doesn't set that, sigh.
<rvba> allenap: there is a commit message
<allenap> rvba: I just added it.
<rvba> ah ok :)
<mgz> allenap: read the message about how to land. :) anyway, commit message now set, and bot is running the tests
<allenap> mgz: I must have missed that :)
<rogpeppe> fwereade: ping
<fwereade> rogpeppe, pong
<rogpeppe> fwereade: have you got your suggested AgentEntity (or whatever name) interface changes done yet?
<rogpeppe> fwereade: i was about to go in that direction after thinking through it a bit
<fwereade> rogpeppe, largely,but not really proposable yet
<fwereade> rogpeppe, sweet!
<fwereade> rogpeppe, I'd be more than happy to step up the pace there though
<rogpeppe> fwereade: i still think that state.Agent isn't the right name (we've got too many things called "agent" already)
<fwereade> rogpeppe, sure, I don't think it's really a great name
<rogpeppe> fwereade: EntityThatCanHaveAnAgent :-)
<fwereade> rogpeppe, but so much of unit/machine is deeply bound up with agentness that I think it's really quite a useful thing
<fwereade> rogpeppe, EnsureDead/Remove forexample
<rogpeppe> fwereade: yeah
<rogpeppe> fwereade: and it makes it easier to define an IsAgent authorizer method that's not just !IsClient
<rogpeppe> fwereade: which is what i'm doing currently and doesn't seem quite right
<fwereade> rogpeppe, I'dbeen just explicitly doing IsUnitAgent() || IsMachineAgent()
<rogpeppe> fwereade: ah, well that might be as good actually
<rogpeppe> fwereade: i'll propose a small change that just adds the interface, if that seems ok
<rogpeppe> fwereade: then we can both move forward building on that
<fwereade> rogpeppe, ok, sgtm
<dimitern> fwereade, rogpeppe: standup?
<dimitern> mgz: ^^
<mgz> ta
<bigjools> rogpeppe: howdy
<bigjools> just wondering, why should opening a new environ not have side effects?
<dimitern> *facepalm* my testing juju environment on ec2 was running for 9 days straight! I forgot to destroy it.. bugger $18 wasted
<TheMue> dimitern: ouch
<sidnei> rogpeppe: thanks for the review! i thought about unescaping in cleanSettingsMap but it meant changing some tests. i guess i'll do it anyway.
<sidnei> rogpeppe: re: changing copyMap to take a replacer, how can i make it so that the replacer is optional? this seems to be not encouraged by go
<rogpeppe> sidnei: i'd suggest changing it to take func(string)string
<rogpeppe> sidnei: then you can pass func(s string)string{return s} to do nothing
<rogpeppe> sidnei: well, for the identity transformation anyway
<sidnei> rogpeppe: does that mean changing all the call sites where copyMap is used?
<rogpeppe> sidnei: yeah. there are only 6 of them.
<sidnei> rogpeppe: oh, duh. didn't realize it was internal, should've known better. :)
<rogpeppe> sidnei: you could always make nil mean identity if there are lots of calls like thatr
<rogpeppe> sidnei: lower case :-)
<sidnei> indeed!
 * sidnei puts his golang newbie hat on
<rogpeppe> sidnei: the most important thing to fix is that bug in megawatcher.go - i think that will currently wrongly produce keys with escaped dots
<sidnei> rogpeppe: ack, working on it.
<mgz> okay, I actually undertand some of this watcher stuff now... has only taken a week
<fwereade> hey, can anyone give me a second review of https://codereview.appspot.com/12105043/ please?
<mgz> fwereade: the resoning being that panic isn't approprite, because we could just junk instate?
<fwereade> mgz, the panic is now definitely inappropriate because it could happen on the api server
<fwereade> mgz, it didn't seem sensible to clone the validity checks across api and state though
<mgz> fwereade: lgtm
<fwereade> mgz, cheers
<rogpeppe> fwereade: you've got another review
<rogpeppe> fwereade: what's the motivation behind the interactive destroy-environment CL?
<fwereade> rogpeppe, long-existing bug?
<rogpeppe> fwereade: ah, there wasn't a bug referenced in the CL
<fwereade> rogpeppe, trivial embarrassing parity issue
<rogpeppe> fwereade: ah, the python implementation is interactive?
<fwereade> rogpeppe, yeah
<rogpeppe> fwereade: blech
<mgz> adding --no-really flags to dangerosu commands isn't too bad
<fwereade> rogpeppe, I'm inclined to call it validateSet and keep the set-specific terminology
<rogpeppe> mgz: "destroy-environment" is a long enough name as it is
<mgz> but if you care about non-interactiveness (ie, in a script), typing length isn't too important
<rogpeppe> mgz: if you've typed all of that, you don't really need another hoop to jump through. but i appreciate some feel that more nannying is appropriate.
<rogpeppe> mgz: if i'm calling destroy-environment in a script, i probably don't want things to suddenly turn interactive on me. anyway, if python juju does it, we can't avoid it.
<mgz> it's not that hard to braino destroy-machine etc into destro-environment
 * rogpeppe wonders what happened to the original unix approach
<mgz> men are no longer real men, grey beards are no longer real grey beards
<rogpeppe> mgz: people still happily use rm though
<rogpeppe> ha! i'd forgotten, many people alias it to rm -i.
<mgz> which requires flags to not nag you if you want to remove a tree rather than just one file
<rogpeppe> mgz: extra flags, fine. sudden interactiveness, not so fine. in my entirely biased and subjective opinion :-)
<mgz> well, we could make destroy-environment do *nothing* unles you pass --no-really :)
<rogpeppe> mgz: i'd prefer that to reading stdin, which seems similar but worse
<sidnei> rogpeppe: im having a hard time adding something to allWatcherChangedTests that triggers the megawatcher bug. halp?
 * rogpeppe has a look
<rogpeppe> sidnei: i *think* you'll see the issue if you have a set with a setUp function that creates some settings with a dot in a settings name
<sidnei> rogpeppe: this is my attempt so far: http://paste.ubuntu.com/5932838/
<sidnei> with dottedConfig being a config.yaml with 'key.dotted' as a setting
<rogpeppe> sidnei: and that passes?
<sidnei> rogpeppe: it does yes
<rogpeppe> sidnei: hmm, perhaps you could push your branch and i'll have a quick look
<rogpeppe> sidnei: i can't quite see how it can be passing, but i might well be missing something stupid
<sidnei> rogpeppe: lp:~sidnei/juju-core/encode-dollar-and-dot-2
<rogpeppe> sidnei: oh hold on
<rogpeppe> sidnei: i think i see the problem
<rogpeppe> sidnei: try this instead
<rogpeppe> sidnei: do a global substitute of "blog-title" by "blog.title" and see if tests still pass
<rogpeppe> sidnei: in megawatcher_internal_test.go
<sidnei> rogpeppe: i'd need to change the on-disk charm, it complains blog.title is not valid otherwise, thus the AddCustomCharm
<rogpeppe> sidnei: i don't think your test is quite tickling the place where the bug is
<sidnei> yeah, i have the same suspicion. more suspicious perhaps is that if i remove the Config from 'add', the test fails because Config is nil, i'd expect it to be set from setServiceConfigAttr(c, svc, "key.dotted", "boring") in setUp
<sidnei> uhm i think the watcher.Change should be "settings" not "services" to trigger it
<dimitern>  rogpeppe, fwereade: https://codereview.appspot.com/12165043 - fixes lp:1206628
<dimitern> bug 1206628
<_mup_> Bug #1206628: Incorrect unit name in upstart job <juju-core:In Progress by dimitern> <https://launchpad.net/bugs/1206628>
<rogpeppe> sidnei: yes, an excellent point
<dimitern> _mup_ should respond to "lp:#" as well as to "bug #"
<rogpeppe> sidnei: i triggered the bug by changing blog-title to blog.title (and in the charm)
<rogpeppe> sidnei: so it is at least confirmed as a bug :-)
<sidnei> rogpeppe: cool. i think i'm on track again
<rogpeppe> sidnei: great, thanks
<rogpeppe> sidnei: i'm glad you took the time to make sure the test fails before adding the fix
<sidnei> rogpeppe: my time in the landscape team with niemeyer surely paid off :)
<rogpeppe> sidnei: yeah, that's where i got it from too
<fwereade> dimitern, LGTM, just trivials
<dimitern> fwereade: cheers; I'll change the other c.Logf() to use "test %d. %q" as well
<fwereade> dimitern, I find ":" cleaner than ".", I think
<dimitern> fwereade: ah, ok, np
<fwereade> dimitern, "0." makes me think someone's trying to save typing while defining floating point numbers ;p
<dimitern> :)
<dimitern> fwereade: wasn't thinking much how to format it, but i'll do that from now on
<fwereade> dimitern, cheers
<sidnei> im still amazed that go fmt doesn't format anything that i touch. emacs' golang mode is freaking awesome.
<rogpeppe> dimitern: reviewed
<sidnei> rogpeppe: https://codereview.appspot.com/12168043
<dimitern> sidnei: it definitely is! unfortunatelly I couldn't make emacs recognize my $GOPATH, etc. stuff, so in order for gofmt and godef to work in emacs I have to launch it from a terminal, not the launcher
<dimitern> rogpeppe: thanks
<dimitern> rogpeppe: what's wrong with testUnitTag := func () { names.UnitTag(..) } ?
<dimitern> rogpeppe: we don't need or use the return value
<rogpeppe> dimitern: oh, nothing at all. ignore me!
<dimitern> rogpeppe: :) ok
 * sidnei lunches
 * dimitern sighs
<dimitern> from all things that can go wrong today, most have
<dimitern> ok, all merged and tested to be ok
<sidnei> can has a pair of reviews on: https://codereview.appspot.com/12168043/ ?
<dimitern> sidnei: looking
<rogpeppe> fwereade, dimitern: https://codereview.appspot.com/12175043/
<dimitern> sidnei: reviewed
<dimitern> rogpeppe: looking
<sidnei> thanks!
<dimitern> rogpeppe: done
<rogpeppe> "
<rogpeppe> I'm not sure this is a good idea. Why panic when we can have a
<rogpeppe> compile-time error, when trying to use an unimplemented method?
<rogpeppe> "
<rogpeppe> dimitern: because we need to implement all those methods
<rogpeppe> dimitern: and the alternative is writing them all out in full, each one with its own panic message
<dimitern> rogpeppe: and why will they panic if we omit them?
<rogpeppe> dimitern: it won't compile if we omit them
<sidnei> rogpeppe: copyMap and replaceKeys ended up being very similar, except copyMap makes a copy and replaceKeys doesn't. suggestions?
<dimitern> sidnei: implement copyMap as y := replaceKeys(...), return y (the copy) or something?
<rogpeppe> sidnei: if there are good reasons we don't want to copy the map in some places, i think it's ok that they're different functions.
<rogpeppe> dimitern: but they should look as similar as possible - perhaps they should both take func(string)string as an argument
<sidnei> rogpeppe: yes, i made them both take func(string)string
<dimitern> rogpeppe: i wasn't asking that - I didn't get the part in the comment how any call in AgentEntity will panic "automatically" if we try to use it
<rogpeppe> dimitern: because we're embedding the AgentEntity value which is a nil interface
<sidnei> rogpeppe: i can't think of a good reason not to copy the map except needless copy
<dimitern> rogpeppe: if one of them replaces and makes a copy before returning, why not make the former call the latter
<dimitern> rogpeppe: ah, nice! didn't spot that
<rogpeppe> dimitern: because it's somewhat more efficient
<dimitern> rogpeppe: cool, I like it
<rogpeppe> dimitern: it's a nice little idiom, isn't it?
<dimitern> rogpeppe: indeed
<rogpeppe> sidnei: it can be worth avoiding needless copying
<rogpeppe> sidnei: especially if the penalty is only 2 or 3 lines of code in one place
<dimitern> rogpeppe: I upgraded my review to LGTM+ then
<rogpeppe> dimitern: thanks
<pavelpachkovskij> I have a weird bug, you can't define interface: juju-info in your metadata.yml when deploy from local repo
<dimitern> pavelpachkovskij: any relation starting with "juju-" is reserved
<pavelpachkovskij> dimitern, I see, then it's a "bug" in charm which provide this interface
<dimitern> pavelpachkovskij: some charms use it (even though it's wrong) to provide features like "relatable to any other charm"
<pavelpachkovskij> but this way I can't implement any relation hook in my charm
<dimitern> pavelpachkovskij: can you explain a bit what are trying to do?
<pavelpachkovskij> for example, there is a logstash-agent charm in the store
<pavelpachkovskij> I want to have a hook in my charm which triggers when logstash-agent joins
<dimitern> pavelpachkovskij: just a moment, to look at it, 'cause i'm not particularly familiar with that one
<dimitern> pavelpachkovskij: ha, so you see this charm is a subordinate
<dimitern> pavelpachkovskij: it does not provide anything you can require
<dimitern> pavelpachkovskij: it requires "juju-info", so it can detect any other service that can relate to it, so it can set up some type of subordinate logging of it
<pavelpachkovskij> dimitern, it's not a big issue to me at the moment, though I thought someone may want to implement such hook
<dimitern> pavelpachkovskij: well, there are 3 types of charm relations: providers, requirers and peers
<dimitern> pavel: well, there are 3 types of charm relations: providers, requirers and peers
<pavel> that's clear, but to be able to execute relation hooks you have to define this relation in metadata.yml
<dimitern> pavel: you can sit at one endpoint of each, or at the opposite endpoint, so that R->P or P->R, or Peer<->Peer
<pavel> otherwise they are not triggered
<dimitern> pavel: what i'm trying to say is, logstash-agent is only a client, you can relate it to any service
<dimitern> pavel: and the service you're relating it to won't get a hook executed, because it's "serving" to logstash-agent
<pavel> dimitern, yes, that's clear too, but i can't implement logstash-agent-joined hook
<dimitern> pavel: why do you need to do that?
<pavel> dimitern, this is not the question, the question is that I can't do this
<dimitern> pavel: not with juju-info, no
<pavel> ok
<dimitern> pavel: if the charm provides some other interface, you can use it
<pavel> dimitern, so you want to say that it was supposed to work this way?
<dimitern> if you want, think of "juju-info" as a system, one-way channel that you can read from, but not write back
<pavel> dimitern, ok, thanks for explanation
<dimitern> juju-info is not really an interface, it's like a broadcast call
<dimitern> "give me everything that happens"
<dimitern> so it's not an endpoint you can connect, but more like a multicast
<dimitern> pavel: no worries, i hope my description made some sense - there are good (and getting better) docs in lp:juju-core/doc/ in the source and also here https://juju.ubuntu.com/docs/
<rogpeppe> if anyone has a moment, i need another review on this, please: https://codereview.appspot.com/12175043
<dimitern> some of them slightly outdated, but don't hesitate to ask here for help, somebody will be around to answer
<dimitern> rogpeppe: :) I can give you a second LGTM
<rogpeppe> dimitern: hey, that would be cool. unfortunately i don't think LGTM+LGTM=2 * LGTM
<dimitern> rogpeppe: yeah
<dimitern> rogpeppe: btw can you read the scrollback and see if my explanation about juju-info made sense? i'm never so sure with charms stuff
<rogpeppe> dimitern: looking
<rogpeppe> dimitern: while i check it's right, here's another CL for you: https://codereview.appspot.com/12183043/
<rogpeppe> dimitern: it actually integrates the upgrader
<rogpeppe> dimitern: just waiting on a live test now
<dimitern> rogpeppe: cool! looking
<rogpeppe> dimitern: http://paste.ubuntu.com/5933446/
<rogpeppe> dimitern: yay!
<sidnei> rogpeppe: i'll keep the duplication then, thanks!
<dimitern> rogpeppe: \o/
<dimitern> andreas__: hey
<andreas__> dimitern: hey
<andreas__> ahasenack: go away
<dimitern> andreas__: you'd be thrilled to know your bug 1206628 from yesterday is resolved :)
<_mup_> Bug #1206628: Incorrect unit name in upstart job <juju-core:Fix Committed by dimitern> <https://launchpad.net/bugs/1206628>
<rogpeppe> dimitern: your juju-info explanation sounds reasonable
<dimitern> rogpeppe: thanks!
<jcastro> hey who changed the constraints from "cpu" to "cpu-cores"? and when?
<dimitern> rogpeppe: lgtm
<dimitern> jcastro: some months ago, after a discussion
<rogpeppe> dimitern: EnsureWeHaveLXC has gone because it's a 1.10 compatibility hack, and removed as part of https://code.launchpad.net/~rogpeppe/juju-core/355-remove-1.10-hacks/+merge/177638
<dimitern> jcastro: it was due to inconsistent support across providers - ec2, openstack, maas
<dimitern> rogpeppe: ah, nice!
<jcastro> yeah so
<jcastro> no one bothered to update the docs!
<jcastro> Doing so now
<jcastro> can we make it so if people change end-user behavior that they update the docs?
<dimitern> rogpeppe: then please live test upgrade 1.10 -> last stable and tip
<rogpeppe> dimitern: will do
<dimitern> jcastro: that'll be awesome, but afaik the docs were pretty much in a state of flux until recently
<jcastro> do constraints still support instance-type?
<dimitern> jcastro: no
<jcastro> dimitern: yeah, I think we should just say docs are ready, please update as you land things
<dimitern> jcastro: they never did in juju-core
<jcastro> ok
<jcastro> https://juju.ubuntu.com/docs/charms-constraints.html
<jcastro> do I fixed the CPU type bits
<jcastro> do I just totally cut out instance-types?
<dimitern> jcastro: which docs should be updated and where?
<jcastro> the branch is lp:juju-core/docs
<jcastro> they're just html5
<jcastro> committing to that branch regenerates the docs every 24 hours
<rogpeppe> dimitern: i'm hoping that it's ok to require people that use the local provider to apt-get install lxc themselves
<dimitern> jcastro: i think so, but maybe it's better to pass a mail through the list
<jcastro> I am doing so now!
<dimitern> rogpeppe: if so, there should be at least a warning when it's not there
<rogpeppe> dimitern: yeah, i'm not sure what happens
<rogpeppe> dimitern: any idea where i can get a copy of 1.10 from?
<dimitern> rogpeppe: ppa?
<rogpeppe> dimitern: doesn't that just give you the latest version?
<dimitern> rogpeppe: https://launchpad.net/ubuntu/+source/juju-core
<dimitern> rogpeppe: there's a 1.10 in raring backports there
<dimitern> rogpeppe: or alternatively, track the version change commit and revert to that?
<rogpeppe> dimitern: not so easy with all those dependency changes
<rogpeppe> dimitern: sadly
<rogpeppe> dimitern: that's what i wanted to do first
<dimitern> rogpeppe: yep
<dimitern> rogpeppe: we are in dire need of requirements tracking
<rogpeppe> dimitern: yeah
<rogpeppe> dimitern: hmm, i'm surprised it doesn't mention 1.12 here https://launchpad.net/ubuntu/+source/juju-core
<dimitern> rogpeppe: I'm not convinced we did 1.12 at all, maybe it was discussed by not done
<rogpeppe> dimitern: davecheney sent an email that seemed to imply it was done
<sidnei> rogpeppe, dimitern: updated, one last review?
<rogpeppe> sidnei: looking
<dimitern> sidnei: don't you use the "reply" feature on rietveld? it's very useful and it sends your draft replies when you do lbox propose
<dimitern> sidnei: it's a bit hard to track what was changed where
<sidnei> dimitern: uhm, never used that. reply to the review comments you mean?
<dimitern> sidnei: yeah
<dimitern> sidnei: it's very convenient - just go to the file with the inline comment, click on it and you can reply, say "Done.", etc.
<dimitern> sidnei: and RV collects them as drafts until you send them manually or through lbox
<sidnei> dimitern: otoh, did you use the 'delta from patch set' link?
<dimitern> sidnei: yeah, I used that, but my point is the link between reviewer comments and replies gets broken
<dimitern> sidnei: not to worry, just saying
<sidnei> ok, it's only my 3rd branch, i'll do that next time :)
<dimitern> sidnei: that's why I'm mentioning it :)
<dimitern> sidnei: thanks
<dimitern> sidnei: do you also use bzr rv-submit when you're ready to land the CL?
<sidnei> dimitern: first time i heard that
<sidnei> bzr: ERROR: unknown command "rv-submit"
<dimitern> sidnei: just a sec
<dimitern> $ mkdir -p ~/.bazaar/plugins
<dimitern> $ bzr branch lp:rvsubmit ~/.bazaar/plugins/rvsubmit
<sidnei> so 1) reply to review comments, 2) lbox propose, 3) bzr rv-submit once everything is clear?
<dimitern> sidnei: ^^
<rogpeppe> sidnei: reviewed
<dimitern> sidnei: yeah, rv-submit takes care of setting the commit message on the MP in LP, checking for approvals, letting you edit the message if you wish, and finally setting the MP to Approved, so the tarmac bot can pick it up and land it
<rogpeppe> dimitern: ha, i didn't know about rv-submit
<dimitern> rogpeppe: it's f*cking amazing:)
<sidnei> dimitern: awesome. i'll use that then. /me rushes to doctor appt.
<dimitern> otherwise, you'll have to do that yourself on LP
<rogpeppe> dimitern: yeah, that's what i've been doin
<rogpeppe> g
<dimitern> sidnei, rogpeppe: one caveat you'll have to keep in mind is that rv-submit does not push your branch, so be sure to do one last lbox propose (or bzr push) before that
<rogpeppe> dimitern: ok, that's worth knowing thanks
<dimitern> usually I do lbox propose with the last changes + sending my draft replies from the review
<rogpeppe> time to stop. will do the upgrade check tomorrow, when i've managed to build a 1.12 instance
<rogpeppe> g'night all
<dimitern> night!
<ahasenack> guys, if I have a public-bucket-url defined in my environment, does that mean I need to have the tools there too, and not just simplestreams?
<ahasenack> both the tools and simplestreams are taken from public-bucket-url, if it's defined?
<thumper> morning
<thumper> mgz: around?
<sidnei> hey thumper, sent an email about containers and apt proxy, in case you're interested in replying *wink*
<thumper> hi sidnei
<thumper> I'm starting to get into travel mode
<thumper> got things to get organised
<thumper> and kinda focused on the maas demo of containers
<thumper> but I'll try :)
<sidnei> thumper: btw, i'll be at the sprint too
<thumper> sidnei: cool
<sidnei> i keep forgetting that you have to travel almost twice as much than me
<thumper> twice as much or twice as far?
 * thumper gets ready to hurl his toys out of the cot
<thumper> fwereade, mramm: either of you two around?
<sidnei> both i guess :) /me looks it up on google maps
<sidnei> 11689.8 Miles vs 6417.2 Miles
<thumper> wow
<sidnei> to london
<thumper> You kinda get used to it
<thumper> I get in the zone and just watch movies and sleep
<sidnei> same ;)
<sidnei> it's 11h30min from sao paulo to london
 * thumper looks at tripit
<thumper> so I'm at the airport 4pm Saturday
<thumper> and land IOM 4:05pm Sunday
<thumper> and add 11 hours TZ diff
<thumper> 33 hours
<thumper> not door to door
<thumper> that's probably another hour or so
<sidnei> lovely. ill be at the airport at 4pm Saturday and land at IOM 9PM Sunday. the magic of timezones.
<benji> gary_poster: I just had a successful test run, so it's ready to land
<benji> well, once I get some reviews
<benji> and I'm in the wrong channel
<gary_poster> benji awesome, thanks!
<benji> I'll just stay here
<gary_poster> nenji lol ok
<benji> I'm going to be in the wrong channel all the time from now on
<gary_poster> benji
 * benji /joins #php
<thumper> wallyworld: a chat if you please as soon as you start
<wallyworld> thumper: now is ok
<gary_poster> ok sounds good, please just make sure I'm actually on that channel too :-P
<benji> heh
<thumper> wallyworld: ok, I'll start a hangout
<thumper> wallyworld: https://plus.google.com/hangouts/_/dcbe5477374b029b74897c9dffb381cf37f9be97?hl=en
<bigjools> hullo.  I need to update gwacl on the bot before landing a core change, how do I do that?
<mramm> thumper: just got back
<thumper> mramm: and I'm just leaving 8)
<davecheney> bigjools: i believe the procedure is still the same as before
<davecheney> mgz or jam need to do that
<bigjools> I don't know the procedure at all sadly
<bigjools> so I am blocked all day on landing my branch?
<davecheney> bigjools: i believe so
<davecheney> wallyworld: do you have keys to update the bot environment ?
<wallyworld> davecheney: what do you need?
#juju-dev 2013-08-01
<davecheney> wallyworld: bigjools needs gwacls updated on the bot ?
 * bigjools needs gwacl updating on there so I can land a dependent core branch
<wallyworld> i think i can. never done it. let me try
<bigjools> mucho grassy ass
<wallyworld> bigjools: i can ssh into the bot machine and i've found the src tree but when i do a bzr status in the gwacl directory i get: bzr: ERROR: No such file: u'/home/tarmac/trees/src/launchpad.net/gwacl/.bzr/checkout/shelf'
<wallyworld> nfi
<bigjools> can you just do a "bzr up"
<bigjools> seems like it's a checkout
<wallyworld> why wouldn't bzr status work?
<bigjools> nfi
<bigjools> does bzr info work?
<wallyworld> yes
<wallyworld> there's a lock preventing update right now. but there's also a build running
<wallyworld> i'll try again after the build
<bigjools> how often does tarmac run?
<bigjools> you might need to disable it temporarily
<wallyworld> actually, it's a permission denied
<bigjools> O_o
<wallyworld> because i'm logged in as ubuntu and it seems i need to be ~tarmac
<wallyworld> and i don't know the password to su
<wallyworld> i'll see if it's in an email somewhere
<bigjools> can you ssh tarmac@ ... ?
<wallyworld> no, permission denied public key
<bigjools> ah well
<wallyworld> i'll try and find a password
<bigjools> thanks man
<wallyworld> bigjools: done
<bigjools> wallyworld: \o/  thanks
<bigjools> coffee++
<wallyworld> np. rev is 207
<wallyworld> yeah coffee
<thumper> wallyworld: while you are in the landing bot, care to update loggo?
<davecheney> heads up, 1.12.0  has been released https://launchpad.net/juju-core/1.12/1.12.0
<wallyworld> thumper: sure
<jcastro> heya davecheney and thumper!
<thumper> hi jcastro
<davecheney> jcastro: sup!
<jcastro> shiny 1.12!
<davecheney> jcastro: yeah, just doing the paperwork now
<thumper> wallyworld: to deploy wordpress in a container on machine 0 I can do `juju deploy wordpress --to lxc:0` ?
<thumper> wallyworld: and for a new machine "--to lxc"
<wallyworld> thumper: supposedly :-)
<thumper> ?
<thumper> wallyworld: I'll try
<thumper> my eyes are funny
<wallyworld> the --to lxc doesn't work i don't think
<thumper> I think it is lack of oxygen or something
<jcastro> I deployed an entire wordpress stack to one AWS node today, it was glorious
<thumper> jcastro: yeah, saw the blog post
 * thumper waits for scp so he can bootstrap
<thumper> then I can go do something else while it boots
<thumper> jcastro: do you have any test maas environments?
<wallyworld> thumper: loggo on tarmac says no new revisions to pull
<jcastro> thumper: nope
<thumper> wallyworld: check to see if it is a branch or checkout
<thumper> wallyworld: also check revno
<jcastro> thumper: I do know the world wants constraints for the maas provider
<thumper> wallyworld: want 39
<wallyworld> thumper: yep, it is
<thumper> oh... ok
<thumper> seems updated then
<thumper> \o/
<wallyworld> coolio
<thumper> jcastro: perhaps I should ask sabdfl for access to his maas :)
<jcastro> I was going to recommend that exact thing
<jcastro> mims is on holiday so it's probably sitting idle
<davecheney> https://docs.google.com/a/canonical.com/document/d/1eeHzbtyt_4dlKQMof-vRfplMWMrClBx32k6BFI-77MI/edit#heading=h.o3idq0wwl0yz
 * thumper turns the lights on in bigjools's room
<davecheney> ^ nudge, please add agenda items for tonight
<davecheney> evilnickveitch: ping
<thumper> davecheney: ack
<bigjools> <huummmmmm>
<davecheney> still can't access all hands ...
<wallyworld> thumper: i didn't know bigjools liked it with the light on?
<bigjools> true, you normally turn it off for us
<wallyworld> yep, but then i can't watch :-(
<davecheney> axw: do you think https://canonical.leankit.com/Boards/View/103148069/105051172 is done ?
<davecheney> (sorry if you don't have perms for leankit)
<axw> davecheney: looking
<axw> I do now
<axw> davecheney: it works fine for me
<axw> I have the 13.04 packaged version
<axw> never saw any of the weirdness that was logged in the LP bugs
<davecheney> cool, assign to yourself and move it to the RHS
<axw> okey dokey
<evilnickveitch> davecheney, hi
<wallyworld> m_3: marcoceppi: thanks for the replies. could you copy to the list also so others can see your thoughts? sorry, i should have cc'ed you to the original juju-dev email
<marcoceppi> wallyworld: yeah, just joined the juju-dev mailing list. Surprised I wasn't already on it
<davecheney> axw: how about this one ? https://canonical.leankit.com/Boards/View/103148069/106071705
<axw> davecheney: no. thumper has something in the works that changes logging, so I'm holding off for now
 * thumper is back
<marcoceppi> wallyworld: cc'd
<wallyworld> thanks :-)
<davecheney> ok
<thumper> davecheney: yeah I have a branch pending that messes with logging somewhat
<davecheney> thumper: ok
<davecheney> cool
<jcastro> hey, remove-unit also takes the instance down right?
<axw> davecheney: when you say move to the right, do you mean into the review column?
<davecheney> jcastro: yes
<jcastro> that's what I thought
<davecheney> axw: at your judgement, if it isn't reviewable, then drop it in merged
<davecheney> i look in that column when writing the release notes
<axw> ok
<thumper> wallyworld: so... how do I deploy something into a new machine in a container
<thumper> what's the syntax?
<wallyworld> thumper: let me check. i thought you needed to use add-machine first
<wallyworld> there was a constraint also
<thumper> right
<thumper> I'm hoping I can just go 'juju deploy mysql --constraints container=lxc
<thumper> something like that
<wallyworld> thumper: yes that will work
<wallyworld> but it's not what big mark likes
<thumper> :)
<wallyworld> he prefers add-machine
<wallyworld> to create a container
<wallyworld> then --to to select
 * thumper tries it
<wallyworld> thumper: we haven't publicised the constraints version
<wallyworld> because it is verboten
<thumper> ok, that is starting
<wallyworld> but the code was already committed
 * thumper waits 25 minutes
<thumper> I have wordpress coming up in 0/lxc/0
<thumper> and mysql in 1/lxc/0
<bigjools> thumper: I see node 2 startting
<wallyworld> yay
<thumper> and we'll see if they can talk to each other
<bigjools> that one has a VGA cable on it :)
<wallyworld> don't forget to add a relation
<thumper> bigjools: yep, up it comes
<thumper> relation added
<thumper> now we wait
<axw> if anyone's bored, I would appreciate some more eyes on this: https://codereview.appspot.com/12019043/
<axw> davecheney: I yoinked the code out of your old branch for debug-hooks
<axw> thanks
<axw> :)
<bigjools> thumper: it's booting locally now
<thumper> \o/
<bigjools> thumper: might be done
<thumper> bigjools: no, it is downloading the cloud image for the container now
<bigjools> thumper: my interwebs don't look that busy, so I suspect not
<thumper> ah... dumb bug
<thumper> I saw the same bug on ec2
<thumper> bigjools: how's those interweb tubes now?
<bigjools> thumper: busy
<bigjools> I see blinkenlights
<thumper> \o/
<bigjools> two lots of routers, three lots of switches and a modem all looking furious with you
<thumper> oh fark
 * thumper stabs maas
<thumper> the uniter internally dies inside the container
<thumper> /var/lib/juju/MAASmachine.txt: no such file or directory
<bigjools> is container a verb here? :)
 * thumper hacks something
 * davecheney containers something
<thumper> aahgg
 * thumper stabs the nearest thing
 * davecheney goes for lunch
<thumper> poo bum
 * thumper grrs
<thumper> I know what that failed now
<thumper> bigjools: hey
<bigjools> yarp
<thumper> bigjools: is there a monitor attached to your maas controller?
<thumper> and keyboard?
<thumper> bigjools: if you hit http://10.0.0.208 what do you see?
<thumper> bigjools: I'm hoping for a wordpress error page
<thumper> saying no db configured
<bigjools> you mean the server or one of the nodes?
<thumper> or something like that
<thumper> bigjools: just something on the 10 net
<thumper> bigjools: the server is fine
<bigjools> I don't, I would only ssh into the server and use wget
<thumper> :(
<thumper> ok
<bigjools> but you can do that too :)
 * thumper noes
<bigjools> the 10. network is totally isolated for safety, I only access via ssh to the maas server
<bigjools> you could port forward with ssh
<bigjools> remember how -L works
<bigjools> -L localport:remotehost:remoteport
<bigjools> where remotehost is the IP as seen from the host you're sshing into
<thumper> oh yeah...
<thumper> wallyworld: definitely got a problem with the machine watcher
<thumper> on new machines
<thumper> wallyworld: where it is looking for containers
<thumper> wallyworld: it isn't getting initial state
<wallyworld> that bit was rewritten by william i think
<thumper> :(
<wallyworld> there was a large refactoring some weeks back
<thumper> agent-state-info: 'hook failed: "config-changed"'
<thumper> jpw dp O fox tjat?
<thumper> hehe
<thumper> how do I fix that?
<thumper> that was an unintentional weird right hand shift cypher
 * thumper sets up two ssh tunnels
 * thumper wonders if this weird shit will work
 * thumper has broken juju in a number of ways today
<thumper> *sad face*
 * thumper needs debug hooks
<axw> thumper: https://codereview.appspot.com/12019043/ ;)
<thumper> shortly, off to make a coffee and drown my woes in caffeine
<axw> heh :)
<davecheney> axw: do you think debug hooks will land this week ?
<thumper> axw: I have a feeling that review is going to take longer than I can actually give right now
 * thumper hands it to wallyworld
 * thumper writes up learnings
 * wallyworld is trying to get ^#@!%^^! tests to pass
<axw> davecheney: sorry, was making lunch. not sure - still at 0 LGTMs ;)
<axw> thumper: nps
 * thumper back for the meeting later
<davecheney> wallyworld: https://docs.google.com/a/canonical.com/document/d/1WpyfTgaChhmYFqPESBvfavbqLD1Fsj16NLW5PhmWxis/edit#
<davecheney> ^ as you've made everyone very happy with the --to flag
<davecheney> could you write a line or two about it
<davecheney> natefinch: bonjour!
<wallyworld> davecheney: when is the release? friday?
<davecheney> yup
<davecheney> or next week
<davecheney> but it's been two weeks since we did one
<wallyworld> davecheney: i have to go get my kid from school, i'll do it a bit later
<davecheney> wallyworld: no hurry
<wallyworld> davecheney: --to was already released in 1.11.3
<davecheney> wallyworld: really ?
<davecheney> did we call it out ?
<wallyworld> yeah
<wallyworld> i just checked the relese notes
<davecheney> oh well, ignore it then
<wallyworld> ok :-)
 * wallyworld drives to do school pickup
<davecheney> wallyworld:  https://codereview.appspot.com/12232043/
<davecheney> ^ won't this CL drive bigjools even more mental ?
<davecheney> ie, we're moving state out of the state, back to the local disk ?
<wallyworld> davecheney: it's not state but rather configuration
<wallyworld> stuff that was in env.yaml but will now be separate
<wallyworld> it's as per big mark and william's design
<davecheney> fair enough
<davecheney> i'm sure they know what they are doing
<wallyworld> let's hope so ;-)
<davecheney> config is a cluster fuck
<wallyworld> yep
<davecheney> it' can't get any worse
<wallyworld> yep :-)
<wallyworld> this will make it much easier for users
<wallyworld> it's one step of many
<davecheney> i'm sure it's written down
<wallyworld> to clean up env.yaml
<davecheney> i just missed it
<wallyworld> davecheney: https://docs.google.com/a/canonical.com/document/d/1ncsNzDHauV_9Fwsm59GjX0-O-_g48UYnObefwtBStG0/edit
<davecheney> that's the ticket
<rogpeppe> mornin' all
<rogpeppe> davecheney: hiya
<wallyworld> g'day
<rogpeppe> davecheney: do you know where i can get hold of a copy of juju v1.12 ?
<davecheney> rogpeppe: https://launchpad.net/juju-core/1.12/1.12.0
<rogpeppe> davecheney: does that have the dependencies too?
<davecheney> rogpeppe: yes
<rogpeppe> davecheney: great, thanks!
<davecheney> untar it, set your GOPATH to the base of the tar
<davecheney> go install ...
<rogpeppe> davecheney: the idea with config is that bootstrapping gives us a nugget of information that we store to the local disk (or in some other service).
<rogpeppe> davecheney: we then use that to connect back to the environment
<rogpeppe> davecheney: it's definitely a change of model, but i think it makes some kind of sense
<rogpeppe> davecheney: and we've already moved in that direction by storing the CA cert locally
<davecheney> rogpeppe: wallyworld not arguing with you two in anyway
<davecheney> but bigjools with go ape balls
<davecheney> that may or may not be a concern
<rogpeppe> davecheney: i'm interested in your reaction, because this is definitely a change in direction and i don't think it's been widely discussed
<rogpeppe> davecheney: and i'm interested what concerns bigjools might have too
<davecheney> rogpeppe: in as much as I am repeating what bigjools said, he doesn't like all the stuff we store in ~/.juju
<davecheney> i take no position on the matter as I have not been invovled in the design
<wallyworld> the long term goal is to store it in the cloud, for jaas etc
<wallyworld> it's all in the doc
<rogpeppe> davecheney: do you know why he doesn't like the stuff we store in ~/.juju ?
<davecheney> rogpeppe: he has more than one computer
<wallyworld> hence the long term goal :-)
<rogpeppe> davecheney: presumably he has to replicate his environments.yaml across all his computers
<wallyworld> and this isn't adding anything more locally
<wallyworld> just moving the deck chairs a little
<rogpeppe> davecheney: i guess he only has to do that once though (now), for a given environment
<rogpeppe> wallyworld: actually i think this *is* adding more locally
<wallyworld> and it will still be only once
<rogpeppe> wallyworld: it's manufacturing a control bucket
<wallyworld> we do that *now*
<wallyworld> with juju init
<rogpeppe> wallyworld: that's different
<rogpeppe> wallyworld: you don't need to use juju init
<wallyworld> but most people do
<rogpeppe> wallyworld: and it's a manual editing step
<davecheney> i've read that documenta nd mow even more confused
<wallyworld> sorry, whats manual?
<rogpeppe> wallyworld: and it only happens once for a given environment, no matter how many times that env is bootstrapped
<rogpeppe> wallyworld: you edit environments.yaml manually
<wallyworld> that's all that happens with the new stuff too
<wallyworld> it's on;y done once
<wallyworld> no need to edit env.yaml with juju init
<wallyworld> so long as your env variables contain creds
<rogpeppe> wallyworld: so you don't create a new .environments/xxx file every time an env is bootstrapped?
<wallyworld> nope
<wallyworld> just the first time
<wallyworld> for a given environment
<rogpeppe> wallyworld: hmm, interesting. i'm not sure that's right actually, but i'll reserve judgement
<wallyworld> so new env.yaml + local = old env yaml
<wallyworld> so same info, just now in 2 places
<wallyworld> env.yaml is the user facing bit
<wallyworld> we want to make that as simple as possib;e
<wallyworld> users don't need to edit admin secret or control bucket
<wallyworld> that's internal juju magic
<wallyworld> that shouldn't be exposed
<davecheney> wallyworld: oh, so is this CL just hiding those two config options and setting them automatically ?
<davecheney> you're not actually deleteing hte concept of a control bucket ?
<wallyworld> yep
<wallyworld> nope :-)
<rogpeppe> wallyworld: the difficulty is that now we're assuming that the control bucket we automatically generate (out of the user's control) is going to be ok to use for all time
<davecheney> right, objection withdrawn, i completely misunderstood what you were proposing
<davecheney> +1, carry on
<wallyworld> :-)
<wallyworld> rogpeppe: i gotta take the dog for a walk, happy to discuss later
<rogpeppe> wallyworld: enjoy!
<mgz> someone remind me to reboot five mins before the meeting please :)
<axw> wallyworld: I don't understand all the implications, but I was confused by those things in environments.yaml when I came across them. Wasn't sure what, if anything, I was meant to do with them.
 * bigjools reads scrollback and thinks that davecheney thinks I'm an ogre
<rogpeppe> bigjools: you're not?
<rogpeppe> bigjools: :-)
<bigjools> I am simply impatient with fuckwittery :)
<rogpeppe> bigjools: makes you scary to all us fuckwits :-)
<bigjools> ha
<bigjools> it's probably the meds I am taking, they make me do crazy things
<rogpeppe> bigjools: i am interested in your thoughts on this direction BTW
<bigjools> can you summarise?  I didn't read scrollback in detail
<TheMue> morning
<rogpeppe> bigjools: basically, we're moving towards a model where bootstrapping an environment yields a nugget of information that's later used to connect to that environment
<davecheney> bigjools: i was recalling your conversation when you found out how much environment specific state we stored on the client
<rogpeppe> bigjools: that will currently be stored in local disk, but later can be stored in the cloud
<bigjools> ah right
<davecheney> TOO THE CLOUD!
<bigjools> my thoughts are that this should be as HA as anything else
<davecheney> https://twitter.com/riskybusiness/status/362456762521120768
<rogpeppe> bigjools: this makes it possible to elimininate currently manually specified attributes such as control-bucket, and possibly admin-secret and others
<bigjools> I know that film...
<bigjools> rogpeppe: +1 to config elimination
<davecheney> rogpeppe: it sounds like you and wallyworld are working at cross purposes
<davecheney> wallyworld: is just making them take sensible defaults
<davecheney> and you are trying to move them
<rogpeppe> bigjools: obviously we can't eliminate config *entirely* because we need cloud credentials
<rogpeppe> davecheney: i don't *think* so
<bigjools> well obviously, but there's some stuff that's always been unnecessary
<rogpeppe> davecheney: there's no sensible default for control-bucket, because of s3's global name space
<davecheney> rogpeppe: a guid is a sensible default
<rogpeppe> davecheney: sure, but then you need to store that guid somewhere
<davecheney> rogpeppe: hence why i say that you and wallyworld are working at cross purposes
<rogpeppe> davecheney: you may well be right
<rogpeppe> davecheney: i'm coming from my understanding of fwereade and big mark's discussions
<davecheney> i read that document
<rogpeppe> davecheney: which may well be critically flawed
<davecheney> it appears unrelated
<bigjools> davecheney: btw I'll let you know tomorrow about azure improvements
<rogpeppe> davecheney: search for "# write local state as follows:" in the document
<rogpeppe> davecheney: that's the related piece
<rogpeppe> wallyworld: it looks to me from https://codereview.appspot.com/12232043/diff/1/cmd/juju/bootstrap.go that the local state *is* written every time we call Bootstrap
<davecheney> natefinch: it's dangerous to go alone, take this https://plus.google.com/hangouts/_/calendar/bWFyay5yYW1tLWNocmlzdGVuc2VuQGNhbm9uaWNhbC5jb20.mut2dk4mvoj39eq8jqni20ukoc?authuser=1
<axw> mgz: 5 mins (or so)
<natefinch> davecheney: thanks
<mgz> axw: ta!
<rogpeppe> fwereade: meeting?
<dimitern> fwereade: meeting?
<dimitern> wallyworld: ^^
<thumper-afk> mramm: I'm counting on you cancelling the managers meeting in 2.5 hours :)
<thumper> mramm: just saw the notification \o/
<mramm> thumper: cool
<mramm> see you in a couple of days ;)
<thumper> mramm: yep
<thumper> travel safe
<natefinch> ok, back to bed for me.
<axw> night
<rogpeppe> fwereade, wallyworld: lost you
<wallyworld___> rogpeppe: dimitern: stupid network died again, will talk to you guys after dinner
<rogpeppe> wallyworld___: ok
<rogpeppe> ([a-z]+:)?[0-9]+(/[a-z]+/[0-9]+)*
<mgz> enlightening
<rogpeppe> mgz: :-)
<mgz> doesn't match
<rogpeppe> lxc:0/kvm/12
<fwereade> rogpeppe, lxc:0/kvm/12 is meaningless, I think
<fwereade> ah I see
<rogpeppe> fwereade: orly?
<fwereade> rogpeppe, yeah, ignore me
<fwereade> rogpeppe, wallyworld___, dimitern: my internets seem to be maybe functional again
<fwereade> rogpeppe, wallyworld___, dimitern: so I'm back in the team meeting hangout if I'm wanted
<rogpeppe> fwereade: i'm suggesting that we should have something in the names package that understands that syntax, and knows at least how to split off the new container part
<fwereade> rogpeppe, still don't really think it's about names
<axw> rogpeppe: are you okay with my response to your destroy-environment comments? okay to land?
<wallyworld___> rogpeppe: dimitern: try again?
<dimitern> wallyworld___: i filed bug 1207230 for it
<_mup_> Bug #1207230: cmd/juju/addmachine.go might fail with unsupported container <juju-core:Confirmed> <https://launchpad.net/bugs/1207230>
<dimitern> it's not urgent, i'll take care of it today or tomorrow
<wallyworld___> dimitern: there error is that is not rejecting a machine id as an arg with a friendly message
<dimitern> wallyworld___: oh?
<dimitern> wallyworld___: isn't it supposed to accept both type:machine and machine?
<wallyworld___> the arg has to be either an container type (lxc) or a container with machine (lxc:1)
<wallyworld___> no
<wallyworld___> remember it is adding a machine
<dimitern> exactly, that's what i was saying
<wallyworld___> add-machine machine-id makes no sense
<dimitern> aaa
<dimitern> ok
<dimitern> so it should be "type:machine" or "type" only
<wallyworld___> the error is the syntax check above the split is broken
<wallyworld___> yes
<dimitern> yep, ok will amend the bug
<wallyworld___> thanks, sorry that i was initially unclear
<wallyworld___> i had to cast my mind back
<dimitern> no worries, thanks for clarifying
 * fwereade back much later
<dimitern> rogpeppe, TheMue: https://codereview.appspot.com/12198044 - StringsWorker
<axw> good night
<TheMue> dimitern: you've got a review
<dimitern> TheMue: cheers
<dimitern> rogpeppe: ping
<rogpeppe> dimitern: pong
<dimitern> rogpeppe: can you take a look at https://codereview.appspot.com/12198044
<rogpeppe> dimitern: will do
<dimitern> rogpeppe: thanks
<mgz> rogpeppe: after that, can you look at the branches I've put up and tell me where I'm going wrong?
<rogpeppe> mgz: i'll have a look
<mgz> thanks
* ChanServ changed the topic of #juju-dev to: https://juju.ubuntu.com | On-call reviewer: - | Bugs: 5 Critical, 81 High - https://bugs.launchpad.net/juju-core/
<rogpeppe> dimitern: reviewed
<rogpeppe> mgz: which branch should i look at first?
<natefinch> I feel like I was just here...
<dimitern> rogpeppe: thanks!
<dimitern> rogpeppe: no Stop() ?
<rogpeppe> dimitern: indeed.
<dimitern> rogpeppe: i don't get it
<rogpeppe> dimitern: not necessary
<dimitern> rogpeppe: expand please
<rogpeppe> dimitern: worker.Stop(typeWithKillAndWaitOnly) == w.Stop()
<rogpeppe> dimitern: oops, didn't mean to send that
<rogpeppe> dimitern: basically, nothing needs Stop - it's entirely implementable with Kill and Wait
<rogpeppe> dimitern: and the only thing we need workers for is to pass to worker.Runner
<dimitern> rogpeppe: but there are tests about stopping it cleanly
<rogpeppe> dimitern: which does not require a Stop method
<rogpeppe> dimitern: well then they should check that worker.Stop(w) stops it cleanly
<dimitern> rogpeppe: wait, so there is a global Stop method in worker?
<rogpeppe> dimitern: function, yes
<dimitern> s/method/function/
<dimitern> I see
<dimitern> rogpeppe: ok then
<TheMue> standup, lunch is waiting ;)
<TheMue> dimitern, rogpeppe: ^^^
<natefinch> or breakfast, for some of us ;)
<wallyworld_> or more wine :-)
<natefinch> rogpeppe: let me know when you'd like to do the code walkthrough, whenever is good for you is fine with me.
<rogpeppe> natefinch: now's good if you like
<natefinch> Sure
<rogpeppe> natefinch: shall we reuse the standup hangout?
<natefinch> rogpeppe: yep
 * TheMue => lunchtime
<ahasenack> hm, is something going on with the amazon tools bucket and juju?
<ahasenack> 2013-08-01 12:07:09 ERROR juju supercommand.go:254 command failed: Get https://juju-dist.s3.amazonaws.com/tools/juju-1.11.4-precise-amd64.tgz: EOF
<ahasenack> error: Get https://juju-dist.s3.amazonaws.com/tools/juju-1.11.4-precise-amd64.tgz: EOF
<ahasenack> wget works on that url
 * ahasenack freshens trunk
<rvba> ahasenack: ohoh!  That's something thumper saw with the MAAS provider as wellâ¦ I think it's worth filing a bug.
<ahasenack> rvba: ok, let me just see if a recent trunk has it too. Mine is from yesterday
<ahasenack> rvba: do you know if there is some rate limiting being applied to that bucket? I was trying sync-tools a few times before, testing --public (filed a bug), and now without --public and it started happening
<rvba> ahasenack: no idea, maybe mgz/jam will knowâ¦
<bigjools> this is the potential Go bug
<rvba> bigjools: yes :)
<rvba> That's him in person :)
<ahasenack> rvba: it's working now. Either it was the delay (I waited until a new copy of trunk was downloaded and build), or the new code
<ahasenack> I'm on Go 1.1.1
<ahasenack> the bug I filed before about sync-tools and --public is https://bugs.launchpad.net/juju-core/+bug/1207294
<rvba> ahasenack: I think it was just a genuine but transient problemâ¦ maybe rooted in Go itself.
<_mup_> Bug #1207294: sync-tools fails with --public <juju-core:New> <https://launchpad.net/bugs/1207294>
<ahasenack> I'm working around that bug now by making my control bucket temporarily named juju-dist ;)
<ahasenack> I have a question, when generate-image is run and outputs this:
<ahasenack> $ juju-metadata generate-image -i 65a1e7ba-eb56-48e6-9b4e-8f7c0c05e779  -s precise -r serverstack
<ahasenack> Boilerplate image metadata files "index.json, imagemetadata.json" have been written to /home/andreas/.juju.
<ahasenack> Copy the files to the path "streams/v1" in your cloud's public bucket.
<ahasenack> that path, "streams/v1"
<ahasenack> does that mean a bucket called streams?
<ahasenack> or is that inside the juju-dist bucket? Or your control bucket?
<ahasenack> since the public bucket url doesn't have a bucket component
<mgz> rogpeppe: sorry, missed your question earlier. one branch depends on t'other, but they're pretty seperate. the machine one is the first.
<marcoceppi> Has anyone gotten this error before?
<marcoceppi> error: cannot get latest charm revision: charm not found in "/home/marco/Projects/charms": local:precise/relation-sentry
<rogpeppe> mgz: ta
<marcoceppi> However, ~/Projects/charms/precise/relation-sentry does indeed exist
<dimitern> rogpeppe: updated https://codereview.appspot.com/12198044
<dimitern> oops, missed one typo
<dimitern> and one extra return, will repropose again after running tests
<ahasenack> marcoceppi: hm, I might have, but I don't remember when or how now
<marcoceppi> ahasenack: bleh, I'm really at a loss as to why it's freaking out. There are 5 charms in this local repo: wp, mysql, two custom subs, and this one standalone, and juju just does not like this charm
<ahasenack> marcoceppi: I would check if that path is bzr branch, has or not a revision file, and if it's the same charm ou actually deployed, if you have deployed one already
<ahasenack> marcoceppi: could it be that you have two or more metadata.yaml files with the same charm name inside? The directory of the charm dosn't matter
<marcoceppi> ahasenack: checked that and it's not the case. These three charms are being auto-generated so I'm really just trying to focus on what I did wrong
<marcoceppi> It has a .bzr dir and has revision information, I added a revision file to the charm (the other two that dpeloy don't have it and worked OK), metadata.yaml are all unique wrt names
<marcoceppi> charm proof only complains about things like copyright file, etc
<ahasenack> marcoceppi: -v?
<marcoceppi> ahasenack: OH
<marcoceppi> this is a problem
<ahasenack> do tell
<marcoceppi> first of all, feel really silly for not using -v, total shame on me over here
<marcoceppi> 2013-08-01 13:03:37 WARNING juju repo.go:341 charm: failed to load charm at "/home/marco/Projects/charms/precise/relation-sentry": charm "relation-sentry" using a duplicated relation name: "mysql_db-wordpress_db"
<marcoceppi> I have a provide and require using the same relation name, didn't realize that was a no-no
<marcoceppi> This makes things a little more complicated, but I can work around it. ahasenack thanks!
<ahasenack> marcoceppi: still, totally incorrect error message before
<dimitern> rogpeppe: updated https://codereview.appspot.com/12198044/ now with all suggestions; sorry for the spam
<ahasenack> marcoceppi: worth a papercut bug
<marcoceppi> ahasenack: yeah, I'll open a bug about the wording for it
<marcoceppi> ahasenack: and charm proof can be updated to catch things like this as well
<rogpeppe> dimitern: np - am giving nate a walkthrough, will be a little while, sorry
<ahasenack> marcoceppi: where can I get charm proof?
<dimitern> rogpeppe: no worries
<marcoceppi> ahasenack: charm-tools project
<ahasenack> marcoceppi: got a ppa handy or is it just in a branch?
<marcoceppi> ahasenack: it's in ppa:juju/pkgs
<marcoceppi> to be moved to ppa:juju/<whatever we decide for tools>
<ahasenack> marcoceppi: that's the one with pyjuju too, right?
<marcoceppi> ahasenack: correct
<marcoceppi> speaking of which ahasenack, I'm tempted to bite the bullet make a ppa:juju/tools and dump charm-tools, amulet, deployer, etc to it
<ahasenack> marcoceppi: I like that name
<marcoceppi> I don't think stable is the best name for it since a lot of these are just using build recipies
<ahasenack> right
 * marcoceppi pulls trigger
<rogpeppe> dimitern: reviewed
<dimitern> rogpeppe: cheers
<marcoceppi> ahasenack: there's a ppa:juju/tools now, if you want to move the builds for juju-deployer/api over to it
<ahasenack> ok
<ahasenack> marcoceppi: do I have upload permissions?
<marcoceppi> ahasenack: are you in the ~juju group?
<ahasenack> let me check
<ahasenack> marcoceppi: I'm not
<ahasenack> marcoceppi: let's just let hazmat copy the branches and recipes and use them in ~juju
<marcoceppi> ahasenack: works for me
<rogpeppe> mgz: could you re-propose https://codereview.appspot.com/12218043/ please; i'm getting a chunk mismatch
<ahasenack> :( I can't get juju to use my custom image
<mgz> rogpeppe: wha?
<rogpeppe> mgz: it's a not-uncomming rietveld/lbox error (i don't know which one's to blame)
<mgz> 'ing reitveld
<rogpeppe> uncommon
<rogpeppe> mgz: your TestSetAddresses function isn't testing what you think it is
<mgz> that's what I suspect
<rogpeppe> mgz: the state.address type is broken
<mgz> but... I'm not sure what the right way of asserting that stuff actually arrives in state is
<rogpeppe> mgz: i suggest marshalling instance.Address directly (but change it so it doesn't embed the network scope)
<rogpeppe> mgz: the usual thing is to call Machine again (or call Refresh)
<rogpeppe> mgz: because otherwise you're not actually reading from mgo
<rogpeppe> mgz: the reason that the address type is currently broken is that the fields are not exported
<mgz> I may well end up sticking instance.Address straight in, but wanted parallel types for now so the serialisation is seperate from the various populating logic
<mgz> ...gah, I changed that per a review comment
<mgz> no wonder I was sure this worked previously :)
<mgz> just recapitalise then?
<rogpeppe> mgz: just use instance.Address :-)
<rogpeppe> mgz: if it's got some "bson:" struct tags then it should be obvious that it's being serialised
<rogpeppe> mgz: although i do really want some more formal controls on changes to structs that are serialised
<rogpeppe> right, i need lunch
<mgz> okay, that fails then passes correctly
<dimitern> rogpeppe, TheMue: next in line https://codereview.appspot.com/12254043 - Deployer and MinUnitsWorker use StringsWorker now
<TheMue> dimitern: reviewed
<dimitern> TheMue: thanks
<mgz> well, that was easy to make working at least
<mattyw> I was going to take a look at https://bugs.launchpad.net/juju-core/+bug/1020322, but it looks like it's already been done?
<_mup_> Bug #1020322: Unit not found message is repetitive <bitesize> <papercut> <ui> <juju-core:Triaged> <https://launchpad.net/bugs/1020322>
<dimitern> mgz: you've got a review
<dimitern> mgz: also, please live test this
<TheMue> hmmpf
<TheMue> set --default would also introduce a behavior change
<TheMue> empty strings as configuration values are alowed then
<TheMue> dunno if this leads to compatibility problems
<mgz> dimitern: I don't understand this comment of yours:
<dimitern> mgz: and another one
<dimitern> mgz: yeah?
<mgz> > Also it's good to check this before that:
<mgz> > c.Assert(machine.Addresses(), HasLen, 0)
<mgz> that will never be the case I think? the issue I had was I got non-zero length even though the addresses never got in the doc
<dimitern> mgz: I mean check there are no addresses before calling SetAddresses, then check the same once more before calling Refresh, and then check they're set after Refresh
<mgz> but with the refresh, it will still be non-zero length, it will just also reload to actually exercise state
<dimitern> mgz: hmm? i wonder why's that
<mgz> ah, you meant right at the start after making the machine?
<dimitern> mgz: so there should be a test to check what's the state when you never called SetAddresses on a fresh machine, and they should be an empty slice, i think
<mgz> okay.
<dimitern> rogpeppe: got a moment?
<dimitern> mgz: could you return the favor by reviewing https://codereview.appspot.com/12254043/ ? :)
<mgz> sure :)
<dimitern> thanks!
<mgz> oo, it even looks educational
<rogpeppe> dimitern: just back from lunch, yes i've got a mo
<dimitern> rogpeppe: about https://codereview.appspot.com/12254043/
<mramm> hey hey
<mramm> so we need to get provider specific constraints on the roadmap for the next few weeks
<dimitern> mramm: like instance-type and such?
<rogpeppe> dimitern: reviewed
<dimitern> rogpeppe: thanks
<dimitern> well, what do you know.. i ran out of stuff to do this week :)
<dimitern> looking at bugs currently though
<dimitern> mramm: is there a plan who's going to work on bugs and who on the remaining api stuff until the end of next week?
<dimitern> rogpeppe: is this card merged now? Upgrader API only worker
<rogpeppe> dimitern: nope
<rogpeppe> dimitern: i'm just testing the 1.10->1.12->current upgrade path now
<dimitern> rogpeppe: I see
<mramm> dimitern: I think if you are working on API and can safely continue to do so it makes sense that you do
<mramm> I don't think there is a "plan" from above
<dimitern> mramm: ok then
<mramm> I think you guys can work it all out ;)
<dimitern> rogpeppe: I think I can start implementing the uniter API now, with the UA having connection to the API already, right?
<rogpeppe> dimitern: well, it will have a connection to the API when my CL lands
<rogpeppe> dimitern: which only has one review so far (https://codereview.appspot.com/12183043/ hint hint anyone :-])
<dimitern> rogpeppe: yeah, but it'll happen soon anyway, and I won't be ready with it for a few days perhaps
<dimitern> mgz: perhaps? ^^
<dimitern> mgz: you hate responding to comments on rietveld, right? :)
<mgz> somewhat :)
<natefinch> rogpeppe: (or anyone else) got a second to help the newbie?  I made a small change that requires changes to several tests, so I want to make sure it's the right thing to do before I go changing 8 different tests
<dimitern> natefinch: sure, bring it on :)
<natefinch> Looking at this bug: https://bugs.launchpad.net/juju-core/+bug/1154938
<_mup_> Bug #1154938: juju status should give the same help as juju bootstrap <bitesize> <cmdline> <ui> <juju-core:Triaged by natefinch> <https://launchpad.net/bugs/1154938>
<natefinch> It says juju status should give the same message, but really ,wouldn't it be an appropriate message for any command that needs the default environment file?
<dimitern> natefinch: ok, but where's your CL?
<mgz> hm, the state package really doesn't use loggo anywhere?
<natefinch> I'll check it in, it just breaks some tests as-is... wasn't sure if I should check in and then ask
<dimitern> mgz: not yet
<dimitern> natefinch: if it breaks tests, then definitely don't :) the bot won't let you anyway
<natefinch> dimitern: ok, good.  So... the change is just to have environs.ReadEnvirons to return a specific error if it can't read the default environments.yaml file... and then in cmd/Main() check for the file and output that error message to the context's stderr  (just like it did for bootstrap)
<dimitern> natefinch: can I see a link to the branch please?
<natefinch> like I said, the changes are only local right now, they're not commited.
<natefinch> Maybe I'm not using the right terminology for bzr... I'm still new to it.
<dimitern> natefinch: can you push it on LP so I can have a look? you can do lbox propose -wip
<natefinch> dimitern: thanks... new to LP too :)
<mgz> natefinch: bzr diff|pastebinit
<dimitern> natefinch: that way it's pushed on LP, and a CL on rietveld is created, but no mails are sent
<dimitern> natefinch: ah, sorry
<mgz> for the even more lo-fi method
<dimitern> natefinch: do you have lbox working?
<natefinch> it's installed, haven't run it, so....
<dimitern> then, in your work dir with the branch, bzr commit it, and then run lbox propose -wip
<dimitern> -wip is for work-in-progress = don't send review emails, just push it to codereview.appspot.com (rietveld)
<natefinch> dimitern: rietveld appears to be asking for google login credentials? How does that work with SSO?
<dimitern> natefinch: do you want to have a g+ chat, so I can help you as you go?
<natefinch> dimitern: yeah
<dimitern> natefinch: just a sec, i'll start a hangout
<dimitern> man they changed g+ *yet again*! how do I start a hangout now?
<natefinch> haha
<natefinch> upper right
<dimitern> i don't want to invite, i just want the link
<dimitern> ah.. it's hidden down there https://plus.google.com/hangouts/_/375c6630051efe7089a102bc829f8afd25fb80d9?hl=en
<dimitern> natefinch: ^^
<rogpeppe> dimitern: just tested the upgrade path from 1.10 -> 1.12 -> api-based upgrader branch and it all seems to work
<dimitern> rogpeppe: woohoo!
<rogpeppe> dimitern: :-)
<rogpeppe> dimitern: unfortunately fwereade not-LGTM'd a prereq branch so i can't get anything in until he's available again
<rogpeppe> please someone: another review of https://codereview.appspot.com/12183043/ would be much appreciated
<TheMue> rogpeppe: looking
<rogpeppe> TheMue: thanks
<TheMue> rogpeppe: done
<rogpeppe> TheMue: thanks!
 * TheMue still thinks about setting empty strings in config
<TheMue> setting to default now works, but the empty string leads to changes deep in the charm config
<rogpeppe> TheMue: have you implemented juju set --default now?
<TheMue> rogpeppe: set --default works, but set option= to set it to empty string not
<TheMue> rogpeppe: currently discussing is on #juju
<rogpeppe> TheMue: ah
<mgz> dimitern: where's a simple non-horrible example of table tests?
<TheMue> rogpeppe: in that case I have to change config in .../charm
<TheMue> rogpeppe: that could break charms
 * rogpeppe looks for a particularly nice table-based test
<mgz> ta rog
<TheMue> mgz: cmd/juju/config_test.go
<mgz> thanks!
<TheMue> mgz: an about string/info string, input args, a possible error and the expected results
<rogpeppe> mgz: charm/url_test.go has a few reasonable simple examples
<rogpeppe> mgz: although actually Commentf stuff is a bit antiquated now
<rogpeppe> s/Comment/the Comment/
<rogpeppe> mgz: version/version_test.go is another nice example
<rogpeppe> mgz: i think we'd probably add some more identifying information to the Logf statement now
<rogpeppe> hmm, oops: http://paste.ubuntu.com/5936989/
 * rogpeppe needs to go
<rogpeppe> g'night all
 * TheMue has to go too
<TheMue> cu tomorrow
<thumper> morning
<thumper> I'm going to be in and out today as I organise stuff for travel
<sidnei> hey thumper! i'd love some comment on the cloud-init message. mramm suggested talking to fwereade but i guess he's en-route too
<davecheney> arosales: ping
#juju-dev 2013-08-02
<thumper> axw: ping
<axw> thumper: ahoy
<thumper> axw: how are you going for work?
<thumper> axw: I'm wondering about flicking you a piece of work
<axw> I'm working on https://bugs.launchpad.net/juju-core/+bug/1167441 atm
<_mup_> Bug #1167441: environs/providers must report instance state, like py-juju <juju-core:Triaged by axwalk> <https://launchpad.net/bugs/1167441>
<axw> this shouldn't take too long I think
<axw> (or I can switch tracks if it's important)
<axw> thumper: ?
<thumper> otp
<axw> ok
<thumper> kk back
<thumper> this isn't urgent, but it is important
<thumper> so you don't have to switch
<thumper> it is really just doing some checks prior to bootstrap for the local provider
<thumper> with nice error messages
<thumper> something like:
<thumper> if ubuntu: check to make sure lxc and mongod installed
<thumper> if not, give instructions: apt-get install blah blah
<thumper> if linux:
<thumper> check and give generic instructions: ie, plz install mongod and lxc
<thumper> otherwise:
<thumper> sorry, local provider not supported on your platform
 * thumper looks to see if there is a bug already for it
<thumper> https://bugs.launchpad.net/juju-core/+bug/1204094
<_mup_> Bug #1204094: juju-core should suggest mongodb-server <papercut> <juju-core:Confirmed> <https://launchpad.net/bugs/1204094>
<thumper> that's about as close as it gets
<thumper> but slightly different
<thumper> although I think the rationale for that bug is that we don't give good error messages if we fail
<thumper> actually, right now, if you don't have it installed, the boostrap "works"
 * thumper thinks
<thumper> no it does
<thumper> n't
<thumper> it fails while waiting for the service to start
<thumper> but most likely, not a good error message
<axw> oops sorry I wasn't looking - reading back
<axw> ok
<axw> I'll get this one under wraps, then start on that
<thumper> axw: awesome, thanks
<wallyworld_> axw: here's another bug about local provider error messages. bug 1206959
<_mup_> Bug #1206959: error from no installed lxc is obscure <juju-core:New> <https://launchpad.net/bugs/1206959>
<axw> wallyworld_: thanks
<wallyworld_> axw: thanks for looking at it. i saw in the back scroll you were doing some work in this area. i'll assign the bug to you
<axw> nps
<axw> wallyworld_: any idea why lbox would say this?
<axw> bzr: ERROR: Permission denied: "~axwalk/launchpad.net/goamz/": : Project 'launchpad.net' does not exist.
<axw> eh I think because I used go get originally
<axw> so I got the wrong push branch
<bigjools> bzr pull --remember lp:goamz
<bigjools> will fix it
<axw> bigjools: thanks, that's what I was looking for
<bigjools> np
<axw> --remember doesn't remember :(
<wallyworld_> axw: sorry, i was picking up my car from the repair shop, so missed your message
<axw> wallyworld_: nps, I've got it sorted now
<axw> I forgot I'd modified ~/.bazaar/locations.conf
<axw> so the push location as getting overridden
<axw> wallyworld_: I've got a trivial change on goamz, would you mind reviewing?  https://codereview.appspot.com/12324043/
<wallyworld_> sure
<axw> needed for a test in juju-core
<wallyworld_> axw: just land it, since it's trivial, no need for a 2nd +1
<axw> cheers
<wallyworld_> np
<axw> wallyworld_: what's the merge process for goamz?
<TheMue> morning
<axw> bzr merge?
<axw> TheMue: morning
<wallyworld_> axw: you push to trunk
<axw> ok
<wallyworld_> you may not have permission if you are not in the group that owns it
<wallyworld_> i can do it for you if you are unable
<wallyworld_> just make sure you run all the tests
<axw> wallyworld_: tests all pass. I'm not a member of ~goamz, so I don't think I'm going to be able to push
<wallyworld_> axw: i'll land it
<axw> ta
<jtv2> Hi folks Â­â any reviewers available for this one?  https://codereview.appspot.com/12270043
<wallyworld_> axw: done
<axw> thanks!
<jtv> TheMue: Morgen!  Hast Du vielleicht etwas Zeit dafÃ¼r?  ^
<TheMue> jtv: Oh, in German. Nice. Currently triaging a bug but almost done with it. Then I'll take a look.
<jtv> Thanks.  Somebody I know spoke German with me recently, and now I feel the urge to practice again.  A decade without practice made me really bad at it.
<jtv> It was probably my 3-rd best language at school, but now...
<axw> jtv: I did 6 years of German at school, never practiced it after, and now ich kann nichts .. rememberen ;)
<jtv> axw: I can't fault your grammar, only your vocabulary.  :-)
<axw> ;)
<jtv> I think it's "und jetzt kann ich mich nichts mehr erinnern"
<jtv> "remember" is transitive.
<rogpeppe> mornin' all
<axw> morning
<rogpeppe> axw: hiys
<rogpeppe> hiya even :-)
<jtv> Hi rogpeppe
<jtv> I mean, hiys!
<rogpeppe> jtv: hiys :-)
<TheMue> *phew* found it, feeling has been right that this bug is already fixed and committed
<TheMue> jtv: Nun kann ich deinen Code begutachten. (Now I can review your code.) ;)
<jtv> Hurrah!
<jtv> Ob das wirklich "begutachten" heisst wirden wir mal sehen...   :-)
 * jtv remembers alternative words such as ablenken, and scheitern.
<jtv> "werden."  :(
<axw_> net's a little wonky, might be in and out
<TheMue> jtv: review is "begutachten", but it is a not very common term. "prÃ¼fen" may be better, but does not have the same official character has "begutachten".
<TheMue> jtv: and your code is reviewed. ;)
 * TheMue just got a parcel with 4 books for review. in this case it is called "Rezension".
<jtv> Thanks TheMue â but "begutachten" is etymologically derived from "consider good," right?
<TheMue> jtv: even if it contains the stem "gut" it is more the verb for the noun "Gutachten". you can also say "ein Gutachten erstellen". and that surely can end in a bad result
<jtv> Ah!
<jtv> Thanks for explaining :)
<frankban> could anyone please review https://codereview.appspot.com/12178043 ? I just need the second review, thanks!
<dimitern> frankban: i'll take a look
<frankban> thanks dimitern
<dimitern> frankban: done
<dimitern> fwereade: ping
<frankban> dimitern: thank you! re your suggestion, I don't want the test to fail if len(units) != 1, I just want the loop to continue
<dimitern> frankban: ah, I see, ok then - ignore that :)
<frankban> cool
<fwereade> dimitern, heyhey
<dimitern> fwereade: hey, I'm decided to start working on the uniter API
<dimitern> fwereade: do we need to discuss it first, how do you think?
<fwereade> dimitern, probably not a bad idea
<fwereade> dimitern, quick g+?
<dimitern> fwereade: sure
<dimitern> fwereade: https://plus.google.com/hangouts/_/f497381ca4d154890227b3b35a85a985b894b471
<rogpeppe> fwereade: any chance of another look at https://codereview.appspot.com/12175043/ ? i'm currently blocked on your "not lgtm"
<rogpeppe> fwereade: also, you might want to have a look at https://codereview.appspot.com/12183043/
<axw> fwereade: when you're not inundated, please see my reply to your latest question on the debug-hooks change. If you're okay with that, I'll land it on Monday
<axw> night all, have a nice weekend
 * TheMue => lunch
<dimitern> fwereade: so removing the settings from UnitSettings seems a lot bigger than I originally though, and I'll leave it as is, as you suggested if it happens to be more difficult that expected
<fwereade> dimitern, bah, annoying, but fair enough
<fwereade> dimitern, is the complexity mostly on the watcher side or the client side?
<dimitern> fwereade: well a lot of hookqueue tests have to be changes and with each change I'm getting less certain i'm doing it right
<dimitern> fwereade: I can make them pass if I spend a few hours more perhaps
<fwereade> dimitern, yeah, I can understand that
<fwereade> dimitern, in that case just make it clear that UnitSettings.Settings is never guaranteed
<fwereade> dimitern, and we can then kill it with impunity at some point in the future
<dimitern> fwereade: ok, will do
<dimitern> rogpeppe, fwereade: https://codereview.appspot.com/12344043/
<natefinch> dimitern: what's the proper way to contact IS about my reitveld sign-in problem?
<dimitern> natefinch: #is on the canonical irc server
<natefinch> dimitern: thanks
<dimitern> natefinch: there's also a request tracker somewhere, which I have never used
 * fwereade gtg out I'm afraid, I'll do some more reviews after lunch
<natefinch> dimitern: is there a way to manually perform the steps that lbox does? Maybe that would give me a better idea of what's wrong
<rogpeppe> natefinch: what's your sign-in problem?
<rogpeppe> dimitern: reviewed
<dimitern> natefinch: I don't really know, but probably if you trace that the code's doing..
<dimitern> rogpeppe: cheers
<natefinch> rogpeppe: when I try to sign into rietveld using lbox, it tells me bad username or password... I'm using my ubuntu one credentials, which definitely work on login.ubuntu.com
<natefinch> (and I can sign into reitveld in chrome w/ SSO no problem)
<TheMue> dimitern: standup
<rogpeppe> mgz: hg log -l 1 --template '{node}\n' -r .
<rogpeppe> mgz: is the preferred solution i think
<dimitern> rogpeppe: https://codereview.appspot.com/12344043/ - is that better?
<dimitern> rogpeppe: I noticed a typo: s/remove/remote/
<mgz> >_<
<rogpeppe> dimitern: made another suggestion based on your version
<dimitern> rogpeppe: thanks
<rogpeppe> trivial CL anyone? https://codereview.appspot.com/12349043
<dimitern> rogpeppe: looking
<dimitern> rogpeppe: lgtm
<rogpeppe> dimitern: trivial?
<dimitern> rogpeppe: i think so yeah
<dimitern> rogpeppe: method expressions?
<rogpeppe> dimitern: next in line
<dimitern> rogpeppe: ok
<TheMue> rogpeppe: reviewed
<rogpeppe> TheMue: thanks
<allenap> Hi, does anyone have time for a relatively short review? https://codereview.appspot.com/12176044/
<allenap> I have one LGTM already, and this branch is a pre-req for another already approved branch.
<dimitern> allenap: looking
<allenap> dimitern: Thanks!
<dimitern> allenap: i don't see your first LGTM though
<allenap> dimitern: Oh, I thought jtv had done that. I guess I need another reviewer then; it's well past jtv's EOD now.
<allenap> Anyone else for a shortish review? https://codereview.appspot.com/12176044/
<dimitern> allenap: you've got a review
<allenap> dimitern: Ta :)
<rogpeppe> lunch
<allenap> sudo lunch
<allenap> mgz: Can I threaten, er, politely request a review? https://codereview.appspot.com/12176044/
<mgz> allenap: sure :)
<allenap> mgz: Ta muchly.
<mgz> ah, and I actually read it already, so joy
<dimitern> allenap: oops, my bad - missed the ports arg there
<allenap> dimitern: No worries :)
<natefinch> Perhaps an odd question: What's the release process like for Juju?  Is it documented somewhere?
<dimitern> natefinch: not sure it's actually documented in one place, it's more like scattered around in mailing lists and few google docs
<dimitern> natefinch: mgz and davecheney are your best sources on that I think
<mgz> yeah,
<mgz> I did say I'd gather everything up into a releaseing doc at one point, we're still refining stuff each release
<mgz> mostly dave does the work
<dimitern> mramm: ping
<mramm> dimitern: pong
<dimitern> mramm: still no response from hr about my missing tasks in allhands, I wrote to claire o'connell yesterday
<mramm> ok
<mramm> let's give it a couple of days
<natefinch> ok, follow up... who decides what features go into a release?
<mramm> and I'll follow up with her next week
<dimitern> mramm: ok, just saying i did my part to try and resolve this
<mramm> natefinch: dave cheney or everybody depending on how you look at it
<mramm> dave picks the point in trunk from which he cuts the release
<mramm> but the idea is that everything that goes into trunk should be releasable
<natefinch> yep, cool
<natefinch> are there dedicated QA people? Or just us?
<dimitern> natefinch: wrt charms and stuff there are some automated tests
<dimitern> natefinch: but juju-core itself testing is mostly us - go tests and live testing on ec2/canonistack
<dimitern> natefinch: and we get feedback from a lot of other canonical (and some external) guys
<natefinch> dimitern: that's cool
<dimitern> natefinch: you'd probably want to have an ec2 account for testing and setup your canonistack creds for openstack live tests
<dimitern> natefinch: ec2 costs can be reimbursed
<natefinch> I have an ec2 account, don't have anything set up with canonistack yet
<dimitern> natefinch: take a look here https://wiki.canonical.com/InformationInfrastructure/IS/CanonicalOpenstack?action=show&redirect=CanoniStack
<natefinch> dimitern: thanks
<dimitern> mgz: are you sure the bot's runining the ppa's golang 1.1.1 ?
<dimitern> mgz: ah, sorry, ignore that
<TheMue> wow, 35Â°
<dimitern> rogpeppe: your branch fails to build in rpc_test and apiserver/client_test
<dimitern> TheMue: ah, it's much cooler here today - 28 and cloudy for a change
<dimitern> hmm, haven't looked out actually - it's not cloudy at all
<TheMue> dimitern: I've got a list of all times and temps of all team members. only John has it warmer. ;)
<dimitern> TheMue: ah, well - 40+ there is like every day's average
<natefinch> TheMue: we had a bunch of 35-ish days earlier in the summer, but lately it's been more around 26, and today it's actually only about 20 out.
<TheMue> dimitern: yeah, very hot there
<natefinch> (26 is more like our normal summer temps)
<TheMue> natefinch: we have typically 20 to 25 and seldom above, but the whole July has been fascinating and it shall continue next week
<dimitern> natefinch: here in july and august it's typically 32-38, some days in august gettin 42-44
<natefinch> dimitern: dang
<natefinch> Pretty sure if it ever hit 42 here, the entire town would burst into flames
<dimitern> natefinch: on the flip side, it never gets much below 10-12 in winter
<dimitern> :)
<natefinch> dimitern: Ha. -20 isn't that unusual here, and most of the time it's around -10
 * natefinch totally doesn't have google open to translate between F and C ;)  stupid american units...
<rogpeppe> dimitern: ha, i was totally sure i'd run gotest-c ./...
<dimitern> natefinch: oh, in winter I grew up back home with -15 most of the time, -25 often, -35 at rarely, but very memorable :)
<dimitern> rogpeppe: ha!
<dimitern> natefinch: so i enjoy the hot weather, preferably indoors when it's too hot
<TheMue> natefinch: different units are always a pain, also when comparing inch and centimeters or miles and kilometers, not talk about feet
<dimitern> rogpeppe: when changing method expressions i might want to skip the apiserver/machiner
<dimitern> TheMue: one of the worst I think are volume measures - oz., gallons, etc.
<natefinch> TheMue: meters don't bother me, because I can pretty much translate 1:1 with yards, but kilometers are tricky.... and yeah, volume is the worst
<rogpeppe> dimitern: why so?
<dimitern> rogpeppe: well, to make my life a bit easier while refactoring machiner to use a common setstatuser
<dimitern> rogpeppe: or actually, don't worry, i'll deal with the conflicts
<TheMue> natefinch, dimitern: yeah, no idea of the volumes
<rogpeppe> dimitern: ok, thanks
<natefinch> gallons to liters is pretty easy, since a gallon is about 3.75 liters... you can just call it 4 ,and you're pretty close. Smaller volumes is harder.
<dimitern> TheMue: my second-most used google feature, after search is "x <unit> in <other-unit>"
<natefinch> ....but at least we don't use stones for weight :)
<natefinch> dimitern: yep, me too. Love that.
<dimitern> natefinch: oh, stones! yeah there's that as well
<dimitern> I think there's no plural actually: it's 20 stone :)
<TheMue> dimitern: i've got an app for it ;)
<natefinch> haha
<TheMue> dimitern: it also converts currencies
<dimitern> yep, I even wrote one (well, followed the tutorial really) currency converter for my ubuntu phone
<natefinch> intersting... I had tests that were failing last night that are passing this morning.... I hate that
<dimitern> natefinch: ah, we have a special tag for these "intermittent-failure" - if you happen across them check if they're already reported and file a bug please
<natefinch> dimitern: thanks. I'll do that if I come across them... unfortunately I closed the terminal they were in, and I don't remember exactly what they were
<dimitern> natefinch: no worries, they're tricky and usually helps to report them if you see them more than once in a while
<dimitern> natefinch: some tests are notoriously flaky because of some timeouts, which after lots of tweaking are *mostly* stable
<natefinch> dimitern: yeah, been there, done that.  I understand
<dimitern> rogpeppe: are you going to introduce state/interfaces.go ?
<rogpeppe> dimitern: yeah, i think so
<dimitern> rogpeppe: ok, i'll have some to add there
<dimitern> rogpeppe: btw it'd be really nice if godef follows symlinks and reverts back to the symlink, rather than resolving it finally
<dimitern> rogpeppe: i mean, I have ~/work/go/src/launchpad.net/juju-core/ symlinked to ~/work/juju-core/ and every time I do a godef lookup in emacs it resolves it to the full path, rather than the one in ~/work/juju-core/ where I originally clicked
<rogpeppe> dimitern: hmm, i'll have to think about that
<rogpeppe> dimitern: i'm not entirely sure it's possible
<dimitern> rogpeppe: well, perhaps if you detect the input file is symlinked, you can use that prefix when returning the result?
<dimitern> rogpeppe: not a big deal really, just saying - I might try to hack something around that in my copious free time :)
<dimitern> dang.. so following go conventions i'll end up with a type like SetStatuserer
<rogpeppe> dimitern: i'm a bit surprised it works at all if you're passing it a filename like ~/work/juju-core/state/foo.go
<rogpeppe> dimitern: StatusSetter
<dimitern> rogpeppe: oh, it works like charm
<rogpeppe> dimitern: weird, 'cos that's not inside your $GOPATH
<dimitern> rogpeppe: probably the link resolution comes before that
<rogpeppe> dimitern: yeah, maybe go/build makes a canonical path
<dimitern> rogpeppe: I need type StatusSetter in apiserver/common and state interface StatusSetter
<rogpeppe> dimitern: seems not unreasonable
<dimitern> rogpeppe: cf. common/remove.go - Remover and Removerer
<rogpeppe> dimitern: "Removerer" is an abomination
<rogpeppe> dimitern: but also quite funny
<dimitern> rogpeppe: :) yeah, like double negative
<dimitern> rogpeppe: I'll need StatusSetter and StatusSetterer in common
<rogpeppe> dimitern: we're going to move away from having a method on state for each interface it can return
<rogpeppe> dimitern: and have a single method, Entity, which returns the methods that all entities have in common
<rogpeppe> dimitern: then each place that needs a particular interface can type-convert to that interface as required
<dimitern> rogpeppe: websters dictionary actually contains setterer
<dimitern> rogpeppe: yeah, that'd be nice
<rogpeppe> dimitern: "setterer" means "one who cuts the dewlap (of a cow or ox), and inserts a seton, so as to cause an issue."
<rogpeppe> dimitern: that is, a person that setters.
<rogpeppe> dimitern: because that's the meaning of the verb "to setter"
<dimitern> rogpeppe: not sure what either a dewlap or seton are
<rogpeppe> dimitern: neither me :-)
<dimitern> :)
<rogpeppe> dimitern: on a dog, the dewlap is the bit that hangs down over the teeth, istr
 * TheMue is a differ, a person that does manual diffing ;)
<rogpeppe> dimitern: nope, i'm wrong
<rogpeppe> dimitern: http://en.wikipedia.org/wiki/Dewlap
<dimitern> wow :)
<jcastro> hey guys, so if I want to get say an m1.large and I put in the matching constraint numbers it gives me the next larger unit.
<jcastro> who do I need to convince that we'd like instance-types back?
<dimitern> jcastro: no-one, we'll have them
<jcastro> oh ok
<dimitern> jcastro: it was decided
<jcastro> well that was easy!
<dimitern> jcastro: and in the roadmap for next 2-3 weeks iirc
<jcastro> awesome!
<dimitern> jcastro: there was a lot of bikesheding around how to define them across providers/clouds though
<dimitern> jcastro: like, if you need fallbacks for the same provider, but different clouds, etc.
<jcastro> yeah
<jcastro> I would be happy with just ec2 since those are the ones people know
<dimitern> jcastro: i'm pretty sure openstack has to go there too
 * jcastro nods
<dimitern> rogpeppe: for SetStatus I'll need a way to get the entity from it's tag, so I can call SetStatus on it
<rogpeppe> dimitern: that's what the State.Entity method will do
<dimitern> rogpeppe: is that in yet?
<dimitern> rogpeppe: will.. so probably not then
<rogpeppe> dimitern: no, sorry, i just got distracted by the dubious code in testing.TestLockingFunction
<dimitern> rogpeppe: ok, I'll work with the assumption it's there already
<rogpeppe> dimitern: cool. you can call State.Lifer for the time being
<dimitern> rogpeppe: how so? that only gets me Tag() and Life()
 * rogpeppe just managed to get the go compiler to go into an apparently infinite loop using up all of memory
<rogpeppe> dimitern: Entity will only return a Tagger, probably
<rogpeppe> dimitern: you can type convert
<dimitern> rogpeppe: so I can do entity, err := state.Lifer(tag) and then if statusSetter, ok := entity.(state.StatusSetter); ok { statusSetter.SetStatus(...) } ?
<rogpeppe> dimitern: exactly
<dimitern> rogpeppe: ok, cool
<TheMue> so, both CLs are ready for review: https://codereview.appspot.com/12347043/ and https://codereview.appspot.com/12343045
<dimitern> TheMue: will take a look
<TheMue> dimitern: thx
<dimitern> TheMue: so is it possible to say "remove the setting" if the default is !nil or "" ?
<dimitern> TheMue: like juju set <svc> x= ?
<dimitern> TheMue: or juju set <svc> --default x= (set the default to empty) ?
<dimitern> rogpeppe: it seems you reverted back one of the panics?
<rogpeppe> dimitern: i reverted back the panics that were necessary
<dimitern> rogpeppe: why not just return some error there?
<TheMue> dimitern: remove a string should only be possible if it is configured as default: null and you say set <svc> --default thatOption
<rogpeppe> dimitern: which one are you referring to?
<rogpeppe> https://code.google.com/p/go/issues/detail?id=6016
<TheMue> dimitern: but that only with the 2nd cl. the first one doesn't change the behavior of set option=
<dimitern> rogpeppe: in rpc_test
<dimitern> TheMue: so what will now juju set <svc> option= do?
<dimitern> TheMue: can you do as well juju set <svc> --default option= ?
<rogpeppe> dimitern: because if we hit that line, something horrible has gone wrong
<dimitern> rogpeppe: wow :) you actually found a compiler bug, again? :)
<rogpeppe> dimitern: because it really should be unreachable
<rogpeppe> dimitern: seems like it
<dimitern> rogpeppe: awesome!
<dimitern> rogpeppe: seems like we're one of the main sources of go bugs :)
<TheMue> dimitern: as said, the 1st cl only adds --default as an alternative to option=, you cannot mix it.
<TheMue> dimitern: but you can do set option=
<rogpeppe> dimitern: erm, have you seen how many open bugs there are?!
<TheMue> dimitern: both set to default
<TheMue> dimitern: with the 2nd cl this changes
<dimitern> TheMue: I think that's confusing
<dimitern> TheMue: and needs more tests to verify all such cases
<TheMue> dimitern: then string option will be set to an empty string with option=
<dimitern> TheMue: and --default cannot take = after option or a value?
<TheMue> dimitern: you have to see both cls combined, only splitted in two cls
<dimitern> rogpeppe: haven't checked lately
<TheMue> dimitern: which case do you want to be tested?
<TheMue> dimitern: are you talking about the 1st cl?
<TheMue> dimitern: i already said twice, it cannot. why should it?
<dimitern> TheMue: --default option= and --default option=x at least
<dimitern> TheMue: because if you're able to do that without --default, people will expect you can do it with, and it should be tested
<TheMue> dimitern: it is, as those are detected as illegal options ;)
<dimitern> TheMue: I can only see --default invalidoption
<dimitern> TheMue: not --default validoption= or --default validoption=blah
<TheMue> dimitern: option= is an invalid option too, and option=x also
<dimitern> TheMue: ok, let's have 2 more tests for that then
<dimitern> TheMue: I'll commet it on the review
<TheMue> dimitern: i can add it, it helps you as a developer, but not the user
<dimitern> TheMue: it's exactly the other way around I think
<dimitern> TheMue: the tests should cover user stories, especially client-facing stuff like the CLI
<dimitern> TheMue: so --default is a flag?
<dimitern> TheMue: so we need tests that mix --default and other key=value pairs as well
<dimitern> TheMue: users might try juju set <svc> key1=val1 --default key2 key3=val3
<dimitern> TheMue: that's why I don't think --default should be a flag
<TheMue> dimitern: that flag has been the  result of a longer discussion. what would you propose?
<dimitern> TheMue: it should apply to the argument immediately following it, then it's obvious (and should be documented) it's an argument
<dimitern> TheMue: like --default=x (with or without the =)
<TheMue> dimitern: an argument looking like a flag?
<dimitern> TheMue: is --config a flag?
<dimitern> TheMue: it's not and it has an argument
<TheMue> dimitern: btw, also --default a b c d is working
<dimitern> TheMue: yeah, there are no tests for that as well
<TheMue> how do you handle multiple defauls in one tx?
<dimitern> TheMue: sorry? is it working or now?
<dimitern> not*
<TheMue> dimitern: in the cl set --default opta optb optc sets all three to default
<TheMue> dimitern: how should the call look like in your opinion?
<dimitern> TheMue: it can look like --default opta --default optb --default optc
<TheMue> dimitern: userfriendly?
<dimitern> TheMue: at least it's explicit, rather than key1=val1 --default key2 key3=val3 failing
<TheMue> dimitern: yeah, that's not optimal
<dimitern> TheMue: it has to be documented that --default has to be last
<TheMue> dimitern: but the explicit way is not user friendly
<dimitern> TheMue: i don't think is unfriendly, but that's another thing
<TheMue> dimitern: why has it to be the last?
<dimitern> TheMue: because of k=v --default x w=v
<TheMue> dimitern: ???
<dimitern> TheMue: it has to be last, otherwise the user might assume he can continue passing key=value pairs after --default <something>
<dimitern> TheMue: oh, I see, so you assume in the code there's either --default or not and it comes first
<dimitern> TheMue: ok, this simplifies things, but has to be documented better - there are 2 ways to invoke juju set: 1) <svc> key=value ... pairs, 2) --default name name...
<TheMue> dimitern: yes, the doc is currently not enough
<natefinch> is there a keyboard shortcut to tell ubuntu to make a window half the screen size? Like when you drag it up against the side of the screen? It's the one thing I miss from WIndows, and I use it all the time.
 * TheMue works with fullscreen on four virtual screens
<natefinch> I like being able to see stuff side by side, and with big monitors, making things fullscreen is usually a waste of space
<dimitern> TheMue: reviewed the first one
<TheMue> dimitern: thx
<dimitern> natefinch: there are all sorts of shortcuts - if you install ccsm you can set them yourself
<dimitern> apt-get install compizconfig-settings-manager
 * fwereade observes that a very small insect has somehow managed to get inside his laptop screen
<natefinch> google figured it out for me, ctrl-super-<direction arrow>
<dimitern> then run ccsm - go to to Window Management - Grid
 * fwereade wonders how long it will crawl around in there for
<TheMue> fwereade: inside? that's strange
<dimitern> fwereade: wow :)
<fwereade> TheMue, yeah, indeed
<fwereade> TheMue, blasted countryside
<fwereade> TheMue, full of life
<natefinch> I tried installing ccsm on my last ubuntu VM and was not successful. The default shortcut is fine by me, especially since it is nearly the same as I'm used to on Windows
<TheMue> fwereade: thought you were in london?
<fwereade> TheMue, suffolk today
<sidnei> reviews: https://codereview.appspot.com/12352043
<dimitern> TheMue: reviewed the second as well
<sidnei> fwereade: mramm told me to bug you about the cloud-init message i sent to the list. i suspect that's already on the schedule for being discussed next week?
<dimitern> natefinch: also it's worth mentioning that dragging the window around the edges will also put it left/right or maximize it
 * fwereade tries to load state for sidnei, just a mo
<natefinch> dimitern: yeah, that's what I've been doing, but if I can avoid using the mouse, it's preferable
<mramm> sidnei: it isn't yet, but I'm adding it now
<sidnei> thanks mramm
<natefinch> dimitern: it's also finicky with multiple monitors, easy to overshoot
<TheMue> dimitern: thx
<dimitern> natefinch: the defaults for grid window placement is ctrl+alt+keypad #
<natefinch> ahh, neat
<dimitern> sidnei: can you repropose please, the diff is not there
<sidnei> yeah, just noticed. doing it.
<dimitern> man.. i have sticky keypad now after yesterday's little beer spill
<natefinch> haha
<TheMue> i have no keypad
<dimitern> it good it's the external kbd, rather than the laptop
<sidnei> dimitern: there, fixed
<dimitern> sidnei: looking
<natefinch> dimitern: I did the same thing last week (soda, not beer)... also external kbd . Luckily no damage after letting it dry out overnight.
<dimitern> sidnei: wow, i never heard of install before
<dimitern> natefinch: i have to submerge it in water and leave it to dry :)
<fwereade> mramm, thanks; sidnei, I think I understand your need but smoser's points are good ones; I'm a bit leery of exposing cloud-init directly to users, even sophisticated ones
<natefinch> dimitern: yikes, good luck with that! Hope it's not an expensive keyboard
<fwereade> sidnei, what does cloudinit do for you, beyond (say) runcmd and add-package?
<dimitern> or probably just dismantle it and clean it up carefully
<fwereade> sidnei, because it seems potentially viable for juju to expose those in some way itself, and just happen to implement them with cloudinit
<fwereade> sidnei, (sorry, of course, apt-proxy as well)
<dimitern> sidnei: reviewed
<rogpeppe> dimitern, fwereade, anyone else: https://codereview.appspot.com/12354043/
<dimitern> rogpeppe: looking
<rogpeppe> mgz: do you think the dependency file should contain dependencies for a) just cmd/juju and cmd/jujud; b) the entire tree or c) the entire tree plus testing deps too ?
<dimitern> rogpeppe: lgtm
<rogpeppe> dimitern: ta
<mgz> rogpeppe: the lot
<rogpeppe> mgz: okey dokey
<dimitern> oh, yeah, the lot +1
<natefinch> getting an error building trunk after my last pull:
<natefinch> # launchpad.net/juju-core/environs/azure
<natefinch> ../juju-core/environs/azure/storage.go:149: context.GetContainerProperties undefined (type *gwacl.StorageContext has no field or method GetContainerProperties)
<rogpeppe> i just saw a failure in MachineSuite.TestWatchMachine
<rogpeppe> though i can't reproduce it reliably
<mgz> natefinch: see gwacl, pull that
<sidnei> fwereade: there's a lot of stuff in cloud-init. things like apt_mirror_discover_from_dns or whatever it's spelled are interesting. it looks up an ubuntu-mirror.%(domain)s hostname and uses that as the default mirror for example. it might be more interesting to people which are heavy cloud-init users indeed.
<rogpeppe> machine_test.go:594:
<rogpeppe>     testing.NewNotifyWatcherC(c, s.State, w).AssertOneChange()
<rogpeppe> testing/watcher.go:85:
<rogpeppe>     c.Fatalf("watcher sent unexpected change: (_, %v)", ok)
<rogpeppe> ... Error: watcher sent unexpected change: (_, true)
<rogpeppe> anyone seen that before?
<mgz> yeah, not sure I have any other context for you though
<dimitern> rogpeppe: it's intermittent
<rogpeppe> dimitern: you've seen it too?
<mgz> just remember complaining to william that the assert didn't show anything useful
<dimitern> rogpeppe: i've seen it like 3-4 times out of 50 runs
<fwereade> sidnei, yeah, the trouble is that if we expose it we end up relegating anything we don't provision with cloud-init to a second class citizen
<sidnei> fwereade: that's also smoser's concern yes.
<sidnei> fwereade: for now i'd settle on simply fixing https://bugs.launchpad.net/juju-core/+bug/1203816 the simplest way, and then we can discuss further.
<_mup_> Bug #1203816: local provider should support use of local proxy <juju-core:New> <https://launchpad.net/bugs/1203816>
<fwereade> sidnei, yep, that sounds good to me
<fwereade> sidnei, triaged high
<fwereade> sidnei, and next week is bug week
<fwereade> sidnei, so hopefully the immediate issue will be handled while we try to figure out the bigger ones
<sidnei> fwereade: if i didn't make it clear, im working on a branch already. and i'll be at the sprint next week.
<natefinch> mgz: thanks, that fixed me up
<fwereade> sidnei, ah, I didn't spot that -- many thanks then
<sidnei> dimitern: trying to make a const as you suggested in the review, but im failing to make it better to read. help?
<sidnei> dimitern: or something like this is ok? http://paste.ubuntu.com/5940759/
<rogpeppe> dimitern: i think i see how it can happen
<rogpeppe> dimitern: but i'm not yet sure how to fix the test so it's reliable
<dimitern> sidnei: my suggestion was (perhaps failed to mention) to use ` quotes
<dimitern> sidnei: that way you don't need to concat the lines
<sidnei> dimitern: http://paste.ubuntu.com/5940764/ ?
<dimitern> sidnei: something like this http://paste.ubuntu.com/5940765/
<dimitern> sidnei: yeah :)
<sidnei> dimitern: your version adds an extra \n at the beginning. is it possible to avoid that with `\ like in python?
<dimitern> rogpeppe: well, it happes rarely
<dimitern> sidnei: no, for version seems better actually, if it works for you use it - it reads better already
<sidnei> oki
<rogpeppe> dimitern: it's important that tests are reliable
<rogpeppe> dimitern: and that we know why they're failing
<dimitern> rogpeppe: i agree completely
<dimitern> rogpeppe: but i failed to see a reason why that particular one could fail
<rogpeppe> dimitern: it depends on the state/watcher implementation, and whether that will send an event or not
<dimitern> rogpeppe: can you make it fail more often than not?
<dimitern> rogpeppe: not can you make it, but does it do that with you
<rogpeppe> dimitern: i thought i'd be able to, but i haven't succeeded yet, which might mean my theory is bollocks
<rogpeppe> dimitern: right, i can now make it fail reliably
<natefinch> I'm getting some weird build failures trying to run go test in my new branch...
<natefinch> cmd/environmentcommand_test.go:44: undefined: cmd.GetDefaultEnvironment
<dimitern> rogpeppe: what was needed?
<dimitern> natefinch: did you pull trunk recently?
<natefinch> ...except that cmd.GetDefaultEnvironment is properly defined in a _test.go file
<natefinch> yeah
<rogpeppe> dimitern: i changed AssertOneChange to this: http://paste.ubuntu.com/5940791/
<rogpeppe> dimitern: and called that function at the end of TestWatchMachine
<dimitern> rogpeppe: well, commenting out the sync stuff will surely cause any time-sensitive watcher test to fail
<rogpeppe> dimitern: in theory, making those changes should not affect the behaviour of the test
<natefinch> dimitern: yeah, just pulled. Do I need to clean something out?
<rogpeppe> dimitern: not really
<rogpeppe> dimitern: the poll interval of state/watcher is 5s, considerably shorter than testing.LongTimeout
<dimitern> natefinch: can you paste the log you're getting with the errors?
<dimitern> rogpeppe: but the sync stuff is needed to get the changes after triggering them one the line just before the assert, right?
<natefinch> dimitern: http://pastebin.ubuntu.com/5940792/   (plus a lot more)
<rogpeppe> dimitern: only if you don't want to wait for the state/watcher to get around to polling
<rogpeppe> dimitern: it's a short cut, not essential
<dimitern> rogpeppe: I had to add it to a lot of tests to cause them to pass at all
<dimitern> natefinch: pulling trunk and trying now myself
<rogpeppe> dimitern: that's because the timeout was probably less than 5s
<dimitern> rogpeppe: most of the time it's a lot less
<dimitern> natefinch: so the cmd.GetDefaultEnvironment should be in cmd/export_test.go - can you see it there?
<rogpeppe> dimitern: these days, the worst case timeout should always be testing.LongWait (10s)
<natefinch> dimitern:  yep. it's there
<natefinch> dimitern:  the code looks correct, but go test seems to disagree
<dimitern> natefinch: try cd cmd/ && go test -gocheck.vv
<natefinch> dimitern: same log output, same failures
<dimitern> natefinch: it seems like there shouldn't be any failures, because it fails to build the tests
<natefinch> sorry... I meant same failure to build
<dimitern> natefinch: ok, but hmmm..
<dimitern> natefinch: try pasting "go env"
<natefinch> dimitern: http://pastebin.ubuntu.com/5940823/
<natefinch> dimitern:  go version go1.1.1 linux/amd64
<dimitern> natefinch: I think your gopath is wrong
<dimitern> natefinch: it should be just one path, not a list of paths
<rogpeppe> dimitern: here's a sketch of what i think is going on: http://paste.ubuntu.com/5940824/
<dimitern> rogpeppe: did you try the race detector?
<rogpeppe> dimitern: there's no memory race
<rogpeppe> dimitern: plus unfortunately we can't use the race detector currently because of the bug i linked to earlier
<sidnei> rogpeppe: can i get your blessing on https://codereview.appspot.com/12352043
<rogpeppe> sidnei: looking
<dimitern> rogpeppe: these 2 simple code paths have some serious and nasty complications
<rogpeppe> dimitern: how do you mean?
<dimitern> rogpeppe: we need to sync watchers so they don't compete like this
<natefinch> dimitern: gopath can be a list of paths... https://code.google.com/p/go-wiki/wiki/GOPATH
<dimitern> natefinch: it can be, but it's better that it's not
<dimitern> natefinch: it's tricky and flaky, trust me
<dimitern> rogpeppe: i mean the entitywatcher should somehow wait for the state watcher to poll first
<TheMue> so, will step out into vacation
<TheMue> dimitern: review is handled
<dimitern> TheMue: have a great holiday!
<dimitern> TheMue: thanks
<rogpeppe> dimitern: i *think* the problem in this case may be solved simply by calling Sync rather than StartSync
<TheMue> will keep an eye on further reviews so that i can push the stuff during some spare time
<TheMue> dimitern: thanks
<rogpeppe> dimitern: alternatively, it would be great if StartSync didn't allow a window for other events to arrive before actually starting to sync
<rogpeppe> dimitern: although fixing that implies restructuring the state/watcher control loop a bit
<dimitern> rogpeppe: yeah, a whole new can of worms i suspect
<rogpeppe> dimitern: it shouldn't be too bad, in theory
<rogpeppe> dimitern: i don't understand this comment, BTW
<rogpeppe> // NewLaxNotifyWatcherC returns a NotifyWatcherC that runs a full watcher
<rogpeppe> // sync before reading from the watcher's Changes channel, and hence cannot
<rogpeppe> // verify real-world coalescence behaviour.
<dimitern> rogpeppe: me neither, you should ask jam
 * dimitern steps out for 10m
<natefinch> dimitern: changed gopath to just the first directory, which is now reflected by go env, but same problem
<natefinch> dimitern: take your time, I'll go work on something else, no big deal
 * fwereade is off again, back again later
<dimitern> natefinch: try and paste go list all
<natefinch> dimitern: http://pastebin.ubuntu.com/5940890/
<dimitern> natefinch: I think there's your problem
<dimitern> natefinch: you have multiple copies of juju-core in your gopath
<dimitern> natefinch: if you try removing all juju-core* dirs except juju-core2 from $GOAPTH/src/launchpad.net/
<dimitern> natefinch: or moving them out of the way at least
<natefinch> hmm ok
<dimitern> natefinch: and also, rename $GOPATH/src/launchpad.net/juju-core2 to juju-core
<dimitern> natefinch: import paths and work dir checkouts must match the import paths
<dimitern> natefinch: yeah, too many import paths :)
<natefinch> dimitern: right, right... silly me.  I don't usually have multiple branches going of the same code in Go... forgot you can't just call them something else
<natefinch> that did it
<dimitern> natefinch: cool!
<natefinch> dimitern: thanks... I'll remember that for next time - gotta rename the branch I'm building to juju-core first
<dimitern> natefinch: np :)
<dimitern> natefinch: and now, after you fixed you lbox woes and everything is up and running, please don't forget to lbox propose your branch
<natefinch> dimitern: yep. Gotta write tests for my change first, which is why I was trying to run the tests in the first place. Probably by EOD though.
<dimitern> natefinch: no worries, it's good you have it running smoothly anyway
<natefinch> yep
 * dimitern reached eod: happy weekend everyone!
<natefinch> dimitern: have a good weekend!
<dimitern> natefinch: cheers, you too!
<rogpeppe> mgz: https://codereview.appspot.com/12361043
 * rogpeppe has reached eod too
<rogpeppe> g'night and happy weekends all
<natefinch> rogpeppe: g'night!
<sidnei> bummer, no review from rog. natefinch: are you into doing reviews yet?
<natefinch> sidnei: I don't think I'm qualified to do reviews yet. I can certainly review the quality of the code, but as for how it interacts with the rest of the system... I'm going to miss anything that's more than a little subtle
<natefinch> sidnei: in other words, I can review, but it won't count for much :)
<sidnei> natefinch: tis fine, a mostly trivial branch. https://codereview.appspot.com/12352043/
<natefinch> sidnei: done.  lgtm.
<natefinch> sidnei: if it were me, I'd rename addscripts to AddRunCmds or something similar, but that's really more of a complaint against the original code, not your changes
<sidnei> natefinch: i think it's a good suggestion, i'll make the change.
<natefinch> sidnei: cool.
#juju-dev 2014-07-28
<davecheney> wow. such merge. very conflict
<menn0> davecheney: is that the output of "git merge --doge"?
<wallyworld> thumper: you got time for a quick hangout?
<thumper> wallyworld: hey, I should be doing my overdue 360 review for fwereade
<wallyworld> thumper: well, do that first
<thumper> heh
<wallyworld> maybe ping me when you are free?
<thumper> wallyworld: I have 1:1 calls for 1.5 hours starting in 30 minutes
<wallyworld> :-(
<thumper> sure you don't want to chat now?
<wallyworld> ok
<wallyworld> https://plus.google.com/hangouts/_/canonical.com/foo
<davecheney> wallyworld: how come we have gopkg.in depdenendcies in juju now
<davecheney> I thought it was very clear they were not going to be added without further discussion
<wallyworld> davecheney: cause someone addd it? i have no idea. i didn't agree but it was ut of my hands
<wallyworld> i was outvoted
<davecheney> fine
<wallyworld> sorry
<davecheney> not yourfault
<axw> davecheney: we're going to have to anyway, labix.org/v2/mgo is not going to be updated anymore
<axw> and the github repo underneath can't really be used, because it refers to gopkg.in anyway
<axw> (I'm in the process of updating mgo)
<rick_h__> axw: davecheney it was also brought up around the charmv2 stuff helping us version the api for that stuff
<rick_h__> axw: davecheney though let me know if we need to work with IS to get something on prodstack. I'm all for making sure we run the stuff 100% correct
<rick_h__> heh, then again I see you're referring to the charmstore
<rick_h__> axw: just a heads up, we've got an in progress next generation in the branch v4 (which will be renamed to v2) https://github.com/juju/charmstore/tree/v4
<rick_h__> axw: not sure if you can/makes sense to make the same pr there as well
<rick_h__> or we can make sure to pull it across, but fyi
<axw> rick_h__: yup, rogpeppe let me know, I have done so
<axw> thanks
<rick_h__> axw: ty kind sir
<axw> rick_h__: as for hosting repo on prodstack; there's no point unless all of gopkg.in is on there
<axw> I don't think it's going to be any less reliable than labix.org, which hasn't really been a problem (except for a hiccup recently)
<rick_h__> axw: ok, I know I had a debate with roger last week about 'well it's not been down' being a bit different than 'it's hosted to our standards'
<rick_h__> axw: cool
<davecheney> axw: /me grumbles, loudly
<waigani> thumper: hangout?
<waigani> axw: when you have a moment, can we do a hangout?
<axw> waigani: sure
<axw> now's fine
<waigani> axw: cool give me a sec
<waigani> https://plus.google.com/hangouts/_/gu5bp7izdb5uz2sv6uzpz3fppaa?hl=en-GB
<wallyworld> axw: could you take a peek at bug 1347715 to see any recent work we did may be responsible (one of the state server instance commits is blamed)
<_mup_> Bug #1347715: Manual provider does not respond after bootstrap <bootstrap> <ci> <regression> <juju-core:Triaged> <https://launchpad.net/bugs/1347715>
<axw> okey dokey
<wallyworld> ta
<axw> wallyworld: when you have a sec, https://code.launchpad.net/~axwalk/gomaasapi/update-mgo-test-dependency/+merge/228442
<wallyworld> sure
<axw> and there's a bunch off PRs on various juju repos
<wallyworld> ok
<axw> thumper: thanks. don't suppose you have any better ideas about how to configure the mongod to use?
<thumper> not really
<thumper> seems like a solid enough approach
<axw> wallyworld: I just manually bootstrapped, worked fine.. :/
<wallyworld> axw: hmmm. i did think the error described in the bug (the upgrade quit one) was more noise than anything that would stop the agent working
<wallyworld> the jenkins job linked in the bug is still red sadly
<wallyworld> needs more investigation
<axw> yep. I'll see if I can run the CI script locally to repro
<axw> wallyworld: thanks
<wallyworld> np
<menn0> a review from someone who knows the machine agent would be appreciated: https://github.com/juju/juju/pull/407
<axw> wallyworld: missed one before https://github.com/juju/blobstore/pull/11
<davecheney> https://github.com/juju/juju/pull/408
<davecheney> anyone
<davecheney> trivial
<thumper> davecheney: done
<davecheney> thumper: ta
<davecheney> that had me scratching my head for an hour
<davecheney> due to a merge conflict that put that type back in a signature
<axw> davecheney: thanks. I'll have a look about fixing version in a followup
<davecheney> axw: ta
<davecheney>         // TODO(dfc) wtf
<davecheney>         if !canWatch(nil) {
<davecheney>                 return result, common.ErrPerm
<davecheney>         }
<davecheney> ............................................________
<davecheney> ....................................,.-'"...................``~.,
<davecheney> .............................,.-"..................................."-.,
<davecheney> .........................,/...............................................":,
<davecheney> .....................,?......................................................,
<davecheney> .................../...........................................................,}
<davecheney> ................./......................................................,:`^`..}
<davecheney> .............../...................................................,:"........./
<davecheney> ..............?.....__.........................................:`.........../
<davecheney> ............./__.(....."~-,_..............................,:`........../
<davecheney> .........../(_...."~,_........"~,_....................,:`........_/
<davecheney> ..........{.._$;_......"=,_......."-,_.......,.-~-,},.~";/....}
<davecheney> ...........((.....*~_......."=-._......";,,./`..../"............../
<davecheney> ...,,,___.`~,......"~.,....................`.....}............../
<davecheney> aww, where did the rest of it go
<wallyworld> axw: sorry, was doing scholl pickup and dinner shopping
<axw> wallyworld: nps (sorry, was doing school pickup ;))
<wallyworld> :-)
<axw> wallyworld: thanks for approving leave. gotta do some moving/painting
<wallyworld> np, have "fun"
<TheMue> morning
<voidspace> morning all
<voidspace> Some issues setting up a workstation in Romania, but I'm online
<voidspace> Should be better tomorrow
<TheMue> *gnah*
<TheMue> still fighting with my IPv6 routing between containers on differen nodes
<rogpeppe1> axw: for future reference, we have CI enabled on the charm store repo. to merge, add a review comment containing :shipit:
<axw> oops, thanks rogpeppe1
<rogpeppe1> axw: and... you didn't update the dependencies.tsv file
<axw> gah
<rogpeppe1> axw: so the branch is actually broken, i'm afraid
<axw> I will fix it
<axw> sorry
<rogpeppe1> axw: thanks
<axw> remove me from committers after please ;)
<rogpeppe1> axw: perhaps you could roll back tip, assuming nothing has landed in the meantime
<axw> sure
<rogpeppe1> axw: ta.
<axw> wtf did I just do. reverted my revert. well done
<rogpeppe1> axw: what *did* you just do?
<axw> I have no idea. not enough sleep. I'll do it slowly this time
<axw> rogpeppe1: so, CI triggers on :shipit:?
<rogpeppe1> axw: yup
<rogpeppe1> axw: but please wait for a review first :-)
<axw> sure
<axw> rogpeppe1: https://github.com/juju/charmstore/pull/37
<axw> rogpeppe1: and https://github.com/juju/charmstore/pull/38 for v4
<perrito666> morning
<TheMue> perrito666: morning
<rogpeppe1> trivial PR for juju/testing. review anyone? https://github.com/juju/testing/pull/25
<rogpeppe1> perrito666, mgz, TheMue: ^
<TheMue> rogpeppe1: yup, taking a look
<rogpeppe1> TheMue: ta
<TheMue> rogpeppe1: LGTM, itâs pretty small ;)
<rogpeppe1> TheMue: yup :-)
<rogpeppe1> TheMue: do you know if there's CI set up on juju sub-repos yet?
<TheMue> rogpeppe1: sorry, no
 * TheMue still fights with IPv6 routing between containers on different nodes
<axw> rogpeppe1: not sure if you saw this... https://github.com/juju/charmstore/pull/38
<rogpeppe1> axw: ah, sorry, lost in a sea of reversions :-)
<rogpeppe1> axw: looking
<axw> :)
<rogpeppe1> axw: i thought i just approved a branch that looked just like that
<rogpeppe1> axw: (that you pointed me at)
<rogpeppe1> axw: ah, v4!
<rogpeppe1> axw: gotcha
<rogpeppe1> axw: LGTM
<axw> thought I'd be proactive and break both branches
<axw> thanks rogpeppe1
<rogpeppe1> axw: :)
<axw> sorry for that
<rogpeppe1> axw: that's fine
<rogpeppe1> axw: CI is not consistently applied to juju sub-repos...
<rogpeppe1> axw: do you know if juju/testing is CI'd
<rogpeppe1> ?
<axw> nope. coming soon, I think
<axw> mgz is working on it
<rogpeppe1> axw: cool. i'll just push then.
<mgz> Any Minute Now
<rogpeppe1> axw: further update: please don't land that branch - frankban has fixed everything :-)
<axw> rogpeppe1: which branch?
<axw> rogpeppe1: the one to update dependencies.tsv?
<rogpeppe1> axw: confusion - perhaps you have already landed it
<axw> rogpeppe1: the reversion already merged
<rogpeppe1> axw: right, i *thought* so
<rogpeppe1> frankban: ^
<rogpeppe1> frankban: do you want to do the changes to use gopkg.in/mgo then?
<frankban> rogpeppe1: not for now, I just need to merge my branch, will merge trunk again
<rogpeppe1> frankban: ok
<rogpeppe1> axw: it's still up to you then :-)
<axw> rogpeppe1: I'll take a look tomorrow
<rogpeppe1> axw: ta
<mgz> axw: so, Revert "Revert "Revert "Update... what's tha changing exactly :P
<axw> !!!false
<axw> :)
<jam> TheMue: are you around now, or is this worker time?
<TheMue> jam: Iâm here, tracing around a bit. ;)
<jam> TheMue: I have to go check on the dog, brb
<TheMue> jam: opening 1:1 hangout
<rick_h__> axw: wallyworld fyi we have the charmstore stuff in ci at http://ci.jujugui.org:8080/ and it uses the lander. We'll look into why the branch/test didn't get picked up today
<rick_h__> axw: wallyworld so no big green merge buttons in that please
<wallyworld> rightio
<axw> rick_h__: yep sorry, I wasn't aware. rogpeppe1 pointed out after I broke it
<rick_h__> axw: gotcha, ok cool. Still catching up this morning. Sorry for the dupe pointer.
<axw> nps
<mgz> rick_h__: can you remove the hackers as a contributor to the branch then?
<axw> +1
<mgz> and add bots
<rick_h__> mgz: we could, but our team's always been a trust everyone all permissions kind of team.
<rick_h__> mgz: so understand the issue, it's a bit of a shift from normal work but we'll look into it
<jam> TheMue: omw
<axw> works well for people working on the charmstore regularly, not so much for people like me :)
<rick_h__> e.g. all team members have ci access at same level, manager on leankit, etc.
<rick_h__> axw: right, the pool is people is growing, culture shift probably on the way I guess. :(
<axw> I guess I have been conditioned a bit tho
<mgz> rick_h__: pretty much it just removes the footgun
<axw> I see a button, I think there's no CI
<rick_h__> understand, like I said, diff culture.
 * TheMue wants a command to see how often he rebooted his testing VMs today
<gsamfira1> TheMue: try: last
<TheMue> gsamfira: oh, nice, thx. didnât know that
<gsamfira> you are welcome :)
<TheMue> gsamfira: and grep and wc are my friends too ;)
<gsamfira> oh, of course. these are a sys admins best friend, along side lsof, sed, awk and bash one liners :D
<jrwren_> strace. never forgt.
<gsamfira> I was just tinking about this
<gsamfira> :))
<perrito666> ericsnow: seen nate?
<ericsnow> perrito666: nope (I just got on)
<perrito666> sinzui: are you on the habit of making trick PRs now? :)
<sinzui> No. Just frustrated. I may not merge that PR since I don't know what will happen this week with 1.20.2
<perrito666> sinzui: which reminds me
 * perrito666 goes to check restore CI
 * perrito666 raises an eyebrow
<perrito666> is that running in hp or ec2?
<sinzui> I think it is running in Hp because ec2 was failing to provide instances when we needed them
<perrito666> sinzui: I see a great deal of failure bootstraping :|
<sinzui> aws is healthy right now
<perrito666> sinzui: I see roughtly 50% of the tests failing and all before even beginning for what seems to be machine not coming up on bootstrap
<sinzui> perrito666, I reset the test. It will play on ec2
<sinzui> perrito666, this test left a machine that we could delete last week. maybe it has happened again.
<perrito666> sinzui:  fwiw I see no more apt related errors
<sinzui> yep
<natefinch> dmesg says my network adapters keep exiting with status 1
<natefinch> by keep, I mean after reboot and after replugging my USB Ethernet adapter
<perrito666> natefinch: ...?
<perrito666> your eth is usb?
<gsamfira> lsusb ?
<perrito666> natefinch: if you pastebin the dmesg I might be able to understand what exit means for an eth
<gsamfira> also, might help to get the ethernet card type and loaded kernel modules :)
<natefinch> that'll be tricky
<perrito666> natefinch: ?
<natefinch> lsusb doesn't show it. but dmesg says it gets recognized and then it exits
<perrito666> natefinch: sudo?
<natefinch> pastebin is tricky  with no internet
<perrito666> natefinch: I take you are not on that compuer
<gsamfira> it should show up in lsusb, or at least lspci
<natefinch> I could sneaker net it to my wife's laptop I guess
<natefinch> I am on my tablet
<gsamfira> if it does not, you can stop there :).
<gsamfira> and order a new one
<perrito666> natefinch: use the pendrive luke
<sparkiegeek> ...or a different USB port
<natefinch> it's not just the Ethernet, the built in WiFi does the same thing
<perrito666> natefinch: at this point I would recommend the following
<perrito666> boot with a live CD/USB
<perrito666> if that works backup your hd, fast
<natefinch> I have off site backup regardless, but yeah, annoying.
<perrito666> natefinch: anyway, what I meant is, if booting with live media works is your hd or at least the fs that is fried
<katco> https://github.com/juju/juju/pull/398
<natefinch> ug ok, so live disk works fine
<perrito666> natefinch: you have now 2 opts, fs corruption or hd breakage
<gsamfira> I think its just a bad kernel update :)
<natefinch> I'm with gsamfira
<perrito666> gsamfira: well if it where so we should hear axw yell on the same direction soon
<natefinch> and ericsnow
<gsamfira> :))
<perrito666> natefinch: 14.04?
<natefinch> all three of us have the same laptop
<natefinch> yep
 * ericsnow makes mental note to check HD
<perrito666> natefinch: well you can always chroot and install an older kernel
<ericsnow> natefinch: keep in mind that mine is a newer model (with SD)
<natefinch> I don't have the standard HD... hada big SSD before I bought it
<natefinch> ok, someone's going to have to help me install the older kernel... please and thank you...
<natefinch> is there a way to just load up a backup from a couple days ago or something like that?  I don't think I've done a kernel update recently
<gsamfira> you still have the old kernel
<gsamfira> after rebooting, keep shift pressed
<gsamfira> you will get the grub menu
<gsamfira> just select an alder version
<gsamfira> :)
<natefinch> ok
<perrito666> and since you are there you can always do an fsck on your sdd
<perrito666> ssd
<gsamfira> and if you don't already have trim, you should put that in a cronjob (considering you rarely reboot) :)
 * perrito666 gets cold called by directv and his phone company with bad offers
<perrito666> man, these people get really pushy
<gsamfira> :))
<natefinch> well that was fruitless
<natefinch> I knew I hadn't updated the kernel in ages
<natefinch> sigh
<natefinch> the HD is only a year old, and it's a top of the line samsung...   but certainly something is fubared
<gsamfira> if anyone is willing, I would appreciate a review for: https://github.com/juju/juju/pull/189
<hackedbellini> natefinch: hi! Is there any news on my issue?
<natefinch> hackedbellini: no, sorry.  We had a couple other issues come in that I had to look at as well.   I tried to write a fix for your problem, but had some problems getting it to work with the mongo driver we're using.  It'll take a little more time.  I might be able to help you tweak the database directly to let the upgrade work correctly.  Unfortunately, right now  I'm trying to fix my laptop as it crashed this morning and now h
<natefinch> as a ton of problems
<hackedbellini> natefinch: no problem :). It will be very nice if you can help me to tweak my database to make the upgrade work correctly! There's no problem that you don't have the time to do that right now, I can wait until you can.
<katco> thumper: hey do you have time to do a review on https://github.com/juju/juju/pull/398?
<katco> er i guess it's the middle of the night for him. who is the on-call reviewer?
<jcw4> katco: menn0 is the other one... probably not around either :)
<katco> jcw4: yeah... also out of NZ =/
<katco> hmmmm
<jcw4> natefinch is fighting HD issues... perrito666 or axw ?
<katco> axw is out of australia
<jcw4> dang
<katco> perrito666: is in the western hemisphere :) just very south of me!
<jcw4> :)
<jcw4> katco: the code looks pretty and well thought out, but I don't know much about the subject matter :/
<katco> jcw4: lol, well i at least appreciate the compliments. it was a team effort :)
<jcw4> :)
<marcoceppi> where is the event queue stored on the unit? is it in a data directory or in memory or?
<natefinch> marcoceppi, pretty sure we don't store anything on disk
<marcoceppi> natefinch: then where does the pending queues get stored?
<natefinch> marcoceppi, I sort of assumed we just snagged each one from mongo one at a time
<marcoceppi> natefinch: so it lives in mongo then?
<natefinch> marcoceppi, everything lives in mongo :)
<natefinch> marcoceppi, but I don't know for sure
<natefinch> I would look at the code, but my computer is currently hosed.
<wallyworld> sinzui: hey, can you remember how to deal with GhostRevisionsHaveRevNo errors when pushing a bzr branch?
 * sinzui thinks
<sinzui> wallyworld, It is a staking order
<wallyworld> sinzui: ok. katco did a go get in order to get trunk, then did a bzr branch and a commit, then pushed
<wallyworld> so maybe bzr checkout lp:golxc would have been better
 * katco mopes around looking guilty.
<waigani> thumper, menn0: what is the 'url' field in jenv for?
<wallyworld> although bzr merge lp:golxc said nothing to do
<wallyworld> maybe thumper knows
<thumper> wat?
 * thumper otp now
<sinzui> wallyworld, katco The problem is usually the project changed the default branch, but other branches weren't restacked
<sinzui> katco, I think you need to run
<sinzui> bzr reconfigure --unstacked
<sinzui> bzr reconfigure --stacked-on:lp:golxc
<waigani> juju destroy-environment local --force
<waigani> ERROR cannot read environment info for "local": error unmarshalling "~/.juju/environments/local.jenv": YAML error: line 138: did not find expected key
<waigani> line 138 is: url: ""
<wallyworld> sinzui: i just checked lp and katco's branch is there with the changes she did
<wallyworld> even though push failed
<wallyworld> "failed"
<sinzui> I think lp:~rogpeppe/golxc/golxc was the original trunk, then lp:~juju/golxc/golxc became trunk
<waigani> hmph, simply deleting that line allowed me to force destroy
<wallyworld> sinzui: the mp worked without any restacking :-) so the push error wasn't fatal as such. thanks for help.
<menn0> waigani: I've just had a quick look in to your url question
<menn0> waigani: that message is complaining that the .jenv has "url" in it but that isn't a known field
<menn0> waigani: if you look in environs/config/config.go you'll see that "url" isn't described there
<menn0> waigani: so the question really is: how did "url" get in that .jenv file?
<waigani> menn0: thanks. yes, indeed - that is what I'm trying to work out now.
<menn0> waigani: looking through recent-ish commits for config.go I don't see the "url" ever being defined
<menn0> s/ ever/ field ever/
<menn0> waigani: has the file been manually monkeyed with perhaps?
<waigani> menn0: I haven't touched it - promise!
<waigani> menn0: though I have been manually provisioning lxc containers and it seems to happen during that process ...
<waigani> menn0: just trying to reproduce it now
<menn0> waigani: ok. hope you figure it out.
<waigani> menn0: I'm about to attempt reproducing the bug that I *think* killed my network config over the weekend. If I go offline and miss our standup - that is why!
<menn0> waigani: ok :)
<waigani> menn0: okay this is really interesting. I manually provisioned the lxc, then destroyed it via lxc-destroy (i.e. not via juju). Now the network menu on the top bar of my desktop has disappeared.
<waigani> menn0: I'm guessing if I restart I will not be able to connect anymore
<menn0> and he's gone ...
<katco> wallyworld: privisioners_test.go failed but it looks unrelated. any objections to merging?
<wallyworld> katco: what was failure error?
<katco> error message didn't match; "Failed to get machine 1" vs "failed to get machine 0"
<wallyworld> ah, one of those map ordering ones
<wallyworld> yep, good to go
<katco> ahhh
<katco> ok pushing up now
<wallyworld> thanks, don't forget 1.20 :-)
<katco> starting with that :)
<katco> https://github.com/juju/juju/pull/410 if you're interested in LGTM
<katco> wallyworld: landed in v1.20
<wallyworld> \o/
<wallyworld> thanks
<katco> wallyworld: testing trunk
<katco> wallyworld: no problem!
<alexisb> wallyworld, when you have a moment I could use a few minutes of your time
<wallyworld> alexisb: sure, now?
<wallyworld> hangout?
<alexisb> sure, same as our 1xq
<alexisb> 1x1
#juju-dev 2014-07-29
<waigani> thumper, menn0: trunk also kills network. I've filed a bug: https://bugs.launchpad.net/juju-core/+bug/1349635
<_mup_> Bug #1349635: Destroying a manually provisioned lxc container breaks network configuration on host computer. <juju-core:Triaged> <https://launchpad.net/bugs/1349635>
<axw> waigani: agh, I got that too. I think worker/networker may be screwing with things that it shouldn't.
<axw> waigani: did you bootstrap your host?
<axw> I think that's what caused it for me.
<axw> pretty sure destroying a container has nothing to do with it
<waigani> axw: oh really?
<waigani> axw: so just "juju bootstrap" ?
<axw> waigani: bootstrapping the manual provider, yeah
<waigani> ha
<waigani> that's even worse
<axw> not entirely sure tho
<axw> I haven't attempted to narrow it down
<waigani> I have to put digging into it on hold for now
<wallyworld> thumper: can you mark bug 1349312 as in progress and assign it to someone so we can see it's being looked at?
<_mup_> Bug #1349312: Machine stuck in "down" state because "an upgrade is in progress" <cloud-installer> <landscape> <juju-core:Triaged> <juju-core 1.20:Triaged> <https://launchpad.net/bugs/1349312>
 * wallyworld bbiab
<davecheney> thumper: i've been trying to carve up my names change
<davecheney> but it's hard
<davecheney> state.FindEntity requires that we parse the tag to a Tag
<davecheney> and that needs to happen in every api call
<davecheney> and also every api call also calls a common.AuthFunc
<davecheney> so I can carve my change up into just the change to state.FindEntity which requires parsing in every api endpoint
<davecheney> or I can carve it up into a change to common.AuthFunc to take a Tag
<davecheney> there is a lot of crossover in each PR
<davecheney> maybe I should just keep it together in one
<davecheney> i'm down to a few failing tests in the ./apiserver/... packages
<davecheney> which are all symtoms of the same thing; returning an error that isnt common.ErrPerm
<davecheney> and I've mostly got those fixed
<wallyworld> katco: i moved you lxc card back to review until the merge to master is also done
<wallyworld> ie until both branches of the bug are marked fix committed
<davecheney> wallyworld: thumper axw https://github.com/juju/juju/pull/411
<davecheney> ^ this one is blocking my names branch
<axw> looking
<wallyworld> davecheney: i don't have enough context - are you going to add real authenticators later?
<axw> likewise
<axw> davecheney: is the intention not to assign something meaningful to getCanWrite/getCanRead?
<davecheney> axw: no idea
<davecheney> but that logic was a time bomb
<wallyworld> generally our api server endpoints need authenticators
<wallyworld> the ones there were placeholders for sure
<wallyworld> pending the real ones being added
<wallyworld> i'm not sure it's valid to remove them and all the associated logic
<wallyworld> maybe that's a question thumper needs to answer as you guys know the roadmap better than us
<davecheney> wallyworld: those checks are noops
<davecheney> when they are removed the code still passes
<wallyworld> sure, now they are
<davecheney> when they are not noop's someone can add them back
<davecheney> but right now they are actively doing the wrong thing
<davecheney> like authenticating invalid tags
<wallyworld> right now, they are saying "we do not offer authentication"
<davecheney> worse
<davecheney> "we say YES to anyone"
<davecheney> or anything
<davecheney> or ""
<davecheney> IMO they are worse than useless
<wallyworld> isn't this wip though?
<wallyworld> no one is using this yet
<davecheney> wallyworld: right, when they do we can revert this change
<davecheney> that is what source control is for
<davecheney> but given how much time we generall have to go back and clean up messes
<davecheney> i'd say the chances of that happening anytime this cycle are pretty low
<wallyworld> i guess i'm just not across the roadmap/plans for usermanager so can't really offer an authorative comment
<wallyworld> where's thumper when you need him
<davecheney> wallyworld: after a week in NZ with thumper
<davecheney> it'll be onxy doing the work
<davecheney> matty and green are moving back to the other thing they normally do
<wallyworld> sure, but maybe he plans to add authentication for usermanager next week
<wallyworld> that's the sort of planning i hav no visibility to
<davecheney> wallyworld: then we can revert this change then
<davecheney> but after spending a week in NZ with thumper
<wallyworld> if the code is removed, the behaviour is the same as now right, everything gets through?
<davecheney> i an pretty confident that we're not working on that next week
<davecheney> wallyworld: yes, the athentuication logic is currently hard coded to accept any string and give it the thumbs up
<wallyworld> so, why remove it? there's no change in behaviour after the removal, ahd the dummy auth is clearly labeled
<wallyworld> and avoids code churn
<davecheney> wallyworld: because the logic only athenticates tags, not username strings
<davecheney> the tag commonly passed by the api is invalid
<davecheney> but the logic doesn't check that
<davecheney> the dummy auth code is wrong
<davecheney> because it always says true to anything
<davecheney> even when it is an invalid tag
<davecheney> but agian, there are no tests to even check this
<davecheney> I want to remove this code, it was a mistake
<wallyworld> ok. so with the stuff removed, we will still allow invalid tags though just like now. why not jusy fix the dummy auth code?
<wallyworld> then everything that uses it will benefit
<davecheney> wallyworld: i am fixing it
<davecheney> this is pulled out of my larger strings -> names.Tag branch
<davecheney> do you want to review a 40 line change, or a 3,000 line change :)
<wallyworld> ah ok, sorry, as ai said, i have no contest for this
<wallyworld> context
<davecheney> s'ok
<davecheney> the problem is that an invlida tag shouldn't even make it this far into the api
<wallyworld> so long as "you" promise to fix it later, i'll got and +1 :-)
<davecheney> it's also complicated by the fact that the usermanager accepts both a username string and a tag
<davecheney> (a tag as a string that is)
<davecheney> yet, canRead/canWrite only validate the tag
<davecheney> which is completely broken
<davecheney> and only works currently because canRead("") returns true
<davecheney> even though "" is not a valid tag
<wallyworld> yeah, sounds messy
<davecheney> in summary, the logic is all fucked up and these dummy functions are actively not helping
<davecheney> so, out they go
<wallyworld> ok :-)
<davecheney> ta
<davecheney> anyone else for a second look ?
<davecheney> (i'll wait for thumper, he won't be far away)
<wallyworld> axw: got time to talk?
<axw> wallyworld: sure
<axw> tanzanite hangout?
<wallyworld> standup hangout
<wallyworld> yup
<thumper> davecheney: sup?
<davecheney> thumper: https://github.com/juju/juju/pull/411
<davecheney> ^ from my larger names change
<davecheney> see the pasionate discussion I put forth in the backscroll
<thumper> kk
<thumper> davecheney: in other words, it is big and very hard to break apart, so please review the big one?
<davecheney> no, bertter than that, please review this https://github.com/juju/juju/pull/411
<davecheney> which is a smaller one
<davecheney> which unblocks my larger one
<thumper> ack, will get food and look while munching
 * davecheney steps away from the keyboard
<wallyworld> thumper: after munching can we have a chat
<thumper> davecheney: I'm not sure about that change
<thumper> davecheney: sure, right now the authenticators do nothing
<thumper> but there is logic there for when we change them
<wallyworld> that's what wallyworld said :-)
<thumper> how does this unblock other work?
 * thumper reads more of the scrollback
<thumper> wallyworld: real authentication isn't slated for this cycle
<thumper> but will likely be the start of next
<wallyworld> ok, but i would have though we'd want *some* validity checks
<wallyworld> thumper: do you have time to talk now?
<thumper> wallyworld: sure
 * wallyworld creates hangout
<wallyworld> https://plus.google.com/hangouts/_/g5aavwaio7thqbiatwjbdtsdrma
<thumper> wallyworld: it says the party is over
<wallyworld> ffs
<wallyworld> https://plus.google.com/hangouts/_/canonical.com/tanzanite-stand
<davecheney> thumper: 1. the authenticators are wrong
<davecheney> they authenticate INVALID data
<davecheney> not just say yes to VALID users
<davecheney> 2. they arent' tested
<davecheney> this code passes 100% without them
<davecheney> that alone is reason to remove them
<waigani> thumper: can we do a hangout when you have a mo?
<davecheney> wallyworld: jcw4 just told me that the bot isn't runing gofmt checks anymore
<davecheney> jcw4: just pushed a branch to fix the problem
<thumper> waigani: sure...
<jcw4> davecheney: tx!
<waigani> thumper: https://plus.google.com/hangouts/_/gyvhagf6dafbd3piihpd5jtt5ia?hl=en
<wallyworld> davecheney: might not be, i'll check with martin
<davecheney> wallyworld: it used to do this
<davecheney> i wonder where that check was lost
 * davecheney ponders on the parable about the elephant and the piece of string
<wallyworld> totally different scripts
<wallyworld> we should be able to add it back in
<davecheney> wallyworld: eh ? the bot has nack'd changes before 'cos they aren't goformatted
<wallyworld> github lander or tarmac?
<davecheney> wallyworld: github
<wallyworld> hmmm, in that case i have no idea, i didn't realise it had changed
<wallyworld> seems like a mistake
<wallyworld> i'll get it fixed
<hazmat> is trunk broken?
<hazmat> hmm.. maybe a wierd cycle around updates, tags, and godeps
<voidspace> morning all
<hazmat> hmmm.. can't build 1.20.2 -> src/launchpad.net/gnuflag": bzr: ERROR: branch has no revision roger.peppe@canonical.com-20140716064605-pk32dnmfust02yab
<voidspace> I just did a pull and build ok
<axw> wallyworld: you're not planning on just changing the fslock code are you? I think you can only change the template management call site to use flock
<wallyworld> axw: yep, not changing fslock at all
<axw> cool
<wallyworld> just the template stuff
<axw> I think the charm locks need to outlive processes, but not entirely sure
<wallyworld> yep, just making minimal changes for 1.20
<fwereade> good mornings
<axw> morning
<TheMue> morning
<voidspace> fwereade: morning (from Romania)
<voidspace> TheMue: morning
<TheMue> voidspace: Romania?
<voidspace> TheMue: I'm in Romania for the next month
<voidspace> TheMue: it's where my wife is from
<voidspace> so I'm currently working from the balcony of a flat in the town where her parents live
<voidspace> Nice and sunny
<voidspace> TheMue: are you working on ipv6 container addressability?
<TheMue> voidspace: yep, Iâm getting closer
<voidspace> TheMue: can I help or should I pick something else up?>
<voidspace> either way I need coffee first
<TheMue> voidspace: in my scenario two hosts see each other, see the containers they run, those containers can see each other, but a container on one host doesnât reach a container on another host
<voidspace> ah, interesting
<voidspace> and confusing...
<TheMue> voidspace: hehe, yes
<TheMue> voidspace: will just update my doc with the latest scenario and share it with you then
<voidspace> TheMue: cool
<voidspace> I'm grabbing coffee - back in a bit
<TheMue> ok
<fwereade> voidspace, ah, nice
<fwereade> TheMue, would you describe your scenario a little more?
<fwereade> TheMue, AFAIK we haven't done the container-addressability work we'd need to get that working
<fwereade> TheMue, in MAAS it should work but not anywhere else
<TheMue> fwereade: currently itâs no development stuff, itâs simply the evaluation how an IPv6 network has to be configured to enable IPv6 traffic to/from/between containers
<fwereade> TheMue, what are you working against?
<TheMue> fwereade: in a first step against pure LXC. IPv6 is pretty new to me and Iâm reading/trying a lot. next step has to be discussed with jam then
<fwereade> TheMue, yeah, to me too :)
<TheMue> fwereade: sure ;)
<fwereade> TheMue, what's the end goal of what you're doing?
<TheMue> fwereade: currently a proof of concept for IPv6 and LXC
<fwereade> TheMue, because I thought that the first ipv6 use case we were targeting was about just managing ipv6 *and* ipv4 addresses in dual-stack networks
<TheMue> fwereade: later, as I understood jam, the active setting of addresses on any kind of nodes (hosts and containers)
<fwereade> TheMue, sorry, cannot quite parse, restate please?
<TheMue> fwereade: hehe, yip
<TheMue> fwereade: if I understood jam right he talked about a change where at least containers donât work with the address the infrastructure passes them (which is link-local) but ask the API for a public adress and use it
<TheMue> fwereade: hope I phrased it better now
<fwereade> TheMue, certainly, we will want that -- that's what I think of as "container addressability" and I agree it's important
<TheMue> fwereade: yep, thatâs how I understood it
<fwereade> TheMue, I'm not sure that doing it for ipv6 alone is quite what we're looking for at the moment though -- I thought we were aiming at working with dual-stack networks in situations that already work first of all
<TheMue> fwereade: detailed task planning is still open, as weâre only have been us two the last week
<fwereade> TheMue, I'm not trying to seagull you, don't let me stop you -- but... ah ofc dimitern is on holiday in malta, probably on a boat, can't ask him right now
<TheMue> fwereade: hehe, yeah, diving. he worked on the topic too before he left
<TheMue> fwereade: but jam will be back tomorrow, so you can talk to him then
<fwereade> TheMue, cool, thanks
<TheMue> fwereade: yw
<TheMue> fwereade: how has your trip been? stressful?
<fwereade> TheMue, new zealand is lovely, travelling there not so much
<fwereade> TheMue, not so stressful really
<fwereade> TheMue, I actually wrote some code which made a nice change
<TheMue> fwereade: but surely a very long flight
<fwereade> TheMue, yeah, pretty much all weekend both ways
<TheMue> fwereade: would like to visit NZ once too
<fwereade> TheMue, 2 full working weeks of travel in 1 week :/
<TheMue> fwereade: hard. with a stop in Hongkong or Singapure?
<fwereade> TheMue, dubai, bangkok, sydney, christchurch, dunedin
<TheMue> fwereade: ouch! so many? uuugh
<fwereade> TheMue, yeah, was a bit much :)
<fwereade> TheMue, at least I didn't have to stop in tripoli, which the original tickets had
<fwereade> TheMue, but emirates was kind enough to not send me through there while the airport was being actively bombarded
<axw> :o
<axw> stop over in libya, via ukraine
<TheMue> fwereade: eh, hey, it has been planned as a business trip, no adventure tour
<TheMue> axw: you forgot syria
<fwereade> haha
<voidspace> fwereade: you're in NZ now?
<voidspace> a sprint?
<voidspace> I understood the ipv6 work was to support our telco customer who required it
<voidspace> NZ is lovely, I was there last year. But I only explored the North Island.
<fwereade> voidspace, back now
<fwereade> voidspace, bit scrambled mentally still
<voidspace> fwereade: ah
<voidspace> fwereade: yeah, long journey. About as far as you can go in fact.
<fwereade> voidspace, yeah, which is why I raised a bit of an eyebrow at what TheMue was doing
<fwereade> voidspace, indeed :)
<voidspace> fwereade: ah right - because for that we need ipv6 support, but we don't yet need nested container support
<voidspace> hmmm
<fwereade> voidspace, I'd kinda expected that the ipv6 work that'd actually be delivering value is the stuff we talked about with jamespage and rbasak -- private-address and private-address-ipv6, and setting the right ones in the right situations
<voidspace> fwereade: that sounds right, although in an ipv6-only scenario I'd hope that juju would "just work"
<voidspace> if machines/providers report ipv6 addresses we use those without problem
<voidspace> and we've fixed some issues around that
<fwereade> voidspace, yeah, it turns out that what we actually need is dual-stack support for the relation addresses
<voidspace> (e.g. no longer explicitly dropping ipv6 addresses, passing the right flags to mongo)
<voidspace> fwereade: ok
<voidspace> and as you say, dimiterm is our real expert here
<voidspace> although I'd expect jam to be pretty clued up as to the roadmap
<fwereade> voidspace, yeah, mongo on ipv6is another of the details I keep forgetting about ;)
<voidspace> fwereade: that should be done
<fwereade> voidspace, brilliant
<voidspace> barring horrible mongo bugs - like the fact that mongo can't parse ipv6 addresses
<voidspace> :-)
<voidspace> so long as you stick to the format they don't manage to internally screw up you're alright though
<voidspace> (you must use ::1:port format, and not [::1]:port nor a bare address without a port)
<fwereade> eww :)
<bodie_> if anyone has a few minutes to rip up my code so I can make a semblance of usefulness tomorrow, would be much appreciated! https://github.com/juju/juju/pull/415
<bodie_> (4:30am est right now -- I need to sleep the sleep of the dead)
<voidspace> TheMue: you got the link to your doc?
<TheMue> voidspace: one moment
<voidspace> sure
<mattyw> morning folks
<voidspace> brb, back soon
<voidspace> TheMue: I may be a couple of minutes late to standup
<voidspace> TheMue: not long though
<TheMue> voidspace: weâre only we both ;)
<voidspace> TheMue: oh!
<voidspace> TheMue: where is jam ?
<TheMue> voidspace: national holiday
<voidspace> ah
<perrito666> good morning
<voidspace> perrito666: morning
<wallyworld> hazmat: you around?
<natefinch> whelp, it's gonna be another long day.  Had totally reinstall the OS this morning... recopying my home directory now, but hello reinstalling everything.
<perrito666> natefinch: ouch
<perrito666> for next time this happens, there is a dpkg invocation that might be of help there
<natefinch> in theory you should be able to reinstall on top of the old installation and it'll keep your home directory, but the installer said there was no OS installed, which is.... interesting
<natefinch> I think my OS was f'ed up somehow. No idea how, but if the installer can't even tell there's an OS there... something is pretty screwy
<natefinch> now I have to figure out if I overwrite all my dot files, if it'll muck up this install
<natefinch> current status: restoring my backed up trash folder.  Sigh.  I wonder how much of my backed up data is just filecaches, trash, and downloaded installers
<axw> wallyworld: running late again tonight. if you can hold off for 30 mins I can probably make the standup
<axw> otherwise: I did more mongo 2.6 stuff
<axw> couple of PRs in the queue
<wallyworld> axw: it's my wife's birthday today so i want finish the stand up and have a drink
<wallyworld> but any other time i could delay
<mgz> is katco on yet? we could do it early instead
<wallyworld> might be too early
<axw> wallyworld: fair enough :)
<natefinch> hey, reinstalling made workspaces work on my machine finally
<perrito666> lol
<natefinch> hopefully copying over all my dotfiles will mean I don't have to reconfigure everything to work the way it used to.... but I'm not too optimistic
<hazmat> wallyworld, am now
<wallyworld> hazmat: could you reply to the email about the api endpoint changes as per the bug you want backported?
<natefinch> like... how the hell do you turn off sound effects on Ubuntu?  That's always my first stop when installing Windows... turn off all the damn sounds.  Computers should be seen and not heard
<wallyworld> hazmat: i'm not 100% across the exact changes as i didn't do the work
<hazmat> wallyworld, sure
<wallyworld> ty
<perrito666> natefinch: which sounds?
<perrito666> natefinch: I think you installed the wrong OS :p
<wwitzel3> natefinch: dconf-editor will let you disable most sounds that annoy you.
<perrito666> wwitzel3: natefinch also there is a mute button :p
<natefinch> perrito666: the startup sound, for one.... there's also an annoy ploink sound that happens occasionally and I don't exactly know what causes it.
<natefinch> perrito666: mute only works so long as I don't actually want to hear music or videos or hangouts
<perrito666> you said you did not want to hear your computer :p
<wwitzel3> natefinch: /usr/share/sounds/ubuntu is where the files are, you can always just rename the ones you don't want with .mute
<voidspace> TheMue: I'd still love a link to your doc
<voidspace> TheMue: plus any suggestions as to what I might usefully work on
<natefinch> that's not the computer, that's media.  Things ploinking is hearing my *computer*
<voidspace> TheMue: none of the things in the kanban queue looked plausible for me to start
<TheMue> voidspace: you should have get a mail
<voidspace> wwitzel3: natefinch: morning from Romania
<voidspace> wwitzel3: natefinch: actualy 3:30pm more or less
<voidspace> TheMue: ah, ok - I'll check
<TheMue> voidspace: when I shared the doc with you
<voidspace> TheMue: thanks
<perrito666> hi voidspace, seems that moonstone in romania is becoming a trend :p
<wwitzel3> voidspace: o/
<natefinch> voidspace: howdy.... how was your vacation?
<voidspace> TheMue: hmmm... no
<voidspace> natefinch: EuroPython, it was cool
<TheMue> voidspace: currently I changed the setup below a bit
<voidspace> natefinch: lots of love for logstash backed by Elasticsearch for distributed logging
<wwitzel3> yeah, people love some ELK
<hazmat> wallyworld, also the fix in trunk for that issue is broken.. it turned a list into a scalar.
<hazmat> wallyworld, http://pastebin.ubuntu.com/7894639/
<katco> wallyworld: happy birthday to your wife!
<perrito666> katco: in my country that is practically an insult :p
<katco> perrito666: lol
<katco> all things are impermanent. no use in fighting it :)
 * perrito666 's chair armrest breaks apart while he was using it to get up and now he has 2 hurting fingers bc his hand landed on a very hard 5mm steel piece
<perrito666> that hurts
<katco> ouch =/
 * perrito666 tries to shop online for a chair not made of plastic
 * perrito666 fails
<perrito666> wallyworld: https://pbs.twimg.com/media/BtQnfw2CYAIh123.jpg
<katco> TheMue: you around?
<TheMue> katco: yep
<katco> TheMue: i've been tasked with backporting https://bugs.launchpad.net/juju-core/+bug/1311227
<_mup_> Bug #1311227: juju api-endpoints has no way to distinguish public and private addresses <api> <regression> <juju-core:Triaged by themue> <juju-core 1.20:Triaged> <https://launchpad.net/bugs/1311227>
<katco> just want to double-check; this looks like the PR for that? https://github.com/juju/juju/pull/208
<TheMue> katco: yes, exactly
<katco> TheMue: great, i'll cherry that and be on my way :) thank you!
<TheMue> katco: yw, itâs a small change
<TheMue> katco: it seems to need a change
<katco> TheMue: ?
<TheMue> katco: if I understand hazmat correct (see last comment), we have to return [0:1] instead of [0]
<TheMue> katco: so that the rendering as JSON or YAML would have the correct format
<TheMue> katco: see http://pastebin.ubuntu.com/7894639/
<katco> TheMue: ah. not sure what the thing to do is. wallyworld pretty urgently wanted this backported so we could cut 1.20.3
<katco> do we usually fix further bugs before backporting?
<TheMue> katco: the current change only returns one string, the former one returned a slice with one string
<TheMue> katco: in this case the renderings are different
<katco> TheMue: yeah i see that. so i guess you're saying we wouldn't want to backport before fixing this issue?
<TheMue> katco: I would change the backport in a way that it returns the slice and change the current trunk to it in a second issue for the 1.21 again
<katco> TheMue: gotcha. i'll see what i can do. thanks for the guidance :)
<TheMue> katco: has been an interesting feedback by hazmat for me too
<TheMue> katco: absolutely missed that beside the data we also changed the type and that this influences the rendering
<TheMue> katco: shall I quickly do the change on trunk?
<katco> TheMue: sure, if you feel like it! i'm still getting going (still earlyish here)
<TheMue> katco: ok
<katco> TheMue: sounds like it should be a 2-char change?
<TheMue> katco: exactly ;)
<hazmat> TheMue, correct
<hazmat> TheMue, katco as long as your doing that per state server
<hazmat> and extending the result slice
<TheMue> yep
<natefinch> sinzui: want to go to Romania?
<voidspace> I have somewhere to stay if you do...
<perrito666> sinzui: http://i1.kym-cdn.com/photos/images/facebook/000/001/384/Atrapitis.gif
<voidspace> hah :-)
<natefinch> perrito666: haha
<perrito666> sinzui: natefinch says you have to go see this guy http://upload.wikimedia.org/wikipedia/en/0/00/CountDracula6.jpg
<voidspace> TheMue: I *just* got an email saying you shared the doc with me :-)
<TheMue> voidspace: heya, only hours later
<voidspace> right :-)
<sinzui> perrito666, I understand Dracula's Castle is for sale. It could be a new Disney attraction
<TheMue> who is OCR today?
<perrito666> TheMue: fwereade
<voidspace> there are lots of "dracula's castle"
<TheMue> Iâve got https://github.com/juju/juju/pull/417, a quick change.
<TheMue> fwereade: ^^^
<perrito666> sinzui: if disney keeps buying things we will soon see a crossover of avengers + jedis vs vampires
<perrito666> natefinch: standup
<sinzui> :)
<voidspace> sounds fun
<natefinch> perrito666: thanks, one sec
<voidspace> although jedis plus vampires versus avengers maybe
<fwereade> TheMue, is that really addressing the bug? I'm not convinced it should be throwing away all the addresses
<fwereade> TheMue, it's definitely good that it's a list again, true
<fwereade> TheMue, but don't we want the public addresses for all the state servers?
<TheMue> fwereade: if I remember correctly we decided to do it this way because of the problems to determine which address is public and which not
<TheMue> fwereade: depending on the environment and its address range (e.g. in private clouds)
<fwereade> TheMue, dammit, do we still have addresses in state that don't know their scope?
<TheMue> fwereade: apiendpoint.Addresses simply is a string slice :(
<fwereade> TheMue, grar, ok
<katco> fwereade: TheMue: it sounds like there may be a larger issue here. just some context to try and represent wallyworld's request: i think he wanted this backported ASAP so we can do a cut on v1.20.3, so i think whatever is safe, but quick would be preferred.
<fwereade> katco, yeah, agreed, I just LGTMed it slightly grudgingly
<katco> fwereade: i know that pain! :) ty!
<fwereade> katco, we evidently should be storing addresses with a sensible scope in the first place, and I *think* that should be possible now
<TheMue> fwereade: yeah, I once started with a kind of filtering: https://github.com/TheMue/juju/commit/9dce055bac4eb3fa275a007584894eace0d82841
<fwereade> katco, modulo all the tedium of dealing with old API versions etc etc
<TheMue> fwereade: but then we had the discussion about it
<TheMue> fwereade: but storing the socpe directly with the address is better, yep
<fwereade> TheMue, we might not even need to do that client-side -- we could plausibly just make sure we only return addresses with a sensible scopein the first place
<perrito666> query fwereade
<perrito666> lol
<perrito666> that was /query
<TheMue> fwereade: sounds good, yes. are there cases a client could be interested in private addresses too?
<fwereade> TheMue, I fear that's not impossible -- in general I think we only know what addresses make sense if we know where people want to connect *from*
<TheMue> hmm, yeah
<rogpeppe1> fwereade: gentle ping re: my last suggestion for charm.URL vs charm.Reference in the juju-dev thread. We'd quite like to move forward with some solution.
 * fwereade looks back fretfully
 * TheMue just fetched a Ben & Jerryâs Chocolate Fudge Brownie against the warm weather
<fwereade> rogpeppe1, ah, hmm: I sorta see where you're coming from, but it also feels like most places should be parsing urls and only falling back to parsing references where that fails -- and that having a reference implies a separate code path that needs to better qualify the reference?
<fwereade> rogpeppe1, although, heh, a URL may itself want to be further qualified by looking up the best revision
<rogpeppe1> fwereade: anything that's a URL is also a Reference
<rogpeppe1> fwereade: but not vice versa
<rogpeppe1> fwereade: the case i'm specifically needing to deal with here is that we need to marshal and unmarshal series-agnostic URLs and there's no decent way of doing that currently
<fwereade> rogpeppe1, ok, that makes sense, I think
<rogpeppe1> fwereade: cool, thanks
<fwereade> rogpeppe1, I still feel there's something a bit off about having the same type underneath -- would it make sense to you to define them separately?
<rogpeppe1> fwereade: i don't really see why that's useful
<fwereade> rogpeppe1, I'm more concerned that reusing the same structure for two different purposes is turning a coincidental similarity into something more
<rogpeppe1> fwereade: it's surely not a coincidental similarity
<fwereade> rogpeppe1, "coincidental" is slightly too strong a word, true...
<rogpeppe1> fwereade: and in fact redefining the fields is exactly equivalent
<fwereade> rogpeppe1, I'm mostly nervous I'll see people casting between them
<rogpeppe1> fwereade: they can do that even if the fields are separately defined
<fwereade> rogpeppe1, so they can
 * fwereade shudders gently
<fwereade> rogpeppe1, ok, consider objections withdrawn
<perrito666> fwereade: can I get a moment of you in hangout?
 * perrito666 irq's
<rogpeppe1> fwereade: thanks
<katco> rogpeppe1: hey you maintain godeps, right?
<rogpeppe1> katco: i do
<fwereade> perrito666, yeah, set one up, with you in 3-4 mins
<rogpeppe1> katco: and i'm aware it has a rather annoying bug with godeps -u currently :-)
<katco> rogpeppe1: could i request that in the event of an error, it return an error code to the shell? :)
<rogpeppe1> katco: it *should* do :-)
<rogpeppe1> katco: can you provide a repro case?
<katco> rogpeppe1: hm let me see
<perrito666> fwereade: https://plus.google.com/hangouts/_/g4hpll6qr6xz4jfhqotbeap4dua
<rogpeppe1> katco: it looks to me at a quick scan that it's doing it ok
<katco> rogpeppe1: same here. i ran into something last night... i'll let you know if it's repro or not :p thanks :)
<rogpeppe1> katco: np
<perrito666> ericsnow: ill go back to restore, let me know if you need anything else from me
<ericsnow> perrito666: will do
<katco> TheMue: ty for landing that so quickly! backporting now :)
<TheMue> katco: yw, youâve seen itâs only a quick and dirty fix
<katco> TheMue: i think that actually might be best case in this situation.
<katco> TheMue: just b/c of the urgency of cutting v1.20.3
<TheMue> katco: yes, here a better solution would last too long
<katco> TheMue: (putting 3 years of german class to work): danke!
<TheMue> katco: wunderbar :D
<katco> TheMue: haha
<TheMue> h5
<bodie_> good morning #juju-dev :)
<katco> good morning bodie_
<katco> TheMue: i'm still relatively new to backporting w/ git.. do i cherry all the commits in your PR in order? or can i just do the last one in the original PR?
<TheMue> katco: I have to admit, Iâve so far never tried it.
<TheMue> katco: surely somebody else has more experience here
<katco> TheMue: ok, thanks :) i'll see what google has to say in addition
<katco> TheMue: i suppose this is a use-case for squashing
<perrito666> ok, question to all:
<perrito666> I have a file on a client machine and want to get it into environ storage, what is the preferred way to get there
<perrito666> ?
<gsamfira> katco: here's a great article about cherry-picking: http://wiki.koha-community.org/wiki/Using_Git_Cherry_Pick
<katco> gsamfira: ty! i'll give it a read
<gsamfira> my pleasure :)
<katco> mgz: not entirely sure this CI failure is b/c of my code. can you have a look? http://juju-ci.vapour.ws:8080/job/github-merge-juju/154/console
<katco> i'm going to resubmit in the meantime...
<bodie_> katco, something I like to do is just rebase on master to get my commits to the top of the pile, then merge to the branch I'm trying to land
<bodie_> then rebase -i against master, and fixup all but the top commit, reword that one
<bodie_> not sure if that's what you're looking for, but it's pretty clean
<bodie_> that's something I've learned since working on this project, I always used to simply merge, but I think it makes for a very usable log
<bodie_> of course, you might be talking about a completely different use-case for git, in which case feel free to pipe this to /dev/null
<katco> bodie_: thanks for the tip! in this case i'm trying to go from master -> backport branch.
<katco> bodie_: cherrypick works just fine for me, the thing i'm wondering about is if there's a way to grab an entire PR instead of cherry picking all the discrete commits in PRs
<bodie_> I imagine the best way would be to cherry-pick <old hash>..<new hash> assuming the ones you want are in a continuous range
<bodie_> if they're not, perhaps do it anyway and rebase -i simply deleting the undesired entries
<bodie_> although
<bodie_> you can checkout pr's
<bodie_> but that's kind of hacky and ugly and makes your fetches enormous
<bodie_> at least, the way I have it set up
<bodie_> ymmv
<bodie_> https://gist.github.com/piscisaureus/3342247
<bodie_> apparently there's also this
<bodie_> https://help.github.com/articles/checking-out-pull-requests-locally
<bodie_> if you don't want to permanently add the ability
<katco> hey cool :)
<katco> bugger... CI is going to fail again looks like. mgz are you there?
<mgz> katco: am now, but it's not the end of the world to let a failing run just complete
<katco> mgz: yeah, just wondering why it failed. i do see some kvm stuff in there now i'll have to look at after i land this backport
<katco> initially i saw a bunch of mongo stuff: PANIC: action_test.go:1: MachineSuite.TearDownTest
<katco>  
<katco> ... Panic: Cannot drop MongoDB database juju: local error: bad record MAC (PC=0x4144D6)
<katco> http://juju-ci.vapour.ws:8080/job/github-merge-juju/154/console
<mgz> that's a know intermittent thing, but there's also a nill deref in kvm BrokerSuite?
<katco> yeah, have to look at that. i didn't touch the brokers, but it's probably related to my changes somehow
<mgz> katco: just see if you can repo locally first, you also have the second run to compare with
<katco> mgz: will do, thanks. working on some other test failures in this backport =/
<fwereade> katco, we're pretty sure the "bad record mac" stuff is a mongo 2.4 bug -- if you're seeing it against 2.6 that's worth making noise about
 * fwereade supper
 * perrito666 supra 
<perrito666> man, that was a better joke in my head
<jcw4> perrito666: lol
<perrito666> sinzui: I submitted a fix for https://bugs.launchpad.net/juju-core/+bug/1342937 and its merged :(
<_mup_> Bug #1342937: Juju restore  fails Could not get lock /var/lib/dpkg/lock <backup-restore> <ci> <regression> <juju-core:Triaged by hduran-8> <https://launchpad.net/bugs/1342937>
<sinzui> perrito666, update the bug to fix committed
<perrito666> ah apologize, I forgot that does not happen anymore
<sinzui> perrito666: I miss that feature too
<perrito666> there, changed and sent a mail in response
<katco> how do i connect to juju's mongo instance using the mongo shell? i do mongo localhost:37017, but i receive "Error: DBClientBase::findN: transport error: localhost:37017 ns: admin.$cmd query: { whatsmyuri: 1 } at src/mongo/shell/mongo.js:147
<katco> exception: connect failed"
<sinzui> katco, juju-db doesn't have js support
<jcw4> katco: one thing I've found is that to connect you need to specify --ssl
<katco> jcw4: that worked, thank you :)
<jcw4> but I actually haven't figured out how to connect to juju mongo and actually poke around in the collections... did you get that far?
<jcw4> I always get authentication issues and I haven't figured out the incantation yet
<katco> sinzui: so how do i explore juju's mongo instance? are you saying it doesn't support the mongo frontend? sorry, i'm pretty unfamiliar with mongo
<natefinch> perrito666: ^^
<katco> jcw4: obviously not :p
<jcw4> katco: lol
<natefinch> perrito666: didn't you document how to log into mongo somewhere?
<katco> i try to issue show dbs and get "listDatabases failed:{ "ok" : 0, "errmsg" : "unauthorized" } at src/mongo/shell/mongo.js:46"
<katco> i mean it looks like mongo is a js shell, so i surmise that it won't work at all b/c of sinzui's statement, but i thought that was the canonical way to talk to a mongo instance...
<katco> i didn't know there was another way
<jcw4> katco: that's what I would expect too... I'm hoping perrito666 did indeed document the right way
<jcw4> sinzui: do you mean that connecting to juju mongo using the standard mongo cli doesn't work?
<sinzui> jcw4, that's right. I think the "mongo" command is crippled because it is backed by webkit js engine that wasn't compiled with juju-mongo
<jcw4> sinzui: oh, very interesting.  Is there a 'right' way to poke around in mongo then or do you have to write code to do that always?
<sinzui> jcw4, I think it is code. I don't have any experience hacking a working juju-db.
<jcw4> sinzui: tx
<katco> ugh
 * katco wonders how she's going to debug this test failure
<katco> ... Panic: watcher iteration error: not authorized for query on juju.txns.log (PC=0x40EF8D)
<jcw4> katco do you have the link to the full log? Is it a recent build in jenkins?
<katco> jcw4: https://pastebin.canonical.com/114411/
<katco> jcw4: it's a local test failure; trying to backport a modification
<natefinch> friggin' a.... backing up my home directory removed the execute bit from all any applications that happened to be in there
<natefinch> well, backing up and restoring
<jcw4> katco: I'm an external contractor, I don't think I have access to that pastebin
<katco> natefinch: i think you could write a very short script to do a "file"
<jcw4> I'm just wondering if it's a transient issue or a consistently reproducable issue
<katco> natefinch: and chmod +x to any ELF binaries
<katco> jcw4: try this: http://pastebin.com/4S4mwBzE
<katco> jcw4: i'm pretty sure it's not transient given these changes are in the stack of the panics
<katco> jcw4: but i'm new, so i'm also pretty sure i'm wrong often :)
<jcw4> katco, i see :)
<jcw4> katco: Panic: cannot share a state between two dummy environs; old "dummyenv"; new "dummyenv" (PC=0x40EF8D)
<jcw4> katco: is it possible you're inadvertently spinning up two instances of the dummy environment?
<katco> jcw4: you know i forgot, i think it's recommended to run on only 1 cpu
<jcw4> katco: oooh... maybe two tests are running concurrently and stepping on each other
<katco> jcw4: right
<katco> attempting again!
<katco> jcw4: however, that first error doesn't seem to be related to that, does it?
<katco> "not authorized"?
<jcw4> katco: I wonder if the authorization was for one env, and failed against the other
<jcw4> dunno if auth is generated per-env
<katco> jcw4: well, i suppose i'll just see what running on 1 cpu does for me.
<jcw4> fun
<katco> i completely forgot about that
<katco> curse my extra cores! curse them!
<jcw4> haha
<perrito666> natefinch: I documented many things but not how to log into mongo
<perrito666> yet
<perrito666> mongo -u <machine-tag> -p <statepassword> host:port/juju
<perrito666> is simple enough to remember
<perrito666> or mongo -u admin -p <oldpassword> host:port/admin
<jcw4> perrito666: I think the <machine-tag> was the part I was missing
<perrito666> which might or might not work
<jcw4> I don't think the -u admin works, but I may have been using the wrong <oldpassword>
<perrito666> you might, that changes
<perrito666> anyway, bike time, bbl
<jcw4> perrito666: have fun
<katco> jcw4: fyi, this run seems to be going _quite_ a bit more smoothly.
 * jcw4 crosses his fingers
<katco> what is <machine-tag> in the above example?
<jcw4> katco: not sure... I've tried "0", "machine-0", "machine/0" to no avail, but I might be using the wrong password too... I
<jcw4> I'm grepping the password from the local.jenv file
<jcw4> I got those id's by taking the output of 'juju status', and inferring possible tag prefixes for the 0th machine
<katco> https://github.com/juju/juju/pull/419 for backport to v1.20
<katco> jcw4: same.
<jcw4> ah!
<jcw4> katco: maybe ~/.juju/local/agents/machine-0/agent.conf
<katco> jcw4: checking...
<jcw4> katco: bingo!
<jcw4> grr... show collections gets the next error: not authorized for query on juju.system.namespaces
<jcw4> :)
<katco> huh, so this is still failing for me: "mongo -u=machine-0 -p=<statepassword> localhost:37017/juju
<katco> oh shoot forgot ss
<katco> ssl
<jcw4> katco: I also just used spaces instead of =
<jcw4> dunno if that makes a difference
<jcw4> brb
<katco> well now i get login failed. hm
<katco> there we go!
<katco> jcw4: but yes, get same error
<katco> so it looks like my changes are failing because machineConfig did not have a environs/config/Config... will that ever occur? should i fix the tests, or change my code to account for possible nil Config values?
<natefinch> I think that should be impossible
<katco> natefinch: ty, nate. so fix the test(s)?
<natefinch> yeah.... are these tests you wrote?  if not, why are they failing now, just you using a value that wasn't used before?
<katco> they are not. worker/provisioner/kvm-broker_test.go
<katco> they are failing now b/c i introduced a change in kvm.go to look at machineConfig.Config.ImageStream()
<katco> and apparently these tests don't set up machineConfig.Config
<natefinch> Yeah, that's kind of the problem with our tests... we mock out enough to get the code to pass, but if you deviate from what's mocked out, things explode
<natefinch> so, yeah, need to set up a machine config
<katco> natefinch: mocking more than 1 level is a smell i think. you end up with tests that are very tightly coupled to your exact implementation which defeats the purpose of mocking =/
<natefinch> yeah..... a *lot* of our tests are that way, unfortunately
<katco> i would like to have this very interesting discussion with juju-dev, but i need to be less new.
<natefinch> heh yeah
<natefinch> me too ;)
<katco> right now i'm just breaking all the things :) and drinking from the firehouse, and using a bunch of colloquialisms
<natefinch> heh... and typoing them in interesting ways
<katco> natefinch! a hacker never typos. she types exactly what she means, when she means to say it! (name that movie)
<sinzui> katco, I am sorry https://bugs.launchpad.net/juju-core/+bug/1350011
<_mup_> Bug #1350011: lxc deploys broken on precise <ci> <local-provider> <lxc> <precise> <regression> <juju-core:Triaged> <juju-core 1.20:Triaged> <https://launchpad.net/bugs/1350011>
<jcw4> katco: a wizard?  I dont' know why I heard Morgan Freemans voice, even though it was Gandalf's face
<natefinch> gandalf sounds right
<natefinch> never late
<natefinch> that's what it is
<jcw4> that's it
<katco> sinzui: i see from the error message that this contains the fix i put in last night. how would i tell that from the meta data?
<sinzui> katco, which metadata? the jenkins tests?
<katco> sinzui: well, from the launchpad bug. is there a way i would know that this was tested on the latest trunk?
<sinzui> katco, no, since trunk changes many times a day
<katco> sinzui: ah ok. how did you tell?
<katco> sinzui: where the break occurred?
<sinzui> katco, I forgot to include the links to the test and the specific runs, which include the branch and commit hashes
 * sinzui adds them
<katco> sinzui: ah ok. sorry, trying to generalize on how i would troubleshoot if the comments weren't so good.
<sinzui> katco, on day I will have time to make reports.vapour.ws show all the interesting logs, artefacts, and results for each run against stable and devel
<katco> sinzui: :)
<natefinch> sinzui: what's up with the domain name vapour.ws anyway?
<sinzui> natefinch, I could afford it :)
<natefinch> sinzui: my guess was actually going to be "it was cheap"
<sinzui> natefinch, clouds are made from vapour.
<natefinch> ahh yes
<perrito666> katco: machine tag is, in the case of machine 0 machine-0
<katco> perrito666: ty, sir. jcw4 and i figured it out, but were unable to do anything useful once connected.
<katco> perrito666: turns out my errors were due to running tests in parallel anyway.
<ericsnow> what would be a better place to store JSON metadata for backup archives (themselves stored in env storage): state or env storage?
<perrito666> katco: you need to do db.GetDatabase("juju") iirc
<katco> sinzui: what's the easiest way to get a man page on that version of lxc-start?
<katco> sinzui: nm got it
<katco> this version of lxc-start doesn't have a --version tag. hm.
<katco> * flag
<katco> need an opinion here. would it be stupid to query dpkg for the version of lxc?
<natefinch> yes
<natefinch> but also might be the only way
<natefinch> unless we can do one of those "if it doesn't have --version, then we know what version that is"
<katco> natefinch: blech
<katco> natefinch: why is querying dpkg bad?
<natefinch> just adds a dependency.... it's not really that bad
<katco> do we run on other nixes w/o dpkg?
<katco> natefinch: ^^^
<katco> natefinch: being that this is specifically for lxc
<natefinch> back up a sec... why do we care about the version?
<katco> natefinch: started with this  https://bugs.launchpad.net/juju-core/+bug/1348386
<_mup_> Bug #1348386: lxc template fails to stop <clone> <lxc> <juju-core:Fix Committed by cox-katherine-e> <juju-core 1.20:Fix Committed by cox-katherine-e> <https://launchpad.net/bugs/1348386>
<katco> natefinch: tanzanite had the idea to sniff the version to change what flag we use to pass a console-file
<natefinch> how about trying -L and if it fails, try -c?
<natefinch> and I agree with Tim, using the long flags in code is better than the short flags... less possibility for confusion
<katco> that idea came up too. i think the downsides were: 1) there's no way to distinguish between -L not existing and something else going wrong, and 2) conditionals by error = bad
<katco> natefinch: also, the long-names are different b/t versions as well
<natefinch> I think conditionals by error = good a lot of the time.  Instead of guessing if something will work, just try it.
<katco> natefinch: that is so expensive
<natefinch> katco: right, but --console is much less likely to get reused as something else than -c
<natefinch> katco: sometimes, and sometimes it's just the flag parser that'll bail early :)
<katco> natefinch: ah, no what i meant is: what if the file isn't there, what if the shell couldn't fork a process
<katco> natefinch: we don't know if it failed for that specific reason, or one in the set of all possible reasons
<natefinch> katco: yes, it's true... due to the nature of command line applications, it's hard to determine if the error is the one we think it is
<natefinch> katco: grep the help text? :)
<katco> natefinch: exit codes are supposed to solve that
<natefinch> katco: if anyone ever returned something other than 0 or 1 :)
<katco> natefinch: https://yourlogicalfallacyis.com/bandwagon
<natefinch> haha
<ericsnow> natefinch: you have an opinion on my question about backup metadata?
<katco> i love that webpage :)
<perrito666> natefinch: review backup?
<perrito666> :)\
<katco> bringing in dpkg does seem heavy, maybe failing is the way to go here
<katco> have to get wallyworld's opinion when he gets on
<natefinch> ericsnow: putting the metadata in state is the whole point, isn't it?
<ericsnow> natefinch: the names at least
<ericsnow> natefinch: is there any advantage to storing the metadata in env storage?
<natefinch> ericsnow: not really... env storage is just a place for blobs we don't want to burden the database with.... I think
<ericsnow> natefinch: yeah, I guess that is my big question :)
<natefinch> perrito666: I can review tomorrow, trying to get the windows nonce bug fixed... but there's tendrils of the code friggin everywhere
<sinzui> katco, sorry, I was in a meeting. I have an precise lxc that I often use to lookup what precise uses.
<katco> sinzui: no worries, thanks for getting back. i ended up downloading the deb and extracting the man page.
<natefinch> I have a precise vm for that, too
<katco> sinzui: so another question: did an official build go out w/ that change in place, or was someone just testing trunk?
<sinzui> katco, every change to devel or stable is tested at juju-cu.vapour.ws. It does both integration testing, and unit testing against all supported architectures and series
<katco> sinzui: ah ok. good to know that wasn't actively affecting anyone.
<sinzui> katco, CI just saw the changes to 1.20 then master, ran the tests, and sent me email to investigate
<katco> sinzui: very nice. glad our process caught this :) thank you for your efforts
<thumper> alexisb: morning, got a few minutes?
<wallyworld> katco: hiya, just read backscroll. well this sucks. i don't want to use dpkg because centos etc. imo best choice (out of a bad bunch) is to run --version and if that fails, we know version < 0.7 or whatever. we really do want to sniff the version and make a decision on that, cleanest approach. so all we're doing is tweaking the current implementation to makde the version detection more robust; all we care about is the binary choice
<wallyworld> whether version > 0.8. a single call to lx-start --version gets us that knowledge even when that call fails because --version doesn't exist
<katco> wallyworld: sounds good, almost ready for a review (i implemented the dpkg version first just in case)
<wallyworld> sorry :-(
<wallyworld> katco: also, is there an update on the backport of the api endpoints fic from master?
<katco> wallyworld: no worries. that was the harder of the 2; wanted it ready in case you wanted to go that route. the failure version is easy
<wallyworld> katco: do you agree with my reasoning?
<katco> wallyworld: yes, https://github.com/juju/juju/pull/419
<wallyworld> great thanks, looking
<katco> wallyworld: yeah absolutely. i didn't know if we were on any non dpkg systems
<wallyworld> not yet but real soon now
 * katco cheers
<waigani> morning all
<wallyworld> katco: we may need to tweak it, did you see the extra emails in canonical-juju? seems we need to output the address as a list
<wallyworld> katco: if you're at EOD, I can pick it up
<waigani> menn0, when you have a mo, can we do a hangout?
<katco> wallyworld: i still don't think i'm on canonical-juju :(
<menn0> waigani: yep. give me a few minutes - I'm in the middle of something
<wallyworld> katco: ah, bollocks, ok. i did ask. i'll follow up, sorry
<waigani> menn0: all good. Just ping me.
<wallyworld> katco: i forwarded the email
<katco> wallyworld: err... only flaw in that proposal is that the absence of --version does not correlate with the change in -c to -L. e.g.: 1.0.0~alpha1-0ubuntu14.1~ubuntu12.04.1~juju1 does not have --version, but does have -L
<katco> wallyworld: ty, sir
<wallyworld> katco: ah, ok, i was assuming not having --version was an early version thing
<katco> wallyworld: apparently not =/
<katco> wallyworld: you may as well pick this up, i am at EOD and need to eat etc.
<wallyworld> katco: so do we know if 1.0.0 alpha has an equivalent flag to --version?
<wallyworld> sure
<katco> wallyworld: no it does not. i'll post the man for easy reference
<thumper> wallyworld: katco: lxc doesn't have a version
<menn0> thumper: since I'm looking at bug 1349312 already should I assign it to me or would you prefer someone else looks at it?
<_mup_> Bug #1349312: Machine stuck in "down" state because "an upgrade is in progress" <cloud-installer> <landscape> <juju-core:Triaged> <juju-core 1.20:Triaged> <https://launchpad.net/bugs/1349312>
<wallyworld> wot
<wallyworld> lxc-start --version
<wallyworld> 1.0.4
<thumper> wallyworld, katco: I was talking with hallyn about this, and the easiest thing for us to do would be to try with "--console-log" and if lxc errors with rc=1, try with "--console"
<katco> wallyworld: i just emailed you the manpage from precise
<wallyworld> thumper: out thinking was rc=1 sucks because that could be any error
<thumper> could be
<menn0> wallyworld: older versions didn't support --version
<wallyworld> menn0: yes, but sadly it doesn't correspond to the switch to use -L which we were hoping for
<wallyworld> thumper: also, if rc=1, does that guarantee that lxc-start hasn't actually start something
<wallyworld> because i think the container is actually started
<wallyworld> otherwise local provider would be totally broken
<thumper> nah...
<thumper> here is what is happening
<wallyworld> so we can't just call it twice
<thumper> we say: -c path/to/file
<menn0> wallyworld, katco, thumper: I'm beginning to doubt myself about --version. It's not mentioned on the man page for the 1.0.4 but does work.
<menn0> maybe it works for the older versions too but isn't documented
<thumper> lxc goes, "that isn't a device, I'll ignore it"
<thumper> and continues
<thumper> that is different to say "--console-log=path/to/file"
<thumper> as old lxc goes "I dunno what you mean there"
<thumper> immediately
<thumper> and doesn't try to start
<wallyworld> ah, good
<thumper> I tested that locally
<wallyworld> thumper: and that would be the same for -L
<thumper> yes
<thumper> but please use long opts
<thumper> I should have originally
<wallyworld> ok
<wallyworld> katco: sounds like we have our solution
<katco> menn0: i did not test it empirically, but this error wouldn't have occurred if it was supported (unless it's some other error that is rc=1 per wallyworld's earlier comment)
<katco> wallyworld: just try it 2x?
<wallyworld> katco: yeah, try --console-log first
<thumper> katco: I'd say "try with --console-log first"
<thumper> and if that fails, just try with "--console"
<wallyworld> and if rc=1, fallback to --console
<katco> will do
<thumper> wallyworld: good to see we agree
<thumper> :)
<wallyworld> yep :-)
<wallyworld> thanks for clarifying
<katco> wallyworld: thumper: the both of you are wrong! wrong i say!
<wallyworld> :-P
<thumper> I have another lxc based message coming to -dev soon
<thumper> katco: wrong why?
<katco> i hope that makes you two feel better ;)
<katco> thumper: i'm just joking
<thumper> ok
 * katco has an odd sense of humor
<thumper> I've already copped a lot of wrong this morning
<wallyworld> katco: you need to eat - are you ok to fix the lxc thing or did you want to EOD?
<menn0> but wait: has anyone tried --version with an older lxc-start
<menn0> ?
<wallyworld> thumper: i knew she was joking :-)
<menn0> it might just work despite not being on the man page
<katco> wallyworld: i can probably get this in rq... easy fix
<thumper> menn0: I bet --version came in at a different time to --console-log
<katco> wallyworld: actually... might take longer to push to launchpad lol. maybe you should do this to get it out
<wallyworld> menn0: i think thumper is right
<thumper> menn0: I don't know, but guessing
<wallyworld> katco: ok
<menn0> but if --version has always been there then we can just use that right?
 * thumper looks in precise
<wallyworld> katco: i've not heard anything from mgz about the flock stuff, have you?
<katco> wallyworld: i have not
<wallyworld> ok
<katco> menn0: i did not test it empirically, but this error wouldn't have occurred if it was supported (unless it's some other error that is rc=1 per wallyworld's earlier comment)
<katco> menn0: the --version flag i mean
<katco> menn0: here is the entirity of the function that's failing: // Returns the lxc-start version
<katco> func lxcStartVersion() (string, error) {
<katco> 	version, err := exec.Command("lxc-start", "--version").Output()
<katco> 	return string(version), err
<katco> }
<katco> ok have to EOD... wallyworld email if you need anything; i have my phone
<wallyworld> np, thank you
<katco> wallyworld: ty
<thumper> so at least lxc in default precise (0.7.5) has no --version on lxc-start
<wallyworld> thumper: since we can't conclusively correlate addition of version with support for console-log, seems easiest just to check rc value
 * thumper nods
<thumper> seems reasonable for now
<menn0> wallyworld, thumper, katco: yep that sounds right
<menn0> sorry for the noise
<wallyworld> menn0: no problem at all, appreciate the input
<menn0> better to check for the actual functionality
<wallyworld> menn0: *if* --version were universally supported, we could have version sniffed
<wallyworld> since we know the version where --console-log was introduced
<menn0> now thumper what about bug 1349312? who do you want to own that? I've started looking at it but I'm pretty sure it's a dup of bug 1318366 which looks serious and horrible.
<_mup_> Bug #1349312: Machine stuck in "down" state because "an upgrade is in progress" <cloud-installer> <landscape> <juju-core:Triaged> <juju-core 1.20:Triaged> <https://launchpad.net/bugs/1349312>
<_mup_> Bug #1318366: jujud on state server panic misses transaction in queue <cloud-installer> <landscape> <orange-box> <panic> <performance> <sm15k> <juju-core:Triaged> <juju-core (Ubuntu):Triaged> <https://launchpad.net/bugs/1318366>
<menn0> I'm happy to keep looking to make sure it's a dup (should know with 20 more minutes of investigation) and mark it as such.
<wallyworld> menn0: thumper: can i assume you guys are focusing on working that bug to completion?
<wallyworld> its critical we get 1.20 shipped
<thumper> wallyworld: let me look first
<wallyworld> ok, let me know
<thumper> menn0: hangout to chat through this?
<menn0> thumper: yep
<menn0> waigani: will catch you after this hangout with thumper
<waigani> menn0: no rush, I've ventured down another rabbit hole in the mean time...
<thumper> menn0: https://plus.google.com/hangouts/_/gxnmnjsipg4yzjyqf5hat2iogqa?authuser=1&hl=en
<perrito666> menn0: hey, have a sec
<perrito666> ?
<menn0> perrito666: otp
<waigani> menn0: don't worry about catching up with me anymore
<perrito666> wallyworld: I am supposed to tell you something as per what I talked to fwereade this afternoon but I forgot
<wallyworld> perrito666: o/
<wallyworld> \o/
<perrito666> and I actually began taking notes whith a pen like the the red one here http://image.made-in-china.com/2f0j00ICetapBdaMuT/Finger-Pen-BKST08-.jpg which usually means I will remember
<perrito666> it was something about envstorage
<perrito666> and restore
<ericsnow> perrito666: how to upload an archive into env storage?
<perrito666> ericsnow: no, I pretty much figured that out
<ericsnow> perrito666: oh, cool
<waigani> thumper: hangout when you have a mo?
<waigani> thumper: tests fail with this: http://pastebin.ubuntu.com/7898958/ because  provider/dummy/environs.go:711 says environ is not bootstrapped
<waigani> thumper: even though we are calling environs.APIInfo() at the end on cmd/juju/bootstrap.go.Run
<waigani> thumper: note that live testing works, this is just a problem with the dummy provider
<waigani> thumper: so my question is, when does provider/dummy/environs.go.Bootstrap() get called? It needs to be executed before we can call environs.APIInfo()
<bodie_> hey guys -- quick question.  can you point us in the right direction to demo a custom charm with some bits and pieces we've added?
<bodie_> it should be as simple as adding a subdir and a couple of files
<waigani> thumper, menn0 standup?
<thumper> waigani: coming
<jcw4> marcoceppi: is charm-tools on github the correct repo to get charm-tools from?
<jcw4> marcoceppi: https://github.com/juju/charm-tools
<alexisb> thumper, I am here now
<alexisb> if you are available
<thumper> alexisb: can we chat after the standup?
<alexisb> sure
<alexisb> ping me when you are done
<marcoceppi> jcw4: no. Lp is the source
<jcw4> marcoceppi: tx
<marcoceppi> jcw4: I'll start mirroring again
<waigani> davecheney: what is the 'race runtime'?
<davecheney> waigani: http://blog.golang.org/race-detector
<waigani> davecheney: cool, thanks
<jcw4> marcoceppi: on a related note - https://github.com/juju/docs/pull/134
#juju-dev 2014-07-30
<marcoceppi> jcw4: LGTM, thanks
<jcw4> marcoceppi: cool
<waigani> thumper: dummy.Bootstrap sets a bool: estate.bootstrapped = true. dummy. dummy.StateServerInstances errs after checking that bool:
<waigani> if !estate.bootstrapped {
<waigani> 		return nil, environs.ErrNotBootstrapped
<waigani> 	}
<waigani> thumper: so, I don't see how writing the bootstrap IP to storage will change estate.bootstrapped?
<menn0_> perrito666: sorry... it's been a crazy morning. are you still around?
<wallyworld> thumper: if you have a moment, https://code.launchpad.net/~wallyworld/golxc/lxc-console-log/+merge/228778
<davecheney> waigani:   * for i in `seq 0 4`; do juju deploy trusty/ubuntu --to lxc:0 trusty; done;
<davecheney> sorry
<davecheney> wallyworld:
<davecheney>   * for i in `seq 0 4`; do juju deploy trusty/ubuntu --to lxc:0 trusty; done;
<davecheney>   * for i in `seq 0 4`; do juju deploy precise/ubuntu --to lxc:0 precise; done;
<davecheney> ^ from dpb's email
<davecheney> this will result in a broken juju
<davecheney> what he means to do is juju deploy trusty/ubuntu -n 4
<wallyworld> davecheney: haven't seen that email yet, but will look soon
<davecheney> what will happen is the furst unit of the trusty/ubuntu service will deploy
<davecheney> the other 7 will fail
<wallyworld> yes, i think you are right
<wallyworld> thanks
<davecheney> wallyworld: in that case, i have no idea what is going on
<davecheney> does --to lxc:0 override the duplicate service check ?
<wallyworld> don't think so
<davecheney> in that case i cannot explain what dpb is doing
<davecheney> or how it works
<davecheney> or how it didn't work but he didn't notice
<davecheney> i'm also loath to comment as it will be a distraction
<wallyworld> ok, i'll look into it
<davecheney> ta
<wallyworld> thank you too
<davecheney> thumper: i'm down to three api packages failing, some 10 test cases left to fix
<davecheney> thumper: wallyworld http://paste.ubuntu.com/7900177/
<davecheney> do you agree that this change is correct
<davecheney> it is the source of a lot of problems
<davecheney> AuthAlways is curently accepting anything, including invalid data and returning true
<davecheney> when I change it to only return true for valid tags => dozens of test failures
<thumper> waigani: have you found the problem then?
<thumper> davecheney: that change looks ok to me
<waigani> thumper: not yet
<davecheney> thumper:         if !canWatch("") {
<davecheney>                 return result, common.ErrPerm
<davecheney>         }
<davecheney> this is rife through the codebase
<davecheney> what does this mean ?!?!
<davecheney> canWatch(anything?)
<davecheney> canWatch(nothing?)
<davecheney> authenticate anyuthing
<davecheney> even the empty string !?!?
<thumper> I'm not sure...
<wallyworld> axw: i tested the endpoints branch on 1.20, seems  to work ok, plus has the fix for the list rendering, so off it goes to the bot
<wallyworld> all bollocks, except bot is blocked
<wallyworld> thumper: can you review that lxc fix so i can unblock the bot?
<thumper> wallyworld: doing it now
<wallyworld> fanks
<thumper> wallyworld: rework needed
<thumper> wallyworld: lxc-create doesn't support long opts
<wallyworld> :-(
<thumper> lxc-start does
<thumper> hazaah
<wallyworld> thumper: but lxc-creat --help says otherwise
<thumper> wallyworld: of which version?
<wallyworld> thumper: so what are you basing that on?
<thumper> wallyworld: I'm looking on the man page, and output of lxc-create on precise 0.7.5
<wallyworld> hmm, i have 1.0.4
<wallyworld> sigh
<thumper> heh, the man page for lxc-create says no long opts, lxc-create --help says yes
<thumper> for 1.0.4
<wallyworld> yep
<thumper> go 'man lxc-create'
<thumper> geez
<wallyworld> confusing
<thumper> yep
<wallyworld> thumper: i tested running up a local env
<wallyworld> but that was 1.0.4
<thumper> sure, but you have a modern lxc
<wallyworld> are you sure 0.7.5 doesn't support long args?
<thumper> yep
<wallyworld> ok, and it's just create?
<thumper> well, not actually tried passing arg
<thumper> seems to be
<thumper> well
<thumper> i only looked at lxc-create and lxc-start
<thumper> lxc-stop has long
<wallyworld> lxc-info, lxc-wait?
<thumper> lxc-destroy short only
<wallyworld> thumper: fuck, it, maybe we just go back to short
<thumper> lxc-info is long
<thumper> lxc-wait is long
<wallyworld> ok, so just create, destroy
 * thumper nods
<wallyworld> rightio
<thumper> I do wonder if we could just say "your lxc is too old, go away"
<wallyworld> i wish
<wallyworld> thumper: pushed changes
<wallyworld> ah sorry, left in info
<wallyworld> will delete those, that was for debugging
<thumper> lxc-clone is short only on old :(
<thumper> wallyworld: ^^
<wallyworld> ffs
<wallyworld> thumper: try now
<thumper> done
<wallyworld> thumper: ty
<davecheney> thumper: it just gets worse
<davecheney> http://paste.ubuntu.com/7900384/
<davecheney> the fake authoriser used in our tests rarely has the tag that it is authenticating set
<thumper> davecheney: if an arg can be empty in a test, you can bet your eggs that someone will pass "" through
<jcw4> any hints why 'juju ssh 0' keeps giving me Permission denied (publickey,password) ?
<thumper> jcw4: yes
<thumper> jcw4: I bet you are using the local provider
<jcw4> thumper: mind reader!
<thumper> jcw4: and you have no ubuntu user on the host
<jcw4> thumper: wow, interesting
<thumper> and/or your aren't running sshd on the host
<jcw4> the former
<thumper> jcw4: don't do it
<thumper> not supported
<jcw4> oh?  juju ssh not supported on local?
<thumper> saves you from running "juju run --machine 0 'sudo reboot; "
<jcw4> lol
<thumper> just for machine 0
<thumper> because it is the host
<thumper> I'd love to fix the local provider so machine 0 is a container too
<thumper> but I don't have enough working hours
<jcw4> I'm trying to figure out why all my machines stay stuck in pending except for 0
 * thumper sighs
 * thumper raises his hand again
 * jcw4 feels nervous now
<thumper> probably my fault
<thumper> hopefully wallyworld is going to fix it to be less shit
<thumper> jcw4: please run "sudo lxc-ls --fancy" for me
<wallyworld> yep, rsn
<jcw4> lxc: Error: juju-trusty-template creation was not completed
<jcw4> NAME                  STATE    IPV4  IPV6  AUTOSTART
<jcw4> ----------------------------------------------------
<jcw4> juju-trusty-template  STOPPED  -     -     NO
<jcw4> interesting...
<thumper> jcw4: ok, do this:
<thumper> sudo lxc-destroy -n juju-trusty-template
<thumper> jcw4: then...
 * thumper wonders where the hell he put the lock file
<jcw4> container not defined?
<jcw4> n/m; at least lxc-ls is empty now
<thumper> jcw4: look in /var/lib/juju/locks
<jcw4> juju-trusty-template/message|held
<thumper> jcw4: delete that dir
<jcw4> done
<thumper> now I expect one of your machines will fail to start
<thumper> and then the next will be slow to start
<thumper> as it is recreating the template
<thumper> the rest should be fast
<thumper> do a "sudo lxc-ls --fancy" again
<thumper> see if the template has been created again
<jcw4> yes, but no error now
<thumper> right
<thumper> now wait
<thumper> jcw4: just before everything starts to fly
<thumper> you'll see the template go from running to stopped
<thumper> the second machine may fail if you have slow internet
<jcw4> oh, it was stopped when I looked
<thumper> due to timing
<thumper> that wallyworld if fixing right now
<jcw4> and machines 1, and 2 are still pending
<thumper> jcw4: it may still have been creating
<thumper> look now
<wallyworld> thumper: i'm fixing the lock around downloading/creating the template
<jcw4> NAME                  STATE    IPV4  IPV6  AUTOSTART
<jcw4> ----------------------------------------------------
<jcw4> juju-trusty-template  STOPPED  -     -     NO
<wallyworld> the fact that the lock can be left aquired
<jcw4> ah, now it's starting to come up
<thumper> wallyworld: I was referring to the --console-log one
<wallyworld> ah, ok
<thumper> wallyworld: as that impacts the "template failed to stop" issue
<jcw4> thanks thumper
<thumper> jcw4: np
<wallyworld> the bot is running the merge job now
 * thumper goes to fix our mongo upstart bouncyness
 * thumper picks music
<thumper> disturbed I think
<jcw4> :)
<davecheney> thumper: that is a nice bug
<wallyworld> thumper: i can't hear, can you turn up the volume
<davecheney> agent restarts, rewrites upstart config, upstart restarts mongo, agent restarts, rinse, repeat
<thumper> davecheney: aye
<davecheney> whups
<davecheney> thumper: OMG
<davecheney> i just found hundreds of places where the tests set fakeauthorizer.tag to somethign
<davecheney> without setting fakeauthorizer.entity
<davecheney> !?!?
<davecheney> i've changed it so you set the entity and that is what defines the tag
<davecheney> as they are not indepdeant
<davecheney>         fakeBadAuth := apiservertesting.FakeAuthorizer{
<davecheney>                 Tag:       s.mysqlUnit.Tag(),
<davecheney>                 LoggedIn:  true,
<davecheney>                 UnitAgent: true,
<davecheney>                 Entity:    s.wordpressUnit,
<davecheney>         }
<davecheney> oh crap
<davecheney> i can't even do that
<davecheney> althoguht I cannot explain what this is trying to test
 * thumper hides and codes for 20 minutes
<jcw4> okay, next question
<jcw4> juju debug-log is getting spammed with modprobe errors
<jcw4> could not insert 8021q ; operation not permitted
<jcw4> on machine-2
<davecheney> jcw4: sounds unrelated
<jcw4> davecheney: okay.  I'm just concerned because it's drowning other messages
<davecheney> it's a bug for sure
<davecheney> but that's something related to wifi
<jcw4> interesting
<jcw4> davecheney: thx
<davecheney> thumper: we need to have a serious chat about apiserver/testing/FakeAuthoriser
<davecheney> it's wrong
<davecheney> in many ways
<davecheney> and the tests have mutated to accept it as the source of truth
<thumper> davecheney: would it be better to take it to the list?
<davecheney> thumper: i'm not at that stage
<davecheney> it just keeps getting more confusing
<thumper> ok, can I put you off for a few minuts to get this bug fixed?
<davecheney> sometimes things are authenticated againts the GetAuthEntit
<davecheney> others authenticate against GetAuthTag
<davecheney> in most cases the tag and the entity don't match, and most cases one is nil
<davecheney> thumper: which bug ?
<thumper> https://bugs.launchpad.net/juju-core/+bug/1349969
<_mup_> Bug #1349969: Jujud rewrites /etc/init/juju-db.conf constantly <mongodb> <performance> <juju-core:In Progress by thumper> <juju-core 1.20:Triaged by thumper> <https://launchpad.net/bugs/1349969>
 * thumper takes a deep breath
 * thumper silently stabs the person who named a public struct param "Desc" instead of "Description"
 * thumper mutters under his breath
<thumper> fucking brain dead test
 * jcw4 quietly does a grep to make sure it wasn't him
<thumper> (â¯Â°â¡Â°)â¯ï¸µ â»ââ»
<jcw4> nice
<jcw4> I saw davecheney use that table flipping thing before
<thumper> jcw4: emojicons.com/table-flipping
<jcw4> oooh fun
<thumper> sorry davecheney, giving away trade secrets
<jcw4> is there a way to update the jujud binary without destroying and bootstrapping?
<jcw4> can I just kill the process?
<davecheney> jcw4: juju upgrade-juju --uplaod-tools
<jcw4> davecheney: cool
 * jcw4 is embarrassed that almost all of his usage of juju has been in unit tests
<axw> wallyworld: you saw CI failed your golxc PR?
<axw> dependencies.tsv update
<wallyworld> no, not yet
<wallyworld> vapour wouldn't load for me
<wallyworld> i hadn't checked back
<axw> huh, working for me
<axw> looks like a CI infrastructure failure
<wallyworld> axw: so you can load the dashboard?
<wallyworld> i can't
<axw> yep
<axw> http://juju-ci.vapour.ws:8080/
<wallyworld> yep, the browser title changes, the page goes blank, and it gets stuck reading
<axw> le shrug
<wallyworld> axw: what does the error say (as i can't see it)
<axw> un moment
<wallyworld> ah, chrome can load the page
<wallyworld> i-da61a1f6 doesn't exist anymore
<wallyworld> our ec2 instance has been removed
<axw> oh joy
<thumper> oh fark... again...
<sinzui> wallyworld, I see a problem
<wallyworld> sinzui: i was lookingif our image id were are using had changed
<sinzui> wellm that is indeed my topis
<sinzui> topic
<wallyworld> script uses ami-e55a648c
<sinzui> testing with saucy is bogus, it is EOL
<sinzui> wallyworld, you want a trusty id?
<wallyworld> maybe ami-018c9568 ?
 * sinzui looks at other trusty test
<wallyworld> i though we did have a trusty id
<wallyworld> thought
<wallyworld> surprised we didn't
<wallyworld> i'll follow up with martin to see wtf is going on :-(
<sinzui> wallyworld, ami-018c9568 is what CI will use when it re-runs unit tests
<sinzui> I think I can change it now if you like
<wallyworld> sinzui: yep, that's where i got it from :-)
<wallyworld> i'm changing it
<wallyworld> the github-merge-job
<thumper> wallyworld: https://github.com/juju/juju/pull/424
<wallyworld> looking
<wallyworld> sinzui: i was hoping to be able to do a new 1.20.2 build today but we're not ready :-(
<sinzui> wallyworld, I understand. I am frantically putting a set of certification tests together for Ubuntu. There just aren't enough people to do the work
<wallyworld> and we keep finding more issues to fix :-(
<sinzui> wallyworld, Most of the issues I saw today weren't essential I placed them in 1.20-alpha1. I am trying to keep the issues in 1.20 to be regressions and detrimental performance
<wallyworld> sinzui: yeah. issues we're working on: template lock, mongo restarts every 3 seconds, backport of api endpoint fix
<sinzui> I don't disagree with those. The restart is something I see too often myself
<thumper> wallyworld: what is the typo you refer to?
<thumper> it isn't a well structured sentence, but no typo
<wallyworld> thumper: maybe i can't read. ah, it makes sense a second time
<wallyworld> sorry
<thumper> I'll restructure...
<axw> wallyworld: you merged? how did you get the instance back?
<axw> or was it just the temporary instance went away
<wallyworld> axw: i used a new one
<wallyworld> a trusty one
<axw> ok
<wallyworld>  i think the other one was saucy
<wallyworld> but i didn't know that - i assumed were had been set up for trusty
<wallyworld> axw: but something is still wrong, the console output shows no tests as being run
<wallyworld> sigh
<wallyworld> all i did was change the image id
<axw> wallyworld: that's a bit of a worry, since it merged...
<wallyworld> yes indeed
<sinzui> axw, wallyworld don't panic. we know that the AMI is bad
<sinzui> wallyworld, see http://juju-ci.vapour.ws:8080/job/run-unit-tests-trusty-amd64/1215/console
<wallyworld> oh
<wallyworld> got a good one?
<sinzui> wallyworld, looks like we need to find another. I can do that now. lets see these results playout before reverting
<wallyworld> sinzui: they should be ok, it was a simple dependencies.tsv change
<sinzui> wallyworld, I just cannot get everything transitioned to the slaves fast enough
<sinzui> yep, I think it is safe too
<wallyworld> yeah, i hear you
<wallyworld> it's way past you eod so thank you very uch
 * thumper is sad
<thumper> code was broken but no tests failed
 * thumper writes another test
<jcw4> another quick question... juju upgrade-juju --upload-tools works great... can I update a charm in a similar way without destroying/deploying it?
<thumper> fark
<thumper> I know why
<thumper> stabby stabby
<thumper> jcw4: yes
<thumper> juju upgrade-charm foo
<thumper> calls the upgrade hoook
<jcw4> thumper: it's like magic
<thumper> yep
<thumper> sucky tests suck
 * thumper unsucks the tests
<jcw4> ha
<sinzui> wallyworld, our new ami for trusty is ami-b027efd8. I will update the jobs that seem to need it
<wallyworld> sinzui: great, ty
<thumper> axw: which todo are you referring to?
<thumper> axw: nm, found it
 * thumper needs coffee
<thumper> wallyworld, menn0: updated the PR, axw - removed old todo
 * thumper goes to make coffee
<thumper> 20 minutes guess -> 2 hours seems about right
<menn0> thumper: looking now
<thumper> suppose I should squish all those commits for easier cherry picking into 1.20
<menn0> thumper: what about the comment I made (+1'ed by axw) about starting the service?
<menn0> the other change looks good
<thumper> sure, will do
<thumper> menn0: that means another damn test
<menn0> thumper: sorry :p
<thumper> ok, so how do I squick all these again
 * thumper pushes a single commit
<thumper> geez I must be good to get that right first time
<thumper> just don't look at the review comments
<thumper> ah fark
 * thumper found a problem
<bodie_> https://github.com/juju/juju/pull/415
<bodie_> if anyone has a minute to inspect :)
<bodie_> I still need to add a few comments to things -- will take care of
<menn0> wallyworld: I've updated the LP bugs related to this morning's discussion with everything we currently know and what's being done
<menn0> wallyworld: should I also email juju-dev asking for help?
<wallyworld> menn0: \o/ thank you
<wallyworld> with the mongo issue?
<menn0> yep
<wallyworld> the panic
<wallyworld> yes please
<menn0> ok doing that now
<thumper> menn0: and another look at my branch?
<thumper> ah fark...
 * thumper stabs it again
<menn0> thumper: huh?
<thumper> old comments in the new tests
<thumper> just removed them
<thumper> wallyworld: is the bot unblocked?
<wallyworld> le tme check
<thumper> you folks have until my coffee is made to complain about that branch, otherwise I'll take the previous four LGTMs and merge it
<thumper> changed somewhat
<wallyworld> thumper: appears to be yes
<thumper> menn0: changing the commit message, just for you
<menn0> thumper: aww shucks
<davecheney> is trunk unblocked ?
<bodie_> woot!  we have an end to end action
<bodie_> marcoceppi, :)
<wallyworld> axw: i have a flock implementation which hopefully will be suitable https://github.com/juju/juju/pull/425
<jcw4> ï¼¼(ï¼¾Oï¼¾)ï¼
 * thumper goes to drop of kid a sports
<davecheney> wtf, why can't i merge things
<davecheney> I just saw something lang
<davecheney> land
<ericsnow> we are going to store metadata for backups in the state...so I'm guessing we need a new collection, etc.
<ericsnow> is that right?  what's the best way to do that?
<davecheney> ericsnow: obtain paper bag, breath deeply
<davecheney> let the carbon dioxyde sooth you
<ericsnow> davecheney: careful, it's quite late here and my brain is already rather fuzzy :)
<thumper-afk> davecheney: critical bugs blocking landing
<wallyworld> axw: ping
<tasdomas> hi
<tasdomas> tried to land my PR for juju-core and got this response from the bot: Does not match ['$$fixes-1347715$$', '$$fixes-1342725$$']
<tasdomas> what does this mean?
<fwereade> tasdomas, this means that sinzui has put his foot down -- it's explained on juju-dev
<davecheney> thumper, wallyworld how come this one landed ? https://github.com/juju/juju/pull/419
<wallyworld> davecheney: 1.20
<wallyworld> different target branch
<davecheney> wallyworld: why did it fail the first time ?
<wallyworld> davecheney: the critical bug affected 1.20 also
<wallyworld> now that one has been fixed
<davecheney> wallyworld: yes, but the magic string was never mentioned
<davecheney> i just want to make sure the bot is working properly
<wallyworld> Build failed: Does not match ['$$fixes-1350011$$']
<wallyworld> build url: http://juju-ci.vapour.ws:8080/job/github-merge-juju/157
<wallyworld> it was wasn't it?
<davecheney> it was what ?
<wallyworld> mentioned
<wallyworld> you asked if the magic string was mentioned
<wallyworld> i pasted the comment from the failed merge showing it was
<davecheney> yes, and I cannot see it there
<davecheney> the bot said that
<davecheney> so the build fails, the bot then comments with the right string and resubmits itself ?
<wallyworld> no, the developer has to
<davecheney> wallyworld: i cannot see a comment from a developer with the right string
<wallyworld> i saw the failed pr and resubmitted
<davecheney> wallyworld: you said $$Merge$
<davecheney> that isn't the correct string
<wallyworld> oh, i did the right thing for master
<wallyworld> maybe there's a gitch
<davecheney> wallyworld: i think there is a glitch
<wallyworld> i did it at the same time for both pr's
<davecheney> à° _à° 
<voidspace> morning all
<axw> wallyworld: pong. sorry, went out for a while
<wallyworld> axw: no problem. just wanted to get you to look at fix for clone lock, and i changed to pr so didn't want you to look at wrong one. new one is https://github.com/juju/juju/pull/427
<axw> wallyworld: I think you branched off katco's branch by accident
<axw> ok
<wallyworld> axw: yep :-)
<wallyworld> that has lande dnow
<axw> cool
<wallyworld> axw: also there was some double up (as per emails), i haven't looked at martin's implementation
<axw> okey dokey
<wallyworld> i kept mine self contained - just added lock to container package
<wallyworld> axw: also, i'm concerned we're using fslock in container handler setup, but we still need it since hooks still use fslock
<wallyworld> we need to think about using the new lock instead
<axw> wallyworld: reviewed
<wallyworld> ty
<wallyworld> axw: trouble with LOCK_NB is that it actually acquires the lock, even if you just want to check the status
<wallyworld> well not it itself
<wallyworld> but it's used with LOCK_EX
<axw> you can unlock it immediately after
<wallyworld> yuk
<wallyworld> though about that
<axw> doesn't matter
<axw> leave as is for now
<wallyworld> the IsLocked is just for testing
<wallyworld> prod code only needs lock/unlock
<wallyworld> axw: my only real concern is whether we should have a lock timeout
<axw> then you'll need to use LOCK_NB and poll. we're not doing timeouts now right? I think it'd be better to keep it simple
<wallyworld> axw: correct, no timeouts now. but just thinking we may need them. i mean we should be able to determine that we don't want to wait 100 years for a clone template lock
<wallyworld> but for now i think this fixes the issue better than what we had
<axw> hey what, the manual provisioning jobs started working again...?
<axw> ah, 1.20
<wallyworld> axw: changes pushed
<axw> looking
<axw> wallyworld: LGTM
<wallyworld> axw: awesome ty
 * axw gives worker/networker the evil eye
<axw> wallyworld: I have a vague suspicion that we're screwing around with networking too much at bootstrap time
<axw> not sure yet, but I've had some issues with azure
<wallyworld> could be
<axw> and in the last failing manual bootstrap job, there's this:
<axw> 2014-07-29 18:25:31 ERROR juju.cmd supercommand.go:323 failed to stop mongo: exec ["stop" "--system" "juju-db"]: exit status 1 (stop: Method "Get" with signature "ss" on interface "org.freedesktop.DBus.Properties" doesn't exist)
<wallyworld> yuk
<wallyworld> you're looking t trunk?
<axw> that's CI running with trunk, yes
<axw> 1.20 is working
<wallyworld> so this may be related to the other network screw ups eg network-manager issues
<wallyworld> axw: small one https://github.com/juju/juju/pull/428
<wallyworld> thanks
<wallyworld> fwereade: hi, you ok for the juju gui meeting?
<wallyworld> rick_h__: is francesco able to come?
<fwereade> wallyworld, yeah, I can do that I think
<fwereade> wallyworld, but I was thinking I'd take my second swapday from NZ the rest of the day
<fwereade> wallyworld, I'll make sure my phone will warn me
<rick_h__> wallyworld: not sure, will check today
<rick_h__> frankban: are you up for a late night charm meeting tonight with wallyworld? It's optional, so don't worry if not.
<wallyworld> rick_h__: oh sorry, i thought it would be late afternoon. fucking timezones
<rick_h__> wallyworld: all good, frankban and I had a chat during the sprint so I think I've got a good list of all the stuff to worry about
<wallyworld> ok
<voidspace> jam: TheMue: hard crash! rejoining room
<jam1> voidspace: see you in a sec
<frankban> rick_h__: I should be able to be in the call later tonight
<axw> can someone please review https://github.com/juju/juju/pull/429
<perrito666> morning
<axw> should fix the manual provider regression
<axw> morning perrito666
<voidspace> perrito666: morning
<wallyworld> mgz_: standup?
<jam1> axw: have you tested that https://bugs.launchpad.net/juju-core/+bug/1347715 is fixed ?
<_mup_> Bug #1347715: Manual provider does not respond after bootstrap <bootstrap> <ci> <regression> <juju-core:In Progress by axwalk> <https://launchpad.net/bugs/1347715>
<jam1> CI says your patch has landed but it hasn't run the manual provider with the new rev.
<axw> jam1: I could not reproduce it completely, I could only verify that .jenv is properly populated now
<jam1> k, it looks like it will try again soon http://juju-ci.vapour.ws:8080/job/manual-deploy-precise-amd64/
<axw> I'll check back later
<axw> hmm, I don't think CI has built my rev yet
<sinzui> wallyworld, davecheny, your conversation explains why tomas's branch was accepted after being rejects. I have taught the script to ignore comments by the bot.
<wallyworld> sinzui: thank you
<katco> sinzui: will that break listening to failure messages, so a
<katco>          future $$merge$$ works again?
<sinzui> katco, yes, you can re $$merge$$
<katco> sinzui: cool :)
<jam1> sinzui: so is the only remaining bug the Windows CLI regression that natefinch was going to work on?
<sinzui> jam1. I believe so
<mgz_> sinzui: what exactly is the fixes check/change? I don't understand the dollars in it.
<mgz_> I guess I should just replay to your thread
<mgz_> -a
<rogpeppe> fwereade: would you mind adding a brief "sgtm" reply to the "series-agnostic charm URLs" thread in juju-dev, for the record, please?
<sinzui> mgz_, the script iterated over the comments looking for $$fixes-xxx$$. when it rejects a merge because of blockers, it then comments on the pr with the list of blockers it is looking for. A resubmit will be merged because the jujubot comment matched a blocker :(
<sinzui> mgz_, the fix was to ignore all comments by jujubot
<mgz_> okay, I guess that's harmless. just the cute dollar-anything change I made causing issues... ;_;
<sinzui> mgz_, I don't think that can cause a problem the script is doing simple string checking: http://bazaar.launchpad.net/~juju-qa/juju-ci-tools/trunk/view/head:/check_blockers.py
<mgz_> sinzui: the issue is the *landing* script looks for a comment from a juju-dev with $$wtv$$ as a sign to go ahead and land
<sinzui> mgz_, yeah. there may be reason to force a merge. and I cannot stop devs from lying about what the branch fixes or they could change the status of a bug for a few minutes to hide the blockers
<perrito666> aghh fml (type *"labix.org/v2/mgo".DialInfo) as type *"gopkg.in/mgo.v2".DialInfo
<sinzui> mgz_, I will shout if I think developers are abusing the rules
<mgz_> sinzui: I don't think that's an issue, just that because your script reports an answer with dollars it can confuse the landing script when it reads github comments
<mgz_> but I can just revert the cute change
<sinzui> mgz_, ah, so you want a different quote. We can do that.
<mgz_> yup, just for confusion's sake if nothing else
<sinzui> mgz_, I like __fixes-nnnn__
<mgz_> sinzui: that seems fine, though I'm a bit confused as to why it needs quoting at all, /fixes-[0-9]+/ is already hard to accidentally work into your comment by accident :)
<sinzui> I am so tired. I created a certification tests for Ubuntu last night. Since I am alone this week, I had no one to talk to but myself. I heard my wife asking by daughter if she thought I was crazy
<mgz_> unlike duplicateing accidentally words by accident, I do that all the time
<sinzui> mgz_, okay, the hyphen is not natural in typing
<axw> sinzui: what triggers build-revision?
<axw> the job
<sinzui> axw, a cron tab polls for new commits in stable and master.
<sinzui> axw your work will start testing in 45 minutes?
<natefinch_> wwitzel3: 1 on 1?
<axw> sinzui: ok, thanks
 * perrito666 tries for the first time restore with an integrated cli and backend
<voidspace> perrito666: good luck!
<perrito666> heh, I already know it will not work :p I am missing a bit in state/apiserver, just trying to figure out which :p
<ericsnow> perrito666: I've looked at that code a bunch so let me know how I can help :)
<perrito666> natefinch_: lemme know when you are here
<perrito666> its a totally non urgent matter
<natefinch_> perrito666: here
<rogpeppe> does anyone know what the current status of CI on github.com/juju/charm is?
<rogpeppe> mgz_: ^
<mgz_> rogpeppe: I've not done it yet
<rogpeppe> mgz_: ok, ta
<rogpeppe> mgz_: big green button it is then :-)
<wwitzel3> perrito666, ericsnow: standup
<rogpeppe> wwitzel3, mgz_, fwereade, voidspace, bodie_, natefinch_, frankban: i've updated this PR for tip; it's huge most almost entirely mechanical. i'd appreciate a quick review if possible, so that it doesn't bitrot again. https://github.com/juju/juju/pull/253
<voidspace> I'm just going EOD
<voidspace> 6:30pm here
<voidspace> but good luck :-)
<TheMue> voidspace: enjoy your evening
<rogpeppe> voidspace: ok
<voidspace> thanks
<rogpeppe> voidspace: where are you?
<voidspace> rogpeppe: Romania
<rogpeppe> voidspace: ah, fun
<voidspace> rogpeppe: until the end of August
<rogpeppe> voidspace: cool
<voidspace> gotta run, got a date with the gym :-)
<rogpeppe> voidspace: any particular reason, or just 'cos you thought it'd be a nice place to hang out?
<voidspace> night all
<rogpeppe> voidspace: g'nigfht
<voidspace> rogpeppe: wife is Romanian
<rogpeppe> voidspace: ah!
<voidspace> so we're living next door to my parents in law!
<voidspace> babysitters on tap though, so not all bad...
<rogpeppe> voidspace: joy :-\
<bodie_> lol
<bodie_> rogpeppe, I can give it a look after lunch :) but I can't promise I'll have much to say
<rogpeppe> bodie_: just "LGTM" would do nicely :-)
<rick_h__> lol, go bodie_ go
<rogpeppe> anyone else up for it? TheMue? perrito666? https://github.com/juju/juju/pull/253
<bodie_> rick_h__, we just demoed our first baby working action for Mark :)
<rick_h__> bodie_: woot! congrats. Really glad to see that progressing.
<bodie_> the client API needs to be built out a bit, and we have a couple of minor tech debt items that we pinned together for the demo, but it's really close
<bodie_> rick_h__, Mark mentioned we should sync with the frontend in the near future
<bodie_> so, put that on your brain plate and nibble on it :)
<rick_h__> bodie_: sure thing. I'm out next week and change, but say in 2wk we could sync up
<rogpeppe> frankban: i've updated https://github.com/juju/charmstore/pull/45 to add some sanity checking for the metaEndpoint.get functions
<rick_h__> bodie_: who've you been working with on actions mostly these days?
<rick_h__> bodie_: I want to chat with them and get an update
<jcw4> rick_h__: It's mostly bodie_ and I
<jcw4> We have our stand up in a minute
<jcw4> Might be discussion w/niemeyer, but you're welcome to join
<rick_h__> jcw4: if you guys don't mind and want to fill me in I'd love to jump on and derail it for you :)
<jcw4> you're welcome... one small detail, the hangout link doesn't work til a Canonical joins: https://plus.google.com/hangouts/_/canonical.com/juju-actions
<rick_h__> ah, well then I can fix that :)
<jcw4> :)
 * rick_h__ joined
<jcw4> hmm I'm still getting the "this party is over" message
<rick_h__> hmm
<jcw4> maybe mgz_ or fwereade have to join?
<rick_h__> hmm, odd
<rick_h__> pm me your google name and I'll try to manual invite?
<bodie_> rick_h__, you asked who we've been working on actions with -- mgz and fwereade are both tuned in, though not actively engaged in pushing code
<bodie_> and we've been talking a bit with marcoceppi as well
<rick_h__> bodie_: understood. In the meeting next week I want to know who I should ping to represent juju-core.
<rick_h__> bodie_: thanks for the contacts
<bodie_> cool
<cmars> hey, anyone else getting worker/uniter test failure in master?
<jcw4> cmars log message?
<natefinch> do the container/lxc tests take forever for anyone else?
<cmars> jcw4, http://paste.ubuntu.com/7906865/
<jcw4> cmars: hmm; bodie_ might have some insight
<jcw4> bodie_: know anything about ^^
<perrito666> natefinch: I would run them but I need my ram to run the restore ones
<perrito666> sorry
<jcw4> cmars: is it possible your system was under enough load that 10 seconds could have passed before the system could finish that step?
<natefinch> perrito666: it's ok, it's probably something wacky in my new system...
<cmars> jcw4, yes, possible. after closing all the browser windows, it passes.
<cmars> rerolling to be sure
<jcw4> that's one hell of a tab collection
<jcw4> :)
<cmars> jcw4, not many tabs, really. i'm surprised it made a difference
<jcw4> still, 10 seconds seems awfully short for 'worstCase'
<cmars> uhoh, failed again. i think it might just be intermittent. :(
<jcw4> urg... the worst.  Not suprising to me though
<jcw4> whenever your test has a time element that screams random failure to me
<jcw4> and when it's 10 seconds in a distributed system...
<katco> natefinch: remember how yesterday i was asking if it was ever reasonable for an environment config not to be present in a machine config? what about provisioning machines?
<natefinch> katco: I'm pretty sure that the environment config is always added to the machine config before it's sent to the server being provisioned
<natefinch> katco: I don't know for sure, though
<katco> natefinch: could you look at juju/juju/worker/provisioner/provisioner_task.go::provisioningInfo?
<katco> it creates a new machine config, but doesn't seem to fill in the environ config
<natefinch> oh FFS.  Don't do deep equals on a map!~
<katco> if that's the case, i'm not sure what the right thing to do in kvm.go where it is trying to read the simplestream's path... i could just ignore it if it's not present, but i don't know if that's the "right thing"
<perrito666> bbl
<natefinch> katco:  Sorry.  I'm not sure.
<katco> natefinch: thats ok, thanks for taking the time to look
<ericsnow> who can tell me what is involved when adding a new collection to the state?
<jcw4> pretty straightforward ericsnow
<jcw4> about 3 spots to change, and maybe a little more if you want to do indexes
<jcw4> lemme find my actions and actionresults commits and send the hash #'s to you
<ericsnow> jcw4: this is for backups so it should be relatively simple (and small)
<ericsnow> jcw4: that would be a big help. thanks!
<jcw4> ericsnow: hash adfdfa2f
<jcw4> actionresults
<jcw4> mostly state/state.go and state/open.go
<jcw4> ericsnow: wallyworld refactored a bit since then, but the same pattern applies
<jcw4> ericsnow: also, 3d262b2f for actions
<ericsnow> jcw4: thank you
<jcw4> ericsnow: the second one wasn't complete 'cause I learned about the indexes later... still looking for that commit
<ericsnow> jcw4: np
<alexisb> natefinch, ping
<cmars> yeah, worker/uniter tests are pretty flaky on my laptop. ran them 10 times in a loop: http://paste.ubuntu.com/7907518/
<natefinch> alexisb: howdy
<jcw4> cmars: presumably all in the same specific test?
<alexisb> natefinch, can I take a few minutes of your time?
<jcw4> cmars: can you pipe output to a file instead of /dev/null?
<natefinch> alexisb: sure
<cmars> jcw4, i probably should have captured that, sure
<jcw4> cmars: not really necessary I guess
<jcw4> cmars: just my cautious nature
<natefinch> alexisb: pretty sure that's one of your primary responsibilities ;)
<cmars> every time i've observed it, its been the same "never got expected hooks"
<cmars> but i didn't really observe it there, did i?
<jcw4> cmars: that's probably it... that also means your loop must've taken at least 100 seconds?
<cmars> jcw4, it runs about 170-180 seconds
<cmars> per iteration
<cmars> :(
<jcw4> cmars: ooh
<jcw4> so 1800 total for the loop 10 times?
<cmars> more or less, yeah
<cmars> its probably not load either, i had to join a google hangout for the last 6-7 iterations and let it run
<jcw4> to me that says 2 problems
<jcw4> 1. the test's "worstCase" time is fairly close to the boundary of the "normalTime" (at least on your machine)
<jcw4> 2. why does worker/uniter/ take over two minutes to run?
<jcw4> cmars: have you been able to reproduce it with 'go test -v ./worker/uniter -gocheck.f=UniterSuite.TestActionEvents'
<jcw4> i.e. just that specific test only
<cmars> jcw4, yep, that does it. runs at about 26s. pass/fail intermittent
<jcw4> cmars: okay, I think that's a bug that bodie_ and I have to figure
<jcw4> cmars: out of curiousity, you're not running multiple cores by any chance?
<jcw4> as in Go configured to use multiple cores
<cmars> jcw4, this is on a 4-core  i7, thinkpad x230
<cmars> i haven't messed with GOMAXPROCS
<cmars> but i could..
<jcw4> cmars: I think it defaults to 1 if it's not specified
<jcw4> but for grins, maybe set it to 1 and try?
<cmars> jcw4, another datapoint, which might be relevant.. i recently reimaged my laptop, and installed juju-mongodb
<cmars> before i was running mongodb-server
<jcw4> cmars: interesting
<cmars> GOMAXPROCS=1 seems to pass. we're 6 for 6, so far.
<katco> cmars: not sure if this is applicable -- just popping my head in -- but you might try setting -parallel=1 as a flag when running tests
<katco> cmars: juju does a lot of heavy tests with real resources, so parallel tests can step on each other.
<jcw4> cmars: yeah, I got 10 for 10, so I'm guessing it's related to -parallel
<natefinch> -parallel shouldn't matter... only tests that mark themselves as being able to be run in parallel are run in parallel
<natefinch> http://golang.org/pkg/testing/#T.Parallel
<jcw4> natefinch: I see.  What about GOMAXPROCS?
<cmars> i get intermittent pass/fail with -parallel=1
<jcw4> I haven't reproduced cmars issue myself yet with default and GOMAXPROCS=4
<natefinch> jcw4: gomaxprocs is just the default for parallel
<jcw4> natefinch: I see
<jcw4> cmars: have you repro'd the error with GOMAXPROCS=1 yet?
<cmars> jcw4, no, GOMAXPROCS=1 seems to pass
<jcw4> hmm
<jcw4> maybe unrelated, but suspicious
<natefinch> generally if gomaxprocs > 1 affects your tests, it's because of a bug in your code that is expecting things to run more serially than they really will
<natefinch> (a bug in someone's code that happens to be tested)
<natefinch> (not laying blame :)
<jcw4> natefinch: that's what I'm afraid of
<katco> natefinch: i regularly experience failures w/o -parallel=1
<natefinch> katco: hmm... that's a problem
<katco> natefinch: jcw4 and i beat my head against that issue yesterday actually
<katco> i wonder if -parallel=1 somehow affects gomaxprocs as well which would affect goroutines
<jcw4> cmars: bodie_ worked pretty much 2 days straight, so I don't expect to see him today.  I think he is most familiar with that test, but anyone with hook familiarity can probably get up to speed on it quicky too
<cmars> i got some fails with GOMAXPROCS=1. less often though, 2 out of 10 runs
<jcw4> cmars: okay.. that's good news actually
<cmars> thanks jcw4 katco, i'll keep poking at this
<jcw4> cmars: that just means parallelism is just a complicating factor, not the cause
<jcw4> cmars: good luck :)
<perrito666> how can I get a machine address within a Client method from state/apiserver/client/client.go ?
<ericsnow> perrito666: try c.st.addr
<ericsnow> perrito666: oops, that is the client side
<perrito666> wong c
<perrito666> :p
<perrito666> yup
<perrito666> well I can machine, err := c.api.state.Machine(p.Target) and then ask addr := network.SelectInternalAddress(machine.Addresses(), false)
<perrito666> and since p.Target is invariantly 0 in my case, should be enough
<ericsnow> yep
<alexisb> wallyworld, you online yet?
<wallyworld> alexisb: in a meeting, finished soon
<alexisb> ack
<perrito666> mmpdfs I think I hit some kind of limit on amazon
<thumper> niemeyer: hey there
<niemeyer> thumper: Heya
<thumper> niemeyer: is the mgo fix committed to trunk?
<niemeyer> thumper: It is
<thumper> niemeyer: thanks for the fix btw
<thumper> not sure anyone else could have found it anywhere near as quickly
<niemeyer> thumper: np, and sorry for the bug pain
<thumper> I'm just happy it has been found and fixed
<thumper> cheers
<niemeyer> thumper: Please note it's on github
<thumper> niemeyer: we are using gopkg.in for mgo now
<thumper> so that picks it up right?
<perrito666> anyone had this problem with amazon? Request limit exceeded. (RequestLimitExceeded)
<thumper> perrito666: you are doing too much :)
<perrito666> why do these things happen when one has to try the whole thing
<niemeyer> thumper: Ah, brilliant yeah
<thumper> menn0: re bug 1318366
<_mup_> Bug #1318366: jujud on state server panic misses transaction in queue <cloud-installer> <landscape> <orange-box> <panic> <performance> <sm15k> <juju-core:Triaged> <juju-core (Ubuntu):Triaged> <https://launchpad.net/bugs/1318366>
<thumper> menn0: niemeyer says the fix is now in trunk of mgo
<menn0> thumper: yep, just catching up. that's great news.
<thumper> menn0: so the fix for us should be to just update dependencies.tsv
<thumper> menn0: should do it on the 1.20 branch too
<thumper> menn0: If we can
<menn0> thumper: shall I do that?
<thumper> menn0: please
<menn0> will do
<thumper> menn0: re 1.20, we recently changed the imports for mgo from labix to gopgk, not sure if it is in 1.20 or not
<thumper> menn0: so could be more of a problem there maybe
<thumper> sinzui: wallyworld: do you know?
<thumper> about the import for mgo in the 1.20 branch that is
<thumper> menn0: I have waigani arriving here shortly to pair on the bootstrap issue
 * wallyworld reads back scroll
<wallyworld> alexisb: just finished meeting
<thumper> morning wallyworld
<wallyworld> morining
<wallyworld> sinzui: thumper: we now import gopkg.in for mgo
<thumper> wallyworld: yes, but what about the 1.20 branch?
<thumper> wallyworld: the mgo panic fix is in github
<menn0> thumper: yep - I already talked to waigani this morning (he has his sublimetext go oracle plugin working)
<alexisb> wallyworld, we are in a test call, but I think we are good, was just going to invite you
<wallyworld> alexisb: ah ok,sorry,i scheduled and was in a different meeting
<wallyworld> thumper: sinzui: yes, you are right. to get the mgo fix in 1.20 we need to change the imports
<wallyworld> sinzui: we will do that this morning within the next few hours. then CI can bless a new 1.20.2 build
<thumper> wallyworld: omg, that is a pain
<thumper> wallyworld: do we want the mongo service bouncing in 1.20 for the next build?
<wallyworld> thumper: yes, i thought that bug was marked as affectibng 1.20 and that yuo were going to backport your fix from trunk
<thumper> wallyworld: I am, was wondering about 1.20.2 vs 1.20.3
<wallyworld> the next RC build will still be 1.20.2
<wallyworld> 1.20.2 was never released officially - just packaged for interal stakeholder testing
<wallyworld> thumper: the above is my understanding unless sinzui tells me i'm wrong
<wallyworld> alexisb: there's no video call link for the meeting
<alexisb> crap
<alexisb> one sec
<sinzui> wallyworld, thumper I am catching up. 1. please update imports in 1.20. 2. CI is happy/clean right now so I think 1.20.2 might have a better canididate
<alexisb> wallyworld, added
<alexisb> wallyworld, I will be a little late
<menn0> niemeyer: to confirm we should now be depending on gopkg.in/mgo.v2 rev dc255bb679efa273b6544a03261c4053505498a4 right?
<wallyworld> sinzui: thank you, will do
<niemeyer> menn0: Haven't checked, but whatever v2 points to right now
<menn0> niemeyer: ok, thanks.
<niemeyer> menn0: Looking at https://github.com/go-mgo/mgo, that matches
<perrito666> meh, my zone is degraded temply apparently
<perrito666> ok, that marks EOD
<perrito666> ericsnow: remember the review
<perrito666> natefinch: same
<ericsnow> perrito666: didn't forget (just running late) :)
<natefinch> perrito666: ok L(
<natefinch> er :)
<menn0> niemeyer: great
<perrito666> not pushing here, just a gently reminder
<menn0> wallyworld, sinzui, thumper: I will take care of the import changes in 1.20
<wallyworld> menn0: awesome, ty :-D
<sinzui> looks like thumper found a way to circumvent the fixes-* block on master
 * sinzui adds more locks to the jail
<thumper> sinzui: wat?
<thumper> sinzui: is it still blocked?
<sinzui> thumper, your reply  with $$tryagain$$ contained jujubot's helpful message of why your branch cannot land
<thumper> sinzui: I saw the landings and assumed it was all good
<sinzui> that tricked jujubot seeing a comment from you into thinking the branch fixes bug 1347715
<_mup_> Bug #1347715: Manual provider does not respond after bootstrap <bootstrap> <ci> <regression> <juju-core:In Progress by axwalk> <https://launchpad.net/bugs/1347715>
<sinzui> thumper, there are still two blocking bugs
<thumper> ah
<sinzui> thumper, but if your branch is critical, then we either escalate an issue to be a critical regression or we add an escape clause because sometime the bot has to do what we say
<thumper> sinzui: the branch I was trying to land was one for mongo service restarting every time jujud starts
<thumper> sinzui: it isn't currently critical
<thumper> sinzui: just high
<stokachu> question, im seeing a odd behavior that the state-servers aren't being populated in local.jenv until i run juju status at least once
<stokachu> is that normal
<thumper> sinzui: I think an escape clause would be good
<thumper> stokachu: yes normal
<thumper> stokachu: and being working on right now
<thumper> to fix it
<stokachu> thumper, ah ok, is there a bug for that yet that i can follow?
<thumper> stokachu: no, it is a feature :)
<stokachu> haha fair enough
<thumper> I'm not aware of a bug for this behaviour
<stokachu> i only noticed it b/c i am using the api and couldnt get a state server address right after bootstrap
<thumper> heh
<thumper> stokachu: waigani and me are looking at this as we type
<stokachu> thumper, awesome, lemme know if you need me to test anything
<thumper> stokachu: thanks, but it is pretty easy to check :)
<stokachu> sounds good :)
<menn0> sinzui: is bug 1318366 on of the ones blocking 1.20? it should be.
<_mup_> Bug #1318366: jujud on state server panic misses transaction in queue <cloud-installer> <landscape> <orange-box> <panic> <performance> <sm15k> <juju-core:Triaged> <juju-core (Ubuntu):Triaged> <https://launchpad.net/bugs/1318366>
<sinzui> menn0, 1.20 is unblocked. No critical regressions reported against it
<menn0> sinzui: ok.
<menn0> sinzui: sorry, I'm confusing blocked landings vs blocked releases.
<menn0> thumper, wallyworld, sinzui: at any rate here's the mgo change for trunk: https://github.com/juju/juju/pull/433
<menn0> working on the 1.20 change now
<wallyworld> menn0: otp, look soon
<sinzui> menn0, there are two branches, master and 1.20 master is has critical regressions, so juju bot is only accepting fixes for those issues to merge into master
<sinzui> menn0, but you point out that you probably need to land in both branches at about the same time.
<menn0> sinzui: the changes to master and 1.20 don't really have to happen at the same time but certainly soon. 1.20 is probably higher priority but I've made the master change already because it's very straightforward.
<sinzui> menn0, I am revising the token per mgz's advise. I am going to add something, maybe __JFDI__ to ensure engineers can always force a merge when we agree the merge is critical for other reasons
<menn0> sinzui: sounds good
<perrito666> jam: ping
<wallyworld> perrito666: it's 4 or 5 in the morning for him
<perrito666> ah, how dares he sleep
<perrito666> wallyworld: ah, I just notice the time here, it seems late in the night
<wallyworld> :-)
 * perrito666 watches the minister of economy of his country not daring to say on a press conference that we are in default
<thumper> wallyworld: FARK
<perrito666> wallyworld: given the present state we can do the next sprint here, for about U$D2
<thumper> wallyworld: the 1.20 code for upstart services is completely different
<thumper> wallyworld: cherry pick is a fail
<wallyworld> thumper: oh joy :-(
<wallyworld> perrito666: i'd love to come to argentina
<ericsnow> oh how I love the import cycles caused by the state package
<mjs0> thumper: I'm having 1.20 backporting problems too. I think we were using mgo v1 in 1.20 but the fix we need is in v2
 * thumper sighs
<wallyworld> alexisb: i'm ready for meeting now
<mjs0> I'm just figuring out what's going to be easiest: updating 1.20 to work with mgo v2 or backporting the mgo fix into mgo v1
<mjs0> niemeyer: any thoughts? ^^^
<niemeyer> mjs0: mgo v2 has been out for several years
<niemeyer> mjs0: You're definitely using v2
<alexisb> wallyworld, that means I have to stop stuffing my face with popcorn ;)
<wallyworld> no it doesn't :-)
<perrito666> alexisb: uh, popcorn, good idea
<mjs0> niemeyer: ok. I thought someone recently changed juju to use v2 but I must have that wrong
<mjs0> niemeyer: it must just have been the import changes from labix to gopkg
<wallyworld> mjs0: the import path changed from labix to gopkg.in
<menn0> never mind. I will figure out the build issue then.
<menn0> stand up first...
<wallyworld> menn0: thumper: 3 hours later and i have finished the first round of meetings for today. is there anything i need to do to help with the final 1.20 backports?
<menn0> wallyworld: I am in dependency hell because of the labix to gopkg change
<thumper> wallyworld: hey
<thumper> wallyworld, menn0: perhaps the easiest change would be to get the fix applied to the labix.org branch of mgo?
<wallyworld> menn0: what sort of hell?
<thumper> niemeyer: any chance we can have that?
<menn0>  I've had to update several entries in dependencies.tsv to get the labix -> gopkg changes for mgo
<menn0> but then juju/charms requires an update to juju/names which breaks juju 1.20
<thumper> niemeyer: our 1.20 branch was pointing to labix.org for mgo
<wallyworld> ah yes, because the sub repos
<menn0> juju/charms with the required mgo import change requires names.IsValidUser
<thumper> niemeyer: and backporting the gopkg change is a nightmare
<menn0> and updating to juju/names with IsValidUser breaks juju 1.20
<thumper> wallyworld: I suggested 1.20 braches of dependencies
<wallyworld> menn0: i have dealt with that before - there' already 1.20 branches for those sub repos
<thumper> starting with the version we need
<wallyworld> you just need to update the 1.20 breanches of the sub repos
<menn0> I think we can probably break the cycle by having a 1.20 branch for juju/charms that just has the import changes
<menn0> I'll do that
<wallyworld> there should be 1.20 branches for all the sub repos which need it
<wallyworld> with different revisions to master
<wallyworld> thumper: how's the mongo restart backport?
<menn0> wallyworld: thanks. I think I see what I need to do.
<wallyworld> menn0: thank you for saving me from having to do it. if you need to hand it over, i canpick it up
<wallyworld> menn0: the necessary 1.20 branches should already exist is what i should have said above, so it involves checking out those existing branches and updating
<menn0> how do I go about getting the changes merged. do I need to fork the subrepo on GH first?
<wallyworld> yeah
<menn0> ok
<wallyworld> same as for makng changes to master
<wallyworld> fork, make branch, pull request
<wallyworld> then merge manually
<thumper> wallyworld: getting there
<wallyworld> thanks for doing it
<wallyworld> arosales: you got a minute to talk about bug 1350493
<_mup_> Bug #1350493: 1.20.x local provider not running apt-get update <charms> <ci> <regression> <juju-core:Triaged> <juju-core 1.20:Triaged> <https://launchpad.net/bugs/1350493>
<arosales> wallyworld: for sure.
<wallyworld> arosales: ok, let me create a hangout
<wallyworld> arosales: we can use this one https://plus.google.com/hangouts/_/canonical.com/tanzanite-stand
<thumper> shit fuck shitfuck damn
<thumper> â¯Â°â¡Â°)â¯ï¸µ â»ââ»
<rick_h__> thumper: that good eh?
<menn0> thumper, wallyworld: here's the required juju/charm change: https://github.com/juju/charm/pull/30
<menn0> thumper, wallyworld: 1.20 is building now with the new import paths but I see at least one mgo related test failure which seems related to the change
<wallyworld> menn0: sec, otp again
<menn0> chasing that now
#juju-dev 2014-07-31
<menn0> wallyworld, thumper: sorted out the test failure. it was due to a change in how mgo does retries. I copied the change from master and it now passes. I've tried running big chunks of our state tests and all is looking good. will propose shortly.
<wallyworld> menn0: that's awesome, ty
<perrito666> restore from ./juju-backup-20140728-1542.tgz completed <-- with failures but :D
<thumper> wallyworld: https://github.com/juju/juju/pull/434 for backported mongo change
<wallyworld> \o/ looking
<menn0> thumper, wallyworld: this one needs a look before I can merge the big juju 1.20 change: https://github.com/juju/charm/pull/30
<wallyworld> sure
<wallyworld> menn0: tests pass?
<menn0> thumper, wallyworld, sinzui: also, the bot doesn't seem to be noticing this: https://github.com/juju/juju/pull/433
<menn0> what am I doing wrong?
<menn0> wallyworld: yep, tests pass
<thumper> menn0: did you still say merge?
<sinzui> menn0, __fixes-1318366__
<wallyworld> menn0: awesome, juju/charm change merged
<menn0> thumper: no. so you need both.
<thumper> menn0: AFAIK
<menn0> in the same comment or it doesn't matteR?
<wallyworld> thumper: your pr says it has conflicts
<davecheney> menn0: use figlet(1)
<sinzui> menn0, oh, but that isn't a merge command $$merge$$ to request merge testing.  __fixes-1318366__ is needed to convince CI to test it for the merge bot
<thumper> wallyworld: really?
<thumper> wtf?
<thumper> sinzui: I thought you said 1.20 landings were ungated?
<menn0> thumper: this is for master
<sinzui> menn0, damn, I think github is swallowing __
<thumper> menn0: mine isn
<thumper> isnt'
<sinzui> thumper, they are ungated, or were when I last looked
<thumper> sinzui: https://github.com/juju/juju/pull/434#issuecomment-50698948
<sinzui> ah, 1350493 is a regressions
<menn0> looks like bug 1318366 isn't on the list of allowed fixes for master: "Does not match ['fixes-1350493', 'fixes-1347715', 'fixes-1342725']"
<_mup_> Bug #1318366: jujud on state server panic misses transaction in queue <cloud-installer> <landscape> <orange-box> <panic> <performance> <sm15k> <juju-core:Triaged> <juju-core (Ubuntu):Triaged> <https://launchpad.net/bugs/1318366>
<menn0> should I wait?
<menn0> or __JFDI__
<wallyworld> jfdi
<sinzui> menn0, Yes please, your work predates the discovered of the regressions
<menn0> sinzui: ok thanks
<thumper> ah fark
<sinzui> I will remove find something other than __ to avoid the markdown conflict
<sinzui> CI will accept underscores and non- underscores for fixes-nnn to avoid the issue.
<sinzui> I will remove the regression tag on 1.20 since there is no test showing the regression at this time
<sinzui> I mean I removed "ci" from the bug 1350493 since ci didn't see the regressions
<_mup_> Bug #1350493: 1.20.x local provider not running apt-get update <charms> <regression> <juju-core:Triaged> <juju-core 1.20:Triaged> <https://launchpad.net/bugs/1350493>
 * thumper rolls all the instructions into one
<thumper> wallyworld: for some reason my 1.20 base branch didn't have upstream 1.20
<thumper> merge accepted
<menn0> thumper, wallyworld: here's the big 1.20 mgo change: https://github.com/juju/juju/pull/435
<wallyworld> looking
<thumper> menn0: oh, only 59 files?
<menn0> thumper: yeah sorry. I tried to make it more but couldn't find anything else to search and replace.
<thumper> heh
<thumper> I say if all the tests pass, shipit
<wallyworld> menn0: ty, +1
<menn0> thumper: I haven't run all the tests but most of what's in the state and worker directories
<menn0> merging now
<davecheney> thumper: good news
<davecheney> almost all the uses of authorizer.GetAuthEntity
<davecheney> are in type switches
<davecheney> so they are the same as a type switch on authorozer.GetAuthTag()
<davecheney> thumper: and the ones that aren't when they get the entity, they just take it's tag anyway
<davecheney> spot the bug
<davecheney>                 loggedInUser := api.getLoggedInUserTag()
<davecheney>                 if loggedInUser != argUser.Tag() {
<davecheney>                         result.Results[i].Error = common.ServerError(fmt.Errorf("Can only change the password of the current user (%s)", loggedInUser.Id()))
<davecheney>                         continue
<davecheney>                 }
<davecheney> ^ getLoggedInUser returns nil if the logged in user isn't a user
<davecheney> say a machine or somethig
<davecheney> so returning the error would panic the server
<thumper> heh
<davecheney> so i guess there isn't any coverage of this path ...
<thumper> I guess not
<davecheney> thumper: you're a winner
<wallyworld> thumper: your change merged \0/, now just waiting for menn0 's
<thumper> phew
<wallyworld> hurry up bot
<hazmat> is there any way to make the test runner print the name of test before it starts running it?
<axw> only with -gocheck.vv I think
<axw> which gives you all the logs too
<hazmat> i'm using that, sadly that's not doing the trick working w/ mgo though
<thumper> menn0: FWIW I got this failure on master: FAIL: upgrade_test.go:274: UpgradeSuite.TestLoginsDuringUpgrade
<sinzui> A recent commit to master broke deploy in 4 clouds. Something about /var/lib/juju/db not existing
 * sinzui gathers logs
<hazmat> axw, maybe it is.. its just lost in the undifferentiated output
<davecheney> thumper: https://github.com/juju/juju/pull/436
<davecheney> ^ with fix and test
 * thumper wonders if he broke trunk again
<davecheney> thumper: can I land that fix ?
<davecheney> menn0: you branch fialed to land
<wallyworld> menn0: good news for you - gomaasapi needs updating too!
<davecheney> yeah
<thumper> davecheney: not yet I don't think
<davecheney> just about to say that
<davecheney> thumper: ok
<davecheney> thumper: it wasn't really a question, more 'can I use the magic string to land it'
<thumper> davecheney: I'd rather you didn't just now
<davecheney> ok
<waigani> thumper: https://github.com/juju/juju/pull/437
<axw> wallyworld: https://github.com/juju/juju/pull/431
<axw> fixes the manual provider regression
<wallyworld> looking
<axw> for real this time
<axw> verified on the CI machine
<sinzui> thumper, https://bugs.launchpad.net/juju-core/+bug/1350633
<axw> wallyworld: also https://github.com/juju/juju/pull/430 unbreaks something I changed in the previous change
<axw> wallyworld: thanks
<wallyworld> np, thanks for fixing
<axw> just thinking, maybe it'd be better to return an error if the output is something else
<axw> i.e. not "no-agent-dir" or whatever
<wallyworld> i wondered that
<axw> then we'd see it in the output
<wallyworld> yep
<wallyworld> so long as it works in all circumstances
<axw> it's only going to consider stdout still
<axw> so it should be fine
<thumper> sinzui: ok, on it
<perrito666> axw: tx for the review on restore
<axw> perrito666: nps
<perrito666> I was really needing a second pair of eyes on that thing
<thumper> sinzui: fuck fuck fuckity fuck, found it (I think)
<thumper> yep
 * thumper gets a patch ready
 * thumper thinks of how to test it
 * thumper wonders why the existing test didn't fail
<menn0> davecheney, wallyworld: back from lunch. I'll deal with the failed merge after the team meeting.
<wallyworld> np
<menn0> thumper: do you have more detail on the UpgradeSuite.TestLoginsDuringUpgrade failure you saw?
<thumper> menn0: only the scrollback
<thumper> I'll look in a miute
<sinzui> thumper, great the --debug I ran didn't give me any more information than the console output. I did find another test instance that has be deleting for more than a day in HP. good I get to write a support ticket
<thumper> sinzui: I know what the problem is, just not sure why the tests didn't catch it
<perrito666> natefinch: you are not around for the meeting right?
<perrito666> davecheney: its odd, you are the one I hear the best next to jeese
<perrito666> and I think we are as far apart (network wise) as topologically possible
<davecheney> perrito666: hangouts appear to be point to point based, so some sound ok, others are complete disasters
<perrito666> well, mystery :) Ill try to have more meetings with you :p I hear you better than almost everyone else
<perrito666> ok ppl almost midnight here, see you all tomorrow, cheers
 * perrito666 turns into a pumpkin
<davecheney> perrito666: it's because I have a loud mouth
<menn0> davecheney, wallyworld: I don't understand why this happened: https://github.com/juju/juju/pull/435#issuecomment-50702449
<davecheney> menn0: toptip: don't trust godeps
<davecheney> i think it's fucked
<davecheney> it tells you it's updated to the correct rev
<davecheney> but it lies
<wallyworld> huh?
<wallyworld> gomaas was never updated
<menn0> hmm ok
<wallyworld> was it?
<wallyworld> gomaas also needs the import path changes
<wallyworld> afaik, godeps works ok now that it has the -f option
<davecheney> wallyworld: your experience differs from mine
<wallyworld> :-
<wallyworld> (
<davecheney> i have found it to be unreliable since growing the ability to update if a rev is missing
<wallyworld> ok, shame
<wallyworld> i wish Go as a platform supported something better
<wallyworld> not like this problem is new or anything
<menn0> davecheney, wallyworld: well I look at my current gomaasapi copy and it indeed has references to labix.org/v2/mgo/
<menn0> so I have no idea how builds and tests are working
<davecheney> menn0: then the hash your using isn't the same one as dependencies.tsv
<wallyworld> menn0: i think you still have labix source locally
<wallyworld> but the bot doesn't
<thumper> aarg!!!
<thumper> found out why the tests passed
<wallyworld> and......
<davecheney> wallyworld: menn0 yeah, that could be it
<wallyworld> drumroll
<menn0> yep, that's exactly it
 * davecheney holds breath
 * menn0 deletes the old repo
 * davecheney is breathless with ................ anticipation
 * wallyworld taps fingers
 * wallyworld holds breath
<davecheney> OUT WITH IT MAN!
<thumper> wallyworld: mocking
<wallyworld> ah
<wallyworld> ffs
<wallyworld> \o/
<thumper> s.PatchValue(mongo.AvailSpace, <-- said a constant
<thumper> new function makes sure the directory exists
<davecheney> wallyworld: let me tell you about apiserver/testing/fakeauthorizer some day
<wallyworld> davecheney: noooooooo!
<davecheney> wallyworld: thumper will tell you all about it when he tucks you in next week
<wallyworld> ooooh
<wallyworld> can't wait
 * wallyworld likes thumper's good night kisses
<axw> menn0: did you update the gomaasapi rev in dependencies.tsv in 1.20?
<axw> I bumped it in master only
<davecheney> axw: that'll be it
<menn0> axw: yep I'm just pushing that now
<thumper> wallyworld: https://github.com/juju/juju/pull/438
<menn0> axw: it took me a while to figure out why everything worked on my machine without that change. turns out I still had the old labix mgo hanging around
<wallyworld> looking
 * thumper fixes 1.20
<wallyworld> thumper: goes to show one has to be careful when writing mocks - just the correct bits need to be mocked out and nothing else
 * thumper nods
<thumper> damn git and it's auto commit shit
<wallyworld> "damn git" without the qualifier is what you meant i think
<thumper> wallyworld: and the backport https://github.com/juju/juju/pull/439
<wallyworld> hmm, where has i seen that diff before?
<thumper> sinzui: I do like the __JFDI__ flag, and the bold actually fits
 * thumper has quick dogwalk before school ends
<axw> review for https://github.com/juju/juju/pull/440 please? should fix the windows bootstrap regression
<menn0> wallyworld: I can see that the test run for the 1.20 changes already has at least one failure
<menn0> :(
<menn0> looking in to it now
<wallyworld> ok
<axw> wallyworld: I don't follow your comment about precise
<axw> I'm just using "trusty" because the series is used to infer the OS
<axw> it could be precise, quantal, trusty, ...
<wallyworld> axw: i thought that people running precise would get confused if they saw a /var/lib/juju/data/trusty dir
<wallyworld> "wtf, i'm on precise, why is juju saying trusty"
<thumper> axw: is there no other reasonable series we can use at that callsite?
<axw> it won't be in there
<thumper> not one that is passed in?
<axw> wallyworld: it'll just be /var/lib/juju
<menn0> wallyworld, axw: does this ring any bells? http://paste.ubuntu.com/7910716/
<wallyworld> axw: oh, ignore me
<menn0> it's failing on 1.20 for me with the newer mgo
<axw> thumper: I could just change it to "/var/lib/juju" and do away with the call altogether
<wallyworld> axw: i misread it, sorry
<menn0> in CI too
<axw> menn0: looking
<wallyworld> axw: that helper function is what i was referring to
<wallyworld> doh
<menn0> axw: the test itself is the same in master
<axw> menn0: hmm no sorry
<menn0> axw: thanks. I'll keep digging.
<thumper> menn0: I think I have seen that intermittently once or twice
<menn0> thumper: it could be that the timeout is a little tight
<menn0> and perhaps the fix to this panic changes mgo's timing. the test is about watchers.
<wallyworld> menn0: that error doesn't ring a bell. the only wather timing issues i know of are in state/watcher
<wallyworld> axw: my vote is just to use /var/lib/juju with a TODO
<axw> righto, will change
<menn0> now I can't get that test to fail on my machine. I'm going to increase the timeout a bit.
<wallyworld> menn0: don't you just love tests with timeouts? sigh
<menn0> wallyworld: well the timeout is only in case the code under test doesn't work ... but unfortunately the code needs most of that timeout to do it's thing
<wallyworld> menn0: "we" should be using channels and signals for tests that need coordination, not timeouts
<wallyworld> but most of our tests are bad in that respect
<thumper> hmm.... MachineSuite.TearDownTest... Panic: not authorized for query on presence.presence.beings (PC=0x414686)
<menn0> wallyworld: it IS using channels. the timeout is used for the maximum time to wait for something to come back from the channel. the code is dependent on the watcher frequency which is why it has to wait.
<menn0> so the test isn't THAT bad
<wallyworld> menn0: ok, sorry :-) i spoke without looking at the code
<menn0> it should probably patch the watcher frequency so it doesn't have to wait so long
 * wallyworld is scared by bad tests
<menn0> but I don't know if that would have other bad effects
<thumper> also...  Panic: local error: bad record MAC (PC=0x414676)
<wallyworld> menn0: there's a way to manually trigger the watcher
<wallyworld> thumper: that's a mongo 2.4 bug
<thumper> wallyworld: ok
<wallyworld> hopefully fixed in 2.6
<wallyworld> hence the drive to port juju to mongo 2.6
<menn0> wallyworld: this test appears to be fairly high level so I don't know if that applies
<menn0> I'm sure there's a way to make it faster
<menn0> but I'm not going to try and solve that now
<menn0> there's a TODO already
<wallyworld> menn0: yep. for now i'd to the minimum
<menn0> actually I think I see the problem
<menn0> there could be a race
<wallyworld> thumper:  that not authorised panic is a worry - it can happen with the new session copy stuff if there's a race
<wallyworld> since a wrong session without credentials is used to connect
<wallyworld> does it only happen every so often?
<thumper> wallyworld: cmd/jujud tests
 * thumper is running the tests again
<wallyworld> from what i've seen, given al the improvements to tests over the past several weeks, the cmd/jujud tests are the main ones still failing
<thumper> wallyworld: succeeded that time
<wallyworld> ah, intermittent tests
<marcoceppi> anyone know, in the actions spec
<marcoceppi> is it action.yaml or actions.yaml?
<wallyworld> yes
<wallyworld> :-P
 * marcoceppi waddles away
<wallyworld> sorry :-)
<wallyworld> i don't know which one
<marcoceppi> haha, it's fine
<marcoceppi> I'm trying to dig up the spec
<wallyworld> marcoceppi: in the code, it seems to be actions.yaml
<wallyworld> in juju-core code that is
<marcoceppi> wallyworld: interesting that it's pluarl but metadata and config aren't
<wallyworld> yeah
<wallyworld> i have had no involvement so can't comment
 * marcoceppi wonders if he should call it benchmark or benchmarks.yaml
<wallyworld> marcoceppi: well, it is environments.yaml for example
<marcoceppi> wallyworld: ah, true, good point
<marcoceppi> I guess pluarl is depending on how well the word sounds :)
<wallyworld> i'd go with plural
<marcoceppi> I'll go with plural form
<marcoceppi> yeah
<axw> thumper: sorry, I thought you were working on the master branch - I shouldn't have changed the status of that bug :)
<davecheney> uh,oh
<davecheney> lucky(~/src/github.com/juju/juju) % git pull upstream master
<davecheney> fatal: unable to access 'https://github.com/juju/juju.git/': Could not resolve host: github.com
<menn0> wallyworld, sinzui: the mgo fixes for 1.20 are in! *\O/*
<menn0> davecheney: I've had that a bit today as well (but my internet link has been a bit flaky too)
<wallyworld> menn0: whoo hoo
<wallyworld> ty
 * menn0 updates the LP bug
<davecheney> thumper, wallyworld I would like permission to land this, https://github.com/juju/juju/pull/442
<davecheney> I'm tired to skipping over this test failure
<wallyworld> davecheney: go for it
<davecheney> wallyworld: thanks, i helps as I'm working in that area daily
<wallyworld> no problem at all, nice change
<davecheney> Oh, this change was actuall Go 1.4
<davecheney> nm
<davecheney> what is important is there are some improvements in the race detector coming soon to 1.4 dev
<davecheney> and I want to be able to run juju under this improved race detector
<davecheney> given the plethora of problems we have at ht emoment
<menn0> ericsnow: ping?
 * ericsnow hides
<ericsnow> menn0: hi :)
<menn0> ericsnow: do you want to do a quick hangout re the backup work? it might be more efficient.
<ericsnow> menn0: sure, I really should have gone to bed hours ago, but at this point I'm not going to sweat it :)
<menn0> ericsnow: I don't have much time before I need to go so I promise it'll be quick :)
<menn0> ericsnow: https://plus.google.com/hangouts/_/gthfw6mxzrcsonn5bzqoqdb5iya?authuser=1&hl=en-GB
<menn0> ericsnow: https://plus.google.com/hangouts/_/gthfw6mxzrcsonn5bzqoqdb5iya?authuser=1&hl=en-GB
<davecheney> thumper, wallyworld large email about FakeAuthorizer sent to the list, enjoy!
<davecheney> jcw4|away: this test has been broken for weeks
<davecheney> http://paste.ubuntu.com/7911495/
<davecheney> is it on your schedule to fix ?
<davecheney> jcw4|away: the test failure stems from the caller expecting actions to be returned in a set order
<ericsnow> *END* *OF* *DAY*
<wallyworld> davecheney: jeez, it's not good when a mock breaks the contract implemented by the thing it is mocking
<davecheney> wallyworld: indeed
<davecheney> wallyworld: ideally, if I do this properly, we won't need a mock at all
<wallyworld> \o/
<davecheney> there will just be apiserver.TagAuthenticator
<davecheney> wallyworld: https://github.com/juju/juju/pull/443
<wallyworld> looking
<davecheney> wallyworld: not ugrent
<davecheney> urgent
<wallyworld> davecheney: already +1 :-)
<davecheney> this is part of unfucking FakeAuthoriser
<davecheney> wallyworld: it'll wait til the trunk is unblocked
<wallyworld> ok
<davecheney> i'm doing a poor man's git pipeline
<wallyworld> i miss lp for that
<marcoceppi> Why can't I use juju run against a subordinate?
<rogpeppe> is there an easy way to tell the current blocked status of commits to juju-core? i *think* that it's currently blocked by #1345638 (only) but it would be nice to have a definitive way to tell other than trying a $$merge$$
<_mup_> Bug #1345638: ec2 changes? rising failure rate in ec2 health checks <ec2-provider> <juju-core:Triaged> <juju-core 1.20:Triaged> <https://launchpad.net/bugs/1345638>
<rogpeppe> marcoceppi: i don't see why you shouldn't be able to
<rogpeppe> marcoceppi: what error do you see?
<marcoceppi> rogpeppe: currently getting this
<marcoceppi> juju run --unit subordinate/0 "cabs status"
<marcoceppi> ERROR subodinate/0 is not a principal unit
<marcoceppi> rogpeppe: should I file a bug?
<rogpeppe> marcoceppi: yes - it does seem to be a deliberate decision, but i can't immediately think of a reason why you shouldn't be able to do it.
<marcoceppi> rogpeppe: cool, this will really help unblock me with some stuff around benchmarking
<rogpeppe> marcoceppi: note: i wasn't involved in doing juju-run at all - there may well be a good reason why it doesn't allow it
<marcoceppi> rogpeppe: anyone you know off the top of your head i could ping for more clarification?
<rogpeppe> marcoceppi: fwereade might know. or axw. otherwise i think thumper is the man.
<axw> hmm, I don't know why
<fwereade> marcoceppi, rogpeppe: can't think why offhand. are there maybe issues around ssh to subordinate units that juju run falls foul of?
<rogpeppe> fwereade: i don't see why it should
<marcoceppi> fwereade: I can juju ssh to subordinate/0 without issue
 * marcoceppi is scouring the mailing list atm
<fwereade> marcoceppi, it's evidently not that then :)
<marcoceppi> I'll open a bug and see if thumper or axw chime in
<rogpeppe> marcoceppi: how about proposing a trivial fix for the issue (just remove the unit.IsPrincipal check) and try to get a review off thumper?
<rogpeppe> marcoceppi: or that
<marcoceppi> rogpeppe: ah, was going to check next how hard it woudl be to patch
<marcoceppi> if it's just a line or two I'll do that
<rogpeppe> marcoceppi: it's just one if condition
<marcoceppi> rogpeppe: cool, I'll go that route then
<rogpeppe> marcoceppi: github.com/juju/juju/state/apiserver/client/run.go:68
<marcoceppi> and duke it out in a pull request
<marcoceppi> rogpeppe: ta!
<fwereade> marcoceppi, yeah, should be a trivial fix -- IIRC AssignedMachineId does work for subordinates, so just drop the IsPrincipal() check and see what happens
<fwereade> marcoceppi, get thumper's opinion on the PR, though, he might remember some important reason I've forgotten
 * fwereade observes that rogpeppe said all that already
 * fwereade slinks off
<marcoceppi> fwereade: ack, I'll take a stab at it later tonight and just work around it for now. I'd want to compile/test as well to make sure it addresses my issue and actually works
<rogpeppe> :-)
<marcoceppi> thanks for the help fwereade and rogpeppe o/
<axw> can someone review please: https://github.com/juju/juju/pull/445  <- fixes a critical bootstrap bug on master, 1.20 will come shortly
<TheMue> axw: *click*
<voidspace> axw: change looks fine to me (I'll let TheMue do formal review)
<axw> thanks
<voidspace> axw: the PR says ""With recent changes, we were leaving the installation of mongodb until too late"
<voidspace> axw: *which* changes made this difference?
<axw> voidspace: thumper fixed a bug where we were reinstalling/restarting the upstart service unnecessarily
<axw> but left the installation bit where it was
<TheMue> axw: +1
<voidspace> ok, cool
<axw> TheMue: thanks
<voidspace> just wanted to understand the need
<TheMue> axw: and btw thx for the initial comment describing WHY and not WHAT has changed.
<TheMue> axw: just reviewd another PR this morning where the motivation for the change was missing
<axw> no worries (though evidently could've been better). I like to know why things are done too ;)
<TheMue> axw: yeah, helps when doing the review
 * TheMue has to admit that he has to improve himself here
<voidspace> heh, all round I think :-)
<TheMue> btw, this morning Iâve seen a pattern to avoid a large number of arguments. here the args are in a struct and this is passed as variadic
<TheMue> inside the function it is checked if 0 or 1 of these structs is passed
<TheMue> and then the values are checked or a default is taken
<TheMue> somehow this looks a bit strange
<TheMue> what I like more is a pattern by Rob which can be found here http://commandcenter.blogspot.nl/2014/01/self-referential-functions-and-design.html
<TheMue> itâs a bit more code, but when used it reads really good
<TheMue> fwiw ;)
<axw> that would be quite a lot of code, seems like it'd be overkill except in public APIs
<axw> it is neat
<axw> can't say I've seen any optional/variadic struct signatures - that sounds a bit unusual for the codebase
<TheMue> axw: I found it in state, one already exists and one has copied this in the PR Iâve reviewd
<TheMue> axw: one moment, will look for the file
<TheMue> axw: oh, just have seen that itâs in a testing package, testing/factory/factory.go, line 88
<TheMue> axw: so for testing code it may be ok
<axw> I see
<axw> I'd be tempted to make a second function, MakeUserDefaults
<axw> which calls the other with default values
<marcoceppi> Is there someone I need to ping or a review queue for pull requests agianst core?
<TheMue> or you have to pass a struct but it can be empty (which leads to defaults)
<TheMue> marcoceppi: the OCR (see https://docs.google.com/a/canonical.com/spreadsheets/d/1iQLLOWrjzxddm5VhYWYi0-2k3xI6wTMlpkvnVNJCYGY/edit#gid=0) can be pinged
<TheMue> marcoceppi: or simply asking here
<TheMue> marcoceppi: you talk about 447? change looks ok but Iâm missing a change in the according unit tests
<marcoceppi> TheMue: I don't think the unit tests ever covered this. When I ran the test post-change it still worked
 * marcoceppi is really not that good at go
<marcoceppi> TheMue: http://paste.ubuntu.com/7912806/
<TheMue> marcoceppi: yeah, we have several uncovered aspects ;)
<marcoceppi> since it's removing a restriction that was not already covered, how would you recommend I proceed?
<TheMue> marcoceppi: so based on the existing test base and your live tests itâs OK. if there before would have been a test expecting an error this would fail now
<marcoceppi> TheMue: right, I checked for that but then I read too much golang and got dizzy ;)
<TheMue> marcoceppi: adding a test for a removed restriction, hmm, dunno how to do it. only by removing an existing test like described above. but so?
<TheMue> marcoceppi: then I would say LGTM and it can be merged
<TheMue> marcoceppi: but hey, dizzy by golang? no :D
<marcoceppi> ideally I'd want to s.State.AddService('subordinate') but I have no idea how to distiguish a service as a subordiante
<marcoceppi> then make sure that subordinate reports back it's units in run_test.go around line 77
<marcoceppi> so regressions don't occur
 * marcoceppi does some more digging
<voidspace> axw: ping, you still around?
<axw> voidspace: pong, I am
<voidspace> axw: so I'm removing the code that opens the stateport to the outside world in the various providers
<voidspace> axw: I've done ec2 and openstack
<voidspace> axw: azure is slightly different
<voidspace> axw: provider/azure/environ.go
<voidspace> axw: it looks like I just delete the state-port endpoint, lines 794+
<marcoceppi> yup, I'm over my head
<voidspace> axw: does that sound right to you?
<axw> voidspace: looking/refreshing memory
<voidspace> sure :-)
<marcoceppi> yup, I'm in over my head
<axw> voidspace: while you're here, can you delete that TODO in getInitialEndpoints please
 * TheMue laughs about http://geek-and-poke.com/geekandpoke/2014/7/31/hansel-and-geekel
<axw> voidspace: yep, you can just remove the StatePort bits
<voidspace> axw: okey-dokey, and thanks
<axw> nps
<axw> voidspace: ooh, hold on
<axw> complicated
<voidspace> axw: my only concern would be if it prevents us using the *local port* too
<axw> if we just remove it, listPorts will start showing StatePort
<voidspace> axw: as available?
<axw> it won't
<axw> voidspace: actually I don't think it matters. for some reason the code tries to mask the state port from the result of Ports
<axw> but... a unit should not be opening that port
<voidspace> axw: and why would it matter if a unit opens that port?
<voidspace> axw: unless the unit is deployed to a state server I guess
<axw> well, it'll be opening up mongo if the unit is running on a state server
<voidspace> which we allow
<voidspace> rught
<axw> right
<voidspace> *right
<axw> I think we should handle that at a higher level though
<voidspace> axw: right, it shouldn't be the job of every separate provider to prevent that
<axw> voidspace: so I think the idea is that we don't want to report that we've internally opened a port, but I actually don't know what that affects
<axw> if anything
<voidspace> we don't want to report that we've opened it? But the change is that we *don't* open it. So if the desire is to not report it, then surely that won't change...
<axw> upgrades
<axw> an existing instance will have opened it
<axw> if we then remove the port from the mask, it'll show up
<voidspace> ah
<voidspace> security by obscurity?
<voidspace> in the hope that no-one will ever read the source code
<voidspace> or the logs
<axw> I don't know if that's the point - I hope not
<voidspace> heh
<voidspace> maybe just not to leak internal details to user facing information
<voidspace> if they're asking which ports are open they *probably* want to know which ones *they* opened
<voidspace> nonetheless, I have a test failure due to this
<axw> voidspace: I'm just looking at the firewaller; looks like it's to stop the firewaller from closing ports it didn't tell the instance to open
<voidspace> so l will go on lunch
<axw> enjoy
<voidspace> axw: ah, ok
<voidspace> axw: what's the implication of that?
<axw> voidspace: we need to preserve the mask
<voidspace> axw: surely that's good - if we no longer mask the state port it *will now* be closed on upgrade
<voidspace> which is what we want
<axw> heh I guess so :)
<axw> I'm sold
<voidspace> it means we don't need an explicit upgrade step to close the port...
<voidspace> :-D
 * voidspace lurches to lunch
<jam1> voidspace: better to lurch towards lunch, than to lurch during/after lunch, I guess
<voidspace> heh
<voidspace> I lurch a lot
<mattyw> fwereade, ping?
<wallyworld> mgz_: 1:1 time
<mattyw> fwereade, If possible I'd like to schedule some time with you to talk to emerald squad about some stuff - I was going to shove something in the diary - wondered if you had a preference of timing?
<perrito666> morning
<TheMue> perrito666: morning
<rogpeppe> fwereade: i'd appreciate your review of this since we discussed it recently, if you have a little time: https://github.com/juju/charm/pull/31
<rogpeppe> other reviews also appreciated, please
<voidspace> TheMue: jam1: coffee on the boil - be at standup in 3 minutes or so...
<jam1> kk
<TheMue> just fetched my headset
<voidspace> in
<TheMue> voidspace: afk for lunch, so weâll talk later
<voidspace> TheMue: sure, I have to finish this ticket first anyway
<wallyworld> katco: mgz_: axw: still in other meeting, will ping soon for standup
<perrito666> hey congrats and thanks to the people involved in the style and review guide, that helps a lot
<jam1> cmars: thanks to your patch I did get the client side stuff landed today.
<perrito666> jam1: hey, have a moment?
<cmars> jam1, excellent
<bac> hi mgz_, are you using jenkins-github-lander on your CI?
<cmars> jam1, i'm updating my login API accordingly
<jam1> what's up perrito666
<rogpeppe> cmars: any chance you could take a look at https://github.com/juju/charm/pull/31 please, as it's changing some of your code, i believe? (i got agreement from fwereade that this was a reasonable way to move forward)
<bac> sinzui: ^^
 * cmars takes a look
<perrito666> jam1: some time ago you asked me about a running aws instance and also to vlad, how do you see who does the instance belong? I see one running since the 24th and seems to be a leftover state server
<perrito666> but I cannot determine who does it belong to
<jam1> what region is it in ?
<perrito666> us-east-1
 * thumper pops on briefly
<thumper> mattyw: I'm going to take the names branch for user tags, unless you want to move it forwards
<thumper> mattyw: ok with that?
<jam1> perrito666: the only one I see in us-east was started July 31, 2014
<perrito666> jam1: ah, cool, it was destroyed yesterday then :) sorry I made a todo note to ask you when I noticed the instance yesterday
<jam1> perrito666: generally I know because the juju environment name is part of the security group, and wallyworld is the only one that names it 'amazon'
<perrito666> ehh lol
<jam1> perrito666: and I ask that people name their environments with their name in them
<jam1> like mine is "amz-jam"
<perrito666> I thought the user was stored somewhere in the aws web
<jam1> perrito666: I would have hoped IAM credentials could let you track that, but I haven't seen it anywhere
<perrito666> jam1: I do too but amazon was a bit too generic
<mattyw> thumper, I was just commenting on the pr actually
<mattyw> thumper, I've got a 'problem' with it - if you want to carry it on I'm fine with that
<thumper> did you comment your problem?
<mattyw> thumper, I will have done in about 2 minutes
<thumper> ok
<jam1> perrito666: we might also be able to grab the userdata and parse it, but I've just always gone off the security group, and when not sure, just start asking everyone :)
<thumper> I'll read in the morning
 * thumper heads to bed
<thumper> night all
<perrito666> jam1: will keep in mind for the future, thank you
<wallyworld> katco: axw: mgz_: finally finished meetings, standup?
<katco> wallyworld: omw after refreshing coffee.
<wallyworld> kk
<cmars> rogpeppe, no major objections, but I have a question about validating Reference to URL conversion, commented on the PR
<rogpeppe> cmars: you can't stop it, but you also can't stop a user just setting a URL.Series to ""
<rogpeppe> cmars: if we see people doing it, it should be an obvious smell
<cmars> rogpeppe, malicious abuse of the API is less of a concern than unintended side effects. a conversion function could catch and prevent a class of defects when using the juju APIs
<rogpeppe> cmars: if we really wanted to, we could make both URL and Reference opaque (and incompatible) types, but that would be a much bigger change, and i honestly don't think the payoff is worth it. the problem is largely theoretical AFAICS.
<rogpeppe> cmars: we already have a conversion function
<rogpeppe> cmars: just nothing to stop a deliberate type conversion.
<rogpeppe> cmars: isn't doing (*charm.URL)(ref) just as much an abuse of the ABI as url.Series="" ?
<rogpeppe> cmars: what's the worst that can happen if a series is left unspecified anyway?
<rogpeppe> cmars: ISTM that this is similar to the "you can put the wrong constant in a typed constant" problem - yes, it's a theoretical problem, but it's not one that seems to be an issue in practice.
<rogpeppe> cmars: also, it's easy to statically check for type conversions like this
<cmars> rogpeppe, how would you check for them? just curious
<rogpeppe> cmars: it'd be easy enough to write a little go program that used go/types (that would guarantee 100%) but just a grep for '\(\*charm\.URL\)\(' would be pretty close, given gofmt'd code
<perrito666> say I found a bug and I already know the fix, do I need to also create the bug in launchpad?
<perrito666> or can I just send the fix with the explanation
<rogpeppe> perrito666: i'd do the latter. but perhaps i'm just lazy :-)
<natefinch> perrito666: usually filing a bug is a good idea so that if someone comes from an older release and complains about the bug, we can know it's fixed in the current releasre
<rogpeppe> perrito666: although, perhaps best to add the bug, because of what natefinch says
<perrito666> rogpeppe: yeh, he is the boss in my case :p
<perrito666> so if he says jum, I ask how far
<rogpeppe> totally trivial PR for review, please: https://github.com/juju/txn/pull/6/files
<cmars> rogpeppe, thanks. i think i'm ok with the types. still going over other aspects of the change. need some coffee :)
<rogpeppe> (one line change with no semantic implication)
<rogpeppe> cmars: cool.
<natefinch> anyone know how to manually update something in juju's db?  I need to set one property in a user's deployment that mgo doesn't support, so ideally I'd just go in and set it by hand.... but without the javascript console, I'm not sure if that's possible
<rogpeppe> natefinch: what property is that?
<rogpeppe> natefinch: also, why don't you have a js comsole?
<perrito666> natefinch: just use the mongo cli
<perrito666> rogpeppe: not installed by default
<sinzui> wallyworld, axw. Sorry 1.20 appears to be broken. the precise unit tests fail, precise deployments error, because there is no mongo
<natefinch> rogpeppe: the juju-mongodb doesn't have javascript support, I figured that would prevent us from being able to log in and just issue javascript commands
 * sinzui reports bug
<wallyworld> sinzui: hang on a se c
<wallyworld> sinzui: it is fixed, but CI is a couple of revisions behind
<rogpeppe> natefinch: i *think* most of the js runs client-side
<sinzui> wallyworld, \o/
<wallyworld> sinzui: i was worried too but i checked the revisons
<wallyworld> sinzui: i also live tested tip of 1.20 on ec2
<rogpeppe> natefinch: i've not had a problem using the js console on the juju db
<natefinch> rogpeppe: the property is the readonly property on a user
<natefinch> rogpeppe: ok, cool
<wallyworld> sinzui: CI was *2* revisions behind, so this next run may fail also
<sinzui> wallyworld, I see archive issues in some of the unit-test runs. I am trying a newer ami too
<rogpeppe> natefinch: mgo has a few back doors you can usually do stuff through
<wallyworld> sinzui: rev 1cd26425cac98adc4e9aa70efa4e23b70f026c1d is the good one
<sinzui> wallyworld, it will fail, it is getting the mongo error at the moment. I wont panic
<sinzui> noted, thank you wallyworld
<wallyworld> ok, i oaniced :-)
<rogpeppe> natefinch: e.g. http://godoc.org/labix.org/v2/mgo#Session.Run
<wallyworld> panicked
<wallyworld> np
<natefinch> rogpeppe: yeah, ideally I wouldn't have to write code, just run a quick javascript command through the mongo cli
<rogpeppe> natefinch: have you tried it?
<wallyworld> sinzui: i was going to contact you but i only *just* finished all my meetings
<natefinch> rogpeppe: not yet
<rogpeppe> natefinch: worth doing, i think
<sinzui> wallyworld, np, I was only 20 minutes into the investigation
<wallyworld> sorry
<natefinch> rogpeppe: the issue is that hackedbellini has a server in a really unusual bad state of being half-upgraded from 1.19 to 1.20, and he gets an error when trying to update the admin password saying the entry must not have both a roles field and a readonly field
<rogpeppe> natefinch: marvellous
<natefinch> he's the one with the server that somehow managed to upgrade from 1.18 to 1.19, even though that shouldn't be possible
<natefinch> so we're trying to get him upgraded to 1.20
<natefinch> This is the current error that is blocking the upgrade - mongo returns "system.users entry must not have both 'roles' and 'readOnly' fields"
<natefinch> when we try to set the admin password.  We should probably fix it in code, but I'm super busy right now, so I was hoping to give him a quick javascript command to run that would unblock him by removing the readOnly field
<natefinch> brb
<cmars> jam1, can you PTAL at my login API versioning branch, just rebased against master, https://github.com/juju/juju/pull/392
<hackedbellini> rogpeppe: yes, we were affected by this issue: https://bugs.launchpad.net/juju-core/+bug/1325034 (it was actually my boss who opened it)
<_mup_> Bug #1325034: juju upgrade-juju on 1.18.3 upgraded my agents to 1.19.2 <upgrade-juju> <juju-core:Triaged> <https://launchpad.net/bugs/1325034>
<hackedbellini> Then we tried upgrading from 1.19 to 1.20 and we had a problem because the installation was missing HA
<hackedbellini> thumper said to me to try to change the agent.conf to read "upgradedToVersion: 1.18.4" so it would do the HA setup (that appears to only be triggered in the 1.18 => 1.20 migration and not the 1.19 => 1.20)
<hackedbellini> by doing that we hit that other issue natefinch described
<rogpeppe> hackedbellini: good luck :-)
<perrito666> gsamfira: ping
<natefinch> back
<natefinch> rogpeppe: how do I get the password to use to log into mongo in an existing environment?
<rogpeppe> natefinch: from a machine agent config file
<natefinch> rogpeppe: ahh ok
<gsamfira> perrito666: pong
<perrito666> natefinch: statepassword iirc in /var/lib/juju/agents/machine-0/agent.conf
<marcoceppi> How do I create a subordinate in a core test? I've tracked down a few examples but the entire testing side of the core project is quite mysterious. if someone had a few moments to help me out that'd be awesome
<rogpeppe> cmars: are you still reviewing?
<fwereade> marcoceppi, heyhey
<marcoceppi> o/
<fwereade> marcoceppi, it can indeed be a bit of a hassle, but give me a sec and I'll try to find you an example at a suitable level
<voidspace> rebooting to (hopefully) fix some odd test failures that I think are due to machine load
<marcoceppi> fwereade: that would be awesome. I understand this entire part of the test. Just no idea how to s.AddTestingSubordinateCharm()
<marcoceppi> or whatever the method name will be
<marcoceppi> I guess it would be AddTestingCharm, then s.State.AddSubordinateService or something such
<fwereade> marcoceppi, in short you have to do all the steps manually: ie add a subordinate charm, create a service, add a relation with the principal service, and then have the principal unit enter scope
<fwereade> marcoceppi, see TestDestroySubordinateUnits in client_test.go
<marcoceppi> fwereade: so I found something like that in another module of the project
<marcoceppi> fwereade: ack, will look! Thanks
<ericsnow> fwereade: thanks for the review...it's really helpful :)
<fwereade> marcoceppi, if you feel like being awesome, you could take a look at testing/factory and add a MakeSubordinate method :)
<fwereade> ericsnow, cool
 * marcoceppi scratches chin
<marcoceppi> well I do like being awesome
<fwereade> ericsnow, if there's anything that bears discussion let me know and we can hangout
<ericsnow> fwereade: I keep forgetting that I'm only about a meter below the waterline while chipping at the iceberg that is juju
<fwereade> ericsnow, yeah, there's an awful lot to take in I'm afraid
<ericsnow> fwereade: menno also gave me some good feedback last night before I went to bed
<fwereade> ericsnow, excellent
<rogpeppe> fwereade: any chance you might be able to take a look at https://github.com/juju/charm/pull/31 ?
<ericsnow> fwereade: will you have some time to chat in a little while (I have standup soon)?
<fwereade> ericsnow, sure, just ping me when you're free
<ericsnow> fwereade: will do, thanks
<mattyw> fwereade, I'm going to put something in the diary for a little talk with green squad if that's ok? probably after the next sprint
<perrito666> natefinch: stand up?
<mattyw> fwereade, unless you have spare time tomorrow
<natefinch> perrito666: coming
<fwereade> mattyw, I should be able to do tomorrow
<fwereade> mattyw, morning would be better than afternoon I think, my time sense is still a bit messed up and I start feeling a bit sleepy and useless at lunchtime
<mattyw> fwereade, welome to my life
<mattyw> fwereade, just sent an intivte, probably won't take an hour
<ericsnow> fwereade: you available?
<fwereade> ericsnow, sure, 5 mins?
<ericsnow> fwereade: sounds good
<perrito666> rogpeppe: have a sec?
<rogpeppe> perrito666: i have a meeting in 4 minutes
<rogpeppe> perrito666: but if you make it fast... :-)
<perrito666> rogpeppe: ok, ill try
<perrito666> I made as you know a tar/untar wrapper which works very well except when untaring symlinks
<wwitzel3> trying build juju-1.19.3 and I'm getting launchpad.net/juju-core/testing/testbase cannot find pacakge
<wwitzel3> godeps -f -u is running cleanly
<rogpeppe> wwitzel3: perhaps dependencies.tsv hasn't been updated
<perrito666> do you happen to know where is the link stored in the header? I get a fileinfo struct and I am pretty sure its in the Sys() struct but I haven't looked at it yet
<rogpeppe> perrito666: isn't it in Header.Linkname ?
<perrito666> rogpeppe: aghh, I was looking at the wrong place, thank you again
<rogpeppe> perrito666: np :-)
<wwitzel3> rogpeppe: I checked out to the 1.19.3 tag, I assume that the dependencies.tsv would of been updated accordingly when that tag was commited.
<rogpeppe> wwitzel3: worth checking
<wwitzel3> rogpeppe: I have no idea what I'm looking for .. I have no clue what version of juju-core/testing 1.19.3 is supposed to be pinned on.
<wwitzel3> rogpeppe: or should I be building 1.19.3 from launchpad and not github?
<rogpeppe> wwitzel3: i don't know, i'm afraid
<rogpeppe> wwitzel3: perhaps sinzui or mgz would be more help
<wwitzel3> thanks :)
<sinzui> wallyworld, no, but I cannot prove it
<hackedbellini> natefinch: any news?
<sinzui> wwitzel3, interesting question
<marcoceppi> is there any formatting guidelines for core? like 80-col wrap, etc?
<sinzui> wwitzel3, while tags were not migrated to github, we can add the tags we need.
 * marcoceppi just found go fmt
<sinzui> wwitzel3, do you want the tag, or do you just want to see what the deps were for the release?
<wwitzel3> sinzui: well my issue was that there is a 1.19.3 tag, but checking that out, running godeps, and attempting to build results in some package not found errors.
<sinzui> wwitzel3, I think developers moved packages again.
<wwitzel3> sinzui: refercing juju-core/testing/testbase which is a package that doesn't exist anymore I think.
<sinzui> wwitzel3, When CI find the problem in a test, we ask that the package be put back...obviously we have not tested 1.19.3 in 2 months
<wwitzel3> sinzui: but I answered my own question, if there is a 1.19.3 in lp, I will just build it from there.
<natefinch> hackedbellini: I'm handing you off to wwitzel3.  He'll take care of you.
<wwitzel3> sinzui: yeah, I understand, I'm just trying to replicate the environment that hackedbellini's has
<wwitzel3> sinzui: so was trying to get a local provider up and running with 1.19.3
<sinzui> wwitzel3, maybe you want the tarball that was that release?
<wwitzel3> sinzui: seems like a good solution :)
<sinzui> wwitzel3, This is the release https://launchpad.net/juju-core/+milestone/1.19.3
<sinzui> wwitzel3, I just checked github/lp . 1.19.3 is only in github, even if it was in  Lp, the packages would be moved. I think the tarball or deb is the way to get what the user has
<natefinch> hackedbellini: wwitzel3 is taking care of you
<natefinch> hackedbellini: I had to hand you off because I got assigned some critical work.  Wayne will get it sorted out for you, though.
<natefinch> hackedbellini: and he's less busy than me, so he's less likely to make you wait
<rogpeppe> cmars: gentle nudge about https://github.com/juju/charm/pull/31
<sinzui> 1.20.2 has a new regression in precise unit tests. I am looking for a common cause of the failure https://bugs.launchpad.net/juju-core/+bug/1350911
<_mup_> Bug #1350911: precise unit-tests fail in 1.20 <ci> <regression> <test-failure> <juju-core:Triaged> <https://launchpad.net/bugs/1350911>
<bodie_> https://github.com/juju/juju/pull/448 re. davecheney getting out-of-order Actions failing the apiserver test
<bodie_> very simple test fix to include a map which counts appearances instead of expecting actions in a specific order
<bodie_> +27, -9
<wwitzel3> when I deploy with local provider, why don't the containers show up in lxc-ls?
<rick_h__> wwitzel3: they should
<rick_h__> wwitzel3: sudo lxc-ls?
<wwitzel3> rick_h__: ahh that's probably it
<wwitzel3> rick_h__: thanks
<bodie_> sudo all the things!
<rick_h__> wwitzel3: np
<bigjools> hello juju people
<rick_h__> bigjools: party party
<bigjools> when a provider gets asked to start a machine up, is that dine in a go routine?
<bigjools> dine?  done
 * bigjools going to ping devs at random now
<natefinch> bigjools: are you asking if it's async or not?
<bigjools> natefinch: sort of, we want to put some polling in the maas provider and noticed it already has blocking Sleep calls in it
<bigjools> which is either great or horrifying
<natefinch> bigjools: it's at least the latter
<bigjools> I have few issues concurring
<natefinch> bigjools: so, everything is done in a goroutine.... it's just a matter of which one and what else wants to get stuff done on the same goroutine
<bigjools> natefinch: ok, so would be be ok to block the return until it acquires a machine?  And can the caller handler retries?
<natefinch> bigjools: the maas provider just does a POST on the start endpoint... it doesn't seem to wait very long for it to return, so I presume the serverside itself is async
<bigjools> natefinch: well I am asking about the provider here - we're changing the maas API to help with working out when an acquisition is successful, or failed.  It will need to poll an API endpoint for status.
<bigjools> so it sounds like it's ok to just block inside a loop that Sleeps;polls;Sleeps etc.
<hackedbellini> natefinch: no problem :)
<hackedbellini> so, wwitzel3, will we workaround the issue today? If you are busy, we can do it next week, no problem =P. I'll be here for more 2 hours and tomorrow I won't come to work
<jcw4> perrito666: does todays big news affect you much?
<perrito666> jcw4: nah, I dont think general population will be affected yet, macroeconomic issues take months to show in daily life
<jcw4> perrito666: figured, but since you'd mentioned it a few weeks ago thought I'd ask
<perrito666> jcw4: tx man, there was some incertitude, but its like when your girlfriend tells you "we need to talk" after you talk, wether the news are good or bad, its done and everything goes back to normal :p
<jcw4> perrito666: hahaha
<natefinch> dammit... I just saw that Andrew submitted a fix for the windows bug that I've spent the last day fixing
<perrito666> that happens a lot lately, we should be more vocal about what we are doing
<perrito666> there was some of that on last night discussion
<natefinch> My fault, I guess for not assigning the bug to myself.... I did post in response to the email about CI being blocked
<jcw4> natefinch: so what is the process if you see a bug?  Check for bug in lp and file if it's not there, and then assign to self?
<natefinch> jcw4: the assigning part is optional unless you want to fix it
<jcw4> natefinch: okay
<jcw4> so any self-initiated work to fix a bug should probably be tracked through lp then?
<natefinch> yeah, that way if someone comes along and sees it in an older version, we know it's been fixed, and if any developer sees it at approx. the same time, you don't have two people working on it at the same time (like what happened with me)
<jcw4> makes sense... I've avoided the bug list in lp for a while... I should probably start paying closer attention.
<perrito666> yo might also want to do some noise here
<jcw4> perrito666: +1
<perrito666> so someone will most likely remember what you said when someone else asks
<tasdomas> hi
<tasdomas> I have a gwacl question - since it's a bit early in the day for axw, could anyone help me?
<natefinch> maybe
<bodie_> hmmm...  I think I just yawned a yawn to make up for the grind of the last four days.  that was great.
<bodie_> it feels so good to see Actions firing off.
<tasdomas> natefinch, I'm working on the port ranges task and am at the moment changing the providers to operate on port ranges
<tasdomas> gwacl, however, does not seem to have the ability to open a range of ports at once, though
<natefinch> tasdomas: might have to be something you add, then
<tasdomas> natefinch, yeah, I figured that - was simply wondering if az
<tasdomas> azure api actually supports that
<natefinch> tasdomas: sorry, no idea. I would think so, but azure is wacky.   You'll have to look it up
<tasdomas> natefinch, thanks
<bodie_> hmmm, what's up with this jenkins build output? http://juju-ci.vapour.ws:8080/job/github-merge-juju/196/console
<natefinch> bodie_: trunk is locked
<natefinch> bodie_: the beatings will continue until morale improves
<natefinch> bodie_:   note the comment on your PR: https://github.com/juju/juju/pull/415
<natefinch> there's a couple blocking bugs
<bodie_> ah
<bodie_> natefinch, presumably to be found at LP/juju-core/bugs
<bodie_> +bugs*
 * perrito666 is becoming a tibetan monk while testing restore
 * bodie_ is confused by perrito666's sense of humor
<perrito666> bodie_: it requires to prepare a lot of things, run them and in the mean time wait
<perrito666> and meditate
<bodie_> perrito666, go into your mind palace like Sherlock Holmes and study the ineffable mysteries of reducing "if err != nil { return err }" statements Go :P
<bodie_> in Go*
<natefinch> man.... whenever I go to build something that isn't a go project, I am reminded of why go rocks so much.... there's no like 8 step process to download the code and set up the build environment and run the build.
<rick_h__> no, just magic /.. :P
<natefinch> there's no magic, it's all very derministic
<natefinch> deterministic... unlike my spelling
<natefinch> also, people who put the shell prompt in the text of their command line instructions need to be shot.  Thanks for ruining copy & paste.
<jcw4> natefinch: don't you think shooting is a little harsh? maybe a stern talking to?
<rick_h__> or maybe using your tools to select the copy/pasteable part?
 * rick_h__ ducks as he always does the $ command here
 * jcw4 too
<natefinch> jcw4: I didn't say with what I'll shoot them
<jcw4> heh; I'm hoping for old nerf guns
<natefinch> something smelly and sticky
<jcw4> :)
<natefinch> also shooting people who put relative links in their instructions without making it perfectly clear what the directory structure should look like
<jcw4> easy, just do: $ ln -s ../hooks/remember-absolute-paths.sh
<perrito666> natefinch: doen't your editor support block selection?
 * perrito666 hides
<natefinch> perrito666: It's the browser
 * natefinch squints at jcw4 
<jcw4> haha
<perrito666> natefinch: isn;t your browser your editor?
<natefinch> https://github.com/Tokutek/mongo/blob/master/docs/building.md
 * perrito666 waits for katco to say something
<natefinch> perrito666: no no, katco's editor is her browser... there's a difference
<jcw4> katco's an emacs zombie!?
<natefinch> yep
 * jcw4 ducks and hides
<rick_h__> hah, thought you were saying she's using that newish github thing that's nodejs and all JS
<natefinch> atom.io
<jcw4> atom?  I've tried it
<natefinch> I would if..... *drum roll*  their build instructions weren't a mile long
<jcw4> har har har
<natefinch> seriously: https://github.com/atom/atom/blob/master/docs/build-instructions/linux.md
 * jcw4 wonders if natefinch knows how long a mile is
<perrito666> OS with 64-bit or 32-bit architecture
 * perrito666 looks suspiciously
<perrito666> what exactly does that mean?
<natefinch> haha
<perrito666> like, dont do this in win 3.11?
<natefinch> heh, I was just typing that
<natefinch> I love installations that start with "curl this script and run it"
<perrito666> as long as it isnt sudo curl this
<natefinch> they didn't write sudo curl, but it doesn't work unless you sudo
<natefinch> https://github.com/joyent/node/wiki/Installing-Node.js-via-package-manager#ubuntu-mint-elementary-os
<perrito666> lol
<perrito666> "Ill leave this curl here, and if you sudo it, it will be your responsability"
<natefinch> That's also a pet peeve... if something needs sudo, just write sudo, don't assume I'm running as root like an idiot
<perrito666> that is a bit harsh on idiots
<natefinch> heh
<perrito666> Idiots most likely run user 1000
<natefinch> oh, hey, while I'm cloning crap that isn't go code... I heard a suggestion someone made a long time ago that I really like - they put all open source code in their GOPATH... even non-go code. So, like, I'm putting tokumx in $GOPATH/src/github.com/Tokutek/mongo  and atom in $GOPATH/src/github.com/atom/atom
<jcw4> i've been doing that too... not sure yet whether or not it'll be a good idea
<natefinch> I like it.... it means I never need to wonder where I put some code
<jcw4> I've been able to go get non go code on github :)
<natefinch> ha, yeah, that works
<jcw4> I get a build error, but the repo's there
<natefinch> it saves some typing, at least
 * natefinch is go getting atom
<perrito666> natefinch: lol, I nuke my GOPATH every now and then, but cant hurt to try
<natefinch> perrito666: sacriledge
<perrito666> natefinch: I treat my work machine storage as something ephemeral
<natefinch> perrito666: I periodically nuke individual folders because source control doesn't always do the right thing... but I keep around most of it
<perrito666> and I assume everything in repos to be re-fetchable or not safe to use
<natefinch> oh yeah, definitely.... I just don't like waiting :)
<bodie_> jcw4 must have missed the minor editor scuffle we had in here a few days ago
<natefinch> hazmat: you around?
<bodie_> there was nearly a discussion of the editor of the beast
<bodie_> vi, vi, vi
<jcw4> lol
<TheMue> yeah, vi(m) plus my little go plugin
<jcw4> I switched to vim a long time ago when I reasoned vi was more ubiquitous than emacs
<jcw4> but I still wish I knew emacs a little better
<TheMue> Iâm happy with vi since my time as admin in the 90s. itâs on each system, especially during server hopping, and always is quick when opening opening files with it
<hazmat> natefinch, yup
<hazmat> natefinch, currently in meetings
<hazmat> natefinch, free in 15m
<natefinch> hazmat: ok, let's talk then.  Trying to build tokumx with ssl (I presume that's possible)
<hazmat> natefinch, cool
<hazmat> natefinch, i think  trunk uses cmake instead of scons
<hazmat> of tokumx
<natefinch> hazmat: yeah, their build instructions use cmake
<natefinch> build warnings in production code are cute
<wwitzel3> lol
<natefinch> one of the very first things I did at my last job was to turn on "warnings as errors" and eliminate all warnings from the codebase.  Took a while, but... seriously, people.   Read the warnings and fix your damn code.
<wwitzel3> natefinch: I agree, I found that warnings as errors usually resulted in my fixing things that were about to be bugs anyway
<natefinch> yep
<natefinch> it also makes it a lot easier to see the real errors when you don't have 500 warnings :)
<wwitzel3> hah
<hazmat> natefinch, got time now?
<hazmat> i've got an 1hr till my next mtg
<hazmat> natefinch, have you tried building mongo from src?
 * hazmat remembers it being painful
<hazmat> and slow
 * perrito666 notices that his new bootstrap machine seems to lack /tmp
<natefinch> hazmat: yeah, I built mongo from source
<natefinch> http://askubuntu.com/questions/392664/how-do-i-build-mongodb-with-ssl-support-on-saucy
<natefinch> hazmat: I'm trying to run juju against tokumx, but the default version doesn't have SSL, which we use
<natefinch> hazmat: so I built from source, but I'm not sure how to build with SSL, wea hoping you'd already done that, but I guess not :)
<natefinch> hazmat: ahh, -D USE_SSL=ON
<hazmat> cool
<hazmat> natefinch, i was just using mgo test suite directly against tokumx dl bins
<hazmat> and writing txn programs against that
<natefinch> hazmat: sounds like we're doing nicely parallel operations, so I'll keep on seeing if it really is a "drop in" replacement... even if some of the mgo tests fail
<natefinch> parallel?  orthogonal?  one of those
<natefinch> neither duplicating nor conflicting
<natefinch> doh
<natefinch> Error 2
<natefinch> well, thanks for the informative error message :/
<natefinch> ug, lots of build errors in code with ssl in the name :/
<hazmat> natefinch, all dev libs installed?
<natefinch> hazmat: I think so
<hazmat> natefinch, mgo tests are exhaustive failure modes.. some of which i suspect are attuned to mongo's impl
<natefinch> hazmat: yeah, I assumed the mgo tests are probably testing stuff we don't depend on.... but I figured the best way to find out is to just try it
<hazmat> natefinch, agreed
<natefinch> I posted to the user forums, we'll see if there's an answer
<natefinch> https://groups.google.com/forum/#!topic/tokumx-user/KeZ_SJ_BUac
<hazmat> natefinch, re ssl errors you have libssl-dev ?
<natefinch> yep
<hazmat> natefinch, cool.. i'll give it a try as well
<hazmat> hmm
<natefinch> I installed all the libs I listed here: http://askubuntu.com/questions/392664/how-do-i-build-mongodb-with-ssl-support-on-saucy
<hazmat> natefinch, those look like unresolved refs to ssl includes.. and sure enough its not in their cmake lists
<natefinch> plus they needed libpcap-dev
<hazmat> natefinch, where do you see that?
<natefinch> hazmat: when I built it said Could NOT find PCAP (missing:  PCAP_LIBRARY)
<hazmat> interesting
 * natefinch apt-get installs all the things
<hazmat> somewhat curious why mongo (which also apparently needs it ) uses pcap
<natefinch> hmm... I don't remember having to install it for building mongo, at least the version I built back in December
<hazmat> natefinch, there is a cmake/FindSSL.cmake thingy
<natefinch> but maybe I had it already
<natefinch> for whatever reason
<natefinch> always inspiring to have your first encounter with your database be a pull request to fix their makefile :/
<hazmat> natefinch, have you built mongo before?
<hazmat> oh cool
<hazmat> i've had to custom patch it as well
<natefinch> can you share your patch?  My make skills are about on par with my Swahili
<natefinch> oops, didn't realize it was late already.  Gotta bail early today.  Email me the change if you can, otherwise I'll hack on it in the morning.
<natefinch> hazmat:  ^
<hazmat> k
<hazmat> was in ref to mongo, in ref to tokumx it looks like you need gnutls-dev
<arosales> any folks have the latest on where the microsoft support merge is currently at?
<thumper> sinzui: hey
<thumper> sinzui: the current test failure, is that just a normal test run? or something else?
<sinzui> thumper, ci is testing 1.20. Nothing seems normal today
<thumper> sinzui: do the devel tests fail on precise?
<sinzui> thumper sorry, we have many regressions that affect each branch differently
 * thumper sighs
<sinzui> thumper, devel and stable precise unit tests are broken for different reasons :(
 * hazmat notes nates not here.
<hazmat> built on the first try for me
<sinzui> thumper, I just sent an email summarizing my abdominal day. It lists 6 bugs, 5 of which are new in the last 12 hours
<thumper> sinzui: yeah, reading it now
<sinzui> Maybe I should have cheered that the win client works again after a 5 weeks of hate
<stokachu> in juju 1.20.x there seems to be a delay when the environment is bootstrap and when you can actually access the state api server
<stokachu> i get connection refused for about 4-5 seconds
<thumper> stokachu: which provider?
<stokachu> thumper, local provider with kvm container
<thumper> hmm...
<stokachu> i can create a bug with a reproducer
<thumper> sure, why not
<waigani> morning thumper are you still reviewing or can I push?
<thumper> waigani: push away
<voidspace> what's the default api port?
<voidspace> I mean, I could look it up...
<voidspace> 17070
<voidspace> what's the easiest way of getting a 1.18 juju?
<voidspace> does it involve bzr...
<voidspace> git tags seem to start at 1.19.3
<voidspace> to be fair that will work fine though
<waigani> thumper: PTAL https://github.com/juju/juju/pull/437
<wallyworld> sinzui: hi, i'm trying to understand the stale lock bug. where did you find stale locks? in /var/lib/juju/locks? did you remove files inside that dir to release the lock? the new implementation uses native flock which releases any lock held when the lock is closed or when the  process dies so i'm confused right now as to what is happening
<sinzui> wallyworld, I do indeed need to delete those locks.
<sinzui> wallyworld, I destroyed the env, but the lock still exists
<wallyworld> hmm
<sinzui> wallyworld, then when older juju runs...nothing
<sinzui> wallyworld, I can confirm 1-2 hours passes on some of the machines where no juju processes were running
<wallyworld> sinzui: the lock subdir inside /var/lib/juju/locks is meant to be removed when the template container is created. and even if there's a bug and it's not, when machineagent dies, it is supposed to be released since that's how flock works
<sinzui> :(
<wallyworld> ok, we will look into it
<wallyworld> :-( indeed
<wallyworld> sinzui: i've created and destroyed local provider environments several times without an issue so will be interesting to see what's happening here
<sinzui> wallyworld, would you like to visit the i386 slave which had a lock after 3 tries?
<wallyworld> yes please
<stokachu> thumper, sinzui https://bugs.launchpad.net/juju-core/+bug/1351083
<_mup_> Bug #1351083: API server inaccessible for roughly 5 seconds after bootstrap <api> <cloud-installer> <juju-core:New> <https://launchpad.net/bugs/1351083>
<sinzui> thank you stokachu
<stokachu> np :D
 * thumper goes to make another coffee before he falls asleep
<menn0> stokachu: I have a theory on that bug. Could you attach the API server logs to the ticket please?
<stokachu> menn0, sure lemme re-run it to get a clean log
<menn0> stokachu: I'm mainly interested in the logs from the time the machine-0 agent starts until it starts accepting API connections
<stokachu> menn0, ok ill get that narrowed down for you
<menn0> if the entire log isn't too big then don't bother about filtering
<stokachu> ok
<menn0> back in 10...
<stokachu> menn0, ok got the log added
<stokachu> wasn't much so attached the whole thing
<stokachu> took about 9 seconds for the api server to become responsive
<marcoceppi> Hey thumper: https://github.com/juju/juju/pull/447 on my phone, but could you take a look sometime?
 * thumper looks now at marcoceppi's pr, with sticky fingers
<marcoceppi> It's pretty small
<marcoceppi> But has a large impact on charm testing and benchmarking
<thumper> marcoceppi: +1
<marcoceppi> \o/
 * thumper was eating an almond croissant
<thumper> to go with the second coffee
<jcw4> Okay, I filed my first bug https://bugs.launchpad.net/juju-core/+bug/1351089
<_mup_> Bug #1351089: Isolation failure in sshstorage test <juju-core:New> <https://launchpad.net/bugs/1351089>
<jcw4> which is a simple test suite isolation issue
<jcw4> however, I can fix my own case by modifying SSHStorage.Put to use >| instead of > to get around my noclobber envar
<jcw4> and that seems like a reasonable change to me anyway.
<jcw4> arguments against?
<jcw4> I think we still need to fix the environment isolation for the test, but...
<marcoceppi> thumper: so now what?
<thumper> marcoceppi: we wait until the bot is unblocked by CI
<marcoceppi> thumper: cool, thanks. Looking forward to doing more minor little commits
<jcw4> per my comments above: https://github.com/juju/juju/pull/450
<thumper> marcoceppi: yay
<menn0> stokachu: well your bug isn't what I thought it might be. I'll add some thoughts to the ticket though.
<stokachu> ok thanks
<ericsnow> wallyworld: when you have a minute I have some persistence layer questions
<wallyworld> sure
<wallyworld> askaway
<ericsnow> for backups I'm storing the archive in env storage and the metadata in mongo (via a new state collection)
<ericsnow> I'm using a couple interfaces (DocStorage and FileStorage) to abstract that away from backups
<ericsnow> however for the actual implementation in state for the "doc" side, I feel a bit dirty hijacking a collection for something that's not actually part of state (backups are only *about* state)
<ericsnow> any thoughts on alternatives?
<ericsnow> also, I was talking to William about the storage abstractions I introduced as well as the env storage interfaces (and implementations)
<ericsnow> he suggested asking you what you thought about introducing a new top-level storage package to gather in the different interfaces and implementations
<sinzui> wallyworld, thumper the azure regression in devel might also be a cloud issue. stable is azure-deploy failed too for different reasons http://juju-ci.vapour.ws:8080/job/azure-deploy-precise-amd64/2061/console
<sinzui> wallyworld, thumper, but in both cases, azure-upgrade (bootstrap with 1.20.1) works
<ericsnow> the relevant PR: https://github.com/juju/juju/pull/426
<sinzui> oh, and azure-upgrade has not failed in 2 days, so newer jujus are broken
<wallyworld> ericsnow: there's also the blobstore stuff - a blob store takes a mongo db for the collection of namespaced paths, and a mongo db for the gridfs based blob storage
<wallyworld> ericsnow: the backups could be stored in a namespaced path "/backups/..."
<ericsnow> wallyworld: so when did you say you're getting us a nice persistence layer abstraction? <wink>
<wallyworld> the you'd have a BackupStorage Fascade to access then
<wallyworld> ericsnow: that abstraction is a while away, so much spaghetti to untangle
<ericsnow> wallyworld: yeah, I have sauce all over my fingers :)
<wallyworld> ericsnow: so if it were me, i'd create a BackupStorage interface that holds a ManagedStorage instance
<wallyworld> oh hang on
<wallyworld> you want to use file storage for the backups
<wallyworld> ok, i had thought there was talk of storing them in a separate mongo db
<wallyworld> so we could make them available on any state server
<wallyworld> because cloud storage is going away
<ericsnow> wallyworld: I'm not so concerned about the file side of backups at this point
<ericsnow> wallyworld: we can sort of the storage backend after we get backups done :)
<wallyworld> ericsnow: yep, so a BackupStorage interface can be done and the back end swapped out later
<ericsnow> my questions center more on storing the metadata in State and on a new top-level storage package
<ericsnow> wallyworld: yeah, that's exactly what I did :)
<wallyworld> ericsnow: so what we are doing with env.Storage() is actually removing that method off Environ completely
<ericsnow> wallyworld: that's fine, but the interfaces there (and several implementations) are still useful, no?
<wallyworld> yes, will be changing though, but if backup is already in palce, we will port it across when the time comes
<ericsnow> wallyworld: sounds good (on that point)
<wallyworld> i think it's ok to store backup collection in DB("juju")
<wallyworld> although if we think there may be more metadata type collections, we could use a new db
<ericsnow> makes sense
<wallyworld> but since schema migrations are coming, we could just do it the easy way for now and migrate later if needed
<ericsnow> +1
<wallyworld> so does that answer your question?
<ericsnow> regardless, I'm trying to do it in a way that makes it easy to switch underneath
<ericsnow> what about a top-level storage package?
<wallyworld> main thing is we have that BackupStorage interface in place, and if can use an environs.Storage() interface for now
<wallyworld> what would go inthe top level storage package?
<ericsnow> the problem is that we can't use environs.storage.Storage in backup (due to circular imports)
<ericsnow> the storage package would basically take the storage interfaces and implementations (where applicable)  from environs
<wallyworld> ok, I see. Storage interface used to be in environs package actually. it was moved to environs/storage to avoid circular imports
<wallyworld> sinzui: i'll get andrew to look at the azure issue
<ericsnow> wallyworld: unfortunately getStorage is still in environs
<ericsnow> regardless, I worked around that problem and it probably turned out better anyway because of that :)
<ericsnow> I guess that answers my questsions
<ericsnow> thanks
<wallyworld> ericsnow: maybe GetStorage() should be moved to storagepackage?
<ericsnow> wallyworld: I'd argue it belongs under state somewhere, since you are getting a state's env storage
<wallyworld> yeah, true
<wallyworld> we may well introduce a top level storage package - but sort of want to do it wholistically with all uses cases in mind
<wallyworld> so if you can get away with it as is for now, that would be great
<ericsnow> no worries
<wallyworld> ty
<ericsnow> it's no blocking me or anything
<ericsnow> I've just run into the fact that discovering storage-related stuff isn't simple
<ericsnow> (both for file storage and "doc"/metadata  storage)
<perrito666> is there a way to prevent a machine from upgrading?
<menn0> super quick review for mgo import fix please: https://github.com/juju/juju/pull/451
<menn0> perrito666: not that I can think of (without changing the code)
<jcw4> menn0: LGTM :)
<menn0> jcw4: cheers
#juju-dev 2014-08-01
<wallyworld> thumper: yo
<wwitzel3> thumper: you were helping a guy who had his juju upgraded from 1.18 to 1.19. Trying to get him to 1.20. I've been trying to replicate things locally
<wwitzel3> thumper: I've got 1.19.3 bootstrapped .. but how do I make it think it is 1.18 so the juju upgrade-juju of 1.20 will proceed?
<wallyworld> wwitzel3: i don't think you can - the version number is obtained via version.Current which is compiled into the executable
<wallyworld> oh, wait, the db agent-version needs to be updated i think
<wallyworld> but doing that will trigger downgrade
<wallyworld> the version.Current and agent-version in db need to match, or else juju willtryand make them match
<wallyworld> so you may need to hack 1.20 to run upgrade steps for 1.19 rather than 1.18
<jcw4> axw: thumper suggested I ask you to review https://github.com/juju/juju/pull/450
<jcw4> axw: It's one half of the issue raised in https://bugs.launchpad.net/juju-core/+bug/1351089
<_mup_> Bug #1351089: Isolation failure in sshstorage test <juju-core:New for johnweldon4> <https://launchpad.net/bugs/1351089>
<jcw4> axw: I have another PR coming soon that addresses this specific isolation error, and a handful of others too, by supressing the load of a users custom BASH_ENV file
<jcw4> axw: but I thought that this PR was a valid change on it's own merits
<wallyworld> sinzui: i remember why the lock dir is not removed - i read that removing the file could potentially cause issues (i think if other processes held the lock, not sure now). so that's why it is left behind. so i've made it so that bootstrap and destroy remove any lock files at that point
<axw> jcw4: will take a look in a bit, thanks
<thumper> wwitzel3: hey
<thumper> wwitzel3: I *think* you just need to do the upgrade, then change the agent version in the agent configuration files on the various machines
<thumper> wallyworld: hey
<thumper> davecheney: care to look at https://github.com/juju/names/pull/22
<thumper> wallyworld: around?
<davecheney> thumper: /me looks
<jcw4> thanks axw
<jcw4> general question... how do I know when CI is ready to start accepting normal merges again?
<axw> jcw4: you'd have to check the bugs I'm afraid
<axw> they're tagged with "regression"
<davecheney> jcw4: https://bugs.launchpad.net/juju-core/+bugs?field.searchtext=&orderby=-importance&field.status%3Alist=NEW&field.status%3Alist=CONFIRMED&field.status%3Alist=TRIAGED&field.status%3Alist=INPROGRESS&field.status%3Alist=INCOMPLETE_WITH_RESPONSE&field.status%3Alist=INCOMPLETE_WITHOUT_RESPONSE&field.importance%3Alist=CRITICAL&assignee_option=any&field.assignee=&field.bug_reporter=&field.bug_commenter=&field.subscriber=&field.structural_sub
<jcw4> awesome, thanks axw and davecheney
<davecheney> thumper: I cannot see an item on the N sprint for addressing the rquirements to support Trusty's 1.18 client
<thumper> davecheney: I'll add one
<davecheney> thumper: thanks
<davecheney> thumper: for example, https://github.com/juju/juju/pull/449#issuecomment-50825367
<axw> davecheney: does 1.18 CLI still dial mongo directly? I thought 1.16 was the last to do so
<axw> looking at the 1.18 branch, looks like they all use API
<davecheney> axw: cool
<davecheney> i don't know the answer, that is why I asked
<hazmat> how long are state tests supposed to take?
 * hazmat realizes its been a while 
<axw> hazmat: I think it takes 60s-80s on my laptop with SSD
<axw> scratch that, with tmpfs
<davecheney> hazmat: yup, that is how long it takes
<davecheney> apiserver also take ~70 s for me
<hazmat> hmm.. i haven't hit a failure but i am hitting timeouts with tokumx on ssd.. was running with extra verbose those (-gocheck.vv -v)
<davecheney> axw: are all the build blockers related ?
<hazmat> 10m and the test gets killed
<davecheney> hazmat: then the test fuked up
<davecheney> it happens
<axw> davecheney: nfi
<davecheney> axw: someone suggested at the team meeting they were all the same underlying cause; mongo startup failures
<axw> hazmat: is tokumx cleanroom, or based on some version of mongo? if the latter, which version?
<axw> davecheney: the azure one certainly is mongo
<hazmat> axw, current release is against 2.4
<hazmat> axw, but its a mvcc db under the hood.. ie. always journaled
<axw> ok, just asking cos I've been trying to get things working with 2.6 and have had a bunch of issues
<hazmat> i'm wondering if the mvcc stuff is causing some additional time consumption due to write flushes
<axw> I would hope it wouldn't add *that* much
<axw> how do you control transaction isolation?
<hazmat> axw, db.beginTransaction(); db.commitTransaction(); db.rollbackTransaction()
<hazmat> axw, http://docs.tokutek.com/tokumx/tokumx-transactions.html
<hazmat> axw, actually better http://docs.tokutek.com/tokumx/tokumx-commands.html#tokumx-new-commands-transactions
<axw> cool
<hazmat> are folks using go 1.3 for dev ?
<axw> I am
<davecheney> i use trunk
<hazmat> cool, i am as well, just wanted to double check i had some issues with the rcs and juju
<davecheney> rsc ?
<davecheney> rcs ?
<hazmat> davecheney, release candidates.. http client errors on writes to s3
<hazmat> when uploading tools, i would get  EOF often
<davecheney> ok
<stokachu> anyone know if work has been committed on the api servers not being added to .jenv files until running juju status the first time?
<stokachu> i looked through the commit logs but didnt see anything
<stokachu> the state server i should say
<davecheney> stokachu: it's waiting to land now
<stokachu> davecheney, ok cool, thanks
<axw> davecheney: they'll be stored by the bootstrap command?
<davecheney> axw: waigini knows
<davecheney> but yes
<axw> cool
<davecheney> axw: I think the failure on precise is because the cloud archive isn't being added
<davecheney> Setting up rsyslog-gnutls (5.8.6-1ubuntu8.6) ...
<davecheney> Setting up libsnappy1 (1.0.4-1build1) ...
<davecheney> Setting up mongodb-clients (1:2.4.6-0ubuntu5~ubuntu12.04.1~juju1) ...
<davecheney> Setting up mongodb-server (1:2.4.6-0ubuntu5~ubuntu12.04.1~juju1) ...
<davecheney> Adding system user `mongodb' (UID 107) ...
<davecheney> ^ this isn't the juju mongo
<davecheney> it's the system one
<davecheney> no
<davecheney> wait
<axw> I don't think we use juju-mongodb on precise
<davecheney> it _is_ the juju one
<davecheney> axw: we _have_ to
<davecheney> precise is ooooooooooooold sauce
<davecheney> there is logic in cloudinit that does the switch
<davecheney> something like mongo.*Series
<axw> I don't think it *exists* in precise. I can't remember the logic... will have to dig. but anywya, that hasn't changed AFAIK
<axw> trusty+ uses juju-mongodb, everything else uses mongodb-server. it may be that it's meant to come from cloud-tools tho
<davecheney> 2.0 is in precise
<davecheney> anyway
<davecheney> probably a red herring
<davecheney> just looking for somehting I can help
<rick_h__> davecheney: wonder if your email is due to https://github.com/juju/txn/pull/6
<davecheney> rick_h__: nope
<rick_h__> davecheney: ok, nvm then
<davecheney> this is something stupid we did to ourselves back in LV
<davecheney> juju-local depends on juju
<davecheney> and you can't run the tests without juju-local
<davecheney> so even in an isolated environment you need to install juju
<davecheney> then carefully ignore it
<rick_h__> davecheney: ah, gotcha. Ok, just saw testing/dep and juju after seeing this pr today so wondered
<davecheney> rick_h__: -ENAMEINGOVERLOAD
<rick_h__> lol
<katco> wallyworld: hey, i just pushed up a new round of changes. also exporatory. some tests aren't passing, but i'm not sure if they're transient. don't have time to verify tonight.
<thumper> davecheney: added a sprint session to talk 1.18 support, see the bottom of the list
<davecheney> thumper: thanks
 * davecheney lunch
<menn0> thumper: can I get your advice on something
<menn0> ?
<wwitzel3> wallyworld: thanks for the followup email
<thumper> menn0: sure
<menn0> thumper: I'm working on adding the ability to roll back the agent version to force a downgrade
<thumper> ok
<menn0> the upgrader had to be changed because it doesn't normally allow downgrades - that's done
<thumper> ok
<menn0> but now I'm at the part where I need to set the actual agent version back in state
 * thumper tries not to be distracted by the thought of coffee
<thumper> ok
<menn0> and state.SetEnvironmentAgentVersion checks to make sure the new version makes sense
<menn0> hang on...
<menn0> ok
<menn0> so one of the checks is that all the machines and agents are starting out at the same version
<menn0> and in this case they might not be and that's actually ok
<menn0> we want to roll back to last good version anyway
<thumper> can I suggest that I make my coffee and then we have a hangout?
<menn0> ok sounds good
<menn0> coffee wins :)
<thumper> what we should identify is all the places in state where we record the agent version
<thumper> and also where on disk this is stored
<thumper> and at which part of the process the various places change
<thumper> so we know what is considered a valid rollback version
 * thumper goes to make coffee
<menn0> looking more closely I actually think I don't need to worry. would be good to discuss quickly anyway.
<jcw4> so, should I not even try to $$merge$$ until the regressions are fixed?
<thumper> jcw4: correct
<jcw4> axw: this is the other half of the test isolation fix: https://github.com/juju/juju/pull/454
<jcw4> thumper: thanks
<axw> jcw4: can we just use IsolationSuite instead?
<axw> or OsEnvSuite
<axw> directly
<jcw4> axw: I actually did that first, but it didn't fix the issue and the test I was testing on needed more refactoring to use it, which I wasn't 100% sure on... I can try again
<jcw4> axw: I'll do that again and bug you with questions if I have them :)
<axw> no worries
<axw> thanks
 * axw wanders off to get some lunch
<axw> bbs
<thumper> menn0: https://plus.google.com/hangouts/_/canonical.com/upgrades?authuser=1
<menn0> "could not start because of an error"
<menn0> thumper: ^^
 * thumper sighs
<thumper> menn0: you start one then
 * thumper closes the hangout
<menn0> thumper: k
<jcw4> axw: one point, this one line fix to suppress BASH_ENV in the tests fixes 4 or 5 tests for me.  It seems helpful to merge this change *and* refactor the specific test we initially discussed
<menn0> thumper: happened again as soon as you answered. killing my chrome now.
 * thumper didn't answer
<menn0> thumper: ok. well it keeps happening. even after restarting chrome.
 * menn0 sighs
<thumper> firefox?
<davecheney> menn0: do you have two google identies ?
<davecheney> i often have to add &authuser=1 to any link I open to make it use the right identify
<menn0> (â¯Â°â¡Â°)â¯ï¸µ â»ââ» ï¸µ â¯(Â°â¡Â° â¯)
<menn0> davecheney: i have 2 identity but it usually "just works"
 * menn0 tries firefox
<davecheney> menn0: maybe this is a time when it doesn't
<stokachu> did the separate logs for each machine go away in juju 1.20.x?
<menn0> FU22FA...
 * menn0 goes to retrieve his phone from child
<thumper> stokachu: no...
<thumper> stokachu: local provider?
<stokachu> interesting, only machine-0.log is being created
<stokachu> thumper, yea local provider
<thumper> stokachu: multiple local provider environments?
<stokachu> machine-0.log shows all the logs from each machine correctly
 * thumper recalled a bug
<stokachu> thumper, nah a single local provider with kvm as the container
<thumper> hmm
<thumper> ah
<thumper> kvm log files aren't mounted like the lxc ones because they can't
<thumper> should still be an all-machines.log though
<stokachu> yea there is, but the nested lxc machines aren't having their logs created either
<stokachu> i guess is that what you meant by 'multiple' providers
<thumper> no... they don't
<thumper> no...
<stokachu> kvm machines used to create machine-x.log files
<stokachu> the unit logs aren't being created either if that helps
<davecheney> stokachu: what does juju status say ?
<menn0> thumper: https://plus.google.com/hangouts/_/gqu6sqg3xlszyfsl2u4blczvuaa?hl=en-GB
<davecheney> have any units/services been deployed ?
<stokachu> http://paste.ubuntu.com/7920401/
<thumper> menn0: I get the party is over :-|
<stokachu> yea, a bunch
<davecheney> weird
<menn0> thumper: trying again... at least it ain't crashing in FF
<menn0> thumper: https://plus.google.com/hangouts/_/gqu6sqg3xlszyfsl2u4blczvuaa?hl=en-GB
<stokachu> all-machines.log  ca-cert.pem  machine-0.log  rsyslog-cert.pem  rsyslog-key.pem
<stokachu> those are the only files in .juju/local/log
<wallyworld> menn0: july 28 is 2 days ago, not 2 weeks ago :-P
<thumper> stokachu: yes, that is right
<thumper> menn0: try this one https://plus.google.com/hangouts/_/gvvbftptty735axcajn45l2efia?hl=en-GB
<thumper> arg
<thumper> now I get error
<stokachu> yea but there should be more of them :)
<thumper> stokachu: no
<thumper> stokachu: there shouldn't
<menn0> wallyworld: 4-5 ish days, but yes
<thumper> stokachu: it doesn't work that way
<menn0> wallyworld: I screwed that up
<stokachu> huh
<stokachu> then why the did logs used to be there
<thumper> for lxc they were
<thumper> but kvm, never were
<thumper> lxc containers share a log mount point
<axw> jcw4: yeah, seems like it'll be too error prone to get everyone to use IsolationSuite - and it may not be viable in some cases
 * menn0 needs more sleep
<thumper> kvm can't
<menn0> thumper: try calling me when you're ready
<stokachu> but i have lxc containers deployed and there aren't logs
<thumper> but you lxc containers are inside the kvm containers
<thumper> not sure what you are expecting there
<stokachu> and im pretty sure i had multiple machine logs with kvm
<thumper> if you look inside all-machines.log, you should see both machine and unit logs
<thumper> if you don't you have a problem
<stokachu> all i know is juju used to create unit-x.logs and machine-x.logs with this same setup
<thumper> also visible with 'juju debug-log'
<stokachu> and now they dont
<thumper> no
<thumper> it didn't
<thumper> never with kvm
<thumper> trust me on this
<thumper> I wrote it
<thumper> kvm can't
<thumper> otherwise it would
<thumper> I talked with robbie basak about it
<axw> jcw4: reviewed your original change
<jcw4> axw: great thanks... will add that comment
<thumper> menn0: trying again: https://plus.google.com/hangouts/_/gqu6sqg3xlszyfsl2u4blczvuaa?authuser=1&hl=en
<thumper> gah
 * jcw4 is sad; can't seem to find any of the blocking bugs that he can easily fix to clear the CI pipeline
<thumper> also issues with couldn't start
<thumper> WTF?
<menn0> thumper: wondering if it's actually something wrong with hangouts at the moment
<menn0> thumper: try calling me one more time
<thumper> just did, it starts then crashes
<thumper> menn0: ok, so back to previous statement, you have it sorted now?
<menn0> maybe
<menn0> thumper: it looks like changing the env agent version is allowed as long as all the machines in the env are on either the current or next version
<menn0> thumper: which they should be for what I'm looking at
<menn0> thumper: so it might all be fine.
<thumper> ok, that's good then
<menn0> thumper: I'll be doing some extensive manual testing before trying to merge this
 * thumper nods
<menn0> thumper: thanks rubber duck / teddy bear :)
<thumper> how are you going to make it fail?
<menn0> thumper: hack the code I think
<menn0> make one of the state agents not upgrade
<thumper> menn0: I know
<thumper> add an upgrade step
<thumper> that checks for some random file on disk
<thumper> say /var/lib/juju/kill-upgrade
<thumper> and if it is there, the upgrade fails
<menn0> that's a nice idea but this is just before the upgrade steps run
<thumper> what if the steps fail?
<thumper> don't we want to go back?
<menn0> this is for the case where one of the state servers fails to come up with the new agent version
<thumper> or are we going forwards?
<menn0> that depends
<menn0> if it's the master, we roll back using the backup
<thumper> ok, instead of an upgrade step
<menn0> unless there is no backup... then we go in to an error state
<thumper> make it something at the start of the machine agent
<menn0> if it's the secondary it marks itself as broken but the upgrade continues
<thumper> I'm half considering that we should always have something that looks for a file in order to die
<thumper> think the chaos monkey stuff
<jcw4> thumper: +1
<thumper> /var/lib/juju/chaos
<jcw4> :)
<thumper> so we can have CI tests that controllably cause things to fail
 * thumper goes to add another agenda item to next week's meeting
<menn0> thumper: that's not a silly idea
<thumper> sinzui: you there next week?
<menn0> thumper: i'll see if I can leave something permanent and extensible in place for testing this stuff
<thumper> menn0: I suggest $datadir/chaos/machine-agent
<menn0> thumper: I like it
<jcw4> so we have 6 blocking regression bugs, but only two are assigned and in progress... since no-one can land anything til these are resolved, shouldn't everyone be working on these?
<thumper> s/everyone/someone/
<thumper> jcw4: and yes
<jcw4> :D
 * thumper is prepping for a trip away leaving tomorrow
 * jcw4 bravely looks at installing precise on a virtualbox instance
<davecheney> jcw4: you don't need to install precise
<davecheney> set your default series to precise
<davecheney> and bootstrap ec2
<jcw4> davecheney: I haven't done that yet... do I need to provide ec2 tokens in my env. or something?
<jcw4> i.e. do I use my own ec2 credentials
<davecheney> jcw4: yes
<davecheney> just set the usual ec2 env vars and it works (majic)!
<jcw4> davecheney: okay... I want to try that
<davecheney> jcw4: you can use any provider
<davecheney> well, not aszure, that is properly borken
<jcw4>  hehe
<davecheney> but openstack if you use rackspace or hp cloud
<jcw4> I'm most familiar with ec2, but I've got a couple rackspace accounts too
<axw> wallyworld: I've got some changes to hopefully make bootstrap/mongo more robust, but unit tests on 1.20 are not happy
<axw> wallyworld: I can't run 1.20 tests without something mongo related failing
<axw> with or without my changes
<wallyworld> axw: did you want a quick chat
<axw> sure
<axw> ehrm, what's up with hangouts
<wallyworld> i'm in 1:1
<axw> wallyworld: it's dying on me
<wallyworld> axw: yeah, you joined and then keft, we can try standup one
<axw> wallyworld: same thing
<axw> thumper: did you get hangouts to work? I'm getting the same thing
<davecheney> jcw4: protip: do a bootstrap without default-series set
<davecheney> so it _should_ choose trusty (dunno)
<davecheney> and maybe will work before you start trying to debug why it doesn't
<wallyworld> axw: hmmm, restart chromium?
<jcw4> davecheney: I see, so do a pass through on trusty using ec2, and then change my series to precise?
<axw> wallyworld: didn't help :/
<wallyworld> wtf
<axw> I'll try firefox
<axw> may have to install the plugin
<jcw4> davecheney: and to make sure I'm clear... I initiate the tests on my local trusty box, and if my ~/.juju/... config is pointed at ec2 it should "just work" ?
<davecheney> juju switch "the name of your ec2 environment"
<davecheney> juju bootstrap --upload-tools
<davecheney> jcw4: i am concerned that bootstraping an environment is not second nature to you
<davecheney> given the number of bugs we have that are not caught in CI
 * jcw4 blushes
<davecheney> you shouldn't just assume "works on my machine" == "ship it"
<jcw4> davecheney: almost all of my work has been in areas that don't seem as susceptible to environmental issues
<jcw4> davecheney: and my testing has been 100% via unit tests.
<jcw4> davecheney: my first real dogfood testing of actions on the command line was yesterday
 * jcw4 slinks off and hides
<axw> oh wtf
<davecheney> jcw4: better late than never
<axw> firefox doesn't like it either
<wallyworld> hmmm
<wallyworld> axw: how about you try and start one?
<axw> yeah trying now
<axw> wallyworld: nope.
<wallyworld> jeez
<davecheney> axw: wallyworld menn0 why not use skype ?
<wallyworld> yuk
 * wallyworld doesn't have skype installed
 * axw has never used skype before
<wallyworld> axw: so do the trunk tests pass? is it just 1.20?
<axw> wallyworld: I'll try now
<menn0> axw, wallyworld: if you guys are having trouble too then hangouts is broken right now
<axw> menn0: I am, dunno about wallyworld
<menn0> thumper and I were unable to get a call up despite many attempts in chrome and firefox
<axw> yeah, I guess it's busted
<wallyworld> seems to work for me
<menn0> it was crashing for us while the call rang
<axw> wallyworld: I did get an error on master just now
<axw> Panic: not authorized for query on presence.presence.beings (PC=0x40EF7D)
<wallyworld> ffs
<wallyworld> the precise failures on CI were uniter related
<jcw4> davecheney: so after juju bootstrap --upload-tools... I do "go test ./..." locally and it'll magically connect to ec2?  Or do I need to first ssh into ec2 and then somehow initiate the tests?
<davecheney> jcw4: nope
<davecheney> jcw4: deploy some charms and see if your environment works
<jcw4> davecheney: oh... I see.  What if I want to reproduce the test errors that are blocking CI?
<davecheney> the error is "can't bootstrap a precise image"
<davecheney> this isn't tested in the unit tests
<davecheney> it's done in some intergration test build that curtis runs
<davecheney> which is roughtly the steps you just did
<davecheney> there might be some juiggery pokery we need to do to make sure that boostraps a 32bit environment (getting pretty rare in ec2 these days)
<jcw4> davecheney: oh, ok.
 * jcw4 scrambles to keep up
<jcw4> :)
<jcw4> I have a friend who always says "Don't judge me Weldon"
<jcw4> I know how he feels :)
<axw> wallyworld: I think a lot of the mongo errors we get in tests are to do with how we reuse Mongo databases
<wallyworld> axw: you mean in the test setup?
<axw> wallyworld: MgoTestPackage creates a single Mongo database and then MgoSuite reuses it
<axw> restarting it only on authorisation errors
<axw> sometimes those errors don't get caught in the right place tho
<wallyworld> yeah, that has bothered me
 * thumper eagerly awaits daylight savings time so the team lead calls are at a sane time
 * thumper is brain dead
<wallyworld> thumper is soft
<wallyworld> axw: i've tried removing the lock file and it ran into various issues, so easiest for now just to leave it but use a different name to previously
<wallyworld> so diff is 1 line
<axw> wallyworld: cool, I think that'll be fine
<wallyworld> yep,for now
<wallyworld> gotta get this release out
<axw> wallyworld: the change I'm trying to do is to add the admin user to mongo before initialising state
<axw> that way we can always open state authenticated, and use session.Copy
<wallyworld> axw: is that the cause of some issues?
<axw> wallyworld: I couldn't reproduce the i/o timeout, but it's the only thing I can think of
<axw> wallyworld: sorry, this is for azure
<wallyworld> hmm, i would hope that this sort of bug would at least be consistent across providers
<axw> bootstrap fails because the mgo socket gets a timeout
<axw> well it's timing related
<wallyworld> but adminuser first,then a consistent way to open state is good
<wallyworld> then that leaves precise tests :-(
<axw> well I need to get tests running for 1.20 on my trusty machine too...
<wallyworld> sigh, at least it fails for both series then
<wallyworld> axw: i'll gotta go and do some packing for the flight tomorrow, how far away is the io timeout fix?
<axw> wallyworld: it's done, but I can't verify that the tests are unaffected
<wallyworld> ah right
<jcw4> davecheney: it's aliiive :)
<axw> so, however long it takes to get the unit tests to run, which could be quite a while at this rate
<wallyworld> does it bootstrap ok?
<wallyworld> could you see the azure issue?
<axw> wallyworld: it bootstraps fine. I couldn't reproduce the error in the first place.
<wallyworld> sigh
<wallyworld> axw: i'm wondering if it's worth pushing up the fix - do the relevant state tests pass?
<axw> I'll try them in isolation
<wallyworld> at least CI can have a go then
<davecheney> jcw4: ok, so the next thing is to ensure you're bootstrapping a 386 environment
<davecheney> so
<davecheney> juju destroy-environment -y $(juju switch)
<davecheney> then juju bootstrap --constraints="arch=386" --upload-tools
<davecheney> this may work
<davecheney> or it might fail horribly
<davecheney> i'm not sure --upload-tools will work
<jcw4> davecheney: where do I change the series?
<jcw4> I didn't see it in environments.yaml
<davecheney> jcw4: lets leave that for the moment
<jcw4> ok
<davecheney> changing the architacture might be a showstopper
<jcw4> (I saw default series)
<jcw4> bad arch constraint?
<jcw4> juju bootstrap --constraints="arch=386" --upload-tools
<jcw4> error: invalid value "arch=386" for flag --constraints: bad "arch" constraint: "386" not recognized
<davecheney> try i386
<davecheney> we have to translate between debian nouns and go nouns
<jcw4> better... but:
<jcw4> juju bootstrap --constraints="arch=i386" --upload-tools
<jcw4> Bootstrap failed, destroying environment
<jcw4> ERROR cannot build tools for "i386" using a machine running on "amd64"
<davecheney> right
<davecheney> so, this is going to be tricky to reproduce
<davecheney> i would recommend not contining with this issue
<jcw4> :) Okay.. it's approaching bedtime, but now my interest is piqued
<axw> wallyworld: https://github.com/juju/juju/pull/456
<jcw4> I assume the error is because I first bootstrapped with amd64
<jcw4> and my terminated machines are configured for amd64
<jcw4> and I'm guessing juju tries to re-use them?
<axw> wallyworld: the only production code I changed was in agent.InitializeState; only tests in "cmd/jujud" and "agent" call that, and both those packages pass in isolation
<davecheney> jcw4: nope, it's because --upload-tools can only generate tools for your curent machine
<davecheney> which is amd64
<jcw4> oooh
<wallyworld> looking
<jcw4> davecheney: well I *could* fire up a 386 vbox machine
<davecheney> jcw4: if you want to try
<davecheney> you need to get your juju environment up and running
<davecheney> which is roughtly
<jcw4> davecheney: I do want to try; I've gotten my env up a few times on different 64 bit machines
<davecheney> sudo apt-get install golang-go mercurial bzr git && go get github.com/juju/juju/...
<jcw4> davecheney: yeah (plus GOPATH=~/go or something)
<jcw4> davecheney: fun for tomorrow though, if someone doesn't fix it first
<jcw4> davecheney: it doesn't attempt to re-use terminated instances?
<jcw4> davecheney: I suppose I have to clean those up manually
<davecheney> jcw4: destroy-environment removes all machines
<jcw4> davecheney: and if it doesn't that's a bug?
<davecheney> yup
<jcw4> 'cause it terminated them, but didn't remove them (unless the -y switch is what kept them around)
<davecheney> what is it ?
<davecheney> and how can you tell they aren't removed ?
<jcw4> juju destroy-environment <== "it"
<jcw4> https://console.aws.amazon.com is how I could tell
<davecheney> did the command complete sucessfully ?
<jcw4> yep
<jcw4> I'll do it again to verify
<davecheney> be carefully
<davecheney> juju will delete _ANYTHING_ connected to those ec2 credentials
<jcw4> now you tell me
<jcw4> ;p
<jcw4> my production web site hosting is in that account
<jcw4> but no, I know have three new terminated instances
<jcw4> and juju didn't seem to touch my running production instance
<davecheney> phew
<davecheney> ok
<davecheney> don't do that again
<jcw4> hehe
<jcw4> I should know better
<davecheney> sorry, should have said that juju will do that
<jcw4> I think if I create additional keys it'll firewall them
<davecheney> yup, different account that cannot see the running machines will be fine
<jcw4> (metaphorically speaking)
<jcw4> k... now it's bedtime for real.  Thanks again davecheney
<davecheney> np
<voidspace> morning all
<menn0> voidspace: morning'
<TheMue> morning
<voidspace> TheMue: does the 1.18 client rely on direct mongo access?
<TheMue> voidspace: very good question. I would expect that there are still parts, yes.
<voidspace> TheMue: if we need to support 1.18 (LTS client) does that mean we *can't* shut off direct mongo access
<TheMue> voidspace: oh, eh, indeed. software would cry. :â(
<voidspace> I have a bootstrapped environment on amazon created with direct mongo access shut off
<voidspace> going to switch to 1.18 and see if I can interact with it
<voidspace> but I suspect not....
<fwereade> voidspace, I'm pretty sure that 1.18 had switched to the API everywhere -- but it still needed direct-mongo-access code to interact with 1.16 installations
<fwereade> voidspace, if we *hadn't* switched by then we screwed up royally by releasing it -- waiting for API everywhere was one of the big reasons we waited so long to release it
<voidspace> fwereade: ok, I hope that's the case
<voidspace> fwereade: I have an mp closing the mongo ports
<voidspace> or rather, not opening them...
<fwereade> voidspace, awesome
<voidspace> hmm... internet here not as good as I remember it being last year
<voidspace> I lost an hour or so at the end of the day yesterday. But that was ok, I had insomnia and ended up working at 1am. :-/
<voidspace> so, when I try to interact with a 1.21-alpha1.1 juju state server from a 1.18 client I get: ERROR invalid agent version in environment configuration: "1.21-alpha1.1"
<voidspace> I can't find a reference to agent in the jenv (nor in environments.yaml)
<axw> I thought we stopped building jujud in our tests?
 * axw witnesses tests take 10s longer than they need to
<voidspace> "juju get-env" reports the agent version
<voidspace> ah, the 1.18 client probably doesn't like the "alpha" in the agent version
<voidspace> so I can't really test this without faking the version number
<voidspace> but "juju status" works fine without direct mongo access :-D
<axw> ugh. I guess that's not a problem since we'd only do that for pre-release versions...
<voidspace> axw: right, but it makes testing that the 1.18 client still works with pre-release servers tricky...
<voidspace> servers/environments
<axw> indeed
 * voidspace lurches
<fwereade> mattyw, oops, forgot -- does the meeting have a video call?
<mattyw> fwereade, there should be one on the meeting thing - otherwise: https://plus.google.com/hangouts/_/canonical.com/initial-metrics
<mattyw> fwereade, an no problem - it's still early
<rogpeppe> trivial change to the charm.v3 package: https://github.com/juju/charm/pull/32
<TheMue> rogpeppe: *click*
<TheMue> rogpeppe: done
<rogpeppe> TheMue: thanks
<voidspace> who is OCR?
<TheMue> voidspace: o/ and fwereade
 * fwereade should probably go and do some reviewing
 * TheMue is happy about VM snapshotting. otherwise his test environment would have had hard network troubles now.
<voidspace> TheMue: heh, yeah - messing with networking configuration is a recipe for pain
<voidspace> TheMue: fwereade: a simple one if you have time https://github.com/juju/juju/pull/449
 * perrito666 has been working 1h without glasses and finally realises why is this screen so bright
<voidspace> this is the one that shuts off the StatePort
<fwereade> voidspace, looking at that one right now
<voidspace> perrito666: heh
<voidspace> thanks
<voidspace> fwereade: there is a comment removed, it's not entirely clear just from the mp why that comment is removed
<voidspace> fwereade: and the answer is "because axw asked me to remove the TODO"...
<fwereade> voidspace, haha, cheers
<voidspace> as I was touching that code (in the azure changes)
<TheMue> voidspace: quick hangout?
<voidspace> TheMue: sure
<voidspace> TheMue: let me grab a shirt
<voidspace> for your sake...
<TheMue> voidspace: hehe
<fwereade> voidspace, LGTM, but I think we need followups to close the port in upgraded-from environments
<fwereade> voidspace, I would plausibly accept bugs for the cases that's not actually possible, because there probably is some uncooperative provider
<voidspace> fwereade: cool
<voidspace> fwereade: I'll look at a port closing upgrade step
<voidspace> fwereade: not needed for azure
<voidspace> fwereade: as we no longer mask the state-port the firewaller will close it for us
<fwereade> voidspace, ah, ok, cool -- don't follow how that's azure-specific though
<TheMue> voidspace: seems I lost you
<voidspace> TheMue: sorry connection went down, back now - will re-enter hangout if you're still around
<voidspace> fwereade: I'm not sure why it was azure specific either, but that was the only provider where I ended up touching masking code
<voidspace> fwereade: with luck it may apply to all the providers - I'll look into it
<TheMue> voidspace: no problem, only said I found another problem in my setup due to copying the VMs. will notify you about the next result.
<voidspace> TheMue: ok, cool
<voidspace> TheMue: did you manage to get onto atanga?
<voidspace> TheMue: I would like to know how to do that, I can file an rt about it though
<voidspace> I don't have ipv6 routing from here to the outside world, so I'd need to vpn it as well (like jam )
<voidspace> could be fiddly
<voidspace> but then we can experiment with ipv6 routing without killing our own network configurations...
<TheMue> voidspace: not yet, would be the next step
<voidspace> cool
<voidspace> if I get upgrades completed today I'll look at that
<TheMue> voidspace: me neither, my provider currently doesnât support it :(
<voidspace> vpn will be fine, it's just another stage of setup
<TheMue> yep
<mattyw> fwereade, quick question?
<mattyw> fwereade, (2 including that one)
<fwereade> mattyw, sure, ofc
<fwereade> :)
<mattyw> fwereade, if meterstatus changes we want to fire the meter-changed (or config-changed) hook, my question: We probably want to add some rate limiting on that - so we don't call the hook too many times in quick sucession - yes or no?
<fwereade> mattyw, I think it naturally limits itself, doesn't it?
<fwereade> mattyw, if there's little enough going on that we have time to run a hook for every change we detect, that's fine
<rick_h__> mattyw: fwereade is this convo for another channel?
<fwereade> mattyw, otherwise we'll deal with them by coalescing as usual -- we never get config-changes queued up, we just make them available until they're acted on
<mattyw> fwereade, I was just thinking if there was some bug and it got updated 1k times in 1 second we probably would only want to fire the hook once for the last value?
<mattyw> fwereade, or is that optimising too soon?
<fwereade> mattyw, no, that's correct, and it should fall naturally out of an implementation that conforms to what we already do
<fwereade> mattyw, look at uniter.filter, that's basically its job
<mattyw> fwereade, awesome, having it already there makes me happy
<mattyw> fwereade, noted, thanks
 * fwereade lunch for a bit
<axw> wallyworld mgz_ : https://github.com/juju/juju/pull/458
<wallyworld> sinzui: you online yet?
<sinzui> I am
<sinzui> wallyworld, I am
<wallyworld> sinzui: so,the CI errors seem to be related to juju not talking to mongo when everything is first starting. i have deployed many ec2 environments today with no problem. but a change has been made to force juju to ignore repliasets when first connecting and that is landing now. hopefully it will help
<wallyworld> sinzui: also, the name of the lock file for 1.20.3 has been altered slightly so as to not confuse 1.20.2 or earlier
<sinzui> wallyworld, I don't recall an ec2 problem
<wallyworld> there's lots of failures in the aws-deploy-precise-amd64 job
<wallyworld> the same ones as for azure
<sinzui> I saw your comment. I updated tests to not cleanup so that we can verify this version under test
<sinzui> oh, sorry I did not see that
<wallyworld> np, azure was most affected
<wallyworld> i just fucking hope we can get a build out today
<wallyworld> also, andrew is landing a number of changes in trunk which will hopefully make the mongo related tests more reliable
<wallyworld> sinzui: anyway, i have to leave for the airport in 7 hours and need sleep. so i'm going, but just wanted to let you know what is happening
<sinzui> wallyworld, Do we want to ask for testing of 1.20.3 even if azure fails?
<wallyworld> i'm think we could
<mgz_> wallyworld: where's our guide for setting up simplestreams on openstack?
<wallyworld> i didn't try maas though
<sinzui> As we will both be flying, this is our only chance to get something to testers
<bigjools> you're up late wallyworld
<wallyworld> bigjools: yeah :-( trying ti get a juju version out
<wallyworld> mgz_: juju docs somewhere, can't recall exact url, let me check
<bigjools> you get to Deutschland Sunday?
<wallyworld> mgz_: https://juju.ubuntu.com/docs/howto-privatecloud.html
<wallyworld> bigjools: i leave in 7 hours
<bigjools> lol
<wallyworld> for the airport
<wallyworld> still need to finish packing
<bigjools> lolol
<wallyworld> bigjools: FO
<wallyworld> bigjools: how is the sprint?
<mgz_> wallyworld: thanks!
<bigjools> wallyworld: productive
<wallyworld> good
<bigjools> some nice improvements
<wallyworld> i has lunch with steve k today
<bigjools> ha
<wallyworld> he's in brisbane for pycon
<bigjools> that's thre people in Bris while I've been away... .ffs
<wallyworld> he said he didn't want to see you anyway
<wwitzel3> hah
<bigjools> heh
<wallyworld> he also said HP is investing $2 BILLION in openstack next year
<wwitzel3> that's it?
<wallyworld> that's heat and iron.io as well
<wallyworld> or was it 1 billion
<wallyworld> but a lot of money, so we had better get our shit sorted
<katco> wallyworld: holy moly
<katco> that is a lot of money
<wallyworld> yeah :-( deep pockets
<bigjools> fark
<wallyworld> they employ so many good openstack people
<katco> openstack is good for juju, yes?
<wallyworld> and there's lots of buy in for heat and iron.io since a lot of peole want just an openstack solution
<perrito666> natefinch: we seem to have a meeting
<wallyworld> katco: well it is supposed to be, but it has a juju comptitor called heat
<katco> wallyworld: yeah reading up on that now
<wallyworld> and maas competitor iron.io
<wallyworld> i think it's called that
<wallyworld> so lots of people just want one technology stack, and built in products integrate much better than generic 3rd party ones
<wallyworld> so we need to make juju/maas compelling in other ways
<natefinch> iron.io is a competitor of MaaS?
<hazmat> natefinch, fwiw. the binaries compiled fine for me. i can put a copy up somewhere (dropbox, chinstrap) if that would be helpful. i used a pristine trusty container, and this is my extracted bash_history for the compile http://paste.ubuntu.com/7924025/
<bigjools> I thought it was called Ironic
<hazmat> natefinch, huh
<wallyworld> natefinch: AH YES
<wallyworld> sorry, i got the name wrong
<wallyworld> i'm tired
<bigjools> go to bed
<wallyworld> ironblahsomething
<hazmat> iron.io is a golang shop using mgo for queues, and stuff
<hazmat> sass style
<hazmat> saas even ;-)
<wallyworld> yeah, i got the name mixed up
<hazmat> how ironic ;-)
<wallyworld> lol
<natefinch> hazmat: yes please put it somewhere so I can grab it
<natefinch> perrito666: coming
<wwitzel3> hah
<wwitzel3> this channel is on a roll today
<natefinch> yeah, ok... I was going to say, I thought I sorta understood what iron.io did, and it's nothing like maas
<bigjools> the only irony is that Americans don't understand irony :)
<wallyworld> especially alanis morrisette
<wallyworld> although see is canadian
<natefinch> I thought Alanis Morrisette was Canadian
<natefinch> yeah, see?
<wallyworld> yeah
<wallyworld> she
<wwitzel3> same thing, americas hat
<wallyworld> right i'm off, catch you guys later, hope the build passes CI finally, i'll wake up and check the computer straight away :-/
<katco> wallyworld: travel salfe, sleep welel.
<katco> well
<wwitzel3> wallyworld: see ya
<hazmat> natefinch, uploading it to dropbox, so all state tests pass minus apiservers afaics.. i've got quite a few notes in the activity log section of the ACID doc.
<hazmat> the api server failures are around concurrency issues (doc level lock contention)
<hazmat> in a few of the tests, worth investigating more.. we've done quite a lot of hot spot creation on docs to work around various definiciencies of not having txns and isolation (various ref counts)
<natefinch> perrito666: you still there?
<natefinch> hazmat: very interesting
<hazmat> natefinch, https://www.dropbox.com/s/dbcrgahxxyt8buv/tokumx-1.5.0-linux-x86_64.tgz
<natefinch> hazmat: awesome, thanks.   No idea why the build failed for me
<hazmat> natefinch, yeah.. rather curious.. using pristine containers for builds is a good rule of thumb, and also isolates build crap from the host
<hazmat> natefinch, added my build notes/recipe to the doc as well
<natefinch> hazmat: maybe I just need to clean before I build... haven't done that
<hazmat> natefinch, i have some requests out to tokutek re info on how to speed up dropdb equiv.. there's alot of time it seems like in setup/teardown  that's causing the tests to go slower overall even though actual test times look normal
<hazmat> natefinch, instrumenting that to isolate would be useful, as would investigating the doc level conflicts we're doing with concurrent mods
 * hazmat wanders off to pre-sales meetings
<fwereade> ericsnow, ping
<ericsnow> fwereade: o/
<fwereade> ericsnow, just wanted to check quickly -- what is the Status going to be used for, and why do we need to have the id matching the timestamp?
<ericsnow> fwereade: Status is just part of my enums compulsion :)
<ericsnow> fwereade: the timestamp thing is just me overthinking
<fwereade> ericsnow, I'm questioning the very existence of everything connected with status -- I'm fine with the *code* but I don;t quite see what it's for
<fwereade> ericsnow, I'd imagined we could just create the backup, and record the complete metadata just once when we know the backup is safely stored elsewhere
<fwereade> ericsnow, no need for status at all afaics
<ericsnow> fwereade: 2 things
<ericsnow> fwereade: if storing the archive succeeds but the metadata fails, I didn't want to leave the archive without metadata
<ericsnow> fwereade: the other thing is I was thinking about restore, where I expect we will add the info without an archive (when uploading an archive for restore)...now obviously to me a premature optimization :)
<cmars> jam, thanks for the review on login v2
<fwereade> ericsnow, good thought re orphan archives, wondering if there's a different way to do it, can't think of an obvious one
<fwereade> ericsnow, anyway I have a few other comments, let me know what you think
<ericsnow> fwereade: so yeah, the status stuff is overkill and I'll find a simpler way
<ericsnow> fwereade: thanks for all the help
<fwereade> ericsnow, a pleasure :)
<ericsnow> fwereade: do you think having dedicated error values (like the 3 in my patch) is worth the inflexiblity?
<ericsnow> fwereade:   The idea of checking the error message to decide on what to do really bugs me, but identity checking means you can't customize the error.
<ericsnow> fwereade: I guess I could have a customizable error type and a helper function that lets you ask if an error is a particular one (kind of like happens in state/api/params/apierror.go), but that's just too much work for what I need
<fwereade> ericsnow, the code is all already written in juju/errors
<ericsnow> fwereade: got it
<gmb`> Guys, from where can I clone a branch of the latest stable version of Juju? I need it to hack up some demo interactions with MAAS.
<zirpu> gmb`: github.com/juju/juju i think. or find it on launchpad also.
<mgz_> gmb`: what do you mean by latest stable?
<mgz_> not-trunk?
<mgz_> the 1.20 branch on github
<gmb`> mgz_: Okay, thatâs perfick. Ta.
<sinzui> gmb: there will 1.20.3 tools and debs in a few minutes if you just need a juju that is very current
<gmb`> sinzui, mgz_ Okay. I canât get 1.20 (or trunk) to build from source
<ericsnow> for our use of mongo in a state collection (e.g. backups), is it okay to use omitempty on an _id field (i.e. forcing auto-generated unique ID)
<marcoceppi> sinzui: for juju-core merges, to all merges have to be target at a bug?
<gmb`> go install -v github.com/juju/juju/â¦ fails:
<marcoceppi> s/to/do/
<sinzui> gmb, that's right
<gmb`> sinzui: Okâ¦
<sinzui> gmb, go doesn't support git like that
<gmb`> sinzui: Shame that the documentation in the branch says to do *exactly* that.
<natefinch> https://github.com/juju/juju/blob/master/CONTRIBUTING.md#getting-started
<sinzui> gmb`, it says that to get stable?
<gmb`> sinzui, natefinch: Hmm, my env must be screwy, rvba  isnât havenât the problemâ¦
<sinzui> marcoceppi, no, only when there are regressions. We fix regressions immediately now...we dont wait a few months
<marcoceppi> sinzui: I don't understand this error https://github.com/juju/juju/pull/447
<gmb`> natefinch: https://github.com/juju/juju/blob/master/README.md#building-juju
<gmb`> sinzui: ^^
<gmb`> Anyroad.
<sinzui> marcoceppi, you branch doesn't fix a bug that needs to be fixed now. you cannot land unless you add fixes-<critical-regression>
<marcoceppi> sinzui: oic
<sinzui> marcoceppi, you cannot land until the build is fixed
<marcoceppi> that's pretty cool
<marcoceppi> slightly annoying, but cool
<sinzui> marcoceppi, I would hope it is so annoying that regressions wont live for weeks
<marcoceppi> that's what makes it cool
<sinzui> gmb`, the instructions are right, did you skip dependencies...https://github.com/juju/juju/blob/master/CONTRIBUTING.md#dependency-management
<gmb`> sinzui: No.
<sinzui> gmb`, This script is very convoluted because it makes a tarball with frozen deps http://bazaar.launchpad.net/~juju-qa/juju-release-tools/trunk/view/head:/make-release-tarball.bash
<sinzui> it does go-get, and godeps
<natefinch> gmb`: what error are you getting?
<katco> hey all, having trouble with trunk on my local machine. several panics, first of which is: PANIC: cmd_test.go:54: CmdSuite.TearDownTest
<katco> ... Panic: watcher iteration error: not authorized for query on juju.txns.log (PC=0x40EF8D)
<katco> any ideas here?
<jcw4> katco: not GOMAXPROCS right >
<jcw4> ;)
<katco> jcw4: lol no... that is hard-coded into my script now :)
<jcw4> hehe
<katco> well, -parallel actually. let me try gomaxprocs just to be sure it's not the same thing
<jcw4> katco: oh, interesting - I think -parallel is specific to how the tests are structured, vs. GOMAXPROCS which is more general
<katco> jcw4: yeah, that's true
<katco> here we go...
 * bodie_ lights a votive candle for katco's dev environment
<katco> LOL
<katco> it felt the good vibes and got past the problem point!
<katco> i am totally comfortable with dismissing jcw4's insistance on GOMAXPROCS=1 and attributing it _all_ to bodie_'s candle. thank you so much bodie_. way more helpful than jcw4 :)
<bodie_> the cargo gods smile on this day
 * katco is frustrated. back to coding...
<bodie_> maybe next they'll get my branch landed :P
<katco> haha
<katco> hey i'm hoping for that too!
<katco> in fact, i may need a PR reviewed here in a bit, assuming these tests now pass on my branch
<jcw4> katco: lol
<jcw4> and bodie_
<ericsnow> is there any type in juju that records identifying information for the state server?  something like (unique juju instance ID, environment ID, state machine ID, hostname)
<katco> alright, review needed: https://github.com/juju/juju/pull/398
<axw> mgz_: I'm going to crash shortly, just added some comments to the azure i/o timeout bug
<axw> looks like mongo is blocking reads/writes during index creation
<natefinch> axw: 1am on a Friday night?  Weak  ;)
<wwitzel3> lol
<axw> :~(
<axw> I'm a young old man
<mgz_> axw: ta, I'll have a look
<natefinch> axw: I go to bed at 9:30 most nights.  I'm just an old man :)
<axw> hehe
<TheMue> how to directly merge a PR without CI (itâs only one changed doc file)
<TheMue> natefinch: hey, you and old, ha!
 * TheMue only laughs about it
<natefinch> Heh
<TheMue> wonna bet?
 * TheMue reaches his next decade next year
<jcw4> TheMue: I was wondering if JFDI meant merge regardless of CI gate?
<natefinch> TheMue: oh, I know you're older than me ;)
<TheMue> jcw4: JFDI?
<jcw4> TheMue: I've seen it in a few $$merge$$ messages... I thought it was an expression of frustration, and then I wondered if it was a secret code to CI :)
<TheMue> jcw4: ah, hmm, afaik the bot merges with $$.*$$, so regardless the text
<jcw4> oh well...:)
<TheMue> I thought thereâs an option on the web interface too
<jcw4> TheMue: I've only seen it on the smaller repos
<jcw4> TheMue: Unless you're in the smaller "owners" group maybe?
<TheMue> jcw4: seems to be on option only visible with according access rights
<jcw4> TheMue: yep
<TheMue> ok, so using the standard way
<natefinch> TheMue, jcw4:  just so no one is unclear, it's $$\S$$  which is to say, no spaces in the word between the dollar signs
<jcw4> ah
<TheMue> natefinch: ok, thatâs more precise
<katco> hey jcw4 had a very good question: is there any reason we can't parallelize machine provisioning? https://github.com/juju/juju/pull/398#discussion-diff-15706382
<jcw4> I was thinking that since we're blocking waiting for the machine to be provisioned anyway it would be a perfect opportunity use goroutines
<TheMue> eh, now it tells me âdoes not match ['fixes-1350983', 'fixes-1350911', 'fixes-1347715', 'fixes-1351030', 'fixes-1351019â]â
<natefinch> oh yeah.... sorry, the landing bot is locked down because there are bugs breaking CI
<katco> jcw4: yeah i mean why not provision them in parallel. there could be an underlying reason i'm not aware of
<natefinch> katco, jcw4: as long as you aggregate the errors back to the same place where they would go if they were serial, that's probably ok
<katco> sweet... this could really speed things up. great idea jcw4
<TheMue> natefinch: thx for info
<natefinch> katco, jcw4: actually... I think there's a couple reasons not to do that.... the major one is that we should be making a bulk call to the API.  instead of "Start one machine" x5, we should do "start 5 machines"
<katco> natefinch: i think i see what you mean... we've tied it to the Machine struct, but it looks like it can take multiple
<natefinch> katco, jcw4: we also have to take into account rate limiting, though really that should take care of itself if the code is correct (though I think it's not... I think there's an outstanding bug where if you say deploy 6 and after 4 you hit a rate limit, it won't ever retry)
<katco> natefinch: well, i'm not going to touch this then. this PR is already 3 weeks old
<natefinch> yeah
<natefinch> I wouldn't do it with your PR
<natefinch> it should be done separately
<katco> natefinch: are LGTM from non canonical employees sufficient for landing?
<jcw4> katco, natefinch : my guess is it's more related to experience on the project and with Go than with employment status?
<katco> jcw4: i would think that should be the case, but i just don't know.
<natefinch> yeah
<jcw4> I mean if Rob Pike wandered in and said LGTM, I'd be pretty okay with it
<jcw4> :)
<natefinch> lol
<katco> haha
<natefinch> I actually wouldn't, since he doesn't kn ow the project.... but if he said not LGTM, I'd listen, because there is probably a code problem
<jcw4> +1
<jcw4> good point
<katco> natefinch: i understand the landing bot is broken; do we still do $$merge$$ and assume it will catch up?
<bodie_> to be pedantic, there is probably a good argument to be made that if code needs to be special-cased around the project, it's a little bit not-go-ish
<bodie_> though there are some cool bits and pieces, certainly
<jcw4> last night thumper indicated I shouldn't $$merge$$ until CI opeend up
<katco> ah ok.
<jcw4> I don't get the impression the bot will catch up
<katco> poor bot.
<jcw4> katco: I don't think the bot is broken, I think it's actively rejecting anything that doesn't fix the critical regressions
<katco> jcw4: ahhh
<katco> thank you for that adjustment in perception. now some recent email threads make more sense :)
<natefinch> yep
<natefinch> it's functioning as designed
<jcw4> it's a feature!
<natefinch> rejecting everything until someone fixes the bugs
<katco> haha
<hazmat> any body familiar with juju metadata tools
<hazmat> a question came up for generating image stream data with multiple series, and its not clear that the generate-image subcommand has any capability to do that
<ericsnow> what uniquely identifies a juju instance?
<natefinch> hazmat: unless sinzui knows.... you're on the at the wrong time of day
<natefinch> ericsnow: what do you mean by instance?
<hazmat> natefinch, yeah.. i know who to ask when the right time comes.. just curious if this blackbox has other initates
<hazmat> ericsnow, two things.. a machine id from corresponding sequence, and a provider id... for a group when querying provider its the sec group typically. maas scopes by account.
<hazmat> internal to juju its all machine id
<ericsnow> the juju instance in common between multiple state servers
<natefinch> ericsnow: you're still not defining instance
<natefinch> ericsnow: you mean the environment?
<ericsnow> natefinch: effectively
<ericsnow> natefinch: however with multi-env that would not work, right?
<natefinch> There's an environment ID
<ericsnow> right (State.EnvironTag().Id())
<natefinch> when we move to multiple environments per state server, the code will need to change to recognize it's not a 1:1 relationship anymore
<ericsnow> fair enough...I'm thinking ahead I guess
<natefinch> don't think too far ahead :)
<ericsnow> natefinch: never! :)
<natefinch> exactly
<sinzui> hazmat, natefinch . sorry. I don't have any experience with generate-image
<natefinch> sinzui: it's ok... I only suggested you because you often seem to know everything ;)
<hazmat> sinzui, it was for ivoks, looks you already answered, thanks
<hazmat> er. looks like
<sinzui> natefinch, I know more than I should and I am bad at explaining why a suggestion make be cry in less than 20 words
<sinzui> hazmat, I failed I think. I gave him an example for juju tools
<hazmat> sinzui, he just needed to run the command twice re image metadata once for each series
<sinzui> I know jerff (Ben) make the official images
<sinzui> hazmat, That gives you two files though. I think Ben knows how to make one file
<hazmat> sinzui, hmm.. bummer i was hoping.. but the params didn't give confidence.. there's a separate simple streams project with py tools for assembly
 * hazmat files a bug
<sinzui> hazmat, yep, I think that is what Ben and Scott use
<hazmat> filed as bug 1351426
<_mup_> Bug #1351426: juju metadata generate-image only supports a single series <juju-core:New> <https://launchpad.net/bugs/1351426>
<hazmat> ericsnow, ah.. ic what you mean.. effectively the state servers of a MES situation aren't part of the environments their hosting (ie not machine 0)... there's been some notion of a special env within mes that they are a part of to support existing management techniques. ops like ensure ha from hosted/guest envs would be no-ops against them though.
<perrito666> hey ppl, my ISP died on me and my cell phone is not all that great as a modem so Ill be offline while I sort this out, mail me if you need anything I am likely to answer right away from the phone
<perrito666> cheers
<dpb1> There is no option to leave the bootstrap node up, is there?
<dpb1> (in case of failure)
<natefinch> not currently
<natefinch> we want to add a flag to do that... and that's probably coming in the near future
<natefinch> dpb1: one thing you can do is do a kill -stop right before the code does the teardown
<natefinch> I think anytime after you see the line about bootstrapping juju in the --debug log output, stopping the juju client will prevent it from killing the instance
<natefinch> it's kind of a hack, but it works
<dpb1> natefinch: ok, interesting
<dpb1> natefinch: that indeed will help me I think
 * dpb1 tries now
<natefinch> dpb1: cool.  I think we'll add that flag to bootstrap sometime pretty soon.  I might be able to find time for someone to do it next week if we're lucky.... it plagues the core devs as well as users.
<dpb1> natefinch: indeed, it's up.  now I can debug why it failed. :)
<dpb1> thx
<natefinch> dpb1: awesome
 * perrito666 borrows a neighbor's internet
<wallyworld> hazmat: you run generate-image more than once, just with a different series and inage id and will append to what's there, that's how you get > 1 series
#juju-dev 2015-07-27
<axw> mgz: if you have some time to spare, would you please review https://github.com/go-amz/amz/pull/57 ?
<menn0> axw: ping
<axw> menn0: hey
<menn0> axw: i've just had a look at bug 1478024 and it looks quite serious
<mup> Bug #1478024: Looping config-changed hooks in fresh juju-core 1.24.3 Openstack deployment <canonical-bootstack> <juju-core:Triaged> <juju-core 1.24:Triaged> <https://launchpad.net/bugs/1478024>
<menn0> axw: i'm not working tomorrow so I wanted to hand let someone else know about it
<axw> menn0: ok. anything to share that's not on the bug?
<menn0> axw: the uniters for the units keep dying which causes many unnecessary config-changed hook firings and I think is hurting performance badly
<menn0> axw: no everything is on the ticket I think
<axw> menn0: ok, see if I can work out what's causing those errors. thanks for letting me know
<menn0> axw: I've spent most of my day looking at bug 1478232 and I'm now beginning to think they're related
<mup> Bug #1478232: juju 1.24 poor performance <cpec> <juju-core:Triaged by menno.smits> <juju-core 1.24:Triaged by menno.smits> <https://launchpad.net/bugs/1478232>
<axw> ok
<menn0> axw: I might email the list as well to get some extra eyes on this overnight
<menn0> axw: email sent.
<menn0> axw: if you don't get anywhere with it then hopefully someone else can.
 * menn0 is done
<axw> menn0: thanks. have a nice day off
<dimitern> morning folks
<dooferlad> hi dimitern, was expecting you to take a swap day.
<dimitern> dooferlad, I was thinking about it, but decided to do instead 2 half days - tomorrow and on wednesday
<dimitern> or something like it - today and tomorrow actually
<TheMue> morning *yawn*
<dimitern> TheMue, o/
<TheMue> Weather is grey, energy is low, need some caffeine this morning.
<dimitern> TheMue, be glad it's gray :) it closing 40 degrees in BG this week
<TheMue> dimitern: ok, 40Â° is a bit too much. 25 to 30 would be nice
<dimitern> dooferlad, dooferbot - you're multiplying yourself? :)
<dooferlad> dimitern: little experiment
<dooferlad> dimitern: go server, web front end
<dooferlad> dimitern: you know, for fun!
<dimitern> dooferlad, cool :)
<dimitern> TheMue, 1:1 ?
<TheMue> dimitern: oh, yeah, forgot, sorry. just hacking. ;) omw
<mattyw> bogdanteleaga, ping?
<axw> dimitern: hey, when you have a moment can you please take a look at https://github.com/go-amz/amz/pull/57?
<dimitern> axw, hey, sure - looking
<dimitern> axw, LGTM
<axw> dimitern: thanks!
<bogdanteleaga> mattyw: hey
<mattyw> bogdanteleaga, good morning, - this is good to land http://reviews.vapour.ws/r/2259/
<bogdanteleaga> mattyw: cool, I think you can push it if it's a blocker and I'm not around
<mattyw> bogdanteleaga, ok will do
<mattyw> bogdanteleaga, I'll keep an eye on it - many thanks
<bogdanteleaga> mattyw: np, I'm still not sure why SupportedSeries does not return all of them on ubuntu, it does seem like a bug to me
<mattyw> bogdanteleaga, that does seem odd you're right
<bogdanteleaga> mattyw: that was fast :)
<mattyw> bogdanteleaga, I happened to come across the tab at the right time
<mattyw> bogdanteleaga, I have a headache this morning so endlessly scrolling through tabs is about as productive as I can be :)
<dimitern> jam, ping
<dimitern> katco, jam, there's no g+ link on the making juju better call I'm supposed to attend
<dimitern> fwereade, hey
<fwereade> dimitern, heyhey
<dimitern> fwereade, any idea where are we supposed to join that call starting now?
<fwereade> dimitern, what with being at a sprint, can I skip our 1:1 please?
<fwereade> dimitern, oh, er, what call?
<dimitern> fwereade, sure, already declined
<fwereade> dimitern, ah
<fwereade> dimitern, the schedule is ...fluid
<fwereade> dimitern, so that particular meeting is not happening now
<dimitern> fwereade, Making Juju Better - salon AB
<dimitern> fwereade, ok, that's good to know :)
<fwereade> dimitern, we will be sure to let you know when it really is ;)
<dimitern> fwereade, thanks
<dimitern> fwereade, are you on the sprint btw?
<fwereade> dimitern, yeah
<dimitern> fwereade, so I ask you to let me know when I'm needed and where then :)
<dimitern> actually, I said I'll be around for half a day, so I'd better do it
<bogdanteleaga> any gwacl expert around?
<perrito666> morning
<anastasiamac> perrito666: o/
<fwereade> does anyone know why we have a bunch of api structs defined in api/client.go instead of somewhere in the apiserver/params package?
<perrito666> fwereade: I would daresay snowballing
 * perrito666 curses his space bar
 * TheMue would even prefer .../api/client, api/server, and api/params, so that client users don't have to import apiserver/params
<natefinch> ericsnow, wwitzel3: btw, going to be here after all.  Kids are sick, so no swim lessons today.
<ericsnow> natefinch: k
<wwitzel3> natefinch: :( bummer
<wwitzel3> natefinch: lol, not that you are here, but that the kids are sick
<natefinch> haha
<natefinch> wwitzel3: oh, forgot to mention, you inspired me to build , so I'm making a kids sized picnic table and a full size picnic table.
<wwitzel3> natefinch: nice!
<perrito666> until mid sentence I thought that wwitzel3 had inspired you to run make
<natefinch> lol
<natefinch> I never run make
<perrito666> well perhaps wwitzel3 had inspired you to?
<natefinch> wwitzel3: got a pocket hole jig so I can make the tops w/o screw holes showing... loving that thing, wish I'd gotten one much earlier
<wwitzel3> natefinch: yeah, they are very useful
<perrito666> wow, there is actually a tool for that :|
<natefinch> perrito666: I'd built a jig to do it, but it's fiddly to get it precisely right, and the jig you buy has a bunch of nice markings to make it easy to get everything lined up perfectly.  Worth it for me.  Plus it's a lot smaller than my shop built jig (and therefore I'm much more likely to use it)
<perrito666> I just use a steady hand for that :p
<perrito666> but I reckon that using a jig gets nicer results
<perrito666> I am so buying one of those
<natefinch> perrito666: I'm impressed at anyone able to do it by hand. Getting a drill hole started at an angle by hand has always been disaster for me
<natefinch> perrito666: this is what I bought: http://www.amazon.com/Kreg-K4-Pocket-Hole-System/dp/B001DYFISG
<perrito666> you have big pockets dude
<natefinch> :/
<perrito666> natefinch: to do an angled hole by hand you first make a dent in the wood
<perrito666> natefinch: that is certainly not a "pocket tool"
 * perrito666 looks for the same device with proper units
<wwitzel3> even with a starter spot, if you are doing anything longer than 2 or 3" and you want tight tolerances for your hardware, you'll need a jig, almost impossible drilling 4,5,6 inches straight without a jig
<perrito666> wwitzel3: agreed, my results are ugly
<perrito666> they are just barely enough to cover the screw and I never get 2 to look the same
 * perrito666 notices that he has no clue how to buy that here as he does not know the name in spanish
<natefinch> perrito666: actual results from me using the jig for the first time: http://imgur.com/WvPxnBc
<perrito666> well the name in spanish is a bit dissapointing
<perrito666> basically it transalates to "template to make holes with an inclination"
<natefinch> lol
<mup> Bug #1478660 opened: juju uses proxy to access bootstrap node <juju-core:New> <https://launchpad.net/bugs/1478660>
<mup> Bug #1478027 changed: supportedSeriesWindowsSuite.TestSupportedSeries mismatch with "arch" <blocker> <ci> <regression> <unit-tests> <windows> <juju-core:Fix Released by bteleaga> <https://launchpad.net/bugs/1478027>
<sinzui> ericsnow: Do you need to meet today?
<mup> Bug #1478706 opened: Supported series only returns ubuntu series on ubuntu <juju-core:New> <https://launchpad.net/bugs/1478706>
<mup> Bug #1478706 changed: Supported series only returns ubuntu series on ubuntu <juju-core:New> <https://launchpad.net/bugs/1478706>
<mup> Bug #1478706 opened: Supported series only returns ubuntu series on ubuntu <juju-core:New> <https://launchpad.net/bugs/1478706>
#juju-dev 2015-07-28
<mup> Bug #1478762 opened: juju bootstrap failed to connect to environment  with error "discarding API open error"  <juju-core:New> <https://launchpad.net/bugs/1478762>
<dooferlad> fwereade: hangout?
<fwereade> dooferlad, sprinting, a bit inconvenient
<dooferlad> fwereade: have fun!
<TheMue> ok
<fwereade> dooferlad, cheers :)
<TheMue> dooferlad: no answer from the maas guys so far, will ask again later. but found the reason for my failing code, a type assertion doesn't work as wanted
<dooferlad> TheMue: thanks for chasing them.
<fwereade> TheMue, dooferlad: can I borrow one of you for a bit of independent sanity-verification?
<dooferlad> fwereade: sure
<fwereade> TheMue, dooferlad: I have a branch called final-leadership-switch-1.24
<fwereade> TheMue, dooferlad: builds fine, tests not fixed
<fwereade> TheMue, dooferlad: would you please run an HA environment with a bunch of ubuntu units deployed
<fwereade> TheMue, dooferlad: and let me know if it appears to work right
<fwereade> TheMue, dooferlad: just started one myself
<fwereade> TheMue, dooferlad: and *very* preliminary indications are good
<fwereade> TheMue, dooferlad: but please try to break it if you can
<dooferlad> fwereade: if you can point me to instructions, sure.
<dooferlad> fwereade: haven't done anything with HA yet
<fwereade> dooferlad, `juju ensure-availability`
<dooferlad> fwereade: but I am always happy to try and break things :-)
<fwereade> dooferlad, leadership is charm-facing not user-facing
<fwereade> dooferlad, the hook tools you'll want to poke are `is-leader`, `leader-set` and `leader-get`
<fwereade> dooferlad, will be back shortly, have to go to lunch now
<dooferlad> fwereade: OK, enjoy.
<fwereade> dooferlad, tyvm
<TheMue> f*ck
<TheMue> sorry
<TheMue> assertion fails due to usage of mocking interfaces, changing them to concrete types makes mocking harder again
<TheMue> have to thing about it
 * dooferlad goes for lunch
<TheMue> dooferlad: (a) hangout is canceled, (b) found a solution for my mentioned problem, yeah
<fwereade> dooferlad, TheMue: any findings? +ve or -ve? :)
<dooferlad> fwereade: I kicked off what should have been a simple MAAS-in-kvm bootstrap and ensure-availability, but the bootstrap failed. Just back from lunch so will debug and retry once I have 3+ machines again.
<dooferlad> ah, DNS you swine.
<fwereade> dooferlad, cheers
<rogpeppe2> fwereade: do you know why unit logging is always forced to be DEBUG ?
<fwereade> rogpeppe2, hmm, I *think* it might be because people got upset that we'd hidden hook output from debug-log by default
<fwereade> rogpeppe2, long time ago
<rogpeppe2> fwereade: right - i see it changed start of 2014
<rogpeppe2> fwereade: i just reported https://bugs.launchpad.net/juju-core/+bug/1478936
<mup> Bug #1478936: environs/config: fails if logging config is not attr=value <juju-core:New> <https://launchpad.net/bugs/1478936>
<rogpeppe2> fwereade: which was causing my tests to fail
<fwereade> rogpeppe2, shouldn't your logging-config be "<root>=DEBUG"?
<fwereade> rogpeppe2, not just DEBUG
<rogpeppe2> fwereade: just "DEBUG" is a valid logging config
<rogpeppe2> fwereade: it's equivalent to "<root>=DEBUG" but much easier to type
<fwereade> rogpeppe2, ah,, good to know
<mup> Bug #1478934 opened: IPv6 openstack security group rules not managed by juju in dual stack <juju-core:New> <https://launchpad.net/bugs/1478934>
<mup> Bug #1478936 opened: environs/config: fails if logging config is not attr=value <juju-core:New> <https://launchpad.net/bugs/1478936>
<mup> Bug #1478934 changed: IPv6 openstack security group rules not managed by juju in dual stack <juju-core:New> <https://launchpad.net/bugs/1478934>
<mup> Bug #1478936 changed: environs/config: fails if logging config is not attr=value <juju-core:New> <https://launchpad.net/bugs/1478936>
<mup> Bug #1478934 opened: IPv6 openstack security group rules not managed by juju in dual stack <juju-core:New> <https://launchpad.net/bugs/1478934>
<mup> Bug #1478936 opened: environs/config: fails if logging config is not attr=value <juju-core:New> <https://launchpad.net/bugs/1478936>
<mup> Bug #1478943 opened: Rsyslog certificate fails when using IPv6/4 dual stack with prefer-ipv6: true <juju-core:New> <https://launchpad.net/bugs/1478943>
<mup> Bug #1478943 changed: Rsyslog certificate fails when using IPv6/4 dual stack with prefer-ipv6: true <juju-core:New> <https://launchpad.net/bugs/1478943>
<mup> Bug #1478943 opened: Rsyslog certificate fails when using IPv6/4 dual stack with prefer-ipv6: true <juju-core:New> <https://launchpad.net/bugs/1478943>
<dooferlad> ok, so running 8 kvms in a MAAS cluster containing a HA MySQL and Ceph cluster may slow my machine down a bit.
<dooferlad> Maybe I should upgrade to 32GB RAM
<perrito666> dooferlad: I had the same thought, then I finally admitted that I should not be doing that on a laptop :p
<dooferlad> perrito666: oh, this is a desktop.
<dooferlad> perrito666: it is fine now, it was just bootstrapping several machines at once that seemed to be a problem. Now down to 13GB in use.
<dooferlad> I think I could put 5 physical nodes + 1 master together, but power control would be painful. The 2 nodes, 1 master set up I have is enough for most work.
<dooferlad> trust fwereade to break things :-)
<perrito666> I definitely need to make git co run godeps
<mup> Bug #1478983 opened: Cannot resolve a blocked unit <juju-core:New> <https://launchpad.net/bugs/1478983>
<fwereade> mgz, pinjg
<perrito666> what is that, chinese ping?
<fwereade> perrito666, ;p
<mgz> fwereade: hey
<fwereade> mgz, so, I would like to distribute a deeply hacky build of juju, and it has been suggested that a ppa would be a good way to go
<fwereade> mgz, is there a quick easy way I can cause this to occur?
<mgz> nope.
<mgz> for starts, if you care about more than the client
<fwereade> mgz, ok, problem solved, I'll send a .tgz with the two binaries and --upload-tools ;)
<mgz> whoever you want to use this either needs a very temp env with --upload-tools and only one arch, or set up their own streams hosted somewhere
<mgz> so a ppa gets you nothing
<perrito666> fwereade: I could help you there
<mgz> if you want people to test a fix, just giving them some tools built for the right arch and instructions on how to avoid using published streams by mistake is probably what you want
<mgz> if they're intending to leave that environment up, that ends up being painful
<mgz> fwereade: all make sense?
<fwereade> mgz, yeah, think so, have to come back to it later anyway
<dooferlad> TheMue: do you have a moment to help with a compile error? https://ide.c9.io/dooferlad/juju
<TheMue> dooferlad: sure
<dooferlad> TheMue: ok, so I am going to have to re-think this. It sucks.
<dooferlad> TheMue: I need to get more state out of the functions I want to test, but I can pass things in. I think.
<TheMue> dooferlad: yeah, had it the same, needed state and wanted to avoid state in tests and work with a subinterface as mock
<TheMue> dooferlad: had to change the entity watcher interface for it, thankfully I'm so far the only user.
<mup> Bug #1479024 opened: TestRootDiskTags localServerSuite fails on ppc64el <blocker> <ci> <ppc64el> <regression> <juju-core:Triaged> <https://launchpad.net/bugs/1479024>
<mup> Bug #1479024 changed: TestRootDiskTags localServerSuite fails on ppc64el <blocker> <ci> <ppc64el> <regression> <juju-core:Triaged> <https://launchpad.net/bugs/1479024>
<mup> Bug #1479024 opened: TestRootDiskTags localServerSuite fails on ppc64el <blocker> <ci> <ppc64el> <regression> <juju-core:Triaged> <https://launchpad.net/bugs/1479024>
<cherylj> Is there some traditional way of delivering a patched version of juju to a bug reporter for verification that it fixes their problem?
<perrito666> cherylj: not that I know
<natefinch> google drive or dropbox... used to be Ubuntu One but... yeah no
<axw> perrito666: che?
<perrito666> axw: directed to anastasiamac being revolutionary :)
<axw> aha :)
<anastasiamac> perrito666: axw: D someone has to take the stance, rite :D
 * perrito666 sends the beret, cigar and fake beard pack to anastasiamac 
<anastasiamac> perrito666: I think that tent is more important - I'll neee to live somewhere too :)
#juju-dev 2015-07-29
<axw> mgz: can I get on the ppc64el CI machine to dig into this bug?
<axw> mgz: never mind. fails on amd64 using gccgo.
<axw> waigani: looks like you're OCR today. can you please review https://github.com/juju/juju/pull/2892? fixes the critical blocker on master
<waigani> axw: sorry, just saw this.  Shipit
<axw> thanks
<mup> Bug #1479194 opened: Juju agent hangs if debug-hooks session goes away <juju-core:New> <https://launchpad.net/bugs/1479194>
<mup> Bug #1479194 changed: Juju agent hangs if debug-hooks session goes away <juju-core:New> <https://launchpad.net/bugs/1479194>
<mup> Bug #1479194 opened: Juju agent hangs if debug-hooks session goes away <juju-core:New> <https://launchpad.net/bugs/1479194>
<dimitern> morning
<mup> Bug #1479024 changed: TestRootDiskTags fails on ppc64el <blocker> <ci> <ppc64el> <regression> <juju-core:Fix Released by axwalk> <https://launchpad.net/bugs/1479024>
<dimitern> dooferlad, hey
<dooferlad> dimitern: hi. Sorry, that was a very long reboot.
<dooferlad> wasn't the entire 40 minutes!
<dooferlad> more like 10
<dimitern> dooferlad, :) wow
<dooferlad> well, I think something hung. Gave up and hit reset.
<dimitern> dooferlad, just a heads up about tomorrow and friday - approved
<dimitern> dooferlad, please update the calendar
<dooferlad> I had 8 KVMs running, so I figured those may be an issue...
<dimitern> :D
<fwereade> thumper, final-leadership-switch-1.24
<dooferlad> eugh. bug #919437 sucks
<mup> Bug #919437: Lost window, cannot get it back. <amd64> <apport-bug> <distro-priority> <precise> <running-unity> <Compiz:New> <Compiz Core:New> <Unity Distro Priority:Fix Committed> <compiz (Ubuntu):Confirmed> <https://launchpad.net/bugs/919437>
<mup> Bug #1479278 opened: service status derivation happens in the wrong place <juju-core:Triaged> <https://launchpad.net/bugs/1479278>
<mattyw> axw, ping?
<axw> mattyw: hey, I'm here for just a moment. what's up?
<axw> mattyw: sorry gotta go again, leave a message I'll check back later
<mattyw> axw, sorry, missed you. no problem, I've added another question about that branch, it's basically lgtm to me though, I just need enlightening :)
<mup> Bug #1479289 opened: statushistory uses sequence, fails in multi-env state servers <juju-core:Triaged by wallyworld> <https://launchpad.net/bugs/1479289>
<axw> mattyw: thanks for the review
<mattyw> axw, welcome, sorry I missed it
<mattyw> axw, reviewboard colours invert if I have my monitor at the wrong angle
<axw> mattyw: oh :/
<mattyw> axw, one of my faviourite features
<dimitern> dooferlad, hey
<dimitern> dooferlad, are available now for about 1/2h ?
<dimitern> perhaps less
<dooferlad> dimitern: just grabbing coffee and then will be back from lunch.
<dooferlad> dimitern: back
<dimitern> dooferlad, ok
<dimitern> dooferlad, let's use our 1:1 g+ and the c9 workspace?
<dooferlad> dimitern: sounds good
<TheMue> dimitern: ping
<dimitern> TheMue, pong
<TheMue> dimitern: wanted to have a quick chat about the final failing test
<TheMue> dimitern: it is at https://github.com/TheMue/juju/blob/addresser-worker-using-api/worker/addresser/worker_test.go#L237
<TheMue> dimitern: here I've got a timeout when waiting for a release op by the dummy provider
<dimitern> TheMue, sure, looking
<TheMue> dimitern: the rest works fine
<TheMue> dimitern: I'll paste the debug log, mom
<TheMue> dimitern: so, http://paste.ubuntu.com/11959517/, could help
<dimitern> TheMue, could it be due to this: https://github.com/TheMue/juju/blob/addresser-worker-using-api/worker/addresser/worker_test.go#L90
<dimitern> more than 10 ops queued?
<TheMue> dimitern: it's worth a try, due to the now happening bulk requests.
<dimitern> TheMue, try logging each ReleaseAddress dummy method call
<TheMue> dimitern: nope, no change. and the number of dummy ops should be the same, even with bulk request. they happen per address on the server
<dimitern> TheMue, is the  apiserver facade actually calling the environ ReleaseAddress ?
<dimitern> TheMue, I see no logs there
<dimitern> s/there/about it/
<TheMue> dimitern: in principle it does, all other tests waiting for releases work, and the op is sent by the dummy provider
<TheMue> dimitern: but SetUp adds four addresses, later a fifths is added in this test, and I only see four tries to release
<TheMue> dimitern: this 0.1.2.9 seems not to be released
<TheMue> dimitern: when the machine is removed the address is dead, but it looks like the addresser doesn't recognises it
<TheMue> dimitern: TestWorkerRemovesDeadAddress() in line 179 has no problem *sigh*
<dimitern> TheMue, yeah, but there the addresses start as dead
<dimitern> TheMue, so it feels like a watcher/sync issue
<dimitern> TheMue, why call do you StartSync again in TestMachineRemovalTriggersWorker (twice even?)
<TheMue> dimitern: ok, will add some debug statements on this path
<dimitern> TheMue, IIRC StartSync spawns a goroutine
<TheMue> dimitern: the tests are take as they have been before, I only had to change one combined error message so far
<TheMue> dimitern: my hope have been good blackbox tests don't caring if the addresses uses and api or state
<TheMue> ;)
<TheMue> dimitern: but ok, have now a direction where to investigate, thanks
<dimitern> TheMue, well, since the logic has changed, the tests might break - e.g. 2 ops per list of ips (release, remove) rather than 2xN
<TheMue> dimitern: aren't the ops by the dummy, so that only the calls to env are counted? those are only the release calls, remove then works on state again
<TheMue> dimitern: and the number of release calls depends on the number of ips in the test case
<dimitern> TheMue, true I think - env.ReleaseAddress is called once per IP
<TheMue> dimitern: it's now only that it isn't called by the worker but by the server api
<TheMue> dimitern: yep
<TheMue> dimitern: the server api gets a bulk to release and then calls the according env menthod
<TheMue> ... n times
<dimitern> TheMue, I'd suggest more logging
<dimitern> TheMue, I need to be in a call now, but let's revisit it tomorrow if it's still an issue?
<TheMue> dimitern: yes, will do so, thanks for support
<dimitern> TheMue, np
 * TheMue rants about the weather. we've got July 29th and I sit here with thick socks, blanket, and cardigan. :( cold.dislike == true
<dooferlad> dimitern: https://github.com/juju/juju/compare/net-cli...dooferlad:net-cli-spaces-state?expand=1 should be more like what you were after. I hope.
<dooferlad> dimitern: I am going to grab some tea, but am happy to talk about the branch. I know it needs more tests!
<dimitern> dooferlad, ack, will look shortly
<dimitern> dooferlad, looks mostly OK, just a few passing notes: use string and []string in params structs, not names.*Tag - the params struct describes the wire format (and for some other good reason that currently escapes me)
<dimitern> dooferlad, also - doc types in state are not exported for a reason; no need to declare SetUp*/TearDown* for SpacesSuite - this is needed only if you embed multiple "suite" types etc.
<dooferlad> dimitern: I thought we were trying to always call the SetUp* etc calls, even if they weren't needed, just because of good habits.
<dooferlad> dimitern: I don't care either way
<dimitern> dooferlad, if we do now, I'm not aware of it :)
<mgz> dooferlad: you don't need to redirene SetUp* if you're embedding exactly one suite
<mgz> *redefine
<mgz> because gocheck will just call that setup
<mgz> what you have to be careful about is if you embed multiple suites, or write your own SetUp* - then you need to upcall
<dooferlad> mgz: apparently I imagined a conversation about it. Will get rid.
<mgz> dooferlad: the thread happened, the circumstances are just a little narrower than you were thinking
<dooferlad> mgz: good to know :-)
<menn0> anyone able to review these?
<menn0> http://reviews.vapour.ws/r/2276/
<menn0> http://reviews.vapour.ws/r/2275/
<menn0> (easy ones)
<perrito666> menn0: ill give it a shot
<menn0> perrito666: thank you
<perrito666> menn0: any idea why the tags where there for bson?
<menn0> perrito666: I suspect it was started by someone who didn't understand what they were doing and then other people copied
<menn0> cargo cult programming
<perrito666> menn0: indeed, I especially like the seccond one
<perrito666> I am a bit amazed that nothing broke there
<perrito666> almost too good to be true
<menn0> :)
<menn0> perrito666: i'm about to make some more signficant changes that will almost certainly break things :)
<perrito666> menn0: yeah, its the interface->string change that has me baffled
 * perrito666 also sees a lots of panics and supposes this code was just ugly from scratch
<menn0> perrito666: that's just a simple tidy up... all the ids were strings anyway, and localID() was being called on all of them, so I just changed where that was being done so it's just in one place
<perrito666> menn0:  shipthem
<menn0> perrito666: thanks
<menn0> perrito666: yeah, this area is a bit special
<perrito666> menn0: I was just suspicious of exactly that, as if the code was writen for public facing stuff but all methods where private
<menn0> perrito666: yep. the stuff I changed is all internal only.
<perrito666> leadership is currently broken in master?
<menn0> perrito666: pretty much
<menn0> perrito666: will is working on it
<perrito666> menn0: I was not sure if it was broken or just extremely unstable
 * perrito666 cannot ftloc make status tests pass
<menn0> perrito666: extremely unstable ~= broken
<mup> Bug #1479546 opened: Storage provisioner timeouts spawning extra volumes on AWS <juju-core:New> <https://launchpad.net/bugs/1479546>
<menn0> waigani: review pls? http://reviews.vapour.ws/r/2277/
<davecheney> menn0: how expensive is that call to st.EnvUUID() ?
<menn0> davecheney: not very. it just returns a field of the struct
<menn0> davecheney: and ... you're back!
<davecheney> i am
<davecheney> hello
<davecheney> in taht case
<davecheney> LGTM
<davecheney> (as I'm also OCR today)
#juju-dev 2015-07-30
<menn0> davecheney: I knew that but didn't think you were around
<davecheney> got back on monday
<davecheney> took a few days off to recover
<davecheney> now back to hunting races
<davecheney> \o/
<anastasiamac> wow! first time experiencing eqrthquake in Brisbane... 5.3 @ 35km of coral sea :D
<mup> Bug #1479653 opened: state depends on system clock <tech-debt> <juju-core:Triaged> <https://launchpad.net/bugs/1479653>
<TheMue> dimitern: ping
<dimitern> TheMue, pong
<TheMue> dimitern: feeling better today, good for work, but not for hangout. but getting closer with the test problem. assigning a new IP address to a machine that exists before (!) the worker started leads to the wanted event. but if the machine is created after the worker nor events are raised. interesting behavior, will add more logging
<TheMue> dimitern: wondered like you yesterday, that the 0.1.2.9 is never shown in the logs.
<dimitern> TheMue, I'm glad you're feeling better
<TheMue> dimitern: now simply created a 0.1.2.10 and added it to the 1st machine initialized in SetUp it funnily is logged
<dimitern> TheMue, hmm this feels like the EntityWatcher is forwarding the initial event, but then it's not triggering on change?
<TheMue> dimitern: thanks, thankfully our job allows to work below a blanket ;)
<TheMue> dimitern: the change comes later, but it is related to an already existing machine
<dimitern> TheMue, :) yeah
<dimitern> TheMue, not quite sure I follow you - please describe the steps when the event is triggered (and when it's not) in detail
<TheMue> dimitern: IMHO the state.WatchIPAddresses() should react on state.AddIPAddress()
<TheMue> dimitern: ok, prepare a small paste
<dimitern> TheMue, hmm wait
<dimitern> TheMue, AddIPAddress adds an alive address, right?
<dimitern> TheMue, doesn't the entity watcher only trigger on dead addresses?
<TheMue> dimitern: http://paste.ubuntu.com/11965055/
<TheMue> dimitern: IMHO not, but would have to look. It's only a mapping StringWatcher, which maps the received string values to their according entity tags
<TheMue> dimitern: I wondered, because another existing test adding a new IP doesn't fail. but it uses the existing machine. so I added this fragment to my failing test and found the astonishing behavior.
<dimitern> TheMue, looking at the code to remind myself what was implemented
<TheMue> dimitern: /me too, digging deeper and adding more logs (have to remove them afterwards, phew)
<dimitern> TheMue, so the worker starts the watcher on SetUp ?
<dimitern> TheMue, show me your latest branch code please
<TheMue> dimitern: the branch is here: https://github.com/TheMue/juju/tree/addresser-worker-using-api
<dimitern> TheMue, so far, looking at state, api, and apiserver watcher code I can't see any obvious flaws that might be causing it, so it must be the way worker uses it
<alexisb> fwereade, I will need to steal thumper for 30 minutes
<TheMue> dimitern: ah, wait, I've got an idea. may be due to the mix of strings watcher and entity watcher
<TheMue> alexisb: heya o/
<dimitern> TheMue, I don't see your worker implementing SetUp, where it should start the watcher
<alexisb> heya TheMue
<dimitern> TheMue, ah, I saw it below
<TheMue> dimitern: yep
<dimitern> alexisb, hey, btw there's a 30m scheduling conflict for OS+juju call and networking roadmap one
<dimitern> alexisb, I guess the OS call is more important than the other one?
<alexisb> dimitern, I am not sure what the OS+juju call?
<dimitern> alexisb, the one with jamespage
<alexisb> dimitern, you are good, they are the same
<dimitern> alexisb, I see :) cheers then
<dimitern> TheMue, does waitForInitialDead work in your branch (TestWorkerRemovesDeadAddresses) ?
<TheMue> dimitern: yes, all other tests are fine
<dimitern> TheMue, waitForInitialDead should (almost?) immediately see 2 dead IPs - 0.1.2.4 and 0.1.2.6, right?
<TheMue> dimitern: yes, as those belong to machine2
<dimitern> TheMue, fetching the IPAddress from state and then calling EnsureDead on it is weird
<dimitern> TheMue, it's not what will happen in real life - the address being dead is a side effect of the machine it's assigned to getting destroyed
<TheMue> dimitern: you mean in TestWorkerRemovesDeadAddress? that's what I found in the existing tests
<TheMue> dimitern: the failing one is TestMachineRemovalTriggersWorker
<dimitern> TheMue, but, machine removal should indeed trigger "Set all allocated ips to dead for this machine id"
<TheMue> dimitern: so the original test already has been wrong? can remove it then
<dimitern> TheMue, no :) let's think first why it's failing
<dimitern> TheMue, so *only* TestMachineRemovalTriggersWorker fails?
<TheMue> dimitern: yes, and the IP address is dead, see the adderts following to the machine removal
<TheMue> dimitern: exactly, the rest works fine
<dimitern> TheMue, then there's the problem :)
<TheMue> dimitern: already the adding of the new IP to the new machine isn't reported (at least as alive) while the reporting to a machine existing before the worker is started is reported (see pastebin, the second IP is reported)
<dimitern> TheMue, see, removing a machine should include an op to ensure all alive ips of that machine end up dead *without* needing to do anything else (e.g. expecting the provisioner to see the machine getting dead and marking allocated ips as dead)
<dimitern> TheMue, so I'd dig more into the list of ops machine.EnsureDead() and/or Remove() includes w.r.t. ipaddressesC
<TheMue> dimitern: yeah, just started a state browsing of ipaddressesC to look exactly there ;)
<dimitern> TheMue, adding a new alive IP (not need to even allocate it to machine) *should* trigger the IP addresses watcher, but should be ignored by the worker I *think*
<TheMue> dimitern: as it is alive, yes. the logs should show it like "[LOG] 0:00.351 DEBUG juju.worker.addresser IP address ipaddress-03c48ed1-c389-4930-82e1-1df101fb7ab2 is not dead (life "alive"); skipping"
<dimitern> TheMue, I *seriously* hope we dial down this log message to TRACE level (image thousands of IPs being reported when rapidly provisioning machines)
<TheMue> dimitern: so far I haven't touched the log levels I found, but can do it while finishing the code
<dimitern> TheMue, if I've suggested adding it at DEBUG, sorry
<TheMue> dimitern: the modification on worker level has been less than thought, mostly moving the release stuff to server side and change behavior from single to bulk
<dimitern> TheMue, state.ensureIPAddressDeadOp looks dangerous on its own - without an assert isAliveDoc (and the corresponding handing of ErrAborted where it's called) it's potentially overwriting the life field of the doc indiscriminately
<TheMue> dimitern: I see. so the original intention has been to set the address to dead regardless of its life status? what's happening, when it isn't alive, so dying or already dead?
<TheMue> dimitern: one usage is in Machine.Remove()
<dimitern> TheMue, yeah, that's the one without an assert set, the other (with isAliveDoc) is in IPAddress.EnsureDead
<TheMue> dimitern: and one is in IPAddress.EnsureDead() with an assert isAliveDoc
<TheMue> h5
 * TheMue loves mongo transactions <SARCASM OFF/>
<dimitern> TheMue, have you tried: 1) adding s.State.StartSync() just after line 234 (asserting the addr is dead); 2) if that doesn't work, try removing one or both of the other StartSync() calls before that, but leave the one introduced in 1)
<dimitern> TheMue, looking at the sequence of ops, it looks like waitForReleaseOp is timing out because the apiserver has no chance of observing the address being dead before reading from the dummy ops chan
<dimitern> TheMue, however, since opsChan is buffered, that shouldn't be the case (unless buffer size of 10 is somehow not enough)
<TheMue> dimitern: already tried with a larger buffer, and played with the StartSync()s. not sure if I've done it how you've described, so I'll do now
<dimitern> TheMue, need to get in a call, let's continue later
<TheMue> dimitern: ok
<perrito666> morning
 * perrito666 is devoid of his internet connection
<dimitern> TheMue, any luck isolating the issue?
<TheMue> dimitern: not yet done, but deeper, heads down in the lifecycle watcher ;) wondering about its merge()
<TheMue> dimitern: one moment, showing you an interesting log fragment
<dimitern> TheMue, ok
<TheMue> dimitern: http://paste.ubuntu.com/11966200/
<TheMue> dimitern: so, here the first four addresses are the normal ones
<TheMue> dimitern: the 0.1.2.9 is the one for the new created machine
<TheMue> dimitern: the 0.1.2.10 is instead created for the existing machine
<TheMue> dimitern: why is the 0.1.2.9 in updates, but not in the updated ids anymore? the only step between is the merge() of the lifecycle watcher and here I'm looking now
<dimitern> TheMue, it looks to me the lifecycle watcher is receiving entities with wrongly prefixed IDs
<TheMue> dimitern: the updates map contains all known IPs so far, all with the env id as prefix
<TheMue> dimitern: so I have to see what merge() exactly does
<dimitern> TheMue, hmm that's right - the ids are ok at that point
 * TheMue never has been so deep in our watcher. this mix of differently formatted events, transformations, mappings, online queries etc seems weird sometimes
<dimitern> TheMue, merge should combine the updates with the entities with known life and produce ids for the changes
<TheMue> dimitern: and you can imagine the large number or debug statements *lol*
<TheMue> dimitern: and here it drops the 0.1.2.9, maybe after its machine has been removed <LOOKING />
<dimitern> TheMue, nothing should just remove ips without releasing them, the machine removal just triggers "set to dead"
<perrito666> TheMue: any part of juju, upon detailed inspection, looks weird
<TheMue> perrito666: *rofl* thanks for motivational remarks from Argentina
<dimitern> TheMue, and I don't get why 0.1.2.3 is even there
<TheMue> perrito666: heya btw
<perrito666> TheMue: hi :)
<TheMue> dimitern: you mean the received one?
<dimitern> TheMue, yeah
<TheMue> dimitern: you're right, the machine as well as its IPs aren't touched during the test
<TheMue> dimitern: http://paste.ubuntu.com/11966320/ to understand where and what I'm logging in the lifecycle watcher
 * TheMue should add a debug log remover based on the comments above to his juju development tool ...
<dimitern> TheMue, it seems more and more like a sync issue to me
<dimitern> TheMue, have you tried dropping all StartSync() calls?
<TheMue> dimitern: yes, the log is w/o sync as well as w/ sync after the assert that the ip addrress is dead
<TheMue> dimitern: doesn't change anything
<TheMue> dimitern: and as I said, the IP assigned to the new machine is dropped in the notifications while the one for an existing machine is kept
<TheMue> dimitern: look how different the .9 and the .10 behave
<TheMue> dimitern: a theoretical question
<TheMue> dimitern: oh, forget, got it while formulating it
<dimitern> TheMue, :)
<dimitern> TheMue, weird issue indeed
 * dimitern *hates* debugging watchers
 * TheMue too
<TheMue> dimitern: boah, no, you don't get it
<TheMue> dimitern: I took a deeper look at merge() with the individual states of the IPs etc
<TheMue> dimitern: and I've seen that the .9 always is dead
<TheMue> dimitern: and never known as alive
<TheMue> dimitern: so no removal
<TheMue> dimitern: then I thought we've too fast, dead simple
<TheMue> dimitern: and for testing I added a 30secs pause between adding and machine removal
<TheMue> dimitern: and now - *TADDAAH* - the test passes
<TheMue> dimitern: so, yes, it is a syncing problem, but different from State.StartSync()
<dimitern> TheMue, sorry, was afk; catching up..
<dimitern> TheMue, that sounds like the desired behavior for watchers (consolidating multiple changes between two events)
<TheMue> dimitern: isn't the API watcher a kind of polling?
<TheMue> dimitern: because we now don't have a direct state watcher anymore, but using the API
<dimitern> TheMue, ok, how about this: instead of sleeping for 30s, just add a short attempt loop between machine removal and adding 0.1.2.9 and setting it to dead
<TheMue> dimitern: sure, the hard coded sleep just has been a test
<dimitern> TheMue, cheers
<katco> wwitzel3: natefinch: ericsnow: ping
<ericsnow> katco: heyheyhey
<wwitzel3> katco: pong
<katco> o/
<katco> did you guys get my email?
<katco> how are we looking for iteration work?
<wwitzel3> katco: good, the state/persistence story won't land
<wwitzel3> katco: all others will be done by EOD Friday
<wwitzel3> katco: of the pointed stuff that is
<katco> wwitzel3: i can live with that :)
<wwitzel3> katco: we have some low-prio overhead that probably won't get done
<katco> wwitzel3: understood... glad the pointed work is mostly landed
<katco> wwitzel3: ericsnow: ty, just wanted to check in!
<katco> we'll talk about the sprint sometime after i get back. lots of interesting stuff
<ericsnow> katco: sweet
<katco> ericsnow: wwitzel3: k gotta run to another meeting... ty again, and if i don't talk to you before, have a great weekend
<wwitzel3> katco: dibs on the Python library, lol
<katco> rofl
<ericsnow> wwitzel3: dang it!
<ericsnow> wwitzel3: we should pair up :)
<wwitzel3> katco: you too, safe travels
<ericsnow> katco: ditto
<thumper> o/ sinzui
<thumper> sinzui: been working with fwereade on this blocker issue
<thumper> just asked the bot to land it
<thumper> it has been tested by Ed to deploy a complex openstack bundle that uses leadership a lot
<thumper> and it all worked
<thumper> \o/
<thumper> also, I have run all the tests locally, and they at least pass here
<thumper> first time too
 * thumper crosses fingers for the bot to do its thing
<thumper> hello?
<thumper> anyone alive in here?
 * thumper streaks through the empty channel
 * ericsnow averts eyes
<alexisb> ericsnow, all of us in annecy have to see it in real life
<mgz> thumper: sorry, I wasn't sure if there was actually a question in all that
 * alexisb is blinded
<thumper> mgz: there wasn't
<ericsnow> alexisb: :)
<mgz> thumper: okay then, carry on streaking :)
<thumper> but I do like to know that I'm not just talking to myself
<wwitzel3> lol
<alexisb> mgz, as soon as we land it is release time
<thumper> well
<thumper> once it passes CI
<wwitzel3> I've given up and just assume I'm always talking to myself
<alexisb> thumper, details details ;)
<alexisb> mgz, what thumper said
<thumper> wwitzel3: so... tycho here is doing some lxd container stuff for us
<sinzui> thumper: was OTP. CI is ready for your landing
<wwitzel3> thumper: awesome
<thumper> sinzui: coolio
<wwitzel3> thumper: what stuff?
<thumper> container/lxd
<sinzui> thumper: alexisb mgz: Robie had a brilliant idea to solve the deoloyer/quicikstart/pyjujuclient problem. Maybe we can include those plugins in the juju-code source package to ensure lock-step delivery of compatible plugins to trusty (and everywhere)
<wwitzel3> thumper: right, but what about it is being done for us, I mean
<alexisb> wwitzel3, tych0 is adding lxd support to juju-core
<alexisb> sinzui, thumper and mramm have been pondering that
<alexisb> and I am sure would like your input
<wwitzel3> alexisb: oh, nice :)
<sinzui> alexisb: we can release as we have done in the past. But I thinkn we need to change the policy to release blessed revisions that have passed compatability and reliability tests. Those tests take days to run and mostly run on weekends when CI has more resources
<tych0> thumper: github.com/tych0/juju lxd-container-type
<perrito666> anyone more or less familiar with environ.Config?
<TheMue> perrito666: don't know if I can help you, but ask
<perrito666> I am looking at the implementation because I might want to add a key but I am not sure I understand it properly
<TheMue> perrito666: regarding schema and default values?
<mup> Bug #1479889 opened: Test failure com_juju_juju_featuretests.TearDownTest.pN44_github.com_juju_juju_featuretests.dblogSuite <ci> <intermittent-failure> <ppc64el> <test-failure> <unit-tests> <juju-core:Triaged> <juju-core trunk:Triaged> <https://launchpad.net/bugs/1479889>
<redelmann> Hi there.
<redelmann> Need some help upgrading juju 1.23 to 1.24.3
<redelmann> 1.23.3 to 1.24.3
<perrito666> redelmann: what is going on?
<redelmann> perrito666, hi.
<redelmann> perrito666, i was trying to upgrade juju in maas environment
<redelmann> perrito666, after running "juju upgrade-juju"
<redelmann> perrito666, machine0.log says: http://paste.ubuntu.com/11967995/
<redelmann> perrito666, Well, after that I can't run any juju command
<redelmann> perrito666, that's the problem :P
<perrito666> mm, are the machines still there? if so what is on the logs for machine 0? (Assuming you can access it)
<redelmann> perrito666, all machines are online, machine0.log:  http://paste.ubuntu.com/11967995/
<perrito666> have you tried restarting the juju service by hand?
<redelmann> perrito666, yes, and nothing happend
<redelmann> perrito666, same log
<perrito666> mm, strange, I think you will have to make some changes by hand
<redelmann> perrito666, "ls /var/lib/juju/tools": http://paste.ubuntu.com/11968047/
<redelmann> perrito666, agents tools are there, but not linked
<perrito666> there is more than that to updates :)
<redelmann> perrito666, well i suppose that moving links will not fix anything
<perrito666> redelmann: I cannot really recall what change you need to do
<redelmann> perrito666, mhhh.... look at this:
<redelmann> perrito666, http://paste.ubuntu.com/11968067/
<perrito666> redelmann: the rest are links
<redelmann> perrito666, :P i see
<redelmann> perrito666, couldn't read wrench directory: stat /var/lib/juju/wrench: no such file or directory
<redelmann> perrito666, that's is nothing to worry about?
<perrito666> that is not a problem, wrench is something to develop
<perrito666> t is used to introduce failures into juju
<redelmann> perrito666, i suppose that: rsyslogd-2039: Could no open output pipe '/dev/xconsole': No such file or directory [try http://www.rsyslog.com/e/2039 ]
<redelmann> perrito666, is not a problem too
<natefinch> ericsnow: I'd love it if you could review the status stuff again today.  I think it should be all set.
<ericsnow> natefinch: will do
<redelmann> perrito666, Ok, fixed by hand
<perrito666> hey, I was afk, how did you?
<marcoceppi> katco: could you or someone from moonstone look into this? https://bugs.launchpad.net/juju-core/+bug/1478156
<mup> Bug #1478156: summary format does not give enough details about machine provisioning errors <charmers> <juju-core:Triaged> <https://launchpad.net/bugs/1478156>
<marcoceppi> katco: ugh, nvm
<marcoceppi> I see it's marked as high now, I had old data on the page
<natefinch> wwitzel3: you around?
<natefinch> ericsnow: you around?
<ericsnow> natefinch: yep
<natefinch> ericsnow: I was trying to work out what exactly I needed to do for my kanban card about local file images and docker.... and it seems like there's no such thing as a local file image... they're all stored in a local docker repository and behave exactly like remote ones.... there's no "docker run file://home/nate/mydockerimage"
<natefinch> at least as far as I can tell
<ericsnow> natefinch: the idea is, for local file images, to load them first
<mup> Bug #1479931 opened: Juju 1.22.6 cannot upgrade to 1.24.3/1.24.4 <blocker> <ci> <regression> <upgrade-juju> <juju-core:Triaged> <juju-core 1.24:Triaged> <https://launchpad.net/bugs/1479931>
<mup> Bug #1479942 opened: Reference to undefined method <ci> <intermittent-failure> <ppc64el> <test-failure> <juju-core:Triaged> <https://launchpad.net/bugs/1479942>
<natefinch> ericsnow: sort of a problem... the name of the tar file bears no relation to the name of the image.
<natefinch> ericsnow: so if we're given foo.tar as something to load and run... we can load it, but we won't know what it is called once it's in the registry.  I guess we could look in the tar file and figure it out :/
<ericsnow> natefinch: wwitzel3 will have to take it from here; I don't know enough about that
<natefinch> ericsnow: ok... actually, looks like a tar can have multiple images, so it even moreso won't work
<wwitzel3> natefinch: yeah, looking at some of the other tools out there that wrap docker, they take an inventory first, using docker images
<wwitzel3> natefinch: then they load it, and parse the diff
<natefinch> wwitzel3: doesn't solve the problem if more than one image is loaded from the tar file
<wwitzel3> natefinch: we could also use the remote API instead of wrapping the cmd
<wwitzel3> natefinch: it does, since we would parse out both of them and they can only specify a single image name in the process definition
<natefinch> wwitzel3: but I thought the feature was that the image name *is* the tar file
<ericsnow> natefinch: gave you one last review (LGTM with some minor caveats)
<natefinch> ericsnow: thanks
<ericsnow> natefinch: np
<wwitzel3> natefinch: well, in that case we could launch and register both
<wwitzel3> natefinch: or we could leave image as is and make the file to load a type specific arg
<natefinch> wwitzel3: so, does this seem like a useful feature?  Is the idea that someone will package a tar file in their charm?
<wwitzel3> natefinch: I can't remember the reason for it, it was based on some feedback we got iirc
<natefinch> wwitzel3: seems like it needs to be better defined before we work on it.  I don't want to guess at the correct implementation.
<wwitzel3> natefinch: I don't even see a card for it
<wwitzel3> natefinch: oh, there it is, overhead
<natefinch> wwitzel3: yep
<wwitzel3> natefinch: so if the file replaces the image name, then it won't matter how many images are in the tar, we would just load and launch any it contained
<natefinch> wwitzel3: I don't think that's a good idea... in all other cases, the process specification is for a single process - you give it a command to run, etc.  I think it would be surprising for a single process definition in the yaml to result in multiple registered processes.
<natefinch> wwitzel3: maybe if we added a LoadFrom field in the process info that would tell Juju to load the image before launching it
<natefinch> or maybe we need a separate step that loads all images before we start launching processes
<wwitzel3> natefinch: I don't think it would be a surprise if I, the charm author provided a tar that had multiple images in it, but we shouldn't be designing this interacton anyway. We should probably ping lazyPower and whit about what that interaction would look like and what they want :)
<lazyPower> hello o/
<lazyPower> in office hours
<lazyPower> will circle back when we're out, because i know what you're talking about and want to be a part of it
<natefinch> lazyPower: awesome
<natefinch> lazyPower: I love a man that knows what he wants ;)
<lazyPower> natefinch: ok my session is over, whaaatt would we like to do with process management in charming? :) i have some ideas already for example workloads to deliver with this.
<lazyPower> ah i see, this is wrt multi processes
<natefinch> lazyPower: well, so, I had a work item to support loading images from files on disk (a la docker's load from a tar)
<lazyPower> ok, i dont see shipping multiple images in teh charm, i see more shipping with a dockerfile/compose-formation, and building on the host during deploy, or pulling from a private registry
<lazyPower> thats the established pattern. Do we want to advocate for fatpacking images in a charm?
<natefinch> I don't know that we want to make that standard practice, but some people may certainly ask for it.  Fat charms are popular.
<lazyPower> ok, let me re-check the spec to make sur ei'm on the same page
<lazyPower> i dont want to try and account for something thats already been discussed.
<natefinch> lazyPower: AFAIK, it's not in the spec. So maybe that answers the question
<natefinch> ^^ ericsnow
<lazyPower> We can always file and iterate
<ericsnow> natefinch: this is something we added to the spec late last week in response to feedback katco got prepping for the demo
<lazyPower> i think if you put in multiple resource uri's, fetch them
<lazyPower> it wont be ovious to the user they only get a single resource, and thats not a one size fits all scenario
<lazyPower> *obvious
<lazyPower> and we'll see weird things happening like people tarballing up multiple images and then writing extra code to handle that when we could be handling it in the delivery mechanism
<lazyPower> s/images/payloads/
<natefinch> ericsnow: I think it's a bad idea to munge the idea of images with the tar files that docker supports.  tar != image
<natefinch> ericsnow: I'd prefer to either let the charm do the loading itself during install, or add a new field that'll tell juju how to load the info
<ericsnow> natefinch: hey, it wasn't *my* idea! :)
<wwitzel3> natefinch: I think having another field for the URI seperate from the image is fine
<wwitzel3> natefinch: since that would also work for the location of a private docker registry
<natefinch> wwitzel3: that seems fine... unless you wanted to specify both
<natefinch> wwitzel3: load the images from this tar into this registry... or is that not a thing?
<wwitzel3> natefinch: if you want to specify both, then you define two processes
<wwitzel3> natefinch: packing two images in to a single tar isn't that common from what I know, lazyPower might have more experience with that than me
<wwitzel3> natefinch: but I've not seen it done personally, because the size of the tar is already large, most people are trying to make their images and archives smaller, not bigger
<lazyPower> wwitzel3: well, you wouldnt hve 2 images in a single tar
<lazyPower> once you export, its a single package per container. I can see someone trying to work around an artificial limitation by bundling 2 images in a tar file
<lazyPower> but that wouldn't be the norm i dont think.
<lazyPower> unless you're trying to get hyper specific with arch and support multi-arch in the charm
<lazyPower> ARMHF images will not run on amd64 for example, and vice versa
<natefinch> ericsnow: ug, these juju status tests are horrible
<ericsnow> natefinch: sorry
<natefinch> ericsnow: as well you should be ;)
<natefinch> ericsnow, wwitzel3, lazyPower: what do you guys think about adding a resource: key to the process info, that gets passed to the plugin, and the plugin can handle it however it wants (for docker it would do a docker load)
<lazyPower> I like that idea
<perrito666> natefinch: i would be a bit careful about the use of the word resource
<ericsnow> natefinch: at long as it makes sense as a general feature and not just mostly-docker-specific
<perrito666> I really dont feel like having State all over again
<natefinch> ericsnow: I presume other container technologies might need a separate step for "install the image"  before running it... but I don't know.
<ericsnow> natefinch: yeah, who knows
<lazyPower> natefinch: looking at the existing things - rocket/docker/runc - its all basically the same delivery mechanism
<ericsnow> natefinch: for now we could just support it with a type option
<lazyPower> but looking @ say, tomcat - loading a warfile has a different process
<natefinch> ericsnow: ahh, yeah, type options... that makes sense
<natefinch> ericsnow: forgot about that escape hatch
<ericsnow> natefinch: yep, that's why we added them
<natefinch> ok I gotta run.  I'll do it via type-option for now, and we can always make it more official later
<ericsnow> natefinch: sounds good
<lazyPower> natefinch: ericsnow - is this going into a different branch than what landed for the concept wwitzel3 did?
<ericsnow> lazyPower: nope, it'll go into feature-proc-mgmt
<wwitzel3> lazyPower: it is going in to feature-proc-mgmt branch
<lazyPower> ack
<lazyPower> i'm going to setup a build and get a container running for this while its under active dev if you'd like active feedback on the feature before it hits CR
<lazyPower> I had intended to do this for wwitzel3 but got sidetracked with the 1.0 launch of k8's
<wwitzel3> yes please *bat eyelashes*
<lazyPower> :) you got it dude
<lazyPower> wwitzel3: i'll ping when i'm working on it tomorrow
<wwitzel3> lazyPower: awesome, ty
<sinzui> cherylj: you cannot make CI regression as fix released, we have tests and cloud checks that say upgrades are broken
<cherylj> I didn't do that
<cherylj> sinzui: It was set to fix released by the QA bit
<cherylj> bot
<sinzui> cherylj: from the same report we can see http://reports.vapour.ws/releases/2934 that the 22 jobs failed
<cherylj> sinzui: Yeah, I can recreate the failure.  Debugging it more now.
<sinzui> cherylj: sorry, IU have two email with your name first :( I had to make them non-voting for this run because if the command to release 1.24.4, but I will mkae the voting again soon
<cherylj> sinzui: I think this is a problem with 1.22.6, not 1.24.3/4.  The upgrade is failing when it's trying to get the tools for 1.24.3
<cherylj> just fyi
<sinzui> cherylj: maybe we should try 1.22.7 (1.22 tip) if it works, it is an incentive to relesse as soon as possible.
<cherylj> sinzui: I can give that a try after this debug run I'm doing now.
<cherylj> ec2 seems particularly slow for me today :(
<sinzui> cherylj: Indeed it is installing packafes seems to be taking longer
<sinzui> cherylj: Joyent and GCE are the fastest clouds. I tend to use joyent
<cherylj> sinzui: are there some shared creds for the core team?  or do I need to create my own account?
<sinzui> cherylj: in cloud-city? yes you can use default-joyent. and you can try different regions
<cherylj> menn0: The state server will refuse connections while it's performing an upgrade, right?
<cherylj> menn0: It appears that the state server is hung trying to unpack the tools, and I see the syslog filling up with these errors:  http://paste.ubuntu.com/11969606/
<menn0> cherylj: no the state server still accepts connections during an upgrade
<cherylj> this is weird.
<menn0> cherylj: the available API requests are quite limited though
<menn0> cherylj: status should still work
<menn0> cherylj: "the not authorized for status" error is worrying
<cherylj> yeah
<menn0> cherylj: also, the very high connection count
<cherylj> just keeps going up!
<cherylj> heh
<menn0> cherylj: something in juju isn't releasing the connections
<menn0> cherylj: that's probably not the root cause but related to it
<menn0> cherylj: the authorization errors sounds closer the root cause
<menn0> have you got the machine-0.log?
<menn0> hang on... flying solo with a kid at the moment and he's calling
<cherylj> yeah, I can add your SSH key to this machine.
<sinzui> cherylj: menn0 help: I don't know which bugs thumpers merge at tip https://github.com/juju/juju/commits/1.24 were fixed. I can make a release, but I cannot say what issues are fixed
<menn0> sinzui: looking
<menn0> sinzui: looks like will and thumper have been activating the new leadership bits
<menn0> sinzui: this will fix bug 1478024
<mup> Bug #1478024: Looping config-changed hooks in fresh juju-core 1.24.3 Openstack deployment <blocker> <canonical-bootstack> <leadership> <upgrade-juju> <juju-core:Triaged> <juju-core 1.24:In Progress by fwereade> <https://launchpad.net/bugs/1478024>
<sinzui> \o/
<menn0> sinzui: but I wouldn't cut a release until they say it's done
<menn0> sinzui: based on the commit messages it looks like they're close though
<sinzui> menn0: I see this in the context od thumper, mgz and alexis a few hours ago
<sinzui> alexisb>
<sinzui> mgz, as soon as we land it is release time
<menn0> sinzui: ok cool
 * sinzui this the final job just passed and the rev is bless by all the old rules
<menn0> sinzui: we still have bug 1479931
<mup> Bug #1479931: Juju 1.22.6 cannot upgrade to 1.24.3/1.24.4 <blocker> <ci> <regression> <upgrade-juju> <juju-core:Triaged> <juju-core 1.24:Triaged> <https://launchpad.net/bugs/1479931>
<menn0> sinzui: for some reason the QA bot marked it as fix released for 1.24
<menn0> sinzui: but cherylj was able to repro it
<menn0> sinzui: we're looking at that one now
<sinzui> menn0: We had to make the two jobs that show the regression non-voting, which conviced CI that ere was a bless
<menn0> sinzui: never mind... I just saw your comment on the bug
<menn0> sinzui: cool, makes sense
<sinzui> menn0: we are jugglin a nasty case of a regression in the wild. 1.24.4 is better than 1.24.3 :/
<menn0> sinzui: I don't think we should release another 1.24 until this one is figured out
<sinzui> menn0: I think so, I really don't like releasing in this rush. I officially EODed lat hour
<sinzui> menn0: we can replace the proposed version with an other fixed version while in propsed. maybe 1.24.5 can be put in place by your tuesday
<menn0> sinzui: ok
<menn0> sinzui: this one should be fixed soon I think. i'm getting a sense of the problem from the logs
<sinzui> menn0: also, I will hit the delay in Lp's builders. If I see a fix in CI, I can just switch the debs we plan to put in streams :)
<menn0> sinzui: sounds good
<menn0> waigani: if you get a chance could you have a look at http://reviews.vapour.ws/r/2279/ pls? (no rush though)
<waigani> menn0: okay, I'm just finishing some stuff for Will. Probably get to it around 11am?
<menn0> waigani: np. i'm looking at this upgrade issue anyway.
<menn0> cherylj: I see the problem... the relevant revision is 0e39ac8d6fcc77793e5028e03bfb651707cf1bb6
<menn0> cherylj: if the env UUID is missing open() tries to query the DB to figure it out, but that's before the mongodb login happens in newState() so the query isn't allowed
<menn0> cherylj: I find it hard to believe that this was tested with an actual upgrade...
<menn0> cherylj: it should be fixable by extracting the login into it's own method
<menn0> and calling that earlier in open()
<sinzui> menn0: waigani Can either of you review http://reviews.vapour.ws/r/2283/
<menn0> sinzui: ship it
<menn0> sinzui: btw I'm pretty sure I have a fix for bug 1479931
<mup> Bug #1479931: Juju 1.22.6 cannot upgrade to 1.24.3/1.24.4 <blocker> <ci> <regression> <upgrade-juju> <juju-core:Triaged> <juju-core 1.24:Triaged> <https://launchpad.net/bugs/1479931>
<menn0> sinzui: testing now
<sinzui> menn0: Thank you . I may need to wait  though. Hp cloud got relested and a job failed, so I am retesting
<menn0> ok
<sinzui> menn0: ping when you want to merge because I might just as well release your fix
<menn0> sinzui: ok
<menn0> sinzui: ok that fix works... just prepping for proposing now
<sinzui> menn0: You rock, as does cherylj . I will let CI accept the current failure and wait for the fix
<menn0> waigani or anyone else, review for CI blocker please : http://reviews.vapour.ws/r/2284/
<waigani> menn0: looking
<menn0> waigani: never mind ... the change breaks the state unit tests
<menn0> sinzui: this is going to take longer
<waigani> menn0: okay
<axw> anastasiamac_: ok to delay 10m to wait for perrito666?
<sinzui> menn0: okay. I Hp hates me so I am in no rush
<anastasiamac_> axw: yes :D brilliant - m going to coffee
<anastasiamac_> axw: is ur school run going to b k?'
<menn0> sinzui: ok. I have to be out house for a bit soon so it might be a few more hours
<axw> anastasiamac_: should be fine
<anastasiamac_> axw: gr8! see u then :D
<menn0> sinzui: or perhaps someone else can run with it
<menn0> let's see where I get to
<menn0> waigani, sinzui: tests fixed
<menn0> waigani: pushing now
<menn0> waigani: can you take a look again please?
<waigani> menn0: yep
<menn0> waigani: I need to step away for a bit. if you're happy with the change can you pls hit merge for me?
<menn0> back in 10min
<waigani> menn0: yep np
<perrito666> anastasiamac_: axw I am back, thanks :D
<anastasiamac_> perrito666: axw: omw
<waigani> menn0: done, I hit merge also
<sinzui> menn0: waigani : the magic fixes-1479931 was missing, I am adding it and requeing the merge
<waigani> sinzui: ugh, sorry I keep forgetting that.
<menn0> waigani, sinzui: i'm back for 20 mins or so then off again
<sinzui> menn0: okay I will watch the merge and retry as needed
<waigani> menn0: half day for me, heading to airport in 30min.
<menn0> sinzui, waigani: thanks both of you
<waigani> :)
<mwhudson> davecheney: what's happened to the ppc64le builder?
#juju-dev 2015-07-31
<davecheney> mwhudson: /me looks
<davecheney> hmm, it was working fine up til last night
 * davecheney steps into phone box, enables vpn
<anastasiamac_> davecheney: i thought u were stepping into phone booth to change into ur super outfit...
<davecheney> anastasiamac_: it's the same thing
<davecheney> mwhudson: looks like the builder _is_ running
<mwhudson> davecheney: hm
<davecheney> i'll keep an eye on it
<davecheney> the proxy might have screwed up
<davecheney> and migth be throwing away the calls to the dashboard that report results
<mwhudson> yummy proxies
<davecheney> mwhudson: you saw the note about go 1.5 last night ?
<davecheney> i'd say it'll ship in august
<davecheney> well
<davecheney> before september :)
<mwhudson> davecheney: yeah
<davecheney> mwhudson: how much of a problem will that be ?
<mwhudson> don't know
<davecheney> should I be talking to tim and alexis now
<davecheney> and issuing dire warnings ?
<mwhudson> argh i've forgotten when feature freeze is
<davecheney> aug 20
<mwhudson> hmm
<davecheney> alpha 2 was yesterday
<mwhudson> i guess that's getting close
<mwhudson> davecheney: it might be worth getting alexis to talk to steve l about dates, yeah
<davecheney> i can see the timeline being an issue
<mwhudson> yeah, it's getting to 'uneasy' i think, a few notches below 'panic' or 'give up and start mowing lawns'
<davecheney> mwhudson: done
<davecheney> i've been here before and excessive planning and overcommunication is the path to success
<mwhudson> definitely
<mwhudson> talking of planning, i'll see about doing another rebuild test using real go for arm64 and ppc64le
<davecheney> mwhudson: what was that site you used that decoded instructions ?
<mwhudson> davecheney: https://www.onlinedisassembler.com/odaweb/
<mwhudson> davecheney: i like the new contender for most useless bug reporter ever
<mwhudson> (https://github.com/golang/go/issues/11957)
<natefinch> ahh the old "it doesn't work" bug
<natefinch> lol
<natefinch> insane amounts indeed
<mwhudson> perhaps not as quite as useless as the "can't bootstrap with gccgo" guy
<natefinch> It's amazing how even people who work in development can fail to post even the most basic information about a bug.  I can't tell you how often I've had to tell even the same people in an org inside my own company to include the damn logs when reporting a bug.  It's not rocket science.
<natefinch> Gah, people, if you're going to have a field which is a map[string]someStruct  ... you gotta explain WTF the string is
<davecheney> yup,
<natefinch> ...this is why I hate using maps for things which should probably just be slices... because the most important field in the whole struct *isn't in the struct*
<davecheney> natefinch: yup
<natefinch> lol @ omitempty on non-pointer struct fields
<axw> natefinch: why? omitempty works for non-pointer values
<natefinch> axw: for non-pointer struct values?  I was just seeing it not work
<axw> natefinch: http://play.golang.org/p/Q9C5yKHhqi
<natefinch> axw: I mean this: http://play.golang.org/p/rVw_82ZOl8
<axw> natefinch: ah, fields of struct type. gotcha.
<natefinch> right, sorry, didn't explain it well
<mwhudson> davecheney: i take it back, i think this might be the most clueless reporter ever
<alexisb> jam, thumper if you guys are watching your screens we could use you upstairs
<thumper> hey mgz
<thumper> mgz: the 1.24 branch didn't get blessed due to an intermittent failure on the i386 tests
<thumper> mgz: can you just run them again to check?
<thumper> mgz: failing that, we need someone to pick this up
<thumper> dimitern: can you please keep on top of this?
<thumper> it is super important
<dimitern> thumper, ok, will see what I can do
<thumper> dimitern: cheers
<dimitern> thumper, by "super important" I guess you won't mind skipping that test for i386 for the time being - it looks like a timeout issue
<thumper> dimitern: if it is obviously broken...
<thumper> then we should not run it
<thumper> I'm ok with skipping it on "i386" only if we can do that
<thumper> as long as we file a bug
<dimitern> thumper, yes we can :)
<thumper> hopefully this test will be rewritten as part of the uniter sprint upcoming
<dimitern> thumper, my point exactly, yeah
<thumper> dimitern: do it!
<katco> fwereade: how great is this, we already have james flagged as the "C" in RACI for min version
<dimitern> thumper, done - stamp it! http://reviews.vapour.ws/r/2286/
<thumper> dimitern: stamped
<thumper> later folks, lunch time here
<thumper> then we're done
<dimitern> thumper, thanks and enjoy :)
<thumper> hey dimitern
<thumper> dimitern: you have been volunteered to make sure 1.24 gets blessed :)
<thumper> we are all done here and people are stopping looking at laptops
<thumper> I'm hoping that it will all be good
<thumper> the only blocker would be another intermittent failure
<thumper> fingers crossed, we're good
<dimitern> thumper, oh is that right :)
<dimitern> thumper, I'll keep an eye on the builds and status
<thumper> but someone needs to hold the token :)
<thumper> if you hit EOD, make sure someone in the US gets the token
<dimitern> thumper, hopefully should be fine and I'd nudge it if needed
<thumper> sound good?
<dimitern> thumper, yes, wilco ;)
<thumper> awesome
<thumper> see y'all next week
<dimitern> safe travels!
 * thumper closes laptop
<mup> Bug #1480298 opened: unknown object type "Charms" <blocker> <ci> <compatibility> <regression> <juju-core:Triaged> <https://launchpad.net/bugs/1480298>
<TheMue> dimitern: in your review when I'm registering the watcher you mentioned a possible failure detection and watcher stopping. how to detect an error during registering? or did you mean when above the mapping returns an error?
<mup> Bug #1480310 opened: dbus link request failed for service FOO: Unit name FOO is not valid. <blocker> <ci> <systemd> <wily> <juju-core:Triaged> <systemd (Ubuntu):New> <https://launchpad.net/bugs/1480310>
<bhundven> https://github.com/juju/juju/blob/master/container/kvm/kvm.go#L158   -- This line does not print the constraints
<bhundven> machine-0: 2015-07-31 15:36:54 TRACE juju.container.kvm kvm.go:158 create the container, constraints:
<bhundven> I think it's because %+v outputs multiple lines?
<bhundven> er, %v
<perrito666> does it? what is the ouput you get there?
<bhundven> 08:43:32 <bhundven> machine-0: 2015-07-31 15:36:54 TRACE juju.container.kvm kvm.go:158 create the container, constraints:
<bhundven> the next line is the next log message, and the kvm container is being created with the default constraints
<bhundven> instead of the ones I passed.
<perrito666> duh, I am so used to another channel that I ignore all the lines next to links
<bhundven> I'm debugging the issue by doing: logger.Debugf("Params passing to container. Arch: %s : Memory: %d : Cores: %d : RootDisk: %d", startParams.Arch, startParams.Memory, startParams.CpuCores, startParams.RootDisk)
<bhundven> before it parses the hardware
<bhundven> https://bugs.launchpad.net/juju-core/+bug/1399613
<mup> Bug #1399613: juju-core not using constraints when creating KVM  unit on maas machine <constraints> <kvm> <maas-provider> <juju-core:Triaged> <https://launchpad.net/bugs/1399613>
<bhundven> I've tested the issue with 1.22 through current 1.25 alpha
<bhundven> http://paste.ubuntu.com/11974200/
<bhundven> juju machine add kvm:0 --constraints "cpu-cores=2 mem=2G root-disk=20G"
<bhundven> is what I'm passing
<cherylj> anyone want to help me in crafting an error message?  I think I'm over thinking things and trying to make things way too complicated.
<cherylj> it's for bug 1480298
<mup> Bug #1480298: unknown object type "Charms" <blocker> <ci> <compatibility> <regression> <juju-core:Triaged by cherylj> <https://launchpad.net/bugs/1480298>
<cherylj> basically, we're using a new juju client with an older version of juju
<cherylj> and we try to register the charm for metering, and can't since it's not supported in earlier versions of juju
<cherylj> What I have is: "current state server version does not support charm metering" as a warning, but don't return an error.
<cherylj> thoughts?
<cherylj> mattyw ^^  (if you're still around)
<mattyw> cherylj, hey hey
<bhundven> the maas provider doesn't call CreateContainer?
 * bhundven is stumped
<bhundven> ah, it uses instanceBroker
<mup> Bug #1479931 changed: Juju 1.22.6 cannot upgrade to 1.24.3/1.24.4 <blocker> <ci> <regression> <upgrade-juju> <juju-core:Fix Released by menno.smits> <juju-core 1.24:Fix Released by menno.smits> <https://launchpad.net/bugs/1479931>
<bhundven> Well, the instanceConfig passed to CreateMachine in containers/kvm/kvm.go doesn't contain the constraints.
<bhundven> http://paste.ubuntu.com/11975150/
<bhundven> http://paste.ubuntu.com/11975152/
<bhundven> iow, instanceConfig.Constraints doesn't exist
<sinzui> cherylj: ericsnow wwitzel3 : this befuddles me. I cannot find a dupe, but it looks familar. Is this a new bug? Do we need to fix this in 1.25? https://bugs.launchpad.net/juju-core/+bug/1478762
<mup> Bug #1478762: juju bootstrap failed to connect to environment  with error "discarding API open error"  <juju-core:New> <https://launchpad.net/bugs/1478762>
<ericsnow> sinzui: doesn't sound familiar
<lazyPower> natefinch-afk: status update on our convo - i have the branch built and living locally in a container. I'm looking at way to do this that would apply to any feature branches we want to track, and get those added as nightly builds, and yield a container that isnt 2gb - should have something for you by early next week say tuesdayish
<natefinch> lazyPower: cool
<natefinch> lazyPower: I think sinzui can point you to binaries created by the CI system that could easily be just copied wherever you need them.
<lazyPower> so our CI is already building/archiving branches?
<sinzui> lazyPower: Ci tests every revision, the binaries built are places in s3, and reports.vapourr.ws can list them for you
<sinzui> lazyPower: are you interested in 1.24.4 or 1.25-alpha1?
<lazyPower> sinzui: feature-proc-mgmt branch
<sinzui> lazyPower: http://reports.vapour.ws/releases lists that branch and the last build tested (2928)
<sinzui> lazyPower: http://reports.vapour.ws/releases/2928 has a link to binaries (faster than scanning the jobs)...http://reports.vapour.ws/releases/2928/binaries
<cherylj> sinzui: it looks familiar to me too.  I can try to find if there is a dup, or if we're both going crazy
<sinzui> cherylj: maybe I saw issues like this because of maas setup, and the bug was moved from juju-cire to maas?
<cherylj> sinzui: I see bug 1477920 which was marked as a dup of 1321212
<mup> Bug #1477920: juju bootstrap failed with "discarding API open error" <bootstrap> <cloud-installer> <maas-provider> <juju-core:New> <https://launchpad.net/bugs/1477920>
<cherylj> sinzui: but I thought that thumper had done some work around that to retry the connection while bringing up the bootstrap node...  hmmm
<cherylj> maybe I'm going crazy
<cherylj> cmars: could you take a look: http://reviews.vapour.ws/r/2287/
<bhundven> Well, I'm not sure what to do. It seems that this (https://code.launchpad.net/~thumper/juju-core/kvm-constraints/+merge/197815) was an attempt to fix constraints passing to kvm containers. Without being able to set constraints on the kvm I need to deploy, I can't move forward with my evaluation of juju. I've tried to figure it out on my own. \o/
 * bhundven stops talking to rocks...
 * perrito666 decides to test a worker with unittests and see if someone gets mad
#juju-dev 2015-08-01
<mup> Bug #1480616 opened: juju with RackSpace configuration <juju-core:New> <https://launchpad.net/bugs/1480616>
#juju-dev 2016-08-01
<thumper> oh poo
<thumper> wanting to add something to a worker manifold, but it just defines itself as a copy of engine.AgentApiManifoldConfig
 * thumper sighs
 * thumper unpicks
<thumper> perhaps after a dog walk
<mup> Bug #1271744 changed: bootstrap on maas with --metadata-source fails <bootstrap> <maas> <maas-provider> <simplestreams> <upload-tools> <juju-core:Triaged by anastasia-macmood> <https://launchpad.net/bugs/1271744>
<mup> Bug #1567763 changed: bootstrapping private openstack, with --metadata-source fails when instance-type constraint is specified <bootstrap> <constraints> <simplestreams> <juju-core:In Progress by anastasia-macmood> <juju-core 1.25:Triaged> <https://launchpad.net/bugs/1567763>
<thumper> bugger
<thumper> clean up a test and now it fails
 * thumper reverts
<menn0> axw: the more I think about it, the more I think your approach for those flaky MachineSuite tests is the right thing to do for now
<menn0> axw: i'll give it a try soon
<axw> menn0: cool
<thumper> fark
<menn0> thumper: http://reviews.vapour.ws/r/5342/
<mup> Bug #1588115 changed: json: cannot unmarshal string into Go value of type nova.jsonEntity <bootstrap> <juju> <juju-core:Expired> <https://launchpad.net/bugs/1588115>
<menn0> thumper: http://reviews.vapour.ws/r/5343/
<rogpeppe> axw: ping
<axw> rogpeppe: pong
<rogpeppe> axw: yo!
<axw> howdy
<rogpeppe> axw: is it a bug or a feature that credentials can't be updated or deleted?
<axw> rogpeppe: bug
<rogpeppe> axw: ok, thought so, just checking
<axw> rogpeppe: working on the foundations of updating them still
<rogpeppe> axw: (if you try to update an existing credential, you get a "state changing too quickly" error)
<rogpeppe> axw: (not the most informative error in the world :] )
<axw> rogpeppe: oh, well that's a different type of bug :)   I just meant that we don't react to changes at the moment
<axw> I guess we're assuming they don't exist at the moment
<rogpeppe> axw: yeah, so there's no way for us to change them
<rogpeppe> axw: i was wondering if immutability was by design
<rogpeppe> axw: but it seems not :)
<rogpeppe> axw: i think it should make an update txn if the doc already exists
<axw> rogpeppe: yep. not set in stone, but at the moment we don't assume immutability. there's no documented workflows for updating creds, but I don't see any problem with updating existing ones
<rogpeppe> axw: i think that perhaps it's a mistake for the transaction Run method to *always* return "state changing too quickly" if the transaction fails
<rogpeppe> axw: whether that's appropriate surely depends on whether the transaction is designed to work in all cases
<axw> rogpeppe: it should always be valid, except if the transaction asserts are wrong?
<axw> (which seems to be the case here)
<rogpeppe> axw: well, there might well be operations which are designed to fail in certain cases (for example, a Remove operation might fail because the doc doesn't exist)
<rogpeppe> axw: or it might well be legitimate to have an operation that is supposed to fail if the doc already exists (insert vs update)
<axw> rogpeppe: sure, but you check that at the top of the transaction loop. if it doesn't exist, you return errors.NotExistsf. otherwise you assume it's there, but add an assert; the failure causes the loop to restart
<axw> you only get the "state changing too quickly" error if what you're chekcing at the top of the loop doesn't match what's in the assert, or if it really is happening too quickly
<axw> changing*
<rogpeppe> axw: that implies even more unnecessary round trips
<rogpeppe> axw: but i guess that's par for the course
<axw> rogpeppe: you don't *have* to use the transaction loop
<axw> rogpeppe: this error only occurs when you do
<rogpeppe> axw: you don't have to use the transaction loop? i thought that was the only way to run transactions these days.
<axw> rogpeppe: state.State.runTransaction doesn't use a loop
<axw> rogpeppe: state.State.run does
<rogpeppe> axw: ah, i didn't know about runTransaction or the distinction between that and run
<rogpeppe> axw: not great naming tbh - i think that Run should probably be named something that implies it will loop
<axw> rogpeppe: agreed on that
<rogpeppe> axw: just reported these bugs:
<rogpeppe> axw: https://bugs.launchpad.net/juju-core/+bug/1608421
<mup> Bug #1608421: UpdateCloudCredentials should be able to change existing credential <juju-core:New> <https://launchpad.net/bugs/1608421>
<rogpeppe> axw: https://bugs.launchpad.net/juju-core/+bug/1608422
<mup> Bug #1608422: it is not possible to remove cloud credentials <juju-core:New> <https://launchpad.net/bugs/1608422>
<axw> rogpeppe: thanks
<rogpeppe> axw: you're planning to fix these, right? (if not, we can probably do some work on it)
<axw> rogpeppe: eventually yes, but I don't know when I will get to them
<rogpeppe> axw: ok
<mup> Bug #1608421 opened: UpdateCloudCredentials should be able to change existing credential <juju-core:New> <https://launchpad.net/bugs/1608421>
<mup> Bug #1608422 opened: it is not possible to remove cloud credentials <juju-core:New> <https://launchpad.net/bugs/1608422>
<mup> Bug #1608421 changed: UpdateCloudCredentials should be able to change existing credential <juju-core:New> <https://launchpad.net/bugs/1608421>
<mup> Bug #1608422 changed: it is not possible to remove cloud credentials <juju-core:New> <https://launchpad.net/bugs/1608422>
<mup> Bug #1608421 opened: UpdateCloudCredentials should be able to change existing credential <juju-core:New> <https://launchpad.net/bugs/1608421>
<mup> Bug #1608422 opened: it is not possible to remove cloud credentials <juju-core:New> <https://launchpad.net/bugs/1608422>
<rogpeppe> axw: is it my imagination, or are there no tests at all for the State.UpdateCloudCredentials method?
<axw> rogpeppe: indeed, that one slipped through
<rogpeppe> axw: i'm doing a coverage test on state now :)
<fwereade> huh, irc wasn't open
<fwereade> anastasiamac, can we chat about supported architectures?
<anastasiamac> fwereade: yes we can :)
<fwereade> anastasiamac, tell me if I get any of the following statements wrong
<anastasiamac> fwereade: k
<rogpeppe> axw: as a followup to the UpdateCloudCredentials thing, there are a few other methods that could do with tests in state... https://bugs.launchpad.net/juju-core/+bug/1608494
<mup> Bug #1608494: state: not all public methods are tested <juju-core:New> <https://launchpad.net/bugs/1608494>
<fwereade> anastasiamac, *in general*, bootstrapping with local image metadata will cause the image metadata to be uploaded and put in the database and made accessible to all environ instances created on the controller
<anastasiamac> fwereade: right (when database is present and we have a connection to it)
<fwereade> anastasiamac, there is a window of badness that affects *only* the environ instance that's actually bootstrapping the controller
<anastasiamac> fwereade: kind of... i have a gut feeling that the "window of badness" has a flow on affect. If it's fixed the flow-on effect *may* be fixed too
<fwereade> anastasiamac, that problematic environ instance is running on the same machine as the one that got the image metadata in the first place
<fwereade> anastasiamac, (I'm pretty sure that agents won't get env config except via an api conn? or at least via the database)
<anastasiamac> fwereade: i *think* it maybe that environ instance *has access* to the machine that has image metadata
<anastasiamac> fwereade: well, metadata has several data soureces - database is one of thethem and we hope is the main one - but ther are also url and file data sources..
<fwereade> anastasiamac, I don't understand the follow-on effect
<fwereade> anastasiamac, well, sure, but I don't think we need to care what the data sources are -- we just need to care that they *match*
<anastasiamac> fwereade: so I ahve seen bugs where private clouds (or no intrnet env) can bootstrap using --metadtaa-url (= web served data) not metadata source (= file locations)
<anastasiamac> fwereade: but had troubles deploying workload
<anastasiamac> fwereade: right about the match
<anastasiamac> fwereade: so form what i've seen, the "badness" occurs before stat is open where we select tools and get custom metadata from locally accessible location
<anastasiamac> fwereade: we detemrine supported architectures from declared data sources (which we have not declared yet) and are ignoring bootstrap custom metadata
<fwereade> anastasiamac, so, the local stuff is not a properly configured data source for the environ? shouldn't it be?
<anastasiamac> fwereade: when we get it, we do not have environ yet
<anastasiamac> fwereade: we pass it into startinstance as params
<fwereade> anastasiamac, all the more reason to create the environ knowing what data source it should use
<anastasiamac> fwereade: data source is created
<anastasiamac> fwereade: but data source is just the location to look at
<anastasiamac> fwereade: what we need here is a collection of actual values
<anastasiamac> fwereade: since we do not have anywhere to put them et. we can only pass them around
<anastasiamac> fwereade: i *think* :)
<fwereade> anastasiamac, the data source is an abstraction allowing us to get those values, isn't it?
<fwereade> anastasiamac, how does an environ know SupportedArchitectures if not by looking at what some datasource provides?
<anastasiamac> fwereade: yes, and as soon as we get a chance we put them in db :)
<anastasiamac> fwereade: suppoted architectures does not look i db at this stage anyway.. it's somethign that needs to happen but has not yet
<anastasiamac> fwereade: putting this custom metadata into db will not help
<fwereade> anastasiamac, well, the provider should pretty much never be looking in the db, tbh
<fwereade> anastasiamac, I'm not suggesting we should
<anastasiamac> fwereade: becasue we only obtain it and use it before db is started
<fwereade> anastasiamac, right
<anastasiamac> fwereade: \o/
<fwereade> anastasiamac, I'm saying that the environ we use to bootstrap is misconfigured if it's using a different data source to the one specified
<fwereade> anastasiamac, (and that a local source needs to be uploaded and put in the db to be accessible later, but it sounds like that all works correctly anyway)
<anastasiamac> fwereade:db upload works exactly as expected :)
<anastasiamac> fwereade: peerfectly :)
<fwereade> anastasiamac, (and also cautioning you against imagining that an environ ever "should" look in the db, that may be the ultimate source of the data but db concerns belong nowhere near environs)
<fwereade> anastasiamac, cool
<fwereade> anastasiamac, I'm sorta implicitly dismissing the follow-on concerns then
<anastasiamac> fwereade: even better for me then :)
<fwereade> anastasiamac, I can see an easy way to bootstrap and not be able to deploy, if you use a metadata url that's accessible to the client but not the controller
<fwereade> anastasiamac, and that is sorta a Don't Do That Then situation
<fwereade> anastasiamac, and it sounds like the upload of local metadata is also fine, so managing to bootstrap should imply we can deploy anything covered by that local metadata
<fwereade> anastasiamac, remind me how data sources *are* associated with an environ?
<mup> Bug #1608494 opened: state: not all public methods are tested <juju-core:New> <https://launchpad.net/bugs/1608494>
<anastasiamac> fwereade: this specific fix does not deal with URL served metadata - this works. Metadat-source is a file location
<anastasiamac> fwereade: metadata-url vs metadata-source
<fwereade> anastasiamac, yeah -- and it really seems like there's *one* environ, that we're trying to bootstrap, which will fail if it doesn't have proper access to the local metadata
<fwereade> anastasiamac, am I missing something? or am I pointing at the central problem
<anastasiamac> fwereade: right. of course with my changes, i managed to bootstrap :)
<rick_h_> morning
<mup> Bug #1608527 opened: lxd bootstrap now slow, timing out, fails <canonical-is> <juju-core:New> <https://launchpad.net/bugs/1608527>
<mup> Bug #1608527 changed: lxd bootstrap now slow, timing out, fails <canonical-is> <juju-core:New> <https://launchpad.net/bugs/1608527>
<mup> Bug #1608528 opened: machineSuite.TestShortPollIntervalWhenNoStatus timing problem: expect 2, obtained 2 <ci> <intermittent-failure> <regression> <unit-tests> <juju-core:Triaged> <https://launchpad.net/bugs/1608528>
<mup> Bug #1608529 opened: suprious 'd' in log output during lxd bootstrap <juju-core:New> <https://launchpad.net/bugs/1608529>
<mup> Bug #1608533 opened: Race in github.com/juju/juju/apiserver/tools_test <ci> <race-condition> <regression> <unit-tests> <juju-core:Triaged> <https://launchpad.net/bugs/1608533>
<perrito666> will be back later
<natefinch> ug, taxes on part of my property went up by 54% since last year :/  Luckily, it's the smaller of the two parcels, but it still means over $200 a month extra I'm paying... except that it's doubled by my mortgage company this year to put extra in escrow :/
<mup> Bug #1608597 opened: CalledProcessError for juju-2.0 deploy -m slaveX:default deployment_file <juju-core:New> <https://launchpad.net/bugs/1608597>
<mup> Bug #1608597 changed: CalledProcessError for juju-2.0 deploy -m slaveX:default deployment_file <juju-core:New> <https://launchpad.net/bugs/1608597>
<mup> Bug #1608597 opened: CalledProcessError for juju-2.0 deploy -m slaveX:default deployment_file <juju-core:New> <https://launchpad.net/bugs/1608597>
<perrito666> natefinch: I understood very little of that
<perrito666> you can move to argentina, 200 dollars is about 1/3 of my yearly tax
<natefinch> perrito666: the property that my house is on is in two towns... one of the towns decided that the piece of land I own in their town is worth twice as much this year as was worth last year.
<perrito666> ah, I see, we have a much more strict definition of town
 * rick_h_ goes for lunchables
<natefinch> rick_h_: you should really find something less processed than lunchables. Those things are terrible.
<rick_h_> natefinch: just my way of saying 'food for lunch'
<rick_h_> leftover blue apron meal today
<natefinch> rick_h_: I know, just giving you a hard time :)
<natefinch> rick_h_: I had leftover thai food :)
<perrito666> I had .... too hard to translate, dry tomatoes, some greens, mozzarela and ham on ciabatta with a flavoured cream :p
<perrito666> lunch caught me off my house, otherwise it would be way less pretentious
<natefinch> perrito666: sounds tasty
<natefinch> also, verdict on the taxes: evidently the town did a review, and realized they'd been taxing us at the residential rate, but that piece of land is in a commercial zone, which is a lot more expensive.  sigh.
<alexisb> natefinch, 54% is crazy in one year
<alexisb> I would have something to say about that
<natefinch> alexisb: well, the land *is* in a commercial zone, I knew that when we moved in.  So, basically we've been getting a 33% discount for the last 6 years :/
<hatch> when attempting to build Juju from master it is hanging on cmd/jujud has anyone ever run into this before?
<natefinch> hatch: nope.
<natefinch> hatch: when's the last time you did a successful build?
<hatch> natefinch: on this machine, never
<hatch> fresh install
<natefinch> hatch: hm.. suspicious
<hatch> Go 1.6.3
<natefinch> hatch: are you using the makefile or running go install manually?
<hatch> I was running `go install -v ./...`
<natefinch> *nod* did you run godeps first?
<hatch> yep
<natefinch> I got nuthin.
<hatch> maybe Juju doesn't build with 1.6.3?
<natefinch> I can try it locally.... I was using 1.6.2, can try 1.6.3 easy enough
<hatch> I've just deleted everything and it's rebuilding
<hatch> will see if it hangs
<hatch> yup hung again on jujud
<hatch> I'll try downgrading to 1.6.2
<hatch> natefinch: fwiw 1.6.2 also hangs
<rick_h_> natefinch: ping for meeting
<natefinch> rick_h_: oops, thanks, coming
<natefinch> hatch: building now... probably something weird with the machine you're building with
<hatch> natefinch: yeah, I am just not sure how I go about debugging it as there isn't any output
<hatch> natefinch: go build also hangs
<hatch> as expected I suppose
 * rick_h_ goes to get boy from camp biab
<rick_h_> katco: can you add some step by step QA docs to https://github.com/juju/juju/pull/5906 please and once there natefinch can you please look at and review and validate QA please?
<natefinch> rick_h_: sure thing
<katco> rick_h_: pointer to step-by-step instructions are in the review's "testing" section
<rick_h_> katco: ah, sorry. I got an email on the PR but didn't see anything to the RB
<rick_h_> natefinch: also please mark https://bugs.launchpad.net/juju-core/+bug/1604474 fix comitted
<mup> Bug #1604474: Juju 2.0-beta12  userdata execution fails on Windows <azure-provider> <ci> <juju2.0> <oil> <oil-2.0> <regression> <windows> <juju-core:In Progress by natefinch> <https://launchpad.net/bugs/1604474>
<natefinch> rick_h_: done
<rick_h_> ty
<rick_h_> katco: while your branch is up for review can you peek at https://canonical.leankit.com/Boards/View/122969419/123586962 please?
<rick_h_> katco: looks like it just didn't get landed due to conflicts that maybe you could resolve/get it landed?
<rick_h_> katco: as a quick win for the b14
<katco> rick_h_: it looks like it doesn't have a ship it
<rick_h_> katco: oh nvm, reviews say needs lots of love. More than just conflicts.
 * rick_h_ follows bug to pr to RB to ... :)
<katco> hehe
<natefinch> man, the github CLI helper, hub, really makes testing other people's branches easy.  I can just hub checkout https://github.com/juju/juju/pull/5906  and run the code from a PR.
<rick_h_> natefinch: <3 if you find a good pattern write it up please. I was using my old tricks from before with custom git aliases
<rick_h_> natefinch: making it easier/faster to qa-prs is <3
<rick_h_> natefinch: https://github.com/juju/docs/blob/adc36a78430d84f5c6ab05b271eb3b700768ba40/README.md#using-git-aliases is what we used to use
<natefinch> katco, rick_h_: ran out of time to test that PR.  I have it all deployed.. but hit a weird situation while removing and re-adding.  Will continue looking at it after the kids are in bed
<mup> Bug #1608677 opened: Remove filesystem cache for charm archives <juju-core:New> <https://launchpad.net/bugs/1608677>
<rick_h_> natefinch-afk: ty, have a good evening
<bdx> hey whats up guys?
<bdx> I'm having some issues with network spaces on aws ... I guess I'll write the list ... thought I would check here first
<bdx> I have successfully bootstrapped into my aws vpc using `juju bootstrap mycloud aws --credential mycred --config vpc-id=my-vpcid --config force-vpc-id='true' --upload-tools`
<bdx> and subsequently created a model on my aws controller in the vpc with `juju add-model my-new-model -credential mycred --config vpc-id=my-vpcid --config force-vpc-id='true'`
<bdx> following which, I add a network space, and then my subnet
<bdx> http://paste.ubuntu.com/21814798/
<bdx> ok, everything looks great so far .... then I go and launch an instance and it all falls apart -> http://paste.ubuntu.com/21815678/
<bdx> any ideas?
<bdx> sent to the list
<mup> Bug #1608723 opened: "juju test" command needs updating for juju 2.0 <juju-core:New> <https://launchpad.net/bugs/1608723>
<menn0> thumper: o/ http://reviews.vapour.ws/r/5346/
<menn0> this makes that flaky MachineSuite test fail reliably as well as cleaning up a bunch of other stuff
 * thumper looks
<thumper> shipit
<rick_h_> bdx: can you confirm the rest of the story there? Did the bootstrap instance start on the right vpc you asked it to?
<rick_h_> bdx: from the list it seems like you asked it to do the right thing, but I'm curious if juju did all the right things with the vpc for the controller, machines for the units deployed, etc.
<perrito666> thumper: point me to your review
<perrito666> thumper: the liiiiiiink
<thumper> http://reviews.vapour.ws/r/5345/
#juju-dev 2016-08-02
<rick_h_> menn0: ping, re: #1597601 this is in the process of a deploy, why can't we just catch that clear message and retry for a bit?
<mup> Bug #1597601: ERROR cannot deploy bundle: cannot deploy application: i/o timeout <2.0> <bundles> <deploy> <oil> <oil-2.0> <repeatability> <retry> <juju-core:Triaged by menno.smits> <https://launchpad.net/bugs/1597601>
<rick_h_> menn0: it's not clear why the user can retry when it's in our control from a bundle deployment (blocking operation atm) and know the issue? but they can?
<perrito666> thumper: k reviewing
<perrito666> thumper: I have a few comments
<thumper> perrito666: ok
<perrito666> dont hate me
<perrito666> blame the checklist
<perrito666> k ppl, dinner, bbl
<menn0> rick_h_: it goes deeper than that
<menn0> rick_h_: this error can happen at any time... not just during deploy
<menn0> rick_h_: when mongodb does a leader election, it drops all it's connections and all our workers die
<menn0> rick_h_: if an api request comes in just as the mongodb conns go down the i/o timeout happens
<menn0> rick_h_: the apiserver gets taken down so we can't retry internally
<menn0> rick_h_: changing that requires some pretty fundamental changes to the way our workers are arranged and how state.State works
<menn0> I don't think we can get that done before 2.0
<menn0> rick_h_: oh I see what you're saying... I guess I wasn't clear enough
<menn0> rick_h_: the "please retry" error would come from the apiserver and be handled by the client. the end user wouldn't have to do anything.
<menn0> updating the ticket
<axw> menn0: in case you were planning to change any other workers to depend on environ-tracker, I'm updating storage-provisioner to do that now
<axw> menn0: (related to my ongoing work)
<menn0> axw: ok cool. I wasn't planning on doing that one but makes sense to do it while we're thinking about it
<menn0> axw: that will mean that the minimal provider we inject in this other test will probably need to implement a little more, but I guess that won't be too ahrd
<menn0> hard
<axw> menn0: as long as it has a "Config()" method, it'll be fine for the storage provisioner
<menn0> axw: that's fine then, as long as the config it has to return isn't too onerous
<axw> menn0: AFAICR, it won't need anything at all
<axw> I mean, just a base config
<axw> I'll make sure of that before I land
<menn0> axw: sounds great then.
<menn0> axw: I'm working on the provisioner changes right now
 * menn0 wants this done
<axw> :)
<perrito666> Wallyworld tx for the review
<bdx> rick_h_: yea, I still can't seem to get the instance to deploy ....
<bdx> rick_h_: or any instance for that matter
<bdx> rick_h_: yea, the bootstrap instance deployed to the vpc I specified
<natefinch> Hey, just realized I hit my 3 year anniversary
<natefinch> (at canonical)
<anastasiamac> natefinch: congrats? :)
<perrito666> natefinch: sweet, congrats
<perrito666> by all going to sleep
<anastasiamac> perrito666: nite nite
<natefinch> see ya
<menn0> thumper: permission to JFDI this? (test only change) https://github.com/juju/juju/pull/5908
<menn0> perrito666: good night
 * thumper looks at menn0's patch
<thumper> menn0: ack
<menn0> thumper: thanks
<thumper> menn0: http://reviews.vapour.ws/r/5349/
<thumper> menn0: and http://reviews.vapour.ws/r/5350/
<thumper> menn0: when those two have landed I have a juju branch
<thumper> that needs these changes to make it work with the new loggo
<thumper> 27 files changed in juju
<menn0> thumper: ok, will look soon. just pushing my next thing.
<thumper> menn0: np
<thumper> ok... starting a stab at filesystem migration now
<thumper> when I lose the will on that I may attack an intermittent failure
<menn0> haha
<menn0> axw: here's the provisioner change: http://reviews.vapour.ws/r/5351/
<axw> menn0: thanks, will look shortly. if you have time, I've got the storage provisioner one up here: http://reviews.vapour.ws/r/5348/
<menn0> axw: will do
<natefinch> thumper: how much do you know about github.com/juju/schema?
<natefinch> (or anyone else for that matter).  Mostly wonder if anyone will kick and scream if I unmangle the API very slightly.
<natefinch> schema and environschema suffer from "I wish this was python" syndrome
<menn0> thumper: reviews done
<thumper> menn0: ta
<thumper> natefinch: a reasonable amount
<thumper> natefinch: why?
<menn0> axw: just an FYI but I'm pretty sure QA steps are supposed to be detailed step by step instructions
<menn0> axw: alexis has pulled me up on that recently
<menn0> axw: don't worry about it for this one
<axw> menn0: okey dokey, thanks
<natefinch> thumper: so, the Coerce method on the checker returned by FieldMap uses a lot of reflection to avoid just casting the interface to map[string]interface..... the end result really just being that it effectively works with any key that is a string or has a String() method
<natefinch> thumper: AFAIK, core code always passes in map[string]interface{} .... would it be kosher to strip out the reflection and just cast to map[string]interface{} inside fieldMap's coerce?
<thumper> I don't know of other users
<thumper> but it shouldn't hurt juju
<thumper> but my question is why?
<thumper> what are you doing to schema that got you looking there?
<natefinch> thumper: it would make the code a lot simpler
<thumper> I'm just thinking priorities
<thumper> that's all
<natefinch> thumper: I'm adding the concept of dependencies between attributes in a field map.  So, like, A should only be set if B is set to value XXX.
<thumper> ah...
<natefinch> thumper: this is to support add-cloud using the environschema to generate the add-cloud interactive prompts
<thumper> is this mostly in environschema?
<thumper> or the schema package itself?
<thumper> but to go back to the original...
<natefinch> thumper: the two are pretty intertwined... but the dependency stuff needs to be in schema
<thumper> I'm pretty sure that juju doesn't passing "Stringer"s into the schema checking
<thumper> pretty sure, as you said, that it all goes through map[string]interface{}
<natefinch> thumper: it's not really important.  I don't want to break anyone... just struck me as making the code obtuse for no reason.
<menn0> axw: review done
<axw> menn0: thanks, yours too if you didn't see. I didn't get the name references sadly, so can't follow ;p
<axw> something about Cats I think?
<menn0> axw: thanks for your review. your suggestion is spot on. I'll add a TODO.
<natefinch> brb
<menn0> axw: I have NFI either. Just noted the high brow sounding names :)
<axw> hehe
<menn0> axw: looks like cats :)
<thumper> menn0: last one
<thumper> http://reviews.vapour.ws/r/5353/
 * menn0 looks
<mup> Bug #1325968 changed: juju 1.18.3 - MAAS Node - cannot execute binary file: Exec format error  <arm64> <bootstrap> <jujud> <maas-provider> <juju-core:Expired> <https://launchpad.net/bugs/1325968>
<menn0> axw: here's the final PR for the TestHostedModelWorkers problem: http://reviews.vapour.ws/r/5354/
<axw> menn0: cool, looking
<axw> menn0: LGTM, thanks
<anastasiamac> rick_h_: dimitern: before going, James put a fix for bug 1602054. PR is linked to the bug. Would be awesome to get into next release \o/ it was highlighted in sts call last week
<mup> Bug #1602054: juju deployed lxd containers are missing a default gateway when configured with multiple interfaces <2.0> <network> <regression> <juju-core:In Progress by dooferlad> <https://launchpad.net/bugs/1602054>
<dimitern> anastasiamac: ok, I'll have a look
<mup> Bug #1608818 opened: Default storage pools are not registered for hosted models <juju-core:In Progress by axwalk> <https://launchpad.net/bugs/1608818>
<mup> Bug #1608821 opened: "juju storage-pools --provider=..." does not work correctly <juju-core:In Progress by axwalk> <https://launchpad.net/bugs/1608821>
<mup> Bug #1608818 changed: Default storage pools are not registered for hosted models <juju-core:In Progress by axwalk> <https://launchpad.net/bugs/1608818>
<mup> Bug #1608821 changed: "juju storage-pools --provider=..." does not work correctly <juju-core:In Progress by axwalk> <https://launchpad.net/bugs/1608821>
<mup> Bug #1608818 opened: Default storage pools are not registered for hosted models <juju-core:In Progress by axwalk> <https://launchpad.net/bugs/1608818>
<mup> Bug #1608821 opened: "juju storage-pools --provider=..." does not work correctly <juju-core:In Progress by axwalk> <https://launchpad.net/bugs/1608821>
<anastasiamac> dimitern: tyvm \o/
<dimitern> reviewboard seems to be having issues - or it's just for me?
<dimitern> can anybody open http://reviews.vapour.ws/r/5333/ for example?
<dimitern> ah, it's back now
<dimitern> :/ gone again
<dimitern> macgreagoir: hey, are you around?
<dimitern> should've checked the cal
<rogpeppe> axw: just FYI, following up from yesterday, i reported https://bugs.launchpad.net/juju-core/+bug/1608494
<mup> Bug #1608494: state: not all public methods are tested <juju-core:New> <https://launchpad.net/bugs/1608494>
<axw> rogpeppe: ok, thanks
<rogpeppe> axw: there are others which seem to have test coverage only coincidentally (no dedicated tests), e.g. State.Cloud (tested only because NewModel calls it)
<rogpeppe> axw: i'm just fixing UpdateCloudCredentials now and writing a test for it
<axw> rogpeppe: great, thank you
<rogpeppe> axw: currently trying to work out how to create a named cloud
<axw> rogpeppe: to bootstrap with?
<rogpeppe> axw: so that i can have a valid cloud name to pass to UpdateCloudCredentials
<rogpeppe> axw: for the test
<axw> rogpeppe: for now you cannot add clouds, you can only refer to the cloud you bootstrapped with. in all the state tests (I think all?) that's "dummy"
<rogpeppe> axw: ah, ok, cool
<rogpeppe> axw: hmm, so the dummy provider has no attributes in its cloud credentials, and there seems to straightforward way to make more clouds
<rogpeppe> axw: so i think it's not going to be easy to test the UpdateCloudCredentials logic
<rogpeppe> s/to straightforward/no straightforward/
<rogpeppe> axw: i guess i could write a new dummy provider and redo something like ConnSuite from scratch, but that seems... quite a bit of work
<axw> rogpeppe: I don't think you need to write a new provider, just initialize state with a different cloud definition
<rogpeppe> axw: ok, but ConnSuite has already initialized the state
<axw> rogpeppe: yeah, you would have to not use ConnSuite
<axw> rogpeppe: or... maybe change ConnSuite so that you can parameterise the cloud def
<rogpeppe> axw: yeah, not sure which way's best
<axw> rogpeppe: i.e. override before SetUpSuite
<axw> or SetUpTest or whatever
<axw> that's probably the least amount of work
<rogpeppe> axw: i guess i'd need a separate test suite for every cloud variation then
<rogpeppe> axw: or... i guess i could call SetUpTest inside each test directly
<axw> rogpeppe: ew, but yeah :)
<rogpeppe> axw: or provide some more modular functionality inside state/testing, i suppose
<rogpeppe> axw: or provide the capability to add more clouds
<axw> rogpeppe: it's probably fine to do that TBH, it's not going to harm anything
<axw> rogpeppe: and it's going to happen sooner or later
<axw> so if it's easy...
<rogpeppe> axw: :)
<rogpeppe> axw: this is all unbudgeted-for stuff
<axw> rogpeppe: gtg, thanks for fixing it up - I'm still neck high in config stuff
<rogpeppe> axw: np
<rogpeppe> axw: have fun!
<dimitern> reviews on http://reviews.vapour.ws/r/5356/ will be much appreciated!
<babbageclunk> dimitern: I'll trade you! ;) Take a look at these ones? http://reviews.vapour.ws/r/5312/ http://reviews.vapour.ws/r/5317/
<dimitern> babbageclunk: sure ;) looking
<rogpeppe> anyone familiar with the new cloud stuff? named clouds and that sort of thing?
<rogpeppe> axw: i'm presuming you're done for the day...
<balloons> anastasiamac, are you going to schedule something this week to talk about the bootstrap acceptance criteria?
<babbageclunk> dimitern: Reviewed, a couple of minor things.
<dimitern> babbageclunk: cheers! still looking at yours I'm afraid
<anastasiamac> oh balloons: I'd love to :D r u available? any pref days/times?
<balloons> anastasiamac, it is easy for me to meet about this time. Does tomorrow work?
<anastasiamac> balloons: i'll add it to calendar! tyvm :)
<anastasiamac> balloons: bootsrap? there is add cloud.. not botstrap done :)
<balloons> anastasiamac, is your github PR all up to date?
<balloons> ahh right.. add-cloud: https://github.com/anastasiamac/juju/blob/acceptance-add-cloud/acceptance/cloud/add_cloud.feature
<rick_h_> morning
<dimitern> babbageclunk: thanks for fixing the vsphere issue btw - LGTM
<anastasiamac> balloons: yes
<anastasiamac> balloons: at least for now an as far as I got with everyone sprinting... it needs more discussions but i believe it's at the next logical step and can be useful for u to kick things off on ur side :P
<mup> Bug #1571593 changed: lxd bootstrap fails with unhelpful 'invalid config: no addresses match' <juju-release-support> <lxd-provider> <usability> <juju-core:Triaged> <https://launchpad.net/bugs/1571593>
<axw> rogpeppe: yes EOD. going away again :)
<rogpeppe> axw: np :)
<rogpeppe> axw: just wondering if clouds should be immutable
<mup> Bug #1443942 changed: SNAT for externally routed traffic should be only for EC2 and for subnets in the VPC <bug-squad> <ec2-provider> <network> <tech-debt> <juju-core:Won't Fix> <https://launchpad.net/bugs/1443942>
<mup> Bug #1540832 changed: Hard wired bridge prevents the use of the fan overlay network <network> <juju-core:Triaged> <https://launchpad.net/bugs/1540832>
<mup> Bug #1608723 changed: "juju test" command needs updating for juju 2.0 <juju-core:Invalid> <https://launchpad.net/bugs/1608723>
<mup> Bug #1535891 opened: Feature request: Custom/user definable cloud-init user-data <juju-core:Triaged> <https://launchpad.net/bugs/1535891>
<dimitern> babbageclunk: updated http://reviews.vapour.ws/r/5356/ can you have a second look please?
<babbageclunk> dimitern: yup, looking now
<dimitern> babbageclunk: ta!
<dimitern> babbageclunk: and if you can also have a look at https://github.com/juju/juju/pull/5871 at some point will be awesome! :)
<mup> Bug #1608723 opened: "juju test" command needs updating for juju 2.0 <juju-core:New> <https://launchpad.net/bugs/1608723>
<mup> Bug #1608938 opened: clientSuite.SetUpTest mongo could not create index <ci> <intermittent-failure> <mongodb> <regression> <unit-tests> <juju-core:Triaged> <https://launchpad.net/bugs/1608938>
<mup> Bug #1608942 opened: UpgradeCharmSuccessSuite.SetUpTest cannot set admin password <ci> <intermittent-failure> <mongodb> <regression> <unit-tests> <juju-core:Triaged> <https://launchpad.net/bugs/1608942>
<babbageclunk> dimitern: looking at 5871 now - why no RB for it?
<dimitern> babbageclunk: dunno - perhaps due to formatting of the description the RB bot didn't pick it up ..
<mup> Bug #1608947 opened: MSpan_Sweep: bad span state after sweep in github.com/juju/juju/api/provisioner <ci> <go1.6> <intermittent-failure> <regression> <unit-tests> <juju-core:Triaged> <https://launchpad.net/bugs/1608947>
<mup> Bug #1608947 changed: MSpan_Sweep: bad span state after sweep in github.com/juju/juju/api/provisioner <ci> <go1.6> <intermittent-failure> <regression> <unit-tests> <juju-core:Triaged> <https://launchpad.net/bugs/1608947>
<mup> Bug #1608947 opened: MSpan_Sweep: bad span state after sweep in github.com/juju/juju/api/provisioner <ci> <go1.6> <intermittent-failure> <regression> <unit-tests> <juju-core:Triaged> <https://launchpad.net/bugs/1608947>
<mup> Bug #1608952 opened: Deployer: KeyError: 'uuid' connecting to environment <ci> <deployer> <regression> <juju-core:Triaged> <juju-deployer:New> <https://launchpad.net/bugs/1608952>
<mup> Bug #1608956 opened: local charms can be deleted while still referenced <juju-core:Triaged> <https://launchpad.net/bugs/1608956>
<mup> Bug #1608952 changed: Deployer: KeyError: 'uuid' connecting to environment <ci> <deployer> <regression> <juju-core:Triaged> <juju-deployer:New> <https://launchpad.net/bugs/1608952>
<mup> Bug #1608956 changed: local charms can be deleted while still referenced <juju-core:Triaged> <https://launchpad.net/bugs/1608956>
<perrito666> morning, I am OCR so ill be reviewing stuff :)
<mup> Bug #1608952 opened: Deployer: KeyError: 'uuid' connecting to environment <ci> <deployer> <regression> <juju-core:Triaged> <juju-deployer:New> <https://launchpad.net/bugs/1608952>
<mup> Bug #1608956 opened: local charms can be deleted while still referenced <juju-core:Triaged> <https://launchpad.net/bugs/1608956>
<dimitern> babbageclunk: review poke ? :)
<babbageclunk> dimitern: Still reading - sorry, was interrupted by call with alexisb.
<babbageclunk> nearly done
<dimitern> babbageclunk: no worries
<babbageclunk> dimitern: done!
<dimitern> babbageclunk: tyvm!
<mup> Bug #1608959 opened: deleted local charms not removed from caches <juju-core:Triaged> <https://launchpad.net/bugs/1608959>
<rick_h_> fwereade: are you up for cleaning the charm/cache problems 'the right way'?
<rick_h_> fwereade: if you are cool with it would love to tackle those together with a central plan that removes the array of issues we're nipping at from different directions
<fwereade> rick_h_, I... really rather sort of am, yeah
<rick_h_> fwereade: cool, let's break down the steps then for the kanban board and make sure to collect the array of bugs that we're targeting to make sure they fall away when the work is complete.
<fwereade> rick_h_, ack, will try to pull it all together
<rick_h_> fwereade: <3 ty much
<katco> fwereade: hey, i'm not sure what to do based on your email (i.e. which "fix" is "the fix" :)). are we ok to go ahead with the fix we discussed yesterday?
<fwereade> katco, heh, I was sort of raising a big heap of related issues for general consideration
<fwereade> katco, yesterday we were saying "delete the charm data, keep the doc, see what happens"?
<katco> fwereade: yeah, it looks like our charm caching is in a bad way atm
<katco> fwereade: yeah, that's what i have proposed
<fwereade> katco, ah, hadn't spotted that -- I'll take a look
<katco> fwereade: http://reviews.vapour.ws/r/5344/
<katco> fwereade: it already has a ship it, i just wanted to see where we're at with ian's input, and if you were raising additional points
<fwereade> katco, but, yeah, the worst consequence I can think of is the occasional failed download as a result of the related issues that are too big to drag in
<katco> fwereade: yep
<fwereade> katco, and that's mitigated by the evil caching anyway
<fwereade> katco, so, yeah, I think it's the best step forward
<katco> fwereade: ok, cool. i'll go ahead and land
<katco> fwereade: ta
<fwereade> katco, fix the docstring on deleteCharmarchive if you haven't triggered yet
<katco> fwereade: np i can do that
<fwereade> katco, ta
<katco> rick_h_: looks like master is blocked. what do i do?
<rick_h_> katco: mark your card as blocked and put it in landing please
<rick_h_> katco: and let's see what's up and what needs to happen to unblock master
<katco> rick_h_: apparently it's blocked on the other bug i am to be working on
<rick_h_> katco: k, then leave the current card in landing/blocked and grab the other one please
<katco> rick_h_: so i am my own grandma and i am blocking myself
<rick_h_> katco: :)
<rick_h_> katco: more like someone didn't stack the bugs in order of actual todo priority
 * rick_h_ hides real quick 
<katco> rick_h_: oh... jujubot has accepted my merge request... odd
<katco> juju.fail is lying to me i suppose. i wish ci just had a dashboard
<dimitern> katco: you can checkout the python script check-blockers from juju-ci-tools and run it trivially btw ;)
<katco> dimitern: thanks, i might just start doing that. i dunno why ci can't provide that info on our dashboard though
<dimitern> that's a good question... not a priority I guess
<rick_h_> dimitern: katco we'll take that into advisement as we work on the new workflows/processes
<dimitern> rick_h_: +1
<katco> rick_h_: good luck. i raised that 2 years ago haha
<perrito666> k I am about to tackle the queue as it is, anyone needs an urgent review before that?
<natefinch> oh distro packages, you're so wacky.  installing the golang package installs gcc and make and some perl crap... geez
<andrey-mp> Hi, I've asked a question about glance-charm in the OpenStack dev mailing list - http://lists.openstack.org/pipermail/openstack-dev/2016-August/100660.html  is it a suitable place for the question or there is a better place present?
<perrito666> natefinch: odd, why would it install gcc?
<dimitern> natefinch: simply golang or golang-go ? the latter shouldn't depend on gcc
<perrito666> andrey-mp: hi there, I think #juju is a more suitable place but you are free to ask and if someone knows the answer will gladly tell it to you
<natefinch> dimitern: golang... I certainly don't know the difference between thw two
<andrey-mp> perrito666: thanks, will ask in #juju
<natefinch> perrito666: http://pastebin.ubuntu.com/21900049/
<dimitern> natefinch: one is a metapackage, the other specifically using the gc toolchain
<dimitern> (IIRC)
<perrito666> natefinch: it most likely depends on build-essentials
<perrito666> ah, yes it does
<perrito666> natefinch: build essential is the bag of stuff that is required to build pretty much everything (in terms of tools)
<perrito666> dimitern: you notice rb failing earlier?
<perrito666> dimitern: I am getting a 500
<natefinch> perrito666: evidently not actually essential Â¯\_(ã)_/Â¯
<perrito666> natefinch: the name made sense when it was crafted
<perrito666> natefinch: ideally in any debian based distro you install build-essential and apt-get build-dep from whatever package you want and you can compile it by hand
<perrito666> mgz: sinzui abentley could any of you take a peek at the rb server? I am getting a consistent 500, I will put all my chips in lack of space
<natefinch> lol, but golang *doesn't* depend on bzr.  Nice.
<sinzui> perrito666: what is rb?
<natefinch> reviewboard
<katco> perrito666: working for me
<sinzui> natefinch: you marked bug 1604474 as fixed but ci still cannot deploy windows charms. I can when we rest with juju from the first week of July
<mup> Bug #1604474: Juju 2.0-beta12  userdata execution fails on Windows <azure-provider> <ci> <juju2.0> <oil> <oil-2.0> <regression> <windows> <juju-core:Fix Committed by natefinch> <https://launchpad.net/bugs/1604474>
<natefinch> sinzui: uh, weird.  Ok, I'll have to look at it again.
<perrito666> katco: strange, It seems to be a random failure
<perrito666> katco: would you try to enter this for me? http://reviews.vapour.ws/r/5355/
<katco> perrito666: weird, that gives me a 500
<perrito666> It is a django, so that must be logging errors somwehere
<rick_h_> natefinch: heads up https://bugs.launchpad.net/juju-core/+bug/1604474
<mup> Bug #1604474: Juju 2.0-beta12  userdata execution fails on Windows <azure-provider> <ci> <juju2.0> <oil> <oil-2.0> <regression> <windows> <juju-core:In Progress by natefinch> <https://launchpad.net/bugs/1604474>
<rick_h_> natefinch: moved the card back to the high prio lane for after the current work/pr to see if we can understand why they're still seeing it
 * rick_h_ goes out for lunchables today
<mup> Bug #1609041 opened: Race in github.com/juju/juju/cmd/modelcmd <ci> <race-condition> <regression> <unit-tests> <juju-core:Triaged> <https://launchpad.net/bugs/1609041>
<perrito666> bbl lunch
<natefinch> gah, gotta call an electrician... the outlet for our electric range is only feeding it 120, not 240, so I can't cook anything :/
<mgz> natefinch: rediscover fire
<perrito666> Natefinch most likely you have a breaker for one phase that you only use for that
<rogpeppe> here's a fix to UpdateCloudCredentials. a review would be much appreciated, thanks! https://github.com/juju/juju/pull/5917
<natefinch> perrito666: there's a double breaker just for the stove, but toggling it doesn't help.  Google says it's likely either a bad breaker or bad outlet.
<perrito666> Do you have a multimeter?
<perrito666> If so measure the input to the breaker
<perrito666> And make sure that you measure between two  phases otherwise you will get 120
<natefinch> I do have a multimeter, but I don't think I can get at the input to the breaker without taking the breaker box apart
<natefinch> and whether it's the outlet or the breaker - I'm not doing that myself.  I could in theory do the outlet, but I doubt my wife would let me.
<perrito666> Geek up
 * rick_h_ goes to do kid duty, back later. 
<alexisb> so natefinch, everytime I have to bootstrap without the interactive stuff I get annoyed :)
<alexisb> liking the interactive bootstrap
<katco> any python enthusiasts want to help me debug installing ci tools?
<rick_h_> katco: what's up?
 * rick_h_ dusts off python stuff
<katco> rick_h_: getting an error after doing make install-deps. retrying after tweaking something... looks like it's potentially gotten past the error point
<rick_h_> katco: k, let me know how it goes
<katco> rick_h_: yep, different error this time; timeout. looks like it's doing something with s3...
 * katco is now debugging a python script to install dependencies for a CI system so she can debug an actual Go bug in Juju
 * katco feels fantastic about this
<katco> i just tried re-running the test and it looks like it's doing something, so i'll just hope i don't need whatever this script is trying to download
<rick_h_> katco: heh ok, welcome to the polyglot future :-)
<katco> rick_h_: been there for awhile :)
<perrito666> I either need to stop nodding on standups or buy a webcam
<menn0> katco: ping
<katco> menn0: pong
<menn0> katco: how's bug 1603221 going?
<mup> Bug #1603221: Charms utilizing storage fail on LXD <blocker> <jujuqa> <lxd-provider> <storage> <juju-core:In Progress by cox-katherine-e> <https://launchpad.net/bugs/1603221>
<menn0> katco: is there a need for handoff before you finish up?
<katco> menn0: i just started to try and reproduce today; nothing to really hand off atm
<menn0> katco: ok cool.
<menn0> katco: is it really worthy of blocker status?
<katco> menn0: that i don't know. maybe not since it's limited to 1 feature on 1 substrate
<menn0> katco: cool. I'll bring it up in the standup.
<katco> menn0: cool. i'm not sure who deems things blockers these days
<menn0> katco: in this case it was alexisb
<menn0> :)
<katco> menn0: ah. well maybe she can give some more info as to why
<menn0> katco: that's what I'm thinking
<alexisb> menn0, we are on lock down
<alexisb> it gets decided in the release call
<alexisb> we are working towards a bless for this weeks release
<menn0> alexisb: ok cool
<veebers> I'm seeing this error repeated in my mongodb deploy log (for a ci test) Not sure what may cause it: ERROR juju.worker.dependency engine.go:539 "leadership-tracker" manifold worker returned unexpected error: leadership failure: lease manager stopped
<veebers> sigh, might need another coffee. Just tried --veebers instead of --version :-\
<axw> lol
<anastasiamac> new option \o/
<veebers> hah, I would hate to think what it did
<anastasiamac> functional test coverage? :)
<veebers> heh :-)
<menn0> veebers: that's not good. which version of Juju?
<menn0> veebers: and do you have full logs?
<veebers> menn0: I realised before it was a slightly older version (2.0-beta13-xenial-amd64)
<veebers> menn0: I can put that log up somewhere if it's useful. I'm just about to try a run with beta14 if that'll be of more interest
<menn0> veebers: it would be good to confirm if the problem still exists in a later version
<menn0> veebers: I think fwereade_ has been doing some work to fix things in this area
<veebers> menn0: ack. I'll put these current logs aside so they don't get destroyed and do a couple of runs with a newer juju binary
<menn0> veebers: great, thanks
<veebers> nw
#juju-dev 2016-08-03
<veebers> menn0: right this run failed with the same message too. What's the most useful way to present the logs? Also, which logs would be useful? (I'm seeing that error in unit-mongodb-0.log.gz).
<veebers> menn0: oh wait, I can more than likely see the same thing with the jenkins run, ignore me for now :-)
<menn0> veebers: if the jenkins run has everything then that's perfect
<rick_h_> menn0: can you parallelize make check in any way?
<menn0> rick_h_: it is parallelised, but by package
<menn0> rick_h_: so if you're running tests in just one package they get run serially
<rick_h_> menn0: hmm, ok. I guess it might have been done but didn't give me my console back. I see xx passed, 1 skip, 4 failed.
<rick_h_> menn0: but yea, a second run does show it running pretty parallel now that I start over. https://flic.kr/p/JQCkPg
<menn0> rick_h_: yep... the way that all cores get pegged for most of the test run is also a good indication
 * rick_h_ is more patient for run #2
<menn0> rick_h_: is your /tmp on tmpfs? That makes a big difference for test run time.
<rick_h_> menn0: no, ty for the tip. i need to spend some time getting comfy with go dev and tricks like that
 * rick_h_ needa an induction sprint :p
<menn0> rick_h_: haha np :)
<menn0> axw: big review done. phew!
<menn0> axw: nice work.
<axw> menn0: TYVM
<axw> wallyworld: and you too
<wallyworld> sure
<veebers> menn0: I'm just trying to get a run with that error. I'm also trying to confirm that it's not a red-herring. I believe that there are issues as the host machine is network confined
<menn0> veebers: seems unlikely that it could be related. the lease manager is a fairly internal thing.
<wallyworld> menn0: i've had a look at a race in juju ci tests - looks like a loggo issue due to the recent changes. i can't repro, but i think i have convinced myself where the issue is https://github.com/juju/loggo/pull/18
<menn0> wallyworld: ok, give me 2 mins
<wallyworld> sure, np
<mup> Bug #1608952 changed: Deployer: KeyError: 'uuid' connecting to environment <blocker> <ci> <deployer> <regression> <juju-core:Invalid by wallyworld> <juju-deployer:New> <https://launchpad.net/bugs/1608952>
<menn0> wallyworld: sorry, got distracted by other work
<wallyworld> no problemo
<menn0> wallyworld: should the mutex be on the the writer itself perhaps?
<wallyworld> menn0: the writer is an interface and my thought was that if e do that, we then require all concrete implementations to do the muxtex, whereas doing it in the context is safer?
<menn0> wallyworld: yeah, fair enough
<menn0> wallyworld: ship it... the PR description uses muxtex twice instead of mutex though :)
<wallyworld> it is well know i can't type
<menn0> wallyworld: I think you can blame the drugs this time
<wallyworld> sigh, see ^^^^
<menn0> hahaha
<wallyworld> axw: since menno is away, want a 2 line review? http://reviews.vapour.ws/r/5359/
<axw> wallyworld: looking
<axw> wallyworld: LGTM
<wallyworld> ta
<veebers> menn0-school-run: I can't get the jenkins run of that test to fail in the same way. I'll let you know if I can get it to happen at some point
<menn0> veebers: ok bummer. I can take a look at the logs you gathered earlier if you like.
<veebers> menn0: I'm not sure if they'll be interesting. It could be a red-herring due to the network confinement etc. on that machine. I'll double check and get back to you tomorrow? (i.e. I may be doing something odd there)
<blahdeblah> Is there a way to push juju tools when you manually provision a machine, or must it always pull from machine 0?
<blahdeblah> Or perhaps give it a different pull location?
<menn0> veebers: no problems
<rogpeppe> axw: ping
<mup> Bug #1609343 opened: [aws; beta13] Juju can pick subnets from the wrong VPC with spaces constraints specified <ec2-provider> <usability> <juju-core:In Progress by dimitern> <https://launchpad.net/bugs/1609343>
<perrito666> anyone uses vim plus ctrlp to work on juju?
 * perrito666 looks at rick_h_ 
<rick_h_> perrito666: well I do use vim and ctrlp but don't consider I've "worked on juju" atm
<perrito666> rick_h_: ever had missing files? even tuning the max depth and limits I still miss files
<rick_h_> perrito666: not tried it enough to say tbh
<lazyPower> perrito666 - yeah thats weird. ctrlp has worked well for me even on large code bases.. but i admit i haven't tried it on the juju codebase
<lazyPower> might some other bug causing it to drop files
<perrito666> lazyPower: very likely, in my case the files are missing even from the buffers list
<mup> Bug #1609405 opened: DeploySuite.SetUpTest connection was forcibly closed <ci> <intermittent-failure> <regression> <unit-tests> <juju-core:Triaged> <https://launchpad.net/bugs/1609405>
<mup> Bug #1609407 opened: remoteFunctionalSuite.TestUsingTCP no such network interface <ci> <intermittent-failure> <regression> <unit-tests> <juju-core:Triaged> <https://launchpad.net/bugs/1609407>
<mbruzek> balloons: Are you there?
<dimitern> katco, babbageclunk: quite a tiny review fixing bug 1609343, when you have a moment please!
<mup> Bug #1609343: [aws; beta13] Juju can pick subnets from the wrong VPC with spaces constraints specified <ec2-provider> <usability> <juju-core:In Progress by dimitern> <https://launchpad.net/bugs/1609343>
<mbruzek> mgz: I am having trouble installing juju today, juju-core gives me 1.25.6 and the juju package does not seem to include the juju binary.
<rick_h_> fwereade_: do you have time to help dimitern by reviewing http://reviews.vapour.ws/r/5363/ please so it might make b14?
<mgz> mbruzek: well, that's interesting
<fwereade_> rick_h_, looking
<mgz> mbruzek: using what ppa?
<rick_h_> fwereade_: ty
<mbruzek> mgz: but tab completion works like a charm!
<mgz> mbruzek: I have reports to the opposite with other setup
<mgz> so... things in general are not quite right
<dimitern> rick_h_, fwereade_: thanks! :)
<mbruzek> mgz: I have both devel and stable in my source.list.d directory:
<mbruzek> deb http://ppa.launchpad.net/juju/stable/ubuntu xenial main
<mbruzek> deb http://ppa.launchpad.net/juju/devel/ubuntu xenial main
<mgz> mbruzek: so, the fix is likely you just need to install `juju-1.25` but I'm a little concerned the dep chain is wrong for the packages you hae installed
<rick_h_> dimitern: care to trade for fwereade_'s branch http://reviews.vapour.ws/r/5362/ please?
<rick_h_> dimitern: before jumping into the next pool
<dimitern> rick_h_: sure - I'll have a look before digging in around bug 1608105
<mup> Bug #1608105: LXD no longer activates all interfaces on initial deploy when using MAAS2rc3 and JUJU Beta13 <juju-core:Triaged> <https://launchpad.net/bugs/1608105>
<mgz> ugh, the ppa packaging is just all a mess still >_<
<mbruzek> mgz: what if I wanted 2.0-beta13?
<mgz> that's what just 'juju' should get you if you have the devel package installed
<mgz> but I'm not sure that mixing devel and stable ppas actually works how we want atm
<mbruzek> mgz: It was necessary to have both devel and stable at one point to get juju installed.
<mbruzek> mgz: I did not do this to anger you, it was needed at one point
<mgz> mbruzek: yeah, and it certainly should work
<mbruzek> mgz: I could remove stable and try again if you think that will work
<mgz> we just have too many different sets of packaging and they don't all play nicely with each other
<mgz> mbruzek: pastebin `dpkg -l "juju*"` first
<dimitern> fwereade_: you've got a review ;)
<mbruzek> mgz: http://paste.ubuntu.com/22028864/
<fwereade_> dimitern, cheers :)
 * dimitern whew.. that's got to be the longest bug and PR descriptions for a fix with diff size less than 1/3 of the length of both those descs..
<rick_h_> dimitern: :P
<mgz> mbruzek: thanks, go ahead and futz now and see if you can get a working set?
<fwereade_> dimitern, and so do you :)
<dimitern> fwereade_: tyvm!
<dimitern> rick_h_: so how's the process now - with +1 I need to ask e.g. mgz (hey there ;) for a second +1 and test the QA steps?
<mbruzek> mgz: I removed the stable ppa, updated and got this message when trying to install juju-core:juju-core is already the newest version (1.25.6-0ubuntu1~16.04.1~juju1).
<rick_h_> dimitern: no, you can just check the QA steps locally using the doc for any shortcuts if it's something that's pretty QA'able
<rick_h_> dimitern: nothing there involves the QA team, it's all checking each other
<dimitern> rick_h_: I see - but do I still need 2x LGTM or not?
<mgz> it would be nice to actually have functional test coverage for subnet stuff on aws
<rick_h_> dimitern: no, we're not doing 2x +1 atm
<rick_h_> dimitern:  more +1 and QA OK
<dimitern> rick_h_: ok then, thanks
<dimitern> mgz: there are a couple in featuretests/
<rick_h_> mgz: yes, we need to get some more of that for the AWS stuff since it does't require too much custom setup/etc like MAAS
<dimitern> mgz: can you give http://reviews.vapour.ws/r/5363/ a QA OK using the steps there please?
<rick_h_> dimitern: it's on our own team to check QA. Maybe natefinch for katco or fwereade_
<rick_h_> dimitern: unless mgz is just curious :)
<mbruzek> mgz: This is me futzing: http://paste.ubuntu.com/22029893/
<mbruzek> mgz: Shall I open a bug or is this just my system messed up?
 * dimitern leaves it for standup
<mgz> mbruzek: wanting to install juju-1.25 seems right
<rick_h_> dimitern: fwereade_ natefinch ping for standup
<dimitern> omw
<natefinch> rick_h_: omw
<mbruzek> mgz: right but how do I get 2.0 ?
<mgz> mbruzek: a bug is probably a good idea regardless
<mgz> we need something to track sorting out the ppas
<mbruzek> mgz: juju-core or is there a packaging project?
<mgz> just juju-core
<mbruzek> mgz: https://bugs.launchpad.net/juju-core/+bug/1609437
<mup> Bug #1609437: Unable to install juju 2.0 using apt <juju-core:New> <https://launchpad.net/bugs/1609437>
<mgz> ...that's a scarier bug title than it should be :)
<mbruzek> mgz: sorry what would you like me to change it to?
<mgz> mbruzek: don't worry about it, I cna edit
<mbruzek> do ash you wish. I am not feeling creative today
<katco> rick_h_: so apparently my bug is no longer a blocker; same gameplan?
<rick_h_> katco: /me looks
<katco> rick_h_: you responded to that thread last night it looks like
<rick_h_> balloons: oh, was #1603221 the one that axw noted was not implemented in lxd?
<mup> Bug #1603221: Charms utilizing storage fail on LXD <blocker> <jujuqa> <lxd-provider> <storage> <juju-core:In Progress by cox-katherine-e> <https://launchpad.net/bugs/1603221>
<katco> rick_h_: yeah
<rick_h_> katco: ok, then let's play normal OCR please
<rick_h_> fwereade_: dimitern and if it's EOD please work with katco to help do QA with the shared info before you head out
<katco> rick_h_: sounds good
<mgz> fwereade_: mind if I go ahead and land your ErrMissing branch for trunk? we want a new change to test.
<natefinch> review for anyone interested, fairly simple code: http://reviews.vapour.ws/r/5364/
<fwereade_> mgz, be my guest :)
<mup> Bug #1609437 opened: Unable to install juju 2.0 using apt <juju-core:New> <https://launchpad.net/bugs/1609437>
<katco> poor axw... did we ever figure out what was going on with his review? http://reviews.vapour.ws/r/5355/
<dimitern> rick_h_: sure, will check with katco
<dimitern> babbageclunk: ping
<babbageclunk> dimitern: hey
<dimitern> babbageclunk: hey :) I've seen your comment re not seeing the expected subnet
<dimitern> babbageclunk: can you give me more details about it?
<babbageclunk> dimitern: Sure - I got an error running `juju add-space test subnet-096b3f72 subnet-0c9eaf65`
<babbageclunk> dimitern: error: invalid arguments specified: "subnet-096b3f72" is not a valid CIDR
<dimitern> babbageclunk: hmm .. odd - I'm trying now to see if I'd made a typo
<babbageclunk> dimitern: If I look in the AWS console under network interfaces (which might not be the right place) I can see subnet-0c9eaf6 but not 096b3f72
<dimitern> babbageclunk: have a look at the dropdown menu above on the left (Services v), pick VPC from it and then Subnets
<babbageclunk> dimitern: Oh, ok - I can see it in there.
<babbageclunk> dimitern: So I don't know why I was getting that error then.
<dimitern> babbageclunk: you're right - that error wasn't exactly expected :/
<dimitern> babbageclunk: it will work in 3 steps though (with update the QA steps shortly) - i.e. add-space test; add-subnet subnet-xxx test; add-subnet subnet-yyy test;
<babbageclunk> dimitern: ok cool - happy to try doing it again in a bit.
<dimitern> babbageclunk: if you can - great! ;)
<dimitern> btw the shared aws account has these additional users, which never logged in: natefinch, alexisb; while wallyworld, and mfoord haven't logged since 2015 - please ping/mail me if you want account setup info (or password reset, etc. if you forgot)
<mup> Bug #1609437 changed: Unable to install juju 2.0 using apt <packaging> <juju-core:Won't Fix> <juju-release-tools:Triaged> <https://launchpad.net/bugs/1609437>
<mup> Bug #1609463 opened: upgrade-charm command is inconsistent with deploy when using local charms <juju-core:New> <https://launchpad.net/bugs/1609463>
 * rick_h_ goes for lunchables
<mup> Bug #1609494 opened: grant-revoke: disabled user still in admin read-write <ci> <grant> <regression> <user> <juju-core:Triaged> <https://launchpad.net/bugs/1609494>
<mup> Bug #1609494 changed: grant-revoke: disabled user still in admin read-write <ci> <grant> <regression> <user> <juju-ci-tools:Triaged> <juju-core:Triaged> <https://launchpad.net/bugs/1609494>
<mup> Bug #1609494 opened: grant-revoke: disabled user still in admin read-write <ci> <grant> <regression> <user> <juju-ci-tools:Triaged> <juju-core:Triaged> <https://launchpad.net/bugs/1609494>
<perrito666> bbl
<natefinch> katco: default is a keyword.  It unfortunately is a very useful variable name, and there aren't many good alternatives.  Suggestions more than welcome.  I agree dflt is terribad.
<natefinch> katco (or anyone else) could use a review on this (sorry no reviewboard link, not sure what happened) https://github.com/juju/schema/pull/13
<natefinch> I wish hexchat had a hotkey to change font size
<katco> natefinch: lol oops forgot about that
<katco> natefinch: d3fault
<katco> natefinch: dfault
 * katco shrugs
<natefinch> dfault is pretty good
<natefinch> sorta sounds like a DJ name
<katco> lol
<natefinch> gah, reflection is so horrible... once you start using it, you can't ever take it out, because you never know who is relying on it :/
<natefinch> I'm pretty sure we're always passing a map[string]interface{} to coerce, but because we're using reflection, I can't know for sure... in theory it can take map[Stringer]interface{} too, but I'm pretty sure no one does that.
 * rick_h_ goes to get the boy from camp
<perrito666> back
<perrito666> katco natefinch: byOmission sort of applies to default in a very pompous way
<mup> Bug #1609041 changed: Race in github.com/juju/juju/cmd/modelcmd <blocker> <ci> <race-condition> <regression> <unit-tests> <juju-core:Fix Released by wallyworld> <https://launchpad.net/bugs/1609041>
<mup> Bug #1609041 opened: Race in github.com/juju/juju/cmd/modelcmd <blocker> <ci> <race-condition> <regression> <unit-tests> <juju-core:Fix Released by wallyworld> <https://launchpad.net/bugs/1609041>
<katco> perrito666: hmmm... context for that comment?
<perrito666> katco: you where discussing a replacement for the word default
<katco> perrito666: ah
<perrito666> and I used my super spanish powers to find an old and unused one :p
<katco> haha
<natefinch> haha
<mup> Bug #1609041 changed: Race in github.com/juju/juju/cmd/modelcmd <blocker> <ci> <race-condition> <regression> <unit-tests> <juju-core:Fix Released by wallyworld> <https://launchpad.net/bugs/1609041>
<babbageclunk> thumper: sorry! Here now if you want to do a quick chat?
<thumper> babbageclunk: ok
<alexisb> wallyworld, ping
<wallyworld> yo
<alexisb> yo dawg
<wallyworld> zup
<alexisb> wallyworld, did you impliment the show-model command
<wallyworld> no
<wallyworld> was multi model work i think
<alexisb> thumper, was it you?
<perrito666> wallyworld: how are you feeling?
<wallyworld> much better today thanks
<wallyworld> had a raging headache and sore throat yesterday
<katco> wallyworld: didn't realize you were under the weather :( glad you're feeling better
<perrito666> wallyworld: cool, then I wont feel guilty saying I addressing your comments and you should take a second look :p
<wallyworld> lol
<wallyworld> katco: tis all good :-)
<katco> i don't know how, but even a remote globally distributed team still seems to demonstrate properties of infection clusters
<wallyworld> katco: visruses spread using computers you know
<katco> wallyworld: i bet i transferred it from my compooper when i got my drink out of its cup-holder
<wallyworld> seems plausible
<perrito666> well we are clever enought to get together once every semester, when its winter for half of the team
<perrito666> we are not that smart
<alexisb> anastasiamac, running late
<katco> alexisb: not sure if you're there, but we lost you
<perrito666> katco: that answers the question
<katco> perrito666: apparently :)
<mup> Bug #1558703 changed: PatchValue unsafe for SetUpSuite <testing> <unit-tests> <juju-core:Fix Released by jameinel> <https://launchpad.net/bugs/1558703>
<axw> redir: that bug that's assigned to you about grant/revoke: I have a fix for it already. it's bundled up with some other changes, not sure if we want to gate on them
<axw> katco: nfi what's up with reviewboard, but my PR was reviewed on github :)
<katco> axw: ah ok :) good to hear
<perrito666> axw: point me to the redir issue (redir is on holidays iirc)
<katco> axw: your code was so good RB knew it didn't need to be reviewed
<perrito666> axw: I am giving some love to grant/revoke
<axw> perrito666: https://bugs.launchpad.net/juju-core/+bug/1609494
<mup> Bug #1609494: grant-revoke: reenabled users missing from list-users <blocker> <ci> <grant> <regression> <user> <juju-ci-tools:Invalid> <juju-core:Triaged by reedobrien> <https://launchpad.net/bugs/1609494>
<axw> katco: heh, probably more like it was +1500/-1600 lines and it fell over :p
<katco> haha
<perrito666> I think i would gladly give time of my life to change reviewboard for something else that we can think is better for a few months before starting hating that too
<katco> perrito666: i think all diffs and comments should be pasted here, in irc.
<perrito666> katco: I think emacs got to your nervous system and its not you talking
<axw> wallyworld: is the leads call no more?
<wallyworld> axw: yeah, seems so
<wallyworld> i thought we were still going to have it but seems not
<axw> cool, got up at 5:45 for no reason -_-
<wallyworld> axw: i only found out by chance when i saw the meeting invite come through yesterday and it was cancelled
<alexisb> wallyworld, ping
<alexisb> sorry lost network, back now
<wallyworld> ok, see you in 1:1
<menn0> thumper: I've just done a big card cleanup. All the cards on the onyx board that were still relevant have been moved to the A team board
<thumper> menn0: cool
<thumper> menn0: can we chat about the i/o timeout bug?
<menn0> thumper: sure
<thumper> 1:!
<menn0> thumper: i'm there already
<mup> Bug #1600257 changed: Broken bash completion with old ppa packages present <bash-completion> <packaging> <verification-done> <juju-core:Invalid> <juju-core (Ubuntu):Fix Released> <juju-core (Ubuntu Xenial):Fix Released> <https://launchpad.net/bugs/1600257>
<axw> veebers: FYI this is the branch for juju-ci-tools: https://code.launchpad.net/~axwalk/juju-ci-tools/cli-model-owner
<axw> veebers: ignore the one linked from the PR
<mup> Bug #1600257 opened: Broken bash completion with old ppa packages present <bash-completion> <packaging> <verification-done> <juju-core:Invalid> <juju-core (Ubuntu):Fix Released> <juju-core (Ubuntu Xenial):Fix Released> <https://launchpad.net/bugs/1600257>
<veebers> axw: axk
<veebers> :-\ ack
<mup> Bug #1600257 changed: Broken bash completion with old ppa packages present <bash-completion> <packaging> <verification-done> <juju-core:Invalid> <juju-core (Ubuntu):Fix Released> <juju-core (Ubuntu Xenial):Fix Released> <https://launchpad.net/bugs/1600257>
#juju-dev 2016-08-04
<alexisb> anastasiamac, ping
<alexisb> if you are around we can hope on the release standup
<anastasiamac> alexisb: tyvm! see u there
<veebers> axw: to clarify for myself, you want to get this landed for the coming release right? https://github.com/juju/juju/pull/5877
<wallyworld> veebers: technically, we are down to critical fixes only. if we get a good CI run, maybe this could land then and we could use it if CI passes, but have the fallback of a good run with all criticals fixed
<veebers> wallyworld: right, I'm checking so I know the timeline expectations for getting this in. i.e. if I ping about it tomorrow mornings standup it'll probably be to late to be included in the release. But sounds like that's ok?
<wallyworld> veebers: yeah, i think they want to start the release their thursday, so too late
<wallyworld> we have stuff queued up to land post beta
<veebers> wallyworld: cool. I'll get it sorted today/tomorrow
<wallyworld> sounds good, ty
<axw> veebers wallyworld: yeah it doesn't have to go into this release, it's just been dragging on for a while now, and needs to get sorted
<axw> veebers wallyworld: sooner we address the better, because it's a change for users to adapt to. we may need to iterate on syntax based on feedback
<wallyworld> yep
<veebers> ack
<wallyworld> axw: we can do a snap :-)
<axw> wallyworld: true :)
<wallyworld> well, as soon as I get a bit more sorted out
<veebers> axw: re: http://bazaar.launchpad.net/~axwalk/juju-ci-tools/cli-model-owner/revision/1523/utility.py can you give an example of what model_name being passed in would look like and what the expected return output would be. I'll branch that and get unit tests written and propose it etc.
<axw> veebers: e.g., "admin@local/default"
<axw> or just "admin/default"
<axw> veebers: and thanks
<veebers> nw
<axw> anastasiamac: can http://reviews.vapour.ws/r/5341/ be closed?
<anastasiamac> axw: yes. let's :) I'll re-PR when ready :)
<axw> thanks
<anastasiamac> axw: done
<wallyworld> axw: does the diff for "environs: update API for hosted models" include the work from the dependent PR. I think it does? So easiest to review once that other PR lands and it can be rebased?
<axw> wallyworld: it does, but the RB diff should just show the delta
<wallyworld> really? even if proposed against master? ok
<axw> wallyworld: yeah, you can do that with "rbt post -r <RB review ID> --parent <parent git branch>"
<perrito666> mm, what was the way to tell mongo to ve Trace level verbose?
<perrito666> s/mongo/juju
<wallyworld> axw: nice. where does RB review ID come from? that implies you propose via github PR, and the issue that post with the newly created id?
<axw> wallyworld: yes that's I do. create the PR, the bot creates the RB review (ID is just the number in the URL), then you pass that to the tool
<wallyworld> axw: and the initial step is to branch off the upstream branch right? instead of branching off master
<anastasiamac> axw: i do not want to continue crossing swords on this review. Could u plz double-check outstanding issues so that we can progress its landing? http://reviews.vapour.ws/r/5360/
<perrito666> is the all team meeting happening? I somehow presume that its the exact same group of people than the standup
<anastasiamac> perrito666: m all for team meeting. there are some updates around bug and release mgmt that can b communicated better. there is criteria stuff that i'd love to talk about :)
<anastasiamac> perrito666: and there is always nice dueling to witness
<anastasiamac> perrito666: also would love to touch base re: review process
<anastasiamac> perrito666: oc, i might b dreaming and noone will join me again.. in which case, I'll just tlak to myself ;)
<axw> anastasiamac: I don't really think splitting that test is worthwhile. it's one of the cases where I think a table-driven test would be fine
<anastasiamac> axw: as an OCR, m happy to go with ur opinion
<anastasiamac> axw: thumper: menn0:perrito666: team meeting
<anastasiamac> natefinch: ^^
<axw> wallyworld: I think we should stop showing bootstrap-config in "show-controller" by default (maybe not at all?)   what do you think?
<axw> wallyworld: now that bootstrap config contains all the defaults, it's taking up a lot of screen space
<wallyworld> axw: yeah, not much point. what we *should* show is controller config
<axw> wallyworld: hmm is that going to be dynamic? will we have commnads to update it?
<wallyworld> axw: so far, it is mongo port, api port which are static, plus numa setting, which i guess could be dynamic. and there is already a bespoke get-controller-config command. so yeah, just remove bootstrap config i reckon
<axw> wallyworld: ah I thought you meant inherited config. okey dokey
<wallyworld> s/remove/not show
<wallyworld> axw: there's a juju model-defaults to show inherited config
<axw> wallyworld: think it's worth having a flag to show? I'm not sure it was even asked for, I think I just added it there
<wallyworld> i wouldn't add to the complexity by even having a flag - just not show IMO. people don't really need to see it and it's only there for kill-controller and restore -b
<axw> wallyworld: cool, SGMT
<axw> SGTM*
<axw> wallyworld: btw I've just bootstrapped AWS with region, access-key and secret-key removed from model config
<axw> finally got there
<wallyworld> \o/ ^ 100
<wallyworld> awesome sauce
<wallyworld> that deserves a beer or two
<axw> wallyworld: should be able to drop region from restricted config and add a model in another region now too, I'll try that at the same time
<wallyworld> whohoo
<wallyworld> assuming networking is set up so the model can talk to the controller
<wallyworld> not sure what's involved there
<wallyworld> may need to specify a vpc id?
<axw> wallyworld: it works because it goes over the internet
<axw> public IPs
 * axw tests
<wallyworld> ah right. we should look to fix it so it doesn't have to, or document how to at least
<axw> wallyworld: why?
<axw> wallyworld: traffic cost?
<wallyworld> yep, plus efficency
<wallyworld> maybe port exposing / security groups would prevent it also if it is external traffic?
<axw> wallyworld: I'd like to think that AWS knows how to route those addresses efficiently. don't know about the cost side
<wallyworld> not sure that AWS does that sort of short circuiting
<wallyworld> could be wrong
<axw> wallyworld: anyway, I now have a controller in AWS with machines in two regions :)
<wallyworld> awesome :-)
 * axw goes to make a cup of tea to celebrate
<wallyworld> but IMO we need clear guidelines on how to set up
<wallyworld> add some rum to the tea
<axw> wallyworld: what do you mean? there's no setup. just bootstrap, then add-model --region=foo
<wallyworld> networking
<wallyworld> how to avoid external traffic etc
<wallyworld> will be provider specific
<axw> wallyworld: ok. yes, if/when we change that to not go over hte internet
<wallyworld> maybe we guide them to a suitable space set up etc
<veebers> wallyworld: re: log forwarding, just adding a model wouldn't be enough to get that models logs forwarded to the controller right? It'll need to do some <action> for that to trigger a forward?
<veebers> (this is in response to an email from you from a wee while ago)
<wallyworld> veebers: i think log forwarding needs to be enabled on the controller model, and then yeah the hosted model needs to log somethong
<veebers> wallyworld: I have the basic forwarding stuff (i.e. controller forwards it's logs). What action would generate a log from the model that would be forwarded?
<wallyworld> veebers: just the act of adding the model - it will log worker startup etc
<veebers> wallyworld: interesting. I'm not seeing that forwarded but I might be doing something wrong. I'll continue digging
<wallyworld> you see the controller model logs ok though?
<wallyworld> just not hosted model logs
<veebers> wallyworld: correct
<wallyworld> hmmm, it may be that it's only enabled for the controller, i'd need to check
<wallyworld> give me a few minutes
<veebers> wallyworld: awesome, cheers
<thumper> menn0: http://reviews.vapour.ws/r/5369/
<wallyworld> axw: doing a rb post, what username/password did you use?
<wallyworld> since i normally sign into rb using github sso
<menn0> wallyworld: you use oauth with rbt too
<menn0> wallyworld: see the bottom of reviewboard.md in docs/contributing
<menn0> docs/contributions
<wallyworld> menn0: ta
<menn0> thumper: looking
<menn0> thumper: review done
<thumper> menn0: ta
<menn0> thumper: did you try reproducing using enable-ha?
<thumper> menn0: I did, wasn't able to reproduce
<thumper> menn0: btw, are you taking the piss?
<menn0> thumper: I guess it's somewhat timing dependent
<thumper> "errorCoder" ?
<menn0> thumper: slightly :)
<menn0> thumper: only because I knew it would annoy you :)
 * thumper slaps menn0
<menn0> thumper: you can drop it :)
<thumper> I did :)
<thumper> menn0: can't really have the server tell the client to retry without parsing the error types...
 * thumper thinks
<thumper> let me look a bit more
<wallyworld> veebers: the log forwarder will get it's logs to send what whatever we record in state for debug log
<wallyworld> menn0: does debug log include logs for hosted models?
<menn0> wallyworld: yes, but only for the machines and units in the model
<wallyworld> menn0: so not controller actions like starting workers etc
<menn0> wallyworld: any controller level activity (API requests and workers specific to the model in the controller) is still logged against the controller model
<menn0> wallyworld: I have a plan to fix this.
<menn0> wallyworld: thumper's recent work on loggo is part of that
<wallyworld> menn0: no worries, veebers was testing log forwarder and wanted to know what to expect
<menn0> kk
<wallyworld> for hosted models
<wallyworld> veebers: so you'll need to deploy something to see activity
<veebers> wallyworld: ok makes sense. Thank you
<wallyworld> np, hope it tests ok
<veebers> wallyworld: ah, I did try deploying something while poking around but maybe looks like it gets logged once the deloy is done? at any rate that helps, should be easy enough to test
<wallyworld> ok, let me know
<veebers> will do
<mup> Bug #1609643 opened: provider/...: make use of Environ.Create to create environ-wide resources like security groups <juju-core:Triaged> <https://launchpad.net/bugs/1609643>
<rogpeppe> fwereade_: you around?
<rogpeppe> fwereade_: just wondering if there's a good reason why the mock clock interface doesn't define the NewTimer method
<dimitern> rick_h_: ping
<dimitern> rick_h_: I was thinking to JFDI https://github.com/juju/juju/pull/5922, since there are only 2 blockers, both Fix Committed - any concerns?
<fwereade_> rogpeppe, I think I did it that way to begin with but was unbothered by a PR that made things slightly cleaner by separating them, but memory is a little fuzzy
<rogpeppe> fwereade_: it's just awkward if you need to use it with something that actually wants to use Reset
<rogpeppe> fwereade_: for example, we're implementing an apiserver pinger and it would be nice to use the mock clock stuff
<rogpeppe> fwereade_: but it's awkward if you can't have Reset
<rogpeppe> fwereade_: i wondered if there was some "that's gonna be hard to do" reason for the omission or just that it was more convenient at the time.
<rogpeppe> fwereade_: one other thing: testing.Timer is exported, as is testing.Timer.Id. any particular reason for that?
<fwereade_> rogpeppe, I'm pretty sure, thinking further, that the only reason we don't have NewTimer is because we didn't need it yet
<rogpeppe> fwereade_: ah, ok
<fwereade_> rogpeppe, sorry, I was confused with the AfterFunc stuff, which was the reason Timer was added
<fwereade_> rogpeppe, (for whatever reason I've never found Timer very helpful myself, but I have no real objections to it, please go ahead and add it if it would be useful to you)
<rogpeppe> fwereade_: ok, cool. it means that normal idiomatic timer code can be easily changed to use mock clocks.
<rogpeppe> fwereade_: i'm going to unexport testing.Timer too, if that sgty
 * dimitern decides to use JFDI
<babbageclunk> dimitern: It's pretty early in the morning for rick_h_, I think.
<dimitern> babbageclunk: true, thought I wasn't sure if he's back home..
<dimitern> babbageclunk: btw which version of emacs are you on?
<babbageclunk> dimitern: oh, good point.
<babbageclunk> dimitern: 24.5.1 apparently
<dimitern> babbageclunk: from the archive or ppa?
<babbageclunk> dimitern: archive.
<dimitern> babbageclunk: ok, thanks - I'm on 25.1.50.3 built from tip a while ago
<dimitern> /me, inspired by ivoks-vim snap is snapping emacs ;)
<rogpeppe> fwereade_: BTW i think the AfterFunc implementation is subtly wrong - i don't think it would work correctly in this scenario: https://play.golang.org/p/X82i5TjzYD
<babbageclunk> dimitern: nice.
<ejat> https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1609707
<mup> Bug #1609707: lxc in Power8 System <lxc (Ubuntu):New> <https://launchpad.net/bugs/1609707>
<babbageclunk> ejat: Hi, did you mean to post that in juju-dev?
<ejat> babbageclunk: sorry mistakenly
<dimitern> ejat: https://linuxcontainers.org/lxd/getting-started-cli/ - have you tried enabling trusty-backports and installing from there?
<ejat> thanks dimitern ... its help
<dimitern> ejat: if it worked, please comment on the bug ;)
<ejat> yeah .. might be closing the bugs as well
<babbageclunk> fwereade_, fwereade__, dimitern: can we do a hangout to talk about axw's comments on http://reviews.vapour.ws/r/5365/?
<dimitern> babbageclunk: sure, let me have a look first though..
<babbageclunk> actually, axw, are you around too?
 * babbageclunk keeps forgetting Perth's in a very different timezone from NZ.
<fwereade__> babbageclunk, they're all basically the same place, right? ;p
<dimitern> babbageclunk: are you now in NZ?
<fwereade__> babbageclunk, (yes, ofc)
<fwereade__> babbageclunk, where?
<ejat> dimitern: in 14.04 lts cant use juju .. but if im trying to use all-in-one installer gets error
<ejat> s/juju/conjure
<dimitern> ejat: I'd suggest asking in #ubuntu-server for conjure-up, folks here are not that familiar with it; also have you checked http://conjure-up.io/ ?
<dimitern> babbageclunk, fwereade__: ok, I can do a HO now if it works for you as well
<babbageclunk> dimitern: No, I'm still in the uk, but I kind of lump axw and other Aussies into the NZ timezone in my head.
<dimitern> babbageclunk: ah :)
<dimitern> babbageclunk: you have a review btw
<babbageclunk> Sorry, was afk - shall we meet in standup?
<dimitern> babbageclunk: let's do it
<anastasiamac> babbageclunk: omg! how could u?  Just kidding :) Brisbane (Ian and I) are 2 hrs behind NZ and Andrew is 2hrs behind us... and it's 7pm for axw :) but who really looks at time here? :D
<babbageclunk> anastasiamac: I mean, I realise that thinking of a huge continent all being in the same timezone as a couple of islands three hours flight away is wrong, I just can't convince my brain of it. ;)
<anastasiamac> babbageclunk: yeah :) time zones are great \o/ for eg, russia has fun fluctuating between having 9 and 11 time zones https://en.wikipedia.org/wiki/Time_in_Russia
<rogpeppe> fwereade__: WIP (I want some tests) but this is my suggestion for updates to the Clock implementation: https://github.com/juju/testing/pull/108
<fwereade__> rogpeppe, thanks
<rogpeppe> fwereade__: ah, just remembered that it needs to fire notifyAlarm on reset.
<fwereade__> rogpeppe, very nice, but I can't help but think it needs tests
<fwereade__> probably did from the beginning really
 * fwereade__ hangs head in shame
<rogpeppe> fwereade__: i totally agree
<rogpeppe> fwereade__: that's why i labelled it as WIP in the PR descr
<rogpeppe> fwereade__: just thought you might want to look initially
<rogpeppe> fwereade__: i think this fixes a few bugs too
<fwereade__> rogpeppe, yeah, much appreciated
<fwereade__> rogpeppe, indeed
<fwereade__> rogpeppe, the urge to LGTM without looking further was strong
<rogpeppe> fwereade__: unfortunately we also need to change juju-core to use the testing.Clock rather than juju/testing.Clock too
<fwereade__> rogpeppe, dammit
<rogpeppe> fwereade__: and juju/clock itself needs updating to change the interface
 * fwereade__ envies google's single-giant-repo more every day
<rick_h_> dimitern: looks like you're all set
<dimitern> rick_h_: yep
<dimitern> rick_h_: it was a low risk change anyway I guess :)
<rick_h_> dimitern: if you get a sec can you peek at https://askubuntu.com/questions/808011/how-to-specify-what-maas-interface-juju-should-use
<rick_h_> dimitern: if you know of a way in 1.25 to do that?
<dimitern> rick_h_: I've looked at it, and almost answered but got distracted
<rick_h_> dimitern: ah cool ty
<fwereade__> oh poo
<fwereade__> babbageclunk, I have a migrations problem and could use an interlocutor, do you have a moment?
<mup> Bug #1609407 changed: remoteFunctionalSuite.TestUsingTCP no such network interface <blocker> <ci> <intermittent-failure> <regression> <unit-tests> <juju-core:Fix Released by wallyworld> <https://launchpad.net/bugs/1609407>
 * fwereade__ will soliloquize; anyone interested should chime in
<fwereade__> I'm adding refcounts to charms; they're contributed by units and applications
<fwereade__> we already have a very similar mechanism: *settings* refcounts, which are similarly contributed by apps and units
<fwereade__> and the underlying mechanism will work just fine if we use the charm globalKey for those refcounts directly, rather than appname#charm
<fwereade__> but (1) we migrate settingsrefcounts, which is suspicious, because it's an implementation detail entirely derived from other app and unit state
<fwereade__> (heh,  (2) is not really important, assuming we check that unit charm urls match their apps', will check whether we do)
<fwereade__> ...ok, I cannot convince myself that it is definitely correct
<fwereade__> so, (2), the settingsrefs migration has potential problems
<fwereade__> and in combination I am reasonably sure that we should simply *not* be representing the refcounts directly in the serialized model, but should be reconstructing them on import
<mbruzek> Do we have any documentation on how the charm store and charm commands work with macaroons and the ubuntu sso? I have a partner of ours having trouble with the commands and I wanted to point them at some documentation about the process.
<rick_h_> natefinch: I'm getting https://pastebin.canonical.com/162328/ trying to use my own build of juju, anything there look familiar e.g. "you did X wrong clearly"?
<rick_h_> natefinch: tried it on two different providers and 4 bootstraps all fail with some # of "after # attempts"
<dimitern> sinzui: hey, I've noticed you changed the milestone on bug 1609343 to beta15, but I forgot to set it to fix committed earlier today, and put the milestone back to beta14
<mup> Bug #1609343: [aws; beta13] Juju can pick subnets from the wrong VPC with spaces constraints specified <ec2-provider> <usability> <juju-core:Fix Committed by dimitern> <https://launchpad.net/bugs/1609343>
<dimitern> since we don't have beta14 out
<sinzui> dimitern: put it back to beta15. your commit is too new
<dimitern> sinzui: ok then
<babbageclunk> fwereade__: back, sorry - I think I follow. What you're saying makes sense to me, and is simpler than having a system where the refcounts are set manually separately on import.
<dimitern> sinzui: done - I thought you're preparing to release b14 and pushing unfinished bugs forward
<sinzui> dimitern: I am the best revision to release is from yesterday. your change is still being tested and has new kinds of failures
<babbageclunk> fwereade__: you could have them still be serialised in the export and then check the serialised ones against the final ones after import?
<fwereade__> babbageclunk, well, we *do* have to set them manually on import, one way or another
<dimitern> sinzui: I've checked the reports but nothing seemed remotely relevant to the fix itself
<sinzui> dimitern: I am not saying your change made the failures. we are seeing new kinds of failures from many possible sources http://reports.vapour.ws/releases/4207
<fwereade__> babbageclunk, we have to write the code either way
<fwereade__> babbageclunk, I'm not really sure which will be easier to get wrong
<babbageclunk> fwereade__: Right, but ordinarily they'll be maintained as units and apps refer to them.
<fwereade__> babbageclunk, (incidentally, is there some code I'm missing that prevents us from trying to export if any charm upgrade is in progress? I feel like it should exist but couldn't find it in a quick scan)
<fwereade__> babbageclunk, indeed
<babbageclunk> fwereade__: Don't know, sorry.
<fwereade__> babbageclunk, hm, I might actually be able to push it all below the layer that migration happens at
<babbageclunk> fwereade__: Right, so then the refcounts are maintained as you restore apps and units?
<fwereade__> babbageclunk, yeah
<babbageclunk> fwereade__: So the serialised refcount could be treated as a check after import.
<babbageclunk> fwereade__: (That could cause problems if the point of the dummp and restore was to upgrade to a version that counted refs differently.)
<fwereade__> babbageclunk, I think I'd still rather it be a calculated property rather than an independent variable
<fwereade__> babbageclunk, and, yeah, it really *does* feel like an implementation detail
<fwereade__> babbageclunk, the only reason we're refcounting is because it's the only technique we've found applicable at this level
<babbageclunk> fwereade__: presumably this is just a performance optimisation? Can you always recalculate it from the apps and units?
<babbageclunk> fwereade__: Or is there some kind of cross-model consideration?
<rick_h_> fwereade__: natefinch dimitern ping for standup
<perrito666> rogpeppe: ping?
<fwereade__> babbageclunk, the refcounting is basically just for integrity
<fwereade__> babbageclunk, am I misunderstanding?
<babbageclunk> fwereade__: The refcount prevents you from deleting something because there are other things referring to it - you could instead go and count all of the things that refer to it, right? I might be misunderstanding also.
<natefinch> fwereade__: github.com/juju/schema.Checker has a "path" argument to Coerce that isn't documented at all.  What is that for? https://godoc.org/github.com/juju/schema#Checker
<fwereade__> babbageclunk, yeah, exactly -- they're relevant only for the txn level
<fwereade__> natefinch, constructing useful descriptions of where you are in a nested structure
<fwereade__> natefinch, coerce failed at config.foo.bar[baz]: not an int
<fwereade__> natefinch, can't remember anything about how it actually works
<natefinch> fwereade__: k
<natefinch> fwereade__: related - Coerce for a FieldMap expects an interface that is a map of <something> to interface... where something can be a string or something with a String() method (possible due to reflection).  Does anyone actually use the stringer form? Do we need to keep that code around?  It makes the implementation a lot messier.
<fwereade__> natefinch, I don't know, I'm afraid
<fwereade__> natefinch, I am having difficulty imagining how that would work without stabbing you in the back on the regular
<natefinch> fwereade__: indeed
<natefinch> fwereade__: I sorta need to make a new version of the library anyway, maybe that's the best way to "fix" it.
<fwereade__> natefinch, if we're having to go that far, should we be dropping coerce and building something up with gojsonschema?
<mup> Bug # changed: 1457575, 1552948, 1566801, 1568845, 1570096, 1575676, 1579010, 1588095, 1599503, 1600054, 1602034, 1602054, 1602716, 1604644, 1604931, 1605050, 1607557
<natefinch> fwereade__: the change to schema is actually backwards compatible... it's adding a notion of dependencies between attributes... here's the PR: http://reviews.vapour.ws/r/5364/
<natefinch> fwereade__: so.. I don't know.  Personally, I'd prefer to use a standard, but I'm afraid that switching to gojsonschema might be a bigger change than we really want to make right now
<fwereade__> natefinch, is there a strong benefit to dependencies vs subdocs? is {foo-bar: x, foo-baz: y} is really a win over {foo: {bar: x, baz: y}}?
<natefinch> fwereade__: No.  I hadn't thought about using a subdoc for it
<fwereade__> natefinch, worth considering
<fwereade__> natefinch, that said we have no shortage of things in the first form already
<fwereade__> natefinch, however, if we *are* making changes, that might stremline things a bit
<natefinch> fwereade__: not sure if that cleans things up or not.  The main use case right now is openstack authentication.  Either you have SSO or username/password, in the latter case, you need to specify username and password, in the former, you don't.
<fwereade__> natefinch, yeah, I see, even if there's an "auth" subdoc you still need the switch
<fwereade__> natefinch, or, hold on
<fwereade__> natefinch, wouldn't you do that with, uh, `schema.Any(ssoChecker{}, userpassChecker{})` or something?
<fwereade__> natefinch, but *that* only works on a subdoc
<fwereade__> natefinch, even so, {auth: {sso: blah}} and {auth: {user: foo, pass: bar}} is nicer than having auth-sso/auth-user/auth-pass all at the top level
<fwereade__> natefinch, and it feels more in tune with the schema package
<fwereade__> natefinch, even if that is a bit tautological
<natefinch> fwereade__: this library is soooo confusing... yes, that would work
<natefinch> fwereade__: though I don't know how to translate that to something you can define with environschema
<fwereade__> natefinch, can an Attr just have an optional Checker field?
<natefinch> fwereade__: not really.. Attr is just a serialization schema... you can't really put an arbitrary piece of code in there
<fwereade__> natefinch, ...then the path of least resistance maybe starts to look like a Schema field with some jsonschema in there?
<mup> Bug #1609818 opened: WorkerSuite.TestDelayedUpdateError timeout no more updates for you <ci> <intermittent-failure> <regression> <unit-tests> <juju-core:Triaged> <https://launchpad.net/bugs/1609818>
<natefinch> fwereade__: the path of least resistance is to use the code that I've already written :)
<fwereade__> natefinch, might be a local maximum... it feels like schema is a fairly significant source of friction here
<natefinch> fwereade__: that may be fair
<mup> Bug #1609879 opened: juju2 says to destroy-model --force when using --keep-broken <juju-core:New> <https://launchpad.net/bugs/1609879>
<babbageclunk> fwereade__: a state.LinkLayerDevice has (potentially) multiple addresses associated with it, but params.NetworkConfig (and network.InterfaceInfo) have only one address...
<babbageclunk> fwereade__: Should I pick an address or have multiple interface infos coming back?
<babbageclunk> fwereade__: (Might be more for dimitern but he's not around.)
 * babbageclunk will re-ask tomorrow.
<mup> Bug #1609893 opened: juju status returns ERROR not logged in <juju-core:New> <https://launchpad.net/bugs/1609893>
<mup> Bug #1609893 changed: juju status returns ERROR not logged in <juju-core:New> <https://launchpad.net/bugs/1609893>
<rick_h_> natefinch: katco or all other people smarter than me, trying to use my juju build I get a failed bootstrap, but damn if everything doesn't seem to work out per logs/etc. https://pastebin.canonical.com/162345/plain/
<rick_h_> I'm really open to ideas from folks that know more.
<natefinch> rick_h_: looking
<tvansteenburgh> hey core folks, i have a websocket client connected to a juju api server, but i don't know which version of juju i'm connected to. what's the easiest way to determine that?
<katco> rick_h_: try turning on tracing and --debug while bootstrapping?
<rick_h_> katco: that is with --debug
<katco> rick_h_: i see: "/home/rharding/src/juju/bin/juju bootstrap --upload-tools --keep-broken test" ?
<rick_h_> katco: ah sorry, I pasted from a previous run
<katco> rick_h_: ah
<katco> rick_h_: is it possible to set the log level to trace at bootstrap time?
<rick_h_> katco: will look for my next run
<natefinch> tvansteenburgh: hmm.. AFAIK we don't have a dedicated "version" endpoint (which is a shame).  I think the GUI has some heinous hacks to figure it out, but not entirely sure.
<tvansteenburgh> natefinch: i was afraid that was the answer :/
<mup> Bug #1609893 opened: juju status returns ERROR not logged in <juju-core:New> <https://launchpad.net/bugs/1609893>
<mup> Bug #1609896 opened: Race in github.com/juju/juju/rpc/server <ci> <intermittent-failure> <race-condition> <regression> <unit-tests> <juju-core:Triaged> <https://launchpad.net/bugs/1609896>
<mup> Bug #1609910 opened: Juju API lacks version endpoint <juju-core:New> <https://launchpad.net/bugs/1609910>
<mup> Bug #1609910 changed: Juju API lacks version endpoint <juju-core:New> <https://launchpad.net/bugs/1609910>
<natefinch> rick_h_: got some time to talk?  I got some feedback from william on my pr that needs discussion
<natefinch> fwereade__: I presume you're long gone?
<rick_h_> natefinch: I've got a call in 7 if we can do it in there
<rick_h_> natefinch: https://hangouts.google.com/hangouts/_/canonical.com/rick?authuser=1
<natefinch> sure
<mup> Bug #1609910 opened: Juju API lacks version endpoint <juju-core:New> <https://launchpad.net/bugs/1609910>
<natefinch> gah... gojsonschema has almost zero documentation.
<katco> any juju architecture guru types around? fwereade__?
<niedbalski> We are trying out beta14 and found this serious problem: http://pastebin.ubuntu.com/22225558/
<niedbalski> sinzui, alexisb ^^ is this expected?
<sinzui> niedbalski: officiall we don't support that
<sinzui> niedbalski: We don't even test uprades since juju is breaking behavious
<niedbalski> sinzui, ok. So it might be a required to bootstrap this env again?
<sinzui> niedbalski: yes :/
<niedbalski> sinzui, ok
<mgz> niedbalski: yup, 'fraid so, we don't do upgrades between betas
<thumper> snow day here, kids all at home
<thumper> barely 2cm of snow and the city shuts down
<niedbalski> mgz, sinzui thanks guys.
<mup> Bug #1609980 opened: Juju does not give a clear error when unable to create a loop device on lxd <lxd> <storage> <ui> <juju-core:Triaged> <https://launchpad.net/bugs/1609980>
<mup> Bug #1609994 opened: Race in github.com/juju/loggo global <blocker> <ci> <race-condition> <regression> <unit-tests> <juju-core:Triaged> <https://launchpad.net/bugs/1609994>
<mup> Bug #1609994 changed: Race in github.com/juju/loggo global <blocker> <ci> <race-condition> <regression> <unit-tests> <juju-core:Triaged> <https://launchpad.net/bugs/1609994>
<perrito666> now, this is new: /home/hduran/Develop/golang/go1.6.2/pkg/tool/linux_amd64/link: running gcc failed: fork/exec /usr/bin/gcc: cannot allocate memory
<mup> Bug #1609994 opened: Race in github.com/juju/loggo global <blocker> <ci> <race-condition> <regression> <unit-tests> <juju-core:Triaged by thumper> <https://launchpad.net/bugs/1609994>
<thumper> menn0: http://reviews.vapour.ws/r/5376/
<menn0> thumper: looking
<thumper> menn0: 1:1 ?
<menn0> thumper: ok
<thumper> wallyworld, menn0: http://reviews.vapour.ws/r/5377/
<wallyworld> thumper: +1
<thumper> landing
<thumper> seems we have no on call reviewer today
<thumper> http://reviews.vapour.ws/r/5345/diff/#
<thumper> menn0: http://reviews.vapour.ws/r/5369/diff/# updated to use 1500ms max dealy as discussed
<menn0> thumper: looking
<menn0> thumper: it just occurred to me that the tests could be simpler if instead of injecting a Clock, retry.Call was injected
<menn0> thumper: that way you just need to check that retry.Call is given the right args
<menn0> thumper: and the tests aren't checking retry.Call's behaviour
<menn0> thumper: not saying you need to change it, but just an idea for future work like this
 * thumper nods
<thumper> that's a thought
<menn0> thumper: ship it
<menn0> thumper: does that loggo race really need to be a blocker?
<menn0> master was open when I submitted a PR but by the time it ran it was blocked again
<mgz> now that's what I call a race
<menn0> mgz: haha
<menn0> thumper: I just realised that MM ids have an nice (unintentional) property: they're globally unique across all controllers (because of the was sequences are migrated)
<wallyworld> menn0: when the PR lands. we'll remove the blocker tag. a race in a 3rd party lib should not stop 15 people from landing work
<menn0> wallyworld: +1
<wallyworld> menn0: the PR to update deps just got an intermittent error, i resubmitted, hopefully will land this time
<mup> Bug #1610007 opened: Juju 2.0-beta14: AllWatcher deltas on unclean model do not  report proper application state <kanban-cross-team> <landscape> <juju-core:New> <https://launchpad.net/bugs/1610007>
<mup> Bug #1610012 opened: can't migrate a model off a controller twice <migration> <juju-core:New for menno.smits> <https://launchpad.net/bugs/1610012>
<thumper> um...
<thumper> I don't think that is a bug
<thumper> ok, the heading is confusing
<mup> Bug #1610012 changed: can't migrate a model off a controller twice <migration> <juju-core:New for menno.smits> <https://launchpad.net/bugs/1610012>
#juju-dev 2016-08-05
<mup> Bug #1610012 opened: can't migrate a model off a controller twice <migration> <juju-core:New for menno.smits> <https://launchpad.net/bugs/1610012>
<anastasiamac> menn0: thumper: could we do a quick ho re:migration?
<anastasiamac> m happy to talk to one of u, if getting time with both is difficult
 * thumper is about to go walk the dog
<thumper> wallyworld: blocker tag removed
<menn0> anastasiamac: can it wait until later today please? i'm trying to get some of these bugs fixed
<wallyworld> huzah
<anastasiamac> menn0: of course \o/ ping when u have a chance
<menn0> anastasiamac: will do
<wallyworld> thumper: here's the muxtex bit that needs changing const prefix = "@/var/lib/juju/mutex-"
<wallyworld> *mutex
<wallyworld> bug 1604967
<mup> Bug #1604967: Apparmor denies bind to abstract unix sockets such as @/var/lib/juju/mutex-/store-lock <snapd-interface> <Snappy:Triaged by jdstrand> <https://launchpad.net/bugs/1604967>
<wallyworld> if we change the path, i don't think we'll need the apparmor change
<wallyworld> will need to test
<thumper> what abstract sockets does snappy apparmor allow?
<thumper> wallyworld: ?
<thumper> any?
<thumper> wallyworld: looks like a bug on snappy not juju
<wallyworld> thumper: not a snappy bug, but a profile issue which can be solved by using path that doesn'nt need an apparmor tweak
<wallyworld> i'll test
<wallyworld> we got advice from the snappy folds IIRC that's what we needed to do
<menn0> wallyworld or thumper: http://reviews.vapour.ws/r/5378/
<menn0> or anastasiamac or axw: ^^^ :)
<axw> menn0: looking
<axw> wallyworld: thanks for hitting merge. doesn't matter now, but I was going to merge the end of the pipeline since it includes all the other commits
<wallyworld> oops
<axw> wallyworld: all good :)  I'll do it with the other one
<axw> menn0: LGTM
<menn0> axw: thank you
<axw> menn0: can you please review this trivial one: http://reviews.vapour.ws/r/5379/. I had added a CloudSpec API to provisioner, but it's not needed now after your changes to use environ-tracker
<menn0> axw: looking
<menn0> axw: done
<axw> menn0: thanks
<niedbalski> dooferlad, ping
<niedbalski> dooferlad, dimitern https://bugs.launchpad.net/juju-core/+bug/1610037
<mup> Bug #1610037: Juju2 beta14, missing network stanzas. <sts-needs-review> <juju-core:New> <https://launchpad.net/bugs/1610037>
<mup> Bug #1610037 opened: Juju2 beta14, missing network stanzas. <sts-needs-review> <juju-core:New> <https://launchpad.net/bugs/1610037>
<menn0> yes!
 * menn0 quashes migration bugs
<hatch> If I've found, what I believe to be a regression would you prefer I re-open an old bug or create a new one?
<anastasiamac> niedbalski: dooferlad is on paternity leave :) dimitern will be online in about 4+ hrs \o/
<anastasiamac> hatch: dpends on what bug u r planning to re-open..
<hatch> anastasiamac: https://bugs.launchpad.net/juju-core/+bug/1566589
<mup> Bug #1566589: ERROR cannot find network interface "lxcbr0": route ip+net: no such network interface <juju-core:Fix Released by tycho-s> <https://launchpad.net/bugs/1566589>
<hatch> There doesn't appear to be a way to specify a custom lxd network interface name
<anastasiamac> hatch: re-open please \o/
<hatch> even when setting the default profile to use something else it still tries to use lxcbro
<hatch> allllrighty, I'm just running one last test here then I'll re-open
<hatch> thanks
<anastasiamac> hatch: please advice why u r re-opening in the bug comments :)
<hatch> oh definitely - I'm also trying to use juju to bootstrap lxd's while running in an lxd itself
<hatch> so it's a little funky network setup wise as it is
<anastasiamac> hatch: \o/ the more info, the better to diagnose :)
<mup> Bug #1566589 opened: ERROR cannot find network interface "lxcbr0": route ip+net: no such network interface <juju-core:Triaged by rharding> <https://launchpad.net/bugs/1566589>
<thumper> axw: do both volumes and filesystems have settings?
<thumper> axw: or was it just storage?
<axw> thumper: neither. they both refer to "storage pools", and pools are defined in settings
<thumper> axw: through settings on the state.Storage type?
<thumper> hmm...
<axw> thumper: storage/poolmanager takes a settings manager, which state implements
<thumper> axw: I think what we really need to do is to get to the state where we have all the storage bits at least mostly handled, then create an environment where all these moving parts are created, then dump it and check the output
<thumper> until then, I'm kinda guessing
<axw> wallyworld thumper: have you seen this before? not sure if it's something I've caused... http://juju-ci.vapour.ws:8080/job/github-merge-juju/8636/artifact/artifacts/windows-out.log/*view*/
 * thumper looks
<wallyworld> axw: that's due to other recent work to remove supported ciphers i believe
<thumper> axw: that is an intermittent failure
<thumper> but all the extra log spam is new
<axw> ok, thanks
<natefinch> ug, did I leave log spam in?  Sorry.
<natefinch> oh oh... I think I know what that is.. shit.  I edited the stdlib... I should probably put that bad
<natefinch> back
<menn0> wallyworld: do you have time to give thumper and I (and anyone else) a quick snappy intro?
<menn0> wallyworld: I'm pretty much ready to send this test build out
<wallyworld> menn0: sorry, missed ping, was out having 1:1 with anastasia
<wallyworld> menn0: i need to do some work to tools upload (which i am doing now). if you can wait till monday....
<menn0> wallyworld: all good... I figured out most of it myself
<menn0> wallyworld: installing snapcraft from source was the hardest part
<wallyworld> i had to do that too today - had to bring in some python deps
<wallyworld> menn0: the tools work i am doing is do stuff "just works" for snaps without upload-tools
<wallyworld> and also cleans stuff up a bit - there's a bit of cruft there, and i reckon i can see a suspect ofr that bootstrap version issue recently
<menn0> wallyworld: ofr?
<wallyworld> *for
<wallyworld> you know i can't type :-)
<wallyworld> axw: i added a few things, plus a bit of info on the other config work
<wallyworld> i'll do another pass a bit later
<axw> wallyworld: thanks. should I add in reacting to credential changes to in-scope work?
<wallyworld> axw: i did that already, maybe needs a few more words
<axw> wallyworld: ah I see. no that's fine
<wallyworld> axw: i also added the update clouds worker
<fwereade_> menn0, what PR did you want me to look at? can't seem to get to reviews.vapour.ws
<fwereade_> menn0, and if you have a moment to look at https://github.com/juju/juju/pull/5932 before the weekend, that would be awesome
<fwereade_> menn0, (also, I'm dumb, but I couldn't find the code that prevents us from migrating mid-charm-upgrade: can you point me to it?)
<fwereade_> thumper, if you're around you too could address my last 2 messages :)
<thumper> meetingology: we might not have it yet
<meetingology> thumper: Error: "we" is not a valid command.
<thumper> fwereade_: see above mse
<thumper> msg
<thumper> bah humbug
<fwereade__> wallyworld, long shot: do you recall what the bits starting at about state/charm_test.go:250 were testing? am confused by the non-txn ops
<wallyworld> fwereade__: not sure off hand without a bit of thought. i don't recognise the code, it looks like it was moved from somewhere else
<mup> Bug #1610169 opened: invalid lxd config after update to 2.0-beta14-0ubuntu1~16.04.2~juju1 <juju-core:New> <https://launchpad.net/bugs/1610169>
<babbageclunk> fwereade__, dimitern: a state.LinkLayerDevice can have multiple addresses, but a network.InterfaceInfo (and a params.NetworkConfig) only has one. Do s
<babbageclunk> Oops
<babbageclunk> Do you think I should produce multiple NetworkConfigs for a device with multiple addresses? Or pick one somehow?
<dimitern> babbageclunk: multiple
<babbageclunk> dimitern: Yeah, I was leaning towards that. Cool, thanks.
<dimitern> babbageclunk: more verbose representation is used in network/ (at least for now)
<dimitern> babbageclunk: there are tests (see networkingcommon) to convert between those IIRC
<dimitern> babbageclunk: in case you're wondering why - network.InterfaceInfo came to be as a way to have the full config per NIC needed to render /e/n/i
<babbageclunk> dimitern: Yeah, I guessed that from the fields :)
<dimitern> :)
<dimitern> hatch: unlikely, but are you around? re bug 1566589
<mup> Bug #1566589: ERROR cannot find network interface "lxcbr0": route ip+net: no such network interface <juju-core:Fix Released> <https://launchpad.net/bugs/1566589>
<dimitern> rick_h_: ^^ closed that one and unassigned you from it, FYI
<mup> Bug #1566589 changed: ERROR cannot find network interface "lxcbr0": route ip+net: no such network interface <juju-core:Fix Released> <https://launchpad.net/bugs/1566589>
<fwereade__> babbageclunk, I've just thought of a problem
<babbageclunk> fwereade__: oh good
<fwereade__> babbageclunk, we really shouldn't delete the machine document while it's got outstanding resources
<fwereade__> babbageclunk, that might be the only thing keeping the model alive
<fwereade__> babbageclunk, not the end of the world
<fwereade__> babbageclunk, but it means that the provisioner should now be explicit about not *removing* machines, but on handing responsibility to something else once the instance has gone away and unblocked it
<mup> Bug #1566589 opened: ERROR cannot find network interface "lxcbr0": route ip+net: no such network interface <juju-core:Fix Released> <https://launchpad.net/bugs/1566589>
<fwereade__> babbageclunk, and then the "I've finished with machine X" messages can trigger the actual *remove*
<fwereade__> babbageclunk, one upside there is that we never have parallel responsibility for the machine, so whatever's responsible can write status without worrying
<fwereade__> babbageclunk, how badly have I wrecked your day..?
<babbageclunk> fwereade__: So we end up splitting machine.Remove into two parts - one that does everything except removing addresses, link layer devices and the actual remove, and the other part that really removes everything.
<rick_h_> dimitern: ty
<fwereade__> babbageclunk, well, I'm wondering if it's more like `Provisioner.MarkForGC([machine-3-lxd-3])` or whatever name we pick
<fwereade__> babbageclunk, where that txn checks the machine is dead and creates the removal doc for the attention of the watcher
<babbageclunk> fwereade__: like, moderately? :) I just got finished doing it the other way. Haven't had a chance to think through the implications yet - might not actually be much, except that I probably no longer need to move various methods off Machine if we'll still have one at the end.
<babbageclunk> fwereade__: yeah, ok - that makes sense.
<fwereade__> babbageclunk, it definitely hits the fiddly-txn-ops side :( but I think the removals+watch remain the same?
<babbageclunk> fwereade__: yeah, that part is the same. And it's cleaner this way.
<babbageclunk> fwereade__: ok, thanks for the headsup - I'll start switching over to that after lunch, should get something up for review soonish.
<fwereade__> babbageclunk, just added some replies on http://reviews.vapour.ws/r/5366/ fwiw
<fwereade__> babbageclunk, thanks :)
<mup> Bug #1566589 changed: ERROR cannot find network interface "lxcbr0": route ip+net: no such network interface <juju-core:Fix Released> <https://launchpad.net/bugs/1566589>
<babbageclunk> fwereade__: those review comments are enlightening, thanks!
 * babbageclunk lunches
<fwereade__> does anyone know why we might rewrite the revisions of charmstore charms "to handle the revision differences between unpublished and published charms in the store"?
<fwereade__> rogpeppe, rick_h_ ^^
<fwereade__> babbageclunk, cool, yw :D
<rogpeppe> fwereade__: what's the context?
<fwereade__> rogpeppe, migrations
<rogpeppe> fwereade__: model migration?
<fwereade__> rogpeppe, apparently we might have charm archives with revisions that don't match their url, and that worries me
<fwereade__> rogpeppe, yeah
<fwereade__> rogpeppe, and the comment mentions the charm store -- and that's all I know :)
<rogpeppe> fwereade__: where does that remark come from?
<fwereade__> rogpeppe, apiserver/charms.go:262
<fwereade__> rogpeppe, I think menn0's been gone for a while, it's nbd, I will mail him if it doesn't resonate with you
<rogpeppe> fwereade__: i'm looking at the code. gimme a minute or two.
<fwereade__> rogpeppe, cheers :)
<rogpeppe> fwereade__: i don't think revisions in charm archives are a thing any more
<rogpeppe> fwereade__: i don't think the code should ever be looking at them
<rogpeppe> fwereade__: it was always a bad idea
<fwereade__> rogpeppe, strongly agree
<fwereade__> rogpeppe, ok, I had also sorta thought that; I will continue to poke away at it in that light
<rogpeppe> fwereade__: it looks like api.Client.UploadCharm always attaches a revision
<rogpeppe> fwereade__: so that logic is pretty much irrelevant AFAICS
<fwereade__> rogpeppe, well... that would explain it, I suppose
<rogpeppe> fwereade__: i'd suggest changing it so that it fails if there's no revision form field specified
<fwereade__> rogpeppe, yeah, that sounds sane to me
<rogpeppe> fwereade__: given that the charm package is still "unstable", i'd really like to remove the whole notion of revision from charm.Charm
<fwereade__> rogpeppe, +1eMAXINT
<rogpeppe> fwereade__: :)
<rogpeppe> fwereade__: it shouldn't be hard to change in the charm package itself :)
<fwereade__> rogpeppe, I'm pretty sure it'd be worth it despite the downstream pain
<rogpeppe> fwereade__: agreed
<rogpeppe> fwereade__: feel free to go for it
<fwereade__> ...you know, we really *don't* use .Revision() very much at all
<fwereade__> I can certainly excise its use from juju/juju
<fwereade__> rogpeppe, do you have a picture of how it'd impact other dependencies? how much stuff would I plunge into unbuildable catastrophe if core were suddenly using a new Charm interface?
<rogpeppe> fwereade__: the only real impact would be on the semantics of local repos
<rogpeppe> fwereade__: but we don't support local repos like that any more anyway really
<rogpeppe> fwereade__: and i bet no-one relies on the current semantics, which are bizarre
<fwereade__> rogpeppe, yeah
<fwereade__> rogpeppe, what about name?
<rogpeppe> fwereade__: i'd love to get rid of Name too
<rogpeppe> fwereade__: the charm store never uses it, or Revision
<fwereade__> rogpeppe, ...and unless we *actually get rid of* Name+Revision we have this opportunity for mismatch everywhere we go
<rogpeppe> fwereade__: exactly
<rogpeppe> fwereade__: putting the name and revision in the content is a silly idea
<fwereade__> rogpeppe, no argument here
<rogpeppe> fwereade__: i wish we'd persuaded gustavo back in the day...
<fwereade__> :)
<anastasiamac> dimitern: thank you for looking at this lxdbr0 bug earlier \o/ do u think that this is related? https://bugs.launchpad.net/juju-core/+bug/1610169
<mup> Bug #1610169: invalid lxd config after update to 2.0-beta14-0ubuntu1~16.04.2~juju1 <juju-core:New> <https://launchpad.net/bugs/1610169>
 * dimitern managed wade through maas'es bind9 config and fix streams.canonical.com to 127.0.0.1 \o/  
<sinzui> rick_h: bug 1610243 is a blocker. The azure provider is broken. Juju cannot bootstrap
<mup> Bug #1610243: Azure provider storage account not found <azure-provider> <blocker> <bootstrap> <ci> <regression> <juju-core:Triaged> <https://launchpad.net/bugs/1610243>
<rick_h_> sinzui: rgr looking
<mup> Bug #1610238 opened: UnitSuite.TestWithDeadUnit timed out waiting for agent to finish <ci> <intermittent-failure> <regression> <unit-tests> <juju-core:Triaged> <https://launchpad.net/bugs/1610238>
<mup> Bug #1610239 opened: Race in src/gopkg.in/mgo.v2 <ci> <intermittent-failure> <race-condition> <regression> <unit-tests> <juju-core:Triaged> <https://launchpad.net/bugs/1610239>
<mup> Bug #1610243 opened: Azure provider storage account not found <azure-provider> <blocker> <bootstrap> <ci> <regression> <juju-core:Triaged> <https://launchpad.net/bugs/1610243>
<tvansteenburgh> anyone know what would cause only 2 facades to be reported (UserManager and ModelManager) when logging in to the api?
<tvansteenburgh> (juju2)
<tvansteenburgh> well actually i'm getting more than 2, but the Client facade is missing and i'm not sure why that would be the case
<mup> Bug #1609994 changed: Race in github.com/juju/loggo global <ci> <race-condition> <regression> <unit-tests> <juju-core:Fix Released by thumper> <https://launchpad.net/bugs/1609994>
<tvansteenburgh> Login response: {'server-version': '2.0-beta12', 'facades': [{'name': 'AllModelWatcher', 'versions': [2]}, {'name': 'Cloud', 'versions': [1]}, {'name': 'Controller', 'versions': [3]}, {'name': 'MigrationTarget', 'versions': [1]}, {'name': 'ModelManager', 'versions': [2]}, {'name': 'UserManager', 'versions': [1]}], 'server-tag': 'model-d63ff9c4-3d46-464b-8c98-9459afbef958', 'servers': [[{'type': 'ipv4', 'scope': 'local-cloud', 'por
<tvansteenburgh> hmm, do i need to login to a specific model endpoint to get the Client facade perhaps?
<natefinch> tvansteenburgh: yeah, I think that's a new thing - they split off the controller API from the model API
<mup> Bug #1609994 opened: Race in github.com/juju/loggo global <ci> <race-condition> <regression> <unit-tests> <juju-core:Fix Released by thumper> <https://launchpad.net/bugs/1609994>
<mup> Bug #1609994 changed: Race in github.com/juju/loggo global <ci> <race-condition> <regression> <unit-tests> <juju-core:Fix Released by thumper> <https://launchpad.net/bugs/1609994>
<mup> Bug #1610254 opened: model-migration: Mongo db is not in an expected state <ci> <model-migration> <mongodb> <juju-core:Triaged> <https://launchpad.net/bugs/1610254>
<mup> Bug #1610255 opened: Cannot start bootstrap instance: DB is locked <bootstrap> <ci> <lxd-provider> <regression> <juju-core:Triaged> <https://launchpad.net/bugs/1610255>
<mup> Bug #1610254 changed: model-migration: Mongo db is not in an expected state <ci> <model-migration> <mongodb> <juju-core:Triaged> <https://launchpad.net/bugs/1610254>
<mup> Bug #1610255 changed: Cannot start bootstrap instance: DB is locked <bootstrap> <ci> <lxd-provider> <regression> <juju-core:Triaged> <https://launchpad.net/bugs/1610255>
<rick_h_> natefinch: standup ping take 4
<mup> Bug #1610254 opened: model-migration: Mongo db is not in an expected state <ci> <model-migration> <mongodb> <juju-core:Triaged> <https://launchpad.net/bugs/1610254>
<mup> Bug #1610255 opened: Cannot start bootstrap instance: DB is locked <bootstrap> <ci> <lxd-provider> <regression> <juju-core:Triaged> <https://launchpad.net/bugs/1610255>
<mup> Bug #1610260 opened: AWS Error fetching security groups EOF/timeout <bootstrap> <ec2-provider> <intermittent-failure> <juju-core:Incomplete> <juju-core 1.25:Triaged> <https://launchpad.net/bugs/1610260>
<niedbalski> dimitern, ping
<niedbalski> dimitern, re: 1610037, check: https://pastebin.canonical.com/162396/
<dimitern> niedbalski: otp, will get back to you shortly
<dimitern> niedbalski: I might be missing something, but I still can't see /e/n/i from the container in your paste
<dimitern> niedbalski: ah, sorry - line 287
<dimitern> niedbalski: there do those lines come from, e.g.: 'post-up ifup bond0:1' ?
<niedbalski> dimitern, that's the host deployed by maas.
<dimitern> niedbalski: so maas/curtin rendered that?
<niedbalski> dimitern, yep; here is the config on the maas-ui, fyi: http://pasteboard.co/4O4UwMdWX.png
<hatch> dimitern: thanks for the response on the bug. I noticed the beta14 email quite late and was going to confirm it in the morning. You beat me to it :)
<dimitern> niedbalski: can you also paste /var/log/cloud-init-output.log and /var/log/juju/machine-0.log please?
<dimitern> hatch: ;) no worries
<hatch> dimitern: this weekend I'll resume my testing on running Juju in an LXD where the nested lxd's also get an ip on the network
 * hatch crosses fingers
<niedbalski> dimitern, sure.
<dimitern> hatch: is this on maas?
<dimitern> hatch: or lxd provider?
<hatch> dimitern: nope, just a raw Xenial box: Metal > LXD > Juju > LXD
<hatch> I had the both LXD's in that diagram getting the ip's but Juju wouldn't use them
<hatch> so hoping it will now
<dimitern> hatch: I *think* you might be out of luck, but if you give me a few more details about what you want to test I can perhaps save you some time if it won't ever work ;)
<dimitern> hazmat: so a plain xenial, you ssh into it, apt install juju-2, bootstrap lxd lxd, and then what?
<dimitern> sorry hazmat ;) hatch: ^^
<hatch> dimitern: so I've supplied a bridge to the outer LXD's so that they get a real IP following jrwren's blog post. That all worked well. Then inside that LXD I created yet another bridge pointing to the parent containers lxd and then IT was receiving ip's from DHCP
<hatch> however jujud kept using the 10. ip instead of the br0 ip
<dimitern> hatch: so now you can customize which bridge to use for lxd provider before bootstrapping, but changing the one on the default LXD profile (i.e. apt install lxd, configure, then bootstrap)
<dimitern> hatch: once bootstrapped though, juju will insist on rendering a default /etc/default/lxd-bridge with lxdbr0 using another subnet than the one the controller container is on
<natefinch> rick_h_: fwereade__ was a big help in finding an way forward that we can do incrementally.  Basically we'll tack jsonschema on the side of what we already have in environschema, and we can incrementally move things over to use that, rather than needing to do a big bang change.
<rick_h_> natefinch: <3 ty fwereade__ and sounds like a solid pla
<rick_h_> plan
<dimitern> hatch: to make it work, you'll need to manually go to each nested container and change the bridge config
<hatch> dimitern: that's terrible :)
<hatch> dimitern: so my goal is to run Juju in an LXD and have each LXD it creates to get a real IP on the network so that I can actually access them
<hatch> am I out of luck?
<dimitern> hatch: you can do some iptables magic on the controller LXD container to let that happen
<rick_h_> hatch: so you need juju to support remote lxd servers so juju can be in a lxd and talk to other lxd on the root machine but that's not there atm
<hatch> rick_h_: yeah that was my first idea, which, as you just mentioned doesn't work :D
<babbageclunk> fwereade__: Is it legit to run multiple machine.Remove() transactions in response to a single CompleteMachineRemoval(ids) call, or should I build up a big transaction from each of the machines remove ops?
<hatch> dimitern: I had it working using `redir` but that was manual and painful :D
<babbageclunk> fwereade__: s/from each/with each/
<hatch> I was hoping for an easy DHCP ip :)
<dimitern> hatch: assuming the above setup, on machine-0 (LXD controller container) you'll have 1 IP from the bridge you configured on the host machine (e.g. 10.42.0.12)
<dimitern> hatch: then on that same machine, if you enable IP forwarding (sudo sysctl -w net.ipv4.ip_forward=1 && echo 'net.ipv4.ip_forward = 1' | sudo tee -a /etc/sysctl.conf), and add this rule:
<dimitern> hatch: sudo iptables -t nat -A POSTROUTING -s 10.33.0.0/24 ! -d 10.33.0.0/42 -j MASQUERADE
<dimitern> hatch: 10.33.0.0/24 is the LXD network inside the controller LXD container, while 10.42.0.0/24 is the one on its host
<hatch> interesting
<dimitern> hatch: this will allow hosted containers on the controller LXD to access outside with NAT, without being on the same network as the controller
<dimitern> also - no need to touch anything else on each nested LXD machine
<hatch> dimitern: so how would I access those lxd's from my desktop?
<dimitern> hatch: but I'm trying it now to double check I'm not misaken
<dimitern> hatch: ah :)
<hatch> dimitern: using what I currently have I can use redir on the host lxd pointing to the child lxd and it 'works'
<hatch> no fancy iptables stuff necessary
<hatch> but that's a manual step
<hatch> IF I could get the nested lxd's a dhcp ip I'd be golden
<hatch> which, I can do, but Juju doesn't use it :)
<hatch> it uses the internal 10. ip which it can't access after I break it ;)
<dimitern> hatch: you can only get dhcp for containers on the lxd provider anyway
<dimitern> only on maas the ux is better atm
<hatch> dimitern: ok so what I'll do over the weekend is outline in detail what I'm trying to do and the steps I've taken and where I'm hitting roadblocks and then maybe we can work towards making the experience better so that this workflow is a Juju reality
<dimitern> hatch: that'd be great! thanks, I'll be happy to try to replicate your setup and chat about improving the UX!
<hatch> great thanks
<dimitern> np ;)
<dimitern> niedbalski: ping (re logs?)
<katco> fwereade__: here's the fix if you're interested: http://reviews.vapour.ws/r/5384/
<katco> natefinch: could use a review when you get 'round to it ^^
<natefinch> katco: will do
<natefinch> rick_h_: what was it you needed me to review?
<rick_h_> natefinch: /me looks at board
<rick_h_> natefinch: oh, to fill in for OCR a bit since Michael is out today
<rick_h_> natefinch: so I guess a quick run of things that might have come in overnight from the other folks
<rick_h_> natefinch: fwereade__'s branches we're going to ask the migration folks to review
<natefinch> rick_h_: ok, sure. Wanted to make sure there wasn't something in particular
<rick_h_> natefinch: but you're free to poke at it if you'd like to be a +2 on it
<natefinch> rick_h_: cool
<rick_h_> natefinch: looks like katco's branch just hit the review lane
<rick_h_> natefinch: so that would be <3 to help quickly turn that around
<natefinch> will do
<fwereade__> katco, I have unhelpful comments on http://reviews.vapour.ws/r/5384/ I'm afraid
<fwereade__> katco, well, hopefully not unhelpful
<katco> fwereade__: lol k tal
<fwereade__> katco, I think the bad scenario is where we do have a misbehaving cloud, and *every* machine we try to provision goes through the same backoff process, uninterruptibly, and after N minutes reports its status and has the provisioner move on to start the process with the next
<katco> fwereade__: yeah that is problematic. really not sure if i should try and tackle that here, or in a follow-up
<katco> fwereade__: i mean i guess in a sense this would be "breaking" things by fixing things
<fwereade__> katco, yeah, this is a fragile-ecosystem sort of concern
<katco> fwereade__: if i were to set status on every retry (as we discussed, sorry), is that enough? or would the user be just as frustrated...
<fwereade__> katco, that is a good mitigation, for sure -- can we extract timings? if we say when we will, and do what we say, that is at least *something*
<fwereade__> katco, even if juju is not doing the smartest thing, you can see what it *is* doing
<katco> fwereade__: yeah, they're defined explicitly in i think provisioner.go
<fwereade__> katco, which is a lot better than a silent magic box
<fwereade__> katco, yeah that sounds right
<katco> fwereade__: so, do that, land it, and then take a more comprehensive look at retries, and specifically how scheduling works here?
<fwereade__> katco, what's the total delay per machine that we'll actually have before we move on?
<katco> fwereade__: 3 retries of 10 seconds, so 30s
<fwereade__> katco, ah, that's not so bad
<fwereade__> katco, mm, I wonder if it's be easy to make jupsen cut off access to provider endpoints... mattyw?
<mattyw> fwereade__, not currently, but it could be added quite easily I think
<mattyw> fwereade__, you can cut off the controller from all traffic, but that's not advisable
<fwereade__> katco, so, ok, I think I am comfortable that what we currently have is a sane and conservative strategy, but (1) the drawbacks, and the havoc that will be wreaked if we tweak the strategy, *must* be documented in shades of terror and woe; and (2) I think it would be a good idea to cut off provider access and tell the controller to deploy a bunch of machines, and see how it actually feels in practice
<katco> fwereade__: ok, i'll have to figure out how to do that
<fwereade__> katco, do take a look at jupsen
<fwereade__> katco, I bet you could hack it quickly and situationally with ease
<katco> fwereade__: i.e. implement it in jupsen?
<fwereade__> katco, it's just the first thing that springs to mind for inducing netsplits in juju
<fwereade__> katco, I barely remember the internals though so I'm not sure
<katco> fwereade__: responded to a few of your comments; require feedback
<natefinch> katco: I'm reviewing your branch now BTW
<katco> natefinch: cool
<natefinch> katco: do we not care about the task dying in the middle anymore?  We used to check task.catacomb.Dying()
<katco> natefinch: oh jees... i had that in there, but i've refactored this thing like 3 times. it must have fallen out. the select statement should still be in there
<natefinch> katco: heh, yep, I've done the same thing.
<natefinch> I wish that kind of thing were easier to test for.... there should be a test that kills it in the middle and ensures it behaves correctly... but that's really tricky.
<katco> natefinch: if the code were structured to be unit testable, it wouldn't be so hard
<katco> natefinch: but as it sits, yeah. it would be some kind of weirdly shaped full-stack test
<dimitern> fwereade__: are you still there btw?
<fwereade__> dimitern, o/, sort of
<fwereade__> katco, I think I've fed back
<katco> fwereade__: ta
<natefinch> katco: published some comments
<katco> natefinch: ta
<fwereade__> katco, natefinch: IIRC menn0? was just doing some work to extract the environ dependency which is one of the big ones that drags heaps of sludge with it
<dimitern> fwereade__: am I right to think most workers expect apicaller resource, which in turn depends on the upgrade gate to be lifted?
<fwereade__> dimitern, ummmmmmm I forget the exact upgrade dance
<fwereade__> dimitern, there's a couple of layers remember
<fwereade__> dimitern, we need to complete state upgrades before letting the apiserver at it
<dimitern> fwereade__: I'm looking at bug 1607749 and so far it seems we have a catch 22 where the proxyupdater can't start because the upgrader haven't opened the gate yet, but it NEEDS a proxy to do that
<mup> Bug #1607749: juju bootstrap fails with MAAS trunk and juju (beta12 behind a proxy too) <bootstrap> <maas-provider> <juju-core:In Progress by dimitern> <https://launchpad.net/bugs/1607749>
<fwereade__> dimitern, but then most other upgrades will be happening through the api
<fwereade__> dimitern, I don't understand what's triggering an upgrade there
<mup> Bug #1610319 opened: Juju fails to download charm <juju-core:New> <https://launchpad.net/bugs/1610319>
<fwereade__> dimitern, if you upgrade juju and change proxy settings at the same time I can see how that could happen
<dimitern> fwereade__: what I think happens is this: 1) juju client cannot login due to "upgrade in progress" (ok and expected), 2) upgrader starts first, before even proxyupdater (bad), 3) upgrader tries to hit streams.c.c, fails (with set http_proxy= in the exec-start.sh job for jujud-machine-0 works!), 4) proxyupdater stops with dependency "apicaller" not present
 * perrito666 reads a test that breaks so many principles of good testing that makes him cry
<dimitern> fwereade__: this is during bootstrap
<fwereade__> dimitern, why are we bootstrapping with tools that immediately want to replace themselves?
<dimitern> fwereade__: now that's interesting - I'm not passing --upload-tools, but building from source (tag juju-2.0-beta12)
<mup> Bug #1610319 changed: Juju fails to download charm <juju-core:New> <https://launchpad.net/bugs/1610319>
<dimitern> fwereade__: and I can see in the logs current version is juju-2.0-beta12.1, want version juju-2.0-beta12
<fwereade__> dimitern, I *think* the upgrade-on-bootstrap is the problem
<fwereade__> dimitern, *but* I would be super supportive of something that cached proxy settings in agent config and set them up as early as possible
<fwereade__> dimitern, leave the updating to the worker, and make it update the cache too
<dimitern> fwereade__: --auto-upgrade is not passed to juju bootstrap, so I'm not sure why the upgrade is triggered
<fwereade__> dimitern, I bet there's some subtle version mismatch
<dimitern> fwereade__: what you suggest makes perfect sense though
<fwereade__> dimitern, honestly they should probably go into agent config at cloudconfig time
<dimitern> fwereade__: yeah
<fwereade__> dimitern, I don't like putting things in agent config unless I *have* to, but this makes a better case than most
<mup> Bug #1610319 opened: Juju fails to download charm <juju-core:New> <https://launchpad.net/bugs/1610319>
<dimitern> well beta15 apparently works better than beta12 in that same scenario :/
<rick_h_> katco: ping, assigned a bug your way that might be fixed with your last chunk of work
<katco> rick_h_: cool, ta
<rick_h_> katco: can you see if you can replicate with the given steps and trunk and if so it sounds like it might be related to the revision issue you were chasing
<katco> rick_h_: k
 * rick_h_ hopes it's an easy "fix already comitted" :)
<katco> that would be nice
 * rick_h_ goes to grab lunchables
<natefinch> sinzui: reviewboard is borken... getting 500s who's in charge of that now?  G
<sinzui> natefinch: no one
<sinzui> natefinch: I can take a look
<sinzui> natefinch: is there a specific url that gives a 500?
 * sinzui visits app
<natefinch> sinzui: looks like any specific review url
<natefinch> sinzui: or.. not
<sinzui> natefinch: I am not seeing errors
<natefinch> sinzui: http://reviews.vapour.ws/r/5355/
<sinzui> natefinch: ty
<sinzui> just that one url, the neighbors are fine
<sinzui> natefinch: there are seveal errors like this in the log https://pastebin.canonical.com/162540/ all are for /r/5355/. I see me, you and axw.
<natefinch> lol python
<sinzui> natefinch: I think the data for this review is bad. I will see what I can do
<natefinch> sinzui: there's a way to delete it and recreate it... but I think it requires admin rights to really really delete
<sinzui> natefinch: yeah. I am hunting for that power, or a command line util on the host
<katco> sinzui: natefinch: ericsnow still works for canonical, just saying :)
<natefinch> katco: lol good point
<katco> i don't think it's *that* much of an imposition to ask for instructions 1x. but we should write them down
<alexisb> perrito666, ping
<perrito666> alexisb: pong
<sinzui> natefinch: do you know who created it? I have a list of reviews, but no id to match it to the url
<natefinch> sinzui: andrew
 * natefinch is pinging ericsnow
<ericsnow> natefinch: what's up?
<katco> ericsnow: hey! o/
<perrito666> wow, instant summoning
<ericsnow> :)
<katco> wwitzel3: summon? for old times sake?
<natefinch> ericsnow: I think we need to perma-delete a review so it can be recreated
 * perrito666 burns incense in a monument for ericsnow to pray for the fixing of review board
<natefinch> ericsnow: but I'm not sure any of us are admins, and IIRC one needs to be an admin to do it
<natefinch> ericsnow: start of the story, this review returns a 500: http://reviews.vapour.ws/r/5355/
<ericsnow> natefinch: yep
<ericsnow> natefinch: looks like katco still is an admin
<natefinch> katco is the new ericsnow.  It is known.
<katco> i quit
<natefinch> lol
<katco> good working with you folks
<perrito666> please make me admin too, I know my way around django
<perrito666> and that gives us some redundancy
<natefinch> perrito666 is the new ericsnow
<ericsnow> (also admin: alexisb, cmars, frobware, fwereade__, thumper, jam, sinzui, and wallyworld)
<katco> rick_h_: https://bugs.launchpad.net/juju-core/+bug/1610319/comments/5
<mup> Bug #1610319: Juju fails to download charm <juju-core:Triaged by cox-katherine-e> <https://launchpad.net/bugs/1610319>
<alexisb> ericsnow, what are we admin to?
<natefinch> ericsnow: nice.  Good.  Sorry, I didn't realize.  That's a good list.  I agree with putting perrito666 on there... this really should be dev's job to maintain.
<natefinch> alexisb: reviewboard
<alexisb> aaah yeah ok
<ericsnow> alexisb: reviewboard (click on your username and you'll see an "Admin" link)
 * katco goes for lunch
<ericsnow> natefinch: all good now?
<natefinch> ericsnow: is there a trick to permadeleting a review?  I don't have the admin UI, so I don't know how to do it.  Does the author have to delete it first?
<ericsnow> natefinch: it's a third option in the "Close" menu: "Delete Permanently"
<rick_h_>   katco <3 ty much
<natefinch> ericsnow: cool, thanks.
<ericsnow> natefinch: take care!
<natefinch> ericsnow: I release you from the summons.  Thanks for the help.
 * natefinch makes a page in the wiki for reviewboard tips
<alexisb> thank you natefinch
<fwereade__> that was a truly spectacular CL, by the way; I think it's the only time RB's been broken by sheer awesomeness
<alexisb> "broken by sheer awesomeness"
<alexisb> :)
<perrito666> I would love to open that issue in rb
<natefinch> perrito666: are you an admin on rb now?
<perrito666> "rb breaks when excessive awesomeness present in patch"
<perrito666> natefinch: checking
<perrito666> natefinch: nope, still a mere mortal
<mup> Bug #1604955 changed: TestUpdateStatusTicker can fail with timeout <ci> <intermittent-failure> <test-failure> <juju-core:Fix Released by fwereade> <https://launchpad.net/bugs/1604955>
<mup> Bug #1608105 changed: LXD no longer activates all interfaces on initial deploy when using MAAS2rc3 and JUJU Beta13 <juju-core:Fix Released> <https://launchpad.net/bugs/1608105>
<rick_h_> katco: can you add a link to your PR in your aws storage card please?
<natefinch> alexisb, sinzui: can one of you make perrito666 and me admins on reviewboard?
<natefinch> I don't think there's any reason not to have a ton of admins
<alexisb> natefinch, yep one se
<alexisb> c
<sinzui> natefinch: Fix (-ish) rb fellover parsing the first change set. I unlinked it http://reviews.vapour.ws/r/5355/
<sinzui> natefinch: I think I can
<alexisb> sinzui, I got it
<alexisb> perrito666, you should have all powers now
<alexisb> natefinch, doing yours next
<natefinch> alexisb: cool, thanks
<alexisb> ok natefinch make sure you are all powerful
<sinzui> natefinch: My suspision that a comment couldn't be parsed was wrong. I am surprised that the changesets are parse as markdown.
<natefinch> sinzui: lol, it parses the PR/commit messages as markdown?  that's horrible
<natefinch> sinzui: I mean, it still shouldn't *break*
<sinzui> natefinch: I think it parsed the diff as markdown!
<natefinch> lol
<sinzui> natefinch: the comments were fine.
<sinzui> I understand the schema now so I wont be slow the next time this happens
<natefinch> well, good
<natefinch> alexisb: thanks
<perrito666> natefinch: alexisb http://stream1.gifsoup.com/view/572272/he-man-o.gif
<alexisb> perrito666, I loved he-man growing up, I so wanted to be she-ra
<natefinch> nice nice... yeah, he-man was one of the few licensed toys I had growing up.  I think my mother still has some of them in the attic somewhere.
<natefinch> alexisb: are you an admin on https://github.com/juju/environschema/ ?  I need a v2 branch there
<rick_h_> natefinch: I can help with that
<natefinch> rick_h_: thanks
<rick_h_> natefinch: https://github.com/juju/environschema/tree/v2 when you're sure it's stable
<rick_h_> natefinch: let's make sure to go back and make it the default branch of the project
<natefinch> rick_h_: yep
<rick_h_> and with that I'm going to run to get the boy, have a good weekend folks
<natefinch> rick_h_: see ya
<perrito666> yeah, he man was strategically broadcast at the time kids get out of school and get together to drink tea with cookies
<mup> Bug #1610319 changed: Juju fails to download charm <juju-core:Fix Committed by cox-katherine-e> <https://launchpad.net/bugs/1610319>
<mup> Bug #1610397 opened: juju2, maas2, cloud deployment failure when two domains are used. <kanban-cross-team> <landscape> <juju-core:Triaged by rharding> <MAAS:New> <nova-cloud-controller (Juju Charms Collection):New> <https://launchpad.net/bugs/1610397>
<mup> Bug #1610397 changed: juju2, maas2, cloud deployment failure when two domains are used. <kanban-cross-team> <landscape> <juju-core:Triaged by rharding> <MAAS:New> <nova-cloud-controller (Juju Charms Collection):New> <https://launchpad.net/bugs/1610397>
<natefinch> perrito666: I need another brain
<perrito666> natefinch: have you tried amazon?
<mup> Bug #1610397 opened: juju2, maas2, cloud deployment failure when two domains are used. <kanban-cross-team> <landscape> <juju-core:Triaged by rharding> <MAAS:New> <nova-cloud-controller (Juju Charms Collection):New> <https://launchpad.net/bugs/1610397>
<natefinch> perrito666: got time for a hangout?
<perrito666> natefinch: sure, gimme a sec
<natefinch> perrito666: when you're ready: gah, dammit
<natefinch> lol, wrong copy and paste
<natefinch> https://hangouts.google.com/hangouts/_/canonical.com/moonstone?authuser=1
<mbruzek> Can I get someone to triage this bug: https://bugs.launchpad.net/juju-core/+bug/1609893 I know it is not a high priority probem but I am able to reproduce it again today.
<mup> Bug #1609893: juju status returns ERROR not logged in <usability> <juju-core:Triaged> <https://launchpad.net/bugs/1609893>
<mup> Bug #1610450 opened: feature request: suspend models <juju-core:New> <https://launchpad.net/bugs/1610450>
<perrito666> aghh really blocked again?
<perrito666> alexisb: is it really that blocking?
#juju-dev 2016-08-06
<mup> Bug #1588542 changed: Juju2 is slow with MAAS2, log shows errors, works anyway <maas-provider> <juju-core:Expired> <https://launchpad.net/bugs/1588542>
<mup> Bug #1588572 changed: cmd supercommand.go:448 cannot read tools metadata in tools directory: open /var/lib/juju/tools/2.0-beta6-xenial-amd64/downloaded-tools.txt: no such file or directory <juju-core:Expired> <https://launchpad.net/bugs/1588572>
<mup> Bug #1588542 opened: Juju2 is slow with MAAS2, log shows errors, works anyway <maas-provider> <juju-core:Expired> <https://launchpad.net/bugs/1588542>
<mup> Bug #1588572 opened: cmd supercommand.go:448 cannot read tools metadata in tools directory: open /var/lib/juju/tools/2.0-beta6-xenial-amd64/downloaded-tools.txt: no such file or directory <juju-core:Expired> <https://launchpad.net/bugs/1588572>
<mup> Bug #1588542 changed: Juju2 is slow with MAAS2, log shows errors, works anyway <maas-provider> <juju-core:Expired> <https://launchpad.net/bugs/1588542>
<mup> Bug #1588572 changed: cmd supercommand.go:448 cannot read tools metadata in tools directory: open /var/lib/juju/tools/2.0-beta6-xenial-amd64/downloaded-tools.txt: no such file or directory <juju-core:Expired> <https://launchpad.net/bugs/1588572>
#juju-dev 2016-08-07
<mup> Bug #1566420 changed: lxd doesn't provision instances on first bootstrap in new xenial image <lxd> <juju-core:Expired> <https://launchpad.net/bugs/1566420>
<mup> Bug #1610169 changed: invalid lxd config after update to 2.0-beta14-0ubuntu1~16.04.2~juju1 <juju-core:Invalid> <https://launchpad.net/bugs/1610169>
<wallyworld> anastasiamac: ?
<anastasiamac> wallyworld: ? :D
<mup> Bug # changed: 1287718, 1315497, 1501568, 1519128, 1556161, 1556349, 1568372, 1585849, 1590172, 1597879, 1602780, 1604785, 1604787, 1605986, 1610243
#juju-dev 2017-07-31
<veebers> wallyworld: hmm, I've never heard of that before and can't find any reference to it. Looks like jujugui bot commented on the previous PRs so perhaps handled by them?
<wallyworld> veebers: could be the case, i'll follow up, thanks
<veebers> wallyworld: sweet, sorry to pass it off :-\
<wallyworld> totslly ok
<anastasiamac> could i get an easy review of resources cmd registration complying with the fold - https://github.com/juju/juju/pull/7686
<babbageclunk> anastasiamac: lookinh
<babbageclunk> g
<wallyworld> menn0: i've replied, i hope it makes sense
<menn0> wallyworld: ok thanks
<anastasiamac> babbageclunk: \o/
<menn0> wallyworld: that helps
<wallyworld> menn0: still haven't decided whether we need status history etc. regardless, i think having status attribute on relation doc for the current value is useful; any history would be stored in the separate collection
<wallyworld> makes the watcher much easier to write
<menn0> wallyworld: that sounds right. i'm not sure about the need for history either.
<menn0> I guess i'm not clear on what would cause the status to change
<wallyworld> if someone revokes an offer for example
<wallyworld> because a bill is unpaid or whatever
<wallyworld> of they exceed a quota
<wallyworld> *or
<menn0> ok cool
<wallyworld> any relations to that offer would become revoked
<wallyworld> departed hooks would run
<wallyworld> but relation is still there
<wallyworld> rendered somehow in gui and inactive
<wallyworld> able to be re-enabled again
<babbageclunk> anastasiamac: lgtm'd
<menn0> wallyworld: cool. that helps my understanding a lot.
<wallyworld> menn0: sorry for brief PR description, there wasn't a lot of context there for sure
<menn0> all good
<menn0> wallyworld: review done
<wallyworld> menn0:  thanks for review. i considered the simpler approach with the strings watcher and followup api call. but for cross controller communication, i was trying to eliminate the chattiness. in this use case, we don't need to know anything else from the watched model apart from life/status, so making a second api call (potentially across clouds) to get a simple scalar value that is instead passed across with the initial notification seemed
<wallyworld> wasteful and something that would not scale so well. what do you think? with the notify->api call approach, i'd still need to do extra code to provide the apis to get the relation life/status. so there's no real net code reduction. and it is more chatty which is bad for networked services. i'm happy to revisit though if needed
<menn0> wallyworld: np. as long as you've thought about it :)
<wallyworld> menn0: the non-simple approach did bother me though. i'm still not 100% convinced it's the right thing to do to deviate from the model used elsewhere. what is your regret about the migration watcher?
<menn0> wallyworld: a couple things: if you want access to the data/logic behind the watcher *without* using a watcher you end up having to double it up
<menn0> wallyworld: and: managing the changing of data returned by a watcher API is more painful
<menn0> they're harder to version
<wallyworld> menn0: the watcher events arrive in the order they are generated server side i think? in my case here, we just care about knowing the last/latest status value. there's always the chance that the relation could go active again on the other side after you get told it's revoked, but there'd still be an as yet undelivered notification to act on to correct things. and life can only go one way. so i think it works out ok?
<menn0> wallyworld: if you only need to know the latest status, then the "notify and check" pattern is probably better
<menn0> wallyworld: b/c the API call to get current state, sees the latest state
<menn0> wallyworld: where-as queued up "rich" notifications could have stale data in them
<wallyworld> it does. but it's an api call that would otherwise not need to be made
<menn0> wallyworld: totally
<menn0> wallyworld: in this case, b/c of the nature of the API requests (cross-cloud), a specialised watcher certainly makes more sense
<wallyworld> and multiple that uneeded api call by 1000 or however many consumers there are
<wallyworld> more load on the offering controller
<wallyworld> babbageclunk: did you see comment #7 on this bug 1705730?
<mup> Bug #1705730: `juju migrate` fails with source prechecks failed ERROR <juju:New> <https://launchpad.net/bugs/1705730>
<babbageclunk> wallyworld: no, I hadn't - thanks
<wallyworld> np, i assumed you had been looking at it?
<wallyworld> axw: thanks for review
<axw> babbageclunk: your PR is good to land
<anastasiamac> another tiny and easy review, please \o/ https://github.com/juju/juju/pull/7688 (order resources list output)
<babbageclunk> axw: oh, thanks!
<babbageclunk> thumper: can you merge https://github.com/juju/1.25-upgrade/pull/6 plz?
<thumper> babbageclunk: you can now
<babbageclunk> thumper: oh, so I can - thanks!
<axw> wallyworld: can you please create a section under TODO in leankit for 1.25 upgrades?
<wallyworld> sure
<wallyworld> axw: done
<axw> wallyworld: gracias
<axw> babbageclunk: if you've got things to add ^^
<babbageclunk> axw: oh yes, good call
<babbageclunk> axw: how can I find what permissions I have on a model?
<babbageclunk> axw: (or what permissions some other juju user has on the model)
<axw> babbageclunk: I think "juju show-model" lists users/access
<axw> yep
<babbageclunk> axw: ok - so as a superuser I should be able to grant access to a model to myself, I guess?
<axw> babbageclunk: yep
<menn0> wallyworld, axw or thumper: I need to bounce some ideas off someone
<wallyworld> ok
<menn0> wallyworld: quick hangout?
<menn0> wallyworld: https://hangouts.google.com/hangouts/_/canonical.com/menn0-wallyworld
<wallyworld> sure
#juju-dev 2017-08-01
<anastasiamac> a super easy one, plz \o/ https://github.com/juju/juju/pull/7693
<hml> anastasiamac: looking
<hml> anastasiamac: just a tiny nit; looks okay to me
<anastasiamac> hml: awesome \o/ ta... (i've ignored the comment since the alias still stayed but sure :D updated just for u...)
<anastasiamac> ignored initially, i mean :D
<hml> anastasiamac: ty!
<babbageclunk> axw: Hey, any reason not to put go generate into the makefile install target for 1.25 upgrades?
<babbageclunk> axw: I guess there wasn't any need for you since you weren't changing the underlying script?
<axw> babbageclunk: no particular reason for or against doing that, I just went with the go native approach
<axw> babbageclunk: unlikely to have to change it
<babbageclunk> axw: ok, I'm going to add it for mine. Otherwise I'm probably going to forget a generate and then get really confused about why it's not working.
<axw> babbageclunk: fair enough. feel free to change that one too if it's easy enough
<babbageclunk> axw: oh hang on - I don't understand what you're saying.
<axw> babbageclunk: I took what you said to mean you're going to add a makefile target for your thing
<babbageclunk> axw: no, I meant I was going to run go generate ./commands from the install target (so I wouldn't forget to run it after changing the upgrade script).
<axw> babbageclunk: oh ok, that sounds fine too
<babbageclunk> cool
<axw> unconditional make targets make me sad, but it's just a little project ;)
<wallyworld> babbageclunk: if you get time before your eod, would love a review. but don't interrupt your 1.25 upgrade work if you're in the middle of something https://github.com/juju/juju/pull/7694
<babbageclunk> wallyworld: sure - looking now
<wallyworld> yay, ty
<babbageclunk> wallyworld: reviewed
<wallyworld> babbageclunk: awesome, thanks
<wallyworld> babbageclunk: it will be used to populate status on the offering side
<wallyworld> to show who is connected to each offer and what endpoint they are connected to
<wallyworld> also to allow easy removal of remote relations on the offered side
<wallyworld> babbageclunk: see if my explanation in the PR makes sense
<babbageclunk> wallyworld: How can you use it in status on the offering side? Will the consuming side push the information to the offering controller?
<wallyworld> the collection containing the details of who is connected to an offer is set up in the register relation api call
<wallyworld> s/set up/populated
<wallyworld> and register relation comes from the consumer side
<babbageclunk> wallyworld: OHH, I misread it as being stored in the consuming side.
<wallyworld> it's messy for sure
<babbageclunk> wallyworld: But it's actually in the offering side, in a different facade from where the macaroon is minted. Ok, that makes more sense.
<babbageclunk> wallyworld: yeah, ok that makes sense then.
<wallyworld> yeah. and the macaroon will gain a Location URL which will be used to discharge the 3rd party caveat that the user has access to the offer
<wallyworld> but thta's not done yet
<wallyworld> for controller->controller it will be a local url
<wallyworld> on the offering controller
<babbageclunk> ok
<babbageclunk> axw: ping?
<axw> babbageclunk: pong, sorry was riding
<axw> oh that was a minute ago... not sorry ;p
<babbageclunk> ha!
<babbageclunk> axw: Actually I think I've answered my own question
<axw> yay
<babbageclunk> axw: Having some confusion over whether the permission denied I'm getting was because I couldn't read the system identity or create the destination dir, but I think it's the latter.
<axw> babbageclunk: okey dokey. everything runs through sudo, so shouldn't be the former
<axw> but then... shouldn't be the latter either...
<axw> babbageclunk: FYI I have a backup-lxc PR up: https://github.com/juju/1.25-upgrade/pull/8. no rush to review. I'm working on the lxc-to-lxd command now
<babbageclunk> well, this is on the hop from the state-server machine to the other machines, so I think it's connecting as ubuntu
<babbageclunk> axw: oh, ok - I'll take a look in a bit.
<axw> ah ok
<babbageclunk> axw: or I might look tomorrow morning if it's no difference to you?
<axw> babbageclunk: it can wait till tomorrow if you'd prefer not to context switch
<axw> yep
<babbageclunk> ok cool
<rick_h> axw: morning
<wallyworld> rick_h: andrew will be online soon. thanks for the excellent storage feedback
<rick_h> wallyworld: all good, I wanted to see what i was missing for the --attach-storage stuff so I can move forward some more and maybe cover it for juju show material tomorrow. I'll chill out and be patient. :)
<wallyworld> rick_h: yeah, that should have worked
<rick_h> wallyworld: yea, I was wondering if there's a FF or something that was left out of the blog post/docs or something? It's not in the juju deploy --help or anything so it's like it's not there.
<wallyworld> rick_h: yeah, weird. just joining a new meeting, so will be distracted
<rick_h> wallyworld: all good, I'll be patient. ty
#juju-dev 2017-08-02
<axw> rick_h: heya. about to go into standup, will be free to chat in a little while
<rick_h> axw: k
<wallyworld> babbageclunk: standup?
<babbageclunk> oops
<axw> rick_h: ok, reading your notes now
<rick_h> axw: k, I'd like to see what I'm missing for --attach to work so I can move forward
<rick_h> axw: the rest is feedback/notes just on using stuff
<axw> rick_h: I don't understand why --attach-storage isn't working for you. it's working for me, and I'm pretty sure wallyworld used it in his demo
<rick_h> axw: is there a feature flagged or something?
<rick_h> Oh...maybe I didn't use the snap path. Let me double check.
<axw> rick_h: no, there was one but I removed it ages ago
<wallyworld> yeah, worked for me in demo IIANM
<wallyworld> externalreality: reviewed PR, see if my comments make sense
<rick_h> axw: yea, that's it. Apologies. I have multiple Juju on here and forgot to use the right /snap/bin path
<rick_h> I'm not sure why I didn't notice it through all the notes/etc
<rick_h> axw: let me know if any of the other notes are unclear or you want to chat about
<rick_h> axw: I assume this works on OpenStack and AWS, does it work anywhere else?
<axw> rick_h: AWS, GCE, OpenStack, Azure
<rick_h> axw: <3 awesome
<axw> rick_h: oh, and LXD :)
<axw> rick_h: there's some new functionality which I've commented on in the doc, which is only supported on AWS and LXD atm: releasing and importing storage
<rick_h> axw: yea, I've got to get the zsh thing setup to play with that side some.
<rick_h> axw: k, ty
<axw> rick_h: you can now do this: juju remove-storage --no-destroy pgdata/0. that'll remove it from juju, but leave the EBS volume (or whatever) alone
<rick_h> axw: k, cool
<axw> rick_h: you can then: juju import-filesystem ebs vol-123456 pgdata, into a new controller. you'll end up with pgdata/N with that EBS volume
<axw> rick_h: still need to implement import-volume
<rick_h> axw: hmm, wouldn't it need to know the charm to make sure the title is ok for the declared storage location?
<rick_h> axw: e.g. can I just call it whatever vs pgdata?
<rick_h> axw: and if so how would I use it as I note in the docs the attach-storage doesn't take the extra arg like deploy --storage does?
<wallyworld> we talked about that, but for now the import name needs to match the charm storage name
<axw> rick_h: you can call it whatever. it's a bit rough, I'm not sure what the best UX is there. but it needs to be able to support importing before deploying the app
<rick_h> wallyworld: right, but how's that validated on import then if you don't specify the charm name?
<wallyworld> it's not right now
<wallyworld> this was all done last minute
<rick_h> axw: ah, yea, I think that's why i'm wondering if the arg needs to not get dropped in --attach-storage vs --storage
<axw> rick_h: yes, probably
<rick_h> wallyworld: k, well just the questions/issues I saw in playing. Totally understand that it's WIP and such
<wallyworld> np, the feedback is awesome
<axw> rick_h: +1, thank you
<wallyworld> we know though there's more to do
<rick_h> ok, I'll play with more tomorrow then and demo on the juju show tomorrow afternoon.
<wallyworld> yay
<rick_h> anything else I think of I'll add to the doc
<rick_h> ty for the time axw and wallyworld
<wallyworld> rick_h: and the cmr blog issue?
<rick_h> wallyworld: replied to your email
<wallyworld> i think we should go ahead, the macaroon stuff is internal
<rick_h> wallyworld: I'll make one more run by uros just to make sure that it's not a case of two folks hearing two different things from the same conversation.
<rick_h> wallyworld: but I can steer a path I'm sure
<wallyworld> sounds good ty
 * babbageclunk goes for a run
<wallyworld> babbageclunk: for whenever, here's a followup to the pr from yesterday - offer connection info now displayed in status https://github.com/juju/juju/pull/7698
<babbageclunk> wallyworld: back now but I want to get some things finished off first
<wallyworld> no hurry at all
<wallyworld> just whenever
<babbageclunk> wallyworld: cool cool
<babbageclunk> axw: ping?
<wallyworld> axw: here's a small one to fix something that was shitting me with juju offers (was on the todo list) https://github.com/juju/juju/pull/7699
<axw> babbageclunk: sorry, pong
<axw> wallyworld: looking
<axw> wallyworld: why not just make it a model command?
<axw> wallyworld: you can still get a controller API for a model command, if that's why you didn't
<wallyworld> axw: it can't be a model comand because it talks to a controller facade
<axw> wallyworld: <axw> wallyworld: you can still get a controller API for a model command, if that's why you didn't
<wallyworld> hmmm, ok, i'll look into it
<axw> wallyworld: see: ModelCommand.NewControllerAPIRoot
<wallyworld> ok, i had a feeling there was something else amiss, but maybe not. there was a lot of churn at one point with all the facades
<babbageclunk> Ha ha, spent the afternoon writing Python and suddenly I'm leaving off all the closing braces.
<wpk> :)
<redir> Hello juju... Chloe Grace wanted to say hi, https://goo.gl/photos/wVPHohn5MLbf684TA
<rick_h> redir: !!!!!!!
<redir> hope all is well in juju-land
<rick_h> redir: congrats sir! All the best to the little one and momma
<redir> thank you, rick_h :)
<rick_h> redir: very very happy for you
<redir> me too, she's awesome
<rick_h> :)
#juju-dev 2017-08-03
<hml>  wallyworld: ping
<wallyworld> hi
<hml> wallyworld: i need some help with the mock test please.  :-)
<hml> wallyworld: ho?
<wallyworld> sure
<hml> wallyworld: if you have a spare momment
<hml> wallyworld: standup ho
<hml> ?
<babbageclunk> axw ping?
<axw> babbageclunk: pong
<babbageclunk> axw: hey, quick q: I can't use `juju ssh 0` on the Juju 2 controller of blahdeblah's that we have access
<babbageclunk> axw: But I can ssh to ubuntu@ip
 * axw tries
<babbageclunk> axw: Can you use juju ssh? Have I missed some setup?
<babbageclunk> axw: I'm not very familiar with using controllers that I'm not admin for.
<axw> babbageclunk: failing because I don't have my key added, but it's connecting
<axw> babbageclunk: with key added, works fine
<axw> babbageclunk: you're talking about "canonistack2", right?
<axw> IP is 10.55.32.38 ?
<babbageclunk> axw: it's canonistack-lcy02
<axw> babbageclunk: don't suppose you're still around? I just pushed a refactoring of the migrate-lxc command
<axw> fairl substantial, so would be good to get another look over
<frankban> wallyworld: hey, I am looking for a review for https://github.com/juju/juju/pull/7704
<wallyworld> frankban: sorry, was at soccer. lgtm
<frankban> wallyworld: np and thanks, what role do you play at soccer?
<wallyworld> tonight - coach. tomorrow, i play, position is wing back
<hml> babbageclunk: any chance youâve been in the featuretest code?  :-)
<babbageclunk> hml: not much, but I'll try my best!
<hml> babbageclunk: have time for a HO?
<babbageclunk> hml: Sure!
<babbageclunk> hml: in standup?
<hml> https://hangouts.google.com/hangouts/_/canonical.com/featuretest?hl=en&authuser=0
<hml> babbageclunk: ^^
<hml> babbageclunk: our idea appears to be working.  :-)  ty
<babbageclunk> hml: great!
<wallyworld> thumper: we miss you
<thumper> coming
#juju-dev 2017-08-04
<wallyworld> babbageclunk: and if you get a chance today, that code review so i can include in dev summary email :-)
<babbageclunk> wallyworld: oh sorry, forgot about that! I'll look after this.
<wallyworld> no wuckers
<hml> wallyworld: ping
<wallyworld> hi
<hml> wallyworld: do you have a few minutes for an HO?  darn feature tests
<hml> :-)
<wallyworld_> hml: sorry, computer froze :-(
<hml> wallyworld: silly computers.  :-)  do you have time for a HO?  featuretests ...
<wallyworld_> yep
<hml> wallyworld_: team ho?
<wallyworld_> ok
<wallyworld_> hml: actually, standup
 * babbageclunk goes for a run
<babbageclunk> wallyworld_: reviewed, sorry for the delay!
<wallyworld_> no worries, thanks for doing it
<anastasiamac> axw: tyvm for review \o/
<axw> anastasiamac: np, sorry for the delay
<anastasiamac> i did not feel like there was - m entertained atm :)
<axw> anastasiamac: :)
<veebers> Hi all, please ignore any extra check-merge comments on open PRs. Some teething issues moving to a new system (triggered new runs for existing PRs)
<babbageclunk> wallyworld_ or axw (or anyone else, but you two seem like you should know): what does the upgradedToVersion key in agent.conf mean? I'm looking at a unit which is in a 2.2.2 model but it has 2.1.0 in the conf file.
<axw> babbageclunk: that's the version for which the upgrade steps have run on that agent
<wallyworld_> +1
<babbageclunk> axw: ok - so if there haven't been any unit-level upgrade steps since 2.1.0 then it won't have changed?
<babbageclunk> axw: But I guess no harm in me setting it to 2.2.2 either?
<babbageclunk> axw: Also, what's the relationship between apipassword, statepassword and oldpassword?
<axw> babbageclunk: hmm I thought it would change it anyway, even if there weren't upgrade steps... seems to me it should do that if it doesn't. there's an upgrade step that should be in 2.2.2 (currently targeted to 2.2), which is to set the environ-version
<axw> babbageclunk: statepassword is the mongo password. apipassword is the juju user password (I forget if those two are different...), and oldpassword... I forget
<babbageclunk> axw: I'm going to assume they don't need to change between 1.25 and 2.2
<babbageclunk> for now at least
<axw> babbageclunk: statepassword is only relevant for controllers, so you should just be able to drop that
<axw> babbageclunk: apipassword and oldpassword can remain the same
<babbageclunk> axw: nice, thanks. It seems the same for stateaddresses too
<axw> babbageclunk: yup
<babbageclunk> axw: awesome.
#juju-dev 2017-08-06
<babbageclunk> axw: around yet?
#juju-dev 2018-08-01
<nkuttler3> With our IRC ad service you can reach a global audience of entrepreneurs and fentanyl addicts with extraordinary engagement rates! https://williampitcock.com/
<nkuttler3> I thought you guys might be interested in this blog by freenode staff member Bryan 'kloeri' Ostergaard https://bryanostergaard.com/
<nkuttler3> Read what IRC investigative journalists have uncovered on the freenode pedophilia scandal https://encyclopediadramatica.rs/Freenodegate
<nkuttler3> A fascinating blog by freenode staff member Matthew 'mst' Trout https://MattSTrout.com/
<anderson2> With our IRC ad service you can reach a global audience of entrepreneurs and fentanyl addicts with extraordinary engagement rates! https://williampitcock.com/
<anderson2> I thought you guys might be interested in this blog by freenode staff member Bryan 'kloeri' Ostergaard https://bryanostergaard.com/
<anderson2> Read what IRC investigative journalists have uncovered on the freenode pedophilia scandal https://encyclopediadramatica.rs/Freenodegate
<anderson2> A fascinating blog by freenode staff member Matthew 'mst' Trout https://MattSTrout.com/
<physpi3> With our IRC ad service you can reach a global audience of entrepreneurs and fentanyl addicts with extraordinary engagement rates! https://williampitcock.com/
<physpi3> I thought you guys might be interested in this blog by freenode staff member Bryan 'kloeri' Ostergaard https://bryanostergaard.com/
<physpi3> Read what IRC investigative journalists have uncovered on the freenode pedophilia scandal https://encyclopediadramatica.rs/Freenodegate
<physpi3> A fascinating blog by freenode staff member Matthew 'mst' Trout https://MattSTrout.com/
<montag45118> With our IRC ad service you can reach a global audience of entrepreneurs and fentanyl addicts with extraordinary engagement rates! https://williampitcock.com/
<montag45118> I thought you guys might be interested in this blog by freenode staff member Bryan 'kloeri' Ostergaard https://bryanostergaard.com/
<montag45118> Read what IRC investigative journalists have uncovered on the freenode pedophilia scandal https://encyclopediadramatica.rs/Freenodegate
<montag45118> A fascinating blog by freenode staff member Matthew 'mst' Trout https://MattSTrout.com/
<Goldman6014> With our IRC ad service you can reach a global audience of entrepreneurs and fentanyl addicts with extraordinary engagement rates! https://williampitcock.com/
<Goldman6014> I thought you guys might be interested in this blog by freenode staff member Bryan 'kloeri' Ostergaard https://bryanostergaard.com/
<Goldman6014> Read what IRC investigative journalists have uncovered on the freenode pedophilia scandal https://encyclopediadramatica.rs/Freenodegate
<Goldman6014> A fascinating blog by freenode staff member Matthew 'mst' Trout https://MattSTrout.com/
<Guest61508> With our IRC ad service you can reach a global audience of entrepreneurs and fentanyl addicts with extraordinary engagement rates! https://williampitcock.com/
<Guest61508> I thought you guys might be interested in this blog by freenode staff member Bryan 'kloeri' Ostergaard https://bryanostergaard.com/
<Guest61508> Read what IRC investigative journalists have uncovered on the freenode pedophilia scandal https://encyclopediadramatica.rs/Freenodegate
<Guest61508> A fascinating blog by freenode staff member Matthew 'mst' Trout https://MattSTrout.com/
<vegii25> With our IRC ad service you can reach a global audience of entrepreneurs and fentanyl addicts with extraordinary engagement rates! https://williampitcock.com/
<vegii25> I thought you guys might be interested in this blog by freenode staff member Bryan 'kloeri' Ostergaard https://bryanostergaard.com/
<vegii25> Read what IRC investigative journalists have uncovered on the freenode pedophilia scandal https://encyclopediadramatica.rs/Freenodegate
<vegii25> A fascinating blog by freenode staff member Matthew 'mst' Trout https://MattSTrout.com/
<Shibe3> With our IRC ad service you can reach a global audience of entrepreneurs and fentanyl addicts with extraordinary engagement rates! https://williampitcock.com/
<Shibe3> I thought you guys might be interested in this blog by freenode staff member Bryan 'kloeri' Ostergaard https://bryanostergaard.com/
<Shibe3> Read what IRC investigative journalists have uncovered on the freenode pedophilia scandal https://encyclopediadramatica.rs/Freenodegate
<Shibe3> A fascinating blog by freenode staff member Matthew 'mst' Trout https://MattSTrout.com/
<ccallahan21> With our IRC ad service you can reach a global audience of entrepreneurs and fentanyl addicts with extraordinary engagement rates! https://williampitcock.com/
<ccallahan21> I thought you guys might be interested in this blog by freenode staff member Bryan 'kloeri' Ostergaard https://bryanostergaard.com/
<ccallahan21> Read what IRC investigative journalists have uncovered on the freenode pedophilia scandal https://encyclopediadramatica.rs/Freenodegate
<noonehere4u6> With our IRC ad service you can reach a global audience of entrepreneurs and fentanyl addicts with extraordinary engagement rates! https://williampitcock.com/
<noonehere4u6> I thought you guys might be interested in this blog by freenode staff member Bryan 'kloeri' Ostergaard https://bryanostergaard.com/
<noonehere4u6> Read what IRC investigative journalists have uncovered on the freenode pedophilia scandal https://encyclopediadramatica.rs/Freenodegate
<noonehere4u6> A fascinating blog by freenode staff member Matthew 'mst' Trout https://MattSTrout.com/
<ATDT91120> With our IRC ad service you can reach a global audience of entrepreneurs and fentanyl addicts with extraordinary engagement rates! https://williampitcock.com/
<ATDT91120> I thought you guys might be interested in this blog by freenode staff member Bryan 'kloeri' Ostergaard https://bryanostergaard.com/
<ATDT91120> Read what IRC investigative journalists have uncovered on the freenode pedophilia scandal https://encyclopediadramatica.rs/Freenodegate
<ATDT91120> A fascinating blog by freenode staff member Matthew 'mst' Trout https://MattSTrout.com/
<purrdeta21> With our IRC ad service you can reach a global audience of entrepreneurs and fentanyl addicts with extraordinary engagement rates! https://williampitcock.com/
<purrdeta21> I thought you guys might be interested in this blog by freenode staff member Bryan 'kloeri' Ostergaard https://bryanostergaard.com/
<purrdeta21> Read what IRC investigative journalists have uncovered on the freenode pedophilia scandal https://encyclopediadramatica.rs/Freenodegate
<purrdeta21> A fascinating blog by freenode staff member Matthew 'mst' Trout https://MattSTrout.com/
<Yoda8> With our IRC ad service you can reach a global audience of entrepreneurs and fentanyl addicts with extraordinary engagement rates! https://williampitcock.com/
<Yoda8> I thought you guys might be interested in this blog by freenode staff member Bryan 'kloeri' Ostergaard https://bryanostergaard.com/
<Yoda8> Read what IRC investigative journalists have uncovered on the freenode pedophilia scandal https://encyclopediadramatica.rs/Freenodegate
<Yoda8> A fascinating blog by freenode staff member Matthew 'mst' Trout https://MattSTrout.com/
<MrElendig9> With our IRC ad service you can reach a global audience of entrepreneurs and fentanyl addicts with extraordinary engagement rates! https://williampitcock.com/
<MrElendig9> I thought you guys might be interested in this blog by freenode staff member Bryan 'kloeri' Ostergaard https://bryanostergaard.com/
<MrElendig9> Read what IRC investigative journalists have uncovered on the freenode pedophilia scandal https://encyclopediadramatica.rs/Freenodegate
<MrElendig9> A fascinating blog by freenode staff member Matthew 'mst' Trout https://MattSTrout.com/
<AlwaysHigh6> With our IRC ad service you can reach a global audience of entrepreneurs and fentanyl addicts with extraordinary engagement rates! https://williampitcock.com/
<AlwaysHigh6> I thought you guys might be interested in this blog by freenode staff member Bryan 'kloeri' Ostergaard https://bryanostergaard.com/
<AlwaysHigh6> Read what IRC investigative journalists have uncovered on the freenode pedophilia scandal https://encyclopediadramatica.rs/Freenodegate
<AlwaysHigh6> A fascinating blog by freenode staff member Matthew 'mst' Trout https://MattSTrout.com/
<mist28> With our IRC ad service you can reach a global audience of entrepreneurs and fentanyl addicts with extraordinary engagement rates! https://williampitcock.com/
<mist28> I thought you guys might be interested in this blog by freenode staff member Bryan 'kloeri' Ostergaard https://bryanostergaard.com/
<mist28> Read what IRC investigative journalists have uncovered on the freenode pedophilia scandal https://encyclopediadramatica.rs/Freenodegate
<mist28> A fascinating blog by freenode staff member Matthew 'mst' Trout https://MattSTrout.com/
<wget26> With our IRC ad service you can reach a global audience of entrepreneurs and fentanyl addicts with extraordinary engagement rates! https://williampitcock.com/
<wget26> I thought you guys might be interested in this blog by freenode staff member Bryan 'kloeri' Ostergaard https://bryanostergaard.com/
<wget26> Read what IRC investigative journalists have uncovered on the freenode pedophilia scandal https://encyclopediadramatica.rs/Freenodegate
<wget26> A fascinating blog by freenode staff member Matthew 'mst' Trout https://MattSTrout.com/
<profall17> With our IRC ad service you can reach a global audience of entrepreneurs and fentanyl addicts with extraordinary engagement rates! https://williampitcock.com/
<profall17> I thought you guys might be interested in this blog by freenode staff member Bryan 'kloeri' Ostergaard https://bryanostergaard.com/
<profall17> Read what IRC investigative journalists have uncovered on the freenode pedophilia scandal https://encyclopediadramatica.rs/Freenodegate
<profall17> A fascinating blog by freenode staff member Matthew 'mst' Trout https://MattSTrout.com/
<Connecting> With our IRC ad service you can reach a global audience of entrepreneurs and fentanyl addicts with extraordinary engagement rates! https://williampitcock.com/
<Connecting> I thought you guys might be interested in this blog by freenode staff member Bryan 'kloeri' Ostergaard https://bryanostergaard.com/
<Connecting> Read what IRC investigative journalists have uncovered on the freenode pedophilia scandal https://encyclopediadramatica.rs/Freenodegate
<Connecting> A fascinating blog by freenode staff member Matthew 'mst' Trout https://MattSTrout.com/
<Guest43996> With our IRC ad service you can reach a global audience of entrepreneurs and fentanyl addicts with extraordinary engagement rates! https://williampitcock.com/
<Guest43996> I thought you guys might be interested in this blog by freenode staff member Bryan 'kloeri' Ostergaard https://bryanostergaard.com/
<Guest43996> Read what IRC investigative journalists have uncovered on the freenode pedophilia scandal https://encyclopediadramatica.rs/Freenodegate
<SlashLife8> With our IRC ad service you can reach a global audience of entrepreneurs and fentanyl addicts with extraordinary engagement rates! https://williampitcock.com/
<SlashLife8> I thought you guys might be interested in this blog by freenode staff member Bryan 'kloeri' Ostergaard https://bryanostergaard.com/
<SlashLife8> Read what IRC investigative journalists have uncovered on the freenode pedophilia scandal https://encyclopediadramatica.rs/Freenodegate
<SlashLife8> A fascinating blog by freenode staff member Matthew 'mst' Trout https://MattSTrout.com/
<lmartin9222> With our IRC ad service you can reach a global audience of entrepreneurs and fentanyl addicts with extraordinary engagement rates! https://williampitcock.com/
<lmartin9222> I thought you guys might be interested in this blog by freenode staff member Bryan 'kloeri' Ostergaard https://bryanostergaard.com/
<lmartin9222> Read what IRC investigative journalists have uncovered on the freenode pedophilia scandal https://encyclopediadramatica.rs/Freenodegate
<lmartin9222> A fascinating blog by freenode staff member Matthew 'mst' Trout https://MattSTrout.com/
<Algernop11> With our IRC ad service you can reach a global audience of entrepreneurs and fentanyl addicts with extraordinary engagement rates! https://williampitcock.com/
<Algernop11> I thought you guys might be interested in this blog by freenode staff member Bryan 'kloeri' Ostergaard https://bryanostergaard.com/
<Algernop11> Read what IRC investigative journalists have uncovered on the freenode pedophilia scandal https://encyclopediadramatica.rs/Freenodegate
<Algernop11> A fascinating blog by freenode staff member Matthew 'mst' Trout https://MattSTrout.com/
<mub20> With our IRC ad service you can reach a global audience of entrepreneurs and fentanyl addicts with extraordinary engagement rates! https://williampitcock.com/
<mub20> I thought you guys might be interested in this blog by freenode staff member Bryan 'kloeri' Ostergaard https://bryanostergaard.com/
<mub20> Read what IRC investigative journalists have uncovered on the freenode pedophilia scandal https://encyclopediadramatica.rs/Freenodegate
<mub20> A fascinating blog by freenode staff member Matthew 'mst' Trout https://MattSTrout.com/
<lunaaa> With our IRC ad service you can reach a global audience of entrepreneurs and fentanyl addicts with extraordinary engagement rates! https://williampitcock.com/
<lunaaa> I thought you guys might be interested in this blog by freenode staff member Bryan 'kloeri' Ostergaard https://bryanostergaard.com/
<lunaaa> Read what IRC investigative journalists have uncovered on the freenode pedophilia scandal https://encyclopediadramatica.rs/Freenodegate
<lunaaa> A fascinating blog by freenode staff member Matthew 'mst' Trout https://MattSTrout.com/
<Guest51933> With our IRC ad service you can reach a global audience of entrepreneurs and fentanyl addicts with extraordinary engagement rates! https://williampitcock.com/
<Guest51933> I thought you guys might be interested in this blog by freenode staff member Bryan 'kloeri' Ostergaard https://bryanostergaard.com/
<Guest51933> Read what IRC investigative journalists have uncovered on the freenode pedophilia scandal https://encyclopediadramatica.rs/Freenodegate
<Guest51933> A fascinating blog by freenode staff member Matthew 'mst' Trout https://MattSTrout.com/
<samouy28> With our IRC ad service you can reach a global audience of entrepreneurs and fentanyl addicts with extraordinary engagement rates! https://williampitcock.com/
<samouy28> I thought you guys might be interested in this blog by freenode staff member Bryan 'kloeri' Ostergaard https://bryanostergaard.com/
<samouy28> Read what IRC investigative journalists have uncovered on the freenode pedophilia scandal https://encyclopediadramatica.rs/Freenodegate
<samouy28> A fascinating blog by freenode staff member Matthew 'mst' Trout https://MattSTrout.com/
<opung25> With our IRC ad service you can reach a global audience of entrepreneurs and fentanyl addicts with extraordinary engagement rates! https://williampitcock.com/
<opung25> I thought you guys might be interested in this blog by freenode staff member Bryan 'kloeri' Ostergaard https://bryanostergaard.com/
<opung25> Read what IRC investigative journalists have uncovered on the freenode pedophilia scandal https://encyclopediadramatica.rs/Freenodegate
<opung25> A fascinating blog by freenode staff member Matthew 'mst' Trout https://MattSTrout.com/
<mort8> With our IRC ad service you can reach a global audience of entrepreneurs and fentanyl addicts with extraordinary engagement rates! https://williampitcock.com/
<mort8> I thought you guys might be interested in this blog by freenode staff member Bryan 'kloeri' Ostergaard https://bryanostergaard.com/
<ExeciN5> With our IRC ad service you can reach a global audience of entrepreneurs and fentanyl addicts with extraordinary engagement rates! https://williampitcock.com/
<ExeciN5> I thought you guys might be interested in this blog by freenode staff member Bryan 'kloeri' Ostergaard https://bryanostergaard.com/
<ExeciN5> Read what IRC investigative journalists have uncovered on the freenode pedophilia scandal https://encyclopediadramatica.rs/Freenodegate
<ExeciN5> A fascinating blog by freenode staff member Matthew 'mst' Trout https://MattSTrout.com/
<dwC--> With our IRC ad service you can reach a global audience of entrepreneurs and fentanyl addicts with extraordinary engagement rates! https://williampitcock.com/
<dwC--> I thought you guys might be interested in this blog by freenode staff member Bryan 'kloeri' Ostergaard https://bryanostergaard.com/
<dwC--> Read what IRC investigative journalists have uncovered on the freenode pedophilia scandal https://encyclopediadramatica.rs/Freenodegate
<dwC--> A fascinating blog by freenode staff member Matthew 'mst' Trout https://MattSTrout.com/
<bladernr16> With our IRC ad service you can reach a global audience of entrepreneurs and fentanyl addicts with extraordinary engagement rates! https://williampitcock.com/
<bladernr16> I thought you guys might be interested in this blog by freenode staff member Bryan 'kloeri' Ostergaard https://bryanostergaard.com/
<bladernr16> Read what IRC investigative journalists have uncovered on the freenode pedophilia scandal https://encyclopediadramatica.rs/Freenodegate
<bladernr16> A fascinating blog by freenode staff member Matthew 'mst' Trout https://MattSTrout.com/
<cheapie13> With our IRC ad service you can reach a global audience of entrepreneurs and fentanyl addicts with extraordinary engagement rates! https://williampitcock.com/
<cheapie13> I thought you guys might be interested in this blog by freenode staff member Bryan 'kloeri' Ostergaard https://bryanostergaard.com/
<cheapie13> Read what IRC investigative journalists have uncovered on the freenode pedophilia scandal https://encyclopediadramatica.rs/Freenodegate
<cheapie13> A fascinating blog by freenode staff member Matthew 'mst' Trout https://MattSTrout.com/
<catfuneral> With our IRC ad service you can reach a global audience of entrepreneurs and fentanyl addicts with extraordinary engagement rates! https://williampitcock.com/
<catfuneral> I thought you guys might be interested in this blog by freenode staff member Bryan 'kloeri' Ostergaard https://bryanostergaard.com/
<catfuneral> Read what IRC investigative journalists have uncovered on the freenode pedophilia scandal https://encyclopediadramatica.rs/Freenodegate
<catfuneral> A fascinating blog by freenode staff member Matthew 'mst' Trout https://MattSTrout.com/
<heinrich599112> With our IRC ad service you can reach a global audience of entrepreneurs and fentanyl addicts with extraordinary engagement rates! https://williampitcock.com/
<heinrich599112> I thought you guys might be interested in this blog by freenode staff member Bryan 'kloeri' Ostergaard https://bryanostergaard.com/
<heinrich599112> Read what IRC investigative journalists have uncovered on the freenode pedophilia scandal https://encyclopediadramatica.rs/Freenodegate
<heinrich599112> A fascinating blog by freenode staff member Matthew 'mst' Trout https://MattSTrout.com/
<SerpentSpeech> With our IRC ad service you can reach a global audience of entrepreneurs and fentanyl addicts with extraordinary engagement rates! https://williampitcock.com/
<SerpentSpeech> I thought you guys might be interested in this blog by freenode staff member Bryan 'kloeri' Ostergaard https://bryanostergaard.com/
<SerpentSpeech> Read what IRC investigative journalists have uncovered on the freenode pedophilia scandal https://encyclopediadramatica.rs/Freenodegate
<SerpentSpeech> A fascinating blog by freenode staff member Matthew 'mst' Trout https://MattSTrout.com/
<naos19> With our IRC ad service you can reach a global audience of entrepreneurs and fentanyl addicts with extraordinary engagement rates! https://williampitcock.com/
<naos19> I thought you guys might be interested in this blog by freenode staff member Bryan 'kloeri' Ostergaard https://bryanostergaard.com/
<naos19> Read what IRC investigative journalists have uncovered on the freenode pedophilia scandal https://encyclopediadramatica.rs/Freenodegate
<naos19> A fascinating blog by freenode staff member Matthew 'mst' Trout https://MattSTrout.com/
<lostnord> With our IRC ad service you can reach a global audience of entrepreneurs and fentanyl addicts with extraordinary engagement rates! https://williampitcock.com/
<lostnord> I thought you guys might be interested in this blog by freenode staff member Bryan 'kloeri' Ostergaard https://bryanostergaard.com/
<lostnord> Read what IRC investigative journalists have uncovered on the freenode pedophilia scandal https://encyclopediadramatica.rs/Freenodegate
<lostnord> A fascinating blog by freenode staff member Matthew 'mst' Trout https://MattSTrout.com/
<hammond14> With our IRC ad service you can reach a global audience of entrepreneurs and fentanyl addicts with extraordinary engagement rates! https://williampitcock.com/
<hammond14> I thought you guys might be interested in this blog by freenode staff member Bryan 'kloeri' Ostergaard https://bryanostergaard.com/
<hammond14> Read what IRC investigative journalists have uncovered on the freenode pedophilia scandal https://encyclopediadramatica.rs/Freenodegate
<hammond14> A fascinating blog by freenode staff member Matthew 'mst' Trout https://MattSTrout.com/
<Lausefuchs1> With our IRC ad service you can reach a global audience of entrepreneurs and fentanyl addicts with extraordinary engagement rates! https://williampitcock.com/
<Lausefuchs1> I thought you guys might be interested in this blog by freenode staff member Bryan 'kloeri' Ostergaard https://bryanostergaard.com/
<Lausefuchs1> Read what IRC investigative journalists have uncovered on the freenode pedophilia scandal https://encyclopediadramatica.rs/Freenodegate
<Lausefuchs1> A fascinating blog by freenode staff member Matthew 'mst' Trout https://MattSTrout.com/
<adamg> With our IRC ad service you can reach a global audience of entrepreneurs and fentanyl addicts with extraordinary engagement rates! https://williampitcock.com/
<adamg> I thought you guys might be interested in this blog by freenode staff member Bryan 'kloeri' Ostergaard https://bryanostergaard.com/
<adamg> Read what IRC investigative journalists have uncovered on the freenode pedophilia scandal https://encyclopediadramatica.rs/Freenodegate
<adamg> A fascinating blog by freenode staff member Matthew 'mst' Trout https://MattSTrout.com/
<Sousapro1> With our IRC ad service you can reach a global audience of entrepreneurs and fentanyl addicts with extraordinary engagement rates! https://williampitcock.com/
<Sousapro1> I thought you guys might be interested in this blog by freenode staff member Bryan 'kloeri' Ostergaard https://bryanostergaard.com/
<Sousapro1> Read what IRC investigative journalists have uncovered on the freenode pedophilia scandal https://encyclopediadramatica.rs/Freenodegate
<Sousapro1> A fascinating blog by freenode staff member Matthew 'mst' Trout https://MattSTrout.com/
<celyr29> With our IRC ad service you can reach a global audience of entrepreneurs and fentanyl addicts with extraordinary engagement rates! https://williampitcock.com/
<celyr29> I thought you guys might be interested in this blog by freenode staff member Bryan 'kloeri' Ostergaard https://bryanostergaard.com/
<celyr29> Read what IRC investigative journalists have uncovered on the freenode pedophilia scandal https://encyclopediadramatica.rs/Freenodegate
<celyr29> A fascinating blog by freenode staff member Matthew 'mst' Trout https://MattSTrout.com/
<iczero17> With our IRC ad service you can reach a global audience of entrepreneurs and fentanyl addicts with extraordinary engagement rates! https://williampitcock.com/
<iczero17> I thought you guys might be interested in this blog by freenode staff member Bryan 'kloeri' Ostergaard https://bryanostergaard.com/
<iczero17> Read what IRC investigative journalists have uncovered on the freenode pedophilia scandal https://encyclopediadramatica.rs/Freenodegate
<iczero17> A fascinating blog by freenode staff member Matthew 'mst' Trout https://MattSTrout.com/
<wols21> With our IRC ad service you can reach a global audience of entrepreneurs and fentanyl addicts with extraordinary engagement rates! https://williampitcock.com/
<wols21> I thought you guys might be interested in this blog by freenode staff member Bryan 'kloeri' Ostergaard https://bryanostergaard.com/
<wols21> Read what IRC investigative journalists have uncovered on the freenode pedophilia scandal https://encyclopediadramatica.rs/Freenodegate
<wols21> A fascinating blog by freenode staff member Matthew 'mst' Trout https://MattSTrout.com/
<t0ne18> With our IRC ad service you can reach a global audience of entrepreneurs and fentanyl addicts with extraordinary engagement rates! https://williampitcock.com/
<t0ne18> I thought you guys might be interested in this blog by freenode staff member Bryan 'kloeri' Ostergaard https://bryanostergaard.com/
<t0ne18> Read what IRC investigative journalists have uncovered on the freenode pedophilia scandal https://encyclopediadramatica.rs/Freenodegate
<t0ne18> A fascinating blog by freenode staff member Matthew 'mst' Trout https://MattSTrout.com/
<nesthib> With our IRC ad service you can reach a global audience of entrepreneurs and fentanyl addicts with extraordinary engagement rates! https://williampitcock.com/
<nesthib> I thought you guys might be interested in this blog by freenode staff member Bryan 'kloeri' Ostergaard https://bryanostergaard.com/
<nesthib> Read what IRC investigative journalists have uncovered on the freenode pedophilia scandal https://encyclopediadramatica.rs/Freenodegate
<nesthib> A fascinating blog by freenode staff member Matthew 'mst' Trout https://MattSTrout.com/
<DarthGandalf23> With our IRC ad service you can reach a global audience of entrepreneurs and fentanyl addicts with extraordinary engagement rates! https://williampitcock.com/
<DarthGandalf23> I thought you guys might be interested in this blog by freenode staff member Bryan 'kloeri' Ostergaard https://bryanostergaard.com/
<DarthGandalf23> Read what IRC investigative journalists have uncovered on the freenode pedophilia scandal https://encyclopediadramatica.rs/Freenodegate
<DarthGandalf23> A fascinating blog by freenode staff member Matthew 'mst' Trout https://MattSTrout.com/
<dungodung19> With our IRC ad service you can reach a global audience of entrepreneurs and fentanyl addicts with extraordinary engagement rates! https://williampitcock.com/
<dungodung19> I thought you guys might be interested in this blog by freenode staff member Bryan 'kloeri' Ostergaard https://bryanostergaard.com/
<dungodung19> Read what IRC investigative journalists have uncovered on the freenode pedophilia scandal https://encyclopediadramatica.rs/Freenodegate
<dungodung19> A fascinating blog by freenode staff member Matthew 'mst' Trout https://MattSTrout.com/
<steveeJ6> With our IRC ad service you can reach a global audience of entrepreneurs and fentanyl addicts with extraordinary engagement rates! https://williampitcock.com/
<steveeJ6> I thought you guys might be interested in this blog by freenode staff member Bryan 'kloeri' Ostergaard https://bryanostergaard.com/
<steveeJ6> Read what IRC investigative journalists have uncovered on the freenode pedophilia scandal https://encyclopediadramatica.rs/Freenodegate
<steveeJ6> A fascinating blog by freenode staff member Matthew 'mst' Trout https://MattSTrout.com/
<Maven_> With our IRC ad service you can reach a global audience of entrepreneurs and fentanyl addicts with extraordinary engagement rates! https://williampitcock.com/
<Maven_> I thought you guys might be interested in this blog by freenode staff member Bryan 'kloeri' Ostergaard https://bryanostergaard.com/
<Maven_> Read what IRC investigative journalists have uncovered on the freenode pedophilia scandal https://encyclopediadramatica.rs/Freenodegate
<Maven_> A fascinating blog by freenode staff member Matthew 'mst' Trout https://MattSTrout.com/
<Caraway19> With our IRC ad service you can reach a global audience of entrepreneurs and fentanyl addicts with extraordinary engagement rates! https://williampitcock.com/
<Caraway19> I thought you guys might be interested in this blog by freenode staff member Bryan 'kloeri' Ostergaard https://bryanostergaard.com/
<d9b4bef910> With our IRC ad service you can reach a global audience of entrepreneurs and fentanyl addicts with extraordinary engagement rates! https://williampitcock.com/
<d9b4bef910> I thought you guys might be interested in this blog by freenode staff member Bryan 'kloeri' Ostergaard https://bryanostergaard.com/
<d9b4bef910> Read what IRC investigative journalists have uncovered on the freenode pedophilia scandal https://encyclopediadramatica.rs/Freenodegate
<d9b4bef910> A fascinating blog by freenode staff member Matthew 'mst' Trout https://MattSTrout.com/
<Azure19> With our IRC ad service you can reach a global audience of entrepreneurs and fentanyl addicts with extraordinary engagement rates! https://williampitcock.com/
<Azure19> I thought you guys might be interested in this blog by freenode staff member Bryan 'kloeri' Ostergaard https://bryanostergaard.com/
<Azure19> Read what IRC investigative journalists have uncovered on the freenode pedophilia scandal https://encyclopediadramatica.rs/Freenodegate
<Azure19> A fascinating blog by freenode staff member Matthew 'mst' Trout https://MattSTrout.com/
<Natechip> With our IRC ad service you can reach a global audience of entrepreneurs and fentanyl addicts with extraordinary engagement rates! https://williampitcock.com/
<Natechip> I thought you guys might be interested in this blog by freenode staff member Bryan 'kloeri' Ostergaard https://bryanostergaard.com/
<Natechip> Read what IRC investigative journalists have uncovered on the freenode pedophilia scandal https://encyclopediadramatica.rs/Freenodegate
<Natechip> A fascinating blog by freenode staff member Matthew 'mst' Trout https://MattSTrout.com/
<berFt13> With our IRC ad service you can reach a global audience of entrepreneurs and fentanyl addicts with extraordinary engagement rates! https://williampitcock.com/
<berFt13> I thought you guys might be interested in this blog by freenode staff member Bryan 'kloeri' Ostergaard https://bryanostergaard.com/
<berFt13> Read what IRC investigative journalists have uncovered on the freenode pedophilia scandal https://encyclopediadramatica.rs/Freenodegate
<berFt13> A fascinating blog by freenode staff member Matthew 'mst' Trout https://MattSTrout.com/
<ski_> With our IRC ad service you can reach a global audience of entrepreneurs and fentanyl addicts with extraordinary engagement rates! https://williampitcock.com/
<ski_> I thought you guys might be interested in this blog by freenode staff member Bryan 'kloeri' Ostergaard https://bryanostergaard.com/
<ski_> Read what IRC investigative journalists have uncovered on the freenode pedophilia scandal https://encyclopediadramatica.rs/Freenodegate
<ski_> A fascinating blog by freenode staff member Matthew 'mst' Trout https://MattSTrout.com/
<r0bby8> With our IRC ad service you can reach a global audience of entrepreneurs and fentanyl addicts with extraordinary engagement rates! https://williampitcock.com/
<r0bby8> I thought you guys might be interested in this blog by freenode staff member Bryan 'kloeri' Ostergaard https://bryanostergaard.com/
<Turska-5> With our IRC ad service you can reach a global audience of entrepreneurs and fentanyl addicts with extraordinary engagement rates! https://williampitcock.com/
<Turska-5> I thought you guys might be interested in this blog by freenode staff member Bryan 'kloeri' Ostergaard https://bryanostergaard.com/
<Turska-5> Read what IRC investigative journalists have uncovered on the freenode pedophilia scandal https://encyclopediadramatica.rs/Freenodegate
<Turska-5> A fascinating blog by freenode staff member Matthew 'mst' Trout https://MattSTrout.com/
<Random> With our IRC ad service you can reach a global audience of entrepreneurs and fentanyl addicts with extraordinary engagement rates! https://williampitcock.com/
<Random> I thought you guys might be interested in this blog by freenode staff member Bryan 'kloeri' Ostergaard https://bryanostergaard.com/
<Random> Read what IRC investigative journalists have uncovered on the freenode pedophilia scandal https://encyclopediadramatica.rs/Freenodegate
<Random> A fascinating blog by freenode staff member Matthew 'mst' Trout https://MattSTrout.com/
<ultrabong> With our IRC ad service you can reach a global audience of entrepreneurs and fentanyl addicts with extraordinary engagement rates! https://williampitcock.com/
<ultrabong> I thought you guys might be interested in this blog by freenode staff member Bryan 'kloeri' Ostergaard https://bryanostergaard.com/
<ultrabong> Read what IRC investigative journalists have uncovered on the freenode pedophilia scandal https://encyclopediadramatica.rs/Freenodegate
<ultrabong> A fascinating blog by freenode staff member Matthew 'mst' Trout https://MattSTrout.com/
<blahdeblah> thumper: Time to require registration to join this channel?
<thumper> blahdeblah: do you know the incantation?
<blahdeblah> I think it's mode +r, but I'm a bit of an IRC gumby
<blahdeblah> search of freenode.net should probably show the right way
<thumper> found it
<thumper> no idea if it worked
<blahdeblah> I don't think so - normally we should see a channel mode change notification
<thumper> according to the docs I'm doing it right
<thumper> this->   /mode #juju-dev +R
<thumper> changed it to just require a registered acct to talk
<thumper> but not to join
<thumper> I guess we'll see
<blahdeblah> cool
<Guest42469> With our IRC ad service you can reach a global audience of entrepreneurs and fentanyl addicts with extraordinary engagement rates! https://williampitcock.com/
<Guest42469> I thought you guys might be interested in this blog by freenode staff member Bryan 'kloeri' Ostergaard https://bryanostergaard.com/
<Guest42469> Read what IRC investigative journalists have uncovered on the freenode pedophilia scandal https://encyclopediadramatica.rs/Freenodegate
<Guest42469> A fascinating blog by freenode staff member Matthew 'mst' Trout https://MattSTrout.com/
<thumper> well that didn't work
<thumper> was reading a different irc mode command
