[00:28]  * thumper looks at anastasiamac_
[00:29] <thumper> anastasiamac_: Is there a reason that block.ProcessBlockedError doesn't use errors.Cause(err) ?
[00:31]  * thumper stops staring and wonders why the test is still failing with that line added
[00:31] <thumper> haha
[00:31] <thumper> ha
[00:31] <thumper> hmm...
[00:32]  * thumper looks at trunk
[00:32] <thumper> yep... broken in trunk
[00:32]  * thumper enfixorates
[01:14]  * thumper does a little dance
[01:14] <thumper> my three outstanding branches landed today
[01:14] <waigani> \o/
[02:02]  * menn0_ is struggling with the damn open ports migration (again)
[02:03] <menn0_> the tests are sensitive to anything with the DB changing...
[02:15]  * thumper weeps 
[02:15] <thumper> I know what is a great idea...
[02:15] <thumper> lets test the apiserver by exhaustively testing the command line client
[02:17] <thumper> or even better...
[02:17] <thumper> let's test the apiserver by calling the api client
[02:17] <thumper> what could possibly go wrong?
[02:17] <thumper> stabby stabby
[02:18]  * thumper takes a deep breath
[02:22]  * thumper breathes out
[02:23] <thumper> why does this make me so fucking angry?
[02:23] <wwitzel3> because it's wrong
[02:31] <thumper> thank you waigani
[02:31] <thumper> waigani: I think it is work I made you do earlier this year that makes the work I'm doing now slightly less painful
[02:33] <waigani> ha, I thought it was another wallyworld typo
[03:50] <thumper> menn0_: https://github.com/juju/juju/pull/1295
[03:50] <menn0_> thumper: looking
[03:51] <thumper> menn0: like the machine command branch but for environment commands
[03:51] <thumper> 1710 lines, and I tried to keep it small
[03:51] <thumper> geez
[03:52] <thumper> menn0: I suppose I could have landed the apiserver and client test refactoring separately
[03:52] <thumper> that would have reduced it by about 300 lines
[03:52] <menn0> menn0: yeah I was thinking that but now that you've done it
[03:52] <menn0> ...
[03:55] <thumper> meh
[03:55] <thumper> just noticed doc help for environment get still metions get-environment
[03:55]  * thumper stops for coffee
[04:27] <mattyw> jam1, are you around?
[04:45] <menn0> thedac: phew! review done.
[04:46] <menn0> thedac: that should have been thumper
[07:01] <mattyw> jam1, ping?
[07:01] <jam1> mattyw: hi
[07:01] <mattyw> jam1, hi there, I fixed http://reviews.vapour.ws/r/563/ after your comments, would you mind taking another look?
[07:02] <jam1> mattyw: looking
[07:11] <jam1> the diff still hasn't loaded....
[07:12] <jam1> mattyw: refresh worked. Anyway LGTM
[07:14] <mattyw> jam1, thanks very much
[07:14] <mattyw> jam1, I'm going to land it
[07:14] <jam1> np
[07:14] <jam1> sounds good
[07:35] <fwereade> axw, would you take a look at the latest diff on  http://reviews.vapour.ws/r/606/ please? context is failed test here: http://juju-ci.vapour.ws:8080/job/github-merge-juju/1581/console
[07:35] <axw> fwereade: looking
[07:36] <axw> fwereade: http://reviews.vapour.ws/r/589/? :)
[07:36] <fwereade> axw, dammit, ty
[07:51] <fwereade> axw, so, the doubled fields don't feel quite right to me -- ISTM that there's a fundamental properties-of-a-single-block-device struct that wants to get out
[07:52] <fwereade> axw, altough I *also* know that it's not quite that simple, witness the Constraints/HardwareCharacteristics dichotomy
[07:53] <axw> fwereade: there is one already: storage.BlockDevice. it's pretty much parallel to Constraints/HC
[07:53] <fwereade> axw, and I can also see the attraction to parsing constraints into a single struct that replaces the service-level one that came from the charm
[07:54] <fwereade> axw, yeah, I'm quibbling about the doubled fields more than anything
[07:54] <axw> fwereade: you mean Size vs. MinSize?
[07:54] <fwereade> axw, instinct is suggesting that Minimum and Preferred would be better top-level fields?
[07:54] <axw> ah, I see
[07:55] <fwereade> axw, and I see how Count is a bit of a problem from that perspective
[07:55] <fwereade> axw, but I'm starting to think that maybe it's a matter of an array of duped {min, pref} structs?
[07:56] <axw> fwereade: I did wonder about that, but how do you say that a struct isn
[07:56] <axw> erk
[07:56] <axw> isn't required at all
[07:56] <axw> s/struct/disk/
[07:57] <axw> i.e. I might like 100 disks, but I'll be happy if you have one or two
[07:57] <fwereade> axw, right, I see, it probably can't sanely be an array
[07:57] <axw> I would prefer if it's not in there though, since it's not an independent variable...
[07:58] <fwereade> axw, indeed, it does feel like it wants to exist at another level
[08:01] <fwereade> axw, although, hmm
[08:01] <fwereade> axw, I think the min/pref thing does still apply
[08:01] <fwereade> axw, we need at least 2 disks but really want 6
[08:02] <fwereade> axw, but you're right that they're independent
[08:02] <fwereade> axw, I can well imagine preferring to have 2 awesome disks than 6 crappy ones
[08:04] <fwereade> axw, that feels like it's pushing us towards more sophisticated fallback behaviour again
[08:05] <fwereade> axw, because if we just do straight "try preferred, then try minimum" we'd end up with 2 crappy disks
[08:05] <axw> good point
[08:05] <axw> ugh
[08:05] <fwereade> axw, can we make a case for count being different enough to be a separate dimension, even if it's specified together?
[08:06] <fwereade> axw, but even then
[08:06] <axw> fwereade: I think so- try preferred and then min count of (other) preferred constraints before
[08:06] <axw> anything else
[08:07] <fwereade> axw, it feels like we should *definitely* get explicit user feedback re choosing whether to degrade count or quality first
[08:07] <axw> which equates to, "give me as many of the best disks you can give me"
[08:07] <axw> yeah
[08:07] <fwereade> axw, some people will certainly care more about redundancy than speed
[08:08] <axw> fwereade: there's always going to be the option of being explicit about the constraints, in which case there's no degradation anyway
[08:08] <axw> but yes, this needs some input from interested parties
[08:08] <fwereade> axw, yeah, indeed
[08:08] <axw> my last email got crickets...
[08:09] <fwereade> axw, yeah, I feel this is something of a systemic issue
[08:09] <fwereade> axw, there *are* interested parties, but they all have their own priorities, and fixing the bugs today tends to take priority over defining the features of tomorrow
[08:11]  * axw nods
[08:14] <axw> fwereade: your diff LGTM
[08:15] <fwereade> axw, cool, thanks
[09:31] <perrito666> morning
[09:53] <TheMue> perrito666: o/
[10:01] <jam1> dimitern: standup ?
[10:01] <dimitern> jam, brt
[10:54] <axw> fwereade: in the interest of getting something working, would you be satisfied with separating the constraints out into top-level Minimum and Preferred, and refactoring if it turns out that it doesn't fit with the default fallback approach decided on later?
[10:54] <fwereade> axw, +1
[10:55] <axw> cool
[10:55] <fwereade> axw, I think it's one of those cases where we'll have to converge to what's actually right regardless
[10:56] <axw> fwereade: maybe, but I can't really see how there is a "right" here; it depends on the user, so it'd have to be policy driven
[10:57] <fwereade> axw, I'm really just thinking about the shape of the code and the structs that most happily map between the user view and the substrate
[10:57] <axw> oh, right
[11:41] <fwereade> so, I'm suffering an attack of incandescent rage re: the uniter tests building jujud
[11:41] <fwereade> does anyone have any bright ideas for how we might avoid doing this?
[12:22] <hazmat> what's the story on juju actions?
[12:22] <hazmat> we have apis but no cli?
[12:24] <fwereade> hazmat, they're under development, in https://github.com/juju-actions
[12:24] <fwereade> hazmat, hopefully soon tobe behind a feature flag as proposed by thumper, but I haven't kept up on whether he's done that
[12:24] <fwereade> hazmat, jw4 or bodie_ should know the latest
[12:39] <axw> fwereade: why do the uniter tests need jujud? are they executing hook tools?
[12:40] <fwereade> axw, yeah
[12:41] <fwereade> axw, I am *sooo* tempted to just use jsonrpc and hack up jujuc in python already :/
[12:42] <fwereade> axw, it used to be a separate executable
[12:42] <fwereade> axw, but it's not very small
[12:42] <fwereade> axw, and so we rolled it into jujud
[12:43] <axw> yeah, not long after I started I think
[12:43] <fwereade> axw, (but then that's not very nice for windows... /sigh)
[12:43] <fwereade> axw, I thought it was even before that
[12:44] <axw> maybe, maybe I just remember the old packages
[12:44] <fwereade> axw, hey ho :)
[12:45]  * perrito666 tipes fearful that the power might once again go off ..
[12:45] <perrito666> you have to love local power company
[12:50] <axw> fwereade: as a minimal change, perhaps move jujuCMain out of cmd/jujud/main.go into worker/uniter/jujuc somewhere, and add a new minimal cmd package just for those tests that calls jujuCMain
[12:50] <axw> then at least it doesn't build the entire tree
[12:54] <fwereade> axw, yeah, I was thinking about that, and then I got stressed about having a separate code path for the tests
[12:54] <fwereade> axw, which was leading me towards just doing a separate implementation in a scripting language
[12:55] <fwereade> axw, and then I started trying to find out what the protocol was for plain golang rpc and *ofc* we'd have to change it out for json and grr arrgh hmmph
[12:56] <axw> fwereade: what, everyone doesn't use websockets+json ? :)
[12:56] <fwereade> axw, ;p
[14:09] <jw4> hazmat: wrt actions - we've been holding off on the CLI until we can land the full implementation, but now that we have feature toggle we'll start landing what we have behind a flag.
[14:17] <coreycb> jw4, interesting timing on this topic, I was just going to ask about it :)
[14:17] <jw4> coreycb: :)
[14:17] <coreycb> jw4, any estimates on when cli will start to land?
[14:18] <jw4> Well, we have some finished already in the github.com/juju-actions/juju fork under the cli-action-dev branch
[14:19] <jw4> coreycb: my mission in the next couple days is to start landing the super command and sub commands behind a feature toggle
[14:19] <coreycb> jw4, great, thanks.  any chance you could point me to a charm that has action hooks?
[14:20] <jw4> coreycb: bodie_ mocked up a demo one that he's using for sample usage : https://github.com/binary132/actions-demo
[14:21] <jw4> coreycb: also, marcoceppi is using bleeding edge versions of the API for a project he's working on
[14:22] <coreycb> jw4, awesome, thank you
[14:23] <jw4> coreycb: please hit bodie_, TheMue , or I up with any and all comments / feedback / issues
[14:24] <coreycb> jw4, will do
[14:44] <wwitzel3> natefinch: ping
[14:45] <natefinch> ericsnow, wwitzel3: btw, realized I made a mistake with some of the configuration code for GCE..... we can talk about it in standup, but long story short, we have to keep all configuration in the original map[string]interface{}, unfortunately
[14:45] <natefinch> wwitzel3: howdy
[14:46] <natefinch> wwitzel3: want to hop in moonstone for the 1:1?
[14:46] <wwitzel3> natefinch: yep
[14:46] <sinzui> natefinch, We have a regressions bug 1401130 about joyent. There is only 1 suspect commit. Can you ask someone to investigate
[14:46] <mup> Bug #1401130: Joyent deployments cannot download agents from state-server <ci> <joyent-provider> <regression> <juju-core:Triaged> <https://launchpad.net/bugs/1401130>
[14:47] <natefinch> sinzui: sure
[14:47] <sinzui> dimitern, how goes the work on bug 1397376?
[14:47] <mup> Bug #1397376: maas provider: 1.21b3 removes ip from api-endpoints <api> <cloud-installer> <fallout> <landscape> <maas-provider> <juju-core:In Progress by dimitern> <juju-core 1.21:In Progress by dimitern> <https://launchpad.net/bugs/1397376>
[14:48] <dimitern> sinzui, live testing latest changes - maas still gives me some issues
[14:48] <sinzui> :/
[14:48] <dimitern> sinzui, I'll propose the fix while waiting
[14:48] <sinzui> thank you dimitern
[15:06] <hazmat> coreycb, jw4 re marcoceppi's prototype action cli via api https://github.com/juju-solutions/juju-action
[15:08] <jw4> thanks hazmat
[15:09] <coreycb> jw4, thanks!
[15:09] <coreycb> I mean, hazmat ^
[15:33] <katco> ericsnow: ping
[15:33] <ericsnow> katco: hey
[15:34] <katco> ericsnow: good morning :)
[15:34] <katco> ericsnow: i'm reviewing http://reviews.vapour.ws/r/608/
[15:34] <katco> ericsnow: the code looks good, but i'm having trouble knowing if it's complete. can you point me to some light literature on the nature of the change?
[15:35] <ericsnow> katco: https://github.com/juju/juju ;)
[15:35] <katco> ericsnow: haha
[15:35] <ericsnow> katco: I'm not expert on the uniter code nor on jujuc
[15:36] <katco> ericsnow: i guess i'm trying to understand if availability zones need to be added elsewhere, or if any additional tests are needed
[15:36] <katco> ericsnow: as i am not an expert on this concept either
[15:36] <ericsnow> katco: for this change I simply traced how we get the IP address stuff into relation-get and did the same for the availability zone
[15:36] <katco> ericsnow: ah ok. so the use-case is much the same
[15:37] <ericsnow> katco: yep
[15:37] <katco> ericsnow: do you think any additional tests are needed to ensure it's being set?
[15:37] <ericsnow> katco: see https://docs.google.com/a/canonical.com/document/d/1yVlzgKqfhKccUbm3WcZBq7WnzglBygknscr_I_u4bUg/
[15:37] <katco> ericsnow: thanks
[15:38] <ericsnow> katco: this patch is just a tiny part of all that spec
[15:38] <katco> ericsnow: like maybe instead of checking for an empty string in uniter_base_test.go, we maybe fill in an availability zone and check it?
[15:39] <ericsnow> katco: I'd be glad to add more tests (there's always a gap to fill)
[15:39] <katco> ericsnow: nothing too crazy or anything, maybe just a single test to ensure it's being passed around correctly?
[15:40] <ericsnow> katco: suggesting it in a review comment would be most helpful
[15:40] <katco> ericsnow: you got it
[15:40] <ericsnow> katco: good idea
[15:40] <ericsnow> katco: tas
[15:40] <katco> ericsnow: thanks for the explanation :)
[15:40] <ericsnow> katco: I just dumped everything I know on the subject ;)
[15:41] <katco> ericsnow: haha well it was helpful :)
[15:41] <ericsnow> katco: good
[16:10] <ericsnow> natefinch: standup?
[16:12] <natefinch> ericsnow: doh, coming
[16:14] <dimitern> ericsnow, is the RB hook not working?
[16:15] <dimitern> ericsnow, I have this PR https://github.com/juju/juju/pull/1297 - maybe the description is too long for the hook to handle and add the RB link?
[16:15] <dimitern> anyway..
[16:16] <ericsnow> dimitern: this happened the other day to axw
[16:16] <ericsnow> dimitern: I'll check it out
[16:16] <dimitern> ericsnow, yeah, I guess the bot just said tl;dr :)
[16:16] <ericsnow> dimitern: :)
[16:17] <dimitern> katco, as OCR can you have a look at this fix for bug 1397376 ?  https://github.com/juju/juju/pull/1297
[16:17] <mup> Bug #1397376: maas provider: 1.21b3 removes ip from api-endpoints <api> <cloud-installer> <fallout> <landscape> <maas-provider> <juju-core:In Progress by dimitern> <juju-core 1.21:In Progress by dimitern> <https://launchpad.net/bugs/1397376>
[16:17] <katco> dimitern: one sec, on a call
[16:18] <dimitern> katco, np, when you can
[16:18] <dimitern> fwereade, is you're still around and willing can you have a look as well? ^^
[16:18] <dimitern> if*
[16:40] <katco> dimitern: apologies. i am in the middle of reviewing axw's storage branch and then i'll hop onto yours
[16:41] <katco> dimitern: ty for the ping :)
[16:42] <dimitern> katco, it's ok, take your time
[16:51] <katco> ericsnow: hey can you look at the diff for http://reviews.vapour.ws/r/589/
[16:51] <katco> ericsnow: i think review board has an error
[16:51] <katco> ericsnow: it's not displaying the diff for some files
[16:51] <ericsnow> katco: will do
[16:52] <ericsnow> katco: were those files removed?
[16:52] <katco> ericsnow: ty sir
[16:52] <katco> ericsnow: um. hrm.
[16:52] <katco> ericsnow: let me check, didn't think of that
[16:53] <katco> ericsnow: ah yes they were. but that shouldn't show up as an error should it?
[16:53] <katco> ericsnow: i would expect it to say something sensible, like "file deleted" for the RHS
[16:56] <katco> dimitern: hey am i daft? i don't see your PR on review board?
[16:57] <dimitern> katco, yeah - it got hit by the "desc tl;dr" RB bot bug
[16:57] <dimitern> ..apparently
[16:57] <katco> dimitern: oh, haven't hit that one yet. so can you post the diffs to RB manually?
[16:57] <dimitern> katco, I can certainly try.. give me a sec
[16:58] <katco> dimitern: ty sir
[16:59] <ericsnow> dimitern: looks like github is giving us a 404 when we go to pull the diff
[16:59] <ericsnow> dimitern: I'll need to investigate further
[17:00] <dimitern> katco, there you go - http://reviews.vapour.ws/r/611/diff/
[17:00] <dimitern> ericsnow, oh boy.. it's not even that big :) ~1K lines
[17:01] <sinzui> natefinch, is anyone working on bug 1401130 or bug 1400358 that block merges
[17:01] <ericsnow> dimitern: (though the 404 may actually mean 401)
[17:01] <mup> Bug #1401130: Joyent deployments cannot download agents from state-server <ci> <joyent-provider> <regression> <juju-core:Triaged> <https://launchpad.net/bugs/1401130>
[17:01] <mup> Bug #1400358: TestLoginsDuringUpgrade broken on i386 <ci> <regression> <testing> <juju-core:In Progress by menno.smits> <https://launchpad.net/bugs/1400358>
[17:01] <katco> dimitern: tyvm!
[17:01] <dimitern> ericsnow, interesting - some auth cache/cookie expired?
[17:02] <sinzui> dimitern, if you need to submit you fix for api-endpoints and CI is blocked, use "__JFDI__" in the message
[17:02] <natefinch> sinzui: no, sorry, been in meetings all morning.  I'll try to get someone on those now.
[17:02] <dimitern> sinzui, yep, I know the drill :)
[17:02] <ericsnow> dimitern: pretty sure the auth is okay (but the 400 implies it's not)
[17:03] <dimitern> weird..
[17:03] <dimitern> anyway I'll be off now
[17:04] <dimitern> sinzui, I'll merge the fix tomorrow morning. it seems
[17:05] <katco> dimitern: i'll ping you after i'm done reviewing in the off-chance you're still on
[17:06] <katco> dimitern: but this one is likely going to take awhile
[17:07] <dimitern> katco, ok
[17:08] <dimitern> katco, btw don't feel obliged to approve it, if it's not clear; it's was a mess before, a little less now, but still not perfect
[17:10] <katco> dimitern: no worries
[17:39] <wwitzel3> ericsnow: ping
[17:40] <ericsnow> wwitzel3: ready?
[17:41] <wwitzel3> ericsnow: yep, in moonstone
[17:41] <ericsnow> wwitzel3: brt
[17:58] <ericsnow> wwitzel3: port range parsing: http://reviews.vapour.ws/r/612/
[18:49] <natefinch> perrito666: can you take a look at https://bugs.launchpad.net/juju-core/+bug/1401130 ?   unfortunately, I have to take the kids while my wife goes to a prenatal checkup, so I'll be out most of the afternoon.
[18:49] <mup> Bug #1401130: Joyent deployments cannot download agents from state-server <ci> <joyent-provider> <regression> <juju-core:Triaged> <https://launchpad.net/bugs/1401130>
[18:50] <natefinch> sinzui: menno has a fix for the other one, I think it best for him to just get that in later today (early in his day)
[18:51] <sinzui> okay. thank you natefinch
[19:14] <perrito666> looking
[19:19] <jw4> We're beginning to land Actions CLI commands now behind an "action" feature flag
[19:19] <jw4> the first PR is http://reviews.vapour.ws/r/613/
[19:19] <jw4> PTAL OCR ^^
[19:19] <jw4> :)
[19:24] <katco> jw4: PTAL? sorry still working my way through dimitern's change
[19:26] <perrito666> sinzui: has anyone tried that by hand?
[19:28] <sinzui> perrito666, about the which thing?
[19:28] <sinzui> oh, I see
[19:28] <perrito666> sinzui: sorry I swallowed the context
[19:28] <perrito666> about the joyent issue
[19:29] <sinzui> perrito666, Yes. I tried joyent with tip and 1.20.13 and 1.20.14
[19:29] <sinzui> perrito666, I the 1.20.x do work
[19:29] <sinzui> perrito666, I attached the cloud-init-output.log of the 1.22-alpha1 machine that was stuck in pending
[19:31] <perrito666> sinzui: it is interesting that you think it can be related to this bug https://bugs.launchpad.net/ubuntu/+source/unity/+bug/1283992
[19:31] <mup> Bug #1283992: Multi-monitor: wallpaper is corrupted <amd64> <apport-bug> <compiz-0.9> <trusty> <ubuntu> <unity (Ubuntu):Invalid> <https://launchpad.net/bugs/1283992>
[19:31] <sinzui> perrito666, Joyent has a history of good bootstraps and bad deployments because the other machines got a different network than the one the state-server was one. A few months ago, wallyworld or awx added a rule to select the right network
[19:31] <perrito666> ahh buu the title is right here
[19:31] <sinzui> oops.
[19:31]  * sinzui looks for other joyent network bug
[19:32]  * perrito666 changes wallpaper
[19:33] <sinzui> perrito666, I think the current issue may relate to bug 1383922
[19:33] <mup> Bug #1383922: Services deployed joyent have broken networks <ci> <deploy> <joyent-provider> <reliability> <juju-core:Triaged> <https://launchpad.net/bugs/1383922>
[19:34] <sinzui> perrito666, there is one other nuance. Joyent added firewalls as a feature for each. machine. We don't use them, but I wondered if joyent ever had a rule to bring up the machine with with firewall up, then takes it down when it thinks the machine is ready
[19:55] <perrito666> sinzui: sorry to bother again, I am trying to make a picture of the issue here
[19:56] <sinzui> go ahead perrito666
[19:59] <perrito666> sinzui: the cloudinit log from a failure, comes from an attempt with master tip?
[19:59] <perrito666> (sorry for the dramatic pause, dog ran away into a pool of muddle)
[19:59] <sinzui> perrito666, yes, was a few hours ago
[20:00]  * sinzui looks for commit
[20:00] <sinzui> perrito666, it was commit 0363d9c6
[20:01] <perrito666> sinzui: I think a valid test would be to run by hand the last successful commit
[20:01] <perrito666> it is a quick way to know if its us or them
[20:01] <sinzui> perrito666, this log is uniformative http://juju-ci.vapour.ws:8080/job/joyent-deploy-precise-amd64/1240/console, so while it was stalled in pending, I sshed into one of the machine
[20:02] <sinzui> perrito666, but there are no streams for it. I can run the entire build or...
[20:02]  * perrito666 thinks
[20:03] <perrito666> I think the test would be valid enough with upload tools
[20:03] <sinzui> ...or use a binary from http://juju-ci.vapour.ws:8080/job/publish-revision/1283/ with --upload tools
[20:03] <perrito666> sidenote: we need to have a non hackish tools to publish a stream
[20:17] <sinzui> perrito666, that last version just worked for me.
[20:18] <perrito666> ok, so we broke something
[20:24] <thumper> waigani_: so "state-id" in the dummy config seems like it is not important
[20:24] <thumper> waigani_: I'm trying to see where it is used
[20:24] <thumper> waigani_: what exactly is failing for you?
[20:24] <waigani_> ... value *errors.Err = &errors.Err{message:"cannot add a new machine", cause:(*errors.errorString)(0xc21027f730), previous:(*errors.errorString)(0xc21027f730), file:"github.com/juju/juju/state/addmachine.go", line:168} ("cannot add a new machine: invalid state-id \"90168e4c-2f10-4e9c-83c2-feedfacee5a9\"")
[20:25] <waigani_> and if I don't pass the state-id in:
[20:25] <waigani_> 	... value *errors.Err = &errors.Err{message:"cannot add a new machine", cause:(*errors.errorString)(0xc21008b9c0), previous:(*errors.errorString)(0xc21008b9c0), file:"github.com/juju/juju/state/addmachine.go", line:168} ("cannot add a new machine: environment is not prepared")
[20:25] <waigani_> thumper: ^
[20:26] <thumper> waigani_: well a state id needs to be an integer
[20:27] <thumper> waigani_: and it seems llike the dummy env sets it itself
[20:27] <thumper> waigani_: because it expects only one environment
[20:27] <waigani_> ah
[20:27] <thumper> waigani_: you may need to look through the dummy provider somewhat
[20:28] <thumper> waigani_: the dummy provider calls 'newState' which seems to do stuff we don't want
[20:28] <thumper> for secondary environments
[20:28] <waigani_> thumper: right, maybe a new branch to get dummy to work with non-state-server envs?
[20:29] <thumper> waigani_: yeah... I think that may be needed
[20:29] <thumper> waigani_: it seems that dummy assumes too much now
[20:29] <waigani_> haha, I am now three branches removed from what I started on this week
[20:29] <thumper> :-)
[20:29] <thumper> push another on the stack
[20:29] <thumper> eventually you'll get to pop some
[20:30] <waigani_> yep
[20:30] <thumper> waigani_: please add a task card on kanban :)
[20:30] <menn0> waigani_: it could be worse. you might be using Subversion.
[20:30] <waigani_> lol
[20:31] <waigani_> thumper: okay, I'll shelve others, update kanban and start this new branch.
[20:31]  * thumper nods
[22:21] <menn0> thumper: here's that test fix: http://reviews.vapour.ws/r/615/
[22:22] <menn0> thumper: I think it's ok now (not *too* ugly)
[22:23]  * thumper looks
[22:24] <thumper> menn0: why refactor the machine agent?
[22:24] <thumper> what do you get out of it?
[22:25] <menn0> thumper: so that the specific workers that the test needs can be run
[22:25] <menn0> thumper: instead of spinning up the whole agent
[22:26] <menn0> thumper: moving the code that starts workers into methods makes it available from the test
[22:27] <menn0> s/it/them/
[22:27] <thumper> ah..
[22:27] <thumper> kk
[22:27] <thumper> hadn't got to the tests yet :)
[22:27] <menn0> thumper: right, I can see how the machine agent changes might have seemed unnecessary without seeing the tests :)
[22:37] <thumper> menn0: ship it!
[22:37] <menn0> thumper: cheers
[22:39] <menn0> thumper: I hadn't realised that this bug had been "promoted" to a CI blocker
[22:40] <menn0> thumper: just as well that I was working on it
[22:40] <thumper> :)
[22:40] <thumper> I didn't know either
[22:40] <thumper> oh, looky looky, there are two critical bugs in the topic
[22:50] <alexisb> thumper, that is very observant of you
[22:50] <alexisb> perrito666 is working one
[22:51] <alexisb> or was the last time I checked in
[22:52] <thumper> alexisb: I try
[22:56] <jw4> Okay take two :: OCR PTAL http://reviews.vapour.ws/r/616/
[22:57] <jw4> thumper: included your feedback into this new PR ^^
[22:57] <thumper> jw4: ok, I'll take a look after lunch. not OCR but interested
[22:58] <jw4> thumper: cool, thanks - fwiw my approach to setting and restoring the flags might need to be generalized but I wanted to keep it light
[22:58] <thumper> jw4: I've not looked, but we probably want two tests for the commands, one to show it isn't there by default, and one to show it is when flag is set
[22:59]  * thumper wanders off for a bit
[22:59] <jw4> thumper: +1
[23:16] <menn0> hmmm... this is a new merge failure
[23:16] <menn0> Traceback (most recent call last):
[23:16] <menn0>   File "/var/lib/jenkins/juju-ci-tools/ec2-terminate-job-instances", line 3, in <module>
[23:16] <menn0>     from deploy_stack import destroy_job_instances
[23:16] <menn0>   File "/var/lib/jenkins/juju-ci-tools/deploy_stack.py", line 23, in <module>
[23:16] <menn0>     from jujupy import (
[23:16] <menn0>   File "/var/lib/jenkins/juju-ci-tools/jujupy.py", line 25, in <module>
[23:16] <menn0>     from utility import (
[23:17] <menn0>   File "/var/lib/jenkins/juju-ci-tools/utility.py", line 16, in <module>
[23:17] <menn0>     from mock import patch
[23:17] <menn0> ImportError: No module named mock
[23:17] <menn0> looks like mock isn't installed on the build host
[23:17] <menn0> or something
[23:19] <ericsnow> wwitzel3: I didn't realize it was so late for you
[23:19] <ericsnow> wwitzel3: want to pick this up tomorrow?
[23:20] <ericsnow> wwitzel3: I got the PortSet patch up: http://reviews.vapour.ws/r/617/
[23:20] <ericsnow> wwitzel3: I also updated dependencies.tsv on the GCE branch
[23:20] <ericsnow> wwitzel3: I'll still be here a while
[23:30] <perrito666> alexisb: hey I was looking at the joyent one until the power went down
[23:30] <perrito666> I am just back
[23:36] <wwitzel3> ericsnow: ok, sorry, yeah was doing the dinner thing
[23:37] <ericsnow> wwitzel3: no worries
[23:37] <ericsnow> wwitzel3: I feel dumb for taking you so far past lunch :(
[23:37] <ericsnow> wwitzel3: ...that you simply went straight to dinner
[23:38] <ericsnow> wwitzel3: timezones stink
[23:38] <wwitzel3> ericsnow: it's fine, it was fun, I will give a review to PortSet and helpers before I take off. Then we can pickup tomorrow where you we leave off with you driving.
[23:39] <ericsnow> wwitzel3: perfect
[23:39] <ericsnow> wwitzel3: have a nice evening
[23:41] <menn0> davecheney: would you mind taking a look at http://reviews.vapour.ws/r/618/
[23:41] <menn0> davecheney: it's a one line change
[23:42] <menn0> so builds are broken right now
[23:43] <menn0> I'm trying to merge the fix for one of the CI blockers. The test all pass but the CI tool that cleans up the EC2 instances dies because it can't import the Python "mock" library.
[23:45] <menn0> thumper: ^^^
[23:45] <menn0> thumper: looks like we're blocked until someone for the QA team is around
[23:51] <davecheney> sure
[23:51] <davecheney> looking
[23:56] <thumper> jw4: I thought you were going to break that branch up?
[23:57] <jw4> thumper: exactly
[23:57] <jw4> thumper: that's why I didn't the first time
[23:57] <thumper> jw4: 616 is still everything
[23:57] <jw4> thumper: bodie made that initial commit set up the framework for all the subcommands
[23:58] <jw4> thumper: no, none of the subcommands are implemented
[23:58] <jw4> thumper: just skeletal
[23:58] <jw4> thumper: later commits fill in all the subcommands
[23:58] <thumper> ah...
[23:58] <thumper> ok
[23:58]  * thumper looks again
[23:58] <jw4> thumper: I'd have to actually break up that one commit to get it smaller
[23:58] <jw4> thumper: and it'd be a royal pain
[23:58] <jw4> thumper: but... if that's what is required