#juju-dev 2012-06-01 <hazmat> davecheney, the pa needs a lock around a the ma <hazmat> er. around the machine state its processing <hazmat> to allow for concurrent pa <davecheney> hazmat: yes <davecheney> hazmat: even simpler the PA stores the provider instance id into the state once it is known * hazmat tries to catch up the on the conversation <davecheney> which can be used as a sentinal to say 'hey, at least I started this vm, it might be dead now, but I tried' <hazmat> davecheney, sure.. that's what it does currently <davecheney> that would be problematic with multiple PA's all racing to provision machines <davecheney> TBH, i haven't thought about how to solve that yet <hazmat> its just a per machine lock op lock, or a even a queue.. <davecheney> hazmat: would that be implemented in ZK ? <hazmat> davecheney, sure <davecheney> finger in the air, maybe that could be done with a new content node /machines/machine-X/state <hazmat> there's recipes for building all of these structures for zk on the zk wiki.. the py zk lib (txzk) has several implemented.. <davecheney> i;ll go check that out <hazmat> /machines/machine-x/lock i would think <davecheney> but i'll have to moderate that with gustavo's desire to not be too closely tied to SK <hazmat> or even /machines/provisioning-queue/ <davecheney> ZK <davecheney> hazmat: sounds like maildir * hazmat giggles <hazmat> well he wants to maintain the current client api <hazmat> so assuming the guarantees are the same, the principles should carry over.. <hazmat> mongo is consistent and has atomic ops.. <davecheney> it's on my pondering queue, but right now we have 0 PA's, so i'm not really focusing on having N PA's yet <hazmat> doing locks, and queues with it is straight forward <hazmat> sure.. <davecheney> hazmat: that might be simpler <hazmat> the goal seems to be to get to the parity.. <davecheney> in mongo, when the client disconnects, do the locks go away ? <hazmat> and then flip the bits ;-) <davecheney> my concernt with lock files and shit is recovering from a stale lock <hazmat> davecheney, you record the client and a timestamp on the lock.. <hazmat> davecheney, have a look at the store code.. <hazmat> it has some locking <davecheney> i'll do so <davecheney> hazmat: in python, what was the result of the tcp connection to zookeeper going away ? <davecheney> did the agent exit, or did you try to recover ? <hazmat> davecheney, it recovers <hazmat> davecheney, there's a connection wrapper that basically creates an immortal connection <davecheney> where is that handled ? in the zk library, by trying other replicas ? <davecheney> ahh right <hazmat> davecheney, it handles transient disconnects and session expirations <hazmat> for transient disconnect the reconnection is handled by the libzk <hazmat> for session expirations its handled by the wrapper <hazmat> also triggers watches on session reconnect, its a fairly straightforward impl.. http://bazaar.launchpad.net/~juju/txzookeeper/trunk/view/head:/txzookeeper/managed.py <hazmat> re mongo.. here's a simple queue impl i wrote with locking.. effectively each client has to be cooperative about breaking stale locks.. their easy to detect.. and the breaking is just part of the queue impl. <hazmat> rog's upgrade solution is odd.. <hazmat> i guess that makes sense.. ma responsible for code upgrade, others sync on that <davecheney> hazmat: what if the tools were a .deb, upgrades would be as simple as something running an apt-get upgrade on every machine <hazmat> davecheney, debs are frought with problems in this context <hazmat> davecheney, across multiple versions of the distro... needs an apt repo maintenance.. <davecheney> hazmat: sure, i guess that was a nieve solution <hazmat> the actual download isn't a huge problem <hazmat> its just trying to ensure the coordination around it <davecheney> i'm just wondering if we're reinventing dpkg hooks <hazmat> davecheney, how does apt handle multiple versions avail.. <hazmat> it picks the latest.. <davecheney> indeed <hazmat> by default anyways.. <hazmat> dpkg hooks aren't really about cross machine coordination <hazmat> the whole thing becomes much more interesting, and indeed.. simpler when you consider it from a db upgrade perspective <davecheney> no, really just for poking upstart <davecheney> 'Everyone! Switch to version X! <hazmat> where you need to everything having the new code ready.. you do a centralized db upgrade.. and then restart everything.. <davecheney> i like the use of the state for signalling things like that <hazmat> indeed.. that's why we have zk.. <wrtp> davecheney: morning! <wrtp> TheMue: yo! <TheMue> davecheney, wrtp, fwereade: Morning. <wrtp> fwereade: hey! <davecheney> wrtp: TheMue fwereade Aloha! <davecheney> wrtp: TheMue I have questions about the state <davecheney> who is sober enough to answer them ? <wrtp> davecheney: woke up with a head full of crack after last night's recursive agent discussions... <TheMue> davecheney: Let's try it. <wrtp> davecheney: i'm sober enough but i might not know the answers <davecheney> so, in the latest propose for the PA, gustavo had this concern <davecheney> https://codereview.appspot.com/6250068/diff/5004/cmd/jujud/provisioning.go#newcode37 <davecheney> TheMue: wrtp after trying all day, I can't actually make the state break, that is, ever return an error <davecheney> nor can I observe any of the watchers close on me through rough handling of the zookeeper server <wrtp> davecheney: that's true currently, but might not be in the future, when we're not talking directly to zk (or zk is actually mgo under the covers) <davecheney> wrtp: yup, after talking to hazmat he said that in python they also have a wrapper than makes the state immortal and can cope with transient disconnections from the server <wrtp> davecheney: that's controversial... <davecheney> wrtp: TheMue my intention was to add a state.IsValid() method somewhere so that the PA could drop out of the loop, make another state connection and try again <davecheney> but without the ability to ever make the damn thing crap itself, it's hard <wrtp> davecheney: what would IsValid test? <wrtp> davecheney: isn't that what the channel returned from zk.Dial is supposed to do? <davecheney> wrtp: my idea was it would be set to false it an error (of the sort that GetW or ExistW give) <TheMue> wrtp: Yes, good question. <davecheney> but as I can't get it to generate an error ... <davecheney> wrtp: IsValid is supposed to detect the 'broken' Gustavo spoke of in that comment <TheMue> davecheney: That's depending on todays gozk. But as Roger said this will change (or at least wrapped as a first step). <TheMue> davecheney: In case of a broken connection the state is not invalid. It's "only" a connection error. Indeed the watcher may be notified if we don't have a mechanism to automatically reestablish it. <davecheney> TheMue: yup, i'm always planning that ZK has a limited shelf life <TheMue> davecheney: But reading and writing of the state is always life. <wrtp> davecheney: i think fwereade did some experiments around breaking zk connections, but i may remember wrong <davecheney> TheMue: so here is the logic, something is receiving from the watcher channel, and it detects channel closed, so we call Stop on the watcher to clean up <davecheney> then before going back into the loop, i need someting like state.IsValid or !isClosed() to say 'don't try this again, it won't do any better this time' <TheMue> davecheney: isDisconnected() or something like that, but please not IsValid(). <TheMue> davecheney: Because the state in ZK is still valid. <wrtp> davecheney: you should get an error from the watcher's Stop method, i think <davecheney> wrtp: yes, that is another way to do it, but is fraught with difficulties as the error might be wrapped <davecheney> wrtp: but if you're saying on _any_ error from stop we should consider the state disconnected and tear everything down <wrtp> davecheney: we should make sure that we make *sure* that a fatal error from zk is passed through in a recognisable way to the Stop return value <davecheney> wrtp: can you elaborate on what you mean by recognisable way <wrtp> davecheney: i mean that it should have a known type or a known value <wrtp> (probably the former, so we can encapslate the actual zk error) <davecheney> wrtp: that is what I was thinking too, rather than error, state.Error <wrtp> davecheney: well, *state.Error returned as an error. <wrtp> gotta go to breakfast <davecheney> wrtp: of course <davecheney> btw, did aram write Doozer ? <fwereade> hey all <davecheney> has anyone been able to sign up to the HP cloud ? <davecheney> I tried twice today, with my canonical and personal email addresses, but I haven't got a confirmation email back yet :( <wrtp> davecheney: i haven't tried <davecheney> wrtp: i emailed jorge to see if he could reach out to a tech contact there <wrtp> davecheney: gustavo says "sign up, give them your credit card details, then send me the account id and the tennant id" <davecheney> wrtp: i'm blocked at the 'sign up' stage <wrtp> davecheney: (but obviously that might be hard if they won't let you sign up!) <davecheney> it never sends me the confirmation email <davecheney> jynx! <davecheney> OT: at mailguard, our bot would mute someone if you call jynx <davecheney> it used a levenstein computation to see who to mute <wrtp> davecheney: cool <davecheney> further proof that with enough time and perl you can achieve even the most useless of things <wrtp> davecheney: i wonder if there's a go package for computing levenstein distance <davecheney> wrtp: wouldn't be hard, i don't think its very complicated to do in code <wrtp> davecheney: agreed. it's nice to be able to take stuff off the shelf though <davecheney> ask uriel <wrtp> davecheney: gotta go. have fun. <davecheney> wrtp: cya <niemeyer> Hellos! <rog> Aram, niemeyer: it'd be nice to be able to talk, eh? <Aram> heh, yeah <niemeyer> rog: Yeah.. well.. I'm just responding to Dave's email, and then we can move elsewhere to chat as well <niemeyer> fwereade: ping <fwereade> niemeyer, pong <niemeyer> fwereade: Heya, good morning <fwereade> niemeyer, and yourself :) <niemeyer> fwereade: Do you have the RT# for the juju-dev ML? <fwereade> niemeyer, it was set up this morning <niemeyer> fwereade: Oh <fwereade> niemeyer, I appear to be an administrator, which I guess I should have expected :/ <niemeyer> fwereade: Yeah :-) <fwereade> niemeyer, something wrong? <niemeyer> fwereade: No, I want to use it :) <niemeyer> fwereade: Have you subscribed people to it? <fwereade> niemeyer, not yet <niemeyer> fwereade: Ok, would you mind to do that so we can start using it? <fwereade> niemeyer, on it <niemeyer> fwereade: Subscribing the obvious candidates, and then mailing juju@ should do it <niemeyer> fwereade: Thanks a lot <niemeyer> I'll hold off sending the email to Dave to send it to the list instead <fwereade> niemeyer, added * fwereade worries that he's forgotten someone who will be mortally offended <niemeyer> fwereade: rodriguezcrystal@example.org? <fwereade> niemeyer, yeah <niemeyer> fwereade: Send an email to juju@ inviting people.. no body will be offended <niemeyer> nobody <niemeyer> fwereade: Is Aram in? <fwereade> niemeyer, yeah <niemeyer> fwereade: Superb <niemeyer> fwereade: Thanks a lot for taking care of this <niemeyer> Sending first email <fwereade> niemeyer, a pleasure :) <niemeyer> Done <niemeyer> Let's see if email still works these days ;-) * TheMue has the mail in his folder for this list, nice. <niemeyer> TheMue: ping <TheMue> niemeyer: pong <niemeyer> TheMue: I spent some time yesterday with rog and aram <niemeyer> TheMue: around the concept of relations and how they were inverted <TheMue> niemeyer: I'm listening. <niemeyer> TheMue: We got to the conclusion that the original design was actually more future proof that what we have in place in the CL now <niemeyer> TheMue: It's very hard to imagine that we'll have a single service participating in a single relation with two roles <niemeyer> TheMue: But it's not so much of a stretch to imagine that two services may participate in a relation with the same role <TheMue> niemeyer: IC <niemeyer> TheMue: E.g. a master with two slaves, two peers, etc <niemeyer> TheMue: The new design makes that unfeasible <TheMue> niemeyer: Hmm, a change from map[role]serviceKey to map[role][]sericeKey wouldn't help (as a quick thought)? <TheMue> niemeyer: With all depending changes naturally. <niemeyer> TheMue: Sounds worse than just doing what we had <niemeyer> TheMue: map[service key]stuff <TheMue> niemeyer: OK <niemeyer> TheMue: That said, hold on a moment <niemeyer> TheMue: I'll re-review the latest state of that branch.. I'm hoping we can integrate the current version, and then refactor it over <TheMue> niemeyer: The idea of William and me has been to move away from seperate AddRelation() and AddEndpoint(). So that the risk of having a relation w/o EP or only a provider or requirerer is lower. <TheMue> niemeyer: Maybe following the current model but with a new API could do this too. <niemeyer> TheMue: I don't see how that's related to the point above <TheMue> niemeyer: It's only the motivation how the change started. The model change has then rised out of a discussion (as it seems sadly with a wrong direction). <TheMue> niemeyer: So maybe the model could now better stay as it is in Py, but the API changes to reduce the risk of adding illigal relation sinks. <niemeyer> TheMue: Agreed, not suggesting further changes.. just the topology has to be adapted to invert the map <TheMue> niemeyer: OK, start a new branch based on the zk to topo renaming to change the topology first. Afterwards new branches for AddRelation() and RemoveRelation() while the two current open ones will be abandoned. <niemeyer> TheMue: Please hold on <niemeyer> TheMue: What are you abandoning? <TheMue> niemeyer: The AddRelation() and the RemoveRelation() branches. They have older branches as prerequisites. <TheMue> niemeyer: I don't know how good the newer refactoring branch then works with those two. <niemeyer> TheMue: No, please don't drop them <niemeyer> TheMue: We've spent a lot of time polishing those branches <niemeyer> TheMue: Let's get them in, and have the change on top of them <TheMue> niemeyer: Merging is now problem? <niemeyer> TheMue: Me not understand <TheMue> niemeyer: Ah, but I understand you now. You want to get both in the trunk first before I start refactoring. <niemeyer> TheMue: Yeah <TheMue> niemeyer: Am I right? <TheMue> niemeyer: Good. <TheMue> niemeyer: Otherwise I would have kept the source and then bring it in with new branches. <TheMue> niemeyer: The "new" RemoveRelation() propose will come in in a few moments, just testing. <niemeyer> TheMue: Ah, cool <TheMue> niemeyer: Aaargh, it's in, but again with a lot of file too much in the review list. <niemeyer> TheMue: Ok, can you please clean it up so I can review and unblock you? <TheMue> niemeyer: Will try. It depends on the AddRelation() proposal. <niemeyer> Aram: https://launchpad.net/mgokeeper <niemeyer> Aram: bzr branch lp:mgokeeper and profit :) <niemeyer> TheMue: The pre-requisite is merged.. it's the same problem you had last time, and the same solution as well <TheMue> niemeyer: Yep <niemeyer> TheMue: "Today this isn't done. I would like to do it in a new small branch after this <niemeyer> and RemoveRelation() are in." <niemeyer> TheMue: Ok, but please note that down as the next task after fixing the topology details <hazmat> new 'juju-dev' mailing list? <TheMue> niemeyer: Hmm, merged, pushed, proposed, everything is there. But also still those files not part of the branch. It's only that they are with one delta in rietveld while the changed file have two. <niemeyer> TheMue: You have to push the pre-req after merging trunk in it, as you did last time <TheMue> niemeyer: I've done. <niemeyer> TheMue: The diff is the diff that bazaar generates <niemeyer> TheMue: So whatever is being pushed is the actual diff between the two branches <TheMue> niemeyer: I have to digg deeper. <niemeyer> TheMue: That's all that there is to it really <niemeyer> TheMue: If you merge trunk on the pre-req, push it to Launchpad, merge trunk on the follow up, repropose, it should wokr <TheMue> niemeyer: Why the quotes around the sentence above? "Today this â¦" <niemeyer> TheMue: Because it's your sentence <niemeyer> hazmat: Yeah, William sent a note to juju@ <niemeyer> TheMue: The task should not be lost.. a few times we've said something was going to be done as a follow up and it ended up going missing <niemeyer> TheMue: So please write down to keep track this should be in the queue after the current branch and the topology changes <niemeyer> We really need an organized bug tracker that we can look at <niemeyer> Hmm.. maybe we should create a juju-core project in Launchpad <TheMue> niemeyer: Yep, missing that. Workied with it since the 90s and introduced it in several projects. It's indeed helping. <niemeyer> TheMue: LOL.. yeah :) <niemeyer> TheMue: We have a bug tracker.. it's just a mess because of the mix up of juju py <TheMue> niemeyer: So time for juju go? <niemeyer> TheMue: Hm? <niemeyer> TheMue: So, do you know the task I'm talking about above? <TheMue> niemeyer Not yet, will look into the logs. Right now I'm fighting with bzr. It says in the prerequisite as well as in the current branch that there's nothing to merge from the trunk and in the prerequisite that there's nothing to push. <TheMue> niemeyer: Drives me mad. <niemeyer> TheMue: Ok.. I'll file a bug and assign to you. <TheMue> niemeyer: Thx <niemeyer> TheMue: Have you merged trunk onto the pre-requisite? <TheMue> niemeyer: Yes. <TheMue> niemeyer: Just tried again, nothing to do. *sigh* <TheMue> niemeyer: Same in my branch. <TheMue> niemeyer: And bzr push says that there is nothing to push. <niemeyer> TheMue: Merge the pre-req onto your branch now <TheMue> niemeyer: Oh, something new, a warning about criss-cross, but everything merged successful. <niemeyer> TheMue: Yep.. that's the problem <niemeyer> TheMue: Try pushing the new content <niemeyer> and proposing it <niemeyer> I hope that works <TheMue> niemeyer: Ah, yeah, better now. Thank you. <niemeyer> TheMue: Woohay! <TheMue> niemeyer: Worked too long w/o branching. But by now I've also started to branch my private software. ;) <niemeyer> TheMue: I see you're renaming from zkRelation to topoRelation.. are tests broken at the moment without that? <TheMue> niemeyer: Without renaming it has been broken. <TheMue> niemeyer: Yes. <niemeyer> TheMue: Ok :( <niemeyer> TheMue: Trunk is being broken way too often :( <niemeyer> 382 t.RemoveRelation(relation.key) <niemeyer> 383 return nil <niemeyer> TheMue: Is RemoveRelation returning no errorr? <TheMue> niemeyer: No, it's only removing inside a map. Today it's also not checked at that point if it exists in that dir. <niemeyer> TheMue: OK <niemeyer> / Relation returns the relation with key from the topology. <niemeyer> func (t *topology) Relation(key string) (*topoRelation, error) { <niemeyer> if t.topology.Relations == nil || t.topology.Relations[key] == nil { <niemeyer> return nil, fmt.Errorf("relation %q does not exist", key) <niemeyer> TheMue: We don't want the user to be getting this error message <TheMue> niemeyer: Oh, please wait.Just seen an assert_relation there. Will add it too. <niemeyer> TheMue: The relation key is completely uninteresting as far as a user is concerned <niemeyer> TheMue: The state method should verify the state in those cases, and error early with a sensible message <TheMue> niemeyer: OK <niemeyer> TheMue: If we get an Relation from relation we should display prefixed with something saying that an unexpected action happened while doing whatever <niemeyer> TheMue: In which case the relation key might go out, but we have no idea about why it was failing since we've checked it early <niemeyer> TheMue: So it's debugging rather than something we'd like the user to be commonly looking at <TheMue> niemeyer: IC. Do you note it in the review? <niemeyer> TheMue: I'll copy & paste what I just said <TheMue> niemeyer: I have to break for lunch, wife is calling. <TheMue> niemeyer: Yes, thx. <niemeyer> TheMue: Sure, I'll see you on Monday, have a good lunhc <niemeyer> fwereade: Have you added andrewmelina? <niemeyer> fwereade: To the list? <fwereade> niemeyer, sorry, no I didn't <niemeyer> fwereade: no problem, I thought we might have missed it <fwereade> niemeyer, is that the same person as andrewsmedina at gmail? <fwereade> niemeyer, can do that now <niemeyer> fwereade: Yeah, I suspect so <niemeyer> fwereade: Thanks! <niemeyer> TheMue: https://bugs.launchpad.net/juju-core/+bug/1007373 <niemeyer> TheMue: https://codereview.appspot.com/6223055/ is still dirty <TheMue> niemeyer: So, 6223055 is cleaned up. <niemeyer> TheMue: Thanks <TheMue> niemeyer: Same problem with its prerequisite again. <niemeyer> TheMue: Yeah, I do apologize for the problem.. I should have fixed it already <TheMue> niemeyer: Gna, it's also my inexpertness with branching. So don't mind. The more often I have this problem the better I learn how to avoid it. ;) <niemeyer> TheMue: It's not actually your fault.. the pre-req support in lbox should handle that case correctly without you having to worry about it <TheMue> niemeyer: So I'm happily awaiting the next release. <niemeyer> TheMue: Review delivered, and you have a LGTM with a few trivial comments <TheMue> niemeyer: Just reading them. <TheMue> niemeyer: Thanks. <niemeyer> fwereade: You got a LGTM too <fwereade> niemeyer, sweet tyvm <niemeyer> fwereade: it's on the smaller branch, though :( * niemeyer <= cheater * niemeyer <= hungry too <niemeyer> We'll step out for lunch <fwereade> niemeyer, no worries :) <fwereade> LGTMs invariably LGTM ;p <niemeyer> Hehe :) <niemeyer> SGTM! ;) <fwereade> rog, is DefaultSeries making its way somewhere that's accessible via a juju.Conn? <fwereade> bah, that was a *we*'ll step out for lunch, wasn't it? <TheMue> fwereade: Looks like. <niemeyer> fwereade: You've got another LGTM.. hopefully it's sensible <niemeyer> fwereade: (the comments, I mean) <niemeyer> fwereade: Regarding DefaultSeries, yeah, CurrentSeries is going to be available <fwereade> niemeyer, cool, thanks <fwereade> niemeyer, is that going to be directly on Environ? <fwereade> niemeyer, CurrentSeries^^ <niemeyer> fwereade: No, it's a global based on the current machine IIRC <niemeyer> fwereade: So should be usable from elsewhere, as long as we have no loops <fwereade> niemeyer, hmm, ok; I presume it will be an env setting at some stage soon, though? <niemeyer> fwereade: Ah, yep <niemeyer> fwereade: That's something else, sorry, I misunderstood <niemeyer> fwereade: DefaultSeries coming from the env config will certainly be accessible via Conn, since it's stored in the State <fwereade> niemeyer, I have a feeling that rog and dave are both circling that general area so I'm rather reluctant to start implementing that sort of stuff <niemeyer> fwereade: I don't *think* either of them are looking at it now <fwereade> niemeyer, hm, ok, I though I saw a CL from dave that was State.Environment <fwereade> niemeyer, just a ConfigNode for now but clearly a start <niemeyer> fwereade: Uh.. maybe I missed it * niemeyer looks at review queue <niemeyer> add-environment.. suspect.. looking <fwereade> niemeyer, https://codereview.appspot.com/6261055/ <niemeyer> fwereade: Yep, looks good <niemeyer> fwereade: Hmmm <niemeyer> fwereade: I'm a bit sad that we'll be poking at that configuration manually <niemeyer> fwereade: For well-known keys <fwereade> niemeyer, I was a bit uncertain about it; trying to remember the discussion we had at UDS <niemeyer> fwereade: Wondering if DefaultSeries + SetDefaultSeries are reasonable <niemeyer> fwereade: and whether they should be adding to that same setting, or living outside <niemeyer> fwereade: These settings will be common for all providers, I suspect <fwereade> niemeyer, I'm hoping for a separate type for common env settings that we can manipulate nicely <niemeyer> fwereade: I'd like that too <niemeyer> fwereade: We don't even need a separate type, I suppose.. state.DefaultSeries() might work <fwereade> niemeyer, hmm... DefaultSeries and Constraints are both common env settings, and PlacementPolicy may end up becoming one too... with 3 candidates for that sort of thing I'm reluctant to tack it directly onto State <niemeyer> fwereade: Why? What do we get by injecting them in another type? <rog> TheMue, fwereade, niemeyer: here's how it looks when we store units inside services rather than as a global thing. https://codereview.appspot.com/6247066 <fwereade> niemeyer, it's just that State feels big enough already :) <niemeyer> fwereade: It does, because indeed it has a lot of stuff.. but I'm not sure that having to do state.EnvironSettings().SetDefaultSeries(...) is any better <fwereade> niemeyer, yeah, maybe so <rog> fwereade: can DefaultSeries be modelled as a constraint? <niemeyer> fwereade: Maybe the fact we can change multiple things at once and then flush might justify having a separate type <fwereade> rog, IIRC I couldn't quite find a clean way to do so <fwereade> rog, but it's clearly that species of kidney from a certain perspective <rog> fwereade: do you remember why, by any chance? <niemeyer> rog: Ah, no, it's actually not part of the constraint, and there's a good reason <niemeyer> rog: It's part of the charm URL <fwereade> rog, I think it's that it's the only thing that's a charm constraint as well as a machine constraint <fwereade> rog, so it ends up feeding into the constraints <fwereade> rog, but it isn't really one itself <rog> fwereade, niemeyer: couldn't we just take it from the constraints anyway? if we have no constraints, then we'll need to decide somehow and then that will have to be an instance constraint, presumably <fwereade> rog, IMO that is likely to end up a bit convoluted <fwereade> rog, we've already decided, based on the charm, before other constraints really come into play <rog> fwereade: so does it ever make sense to have a "series" constraint that doesn't match DefaultSeries? <niemeyer> rog: No, can't come from the constraints, because the charm has a URL <niemeyer> rog: That's where the decision comes from <fwereade> rog, juju deploy oneiric/wordpress <rog> fwereade: so maybe one way of looking at it is that the *charm* implies some constraints. <fwereade> rog, absolutely so <fwereade> rog, ubuntu-series is a computed constraint that's never exposed in the UI but is used in picking image <niemeyer> fwereade: I'm tempted to suggest we just state.SetDefaultSeries => state.EnvironConfig().Set("default-series", ...) <niemeyer> fwereade: Or maybe not even that, actually.. it's not clear we'll ever set this value through the API outside of environment changes <niemeyer> fwereade: Given that the client API is actually "juju set-env default-series=oneiric" <niemeyer> fwereade: Right? <niemeyer> fwereade: Or did you have something else in mind? <fwereade> niemeyer, yeah, I think so <niemeyer> fwereade: The reading aspect seems to make sense, though <niemeyer> fwereade: I mean <fwereade> niemeyer, all I'm really saying is that I'll want to know how to read it at some point soon :) <niemeyer> fwereade: Having state.DefaultSeries() => EnvironConfig().Get("default-series") <niemeyer> fwereade: jinx <niemeyer> ;) <fwereade> niemeyer, :p <rog> sounds good to me <fwereade> niemeyer, btw, ty for Resolve review; ok to sumbit if I err out on empty local path (and make the other changes ofc ;))? <fwereade> rog, btw, the unit path change looks really nice to me <fwereade> rog, is this something we've agreed to go with or just something you're throwing out there for discussion? <fwereade> rog, if the former I'll give it a more detailed look :) <niemeyer> fwereade: Yeah, that's implied by the LGTM <niemeyer> fwereade: If you think something might be done differently, or disagree with one of the points, a new review makes sense, otherwise a change+submit is fine on LGTM <fwereade> niemeyer, cool, cheers, wasn't quite sure how to interpret the "should we" ;) <rog> fwereade: just been discussing with gustavo <niemeyer> Very warmly.. I feel sorry for Aram :) <rog> fwereade: couple of changes coming up in a mo <niemeyer> We agree, though, as usual <niemeyer> OKAY! <niemeyer> Time to head home <niemeyer> A good weekend to all, and wish me luck on hiding the big aluminum cigar <Beret> heh <niemeyer> s/hiding/riding * Beret won't ask <niemeyer> Beret: airplane.. * robbiew adds mramm to his buddy list ;) <TheMue> mramm: Hiya <mramm> Hy <mramm> how's everything going? <TheMue> mramm: Fine, thank you. Welcome on board. <mramm> Thanks <robbiew> we are now just waiting for him to get access to the inner sanctum...aka irc.canonical.com & wiki.canonical.com :P <Beret> from there, his soul is forever tainted <mramm> very interested in looking around the inner sanctum <robbiew> lol <mramm> sure, but there's interesting stuff <Beret> thus the tainting <mramm> to look at while my soul is being eaten away <robbiew> it's where we hide the oompa loompas <mramm> ahh <mramm> I wondered <fwereade> robbiew, ping <robbiew> fwereade: pong <robbiew> fwereade: one sec ;) <robbiew> fwereade: invite sent <rog> Beret: lol <fwereade> happy weekends all! <rog> fwereade: and you! <TheMue> fwereade, rog: Happy weekend too. <rog> TheMue: and you. i'm away monday and tues <rog> TheMue: so see you wed! <rog> trying hard to lbox propose from the train through my phone... <rog> it's not liking it much! <TheMue> rog: Greet the queen. <rog> TheMue: of course. i always pop in for a quick cuppa if i'm in town <TheMue> rog: *lol* <rog> TheMue: yay! https://codereview.appspot.com/6247066 <TheMue> rog: Uh, there are flies on the front page. Your train is too fast. <rog> TheMue: lol <rog> TheMue: that CL make the unit key look like unit-00000-00000 where the first number is the service key number and the second is the id within the service <rog> s/make/makes <Aram> hello. * Aram is back in austria. <andrewsmedina> Aram: hi #juju-dev 2012-06-02 <Aram> moin. #juju-dev 2012-06-03 <cprofitt> hey all #juju-dev 2012-06-04 <davecheney> fwereade: aloha! <fwereade> davecheney, heyhey <fwereade> davecheney, how's it going? <davecheney> good <davecheney> spent the weekend looking at ARM assembly <davecheney> so a change is as good as a holiday <fwereade> davecheney, excellent :) <TheMue> Morning. <fwereade> heya TheMue <fwereade> TheMue, ping <TheMue> fwereade: pong <fwereade> TheMue, figuring out what I should work on; wondering how the relation stuff is going <TheMue> fwereade: One moment please, have to change rooms. <fwereade> TheMue, np <TheMue> fwereade: So, back again. My wife has been in the home office before. ;) <TheMue> fwereade: Currently the State.AddRelation() and State.RemoveRelation() are in review and short before LGTM. <TheMue> fwereade: But Roger and Gustavo discussed and want to keep open, that a service might have relations of the same role mltiple times in future. <TheMue> fwereade: So I'll now change the topology for it and afterwards the AddRelation() and RemoveRelation() to use this new model. <fwereade> TheMue, ok, cool, so not *imminent* -- cheers :) <TheMue> fwereade: Next step will then be to enhance AddRelation() by a better verification of the endpoints. Today it has the same checks as the Py code, but it's not enough. <TheMue> fwereade: What is not so imminent? <fwereade> TheMue, sorry, got diverted; I mean that a usable state.Relation type is still some way off <TheMue> fwereade: There's enough to do, yes. <fwereade> TheMue, cool; I should probably do something that doesn't depend on it then :) <TheMue> fwereade: Or participate. ;) <fwereade> TheMue, if you think the work can be usefully divided that would be cool -- what's the plan? <TheMue> fwereade: That's the problem, there is no real plan. I'm just doing the functionality top-down. I've started with the relation manager, those methods move into our new State. <TheMue> fwereade: Next step would be relation type by type. <TheMue> fwereade: I've seen that the service relation has a lot of functionality. <fwereade> TheMue, I could happily try to do some rudimentary types <fwereade> TheMue, see how far I can take them <fwereade> TheMue, what's the latest stable-ish unmerged relations branch? if you think some will go in soon, it seems sensible to branch from there <TheMue> fwereade: The latest is go-state-remove-relation. But it has a line of prerequisites. <fwereade> TheMue, and is that likely to be merged by the time I have a new type to propose on top of it? and not to change too much between now and then? <TheMue> fwereade: So maybe you should wait until the all are in the trunk. <TheMue> fwereade: I hope to keep the API stable, as well as the types so far. <TheMue> fwereade: Right now only the topology below is changed. <fwereade> TheMue, ok; in that case I can probably just go from trunk, right? <TheMue> fwereade: In trunk there's the current topology, but not yet the relation types as well as Add and Remove. <fwereade> TheMue, I'm just re-checking your current proposals to get myself more up to speed <TheMue> fwereade: Yes, take a look. I think both will go in today or tomorrow. <TheMue> fwereade: Just wait for the LGTM. The Addâ¦ had a pre-LGTM by Gustavo. <fwereade> TheMue, hmm, so I should maybe branch from add-relation and add functionality to ServiceRelation? <TheMue> fwereade: Sounds like a plan. ;) In Removeâ¦ it only has one method more to return the according Relation. <fwereade> TheMue, cool, I'll ping you if I have any trouble <TheMue> fwereade: Cheers. <TheMue> fwereade: You'll see that those zkXyz are now topoXyz, as we talked about in Oakland. <fwereade> TheMue, sweet <fwereade> TheMue, just mailed juju-dev; would apreciate your thoughts <TheMue> fwereade: Will take a look. <TheMue> fwereade: To summarize: Interface changes (with checks) are ok, but no subordinate changes. Am I right? <fwereade> TheMue, that's what I *think* we should do <fwereade> TheMue, you tell me whether that's right :) <TheMue> fwereade: Hehe, then you have to help me with subordinates before. Where do we find it in our model? <fwereade> TheMue, we don't really yet <fwereade> TheMue, I think that I need to incorporate them before we can move much further ahead on the relations <TheMue> fwereade: Could you please tell me more about subordinates? <fwereade> TheMue, I'm just changing Service.AddUnit to take (container *Unit) and seeing where I go from there <fwereade> TheMue, ok, I'll try <fwereade> TheMue, charms can be subordinate <fwereade> TheMue, if they are, their characteristics change <fwereade> TheMue, when deployed, no units are created <TheMue> fwereade: Do you have an example? <fwereade> TheMue, when added to a relation, units of the subordinate are deployed inside the containers of every unit of the principal service <fwereade> TheMue, rsyslog would make a good subordinate charm <fwereade> TheMue, there are a number of other consequences which I only really discovered today <fwereade> TheMue, and am not quite sure I have a handle on <fwereade> TheMue, so stop me if anything sounds like crack <fwereade> TheMue, one of the issues is that the "connections" are different to in a normal relation <fwereade> TheMue, in a normal relation between P and Q, every unit of P can see every unit of Q, and react to settings changes; and vice-versa <TheMue> fwereade: It's ok so far. I only try to understand it right. Typically I've used to work a lot with my colleagues around a whiteboard. I need to visualize it. <fwereade> TheMue, in a subordinate relation, each unit of P sees only the unit of Q that it shares a container with <fwereade> TheMue, and settings changes are processed entirely within, and do not leak beyond, that container <fwereade> TheMue, (everything is still mediated by ZK, obviously; but a settings change for one unit of P will not e noted by a unit of Q outside its container <fwereade> TheMue, so... when storing unit relations, we have different ZK paths to the settings etc <TheMue> fwereade: IC <fwereade> TheMue, we currently handle the /relations/rel-id case, which is what we want globally; but we also need /relations/rel-id/unit-id (I think) * fwereade goes to check <fwereade> TheMue, yeah; and the unit-id I referred to above is specifically the unit id of the principal (ie the one that "owns" the container <fwereade> ) <TheMue> fwereade: In Py there's code handling /relations/rid/cid/role <TheMue> fwereade: Where cid is the container id <fwereade> TheMue, and also /relations/rid/role, right? <TheMue> fwereade: For global relations, yes. <fwereade> TheMue, AIUI the structure of the nodes underneath that should be similar <fwereade> TheMue, does that seem right to you? <fwereade> TheMue, look for _get_scope_path and how it's used <TheMue> fwereade: Thought it is, but not yet covered the container scoped relations. <fwereade> TheMue, I'll proceed as though it is; can't be sure of every use of it yet but we'll see how it goes <fwereade> TheMue, the topology also changes to accommodate knowledge of what container a given unit is actually deployed <fwereade> TheMue, in <fwereade> TheMue, anyway, I'm just making those changes to begin with <TheMue> fwereade: So this is also a topology change to the current Py version? <fwereade> TheMue, no, it's part of the topology already in py <TheMue> fwereade: OK, then I got you wrong, sorry. <TheMue> Lunchtime <Aram> heyhey. <TheMue> Aram: Hiya. <hazmat> g'morning <fwereade> Aram, hazmat: heyhey <fwereade> heya niemeyer <niemeyer> Yo <niemeyer> ! <fwereade> niemeyer, TheMue, Aram: conundrum follows <fwereade> in the topology, in python, we store Machine and Container for each unit <fwereade> only one of those can ever be valid <fwereade> I just got an urge to store Location, which is just a unit key or a machine key (and we can tell which is which, right?) <fwereade> this feels kinda evil, but so does allowing the content to be insane by having both or neither set <fwereade> niemeyer, TheMue, Aram: opinions? ^^ <fwereade> niemeyer, TheMue, Aram: I'm leaning towards storing them under separate keys and just being careful about what we write, but... <niemeyer> fwereade: Having a single key feels bad indeed <fwereade> niemeyer, TheMue, Aram: hmm, *at the moment* only one can ever be correct <fwereade> niemeyer, TheMue, Aram: forget I said anything :) <niemeyer> fwereade: They're different fields meaning different things.. having to guess what the field means based on the value isn't great <fwereade> niemeyer, indeed <fwereade> niemeyer, we could still have garbage set in that one field anyway <TheMue> fwereade: Forgotten. ;) <niemeyer> fwereade: can you please expand? Maybe I misunderstand <fwereade> niemeyer, I'm agreeing -- the extra guard against insanity of the icky magic field doesn't eliminate the possibility of insanity anyway, so so even that is not an argument for the icky magic field over two separate fields * fwereade should go and borrow a cuddly toy from laura to ask these questions to before polluting irc :) <niemeyer> fwereade: Hehe. Jamu used to call that "talking to the bear" :-) <fwereade> niemeyer, yeah, it's a noble technique, we had a cat called mutex at resolver who sometimes served that purpose <TheMue> fwereade: Hehe, or take your pet to talk to (if you got one). Cats are good listeners. <fwereade> TheMue, just a cuddly cat actually <fwereade> TheMue, I'm not sure a real cat would have the patience anyway ;) <TheMue> fwereade: I'm sure -- it doesn't. *lol* <niemeyer> fwereade: That's a great name for a cat :) <fwereade> niemeyer, isn't it :) <TheMue> niemeyer: One question about the topo service inversion. Shall I open the combination of roles even if e not yet use them or shall I keep the current validation for provider/requirer or peer? <niemeyer> TheMue: The validation is fine <niemeyer> TheMue: I mean, it will have to be adapted, of course <niemeyer> TheMue: Given the map change <TheMue> niemeyer: Sure, but I'll keep it and later we can extend it. OK. <niemeyer> TheMue: But we don't have to pretend it's general right now.. we just don't want to shoot ourselves in the foot <TheMue> niemeyer: Could hurt, indeed. ;) <TheMue> niemeyer: So, change is done. Influence on State.AddRelation() is small, only three lines. <fwereade> niemeyer, TheMue: https://codereview.appspot.com/6268050 has subordinate units <niemeyer> fwereade: Woohay <niemeyer> TheMue: Woohay too :) <TheMue> :D <fwereade> niemeyer, er, there'll be a small diff upcoming, missed a signature change in the rest of the project <fwereade> niemeyer, should be a trivial additional file changed <fwereade> niemeyer, ie shouldn't block sane reviewing if you're of a mind :) <niemeyer> fwereade: Not yet.. still trying to catch up on post-sprint stuff <niemeyer> fwereade: But I'll get there <fwereade> niemeyer, no worries :) <fwereade> niemeyer, btw, tyvm for reviewing what you did during the sprint, hope it didn't take too much time away <niemeyer> fwereade: No problem. It didn't take much time away because I've used the evenings for the largest chunks <fwereade> niemeyer, jolly good, thanks :) <fwereade> niemeyer, TheMue, Aram: oh, blast: I've put myself in a situation in which I need two prereqs for the next branch <fwereade> niemeyer, TheMue, Aram: did we ever come up with a nice way of dealing with this? <niemeyer> fwereade: Is any of them small enough that I can review quickly? <niemeyer> fwereade: There's no way to handle that automatically with current infra <niemeyer> fwereade: Launchpad doesn't support it <fwereade> niemeyer, one of them is TheMue's add-relation branch <niemeyer> fwereade: Hmm <fwereade> niemeyer, which IIRC has an LGTM from you already actually <niemeyer> fwereade: I thought that was in already <TheMue> fwereade: There's only a final lgtm missing. <niemeyer> Link? <TheMue> niemeyer: I only proposed it for the final one after the last open points. <TheMue> niemeyer: https://codereview.appspot.com/6223055/ <TheMue> niemeyer, fwereade: I'm ready for submitting it. <fwereade> TheMue, if it has an LGTM you should be good to go unless you disagreed with any of the points in the LGTM <fwereade> TheMue, I have been known to be too hesitant on this front :) * TheMue likes clean LGTMs. ;) * fwereade lives in hope of them, and is most joyful when they come to pass <niemeyer> TheMue: LGTM <TheMue> niemeyer: Ah, thx, here it comes. <fwereade> niemeyer, thanks, sorry context switch :( <niemeyer> fwereade point applies in this case, FWIW.. your branch reflected the agreement of the last review <niemeyer> fwereade: No problem, happy to prevent blockage <TheMue> niemeyer: Updated the latest propose (topology). Now the new trunk containing State.AddRelation() is merged, the changes adopted and all lamps are green. <niemeyer> TheMue: Beautiful, thank you <niemeyer> ! <TheMue> niemeyer: np :D <niemeyer> mramm: ping <mramm> pong <mramm> neimeyer: pong <niemeyer> mramm: Heya <niemeyer> mramm: Are you subscribed to juju-dev? <niemeyer> davecheney: ping <davecheney> niemeyer: ack <davecheney> hang on <davecheney> let me change terminals <davecheney> x has shat itself <davecheney> niemeyer: back <niemeyer> davecheney: Heya <niemeyer> davecheney: Morning <davecheney> yes! finally it wasn't raining, so it was my first chance to go for a ride before work for weeks! <davecheney> niemeyer: how was your trip ? <niemeyer> davecheney: Oh, congrats! :) <niemeyer> davecheney: It was great indeed.. very happy that I managed to meet Aram and rogpeppe in addition to the unrelated sprint <davecheney> niemeyer: didn't you meet roger at UDS ? <davecheney> :P <davecheney> btw, is Aram the Aram taht wrote doozer ? <niemeyer> davecheney: Yeah, but it was great even then.. we managed to cover some interesting ground there <niemeyer> davecheney: He's the Aram that patched doozer for persistence, yeah <niemeyer> ;) <davecheney> niemeyer: i had a great day with rog when we went to the computer history museum <niemeyer> davecheney: By the way, I've pushed a gozk branch that does the semantic change I mentioned <davecheney> 5 hours on SF public transport left ample time for getting to know each other <davecheney> niemeyer: sweet, i'll go get -u now <niemeyer> davecheney: I didn't submit yet, but if you LGTM it I'll push it on <davecheney> niemeyer: does the notification go to gophers ? <davecheney> i haven't seen an email <niemeyer> davecheney: I'd hope so <davecheney> i guess not <davecheney> let me double check <davecheney> https://codereview.appspot.com/6292044 <davecheney> but no email, i just foudn that from your reply to my handover note <niemeyer> Hmm <niemeyer> Weird <davecheney> am i a member of golang-gophers? or just the juju project ? <niemeyer> davecheney: I'm somewhat concerned with the lack of tests in the provisioner brancher.. there are tons of edge cases there that are being carefully considered but untested <niemeyer> davecheney: I'm sure you've tested by hand or at least put good thought on these edge cases <davecheney> niemeyer: yes, i wonder how I can decompose the functions to test them <niemeyer> davecheney: Have you used TDD before? <davecheney> nope <niemeyer> davecheney: Ok.. there are a couple of good books that might be useful.. I like the one from Kent Beck, but just last week I've received good feedback on Growing Object-Oriented Software, Guided by Tests by Steve Freeman <niemeyer> davecheney: I suspect Kent Beck might be more to-the-point in terms of TDD specifically, though <niemeyer> davecheney: Regarding decomposing the functions, that may not be necessary <niemeyer> davecheney: I'm more concerned about testing the real edge cases than the *implementation* <niemeyer> davecheney: A simple example: if a misconfigured environment somehow arrives, the new configuration is ignored, but a follow up configuration actually takes place <niemeyer> davecheney: We can integrate this branch before that, though.. I'm happy to have those increments nicely done on top of that, given that what we have in place was well debated over already <davecheney> niemeyer: cool <niemeyer> davecheney: Right now I'm just doing some minor commenting on trivial stuff like log messages and whatnot <davecheney> niemeyer: ... wondering how to observe a misconfigured environment being rejected <niemeyer> davecheney: What we care about is not that it is rejected, but that the provisioner itself stays up <niemeyer> davecheney: and that a follow up correct configuration is loaded <davecheney> niemeyer: gotcha <davecheney> understood <davecheney> making a list now <davecheney> * provisioning does not occur with broken env <davecheney> * provisioning does occur when env is valid, then broken <davecheney> * provisioning does occur when env is valid, then broken, then valid <davecheney> niemeyer: are you comfortable with me integrating those into the woodenman branch ? <niemeyer> davecheney: woodenman? Do we already have another branch up? Sorry, I'm still catching up <davecheney> yeah, strawman is the basic provisioning agent that just obseverves environment changes <davecheney> woodenman is the follow on that actually pokes the Environ when it needs to add machines, etc <niemeyer> davecheney: I'd prefer to fix these outstanding issues before we increase the functionality <niemeyer> davecheney: We have quite a few pending things there <davecheney> sure <niemeyer> davecheney: Tests, state issues within the loop (maybe?), state reconnection <davecheney> ok <niemeyer> davecheney: If we add more logic, we'll be increasing the debt <niemeyer> davecheney: It's not clear to me we need IsValid anymore, btw, assuming the gozk branch <niemeyer> davecheney: We'll have to think about it.. <niemeyer> davecheney: Well.. and maybe a test <davecheney> niemeyer: no, as long as the watchers close, then I can return to the Run function, tear everything down, and start again <davecheney> niemeyer: re: gozk, I guess that looks good <davecheney> i don't think i can comment authoratively <niemeyer> davecheney: Actually, we may still need a note from the state <davecheney> niemeyer: that is what I thought of from IsValid() <niemeyer> davecheney: Yeah, may be good to be explicit <davecheney> so the innerLoop becomes for state.IsValid() { .... } <niemeyer> davecheney: Yeah, or IsConnected <davecheney> niemeyer: yup, i'm not fussed about the name <niemeyer> davecheney: I know, just brainstorming as we go <davecheney> I had the idea that that would return false after some event that caused the state to be 'broken' <niemeyer> davecheney: We can watch the session channel for that <niemeyer> davecheney: Should be an easy walk <niemeyer> davecheney: Anything returning event.Ok() != true can set the flag to red <niemeyer> davecheney: Actually, now that I think of it.. I don't think the complexity of machinesChanges and environChanges makes sense anymore, with those decisions <niemeyer> davecheney: Just imagine in which circumstances these channels will break <davecheney> niemeyer: you mean making them recreate themselves <niemeyer> davecheney: Oh, duh.. please ignore me <niemeyer> davecheney: No, wait.. I'm confused <niemeyer> davecheney: These channels are internally reestablished.. <niemeyer> davecheney: Yeah, the initial idea seems to proceed <niemeyer> davecheney: We only need to recreate on !ok, right? <davecheney> niemeyer: they are only recreated if, a, they were nil to begin with (just started up) or b, their Stop() method was called, in response to them being closed <niemeyer> davecheney: Yeah, in that second scenario, it doesn't really make sense to bring them back <niemeyer> davecheney: If they're dead, the state itself must be dead too <davecheney> niemeyer: with your change, that is now true <niemeyer> davecheney: That said, it's a trivial simplification we can do in a second moment.. not hurting reliability, so let's move on <davecheney> they anre't recreated util you go through the loop again, so if the loop has a condition that is false if the state is closed <davecheney> they wont' be recreated <niemeyer> davecheney: It was always true.. <niemeyer> davecheney: We've changed !ok to happen more frequently, but it was always the case that with !ok the state is dead <davecheney> niemeyer: absolutely, just those channels never closed <niemeyer> davecheney: Exactly, and stop is only called when they closed <davecheney> so, we can use !ok as a proxy for state is closed <davecheney> ok, that makes things simpler <niemeyer> davecheney: Yeah, I think so too <davecheney> if a watcher closes, it's underlying state is closed, so collapse back to the top, cleaning up as we go, then start again <niemeyer> davecheney: Right <niemeyer> davecheney: I think we pretty much never have to retry in place <niemeyer> davecheney: These scenarios are edge cases anyway, and we need to handle harsher scenarios too <niemeyer> davecheney: So we can safely handle hiccups in conservative ways <davecheney> niemeyer: i also wanted to ask you about retring <davecheney> retrying <niemeyer> davecheney: and proceed as if they were major breakups <davecheney> roger suggested there was some retry logic in the ec2 code, but unless he's talking about goamz, I couldn't find it <niemeyer> davecheney: Hopefully we'll also be better off when the major break does happen <niemeyer> davecheney: No, there is indeed, inside environs/ec2 <davecheney> grep -i -r retry didn't help me, i'll try again <niemeyer> davecheney: grep for shortAttempt <davecheney> ok <niemeyer> davecheney: Should give you the seed <davecheney> i want to reuse that for the loop at the top of the PA, so
{'channel': 'juju-dev', 'month': 6}