davecheney | niemeyer: ahh, `yaml:"flow"`, might be the savation | 00:07 |
---|---|---|
niemeyer | davecheney: Ah, hold on | 00:08 |
niemeyer | davecheney: You want to compare output? | 00:08 |
niemeyer | davecheney: for testing purposes? | 00:08 |
davecheney | niemeyer: yes | 00:09 |
niemeyer | davecheney: That's probably not a good direction | 00:09 |
niemeyer | davecheney: We've had a lot of pain comparing yaml like that | 00:09 |
davecheney | ok | 00:09 |
niemeyer | davecheney: It's easier to unmarshal the yaml back | 00:09 |
niemeyer | davecheney: and compare the value | 00:10 |
niemeyer | davecheney: This also helps because you can compare bits, rather than full docs | 00:10 |
davecheney | using deep equals ? | 00:10 |
niemeyer | davecheney: Yeah | 00:10 |
niemeyer | davecheney: Indentation is doable, etc | 00:10 |
davecheney | ok, i'll keep working on it | 00:11 |
davecheney | niemeyer: is this a bug ? http://play.golang.org/p/P1dQvMC9T4 | 01:41 |
davecheney | niemeyer: nm, the channel corrected my mistake | 01:43 |
niemeyer | davecheney: Yeah, no commas | 01:44 |
TheMue | davecheney, fwereade__, rog: morning btw | 06:22 |
rog | davecheney, fwereade__, TheMue: yo! | 06:22 |
davecheney | rog: themue, hello! | 06:38 |
davecheney | rog: https://codereview.appspot.com/6432045 if you have any comments on the test harness | 06:39 |
davecheney | i would be glad to hear them | 06:39 |
davecheney | testing json and yaml is a pain the butt | 06:40 |
davecheney | but at least this way, it isn't a pain in the butt when we're pressed for time and someone points out json output is manditory | 06:40 |
* rog looks | 06:43 | |
rog | davecheney: i wonder if we should use MarshalIndent to produce nice looking json. just a thought. | 06:46 |
davecheney | rog: sure | 06:47 |
rog | davecheney: also, i wonder if the status tests could just specify the value of the data structure required; then we could unmarshal the output (in whatever format we want to check) and make sure it deep equals the | 06:47 |
rog | required value | 06:48 |
davecheney | rog: tried that, didn't wokr | 06:48 |
rog | davecheney: ah, because the unmarshal differently? | 06:48 |
rog | theyt | 06:48 |
rog | they | 06:48 |
rog | :-) | 06:48 |
davecheney | yes, json produces map[string]interface{} | 06:48 |
davecheney | yaml produces map[interface{}]interface{} | 06:48 |
rog | davecheney: hmm, but can't you unmarshal into a data structure of the expected kind? | 06:49 |
davecheney | rog: yes, but then the next level down becomes m[i]i | 06:50 |
rog | m[i]i ? | 06:51 |
rog | oh yeah | 06:51 |
rog | hmm | 06:51 |
davecheney | i don't think it's solveable | 06:51 |
davecheney | anyway, that is enough to start mergeing in my working branches | 06:52 |
davecheney | and if the harness is uttery wrong | 06:52 |
davecheney | then i'll tackle it then | 06:52 |
rog | davecheney: one last thought: could you start with the expected data structure, then marshal it and unmarshal it again, *then* check against the original unmarshalled value you got? | 06:54 |
davecheney | or marshal it, and compare it to the data in cxt.Stdout | 06:55 |
rog | davecheney: no, that won't work | 06:55 |
davecheney | why not | 06:55 |
rog | davecheney: because marshalling isn't deterministic | 06:55 |
davecheney | for json it is, but i take your point | 06:56 |
rog | davecheney: oh really, json sorts map keys? cool, i didn't know that. | 06:56 |
davecheney | gustavo argued that goayml can do the same thing | 06:56 |
davecheney | i'm going to hvae to change goyaml slightly anyway | 06:56 |
rog | davecheney: it would make life easier | 06:56 |
rog | davecheney: and json is a good precedent | 06:57 |
* davecheney thinks that json is about as crack headed as javascript | 06:57 | |
davecheney | for example, struct { Machines map[int]interface{} } | 06:57 |
davecheney | cannot be json marshalled | 06:57 |
davecheney | yet _must_ be marshalled by yaml | 06:57 |
davecheney | so, because of that, i have to conver machine.Id to a string, then change goyaml to accept a formatting flag to convert the string keys back to ints | 06:58 |
rog | davecheney: oh that's a pity | 06:58 |
davecheney | anyway, dinner time | 06:59 |
davecheney | then i'll ponder your idea | 06:59 |
davecheney | if that means we describe the output once, that is a big win | 06:59 |
rog | davecheney: given what you've said above, i'm not sure it can work. | 07:00 |
rog | davecheney: pity machine ids aren't strings | 07:00 |
TheMue | rog: Let the Firewaller only use a passed state has been a nice simplification, but how do I get the environment now. Somehow lost the path. | 07:04 |
rog | TheMue: ha ha. you'll need to pass the environment in as an argument too. | 07:05 |
TheMue | rog: sh** | 07:05 |
TheMue | rog: Already expected it *sigh* | 07:06 |
TheMue | rog: Btw, on Sunday, do we try to get seats next to each other or do we just meet at the baggage claim? | 07:11 |
rog | TheMue: it would be nice to sit together, but i can't quite work out how :-) | 07:11 |
fwereade_ | morning all | 07:12 |
TheMue | rog: That's the problem. | 07:12 |
TheMue | fwereade_: Morining | 07:12 |
rog | TheMue: except, i guess, we can try to arrive at the checkin desk together... but most seats are gone by then. | 07:12 |
rog | TheMue: i have an idea | 07:12 |
* TheMue listens | 07:13 | |
rog | TheMue: i won't have access to a computer, but perhaps i could give you my booking details and you could try and select a seat for both of us on the airline website | 07:13 |
rog | TheMue: in fact, perhaps they allow us to choose a seat now. i'll have a look. | 07:13 |
TheMue | rog: That could work | 07:13 |
TheMue | rog: Your Environ.OpenPorts() wants all ports that have to be open or just a delta that should be opened with this action? | 07:20 |
rog | TheMue: just a delta | 07:21 |
TheMue | rog: Good | 07:21 |
rog | TheMue: otherwise there wouldn't be a ClosePorts method :) | 07:21 |
TheMue | rog: Makes it more simple | 07:21 |
TheMue | rog: Sounds logical :D | 07:21 |
rog | TheMue: yeah, i toyed with both approaches, but this seemed better | 07:21 |
TheMue | rog: Yes, otherwise I would have to maintain a list of all open ports on a machine inside the firewaller. Now I just tell you to open it. | 07:22 |
rog | TheMue: yeah | 07:22 |
TheMue | rog: Hmm, if a port can't be opened (so you return an error), how hard is this error? I could do a panic, but that wouldn't be helpful. Better would be a kind of retry. | 07:25 |
rog | TheMue: yeah, it's a good question. | 07:26 |
rog | TheMue: not very hard, i'd say | 07:26 |
rog | TheMue: perhaps you could put the retry in later, to avoid cluttering the initial logic | 07:26 |
TheMue | rog: But have to leave now until noon, some shopping with Carmen. We can talk later again. | 07:27 |
TheMue | rog: So far I'll ad a TODO, yes | 07:27 |
asachs_ | Hello all | 07:54 |
fwereade_ | asachs_, hi | 08:12 |
fwereade_ | everyone, sorry, I have to pop out for 30 mins | 08:12 |
fwereade_ | bbs | 08:12 |
asachs_ | anyone seen a MaaS based bootstrap fail to install zookeeper ? | 09:05 |
fwereade_ | asachs_, not offhand; can you ssh into the instance at all? | 09:13 |
asachs_ | fwereade_: yeah i could - but no zookeeper installed :( | 09:13 |
* fwereade_ desperately tries to remember where cloudinit logs to | 09:14 | |
fwereade_ | asachs_, can you take a look at /var/log/cloud-init-output.log on the instance? | 09:15 |
rog | fwereade_, asachs_: /var/log/cloud-init.log | 09:15 |
fwereade_ | rog, ah ok | 09:15 |
rog | fwereade_, asachs_: also, perhaps: cloud-init-output.log | 09:15 |
rog | fwereade_: here's a script i use occasionally for debugging, which automatically copies the logs from an instance to my local machine: http://paste.ubuntu.com/1101520/ | 09:17 |
fwereade_ | rog, nice :) | 09:17 |
rog | fwereade_: wanna swap a book or two again? | 09:37 |
fwereade_ | rog, I'll see if I can find something worth reading :) | 09:39 |
davecheney | rog: can you paste that link again please ? | 09:49 |
rog | davecheney: which link? | 09:51 |
davecheney | the one you emailed me | 09:51 |
davecheney | play.g.o | 09:51 |
rog | davecheney: http://play.golang.org/p/AMq8qURfBW | 09:52 |
davecheney | ta | 09:53 |
asachs_ | rog: thanks - its for a maas setup so the ec2 stuff will not work so nice :) | 10:39 |
rog | asachs_: np. it should be easy enough to port the concept though, if you want. i doubt you have the rc shell installed anyway :-) | 10:41 |
asachs_ | rog: it looks fairly straightforward, will have a go at it once my new MAAS server is up | 10:42 |
asachs_ | rog: and thx | 10:42 |
rog | asachs_: tbh, i usually ended up doing ssh and tail -f for a more interactive view. | 10:42 |
rog | fwereade_: i wonder if you might take a look at this and see whether it seems reasonable. i haven't yet done the extra tests in the juju package, but the cmd/juju test suite passes: https://codereview.appspot.com/6428061/ | 11:30 |
fwereade_ | rog, very shortly, have much state loaded atm | 11:32 |
rog | fwereade_: np | 11:32 |
rog | fwereade_: it's fairly trivial refactoring, nothing substantial | 11:33 |
fwereade_ | rog, cool | 11:33 |
=== TheMue_ is now known as TheMue | ||
rog | just off for lunch, then travelling this afternoon - i'll probably leave here in a couple of hours | 12:12 |
TheMue | rog: enjoy | 12:12 |
fwereade | rog, ok, I am at last on your review, lunch intruded | 13:12 |
fwereade | rog, sorry | 13:12 |
rog | fwereade: it's still WIP BTW | 13:20 |
rog | fwereade: 3 possible books: Crystal Rain (Tobias Buckell), Harmony (Project Itoh) and Wolf Hall (Hilary Mantel). read any of 'em? | 13:21 |
fwereade | rog, none of them :) | 13:24 |
rog | fwereade: last one's historical rather than sf, but great anyway | 13:24 |
fwereade | rog, excellent | 13:27 |
fwereade | rog, what's your general view of bleak sprawling messed-up fantasy? | 13:27 |
fwereade | rog, reviewed btw | 13:28 |
fwereade | rog, and I did the linked list thing with HookQueue and I think it worked out really nicely | 13:30 |
fwereade | rog, so many thanks for that | 13:30 |
fwereade | rog, https://codereview.appspot.com/6422049 | 13:30 |
fwereade | rog, nothing is O(1) though | 13:31 |
fwereade | rog, Add is O(len(changed_units)) | 13:31 |
TheMue | rog: I have some troubles with http://paste.ubuntu.com/1087489/, line 41 ff. | 13:31 |
fwereade | rog, Next is O(len(members)) | 13:31 |
fwereade | rog, but those are both better than before :) | 13:32 |
TheMue | rog: It seems like your outline iterates twice over the change (which is the list of open ports). | 13:33 |
rog | fwereade: last night i couldn't resist seeing what the linked list idea might look like; i was going to throw it away, but... http://paste.ubuntu.com/1101809/ | 13:37 |
* rog is trying desperately to pack | 13:38 | |
fwereade | rog, I'm afraid I really can't judge it without tests ;) | 13:40 |
rog | fwereade: indeed | 13:40 |
niemeyer | Good mornings! | 13:51 |
fwereade | niemeyer, heyhey | 13:52 |
TheMue | niemeyer: Moin | 13:53 |
niemeyer | Heyas! | 13:53 |
rog | niemeyer: yo! i'm heading to the airport in 25 mins... | 13:55 |
niemeyer | rog: Oh, going to Lisbon already? | 13:56 |
rog | niemeyer: first leg only. laying over for the weekend with some university pals in amsterdam (planned ages and ages ago, and cut short a bit by the sprint). | 14:07 |
niemeyer | rog: Ah, nice | 14:07 |
niemeyer | rog: Have some good fun there | 14:08 |
rog | niemeyer: should be fun. at least one of them i haven't seen for 20 years | 14:08 |
niemeyer | rog: WOah | 14:08 |
rog | niemeyer: i'll try not to arrive too hungover! | 14:08 |
niemeyer | rog: Have you graduated 20 years ago!? 8) | 14:08 |
rog | niemeyer: old bugger, me | 14:08 |
niemeyer | rog: LOL | 14:09 |
rog | niemeyer, fwereade, TheMue: right, i'm off. might be online for a bit from the airport though. | 14:10 |
rog | otherwise see y'all in lisbon! | 14:10 |
rog | i'm looking forward to it! | 14:10 |
fwereade | rog, have fun! | 14:10 |
TheMue | rog: Enjoy, we'll see at least at Lisbon airport | 14:10 |
niemeyer | rog: Indeed! | 14:10 |
niemeyer | rog: Have fun! | 14:10 |
rog | toodle pip | 14:10 |
niemeyer | fwereade: So, the validation stuff is up for review | 14:19 |
fwereade | niemeyer, I'm reading it now, it looks *awesome* so far | 14:19 |
niemeyer | fwereade: Very glad (and relieved :-) to hear it | 14:21 |
fwereade | niemeyer, LGTM, but I think control-bucket should also be immutable | 14:25 |
niemeyer | fwereade: Is it not? | 14:26 |
fwereade | niemeyer, huh, couldn't see it | 14:26 |
* fwereade reads again | 14:26 | |
fwereade | niemeyer, it's not mentioned in Validate | 14:26 |
fwereade | niemeyer, did you do something clever? | 14:27 |
niemeyer | fwereade: Isn't that awesome? :-) | 14:27 |
niemeyer | fwereade: Oh, wait | 14:27 |
fwereade | niemeyer, but the structure of it all is perfect | 14:27 |
niemeyer | fwereade: You mean immutable as in cannot be changed from old to cfg | 14:27 |
niemeyer | Okay | 14:27 |
fwereade | niemeyer, yeah, sorry | 14:27 |
niemeyer | fwereade: I read that as in *config.Config is immutable | 14:28 |
niemeyer | fwereade: WE don't ever change, or even reference, control-bucket within Validate | 14:28 |
fwereade | niemeyer, nah, Config seems fine to me :) | 14:28 |
niemeyer | fwereade: Which is what I claimed is awesome | 14:28 |
fwereade | niemeyer, ohhhhh | 14:28 |
fwereade | niemeyer, hmmmmm | 14:28 |
fwereade | niemeyer, can't quite decide whether that's awesome or evil | 14:29 |
niemeyer | fwereade: But, you're right I think.. we shouldn't allow the control-bucket to change, at least for now | 14:29 |
niemeyer | fwereade: Really? | 14:29 |
niemeyer | fwereade: Why would it be evil? The schema is doing the whole validation for us | 14:29 |
fwereade | niemeyer, sorry, I misunderstood what you said | 14:30 |
fwereade | niemeyer, not to worry :) | 14:30 |
niemeyer | fwereade: Cool :-) | 14:30 |
fwereade | niemeyer, a suggestion: we should store relation resolved nodes under the relation (like settings and presence), not under the unit | 14:34 |
fwereade | niemeyer, (and we should do the same for the workflow nodes, if they're not already there, which I don't immediately recall) | 14:35 |
fwereade | niemeyer, oh, hmm, maybe that's problematic | 14:35 |
* fwereade goes off to read code | 14:35 | |
niemeyer | fwereade: I do think there's an awesometastic potential for simplifying things in that state machine, but indeed we have to think through the error management | 14:36 |
niemeyer | fwereade: "If it's worth checking for a missing endpoint (as we do in Open) I maintain it's worth checking for here rather than there :)." | 14:38 |
fwereade | niemeyer, ...but it turns out you dropped that check entirely, and I'm fine with that | 14:38 |
niemeyer | fwereade: Part of the beauty is that this is now done in both locations, and in SetConfig | 14:38 |
fwereade | niemeyer, oh? sorry, where? | 14:38 |
niemeyer | fwereade: I haven't dropped it.. this branch actually *increases* validation significantly, perhaps to my surprise also :-) | 14:38 |
niemeyer | fwereade: There's a single code path to grab an ecfg | 14:39 |
niemeyer | fwereade: and it validate | 14:39 |
niemeyer | s | 14:39 |
fwereade | niemeyer, there's also a funny little bit in Open, that you deleted, that checks the EC2Endpoint on the chosen region | 14:40 |
fwereade | niemeyer, I don;t see EC2Endpoint anywhere else in the diff | 14:40 |
niemeyer | fwereade: Oh? | 14:41 |
fwereade | niemeyer, but I don't really see why we should need to check it in the first place | 14:41 |
niemeyer | fwereade: Where is that? | 14:41 |
fwereade | niemeyer, https://codereview.appspot.com/6416055/diff/4001/environs/ec2/ec2.go#oldcode117 | 14:41 |
niemeyer | fwereade: Oh, sorry | 14:41 |
niemeyer | fwereade: I did misread that code | 14:41 |
niemeyer | fwereade: I've read the error message, and inferred the test | 14:42 |
niemeyer | fwereade: If the region exists in aws.Region, I claim we can use it | 14:42 |
niemeyer | fwereade: We're not checking S3Endpoint, for example | 14:43 |
fwereade | niemeyer, agreed | 14:43 |
niemeyer | fwereade: Thanks, though, I did miss the real test | 14:43 |
fwereade | niemeyer, I don't think that bit ever had an explicit test anyway | 14:43 |
niemeyer | fwereade: Indeed | 14:44 |
niemeyer | fwereade: I'll add the control-bucket check | 14:44 |
fwereade | niemeyer, cool | 14:44 |
fwereade | niemeyer, btw, I added those methods to Relation, in https://codereview.appspot.com/6430055/ | 14:46 |
fwereade | niemeyer, and in the CL I suggest that maybe they should be on Unit | 14:46 |
fwereade | niemeyer, but in *fact* I now think a RelationUnit type, which just holds the stuff we repeatedly calculate in Relation.unitScope, is really the right place for them | 14:47 |
fwereade | niemeyer, (*Relation)Unit(*Unit) (*RelationUnit, error) | 14:48 |
fwereade | niemeyer, (*RelationUnit) Watch() (*presence.Pinger, error) | 14:48 |
fwereade | niemeyer, (*RelationUnit) Settings() (*ConfigNode, error) | 14:48 |
fwereade | niemeyer, (*RelationUnit) Watch() (*RelationUnitsWatcher, error) | 14:48 |
fwereade | niemeyer, and then... | 14:49 |
fwereade | niemeyer, something a bit like (*RelationUnit) WaitResolved() (<-chan bool, error) | 14:49 |
fwereade | niemeyer, and similar methods for Workflow etc etc | 14:50 |
fwereade | niemeyer, would you be OK with that? | 14:50 |
fwereade | niemeyer, sorry, way up there, s/unitScope/unitInfo/ | 14:51 |
fwereade | (what the hell, how is it 5pm? time flies :)) | 14:53 |
niemeyer | fwereade: I'm on the fence about it, mostly because I don't see the actual benefit and do see increased API surface, and even usage burden (e..g you now must check error twice to reach a Relation's Settings). | 14:53 |
niemeyer | fwereade: Do you see simplification on the implementation? And if so, can you describe a bit of it? | 14:54 |
fwereade | niemeyer, the benefit IMO is that we don't need to pass a Relation and a Unit around everywhere we're dealing with the relation lifecycle | 14:55 |
fwereade | niemeyer, I think it'll also have methods like Workflow and SetResolved and so forth | 14:55 |
fwereade | niemeyer, which would be icky on Unit (because it will want stuff like that itself) | 14:56 |
niemeyer | fwereade: Sounds sensible | 14:56 |
niemeyer | fwereade: +1 | 14:56 |
fwereade | niemeyer, and the big issue with the current form is (*Relation)Watch(*Unit), which *really* looks like we're watching a unit | 14:56 |
niemeyer | fwereade: Agreed.. I dislike that too | 14:57 |
niemeyer | fwereade: It's also nice that we can have an *actual* Relation.Watch method, taking no parameters | 14:57 |
niemeyer | fwereade: That doesn't ignore any units | 14:57 |
fwereade | niemeyer, ooh, nice | 14:57 |
niemeyer | fwereade: I'm looking forward to use that in a monitoring tool :-) | 14:57 |
fwereade | niemeyer, ok, I'll wip that and make the change | 14:58 |
niemeyer | fwereade: Thanks a lot | 14:58 |
fwereade | niemeyer, but https://codereview.appspot.com/6422049/ is also ready(?) and I think it's pretty cool actually | 14:58 |
fwereade | niemeyer, it lacks the occasional pathological performance characteristics of the first one | 14:59 |
fwereade | niemeyer, I think :) | 14:59 |
niemeyer | fwereade: Sweet, will have a look | 15:01 |
niemeyer | Actually, I'll review that first thing in the afternoon if that's ok | 15:02 |
fwereade | niemeyer, no rush :) | 15:02 |
fwereade | niemeyer, I have two nicely complementary streams of work at the moment, both UA related, and easy to switch between | 15:03 |
fwereade | niemeyer, when they collide I'll be screaming for reviews, so take it easy while you can ;) | 15:03 |
niemeyer | fwereade: LOL | 15:04 |
niemeyer | fwereade: Sweet | 15:04 |
rog | fwereade: is there any particular reason that StartUnit should be StartUnits? it's trivial for the caller to write a for loop, and it means that the caller can decide what to do if one fails after several have succeeded. | 15:36 |
fwereade | rog, just seems more appropriate for a high-level interface somehow | 15:37 |
fwereade | rog, matter of taste, not really bothered, we'll find out what we really need later | 15:38 |
rog | fwereade: if we were going to potentially optimise AddUnits(n) so that it wasn't just a simple for loop around AddUnit, i think i'd agree. but otherwise i can't see the point. | 15:39 |
rog | fwereade: it's not *that* high level - we assume the caller can program :-) | 15:39 |
fwereade | rog, that's what I kinda think we should be doing :) | 15:39 |
rog | fwereade: yeah, ok, will go for AddUnits then | 15:40 |
rog | fwereade: then if the state API changes to allow a more efficient approach, the juju API can remain the same | 15:41 |
fwereade | rog, yeah, exactly | 15:41 |
fwereade | rog, niemeyer: hey, why does AddUnitSubordinateTo exist? | 15:42 |
rog | fwereade: and one approach to that would be to add AddUnits to the state API and not download the charm for every unit! probably a better approach than caching | 15:42 |
niemeyer | fwereade: Hm? | 15:43 |
fwereade | rog, niemeyer: should this not be handled at AddUnit time, with something like Service.Subordinates()? | 15:43 |
fwereade | rog, niemeyer: anyway, total derail really, but I can't see any benefit to exposing the functionality | 15:43 |
rog | fwereade: i guess it depends what level you see the state API | 15:43 |
rog | fwereade: i see it as potentially allowing things outside the scope of what is allowed in the high level juju view | 15:44 |
fwereade | rog, regardless of level, I'm not sure it should let us do things that aren't internally consistent | 15:44 |
fwereade | rog, without the appropriate relations in place, isn't it straight-up nonsensical to try to do that? | 15:45 |
niemeyer | fwereade: Yeah, could be internalized I guess | 15:45 |
fwereade | rog, niemeyer: one for our Copious Free Time, I think, anyway ;) | 15:45 |
rog | fwereade: i think i agree | 15:45 |
niemeyer | fwereade: It doesn't let us do things that aren't internally consistent already, but if we can simplify it that's a bonus | 15:45 |
niemeyer | fwereade: I've added the control-bucket stuff and re-proposed.. if all looks good will submit once I'm back from lunch | 15:59 |
fwereade | niemeyer, cool, I'll take a look | 16:00 |
fwereade | niemeyer, just unwipped https://codereview.appspot.com/6430055 | 16:01 |
fwereade | niemeyer, according to how the tests feel, it was a good move :) | 16:01 |
niemeyer | fwereade: Sweet! | 16:01 |
fwereade | niemeyer, dammit, I'm meant to be going out and having fun this evening ;p | 16:02 |
mramm2 | fwereade: no rest for the wicked! | 16:03 |
fwereade | mramm2, haha | 16:03 |
=== imbrandon is now known as Guest41572 | ||
niemeyer | fwereade: You really should :-) | 16:04 |
fwereade | niemeyer, oh, I will, but it's really inconvenient right now :) | 16:04 |
niemeyer | fwereade: Next week we'll have tons of time together to push awesomeness forward :) | 16:04 |
niemeyer | fwereade: LOL | 16:05 |
niemeyer | fwereade: I know how that feels | 16:05 |
niemeyer | fwereade: I was hacking until post midnight yesterday | 16:05 |
niemeyer | fwereade: Hard to stop when in a roll :) | 16:05 |
fwereade | niemeyer, yeah :) | 16:05 |
fwereade | TheMue, ping | 16:14 |
=== Guest41572 is now known as imbrandon | ||
TheMue | fwereade: mom | 16:15 |
=== imbrandon is now known as imbrandon_ | ||
fwereade | TheMue, it always disturbs me when you call me mom :) | 16:16 |
TheMue | fwereade: You're to me like a mom ;) | 16:16 |
fwereade | TheMue, aww :) | 16:16 |
fwereade | TheMue, well, all right darling | 16:16 |
=== imbrandon_ is now known as imbrandon | ||
fwereade | TheMue, (I'll ask now; but no rush, please just respond when you're ready, I might have to go in a sec, I'll see your response later) | 16:20 |
fwereade | TheMue, I'm getting a slight urge to do violence to the ResolvedMode stuff | 16:20 |
fwereade | TheMue, (1) I don't think we have any need for the 1000/1001 magic numbers | 16:21 |
fwereade | TheMue, (2) I don't think we have any need for anything other than SetResolved, ClearResolved, and WaitResolved() (retry bool, err error) | 16:22 |
fwereade | TheMue, ie I can't see a use case for WatchResolved; am I missing something? | 16:23 |
fwereade | TheMue, (hmm, actually, what I'd *really* like is a one-shot <-chan bool watch, I think it will mesh very nicely with my plans for the hook executor) | 16:24 |
fwereade | TheMue, anyway, let me know your thoughts | 16:24 |
fwereade | niemeyer, I would also appreciate your perspective on the above | 16:24 |
fwereade | I'm thinking that I want, on both Unit and RelationUnit: | 16:26 |
fwereade | SetResolved(retry bool) error | 16:26 |
fwereade | ClearResolved() error | 16:26 |
fwereade | WaitResolved() (retry <-chan bool, err error) | 16:27 |
fwereade | but ofc I'm open to mockery and dismissal :) | 16:27 |
fwereade | anyway, later all | 16:27 |
fwereade | niemeyer, (also, am I right in thinking that we can't separately resolve errors in relations of the same name? is this deliberate, or am I misreading juju/control/resolved.py?) | 16:29 |
TheMue | fwereade: So, back again. Our daughter had problems today. | 16:36 |
mramm2 | TheMue: sorry to hear about that | 16:37 |
TheMue | oops | 16:38 |
fwereade | TheMue, no worries, I might be able to pop back and read in 5-10 mins | 16:39 |
fwereade | TheMue, hope all is ok now | 16:39 |
TheMue | mramm2: Thankfully it's not her direct problem. It a harder problem by her best girl friend. But now our daughter has problems with her employer because she came later to the afternoon stint | 16:40 |
TheMue | fwereade: Yes, it's ok. Thx. | 16:41 |
TheMue | fwereade: So you're looking if the ResolvedMode is needed? Or what is your question? | 16:42 |
TheMue | fwereade: I've translated it from the python code, but if we don't need it anymore we should remove it. | 16:43 |
fwereade | TheMue, sorry, I'm really just asking if you're aware of any uses for it that I may have missed | 16:50 |
fwereade | TheMue, that can't be covered by what I proposed | 16:50 |
fwereade | TheMue, or if there's anything otherwise obviously ludicrous about what I suggest | 16:50 |
TheMue | fwereade: Right now I don't know. I'll take a look. | 16:52 |
TheMue | fwereade: So far it's not used, yes. I only ported it without looking who later will use it. | 16:55 |
TheMue | fwereade: In Py it's used by the agent. | 16:57 |
niemeyer | fwereade: Hah.. so I screwed up the copy & paste.. | 17:26 |
niemeyer | That's what I get for not self-reviewing | 17:26 |
TheMue | So, next proposal for the firewaller is in and I'm out. If we don't see tomorrow evening here we'll see on Sunday in Lisbon. | 18:27 |
TheMue | Have a nice evening. | 18:27 |
niemeyer | TheMue: Thanks, have a great trip! | 18:37 |
TheMue | niemeyer: Thx, yes, and you have a great trip too. Will be a long flight. | 18:38 |
niemeyer | TheMue: Thanks, this one is going to be surprisingly good, actually | 18:42 |
niemeyer | TheMue: A single leg.. first time ever | 18:42 |
TheMue | niemeyer: Yeah, so it's a good location. Only Dave will always ever have problems. | 18:42 |
TheMue | niemeyer: So we once should visit him. | 18:43 |
TheMue | :D | 18:43 |
niemeyer | TheMue: True :-) | 18:43 |
TheMue | niemeyer: Next UDS is very near. I'm already ching if not train will be better. | 18:44 |
niemeyer | TheMue: Nice, that should be a breeze indeed | 18:44 |
TheMue | niemeyer: Yes, but that's still some month in front. Let's face our sprint next week. | 18:45 |
niemeyer | TheMue: Yeah, and I have nightmareish trip before that, in early August | 18:45 |
niemeyer | 4 legs each way.. :-( | 18:45 |
TheMue | niemeyer: Ouch | 18:46 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!