[07:35] morning! [08:00] rog: hiya [08:01] TheMue: yo! === Leseb_ is now known as Leseb [08:03] weird problem: i'm changing a time.Sleep statement. if it's 0.1 seconds, the test runs for 6.749s. if it's 1 second, the test runs for 9.375s. [08:04] i wonder if time is moving wrongly on this machine [08:06] ah, easy answer! the test is run three times... [08:09] hehe, so no wonder [08:35] fwereade: morning [08:35] TheMue, heyhey [08:44] fwereade: i've just submitted the long-time-pending branch of gnuflag that adds SetOutput, amongst other things [08:44] fwereade: i was waiting for a review from niemeyer, but it never came [08:44] rog, awesome, tyvm [08:45] rog, I have a trivial here to get a very few tests passing again with the new gocheck: http://paste.ubuntu.com/858896/ [08:46] fwereade: LGTM [08:46] fwereade: i'm just about to have a look at your new persistence branch BTW [08:46] fwereade: and thanks for the review of go-ec2-robustness [08:46] rog, a pleasure :) [08:47] fwereade: glad you liked the attempt type :-) [08:47] * fwereade tries to remember what branches he has queued up [08:47] (i thought it was quite neat) [08:47] rog, yes indeed, that branch made me happy :) [08:49] fwereade: a previous branch had a version of this code in, which made quite a nice pair with attempt, but it became unnecessary, so i deleted it, with slight regret. http://code.google.com/p/rog-go/source/browse/parallel/parallel.go [08:50] rog, nice :) [09:14] TheMue: I have some trivial changes to make state work with the new gocheck: http://paste.ubuntu.com/858916/ [09:16] fwereade: yep, i'm just doing it [09:16] TheMue, ah sorry, I should have coordinated [09:17] TheMue, rog: is there a part of juju/go whose test failures are *not* being looked at by one of you, that I can pop in and fix quickly? [09:18] fwereade: I'll do everything below state [09:18] TheMue, cool [09:19] rog, is any of what remains under your aegis or shall I just work through them? [09:19] TheMue, do you mean to include store in what you said or not? [09:20] fwereade: no, only state. i don't know what gustavo already did there [09:21] TheMue, rog: ok, I'll pick something not in state at random and go from there [09:21] fwereade: sounds reasonable [09:22] fwereade: i'm happy to do everything under environs [09:22] TheMue, btw, the patch above seems to fix all the actual failures; it doesn't deal with switching to HasLen where appropriate [09:22] rog, cool [09:22] fwereade: i'll just go and update gocheck [09:22] fwereade: i'll take a look [09:24] fwereade: i'm slightly concerned about tests that do: c.Assert(x, Not(Equals), y) [09:24] fwereade: because they won't necessarily fail though they'll be wrong [09:24] fwereade: worth looking for, i think [09:25] rog, hmm; I haven't seen many of those thankfully, but I'll try to give every Equals at least a quick glance ;) [09:35] rog, TheMue: would one of you cast an eye over http://paste.ubuntu.com/858930/ please? [09:35] on it [09:36] * TheMue too (and I would like a neat diff visualizer) [09:36] fwereade: bug := Commentf("ParseURL(%q)", t.s) [09:36] fwereade: seems wrong [09:37] fwereade: shouldn't be named "bug" any more... [09:37] rog, good point, ty [09:37] TheMue: bzr qdiff works well [09:37] TheMue: also we've got codereview.com :-) [09:38] rog: I meant in web instead of using paste… here [09:38] TheMue: yeah, well that's why we've got rietveld... [09:39] TheMue, ah, sorry, I was thinking most of these were quite well suited to plain-ol-diff format [09:39] fwereade: they were [09:39] fwereade: LGTM modulo s/bug/com(ent)?/ [09:39] s/ent/ment/ :-) [09:39] rog, cool, I called it comment [09:40] rog, fwereade: like many pastes provide syntax highlighting i just would like a better visualization of a pasted diff. good uis are nothing bad. [09:41] TheMue, rog: do we want double-reviews for these or are we ok with a single LGTM? [09:41] fwereade: i think we're fine with single LGTMs for these [09:42] TheMue, sorry, I didn't intend any unnecessary cognitive load [09:42] rog, fwereade: ack [09:42] TheMue, I'll lbox propose the next one, doesn't cost me much ;) [09:43] fwereade: no, that's not your problem, no need to excuse. only a feature wish to pasting-plattforms [09:44] fwereade: even w/o lbox it should be possible to create more readable diff vizualizations [09:45] fwereade: at least coloring - in red and + in green [09:45] TheMue, quite so, syntax highlighting on paste.ubuntu.com would be nice (as long as I didn't have to think about it at all ;)) [09:46] fwereade: yep, just paste, the system guesses (or you set a lang or diff) and done [09:48] rog, TheMue: first one to ack gets the glory of reviewing this not-really-very-complex-but-nonetheless-unhighlighted diff: http://paste.ubuntu.com/858944/ [09:48] ack [09:48] ack [09:49] fwereade: LGTM [09:49] fwereade: BTW i think these should probably go through lbox propose anyway, just for the annotations [09:50] rog, I planned to do that, and then cloudinit seemed so trivial as to be mocking me ;) [09:50] rog, will do though [09:50] fwereade: do 'em all in one branch [09:51] rog, as you like it :) [09:51] fwereade: (i can't see any reason to do a separate branch for each package - they're all fixes relating to the same thing) [09:52] rog, optimal triviality of reviewing :) [09:52] amortised anyway... [09:53] rog, or at least "perceived" ;) [10:00] fwereade: what's a good way to "un-diverge" a branch when it says it's diverged? [10:00] (i only forked it earlier this morning) [10:00] fwereade: i did merge with trunk [10:00] fwereade: still diverged [10:00] rog, not really sure I'm afraid :( [10:01] rog, I have on occasion got myself out of such holes with voodoo and magic that I don't recall [10:01] ah, i've discovered the problem! [10:01] rog, but last time I think I went straight to diff, fresh branch, patch [10:01] fwereade: lbox was trying to push to lp:juju/go [10:01] rog, oh yes? [10:01] fwereade: i forgot to do the manual push [10:02] rog, cool [10:02] fwereade: would be nice if it mentioned the name of the branch it failed to push to... [10:02] rog, ha, yeah [10:11] fwereade, TheMue: first to ack gets it: https://codereview.appspot.com/5699085/ [10:11] rog, ack [10:12] rog, TheMue: https://codereview.appspot.com/5701056 [10:13] fwereade: LGTM [10:14] rog, LGTM also [10:15] rog, get yours in first and I'll merge and submit afterwards [10:15] fwereade: submitted [10:16] fwereade: thanks [10:18] rog, and likewise and likewise :) [10:31] So, https://codereview.appspot.com/5671055/ and https://codereview.appspot.com/5690051/ urgently need their LGTM to move into the trunk. [10:32] TheMue: the second one can't be reviewed until the first one is submitted [10:33] TheMue: and the first one is waiting for a LGTM from niemeyer, so i can't help, sorry. [10:33] rog: yep, i already asked gustavo for it. [10:33] TheMue: you'll just have to wait until he's ready, i'm afraid. [10:34] TheMue: (you can do the gocheck fixes before submitting those branches, of course) [10:39] rog: the last both proposes now contain the gecheck fixes [10:39] TheMue: you should do the gocheck fixes as a separate propose, i think. [10:40] TheMue: that way we can get a working state without the necessity to submit both of those branches [10:40] TheMue: (you can do the fixes as a branch from the current trunk, then merge it into your upcoming branches) [10:42] rog: yeah, could do, but i dislike this juggling. the reviews are really almost ready since now almost 4 days [10:43] TheMue: yes, i know the feeling very well. it's frustrating, but we have to live with it... [10:43] rog: yep [10:43] lunchtime [10:46] fwereade: review delivered [10:46] rog, cheers [10:46] fwereade: trivial matters only... [10:46] rog, sweet :) [11:32] fwereade: what's with "iNstance" ? [11:32] rog, er, it looks a bit more like an instance id. I totally should have called it "instance-id" [11:33] * fwereade looks a bit shamefaced [11:33] fwereade: i've been using i-aaaaaaaa [11:33] fwereade: (or similar) [11:34] (which is actually a valid ec2 instance id) [11:34] rog, yeah, seems smarter [11:34] fwereade: i thought there was some cross check i hadn't seen [11:34] so, https://codereview.appspot.com/5695073/ is for the current trunk [11:35] rog, no, I'm afraid it does nothing whatsoever === Leseb_ is now known as Leseb [11:35] fwereade: ok, cool. maybe worth changing though [11:35] rog, definitely [11:36] TheMue: c.Assert(keys, Equals, []string{"m-0", "m-1"}) [11:37] TheMue, I'm 99% sure I spotted some Assert(len(blah), s [11:37] TheMue: i can't see how this is guaranteed to work [11:37] oops, sorry [11:37] TheMue: didn't see the sort.Sot [11:37] Sort [11:37] Strings, even [11:37] ;) [11:38] fwereade: tests are green. what problem do you expect? [11:39] TheMue, no failures expected; just that not using HasLen leads to more opaque failures if and when they do happen [11:41] fwereade: oh, will take a look [11:43] rog: what do you mean with "no ItemChange"? [11:44] TheMue: you could write it as []ItemChange{{....}} [11:44] er, i think, hold on [11:44] yeah [11:45] TheMue: within a slice initialiser, you can omit the type names if they're implied [11:45] rog: ah, yes, one of the g1 changes [11:46] TheMue: that change has been around for months actually [11:46] rog: yep, missed to use it [11:47] TheMue: in fact it was in r60 [11:47] (assuming play.golang.org still uses r60) [11:47] rog: anything else? [11:47] TheMue: nope [11:53] just gonna reboot and try and get my system working again [12:00] fwereade, rog: fixed it [12:01] TheMue, LGTM === Leseb_ is now known as Leseb [12:42] niemeyer: hiya [12:42] rog: Yo [12:43] niemeyer: i think most of the gocheck changes have been done, BTW [12:43] niemeyer: just state to be submitted [12:43] rog: neat, I was just checking them out, thanks for that [12:44] niemeyer: hiya from Germany too [12:47] TheMue: Hey man [14:50] fwereade_: You've got a review on the presence node [14:50] niemeyer, thanks [14:51] fwereade_: Let me know if you wanna talk about any of the points [14:51] fwereade_: The whole thing looks very good [14:51] niemeyer, will do :) [14:51] niemeyer, sweet :D [14:51] fwereade_: Mostly details [14:51] fwereade_: There's a single actual issue in the implementation [14:51] niemeyer, bother [14:52] fwereade_: https://codereview.appspot.com/5672067/diff/16001/state/presence/presence.go#newcode133 [14:52] fwereade_: I think this is the only one that will require a bit of fiddling [14:53] niemeyer, hmm, that was largely inspired by worries of "what if for some reason the remote node starts up with a different timeout?" [14:53] fwereade_: I don't understand how that changes the point [14:54] fwereade_: Can you describe further.. ok, what if..? [14:54] niemeyer, it's a possible reason to pay the costs you point out [14:54] niemeyer, then we might see it "die" because we're expecting it to update more often than it does [14:54] fwereade_: I mean I'm still missing the problem.. what if it starts with a different timeout.. why do we have to read clock on every ping? [14:55] niemeyer, ha, good point, sorry misunderstoof [14:56] niemeyer, thanks for that, I'll figure something out :) [14:56] fwereade_: Thank you [14:57] fwereade_: Btw, please ignore the first two comments.. they were left-overs from a previous review not delivered [14:57] niemeyer, ok [14:57] fwereade_: wasn't this the same point we discussed before? [14:58] fwereade_: i thought you were concerned about clock skew [14:58] rog, I was, and for some reason that didn't seem relevant just now [14:59] * fwereade_ tries to switch mental gears properly [15:01] rog, got it, it no longer feels like an issue because the watches are no longer expecting to live through multiple liveness changes [15:07] fwereade_: actually, i think the real reason it seems ok is that you've got a notion of "now" from the just-changed node... [15:08] rog, or alternatively that I know the node has just changed *before* my timeout fired, and so I don't really care when "now" is any more [15:09] fwereade_: good point [15:15] niemeyer: had a chance to look into https://codereview.appspot.com/5671055/? [15:34] rog: https://codereview.appspot.com/5698073 is done [15:34] TheMue: Will look next [15:35] niemeyer: fine, thx [15:35] niemeyer: that was quick! thanks a lot. [15:35] rog: np [15:58] TheMue: done [15:59] niemeyer: ah, fine [15:59] TheMue: The last comment is wrong.. the one about s/anyone/it/ [15:59] TheMue: It should be "any other charm" rather than "anyone" [15:59] niemeyer: ok, will take care [15:59] TheMue: Cheers [16:05] niemeyer: regarding the bundle url, shall it be a charm.URL too? so far it has been just a string [16:06] TheMue: No, that's not a charm URL.. it's a real URL [16:07] TheMue: http, https, whtaever [16:08] niemeyer: got it, will take net/url.URL [16:08] TheMue: That'd be fine, yeah [16:12] niemeyer: changes made. you might want to take a brief look before i submit as i've made the gocheck changes too. [16:15] rog: Nice, thanks [16:15] rog: LGTM [16:15] niemeyer: thanks [16:16] * niemeyer => lunch! [16:16] rog: np [16:16] niemeyer: enjoy [16:16] niemeyer: (submitted BTW) [16:33] fwereade_, niemeyer: this is my current test for zk concurrent close. it's fairly complex and not a little fragile. i'm thinking perhaps i should chuck it in and do something that does a much more simple verification of a single non-zk-read-lock-taking operation, because the read lock code is so simple to verify by eye. what do you think? [16:33] http://paste.ubuntu.com/859386/ [16:34] fwereade_: (you might recognise your proxy code, in heavily mutated form...) [16:36] rog, heh; when you say "fragile" do you mean "sometimes breaks in practice", or just "assumes more than it should to be a nice black box test"? [16:36] fwereade_: i mean "might break in practice on a heavily loaded machine" [16:36] fwereade_: because it has to do a sleep to ensure that the right piece of code takes the lock at the right time [16:36] fwereade_: there's no guarantee that it works [16:36] rog, ah, I missed that, hmm [16:37] fwereade_: of course 1/20th of a second *should* be perfectly sufficient, but... [16:37] rog, indeed [16:37] fwereade_: i can't think of another way to do it, as we need to test the two operations concurrently and there's no way to "get inside" either of them [16:38] fwereade_: unless we just do that and have an operation (in export_test.go) whose raison d'etre is to test the locking logic. [16:38] fwereade_: but that can't be used to directly test all the operations. [16:39] rog, I am inclined to go with the "50ms should be enough for anybody" approach, but expand please: what would you put in export_test to get around this? [16:39] fwereade_: i'd add a fake test operation to zk.Conn which took the read lock, then waited for notification, then relinquished it. [16:40] fwereade_: so then at least we could test the Close behaviour [16:40] fwereade_: and all the operations are tested "by analogy". not great. but can you think of a better way? [16:41] rog, afraid not [16:41] rog, I think I'd prefer theoretically-unsound tests of the actual behaviour [16:41] fwereade_: it seems like a lot of code to test something which is really quite simple. (as you saw it only took about 5 minutes to implement, and it's quite easy to verify by hand) [16:42] fwereade_: and it can't test all of the operations either [16:42] fwereade_: (it has to omit the ones that don't interact with the zk server) [16:44] rog, if I think of anything better I'll let you know ;) [16:44] rog, afk a sec [16:44] fwereade_: afk? [16:46] rog, away from keyboard [16:46] jimbaker: ah, thanks. hadn't seen that one before. [16:46] jimbaker: good morning, BTW! [16:47] rog, thanks! and hopefully a nice evening to you! :) [16:47] jimbaker: more like afternoon. evening approaches though. [16:47] jimbaker: pretty grey day, to be honest. [16:49] rog, my impressions of newcastle, formed purely by literature, are always of a gray day, lashed by the winds of the north sea :) [16:50] this may or may not have a basis in truth [16:50] jimbaker: well, north sea about 20 east of here, but it can be gray. although it can be beautifully sunny too! [16:50] s/20/20 miles/ [16:53] rog, glad to hear that. probably my mind is fixated on wind, we just went through about 5 days of strong winds here. at my house, gusts of approx 150 km/hr. enough to see grassfires, trucks lying on their sides, bicyclists blown over... now that's some imagery [16:54] jimbaker: that is strong. we've had some fairly good winds here this season (our house faces the prevailing westerlies) but nothing like that [16:56] rog, same with us in terms of exposure to westerlies, which are the strongest winds here. anyway, it's the worst in the 11 years i have lived here [16:57] but it's back to calm and sunny skies. the mountains made us aware of their presence, they are now back to quiet brooding [17:00] niemeyer: https://codereview.appspot.com/5671055/ is in again [17:30] TheMue: cheers! [17:35] TheMue: TestCharm still needs dropping [17:35] TheMue: It's fully redundant with the test followin git [17:35] TheMue: Otherwise, LGTM [17:37] niemeyer: oh, did i missed it? shit. [17:38] niemeyer: ok, will propose it in a few minutes again. btw, rog reminded me that i can remove ItemChange inside of []ItemChange{}. Could do it quickly too. [17:38] TheMue: why not leave that for the next one? [17:39] rog: could do so too. only because it's a quick one. [17:39] TheMue: your call [17:40] niemeyer: what do you say? [17:43] TheMue: Works either way for me, as long as that's the end of it === TheMue_ is now known as TheMue [17:48] Gna! Connection lost. [17:58] niemeyer: so, hopefully last try [18:00] pwd [18:00] oops [18:04] TheMue: TestCharm is *still* there!? [18:05] i'm off for the day, see y'all tomorrow [18:05] rog: Have a good one [18:06] niemeyer: arg, sorry, got you wrong. though you meant the url comparison and the last assert should be removed, not the whole test. *sigh* [18:06] niemeyer: my fault. [18:06] TheMue: All of the lines in TestCharm may be found in that precise shape in the test following it [18:07] TheMue: So there's no point in having it [18:07] niemeyer: yep, i understand, only understood your review wrong [18:08] niemeyer: i have been too much focused on the url [18:08] TheMue: Cool, np [18:09] niemeyer: so one last propose ... [18:09] TheMue: Please just drop the test and submit [18:09] niemeyer: ok, that's shorter ;) [18:10] niemeyer: sadly you stole me some test methods today, so my high watermark is lower now :( [18:23] niemeyer: i'm still not secure with lbox submit, i updated my trunk, merged it into my change and now wanted to submit it. but it says the branch is not clean. do i have to do a commit before lbox submit? [18:23] TheMue: If you have changes in your branch, you necessarily must commit them, or revert if you don't want them in the final merge [18:24] niemeyer: i committed my changes before the merge (it's the removing of AddCharm() ) [18:24] TheMue: submit will deliver the changes that you did in your branch onto the target branch.. it will not do changes behind your back [18:24] TheMue: So why is the branch dirty? [18:26] niemeyer: after my commit i've done a bzr pull in my go-trunk (the base of this propose), then i changed back to my go-state-… and do a bzr merge ../go-trunk there [18:28] niemeyer: here i got no conflicts and a final go test in state worked fine [18:29] TheMue: Sure.. and then you have to commit that.. the merge will not be committed automatically [18:30] niemeyer: ah, ok, that's missing. lbox help also states a commit, so i thought it's done automatically. [18:31] TheMue: It will commit the merge of your branch onto the target branch [18:31] TheMue: It will not fiddle with unfinished states in your own branch [18:34] niemeyer: still not absolutely safe in the world of dvcs. [18:34] niemeyer: thx for your help [18:39] niemeyer: it's in [18:39] TheMue: Woohay! [19:12] niemeyer, does lbox -cr support prerequisite branches? [19:15] hazmat, use the -req option [19:17] jimbaker, thanks [19:19] hazmat: Kind of [19:19] hazmat: THis is my first TODO after the store work [19:19] hazmat: It won't diff the branches properly, so all but the first branch in the pipeline will contain data for the previous entries too [19:20] hazmat: So, in practice, it doesn't work very well yet [19:20] hazmat: I didn't want to fix that before submit was working, though, to prevent people mistakingly submitting follow up branches thinking that this was _just_ what they were changing [19:20] niemeyer, thanks for clarifying, i was noticing that problem but wasn't sure if -req was obmitted or would help. [19:20] hazmat: Now submit works, so I'll make submitting check to see if the pre-req is in [19:21] hazmat: and will make propose diff against the previous branch in the pipeline [19:21] hazmat: Will work on this as soon as store is out of the way [19:21] niemeyer, sounds good [19:22] andrewsmedina: How're things going there? [19:24] niemeyer: hi [19:24] andrewsmedina: Heya [19:25] niemeyer: I started the local provider [19:25] andrewsmedina: Sweet! [19:25] niemeyer: inspired by ec2 provider [19:25] andrewsmedina: Super [19:25] niemeyer: but I had some problems with gocheck [19:25] andrewsmedina: Hmmm.. when did you do that? [19:26] bcsaller1, is the subordinate spec ready for niemeyer to have another look? [19:26] andrewsmedina: Do you want an introduction to the development process via a low-hanging fruit? [19:27] hazmat: yeah, thought it was in the queue, I'll check again [19:27] niemeyer: low-hanging fruit? [19:27] bcsaller1, it was proposed again to reitveld afaics [19:27] bcsaller1: Maybe it was and I just overlooked it.. please let me know of the URL and I'll check it out [19:27] er. wasn't [19:28] andrewsmedina: A simpler change that allows to see how things work [19:28] andrewsmedina: It's probably better than doing a lot of work without touching base as your first task [19:28] niemeyer: It would be amazing :D [19:28] bcsaller1, it looks like it was just pushed again to lp, lbox propose again should do the trick [19:28] andrewsmedina: This is a good candidate: https://codereview.appspot.com/5532098/diff/4001/juju/charm/metadata.py [19:29] niemeyer, hazmat: it doesn't appear to upload the new push, I'll try it now [19:29] must have gotten an error before I didn't see [19:29] bcsaller1, hazmat: Was that original spec merged already? [19:29] no [19:29] bcsaller1: Ouch [19:29] bcsaller1: What happened? [19:29] kapil had to +1 it as well and then there were the changes you'll be looking at now [19:30] niemeyer: what needs to be done? [19:30] andrewsmedina: We need to port that change onto the Go side [19:30] andrewsmedina: Should be a pretty comfortable ride [19:30] ok [19:30] andrewsmedina: This will affect charm/meta.go [19:30] andrewsmedina: and the respective tests, of course [19:30] niemeyer: how you set your dev enviroment and run the tests? [19:31] andrewsmedina: I do: export GOPATH=$HOME [19:31] niemeyer: I did checkout in gopath [19:31] andrewsmedina: and "go get launchpad.net/juju/go/charm", for example [19:31] niemeyer: and I run, tests module by module [19:31] andrewsmedina: This will set up all dependencies [19:31] niemeyer: yes [19:31] bcsaller1: :-( [19:32] bcsaller1: We spent a lot of energy to agree on that state [19:32] niemeyer I'm on the right way [19:32] niemeyer: we talked about this at the call on Thursday [19:33] bcsaller1: If Kapil had comments on it, they should be applied on the original state.. now we have an unrelated new change that is piled up together with the whole spec, and we've got no agreement committed yet [19:34] niemeyer: I saw them as related changes from the needed second +1 [19:34] bcsaller1: I know, but I thougth you were talking about a _new_ branch.. I had no idea that this change that we agreed on is still floating around uncommitted [19:35] I have the full revision history. This is getting merged into the docs branch anyway, we can build whatever history you want there [19:35] bcsaller1: Do you have the link at hand? [19:36] niemeyer: https://codereview.appspot.com/5541054/ [19:36] bcsaller1: All I see in that link is "Thanks a lot for the extensive spec, and for keeping up with it Ben. Just a few [19:36] last minute trivials." [19:36] bcsaller1: and hten "Please take another look." [19:36] bcsaller1: Where are the comments from Kapil that you are addressing? [19:37] niemeyer: prior G+ talks , there are the changes brought up in the last meeting reflected in subordinate-internals [19:37] This is really bad.. [19:38] This is a spec from several months ago.. that was approved more than 2 weeks ago, and now it revives. [19:38] * niemeyer looks.. [19:44] bcsaller1, hazmat: [19:44] 49 global/ [19:44] 50 global/ [19:44] !? [19:45] niemeyer: thats so that the path structure is the same for all types [19:45] container/unit-0001/... or global/global/... [19:45] the same path construction logic can then be used [19:46] bcsaller1: Sorry, I don't get.. [19:46] that feels a little strange [19:46] also for containers the settings node should be under the container [19:46] one is relation_scope_type/relation_scope/value [19:46] err... one is relation_scope_type/relation_scope_value [19:47] bcsaller1, but its redundant [19:47] bcsaller1, global should suffice for scope and value [19:48] hazmat: not really, it looks that way to a human, but its a uniform structure to the apis [19:48] bcsaller1, the api can interpret global scope however it chooses [19:49] bcsaller1, and settings should always be under scope, else the additional containment serves little purpose imo.. effectively this is reuse of the existing relation work/watchers, with a prefix to the base path [19:50] hazmat: agreed, I guess I didn't juggle it properly [19:50] bcsaller1: I don't understand.. you have to special case it anyway to pick global.. in fact why don't we even have any "global" in there at all? [19:50] s/don't we/do we/ [19:51] bcsaller1: I assume we can tell whether a relation is a container relation or not based on the topology information, right? [19:51] niemeyer: it mirrors container/unit-0001, container/unit-00002 etc. the path is relations/relation_id/relation_scope_type/relation_scope_value/relation_role/... where things under relation_scope_value are the previous structure [19:51] niemeyer: yes, that has to be the case [19:52] bcsaller1: So why do we even have "container" or "global" nodes? [19:52] bcsaller1: What problem are these solving? [19:53] bcsaller1: In fact, what problem is the change from the original spec that was last reviewing solving? [19:53]