[14:16] Hmm.. time to sort out UDS arrangements now that I have a passport again [15:52] hazmat: Good morning [15:53] niemeyer, good morning! [15:53] hazmat: How's the upgrade stuff coming? [15:54] hazmat: Just trying to get a grasp of what we'll be presenting at UDS, etc [15:54] niemeyer, pretty good, i finally got the workflow stuff figured out, and i've got some of that coded out, the actual mechanism was pretty easy, just figuring out error conditions and recovery took some time [15:54] hazmat: Interesting, cool [15:55] hazmat: So how does the time frame feel for you? [15:55] niemeyer, upgrade will be done by then, i can probably fit one more feature on my plate.. or a bunch of useability things [15:55] shutdown with warning, some more sample formulas, ensemble scp.. etc [15:56] hazmat: Nice, cool.. I think that'd be best indeed [15:56] hazmat: Our formulas need some love indeed [15:56] niemeyer, i setup a monitoring / alerting system over the weekend for some folks.. i'm starting to think we need a new abstraction around the 'machine policy'/formula [15:57] hazmat: Interesting, what kind of alerting system was that? [15:57] niemeyer, just munin and nagios [15:57] Ok [15:57] hazmat: Yeah, we have to discuss the whole placement idea [15:57] i tried out this nice visualization on collectd which was pretty slick.. scripted it all with fabric.. their probably going to move over to chef at some point [15:58] hazmat: What about Ensemble? [15:59] niemeyer, i've discussed it with them, their interested, but their not up for living on the bleeding edge [15:59] hazmat: Understandable [16:02] niemeyer, still one of the nicer collectd visualizations i've used.. http://ec2-174-129-219-53.compute-1.amazonaws.com:9292/profiles/shotgun+graph [16:02] all jquery flot ui [16:03] https://github.com/auxesis/visage [16:03] * niemeyer looks [16:05] Nice [16:21] niemeyer: Hey Gustavo o/ [16:21] Are you ok with the weekly progress meeting [16:21] the one I mentioned in email [16:21] kim0: Hi there [16:21] can we do it on Wed for example [16:22] kim0: Hmmm, but I thought we already had a weekly meeting? [16:23] niemeyer: the server team one ? [16:23] kim0: No, the weekly meeting we have in 37 minutes :-) [16:23] I'm talking about a public irc meeting [16:24] niemeyer: I'm in a call .. sorry for not being too focused [16:24] kim0: Ok, let's talk latter then.. I have to have lunch too [16:24] sure thing [16:28] Laters === niemeyer is now known as niemeyer_lunch === niemeyer_lunch is now known as niemeyer [16:59] kim0: Meeting time? === deryck is now known as deryck[lunch] [17:10] niemeyer: ew sorry, suddenly my internet is at 60% packet loss [17:10] * kim0 recovering [17:25] kim0: No worries [17:25] kim0: Regarding the weekly meeting you were proposing earlier, what kind of content would you like to have on it? [18:07] hazmat: Are you subscribed to the public Ensemble list? [18:07] niemeyer, i believe so [18:07] * hazmat checks [18:07] hazmat: Ah, I guess you've seen my answer [18:08] niemeyer, yeah.. i had my reply drafted for a while but needed to transfer from thunderbird to sup [18:08] :-) [18:08] hazmat: Might be cool to send the same msg to the public one too [18:08] niemeyer, oh.. didn't realize it was private only [18:09] it's ensemble@lists.ubuntu.com - i thought that was public [18:10] jimbaker, it is [18:11] jimbaker, the original email came in @lists.canonical.com which is private, and my reply wen there as well [18:14] hazmat, ok, but in my case i see the reply to the list mentioned above [18:14] jimbaker: My reply, not his [18:14] hmm.. there are two replies in two different threads [18:15] Yep [18:15] gustavo is referring to my reply in the 1st time user thread which was private [18:15] er. on the internal list.. i just forwarded it to the public one [18:16] hazmat, yeah i see the distinction now - ahmed's vs clint's [18:17] hazmat: I've mostly refactored out a YAMLState object which handles some of the issues we talked about re retry change but allowing BadVersionErrors to bubble through would change semantics and I'm not sure what that we mean in the live system yet === deryck[lunch] is now known as deryck [18:29] bcsaller, awesome! [18:29] bcsaller, a base class or utility that generically handles dictionary merges for retry change sounds like a good win [18:30] Its a state object you bind to the node and then delegate to [18:30] pseudo-code:: hook.get(): returnValue(relation_node.get()) [18:30] bcsaller, as for the error condition, its handling its going to be context sensitive. [18:31] yeah, I'll get this in its own branch and push it so we can talk about the same thing, I need a little feedback before its ready for a merge [18:32] bcsaller, sounds good [18:36] <_mup_> ensemble/yaml-state-node r183 committed by bcsaller@gmail.com [18:36] <_mup_> initial work on YAMLState object [18:36] niemeyer: hey ... my internet is unchocked again :) [18:37] niemeyer: so I was talking about the email "Ensemble community venues" [18:37] basically would like to setup a weekly irc meeting where the team mentions progress about ensemble development [18:37] this should pick up community members going forward [18:38] Since the conversation drifted to whether or not we should freeze formula definitions .. [18:38] would be great if you and the team could reply letting me know whether you guys agree on that [18:38] hazmat: lp:~bcsaller/ensemble/yaml-state ensemble/state/utils.py when you have a minute to talk it over, doesn't have to be now [18:39] kim0: I don't have any email with that subject (or something related) coming from you [18:39] niemeyer: it's on the public list [18:39] niemeyer: everyone else replied [18:39] niemeyer: kim0@ubuntu.com [18:40] kim0: "from:kim0@ubuntu.com venue" returns an empty list to me [18:40] niemeyer: https://lists.ubuntu.com/archives/ensemble/2011-April/000020.html [18:41] niemeyer: your reply to that would great .. nothing urgent .. tyt [18:41] kim0, i agree that it makes sense, post budapest.. i've been keeping an itinerant ensemble development newsletter going, but i've been waiting for things to queue up before writing it [18:41] would be* [18:41] kim0: I never got that [18:41] niemeyer: weirdo ?! [18:41] hazmat: I'm fine with post budapest [18:41] niemeyer: spam filters ? [18:43] I have no idea.. I'm a member [18:43] kim0: I got your previous message too [18:43] yeah weird indeed [18:43] niemeyer: you didn't even get replies from others [18:44] Nope [18:45] I didn't get Kapil's fwd yet either [18:45] quite strange [18:46] just forwarded you the thread [18:46] kim0: Thanks, I'm looking through the archives [19:01] <_mup_> ensemble/unit-agent-formula-upgrade r199 committed by kapil.thangavelu@canonical.com [19:01] <_mup_> additional documentation of the steps, clear upgrade flag before proceeding with ugprade work [19:03] niemeyer, could you have a look at my comments regarding the state-machine branch? should i put it back into review? re needs information status on the merge. [19:03] hazmat: Yeah, please put it back [19:04] hazmat: That WIP <=> Needs Review back and forth is a neat way to very easily know who's got the ball ATM [19:05] niemeyer, agreed, sounds good. [19:05] agreed on the WIP/NR state transition, it just works [19:09] hazmat: We'll have to talk a bit about the transition stuff.. it feels like the simplicity of a state machine is derailing a bit [19:09] niemeyer, yeah.. i'm diagramming it at the moment [19:10] niemeyer, i'm not sure i need the action handler [19:10] niemeyer, it looks like i'll end up structuring the upgrade transitions as a transtion from state X to state X [19:10] with the success transition to follow [19:11] the question is what's the best handling of an upgrade-error [19:11] hazmat: Yeah, loops are good abstractions in state machines [19:12] hazmat: We can put it in an upgrade-error state, but in that sense it feels a bit like we're doing the opposite of what we should do [19:12] hazmat: What do we want to happen? [19:12] hazmat: We shouldn't be talking about the state machine, but about the goal [19:12] hazmat: The state machine will reflect it [19:12] niemeyer, agreed [19:13] We might: a) Stop the unit world; or b) Log and move on [19:13] the question is what's the best handling of an upgrade-error.. do we want to re-exec the upgrade hook, do we want to continue with the last known pre-ugprade step.. or just have a definite procedure.. of redo install-start [19:13] hazmat: Reexecuting implicitly feels bad [19:13] niemeyer, sure, we do both a+b [19:14] hazmat: Looking at packages, upgrade hooks are not really idempotent in most cases [19:14] niemeyer, the case i'm asking about is someone trying to recover manually an upgrade error [19:15] do we just expose transition something like transition to state("x") where x is running, stopped? [19:16] more generically do we have a definite sequence of hooks we want to have happen, or do we want let the user specify hooks to run or state to try and achieve. [19:17] hazmat: Seems like too much knowledge would be needed [19:17] hazmat: We need something people can more easily reason about [19:18] hazmat: E.g. "ensemble recover unit/1" simply unblocks the unit and puts it back in the state the last transition was trying to achieve [19:18] hmm [19:19] hazmat: Or perhaps, "ensemble resolved unit/1" [19:19] niemeyer, looks good [19:19] niemeyer, i prefer recover, it suggests actions to be performed, rather than noting something already done. [19:19] hazmat: Since it's not really an action.. it's simply informing that "I have resolved the issue" [19:19] hazmat: Exactly, the intention is the latter [19:19] hazmat: We won't be doing the action.. the user is supposed to resolve the problem himself [19:19] niemeyer, hm... so your suggesting we don't execute the transition? [19:20] for failure recovery [19:20] hazmat: Right, not by default at least [19:20] hazmat: We can have [19:20] hazmat: ensemble resolved --retry [19:20] niemeyer, what about an exposing an easy way to run an abitrary hook? [19:21] also useful for the debugging hooks scenarios [19:21] hazmat: Feels pretty invasive.. formulas are not built with the idea that hooks can be run in arbitrary moments [19:21] hazmat: The user can go into the machine and run it manually, if they wish to [19:21] niemeyer, this is more an advanced tool for formula authors or motivated users. [19:22] niemeyer, not in the proper environment without a debug running which needs hook execution to trigger fully [19:22] hazmat: Sure, we can have a debug command for that, no worries with that [19:22] hazmat: But this should not be documented anywhere, if you see what I mean [19:22] hazmat: This is far from a workflow we want to encourage [19:22] simulating the context for relation hooks might be a bit strange there too [19:22] hazmat: Yep [19:23] niemeyer, i see your point yeah its not something we want to expose.. users shouldn't need to care about this... but in the real world they often do ;-) [19:23] hazmat: That's why "ensemble resolved" feels more "grounded".. If a hook exploded in-flight, we have no idea why [19:23] hazmat: Let the user debug it and then type "ensemble resolved" to restore normal operation [19:24] hazmat: They don't, actually.. I don't see people typing "postrm" manually [19:24] Or postinst... [19:24] niemeyer, true, but the formula-author might having inspected its logs, and fixed the hook, and might just want to run 'dpkg' again for example [19:24] the --retry works [19:24] hazmat: Yes, they remove and reinstall the package.. that works for us too :) [19:25] niemeyer: just replied .. letting you know in case you don't get it [19:25] hazmat: So I guess, going back to the original point, we have to introduce "ensemble resolved", and then make an error transition to upgrade-error or the such [19:26] * kim0 mostly afk now on [19:26] hazmat: and then transition back with resolved [19:26] kim0: I got it [19:44] niemeyer: hmm, what does driving that meeting entail? Is it like the server meeting chair [19:44] kim0: It is about taking care of organizing it, collecting topics for it, and in general ensuring it stays sensible and useful to everyone involved. [19:45] sounds good [19:45] No problem, volunteering :) [19:46] kim0: Awesome, thanks! [19:46] niemeyer: when do we start? this week or after udso [19:47] kim0: You tell me.. I'll be happy to attend it this week already :) [19:50] niemeyer: well I have no problem announcing the meeting publicly and starting from this week. As mentioned don't expect much attendance for the first period, but everything should be kept public from day one. Mostly it's gonna be about team members talking the current state of ensemble ..etc, and if you're ok with it, I'm definitely ok having it this week [19:50] kim0: Sure, let's do it then [19:50] awesome .. deal [19:50] kim0: It's important to be a bit prepared for it [19:51] kim0: Rather than simply inviting us to speak [19:51] Tips are welcome [19:51] kim0: You can always keep an eye on what's happening here: http://people.canonical.com/~niemeyer/budapest.html [19:51] kim0: If you participate in the team in Launchpad, you can also watch reviews passing by [19:52] kim0: So it should be very easy to keep track of what the most interesting conversations/actions happening [19:52] well yeah, except non devs like me don't particularly enjoy reading patches :) [19:52] but yeah sure [19:52] kim0: Yeah, I'm not suggesting that [19:52] kim0: Patches always have textual descriptions accompanying them, and a bug attached [19:52] * kim0 nods [19:52] <_mup_> ensemble/trunk-merge r184 committed by kapil.thangavelu@canonical.com [19:52] <_mup_> merge trunk [19:53] kim0: You should also feel free to poke people that don't describe what they're doing well. [19:53] Ok ... so making sure devs can speak in plain English [19:53] kim0: I'll be happy to explain better something I slack when describing in a review, for instance. [19:53] I can do that :) [19:53] kim0: Right, exactly [19:53] got you [19:53] kim0: Our docs also have been improving a lot [19:54] kim0: Features should generally be accompanied by a doc patch/improvement [19:54] kim0: If they are not, that's a good thing to poke about [19:54] I'm planning on contributing to that soonish too [19:54] * niemeyer pokes jimbaker ;-) [19:54] Yes.. excellent point [19:54] niemeyer, poked [19:54] kim0: If you can't figure what's happening, no one else will [19:55] True .. got your point [19:55] niemeyer: thanks for tips .. we'll definitely improve with time as well [19:56] kim0: You're welcome, and thanks for organizing this [19:56] rock n roll the service management space :) [19:56] * kim0 afk for real this time .. :) [19:59] btw does Ensemble have a logo/mascot [19:59] or is someone working on one rather [20:01] kim0, definitely.. perhaps a musical instrument on a cloud background [20:01] hazmat: definitely means someone is working on it ? or you'd love to :) [20:01] kim0, love to have it [20:02] ah hehe [20:02] I'd love to .. would give a nice visual ID [20:02] http://en.wikipedia.org/wiki/File:Zentralfriedhof_Vienna_-_Boltzmann.JPG [20:03] related to the other meaning of "canonical ensemble" ;) [20:03] is that blotzman the scientist [20:03] kim0, yes [20:03] jimbaker, yeah.. looking at http://en.wikipedia.org/wiki/Machine_learning_ensemble i almost think of a mathematical E symbol over a cloud might be cool as well [20:03] of "constant" fame hehe [20:03] we need a bunch to choose from :) [20:04] okie dokie .. I'll see who I can bribe to work on this :) [20:07] hazmat, it is cool how such ensembles do perform nicely - similar i guess to doing metanalysis of study results to boost signal [20:08] bcsaller, hazmat, niemeyer - i really want to have lunch. should we do our standup? [20:09] jimbaker: Sure, let's do it [20:11] Or maybe not? Where's everyone? :) [20:12] looks like it's just hazmat who is not visible to me [20:12] jimbaker: Nevermind.. go have your lunch [20:13] jimbaker: We can catch up later/tomorrow [20:13] just the time of year when DST ensures this standup window falls right in the middle of lunchtime [20:13] ok, sounds good, i'm making progress [20:15] jimbaker: We should also move the standup if it's right in your lunch time [20:15] jimbaker: I'm sure we can find another suitable time that works for the three of us [20:16] if we start on time (75 minutes ago), it's fine. it's just the variance on the window time that makes me starve :) [20:18] doh.. sorry got a snack [20:18] also making progress [20:18] I am as well [21:07] <_mup_> ensemble/state-machine-enhancements r203 committed by kapil.thangavelu@canonical.com [21:07] <_mup_> support for firing transition with fuzzy match on transition [21:15] <_mup_> ensemble/unit-agent-formula-upgrade r202 committed by kapil.thangavelu@canonical.com [21:15] <_mup_> lifecycle integration of upgrade-formula hook [21:31] apport concurrent report productivity kill [21:35] niemeyer, irc as other medium or skype? [21:36] hazmat: Skype would probably work better [21:36] niemeyer, ready when you are [21:37] hazmat: Cool, just a moment [21:39] hazmat: I'm up [21:45] niemeyer: re-reading my post, it may have been a bit dramatic and overriden my point that I don't feel comfortable suggesting people start playing with it without some kind of release strategy. [21:55] hazmat: ensemble upgrade --force [21:55] hazmat: ensemble resolved --retry [21:59] hazmat: id + "_upgrade_" + id [22:02] SpamapS: So, off meeting [22:02] SpamapS: We just have to be honest about the project state [22:02] SpamapS: We've been doing pretty well in terms of compatibility so far [22:03] SpamapS: and it feels like the ground we're building is quite solid [22:03] SpamapS: But there's no point in making blank statements right now.. the project works at all for a couple of months [22:03] biab, need to take my daughter to her doctor checkup [22:03] SpamapS: If we decide to make changes, there will be some very good background to them, and you'll be in the loop [22:05] niemeyer: Indeed I think its time to bring on early adopters who may actually use it for something... its only going to be *very* aggressive users who will use it w/o an official release. [22:08] SpamapS: We'll have releases.. we're just walking towards it [22:08] SpamapS: We're working on important features right now which are also critical for these same users which care about the release [22:10] Alright, I'll step out for some exercising.. bbl likely === niemeyer is now known as niemeyer_away [22:10] niemeyer: sounds good. Glad we're on the same page then. :) [22:24] <_mup_> ensemble/state-machine-enhancements r204 committed by kapil.thangavelu@canonical.com [22:24] <_mup_> backout of matching or alias tranasitions [23:59] something quite strange