[00:18] <_mup_> ensemble/verify-version r323 committed by jim.baker@canonical.com
[00:18] <_mup_> Merged trunk
[00:22] <_mup_> ensemble/verify-version r324 committed by jim.baker@canonical.com
[00:22] <_mup_> Change protocol version to 0; explicity verify version key in test of InternalTopology.reset
[00:30] <adam_g> SpamapS: no dice unless im pushing to the wrong place. http://paste.ubuntu.com/667795/
[00:53] <_mup_> ensemble/expose-cleanup r312 committed by jim.baker@canonical.com
[00:53] <_mup_> More initial code
[01:31] <hazmat> niemeyer, do we have a eureka kanban?
[01:31] <niemeyer> hazmat: Not yet, but if the milestone is in place I can set it up right away
[01:31] <hazmat> niemeyer, the milestone is in place and most of the bugs are moved over
[01:31] <niemeyer> hazmat: Woot
[01:31] <niemeyer> hazmat: let me handle that
[01:31] <hazmat> niemeyer, much more fun programming lp than doing it in the browser
[01:32] <hazmat> niemeyer, i ended up writing a mongodb sync script last night after abandoning  cli integration
[01:32] <niemeyer> hazmat: Wow
[01:32] <niemeyer> hazmat: That sounds awesome
[01:32] <hazmat> niemeyer, and used that just now as a basis for doing all the mods (queries).. its gratitious i could have done it through the lp api, but the turnaround was much faster this way
[01:33] <hazmat> niemeyer, fwiw the mongodb sync code.. very much still in progress, i haven't gotten around to syncing people or teams yet, but its been useful by itself.. i need to parallelize the lp connections to take real advantage of the gevent concurrency options http://pastie.org/private/lnrfrdufyffnpbi7m69q
[01:36] <hazmat> right now the gevent integration is gratitutous
[01:39] <hazmat> interesting http://aws.amazon.com/govcloud-us/
[02:50] <_mup_> ensemble/expose-cleanup r313 committed by jim.baker@canonical.com
[02:50] <_mup_> Implemented reasonably robust spike
[02:51] <jimbaker> mocking tomorrow...
[11:14] <_mup_> ensemble/trunk r318 committed by gustavo@niemeyer.net
[11:14] <_mup_> Merge missed revision from kirkland's byobu-tmux branch, left
[11:14] <_mup_> out due to an error on my part when merging. [trivial]
[11:23] <fwereade> niemeyer: morning! missed you before :)
[11:23] <niemeyer> fwereade: Hey!
[11:23] <fwereade> niemeyer: thanks for all the reviews
[11:23] <niemeyer> fwereade: No problem!
[11:24] <fwereade> niemeyer: I think I'll be doing significant post-review changes in new stacked branches in future, to avoid monstrous diffs like the hide-instances one
[11:24] <fwereade> niemeyer: sensible?
[11:24] <niemeyer> fwereade: That sounds very sensible
[11:25] <fwereade> niemeyer: in that case: https://code.launchpad.net/~fwereade/ensemble/provider-base-launch-machine/+merge/71850 :)
[11:26] <fwereade> niemeyer: really just to check that that was what you wanted me to do
[11:26] <niemeyer> fwereade: Looking at it right now, coincidently
[11:26] <fwereade> niemeyer: it could be taken much further but I'm not yet convinced that's a good idea
[11:26] <fwereade> niemeyer: cool :)
[11:29] <niemeyer> fwereade: The bootstrap parameter doesn't look bad per se
[11:29] <niemeyer> fwereade: But there's something weird in it as a whole
[11:29] <fwereade> niemeyer: it's not *bad* but it feels a bit ...off-kilter
[11:29] <niemeyer> fwereade: Why do we have bootstrap() and start_machine(bootstrap=True)?
[11:29] <niemeyer> (rhetorical)
[11:30] <niemeyer> fwereade: It sounds like we're about to have an eureka moment :)
[11:31] <fwereade> niemeyer: because (1) bootstrap, in the context of start_machine, is shorthand for saying "I'd like this machine to play another couple of roles"; and (2) because LaunchMachine has an extra resposibility, which it shouldn't, that also uses the bootstrap parameter to complete the bootstrap operation (ie saving provider-state)
[11:31] <fwereade> niemeyer: I'd definitely like to fix it but it feels like a distinct bug/branch to me
[11:33] <niemeyer> fwereade: We need to distinguish the two operations in this branch, even if it's a matter of naming
[11:35] <fwereade> niemeyer: how about (1) moving the state-saving into bootstrap where it should be, and renaming the start_machine parameter "master"?
[11:35] <fwereade> niemeyer: (there should have been a (2) somewhere in there)
[11:35] <niemeyer> fwereade: Moving state-saving is unrelated to this, I think
[11:36] <fwereade> niemeyer: well... it's a lot of the justification for the param name being bootsrtap
[11:36] <fwereade> niemeyer: but that makes sense
[11:36] <fwereade> niemeyer: rename to "master", open a bug to move the state-saving?
[11:37] <niemeyer> fwereade: Alright, I think I know what to do..
[11:37] <fwereade> niemeyer: cool :)
[11:37] <niemeyer> Maybe
[11:38] <niemeyer> fwereade: Renaming to master is hiding the intention rather than making it more obvious
[11:39] <niemeyer> fwereade: Hmm, or maybe not
[11:39]  * niemeyer thinks
[11:39] <fwereade> niemeyer: well, one problem is that I think we lack a canonical term for that machine
[11:40] <fwereade> niemeyer: sometimes we call it the bootstrap node, sometimes the zookeeper
[11:40] <niemeyer> fwereade: True
[11:40] <niemeyer> fwereade: But that's not entirely a coincidence
[11:40] <niemeyer> fwereade: The machine itself is not special
[11:40] <fwereade> niemeyer: and I guess that when we have multiple zookeepers the precise nature of the machine(s) will change again
[11:40] <fwereade> niemeyer: quite so :)
[11:41] <niemeyer> fwereade: It just runs a service that we care about early on
[11:41] <fwereade> niemeyer: that was why I was thinking that it's actually part of machine_data (where machine_data refers to a putative sensible replacement for the data bag)
[11:42] <fwereade> niemeyer: machine-id is always needed; a machine implicitly always runs a machine agent; it may also run a zookeeper, and/or a provisioning agent
[11:42] <niemeyer> fwereade: That said, I retract my pedantism :)
[11:42] <niemeyer> fwereade: master=True sounds like a straightforward solution right now
[11:42] <fwereade> niemeyer: however I'm loath to dirty up machine_data further right now
[11:42] <fwereade> niemeyer: cool, cheers :)
[11:43] <niemeyer> fwereade: We can improve the situation once we do more about turning zookeeper and the provisioning agents into actual formulas
[11:44] <fwereade> niemeyer: ...I'm not sure we could deploy them as formulas without already having them in place, could we?
[11:44] <fwereade> niemeyer: oh, additional ones
[11:44] <fwereade> niemeyer: (right?)
[11:45] <niemeyer> fwereade: There's a chicken & egg problem we need to solve, but I think it's doable
[11:45] <fwereade> niemeyer: I can't quite see it yet, but it will be very nice if we can figure it out
[11:47] <fwereade> niemeyer: anyway, can I go ahead and merge that one back into provider-base with just your review?
[11:47] <fwereade> niemeyer: or should we wait for someone else to review both separately?
[11:47] <niemeyer> fwereade: E.g. 1) deploy zk alone; 2) Run machine agent against zk; 3) Deploy a unit within machine 0 with a second zk; 4) Sync second zk with first one; 5) Kill first zk..
[11:48] <niemeyer> fwereade: I think it's find to merge this as a review point for the first one
[11:48] <fwereade> niemeyer: hm, maybe :)
[11:48] <fwereade> niemeyer: ok, cool
[11:48] <fwereade> niemeyer: cheers
[11:48] <niemeyer> fwereade: Thanks for separating this out, btw.. it made a whole lot easier to review it
[11:48] <niemeyer> fwereade: We should talk to others in our meeting about this workflow
[11:59] <fwereade> niemeyer: cheers :)
[11:59] <fwereade> niemeyer: I'll try to remember
[12:08] <niemeyer> kim0: ping
[12:09] <kim0> niemeyer: Hey
[12:09] <niemeyer> kim0: Hey man
[12:09] <niemeyer> kim0: You probably haven't had time yet, but when you have a moment, can you please fix the "Ensemble security and firewall enhancements" post?
[12:18] <kim0> niemeyer: done .. thanks for clearing that up
[12:29] <_mup_> Bug #827994 was filed: MachineProvider interface inconsistent (list/*args) <Ensemble:New> < https://launchpad.net/bugs/827994 >
[12:42] <niemeyer> kim0: np!
[12:46] <fwereade> niemeyer: couple of clarifications on https://code.launchpad.net/~fwereade/ensemble/cobbler-zk-connect/+merge/71734 ...
[12:46] <fwereade> niemeyer: error style as follows?
[12:47] <fwereade> Some general thing that went wrong: Some specific explanatory message: Some message from the underlying exception
[12:48] <fwereade> eg
[12:50] <fwereade> ...er, sorry don't have the exact example I'm looking for
[12:51] <fwereade> niemeyer: anyway, the other question was: remove launch_time from ProviderMachine as well? I don't think anything else uses it...
[12:52] <fwereade> niemeyer: anyway, error message example
[12:53] <fwereade> Ensemble environment is not accessible: Machine i-foobar may not be ready: Connection timed out
[13:02] <niemeyer> fwereade: Sorry, was grabbing some coffee
[13:02] <niemeyer> fwereade: re. the message,
[13:02] <fwereade> niemeyer: np
[13:03] <niemeyer> fwereade: More than two levels feels a bit weird to me
[13:03] <niemeyer> fwereade: But you get the idea
[13:03] <fwereade> niemeyer: likewise, because that was my intent with the ones that aren't capitalised
[13:03] <niemeyer> fwereade: +1 on dropping launch_time if we have no users (woohay!)
[13:04] <fwereade> niemeyer: although I guess it's maybe not ideal having a common prefix on EnvironmentPending ("Ensemble environment is not available:")
[13:04] <niemeyer> fwereade: I think I provided an example of this message in the review, btw
 Ensemble environment is not accessible: Machine i-foobar may not be ready: Connection timed out
[13:04] <niemeyer> This message, I mean
[13:05] <fwereade> niemeyer: yep, seems reasonable, I think I misread exactly what you were after
[13:05] <fwereade> niemeyer: and, yay, code to delete :D
[13:06] <niemeyer> "Can't connect to machine %s (perhaps still initializing): %s"
[13:06] <niemeyer> fwereade: This will work regardless of context
[13:07] <niemeyer> fwereade: The message in your quote mentions the environment not being accessible, which has assumes things 
[13:07] <niemeyer> s/has//
[13:07] <fwereade> niemeyer: I should point out that ProviderInteractionError uses That: Nested: Style
[13:08] <niemeyer> fwereade: Hmm.. what's the outside message prefix?
[13:08] <niemeyer> fwereade: (wondering if we can drop it)
[13:08] <fwereade> niemeyer:         return "ProviderError: Interaction with machine provider failed: %r" % self.error
[13:09] <fwereade> niemeyer: ...and we expect PIE to wrap a range of other possible errors, I think, which may themselves Do: That
[13:09] <niemeyer> fwereade: That's not very nice
[13:09] <niemeyer> fwereade: That was kind of ok in the original context
[13:09] <fwereade> niemeyer: I think we can certainly lose the ProviderError: prefix
[13:10] <niemeyer> fwereade: ProviderInteractionError was used for wrapping
[13:10] <niemeyer> fwereade: Agreed
[13:10] <niemeyer> fwereade: Ugh.. and it uses repr
[13:10] <niemeyer> fwereade: This feels like an overlook
[13:10] <fwereade> niemeyer: OK, I'll see what I can do with that
[13:11] <niemeyer> fwereade: I think we can remove this entirely
[13:11] <niemeyer> fwereade: The wrapping, that is
[13:11] <niemeyer> fwereade: We shouldn't be wrapping our own error messages
[13:11] <niemeyer> fwereade: Unless we actually have something interesting to say, of course
[13:11] <niemeyer> fwereade: Which is not the case.
[13:11] <fwereade> niemeyer: I think PIEs tend to have been tested with assertIn("blah", str(error))
[13:12] <fwereade> niemeyer: I'll look for assertIns and make them assertEqualss, which should then make the nasty messages stick out
[13:12] <niemeyer> fwereade: If we wrap a message from e.g. S3 into a PIE, we should add a prefix at the wrapping spot, if at all
[13:12] <niemeyer> fwereade: This may be more work than you're looking for
[13:12] <niemeyer> fwereade: I'd just fix the messages themselves and fix whatever breaks
[13:13] <fwereade> niemeyer: I'll start a stacked branch and at least do a search, see how heavyweight it looks
[13:13] <niemeyer> fwereade: Cool, thanks
[13:13] <fwereade> niemeyer: killing launch_machine is pretty low-risk/low-noise, though, I'll do that inline first
[13:15] <fwereade> niemeyer: er, launch_time
[13:15] <niemeyer> fwereade: Superb
[14:07] <pindonga> hi, just wanted a quick heads up
[14:07] <pindonga> is ensemble still working only with ec2?
[14:07] <pindonga> or is it possible to use it with vms, like Vagrant , for example
[14:16] <niemeyer> pindonga: Hey
[14:16] <niemeyer> There's good work in progress to make it work with physical machines
[14:16] <niemeyer> pindonga: and local deployments too
[14:19] <jimbaker> fwereade, just a quick note - take a look at bzr log. our standard is to indicate in the log text which branch was merged in, along with reviewers and the bug fixed
[14:19] <jimbaker> when merging branches into trunk
[14:20] <fwereade> jimbaker: whoops, sorry
[14:21] <fwereade> jimbaker: I'll try to remember
[14:23] <jimbaker> fwereade, no worries
[14:26] <fwereade> niemeyer, everyone: I assert that (1) MachinesNotFound is a ProviderInteractionError, not just a ProviderError; and (2) anywhere we "except ProviderInteractionError" is still wrong, because many provider interactions raise ProviderError (for bad args, for example)
[14:26] <fwereade> opinions?
[14:27] <niemeyer> fwereade: 2 sounds sensible.. 1 feels strange
[14:28] <niemeyer> fwereade: Provider*Interaction*Error was, again, supposed to wrap interaction errors with the provider that we didn't expect 
[14:28] <fwereade> niemeyer: if I fix 2, I'm happy
[14:29] <niemeyer> fwereade: MachinesNotFound may not be an error in the provider, but on our own data about it
[14:29] <fwereade> niemeyer: yep, makes sense
[14:29] <niemeyer> fwereade: It's a ProviderError, but a well understood one
[14:29] <niemeyer> fwereade: I hope we kill ProviderInteractionError entirely at some point
[14:30] <fwereade> niemeyer: cool
[14:30] <fwereade> niemeyer: I'll be making sure the existing except PIEs also catch PEs in the errors branch I think
[14:31] <fwereade> niemeyer: feels like a really bad idea to let that linger
[14:31] <niemeyer> fwereade: Sounds good
[14:32] <fwereade> niemeyer: cheers, I'll just let it all bed in for a few minutes
[14:41] <_mup_> ensemble/expose-cleanup r314 committed by jim.baker@canonical.com
[14:41] <_mup_> Cleanup
[14:54] <niemeyer> Folks, have been working since early morning and stayed around until late yesterday.. I'm taking a longer mid-day break today for resting a bit.
[14:56] <_mup_> ensemble/formula-state-with-url r314 committed by kapil.thangavelu@canonical.com
[14:56] <_mup_> lazy init of storage url in formula serialization, default none url on state, restore passthrough error, and update failure/mock test that verifies for additional url param
[14:58] <hazmat> niemeyer, cheers
[15:07] <pindonga> niemeyer, anything I could try out (re: local deployments)
[15:12] <hazmat> pindonga, not at the moment, its actively being developed for our next internal release milestone mid september.
[15:13] <pindonga> hazmat, ok, I was asking as I'm in need of automating our infrastructure, so I wanted to follow the path of least effort :)
[15:13] <hazmat> it will be in the ppa ensemble roughly around then
[15:13] <pindonga> I want to be able to use ensemble in the future
[15:13] <pindonga> but since I need this now, I guess puppet+something else will have to do
[15:13] <hazmat> pindonga, atm ensemble really only works against ec2
[15:13] <pindonga> yeah
[15:14] <pindonga> thx anyway
[15:14] <hazmat> pindonga, we're striking out in a couple of different directions to address this, orchestra/cobbler integration for physical machines, lxc/local development, and out of the box openstack support. i'd say its probably about a month till we get these landed.
[15:15] <pindonga> cool
[15:15] <pindonga> I'll take a look again in a month then :)_
[15:20] <RoAkSoAx> fwereade: ping
[15:21] <fwereade> RoAkSoAx: pong
[15:21] <fwereade> RoAkSoAx: how's it going?
[15:21] <RoAkSoAx> fwereade: pretty goo, and you? heard you got stuck in chicago on the weekend?
[15:22] <fwereade> RoAkSoAx: yeah, it was a bit of a hassle :)
[15:22] <fwereade> RoAkSoAx: all good now though
[15:24] <fwereade> RoAkSoAx: are you in a position to do some reverification?
[15:24] <fwereade> RoAkSoAx: we're only 3 merges away from trunk now :)
[15:24] <RoAkSoAx> fwereade: yay!! and will do later today
[15:24] <RoAkSoAx> fwereade: i'm finishing some stuff up with cobbler/arm and once that's done i'm free
[15:24] <fwereade> RoAkSoAx: awesome!
[15:25] <fwereade> RoAkSoAx: how's that going?
[15:25] <RoAkSoAx> fwereade: pretty good, just patching cobbler, and have to write another small fix and it iwll be good to go
[15:25] <RoAkSoAx> fwereade: btw.. what branch of yours should I be using?
[15:25] <fwereade> RoAkSoAx: I'll send you a new branch, I honestly can't remember the state of the old ones and I don't fancy merging everything through
[15:26] <fwereade> RoAkSoAx: can you wait an hour or so? I'll make sure I've done it before I stop for the day :)
[15:28] <RoAkSoAx> fwereade: sure, take your time
[15:30] <hazmat> fwereade, so the base of provider-base-machine is provider-base-launch-machine?
[15:31] <fwereade> hazmat: I branched PBLM from PB, so niemeyer could review that separately and check it matched his thinking from the PBLM review; then I merged it back into PB
[15:32] <hazmat> ic, so the base is still trunk
[15:32] <fwereade> hazmat: gaah: s/from the PBLM review/from the PB review/
[15:32] <fwereade> hazmat: yep
[16:01] <fwereade> hey, is it team meeting time?
[16:03] <hazmat> fwereade, i though that was tomorrow
[16:04] <hazmat> s/thought
[16:04] <fwereade> hazmat: that would be quite convenient as it happens :)
[16:04] <fwereade> hazmat: thanks for the review btw 
[16:06] <hazmat> fwereade, np.. great stuff
[16:06] <fwereade> hazmat: I try :)
[16:11] <hazmat> niemeyer, bcsaller, jimbaker, fwereade btw. you guys probably saw the bug spam, but i closed out the dublin milestone, any dublin bugs which didn't have an assignee, got unassigned, and the rest moved on to the eureka milestone.
[16:12] <fwereade> hazmat: thanks 
[16:12] <hazmat> the eureka milestone has hard deadline, as its release time, so we're trying to only keep things on the milestone which we expect/need to get done for the close of the oneiric cycle
[16:12] <fwereade> jimbaker: curses, I included the bug and reviewers, and forgot the branch :/
[16:12] <hazmat> fwereade, np.. was fun to script it with the launchpad api
[16:18] <_mup_> Bug #828147 was filed: Ensemble branch option needs to allow for distro pkg, ppa, and source branch install <Ensemble:New> < https://launchpad.net/bugs/828147 >
[16:27] <_mup_> Bug #828152 was filed: default formula config values not available to hooks <Ensemble:New> < https://launchpad.net/bugs/828152 >
[16:28] <fwereade> later all
[16:35] <hazmat> fwereade, cheers
[16:39] <hazmat> jimbaker, do you mind if i put bug 828147  on your plate for the eureka milestone?
[16:39] <_mup_> Bug #828147: Ensemble branch option needs to allow for distro pkg, ppa, and source branch install <Ensemble:New> < https://launchpad.net/bugs/828147 >
[16:39] <hazmat> its something unrelated to feature dev, that we need for the release
[16:39] <jimbaker> hazmat, sure, looks like i would learn something fun
[16:39] <jimbaker> in terms of working with launchpad
[16:59] <hazmat> jimbaker, sadly the lp integration there is pretty minimal
[16:59] <hazmat> jimbaker, are you going to be enabling a runner that will do functional tests?
[16:59] <hazmat> jimbaker, i'm looking at some of the ftest outstanding bugs, and wondering if they should be on the eureka milestone
[17:08] <_mup_> ensemble/machine-agent-uses-formula-url r313 committed by kapil.thangavelu@canonical.com
[17:08] <_mup_> merge predecessor
[17:13] <_mup_> Bug #828189 was filed: machine agent should use formula url for unit deployment <Ensemble:In Progress by hazmat> < https://launchpad.net/bugs/828189 >
[17:15] <SpamapS> hazmat: dublin is over, right?
[17:17] <jimbaker> hazmat, ftest should be on the eureka milestone
[17:17] <jimbaker> as well as part of some sort of CI, presumably using jenkins
[17:18] <jimbaker> buildbot would also be ok, but jenkins has much better reporting
[17:23] <hazmat> SpamapS, it is
[17:23] <hazmat> jimbaker, jenkins is also a bit easier to setup imo
[17:23] <SpamapS> If only canonistack's S3 worked, it would already be running there. ;)
[17:24] <SpamapS> Actually I'm not sure canonistack is going to work.. 1.5GB isn't really enough for all those logs and graphs. ;)
[17:24] <jimbaker> hazmat, sounds good - i haven't done either setup, but i was very impressed w/ working w/ jenkins/hudson in the past
[17:24]  * SpamapS is thinking maybe that should be his Ensemble Audition candidate. :)
[17:25] <jimbaker> SpamapS, sounds like a good use of ensemble
[17:25] <m_3> SpamapS: can canonistack point to real S3?
[17:25] <jimbaker> to self monitor
[17:26] <m_3> at least temporarily
[17:26] <_mup_> ensemble/verify-version r325 committed by jim.baker@canonical.com
[17:26] <_mup_> Merged trunk & resolved conflict
[17:26] <m_3> or just external swift
[17:26] <hazmat> jcastro is your branch for bug 806638 ready for merging/review?
[17:26] <_mup_> Bug #806638: Docs need updating to mention what it expects as a value for instance type <Ensemble:In Progress by jorge> < https://launchpad.net/bugs/806638 >
[17:27] <hazmat> jcastro, actually that looks more like a trivial
[17:28] <SpamapS> m_3: no because the auth details would be different
[17:28] <hazmat> jcastro, i'll cowboy that in
[17:28] <hazmat> jimbaker, bcsaller1, niemeyer  can i get +1 on this trivial, http://bazaar.launchpad.net/~jorge/ensemble/docfix-instance-type/revision/266
[17:29] <m_3> gotcha... wasn't sure if we could configure separate S3_URL from ec2 endpoint for ensemble
[17:29] <SpamapS> m_3: been there, tried that. ;)
[17:29] <m_3> it's really about the image store though
[17:29] <jimbaker> hazmat,taking a look
[17:30] <jimbaker> hazmat, +1 on the trivial
[17:30] <bcsaller> hazmat: lgtm too
[17:33] <jcastro> hazmat: ah yeah I had forgotten about that, I was learning the docs and took an opportunity to do a quick fix.
[17:36] <_mup_> ensemble/trunk r320 committed by jim.baker@canonical.com
[17:36] <_mup_> merged verify-version [r=niemeyer,hazmat][f=825398]
[17:36] <_mup_> Store ensemble protocol version in /topology znode to ensure all
[17:36] <_mup_> topology using ops failfast with IncompatibleVersion if mismatch.
[17:38] <_mup_> ensemble/trunk r321 committed by kapil.thangavelu@canonical.com
[17:38] <_mup_> [trivial] clarify valid values ec2 provider option default-instance-type [r=bcsaller,jimbaker][a=jcastro]
[17:43] <_mup_> ensemble/trunk-merge r276 committed by kapil.thangavelu@canonical.com
[17:43] <_mup_> merge trunk
[17:43] <_mup_> ensemble/security-policy-with-topology r326 committed by kapil.thangavelu@canonical.com
[17:43] <_mup_> merge trunk and resolve conflict
[17:50] <_mup_> ensemble/security-agents-with-identity r314 committed by kapil.thangavelu@canonical.com
[17:50] <_mup_> resolve conflict and merge
[17:53] <_mup_> ensemble/states-with-principals r326 committed by kapil.thangavelu@canonical.com
[17:53] <_mup_> remove merge conflict files that got added.
[18:18] <_mup_> ensemble/expose-cleanup r315 committed by jim.baker@canonical.com
[18:18] <_mup_> Merged trunk & resolved conflict
[18:32] <_mup_> ensemble/expose-cleanup r316 committed by jim.baker@canonical.com
[18:32] <_mup_> Fixes due to provider refactoring
[19:57]  * niemeyer waves
[19:59] <niemeyer> hazmat: I started going in the direction we discussed for gozk last night, and suddenly a feeling of approach-rightness stroke me..
[20:00] <niemeyer> hazmat: I have to say it's really weird the way zk works by default
[20:00] <niemeyer> Can't imagine people writing reliable software would want this
[20:00] <niemeyer> In the specific sense of watch vs. CONNECTING/ASSOCIATING events
[20:01] <niemeyer> It's a bit like TCP popping up a notice to the stream saying "Hey, an ip packet got duplicated, but I dropped it, alright?"
[20:08] <hazmat> niemeyer, indeed its noise to most apps
[20:09] <hazmat> niemeyer, my short term memory must be really bad, i don't recall discussing gozk last night
[20:11] <hazmat> niemeyer, bcsaller, jimbaker also reminder we've got our weekly team meeting tomorrow
[20:11] <niemeyer> hazmat: We didn't.. I just felt in the mood to fix it after the previous talk we had a while ago
[20:12] <hazmat> ah.. right, previous discussions about gozk and session events, gotcha
[20:14] <_mup_> Bug #828326 was filed: need to be able to retrieve a service config or schema from the cli <Ensemble:New> < https://launchpad.net/bugs/828326 >
[20:26] <_mup_> ensemble/expose-cleanup r317 committed by jim.baker@canonical.com
[20:26] <_mup_> Partial fix of mock expectations in shutdown tests
[21:31] <_mup_> ensemble/expose-cleanup r318 committed by jim.baker@canonical.com
[21:31] <_mup_> Mocking on describe_instances going through state transitions
[21:54] <_mup_> Bug #828378 was filed: handle ec2 instance quotas <Ensemble:New> < https://launchpad.net/bugs/828378 >
[21:56] <hazmat> bcsaller, niemeyer so does an lxc sf mini-sprint still sound good?
[21:57] <bcsaller> hazmat: yes, did something change?
[21:58] <hazmat> bcsaller, just wanted to confirm
[22:02] <niemeyer> hazmat: Absolutely
[22:03] <niemeyer> hazmat: Makes a lot of sense
[22:04] <hazmat> niemeyer, great
[23:16] <_mup_> Bug #828411 was filed: relation status shows "up" before relation hooks complete execution <Ensemble:New> < https://launchpad.net/bugs/828411 >
[23:40] <jimbaker> m_3, bug 828411 is interesting - certainly not at a granularity that we currently track as you note
[23:40] <_mup_> Bug #828411: relation status shows "up" before relation hooks complete execution <Ensemble:New> < https://launchpad.net/bugs/828411 >
[23:42] <m_3> jimbaker: yeah, main use-case is testing at the moment
[23:42] <jimbaker> m_3, the only thing that really gives us a fairly comprehensive trace of the system state are the logs
[23:43] <m_3> but this should be simple and it's definitely something you'd expect the framework to tell you
[23:43] <jimbaker> maybe we can push more info into ZK, not certain
[23:43] <m_3> especially when it comes to more automation
[23:44] <jimbaker> m_3, the info being reported by status is actually is what is driving hook execution
[23:45] <m_3> might surface more with user-defined hooks or something
[23:45] <m_3> right now it's just a nice-to-have
[23:45] <jimbaker> m_3, sure, definitely will think about it. i just wonder if we can extract more value from logs
[23:45] <m_3> but seems like it would be important for state consistency going forward
[23:46] <m_3> logically it's two different states
[23:46] <m_3> (haven't taken the time to figure out a good solution... just starting the conversation with the bug)
[23:47] <jimbaker> m_3, it's possible that the shared scheduler mentioned in UnitRelationLifecycle would benefit from this
[23:48] <jimbaker> in terms of sharing more state through ZK,  which status could pick up
[23:48] <jimbaker> the shared scheduler being something not implemented
[23:49] <jimbaker> to my knowledge, the unit lifecycle is not recorded in ZK, but only in memory in the unit agent
[23:49] <m_3> hmmm... I'll have to look
[23:50] <jimbaker> i don't know dev plans for this. maybe to be addressed in the go rewrite, maybe earlier
[23:53] <m_3> kinda almost sits at the same level of user-defined hooks... user-defined events... user-defined states
[23:53] <m_3> that's probably what it should get lumped with
[23:53] <m_3> not sure
[23:57] <jimbaker> m_3, currently they are separate things, including what i would understand user-defined things to be
[23:58] <jimbaker> m_3, but where they could intersect is on the scheduling
[23:59] <jimbaker> also it's possible that user-defined could be meaningful on a relation, so that it would expand beyond settings