=== Guest2621 is now known as rogpeppe [07:42] dimitern: mornin' [07:42] rogpeppe: morning :) [07:42] rogpeppe: say, where can I get the 'propose' command to setup lbox for goose? [07:43] dimitern: i think you can just apt-get lbox, assuming you've added the right repository [07:43] dimitern: except... what's goose? [07:43] rogpeppe: the go openstack exchange - lp:goose [07:44] dimitern: ah [07:44] dimitern: have you already got lbox? [07:44] rogpeppe: no, just apt-getting it [07:45] dimitern: i think you can just use it - no setup required [07:46] rogpeppe: ok, I got lbox now, but looking into juju-core, there's the .lbox file, containing: propose -cr -for lp:juju-core [07:46] dimitern: that's actually optional, but you probably want to create it and commit it [07:46] rogpeppe: if I create a similar one for goose in the root dir, it should be "propose -cr -for lp:goose" right? [07:46] dimitern: yup [07:47] rogpeppe: and then how do I actually use it? just run $ lbox propose ? [07:47] dimitern: yeah. i usually do "lbox propose -wip" first, so i can look at the changes on codereview before sending mail to people [07:48] dimitern: you might also want to copy the .lbox.check file [07:48] dimitern: which makes some checks before allowing the proposal [07:49] dimitern: in particular it doesn't allow you to propose code that's not gofmt'd [07:49] dimitern: which is a Good Thing [07:49] rogpeppe: ok, now after committing, running lbox propose -wip opens chrome at some lp authorize token url, which is blank.. [07:50] dimitern: hmm, nothing you can enter your lp id/password into?| [07:50] rogpeppe: nah, just an empty Untitled page [07:50] dimitern: weird. what has it printed? [07:51] dimitern: lbox, that is [07:52] rogpeppe: hmm.. it seems the chrome-unstable i'm using is borked today [07:53] rogpeppe: in ff it works and asks what perms should I give to lpad [07:53] rogpeppe: Change Anything? [07:53] dimitern: i guess so [07:55] God morning, gophers. [07:57] TheMue: hiya [07:57] rogpeppe: any idea why lbox is insisting on launching chrome, when ff is my default browser? [07:57] TheMue: hey [07:57] rogpeppe, dimitern: Hi. [07:57] dimitern: no idea, sorry - it never launches any web browser for me [07:59] dimitern: Interesting, here it also never opens any browser. You do a "lbox propose" and it opens? [07:59] TheMue: I did propose -wip, and it says: Go to your browser now and authorize access to Launchpad. [07:59] Press [ENTER] after authorization is confirmed... [08:01] TheMue: after which it opens a somehow broken chrome window with an authorize token link, but the page is empty, in fact any other page I try to open in the same chrome window is empty, but if I copy the url to firefox, it works and I authorized "lpad" there, but "lbox propose -wip" then still opens chrome! [08:02] dimitern: That's indeed strange. Have to dig into my old notices how I authorized access to LP. [08:06] TheMue: so, digging into lp:lpad's go source it seems it tries to call something called "sensible-browser" - never heard of it :) but that's the broken chrome [08:06] dimitern: Me neither. [08:12] dimitern: My notes sadly only say that lbox asks for access to LP. But it seems it found the right browser when I've done it. Because I haven't made any further notices. [08:13] TheMue: I fixed it! it seems even though firefox is a default browser, chrome managed to set itself as a gnome-www-browser and x-www-browser :) [08:14] dimitern: So there are multiple default browsers, interesting behavior. [08:17] rogpeppe: when I try "lbox propose -wip" now, after doing the oauth stuff successfully, it says: error: Failed to load data for branch lp:~/goose/client-auth-refactoring: resource not found (and I did push the branch) [08:18] dimitern: hmm, odd [08:18] dimitern: have you tried running it with --verbose --debug ? [08:18] no, i'll [08:20] rogpeppe: so it produces a whole lot of logs, but what to look for? [08:20] dimitern: good question - i haven't debugged it for ages :-) [08:21] rogpeppe: wanna see the paste of it? [08:21] dimitern: go on then. [08:21] dimitern: i probably won't be able to help though, i'm afraid [08:22] rogpeppe: http://paste.ubuntu.com/1369607/ [08:23] morning all [08:23] fwereade: morning [08:23] fwereade: yo! [08:25] fwereade: maybe you can help me with lbox? [08:25] dimitern, perhaps :) [08:25] :) [08:25] dimitern, what's up with it? [08:26] so I installed it, added the .lbox and .lbox.check from juju-core, changed to lp:goose in .lbox, and then did propose -wip, launched a browser, I authorized it and then wanted to propose that branch (which has only these 2 files added) [08:27] and the verbose output I got, along with the error is pasted above [08:27] dimitern, lp:~dimitern/goose/client-auth-refactoring? [08:28] fwereade: well, it seems correct to me [08:28] and the branch is there [08:28] dimitern, oh hold on, it has lp:~/goose/... [08:29] fwereade: well spotted [08:29] rogpeppe, I'm suspicious that it doesn't actually matter though [08:29] fwereade: yes, but before I did bzr push lp:~/something... and it worked, i mean it resolved it to ~dimitern [08:30] dimitern, ah! [08:30] dimitern: it's quite possible that lbox doesn't work properly with that [08:30] dimitern, ok, cool, I had no idea you could do that :) [08:30] fwereade: neither me [08:30] fwereade: I asked jam and the guys before that bzr supports the ~ shortcut [08:30] dimitern, nice [08:31] fwereade: anyway, I should use the full name then probably, how to change it? .bzr/ something? [08:31] dimitern: try push --remember lp:~dimitern/goose/client-auth-refactoring [08:31] dimitern: and propose again and see what happens [08:31] +1 [08:32] rogpeppe: well, did that, and then lbox propose -wip -v -debug and it again tried to push lp:~/goose/client-auth-refactoring :( [08:32] dimitern: hmm. [08:33] dimitern: how about deleting the branch within launchpad [08:33] dimitern: what does bzr info print? [08:34] dimitern: hmm, it's possible that the ~/ was baked into the original oauth request, i suppose [08:34] dimitern@kubrik:~/work/goose$ bzr info [08:34] Lightweight checkout (format: 2a) [08:34] Location: [08:34] light checkout root: . [08:34] checkout of branch: .bzr/cobzr/client-auth-refactoring [08:34] shared repository: .bzr/cobzr [08:34] Related branches: [08:34] push branch: lp:~/goose/client-auth-refactoring [08:34] parent branch: .bzr/cobzr/master [08:34] and I did delete the branch and launched lbox propose again, same error, but the branch was pushed [08:34] dimitern: i know almost nothing about oauth though [08:35] dimitern: hmm, looks like it hasn't remembered properly [08:36] rogpeppe: seems so yes, but how to fix it? [08:37] dimitern: are you using cobzr? [08:37] rogpeppe: yes [08:37] dimitern, ~/.lpad? something like that to clear the stored auth, perhaps? [08:37] dimitern, delete it I mean [08:37] dimitern: in that case, try editing .bzr/cobzr//.bzr/branch/branch.conf [08:38] dimitern: and delete the push location. (in fact, what does the push location say there?) [08:38] push_location = bzr+ssh://bazaar.launchpad.net/~dimitern/goose/client-auth-refactoring/ [08:38] hmm, that looks fine [08:38] :( man, these things always happen to me [08:39] dimitern: yeah, try deleting $HOME/.lpad_oauth [08:39] dimitern: they happened to me a lot until i learned not to tickle lbox's bugs [08:40] rogpeppe: I did delete it, run it again, same error [08:40] dimitern: did it ask you to authenticate again? [08:41] rogpeppe: yes, and I did [08:41] dimitern: was it still talking about ~/goose ? [08:41] 2012/11/19 09:40:04 Pushing branch: lp:~/goose/client-auth-refactoring [08:41] 2012/11/19 09:40:08 Branch pushed successfully. [08:42] and later on: 2012/11/19 09:40:09 Loading data for branch lp:~/goose/client-auth-refactoring... [08:42] dimitern: what does your .lbox file hold? [08:42] which fails [08:42] propose -cr -for lp:goose [08:43] dimitern: has a merge proposal been created in launchpad? [08:43] rogpeppe: no, does it have to be? [08:43] dimitern: no [08:44] dimitern: that's what lbox should create [08:44] dimitern: i'm just grasping at straws here [08:44] rogpeppe: maybe because -wip was passed? [08:44] dimitern: -wip shouldn't make any difference here [08:44] dimitern: it's failing before it gets to that stage [08:45] rogpeppe: so I don't have to propose it first from lp [08:45] dimitern: nope [08:45] dimitern: lbox should do all that [08:45] rogpeppe: yeah, I thought so [08:50] dimitern: hmm, i still think the root problem is that bzr info is printing the ~/ url [08:50] rogpeppe: ok, but even so it lbox still manages to push it correctly [08:51] dimitern: that'll be because it's using bzr to push it, and bzr understands the ~/ syntax [08:51] rogpeppe: so I found a but in lbox, as such [08:51] :) [08:51] s/but/bug/ [08:52] dimitern: i am just speculating here. i don't know for sure. [08:54] rogpeppe: I think the problem is around here: http://bazaar.launchpad.net/~niemeyer/lpad/trunk/view/head:/branch.go#L16 [08:55] dimitern: yeah, i'm looking in that area [08:57] dimitern: it's quite possible that launchpad doesn't handle the ~/ prefixes in getByUrl [08:58] rogpeppe: so then patching lpad slightly to cater for lp:~ -> lp:~user before calling getByUrl should work? [08:58] dimitern: i'm not sure it's the right fix, but i'd try it anyway - if it works, we know we're on the right track [08:59] dimitern: just hack it so it replaces ~/ by ~dimitern/ [08:59] dimitern: 'cos i don't know that the Root knows the user name at that point [09:01] dimitern: what happens if you pull the branch under a different name? [09:01] dimitern: i.e. bzr branch lp:goose/trunk test-branch [09:01] dimitern: bzr switch test-branch [09:02] dimitern: lbox propose -for lp:goose -wip [09:02] dimitern: i wonder if that might work [09:03] rogpeppe: I'm trying to patch lpad branch.go first [09:03] dimitern: ok [09:04] rogpeppe: after I change it, how can I recompile it? [09:04] dimitern: go install [09:04] dimitern: rather, go install launchpad.net/lbox === jam1 is now known as jam [09:06] rogpeppe: but it's lpad actually [09:06] dimitern: if you've changed lpad, go instlling lbox will use the changed lpad [09:07] rogpeppe: ok, it worked so far [09:07] rogpeppe: It works with the patch! [09:08] dimitern: cool [09:08] dimitern: so we know what the culprit is! [09:08] dimitern: in the meantime, you could work around it, i think, by re-branching [09:08] rogpeppe: yeah [09:08] rogpeppe: rebranching? [09:09] dimitern: doing a cobzr branch, as i suggested above [09:10] rogpeppe: ok, btw it asked for www.google.com password at some point, and I used my @canonical one, but it seems it didn't like it [09:11] dimitern: hmm, have you used codereview.appspot.com before? [09:11] rogpeppe: no [09:11] dimitern: try going to that site - you may need to authorize with it separately [09:20] * TheMue has to test code with root rights, somehow not nice. [09:38] Ah, found it, a little script is helping. [09:43] fwereade: ping [09:58] TheMue, pong [09:58] TheMue, sorry, didn't see the notification [09:58] TheMue, what can I do for you? [09:58] fwereade: NP, good morning btw. [09:58] TheMue, and yourself :) [09:59] fwereade: If I'm right you share Arams interest in a container abstraction between machine and unit in the state package. Am I right? [09:59] TheMue, yeah, I think so [10:00] fwereade: Could you please tell me more about your motivation behind it? [10:00] TheMue, it's mostly based on a feeling that it is a more "correct" model of the actual situation [10:01] TheMue, and that the principal stuff is kinda tacked on to unit [10:01] TheMue, and that it would probably be happier in its own type [10:02] TheMue, but I understand that such a change will have other consequences, and I'm open to being convinced otherwise [10:05] TheMue, what's your position? [10:06] TheMue, (I can also see advantages to the principal stuff on unit, so it's not 100% clear cut) [10:07] fwereade: One moment, I'm coming back in a few minutes here. Just helping my daughter, sorry. [10:07] TheMue, np [10:13] fwereade: So, back again, sorry again. [10:14] TheMue, np :) [10:14] fwereade: To me having the container as an extra type is more natural. [10:16] fwereade: Today the assignments of units are distributed, but a container could group them better and a machine could then manage/run/contain one or more containers. [10:16] fwereade: Additionally the implementation of the watchers would be more easy. [10:19] TheMue, doesn't the unit already have a list of its subordinates? [10:19] TheMue, Subordinates []string [10:20] TheMue, and the machine has a list of principals already [10:20] TheMue, so in either case a watcher can be implemented by watching a single entity (and then death-watching its dependants) [10:20] niemeyer, heyhey [10:21] fwereade: Yes, and the new approach would be that a Machine has a slice of Containers and each Container has a slice of units. [10:22] fwereade: Good morning! [10:22] TheMue, I understand that, but I'm not sure that this change allows for a better implementation [10:22] TheMue, I'm with you on the "more natural" argument [10:22] fwereade: Each container would have one principal and the according subordinates. [10:23] TheMue, in this instance I don't see what we gain from the additional layer [10:23] fwereade: That's why I'm collecting different views and opinions, just to see, if it's worth to change it. [10:24] TheMue, personally I would like to change it but can't really justify it ;) [10:24] fwereade: As I understood Aram the implementation of watchers would be by far more simple. [10:24] TheMue, so if it were up to me I think I would regretfully resist the temptation :) [10:24] TheMue: So all it takes is to explain why that's the case [10:25] niemeyer: Good morning. [10:25] TheMue: Morning [10:25] TheMue, in either case it's a matter of a single entity watch -- the only difference is whether we're watching the unit (we can already do this) or adding a whole new type to watch [10:25] niemeyer: Yes, and that's why I'm currently collecting different views. [10:26] niemeyer, btw, this is roughly what I was babbling on about last week in the meeting [10:26] niemeyer, what the MA does to principals is the same as what a principal UA does to subordinates [10:27] niemeyer, the points of difference are (1) how to deploy and (2) what entity needs to be watched to detect new deployees [10:27] fwereade: Yeah, I can see the correlation [10:27] fwereade: As Aram said the watching of machine and unit in one watcher is somehow, hmmm, bad maintainable. [10:27] niemeyer, this feels to me like a task [10:27] fwereade: I just don't yet see the fallout of that [10:27] fwereade: (how we use that fact in a way that's not trivial) [10:28] TheMue: It doesn't matter how many people like it or don't like it.. we need to know the reasoning for doing it or not [10:29] niemeyer: Yep, that's why I'm simply collecting those pros and cons. To see if it's worth to change it or better to just keep it. [10:30] TheMue: Do you have *any* reasoning for changing it yet that you could tell us about clearly? [10:30] niemeyer: Right now I'm only have some kind of gut feeling. That's not enough. [10:31] niemeyer, well, IMO the thing it would be nice to keep a single implementation of is the watching (notify of alive additions; watch each independently for death) [10:31] niemeyer, to do that we need (1) entity watchers not to return ids, because machine and unit watchers can't currently satisfy the same interface [10:32] niemeyer, and (2) machine and unit to have a common DependantUnits() []*Unit method [10:32] niemeyer: We're collecting it in https://docs.google.com/a/canonical.com/document/d/1Chla4FgaMTlwXFdAzFv-ToN0iNsWKFECNGOCerC8PH0/edit in "Add container abstraction" - "Motivation". [10:32] niemeyer, that feels to me like it's worth the effort [10:32] fwereade: Yeah, but what then? [10:33] fwereade: How do we use that in a way that is common? [10:33] niemeyer, and if we have a Container abstraction for deploying stuff (which we do, even if no containers are involved; it's the Deployment abstraction we had in py) [10:33] niemeyer, the Machiner already takes a Container, doesn't it? [10:34] fwereade: Not sure.. looking [10:34] niemeyer, so it's the difference between fixing Machiner to do the right thing [wait, ECONTEXT, that might have changed], and turning it into a Placer which does the [10:34] niemeyer, ...right thing in both cases [10:35] niemeyer, yeah, machiner is still using Added/Removed [10:35] fwereade: Yeah, that's in review [10:35] niemeyer, ah ok [10:37] TheMue: There's no clear motivation there [10:38] TheMue: Saying it simplifies "foo" requires a leap of faith that I'm not willing to concede on without further analysis [10:39] niemeyer: One moment [10:39] TheMue: The change being suggested isn't free.. it's not *less* code [10:39] TheMue: It's *more* code, *more* logic, *more* entities [10:40] fwereade: Sounds good re. that stuff [10:41] fwereade: I don't think the ids are specially interesting so far [10:41] fwereade: I think we have perhaps a couple of places that actually use them [10:41] fwereade: and that's in testing [10:41] niemeyer, yeah, and if you started a watch you know what you're watching anyway [10:41] niemeyer, yep [10:42] fwereade: Right, we can always bundle the id in when we really care [10:45] niemeyer: As I understood Aram the code is simple and would lead to less and better maintainable code, especially for the watchers. [10:45] TheMue: Repeating things doesn't make them true :-) [10:46] TheMue: What we need is a clear analysis of why that is so [10:47] TheMue: If you're not able to articulate why that is the case, it means you don't understand it yourself [10:47] niemeyer: That's what I'm trying. Collecting pros and cons and imlementation details. [10:47] TheMue: So you should try to convince Aram that this isn't the case, until you do understand why [10:48] TheMue: It's more important to be able to talk about things like that in a way we can brainstorm on, than to file up a bullet list [10:48] niemeyer: Did you read the docuument? What do you say about the details there so far? [10:49] TheMue: There's no clear motivation there [10:49] TheMue: Saying it simplifies "foo" requires a leap of faith that I'm not willing to concede on without further analysis [10:51] niemeyer: So would be less and clearer code with better maintainability an argument for you? [10:51] TheMue: I'm concerned we're getting side-tracked onto that kind of detail that doesn't really make a difference at the moment and not making any significant progress towards implementing support for what we have to [10:52] TheMue: Definitely would [10:52] TheMue: But saying "you don't need to write that watcher" isn't it [10:53] niemeyer, (hey, a sudden thought: there is one case where we *do* want something out of an entity watcher: that's the TxnRevno for config settings) [10:53] TheMue: Because you need to add a whole new entity to the system with everything it takes instead [10:53] TheMue: So "less code" must include everything you need to *add* as well [10:53] niemeyer, (how would you feel about standardizing entity watchers on that?) [10:53] fwereade: Do we ever use that value for entities? [10:54] niemeyer, only if you consider a settings node to be an entity :) [10:54] fwereade: Right :-) [10:54] niemeyer: Sure, my feeling so far is, that we may reach todays features with less and more clear code, but I'm not yet sure. That's why I'm collection different opinions to discuss it with Aram when he's back. [10:54] fwereade: I wasn't considering that yet [10:55] TheMue: Repeating things doesn't make them true :-) [10:55] TheMue: If you're not able to articulate why that is the case, it means you don't understand it yourself [10:55] niemeyer, I'm working from a perspective from which I perceive single-thing watchers, and many-thing watchers, and feel that their respective commonalities are worth enhancing [10:55] TheMue: Which is fine on itself [10:55] niemeyer, hey wait [10:56] TheMue: But it means you should try to understand why *you* want it to be done [10:56] niemeyer, if we *did* return txnrevno, perhaps we can have only one single-thing watcher implementation [10:56] TheMue: Because so far it feels like "Hey, I want to build my own house.. please tell me why I should do that." [10:57] niemeyer: Yes, absolute. That's why I wrote "gut feeling" and why I try to understand it instead of saying "We have to change it.". And here your, Williams and Arams input do help me (beside reading the code.). [10:58] fwereade: I'm slightly concerned with the idea of binding txn-revno to it [10:58] fwereade: Watchers don't necessarily have a 1-to-1 event-to-revno-change correlation [10:58] niemeyer, I *think* that single-entity watchers do, don't they? [10:59] fwereade: Perhaps they do for now, but that's not necessarily the case [10:59] fwereade: We could easily decide to fire a, say, unit's watcher based on a correlated value [10:59] niemeyer, yeah, granted [10:59] niemeyer, cheerfully withdrawn for now [10:59] ;) [10:59] fwereade: I think settings are the exception on that [11:00] fwereade: I do appreciate your core motivation, though [11:00] niemeyer, cheers :) [11:09] niemeyer: based on your comments in a later CL, i've decided to use "CA" for everything related to the root CA certificate, and i'm losing the "root" qualifier entirely. does that sound reasonable? [11:09] niemeyer: morning, BTW! [11:09] niemeyer: for example: http://paste.ubuntu.com/1369804/ [11:19] rogpeppe: It does [11:20] rogpeppe: I think it's a short and unambiguous way to talk about the concept internally and on docs [11:20] niemeyer: there's also the potentially interesting thing that it might not necessarily be a root [11:24] rogpeppe: Indeed [11:49] lunch, bbiab [11:52] fwereade: Enjoy! [12:15] niemeyer: what do you think about CAPEM vs CA_PEM vs ... ? [12:16] niemeyer: actually... maybe just CACert is sufficient. [12:16] rogpeppe: +1 on the latter [12:20] niemeyer: morning :-) [12:21] fss: Heya [12:24] niemeyer: how is that iam CL going? [12:24] fss: Haven't seen much attention, has it [12:24] fss: I'll try to give it some love this morning still [12:24] fss: After the currently going batch of reviews [12:25] niemeyer: great, thanks! :) [14:09] fss: You've got a review there, thanks for the change btw [14:15] rogpeppe, does this look familiar? [14:15] ---------------------------------------------------------------------- [14:15] FAIL: bootstrap_test.go:42: bootstrapSuite.TestBootstrapKeyGeneration [14:15] bootstrap_test.go:45: [14:15] c.Assert(err, IsNil) [14:15] ... value *errors.errorString = &errors.errorString{s:"cannot generate CA certificate: canot create certificate: ASN.1 structure error: PrintableString contains invalid character"} ("cannot generate CA certificate: canot create certificate: ASN.1 structure error: PrintableString contains invalid character") [14:15] OOPS: 17 passed, 1 FAILED [14:15] --- FAIL: Test (8.12 seconds) [14:15] FAIL [14:15] FAIL launchpad.net/juju-core/juju 8.171s [14:15] fwereade_: hmm, i don't think i've seen that before [14:16] fwereade_: you've just pulled from trunk, i presume [14:16] rogpeppe, yeah [14:16] rogpeppe, haven't tried trunk directly yet, just a mo [14:16] fwereade_: it might be a problem in 1.0.3 but not in tip i suppose [14:18] * niemeyer => lunch [14:21] fwereade_: i'm just building 1.0.3 to test [14:22] fwereade_: yup, that's the issue [14:22] fwereade_: will fix, one mo [14:22] rogpeppe, lovely, thanks [14:33] fwereade_: hmm, i'm not sure what the best solution is here. looks like it's issue 3791, fixed by this CL https://codereview.appspot.com/6348074 [14:34] fwereade_: however i'm not entirely sure i *want* the string to turn into a utf-8 string [14:34] rogpeppe, ehhh, yes, tricky [14:34] fwereade_: i'll check it works against mgo [14:34] fwereade_: if it does, i'll go with it [14:35] * rogpeppe can't believe quite how crap x509/asn1 is [14:42] niemeyer, fwiw, http://paste.ubuntu.com/1370176/ just happened [14:44] niemeyer, fwereade_: fix trunk: https://codereview.appspot.com/6842065/ [14:44] niemeyer, fwereade_: one alternative would be to use single-quotes, i suppose [14:44] niemeyer: which i believe are allowed [14:45] rogpeppe, LGTM [14:49] fwereade_: i'll submit it now, and we can change it later if someone disagrees [14:50] fwereade_: done [14:53] rogpeppe, cheers [14:59] TheMue, rogpeppe: what (if anything) has been your involvement in recent machine unit watching discussions? [14:59] niemeyer: thanks, i will take a look later today [14:59] TheMue, rogpeppe: because I'm a bit confused about unassignment [15:00] fwereade_: Only talked with Aram about implementation details so far. About how a container would make it more simple. [15:01] fwereade_: In which way confused? [15:02] TheMue, well, we're watching for unassignments that never happen and don't matter, but ignoring the deaths that do happen and do matter, or so it seems to me [15:03] TheMue, I was hoping someone would explain why we're watching for them when there's no forseeable use case [15:04] TheMue, ATM, once the machiner is properly done, it will be (indirectly) responsible for the unassignment [15:04] TheMue, if other things unassign, which one day perhaps they may, that should also be watched for, but as it is they don't [15:05] TheMue, (also, UnassignFromMachine probably shouldn't even exist at the moment... it should be rolled into any unit destruction transaction) [15:06] fwereade_: Yo see me puzzled. [15:07] TheMue, no worries :) is aram on holiday atm? [15:07] fwereade_: Let's try to sort it again. [15:07] fwereade_: Yes, he is to a memorial. :( [15:07] :( [15:07] fwereade_: No good reason. [15:08] fwereade_: Or better said: A sad reason. [15:08] TheMue, ha, yeah, the first formulation is unhelpfully ambiguous [15:08] TheMue, ok, can I explain what I think should be going on? please jump in if I say anything that gives you pause [15:08] fwereade_: Exactly. In the moment I read it I felt so. [15:09] fwereade_: Yes, let's do so [15:09] TheMue, the MA and the UA are both responsible for the lifetimes of other units [15:09] TheMue, the MA for its principals and that UA for its subordinates [15:09] TheMue, in each case, the agent is responsible for 2 things [15:10] TheMue, 1) detecting new, alive units, and deploying them [15:10] TheMue, 2) detecting Dead units and destroying them [15:10] TheMue, any uncertainty/ambiguity thus far? [15:11] fwereade_: So far e'thing ok. [15:11] TheMue, cool [15:11] TheMue, hum, actually, I think I need to go back further [15:12] fwereade_: Adam and Eve? [15:12] TheMue, can you explain to me the deal with assignment in general? specifically why it's separate from unit creation, and whether it actually should be [15:12] s/creation/creation and destruction/ [15:14] TheMue, ie I'm not so interested in historical reasons unless they still apply [15:15] TheMue, is there any time it makes sense for a principal unit not to be assigned to a machine? [15:15] fwereade_: In the firewaller the machineData, which represents one machine, watches for its units. This is needed to see, if ports on the mache have to be opened/closed. [15:15] TheMue, I understand that units need to be assigned to machines [15:16] TheMue, I don't see why we're not doing the assignment/unassignment in the unit add/remove transactions [15:16] fwereade_: Yes, here the new (currently in review) approach of Aram shall watch all assignments. Today only the principals are watched. [15:17] TheMue, subordinates can't be assigned [15:17] fwereade_: Cheers [15:17] fwereade_: Sorry, I'm lost in the last step. [15:17] TheMue, assignToMachine will barf if you pass it a subordinate [15:18] TheMue, subordinates are in fact deployed on machines but they're not "assigned" to them [15:18] fwereade_: OK [15:19] TheMue, wait, there's the principals watcher currently in review [15:19] TheMue, the firewaller's all-units watcher is a separate problem I think [15:21] fwereade_: Aram has a change to the watchers in review, one also leads to a change in the firewaller. [15:30]