hazmatbcsaller, lots of comments on the rel type branch..01:34
bcsallerhazmat: thanks, cool, I'll check it out01:34
hazmatnothing structural01:34
hazmatnot finished01:34
bcsallerhazmat: yeah, didn't post yet. I do like that it will IM me01:38
hazmatbcsaller, oh? i didn't know that it IMs02:01
bcsallerhazmat: when you log in with your google account I think its an account setting, you have to allow it access to your contacts or something02:02
bcsallerand then it shows up in google chat02:02
hazmatreview out02:06
bigjoolsanyone around who can help me debug stuff in the cloudinit provider please?05:09
TheMuefwereade: morning07:44
fwereadeTheMue, heyhey07:44
TheMuefwereade: new agent approach is in, now even more simplified07:44
fwereadeTheMue, reviewed, basically LGTM but with handwavey architectural notes08:05
TheMuefwereade: what does "handwavey" mean?08:07
fwereadeTheMue, that I can't really justify my claims, even if they feel right to me, so I've waving my hands around in an attempt to convince by distraction08:07
TheMuefwereade: hehe08:08
TheMuefwereade: i'm currently testing a bit with private interface methods. so that at initialization only the surrounding instance has to be passed.08:09
fwereadeTheMue, yeah, I don't think there's anything wrong with your choices: I think you'll end up changing them in the future, but IMO nothing there is unclear or unpleasant and it can mutate to fit in with the rest of the app when we know *how* it needs to mutate08:11
TheMuefwereade: the period and timeout are first shots, thats why i put them into constants. makes the tuning easier. could even be configurable in future08:13
fwereadeTheMue, yeah: those timings are good for testing08:13
TheMuefwereade: and the embeddable type surely can be public if wanted. do you know any place today where the mixin is used outside the state lib?08:13
fwereadeTheMue, I may be wrong, but I thought the agent types themselves would use it and I was unjustifiably expecting them to live outside state08:14
fwereadeTheMue, btw total quibble: I'm not sure you need "embed" in the name -- it's a perfectly good agent class on it own, even if it doesn't have any behaviour other than connect/disconnect08:15
TheMuefwereade: i've choosen it because it is no agent itself, it only provides something to embed for the work with/in agents08:17
TheMuefwereade: like the current type is called AgentMixin08:17
fwereadeTheMue, like I said, total quibble :)08:17
fwereadeTheMue, yeah, I'm not saying "you must change this", just "I would have done it differently"; maybe some of my arguments will strike you as good things but I don't think they're dealbreakers :)08:18
TheMuefwereade: yeah, currently there's no established way in go how to name a type wich is intended to be embedded only08:18
TheMuefwereade: otoh AgentEmbed sounds indeed strange.08:21
fwereadeTheMue, random thought: AgentCore?08:21
TheMuefwereade: core isn't used yet in the go port, but base. so i would prefer agentBase. and btw, todays mixin is only used inside state. so it's ok to let it be private08:25
fwereadeheya rog08:51
fwereadeer, wrtp :)08:51
wrtpfwereade: mornin'08:52
* wrtp doesn't seem to have a hangover but can't quite believe it yet.08:52
fwereadewrtp, it's probably waiting in the wings :p08:53
wrtpfwereade: that's what i'm worried about. am continuing to drink water...08:53
wrtpTheMue: i still don't understand quite how you intend agentEmbed to be used. on the one hand, it has a Pinger, which is something used by the agent itself; but on the other hand it calls Alive, which is something to be used by something outside the agent.09:00
wrtpTheMue: i'm not sure that it makes sense to put both of these things in the same type.09:00
wrtpTheMue: good morning BTW!09:00
TheMuewrtp: moin ;)09:02
TheMuewrtp: it's just used like the old AgentStateMixin09:03
wrtpTheMue: i'm not sure that we need to faithfully copy every detail of the python structuring.09:03
TheMuewrtp: it's embedded into Service, Machine, Unit (and maybe some more)09:03
wrtpTheMue: as it is, it just looks to me like a very thin wrapper around the presence package.09:04
wrtpTheMue: (presence + one method that does a timeout)09:04
TheMuewrtp: dunno if any architectural changes are planned. afaik the first goal is to catch up with the python implementation and later make changes09:04
wrtpTheMue: i think we're copying behaviour, not internal architecture.09:05
wrtpTheMue: after all, this is quite a different language, and different structuring is often appropriate.09:05
TheMuewrtp: it is, yes. but while presences is a technique regarding zk the wrapping is a more semantical encapsulation. otherwise we deon't need a state, every state user could use zk itself.09:06
wrtpTheMue: i look at this code and i think "what does this actually *do*?".09:06
TheMuewrtp: currently it's only demonstrating a way to discuss about09:07
wrtpTheMue: as far as i can see, this is a convenience for stuff *inside* state, not an important visible abstraction.09:07
TheMuewrtp: later that agentEmbed will be embedded in at least Service, Machine and Unit. And with that step they all will get the agent functionality.09:07
wrtpTheMue: yeah, ok, i think i see it now09:08
TheMuewrtp: it's just a pretty simple encapsulation that doesn't hurd but bundles logical behavior instead of reimplement those four methods inside of each type which needs it09:09
wrtpTheMue: how about calling the type "agent" rather than agentEmbed09:09
wrtpTheMue: then the various unit types can be UnitAgent, ServiceAgent, etc09:10
wrtpTheMue: and they'll embed it09:10
TheMuewrtp: fwereade and i already discussed about the naming. agendEmbed is indeed ugly, but only agent is also wrong. it "is" no agent. so i would prefer agentBase (or fwereades' agentCore).09:11
TheMuewrtp: the embedding types are just stete.Service, state.Machine, state.Unit09:12
wrtpTheMue: what about agentPresence?09:12
wrtpTheMue: after all, that's what the type implements09:12
TheMuewrtp: no, in this case all state types would have to be called UnitZK, ServiceZK, ...09:13
TheMuewrtp: no information about "how" please, only about "what"09:13
wrtpTheMue: i don't understand. isn't the type about the presence or absence of an agent?09:14
wrtpTheMue: regardless of the fact it uses the presence package.09:14
TheMuewrtp: the usage of those methods is btw spreaded. has_agent (now AgentConnected) is e.g. calles by juju.control.status09:14
TheMuewrtp: it's about if an agent is connected or not. this naming has been a proposal by fwereade09:15
fwereadeTheMue, wrtp: I'm starting to lean towards just state.Agent myself09:16
wrtpTheMue: connected==present, no?09:16
wrtpfwereade, TheMue: i'm wondering if rather than embedding this type, each type (Service, Machine etc) could have a field or method which returns the Agent.09:16
TheMuewrtp: yep09:16
wrtpfwereade: then you'd call, e.g. svc.Agent().Connected()09:17
wrtprather than svc.Connected()09:17
fwereadewrtp, that reads very nicely, yeah09:17
TheMuewrtp: what are your concerns regarding embedding (aka mixin in py)?09:17
TheMuewrtp: you /only/ win the additional ().09:18
wrtpTheMue: i think the fact that the methods are named AgentConnected, WaitAgentConnected etc hints to me that this is really an independent type struggling to get free :-)09:18
wrtpTheMue: if we don't embed, then we can use the more natural Connected(), WaitConnected(), Connect() and Disconnect()09:19
TheMuewrtp: i can remove those Agent parts ;)09:20
TheMuewrtp: every embedded type is an own type, nothing else, but only "embedded"09:20
wrtpTheMue: yeah, but when the methods are directly on Unit etc then it's not entirely obvious that they're about the agent associated with the type.09:20
TheMuewrtp: that's why i put Agent into the name ;)09:20
wrtpTheMue: i'm not sure it's a big win to have it embedded. it means that, for instance, the agent methods will be documented several times.09:22
wrtp(i think - i'll just check)09:22
TheMuewrtp: your arguments match to all embedded types. they allways could be put in as extra field09:22
wrtpTheMue: not when the embedded type is there to satisfy an interface, which is the usual reason for using them09:22
TheMuewrtp: yeah, documented exactly where they are matching, at a Service, Unit, Machine09:22
TheMuewrtp: … which is one (of many) use cases for type embedding, but it's not restricted to only this one.09:23
TheMuewrtp: type embedding is the good old composition, nothing more09:23
wrtpTheMue: i think that using them to satisfy interfaces is the usual reason. otherwise why embed rather than just adding a field or a method?09:28
wrtpTheMue: BTW AFAICS if you have an embedded type, the embedded methods aren't documented at all. i thought they'd fixed that, but it seems not.09:28
TheMuewrtp: but opposit of embedding/using an accessor we maybe shoud discuss with gustavo how this topic should be handled in future. the provided methods of todays mixin are only used in tests and at about 5 places in code. ;)09:29
wrtpTheMue: sounds like a reasonable reason for not embedding it to me - no particular need to privilege those methods.09:30
TheMuewrtp: good to know (the doc info). if you embedd a type you don't need an accessor method. and if you alternatively make the field public anyone could write to it (what could be unintended).09:30
wrtpTheMue: that's not unusual. just because something is public doesn't mean you're allowed to write to it. (there are lots of examples in the core Go tree)09:32
TheMuewrtp: it seems to me that you more have a problem that it is embedded than if it is logically working the right way or maybe should be organized a different way?09:32
TheMuewrtp: which doesn't make it better (those exambles) for long term maintainability09:32
wrtpTheMue: yeah, i'm happy with the functionality. i think it would work well (and be better documented) as an independent type.09:32
wrtpTheMue: i'm concerned that if we embed it: a) we won't see any documentation for the Agent* methods at all or b) we'll get the same documentation comments repeated several times.09:34
TheMuewrtp: btw, it IS an independent type also. there's no problem (beside the weird naming) with using it as a field09:34
wrtpTheMue: cool. in which case why not just call it Agent, rather than assuming it's going to be embedded?09:35
TheMuewrtp: the first argument is indeed bad, yes. multiple times wouldn't bother me, because i don't have to navigate to a different type to get the doc.09:35
TheMuewrtp: is it an agent?09:35
TheMuewrtp: or does it represent an agent?09:36
wrtpTheMue: the latter, i think.09:36
wrtpTheMue: it's all that the state package knows of agents, AFAICS09:36
TheMuewrtp: what btw is an agent exactly?09:37
wrtpTheMue: an agent is the program that runs on the machines or units etc and implements the connection between the state and the actual juju behaviour.09:38
wrtpTheMue: so, Agent wouldn't *be* the agent, but it would represent one.09:38
TheMuewrtp: still not absolutely happy with it09:40
TheMuewrtp: i would like to know more about the motivation why the original code has choosen a mixin (opposit to a regular type).09:41
TheMuewrtp: if that had no real reason i'm fine with those changes you've mentioned09:41
wrtpfwereade: what do you think? was there a particular reason why the original code chose to use a mixin rather than a regular type?09:42
fwereadewrtp, TheMue: it's common behaviour across a few types that aren't otherwise related; don't think there was any deeper reason than that09:43
wrtpfwereade: do you think Agent as a name for the type seems reasonable?09:43
wrtpfunc (u *Unit) Agent() *Agent09:44
fwereadewrtp, yeah, I think so, package naming should take care of type ambiguity09:45
fwereadewrtp, but I feel that this remains somewhat academic until we have a client09:45
wrtpfwereade: agreed.09:46
wrtpfwereade: i think it'll simplify the documentation though. rather than "agentEmbed is a helper type to embed into those state entities which..." we can have "Agent represents a juju agent."09:47
wrtpTheMue: does that sound reasonable to you?09:47
TheMuewrtp: it's ok for me to name it Agent (even if i'm still not absolutely happy with it). but mixins/emebeds are a nice way for my to encapsulate related functionality to weave it transparently into multiple types09:47
TheMuewrtp: naming and doc change is ok09:48
wrtpTheMue: embedding could still work ok if we embedded the Agent as a public field. i'm not sure that'll be the best idea, but it would allow the same access pattern.09:49
wrtpTheMue: cool. sorry for my usual recalcitrance :-)09:50
TheMuewrtp: no, please no public field. than i would better prefer an accessor09:50
wrtpTheMue: fair enough. unit.Agent().WaitConnected() it is then :-)09:51
TheMuewrtp: will change the proposal but will also ask gustavo09:51
wrtpTheMue: sounds good09:52
* TheMue still likes type embedding even w/o the needance of an interface implementation09:52
* wrtp has been trying to look for examples where it's used like that.09:55
TheMuefwereade: changed the timout value, but that's bad for tests. so i have to change it to be configurable10:07
TheMuewrtp: we are 'before' Go 1, the language is young. so it will still last a long time until all good pattern/idioms are found10:08
wrtpTheMue: true.10:08
wrtpTheMue: but there is lots of good code already...10:08
TheMuewrtp: yep10:08
TheMuewrtp: and also lots of bad code10:11
wrtpTheMue: of course, but not much in the Go tree as far as i've seen. that's my "gold standard"...10:11
TheMuewrtp: and both will grow, with some/few pearls and a lot of bollocks10:12
wrtpTheMue: sure.10:12
fwereadebigjools, are you there?10:39
wrtpTheMue, fwereade: trivial review for you: https://codereview.appspot.com/5845045/10:47
TheMuewrtp: LGTM, but what does IsError() additionally do?10:49
wrtpTheMue: additionally?10:50
wrtpTheMue: you mean "what does it do as well as check the particular zk error code?"10:50
wrtpTheMue: or just "what does it do?"10:50
TheMuewrtp: ok, better, what does it more than err = ...?10:52
wrtpTheMue: zk errors are no longer simple integer types.10:52
wrtpTheMue: check out the new version of zk.10:52
TheMuewrtp: but error types, aren't they?10:53
TheMuewrtp: will look later, have to leave for about two hours10:53
TheMuewrtp: cu10:53
wrtpTheMue: yeah, the thing you want to compare is the error code, not the struct containing it10:53
wrtpTheMue: have fun10:53
TheMuewrtp: ah, ok, thx10:54
wrtpTheMue: i did originally name the function "HasErrorCode" but niemeyer suggested IsError10:54
wrtpTheMue: which is a better name i think.10:54
=== TheMue_ is now known as TheMue
fwereadewrtp, LGTM11:21
wrtpfwereade: i think i'm gonna submit as it's so trivial11:22
fwereadewrtp, sounds good to me11:23
fwereadewrtp, were you working on an extension to testing to get States?11:24
fwereadewrtp, or did you decide to leave it?11:24
wrtpfwereade: i decided that testing shouldn't rely on the state package, but i am working on an extension to testing to clean the zk tree.11:25
fwereadewrtp, sweet11:25
wrtpfwereade: i'm wondering about exporting a ZkRemoveTree function from testing too, so we don't have *three* implementations...11:27
fwereadewrtp, +10-11:27
fwereadewrtp, how does https://codereview.appspot.com/5832045 look to you?11:50
wrtpfwereade: it seems a little odd that the ContextId can't be inferred from the Context...11:52
fwereadewrtp, I see ContextId as only meaningful in a map[string]*Context11:53
fwereadewrtp, it's not like the Context ever uses the id itself11:53
wrtpfwereade: i was thinking that perhaps it would work well if the context id was created in (and stored inside) the context itself.11:54
wrtpfwereade: makes it easy for methods on the context to print it out in log messages too, which might be useful11:54
fwereadewrtp, I don;t think the context id will be helpful in a log; the unit and relation definitely are, but the context id tells us nothing11:54
fwereadewrtp, the members *might* be but that should be left up to the user, we don't want to print an arbitrarily long list of members every time11:55
wrtpfwereade: can't we potentially have several contexts for a given unit/relation pair?11:56
fwereadewrtp, the only meaningful way in which they will differ is in the members list11:56
wrtpfwereade: they've also got state too, right?11:56
fwereadewrtp, and what temporary/cached settings they happen to have11:57
wrtpfwereade: yeah11:57
wrtpfwereade: *shrug*11:57
fwereadewrtp, yeah, but any State object will do; it's about the state of the env, not something unique to the context11:57
wrtpfwereade: not quite, because there's temporary state that gets flushed (or not), right?11:58
fwereadewrtp, (heh, where "env" refers to the global ZK environment)11:58
fwereadewrtp, yeah, that's the map[string]*ConfigNode stuff I mentioned11:58
fwereadewrtp, which remains, technically, speculation11:58
wrtpfwereade: just seems like it might be a nice place to store the context id. we're always gonna have a 1-1 relationship of context<->id, no?11:59
fwereadewrtp, why duplicate the information? it'll be in a map of context ids to contexts anyway12:00
wrtpfwereade: in the past when i've had map[id]something, i've usually ended up putting the id in the something eventually.12:00
fwereadewrtp, then we can put it in as soon as there's a need :)12:00
wrtpfwereade: if you do that, you'll remove the field from ExecInfo, right?12:00
fwereadewrtp, ofc12:00
wrtp(that's a good enough reason for me, BTW)12:01
fwereadewrtp, cool :)12:01
fwereadewrtp, TheMue: I want to add something to testing, and I need opinions12:06
fwereadewrtp, TheMue: specifically I want to move the test charms repo into testing and add some methods that always returns paths to copies of those charms (which should remain inviolate)12:07
wrtpfwereade: sounds like a good idea to me12:07
wrtpfwereade: make testing pull its weight a little more :-)12:08
fwereadewrtp, TheMue: have me made a semi-firm decision to keep dependencies out of testing?12:08
wrtpfwereade: not necessarily12:08
fwereadewrtp, TheMue: because what'll actually be *convenient* 9 times out of 10 is "gimme a Charm", not a path-to-a-charm12:08
wrtpfwereade: does that mesh well with the current charm testing code?12:09
fwereadewrtp, depends: in go/charm itself, sometimes but definitely not always12:10
fwereadewrtp, in terms of tests for state, and also for hooks (which will be using state)12:10
fwereadewrtp, ...pretty much always, I think12:10
wrtpfwereade: i'm happy either way. the testing package is all about convenience, and dependencies don't matter too much (although it's nice to keep them down as usual)12:11
fwereadewrtp, well, ok, both charms and paths-to-charms will be useful in both situations12:11
fwereadewrtp, cool, thanks12:11
wrtpfwereade: you've got a reivew12:26
fwereadewrtp, cheers12:26
wrtpfwereade, TheMue: another review for your entertainment and delight:  https://codereview.appspot.com/584104712:52
fwereadewrtp, what would you think of renaming TestingT to Fatalfer?13:00
wrtpi wondered about that.13:00
fwereadewrtp, my brain got tangled up trying t figure out what was actually in play there13:00
fwereadewrtp, and since a gocheck.C would work just as well...13:00
fwereadewrtp, ...the T feels wrong13:01
wrtpfwereade: agreed13:01
wrtpfwereade: but i couldn't think of a better name13:01
fwereadewrtp, Fatalfer is ugly but effective13:01
wrtpfwereade: true, and noone is ever gonna name it :-)13:01
fwereadewrtp, IMO13:01
wrtpok, i'll change it13:02
fwereadewrtp, yeah13:02
fwereadewrtp, cool13:02
fwereadewrtp, reviewed13:03
wrtpfwereade: "Can we really delete "/" without getting an error?"13:04
wrtphmm, seems so!13:04
fwereadewrtp, it's not in the tests13:04
wrtpfwereade: ah, good point13:04
wrtpfwereade: will add it13:04
fwereadewrtp, cool, thanks13:05
wrtpniemeyer: hiya!13:38
niemeyerMorning jujuers!13:38
fwereadeniemeyer, heyhey13:45
TheMueniemeyer: moin ;)13:46
wrtpTheMue: any particular reason why some methods are on *TopologySuite and some on TopologySuite?13:46
TheMuewrtp: have to look, normally no reason.13:47
wrtpTheMue: ok, was thinking of editing to make them consistent.13:48
fwereadewrtp, LGTM13:48
wrtpTheMue: another thing: why is TopologySuite in internal_test.go? i haven't looked too hard, but it looks like most of what it does is using public methods. you could maybe get away with putting readTopology into export_test.go, perhaps?13:50
TheMuewrtp: it's only needed in SetUpTest() due to field modification13:51
wrtpTheMue: what is?13:52
TheMuewrtp: it's there because in the first approach the methods have been private13:52
wrtpTheMue: ah, so it could go back outside internal_test? that would be a good thing to do, i think.13:52
TheMuewrtp: hehe, that's the problem of asking a second question while the first isn't answered yet13:53
wrtpTheMue: ah you mean *TopologySuite is only needed in SetUpTest?13:53
TheMuewrtp: yep13:53
wrtpi think i'd just make 'em all pointer-receiver13:53
wrtpTheMue: it's pretty conventional to do that.13:54
TheMuewrtp: could do this, yep, would change nothing beside the fact that any test could create side-effects by modifying the suite data by accident13:57
wrtpTheMue: i don't mind that13:58
TheMuewrtp: btw, the agent entity in the test will be removed if we agree that this approach is the right one. it has been there only for testing.13:58
wrtpTheMue: ok.13:58
TheMuewrtp: as i don't mind about not always use reference types13:59
TheMuewrtp: otherwise, why aren't all automatically reference types, e.g. like in java?13:59
wrtpTheMue: i usually go all one or all the other.13:59
TheMuewrtp: what do you win with that approach?14:00
wrtpTheMue: i usually use reference types when the struct is bigger than a few words.14:00
wrtpTheMue: dunno really, just seems conventional.14:00
TheMuewrtp: regarding agent, i would still like to keep it private. it's no standalone data type and will only be used directly inside the state package14:01
wrtpTheMue: that's only true if it's embedded. i'm thinking that it'll be returned as an object in itself.14:01
wrtp[09:44] <wrtp> func (u *Unit) Agent() *Agent14:02
TheMuewrtp: one can call myUnit.Agent().Connected() w/o problems14:02
wrtpTheMue: if the Agent method is exported, i think its return type should be.14:03
wrtpTheMue: otherwise you can't declare a variable to assign it into.14:03
TheMuewrtp: you don't need an extra variable14:03
wrtpTheMue: you might want one...14:04
TheMuewrtp: why?14:04
TheMuewrtp: what's the use case?14:04
wrtpTheMue: so you can use it some way that's independent of the unit its associated with.14:04
wrtpTheMue: having a publicly exported method with a private return type seems a bit... rude.14:05
wrtpTheMue: and then you won't see the docs for the methods either.14:05
TheMuewrtp: that's why i preferred the embedded approach first14:05
wrtpTheMue: i don't see why we can just export the Agent type. seems to work ok for me.14:06
niemeyerwrtp: Which methods would be in the Agent?14:06
TheMuewrtp: so anyone can do an agt := &state.Agent{st, "/some/crude/path", nil} ?14:07
wrtpniemeyer: https://codereview.appspot.com/5782053/diff/15001/state/agent.go14:07
TheMueniemeyer: it's the reincarnation of the old AgentStateMixin14:07
wrtpTheMue: only if you export the fields.14:07
TheMueniemeyer: my second approach has been to create it as type that can be embedded14:08
TheMuewrtp: ok, agt := &state.Agent{}14:08
wrtpTheMue: that's true of any exported type.14:08
wrtpTheMue: including State, etc14:08
TheMuewrtp: yep, that's why i'm careful with exporting14:09
TheMuewrtp: Agent only makes sense together with its state entity14:09
wrtpTheMue: i disagree. it makes perfect sense for a unit agent to get the Agent from its Unit and use that independently.14:10
TheMuewrtp: and forget about the unit state?14:11
wrtpTheMue: (if it feels like it)14:11
wrtpTheMue: yeah, why not?14:11
wrtpTheMue: it'll be doing other things with the unit state, but it's not nonsense to use the Agent type independently.14:12
niemeyerTheMue: I suggest having those methods on the unit itself..14:12
TheMueniemeyer: hehe14:12
niemeyerTheMue: StartAgentPinger, IsAgentAlive, WaitAgentAlive..14:12
TheMueniemeyer: that's what i had with embedding14:12
niemeyerTheMue: You don't need DIsconnect.. just return the pinger14:12
niemeyerTheMue: No need to embed either.. this is the unit..14:12
TheMueniemeyer: only the unit? today it's also in machine and service14:13
niemeyerTheMue: pinger should be returned, rather than kept within the agent/unit14:13
niemeyerTheMue: Ah, bad assumption on my part.. nevermind then14:13
wrtpniemeyer: you might prefer TheMue's original implementation: https://codereview.appspot.com/5782053/diff/7001/state/agent.go14:13
TheMueniemeyer: we had a longer discussion about different variants this morning14:14
niemeyerTheMue: Yeah, just export Agent then..14:14
wrtpniemeyer: i thought that if this functionality was going to be used in several different places, that it would make sense as an independent type rather than embedding it.14:14
niemeyerTheMue: Sounds good, sorry for jumping in.. I'm clearly missing details14:14
niemeyerwrtp: +114:14
niemeyerwrtp, TheMue: What's there looks quite good, FWIW14:14
wrtpniemeyer: hence the current proposal.14:14
wrtpniemeyer: the latest version? or the earlier one?14:15
TheMueniemeyer, wrtp: ok, will go in in a few moments as new proposal14:15
niemeyerwrtp: What's in https://codereview.appspot.com/5782053/diff/15001/state/agent.go14:15
wrtpniemeyer: cool14:15
wrtpniemeyer: i'm thinking that with the agent type exported, it'll work well.14:16
wrtpniemeyer: but i'm not sure that TheMue agreeds :-)14:16
TheMuewrtp: no pro, 3 to 1 ;)14:16
wrtpTheMue: i'm hoping you'll agree too when you see it being used :-)14:17
TheMuewrtp: nah, there only has been small doubts. i simply like embedded types.14:19
wrtpme too... in their place :-)14:19
TheMuewrtp: so i now can also remove the test type and integrate agent into unit as a first run14:22
wrtpTheMue: sounds good14:22
* wrtp goes to lunch.14:38
niemeyerfwereade: ping14:40
fwereadeniemeyer, pong14:40
niemeyerfwereade: Do you have a moment for a call?14:40
fwereadeniemeyer, sure14:40
fwereadeniemeyer, g+?14:41
niemeyerfwereade: Sounds good14:41
fwereadeniemeyer, invited14:43
niemeyerfwereade: You too :-D14:43
fwereadeniemeyer, ha, sorry, I'll join yours; ok?14:43
niemeyerfwereade: Ok, I'm moving, ok?14:43
niemeyerfwereade: Choose a random number, now! :-)14:43
wrtpare we having a meeting now?16:03
wrtpniemeyer, hazmat: ^16:03
fwereadewrtp, an hour from now I think16:05
wrtpfwereade: my calendar said now.16:05
wrtpfwereade: but i'm happy to go with an hour from now too16:06
fwereadewrtp, niemeyer said "lunchtime" ;)16:06
wrtpfwereade: ah, that's fairly conclusive :-)16:06
hazmatmeeting in 1hr16:07
hazmati pushed it to the same time not taking into account aforementioned timezone shifts16:07
hazmaton the calendar16:07
* niemeyer waves17:01
niemeyerhazmat, fwereade, wrtp, bcsaller, jimbaker: Party time?17:02
wrtpniemeyer: yay!!!17:02
jimbakersorry, i need to find a better place. didn't realize we had a meeting now17:04
hazmatinvites should be out17:04
niemeyerI used to hangout with people.. nowadays I hangout with extras..17:04
wrtpbizarre, i wonder where my windows have been disappearing to18:02
wrtpthey've all gone, including my editor (this IRC window, until i quit it from the sidebar and restarted it), my music player, etc18:03
wrtpbut they're still running!18:03
wrtpguess i'll try restarting unity18:03
wrtpweird, i did that and they've all come back .... except for Chrome which has now disappeared again18:05
wrtptime to reboot, i think18:05
wrtpand i can't type into any of them except this one!18:06
wrtpniemeyer: that error will never happen unless something is doing a concurrent delete alongside ZkRemoveTree18:12
wrtpniemeyer: because we'll get an error earlier when calling zk.Children18:12
niemeyerwrtp: That error will never happen unless it happens.. you've documented it to have a given behavior, so either implement the behavior or remove the comment.18:16
wrtpniemeyer: fair enough18:17
fwereadewrtp, I strongly fvour removing the comment18:18
fwereadewrtp, I'd rather have that test fail than other tests work with weird inconsistent data18:18
wrtpfwereade: i think it's important to be able to do ZkRemoveTree("/x") and have it work when /x doesn't currently exist18:19
wrtpfwereade: it means that a test can be correctly torn down even if the path was not created as expected.18:20
fwereadewrtp, should we not specifically be ignoring ZNONODEs though?18:20
niemeyerfwereade: The end result is the same if the node doesn't exis18:20
niemeyerfwereade: RIght, that's what's documented18:20
fwereadewrtp, if there's any other error we want to know about it18:20
fwereadeniemeyer, ^18:20
niemeyerfwereade: Yeah18:21
wrtpfwereade: yeah. i am, but i hadn't taken into account the possibility that something might be deleting nodes concurrently with ZkRemoveTree18:21
wrtpfwereade: that's what i do, i think18:21
fwereadewrtp, ohhh... sorry, yes, you never get to delete if you got a ZNONODE out of children18:22
wrtpfwereade: yup18:22
fwereadewrtp, I guess we're unlikely to call that any time other than test teardown so it's unlikely anything else would be working concurrently18:24
wrtpfwereade: that was my thought, but i'm checking anyway now, for completeness' sake.18:24
fwereadewrtp, yeah, seeing two "unlikely"s in the same sentence makes me nervous ;)18:25
wrtpfwereade: i'm not going to add a test though 'cos it's hellish difficult to test.18:25
fwereadewrtp, I think I'm ok with that :)18:25
wrtpfwereade: phew18:25
niemeyerwrtp: It's already quite awesome that we have testing for the testing functions at all :)18:29
* wrtp smiles and nods.18:29
wrtpit was easy to do and i wanted to check the thing worked!18:30
wrtpniemeyer: submitted. thanks for the review.18:38
fwereadewrtp, just saw a transient failure in TestStartAndClean: "cannot start ZooKeeper server: "cannot listen on port 21812: listen tcp address already in use"18:43
wrtpfwereade: hmm18:44
wrtpfwereade: i think perhaps there is a race because the server might hang on to the port for a little longer than it should after Destroy.18:45
fwereadeniemeyer, wrtp: gtg before cath becomes vexed, but: https://codereview.appspot.com/5845051 (and happy weekends!)18:45
wrtpfwereade: nice.18:45
wrtpfwereade: and a very happy weekend to you too18:46
wrtpfwereade: perhaps we should not always start the server on the same port.18:46
wrtpfwereade: i was considering making that change anyway.18:46
wrtpfwereade: because it eliminates a nasty category of difficult-to-diagnose error.18:46
wrtpfwereade: the problem is that we can't reliably pick a good port to use, because there's if we use a socket to check it, there's a possibility that the port allocation lingers for a little while even after the connection's been closed.18:48
niemeyerfwereade: Cheers!18:49
niemeyerfwereade: Great way to close the week! :-)18:49
wrtpniemeyer: i'm off too. have a good weekend!19:12
=== dvestal|away is now known as dvestal
niemeyerwrtp: Thanks, a good one for you as well19:33
niemeyerI'll actually break now.. will be back in an hour or so for more reviews19:33
hazmatfwereade, i remember talking to you about this bug https://bugs.launchpad.net/juju/+bug/920000 a while ago.. i believe you said it was invalid?19:39
fwereadehazmat, as I recall it implies some can't-happeny environment weirdness -- it's clearly somehow related to the twisted change but we couldn't figure out exactly how20:40
hazmatfwereade, okay.. so not fixable without reproduction, which shouldn't be possible?20:42
fwereadehazmat, yes, well put20:42
hazmatfwereade, thanks20:44
hazmatniemeyer re status output..     relations:20:46
hazmat        db: [blog1, blog2]20:46
hazmatif a client has multiple relations to the mysql db in this case..  it would show up multiple times in that list without any contextual information to differentiate20:46
niemeyerhazmat: Yo!21:40
niemeyerhazmat: Sorry, that took longer than expected21:40
niemeyerhazmat: We have two options: 1) mention as many times as necessary, with more context; 2) mention a single time, and if you want to know how e.g. blog2 is connected to mysql, well, look at blog221:42
niemeyerhazmat: Option 2 is more concise21:43
hazmatniemeyer, option2 feels like a cleaner ui, if any of the connections from it are failing than it shows under relation-error:21:44
niemeyerhazmat: +121:45

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!