_mup_ensemble/verify-version r323 committed by jim.baker@canonical.com00:18
_mup_Merged trunk00:18
_mup_ensemble/verify-version r324 committed by jim.baker@canonical.com00:22
_mup_Change protocol version to 0; explicity verify version key in test of InternalTopology.reset00:22
adam_gSpamapS: no dice unless im pushing to the wrong place. http://paste.ubuntu.com/667795/00:30
_mup_ensemble/expose-cleanup r312 committed by jim.baker@canonical.com00:53
_mup_More initial code00:53
hazmatniemeyer, do we have a eureka kanban?01:31
niemeyerhazmat: Not yet, but if the milestone is in place I can set it up right away01:31
hazmatniemeyer, the milestone is in place and most of the bugs are moved over01:31
niemeyerhazmat: Woot01:31
niemeyerhazmat: let me handle that01:31
hazmatniemeyer, much more fun programming lp than doing it in the browser01:31
hazmatniemeyer, i ended up writing a mongodb sync script last night after abandoning  cli integration01:32
niemeyerhazmat: Wow01:32
niemeyerhazmat: That sounds awesome01:32
hazmatniemeyer, 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 way01:32
hazmatniemeyer, 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/lnrfrdufyffnpbi7m69q01:33
hazmatright now the gevent integration is gratitutous01:36
hazmatinteresting http://aws.amazon.com/govcloud-us/01:39
=== niemeyer changed the topic of #ubuntu-ensemble to: http://j.mp/ensemble-eureka | http://ensemble.ubuntu.com/docs
_mup_ensemble/expose-cleanup r313 committed by jim.baker@canonical.com02:50
_mup_Implemented reasonably robust spike02:50
jimbakermocking tomorrow...02:51
=== otubo is now known as otubo[AFK]
_mup_ensemble/trunk r318 committed by gustavo@niemeyer.net11:14
_mup_Merge missed revision from kirkland's byobu-tmux branch, left11:14
_mup_out due to an error on my part when merging. [trivial]11:14
fwereadeniemeyer: morning! missed you before :)11:23
niemeyerfwereade: Hey!11:23
fwereadeniemeyer: thanks for all the reviews11:23
niemeyerfwereade: No problem!11:23
fwereadeniemeyer: I think I'll be doing significant post-review changes in new stacked branches in future, to avoid monstrous diffs like the hide-instances one11:24
fwereadeniemeyer: sensible?11:24
niemeyerfwereade: That sounds very sensible11:24
fwereadeniemeyer: in that case: https://code.launchpad.net/~fwereade/ensemble/provider-base-launch-machine/+merge/71850 :)11:25
fwereadeniemeyer: really just to check that that was what you wanted me to do11:26
niemeyerfwereade: Looking at it right now, coincidently11:26
fwereadeniemeyer: it could be taken much further but I'm not yet convinced that's a good idea11:26
fwereadeniemeyer: cool :)11:26
niemeyerfwereade: The bootstrap parameter doesn't look bad per se11:29
niemeyerfwereade: But there's something weird in it as a whole11:29
fwereadeniemeyer: it's not *bad* but it feels a bit ...off-kilter11:29
niemeyerfwereade: Why do we have bootstrap() and start_machine(bootstrap=True)?11:29
niemeyerfwereade: It sounds like we're about to have an eureka moment :)11:30
fwereadeniemeyer: 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
fwereadeniemeyer: I'd definitely like to fix it but it feels like a distinct bug/branch to me11:31
niemeyerfwereade: We need to distinguish the two operations in this branch, even if it's a matter of naming11:33
fwereadeniemeyer: how about (1) moving the state-saving into bootstrap where it should be, and renaming the start_machine parameter "master"?11:35
fwereadeniemeyer: (there should have been a (2) somewhere in there)11:35
niemeyerfwereade: Moving state-saving is unrelated to this, I think11:35
fwereadeniemeyer: well... it's a lot of the justification for the param name being bootsrtap11:36
fwereadeniemeyer: but that makes sense11:36
fwereadeniemeyer: rename to "master", open a bug to move the state-saving?11:36
niemeyerfwereade: Alright, I think I know what to do..11:37
fwereadeniemeyer: cool :)11:37
niemeyerfwereade: Renaming to master is hiding the intention rather than making it more obvious11:38
niemeyerfwereade: Hmm, or maybe not11:39
* niemeyer thinks11:39
fwereadeniemeyer: well, one problem is that I think we lack a canonical term for that machine11:39
fwereadeniemeyer: sometimes we call it the bootstrap node, sometimes the zookeeper11:40
niemeyerfwereade: True11:40
niemeyerfwereade: But that's not entirely a coincidence11:40
niemeyerfwereade: The machine itself is not special11:40
fwereadeniemeyer: and I guess that when we have multiple zookeepers the precise nature of the machine(s) will change again11:40
fwereadeniemeyer: quite so :)11:40
niemeyerfwereade: It just runs a service that we care about early on11:41
fwereadeniemeyer: 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:41
fwereadeniemeyer: machine-id is always needed; a machine implicitly always runs a machine agent; it may also run a zookeeper, and/or a provisioning agent11:42
niemeyerfwereade: That said, I retract my pedantism :)11:42
niemeyerfwereade: master=True sounds like a straightforward solution right now11:42
fwereadeniemeyer: however I'm loath to dirty up machine_data further right now11:42
fwereadeniemeyer: cool, cheers :)11:42
niemeyerfwereade: We can improve the situation once we do more about turning zookeeper and the provisioning agents into actual formulas11:43
fwereadeniemeyer: ...I'm not sure we could deploy them as formulas without already having them in place, could we?11:44
fwereadeniemeyer: oh, additional ones11:44
fwereadeniemeyer: (right?)11:44
niemeyerfwereade: There's a chicken & egg problem we need to solve, but I think it's doable11:45
fwereadeniemeyer: I can't quite see it yet, but it will be very nice if we can figure it out11:45
fwereadeniemeyer: anyway, can I go ahead and merge that one back into provider-base with just your review?11:47
fwereadeniemeyer: or should we wait for someone else to review both separately?11:47
niemeyerfwereade: 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:47
niemeyerfwereade: I think it's find to merge this as a review point for the first one11:48
fwereadeniemeyer: hm, maybe :)11:48
fwereadeniemeyer: ok, cool11:48
fwereadeniemeyer: cheers11:48
niemeyerfwereade: Thanks for separating this out, btw.. it made a whole lot easier to review it11:48
niemeyerfwereade: We should talk to others in our meeting about this workflow11:48
fwereadeniemeyer: cheers :)11:59
fwereadeniemeyer: I'll try to remember11:59
niemeyerkim0: ping12:08
kim0niemeyer: Hey12:09
niemeyerkim0: Hey man12:09
niemeyerkim0: 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:09
kim0niemeyer: done .. thanks for clearing that up12:18
_mup_Bug #827994 was filed: MachineProvider interface inconsistent (list/*args) <Ensemble:New> < https://launchpad.net/bugs/827994 >12:29
niemeyerkim0: np!12:42
fwereadeniemeyer: couple of clarifications on https://code.launchpad.net/~fwereade/ensemble/cobbler-zk-connect/+merge/71734 ...12:46
fwereadeniemeyer: error style as follows?12:46
fwereadeSome general thing that went wrong: Some specific explanatory message: Some message from the underlying exception12:47
fwereade...er, sorry don't have the exact example I'm looking for12:50
fwereadeniemeyer: anyway, the other question was: remove launch_time from ProviderMachine as well? I don't think anything else uses it...12:51
fwereadeniemeyer: anyway, error message example12:52
fwereadeEnsemble environment is not accessible: Machine i-foobar may not be ready: Connection timed out12:53
niemeyerfwereade: Sorry, was grabbing some coffee13:02
niemeyerfwereade: re. the message,13:02
fwereadeniemeyer: np13:02
niemeyerfwereade: More than two levels feels a bit weird to me13:03
niemeyerfwereade: But you get the idea13:03
fwereadeniemeyer: likewise, because that was my intent with the ones that aren't capitalised13:03
niemeyerfwereade: +1 on dropping launch_time if we have no users (woohay!)13:03
fwereadeniemeyer: although I guess it's maybe not ideal having a common prefix on EnvironmentPending ("Ensemble environment is not available:")13:04
niemeyerfwereade: I think I provided an example of this message in the review, btw13:04
niemeyer<fwereade> Ensemble environment is not accessible: Machine i-foobar may not be ready: Connection timed out13:04
niemeyerThis message, I mean13:04
fwereadeniemeyer: yep, seems reasonable, I think I misread exactly what you were after13:05
fwereadeniemeyer: and, yay, code to delete :D13:05
niemeyer"Can't connect to machine %s (perhaps still initializing): %s"13:06
niemeyerfwereade: This will work regardless of context13:06
niemeyerfwereade: The message in your quote mentions the environment not being accessible, which has assumes things 13:07
fwereadeniemeyer: I should point out that ProviderInteractionError uses That: Nested: Style13:07
niemeyerfwereade: Hmm.. what's the outside message prefix?13:08
niemeyerfwereade: (wondering if we can drop it)13:08
fwereadeniemeyer:         return "ProviderError: Interaction with machine provider failed: %r" % self.error13:08
=== otubo[AFK] is now known as otubo
fwereadeniemeyer: ...and we expect PIE to wrap a range of other possible errors, I think, which may themselves Do: That13:09
niemeyerfwereade: That's not very nice13:09
niemeyerfwereade: That was kind of ok in the original context13:09
fwereadeniemeyer: I think we can certainly lose the ProviderError: prefix13:09
niemeyerfwereade: ProviderInteractionError was used for wrapping13:10
niemeyerfwereade: Agreed13:10
niemeyerfwereade: Ugh.. and it uses repr13:10
niemeyerfwereade: This feels like an overlook13:10
fwereadeniemeyer: OK, I'll see what I can do with that13:10
niemeyerfwereade: I think we can remove this entirely13:11
niemeyerfwereade: The wrapping, that is13:11
niemeyerfwereade: We shouldn't be wrapping our own error messages13:11
niemeyerfwereade: Unless we actually have something interesting to say, of course13:11
niemeyerfwereade: Which is not the case.13:11
fwereadeniemeyer: I think PIEs tend to have been tested with assertIn("blah", str(error))13:11
fwereadeniemeyer: I'll look for assertIns and make them assertEqualss, which should then make the nasty messages stick out13:12
niemeyerfwereade: If we wrap a message from e.g. S3 into a PIE, we should add a prefix at the wrapping spot, if at all13:12
niemeyerfwereade: This may be more work than you're looking for13:12
niemeyerfwereade: I'd just fix the messages themselves and fix whatever breaks13:12
fwereadeniemeyer: I'll start a stacked branch and at least do a search, see how heavyweight it looks13:13
niemeyerfwereade: Cool, thanks13:13
fwereadeniemeyer: killing launch_machine is pretty low-risk/low-noise, though, I'll do that inline first13:13
fwereadeniemeyer: er, launch_time13:15
niemeyerfwereade: Superb13:15
pindongahi, just wanted a quick heads up14:07
pindongais ensemble still working only with ec2?14:07
pindongaor is it possible to use it with vms, like Vagrant , for example14:07
niemeyerpindonga: Hey14:16
niemeyerThere's good work in progress to make it work with physical machines14:16
niemeyerpindonga: and local deployments too14:16
jimbakerfwereade, 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 fixed14:19
jimbakerwhen merging branches into trunk14:19
fwereadejimbaker: whoops, sorry14:20
fwereadejimbaker: I'll try to remember14:21
jimbakerfwereade, no worries14:23
fwereadeniemeyer, 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
niemeyerfwereade: 2 sounds sensible.. 1 feels strange14:27
niemeyerfwereade: Provider*Interaction*Error was, again, supposed to wrap interaction errors with the provider that we didn't expect 14:28
fwereadeniemeyer: if I fix 2, I'm happy14:28
niemeyerfwereade: MachinesNotFound may not be an error in the provider, but on our own data about it14:29
fwereadeniemeyer: yep, makes sense14:29
niemeyerfwereade: It's a ProviderError, but a well understood one14:29
niemeyerfwereade: I hope we kill ProviderInteractionError entirely at some point14:29
fwereadeniemeyer: cool14:30
fwereadeniemeyer: I'll be making sure the existing except PIEs also catch PEs in the errors branch I think14:30
fwereadeniemeyer: feels like a really bad idea to let that linger14:31
niemeyerfwereade: Sounds good14:31
fwereadeniemeyer: cheers, I'll just let it all bed in for a few minutes14:32
_mup_ensemble/expose-cleanup r314 committed by jim.baker@canonical.com14:41
niemeyerFolks, 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:54
_mup_ensemble/formula-state-with-url r314 committed by kapil.thangavelu@canonical.com14: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 param14:56
hazmatniemeyer, cheers14:58
pindonganiemeyer, anything I could try out (re: local deployments)15:07
hazmatpindonga, not at the moment, its actively being developed for our next internal release milestone mid september.15:12
pindongahazmat, 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
hazmatit will be in the ppa ensemble roughly around then15:13
pindongaI want to be able to use ensemble in the future15:13
pindongabut since I need this now, I guess puppet+something else will have to do15:13
hazmatpindonga, atm ensemble really only works against ec215:13
pindongathx anyway15:14
hazmatpindonga, 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:14
pindongaI'll take a look again in a month then :)_15:15
RoAkSoAxfwereade: ping15:20
fwereadeRoAkSoAx: pong15:21
fwereadeRoAkSoAx: how's it going?15:21
RoAkSoAxfwereade: pretty goo, and you? heard you got stuck in chicago on the weekend?15:21
fwereadeRoAkSoAx: yeah, it was a bit of a hassle :)15:22
fwereadeRoAkSoAx: all good now though15:22
fwereadeRoAkSoAx: are you in a position to do some reverification?15:24
fwereadeRoAkSoAx: we're only 3 merges away from trunk now :)15:24
RoAkSoAxfwereade: yay!! and will do later today15:24
RoAkSoAxfwereade: i'm finishing some stuff up with cobbler/arm and once that's done i'm free15:24
fwereadeRoAkSoAx: awesome!15:24
fwereadeRoAkSoAx: how's that going?15:25
RoAkSoAxfwereade: pretty good, just patching cobbler, and have to write another small fix and it iwll be good to go15:25
RoAkSoAxfwereade: btw.. what branch of yours should I be using?15:25
fwereadeRoAkSoAx: 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 through15:25
fwereadeRoAkSoAx: can you wait an hour or so? I'll make sure I've done it before I stop for the day :)15:26
RoAkSoAxfwereade: sure, take your time15:28
hazmatfwereade, so the base of provider-base-machine is provider-base-launch-machine?15:30
fwereadehazmat: 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 PB15:31
hazmatic, so the base is still trunk15:32
fwereadehazmat: gaah: s/from the PBLM review/from the PB review/15:32
fwereadehazmat: yep15:32
fwereadehey, is it team meeting time?16:01
hazmatfwereade, i though that was tomorrow16:03
fwereadehazmat: that would be quite convenient as it happens :)16:04
fwereadehazmat: thanks for the review btw 16:04
hazmatfwereade, np.. great stuff16:06
fwereadehazmat: I try :)16:06
hazmatniemeyer, 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:11
fwereadehazmat: thanks 16:12
hazmatthe 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 cycle16:12
fwereadejimbaker: curses, I included the bug and reviewers, and forgot the branch :/16:12
hazmatfwereade, np.. was fun to script it with the launchpad api16:12
_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:18
_mup_Bug #828152 was filed: default formula config values not available to hooks <Ensemble:New> < https://launchpad.net/bugs/828152 >16:27
fwereadelater all16:28
hazmatfwereade, cheers16:35
hazmatjimbaker, 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
hazmatits something unrelated to feature dev, that we need for the release16:39
jimbakerhazmat, sure, looks like i would learn something fun16:39
jimbakerin terms of working with launchpad16:39
hazmatjimbaker, sadly the lp integration there is pretty minimal16:59
hazmatjimbaker, are you going to be enabling a runner that will do functional tests?16:59
hazmatjimbaker, i'm looking at some of the ftest outstanding bugs, and wondering if they should be on the eureka milestone16:59
_mup_ensemble/machine-agent-uses-formula-url r313 committed by kapil.thangavelu@canonical.com17:08
_mup_merge predecessor17:08
_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:13
SpamapShazmat: dublin is over, right?17:15
jimbakerhazmat, ftest should be on the eureka milestone17:17
jimbakeras well as part of some sort of CI, presumably using jenkins17:17
jimbakerbuildbot would also be ok, but jenkins has much better reporting17:18
hazmatSpamapS, it is17:23
hazmatjimbaker, jenkins is also a bit easier to setup imo17:23
SpamapSIf only canonistack's S3 worked, it would already be running there. ;)17:23
SpamapSActually I'm not sure canonistack is going to work.. 1.5GB isn't really enough for all those logs and graphs. ;)17:24
jimbakerhazmat, sounds good - i haven't done either setup, but i was very impressed w/ working w/ jenkins/hudson in the past17:24
* SpamapS is thinking maybe that should be his Ensemble Audition candidate. :)17:24
jimbakerSpamapS, sounds like a good use of ensemble17:25
m_3SpamapS: can canonistack point to real S3?17:25
jimbakerto self monitor17:25
m_3at least temporarily17:26
_mup_ensemble/verify-version r325 committed by jim.baker@canonical.com17:26
_mup_Merged trunk & resolved conflict17:26
m_3or just external swift17:26
hazmatjcastro 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:26
hazmatjcastro, actually that looks more like a trivial17:27
SpamapSm_3: no because the auth details would be different17:28
hazmatjcastro, i'll cowboy that in17:28
hazmatjimbaker, bcsaller1, niemeyer  can i get +1 on this trivial, http://bazaar.launchpad.net/~jorge/ensemble/docfix-instance-type/revision/26617:28
m_3gotcha... wasn't sure if we could configure separate S3_URL from ec2 endpoint for ensemble17:29
=== bcsaller1 is now known as bcsaller
SpamapSm_3: been there, tried that. ;)17:29
m_3it's really about the image store though17:29
jimbakerhazmat,taking a look17:29
jimbakerhazmat, +1 on the trivial17:30
bcsallerhazmat: lgtm too17:30
jcastrohazmat: ah yeah I had forgotten about that, I was learning the docs and took an opportunity to do a quick fix.17:33
_mup_ensemble/trunk r320 committed by jim.baker@canonical.com17:36
_mup_merged verify-version [r=niemeyer,hazmat][f=825398]17:36
_mup_Store ensemble protocol version in /topology znode to ensure all17:36
_mup_topology using ops failfast with IncompatibleVersion if mismatch.17:36
_mup_ensemble/trunk r321 committed by kapil.thangavelu@canonical.com17:38
_mup_[trivial] clarify valid values ec2 provider option default-instance-type [r=bcsaller,jimbaker][a=jcastro]17:38
_mup_ensemble/trunk-merge r276 committed by kapil.thangavelu@canonical.com17:43
_mup_merge trunk17:43
_mup_ensemble/security-policy-with-topology r326 committed by kapil.thangavelu@canonical.com17:43
_mup_merge trunk and resolve conflict17:43
_mup_ensemble/security-agents-with-identity r314 committed by kapil.thangavelu@canonical.com17:50
_mup_resolve conflict and merge17:50
_mup_ensemble/states-with-principals r326 committed by kapil.thangavelu@canonical.com17:53
_mup_remove merge conflict files that got added.17:53
=== otubo is now known as otubo[AFK]
_mup_ensemble/expose-cleanup r315 committed by jim.baker@canonical.com18:18
_mup_Merged trunk & resolved conflict18:18
_mup_ensemble/expose-cleanup r316 committed by jim.baker@canonical.com18:32
_mup_Fixes due to provider refactoring18:32
=== otubo[AFK] is now known as otubo
* niemeyer waves19:57
niemeyerhazmat: I started going in the direction we discussed for gozk last night, and suddenly a feeling of approach-rightness stroke me..19:59
niemeyerhazmat: I have to say it's really weird the way zk works by default20:00
niemeyerCan't imagine people writing reliable software would want this20:00
niemeyerIn the specific sense of watch vs. CONNECTING/ASSOCIATING events20:00
niemeyerIt'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:01
hazmatniemeyer, indeed its noise to most apps20:08
hazmatniemeyer, my short term memory must be really bad, i don't recall discussing gozk last night20:09
hazmatniemeyer, bcsaller, jimbaker also reminder we've got our weekly team meeting tomorrow20:11
niemeyerhazmat: We didn't.. I just felt in the mood to fix it after the previous talk we had a while ago20:11
hazmatah.. right, previous discussions about gozk and session events, gotcha20:12
_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:14
_mup_ensemble/expose-cleanup r317 committed by jim.baker@canonical.com20:26
_mup_Partial fix of mock expectations in shutdown tests20:26
_mup_ensemble/expose-cleanup r318 committed by jim.baker@canonical.com21:31
_mup_Mocking on describe_instances going through state transitions21:31
_mup_Bug #828378 was filed: handle ec2 instance quotas <Ensemble:New> < https://launchpad.net/bugs/828378 >21:54
hazmatbcsaller, niemeyer so does an lxc sf mini-sprint still sound good?21:56
bcsallerhazmat: yes, did something change?21:57
hazmatbcsaller, just wanted to confirm21:58
=== otubo is now known as otubo[AFK]
niemeyerhazmat: Absolutely22:02
niemeyerhazmat: Makes a lot of sense22:03
hazmatniemeyer, great22:04
_mup_Bug #828411 was filed: relation status shows "up" before relation hooks complete execution <Ensemble:New> < https://launchpad.net/bugs/828411 >23:16
jimbakerm_3, bug 828411 is interesting - certainly not at a granularity that we currently track as you note23:40
_mup_Bug #828411: relation status shows "up" before relation hooks complete execution <Ensemble:New> < https://launchpad.net/bugs/828411 >23:40
m_3jimbaker: yeah, main use-case is testing at the moment23:42
jimbakerm_3, the only thing that really gives us a fairly comprehensive trace of the system state are the logs23:42
m_3but this should be simple and it's definitely something you'd expect the framework to tell you23:43
jimbakermaybe we can push more info into ZK, not certain23:43
m_3especially when it comes to more automation23:43
jimbakerm_3, the info being reported by status is actually is what is driving hook execution23:44
m_3might surface more with user-defined hooks or something23:45
m_3right now it's just a nice-to-have23:45
jimbakerm_3, sure, definitely will think about it. i just wonder if we can extract more value from logs23:45
m_3but seems like it would be important for state consistency going forward23:45
m_3logically it's two different states23:46
m_3(haven't taken the time to figure out a good solution... just starting the conversation with the bug)23:46
jimbakerm_3, it's possible that the shared scheduler mentioned in UnitRelationLifecycle would benefit from this23:47
jimbakerin terms of sharing more state through ZK,  which status could pick up23:48
jimbakerthe shared scheduler being something not implemented23:48
jimbakerto my knowledge, the unit lifecycle is not recorded in ZK, but only in memory in the unit agent23:49
m_3hmmm... I'll have to look23:49
jimbakeri don't know dev plans for this. maybe to be addressed in the go rewrite, maybe earlier23:50
m_3kinda almost sits at the same level of user-defined hooks... user-defined events... user-defined states23:53
m_3that's probably what it should get lumped with23:53
m_3not sure23:53
jimbakerm_3, currently they are separate things, including what i would understand user-defined things to be23:57
jimbakerm_3, but where they could intersect is on the scheduling23:58
jimbakeralso it's possible that user-defined could be meaningful on a relation, so that it would expand beyond settings23:59

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!