#juju-dev 2013-02-11
<davecheney> fwereade_: pin
<davecheney> ping
<davecheney> does goose support the lcy02 region ?
<bigjools> perhaps wallyworld_ would know that
<wallyworld_> yes, it should
<wallyworld_> i've only used the lcy01 region myself, but there's no reason lcy02 should not work
<davecheney> wallyworld_: i'm trying to work around the lack of public IP's in lcy01
<davecheney> how can I use lcy02 ?
<wallyworld_> you can delete some i think
<davecheney> different keystone url ?
<wallyworld_> to return them to the pool
<davecheney> wallyworld_: i never had any to start with
<wallyworld_> let me check something'
<wallyworld_> davecheney: the keystone url should be the same, you just change OS_REGION_NAME
<wallyworld_> to use a different rgion
<wallyworld_> i normally use "nova floating-ip-list" to see what floating ips are used
<wallyworld_> and then delete them so that they can be re-used
<davecheney> wallyworld_: what is the config value in juju/environments.yaml that matches OS_REGION_NAME ? region ? (guess)
<davecheney> i don't understand what you mean my delete floating ip's
<davecheney> i don't own any floating ips to delete
<wallyworld_> should be "region" in the yaml
<wallyworld_> i didn't think i owned any floating ips either - i thought there was a pool we could all share
<wallyworld_> and we were allowed 2 or 3 each
<davecheney> trying lcy02, still don't understand about delete
<davecheney> 2013/02/11 12:49:23 JUJU environs/openstack: opening environment "canonistack"
<davecheney> 2013/02/11 12:49:23 JUJU environs/openstack: bootstrapping environment "canonistack"
<davecheney> 2013/02/11 12:49:28 JUJU environs: searching for tools compatible with version: 1.9.8-quantal-amd64
<davecheney> 2013/02/11 12:49:32 JUJU juju bootstrap command failed: cannot start bootstrap instance: cannot allocate a public IP as needed
<davecheney> error: cannot start bootstrap instance: cannot allocate a public IP as needed
<davecheney> lucky(~) % nova floating-ip-list
<davecheney> ^ non
<wallyworld_> delete deallocates a floating ip so it can be reused
<wallyworld_> nova floating-ip-delete <address>
<wallyworld_> hmmm. i see no floating ips either
<davecheney> wallyworld_: i have no floating ips too delete
<wallyworld_> i could have sworn that there were some around last week
<davecheney> wallyworld_: https://pastebin.canonical.com/84346/
<davecheney> get a weird error when the region is not known
<wallyworld_> the error makes sense given how the internals work - authentication worked and it gave backa list of endpoints per region. the region you had didn't match any so there were no endpoints available
<wallyworld_> perhaps the error can be reworded
<davecheney> wallyworld_: raise a bug ? or leave it for later ?
<wallyworld_> a bug would be great
<davecheney> no wukks
<wallyworld_> i have no idea about the lack of floating ips though
<davecheney> i might have to go groveling back to HP an ask to reopen my hp cloud account
<wallyworld_> i really think we should get some canonistack ones so we can devel/test easily etc
<davecheney> seconded
<davecheney> noted in meeting agenda
<wallyworld_> \o/
<wallyworld_> davecheney: there is a hp account martin has which he has shared the credentials with the blue squad - i can send you those?
<davecheney> wallyworld_: please
<davecheney> i forget why I closed my account with HPO
<wallyworld_> ok, will find email and send
<davecheney> I think they screwed me on billing or something
<wallyworld_> email sent
<davecheney> danku
<wallyworld_> np, anytime
<jam> wallyworld_: morning!
<wallyworld_> hello, mumble?
<jam> davecheney: just as an aside, we've been requested to use the AZ3 compute zone for testing, as it is supposed to be the lowest utilization for canonical.
<davecheney> jam: right
<davecheney> never heard of that one
<davecheney> jam: having trouble connecting to that region
<jam> davecheney: we're talking about HP now, right?
<davecheney> nope
<davecheney> i thought you were talking about canonistack
<jam> sorry, yeah on HP cloud we want to use az3, on canonistack we *should* work with lcy02, but my understanding is it has been updated to Grizzly, so isn't quite the same as lcy01
<davecheney> jam: i cannot bootstrap in any canonistack regions
<davecheney> no EYE PEES availble
<jam> davecheney: right, go-juju now connects directly to mongo, so it needs to have a floating IP because the ssh tunnelling doesn't work.
<jam> and lcy01 is running out of *virtual* IPs (the region is limited to a class C, and apparently we are running out of that address space)
<dimitern> mornings :)
<rogpeppe> goood morning!
<rogpeppe> davecheney: hiya
<davecheney> hi rogpeppe
<davecheney> i'm just steppig out to the shops
<davecheney> back in a bit
<rogpeppe> davecheney: nice to see your post to golang-nuts
<rogpeppe> davecheney: BTW i've got a couple of CLs out for review that i'd be interested in your comments on
<davecheney> rogpeppe: sure, i'll have a look after dinner
<rogpeppe> https://codereview.appspot.com/6878052/ and https://codereview.appspot.com/7299066/
<TheMue> lunchtime
<fwereade_> jam, ping
<fwereade_> jam2, ping
<jam2> fwereade_: pong
<fwereade_> jam, so, I was wondering whether you guys had had an opportunity to look over the get/set/upgrade-charm treatment I sent a few days ago
<jam> fwereade_: we haven't looked deeply at it, it isn't in our immediate work
<fwereade_> jam, ok, cool -- my understanding was that someone would be starting on that front pretty soon, I guess that was inaccurate
<jam> fwereade_: it was on the list of "things we could look at next", but there are enough things we're going to be picking on some of the smaller ones first
<jam> ease ourselves into it.
<fwereade_> jam, ok -- tbh most of the stuff on there is kinda necessary for parity, so it deserves at least a bit of attention sooner than later
<fwereade_> jam, and there are definitely some easy bits there that can help you to get started
<fwereade_> jam, so perhaps some of us could have a chat about it after the team meeting tomorrow? I might be able to make the simple starting points a little clearer
<fwereade_> jam, this is not to say that I don't appreciate the sanity of your strategy :)
 * fwereade_ => lunch
<niemeyer> Goood morning
<dimitern> niemeyer: hiya
<rogpeppe> niemeyer: yo!
<jam> mgz: poke for great mumbling?
<mgz> hey :D
<jam> mramm2: are we doing 8UTC tomorrow, or is that not starting until next week?
<mramm2> tomorrow
<rogpeppe> fwereade_: concurrent rpc requests: https://codereview.appspot.com/7307090
<fwereade_> rogpeppe, cheers
<rogpeppe> fwereade_: i'm hoping i might have a review of those other api-related branches at some point :-)
<rogpeppe> fwereade_: i have a first watcher implementation mostly done BTW
<rogpeppe> fwereade_: g+?
<fwereade_> rogpeppe, omw
 * rogpeppe goes for some lunch.
<niemeyer> rogpeppe: ping
<rogpeppe> niemeyer: pong
<niemeyer> rogpeppe: Heya
<rogpeppe> niemeyer: hiya, how's tricks?
<niemeyer> rogpeppe: I've added some further hardening on the multi upload branch
<rogpeppe> niemeyer: cool
<niemeyer> rogpeppe: There was one bug related to retries that was breaking tests
<niemeyer> rogpeppe: Do you want to have a look at the delta before submitting: https://codereview.appspot.com/7237068
<rogpeppe> niemeyer: ok, will do
<niemeyer> rogpeppe: There shouldn't be anything  controversial there
<niemeyer> rogpeppe: Except for some occasional long-time S3 errors, I'm able to run tests quite well now
<rogpeppe> niemeyer: i'm looking at it, BTW
<niemeyer> rogpeppe: Thanks!
<rogpeppe> niemeyer: where was the bug? in S3.prepare, i presume, but i can't see quite what the problem was, or how the changes have fixed it (the new code looks fine BTW, i'm just interested)
<niemeyer> rogpeppe: Retrying would corrupt req.path due to how prepare was implemented
<rogpeppe> niemeyer: ah, yes, req.path would keep on growing
<niemeyer> rogpeppe: THat's right
<niemeyer> rogpeppe: Live tests picked it up
<rogpeppe> niemeyer: LGTM then
<niemeyer> rogpeppe: Awesome, cheers
<rogpeppe> that's me for the day
<rogpeppe> g'night all
<thumper> mramm: is there a calendar that I should be looking at?
<thumper> mramm: got an email with an agenda for today
<thumper> mramm: but no time specified for the meeting
<thumper> mramm: hmm.. also guessing that the date is US local?
<thumper> so tomorrow, not today?
<mramm> yea
<mramm> yea
<mramm> I will get you on the calendar invite right away
<mramm> you are now on the invite, I'm also adding you to the juju-core calendar which we use for vacations and whatnot
<thumper> mramm: ta
<hazmat> thumper, welcomes
<thumper> hi hazmat
<thumper> hazmat: should be interesting :)
 * thumper goes in search of more coffee
#juju-dev 2013-02-12
<thumper> davecheney: are you available for a hangout later?
<davecheney> thumper: i certainly am
<davecheney> you are 2 ? 3 ? hours ahead of me ?
<davecheney> thumper: if you're still around, are you free to chat ?
<thumper> davecheney: hey
<thumper> davecheney: let me just check on the family...
<davecheney> if you want, we can try agian tomorrow
<davecheney> maybe it would make more sense after le' meeting
<davecheney> probably a better time for your anyway
<thumper> davecheney: let me just check on the family...\
<thumper> ugh
<thumper> stupid up arrow
<niemeyer> davecheney: yo
<niemeyer> What's up folks
<niemeyer> thumper: Heya, welcome to juju
<thumper> hi niemeyer
<thumper> thanks
<thumper> niemeyer: I have been thinking serioursly about it now since we kinda chatted in miami about it
<thumper> then it was more of a joke
<thumper> happy to be on board now
 * thumper needs to go and make dinner
<thumper> niemeyer: isn't it late for you?
<niemeyer> thumper: Yeah, I figured by then, but when we talked recently I got the impression you were actually jumping in
<niemeyer> thumper: Depends on the point of view
<niemeyer> thumper: It's about to be early too :)
<thumper> :)
<thumper> I suppose it matters if you have slept yet or not
<thumper> niemeyer: I was going to just rotate in for a short while
<thumper> but in the end, it became more of a dive
<thumper> longer term
<niemeyer> thumper: Very happy to hear that
<thumper> it'll be fun
<thumper> I've been keeping a file of questions :)
<thumper> it is getting quite long now
<thumper> some I have found out myself by reading more
<thumper> others are still open
<thumper> but I have some calls scheduled with jcastro and davecheney now
<niemeyer> thumper: It's a brilliant team to be part of, and it's even better with you in
<thumper> thanks for that :-)
<thumper> I'm love working with smart people
<thumper> makes for interesting times
<thumper> s/I'm/I/
 * thumper steps away from the keyboard to go make dinner
<rogpeppe> morning all!
<TheMue> morning rogpeppe
<dimitern> morning!
 * TheMue just listens to The Dark Side of the Moon, 40 years of great music ...
<dimitern> ready for an early meeting? ;)
<dimitern> TheMue: +1, yeah, oldies-goldies
<TheMue> dimitern: Early? What shall Mark say? :D
<dimitern> :)
<dimitern> it's actually late there
<dimitern> too late to be early
<TheMue> dimitern: Hehe, indeed also a way to handle it.
<davecheney> morning
<dimitern> davecheney: evening :)
<davecheney> touche
<TheMue> davecheney: hiya
<thumper> hmm...
<thumper> I hope this doesn't get too confusing
<thumper> in another channel there is TheMuso
<TheMue> thumper: Never had any conflicts.
<TheMue> thumper: In 1997 mue has been enough, but later often other people claimed it.
<jam> https://plus.google.com/hangouts/_/3054ca9e05632bb677f4a136cc956486d9aac90f
<jam> for anyone not here yet
<mgz> ta
<rogpeppe> TheMue: ^
<jam> mgz: w7z: https://plus.google.com/hangouts/_/3054ca9e05632bb677f4a136cc956486d9aac90f
<rogpeppe> fwereade_: ^
<davecheney> hold up, installing pluginz
<TheMue> rogpeppe: ah, thx, link in calendar doesn't work
<davecheney> and the hangout plugin segfualted
<rogpeppe> joy...
<davecheney> hmm, can't talk to any google properties at the moment
<davecheney> anyone else dropped off ?
<thumper> davecheney: haha
<thumper> davecheney: no, just you
<rogpeppe> nope, sorry
<davecheney> nope, no route to google properties at the moment
<rogpeppe> mark's talking about making a kanban board for the command line stuff
<davecheney> +1
<rogpeppe> 'cos there's a big scrum on that
<davecheney> any it's still in the design phase, as I understand it
<rogpeppe> "if we get more need for coordination, we can try having a scrum-of-scrums meeting"
<rogpeppe> davecheney: is it working for you now?
<rogpeppe> davecheney: apparently not :-)
<davechen1y> got a few mins
<davechen1y> then dropped out again
<davechen1y> mark was very choppy
<davechen1y> all my google services have eaten a goose egg
<davechen1y> gmail is slow
<davechen1y> can't get to plus anymore
<rogpeppe> we're talking about the floating ip problem
<davechen1y> please take notes
<rogpeppe> essentially: floating ips are in limited supply and we need some way to work around that
<Pavel_> Is there any kind of framework for writing new Charms? At least with ability to handle templates?
<Pavel_> It could be great to have some kind of dsl for common cases. Something like Chef have.
<Pavel_> Another thing I thought about is custom events, not only joined, changed, broken and departed but any user defined. For now this can be done via relation_ids and relation_set but it seems like workaround for the case.
<Pavel_> Do you have such thing in your plans?
<jam> mgz: do you remember the rt # +
<jam> ?
<mramm> thanks everybody for a productive meeting
<rogpeppe> Pavel_: a framework for writing charms is a reasonable idea. i think various people have python helper scripts, which could be a start. lots of places to explore here.
<TheMue> so, lunchtime, biab
<rogpeppe> interesting, live tests against the "enable password checking" branch fail because the tests try to access an api.Machine, which is denied by our policy rules.
<jcastro> rogpeppe: did you guys know there's a discussion on juju/go on reddit? http://www.reddit.com/r/programming/comments/18atce/juju_canonical_109k_lines_of_go_code/
<rogpeppe> jcastro: nope, hadn't seen that, ta!
<jcastro> tell the team, the discussion looks interesting enough for you guys to participate in
<teknico> is the 32-bit 2.2.3 MongoDb version on the website good for using with Juju?
<teknico> everything on http://juju-dist.s3.amazonaws.com/ is 64-bit
<rogpeppe> fwereade_: i had to make a slightly more extensive change than i'd expected in response to the live test failure - i implemented the Client type and a skeleton Status method so that live tests could talk to it. would appreciate if you could have another look: https://codereview.appspot.com/7299066
 * fwereade_ looks
<fwereade_> rogpeppe, LGTM if you write a bug for Client.Status, I don't imagine that's going to be a priority for a couple of days so it's good to have it tracked
<fwereade_> rogpeppe, (just that it's very unfinished)
<rogpeppe> fwereade_: ok, i'll make a ticket
<rogpeppe> fwereade_: done
<rogpeppe> fwereade_: there are a couple of unresolved comments i responded to too. https://codereview.appspot.com/7299066/diff/3007/state/api/apiserver.go#newcode117 and https://codereview.appspot.com/7299066/diff/3007/state/api/client.go#newcode31 in particular
<fwereade_> rogpeppe, sorry, missed those; thanks; responded
<rogpeppe> fwereade_: thanks
<rogpeppe> fwereade_: i've just seen a slightly concerning live test failure: http://paste.ubuntu.com/1639959/
<rogpeppe> fwereade_: the jujutest code looks plausible, but it seems the unit hasn't gone properly. is it doing something wrong?
<rogpeppe> fwereade_: (that was in my branch, which i don't *think* would impact that behaviour, but am testing in trunk now)
<fwereade_> rogpeppe, heh, that's that totally crackful bit
<rogpeppe> fwereade_: ah, i wondered if that was the case
<fwereade_> rogpeppe, niemeyer's comment is a bit out of date but correct in intent
<rogpeppe> fwereade_: how *should* it remove the unit so it can remove the machine?
<rogpeppe> fwereade_: the kitchen sink comment?
<rogpeppe> fwereade_: ah no, i see
<fwereade_> rogpeppe, I think it should be: (1) destroy unit, wait removed (2) destroy machine, wait removed
<fwereade_> rogpeppe, I can see that that is maybe inconvenient for you though
<fwereade_> rogpeppe, and, hmm, I think there's a bug pointing out that the provisioner doesn't actually remove dead machines
<rogpeppe> fwereade_: hmm, there should be convenience methods in juju.Conn to remove units and machines, presumably?
<fwereade_> rogpeppe, huh, can't see it obviously, I'm sure I saw it yesterday
<fwereade_> rogpeppe, yeah, there's DestroyUnits and DestroyMachines IIRC
<rogpeppe> fwereade_: presumably it *did* work, otherwise that test would never have passed
<fwereade_> rogpeppe, yeah, but it's also total nonsense -- it tells us nothing about whether anything is working as expected and if anything just causes trouble by doing things that deployed code is expecting to do itself
<rogpeppe> fwereade_: really? it seems to verify that something is responding to machine removals by stopping instances, doesn't it?
<fwereade_> rogpeppe, yeah, must have been seeing things, provisioner looks like it should work
<rogpeppe> fwereade_: should we just lose that part of the test and assume that the deployer is adequately tested? or perhaps you've got a better way of testing that things are working live?
<fwereade_> rogpeppe, I tend to test live stuff by hand, I have more opportunities to do surprising things and see what happens ;)
<rogpeppe> fwereade_: i do too, but i think it's important to have some automated tests too
<fwereade_> rogpeppe, I'd really prefer it if we did have that part of the test doing something sane
<fwereade_> rogpeppe, it's not exactly an edge case, seems perverse to leave it out
<rogpeppe> fwereade_: so it would be ok to do the above dance (destroy unit, wait destroyed, destroy machine, wait destroyed) ?
<fwereade_> rogpeppe, I think it should be, yes
<fwereade_> rogpeppe, that's the expected interaction
<rogpeppe> fwereade_: ok, i'll add a TODO ticket for that.
<fwereade_> rogpeppe, ok, cool
<fwereade_> need to go to the shops; might not get back to work tonight
<rogpeppe> fwereade_: i'm going soon too
<rogpeppe> fwereade_: see ya tomorrow, probs
<TheMue> Yeah! Putting files works fine too. Will only extend it to a table driven test tomorrow.
<rogpeppe> yay, all the outstanding api branches now submitted!
<TheMue> rogpeppe: grats
<rogpeppe> good place to stop. g'night all.
<thumper> hi jcastro
<jcastro> thumper: fire up a G+
<thumper> kk
<thumper> jcastro: created
<thumper> jcastro: http://docutils.sourceforge.net/docs/user/rst/quickref.html
<davecheney> thumper: any time you're ready
<thumper> hi davecheney
<thumper> I'm in the middle of writing an email about constraints, but I have a feeling it will be a while, so lets chat now :)
<davecheney> nah, it can wait
<davecheney> you're documenting stuff
<davecheney> that trumps everything
<thumper> ok, after lunch then :)
<davecheney> kk
<thumper> although not so much documenting stuff, but arguing :)
<thumper> and trying to get a better understanding
<thumper> I'm already getting plans and ideas
<thumper> I just hope that then end up sounding rational and useful
<davecheney> if you could see your way clear to cc'ing juju-dev, that would be awesome
<davecheney> too much silo'ing atm
<thumper> who's on juju-dev mailing list?
<thumper> it seems that only the admin can see the subscriber list
<davecheney> thumper: well, it is all of us devs
<davecheney> it is public
<davecheney> gustavo or william is probably the admin
<thumper> davecheney: my only concern about taking it public is that the chat started private, and I'm always careful about dragging conversations public without letting the others know first
<thumper> however I'll do more of a scan
<thumper> and remove anything that could be construed weird
<davecheney> thumper: understood, see previous head shaking about silo'ing
<thumper> mramm: got any objections to me taking the constraints email public?
<thumper> davecheney: it was partly for my benefit as I'm still grappling with many concepts
<davecheney> thumper: understood that email is a poor documentation medium, but it is better than what we have at the moment
<fwereade_> thumper, fwiw I'm happy to have the discussion in public
<thumper> fwereade_: awesome, I've cut out most of the initial email and your reply, just leaving relevant bits
<thumper> just finishing off the reply now
<fwereade_> thumper, cool, cheers
 * thumper heads out for an early lunch
<thumper> davecheney: I'll ping you when I'm back
<fwereade_> thumper, I'm not sure I'll answer that tonight; when you return you might find that some of it has been covered in the recent thread starting at https://lists.ubuntu.com/archives/juju-dev/2013-February/000479.html
#juju-dev 2013-02-13
<thumper> davechen1y: ping
<davechen1y> ack
<davechen1y> thumper: ack
<thumper> davecheney: hangout?
<davecheney> yy
<thumper> davecheney: have you got video working?
<davecheney> no video on this x220
<thumper> why?
<thumper> that is a thinkpad right?
<davecheney> you can video, but bodgy sound (via n7) or good sound, and no video
<thumper> davecheney: what about skype?
<davecheney> sure, lemme install it
<davecheney> i had al lthe tools on my mac
<davecheney> but it died while I was on vacation
<thumper> :(
<davecheney> and a long series of sad stories and trips to the apple store have not resulted in it working again
<thumper> I've tried to avoid apple hardware as much as possible
<thumper> don't want to start down that track
<thumper> I do know others that are almost 100% in to it
<thumper> like popey and njpatel
<davecheney> i think avoiding it is a good idea
<davecheney> they use bcm wifi chips which are poorly supported
<thumper> so I'm looking for a non-apple macbook air type equivalent
<thumper> small, thin, metallic (robust), with good battery life
<davecheney> stay away from dells
<davecheney> they are all junk
<davecheney> the X1 isn't bad
<davecheney> lenvovo x1
<davecheney> some of the samsung ultrabooks are quite nice
<davecheney> byut hard to get in au
<thumper> oh, I forgot cheap (ish)
<davecheney> so i havne't seen many in the flesh
<thumper> I've seen quite a few samsung ultrabooks here
<thumper> jb hifi has them here
<davecheney> some are ok, some are just weird
<davecheney> stay away from sony stuff, that is actually wierd
<davecheney> weird
<thumper> I had a sony laptop a while back, proprietary hardware, non-open drivers caused a pain
<davecheney> yeah, total crap shoot
<davecheney> asus make a lot of models
<davecheney> its going to have very very stock hardware inside
<davecheney> some of them are ok, but for me it is hard to shake their reputation as making cheap and nasty kit
<davecheney> thumper: it's lunch o clock now, afk for prob 40-60 mins to get some lunch for me and my misses
<thumper> davecheney: ack
<thumper> davecheney: let me know when you're back
 * thumper afk for a bit
<davecheney> thumper: ping
<thumper> hey, just otp
<davecheney> no wuks
<thumper> kk , ready now
<thumper> davecheney: skype again?
<davecheney> y
<rogpeppe> mornin' all
<elimisteve> morning
<dimitern> hey all, william asked me to tell you there's a power cut in his area at present, in case you wonder where is he
<TheMue> dimitern_afk: Thx for the notification. And good morning btw. ;)
<elimisteve> any estimates on when juju 2.0 will be out?
<elimisteve> good job making so much progress on the Go port, all. Very exciting...
<elimisteve> is v2.0 when the Go version will be the primary one that you encourage people to use?
<jam> elimisteve: the goal is to have the Go port the default version for 13.04 (Ubuntu Raring)
<elimisteve> jam: great, thanks
<dimitern> TheMue: morning :)
<TheMue> dimitern: Hiya
<dimitern> i think it's high time to do something about keeping the channel topic in sync with what's happening in the project, so the people could get an idea quickly, like #launchpad channels
<TheMue> dimitern: oh, yes, good hint
<rogpeppe> fwereade: yo!
<rogpeppe> fwereade: power back then, i guess
<dimitern> fwereade: hey
<fwereade> rogpeppe, heyhey; and, yeah, a little while ago, but I forgot to open irc again ;0
<fwereade> dimitern, heyhey
<fwereade> rogpeppe, I'm getting the rpc module tests timing out after 600s
<rogpeppe> fwereade: i *just* realised that i forgot to put in the timeouts you requested
<fwereade> rogpeppe, haha
<rogpeppe> fwereade: am currently editing rpc_test.go!
<rogpeppe> fwereade: (as of 5 mins ago...)
 * fwereade gets to feel all smug and prophetic ;p
<rogpeppe> bah :-)
<dimitern> fwereade: do you want to discuss shortly https://codereview.appspot.com/7301085/ ?
<fwereade> dimitern, sgtm, I'll start a hangout
<dimitern> fwereade: cool
<dimitern> fwereade: actually, since it's almost standup time, can we do it around 13h?
<jam> allenap: poke
<jam> I'm just checking on https://code.launchpad.net/~allenap/juju-core/break-out-juju-store/+merge/142564
<jam> and seeing if you need it landed, or if it needs updating, etc.
<allenap> jam: Hello.
<jam> The last comment was only a few days ago, so I think I can just land it for you/
<jam> ?
<allenap> jam: I /think/ it's up to date, but I'll check.
<fwereade> dimitern, ah, yeah, sure -- might be eating then, but ping me when you're free and we'll figure something out
<dimitern> fwereade: sure, no rush
<TheMue> lunchtime
<niemeyer> rogpeppe: Anything else on https://codereview.appspot.com/7313081/?
<rogpeppe> niemeyer: looking
<rogpeppe> niemeyer: i think zero is a reasonable length for a file, and i think think PutAll should work with all files
<niemeyer> rogpeppe: It's not up to us
<niemeyer> rogpeppe: It does work, though
<niemeyer> rogpeppe: But we can't test that live
<rogpeppe> niemeyer: why not?
<niemeyer> rogpeppe: Because it's not up to us whether an upload works with no content or not
<allenap> jam: Yes, it's up to date.
<rogpeppe> niemeyer: if it doesn't work, we should return an error
<niemeyer> rogpeppe: Amazon returns the error
<rogpeppe> niemeyer: if the file length is zero, we don't make any calls for amazon to return the error, no?
<niemeyer> rogpeppe: Multipart uploads of files of length zero do not work
<niemeyer> rogpeppe: I don't know what you're trying to achieve
<rogpeppe> niemeyer: i'd like to be able to iterate over all the files in a directory and call PutAll on each one, regardless of the file's size
<allenap> jam: Forgot to say: yes, please, I'd be grateful if you could land it :)
<rogpeppe> niemeyer: presumably you're allowed buckets holding zero-length files?
<niemeyer> rogpeppe: *multipart uploads*.. that's what this CL is about
<niemeyer> rogpeppe: and I can understand your desire.. you should file a bug against S3. :-)
<rogpeppe> niemeyer: PutAll works with a file that's 1 byte long. i think it should work if it's 0 bytes long, and i don't think it's hard to make it do that.
<rogpeppe> niemeyer: perhaps it should use multipart only where necessary.
<niemeyer> rogpeppe: PutAll is a method on Multi
<rogpeppe> niemeyer: ahem, good point :-)
<rogpeppe> niemeyer: well at the least, if multipart uploads of files of length zero don't work, we should return an error in that case.
<niemeyer> rogpeppe: Sorry, we're going in circles
<rogpeppe> [11:31:00] <niemeyer> rogpeppe: Multipart uploads of files of length zero do not work
<niemeyer> rogpeppe: Amazon will say so.. I don't think there's any benefit in us reporting it early
<niemeyer> <niemeyer> rogpeppe: Amazon returns the error
<rogpeppe> niemeyer: ah, you get the error from Complete?
<niemeyer> rogpeppe: It will fail in whatever way Amazon chooses to fail
<niemeyer> rogpeppe: Just like everything else
<niemeyer> rogpeppe: Look.. I can put an error result there if that makes you happier
<rogpeppe> niemeyer: ok, that seems reasonable - perhaps a doc comment rather than an error - amazon may fix it in the future, i suppose.
<niemeyer> rogpeppe: It may
<rogpeppe> niemeyer: (failing when amazon chooses to fail seems reasonable, i mean)
<niemeyer> rogpeppe: Cool
<rogpeppe> niemeyer: replied
<niemeyer> rogpeppe: Actually, I just found a way to make it work
<niemeyer> rogpeppe: I'll fix it
<rogpeppe> niemeyer: cool. the less edge cases, the better i like it :-)
<niemeyer> rogpeppe: Amazon happily takes it if I upload a part with zero content
<niemeyer> rogpeppe: It is an edge case still
<rogpeppe> niemeyer: only for goamz, not for the person using it, hopefully
<niemeyer> rogpeppe: It is an edge case for the API
<niemeyer> rogpeppe: People may not care in most sane cases, though
<niemeyer> rogpeppe: The result of len(parts) with no content is 1 rather than 0
<rogpeppe> niemeyer: yeah. it seems reasonable that a file should always have at least one part though.
<rogpeppe> niemeyer: even if it's zero-length.
<niemeyer> rogpeppe: It's an edge case.
<rogpeppe> niemeyer: agreed. seems like the least-surprises way forward though.
<niemeyer> rogpeppe: As I said, I'll fix it
<rogpeppe> niemeyer: cool, thanks.
<niemeyer> rogpeppe: np, thanks for the review
<niemeyer> In the future we can have an API in Bucket itself which chooses properly whether to upload a multipart or not based on size
<niemeyer> But I'd rather fix the overall package API first
<rogpeppe> niemeyer: that sounds good
<rogpeppe> niemeyer: i thought i remembered that dave cheney made some fixes to gocheck so that c.Logf wasn't racy if called in multiple goroutines. am i imagining things? (i get lots of errors from the race detector, which would be nice not to see)
<niemeyer> rogpeppe: Probably lying in the queue
<niemeyer> rogpeppe: I'll have a look later
<rogpeppe> niemeyer: ok, cool.
<rogpeppe> niemeyer: i was initially slightly worried by my 5 data races :-)
<niemeyer> rogpeppe: Yeah, quite misleading
<rogpeppe> fwereade: fairly trivial. https://codereview.appspot.com/7324046
<rogpeppe> fwereade: and i'd like to know where your tests fail with this applied.
<jam> allenap: btw, I'm changing the signature of one of the testing/charm.go apis, which effects "store/branch_test.go" and "store/store_test.go".
<jam> rogpeppe: so I see the tests hanging as well, and it is nice to not have them hang, but doesn't that mean the test is actually still failing?
<rogpeppe> jam: yeah - it shouldn't happen, but tests pass for me.
<rogpeppe> jam: until i can reproduce the problem, i'm not going to be able to fix the bug
<jam> rogpeppe: http://paste.ubuntu.com/1643683/
<jam> rogpeppe: are you running go 1.1 or some variant thereof?
<jam> I was running go1 (default on precise) but it turns out lbox doesn't work with it.
<rogpeppe> jam: yes - although i think i've run the tests on 1.0.2
<jam> So I'm now running go-1.0.3 from ~gopher's ppa
<rogpeppe> jam: ah!
<rogpeppe> jam: this probably is highly indicative: cannot unmarshal null into Go value of type rpc_test.stringVal
<jam> rogpeppe: yeah, it says the same for the struct{} object.
<rogpeppe> jam: i guess i only ran the live tests against 1.0.2.
<rogpeppe> jam: because i see the same failure.
<rogpeppe> jam: thanks.
<jam> rogpeppe: yeah, prob just a json change between go std lib and how they handle nil
<rogpeppe> jam: yes, i think so
<fwereade> rogpeppe, http://paste.ubuntu.com/1643711/
<fwereade> rogpeppe, ha, just like jm's
<fwereade> rogpeppe, sorry
<rogpeppe> fwereade: yeah, i'm on it. it's a go1.1 compatibility issue
<rogpeppe> fwereade: np
<allenap> jam: Okay, once you've done that, I'll merge the relevant changes into juju-store. Or, do you want to land my branch before making your changes, and I'll fix-up juju-store?
<jam> allenap: it doesn't change your branch, it is just going to break juju-store
<jam> your branch and mine have both landed.
<jam> so you'll just want to touch juju-store
<jam> which is generally just removing a parameter.
<allenap> jam: Okay, I'll look into that. Thanks for sorting this out!
<jam> allenap: lp:~jameinel/juju-core/no-symlinks is the branch, you can look at -r -2
<jam> but it is basically just remove: "series" being passed.
<TheMue> fwereade, rogpeppe: time for a first review? https://codereview.appspot.com/7323059
<rogpeppe> TheMue: will look after lunch
 * rogpeppe goes for lunch
<TheMue> rogpeppe: Great, thx.
<TheMue> rogpeppe: Enjoy.
<dimitern> fwereade_: is it usual for the worker/uniter tests to take long?
<fwereade_> dimitern, yes, afraid so
<fwereade_> dimitern, I wasn't avle to find any particular hotspots
<dimitern> fwereade_: ok :)
<fwereade_> TheMue, please remind me: how's public storage useful to the local provider?
<fwereade_> TheMue, won't it implicitly upload tools anyway, rendering the whole thing redundant?
<fwereade_> s/upload/"upload"/
<dimitern> fwereade_: *** Test killed: ran too long. ??
<fwereade_> dimitern, ok, no, they shouldn't take that long
<dimitern> fwereade_: am I doing something wrong?
<dimitern> fwereade_: I just run go test ./... in worker/uniter
<dimitern> fwereade_: does it need internet access during the tests?
<fwereade_> dimitern, no, shouldn't do, and that sounds sane (even if I always run from root -- go test ./worker/uniter/... -- but I doubt that's remotely relevant)
<dimitern> fwereade_: hmm, well I'll try running them in order going into each subdir to see which one is to blame
<fwereade_> dimitern, I'm just running them myself, because I forget exactly how long they should take -- enough to be annoying, certainly, but nowhere near test timeout limit
<dimitern> fwereade_: ah, actually it shows - FAIL	launchpad.net/juju-core/worker/uniter/charm	600.002s
<dimitern> fwereade_: all others are ok
<fwereade_> dimitern, hmm, very interesting: try that one with -test.v -gocheck.vv
<dimitern> fwereade_:  [LOG] 58.01524 JUJU mongod: error command line: unknown option sslOnNormalPorts
<dimitern> [LOG] 58.01531 JUJU mongod: use --help for help
<dimitern> that's almost immediately at the beginning
<fwereade_> dimitern, what mongo build are you using?
<dimitern> fwereade_: and it just stays there
<dimitern> fwereade_: mongod -v?
<fwereade_> dimitern, did you get the special version with ssl support?
<dimitern> fwereade_: git version: d1b43b61a5308c4ad0679d34b262c5af9d664267
<fwereade_> dimitern, it's in an ec2 bucket somewhere iirc
<dimitern> fwereade_: not sure, I might have installed it from the archive
<fwereade_> dimitern,     http://juju-dist.s3.amazonaws.com/tools/mongo-2.2.0-precise-amd64.tgz
<dimitern> fwereade_: it says 2.2.2
<fwereade_> dimitern, you need this build for SSL support, which is not optional
<dimitern> fwereade_: how about quantal?
<fwereade_> I suspect there's one if you s/precise/quantal/
<dimitern> fwereade_: same version?
<fwereade_> dimitern, yeah, think so
<fwereade_> dimitern, take a look at the bucket in a browser, I think it lists everything for you anyway
<dimitern> fwereade_: and I should purge the currently installed mongo as well?
<fwereade_> dimitern, up to you, but make sure the tests find the ssl version
<dimitern> fwereade_: the bucket reports access denied on dir listing, but direct link works
<fwereade_> dimitern, ah ok, maybe that changed
<dimitern> fwereade_: where should I put the extracted tarball?
<dimitern> fwereade_: anywhere in $PATH should work?
<fwereade_> dimitern, yeah, should be fine
<dimitern> fwereade_: great, 10x - now the tests pass ok and fast
<TheMue> fwereade_: Sorry, phone
<fwereade_> TheMue, np
<TheMue> fwereade_: Maybe oriented too much at the dummy environ. If I've seen right it also uses two different storage that are returned by Environ.
<fwereade_> TheMue, in the doc we agreed to just return an empty storage
<fwereade_> TheMue, and I'm confused by the way they appear to share a port..?
<fwereade_> TheMue, if we can just do a dumb empty-on-list, err-on-get StorageReader I think that lets us drop all this confusing private/public stuff
<TheMue> fwereade_: The URL depends on the environ name and if it is started as private or public. And it is empty.
<fwereade_> TheMue, it kinda looks like an awful lot of additional complexity to save two one-line methods on a new type
<TheMue> fwereade_: Please note it in the review.
<fwereade_> TheMue, will do, just checking in case I was missing something obvious
<TheMue> fwereade_: To me the symetric usage of the storage has been more simple.
<rogpeppe> fwereade_: meeting?
<fwereade_> rogpeppe, a thought: is the set of available arches not the intersection of those available on the provider with those we can find tools for?
<rogpeppe> fwereade_: that seems a reasonable thought
<fwereade_> rogpeppe, in which case I don't really think it's ok to require that someone recompile the client to use another cloud...
<fwereade_> rogpeppe, additional exercise: how are we meant to discover those values from the CLI? I don;t think we can safely assume the existence of an environments.yaml
<fwereade_> rogpeppe, sure, we won;t figure out how to drop it *soon*
<fwereade_> rogpeppe, but still...
<rogpeppe> fwereade_: GUI clients won't have environments.yaml
<fwereade_> rogpeppe, indeed
<rogpeppe> fwereade_: i didn't mean to suggest we should recompile the client to use another cloud
<rogpeppe> fwereade_: one mo, i need to interact in #juju-gui
<fwereade_> rogpeppe, I admit, I put those words into your mouth, but I think it's a consequence of specifying the list of "available" architectures on the client
<fwereade_> rogpeppe, np
<TheMue> fwereade_: Just proposed a change with no more separation between public and private but with using environs.EmptyStorage.
<fwereade_> TheMue, awesome
<fwereade_> TheMue, whoops, I never actually hit m
<fwereade_> TheMue, I'll drop the redundant comments
<fwereade_> TheMue, sent a couple, let me know what you think
<TheMue> fwereade_: yep, cheers
<TheMue> fwereade_: Yep, both makes sense, storage-port (maybe more settings for the storage backend will follow) and the comments. As you see I so far mostly panic, it's just an interface copy for quick compilation. ;)
<fwereade_> TheMue, cool, thanks
<fwereade_> rogpeppe, is trunk still expected to be broken?
<rogpeppe> fwereade_: yes. here's a branch to fix it: https://codereview.appspot.com/7324048
<rogpeppe> fwereade_: sorry about the delay.
<rogpeppe> fwereade_: it took a little more than i expected.
<fwereade_> rogpeppe, no worries, just syncing up
<rogpeppe> fwereade_: review appreciated
<rogpeppe> dimitern, jam, anyone else: ^
<dimitern> rogpeppe: i'll take a look
<rogpeppe> dimitern: ta!
<fwereade_> rogpeppe, looking good so far; you might be interested in https://codereview.appspot.com/7324049
<fwereade_> rogpeppe, LGTM
<rogpeppe> fwereade_: thanks
<fwereade_> aaaand I'm done for now -- but I might pop back on later
<fwereade_> gn all
<dimitern> rogpeppe: reviewed
<rogpeppe> dimitern: thanks! submitted.
<rogpeppe> fwereade_: gn
<rogpeppe> right, that's me for the day. first watcher test now failing in a useful way.
<rogpeppe> g'night all
<thumper> morning
<thumper> mramm: morning, you around now
<thumper> ?
<mramm> thumper: yep
<mramm> I was just about to send an e-mail because I will be out most of the day tomorrow
<fwereade_> thumper, heyhey -- I have a grumpy daughter who might take a while to get to sleep, but hope to be able to swing by again later
<thumper> fwereade_: ok, np
<benji> "go install launchpad.net/juju-core/cloudinit: open /usr/lib/go/pkg/linux_386/launchpad.net/juju-core/cloudinit.a: no such file or directory"
<benji> that happens when I run "go get -v launchpad.net/juju-core/..."
<thumper> hi benji
<benji> hi!
<thumper> benji: I can't help, but just saying hi
<benji> heh
<benji> actually, that looks like a permission problem, I guess it should be "sudo go get [...]"
<thumper> benji: well, should only need sudo if you don't have a go path set, no?
<rogpeppe> benji, thumper: definitely no need to use sudo
<thumper> hi rogpeppe
<thumper> rogpeppe: why are you still up?
<rogpeppe> benji: looks like you might not have GOPATH set
<thumper> or online at least
<rogpeppe> thumper: i'm not :-)
<rogpeppe> thumper: honest
<thumper> so this is your irc bot then?
<rogpeppe> yup
<rogpeppe> rog made me very clever
<thumper> are you up for a chat at some stage?
<benji> hmm, GOPATH is set
<rogpeppe> benji: and exported?
<rogpeppe> thumper: definitely
<benji> yep
<thumper> rogpeppe: when would be good?
<thumper> bit of an issue with you being on the other side of the planet
<rogpeppe> thumper: when's good for you?
<thumper> rogpeppe: ideally between 9 and 5 local :)
<thumper> heh
<rogpeppe> thumper: what's your time zone?
<thumper> UTC+13
<rogpeppe> thumper: what time is it now for you/
<rogpeppe> ?
<thumper> 10am
<benji> well, either way "go get -v launchpad.net/juju-core/..." (no sudo) now works, I haven't touched GOPATH since it failed <shrug>
<rogpeppe> thumper: 10am thursday?
<thumper> yes
<rogpeppe> thumper: busy for probably an hour, but should be able to make half an hour or so after that, if you're around all today
<rogpeppe> thumper: i'll ping you
<thumper> ok
<fwereade> thumper, ping
<thumper> fwereade: hi
<fwereade> thumper, heyhey, I'm free for a chat if you like -- g+?
<thumper> fwereade: g+ sounds good
<rogpeppe> thumper: ping
<thumper> rogpeppe: hey, just talking with fwereade now
<rogpeppe> thumper: i could join if you fancy it
<rogpeppe> thumper: depends what you're chatting about really
<thumper> rogpeppe: propable one on one intially would be better
<rogpeppe> thumper: sounds good
<rogpeppe> thumper: unfortunately my window of opportunity is short tonight, so maybe we won't make it
<thumper> rogpeppe: ok, perhaps tomorrow?
<rogpeppe> thumper: possibly, though unlikely.
<rogpeppe> thumper: evenings not usually good for me.
<thumper> rogpeppe: I could get up early
<thumper> 17:00 UTC
<rogpeppe> thumper: that sounds possible, yeah
<rogpeppe> thumper: i'll schedule it in...
<thumper> ok
<rogpeppe> thumper: you have an invite :-) (means i might get a reminder...)
<thumper> :)
<rogpeppe> thumper: if you get off chatting with william tonight, ping us anyway. i might still be around.
#juju-dev 2013-02-14
<jam> jtv1: poke about https://code.launchpad.net/~jtv/juju-core/no-go-env/+merge/142280 need help landing it?
<jam> wallyworld_: I saw you landed your patches (which is great), but noticed you had some troubles with the first one. Is there a process issue or just a misunderstanding?
<wallyworld_> not sure - tarmac said there was a conflict but i could reproduce locally
<wallyworld_> couldn't
<jam> couldn't ?
<wallyworld_> i recreated the branch and repushed and it was ok after that
<jam> wallyworld_: so if I try to merge your first commit, I get a conflict in client/client.go. After your "merge trunk" commit things work successfully.
<jam> I wonder if the bot/launchpad somehow didn't get your latest update.
<jam> Maybe you forgot to push after doing the merge?
<jam> but that doesn't match what is on the MP
<wallyworld_> could be, that would seem the mostly likely cause. perhaps i am used to lbox submit doing the final push
<jam> it doesn't show any new commits after you marked it approved
<wallyworld_> i can't remember exactly what i did
<jam> but then the MP seems to not show any new commits, I'm guessing the recreating the branch broke the MP
<jam> as there is no diff, etc.
<wallyworld_> a bit of ifddling and it came good
<wallyworld_> i don't think there's anything wrong with tarmac, it must have been my issue
<wallyworld_> i always got to lbox submit and realise after i get an error that goose doesn't work that way anymore
<wallyworld_> and then i forget to copy the descriptin to the commit message
<wallyworld_> i'll get the muscle memeory right one of these days
<wallyworld_> gotta go pick up my som, back in a bit
<jam> wallyworld_: so goose was trying to merge your first commit (ian.booth@canonical.com-20130211050134-up8560e45212lnc6) according to tarmac logs
<jam> wallyworld_: see you later.
<wallyworld_> sorry that i have to go 1/2 way through, i'm late :-(
<jam> np
<jam> davecheney: I'm looking to land a patch which removes 'jujuc' and moves the functionality into 'jujud' https://code.launchpad.net/~jameinel/juju-core/only-jujud/+merge/148181
<jam> I want to make sure it doesn't break upload tools, et al.
<jam> I think I've covered the bits (and the test suite passes), but you seem to be the one with the most tool-uploading experience.
<jam> Is there anything you want me to test manually before I submit the change?
<wallyworld_> jam: back
<wallyworld_> i think maybe i just didn't have the latest local rev pushed, that would explain the behaviour i think
<jam> wallyworld_: yeah, tarmac was definitely trying to merge an older revision
<jam> so either it wasn't pushed to LP, or tarmac wasn't seeing it for some reason.
<wallyworld_> i'd guess the former
<wallyworld_> but in my mind i had pushed it
<wallyworld_> PBKAC
<rogpeppe> fwereade: morning!
<rogpeppe> TheMue: hiya
<fwereade> rogpeppe, TheMue, heyhey
<fwereade> rogpeppe, TheMue: there is a start up at https://codereview.appspot.com/7324049/
<fwereade> rogpeppe, TheMue: I'm more concerned about implementation sanity than with exactly what I'm implementing
<fwereade> rogpeppe, TheMue: because... well, you know why. I can change them easily, but if I wait for perfect agreement on everything I'll wait forever
<rogpeppe> fwereade: looking
<TheMue> rogpeppe, fwereade: Good morning.
<TheMue> fwereade: *click*
<TheMue> fwereade: You've got a review.
<fwereade> TheMue, tyvm
<rogpeppe> fwereade: reviewed
<fwereade> rogpeppe, cheers
<fwereade> TheMue, the answer to your question is "yes"
<fwereade> rogpeppe, is there some way to express `Constraints{CpuCores:&123}`?
<rogpeppe> fwereade: only with an extra line
<fwereade> rogpeppe, so, not in a top-level var for the tests?
<rogpeppe> fwereade: i was just looking at tim's "gap" document. where do we stand on centralised logging support (something i believe pyjuju has)?
<rogpeppe> fwereade: huh?
<fwereade> rogpeppe, I guess I could do a little `pInt(int) *int` func or something
<rogpeppe> fwereade: Constraints{CpuCores: &t.cpuCores} ?
<fwereade> rogpeppe, how do I express nil in the tests then?
<rogpeppe> fwereade: ah!
<rogpeppe> fwereade: yeah, i think intp(123) would be better than using interface{}
<fwereade> rogpeppe, ok, cool
<TheMue> fwereade: Thx. ;)
<rogpeppe> fwereade: although...
<fwereade> rogpeppe, re logging I think there's a bug open
<fwereade> rogpeppe, and, yeah, we need it
<TheMue> Btw, anyone able to change the topic to the actual state/milestone goals?
<rogpeppe> fwereade: if you moved the parsing code into state, it might work to specify a string instead.
<fwereade> rogpeppe, that code does feel very cli-specific though
<rogpeppe> fwereade: i'm not sure. i suspect we might use it as a universal serialisation format for constraints
<fwereade> rogpeppe, hmm, I was expecting just to store documents in state
<rogpeppe> fwereade: i'm thinking of the API
<rogpeppe> fwereade: (also some other tools might want to parse constraint strings too)
<rogpeppe> fwereade: i think people using the GUI should be able to type constraint strings in the same format that we've got on the command line.
<rogpeppe> fwereade: and i'd prefer it if the GUI people didn't have to duplicate our parsing code
<fwereade> rogpeppe, hm, I'd expect the constraints gui to be a little more graphical/restrictive than that
<rogpeppe> fwereade: hmm, maybe
<rogpeppe> fwereade: anyway, i still think that code would fit very nicely alongside the String code.
<fwereade> rogpeppe, and it's not very consistent with setting env/service config
<rogpeppe> fwereade: because those are yaml?
<fwereade> rogpeppe, not in the API they're not
<fwereade> rogpeppe, also SetgentTools etc
<rogpeppe> fwereade: oh really? we have to translate env and config settings to and from js?
<fwereade> rogpeppe, the whole API is written with the assumption that we want to use objects rather than identifiers everywhere
<rogpeppe> fwereade: the tools parsing is next to the tools stringer
<fwereade> rogpeppe, I never really liked it
<rogpeppe> fwereade: i'm not sure how that's relevant here
<fwereade> rogpeppe, don't we have to translate *everything* to and from js for the gui?
<rogpeppe> fwereade: i guess so. it might make some things awkward though. people can express things in the config yaml that can't make it through a json round trip.
<fwereade> rogpeppe, remind me, what's allowed that we'll lose?
<rogpeppe> fwereade: (at least, i *think* they might be able to)
<fwereade> rogpeppe, my fervent hope is that the schemas are tight enough that they can't
<fwereade> rogpeppe, but a hope is ll it is :/
 * rogpeppe goes to look at the config settings code
<fwereade> jam, wallyworld_: do I need another goose update? openstack's localLiveSuite.TestPorts is failing
<fwereade> jam, wallyworld_: nope, still failing: http://paste.ubuntu.com/1648509/
<rogpeppe> fwereade: hmm, we parse all config options into string, and silently throw away anything that doesn't fit.
<rogpeppe> fwereade: that will probably work ok with json.
 * fwereade raises a single eyebrow with titanic self-control
<fwereade> rogpeppe, that is surprising to me... both environment and service config?
<rogpeppe> fwereade: just looking at service config there
<rogpeppe> fwereade: i'll have a look at env parsing again
 * fwereade wonders why we have types then
<rogpeppe> fwereade: env parsing is up to the provider. as long as providers stick to json-compatible values we'll be ok
<jam> fwereade: I get "TestPorts(Work in Progress)" meaning it is skipped
<jam> fwereade: using rev 891 of juju-core
<jam> in environs/openstack/live_tests.go it has 2 functions, both of which comment out the Port tests.
<jam> fwereade: now, IIRC mgz accidentally landed a possibly port-related patch yesterday, but found he made a mistake when doing so, so rolled back the commit about 5 min later. It doesn't make a lot of sense that you would have seen it inside that window, but it is possible.
<jam> fwereade: can you do "bzr log" in your juju-core branch and check?
<jam> It should end with an Ian Booth commit
<jam> fwereade: ok, sorry about that, it looks like 890 was mgz's patch that exposes the global ports tests (and expects them to pass), but then 891 landed by wallyworld_ removes that change
<fwereade> jam, yeah, but there's only one mgz commit before that
<fwereade> jam, and I see no skipped ports test in 891
<jam> fwereade: yeah, something weird here, let me see if I have something wrong
<fwereade> jam, thanks
<rogpeppe> fwereade: *after* we've parsed service config options into string, we validate them with charm.Config.Validate.
<rogpeppe> fwereade: but tbh i think it's a bit crackful that that validation is done by the command line command, not in the state.
<jam> fwereade: I had 'bzr revert -r -2' a while back to check if something was a regression. So it looks like 890 does, indeed, enable those tests. I'll run them again to see if they pass here.
<fwereade> rogpeppe, yeah, there's a hack in config-get saying essentially "remove this when Service.Config is no longer crack"
<jam> fwereade: it fails here.
<jam> Blame mgz :) I'll see what I can sort out
<jam> It looks like an accumulator is getting the same entry 2 times and not stripping the double
<fwereade> jam, cheers :)
<rogpeppe> fwereade: this one?
<rogpeppe> 		// TODO Remove this once state is fixed to report default values.
<fwereade> rogpeppe, yeah
<rogpeppe> fwereade: i think that state *does* report default values
<rogpeppe> fwereade: but only because we make sure to put them in in the first place
<jam> fwereade: as I'm checking this for you, can you test if environs/ec2: go test -live works for you?
<fwereade> rogpeppe, we should definitely NOT do that
<jam> It times out for me after 10 minutes, and 2 modules that take > 5min
<rogpeppe> fwereade: ah, because they might change on upgrade?
<fwereade> rogpeppe, yeah
<rogpeppe> jam: go test -live needs to be run with a longer timeout
<rogpeppe> jam: it usually takes about 15 minutes for me
<jam> rogpeppe: how does one do that?
<jam> (and can -live do it automagically?)
<fwereade> rogpeppe, did you fix the bootstrap tests crazy teardown bit?
<rogpeppe> jam: this is the script i call "livetest":
<rogpeppe> go test -amazon -test.timeout 2h -gocheck.vv $* >[2=1] | timestamp
<rogpeppe> fwereade: not yet
<jam> rogpeppe: is timestamp your own tool?
<rogpeppe> jam: yeah, sorry, ignore that bit
<rogpeppe> jam: (though i do find it dead useful)
<jam> rogpeppe: there is a 'timestamp' provided by the "Internetwork Routing Protocol Attack Suite", but that didn't seem fitting
<jam> I imagine it logs what time each line came in
<rogpeppe> jam: yeah
<jam> which I've seen elsewhere, but not packaged.
<fwereade> rogpeppe, trivial: https://codereview.appspot.com/7312099
<rogpeppe> jam: go get code.google.com/p/rog-go/cmd/timestamp
<rogpeppe> :-)
<rogpeppe> fwereade: looking
<jam> fwereade: it looks like it is a local-ism. Probably Martin was testing against the -live server and it was working, and didn't run the tests again with only the local server.
<jam> The local double lets you expose the same port twice
<jam> but then reports that the port is *open* twice.
<jam> so we'll need to patch goose for that it looks like.
<jam> fwereade: I'll put up a patch quickly.
<fwereade> jam, lovely, thanks
<jam> (I haven't fully confirmed that, but it seems likely)
<fwereade> jam, I'd expect -live to run them locally as well for verification's sake
<jam> fwereade: it does
<jam> I just tried it
<jam> and it fails
 * fwereade grumbles
<jam> so I'm not sure how this got through
<jam> mgz should be up soon to ask
<rogpeppe> fwereade: hmm, does this look right to you? i can't remember what unit names we intended to disallow: ^[a-z][a-z0-9]*(-[a-z0-9]*[a-z][a-z0-9]*)*/[0-9]+$
<fwereade> rogpeppe, I think that's right, yeah
<fwereade> rogpeppe, service names ending with `-%d` are not allowed
<rogpeppe> fwereade: ah yes, i see now. foggy memories of that regexp resurface :0)
<rogpeppe> fwereade: reviewed
<fwereade> rogpeppe, I don't think it complains about a string with a / in, it just strips off the "unit-", doesn't it?
<rogpeppe> jam: ha. would help if i actually pushed it
<fwereade> rogpeppe, subsequent complaints about unknown units are, I think, sane
<fwereade> rogpeppe, but maybe "invalid unit specifier" should just be "invalid entity name" as above
<rogpeppe> fwereade: if you pass in "unit-foo-bar", you'll see `"foo/bar" is not a valid unit name` but if you pass in "unit-foo", you'll see `invalid unit specifier "foo"`
<rogpeppe> fwereade: they're both invalid unit names
<fwereade> rogpeppe, ahh, yeah
<rogpeppe> fwereade: so i think they should probably draw the same error
<fwereade> rogpeppe, reproposed
<fwereade> rogpeppe, I think it's useful to be clear about the unit name being the problem rather than the entity name
<fwereade> rogpeppe, maybe that's pointless though
<rogpeppe> fwereade: hmm
<rogpeppe> fwereade: i think it might be pointless actually
<rogpeppe> fwereade: i suspect all "invalid name" errors from that function should look the same
<rogpeppe> fwereade: and should all mention the actual entity name that was typed in
<rogpeppe> fwereade: sorry for pushing back on this pissy trivial issue :)
<fwereade> rogpeppe, np, I'd prefer to get it right :)
<rogpeppe> fwereade: but i suppose it is something that users will actually see
<fwereade> rogpeppe, when whatever they're using to log in doesn't handle  the user name right? or more cases?
<rogpeppe> fwereade: hmm. maybe not actually. the user will never type an entity na,e.
<fwereade> rogpeppe, I am now wondering whether we should be checking validity of machine and user ids as well though
<fwereade> rogpeppe, what are the username restrictions (if any?)
<rogpeppe> fwereade: i think that's ok because we don't mangle the id going into those functions
<fwereade> rogpeppe, I think machine-henry is still an invalid entity name
<rogpeppe> fwereade: it is. interestingly State.Machine doesn't check for a valid machine id either.
<fwereade> rogpeppe, ha, that'd be my fault
<rogpeppe> fwereade: how about having a regexp for valid entity names?
 * fwereade has to fix id types but thinks it's less important than constraints :(
<fwereade> rogpeppe, -1, I think, it's not going to be pretty
<rogpeppe> fwereade: it won't. although it could be built up of existing components
<fwereade> rogpeppe, the service/unit ones are bad enough as it is :)
<rogpeppe> fwereade: i'd reuse those
<rogpeppe> fwereade: `^(unit-`+unitNameValid+`)|(machine-[0-9]+)| etc`
<rogpeppe> fwereade: but given the user never types an entity name, i think we're going overboard
<fwereade> rogpeppe, yeah, I'm about to propose with trivial machine id checking as well, and hope we'll never need to touch it gain :)
<rogpeppe> fwereade: let's just leave it where you started, except perhaps pass the invalid name into State.Unit even if it has no slash in it
<rogpeppe> fwereade: that way you'll always get a consistent error.
<fwereade> rogpeppe, I think invalid is different to not found, and I've already written it :)
<rogpeppe> fwereade: State.Unit returns an error on invalid names already
<fwereade> rogpeppe, I still think there's something to be said for consistency at the level of this func alone
<fwereade> rogpeppe, and I don't think it's a heavy cost to pay :)
<fwereade> rogpeppe, reproposed
<rogpeppe> fwereade: LGTM
<fwereade> rogpeppe, cheers
<fwereade> rogpeppe, http://paste.ubuntu.com/1648829/ (doesn't seem consistent, might have seen it once when other stuff was broken but not last time I ran these tests)
<rogpeppe> fwereade: are you using trunk?
<fwereade> rogpeppe, that was a paranoid re-run of all tests against the fix-auth-entity
<rogpeppe> fwereade: i don't see a similar assert at line 557 and tests pass for me
<fwereade> rogpeppe, branched from trunk very recently
<fwereade> rogpeppe, weird
<fwereade> rogpeppe, wish I hadn't deleted the branch after verifying I couldn't repro
<rogpeppe> fwereade: the ErrShutdown assert is on line 616 in trunk
<fwereade> rogpeppe, assume I'm on crack then, I'll complain if it happens again
<rogpeppe> fwereade: except it *is* testing for ErrShutdown. it may well be a race. i'll have a closer look at the logic.
<rogpeppe> fwereade: (if it is a race, it's a benign one - it doesn't really matter which of those errors is returned in practice)
<fwereade> rogpeppe, agreed, I just don't like test failures :)
<rogpeppe> fwereade: me neither. i end up asserting one of two possible errors.
<rogpeppe> s/end/might end/
<fwereade> rogpeppe, fine by me if it's not simple to make it consistent
<jtv1> jam: I'm off today but yes, some help landing it would be very much appreciated!
<jam> rogpeppe: how do you tell if a map is empty?
<jam> can you use len(mymap) ?
<rogpeppe> jam: yup
<rogpeppe> jam: (works on nil maps too)
<jam> rogpeppe: is there an easy way to check if maps are equal? Or do you have to iterate both and look them up in the other one?
<rogpeppe> jam: in a test, i'd use DeepEqual
<rogpeppe> jam: otherwise, yes
<jam> rogpeppe: in tests that is fine, but in real code?
<rogpeppe> jam: it depends really. DeepEqual is slow and often not what you want (depends on the type of the map values)
<jam> rogpeppe: I know of DeepEquals from gocheck, where do you get DeepEqual from? (stdlib?, somewhere else?)
<rogpeppe> jam: reflect
<rogpeppe> jam: reflect.DeepEqual(x, y)
<jam> rogpeppe: thx, this is a map[string]string
<rogpeppe> jam: the other thing about DeepEqual is it's not type safe
<jam> I just want to see if they are passing something I already have
<rogpeppe> jam: i'd just write the comparison code.
<rogpeppe> jam: it's only 6 lines or so
<mariusko> Hi, does it exist some system for notification/autentication between charms?
<mariusko> Other than (mis)-use relations
<rogpeppe> mariusko: that's what relations are for
<mariusko> I would like to trigger redeploy from a git server charm to e.g. node-app on git push received
<mariusko> I thought of either setting the branch name again on node-app in that case to trigger it, or add a parameter to store the SHA1 to deploy
<mariusko> But how would the app-charm get access to the git repo? Is there a magic authentication through ssh or something?
<mariusko> Or access it through NFS?
<fwereade> TheMue, ping
<fwereade> mariusko, do you have a config setting for your git repo? feels like a job for an external tool: set the service config, and let the charm's config-changed hook handle it
<TheMue> fwereade: pong
<fwereade> TheMue, it crosses my mind that we probably don't want the storage backend implementation hidden away inside environs/local
<fwereade> TheMue, how are you planning to deploy it?
<TheMue> fwereade: If there's good multiple usage I can surely move it.
<fwereade> TheMue, I'm probably missing something, but I don't see when it'll be used inside environs
<TheMue> fwereade: The backend only indirectly. I only put it there as we so far had no other need for it.
<fwereade> TheMue, what's the planfor actually running it?
<TheMue> fwereade: It can be a standalone binary of maybe also a configurable part of the machine agent. But here I'm not yet secure enough, I haven't yet looked.
<TheMue> fwereade: The component is flexible enough.
<fwereade> TheMue, yeah, I'm wondering whether a worker might be the way forward
<fwereade> TheMue, not something that needs to be done right away though, I guess
<TheMue> fwereade: I will keep it in mind, but yes, that would be a good "environment" for the backend to live in.
<fwereade> TheMue, although I imagine you're aiming for a bootstrap ASAP?
<TheMue> fwereade: Exactly.
<fwereade> TheMue, cool, I imagine it will fall out naturally soon enough then
<TheMue> fwereade: Think so too.
<fwereade> TheMue, can I ask you to take a little look at davecheney's stater work, and let me know whether any of that will potentially fit in well with what you need in the local provider?
<TheMue> fwereade: Do you know how to change topic w/o op?
<fwereade> TheMue, I'm afraid I don't
<fwereade> TheMue, maybe ask niemeyer when he comes on?
 * niemeyer is around
<TheMue> fwereade: Good idea, and yes, I will take a look at the stater.
<niemeyer> morning folks
<TheMue> niemeyer: Good morning.
<TheMue> niemeyer: Nice video about maps btw.
<niemeyer> Hmm.. actually, how do I allow the topic to be changed by everyone again?
 * niemeyer looks at the help
<niemeyer> TheMue: Cheers!
<fwereade> niemeyer, heyhey, sorry I missed you :)
<fwereade> TheMue, it's stalled in review at the moment because dave is looking at other things, but I don;t think we can afford to exclude it from consideration -- if you can come up with a plan that fits both local and HA use cases I will send you virtual flowers
 * fwereade needs to take an extended lunch today, off in a few mins, and will see everyone in a couple of hours
<TheMue> fwereade: Oh, Valentine's. *rofl*
* ChanServ changed the topic of #juju-dev to: I am a new topic.
<niemeyer> TheMue: /msg chanserv topic #juju-dev <whatever>
<TheMue> niemeyer: Great, thank you.
* ChanServ changed the topic of #juju-dev to: finish ALL THE THINGS
<fwereade> if someone can come up with a better topic, go for it :)
 * fwereade => off
<wallyworld_> jam: mgz: dimitern: can we delay the meeting for 30 minutes or so? i've had a call from my wife and i unexpectedly have to go and pick her up from a work meeting
<dimitern> wallyworld_: works for me,
<jam> wallyworld_: if anyone else was here it would be delayed :), but yeah, wfm
<wallyworld_> ok, thanks :-) will leave now and hopefully be back in 1/2 hour or so
<TheMue> lunchtime
<mariusko> fwereade: I think I will have to try to hack a bit to see when I get time. Maybe add a connection between gitolite and node-app charm where either you specify a ssh key to fetch the updated code or that node-app adds a ssh key to the server
<jam> dimitern: the rest of us are all here
<wallyworld_> dimitern: i'm back
<dimitern> jam: just a sec
 * rogpeppe goes for lunch
<rogpeppe> back, but i'll probably step out for a breath of fresh air later
<dimitern> fwereade, others?: https://codereview.appspot.com/7303091 - refactoring of hook module
<rogpeppe> just rebooting, back in a mo
<fwereade> dimitern, ping
<dimitern> fwereade: pong
<dimitern> fwereade: that's the CL we were talking about yesterday
<fwereade> dimitern, I think hook.Info shouldn't be in charm/hook -- that bit is very specific to the uniter
<dimitern> fwereade: ah, ok, I can move that bit back into worker/uniter/hook ?
<bac> hi i just set up my environment and have r892 of juju-core.  i'm seeing test failures for state/api.  trying to figure out if it is my environment or if that test is really broken in trunk.
<fwereade> dimitern, yeah -- I know it'll make both packages feel a little anaemic, but I think it's the right division
<dimitern> fwereade: sure, np
<dimitern> fwereade: how about the ScanCharm ?
<fwereade> bac, would you paste them? I know there was churn there in the last couple of days
<bac> fwereade: sure
<fwereade> dimitern, my first reaction was eww! to the Errors type, but I haven't looked closely enough to figure out whether that's a sensible response ;p
<dimitern> fwereade: it's a bit iffy at first, but I think it makes sense for what it does
<fwereade> dimitern, I think you should be ok trusting the contents of the Meta though -- it does validate on load
<bac> fwereade: http://paste.ubuntu.com/1650787/
<dimitern> fwereade: including duplicate relations scanning?
<fwereade> bac, both of those are known and don't indicate anything seriously wrong that won't be fixed today
<bac> fwereade: great, thanks for looking
 * fwereade looks meaningfully at rogpeppe and mgz, neither of whom appear to be around right now
<fwereade> dimitern, I think so, yeah
<fwereade> dimitern, lines 99-102 in meta.go
<fwereade> bac, btw, much love for the bzr revision and go version at the bottom of the paste :)
<bac> :)
<dimitern> fwereade: ok then, I'll remove this check - can you comment that?
<fwereade> dimitern, yeah, will do, just going through it now
<rogpeppe> fwereade, dimitern, jam, anyone else: a small CL that adds error codes to the rpc package: https://codereview.appspot.com/7311097
<dimitern> rogpeppe: looking
<rogpeppe> dimitern: ta!
<fwereade> dimitern, I think it's all doing a bit much, I'm afraid
<fwereade> dimitern, I totally understand the temptation to use filepath.Walk
<fwereade> dimitern, but I think it'll work out clearer if you just build up a list of possible hook names given the available relation names
<dimitern> fwereade: why using Walk is bad?
<fwereade> dimitern, because we don't care about anything except the actual hooks that juju might try to run
<dimitern> fwereade: hmm..
<fwereade> dimitern, I think that all we need is to build a list of all the global hooks, plus 4 relation hooks for every relation
<dimitern> fwereade: do you think it's better, once we have discovered all relations, just do a loop over and find whether they're there
<fwereade> dimitern, we don't even care if they're not there
<fwereade> dimitern, the only thing we should worry bout is if they're there but aren;t executable
<dimitern> fwereade: so the executable check has to happen in ScanCharm?
<fwereade> dimitern, g+? might be quicker than typing
<dimitern> fwereade: sure, I'll start a hangout
<fwereade> dimitern, cheers
<dimitern> fwereade: https://plus.google.com/hangouts/_/a19365e0ad7fd87450ce5dcdb4539de6e2fa6ca8?authuser=0&hl=en
<fwereade> rogpeppe, http://paste.ubuntu.com/1650787/ -- bac has been seeing EOFs too
<rogpeppe> fwereade: thanks. i'm looking at that right now, though i haven't been able to reproduce it
 * dimitern >> lunch
<bac> rogpeppe: thanks for looking.  i've got a fresh install and am using bigjool's mongo PPA.
<fwereade> rogpeppe, you have an LGTM on the error codes, but I'd like to see the NotFound stuff implemented for Machine soon -- I'm not 100% clear on how that'll look in practice
<fwereade> rogpeppe, also, re the int suggestion for CpuPower, would you expand a bit on what you're thinking -- something like 1000 CpuPower == 1 ECU?
<rogpeppe> fwereade: sorry, was in a hangout
<rogpeppe> fwereade: thanks. that's the next step
<fwereade> rogpeppe, np, I expected so
<rogpeppe> fwereade: yeah, for CpuPower, something like that. probably 100 could be sufficient.
<rogpeppe> fwereade: we can display it as a float if we want.
<rogpeppe> fwereade: although probably easier not to
<fwereade> rogpeppe, yeah, that's the plan -- I'd kinda like to keep a bit more accuracy in there than I expect us to need :)
<rogpeppe> fwereade: i hope you don't mind my instinctive discomfort with floats.
<rogpeppe> bac: can you reproduce the test failure consistently?
<bac> rogpeppe: yes as can teknico
<rogpeppe> bac: cool - i'll push a branch for you to test in a moment
<fwereade> rogpeppe, no, I share it really, I just thought it might be clearer as a float
<bac> rogpeppe: thanks
<fwereade> rogpeppe, the best float bug I ever heard about was in some game with decent-sized worlds made up of smaller rooms... when the rooms (which were playtested originally in the centre of the universe) were placed far enough away from (0, 0, 0), the loss of resolution meant that the geometry was represented funkily enough to allow people to clip through walls/floors/etc
<rogpeppe> fwereade: i bet they were using float32s
<fwereade> rogpeppe, probably -- and take the details with a pinch of salt
<rogpeppe> fwereade: cool bug!
<fwereade> rogpeppe, but still, floats are bad :)
<fwereade> rogpeppe, indeed
 * rogpeppe likes floats... in the right place.
<fwereade> rogpeppe, probably not so cool to debug ;)
<rogpeppe> fwereade: or probably to fix...
<fwereade> rogpeppe, as long as nobody kids themselves they're numbers they're fine
<fwereade> rogpeppe, ha, yeah
<rogpeppe> bac: lp:~rogpeppe/juju-core/216-rpc-consistent-close-error
<bac> rogpeppe: will try now
<bac> teknico: ^^
<rogpeppe> bac: thanks
<teknico> bac, rogpeppe, I'll try it too shortly
<rogpeppe> fwereade, TheMue: it finally dies...
<benji> hi all; I'm getting an error (well, lots of similar errors) when running "go get -v launchpad.net/juju-core/..." --> "import "crypto/rand": import path doesn't contain a hostname"
<bac> rogpeppe, teknico: i now see a different failure, which i have seen before:  http://paste.ubuntu.com/1651636/
<rogpeppe> bac: that's blue team's domain :-)
<bac> jam: ^^
<teknico> sorry, on a call, haven't tried yet
<rogpeppe> bac: have you tried go get -u launchpad.net/goose ?
<rogpeppe> benji: instead of that, try go get -v launchpad.net/juju-core/cmd/juju
<bac> rogpeppe: i did update goose but not goamz
<rogpeppe> bac: so have you got it working now?
<benji> rogpeppe: go install launchpad.net/juju-core/log: mkdir /usr/lib/go/pkg/linux_386/launchpad.net: permission denied
<rogpeppe> benji: what's your GOPATH?
<benji> I had a GOROOT set when I got the aformentioned error, now with no GOROOT I get the above
<bac> benji: :)
<rogpeppe> benji: you need a GOPATH
<benji> % echo $GOPATH
<benji> /home/benji/workspace/go
<teknico> rogpeppe, as for bac, the "api_test.go:524: suite.TestStop" is gone, but the "live_test.go:0: localLiveSuite.TestPorts" is still there
<teknico> is "blue team's domain" a reliable enough escape hatch? ;-P
<rogpeppe> teknico: yeah, i see the error too
<dimitern> rogpeppe: i believe mgz should have fixed that
<rogpeppe> dimitern: cool
<dimitern> rogpeppe: we're talking about disabling the ports test today
<fwereade> teknico, we were expecting mgz to show up and fix it, and that has not happened -- I think I'll just propose a trivial that skips it again
<teknico> fwereade, thanks, bac, ^^
<dimitern> why was the test failing again?
<mgz> ah, did we not report in here?
<mgz> it just wants a goose branch landed to make the test service return a sanish error in response to the juju-core tests checking duplicate rule behaviour and probably not being very well isolated
<rogpeppe> mgz, dimitern: i've also seen this failure in openstack: http://paste.ubuntu.com/1651926/
<dimitern> oh, yeah
<dimitern> it relies on some (undocumented?) ec2 error behavior
<mgz> okay, I marked the proposal as approved so it should auto land shortly
<dimitern> mgz: cool, thanks
<mgz> rogpeppe: that's an isolating issue, that's *already* worked around on goose
<mgz> *isolation
<dimitern> fwereade: a thought - how about instead of having a Meta method returning a map[string]true, instead return a slice and have a separate method IsHook() which uses a map internally to check that quickly, because that's what we care about in expand/bundle anyway..
<rogpeppe> mgz: what do you mean by an "isolation issue"?
<mgz> basically, live-esque tests don't reset state in the test service
<fwereade> dimitern, remember that a Meta needs to be stored in state -- we don't want private fields
<mgz> so, within a file, all tests share the same service, which means subsequent ones have stuff like left over security groups from the previous tests
<dimitern> fwereade: ah, didn't realize that
<mgz> okay, pull goose and rerun everyone
<fwereade> dimitern, and I don't think that a list of possible hooks is important enough to make visible
<dimitern> fwereade: it can use a private map var
<rogpeppe> mgz, dimitern: oh yes, another problem - at least one test fails when run by itself: http://paste.ubuntu.com/1651977/
<fwereade> dimitern, I think I'd prefer to just create it explicitly in the rare situations it's needed
<mgz> rogpeppe: that one is new to me :)
<dimitern> fwereade: no, i meant something else, let me paste some code
<fwereade> dimitern, ah sorry
<dimitern> rogpeppe: I think that's my doing
<dimitern> rogpeppe: i'll have a look shortly
<rogpeppe> mgz: yeah, i see the issue - kinda the point of the live tests is so that you *don't* have to bootstrap the environment every time, so that we have some possibility of running the test suite in under a day...
<rogpeppe> mgz: but that's inevitably going to lead to isolation-related issues
 * fwereade doesn't want to impose a fedex-everyone-biscuits penalty for breaking the build, but is considering a wear-stupidest-available-hat-in-hangouts policy
<mgz> I'm fine with tht :)
<rogpeppe> fwereade: excellent idea
<mgz> just having a bot is better of course
<rogpeppe> mgz: a bot would be a great thing. how's it working out for you guys?
<mgz> the tests passed locally, because goose still had my fix installed, which isn't terribly easy to detect
<fwereade> mgz, +1 in theory, but that doesn't feel like it would play cleanly with the irritating synchronized-checkins requirement
 * fwereade still kinda feels like cloning goose into thirdparty/ is the cleanest solution while it's still changing
<fwereade> firstparty/ ?
<dimitern> fwereade: hmm.. I can't decide whether having both Hooks() map[string]bool and AllHooks() []string
<dimitern> fwereade: it seems a plain slice is useful, but then again having a map for quick lookup is also nice, and can be looped over like a slice for the keys
<fwereade> dimitern, I'd stick with the first, but now you've mentioned it in public the weight of popular opinion my push us towards an []string with  O(N^2) checks
<fwereade> dimitern, what are the use cases? for the only one I know, the map gets us the most compact code, I think
<fwereade> dimitern, is one better for ExpandTo, the other for BundleTo?
<dimitern> fwereade: sure, map is what we need - with the lack of keys(), which you have to loop over anyway, so should be enough
<fwereade> dimitern, cool
<dimitern> fwereade: for expand/bundle map is perfect, since files are processed one at a time
<fwereade> dimitern, sgtm
<dimitern> rogpeppe: that error is due to not passing --upload-tools (or equiv) I think - i've seen it before
<dimitern> rogpeppe: or maybe some ill bootstrapping
<rogpeppe> dimitern: well, it passes when i run all the tests together
<dimitern> rogpeppe: that's bad
<rogpeppe> fwereade: ahem, shame on me, i submitted a branch accidentally: https://codereview.appspot.com/7324054/
<dimitern> rogpeppe: it's not idempotent
<rogpeppe> fwereade: it's fairly trivial (two line change) but still
<rogpeppe> fwereade: i thought i was submitting another branch
<rogpeppe> fwereade: (it does fix trunk too)
<fwereade> rogpeppe, retroactively LGTMed
<dimitern> rogpeppe: so accidentally submitted the right thing?
<dimitern> :)
<rogpeppe> fwereade: thanks
<rogpeppe> dimitern: too early :-)
 * fwereade doesn't trust any of you, and is going to run all the tests from scratch again ;p
<dimitern> today's break the build day :)
<dimitern> as a friend says - "if you break the build, you *become* the build"
<dimitern> fwereade: given Meta needs to be stored in state, it isn't a problem to have m *Meta methods, right?
<fwereade> dimitern, I don;t think so, but they probably shouldn't need to be, because I don't think they should modify it
<dimitern> fwereade: ofc, right
<fwereade> mgz, rogpeppe, bac, teknico: tests cleanly for me with fresh goose; thanks all for warnings and fixes as appropriate
<rogpeppe> fwereade: me too. fresh goose made things all tasty again.
<teknico> fwereade, thanks. for my education, is there a better way than "go get"ting everything all the time?
<rogpeppe> teknico: with changing external dependencies, not currently, no
<dimitern> rogpeppe: fresh goose always makes things better :)
<mgz> we've generally tried to post to the list when there needs to be a syncronous juju-core/goose update, but that only works for planned breakage, and is pretty frequent given doing pretty much anything in go involves changing an api
<mgz> no new optional param, no new ignorable field migrations
<rogpeppe> mgz: you can add struct fields and methods without breakage in general
<mgz> not if you need to actually use them somewhere :)
<mgz> in python you'd just getattr something on a class if you want to run against a dep that may or may not be a new version
<mgz> which is ugly in the long run, but nice as a workaround
<rogpeppe> mgz: yeah, i don't think we want to be doing that :-)
<mgz> so, lockstep updates are a way of life.
<rogpeppe> i still think there's no *inherent* reason that version-number-as-path needs to be painful, but i haven't worked out how the workflow should go exactly.
<mgz> 's fine once things are stable-ish, but atm they are not.
<dimitern> mgz: if you bzr rm a file, propose it, then add another file at it's place and bzr add it, when proposing it complains: error: Failed to send patch set to codereview: can't upload base of worker/uniter/hook/hook.go: ERROR: Checksum mismatch.
<dimitern> any idea is this a lp, bzr or lbox issue?
<mgz> needing to bump a version in every goose and every juju-core file multiple times a week doesn't work with more than one person doing development
<mgz> dimitern: sounds like an lbox bug
<mgz> but is it actually a different file, or did you break history for fun?
<mgz> 'd cp your current file, bzr revert the path, mv the file back, and unless the diff is complete nonsense use that
<rogpeppe> mgz: it's not inherently more work than bumping a version in one file AFAICS
<mgz> rogpeppe: I'm proposing a feature, Ian's proposing a feature, how do we both bump the version?
<mgz> it's hostile to distributed workflows
<rogpeppe> mgz: how do you do that in the python world?
<rogpeppe> mgz: is there something that auto-increments the version with each merge or something?
<mgz> mostly by having flexible apis and the tools to work against older deps, but otherwise, by having the version in exactly one place that can get bumped as a seperate proposal, and is a single conflict point
<rogpeppe> mgz: i think that bumping the version as a separate proposal could work fine even if there are multiple files involved. the conflicts will be obvious and easy to resolve.
<mgz> they're mixed up with the imports...
<mgz> and it can't be seperate, otherwise the code using whatever new api thing it is won't build
<rogpeppe> mgz: that's fine, won't it? you could even have a tool that automatically diagnoses version number conflicts, perhaps, because they'll be so predictably formed AFAICS.
<mgz> but it's not just conflicts, it's development
<rogpeppe> mgz: i *think* development could work ok too, as long as a) there's an easy way to change all imports and b) there's a single development branch that has a static path.
<mgz> if you're baking a number into the import, it makes every feature branch into an ordering complication
<dimitern> mgz: so i first removed worker/uniter/hook/*, then proposed, then added worker/uniter/hook/ - 2 different files (part of what was there before, same names), reproposed, got the error, did bzr checkout -b newbranch, lbox proposed, same error again, and if you look at https://codereview.appspot.com/7337043/ some of the files are not there (upload in progress), but others are
<mgz> if it's just +=1, you get breakage from two people landing at the same time due to it not being clear which new feature is actually being depended upon
<dimitern> I don't see what's special about removing and re-adding a file with the same path in the same branch
<mgz> dimitern: you change the fileids
 * fwereade is somewhat upset to find he is no longer capable of spelling "uint" as anything other than "unit"
<rogpeppe> fwereade: lol
<mgz> bzr cares about fileids, I suspect lbox doesn't understand them and just keys off path
<rogpeppe> mgz: presumably that's true of any monotonic version numbering scheme though
<rogpeppe> mgz: yeah, i don't think codereview.com knows about fileids
<dimitern> mgz: well, if you look at the diff in lp, is says confusing things: https://code.launchpad.net/~dimitern/juju-core/reorganize-charm-hooks/+merge/148500 (added directory, then removed the same dir, added a file inside it next)
<mgz> right, but it's not in the import generally, so isn't directly tied to code changes in *both* sides of the dep link
<mgz> dimitern: right, really you shouldn't do that
<fwereade> dimitern, when this sort of thing happens I usually just clone a fresh trunk and copy everything in from the borked one
<dimitern> mgz: what? is it because a dir was deleted and re-added ?
<mgz> what you probably want to do is branch the initial version, change the files to your changes (not using bzr rm and bzr add, but by changing the files), and push --overwriting
<dimitern> fwereade: yeah, almost did it, but decided to ask and maybe learn the error of my ways :)
<mgz> dimitern: you've said the files are unrelated by doing that
<mgz> which confuses lbox
<mgz> and anyone using the dvcs history
<dimitern> I dont's see how, provided the history is in the right order
<mgz> you removed a file, then added another file with the same name, and similar contents
<dimitern> mgz: yeah, so? how's this different from doing the same, with the same file, but on 2 subsequent proposals?
<mgz> well, it breaks lbox apparently, is how it's different
<dimitern> mgz: but bzr is ok with this, I mean
<mgz> it's okay with it, but you should have used mv
<mgz> because it looks like a break in the history, when it's really a mv
<mgz> anyway, you still can fix this, if you just start from r-2 and redo the change
<dimitern> mgz: I got you, i though bzr will pick it up rm+add, but if the contents differ a bit (even if only at the bottom)
<mgz> no, it means something else
<niemeyer> fwereade: Where is the juju store nowadays?
<mgz> you need to use `bzr mv` which does have some switches for guessing
<niemeyer> fwereade: I see it got killed on Wednesday
<mgz> but it's best to just be explicit
<fwereade> niemeyer, lp:juju-store
<niemeyer> bzr branch lp:juju-store
<niemeyer> bzr: ERROR: Not a branch: "bzr+ssh://bazaar.launchpad.net/+branch/juju-store/".
<niemeyer> fwereade: ^
<niemeyer> allenap: ping
<fwereade> niemeyer, ah, hmm, you would seem to be right -- I saw the project but didn't check the code
<niemeyer> fwereade, allenap: Has anyone has coordinated with the team that deploys the store code to update the deployment procedure?
 * fwereade has not :/
<niemeyer> fwereade: Was there any meetings that I lost about this change?
<allenap> niemeyer: Nope. I don't know who deploys the store exactly, but I can ask the webops.
<fwereade> niemeyer, the MP referenced the discussions in austin in which we all seemed to agree that the store was best off separate if it was being worked on by another team
<dimitern> mgz: cheers
<niemeyer> allenap: I'm a bit concerned that we seem to be shaking things without much coordination
<niemeyer> fwereade: Maybe.. it doesn't seem like a reason on itself, though
<fwereade> niemeyer, but you're absolutely right that nobody considered the deployment
<fwereade> niemeyer, I'm not sure -- the more teams we have hitting the same codebase, even if the work is theoretically non-overlapping, the more confusion there seems to be
<niemeyer> fwereade: I think it would be nice to have that in the same place, at least for a while
<rogpeppe> thumper: yo!
<niemeyer> fwereade: As I understand it, that new team has never worked with Go, or with juju-core
<thumper> hi rogpeppe
<thumper> rogpeppe: I was waiting on the hangout :)
<niemeyer> fwereade: Having teams closer together would probably be beneficial
<niemeyer> fwereade, allenap: We actually had a thread going in the mailing list about this..
<niemeyer> fwereade, allenap: So, where is the code now, and who will coordinate with IS to update the scripts and make sure they work?
<fwereade> niemeyer, perhaps I remember wrongly -- I thought the thread was essentially a rejection of the theory that occasional failing tests were a good reason to separate it
<allenap> niemeyer: It's in lp:juju-store, which is currently private. I'll talk to the webops.
<niemeyer> allenap: Can I please have access?
<niemeyer> allenap: Does it have to be private now?
<niemeyer> allenap: This means you'll be dropping codereview for the moment, since lbox won't keep content private
<allenap> niemeyer: ~juju was invited to the ~juju-store team a while back, but I'll add you individually for now.
<niemeyer> allenap: Let me try to approve that
<allenap> niemeyer: hazmat originally asked for it to be private, iirc, so I'm going to punt on that :)
<niemeyer> hazmat?
<dimitern> fwereade: finally, I think this is the last of it - https://codereview.appspot.com/7317045
<hazmat> allenap, niemeyer in meeting back shortly
<dimitern> rogpeppe: you too perhaps? ^^
<niemeyer> allenap: When will you start work on it?
<niemeyer> allenap: That justifies the change, and it being private?
<allenap> niemeyer: I think the Red Squad were happier to use LP for code reviews. However, we're not going to be working on the store any more... so whoever takes it on may decide they want back in to juju-core. It shares history so it ought not to be too hard to merge back in.
<niemeyer> allenap: Erm.. who's actually working on that code?
<allenap> niemeyer: I don't know, to be honest. Deryck may be able to help.
<niemeyer> allenap: https://launchpad.net/juju-store/trunk
<niemeyer> allenap: The project doesn't even have code set up
<niemeyer> allenap: So I guess no one right now
<allenap> niemeyer: https://code.launchpad.net/~juju-store/juju-store/trunk
<allenap> niemeyer: Also, https://launchpad.net/juju-store/trunk looks right to me.
<niemeyer> allenap: Thanks, I wasn't properly logged in
<allenap> niemeyer: Cool.
<fwereade> allenap, where should I have been to find out that store work was now off your plate? did I miss something obvious?
<allenap> fwereade: It should have percolated through via management I assume, but I don't know that it's written anywhere.
<allenap> Not written anywhere I know of.
<niemeyer> Okay, I'm sending an email to sync us up
<fwereade> allenap, it's perfectly possible that I missed something, but it doesn't ring any bells here :)
<hazmat> allenap, i though we belayed removing it for a copy?
 * hazmat is confused about whose on first
<hazmat> allenap, when did that change re red not on store?
<allenap> fwereade, hazmat: Okay, this is not the message I got in Austin, which was to reopen and land the break-out-juju-store branch.
<fwereade> hazmat, allenap: a copy seems like a suboptimal solution from just about every perspective... things can but diverge and cause (more) confusion
<allenap> The cavalry has arrived :)
<allenap> fwereade, hazmat: We can revert if you want: r886 is the offender.
 * allenap has to go to collect his kids about 10 minutes ago.
<fwereade> allenap, collect your kids, we'll figure it out :)
<fwereade> deryck, am I right in thinking that there's no current work happening on the charm store? or am I just confused?
<deryck> no current work, no
<deryck> I'm otp so will have to answer questions as I can, just FYI
<fwereade> deryck, hazmat: does anyone have any objections to moving it back until it gets a happy new home with loving parents? ;)
<deryck> fwereade: what are we talking about? a revno? Or something else? Maybe hazmat is better to comment here.
<fwereade> deryck, I'm talking about the store package's removal from juju-core, on the understanding (I thought) that red would be doing imminent work on it
<deryck> ah
<fwereade> deryck, if that's not happening now, I think it's probably best left in juju-core for the time being
<deryck> That makes sense to me. But I also think work will happen in the short term on the store. either red or green.
<deryck> just not happening now.
<deryck> I'd also prefer to defer to hazmat ultimately on this question.
<fwereade> deryck, ok, thanks :)
<fwereade> hazmat, it sounds as though you may have a clearer picture than any of us..?
<fwereade> hazmat, or maybe we're just accusing you of that without any basis in fact ;)
<deryck> fwereade: did allenap have objections to putting the store back in core?  sorry to join late.
<fwereade> deryck, I haven't heard any objections yet
<fwereade> deryck, np :)
<deryck> ok cool
<niemeyer> fwereade, deryck: hazmat replied on canonical-juju
<fwereade> niemeyer, ah, thanks
<fwereade> niemeyer, deryck: I need to stop for the night; I'll restore it tomorrow (or maybe later...) if nobody else gets there first
<fwereade> sorry to dash
<fwereade> dimitern, LGTM, a few trivials
<niemeyer> fwereade: Have a good one
<hazmat> fwereade, niemeyer sorry about the confusion, things have been unclear to me as well
<dimitern> fwereade: cheers!
<niemeyer> hazmat: No worries, thanks for clarifying
<dimitern> rogpeppe: ping
<rogpeppe> dimitern: pong
<rogpeppe> dimitern: sorry, i was chatting with thumper
<dimitern> rogpeppe: np, if you can take a look at https://codereview.appspot.com/7317045
<dimitern> i'd like to land it today
<rogpeppe> dimitern: will do
<rogpeppe> dimitern, fwereade: is it really worth defining a new package to deal with charm hooks? wouldn't it be ok to have that stuff in the charm package itself?
<allenap> fwereade, deryck: No objections from me for putting it back in juju-core.
<dimitern> rogpeppe: hooks work in contexts where charm is too much to ask
<rogpeppe> dimitern: what do you mean by "too much to ask"?
<dimitern> rogpeppe: :) i mean you're not interested in the whole charm, just need to work with hooks
<rogpeppe> dimitern: that's fine - you don't need to use the other charm-related stuff
<dimitern> rogpeppe: and in addition, there are a lot of places in the uniter where this has to change
<dimitern> rogpeppe: charm.RelationJoined vs hook.RelationJoined
<dimitern> rogpeppe: I agree it might be a stupid thing, but looks cleaner
<rogpeppe> dimitern: i think charm.RelationJoined reads ok
<dimitern> rogpeppe: well, it's the same to me, if fwereade agrees as well
<rogpeppe> dimitern: actually, on reflection, i don't mind too much.
<rogpeppe> dimitern: but i do think you should be aliasing charm/hook, not uniter/hook inside the uniter code
<dimitern> rogpeppe: i did that before
<rogpeppe> dimitern: orly?
<dimitern> rogpeppe: but it seemed wrong and funny :)
<dimitern> chook here, chook there
<rogpeppe> dimitern: charmhook would work too
<dimitern> i didn't know is aussie for chicken :)
<rogpeppe> dimitern: chhook maybe
<rogpeppe> dimitern: just i think that the principle of renaming the thing that's furthest away is a decent one
<dimitern> rogpeppe: charmhook was my first choice, but it's too long for long case x,y,z lines
<dimitern> rogpeppe: ok, I can changed the uniter code to use hook and chook?
<rogpeppe> dimitern: i *think* that'll be better
<rogpeppe> dimitern: although changing it all to charm. is an alternative too - no name collision there
<dimitern> rogpeppe: ok, I can now see charm.* seems a better choice
<rogpeppe> dimitern: though you may want a common prefix for the hook names (HRelationJoined, HRelationDeparted etc?)
<dimitern> rogpeppe: then a few things need changing, like IsRelation -> IsRelationHook, Install->InstallHook maybe? charm.Install seems ambiguous
<rogpeppe> dimitern: charm.HInstall
<rogpeppe> ?
<dimitern> rogpeppe: I'd like to pass this through fwereade as well, since it touches a lot of the uniter code
<rogpeppe> dimitern: definitely
<dimitern> rogpeppe: otherwise, I'm fine
<dimitern> rogpeppe: so I guess I'll leave it for tomorrow then
<rogpeppe> dimitern: sorry about that
<dimitern> rogpeppe: tyvm!
<rogpeppe> dimitern: np. naming issues, pah
<dimitern> rogpeppe: np, it'll be better
<dimitern> rogpeppe: it's a trivial change, so it up to agreement for readability/convenience really
<dimitern> i'm off then
<dimitern> good night all
<rogpeppe> i'm off too
<rogpeppe> g'night!
<rogpeppe> dammit, i just saw another "unexpected EOF" test failure and i can't see how it could possibly have happened :-(
<thumper> morning
<thumper> how do you normally upgrade the trunks in a GOPATH layout?
<thumper> if I want latest juju-core trunk
<thumper> is it normally just a pull?
<thumper> or is there a special go command?
<thumper> niemeyer, fwereade, anyone...
 * niemeyer heads up
<niemeyer> thumper: I personally just pull
<thumper> niemeyer: ok, ta
<niemeyer> thumper: go get does support a -u flag, though
<thumper> pull works for me
<niemeyer> thumper: That may not go so well with cobzr
<niemeyer> thumper: I mean, -u
<thumper> niemeyer: I'm not using cobzr :)
 * thumper is special
<niemeyer> thumper: That's fine.. whatever works :)
<thumper> niemeyer: how do you handle the situation of pulling a new version of trunk... do you then run the tests to make sure all the appropriate deps are there and the API hasn't changed?
<thumper> I'm considering the email sometime before
<thumper> about "you need to upgrade goose as well as juju-core"
<thumper> how do I know if I have other things to pull?
<niemeyer> thumper: I don't generally run tests when starting to hack
<niemeyer> thumper: But if you're not sure if it's working, that's a good idea
<thumper> go test, right?
<thumper> or go test juju-core?
 * thumper found it
<thumper> I'm getting failures running the tests on trunk with `go test launchpad.net/juju-core/...`
<thumper> anyone else?
 * thumper hates broken tests on trunk
<thumper> although it is probably broken deps
<thumper> or deps not updated
<thumper> wallyworld___: ping
<wallyworld___> thumper: g'day
<thumper> wallyworld___: hey there
<thumper> wallyworld___: long tail you have there
<wallyworld___> yeah, stupid quassel
<thumper> wallyworld___: was hoping you could help me with some test stuff
<wallyworld___> sure
<thumper> hangout?
<wallyworld___> ok
<davecheney> aww fuck,
<davecheney> # launchpad.net/juju-core/store_test
<davecheney> store/branch_test.go:28: too many arguments in call to "launchpad.net/juju-core/testing".Charms.Dir
<davecheney> store/store_test.go:114: too many arguments in call to "launchpad.net/juju-core/testing".Charms.ClonedDir
<davecheney> thumper: % bzr merge -r 886..885
<davecheney>  is that the correct incantation for a reverse merge ?
<thumper> davecheney: something like that
<davecheney> cool
<davecheney> looks like the problem is a change made afterwards to some testing stuff
<davecheney> merge proposal coming up real soon now
<davecheney> thumper: can I get a hell yeah, https://code.launchpad.net/~dave-cheney/juju-core/080-revert-store-change/+merge/148571
 * thumper looks
<davecheney> hang on, intertubes still grinding
<davecheney> done
<thumper> davecheney: what is the api change?
<davecheney> the testing.Charm helper had an argument which was always "series"
<davecheney> so revno 887 removed the parameter and bought the value indoors
<davecheney> http://bazaar.launchpad.net/~gophers/juju-core/trunk/revision/887
<thumper> davecheney: seems I'm not in gophers
<davecheney> thumper: I will try to fix
<davecheney> speaking of that
<davecheney> i've stopped getting notifications from LP
<davecheney> which is a double edged sword
<thumper> for what?
<davecheney> about anything
<davecheney> not the continuall flood of changes related to intel chips
<davecheney> and more importantly no bug change notifications
<thumper> hmm...
<thumper> I'm still getting emails
<davecheney> niemeyer: can you please make me an administator of https://launchpad.net/~gophers/+members
<davecheney> and or approve tim
<thumper> I've added myself, but it needs approval
<thumper> for the restricted team
<thumper> davecheney: I left my mark on the merge proposal FWIW
<davecheney> thumper: ta muchly, i'll get it sorted today
 * thumper fires off another two emails to juju-dev
<thumper> actually, lunch first
<niemeyer> davecheney: Done
<niemeyer> davecheney: and done
<davecheney> niemeyer: thanks muchly
<davecheney> niemeyer: please ignore my email then
<niemeyer> davecheney: and done as well on kicking
<niemeyer> davecheney: There are a couple of proposed members there.. I'm not sure if they should be or not
<niemeyer> davecheney: I'd wait until they come and explain their needs
<davecheney> niemeyer: SGTM
<davecheney> niemeyer: unrelated, did you get my mail about the guy with the GPIO board ?
<niemeyer> Actually, we can disregard at least one of them
<niemeyer> davecheney: Oh, I did.. but I just skimmed through and planned to go back.. I'll do that
<niemeyer> davecheney: I may be interested, depending on what it is
<davecheney> niemeyer: lemmie know before next tuesday, i'll forward you his price list
<niemeyer> davecheney: I'd probably be happy even if it's just a cable that lands on the protoboard
<niemeyer> davecheney: Thanks a lot
<davecheney> niemeyer: are you waiting on the GPIO <> serial cable ?
<niemeyer> davecheney: If it's too involved/pricey, I'll probably not want as it's likely microprocessed
<davecheney> niemeyer: i don't think it is, just a breakout board for the 20 gpio pins in some sensible groupings
<niemeyer> davecheney: Ah, sweet, that I'd be interested on
<davecheney> forward'ed email, lets take the discussion there
<niemeyer> davecheney: a friend did that by hand, splitting into spacing so that the two rows can land on both sides of the protoboard
<niemeyer> davecheney: That's pretty cool
<niemeyer> davecheney: One important detail to be aware of, which you probably already are, is that the pins aren't 5V-tolerant
<niemeyer> davecheney: worth mentioning just in case
<niemeyer> as this is the kind of thing one generally expects of such hardware
<davecheney> niemeyer: this is the nice thing about what this guy has done, along with the sheild, is a set of click together units
<davecheney> so you can just attach a light, or a button, etc
<davecheney> which is exactly what I want, as I can't solder for shit
<davecheney> it's been decades
<niemeyer> davecheney: Alternatively, you can go a long way with protoboards.. these days there are some nice small ones for that kind of "deployment"
<niemeyer> davecheney: It's more fun to evolve the project as well
<davecheney> niemeyer: i'm not really interested (at the moment) in _using_ the gpio pins
<davecheney> but I am interested in write an interface to them for Go
<niemeyer> davecheney: Ah, I see.. you just want to write the software
<niemeyer> davecheney: Neat, I thought about doing that as well.. will be glad to use your package instead. ;)
<davecheney> last week I met Alex Bradbury from the RPi foundation
<davecheney> actually, i'll send you my notes, that is easier
<niemeyer> davecheney: For that, I think a led and a resistor would do
<davecheney> niemeyer: exactly
<davecheney> you can already using the GPIO in bash, via /sys
<davecheney> the libgpio driver uses a mmap of a magic area of /dev/mem
<niemeyer> davecheney: Yeah, that's quite neat.. the interrupts are probably more interesting, though
<davecheney> yup, that is why I have ordered a button
#juju-dev 2013-02-15
<wallyworld___> davecheney: g'day. i want a mutex with a timeout. any pointers? i couldn't see native support in the go libs? is there anything we use already?
<davecheney> wallyworld___: hmm, might have to use something with a channel
<davecheney> let me ponder for a few mins
<wallyworld___> ok
<wallyworld___> hard to believe a modern language doesn't have such a construct built in
<wallyworld___> or at least in the libs i mean
<davecheney> i never ran across such a thing in java
<davecheney> can you give me an example from another language
<davecheney> probably can do it with a waitgroup and a goroutine
<davecheney> but a mutex that unlocks itself sounds dangerous
<wallyworld___> java has had it for quite a while
<wallyworld___> not unlocks itself, just a wait to have the acquire not wait forever
<wallyworld___> so you can say, try and grab this thing, but if not successful after x seconds, return with an error
<wallyworld___> useful to avoid deadlocks
<wallyworld___> and also when making network calls
<davecheney> oh, right
<davecheney> i understand now
<davecheney> you don't want to block on the lock forever
<davecheney> understood
<wallyworld___> the java stuff is in java.util.concurrent
<wallyworld___> yes
<davecheney> probably still going to look like a channel
<davecheney> ie, you try to send a command to something via a channel
 * davecheney searches archives
<wallyworld___> ok. i may extend the built in mutex to provide a Lock(timeoutms int) method, using a channel or whatever
<wallyworld___> i can't be the only one who needs this
 * davecheney agrees
 * davecheney continues to search archive
<wallyworld___> thank you
<wallyworld___> i'll look as well
<davecheney> if you feel brave you can as on #go-nuts
<wallyworld___> i'll see what i can find first, my flame retardant suit in at the cleaners
<davecheney> smart move, the annoying pedant quotient is quite high in that channel atm
<wallyworld___> :-)
<thumper> wallyworld___: chop off your tail dude...
<thumper> davecheney: I'm wondering if I raised the annoying pedant quotient
<thumper> :)
<davecheney> thumper: not possible
<davecheney> i got a bitchslap by @tqbf two days ago
 * thumper doesn't know who that is
<thumper> wallyworld__: you are broken
<wallyworld__> yep
<wallyworld__> it's only freenode too
<wallyworld__> no issue with canonical channels
<thumper> wallyworld__: how are you connecting to freenode?
<wallyworld__> using auto identity in quassel
<thumper> I seem to have lost my menus for quassel
<thumper> dumb unity
<wallyworld__> davecheney: i couldn't find anything, so i did this - seems to work http://pastebin.ubuntu.com/1654692/
<wallyworld__> thumper: you had your chance to solve all of Unity's problems before you let them
<wallyworld__> left
<wallyworld__> you failed :-P
<thumper> wallyworld__: unfortunately I think that code is flawed
<wallyworld__> :-(
<thumper> wallyworld__: lets say you Attemt(100) and it fails
<davecheney> wallyworld__: looking at your sample
<thumper> but 50ms later, the lock succeeds
<davecheney> i need to think through it some more
<thumper> wallyworld__: the channel then has a true in it
<thumper> next time you attempt
<thumper> you pull off the true, but have another attempted lock pending
<thumper> davecheney: am I right in that reading?
<wallyworld__> ah, i want to make the channel locally
<wallyworld__> not as an attribute of the mutex
<wallyworld__> then i also can ditch the New()
<davecheney> thumper: yeah, it's even a little more complicated because the channel is not buffered
<thumper> right, so the previous go routine is still alive
<davecheney> so chan <- true does not succeed unless something else comes along and does <- chan
<davecheney> I think there is a possiblity the lock could leak in the locked state
<davecheney> and locks are not re-enterent
<thumper> ouch
<thumper> so broken by design
<thumper> sorry wally
<thumper> you suck :-)
<davecheney> that sounds like my cue to go to lunch
<wallyworld__> http://pastebin.ubuntu.com/1654719/
 * thumper is laughing to himself
 * thumper feels lucky to know wallyworld__ personally and knowing he can handle the ribbing
 * thumper clicks on rev2
 * wallyworld__ contemplates ending it all, can't take it anymore
<thumper> wallyworld__: still have the issue of the lock attempting to lock after the method has returned
<thumper> wallyworld__: perhaps this crazy thing...
<thumper> oh oh...
 * thumper writes some go
<wallyworld__> ah yes, you are right
<wallyworld__> i'll see if i can fix that
<wallyworld__> i just wanted to first ditch the channel from the mutex
 * wallyworld__ still doesn't understand why this is so hard in Go :-(
<thumper> wallyworld__: http://pastebin.ubuntu.com/1654742/
<thumper> might have some syntax wrong
<wallyworld__> or http://pastebin.ubuntu.com/1654745/
<thumper> nah
<thumper> that won't work
<thumper> as the defer is run when the method ends
<thumper> which may be before the Lock succeeds and the goroutine finishes
<thumper> I am assuming that the lifetime of the goroutine can outlive the surrounding function
<wallyworld__> i wonder what happens which the function ends - are the channels cleaned up straight away?
<thumper> they are created on the heap (effectively) and killed when no longer reffed
<thumper> so the channels will no doubt still be around
<wallyworld__> what happends to the go routines that are running - i guess they keep going
 * thumper hinks
<thumper> I think so
<thumper> but I'm really just guessing
<wallyworld__> i had assumed everything would be cleaned up, hence my original solution
<wallyworld__> but if that doesn't hold true, then yours looks better for sure
<wallyworld__> except that with yours the test spews out all osrts of go routine type errors
<wallyworld__> ah deadlock
<wallyworld__> in the failure test
 * wallyworld__ debugs
<thumper> heh
<thumper> I did say it might not be right
<thumper> my first go in anger
<thumper> others so far have been little test scripts
 * thumper pokes the help command
<wallyworld__> i wasn't criticising :-)
<thumper> school run, bbs
 * thumper sobs quietly
<thumper> but in a happy way as I understand it, just... ugh
 * thumper now understands all the command stuff
<thumper> now to just write a useful help command
<thumper> (FSVO all)
<thumper> davecheney: we don't do much with internationalization do we?
<thumper> davecheney: is there any locale support in go?
<davecheney> virtually none
<davecheney> ^ as in, we do
<davecheney> locale support ... nothing that looks like the c tools (iconv isn't it ?)
<thumper> not sure
<thumper> I'm just going to pretend the entire world speaks english
<thumper> :)
<davecheney> that's the spirit
<wallyworld__> davecheney: thumper: this seems to work ok now, http://pastebin.ubuntu.com/1655490/
<thumper> davecheney: what does %q do in fmt.Errorf ?
<wallyworld__> i could put this into goose but it doesn't belong there. what's our policy for utilis like this?
<davecheney> thumper: "quotes" things
<davecheney> but will also print them 'safely' for some value of safely i can't remember at the top of my head
<thumper> ta
<thumper> hmm...
<thumper> I wonder why we write help to stderr instead of stdout
<thumper> davecheney: ok, once I've been editing away on some go files
<thumper> davecheney: how to I (re)build the juju command??
<thumper> davecheney: nm
<thumper> davecheney: nah, had that wrong
<thumper> how do I rebuild?
<thumper> wallyworld__: you know?
<thumper> I just want to get this bit working and I can finish and have a drink
 * thumper taps his fingers
<thumper> no pressure guys
<thumper> hmm...
<thumper> found install
<thumper> seems to be mostly going now
<thumper> enough for me to call time and get a drink anyway
<thumper> caio
<fwereade> davecheney, thanks for reverting the store
<davecheney> fwereade: no worries mate
<davecheney> i think i'm missing email at the moment
<davecheney> or was that just poorly communicated
<fwereade> davecheney, I think it was screwed-up communications
<davecheney> oh well, it's fixed now
<fwereade> davecheney, yeah -- and it's really nice to have the thing I was planning to do first thing already done when I come in :)
<fwereade> davecheney, incidentally, re external dependencies... I am becoming entirely dissatisfied by the state of go in this regard, and starting to think that the only way to get anything resembling a consistent build is to copy every damn thing into thirdparty/
<fwereade> davecheney, which sucks, obviously, but seems to suck strictly less than every other option
<davecheney> fwereade: i understand
<davecheney> this is a problem that has occupied my thoughts for some time
<davecheney> i do not have anything to add at this point
<fwereade> davecheney, even goamz etc -- even if it's stable API-wise, new things are being added and it's only a matter of time before we start getting weird bugs that are eventually tracked down to "oh, you didn't update XXX? silly you"
<fwereade> davecheney, (not even new things -- just little fixes, improvements, etc)
<fwereade> davecheney, another thought -- the 4th option is for us to publish, ourselves, to a public bucket we control (on *any* openstack, so long as that bucket in configured for unauthenticated access) and make sure the public-bucket-url defaults to that
<davecheney> fwereade: yes, part of the problem is API breakage, major version changes
<davecheney> the other, much larger half, is behavioural changes, X.1, and X.Y.1 changes
<fwereade> davecheney, yeah, exactly
<davecheney> fwereade: yes, on the 4th optoin, i need to get a clear indication from the buisiness what these 'network hostile' customers look like
<fwereade> davecheney, (btw, we should *also* I think be checking hashes of the tools we use, and I don't think we do that... it's crazy that we have it for charms but not for the actual code that we run)
<davecheney> fwereade: i agree, if we have to stay with the tarball approach, then hashs' or maybe even sigs would be the order of the day
<davecheney> fwereade: on a scale of annoying to fucking us daily, where would you place the pkg version problem ?
<fwereade> davecheney, persistently annoying... the actual *detected* fuckery is relatively rare but I suspect that (1) probably someone is inconvenienced by it every single day and (2) critically, none of us can *tell* when we might be being fucked by it
<fwereade> davecheney, it's the uncertainty more than anything else
<rogpeppe> davecheney, fwereade, mgz: morning!
<davecheney> fwereade: understood, seconded
<fwereade> davecheney, eg bac produced a very helpful paste yesterday, with juju-core's bzr version and the go version at the bottom
<davecheney> i don't like that double checking your own local environment has to be the first step when debugging biuld breakage
<fwereade> davecheney, but that isn't actually enough, and I couldn't esily give you a complete list of external packages we depend on
<fwereade> davecheney, trashing src/ every time you have a problem is absurd, but it's starting to seem reasonable in my mind
<fwereade> rogpeppe, heyhey
<davecheney> fwereade: for you and me and rog, it is acceptable
<davecheney> for blue, who have branches in goose and juju-reo, it is totally unacceptable
<fwereade> davecheney, I cannot ask anyone else to do that without permanently staining my honour
<fwereade> davecheney, exactly
<rogpeppe> wallyworld_: ping
<wallyworld_> hi
<rogpeppe> wallyworld_: http://play.golang.org/p/YXAHy5kBfD
 * wallyworld_ looks
<rogpeppe> wallyworld_: that's the classic method
<wallyworld_> ok. the good thing about my home grown approach is you don't need a New()
<wallyworld_> in any case, why isn't this part of the std libs i wonder? why is everyone forced to roll their own?
<rogpeppe> wallyworld_: it's not that common a requirement (people usually need to wait for channels to be available or functions to return, not mutexes to be taken), and it's trivial to implement, as you can see.
<rogpeppe> wallyworld_: we could make the above example not need New too
<wallyworld_> it's very common in any environment i've ever worked in. trivial yes, but still code that has to be written and live somewhere. goose? juju-core? yet another 3rd party lib we create?
<wallyworld_> i guess i'm saying it should have been included out of the box
<rogpeppe> wallyworld_: i've written go for quite a while now, and although i know that idiom, i've never required it
<rogpeppe> wallyworld_: i think it's probably because mutexes aren't usually used to guard long-lived things
<wallyworld_> really? ok. forget Go per se. when using mutexes with network  or other resources, you need to timeout to prevent deadlocks etc
<wallyworld_> i guess compared to java.util.concurrent, i'm finding Go's concurrent support to be a bit primitive
<wallyworld_> so, thanks for the code btw, it does look nice. but where should we put it?
<wallyworld_> not Goose, cause then other stuff can't easily use it
<rogpeppe> wallyworld_: honestly, it's trivial - if you need it, just copy and paste it.
<wallyworld_> or maybe just stick it there for now
<wallyworld_> aargggh noooo. not copy and paste
<TheMue> Morning
<fwereade> TheMue, wallyworld_, heyhey
<wallyworld_> hi
<TheMue> Somewhat flaky connection this morning. :/
<TheMue> fwereade, wallyworld_ : Hiya
<rogpeppe> wallyworld_: seriously, it's about as trivial as a for loop
<TheMue> fwereade: I yesterday pushed the last proposal again.
<fwereade> TheMue, cool, thanks, I'll take a look as soon as I can
<wallyworld_> rogpeppe: that's not the point - it's still business logic that can and should be re-used via being packaged
<wallyworld_> Go is verbose enough already without yet more cut and paste - they all start to add up
<rogpeppe> wallyworld_: out of interest, what are you using the mutex for?
<wallyworld_> rogpeppe: to guard the Authenticate call in a Goose client (which we are now sharing between all nova, swift etc instances). we can't allow 2 users to attempt to Auth at the same time
<wallyworld_> but Authenticate() is a network call
<wallyworld_> so we don't want to block indefinitely
<rogpeppe> wallyworld_: presumably the network call itself will time out eventually?
<wallyworld_> perhaps. who knows. we can't asume that
<wallyworld_> even if it does, the timeout might be tool ong
<rogpeppe> wallyworld_: it's easy to make a network call time out if you want
<rogpeppe> wallyworld_: i think i'd go in that direction (having one thing timing out on the operation in question) rather than have lots of things all timing out on the mutex
<fwereade> rogpeppe, http://thecodelesscode.com/case/71
<wallyworld_> we are using http.client as the transport - request.Do() and all that - you saying we can make that time out?
<rogpeppe> fwereade: nice. i think i've missed the point though.
<rogpeppe> wallyworld_: yes, in two ways, one much easier than the other
<wallyworld_> rogpeppe: out of curiousity, how would i get rid of the New() in the implementation using a channel, if the channel needs to be make()ed ?
<rogpeppe> wallyworld_: use a mutex :-)
<fwereade> rogpeppe, I was alluding to the "it will eventually time out" assertion, probably not in a very constructive way
<wallyworld_> ah, yes, ok
<rogpeppe> wallyworld_: http://play.golang.org/p/vooGdZw5aa
<wallyworld_> yes, that seems sensible, thanks
<fwereade> bbiab
<rogpeppe> wallyworld_: that's actually a useful general technique for making any zero value usable without a New function.
<wallyworld_> rogpeppe: i'll look at the http request timeout, but it will need a little thought - we only really want to do it for Auth calls, since they are the only ones that need to be serialised. we don't really need to do anything for other send request calls
<wallyworld_> so having a mutex with a timeout works nicely
<rogpeppe> wallyworld_: if the auth times out, does it matter if the actual authenticate call is still going on the background?
<wallyworld_> not really - i don't think so, but need to work through that scenario
<rogpeppe> wallyworld_: that is, is the authenticate call idempotent? if it's failed once, do you want everything that wants to use it to fail?
<wallyworld_> without it succeeding, nothing can really work from that point
<wallyworld_> since nothing will have a token
<wallyworld_> nor the endpoint urls
<wallyworld_> rogpeppe: thanks for the input, i have to head off to soccer. i'll revisit what's been done with the new info next SOD
<rogpeppe> wallyworld_: ok
<rogpeppe> wallyworld_: i have a little example for you when/if you come back this evening
<wallyworld_> i have a few more minutes before i have to go
<rogpeppe> wallyworld_: http://play.golang.org/p/sd1Cx2Ey-c
<rogpeppe> wallyworld_: where the authenticate function is standing in for your Auth call.
<wallyworld_> rogpeppe: excellent thanks. it will take me a little time to digest. i'll read it in detail after soccer
<rogpeppe> wallyworld_: look ma, no mutex timeouts! :-)
<wallyworld_> rogpeppe: yes indeed. i wonder how reusable it is though. eg with a mutex.TryLock() type operation, it can be used trivially as needed
<wallyworld_> this latest solution *seems* to mix a fair bit of boilerplate with the business logic
<wallyworld_> but i need to read it fully
<wallyworld_> whereas with the mutex.TryLock(), there is no boilerplate in the business logic
<wallyworld_> anyway, gotta run, hopefully back later. thanks again for the code, i'll learn something for sure just reading it
<rogpeppe> wallyworld_: see ya!
<rogpeppe> wallyworld_: have a good footy session
<wallyworld_> i will hopefully, thanks :-)
<rogpeppe> wallyworld_: for the record, here's some of the boilerplate factored out: http://play.golang.org/p/XHJ_PLO6RR
<dimitern> fwereade: ping
<fwereade> dimitern, heyhey
<dimitern> fwereade: hey :)
<dimitern> fwereade: about that CL from yesterday
<dimitern> fwereade: https://codereview.appspot.com/7317045/
<fwereade> dimitern, rogpeppe: IMO it is worth having a package just for those constants -- is there some cost to a package that I'm not aware of?
<dimitern> fwereade: how do you feel about moving hook inside charm/, rather than have it in charm/hook/
<fwereade> dimitern, rogpeppe: I'm probably +1 on chook rather than uhook
<rogpeppe> fwereade: i see the hooks as very closely related to charms, so can't really see that it needs a new package. but i don't mind much. no there's no particular cost to a package.
<fwereade> dimitern, rogpeppe, I don't have a strong argument tbh, it's just that charm.HookUpgradeCharm feels irritatingly verbose compared to chook.UpgradeCharm
<rogpeppe> fwereade: if the constants were in charm, there would be no need for the awkward charm/hook uniter/hook name clash
<rogpeppe> fwereade: i'd go for charm.HUpgradeCharm, i think
<fwereade> rogpeppe, eww ;p
<dimitern> rogpeppe: but we might have to rename a few things to make them unambiguous
<dimitern> :)
<fwereade> dimitern, rogpeppe: ha: charm/hooks vs worker/uniter/hook would resolve it
<dimitern> +1
<fwereade> dimitern, rogpeppe: and read better just about everywhere, I think
<dimitern> fwereade: so rename it to charm/hooks
<fwereade> dimitern, I'd like to see what rogpeppe thinks
<dimitern> rogpeppe: sounds good?
 * rogpeppe sucks his teeth
<rogpeppe> fwereade: the singular/plural distinction seems... arbitrary
<fwereade> rogpeppe, hooks.UpgradeCharm vs hook.Info seems to read pretty well to me
<dimitern> fwereade, rogpeppe: uniter/hookinfo and use hi.* ?
<rogpeppe> fwereade: haven't you got that the wrong way around?
<fwereade> rogpeppe, I don't think so... hooks enumerates the available hooks, while hook is the uniter-specific package dealing with info attached to single hook executions
<rogpeppe> fwereade: oh yeah, i'd forgotten that UpgradeCharm is a hook :-)
<fwereade> rogpeppe, yeah, the actual upgrade code is mostly in uniter/charm, which itself collides with charm :(
<rogpeppe> fwereade: ha ha! http://godoc.org/launchpad.net/juju-core/worker/uniter?view=import-graph
<rogpeppe> fwereade: that's a bit better: http://godoc.org/launchpad.net/juju-core/worker/uniter?view=import-graph&hide=1
<fwereade> rogpeppe, my eyes, my eyes; the goggles, they do nothing
<fwereade> rogpeppe, yeah, slightly less awful
<rogpeppe> fwereade: why do we need a uniter/hook package again?
<fwereade> rogpeppe, primarily to avoid the everything-friends-with-everything situation in (eg) state that makes it so hard to tell what uses what in arbitrarily inappropriate ways
<dimitern> cool graph, i didn't know you can generate these from godoc
<rogpeppe> fwereade: does anything outside of uniter itself use hook.Info?
<fwereade> rogpeppe, uniter/relation
<fwereade> rogpeppe, for the relation hook queues
<rogpeppe> fwereade: ah, of course, i thought it was something like that.
<rogpeppe> fwereade: presumably, it *could* be relation.HookInfo ?
<dimitern> rogpeppe, fwereade: do do we reach a consensus?
<fwereade> rogpeppe, nope, it's not just for relation hooks
<fwereade> rogpeppe, and I'm really not keen on just jamming everything into uniter
<rogpeppe> fwereade: i mean theoretically, but yeah
<rogpeppe> fwereade: i don't think you *can* jam it into uniter
<rogpeppe> fwereade: because then there would be a cycle
<fwereade> rogpeppe, we could if we jammed relation in as well -- I seem to recall yu arguing for that once, but I was not then and am not not convinced that's a good idea
<fwereade> s/not not/not now/
<fwereade> rogpeppe, can we agree on charm/hooks and uniter/hook on the basis that it leads to clarity and readability at the "cost" of having more smaller packages that do one thing only? ;p
<rogpeppe> fwereade: i think i'd go for uniter/hookinfo, as that's really what it is
<fwereade> rogpeppe, dimitern: the other possible direction *may* be uniter/state (not that *that* doesn't have aliasing problems...)
<rogpeppe> fwereade: this is a package with one type with a single method, right?
<fwereade> rogpeppe, yeah, I think so
<rogpeppe> fwereade: in fact... i've just seen the logic for charm/hooks and uniter/hook
<dimitern> fwereade: move uniter/hook stuff in uniter/state ?
<rogpeppe> fwereade: let's go for that
<dimitern> fwereade, rogpeppe: ok, so finally :) charm/hooks then?
<rogpeppe> dimitern: naah. we don't need another state package that's just there for hook info :-)
<fwereade> rogpeppe, cool :)
<rogpeppe> dimitern: yeah. sorry for the swithering.
<dimitern> :) np
<fwereade> rogpeppe, dimitern: the suggestion would have been to move uniter.State in there as well, but I'm not sure what that costs usor whether anything blocks it: so, yes, charm/hooks and uniter/hook
 * fwereade does the happy dance
<rogpeppe> dimitern: the godoc package graph functionity is cool, isn't it. it's the first time i've used it on juju...
<dimitern> rogpeppe: it would've been even cooler if you can rearrange the nodes like juju-gui does with machines
<rogpeppe> dimitern: definitely
<rogpeppe> dimitern: i'm sure gary would accept a patch :-)
<fwereade> TheMue, I've sent some more thoughts
<fwereade> TheMue, this might go better, I think, if you do the following:
<fwereade> TheMue, 1) trivial CL dropping the lxc/network files
<fwereade> TheMue, 2) CL for just the backend, with tests
<fwereade> TheMue, 3) CL with the Storage implementation, with tests (as they are today)
<fwereade> TheMue, 4) CLs with things like the config, the provider, the environ, etc, with tests
<TheMue> fwereade: Thx for the review
<TheMue> fwereade: Yep, the real CL for the environ etc has already been intended to follow. This has only been a consolidation.
<TheMue> fwereade: Maybe already done too much, so I'll split it.
<fwereade> TheMue, thanks, I'd like that
<TheMue> fwereade: No problem.
 * TheMue still tends to create too large CLs, shit. *sigh*
<fwereade> TheMue, I think we definitely need independent tests for the backend though -- and if you're splitting it, it might be a good idea to put it in its own package to prevent the pain of unpicking it later
<fwereade> TheMue, I offend on that front myself, I know :(
<fwereade> TheMue, when I manage not to everything goes much smoother though ;)
<TheMue> fwereade: Yep
<dimitern> so if I have a map[string]bool as an argument to a func, does it have to be *map... to change it in place?
<fwereade> dimitern, no, don't think so, a map is already a reference
<dimitern> fwereade: cheers
<fwereade> dimitern, http://play.golang.org/p/GEEcsp2KPp
<dimitern> fwereade: yeah, I keep getting mixed up occasionally with the reference/pointer logic for maps/slices still
<fwereade> dimitern, I know the feeling, it'll bed in soon enough :)
<dimitern> rogpeppe, fwereade: here it is https://codereview.appspot.com/7317045
<fwereade> dimitern, cheers
<dimitern> i'll change the description on submit - i couldn't find a way otherwise
<fwereade> dimitern, you can do lbox propose -edit
<fwereade> dimitern, looks good though, just a remark or two
<fwereade> bbiab
<dimitern> fwereade: ok, 10x
<dimitern> fwereade: since i'm not aware how to define a const slice, I'll just make a method that returns a copy of the private for both types of hooks
<dimitern> rogpeppe: ping
<rogpeppe> dimitern: pong
<dimitern> rogpeppe: you're ok with the CL?
<rogpeppe> dimitern: looking
<rogpeppe> fwereade: i really don't think we need to copy UnitHooks every time it's used
<rogpeppe> fwereade: there are plenty of places where we have globals that are immutable by convention
<fwereade> rogpeppe, how is "immutable by convention" not just an "invitation for bugs"?
<rogpeppe> fwereade: there are many possible places for bugs. this one is not easy to trip over.
<rogpeppe> fwereade: in my view doing this it would create more garbage for very little gain.
<dimitern> rogpeppe: i don't see a problem copying a private slice like this
<rogpeppe> dimitern: i think it sets a bad convention. it's really ok for a package to expose tables of data directly.
<rogpeppe> dimitern: see, for example, the unicode package in the standard library
<fwereade> rogpeppe, if all your friends jumped off a bridge... ;p
<rogpeppe> fwereade: there would be good reason for it... yeah :-)
<dimitern> fwereade: what do you think can go wrong with slices? somebody changing it silently? we'll catch this is a review
<fwereade> dimitern, I think your faith in the review process is perhaps a little too solid... bugs can and do make it through review, even obvious ones... but if people really object to this small and cheap nod towards safety/sanity I can't be bothered to fight it :)
<dimitern> i'm ok either way, I really want to land this, so I can finish my bug fix
<fwereade> dimitern, then I leave it to your consicience :)
<dimitern> fwereade: I already did what you suggested
<dimitern> rogpeppe: is it really that big of a difference?
<rogpeppe> dimitern: i think of it as increasing complexity due to unjustified paranoia about side effects. we use these things in precisely one place, in a range statement. making a copy seems total overkill.
<fwereade> rogpeppe, that sounds like an assertion that we will only ever use these things in one place...
<rogpeppe> dimitern: if we think it's justified here, then we will never be allowed an exported data table in any package, and i think that's not great
<rogpeppe> fwereade: i think it's easier to guard against undesired mutation than you fear
 * dimitern gets a coffee and sits waiting
<fwereade> rogpeppe, what is it that's difficult about copying them?
<rogpeppe> fwereade: it's more code and more garbage generated for no reason.
<rogpeppe> fwereade: i think a table variable is a very elegant and simple thing. i don't think we should disallow ourselves that.
<dimitern> rogpeppe: are the std lib packages using some special built-in way to define immutable exported slices?
<rogpeppe> dimitern: nope
<rogpeppe> dimitern: you can change 'em, but that's your own fault if you do.
<dimitern> rogpeppe: so you can change them and screw up everybody using the package from that time on?
<rogpeppe> dimitern: sure
<rogpeppe> dimitern: you can change os.Stdin too
<dimitern> fwereade: can you point out your concerns about changing these exported slices in a bad way?
<rogpeppe> dimitern: or image.Black, or os.ErrNotExist
<dimitern> rogpeppe: the added code is really 6 lines including comments, and since the slices are tiny making a copy doesn't at all sound like an overkill
<fwereade> rogpeppe, are you arguing that it is *good* to be able to change, say, image.Black? what's the benefit?
<rogpeppe> fwereade: i'm arguing that it's good to be able to expose simple static values as variables
<rogpeppe> fwereade: and that that's not actually error prone - you have to go out of your way to fuck it up.
<dimitern> well, if taking go std lib as best applied practices, then it certainly seems to me following the same pattern is clearer and not unexpected behavior
<rogpeppe> fwereade: yes, if we had a language with const, we'd probably use that, but we don't, and it works ok.
<rogpeppe> dimitern: +1
<dimitern> I wish go had const slices
<dimitern> or a way to mark an exported immutable, but alas..
<dimitern> how about a programmatic solution - something like go fix or similar, which is able to detect such things?
<fwereade> dimitern, like I said, it's between you and your conscience -- I just wish there was a better argument on the other side than "the stdlib does it so it must be ok", with an implied "encapsulation is teh stupids because everybody always considers every ramification of their actions" :(
<dimitern> going through the code and making sure things marked in some way (eg. comments) are not touched
<dimitern> fwereade: i certainly see your point
<dimitern> fwereade: and agree encapsulation is great, but why haven't we done that before (copy exported data) - or this is the first case?
<dimitern> fwereade: I mean *have we done*
<fwereade> dimitern, I have not gone through and checked everywhere -- but certainly ISTM to be good hygiene to (eg) copy a struct's internal maps when returning it from a method
<fwereade> dimitern, I feel it's essentially the same case
<jam> fwereade: "if all of your friends jumped off a bridge": http://xkcd.com/1170/
<fwereade> jam, indeed :)
<jam> has a good point that yeah, if everyone I know seems to think that the most rational thing to do is X, they are probably right
<dimitern> jam: hey :) i thought of that as well
<fwereade> I had it uppermost in my mind as I typed it, believe it or not
<jam> I probably agree that "immutable by convention" is asking for that one case where someone doesn't know the convention.
<jam> copying a *slice* is trivially cheap, because it is just a reference object, but I haven't looked at the code review.
<rogpeppe> jam: hopefully we ourselves *do* know the convention :-)
<rogpeppe> jam: i think we were talking about copying the contents of the slice here.
<fwereade> rogpeppe, that is a hideously short-sighted attitude IMO
<fwereade> rogpeppe, if we get this right, people will still be working on the codebase N years in the future
<rogpeppe> fwereade: i think it's reasonable to consider the std lib as best practice.
<fwereade> rogpeppe, like go get, huh?
<rogpeppe> fwereade: that's not the standard lib, it's a command.
<dimitern> jam: that's the CL https://codereview.appspot.com/7317045/ if you want to take a look
<fwereade> rogpeppe, it would still seem to argue that the authors of go can do profoundly short-sighted things
<rogpeppe> fwereade: what you're saying is that we should never be allowed *any* global exported variables from any package.
<rogpeppe> fwereade: and i'm slightly surprised at your attitude, coming from python where you can change *anything* :-)
<fwereade> rogpeppe, why do you think I'm so happy doing go? this sort of thing is seductive but IME it screws you up in the not-very-long-term
<rogpeppe> fwereade: it's a continuum.
<fwereade> rogpeppe, and I'm not saying *never* -- but I think there should probably be a good reason *for* doing so, much like using interface{}
<dimitern> fwereade, rogpeppe: how about a compromise? IsUnitHook(string) bool; IsRelationHook(string) bool (or Kind) ?
<dimitern> no that won't do actually - i still need to be able to iterate over them..
<rogpeppe> dimitern: yup
<rogpeppe> dimitern: BTW i just posted a couple of comments to the CL
<dimitern> rogpeppe: cheers
<rogpeppe> fwereade: honestly, we don't lose sleep about people mutating state.ErrUnauthorized. i don't think we should worry about a global UnitHooks either.
<fwereade> dimitern, rogpeppe: I first said I was not interested in fighting it almost 30 mins ago... I do not think I'm likely to be convinced that "immutable by convention" is ever a good idea, so please stop trying to convince me that it's somehow *better* than "actually immutable"... but I can also accept that there are much bigger deals
<dimitern> rogpeppe: you're not exactly right about IsRelation being the opposite of IsUnit, because relation hooks are suffices, and unit hooks are exact matches
<rogpeppe> dimitern: it is the opposite in terms of Kind, no?
<dimitern> ok, another thought - a func taking a callback func and iterating over unit/relation hook kinds?
<fwereade> rogpeppe, the furthest I'll go is "not a bad enough idea to lose sleep over"
<dimitern> rogpeppe: no, because IsRelation("foo-relation-changed") is false
<rogpeppe> dimitern: isn't it true that for all kinds k defined in charm/hooks, IsRelation(k) == !IsUnit(k) ?
<dimitern> rogpeppe: in terms of Kind, yes, but with actual strings I have to check for in expand/bundle (file names), it won't work
<fwereade> dimitern, please just go with whichever you personally prefer
<dimitern> i'm between the anvil and the hammer here :) I don't want to choose sides of this merely philosophical debate
<rogpeppe> dimitern: you don't seem to call IsUnit anywhere.
<dimitern> rogpeppe: no, I added it for a slightly different logic, now it's useless, so I agree and will remove IsUnit()
<dimitern> there's a fairly long discussion on golang-nuts about immutables: https://groups.google.com/forum/?fromgroups=#!topic/golang-nuts/BnjG3N77Ico
<dimitern> to satisfy both views, we can have something like func (kind Kind) RelationHooks() []Kind and the sane for unit hooks
<dimitern> s/sane/same/
<rogpeppe> fwereade: that's no better tbh
<rogpeppe> oops
<rogpeppe> dimitern: ^
<rogpeppe> dimitern: go with UnitHooks() []Kind if you like. i'll just sigh from a distance :-)
<dimitern> rogpeppe: but since we already have methods on Kind, it seems like the right place, no?
<rogpeppe> dimitern: it makes it sound like the it's returning a slice that has something to do with the receiving kind.
<rogpeppe> s/the//
<dimitern> rogpeppe: yeah, and if you don't have a kind, you have to do smth. like Kind("").RelationHooks() .. ugly
<rogpeppe> dimitern: yup
<dimitern> rogpeppe: so you agree to have UnitHooks() []Kind ?
<dimitern> albeit reluctantly i guess..
<rogpeppe> dimitern: *sigh* yes. does that mean i have to make testing.ServerCert into a function now?
<dimitern> rogpeppe: tyvm; I don't think we're setting a precedent here
<rogpeppe> i really do feel it's a slippery slope actually
<dimitern> fwereade, rogpeppe: final look? https://codereview.appspot.com/7317045/
<rogpeppe> dimitern: that's worse, sorry. it doesn't fix fwereade's issue, and if a function returns a slice, it *really* looks like it's ok to modify.
<dimitern> rogpeppe: ok, maybe I didn't get what I was supposed to do?
<rogpeppe> dimitern: i think you need to do. func RelationHooks() []Kind{a := make([]Kind, len(relationHooks); copy(a, relationHooks); return a}
<dimitern> rogpeppe: ah, ok - it'll not copy it simply by returning it
<rogpeppe> dimitern: indeed - slices are references
<dimitern> rogpeppe: fixed
<dimitern> ready to submit then?
<rogpeppe> dimitern: LGTM
<dimitern> rogpeppe: thanks!
<dimitern> I have this bug fix here - https://codereview.appspot.com/7305096 - anyone care to review?
<dimitern> fwereade, rogpeppe, jam? ^^
<fwereade> dimitern, re dummy's install hook
<fwereade> dimitern, is there anything currently checking its permissions?
<dimitern> fwereade: no
<fwereade> dimitern, best to just fix it then, I think :)
<dimitern> fwereade: but how?
<fwereade> dimitern, I think you can just chmod it? doesn't bzr see that as a change?
<dimitern> fwereade: not sure how to set +x on it, tried chmod +x but bzr didn't pick it up
<fwereade> dimitern, bah, ok... anyone?
<dimitern> fwereade: ah, you know, that's not the problem
<fwereade> dimitern, oh yes? something else does check that?
<dimitern> fwereade: my bad - I'm not checking before setting them and issuing a warning
<fwereade> dimitern, I've sent a few comments anyway
<dimitern> fwereade: dummy/hooks/install was already +, that's why bzr didn't pick it up
<dimitern> +x
<dimitern> fwereade: cheers
<fwereade> dimitern, ha! I completely missed that :/
<dimitern> fwereade: what do you mean about the block obfuscating the test? the for loop?
<fwereade> dimitern, the checks for the test data being the test data -- what relations are there, what it's called, what its rev is
<fwereade> dimitern, and as I say at the top I'd like those tests most of all if we had some hooks with problems, some without, and some missing
<dimitern> fwereade: not sure I get your point
<fwereade> dimitern, sorry, my first point or my second point?
<dimitern> fwereade: you mean the asserts before the loop are unnecessary?
<fwereade> dimitern, I think so, I'm certainly open to argument otherwise
<dimitern> fwereade: well, I agree they don't bring anything more than validating the all-hooks charm has what we need
<dimitern> fwereade: removing them does not weaken the test i think
<dimitern> fwereade: not sure about logging the name of the charm beforehand - this will cause assertions on log fail in other cases
<fwereade> dimitern, grar
<dimitern> fwereade: maybe instead, log the hooks as "charm/hooks/name"?
<dimitern> fwereade: and take charm name from meta.Name
<fwereade> dimitern, probably better not to put it into an apparent path if it doesn't refer to a real one, I think I preferred the original form
<dimitern> fwereade: without charm name or with?
<fwereade> dimitern, can we move that bit down, though, to where we do check setExec?
<fwereade> dimitern, with is fine
<dimitern> fwereade: sure, it seems the right place
<fwereade> dimitern, cool, ty
<dimitern> fwereade: and i'll add additional assets in dir_test to check perms after checking the logged warnings
<fwereade> dimitern, cheers
<rogpeppe> ha! i've worked out why i checking for ErrShutdown after server close is inherently racy.
<rogpeppe> obvious really, doh!
 * fwereade cheers at rogpeppe
<fwereade> rogpeppe, incidentally, https://codereview.appspot.com/7324049/ is back in review
<rogpeppe> fwereade: thanks, i'll try to have a look, although i'm making a concerted effort to move forward with the api today. the race (not a bug, just my own stupidity in not understanding the issue) has set me back a bit.
<fwereade> rogpeppe, no worries, I basically did everything you suggested -- but I decided that it was too much effort messing around with floatifying, so 100 cpu-power == 1 ECU
<rogpeppe> fwereade: sgtm
<fwereade> rogpeppe, cheers -- TheMue or dimitern, if you'd like to take a quick look I'd appreciate it
<dimitern> fwereade, rogpeppe: PTAL https://codereview.appspot.com/7305096/ - suggestions addressed
<fwereade> rogpeppe, one thing that is starting to bother me, though... I think the implicit one-environ-per-state will be *much* harder to fix after we release (much like the entity id types)
<fwereade> rogpeppe, I have a horrible feeling that it's not possible to address it in time though
<rogpeppe> fwereade: why do you think it's going to be particularly hard?
<rogpeppe> fwereade: (not that i necessarily disagree)
<rogpeppe> fwereade: you're thinking about cross-environment juju?
<fwereade> rogpeppe, because I think all the cross-collection keys will need an e#%d# prepended
<fwereade> rogpeppe, I'm thinking about multitenanting
<fwereade> rogpeppe, I know that is not a deliverable, so maybe I should put that on the "meh, fix it later" pile, but a lot of my current stress comes from feeling we have been too quick to do that in the past
<rogpeppe> fwereade: i don't think we'd particularly need someone's existing juju environment to upgrade to multitenanting
<fwereade> rogpeppe, just adding multitenanting should not break an existing one, though
<rogpeppe> fwereade: well, even if we do - it's just a major upgrade, we stop the world, fix the database, upgrade the clients, and carry on
<fwereade> rogpeppe, we have done no work to enable that
<rogpeppe> fwereade: indeed - major version upgrades need to be done
<rogpeppe> fwereade: but we can upgrade to allow major version upgrades, *then* change to support multi-tenanting
<fwereade> rogpeppe, I'm not sure that's trivial either... and while we can't do it, we're basically locked to our existing schema, which makes me nervous
<rogpeppe> fwereade: it's not trivial, but one of the main points of major version upgrades is to allow us to change db schemas, no?
<fwereade> rogpeppe, yeah, but *not* changing our schema is even better :)
<rogpeppe> fwereade: another possibility is keeping one State per environ, but making it possible to have several States in the same mongo; we could use a collection prefix.
<fwereade> rogpeppe, indeed, that might actually be smarter, hard to tell at this point
<rogpeppe> fwereade: it would certainly give more isolation
<fwereade> rogpeppe, anyway, I must not distract you from the API, sorry :)
<rogpeppe> fwereade: thanks :-)
 * rogpeppe undistracts
 * dimitern lunch
<TheMue> *sigh* Bad net today. *hmpf*
<rogpeppe> fwereade, dimitern, jam: this should fix at least one of the common errors we're getting in trunk: https://codereview.appspot.com/7310095/
<dimitern> rogpeppe: i'm on it
<rogpeppe>  i'm a bit worried by this though - i've never seen it; has anyone else other than jam? http://pastebin.ubuntu.com/1654670/
<dimitern> rogpeppe: I haven't
<dimitern> rogpeppe: reviewed, care to reciprocate? https://codereview.appspot.com/7305096/
<rogpeppe> dimitern: ok!
<rogpeppe> dimitern: thanks BTW
<dimitern> rogpeppe: yw
<fwereade> dimitern, sorry, a couple more comments, looking good though
<dimitern> fwereade: sure, np
<dimitern> fwereade: you're right about BundlePath(), I'll fix it
<dimitern> and the other thing as well, i'll change the logic to handle hooks dir paths better
<fwereade> rogpeppe, https://plus.google.com/hangouts/_/539f4239bf2fd8f454b789d64cd7307166bc9083#
<fwereade> mramm, rogpeppe, TheMue: sorry, restarting firefox, brb
<fwereade> mramm, rogpeppe, TheMue: ffs... restarting whole machine
<rogpeppe> fwereade: k
<fwereade> rogpeppe, screw it, updates seem like my only hope :/
<rogpeppe> dimitern: you've got a review. that was a bit of an unequal swap!
 * fwereade feels lucky
<fwereade> rogpeppe, mramm, TheMue: heh, are we done?
<dimitern> rogpeppe: tyvm
<dimitern> rogpeppe: sorry :)
<mramm> fwereade: yea
<fwereade> mramm, did we come to any conclusions?
<mramm> we ended with me saying that I thought that a vendor dir was a mostly effective way of handling dependencies back in the early days of svn and python
<mramm> and given that we are still a bit of a similar bleeding edge state with go
<mramm> I think it makes sense
<mramm> and there was general agreement -- with roger picking up the job of creating an experimental branch with everything "vendored in" to bzr
<fwereade> mramm, awesome; rogpeppe, thanks very much
<rogpeppe> fwereade: one problem with the third-party directory possibility: go test ./... takes a lot longer...
<fwereade> rogpeppe, ha, I bet :/
<fwereade> rogpeppe, incidentally, re printing log messages... making logging sane on the CLI feels like an awful lot of work for very little payoff at this stage
<rogpeppe> fwereade: yeah, it was just a passing thought
<fwereade> rogpeppe, I wanted that, but felt that gating this bug fix on "oh, and fix our logging while you're at it" would be unhelpful :)
<rogpeppe> fwereade: yeah, that's why i said "aside" in the comment
<rogpeppe> pwd
<fwereade> rogpeppe, no worries, I wasn't accusing you of doing the same... maybe slightly hoping you had a cunning plan I hadn't thought of, at most :)
<fwereade> rogpeppe, how much longer, incidentally?
<rogpeppe> fwereade: i'll tell you in a mo
<fwereade> rogpeppe, ouch
<rogpeppe> fwereade: no, i haven't started the tests yet
<fwereade> rogpeppe, ah, phew :)
<dimitern> fwereade, rogpeppe: I think it should be much better now - https://codereview.appspot.com/7305096/  - I even caught an issue I haven't noticed, once fixing the tests it popped out :)
<fwereade> dimitern, awesome, I'll take a look -- and would you give https://codereview.appspot.com/7324049/ a once-over please?
<dimitern> fwereade: sure, i'm on it
<dimitern> fwereade: reviewed
<fwereade> dimitern, cheers -- and LGTM for yours :)
<dimitern> fwereade: tyvm
<dimitern> rogpeppe: I think I addressed all you comments as well
<rogpeppe> fwereade: the thirdparty thing is a time waster. i'm leaving it for now. goyaml tests fail for me against tip :-(
<fwereade> rogpeppe, heh, that doesn't sound great :(
<rogpeppe> fwereade: (which is worrying, but not what i want to be worrying about right now)
<rogpeppe> fwereade: i suspect unsafe buggery
<fwereade> rogpeppe, sounds all too plausible
<fwereade> dimitern, not sure how space-stripping makes things simpler -- as it is I handle both "k1=v1" "k2=v2" and "k1=v1 k2=v2" cleanly (to fit both expected command line forms)
<fwereade> dimitern, expand?
<fwereade> dimitern, also seems like it would make "mem=" constraints very tricky to get right
<dimitern> fwereade: that was just a thought really
<fwereade> dimitern, no worries
<dimitern> fwereade: think of handling extra spaces though
<dimitern> fwereade: like "   k1=v1   " ?
<dimitern> fwereade: Split(" ") will give you empty entries in that case?
<fwereade> dimitern, hmm, yeah, maybe I should trim external spaces and ignore empties when split
<fwereade> dimitern, thanks
<dimitern> fwereade: yw
<dimitern> rogpeppe: when you can, please have a final look https://codereview.appspot.com/7305096/
<fwereade> gotta dash gents, happy weekends all
<dimitern> fwereade: happy weekend!
<mramm> It looks like atlanta is the confirmed city for the sprint
<dimitern> mramm: cool, dates as well?
<mramm> starting on the 4th
<mramm> we are still working on finalizing the hotel details
<dimitern> mramm: great
<dimitern> mramm: so we should be getting a mail about what flights to pick?
<dimitern> rogpeppe:  ping
<TheMue> fwereade: Enjoy your weekend.
<mramm> dimitern: fly in on sunday out on friday night or saturday
<mramm> book it through the agent and you are all good
<dimitern> mramm: ok, I'll contact the agent next week
<TheMue> Will do it on Monday too, in on Sunday, out on Friday evening/night. Found a good connection.
<rogpeppe> dimitern: pong
<rogpeppe> dimitern: (sorry, been in a meeting)
<dimitern> rogpeppe: sorry, I submitted it already, but if you thing I should've changed something, take a look pls
<rogpeppe> dimitern: that's fine. i've been a bit frantic all day. haven't reviewed as much as i could
<dimitern> rogpeppe: no worries, it's like that some days :)
<dimitern> rogpeppe: thanks for all reviews
<rogpeppe> dimitern: i've been frantic *and* made no significant progress, which is the really annoying thing. bug fixing all the way.
<dimitern> rogpeppe: sorry, if was bugging you too much actually
<rogpeppe> dimitern: np
<dimitern> but this thing - I wanted to get over with it already - whole week almost just for one bug fix :|
<rogpeppe> dimitern: yeah i know. sorry about that.
<rogpeppe> dimitern: i'm just trying to avoid being a critical-path-blocker for the juju-gui guys
<dimitern> rogpeppe: i see, what's up there?
<rogpeppe> dimitern: they're going to start implementing command-line-equivalent functionality in the api server
<rogpeppe> dimitern: essentially copying stuff from cmd/juju and making it available from state/api
<dimitern> rogpeppe: they're using the api already?
<rogpeppe> dimitern: they've made a connection to it...
<rogpeppe> dimitern: yeah
<dimitern> so no longer juju status polling
<rogpeppe> dimitern: no watchers yet. that was my main goal for this week, and i've not got there yet dammit
<dimitern> rogpeppe: sounds good, but I guess it's hard to integrate initially
<rogpeppe> dimitern: we have a bit of a problem too, that i'm just trying to work out the best way to get around
<dimitern> rogpeppe: i'll follow the development with keen interest, it's coming along nicely so far
<rogpeppe> dimitern: which is that quite a few of the command line commands use a juju.Conn (which is a (State, Environ) pair) but we don't have access to the Environ in the api server
<rogpeppe> dimitern: so the question is: can we make them do without the Environ?
<dimitern> rogpeppe: that's by design or not ready yet?
<rogpeppe> dimitern: for instance, deploy uses the environment storage to upload the charm
<rogpeppe> dimitern: the plan is to store charms in mongodb, but we don't do that yet
<dimitern> rogpeppe: blobs? is that sane performancewise?
<rogpeppe> dimitern: i dunno. is there a particular reason it should be bad?
<rogpeppe> dimitern: a charm wouldn't necessarily need to be stored as a single blob
<dimitern> rogpeppe: well, I don't know about mongo, but doing so in relational dbs is rarely a good idea
<rogpeppe> dimitern: it was part of the reason we moved to mongo, so i hope it won't be too bad.
<rogpeppe> dimitern: this makes it sound like it's ok: http://blog.mongodb.org/post/183689081/storing-large-objects-and-files-in-mongodb
<dimitern> rogpeppe: cool
<dimitern> rogpeppe: sounds way better than using blobs in a table
<rogpeppe> dimitern: the mgo package in supports gridfs: http://godoc.org/labix.org/v2/mgo#GridFS
<rogpeppe> s/in/even/
<dimitern> rogpeppe: and since it's all bson it shouldn't impair performance, and searches will be fast
<rogpeppe> dimitern: yeah
<rogpeppe> dimitern: although we won't be searching inside charms
<rogpeppe> dimitern: so i'm wondering if it might be easier to do the right thing and change our stuff to store charms in mongo than to get a juju.Conn to the api server
<dimitern> rogpeppe: maybe not now, but who knows
<rogpeppe> dimitern: true
<rogpeppe> dimitern: although we'd probably just index the metadata
<dimitern> rogpeppe: yeah
<rogpeppe> dimitern: the other place that uses the environ is status
<rogpeppe> dimitern: it uses it to find out DNS names of instances.
<dimitern> rogpeppe: what's the problem getting the api access the environ?
<rogpeppe> dimitern: we don't really want to give it that power
<dimitern> rogpeppe: maybe read-only
<rogpeppe> dimitern: and it's awkward because it'll have to watch the environconfig for changes
<dimitern> rogpeppe: true
<dimitern> rogpeppe: but then again, there are things in environ, which have to be proxied through the api, i think
<rogpeppe> dimitern: what do you mean?
<dimitern> DNSName for one
<dimitern> rogpeppe: I mean things you get out of status, how the gui used to get it
<rogpeppe> dimitern: yeah
<dimitern> rogpeppe: but if all of these are already in state, then i guess it'll be sufficient
<rogpeppe> dimitern: except they're not
<rogpeppe> dimitern: (perhaps they should be though - but that's more work)
<rogpeppe> dimitern: ha! there's a chicken/egg problem too
<dimitern> rogpeppe: the amount of work can be estimated by what they need, should be easy enough to judge
<dimitern> rogpeppe: they have a working prototype and all
<rogpeppe> dimitern: because the environ isn't valid until someone has connected to the state and pushed the secrets
<rogpeppe> dimitern: and that's done by connecting to the api server
<dimitern> rogpeppe: hmm, how did the gui used to get all that?
<rogpeppe> dimitern: but we're saying that the api server needs an environ
<dimitern> rogpeppe: yeah, maybe at first without caring about environ changes
<dimitern> rogpeppe: it's not changing that much anyway, is it?
<rogpeppe> dimitern: yeah, i think if we provided access to the environ, we'd let the api server come up without it, but any requests that need it would fail
<dimitern> rogpeppe: until? bootstrap?
<rogpeppe> dimitern: until a client connects and pushes the environ secrets
<dimitern> rogpeppe: but isn't the gui also a client like this?
<rogpeppe> dimitern: at which point it'll see a valid environ and api requests will start working.
<rogpeppe> dimitern: yes - the gui client won't be able to bootstrap
<rogpeppe> dimitern: until at least one non-gui client has connected
<dimitern> rogpeppe: really? why not?
<rogpeppe> dimitern: because the gui doesn't have access to the environment secrets.
<dimitern> rogpeppe: so you cannot pass with the gui only
<rogpeppe> dimitern: although... maybe it should
<rogpeppe> dimitern: ah no, it can't bootstrap
<dimitern> rogpeppe: well, if the gui is designed as a full cli replacement, it should be able to bootstrap as well
<rogpeppe> dimitern: because it has no way of talking to the environment provider directly in order to start the first machine
<rogpeppe> dimitern: unless we provide some sort of proxy that does that
<dimitern> rogpeppe: i suspect we'll do that, albeit not for 13.04 probably
<rogpeppe> dimitern: (which means that the user would be handing over their credentials to us, which they probably won't want to do)
<dimitern> rogpeppe: hmm, i see your point
<dimitern> rogpeppe: but having the same functionality from the gui means, we'll have environments.yaml somewhere in the gui
<rogpeppe> dimitern: yeah, but web browsers can't talk to amazon APIs AFAIK
<dimitern> rogpeppe: the backend will do that, but the environ can come from the gui
<rogpeppe> dimitern: yeah, but that's the point: do people trust us enough to give their credentials to the backend?
<dimitern> rogpeppe: and that's not entirely true either - you can have pure js in-browser AWS clients - there're firefox extensions doing that
<rogpeppe> dimitern: in which case, maybe it's a viable option. i don't know. it's a reasonable amount of work.
<rogpeppe> dimitern: and what about other providers?
<dimitern> rogpeppe: it surely is
<dimitern> rogpeppe: other providers - probably can use the same way to connect from the browser
<dimitern> rogpeppe: ofc, all this is possible, but it'll mean reimplementing a lot of client-based code in JS :)
<rogpeppe> dimitern: depends if they provide an API that's sane to access from javascript. tbh if it involves a browser-specific extension, it's probably a no-goer
<dimitern> rogpeppe: webkit / gecko pretty much rule all that's not IE, so even having extensions is not unheard of
<dimitern> rogpeppe: for that password manager app I worked in uniblue, we had extensions for chrome, ff and ie, and the ch/ff shared a lot of common code
<dimitern> but all that is an entirely different direction for speculation :)
<rogpeppe> dimitern: i think a proxy charm would be a nicer solution (i.e. given one juju environment, you can bootstrap another)
<dimitern> rogpeppe: that sounds interesting in more ways than just for gui use
<rogpeppe> dimitern: yeah, there are lots of interesting recursive possibilities :-)
<dimitern> rogpeppe: anyway, interesting times ahead :)
<dimitern> I'm off then
<rogpeppe> dimitern: oh yes
<rogpeppe> dimitern: have a great w/e!
<dimitern> happy weekend all :)
<dimitern> rogpeppe: 10x, you too
<rogpeppe> right, that's me for the week
<rogpeppe> have fun all!
#juju-dev 2013-02-17
<thumper> davecheney: morning
<thumper> davecheney: got a few minutes for a question?
<davecheney> thumper: morning!
<davecheney> sure
<thumper> skype?
<davecheney> sure, lemmie go upstairs where it is quieter
 * thumper pauses the music
 * thumper waits for davecheney to call
<davecheney> thumper: http://play.golang.org/p/ZOSQFos_Jn
<davecheney> go build - builds
<davecheney> alias gb='go install -v'
<davecheney> gb ./...
<davecheney> lias gb='go install -tags debug -v'
<davecheney> alias jc='cd /home/dfc/src/launchpad.net/juju-core/'
<davecheney> gb ./...
<davecheney> jc
<davecheney> gb ./...
<davecheney> go tset ./...
<davecheney> go test ./...
<davecheney> s.Foo()
<davecheney> (s S) Foo()
<davecheney> (&s).Foo(
<davecheney> type I int
<davecheney> func (i I) add(a int) { a += i)
<davecheney> var i I
<davecheney> i.add(1)
<davecheney> func (i *I) add(a int) { *i += i }
#juju-dev 2014-02-10
<axw> axw> wallyworld: my modem keeps resetting itself, may not be able to make standup
<wallyworld> ok
<waigani> axw, wallyworld sorry guys, connection problems
<axw> waigani: nps, we just called it a wrap
<waigani> ah cool
<rogpeppe> mgz: standup?
<mgz> rog, whoops., thanks
<mgz> ...and g+ decides it's time to play up
<rogpeppe1> my net connection is v dodgy currently
<rogpeppe1> mgz: what's the standard procedure for changing the deps on the bot?
<rogpeppe1> mgz: just ssh in and run godeps -u?
<rogpeppe1> dimitern: do you know?
<mgz> rogpeppe1: pretty much
<mgz> I can do it if you like
<rogpeppe1> mgz: thanks
<mgz> only funny if you want to change the older branches as well
<rogpeppe1> mgz: i think it must be using the old version of mgo, which is probably why tests haven't been failing all the time there
<mgz> (I manually pulled and built last time, probably using godeps wouldmake more sense)
<mgz> rogpeppe1: that's likely
<mgz> I should have been the one to bump and didn't
 * dimitern is away for 2h
<dstroppa> JoshStrobl: have a look at the debug-hooks command, it really helped me
<dstroppa> https://juju.ubuntu.com/docs/authors-hook-debug.html
<lazyPower> Greetings, I'm looking over charm-tools and I found a rare condition that the template generator breaks on adding charm tests. I'm trying to get my environment working so i can patch the bug, however following along in Hacking.txt results in the following output when running make, or make test: http://paste.ubuntu.com/6909757/
<lazyPower> I get this in other projects too, is this something I"ve got fouled up in my environment, or am I missing something obvious to seasoned python hackers?
<natefinch> marcoceppi: ^^ any ideas?   It looks like it has the right permissions to run
<natefinch> lazyPower: I'm guessing it's probably not running that python, but some other python... but I'm not familiar enough with the charm tools to know what might cause that
<marcoceppi> lazyPower: one sec
<lazyPower> marcoceppi, natefinch,  I foudn the issue. It was on a NFS hosted symlinked directory. Moving it onto my primary for $HOME seems to have worked.
<lazyPower> so, it was my env. ta
<TheMue> rogpeppe1: I proposed https://codereview.appspot.com/58510045/ again. I removed the passing of the location. So far I have no better idea than passing at least juju-home and env name.
<TheMue> rogpeppe1: Or storing it during bootstrap in the Environment instance in state.
<rogpeppe1> TheMue: ok, thanks. will take a look soon.
<rogpeppe1> TheMue: did you consider my suggestion of a method on environs.EnvironProvider?
<TheMue> rogpeppe1: At least CLI now works for local provider.
<TheMue> rogpeppe1: The method would/could be needed to access. But the API server runs as root but the log location is determined by the bootstrap user.
<rogpeppe1> TheMue: the API server is started by the bootstrap user, isn't it?
<TheMue> rogpeppe1: During this time rsyslogd is configured and that's it.
<TheMue> rogpeppe1: After sudo as root. ;)
<TheMue> rogpeppe1: Simply try a bootstrap and do a ps -ef. It runs as root. *sigh*
<rogpeppe1> TheMue: i'm not sure how the fact that it's sudo'd precludes it from knowing stuff about the user that started it. but don't worry about that for now.
<TheMue> rogpeppe1: Maybe I'm only missing the path to the information I need. Any good idea is welcome.
<TheMue> rogpeppe1: The next bigger step will be the unit tests. Need to export internal parts again to mock real behavior.
<hazmat> this sound familiar to anyone "0 17:51:45 ERROR juju runner.go:220 worker: exited "authenticationworker": adding current Juju keys to ssh authorised keys: generating key fingerprint: invalid authorized_key"
<hazmat> my log keeps filling up with those
<hazmat> is there a reason why juju grabs all public keys it can find?
<mgz> not to me I'm afraid
<natefinch> hazmat: just in case? :)   I don't actually know.
<rogpeppe1> hazmat: axw__ is the one to talk to about those errors. i think i might know what's going on, but i have to stop for the day, sorry
<rogpeppe1> g'night all
<natefinch> night rog
<thumper> wallyworld: hey there, just letting you know I'm not working tody
<wallyworld> thumper: yeah, figured as much
<wallyworld> good sprint hopefully
<thumper> wallyworld: yeah pretty good
<thumper> wallyworld: oh fyi, I'm not working today (and axw_)
<wallyworld> thumper: for when you are back tomorrow, i have an upgrade frameworkin review
<thumper> awesome
<thumper> looking forward
<thumper> to it
<wallyworld> i'll add the first 1.18 plugin today
 * thumper signs off
#juju-dev 2014-02-11
<axw> wallyworld: do you want to take another look at https://codereview.appspot.com/59560043/ before I land?
<axw> I removed the things you and rogpeppe objected to
<wallyworld> ok, i trust you :-)
<axw> cool
<wallyworld> waigani: standup?
<waigani> yep
<waigani> I just had to put my laptop in the fridge! Ubuntu on macbook, woke from sleep by itself while in its cover. When I pulled it out, it was almost too hot to hold!
<wallyworld> axw_: sorry, wrong channel
<wallyworld> ok
<axw_> nps
<wallyworld> axw_: i should put PerformUpgrade in the new file too?
<axw_> wallyworld: that's not going to change over time is it?
<wallyworld> probs not, ok just the upgradeops then
<axw_> wallyworld: your 1.16 branch seems to include things other than dependencies.tsv
<axw_> not intentional, right?
<wallyworld> axw_: lbox fucked up
<wallyworld> it didn't choose the correct branch
<wallyworld> i just deleted the siteveld version and pushed manually
<axw_> ok
<wallyworld> https://code.launchpad.net/~wallyworld/juju-core/gwacl-231/+merge/205698
<axw_> ah I see
<axw_> ta
<wallyworld> i think that's all we need for 16.6
 * wallyworld soccer, be back later
<hazmat> axw_, ping.. looking at revno 2204 and trying to understand why juju is opening/reading all of a user's ssh keys
<axw_> hazmat: hey, just a moment, refreshing memory
<axw_> hazmat: all of the files in ~/.juju/ssh
<axw_> not in ~/.ssh
<axw_> ~/.juju/ssh contains an auto-generated key-pair for Windows/people without keys
<axw_> and you can dump whatever other key pairs you want Juju to try in there
<axw_> and then Juju will add "-i <identity>" for each valid private key in there to each invocation of ssh
<hazmat> axw_, ic.... i'm trying to track down where juju is reading all the ssh files in my ~/.ssh .. one of my keys is very old and i'm getting a looped failure in logs for authenticationworker
<hazmat> running juju get-env does indeed show a concat of all my pub keys as the default env setting
<hazmat> runner.go:220 worker: exited "authenticationworker": adding current Juju keys to ssh authorised keys: generating key fingerprint: invalid authorized_key"
<axw_> hazmat: ah right. authorized-keys defaults to the default public keys in ~/.ssh
<axw_> hazmat: in environs/config
<axw_> authkeys.go I think
<axw_> hazmat: do you have an SSH v1 public key?
<hazmat> could just be a bad format in one key, but that also implies non validation up front which leads to env failure during usage.. but more just  curious why the default to all, there's a list of known keys in the src.
<hazmat> axw_, it looks that way re v1.. dunno, the key is pretty ancient (10+ yrs)
<axw_> yeah it probably should validate earlier. sorry, not parsing the last sentence. what do you mean defaulting to all?
<axw_> it will pick up ~/.ssh/id_rsa.pub, ~/.ssh/id_dsa.pub, ~/.ssh/identity.pub
<hazmat> axw_, yeah.. that's probably it.. 5 keys total in the env
<hazmat> 2 sys keys, plus the probes on the rest.. previous behavior with the list was just to use the first one that was found, it looks like its appending all of them here.
<axw_> yup
<axw_> has been like that as far as I remember, but I don't go back to pyjuju :)
<hazmat> fair enough, not many do, and the rest try to forget  :-)
<axw_> heh
<hazmat> so the corner case bug is basically to validate default key before setting value, else auth worker dies in a loop.
<hazmat> axw_, incidentally fwereade came up with a decent solution re initialization with manual provider client plugin, copy JUJU_HOME to temp,  bootstrap, copy jenv file back
<axw_> yes I think so. we should just ignore public keys that are invalid
<axw_> cool :)
<hazmat> by solution i mean workable hack :-)
<mwhudson> does anyone have a cute picture of the juju-core source import graph?
<axw_> waigani: ^^ did you manage to create one?
<waigani> axw_: no, it was deemed a distraction from bug hunting - so I abandoned it
<axw_> ah yeh
<axw_> ok
<waigani> but these are some of the d3 graphs that caught my eye:
<waigani> http://www.findtheconversation.com/concept-map, http://bl.ocks.org/robschmuecker/7880033, http://mbostock.github.io/d3/talk/20111116/bundle.html, http://bl.ocks.org/mbostock/4063550
<waigani_> I was looking into getting output from libraries like pprof and pythia that  I could pump into a d3, taking the about as inspiration/starting point
<waigani_> *above
<mwhudson> nm :)
<mwhudson> jamespage: https://code.google.com/p/go/issues/detail?id=7303 btw
<dimitern> wallyworld, +1 for shiteveld :)
<wallyworld> yeah :-)
<dimitern> rogpeppe1, mgz, wallyworld, natefinch, standup?
<mgz> dimitern: the apt-get flag is --target-release
<mgz> but how that works with non-release things like ppas I'm not actually sure
<mgz> and general priorities can be handled by apt/preferences and Pin-Priority
<natefinch> what's the question?  I think I missed it (have been struggling with getting ppas working in trusty since no one has released trusty-compatible ppas yet)
<dimitern> mgz, cheers
<dimitern> natefinch, the question is how to install our juju packages from the cloud pocket, without screwing up charms that need different versions of packages that happen to be in the cloud pocket (i.e. django)
<natefinch> dimitern: ahh, I see
<dimitern> jamespage, are you around?
<dimitern> jamespage, you've commented on bug 1240667 about pinning the cloud-archive pocket at a lower priority (400) than the main archive, what's the default priority otherwise?
<_mup_> Bug #1240667: Version of django in cloud-tools conflicts with horizon:grizzly <charms> <cloud-archive> <cts-cloud-review> <packaging> <regression> <ubuntu-cloud-archive:Confirmed> <juju-core:In Progress by dimitern> <https://launchpad.net/bugs/1240667>
<dimitern> jamespage, and also, having done that during cloudinit, what --target-release should we use in apt-get install to ensure we get cloud-archive packages? "precise-updates/cloud-tools" ?
<dimitern> smoser, perhaps you can help there? ^^
<jamespage> dimitern, reading
<jamespage> dimitern, default priority is normally 500 I think
<dimitern> jamespage, ah, ok
<dimitern> jamespage, and what --target-release should I give to apt-get ?
<jamespage> dimitern, just checking that now
<jamespage> looking that the Release file I think its:
<jamespage> Codename: precise-updates/havana
<jamespage> dimitern, ^^
<jamespage> well not that one
<dimitern> jamespage, precise-updates/cloud-tools perhaps?
<jamespage> checking again
<jamespage> dimitern, precise-updates/cloud-tools looks right
<dimitern> jamespage, and what if it's not precise, but something else?
<jamespage> dimitern, well for at least the next 9 months its always precise
<jamespage> cloud-tools does not support any other ubuntu series
<dimitern> jamespage, ah, I see
<dimitern> jamespage, thanks!
<jamespage> np
<teknico> hi all, will someone please review this and address jamespage's concerns? thanks! https://code.launchpad.net/~teknico/charms/precise/keystone/add-valid-service/+merge/205171
<rogpeppe1> dimitern:  just checking, because i sent it with my non-canonical email, but i haven't seen a bounce, and i see it in the archives, have you seen my latest post to juju-dev (starting "I think that the best way to see how they look in real code") ?
<mgz> well, that was a fun power cut
<rogpeppe1> power cuts are always fun
<dimitern> rogpeppe1, let me check
<dimitern> rogpeppe1, yep
<rogpeppe1> dimitern: ok, cool. i guess someone must have subscribed me at my gmail address
<sinzui> abentley, rogpeppe1 Can I trouble both of you to join a hangout to discuss releasing 1.16.6
<rogpeppe1> sinzui: sure
<abentley> sinzui: certainly.
<sinzui> abentley, rogpeppe1 https://plus.google.com/hangouts/_/76cpidk53plj3t5324gml118j0?hl=en
<mattyw> rogpeppe1, could you give me a shout when you're done in the hangout - I have a small favour to ask
<mgz> sinzui: one think I'll note, is there have been requests to backport the network fix if we don't get a 1.18 out in like, the next week or so
<mgz> (we really should)
<dimitern> rogpeppe1, natefinch, mgz, a small review that fixes bug 1240667 ? https://codereview.appspot.com/61410051
<_mup_> Bug #1240667: Version of django in cloud-tools conflicts with horizon:grizzly <charms> <cloud-archive> <cts-cloud-review> <packaging> <regression> <ubuntu-cloud-archive:Invalid> <juju-core:In Progress by dimitern> <https://launchpad.net/bugs/1240667>
<mgz> dimitern: On It
<dimitern> mgz, cheers!
<mgz> description sounds right on
<rogpeppe1> dimitern: looking
<mgz> dimitern: reviewed, lets poke smoser to check it as well.
<dimitern> mgz, thanks
<dimitern> rogpeppe1, ^^
<dimitern> smoser or jamespage - can you take a look at this fix for the cloud-tools bug? https://codereview.appspot.com/61410051
<smoser> mgz, i agree on the dodgy ness.
<smoser> :-(
<smoser> i'm actually surprised that would work.
<smoser> cause as i read it you're sending one argument that is:
<smoser>  --target-release 'precise/cloud-tools' <package>
<smoser> which i would have thought apt would balk at
<smoser> https://codereview.appspot.com/61410051/diff/1/cloudinit/options.go looks sane
<mgz> any other cunning ideas scott?
<smoser> am i right in reading that ?
<smoser> essentially you're doing: 'apt-get' 'install' ... "--taget-release 'precise/cloud-tools' 'mongodb'"
<smoser> ?
<smoser> or something to that effect?
<smoser> so 2 thoughts
<mgz> something like that, the yaml quoting rules makes it all very fun to parse
<smoser> but cloud-init should do the right thing and get that all passed "correctly" to apt
<smoser> ie, not passing it through 'sh'
<smoser> hm..
<smoser> oh well.
<smoser> so 2 thoughts
<mgz> dimitern: in your ec2 test, did you look at the apt logs?
<smoser> a.) we could separate juju into its own cloud-archive.  i don't really like this, and its a lot of work, but then that archive wouldnt have the other packages that were screwing things up (the ones that maas has brought in).
<smoser> that may or may not fix things.
<rogpeppe1> dimitern: reviewed
<smoser> b.) you could just add the archive andinstall something from it later (not through cloud-init).
<smoser> ie, charms install stuff all the time, and could handle that outside cloud-init.
<mgz> we could probbly do the mongo install as a seperate run_cmd
<mgz> but that has plusses and minuses as well
<mgz> we'd need to re-add all the nice extra args to deal with unattended apt, and it's at a later stage in the boot
<dimitern> rogpeppe1, ta!
<dimitern> mgz, not apt logs, just cloud-init-output log
<dimitern> and everything worked nicely
<dimitern> smoser, what I changed is instead of apt-get [numerous options] install 'package', for the packages with --target-release it generates the same apt-get [opts] install --target-release 'precise-updates/cloud-tools' 'package'
<smoser> mgz, well, you would have to do that (the extra args), i agree.
<smoser> thats less than ideal, but it is something that really doesn't change.
<smoser> another thing you'd not get "for free" is eatmydata usage by cloud-init.
 * rogpeppe1 is done
<rogpeppe1> g'night all
<natefinch> night rog
<thumper> o/ waigani wallyworld_
<wallyworld_> thumper: hi
<wallyworld_> lots of emails to get through i assume
<thumper> wallyworld_: I have a doctors appt shortly, but will be back later
<wallyworld_> ok
<thumper> wallyworld_: quite a bit, but currently going through the upgrade doc
<wallyworld_> talk then
<wallyworld_> ah yes
<thumper> just trying to address a few comments
<wallyworld_> we can discuss when you get back
 * thumper nods
 * thumper tries to calculate time to the dr's office
<sinzui> wallyworld_, thumper do either of you have a moment to review a branch? https://codereview.appspot.com/61980043
<thumper> yep
<thumper> done
<wallyworld_> sinzui: all good for 16.6 then i assume?
<sinzui> wallyworld_, yes, thank you very much!
<wallyworld_> great :-)
<sinzui> wallyworld_, I have released. I am waiting for Ubuntu packaging and backporting. That might be 12 hours away
<wallyworld_> ok
<wallyworld_> thumper: did you want a catchup before the standup? to align on upgrades etc
<thumper> wallyworld_: yes, we also have our normal weekly call
<wallyworld_> that's tomorrow
<wallyworld_> but we can hangout now
<thumper> crap, so it is
 * thumper is eating
<wallyworld_> ok
<thumper> how about in a while?
<thumper> but yes
<thumper> do want to chat
<wallyworld_> sure, i'll wait with baited breath
<wallyworld_> sinzui: are the compatibility bugs you refer to in your email the 2 azure bugs listed on 1.17.3 milestones?
<wallyworld_> are there any others?
<sinzui> there are still many listed on https://launchpad.net/juju-core/+milestone/1.18.0
<wallyworld_> ah yes :-(
<wallyworld_> i'd personally like to see these all fixed asap so we have the option of releasing a 1.18 when needed
<sinzui> I will create a compatibility tag. oh, each is really a regression. I will track these as regressions
<wallyworld_> in an ideal world regressions would be critical
<wallyworld_> the opportunity cost of not being able to release 1.18 when needed (eg when the havana stuff lands) is large
<thumper> surely bug 1262175 isn't a bug as it is stated
<_mup_> Bug #1262175: debate drop --upload-tools flag <upload-tools> <juju-core:Triaged> <https://launchpad.net/bugs/1262175>
<thumper> debate something?
<thumper> geez
 * thumper goes to make a coffee prior to wallyworld_ cat
<thumper> chat
<wallyworld_> thumper: i like white with none
#juju-dev 2014-02-12
<thumper> wallyworld_: https://plus.google.com/hangouts/_/76cpj15en6ms7kb8jr9r3fvhco?hl=en
<axw> eh wtf
<axw> I had a dupe of the standup in my calendar and deleted one, now calendar says I'm not coming to the other one
<davecheney> axw: https://codereview.appspot.com/61560045/
<axw> davecheney: about to go to standup, will look a bit later
<davecheney> ta
 * axw wonders if he can justify going to gophercon as well
<axw> thumper: https://codereview.appspot.com/49640050/
<thumper> axw: canonical has 10 entrances due to sponsorship
<thumper> axw: could always see if you could acquire one of those
<axw> ooer
<axw> who do I ask?
<thumper> axw: um... not sure actually
<thumper> axw: mramm to start I guess
<axw> ok
<thumper> ah bugger
<thumper> package review
 * thumper kicks it again
<thumper> perhaps one day soon again
<thumper> although I think it is important, especially with waigani needing to learn stuff
<thumper> we should definitely get back into it
<thumper> however today, I have to take a daughter to the physio
<thumper> WTF?
<thumper> bootstrapping local provider fails with trunk
<thumper> and it didn't delete the .jenv
<thumper> and destroy environment failed
<thumper> as did with --force
<axw> thumper: figure out what's breaking? I'm just testing a fix for azure, I can look after that
<davecheney> axw: thanks for the review
<axw> davecheney: nps
<axw> wallyworld_: a real quick one please, fixes at least one of the critical azure bugs. https://codereview.appspot.com/51300044/
<wallyworld_> sure
<wallyworld_> axw: oh shit that looks like my fault
<axw> yeah, it's easy to do.. the defaults stuff is pretty confusing IMO
<wallyworld_> the whole config stuff is confusing
<thumper> axw: yeah, it was my code in cloudinit causing it to break
<thumper> but it should have been able to remove it, but it didn't
<axw> mk
<davecheney> axw: doesn't look like the bot is running
<axw> hm yeah mine hasn't landed either. I don't have access
<axw> thumper: can you please poke the bot?
<axw> wallyworld_: hey, can you please poke the bot?
<wallyworld_> sure
<axw> once it's moved, I'll see if I can get poking privileges...
<wallyworld_> yeah, will be different infrastructure
<rogpeppe1> mornin' all
<axw> dimitern: heya. just saw your comment. I don't understand how the preferences file gets picked up by apt-get? runcmds run after apt-get installs packages?
<axw> morning rogpeppe1
<rogpeppe1> axw: hiya
<dimitern> morning all
<dimitern> axw, in sshinit I made it so that it gets called immediately after add-apt-repo
<axw> dimitern: yep that bit works, but sshinit is only used for bootstrap
<axw> (and add-machine ssh)
<dimitern> axw, so both add-machine and bootstrap manual will work, don't you agree?
<axw> dimitern: I don't, because they're doing things at different times. For add-machine, cloud-init runs apt-get update, apt-get upgrade, apt-get install XXX, then finally it'll write the preferences file
<axw> so I can't see how the pinning takes effect for non-bootstrap machines
<dimitern> axw, can you point me to the code you're referring to that executes runcmd after any packages were installed?
<axw> dimitern: it's in cloud-init itself. I'll have a rummage in my downloads..
<dimitern> axw, so, looking at cloudinit/sshinit/configure.go - we have addPackageCommands very early, before the runcmds are executed
<axw> dimitern: yes, this is meant to mimic cloud-init
<dimitern> axw, and in case we have an apt source with prefs, we do add-apt-repository, and then immediately it installs the prefs file
<dimitern> axw, (in addPackageCommands)
<axw> yes I get that - just ignore sshinit
<axw> it is not used for add-machine
<axw> bootstrap is fine
<dimitern> axw, ok, so going back to environs/cloudinit/ then?
<axw> yes
<axw> and what happens when you provision a non-bootstrap machine
<dimitern> axw, in ConfigureJuju we have several AddPackage commands before getting to MaybeAddCloudArchiveCloudTools
<dimitern> axw, but that's fine, because none of these packages are affected by the bug - they're in main, not in cloud-tools
<dimitern> axw, the only problematic package is mongodb-server
<axw> dimitern: ok. if we don't care if we get other things from cloud-tools that's fine
<dimitern> axw, yep, sorry if i wasn't clear
<axw> no worries
<dimitern> axw, only mongodb-server and only on precise needs to be installed from cloud-tools pocket
<axw> dimitern: if you don't mind I will move it up into environs/cloudinit though, as a bootcmd
<axw> when I have nothing better to do :)
<dimitern> axw, i don't mind at all, but please live test it ;)
<axw> yes definitely
<dimitern> axw, now there's a slight imperfection (two actually) - the prefs file is created twice
<axw> how's that?
<dimitern> axw, due to the addfile call - both after adding the repo and when all the rest runcmds are run, but the contents are the same
<axw> ah right
<dimitern> axw, and the second issue is the duplication of logic in sshinit, but adding a boot cmd should fix both
<dimitern> mgz, hey
<axw> rogpeppe: did you get anywhere with reporting bootstrap errors back to the user?
<axw> or if you've shelved it, is there something I can pick up?
<rogpeppe> axw: no, i didn't
<dimitern> axw, i had some issues trying out manual bootstrapping on an existing saucy VM
<rogpeppe> axw: i had an idea as to how i might do it, but the sprint got in the way and then i haven't got back to it, i'm afraid
<axw> rogpeppe: nps
<axw> thanks
<axw> dimitern: what's issues?
<axw> what*
<dimitern> axw, it seems it tries to use ubuntu@ even if I set bootstrap-user to something else; and doesn't get very far
<axw> dimitern: it will first try to use ubuntu@ tosee if it has already set up the ubuntu user. it *should* then use bootstrap-user to initialise the ubuntu user
 * axw checks that this works on his machine still
<dimitern> axw, I had to actually create an ubuntu user and authorize my ssh key so i can login passwordless, but it still insisted on asking for password in sudo
<dimitern> axw, although, it might be all moot, because some time down the road i realized i was using sudo juju bootstrap, and that was getting /usr/bin/juju, i.e. 1.16.5 from the ppa
<axw> hrm, seems it's broken
<axw> you shouldn't be using sudo for manual
<dimitern> but once i started using trunk it went fine, except for one small thing
<dimitern> yeah, i know - i was just lazy and relying on bash history :)
<axw> ok
<dimitern> the small thing is I get "storage-auth-key" expected string, got "" after I did destroy-environment, and then status
<axw> hrm
<dimitern> let me try again
<axw> sounds like prepare failed
<axw> dimitern: it is broken on trunk tho
<dimitern> axw, what is?
<axw> dimitern: I started getting rid of BootstrapStorager, and broke it in the process. will see if I can fix it now
<dimitern> axw, ah, ok
<axw> initialising the ubuntu user
<axw> dimitern: in the mean time, if you enable passwordless sudo for unbuntu, you should be good to go
<dimitern> axw, yep, that's how I finally made it
<dimitern> axw, is it normal to get "manual:" instance names in a manual env? when I used add-machine the instance name was "manual:<IP>"
<axw> dimitern: just for the bootstrap node
<dimitern> axw, but since you can't start more instances..
<dimitern> axw, i successfully deployed stuff on 0, but deploying without --to gets me phantom machines and some errors later on in status
<axw> dimitern: yeah, I've got a branch up for review that disallows add-machine (except ssh:...)
<axw> the "Wire up prechecker" one
<axw> it's back from the dead
<dimitern> axw, perhaps any commands that could result in an environs.StartInstance call should be disallowed
<axw> dimitern: yes, that's what will happen
<dimitern> axw, sweet!
<axw> dimitern: also, you won't be allowed to create contains on providers that don't support it
<axw> containers*
<dimitern> axw, ah! that reminds me - i've encountered an issue while live testing in ec2 yesterday - the lxc provisioner kept dying because lxc is not supported
 * dimitern should make a habit of saving odd errors and stuff like that for easier reporting later
<axw> had you tried adding a container?
<dimitern> nope
<dimitern> it's no use - nothing can access it yet
<axw> yeah, just wondering why it would be doing that
<dimitern> i did in previous tests, they deploy ok, but can't relate to each other
<dimitern> mgz, so i can see bug 1241674 you fixed is released in 1.17.1, and bug 1188126 is still in progress?
<_mup_> Bug #1241674: juju-core broken with OpenStack Havana for tenants with multiple networks <cts-cloud-review> <openstack-provider> <juju-core:Fix Released by gz> <https://launchpad.net/bugs/1241674>
<_mup_> Bug #1188126: Juju unable to interact consistently with an openstack deployment where tenant has multiple networks configured <canonistack> <cts-cloud-review> <openstack-provider> <serverstack> <pyjuju:Triaged> <juju-core:Triaged by gz> <https://launchpad.net/bugs/1188126>
<dimitern> adeuring, hey, are you working on bug 1276462 ?
<_mup_> Bug #1276462: add a JUJU_TESTING environment variable for stats=0 on charm store interactions <juju-core:In Progress by adeuring> <https://launchpad.net/bugs/1276462>
<adeuring> dimitern: yes
<dimitern> adeuring, but there's no MP yet?
<adeuring> dimitern: not yet ready -- i'm still learning the code base, so I#m not that fast
<dimitern> adeuring, ok, just checking, thanks
<dimitern> mgz, standup?
<dimitern> niemeyer, thanks for replying - i understand you've been busy lately, didn't mean to bug you unnecessarily :)
<niemeyer> dimitern: Heya
<dimitern> niemeyer, welcome back!
<niemeyer> dimitern: Thanks.. sorry for taking longer than I wish
<dimitern> niemeyer, no problem
<sinzui> jamespage, maybe I was confused about packaging for the 1.16.6 release. Since trusty is leaping to 1.17.x, should I release 1.16.6 though the stable ppa only?
<jamespage> sinzui, yes
<jamespage> sounds good to me
<sinzui> thank you jamespage
<jamespage> sinzui, I started work on the .5 SRU for saucy last week - I'll hold off until .6 is done as well
<sinzui> understood
<niemeyer> dimitern: ping
<dimitern> niemeyer, hey
<niemeyer> dimitern: Heya
<niemeyer> dimitern: We have a small inconsistency being introduced which would be nice to brainstorm on
<niemeyer> dimitern: Nowdays we have ec2.RunInstances
<niemeyer> Nowadays
<niemeyer> dimitern: This type is used as an options structure when calling EC2.RunInstances
<dimitern> niemeyer, yes?
<niemeyer> dimitern: The network support is now adding NetworkInterfaceOptions, and NetworkInterfaceSpec
<niemeyer> dimitern: Which is not quite great
<dimitern> niemeyer, yeah, it was bugging me a bit
<niemeyer> dimitern: They're both very specific to a given context
<niemeyer> dimitern: although their names say nothing about that context
<dimitern> niemeyer, they are
<niemeyer> dimitern: What will we have next? NetworkInterfaceStuff? :)
<dimitern> niemeyer, i'm open to suggestions on naming :)
<niemeyer> dimitern: Following the lead of RunInstances, NetworkInterfaceOptions should probably be called CreateNetworkInterface
<dimitern> niemeyer, ok and NetworkInterfaceSpec - NetworkInterfaceOptions?
<niemeyer> dimitern: What's the difference between the two?
<niemeyer> dimitern: In terms of data
<dimitern> niemeyer, just a sec
<dimitern> niemeyer, so the *Spec is used only in RunInstances, because it can specify either a new or an existing NIC (Id empty or not)
<niemeyer> dimitern: In terms of data
<niemeyer> dimitern: It looks like they are exactly the same, except for two fields.. and one of these fields runs every other field irrelevant
<dimitern> niemeyer, in RunInstances you can specify more things (and different ones) than in CreateNIC
<dimitern> niemeyer, DeviceIndex and DeleteOnTermination do not apply for CreateNIC
<dimitern> niemeyer, and security groups are specified only by id, not name or id
<niemeyer> dimitern: Right.. what is device index about?
<dimitern> niemeyer, where to "mount" the NIC
<dimitern> niemeyer, eth0, 1, ..
<niemeyer> dimitern: I'm tempted to suggest RunNetworkInterface
<dimitern> niemeyer, sgtm
<niemeyer> dimitern: It's not great, but I cannot come up with anything nice that would fit in a tweet :)
<dimitern> niemeyer, indeed :)
<dimitern> niemeyer, so i'll s/NetworkInterfaceOptions/CreateNetworkInterface/ and in the next branch s/NetworkInterfaceSpec/RunNetworkInterface/
<niemeyer> dimitern: Thanks
<dimitern> mgz, ping
<dimitern> niemeyer, I've just noticed in https://codereview.appspot.com/54570048/ there are similar *Status constants - do you want them removed like in the vpc prereq?
<dimitern> niemeyer, I can do it in the RunInstances CL, because I've just submitted the NICs one
<axw__> sinzui: not sure if this classifies as critical or not, but manual provider is buggered on trunk -- https://bugs.launchpad.net/juju-core/+bug/1279259
<_mup_> Bug #1279259: manual: bootstrap fails if ubuntu user is not initialised <manual-provider> <juju-core:Triaged by axwalk> <https://launchpad.net/bugs/1279259>
<axw__> I'm working on it now, but haven't marked it against 1.17.3 in case you want to release without the fix
<dimitern> natefinch, are you around for a review of https://codereview.appspot.com/60620043/ ?
<sinzui> axw__, I think it is critical. I think we are two weeks away from having a manual provisioning env that is tested with every revision merged
<axw__> sinzui: ok, will try to get it fixed tomorrow. thanks
<dimitern> niemeyer, ..or you think it's ok to leave them as they are?
<natefinch> dimitern: yeah
<dimitern> natefinch, ta!
<mattyw> rogpeppe, afternoon - do you have a moment?
<rogpeppe> mattyw: hiya
<rogpeppe> mattyw: yeah, i do
<niemeyer> dimitern: Hmm
<dimitern> natefinch, review poke
<niemeyer> dimitern: INdeed, it's the same issue
<niemeyer> dimitern: and we can already see the mentioned issue surfacing
<dimitern> niemeyer, ok then, I'll remove the constants before I submit the next CL
<niemeyer> dimitern: ec2.AvailableState, and ec2.AvailableStatus
<dimitern> niemeyer, AvailableState is gone now
<niemeyer> dimitern: Right, I mean that the motivation I provided to not do that is real
<niemeyer> dimitern: Either we put context in their name, or we drop them.. I suggest dropping until we have a better idea of how/when to use them
<dimitern> niemeyer, noted, will drop them
<dimitern> niemeyer, and apart from that only one CL left - yay! :)
<rogpeppe> dimitern: can you tell me something about the intended use of juju.apiState.cachedInfo ?
<dimitern> rogpeppe, that's where the api info creds are cached for the CLI
<rogpeppe> dimitern: ah, i see where it's initialised now
<rogpeppe> dimitern: it seems a weird place to stash that
<rogpeppe> dimitern: apiState is supposed to be an ultra-thin wrapper around state
<rogpeppe> dimitern: not a place to store arbitrary runtime context
<dimitern> rogpeppe, if that was the intent, it wasn't well documented :)
<rogpeppe> dimitern: sorry, i thought this comment was reasonably clear.
<rogpeppe> // apiState wraps an api.State, redefining its Close method
<rogpeppe> // so we can abuse it for testing purposes.
<dimitern> rogpeppe, also, you're the reviewer on this change btw ;) r2209
<rogpeppe> dimitern: i'm sure we need something like this - i was just a bit surprised :-)
<rogpeppe> dimitern: memory shmemory :-)
<dimitern> rogpeppe, hehe
<natefinch> dimitern: sorry, got sidetracked by the kids for a bit.  Review is pretty much done
<dimitern> natefinch, thanks!
<dimitern> niemeyer, thanks for all the reviews!
<niemeyer> dimitern: np, thanks for pushing these change
<niemeyer> s
<dimitern> niemeyer, there might be more to come, but these should suffice for now
<dimitern> g'night all!
<rogpeppe> natefinch: largest CL ever? https://codereview.appspot.com/62230043 :-)
<hatch> do people use the GUI with maas?
<marcoceppi> hatch: I do/have
<hatch> marcoceppi thanks :)
<natefinch> rogpeppe: lol, nice
<marcoceppi> natefinch: is juju ipv6 safe?
<natefinch> marcoceppi: I believe so, but I don't know that I've actually tried it.  I know there's code for IPv6 in there, though.,
<rogpeppe1> marcoceppi: i think it's somewhat unlikely
<rogpeppe1> marcoceppi: for example, i think we often assume we can make a valid host/port combo by simply appending ":port"
<marcoceppi> rogpeppe1: you mean within charms, or within the juju core?
<rogpeppe1> marcoceppi: the latter
<rogpeppe1> marcoceppi: it *might* be ok, but it hasn't been verified
<marcoceppi> ah, yeah, it'd need to be encapsulated within []
<rogpeppe1> marcoceppi: yup
<natefinch> marcoceppi: I certainly wouldn't count on it without some heavy testing.
<marcoceppi> thanks
<thumper> o/ marcoceppi
<marcoceppi> thumper: \o/
<thumper> marcoceppi: if juju isn't ipv6 safe we damn well ought to make it so
<thumper> I'd like charms to be able to ask for an ipv6 address
<thumper> hey marcoceppi, are you wanting my incredibly hacked up github webhook charm?
<thumper> natefinch: are you currently working on any of the 1.17.3 or 1.18.0 bugs?
<natefinch> thumper: I just started looking into the mongo location bug, but haven't gotten far with it
<thumper> ok
<rick_h_> thumper: hey, got a sec? I hear you're the guy to talk to about getting multiple local envs working in lxc land?
<thumper> rick_h_: yes
<rick_h_> thumper: I hear there's 3ish tricks to make it work?
<thumper> rick_h_: it works
<rick_h_> thumper: in trunk? in 1.17.3 I get an error on the mongo port not being available
<rick_h_> errr 1.17.2
<thumper> rick_h_: you just need to make sure that you have different ports for mongo, api, storage
<rick_h_> ok, yea I've got different ports for the api/storage but didn't know what key to use for mongod
<rick_h_> I didn't see any docs around it for the env.yaml
<thumper> rick_h_: here is my config for a local that will run with a default local. http://pastebin.ubuntu.com/6922215/
<rick_h_> thumper: thanks, looking
<rick_h_> ah, state-port I don't have
<rick_h_> thanks thumper, I'll try that out.
<natefinch> I think I could save myself a lot of frustration if I just did  ln -s /usr /user
<natefinch> I love it when comments just outright lie.
<natefinch> / This is a variable only to support unit testing.
<natefinch> var mongodPath = "/usr/bin/mongod"
<natefinch> (is then used in production code)
<marcoceppi> thumper: yes please, I heard I should know more about it
<thumper> marcoceppi: ok, will send, but you have to realize it is demo-ware :-)
<marcoceppi> that's fine!
<natefinch> thumper: where does the new mongod live in trusty?
<sinzui> natefinch, It was true when the test was written :) Well I assume test-driven development...otherwise it is a malicious lie
<thumper> natefinch: *shrug*
<thumper> natefinch: do you mean the juju-db package one?
<natefinch> thumper: yeah
<thumper> natefinch: that is somewhere special
<thumper> probably need to look in the package itself
<thumper> I do know that it isn't in th path
<natefinch> sinzui: heh, yeah.  I assume someone put it there for a test,and then someone else came along, needed a path for mongo, and said "hey, there's one already defined" and used it.
<sinzui> natefinch, I had the path, and getting it again
 * sinzui keeps switching between version of juju and deps
<sinzui> natefinch, /usr/lib/juju/bin/mongod
<natefinch> sinzui: thanks
<sinzui> natefinch, this is all that juju-mongodb added to /usr/lib/juju
<sinzui> http://pastebin.ubuntu.com/6922408/
<davecheney> can the bot owner please update distinfo on that bot host
<davecheney> I can't land my change because the os runnong on that machine doesn't know about trusty
<davecheney> thumper: pong
<thumper> davecheney: did I ping you?
<davecheney> thumper: do you have access to the bot ?
<thumper> davecheney: yeah...
<thumper> what do you need?
<davecheney> can you do a `apt-get update && apt-get install distro-info`
<davecheney> so that the bot knows about trusty
 * thumper goes to try
<davecheney> thank you
<thumper> davecheney: it says it is already at the latest revision
<thumper> davecheney: however that doesn't list trusty
<thumper> davecheney: how do we update the source for it?
<davecheney> oh dear
<davecheney> thumper: shoulnd't need to
<davecheney> we publish distro-info's for all supported releases
<davecheney> is the bot running quantal ?
<thumper> --devel still doesn't list it
<thumper> bot is running precise
<thumper> lists up to saucy
<thumper> so...
<thumper> something there is all fubared
<davecheney> try --all
<thumper> did
<thumper> no trusty
<davecheney> maybe juju shouldn't depend on this pacakge
<thumper> heh
<davecheney> this isn't the first time it's let us down
<thumper> blame someone, anyone else
<thumper> can't be our fault
<davecheney> we had the same bullshit in August when Saucy came out
<wallyworld> sinzui: hey. is bug # 1247175 really a block for 1.18? can't we just use the release notes to tell people to update any scripts rather than having to develop/test code which will be removed next release?
<_mup_> Bug #1247175: juju sync-tools does not support --destination <ci> <regression> <juju-core:Triaged> <https://launchpad.net/bugs/1247175>
<thumper> who updates this?
<thumper> wallyworld: hey
<wallyworld> o/
<thumper> wallyworld: I have a proposal that adds an upgrade script
<thumper> wallyworld: needs agent.Config in the upgrade context
<wallyworld> ok
<wallyworld> will add it
<thumper> my branch adds it
<thumper> :-)
<thumper> take a look
<wallyworld> rightio
<sinzui> wallyworld, How do we get people to read the release notes and update their scripts when apt-put it there
<davecheney> sinzui: put clues in the release notes
<davecheney> to install the package users must answer 5 questions drawn from the release notes
<davecheney> it's like copy protection in the 80's
<sinzui> wallyworld, I think the win users are the only one who know there are release notes because they are downloading the client from the milestone page
<wallyworld> sinzui: ok, i'll add the code to support --destination with a deprecation warning
<wallyworld> thumper: i'm seriously considering having each major.minor version have its own sub package under juju-core/upgrades
<wallyworld> otherwise that top level package will bloat
<thumper> wallyworld: I have no strong feelings either way
<thumper> +1 to avoiding bloat
<thumper> subpackage sounds fine
<thumper> wallyworld: this one is important because I fucked up: https://code.launchpad.net/~thumper/juju-core/fix-provider-query-in-machine-env-worker/+merge/205864
<wallyworld> ok, will look at that one too
<thumper> wallyworld: and this one is the one with the upgrade https://code.launchpad.net/~thumper/juju-core/juju-run-on-machine-with-no-units/+merge/206050
<wallyworld> yeah already found that one
 * thumper goes to file a bug for the fuckup
<sinzui> davecheney, we could have a dot-file for each juju version in the user HOME. when juju runs and doesn't find the dot-file, it shows the user the release notes and will not do anything unit the user agrees to save the file.
<davecheney> sinzui: like the thing that sudo does
<sinzui> \o/ home brew accepted juju 1.16.6. I can close the release log
<thumper> \o/
<wallyworld> thumper: i was imagining description would be short, able to be used in logging. look like i need to add a Name field
<thumper> wallyworld: yeah, ok
<thumper> wallyworld: I was wanting it to be nice and long and descriptive :-)
<wallyworld> not sure who would see it
<thumper> maybe it doesn't need to be there
<wallyworld> i'dd do it as a code comment
<thumper> and instead becomes a "docstring" on the function
<wallyworld> and keep the desc short
<thumper> I'm happy either way
<thumper> wan't sure what was needed
<thumper> since we are in a brave new world
<wallyworld> it's really for devs what you have done i think
<wallyworld> yeah
<thumper> I'm happy to change it
<wallyworld> so +1 to doc string :-)
<wallyworld> thanks :-)
<wallyworld> i'll update the Description attr doc string also
<thumper> kk
<wallyworld> so people know to keep it short
<thumper> yep
<wallyworld> thumper: i has upgradeOperation as a base struct for UpgradeStep implementations. if you want to introduce upgradeStep instead, which I think is fine, can you remove upgradeOperations?
<wallyworld> s/s//
<thumper> I assumed that you would have one soon, but I needed something for the branch
<thumper> happy to wait until you've landed something and update it
<thumper> or merge in as a dependency
<wallyworld> if yours is ready first, you can land it and i'll deal with it
<thumper> kk
<wallyworld> thumper: we are missing a test for the actual business logic
<wallyworld> that does the upgrade
<wallyworld> especially a test to ensure it is idempotent
<thumper> yeah...
<wallyworld> i think all upgrade steps should have explicit idempotent tests
<thumper> was wonderinga bout that
<thumper> I have problems though
<thumper> as I don't have an ubuntu user
<wallyworld> and we should reject when reviewing if they don't
<wallyworld> mock
<thumper> so how do we write a test for that
<thumper> hmm...
<wallyworld> don't hard code /home/ubuntu
<wallyworld> use the juju helper func
<wallyworld> to convert ~/ubuntu
<wallyworld> that way you can test with a fake /home/ubuntu
<thumper> hmm... o...k...
<thumper> will try to write something
<wallyworld> do you know the function i mean?
<thumper> no
<thumper> but I can grep :)
<wallyworld> it's in utils, let me check
<wallyworld> i think it's UserHomeDir
<wallyworld> but your test needs to have set up a fake home
<wallyworld> can't quite recall exactly without digging a bit
<thumper> kk
<wallyworld> MakeEmptyFakeHomeWithoutJuju
#juju-dev 2014-02-13
<thumper-lunch> wallyworld: can't use UserHomeDir because I don't have an 'ubuntu' user
 * thumper forgot to reset nick
 * thumper looks at how to mock differently
<wallyworld> you create a fake home dir, add the dir for unbuntu
<wallyworld> oh ok
<wallyworld> UserHomeDir won't work
<thumper> right
<thumper> nm, I'll think of something
<wallyworld> but NormaliseFile or something like that will
<wallyworld> i can't recall exactly
<thumper> nah
<thumper> normalise calls UserHomeDir
<thumper> wallyworld: may mock that out with an interface :-)
<thumper> the package call
<wallyworld> whatever works :-)
<wallyworld> thumper: why not replace /home/ubuntu with NormaliseFile("~/ubuntu")
<wallyworld> or something like that
<thumper> because that still looks for the ubuntu user
<wallyworld> no, the ~ will be replaced
<thumper> oh, you mean ~/../ubuntu
<wallyworld> by the fake home
<thumper> because that's awful
<wallyworld> why?
<thumper> it is also wrong
<thumper> we need it to be /home/ubuntu
<thumper> ~/ubuntu -> /root/ubuntu
<thumper> by the agent
<wallyworld> oh agent runs as different user
<thumper> yeah
<thumper> if it was the ubuntu user
<thumper> it would still be /home/ubuntu/ubuntu
<thumper> which is also wrong
<thumper> I think you mean ~
<wallyworld> sorry, i meant ~unbuntu
<thumper> but still wrong
<thumper> ~ubuntu looks for the ubuntu user
<thumper> I'm going to mock out that looking bit
<wallyworld> so why hard code /home/ubuntu - have a helper function and override in tests
<thumper> well, we have to mock out one of two things
<thumper> either the dir to use
<wallyworld> extend the ~ idea which we already handle
<thumper> of the thing that maps the dir
<wallyworld> the dir to use i reckon is better
<thumper> I was going to do the latter
<thumper> I have no strong preference
<wallyworld> cause we already have the concept of FakeHome, seems like a more natural fit to extend that
<wallyworld> to allow for a fake /home
<thumper> this will have nothing to do with the home
<wallyworld> i mean /home
<thumper> it'll just be a dir
<wallyworld> yes
<thumper> nah, that is getting too complicated
 * thumper sticks with easy
<wallyworld> i just dislike anything that can touch your real /home
<wallyworld> i think that's bad test imppementation
<wallyworld> what happens if a test is buggy and it deletes stuff
<thumper> we can continue this in the hangout :)
<wallyworld> think of stubbing out /home as like stubbing out the charm store url
<wallyworld> thumper: pull your finger out cause i need the new agent config stuff on context
 * wallyworld taps fingers impatiently
<thumper> yeah yeah
<_thumper_> wallyworld__: test created for the upgrade
<wallyworld__> \o/
<_thumper_> proposal being updated now
 * _thumper_ has to go make dinner
<wallyworld__> ok ta
<axw> gtg out for a while, seeing my brother off at the airport
<bradm> anyone got any suggestions on how to debug why a juju 1.17.2 environment will bootstrap, but not deploy an instance?
<bradm> as in, I'm trying to juju deploy a local charm and its just sitting there
<bradm> https://pastebin.canonical.com/104754/ <- been sitting there for a good minute or more
<thumper> axw: ack
<thumper> bradm: it could be downloading the lxc template
<bradm> thumper: this is on a juju deployed openstack using maas
<thumper> oh..
<thumper> maybe not then...
<bradm> thumper: as in, on openstack deployed using juju on top of maas
<thumper> sorry, not sure
<bradm> I just can't see anything going on
<bradm> thumper-afk: no worries
<bradm> nobody else has any suggestions for debugging why juju deploy is hanging?
<bradm> wallyworld__: ^^ ? :)
<wallyworld__> um
<wallyworld__> bradm: i've not deployed any local charms before, all i can think of is perhaps an issue uploading the charm to cloud storage
<bradm> best I can tell it doesn't matter where the charm comes from, it just hangs
<wallyworld__> it still has to copy the charm to cloud storage though
<bradm> hmm, I guess
<wallyworld__> maybe you can ssh into the machine and see if the charm has been unpacked
<bradm> it hasn't spawned a 2nd machine yet, I only have the bootstrap node up
<wallyworld__> what does juju debug-log say?
<bradm> oddly, not a real lot
<bradm> let me try all this again
<bradm> yeah, this is weird, its like too much network traffic and it drops
<bradm> doesn't seem like a juju thing if thats the case
<axw> wallyworld__: terse review, squashed my finger in the car door :\
<rogpeppe2> wallyworld: you just got a review of https://codereview.appspot.com/61510049/
<dimitern> wallyworld, meeting?
<dimitern> mgz, ^^
<mgz> dimitern: ta
<dimitern> mgz, if you can take some time to look, i've updated the networking document to include a preliminary list of needed changes to goose
<TheMue> dimitern: one short question. how do configuration values come into the environ config?
<dimitern> TheMue, what do you mean?
<dimitern> TheMue, from env.yaml ?
<dimitern> TheMue, or from CLI juju set/etc. ?
<TheMue> dimitern: when a system is bootstraped the environment has a config (EnvironConfig() *config.Config)
<TheMue> dimitern: somehow the initial values have to be written into it
<dimitern> TheMue, yes, so the env.yaml settings + some other things get validated and created at prepare time, then stored in the .jenv file
<TheMue> dimitern: and when does this jenv file gets into the database?
<dimitern> TheMue, and the actual *config.Config gets stored in mongo in the settings collection
<mgz> dimitern: sure, I'll have a look
<dimitern> mgz, ta
<TheMue> dimitern: hmm, still have to find the flow where this all happens. reason is that I need to write another value into this config
<dimitern> TheMue, take a look what happens in environs.Prepare
<dimitern> TheMue, ah, for that you just need to add it in environs/config's schema
<TheMue> dimitern: yip, detected that already, only the writing is missing. but the prepare hint is good. thx.
<dimitern> TheMue, and add some get methods, etc. look a recent CL of mine that does that: https://codereview.appspot.com/58170045/
<TheMue> dimitern: ah, nice, having somebody doing the same is very helpful
<dimitern> TheMue, np :)
<sinzui> abentley, jcsackett thedac, I am double booked through the morning
 * sinzui has announcements for the standup
<sinzui> too
<abentley> sinzui: I see.  Should we postpone the standup or go on without you?
<sinzui> abentley, might as well
<abentley> sinzui: what are those announcements?
<abentley> sinzui: I guess just email them to us.
<sinzui> abentley, yeah, that will be best
<rogpeppe2> fwereade, natefinch, wallyworld, dimitern, thumper: updated errgo names as discussed: http://paste.ubuntu.com/6925794/
<dimitern> rogpeppe2, looking
<rogpeppe2> natefinch: how does that feel to you?
<rogpeppe> dimitern: we're going with Cause instead of Diagnosis, and Underlying instead of Cause.
<rogpeppe> dimitern: and Mask instead of Wrap
<rogpeppe> dimitern: and Notef instead of Wrapf
<dimitern> rogpeppe, i'm +1 on all but last two - i liked wrap, what's wrong with it?
<rogpeppe> dimitern: i liked it too, but this is the way we decided to paint the shed :-)
<dimitern> rogpeppe, and how's mask/note better?
<rogpeppe> dimitern: the thought is that it's a good idea to make it clear that we're masking the underlying cause
<natefinch> rogpeppe: can you drop location from the public API?  It's not really necessary
<rogpeppe> natefinch: you mean, make it a private field in Err?
<rogpeppe> dimitern: and everyone seemed to like Note, so we went with that
<rogpeppe> dimitern: (better than Annotate anyway, i think)
<dimitern> rogpeppe, hmm..
<natefinch> rogpeppe: Yeah, so the way I did it was instead of Locationer I had Detailed (Detailer if you must)  and that way you don't dictate a specific set of info from a sub-error, you just call Details() on the sub error and it formats how it wishes
<dimitern> well, meh, it's just an api and it just needs getting used to
<rogpeppe> dimitern: yeah, that's my thought
<rogpeppe> dimitern: as long as the semantics are right, i'll get used to most names
<natefinch> rogpeppe: I'm just trying to narrow the public API so there's less to grok.  There's a ton of stuff to ingest in your public API
<dimitern> rogpeppe, yep
<rogpeppe> natefinch: yeah, the public interface that we'd like people to see most of the time looks like this: http://paste.ubuntu.com/6925836/
<rogpeppe> natefinch: it is useful to have each error responsible only for returning data and not for actually formatting things
<rogpeppe> natefinch: it means that we can potentially provide different views on the same data
<rogpeppe> natefinch: for example, a web interface might implement an alternative version of Details that formats the errors as html with source code links.
<natefinch> rogpeppe: that's true
<rogpeppe> natefinch: it is arguable, i suppose, whether Locationer, Wrapper and Causer should all be separate interfaces, but i think it could make sense to provide some and not others.
<natefinch> rogpeppe: yeah I think that's fine.  small interfaces are nice.
<rogpeppe> natefinch: Details should document how the interfaces are used though.
<natefinch> rogpeppe: it's honestly the func(error)bool stuff that really complicates the API.... which is unfortunate given that they're likely not to be used except in limited cases
<natefinch> rogpeppe: yep
<rogpeppe> natefinch: they're used a fair amount actually (about 10% of the time)
<natefinch> rogpeppe: what's the use for Any?  Isn't that the same as note?
<rogpeppe> natefinch: no, Note masks the cause
<rogpeppe> natefinch: Any allows any cause through
<natefinch> rogpeppe: cause is now what you used to call diagnosis, right?
<rogpeppe> natefinch: yes
<rogpeppe> natefinch: Notef is basically equivalent to fmt.Errorf except that it adds source line info
<natefinch> rogpeppe: how do you note and let the error type pass through?  Or is that only doable through mask(err, Any)?
<rogpeppe> natefinch: you can use NoteMask
<rogpeppe> natefinch: (which may well be better named MaskNote; i can't quite decide)
<rogpeppe> natefinch: NoteMask is actually the underlying wrap primitive, used by all the other wrapping functions except WithCausef
<natefinch> rogpeppe: I wish there was a function that didn't require the function argument that just always let the underlying error become the cause
<rogpeppe> natefinch: var mask = errors.MaskFunc(errors.Any)
<rogpeppe> natefinch: but, as i keep on asserting, that case is actually pretty rare
<natefinch> rogpeppe: yeah, should be
<rogpeppe> natefinch: because returned errors are part of *your* contract, and you should be responsible for knowing what they are
<natefinch> rogpeppe: right
<natefinch> rogpeppe: So mask(err) is effectively the same as just notef(err, "")
<rogpeppe> natefinch: yes
<rogpeppe> natefinch: those two are identical
<abentley> rogpeppe: The current unit test against amd-64-precise got some panics: http://162.213.35.54:8080/job/run-unit-tests-amd64-precise/66/console
<rogpeppe> abentley: looking
<rogpeppe> abentley: hmm, i haven't seen this before
<rogpeppe> ... Panic: unauthorized db:presence ns:presence.presence.beings lock type:0 client:127.0.0.1 (PC=0x414311)
<abentley> rogpeppe: Just telling you because you said you were interested in panics.
<abentley> rogpeppe: previous run did not panic this way (but also failed)
<rogpeppe> abentley: yes, thanks - that's very interesting to see
<rogpeppe> looks like the presence watcher panicked at some point, probably because of the permission changes going on the the db underneath
<rogpeppe> natefinch: one potential way of simplifying things a little is to accept only a single function argument rather than a slice.
<rogpeppe> natefinch: but then you'd always have to pass it, so the most common case becomes harder.
<rogpeppe> natefinch: (the most common case being "return mask(err)" of course)
<natefinch> rogpeppe: yeah.,.. I don't think that's a big deal, I think it's the fact that Note sounds like it doesn't mask the error, because it's obviously named differently than Mask...
<rogpeppe> natefinch: yeah, i quite liked Wrap and Wrapf. but i can accept that and move on, i think.
<natefinch> rogpeppe: Mask and Maskf?
<rogpeppe> natefinch: people said they particularly liked "Note". so Note we have.
<rogpeppe> natefinch: (as agreed)
<sinzui> fwereade, I think we can denominate https://bugs.launchpad.net/juju-core/+bug/1255242 . This change in behaviour is a problem, I am not convinced juju is a fault
<_mup_> Bug #1255242: HP cloud requires 4G to do what AWS does in 2G mem <ci> <hp-cloud> <intermittent-failure> <regression> <upgrade-juju> <juju-core:Triaged> <https://launchpad.net/bugs/1255242>
<natefinch> rogpeppe:  I guess if you start from the assumption that everything gets masked, except for things that pass a mask function, or when using WithCausef, that makes it easier to understand,
<rogpeppe> natefinch: yeah
<fwereade> sinzui, +1, although it would be nice if we can figure out what's at fault... something the image does differently?
<natefinch> rogpeppe: ok, enough bikeshedding for me.  I'm sure we'll get used to it, and if not, we can always find and replace the names if we think of something better.
<sinzui> fwereade, The image is my own suspicion. One day Hp will use our images
<rogpeppe> natefinch: thanks
<rogpeppe> ha, 9889 lines of diffs in 5 seconds. gofmt -r FTW! http://paste.ubuntu.com/6926047/
<natefinch> rogpeppe: nice
<natefinch> rogpeppe: gofmt is pretty awesome
<rogpeppe> natefinch: it would be nice to be able to do statements and declarations as well as expressions, but yeah, it's great
<natefinch> rogpeppe: yeah, I wish it could do more, too.  But for what it can do it's great
<sinzui> fwereade, mgz: are these bugs backportable? Can I tartget them to 1.16.7? https://bugs.launchpad.net/juju-core/+bug/1241674 and https://bugs.launchpad.net/juju/+bug/1188126
<_mup_> Bug #1241674: juju-core broken with OpenStack Havana for tenants with multiple networks <cts-cloud-review> <openstack-provider> <juju-core:Fix Released by gz> <https://launchpad.net/bugs/1241674>
<_mup_> Bug #1188126: Juju unable to interact consistently with an openstack deployment where tenant has multiple networks configured <canonistack> <cts-cloud-review> <openstack-provider> <serverstack> <pyjuju:Triaged> <juju-core:Triaged by gz> <https://launchpad.net/bugs/1188126>
<fwereade> sinzui, mgz is fuguring out if we should be hotfixing them for cts instead
<fwereade> sinzui, they involve a config change
<fwereade> sinzui, but we could handwave them to be "this config setting doesn't work properly in old 1.16s" I suppose
<fwereade> sinzui, so it's just a bugfix ;p
<mgz> sinzui: it's ugly, but possible
<sinzui> mgz, I am happy to not release 1.16.7
<mgz> I would much prefer we get an earlier 1.18
<rogpeppe> natefinch: any chance you're going to merge that voyeur branch some time?
<natefinch> rogpeppe: oh crap, sorry, yeah
<natefinch> rogpeppe: I added the tests you suggested, not sure if there's anything else that needed to be done: https://codereview.appspot.com/57700044
<rogpeppe> natefinch: i think it's good as is. one more test though: we never test what happens when NewValue is called with a non-nil arg
<rogpeppe> natefinch: with that in, LGTM
<natefinch> rogpeppe: cool
<natefinch> rogpeppe: will do that right now
<rogpeppe> natefinch: when you've submitted it, i'll be adding a patch that makes the zero Value ok to use, which i found useful elsewhere.
<natefinch> rogpeppe: nice
<natefinch> rogpeppe: actually there is a test for a non-nil arg, TestValueInitial, it's near the top of the file
<rogpeppe> natefinch: oh yes, i missed it
<rogpeppe> natefinch: LGTM then
<natefinch> rogpeppe: oh ok, I missed your new lgtm, thanks
<natefinch> rogpeppe: it's merging (in theory)
<rogpeppe> natefinch: cool
<TheMue> awsome, my new way of debug-log works even with the local provider via api w/o passing infos during the call
<natefinch> rogpeppe, mgz, fwereade: anyone know what the minimum version of mongo is that we support?
<TheMue> rogpeppe: have to do a bit cleanup, but I think you'll like it
<rogpeppe> TheMue: cool
<rogpeppe> natefinch: no i don't, sorry
<rogpeppe> TheMue: how did you end up doing it?
<TheMue> rogpeppe: I extended the environ config. default log location in there is the standard one, but the local provider sets the local one
<TheMue> rogpeppe: then I can do logLocation = state.EnvironConfig().LogLocation() (a bit more due to returned error of ErrorConfig)
<rogpeppe> TheMue: that seems like a reasonable solution, thanks
<TheMue> rogpeppe: the local provider already sets the location as /var/log/juju-<user>-<envname>/all-machines.log. but it forgets the value after creating the dirs
<rogpeppe> TheMue: you'll need to make sure that it's not a value that the user can set with set-environment
<TheMue> rogpeppe: yeah, it definitely feels better. also the UI needs only to pass lines and filter during the call. how shall the UI installed in a container know about the local user?
<rogpeppe> TheMue: yeah, it was definitely wrong to pass the log location as an arg to the API call
<TheMue> rogpeppe: full agree now
<rogpeppe> TheMue: putting the location in the env config feels a *little* bit like a hack, but i can't currently think of a better idea
<TheMue> rogpeppe: the ensuring of not overwriting it is done where?
<rogpeppe> TheMue: in EnvironProvider.ValidateConfig i think
<rogpeppe> TheMue: just Valid actually
<TheMue> rogpeppe: not in config.go immutableAttributes?
<rogpeppe> TheMue: ah, perhaps there. let me check.
<rogpeppe> TheMue: yes, that'll be the place
<TheMue> rogpeppe: fine, then I've got it right
<rogpeppe> mgz: ping
<rogpeppe> mgz: scratch that, i don't expect you to be around at this time of the evening :-)
<rogpeppe> a bzr question for anyone: i've got a load of commits with a merge from trunk in the middle them. what's the best way to undo the merge and pretend i never did it?
<rogpeppe> s/them/of them/
<natefinch> rogpeppe: make a new branch and cherry pick everything but that branch?  I don't know if there's a better way.  I'm not a bzr expert
<natefinch> s/branch/merge/
<rogpeppe> natefinch: yeah, i've done that, but it's not ideal
<rogpeppe> natefinch: i always feel that whenever i use patch(1) i've failed
<natefinch> rogpeppe: wow, I don't think I ever tried bzr help commands before... that is a friggin' huge UI
<rogpeppe> natefinch: it's minute compared to git...
<rogpeppe> natefinch: vcs's are like OS's before unix came along
<natefinch> rogpeppe: yeah, git looks even bigger.  Man.  I sorta miss SVN.
<hatch> whaaaaa??
 * hatch pinches
<hatch> natefinch you can probably rebase the merge out
<hatch> ohh bzr.....yeah no idea
<hatch> sorry :)
<natefinch> hatch: heh, yeah, same here :)
<thumper> natefinch: ping
<natefinch> thumper: howdy
 * thumper reboots
#juju-dev 2014-02-14
<wallyworld> thumper: shiteveld won't accept by latest diff for the rsyslog upgrader. can you take a peek in lp and see if you are happy? i made a small tweak and responded to comments
<thumper> ok, will look
<thumper> wallyworld: for your Replace file thing, why not use Stat to get the existing premission, and only use 0644 if you can't get it?
<wallyworld> thumper: cause we want the new perms to overwite any exisitng ones
<stokachu> hey, i sent an email to the mailing list but just throwing this here as well, anyone know the latest version of the websocket specification juju api server supports?
<thumper> wallyworld: but you aren't letting the user specify the permissions
<thumper> you are explicit in 0644
<thumper> which may not be right
<thumper> stokachu: I don't sorry
<wallyworld> oh shit, i should have that passed in
<thumper> wallyworld: if we want to overwrite perms, allow the caller to pass them in
<thumper> :)
<stokachu> how do i tell which version of the websocket library is used from go.net/websocket?
<wallyworld> that's what my brain was thinking but my fingers didn;t type that
<thumper> wallyworld: I get that all the time too
<wallyworld> stokachu: i'm not sure. rogpeppe is the best person to ask
<wallyworld> but he's past EOD now
<stokachu> ok
<wallyworld> i'll poke him later to make sure he responds
<stokachu> wallyworld: thanks a bunch
<wallyworld> np
<wallyworld> thumper: fixed
<thumper> kk
<thumper> axw: no os.Groups though ...
<thumper> also easier to mock out in the tests with the command :-)
<axw> thumper: there's Gid?
<thumper> but thanks for the pointer
<thumper> not on a os.User
<thumper> oh
<axw> yes there is
<thumper> so there is
<axw> :)
<axw> anyway, not a problem, just wanted to make sure you knew
<thumper> cheers
<thumper> os.User.Gid is a string and os.Chown needs an int
<thumper> lovely library coherency there
<thumper> axw: I'm happy with https://code.launchpad.net/~wallyworld/juju-core/rsyslogconf-upgrader-118/+merge/206090, you happy?
<wallyworld> yep, for this iteration
<axw> thumper: yeah I was gonna LGTM
<thumper> cool
<axw> FTR, +1 for a sub package for utils
<wallyworld> axw: i reverted to using TempDir cause then the file perms work put nicer - TempFile creates the file with 600 and you need more code to change the perms
<wallyworld> i think that's why it was done that way originally
<axw> ok no worries
<thumper> axw: got a minute?
<thumper> bugger
<thumper> completely missed the standup
<thumper> what a slacker
<thumper> oops, and sorry
<wallyworld> f*cking bot
 * wallyworld stabs it to death 
<axw> thumper: yes
<axw> what's up?
<thumper> axw: was wondering about bootstrapping prcess with maas
<thumper> and how the sync bootstrap handles the networking bits in it
<thumper> particulary how we currently restart networking
<axw> un moment, gotta refresh memory on maas
<thumper> I'm likely to change the "edit /etc/network/interfaces, restart networking"
<thumper> to be "ifdown eth0, edit /etc/network/interfaces, ifup br0"
<thumper> which I have been told will work, but I need to test it
<thumper> these are all different lines in the cloud init scripts section
<thumper> wondering how the sync bootstrap handles this...
<thumper> wondering idly if this relates to : bug 1233751
<_mup_> Bug #1233751: MAAS environment bootstrapped, but not really. <bootstrap> <destroy-environment> <jenv> <maas-provider> <theme-oil> <juju-core:Triaged> <https://launchpad.net/bugs/1233751>
<axw> thumper: I think cloud-init will run that bit. still trying to get my head around it...
<axw> if that's the case it should work no problems
<axw> thumper: yep, maas's StartInstance does that networking bit, so cloud-init will do the networking change
<axw> so it won't break the ssh connection
 * axw looks at the bug
<thumper> how do we handle the bootstrapping?
<thumper> axw: doesn't bootstrap call start instance?
<axw> thumper: I suspect that bug is just cos the bootstrap-state file got left behind on failed bootstrap
<axw> yes it does, but there's two parts to synchronous bootstrap
<axw> part 1: run cloud-init with a very basic cloud-config
<axw> for maas, there's an additional bit of modifying networking
<axw> part 2: wait for the machine to come up, ssh in and do the rest
<thumper> ok, cool, so the hack networking is all part 1?
<axw> and "do the rest" is provider-independent
<axw> yep
<thumper> axw: is the bug then fixed?
<axw> thumper: dunno sorry
<thumper> kk, so I'll manually test the ifdown/ifup story locally on my precise maching :)
<thumper> machine
<axw> doesn't look related to synchronous bootstrap
<axw> pre-bootstrap setup I think
<thumper> ok, but didn't you just fix a bug that deleted the .jenv if the bootstrap fails?
<axw> oh that's a different file
<axw> I'm talking about how we leave a file in cloud storage
<thumper> ah... :(
<axw> thumper: actually, I'm not sure now. you may get the same error for existing .jenv
<axw> I would need a NUC or something to test on ;)
<bigjools> curtis has one IIRC
<thumper> bigjools: can I test something on your maas?
<bigjools> maaaaaybe
<bigjools> it means I have to go and turn it on
<bigjools> thumper: it's on, can you get in?  I can't remember if my router config still works for you
<thumper> um...
<bigjools> since you're sshing into a network two NATs deep :)
<thumper> what was the ip address and port again?
 * bigjools rolls eyes
<thumper> bigjools: I have auth to go buy some NUCs for maas testing locally
<thumper> I just need to get my a into g and get some
<bigjools> thumper: expensed?
<thumper> aye
<bigjools> suhweet
<bigjools> how much in NZ?
<thumper> not sure
<thumper> have to go price some up
 * axw goes offline for a while to run tests without a network
<axw> wallyworld: FYI I have looked at your upgrader CL. It looks good, but I don't think I understand everything well enough to +1 at the moment
<wallyworld> axw: that's ok, it was meant for william to look at anyway :-)
<axw> ok, cool
<wallyworld> thanks for looking though
<axw> nps
<wallyworld> it achieves the same result as a previous version, but with a different approach
<axw> yup, so I see. I understand the idea and see how it works, just not fully aware of how the watcher stuff works for example
<wallyworld> it's a bit involved
<wallyworld> fwereade: no urgency, take 2 - https://codereview.appspot.com/63730043/
<wallyworld> the main tests i copied across from the other branch and made then pass with the new approach
<fwereade> wallyworld, nice, thanks
<fwereade> wallyworld, hey, I was wondering
<fwereade> wallyworld, using ssl-hostname-verification for metadata-needs-signing seems a little strange to me
<wallyworld> which bit of code?
<wallyworld> i'll look
<fwereade> wallyworld, err let me hunt again, I came upon something that looked like it was doing that while trying to figure out some of the joyent provider tests last night
<fwereade> wallyworld, if that doesn't ring a bell I probably just misunderstood it
<wallyworld> i can't recall offhand either
<wallyworld> gotta go for dinner, back later
<fwereade> wallyworld, ah it's ok I completely misunderstood it
<wallyworld> o :-)
<wallyworld> ok
<fwereade> wallyworld, it really is about verifying the hostnames
<fwereade> wallyworld, enjoy your dinner
<wallyworld> will do
<fwereade> I've got a trivial intermittent failure if anyone's got a moment: https://codereview.appspot.com/63710044
<fwereade> rogpeppe, 479-desired-peer-group appears to be LGTMed from a month ago but still unmerged
<rogpeppe> fwereade: oh twats
<rogpeppe> fwereade: it's always that problem when you approve something then switch context back to what you were doing, and forget to check that it's actually merged
<fwereade> mgz, can we land https://codereview.appspot.com/49050044/ ?
<fwereade> rogpeppe, yeah, I have a couple of those myself :/
<fwereade> TheMue, is 058-debug-log-api abandoned in favour of a different approach?
<fwereade> rogpeppe, also 487-remove-job-managestate
<rogpeppe> fwereade: oh, that's worse
<rogpeppe> fwereade: bugger
<rogpeppe> fwereade: looks like today is the day for bountiful conflicts
<fwereade> TheMue, I'm rejecting 058 and WIPing 060
 * fwereade wishes rogpeppe luck
<TheMue> fwereade: I'm currently testing the 060 live, it is the solution. Only coded testing is missing. But it works for all providers (even local) and with older releases (even here now local).
<TheMue> fwereade: The 060 contains both, the backend and the cmd changes.
<fwereade> TheMue, excellent, thanks
<rogpeppe> wallyworld: this is from a suggestion i made in a review - i didn't want to badger you about it, but i think it's worth doing: https://codereview.appspot.com/63530048
<wallyworld> rogpeppe: we prefer interfaces
<rogpeppe> wallyworld: why?
<wallyworld> all the usual reasons
<rogpeppe> wallyworld: when we've just got a bag of data, there is no reason to use an interface
<rogpeppe> wallyworld: it just obfuscates the code for no reason
<rogpeppe> fwereade: i'd appreciate your thoughts on this
<wallyworld> i'm tired tonight so may not be in the best frame of mind for a coherent discussion
<rogpeppe> wallyworld: i appreciate that interfaces are useful when you might want to mock different behaviour
<rogpeppe> wallyworld: but in this case there is no behaviour to mock - the data structure *is* the interface
<wallyworld> now yes
<wallyworld> bit the design is evolving
<wallyworld> but
<wallyworld> the same pattern has been used for agent conf
<rogpeppe> wallyworld: if we need extra behaviour, that will be easy enough to retro-fit. let's not overengineer in advance - this is not Java
<wallyworld> huh?
<rogpeppe> wallyworld: agent conf does actually have some behaviour behind it
<wallyworld> as will the upgrade stuff most likely
<rogpeppe> wallyworld: (it encapsulates the way to read different versions of the file)
<rogpeppe> wallyworld: i don't see that - this is a description of the upgrade steps - that's fundamentally data AFAICS. it's also held inside the binary, not in an external file
<wallyworld> it is data for sure. but the design is still evolving
<rogpeppe> wallyworld: sure, so evolve the data
<rogpeppe> wallyworld: having the extra layer of indirection doesn't help that (actually, it makes it harder)
<rogpeppe> wallyworld: "KISS" :-)
<wallyworld> sure. there's arguments either way
<rogpeppe> fwereade: can we please go the simpler route to start with?
<rogpeppe> fwereade: if you find that interfaces become useful here, i will eat my humble pie
<wallyworld> to me interfaces are simpler because they abstract behaviour and mocks can easily be constrcuted for only some of the methods
<wallyworld> and it's generally just plan good programming practice
<fwereade> rogpeppe, wallyworld: IMO our reliance on concrete types has fucked the codebase pretty hard
<wallyworld> our use of structs everywhere in juju core kinda sucks
<rogpeppe> fwereade: i don't think this case is analagous to that
<fwereade> rogpeppe, wallyworld: once you turn out to need an interface it's a *massive* hassle to fix the concrete types
<wallyworld> +1
<rogpeppe> fwereade: so do you really think we should never use structs? even when we're just holding bags of data?
<fwereade> rogpeppe, I want enough seams in the codebase to allow for easy testing of small units, without backing everything with real implementations
<wallyworld> bags of data now for some things, but the design is evolving
<wallyworld> +1
<rogpeppe> fwereade: there is no "implementation" here - it's just a description of what to do
<rogpeppe> fwereade: the "implementation" is in the Run functions which are already fully mockable
<rogpeppe> fwereade: i can't see what use it is to "mock" a function that just returns a description and does nothing more.
<fwereade> rogpeppe, I'm curious as to what you perceive the benefits of dropping the interface to be
<rogpeppe> fwereade: it 60 lines less code. i consider that a good reason in itself.
<rogpeppe> s/it/it's/
<wallyworld> rogpeppe: you are the one who likes lots of code :-)
<fwereade> rogpeppe, and I'm not so sure that we'll never see behaviour associated with things like Targets
<wallyworld> all those duplicated "contains" functions etc
<fwereade> rogpeppe, by pickinginterfaces from the get-go we can put extensions to behaviour in the right place when the time comes
<wallyworld> they gie us more flexibility to evolve a design
<wallyworld> give
<rogpeppe> fwereade: it is also much more immediately obvious what the code is doing - if i see a field access, i don't have to look at what some arbitrary code might be doing
<fwereade> rogpeppe, if we don't, then the "simple" approach becomes to tweak the code that uses those types
<fwereade> rogpeppe, and behaviour gets smeared out
<fwereade> rogpeppe, and things just get worse and worse
<fwereade> rogpeppe, because even if we *know* it's the time to switch to interfaces
<fwereade> rogpeppe, the hassle and cost of doing so is generally overwhelming
<fwereade> rogpeppe, you don;t have to anyway
<rogpeppe> fwereade: i really don't believe that could be the case here - this is limited-scope code
<fwereade> rogpeppe, the upgrade step knows where it should be applied
<fwereade> rogpeppe, as a client it's not your responsibility to figure it out, and it's none of your business how it's figured out *anyway*
<rogpeppe> fwereade: if we want behaviour on Targets, that's trivial to add.
<fwereade> rogpeppe, and so it begins
<fwereade> rogpeppe, just a little bit of coupling can't hurt
<rogpeppe> fwereade: it's not coupling
<rogpeppe> fwereade: it's evolving the schema
<fwereade> rogpeppe, and forcing the clients to care about that evolution
<rogpeppe> fwereade: what clients?
<rogpeppe> fwereade: this is essentially an internal-use data structure only
<fwereade> rogpeppe, that doesn't mean there aren't clients
<fwereade> rogpeppe, the code that uses it, and the code that tests it, are the minimum set of clients for just about any construct
<rogpeppe> fwereade: so by "client" you mean the package itself?
<fwereade> rogpeppe, yes
<fwereade> rogpeppe, programming is *all about* managing interfaces to impose simplicity on complexity
<fwereade> rogpeppe, package boundaries are way too coarse to be useful
<rogpeppe> fwereade: sure, but an "interface" can just as well be a concrete data structure there
<rogpeppe> fwereade: i've switched back and forth between interfaces and concrete types many times. i much prefer starting with the simple, and then graduating to the more elaborate when it proves necessary.
<fwereade> rogpeppe, I do not agree with that approach
<fwereade> rogpeppe, I gave it a fair shake
<rogpeppe> fwereade: if you can't agree that a simple concrete type is appropriate for representing a simple concrete bunch of data, i give up
<fwereade> rogpeppe, and I'm confident that most of the current complexity of juju is a result of an adherence to flawed notions of simplicity
<fwereade> rogpeppe, it'd be a different story in python
<fwereade> rogpeppe, because you can use a descriptor in place of a field when it becomes necessary
<fwereade> rogpeppe, but with go you *invest* in the struct approach
<fwereade> rogpeppe, it's an expected value calculation
<rogpeppe> fwereade: you really think that most of the complexity of juju is from using structs?
<fwereade> rogpeppe, most of the bits that really hurt and continue to do so, like jujud, are the way they are because we have no seams by which to pick them apart
<fwereade> rogpeppe, the state/environ horrors are because we have a state struct
<rogpeppe> fwereade: i think most of the pain there is in the tests, not the code
<fwereade> rogpeppe, the inability to test state quickly and easily are because of all the structs in mgo which makes it completely unmockable
<rogpeppe> fwereade: because we had a prior aversion to mocking anything
<rogpeppe> fwereade: huh? we could mock mgo easily
<fwereade> rogpeppe, the awful awful uniter stucture is the same story -- there's nothing *that bad* about it in theory, but in practice you can't isolate any of it and have to take the whol lot as an indivisible unit
<rogpeppe> fwereade: well, except that we'd need to mock mongodb semantics
<rogpeppe> fwereade: again, i really think that's because of our prior aversion to mocking anything
<fwereade> rogpeppe, maybe I'm being dense: how would you mock anything without interfaces?
<rogpeppe> fwereade: there are various places in the code where we *do* manage to mock pieces of the State to good effect
<rogpeppe> fwereade: you don't need to *export* the type as an interface
<rogpeppe> fwereade: you just need to define clients in terms of an interface, and then use some trivial bridge code (or nothing) to bridge the gap
<rogpeppe> fwereade: it's all about ad-hoc interfaces
<fwereade> rogpeppe, isn't that what wallyworld is doing? it's just that you consider the clients in this case as to be too trivial to bother with
 * wallyworld apologises - too tired to contribute tonight
<fwereade> wallyworld, don't worry, not calling you into the conversation :)
<rogpeppe> fwereade: if there was any behaviour to mock, i might agree. but there isn't, and i can see no particular prospect of it - it's really a data-driven algorithm
<rogpeppe> fwereade: for a static table of data, a static table of data seems like the right representation to me
<fwereade> rogpeppe, I think what he'd doing is relying on instinct for bits-likely-to-change, and inserting seams where they're likely to be useful
<fwereade> rogpeppe, apart from the Run bits
<fwereade> rogpeppe, they're types with data *and* behaviour
<rogpeppe> fwereade: tbh what i think what's happening is just use-interfaces-by-rote
<rogpeppe> fwereade: the behaviour is independent of the data
<fwereade> rogpeppe, your refactoring still puts them in the same type; I think that's an indication that it's not *quite* as cut and dried as yu say
<fwereade> rogpeppe, note: this is not a request for a more extreme refactoring ;p
<rogpeppe> fwereade: yes, that type composes both the metadata and some behaviour together
<fwereade> rogpeppe, did I say the thing about expected value?
<fwereade> rogpeppe, not sure I did
<rogpeppe> fwereade: not sure you did
<fwereade> rogpeppe, picking an interface has a small cost now and in future; picking a struct has a lower cost now, and a chance of a much higher cost in future
<fwereade> rogpeppe, the choice comes down to a judgment call
<fwereade> rogpeppe, people can legitimately disagree
<rogpeppe> fwereade: you really think that there's a high cost from moving to use an interface? when there are no external clients?
<rogpeppe> fwereade: i have not found that
<rogpeppe> fwereade: i like the code to be as understandable as possible
<fwereade> rogpeppe, yes, I really do
<fwereade> rogpeppe, IMO/E interfaces are at least as understandable as structs
<rogpeppe> fwereade: so you think that changing the code base to use, for example, all the State types as interfaces, would be hard?
<fwereade> rogpeppe, I'm trying t obe generous in acknowledging that sometimes they're a little cheaper
<rogpeppe> fwereade: interfaces are less understandable because it's not obvious what's going to happen when they're called
<fwereade> rogpeppe, yes, it would be a giant hassle and a massive diff
<fwereade> rogpeppe, because it's *not the client's business*
<rogpeppe> fwereade: it would be a big diff certainly (*state.State -> state.State) but actually it would be easy
<fwereade> rogpeppe, and all the other types?
<rogpeppe> fwereade: in this case we *are* the client!
<rogpeppe> fwereade: sure, it wouldn't be a problem
<rogpeppe> fwereade: i could do it this afternoon if we wanted
<fwereade> rogpeppe, there's no use in having a State interface if Machine returns a *Machine, you have to return Machine as well
<rogpeppe> fwereade: sure, that's why i said "all the State types"
<rogpeppe> fwereade: the only hassle would be maintaining the interface types independently from the struct definitions - the interfaces would be enormous.
<rogpeppe> s/struct definitions/method definitions/
<fwereade> rogpeppe, right, so you *can't* usefully use an ad-hoc interface because you have to construct an actual *Machine
<rogpeppe> fwereade: you can, but it's a bit more work
<rogpeppe> fwereade: (the address updater uses that technique for testing)
<fwereade> rogpeppe, it's an *enormous* amount of work to construct one of those that behaves in a specifically tuned way
<fwereade> rogpeppe, and even *that* is hamstrung because it depends on concrete mgo types
<fwereade> rogpeppe, it's *really nice* to be able to test state clients against tuned mocks, rather than building up loads of state every time
<rogpeppe> fwereade: honestly, it's not *that* much hassle - here's the relevant code the instancepoller tests: http://paste.ubuntu.com/6930374/fwereade: actually the best value would come not from mocking *
<rogpeppe> oops
<rogpeppe> fwereade: honestly, it's not *that* much hassle - here's the relevant code the instancepoller tests: http://paste.ubuntu.com/6930374
<rogpeppe> fwereade: actually the best value would come not from mocking *state.State, but the various other types (*Machine &c)
<fwereade> rogpeppe, multiply that work by N tests for N state clients and it becomes a bit unwieldy
<fwereade> rogpeppe, it's the same simple-code-repeated-everywhere problem
<fwereade> rogpeppe, that I'm not sure yu see as an actual problem
<rogpeppe> fwereade: so if State was an interface, how would that help matters here?
<rogpeppe> fwereade: you'd still need to mock out the actual behaviour
<rogpeppe> fwereade: so you'd probably end up with an enormous "one-size-fits-all" state mocker, which would be its own source of considerable complexity
<rogpeppe> fwereade: i've thought sometimes that it might be nice just to mock out the mgo interface, and write some in-memory mongodb interpretation code
<rogpeppe> fwereade: that would mean that you could base all of the State code in memory, so it would be loads faster
<rogpeppe> fwereade: but... you'd still want to be certain that the mock mgo semantics mirrored the actual mongo semantics
<fwereade> rogpeppe, sure *that* would be nice, but again I don't see how you could actually do that
<fwereade> rogpeppe, well, actually, *not* necessarily
<rogpeppe> fwereade: again, it would be straightforward to do
<fwereade> rogpeppe, mocking lets you exhaustively test the operation of a client given a range of locally defined behaviours
<fwereade> rogpeppe, imagining that the only purpose of a mock is to perfectly simulate a real system is to somewhat miss the point
<fwereade> rogpeppe, what-happens-if-X-bizarre-situation becomes *actually* testable, and cheaply
<rogpeppe> fwereade: the problem is that the integration tests don't necessarily test all the behaviours that are being tested in the unit tests
<rogpeppe> fwereade: ideally, you'd be able to test against both the mock (for quick tests) and the real thing (for slower but more complete) tests
<fwereade> rogpeppe, integration tests as tracer bullets, and exhaustively paranoid unit tests with mocks, are O(N) work; exhaustively paranoid integration tests are O(N^layers-used-directly-or-indirecttly)
<jamespage> is it really right that 1.16.6 added errgo?
<fwereade> rogpeppe, oh yes, more direct switch of subject
<rogpeppe> jamespage: definitely not
<fwereade> rogpeppe, if we're depending on it can we please put it under github/juju
<jamespage> rogpeppe, well its in the release tarball...
 * jamespage sighs
<rogpeppe> jamespage: i know why
<jamespage> I'll ping sinzui later
<rogpeppe> jamespage: it's because of the way that the tarball is built
<rogpeppe> jamespage: it's not actually *used* by juju in 1.16.6
<rogpeppe> jamespage: but the tarball is build by doing "go get .../juju" then updating to the correct revision, then updating the deps
<rogpeppe> jamespage: but updating the deps does not remove unused deps
<jamespage> rogpeppe, oh crap - so it will pull in all trunk deps but not drop ones used in stable
<jamespage> not used that would be
<rogpeppe> jamespage: yes
<jamespage> that's not helpful
<rogpeppe> jamespage: that's my understanding
<jamespage> rogpeppe, lemme nag sinzui later
<jamespage> I was going to upload this for SRU but stuff like this will make the SRU team nervous
<rogpeppe> jamespage: what's the actual problem with having unused deps?
<rogpeppe> fwereade: this'll be thumper's errgo, FWIW
<fwereade> rogpeppe, sure, the request still stands
<rogpeppe> fwereade: ok
<rogpeppe> fwereade: you don't think that github.com/errgo/errors is a reasonable path for it?
<rogpeppe> fwereade: it would be considerably more likely for 3rd party code to use it there, i think, and that would be a Good Thing
<fwereade> rogpeppe, I'm not sure that's the case -- and I really don't want to further grow our dependencies on external code
<fwereade> rogpeppe, it'll be a pretty fundamental dependency
<fwereade> rogpeppe, and if it's good and stable I don;t think being under an organisation named for a (hopefully) successful and popular open-source package will do it any harm
<rogpeppe> fwereade: perhaps so.
<rogpeppe> fwereade: i'll probably put it at the above path too, and make sure the two are compatible
<fwereade> rogpeppe, it remains a distinct package with its own identity but we get to move towards drawing our critical dependencies into a sphere over which we have control
<fwereade> rogpeppe, that's perfectly fine
<fwereade> rogpeppe, jamespage: btw, AIUI, we *could* chck out juju, and use deps.tsv to pull in the necessary dependencies on their own, and then not run the risk of pulling in other random unpinned stuff, right? we just don't do that yet
<rogpeppe> fwereade: the problem with that is my fault
<fwereade> rogpeppe, jamespage: but I don't see any reason not to?
<rogpeppe> fwereade: which is that godeps doesn't currently have a way to pull deps - it just updates existing deps
<fwereade> rogpeppe, yeah, I can see that the pulling-deps bit is a hassle
<rogpeppe> fwereade: i should just do that - i've just been lazy so far
<fwereade> rogpeppe, that would be awesome
<fwereade> rogpeppe, btw can I steal 30s of attention for a review of https://codereview.appspot.com/63710044/ please?
<rogpeppe> fwereade: sure
<rogpeppe> fwereade: what's the deal with the changes to UniterAPI.getUnit and getService?
<fwereade> rogpeppe, oh balls
<fwereade> rogpeppe, wrong base
<fwereade> rogpeppe, it's https://codereview.appspot.com/57710043/
<fwereade> rogpeppe, the reason is that there's no guarantee that we're actually passing unit or service tags there
<rogpeppe> fwereade: yeah, i figured that.
<rogpeppe> fwereade: it could still use FindEntity and just check the type-assertion result, but the ParseTag approach is cheaper and probably better, yeah
<rogpeppe> fwereade: i don't quite understand how that CL restores the ability of the uniter to read removed units
<fwereade> rogpeppe, getUnit fails if the unit doesn't exist
<fwereade> rogpeppe, pulling out the service name still works so long as the service is there
<fwereade> rogpeppe, and it will be so long as the relation using it is
<rogpeppe> fwereade: but didn't we just call getUnit to get the RelationUnit ?
<rogpeppe> fwereade: that's operated on by checkRemoteUnit
<fwereade> rogpeppe, the RelationUnitis for LocalUnit
<rogpeppe> fwereade: ah ha!
<rogpeppe> fwereade: ok, makes sense.
<rogpeppe> fwereade: LGTM with a suggestion for a comment
<fwereade> rogpeppe, SGTM, would you LGTM the other one for form's sake too please?
<rogpeppe> fwereade: am looking currentyl
<natefinch> morning all. Seems like I missed the standup?
<fwereade> natefinch, er, I didn't spot the standup reminder :/
<fwereade> rogpeppe, natefinch: shall we do it quickly then?
<rogpeppe> fwereade: i didn't either
<rogpeppe> fwereade, natefinch: let's
<rogpeppe> mgz: standup?
<rogpeppe> mgz: (better late than never...)
<TheMue> could somebody please give me a little hit at the back of my head! somehow I'm in vi mode and trying to operate my sublime editor with vi commands. *aaaargh*
<rogpeppe> anyone see launchpad.net down ?
<natefinch> rogpeppe: fine for me
<rogpeppe> natefinch: ah, it's started working again
<natefinch> rogpeppe: you're welcome ;)
<rogpeppe> natefinch: although it doesn't seem to be registering my branch pushes
<rogpeppe> i'm trying to approve this: https://code.launchpad.net/~rogpeppe/juju-core/487-remove-job-managestate/+merge/202916
<rogpeppe> but it keeps insisting that it's on revno 2250, not the latest revno 2252
<rogpeppe> and as expected the bot is saying "There are additional revisions which have not been approved in review"
<rogpeppe> how frustrating
<natefinch> rogpeppe: yeah weird
<rogpeppe> natefinch: if you do, "bzr revno -r lp:~rogpeppe/juju-core/487-remove-job-managestate", it prints 2252, right?
<natefinch> rogpeppe: it prints ??? as the response, which is less than encouraging
<rogpeppe> natefinch: ah, that might be just bzr - can you pull the branch?
<natefinch> rogpeppe: yep, and once that's done it says 2252
<rogpeppe> natefinch: right, thanks
<rogpeppe> natefinch: so *something* is up with lp
<rogpeppe> mgz: any idea what could cause this?
<rogpeppe> cd ..
<rogpeppe> hmm, interesting bzr push error:
<rogpeppe> bzr: ERROR: Server sent an unexpected error: ('error', 'xmlrpclib.ProtocolError', '<ProtocolError for xmlrpc.lp.internal:8097/codehosting: -1 >')
<natefinch> rogpeppe: have you tried rebooting? :D
<mgz> hm, nothing particular comes to mind
<rogpeppe> natefinch: it doesn't seem like a local problem to me
<rogpeppe> another error: ConnectionReset reading response for 'BzrDir.open_2.1', retrying
<rogpeppe> but then the retry succeeded
<natefinch> rogpeppe: that's the joke.  But yes, aggravating.
<mgz> may be a remote issue
<rogpeppe> mgz: so no idea of how i might be able to prod lp into recognising that a branch has been updated?
<rogpeppe> ha, "Sorry, there was a problem connecting to the Launchpad server."
<rogpeppe> so it's not just one branch
<rogpeppe> natefinch: what happens if you go to https://code.launchpad.net/~rogpeppe/juju-core/479-desired-peer-group/+merge/201245 now?
<mgz> rogpeppe: still getting an error now?
<natefinch> rogpeppe: that's a different MP, is that the right link?
<rogpeppe> natefinch: yeah, i was getting an error on that one too
<rogpeppe> mgz: i just succeeded with that one. let me try the first one again
<rogpeppe> mgz: getting an error with that one still; will keep reloading the page
<rogpeppe> ah, finally!
<rogpeppe> approved at the right version
<natefinch> rogpeppe: what's the proper way to join path strings in a path list? our code does a lot of path+":"+newpath  but that'll fail on windows.... but os.PathListSeparator is a rune, not a string, which makes it a pain in the ass
<rogpeppe> natefinch: i saw a proposal ages ago for a filepath.SplitList, but i think it foundered
<rogpeppe> natefinch: s/SplitList/JoinList
<rogpeppe> natefinch: we could always add it to utils
<natefinch> rogpeppe: ok, yeah, I had hoped I just missed it somewhere
<rogpeppe> natefinch: func JoinList(paths ...string) {return strings.Join(paths, string(os.PathListSeparator))}
<rogpeppe> natefinch: actually, given that it's in utils, it should probably be JoinPathList
<natefinch> rogpeppe: ahh, didn't realize you could cast a rune to a string.
<rogpeppe> natefinch: you should read the spec again :-)
<natefinch> yeah, it's been a while.  Just haven't dealth with runes much
<rogpeppe> structural regexp line noise of the moment: ,x/^=.*\n([^=].*\n)+/y/^=.*\n(---.*\n)?(\+\+\+.*\n)?/x/(^[+\-].*\n)+/g/(errors|errgo)\.Cause/=
 * mgz hits rogpeppe 
 * rogpeppe protests: "but it's doing useful stuff for me!"
<rogpeppe> mgz: perhaps you've got a better idea actually.
<rogpeppe> mgz: i've got an enormous branch that i want to cherry pick certain bits from automatically
<mgz> na, not really, rewrites like this are always just finding the right pain balance of automation and manual work
<rogpeppe> mgz: (or at any rate with a minimum of effort)
<rogpeppe> mgz: do you know of a tool that lets me just click on the bits i want to choose?
<mgz> hm, well, with an existing branch, depending on how the bits are layed out, you may find a merge and a proper three-way editor faster
<natefinch> now you have two problems etc
<natefinch> yeah, a proper merge tool makes it a lot easier
<mgz> natefinch: do you have a particular one you tend to use?
<mgz> I struggle along with vimdiff when I need it generally
<natefinch> mgz: beyond compare is awesome
<natefinch> mgz meld is supposed to be pretty awesome but I haven't used it
<rogpeppe> natefinch: i'm just trying meld, but it's not easy to see how it supports my use case
<natefinch> rogpeppe: you should be able to diff a clean branch vs. your fixed branch then just do a search for .Cause and copy over the changes that you want to keep
<rogpeppe> natefinch: thanks, that sounds plausible, i'll try that
<natefinch> rogpeppe: yeah, since you said there weren't that many spots in which you use cause, it's probably faster and easier than trying to get exactly the right regex to work.
<rogpeppe> natefinch: yeah, and the regex isn't sufficient anyway, because there are other parts related to Cause changes that don't mention Cause
<natefinch> rogpeppe: ahh yeah. Sometimes there's no replacement for the human brain
<natefinch> arg... I kinda wish we hadn't used testing/testbase in utils, because then it means we can't use utils in testing/testbase :/
<niemeyer> Hey all
<niemeyer> fwereade: Is the juju-dist bucket still being used?
<niemeyer> Hmm, looks like it is
<TheMue> *: did anybody had a "cannot upload charm: Post https://localhost:8900/charms?series=quantal: local error: record overflow" in client_test.go TestAddLocalCharm()?
<fwereade> niemeyer, it's still being uploaded to and while it's probably not being used *much* we did come across some guys with a very old environment recently
<fwereade> niemeyer, where there's one there may be more
<TheMue> fwereade, rogpeppe: do you know the test failure mentioned above?
<rogpeppe> TheMue: i haven't seen that
<TheMue> rogpeppe: thx, strange
<niemeyer> fwereade: Hmmm
<niemeyer> fwereade: Do we have any releases in Ubuntu using it?
<fwereade> TheMue, hmm, haven't seen that
<fwereade> niemeyer, I don't *think* so -- 1.14 is the latest that depends on it iirc -- but they need it to upgrade to 1.16
<niemeyer> fwereade: Ah, still recent then, cool
<TheMue> rogpeppe, fwereade: running the test solo it passes, running the suite it fails ???
<rogpeppe> TheMue: it fails reliably?
<TheMue> rogpeppe: seems so, had been able to repeat it multiple times
<TheMue> rogpeppe: the "record overflow" is no text in our code
<rogpeppe> TheMue: interesting.
<rogpeppe> TheMue: what does the test output look like?
<TheMue> rogpeppe: http://paste.ubuntu.com/6931384/
<TheMue> rogpeppe: and the piece of code is http://paste.ubuntu.com/6931388/
<rogpeppe> TheMue: interesting - i'm not sure that could ever have worked
<TheMue> rogpeppe: hehe
<TheMue> rogpeppe: but as I said, running the test function as the only one it works
<rogpeppe> oh, i see; it sets the server root
<rogpeppe> TheMue: i suspect you've got two tests colliding
<rogpeppe> TheMue: that test should definitely not be listening on a fixed port
<TheMue> rogpeppe: sounds logical
<rogpeppe> TheMue: if you change that code to listen on a newly chosen port instead, does it still fail?
<rogpeppe> TheMue: ah, there's another problem with that code too - it may not have actually started listening when you add the local charm
<TheMue> rogpeppe: changed to 8901, still fails
<rogpeppe> TheMue: could you change it to listen on a newly chosen port (use net.Listen("tcp", ":0"))
<rogpeppe> ?
<TheMue> rogpeppe: have to check how I would have to change the code, but now I've got my standup
<rogpeppe> TheMue: the same way that all the other test http listeners do it
<TheMue> rogpeppe: will look there
<TheMue> rogpeppe: changed it and it runs on the same failure
<rogpeppe> TheMue: what does the code look like now?
<TheMue> rogpeppe: paste.ubuntu.com/6931586/ - and it still passes when called alone
<rogpeppe> TheMue: hmm
<rogpeppe> TheMue: one possible thing to try: in the juju-core root directory, run "godeps -u dependencies.tsv"
<TheMue> rogpeppe: could do so, but could you explain the reason for this command before?
<rogpeppe> TheMue: it updates the package dependencies to be as expected
<rogpeppe> TheMue: also, what version of Go are you using?
<TheMue> rogpeppe: 1.1.1
<TheMue> rogpeppe: should update ;)
<rogpeppe> TheMue: yes, you must do that
<rogpeppe> TheMue: you should be using 1.2
<rogpeppe> TheMue: if you're not up to date, you'll probably need to iterate - when godeps complains about a package (because the required revision isn't available), run go get -u <pkgname>
<TheMue> rogpeppe: ok, will quickly change
<sinzui> hi rogpeppe , natefinch : Do either of you have a few minutes to review a backport for 1.16 that lets QA run unit-tests? https://codereview.appspot.com/64000043
<rogpeppe> sinzui: looking
<rogpeppe> sinzui: LGTM
<sinzui> thank you rogpeppe
 * rogpeppe goes for lunch
 * natefinch goes to blow some snow
<TheMue> rogpeppe: after update and rebuild of all pkgs still the same
<rogpeppe> fwereade: https://github.com/juju/errgo
<rogpeppe> fwereade: (README thanks to github.com/robertkrimen/godocdown )
<fwereade> rogpeppe, awesome, tyvm
<sinzui> any ideas about what I can do to make gobot test my branch again? https://code.launchpad.net/~sinzui/juju-core/run-unit-test-on-trusty/+merge/206503
<rogpeppe> sinzui: sometimes it gets stuck
<rogpeppe> sinzui: it should be working again now
<sinzui> plars in #juju reports this error on hp-cloud. The config works for 1.16.3, but not 1.17.2
<sinzui> ERROR bootstrap failed: cannot start bootstrap instance: index file has no data for cloud {region-a.geo-1 https://region-a.geo-1.identity.hpcloudsvc.com:35357/v2.0/} not found
<rogpeppe> sinzui: BTW i updated your commit message - it's really nice if the commit message is exactly the same as is in the codereview description, including the codereview link
<sinzui> I cannot reproduce the issue
<sinzui> noted rogpeppe
<rogpeppe> sinzui: i'm away for the weekend now
<rogpeppe> happy weekends all
<sinzui> me too
#juju-dev 2014-02-16
<fwereade> waigani___, heyhey
<waigani_____> fwereade: hello :)
<fwereade> waigani___, how's it going?
<waigani_____> getting there
<fwereade> waigani___, sorry I haven't really said hi properly since you joined :(
<waigani_____> a LOT of code to get my head around!
<fwereade> waigani___, ha, yes indeed
<waigani_____> no problem, totally understandable
<waigani_____> ditto, sorry for not saying hi :)
<waigani_____> so, I'm getting racy hey?
<fwereade> waigani___, I'm kinda going to bed shortly but I just wanted to chat briefly about the set environ config stuff
<waigani_____> sure
<waigani____> fwereade: hangout or irc?
<fwereade> waigani___, the issue is mainly that I don't really want it to be possible to set an invalid environ config, and I am not convinced that it's possible to guarantee the sanity of a given change without (1) validating the change from the previous version --which is fine, you do it-- and (2) asserting in state that the previous version, from which the change is known to be valid, still applies
<fwereade> waigani____, I think I can irc it, I will be off to bed in a mo
<waigani____> ok
<fwereade> waigani____, does that make sense at first reading or shall I expand a little? ;)
<waigani____> right, so the real issue is the last one
<waigani____> how do you ensure the oldconfig is itslef valid
<fwereade> waigani____, if you can guarantee every change is valid, I think yu can guarantee that the previous version was
<fwereade> waigani____, because you cannot bootstrap but with a valid config
<waigani____> can we?
<waigani____> right
<waigani____> in which case the current method works then?
<waigani____> we can rely on an oldconfig
<waigani____> oohhhh
<waigani____> lol
<waigani____> i see
<waigani____> THAT is why you don't want to allow setconfig without validating
<fwereade> waigani____, the current method is (at least in theory) crack, because the *actual* change we end up making is pretty random -- see state/state.go:264
<waigani____> so this is the race condition you mentioned?
<fwereade> waigani____, in *practice* it's usually ok, but that's because we don't get many concurrent updates to environ config
<fwereade> waigani____, yeah, I think so
<fwereade> waigani____, I have a tendency to froth about a wide range of possible race conditions
<waigani____> heh
<fwereade> waigani____, ah, but, yes, that's the one
<fwereade> waigani____, so what's interesting is that axw is doing some work that involves using an Environ inside state
<waigani____> what does axw mean when he says The settings changes are actually applied as a delta to what's on disk
<waigani____> "applied as a delta"?
<fwereade> waigani____, there's a Settings type
<fwereade> waigani____, it was written in python for zookeeper and ported straight without much consideration for whether it still makes sense
<fwereade> waigani____, hint: it doesn't
<waigani____> lol, okay...
<fwereade> waigani____, I am struggling to remember the *exact* details
<fwereade> waigani____, but it is itself fundamentally racy
<waigani____> don't worry, I'll follow up
<fwereade> waigani____, it reads existing state, calculates delta, applies delta
<waigani____> now I know the direction to look in
<fwereade> waigani____, pretty sure it doesn't assert the base state still holds
<waigani____> now state == mongodb?
<fwereade> waigani____, yeah, take a look at that for a bit of context
<fwereade> waigani____, yep
<waigani____> i.e. config stored in mdb
<fwereade> waigani____, but have a word with axw, because *he* is doing some work that involves using an Environ inside state to check sanity of AddMachine ops by checking with the provider
<fwereade> waigani____, and *you* are doing something that involves checking sanity of applying changes to Environ (configs)
<waigani____> will do.
<waigani____> would you like to see the ApplyAndValidate method I've refactored out, added back into SetEnvironConfig?
<waigani____> Such that you cannot set an environ config without validating it?
<fwereade> waigani____, I think that is at least part of it, but be suspicious of what actually happens when you try to use that settings type
<waigani____> fwereade: be suspicious of SetEnvironConfig?
<fwereade> waigani____, it may be that you're best off using entirely different code that just happens to use the same data format
<fwereade> waigani____, more of state.Settings
<fwereade> waigani____, ...or, heh, maybe converting it to use a new data format
<fwereade> waigani____, I'm also pretty sure that the fields are dumped straight into the mongo document
<waigani____> fwereade: just saw your comment: TODO(fwereade) state.Settings is itself really problematic in just about every use case
<fwereade> waigani____, and by sheer conincidence magic fields like txn-revno happen not to collide with actual env settings
<fwereade> waigani____, I think what I'm saying is that you have stumbled into a rabbit hole
<fwereade> waigani____, do not feel obliged to fix everything
<waigani____> I was just about to say the same!
<fwereade> waigani____, but be careful to understand what you're fixing and what you're not, and please document it clearly
<fwereade> waigani____, take heart: you're unlikely to make that specific code *worse*
<waigani____> obviously my understanding is cursory, so I'll follow up with axw and look into state.Settings
<fwereade> waigani____, and I'll be happy if it just gets a little bit better
<fwereade> waigani____, awesome, thanks
<waigani____> are there any other hits for me?
<waigani____> bits of code I should look at?
<fwereade> waigani____, for this particular stuff it's quite localised
<fwereade> waigani____, there are a couple of other Settings clients
<fwereade> waigani____, one day we'll get rid of them all
<waigani____> okay
<fwereade> waigani____, but it's the env config that really upsets me
<fwereade> waigani____, because it's the most potentially horrible one ;)
<fwereade> waigani____, anyway I should get some sleep
<waigani____> just before you go .... :D
<fwereade> waigani____, I might be a little late tomorrow, but dimitern is staying here, so if you see him and want to talk to me tell him to come shout at me :)
<fwereade> waigani____, I'm still here :)
<waigani____> could you give me one example of the race conditon?
<waigani____> two clients trying to set the config at the same time? Is that right?
<fwereade> waigani____, yeah
<waigani____> clients = machine agent, juju cli, ...
<fwereade> waigani____, ah!
<fwereade> waigani____, there *is* a replaceSettingsOp func
<fwereade> waigani____, that I think is not racy
<waigani____> oh
<fwereade> waigani____, it may need to be retried
<fwereade> waigani____, but if you use it the txn will abort
<waigani____> okay, lots to learn ... I'll let you sleep
<fwereade> waigani____, so, *if* you can construct a known-valid config, you can use replaceSettingsOp to be sure it actually lands in state
<waigani____> thanks for taking the time to walk me through the rabbit whole, a little ;)
<fwereade> waigani____, but to construct a known-valid one inside state, you'll need to talk to axw
<waigani____> *hole
<fwereade> waigani____, because
<fwereade> (you're sitting down, right)
<waigani____> hehe yep
<fwereade> waigani____, just because it's a valid config.Config
<fwereade> waigani____, it is *not* necessarily a valid config for any given provider
<waigani____> ugh
<fwereade> waigani____, let alone a valid change for that specific environ
<waigani____> what?
<waigani____> I get that it might not be valid for other providers
<fwereade> waigani____, simplest case: some fields are immutable, or should be
<fwereade> waigani____, change an env's name from foo to bar, bad things will happenb
<fwereade> waigani____, constructing an env, and setting the new config, *should* catch all those cases
<waigani____> so that should be caught as invalid by the environ provider validator?
<waigani____> right
<fwereade> waigani____, *but* the environs package uses the state package, so you can't directly reference an Environ as such from code inside state
<fwereade> waigani____, axw is dealing with *exactly* the same problem, creating environs inside state to validate machine addition
<fwereade> waigani____, so it would be good if your solutions were roughly aligned :)
<fwereade> waigani____, was that a bit more helpful?
<waigani____> yes, you've set me in the right direction
<fwereade> (ok, it's not *exactly* the same problem, but you can surely talk productively)
<waigani____>  I'll go annoy axw now  ;)
<fwereade> waigani____, cool, cheers
<waigani____> thanks again, sleep well
 * fwereade disappears
#juju-dev 2015-02-09
<mattyw> morning all
<anastasiamac> mattyw: o/
<mattyw> anastasiamac, \o
<anastasiamac> mattyw: ur morning is my afternoon :D but morning to u nonetheless!
<mattyw> anastasiamac, http://www.total-knowledge.com/~ilya/mips/ugt.html
<mattyw> anastasiamac, it's a good point - you're still active in the channel on a sunday afternoon
<anastasiamac> mattyw: monday afternoon :D
<anastasiamac> mattyw: m k with ugt but
<anastasiamac> mattyw: u didn't ugt
<mattyw> anastasiamac, I thought you were south america?
<anastasiamac> mattyw: ug is shorter :D for both start (*universal greeting*) and finish (*universal goodbye*)
<mattyw> anastasiamac, I'm now starting to think that was wrong
<anastasiamac> mattyw: m in Australia
<mattyw> anastasiamac, monday afternoon makes much more sense to be now :)
<mattyw> anastasiamac, I'm in Malayia at the moment - but only for the next month - then I'm back in the UK
<anastasiamac> mattyw: nice place to spend coldest month of the year :D
<mattyw> anastasiamac, it's tough working from home ;)
<axw> mattyw: jealous of all the tasty food you're likely eating :(
<mattyw> axw, The best part is I've still managed to loose weight - it's win win!
<axw> mattyw: hah, winner :)
<axw> anastasiamac: would you mind if we rename the "storage" API to "storagemanager"? there will be a "storageworker" (possibly "storageprovisioner") API, and the names are likely going to get muddled
<anastasiamac> axw: +1 to rename but r u sure about "manager'?
<axw> anastasiamac: I'm not fussed on the name, just picked that to go with "usermanager", "environmentmanager", "imagemanager", etc.
<axw> anastasiamac: there's also metricsmanager which doesn't fit the same pattern, and "diskmanager" which should be renamed anyway
<axw> diskmanager's job is now just to publish info on block devices
<anastasiamac> axw: what would "manager" be primarily responsible for? crud ops?
<axw> anastasiamac: yep, I think so
<axw> anastasiamac: the user's view into that subsystem
<anastasiamac> axw: k. lets rename it to "storagemanager" to align with majority of managers :D
<axw> okey dokey
<anastasiamac> axw: hopefully, all the "managers" that do not do crud will be renamed :D
<axw> anastasiamac: that's difficult, since they exist in released code
<axw> well, the metrics one
<axw> the disk one is easy
<anastasiamac> axw: my "hopefully" is not prescriptive :)
<jam> dimitern: if you see william around, poke him for me. I'll try to keep an eye out.
<jam> fwereade: apparently invoking your name was enough to wake you up (I just tried to ping your 30s ago :)
<dimitern> jam, sure
<fwereade> jam, haha, jolly good
<fwereade> jam, sorry, my sleep got a bit confused over the flights home
<fwereade> jam, I *think* I slept more than usual in24h but it's a bit hard to follow
<fwereade> jam, ah yes and my calendar is still on za time, so I thought we were strting at 11
<dimitern> voidspace, hey old chap ;)
<jam> fwereade: I was just about to grab a coffee and a snack, but I'll be back on the hangout in a couple mins
<fwereade> jam, cool, will be there in a mo
<voidspace> dimitern: morning
<dimitern> voidspace, morning!
<dimitern> voidspace, even though I'm officially off today, I'll be joining the standup to sync up
<voidspace> dimitern: welcome back to Europe
<voidspace> dimitern: ah, ok
<voidspace> dimitern: cool
<voidspace> dimitern: I'm grabbing coffee, brb
<dimitern> voidspace, ok
<dimitern> how's the expert on juju metadata generate-tools?
<dimitern> s/how's/who's/
<fwereade> dimitern, wallyworld
<dimitern> fwereade, yeah, so since he's off today I guess I need the next guy who knows his way around there
<fwereade> dimitern, is this the "it generates index not index2" thing or something else?
<fwereade> dimitern, I might suggest someone from curtis' team, because they're the ones who have to do most of the generating in anger
<dimitern> fwereade, Muntaner here has issues bootstrapping a private openstack cloud due to not finding the juju tools - he had issues before with images, but that's resolved now and bootstrap launches an instance, but can't find the tools
<Muntaner> logs -> http://paste.ubuntu.com/10139639/
<dimitern> fwereade, ok, so just to summarize it for you - generate-tools did create what's needed in the dir, but the tarballs themselves are missing - how should you get them for a stable release?
<dimitern> guys, I need a review on these PRs - http://reviews.vapour.ws/r/890/ (main one for 1.21), http://reviews.vapour.ws/r/891/ (foreport for 1.22 of the same fix), http://reviews.vapour.ws/r/892/ (foreport for 1.23)
<dimitern> these fix bug 1418433
<mup> Bug #1418433: unit ports not populated by API megawatcher <api> <regression> <juju-core:In Progress by dimitern> <juju-core 1.21:In Progress by dimitern> <juju-core 1.22:In Progress by dimitern> <juju-gui:Triaged> <https://launchpad.net/bugs/1418433>
<fwereade> dimitern, hmm, I had expected that for a stable release you'd just want to mirror streams.c.c?
<fwereade> Muntaner, ^^
<Muntaner> hi fwereade :)
<fwereade> Muntaner, o/
<dimitern> fwereade, that sgtm - so basically download all of it in a local dir and run validate-tools against it?
<Muntaner> fwereade: going a bit crazy with juju + private openstack cloud
<fwereade> Muntaner, dimitern: it seemed like the lowest-friction thing to do was just to say "mirror streams.canonical.com somewhere your private cloud can see it"
<fwereade> Muntaner, dimitern: there will surely be cases where that's not good enough, eg if you're testing hotfixes or proposed releases or whatever
<dimitern> Muntaner, or just put juju-1.21.*.tgz files from http://reviews.vapour.ws/r/892/
<dimitern> Muntaner, or just put juju-1.21.*.tgz files from http://streams.canonical.com/juju/tools/releases/ in your local metadata dir at the same path
<dimitern> sorry, ignore the first url :)
<Muntaner> dimitern: it's fine :)
<Muntaner> I'll try and give feedback now
<dimitern> Muntaner, cheers
<fwereade> Muntaner, dimitern: but for the "I just want stable tools" case it's meant to work -- and all the signatures should still match etc so you can still have some confidence in what you're running even though it's not directly from the official source
<fwereade> Muntaner, dimitern: it would be best of all to use a tools-metadata-url pointing to a local server, rather than keeping it in a local dir, I think
<Muntaner> fwereade: should I do this in environments.yawl?
<Muntaner> what line should I add?
<dimitern> fwereade, Muntaner, that's if you are willing to do a full mirror of the /juju/tools/ dir from streams.c.c and run a local webserver for them; alternatively you can just generate the tools metadata and copy the tools tarballs in there
<dimitern> Muntaner, or, maybe even simpler
<fwereade> Muntaner, have you seen https://juju.ubuntu.com/docs/howto-privatecloud.html#deploying-private-clouds ?
<fwereade> Muntaner, "For tools, it is often easiest to just mirror https://streams.canonical.com/tools."
<dimitern> Muntaner, try first of all to specify tools-metadata-url: https://streams.canonical.com/juju/tools in envs.yaml and then bootstrap with --metadata-source <that dir you used earlier>
<Muntaner> yes fwereade, but I was following the troubleshooting suggestions by dimitern :)
<dimitern> Muntaner, the doc is the correct source, but it *might* be a bit out of date, if it doesn't work for you as described there we need to file a docs bug to fix it
<fwereade> Muntaner, so just to be clear: assuming you don't have outside internet access the first thing to try is to mirror streams.c.c on some accessible webserver, and set a suitable value for tools-metadata-url in environments.yaml
<fwereade> Muntaner, is that failing for you?
<Muntaner> so, my environments.yawl now is: http://paste.ubuntu.com/10139920/
<Muntaner> gonna run juju bootstrap --metadata-source /home/mike/juju-tools --debug
<dimitern> Muntaner, ok, give it a try
<fwereade> Muntaner, I'm not sure you want both of those?
<jam> where oh where has my fwereade gone, where, oh where can he be... :)
<dimitern> fwereade, he needs the metadata for the images - it's a local openstack
<Muntaner> juju created the vm on my openstack...
<Muntaner> it is running apt-stuff on it
<Muntaner> (communicating via floating-ip)
<Muntaner> installing packages...
<Muntaner> error QQ
<Muntaner> dimitern: fwereade -> http://paste.ubuntu.com/10139949/
<dimitern> Muntaner, ok, try tools-metadata-url: https://streams.canonical.com/juju and re-bootstrap
<Muntaner> as far as I can understand... he gets the tools, but fails something else later
<dimitern> Muntaner, ah, no wait
<Muntaner> dimitern: already got that in environments.yawl :)
<dimitern> Muntaner, it actually seems to fail finding images
<dimitern> gtg for now, will come back to you later Muntaner
<Muntaner> maybe should set some other urls in environments.yawl? I remember some tutorial suggesting to do that...
<Muntaner> QQ
<Muntaner> fwereade: in fact, the file http://cloud-images.ubuntu.com/releases/streams/v1/index.json exists, why can't juju read it?
<Muntaner> fwereade: he also is searching for http://cloud-images.ubuntu.com/releases/streams/v1/mirrors.json, which does not exist
<dimitern> voidspace, btw when you have some time, please have a look at these -  http://reviews.vapour.ws/r/890/ (main one for 1.21), http://reviews.vapour.ws/r/891/ (foreport for 1.22 of the same fix), http://reviews.vapour.ws/r/892/ (foreport for 1.23)
<voidspace> dimitern: ok
<fwereade> Muntaner, sorry, I'm in a meeting and failing to distribute my attention properly
<Muntaner> fwereade: no problems :)
<dimitern> dooferlad, hey hey :)
<dooferlad> dimitern: hi :-)
<dimitern> voidspace, meet the new and improved dooferlad !
<dimitern> dooferlad, thanks for doing this! :)
<dimitern> mgz, hey! o/
<mgz> dimitern: hey!
<dimitern> mgz, how do you like go-goose? :)
<mgz> it's a cute name :)
<mgz> dimitern: do you need help migrating the code?
<dimitern> mgz, yeah :) it became cuter as a side-effect :)
<dimitern> mgz, I could use some tips to do it faster I guess
<mgz> dimitern: if you want, I can do the import and give you the git branch
<mgz> if we just want the existing history as per juju-core migration
<dimitern> mgz, do you like the icon I came up with ? (it took 15m during lunch, but hey - better have one than a blocky generic GH icon)
<mgz> yeah, the icon was one of my fav bits :)
<dimitern> mgz, :D
<dimitern> mgz, I'd like to keep the history, but we need to migrate the code into a "v1" branch and make that the default, while leaving master alone and putting a "error.go" file that panics in case someone tries to use it (like mgo has)
<mgz> dimitern: see lp:~gz/+junk/juju_git_import for instance
<mgz> I can do an imports rewrite and then we fiddle with the error.go bit after?
<dimitern> mgz, awesome, sgtm
<mgz> okay, I'
<dimitern> mgz, do you think we can set up gated merges with the bot relatively easy as well?
<mgz> ll adapt that, do the import, then share the branch with you and we can work out what else we needed
<dimitern> mgz, +1 ta!
<mgz> dimitern: that's a little more work, but I have some of the setup for it already
<mgz> you'll want to add the juju-bot to the team
<dimitern> mgz, great, I'll do that then
<dimitern> mgz, and ask all the hackers to make themselves public for the bot to see them
<dimitern> mgz, the bot setup can be done in the upcoming days, it's fine - no need to rush it
<voidspace> dimitern: hehe, nice
<voidspace> dooferlad: welcome :-)
<dooferlad> voidspace: hi!
<dimitern> mgz, jujubot is invited in it's own Bots team with write access, like for juju/juju
<mgz> dimitern: do, out github path is going to be github.com/go-goose/goose but the imports should be gopkg.in/goose.v1 ?
<mgz> dimitern: ta
<dimitern> mgz, yes, exactly
<dimitern> mgz, for an easy way to update all imports I used the awesome govers tool rogpeppe1 did
<rogpeppe1> mgz, dimitern: govers is now at github.com/rogpeppe/govers FWIW
<dimitern> rogpeppe1, ah, nice - thanks!
<mgz> dimitern: github.com/bz2/goose is a first pass import, script for that at lp:~gz/+junk/goose_git_import
<mgz> we want to see if there's anything obviously wrong with that, then make any further changes in a new rev and push to the go-goose project - or redo if needed
<dimitern> mgz, sgtm, looking at those now
<rogpeppe1> mgz: govers -m github.com/goose gopkg.in/goose.v1
<mgz> hm, seems I didn't get the import renaming somehow
<rogpeppe1> mgz: also has the advantage that it makes sure that all dependencies are using the same import too
<mgz> I'll use rog's thing
<rogpeppe1> oops
<rogpeppe1> govers -m launchpad.net/goose gopkg.in/goose.v1
<dimitern> mgz, I've created v1 branch from master for go-goose/goose
<dimitern> rogpeppe1, ta!
<dimitern> mgz, I think we need it in place before trying to change imports
<mgz> well, it's a bit chicken and egg
<mgz> just sedding the import paths like I did should make it possible to test locally first
<mgz> I'm just confused by the history atm, my commit was wrong...
<mgz> missed the -a on commit, rerunning
<dimitern> mgz, ah, ok
<mgz> okay, pushed up new revisions, try again
<mgz> that's beetter
<dimitern> mgz, incidentally, do you have permissions to add dooferlad to juju hackers team?
<mgz> sure
<dimitern> mgz, ta!
<perrito667> wiiii sosie saco al gaspar
<perrito667> sorri wrong channel
<dimitern> perrito667, was that you password ? :D
<mgz> dimitern: he's already a member
<dimitern> mgz, well it doesn't show on his lp page and he can't triage bugs, so I guess something else is wrong
<mgz> ah, not github
<dimitern> mgz, yep, LP
<mgz> you mean adding to the ~juju team
<dimitern> mgz, yes, sorry I should've been more clear :)
<dimitern> and also I should be an admin there as well hmmm
<mgz> I'm not an admin on that one. can bug curtis later or one of the other leads.
<dimitern> jam, ping
<mgz> dimitern: you should now
<dimitern> mgz, yeah, I'll ask john to add me, thanks
<perrito667> anybody could http://reviews.vapour.ws/r/889/ ?
<voidspace> dimitern: couldn't we detect older clients and report port ranges as individual ports?
<voidspace> dimitern: rather than dropping the ranges
<dimitern> perrito667, LGTM
<dimitern> voidspace, we do report ranges that look like single ports into the Ports slice
<dimitern> voidspace, and that imo is backward-compatible with older clients
<Muntaner> dimitern: still fighting with images metadata
<Muntaner> can you give me some advices?
<dimitern> Muntaner, have you tried following that section about generating images metadata for private clouds in that docs page?
<dimitern> fwereade, ping
<Muntaner> yes, totally
<dimitern> Muntaner, so how far did you manage to go down that path?
<Muntaner> dimitern: brb in 2 hours
<dimitern> Muntaner, sure
<Muntaner> bye :)
<jam> dimitern: pong
<dimitern> jam, hey, I've noticed I'm not an admin on LP ~juju so I can't add james to it, can you make me an admin please?
<jam> dimitern: just did both of those things
<jam> fwereade: I'm back around
<dimitern> jam, thanks!
<jam> dimitern: you may want to independently confirm it :)
<dimitern> jam, just did
<dimitern> fwereade, all sorted, please ignore last ping
<dimitern> voidspace, ah, sorry - now I got what you're asking
<dimitern> voidspace, and that seems fair, rather than dropping ports add them individually, however that potentially means blowing up the response size with large ranges for the sake of older clients, which will have a few individual ports opened anyway
<voidspace> dimitern: ah, ok - so you don't need to "detect older clients" as that's what compatiblePorts is for anyway
<voidspace> dimitern: but if the older client wants to know open ports then shouldn't we tell them?
<dimitern> voidspace, yes, the older clients will expect Ports to be populated
<voidspace> my chat window isn't scrolling dammit
<voidspace> that's why I missed your replies
<dimitern> voidspace, ah, sorry :)
<voidspace> dimitern: not your fault...
<voidspace> dimitern: but if we have a port range open then we won't tell an older client about it
<voidspace> dimitern: is it alright to just not tell them?
<voidspace> rest of the PR looks fine including tests
<dimitern> voidspace, older clients won't use ranges, so if they did open 50, 51, and 52.. hmm I have to check this
<jam> voidspace: you're thinking to map the range into each entry for compat ?
<voidspace> jam: if 50:52 is open report 50, 51, 52
<voidspace> jam: i.e. tell the truth...
<jam> dimitern: I don't know that we need to collapse individual requests into a range, but we should probably return the individual items if a new client opened a range
<jam> voidspace: right
<dimitern> I think the current behavior is to collapse consecutive ports into a range, so that'll become 50-52
<dimitern> jam, yeah, ranges are always there
<jam> voidspace: dimitern: I don't particularly care if we collapse or not, it depends heavily on the close behavior
<jam> IIRC there was a discussion as to whether you have to exact match in a  close request
<dimitern> jam, however, if a newer client opens 5000-6000/tcp and if we list each port individually for the sake of older clients - guess how big the response will be :)
<jam> so if a client does Open(50), Open(51), Open(52), then Close(50) must also work
<jam> whether we represent that as 3 open ports or a range of 50-52
<jam> dimitern: no bigger than it is today
<dimitern> jam, but it's much easier to open a huge range with one command today
<voidspace> how many bytes is a serialised port struct?
<jam> dimitern: again, this is about compatibility
<jam> we deal with it
<voidspace> a few bytes from the look of it
<jam> new clients won't call the old method
<dimitern> voidspace, {{Number: 123, Protocol: "tcp"}} x number of ports
<voidspace> so a thousand is a few kilobytes
<jam> dimitern: voidspace: so yeah, unless there is a really strong problem, I'd just go with "expand port ranges for the compatibility code"
<jam> *especially* if we are auto upgrading
<jam> if you did
<jam> Open(50), Open(51)
<jam> then you better get 50, 51 from "list-open-ports"
<voidspace> dimitern: I'm failing to trigger the error conditions to test the charmrevisionupdater change
<voidspace> dimitern: I think we're using a mock api (haven't confirmed that) so setting the env variables fails to cause an error
<dimitern> voidspace, I'd just mock the updateVersions call to trigger a failure in the test and check the worker exits
<voidspace> dimitern: ok will do, thanks
<jam> voidspace: dimitern: does my last point make sense? I could sort-of be convinced that if you did a request for a Open 50:52, then maybe the compatible list-ports wouldn't return it (maybe), but *definitely* if we are automatically turning a request for 2 ports to be opened into a range, then we *must* turn a range back into individual items on a list response
<jam> fwereade: are you around yet?
<dimitern> jam, voidspace, ok, I'll do that instead - return all individual ports in ranges
<voidspace> cool
<voidspace> going on lunch
<fwereade> jam, heyhey, yes I am
<jam> fwereade: I should really go help my son for a sec, but I realized I've been sitting in the room for 30 min and missed the earlier ping. I still want to go over the diff with you, how about in 10 min?
<fwereade> jam, sgtm
<dimitern> jam, if you do open(50), open(51), open(52), then close(51), you'll see 50 and 51 as ports in both slices, but if you do open(50-52) you can't close(51)
<jam> dimitern: then why represent it as 50-52 if you can't close it? Is it just a display thing that aggregates the range?
<dimitern> at least I think you can't - must check the code
<jam> dimitern: I'd really rather not have list return things that you can't then use for close
<dimitern> jam, because we're representing it as a range, not individual ports
<jam> because I have the feeling that given what you've said
<jam> if you do Open(50), 51, 52. and then you do list and get 50-52, but you can't close(50:52) that's bad
<dimitern> jam, opened-ports hook tool will return ranges as specified in open-port
<jam> dimitern: do you understand my concern?
<jam> open + opened + close should all work nicely together
<dimitern> jam, however, if you called open-port 3 times with consecutive numbers, opened-ports will return a collapsed 50-52 range
<jam> changing under the hood is fine, as long as close can still interoperate
<jam> open 50, open 51, open 52, => you must be able to close 51
<jam> I think we agree on that
<jam> opened => 50:52, you must be able to close 50:52
<jam> does that also sound sane ?
<dimitern> jam, yes, and that's how it works for both cases you mention
<jam> dimitern: but open 50, open 51, open 52, then opened returns 50:52, but you can't close 50:52
<jam> because it doesn't match an open() request
<dimitern> jam, however the mix of the two - open-port 50-52/tcp then close-port 51/tcp won't work, but opened-ports I believe will return collapsed ranges for the first case (open 50,51,52 individually)
<dimitern> jam, I have to double-check that case
<jam> dimitern: if I do open(50), open(51), open(52) can I close(50-52) /
<jam> ?
<dimitern> anyway, I *really* need to go now to catch the bank before it closes
<jam> I *must* be able to close what I open
<dimitern> jam, I'll verify this as well
<jam> and I *must* be able to close what opened returns
<jam> as long as those two hold true, I don't have a huge care for collapsing vs not
<dimitern> jam, I agree, and will double check all these cases, then get back to you (tomorrow perhaps)
<mgz> dimitern: is there anything else we want to do on the goose repo, before moving it to go-goose? the tests pass locally, I didn't try using it as a replacement with juju-core though
<dimitern> mgz, well, there will be a few bits we can add post-migration, like CONTRIBUTING.md, README.md, stuff like that
 * dimitern goes out, bbl fwiw
<jam> fwereade: so now I have to do dinner, etc. Are you going to be around later? If you're EOD, then maybe we can just pick up tomorrow?
<fwereade> jam, I expect I'll be around later, but likely to be off and on slightly at random once laura's home (not so long from now...)
<Muntaner> hi devs
<Muntaner> hi dimitern, fwereade
<fwereade> Muntaner, heyhey
<fwereade> Muntaner, I should be able to concentrate for a little bit
<fwereade> Muntaner, what's the latest?
<Muntaner> fwereade: I have fresh logs for you
<Muntaner> I "downgraded" the iso of cloud server to try a workaround
<Muntaner> and get these logs
<Muntaner> fwereade:
<Muntaner> http://paste.ubuntu.com/10143346/
<Muntaner> envs.yawl -> http://paste.ubuntu.com/10143360/
<Muntaner> fwereade: the VM is successfully created on the openstack
<Muntaner> and does all the apt-get stuff
<Muntaner> as far as I can see in the logs, it's able to run MongoDB
<Muntaner> but then... that odd error
<Muntaner> need more background, fwereade ?
<Muntaner> fwereade: hard to fix, right? :)
<fwereade> Muntaner, yeah, I'm scratching my head and hunting through code
<Muntaner> fwereade: is this a mistake in my environment or it's actually juju failing?
<fwereade> Muntaner, I can't quite figure that out yet, still digging
<fwereade> Muntaner, I'm a little suspicious about your image-metadata-url (and tools-), though -- I thought you were in an isolated environment?
<Muntaner> fwereade: the thing I can't figure is: how do openstack now which image should instance in the VM if actually fetching of metadata fails?
<Muntaner> well fwereade - I'm with my laptop, connected to the openstack server via Lan (10.0.0.0/24)
<Muntaner> both the machines can naturally go on the internet (the VM created by juju can actually use apt-get stuff)
<Muntaner> I can access VMs via floating IPs, I can ping, ssh them
<Muntaner> and naturally, also the server is contactable
<fwereade> Muntaner, yeah, that's what's weird -- I can't figure out what you would have started (ie how you got far enough to fail that way)
<fwereade> Muntaner, ah, ok, I think I see some of it
<fwereade> Muntaner, with the --metadata-source param you shouldn't need those urls in environments.yaml
<fwereade> Muntaner, what happens if you just remove them?
<Muntaner> you mean - them in envs.yawl?
<fwereade> Muntaner, yes
<Muntaner> fwereade: trying it
<fwereade> Muntaner, I *think* that we're automatically uploading what you need to the right place, but it's not even looking there because it trusts the fields in environments.yaml
<dimitern> sinzui, ping
<fwereade> Muntaner, if that works, thank you for finding a bug -- we should at least fail earlier and more clearly if there's no way to sanely handle both those settings
<sinzui> hi dimitern
<Muntaner> fwereade: not working :(
<Muntaner> seems quite the same log
<dimitern> sinzui, hey, so re bug 1416928
<mup> Bug #1416928: juju agent using lxcbr0 address as apiaddress instead of juju-br0 breaks agents <api> <lxc> <network> <juju-core:Triaged> <juju-core 1.21:Triaged> <juju-core 1.22:Triaged> <https://launchpad.net/bugs/1416928>
<Muntaner> fwereade: http://paste.ubuntu.com/10143716/
<Muntaner> fwereade: envs.yawl -> http://paste.ubuntu.com/10143723/
<dimitern> sinzui, thanks for providing more info
<dimitern> sinzui, however, I think we shouldn't block 1.21.2 for this bug, I had a chat with xwwt and alexisb in cape town that we can possibly do a subsequent point release with this
<alexisb> sinzui, that is correct
<dimitern> sinzui, but I'm interested to hear your thoughts as well
<xwwt> dimitern, sinzui:  We should not block 1.21.2 on this one.  We can point release later.
<fwereade> Muntaner, hmm, I need to dig a bit further, but glad to see you can still launch an instance withoutthose fields
<Muntaner> yep fwereade, but I had to add upload-tools, since I got another error without it
<Muntaner> I'm somewhat confused
<sinzui> dimitern, I am concerned about multiple releases. But I know stakeholders will appreciate your fix for bug 1416134
<mup> Bug #1416134: Unable to override network-bridge if container type is kvm (local provider) <cloud-installer> <config> <lxc> <network> <regression> <cloud-installer:Fix Committed by adam-stokes> <juju-core:Fix Committed by dimitern> <juju-core 1.21:Fix Committed by dimitern> <juju-core 1.22:Fix
<mup> Released by dimitern> <https://launchpad.net/bugs/1416134>
<sinzui> dooferlad, is your fix for bug 1417617 queued for 1.21?
<mup> Bug #1417617: apt-proxy can be incorrectly set when the fallback from http-proxy is used <apt> <network> <proxy> <juju-core:Fix Committed by dooferlad> <juju-core 1.21:In Progress by dooferlad> <juju-core 1.22:In Progress by dooferlad> <https://launchpad.net/bugs/1417617>
<dimitern> sinzui, yes, that fix among a few other as well - it's still worth releasing 1.21.2
<dooferlad> sinzui: Hopefully an hour
<dimitern> dooferlad, sweet!
<sinzui> dimitern, I will give dooferlad an opportunity get his fix merged and tested while I prepare for a 1.21.2 release to proposed
<dimitern> thank you sinzui!
<fwereade> Muntaner, ah, yes, makes sense
<fwereade> Muntaner, can I see the directory structure for your metadata source please?
<dimitern> which reminds me to finish the fix for bug 1418433
<fwereade> Muntaner, I think I see what's failing
<mup> Bug #1418433: unit ports not populated by API megawatcher <api> <regression> <juju-core:In Progress by dimitern> <juju-core 1.21:In Progress by dimitern> <juju-core 1.22:In Progress by dimitern> <juju-gui:Triaged> <https://launchpad.net/bugs/1418433>
<Muntaner> fwereade: how want me to show you that?
<Muntaner> well fwereade, I have just one folder generated
<Muntaner> which is /home/mike/juju-tools/images/streams/v1/
<Muntaner> into, I have two files
<Muntaner> index.json
<Muntaner> com.ubuntu.cloud:released:imagemetadata.json
<fwereade> Muntaner, for future reference: `tree -d /home/mike/juju-tools/`
<fwereade> Muntaner, can I see them both please?
<Muntaner> fwereade: sorry for my noobness :)
<fwereade> Muntaner, no worries :)
<Muntaner> yes fwereade, paste incoming
<Muntaner> fwereade: http://paste.ubuntu.com/10143826/
<fwereade> Muntaner, looks like tree is not necessarily installed, but it's very handy
<Muntaner> installing :)
<Muntaner> fwereade: tree is -> http://paste.ubuntu.com/10143835/
<fwereade> Muntaner, and because I wasn't thinking, if you just skip the -d, it'll give you files too
<Muntaner> fwereade: -> http://paste.ubuntu.com/10143855/
<Muntaner> commands used: juju metadata generate-image -a amd64 -i 662d6b37-2c1b-42c3-9bd7-6f1c3ab5af50 -r RegionOne -s trusty -d /home/mike/juju-tools -u http://10.0.0.230:5000/v2.0 -e OpenStack
<Muntaner> juju metadata validate-images -d /home/mike/juju-tools
<fwereade> Muntaner, yeah, that looks right, and it looks like we're not uploading it properly :-/
<Muntaner> fwereade: may this be a network problem of my architecture?
<fwereade> Muntaner, can the cloud instances see your laptop? as a quick-and-dirty hack, you could serve that dir over http...
<Muntaner> fwereade: yes, obviosly they can
<Muntaner> they can ssh, ping my laptop and - I think - all the devices in 10.0.0.0/24
<fwereade> Muntaner, ok, you could try opening a new terminal and running `python -m SimpleHTTPServer` in your metadata source dir, and specifying that URL in your environments.yaml
<Muntaner> socket.error: [Errno 98] Address already in use
<bodie_> fwereade, looking for confirmation whether `action do` CLI arg values should be parsed as yaml -- I'm thinking yes
<fwereade> bodie_, hmmmmm I don;t think we should be parsing anything as yaml that's not explicitly marked as such
<bodie_> juju action do mysql/0 sleep time=1000 "time is supposed to be a number"
<bodie_> not the greatest ux
<dimitern> voidspace, still around?
<fwereade> bodie_, agreed, but if we're not careful "y" will parse to `true` and so on
<bodie_> hmm, yeah
<bodie_> fwereade, in that case the validation would reject it with a message; then the user could pass signal="y", right?
<fwereade> Muntaner, `python -m SimpleHTTPServer <some-unused-port>`?
<fwereade> bodie_, that is true
<dimitern> frankban, ping
<frankban> hi dimitern
<fwereade> bodie_, ok, yes, I think you're right
<Muntaner> Serving HTTP on 0.0.0.0 port 60000 ...
<Muntaner> fwereade:
<fwereade> Muntaner, ok, cool
<dimitern> frankban, hey, thanks for the review on http://reviews.vapour.ws/r/891/ - can you please also review and approve http://reviews.vapour.ws/r/890/ (the original fix for 1.21) and http://reviews.vapour.ws/r/892/ (foreport of the same fix for trunk, 1.23)
<Muntaner> fwereade: nothing more is coming
<Muntaner> is it hanging?
<bodie_> fwereade, my reasoning is that with action-set it's more important for values to come back to the user exactly as they were set for the purpose of reporting accurately
<Muntaner> never used this command
<bodie_> thanks, I'll open a quick PR
<fwereade> Muntaner, you should be able to specify image-metadata-url as http://your-laptops-ip:60000/images
<Muntaner> ok fwereade
<fwereade> Muntaner, and go back to streams.c.c for tools-metadata-url (sorry, I'd thought you had tools metadata generated locally)
<fwereade> Muntaner, then cross your fingers and try again
<fwereade> Muntaner, (but with tools-m-u you shouldn't need --upload-tools)
<Muntaner> fwereade: what do you mean with "go back to streams.c.c." ?
<fwereade> Muntaner, sorry, specify `tools-metadata-url: streams.canonical.com`
<frankban> dimitern: sure
<dimitern> frankban, thank you!
<fwereade> Muntaner, you had that before and I erroneously told you to drop it
<Muntaner> so fwereade
<Muntaner> fwereade: http://paste.ubuntu.com/10144073/
<Muntaner> does it look fine?
<fwereade> Muntaner, I think so, maybe an https:// on streams.c.c :)
<ericsnow> rogpeppe1: do you think there would be any benefit to our direct HTTP request code in juju core from the httprequest repo code?
<Muntaner> ok did it
<voidspace> dimitern: yes
<Muntaner> fwereade: YOU'RE GREAT, WORKED! :D
<Muntaner> 2015-02-09 15:53:35 INFO juju.cmd supercommand.go:329 command finished
<fwereade> Muntaner, sweet!
<dimitern> voidspace, ah, it's ok just fyi - I changed the fix for the ports bug as you suggested
<fwereade> Muntaner, ok, so serving it from your laptop is not a production solution ;)
<fwereade> Muntaner, you'll want something a bit less temporary there
<voidspace> dimitern: I'll take a look
<dimitern> voidspace, ta
<Muntaner> fwereade: I'm just saying... have something to show to bosses :D
<fwereade> Muntaner, yeah, I know that feeling :)
<Muntaner> fwereade: now I'm trying to deploy juju gui
<dimitern> Muntaner, hey, can I ask you a favor :) summarize what eventually worked as a comment on the bug you had originally
<voidspace> dimitern: all the tests are for single port ranges
<voidspace> dimitern: oh no they're no
<dimitern> voidspace, except for one
<voidspace> *not
<dimitern> :)
<voidspace> dimitern: yeah, I misread
<voidspace> sorry
<dimitern> np
<Muntaner> dimitern: well, the only workaround that fixed the situation has been the Httpserver
<fwereade> Muntaner, you'll almost certainly want to `deploy --to 0` there fwiw
<Muntaner> dimitern: should I open a launchpad bug?
<dimitern> Muntaner, yes, I'd really appreciate if you do, and add comments about what you're trying to do and how you managed to resolve it
<dimitern> Muntaner, others might find it useful, and we can do something about making this easier in the future
<Muntaner> ok dimitern will do it
<Muntaner> thanks 10000
<rogpeppe1> ericsnow: depends how many http request kinds you've got
<dimitern> Muntaner, np, I'm glad we're able to help you and also thanks for all your patience! ;)
<ericsnow> rogpeppe1: basically 3: tools, charms, and backups (upload/download)
<fwereade> Muntaner, I've asked ericsnow to follow up on this and figure out why it wasn't working with just metadata-source -- but I'm pretty sure you've found a real bug, for which, much thanks :)
<rogpeppe1> ericsnow: in which case almost certainly not
<ericsnow> rogpeppe1: k, thanks
<voidspace> dimitern: LGTM
<voidspace> dimitern: have you forward ported as well yet?
<dimitern> voidspace, awesome! yes, I already asked frankban to have a look, but it's good to have another set of eyes - http://reviews.vapour.ws/r/891/ http://reviews.vapour.ws/r/892/
<voidspace> dimitern: 892 isn't showing the inner loop yet
<dimitern> voidspace, nope, I'm about to propose it
<voidspace> ok
<ericsnow> Muntaner: FYI, your troubles appear to be related to bug #1271744
<mup> Bug #1271744: bootstrap on maas with --metadata-source fails <bootstrap> <maas> <maas-provider> <upload-tools> <juju-core:Triaged> <https://launchpad.net/bugs/1271744>
<ericsnow> Muntaner: so I'll follow up there
<ericsnow> Muntaner: would you mind verifying that that matches the situation you ran into?
<natefinch> sinzui: you around?
<sinzui> I am
<natefinch> sinzui: alexis wanted me to work with you on blocking bugs... what's our current list?  I'm a little out of the loop.
<sinzui> natefinch, https://launchpad.net/juju-core/+milestone/1.21.2
<sinzui> natefinch, https://launchpad.net/juju-core/+milestone/1.22-beta3 has one extra bug that voidspace  is working on
<natefinch> wwitzel3: you're working on this one, right? https://bugs.launchpad.net/juju-core/+bug/1417875
<mup> Bug #1417875: ERROR juju.worker runner.go:219 exited "rsyslog": x509: certificate signed by unknown authority <canonical-bootstack> <logging> <regression> <juju-core:Triaged by wwitzel3> <juju-core 1.21:Triaged> <juju-core 1.22:Triaged> <https://launchpad.net/bugs/1417875>
<voidspace> natefinch: sinzui: so I believe that dimitern has already backported my fix to 1.22
<voidspace> natefinch: sinzui: let me double check and mark that as fix committed if it's done
<dooferlad> voidspace: Could you review http://reviews.vapour.ws/r/895/ please?
<voidspace> dooferlad: will do
<voidspace> natefinch: sinzui: hmm... looks like there's a slight error in the backport
<wwitzel3> natefinch: yep, sorry, replied in wrong channel
<Muntaner> ericsnow: dimitern fwereade sorry, was talking with my boss
<Muntaner> just in time, lol
<voidspace> dimitern: ping
<ericsnow> Muntaner: no worries :)
<dimitern> voidspace, hey
<voidspace> dimitern: you backported my proxyupdater fix to 1.22, right?
<voidspace> dimitern: because whoever did it unfortunately did it slightly wrong
<voidspace> dimitern: I'll fix
<natefinch> wwitzel3: cool, I just marked the 1.21 version of the bug as assigned to you too, so it'll be more obvious in the 1.21 list that it's actually being worked on.
<dimitern> voidspace, oh, my bad then - what happened?
<voidspace> dimitern: also, https://github.com/juju/juju/pull/1564
<voidspace> dimitern: handleProxyValues is called with a proxy.Settings object called proxySettings
<voidspace> dimitern: this is new settings
<voidspace> dimitern: in trunk we call SetEnvironmentVariables on that *before* setting it to s.proxy
<dimitern> voidspace, ah, ok - I must've overlooked that
<dimitern> voidspace, sorry :/
<voidspace> dimitern: the code in 1.22 calls s.proxy.SetEnvrionmentVariables()
<voidspace> dimitern: which is the *old settings*
<Muntaner> ericsnow: it doesn't seem to resemble my situation
<voidspace> dimitern: np
<dimitern> voidspace, I can't recall doing it though..
<voidspace> dimitern: someone did it
<Muntaner> actually I don't have tools-related-issues, but more image metadata issues
<voidspace> dimitern: maybe it was me :-)
<Muntaner> with HTTPServer workaround, it works
<dimitern> :)
<dimitern> voidspace, btw that 1564 PR's diff seems very wrong to me
<dimitern> "Showing with 6,842 additions and 2,087 deletions."
<voidspace> dimitern: hah, it's targetting master
<voidspace> that's why...
<voidspace> don't merge it...
<dimitern> :)
<dimitern> ok, I'll have a look later, but I gtg now
<voidspace> dimitern: I hope you've enjoyed your day off! :-o
<dimitern> :) I promise to try resting more tomorrow
<ericsnow> Muntaner: well, the maas part of it won't apply, but the problem they describe with a local metadata index does, right?
<frankban> dimitern: so you changed the branch so that all the ports are enumerated in unitInfo.Ports. this could lead to lots of bytes sent to the wire, but I agree this is technically correct. I think the GUI needs to swithc to useing PortRanges when possible, and recalculate real single ports on the client side.
<voidspace> frankban: a port is 7 or 8 bytes, so even for a thousand ports it's only 7-8kb.
<voidspace> frankban: so it depends what you mean by "lots of bytes"...
<frankban> voidspace: agreed
<Muntaner> ericsnow: sorry if I'm slow - doing 1000 things right now
<ericsnow> Muntaner: no worries, this isn't pressing (more of a follow-up to ensure we track the problem)
<Muntaner> ericsnow: yes, seems pretty similar
<Muntaner> ericsnow: actually, the workaround to make these metadata visible to the environment is to expose them via Http - since uploading isn't happening
<ericsnow> Muntaner: okay, I'll go from there, thanks
<Muntaner> ericsnow: just saying, nobody had tested an environment like mine before? :)
<voidspace> dooferlad: you don't add the trailing slash. Have you manually tested it?
<voidspace> dooferlad: if it works without it then fine...
<dooferlad> voidspace: yea, it works. This is just a backport.
<voidspace> ah, cool
<voidspace> dooferlad: LGTM
<voidspace> natefinch: care to take a look http://reviews.vapour.ws/r/898/
<voidspace> natefinch: this is for https://bugs.launchpad.net/juju-core/+bug/1403225 for 1.22
<mup> Bug #1403225: charm download behind the enterprise proxy fails <cloud-installer> <deploy> <proxy> <sync-tools> <cloud-installer:Confirmed for adam-stokes> <juju-core:Fix Committed by mfoord> <juju-core 1.21:Won't Fix> <juju-core 1.22:In Progress by mfoord> <https://launchpad.net/bugs/1403225>
<voidspace> wwitzel3: as you're OCR, if you have time could you look at this one http://reviews.vapour.ws/r/896/
<dooferlad> wwitzel3: Also, http://reviews.vapour.ws/r/895/ please
<voidspace> dooferlad: I already gave that a ShipIt
<dooferlad> voidspace: I thought I needed two reviews?
<voidspace> dooferlad: no
<voidspace> :-)
<dooferlad> voidspace: OK :-)
<dooferlad> wwitzel3: forget that then!
<Muntaner> ericsnow: fwereade : juju is amazing, I'm deploying stuff easily as nothing :)
<natefinch> voidspace: ship it
<ericsnow> Muntaner: awesome! :)
<Muntaner> ericsnow: but bosses are asking strange stuff... argh, dunno if I can do it via juju
<natefinch> Muntaner: you can do anything with Juju, just a matter of figuring out how ;)
<Muntaner> natefinch: well, they're talking about an existing .net application which is using Windows Azure... maybe we should do a sort of porting, :S
<natefinch> Muntaner: we do support deploying to windows, though it takes a little setup right now
<voidspace> natefinch: thanks
<natefinch> (and I'm being generous with "a little")
<Muntaner> natefinch: I don't have the whole plot clear right now
<natefinch> sinzui: The comments on this bug seem to say it's been that way  for almost a year ... https://bugs.launchpad.net/juju-core/+bug/1417449
<mup> Bug #1417449: Log files now owned by syslog user, 1.21.1 <canonical-is> <logging> <regression> <juju-core:Triaged> <juju-core 1.21:Triaged> <juju-core 1.22:Triaged> <https://launchpad.net/bugs/1417449>
<Muntaner> seems like I should use a VM with Windows Server + Juju
<Muntaner> sooo... OpenStack + Windows Server + Juju
<natefinch> jw4: saw your comment on the above bug...
<sinzui> natefinch, it certainly has been for many many months. also...
<voidspace> who owns juju team calendar. jamestunnicliffe needs adding to it.
<voidspace> natefinch: ^^ any idea?
<sinzui> natefinch, If our policy is use juju debug-log to see the logs, then wont fix is a valid close
<natefinch> sinzui: in general I think the right answer is for local provider to behave like the rest of the providers.... which I sort of assume also have the logs owned by syslog
<sinzui> natefinch, +1, We mark it wont fix and we are done
<natefinch> sinzui: seems fine to me.  I'll comment and do so
<Muntaner> natefinch: actually, what is the relationship between juju and windows?
<natefinch> Muntaner: not sure what you're asking.  Juju can deploy to Windows machines, though right now it takes some special setup.
<Muntaner> ok natefinch, that's an answer :) what do you mean with "special setup" ?
<natefinch> Muntaner: when you use juju to add a machine to your environment (whether through juju add-machine or as a part of juju-deploy), it figures out what image to use for the machine by looking for metadata in a simple-streams location.  For Linux images, this is available on all the clouds Juju supports.  However, for Windows, we don't yet have those metadata files available in the clouds.  You also need the images themselve
<natefinch> s, which need to have a special init system installed on them (cloud-init by Cloudbase) so that we can bootstrap the images appropriately.
<natefinch> Muntaner: setting this up in your own maas or openstack environment is not too hard, but if you want to deploy to a public cloud, it gets a lot trickier
<natefinch> Muntaner: sorry, there's no simpler way to answer the question.  Basically... getting windows images to boot up is harder because they're not free and open source like linux
<Muntaner> natefinch: why this difference in difficulty from private to public?
<Muntaner> natefinch: lol, very clear :)
<natefinch> Muntaner: you control everything in your private cloud, so it's easy to set up all the right urls, image locations, etc.  You don't control everything on Azure/AWS/etc, so it's harder.  I am actually not 100% sure if you can even do it on a public cloud right now.
<Muntaner> natefinch: thanks for the patience :)
<Muntaner> you guys have been very gentle with me
<Muntaner> a lot of thanks, natefinch, ericsnow, fwereade
<Muntaner> maybe I'll be back there for future problems :)
<natefinch> Muntaner: if you'd like a full report on how to do enable windows support for juju from an expert, I can set that up.
<Muntaner> natefinch: this will be a task of the next days :)
<Muntaner> bye guys
<voidspace> juju branch
<voidspace> no that's wrong
<voidspace> go branch
<voidspace> no that's wrong too
<voidspace> git branch
<voidspace> ah yes, that's what I was doing...
<voidspace> one of those afternoons...
<mgz> :D
<natefinch> voidspace: yeah, I keep thinking I should make an uber-command that'll just delegate to the right one based on subcommand... there's only a couple overlaps
<perrito666> I keep telling myself I need to alias got to git
<voidspace> natefinch: do it :-)
<perrito666> I hate when shims keep growing
<wwitzel3> perrito666: the guy who installed the door frames in my old house didn't have that same concern
<voidspace> :-)
<voidspace> wwitzel3: how's the house?
<perrito666> lol
<voidspace> the new one I mean...
<wwitzel3> voidspace: great :) .. we spent this weekend taking the guest bathroom down to studs and subfloor
<wwitzel3> voidspace: is your deal all final on your new house?
<voidspace> wwitzel3: signed and returned all the paperwork. Hoping to get a completion date tomorrow and the keys Friday or Monday.
<voidspace> wwitzel3: so not quite all final yet...
<voidspace> wwitzel3: you got a lot of work to do on the house?
<perrito666> wow that is FAST
<voidspace> perrito666: we made the offer about four weeks ago and have pushed really hard to get it done
<voidspace> perrito666: for the UK that is really fast
<wwitzel3> voidspace: not a lot .. just the most expensive parts :) both bathrooms and the kitchen are getting completely redone.
<voidspace> wwitzel3: yow, sounds expensive
<voidspace> thankfully we don't *think* we need to do anything like that
<voidspace> mostly buy a new kitchen table and some wardrobes
<wwitzel3> voidspace: yeah, it wasn't a suprised at least, we knew going in which makes it easier
<perrito666> we require a "research" made on the house for possible debts and all kinds of judiciary problems and that alone takes a month, then you have a... mm I dont think there are these people elsewere, they are guys that bear witness of a contract and record it in national records and sign making it valid, well one of those crafts new papers for the howse (usually including the previous papers) so basically a houses paper
<perrito666> are like a git repo :p
<voidspace> wwitzel3: you done any forward porting of bugs from 1.21/1.22 ?
<voidspace> I forget the procedure
<voidspace> do I merge just the specific revisions
<perrito666> and after that your house is yours but you still need to wait for that to get updated in all the right places for like 6 months
<wwitzel3> voidspace: it has been a while, I will have to do it with my current one, once it is fixed though. sinzui can you point us to a doc or steps for forwarding porting of fixes?
<voidspace> perrito666: we have a lot of searches to do too (environmental, land registry etc) but they can be done in a couple of weeks with good solicitors
<voidspace> perrito666: our land registry doesn't have "branches" though, just a mainline
<voidspace> so searches are easier
<perrito666> voidspace: I think here is mostly due to the lack of digital information
<voidspace> and all charges (debts) are recorded with the land registry
<voidspace> perrito666: land registry is still all paper
<wwitzel3> perrito666, voidspace: our process is as quick as the sellers and buyers want it to be really .. our house was 30-days, my parents just did a cash deal with a 72-hour closing.
<voidspace> nice
<wwitzel3> I would say the average is 45-60 days
<perrito666> wwitzel3: I assume there is not much paperwork right?
<natefinch> wwitzel3: buyers, sellers, and banks (where it's not cash, which is most of the time)
<sinzui> wwitzel3, I don't think core ever wrote a doc about git patch
<perrito666> I am already in love on how you guys sell cars, I assume houses are pretty much the same
<natefinch> perrito666: there's a ton of paperwork, but that's what lawyers are for.  I paid ~$500 for a lawyer to basically do all the annoying work for us when we bought our house.
<sinzui> wwitzel3, and I am just assuming git patch is the technique to extract and apply changes between divergent branches
<voidspace> sinzui: so it's just a manual process to forward port
<sinzui> voidspace, 'fraid so
<voidspace> np
<perrito666> natefinch: here we pay a percentage (quite high given the numbers at play) to the notary (that was the word I was missing)
<perrito666> and then a fee for each research to be done
<perrito666> then a couple of taxes for all these papers to be sealed by the right authorities
<perrito666> :p
<perrito666> same applies for cars
<perrito666> between the day I paid my car in the dealership and the day I got it there where around 2 months
<voidspace> sinzui: I've marked but 1403225 as fix committed for 1.22
<voidspace> https://bugs.launchpad.net/juju-core/+bug/1403225
<mup> Bug #1403225: charm download behind the enterprise proxy fails <cloud-installer> <deploy> <proxy> <sync-tools> <cloud-installer:Confirmed for adam-stokes> <juju-core:Fix Committed by mfoord> <juju-core 1.21:Won't Fix> <juju-core 1.22:Fix Committed by mfoord> <https://launchpad.net/bugs/1403225>
<sinzui> thank you voidspace
<natefinch> perrito666: we pay a percentage to the real estate agents (2-3% for the buyer's agent and same for seller's agent), which is a shame, because they don't actually do all that much in this age of looking for houses on the internet.
<hazmat> natefinch: +1 insanity..
<voidspace> natefinch: in the UK pretty much everyone uses one website, rightmove, to find houses
<perrito666> well at least I dont have to blow snow :p
<voidspace> natefinch: but you have to be an estate agent to put houses up there, so they keep the cartel going
<perrito666> real estate agents are not a mandatory thing here,  just practical
<natefinch> voidspace: yep, basically the same here.... there's one official listing that several online sites use,  but you need to be in their cartel to put things up there.
<hazmat> natefinch: redfin is slightly disruptive to the industry with lower fees.. also re agent commissions, seller pays costs. there are many listings, only need a real estate agent for mls listing.
 * hazmat has been house shopping lately
<natefinch> hazmat: yep, I bought my house through redfin.  Loved it, got a ~$5k check afterward IIRC
<hazmat> nice
<natefinch> hazmat: It's kinda lucky, because they don't cover everywhere, but the town I wanted to buy in is pretty expensive, so they cover it, but not many of the nearby towns.
<natefinch> hazmat: at least as of 5 years ago when I purchased
<perrito666> natefinch: so why exactly you get money for buying a house?
<perrito666> usually is the other way around
<natefinch> perrito666: the seller pays the buyer's real estate agent 2%, and the seller's real estate agent 2%.... redfin is the buyer's agent, and they turn around and give the buyer 1/2 to 2/3rds of their commission
<natefinch> 333333333333333333
<natefinch> (sorry..... kids)
<perrito666> sounds a bit like commercial .. dis?loyalty? I dont know the word for it in english
<perrito666> although I believe middle men are just blod suckers so I have nothing against it
<natefinch> perrito666: yep.  in theory you don't need a real estate agent, but if you can't get your house listed on The_List_Everyone_Looks_At then no one will see your house is for sale.
<perrito666> we call that list "the paper classified adds" you get in there for a whole week for about 80C
<perrito666> and for free in the paper internet site :p
<perrito666> there is a bad part to it, you need to live in this country
<voidspace> g'night all
<voidspace> EOD
<bodie_> godeps: cannot update "/var/lib/jenkins/workspace/github-merge-juju/tmp.hkAIMyHVpG/RELEASE/src/golang.org/x/crypto"
<bodie_> :S
<bodie_> fatal: remote error: Git repository not found
<bodie_> that doesn't seem right
<bodie_> whatever it was, seems to have worked this time
<marcoceppi> Looking for a juju architect to explain some things to me
<fwereade> marcoceppi, heyhey
<natefinch> man, it's like rubbing a genie's bottle
<marcoceppi> fwereade: my favorite architect (who happened to repsond to me first)
 * marcoceppi goes to PM
<bodie_> was anyone working on a Docker Actions enabled charm?
 * perrito666 rubbs his cheap wather bottle and all he gets is a sale's rep
<perrito666> natefinch: seems marco has more luck
<cherylj> Could someone review a PR I have for juju/cmd?  https://github.com/juju/cmd/pull/13
<katco> wwitzel3: ^^
<cherylj> thanks, katco
<katco> cherylj: np, you know about the OCR schedule, right?
<lazyPower> bodie_: o/
<cherylj> yes, but I swore today was Tuesday and I didn't see natefinch online
<cherylj> Guess I'm still on NZ time
<lazyPower> bodie_: we've been looking into it with the docker infrastructure bundle we threw down, anything specific i can answer?
<katco> cherylj: haha :)
<katco> cherylj: i hope your trip went well
<lazyPower> katco: if i want to track down someone that grokks the jujud on ppc64el who would i pester? :)
<cherylj> katco:  it was great!  I learned a lot and had a great time getting to know everyone
<katco> lazyPower: i think davecheney is our resident ppc expert
<lazyPower> perfect, ta
<katco> lazyPower: possible thumper?
<katco> cherylj: good to hear :D
<katco> lazyPower: they are both in AUS/NZ time, so they should be on later
<lazyPower> already passed on the info. cheers katco :)
<katco> lazyPower: o/
<bodie_> lazyPower, just curious since I'm working with actions :)
<lazyPower> awesome, we're looking at supercharging the docker charms with action support, such as image cleanup, getting running containers, status output, health checks, etc.
<lazyPower> there's quite a bit that's been tossed around but nothing yet, and I'm a pleb that doesn't run off tip yet - so actions haven't landed as of yet
<bodie_> lazyPower, right on.  maybe I could contribute?  I guess your charm in LP is the latest?
<bodie_> I just want something flashy to show off
<bodie_> but I'm also really interested in working with Docker
<lazyPower> ah, actually our dev focus is on github. let me fish up the bundle for you
<lazyPower> https://github.com/mbruzek/docker-bundle
<lazyPower> its in the revq atm pending eyeballs, but dev focus is there :)
<lazyPower> bodie_: if you have *any* issues with the docker bundle we have - feedback/prs/bugs accepted with open arms and a puppy.
<lazyPower> i'm using it in prod with success, but its still only 1/8 of the story that we want to tell with docker.
<wwitzel3> cherylj: taking a look at that PR now
<cherylj> wwitzel3, thanks!
 * perrito666 is back
<bodie_> lazyPower, excellent :)
<davecheney> lazyPower: ping
<lazyPower> davecheney: pong
<davecheney> lazyPower: you rang ?
<lazyPower> davecheney: besiner is looking for a ppc64el expert, there's a backlog of jujud issues he's uncovered orchestrating ppc from an amd64 host.
<lazyPower> http://paste.ubuntu.com/10145407/
<davecheney> that's pretty messed up
<davecheney> has /var/lib/juju/tools/machine-1-lxc-1/jujud
<davecheney> been replaed with a shell script ?
<lazyPower> beisner: ping
<lazyPower> ^
<davecheney> lazyPower: protip: this is how I debug ppc64el issues
<beisner> yo!
<davecheney> 1. were the tools found ?
<davecheney> 2. did they download properly
<beisner> o/ lazyPower davecheney
<davecheney> 3. there is no three
<davecheney> that's it
 * perrito666 sees a paradox
<beisner> lazyPower, davecheney - getting repro scenario documented for review.
<beisner> hi davecheney, lazyPower - please see  http://paste.ubuntu.com/10149580/.  no bug filed yet.  i'm US central time, can touch base in a few hrs after dinner/family time.
<davecheney> beisner: juju bootstrap --constraints arch=amd64 || true
<davecheney> ^ why are you skipping this error ?
<beisner> davecheney, no error there.  i had that because i had already just bootstrapped.
<beisner> ie. a cheap "bootstrap if not bootstrapped" line
<davecheney> ok
<davecheney> beisner: can you paste the contents of the upstart control file for machine-1-lxc-3
<beisner> davecheney, please get more verbose, where is that?
<beisner> lol
<davecheney> i want to rule oout a typo or syntax error in the upstrart file
<davecheney> that errror loooks like it's coming from a shell
<beisner> path i should look in?
<davecheney> /var/init
<davecheney> sorry
<davecheney>  /etc/init
<davecheney> but i have no idea what that looks like when lxc is applied
<beisner> oh ok that's where i'm looking
<davecheney> it might be called something like
<davecheney> jujud-machine-1-lxc-1
<davecheney> but i'm not sure
<davecheney> 'cos lxc
<beisner> jujud-machine-1-lxc-3.conf ->  http://paste.ubuntu.com/10149660/
<beisner> gotta run, will return in a bit.
#juju-dev 2015-02-10
<davecheney> thumper: wanna shoot for a 1:1 today  ?
<beisner> hi davecheney - what do you think?  are we trying something too crazy?
<davecheney> beisner: deploying anything to machine 0 is crazy
<davecheney> but that isn't the problme
<davecheney> best I can tell the error is coming from upstart
<beisner> davecheney, lol.
<davecheney> deploying units to machine 0 has been responsible for 100% of customer data loss
<beisner> davecheney, good to know.   fwiw, this is related to automated deployment testing, and we do that only for density.  the whole enviro gets torn down after openstack tempest tests run.
<beisner> what else do you think, aside from our crazy unit 0 ways?  ;-)
<davecheney> the error is coming from upstart
<davecheney> can you make an issue and attach the raw file from upstart
<davecheney> the one you pasted
<davecheney> it has to be the raw file
<davecheney> i suspect there is some control characters or other whitespace crap in there that is throwing off upstart
<beisner> davecheney, yes, i'd be happy to.  will ping you in a bit.
<thumper> davecheney: yeah, how about after lunch your time?
<beisner> davecheney, so that's getting interesting (copying the raw file) with the 1/lxc/3 having "no internal address."
<beisner> ahh never fear.  there's always /var/lib/lxc/juju-machine-1-lxc-3/rootfs/etc/   ... grabbing it.
<beisner> davecheney, https://bugs.launchpad.net/juju-core/+bug/1420049
<mup> Bug #1420049: jujud: Syntax error: word unexpected (expecting ")") <openstack> <uosci> <juju-core:New> <https://launchpad.net/bugs/1420049>
<thumper> menn0: the more I think about it, the more I reckon the services running on the api server machines on behalf of another environment should not appear in the other environment log, but in the state server environment log
<menn0> thumper: I guess that sort of makes sense
<thumper> which does keep things much simpler
<menn0> thumper: but if I was investigating a problem within an environment I might want to see those logs...
<thumper> well, you'd have to ask
<thumper> :)
<thumper> I think we should definitely have some way to record which env certain logs are for...
<menn0> thumper: but if I was a user with access to an env, but not the state server env then I wouldn't be able to
<thumper> but probably as part of the module
<thumper> exactly
<thumper> I don't think this is a bad thing
<menn0> thumper: it's certainly safer that way
<thumper> much safer
<thumper> and a good starting position
<menn0> thumper: for a user like that, the state server should probably be a black box
<thumper> I'm prepared to be convinced that we may want to change in the future
<thumper> but as a solid well defined starting position
<thumper> the state server for other environments is as you just mentioned, a black box
<menn0> thumper: you've convinced me :)
<thumper> menn0: lets start with that assumption then
<thumper> and document decisions
<menn0> thumper: not state server... JES
<thumper> sure
<thumper> axw: hey, updated http://reviews.vapour.ws/r/864/diff/#
<axw> thumper: looking
<axw> thumper: LGTM
<thumper> axw: ta
<thumper> axw: the expected behaviour is that if you created a new environ config instance with New, then it will fail if there is already one with the same noe
<thumper> name
<axw> thumper: ok, I'm just looking at the contract of EnvironInfo specifically
 * thumper scratches his head
<axw> thumper: I think it needs clarification
<axw> not a big deal
<thumper> also... all likely to change soon
<axw> :)
<thumper> you have me wondering now...
 * thumper looks
<thumper> I had to change the memory implementation to check for created and !initialized in order to get the second write working while failing two news
<thumper> and thought that the check should be the same with the disk implementation
 * thumper looks again
<thumper> hmm...
<thumper> I thought I tested that
<thumper> just using !iniitalized in both places does work
 * thumper goes with simpler
<mattyw> morning all
<mattyw> davecheney, ping?
<axw> anastasiamac: https://github.com/juju/errors/pull/17 please
<mattyw> anastasiamac, and when you're done with that would you mind taking a look at this one http://reviews.vapour.ws/r/903/ :)
<anastasiamac> axw: done but m not graduated :D
<axw> thanks
<anastasiamac> mattyw: np - m going thru another one of axw
<axw> thumper: teeny weeny change to errors, would you mind? https://github.com/juju/errors/pull/17
<anastasiamac> mattyw: it's a lot of fun - storage - it' s huge
<anastasiamac> mattyw: but will be done soon and will look at urs :D
<mattyw> anastasiamac, wnjoy that - mine is just a backport of a pr that landed yesterday so should be simpler :)
<anastasiamac> mattyw: sure thing :D
<thumper> axw: done
<thumper> davecheney: still want to do a 1:1?
<mattyw> anastasiamac, and one more - I've tried to make it as trivial as possible
<mattyw> anastasiamac, .... and here's the link: http://reviews.vapour.ws/r/904/ :)
<anastasiamac> mattyw: i will .. thnx :D
<mattyw> anastasiamac, you'll struggle to find a simpler one than /r/904 - ever I think
<anastasiamac> mattyw: :D i'll let u know where it is on my scale...
<axw> thumper: thanks
<anastasiamac> mattyw: out of interest, where r the credentials for metrics set?
<anastasiamac> mattyw: and yes, 904 is trivial. the only that would beat it, would a punctuation/typo correction ;D
<anastasiamac> mattyw: urs takes the rpize
<anastasiamac> prize*
<mattyw> anastasiamac, they're set here https://github.com/juju/juju/blob/master/state/unit.go#L1790
<mattyw> anastasiamac, it's one level up from the todo in the scheme of things
<anastasiamac> mattyw: ah
<mattyw> anastasiamac, but it makes everything much easier
<anastasiamac> mattyw: thnx :D
<bodie_> hmmmm; so I'm told the table test approach is hard to debug and I shouldn't use it except for trivial cases?
<bodie_> just want to get confirmation of that
<bodie_> i.e., for i, test := range []struct{...}{...}{do some tests on test}
<thumper> bodie_: hey there
<bodie_> o/
<thumper> bodie_: I'd say tables are fine if the body of the test in the loop is simple
<thumper> ie
<thumper> minor setup
<thumper> err := some-test
<thumper> if test.err { c.Assert(err, gc.ErrMatches, test.err); }
<thumper> else {
<thumper> c.Assert(err, jc.ErrorIsNil)
<thumper> other assertions
<thumper> if there are other if statements in the body, break the tests apart
<thumper> there are some table based tests in our code that really shouldn't be
<bodie_> that makes sense
<bodie_> :) thanks thumper
<thumper> np
<thumper> anastasiamac: here's a good one for you: http://reviews.vapour.ws/r/902/
 * thumper runs away
<anastasiamac> thumper: i'd add to it, that u might not want to have tables if u need to take adavantage of setup/teardown
<thumper> anastasiamac: agreed
<thumper> anastasiamac: FYI, a previous branch of mine added PrepareForCreateEnvironment, and renamed Prepare to PrepareForBootstrap
<thumper> some environments need to do additional checks for bootstrap
<thumper> like the local provider makes sure the ports aren't in use
<bodie_> I wrote a super ugly one.. or two.. using a func(){}() to wrap a defer... :P
<thumper> most other providers are much more simple
<thumper> bodie_: while that isn't too terrible, it makes it harder to follow
<thumper> one key indicator I have is "a test should be easy to follow and obviously correct"
<thumper> it is hard enough to decode convoluted code
<thumper> add convoluted tests to that and it just hurts more
 * thumper looks at the uniter tests
<bodie_> oh god
<bodie_> I'll keep that in mind
<thumper> night all
<anastasiamac>  jam: thnx for ur elegant comments on RB894. i was hoping there was a convention :D
<anastasiamac> jam: or at least a precedence
<jam> anastasiamac: happy to, thanks for doing the review as well
<Muntaner> ericsnow: fwereade, good morning
<Muntaner> and good morning to every1
<TheMue> morning
<fwereade> Muntaner, o/
<Muntaner> fwereade: can you have a look? https://bugs.launchpad.net/juju-core/+bug/1420155
<mup> Bug #1420155: Juju fails to bootstrap on a private OpenStack cloud due to not finding image metadata <bootstrap> <cloud> <juju> <private> <ubuntu-openstack> <juju-core:New> <https://launchpad.net/bugs/1420155>
<Muntaner> since I'm italian, maybe my english made this launchpad bug not understandable :)
<fwereade> Muntaner, no, that's clear, and much appreciated
<Muntaner> fwereade: I'm curious about how developers work
<Muntaner> all of the confirmed bugs get fixed in a single release?
<Muntaner> or you choose the most urgent and important and fix them ASAP?
<fwereade> Muntaner, afraid not -- there are many bugs, and somewhat harsh constraints on which ones actually get chosen at a given time
<fwereade> Muntaner, fwiw, I am rather grumpy that we have this particular bug and that it's lived so long
<Muntaner> fwereade: maybe it came out because nobody had tried a configuration like mine
<Muntaner> fwereade: is that possible? just thinking loud :)
<fwereade> Muntaner, most likely, yes -- we see an awful lot of use of juju *deploying* private openstack clouds with maas
<fwereade> Muntaner, and maas has its own image handling
<Muntaner> fwereade: well, my situation is "more new" then - I don't have MAAS in my configuration
<fwereade> Muntaner, yeah -- thank you very much for your help in tracking down the problem
<Muntaner> fwereade: no problem! btw, I noticed that dimitern had reported this situation in another launchpad -> https://bugs.launchpad.net/juju-quickstart/+bug/1411574
<mup> Bug #1411574: quickstart should detect private clouds somehow and generate metadata url in the environments.yaml <juju-quickstart:Triaged> <https://launchpad.net/bugs/1411574>
<Muntaner> dunno if it needs to be merged
<fwereade> Muntaner, quite possibly, and ericsnow found another that looked very closely related too
<fwereade> Muntaner, funny how many ways there are of characterising the exact same underlying issue ;)
<Muntaner> fwereade: so, the problem is that the upload of the metadatas fails in a LAN environment?
<fwereade> Muntaner, I have a strong suspicion that the metadata-uploading is just *broken*, which is what I'm mainly so grumpy about
<fwereade> Muntaner, I suppose that in general, for a prod environment, I'd expect a separate server for the metadata anyway, so maybe that's why it hasn't been spotted
<Muntaner> fwereade: yes - I agree that our configuration is somewhat "raw" :)
<mattyw> fwereade, ping?
<mattyw> jam, ping?
<jam> hey mattyw
<voidspace> dooferlad: TheMue: making coffee, be with you in a minute or two...
<perrito666> morning all
<TheMue> perrito666: heya
<voidspace> perrito666: o/
<perrito666> man, I am waay to far from europe to get an ubuntu phone
<TheMue> voidspace: the latest change on the Prepare... branch is pushed
<voidspace> TheMue: cool
<TheMue> voidspace: the current test for the exhausting of addresses knows the number of available IPs on a fresh dummy machine. that's no real good dependency. I added AddressesAvailable to subnet, but sadly I've got no access to the subnet from inside the test
<TheMue> voidspace: so if you know a good approach here it's welcome
<mattyw> is the build server feeling sick?
 * TheMue is out to lunch
<perrito666> mattyw: ?
<mattyw> perrito666, seems to have been rejected branches for the last hour with all kinds of weird test failures
<perrito666> mattyw: mm odd... well not that odd
<perrito666> mgz ?
<voidspace> TheMue: why do you need AddressesAvailable?
<voidspace> TheMue: you have AllocatableIPLow and AllocatableIPHigh
<voidspace> TheMue: available is High - low + 1 - numberAlreadyAllocated
<voidspace> TheMue: I don't really understand your problem
<voidspace> TheMue: point me to the test you think has the bad dependency
 * TheMue is back
<TheMue> voidspace: AddressesAvailable IS High - low + 1 - numberAlreadyAllocated ;)
<TheMue> voidspace: I only created it to have an external access to this information
<TheMue> voidspace: especially with the retrieval of the numberAlreadyAllocated
<voidspace> TheMue: I don't understand the problem you're trying to solve
<voidspace> TheMue: there is code that calculates this before attempting to pick a new address
<voidspace> TheMue: so it knows if the address space is exhausted
<voidspace> TheMue: and it has to fetch all the allocated IPs anyway
<voidspace> TheMue: so it's no extra work
<TheMue> voidspace: it's only for testing, I would like to know how many are still available opposite to simple pick them until they exhausted
<TheMue> voidspace: it's not for the productive code
<voidspace> TheMue: can't you create a subnet, then manually allocate specific addresses?
<voidspace> TheMue: sorry, I thought you said you wanted to add AddressesAvailable to Subnet
<voidspace> that *would* be external code
<voidspace> why not just create a known situation
<voidspace> TheMue: ah, but you don't have access to the subnet anyway?
<voidspace> is that the problem
<voidspace> so adding AddressesAvailable wouldn't help anyway
<TheMue> voidspace: yep, no access inside the test
<TheMue> voidspace: sadly currently not, exactly
<voidspace> I don't think it's needed anyway
<voidspace> TheMue: I'm about to leave :-/
<TheMue> voidspace: ok, thanks anyway
<voidspace> TheMue: you'd have to manipulate the test setup
<voidspace> which with our test heirarchy is non-trivial
<TheMue> voidspace: hoped for a simpler answer :D
<TheMue> voidspace: currently my test relies on knowing the hard coded subnets of the dummy provider. but once somebody changes it the test would break.
<perrito666> TheMue: well they will most likely notice :p
<voidspace> TheMue: my answer would be that address space exhaustion is already tested
<TheMue> perrito666: yeah, indeed
<voidspace> TheMue: so it doesn't need testing at this level
<voidspace> TheMue: mock out the call that would produce the error and check the error is handled well
<voidspace> TheMue: but you don't need to simulate actual exhaustion
<TheMue> voidspace: ok
<wwitzel3> voidspace: do you have a maas setup?
<voidspace> wwitzel3: yes
<wwitzel3> voidspace: in all my attempts I am failing to reproduce https://bugs.launchpad.net/juju-core/+bug/1417875
<voidspace> wwitzel3: I'll have to look at it on my return, I'm off out to a meeting
<voidspace> wwitzel3: but I'll give it a go
<wwitzel3> voidspace: all I need is for you to bootstrap and deploy something to using --to 0 and see if the logging gives you the x509 cert error.
<wwitzel3> voidspace: thanks, appreciate it
<perrito666> how did I not set my vim to run go fmt before saving before? this is glorious.
<wwitzel3> perrito666: indeed, there is no other appropriate way
<perrito666> wwitzel3: I used to, git diff, review, git commit, git push, notice go fmt is sad, scream, kick, insult, go fmt ./..., git commit --amend, git push
<wwitzel3> perrito666: sounds exhausting
<perrito666> restore 4 out of 6 merged :')
<ericsnow> FYI, at some point Reviewboard will be down for (hopefully) at most an hour while we switch to a new environment
<ericsnow> I'll be sure to notify everyone when we're close
<TheMue> ericsnow: thx for info
<ericsnow> natefinch: one-on-one?
<ericsnow> natefinch: (in 5 min I guess)
<perrito666> really another backup/restore bug breaking 1.21?
<sinzui> perrito666, sorry, two in fact
<perrito666> o ffs
<perrito666> ok, on it
<perrito666> I wonder if we should add testing support for this in the already bloated CI test
<alexisb> hey there hazmat !
<hazmat> alexisb: greetings
<sinzui> Hi natefinch, do you have a moment to review http://reviews.vapour.ws/r/906/
<natefinch> sinzui: ship it@
<natefinch> !
<sinzui> thank you natefinch
<natefinch> sinzui: welcome
 * perrito666 is back, from a 3g network in a dentist's waiting room
* ChanServ changed the topic of #juju-dev to: https://juju.ubuntu.com | On-call reviewer: see calendar | Open critical bugs:  1420426
<sinzui> katco, perrito666, ericsnow: CI just found a cross-compile regressions. bug 1420426
<mup> Bug #1420426: backups_nonlinux.go import error <ci> <osx> <regression> <windows> <juju-core:Triaged> <https://launchpad.net/bugs/1420426>
<perrito666> you have got to be kidding me
<ericsnow> perrito666: perhaps we should just disable all tests in state/backups on non-linux
<ericsnow> perrito666: (in package_test.go add c.Skip() if runtime.GOOS != "linux")
<perrito666> ericsnow: could you tacle this one? I have my hands full with the other two restore blockers
<ericsnow> perrito666: sure
<perrito666> tx a lot, I owe a beverage of your chooice
<perrito666> :)
<perrito666> sinzui: I apologize, that was most likely my
<perrito666> my fault
<ericsnow> perrito666: http://reviews.vapour.ws/r/907/
<voidspace> g'night all
<voidspace> EOD
<perrito666> orry I was suddenly trapped for the past hour in my mother in law's home, its a good thing I know how to tear apart a door
<perrito666> ericsnow: that diff is correct?
<perrito666> I am extremely curious how that got merged to begin
<ericsnow> perrito666: because it would only have failed under non-linux (which I presume the merge bot does not try)
<perrito666>   ah makes sense
<ericsnow> davecheney: regarding that backups fix, I had considered checking runtime.GOOS, but version.Current.OS gives us better granularity
<davecheney> ericsnow: replied on the review
<ericsnow> davecheney: thanks
<perrito666> sinzui: is it possible to backport (and release off course) a fix to 1.20?
<sinzui> perrito666, we can, though it is disabled at this time
<niedbalski> perrito666, sinzui 1.21 is OK to me, if you can confirm that juju upgrade-juju works from 1.20.8.1 to 1.21.x
<niedbalski> :)
<sinzui> niedbalski, 1.20.8.1 is either a custom build or juju built using upload-tools, it is not an official release and not in streams
<sinzui> niedbalski, but I can confirm 1.20.x can upgrade to 1.21.x.
<perrito666> ok, that is all I needed to hear
<sinzui> niedbalski, but I will call your attention to https://bugs.launchpad.net/juju-core/+bug/1416928 which murdered my beloved juju-ci3 env
<mup> Bug #1416928: juju agent using lxcbr0 address as apiaddress instead of juju-br0 breaks agents <api> <lxc> <network> <juju-core:Triaged> <juju-core 1.21:Triaged> <juju-core 1.22:Triaged> <https://launchpad.net/bugs/1416928>
<sinzui> niedbalski, suspect t juju flipped out when it found lxc installed in the bootstrap server
<thumper> cmars: can I defer our call?
<rharper> so, I'm trying to invoke an rpc of addmachine and I want to pass an arg that will be converted to a placement.instance, much lik what the juju cli does when you do juju machine add foo (it converts it to {env-uuid: foo}) ... I'm sending over a Placement value in the MachineParams structure, and the response is that it cannot unmarshal strings to an instance.Placement ;  so the question then is how do I pass the argument to the AddMachines
<rharper>  request such that it does what the juju cli machine add does ?
<niedbalski> sinzui, this is the simpler way to reproduce ( A. start an instance in a cloud and install lxc on it. With the manual provider, attempt to bootstrap it. )
<niedbalski> ?
<rharper> I'm using the python-jujuclient as the sender FWIW;
<natefinch> rharper: placement expects to be scope:directive
<natefinch> rharper: so, like lxc:1
<rharper> except I can do juju add-machine foo
<rharper> and it will do a env-uuid:foo as an instance.Placement
<rharper> object
<rharper> this allows me to have the provide add that machine (maas backend)
<rharper> I want to do the same via rpc, but I can't see how to pass the args that the Init() in cmd/juju/machine/add.go does
<rharper> it attempts to construct an placement object from the args value, and if it fails, it prepends 'env-uuid'
<natefinch> rharper: this is the code that does the parsing of the string: https://github.com/juju/juju/blob/master/instance/placement.go#L53
<rharper> yep
<rharper> https://github.com/juju/juju/blob/master/cmd/juju/machine/add.go#L131
<rharper> that's the bit where it takes extra args from machine add <args> and prepends 'env-uuid' and then calls instance.Placement()
<cmars> thumper, sgtm
<rharper> that's the code that appears to allow juju add-machine foo.maas to pass foo.maas (placement ) to the provide which in turns starts up foo.maas
<rharper> natefinch: what I don't know is how incoming json rpc requests are unmarshal;  it appears from the response that it can't convert strings to instance.Placement objects ...  http://paste.ubuntu.com/10163887/
<sinzui> niedbalski, That is one scenario
<sinzui> niedbalski, for my case. I think I need to bootstrap 1.20.14, install lxc, reboot the machine, upgrade to 1.21. I think those are the events that happened on my server
<natefinch> rharper: oh, I see, ok.  so for just normal json unmarshalling you just need to make placement an object with Scope and Directive string values  so, "Placement": { "Scope": "foo", "Directive": "bar"}
<natefinch> rharper: I actually think that placement parsing code is for translation from the CLI
<natefinch> sorry, my mistake
<rharper> no worries;  just trying to figure out how to do the same thing the cli is doing via rpc;
<rharper> lemme play with that now
<sinzui> natefinch, do you have a minute to review http://reviews.vapour.ws/r/910/
<perrito666> sinzui: the  2 restore ones are now committed to 1.21
<sinzui> perrito666, you rock
<perrito666> sinzui: in this case niedbalski rocks, because he put up with all the "try this" ideas I had and added some of his own :p
<sinzui> thank you niedbalski
<rharper> natefinch: thanks for the tip;  I've got it working, I need to extract the environment's config uuid, pass that in as the scope, and the directive uses the machine name;
<natefinch> rharper: cool, glad you got it working
<niedbalski> sinzui, np
<niedbalski> perrito666, thanks for the fixes :)
<perrito666> I really hate juju bot
<jw4> perrito666: tsk tst
<perrito666> jw4: we all do
<perrito666> admit it
<jw4> perrito666: lol
 * hazmat pats juju bot on the head
<jw4> heh
<alexisb> ericsnow, release call?
<sinzui> wallyworld_, can you review https://github.com/juju/juju/pull/1580
<wallyworld_> sure
<wallyworld_> well that was hard
<ericsnow> alexisb: sorry, had a dentist appt.
<anastasiamac> waigani: morning! as an OCR,could u plz cast ur eyes over http://reviews.vapour.ws/r/888/
<waigani> anastasiamac: yep, just finishing a rather big one off, you're next on the list
<anastasiamac> waigani: thnx :D
#juju-dev 2015-02-11
<wallyworld_> thumper: did you see that question in #juju-dev and ask ubuntu about local provider and not being able to mount /var/log/juju-<user>-local? Do you recall what might cause that?
<thumper> yeah
<thumper> sadly
<thumper> can we chat after I have some food?
<thumper> catch up should be good
<wallyworld_> sure, or you could answer his question :-)
<wallyworld_> catch up sounds good anyway
<wallyworld_> i might grab some food too
<perrito666> wallyworld_: btw, I wanted to ask you so Ill leave the question here
<perrito666> there are descriptions for most of the other statuses describing where they are used and what for, do we have those for the new ones?
<perrito666> waigani: tx for the review btw
<wallyworld_> perrito666: yep, all in the spec
<wallyworld_> the ones in code now are wrong
<wallyworld_> thy are really only there as placeholders
<perrito666> wallyworld_: I guessed so, but abstained from changing them until it was set in stone
<waigani> perrito666: np, I agree with wallyworld_ on the func name, on second thought
<waigani> anastasiamac: http://reviews.vapour.ws/r/888/
<anastasiamac> waigani: just saw :D tyvm!!
<waigani> anastasiamac: sorry for the wait, running low on fuel, need food!
<perrito666> wallyworld_: since they have to change all over in tests too which is a bit of a pain to do more than once :p
<anastasiamac> waigani: np. eat!!
<wallyworld_> perrito666: agreed. i didn't want us to do anything with the actual values until the spec is finalised
<wallyworld_> even the ones there now aren't complete at the time they were added
<perrito666> wallyworld_: well I finally changed then or you would add a comment that I those are nto the right ones each time I pushed to go from one computer to the other :p
<wallyworld_> wot? did i do that? i don't recall. i didn't mean to
<perrito666> ts ok, you reviewed each of my pushes, even the ones I did forgetting that they changed rb lol
<anastasiamac> davecheney: thnx for review :D
<anastasiamac> davecheney: there is no better feeling than seeing Shipit :D
<thumper> wallyworld_: ready when you are
<thumper> anastasiamac: really? no better feeling?
<wallyworld_> one minute
<anastasiamac> thumper: at work? yes - no beta :D
<anastasiamac> thumper: outside of work - driving fast cars does it :D
<thumper> anastasiamac: I wasn't even going to go there :)
<anastasiamac> thumper: where?..
<thumper> outside work
<thumper> wallyworld_: I'm in our 1:1 hangout when you are ready
<anastasiamac> why, thumper... what gives u  a good feeling at work?
<thumper> and reviewing waigani's branch while I wait
<thumper> waigani: getting down to relatively small issues now
<thumper> waigani: I think most comments were about improving readability
<waigani> thumper: okay, thanks
<thumper> hello reviewers: http://reviews.vapour.ws/r/912/
<thumper> menn0, waigani, davecheney: http://reviews.vapour.ws/r/912/
<menn0> thumper: looking
<menn0> thumper: shit it
<menn0> thumper: or ship it :)
<thumper> heh
<thumper> I was going to ask if that was a slip
<menn0> only wrt to how i'm currently feeling, not the code :)
<menn0> thumper: only one more component to go with this logging POC. with a bit of luck i'll have logs streaming through the API end-to-end
<menn0> soon
<thumper> menn0: \o/
<menn0> thumper: it's a bit rough and has no tests and there's a few details to iron out but it should work
<thumper> menn0: sounds like a spike to me :)
<menn0> thumper: the code is mostly reasonable quality. writing tests and cleaning it up will probably add a day or 2
<thumper> waigani: shipit... when the queue is unblocked
<waigani> thumper: great, thanks. I'm going to have some merge conflicts.
<thumper> waigani: best get them sorted now then :)
<waigani> thumper: yep
 * thumper needs coffee
<thumper> bbs
<anastasiamac> waigani: thumper: environments can be annotated
<anastasiamac> waigani: thumper: for all other entities that can be annotated, we remove annotations on entity destruction/removal
<anastasiamac> waigani: thumper: i could be blond but m not seeing it for environment destruction
<anastasiamac> waigani: thumper: s/blond/blind
<waigani> anastasiamac: when an env is destroyed, all docs associated with that env are removed
<waigani> anastasiamac: at least for non state server envs
<anastasiamac> waigani: to ease my mind, would it b possible to have a test for it :D
<waigani> anastasiamac: yep, sounds like a good idea
<anastasiamac> waigani: much appreciated!
<anastasiamac> waigani: plz let me know when env desruction lands
<anastasiamac> waigani: i may need to go over old annotations impl too  as environments r special l:D
<waigani> anastasiamac: just got a shipit, so once the IC blocker is moved ... where's menno?
<anastasiamac> waigani: menno is blocking ci?
<waigani> anastasiamac: no, he is THE UNBLOCKER
<waigani> anastasiamac: so in your annotation's tests your using RemoveEnvironment (or something like that)
<waigani> anastasiamac: that just removes the env doc
<anastasiamac> waigani: yes ;D I had to despite the comment that u guys were not happy with it
<waigani> anastasiamac: once destroy lands, there will be a RemoveAllEnvironDocs func
<anastasiamac> waigani: hence m happy to go over annotation stuff once ur branch lands :D
<anastasiamac> waigani: awesome! m look n forward to it
<waigani> anastasiamac: that func will remove the env doc and ANY doc that has a env-uuid field with a matching UUID
<anastasiamac> waigani: sounds exactly like what i want
<waigani> anastasiamac: so that should clear out any annotation docs associated with the env
<waigani> anastasiamac: but yeah, I'll land the branch and then we can take a look at the annotation tests and make sure it's all covered.
<anastasiamac> waigani: sounds gr8 :D
<anastasiamac> waigani: annotation impl treats env differntly than other entities for historical reasons
<anastasiamac> waigani: so i'll fix this once JES is capable of destroying env D
<waigani> anastasiamac: okay. I haven't looked into annotations at all. But happy to help from the JES side
<anastasiamac> waigani: np
<anastasiamac> waigani: i'll ask if i'll get lost with JES :D
<waigani> sounds good
 * thumper sighs
<thumper> seems like a bad test in state
<thumper> intermittent failure
<thumper> stopped eric's fix branch landing more than once
<thumper> http://juju-ci.vapour.ws:8080/job/github-merge-juju/2093/?
<thumper> FAIL: machine_test.go:1038: MachineSuite.TestMachinePrincipalUnits
 * thumper must write the spec
<thumper> gah, distractions
<axw> wallyworld: I'm not going to go there yet, but I'm starting to wonder whether the machine provisioner should be made more generic, to handle de/provisioning storage as well
<axw> we're going to need to do pretty much all the same things... e.g. "harvesting" volumes that we fail to record in state
<axw> and the machine/container provisioning is very similar to env/machine volume scope
<mattyw> davecheney, ping?
<davecheney> mattyw: pong
<wallyworld> axw: yes, it may com to that
<TheMue> morning
<anastasiamac> TheMue: morning :D
<TheMue> anastasiamac: o/
<anastasiamac> ericsnow: about ci blocker, bug 1420426
<mup> Bug #1420426: backups_nonlinux.go import error <ci> <osx> <regression> <windows> <juju-core:Triaged by ericsnowcurrently> <https://launchpad.net/bugs/1420426>
<anastasiamac> ericsnow: i just got trunk and it looks like the offensive import is not there...
<anastasiamac> ericsnow: should the bug be marked "fix committed" and hopefully unblock CI
<jam> fwereade: greetings
<fwereade> jam, ahoy
<jam> fwereade: How's Leia doing?
<jam>  fwereade: are you coming to leader-election?
<perrito666> morning all
<perrito666> anastasiamac: Block ok pr 916 refers to the action of blocking?
<anastasiamac> perrito666: m lost... could u re-phrase? :D
<perrito666> sure
<perrito666> http://reviews.vapour.ws/r/916/diff/#
<perrito666> Block, means blocking as in preventing something to be done?
<anastasiamac> perrito666: yes :) PR 916 is about adding env blocks to prevent some operations from runnng
<anastasiamac> perrito666: currently, u can 'juju block' whatever
<anastasiamac> perrito666: however, it just adds env variable
<perrito666> anastasiamac: :p as a non native english speaker let me drop a word of advice :) when seen in the code, "block" is a veeery ambiguous word
<anastasiamac> perrito666: we want to be able to desribe why we are blocking smth
<anastasiamac> perrito666: not my choice of vocabulary :D
<perrito666> I first read the pr backwards and was thinking on block as "piece of something" :p
<anastasiamac> perrito666: altho in this instance it is actually descriptive of what it does...
<TheMue> voidspace: ping
<voidspace> TheMue: omw
<voidspace> TheMue: dooferlad: firefox crash!
<voidspace> rejoining
<voidspace> dooferlad: tried chrome, video still didn't work...
<wallyworld> jam: you around?
<voidspace> getting maas running locally again
<voidspace> switching off "disk erase on release" helps...
<voidspace> I'd switched it on for bug hunting previously
<voidspace> desperately hoping I get to successful bootstrap before timeout
<voidspace> and fail...
<voidspace> ooh, now pxe boot is working again for no specific reason
<voidspace> that's nice
<voidspace> possibly due to an update
<voidspace> nope, it boots then shuts down
<voidspace> dammit
<voidspace> ah, the wrong machine pxe booted
<voidspace> starting the second node kicks things off
<voidspace> how odd
<voidspace> race against timeout again
<voidspace> must increase the timeout...
<voidspace> bootstrap!
<voidspace> wwitzel3: ping
<voidspace> wwitzel3: I can (finally) bootstrap and deploy to MAAS with no problem
<voidspace> wwitzel3: can't reproduce the x509 cert issue
<voidspace> wwitzel3: I've added a note on the issue
<anastasiamac> fwereade: o/
<fwereade> anastasiamac, heyhey
<anastasiamac> fwereade: how r u?
<fwereade> anastasiamac, good thanks, and yourself?
<anastasiamac> fwereade: m good... :)
<anastasiamac> fwereade: i need to distract u
<anastasiamac> fwereade: and beg for a favour...
<fwereade> anastasiamac, np :)
<anastasiamac> fwereade: could u plz chnage my subscription to juju-dev from digest at one stage?..
<anastasiamac> fwereade: m getting delayed correspondence
<anastasiamac> fwereade: it'd b gr8 if I could do it myself
<anastasiamac> fwereade: but when I tried, i was sternly told that m already subscribed and need to contact u :D
<fwereade> anastasiamac, hummmm I am technically an administrator there aren't I? :/
<anastasiamac> fwereade: it's not urgent but would b gr8
<anastasiamac> fwereade: yes u r :)
<fwereade> anastasiamac, figuring out what to do is not going to be a 5-min thing so I need to put it on the stack -- can I suggest unsub/resub as a possibly quicker method?
<anastasiamac> fwereade: i'll try :D thnx :)
<anastasiamac> fwereade: i bow to ur wisdom
<anastasiamac> fwereade: when i went to unsubscribe, i had to log in
<anastasiamac> fwereade: which allowed me to change from digest subscription :D
<fwereade> anastasiamac, excellent :)
<anastasiamac> fwereade: all sorted
<anastasiamac> fwereade: tyvm!!
 * fwereade likes thanks for doing nothing at all ;p
<anastasiamac> fwereade: pointing ppl in the right direction is doing smth :D
<fwereade> anastasiamac, when you look closely enough, I suppose :)
<jam> wallyworld: what's up ?
<wallyworld> jam:  hey, re: running-hook in status spec. i'm torn between "executing" as per mark's suggestion, and running-hook and running-action
<wallyworld> did you have an opinion
<jam> I haven't read that particular bit lately, but just from what you bring up, I'm not sure there is a worthwhile *user* distinction there, is there ?
<jam> wallyworld: as in, someone watching "juju status" will wait on running-action but go ahead if it was running-hook
<wallyworld> jam: not so much for scripts, but humans, but i guess that's what message is for. so seems like "executing" might be ok
<jam> wallyworld: yeah, if its just humans than that's what the message is for.
<wallyworld> mark also didn't want like the recent hooks
<jam> run it by fwereade as well
<jam> wallyworld: that was a gustavo thing that we didn't get a chance to run by him
<jam> IIRC
<wallyworld> yeah, i think that was the case
<jam> I think being able to introspect it is good, I don't think *I* would prefer it to be in default status for sure
<jam> possibly when digging deeper
<wallyworld> i suggested using a --verbose flag or some such
<wallyworld> i didn't want it output by default
<wallyworld> but i could see the value
<jam> wallyworld: yeah, I feel like this sort of thing falls more into a "debug-log" sort of syntax
<jam> juju debug show-recent-hooks $ID
<wallyworld> yeah, sounds fine
<wallyworld> i could see how it fitted into a status deep dive also
<jam> wallyworld: yeah, that *might* be a way to get it, though I'd be hesitant to do it on a command that would try to do it against all 1000 units in the env
<wallyworld> true
<jam> fwereade: an interesting development, I accidentally messed up while transcribing the tests and I wonder if I'm running into something.
<fwereade> jam, oh yes?
<jam> specifically, "Set the charmURL to trigger config events" has an assertChange()
<jam> and then we change the config
<jam> and assert that we get one more change
<jam> fwereade: which seems fine, *but*
<jam> if I remove the first assertChange
<jam> then I get 2 changes on the channel
<jam> should those actually be coalesced?
<jam> concretely, filter_test.go, line 327, if you comment that out the next "assertChange" fails because it has 2 events in the queue
<jam> fwereade: anyway, have to take the dog out, bbiab
<fwereade> jam, in general, yes, but... is it plausible that the StartSync (which is not, uh, sync) only causes the second change to be delivered just after the filter sends the event for the first one?
<fwereade> jam, which could indicate the potential for races in the tests that *do* check coalescence... hmm
<jam> fwereade: I have the feeling it is more that maybeSendMessage actually causes us to send 2
<jam> anyway, good that it happened because I "fixed" the test wrong
<jam> but made me wonder
<jam> fwereade: http://reviews.vapour.ws/r/917/diff/# is just my "use nil instead of make(chan)" proposal
<fwereade> jam, LGTM
<jam> fwereade: I made some progress on updating the tests to use ContentAsserterC and NotifyAsserterC, I'll finish that up tonight and propose it.
<alexisb> voidspace, you around?
<wwitzel3> voidspace: thanks
<natefinch> wwitzel3: want to do our 1:1?
<wwitzel3> natefinch: sure
<wwitzel3> natefinch: just refilling my coffee
<natefinch> wwitzel3: a worthy cause for delay :)
<ericsnow> our ReviewBoard site will be having some downtime today
<ericsnow> (for real this time)
<wwitzel3> ericsnow: :)
<ericsnow> I'll send out a message about 10 minutes before taking it down
<ericsnow> and right after it comes up
<natefinch> ericsnow, perrito666: you guys coming to the standup?
<perrito666> my cal says its in 1h but sure
<ericsnow> natefinch: yeah, in 55 minutes :)
<natefinch> ericsnow, perrito666: I just moved it to now :)
<natefinch> ericsnow, perrito666: that way it's always at the same time.... the meetings that had interfered with it in the past are gone, so figured I'd fix it
<natefinch> ....somewhat retroactively
<Muntaner> how are you, devs?
<frankban> voidspace: I proposed a fix for the ports issue here: https://github.com/juju/juju/pull/1588
<natefinch> alexisb: brt, still in standup
<alexisb> nw
<alexisb> no rush
<perrito666> ericsnow: didn't you fix 1420426?
<ericsnow> perrito666: yep
 * perrito666 gets denied by juju bot because of it
<stokachu> natefinch: you ever heard of https://github.com/moovweb/gvm?
<ericsnow> perrito666: Tim landed it last night
<stokachu> i think that would be cool to have for managing juju versions
<stokachu> a similar tool
<stokachu> make it easier to test against development releases
<natefinch> stokachu: yeah, I know of it.  For go, I think it's a terrible idea. :)  For Juju, well, it might be a better idea.
<stokachu> cool, just a thought i had :)
<natefinch> stokachu: ideally we'd make it easier to run different juju clients side by side
<voidspace> frankban: ok, thanks
<stokachu> natefinch: yea that would be perfect, im trying to work out the best way to automate testing our installer against all available juju versions
<voidspace> frankban: reading through it
<natefinch> stokachu: in theory, just switching $JUJU_HOME per version of juju can let you run them side by side
<frankban> voidspace: thanks
<stokachu> natefinch: good point, i could probably script something up for that
<stokachu> we use a custom home anyway for juju
<frankban> voidspace: dow you know why that MP is not automatically hooked to review board?
<voidspace> no
<voidspace> frankban: is your membership of the juju team public?
<frankban> voidspace: I guess so, and my last proposal was correctly hooked
<voidspace> frankban: I think that's a requirement
<voidspace> ah
<voidspace> ericsnow: ping
<ericsnow> voidspace: hey
<ericsnow> voidspace: OTP
<voidspace> ericsnow: this PR hasn't landed on reviewboard
<voidspace> ericsnow: https://github.com/juju/juju/pull/1588/files
<voidspace> ericsnow: ok
<ericsnow> voidspace: I'll take a look in a bit
<voidspace> ericsnow: thanks
<ericsnow> voidspace: it's probably a unicode issue (Python 2.7) :P
<voidspace> ericsnow: hah :-)
<ericsnow> voidspace: I'm actually not kidding! (we have unicode somewhere in our mongo package that RB fails on)
<voidspace> :-/
<voidspace> frankban: so lines 156 on in the megawatcher
<voidspace> frankban: you moved the code assigning PortRanges and Ports
<voidspace> frankban: to "preserve the current status and ports."
<voidspace> frankban: why are we preserving the old ones instead of using the new ones?
<frankban> voidspace: on call, back in a minute, but the answer is that we only need to calculate ports on new entities. If an entity is already there, then its ports are updated by the bakingOpenPorts
<voidspace> frankban: ah, ok - cool, thanks
<voidspace> frankban: that answers my next question too :-)
<voidspace> frankban: so your PR LGTM, but I'm not familiar with the intricacies of all the entities involved
<voidspace> frankban: in essence is the megawatcher now watching another collection?
<frankban> voidspace: yes
<voidspace> frankban: cool
<voidspace> frankban: I'm going to give it an LGTM
<frankban> voidspace: it now watches the openports collection
<frankban> voidspace: ty!
<Muntaner> guys, where can I start to study something about using Juju with Windows Machines?
<gsamfira> Muntaner: hi there. I think I may be able to help
<gsamfira> Muntaner: on which provider would you like to use Windows?
<gsamfira> MaaS, OpenStack, etc?
<Muntaner> gsamfira: I don't have the details under my hands right now - bosses will tell me them soon
<voidspace> gsamfira: o/
<voidspace> gsamfira: hi
<Muntaner> and I wanted to start studying the situatio
<Muntaner> n
<Muntaner> in general
<gsamfira> Muntaner: okay then. So in general there are a few requirements to get windows up and running. And it depends on the provider you are planning to use
<gsamfira> for an Openstack private cloud, you will need 2 things. The windows agent tools, and a windows image preinstalled with cloudbase-init
<gsamfira> I am not sure if the windows agent tools are part of the official simplestreams that juju offers for 1.21
<gsamfira> but if it is not, I can help you build them
<gsamfira> Muntaner: a windows image can be downloaded freely from: http://www.cloudbase.it/ws2012r2/
<gsamfira> its an evaluation image valid for 180 days (I think)
<gsamfira> I can write up a wiki page on setting up your OpenStack private cloud (Incidentally I need to set one up anyway....I can just document the steps)
<Muntaner> gsamfira: thanks!
<gsamfira> My pleasure
<gsamfira> If you plan to use MaaS, you'll need a windows image for that as well. There is a image builder in the works at the moment that will be released as part of MaaS
<gsamfira> Muntaner: in any case, I'll be online a lot in the next couple of weeks. Ping me anytime on IRC :)
<gsamfira> voidspace: hi :D
<Muntaner> gsamfira: great! thanks :D
<voidspace> g'night all
<voidspace> EOD
<ericsnow> in 10 minutes I'm going to be taking reviewboard down for a little while (to move to a new host)
 * perrito666 panics and runs in circles
<ericsnow> reviewboard going down now
<natefinch> If you want to know why GCE isnt finished being reviewed, you can blame ericsnow ;)
<ericsnow> haha
<thumper> morning folks
<thumper> fwereade: if you are around this evening, it would be great to have a catch up call
<ericsnow> reviewboard is back up (on the new host)
<ericsnow> let me know if anything is amiss
<perrito666> ericsnow: no new features :p
<ericsnow> perrito666: wasn't an upgrade ;P
<perrito666> i know
<perrito666> I just fancy upgrades
<perrito666> :p
<natefinch> ericsnow: I'm getting a 500
<natefinch> ericsnow:  http://reviews.vapour.ws/r/771/
<ericsnow> natefinch: impossible
<ericsnow> natefinch: ;)
<ericsnow> natefinch: ah, I guess the charm doesn't install git for you
<ericsnow> natefinch: problem solved
<perrito666> ericsnow: I could do with a different theme (?)
<ericsnow> perrito666: go for it <wink>
<perrito666> ericsnow: oh :( I thought these where canned things
<ericsnow> perrito666: perhaps (I don't know)
<perrito666> hey, next tue i am ocr but its a holiday here, anyone wants to trade?
<katco> perrito666: i can trade, i'm the next day (wed.)
<perrito666> sweet, tx :D
<katco> perrito666: happy holiday :)
<perrito666> tx, its carnival :D
<katco> fun times
<perrito666> though since cellphones we can no longer have as much fun :p
<katco> lol because of cameras everywhere?
<perrito666> and well there is the fact that being a grown up I no longer have one of those wather proof wallets
<perrito666> katco: because of cellphones not being nice with wather
<katco> ah
<perrito666> when I was a kid you would walk pass a neigborhood with kids an they would splash you throwing these small balloons filled with wather
<katco> yeah that would not be too fun with an expensive computer in your pocket
<ericsnow-dentist> be back online ~1 hour
<anastasiamac> CI is blocked... still :(
<thumper> again
<thumper> not still
<alexisb> menn0, you available for a call at the top of the hour?
<menn0> alexisb: yep
<alexisb> thumper, ^^?
<thumper> sure
<thumper> call about?
<alexisb> this re the issue menn0 worked last week
<thumper> ok
<alexisb> and menn0 we are not volunteering you for anything but we need to determine next step for the customer
<alexisb> wwitzel3, ping
<wwitzel3> alexisb: pong
<alexisb> wwitzel3, nevermind, I see #juju
<whit> any know issues with upgrading local charms in 1.22-beta3-trusty-amd64?
 * whit is experiencing a hang on aws
<sinzui> whit, nonw
<sinzui> none
<sinzui> whit, these are the known issues https://launchpad.net/juju-core/+milestone/1.22-beta4
<whit> ok, I'll report it
<ericsnow> sinzui: FYI, I don't think bugs #1403243 and #1391276 apply to 1.22 and 1.23.
<mup> Bug #1403243: juju-backup restarts rabbitmq, reconnect is unstable <canonical-bootstack> <canonical-is> <cts> <upgrade-juju> <juju-core:Triaged> <https://launchpad.net/bugs/1403243>
<mup> Bug #1391276: a terminated juju backup can leaves server in a dirty state <backup-restore> <juju-core:Triaged> <https://launchpad.net/bugs/1391276>
<ericsnow> sinzui: also, why is #1399310 marked as high priority?
<mup> Bug #1399310: The code in apiserver/backup.go belongs in apiserver/backups. <backup-restore> <tech-debt> <juju-core:Triaged> <https://launchpad.net/bugs/1399310>
<thumper> I think it is hilarious that google docs is happy with rick_h, fwereade, and niemeyer, but thinks that mramm is a misspelling
<perrito666> lol
<sinzui> ericsnow Tour welcome to lower them. bug 1391276 is high because some of our customers might be upset if they cannot backup and restore as cts advises
<mup> Bug #1391276: a terminated juju backup can leaves server in a dirty state <backup-restore> <juju-core:Triaged> <https://launchpad.net/bugs/1391276>
<sinzui> ericsnow, if you know a bug is  not high, you can mark it as such when you report it
<ericsnow> sinzui: I did (for #1399310) :)
<mup> Bug #1399310: The code in apiserver/backup.go belongs in apiserver/backups. <backup-restore> <tech-debt> <juju-core:Triaged> <https://launchpad.net/bugs/1399310>
<sinzui> ericsnow, but you didn't remove the bug from the milestone.
<ericsnow> sinzui: ah
#juju-dev 2015-02-12
<anastasiamac> davecheney: ping
<anastasiamac> davecheney: all sorted
<wallyworld> thumper: menn0: waigani: anyone else: I unblocked trunk by reverting a regression commit and reclassifying the associated bug as High for trunk (still critical for 1.22, 1.21)
<wallyworld> this was a per agreement with curtis
<thumper> ok, cool, ta
<waigani> wallyworld: thanks :)
<wallyworld> np :-)
<menn0> wallyworld: tyvm
<thumper> fuck fuck fuck fuck
<rick_h_> thumper: you rang?
<rick_h_> :P
 * thumper sighs
<thumper> we are starting lxc containers on a power machine with amd64 tools
<thumper> and wondering why it is erroring weirdly
<rick_h_> thumper: hmm, that seems less than ideal
<thumper> I'm trying to work out where it got the wrong tools set
<thumper> fark
<thumper> wallyworld: bot still showing blocked
<thumper> wallyworld: regression query not showing blocked
 * thumper is confused
<wallyworld> thumper: huh? anastasiamac told me she got something accepted
<thumper> ok, maybe I tried too soon
<wallyworld> there were 2 bugs - one i marked fix released, ther or as high
<thumper> it was just after you mentioned above
<wallyworld> ah, i was in the process of marking as fix released
<wallyworld> sorry
<thumper> ok
<thumper> I've tried them again
<thumper> we'll see if they land now?
<anastasiamac> wallyworld: i got something accepted by the bot but not landed
<anastasiamac> wallyworld: machine_test.go:1102:
<anastasiamac>     c.Assert(sortedUnitNames(got), gc.DeepEquals, expect)
<anastasiamac> ... obtained []string = []string{"s2/2", "s3/2"}
<anastasiamac> ... expected []string = []string{"s2/2", "s3/1"}
<wallyworld> sure, false error
<wallyworld> but it wasn't rejected due to policy
<anastasiamac> wallyworld: as in re-$$merge
<wallyworld> yep
<wallyworld> that's one of our aewsome transient errors
<ericsnow> wallyworld: I got bit by that one 3 or 4 times in a row last night
<wallyworld> sigh
<wallyworld> is there a bug raised? who does annotate say added the test?
<wwitzel3> ok, so we've run into an issue with the rsyslog direct connections, when we ensure-availability, all of the state machines end up with different rsyslog certs.
<wwitzel3> and the logging is distributed to all 3 of them, so we end up with 1 successful connection, and two failed connections for every nodes rsyslog worker, in a constant loop and it floods the error log.
<wallyworld> wwitzel3: https://bugs.launchpad.net/bugs/1417875 ??
<mup> Bug #1417875: ERROR juju.worker runner.go:219 exited "rsyslog": x509: certificate signed by unknown authority <canonical-bootstack> <logging> <regression> <juju-core:Triaged by wwitzel3> <juju-core 1.21:Triaged by wwitzel3> <juju-core 1.22:Triaged by wwitzel3> <https://launchpad.net/bugs/1417875>
<wwitzel3> wallyworld: correct
<wallyworld> so you managed to diagnose the cause :-)
<wwitzel3> wallyworld: I wasn't able to reproduce until I worked with Paul and figured out it was ensure-availability
<wallyworld> ah, good effort!
<wwitzel3> wallyworld: yep, all my attempts to reproduce were non-HA
<wwitzel3> so manual work around is copy the rsyslog-cert and rsyslog-key from machine 0 to 1 and 2
<wwitzel3> that resolves the issue
<wallyworld> so the fix will be to hand out the machine 0 certs when adding new state servers?
<wwitzel3> wallyworld: right, for the rsyslog certs
<wallyworld> or master
<wallyworld> s/0/master
<wwitzel3> wallyworld: right
<wallyworld> a couple of day's work i guess
<wwitzel3> wallyworld: I didn't see an easy way
<wallyworld> yeah, me either at first glance
<anastasiamac> thumper: let's not be greedy with bot...
<wallyworld> thumper? greedy? never
<thumper> anastasiamac: it is only two
<thumper> geez
<anastasiamac> thumper: hmm... keeping score?..
<thumper> anastasiamac: I'm aiming for that 'nothing better' feeling of landing code
<anastasiamac> thumper: ahh, then we'd beta not disturb
<thumper> rick_h_: you around?
<thumper> still?
<anastasiamac> thumper: there goes that feeling
<rick_h_> thumper: no, I ran away
<thumper> rick_h_: ok, I hear you are ill, go to bed :)
<rick_h_> yea, keep thinking about that
<rick_h_> figured I'd listen to you guys talk and it'll put me to sleep :P
<axw> wallyworld: ah, I just noticed there's a page 2 :)
<axw> hence why I didn't see the upgrade step before
<jog> wallyworld, I'm seeing "ERROR juju.cmd supercommand.go:323 connection is shut down" intermittently with 1.21. Do you know anything about that?
<wallyworld> no :-(
<jog> happens when attempting 'juju deploy'
<jog> mainly seeing it with MaaS 1.8
<jog> but I'm looking for more instances of it on other substrates
* ChanServ changed the topic of #juju-dev to: https://juju.ubuntu.com | On-call reviewer: see calendar | Open critical bugs: None
<jog> wallyworld, the red failures from Feb 11 and 12 on this page are examples: http://juju-ci.vapour.ws:8080/job/test-maas-1_8/
<wallyworld> jog: sadly our CLI sucks - it doesn't report the real root cause error
<wallyworld> it just gives that connectio shutdown
<wallyworld> so you'd need to go look at the debug log
<jog> wallyworld, I've added --debug for future runs, will that help?
<wallyworld> jog: maybe, but likely not - it's the server side logs (machine-X.log or allmachines.log) that would be needed
<jog> ok, I'll see what I can do about capturing those...
<dimitern> jog, you could bootstrap the environment with "logging-config: <root>=INFO,unit=DEBUG"
<dimitern> jog, and then the unit-X.log files are likely to contain useful data, in addition to the machine logs
<jog> dimitern, alright that's an entry in the environments.yaml right?
<dimitern> jog, yeah; for existing envs, you can also change it with juju set-env logging-config='<root>=INFO,unit=DEBUG'  << thumper, this should work, right?
<jog> dimitern, with MaaS... juju status gives the dns-name: as a FQDN only know to the MaaS server for example: 'maas-node-402.maas'
<jog> most clients don't point there DNS as the MaaS server, so they can really do anything with that information.
<jog> Is it possible to provide the IP? dimitern if you're not the right person to ask do you know who is?
<dimitern> jog, that's true I guess - for that reason I had fixes a few issues around api endpoints (e.g. resolving hosts if possible)
<dimitern> jog, by juju you mean?
<jog> the 'juju status' output
<dimitern> jog, how about public-address field for units?
<dimitern> jog, I think this is an IP even with MAAS
<jog> it's the same, there is an example: http://juju-ci.vapour.ws:8080/job/test-maas-1_8/22/console
<dimitern> jog, how about juju run --unit dummy-source/0 'unit-get private-address' ?
<dimitern> jog, well, you can also (e.g. in a script) just try resolving the dns-name using the maas DNS server I guess
<jog> dimitern, I'll try the unit-get method and yeah I can script a way to resolve the dns-name... just wondering if it's a usability issue.
<dimitern> jog, it has been brought up before
<jog> ok, I thought I'd seen a bug for it before
<dimitern> jog, and now in pretty much all other providers we do return resolved IPs instead of hostnames, except for maas (as it prefers to refer to nodes by dns names)
<jog> dimitern, so I must be doing something wrong when setting logging-config:
<jog> I've tired both "logging-config: <root>=INFO,unit=DEBUG" and "logging-config: '<root>=INFO,unit=DEBUG'" in my environments.yaml
<jog> but get ERROR juju.cmd supercommand.go:323 there was an issue examining the environment: unknown severity level "INFO,unit=DEBUG"
<dimitern> jog, ah, I see - so the second one is fo the command line only, as in juju set-env logging-config='<root>=TRACE'
<dimitern> jog, while the first one is for envs.yaml
<dimitern> jog, but as now I actually checked "juju help logging", the format uses "; " not "," as separators
<menn0> jam: ping
<davecheney> review board is a piece of shit
<davecheney> why does it publish all your comments, when you push the "publish" buttont
<davecheney> ****EXCEPT***** the ones where you have commented in the review branch (not review diff) screen
<davecheney> that has a seperate, partially obscured, publish button
<dimitern> davecheney, you can do it for single comments, but IIRC you have to publish each one after adding, rather than hitting the "review-wide" publish
<davecheney> dimitern: the way it works out for me
<davecheney> there are comments when you are reviewing the diff
<davecheney> then there is the hovering button at the top of the page to publish or review them
<davecheney> there is the 'review' and 'ship it' buttons on the view diff and view review pages
<davecheney> but if you're having a conversation in the comments section (not on the view diff)
<davecheney> there is an entirely seperate and different "publish" button hidden just below the list of issues on the view reviews page
<davecheney> you only know if you ened to push it by looking on the dashboard
<davecheney> seeing the icon is orange (?) not blue, and hte mouse over hover says "comments drafted'
<dimitern> yep, not quite thought through UX
<dimitern> also, beware - if you're editing a comment and you wifi connection drops (or is down) when you submit the comment (still draft) UI-wise it appears on the page, but a few seconds later you're taken to a nasty "connection failed" page and "back" doesn't help getting your comment text back
<davecheney> yay, cloud!
<thumper> dimitern: we append the unit=DEBUG unless they explicitly set unit to be otherwise
<thumper> dimitern: so you were mostly right
<thumper> be careful about setting <root> to debug
<thumper> as that'll get golxc and other libraries that also use loggo
<thumper> juju=DEBUG is good
<wallyworld> axw: i've updated the storage pools PR for your viewing "pleasure"
<axw> wallyworld: sorry, I was out before. will look shortly
<TheMue> morning o/
<Muntaner> good morning devs o/
<Muntaner> gsamfira: hi! adventuring myself in trying http://www.cloudbase.it/ws2012r2/
<jam> menn0: poke
<jam> I tried poking earlier but didn't see you online
<axw> wallyworld: reviewed
<axw> sorry for the delay
<frankban> dimitern: morning, I updated my branch as suggested, could you please take another look?
<dimitern> frankban, yes, I'm already looking
<dimitern> frankban, thanks for doing all that so quickly btw!
<frankban> ty
<dimitern> frankban, 99% of the PR looks great, I just want to double-check TestMachinePrincipalUnits as I've seen it fail on ppc64el recently due to some sort ordering
<frankban> dimitern: sortedUnitNames failing on ppc?
<frankban> sounds weird
<dimitern> frankban, nope, sorry - run-unit-tests-trusty-amd64 build #2145 was the one that failed
<dimitern> frankban, http://juju-ci.vapour.ws:8080/job/run-unit-tests-trusty-amd64/2145/console
<dimitern> frankban, it seems the culprit is line #1077 - units[3], err = s3.AllUnits()
<dimitern> frankban, so I was thinking if I could suggest a fix for you to include there
<frankban> dimitern: go ahead
<dimitern> frankban, will do, once I can see where's the issue and reproduce it :)
<frankban> dimitern: heh, ok ty
<Muntaner> guys - a non Juju related question here - is "sed" the best way to edit conf files via a bash script?
<frankban> dimitern: can it be something related to units slices mutated by append? should we reslice in sortedUnitNames(append(a.units, a.subordinates...))?
<dimitern> frankban, perhaps, still looking
<voidspace> dimitern: TheMue: dooferlad: making coffee, be with you in a couple of minutes
<TheMue> voidspace: ok
<dimitern> voidspace, ok
<jam> team standup
<dimitern> TheMue, voidspace, dooferlad, oh, yeah - it's team standup now and ours after
<Muntaner> gsamfira: ping
<voidspace> oh yeah
<voidspace> firefox crash again, yay
<wallyworld> axw: team meeting?
<axw> wallyworld: bollocks, be there in a minute
<jam> mgz: did you want to attend the Juju team meeting ?
<dimitern> frankban, you've got a review BTW
<frankban> dimitern: ty
<wallyworld> axw: thanks for review, will look real soon
<voidspace> TheMue: dimitern: dooferlad: standup?
<dooferlad> voidspace: works for me
<TheMue> voidspace: sounds good for me
<dimitern> voidspace, TheMue, dooferlad, I need 5m
<voidspace> ok, I'll go make more coffee
<TheMue> aka one cigarette ;) *scnr*
<dimitern> but go ahead :)
<dimitern> voidspace, dooferlad, ok, let's do it
<voidspace> omw
<frankban> dimitern: done, can I $$merge$$ it?
<dimitern> frankban, I'm having a last look
<dimitern> frankban, go for it, and thanks again!
<frankban> dimitern: ty, should I have to propose it also against 1.21 and 1.22?
<Muntaner> gsamfira: ping!
<gsamfira> Muntaner: pong
<dimitern> frankban, yes, please, but in both 1.21 and 1.22 my patch has landed, so you'll need to do some cherry picking
<frankban> dimitern: should we land the revert patch first?
<dimitern> frankban, I don't think it's needed, as your patch builds on top of it anyway
<Muntaner> hi gsamfira :)
<Muntaner> just installed the Windows Server 2012 R2 evaluation by cloudbase
<Muntaner> the VM is in the same subnet of Juju VMs
<Muntaner> now... how can I interact with this VM with Juju?
<Muntaner> or am I confused about what I can do?
<gsamfira> Muntaner: a few basics first. Juju has several "providers" it can use to create a juju environment (manual, local, MaaS, OpenStack, etc). The manual provider attempts to connect to an already installed machine and add it to juju. This provider however is not yet supported on windows. It will be in the (hopefully) not to distant future, just not yet.
<gsamfira> Muntaner: if you used the image I pointed you to, that means you have an Openstack environment all set up
<gsamfira> correct?
<Muntaner> gsamfira: yes, everything is working fine atm
<Muntaner> downloaded the qcow2 image of Windows, created a VM in the same subnet of juju VMs
<Muntaner> juju actually is bootstrapped on this OpenStack environment
<gsamfira> cool
<Muntaner> (which is a private cloud, basically)
<Muntaner> if you need screens/logs, ask me whatever it's needed :)
<gsamfira> have you done the whole juju-metadata generate-image song and dance? Or are you using the official simplestream feed?
<Muntaner> gsamfira: did nothing with juju :/ just downloaded the image, added it to OpenStack via glance, and created a VM with the image in it
<axw> wallyworld_: review can wait for tomorrow, but FYI http://reviews.vapour.ws/r/923/
<Muntaner> gsamfira: I did that stuff in the past days, to bootstrap my OpenStack with Juju
<wallyworld_> axw: np, will try and look
<Muntaner> and basically I used an Ubuntu Cloud 14.04 image to do all the stuff
<gsamfira> Muntaner: okay. So you have not yet deployed a massive indispensable infrastructure using juju yet :). There is one last hoop to jump through to get windows in. And that is juju agent and simplestreams that includes a Windows image
<Muntaner> gsamfira: afraid I don't know how that works: (
<gsamfira> Muntaner: no worries. I can guide you through it.
<gsamfira> I just need to get a handle on what you already have
<Muntaner> gsamfira: ask me whatever you need to know :)
<Muntaner> gsamfira: background. We set up a private OpenStack cloud, with all of the components installed on a single server. We have everything working (cinder, glance, swift, etc). Then, we bootstraped Juju on this Openstack. After some problems we got with metadatas (I opened a launchpad about it), also this step has been successfull, and I have Juju working on this Openstack. Now, I wanted to understand how Juju and Windows machine are r
<gsamfira> so first things first. Lets get you the widows agent tools.
<gsamfira> I'm guessing you are using 1.21.2 ?
<Muntaner> 1.21.1-trusty-amd64, gsamfira
<gsamfira> perfect. Building you a windows binary now
<frankban> dimitern: 1.22 backport https://github.com/juju/juju/pull/1594
<dimitern> frankban, looking
<dimitern> frankban, LGTM
<frankban> dimitern: thanks, shipping it
<dimitern> frankban, +1
<wwitzel3> so I am thinking in the rsyslog worker there is the handle config changes, that reacts based on new state servers getting added, so I think I can force the recreation of the rsyslog server certs there and that should fix up the connection issues
<wwitzel3> re: https://bugs.launchpad.net/bugs/1417875
<mup> Bug #1417875: ERROR juju.worker runner.go:219 exited "rsyslog": x509: certificate signed by unknown authority <canonical-bootstack> <logging> <regression>
<mup> <juju-core:In Progress by wwitzel3> <juju-core 1.21:Triaged by wwitzel3> <juju-core 1.22:Triaged by wwitzel3> <https://launchpad.net/bugs/1417875>
 * dimitern steps out for 1/2h
<voidspace> dimitern: when all the pieces are in place, what's the command line incantation to create a new container on a machine?
<dimitern> voidspace, sorry, in a meeting, bbiab
<voidspace> dimitern: no problem, dooferlad remembered anyway
<dimitern> +1
<TheMue> phew, first restructured test works. but nested map[string]interface{} for marshaling tests are a pain in the ass
 * TheMue needs to write some helper
<dimitern> TheMue, consider using something like type M map[string]interface{} + helpers around it in the tests
<TheMue> dimitern: that's how I changing it currently ;)
<dimitern> TheMue, cheers :)
<dimitern> voidspace, so I'll propose the PCII() API tomorrow as it happens
<natefinch> This is why you shouldn't use map[string]interface{} in the first place :)
<katco> natefinch: +1
<dimitern> natefinch, :) if you can avoid it, yeah
<dimitern> natefinch, however writing generic json serialization tests with strings like `....25 lines later...`[1:] is even worse
<TheMue> ah, this looks definitely better
<dimitern> :) I had a feeling it will
<dimitern> ok
<dimitern> I'm outta here
<TheMue> dimitern: yeah, strings are even worse
<dimitern> g'night all, see you tomorrow ;)
<TheMue> dimitern: cu
<katco> dimitern: take a look at that PR tomorrow?
<dimitern> katco, oh, sorry - I promise (bookmarking now)
<katco> dimitern: no worries at all... have a wonderful evening :)
<frankban> dimitern: here is the 1.21 backport: https://github.com/juju/juju/pull/1595 could you please take a look? (slightly different code base there)
<dimitern> katco, thanks!
<dimitern> frankban, ok, I can take one last review I guess :)
<katco> dimitern: i see how it is! haha jk ;)
<dimitern> (for a backport I reviewed already..)
<frankban> dimitern: ty
<frankban> dimitern: oh, didn't notice you were done for the day, sorry
<ericsnow> voidspace: FYI, the webhook worked for PR 1588 yesterday when I tried (after the RB downtime)
<dimitern> frankban, np
<voidspace> ericsnow: cool, good to hear
<dimitern> frankban, ship it!
<frankban> dimitern: thanks! and have a nice evening
<dimitern> ta!
<frankban> sinzui: how do I spell that https://github.com/juju/juju/pull/1595 fixes that bug?
<sinzui> frankban, include fixes-1420403
<voidspace> frankban: $$fixes-1420403$$ I believe
<frankban> sinzui: in the description?
<voidspace> frankban: in the merge comment
<natefinch> you just need the string fixes-1420403 in a comment somewhere, and then the standard $$merge$$ will work
<voidspace> frankban: doesn't need to be in the $$ but it's common
<natefinch> ^
<frankban> ty
<katco> is anyone familiar with the WADL format?
<voidspace> right, going jogging
<voidspace> probably back around in a bit
<katco> have fun voidspace
<voidspace> katco: thanks, good luck with the WADL :-)
<katco> voidspace: hehe thanks
<sinzui> abentley, my azure delete script says juju-functional-backup-restore-tyx8o23ojf is about 24 hours old. If you agree via the console it is more than 12 hours old, I will run the script in real
<perrito666> sinzui: that last sentences terrified me
<sinzui> perrito666, I am dealing with azure instances being left behind after destroy env. and since the Azure console doesn't work well with chrome or firefox, I am scripting an executioner
<perrito666> the onlypart that terrified me is backup-restore :p
<perrito666> btw, just to fill you with expectancy, I PRd the last piece of the new restore
<sinzui> thank you perrito666
<sinzui> I think the restore test job dies because of azure. we never actually bootstrapped http://juju-ci.vapour.ws:8080/view/Juju%20Revisions/job/functional-backup-restore/2180/console
<sinzui> well, I can see we aren't running any env like that, so I will use my new axe
<perrito666> who here knows anything about multiwatcher?
<jw4> perrito666: a very little bit...
<perrito666> git says I am looking for francesco banconi
<rick_h_> perrito666: that's frankban who's EOD working with dimiter
<jw4> perrito666: ah
<perrito666> rick_h_: tx, ill try to catch him in my AM
<rick_h_> perrito666: we use it on the GUI to track all the things
<perrito666> rick_h_: I assume you mean megawatcher and not frankban :p
<rick_h_> perrito666: yea pretty much :)
<perrito666> "so frank, here is the debug log, you read it all and let us know when things change"
<rick_h_> for everyone running a gui, hope you read fast
<jw4> lol
 * perrito666 sees a chance to "import" a new dell for him.. anyone got one of the new xps13 and ran linux on that?
<perrito666> I kind of lack return policy where I am :p
<natefinch> perrito666: google will help, or try posting on warthogs.  I think the XPS laptops are generally pretty far up the chain of laptops that Linux geeks want support for (and that Dell wants linux support for), so usually they work pretty well pretty soon after release.
<abentley> sinzui: looking...
<abentley> sinzui: Not seeing it.  Did you go ahead?
<sinzui> abentley, I did. I found the job that created it and it was 24 hours old
<perrito666> now, this is rather frustrating:  Error: entity mismatch; got len 1; want 1
<jw4> perrito666: uh oh.. which test?
<perrito666> storeManagerStateSuite.TestStateBackingGetAllMultiEnv
<jw4> perrito666: hmm - just makes me nervous because I was in that general area recently
<perrito666> jw4: I know, but this broke something that its still not prd
<perrito666> so worry not, alwhough the test's output is all but helpful, I might fix that
<jw4> perrito666: lol
<jw4> whew
<jw4> perrito666: interesting... it looks like setUpScenario returned only one entity instead of two (my naive reading of it)
<jw4> perrito666: units not entities
<perrito666> jw4: ?
<jw4> perrito666: n/m -- I'm chasing the squirrel of understanding your error
<perrito666> jw4: you should see my codebase for it
<perrito666> :)
<jw4> perrito666: heh
<perrito666> I have a big change in the middle that breaks Unit.SetStatus and Unit.Status
<jw4> perrito666: that explains it
<perrito666> jw4: buuut
<perrito666> there is a deepequals for 2 maps
<perrito666> and then, if that fails, you tell me their lenght missmatches, assuming that the only thing that can fail is getting different lenghts
<jw4> perrito666: that's making more sense as I look at the trunk version of assertEntitiesEqual too
<jw4> although it looks like there should be more descriptive information after that first message
<jw4> but logged at INFO instead of ERROR
<perrito666> jw4: there is, but its Logf
<perrito666> which sucks in my opinion
<jw4> perrito666: +1
<sinzui> abentley, a newly stuck machine in azure
 * sinzui get's his new axe
<perrito666> grc does not work with go's log output... what have I dont to deserve this monochromatic nightmare
<perrito666> sinzui: do you know why ssl-hostname-verification could be not working for canonistack?
<sinzui> perrito666, no, I never worked that out
<perrito666> sinzui: that means this is a known issue?
<sinzui> perrito666, it is and I am looking for the bug.
<perrito666> jw4: ok I might ask for your help
<perrito666> :)
<perrito666> do you know how does *watcher prompt for status changes on units?
<jw4> perrito666: ah
<jw4> gimme a sec
<jw4> perrito666: if I understand your question... allWatcherStateBacking has a method Watch(in chan<- watcher.Change) which sets up a watcher for each collection it's watching
<perrito666> jw4: tx a lot
<jw4> in this case a backingUnit
<perrito666> bbl
<marcoceppi> who created juju-backup ?
<ericsnow> marcoceppi: thumper?
<thumper> nope
<thumper> marcoceppi: the plugin was created by a team effort
<thumper> just over a year ago
<thumper> while I was on leave :)
<marcoceppi> thumper: it's not a very good plugin, it doesn't have a --description or --help flag and breaks juju help plugins
<marcoceppi> ;)
<marcoceppi> is it in the juju-core repo?
<marcoceppi> I'll submit a patch
<thumper> not sure... maybe
<thumper> marcoceppi: yes
<ericsnow> marcoceppi: cmd/plugins/juju-backup/juju-backup.go
<thumper> cmd/plugins/juju-backup
<marcoceppi> thumper: well, interesting. the juju-backup I have is a bash script
<thumper> marcoceppi: yep, that's the one
<thumper> there is no .go at the end
<marcoceppi> oic
<ericsnow> oh, yep :)
<ericsnow> I was thinking of restore
 * marcoceppi goes for is 3rd commit to core
<marcoceppi> well
<marcoceppi> it's kind of moot now, why even maintain the juju-backup command if it just shells out to core again?
<natefinch> marcoceppi: juju-backup is a bad plugin for a lot more reasons than its description and help ;)
<natefinch> marcoceppi: we're replacing the old backup command with a built-in command.  It is a lot more maintainable
<natefinch> sorry, gotta run, but ericsnow and perrito666 are the backup and restore masters :)
<marcoceppi> well, it's worse than that, everytime anyone runs juju help plugins, the backup plugin is executed
<marcoceppi> so it's just dumping backups everywhere
<marcoceppi> it's a pretty big bug, but if 1.21 fixes this (by removing the old logic) then fine
<marcoceppi> but 1.21-beta4 still executes the plugin from what I can tell
<ericsnow> 1.22 is when we added the new backup command (and updated the plugin)
<ericsnow> marcoceppi: we kept the plugin around for backward compatibility
<ericsnow> marcoceppi: but it should probably still handle --help and --description
<marcoceppi> ericsnow: so if I wanted to patch this for 1.21 how would I do this?
<marcoceppi> I'll file a bug now, but since 1.22 is like the next release
<ericsnow> handle those two options at the beginning of the shell script
<ericsnow> there's already a bug
<marcoceppi> right, I understand technically how to implement it in the script
<hatch> hey could someone point me to the golang file where the api routes are defined?
<marcoceppi> I just don't know the whole process
<marcoceppi> I'll just open a merge request
<ericsnow> #1389326
<mup> Bug #1389326: juju-backup is not a valid plugin <backup-restore> <plugins> <juju-core:Triaged> <https://launchpad.net/bugs/1389326>
<hatch> found it
<ericsnow> hatch: apiserver/apiserver.go (see the Server.run)
<hatch> ericsnow: thanks - I just found it :) github's search is not too great :)
<voidspace> ok, g'night all
<marcoceppi> ericsnow: https://github.com/juju/juju/pull/1596
<ericsnow> marcoceppi: thanks
<ericsnow> marcoceppi: would you do me a favor and log into reviews.vapour.ws
<marcoceppi> ericsnow: okay, logged in.
<ericsnow> marcoceppi: we have a webhook on github for PRs that adds the patch to our review tool there
<ericsnow> marcoceppi: but it only works if you've logged in at least once :)
<ericsnow> marcoceppi: so the PR should be updated now with a link to the review request
<ericsnow> marcoceppi: you should also set the bug status to "In Progress"
<ericsnow> marcoceppi: thanks for working on this, by the way :)
<ericsnow> marcoceppi: that patch looks good
<ericsnow> marcoceppi: you just need to get a "senior reviewer" to check it out before merging
<marcoceppi> ericsnow: thanks, updated the testing stuff
<ericsnow> marcoceppi: cool
<jw4> does anyone know of a state transition diagram for the uniter?
<katco> jw4: no, but if you happen to make one, i would love for you to do it in plantuml and place it in the docs like we recently did for storage: https://github.com/juju/juju/blob/master/doc/storage-model.txt
<jw4> katco: oh cool - I'm 20 lines into a graphviz .dot file...
<katco> jw4: relevant doc if you're interested: http://www.plantuml.com/state.html
<jw4> katco: I'll check it out.
<katco> jw4: plantuml uses graphviz under the covers, but has a much simpler syntax
<jw4> katco: nice.  Yeah I have 3.5 modes semi-accounted for
<katco> jw4: online interface if you want an easy repl: http://www.plantuml.com/plantuml/
<jw4> katco: suhweet!
<jw4> katco: the storage model is quite sophisticated compared to what I was doing... I aspire... :)
<katco> jw4: :) axw did that one, and -- as far as i know -- without ever having touched plantuml prior
<katco> jw4: in my experience they tend to grow quite organically
<jw4> yes, I imagine with a good foundation people like to incrementally improve them over time
#juju-dev 2015-02-13
<axw> jw4 katco: yep, that was baby's first plantuml diagram :)
<jw4> axw: lol
<katco> anastasiamac: lmk when you've forwarded it
<katco> ACK! one of my rules was deleting it!
<jw4> katco: you mean the 'killfile anastasiamac' rule?
<katco> jw4: lol no
<jw4> :)
<katco> jw4: it deleted an email from alexisb as well =|
<katco> jw4: gmails filtering syntax doesn't work like i thought it did apparently =|
<jw4> urg.
<anastasiamac> katco: waht rule do u have? delete all from anyone starting with "A"?
<jw4> hahaha
<katco> anastasiamac: LOL
<wallyworld_> axw: here's a trivial 1.22 fix when you get a chance http://reviews.vapour.ws/r/927/
<axw> looking
<axw> wallyworld_: are all the clouds updated?
<wallyworld_> axw: the packaging change is for the deb in the cloud archive repo
<axw> right, ok
<wallyworld_> so the cloud images don't need updating
<axw> wallyworld_: LGTM
<wallyworld_> ty
<axw> wallyworld_: http://www.reddit.com/r/golang/comments/2vo357/if_you_use_jetbrains_intellij_for_development_the/
<axw> you use intellij right?
<wallyworld_> yeah
<wallyworld_> i use a go plugin from someone on github
<wallyworld_> this might be a different one
<wallyworld_> oh, no same one
<wallyworld_> i normally compile from source as i've done a patch or two to it
<axw> wallyworld_: http://reviews.vapour.ws/r/923/, PTAL
<wallyworld_> sure
<wallyworld_> axw: did you push? still the old rev
<axw> wallyworld_: bleh, I guess the hook didn't transfer to RB
<wallyworld_> np, i look in gh
<axw> wallyworld_: I've just rebased and pushing again, I've deleted that file
<wallyworld_> ok
<axw> wallyworld_: btw I don't think the storage/pool package should be depending on storage/provider, it should be the other way around if anything
<axw> storage/provider is common providers... I don't think the pool package doesn't need to know about it
<wallyworld_> yeah, the dependencies are a little messy
<wallyworld_> pool uses provider to reference ProviderType
<wallyworld_> maybe defaultpool should move
<wallyworld_> axw: done, i hate it how gh sends comments before you have a chance to correct them
<axw> wallyworld_: heh yeah :)
<axw> sorry, I should've waited
<wallyworld_> np :-)
<anastasiamac> axw: how idid u come accross the idea article? r u thinking of converting to the dark side?
<axw> anastasiamac: I just saw it on http://www.reddit.com/r/golang
<axw> and no, I am not :)
<anastasiamac> axw: ic :D
<anastasiamac> axw: m sure if they got runtime debugging going, it would convert a few ..
<wallyworld_> works for me
<anastasiamac> wallyworld_: debugging works for u? like stepping through at runtime?
<wallyworld_> yep
<wallyworld_> but it doesn't go over the api
<wallyworld_> so limited use
<anastasiamac> oh i c...
<katco> anastasiamac: i can step through code in emacs as well :)
<Muntaner> good morning!
<TheMue> Muntaner: o/
<perrito666> morning
<dimitern> perrito666, o/
<TheMue> heya perrito666
<dimitern> voidspace, dooferlad, standup?
<TheMue> dimitern: see you're in but it doesn't work
<voidspace> dimitern: omw
<perrito666> frankban: ping
<frankban> perrito666: morning
<perrito666> hello :)
<perrito666> frankban: I broke your code and defintely could use a bit of guidance fixing it
<frankban> perrito666: hope I can help, what's up?
<perrito666> frankban: so, this is the deal, I am working on having agent status and unit status split up
<perrito666> what used to be status for unit, now is status for an agent entity, that holds nothing else other than status
<perrito666> and unit now has a different status with a new globalKey
<perrito666> so, for transitions sake, unit uses the same globalKey than it used to for most things except status
<perrito666> with your last addings to mega/multi watcher it seems that if I am watching agent (that is what you actually want to know) it never gets informed when ports change
<perrito666> and if I watch unit, it never gets informed of the other changes :)
<perrito666> I might add agent and unit to the watcher and split things up
<perrito666> but I will most likely break whatever you are using the watcher for
<perrito666> so I could use some light in that department
<perrito666> oh and al of this before coffee
<frankban> :-)
 * perrito666 tries to defeat the lazyness to turn on the expresso machine
<frankban> perrito666: so the status for the unit is already updated by watching a separate collection right?
<perrito666> if I let the code as is, yes, it watches the unit and gets updates for port changes (although the states are not the one you would expect)
<perrito666> and then you loose the agent statuses
<perrito666> if I change it to watch agent instead, you loose the ports
<perrito666> so I definitely need to watch both
<frankban> perrito666: I am not sure I understand how status and ports are related, perhaps you can show me some code, or we could have an hangout?
<perrito666> frankban: I can do both :)
<frankban> perrito666: https://plus.google.com/hangouts/_/canonical.com/gogogo?authuser=1
 * perrito666 checks that he can speak english this early, check
<frankban> lol
<perrito666> frankban: hold a sec, my computer jsut los sound... because of reasons
 * perrito666 restart
 * perrito666 is in trying to join the call to long
<perrito666> there, you go, wrong authuser
<perrito666> frankban: you froze
<perrito666> frankban: but that's ok I got the info I needed, Ill let you know whenever this is ready to land so you can take a look
<frankban> perrito666: my machine decided to freeze :-/ I am back in the hangout
<perrito666> frankban: brt
 * perrito666 wonders who designed his computer and didn't add a kb key for play/pause
<mgz> I filed bug 1421606 as a blocker
<mup> Bug #1421606: TestAddServiceStorageConstraints fails on ppc64 <ci> <regression> <test-failure> <juju-core:Triaged> <https://launchpad.net/bugs/1421606>
<perrito666> frankban: look into chrome://gpu if your hardware acceleration is dissabled you migh need to hack a bit your chrome launcher to bypass dri check
<frankban> perrito666: good to know, ty
<aznashwan> time-appropriate greetings to everyone! just wanted to consult you guys a little on something
<aznashwan> I'm currently working on getting CentOS fully supported (cloudinit and sshinit-capable), my first point of concern being abstracting away the differences between apt and yum (mostly for sshinit purposes)
<aznashwan> my question is, how necessary is it we set up apt-package pinning, I see it's only actually done in a couple of places and does not seem (from what I can discern) to be that necessary really. would dropping the whole pinning process be too much to take?
<perrito666> aznashwan: without knowing where and why I cant tell you for sure
<aznashwan> perrito666: my bad. they're declared here: https://github.com/juju/juju/blob/master/cloudinit/cloudinit.go#L32
<perrito666> aznashwan: not very explicit of what is that for
<perrito666> aznashwan: doesn't yum support some sort of pinning?
<aznashwan> perrito666: and the only place one is used (apart from a couple of test files), is here: https://github.com/juju/juju/blob/master/environs/cloudinit/cloudinit.go#L370
<perrito666> that is a rather important one
<aznashwan> perrito666: yes it does, but for settling priorities for whole repositories, not for a single package available in multiple sources
<perrito666> aznashwan: you dont want to en up with an unsupported cloud tools
<perrito666> aznashwan: my take, just add a mock implementtion of pining for the moment
<aznashwan> perrito666: true, but this gets us to a bigger problem: that's a cloud tools repo full of .deb's (which is a topic we'll be pitching next week, about how we also need rmp's for all the specific stuff, like the juju specific mongo package you guys have...)
<perrito666> aznashwan: I dont think that old app to install debs in redhat still exist right ? :)
<aznashwan> perrito666: that's a good question, either way it wouldn't be too much work, just the juju-mongodb package and these tools, which I suspect you guys have built automatically, and the main juju package for CentOS...
<aznashwan> perrito666: will look further into the matter, and will take your advice for now and just work around this
<perrito666> aznashwan: seems the easiest way for the moment
<aznashwan> perrito666: much obliged :D
<Muntaner> gsamfira: o/
<Muntaner> I'll be back at work on windows + juju on Monday
<jam> perrito666: is someone looking at https://bugs.launchpad.net/juju-core/+bug/1421606 I just saw its blocking trunk
<mup> Bug #1421606: TestAddServiceStorageConstraints fails on ppc64 <ci> <regression> <test-failure> <juju-core:Triaged> <https://launchpad.net/bugs/1421606>
<jam> i realize that ideally axw or wallyworld_ would be looking at it
 * perrito666 looks
<jam> but I think its past their EOD
<jam> (and thus past their EOW, I believe)
 * perrito666 hears an incoming email from axw as soon as jam said that
<wwitzel3> perrito666: he sets them up on notifies from IRC
<perrito666> lol
<perrito666> jam: but short answer is no, no one was looking at that, I guess we will have to since that seems to lock CI :)
<jam> perrito666: ype
<jam> yep
<perrito666> jam: incidentally, isn't today like saturday for you?
<jam> perrito666: yeah, but I had a big meeting, so I was around, and tried to submit one of my backlog packages, respond to email, etc.
<wwitzel3> jam: lots of people or very important? ;)
<jam> wwitzel3: very important
<jam> spec review with Mark, though hopefully we'll get that regularly scheduled on a workday for me :)
<perrito666> ah the infamous: "meeting on saturday or unemployment on monday" :p
<wwitzel3> jam: ahh, which spec?
 * perrito666 runs to see his spec to make sure it hasn't changed
<jam> wwitzel3: well, we're hopefully going to be doing regular weekly chats about features we're working on. though today's was about the Juju Unit and Service States (aka charm health)
<jam> s/States/Status/
<perrito666> jam: :( I thought we where done with that
<jam> perrito666: nothing major. mostly just moving the stuff we discussed in the overview into the core of the doc
<wwitzel3> jam: nice
<TheMue> hmm, is writing "shit it" due to friday afternoon?
<perrito666> TheMue: ?
<perrito666> dislexic are we
<perrito666> ?
<TheMue> typo during review, thankfully not published w/o correction
<TheMue> ;)
 * dimitern steps out for ~1h
<ashipika> hi all.. a question: trying to bootstrap my ec2 environment in eu-west-1.. but i'm getting the following error: error: invalid value "arch=amd64 cpu-cores=1 cpu-power=100 mem=1740M root-disk=8192M availability-zone=eu-west-1a" for flag --hardware: unknown characteristic "availability-zone"
<ashipika> 13:56
<ashipika> juju version 1.22-alpha1-trusty-amd64
<ashipika> also juju (at least this version) does not seem to know about t2.micro instances (free tier eligible ) if i specify --constraints 'instance-type=t2.micro'
<wwitzel3> ashipika: you can type juju help ec2-provider for specific help with EC2, but the placement directive should just be zone, not availability-zone
<wwitzel3> ashipika: also looking at our instance types, you are right, we only know about t1.micro atm
<ashipika> wwitzel3: zone=<availability-zone-name>
<ashipika> wwitzel3: but then it says: unknown constraint zone
<wwitzel3> ashipika: right, the zone placement should be outsize the constraints
<wwitzel3> ashipika: juju bootstrap zone=name --constraints=""
<ashipika> wwitzel3: juju bootstrap zone="eu-west-1c" âupload-tools    ->  unrecognized args ["zone=....
<ashipika> wwitzel3: ah.. juju bootstrap âto zone=eu-west-1c ....
<wwitzel3> ashipika: you got there first :), was just typing that, my fault .. I've never actually used zone with bootstrap, only with add-machine, and with add-machine you don't need to specifiy a --to
<ashipika> wwitzel3: not solved the problem, though.. still getting
<voidspace> dimitern: so when you say forwarding needs to be setup in container initialisation, you mean from the "initialiseAndStartProvisioner" method of ContainerSetup.
<ashipika> wwitzel3: error: invalid value "arch=amd64 cpu-cores=1 cpu-power=100 mem=1740M root-disk=8192M availability-zone=eu-west-1c" for flag --hardware: unknown characteristic "availability-zone"
<ashipika> ERROR failed to bootstrap environment: subprocess encountered error code 1
<wwitzel3> ashipika: right, you need to remove that availability-zone from your constraints
<ashipika> wwitzel3: i ran -> juju bootstrap --to zone=eu-west-1c --upload-tools
<ashipika> wwitzel3: and the same error without âto
<wwitzel3> ashipika: try running a destroy-environment (you may have to use --force), to clean up, then retry bootstrap
<ashipika> wwitzel3: did.. a few times already.. after every failed attempt
<wwitzel3> ashipika: you can check ~/.juju/environments , probably an old amazon.jenv hanging around
<ashipika> wwitzel3: nah.. deleted .juju and ran juju init..
<wwitzel3> ashipika: hrmph .. then I don't know, you may have found a bug, unless someone else here has some ideas?
<ashipika> wwitzel3: trying with region set to us-east-1 in the .yaml config.. if that fails i'll create a bug report
<TheMue> dimitern: btw, why do we use int for ports, instead of uint16?
<Muntaner> gsamfira: ping
<turicasto> hi to everyone!
<dimitern> TheMue, it's doesn't matter in practice
<dimitern> TheMue, i.e. saving a few bytes at (de)serialization time is negligible
<TheMue> dimitern: I'm not talking about parameters, but as a field type which only allows uint16 values. a port number -1 would be strange ;)
<jw4> turicasto: o/
<rogpeppe> TheMue: using int means that you get a better failure mode if someone happens to get some arithmetic wrong and passes a negative number
<TheMue> rogpeppe: a better one? uints can't even be negative
<rogpeppe> TheMue: if you accidentally substract 64 from 62 and pass -2, you don't really want it to be treated as 65534
<rogpeppe> TheMue: better to have it fail with an out of bounds error
<TheMue> rogpeppe: arg, yes, this arithmetic behavior
<rogpeppe> TheMue: there's a similar argument for not allowing negative slice indexes like in python
<dimitern> TheMue, you mean in network.Port ?
<TheMue> dimitern: yep
<dimitern> TheMue, yeah, that sounds like a good idea, I'd suggest adding this to your list of things to change in the next PR :)
<TheMue> dimitern: Number is an int and so could have invalid values
<TheMue> dimitern: shit, I shouldn't have asked
<TheMue> :D
<dimitern> TheMue, they are validated internally, but yeah
<dimitern> ;)
<TheMue> dimitern: one of the arguments for static typed languages is to have more safety. thankfully go provides very detailed types here (ok, not uint48 *lol*)
<TheMue> or uint128 for uuids, but that better would be a bitstring
<dimitern> TheMue, +1
<jw4> do we do pull requests for just adding a deprecation comment?  https://github.com/juju/charm/pull/84
<dimitern> TheMue, I'd even go further and suggest having a type PortType uint16 in the network package and use it everywhere for port values
<TheMue> dimitern: +1
 * TheMue always likes the simple type definition in Go
<dimitern> TheMue, yeah, and you can even have methods on it;)
<TheMue> dimitern: yeah, that's cool
<perrito666> ericsnow: wwitzel3 ?
<rogpeppe> dimitern, TheMue: a large but totally trivial change: https://github.com/juju/juju/pull/1601/files
<rogpeppe> dimitern: i'd appreciate a quick review so that it doesn't get stale, if poss - there are no manual changes there at all.
<dimitern> rogpeppe, will have a look
<rogpeppe> dimitern: ta!
<TheMue> rogpeppe: currently standup, but will look then
<rogpeppe> TheMue: ta
<wwitzel3> TheMue: http://reviews.vapour.ws/r/932/
<wwitzel3> TheMue: that is for fixing https://bugs.launchpad.net/juju-core/+bug/1417875
<mup> Bug #1417875: ERROR juju.worker runner.go:219 exited "rsyslog": x509: certificate signed by unknown authority <canonical-bootstack> <logging> <regression>
<mup> <juju-core:In Progress by wwitzel3> <juju-core 1.21:Triaged by wwitzel3> <juju-core 1.22:Triaged by wwitzel3> <https://launchpad.net/bugs/1417875>
<TheMue> wwitzel3: already opened, will review after standup
<wwitzel3> TheMue: thanks
<TheMue> wwitzel3: +1
<dimitern> rogpeppe, LGTM
<rogpeppe> dimitern: thanks!
<rogpeppe> dimitern: aw, remind me of the juju magic word for submitting a PR please?
<dimitern> rogpeppe, $$anything-between-two-dollar-signs$$
<dimitern> :)
<TheMue> dimitern: thx, you've been faster
<dimitern> np
<TheMue> rogpeppe: won't merge due to missing fix, but is reviewed. so should be comming soon
<rogpeppe> TheMue: cool. hopefully it won't conflict.
<katco> dimitern: hey sorry, what are you meaning when you say "d"?
<perrito666> katco: delete
<katco> perrito666: ty
<dimitern> katco, :) d==delete this line
<katco> dimitern: so are you referring to whitespace in a lot of those?
<perrito666> katco: which you would know if you used vi :p
<dimitern> katco, but d it's nicer and geeky :D
<katco> haha
<katco> perrito666: shouldn't it be dd?
<mgz>  dd would be clearer :P
<dimitern> katco, yeah, I don't mind it that much though
<mgz> katco won...
<perrito666> d-> is enough :p
<dimitern> dd only if you use vim
<katco> dimitern: i tend to use whitespace to aid in readability
<perrito666> katco: I actually interrupted my lunch to troll you, and you counter troll me
<perrito666> :p
<dimitern> and C-k is longer to type :)
<katco> perrito666: i muahaha at you sir!
<dimitern> katco, I understand
<TheMue> *LOL*
<dimitern> katco, so I'll leave it up to you ;)
<katco> dimitern: ok, ty for the review :)
<dimitern> katco, I'm not done yet :)
<katco> dimitern: oh i know, but i wanted to say ty :)
 * katco making some tea
<dimitern> katco, np
<dimitern> katco, you have a review
<katco> dimitern: tyvm!
<katco> dimitern: hey rq about the SignedURL
<katco> dimitern: i thought this might come up... the new v4 signing messes with request headers, so there's no concept of a signed url
<dimitern> katco, I'd like to read about this more if you have the source
<katco> dimitern: check out aws/sign.go
<dimitern> katco, also, is the v4 signing process now mandatory for all s3 operations?
<katco> dimitern: https://github.com/go-amz/amz/blob/v1/aws/sign.go#L82
<katco> dimitern: it is not; you pass in which signing you'd like into S3 ctor
<dimitern> katco, ok so for older versions URL and SignedURL still make sense to exist, and at least URL should be implementable for V4
<katco> dimitern: for v2, signedurl could still work
<katco> dimitern: for URL, it didn't make much sense to me. what would you do with it?
<dimitern> katco, get a link to something in your bucket that's accessible to public (permission-wise)
<katco> dimitern: ah ok
<dimitern> katco, :)
<dimitern> katco, we do still use this in juju IIRC
<dimitern> katco, and even if we didn't and URL/SignedURL no longer make sense, we can't just drop them - such a change needs a version bump (e.g. a separate PR for v3-unstable)
<katco> dimitern: that was the idea :)
<ericsnow> jam: thanks for the reply re: fakes
<katco> dimitern: so if you'd like to keep SignedUrl, how should we detect that the signing method supports a signed url?
<ericsnow> jam: I sent a follow-up to get some clarification
<dimitern> katco, I see, well - is this something we'll need to use in juju soon?
<katco> dimitern: it's targetted for 1.23. feature freeze is 2w from today.
<dimitern> katco, so that's why it needs to go in v2, but because of the versioning rules, we can't also drop stuff from the exported interface
<dimitern> katco, ...in v2, but we can in v3-unstable
<katco> dimitern: is versioning of goamz tied to something? why can't we do a cut?
<dimitern> katco, out of respect for any potential users
<katco> dimitern: they're free to remain on v2 aren't they?
<dimitern> katco, yes
<dimitern> katco, but once your change lands, their code won't compile anymore with v2
<dimitern> if they use URL and/or SignedURL
<katco> dimitern: my change is targetted against v3-unstable isn't it?
<dimitern> katco, aww :/
<dimitern> katco, that's my bad, sorry - I should've looked
<katco> dimitern: oh no worries.. i was very confused! lol
<dimitern> katco, and I actually asked you to re-target it :)
<dimitern> katco, ok, then it's fine
<dimitern> katco, still isn't URL worth keeping?
<katco> dimitern: sure, i can add that back in
<dimitern> katco, thanks
<dimitern> katco, I'll update the review - how about the live tests?
<katco> dimitern: it will be a function that is: .Region.ResolveS3BucketEndpoint(b.Name)+"/"+path
<katco> dimitern: i still need to do that
<dimitern> katco, however, just a sec
<katco> dimitern: as you pointed out, obviously unit tests pass
<dimitern> katco, if this needs to go in juju for 1.23, then you'll need to cherry-pick what's relevant from this and backport it to v2, isn't it?
<katco> dimitern: any reason we can't move juju to v3?
<dimitern> katco, we could, but this'll mean carefully integrating changes from v2, renaming v3-unstable to v3 and branching v4-unstable of it
<dimitern> katco, as we can't depend on v3-unstable for a release in juju
<katco> dimitern: right
<katco> dimitern: i'm good with whatever you suggest
<dimitern> katco, there are not many things to port from v2 to v3 IIRC
<dimitern> katco, then let's agree to do this migration - I have a couple of PRs for goamz which I'll need to land before the freeze, so I'll re-target them to v3 as well
<katco> dimitern: ok cool
<dimitern> katco, cheers!
<dimitern> katco, I didn't quite get your response on whether you've run go test -check.v -amazon in s3/
<katco> dimitern: :) and progress marches inexorably forward!
<katco> dimitern: no i haven't done that yet
<dimitern> katco, as it should :)
<dimitern> katco, ok, just a reminder then
<katco> dimitern: yep, ty i didn't know about that flag
<katco> dimitern: i was going to test manually
<dimitern> katco, that's fine (ideally we'd like a live test using both s3test and live AWS), but at minimum let's ensure no existing local/live s3test/AWS tests break
<katco> dimitern: will do. thanks for the pointers and your help.
<dimitern> katco, no worries, thank's for bearing up with me :)
<katco> dimitern: it was not a burden; great questions
* ChanServ changed the topic of #juju-dev to: https://juju.ubuntu.com | On-call reviewer: see calendar | Open critical bugs:  1416928 1421621 1421606
<dimitern> thanks even
<dimitern> :)
<voidspace> dimitern: ping
<dimitern> voidspace, pong
<voidspace> dimitern: hey, hi
<voidspace> dimitern: I'm really struggling to test the lxc-broker changes
<voidspace> dimitern: I could just mock out the call that takes the NetworkInfo and check that the results of PrepareContainerInterfaceInfo are used
<voidspace> dimitern: but that seems yucky
<dimitern> voidspace, hmm, let me think
<voidspace> dimitern: and as far as I can tell the results of calling broker.StartInstance don't include network details to check
<voidspace> surprisingly result.NetworkInfo is empty (nil) so I can't inspect that
<dimitern> voidspace, do you have a wip branch up to have a look?
<voidspace> dimitern: yep, hang on
<voidspace> dimitern: I'll push what I have
<dimitern> voidspace, cheers
<voidspace> ah, there might be an lxc.conf file I can look at...
<voidspace> just discover3ed
<dimitern> voidspace, so the result of StartInstance after PCII() did its job must have NetworkInfo populated
<voidspace> dimitern: shall I check that first?
<dimitern> voidspace, yes please
<voidspace> well, it doesn't but I can confirm that our code is being called...
<voidspace> dimitern: I'll check the conf file and see if it has testable info
<dimitern> voidspace, because this is later needed in other cases
<dimitern> voidspace, so, the result of PCII() is used to generate lxc.conf, cloud-init userdata, and to run a few commands essentially
<voidspace> right
<dimitern> voidspace, so all these should be testable, but I might've missed something
<voidspace> testing the commands would just duplicate the production code in the tests so seems pointless
<voidspace> dimitern: see TestNetworking in this branch
<voidspace> dimitern: https://github.com/voidspace/juju/compare/container-prepareprovisioner
<dimitern> voidspace, looking
<voidspace> dimitern: the output of lxc.NetworkInfo is "[]network.InterfaceInfo(nil)"
<voidspace> so NetworkInfo on the StartInstanceResult is not populated
<voidspace> (and I haven't moved forwarding setup to container initialisation yet because that's trivial to do - although also not easy to test)
<ericsnow> niemeyer: thanks for the feedback on "fakes"
<dimitern> voidspace, not in my demo branch, but it should be populated
<ericsnow> niemeyer: it's very insightful and has given me plenty to think about :)
<voidspace> dimitern: oh, you mean this is something additional that should be done?
<dimitern> voidspace, well, my plan is to support passing non-empty args.NetworkInfo to StartInstance() for cases like "start with statically configured network" or "create these 3 nics like this", etc.
<voidspace> ok
<niemeyer> ericsnow: Glad it's being useful
<dimitern> voidspace, then, inside PCII() handle what's needed and return an updated NetworkInfo which is then returned by StartInstance for other uses
<dimitern> voidspace, e.g. to update the firewall rules or something else that happens on the host of the newly provisioned container
<voidspace> ok
<voidspace> dimitern: by the way, pretty sure we'll get the keys to the new house on Wednesday
<voidspace> dimitern: so I'll be in Monday and Tuesday
<dimitern> voidspace, +1, sure
<voidspace> dimitern: thanks
<dimitern> voidspace, so coming back to your question
<dimitern> voidspace, these are a few ideas of what needs testing there
<dimitern> voidspace, 1. given a networkInfo and provided networking and address allocation is supported, verify we get an updated networkInfo out of start instance
<dimitern> (updated like - having an Address, DNSServers and GatewayAddress, as well as ConfigStatic)
<dimitern> voidspace, 2. test local dns servers are parsed and added, when available (mocking where you read them from ofc)
<dimitern> voidspace, 3. the necessary commands for setting up routes, etc. are called (also by mocking - there are a few similar examples in the cmd/ package IIRC and around cloudinit/sshinit)
<dimitern> voidspace, 4. for lxc specifically, check the lxc.conf is updated as expected, and the cloud-init userdata gets updated
<dimitern> voidspace, all these are just the happy path tests
<dimitern> voidspace, the failures need testing as well - like if PCII fails or one of the other steps fail
<dimitern> voidspace, how does this sound?
<voidspace> dimitern: so that will mean *adding* the networkInfo :-)
<voidspace> dimitern: lxc.conf does include some details from PCII() (network name and MAC)
<voidspace> dimitern: testing 2 & 3 will effectively mean duplicating the commands straight from the code into the test
<voidspace> dimitern: so they're not very good tests
<dimitern> voidspace, well, not quite :)
<voidspace> dimitern: mock and record the calls, check the calls match the expected calls
<dimitern> voidspace, the command tests can separately test the behavior around parsing resolv.conf and setting up iptables, etc.
<voidspace> dimitern: what do you mean by "command tests"?
<dimitern> voidspace, while the start instance tests can just check the commands get called or fail
<voidspace> voidspace: executeCommands is called several times (3 I believe)
<voidspace> oops, dimitern ^^
<dimitern> voidspace, I mean the tests around localDNSServers etc.
<voidspace> dimitern: the only way to test that localDNSServers is used is to record what executeCommands is called with and check it matches the production code
<voidspace> dimitern: I mock readFile and I can check the pre-canned data is used, so I can test the file is read
<dimitern> voidspace, let's have a chat on monday ;)
<voidspace> which more-or-less amounts to the same thing
<voidspace> dimitern: just to clarify though
<dimitern> voidspace, I need to sit down and write this first
<voidspace> dimitern: you need the NetworkInfo populated on StartInstanceResult?
<dimitern> voidspace, I'm thinking of several levels of tests
<dimitern> voidspace, yes, indeed
<voidspace> right
<voidspace> I'll look at adding that
<dimitern> voidspace, ta!
<dimitern> happy weekends everyone! ;)
<perrito666> dimitern: likewise
<dimitern> perrito666, ;) cheers
<marcoceppi> natefinch  : any chance we could get this looked at? It's break charm testing and has kind of a weird long standing low priority https://bugs.launchpad.net/juju/+bug/802117
<mup> Bug #802117: juju ssh/scp commands cause spurious key errors <ssh> <Amulet:Triaged> <pyjuju:Triaged> <juju-core:Triaged> <juju (Ubuntu):Triaged> <https://launchpad.net/bugs/802117>
<sinzui> marcoceppi, ci works around the issue with a rule like this
<sinzui> host 10.* 172.* 54.85.* 15.185.*
<sinzui>   StrictHostKeyChecking no
<sinzui>   UserKnownHostsFile /dev/null
<marcoceppi> sinzui: I can't expect every user to do that though
<sinzui> marcoceppi, I expect ever cloud user and lxc user has come across this given time and has realised they don't want those ips in the files
<marcoceppi> :\ I have several long running instances in Amazon that I would like hostkeychecking with
<alexisb> dude marcoceppi that bug has been around a long time
<marcoceppi> alexisb: yeah, it totally has! Someone just hit it on the mailing list. I've always just removed offending keys but surely we can do better
<alexisb> marcoceppi, we can it is a matter of prioritizing it amount the 800+ other bugs
<alexisb> so tag it, and send me a mail
<marcoceppi> Tag it what?
<natefinch> marcoceppi: just got back to the keyboard.  Sounds like alexisb has you covered.
<natefinch> haha, that bug is older than all my kids
<alexisb> natefinch, mine too! ;)
<alexisb> marcoceppi, that is an excellent question, we need better tags, for now send me a note with the bug number
<marcoceppi> alexisb: ack
<natefinch> haha that's from before the project was called juju :)
<marcoceppi> Yeah, it's been lingering around for a bit ;)
<natefinch> Hey, sweet, monday is a holiday in the US
<perrito666> natefinch: here too, and also tuesday
<perrito666> natefinch: what is it there?
<voidspace> right
<voidspace> EOW
<voidspace> g'night all
<voidspace> see you on Monday
<voidspace> except natefinch ...
<sinzui> marcoceppi, "charmers" is the official tag for ecosystems stakeholders
<natefinch> perrito666: George Washington's birthday (first President of the US).... guessing that's not what you're celebrating ;)
<perrito666> natefinch: carnival :p
<sinzui> marcoceppi, and ha ha. regarding those ssh rules I pasted. we don't have those rules for azure and this just just failed http://juju-ci.vapour.ws:8080/job/azure-quickstart-bundle/211/console
<marcoceppi> <3
<natefinch> wwitzel3: you wanted some pictures of the snow?  Here you go: http://imgur.com/a/yqfQS
<TheMue> so, 8:15pm, time for a Single Malt, bye folks, enjoy your weekends
<natefinch> I love the way that I can search for gimp in the software center and it comes up, but if I click on it, it says it can't be found
<perrito666> natefinch: ???
<natefinch> $ sudo apt-get install gimp
<natefinch> [sudo] password for nate:
<natefinch> Reading package lists... Done
<natefinch> Building dependency tree
<natefinch> Reading state information... Done
<natefinch> Package gimp is not available, but is referred to by another package.
<natefinch> This may mean that the package is missing, has been obsoleted, or
<natefinch> is only available from another source
<natefinch> E: Package 'gimp' has no installation candidate
<mbruzek> jog ping?
<jog> mbruzek, pong
<mbruzek> jog is the link to the kubernetes reports http://reports.vapour.ws/kubernetes ?
<mbruzek> Is my url incorrect or is it not working again?
<jog> http://reports.vapour.ws/charm-summary/kubernetes
<mbruzek> jog thanks I spaced on the URL
<jog> mbruzek, http://reports.vapour.ws/charm-summary is the top level for charms and lists all that have test results. If you want to narrow it down to a particular charm you can append /"short charm name" to the URL
<mbruzek> jog that is logical, I was not aware
<jog> mbruzek, or you can find the charm you are interested in on the top level page and just click on it's Charm column entry to get the filtered page.
<natefinch> perrito666: for reference, somehow "main" got unchecked from my list of package sources
<perrito666> ouch
<natefinch> yay for utopic :/
<perrito666> you should try vivid
<ericsnow> natefinch: could you take a quick look at https://github.com/juju/testing/pull/51
<ericsnow> natefinch: niemeyer convinced me Fake wasn't the right name :)
<katco> ericsnow: fwiw that's the nomenclature i've always seen as well (mocks, stubs)
<natefinch> ericsnow, katco:  I generally use stub as a verb, to stub out an interface, which generally means "make it compile but don't have any logic".  However, if there are some well-known nomenclatures, it makes sense to follow those, even if I think they're silly :)
<ericsnow> natefinch: yep
<ericsnow> natefinch: so all that patch does it change the name
<katco> natefinch: i was the same, but wallyworld pointed out to me awhile ago that stub had an actual meaning.
<katco> natefinch: as far as agreeing on nomenclature, that's rather important... i.e. it's how humans communicate ;)
<perrito666> katco: oh no biggie, we can code a shim to translate between our nomenclatures
<ericsnow> katco: see http://martinfowler.com/articles/mocksArentStubs.html#TheDifferenceBetweenMocksAndStubs
<katco> perrito666: whassa shim? you mean facade? (tongue firmly in cheek)
<natefinch> ha
<katco> ericsnow: yeah that's exactly what i read a few months ago
<ericsnow> katco: Fowler cites http://xunitpatterns.com/Mocks,%20Fakes,%20Stubs%20and%20Dummies.html
<katco> ericsnow: also, regarding the end-to-end vs. mock/stub debate
<ericsnow> katco: and that guy has the noble goal of sorting out the nomenclature :)
<katco> ericsnow: i feel like we're rehashing this. i sent out an email a bit ago about the new top-level featuretests package
<ericsnow> katco: eh, I'll still argue both have their place :)
<katco> ericsnow: and my understanding of what the team had agreed upon for going forward: mocks/stubs embedded along-side code. happy-path end-to-end functional tests in featuretests/*
<ericsnow> katco: right
<katco> ericsnow: maybe i confused myself. it just seemed like we were headed back towards that conversation on the ML
<ericsnow> natefinch: thanks
#juju-dev 2016-02-15
<wallyworld> rick_h__: something weird is going on; the ec2 config schema for master is identical to 1.25, so control bucket support should also be the same. so a bug would be good
<wallyworld> oh wait, you said rax?
<wallyworld> how is control-bucket getting into rackspace config
<wallyworld> huh
<wallyworld> and there it is
<wallyworld> looks like someone cut and paste some ec2 code into rackspace provider
<wallyworld> rick_h__: ^^^^ so yeah, that's a bug sadly
<rick_h__> wallyworld: ok, will file and go back to previous alpha for demo hopefully
<rick_h__> wallyworld: is there anything I can pass it to make it less cranky in alpha2?
<wallyworld> yeah, sorry, it's a one line fix by the looks, just a cut and paste error
<wallyworld> rick_h__: sadly no, i don't think so
<rick_h__> wallyworld: k, ty for checking for me
<wallyworld> rick_h__: np, i'll follow up with QA to see how our tests can improve
<wallyworld> rick_h__: if you need a build for demo, i can do that for you
<rick_h__> wallyworld:
 * wallyworld waits in anticipation
<rick_h__> wallyworld: ty for the QA follow up.
<wallyworld> haven't done it yet, but will do tomorrow when we meet :-)
<rick_h__> wallyworld: guessing we're not trying to create-model on each provider
<wallyworld> guess not :-(
<rick_h__> wallyworld: yea, just got me thinking about how that slipped by
<wallyworld> rick_h__: i have a feeling a lot of the QA scripts are pre-JES
<axw> anastasiamac: would you please review this small one? https://github.com/juju/juju/pull/4417
<anastasiamac> axw: of course \o/
<anastasiamac> axw: looks gr8! tyvm
<axw> anastasiamac: ta
<anastasiamac> axw: quartz could b multi-coloured too... and does not imply location (best opals are from Oz \o/) and does not start with "O" like some other teams already...
<anastasiamac> :D
<axw> anastasiamac: good points
<anastasiamac> wallyworld: axw: show-contorller cleaned up http://reviews.vapour.ws/r/3814/
<wallyworld> yay
<axw> anastasiamac: will look shortly
<axw> oh, I already did shipit
<anastasiamac> axw: u did but I've added some output that u might want to agree to...
<axw> anastasiamac: ok
<anastasiamac> axw: no rush, whenever u get a chance \o/
<axw> anastasiamac: why change to using file-based store?
<axw> anastasiamac: in the tests
<axw> wallyworld: a thought just occurred to me, we could change the "restore-bootstrap -b" on its head, and add a "--restore" flag to bootstrap
<axw> wallyworld: not for now, maybe later
<axw> wallyworld: I think that would make intent a bit clearer
<wallyworld> hmm, not a bad idea, i'm asking anastasiamac to do a one pager on this, so she can consider it
<anastasiamac> axw: easier to load in tests...
<anastasiamac> and actually clearer what m loading too...
<axw> anastasiamac: I'd rather we stop messing with the filesystem if possible. I suspect my change to jujuclienttesting (merging now) would make it clearer/easier for the in-mem case
<axw> anastasiamac: I won't block it for now, but next time could you please look at the new MemStore, see if it's easier with the new struct?
<axw> anastasiamac: ... and if not, try and make it easier, so we don't have to touch the filesystem
<anastasiamac> axw: k, m happy to wait for ur changes, rebase and updte the tests.
<wallyworld> axw: one liner http://reviews.vapour.ws/r/3858/
<axw> wallyworld: LGTM
<wallyworld> ta
<anastasiamac> axw: altho, considering list-controller tests depend ont he same stuff.. i'd rather land this and then fix both command testsonce in memory store lands
<axw> anastasiamac: fine by me
<anastasiamac> axw: awesome \o/
<anastasiamac> axw: so if u r happy with smaple output (in current tests probably esier to see), then m going to respect ur original ship-it and land
<axw> anastasiamac: just a moment please, still looking
<anastasiamac> axw: nps
<axw> anastasiamac: couple of small things, and one biggish one -- I think we shouldn't be showing passwords by default
<axw> wallyworld: ^^
<axw> agree?
<wallyworld> of course
<anastasiamac> axw: when u say "by default" do u mean not at all?
<anastasiamac> or do u mean have a flag?
<axw> cherylj: thanks for letting aaron know -- I've been emailing him about this. Aaron says it's a trivial change
<cherylj> axw: ah, ok
<axw> anastasiamac: I mean, clear out the password flag unless the user provides "--include-passwords" or something
<anastasiamac> also isnt this command only displays to users their own accounts?... we are not going out..
<axw> anastasiamac: someone might want to get the addresses for their controller, and inadvertantly show a conference room their password
<anastasiamac> axw: ha. i'll add a flag
<anastasiamac> cherylj: pm-ed u
<axw> wallyworld: I've created a "backup/restore 2.0" card under Juju 2.0
<wallyworld> great ty
<axw> the board is getting out of hand :p
<wallyworld> yes, too much work :-(
<axw> wallyworld: do you have time to review another one? https://github.com/juju/juju/pull/4419  -- ignoring the first commit, and the jenv.go stuff in the second one
<axw> (covered by other PRs)
<wallyworld> axw: just heading out, will get to it as soon as i can
<axw> wallyworld: ok, nps
<axw> argggggghhhhhhhh. have the state tests gotten worse, or were they always this shit
<anastasiamac> axw: probably always
<axw> seems like every 2nd test run fails because "no reachable servers" or similar
<anastasiamac> :(
<bradm> anyone know what generating /etc/rsyslog.d/25-juju.conf ?  its got a dodgy IP in it that I need to remove, from virbr0 as well as all the juju state nodes.  it only appears to be in the state nodes
<menn0> thumper or waigani: this will be used to replace most of what the current statestarter worker does: http://reviews.vapour.ws/r/3860/
 * thumper leaves for waigani
<mup> Bug #1544846 changed: restore fails with could not exit restoring status <nil> <backup-restore> <ci> <regression> <test-failure> <juju-core:Triaged> <https://launchpad.net/bugs/1544846>
<waigani> menn0: sorry just saw your PR looking now
<mup> Bug #1544846 opened: restore fails with could not exit restoring status <nil> <backup-restore> <ci> <regression> <test-failure> <juju-core:Triaged> <https://launchpad.net/bugs/1544846>
<menn0> waigani: np
<waigani> thumper: btw didn't spot anything weird in the diff. Though I release I merged in tip, not latest blessed master. But still, they're not seeing it at all in master.
<waigani> *realize
<thumper> waigani: weird
<mup> Bug #1544846 changed: restore fails with could not exit restoring status <nil> <backup-restore> <ci> <regression> <test-failure> <juju-core:Triaged> <https://launchpad.net/bugs/1544846>
<thumper> waigani: I have to head out shortly, so either check in with menn0 or we could go through it tomorrow
<waigani> thumper: will do. cheers.
<mup> Bug #1545562 opened: Restore assumes systemd present on machines <backup-restore> <juju-core:Triaged> <https://launchpad.net/bugs/1545562>
<mup> Bug #1545563 opened: Cannot deploy service after restoring <backup-restore> <juju-core:Triaged> <https://launchpad.net/bugs/1545563>
<mup> Bug #1545568 opened: api/backups/restore.go has no unit tests <backup-restore> <tech-debt> <juju-core:Triaged> <https://launchpad.net/bugs/1545568>
<mup> Bug #1545562 changed: Restore assumes systemd present on machines <backup-restore> <juju-core:Triaged> <https://launchpad.net/bugs/1545562>
<mup> Bug #1545563 changed: Cannot deploy service after restoring <backup-restore> <juju-core:Triaged> <https://launchpad.net/bugs/1545563>
<mup> Bug #1545568 changed: api/backups/restore.go has no unit tests <backup-restore> <tech-debt> <juju-core:Triaged> <https://launchpad.net/bugs/1545568>
<mup> Bug #1545562 opened: Restore assumes systemd present on machines <backup-restore> <juju-core:Triaged> <https://launchpad.net/bugs/1545562>
<mup> Bug #1545563 opened: Cannot deploy service after restoring <backup-restore> <juju-core:Triaged> <https://launchpad.net/bugs/1545563>
<mup> Bug #1545568 opened: api/backups/restore.go has no unit tests <backup-restore> <tech-debt> <juju-core:Triaged> <https://launchpad.net/bugs/1545568>
<mup> Bug #1545589 opened: Destroying a model leaves stale current-model file <destroy-environment> <juju-release-support> <juju-core:Triaged> <https://launchpad.net/bugs/1545589>
<cherylj> wallyworld, axw, could you guys take a look at http://reviews.vapour.ws/r/3861/ ?
<axw> cherylj: I don't understand this comment: This is necessary as
<axw> / the error type returned from a facade call is rpc.RequestError
<axw> / and we cannot use params.IsCodeUpgradeInProgress
<axw> cherylj: RequestError is an rpc.ErrorCoder, so should be usable in params.ErrCode
<axw> (which is what IsCode... functions use under the hood)
<davecheney> an the "code" is just a string
<cherylj> ah, I may have mixed up my comments.  We can't use params.IsCodeUpgradeInProgress, because the code returned from the rpc call *isn't* apiserver.CodeUpgradeInProgress
<wallyworld> cherylj: sure, looking
<cherylj> it's the inUpgradeError returned from the upgrading_root
<cherylj> it was hard to keep track of all the type mismatches
<cherylj> I'll update the comment
<cherylj> actually, maybe I'll go back to what it was before, and add in a new function into upgrading_root.go to check IsInUpgradeError
<cherylj> axw: how does that sound? ^^
<cherylj> (and I mean, what I had it as before I committed)
<axw> cherylj: as in do the check on the servert, and translate to the code that the client was expecting?
<axw> server*
<cherylj> axw: that's not quite what I was thinking, although I could do that.
<axw> cherylj: can you explain more? sorry, slow. I'm not keen to have snowflakes that don't use the IsCode... functions
<cherylj> Yeah, I'm sorry, I'm super tired
<cherylj> I was going to add a func IsCodeInUpgrade()....
<cherylj> or I could have the existing in Upgrade check see if it matches CodeUpgradeInProgress or the upgrade_root.go inUpgradeErr
<cherylj> am I still not making sense?  It is after midnight here.  Maybe I should go to sleep and continue this tomorrow
<axw> cherylj: you may be, but I still don't understand :p
<cherylj> heh, ok, let me push up a proposed change
<axw> cherylj: sounds good, I comprehend code better than english
<wallyworld> axw: sorry for delay, reviewed your earlier pr, see what you think of suggestions
<cherylj> axw: did you have any other concerns with the PR?
<axw> cherylj: nothing else jumped out
<axw> wallyworld: thanks, looking in a sec
<cherylj> ok, I'm just retesting with my change.  This takes forever...
<wallyworld> axw: later when you are free http://reviews.vapour.ws/r/3862/
<cherylj> omfg why is it taking 20 minutes to do apt-get update on an AWS instance?!
<axw> wallyworld: PTAL. looking at yours now
<anastasiamac> axw: wallyworld: we don't write to models or accounts files yet, riite?..
<axw> anastasiamac: I'm working on it
<anastasiamac> axw: \o/
<anastasiamac> axw: so m not going crazy a little here.. :D
<axw> wallyworld: just one main concern, about the rpc change
<wallyworld> ok
<wallyworld> axw: with the remaining ClientStore() comment, i was really trying to look for a way not to have that method
<wallyworld> the store is really internal to the command
<wallyworld> if the method is merely used to see what's been set is nil, can we cater for that another way
<axw> wallyworld: each controller or model command will need to call ClientStore()
<axw> wallyworld: well maybe not all of them, but some of them do
<wallyworld> ok
<axw> wallyworld: e.g. list-controllers will call ClientStore() to get the store and then call AllControllers()
<wallyworld> fair enough lgtm
<wallyworld> axw: the version != 0 thing. that appeared fundamentally broken. it totally rejected rpc calls where the version was not 0, and with all the old code removed, tests failed
<wallyworld> i don't know a reason why we'd not allow rpc calls with version != 0
<axw> wallyworld: version isn't used in that code below there, so I'm a bit concerned that something is passing in a version wrongly
<wallyworld> axw: yeah, it was only used in that bogus (IMO) check
<wallyworld> why would we return an error if version != 0 ?
<wallyworld> I've tested the branch live with lxd, everythign seems fine
<wallyworld> i'd have to check again, i think the test failure was on the Admin facade
<axw> wallyworld: sorry, it just doesn't look right. if an object doesn't support versioned methods, then the client shouldn't be requesting them. can you find the object & method that's being requested?
<wallyworld> i'll check soon, just diggin into some python client stuff
<mup> Bug #1545126 changed: juju/maas do not create ptr reccords for bare metal servers with multiple networks <MAAS:New> <https://launchpad.net/bugs/1545126>
<cherylj> ugh, this upgrade in progress error is funky - the error string is put into the Message and not the Code
<anastasiamac> cherylj: omg, i hate being the clock but is it not 2am for u?
<cherylj> anastasiamac: it is
<anastasiamac> cherylj: wow
<dimitern> cherylj, that's because it's not a coded error - just like all generic errors it has no code and just message
<cherylj> dimitern: yeah, but I can't inspect it using errors.Cause() == upgradeErr because it's an rpc.ResultError so the types are different
<cherylj> so I need to use the check I have
<cherylj> bleh
<dimitern> cherylj, yeah, that's a result of not using concrete errors, unfortunately - and need to resort to strings.HasSuffix(err.Error(), ...) :.
<dimitern> :/
<cherylj> just got a ship it from thumper, so fuck it.  I'm merging and trying to get some sleep
<dimitern> cherylj, you should +1
<cherylj> heh
<cherylj> thanks for taking  a look at that bug, dimitern
<dimitern> no worries
<dimitern> cherylj, I hope some of my friday rant on that blocker bug helped a bit :)
<axw> cherylj: it appears that the IsCodeUpgradeInProgress only works if the original error is state.UpgradeInProgressError
<axw> cherylj: and not the one in apiserver
<cherylj> axw: yeah, I found that out the hard way yesterday
<axw> cherylj: ok. well, anyway, sleep :)
<wallyworld> axw: that rpc FindMethod() call is being asked to find the "Login" method on the "Admin" facade with version = 3. That's when we fail the test. That code comes from api/state.go Login() which tried v2 then fell back to v1 and then v0.So the only reason it was all working is due to some obsolete fallback code in that client Login() method which I removed
<axw> wallyworld: so the other versions never worked? :/
<wallyworld> master always fell bacl to v0
<wallyworld> or so the code seems to suggest
<wallyworld> there were 2 lots is params.IsCodeNotImplemented()
<wallyworld> in that api state Login()
<axw> SERVERS Y U NO REACHABLE
<wallyworld> i hate that error
<axw> wallyworld: sorry, I still need to convince myself
<wallyworld> axw: open up api/state.go
<wallyworld> see the Login() method at the top
<wallyworld> i removed the fallbacks
<axw> wallyworld: I'm *fairly* sure I don't see three Login RPC calls each time I connect though...
<wallyworld> need to check i guess, maybe it's the tests only affected. but the code path to the error makes sense. we are passing a version 3 and it complains when it has no right to
<wallyworld> the method is there on the facade
<axw> wallyworld: I'm going to pull your branch and dig a bit. if I can convince myself it's ok, I'll merge it (unless you're still around)
<wallyworld> i'll be here. i'll see what master does also
<axw> wallyworld: I think it must be tests only, because live test without that code removed works
<axw> wallyworld: at the top level we should have apiserver.anonRoot, which has its own FindMethod. I suspect some test is constructing a login facade and serving that directly
<wallyworld> axw: but live, we should still be passing the login call to anonroot i would have thought
<axw> wallyworld: yes... testing live works. it goes to anonRoot, but anonRoot is not one of those rpcreflect things that you changed
<wallyworld> ok, i'll dig into tests later fater dinner. but i still can see why we'd just blanket reject calls with non 0 version
<wallyworld> can't
<dimitern> wallyworld, axw, fwiw apiserver/doLogin calls maintenanceInProgress which fakes up a login request with a user tag
<dimitern> might be related, as I discovered while looking into why upgrade/restore didn't work as expected
<axw> wallyworld: the problem is the errRoot
<axw> wallyworld: changing that to have a FindMethod which ignores the version, and using ServeFinder does the trick
<axw> wallyworld: the reason for not accepting a non-zero version is strictness: objects of that type don't understand versions, ergo the client shouldn't request versions. if they do, they're probably doing something wrong
<axw> safer to ignore versions on a case-by-case basis
<frobware> jam: just rebooting to locate my headset...
<jam> frobware: k
<voidspace> dimitern: frobware: dooferlad: if you get a chance http://reviews.vapour.ws/r/3848/
<dimitern> voidspace, sure, looking
<dimitern> voidspace, reviewed
<voidspace> dimitern: you think the local machine will never attempt to login (your comment about that code path never being taken)?
<voidspace> dimitern: won't agents that use the api login as the local machine
<dimitern> voidspace, they'll try, but have a look in maintenanceInProgress and follow what happens when the validator return an unknown error (i.e. not UpgradeInProgress or one of the others)
<dimitern> voidspace, actually doLogin is the place
<voidspace> dimitern: hmmm...
<voidspace> dimitern: I see the code, however that returns a concrete error - and we see the "space discovery in progress" error
<dimitern> voidspace, that's why I suggested (not now, but soon) to add a concrete error for discovery in progress and check it early in doLogin
<voidspace> dimitern: which indicates to me that code path isn't being hit
<voidspace> dimitern: we hit the code path earlier which just fails - we bail out before maintenanceInProgress is called
<voidspace> the switch on concrete error types
<voidspace> dimitern: but those cases all return a restricted api - we either return full api or no api
<voidspace> mind you, not if the login succeeds
<dimitern> voidspace, yeah
<voidspace> ah, so for the local machine doLogin still fails
<voidspace> so why bother allowing local machine at all
<dimitern> voidspace, it fails for any machine
<voidspace> it will attempt to login, succeed, then double check to see if arbitrary logins work
<voidspace> when they don't it will bail
<dimitern> voidspace, if we get as far down as doCheckCreds and maintenanceInProgress
<voidspace> well, only if there's an error
<voidspace> if they logged in with local machine (e.g. the discover spaces worker which needs access to the api)
<voidspace> they should get that far and doCheckCreds should succeed
<voidspace> so it will never hit maintenanceInProgress
<dimitern> voidspace, nope, because of line 68 above
<jam> frobware: did I miss you somehow?
<voidspace> dimitern: if the login is from the local machine they will get "case nil"
<voidspace> dimitern: no error at all
<frobware> jam: nope was still there, saw you come back and thought you disconnected
<voidspace> dimitern: and if the login isn't local machine it will fail completely on line 68
<voidspace> dimitern: and that's all desired behaviour I think
<jam> frobware: yeah, I had to restart the connection, but now I don't seem to see you anymore
<frobware> jam: I got disconnected
<frobware> jam: live migration. :)
<jam> frobware: k. I'm back in the hangout
<frobware> jam: trying..
<dimitern> on error from checkCreds the s.validator is called again with a user tag.. what a mess :/
<voidspace> dimitern: right, but checkCreds shouldn't fail should it?
<wallyworld> axw: changes pushed
<dimitern> voidspace, I'd expect so
<dimitern> voidspace, but maybe it's deeper than that - e.g. something around empty uuid (for backwards compatibility), the MA trying v2 then v1 / v0 ?
<dooferlad> dimitern, voidspace, frobware: may be a tiny bit late for standup - just off to get coffee.
<dimitern> dooferlad, np
<axw> wallyworld: reviewed
<wallyworld> ta
<axw> gotta go take care of the kids for a while, bbl
<menn0> fwereade: would you mind having a look at http://reviews.vapour.ws/r/3860/ pls?
<menn0> fwereade: a bit of infrastructure for converting the state worker to work under the dependency engine
<dimitern> voidspace, standup?
<voidspace> dimitern: oops, sorry - omw
<voidspace> dimitern: frobware: uhm, I can't login
<voidspace> dimitern: frobware: I lost my phone over the weekend - I thought I had some saved codes for two factor auth in my gmail account
<voidspace> dimitern: frobware: but I don't - I'll have to contact IS to get them to turn off two factor temporarily
<voidspace> dimitern: frobware: sorry :-(
<voidspace> dimitern: frobware: dooferlad: my standup report - test fixes and discovery reliability landing now
<dimitern> voidspace, ok, np
<voidspace> dimitern: frobware: dooferlad: I've been working on having the maas provider (maasInstance) Addresses method add provider id
<voidspace> dimitern: frobware: dooferlad: that's complete but needs gomaasapi support for the spaces endpoint in the test server
<voidspace> dimitern: frobware: dooferlad: which is partly implemented but not usable (or tested) - so I've been working on that
<voidspace> when that is done I can test my branch for provider ids and land that
<voidspace> dimitern: frobware: dooferlad: caveat is that we need both the provider id *and* the space name
<voidspace> dimitern: frobware: dooferlad: so addresses out of the provider will have space name and id set - but this will be a *maas name* not a juju name for the space
<voidspace> dimitern: frobware: dooferlad: so we have to ensure it is converted before ever storing it in state or we will confuse ourselves a great deal
<voidspace> dimitern: frobware: dooferlad: *or* we add SpaceProviderName *as well*, which is annoying but might be better
<voidspace> or we just use provider id and don't set the provider space name, this might actually be better
<voidspace> but we have code that currently relies on having the name set I think
<dimitern> voidspace, let's sync up on this after standup
<voidspace> dimitern: ok
<perrito666> morning all
<perrito666> mm, odd for some operations lxd provider seems to be unregistered
<mup> Bug #1545686 opened: Multi-series not backwards compatible <juju-core:New> <https://launchpad.net/bugs/1545686>
<mup> Bug #1545686 changed: Multi-series not backwards compatible <juju-core:New> <https://launchpad.net/bugs/1545686>
<mup> Bug #1545686 opened: Multi-series not backwards compatible <juju-core:New> <https://launchpad.net/bugs/1545686>
<mup> Bug #1545686 changed: Multi-series not backwards compatible <juju-core:New> <https://launchpad.net/bugs/1545686>
<mup> Bug #1545686 opened: Multi-series not backwards compatible <juju-core:New> <https://launchpad.net/bugs/1545686>
<axw> wallyworld: there are assumptions in the code that the initial controller name == initial model name
<axw> wallyworld: so I've had to revert the model name back to controller name, from "admin"
<wallyworld> damn, i thought we could work around those
<axw> wallyworld: possibly in a follow up, but it wasn't working right
<wallyworld> sure np
<wallyworld> i wasn't fully across how deeply ingrained the assumption was
<rick_h___> :(
<rick_h___> thanks for trying!
<wallyworld> rick_h__: temporary setback, it will be fixed :-)
<axw> wallyworld: sorry about the rambling PR, the tendrils keep spreading
<wallyworld> understood
<rick_h___> wallyworld: is there anyone that can hand hold an outside commit? Looks like OCR is out today (domas)
<rick_h___> wallyworld: https://github.com/juju/juju/pull/4426 is from an outsider through the mailing list trying to get the m4 types to work
<rick_h___> wallyworld: so needs some kid gloves and "yay outside commits" love and such
<wallyworld> rick_h__: perrito666 would love to :-)
<rick_h___> ty :)
<wallyworld> he's at SOD
<rick_h___> k
<wallyworld> rick_h__: longer term, we want to query those instance types using the new aws api
<wallyworld> maybe for 2.1
<rick_h___> wallyworld: completely understand and agree
<rick_h___> yep
<rick_h___> marcoceppi: ^ fyi
<axw> wallyworld: at the very least, we should probably stop caring about the region and assume theyre the same relative costs across all
<rick_h___> marcoceppi: faster to reply than me :P
<wallyworld> axw: that is sensible, the costs are just approximate anyway
<wallyworld> used in sorting
<wallyworld> to select the cheapest by default
<marcoceppi> interesting.
<axw> I'm off, bonne nuit
<mup> Bug #1545704 opened: no-auto-upgrade not respected in environments.yaml <kanban-cross-team> <landscape> <juju-core:New> <https://launchpad.net/bugs/1545704>
<rick_h___> marcoceppi: ?
<rick_h___> marcoceppi: also fyi email on the way I need help on asap please so I can help the team out
<marcoceppi> rick_h___: I like the idea of moving aws queries out of the codebase
<rick_h___> marcoceppi: oic, yea. I more meant that we have a reviewer nominated so we don't both bug folks on it.
<rick_h___> marcoceppi: but yea, moving the instance types out is a long standing wishlist thing for the team heh
<marcoceppi> rick_h___: oh, cool. I just say I'm going to bug someone but never actually do it ;)
<rick_h___> marcoceppi: :P
<wallyworld> rick_h__: marcoceppi: until recently we haven't had the option for aws. was built into openstack from day one
<mup> Bug #1545712 opened: WARNING juju.network address.go:268 no hostPorts found in space "default" <network> <juju-core:New> <https://launchpad.net/bugs/1545712>
<rick_h___> wallyworld: yea, the new api for that data is good stuff from aws
<wallyworld> and not a day too soon
<mup> Bug #1545704 changed: no-auto-upgrade not respected in environments.yaml <kanban-cross-team> <landscape> <juju-core:Invalid> <https://launchpad.net/bugs/1545704>
<mup> Bug #1545713 opened: Lost Unit when specifying constraints incorrectly <juju-core:New> <https://launchpad.net/bugs/1545713>
<tvansteenburgh> wallyworld: you and dpb1 proceed w/o me on the python-jujuclient stuff - i can't make the meeting. if i need to be in the loop (to help with the actual work), please take notes or something.
<voidspace> frobware: dooferlad: dimitern: in sapphire room?
<voidspace> frobware: dooferlad: dimitern: our normal retrospective room, or our normal standup room?
<voidspace> I'm in sapphire alone...
<dooferlad> voidspace: https://plus.google.com/hangouts/_/canonical.com/juju-sapphire
<frobware> voidspace, normal standup
<dooferlad> voidspace: that is where andrew and I are
<voidspace> I guessed wrong...
<dimitern> frobware, voidspace, dooferlad, sorry guys just got back in, omw
<marcoceppi> wallyworld: I'll be filling in for tvansteenburgh tomorrow
<wwitzel3> the ol' bait and switch
<rick_h__> hah
<perrito666> ohh, today is a holiday in the US, that explains the silence
<rick_h__> ssshhhh
<rick_h__> we're paying respects to our presidents today
<perrito666> you clearly have better presidens than we do :p
<bogdanteleaga> do charms need to be changed in any way for 2.0? I've got one charm I've been using for a while now for testing, but it doesn't even get downloaded to the machine
<voidspace> frobware: dimitern: dooferlad: PR for gomaasapi spaces support https://github.com/juju/gomaasapi/pull/4
<dimitern> voidspace, looking
<dimitern> voidspace, what's the significance of the *Space used in server.spaces ?
<dimitern> voidspace, it is an optimization to not fetch subnets again?
<voidspace> dimitern: no, it's so that any changes persist rather than them being copied
<voidspace> dimitern: it makes them mutable
<dimitern> voidspace, right
<dimitern> voidspace, LGTM
<voidspace> dimitern: thanks
<dimitern> we should really sort out the growing code duplication in gomaasapi soon btw
<voidspace> dimitern: fair point about goroutine safety - but this is a test server
<voidspace> dimitern: and incrementing id rather than dict iteration preserves order of result by id
<dimitern> voidspace, yeah
<voidspace> dimitern: not my code but I assume that is the intent
<dimitern> voidspace, exactly :)
<dimitern> voidspace, that's the point - if the reason is not obvious, the code needs refactoring
<voidspace> dimitern: well, a comment would do
<dimitern> voidspace, +1
<dimitern> just because it's test code doesn't mean we shouldn't try to make it clean
<voidspace> dimitern: I've added a comment
<voidspace> dimitern: does $$merge$$ work here?
<voidspace> doesn't look like it
<dimitern> voidspace, cheers
<dimitern> voidspace, yes, it should
<voidspace> ah well, I'll wait a bit and see then
<voidspace> ah yes, merge request accepted
<voidspace> aaand merged
<dimitern> voidspace, sweet :)
<voidspace> back to juju then
<perrito666> wallyworld: be warned, it is starting to rain here so power might go off (just in case I dont show at the standup)
<wallyworld> yay
<axw> wallyworld: I might have to look at fixing the "juju status" code this morning, it takes 10 minutes every time I do a full test run...
<axw> killing me
<wallyworld> ouch
<axw> just the cmd/juju/status package
<davecheney> uh, why does the apiserver import the api client during testing ?!?!
#juju-dev 2016-02-16
<anastasiamac> axw: wallyworld: trivial PTAL - http://reviews.vapour.ws/r/3869/ (use in memory store)
<wallyworld> ok
<wallyworld> axw: i think that ssh fix should just be jfdi?
<axw> anastasiamac: that turned out quite neat
<axw> wallyworld: I don't think it's important enough to JFDI
<axw> wallyworld: we've lived with it for 2 years or so... :)
<rick_h__> wallyworld: ping, when you get a sec can you run me through this restore stuff? I'm missing something.
<wallyworld> rick_h__: hey sure
<rick_h__> wallyworld: https://plus.google.com/hangouts/_/canonical.com/rick?authuser=1 when you get a sec
<wallyworld> axw: wanna join
<axw> okey dokey
<anastasiamac> axw: yes. u r awesome :D
<davecheney> thumper: backport PR for 1.25 https://github.com/juju/juju/pull/4431
<thumper> davecheney: you don't normally have to worry about reviews for backports
<davecheney> oneline timesheet ?
<davecheney> i don't like the sound of this
<axw> wallyworld: has anyone changed the "juju resolved" command for 2.0 yet?
 * axw looks at the code and answers his own question
<wallyworld> no, don't think so
<wallyworld> we haven't
<axw> wallyworld: we're going to tho, right?
<wallyworld> yeah, supposedly
<wallyworld> but not this week
<wallyworld> we'll run out of time
<axw> wallyworld: sure. just want to know it's still happening
<axw> I don't think anyone likes it as it is
<wallyworld> nope
<wallyworld> i need to check notes, but in my mind it got approved
<axw> wallyworld: I think I just need to fix tests now, new-style switch is working nicely
<wallyworld> yay
<axw> wallyworld: and I've gotten rid of the current-model file (again)
<wallyworld> even better
<anastasiamac> anyone has any idea what this online timesheeting is about? per davecheney^^^
<axw> wallyworld: juju switch branch: http://reviews.vapour.ws/r/3872/
<wallyworld> axw: looking
<wallyworld> axw: rick's suggestion is show-controller and show-model without args would display the current controller / model
<axw> wallyworld: sounds good
<axw> wallyworld: kind of a pain if you just want the name though
<wallyworld> axw: i think the intent is just the name
<wallyworld> we need that for scripting
<axw> wallyworld: ok, I don't really like that then... another dual purpose command
<wallyworld> it's still a bit messed up though
<wallyworld> yup
<wallyworld> let's try it for the beta and get feedback
<axw> wallyworld: try show-controller/show-model with no args?
<wallyworld> yeah, in the absence of something better. i suggested "juju current-controller" and "juju current-model" and he didn't like it
<axw> okay
<wallyworld> but i do like my suggestions
<axw> wallyworld: if you're making the changes to registration to return the controller UUID, can you please update the "juju register" command to record all the details in jujuclient as well?
<axw> wallyworld: controller & account details
<axw> wallyworld: if that's too much, I can do it after yours is landed
<wallyworld> axw: ok, finishng tests for --share. getting lovely mgo dirty socket errors, will do registration after that if i get a chance after soccer soon
<axw> okey dokey
<dimitern> mgz, morning :)
<dimitern> mgz, it seems a couple of CI jobs have SSH issues and result in false positives for failures
<mgz> that's not a false positive
<mgz> unless a failure is the result we want?
<dimitern> the centos job succeeded apparently
<dimitern> it was marked as a failure due to wait_for_port failing eventually with no route to host, which considering we're killing the controller is to be expected
<mgz> why does that bug lead nowhere...
<dimitern> I was wondering the same :)
<dimitern> while the windows job fails similarly (after apparently succeeding) but due to python 2.7 incompatibility?
<mgz> yeah, I have a solution for that
<frobware> dimitern, ping. sync?
<dimitern> frobware, hey
<dimitern> frobware, yeah, omw - 2m
<axw> wallyworld: I'm going to look at changing the initial model name back to admin, let me know if there's something else you want me to do
<dimitern> dooferlad, voidspace, jam, standup?
<frobware> dimitern, voidspace, dooferlad: new upstream branch is `maas-spaces2'
<dimitern> frobware, cheers, pulling now
<frobware> dimitern, voidspace, dooferlad: also deleting existing branch to avoid any confusion.
<frobware> and gone
<voidspace> frobware: great
<dimitern> frobware, done
<perrito666> morning
<dooferlad> dimitern: do you have a moment to pair up on this?
<dimitern> dooferlad, ok, just give me 2m
<dooferlad> dimitern: sure, thanks
<rick_h__> wallyworld: axw  right, the thing is that adding a new command, doc, tab completing, for such a one off scripting requirement seems :/
<rick_h__> wallyworld: axw especially when I could just run switch and know I was there, or use existing commands to get the machine readable data and such
<dimitern> dooferlad, standup HO?
<dooferlad> dimitern: sure
<dimitern> dooferlad, omw
<mup> Bug #1546043 opened: unit tests leave apiserver/logsink.log behind <unit-tests> <juju-core:Triaged> <https://launchpad.net/bugs/1546043>
<wallyworld> rick_h__: i guess that needs to be balanced against a dual purpose command that is not obvious
<rick_h__> wallyworld: how is it dual purpose? It'll show the same info as normal?
<wallyworld> use case 1: switch models. use case 2. print the current model
<wallyworld> 2 differebt functions
<wallyworld> one command
<rick_h__> wallyworld: so this isn't the show-model command?
<wallyworld> rick_h__: SORRY, I THOUGHT WE WERE TALKING ABOUT JUJU SWITCH
<wallyworld> doh, caps
<wallyworld> we want to remove the function of juju switch which prints the current model
<wallyworld> if we use juju show-model instead, does that print the full yaml or a single name
<voidspace> dimitern: ping
<rick_h__> wallyworld: the full yaml of info
<rick_h__> wallyworld: which includes the name?
<wallyworld> if the full yaml, it's a bit of a pain to use in bash to get the name
<voidspace> dimitern: so, I can switch from mapping space names to id to mapping subnets to space id instead
<voidspace> dimitern: *however*, the effect is *exactly* the same
<voidspace> dimitern: because...
<voidspace> dimitern: ah no it's not
<voidspace> dimitern: forget that
<dimitern> :)
<wallyworld> rick_h__: as in `juu show-model` and assigning that to a var
<voidspace> dimitern: when maas lists subnets it only gives the space name - so I thought I still needed a name -> id map
<voidspace> dimitern: however, the subnets are listed *within the space data structure*
<voidspace> dimitern: so you already know the space id...
<voidspace> so you don't need to lookup by name
<voidspace> my bad :-)
<dimitern> voidspace, exactly, and since the discovery will list spaces rather than subnets we'll have all bits we need in 1 api call - ids and names included (both for spaces and subnets)
<rick_h__> wallyworld: sorry, was otp.
<wallyworld> np
<perrito666> wallyworld: well apparently last nights storm was a bit over average, it about 2 hs of duration it killed 3 people, broke countless trees and flooded hundreds of houses :p
<rick_h__> wallyworld: I think that list-models should indicate current model, and that show-model without an arg shows details for the current model.
<rick_h__> wallyworld: I know it's a pain to grab the name, but really it should be a simple grep'ing of the header?
<rick_h__> wallyworld: or there's tools for parsing out the yaml
<rick_h__> wallyworld: but since you're scripting it's not that it has to be simple/human one liner. You're assumption is they're running code
<wallyworld> rick_h__: sure, just having a simple cli way to print just the name is very useful and we are taking that away
<rick_h__> call the field model-name and a 'juju show-model | grep model-name' won't work?
<wallyworld> guess so
<rick_h__> wallyworld: right, but I just don't think it's useful enough for a one off command imo
<wallyworld> np, your call, we can always add it if people complain
<rick_h__> wallyworld: +1 I've been known to be wrong before :)
<rick_h__> but you did ask my opinion :P
<wallyworld> i did, and i expressed mine also. one of us will be proven to be right
 * rick_h__ bets a bottle of wine on it 
<rick_h__> let's make it interesting!
<wallyworld> ok :-)
<perrito666> we should start putting those things in the code
<perrito666> like // if you remove/add this line inform X that he/she must pay a wine bottle to Y
 * perrito666 enjoys of a rather good connection even though its only 10/2M only because every possible other user has a power outage so the whole connection is for him
<mup> Bug #1546100 opened: Upgrade 1.24.7 -> 1.25.3 fails <juju-core:New> <https://launchpad.net/bugs/1546100>
<alexisb> morning all
<perrito666> alexisb: morning
<rick_h__> morning alexisb
<perrito666> lets say that I need to destroy-controller --force, and we no longer have force, what do I do now?
<anastasiamac> perrito666: i think that kill-controller is kind of like destroy-controller-with-force
<perrito666> yup, it is
<perrito666> it is odd destroy sounds much more final than kill
<anastasiamac> perrito666: neither work really well for me... I have to restart my computer if I want to re-bootstrap after. otherwise, I get "no matching addreses" error :(
<anastasiamac> yes \o/
<perrito666> oh, I have not tried to rebootstrap
<anastasiamac> well, neither wallyworld nor axw have the same issue... deleting all caching files does not help :/ so dunno and don't have enough time to figure it out :D
<anastasiamac> so there is a chance u r not affected :D
<perrito666> karma hates me, I am most likely affected :p
<anastasiamac> perrito666: and here I thought I was the only one with bad karma
<alexisb> anastasiamac, what time is it for you?
 * rick_h___ guesses late
<perrito666> rick_h___: or early
<perrito666> 1AM?
 * anastasiamac wondering what answer alexisb would like to hear
<anastasiamac> alexisb: it's good time for me :D i *think* i solved a bug
<alexisb> I am going to bed
<alexisb> ^^ that answer
<alexisb> :) that is good
<anastasiamac> alexisb: oh. k.. yes.. i will be :D
<rick_h___> being aware at this time sounds like a bug :P
<mup> Bug #1546135 opened: Joyent region not respected <bootstrap> <joyent-provider> <juju-core:New> <https://launchpad.net/bugs/1546135>
<perrito666> rick_h___: I am sure she will come to her senses tomorrow morning when trying to re-read her code :p
<perrito666> happens to me all the time
<alexisb> frobware, I will be late to our 1x1, will ping
<mup> Bug #1546135 changed: Joyent region not respected <bootstrap> <ci> <joyent-provider> <regression> <juju-core cloud-credentials:Triaged> <https://launchpad.net/bugs/1546135>
<frobware> alexisb: probably a good idea as I have bouncing my machine a lot...
<alexisb> k
<mup> Bug #1546135 opened: Joyent region not respected <bootstrap> <joyent-provider> <juju-core:New> <https://launchpad.net/bugs/1546135>
<mup> Bug #1546135 changed: Joyent region not respected <bootstrap> <joyent-provider> <juju-core:New> <https://launchpad.net/bugs/1546135>
<mup> Bug #1546142 opened: After restore, the controller shows its local-cloud address as its public address <backup-restore> <juju-core:Triaged> <https://launchpad.net/bugs/1546142>
<mup> Bug #1546142 changed: After restore, the controller shows its local-cloud address as its public address <backup-restore> <juju-core:Triaged> <https://launchpad.net/bugs/1546142>
<mup> Bug #1546142 opened: After restore, the controller shows its local-cloud address as its public address <backup-restore> <juju-core:Triaged> <https://launchpad.net/bugs/1546142>
<natefinch> fwereade: got a minute? I have a uniter question
<fwereade> natefinch, sure
<perrito666> lol, a minute for a uniter question
<natefinch> fwereade: we're trying to update the code in the uniter so that charm-upgrade fires for updates resources as well as updated charmURL... but I seem to be having some trouble.. the hook fires ok... but it fires over and over. There's a localstate and remotestate that need to get synced and I am evidently not doing that correctly
<cherylj> perrito666: lol!
 * fwereade frantically swaps mental context
<fwereade> natefinch, ok, so you have a resolver.LocalState and a remotestate.Snapshot
<natefinch> fwereade: yes
<fwereade> natefinch, LocalState encodes how you look right now, and the Snapshot tells you how you should look, and some NextOp implementation compares the two and decides what should be done next
<fwereade> natefinch, so presumably there's some new representation of the resource version in each of those?
<natefinch> fwereade: yep.
<natefinch> fwereade: we call it the CharmModifiedVersion, just an int that increments when something in the charm changes
<fwereade> natefinch, so it's a value supplied by the apiserver? and you set it on local-state, to the value-that-triggered-the-op, when you commit whatever operation makes resource changes?
<natefinch> fwereade: I think it's that last bit that I'm having trouble with.  This stuff is all spread across like 7 files
<fwereade> natefinch, yeah, I can imagine that's the point at which it's hard to close the loop
<fwereade> natefinch, so, a bit more context: what operation is responsible for writing new charm resources?
<fwereade> natefinch, does a deploy op now Do More, or is a resource change distinct? I can imagine they'd be tricky to separate?
<natefinch> fwereade: deploy does more (you can also update resources later independently of the charm version)
<natefinch> fwereade: https://github.com/juju/juju/pull/4439/files
<fwereade> natefinch, ok, that makes sense
<fwereade> natefinch, I think all your other operations are resetting CharmModifiedVersion to 0
<fwereade> natefinch, at least, all the ones that call stateChange.apply
<mup> Bug #1545196 changed: Juju claims AWS ap-northeast-2 not found <ci> <ec2-provider> <regression> <juju-core:Invalid> <juju-core cloud-credentials:Fix Released by wallyworld> <https://launchpad.net/bugs/1545196>
<fwereade> natefinch, I'd leave that field off stateChange, and just write it explicitly into the returned *State from the deploy op
<bogdanteleaga> I did something similar not long ago, isn't something like this needed? https://github.com/juju/juju/blob/master/worker/uniter/resolver/opfactory.go#L130
<bogdanteleaga> to update the localstate
<fwereade> natefinch, listen to this man, he speaks truth
<fwereade> wrapUpgradeOp should be the right place
<natefinch> awesome, ok
<mup> Bug #1545207 changed: Rackspace os-security-groups not found <bootstrap> <ci> <rackspace> <regression> <juju-core:Invalid> <juju-core cloud-credentials:Fix Released> <https://launchpad.net/bugs/1545207>
<mup> Bug #1545207 opened: Rackspace os-security-groups not found <bootstrap> <ci> <rackspace> <regression> <juju-core:Invalid> <juju-core cloud-credentials:Fix Released> <https://launchpad.net/bugs/1545207>
<natefinch> fwereade, bogdanteleaga: thanks for the help, that seems to have done the trick!
<bogdanteleaga> great :)
<mup> Bug #1545207 changed: Rackspace os-security-groups not found <bootstrap> <ci> <rackspace> <regression> <juju-core:Invalid> <juju-core cloud-credentials:Fix Released> <https://launchpad.net/bugs/1545207>
<mup> Bug #1455629 opened: TestResumerCalls <intermittent-failure> <test-failure> <windows> <juju-core:Triaged> <https://launchpad.net/bugs/1455629>
<mup> Bug #1456725 opened: TestActionEvents fails <ci> <intermittent-failure> <test-failure> <juju-core:Triaged> <juju-core 1.22:Triaged> <https://launchpad.net/bugs/1456725>
<voidspace> dooferlad:  frobware: trivial one if you have time, but needed for my tests: https://github.com/juju/gomaasapi/pull/5
<frobware> voidspace: occasionally fails for me
<frobware> voidspace: http://pastebin.ubuntu.com/15094253/
<voidspace> frobware: weird, looking
<frobware> voidspace: that's on xenial using go1.6rc2
<frobware> voidspace: 1 in 3 times
<voidspace> frobware: it sometimes fails on an unsupported platform with an unsupported version of go?
<voidspace> hmmm... how much do I care? ;-)
<voidspace> frobware: can't get it to fail here
<voidspace> I wonder if it's a dict iteration order or something
<frobware> voidspace: heh. well, I mentioned that because I jumped to xenial today...
<voidspace> different DNSServers
<voidspace> odd
<voidspace> on a subnet
<voidspace> shouldn't be possible
<voidspace> ah, no - different order of subnets
<voidspace> so it is dictionary iteration order
<voidspace> a nuisance to fix - I'll see if I can make it deterministic
<voidspace> frobware: to be fair this PR doesn't introduce that problem
<voidspace> but it needs fixing
<voidspace> frobware: updated version shouldn't fail
<frobware> voidspace: trying again
<frobware> voidspace: thanks for supporting my unsupported combo. :-)
<frobware> voidspace: LGTM
<voidspace> hehe
<voidspace> might have been the go version
<voidspace> might not
<voidspace> but it needed fixing
<voidspace> frobware: thanks
<jose> katco: ping
<katco> jose: pong
<jose> katco: hey, just read your email and I was thinking on something similar earlier today with my team
<katco> jose: yeah?
<jose> just wanted to make sure we're on the same idea
<jose> with resources/units you mean machines?
<jose> like, a 2GB 2cores machine, and a 4GB 4 cores machine?
<katco> jose: ah, no
<katco> jose: sorry, "resources" is a new concept we're developing in juju
<katco> jose: think "binary blobs of data"
<jose> oh gotcha
<katco> jose: isos, tar files, runtimes, w/e
<jose> sorry about the confusion :)
<jose> yep
<katco> jose: no worries at all. do you think i need to send a clarifying follow-up?
<jose> it's probably just me not catching up with stuff
<katco> jose: it looks as if i have another response, so that will probably steer the conversation in the right direction
<jose> awesome, thanks :)
<katco> jose: thanks for reaching out all the same :)
<natefinch> ericsnow, katco: btw, got the upgrade-charm hook firing exactly right... working on tests and removing some unneeded code now
<ericsnow> natefinch: sweet!
<katco> natefinch: nice!
<mup> Bug #1546272 opened: doc: docs/devel/developer-layers-interfaces typo: get_remove <docs> <juju-core:New> <https://launchpad.net/bugs/1546272>
<perrito666> well, joy and happiness, a storm stronger than yesterday' s is approaching...
<ericsnow> do we have any workers where code sends a request to the worker then blocks until the result comes back from the worker?
<natefinch> ericsnow: workers are usually selfcontained... I don't think we usually send them messages.. they just read info off watchers and/or call the API if they need outside info
<ericsnow> natefinch: that's my understanding as well
<natefinch> ericsnow: my thought is that if you need to give information to a worker, you do so by putting it into mongo
<mup> Bug #1532629 changed: Juju 2.0 should use a different default JUJU_HOME <juju-release-support> <juju-core:Fix Released by wallyworld> <https://launchpad.net/bugs/1532629>
<mup> Bug #1532629 opened: Juju 2.0 should use a different default JUJU_HOME <juju-release-support> <juju-core:Fix Released by wallyworld> <https://launchpad.net/bugs/1532629>
<mup> Bug #1532629 changed: Juju 2.0 should use a different default JUJU_HOME <juju-release-support> <juju-core:Fix Released by wallyworld> <https://launchpad.net/bugs/1532629>
<natefinch> OMG, I hate trying to figure out what's actually wrong when a uniter test fails....
<katco> natefinch: it didn't get better in that regard?
<natefinch> katco: uh... no
<katco> natefinch: :(
<natefinch> katco: here's an example test failure (with literally thousands of lines of logging stripped out): http://pastebin.ubuntu.com/15095985/
<katco> natefinch: ah, is this related to my table-driven test gripe? e.g. you can't run the 1 test you think is broken?
<natefinch> katco: partially... but also that they have factored out so much of the test that you can't actually tell what it's doing, and the failure is deep in some helper function
<katco> boo =|
<perrito666> I know I said this many times before but: status tests are a soul crushing torture
<natefinch> katco: like... what is this testing? https://github.com/juju/juju/blob/master/worker/uniter/uniter_test.go#L723   The error I get is "never reached desired status"
<katco> natefinch: are the structs passed in steps to perform?
<perrito666> they seriously feel like being offered a leaf of lettuce and a small glass of hot wather after a marathon
<katco> perrito666: lol that is an incredible analogy
<perrito666> ahh never reached desired status, one of my favorites, nate you can ad c.Logf() in the status checking with more info oterwise it will mask the fact that you might be erroring
<natefinch> perrito666: thanks
<natefinch> katco: FWIW, it looks like they did break it up so it's one test per test function now
<katco> natefinch: \o/ small victories
<natefinch> katco: yep, at least it's a step in the right direction, and I don't have to run 4 minutes worth of tests for one failure
<menn0> anastasiamac: I just reviewed your simplestreams signing change
<anastasiamac> menn0: \o/
<menn0> wallyworld: juju add-user --share reviewed
<wallyworld> oh wow, thanks menn0
<wallyworld> menn0: juju register is in the cloud-credentials branch
<menn0> wallyworld: ok cool, ignore that then. I was hoping it was something like that.
<perrito666> our expected vs obtained test logs, especially the ones that show missmatch between maps are insanely user unfriendly
<wallyworld> np, all a WIP
<wallyworld> perrito666: depends if gc of js is used
<wallyworld> jc
<wallyworld> jc is better
<perrito666> wallyworld: none does a pretty print
<wallyworld> pprint is for pussies :-) real men look at base64 and can tell the error :-)
<perrito666> base64 is for weaks, real men feel the humming of the pc running tests and know the errors
<wallyworld> yes!
<perrito666> this is a beautiful example https://pastebin.canonical.com/149939/
<perrito666> that usually gets printed line wrapped
<perrito666> wallyworld: I got a LTE modem in case storm returns
<wallyworld> dedication
 * anastasiamac wonders what a definition of real women will be then...? just look at real men and know they are buggy?.. 
<perrito666> uhhh, burn
<perrito666> this modem is already paying for itself
<blahdeblah> anastasiamac: +1
<axw> katco: I take it wallyworld's suggested time doesn't suit someone? I'm afraid your invite is way too early for me :(
<katco> axw: yeah =/ it's not meant to be permanent, just until we can figure something out
<axw> katco: okey dokey
<katco> axw: the problem is that the suggested time will always interrupt someone's family dinner
<axw> katco: fair enough
<katco> axw: it's just going to be difficult, but we'll work out something
<katco> axw: also, i don't think i made this clear in the email: for now there will be 2 stand-ups until we do get that figured out
<katco> axw: so you aren't being cast off or anything :)
<axw> katco: heh :)  ok, no worries
<axw> katco: I keep getting told I'm optional...
<anastasiamac> axw: really? by whom?
<anastasiamac> axw: we r all optional in comparison to u \o/
<katco> axw: if you have imposter syndrome, i will be full on neurotic ;p
<axw> a little bit doesn't hurt
<axw> impostor syndrom.. not neurosis
<axw> wallyworld: have you seen the latest CI results for cloud-credentials? looks very sick
<axw> sick in a bad way, not fully sick
<wallyworld> axw: yes, will discuss in standup
<axw> wallyworld: ok
<perrito666> so much struct duplication
<axw> anastasiamac: I've added a comment to the tags bug, I think it should point you in the right direction
<anastasiamac> axw: \o/
<perrito666> anyone here is allwatcher savvy I have a sudden doubt
<perrito666> ?
<perrito666> nevermind
#juju-dev 2016-02-17
<perrito666> katco: how optional am I on the second standup?
<anastasiamac> perrito666: it's almost philosophical - what variations of optional there are? hard optional? soft optional? :D
<anastasiamac> perrito666: disclaimer:  this question ^^ does not imply ur optionality
<perrito666> anastasiamac: there is a whole range between "we cant live if living is without you" and  "I dont ever want so see you again"
<perrito666> (I had to google for the second song, there aren't as many hate you songs as one would expect)
<anastasiamac> perrito666: really, i was told swift covers a lot of hate ranges
<perrito666> anastasiamac: the thing is, that is very close to my bike time and I might not make it everyday
<anastasiamac> perrito666: ack. i have school drop-off at that time too, so cannot do either :/
<wallyworld> menn0: thanks for review, i've updated pr
<menn0> wallyworld: for some reason RB isn't showing any changes between diffs 1 and 2
<menn0> wallyworld: but I trust you, so ship it
<wallyworld> hmm, ok, ty, i double check
<menn0> wallyworld: it says there's files changed but when I what to see the diffs there's nothing
<menn0> looks like a RB problem
 * perrito666 sends the kind of mail that makes someone hate you
<wallyworld> menn0: i just checked github and the commit it there
<wallyworld> so wtf rb
 * menn0 looks quickly at the changes on GH
 * wallyworld waits in anticipation
<menn0> wallyworld: looks good! my ship it stands :)
<wallyworld> yay, tyvm
<wallyworld> anastasiamac: hey, i commented on the pr, sorry it needs rework
<anastasiamac> wallyworld: i disagree with ur stmt
<anastasiamac> wallyworld: quick hangout?
<wallyworld> sure
<anastasiamac> 1:1
<mup> Bug #1546348 opened: cannot use or destroy controller after bootstrap <azure-provider> <bootstrap> <ci> <ec2-provider> <gce-provider> <joyent-provider> <kill-controller>
<mup> <openstack-provider> <regression> <status> <juju-core:New> <juju-core cloud-credentials:Triaged> <https://launchpad.net/bugs/1546348>
<mup> Bug #1546350 opened: All juju models tagged with "local" <azure-provider> <ec2-provider> <gce-provider> <joyent-provider> <openstack-provider> <juju-core:New> <juju-core cloud-credentials:Triaged> <https://launchpad.net/bugs/1546350>
<perrito666> state tests take a bit too long
<perrito666> someone thought this was a useful test failure error:
<perrito666> Error: entity contents mismatch; same length 1
<anastasiamac> perrito666: juju deals with paradoxes :D
<axw> wallyworld: I think the CI issue is due to the change from <controller> -> local.<controller>
<wallyworld> ah
<wallyworld> axw: that sounds like it's Ci scripts not juju
<axw> wallyworld: model "aws-deploy-trusty-amd64" not found    <-- that'd be because it's called local.aws-deploy-trusty-amd64
<wallyworld> axw: that's the model though not the controller
<axw> wallyworld: yeah, the admin model is currently called the same as the controller
<wallyworld> axw: ah, ok, so when we create the admin model,  we need to strip local.
<axw> wallyworld: that's going to cause problems, due to code expecting controller==model
<axw> wallyworld: (without the branch I'm working on)
<wallyworld> fark
<wallyworld> axw: so we need to get your current branch landed i guess
<axw> wallyworld: yeah, I think so.
<axw> wallyworld: in the mean time, CI could prefix with local.
<axw> not sure how much effort that'd take
<wallyworld> ok, i'll let the qa folks know. i don't think they'd be up for changing scripts now
<axw> wallyworld: they'll need to change them to expect the model name to be "admin" anywya, in case that's not obvious
<axw> unless we change it to be the non-prefixed controller name as an intermediate step
<wallyworld> axw: i'm discussing with sinzui in #juju now
<blahdeblah> Anyone able to explain to me why juju does what it does to /root/.ssh/authorized_keys, and what I can do to fit in with what it does whilst still enabling what I want, which is that a charm needs to be able to write working entries in there.
<blahdeblah> There should have been a ? somewhere in that line.
<wallyworld> np
<natefinch> does anyone know how to debug the uniter tests?  The failures basically read like "Here's a big struct vaguely describing what the test is... oh something failed somewhere"
<natefinch> brb
<bradm> anyone here know about the multi user stuff?  say we were to run it on top of an openstack cloud, we would only need the top env to be deployed with juju 2.0, right?  the underlying cloud could be a stable juju, say 1.25.3?
<natefinch> back
<natefinch> bradm: yeah, the juju that deploys openstack wouldn't need to be multi-user unless you cared about having multiuser for controlling openstack itself
<natefinch> bradm: you could definitely have whatever juju deploys on top of openstack be 2.0+ to get multi-user for those services
<natefinch> bradm: the layers don't talk to each other at all.  As far as the top level juju is concerned, it doesn't know or care how openstack is deployed.
<bradm> natefinch: excellent, I thought that was the case but wanted to confirm before deploying with 1.25.3 for the underlying stack
<axw> wallyworld: RB bot seems to be asleep, here's the first fix: https://github.com/juju/juju/pull/4442
<wallyworld> ta, will look soon
<wallyworld> axw: damn, you and i are going to conflict :-)
<axw> wallyworld: where? register?
<wallyworld> SetBootstrapEndpointAddress
<wallyworld> maybe elsewhere
<axw> wallyworld: ah. my changes there are pretty trivial
<wallyworld> yeah, i have 2 tests to fix before proposing, we can land yours first
<wallyworld> axw: so just to confirm, "-m model" works, and tags are without local-
<axw> wallyworld: I'll bootstrap aws now to verify, but tested with lxd and -m model works
<wallyworld> great
<anastasiamac> axw: wallyworld: when/if u get a chance, PTAL "simple"streams PR - surface difference increased somewot :P
<axw> wallyworld: confirmed that tags don't have local in them, and I can do "juju status -m <controller-name-without-local-prefix>"
<wallyworld> awesome
<axw> anastasiamac: if you must have them at all: please move all of the bug references out of the production code, and into the tests that verify they're fixed
<axw> if we break the code, the tests will fail and the broken tests will point at the bugs
<axw> then we don't have bug references littered all over the code
<anastasiamac> axw: sure
<axw> wallyworld: based on your comment "we don't want one or the other", should we be changing the data sources to take a set of public keys?
<wallyworld> axw: we could do that, or create separate datasources. it's really a corner case for this image-metadata-url datasource. in practice, we don't have the private key used on cloud-images.u.c so maybe we just use the custom key if defined
<wallyworld> and leave off the key if not defined
<axw> wallyworld: so custom ones just use the "user signing key"? sounds sane
<wallyworld> axw: except that we also control the official key for tools
<wallyworld> and so the qa guys may want to test that with a custom source
<axw> simple :)
<wallyworld> streams :-)
<wallyworld> but we do know what's an image vs tools data source so we can make a call there
<axw> yup
<wallyworld> except for the common data source at bootstrap
<wallyworld> which points to a top level dir containing tools and images from memory
<wallyworld> maybe we construct a couple of data sources as needed and allow a signing verification error to be non fatal
<wallyworld> i think that's what we do now
<axw> wallyworld: different topic: would you be ok with temporarily reverting adding the "local." prefix altogether? then when we're through CI we can add it back, and change the initial mode to admin at the same time
<axw> mode=model
<wallyworld> axw: sure, the thought had crossed my mind, but the pr landing now makes things good right?
<axw> wallyworld: still can't destroy-controller with the controller name minus prefix
<axw> wallyworld: dropping the prefix would fix that
<wallyworld> we were going to match local if there were no non-local?
<wallyworld> that might be a smaller change
<axw> wallyworld: so I'm a bit reluctant to add that logic into jujuclient, which currently is agnostic of the names. but adding it in anywhere else would be error prone, given the number of places we're going to write them. and the spec doesn't call for it...
<wallyworld> it is agnotic, it was to be a short term fix. the issue is that if we ship with the UX deviating from the spec in such a visible way, there may be issues
<wallyworld> ie fix for beta1, remove as soon as beta1 ships and Ci gets updated
<axw> wallyworld: it's definitely not not going to be a smaller fix, btw. we'd need to canonicalise the controller names, which we currently expect are canonical
<wallyworld> ok, i guess we can release note it loudly
<axw> wallyworld: and also already deviating from spec, since model is not admin
<wallyworld> yes, but that's not as in your face :-)
<axw> it should be trivial to fix both at the same time
<wallyworld> ok
<wallyworld> let's revert for beta1
<wallyworld> and we'll ensure Ci drops the -m etc at the same time
<axw> wallyworld: another question I have is whether it should be local. or local: -- we use local: for clouds
<wallyworld> yeah, and the spec uses local.model
<wallyworld> we can ask rick
<axw> wallyworld: hrm actually it can't be local:, because then there'd be ambiguity with "local" as a controller name
<wallyworld> ah yes
<wallyworld> axw: right, time to see how bad the conflicts are
 * wallyworld takes a deep breath
<axw> wallyworld: sorry :)
<axw> shouldn't be too bad
<wallyworld> tis all good
<wallyworld> 4 files
<axw> anastasiamac: the answer to your last question on the PR is ^^^^
<axw> wallyworld: (above "different topic")
<axw> erer
<axw> anastasiamac:
<anastasiamac> axw: wallyworld: plz clarify in PR for posterity (and my sanity)
<anastasiamac> axw: m not seeing a definite answer above, just tossing ideas :D
<axw> wallyworld: trivial one: http://reviews.vapour.ws/r/3881/
<wallyworld> looking
<dimitern> axw, hey, could this https://github.com/juju/juju/pull/4444 also fix bug 1546043?
<mup> Bug #1546043: unit tests leave apiserver/logsink.log behind <unit-tests> <juju-core:Triaged> <https://launchpad.net/bugs/1546043>
<axw> dimitern: that's the one
<dimitern> axw, awesome! it was bugging me for a while now :)
<axw> wallyworld: I'm going to rename the "create admin model..." card and create another one, since bulk of the work is done. just need to flip a switch to set it to admin
<wallyworld> +1
<axw> actually I'll just create a new card and transfer points
<axw> wallyworld: when you're done, can we have a chat about what's next?
<dimitern> axw, you've got a review btw, and I hope you don't mind - I assigned yourself to that bug
<axw> dimitern: thanks, not at all
<wallyworld> axw: sure, more tests to fix, won't be long
<axw> dimitern: master's blocked though, I'll land it once the beta's out I guess
<axw> dimitern: why do we care about sorting the addresses w.r.t. v4/v6 on the client?
<dimitern> axw, that's ok - btw I've just confirmed your patch prevents apiserver/logsink.log creation
<axw> dimitern: thanks
<dimitern> axw, ah, that due to the somewhat well-intended-but-not-well-implemented prefer-ipv6 setting
<axw> dimitern: where does that preference actually matter though?
<axw> dimitern: I'm wondering if we should care on the client
<dimitern> axw, it will change soon (first for maas, later for all providers gradually), as we're making controller endpoint selection based on spaces
<axw> because we try all addresses
<dimitern> axw, we do try all of them, but we still put the last we successfully connected to on top
<dimitern> axw, and yeah, it shouldn't matter at the client side
<axw> dimitern: ok, thanks
<axw> wallyworld: ^^ maybe we don't need to worry about it anymore
<wallyworld> that would be good
<wallyworld> axw: quick chat now in standup channel?
<axw> wallyworld: be there in a sec
<frobware> dooferlad_: running 15 mins late for our sync. sorry!
<wallyworld> axw: st.ModelUUID is different to st.Model().ComtrollerUUID() since the latter returns model.serverUUID
<axw> wallyworld: the UUID of the admin model is the same as the controller UUID
<wallyworld> axw: i guess that's true but it seems then we're making an assumption that may change and the code as it is is immune to that
<axw> wallyworld: there's also a controllerTag field on state, we could just expose that
<wallyworld> ok, maybe the latter is better
<axw> wallyworld: avoids a db read
<wallyworld> indeed, but mongo is web scale
<axw> wallyworld: finished reviewing
<axw> anastasiamac: I suggest, for now, you change the image datasources just to use the user-supplied public key
<axw> anastasiamac: nobody is likely to be using the official one with a custom location
<axw> anastasiamac: and that's a separate issue as you noted in the bug
<axw> anastasiamac: so, drop the ImagePublicKey function you added, and just use simplestreams.UserPublicSigningKey in the *image* data sources only
<axw> anastasiamac: the tools ones should continue to use SimplestreamsJujuPublicKey
<frobware> dooferlad_: ping
<axw> anastasiamac: you have a shipit once that's addressed
<frobware> dimitern: ping
<dimitern> frobware, pong
<frobware> dimitern: can we talk about L2 in the standup HO? If not convenient just say.
<dimitern> frobware, sure, sounds good
<dimitern> frobware, omw
<axw> wallyworld: still buggered: http://juju-ci.vapour.ws:8080/view/Juju%20Revisions/job/canonistack-deploy-trusty-amd64/4041/console
<wallyworld> oh
<wallyworld> axw: so it's just the kill. the cli *appears* ok
<wallyworld> oh, also the connect
<wallyworld> after bootstrap, damn
<axw> wallyworld: actually the kill worked, bootstrap returned an error code
<axw> oh, maybe both failed actually
<axw> wallyworld: cannot read controller info: model "canonistack-deploy-trusty-amd64:canonistack-deploy-trusty-amd64" not found
<axw> for bootstrap and kill
<wallyworld> axw: for legacy, we record foo:foo, in new client store, we want just foo, right
<wallyworld> so maybe there's a mix up somewhere
<axw> wallyworld: oh, my bad. bootstrap is failing due to ssh timeout
<axw> ... probably because canonistack
<axw> and destroy is failing because it didn't bootstrap
 * axw checks a different substrate
<axw> wallyworld: sorry, canonistack is non-voting. I'll raise the alarm if another voting substrate fails
<wallyworld> whew
<axw> so far so good on azure..
<axw> wallyworld: it's a little bit unclear, but I think that test you removed is to ensure we can connect with the addresses/creds on disk, without requiring the bootstrap config
<wallyworld> ok, i'll take a look
<axw> wallyworld: winner: http://juju-ci.vapour.ws:8080/view/Juju%20Revisions/job/azure-arm-deploy/217/console
<wallyworld> goo :-)
<wallyworld> good
<axw> wallyworld: sorry, I didn't see that you had just changed the existing blank address check... leave it if you think there's potential for errors there
<wallyworld> axw: a bunch of tests fail which i am fixing. maybe we can hope juju itself is now not broekn anymore
<axw> wallyworld: I'll have to go soon, but will check back later to see your changes
<wallyworld> ok, np, have a few to go
<axw> wallyworld: or I can review tomorrow if you want to finish it tomorrow
<wallyworld> would be nice to land tonight, take a peek if you want later and hopefully will be +1
<axw> sure
<voidspace> dimitern: frobware: http://reviews.vapour.ws/r/3884/
<dimitern> voidspace, looking
<fwereade> dimitern, am bumping up against cmd/jujud/agent.MachineSuite.testAddresserWorkerNewResult
<fwereade> dimitern, is it still relevant, or should we actually just never run it?
<dimitern> fwereade, let me have a look
<fwereade> dimitern, (or always? which would be bad, because it currently seems like "never" ;p)
<fwereade> cheers
<dimitern> fwereade, ah, it's disabled as flaky
<dimitern> fwereade, but we're dropping the address-allocation feature flag soon
<fwereade> dimitern, indeed, but I want to know what the status is of the stuff it's dealing with
<dimitern> fwereade, you mean whether to migrate it to use the dep engine?
<fwereade> dimitern, I already have, I'm just not 100% sure what the expected behaviour is
<fwereade> dimitern, and the agent tests are not making it any easier to figure out ;p
<dimitern> fwereade, as it currently is, it should start and stop immediately when address-allocation feature flag is off (as it calls CanDeallocateAddresses first thing before it starts, which in turn uses the flag)
<dimitern> fwereade, was that helpful? :)
<fwereade> dimitern, it confirms that it's currently doing the right thing
<fwereade> dimitern, and I think that *that* specific behaviour doesn't need testing at agent level
<fwereade> dimitern, well, ok, it's arguable
<dimitern> fwereade, agreed - those couple of tests effectively test the finished worker behavior
<fwereade> dimitern, ehh, it's mainly just a bit annoying that my check-all-workers-are-running thing fails when one of the standard workers is sanely and blamelessly not running
<dimitern> fwereade, ah :) I see
<fwereade> dimitern, and while I *could* just ignore that skipped test I would *know* it'd fail against my current changes when reactivated, and that would be evil
<fwereade> dimitern, so I need to take some action and am rambling at you in the hope that it will become clearer :)
<dimitern> fwereade, I wouldn't worry too much about that particular test - perhaps an expected failure when not skipped + TODO will make it obvious?
<fwereade> dimitern, it's still a timebomb for whoever hits it -- do you recall the nature of the flakiness?
<dimitern> fwereade, yeah, it failed to pass under heavy load IIRC
<fwereade> dimitern, ok, then I'm entirely unsurprised, bloody singularRunner patch :)
 * fwereade hopes what he has is a bit less awful
<dimitern> fwereade, my point about not worrying too much about is that we'll drop the addresser soon anyway
<fwereade> dimitern, that's even better then
<voidspace> frobware: thanks for the review
<dimitern> voidspace, I have a concern re updated dependencies.tsv btw
<voidspace> frobware: the uint comes from the gomaasapi Space object - so unrelated
<frobware> voidspace: np, the only thing that really stuck out was int/uint for ID
<dimitern> voidspace, changing just the sha hash makes it difficult to compare the dates
<voidspace> dimitern: how do I get the date? Running the update steps for dependencies.tsv shown in CONTRIBUTING.md omitted the date.
<voidspace> dimitern: I can just put todays date in
<dimitern> voidspace, godeps github.com/juju/juju/...
<dimitern> voidspace, dumps the result at the end
<voidspace> dimitern: with no dates
<voidspace> dimitern: on my machine
<dimitern> voidspace, make sure you have the latest godeps
<dimitern> voidspace, go get -u -v launchpad.net/godeps/...
<voidspace> frobware: the "int" is purely to convert from the  float that comes out of json
<voidspace> frobware: I can use uint I suppose
<dimitern> voidspace, that's what I got on my in-progress branch when running godeps github.com/juju/juju/...: http://paste.ubuntu.com/15099666/
<voidspace> dimitern: are you sure *you* have the latest version?
<voidspace> heh
<dimitern> voidspace, yes, I did run go get -u -v launchpad.net/godeps/... before suggesting it :)
<voidspace> dimitern: I've updated and I get dates
<voidspace> dimitern: I'll add it
<voidspace> dimitern: I've updated that
<mup> Bug #1546492 opened: It's difficult to debug-hooks storage hooks <juju-core:New> <https://launchpad.net/bugs/1546492>
<dimitern> voidspace, tyvm
<dimitern> voidspace, almost done with your review btw
<mup> Bug #1546492 changed: It's difficult to debug-hooks storage hooks <juju-core:New> <https://launchpad.net/bugs/1546492>
<voidspace> frobware: fmt.Sprintf("%.0f", float) works...
<voidspace> and is less round the houses
<dimitern> network.Id(fmt.Sprintf("%v", x)) will also work for v interface{} :)
<frobware> voidspace: yep
<voidspace> dimitern: but if x is a float %v will do the wrong thing
<voidspace> dimitern: i.e. 2.0 will become network.Id("2.0") and we need network.Id("2")
<voidspace> dimitern: and what comes out of json is a float even if the source is an int
<voidspace> because json
<voidspace> because javascript
<wallyworld> axw: if you're around, pr updated
<mup> Bug #1546492 opened: It's difficult to debug-hooks storage hooks <juju-core:New> <https://launchpad.net/bugs/1546492>
<dimitern> voidspace, uint(2.0) then?
<voidspace> or fmt.Sprintf("%.0f", v)
<voidspace> rather than strconv.Itoa(uint(...))
<voidspace> dimitern: frobware: did you get disconnected too or was it just me?
<voidspace> dimitern: I don't think newAddressOnSpaceWithId should move to network
<voidspace> dimitern: in future we'll be setting provider id *or* name
<voidspace> dimitern: at which point we'll probably need a "NewAddressOnSpaceId
<voidspace> dimitern: this PR is a little bit of an intermediate one where we're setting both, but it won't stay like this
<voidspace> dimitern: probably next PR...
<frobware> voidspace:just you
<voidspace> frobware: weird
<dimitern> voidspace, I think freenode is experiencing DDoS attacks today (yet again)
<voidspace> dimitern: ah
<dimitern> voidspace, I'm not sure about "or"
<frobware> voidspace: I take it back.
<voidspace> frobware: hehe
<voidspace> dimitern: that's the current plan
<voidspace> dimitern: we shouldn't use space names directly from the provider
<voidspace> dimitern: so if the space comes from the provider we should set the id not the name
<voidspace> dimitern: so if we have a name set we *know* it's a juju name
<dimitern> voidspace, what's wrong with having either name and no ID or both?
<voidspace> dimitern: rather than having a mix of juju names and provider names floating through our code
<frobware> dimitern, voidspace: why can't we indirect through the ID for the name?
<voidspace> dimitern: because if you see a name on an address you need to know if it's a juju name or provider name
<voidspace> frobware: we should do, that's what I'm saying
<dimitern> voidspace, frobware, I think a space name should always be a valid juju name
<voidspace> frobware: we won't have an id for ec2 addresses of course because there's no provider id
<voidspace> dimitern: but that isn't currently the case with maas
<voidspace> dimitern: and our current definition of "valid juju name"
<voidspace> dimitern: if they change to be in sync that's a different matter
<voidspace> but even then there's no *problem* with being strict on using id *or* name - there's just less need
<voidspace> but at the moment there's a need
<dimitern> voidspace, yeah - they should change in names so that [A-Za-z0-9-_]+ is a valid juju space name
<dimitern> voidspace, but as it will be the case in maas
<dimitern> voidspace, s/but//
<voidspace> dimitern: yep
<dimitern> voidspace, that's why I suggested to keep the name even if we have an ID
<voidspace> dimitern: my next PR will address this anyway, so I'm going to drop that issue from this PR
<voidspace> dimitern: the trouble is that until they do it (which they say they will but may never do) it's dangerous to mix up juju names and maas names
<dimitern> voidspace, I'm ok with that
<voidspace> dimitern: cool
<frobware> voidspace, dimitern: totally agree with "it's dangerous to mix up juju names and maas names" +1
<dimitern> frobware, voidspace, the only danger I can see is due to bugs in maas atm
<frobware> dimitern: we should stop working around bugs, IMO. fix the root cause.
<axw> wallyworld: are you still working on changing UpdateControllerAddresses to not take UUID?
<dimitern> frobware, I'm not saying we should work around the bugs in maas that prevent us in some cases to use a valid maas space name as a juju space name
<voidspace> dimitern: well, that maas space name definition is broader than juju is not a "bug", it's due to a lack of communication between us
<voidspace> dimitern: it sounds like they will fix it though
<voidspace> dimitern: duplicate names are a bug :-)
<wallyworld> axw: it takes a controllerUUID in one case - after api login when controller name is not known, only uuid. i guess i could look up controller name at that point
<dimitern> voidspace, yeah - spaces allowed in names and duplicate names are 2 bugs they need to fix
<axw> wallyworld: when would we ever not know the controller name?
<dimitern> voidspace, they said they'll fix those two and we should consider them "fixed" - i.e. build our code onto that assumption
<wallyworld> damn, in that one place, i didn't see we had controlle rname
<wallyworld> i'll rework a bit
<dimitern> voidspace, which means if it's not so - i.e. CI maas setups or other (older) 1.9 maas deployments won't work
<dimitern> until those bugs are fixed
<blahdeblah> Repeating earlier question: Why does juju mangle /root/.ssh/authorized_keys, and what I can do to fit in with that, whilst still enabling my charm to write a working entry in there?
<wallyworld> axw: updated, feature test for register runs ok
<axw> wallyworld: ok, looking in a sec. I noticed in CI that manual bootstrap fails because we're now expecting "juju bootstrap manual/<host>", and CI is passing bootstrap-config in config.ayml
<axw> wallyworld: should I try and fix it, or just ask CI to retest with that small change?
<wallyworld> axw: yeah, saw that too, i beliebe aaron knows about that
<axw> wallyworld: we could allow bootstrap-host in config as well, would be better not to deviate from other providers tho
<wallyworld> i will ask them to re-test tomorrow, i prefer consistency
<axw> wallyworld: LGTM, thanks for changes
<wallyworld> axw: np, thanks for review, Ci looking good too
<wallyworld> except for manual of course
<axw> wallyworld: and a few things say they're still pending, but yeah, lots of green :)
<wallyworld> release notes tomorrow, will be quite an essay
<voidspace> dimitern: frobware: my branch has an unrelated failure in featuretests
<voidspace> dimitern: frobware: it's actually a space discovery related failure (can't login)
<voidspace> dimitern: frobware: I'll land my branch on maas-spaces2 and fix this failure with a follow-up on master
<dimitern> voidspace, sounds good +1
<jcastro> is there a quick getting started guide on building juju from source?
<jcastro> I think I found a bug in the alpha but I wanted to confirm with trunk
<Ursinha> jcastro, maybe there's a ppa with daily builds from trunk?
<Ursinha> that would be a good idea regardless :)
<Ursinha> (I realize this is not what you're asking for but figuring out such ppa would make me happy as well solve your problem to test trunk :))
<jcastro> yeah I am wondering why there's not just a daily PPA
<rick_h_> natefinch: wasn't there a thread recently that talked about a doc on building juju core? I can't seem to find it and thought you replied in it.
<rick_h_> Ursinha: jcastro we're looking at ways to get builds out faster. Because of the use of streams and such, we don't do daily builds. We need a less invasive way to get that out.
<natefinch> rick_h_: it's not really very well written for first timers: https://github.com/juju/juju/blob/master/CONTRIBUTING.md
<rick_h_> natefinch: ah ok thanks
<natefinch> rick_h_: we really should write a step by step "this is how you build juju"... which I think that document wants to be, but tries to do too much, and so obscures the actual steps you need to do to build
<rick_h_> natefinch: agreed, good to find this and we'll see what we can do.
<alexisb> natefinch, I used that doc for my first build, wasn't too bad
<natefinch> fwereade:
<natefinch> fwereade: heh, oops.  Wanted to ask about uniter tests
<mup> Bug #1546561 opened: juju sets wrong default gateway for lxc containers when using JUJU_DEV_FEATURE_FLAGS=address-allocation <juju-core:New> <https://launchpad.net/bugs/1546561>
<mup> Bug #1546561 changed: juju sets wrong default gateway for lxc containers when using JUJU_DEV_FEATURE_FLAGS=address-allocation <juju-core:New> <https://launchpad.net/bugs/1546561>
<mup> Bug #1546561 opened: juju sets wrong default gateway for lxc containers when using JUJU_DEV_FEATURE_FLAGS=address-allocation <juju-core:New> <https://launchpad.net/bugs/1546561>
<natefinch> redacting the API params during tests is dumb.
<fwereade> natefinch, oops sorry; uniter tests?
<natefinch> fwereade: there's a bunch of "match hooks" where we expect a specific list of hooks to be fired.  I presume that if that list changes, that's a bad thing?  I'm still working on this resources code, and what I'm getting is an extra upgrade-charm hook firing
<perrito666> uh, that part still exists?
<natefinch> unless something changed in the last 5 or 6 days?
<perrito666> I hoped that to go in the uniter refactor sprint
<natefinch> also, it seems like there's a bug, or at least an inefficiency in the matchHooks code: https://github.com/juju/juju/blob/master/worker/uniter/util_test.go#L250
<natefinch> This match hooks call gets retried until a LongWait expires... but really, after the first time this check fails, we know it'll never ever pass
<perrito666> natefinch: it is not a bug, its a feature :p
<natefinch> we don't ever remove things from the hooksCompleted list, so if one of them doesn't match... that's it, we're done, it'll never match.
<perrito666> no, really its a design flaw
<perrito666> that whole thing is a big bad idea, it is depending a lot on an implementation accident
<perrito666> but fwereade might not agree with me :p
<natefinch> heh
<natefinch> yeah, that was my question... I'm changing the implementation slightly... in theory it should fire the exact same events that it did before, but it's possible some niggling bits in watcher/worker code cause a hook to fire more than once... so I can't tell if I've introduced a bug, or if the tests are just too specific about their expectations.
<perrito666> ok, fwereade might correct me here, tests rely on a hook order that we dont really guarantee, much of the fact that the expected and obtained hook match depends on delicate time balance
<natefinch> som, for example, here's what my change does to the "SteadyStateUpgrade" hooks: http://pastebin.ubuntu.com/15100335/  (I changed the line prefixes so they make more sense without looking at the code, and so the lists match up for easier visual comparison)
<natefinch> (that used to be ctx.hooks vs. ctx.hooksCompleted)
<perrito666> natefinch: you are triggering more hook calls, which is not bad per se
<frobware> fwereade: maybe related to your login issue ^^ "voidspace> dimitern: frobware: it's actually a space discovery related failure (can't login)"
<frobware> dimitern, voidspace: release note sync
<voidspace> frobware: oops, soory - lost track of time
<voidspace> frobware: 5 mins, grabbing coffee
<dimitern> oops sorry, omw
<katco> natefinch: ericsnow_: just want to o/ since no standup in the morning
<katco> natefinch: ericsnow_: how's everything going?
<voidspace> dimitern: frobware: http://reviews.vapour.ws/r/3886/
<ericsnow_> katco: good
<ericsnow_> katco: talked with Ian about that worker
<voidspace> frobware: fwereade: what login issue?
<katco> ericsnow_: yeah? what's the consensus
<ericsnow> katco: we don't need a worker for that
<ericsnow> katco: the precedent (downloading lxc images) indicates that a worker should not be used
<katco> ericsnow: it occurred to me this morning that maybe i didn't represent it accurately. this will be running 100% of the time polling the charm store for all the services, correct?
<ericsnow> katco: no
<ericsnow> katco: that is a different worker
<katco> ericsnow: oh, i see you picked up a diff. card
<katco> ericsnow: ok, so the download worker, is not a worker. gotcha. what is it?
<ericsnow> katco: the one we were discussing related to using a worker to download from the charm store into state in response to resource-get
<mup> Bug #1546272 changed: doc: docs/devel/developer-layers-interfaces typo: get_remove <docs> <juju-core:Invalid> <https://launchpad.net/bugs/1546272>
<ericsnow> katco: in the API code we stream directly from the charm store into the blob store
<ericsnow> katco: (API server side)
<katco> ericsnow: and if the stream errors out?
<ericsnow> katco: since resource-get blocks a worker doesn't add anything
<ericsnow> katco: then we retry (on the server side)
<katco> ericsnow: what's the mechanism for doing so?
<ericsnow> katco: the usual suspect: utils.AttemptStrategy
 * natefinch is here but doesn't want to interrupt.
<katco> natefinch: it's irc ;)
<natefinch> katco: :)
<katco> ericsnow: ok, well glad you worked it out. thanks for bringing it up
<katco> ericsnow: natefinch: i'm working on release notes for resources; i'll want you to review here in a bit
<ericsnow> katco: also, per wallyworld regarding workers: "workers are more for reacting to changes in state"
<ericsnow> katco: no, thanks for the discussion
<natefinch> katco: the uniter tests are a beast.  There are currently about 5 failures that I'm trying to determine if they represent bugs I have introduced, or tests that need to be updated.
<katco> ericsnow: good to know
<ericsnow> katco: it helped paint an even clearer picture about workers in general :)
<katco> natefinch: :( i understand those are difficult to deal with. thanks for reaching out to perrito666. we need that done today, so do whatever is needed to make that happen (e.g. pair if necessary)
<katco> ericsnow: definitely
<ericsnow> katco: FYI, wallyworld also pointed me to the "charmrevisionupdater" worker as something similar to the charmstore poller I'm writing for resource info
<katco> natefinch: ericsnow: btw we have a new card we need to point: validating file extensions
<katco> ericsnow: oh, awesome!
<ericsnow> katco: it's not particularly re-usable for this, but does provide an example; and validation that I'm on the right track :)
<katco> ericsnow: just as useful imo :)
<ericsnow> katco, natefinch: I'm free to point that whenever y'all are ready
<natefinch> fwereade: let me know if you come available
<katco> ericsnow: natefinch: gimme 5 and we'll hop in moonstone?
<natefinch> ericsnow katco sounds good
<ericsnow> katco: +1
<katco> ericsnow: natefinch: ok i'm in there
<fwereade> frobware, voidspace: nah, I was being dumb, had changed a client-side code path without full awareness
<fwereade> natefinch, perrito666: sorry! short version: I am inclined to consider unexpected hook firings to be a problem
<fwereade> natefinch, I am available, just quite deep into code, sorry
<natefinch> fwereade: understandable. that was my assumption as well.
<fwereade> natefinch, cool
<fwereade> natefinch, it *may* be the case that the layers of indirection around the tests are such that we can't reliably induce specific uniter behaviour, but that's still a problem
<fwereade> natefinch, by the way, I think I'm misunderstanding something -- did I see a recent mail from jam saying that new resources are only delivered on resource-get?
<fwereade> natefinch, is it the case that we do an upgrade-charm to inform of new *available* resource versions or something, but nothing has actually changed in the charm at that point?
<natefinch> fwereade: we fire upgrade-charm when you push up a local resource to the controller.  At that point, the unit does not have the bytes from the new resource, and must call resource-get
<fwereade> natefinch, upgrade-charm seems a bit surprising compared to resources-changed or something?
<fwereade> natefinch, the only connection I can see is that they're both sort of to do with the charm, and you can say that about almost anything ;p
<natefinch> fwereade: the idea is that the resource bytes are integral to the functionality of the charm. So changing a resource is just as disruptive as changing the charm version
<natefinch> fwereade: firing upgrade-charm is what is declared in the spec, per rick_h_, mark, jam, etc
<fwereade> natefinch, oh joy
 * natefinch is Not In Chargeâ¢
<fwereade> natefinch, we start by saying "charm logic and payloads can vary independently, let's add tooling to make those use cases easier" and we end up with "upgrade-charm now means two completely distinct things, have fun charmers!"
 * marcoceppi watches as this develops
 * fwereade turns to marcoceppi and gestures vaguely -- if this *is* a happy outcome for you and those you represent, that's awesome -- is it?
<natefinch> marcoceppi, fwereade: http://media0.giphy.com/media/4pMX5rJ4PYAEM/giphy.gif
<fwereade> natefinch, haha
<marcoceppi> fwereade: I had concerns of not being a hook available, but was convinced that this was okay. If there's still a way to get a hook I'd be happier
<marcoceppi> fwereade: if charms have a way to query the version of the resource, without fetching it, then it's not that bad. Just some additional logic in upgrade-charm to determine if it's is new charm code or new resources
<fwereade> marcoceppi, yeah, absolutely, any state we show you as a charmer *should* be guarded by some hook that's guaranteed to fire if it changes
<fwereade> marcoceppi, or both ;p
<marcoceppi> but I'd rather have this feature with upgrade-chram than delay to 2.1
<marcoceppi> we can build libraries in the new reactive framework to work around this
<marcoceppi> or rather, not work around, but enhance this
<fwereade> marcoceppi, sure, understood, I'm just digging to check that "when we introduce new state to charmers, we should introduce new hooks to inform of changes to same" fits with your baseline desires
<marcoceppi> fwereade: I'd prefer new hooks, the more granular the event dispatcher the better
<fwereade> marcoceppi, because, y'know, if we don't tell you about the changes that's obviously stupid, and if we repurpose old hooks we potentially expose latent bugs all over the charm store by changing what hooks will get run in what situations
<fwereade> marcoceppi, cool
<fwereade> marcoceppi, to put it another way: you *can* work around a mish-mash of events, many of which mean "some combination of X, Y and Z distinct things changed", but it kinda sucks to have to
<marcoceppi> in so many words
<marcoceppi> with the exception of the hook thing, th eresources stuff is brilliant
<katco> fwereade: marcoceppi: sorry, just read through the backscroll
<katco> fwereade: marcoceppi: i think the reason that decision was made is because resources never stand alone, it's always the tuple of the charm and resources that is the concept to consider
<marcoceppi> right, but you can also upgrade resources seperately from the charm
<katco> fwereade: marcoceppi: so having being notified of a resource being updated is meaningless if you accept that premise
<katco> marcoceppi: my understanding is that you cannot
<marcoceppi> I was informed otherwise
<katco> marcoceppi: resource updated = new rev of the charm
<marcoceppi> but since you've done the work I'm happy to accept that
<katco> marcoceppi: who am i contradicting?
<marcoceppi> so if I release a new version of my applicaiton, that's a charm rev?
<katco> marcoceppi: yep
<marcoceppi> but it's just an updated resource
<rick_h_> marcoceppi: the 'revision' of a charm becomes a 'revision set'
<rick_h_> marcoceppi: that set is the published set of the charm rev, and the rev of each resource
<rick_h_> marcoceppi: updating any part of that, is an new revision set that much be processed by the upgrade-charm hook.
<rick_h_> that's the way it's currently set out.
<katco> marcoceppi: check out the 3rd bullet of the 1.0 mvp
<marcoceppi> okay, so is there a way for me to query, without first accepting the payload, that I've got a new version?
<marcoceppi> in the charm
<katco> marcoceppi: as a charmer, not currently. as an admin, yes
<rick_h_> marcoceppi: we need that yes. It's not there now, but agree. Honestly it was an optimization thing that came up as we get into using it
<marcoceppi> okay
<rick_h_> marcoceppi: and good feedback that we need to go back with
<marcoceppi> then I'm cool
<katco> marcoceppi: you are cool, marcoceppi.
<marcoceppi> as long as I can say "resource update"
<katco> very cool :)
<marcoceppi> at the end of the day, with reactive, we're not going to care about upgrade-charm hook
<marcoceppi> well some will, most wont
<rick_h_> marcoceppi: katco I think we need something like resource-version or resource-changed to go with resource-get. My concern with resource-changed is that if something fails and you retry, will we have the right answer.
<marcoceppi> we'll only really care about @when('resource.<RESOURCE_NAME>.updated')
<rick_h_> marcoceppi: katco so I think there's some thought we need to get that right
<katco> rick_h_: well, isn't resource-changed redundant? i.e. anytime it would fire, upgrade-charm would also have fired
<rick_h_> katco: not as a hook, but as a hook command
<rick_h_> katco: e.g. resource-changed mysourcecode
<rick_h_> returns true/false
<marcoceppi> rick_h_ katco is resource-list a hook-tool?
<rick_h_> katco: so if one new resource is uploaded out of 3, I can tell which one I need to untar, process, etc
<katco> marcoceppi: no, juju list-resources
<fwereade> katco, rick_h_: the issue is surely that upgrade-charm means "your charm logic has changed" and resource-changed means "some of your tweakable blobs have changed"
<katco> rick_h_: well, that is an optimization. i believe resource-get on a resource that hasn't changed is a nop
<marcoceppi> so, as a charmer, I want to be able to run "resource-list" in a hook with --format json and get something like "resource_name": "version" for each resource
<rick_h_> katco: I'm not so sure
<fwereade> katco, rick_h_: that we have a tuple of things that represent "exactly what's running on this unit" is... coincidental, if you like? we don't even officially expose charm urls to charmers right now
<katco> ericsnow: natefinch: is resource-get on an unchanged resource a no-op right now?
<natefinch> FWIW, we certainly could add a command that tells the unit whether or not it has the latest version of a resource.  We store the version each unit has and the version that is current for the service.
<rick_h_> fwereade: well it was designed/built to not be coincidental. I see what you mean on "charm logic" vs "blob of data" though.
<rick_h_> fwereade: the goal is that when you publish to the charmstore you're declaring "this revision of the charm logic with this revision of this blob and that blob pass tests and work together"
<marcoceppi> natefinch: exposing that I think will be crucial to making the join charmversion + resourceversion + upgrade-charm work for a charm authors perspective
<rick_h_> fwereade: it's the local case that's more muddy
<marcoceppi> joint*
<katco> rick_h_: fwereade: yeah it all begins at 1st principles. either the tuple defines the charm, or it doesn't. if it does, then there's no such thing as updating just the blob
<rick_h_> marcoceppi: +1 the thing is catching the failure cases and making sure it behaves predictably
<natefinch> katco: we don't do that optimization... resource-get will always just download the bytes
<katco> natefinch: fair enough for v1
<rick_h_> natefinch: right, I think we can't noop right now because it means the hooks aren't idempotent
<katco> rick_h_: mm not true
<fwereade> natefinch, katco: so the upshot is that every time you get an upgrade-charm, you *have* to resource-get *all* your resources before you can safely move on?
<natefinch> rick_h_: sure they are... the bytes on disk are the same before and after
<katco> rick_h_: idempotent = end state is always the same
<rick_h_> katco: ah, I see. the bytes are in the folder
<katco> rick_h_: correct
<natefinch> fwereade: yes :/
<katco> fwereade: yeah, as designed currently\
<fwereade> how does this even happen with a supposed "user focus" in design?
<rick_h_> fwereade: no, it just means you have to process your logic.
<rick_h_> fwereade: happy to hop on a call if you've got questions
<katco> rick_h_: would join to be a fly on the wall
<rick_h_> fwereade: but you're starting to cross into unproductive territory here
<fwereade> rick_h_, let's, I fear that I misunderstand something horribly
<rick_h_> https://plus.google.com/hangouts/_/canonical.com/rick?authuser=1 for all interested parties
<perrito666> I think I broke RB
<perrito666> k people bbl
<perrito666> cheers
<mup> Bug #1544796 changed: Backup restore fails: upgrade in progress <backup-restore> <blocker> <ci> <regression> <juju-core:Fix Released by cherylj> <https://launchpad.net/bugs/1544796>
<mup> Bug #1544796 opened: Backup restore fails: upgrade in progress <backup-restore> <blocker> <ci> <regression> <juju-core:Fix Released by cherylj> <https://launchpad.net/bugs/1544796>
<mup> Bug #1544796 changed: Backup restore fails: upgrade in progress <backup-restore> <blocker> <ci> <regression> <juju-core:Fix Released by cherylj> <https://launchpad.net/bugs/1544796>
<mup> Bug #1544796 opened: Backup restore fails: upgrade in progress <backup-restore> <blocker> <ci> <regression> <juju-core:Fix Released by cherylj> <https://launchpad.net/bugs/1544796>
<mup> Bug #1544796 changed: Backup restore fails: upgrade in progress <backup-restore> <blocker> <ci> <regression> <juju-core:Fix Released by cherylj> <https://launchpad.net/bugs/1544796>
<mup> Bug #1546662 opened: juju does not respect --agent-version <bootstrap> <ci> <juju-core:Triaged> <https://launchpad.net/bugs/1546662>
<mup> Bug #1546662 changed: juju does not respect --agent-version <bootstrap> <ci> <juju-core:Triaged> <https://launchpad.net/bugs/1546662>
<perrito666> anyone ever heard of StateServerInstances() ?
<mup> Bug #1546662 opened: juju does not respect --agent-version <bootstrap> <ci> <juju-core:Triaged> <https://launchpad.net/bugs/1546662>
<mup> Bug #1546662 changed: juju does not respect --agent-version <bootstrap> <ci> <juju-core:Triaged> <https://launchpad.net/bugs/1546662>
<perrito666> fwereade: still here?
<perrito666> fwereade: nevermind
<mup> Bug #1546662 opened: juju does not respect --agent-version <bootstrap> <ci> <juju-core:Triaged> <https://launchpad.net/bugs/1546662>
<perrito666> mup: you are a very annoying thing
<mup> perrito666: Strictly speaking, I'm not intelligent enough to understand that.
<perrito666> it shows
<perrito666> :p
<perrito666> bbl
<natefinch> katco: so in talking with william and rick, it sounds like we really need a hook command that can tell the charm what resources are out of date for the unit.  That should be really easy, since we have all the backend code, we'd just replicate a bunch of juju resources <unit> in a hook command.
<katco> natefinch: i agree that sounds like a good idea. let's revisit after we deliver what's on our plate already
<natefinch> katco: yep... and FWIW, rick was able to convince william that we should stick with the charm-upgrade hook, mostly because it's sorta too late to do anything else.
<katco> natefinch: yeah
<katco> natefinch: i wonder if we looked at how we support things, we couldn't support releasing changes like that more easily
<natefinch> katco: I think making a new hook wouldn't been the end of the owrld, but it woudl definitely be  a few more days work than finishing up what we have... and we don't really have a few days to spare.
<katco> natefinch: then the conversation becomes, "that's a good idea. we'll do that next month" instead of "omg change course! change course! we can't have a breaking change!"
<natefinch> katco: rick was positing that it could be delivered later... I'm not 100% convinced that's true, though, since it would break charms that rely on charm-upgrade getting called.
<natefinch> (for resource changes)
<katco> natefinch: we should make more liberal use of our versioned concepts outside of the macro version of juju
<katco> natefinch: and deprecate old versions of things more regularly (apis, hook commands, cli)
<natefinch> katco: well, yeah, we should deliver min-juju-version, which would help with that
<katco> natefinch: true
<natefinch> katco: (in our spare time)
<natefinch> perrito666: you back yet?
<natefinch> super short review for someone?  re-enables showing full API params during tests (if you use the verbose flag during the test). http://reviews.vapour.ws/r/3887/diff/#
<voidspace> EOW, bye all
<natefinch> gah, what I wouldn't give for focused unit tests in the uniter code, so I could narrow down where the bug is in my code :/
<katco> natefinch: i think you and ericsnow better pair up to get through this
<natefinch> katco: yep
<natefinch> katco: sorry, missed when he came back online.
<natefinch> ericsnow: help me ericsnowcurrently, you're my only hope!
<ericsnow> natefinch: let's get it done!
<katco> ericsnow: natefinch: i'm done with admin stuff. reviewing your code now
<rick_h_> cherylj: I've got to get the boy from school and will be late to our meeting with folks. Can you bug thumper please?
<rick_h_> cherylj: I'll have to work with him to move that back since it's sitting in this bad spot
<cherylj> rick_h_: sure, will do
 * thumper heading to dentist with daughter two
<rick_h_> thumper: doh, looks like I missed you
<davecheney> 0 for 2 rick_h_
<rick_h_> davecheney: yea, he's avoiding me. Scheduling things during school time and then running off to dentists.
<rick_h_> :P
<perrito666> Katco I won't make it to your standup, stuck in traffic sorry
<katco> perrito666: np, i just marked you and anastasiamac as optional
<wwitzel3> perrito666 do it from the car :P
<perrito666> I can IRC from traffic jams, how cool is that?
<perrito666> Honestly if the lte dongle wasn't in the trunk I could
<wwitzel3> ahh, the person grabbed it from you as you pushed them in there?
<wwitzel3> ;)
<perrito666> There is no respect anymore
 * perrito666 shouts at the trunk
<perrito666> Traffic is moving bbl
 * perrito666 is back
<perrito666> wallyworld: around?
<wallyworld> in a meeting
<natefinch> ericsnow: sorry... I'll give that a test and see if it needs tweaking or anything
<natefinch> ericsnow: thanks for the help
<ericsnow> natefinch: cool
<perrito666> yay go 1.6
<marcoceppi> perrito666: time to pack it up and move juju to 1.6 ;)
<bogdanteleaga> I'm actually thinking of going back to an older version to save those insane compilation times
<perrito666> bogdanteleaga: the only way to advance is forward
<mup> Bug #1546790 opened: availability zone not set <juju-core:New> <https://launchpad.net/bugs/1546790>
<bogdanteleaga> perrito666, at least by golang 2.0 the test suite run time won't be the bottleneck
<mup> Bug #1546794 opened: lxd provider's namespace property seems to be ignored <juju-core:New> <https://launchpad.net/bugs/1546794>
<mup> Bug #1546795 opened: bootstrap manual broken: failed to check provisioned status: subprocess encountered error code 1 <juju-core:New> <https://launchpad.net/bugs/1546795>
<mup> Bug #1546794 changed: lxd provider's namespace property seems to be ignored <juju-core:New> <https://launchpad.net/bugs/1546794>
<mup> Bug #1546795 changed: bootstrap manual broken: failed to check provisioned status: subprocess encountered error code 1 <juju-core:New> <https://launchpad.net/bugs/1546795>
<mup> Bug #1546794 opened: lxd provider's namespace property seems to be ignored <juju-core:New> <https://launchpad.net/bugs/1546794>
<mup> Bug #1546795 opened: bootstrap manual broken: failed to check provisioned status: subprocess encountered error code 1 <juju-core:New> <https://launchpad.net/bugs/1546795>
 * perrito666 prepares for standup, suddenly remembers there is no standup today
<wallyworld> perrito666: anastasiamac: axw: meeting finished early, let's have standup
<mup> Bug #1546805 opened: storageprovider seems to be stuck in an infinite loop <juju-core:New> <https://launchpad.net/bugs/1546805>
<mup> Bug #1546805 changed: storageprovider seems to be stuck in an infinite loop <juju-core:New> <https://launchpad.net/bugs/1546805>
<mup> Bug #1546805 opened: storageprovider seems to be stuck in an infinite loop <juju-core:New> <https://launchpad.net/bugs/1546805>
#juju-dev 2016-02-18
<perrito666> axw: I mailed you the cause of the error, hope it helps.
<axw> perrito666: back momentarily. thanks. so ... the credentials are being reset to those from the restored state?
<ericsnow> katco: FYI, my poller worker patch is up
<perrito666> axw: yes, the server is restored to the old one
<perrito666> all of the files from the server become the old files
<axw> perrito666: ok, that's an even bigger problem than I had thought. we'll need to extract the credentials from the backup file, I suppose.
<perrito666> axw: sorry I was not more helpful
<axw> perrito666: you were most helpful, I know what the issue is now
<axw> thanks
<perrito666> np
<katco> ericsnow: sweet, ty!
<davecheney> dumb question
<davecheney> assuming i'd never used backup / restore before
<davecheney> how do I use it
<davecheney> lucky(~/src/github.com/juju/juju) % juju backups
<davecheney> ERROR there is already a Writer registered with the name "warning"
<mup> Bug #1546826 opened: juju backups prints unhelpful error <juju-core:New> <https://launchpad.net/bugs/1546826>
<davecheney> totally broken, https://bugs.launchpad.net/juju-core/+bug/1546826
<mup> Bug #1546826: juju backups prints unhelpful error <juju-core:New> <https://launchpad.net/bugs/1546826>
<mup> Bug #1546826 changed: juju backups prints unhelpful error <juju-core:New> <https://launchpad.net/bugs/1546826>
<mup> Bug #1546826 opened: juju backups prints unhelpful error <juju-core:New> <https://launchpad.net/bugs/1546826>
<anastasiamac> wallyworld: team meeting?
<natefinch-afk> davecheney: team meeting?
<mup> Bug #1546836 opened: Cannot deploy to extra models <models> <juju-core:New> <juju-core cloud-credentials:Triaged> <https://launchpad.net/bugs/1546836>
<davecheney> natefinch: is anyone there this time ?
<davecheney> the last dozen have been no shows
<mup> Bug #1546836 changed: Cannot deploy to extra models <models> <juju-core:New> <juju-core cloud-credentials:Triaged> <https://launchpad.net/bugs/1546836>
<mup> Bug #1546836 opened: Cannot deploy to extra models <models> <juju-core:New> <juju-core cloud-credentials:Triaged> <https://launchpad.net/bugs/1546836>
<mup> Bug #1546836 changed: Cannot deploy to extra models <models> <juju-core:New> <juju-core cloud-credentials:Triaged> <https://launchpad.net/bugs/1546836>
<mup> Bug #1546836 opened: Cannot deploy to extra models <models> <juju-core:New> <juju-core cloud-credentials:Triaged> <https://launchpad.net/bugs/1546836>
<mup> Bug #1546840 opened: Cannot restore to new bootstrapped instance <backup-restore> <juju-core:Incomplete> <juju-core cloud-credentials:Triaged> <https://launchpad.net/bugs/1546840>
<davecheney> thumper: coming back ? or can you not get back on at all ?
<mup> Bug #1546840 changed: Cannot restore to new bootstrapped instance <backup-restore> <juju-core:Incomplete> <juju-core cloud-credentials:Triaged> <https://launchpad.net/bugs/1546840>
<thumper> davecheney: I was blocked
<davecheney> relly ?
<mup> Bug #1546840 opened: Cannot restore to new bootstrapped instance <backup-restore> <juju-core:Incomplete> <juju-core cloud-credentials:Triaged> <https://launchpad.net/bugs/1546840>
<davecheney> thumper: i've no idea how to fix that
<thumper> worked this time
<davecheney> i sent you an invite to join the hangout
<natefinch> I miss the longer hangouts... actually get to chat with people not in your standup
<anastasiamac> natefinch: +1 \o/
<wallyworld> anastasiamac: lgtm, ty
<anastasiamac> omg! i thought u were busy and pinged axw (ocr)
<anastasiamac> wallyworld: tyvm
<anastasiamac> axw: tyvm \o/
<axw> nps
<axw> wallyworld: apparently it's a known issue: https://bugs.launchpad.net/juju-core/+bug/1537620
<mup> Bug #1537620: environs/ec2: a stopped machine will cause kill-controller to fail and blow the rate limit <juju-core:Triaged> <https://launchpad.net/bugs/1537620>
<axw> I'll try on GCE instead
<natefinch> finally!  The time package's Parse function has always rejected any day of month larger than 31, such as January 32. In Go 1.6, Parse now also rejects February 29 in non-leap years, February 30, February 31, April 31, June 31, September 31, and November 31.
<wallyworld> joy
<wallyworld> wow, date maths must be hard
<wallyworld> it took them how many releases
<anastasiamac> wallyworld: we should have decimal calendar
<anastasiamac> and decimal clock
<anastasiamac> :D
<wallyworld> yes!
<anastasiamac> HAPPY BIRTHDAY IAN
<natefinch> decimal clock is easy, decimal calendar requires changing the velocity of the earth :D
<davecheney> lucky(~/src/github.com/juju/juju) % juju backups restore -b --file juju-backup-20160218-040500.tar.gz
<davecheney> ERROR old bootstrap instance ["i-f007252f"] still seems to exist; will not replace
<davecheney> lucky(~/src/github.com/juju/juju) % juju backups restore  --file juju-backup-20160218-040500.tar.gz
<davecheney> ERROR could not exit restoring status: cannot complete restore: <nil>: Restore did not finish succesfuly
<davecheney> ERROR cannot upload backup file: PUT https://54.79.223.98:17070/model/3037ea53-64dc-48b8-83c1-c0bea979fca2/backups: while storing backup archive: backup metadata "20160218-040500.3037ea53-64dc-48b8-83c1-c0bea979fca2" already exists
<davecheney> does this actaully work ?
<davecheney> i cannot restore to a system that is running
<davecheney> twiddling different flags just makes it fail in different ways
<natefinch> 1.25 or 2.0?
<davecheney> 2.0
<natefinch> probably just broken...
<natefinch> afaik, no work has been done on it for 2.0, but I may be mistaken
<mup> Bug #1546100 changed: Upgrade 1.24.7 -> 1.25.3 fails <manual-provider> <upgrade-juju> <juju-core 1.24:New> <juju-core 1.25:In Progress by anastasia-macmood> <https://launchpad.net/bugs/1546100>
<axw> wallyworld: https://github.com/juju/juju/pull/4459
<axw> tested live
<wallyworld> looking
<wallyworld> axw: so code from master is effectively added back in?
<wallyworld> with the relevant cloud credentials tweaks
<axw> wallyworld: yes. doing anything else will be substantially more work
<axw> this is just a stop-gap
<wallyworld> yep, +1
<axw> wallyworld: there should be no difference from master now
<axw> from user perspective
<wallyworld> great, was just checking to be sure
<davecheney> https://github.com/juju/juju/pull/4460 << fixes juju backups problem
<axw> wallyworld: you're not doing the register accounts.yaml fix are you? assuming not, I'll do it
<axw> davecheney: LGTM
<wallyworld> axw: not yet, just finished first pass on release notes if you want to see if I've missed anything. maybe it would be better to fix order of regions listing first, and switch
<wallyworld> as those are user visible
<davecheney> HOW DO I USE JUJU RESTORE
<davecheney> you cannot restore the same model you just backed up
<davecheney> if you destroy the model, then you cannot restore at all
<davecheney> i cannot create a new model
<davecheney> i just get a shitload of missing key or TLS mismatch errors
<axw> davecheney: this is what I did just a little while ago
<axw> davecheney: 1. bootstrap   2. create-backup   3. kill the controller instance   4. restore-backup -b --file <backup-file>
<axw> davecheney: only works on non-hosted model AFAIK
<davecheney> lucky(~/src/github.com/juju/juju) % juju restore -m foobarbaz x.tgz
<davecheney> ERROR cannot determine controller instances: making request: Get : 301 response missing Location header
<davecheney> error: exit status 1
<davecheney> lucky(~/src/github.com/juju/juju) % juju restore x.tgz
<davecheney> ERROR cannot determine controller instances: model is not bootstrapped
<davecheney> error: exit status 1
<axw> davecheney: did you destroy your controller with destroy/kill-controller? (if so, that won't work)
<wallyworld> axw: i'm off to soccer in a bit. you think we can go with show-controller noargs for beta1 (and re-instate switch for beta2 if needed)? so i think region ordering is the last remaining fix foe beta1?
<axw> wallyworld: I've just pushed switch no args
<wallyworld> ok, great :-)
<axw> wallyworld: and will send a plea to rick and john to change it :)
<wallyworld> axw: i've asked john to bring it up in spec review
<axw> wallyworld: ok
<axw> wallyworld: https://github.com/juju/juju/pull/4461
<wallyworld> we can do both for beta1 and see what sticks
<axw> wallyworld: I think show-controller noargs is fine anyway, but it's doing more than just giving you the name
<axw> you can script around it, but it's a bit of a pain
<wallyworld> yep
<wallyworld> that was my issue
<wallyworld> axw: lgtm
<axw> wallyworld: ok, will look at region thing next. not sure if I'll be able to get it in in time, but I'll try
<wallyworld> axw: ty, see how you go, i'll document the issue in the release notes if need be
<axw> wallyworld: hmm, are we doing the default-region thing already? I don't think so
<wallyworld> i thought we were
<axw> wallyworld: I mean, if not specified in credentials.yaml and there's more than one... I don't think we use the first in the clouds.yaml file
<wallyworld> you men in credentials.ysaml
<wallyworld> ah maybe not
<wallyworld> i thought we were though
<wallyworld> will need to check
<wallyworld> after soccer
<axw> wallyworld: I don't think so. I don't think that's in the spec either.
<axw> sure, enjoy
<wallyworld> it may not be explicitly, but aws say is expected to have a default region
<wallyworld> of us-east-1
<wallyworld> if nothing else specified
<wallyworld> unless i recall totally wrongly
<axw> wallyworld: we used to. I don't know what the expectation is now.
<wallyworld> the same as before i think is good to go with
<wallyworld> so however we decide to order regions in public clouds yaml
<wallyworld> axw: if i've left anything out of release notes, just edit and fix directly would be great
<axw> wallyworld: sure
<wallyworld> ta
<axw> wallyworld: can't see anything missing. I think we need to change the wording about defaults for beta1. I'm not comfortable making first-in-list the default without input from rick and john. it's already complicated, and that makes it moreso. we'll have a command to set the default in beta2.
<wallyworld> ok
<wallyworld> we still should fix ordering though
<wallyworld> there does have to be an out of the box default
<wallyworld> a deterministic default
<axw> wallyworld: why?
<wallyworld> so people know how juju will behave without guessing
<axw> wallyworld: what makes sense as a default for someone in the US does not make sense for someone in Australia
<axw> it will tell you what to do if you don't specify a region
<axw> (or it should)
<wallyworld> so out of the box, juju bootstrap controller aws needs to just work
<wallyworld> as it does now with a well known default region
<wallyworld> that's IMHO
<wallyworld> we can seek input though
<axw> I think we'll have to, because I disagree :)
<wallyworld> fight!
<wallyworld> right, really off to soccer now
<axw> wallyworld: I'll send an email and CC you
<axw> later
<wallyworld> ta, can you cc john also
<axw> yes
<wallyworld> and reference 1.25 behaviour for comparison
<axw> wallyworld: I've updated the text bootstrap re regions to reflect current reality. please adjust as you see fit
 * fwereade is having some design trouble, anyone free to chat?
 * fwereade will rubber-duck irc for a bit; answer if interested ;)
<fwereade> so. a while ago, I extracted the OpenAPIState func and a few associated bits from jujud/agent, and moved them to worker/apicaller
<fwereade> this functionality includes various agent-specific hacks of varying quality
<fwereade> it handles (1) fixing insecure passwords and writing to remote+local state (2) updating local state to record connected model tag (3) some foul remote-state mongo-password hack that I'm scared to touch and (4) enthusiastic generation of the scorched-earth ErrTerminateAgent error
<fwereade> and none of these things are actually *fundamental*, they're all artifacts of the assumption that this api connection is the sole connection being made on behalf of an actual agent process
 * mgz reads along at least
<fwereade> and when you're making a connection as a controller to a hosted model, none of those actions are actually appropriate and some of them are plain broken
<fwereade> part of my problem is that I don't have a succinct term for distinguishing between those cases -- I need a lots-of-magic path and a nice-simple path, and I know ahead of time (manifold config specification time) which I will want
<fwereade> so the low-friction approach is to add a `NewConnection func(agent.Agent) (api.Connection, error)` field to manifold config
<fwereade> because that lets me dodge the issue of what the difference is or how it should be expressed
<mgz> that does not sound terrible. do the two paths really not share logic at all?
<fwereade> but this makes me uncomfortable -- it feels like what-needs-to-be-done is more a property of the *agent*
<mgz> other option is an OnConnection type interface, which you promise to call immediately after getting api.Connection for the first time?
<fwereade> yeah, that makes me nervous because it'd need to take (conn api.Connection, oldPassword string, usedOldPassword bool), and that feels like unhelpfully exposed guts
<fwereade> so I find myself wanting to add a `ShouldDoFunkyPostConnectStuff() bool` to Agent, but that's *clearly* wrong too
<fwereade> if it were more like `IsVirtualAgent() bool` that would make more sense, it would feel like the decision was happening in the right place
<fwereade> but that's a bad name
<fwereade> so it sort of comes back to "is there a term I can use to express the important property of the agent, in agenty terms, that the apicaller bits can reasonably use to make the decision re: whether to mess with the agent post-connect"
<dooferlad> frobware, dimitern: hangout?
<dimitern> omw
<mgz> fwereade: well, the other part is... this is all one-time stuff really, not actually per-connection? well, I'm not sure about (4)
<fwereade> ...which itself is basically "what is the critical property of the agent that makes it different?" and does assume that it's really the agent that's the source of the difference
<fwereade> *mostly* one-time, yes
<mgz> so it's does-this-hacky-stuff-still-need-doing-and-can-I-do-it
 * fwereade is listening
<mgz> ShouldAttemptStateUpdateHacks? :P
<mgz> I don't have good name ideas. what's the implementation, just always try it if we're not connecting to a hosted env?
<fwereade> mgz, pretty much, yeah
<fwereade> mgz, it currently maps to "is this connection on behalf of an 'Agent' that's running in its own process", but that is neither fundamental to the agent or any of its business really
<fwereade> mgz, so, I'll probably just go with the ManifoldConfig.NewConnection approach because at least it's the most straightforward
<fwereade> mgz, it's only one duplicated func call there
<mgz> it seems reasonable to me
<fwereade> mgz, thanks :)
<mgz> and you can document the whys on the implementations
<fwereade> mgz, yeah, just figuring out *exactly* what all the original funcs do and giving them less-misleading names/documentation has taken a while already
<blahdeblah> Hi folks; any chance of some love for https://bugs.launchpad.net/juju-core/+bug/1465307 sometime soon?  I've got an environment which is basically useless because of it that I'm happy to supply logs from...
<mup> Bug #1465307: 1.24.0: Lots of "agent is lost, sorry!" messages <landscape> <regression> <juju-core:New> <https://launchpad.net/bugs/1465307>
<perrito666> Morning
<rick_h_> morning perrito666
<dimitern> frobware,  dooferlad, http://reviews.vapour.ws/r/3898 please take a look when you can
<dimitern> fwereade, if you can spare some time, I'd appreciate if you have a look as well ^^
<dimitern> fwereade, in case you're wondering, tests using txn hooks will also be added later :)
<fwereade> dimitern, ack, likely to be rather later this pm
<fwereade> dimitern, and, <3
<dimitern> fwereade, cheers, when you get to it :)
 * dimitern steps out for ~1h
<axw> wallyworld: rather than using MapSlice and all that, would you be OK with adding an unserialised DefaultRegion to the Cloud type, and (a) have that populated with the first item, and (b) use it to decide the order in which we write?
<frobware> dimitern: reviewed
<dimitern> frobware, thanks!
<frobware> dimitern: mostly trivial comments - looks a lot, but mostly harmless. :)
<dimitern> frobware, any comments and suggestions are most certainly welcome :)
<frobware> dimitern: regarding parent/child, master/slave. the latter makes more sense to me now that I've read your comment.
<perrito666> has anyone used goamz with tags?
<dimitern> frobware, cheers, but because you asked that tells me the doc comment needs to clarify that :)
<frobware> dimitern: the other thing is s/DNSDomain/DNSSearchDomains/
<dimitern> frobware, yeah, that's a better name - will change
<frobware> dimitern: thanks. the two are entirely related, but different.
<dimitern> frobware, I'm not quite clear on the difference - do we need both DNSDomain and DNSSearchDomains ?
<perrito666> weee cloud credentials is blessed
<frobware> dimitern: don't believe so. just the latter.
<frobware> dimitern: there's also DNSSortList if we want completeness.
<frobware> dimitern: I guess DNSSearchDomain could just be DNSSearch
<dimitern> frobware, I've pushed the changes btw
<frobware> dimitern: looking
<fwereade> don't suppose anyone is up to date with the uninstallAgent logic? has semi-recent menn0/axw touches, so I'm guessing not, but just in case...
<perrito666> I would say menn0 and axw
<fwereade> ehh, someone *might* have said "oh yeah I reviewed that stuff" ;p
<perrito666> perhaps they cross reviewed :p
<katco> ericsnow: i'm in our 1:1... did you have anything you wanted to discuss today?
<ericsnow> katco: nope
<katco> ericsnow: ok, i'll leave you be then :)
<katco> ericsnow: fyi i lost a review i was doing for you yesterday (chrome crashed)... working on it again
<ericsnow> katco: that stinks :(
<ericsnow> katco: hope you didn't lose too much time
<katco> ericsnow: yeah =/ i think like an hour or so. but should go faster the 2nd time
<frobware> dimitern: LTGM now. but perhaps you want to wait to see if fwereade has observations on the state stuff.
<dimitern> frobware, cheers
<dimitern> frobware, I'll push a couple of commits on top of these and drop the interfacelinks.go from the PR for now
<dimitern> dooferlad, frobware, so you'd rather see `802.3 interface "eth0" on machine "42"` than `ethernet interface "eth0" on machine "42"` ?
<dooferlad> dimitern: you don't have to use the const string value as what you print.
<dooferlad> dimitern: but I do care about being completely clear about what protocols we support and what we are doing with them.
<dimitern> dooferlad, so you're saying let's have one value representing the type and another when printing / logging ?
<dimitern> dooferlad, ok, how about a compromise: type/subtype - i.e. ethernet/802.3 and ethernet/802.11Q ?
<dooferlad> dimitern: I don't care so much about the value of ths string, only the variable name
<dooferlad> sorry, const name
<dimitern> dooferlad, I got you
<dooferlad> dimitern: so something nice to read in the string and leave "EthernetInterface" as is.
<dimitern> dooferlad, but the value is the important thing we store in the doc and have to change later and deal with upgrades if it's not the right value
<dooferlad> dimitern: oh, crumbs, I forgot we do that nonsense. I miss enums. </rant>
<dooferlad> I think EthernetInterface = "ethernet", EthernetVLAN1QInterface = "Ethernet 802.1Q bridge"
<dooferlad> since those print nicely and only a crazy person would change the meening of Ethernet.
<dimitern> dooferlad, Ethernet80211QVLAN ?
<dooferlad> dimitern: sure
<dimitern> ok, so Ethernet80211QVLANInterface = "802.11q" ?
<dooferlad> dimitern: as long as you know what sort of VLAN it is. I know it is ugly to read/type, but I can't think of a better version.
<dimitern> dooferlad, or maybe drop the Ethernet and go with 80211QVLANInterface ?
<dooferlad> dimitern: I think it is reasonable to have the string be more readable if you want. "Ethernet 802.1Q bridge" does look better in the logs.
<dimitern> dooferlad, it's not a bridge though
<dooferlad> dimitern: Sorry, "Ethernet 802.1Q VLAN"
<dooferlad> dimitern: I also considered Eth802_11_Q_VLAN so I could actually read it, but I know that wouldn't sit well with the "go way of doing things"
<dimitern> dooferlad, consider this will be all over the place in case of MAAS
<dimitern> dooferlad, so "802.1q" instead is shorter, and I think also clear enough
<dimitern> VLAN8021QInterface InterfaceType = "802.11q"
<dimitern> oops sorry
<dimitern> VLAN8021QInterface InterfaceType = "802.1q"
<dooferlad> dimitern: Indeed. Ugly, but clear.
<dooferlad> dimitern: I am sure we can call it VLAN_8021QInterface and avoid having rocks thrown at us...
<dimitern> dooferlad, we can try :)
<dimitern> yeah, readable code is better than blindly following go naming conventions
<natefinch> man, xchat has started pegging my CPU for 5 minutes whenever it starts up, only started happening this week sometime.
<natefinch> perrito666: you around?
<natefinch> so, where are we hiding the new .juju directory?
<rick_h_> natefinch: .config/local/juju I think
<rick_h_> natefinch: xdg standard locations
<natefinch> rick_h_: I don't hav a .config/local :/  And no, I definitely have not touched my XDG settings off whatever is default
<rick_h_> natefinch: sorry per https://jujucharms.com/docs/devel/temp-release-notes
<rick_h_> natefinch: .local/share/juju
<natefinch> rick_h_: ahh, yeah, ok.  I had just drilled down to the code where that's set. Thanks.
<natefinch> rick_h_: why .local/share and not .config?  I presume it makes sense to someone, but as someone who barely knows XDG exists... it seems odd.
<rick_h_> natefinch: not sure, just guessing it's based on https://specifications.freedesktop.org/basedir-spec/basedir-spec-0.8.html
<natefinch> rick_h_: ok :)
<rick_h_> there's env vars for the locations and we should be using
<natefinch> rick_h_: I'm sure we're doing the right thing, according to the spec.  There's several people on core who Care Very Muchâ¢
<perrito666> natefinch: still need me?
<natefinch> perrito666: yeah... davecheney was trying to use backups with juju 2.0 .... is that supposed to work?  like backup 2.0, bootstrap new 2.0 model, restore?
<perrito666> natefinch: should work, expecially if master is blessed
<natefinch> perrito666: weird... he was getting a multitude of errors
<natefinch> perrito666: http://pastebin.ubuntu.com/15112721/
<perrito666> natefinch: just read the backlog, seems that axw might have hit the spot and that dave was killing the controller
<natefinch> perrito666: seems like our error messages could be a bit better, if this is something that can happen from user error
<perrito666> natefinch: I think he added a bug for that
<natefinch> perrito666: good
<ericsnow> katco, natefinch: our resources PRs are against master now, right?
<katco> ericsnow: no, please still target them to the feature branch
<ericsnow> katco: k
<katco> ericsnow: you always need a ci bless before hitting master
<natefinch> oh, thanks for the clarification :)
<natefinch> right, that makes sense
<perrito666> natefinch: ericsnow ideally both sides merges need a bless, you should not merge to master without a bless nor merge from unblessed master
<perrito666> ymmv on the last one but helps avoid headaches
<perrito666> has anyone succesfully used destroy model?
<natefinch> features work a lot better if you don't accidentally remove the 3 core lines that actually make them function.
<natefinch> ericsnow: during some code cleanup, I evidently removed the lines that actually increment CharmModifiedVersion when you call SetResource :/
<ericsnow> natefinch: classic
<fwereade> menn0, how much do you remember about writeUninstallFile?
<fwereade> menn0, my current understanding is that (1) we need to call it before the agent will pay attention to ErrTerminateAgent (2) there are cases where we send legitimate ErrTerminateAgents that don't have easy access to writeUninstallFile (3) I presume the writeUninstallFile came because we were getting rogue ErrTerminateAgents from somewhere and it was hard to stop them somehow?
<fwereade> menn0, (expansion of (2): and hence don't actually work right)
<mup> Bug #1547186 opened: Cannot create model with Azure provider <docteam> <juju-core:New> <https://launchpad.net/bugs/1547186>
<natefinch> ericsnow, katco: just thought of another benefit to components... it's trivial to test all the code in the component with a simple go test ./... from the top level directory.
<ericsnow> natefinch: nice
<natefinch> was just thinking of that as I am modifying some fairly core parts to resources... I can run all the resources test s in 6.5 seconds, and not worry that I'm missing anything.... and also not have to run 5 minutes worth of tests across the whole repo
<katco> natefinch: hey having a chat about a potential candidate; will be just a little late if you still want to chat
<natefinch> katco: kinda head down on getting the upgrade-charm test running... we can skip if you don't have anything to talk about
<katco> natefinch: k sounds good
<katco> natefinch: that's a good point about the component oriented approach
<natefinch> katco: since you often twiddle a lot of bits in a lot of spots when modifying a feature.. it's nice to be able to very simply test everything you need and nothing you don't.
<katco> natefinch: yeah exactly
<davecheney> thumper: this might explain why restore was so hard
<davecheney> https://github.com/juju/juju/pull/4459
<davecheney> the -b flag, for restoring to a running state server was missing
<thumper> heh
<thumper> oops
<wallyworld> thumper: davecheney: that's only the cloud credentials branch, not master
<wallyworld> we removed it pending reworking some stuff but are re-instating it for now (in cloud credentials)
<natefinch> perrito666: ^^
<natefinch> davecheney, thumper: if the flag was missing, why didn't we complain about an extraneous flag?
<davecheney> natefinch: who is we ?
<davecheney> if the flag is not defined it wont' show up in juju restore --help
<davecheney> (i don't think there is any CI integratino of backup and restore, there certainly is no unit testing of same)
<natefinch> davecheney: I mean, if you pass juju <something> a flag that it's not expecting, the first thing it should do is say "unexpected flag '-b'" .... but it didn't looks like it was doing that
<davecheney> wallyworld: on master from yesterday, http://paste.ubuntu.com/15121569/
<davecheney> no -b
<davecheney> no, i did not try to invoke restore with -b
<davecheney> because --help did not list it as an option
<natefinch> davecheney> lucky(~/src/github.com/juju/juju) % juju backups restore -b --file juju-backup-20160218-040500.tar.gz
<natefinch> <davecheney> ERROR old bootstrap instance ["i-f007252f"] still seems to exist; will not replace
<davecheney> i think that is a differnt problem
<fwereade> menn0, axw: ping re ErrTerminateAgent and writeUninstallAgentFile
<menn0> fwereade: sorry, catching up
<menn0> fwereade: I don't know much about why the uninstall file was created
<menn0> fwereade: my only exposure to that code is when I've converted workers related to it to work with the dep engine
<fwereade> menn0, np, I just saw you and axw had touched related lines recently
<fwereade> menn0, I do have a theory
<natefinch> ericsnow: any idea why StagedResource.Activate() would fail both insert and update during tests?
<fwereade> menn0, that ErrTerminateAgent, being evil, was leaking out from somewhere unexpected and triggering agent suicides
<ericsnow> natefinch: not off the top of my head
<menn0> fwereade: sounds plausible / likely
<fwereade> menn0, and that someone added this additional mechanism -- without which ErrTerminateAgent doesn't work, and just gets swallowed as not-even-an-error
<fwereade> menn0, and now we have 2 places that use this I-really-mean-it mechanism
<wallyworld> davecheney: that's the old plugin
<wallyworld> there's a new restore command
<wallyworld> cmd/juju/backups/restore.go
<fwereade> menn0, and I now need a 3rd, because there's an evidently-undertested path that can generate ErrTerminateAgent and mean it
<fwereade> menn0, and which has thus been broken for quite some time
<menn0> fwereade: bugger
<menn0> fwereade: it seems like now is a good time to fix the situation
<fwereade> menn0, and ok it's low-impact because really anything waiting for the uninstall to happen is ludocrously optimistic *anyway*, dead means "you will be nuked from above"
<fwereade> yeah
<fwereade> I am just trying to keep it bounded
<menn0> fwereade: and get rid of the need for the I-really-mean-it mechanism
<fwereade> menn0, you speak truth
<menn0> fwereade: but yeah, scope creep is an issue
<fwereade> menn0, I just don't know where the rogue errors were coming from, and so the obvious approach is to go through adding safe ErrReallyTerminateAgentGodICantBelieveImSuggestingThis
<menn0> fwereade: maybe poke at it a bit to get a feel for how hard it will be to untangle?
<menn0> :)
<menn0> I wonder if thumper or wallyworld remembers where the uninstall file thing came from?
<fwereade> menn0, good question indeed :)
 * thumper is heads down
<thumper> which what?
<wallyworld> it rings a bell, i can remmeber discussion around it but not why it was added
<thumper> uninstall what?
<fwereade> agent uninstall
<thumper> manual machine removal
<thumper> manual provider
<thumper> stop being a juju machine
<fwereade> ErrTerminateAgent, that evil slice of crap that any cheeky worker can emit to take down the agent
<natefinch> ahh manual, the special needs child
<fwereade> right, that's why we'd *need* to uninstall
<fwereade> rather than just sitting back and waiting for death
<fwereade> but it's not *triggering* based on manualness
<fwereade> it's triggering based on did-the-thing-returning-ETA-also-invoke-the-magic
<thumper> almost certainly it could be done better
<thumper> with the new dep engine
<fwereade> anyway, np if nobody has context, I will figure something out
<thumper> but way out of my scope of caring right now
<fwereade> heh, that is the trouble
<fwereade> anyway, no worries, thanks for listening all ;p
<menn0> fwereade: np. let me know if something needs a review.
<thumper> fwereade, menn0: quick Q, should I use EndPoint or Endpoint ?
<natefinch> ericsnow: do you have 15 minutes to hop on a hangout and help me with this test?  I'm sure I'm doing something dumb and just not seeing it.
<fwereade> menn0, wil do, thanks
<fwereade> thumper, Endpoint IMO?
<ericsnow> natefinch: sure
<menn0> fwereade: I agree with fwereade
<menn0> thumper: "endpoint" is a word
<thumper> ac
<thumper> k
<thumper> I just hit a very weird test failure
<thumper> until I found that I had left "return nil" in a method
<thumper> to remind me to implement it later
<thumper> now is later
<sinzui> wallyworld: Do you have a moment to review http://reviews.vapour.ws/r/3903/
<wallyworld> sinzui: sure
<mup> Bug # changed: 1546348, 1546350, 1546836, 1546840
<mup> Bug # opened: 1546348, 1546350, 1546836, 1546840
<sinzui> wallyworld: are you actually reading the diff of the feasture branch?
<wallyworld> sinzui: yes
<sinzui> wallyworld: you like pain. I assume you reviewed the branches that went into the feature branch. My request is just a formal acknowledgement that we want to merge the feature branch into master with proof that CI likes it
<wallyworld> sinzui: in that case +1, so far it ssems all as i expect
<sinzui> wallyworld: fab. Thank you for cleaning this branch up so quickly. abentley  is standing by to switch CI to treat beta 1 as delta1....ohh..
<sinzui> wallyworld: do we need to change the version of this branch *before* we merge? I think we do
<wallyworld> sinzui: yes, good point. yes we do. sl long as the ci scripts are changed in sync
<mup> Bug # changed: 1546348, 1546350, 1546836, 1546840
<sinzui> wallyworld: CI is paused for the switch over. It is actually tessting the last non-voting job for cloud-credentitials. Can you update the version to beta1. The other option is to upfate master asfter this merges. We wont restart CI until the scripts are switch over and master has cc merged and knows it is beta1
<wallyworld> sinzui: if you have already done the pr, we can hit merge now and i will change version in a separate pr immediately after
<sinzui> wallyworld: okay, I am merging
<axw> fwereade: the uninstall file was added as a way to guard against unintentional signals
<axw> fwereade: it used to not be required, but IS hosed an environment by accidentally SIGTERMing jujud
<perrito666> k ppl EOD
<perrito666> axw: I am so hanging a huge picture of you on my office :p
<anastasiamac> perrito666: have a gr8 w/end
#juju-dev 2016-02-19
<axw> wallyworld: almost there, but I need to duck out
<axw> wallyworld: I'll push the code now, and fix the remaining bugs when I get back
<wallyworld> axw: no problem, ty
<axw> wallyworld: https://github.com/juju/juju/pull/4469
<wallyworld> ta
<mup> Bug #1547268 opened: Can't bootstrap environment after latest lxd upgrade   <juju-core:New> <https://launchpad.net/bugs/1547268>
<thumper> fwereade: are you still lurking?
<axw> wallyworld: bugs fixed, PTAL
<wallyworld> looking
<wallyworld> axw: did you see my last question about map/slice?
<axw> wallyworld: I didn't. no, it won't work, goyaml will unmarshal it as the default types (MapItem is (interface{}, interface{}))
<wallyworld> and we can't do a type assertion?
<axw> wallyworld: no... that's never going to work. goyaml just sees a MapSlice, it doesn't know you want it to be a region
<wallyworld> ok
<wallyworld> axw: also, change the version to beta1 in the PR so we land one change
<axw> wallyworld: sure, just about to rebase on master, will do that
<wallyworld> axw: and just for sanity since we need this to get blessed with one run, test live?
<axw> wallyworld: will do
<wallyworld> ta
<katco> axw: o/
<axw> katco: heya
<katco> axw: don't need anything, just thought i'd say hey while the opportunity presents itself :)
<axw> katco: :)
<axw> katco: I was looking forward to having standups with you and the others, timezones suck
<katco> axw: that they do. i'm positive we'll be in one together sometime in the near future
<axw> maybe I'll get up before the crack of dawn one day
<katco> axw: haha, that will be a nice surprise, but certainly not expected
<katco> axw: wallyworld said, "we'll all just move to st. louis" which i think is an awful idea
<katco> axw: of course i'm not sure i'd like to live in the land of giant spiders either :|
<axw> katco: heh :p
<axw> they mostly just sit there and watch you
<katco> that's even worse!
<axw> wallyworld: what magic do you use to preserve the line ending in setup.iss when updating the version? or does it not matter?
<wallyworld> axw: i think my IDE respects what is there
<sinzui> axw, in every editor I have used to edit setup.iss, all is fine, but git's diff makes the line ending look scary
<axw> sinzui: ok, thanks. I'll sed it and hope for the best
<axw> wallyworld: https://github.com/juju/juju/pull/4470   <- same changes + delta1->beta1
<wallyworld> looking
<wallyworld> axw: lgtm
<axw> wallyworld: I'm going to copy&paste the bootstrap release notes as a reply to your email
<axw> wallyworld: so people know how to bootstrap... and thye can vet the notes at the same time
<wallyworld> axw: ah yes, good idea, ty
<wallyworld> axw: i am so used to the new syntax i forgtot others wouldn't be :-)
<wallyworld> other devs
<axw> wallyworld: I can update the list-clouds output if you like
<axw> if you're not already doing it
<axw> wallyworld: list-clouds output order is not right :/   must be another map somewhere
<wallyworld> damn
<wallyworld> in the cmd i guess
<axw> wallyworld: yep, in cmd/juju/cloud/show.go
<wallyworld> axw: but the default regon is correct. so we can add a note in the release notes
<wallyworld> that list-clouds will be fixed next beta
<wallyworld> axw: i'm out for a bit so will pick up any remaining release notes issues when i get back unless you get to them first
<axw> wallyworld: sure
<axw> enjoy lunch
<natefinch> gaaaah uniter tests
<menn0> thumper and/or waigani: http://reviews.vapour.ws/r/3907/
<thumper> pending tests, I *think* I have relation imports working
<thumper> well, haven't tried to compile yet
<thumper> but the theory seems sound
<thumper> menn0: I'll take a look now before writing tests
<waigani> menn0: oh, was just going to look ....
<menn0> thumper: I like your optimism :p
 * menn0 facepalms
<thumper> waigani: you can look too
<thumper> that's fine
<waigani> thanks :)
<menn0> some people I know in Brisbane (acquaintances) just called their son "Pheonix"
<menn0> at least check the spelling of a word before calling using it for your child's name...
<natefinch> lol
<thumper> heh
<thumper> are they going to "fix" it?
<natefinch> friends of mine called their kid Orion... she's a girl
<thumper> or is this one of those new alternative spellings?
<thumper> at least not "north" or another direction
<natefinch> haha
<natefinch> another friend named their kid Aoife... which is evidently irish and pronounced eefah ... but yeah, good luck kid.
<thumper> menn0: done
<menn0> thumper: thanks
<menn0> thumper: man, I'm clearly tired. lots of stupid stuff
<thumper> :)
<davecheney> All, what is the client facade in the api server ?
<davecheney> is the apiserver a client of itself ?
<davecheney> is this a version of the human centepede ?
<davecheney> no, seriously
<davecheney> what is the Client facade that the API exports
<davecheney> axw: do you know
<axw> davecheney: it's the facade that does all the things that the CLI client wants to do. we've been slowly splitting bits out into new, more specific facades
<menn0> davecheney: what axw said. It has (predictably) grown into a kitchen sink of functionality.
<axw> davecheney: e.g. the Service facade for deploying. that used to be on the Client facade
<menn0> davecheney: nothing new should be added to Client now
<davecheney> so apiserver/client
<davecheney> imports api/ to get api.CharmInfo
<davecheney> this is 3 inches away from an import loop
<davecheney> client is a shitty name for an api endpoint
<davecheney> it would be like me having a child and calling it "person"
<menn0> thumper: review responded to: http://reviews.vapour.ws/r/3907/
<davecheney> hey can anyone get to ap-southeast-2 at the moment ?
<davecheney> ok, so trying to hit aws.amazon.com is routing via tokyo
<natefinch> your packets have a hankering for sushi, I guess
<davecheney> om nom nom
<natefinch> well, I've officially added a new test to the uniter.  And it only took 3 days.
<natefinch> that's not fair.  The test only took a day, it was 2 days of wrestling with the existing tests to figure out why they were failing.
<natefinch> but the test is only 3 lines, which obviously saved me a lot of time.
<thumper> :)
<davecheney> we have two CharmInfo structures delcared in the client
<davecheney> api.CharmInfo
<davecheney> api/charms.CharmInfo
<davecheney> !!!!
<davecheney> THEY ARE IDENTICAL
<thumper> bah, extra tests can wait
<davecheney> and in fact they have the same method on their type
<davecheney> axw: what the F
<davecheney> https://github.com/juju/juju/blob/master/api/charms/client.go#L15-L43
<davecheney> https://github.com/juju/juju/blob/master/api/client.go#L161-L178
<axw> davecheney: I suspect the one in api should have been deleted
<davecheney> trying to figure out which one is unused now
<axw> davecheney: it should be in the params package anyway
<axw> wait... there is one in the params package
<axw> sorry
<axw> never mind.
<davecheney> the api/charms package's CharmInfo method is not used
<davecheney> if I remove the method
<davecheney> then api/charms no longer needs to import "gopkg.in/juju/charm.v6-unstable" as charm
<davecheney> which undermines the name of the whole package
<axw> davecheney: sounds good. that apiserver/client code for CharmInfo might still be required for the GUI, not sure. should be safe to remvoe the api code tho
<davecheney> if the gui needs it
<davecheney> all it cares about is the json form
<davecheney> which is what I was checking
<davecheney> but it turns out that no copies of CharmInfo have any json tags
<davecheney> so we can just replace them with an anon stryct
<davecheney> so we can just replace them with an anon struct
<davecheney> axw: besides i'm removing code from api/
<davecheney> so the gui won't be affected
<axw> davecheney: yeah, I'm saying that's fine, but we should check before going further and removing the backend from apiserver/client
<axw> not that you said you were going to, just in case
<davecheney> axw: https://github.com/juju/juju/pull/4474
<davecheney> yeah, i won't remove that method
<davecheney> just it's dependency on a type defined in it's client
<davecheney> just its dependency on a type defined in its client
<axw> davecheney: uh sorry, lost in translation. I thought you were removing them from the api/client.go code. I'm pretty sure the code should be changed to use api/charm instead of api
<natefinch> man, I'm going to start squashing all my branches down to a single commit... it makes rebasing and cherry-picking and all that garbage so much easier.
<natefinch> axw: on that review where I'm trying to get API params to show during tests... you said to tweak the logging instead. Do you know where that would be done?  JujuConnSuite or something?
<axw> natefinch: if it's for a full stack test, which I assume it is if you need logs, that'd probably be the appropriate spot
<wallyworld> axw: looks like CI is borked so lets sneak this one in http://reviews.vapour.ws/r/3911/
<axw> wallyworld: ... http://reviews.vapour.ws/r/3906/
<wallyworld> damn :-)
<wallyworld> axw: but does map slice work as expected for json
<axw> wallyworld: it'll come out as a [{Key:name, Value:{...}}]
<axw> wallyworld: not ideal. hadn't thought of JSON
<wallyworld> axw: i think my solution works for json
<wallyworld> i could add you test stuff to my branch
<axw> wallyworld: yes please
<wallyworld> sure, will do
<axw> wallyworld: except mines based on formatting/parsing the YAML...
<axw> wallyworld: maybe the YAML format could use Regions instead of RegionsMap?
<wallyworld> axw: to preserve order, yeah, good point
<wallyworld> i'll rework it a bit
<dimitern> wallyworld, axw, just running make check now on master triggered my chrome to open up and ask for credentials - could it be related?
<wallyworld> credentials for what?
<dimitern> well, the sso screen
<axw> dimitern: nothing to do with our changes. *maybe* related to macaroons?
<dimitern> axw, ah, could be
<axw> wallyworld: what version of lxd do you have?
<axw> I dist-upgraded and now lxd provider doesn't work.
<wallyworld> axw: sadly i updated today and so i suspect i am borked
<axw> :/
<wallyworld> yep, known issue, casey files a bug
<wallyworld> they don't test juju with their stuff it seems
<wallyworld> bug 1547268
<mup> Bug #1547268: Can't bootstrap environment after latest lxd upgrade   <juju-core:New> <https://launchpad.net/bugs/1547268>
<axw> wallyworld: lxd_2.0.0~beta2 is OK, FYI
<axw> just uninstalled and installed the deb from cache
<wallyworld> axw: yeah, i think i was running that one priot to the upgrade
<wallyworld> axw: PTAL, also fixed a bug where we were printing storage endpoint in region details even if it was the same as the cloud default storage endpoint
<axw> wallyworld: the same applies to Endpoint
<wallyworld> doh
<wallyworld> of course
<axw> wallyworld: are we pushing the register one through as well, or wait till after?
<wallyworld> axw: it seems pretty safe doesn't it
<wallyworld> will only fail in unit tests
<axw> wallyworld: yeah, also pretty safe to leave it out tho. assuming people don't expect to be able to upgrade from a beta to release...
<wallyworld> we don't support upgrade, and models.yaml is changing also anyway
<axw> true
<axw> wallyworld: I'll just leave it till later. no need to rush it through
<wallyworld> +1
<wallyworld> i hope this current change gets through CI in time
<wallyworld> shoudl do
<frobware> dimitern: ping
<dimitern> frobware, pong
<frobware> dimitern: can we do standup now? james is out, as is michael, and I want to futz with my hosts /e/n/i. :)
<dimitern> frobware, sure, why not - omw
<frobware> dimitern: ah, I suspect I'm in the wrong HO... tis Friday.
<cmars>  https://bugs.launchpad.net/juju-core/+bug/1547268
<mup> Bug #1547268: Can't bootstrap environment after latest lxd upgrade   <juju-core:New> <https://launchpad.net/bugs/1547268>
<cmars> latest lxd (2.0.0~beta3) upgrade seems to break the LXD provider ^^
<cmars> wily does not seem to be affected, but if you're installing lxd from the lxd-stable PPA on trusty, or testing xenial, you'll see it
<cmars> also, i can't seem to juju init with latest master. gonna open a bug...
<katco> ericsnow: hey i left several comments on your download resource metadata pr... lmk if you want to chat about it
<katco> natefinch: how goes the uniter tests?
<natefinch> katco: got them working last night, finally.
<katco> natefinch: woohoo! ah i see your review now
<katco> natefinch: moved your card for you
<katco> natefinch: can you give ericsnow's prs a review?
<natefinch> katco: will do
<ericsnow> katco: thanks
<katco> natefinch: review up
<natefinch> katco: thanks!
<mup> Bug #1547186 changed: Cannot create model with Azure provider <docteam> <juju-core:Invalid> <https://launchpad.net/bugs/1547186>
<perrito666> does anyone know how livetests work?
<natefinch> perrito666: nope
<perrito666> they seem to be mocking ec2, not sure where
<katco> perrito666: hey i know a bit how they work
<perrito666> katco: can you give me a hint? :)
<katco> perrito666: no, i just wanted to let you know i knew :) 1 sec
<katco> perrito666: https://github.com/go-amz/amz/blob/v1/ec2/ec2test/server.go
<katco> perrito666: except you probably want latest, so make sure you hit the v3/v4 branch
<dimitern> frobware, hey
<niedbalski> perrito666, mfoord do you guys know if LP 1435283 is entirely fixed? we are seeing a weird behavior with 1.25.0 (http://paste.ubuntu.com/15132753/) , basically is picking any address as the public-address instead of using a sticky one since first election.
<dimitern> frobware, I've proposed the next step: https://github.com/juju/juju/pull/4481, a few things still remain around tests, but I need to go out, so I'd appreciate if you have a look later
<perrito666> niedbalski: have no clue
<niedbalski> dimitern, can you take a look ? ^^
<dimitern> fwereade, if you're around, I'd very much like your thoughts on that as well ^^
<perrito666> katco: thanks taking a look, I am pretty sure the filter I need is not implemented, because such is my luck
 * dimitern reads scrollback
<katco> perrito666: =/ lmk if you need anything else
<dimitern> niedbalski, well, the fix for that bug in 1.25 IIRC was to ensure whatever gets picked for private/public address sticks for the lifetime of the machine
<dimitern> the story for 2.0 is a lot better though
 * dimitern needs to step out, perhaps back later
<niedbalski> dimitern, well, it doesn't seems to be the case with 1.25.0 http://paste.ubuntu.com/15132831/
<fwereade> dimitern, sorry, I don't think I have any special insight -- did I michael EOWing the other day?
<katco> ericsnow: review on your other pr
<ericsnow> katco: thanks!
<ericsnow> katco: you're tearing it up!
<katco> ericsnow: uninterrupted blocks of time!
<ericsnow> katco: get used to it :)
<ericsnow> katco: (and the consequences <wink>)
<katco> ericsnow: natefinch: master merged into the feature branch cleanly. merge PR CI run underway
<katco> (god bless the component oriented approach)
<perrito666> bbl,
<perrito666> katco: btw, thank you for the pointer it was very helpful.
<katco> perrito666: np, i'm hear for anything you need in the future
<katco> perrito666: i am the ian of the western hemisphere
<katco> perrito666: bleh... s/hear/here/g
<ericsnow> katco: +1 (long live the component-oriented approach!)  :)
<natefinch> katco: awesome about merging master
<katco> ericsnow: natefinch: 7 line change: http://reviews.vapour.ws/r/3916/
<dimitern> fwereade, sorry for the mix up, I meant if you can have a look at this PR https://github.com/juju/juju/pull/4481
<lazyPower> hi o/
<lazyPower> did we nuke kvm as a provider option when we nuked the local provider?
<mbruzek> I am trying to set up juju 2.0 and I really need kvm
<lazyPower> mbruzek really wants to know
<mbruzek> I get an error when bootstrapping kvm.
<mbruzek> ERROR model "kvm" has an unknown provider type "local"
<mbruzek> Does anyone know how I can use kvm in 2.0?  We need that because containers currently don't run in lxd.
<katco> lazyPower: mbruzek: if we did, that was unintended
<katco> tych0: do you have any insight? ^^^
<lazyPower> mbruzek - app-containers *ftfy
<mbruzek> katco: I tried changing the provider to "kvm" that did not work either.
<mbruzek> katco: I was really happy with the kvm support in juju 1.25 it was nearly as fast as the lxc provider, and it let me run docker containers inside kvm machines.
<katco> mbruzek: good to hear. we'll figure out what's going on. it should still work, so either an oversight or we've changed how you interact with it
<mbruzek> katco: Yeah if there is a new way to configure it I would be willing to test those instructions out.
<mbruzek> katco: I checked the docs and seem to be configuring it properly
<mbruzek> https://jujucharms.com/docs/devel/config-KVM
<katco> ericsnow: natefinch: master merged into feature-resources. i don't expect you to have conflicts, but might want to rebase all the same.
<ericsnow> katco: k
 * katco lunches
<ericsnow> natefinch: I just reviewed your patch
<natefinch> ericsnow: thanks!
<natefinch> ericsnow: in theory, resources in the DB shouldn't ever change unless their bytes change, right?  It would be kind of bad if a resource got updated with a different origin or type or something
<ericsnow> natefinch: that's mostly true
<natefinch> ericsnow: there's two logical parts of a resource - the definition as exists in the charm metadata, and the bytes + metadata about the bytes
<ericsnow> natefinch: if I remember right, there's also info for a resource that will have bytes stored soon
<ericsnow> natefinch: e.g. charm store resource where no unit has called resource-get since the last time we synced up with the charm store info for that resource
<katco> ericsnow: you got a pile of comments dumped on you. working through them? disagree?
<ericsnow> katco: working on it :)
<katco> ericsnow: kk
<ericsnow> katco: I'll let you know
<katco> ericsnow: natefinch: just keep in mind we have 4 points to complete next week to stay on track. i have 2 of those in-flight, but waiting to see how ericsnow's poller patch turns out
<katco> ericsnow: also, i think i'll need to ask you to migrate the state stuff since you're most familiar
<ericsnow> katco: k
<natefinch> katco: I think that other 2 pointer will be pretty quick.  I think we're in good shape, but definitely if we can get ahead of the game and get more delivered than scheduled, we should try to do that.
<katco> natefinch: i agree on all counts
<ericsnow> katco, natefinch, rick_h_: doesn't there need to be a way to tell the controller to use a different charmstore revision of a resource?
<katco> ericsnow: what's the use case for that?
<natefinch> I thought it was juju upgrade-charm, to use the latest in the charmstore...
<katco> natefinch: ericsnow: ditto
<natefinch> I'm not sure the charmstore even exposes anything other than the current tuple
<katco> natefinch: well, i think we're defining that
<ericsnow> katco, natefinch: ah, the charm revision in the charm store isn't tied to a particular set of resource revisions
<ericsnow> katco, natefinch: but on the controller it is
<ericsnow> never mind then
<katco> ericsnow: i think we will be coupling those concepts in our new set of api endpoints
<ericsnow> katco: k
<katco> ericsnow: honestly, i probably need to spend next week digging into that
<ericsnow> urulama: ping
<ericsnow> urulama: we need to talk about resources in the charm store API (e.g. that charmrepo PR I put up)
<urulama> ericsnow: sure ... i've already pinged the team about that
<ericsnow> urulama: k
<urulama> ericsnow: sorry, but it's 10pm here and i really want to finish :)
<ericsnow> urulama: no worries :)
<urulama> ericsnow: so, talk to Francesco and Roger next week
<ericsnow> k
<mup> Bug #1547665 opened: juju 2.0 no longer supports KVM <juju-core:New> <https://launchpad.net/bugs/1547665>
<rick_h_> ericsnow: katco natefinch yes, this is all tied to the charmstore apis and updates required there.
<katco> ericsnow: standup time
<perrito666> seems that I drew the short straw for all neverending tests...
<perrito666> meh, hangout died no me
<katco> perrito666: i think it kicked us all out
<perrito666> oh I feel better now
#juju-dev 2016-02-20
<mup> Bug # changed: 1530957, 1532167, 1536446, 1536728, 1542127
<mup> Bug #1547741 opened: Cannot build on armhf with go1.2 <armhf> <packaging> <juju-core:Triaged> <https://launchpad.net/bugs/1547741>
<mup> Bug #1547806 opened: open-port does not work on EC2 <juju-core:New> <https://launchpad.net/bugs/1547806>
<mup> Bug #1547887 opened: Wrong endpoints for Joyent us-east-1 and us-east-2 <joyent-provider> <juju-core:Triaged> <https://launchpad.net/bugs/1547887>
<mup> Bug #1547891 opened: Juju searches for index2.sjson in image streams <streams> <juju-core:Triaged> <https://launchpad.net/bugs/1547891>
<mup> Bug #1547898 opened: create-model confusing, does not just work <create-model> <juju-core:Triaged> <https://launchpad.net/bugs/1547898>
<mup> Bug #1547898 changed: create-model confusing, does not just work <create-model> <juju-core:Triaged> <https://launchpad.net/bugs/1547898>
<mup> Bug #1547898 opened: create-model confusing, does not just work <create-model> <juju-core:Triaged> <https://launchpad.net/bugs/1547898>
<jcastro> did I miss something obvious? `juju init` doesn't work in 2.0beta1
<rick_h_> jcastro: there is no more init
<rick_h_> jcastro: you use list-clouds, list-credentials, etc
<rick_h_> jcastro: try add-credentials
 * rick_h_ hasn't upgraded on here yet
<rick_h_> jcastro: in beta1 there is no more environments.yaml
<jcastro> oh, well init still exists when I just type `juju`
<rick_h_> jcastro: hmm, have to look at why it exists.
<jcastro> ok I see the clouds
<jcastro> how do I do lxd then?
<rick_h_> jcastro: "it just works"
<rick_h_> jcastro: so juju bootstrap lxd $nameofcontroller
<rick_h_> jcastro: and lxd should be the name of the cloud in list-clouds
<jcastro> no lxd in clouds
<rick_h_> jcastro: can you bootstrap it with lxd?
<rick_h_>     juju bootstrap mycontroller lxd
 * rick_h_ wonders if it's there but not visible in list-clouds in this release then
<jcastro> ERROR cloud "lxd" not found
<rick_h_> axw: wallyworld around on the weekend at all? ^
<rick_h_> jcastro: probably have to manually edit the clouds.yaml file for now then if it's not there due to a bug/oversight on the release
<jcastro> trying that now
<rick_h_> jcastro: should be able to add a stanza that's just named lxd with the type value of lxd in it
 * rick_h_ needs to get my laptop out and update to the beta on there 
<jcastro> any idea where I can find a cloud.yaml example?
<rick_h_> should be in the .local/share/juju directory where things lived in alpha2
<rick_h_> it's plural
<rick_h_> clouds.yaml (if you're searching with mlocate/etc)
<jcastro> brand new install though
<jcastro> and init won't generate a skeleton for me since it doesn't exist
<rick_h_> it has to have stuck the file somewhere
<rick_h_> right, but the package install needs to stick that file somewhere
<rick_h_> and that should be in the xdg path
<rick_h_> along with credentials file location, etc
 * rick_h_ goes to get laptop, brb
<jcastro> the package doesn't have that file
<jcastro> do you think it's as simple as
<jcastro> lxd:
<jcastro>     type:lxd
<jcastro> I'll try that
<jcastro> also
<jcastro> Development releases use the "devel" simple-streams. You must configure
<jcastro> the `agent-stream` option in your environments.yaml to use the matching
<jcastro> juju agents.
<jcastro> in the release notes
<jcastro> So is environments.yaml gone or not?
<rick_h_> yes, but should say to use upload-tools perhaps?
<jcastro> I think there's a bootstrapping problem here
<jcastro> not like, bootstrapping in a juju context
<jcastro> but like, without init I don't have any information for juju to know about
<jcastro> and I can't add it because there are no example files
<jcastro> AHA!
<jcastro> dude
<jcastro> juju help add-clouds
 * rick_h_ is upgrading hoping this isn't a brown paper bag release
<rick_h_> jcastro: ah right
<rick_h_> jcastro: but there shuold still be a file that feeds the current list-clousd
<jcastro> nope
<rick_h_> heh running xenial means there's a lot more to upgrade than just juju
<jcastro> just an ssh directory and some keys in there
<jcastro> I am on trusty
<rick_h_> try juju update-clouds
<rick_h_> oh, I wonder if we blacklist there since lxd is wily+
 * rick_h_ is just guessing out the $#@$
<jcastro> ok, added
<jcastro> that wasn't so bad
<jcastro> looks like update-clouds didn't make it
<rick_h_> ok, wasn't sure on that one
<jcastro> yeah, it has to be because I am trusty
<jcastro> that's the only thing that makes sense
<rick_h_> bah, under dist-ugprade vs upgrade /me tries again
<jcastro> ok, will investigate tomorrow, for now it's chimichanga time
<rick_h_> woot
<rick_h_> thanks for the heads up, will check out here on xenial
<rick_h_> once the upgrade finishes
<jcastro> I'll ask on the list
<mup> Bug #1547966 opened: juju beta 1 does not include lxd in clouds <juju-core:New> <https://launchpad.net/bugs/1547966>
<wallyworld> rick_h_: hi
<wallyworld> just reading backscroll, lxd works out of the box, but not on trusty
<wallyworld> rick_h_: update-clouds not in this release, hopefully beta2
<wallyworld> rick_h_: and yeah, no lxd provider on trusty until lxd and golang1.5 added to backports
<rick_h_> wallyworld: k, I think he manually added lxd for his trusty
<rick_h_> wallyworld: so that makes sense, it should show in list-clouds. I know it's not 'public' but that's the list folks will look at how to try things
<rick_h_> wallyworld: so it needs to be a listed option
<rick_h_> wallyworld: ty for the heads up on that it should be working ootb for non-trusty
<wallyworld> rick_h_: yeah, we were following the spec for list-clouds output. easily added
<rick_h_> wallyworld: cool ty
<wallyworld> rick_h_: maybe release notes aren't explicit enough about lxd and trusty
<rick_h_> wallyworld: yea, I think there's a general assumption since we keep saying lxd >= wily
<rick_h_> but if folks manually go at it, they can get trusty/lxd
<wallyworld> i'm not sure of the status of the backports effortd
#juju-dev 2016-02-21
<tych0> katco: no, i didn't nuke kvm, at least
<mup> Bug #1548028 opened: Juju fails to bootstrap on LXD when ZFS has been setup <juju-core:New> <https://launchpad.net/bugs/1548028>
<jcastro> huh that's strange, that must be a new bug because when I set it up like Mark has it prior to beta1 it worked fine
<mup> Bug #1548076 opened: GCE credentials stored in the wrong envs <docs-team> <juju-core:New> <https://launchpad.net/bugs/1548076>
<mup> Bug #1548078 opened: when adding credentials to the credentials.yaml missing the 'name' level causes undecipherable error <juju-core:New> <https://launchpad.net/bugs/1548078>
<thumper> morning
<rick_h_> jose: ping when you get a sec. If you have an GSoC stuff I've got a perfect project
<jose> rick_h_: 'ello
<rick_h_> jose: did you get things filed/etc?
<jose> rick_h_: yup, but nothing is set on stone - we only have an ideas list
<rick_h_> jose: I've got a super project based on the beta1 use and I really want to get this added if possible
<rick_h_> jose: what's the timeline for projects to start?
<jose> oh, definitely!
<jose> we have to get chosen first, results come in on the 29th
<rick_h_> jose: so the project is a tool to aid in adding azure config. If you check out the beta1 release notes and the Azure instructions it's like 6+ commands with a nodejs cli tool
<rick_h_> jose: we should be able to wrap those with Go, maybe start as a plugin, and move to a tool in core to help setup the credentials.yaml for azure
<jose> let me double check the timeline
<rick_h_> and I think it'd be a great GSoC project
<jose> so... students begin coding on the 23rd may
<jose> https://developers.google.com/open-source/gsoc/timeline
<jose> and they finish coding on the 23rd august
<rick_h_> cool yea was just looking
<rick_h_> hmm, might want to have something before then. /me ponders.
<rick_h_> well, maybe worth putting as an idea?
<rick_h_> and we'll see what happens between now and then
<jose> yeah, definitely, let me get you that page
<jose> https://wiki.ubuntu.com/GoogleSoC2016/Ideas
<jose> if there's a student dedicated to charms/juju, then we can probably have him work on this as a subproject
 * rick_h_ loads
 * rick_h_ is having SSO fail on there...delays
<jose> hehehe
<menn0> wallyworld: ping
<menn0> waigani: resumer PR reviewed
<menn0> waigani: storageprovisioner PR reviewed too
<axw> wallyworld: won't be able to make standup sorry
<anastasiamac> axw: wallyworld will not either- no standup ;/
<axw> anastasiamac: ah ok. thanks. ttyl
<anastasiamac> axw: have fun \o/
<thumper> review board isn't picking up a new review... ï¿¼ 15 changed files  with 1,198 additions and 62 deletions.
<thumper> https://github.com/juju/juju/pull/4487
#juju-dev 2017-02-13
<wallyworld> axw: ah, i think i understand what you might be saying - snap lxd daemon picks up the request from juju rather than deb lxd daemon and hence the wrong lxd get used. i thought setting LXD_DIR was supposed to cause the right lxd to get used (at least that's what nicholas thought).
<menn0> wallyworld: I just realised that I hit the same thing with the conjure-up snap last week. it ships with its own version of juju and has LXD issues.
<wallyworld> menn0: yeah. adam and nick know about it. not sure exactly what their solution is. my system is still somewhat screwed even after removing lxd snap
<wallyworld> need to look at it again today
<menn0> wallyworld: do you need to run sudo lxd init again?
<wallyworld> that's my last resort, yeah
<axw> wallyworld: PR to update azure regions: https://github.com/juju/juju/pull/6969. seeing as we need to get the public-clouds.yaml updated anyway, figured we may as well try and get this one in too?
<wallyworld> sure
<wallyworld> axw: sorry about delay. lgtm but there's a block on landing it due to current QA policy. there's a meeting tomorrow where that will be fixed
<axw> wallyworld: thanks
<menn0> wallyworld: were you running into this at bootstrap? 2017-02-13 03:05:33 ERROR cmd supercommand.go:458 new environ: Get https://10.0.8.1:8443/1.0: x509: certificate has expired or is not yet valid
<menn0> anastasiamac: or is this what you saw? ^^
<wallyworld> menn0: similar, yeah, can't recall exact wording
<menn0> its happening for me r
<menn0> too
<menn0> axw: could ^^^ be related to the lxd cert caching change?
<anastasiamac> menn0: i did not see this. wallyworld may have... just fixed my lxd to work over the weekend. my failures were related to lxc profile misconfiguration
<wallyworld> menn0: i've had to totally purge lxd, manually remove neworks and ip links, lxd init again etc. still not there though - juju can't talk to container
<axw> menn0: maybe. or the snap. are you using the snap?
<menn0> no snaps involved
<axw> menn0: you haven't installed the juju or lxd snaps?
<menn0> not on this machine
<axw> menn0: ok. seems most likely related to my changes then. it doesn't happen to me though. can you try and isolate it?
<menn0> axw: sure. where's the cache file?
<axw> menn0: juju will pull certs out of either ~/.config/lxc or ~/.local/share/juju/lxd
<menn0> axw: I don't have ~/.local/share/juju/lxd
<axw> menn0: either/or. if that one doesn't exist, it'll look in ~/.config/lxc
<axw> (I don't have ~/.local/share/juju/lxd either)
<menn0> axw: lxc is working fine by itself
<menn0> axw: I just launched a container with "lxc launch"
<axw> menn0: lxc will use the unix socket locally
<axw> menn0: so HTTPS won't factor at all
<menn0> axw: ok right
<menn0> axw: moving the .config/lxc directory out of the way doesn't fix things
<jam> thumper: menn0: coming by to say hi?
<thumper> jam: yeah
<menn0> jam: coming
<axw> menn0: can you try adding some logging to finalizeLocalCertificateCredential in provider/lxd/credentials.go? we should be generating a new cert, uploading it to lxd, and then using that
<axw> wallyworld: can you pastebin the output of "lxc config trust list" for me?
<axw> wallyworld menn0: one possibility is that the certs in ~/.config/lxc are expired. mine expire in 2026...
<menn0> axw: but I moved them out of the way and the symptoms stayed the same?
<axw> menn0: ok, weird
<axw> menn0: even that doesn't repro for me
<axw> menn0: which version of ubuntu, lxd?
<menn0> axw: well those certs *have* just expired
<menn0>         Validity
<menn0>             Not Before: Feb 10 02:21:23 2016 GMT
<menn0>             Not After : Feb  9 02:21:23 2017 GMT
<menn0> lxd 2.0.8, xenial
<axw> menn0: did you add a lxd cert credential to credentials.yaml? by autoload-credentials perhaps?
<menn0> axw: no lxd creds in credentials.yaml
<axw> menn0: well if you moved the certs, I can't see how their expiry matters :/
<menn0> axw: unless there's something inside the lxd daemon?
<axw> menn0: maybe the server cert is the thing that has expired?
<axw> menn0: the client credential changes could be a coincidence. seeing as the client certs you had have expired, possibly the server cert has too
<menn0> axw: I think you're right. the problem happens with juju 2.0.3 too
<axw> menn0: ok, cool
 * axw wonders how to regen
<axw> menn0: looks like if you delete /var/lib/lxd/server.{crt,key}, lxd will recreate them on startup
<axw> wallyworld: ^^
<menn0> axw: they've expired too. that's got to be the problem.
<axw> menn0: terribly confusing coindidence :)
<wallyworld> axw: yeah, i did that earlier, full lxd reinstall and init was also needed for me
<wallyworld> due to wierd network issues
<jam> wallyworld: ping if you're around
<wallyworld> hey
<perrito666> morning you two
<wallyworld> evening here :-)
<perrito666> wallyworld: any urgent bug that was left last night? otherwise ill just pick from the pile
<wallyworld> perrito666: this one is important https://bugs.launchpad.net/juju/+bug/1623217
<mup> Bug #1623217: juju bundles should be able to reference local resources <juju:Triaged> <https://launchpad.net/bugs/1623217>
<wallyworld> not sure if it can be done in time
<wallyworld> ie not sure of the scope of any change, haven't looked into it
<wallyworld> jam: can i help with something?
<jam> on bug #1577556 they just mentioned that they saw a 'statuses' doc that didn't have a txn-revno. I was a bit confused but it looks like statuseshistory is where we don't use TXNs but 'statuses' we *should* be using txns, right?
<mup> Bug #1577556: unit failing to get unit-get private-address in the install hook <intermittent-failure> <network> <uosci> <OpenStack Charm Test Infra:Confirmed> <juju:Triaged>
<mup> <juju-core:Triaged> <juju-core 1.25:Triaged> <ubuntu-openstack-ci:Triaged> <mysql (Juju Charms Collection):Fix Released> <https://launchpad.net/bugs/1577556>
<jam> wallyworld: sorry, wrong bug. actual is bug #1484105
<mup> Bug #1484105: juju upgrade-charm returns ERROR state changing too quickly; try again soon <bug-squad> <canonical-is> <upgrade-charm> <upgrade-juju> <juju-core:Fix Released> <https://launchpad.net/bugs/1484105>
<perrito666> wallyworld: tx
<wallyworld> jam: yeah, status hisotry avoids txns. but the status doc itself in the status collection should use txn
<perrito666> afaik the regular status collection does use txns
<wallyworld> jam: all usages of statusDoc should be in the context of a txn.Op  slice
<jam> perrito666: right, its supposed to, I was worried we had a case where sometimes we were and sometimes we weren't.
<jam> but they are reliably (?) hitting a case where the statuses docs are missing the txn-revno, which is bad mojo for the TXN logic
<perrito666> jam: odd, I wonder if someone confused status with status history
<perrito666> jam: the latest status added was model status iirc
<wallyworld> jam: i just did a (quick) code search and can't see anywhere where we are writing to the status collection not using txns
<jam> perrito666: wallyworld: yeah, I grepped the code as well. It does mention an assert that "txn-revno == 0" which would indicate we tried to read it, got back 0 and then said "well, its gotta stay 0 for this updaet"
<wallyworld> jam:  you talking about assert := bson.D{{"txn-revno", txnRevno}} in statusSetOps() I assume
<jam> wallyworld: comment #16 on the bug
<jam> there is an enttry in txn queue that says: "a": { "txn-revno": NumberLong(0) }
<jam> my guess is that it read the doc, saw there was no txn-queue so got the 'zero' value and then put that back into the assert.
<jam> So I don't think that is what *caused* the problem in the first place, just those txns all fall over because the data is bad.
<jam> we don't really know what caused it to be bad in the beginning.
<wallyworld> jam: juju uses the txn-revno assert in a set status function (this pattern isused elsewhere too, eg updating ports). but i think that relies on a create being done first to insert the original doc and set the txnrev-no field. and we do have a createStatusOp.  i can't see how we would attempt to set a  status value on a doc with a given doc id without having done a create first
<wallyworld> and that create should insert the txnrev-no field
<jam> wallyworld: (a) race? (b) if we're creating the doc with an upsert, we're still using  the txn logic, and the mgo/txns is the thing that keeps txn-revno correct
<jam> we're just using an assert to say "if this doc is changed underneath us, ignore this change"
<wallyworld> that matches my understanding
<perrito666> jam: just a wild idea, do you think this could be caused by mgopurge?
<wallyworld> we create the doc with an insert and a doc not exists assert
<perrito666> wallyworld: https://bugs.launchpad.net/juju/+bug/1623217 seems like it will need some spec-ing and agreement from stakeholders
<mup> Bug #1623217: juju bundles should be able to reference local resources <juju:Triaged> <https://launchpad.net/bugs/1623217>
<wallyworld> probably, i just saw it and it looked important
<wallyworld> should move to 2.2
<perrito666> wallyworld: it has been like that since december, I dont think it is that urgent that we can skip proper procedure :)
<perrito666> we should get someone started on that spec though
<wallyworld> fair enough, i just skimmed it
<perrito666> true, was just a comment not a rant
<rick_h> perrito666: the goal there is just to allow local file paths like local charms
<rick_h> perrito666: so hopefully a short spec
<perrito666> rick_h: yes
<jam> rick_h: perrito666: not sure how much of a spec it should have, vs you already have a syntax for 'use this local charm' ./path, we just support that for a resource blob as well
<rick_h> jam: +1
<jam> perrito666: short enough spec for you ? :)
<perrito666> jam: sure it is, if annyone comes asking ill post that line :p
<jam> perrito666: I didn't think that was actually going into 2.1, and doing it post rc feels a bit late, but if it isn't terribly hard, it is a nice quality-of-life for a bunch of people
<perrito666> jam: I dont think ill be able to fit this into 2.1 most likely tonight ill move that to 2.2
<Dmitrii-Sh> https://github.com/cloud-green/juju-relation-mongodb/pull/6 cmars, mattyw - JFYI: sent out a couple of patches for the mongodb interface
<thumper> morning folks
 * perrito666 touches tip of hat
<mattyw> Dmitrii-Sh, hey there, thanks very much, will take a look
<tasdomas> could there be a reason why juju 1.25.6 fails to bootstrap an aws model with authentication failure, while juju 2.0.0 works fine (with the same credentials)
<thumper> tasdomas: no idea sorry
<mup> Bug #1664359 opened: Authentication fails for juju 1.25.6 on aws <juju-core:New> <https://launchpad.net/bugs/1664359>
<wallyworld> perrito666: thumper: IMO the proposed test fix for that status history test is too lenient - it throws away the notion of the order of the expected status messges
<wallyworld> the fix should have been to be lenient with the expected count of messages, not the order
<perrito666> wallyworld: I can very well send a follow up, since the test belo does test the order I thought it was not really that important
<wallyworld> it does but the two tests are ostensibly similar - one uses a filter, the other doesn't. they should essentially test the same things the same way
<wallyworld> just with nd without  filter
<perrito666> yes, but there is a race there, that infrastructure was built by william but he did not notice that by inserting the records with identical dates the ordering is non deterministic
<perrito666> two items with the same date can be returned in any given order, and that is ok
<perrito666> because in reality it will never happen that two items have the same date to the nanosecond
<wallyworld> ah, i see, that helps explain it a bit
#juju-dev 2017-02-14
<anastasiamac> menn0: wallyworld: txn-revno related bug 1484105
<mup> Bug #1484105: juju upgrade-charm returns ERROR state changing too quickly; try again soon <bug-squad> <canonical-is> <upgrade-charm> <upgrade-juju> <juju-core:Fix Released> <https://launchpad.net/bugs/1484105>
<wallyworld> that's the one
<menn0> anastasiamac: thank you
<anastasiamac> menn0: wallyworld: anytime \o/
<menn0> wallyworld: i've assigned that maas apt proxy one to you
<babbageclunk> menn0: review plz? https://github.com/juju/juju/pull/6974
<wallyworld> babbageclunk: easiest review eva https://github.com/juju/juju/pull/6975
<babbageclunk> wallyworld: looking
<babbageclunk> wallyworld: I mean, I've seen shorter, but that was pretty easy. LGTM'd!
<wallyworld> ty
<wallyworld> you say that to all the boys
<menn0> babbageclunk: looking
<babbageclunk> menn0: ta
<menn0> babbageclunk: great PR description! regarding your QA steps I would test with a charm that uses resources and ensure that those downloads go through the proxy
 * menn0 tries to remember a good charm to test with
<babbageclunk> menn0: ok - yeah, I was about to ask that
<menn0> babbageclunk: there *is* a good one - I used it for testing migration of resources
<wallyworld> menn0: tiny PR - prereq for maas apt proxy issue https://github.com/juju/utils/pull/267
<menn0> wallyworld: nice. will look soon.
<wallyworld> the juju one wil lalso be 2 lines :-)
<menn0> babbageclunk: the mattermost charm uses resources
<menn0> babbageclunk: that's a good one to test with
<babbageclunk> menn0: Ah, great, thanks/
<menn0> wallyworld: ship it
<wallyworld> ty
<babbageclunk> menn0: how can I get the download to happen a second time? Oh, I guess the first charm download should just not be mattermost.
<wallyworld> menn0: there were no tests for those fie names
<menn0> babbageclunk: yeah... once it's cached in the controller it'll keep using the cached version
 * babbageclunk goes for a run
<babbageclunk> anastasiamac: Thanks for updating the bug with the PR - just came back to do the same thing!
 * babbageclunk really goes for a run
<anastasiamac> babbageclunk: :)
<blahdeblah> Really actually running is a lot better for you than just intending to run & then not doing it. :-)
<wallyworld> menn0: another 2 liner https://github.com/juju/juju/pull/6976
<menn0> wallyworld: ship it
<wallyworld> ta
<menn0> wallyworld: don't forget develop
<menn0> babbageclunk: so much lovely copy pasta :)
<thumper> should we just do a bigger merge of 2.1 into develop as we near release?
<thumper> that way not everyone has to worry about every merge
<anastasiamac> thumper: menn0: +1 on merge from 2.1 into develop. jam is doing it almost daily
<anastasiamac> thumper: menn0: this also eliminates the need to add bugs to 2.2 series. it's noise! it is expected that whatever is addressed on 2.1 will go into 2.2
<anastasiamac> addition of 2.2 series only makes sense if *implementation* will change btw 2.1 and 2.2
<menn0> anastasiamac: sgtm
<menn0> babbageclunk: review done. sorry for delay. lots of interrupts.
<anastasiamac> thumper: wallyworld: menn0: for allocation... would be awesome to have snap bin in $PATH - originally triaged to 2.2 coz life... bug 1660273
<menn0> babbageclunk: a few little things, depends on your QA as well of course
<mup> Bug #1660273: `juju run` does not include /snap/bin in $PATH <juju:Triaged> <https://launchpad.net/bugs/1660273>
<thumper> anastasiamac: seems like the host didn't have /snap/bin in the PATH
<thumper> we don't do anything special with PATHs here
<anastasiamac> thumper: it has been seen by different ppl. we need an answer
<anastasiamac> thumper:  the most recent ne was from stub
<anastasiamac> one*
<thumper> my answer is that it isn't juju's job to manage the snap path
<thumper> who knows about snaps?
<anastasiamac> k. i guess balloons for us?...
<stokachu> i do
<stokachu> so xenial server contains /snap/bin in $PATH but the cloud images do not
<stokachu> probably easier to go that route if you need it included
<anastasiamac> stokachu: note on the bug would be awesome \o/ do we need to get CPC team involved?
<stokachu> anastasiamac, yea probably talk to slangasek about getting it added
<axw> wallyworld thumper menn0 anastasiamac: do any of you have access to any non-x86 machines that I can test manual provisioning on?
<stokachu> anastasiamac, which bug?
<stokachu> https://launchpad.net/bugs/1660273?
<mup> Bug #1660273: `juju run` does not include /snap/bin in $PATH <juju:Triaged> <https://launchpad.net/bugs/1660273>
<thumper> axw: sorry, no
<menn0> axw: I do not
 * axw looks at qemu with resignation
<wallyworld> :-(
<axw> that's a bad word isn't it
<anastasiamac> stokachu: yes. (I *think* i marked all related to it as duplicates..  there shouldn't b others floating around)
<anastasiamac> axw: no :( maybe QA team does?
<axw> oh yes of course
<axw> anastasiamac: thanks
<anastasiamac> axw: \o/
<axw> veebers: do you have a non-x86 machine I can test manual provisioning on?
<veebers> axw: I don't, I'm not sure what hardware CI might have available for such a task either, I can find out for you
<axw> veebers: if you would that'd be great, thanks
<veebers> axw: can do, will probably be tomorrow before we get the info though
<axw> veebers: okey dokey
<axw> veebers: I'll look at using a public cloud provider for now, but will be good to know for future
<veebers> axw: ack, sorry I didn't know off-hand :-P
<axw> veebers: no problem, thank you
<axw> whoa, develop is blessed
<balloons> veebers, the jenkins slaves can be used as needed for non-x86 hardware. What does axw need?
<axw> balloons: anything will do
<axw> arm64?
<balloons> anything? axw, there's also the porter's boxes
<axw> balloons: the what now?
<axw> oh OS porters?
<balloons> right
<axw> balloons: how does one get access? I want to run juju on the host, and provision a LXD container in it
<menn0> babbageclunk: easy one: https://github.com/juju/juju/pull/6977
<balloons> axw, anyways, what do you want to do on the machine?
<babbageclunk> menn0: looking
<balloons> axw, cloud-city is your ticket to getting in; look at the ssh config in that repo, along with the key you need to ssh in
<axw> balloons: ok thanks. I already spun up a host on Packet, but will have a look there next time
<balloons> axw, I was poking veebers since it would be useful for him to know this :-)
<balloons> But it would be useful for the devs to know it as well
<axw> okey dokey
<veebers> balloons: indeed, thanks for that I'll make sure to remember for the future :-)
<balloons> veebers, happy belated birthday.. must be almost 2 days late now eh? But it's your birthday here!
<veebers> balloons: heh, only 1 day. Thanks! ^_^
<anastasiamac> veebers: \o/ HB!!
<veebers> anastasiamac: thanks :-)
<axw> veebers: happy birthday :)
<veebers> thanks axw
<axw> so I have Juju running on a machine with 96 ARM64 cores, 128GB DDR4 ECC RAM. fun
<babbageclunk> veebers: Happy birthday! For yesterday!
<veebers> cheers babbageclunk
<veebers> axw: just saw your email, 96 cores! nice
<axw> veebers: I'll file the bug
<veebers> axw: ah re: cores not showing the correct value. sweet
<babbageclunk> menn0: yay, proxy stuff looks good - it's quite fun watching all the requests scroll past in the log
<babbageclunk> menn0: What did you want me to look out for wrt resources?
<menn0> babbageclunk: just that the resource download also goes through the proxy when you expect it to
<menn0> babbageclunk: I guess if it's TLS, it's hard to tell?
<menn0> babbageclunk: they come from the charm store
<babbageclunk> menn0: but that wouldn't be installed until after the charm software?
<menn0> babbageclunk: that's right. the resource gets pulled when the first unit requests it.
<babbageclunk> menn0: oh, just saw some stuff for api.jujucharms.com - presumably that was it (since the charm code itself would have been downloaded before the deploy started).
<babbageclunk> menn0: ok, I think that's right.
<menn0> babbageclunk: sounds good! nice work.
<axw> jam: I've updated https://github.com/juju/juju/pull/6970 with a fix for the arch thing, PTAL when you can
<axw> (also responded to your other questions/comments)
<axw> wallyworld: did you see my replies on https://github.com/juju/juju/pull/6970? are your concerns allayed?
<jam> axw: we should probably just chat about it quickly
<jam> as I don't think I conveyed my thoughts well, given your replies
<axw> jam: ok
<axw> jam: https://hangouts.google.com/hangouts/_/canonical.com/axw-jam?authuser=1
<axw> jam: or we can IRC if you prefer
<jam> ho, just give me a sec
<axw> jam: just thinking about the Arch thing a bit more. it's possible for InstanceConfig to have tools for multiple arches, so we can't set an overall Arch on entry. the provider gets to choose which arch to start. for LXD, we filter it down to the host arch before passing the tools.List in
<axw> jam: I'll leave a comment explaining that where I've used the AgentVersion method
<axw> jam: alternatively I can just call HostArch, that might be clearer
<jam> axw: I'm happy with HostArch, but a comment is probably useful as well
<axw> jam: will do
<axw> jam: ah, NewKvmBroker is the one you're going to delete. sorry for the noise
<jam> axw: yhea
<jam> yehaa? anyway, np
<wallyworld> axw: sorry, missed your msg
<axw> wallyworld: np, I merged it anyway :p
<wallyworld> yeah i read the comments
<mup> Bug #1664359 changed: Authentication fails for juju 1.25.6 on aws <juju-core:Invalid> <https://launchpad.net/bugs/1664359>
<axw> anastasiamac_: I can't repro https://bugs.launchpad.net/juju/+bug/1539684 in 2.1. what's the protocol, mark as Invalid and say to reopen if it's still an issue?
<mup> Bug #1539684: storage-get unable to access previously attached devices <canonical-bootstack> <storage> <juju:Triaged> <https://launchpad.net/bugs/1539684>
<anastasiamac_> axw: no protocol - depends on the bug :) if the issues is suspected to b fixed, makr as Fixed Committed
<axw> anastasiamac_: ok
<anastasiamac_> axw: if noone touched the functionality, quirks in setup, etc, then Invalid (if we won't fix)
<anastasiamac_> or incomplete if we need more info
<axw> anastasiamac_: well the code was overhauled in 2.0 (actually 1.26)
<axw> anastasiamac_: so could well be a fix fell out of that
<anastasiamac_> axw: so most likely its Fixed :)
<anastasiamac_> axw: yes
<axw> anastasiamac_: I'll mark as Fix Committed with a comment to that effect
<anastasiamac_> axw: my hero \o/
<axw> jam: can you please take a look at https://github.com/juju/juju/pull/6980?
<jam> axw: fwiw, I had submitted https://bugs.launchpad.net/juju/+bug/1654943 but it seems your bug predates mine
<mup> Bug #1654943: cloud init script should have better preference for IP addresses for agent binaries <containers> <network> <spaces> <juju:Triaged> <https://launchpad.net/bugs/1654943>
<axw> jam: ah, I'll reference that in the TODO then
<axw> oh but you already made it a dup
<axw> jam: I think we should leave that one open for the final fix
<jam> axw: either way, I marked it a duplicate, but if we want to leave mine open as a "correct fix" vs yours as the "quick timeout" that's fine with me
<axw> yeah, I'll make the change
<jam> axw: we don't have a test anywhere of the command we create for curl? it seems like just getting the command string and asserting it, with annotations in the test as to why we want all the parts?
<axw> jam: we do, but it's not checking all the flags
<axw> I'll update before landing
<axw> jam: pushed again with test updated
<jam> btw, approved
<jam> axw: ^^ forgot to ping you
<axw> jam: thanks
<rogpeppe> anyone around to give a review of this, please? https://github.com/juju/juju/pull/6964
<rick_h> perrito666: ^
<perrito666> rick_h: rogpeppe just returning from lunch, ill take a look
<axw> thumper: can you please review https://github.com/juju/juju/pull/6982?
<thumper> shipit
<axw> gracias
<menn0-busy> anastasiamac_: so bug 1664409 certainly looks like a networking issue
<mup> Bug #1664409: juju 2.1-beta5 - juju 2.1rc2 - localhost failing to allocate a nested container with an ip <conjure> <regression> <juju:Triaged> <juju 2.1:Triaged> <https://launchpad.net/bugs/1664409>
<menn0> anastasiamac_: jam's theory about conjure-up workarounds fighting what juju is doing (now that it does things better) seems plausible
<menn0> anastasiamac_: aside from already having too much on his plate, jam is best placed to deal with it
<anastasiamac_> menn0: the question is - do we fix it on our side or conjure-up? do we have a fix? is a  quick fix? r we going to fix it today?
<anastasiamac_> menn0: questions r*... i guess :D
<wallyworld> thumper: for standup, which I'll miss due to interview, I have 3 PRs needing review, 2 juju and 1 goose (linked from the juju openstack PR). i also fixed 2 other bugs, the maas apt proxy one and the status colour one
<anastasiamac_> wallyworld: do u have a bug reference for colour one?
<wallyworld> anastasiamac_: no, it was a direct request
<stokachu> anastasiamac_, i dont have a fix yet
<stokachu> anastasiamac_, one thing ive been thinking about is not allowing conjure-up to deploy things to nested lxd containers
<stokachu> but that changes the deployment for just one provider since aws/gce allow this
<stokachu> and we try to stay as close to the bundle spec as possible
#juju-dev 2017-02-15
<anastasiamac_> stokachu: thank you for update \o/ it still leaves my questions open :) specifically, r we fixing it on conjure-up side or juju? nested lxd requirement came too late into 2.1 (we have not supported it previously)
<stokachu> anastasiamac_, so the branch that jam has will try to get a dhcp address from a nested container
<stokachu> anastasiamac_, i think that is a good approach
<stokachu> anastasiamac_, and i have been fixing it in conjure-up with the alteration of lxd profiles myself
<stokachu> anastasiamac_, now my fixes don't work anymore
<stokachu> and this is a heavily utilized feature of conjure-up and is at the center of http://ubuntu.com/cloud
<stokachu> anastasiamac_, so releasing juju 2.1 without having a solution i dont think is a good idea
<stokachu> anastasiamac_, menn0 https://github.com/juju/juju/compare/staging...jameinel:2.1-bridge-tweak that is what he referenced to me earlier
<stokachu> anastasiamac_, does that answer your question?
<anastasiamac_> stokachu: yes, coordination is the key :) thank you
<anastasiamac_> stokachu: of course, i meant cooperation \o/
<stokachu> :D
<stokachu> anyone around that can test conjure-up for bug https://bugs.launchpad.net/juju/+bug/1664409?
<mup> Bug #1664409: juju 2.1-beta5 - juju 2.1rc2 - localhost failing to allocate a nested container with an ip <conjure> <regression> <juju:Triaged> <juju 2.1:Triaged> <https://launchpad.net/bugs/1664409>
<stokachu> sudo snap install conjure-up --classic --edge
<stokachu> conjure-up kubernetes-core localhost
<wallyworld> axw: thanks for reviews
<axw> np
<wallyworld> axw: IIANM, the new azure regions are being tested right? so we'll be able to land your PR "soon"
<axw> wallyworld: pretty sure that's what aaron said
<wallyworld> great, yeah i thought so too
<thumper> wallyworld, anastasiamac_: fyi https://github.com/go-yaml/yaml/pull/241
<wallyworld> looking
<thumper> babbageclunk: do you know how to add patches for upstreams to our codebase?
<wallyworld> thumper: lgtm
<thumper> wallyworld: yeah, but getting it merged may be harder
<wallyworld> :-( may need to do as a patch like for mgo
<thumper> yeah, that's my thinking
<axw> I'm probably going to get disconnected as I test briding stuff. If I don't respond, you're talking to the ghost of axw
<axw> bridging*
<axw> always the bridge-maid, never the bridge
<babbageclunk> lol
<anastasiamac_> wallyworld: to avoid stepping on toes, in case anyone else is doing this... m going to try bootstrap openstack mitaka with ur keystone v3 related changes :D
<wallyworld> awesome ty
<wallyworld> we need to thoroughly test this change
<wallyworld> far out, another 2 blessed builds
<anastasiamac_> wallyworld: v3 stuff should probably go into release notes. cut and paste from ur email would b awesome :D
<wallyworld> indeed, that's the plan, plus a bit more
<anastasiamac_> \o/
<axw> menn0 jam wallyworld: will be a couple of minutes late, start without me
<wallyworld> ok
<menn0> wallyworld: give me 5 mins - need to sort out kids
<wallyworld> k
<thumper> https://github.com/juju/juju/pull/6983
<thumper> wallyworld: ^^
<axw> jam: do you think it's worth us both looking at the LXD networking thing independently? I can repro easily
<jam> axw: can you look at jameinel/juju 2.1-bridge-tweaks ?
<axw> jam: ok
<axw> jam: seems sane, I'll test it
<axw> right after I have some lunch
<axw> jam: so that might help in cloud images, but in the case of LXD provider it's not the issue. there, lxd-bridge is failing to start
<axw> journalctl says: "ip6tables v1.6.0: can't initialize ip6tables table `filter': Tabl"
<axw> err. ip6tables v1.6.0: can't initialize ip6tables table `filter': Table does not exist...
<axw> jam: 2.0.9 made some changes to do with ip6tables: https://bugs.launchpad.net/ubuntu/+source/lxd/+bug/1660506, so maybe related
<mup> Bug #1660506: SRU of LXD 2.0.9 (upstream bugfix release) <verification-done> <lxd (Ubuntu):Invalid> <lxd (Ubuntu Xenial):Fix Released by stgraber> <https://launchpad.net/bugs/1660506>
<jam> so it sounds like we have >1 bug, then
<axw> jam: actually I think I was just looking at outdated instructions. just need to add some kernel modules to the profile
<axw> testing again now
<jam> axw: did you want to meet to chat? We talked a bit earlier, so I don't feel like we have to if you're focused
<axw> jam: I'm happy to skip today
<axw> jam: which was the kubernetes/conjure-up bug #?
<axw> was/is
<jam> axw: bug #1664409
<mup> Bug #1664409: juju 2.1-beta5 - juju 2.1rc2 - localhost failing to allocate a nested container with an ip <conjure> <regression> <juju:Triaged> <juju 2.1:Triaged> <https://launchpad.net/bugs/1664409>
<axw> thanks
<anastasiamac_> plz add PRs to the bugs you work on :)
 * anastasiamac_ looks at some ppl...
<jam> axw: so testing the lxd case locally, it does look like my branch fixes the 'nested container doesn't use DHCP', I'm not 100% sure, but I'm pretty close to being sure
<jam> I saw it trigger the debug statement that should indicate the fix is working
<jam> I'm creating a trivial bundle for testing
<axw> jam: ok, cool
<jam> axw: hm. I wish nested containers would use the host LXD to seed the images... :)
<jam> I wonder how awful and hackish that would be
<axw> jam: probably not too hackish if we had the proxying story down, but otherwise I'm not sure
<axw> jam: I'm not sure where the change was made, but conjure-up kubernetes-core localhost is putting easyrsa on a top-level machine now. the bundle still appears to put it in a lxd container tho
<axw> jam: anyway, adding a unit of it to a (nested) lxd container works with your patch, doesn't work without it
<jam> axw: https://github.com/juju/juju/pull/6985
<jam> axw: I think stokachu changed kubernetes-core to use a local bundle that *doesn't* deploy into a container
<jam> I still need to solve the multi-network case, which I haven't actually formulated a solution for
<axw> jam: yeah that's what I figured, just can't see the commit on github
 * axw nods
<jam> but that likely also fixes bugs we've seen in GCE, etc.
<jam> axw: do you know how to tell conjure-up to refresh its cache?
<axw> jam: I don't know what cache you're talking about, so that'll be a no :)
<jam> axw: ~/.cache/conjure-up holds the spells, etc.
<jam> or ~/.cache/conjure-up-spells
<jam> but I don't know what/how that gets refreshed
<axw> I see
<axw> no idea, sorry
<jam> other than when you do it the first time it says "nothing found, refreshing"
<axw> jam: reviewed
<jam> axw: thanks. I'm trying to see if I can reproduce the nesting failure without juju in the mix
<axw> jam: which one?
<jam> axw: security.nesting: true not being enough to actually deploy a nested container
<jam> and I did
<axw> ok
<jam> https://github.com/lxc/lxd/issues/2885
<wallyworld> axw: does this look like the correct for bug 1645408? https://github.com/juju/juju/compare/2.1...wallyworld:azure-min-root-disk?expand=1
<mup> Bug #1645408: azure root-disk constraint fails if < default root disk size <juju:Triaged> <https://launchpad.net/bugs/1645408>
<wallyworld> *the correct fix
 * axw looks
<axw> wallyworld: hmmm. I guess so? I can't find anywhere that azure specifies what the minimum OS disk size is
<wallyworld> axw: me either. the best i found is that for linux it will be "approx 30GB"
<axw> wallyworld: where'd you see that?
<axw> wallyworld: also, can you please rename defaultRootDiskSize to minRootDiskSize
<axw> wallyworld: probably worth citing the bug since there's no docs or API that state the minimum
<wallyworld> axw: her's one place https://docs.microsoft.com/en-gb/azure/virtual-machines/virtual-machines-linux-expand-disks?toc=%2fazure%2fvirtual-machines%2flinux%2ftoc.json
<wallyworld> first para
<wallyworld> another place said ~30GB
<wallyworld> will do those changes, just have to duck out for school pickup in a sec
<axw> wallyworld: how very vague :)
<axw> wallyworld: ok
<wallyworld> yeah, you'd think they'd say explicitly
<axw> anastasiamac_: can you please review https://github.com/juju/utils/pull/265?
<anastasiamac_> axw: sure.. but need to go afk for a bit - kids time/dinner/life/etc...
<anastasiamac_> axw: nm - lgtm'ed :D
<axw> anastasiamac_: thanks
<wallyworld> axw: here's that azure pr
<wallyworld> https://github.com/juju/juju/pull/6986
<axw> wallyworld: trade you https://github.com/juju/juju/pull/6987
<wallyworld> ok
<axw> wallyworld: LGTM, thanks
<wallyworld> ty
<wallyworld> axw: +1 for your too. yay for no more fork
<jam> axw: the bot seems unhappy
<wallyworld> axw: not sure if your up for a small review https://github.com/juju/juju/pull/6984
<wallyworld> jam: looks like bootstrap cmd error waiting for lxd instance address. failed to bootstrap model: refreshing addresses: instances not found
<jam> wallyworld: well, not the only error. we were seeing mongo teardown errors in 2 of my attempts, and a PubSub timeout failure in the first attempt
<wallyworld> jam: i have seen a similar lxd error before and it was spurious i think
<wallyworld> i think you've just been unlucky :-(
<jam> 4 times unlucky sounds like hardware that is unhappy
<wallyworld> i think the record is 9 or something
<wallyworld> jam: 5th time lucky!
<jam> wallyworld: and here with us actually getting blesses, I thought this was getting better :)
<wallyworld> indeed :-(
<wallyworld> we did have a good run there for a bit
<jam> wallyworld: I'm struggling to find a way to test this bit of code, I don't want to take your evening but having a chat would be good
<wallyworld> sure
<wallyworld> HO?
<jam> wallyworld: https://hangouts.google.com/hangouts/_/canonical.com/a-team-standup?authuser=1
<axw> wallyworld: sorry was at school classroom meetings. gotta get kids ready shortly, will see if I can squeeze a review in
<wallyworld> axw: no worries, ty. only if you have time
<wallyworld> axw: thank you
<axw> anastasiamac_: thanks for spotting the real failure :)
<anastasiamac_> axw: sorry i didn't pick on it earlier \o/ but all in the day's work :D
<axw> bleh, could have sworn I added the dep
<mup> Bug #1613855 opened: SetAPIHostPorts runs afoul of "state changing too quickly" <juju:Fix Released by mfoord> <juju-core:Triaged> <https://launchpad.net/bugs/1613855>
<thumper> morning folks
<perrito666> morning thumper
<perrito666> kinda early for you isnt it?
<thumper> not too early
<thumper> 8:30
<thumper> I'm normally here sometime between 8 and 9
<cholcombe> is there any way to remove a storage pool once it's created?
<perrito666> I thought it was somewhere between 5 and 6
<thumper> cholcombe: I would hope so
<cholcombe> thumper: i can't seem to find it anywhere
<cholcombe> i'm on juju 2.0.3
<perrito666> mmmm, I would not be so sure, you will need to ask axw but he will not be here for a few hours
<thumper> cholcombe: yeah... seems strange
<thumper> I'm sure there is a reason for the behaviour, I just don't know what that reason is.
<cholcombe> i'm also looking for the magic juju env variable that lets me mount loopback devices in my lxc containers
<thumper> daughter forgot her guitar, just running down to her school
<thumper> bbs
<babbageclunk> Hey wallyworld?
<wallyworld> yo
<babbageclunk> wallyworld: I'm trying to work out why this comment is here: https://github.com/juju/juju/blame/staging/state/cleanup.go#L292
<babbageclunk> I don't think you're actually responsible for it, it looks like it was something that got merged in.
<babbageclunk> I guess 2 qs - do you know how I could find the original commit that added that (going to the previous in the blame doesn't help, the function just disappears)?
<wallyworld> yeah, not sure. william did the work from memory. i would have thought we'd need to also clean up non local charms eg resources etc
<wallyworld> you could look in develop history
<wallyworld> i think it would have been committed to that branch
<babbageclunk> duh, didn't click that I was in the staging branch.
<wallyworld> i'm not familiar with the code but can look around to see if the reason becomes apparent
<babbageclunk> hmm, no, that doesn't work - no matter what branch I look on it says you did it.
<wallyworld> i'll have to have a look into it
<babbageclunk> wallyworld: ha ha, that commit is 3694 files changed, 330,000 lines added, 180,000 removed. I think it's when you revived the CMR spike branch you guys had done a long time before?
<wallyworld> ah, right. yes that branch was merged in. are you saying that branch introduced that isLocal check?
<babbageclunk> wallyworld: no, just that it shadows the real commit that added that and I don't know how to get past it.
<babbageclunk> wallyworld: but I've found it just by assuming that Will did it.
<wallyworld> yeah, i'm not across the detail there
<babbageclunk> wallyworld: unfortunately his PR doesn't really explain why we wouldn't remove the charm if it's not local.
<wallyworld> :-(
#juju-dev 2017-02-16
<axw> wallyworld: https://github.com/juju/docs/issues/1665
<perrito666> externalreality: hey, feel free to ping me during the day if you need anything ill be during the day on GMT-3
<menn0> axw, wallyworld or thumper: can I bounce some ideas of one or more of you regarding CAAS?
<axw> menn0: sure, can you give me 5 mins please?
<wallyworld> sure
<axw> just finishing a review
<menn0> axw, wallyworld: cheers. i'll set up a hangout
<menn0> axw, wallyworld: https://hangouts.google.com/hangouts/_/zknvh6oslvc57oppedq6tkfpqae
<blahdeblah> Such a cool hangout name
<blahdeblah> I should make one like it
<blahdeblah> I think I shall name my hangout fee3och3AiwuNoquohvoo9chohhohche
<thumper> menn0, babbageclunk: I'm available now
<thumper> babbageclunk: https://hangouts.google.com/hangouts/_/canonical.com/bang-bang-chitty-chitty-bang-bang
<menn0> thumper: in call above
<thumper> menn0: ok, do you want / need me?
<externalreality> perrito666 thank you, will reach out if have anything :-D
<menn0> thumper: just finished all good
<thumper> ack
<axw> wallyworld: I'm a bit concerned about the performance of that remote relations watcher. apparently those things block the entire watcher infrastructure, so need to keep it as lean as possible
<axw> wallyworld: can we do a join of sorts on the applications/endpoints collections?
<wallyworld> axw: yeah agreed. i can't see  way to do it without a db query though
<axw> wallyworld: understood, just trying to keep the number of queries down
<wallyworld> i got it doen to 2 from 3
<axw> can we get it to 1 :)
<wallyworld> without a join?
<axw> wallyworld: with a join. is there an aggregation operator we can use.. not sure
<wallyworld> if it were sql it would be easy
<wallyworld> i didn't think mgo supported joins
<axw> wallyworld: apparently mongo 3.2 does: https://www.mongodb.com/blog/post/joins-and-other-aggregation-enhancements-coming-in-mongodb-3-2-part-1-of-3-introduction
<wallyworld> ooh, ok
<axw> wallyworld: not sure if it's worthwhile, maybe not
<wallyworld> hopefully mango will play nice then
<wallyworld> i'll have a look
<axw> wallyworld: another option would be to get all of the relation entries first, and add/delete to that collection in-memory as the watcher fires
<axw> wallyworld: that way you only need to query the remote applications collection inside the filter
<axw> I think that would be neater
<axw> seeing as we're already watching the relations collection
<wallyworld> what about scale, if there are 1000 of them. i guess it won't take too much memory
<wallyworld> or 10000 etc
<wallyworld> also when the watcher fires, we'd still need to look up the relation doc from the id
<wallyworld> maybe i'll see if the join works and go from there
<axw> wallyworld: don't spend too much time on it, I'm probably worrying about nothing
<wallyworld> axw: i'll just finish this gui thing i'm doing and will see if i can get it to one query
<axw> ok
<axw> thumper: is it known that the depengine report doesn't show model engines? so I can't see the provisioners, for example
<axw> unless I'm missing a flag or something...
<menn0> thumper: axw: the model engines are different (child) engines. maybe the report on asks the root engine
<axw> menn0: ah, it'll be bundled up in the state workers I guess
<axw> I think we should probably report on all the model engines too. or at least have a flag to specify a model
<menn0> axw: don't think the provisioner is bundled in the state workers
<menn0> axw: it's in the per model engines
<axw> menn0: the model engine is bundled into it. the provisioner is in the model engine
<axw> menn0: model engine runs under the "model worker manager" worker, which gets added to the runner returned by MachineAgent.startStateWorkers
<axw> anyway, I think we could weave it in there somehow. a job for another day
<menn0> axw: yes, it would certainly be useful to see
<axw> jam: can we defer till quarter past please, still eating lunch
<jam> axw: sure
<axw> jam: I'm there now
<wallyworld> axw: after your meeting, here's a GUI related PR https://github.com/juju/juju/pull/6992
<axw> wallyworld: looking
<wallyworld> ty
<axw> wallyworld: why did the base URL path need to change?
<wallyworld> because otherwise the gui would construct urls with the model path duplicated
<wallyworld> ip:17070/gui/u/admin/controller/u/admin/controller
<axw> wallyworld: is that due to a change in the GUI code?
<wallyworld> i'm running with stock 2.3.0 but i think there's an upstream change to do with the new url paths
<wallyworld> i've asked jeff and co to look at the pr also
<axw> wallyworld: reviewed. it looks good but I don't understand why the base URL pat change was necessary
<wallyworld> because it seems the gui appends /u/user/model to the base URL. the gui is expecting the base URL to be IP:17070/gui/modeluuid but the gui doesn't realise that juju ignore everything after $uuid
<wallyworld> with juju now able to handle gui urls with the model path, any bits after /gui/ are not needed
<wallyworld> as the gui appends the model path
<anastasiamac> wallyworld: Huw is in out time zone if u need fast turnaround
<anastasiamac> our*
<wallyworld> he is EOD
<wallyworld> but jeff and co aren't :-)
<anastasiamac> wallyworld: ^^ here is huwshimi \o/
<wallyworld> it's ok, ihave already been talking to others
<wallyworld> who are more immediately acros the issue
<wallyworld> axw: i've done some tests and sadly mongo joins ($lookup) don't work with dotted field names eg "endpoints.applicationname". i can only get it to work matching simple scalar fields. so looks like it has to be 2 queries for now
<axw> wallyworld: no worries, thanks for checking
<wallyworld> was interesting to try
<wallyworld> axw: i found out those gui changes with regards to the model path in the url are as a result of wanting to use consistent urls for juju and jaas. the gui work landed in gui version 2.3.0. so the fact that juju will now support those paths is actually a very good thing
<axw> wallyworld: does it break older GUI versions tho?
<axw> wallyworld: if you upgrade  the controller without upgrading the GUI, is the GUI broken all of a sudden?
<jam> axw: have you had conversations about how the storage changes for 2.2 will be reflected with bundles?
<axw> jam: no. what do the persistent storage changes have to do with bundles?
<wallyworld> axw: it suports both old and new clients (both ways), but there's a small glitch that showed up in my testing with old 2.0 cliesnts. the gui guys are looking at it and we'll fix. it could be upstream in the gui, not sure
<wallyworld> they'll help root cause it and then we can determine where the fix is needed
<axw> wallyworld: I saw the old/new juju clients work. but if the controller is serving GUI version 2.2 (or whatever preceded (2.3.0), will it work?
<wallyworld> it's only  a small issue with login
<wallyworld> yes because the juju gui CLI probes the controller to see what form of the url to use
<axw> wallyworld: I'm not talking about the URL the user plugs into the browser
<axw> wallyworld: you changed the baseURLPath from /gui/uuid to /gui
<axw> wallyworld: that affects what config gets passed to the GUI
<axw> wallyworld: will the old version of the GUI be unhappy with the change?
<wallyworld> right but the gui is downloaded with the controller
<wallyworld> so new 2.1 controllers will be running gui > 2.3.0
<axw> wallyworld: what if you do upgrade-juju?
<axw> from 2.0
<axw> or 2.1-beta5 for that matter
<wallyworld> i'll need to check to be sure
<wallyworld> but they can upgrade-gui also
<wallyworld> we may need to add some doc to release notes
<wallyworld> as it was, gui 2.3.0 was a bit broken with juju 2.1
<axw> wallyworld: yeah, I just don't want there to be a surprise
<axw> ok
<wallyworld> so either way we have potential breakage
<wallyworld> agreed, i'll talk to uros and co
<jam> axw: so in all my recent discussions, the only way people are really deploying things is via bundles, at least for many people they are "the way". Which just makes me want to raise the question of how storage interacts with it
<jam> things like "deploy gets extra flags", sounds like something we may need to introduce into the bundle stanzas
<jam> I'm trying to brush up on the topic before bringing it up, and just thinking about edges
<axw> jam: you can already do "juju deploy bundle --storage app0:store=foo
<axw> jam: is that what you mean?
<jam> axw: so conceptually things continue to use that syntax for --storage-filesystems, etc.
<jam> I'm a little concerned that it isn't very clear that '--storage ...' means allocate new storage vs "--storage-filesystems" means reuse an existing one.
<axw> jam: hmm yeah I guess we'll have to support that too. hadn't considered that
<jam> axw: also, it feels like you still need to use '--storage' as part of deploy at least, since that's declaring the shape of the storage for future units
<jam> (add-unit with no flags)
<axw> jam: yes, that is correct
<jam> axw: this sort of thing makes me wonder if we would have been better splitting deploy, or at least introducing a "declare an application but don't give it units yet"
<jam> probably not, as what a user really wants is a running application, but it would help with some of the "am I talking about the unit that is being brought up, or about the overall application"
<axw> jam: it would make it clearer for the latter case, but yeah, probably don't want to push that onto everyone
<jam> axw: is there a reason we have to think about "volumes" vs "filesystems" ? Is that actually interesting for the operator?
<axw> jam: I think so, because you can't assign a filesystem to a block-type store
<jam> axw: so that's a true statement, but is that a fundamental flag that you have to supply all the time/
<jam> ?
<jam> vs "juju deploy --attach-storage foo=bar" and getting a "bar is a volume not a filesystem, see "juju storage --filesystems"
<jam> or --reuse-storage
<axw> jam: the problem is that the volumes and filesystems just have numeric IDs
<jam> axw: sure, but we can pull them from the same integer counter, couldn't we?
<jam> as in its just 2 vs 3, but it is still just an arbitrary integer
<jam> axw: and fwiw, I have a strong feeling that people are really going to want to be naming these things
<axw> jam: I suppose so. that doesn't seem like better UX to me. it's not obvious on the command line what the ID is
<jam> axw: which is a point for not using just IDs
<jam> cause they don't mean anything to anyone
<jam> volume 10 isn't particularly more descriptive than just 10
<jam> but "production-db-disk" would be
<axw> jam: volume-10 tells me what it is, but not what it's used for. it's not nothing, but it's not perfect either
<axw> jam: I think people have asked for the ability to name things already
<jam> axw: well you're propsed syntax is --storage-volume foo=10
<jam> which decouples the "volume" from the 10 by a pretty wide margin
<jam> and doing
<jam> --attach-storage foo=volume-10
<jam> seems better if it is *just* that
<jam> axw: on 'list-volumes" (whatever the specific name), how do you figure out what '10' was?
<jam> we include information about what the last unit to mount it, and for what named store of that unit?
<axw> jam: it gives you the name of the machine attached to, the location, the storage instance
<jam> axw: the output of "juju storage --filesystem --format=yaml" seems particularly devoid of information that a human needs to know in order to manage that volume
<jam> current: detached
<jam> axw: sorry I'm bringing this up now, just trying to page it in if I'm going to be discussing it and it brought up things I hadn't thought of before
<axw> jam: there should be more than just "current: detached". that's just the status of the volume. but you're right that we do not show the *last* machine that it was attached to
<jam> axw: well last unit+store is probably the most useful
<jam> 'this is what the volume was being used for'
<axw> jam: that is not available in the model right now. we would need to add it in. might be a bit awkward...
<axw> status history would be straight forward, but won't show up in the listing
<jam> i think fundamentally 'name' is a useful approximation that also lets users set whatever they want, but I can't help but feel if we just do persistent-by-default
<jam> people are going to end up with a lot of volumes that are meaningless to them
<jam> sure they're still around
<jam> but which one is the critical db
<jam> and which ones were the throwaway disks that just didn't get thrown away
<jam> $ juju remove-application postgresql
<jam> Persistent filesystem â0â remains. You can use âjuju remove-filesystemâ to remove it.
<jam> axw: that is in the right direction, but that line only exists in the terminal for the time that you're looking at it, and then that information is lost.
<axw> jam: yep, good point
<jam> axw: so I think you and I need a round of talking about this before we bring it to mark. sorry I didn't get a chance to look deeply at it before.
<axw> jam: np
<wallyworld> axw: i'm off to soccer for a bit - can you see what needs doing to get fallback clouds in 2.1 up to date. you may need to pull in reed's gce changes from develop that landed recently and add to your PR. and then try and land and see if they've removed the block
<axw> wallyworld: ok
<wallyworld> tyvm
<frankban> hey wallyworld thanks for that branch! looking
<frankban> wallyworld: https://github.com/juju/juju/pull/6992 reviewed
<axw> jam: here's the LXD changes, if you have any time to review: https://github.com/juju/juju/pull/6994
<axw> wallyworld: still can't land clouds.yaml changes FYI. I backported the GCE changes, will come back to see if aaron is around later to find out what's the go
<jam> axw: thx, looking
<wallyworld> frankban: thanks for review, just got back from soccer, will start making the changes
<frankban> wallyworld: cool thanks
<wallyworld> i didn't reallu know what i was doing in that code :-)
<frankban> wallyworld: well, you did incredibly well then ;-)
<wallyworld> beginner's luck :-)
<wallyworld> i tested it a fair bit
<wallyworld> frankban: with the password comment - do you mean the output of $juju gui where it prints the login credential?
<wallyworld> i don't quite follow wht the issue is
<frankban> wallyworld: yes, after you "juju change-user-password" you'll see that the paswd is empty
<wallyworld> ok, i'll comeup with something
<axw> wallyworld: I'm thinking we could have "juju gui" generate a single-use, time-limited password, and encode it into the URL
<axw> wallyworld: but not for 2.1... too late now
<wallyworld> coukd do but i won't have time tonight
<frankban> axw: I think, on the long period, we'll want to support macaroon's based auth for that
<axw> frankban: how do you get the cookie from the CLI to the browser?
<jam> axw: reviewed lxd, overall lgtm
<wallyworld> axw: not sure of exact words to put when password is changed and the CLI uses macaroon based login. i don't think the gui even supports that yet
<wallyworld> ISTM that is you change password you can no longer access the gui
<frankban|afk> wallyworld: no, I do that all the time
<wallyworld> frankban|afk: I tried and it gui would not log me in at all
<frankban|afk> wallyworld: let me try your branch with the new changes
<axw> wallyworld: the only difference is that the password is not on disk any more. you should still be able to log into the GUI (I've also done it before) using the password you gave in change-user-password
<axw> jam: thanks
<wallyworld> axw: exactly. that's what i tried. i may have just mis remembered what i changed it to. but it was only 3 letters
<frankban> wallyworld: I just tried and I was able to log into the GUI, after changing the password, with your branch
<wallyworld> frankban: ok, maybe i'm just tired and mistyped :-)
<wallyworld> you happy for me to land it?
<wallyworld> i tested the old model uuid urls and they work now
<frankban> wallyworld: no, the base URL Juju is providing is now wrong: /gui/b5d3e307-41f5-4131-8f71-40a698c4c381
<frankban> wallyworld: that should be the one provided only if you manually visit the UUID url
<wallyworld> right. i may have made a mistake, let me retest
<frankban> wallyworld: maybe that's because the config file is still served by a URL including the uuid
<wallyworld> frankban: you talking about the "base" attribute of config.js? that should be correct
<wallyworld> yes. i keep serving static content from the model uui url
<wallyworld> and config.js
<frankban> wallyworld: it's not
<wallyworld> ok, let me check
<frankban> wallyworld: yes, config.js is still served with the uuid url, but it provides the wrong base
<wallyworld> ok, i'll run up a system and look again
<frankban> wallyworld: maybe because, even if the index path does not include the uuid, the config.js path always does, so when baseGUIURLPath is calculated it's always the old one, icluding the uuid?
<wallyworld> not sure, the TestGUIConfigNewURL unit test seems correct to me
<wallyworld> also the logic starting line 147 of apiserver/gui.go seems ok
<wallyworld> frankban: yeah, it seems to be getting confused, because of the url used to serve config.js rather than the url used for the gui itself
<frankban> wallyworld: yeah, one request for the index, and the one for the config is always a uuid path
<wallyworld> and it's the one for the config that is used to set the base attribute
<frankban> wallyworld: yes
<wallyworld> damn, will need to think of a fix
<wallyworld> but it's all stateless
<frankban> wallyworld: but the one for the index is used to set the configURL, so maybe the configURL can include a hint?
<wallyworld> maybe yeah
<frankban> wallyworld: like a query (?uuid=true) in case of old-style index
<wallyworld> i'll try
<wallyworld> frankban: i think it's god now, seems to test ok for me
<wallyworld> good
<frankban> wallyworld: trying again
<frankban> wallyworld: bootstrapping now
<wallyworld> ok
<wallyworld> frankban: hope it works cause it's after 1am and i'm tired
<frankban> wallyworld: yeah, I was wondering if you were a vampire
<wallyworld> i can be if you want me to be
<frankban> lol
<frankban> wallyworld: ok, new GUI new URL works well, with direct URL with uuid it works well, with the new GUI it's just wonderful
<frankban> wallyworld: the I downgraded to GUI 2.2.7
<wallyworld> uh oh
<frankban> wallyworld: I think we are hitting a pat bug there, after logging in the GUI acts weird and then it redirects to "/gui/:modeluuid/" (literally, not a placeholder)
<frankban> wallyworld: IIRC with pat all URLs must end with a /
<wallyworld> frankban: so it's just new controller, old gui that is abroken?
<frankban> wallyworld: yes, and therefore we could fix that in a follow up 2.1.1 probably
<wallyworld> sgtm. i will even fix tomorrow
<wallyworld> first up before release is cut
<frankban> wallyworld: also, with uuid URL old gui works
<frankban> wallyworld: so the only thing slightly broken is: old gui + new URL
<wallyworld> yeah ok, that will be an easy fix. that's the one thing i didn't test :-)
<wallyworld> you ok for me the $$merge$$ then?
<frankban> wallyworld: yes!
<wallyworld> and can you watch it for me in case it fails and try again?
<frankban> wallyworld: sure, thanks a lot!
<wallyworld> thanks for helping test etc
<wallyworld> i learnt a bit today
<wallyworld> 2.1 will be sweet with these new gui urls
<rick_h> wallyworld: is sinzui aware of ^ then for 2.1?
<wallyworld> not yet. the old urls still work
<sinzui> wallyworld: I sort of know...I read the commit
<sinzui> yes, the old urls do work
<wallyworld> rick_h: i sort of stumbled into this work not knowing what i was getting myself into :-) it started as a small fix to juju gui command and sort of grew as a result of a required text change that implied juju core was meant to serve different urls
<rick_h> wallyworld: like all good deeds :) punishment
<wallyworld> indeed
<perrito666> people I need to leave for about 1 to 2 hs, you can mail me if anything requires my attention
<tych0> hey guys. what branch do i make PRs against these days?
<alexisb> tych0, what are you working on?
<tych0> alexisb: we have a new storage API in LXD 2.9, i have some patches that handle it
<tych0> this will be zesty onward, and doesn't need to be backported to trusty
<alexisb> ok, tych0 start with devel
<tych0> sounds good
<tych0> is that "develop"?
<alexisb> you will want to sent a note to thumper and wallyworld to see if they want it in 2.1
<alexisb> yes sorry develop
<tych0> alexisb: cool, thanks!
<alexisb> you bet tych0
<perrito666> Alexisb tych0 i doubt they will want that in 2.1 a day before release
<anastasiamac> perrito666: thumper: making coffee and coming
<perrito666> anastasiamac: nice, bring me one
 * anastasiamac brings perrito666 vitual coffee
<axw> thumper wallyworld: seen https://github.com/juju/juju/pull/6996?
<thumper> axw: no, but in the middle of something
<axw> okey dokey
<frankban> hey wallyworld thanks for the fix
<wallyworld> frankban: no worries. it looks good. the only wrinkle is that you need to click on the canvas after log in. have you seen that?
<frankban> wallyworld: yes, I wonder why
<wallyworld> not sure, but i didn't see it as a blocker and it is a corner case
<wallyworld> we can do that for 2.1.1 if it really is an issue
<frankban> wallyworld: +1 it's not a great issue
<wallyworld> frankban: and will all that extra effort 2.1 release is delayed a few days :-/
<wallyworld> *with
<frankban> auch
<wallyworld> at least it is all fixed
<wallyworld> rc2 will be going out tomorrow
<wallyworld> or tonight
<frankban> ok
<wallyworld> the hosted juju beta is on 2.1rc1 as that is very stable
<wallyworld> staleholders wanted more 2.1 final testing before release
<frankban> wallyworld: yeah, cool. it will provide new-new GUI 2.4.0 then, for new bootstraps, we should release that tomorrow
<wallyworld> great
<frankban> well, today...
<wallyworld> today, tomorrow, timezones make that very murky :-)
#juju-dev 2017-02-17
<axw> wallyworld: gtg take kids to school, can you please babysit https://github.com/juju/juju/pull/6996 and let sinzui know if/when it's landed?
<wallyworld> axw: wil do, i'll also forward port to develop
<anastasiamac> PR 6996 and 6998 landed. wallyworld, thumper, menn0, axw, sinzui - rc2 is good to go, right?
<wallyworld> anastasiamac: yeah, i just let sinzui know in #juju
<wallyworld> one step pahead of you :-P
<menn0> nice
 * wallyworld merges 2.1 into develop
<anastasiamac> wallyworld: one step and probably many years :D
<wallyworld> :-( :-( :-(
<wallyworld> about 9 :-(
<anastasiamac> just keep "experienced" in mind
<anastasiamac> :D
<anastasiamac> and hey! I am still somewhere in my 20s \o/
<wallyworld> sinzui: wait
<wallyworld> looks like the merge was done into 2.2 branch
<wallyworld> let me check
<wallyworld> sinzui: yeah it was :-(
<wallyworld> i'll have to quickly backport
<axw> doh
<axw> wallyworld: sorry, didn't notice that
<wallyworld> axw: no worries, backporting now but lots of conflicts to sort out, i'll propose soon, just getting tests to pass
<wallyworld> axw: i have a failing test in tools/lxdclient. it may be due to the changed socket stuff? i've resolved all the conflicts, diff looks ok, local lxd provider test with IP4 is ok. you may know immediately what issue is? https://github.com/juju/juju/compare/2.1...wallyworld:backport-pr-6996?expand=1
 * axw looks
<axw> wallyworld: pastebin the failure?
<wallyworld> axw: http://pastebin.ubuntu.com/24010792/
<wallyworld> ipv6
<wallyworld> code looks ok to me at first glance
<wallyworld> there's a bit there in fixAddr to sort out IPv6
<axw> wallyworld: fixAddr isn't even used? :/
<axw> wallyworld: delete addserver*.go I think
<wallyworld> axw: huh, yeah, i think you're right
<wallyworld> hmmmm
<wallyworld> axw: doesn't appear used in develop branch either
<axw> wallyworld: chop it. I've never come across it before
<axw> hasn't been touched since 2015
<wallyworld> axw: https://github.com/juju/juju/pull/6999
<wallyworld> thumper: free for 1:1?
<thumper> yeha
<axw> wallyworld: LGTM, thanks
<wallyworld> yay
<wallyworld> axw: talking to tim so will be late for 1:1
<axw> wallyworld: np, ping when
<wallyworld> axw: free now
<axw> wallyworld: just a minute
<babbageclunk> thumper: easy review? https://github.com/juju/juju/pull/7000
 * thumper looks
<menn0> axw: i'm still looking but goswagger is looking like the best fit so far
<thumper> babbageclunk: code looks fine, but left a comment for you to check
<axw> menn0: it would be great if that can be made to work, it's pretty much the de facto standard now
<babbageclunk> thumper: thanks
<axw> menn0: are there any existing examples of mapping between RPC-style and REST-style with it?
<menn0> axw: for the existing rpc API I'm wondering about either generating it from the same swagger yaml or having an RPC to REST layer
<axw> menn0: not sure, I have no hands on experience
<babbageclunk> thumper: yeah, I tried that as well, it worked fine.
<thumper> ok, lgtm
<axw> menn0: somewhat related: https://github.com/OAI/OpenAPI-Specification/issues/523
<axw> menn0 babbageclunk: did either of you fix some proxy related bugs recently? anything that would affect bootstrap on lxd?
<menn0> axw: babbageclunk did make some proxy fixes recently. not sure how they would affect bootstrap though. what's happening?
<axw> menn0: https://bugs.launchpad.net/juju/+bug/1633788/comments/30
<mup> Bug #1633788: juju 2.0.0 bootstrap to lxd fails (connect to wrong "remote" IP address) <canonical-is> <juju> <lxd> <lxd-provider> <s390x> <uosci> <OpenStack Charm Test Infra:Confirmed for 1chb1n> <juju:Fix Released by axwalk> <https://launchpad.net/bugs/1633788>
<axw> menn0: 2017-02-16 12:00:56 ERROR cmd supercommand.go:458 new environ: Get https://10.87.204.1:8443/1.0: Service Unavailable
<axw> menn0: AFAICS, lxd won't return 503. so I'm thinking it's going through the proxy
<menn0> axw: I don't think the proxy settings would ever have been used during bootstrap b/c the proxyupdater worker doesn't run during bootstrap
<axw> I just tested, but now I realise I didn't set https_proxy, only http_proxy
<axw> hmm ok
<babbageclunk> it should use the http_proxy for https if there's no https_proxy set.
<babbageclunk> menn0: would the proxy settings be set in the env for jujud after bootstrap?
<axw> babbageclunk menn0: looks like we do set the proxy settings in cloud-init
<axw> babbageclunk menn0: so they would also affect the bootstrap command
<babbageclunk> axw: gah, that'll be it then.
<babbageclunk> axw: I think you could fix it by initialising juju/juju/utils/proxy.DefaultConfig utils.proxy.DetectProxies()
<babbageclunk> want me to do a diff for it?
<axw> babbageclunk: what will that do?
<babbageclunk> It will set the initial values of the proxy config to whatever's in the env vars.
<babbageclunk> axw: Then after that any changes can be made from the proxyupdater.
<axw> babbageclunk: that sounds sane I think
<axw> babbageclunk: if you would, that'd be good - thanks
<babbageclunk> axw: what should I do about an error from initialising a package variable? There's probably no logging available and panicking seems nasty.
<axw> babbageclunk: can we just do it in cmd/jujud/main.go, and error out if it fails?
<axw> babbageclunk: before we install the proxy thing into the default transport?
<babbageclunk> axw: yeah, sounds good
<babbageclunk> axw: I'll make the PR against 2.1
<babbageclunk> axw: https://github.com/juju/juju/pull/7002
<babbageclunk> axw: trying it out here
<babbageclunk> axw: Sorry I missed that - because the original problem was about cached env vars, my QA steps were "bootstrap without proxy set up, deploy something, set proxy, deploy something else"
<babbageclunk> axw: I should've thought to check bootstrapping with proxy
<axw> babbageclunk: all good
<babbageclunk> axw: also, menn0 misled me. :)
<axw> this is why we have RCs :)
<menn0> babbageclunk: wat?! :)
<babbageclunk> menn0: well, I should've checked anyway
<babbageclunk> axw: so should I ping sinzui so he knows that this should be included in the release?
<axw> babbageclunk: wouldn't hurt, I'm not sure if it's too late
<menn0> babbageclunk, axw: it just occurred to me that what might be confusing to people is that if they bootstrap with --config http_proxy=.... but with $http_proxy not set on the host machine, that proxy on the command line isn't going to get used
<menn0> I guess that's ok
<menn0> you don't necessary want the client doing the bootstrap to use the same proxy as the juju deployment
<axw> menn0: I think we need to support that case too. i.e. the client goes direct, but the env goes thru proxy
<axw> right
<sinzui>  babbageclunk change the proxy config after deploy and expect it to be honoured?
<babbageclunk> sinzui: oh hai
<babbageclunk> sinzui: wasn't expecting you to be up
<sinzui> I was just checking in on the possible last commit
<babbageclunk> sinzui: axw just pointed out a comment that showed my proxy fix didn't work with bootstrapping.
<babbageclunk> sinzui: the fix is building now
<babbageclunk> sinzui: is it too late?
<sinzui> babbageclunk: building as in not merged?
<axw> babbageclunk: it's not 100% clear that's the issue there, but it will be in other scenarios at least
<babbageclunk> axw: true
<babbageclunk> sinzui: yes
<babbageclunk> sinzui: https://github.com/juju/juju/pull/7002
<sinzui> babbageclunk: :/
<babbageclunk> sinzui: sorry :(
<sinzui> babbageclunk: not too late.
<sinzui> babbageclunk: The maas I was worked about is still up so I hope all eill be tested when I wake. I expect to need to reest a few bad substrates like a maas or azure
<babbageclunk> sinzui: it's landed on 2.1 now
<sinzui> thank you babbageclunk . I ma still reetting a maas so that you branch will pass first time
<sinzui> though I think I just worked out how the maas 1.9 is breaking. the squid might be omming
<babbageclunk> the squid might be nomming. On some Patagonian toothfish or something.
<wallyworld> babbageclunk: your latest PR just missed my forward port of 2.1 into develop
<babbageclunk> wallyworld: ok - I'll pull it forward into develop now
<babbageclunk> wallyworld: ping?
<wallyworld> babbageclunk: hey
<babbageclunk> wallyworld: sorry - was having trouble with a merge but I think I sorted it - magit was leading me astray.
<wallyworld> no worries, i was just at school pickup
<babbageclunk> get anything good?
<wallyworld> nope, just a surly 15 year old
<wallyworld> axw: lgtm on your pr
<axw> wallyworld: ta
<babbageclunk> wallyworld: actually, I'm still having trouble. How should I be doing the merge? My branch is reporting heaps of weird differences with develop.
<babbageclunk> wallyworld: https://github.com/juju/juju/compare/develop...babbageclunk:merge-proxy-fix?expand=1
<wallyworld> i'd use cheery pick
<wallyworld> git cherrypick -m 1 <sha>
<wallyworld> merge will give you grief
<babbageclunk> wallyworld: ah, ok - that's how I'd normally do it, but I thought jam preferred using a merge
<babbageclunk> wallyworld: that it is
<wallyworld> yeah, i merged 2.1 this morning and it was ok
<babbageclunk> wallyworld: ok, cherry picking I can do
<wallyworld> for a single commit i tend to cheery pick
<wallyworld> but that's just me
<perrito666> morning
<alexisb_> morning perrito666
<perrito666> alexisb_: morning
<jam> babbageclunk: so you can cherry pick, but that makes future merges harder
<jam> as long as it is 2.1 => develop, I wouldn't try develop => 2.1
<babbageclunk> sorry jam, sounds like I just contributed to the problem again then. Next time I need to do it I'll try to pick your brains. It sounds like I should have just accepted the differences it was reporting?
<perrito666> I believe EOD/EOW reached me, I am really tired
<perrito666> cheers all
#juju-dev 2017-02-19
<junaidali> Hi jam , will the fix for this bug https://bugs.launchpad.net/juju/+bug/1646329 land in 2.0.X?
<mup> Bug #1646329: juju ssh/scp proxy ip address selection oddities <landscape> <juju:Fix Released by jameinel> <https://launchpad.net/bugs/1646329>
<jam> junaidali: I believe at this point there aren't plans to release another 2.0.x after 2.0.3, so I don't think it will.
<junaidali> thanks jam , any idea when will stable 2.1 be released?
<jam> junaidali: rc2 was last week. I think final is supposed to be Wed
<junaidali> thanks jam :)
<mup> Bug #1666069 opened: openstack provider: juju does not give any error if trusty instance forever in pending because of missing image metadata <juju-core:New> <https://launchpad.net/bugs/1666069>
<mup> Bug #1666069 changed: openstack provider: juju does not give any error if trusty instance forever in pending because of missing image metadata <juju-core:New> <https://launchpad.net/bugs/1666069>
<mup> Bug #1666069 opened: openstack provider: juju does not give any error if trusty instance forever in pending because of missing image metadata <juju-core:New> <https://launchpad.net/bugs/1666069>
<axw> wallyworld: sticking with existing standup time today?
<wallyworld> axw: yeah, i thought it best to not change the very first one
<babbageclunk> thumper: When running transactions in state, can we sometimes see the txn get partially applied before getting killed with an ErrAborted?
<babbageclunk> thumper: I'm seeing a situation (in a test) where we try running the txn with 15 ops, which fails with ErrAborted, then the second attempt has only 3 ops and succeeds. Seems weird?
<wallyworld> thumper: we miss you
#juju-dev 2018-02-12
<thumper> babbageclunk: ping
<babbageclunk> thumper: hey
<thumper> babbageclunk: got a few mintues to chat?
<babbageclunk> yup yup
<babbageclunk> 1:1?
<thumper> wallyworld: can you comment on https://bugs.launchpad.net/juju/+bug/1724210 ?
<mup> Bug #1724210: juju 2 controller clings to deleted image, won't check stream for correct ones <canonical-is> <juju:Triaged by wallyworld> <https://launchpad.net/bugs/1724210>
<wallyworld> yeah, saw that, on my todo list to look
<thumper> thanks
<wallyworld> hml: and this one just came in https://bugs.launchpad.net/bugs/1748275
<mup> Bug #1748275: Juju HA fails due to demotion of Machine 0 <cdo-qa> <cdo-qa-blocker> <cpe-onsite> <foundations-engine> <juju:New> <https://launchpad.net/bugs/1748275>
<thumper> that is a weird one
<hml> interesting
<thumper> just been maked critical sla
<thumper> which means we need to have someone assigned to it
<thumper> and working on it until it is resolved
<thumper> volunteers?
<thumper> first analysis would be around how it determins demotion
<thumper> as clearly it is getting that wrong
<thumper> hml:  interested?
<hml> thumper: iâll take a look
<wallyworld> hml: i have a hand wavy theory - see my comments in #juju
<anastasiamac> thumper: wallyworld: ptal https://github.com/juju/juju/pull/8358 - it's ready to land i *believe* :)
<wallyworld> anastasiamac: lgtm, ty
<anastasiamac> wallyworld: \o/
#juju-dev 2018-02-13
<anastasiamac> thumper, wallyworld: message clarity around creds mngmt, part 1 -https://github.com/juju/juju/pull/8363 :D PTAL \o/
<wallyworld> anastasiamac: lgtm, yeah credential mgmt is confusing for people
<anastasiamac> wallyworld: ta \o/
<anastasiamac> wallyworld: as discussed, PR that filters out cloud cred tag from modelinfo unles u r model admin PTAL? https://github.com/juju/juju/pull/8364
<wallyworld> anastasiamac: sorry, was interviewing, lgtm
<anastasiamac> jam: u and guild recently worked on upgrading mongo to 3.4(I guess .7 coz this is what m seeing)... m running featuretests on develop and m getting https://pastebin.ubuntu.com/p/FJHJx6RjVD/ ... after that all subsequent tests in the suite understandably panic... any idea wot's up?
<jam> anastasiamac: it looks like our work on testing 3.4 was incomplete. I think it was a case of "we fixed the ones we knew about" but nobody kept running the suite against them (eric was running the suite, I was fixing). Anyway, I'll debug for a bit
<anastasiamac> jam: sounds great! thnx! m a bit surprised that this featuretests package is not run as part of landing/CI since it's our basic sanity check that layers are glued correctly - from cmd to api to state
<jam> anastasiamac: are you sure it isn't run? where did you get 3.4.7 from? Is it just that you're running Bionic?
<jam> I'm pretty sure the bot isn't testing 3.4
<anastasiamac> jam: m running develop tests locally on my machine after doing a pull and dependencies re-run couple of hrs ago
<jam> anastasiamac: sure. my point is that the bot could very well be running featuretests, just they don't fail with mongo 3.2 which is the one available on !bionic
<anastasiamac> jam: u have no problems running featuretests on ur machine?
<anastasiamac> ah
<jam> testing now
<anastasiamac> mayb it should then? since u r landing this code?... would b nice to have a stable development env, at least on  my machine... ;)
<jam> (seeing if I can reproduce with a 3.4.X of mongo)
<anastasiamac> thnx
<jam> anastasiamac: dblogtest passes even with a mongod that should be 3.4.12, will keep trying to see if I can reproduce
<anastasiamac> jam: it's debugLogDbSuite that fails
<jam> anastasiamac: sure, but the entire dblog_test.go file just passed, still investigating
<anastasiamac> jam: right, m running all tests in that directory, not isolated to a file... so maybe try 'go test -gocheck.v' within the directory?
<jam> anastasiamac: I'm doing exactly that
<jam> anastasiamac: does it fail every time for you?
<jam> or just once in a while
<anastasiamac> every time
<anastasiamac> jam: juts out of curiosity.. which go r u runing?
<jam> go test --check.v passed completely for featuretest for me.
<jam> go 1.9.4 from snap
<jam> on Xenial
<jam> and I'm grabbing the builds from Mongodb themselves, vs the bionic package, so its possible its a bionic thing. Though the error doesn't look specific to how it would be built
<jam> ah, its cause we're preferring /usr/lib/juju/bin
<jam> anastasiamac: you *can* just do "apt install juju-mongodb3.2" if you want to work around this
<jam> anastasiamac: so setting JUJU_MONGOD= to the correct 3.4 path did see the same failure you're seeing.
<anastasiamac> jam: I would prefer not to *work* around this :) i'd rather this was fixed :)
<anastasiamac> jam: m going to comment out this test (and others if any) locally to keep going... but we should address it, I *think*
<anastasiamac> jam: thnx for confirming m not just seeing things \o/
<jam> anastasiamac: so, we absolutely need to support mongo 3.4. I'm just saying that if this is the failure, it isn't just this test.
<jam> anastasiamac: if you want a working environment, I'd recommend installing 3.2 which is what the bot is using
<jam> until we finish supporting 3.4
<anastasiamac> jam: we r in violent agreement then
<anastasiamac> thnx
<jam> anastasiamac: given your recent changes to skip dying models, I'm guessing bug #1742699 should be fixed? it was causing CI fails from time to time
<mup> Bug #1742699: juju show-status fails during teardown <ci> <juju:Triaged> <https://launchpad.net/bugs/1742699>
<jam> anastasiamac: so it seems that test does something nasty and resets how we're running the mongo db server, which then stays in that state for the rest of the tests...
<jam> hm. theoretically not, as in TearDown it resets it, but I think the failure is probably that TearDown is broken because of the compat failure, and then it never runs the cleanup step
<anastasiamac> jam: yes for the bug and ur theory on teardown seems to fit the symptoms...
<jam> anastasiamac: https://github.com/juju/testing/pull/135/files
<jam> its a change to the testing package, but seems to fix things here. can you test?
<jam> anastasiamac: if it works for you, I'll propose an update to 2.3 based on it
<anastasiamac> jam: the code looks good but i'll have to take it for the test run in part 2 of my day
<jam> anastasiamac: you can just do "go test --check.v --check.f debugLogDb" to just test the one that was failing
<thumper> ugh...
<thumper> brain has stopped working
<thumper> yay slides...
<thumper> that said, I'm increasingly happy with the content
<thumper> laters peeps
<jam> anyone care for a very small code review: https://github.com/juju/juju/pull/8368
<jam> anastasiamac: ^^ that brings in the patch to Juju itself
<jam> manadart: externalreality ^^
<manadart> jam: I can look.
<jam> balloons: I have a PR that has been in "$$merge$$" for 2 hrs with no comment from the bot
<jam> https://github.com/juju/juju/pull/8368
<wpk> jam: second time is a charm apparently
<jam> wpk: its also possible the bot has decided it doesn't like me for some reason
<jam> wpk: thanks
<mup> Bug #1749272 opened: Adding existing subnets to space fails <juju-core:New> <https://launchpad.net/bugs/1749272>
<thumper> morning team
<wpk> evening boss
<thumper> wpk: oh hai
<thumper> wpk: still hanging around?
<wpk> thumper: for a moment but yes
<wpk> thumper: final mailcheck
<thumper> all good, we can chat another tiem
<babbageclunk> thumper: with manifold output funcs, can we assume that they won't be called before start returns?
<wpk> thumper: if that's something light and not requiring lots of thinking then I'm open
<thumper> wpk: nah, we're all good at the moment, been on calls, so very async
#juju-dev 2018-02-14
<thumper> wallyworld, babbageclunk: I have a question around upgrade-juju
<thumper> I thought 'juju upgrade-juju --dry-run' would tell you what it would do
<thumper> is that not right?
<babbageclunk> thumper: otp (standup) - it should do, I think?
<thumper> except in the situation where I'm using a build pre-release?
<thumper> it says it would upgrade to 2.3.2
<thumper> but I think it'll do 2.3.3.1
<babbageclunk> thumper: have you specified --build-agent?
<thumper> no
<thumper> huh, this is different than it used to be
<thumper> wallyworld, babbageclunk: I have a stop the line bug for the release...
<thumper> the upgrade failed from 2.2.9
<thumper> interestingly it failed upgrading to 2.3.2
<babbageclunk> :(
<thumper> I'd like some rubberducks
<thumper> if you can jump in the release call, that'd be swell
<babbageclunk> yup yup
<babbageclunk> wallyworld: approved
<anastasiamac> wallyworld: model cred in show-model and models output, PTAL https://github.com/juju/juju/pull/8372
<anastasiamac> wallyworld: also, i *think* that htis is resolved now?... https://bugs.launchpad.net/juju/+bug/1680523
<mup> Bug #1680523: add-credential azure fails <juju:Triaged> <https://launchpad.net/bugs/1680523>
<kerem> Hi All,
<thumper> o/ kerem
<kerem> Hi Tim,
<kerem> can you help me ?
<kerem> I have a problem with juju
<jam> whats up kerem?
<kerem> Hey !
<kerem> Is there anybody there?
<jam> We're here, but you don't seem to be asking any questions yet
<kerem> Hi Jam
<kerem> We are trying to install Openstack using Juju (2.3.2) and MAAS (2.3). When we try to load the application via Juju, we get a random rope. for example when I want to work with 10.0.0.0/24 it uses the overlay (tenant) which is 192.168.1.0/24.  Q: How do I provide interface or ip assignments when distributing over the Juju? The same is true for LXD.
<kerem> https://bugs.launchpad.net/juju/+bug/1616098
<mup> Bug #1616098: Juju 2.0 uses random IP for 'PUBLIC-ADDRESS' with MAAS 2.0 <4010> <cpec> <juju:Fix Released by dimitern> <https://launchpad.net/bugs/1616098>
<kerem> same problem
<jam> kerem: so likely Juju knows about both addresses. And you can see those if you do "juju show-machine X". Its a bit arbitrary which address we pick to show in status, since we only have 1 value.
<jam> kerem: is there an actual problem that you have for the application running, or is it just that 'status' is showing you an address you don't like?
<kerem> I created 5 space and subnet
<kerem> I want to use management-space in node setup, fkaat is using provider-space or ceph-cluster-space
<kerem> My goal is that the physical server and the Lxd servers are in the same space.
<kerem> When I try to deploy, the physical server gives me an ip address I do not want.
<jam> kerem: so are you specifying those as bindings in the bundle?
<jam> bindings:
<jam> kerem: if you deploy the charm directly, you can do "juju deploy fkaat --bind provider-space" for example
<kerem> yes
<jam> or in the bundle definition it would be
<jam> bindings:
<jam>  "": provider-space
<jam> (you can bind endpoints separately, but for now, I'm assuming you want them all to use the same binding for a given application)
<kerem> I could not tell
<kerem> sorry
<jam> kerem: I'm assuming you're deploying from a bundle, can you share that bundle? say via pastebin.ubuntu.com ?
<kerem> No, I have not yet.
<kerem> Because I can not get it like I want.
<kerem> https://bugs.launchpad.net/juju/+bug/1616098
<mup> Bug #1616098: Juju 2.0 uses random IP for 'PUBLIC-ADDRESS' with MAAS 2.0 <4010> <cpec> <juju:Fix Released by dimitern> <https://launchpad.net/bugs/1616098>
<kerem> This same problem
<kerem> my management ip 10.50.10.81
<kerem> my storage ip 10.1.3.81
<kerem> on a node1
<kerem> deployment start "juju deploy nova-comupte --bind management-space" is it true?
<jam> kerem: something like that, but it depends what the actual spaces are and how you want the applications to be configured.
<thumper> babbageclunk: ping
<babbageclunk> thumper: pong
<thumper> babbageclunk: can you be a rubber duck again?
<babbageclunk> yup - give me 2 mins? Just making a OR
<babbageclunk> PR
<thumper> sure, just join the release HO when you are ready
<hml> PR review please?  https://github.com/juju/juju/pull/8379
<babbageclunk> hml: looking
<hml> babbageclunk: ty
<babbageclunk> hml: approved
<hml> babbageclunk: :-)
#juju-dev 2018-02-15
<hml> babbageclunk: i updated the tests based on the merge build failuresâ¦ do you want to take another look before i squash the commits?  :-D
<babbageclunk> hml: sure
<hml> babbageclunk: youâre awesome!
<babbageclunk> hml: Still looks good to me!
<hml> babbageclunk: ty
<babbageclunk> wallyworld: I'm looking at your PR now - can you look at mine? :) https://github.com/juju/juju/pull/8380
<wallyworld> sure, after tim meeting
<babbageclunk> wallyworld: oh, looks like hml beat me to it - do I still need to look at it too?
<wallyworld> babbageclunk: looks like some fixes were asked for so i'll do those and then ping
<wallyworld> lunch first
<babbageclunk> okies
<babbageclunk> bon appetit!
 * babbageclunk feels bad for momentarily forgetting how to type a Ã©
<babbageclunk> *an
<blahdeblah> Ã©
<blahdeblah> ^ like that
<babbageclunk> You just cut'n'pasted my one though, be honest!
<blahdeblah> babbageclunk: compose, ', e
 * babbageclunk is chastened
<blahdeblah> Ã¡ Ã© Ã­ Ã³ Ãº
<blahdeblah> :-P
<babbageclunk> â
<blahdeblah> Apparently, áº Å Ã½ á¹ Å Çµ á¸± Äº ÅºÂ Ä Å á¸¿ all work, too
<babbageclunk> probably useful in wpk-land.
<blahdeblah> possibly - I never realised non-vowels could have accents
<mup> Bug #1749763 opened: remove an application not in bundle should be ignored <juju-core:New> <https://launchpad.net/bugs/1749763>
<wpk> Could someone look at https://github.com/juju/juju/pull/8375 (and at #1 comment in bugreport, as it gives the background) and state if that solution makes sense to them? (it works)
<wallyworld> wpk: i think i agree with roger's comment
<wallyworld> hml: did we need to make a fix to the update series tool to fix the symlink?
<wpk> wallyworld: refresh
<hml> wallyworld: right now itâd be part of the update series how to guide in the docs
<wpk> wallyworld: I forgot to remove it.
<hml> wallyworld: trying to understand if there way a changeâ¦ and if thatâs the only gotcha
<hml> wallyworld: donât remember having to do that at all before
<wpk> wallyworld: the big change is in MongoInfo actually
<wallyworld> hml: ok. i do think we need a fix to the tool ultimately. good that we have a workaround for now. i am surprised we didn't hit the issue before given that agent symlink is tied to series
<hml> wallyworld: thatâs whatâs bugging me
<wallyworld> wpk: the "isController" flag - that means is the connection for *this* controller or *any* controller? I assume *this* controller?
<wpk> wallyworld: isController flag means that we're a controller, and then - as a controller we should connect to self only.
<wallyworld> wpk: makes sense. could you expand the comment a little to make it very clear and that we are deliberately only returning api info with local host for that reason
<wpk> wallyworld: and the MongoInfo stuff? That's a 'hack' (as it assumes that mongos are on the same IPs as controllers).
<wallyworld> still digesting that bit, reading bug
<wallyworld> wpk: so with the patch we try local mongo first but will fail over to connect to a mongo on a different controller if needed. but i'm not sure that we shouldn't just be waiting until out own mongo becomes available. ie controller and mongo tied together. if mongo not available on a controller yet, wait for it. maybe need a second opinion
<wpk> wallyworld: "waiting until out own mongo becomes available" <- that could never happen (see my comment on the bug)
<wallyworld> right, we have a problem. but maybe the solution lies elsewhere. i'm not sure we're fixing the correct root cause. i am not sure it makes sense for a controller to talk to anything other than it's own mongo. but i may be wrong. i'd like to see what john thinks
<wallyworld> it's not super critical to land this right away as 2.3.3 has gone out
<wpk> wallyworld: we've had a discussion today and that was one of the proposals
<wallyworld> oh, i see. john was happy with the approach taken?
<thumper> anyone.. https://github.com/juju/juju/pull/8388
<wpk> wallyworld: (and the controller talks to mongo master, not only own mongo - it just has to know where the other mongos are and we're giving only localhost, then mongo itself tells about all other peers)
<wallyworld> wpk: i guess it will be temporary and will correct itself and then the controller will stil use local host
<thumper> wpk: this may be what jam and I discussed the other day
<wpk> wallyworld: the other approach would be to limit connections to localhost only after the controller is really a controller (hasVote)
<wallyworld> right, i would have maybe preferred that but if john is happy
<wpk> I'm gathering opinions :)
<wallyworld> i am just wary about hw doign this current approach may affect HA
<wpk> Democracy and stuff
<wallyworld> i am not an expert here, just have an opinion
<thumper> wpk: I don't agree with wallyworld and roger
<thumper> just saying
<thumper> wpk: if we are going to filter differently based on controller or not controller
<thumper> I'd rather do that in the connection space, rather than the writing config space
<thumper> we need a filter either way
<thumper> and I'd rather it was closer to the connect
<wallyworld> thumper: my point was that i disagree with the implicit assumption that localhost was always first
<wpk> thumper: My first approach was the way Roger wanted (in config space), but it didn't worked so I moved it to connect code, it worked, but then I realized I have a race and it's just random
<wallyworld> unless that is made very clear that's part of the contract
<wpk> thumper: So here I agree with Roger and Ian
<thumper> I was talking about api connect
<thumper> are you talking about mongo connect?
<wpk> API
<wpk> mongo is a separate thing, that came out of comment/1 on this bug.
<thumper> I like what we have, where we explicitly say []string{localAPIAddr}
<thumper> and just that
<thumper> don't assume localhost first
<thumper> wpk: how did it work before?
<thumper> wpk: if we only ever returned localhost before, how did HA work?
<wpk> thumper: we returned localhost and all other addresses
<wpk> thumper: (localhost first)
<thumper> not in the MongoInfo function on the left
<wpk> thumper: but connecting to other addresses during upgrade caused problems (that we've never reproduced, but we had consistent reports of them)
<wpk> thumper: ah, for Mongo it worked because apicaller could connect to other controllers
<thumper> I'm not sure we are talking about the same thing
<thumper> ah...
<wpk> thumper: and then machiner started, reported to other controller that this machine is alive, the other controller told mongo to connect 'this' mongo to replicaset
<thumper> If we put localhost at the start of the Mongo info, does it happen to choose that first?
<wpk> thumper: that's what in the code, but then it'll connect to master eventually
<thumper> that happens at the driver level right?
<wpk> thumper: even if we set MongoInfo to 'localhost' only it'll connect to master as it'll get it from local mongo, so it's not 'info', it's just 'seed'
 * thumper nods
<thumper> wpk: I'm adding a comment
<thumper> wpk: actually, no comment, this makes sense to me now
<wpk> OK, I'll fix the tests tomorrow and ask for acceptance.
<anastasiamac> thumper: babbageclunk: team meet?..
#juju-dev 2018-02-16
<axw> ICYMI: https://www.mongodb.com/blog/post/multi-document-transactions-in-mongodb :)
#juju-dev 2018-02-17
<jam> wpk: I'd rather we connect to any mongo, because in actuality the mgo driver is doing *exactly* that. With the caveat that we should be tracking some sort of "state addresses" rather than assuming api addresses - port + state port == state addresses.
<wpk> jam: If we'd be tracking state in state - that'd be awesome. But until then - I think that's good-enough hack
<wpk> jam: btw, one of the problems I've had with openstack was that it was reporting two of the same subnets (rfc1918 ones)
<wpk> jam: I have a 'hack' for now (ignore if exists) but it has to be solved for this to be working properly...
<jam> wpk: if I read the code correctly, we support specifying a network to use in Openstack. If we do, then the ListSubnets work should be restricting it to only that network
<wpk> jam: not if using GBP
#juju-dev 2018-02-18
<jam> wpk: well, to start with, I have the feeling we don't limit it anywhere. I'm saying that we probably *should*
