[00:04]  * thumper needs to reply to the api thread to agree with wallyworld_
[00:04]  * wallyworld_ wants to talk surrogate ids with thumper
[00:04] <thumper> wallyworld_: what about them?
[00:05]  * thumper feels like he needs something else...
[00:05] <thumper> just finished some ham, cheese and pineapple toasties
[00:05] <thumper> perhaps another coffee
[00:05] <wallyworld_> i think we can add a natural key to a machine without needed a schema change, but i could be wrong
[00:05] <wallyworld_> there's always time for another coffee
[00:16]  * thumper goes to make that coffee
[00:23] <thumper> hi davecheney
[00:54] <wallyworld_> thumper: hangout time?
[00:54] <thumper> wallyworld_: sure
[00:55] <thumper> wallyworld_: you create
[00:55] <wallyworld_> https://plus.google.com/hangouts/_/d3f48db1cccf0d24b0573a02f3a46f709af109a6
[01:08] <bigjools> today is going to need more coffee and more painkillers
[04:30] <dimitern> morning
[05:50] <wallyworld> davecheney: i don't type any import lines - my IDE does it all automatically :-D
[05:58] <wallyworld> davecheney: so you want all "jujuerrors" import aliases to go away and "errors" aliased to "stderrors" where there are conflicts? not just in the one place you made a comment
[05:59] <davecheney> wallyworld: i think there was only one place where we import both errors and jujuerrors
[05:59] <davecheney> sort of like the way we do with testing and jujutesting
[05:59] <davecheney> testing => stdtesting
[05:59] <wallyworld> there were several in my branch
[05:59] <davecheney> juju-core/testing => testing
[06:00] <wallyworld> ok, i'll fix them all
[06:00] <wallyworld> all of mine i mean
[06:00] <davecheney> cool
[06:00] <wallyworld> thanks for pointing it out
[06:00] <wallyworld> i wasn't sure what the conventoon was
[06:00] <wallyworld> convention even
[06:00] <davecheney> maybe you get to be the trend setter this time
[06:00] <davecheney> at least it's consistent
[06:00] <dimitern> wallyworld: and instead of jujuerrors, you can use coreerrors
[06:01]  * davecheney doesn't care about the color of the bike shed, only that it has a traditional number of walls
[06:01] <wallyworld> i won't need that though if i alias errors to stderrors
[06:01] <dimitern> wallyworld: like coretesting, etc.
[06:01] <dimitern> wallyworld: if you need to
[06:01] <wallyworld> do we want to stick with coretesting?
[06:02] <davecheney> i dont
[06:02] <dimitern> yes we do
[06:02] <wallyworld> me either since it's inconsistent with stdblah
[06:02] <wallyworld> we need *one* pattern
[06:02] <wallyworld> i don't mind which
[06:02] <dimitern> any day i'll prefer a standard convention throuout the code than a new one
[06:03] <davecheney> dimitern: this isn't a new one
[06:03] <wallyworld> depends on what Go best practice is thpough
[06:03] <wallyworld> if best practice is stdfoo, then we should use that
[06:03] <wallyworld> i'm deferring to davecheney here :-)
[06:03] <davecheney> wallyworld: i don't htink the std library can help here
[06:03] <dimitern> i mean if we tend to name core packages, when an import conflict will happen, "core"+package, let's do that
[06:03] <davecheney> we're in uncharted territory
[06:03] <davecheney> but we do have a pattern of importing the std lib's testing as stdtesting
[06:04] <dimitern> yeah, exactly
[06:04] <wallyworld> so: do we alias the core packages to corefoo, or the std lib packages to stdbar. we need to choose one or the other
[06:04] <davecheney> so ithink what wallyworld and I are saying is, lets keep doing that
[06:04] <dimitern> wallyworld: i don't mind which one - there are examples of both
[06:05] <davecheney> as an asside, if we were so arrogant as to give one of our pacakges the same name as a package that already exists in the standard library, we should change out packages' name
[06:05] <dimitern> wallyworld: but i do mind inventing a yet another prefix scheme
[06:05] <wallyworld> the bike shed should all purple or all red, not red and purple :-)
[06:05] <wallyworld> dimitern: sure, using "juju" was wrong, i didn't realise we used "core"
[06:05] <dimitern> wallyworld: that's all i meant, thanks
[06:06] <davecheney> holy fuckj
[06:06] <davecheney> just submit the thing
[06:06] <wallyworld> np, i knew what you meant :-)
[06:06] <davecheney> the person that cares _that_ much about naming thigns can do a followup
[06:06] <wallyworld> i don't mind this discussion, really! i'd like to get it right rather than propagating more inconsistency into the code base
[06:07] <dimitern> at the moment i mostly care for us to come to an agreement what are we doing with  the api
[06:07] <dimitern> 3 days of discussion now and no single solution at the horizon, we're waisting time
[06:07] <davecheney> dimitern: you must be new here
[06:07] <dimitern> davecheney: :D
[06:07] <mramm> is there a notes doc for today's meeting yet?
[06:07] <wallyworld> davecheney: with the "arrogant" thing - if a package has a really generic name like "errors", its hard to avoid a clash
[06:08] <jam> dimitern, wallyworld, mramm: I'm probably going to miss the juju-core meeting. I'll see if I can get back in time, but today is "show your stuff to your parents day at school".
[06:08] <jam> It is done right when the meeting starts.
[06:08] <mramm> jam: no problem
[06:08] <wallyworld> oooh good - what's on display?
[06:09] <jam> dimitern: I didn't feel your email actually had a "should I do it X or Y". or at least, the question wasn't very clearly stated.
[06:09] <davecheney> mramm: it's the same doc as always
[06:09] <davecheney> danios wanted to keep it all one one document from now on
[06:09] <mramm> ahh, right
[06:09] <jam> wallyworld: well, it is KG2, so some crudely drawn paintings that all of us parents will surely fawn over
[06:09] <dimitern> wallyworld: we can introduce a cuning schema of replacing package names with base64(name) or rot13, so such clashes with std packages are avoided }:>
[06:09] <wallyworld> lol
[06:09] <mramm> jam: got time for a quick sync up before you leave?
[06:09] <wallyworld> rotflmao
[06:09] <jam> mramm: It doesn't hurt to resend it to canonical-juju to remind us all about it. Though as it is a private doc we have been suggested to only send it to the private list.
[06:10] <jam> mramm: unfortunately, I have to head out the door now.
[06:10] <davecheney> wallyworld: fair point, but that doesn't mean if we start a juju-core/utils/math package, we have more right to the name "math"
[06:10] <mramm> jam: no problem
[06:10] <mramm> jam: have fun!
[06:10] <jam> mramm: what are you even doing awake?
[06:10] <jam> :)
[06:10] <mramm> I am trying out staying up until the meting
[06:10] <wallyworld> davecheney: agreed! we just need a convention for dealing with it - i think i prefer stdfoo
[06:10] <davecheney> wallyworld: seconded
[06:10] <davecheney> they I's have it
[06:10] <mramm> ... see if I am more awake that way than getting up in the middle of the night...
[06:11] <wallyworld> \o/
[06:11] <dimitern> guys, i'll apreciate your input on the mail i sent yesterday - API Bulk Operations
[06:11]  * davecheney is super testy because he suspects the mongo retry behviour is part of what is making the tests unreliable with the .deb mongo
[06:12] <davecheney> in fact, i'm going to rip the retry shit out and see if that helps
[06:12] <wallyworld> dimitern: sorry about the delay. will look after i pick up my kid from viola soon
[06:12] <wallyworld> davecheney: if you fix the tests you will be my hero
[06:13] <dimitern> wallyworld: cheers
[06:13]  * wallyworld goes to get kid from school
[06:43] <davecheney> https://codereview.appspot.com/9857046/
[06:43] <dimitern> davecheney: on it
[06:45] <dimitern> davecheney: reviewed; how come nobody encountered an issue with that?
[06:49] <davecheney> dimitern: they probably did
[06:49] <davecheney> but didn't realise it
[06:50] <dimitern> davecheney: i'd like to see a test showing the issue before and after the change, if possible
[06:51] <davecheney> dimitern: run the race detector on the cmd/jujud package
[06:51] <dimitern> davecheney: ah, ok, thanks
[06:51] <davecheney> that is how i found it :)
[07:26] <dimitern> davecheney: where's the agenda for today's meeting?
[07:58] <davecheney> dimitern: same as last week
[07:58] <davecheney> remember danilos asked to have it all on one page
[10:09]  * dimitern lunch
[10:09] <wallyworld> fwereade: you now ok with https://codereview.appspot.com/9662048/ ?
[11:02]  * TheMue => lunchtime
[11:36] <wallyworld> dimitern: since you asked :-) https://codereview.appspot.com/9666050/
[11:36] <dimitern> best standup ever!
[11:36] <danilos> :)
[11:36] <wallyworld> jam: oh, so sorry, you missed the standup :-P
[11:42] <dimitern> wallyworld: reviewed
[11:42] <wallyworld> thank you
[12:13] <fwereade> wallyworld, sorry, I'll make sure your reviews are ready for your morning
[12:14] <wallyworld> fwereade: np. i've yet to do any more coding on the drity flag or assignment ploicy ones
[12:14] <fwereade> wallyworld, tentative yes on that one but let me check; I'll need to do a spot more thinking on the assignment policy though
[12:15] <wallyworld> fwereade: with the assignment policy - i'll remove the code which provides the default constraint value in env till we work out how to do it consistently for all constraints
[12:16] <wallyworld> fwereade: with the dirty flag, i'm switching it to "clean" so the semantics are backwards compatible with existing schemas
[12:19] <fwereade> wallyworld, ok, so new machines start with "clean" set and old ones are assumed dirty? sgtm
[12:20] <wallyworld> fwereade: that's the plan. sort of like a failsafe - assume dirty unless told otherwise
[12:21] <wallyworld> i had intended to do it that way originally but got talked out of it :-)
[12:21] <fwereade> wallyworld, heh, annoying, sorry about that
[12:21] <wallyworld> not your fault!
[12:21] <fwereade> wallyworld, I still ned to think about assignment policy, there's something knocking at my mind but I'm not sure what ;)
[12:22] <fwereade> wallyworld, I'm just expressing regret, not taking responsibility ;p
[12:23] <wallyworld> fwereade: the end game is to use a constraint, not to hard code on each provider. i think that bit is ok. bt we need to decide how to specify any default value if the user doesn't specify a policy
[12:23] <wallyworld> i added an env setting for this. but am happy to hard code until we decide how to do constraint default values
[12:23] <fwereade> wallyworld, yeah, agreed; I wish that state could have a concept of an actual environ other than via a config
[12:24] <wallyworld> juju config seems "interesting" and complex to me
[12:25] <fwereade> wallyworld, I'd be most comfortable if we stuck with that rather than taking a "temporary" step in an unhelpful direction... for example, we *could* have the env inject it into the bootstrap constraints if not already set
[12:25] <fwereade> wallyworld, don't even start :/
[12:26] <fwereade> wallyworld, it's trying to be too many things
[12:26] <wallyworld> yeah. i don't prefess to *fully* understanding the design rationale
[12:26] <fwereade> wallyworld, and I'm terrified of the "worse" phase in "it'll get worse before it gets better"
[12:26] <wallyworld> indeed
[12:27] <fwereade> hey ho
[12:27] <fwereade> ok, I am feeling somewhat crappy, I'm going to have a bit more of a rest in the hope of becoming coherent for a chunk of the rest of the afternoon
[12:27] <fwereade> ttyl guys
[12:28] <wallyworld> have a drink! i've imbibed a few already :-)
[13:32] <teknico> marcoceppi: hi, you around?
[13:32] <marcoceppi> teknico: I am!
[13:33] <teknico> marcoceppi: could you please have a look at https://bugs.launchpad.net/juju-plugins/+bug/1185820 ?
[13:35] <marcoceppi> teknico: branch I can run juju-test against?
[13:38] <teknico> marcoceppi: https://code.launchpad.net/~juju-gui/charms/precise/juju-gui/trunk , revno 59
[13:39] <marcoceppi> teknico: thanks, it looks like some discrepencies between what jitsu was doing and what the new plugin does. Based on feedback from others it now executes everythin in the tests/ directory, not just .test files. Which is why your utils.py files are even being considered for tests
[13:39]  * marcoceppi pokes somemore to figure out the other issues
[13:41] <teknico> marcoceppi: thank you
[13:42] <marcoceppi> teknico: you can specify test(s) to be run at the end of the juju-test command, and juju-test won't traverse directories in the tests folder. So you could reorginze your helpers in another directory or just run juju-test unit.test deploy.test
[13:44] <teknico> marcoceppi: good to know about the subdirs. is there a way to reuse an already bootstrapped environment?
[13:45] <marcoceppi> teknico: not at the moment, but I can add that option. The downside being that you wouldn't get a teardown between tests. If your tests are OK with that it shouldn't be a problem
[13:46] <marcoceppi> teknico: finally, there are verbose controls, -v(vvv) which will give you debug output
[13:47] <teknico> marcoceppi: yes, I'm going to try again with those
[13:52] <marcoceppi> teknico: could you attach the output output with -vv in the report when it's done running?
[13:52] <teknico> marcoceppi: sure. what about the default env? any chance to use it?
[13:54] <marcoceppi> teknico: I made it explicit out of concern people would trample their default environments accidentally. However, I guess it'd be ok to use the default as it does a sanity check for already-bootstrapped
[13:55] <teknico> marcoceppi: yeah, it sounds reasonable
[13:55] <marcoceppi> I'll add default-environment support in a few mins
[13:56] <teknico> marcoceppi: great, thanks. I guess in order to actually use "juju test" rather than juju-test, we'll need a package in a PPA, right?
[14:13] <teknico> marcoceppi: output of a -vv run added
[14:16] <teknico> marcoceppi: those "Permission denied" errors are weird, perms and ownership are ok locally
[14:16] <marcoceppi> teknico: permission errors are because the files aren't +x
[14:16] <marcoceppi> well, your helper files aren't
[14:16] <teknico> ah, right
[14:23] <marcoceppi> teknico: It looks like environment variables aren't being passed to test properly. I'll see if I can get a fix for that out asap
[14:23] <teknico> marcoceppi: awesome, thanks
[14:37] <jcastro> dave mentions in the release notes that the PPA has changed
[14:37] <jcastro> but afaict, it's still ppa:juju/devel
[14:42] <marcoceppi> teknico: Give the latest a try. I wasn't able to check against your current repo as I don't have all the dependencies for testing, but it should fix the errors as well as trying to execute none-executables. Though that last bit might go away in the near future. You may want to reorganize or just document that you have to specify which .test files you want to run
[14:42] <marcoceppi> teknico: as for the default environment I'll see if I can get that in there later today
[14:42] <teknico> marcoceppi: thanks, I will in a while, in a call now
[14:43] <marcoceppi> teknico: ack, thanks for filing the bug and playing guinea pig :)
[14:43] <teknico> marcoceppi: oink ;-)
[15:22] <teknico> marcoceppi: there are some problems with last revno, running tests after applying this diff: http://pastebin.ubuntu.com/5717057/
[15:47] <FunnyLookinHat> Anyone here know why Content-Length wouldn't be included in the request to /tokens w/ the OpenStack provider ?
[15:47] <FunnyLookinHat> ( http://hastebin.com/fanagihive.xml )
[15:52] <marcoceppi> teknico: sorry about that! Not sure why make check didn't catch it. I've pushed a fixed that should work now
[15:53] <teknico> marcoceppi: now I'm having unrelated problems with selenium not being able to open displays :-/
[15:54] <marcoceppi> teknico: does selenium use the DISPLAY environment variable?
[15:54] <teknico> marcoceppi: I don't think so, it looks for display :1032
[15:55] <teknico> marcoceppi: the expert on that is frankban, I'll ask his help after our standup call ;-)
[15:56] <marcoceppi> teknico: cool, if there's anything else juju-test needs to set in the way on env vars, etc (as they're pretty light weight what's actually set when each test runs), let me know!
[15:56] <teknico> marcoceppi: I will, thanks again!
[16:04] <fwereade> danilos, https://codereview.appspot.com/9876043/ reviewed
[16:04] <fwereade> danilos, and, doh, disregard last question, I see you already answered it
[16:08] <fwereade> Makyo, ping
[16:08] <Makyo> fwereade, Hey
[16:09] <fwereade> Makyo, I'm a bit concerned about where the UpgradeCharm logic has moved to, can we g+ quickly?
[16:09] <Makyo> fwereade, sure
[16:10] <fwereade> Makyo, heh, I'm not sure which of the many matthew scotts you are...
[16:10] <fwereade> Makyo, I'm sure I *have* met you in person...
[16:11] <Makyo> fwereade, https://plus.google.com/105798904379156554275/posts
[16:13] <teknico> marcoceppi: so, I was wrong, and selenium does indeed need the DISPLAY env var
[16:25] <fwereade> cool, the review queue's looking a bit more manageable
[16:25] <fwereade> later all
[16:45] <marcoceppi> teknico: no problem, I'll add that to the plugin in a second
[16:45] <marcoceppi> teknico: anything else while I'm poking around?
[16:46] <teknico> marcoceppi: no thanks, I patched juju_test.py myself and am trying to run the test again
[16:47] <teknico> marcoceppi: there seem to be problems with manually destroying the env after the juju-test command is interrupted prematurely
[16:48] <teknico> marcoceppi: btw, the feature of only running tests in executable files is working flawlessly, thanks
[16:53] <marcoceppi> teknico: what's the error? That's likely a juju problem but I'll look in to trying to trap Ctrl+C to do better cleanup
[16:53] <teknico> marcoceppi: I get "error: environment is already bootstrapped"
[16:54] <marcoceppi> teknico: ah, because it didn't destroy-environment during the premature exit. You'll have to destroy environment before running again (or, when the option is added, use the "use-existing-bootstrap" option
[16:55] <teknico> marcoceppi: yes, that's what I was trying to do, but it takes quite a few retries, for some reason, or maybe just a bit of time
[17:00] <teknico> ok, EOD, I'll resume this tomorrow
[17:00] <teknico> marcoceppi: thanks again for the help
[17:01] <marcoceppi> teknico: thank you so much for the feedback!
[19:39] <jcastro_> https://bugs.launchpad.net/juju-core/+bug/1027873
[19:39] <_mup_> Bug #1027873: cmdline: Implement constraints set/get <cmdline> <juju-core:In Progress by fwereade> <https://launchpad.net/bugs/1027873>
[19:39] <jcastro_> marcoceppi: is this it?
[19:39] <marcoceppi> jcastro_: similar, that's setting them overall. this is specifically "juju add-unit --constraints"
[19:40] <fwereade> jcastro_, marcoceppi: heh, I apparently suck at bug management
[19:40] <marcoceppi> fwereade: is that released!
[19:40] <marcoceppi> ?
[19:40] <jcastro_> fwereade: hey so we just ran into this while doing a live site
[19:40] <fwereade> marcoceppi, no such thing as unit constraints (except internally, so pretend I didn't say that -- it's not meaningful in the model we want to expose)
[19:40] <jcastro_> where we deployed to an xsmall on HP cloud but need to bumpt the instance size up
[19:41] <marcoceppi> fwereade: right, so the idea was "juju add-unit --constraints" then we can remove unit the old on
[19:42] <fwereade> marcoceppi, you should be able to set service constraints, add-unit, and then remove the oldone
[19:42] <marcoceppi> fwereade: how? I didn't find anything in juju help
[19:42] <fwereade> marcoceppi, this then means that future ones will be deployed with the new constraints as well -- is that unhelpful?
[19:43] <fwereade> marcoceppi, `juju help set-constraints` looks, er, kinda crap... but `juju set-constraints myservice mem=4G` should work?
[19:44] <marcoceppi> fwereade: I'll give it a shot, thanks
[19:44]  * fwereade looks somewhat dolefully at the command and its help, and presumes he implemented that way to match python
[19:45]  * fwereade observes that, no, it doesn't even match python
[19:45] <fwereade> ah! that's ok
[19:46] <fwereade> I was reading get-constraints
[19:46] <fwereade> marcoceppi, juju set-constraints -s myservice mem=4G
[19:46] <fwereade> that's more like it
[19:46] <marcoceppi> cool
[20:06] <marcoceppi> fwereade: thanks, that did the trick!
[20:06] <fwereade> marcoceppi, great
[20:39] <marcoceppi> fwereade: along those same lines, can you force remove-unit?
[20:40] <marcoceppi> It's in a state of dying, but the machines never came up. Now I can't remove unit or terminate machine
[21:30] <thumper> morning
[21:31] <bac> hi thumper
[21:31] <thumper> hi bac
[21:31] <bac> hi marcoceppi, do you have a moment?  i'd like to talk about the charm-tools build recipe
[21:31] <marcoceppi> bac: I've got about 10-15 mins
[21:32] <bac> marcoceppi: perfect.  hangout?  i'll invite you
[21:32] <marcoceppi> bac: sounds good
[21:33] <bac> marcoceppi: failed
[21:34] <marcoceppi> just copy/paste a link?
[21:35] <bac> https://plus.google.com/hangouts/_/b665b424984af215e05d2968dab0964ada7130ed?hl=en
[22:32]  * thumper pulls a funny face
[22:32] <thumper> fwereade: not still up are you?
[22:51] <thumper> arse biscuits
[22:51] <thumper> wallyworld: you around?
[22:56] <wallyworld> thumper: hi
[22:56] <wallyworld> thumper: just a sec, need to talk to plumber
[23:05] <wallyworld> thumper: i gotta go do something. i'll ping you in a bit
[23:05] <thumper> wallyworld: ack