[13:51] TheMue: How did the review look? Good stuff? [13:52] niemeyer: yip, the changes are back in (after i had another special task: check the translation of the press release to maas) ;) [14:01] TheMue: What's coming next? [14:01] TheMue: Acting as a translator too? Nice. :) [14:02] niemeyer: if it's ok for you now i'll submit it and then realize the next watches [14:02] niemeyer: as long as you don't have something more urgent for me [14:04] niemeyer: do we have a kind of roadmap in which order the missing parts shall be ported? [14:05] TheMue: Not at this time.. we have to do all of them, and nobody else is blocked on missing pieces of the state, so you're free to pick the next slice [14:05] TheMue: That said, given we've just entered watches and have them fresh in our minds, sounds like a good choice indeed [14:06] TheMue: I'll have a last look right away [14:06] niemeyer: Fine, so I would continue with those. [14:17] TheMue: Just for the record: [14:17] """ [14:17] Done. Difficult situation would be if in case of an internal watcher error [14:17] Dying() returns an error too. Haven't been able to discaver that in the control [14:17] flow. [14:17] """ [14:17] TheMue: It's fine to give precedence to one of the errors in that case [14:17] TheMue: You've picked the right end of it as well, IMO.. the underlying error is likely of higher precedence if both exist [14:26] niemeyer: That has been my thought too. And I think a panic would be too much while some kind of crippled error mix of both won't help too. [14:26] Right [14:28] TheMue: You got a plain LGTM [14:28] niemeyer: great, thx [14:28] TheMue: Turned out very well.. love the new watch infra [14:30] niemeyer: me too, one kind of tasks which go can handle very well [15:03] of course fwereade leaves the room at our 1:1 time [15:03] lol [15:04] :-) [15:12] Lunch time.. biab [15:34] SpamapS: when are you planning on next uploading to the archive? [15:34] SpamapS: the current archive version doesn't have the constraints support [15:34] SpamapS: not a big deal, but just would like to know your plans [15:44] flacoste: when subordinates lands [15:44] SpamapS: what's the ETA for that? [15:44] bcsaller: how goes it btw? [15:45] flacoste: I've seen brief flurries of review/fix/review cycles so it must be close. === hazmat is now known as kapilt [16:39] gn all (actually, happy weekends all, really, holiday tomorrow) [16:44] fwereade: yip, have a nice long weekend too [16:48] fwereade: Have a good one! === kapilt is now known as hazmat [18:51] jimbaker, after your done merging the rel-id work, would you mind having a look at this txzk branch http://codereview.appspot.com/5976074/ [19:35] hazmat, will do [19:43] jimbaker, thanks [21:05] jimbaker, hazmat: "Use the new hook command, relation-ids [RELATION_NAME], which takes an [21:05] optional relation name (otherwise implies all)" [21:05] jimbaker, hazmat Otherwise implies all? [21:05] niemeyer, yes [21:05] niemeyer, all relation ids are returned if no name is specified [21:05] hazmat: The agreement is that it should imply the current relation name [21:06] niemeyer, if one exists [21:06] it does [21:06] but in the case of a non rel hook context, it won't [21:06] hazmat: Yes, if you doesn't exist it should break and say "give me a relation name".. [21:06] hazmat: Otherwise the command has a completely different behavior depending on context [21:07] niemeyer, hazmat, the actual behavior is to return all the relation ids if no relation name is specified, regardless of context [21:07] jimbaker: That's not what we agreed [21:07] whether relational or not [21:07] jimbaker, doesn't it default to an env var? [21:07] niemeyer, i can certainly change it [21:08] hazmat, it was originally doing that, but that caused the inconsistency [21:08] instead we can have it raise an error as niemeyer suggests [21:09] sounds good [21:09] hazmat, cool [21:10] jimbaker: """ [21:10] 4 This proposal adds a new relation hook command to enumerate the [21:10] 5 relations a service participates in:: [21:10] 6 [21:10] 7 relation-ids [RELATION_NAME] [21:10] 8 [21:10] 9 Hooks that are not relational hooks must specify the relation name as [21:10] 10 an argument; otherwise an error is raised stating "Relation name must [21:10] 11 be specified". For relational hooks, the corresponding relation name [21:10] 12 is the default. [21:10] """ [21:11] niemeyer, thanks for pointing that out [21:11] jimbaker: I'm not reviewing the code going into the Python implementation.. if you don't pay attention to the specification, the point of we agreeing on it is moot [21:13] niemeyer, thanks, this was very helpful