| davecheney | fwereade: thank you for your review | 06:09 |
|---|---|---|
| fwereade | davecheney, np, the tweaks should be straightforward :) | 06:10 |
| davecheney | fwereade: already done | 06:10 |
| fwereade | davecheney, cool | 06:11 |
| davecheney | fwereade: could I press you to expand on this statement | 06:19 |
| davecheney | FWIW, I maintain that user-config is not the same thing as internal-config, and | 06:19 |
| davecheney | trying to pretend that they are causes us nothing but pain. Not sure that topic | 06:19 |
| davecheney | is really open for discussion, though... | 06:19 |
| davecheney | i too feel the sting of too many battles over configuration | 06:19 |
| fwereade | davecheney, I was trying to argue for it when we were originally having the config, and lost... but I'm still not quite sure *why* I lost, and so I can't figure out whether this situation qualifies as a reason to reopen the discussion (and indeed I'm not really sure whether I even want to...) | 06:21 |
| davecheney | fwereade: so this is a diffrence between the environments configuration (passwords and shit that the agents need) | 06:21 |
| davecheney | vs the pure minimum of config as a connection string | 06:22 |
| fwereade | davecheney, I hadn't looked at it exactly that way -- in my eyes the problem is simply that we're trying to make a single parser do different things in different contexts | 06:25 |
| davecheney | fwereade: well, IMO the wrinkle is not in the parser | 06:27 |
| davecheney | but the way BootstrapConfig fucks with the config, then tries to parse it again | 06:28 |
| TheMue | morning | 06:31 |
| davecheney | hello | 06:31 |
| fwereade | davecheney, ISTM that the only reason we're messing around with the config is so that we can pretend that the two situations are the same | 06:31 |
| * davecheney nods | 06:31 | |
| fwereade | davecheney, and that that is the cause of the ugliness you reference | 06:31 |
| fwereade | davecheney, so yeah, not exactly the parser itself, but a decision made in the parser's intellectual scope, if you like | 06:32 |
| fwereade | TheMue, heyhey | 06:32 |
| TheMue | fwereade: heya, just reading your review | 06:32 |
| fwereade | TheMue, probably all these things were covered in a prereq, but I didn't see that I'm afraid | 06:32 |
| TheMue | fwereade: no, they are not | 06:33 |
| TheMue | fwereade: one simply is a typo (c'n'p error) - the "dummy" in the ec2 config. i'll change it | 06:34 |
| TheMue | fwereade: the "default" is still in discussion and may be changed later. but i still prefer the word "default" so that one explicitely state in the config, that he wants the default behavior instead by leaving it empty | 06:36 |
| TheMue | fwereade: could you please describe your question regarding the change of the mode more? do you mean a change at runtime? | 06:37 |
| fwereade | TheMue, feels wrong to me to have 2 names for the same state, but mileages may reasonably vary I guess | 06:37 |
| fwereade | TheMue, yeah | 06:37 |
| fwereade | TheMue, there's handling somewhere for things like attempts to change the env type, we can probably just do something similar there | 06:39 |
| TheMue | fwereade: we don't have two names, we only have, if somebody writes nothing, a default mode. but how would you otherwise explicit define that you want the default mode? | 06:39 |
| fwereade | TheMue, honestly I don't think this should be user-configurable at all | 06:39 |
| fwereade | TheMue, it feels like we're repeating the placement mistake | 06:39 |
| TheMue | fwereade: environments like ec2 have different modes, later maybe also a third one (one group per service). how to control that? | 06:40 |
| fwereade | TheMue, ask the environ what it prefers? | 06:41 |
| TheMue | fwereade: the environment prefers nothing, it depends on your cloud size and services | 06:41 |
| fwereade | TheMue, in that case, surely, it shouldn't have a default value: it's is an important decision that we should require an explicit value for | 06:43 |
| fwereade | TheMue, but... well, look, we'll be dealing with a whole bunch of environments soon enough | 06:43 |
| fwereade | TheMue, some of them have no concept of security groups in the first place, eg MAAS (as far as I know, not very up to date with progress) | 06:44 |
| fwereade | TheMue, for those envs we will actually have to implement a local firewaller in every machine agent anyway, I think | 06:45 |
| TheMue | fwereade: yes, that's why niemeyer wanted a default, because you today can't tell if instance and global are ok for each environment. default is start, more modes to come. | 06:45 |
| TheMue | fwereade: exactly | 06:45 |
| TheMue | fwereade: but more important is your thought about changing it at runtime | 06:46 |
| fwereade | TheMue, ok, if we implement local per-machine firewalling with iptables or something | 06:46 |
| fwereade | TheMue, why would we need "global" or "instance" modes at all? | 06:47 |
| fwereade | <fwereade> TheMue, ok, if we implement local per-machine firewalling with iptables or something | 06:47 |
| fwereade | TheMue, why would we need "global" or "instance" modes at all? | 06:47 |
| fwereade | TheMue, envs like MAAS will require that we add local firewalling, I think | 06:48 |
| fwereade | TheMue_ ^^ | 06:48 |
| TheMue_ | fwereade: yes, but other envs maybe not | 06:48 |
| fwereade | TheMue_, if we have local firewalling implemented for just one env we can just do that everywhere | 06:49 |
| TheMue_ | fwereade: niemeyer wanted to keep it more abstract, so we later can support multiple envs with the same configuration machanism | 06:49 |
| fwereade | TheMue_, and just have a thin layer of the global handling in the environments that need it on top of that | 06:49 |
| TheMue_ | fwereade: you now change the whole firewalling concept | 06:49 |
| TheMue_ | fwereade: please let's do it step by step | 06:49 |
| fwereade | TheMue_, in that situation global-firewalling is just Wrong | 06:50 |
| === TheMue_ is now known as TheMue | ||
| fwereade | TheMue_, how so? AIUI I merely bring up what everyone has always known had to be done from the beginning | 06:50 |
| fwereade | TheMue, I'm not demanding specific action :) | 06:50 |
| fwereade | TheMue, but I am worried that we're adding a piece of totally transitory dev-relevant-only config | 06:51 |
| fwereade | TheMue, that we will end up releasing and have to go through all the tediousness of deprecating | 06:51 |
| TheMue | fwereade: what's wrong with security groups for the ec2 env? | 06:51 |
| TheMue | fwereade: especially, if the user configures abstract modes like instace or global, the change from sec groups to iptables is transparent for the user | 06:53 |
| fwereade | TheMue, they scale like shit, and ISTM that the global firewaller provides so flimsy a veil of kinda-security that , while it may allow us to scale, will not be used in any serious deployments | 06:53 |
| fwereade | TheMue, what is the purpose of the global firewaller if not to paper over the security group issues? | 06:53 |
| TheMue | fwereade: using them today lets us sart while a change to a different implementation later is transparent for the user. so we ca release early with today demands but still have a comfortable solution for the future | 06:54 |
| fwereade | TheMue, today's demands are "match python"; I though python had no global firewaller | 06:55 |
| fwereade | TheMue, the most transaprent thing is to do the best we can for the user given our capabilities | 06:55 |
| fwereade | TheMue, if we want to target, right, now, users who want either scalability or security, but not both, then I guess we have no choice | 06:56 |
| Guest2629 | TheMue, fwereade, davecheney: mornin'! | 06:56 |
| TheMue | fwereade: afaik it's just a simple temporary solution which later is easy to change. how fast could you set up iptables inclusive testing? | 06:56 |
| TheMue | Guest2629: morning | 06:56 |
| === Guest2629 is now known as rogpeppe | ||
| fwereade | TheMue, but if we're asking them to make a choice like *that* I think we should be upfront about it and have no default | 06:57 |
| fwereade | rogpeppe, heyhey | 06:57 |
| TheMue | fwereade: could you add this with your reasons to the review so that we could discuss it with niemeyer later. i'm not good as a man in the middle. | 06:58 |
| fwereade | TheMue, clearly the decision to write the global firewaller has already been made, but when I review the code I lack the context behind the decisions and need to ask questions | 06:58 |
| TheMue | fwereade: yes, for sure | 06:59 |
| fwereade | TheMue, I will expend my review, thanks | 06:59 |
| TheMue | fwereade: but i'm not very good in repeating your questions later to niemeyer. it's better when you ask him too | 06:59 |
| fwereade | er extend | 06:59 |
| fwereade | TheMue, absolutely, np :) | 07:00 |
| TheMue | fwereade: as long as this topic is in move changes are more simple than later | 07:00 |
| rogpeppe | davecheney: ping | 07:01 |
| davecheney | rogpeppe: ack | 07:01 |
| rogpeppe | davecheney: i see your issue with my admin-secret fix, but i think that moving the admin-secret check earlier in the Bootstrap function would fix that. | 07:02 |
| davecheney | rogpeppe: fair call | 07:02 |
| davecheney | what you go, ie the blowup at cloud init level | 07:02 |
| rogpeppe | davecheney: admin-secret can't be a required field in the config, unfortunately AFAICS | 07:02 |
| davecheney | was where i started with | 07:02 |
| davecheney | i got most of the way with making admin-secret rquired | 07:02 |
| davecheney | but BoostrapConfig screwed me | 07:02 |
| rogpeppe | davecheney: the fundamental issue is that we don't want to push admin-secret into the state. | 07:03 |
| davecheney | rogpeppe: what about just overwriting the secret with 'your secret isn't here' | 07:03 |
| davecheney | config.New would be happy | 07:03 |
| davecheney | and we _know_ we're never putting the real value into the state | 07:04 |
| rogpeppe | davecheney: i don't see how that's better than just not requiring the admin secret. | 07:04 |
| davecheney | rogpeppe: i would argue the opposite | 07:04 |
| davecheney | but not streniously | 07:04 |
| rogpeppe | davecheney: it's like we're saying, "yeah it's required, but only means something in some cases" | 07:06 |
| davecheney | rogpeppe: can't we leave it out of config/config | 07:06 |
| davecheney | and apply it at environs/ec2/config.go | 07:06 |
| davecheney | it is already in there | 07:06 |
| davecheney | but specfied as schema.Omit | 07:06 |
| rogpeppe | davecheney: no | 07:06 |
| rogpeppe | davecheney: because we need to be able to create an environment without admin-secret, i think | 07:07 |
| rogpeppe | davecheney: or... maybe that is a possibility, let me think | 07:08 |
| davecheney | rogpeppe: yeah, can't we do that just by changing environs/ec2/config.go ? | 07:08 |
| davecheney | rogpeppe: it would make admin-secret an environ specific value | 07:08 |
| davecheney | unknownattrs, or whatever | 07:08 |
| rogpeppe | davecheney: no, we do need to be able to create an environment without admin-secret | 07:08 |
| davecheney | rogpeppe: i don't understand that sentance | 07:09 |
| davecheney | an environment == ec2 ? | 07:09 |
| rogpeppe | davecheney: environs == environs.Environ | 07:09 |
| rogpeppe | s/environs/environment/ | 07:09 |
| davecheney | yeah, that is easy | 07:09 |
| davecheney | remove the admin-secret atom from environs/config/config.go | 07:10 |
| rogpeppe | davecheney: but can we then open an ec2 environment with that config? | 07:11 |
| davecheney | rogpeppe: depends if it is a valid ec2 config | 07:11 |
| rogpeppe | davecheney: i thought you were suggesting that the ec2 config required admin-secret | 07:12 |
| davecheney | rogpeppe: indeed i am | 07:12 |
| rogpeppe | davecheney: so when an agent opens the environment, it must make up an admin secret? | 07:12 |
| davecheney | rogpeppe: NFI | 07:13 |
| davecheney | i dont know how it works ont he agents | 07:13 |
| rogpeppe | davecheney: it works ok. agents don't need admin-secret | 07:13 |
| rogpeppe | davecheney: only the client has the admin secret | 07:14 |
| davecheney | yeah, they would use environs/config/config.go | 07:14 |
| davecheney | which only requires a generic config | 07:14 |
| davecheney | so removing admin-secret from e/c/config.go is a valid suggestion | 07:14 |
| rogpeppe | davecheney: they've still got to get it through environs/ec2/config.go,m no? | 07:14 |
| davecheney | rogpeppe: don't thye do that by getting the providor, then the provider can validate the config ? | 07:15 |
| rogpeppe | davecheney: i'm not sure i understand. where are you suggesting we make the check for admin-secret's presence? | 07:15 |
| davecheney | environs/ec2/config.go | 07:16 |
| davecheney | it is already there | 07:16 |
| davecheney | but is optional atm | 07:16 |
| rogpeppe | davecheney: so what happens when we don't have an admin secret? | 07:16 |
| davecheney | not a valid config | 07:16 |
| rogpeppe | davecheney: then how can an agent create an Environ? | 07:17 |
| davecheney | well, you got me there | 07:17 |
| davecheney | i guess they are screwed | 07:17 |
| davecheney | and we are back to sq one | 07:17 |
| rogpeppe | davecheney: that's the reason i decided that the best place to put the check was where admin-secret is actually needed - in Bootstrap | 07:17 |
| davecheney | rogpeppe: fair enough | 07:18 |
| davecheney | best of a bad situation | 07:18 |
| davecheney | oh | 07:18 |
| rogpeppe | davecheney: yeah. i'm very happy to entertain other possibilities, but i haven't seen a better one yet | 07:18 |
| davecheney | what about if admin secret in ec2 worked the same way as authorised-keys in e/c/config.go ? | 07:19 |
| davecheney | ie, if it were blank, they values are sourced from somewhere else | 07:19 |
| davecheney | (else == whereever the agents stash their secret value) | 07:19 |
| rogpeppe | davecheney: so you can't stash your secret in environments.yaml? | 07:19 |
| davecheney | rogpeppe: i believe authorised-keys has a fallback mech | 07:20 |
| davecheney | yaml first, disk second | 07:20 |
| rogpeppe | davecheney: yeah it does. | 07:20 |
| rogpeppe | davecheney: but... how does this help? | 07:20 |
| davecheney | does it solve the problem of the e/ec2/config.go being able to require admin-secret, but allow it to come from several locations | 07:20 |
| rogpeppe | davecheney: i think we've got a fundamental issue here - in some places in the system, we don't *have* an admin secret | 07:20 |
| davecheney | agreed | 07:21 |
| rogpeppe | davecheney: ... where it's coming from another location or not | 07:21 |
| davecheney | i think this it the point fwereade says he told us so | 07:21 |
| rogpeppe | davecheney: i agree with fwereade's point, but i don't mind this solution *too* much | 07:21 |
| davecheney | rogpeppe: althoght, it does bail out after writing the data to the s3 store | 07:22 |
| davecheney | which means you have to use juju destroy-environment before trying again | 07:22 |
| rogpeppe | davecheney: yeah, that's a bug | 07:23 |
| rogpeppe | davecheney: as it suggested earlier, the check should come further up | 07:23 |
| rogpeppe | s/it/i | 07:23 |
| rogpeppe | davecheney: i'll fix that | 07:24 |
| davecheney | sweet | 07:24 |
| davecheney | afk for a while | 07:24 |
| rogpeppe | davecheney: afk? | 07:24 |
| fwereade | rogpeppe, away from keyboard | 07:28 |
| rogpeppe | fwereade: thanks | 07:28 |
| TheMue | fwereade: thx for your notes. both sound very good to me. | 07:59 |
| fwereade | TheMue, cool, cheers :) | 07:59 |
| Aram | moin. | 08:32 |
| TheMue | Aram: moin moin | 08:33 |
| TheMue | *: Always the same question. *sigh* When having a chain of CLs which shall bei updated to trunk, then after merge only commit and push or also lbox propose of already submitted pre-requesites? | 08:37 |
| TheMue | rogpeppe, fwereade: any hint ^^? | 09:13 |
| fwereade | TheMue, I generally don't repropose unless there were conflicts | 09:13 |
| TheMue | fwereade: so only commit and push? i twice made it wrong in the beginning and had too much code in the reviews | 09:15 |
| fwereade | TheMue, it seems to work ok for me | 09:15 |
| fwereade | TheMue, I only get too much code when I forget a -req | 09:16 |
| TheMue | fwereade: thx, i'll make a note to keep it in mind next time. ;) | 09:16 |
| Aram | TheMue: no need to repropose before submitting. | 10:10 |
| Aram | just make sure you merge trunk. | 10:10 |
| Aram | so you merge the prereq | 10:10 |
| niemeyer | Morning jujuers! | 12:08 |
| fwereade | niemeyer, heyhey | 12:13 |
| niemeyer | fwereade: Heya | 12:13 |
| niemeyer | fwereade: Good weekend? | 12:13 |
| fwereade | niemeyer, very nice thanks -- saw cath's cousins and their new baby :) | 12:13 |
| niemeyer | fwereade: Oh, nice | 12:14 |
| fwereade | niemeyer, and also stacked up a few reviews which will, I hope, lead to interesting conversations if not necessarily immediate progress | 12:14 |
| niemeyer | fwereade: /me is all sensitive about "new babies" :-) | 12:14 |
| fwereade | niemeyer, he's about 4 months old and smiley and dribbly and cute | 12:15 |
| niemeyer | fwereade: LOL | 12:15 |
| TheMue | niemeyer: morning and thx for your comment | 12:22 |
| niemeyer | TheMue: Heya, np | 12:23 |
| * TheMue 's small baby - she is now 16 yrs old ;) - has her first archery tournament this afternoon. we'll all watch her. | 12:23 | |
| niemeyer | TheMue: Wow, very nice. Good luck there! | 12:27 |
| fss | niemeyer: morning :-) | 12:28 |
| niemeyer | fss: Heya | 12:35 |
| TheMue | niemeyer: thank you, I will tell her when she's back from school. just had to watch our older one leaving home with her driving teacher. one of the last lessons before driving test. | 12:36 |
| fwereade | late lunch, bbiab | 12:48 |
| niemeyer | fwereade: Enjoy | 12:49 |
| niemeyer | fwereade: https://codereview.appspot.com/6651060/ is waiting for you | 13:15 |
| fwereade | niemeyer, cheers | 13:38 |
| niemeyer | Aram: ping | 14:11 |
| fss | niemeyer: ping | 14:22 |
| niemeyer | fss: hi | 14:22 |
| fss | did you see that iamtest cl? | 14:23 |
| niemeyer | fss: Still churning CLs pushed over the holiday and/or weekend | 14:24 |
| fss | niemeyer: oh, right :-) please let me know if I can help with anything | 14:27 |
| niemeyer | fss: Cheers! | 14:31 |
| niemeyer | fwereade_: ping | 14:33 |
| fwereade_ | niemeyer, pong | 14:34 |
| niemeyer | fwereade_: Yo | 14:34 |
| niemeyer | fwereade_: Just started looking at relation-lifecycles | 14:34 |
| fwereade_ | niemeyer, oh yes | 14:35 |
| niemeyer | fwereade_: The N=100k indeed feels troublesome there | 14:35 |
| fwereade_ | niemeyer, does my wolly justification for an end-run around txn hold any water? | 14:36 |
| fwereade_ | s/wolly/wooly/ | 14:36 |
| niemeyer | fwereade_: I'm thinking too.. in principle it sounds doable | 14:36 |
| niemeyer | fwereade_: But even better would be to have these settings collected in a more distributed way | 14:37 |
| niemeyer | fwereade_: Even if we do RemoveAll, 100k is still a lot | 14:37 |
| fwereade_ | niemeyer, not really sure where it makes sense to distribute it to -- a CA that just does a bit of work every few seconds might do the trick I guess :) | 14:38 |
| niemeyer | fwereade_: Yeah, but that sounds worryingly hand-wavy | 14:39 |
| niemeyer | fwereade_: We've decided to leave settings around, and that seems to work well, but is there any real point where we can say settings for a unit leaving aren't relevant anymore? | 14:40 |
| fwereade_ | niemeyer, I don't really think we can at the unit level, can we? We could make subordinate relations be cleaned up incrementally by their own units | 14:41 |
| fwereade_ | niemeyer, but that doesn't help with the big ugly case | 14:41 |
| niemeyer | fwereade_: Right | 14:42 |
| fwereade_ | niemeyer, the CA case doesn't seem too bad to me though -- it's just one extra op to create a document with the relation's ID (or I guess just directly its scope key prefix) | 14:45 |
| fwereade_ | niemeyer, the CA then just removes a few matching docs at a time until it runs out, and then deletes the "droppings" doc | 14:45 |
| niemeyer | fwereade_: The extra doc for? | 14:46 |
| fwereade_ | niemeyer, or adds it into an existing doc, sorry, haven't considered tradeoffs here | 14:46 |
| niemeyer | fwereade_: Ah, I see | 14:47 |
| fwereade_ | niemeyer, brb phone | 14:47 |
| niemeyer | fwereade_: Cool, thinking meanwhile | 14:47 |
| niemeyer | fwereade_: Yeah, you're right.. the CA may be a good idea after all | 14:54 |
| fwereade_ | niemeyer, however I'd prefer not to switch focus to that just now | 14:55 |
| fwereade_ | niemeyer, do you think that an interim solution of either monster-transaction, or remove-all-settings-before-transaction, would be plausible? | 14:56 |
| niemeyer | fwereade_: Not greatly comfortably with either | 15:01 |
| * fwereade_ is crestfallen | 15:02 | |
| * niemeyer looks in the dictionary to see what fwereade_ is | 15:02 | |
| fwereade_ | niemeyer, how about deleting no settings, but creating a droppings doc for future use? | 15:03 |
| * niemeyer laughs at the "-- said of a horse." part of the explanation | 15:03 | |
| * fwereade_ doesn't know which dictionary niemeyer has | 15:04 | |
| niemeyer | fwereade_: That was from gcide | 15:09 |
| fwereade_ | niemeyer, ah nice :) | 15:10 |
| niemeyer | fwereade_: Sounds good regarding injecting doc into cleanups collection | 15:10 |
| fwereade_ | niemeyer, great | 15:11 |
| fwereade_ | niemeyer, and that's a nicer name than droppings | 15:11 |
| niemeyer | fwereade_: {Id: bson.ObjectId, Type: "settings", Prefix: "r#..."} | 15:12 |
| fwereade_ | niemeyer, LGTM | 15:12 |
| niemeyer | fwereade_: /Type/Kind/ perhaps | 15:12 |
| fwereade_ | niemeyer, +1 | 15:12 |
| niemeyer | fwereade_: We'll need the CA soon enough anyway | 15:12 |
| niemeyer | fwereade_: To recover lost transactions | 15:12 |
| fwereade_ | niemeyer, indeed | 15:13 |
| niemeyer | I'll step out for lunch.. back in a bit to continue on reviews | 15:14 |
| fwereade_ | wrtp, Aram, niemeyer: is http://paste.ubuntu.com/1281389/ expected/familiar? just merged... | 16:24 |
| wrtp | fwereade_: i haven't seen that before | 16:25 |
| wrtp | fwereade_: ISTM that's probably a consequence of recent fw changes, renaming "default" to "" | 16:25 |
| fwereade_ | wrtp, yeah, I guess we will see a fix tomorrow | 16:27 |
| niemeyer | I guess no cloud consistency call today.. | 16:31 |
| niemeyer | fwereade_: Can you paste the link again please? | 16:31 |
| fwereade_ | niemeyer, http://paste.ubuntu.com/1281389/ | 16:31 |
| niemeyer | fwereade_: Cheers | 16:31 |
| niemeyer | fwereade_: I have a try at fixing it quickly | 16:32 |
| niemeyer | So we don't stick with a broken trunk | 16:32 |
| niemeyer | robbiew: Cloud consistency call today? | 16:35 |
| robbiew | niemeyer: no idea...I know I won't be attending (at ODS) | 16:35 |
| robbiew | niemeyer: I would say "no" | 16:36 |
| robbiew | ...as I don't know who will be around to attend | 16:36 |
| niemeyer | robbiew: Cheers | 16:36 |
| robbiew | ;) | 16:36 |
| wrtp | i'm off for the day. see y'all tomorrow. | 17:21 |
| niemeyer | wrtp: Enjoy the evening | 17:28 |
| niemeyer | fwereade: https://codereview.appspot.com/6699044 .. nothing exciting, luckily | 17:28 |
| === andrewsmedina is now known as almanegra | ||
| fwereade_ | niemeyer, ping | 20:15 |
| fwereade_ | niemeyer, re service-lifecycles EnterScope txns -- I suspect the logic *is* faulty, but the mistake is not, I think, in the inability of a unit to re-enter a scope -- I think that is a feature | 20:17 |
| fwereade_ | niemeyer, thoughts? | 20:17 |
| niemeyer | fwereade_: Yo | 20:21 |
| fwereade_ | niemeyer, heyhey | 20:21 |
| niemeyer | fwereade_: In principle I don't see a great reason to allow it, but at the same time it feels bad to have faulty logic that doesn't really bring any benefit and misbehaves in such cases | 20:22 |
| fwereade_ | niemeyer, to expand: when a unit leaves the scope, it has run the relation-broken hook and represented to the charm that its participation in the relation is entirely done | 20:22 |
| niemeyer | fwereade_: Sure, but in theory it could happily re-enter the scope by reporting to the charm that it's entering again | 20:23 |
| fwereade | niemeyer, I am 100% with you on the faulty logic, I will rework and explain nicely, unless you feel there is something deeply wrong with the approach -- I think that it is possible to determine the various situations cleanly | 20:24 |
| fwereade | niemeyer, which feeds into ErrScopeDying | 20:24 |
| fwereade | niemeyer, which should maybe be ErrScopeClosed -- indicating that either the unit has already left and can't come back, or just that the scope is not open to new members... | 20:25 |
| fwereade | niemeyer, ...but in either case, the correct response for the uniter is to ignore the error and all further references to that relation | 20:26 |
| niemeyer | fwereade: Is there anything that misbehaves today if we enter the scope again, as far as the the state/watchers/etc are concerned? | 20:26 |
| fwereade | niemeyer, I don't think so, no | 20:27 |
| niemeyer | fwereade: So I don't see yet the motivation to be actively preventing the unit from entering the scope. It feels like a property we can easily explore for good reasons in the future, and don't have to think much right now | 20:28 |
| fwereade | niemeyer, the intent is that a unit "re-entering" a scope should basically do nothing except possibly update the settings if the private address has changed | 20:29 |
| fwereade | niemeyer, that's from the API perspective | 20:30 |
| niemeyer | fwereade: Yep, sounds fine | 20:30 |
| niemeyer | fwereade: I'm talking about leaving and entering, though | 20:30 |
| niemeyer | fwereade: I don't see a reason to actively disallow it | 20:31 |
| fwereade_ | niemeyer, gaah, sorry | 20:31 |
| fwereade_ | niemeyer, I saw/said: | 20:31 |
| fwereade_ | <niemeyer> fwereade: Yep, sounds fine | 20:31 |
| fwereade_ | <fwereade> niemeyer, from the model perspective I think it is sensible to make this part of the model agree with the part which thinks that relation-broken is the dividing line between "in the relation" and "left, never ever coming back" | 20:31 |
| fwereade_ | niemeyer, I would favour consistency for the time being and consider experimentation later | 20:33 |
| niemeyer | fwereade> niemeyer, that's from the API perspective | 20:33 |
| niemeyer | <niemeyer> fwereade: Yep, sounds fine | 20:33 |
| niemeyer | <niemeyer> fwereade: I'm talking about leaving and entering, though | 20:33 |
| niemeyer | <niemeyer> fwereade: I don't see a reason to actively disallow it | 20:33 |
| niemeyer | fwereade_: I don't see the reason to building onto the model that "left, never ever coming back" | 20:33 |
| fwereade_ | niemeyer, I understand that to be the meaning of the relation-broken hook | 20:34 |
| fwereade_ | niemeyer, I had a feeling we did state somewhere that it would be called once per relation and it would be the last thing called | 20:34 |
| fwereade_ | niemeyer, if that is the case (er, I'll see if I can find anywhere...) then I think it's best to be consistent | 20:35 |
| niemeyer | fwereade_: We're getting into shady areas | 20:36 |
| niemeyer | fwereade_: We never discussed what happens when you start a unit in a different machine, for example | 20:36 |
| niemeyer | fwereade_: Do we Leave and then Join from the other machine? Etc | 20:36 |
| niemeyer | fwereade_: I'm not suggesting we should specify any of that right now, though | 20:36 |
| niemeyer | fwereade_: I'm just suggesting we don't start hardcoding unnecessary behavior that closes doors we haven't talked about yet | 20:37 |
| fwereade_ | niemeyer, I shall meditate upon this :) | 20:38 |
| niemeyer | fwereade_: Hehe :) | 20:38 |
| fwereade_ | niemeyer, hm, actually, on https://juju.ubuntu.com/docs/charm.html it says "Runs when a relation which had at least one other relation hook run for it (successfully or not) is now unavailable" | 20:39 |
| fwereade_ | niemeyer, that is not really a good description IMO but it does if anythig carry connotations of potentially being rerunnable | 20:39 |
| niemeyer | fwereade_: Overall, the lifecycle branches look like going in a pretty good direction.. the leave scope one has a few things we'll have to discuss too to make sure we understand what's up, but it's all getting together nicely | 20:39 |
| fwereade_ | niemeyer, yeah, I thought there'd probably be a bit of discussion for each of them | 20:40 |
| fwereade_ | niemeyer, the one that sits on top of them all does make me happy, though | 20:40 |
| niemeyer | fwereade_: It looks lke surprisingly small amount of logic, thankfully | 20:40 |
| fwereade_ | niemeyer, yeah, it's not too bad | 20:41 |
| fwereade_ | niemeyer, there may be a simplification waiting to get out but I haven't got round to implementing it against that tree yet so it could yet surprise me | 20:42 |
| niemeyer | fwereade_: Cool | 20:43 |
| niemeyer | fwereade_: I'll step out to do some end-of-afternoon errands.. back later | 20:44 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!