| niemeyer | andrewsmedina: Heya | 00:17 |
|---|---|---|
| niemeyer | andrewsmedina: Just delivered a review on your branch | 00:17 |
| niemeyer | andrewsmedina: Seems pretty close.. | 00:18 |
| niemeyer | andrewsmedina: just trivial stuff | 00:18 |
| niemeyer | Achievement unlocked! | 00:20 |
| niemeyer | Nothing to review on the Go front! | 00:20 |
| niemeyer | Phew | 00:20 |
| andrewsmedina | niemeyer: thanks for review! I will work to resolve the things that you said | 00:45 |
| === davechen1y is now known as davecheney | ||
| andrewsmedina | anybody here? | 04:16 |
| * davecheney waves | 05:06 | |
| davecheney | andrewsmedina: are you doing a full port for the local provider to juju/go ? | 05:28 |
| davecheney | that would be awesome | 05:28 |
| rogpeppe | davecheney: hiya | 06:31 |
| davecheney | aoy | 06:35 |
| rogpeppe | davecheney: i'm a big fan of sharing-memory-by-communicating in general, but sometimes a mutex gets the job done more cleanly IMHO. http://paste.ubuntu.com/1000362/ | 06:56 |
| rogpeppe | davecheney: (which also has the advantage that we don't serialise all requests) | 06:57 |
| davecheney | rogpeppe: yup, that will work also | 07:00 |
| davecheney | there is no reason why we couldn't also do | 07:01 |
| davecheney | case cmd := <- p.cmd ; go cmd(p.env) | 07:01 |
| davecheney | i'm not sure gustavo is sold on the idea of a proxy yet | 07:02 |
| davecheney | but I do admit your idea is simpler | 07:02 |
| rogpeppe | davecheney: invoking go doesn't quite have the same semantics (something may be operating on the environment while it changes) but perhaps that doesn't matter. | 07:03 |
| davecheney | rogpeppe: it's fine to operate on a stale copy | 07:04 |
| davecheney | because that is inevitable | 07:04 |
| rogpeppe | davecheney: if i'm passing a function into a goroutine just to get mutual exclusion, then i start to think i'm doing something a bit wrong. | 07:04 |
| davecheney | rogpeppe: i was following the way the topology worked | 07:04 |
| * rogpeppe obviously hasn't looked too closely at that code :-) | 07:05 | |
| rogpeppe | davecheney: if you don't care whether things can run on the same environment when it changes, then things can be even simpler: http://paste.ubuntu.com/1000370/ | 07:07 |
| davecheney | nice | 07:08 |
| davecheney | i'll take that, thank you | 07:08 |
| rogpeppe | davecheney: cool, glad to be of help. | 07:08 |
| davecheney | i had some reason why it needed to be the original way | 07:09 |
| davecheney | but I can't remember them now | 07:09 |
| davecheney | so until I do | 07:09 |
| davecheney | lets go for simplicity | 07:09 |
| rogpeppe | davecheney: one thing: do we really need to block in NewProxyEnviron? can't we just let the first operation block until there's a valid environ? | 07:14 |
| davecheney | nope, no need to block | 07:14 |
| rogpeppe | davecheney: that would simplify things even more: http://paste.ubuntu.com/1000379/ | 07:14 |
| davecheney | that was a personal chioce | 07:14 |
| rogpeppe | davecheney: down from 167 lines to 86 :-) | 07:14 |
| davecheney | excellent | 07:14 |
| davecheney | i won't mention that it won't compile anymore | 07:15 |
| rogpeppe | davecheney: minor details | 07:15 |
| rogpeppe | :-) | 07:15 |
| davecheney | ahh, that is why we block til a valid environ | 07:15 |
| davecheney | so we don't need to check for nil | 07:15 |
| rogpeppe | davecheney: ah, that's easy to fix too. | 07:16 |
| davecheney | when NewProxyEnviron returns, there is something that proports to be an envion there | 07:16 |
| davecheney | so no worrying about NPE | 07:16 |
| rogpeppe | davecheney: something like this, perhaps? http://paste.ubuntu.com/1000381/ | 07:17 |
| davecheney | no thanks | 07:17 |
| davecheney | locked isn't protected by a mutex, and the locks and unlocks are unbalanced | 07:17 |
| rogpeppe | davecheney: locked doesn't need to be protected by a mutex (it's local). we ensure that the lock is held on entry to loop. but yeah, it's not so pretty. | 07:18 |
| rogpeppe | davecheney: i had the locked logic wrong BTW: http://paste.ubuntu.com/1000384/ | 07:19 |
| rogpeppe | davecheney: a slightly less unsavoury option: http://paste.ubuntu.com/1000388/ | 07:23 |
| rogpeppe | davecheney: but maybe it's best just to do the wait explicitly in NewProxyEnviron as before. | 07:24 |
| davecheney | lets wait for the request that it doesn't block during startup | 07:24 |
| davecheney | i don't see it as a issue, as nothing can act on the Environ til it's valid anyway | 07:25 |
| davecheney | thanks rogpeppe that made the code a lot simpler | 07:25 |
| davecheney | tests still don't pass, but whatever | 07:26 |
| davecheney | the main goal is to convince gustavo why a proxy is a good way of managing the unstable environment | 07:26 |
| rogpeppe | davecheney: i think that the simpler it is the more likely we are of that | 07:26 |
| rogpeppe | davecheney: BTW i'm not convinced this deserves its own package. it's quite specific to the provisioning agent, isn't it? | 07:28 |
| davecheney | i hope that it makes it easier to test | 07:28 |
| davecheney | ie, we test we can do all the dummy tests against this Environ | 07:28 |
| davecheney | rather than trying to test it via the provisioning agent | 07:28 |
| rogpeppe | davecheney: there's nothing stopping us having internal tests for the provisioning agent code | 07:29 |
| davecheney | but your point is well made that in theory the provisinng agent is the only one talking to the Environ | 07:29 |
| rogpeppe | davecheney: i've done that quite a bit in the ec2 provider | 07:29 |
| rogpeppe | davecheney: also, as a general mechanism it's not quite there | 07:29 |
| rogpeppe | davecheney: because if a client keeps a Storage around, that won't work well - you'd have to proxy that too. | 07:30 |
| davecheney | rogpeppe: yup - i saw that, maybe that can be solved via convention | 07:31 |
| davecheney | on error, get a new storage | 07:31 |
| rogpeppe | davecheney: yeah, but will the provisioning agent actually be writing to storage ever? | 07:31 |
| rogpeppe | davecheney: i.e. do we really care? | 07:31 |
| davecheney | rogpeppe: that, i do not know | 07:31 |
| rogpeppe | davecheney: we could have a Storage method that just paniced. | 07:32 |
| rogpeppe | davecheney: (or returned a Storage that always returned an error, i suppose) | 07:33 |
| rogpeppe | davecheney: oh, i'm talking bollocks, of course the provisioning agent needs to talk to the storage. | 07:34 |
| davecheney | ok, i'll make a proxy storage | 07:34 |
| rogpeppe | davecheney: yeah. it could always call the relevant storage method in proxy before invoking its method. | 07:35 |
| rogpeppe | davecheney: it's slightly easier if you assume that the provisioning agent will never need to *write* to the storage (which i think is the case) http://paste.ubuntu.com/1000412/ | 07:46 |
| rogpeppe | davecheney: and i'm thinking that it's probably best to have NewProxyEnviron block until the environment is valid, and let the caller deal with that. | 07:46 |
| rogpeppe | davecheney: rather than putting an error test in every method. | 07:46 |
| rogpeppe | davecheney: anyway, i should get back to my *own* damn code! | 07:49 |
| davecheney | rogpeppe: thanks for your help | 08:08 |
| davecheney | out | 08:08 |
| Aram | morning. | 11:18 |
| rogpeppe | Aram: hiya | 11:21 |
| rogpeppe | gotta love ec2 request reliability | 12:00 |
| TheMue | rogpeppe: Why? | 12:15 |
| TheMue | rogpeppe: Heya btw. | 12:15 |
| rogpeppe | TheMue: (hiya too) i've run the environs/ec2 amazon tests four times in a row and they've failed each time for different reasons. | 12:15 |
| rogpeppe | TheMue: we really need some retry logic at the goamz/ec2 level - that will help a lot. | 12:16 |
| rogpeppe | TheMue: it's great when a test fails 3/4s of the way through, reading a file that it already read successfully, saying "file not found" | 12:17 |
| TheMue | rogpeppe: Yes, transparent for the user. Only real hard errors we know should raise. | 12:17 |
| rogpeppe | TheMue: yeah. you can't deal with the eventual consistency stuff automatically sadly. but the "premature EOF" and "handshake failure" errors are entirely possible. | 12:17 |
| TheMue | rogpeppe: Is EC2 in general so unreliable? Or is it only a special part of their API? | 12:18 |
| rogpeppe | TheMue: i have a feeling it's all that unreliable | 12:19 |
| rogpeppe | TheMue: but i only have the one data point | 12:19 |
| TheMue | rogpeppe: Uuh, not good. | 12:19 |
| rogpeppe | TheMue: it applies to S3 too | 12:19 |
| rogpeppe | TheMue: yay, put in a couple of retry loops and it all works now | 12:19 |
| TheMue | rogpeppe: Are there any hints by Amazon on an optimal retry strategy (how often, which delay between requests, …)? | 12:21 |
| rogpeppe | TheMue: no. they don't even talk about eventual consistency issues. it all looks hunky-dory in their docs. | 12:21 |
| TheMue | rogpeppe: I've got to admit that I expected this answer. I only had a little hope left. | 12:22 |
| rogpeppe | TheMue: building on shifting sands... | 12:22 |
| TheMue | rogpeppe: So take a house boat, able to move but tied in place. | 12:24 |
| rogpeppe | TheMue: right, time for some lunch | 12:26 |
| TheMue | rogpeppe: Enjoy, I just had. | 12:26 |
| niemeyer | Hullah! | 12:39 |
| TheMue | niemeyer: Moin. ;) | 12:49 |
| niemeyer | TheMue: Heya | 12:49 |
| TheMue | niemeyer: I'm just thinking about the "endpointInfo" in topology.go. It's indeed no beatiful solution and tries to wrap what "get_relation_service" and "get_relations_for_service" return in the Python version. | 12:58 |
| TheMue | niemeyer: Its really very similar to "RelationEndpoint2, only that there are names while "endpointInfo" deals with keys. | 12:59 |
| niemeyer | TheMue: Right | 13:00 |
| TheMue | niemeyer: I could add the keys to "RelationEndpoint" as private fields, that would safe us one type | 13:01 |
| niemeyer | TheMue: Why do we need the keys there? | 13:01 |
| niemeyer | TheMue: See the Python code | 13:01 |
| TheMue | niemeyer: Have to look, one moment. It's taken from the Python code. | 13:02 |
| niemeyer | TheMue: I don't think it is | 13:02 |
| niemeyer | TheMue: This branch diverges wildly from Python all around | 13:02 |
| TheMue | niemeyer: The information that the two functions using the "endpointInfo" returns is the same like the two Python functions named above. | 13:05 |
| TheMue | niemeyer: But there dynamically lists and dictionaries are taken. | 13:05 |
| niemeyer | TheMue: That's not what we were talking about.. | 13:05 |
| niemeyer | <TheMue> niemeyer: I could add the keys to "RelationEndpoint" as private fields, that would safe us one type | 13:05 |
| niemeyer | <niemeyer> TheMue: Why do we need the keys there? | 13:06 |
| niemeyer | <niemeyer> TheMue: See the Python code | 13:06 |
| rogpeppe | gorgeous weather out there for a change. | 13:09 |
| rogpeppe | niemeyer: mornin', BTW | 13:10 |
| TheMue | niemeyer: "get_relations_for_service" stores at least the "relation_id", I don't yet know where it is used. Regarding the "ServiceKey" William and I discussed that it's better than the name, which can be retrieved via "ServiceName(key)". | 13:10 |
| rogpeppe | niemeyer: thanks a lot for the review last night. you might've seen two tiny branches proposed this morning: https://codereview.appspot.com/6220065/ and https://codereview.appspot.com/6221058/ | 13:11 |
| niemeyer | rogpeppe: Morning | 13:13 |
| niemeyer | TheMue: Sorry, I don't understand what you mean.. the service key is a service key, the service name is a service name. Neither is better than the other without context. | 13:14 |
| niemeyer | rogpeppe: No, haven't run through reviews yet | 13:14 |
| rogpeppe | niemeyer: that's fine. they're both independent anyway, | 13:14 |
| niemeyer | rogpeppe: That's great, thanks | 13:15 |
| TheMue | niemeyer: If I have one of it (service name or key) I can retrieve the other (only that from key to name is a bit faster). For relations I need the key to retrieve the name. | 13:17 |
| niemeyer | TheMue: Yes. How does that change the picture in the scenario we were talking about earlier? | 13:18 |
| niemeyer | TheMue: You can use RelationEndpoint to work with relations in the same way that Python deos. | 13:18 |
| niemeyer | does | 13:18 |
| niemeyer | TheMue: You don't need to store any private keys in RelationEndpoint. | 13:18 |
| TheMue | niemeyer: That's only a first observation for me to get a better understanding | 13:19 |
| niemeyer | TheMue: RelationEndpoint needs a RelationName | 13:19 |
| niemeyer | TheMue: All of that has to be fixed | 13:19 |
| niemeyer | TheMue: And all of it are divergences from what Python does | 13:19 |
| TheMue | niemeyer: It has now a name. | 13:19 |
| niemeyer | TheMue: Simplifying is cool, but it needs a lot of attention to what is being done if we are to diverge from what is being done in the Python code. I get quite nervous when I see the implementation diverging wildly both in terms of implementation and in terms of *semantics*. | 13:20 |
| TheMue | niemeyer: What I'm looking for is how to optimally return informations that get_relations_for_service and get_relation_service return. | 13:21 |
| niemeyer | TheMue: Ok, let me look at that | 13:21 |
| TheMue | niemeyer: There they are e.g. dynamic lists with the interface as first field and service topology as second field. | 13:21 |
| niemeyer | TheMue: What is "service topology"? | 13:22 |
| TheMue | niemeyer: For the rest I already adopted your suggestions. | 13:22 |
| niemeyer | TheMue: I suppose get_relations_for_service should return []relation? | 13:24 |
| TheMue | niemeyer: Eh, wrong wording, see return (relation_data["interface"], relation_data["services"][service_id]) | 13:24 |
| TheMue | niemeyer: Good idea, would only have to add the key here (currently it doesn't has). | 13:25 |
| niemeyer | TheMue: Yeah, that sounds fine.. RelationKey | 13:26 |
| niemeyer | Well, not really | 13:26 |
| niemeyer | TheMue: relation{ Key: ... } | 13:26 |
| TheMue | niemeyer: It would be persisted. | 13:26 |
| niemeyer | TheMue: Not necessarily.. omitempty | 13:26 |
| TheMue | niemeyer: Ah, yes, I remember. | 13:26 |
| niemeyer | TheMue: service=services[service_id])) | 13:27 |
| niemeyer | TheMue: What is that data in the service key? | 13:27 |
| niemeyer | {"role": r, "name": n}, I suppose..? | 13:29 |
| TheMue | niemeyer: The function only looks for one service. So our Services map would contain the role and the key. | 13:29 |
| niemeyer | TheMue: Why does it do that? I'm not sure we should mimic it | 13:30 |
| TheMue | niemeyer: Let me look for a consumer of this function, moment. | 13:30 |
| niemeyer | TheMue: If we get a relation back, it should be the actual relation, with its actual.. it's not clear to me why we should be stripping it off arbitrarily | 13:30 |
| niemeyer | s/its actual/its actual data/ | 13:31 |
| niemeyer | TheMue: I was looking at that too.. still not clear.. feels like a poor interface | 13:31 |
| TheMue | niemeyer: So far I don't see any reason too. | 13:31 |
| niemeyer | TheMue: Ok.. let's just return a proper relation with its real data then | 13:32 |
| niemeyer | TheMue: If we find out why we can talk again | 13:32 |
| niemeyer | TheMue: But I suspect this should do quite nicely | 13:32 |
| TheMue | niemeyer: Think so too. | 13:32 |
| TheMue | niemeyer: At least it "feels" better than my current solution. | 13:32 |
| niemeyer | rogpeppe: You got a major LGTM, and a major OMG WHAT ARE YOU DOING? | 13:36 |
| rogpeppe | niemeyer: interesting | 13:36 |
| rogpeppe | niemeyer: the way to fix that OMG is to implement signed URLs in s3, which i haven't got around to yet. | 13:37 |
| rogpeppe | niemeyer: if i put in a TODO, would that be ok? | 13:37 |
| niemeyer | rogpeppe: No.. we're not making anything public and swiping that under the carpet | 13:38 |
| niemeyer | s/anything/everything/ | 13:38 |
| niemeyer | rogpeppe: Been there, doesn't end up well | 13:38 |
| rogpeppe | niemeyer: ok. i'll do the s3 thing first then. | 13:38 |
| rogpeppe | niemeyer: only problem is, i looked for how to do the signed URL thing before and didn't come up with anything | 13:39 |
| niemeyer | rogpeppe: I can do that if necessary | 13:39 |
| niemeyer | rogpeppe: Actually, let me do that | 13:39 |
| niemeyer | rogpeppe: Are you happy with the former s3 branch? | 13:39 |
| rogpeppe | niemeyer: just a pointer to some docs would be fine. or, if you wanna do that, that would be lovely too! | 13:39 |
| rogpeppe | niemeyer: oh shit, forgot about that. one mo. | 13:39 |
| niemeyer | rogpeppe: Cheers | 13:40 |
| rogpeppe | niemeyer: you've got a review | 13:55 |
| niemeyer | rogpeppe: "could we give a nicer error here when we panic?" | 13:58 |
| niemeyer | rogpeppe: When would it panic? | 13:58 |
| rogpeppe | niemeyer: if the host in the headers didn't have two dots in it? | 13:59 |
| niemeyer | rogpeppe: This code can't execute if that's the case | 13:59 |
| rogpeppe | niemeyer: ah yes. | 14:00 |
| niemeyer | rogpeppe: Will fix the rest | 14:00 |
| niemeyer | rogpeppe: Thanks for the review | 14:00 |
| rogpeppe | niemeyer: doh, sorry for that | 14:00 |
| niemeyer | rogpeppe: np | 14:01 |
| niemeyer | rogpeppe: I'll add the "" on a line on its own.. it's not using field names purposefully in this case | 14:01 |
| rogpeppe | niemeyer: that's fine | 14:02 |
| niemeyer | rogpeppe: It should fail if we add a field and forget to update one of the structs | 14:02 |
| rogpeppe | niemeyer: sure. | 14:02 |
| niemeyer | rogpeppe: ${bucket} would probably be a more sensible replacement var | 14:06 |
| rogpeppe | niemeyer: yeah, that would be fine. although if there's ambiguity between $name and the rest, there's gonna be ambiguity between the bucket name and the rest... | 14:07 |
| niemeyer | rogpeppe: Hm? | 14:07 |
| rogpeppe | niemeyer: isn't that why you're preferring ${bucket} ? | 14:07 |
| rogpeppe | niemeyer: because it's unambiguously replaceable? | 14:08 |
| rogpeppe | i suppose the host name might have a $ in. | 14:08 |
| rogpeppe | if that's allowed | 14:08 |
| niemeyer | rogpeppe: $namesis shouldn't get replaced | 14:08 |
| rogpeppe | niemeyer: yeah, true. it's a URL really and URLs can contain $s | 14:10 |
| rogpeppe | niemeyer: ${bucket} is just fine. | 14:10 |
| rogpeppe | niemeyer: lots better than %s :-) | 14:10 |
| niemeyer | rogpeppe: Indeed | 14:12 |
| niemeyer | "@ylastic #AWS #EC2 API calls returning intermittent errors "Unavailable: Unable to process request, please retry shortly"" | 14:15 |
| niemeyer | Things are getting more and more "eventual" | 14:15 |
| niemeyer | rogpeppe: Branch re-proposed | 14:18 |
| rogpeppe | niemeyer: it's wonderful. i tried the amazon test 4 times in a row this morning and it failed each time with a different error. we need to get that retry logic in! | 14:19 |
| rogpeppe | niemeyer: LGTM | 14:22 |
| niemeyer | rogpeppe: Thanks | 14:23 |
| andrewsmedina | rogpeppe, niemeyer morning :D | 14:23 |
| rogpeppe | andrewsmedina: hiya! | 14:23 |
| andrewsmedina | rogpeppe, niemeyer thanks for review | 14:24 |
| rogpeppe | andrewsmedina: np. thanks for bearing with us! | 14:24 |
| andrewsmedina | rogpeppe: when you have a time, I wanted to talk with you about the reivew | 14:24 |
| rogpeppe | andrewsmedina: i've got a meeting in 5 minutes, but in an hour or so, no problem. | 14:25 |
| andrewsmedina | rogpeppe: ok | 14:32 |
| rogpeppe | andrewsmedina: ping | 14:50 |
| andrewsmedina | rogpeppe: pong | 14:57 |
| andrewsmedina | rogpeppe: about the %d | 14:57 |
| rogpeppe | andrewsmedina: about the %d | 14:58 |
| andrewsmedina | rogpeppe: virsh use the %d to create a autoincrement number for the net/bridge name | 14:58 |
| andrewsmedina | rogpeppe: the juju python version uses it | 14:59 |
| rogpeppe | andrewsmedina: is that needed, given that the name needs to unique anyway? | 14:59 |
| rogpeppe | s/to /to be / | 14:59 |
| rogpeppe | andrewsmedina: fair enough. *is* it actually documented anywhere, or is it just a bit of black magic known to those who've read the source? | 15:00 |
| andrewsmedina | rogpeppe: http://bazaar.launchpad.net/~juju/juju/trunk/view/head:/juju/providers/local/network.py#L13 | 15:01 |
| andrewsmedina | rogpeppe: I dont know if this is a oficial feature =/ | 15:02 |
| rogpeppe | andrewsmedina: ok. i see that, thanks. but i'd like to know why we're doing that. or at any rate write a comment saying what it's there for. | 15:02 |
| rogpeppe | niemeyer, hazmat: do you know, by any chance, why we need an autoincrement number in the lxc network bridge name? | 15:03 |
| andrewsmedina | rogpeppe: I will do a comment about it | 15:03 |
| rogpeppe | andrewsmedina: thanks a lot | 15:03 |
| andrewsmedina | rogpeppe: about the split | 15:03 |
| hazmat | rogpeppe, we do? we just use the default libvirt name | 15:03 |
| hazmat | s/name/network | 15:04 |
| andrewsmedina | rogpeppe: virsh always returns the same string pattern | 15:04 |
| rogpeppe | hazmat: see link above | 15:04 |
| andrewsmedina | I need to check anyway? | 15:04 |
| andrewsmedina | hazmat: http://bazaar.launchpad.net/~juju/juju/trunk/view/head:/juju/providers/local/network.py#L13 | 15:04 |
| rogpeppe | andrewsmedina: yes, but virsh isn't part of the juju program. if someone changes the virsh output, we want a "unexpected virsh output" error or similar, rather than an array bounds panic. | 15:05 |
| hazmat | andrewsmedina, we don't specify that value | 15:05 |
| hazmat | andrewsmedina, its escaped because libvirt uses it | 15:05 |
| hazmat | %%d | 15:05 |
| rogpeppe | hazmat: why do we need it? | 15:05 |
| hazmat | rogpeppe, we don't.. libvirt does | 15:06 |
| rogpeppe | hazmat: isn't the bridge name unique enough, given that it includes the network name? | 15:06 |
| hazmat | i'd suggest not being slavish about copying that aspect.. i've got a separate branch local-cloud-img that gets rid of libvirt entirely | 15:06 |
| andrewsmedina | launch time :( | 15:07 |
| andrewsmedina | sorry | 15:07 |
| hazmat | rogpeppe, its not | 15:07 |
| rogpeppe | hazmat: ok. | 15:07 |
| rogpeppe | hazmat: when you say "getting rid of libvirt", you mean "not using virsh" ? | 15:07 |
| rogpeppe | hazmat: i haven't looked too deeply into how all the lxc stuff is set up. i should! | 15:08 |
| hazmat | rogpeppe, no i mean getting rid of libvirt | 15:08 |
| hazmat | rogpeppe, the name comes out virbr | 15:08 |
| hazmat | again this has nothing to do with juju | 15:08 |
| hazmat | this is libvirt's configuration | 15:08 |
| hazmat | and it needs that string insertion for its templates %d | 15:09 |
| rogpeppe | hazmat: i didn't see any mention of the %d in the libvirt docs. but i'm probably looking in the wrong place. | 15:10 |
| rogpeppe | hazmat: (i looked in | 15:10 |
| rogpeppe | http://libvirt.org/formatnetwork.html and | 15:10 |
| rogpeppe | http://libvirt.org/sources/virshcmdref/html/sect-net-define.html | 15:10 |
| rogpeppe | ) | 15:10 |
| rogpeppe | hazmat: so your branch eschews the portability layer and talks to lxc directly? | 15:11 |
| hazmat | rogpeppe, what portability layer? | 15:11 |
| hazmat | rogpeppe, i think your misunderstanding something fundamental here | 15:12 |
| rogpeppe | hazmat: libvirt looks like a portability layer to me, but i may be misinterpreting | 15:12 |
| rogpeppe | hazmat: almost certainly! | 15:12 |
| hazmat | rogpeppe, we don't use libvirt outside of setting up the network | 15:12 |
| hazmat | rogpeppe, its a rather broken portability layer when it comes to lxc | 15:12 |
| hazmat | rogpeppe, it has many additional functionalities that have no meaning on the context of lxc | 15:12 |
| rogpeppe | hazmat: sure. but that is the role it's trying to play, no? or i'm i fundamentally misunderstanding? | 15:12 |
| niemeyer | It's lunch time | 15:12 |
| hazmat | rogpeppe, we're just piggybacking on its packinging of a default network | 15:12 |
| hazmat | in the lxc in precise, this is also in the lxc package | 15:13 |
| hazmat | moreover local provider doesn't use cloud-init or cloud images at the moment, the branch i mentioned local-cloud-img, rips out libvirt, uses cloud images for local provider, and uses cloud-init to configure | 15:13 |
| hazmat | rogpeppe, yes libvirt is an abstraction layer over different virt providers | 15:14 |
| rogpeppe | hazmat: ok, cool. i'm not too far off then! | 15:14 |
| hazmat | rogpeppe, but its not particularly good for several of them | 15:14 |
| rogpeppe | hazmat: that's in the nature of portability layers i guess. lowest common denominator. | 15:15 |
| hazmat | rogpeppe, for example openstack uses libvirt to address several different tech, but there are also standalone providers for some of the same ones that libvirt provides an abstraction for | 15:15 |
| hazmat | within openstack | 15:15 |
| hazmat | rogpeppe, its actually quite rich as a common api, but in the context of lxc specifically its typically out-of-date, and overkill | 15:15 |
| hazmat | rogpeppe, we had a discussion about trying to use libvirt directly a while ago instead of lxc directly | 15:16 |
| rogpeppe | hazmat: given that we're directly reliant on lxc in other aspects, i'd be inclined to agree, although i haven't looked at how hard it is to configure networks in lxc directly. | 15:16 |
| rogpeppe | hazmat: that's the other possibility of course | 15:16 |
| hazmat | rogpeppe, its pretty trivial, just needs the packaging effort around creating the bridge, etc | 15:17 |
| hazmat | trivial to configure that is | 15:17 |
| * hazmat preps for his next meeting | 15:17 | |
| rogpeppe | andrewsmedina: anyway, with a comment, i'm happy with that code. | 15:17 |
| rogpeppe | TheMue: i see sporadic test failures testing state: http://paste.ubuntu.com/1001083/ | 15:49 |
| TheMue | TheMue: I've done no changes at watcher for a longer time, but I've just merged the trunk into my branch and get a watcher failure too. | 15:51 |
| rogpeppe | TheMue: i don't *think* it's my fault :-) | 16:02 |
| * niemeyer waves | 16:10 | |
| niemeyer | TheMue: Perhaps a race? | 16:10 |
| rogpeppe | niemeyer, TheMue: i suspect a race, or an inadequate timeout. | 16:17 |
| rogpeppe | niemeyer: BTW if i take out that PublicRead change, does that "make amazon tests work" branch LGTY? | 16:17 |
| niemeyer | rogpeppe: I've stopped checking it out there | 16:17 |
| TheMue | So, back, had to do an emergency repair here (jalousie broke down). | 16:18 |
| rogpeppe | niemeyer: ok. 'cos i need that branch in an upcoming branch that already has a dependency... | 16:18 |
| niemeyer | rogpeppe: Ok, what's the plan? | 16:27 |
| rogpeppe | niemeyer: i've pushed that branch without that change. the amazon tests no longer pass of course, so i'm changing it temporarily locally so i can test. but the other changes are less trivial and also necessary. | 16:28 |
| rogpeppe | niemeyer: so when s3 implements signed URLs we'll use them and the amazon tests will pass | 16:28 |
| niemeyer | rogpeppe: Ok, I mean what's the plan as far as the branch goes | 16:29 |
| rogpeppe | niemeyer: the "fix amazon tests" branch? | 16:29 |
| niemeyer | rogpeppe: Whatever branch you mean.. yous said you need that branch.. what's your plan | 16:29 |
| TheMue | rogpeppe: I few moments ago I had your watcher error too, but now everything runs. Will investigate it later. | 16:30 |
| rogpeppe | niemeyer: i'll hold off proposing again until the "fix amazon tests" branch is in. | 16:30 |
| niemeyer | rogpeppe: Ok.. so I'm' not sure about what you meant | 16:31 |
| niemeyer | <rogpeppe> niemeyer: BTW if i take out that PublicRead change, does that "make amazon tests work" branch LGTY? | 16:31 |
| niemeyer | <rogpeppe> niemeyer: ok. 'cos i need that branch in an upcoming branch that already has a dependency... | 16:31 |
| rogpeppe | niemeyer: it would be nice to have a review of the "fix tests" branch so i can propose that upcoming branch | 16:31 |
| niemeyer | rogpeppe: You already have a review.. there's a change that can't go in | 16:31 |
| rogpeppe | niemeyer: it no longer has that PublicRead change | 16:31 |
| rogpeppe | niemeyer: i've re-proposed it | 16:32 |
| niemeyer | rogpeppe: Ok.. so you've reproposed and you want another review? | 16:32 |
| rogpeppe | niemeyer: yes please | 16:32 |
| rogpeppe | niemeyer: you should have got a mail saying "please take a look" :-) | 16:32 |
| niemeyer | rogpeppe: Heh | 16:32 |
| niemeyer | rogpeppe: That's a pretty difficult way to ask for a review | 16:33 |
| niemeyer | rogpeppe: Will have a look | 16:33 |
| rogpeppe | niemeyer: isn't that implied? if not, what's the point of the mail? | 16:33 |
| niemeyer | rogpeppe: You see the history above? | 16:34 |
| niemeyer | rogpeppe: "Please have a look at http://... again" is fine | 16:34 |
| rogpeppe | niemeyer: fair enough | 16:34 |
| rogpeppe | niemeyer: (but i thought that was the point of the "Please take a look" email!) | 16:35 |
| niemeyer | rogpeppe: Nevermind! | 16:35 |
| rogpeppe | yay! go tools now working on the server again... | 16:35 |
| rogpeppe | niemeyer: BTW while (if?) you're on little reviews, this is trivial, assuming you agree with the premise. https://codereview.appspot.com/6188068/ | 16:41 |
| niemeyer | rogpeppe: What's the point of these loops? | 16:50 |
| niemeyer | for i := 0; i < 5; i++ { | 16:50 |
| niemeyer | ? | 16:50 |
| andrewsmedina | niemeyer: ping | 16:50 |
| niemeyer | andrewsmedina: hi | 16:50 |
| andrewsmedina | niemeyer: thanks for your review | 16:50 |
| niemeyer | andrewsmedina: np | 16:50 |
| andrewsmedina | niemeyer: I think it is okay | 16:50 |
| andrewsmedina | now | 16:50 |
| rogpeppe | niemeyer: same as for other eventual consistency issues | 16:50 |
| rogpeppe | niemeyer: i copied the retry code from elsewhere. we could use a different retry time or count | 16:51 |
| niemeyer | rogpeppe: Ok, can you please reduce the delay on each retry then, to maybe 1e8, increase the limit to 30 or so, and add a comment explaining? | 16:51 |
| rogpeppe | niemeyer: ok, will do, and in the other place too. | 16:51 |
| niemeyer | rogpeppe: No need to be too extensive in the comment, just a reminder | 16:51 |
| andrewsmedina | niemeyer: I will work on local provider interface now: p | 16:52 |
| niemeyer | rogpeppe: Thanks | 16:52 |
| niemeyer | rogpeppe: "LGTM assuming reduced timeouts and increased N as discussed online." | 16:53 |
| rogpeppe | niemeyer: thanks a lot | 16:53 |
| niemeyer | rogpeppe: No problem.. that was easy :) | 16:56 |
| niemeyer | rogpeppe: Hopefully we can get a fix to the signature issue in very soon | 16:56 |
| niemeyer | rogpeppe: I'll try to address that today still | 16:56 |
| rogpeppe | *splash* | 16:57 |
| rogpeppe | (the sound of a branch landing) | 16:57 |
| andrewsmedina | niemeyer: It needed something more to my proposal be accepted? | 16:58 |
| rogpeppe | right, gotta go. have fun all. see you tomorrow. | 17:00 |
| niemeyer | rogpeppe: See ya | 17:13 |
| niemeyer | andrewsmedina: I haven't re-reviewed your branch yet | 17:13 |
| niemeyer | andrewsmedina: have you addressed the latest comments by rog/ | 17:13 |
| niemeyer | ? | 17:13 |
| twobottux | aujuju: What is the best way to use the mysql charm in Juju with dynamic database credientials? <http://askubuntu.com/questions/140818/what-is-the-best-way-to-use-the-mysql-charm-in-juju-with-dynamic-database-credie> | 17:19 |
| andrewsmedina | niemeyer: yes, about %d rog said it is ok | 17:50 |
| andrewsmedina | niemeyer: about split, virsh always returns the same pattern | 17:50 |
| niemeyer | andrewsmedina: Cool, need to step out for a doc appointment.. back soon, though | 17:50 |
| andrewsmedina | niemeyer: I'm using the same strategy used in juju python code | 17:50 |
| andrewsmedina | niemeyer: ok | 17:51 |
| SpamapS | Multiple IPs!! | 17:55 |
| * SpamapS does a dance | 17:56 | |
| SpamapS | niemeyer: great news! | 17:56 |
| SpamapS | the multiple IPs, not the doc appointment ;) | 17:56 |
| andrewsmedina | SpamapS: :-p | 18:08 |
| niemeyer | SpamapS: Indeed!! | 19:25 |
| niemeyer | Ouch.. that's the sleepiest time of the day | 20:48 |
| niemeyer | Alright, not working.. I'll do it Windows style and take a short nap to reboot | 20:54 |
| Aram | sleep is when the garbage collector runs. | 20:54 |
| niemeyer | davecheney: Morning! | 22:00 |
| niemeyer | Aram: Indeed | 22:00 |
| davecheney | mornign! | 22:02 |
| davecheney | niemeyer: lets talk about the proxy environ | 22:02 |
| niemeyer | davecheney: Yeah, was planning on that too | 22:02 |
| niemeyer | davecheney: Good we're overlapping today | 22:03 |
| davecheney | how can I convince you of it's utility | 22:03 |
| niemeyer | davecheney: Hehe :-) | 22:03 |
| davecheney | niemeyer: yes, sorry about that, i had to go intot he city to finish some of the employment paper work that was dropped when veronika moved on | 22:03 |
| niemeyer | davecheney: Ah, no worries at all | 22:03 |
| niemeyer | davecheney: The concept of having such a wrapper feels pretty icky to me | 22:04 |
| davecheney | niemeyer: ok, maybe the name is a problem | 22:04 |
| niemeyer | davecheney: It's a bit like replacing the car every time the battery goes bad | 22:04 |
| niemeyer | davecheney: Not really | 22:04 |
| niemeyer | davecheney: It's the concept itself | 22:05 |
| davecheney | ok, let me put it like this | 22:05 |
| davecheney | we dont' wrap one Environ in another | 22:05 |
| davecheney | the proxy wraps a *ConfigNode in an Environ | 22:05 |
| niemeyer | davecheney: We wrap it so that it is magically replaced every time its configuration changes | 22:05 |
| davecheney | yes | 22:05 |
| niemeyer | davecheney: That foundational idea is that seems misleading | 22:05 |
| davecheney | ok | 22:06 |
| niemeyer | davecheney: If the configuration of an environment changes, we should replace its configuration at an appropriate well known time, not the entire thing behind the scenes at an arbitrary moment | 22:06 |
| davecheney | niemeyer: hmm, this is a bit of a change of heart frmo UDS | 22:07 |
| davecheney | where we talked about making the environment a *ConfigNide | 22:07 |
| davecheney | Node | 22:07 |
| niemeyer | davecheney: We're talking about different things | 22:07 |
| davecheney | then the provisioning agent would start to watch that node, until it got a valid configuration | 22:07 |
| davecheney | ok | 22:07 |
| niemeyer | davecheney: I'm talking about the thing that offers an environs.Environ interface, not the content of the /environment node | 22:08 |
| davecheney | ok | 22:08 |
| niemeyer | davecheney: Whenever the configuration of an environment changes, there's a window of time that the value in memory we have that represents the environment (implements environs.Environ) will have a wrong configuration. | 22:09 |
| davecheney | yup | 22:09 |
| davecheney | i see that as inevitable | 22:10 |
| niemeyer | davecheney: This is a problem inherent to the distributed context that we can't solve.. | 22:10 |
| niemeyer | davecheney: Understanding that gives us some freedom too, interestingly. It means we can *choose* the best moment to make the configuration active, since we have to deal with it being wrong no matter what. | 22:11 |
| davecheney | i don't think that matters | 22:11 |
| davecheney | the config changing is not the thing that broke the environment | 22:11 |
| davecheney | take the case of AWS keys chanign | 22:11 |
| niemeyer | davecheney: It matters, in the sense that we don't have to rush to replace the configuration of an environment. | 22:11 |
| davecheney | ok, so i see your concern as proxy.loop() replacing the configuration at wil | 22:12 |
| niemeyer | davecheney: Not the configuration, it is replacing *the environment* | 22:12 |
| niemeyer | davecheney: That environs.Environ, is not just a configuration | 22:12 |
| davecheney | how are those not the same thing | 22:13 |
| niemeyer | davecheney: It's the environment state we have in memory. | 22:13 |
| davecheney | the environ.Environ is formed from materialising the configuration stored in zk | 22:13 |
| niemeyer | davecheney: Is httpd and httpd.conf the same thing? | 22:13 |
| davecheney | that is not a good example | 22:13 |
| niemeyer | :-) | 22:13 |
| davecheney | but I take your point | 22:13 |
| davecheney | to offer a counter example, port 80 and httpd.conf are the same thing | 22:14 |
| niemeyer | davecheney: Wait, waht? | 22:14 |
| niemeyer | davecheney: *port 80* and *httpd.conf* are the same thing!? | 22:14 |
| davecheney | as a counter example | 22:14 |
| davecheney | not being too literal | 22:15 |
| niemeyer | davecheney: I can't process or even argue about that.. it seems so wrong in so many levels | 22:15 |
| davecheney | sure, lets get back to the point | 22:15 |
| davecheney | working from the point of view of the PA | 22:16 |
| davecheney | it needs to see changes to the topology relating to machines | 22:16 |
| niemeyer | davecheney: RIght | 22:16 |
| davecheney | and try to make reality match that | 22:16 |
| davecheney | so, it needs an Environ | 22:17 |
| davecheney | this we know | 22:17 |
| niemeyer | davecheney: Right, I'm with you | 22:17 |
| davecheney | however the PA doen't ahve environments.yaml, only the data stored in zk | 22:17 |
| davecheney | again, no supprise | 22:17 |
| niemeyer | davecheney: Right, all good | 22:17 |
| davecheney | so we've added support to state and environs to be able to construct an Envrion interface from zk data | 22:18 |
| niemeyer | Yep, sensible | 22:18 |
| niemeyer | (now comes the interesting leap) | 22:18 |
| davecheney | so, what happens when the underlying data in zk changes | 22:18 |
| davecheney | there are number of possible choices, and it looks liek I've chosen the wrong logic | 22:19 |
| * davecheney re-reads the preceeding discussion before continuing | 22:20 | |
| davecheney | ah, yes, you previously said, "If the configuration of an environment changes, we should replace its configuration at an appropriate well known time, | 22:20 |
| davecheney | " | 22:20 |
| davecheney | i offer that the proxy environ does that | 22:21 |
| davecheney | without having to teach the real environs how to do that | 22:21 |
| davecheney | and it is not papering over their limitations | 22:21 |
| davecheney | but a good seperation of concerns | 22:21 |
| davecheney | hey, what did you miss ? | 22:22 |
| niemeyer | LOL, perfect timing for the disconnection.. | 22:22 |
| niemeyer | <niemeyer> davecheney: Right, all good | 22:22 |
| niemeyer | <davecheney> so we've added support to state and environs to be able to construct an Envrion interface from zk data | 22:22 |
| niemeyer | <niemeyer> Yep, sensible | 22:22 |
| niemeyer | <niemeyer> (now comes the interesting leap) | 22:22 |
| davecheney | 08:18 < davecheney> so, what happens when the underlying data in zk changes | 22:22 |
| davecheney | 08:19 < davecheney> there are number of possible choices, and it looks liek I've chosen the wrong logic | 22:22 |
| davecheney | 08:20 * davecheney re-reads the preceeding discussion before continuing | 22:22 |
| davecheney | 08:20 < davecheney> ah, yes, you previously said, "If the configuration of an environment changes, we should replace its configuration at an appropriate well known time, | 22:23 |
| davecheney | 08:20 < davecheney> " | 22:23 |
| davecheney | 08:21 < davecheney> i offer that the proxy environ does that | 22:23 |
| davecheney | 08:21 < davecheney> without having to teach the real environs how to do that | 22:23 |
| davecheney | 08:21 < davecheney> and it is not papering over their limitations | 22:23 |
| davecheney | 08:21 < davecheney> but a good seperation of concerns | 22:23 |
| niemeyer | davecheney: and that was the interesting leap | 22:23 |
| niemeyer | davecheney: THe proxy doesn't replace the configuration.. it replaces the whole environment | 22:23 |
| davecheney | i accept that | 22:23 |
| niemeyer | davecheney: and has to wrap its whole interface so that whoever has it can pick the latest replacement | 22:24 |
| davecheney | it does so because there is no Environ.ReloadConfiguration() facility | 22:24 |
| niemeyer | davecheney: Exactly | 22:24 |
| niemeyer | davecheney: That's what we need.. well, something like it | 22:24 |
| davecheney | how would such a faciliy with given that Environ knows nothing of state | 22:24 |
| niemeyer | davecheney: SetConfig, potentially | 22:24 |
| niemeyer | davecheney: func (e) SetConfig(config EnvironConfig) error, more precisely | 22:25 |
| davecheney | ok | 22:25 |
| davecheney | i think that pushes a lot of logic down to the environ | 22:26 |
| davecheney | it may potentially hold locks while it's config is reloading | 22:27 |
| davecheney | i think using a proxy acomplishes the same thing with less work | 22:27 |
| niemeyer | davecheney: The logic is in the environment anyway, if you see it from the perspective that the wrapper is actually an environment that deals just with that one factor | 22:27 |
| davecheney | sounds like good separation of concerns | 22:28 |
| niemeyer | davecheney: Not really, from the perspective that two sequential calls to the same environment interface are actually dealing with different environments | 22:28 |
| niemeyer | davecheney: This is really not that great | 22:28 |
| davecheney | ok, now I am understanding your concern | 22:29 |
| davecheney | i see that as inevitable, and something we need to code for anyway | 22:29 |
| davecheney | as the environ can't hold any state about it's remote provider | 22:29 |
| niemeyer | davecheney: Why is it inevitable? | 22:29 |
| niemeyer | davecheney: Why? | 22:30 |
| davecheney | well it can hold state, but it must validate that state before using it | 22:30 |
| davecheney | but that is a digression | 22:30 |
| niemeyer | davecheney: Yes | 22:30 |
| davecheney | so, we're always talking about the case of AWS creds failing | 22:30 |
| davecheney | s/failing/changing | 22:30 |
| niemeyer | davecheney: Yes.. or failing.. both have to be dealt with | 22:31 |
| davecheney | so, take the case of calling .Instances() to get the instance data, then using StopInstances to stop some of those instances | 22:31 |
| davecheney | during the two calls the environ is replaced | 22:31 |
| davecheney | i dont' see the problem | 22:31 |
| davecheney | the data from Instances() comes from the real AWS somewhere, and is passed back to the real AWS in the second call | 22:32 |
| davecheney | ah, let me approach it another way | 22:32 |
| niemeyer | davecheney: I don't want to be using a value that is changing behind my feet.. I don't want to be programming with that mindset. The problems we handle are complex enough by themselves.. we don't have to spoil our own environments. | 22:32 |
| davecheney | so you are happen for the configuration inside an Environ to change, but not the reference to the Environ itself ? | 22:33 |
| niemeyer | davecheney: Yes, I'm happy to see the configuration within the environment changing when the configuration of the environment changes | 22:34 |
| niemeyer | (!) | 22:34 |
| davecheney | maybe i can approach this another way | 22:35 |
| davecheney | with a different example | 22:35 |
| davecheney | two machines are added to the topology, the PA starts the first, then is restarted, then starts the second | 22:36 |
| davecheney | the reason i ask this is I am trying to understand what is so important inside the specific instance of the real Environ that you want to preserve (that isn't its configuration) | 22:37 |
| niemeyer | davecheney: func MyFunc(e environs.Environ) { ... <code> ... }.. is it fine to replace what e *is* in the middle of MyFunc? | 22:37 |
| davecheney | niemeyer: if e is an interface, yes | 22:38 |
| davecheney | wait, let me reread that again | 22:38 |
| davecheney | yes, if e is an interface, yes | 22:38 |
| niemeyer | davecheney: Oh, ok.. so it doesn't matter how e is implemented, or what <code> does? It's always ok, necessarily? | 22:38 |
| davecheney | in the situation of juju, we have to code to taht | 22:39 |
| davecheney | for the specific case that e represents a set of calls to an external provider of resources | 22:39 |
| davecheney | here is a better example | 22:39 |
| davecheney | if e was an SQL connection | 22:39 |
| niemeyer | davecheney: Not at all.. we don't have to code with a wild environment where we have no idea about what our own code is doing | 22:39 |
| davecheney | it is well established to give back a proxy e (sql connection) that goes an gets a real sql connection when invoked | 22:40 |
| niemeyer | davecheney: You've lost me | 22:40 |
| davecheney | let me back up | 22:41 |
| niemeyer | davecheney: I have no idea about what you mean there | 22:41 |
| davecheney | lets not talk about environs for a moment | 22:41 |
| davecheney | you know how db connection pools work | 22:41 |
| niemeyer | davecheney: Yep | 22:41 |
| davecheney | you get a proxy connection from the pool, then when you do work on it, it checks out a real connection | 22:41 |
| niemeyer | davecheney: No | 22:42 |
| davecheney | ok, i'll cease that line of argument | 22:42 |
| davecheney | ok, to summarise, i am aruging that using a proxy environ achieves the same as an (unwritten) Envrion.SetConfig() | 22:42 |
| davecheney | but I can't offer any argument that says it is superior (apart from we don't ahve to write SetConfig) | 22:43 |
| davecheney | so I will drop this branch and go an do SetConfig | 22:43 |
| niemeyer | davecheney: I understand your argument, and I've been pointing out that it doesn't.. an Environ is an interface.. the implementation of that interface can do anything it pleases, cache anything it wants, start any goroutines it wants.. | 22:43 |
| davecheney | niemeyer: ok, yes, and that would be sensible | 22:44 |
| davecheney | howeve the consumer of the interface can't assume any of that | 22:44 |
| niemeyer | davecheney: Replacing the credentials that an environment uses should not destroy all of that. | 22:44 |
| niemeyer | davecheney: Nor should it cause code that takes an Environ to blindly talk to two different values in an arbitrary moment. | 22:44 |
| davecheney | ok, you've won me over | 22:45 |
| davecheney | i would point out that the python version does rebuild a new environ when the config changes | 22:45 |
| davecheney | but i won't take long to do SetConfig | 22:45 |
| niemeyer | davecheney: We're talking about *credentials*.. why are we killing the value representing the whole environment to have its credentials changed | 22:46 |
| davecheney | i have a slight concern that at some point in the future configuration may include more than credentials | 22:46 |
| davecheney | but for right now, and what we need for this cycle | 22:46 |
| davecheney | i can't see that happened | 22:46 |
| niemeyer | davecheney: The Python provisioning agent isn't something I'd put in a frame, for a few different reasons.. I'm sure you can come up with something we'll be a lot more proud of | 22:46 |
| davecheney | flattery will get you everywhere :) | 22:47 |
| niemeyer | davecheney: I'm being honest! | 22:47 |
| davecheney | ok, i'll add SetConfig | 22:47 |
| davecheney | but I would point out my concern that SetConfig will have to drop (potentially) any caches or other internal state | 22:48 |
| davecheney | but having just writtne that | 22:48 |
| davecheney | it's not going to be that hard to recognise those things | 22:48 |
| niemeyer | davecheney: Agreed, and it's also conscious.. the exact moment in time when the agent replaces the environment configuration is under our control. | 22:49 |
| davecheney | ah that raises an intersting point | 22:50 |
| davecheney | when you say under our control, i imagine you saying 'when nothing else is using it' | 22:51 |
| davecheney | is that fair to say ? | 22:51 |
| niemeyer | davecheney: You know it's not :) | 22:51 |
| davecheney | good | 22:51 |
| davecheney | because that would make things harder | 22:51 |
| niemeyer | davecheney: But the provisioning agent itself should not be spinning and replacing the configuration in the background.. there's no reason to, I believe | 22:52 |
| davecheney | so, currently in the proposed PA, the actual stop/start signal is delegated to a goroutine to handle any potential retry logic | 22:52 |
| davecheney | the aim of that was, the signal of topology change is sent one time | 22:53 |
| davecheney | on the change, you can't observe it again | 22:53 |
| davecheney | so we have to store it until it's actioned | 22:53 |
| niemeyer | davecheney: We've debated at length the idea of how the agents should be organized, and our tentative design direction was to have a main loop that is responsible for dispatching tasks | 22:53 |
| niemeyer | davecheney: I imagine the configuration replacement being done as one of the potential tasks in that main loop | 22:54 |
| davecheney | ok my recollection was the opposite, but i'm happy to be corrected | 22:54 |
| niemeyer | davecheney: That's all theoretical, but it gives you the feeling we have about the problem, at least | 22:54 |
| niemeyer | davecheney: I recall we talked about one goroutine per machine.. is that what you are alluding to? | 22:55 |
| davecheney | yes | 22:56 |
| niemeyer | davecheney: Yeah, this is a recent idea | 22:56 |
| davecheney | so, either the main loop servicing the watcher maintains a list of machines to be added and delted | 22:56 |
| niemeyer | davecheney: I'm not entirely sure about it yet.. | 22:56 |
| davecheney | then services that list when there is nothing else to do | 22:56 |
| niemeyer | davecheney: I'm not in a good position to say either way since it depends a lot on how the details are done | 22:56 |
| davecheney | or do something like this | 22:57 |
| davecheney | http://codereview.appspot.com/6220063/ | 22:57 |
| niemeyer | davecheney: I suspect having goroutines per machine should make the problem simpler, at least in terms of moving things concurrently and focusing on a single task at once | 22:57 |
| davecheney | i think so too | 22:58 |
| davecheney | however it makes the problem of reloading the environment configuration a bit trickier | 22:58 |
| niemeyer | davecheney: Still, there's some maintenance task which is unrelated to an individual machine, such as configuration changing, which seems to make sense to be done by a main loop | 22:58 |
| davecheney | as, from the point of view of those workers, it can happen at any time | 22:58 |
| niemeyer | davecheney: That orchestrates the whole thing, if you will | 22:58 |
| davecheney | yup, so it's selecting on the watcher for machines and the watcher for confgiuration | 22:58 |
| davecheney | machine changes get delegated | 22:58 |
| davecheney | configuration change call environ.SetConfig | 22:59 |
| niemeyer | davecheney: Right, but even those changes need some taking care of | 22:59 |
| niemeyer | davecheney: E.g. a controlled reboot needs to take into account those tasks | 22:59 |
| davecheney | right, you're talking about limiting work in progress and the number of concurrent connections in progress | 23:00 |
| niemeyer | davecheney: No, not just that | 23:00 |
| davecheney | can I ask a semi related question ? | 23:00 |
| niemeyer | davecheney: I'm saying that it's not just a background task that we fire and forget | 23:00 |
| davecheney | do machines, that is to say their topology name, ever get reused | 23:00 |
| niemeyer | davecheney: It needs to be managed | 23:00 |
| niemeyer | davecheney: If the provisioning agent has to reboot (e.g. upgrades) it should be done in a controlled fashion | 23:01 |
| davecheney | can you expand a bit on that last sentance pelase | 23:01 |
| niemeyer | davecheney: Pretty much all background activity must be accounted for, and properly terminated synchronously when necessary | 23:01 |
| niemeyer | davecheney: Watchers, for example, have Stop methods that request the termination of the background task | 23:01 |
| niemeyer | davecheney: Those methods are synchronous.. they ask for the background activity to die, and wait until they do so | 23:02 |
| davecheney | can you expand on this bit "If the provisioning agent has to reboot (e.g. upgrades) it should be done in a controlled fashion | 23:02 |
| niemeyer | davecheney: It's critical that things that start background activity, have hooks onto the termination of those activities, and that we can wait and verify that the given activity was ok | 23:02 |
| davecheney | specifically about rebooting the PA | 23:02 |
| niemeyer | davecheney: We need to be able to upgrade, from day zero | 23:03 |
| niemeyer | davecheney: Upgrade == get new version, unpack, reboot | 23:03 |
| niemeyer | davecheney: s/reboot/restart/, maybe that's clear | 23:03 |
| davecheney | ok, i'm not sure i understand the significance of that | 23:03 |
| niemeyer | davecheney: process stops and starts? | 23:04 |
| davecheney | i'm assuming this code will run on EC2 therefore stands a strong chance | 23:04 |
| davecheney | of being rebooted at any time | 23:04 |
| niemeyer | davecheney: Yes, why does that matter? | 23:04 |
| davecheney | i'm writing everything to assume no local state | 23:04 |
| davecheney | everything is sensed from the zk state | 23:04 |
| davecheney | and acts uppon it anew every time | 23:05 |
| niemeyer | davecheney: Yep, that's nice.. but you have local state no matter how much you pray not to.. in memory | 23:05 |
| niemeyer | davecheney: Code running, variables flowing, error conditions | 23:05 |
| davecheney | sure, but lets not get pedantic | 23:05 |
| niemeyer | davecheney: No no, I'm serious | 23:05 |
| niemeyer | davecheney: It's not ok to say 1) start machine; 2) reboot | 23:05 |
| davecheney | the only assumption i'm building on is that the watcher will always tell me about anything I have missed on the first cycle | 23:06 |
| niemeyer | davecheney: Yes, that's fine | 23:06 |
| davecheney | tf the PA can start at any point and learn about the complete topology to that point without having to maintain it's own journal | 23:06 |
| niemeyer | davecheney: I'm talking about background activity.. it's not ok to put a goroutine to do something and then ignore it | 23:06 |
| niemeyer | davecheney: Watchers have Stop methods | 23:06 |
| niemeyer | davecheney: We can stop them, and get the error condition | 23:06 |
| niemeyer | davecheney: That's not what I'm saying.. I'm saying that activities should be controllable.. it's not ok to run stuff in the background and be unable to ask them to stop or to tell if they worked or not | 23:07 |
| niemeyer | davecheney: That's hard to test, hard to debug, hard to make work correctly | 23:07 |
| davecheney | ok, i understand your concerns | 23:07 |
| davecheney | i will work towards addressing them today | 23:08 |
| niemeyer | davecheney: Python code base is largely unmanaged.. watchers are very hard to deal with | 23:08 |
| niemeyer | davecheney: We have code hacks in place for managing the watcher logic that was obtained from trial and error | 23:09 |
| niemeyer | davecheney: "Oh, hey, yeah.. maybe it's still running" | 23:09 |
| niemeyer | davecheney: That sucks.. we know better now.. let's keep track of stuff running so we have a handle on them | 23:09 |
| davecheney | right, because watchers drive twisted callbacks, which might still be firing | 23:09 |
| niemeyer | davecheney: Exactly | 23:10 |
| davecheney | so, to conclude, because this has taken a lot of your time | 23:10 |
| davecheney | you are happy for me to continue to itterat on this | 23:10 |
| davecheney | i do worry that the PA is becoming a blocker to having _something_ to get us a golang juju | 23:11 |
| niemeyer | davecheney: I am very happy with that, and I find that conversation very healthy | 23:11 |
| niemeyer | davecheney: It is a blocker indeed, but you had to learn about the problems we face | 23:11 |
| niemeyer | davecheney: and we all have to learn about how to design it properly | 23:11 |
| niemeyer | davecheney: I suggest small branches, that we can quickly merge/refactor/reject/whatever | 23:12 |
| andrewsmedina | Im back | 23:12 |
| niemeyer | davecheney: So that as a side effect of these conversations we move forward steadily, and get unblocked | 23:12 |
| * davecheney applauds | 23:12 | |
| niemeyer | Alright.. I have to go help my wife for a moment.. back later | 23:13 |
| niemeyer | andrewsmedina: Heya | 23:13 |
| davecheney | nw | 23:13 |
| davecheney | thanks for the talk | 23:13 |
| niemeyer | andrewsmedina: Will still be back today, in case you wanna talk | 23:13 |
| andrewsmedina | niemeyer: ok | 23:15 |
| andrewsmedina | niemeyer: juju client on centos working fine :D | 23:26 |
| niemeyer | andrewsmedina: Woohay | 23:33 |
| jimbaker` | andrewsmedina, is this the python version of the juju client? | 23:35 |
| niemeyer | I suppose.. the Go version isn't runnable yet | 23:35 |
| andrewsmedina | jimbaker`: in this python version | 23:39 |
| andrewsmedina | niemeyer: we will work now to do vms create by juju works fine with centos :D | 23:39 |
| niemeyer | andrewsmedina: Sweeet | 23:40 |
| niemeyer | andrewsmedina: How's the PaaS side of things going? | 23:41 |
| andrewsmedina | niemeyer: the PaaS have a cli and a webserver (rest api) both written in go | 23:43 |
| davecheney | andrewsmedina: cool | 23:43 |
| davecheney | and that runs ok on RHEL5 ? | 23:43 |
| davecheney | i ask because technically 2.6.18 isn't a supported kernel | 23:44 |
| andrewsmedina | davecheney: it's running on ubuntu at the moment | 23:44 |
| davecheney | ah, ok | 23:44 |
| andrewsmedina | davecheney: we will use centos 6. | 23:44 |
| andrewsmedina | 6.2 | 23:44 |
| davecheney | no problems then | 23:44 |
| davecheney | 2.6.32 is fine | 23:44 |
| davecheney | go could be made to run on 2.6.18 easily | 23:44 |
| andrewsmedina | to create machines for projects (django, php, rails) and services (mysql, mongo, elastic search) the webserver calls juju in the backend | 23:46 |
| andrewsmedina | and with juju we can use openstack or ec2 for IaaS | 23:46 |
| andrewsmedina | we are using openstack essex | 23:46 |
| andrewsmedina | this project is opensource https://github.com/timeredbull/tsuru | 23:47 |
| davecheney | niemeyer: are you still there | 23:50 |
| davecheney | niemeyer: nm, will be back in 30 mins (breakfast) | 23:51 |
| niemeyer | davecheney: Here | 23:51 |
| davecheney | was just looking at the latest changes to environs/interface.go | 23:52 |
| niemeyer | Trying to get that S3 signing stuff working | 23:52 |
| niemeyer | davecheney: Ok? | 23:52 |
| davecheney | what is the signature that Environs.SetConfig() should use | 23:52 |
| davecheney | should it take an EnvironConfig ? | 23:52 |
| davecheney | or just a plain map[string]interface{} | 23:52 |
| niemeyer | davecheney: Yeah, EnvironConfig | 23:53 |
| niemeyer | davecheney: So that we force the raw data to go through NewConfig | 23:53 |
| niemeyer | davecheney: Which validates and processes it into something the environment is happy with | 23:54 |
| davecheney | ok, might have to do some type checking on the way in | 23:54 |
| niemeyer | davecheney: I think it's fine to assume it's the correct one | 23:55 |
| niemeyer | davecheney: It will panic if it's not, and that seems fine given it would be a major coding mistake | 23:55 |
| davecheney | yup | 23:55 |
| davecheney | ok, afk for real this time | 23:55 |
| niemeyer | davecheney: See ya later | 23:55 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!