=== bigjools_ is now known as bigjools
=== jtv2 is now known as jtv
jamwallyworld__: welcome back! I hope you had a great break04:45
wallyworld__jam: thanks, yes it was great. i hardly opened the computer at all. it was against the rules i was told by the better half04:45
jamdid you travel at all?04:46
wallyworld__jam: how was your break?04:46
wallyworld__jam: yes, went north to mackay to visit a friend04:46
wallyworld__went to the whitsunday islands etc, very nice04:46
jampretty good. No travelling, but took it easy, did lots of family stuff.04:46
wallyworld__yeah, back to reality today :-(04:46
wallyworld__jam: i have to go and get the car back from the repairer, may be a few minutes late for our call05:10
jamwallyworld__: np05:10
wallyworld__jam: hi, you free now?06:03
jamwallyworld__: yeah, sorry I missed your message.06:08
TheMue*: Morning.07:26
rogpeppefwereade_, jam, mgz, TheMue, wallyworld__: mornin' all07:51
jammorning rogpeppe07:51
TheMuerogpeppe: hiya07:51
fwereade_rogpeppe, jam, TheMue, mgz, wallyworld__: mornings!07:52
rogpeppefwereade_: thinking about it last weekend, i definitely think that checking for state-fatal errors (and having workers be more independent) is the way to go08:39
fwereade_rogpeppe, cool08:39
rogpeppefwereade_: i have an idea for how it might work actually08:39
fwereade_rogpeppe, oh yes?08:39
rogpeppefwereade_: rather than making sure that errors need to be passed back preserving the "this was caused by a state-fatal problem" property, we could make the underlying operations on state check the error from mongo, and record a "was fatal" flag in the state if it found one08:40
rogpeppefwereade_: then we could just check the state to see if we should reconnect or not08:41
rogpeppefwereade_: when we get an error from a worker08:41
fwereade_rogpeppe, do you recall what the problem that prevents us from checking the state's liveness/sanity in the first place was?08:41
fwereade_rogpeppe, because I worry a little that setting broken state *everywhere* we return some mongo error may be somewhat burdensome and hard to do right08:42
rogpeppefwereade_: no, but i'm wary of another probe - particularly when we might have timeout errors08:42
fwereade_rogpeppe, hm, reasonable, still not 100% sure that solution will cover us adequately08:43
rogpeppefwereade_: i don't think it's necessarily a problem - if we wrap Run we get a long way08:43
fwereade_rogpeppe, mm, I'm more worried about the arbitrary gets of a doc here, a few fields there, etc08:45
rogpeppefwereade_: basically, i think we can wrap a few mgo methods to check the error, and i *think* that'll be sufficient08:45
fwereade_rogpeppe, yeah, maybe we're restricted to something like  FindCount, FindOne, FindAll, FindFieldsOne, FindFieldsAll08:46
fwereade_rogpeppe, interesting08:46
rogpeppefwereade_: yeah, that's the idea08:46
fwereade_rogpeppe, tentative SGTM then08:47
rogpeppefwereade_: cool, we'll see.08:53
rogpeppefwereade_: just gotta reboot08:53
dimiternjam: ping09:09
fwereaderogpeppe, TheMue, dimitern, jam, mgz: btw I have a couple more doc drafts in review: https://codereview.appspot.com/7094052/ and https://codereview.appspot.com/7095049/09:59
fwereadeall lifecycle-related and mostly accurate09:59
fwereadebut the service destruction stuff is speculative -- it already exists in slightly different form, but needs to be reworked as agreed elsewhere10:00
rogpeppefwereade: will have a look in a bit. thanks.10:00
TheMuefwereade: *click*10:00
TheMuearam: moin10:17
fwereadeTheMue, what's the status of 006-state-retry-delay?10:27
TheMuefwereade: I'll get an answer by Dave tomorrow why he prefers a different solution.10:28
TheMuefwereade: He has it on his todo but didn't found time for it today, so he sent me a little note.10:29
fwereadeTheMue, ok, cheers10:31
fwereaderogpeppe, 181-mgo-show-log has been approved for a while, is it ok?10:32
rogpeppefwereade: hmm, i'd forgotten about that10:33
rogpeppefwereade: will submit10:34
fwereaderogpeppe, cool10:35
rogpeppefwereade: thanks - i should really go through my outstanding CLs some time!10:38
niemeyerGooood morning all!10:48
dimiternniemeyer: hey, morning :) happy new year and congrats on the baby!\10:48
niemeyerdimitern: Thanks, and happy new year too10:49
fwereadeniemeyer, heyhey!10:50
fwereadeniemeyer, happy new year and many congratulations!10:50
fwereadeniemeyer, you had any sleep yet? ;p10:50
niemeyerfwereade: Kind of :-)10:51
fwereadeniemeyer, cool, treasure it ;)10:51
TheMueniemeyer: Oh, hello, and a happy new year and grats to the new born child from my side too.10:51
niemeyerfwereade: Ale is obviously suffering a bit more as every other hour he demands her attention10:52
fwereadeniemeyer, yeah, it can all get a bit much10:53
niemeyerTheMue: Heya! Thanks!10:53
TheMueniemeyer: Even if the first weeks are hard enjoy them. Little children are a precious wonder, and getting a smile opens the heart.10:55
niemeyerTheMue: Yeah, we're definitely enjoying it a lot10:56
TheMueniemeyer: For us this time is now so long away, but still each day is different and interesting. Currently we're discussing ideas about jobs and our older daughter now has a driver license (and we no car anymore, she's using it all the time). :D10:59
rogpeppeniemeyer: yo!11:04
rogpeppeniemeyer: brilliant news, BTW, i was so happy when i saw your G+ announcement.11:05
niemeyerrogpeppe: Hey man!11:06
niemeyerrogpeppe: Thanks for sharing the joy11:06
=== _mup__ is now known as _mup_
hazmatniemeyer, g'morning, and congratulations!11:29
niemeyerhazmat: Morning, and thanks!11:29
rogpeppefwereade: https://codereview.appspot.com/709605411:43
fwereaderogpeppe, cheers11:44
rogpeppeniemeyer: you might wanna take a look too - there's a new package that hopefully you won't consider too crackful :-)11:45
niemeyerrogpeppe: I'll start from the bottom up11:47
rogpeppeniemeyer: where's the bottom? :-)11:47
niemeyerrogpeppe: I'll have a look at the changes done since I went out11:48
rogpeppeniemeyer: good plan11:48
rogpeppefwereade: what's your intended audience for the docs? much of the death-and-destruction document seems to me like it might live more happily as comments inside the state package.11:52
fwereaderogpeppe, yeah, I had that though too11:52
rogpeppefwereade: in particular, talking about transactions seems like it's really very implementation-specific. i'd thought that the docs were to be higher level.11:53
fwereaderogpeppe, the trouble with the state docs is that they are by their nature distributed across files and it's hard to explain things clearly that way11:53
rogpeppefwereade: perhaps an overview doc comment in state.go might be the way forward11:54
rogpeppefwereade: i'd like to see some docs on death and destruction that will still be valid after we've moved over to using the API11:55
fwereaderogpeppe, but the real purpose of that CL is to get people either agreeing or disagreeing with what's there, because I feel like the state package is approaching maturity11:55
fwereaderogpeppe, will those not still be valid?11:55
fwereaderogpeppe, the same stuff will happen, but in a different place, surely?11:55
rogpeppefwereade: i'm just not sure how helpful it is to see the implementation details (e.g. "Removing a unit involves *two* transactions, defined as follows:") when what we're trying to do, i think, is document what we're aiming towards - the externally visible behaviour rather than the details of how we make that happen.11:58
rogpeppefwereade: i'm not saying that it's not good to have implementation details somewhere, but i *think* that closer to the source is better for those.11:59
fwereaderogpeppe, I need at least one other person to analyze my plans at this level of detail11:59
rogpeppefwereade: i think that's a great plan, but i think that should be either an email to juju-dev or a doc comment in state. i still think it's worth having a document that summarises at a high level (and hopefully very simply) our approach to death and destruction.12:00
fwereaderogpeppe, I think the line-by-line comments make a CL a good discussion point; much of it may go well in doc comments, but to evaluate it all properly you do kinda need to read it all and check it's internally consistent12:03
rogpeppefwereade: ok, i'll review it as if it were a doc comment12:03
fwereaderogpeppe, last time I tried a braindump of this nature doc/draft was suggested as an appropriate landing point12:03
rogpeppefwereade: well, if others differ, i'm happy to defer to them. this was just my initial reaction when going through the doc.12:04
fwereaderogpeppe, cool -- I think there's a lot of value to having that information all collected in one place12:06
rogpeppefwereade: it does seem very implementation-specific to me, something that would live happily in state, as you don't need to know any of those details externally to state.12:06
rogpeppefwereade: hence my suggestion for putting it in state as a doc comment12:07
rogpeppefwereade: or is there more of a cross-package nature to the doc that i'm not seeing?12:07
fwereaderogpeppe, it's not cross-package, and it's definitely all about state, but it's a complex-enough topic that I think distributing the docs across comments for various methods on various types will be counterproductive12:09
rogpeppefwereade: that's not what i'm suggesting12:09
rogpeppefwereade: i'm suggesting that we could have it as a single comment/.12:09
rogpeppefwereade: maybe even in its own file, doc.go12:09
fwereaderogpeppe, I think that's a place for API docs, which are not quite the same thing12:11
fwereaderogpeppe, but I may be wrong12:11
rogpeppefwereade: we have many comments about the internal implementation too; they're not visible with godoc, but they're still useful when working on state.12:11
rogpeppefwereade: this doc seems like it comes into a similar category12:12
fwereaderogpeppe, perhaps so -- I'm basically treating doc/draft as a sort of holding area for things that I feel ought to be written down12:15
fwereaderogpeppe, writing that stuff down was important for coming to understand it all better myself12:16
rogpeppefwereade: fair enough. i hadn't realised that - to my shame this is the first of your drafts i've looked at, and i was presuming it was all higher level stuff.12:16
fwereaderogpeppe, no worries12:16
fwereaderogpeppe, the original plan for the first stuff that went in there was "give the technical writer something to start with"12:17
rogpeppearam, TheMue, dimitern, jam, mgz: any chance of a second look at this CL? https://codereview.appspot.com/709605412:28
dimiternrogpeppe: looking12:28
rogpeppedimitern: ta!12:28
jamrogpeppe: I'm *really* not a fan of global state like that mutex. Is it possible to put it struct local?12:28
jam(*c = *nc) is a bit scary, but I sort of understand why.12:29
rogpeppejam: i agree in principle, but in this case, i really want to keep the struct with all-exported fields. also, i want it to work even if two agents are using different config structs that point to the same datadir/entity12:30
rogpeppejam: i *could* have a global mutex per dataDir/entity, but that would be overkill12:30
rogpeppejam: (and i'd still need a global mutex to guard access to that!)12:31
dimiternrogpeppe: LGTM12:31
rogpeppedimitern: thanks12:31
dimiternfwereade: +1 on https://codereview.appspot.com/7094052/12:38
fwereadedimitern, tyvm12:39
rogpeppefwereade, niemeyer: i think we need a collection in the state that holds entity-name/password pairs (as distinct from mgo user/password pairs, currently used, which will eventually only be used by the API servers). i thought about calling it "users". how does that seem to you?12:53
niemeyerrogpeppe: Hard to tell without background12:54
rogpeppeniemeyer: ok12:54
fwereaderogpeppe, seems to echo my own ill-formed thoughts but I don't think I can justify it to myself yet, would like to hear more12:54
rogpeppeniemeyer: so... eventually, when everything possible is going through the API, we don't want a random agent to be able to connect directly to the state12:54
niemeyerrogpeppe: Indeed12:55
rogpeppeniemeyer: so our current approach of storing mongo user/passwords won't fly, so we need to store the passwords somewhere else.12:55
rogpeppeniemeyer: and inside the state seems like the most reasonable (only possible?) approach12:55
niemeyerrogpeppe: Ideally we should never store passwords themselves12:55
rogpeppeniemeyer: sure, we'll store them hashed12:56
niemeyerrogpeppe: s/them hashed/their hashes/ yes12:56
rogpeppeniemeyer: i'm thinking that the current SetPassword will end up renamed to (perhaps) SetMongoPassword12:56
rogpeppeniemeyer: and that SetPassword will operate on the mongo collection12:57
rogpeppeniemeyer: then when the provisioner want to allocate a new machine that's allocated the APIServerJob job, it will additionally add a password for the new agent using SetMongoPassword12:58
rogpeppeniemeyer: so that the new machine agent can access the state directly.12:59
niemeyerrogpeppe: Not entirely sure about that12:59
niemeyerrogpeppe: Who would use unit.SetMongoPassword?13:00
rogpeppeniemeyer: the provisioner13:00
rogpeppeniemeyer: (only)13:00
niemeyerrogpeppe: Why?13:00
niemeyerrogpeppe: The unit should never connect to the state13:00
niemeyerrogpeppe: To mongodb, that is13:00
rogpeppeniemeyer: i thought we had agreement that the API server would be just another job that the machine agent could run13:00
rogpeppeniemeyer: (and i've been proceeding on the basis of that understanding)13:02
niemeyerrogpeppe: That seems completely unrelated to what I just said13:02
rogpeppeniemeyer: ah, sorry, i'd missed the "unit" bit13:03
rogpeppeniemeyer: yes, we wouldn't have that method13:03
rogpeppeniemeyer: just Machine.SetMongoPassword13:03
rogpeppeniemeyer: although we'd leave Unit.SetMongoPassword around for the time being, until the unit no longer needs to connect directly to the state.13:05
niemeyerrogpeppe: +113:10
rogpeppeniemeyer: cool, thanks13:10
* fwereade -> lunch13:13
rogpeppefwereade: enjoy!13:14
rogpeppejam: are you ok with this CL after my explanation? i won't submit unless you are. https://codereview.appspot.com/709605413:26
hazmatare the ostack and ec2 public containers are global across accounts?13:31
rogpeppehazmat: yes13:32
rogpeppehazmat: well, the ec2 public containers are13:32
rogpeppehazmat: (that's kinda the point)13:32
hazmatwe're looking for a fallback location to publish cloud image streams/data, istm that those locations might be reasonable choices then if their global to the provider in question.13:32
dimiternrogpeppe: but the OS ones seem account-dependant13:33
jamrogpeppe: how about a comment that we use a global because what we are actually locking is the filesystem paths. Though arguably you need an on-disk lock for that.13:33
dimiternrogpeppe: I can have the same container as another user and using ACLs both than be made public, with different URLs13:33
jamrogpeppe: otherwise, I'm certainly not -1 on it. So you can land it.13:33
rogpeppejam: yeah, i'm assuming that we only care about concurrent use within a given agent, which means a lock inside the agent is sufficient13:34
rogpeppedimitern: hmm, how's the juju public-bucket stuff done then?13:34
rogpeppedimitern: ('cos there we really want to avoid uploading tools every time)13:35
rogpeppejam: but i'll add a comment. thanks for the feedback.13:35
dimiternrogpeppe: well, wallyworld__ or mgz can tell you more details, but what we agreed upon is to have a public container (with ACLs) per region for the tools in OS13:36
dimiternrogpeppe: and specify it's full URL in environments.yaml13:37
rogpeppedimitern: that seems like what i'd expected. global across acounts?13:37
rogpeppedimitern: ah, so rather than specifying a bucket name, we specify the URL.13:37
rogpeppedimitern: that seems fine too.13:37
dimiternrogpeppe: depends on how you define "global" - definitely they're not in a single namespace13:37
mgzrogpeppe: the goal will be what we talked about in denmark, with a tool to mirror the tools from ec2 to your openstack deployment13:38
mgzbut we'll also support per-tenant tools, and that's what's going to work first.13:38
rogpeppedimitern: it still sounds like a reasonable place for hazmat's need, i'd guess though.13:38
rogpeppemgz: sounds good13:39
hazmatdimitern, its not a single namespace, but it is a url/container that can be reference'd across accounts for tool access which would suffice for also storing/publishing the image stream/data.13:40
dimiternrogpeppe: in this sense "global", as in one for all environments running on canonistack region lcy01, yes they are global, but still a specific user/tenant account creates it13:40
rogpeppedimitern: true of ec2 too, although the bucket names themselves are global too.13:41
dimiternhazmat: yeah, provided we have easy means (tools) to update and sync the tools in the global location (per region and per OS installation)13:41
rogpeppeon ec2, that is13:41
dimiternwhat I'm doing now is making juju bootstrap work (hopefully :) ) on canonistack with goose - using this global container url13:42
dimiternmgz: is there a need for both public-bucket and public-bucket-url in the config?13:44
mgzdimitern: public-bucket is not strictly needed, but we'd hardcode a string for it otherwise13:51
dimiternmgz: not only it's not needed, I don't see it used - it's just confusing13:53
dimiternmgz: maybe at lest a TODO or something would be nice13:53
mgzwe'll use it for the uploading of tools13:53
* rogpeppe goes for some lunch13:53
dimiternmgz: isn't that what the control bucket is used for?13:58
dimiternmgz: I see it now - in provider.SetConfig() - but I'm confused - why do we need 2 buckets now?14:02
fwereadedimitern, because we generally want people not to have to build and/or upload their own tools: they can get theirs from the public bucket14:19
fwereadedimitern, but we also sometimes want to deploy our own tools, eg with juju bootstrap --upload-tools14:20
fwereadedimitern, and so we need to use our own private bucket for those14:20
fwereadedimitern, the control bucket also holds the charm bundles IIRC14:21
dimiternfwereade: so the control bucket (private one) always has either the tools from the public bucket or the ones we upload with --upload-tools specifically14:22
fwereadedimitern, I can't remember if we copy public tools into the private bucket; rogpeppe would probably know14:23
dimiternfwereade: and if we don't we just copy the tools from the public bucket to the control bucket on bootstrap?14:23
=== TheMue_ is now known as TheMue
dimiternfwereade: I see14:23
fwereadedimitern, I *think* so, let me check something14:23
fwereadedimitern, environs/cloudinit/cloudinit.go:10514:25
fwereade        fmt.Sprintf("wget --no-verbose -O - %s | tar xz -C $bin", shquote(cfg.Tools.URL)),14:25
fwereadedimitern, hm sorry that's not so helpful14:25
fwereadedimitern, rogpeppe will remember the details of how they're distributed14:26
dimiternfwereade: I'm looking at cloudinit.go - so this happens after or during bootstrap?14:29
fwereadedimitern, ok, look quickly at environs/ec2/ec2.go:23414:31
fwereade    if uploadTools {14:32
fwereadedimitern, tools comes from either PutTools or FindTools14:32
dimiternfwereade: sorry, my router went berserk again14:37
fwereadedimitern, np, so did mine14:37
fwereadeI didn't actually say much, what was the last thing you saw?14:38
dimiternfwereade: I'm looking at cloudinit.go - so this happens after or during bootstrap?14:38
fwereadedimitern, the cloudinit file is used to bootstrap each instance, whatever it will end up running, and one of the things you see it doing there14:39
fwereadedimitern, is wgetting the tools from the *Tools that was passed in14:39
dimiternfwereade: but how does it get called?14:39
fwereadedimitern, that *Tools comes from environs/ec2/ec2.go:234...14:39
dimiternfwereade: ah, now I see14:40
fwereadedimitern, where it does either PutTools (to upload) or FindTools(to pick the right sort); when FindTools is subsequently used, it check for PutTollsed tools before falling back to the public bucket14:41
fwereadedimitern, but it doesn't do any copying into the control bucket that I can see except when it's uploading the local tools14:41
dimiternfwereade: yeah, that's it then14:42
=== slank_away is now known as slank
rogpeppefwereade: yup, that's right14:54
rogpeppemechanical rename CL; trivial if you agree with the rename. https://codereview.appspot.com/709805316:08
rogpeppefwereade, TheMue, aram, niemeyer: ^16:09
TheMuerogpeppe: *click*16:09
rogpeppeniemeyer, fwereade: i was thinking that, rather than have a separate user/password collection, the best place to store the passwords would be in the entity docs themselves. does that make sense to you?16:11
niemeyerrogpeppe: I still feel it's slightly awkward to expose Mongo at that level of the API, but this feels like a bike-sheddy discussion that won't drive us anywhere. +1 on moving forward with this and reducing impact later.16:11
rogpeppeniemeyer: we could call it CoreDBPassword or something16:12
niemeyerrogpeppe: It's fine as it is for now.. it'll be more useful to get rid of the method where possible ASAP16:12
rogpeppeniemeyer: yeah16:13
niemeyerrogpeppe: Regarding storing the password in the entity doc, sounds reasonable in principle (without looking at details)16:13
rogpeppeniemeyer: the only issue that i can see is that the state open process will want a way to map from entity name to entity, so it can check the password16:14
rogpeppeniemeyer: but if you're ok with that, i think there's a clear path16:14
niemeyer"state open process"?16:14
rogpeppeniemeyer: sorry, state.Open16:15
niemeyerrogpeppe: I think it's fine16:15
TheMuerogpeppe: You'vve got  a review16:15
niemeyerrogpeppe: We'll eventually need that anyway to be able to constrain access on a per-entity basis16:16
rogpeppeniemeyer: i'm thinking func (st *State) entity(entityName string) (entity, error); type entity interface {SetPassword(pass string) error; HashedPassword() string; possible other methods}16:16
rogpeppeniemeyer: perhaps Entity instead of entity16:16
niemeyerrogpeppe: Why do we need that?16:16
rogpeppeniemeyer: that's a way to map from entity name to entity16:17
niemeyerrogpeppe: I now perceive I don't understand what you meant16:17
rogpeppeniemeyer: inside state.Open, we need a way to find the hashed password for an entity given an entity name16:18
niemeyerrogpeppe: and why is that non-trivial?16:18
rogpeppeniemeyer: i guess state.Open could dive directly into the entity doc16:19
rogpeppeniemeyer: perhaps that would be better - is that what you're thinking?16:19
niemeyerrogpeppe: Yeah, feels like simple switch statement16:20
rogpeppeniemeyer: i was thinking of a simple switch statement actually: switch entityKind {case "unit": return st.Unit(name); case "machine": return st.Machine(name) }16:21
rogpeppeniemeyer: and Unit and Machine will already implement the methods in the entity interface16:22
rogpeppeniemeyer: so there's no need to spread any doc-specific code outside of the entities themselves16:22
niemeyerrogpeppe: The only difference is the collection name.. no need to even load the entities16:23
niemeyerrogpeppe: But whatever.. it's fine either way16:23
niemeyerrogpeppe: Your implementation.. I agree with the idea16:23
rogpeppeniemeyer: ok, i'll go with this for the time being. i'm not sure if the performance difference would be significant.16:25
fwereadedimitern, or not? ;p16:26
rogpeppeTheMue: thanks!16:26
dimiterni just got home and tried and it seems back on16:26
TheMuerogpeppe: yw16:26
dimiternfwereade: don't send it if you haven't, 10x16:26
fwereadedimitern, already sent :)16:26
dimiternfwereade: np, I'll reply16:27
fwereaderogpeppe, https://codereview.appspot.com/7098053/ LGTM16:54
rogpeppefwereade: tyvm16:54
fwereaderogpeppe, can I redraw your attention to https://codereview.appspot.com/7092044/ and https://codereview.appspot.com/7094045/ in particular please? ;)16:54
rogpeppefwereade: looking now, thanks for the reminder16:55
fwereaderogpeppe, there are more, if you're of a mind, but I know you have to maintain balance ;)16:55
rogpeppefwereade: i think i'll do just those two for today if that's ok. perhaps i'll have a review morning tomorrow.16:56
fwereaderogpeppe, sgtm16:56
rogpeppefwereade: ping17:13
fwereaderogpeppe, pong17:13
rogpeppefwereade: i'm looking at this expression in your CL: ru.st.units.Find(selSubordinate).Select(lifeFields)17:13
fwereaderogpeppe, oh yes17:13
rogpeppefwereade: can that ever result in more than one result, and if not, why not?17:13
fwereaderogpeppe, I believe not, because of the check in the unit addition ops17:14
fwereaderogpeppe, (well, it can, but only if you use AUST)17:14
* rogpeppe has forgotten what AUST stands for17:15
fwereaderogpeppe, (the unit add op asserts that the principal has no subordinate unit with a name starting with "svcname/")17:15
fwereaderogpeppe, AddUnitSubordinateTo17:15
rogpeppefwereade: of course, ta17:15
rogpeppefwereade: hmm17:15
rogpeppefwereade: can't the unit have several existing subordinate units?17:16
fwereaderogpeppe, but only one of each service17:16
rogpeppefwereade: why does that make a difference?17:17
rogpeppefwereade: is the above Find selecting only subordinate units from one service?17:17
fwereaderogpeppe, selSubordinate := D{{"service", serviceName}, {"principal", unit Name}}17:17
fwereaderogpeppe, (sorry line break)17:18
rogpeppefwereade: ok so (pardon my lack of understanding here) what's stopping RelatedEndpoints returning more than one end point?17:20
fwereaderogpeppe, the fact that we can only create relations with 1 or 2 endpoints17:20
rogpeppefwereade: ah, ok.17:20
rogpeppefwereade: i guess i'm trying to see the code path that happens when the principal unit has more than one dying subordinate unit17:21
fwereaderogpeppe, only one subordinate unit is ever relevant for a scope entry17:21
fwereaderogpeppe, the unit of the other service in the relation17:21
rogpeppefwereade: i think this comes down to my fundamental difficulty in grasping exactly what a RelationUnit is :-)17:22
fwereaderogpeppe, it controls a single unit's effects on a particular relation17:23
fwereaderogpeppe, in fact, better17:23
fwereaderogpeppe, it's the interface a relation exposes to a unit (roughly, with caveats and handwaving)17:23
rogpeppefwereade: and a relation is between two services only?17:24
fwereaderogpeppe, two or one17:24
rogpeppefwereade: yea17:25
fwereaderogpeppe, but a subordinate relation will only be between 217:25
rogpeppefwereade: ok, i'm starting to get it better now, thanks17:25
fwereaderogpeppe, this may, one day, change, but I don't think it's yet on the horizon17:25
fwereaderogpeppe, cool17:26
rogpeppefwereade: you've got a pair of reviews17:37
niemeyermramm: Is there a consistency meeting today?17:37
dimiternniemeyer: the weekly (double) meeting is tomorrow as usual, if you refer to this one17:40
niemeyermramm: Nope, it's a different one17:41
niemeyerrobbiew: Meeting today?17:41
robbiewniemeyer: nah...client sprint this week17:41
niemeyerrobbiew: Ah, that's why I thought the Austin sprint started on the 13th17:41
rogpeppefairly simple CL: https://codereview.appspot.com/710505418:31
rogpeppeand that's me for the day. see y'all tomorrow!18:31
hazmatniemeyer, will you be @ austin?18:31
niemeyerhazmat: Nope18:49
niemeyerrogpeppe: Have a good one18:49
hazmatniemeyer, bummer, but understood18:50
niemeyerhazmat: Cesarean and all.. wouldn't feel right18:50
hazmatniemeyer, ouch.18:51

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