| hazmat | mramm, welcome back | 01:14 |
|---|---|---|
| mramm | hazmat: thanks | 01:14 |
| TheMue | Morning | 07:00 |
| rogpeppe1 | TheMue_, davecheney, fwereade: morning! | 07:47 |
| TheMue_ | rogpeppe1: Heyhey | 07:47 |
| fwereade | rogpeppe1, TheMue_, davecheney: heyhey | 07:52 |
| TheMue_ | fwereade: Also for you a good morning | 07:52 |
| jam | TheMue_: good morning | 08:11 |
| TheMue_ | jam: Hiya | 08:11 |
| === TheMue_ is now known as TheMue | ||
| fwereade | TheMue, rogpeppe1: do either of you have any context on what the deal is with those vast terrifying incomprehensible tables in machine_test.go? | 08:48 |
| fwereade | TheMue, rogpeppe1: ISTM that they should be completely rewritten and could probably be at least 50% smaller | 08:48 |
| === rogpeppe1 is now known as rogpeppe | ||
| * rogpeppe looks | 08:49 | |
| fwereade | TheMue, rogpeppe: but I don't know that for sure, and maybe one of you will be able to point out some way this would be a foolish move | 08:49 |
| rogpeppe | fwereade: you're talking about machinePrincipalsWatchTests, right? | 08:50 |
| fwereade | rogpeppe, all the machine watchy tests really | 08:50 |
| rogpeppe | fwereade: if you've got a nice way of making them prettier and more maintainable, i'm definitely all for that | 08:50 |
| rogpeppe | fwereade: it would be nice if all the test cases were independent, right enough | 08:51 |
| rogpeppe | fwereade: although i fear that we might slow down the testing considerably by doing that | 08:52 |
| rogpeppe | fwereade: i'd prefer to avoid another test suite that takes 2 minutes to run | 08:52 |
| fwereade | rogpeppe, yeah, it's work I don't really *want* to do, but since I need to mess with those tests destructively anyway (because they're doing totally nonsensical things with subordinates) | 08:52 |
| fwereade | rogpeppe, indeed, I shall try to figure out a way to avoid setting up and tearing down all of state in one go | 08:53 |
| fwereade | rogpeppe, incidentally, I would appreciate comments on https://codereview.appspot.com/6845120/ if you have a moment | 08:54 |
| rogpeppe | fwereade: yes, sorry, i've been fully focusing on getting an API proof-of-concept spike going the last couple of days. (i'm hoping to have something for you to have a look at later this morning) | 08:56 |
| fwereade | rogpeppe, awesome | 08:56 |
| TheMue | fwereade: I'll take a look. | 08:59 |
| * TheMue is puzzled about his firewaller test which is hanging after the last change | 09:01 | |
| fwereade | TheMue, cheers | 09:05 |
| TheMue | fwereade: Didn't forget you, just stuck in the tests. ;) So far OK, I'm only a bit unhappy with Context. | 09:36 |
| fwereade | TheMue, if yu can think of a beeter name for it I'm all ears -- or are there deeper worries? | 09:37 |
| TheMue | fwereade: No, it's exactly the name. Somehow too generic. I'm trying to find a better one, but so far I've got none. :/ | 09:38 |
| TheMue | fwereade: Where do you see the future implementations of the Context interface? At the providers? | 09:39 |
| fwereade | TheMue, I was considering Target but that wasn't quite right | 09:39 |
| fwereade | TheMue, no, I expect an LXC implementation and that's it | 09:39 |
| fwereade | TheMue, I am only aware of those two deployment styles, but I guess there may be others one day? | 09:40 |
| TheMue | fwereade: Hmm, here I'm missing the big picture. I would like to stand in front of a whiteboard with you now. :) | 09:40 |
| fwereade | TheMue, ok, I'll try to do the quick version | 09:40 |
| fwereade | TheMue, principal is to machine as subordinate is to principal | 09:41 |
| fwereade | TheMue, ie the responsibilities of a machine (wrt deployment) are the same as those of a prinicpal: the aspects that differ are (1) what setof units are relevant and (2) how those units should be deployed | 09:42 |
| fwereade | TheMue, at the moment, I plan to add deployers for both machine agents and for prinicpal unit agents, each of which will use the SimpleContext | 09:42 |
| fwereade | TheMue, once we have LXC available, the machine's deployer just swaps out the Context, and we're done | 09:43 |
| TheMue | fwereade: Thanks, makses it clearer. | 09:44 |
| fwereade | TheMue, cool | 09:44 |
| TheMue | fwereade: Sadly all the names that come into my mind now are generic too. | 09:44 |
| TheMue | fwereade: Maybe workspace, that matches to your method names. | 09:46 |
| fwereade | TheMue, hmm, interesting, I think I might like that | 09:47 |
| fwereade | TheMue, it makes me wonder whether the state info should be on the context/workspace or the Deployer | 09:48 |
| TheMue | fwereade: Cheers | 09:48 |
| fwereade | TheMue, with "context" that made sense, with "workspace" maybe less so | 09:49 |
| fwereade | TheMue, but maybe the interface should be demanding the deployer name in every method, and state info for dpeloying with | 09:49 |
| TheMue | fwereade: What exactly do you refer with "state info" to? | 09:49 |
| fwereade | TheMue, *state.Info? | 09:49 |
| TheMue | fwereade: Aargh, ok. | 09:50 |
| TheMue | fwereade: I would see a Workspace implementation only responsible for that Workspace, but everything regarding the state should be handled by the Deployer. | 09:50 |
| TheMue | fwereade: But for shure those informations could be passed to the Workspace by the Deployer initially. | 09:51 |
| fwereade | TheMue, yeah, I'll think about it :) | 09:52 |
| TheMue | fwereade: Cheers++ | 09:52 |
| TheMue | fwereade: AddUnitSubordinateTo(unit) is on Service and adds the Unit as subordinate to the Service? | 09:57 |
| fwereade | TheMue, it is currently, but I am changing that ATM | 10:04 |
| TheMue | fwereade: What will the new name be? | 10:04 |
| fwereade | TheMue, I want RelationUnit.EnsureSubordinate() | 10:04 |
| TheMue | fwereade: What we talked about, ok. Thought that this would not come. Alternatively AddUnitAsSubordinate() would also be ok, not as elegant as Ensure…, but ok. :) | 10:05 |
| fwereade | TheMue, this is unwieldy from a testing perspective, but I think right from every other perspective | 10:06 |
| fwereade | TheMue, sorry, what type would that method be on? | 10:06 |
| fwereade | TheMue, and what args? | 10:06 |
| TheMue | fwereade: Eh, as I've seen it here in the tests on Service. But you do more than just a renaming, so I have to wait and see. | 10:07 |
| fwereade | TheMue, my issue with putting it on Service is that, at the point we need to add a subordinate, we have a RelationUnit but no Service; and it seems silly to do the whole service-getting dance outside state, just so we can use a method with lots of opportunities for crackful usage, rather than to keep the fiddly details inside state and have a single method that can only be used when there's a reasonable chance of the operation being sane | 10:09 |
| fwereade | TheMue, the tests are riddled with nasty things like principals with N subordinates of the same service, and subordinates existing without having relations with their principal | 10:10 |
| fwereade | TheMue, EnsureSubordinate involves more work with the tests, but at least ensures (ha) that we can only add subordinates when it's sane to do so | 10:11 |
| TheMue | fwereade: Thanks for explanation, I only stumbled uppon the name. | 10:11 |
| fwereade | TheMue, ofc fixing all those tests is no fun, every time I look at machine_test.go my brain thinks of something else I have to do that is terribly important | 10:12 |
| fwereade | TheMue, but I'm getting there :) | 10:12 |
| TheMue | fwereade: *rofl* | 10:13 |
| rogpeppe | fuck me, it works | 10:29 |
| rogpeppe | :-) | 10:29 |
| fwereade | rogpeppe, yay! | 10:33 |
| rogpeppe | fwereade: here's the spike: https://codereview.appspot.com/6878052/ | 10:40 |
| rogpeppe | fwereade: i'm very interested to know what you think. in particular, i *think* the rpc package is quite nice, but mileages might vary significantly! | 10:41 |
| rogpeppe | TheMue: likewise, i'd like your reaction | 10:44 |
| rogpeppe | the docs for the rpc package can be viewed here: http://go.pkgdoc.org/launchpad.net/~rogpeppe/juju-core/176-rpc-spike/rpc | 10:44 |
| TheMue | rogpeppe: I'll take a look. | 10:44 |
| Aram | moin. | 10:45 |
| rogpeppe | Aram: hiya | 10:46 |
| rogpeppe | Aram: if you fancy it, you might wanna take a look at my API spike branch. https://codereview.appspot.com/6878052/ | 10:47 |
| TheMue | Aram: Moring | 10:48 |
| TheMue | s/Moring/Morning/ | 10:48 |
| Aram | rogpeppe, right away. | 10:50 |
| Aram | TheMue, cheers. | 10:50 |
| TheMue | rogpeppe: First look is impressive, need more time to get it. Will look again after found my own problem here. ;) | 10:57 |
| rogpeppe | TheMue: thanks | 10:57 |
| rogpeppe | here comes the snow... | 11:02 |
| TheMue | rogpeppe: Here we have a fine white cover since last night. Not very much, but white (and cold, -6° this morning). | 11:09 |
| rogpeppe | TheMue: it's just started snowing quite hard... i wonder how long it'll keep going | 11:10 |
| TheMue | rogpeppe: Those are the day I like working from home. ;) | 11:10 |
| rogpeppe | TheMue: me too! | 11:14 |
| fwereade | whoops, gotta dash, post office about to close, bbiab | 11:22 |
| niemeyer | Morning all | 11:39 |
| rogpeppe | niemeyer: hiya | 11:46 |
| dimitern | jam, wallyworld_ here's the first part of the nova double https://codereview.appspot.com/6877054 | 12:03 |
| wallyworld_ | cool | 12:03 |
| dimitern | jam: ping | 12:16 |
| dimitern | just a quick question - so I have that branch I proposed, but I want to keep working on the same feature, is the correct process like this: 1) create a new branch while I'm in the same branch I proposed, 2) continue working there, 3) once ready - propose it with a prerequisite=the old branch? | 12:19 |
| jam | dimitern: it depends what "keep working" means, but generally I would say yes. I'm not sure if lbox supports prerequisite branches or not, though. | 12:21 |
| dimitern | jam: yes it does | 12:22 |
| jam | --req = | 12:22 |
| dimitern | yep | 12:22 |
| dimitern | jam: keep working means continue on the same feature, even though the first branch is not merged yet | 12:23 |
| jam | dimitern: right, so it is possible that keep-working is tweaking the already proposed branch, such that you would just push up a new version. Or it can be "building stuff on top of the branch" which would be creating a new branch and using prereq | 12:24 |
| jam | Most likely what you want is a prereq | 12:24 |
| dimitern | jam: ok, so I'll do that (with the new branch of the old one) - I ask because once the proposed branch is merged, you cannot propose it again - it has to be a new one | 12:25 |
| jam | dimitern: I think 'lbox propose' will refresh the current proposal | 12:25 |
| jam | certainly you can resubmit in the lp ui | 12:25 |
| jam | I'm not 100% sure what the reitveld bits are. | 12:26 |
| dimitern | jam: not unless it's submitted (it will reopen the CL, but the merge won't work if you try submitting again)\ | 12:26 |
| Aram | lbox propose refreshes both rietveld and launchpad, yes. | 12:30 |
| Aram | basically the workflow you describe dimitern is sane, that's what we use. | 12:30 |
| Aram | do something, propose, branch into something else, propose with prereq, repeat. | 12:31 |
| dimitern | Aram: ok, thanks, good to know I'm doing it right :) | 12:31 |
| niemeyer | Gosh | 12:39 |
| niemeyer | I was trying to build a C++ program last night.. it's interesting how biased we get after we taste sane builds | 12:39 |
| niemeyer | Not only it took several hours and overheated the laptop, but it also killed my disk space | 12:40 |
| niemeyer | (which is why I'm reminding of it just now) | 12:40 |
| Aram | what the hell did you try to build? | 12:40 |
| jam | niemeyer: what were you building? | 12:40 |
| niemeyer | jam: LLVM | 12:40 |
| Aram | ah, yes. | 12:40 |
| Aram | heh. | 12:40 |
| niemeyer | 7GB on the build directory so far | 12:41 |
| niemeyer | Hasn't finished, so I don't know how much it actually takes | 12:41 |
| niemeyer | and some people complain Go binaries are large | 12:41 |
| Aram | it's interesting. Solaris was 20 million lines of C code. It took two hours to build on T410, but LLVM is significantly smaller and takes longer just because it is C++ not C. | 12:42 |
| Aram | oh, and Solaris was built twice in this time (one with gcc and once with sunpro). | 12:43 |
| rogpeppe | niemeyer: i've made a spike branch as a proof of concept around the API stuff. i'd like to know what you think. it's sketchy in many places. https://codereview.appspot.com/6878052/ | 12:46 |
| niemeyer | rogpeppe: Cool, I'll just finish this test I'm writing and we can talk | 12:46 |
| rogpeppe | niemeyer: cool | 12:47 |
| niemeyer | Why is env.Destroy hanging on TearDown of the dummy live tests? | 12:47 |
| rogpeppe | niemeyer: it works for me | 12:49 |
| niemeyer | The lack of space probably destroyed my state | 12:50 |
| niemeyer | Nope.. looks like something is actually wrong with the way dummy is managing MongoDB | 12:56 |
| niemeyer | rogpeppe: We should go back to that idea of using a single binary at some point | 13:07 |
| rogpeppe | niemeyer: agreed | 13:07 |
| rogpeppe | niemeyer: it'll be quite simple to change i think. the only wrinkle is setting up the symlinks | 13:07 |
| niemeyer | rogpeppe: How's it different? | 13:08 |
| rogpeppe | niemeyer: we'd still need binaries called "juju", "jujud", and "jujuc" even if they all point to the same thing, no? | 13:08 |
| niemeyer | rogpeppe: I don't think so | 13:08 |
| rogpeppe | niemeyer: ah ok - we just have the same binary act as all things? | 13:09 |
| niemeyer | rogpeppe: jujuc is already just a symlink target by itself | 13:09 |
| niemeyer | rogpeppe: jujud is the only one that might require some tweaking | 13:09 |
| rogpeppe | niemeyer: so the user types "juju help" and they get jujud subcommands too? | 13:09 |
| niemeyer | [LOG] 81.27788 JUJU state: connection failed: dial tcp 107.21.168.241:37017: connection refused | 13:10 |
| niemeyer | [LOG] 81.27794 JUJU state: connecting to 107.21.168.241:37017 | 13:10 |
| niemeyer | [LOG] 81.46296 JUJU state: connection failed: dial tcp 107.21.168.241:37017: connection refused | 13:10 |
| niemeyer | [LOG] 82.02849 JUJU state: connecting to 107.21.168.241:37017 | 13:10 |
| niemeyer | [LOG] 82.23336 JUJU state: connection failed: dial tcp 107.21.168.241:37017: connection refused | 13:10 |
| niemeyer | [LOG] 82.23343 JUJU state: connecting to 107.21.168.241:37017 | 13:10 |
| niemeyer | rogpeppe: Btw, we should slow that down a bit, I thnk | 13:10 |
| rogpeppe | niemeyer: i agree. perhaps an option in mgo.Info ? | 13:10 |
| niemeyer | rogpeppe: A sane default might be enough | 13:10 |
| rogpeppe | niemeyer: yeah, true | 13:11 |
| niemeyer | We're punching the server/services too hard it seems | 13:12 |
| rogpeppe | niemeyer: is it causing problems? | 13:12 |
| niemeyer | rogpeppe: It creates a fast-scrolling log, without much in return | 13:13 |
| rogpeppe | niemeyer: agreed. | 13:13 |
| niemeyer | rogpeppe: and I just got a "unauthorized access" error | 13:13 |
| niemeyer | rogpeppe: Any hints when that happens? | 13:13 |
| rogpeppe | niemeyer: did it cause a test failure? | 13:13 |
| niemeyer | rogpeppe: Yeah | 13:13 |
| rogpeppe | niemeyer: hmm. i thought i'd fixed that | 13:13 |
| niemeyer | rogpeppe: What was the cause? | 13:14 |
| rogpeppe | niemeyer: can you paste the test log? | 13:14 |
| rogpeppe | niemeyer: the race between bootstrap-state and the client connection | 13:14 |
| niemeyer | rogpeppe: The log is really uninteresting.. a long tail of attempts to connect followed by unauthorized | 13:14 |
| rogpeppe | niemeyer: which test was it? and at which point in the test was it trying to connect? the log might still be useful to show that. | 13:15 |
| rogpeppe | niemeyer: this was in the live tests? | 13:15 |
| niemeyer | rogpeppe: It's the test I'm writing, and it's trying to connect after bootstrap | 13:15 |
| niemeyer | rogpeppe: Yes | 13:15 |
| niemeyer | rogpeppe: Maybe it's my fault then.. I'll have a deeper look | 13:16 |
| rogpeppe | niemeyer: is it using juju.NewConn ? | 13:16 |
| niemeyer | rogpeppe: Yeah | 13:16 |
| niemeyer | Awww | 13:16 |
| niemeyer | It kills the machine doesn't it | 13:16 |
| rogpeppe | niemeyer: i bet bootstrap-state never ran | 13:17 |
| niemeyer | rogpeppe: Yeah, possibly.. it'd be easy to figure it out with logs | 13:17 |
| niemeyer | I mean, if I had access to the machine | 13:17 |
| niemeyer | Hmm.. I wonder if I can still check the console logs | 13:18 |
| rogpeppe | niemeyer: run the test, wait until it's started the machine, then ^C the test and ssh to the machine | 13:18 |
| niemeyer | Yep! | 13:18 |
| rogpeppe | niemeyer: do you actually see anything useful in the console logs? | 13:18 |
| niemeyer | rogpeppe: All good, it's probably me doing something silly on the test | 13:18 |
| niemeyer | rogpeppe: It couldn't find jujud | 13:19 |
| niemeyer | rogpeppe: Which is most likely me | 13:19 |
| rogpeppe | niemeyer: ah, that could explain it :-) | 13:19 |
| niemeyer | rogpeppe: I'll keep the symptom in mind :) | 13:19 |
| rogpeppe | niemeyer: there is one outstanding issue to do with unauthorized access, but i think that only happens when several clients are trying to connect concurrently. | 13:19 |
| rogpeppe | niemeyer: yeah, it would be nice to give a more helpful error. | 13:20 |
| rogpeppe | niemeyer: the only problem is that if your password is genuinely wrong, then that error message is actually correct. | 13:21 |
| niemeyer | rogpeppe: Yeah, it's a bit tricky to be helpful in this case | 13:21 |
| niemeyer | rogpeppe: Really, *anything* could go wrong | 13:21 |
| niemeyer | There I go again | 13:24 |
| niemeyer | Awesome, the failing test was entirely related to the fact the test was *supposed* to fail. | 13:29 |
| * rogpeppe goes for some lunch | 13:30 | |
| niemeyer | rogpeppe: Enjoy | 13:30 |
| niemeyer | I shall not be long either | 13:30 |
| niemeyer | mramm: ping | 13:48 |
| rogpeppe | back | 13:48 |
| niemeyer | https://codereview.appspot.com/6868070 | 13:58 |
| niemeyer | I'll step out for lunch | 13:58 |
| niemeyer | mramm: The meeting you scheduled overnight is over my lunch time.. I hope it's okay to move it forward. | 13:59 |
| andrewdeane | niemeyer, rogpeppe Hello. I'm just going through the data available. Is it possible to detail the certificate(s) associated with an environment, machine, service, unit? Thanks. | 14:50 |
| rogpeppe | andrewdeane: from what point of view are you asking? | 14:50 |
| andrewdeane | When recording the current state I'd like to see the details of the 'person' that invoked the item. | 14:52 |
| mramm | niemeyer: sure, we can move it, let's move it back though. | 14:55 |
| mramm | just ping me when you get back from lunch | 14:55 |
| rogpeppe | andrewdeane: i don't quite understand what you're saying there. what do you mean by "recording the current state" ? | 15:00 |
| rogpeppe | andrewdeane: (BTW i generally won't see remarks on IRC unless they mention my IRC nick) | 15:00 |
| rogpeppe | fwereade: ping | 15:00 |
| fwereade | rogpeppe, pong | 15:00 |
| rogpeppe | fwereade: i'm trying to understand what you're trying to protect against with the DeployerName check | 15:01 |
| rogpeppe | fwereade: when might it be triggered? | 15:01 |
| fwereade | rogpeppe, sorry, which check? the purpose of DeployerName is to distinguish between different contexts that happen to be using the same init dir | 15:02 |
| rogpeppe | fwereade: when would that happen? | 15:02 |
| andrewdeane | rogpeppe, Sorry. If I do a juju status is there a way to see who (certificates?) started the items? | 15:02 |
| fwereade | rogpeppe, any agent that runs will have an upstart job for itself in that dir that it is not responsible for | 15:02 |
| rogpeppe | andrewdeane: not currently, no. | 15:03 |
| andrewdeane | rogpeppe, any plans to, or to get the information out some other way? | 15:04 |
| fwereade | rogpeppe, and since we don't currently have LXC, we'll have (1) the machine agent which should not be removed; (2) N principals which should be touched by the machine agent only and (3) M subordinates which should each be touched only by their principal | 15:04 |
| fwereade | rogpeppe, all in the same init dir | 15:04 |
| rogpeppe | fwereade: but surely the deployer's unit watcher won't see the wrong units? | 15:04 |
| rogpeppe | fwereade: (which is what we're trying to guard against, presumable) | 15:05 |
| rogpeppe | y | 15:05 |
| rogpeppe | andrewdeane: currently there are no notions of "ownership" in the state. we might move in that direction in the future, but maybe not for a while | 15:05 |
| rogpeppe | andrewdeane: anyone with admin rights (the administrator password) can currently change anything in the state. | 15:06 |
| fwereade | rogpeppe, hmm, I suppose we could just drop the ability to list deployed services | 15:07 |
| rogpeppe | fwereade: or we could perhaps tag the upstart job name with the entity that's responsible. | 15:08 |
| fwereade | rogpeppe, that is what you're complaining about, isn't it? | 15:08 |
| andrewdeane | rogpeppe, is it true that on bootstrap we know which cert is being used? Is there a way to id those with admin rights? Incoming IP, say? | 15:08 |
| rogpeppe | fwereade: i'm mumbling because i don't understand the logic in changed() and why it's there. | 15:09 |
| rogpeppe | andrewdeane: with the API will come the ability to know who's doing what in the state. | 15:09 |
| rogpeppe | andrewdeane: then it will be easy enough to tag items with the entity that touched them | 15:09 |
| rogpeppe | andrewdeane: but first i've got to implement it! | 15:10 |
| andrewdeane | rogpeppe, :) I wont hold you to anything but do you have ball park timescales? | 15:10 |
| rogpeppe | andrewdeane: currently there are only two certificates in the system - the server's certificate and the CA certificate. | 15:10 |
| rogpeppe | andrewdeane: the API is due for 13/04, i think | 15:10 |
| fwereade | rogpeppe, I'm not sure how to answer that -- changed() makes sure that the local deployed state is what it should be, for any given unit, and recalls anything that shouldn't be there even if by some poor luck it was not mentioned in an event | 15:11 |
| fwereade | rogpeppe, eg on unit reassignment | 15:11 |
| fwereade | rogpeppe, if a unit is assigned away from a machine while the agent is down, it won't know about the unit at all when it comes back up, except by examining local state | 15:11 |
| fwereade | rogpeppe, I know we never unassign from machines in real code at the moment | 15:12 |
| andrewdeane | rogpeppe, ok. thanks. I can put placeholder fields in, in the meantime. | 15:12 |
| fwereade | rogpeppe, but since it's possible, I want to be sure it's handled sanely, even if it's kinda incomplete | 15:12 |
| fwereade | rogpeppe, ie I'm trying to handle what's currently possible sanely, not to make the whole assign/unassign functionality sane and usable at this stage | 15:13 |
| fwereade | rogpeppe, sorry gtg a mo | 15:13 |
| rogpeppe | fwereade: k | 15:14 |
| rogpeppe | fwereade: i'm trying to understand how a DeployedUnits can return the names of any units that weren't deployed by the context's deployer entity, given that the upstart job's name is tagged with that entity name. | 15:18 |
| rogpeppe | fwereade: i.e. i think we could lose the "responsible" logic entirely, and we would never see any difference in behaviour. | 15:19 |
| niemeyer | mramm: Hi | 15:19 |
| mramm | hey | 15:19 |
| niemeyer | mramm: Back and forward are interesting when talking about time | 15:20 |
| niemeyer | mramm: I tend to think that "moving forward" is making it later | 15:20 |
| niemeyer | mramm: But that's obviously subjective :) | 15:20 |
| mramm | niemeyer: forward feels like pulling it towards me | 15:21 |
| mramm | and back like pushing it away | 15:21 |
| niemeyer | mramm: TIme machines that move back in time tend to go to the past :) | 15:21 |
| mramm | niemeyer: true enough | 15:21 |
| Aram | I never understood forward and backward when talking about time. it's especially confusing during daylight changes. "how did the clock move?", "one hour forward", "wtf". | 15:21 |
| niemeyer | Aram: Yeah, I'm totally lost on those too | 15:22 |
| niemeyer | There might be some cartesian thinking there too.. I tend to think of the T axis as having positive values on the right-hand side | 15:23 |
| fwereade | rogpeppe, sorry, I forgot I was talking to you :/ | 15:35 |
| fwereade | rogpeppe, ok, what should happen when a unit is unassigned while the machine agent is down? | 15:35 |
| rogpeppe | fwereade: when it comes back up, it should remove it. | 15:36 |
| fwereade | rogpeppe, how do we do that without the responsible logic? | 15:36 |
| rogpeppe | fwereade: SimpleContainer doesn't return any units that weren't deployed by the responsible entity | 15:37 |
| rogpeppe | fwereade: so, AFAICS, the responsible logic is redundant | 15:37 |
| fwereade | rogpeppe, I don't understand how that can be the case -- I could rearrange how the deployer is written, but I still need to handle that case, don't I? | 15:39 |
| fwereade | rogpeppe, and I still need to be able to get just the units I've deployed | 15:39 |
| rogpeppe | fwereade: that's what SimpleContainer does, no? | 15:39 |
| fwereade | rogpeppe, precisely how I reconcile is open for discussion, but I picked what I did because it seemed simplest | 15:39 |
| rogpeppe | fwereade: (by including the deployer name in the upstart job name) | 15:39 |
| rogpeppe | fwereade: i may well have got the wrong end of the stick! | 15:40 |
| fwereade | rogpeppe, ah! got you! sorry, no, I did | 15:40 |
| fwereade | rogpeppe, how can we guarantee that a unit reported by WatchPrincipalUnits is still assigned to the machine that reported it? | 15:41 |
| fwereade | rogpeppe, all we know is that something changed wrt that unit | 15:42 |
| rogpeppe | fwereade: the responsible logic isn't checking the assigned machine AFAICS | 15:42 |
| fwereade | rogpeppe, `responsible = deployerName == d.ctx.DeployerName()`? | 15:43 |
| rogpeppe | fwereade: how does that tell us anything about the assigned machine? | 15:44 |
| fwereade | rogpeppe, what is deployerName? | 15:44 |
| rogpeppe | fwereade: ah, gotcha. | 15:45 |
| rogpeppe | fwereade: but if the unit *has* been assigned to a different machine, surely we'd want to kill it locally anyway> | 15:46 |
| rogpeppe | ? | 15:46 |
| fwereade | rogpeppe, we want to recall it, but not to do anything else | 15:46 |
| fwereade | rogpeppe, if it's installed and we're not responsible, we recall it | 15:47 |
| fwereade | s/installed/deployed/ | 15:47 |
| rogpeppe | fwereade: i don't like the "recall" name btw | 15:47 |
| rogpeppe | fwereade: i think "kill" might be better | 15:47 |
| fwereade | rogpeppe, whoa please no | 15:47 |
| fwereade | rogpeppe, total sematic collision with ensuredead etc | 15:47 |
| rogpeppe | fwereade: recall sounds like something fairly non-destructive | 15:47 |
| niemeyer | rogpeppe: Replied to the comments, thanks for the review | 15:48 |
| fwereade | rogpeppe, mmmaybe, although I think it is conceptually non-destructive -- put your mind 6 months in the future and consider, if the unit is unassigned and recalled, surely any persistent storage it uses will still be around ready for its new assignment | 15:50 |
| rogpeppe | fwereade: rm -rf is pretty destructive, no matter how you look at it. | 15:50 |
| fwereade | rogpeppe, won't that actually just be "unmount" in the future though? | 15:51 |
| niemeyer | fwereade: I think unassignment is the same as a Dead unit, for all purposes of the deployer, except it shouldn't remove the unit from the state | 15:51 |
| niemeyer | fwereade: I don't think we even need a noun for that.. "the unit was unassigned" sounds fine | 15:52 |
| fwereade | niemeyer, is there some way in which what I have implemented differs from that? | 15:52 |
| niemeyer | fwereade: I have no idea.. I'm commenting on top of the conversation above | 15:52 |
| niemeyer | fwereade: I'll try to review the branch today still, though | 15:52 |
| niemeyer | fwereade: I see you saying "we want to recall it", for example, and whether "kill" or "recall" is beter | 15:53 |
| niemeyer | better | 15:53 |
| niemeyer | fwereade: I think we want to remove the container, in the same way we do for a dead unit | 15:54 |
| fwereade | niemeyer, yes | 15:54 |
| fwereade | niemeyer, that is what I do | 15:54 |
| fwereade | niemeyer, "recall" is the opposite of "deploy", in english, and it seems sensible to use words in juju to mean what they mean in english where possible | 15:55 |
| niemeyer | fwereade: Cool, I'm probably just misunderstanding the context then | 15:55 |
| fwereade | niemeyer, the semantic intent is precisely "opposite of deploy" | 15:55 |
| fwereade | niemeyer, this is *currently* a destructive operation | 15:55 |
| niemeyer | fwereade: That's what I was referring to | 15:57 |
| niemeyer | fwereade: I don't *think* we need a new noun for "remove the container" | 15:57 |
| fwereade | niemeyer, but I don't think that "undeploying" a unit is necessarily always going to be so | 15:57 |
| niemeyer | fwereade: juju deploy is something pretty different | 15:57 |
| fwereade | niemeyer, ok, we agreed that "deploy" was the term to use for "install a unit agent" | 15:57 |
| fwereade | niemeyer, I implemented an Installer you told me was badly named, sight unseen, and now you're telling me that deploy is the wrong verb? | 15:58 |
| niemeyer | fwereade: Erm | 15:58 |
| niemeyer | fwereade: Sorry, please ignore me | 15:59 |
| fwereade | niemeyer, np -- I think we do have terminology problems though, in hindsight you had no way of knowing what sort of "deploy" we were talking about :) | 15:59 |
| niemeyer | fwereade: I think we have too much terminology.. I don't know what "recall" actually means, and I was hoping I wouldn't have to learn. | 16:00 |
| fwereade | niemeyer, it is the opposite of "deploy", and is used entirely within the deployer package to indicate the operation that reverses a deploy | 16:01 |
| niemeyer | fwereade: Okay | 16:02 |
| fwereade | niemeyer, I'm not emotionally attached to the name, but "undeploy" just seemed overwhelmingly sucky so I spent some time with a dictionary :) | 16:02 |
| fwereade | niemeyer, always happy to hear improvements :) | 16:03 |
| rogpeppe | fwereade: remove? | 16:04 |
| fwereade | rogpeppe, collides with other remove operations in the package | 16:04 |
| fwereade | rogpeppe, words involving death collide with death-related operations used in the package | 16:04 |
| rogpeppe | fwereade: RemoveDeployment ? :-) | 16:04 |
| rogpeppe | niemeyer: replied https://codereview.appspot.com/6868070/ | 16:05 |
| rogpeppe | niemeyer: if you've got a little while at some point, i'd like to have a chat about the API stuff | 16:06 |
| fwereade | rogpeppe, is life *so* boring that we need to overload terminology to keep ourselves on our toes? | 16:06 |
| niemeyer | fwereade: recall is fine | 16:06 |
| fwereade | rogpeppe, (and what makes you think that recalling intrinsically "removes" anything? ;)) | 16:07 |
| fwereade | niemeyer, cheers | 16:07 |
| niemeyer | fwereade: I mainly wondered if we could avoid the term altogether.. maybe we can't | 16:07 |
| niemeyer | fwereade: (rather than suggested there was another term that would fit better) | 16:07 |
| rogpeppe | fwereade: "os.RemoveAll(agentDir)" :-) | 16:07 |
| fwereade | niemeyer, it's not something that anyone needs to know unless they're directly working withing the deployer package | 16:07 |
| fwereade | rogpeppe, and? | 16:08 |
| fwereade | rogpeppe, that is the only possible implementation? | 16:08 |
| fwereade | rogpeppe, we have no persistent storage features planned? | 16:08 |
| rogpeppe | fwereade: we do, but they might not be always active. | 16:08 |
| rogpeppe | fwereade: "Recall" sounds like it's fetching something | 16:09 |
| rogpeppe | fwereade: but it's actually removing local state pertaining to the deployed unit | 16:09 |
| fwereade | rogpeppe, my point is that all your suggestions carry a "this is a destructive operation" payload, and I don't think that's necesarily appropriate | 16:09 |
| niemeyer | Really, recall is fine.. the discussion I was trying to avoid is already happening :) | 16:09 |
| fwereade | niemeyer, ha, yeah, I will be quiet :) | 16:10 |
| niemeyer | We all know what "recall" means now :) | 16:10 |
| rogpeppe | niemeyer: ok, if you're ok with it, i'll go with it too :-) | 16:10 |
| fwereade | niemeyer, haha | 16:10 |
| fwereade | rogpeppe, cheers | 16:10 |
| fwereade | huh, cath has done a super-early supper, I'll be back in a sec | 16:10 |
| mramm | I'm heading out to a lunch meeting, will be back in a bit. | 16:21 |
| mramm | if you need me in the meantime my phone is operational again, so feel free to call/text | 16:22 |
| rogpeppe | niemeyer: any chance of that chat some time today? (sorry to poke, but it would be nice to have an idea if i'm totally off in the wrong direction) | 16:50 |
| niemeyer | rogpeppe: Oh yeah, thanks for poking, I forgot actually | 16:50 |
| niemeyer | rogpeppe: What's up? | 16:50 |
| rogpeppe | niemeyer: i did a spike branch, just to see if some ideas would work out | 16:50 |
| rogpeppe | niemeyer: it's only a sketch in quite a few places, but it does give an idea of how it might work, end-to-end: https://codereview.appspot.com/6878052/ | 16:51 |
| rogpeppe | niemeyer: crucial pieces are: | 16:51 |
| rogpeppe | http://bazaar.launchpad.net/+branch/~rogpeppe/juju-core/176-rpc-spike/view/head:/state/api/serve.go | 16:51 |
| rogpeppe | http://go.pkgdoc.org/launchpad.net/~rogpeppe/juju-core/176-rpc-spike/rpc#NewServer | 16:52 |
| rogpeppe | niemeyer: the former is how the API surface is implemented at by the server. the latter is the piece of magic that makes it possible. | 16:52 |
| rogpeppe | s/at by/by/ | 16:53 |
| niemeyer | rogpeppe: Well, there are thousands of lines in there.. I can't really comment on it without sitting down and reading what's going on | 16:53 |
| rogpeppe | niemeyer: that's why i pointed you at the NewServer docs | 16:54 |
| rogpeppe | niemeyer: which should give an idea, even without looking at the implementation | 16:54 |
| niemeyer | rogpeppe: A Server with an Accept method.. yeah, that sounds fine :-) | 16:54 |
| rogpeppe | niemeyer: the idea is that a single API implementation can provide access to both http and connection-based RPC interfaces. | 16:55 |
| rogpeppe | niemeyer: i've modelled the rpc package quite strongly on net/rpc where appropriate | 16:56 |
| rogpeppe | s/on/after/ | 16:56 |
| niemeyer | rogpeppe: That kind of stuff is a bit dubious: "If a path element contains a hyphen (-) character, the method's argument type T must be string, and it will be supplied from any characters after the hyphen." | 16:58 |
| rogpeppe | niemeyer: that's so you can use a path like: /State/Machine-0/InstanceId | 16:59 |
| niemeyer | rogpeppe: There seems to be quite a bit of generality built on that interface | 16:59 |
| niemeyer | rogpeppe: I'd feel more comfortable with an API that was highly tailored for our specific problem | 16:59 |
| niemeyer | rogpeppe: with one encoding, that is known sensible for all use cases we have in mind | 17:00 |
| niemeyer | rogpeppe: we're not building net/rpc, in that sense | 17:00 |
| rogpeppe | niemeyer: i think we want to provide both http access and RPC-style access | 17:00 |
| niemeyer | rogpeppe: We discussed this over UDS, I think | 17:00 |
| niemeyer | rogpeppe: The strawman was attempt to have https only | 17:01 |
| niemeyer | rogpeppe: and see where that would lead | 17:01 |
| rogpeppe | niemeyer: even if we don't provide access via multiple protocols, i still think this package is a good way to do it | 17:02 |
| niemeyer | rogpeppe: Having stuff like XML there makes it pretty clear that we're over-engineering it, and stumbling upon that while trying to tailor it to our needs | 17:02 |
| niemeyer | rogpeppe: (as the /State/Machine-0/InstanceId edge case indicates) | 17:02 |
| rogpeppe | niemeyer: the XML stuff is like 10 lines of code | 17:02 |
| niemeyer | rogpeppe: It could be 2 | 17:02 |
| niemeyer | rogpeppe: Or one | 17:02 |
| niemeyer | rogpeppe: It's still XML, and we don't want to use that | 17:02 |
| rogpeppe | niemeyer: sure. i just put it in there because it only took 10s to type | 17:03 |
| niemeyer | rogpeppe: EC2 is a lesson in that sense.. there are two interfaces | 17:03 |
| niemeyer | rogpeppe: And no body but the heaviest Java pundits use that | 17:03 |
| rogpeppe | niemeyer: http://paste.ubuntu.com/1412851/ | 17:03 |
| niemeyer | rogpeppe: You see my underlying point, though? | 17:04 |
| niemeyer | rogpeppe: It took 10 seconds to put it in there because there's a *LOT* of logic to make that possible | 17:04 |
| rogpeppe | niemeyer: so do you think we should build it as a standard web server, with no websockets? | 17:04 |
| rogpeppe | niemeyer: i hadn't thought we'd decided that at UDS. | 17:05 |
| niemeyer | rogpeppe: Erm.. how did websockets get into the above context? | 17:05 |
| rogpeppe | niemeyer: well, there's a significant difference between serving GET requests and serving messages from a websocket | 17:05 |
| niemeyer | rogpeppe: I bet.. still.. !? | 17:06 |
| rogpeppe | niemeyer: i'd be happy if we could do both. | 17:06 |
| niemeyer | rogpeppe: Ah, I see | 17:06 |
| niemeyer | rogpeppe: Rather than designing two entirely different API mechanisms at once, it feels like we could try to get one of them right | 17:07 |
| rogpeppe | niemeyer: this package means we can serve them both with the same implementation | 17:08 |
| niemeyer | rogpeppe: Understood, the comments above take that into account | 17:08 |
| rogpeppe | niemeyer: agreed. i'd start with the websocket implementation, in that case. | 17:08 |
| rogpeppe | niemeyer: and i *still* think this would be a useful package for that. | 17:09 |
| rogpeppe | niemeyer: because net/rpc is not sufficient | 17:09 |
| niemeyer | rogpeppe: I'm not sure.. I'd start with the http package, and the websocket package | 17:09 |
| rogpeppe | niemeyer: so where do we deal with the message processing? | 17:09 |
| rogpeppe | niemeyer: this rpc package is my way of trying to abstract that ou | 17:10 |
| rogpeppe | out | 17:10 |
| rogpeppe | niemeyer: in the same way that net/rpc does, but a little more general | 17:10 |
| rogpeppe | niemeyer: in that it allows rpc calls to know the context of the connection that's making the call | 17:10 |
| rogpeppe | niemeyer: i *think* it makes for a very natural style of implementation of the API, while keeping all the RPC gunge out of the way. | 17:13 |
| niemeyer | rogpeppe: I'm trying to understand what that would mean, but I can't see that yet | 17:14 |
| rogpeppe | niemeyer: did you look at the server implementation? http://bazaar.launchpad.net/+branch/~rogpeppe/juju-core/176-rpc-spike/view/head:/state/api/serve.go | 17:14 |
| niemeyer | rogpeppe: It seems that most of whta is there is a generic mechanism to plug different codecs | 17:14 |
| niemeyer | rogpeppe: Without any correlation to the needs of the underlying infrastructure | 17:14 |
| rogpeppe | niemeyer: you could delete all the codec stuff and it would still be useful | 17:14 |
| rogpeppe | niemeyer: for instance we could hard-code JSON | 17:15 |
| rogpeppe | niemeyer: that would be fine | 17:15 |
| niemeyer | rogpeppe: What are we getting out of it then? | 17:16 |
| niemeyer | rogpeppe: http://gary.beagledreams.com/page/go-websocket-chat.html | 17:16 |
| niemeyer | rogpeppe: This is where I would start | 17:16 |
| rogpeppe | niemeyer: i've written something that sends and receives messages over websockets already | 17:17 |
| niemeyer | rogpeppe: It seems a few orders of magnitude more straightforward than the logic that is in that rpc package | 17:17 |
| niemeyer | rogpeppe: I'm not saying that stuff is impossible to do with your implementation.. I bet you can do anything with it. :-) | 17:17 |
| rogpeppe | niemeyer: but we don't want to manually marshal and unmarshal messages for every single call in the API | 17:18 |
| niemeyer | rogpeppe: No, we don't.. we also don't want to implement a generic net/rpc package that is even more generic than net/rpc | 17:18 |
| niemeyer | rogpeppe: There's a sweet spot in between, and hopefully that sweet spot is actually trivial to implement | 17:18 |
| rogpeppe | niemeyer: well, it *needs* to be more generic than net/rpc | 17:19 |
| rogpeppe | niemeyer: because net/rpc doesn't provide what we need | 17:19 |
| niemeyer | rogpeppe: It doesn't have to be generic at all, IMHO.. it has to solve our problem, our very specific problem.. not anyone else's problem | 17:19 |
| rogpeppe | niemeyer: i thought it was quite neat :-( | 17:19 |
| niemeyer | rogpeppe: It seems super neat, and a lot of people will love that I think.. | 17:20 |
| niemeyer | rogpeppe: But we have a smaller issue to solve | 17:20 |
| rogpeppe | niemeyer: agreed, but our API surface is fairly broad. i was trying to think of something just sufficiently broad to solve our problem. | 17:20 |
| niemeyer | rogpeppe: Okay, *that* is exactly the problem | 17:21 |
| niemeyer | rogpeppe: I suggest we start by *having* the problem, and walking up from there | 17:21 |
| rogpeppe | niemeyer: where do you think i should start then? | 17:21 |
| niemeyer | rogpeppe: By implementing one tiny API call that actually works | 17:22 |
| niemeyer | rogpeppe: Without significant infrastructure to support everything we think we may need for everything we think we'll do | 17:22 |
| rogpeppe | niemeyer: ok, so don't use net/rpc at all then. | 17:23 |
| niemeyer | rogpeppe: Right | 17:23 |
| rogpeppe | niemeyer: ok, i'll start there. and i still think that what i've just made will be a good fit for what we'll need, but i take your point that it's perhaps overly general. | 17:24 |
| rogpeppe | niemeyer: i built something that would make building what we need fairly trivial, which i thought was a reasonable approach. | 17:25 |
| niemeyer | rogpeppe: I reserve my right to doubt that this net/rpc replacement makes building what we need fairly trivial. | 17:26 |
| rogpeppe | niemeyer: but still, only three days lost. | 17:26 |
| niemeyer | rogpeppe: We have enough track record about "fairly trivial" changes by now :) | 17:27 |
| rogpeppe | niemeyer: yeah, "fairly trivial" means "i can see a clear path" :-) | 17:27 |
| niemeyer | rogpeppe: Exactly, a path to somewhere.. but given that we don't have a working API, and are not even close to having one, we don't know where that path really leads | 17:28 |
| niemeyer | rogpeppe: There's a lot of value in putting stuff to actually work, and learning about what it takes to do that | 17:28 |
| rogpeppe | niemeyer: well, that branch does include at least one test from the state package that passes. | 17:28 |
| rogpeppe | niemeyer: which seems not a million miles away from having a working API | 17:29 |
| niemeyer | rogpeppe: In 20 minutes I can code a websocket that talks across the wire to the state package | 17:30 |
| niemeyer | rogpeppe: I'd still consider myself completely ignorant about what it takes to make all the juju communication work across the wire | 17:30 |
| niemeyer | rogpeppe: But that's just me.. perhaps I'm just pessimistic about myself. | 17:31 |
| rogpeppe | niemeyer: in a few days, i reckon i could get most of the non-watcher state tests passing. but perhaps that would still be "not even close". | 17:36 |
| niemeyer | rogpeppe: That's great to hear.. maybe we can have the API working even before christmas then | 17:39 |
| rogpeppe | niemeyer: without some equivalent of net/rpc, i'm not sure. | 17:39 |
| rogpeppe | niemeyer: oh, sorry, that was sarcasm, right? | 17:43 |
| niemeyer | rogpeppe: Not at all, I was seriuos | 17:47 |
| niemeyer | rogpeppe: If you can get everything all of state in three days, it doesn't feel off-the-park to have most of it in 2.5 weeks | 17:47 |
| rogpeppe | niemeyer: i could only do that because my rpc package makes it straightforward | 17:48 |
| niemeyer | rogpeppe: heh | 17:48 |
| rogpeppe | niemeyer: because all the bookkeeping is hidden away | 17:48 |
| niemeyer | rogpeppe: I'm only suggesting doing what we actually need, rather than what we need and what we don't | 17:48 |
| niemeyer | rogpeppe: There's nothing about websockets there, there's nothing about auth there, there's nothing about a lot of stuff there | 17:49 |
| rogpeppe | niemeyer: websockets are trivial to add, and so is auth | 17:49 |
| rogpeppe | niemeyer: i designed it with both in mind | 17:49 |
| niemeyer | rogpeppe: Can you explain how websockets is trivial to add there and is so hard without it? | 17:50 |
| niemeyer | rogpeppe: Because this: http://gary.beagledreams.com/page/go-websocket-chat.html, is surprisingly similar to what we want | 17:50 |
| niemeyer | rogpeppe: and it has a fraction of the size | 17:50 |
| rogpeppe | niemeyer: most of the code that we will be writing will be working out what call has been made, marshalling and unmarshalling parameters, and checking authorisation. | 17:51 |
| rogpeppe | niemeyer: not dealing with websockets directly | 17:51 |
| rogpeppe | niemeyer: that example has only a single message type | 17:51 |
| rogpeppe | niemeyer: and no authorisation | 17:52 |
| rogpeppe | niemeyer: we've got about 60 calls in our API used outside of state | 17:53 |
| niemeyer | rogpeppe: http://go.pkgdoc.org/code.google.com/p/go.net/websocket | 17:53 |
| niemeyer | var JSON = Codec{jsonMarshal, jsonUnmarshal} | 17:53 |
| niemeyer | type T struct { | 17:53 |
| niemeyer | Msg string | 17:53 |
| niemeyer | Count int | 17:53 |
| niemeyer | } | 17:53 |
| niemeyer | rogpeppe: You see the similarity in terminology? | 17:53 |
| niemeyer | type Codec struct { | 17:54 |
| niemeyer | Marshal func(v interface{}) (data []byte, payloadType byte, err error) | 17:54 |
| niemeyer | Unmarshal func(data []byte, payloadType byte, v interface{}) (err error) | 17:54 |
| niemeyer | } | 17:54 |
| niemeyer | func (cd Codec) Send(ws *Conn, v interface{}) (err error) | 17:54 |
| rogpeppe | niemeyer: it can encode and decode json messages... and? | 17:54 |
| niemeyer | rogpeppe: and!? | 17:55 |
| rogpeppe | niemeyer: that's a fraction of what we need to do | 17:55 |
| niemeyer | rogpeppe: Exactly, that's all pretty close to what that package implements | 17:55 |
| niemeyer | rogpeppe: Codecs, marshalling, unmarshalling | 17:55 |
| niemeyer | rogpeppe: There's missing logic.. let's add it | 17:55 |
| rogpeppe | niemeyer: yes, and none of that is implemented by my rpc package | 17:55 |
| rogpeppe | niemeyer: it just uses codecs from outside | 17:55 |
| niemeyer | rogpeppe: Okay, sorry, if you think state is going to be ready before the end of the week, please go for it. | 17:56 |
| niemeyer | rogpeppe: We're clearly talking across each other without much benefit | 17:56 |
| niemeyer | rogpeppe: If state isn't ready by the end of the week, we can talk again | 17:56 |
| rogpeppe | niemeyer: i will implement a direct websocket implementation to show where we might be headed without something like net/rpc. | 17:56 |
| TheMue | Yiiiiiiiiehaaa! After a wrong direction and fiddling why that breaks I think the firewaller is stable now. I'll add some explicitely stressing tests tomorrow, but it looks good. *phew* | 17:57 |
| rogpeppe | niemeyer: and then hopefully it'll be more clear what the advantages are | 17:57 |
| niemeyer | rogpeppe: Please don't do that.. I'm not interested in you coding logic to prove how bad it will look like | 17:57 |
| rogpeppe | niemeyer: in which case i don't know what to do | 17:57 |
| rogpeppe | niemeyer: i'd try to make it look as nice as possible | 17:58 |
| niemeyer | rogpeppe: I was hoping to collaborate to a working prototype, without creating massive infrastructure which is obviously necessary, despite the fact we have no idea | 17:58 |
| niemeyer | rogpeppe: The freaking thing supports XML for god's sake | 17:58 |
| rogpeppe | niemeyer: only because it was ultra-trivial to do | 17:58 |
| rogpeppe | niemeyer: (and actually it doesn't work :-]) | 17:58 |
| niemeyer | rogpeppe: Yeah, it's trivial to put a car within an airplane, once you have the airplane | 17:59 |
| * rogpeppe should have known that typing the letters X-M-L was a mistake | 17:59 | |
| niemeyer | rogpeppe: But this isn't being productive.. there's no point in you working on stuff you're unhappy about | 17:59 |
| rogpeppe | niemeyer: i think that putting in the infrastructure for the websocket stuff from the bottom up would actually be a good thing | 18:00 |
| niemeyer | rogpeppe: My personal opinion is that the current super-net/rpc package is a pretty trivial part of the problem we have to solve, and I'd prefer to focus on the problem itself rather than trying to put yet another layer we don't even understand | 18:00 |
| niemeyer | rogpeppe: But there's an easy way out: you said it's going to be ready in three days, so go for it. | 18:01 |
| rogpeppe | niemeyer: then when we've sent a few messages back and forth, we can see if something like my rpc package might be a good fit. | 18:01 |
| niemeyer | rogpeppe: Won't be much time spent, and will be a learning exercise anyway. | 18:01 |
| niemeyer | rogpeppe: I think there's a non-trivial number of pieces missing, that will guarantee thousands of additional lines | 18:01 |
| rogpeppe | niemeyer: it's a spike. even if i get things working, it's still a spike. | 18:01 |
| rogpeppe | niemeyer: out of interest, what pieces are you thinking of particularly? | 18:02 |
| rogpeppe | niemeyer: i'm wondering where you see the blocking points | 18:02 |
| niemeyer | rogpeppe: Well, it's not a code spike.. a spike is something we code to understand a problem. This is a pretty polished API that is documented and that you're attached to already | 18:03 |
| rogpeppe | niemeyer: it really was code to try to understand how i might solve the problem | 18:03 |
| rogpeppe | niemeyer: even if i did write some doc comments | 18:03 |
| rogpeppe | niemeyer: (which i actually wrote before i wrote the code, so i had an idea of what i was trying to do) | 18:04 |
| rogpeppe | niemeyer: and it's true i think it turned out quite nice, but there y'go. | 18:05 |
| rogpeppe | niemeyer: anyway, gotta go. | 18:05 |
| rogpeppe | niemeyer: see you tomorrow | 18:05 |
| niemeyer | rogpeppe: See ya | 18:05 |
| niemeyer | This reminds me of Launchpad's API all over again | 18:06 |
| niemeyer | rogpeppe: That sounds like a side effect of that design, for example: | 18:15 |
| niemeyer | 102 path := fmt.Sprintf("/Machine-%s/SetInstanceId", m.Id) | 18:15 |
| niemeyer | 103 return m.state.c.Call(path, instId, nil) | 18:15 |
| niemeyer | rogpeppe: The natural design on that is to have the equivalent of {"method": "set-instance-id", "machine": m.Id, "instance-id": instId} | 18:16 |
| niemeyer | (disconsidering marshalling issues.. that's a map in whatever format we decide to us) | 18:17 |
| niemeyer | use | 18:17 |
| niemeyer | Possibly with an additional "request-id" key too | 18:18 |
| niemeyer | I guess I suck at explaining.. I should try to do what I do best and code it | 18:24 |
| * niemeyer => doc appointment.. back later | 18:49 | |
| fwereade | niemeyer, ping | 21:44 |
| fwereade | niemeyer, in case you come back, please consider what the Dying state might mean for a Machine; I'm starting to believe it's meaningless (setting a machine to Dying should not, I think, affect its units; so a Dying machine generally just sits there forever (or at least until all its units are unassigned; but having a long-running machine which cannot have further units assigned feels like crack, as does the alternative of allowing units to be assigned t | 23:10 |
| fwereade | o Dying machines | 23:10 |
| fwereade | ) | 23:10 |
| fwereade | niemeyer, grar, just thought of something: there's an additional constraint on subordinate relations, which is that the principal and the subordinate charms must have the same series | 23:13 |
| * fwereade will stop dumping random thoughts into the channel and go to bed | 23:14 | |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!