| TheMue | morning | 07:31 |
|---|---|---|
| fwereade__ | TheMue, heyhey | 07:39 |
| TheMue | fwereade__: hello | 07:39 |
| fwereade__ | TheMue, just in case you have perspective on this: ISTM that there is nothing preventing a charm from publishing multiple relations with the same name, so long as they have different roles... do you know if this is intentional? | 07:40 |
| TheMue | fwereade__: sorry, dunno. net yet went deeper into relations constraints | 07:41 |
| fwereade__ | TheMue, no worries :) | 07:42 |
| TheMue | fwereade__: phew ;) | 07:42 |
| fwereade__ | TheMue, it's just that I saw you at the exact moment I was deciding I didn't know the answer myself :) | 07:43 |
| TheMue | fwereade__: yeah, I would have liked to give you the missing link | 07:45 |
| wrtp | fwereade__, TheMue: mornin' | 08:16 |
| TheMue | wrtp: bonjour | 08:17 |
| Aram | moin. | 08:49 |
| TheMue | Aram: moin moin | 09:06 |
| fwereade__ | Aram, wrtp, TheMue: does anyone know why the juju-info relation has global scope? | 09:16 |
| fwereade__ | bcsaller, actually, if you're around, then you will be sure to know: ^^ | 09:17 |
| TheMue | fwereade__: sorry again, but it seems i have to take a deeper look at relations to get a better understanding | 09:19 |
| wrtp | fwereade__: that does seem a bit odd | 09:57 |
| wrtp | fwereade__: isn't the whole point of juju-info to support subordinates' relationship with their principal? | 09:57 |
| fwereade__ | wrtp, that had indeed been my conception of it | 09:57 |
| fwereade__ | wrtp, hmm, I'm suddenly wondering whether we should be occupying the juju-* namespace for hooks as well as relations | 10:05 |
| fwereade__ | wrtp, otherwise people could implement hooks for the provider side of juju-info | 10:06 |
| wrtp | fwereade__: hmm, interestin | 10:06 |
| wrtp | g | 10:06 |
| fwereade__ | wrtp, which becomes icky if those hooks suddenly appear during a charm upgrade, with a bunch of hooks already "run" | 10:06 |
| wrtp | fwereade__: i'm not quite sure i understand | 10:07 |
| fwereade__ | wrtp, it might not be a big deal, I'm not quite sure | 10:08 |
| fwereade__ | wrtp, I can't figure out whether there's any value in implementing provider-side hooks for juju-info | 10:09 |
| wrtp | fwereade__: i don't think we can occupy the juju-* name space entirely, otherwise you won't be able to implement requirer-side hooks for it | 10:09 |
| wrtp | fwereade__: hmm, i can see that there *might* be | 10:09 |
| fwereade__ | wrtp, ha, just realised | 10:10 |
| wrtp | fwereade__: although it's perhaps dodgy. | 10:10 |
| fwereade__ | wrtp, even if there is value it's fundamentally dodgy anyway | 10:10 |
| fwereade__ | wrtp, if we have multiple relations with the same name then the "what hook do we run" question becomes, I think, insoluble | 10:11 |
| wrtp | fwereade__: why would we have multiple relations with the same name? | 10:11 |
| fwereade__ | wrtp, we already do... everything implicitly provides juju-info, and some things also require it | 10:12 |
| wrtp | fwereade__: doesn't a principal provide exactly one juju-info relation? | 10:12 |
| fwereade__ | wrtp, yes, but so does a subordinate | 10:12 |
| fwereade__ | wrtp, everything provides exactly one | 10:12 |
| wrtp | fwereade__: ah, so you've got the same relation in provider and requirer roles | 10:12 |
| fwereade__ | wrtp, everything requires one or zero | 10:12 |
| fwereade__ | wrtp, yeah, essentially, but they're not really the same relation | 10:13 |
| wrtp | fwereade__: yeah sorry, | 10:13 |
| wrtp | fwereade__: i meant the same relation name | 10:13 |
| fwereade__ | wrtp, cool | 10:14 |
| wrtp | fwereade__: so it makes sense that you can't specify a juju-info hook | 10:14 |
| fwereade__ | wrtp, no, but yu have to | 10:14 |
| fwereade__ | wrtp, otherwise the whole relation is worthless | 10:14 |
| wrtp | fwereade__: because if you're requiring a juju-info hook, you'd name the relation something different, no? | 10:14 |
| wrtp | fwereade__: tbh i haven't yet seen a good use for the juju-info relation | 10:15 |
| fwereade__ | wrtp, I haven't done an exhaustive check but I've seen at least two charms with a require named juju-info | 10:16 |
| wrtp | fwereade__: did you see what they used it for? | 10:16 |
| fwereade__ | wrtp, here is one one example http://jujucharms.com/~david-duffey/precise/ddclient/hooks/juju-info-relation-joined | 10:17 |
| fwereade__ | wrtp, here is another: http://jujucharms.com/~ted/precise/application-start/hooks/juju-info-relation-joined | 10:18 |
| wrtp | fwereade__: it's interesting that they both specify scope: container | 10:21 |
| wrtp | fwereade__: i suppose that actually it makes sense to allow non-locally-scoped juju-info relations, because requirers can get local scope if they want | 10:22 |
| fwereade__ | wrtp, I'm not sure we get anything out of that ability though | 10:23 |
| fwereade__ | wrtp, I suspect it just misleads | 10:23 |
| fwereade__ | wrtp, I *think* that what I would like is: | 10:23 |
| wrtp | fwereade__: it provides the ability for one service to watch any other service in a generic way | 10:23 |
| fwereade__ | wrtp, every subordinate implicitly requires it; every principal implicitly provides it; write all the hooks you want; don't allow cross-role name collisions | 10:26 |
| wrtp | fwereade__: how many of those statements are true today? | 10:27 |
| fwereade__ | wrtp, just about none :/ | 10:27 |
| wrtp | fwereade__: i'm not sure about the first one | 10:27 |
| fwereade__ | wrtp, except possibly for write-all-the-hooks-you-want, but it's worthless due to name collisions | 10:27 |
| wrtp | fwereade__: why should every subordinate implicitly require it? | 10:28 |
| fwereade__ | wrtp, the subordinates don't have to do anything with it, just as principals don't have to do anything with the one they implicitly provide | 10:28 |
| wrtp | fwereade__: i thought *all* services provided a juju-info relation | 10:28 |
| wrtp | fwereade__: it kinda makes sense to me that that might be the case | 10:28 |
| fwereade__ | wrtp, yeah, I think that subordinates shouldn't | 10:29 |
| wrtp | fwereade__: why not? | 10:29 |
| wrtp | fwereade__: i think it could make sense to think of juju-info as something entirely orthogonal to the subordinate-principal relationship | 10:30 |
| fwereade__ | wrtp, because we have charms that both provide and require juju-info, and that's obviously crack | 10:30 |
| fwereade__ | wrtp, that's a nice idea, but I can't see how to make it work | 10:30 |
| fwereade__ | wrtp, (without changing existing charms...) | 10:31 |
| fwereade__ | wrtp, ok, alternative that might work | 10:31 |
| wrtp | fwereade__: i'm not sure. if we say that all charms implicitly provide juju-info, and juju-info relation hooks refer to the requirer side, i think that *might* work | 10:31 |
| fwereade__ | wrtp, everything implicitly provides juju-info unless it explicitly requires juju-info | 10:31 |
| fwereade__ | wrtp, apart from anything else, surely the fact that we can have unresolvably ambiguous relation specs is enough to sink the idea that name collisions are ok | 10:33 |
| wrtp | fwereade__: one possible way would be to move in a backwardly-incompatible way and prohibit people declaring a relation with the name "juju-info" | 10:33 |
| wrtp | fwereade__: given that very few people seem to use this functionality so far, that might not be so bad | 10:34 |
| wrtp | fwereade__: and then all the problems go away | 10:34 |
| fwereade__ | wrtp, could do, I guess -- but that feels like a punt on the big issue, which is that we apear to allow relation name collisions in charms | 10:34 |
| wrtp | fwereade__: you can declare several relations with the same name? | 10:35 |
| wrtp | fwereade__: that does seem like crack | 10:35 |
| fwereade__ | wrtp, yeah | 10:35 |
| wrtp | fwereade__: i wonder if any charms do that | 10:35 |
| wrtp | fwereade__: (other than the ones that declare juju-info, of course) | 10:35 |
| fwereade__ | wrtp, any with a juju-info relation do | 10:35 |
| fwereade__ | wrtp, ;p | 10:35 |
| fwereade__ | wrtp, I hope not :) | 10:35 |
| wrtp | fwereade__: i think it makes sense to reserve all relations with the prefix "juju-" | 10:36 |
| wrtp | fwereade__: or actually... | 10:36 |
| wrtp | fwereade__: yeah, it makes sense to do that; then we can add more in the future without breaking charms. | 10:37 |
| wrtp | fwereade__: but i think people could still write juju-info hooks | 10:38 |
| wrtp | fwereade__: i don't really see why that's a problem yet | 10:38 |
| fwereade__ | wrtp, they are actually all meant to be reserved, I think :/ | 10:39 |
| wrtp | fwereade__: if we insist that noone can redeclare juju-info, then we don't have any ambiguity | 10:39 |
| wrtp | fwereade__: in which case that ddclient charm is bogus, right? | 10:39 |
| wrtp | fwereade__: (the other one is ok, as it doesn't name the relation "juju-info") | 10:40 |
| fwereade__ | wrtp, hell, the hook naming totally threw me there | 10:41 |
| fwereade__ | wrtp, yeah, that sounds sensible to me | 10:41 |
| fwereade__ | wrtp, I could swear I'd seen code explicitly forbidding explicit juju-* relations | 10:41 |
| wrtp | fwereade__: we don't know that that charm actually works... | 10:42 |
| === Aram2 is now known as Aram | ||
| fwereade__ | wrtp, haha :/ I had hoped that charm store entry procedures were a little stricter, but I guess we already know they aren't all perfect | 10:46 |
| fwereade__ | wrtp, can you think of any reason not to insert the implicit relation in ReadMeta? | 11:13 |
| wrtp | fwereade__: that's a good question | 11:14 |
| wrtp | fwereade__: my gut says it's probably not a great idea, but... | 11:14 |
| fwereade__ | wrtp, yeah, I too feel discomfort, but I don't think any other place works | 11:15 |
| wrtp | fwereade__: can't it be done in state, when the charm is added? | 11:17 |
| wrtp | fwereade__: i think the charm package should prohibit the declaration of relations with a juju- prefix, but i'm not sure it should actively declare them. | 11:18 |
| wrtp | fwereade__: that seems to me like something that's appropriate for the system implementation to do. | 11:19 |
| wrtp | fwereade__: i'm kind of thinking that at some point in the future, we might see charms being used in different contexts, some of which might have a different set of implicitly declared juju- relations. | 11:19 |
| fwereade__ | wrtp, you may be right... I guess it's just that I'd prefer that the unit agent be able to determine whether a potential relation is valid by reading its own charm instead of having to hit remote state for it | 11:20 |
| fwereade__ | wrtp, actually that's no bug deal it's just a method that takes a charm.Charm | 11:20 |
| fwereade__ | wrtp, yeah, sgtm, cheers | 11:20 |
| wrtp | fwereade__: cool | 11:20 |
| wrtp | fwereade__: gustavo may well think differently, of course! | 11:21 |
| fwereade__ | wrtp, I understand that caveat to be implicit in everything I hear | 11:21 |
| fwereade__ | wrtp, or think ;) | 11:21 |
| wrtp | lol | 11:21 |
| fwereade__ | wrtp, hm, the python explicitly disallows *provides* with a juju-* name or interface | 11:24 |
| wrtp | fwereade__: i think it should disallow requires too | 11:24 |
| fwereade__ | wrtp, ISTM that we should disallow any juju-* name (or just "juju") | 11:24 |
| fwereade__ | wrtp, but I'm not sure we have any reason to mess with the interface | 11:24 |
| wrtp | fwereade__: any juju- name | 11:24 |
| fwereade__ | wrtp, so "juju" should be allowed? | 11:25 |
| wrtp | fwereade__: yeah, why not? | 11:25 |
| fwereade__ | wrtp, because it is misleading to see a "juju-info-relation-joined" hook | 11:26 |
| wrtp | fwereade__: i'm not sure i see why | 11:27 |
| fwereade__ | wrtp, I'm almost tempted to say that `starts with "juju"` should be the criterion | 11:27 |
| wrtp | fwereade__: why is juju-info-relation-joined misleading, even if there is a juju relation? | 11:28 |
| fwereade__ | wrtp, hold on, it's crack anyway | 11:28 |
| fwereade__ | wrtp, application-start has one of those | 11:28 |
| fwereade__ | wrtp, but it'll never get run afaict | 11:29 |
| wrtp | fwereade__: why not? | 11:29 |
| fwereade__ | wrtp, the only explicit relation it has is juju; it may run if it uses its implicit juju-info relation | 11:29 |
| wrtp | fwereade__: if you have a juju-info hook, then it must refer to the provider side, right? (assuming you're not allowed to explicitly declare a juju-info relation) | 11:30 |
| wrtp | fwereade__: so there's no ambiguity and... no problem? | 11:31 |
| Aram | wrtp: btw, regarding our discussing about " and =, = and == were in 10th edition unix, just catched my eye yesterday :). | 11:35 |
| fwereade__ | wrtp, guess so... still worried about the inconsistencies on charm upgrade when we add such hooks | 11:36 |
| Aram | also, the rc manual in 10th edition manual mentions plan 9, I wonder when did plan 9 development started. | 11:36 |
| wrtp | Aram: yeah, i think i used "=" first; then i added "==" (without knowing about the 10th edition version); then i moved to rc and started using - and -- instead | 11:36 |
| wrtp | fwereade__: what kind of inconsistencies are you thinking about? | 11:36 |
| wrtp | fwereade__: it would be easy to disallow juju-info hooks in the first instance, anyway | 11:37 |
| wrtp | Aram: i remember seeing plan 9 around just after i'd left university, around '91. charles had built his own clone of it (called Orbit) before it was made publicly available. | 11:38 |
| Aram | really? did he make any code available? | 11:39 |
| wrtp | Aram: i might have a pirated copy on magtape somewhere :-) | 11:40 |
| wrtp | Aram: he got the whole comp sci year using it for a year or so | 11:40 |
| fwereade__ | wrtp, most relations won't even be joined if the charm doesn't explicitly provide them; but the juju-info relation will be processed as usual | 11:50 |
| fwereade__ | wrtp, if we upgrade to a version that does provide hooks, it won't see the expected events | 11:51 |
| fwereade__ | wrtp, it will see departs of units that never joined, etc | 11:51 |
| wrtp | fwereade__: i see. | 11:51 |
| fwereade__ | wrtp, this *might* not be a big deal in practice but it involves dropping guarantees that STM to be useful | 11:52 |
| wrtp | fwereade__: i think that that's probably good enough reason to disallow implementation of juju-* hooks | 11:52 |
| wrtp | fwereade__: it kinda makes sense that the system is providing all interactions with juju- relations. | 11:53 |
| wrtp | fwereade__: one could see it as implicitly declaring the necessary hooks | 11:54 |
| wrtp | fwereade__: so it doesn't make sense for a charm to redefine them | 11:54 |
| fwereade__ | wrtp, yeah, this sounds reasonable | 11:55 |
| fwereade__ | wrtp, that then means that we should disallow "juju" as a relation name as well, otherwise we won't be able to write juju-relation-joined hooks | 11:55 |
| fwereade__ | s/otherwise/because/ | 11:56 |
| wrtp | fwereade__: i'm not sure i follow | 11:56 |
| fwereade__ | wrtp, disallow implementation of juju-* hooks => juju-relation-joined not ok => cannot meaningfully declare a "juju" relation | 11:57 |
| wrtp | fwereade__: i don't get the first inference. we disallow implementations of hooks for relations with a juju- prefix. but the relation name in juju-relation-joined is "juju" not "juju-" | 11:58 |
| fwereade__ | wrtp, ah, I thought yu were advocating the simpler "no hook can start with `juju-`" rule | 11:59 |
| fwereade__ | wrtp, which honestly I would prefer | 11:59 |
| wrtp | fwereade__: i think it's easier to think in terms of relation names | 12:00 |
| wrtp | fwereade__: (HasPrefix(name, "juju-") || name == "juju") is more complex and arbitrary, IMHO, than just the HasPrefix test | 12:00 |
| fwereade__ | wrtp, I think specifying that no files in charm/hooks can start with "juju-" is the absolute simplest way to get what we need | 12:01 |
| wrtp | fwereade__: and i don't see that we'll ever need to define a "juju" relation. | 12:01 |
| fwereade__ | wrtp, why should we allow others to? | 12:01 |
| wrtp | fwereade__: because it's a convenient name to use for the requirer side of a juju-info relation? | 12:02 |
| fwereade__ | wrtp, doesn't this presuppose that we won't have other juju- relations? | 12:02 |
| wrtp | fwereade__: i don't think so. | 12:02 |
| fwereade__ | wrtp, it's only a good name so long as juju-info is the only juju- one available | 12:02 |
| wrtp | fwereade__: a better name would probably be principal-info, right enough | 12:03 |
| wrtp | fwereade__: tbh i wouldn't mind if we just reserved all juju* names. | 12:04 |
| fwereade__ | niemeyer, heyhey | 12:04 |
| wrtp | niemeyer: yo! | 12:04 |
| fwereade__ | wrtp, that's what I'd prefer | 12:04 |
| niemeyer | Good morning! | 12:04 |
| fwereade__ | niemeyer, I was wondering, did you see the prereq of the CL you approved last night? I have a suspicion it may have got caught in the miscommunication | 12:08 |
| niemeyer | fwereade__: Let me check | 12:08 |
| fwereade__ | niemeyer, https://codereview.appspot.com/6678046/ | 12:08 |
| fwereade__ | niemeyer, you have reviewed it once butthat was a while ago | 12:08 |
| niemeyer | fwereade__: Ah, sorry.. I didn't realize it was a pre-req.. I reviewed the other one in an attempt to unblock you, but I has fail | 12:09 |
| fwereade__ | niemeyer, np at all, I have other things I have been thinking about usefully | 12:09 |
| fwereade__ | niemeyer, I will definitely want a call about charms and relations at some point | 12:10 |
| niemeyer | fwereade__: I'm game at any time | 12:10 |
| fwereade__ | niemeyer, it's just that I'm getting peckish and will probably disappear for luch soonish ;p | 12:10 |
| niemeyer | fwereade__: Sounds like a good plan :-) | 12:10 |
| fwereade__ | niemeyer, ok, I will be back in a little while, hopefully the various issues will settle into some sort of order in my mind :) | 12:12 |
| wrtp | niemeyer: a bootstrap can "succeed" several times, because the only way it can find out if the environment is already bootstrapped is by reading the environment's storage, which might not be available because of eventual consistency. | 12:14 |
| wrtp | niemeyer: it's possible that moving to using tags might help this issue, but i'm not sure. | 12:14 |
| niemeyer | wrtp: We shouldn't allow for that to happen | 12:15 |
| niemeyer | wrtp: Otherwise it's ad-hoc | 12:15 |
| wrtp | niemeyer: do you have an idea for how we might prevent it? | 12:16 |
| wrtp | niemeyer: we could put a sleep at the start of Bootstrap, i suppose | 12:16 |
| niemeyer | wrtp: We can read the information we just wrote, for example | 12:16 |
| niemeyer | wrtp: Before confirming it worked | 12:16 |
| wrtp | fwereade__: how does that help? | 12:17 |
| wrtp | niemeyer: how does that help? | 12:17 |
| wrtp | fwereade__: (didn't mean to address that to you, sorry) | 12:18 |
| wrtp | niemeyer: BTW could we have a chat about TLS certs some time today? | 12:18 |
| niemeyer | wrtp: Well, the idea is ensuring data we just wrote is visible | 12:21 |
| wrtp | niemeyer: doing that does not ensure that, unfortunately | 12:21 |
| wrtp | niemeyer: a read can succeed and then fail | 12:21 |
| wrtp | niemeyer: (there's one live test that prints a *sigh* message when that happens, and i see it reasonable often) | 12:22 |
| wrtp | niemeyer: it would probably reduce the frequency of Bootstrap succeeding twice in succession, but i don't think it would stop it entirely. | 12:23 |
| niemeyer | wrtp: It's not just about Bootstrap.. this isn't right either: | 12:26 |
| niemeyer | r, err = storage.Get(name) | 12:26 |
| niemeyer | if err == nil { | 12:26 |
| niemeyer | break | 12:26 |
| niemeyer | } | 12:26 |
| wrtp | niemeyer: i was just looking at that | 12:26 |
| wrtp | niemeyer: yes, that's wrong. | 12:26 |
| wrtp | niemeyer: storage.Get does the retry anyway, so it's unnecessary for the tests to do that | 12:26 |
| niemeyer | wrtp: Eventual consistency sucks to deal with, and we should take the bullet to offer people a sane API | 12:26 |
| wrtp | niemeyer: i agree. | 12:26 |
| wrtp | niemeyer: but in some cases i'm not sure it's possible | 12:27 |
| niemeyer | wrtp: If accessing data is *entirely* random, then I can't see why people use S3 | 12:27 |
| wrtp | niemeyer: it's not entirely random. it works... eventually. | 12:27 |
| niemeyer | wrtp: Yep, so we should wait until it does | 12:28 |
| wrtp | niemeyer: for the record, i see the *sigh* message relatively often. | 12:28 |
| wrtp | niemeyer: we do! | 12:28 |
| wrtp | niemeyer: but in these cases, the request succeeds, so there's nothing to wait for | 12:29 |
| niemeyer | wrtp: Obviously a request succeeding doesn't seem to mean much | 12:29 |
| wrtp | niemeyer: if we delete a file, we can sometimes fetch it even after the delete request. that request is succeeding, but it shouldn't. it will fail eventually though, but the thing doing the Get can't know that it was expected to fail and hence retry. | 12:30 |
| niemeyer | wrtp: I understand what eventual consistency means, and I also understand that S3 has it | 12:32 |
| wrtp | niemeyer: i'm not sure how you expect me to fix the problem while removing the loops in jujutest then | 12:34 |
| niemeyer | wrtp: I'm thinking as well | 12:39 |
| niemeyer | wrtp: So, I think the issue is on loading, rather than on writing | 12:42 |
| niemeyer | wrtp: It'd suck to wait a long time for things to show up when we're writing sequentially several charms or whatever | 12:43 |
| niemeyer | wrtp: But it seems that in general files we read from S3 are in well known locations, that should be there | 12:43 |
| wrtp | niemeyer: i don't yet see where you're going with this | 12:44 |
| niemeyer | wrtp: Bootstrap doesn't tell you that there was a previous bootstrap because it fails to get the previous file | 12:44 |
| niemeyer | wrtp: We already have a retry strategy on Get.. why is it not working? | 12:45 |
| wrtp | niemeyer: look at the start of the Bootstrap method | 12:45 |
| wrtp | niemeyer: we fail when the Get *succeeds* | 12:45 |
| niemeyer | <niemeyer> wrtp: Bootstrap doesn't tell you that there was a previous bootstrap because it fails to get the previous file | 12:46 |
| wrtp | niemeyer: yeah, i was wrong there | 12:46 |
| wrtp | niemeyer: it can only know if there was a previous bootstrap if it can get the file which was created by the previous bootstrap. | 12:47 |
| niemeyer | Yep | 12:47 |
| wrtp | niemeyer: actually, Bootstrap should do the loop itself | 12:47 |
| wrtp | niemeyer: because it knows that it's expecting the file not to be there. | 12:48 |
| wrtp | niemeyer: that would erase the jujutest bootstrap loop at any rate, if not the others., | 12:48 |
| wrtp | niemeyer: it means Bootstrap will always take 5 seconds when the environment is already bootstrapped, but that might not be a problem. | 12:52 |
| niemeyer | wrtp: Hmm | 12:52 |
| niemeyer | wrtp: Why would it do the loop itself? | 12:53 |
| niemeyer | wrtp: Get does the loop already | 12:53 |
| wrtp | niemeyer: Get only loops if the file is not found | 12:53 |
| niemeyer | wrtp: We just have to improve Get until it works more reliably | 12:53 |
| niemeyer | wrtp: Yes, and that's what we need | 12:53 |
| wrtp | niemeyer: in this case the file *is* found, so it won't loop | 12:53 |
| wrtp | niemeyer: and that's a problem for Bootstrap, because it gives an error when the file is found. | 12:54 |
| niemeyer | wrtp: If the file is found, Bootstrap can fail | 12:54 |
| wrtp | niemeyer: exactly. | 12:54 |
| niemeyer | wrtp: Immediately | 12:54 |
| niemeyer | wrtp: I mean it *can* fail | 12:54 |
| wrtp | niemeyer: that's a problem if we do a Destroy followed by a Bootstrap. | 12:54 |
| niemeyer | wrtp: Destroy kills the whole bucket | 12:55 |
| wrtp | niemeyer: yes, but we might still be able to fetch that bucket even after it's been killed | 12:55 |
| wrtp | niemeyer: which will cause Bootstrap to fail inappropriately. | 12:55 |
| niemeyer | wrtp: Okay, so perhaps we should make Destroy more reliable instead | 12:55 |
| niemeyer | wrtp: Because that's the weak link | 12:56 |
| wrtp | niemeyer: so we make Destroy always take 5 seconds? | 12:56 |
| niemeyer | wrtp: We can have slightly more deterministic logic by having it retry until it can no longer see the file in a few different tries | 12:57 |
| niemeyer | wrtp: That means we don't slow down tests much | 12:57 |
| wrtp | niemeyer: that doesn't necessarily mean that a subsequent fetch won't still succeed | 12:57 |
| niemeyer | wrtp: Heh | 12:57 |
| niemeyer | wrtp: It won't ever mean that, whatever we do | 12:57 |
| niemeyer | wrtp: Even hours later S3 can still pull off a TA-DA! moment | 12:58 |
| niemeyer | wrtp: But we can at least try to bring some sanity | 12:58 |
| wrtp | niemeyer: yeah | 12:58 |
| wrtp | niemeyer: but it means we still need the Bootstrap loop if we're to make the tests reliable | 12:58 |
| niemeyer | wrtp: I don't see why.. bootstrap uses loadState which uses Get | 12:59 |
| wrtp | niemeyer: ... which can succeed even after the bucket has been destroyed and we've verified that we get a 404 error. | 12:59 |
| niemeyer | wrtp: We've just said we'd improve Destroy? | 13:00 |
| niemeyer | wrtp: What has to change in Bootstrap? | 13:00 |
| wrtp | niemeyer: that's the "verified that we get a 404 error" bit | 13:00 |
| wrtp | niemeyer: nothing has to change in Bootstrap. i'm talking about the loop in the test that calls Bootstrap. | 13:00 |
| wrtp | niemeyer: (the one that triggered this discussion) | 13:00 |
| niemeyer | wrtp: Erm.. | 13:00 |
| niemeyer | wrtp: Yes.. I'm a bit lost now.. all we've been saying above is to make things more reliable | 13:01 |
| niemeyer | wrtp: If we still have to loop in tests, the whole point is moot | 13:01 |
| wrtp | niemeyer: yes, but it won't be that reliable, even with the change above. | 13:01 |
| niemeyer | wrtp: Why? | 13:01 |
| wrtp | niemeyer: because verifying that the Get fails after Destroy doesn't verify that get Get called in Bootstrap won't subsequently succeed. | 13:02 |
| wrtp | s/get Get/the Get/ | 13:02 |
| wrtp | niemeyer: personally, i *think* the loop in the test is the lesser evil. much better would be if we could talk to *something* in amz that was fully consistent. | 13:05 |
| niemeyer | wrtp: If the Get sequentially fails several times at Destroy, and then Bootstrap can see the file again, too bad.. let the test blow | 13:05 |
| niemeyer | wrtp: Much better is if we don't use S3 at all.. that's where we have to go | 13:06 |
| wrtp | niemeyer: how many times do we try? what if this causes the test to fail 10% of the time? | 13:06 |
| niemeyer | wrtp: We improve it until it's 1% or 0.01% | 13:06 |
| wrtp | niemeyer: i'm not entirely sure that avoiding S3 will help here. | 13:06 |
| niemeyer | wrtp: Erm? | 13:06 |
| niemeyer | wrtp: Everything we've been talking about for the past hour is about S3 | 13:07 |
| wrtp | niemeyer: what's the alternative? tags? surely they'll suffer from a similar problem? | 13:07 |
| niemeyer | wrtp: An internal storage | 13:07 |
| wrtp | niemeyer: how does that help with Bootstrap? | 13:07 |
| niemeyer | wrtp: True.. | 13:07 |
| niemeyer | wrtp: Either way, let's not derail | 13:07 |
| niemeyer | wrtp: The test is great.. it's showing the API is flaky.. there's nothing to fix there | 13:07 |
| wrtp | niemeyer: what about the other tests that loop? | 13:08 |
| niemeyer | wrtp: Same thing.. we have that shows storage.Get failing, and you say it fails often | 13:08 |
| niemeyer | wrtp: Sounds to me like we should improve storage.Get too | 13:08 |
| wrtp | niemeyer: by causing it to fetch several times? | 13:09 |
| wrtp | niemeyer: it does already retry on error | 13:09 |
| niemeyer | wrtp: Or perhaps try more often | 13:09 |
| niemeyer | wrtp: We should have a live test specifically for it, showing whether it works reasonably well or not | 13:10 |
| wrtp | niemeyer: ISTM that these tests are doing something that people won't be doing much in normal usage - we don't really care if something succeeds when it shouldn't most of the time. | 13:10 |
| niemeyer | wrtp: ISTM that we don't know how people will be using it | 13:10 |
| niemeyer | wrtp: destroy+bootstrap is not uncommon at all, for example | 13:11 |
| wrtp | niemeyer: i'm not sure what the Get test you're suggesting would do, and how Get might be improved. i don't think we want to retry on Get. nor, probably do we want to slow down every Put or Delete by doing a sequence of Gets after it. | 13:14 |
| wrtp | s/retry on Get/retry when Get succeeds/ | 13:15 |
| niemeyer | wrtp: It would verify how reliable Get looks like when we put something | 13:16 |
| niemeyer | wrtp: We want to solve the instability you see in the test by fixing the API, rather than by looping in the test | 13:17 |
| niemeyer | wrtp: We want to avoid looping in the test, because it shows very unstable behavior in the API itself.. we don't want that to be our high-water mark for all the providers. | 13:18 |
| wrtp | niemeyer: i'd like to fix the API (and we *have* fixed it when things fail), but i'm not sure how we can fix it without slowing everything down to full-eventual-consistency pace. | 13:18 |
| niemeyer | wrtp: I've just explained | 13:19 |
| wrtp | niemeyer: i fully agree that it's unfortunate | 13:19 |
| wrtp | niemeyer: ok, so suppose i write the test and it shows that in 40% of cases, a Get succeeds when it should not. | 13:19 |
| wrtp | niemeyer: what then? | 13:19 |
| niemeyer | wrtp: Then that's REALLY BAD isn't it!? | 13:20 |
| niemeyer | wrtp: If Destroy+Bootstrap fails 40% of the times, we suck I think | 13:20 |
| wrtp | niemeyer: that's S3 for you :-( | 13:20 |
| niemeyer | wrtp: Nope.. that's juju developers for you | 13:20 |
| niemeyer | wrtp: S3 seems to work fine for a lot of people | 13:20 |
| niemeyer | wrtp: storage.Get succeeding is fine | 13:21 |
| wrtp | niemeyer: we can easily make Destroy+Bootstrap fully reliable by making Bootstrap wait for eventual consistency to resolve before returning an error, as Get does. | 13:21 |
| niemeyer | wrtp: It's the other case that is a lot more rare: there are very few spots where we care about content being *deleted* | 13:21 |
| wrtp | niemeyer: Get("nonexistent-thing") will currently always take 5 seconds. | 13:22 |
| niemeyer | wrtp: I don't see how that's relevant | 13:22 |
| wrtp | niemeyer: i agree. but that's what these tests are showing. | 13:22 |
| niemeyer | wrtp: Bootstrap uses loadState, which uses Get.. Bootstrap is fine as it is | 13:22 |
| wrtp | s/showing/testing/ | 13:23 |
| wrtp | niemeyer: our current technique for avoiding eventual consistency issues is to try to avoid errors. | 13:24 |
| wrtp | niemeyer: so, if we're about to return an error, we try a few times to make sure that we've *really* got an error. | 13:24 |
| wrtp | niemeyer: ISTM that Bootstrap fits into that category. | 13:24 |
| niemeyer | wrtp: Sorry.. can we get to actual use cases so we can start to funnel the conversation towards agreement? | 13:25 |
| niemeyer | wrtp: We're talking for more than an hour, so it's time to reach some conclusions | 13:25 |
| niemeyer | wrtp: Destroy+Bootstrap fails and we want it to work.. | 13:26 |
| niemeyer | wrtp: We can make that more reliable by having Destroy wait until the file at least looks gone | 13:27 |
| wrtp | niemeyer: my suggestion is to make Bootstrap not fail until the bootstrap bucket definitely isn't disappearing | 13:27 |
| niemeyer | wrtp: I don't know what that means | 13:28 |
| niemeyer | wrtp: Probably because thre are three negatives | 13:28 |
| wrtp | niemeyer: your suggestion is *more* reliable, but it still isn't reliable. i believe my solution is reliable (well, as reliable as our Get heuristics) | 13:28 |
| wrtp | niemeyer: this is what i suggest for the start of the Bootstrap method :http://paste.ubuntu.com/1285011/ | 13:29 |
| niemeyer | wrtp: We're almost in agreement | 13:30 |
| wrtp | niemeyer: the down side is that a failed Bootstrap gets slower. but that's what happens with a failed Get too, so comparable cases, i think. | 13:30 |
| niemeyer | wrtp: The difference is that you're doing the verification that should be dong in Destroy within Bootstrap | 13:32 |
| niemeyer | wrtp: That's effectively what this is doing.. it's waiting until Destroy actually takes place.. we can do that in Destroy itself | 13:33 |
| wrtp | niemeyer: i'm not sure we can do that and ensure that the subsequent Bootstrap will succeed, without waiting for the full eventual consistency timeout. | 13:34 |
| wrtp | niemeyer: and perhaps that's actually best - we'd just delay destroy-environment for a while. | 13:35 |
| niemeyer | wrtp: That's true | 13:36 |
| niemeyer | wrtp: Okay, sounds good | 13:36 |
| wrtp | niemeyer: so we add a sleep to Destroy? | 13:36 |
| niemeyer | wrtp: What? :) | 13:37 |
| wrtp | niemeyer: or... what sounds good to you? | 13:37 |
| niemeyer | wrtp: Your proposal.. | 13:37 |
| wrtp | niemeyer: ok, cool. | 13:37 |
| niemeyer | wrtp: I think storage.Get likely deserves some improvement too to sort out that issue you see frequently | 13:38 |
| wrtp | niemeyer: i'll still need to leave the loops in some of the other jujutest tests, i think. | 13:38 |
| niemeyer | wrtp: I'd prefer to nail down problems rather than looping | 13:38 |
| niemeyer | wrtp: For all the reasons we already covered | 13:38 |
| niemeyer | wrtp: We're nailing one of them | 13:38 |
| wrtp | niemeyer: i only see it frequently because the test is checking Get after Delete, which i don't think is something that we care too much about in real-world code. | 13:38 |
| niemeyer | wrtp: Let's solve that first one, and then we see the others | 13:39 |
| niemeyer | wrtp: So let's not do that | 13:39 |
| wrtp | niemeyer: remove that test? | 13:39 |
| niemeyer | wrtp: Well, I suppose this is testing Delete? | 13:39 |
| wrtp | niemeyer: yes | 13:39 |
| wrtp | niemeyer: there's also one in the test that tests List, i think. | 13:40 |
| niemeyer | wrtp: List is a tough one, because we don't know what we're waiting for.. | 13:41 |
| wrtp | niemeyer: in fact it's all in TestFile | 13:41 |
| wrtp | niemeyer: yup | 13:41 |
| niemeyer | wrtp: I guess those loops for the storage method itself are fine, at least for now | 13:43 |
| niemeyer | wrtp: It's the environment interaction we care the most about | 13:43 |
| wrtp | niemeyer: yeah | 13:43 |
| wrtp | niemeyer: i'm happy to have Bootstrap work a little more reliably. | 13:43 |
| niemeyer | wrtp: Me too | 13:44 |
| niemeyer | wrtp: I think storage.Get may need some tweaking too | 13:44 |
| niemeyer | wrtp: But we'll see | 13:45 |
| wrtp | niemeyer: what kind of tweak are you thinking of? | 13:45 |
| niemeyer | wrtp: Perhaps just reducing the time between retries | 13:45 |
| niemeyer | wrtp: So we don't increase the overall time further but improve the method a tad | 13:45 |
| wrtp | niemeyer: i'm not sure that helps here. we're talking about the case where it doesn't retry at all, because the Get succeeds. | 13:46 |
| wrtp | niemeyer: we could retry even when the fetch succeeds, but i *think* that's unnecessary. | 13:47 |
| niemeyer | wrtp: I was considering something else, but it doesn't really matter right now.. sorry for the noise. | 13:47 |
| wrtp | niemeyer: np | 13:47 |
| wrtp | niemeyer: i'm sorry i'm bad at explaining things! | 13:48 |
| niemeyer | wrtp: I don't think you're bad at explaining things. | 13:49 |
| wrtp | niemeyer: it felt like i wasn't explaining things well above, but we got there! | 13:51 |
| niemeyer | wrtp: I don't think it was a problem in the explanation.. | 13:53 |
| niemeyer | <wrtp> niemeyer: nothing has to change in Bootstrap. i'm talking about the loop in the test that calls Bootstrap. | 13:54 |
| niemeyer | wrtp: That was 1h ago.. | 13:54 |
| niemeyer | wrtp: It took 1h for us to agree to solve the actual problem without looping in tests. | 13:54 |
| wrtp | that was in response to talking about making Destroy try the get, i think | 13:56 |
| fwereade__ | niemeyer, take a look at http://paste.ubuntu.com/1285056/ -- I think it roughly covers the areas I'm thinking about | 13:56 |
| niemeyer | wrtp: <wrtp> niemeyer: i'd like to fix the API (and we *have* fixed it when things fail), but i'm not sure how we can fix it without slowing everything down to full-eventual-consistency pace. | 13:58 |
| niemeyer | wrtp: Etc etc | 13:58 |
| wrtp | niemeyer: to be fair, i had suggested the current solution some time before my "nothing has to change" remark | 13:59 |
| wrtp | niemeyer: and our API is still broken (Bootstrap is less so now, happily), and we can't fix it | 13:59 |
| niemeyer | wrtp: Nevermind.. You rock. | 14:00 |
| niemeyer | fwereade__: Checking it out | 14:00 |
| * wrtp wishes he did | 14:00 | |
| niemeyer | fwereade__: 0) that seems crazy indeed | 14:01 |
| niemeyer | fwereade__: The name is precisely the way in which the charm uniquely identifies the relation | 14:01 |
| fwereade__ | niemeyer, cool | 14:03 |
| wrtp | niemeyer: this might do it: https://codereview.appspot.com/6696043/ | 14:04 |
| niemeyer | fwereade__: 1a) +1 | 14:04 |
| wrtp | niemeyer: (waiting on live tests to complete a few times before i believe it) | 14:04 |
| niemeyer | fwereade__: 1b) "but allowing freedom to implement any interfaces": I don't think we should allow people to implement juju-* interfaces | 14:04 |
| fwereade__ | niemeyer, they have to implement it to talk to juju-info | 14:05 |
| fwereade__ | niemeyer, (whose interface is also juju-info) | 14:06 |
| niemeyer | fwereade__: Okay, that's requiring the interface, specifically | 14:06 |
| niemeyer | fwereade__: Although, you could say that means implementing it too | 14:07 |
| niemeyer | fwereade__: So my bad in the wording | 14:07 |
| fwereade__ | niemeyer, and honestly I don't see any reason to *stop* people from implementing non-juju-namespaced relations that happen to be acceptable substitutes | 14:07 |
| niemeyer | fwereade__: What I meant is that we shouldn't allow people to provide juju-info | 14:07 |
| fwereade__ | niemeyer, it'd be kinda dumb but harmless I think | 14:07 |
| fwereade__ | niemeyer, ah, not harmless then? | 14:07 |
| niemeyer | fwereade__: No, juju-* is reserved | 14:08 |
| niemeyer | fwereade__: We shouldn't break people's charms if we decide to implement juju-mama tomorrow | 14:08 |
| niemeyer | fwereade__: If we don't reserve it, we can | 14:08 |
| niemeyer | We can break, I mean | 14:08 |
| fwereade__ | niemeyer, ok, sgtm | 14:09 |
| fwereade__ | niemeyer, so: you can't call a relation juju or juju-*; you can't provide an interface called juju or juju-*; anything else is ok? | 14:09 |
| niemeyer | fwereade__: +1 | 14:12 |
| niemeyer | fwereade__: 1c) Charm metadata is definitely not the place to insert implicit relations | 14:13 |
| niemeyer | fwereade__: Otherwise they'd not be implicit | 14:13 |
| niemeyer | fwereade__: If we inserted, that would affect several places we don't want to touch | 14:14 |
| niemeyer | fwereade__: e.g. the store | 14:14 |
| niemeyer | fwereade__: and it'd also mean that old charms don't get new implicit relations | 14:14 |
| fwereade__ | niemeyer, that applies to the metadata file... when about the Meta type? | 14:15 |
| * fwereade__ regards "when about" with horror | 14:15 | |
| niemeyer | fwereade__: LOL | 14:15 |
| niemeyer | fwereade__: I was about to put that in my vocabulary.. you have to watch out when you talk to me | 14:16 |
| fwereade__ | niemeyer, (actually, derail for now, it will be relevant again soo) | 14:16 |
| fwereade__ | niemeyer, nah, just an incompetent edit | 14:16 |
| niemeyer | fwereade__: Meta reflects the metadata | 14:16 |
| niemeyer | fwereade__: It's actually stored in the store | 14:16 |
| niemeyer | fwereade__: a terrible evil will fall upon us if we hack that nice piece of immutable information | 14:17 |
| fwereade__ | niemeyer, right, cool, the "doesn't feel right" is accurate | 14:17 |
| niemeyer | fwereade__: Okay, in sync, so going to 2 | 14:18 |
| niemeyer | fwereade__: 2a) +1.. I think that was covered in 1b | 14:18 |
| fwereade__ | niemeyer, yeah, there is some overlap | 14:18 |
| niemeyer | fwereade__: I mean, +1 to the (no) | 14:18 |
| fwereade__ | niemeyer, cool | 14:18 |
| niemeyer | fwereade__: 2b) Perhaps nothing.. let's handle them silently within the uniter if it reaches it, and blow up at the door when bundling/loading the charm | 14:19 |
| niemeyer | So the uniter doesn't have to know about these conventions | 14:20 |
| fwereade__ | niemeyer, in code terms, I was thinking of just refusing to load such abominations | 14:20 |
| fwereade__ | ;) | 14:20 |
| niemeyer | fwereade__: That's what I meant.. we don't have to special case in the uniter, because we don't bundle them | 14:21 |
| fwereade__ | niemeyer, cool, perfect | 14:21 |
| niemeyer | fwereade__: 2c) Yes, people should certainly be able to run a hook for juju-info.. but it's not clear if that's the question you asked | 14:21 |
| fwereade__ | niemeyer, oh ok -- I was expecting to be able to relate *to* juju-info, and run hooks in repsonse to a counterpart's juju-info, but I was not expecting charmers to implement, say, juju-info-relation-joined | 14:23 |
| fwereade__ | niemeyer, what does that tell you other than "a subordinate exists"? | 14:23 |
| fwereade__ | niemeyer, except it doesn't even tell you that | 14:23 |
| fwereade__ | niemeyer, because juju-info has global scope | 14:23 |
| fwereade__ | niemeyer, it just means "something you don't know about is in a relation with you" | 14:24 |
| niemeyer | fwereade__: Okay, let's break that apart | 14:24 |
| fwereade__ | niemeyer, and I can't figure out how that information is useful to anyone | 14:24 |
| niemeyer | fwereade__: juju-info-relation-joined means the relation *name* is juju-info, which is.. hmm.. interesting | 14:25 |
| niemeyer | fwereade__: We said before we'd disallow it, but I'm not sure we should, now that I think of it | 14:25 |
| fwereade__ | niemeyer, I have one concern there | 14:26 |
| niemeyer | fwereade__: First, because it doesn't really matter.. that's the user-provided name for the relation | 14:26 |
| niemeyer | fwereade__: We don't really care, I think | 14:26 |
| niemeyer | fwereade__: Second, because we offer convenient shortcut notation in charms that make relation-name == relation-interface | 14:26 |
| niemeyer | fwereade__: So, I think relation *names* that have juju* sound okay, in principle. What do you think? | 14:27 |
| fwereade__ | niemeyer, the specific thing I want to block is an author who responds to changes he shouldn't know about, by doing things in response to the implicit juju-info relation changing | 14:28 |
| niemeyer | fwereade__: Before we derail, does the above sound sane? | 14:28 |
| fwereade__ | niemeyer, blocking juju entirely seemed like the simplest and clearest way to ensure the situation didn't come up in future | 14:28 |
| niemeyer | fwereade__: is there a reason to prevent a relation *name* from being named juju* | 14:28 |
| niemeyer | fwereade__: Blocking a relation name doesn't do anything.. it has absolutely no semantics attached to it | 14:29 |
| niemeyer | fwereade__: Other than being an identifier | 14:29 |
| fwereade__ | niemeyer, I thought it want just a reserved-for-=future-use deal | 14:29 |
| fwereade__ | niemeyer, s/want/was/ | 14:29 |
| * fwereade__ is typing, er, "dynamically" today | 14:30 | |
| niemeyer | fwereade__: The point I'm considering is that: a) It's useful to have it because we have syntax that makes relation-name == relation-interface convenient, and we have relation interfaces called juju-*; | 14:30 |
| niemeyer | fwereade__: b) There's nothing to reserve. It's an identifier without any semantics attached to it other than being a way to reference the relation by the local charm author | 14:31 |
| fwereade__ | niemeyer, ok, we have one relation interface called juju-info, at this stage, that *everything* provides | 14:31 |
| niemeyer | fwereade__: interface != name | 14:31 |
| fwereade__ | niemeyer, if we do a shortcut "juju-info" relation then the name will collide | 14:31 |
| niemeyer | fwereade__: Everything I said above is about the relation name, not the interface | 14:32 |
| fwereade__ | s/interface // | 14:32 |
| fwereade__ | niemeyer, we can't allow juju-info because the name collides with the implicit relation | 14:32 |
| niemeyer | fwereade__: If a name collides, it will blow up.. that's a separate constraint that should necessarily be enforced for every relation, despite its name | 14:32 |
| fwereade__ | niemeyer, if we allow juju-* relation names we are setting ourselves up for future collisions | 14:33 |
| niemeyer | fwereade__: I don't see how that's relevant at all | 14:33 |
| niemeyer | fwereade__: Or perhaps, more clearly, I don't see how we'd be setting ourselves up for future collisions | 14:34 |
| niemeyer | fwereade__: Relation names are a local namespace | 14:35 |
| fwereade__ | niemeyer, ISTM that we will not be free to pick sensible names for future implicit relations, because other charms might already be using those names for something different | 14:35 |
| niemeyer | fwereade__: I don't think that's true | 14:35 |
| niemeyer | fwereade__: Can you provide a short example? It'll elucidate the point | 14:36 |
| fwereade__ | niemeyer, imagine we wanted to introduce juju-info, but charms already existed which use that relation name... what is the appropriate course of action? break the charms, or just call it "juju-inof-no-really-this-is-the-official-one"? ;p | 14:37 |
| fwereade__ | niemeyer, I don't know what other implicit relations we may want to introduce | 14:37 |
| niemeyer | fwereade__: We introduce the *interface* juju-info, and absolutely nothing breaks at all | 14:37 |
| fwereade__ | niemeyer, so what do we name the relation then? | 14:38 |
| niemeyer | fwereade__: We don't.. it's not our name.. we don't care | 14:38 |
| fwereade__ | niemeyer, it *is* our name | 14:38 |
| fwereade__ | niemeyer, we implicitly provide juju-info | 14:38 |
| niemeyer | fwereade__: Ahh, I see. You're wondering about the provider side | 14:39 |
| niemeyer | fwereade__: It's a good point.. hmm | 14:39 |
| fwereade__ | niemeyer, I'm a little bewildered - I *think* I'm just reiterating that names should be unique within a charm -- across roles | 14:39 |
| niemeyer | fwereade__: across roles? | 14:39 |
| fwereade__ | niemeyer, a provider called foo and a requirer called foo? | 14:40 |
| niemeyer | fwereade__: Ah, no no.. that's definitely not ok | 14:40 |
| niemeyer | fwereade__: Must be unique | 14:40 |
| niemeyer | fwereade__: I just never thought about the charm referencing the provider relation locally | 14:40 |
| niemeyer | fwereade__: The implicit one, that is | 14:40 |
| niemeyer | fwereade__: Again, it's a good point.. it just escaped me | 14:40 |
| fwereade__ | niemeyer, yeah, I only came across it this morning | 14:41 |
| niemeyer | fwereade__: So here is a suggestion that preserves my original intention, and I think sorts out the problem you bring: we do allow juju* relation names, as long as they match the interface name | 14:41 |
| niemeyer | fwereade__: In other words, it's fine for a requirer juju-info relation to be named juju-info | 14:42 |
| * fwereade__ thinks a bit | 14:42 | |
| fwereade__ | niemeyer, I'm not sure that helps | 14:42 |
| niemeyer | fwereade__: Ah, indeed | 14:42 |
| fwereade__ | niemeyer, what does `svc1:juju-info` refer to? | 14:42 |
| niemeyer | fwereade__: requirer and provider would conflict | 14:43 |
| niemeyer | Dmad | 14:43 |
| niemeyer | Damd | 14:43 |
| niemeyer | fwereade__: Okay, +1 on not allowing it.. it's clearly non trivial and I'm digging a hole | 14:44 |
| fwereade__ | niemeyer, cool, cheers | 14:44 |
| niemeyer | fwereade__: Okay, another point on your comment: juju-info has global scope | 14:45 |
| niemeyer | fwereade__: I don't think that's the case | 14:45 |
| niemeyer | fwereade__: The *relation* has whatever scope the requirer gives it | 14:45 |
| niemeyer | fwereade__: Otherwise we'd not be able to use juju-info for the very reason it was created | 14:45 |
| fwereade__ | niemeyer, ok, yes -- what I mean is that it *allows for* globally scoped relations, and I'm not sure it has any value in that instance | 14:46 |
| fwereade__ | niemeyer, I am almost certainly missing something here though | 14:46 |
| niemeyer | fwereade__: It provides the ip address of the related unit | 14:46 |
| niemeyer | fwereade__: So there's *some* value | 14:46 |
| fwereade__ | niemeyer, yeah, I guess we could have an automated try-to-hack-this-box charm we could relat to everything :0 | 14:47 |
| fwereade__ | niemeyer, ok, objections withdrawn :) | 14:47 |
| niemeyer | fwereade__: That said, I'm not sure about why this is relevant to be honest.. it's just another relation, that can be global or container, and behaves like anything else in that sense | 14:47 |
| niemeyer | fwereade__: Am I missing something? | 14:47 |
| fwereade__ | niemeyer, I think it's just a derail, sorry :) | 14:48 |
| niemeyer | fwereade__: Indeed, but given that we've derailed.. can we agree it's just like any other relation in that sense? | 14:48 |
| niemeyer | fwereade__: I just want to make sure I'm not missing yet another aspect | 14:49 |
| fwereade__ | niemeyer, yes, certainly | 14:49 |
| niemeyer | fwereade__: Cool, thanks | 14:49 |
| niemeyer | fwereade__: (to me there's value in things not being special :-) | 14:49 |
| niemeyer | So, where were we.. | 14:49 |
| niemeyer | 2c was last I think | 14:50 |
| niemeyer | Ah, and we didn't yet answer it | 14:50 |
| niemeyer | fwereade__: People should be able to write requirer hooks for juju-info relations | 14:50 |
| fwereade__ | niemeyer, my feeling still leans toward "no" -- the idea of juju-info, in particular, is that it's what yu relate to when the other charm doesn't know anything about you | 14:51 |
| fwereade__ | niemeyer, ok, yu mean relations with the juju-info interface, not the name, right? | 14:51 |
| niemeyer | fwereade__: Yes | 14:51 |
| fwereade__ | niemeyer, I have no arguments there | 14:51 |
| fwereade__ | niemeyer, but that will not be a hook called juju-info-anything | 14:51 |
| niemeyer | fwereade__: -1 as well on juju-info *provider* hooks | 14:51 |
| fwereade__ | niemeyer, it might be called, say, principal-info-something | 14:52 |
| niemeyer | fwereade__: I don't think the name of the hook matters much | 14:52 |
| niemeyer | fwereade__: It could be called foo-relation-joined and still be a juju-info hook | 14:52 |
| fwereade__ | niemeyer, ok, I am thinking from the name perspective here, because those are the things that can lead to collisions | 14:52 |
| niemeyer | fwereade__: We've already decided on the name | 14:53 |
| niemeyer | fwereade__: I'm talking about relation hooks that respond to relations with the juju-info interface | 14:53 |
| fwereade__ | niemeyer, let me restate what I'm wondering | 14:53 |
| fwereade__ | niemeyer, given the relation naming restrictions, would it be ok for us to just declare the whole juju namespace in the hooks dir out of bounds? | 14:54 |
| fwereade__ | niemeyer, if we *don't* then we run the risk of one of those names matching a future hook and firing as a hook when it's not expected | 14:54 |
| fwereade__ | niemeyer, that is always a risk with any file in that dir to be fair | 14:55 |
| niemeyer | fwereade__: That doesn't look like 2c | 14:55 |
| fwereade__ | niemeyer, ok, smaller question | 14:56 |
| fwereade__ | niemeyer, is it ever sane to have a file named "juju-info-relation-joined" in your hooks dir? | 14:56 |
| niemeyer | fwereade__: It does the exact same thing as a file named can-I-has-catz | 14:56 |
| fwereade__ | niemeyer, how do we stop it from running? special-casing in the uniter? | 14:58 |
| niemeyer | fwereade__: Why would we have to special case? | 14:58 |
| niemeyer | fwereade__: It does absolutely nothing.. there's nothing interesting about that name | 14:58 |
| fwereade__ | niemeyer, it will be executed when the provider joins the relation, won't it? | 14:58 |
| fwereade__ | niemeyer, unless we explicitly avoid running all such hooks | 14:59 |
| niemeyer | fwereade__: Aha, okay.. | 14:59 |
| niemeyer | <niemeyer> fwereade__: -1 as well on juju-info *provider* hooks | 14:59 |
| niemeyer | fwereade__: So you want to avoid these hooks by scanning the directory and banning everything hooks/juju*? | 15:01 |
| fwereade__ | niemeyer, essentially, yes | 15:01 |
| fwereade__ | niemeyer, or possibly explicitly ignoring them in the uniter | 15:02 |
| fwereade__ | niemeyer, either way smacks of icky special-casing, not sure which is worse | 15:02 |
| niemeyer | fwereade__: That sounds like a good idea | 15:02 |
| niemeyer | fwereade__: I think we should do better, in fact | 15:03 |
| niemeyer | fwereade__: Ban *all* unwanted files from hooks/* | 15:03 |
| niemeyer | fwereade__: We can't do that in the short term, but we should start warning people about that asap | 15:03 |
| fwereade__ | niemeyer, hmmmmmmm a lot of people use a nunch of symlinks to a single implementation file | 15:03 |
| niemeyer | fwereade__: That works, as long as the implementation file is one of the hooks | 15:03 |
| fwereade__ | niemeyer, can't remember offhand, but I'm not sure it is | 15:04 |
| niemeyer | fwereade__: Understood.. I'm sure it'll break what people do right now | 15:04 |
| fwereade__ | niemeyer, (in general, in the cases I've seen...) | 15:04 |
| niemeyer | fwereade__: Which is why we cannot push in the short term, but can start warning asap | 15:04 |
| fwereade__ | niemeyer, ok, regardless this is a direction statement of which I approve, I will add some deprecation warnings | 15:04 |
| fwereade__ | niemeyer, and also explicitly skip juju-* "hooks" in the uniter, I guess? | 15:05 |
| niemeyer | fwereade__: It avoids the future-hooks issue, and establishes a good convention on which the juju* ban works | 15:05 |
| niemeyer | fwereade__: I'd prefer to explicitly forbid *those* hooks right away | 15:06 |
| niemeyer | fwereade__: The uniter is too late | 15:06 |
| niemeyer | fwereade__: It'll blow people up way down the pipeline | 15:06 |
| fwereade__ | niemeyer, ok, SGTM -- error on Read hooks/juju-*; warning on Read hook/anything-not-referenced-elsewhere? | 15:06 |
| niemeyer | fwereade__: +1 | 15:07 |
| fwereade__ | niemeyer, ok, great | 15:07 |
| niemeyer | fwereade__: Wait, hmm.. | 15:07 |
| niemeyer | fwereade__: There are forward compatibility issues I thnk | 15:07 |
| niemeyer | fwereade__: It'd mean an old juju version cannot deploy any charms that expose a new hook implementation | 15:08 |
| fwereade__ | niemeyer, hmm | 15:08 |
| niemeyer | fwereade__: We don't have to solve that now | 15:09 |
| niemeyer | fwereade__: Let's agree on what seems clear: no hooks/juju* | 15:09 |
| fwereade__ | niemeyer, perfect | 15:09 |
| niemeyer | Awesome | 15:09 |
| niemeyer | 2c) Check | 15:10 |
| niemeyer | 2d) Block them when reading? | 15:10 |
| fwereade__ | niemeyer, +1 | 15:10 |
| niemeyer | Cool | 15:10 |
| fwereade__ | niemeyer, 2e, 2f covered | 15:10 |
| niemeyer | 2e) Definitely not | 15:10 |
| fwereade__ | niemeyer, no, block when reading | 15:10 |
| niemeyer | Cool | 15:10 |
| niemeyer | 3 | 15:10 |
| niemeyer | 3a) Yes | 15:11 |
| fwereade__ | niemeyer, note that we should be careful about charm store releases once we've tightened these up | 15:11 |
| niemeyer | fwereade__: Yeah, I think it's okay | 15:12 |
| niemeyer | fwereade__: But we'll see | 15:12 |
| fwereade__ | niemeyer, at least the 2 footnoted charms will be refused, and probably others | 15:12 |
| niemeyer | fwereade__: 2b) I don't understand the point | 15:12 |
| niemeyer | fwereade__: Probably lost on "charm URLs match are for" | 15:13 |
| fwereade__ | niemeyer, er, I apparently cannot haz craggar | 15:13 |
| fwereade__ | er, grammer :/ | 15:13 |
| fwereade__ | GAAAH | 15:13 |
| * fwereade__ takes a deep breath | 15:13 | |
| niemeyer | :) | 15:14 |
| fwereade__ | niemeyer, ISTM that the right way to accomplish 3a is to Assert that the service's charms are the same charms we used to determine that the endpoint list was OK | 15:14 |
| fwereade__ | niemeyer, it shouldn't in itself be controversial, it's just setting up 3c | 15:14 |
| niemeyer | fwereade__: I don't think that's the case | 15:14 |
| fwereade__ | niemeyer, cool, go on | 15:15 |
| niemeyer | fwereade__: I think I see what you mean, actually, and agree | 15:16 |
| fwereade__ | niemeyer, ah, ok, great | 15:16 |
| niemeyer | fwereade__: We need to assert that the charm still has the relation | 15:16 |
| niemeyer | fwereade__: There's a red-herring in that description regarding the charm URL not having changed, which isn't the case, but it doesn't matter | 15:17 |
| fwereade__ | niemeyer, please explain, I don;t see it | 15:17 |
| niemeyer | fwereade__: "charm URLs match are for the | 15:18 |
| niemeyer | charms from which those endpoints have been determined" | 15:18 |
| niemeyer | fwereade__: The determination of the endpoints is done at time T1.. the adding of relation is done at T2 | 15:18 |
| fwereade__ | niemeyer, ISTM that the services' charm urls (and lifes) are exactly what we need to assert are what we expect | 15:18 |
| fwereade__ | niemeyer, agree | 15:19 |
| niemeyer | fwereade__: Things may change in between.. the important fact is that at T2 the relation is still sane | 15:19 |
| fwereade__ | niemeyer, ok, indeed, we probably do want to retry the validation in that case | 15:19 |
| niemeyer | fwereade__: Cool, in sync again | 15:19 |
| niemeyer | So, 3b check | 15:20 |
| fwereade__ | niemeyer, yep | 15:20 |
| niemeyer | fwereade__: 3c) Doesn't seem entirely the case, for the reasons described | 15:21 |
| fwereade__ | niemeyer, for the first attempt, it does seem wrong to redo the work we just did | 15:21 |
| niemeyer | fwereade__: I'm not entirely comfortable with changing what an Endpoint is because of that minor need | 15:22 |
| niemeyer | fwereade__: and endpoint is a high-level description of one side of the relation | 15:23 |
| niemeyer | fwereade__: It's not bound to any charm | 15:23 |
| fwereade__ | niemeyer, yes, but we can see very neatly whether or not it will apply to a given charm | 15:23 |
| Aram | uniter tests fail because of: | 15:23 |
| Aram | [LOG] 4.30775 JUJU git command failed: exit status 1 | 15:23 |
| Aram | path: /tmp/gocheck-894385949183117216/0/agents/unit-u-0/charm | 15:23 |
| Aram | args: []string{"pull", "/tmp/gocheck-894385949183117216/0/agents/unit-u-0/state/deployer/current"} | 15:23 |
| Aram | M.juju-charm | 15:23 |
| Aram | Udata | 15:23 |
| Aram | Mhooks/start | 15:23 |
| Aram | Aignore | 15:23 |
| Aram | Mrevision | 15:23 |
| Aram | anybody seen this? | 15:23 |
| Aram | this is from trunk | 15:23 |
| fwereade__ | niemeyer, this is actually maybe the point at which things will be clearest if you read to the end and then ask questions again | 15:23 |
| fwereade__ | Aram, grar, would you paste me the full test output? | 15:24 |
| Aram | ok | 15:24 |
| fwereade__ | Aram, I suspect my unracing in a particular step was not as good as it might have been | 15:24 |
| fwereade__ | niemeyer, it's definitely the part I am least certain about | 15:24 |
| niemeyer | fwereade__: Yeah, I understand.. it seems to do exactly what 3c suggests | 15:27 |
| niemeyer | fwereade__: IOW, associate an endpoint with a charm | 15:27 |
| niemeyer | fwereade__: This makes the model more complex in a few different ways | 15:27 |
| fwereade__ | niemeyer, *optionally* do so, but yes | 15:27 |
| niemeyer | fwereade__: Not optionally.. always.. except we now have *two* endpoint types, so we must be qualifying them | 15:27 |
| niemeyer | fwereade__: All seems like changing something clear into something that requires further effort to understand and communicate | 15:28 |
| niemeyer | fwereade__: The need you expose seems relevant | 15:28 |
| niemeyer | fwereade__: But I think we can solve the need without refactoring what an endpoint means | 15:28 |
| niemeyer | fwereade__: In the short term, it sounds a lot easier to move forward by simply having AddRelation fail if the endpoints don't exist at the transaction time | 15:30 |
| fwereade__ | niemeyer, ok... | 15:30 |
| fwereade__ | niemeyer, the proposal also I think incorporates an additional perspective that I didn't mention | 15:30 |
| niemeyer | fwereade__: That's the common denominator of all of the points and interface changes, I think, so having that encapsulated under that one operation feels like a significant win | 15:31 |
| fwereade__ | niemeyer, which is that I think I will be wanting to validate endpoints against *deployed* charms | 15:32 |
| niemeyer | fwereade__: Sounds sane | 15:33 |
| fwereade__ | niemeyer, I think that endpoint matching/checking go very well together with charms | 15:33 |
| fwereade__ | niemeyer, without having to involve state | 15:33 |
| niemeyer | fwereade__: charm.HasEndpoint(endpoint)? | 15:34 |
| fwereade__ | niemeyer, nearly -- a container-scoped one should match a global one that the charm declares | 15:34 |
| fwereade__ | niemeyer, actually yeah HasEndpoint covers that | 15:34 |
| fwereade__ | niemeyer, the thinking is generally that this block of data, excluding the service name, appears to be relevant and useful in the charm package on its own | 15:35 |
| niemeyer | fwereade__: I don't think so, unless you change what an endpoint is | 15:35 |
| niemeyer | fwereade__: The concept of "endpoint" began its life as that "service:relationname" we use in the command line | 15:36 |
| niemeyer | fwereade__: To represent one side of the relation in an unambiguous way | 15:36 |
| fwereade__ | niemeyer, hm, fair enough -- maybe I'm asking for a rethink of charm.Relation instead? | 15:37 |
| fwereade__ | niemeyer, which lacks Role and something else | 15:37 |
| niemeyer | fwereade__: I don't know.. I don't know what we're after | 15:37 |
| fwereade__ | niemeyer, I think it would be very useful to have a type, regardless of its name, which I could use with charms to determine what charms can talk to what other charms | 15:38 |
| fwereade__ | niemeyer, at the moment RelationEndpoint roughly givesus that, but the service name is a distraction from that POV | 15:39 |
| niemeyer | fwereade__: Can we cover the problem we're trying to solve first? | 15:39 |
| fwereade__ | niemeyer, I would like to be able to manipulate implementations of charm.Charm in such a way as to be able to easily ask questions about what can relate to what | 15:41 |
| niemeyer | fwereade__: This is still talking about the API you want.. can we talk about the *problem* first? | 15:41 |
| Aram | fwereade__: http://paste.ubuntu.com/1285248/ | 15:41 |
| Aram | fwereade__: only one test failure in that log, if I run it without piping in a file I get more errors, if I pipe in a file I get only one error, or no failure at all. | 15:41 |
| fwereade__ | niemeyer, the problem is charm upgrades | 15:42 |
| niemeyer | fwereade__: Okay.. what happens with charm upgrades? | 15:42 |
| niemeyer | fwereade__: The uniter has a single local charm that is deployed, and an upgrade candidate | 15:42 |
| niemeyer | fwereade__: What do we have to do about that/ | 15:42 |
| niemeyer | ? | 15:42 |
| fwereade__ | niemeyer, I'm more thinking of a charm that has *not* yet been upgraded; detecting a relation that was added to the service since the service was upgraded, but which the local charm does not know about | 15:43 |
| fwereade__ | niemeyer, I don't think the uniter needs to worry about upgrades | 15:43 |
| fwereade__ | niemeyer, the idea is that we don't even allow upgrades if they would break relations that currently exist | 15:44 |
| fwereade__ | niemeyer, but that, when we see a relation, we have no guarantee it's not for a newer version of the charm, to which we have not yet upgraded | 15:44 |
| fwereade__ | niemeyer, and so by comparing the ... endpoint ... of the relation against the current charm we can know we shouldn't actually enter | 15:45 |
| fwereade__ | niemeyer, so I would like a Thing representing the relation-from-charm-perspective, or endpoint-but-not-about-service, or whatever we call it -- that Name/interface/Role/Scope quartet | 15:47 |
| niemeyer | fwereade__: Okay.. so the goal is knowing that the established relation is not in fact known to the current charm, even though it's known to the service | 15:47 |
| fwereade__ | niemeyer, yes | 15:47 |
| niemeyer | fwereade__: Awesome, thanks | 15:47 |
| fwereade__ | niemeyer, (and also, taking a charm and determining what ... endpoints ... it exposes) | 15:47 |
| niemeyer | fwereade__: So how do we guarantee that? | 15:47 |
| fwereade__ | niemeyer, sorry about the vocab, it's just that endpoint STM to be the losest word we have to the thing I'm trying to describe | 15:48 |
| niemeyer | fwereade__: Let's pleast not loose it | 15:48 |
| niemeyer | fwereade__: We have a well defined meaning for endpoint | 15:48 |
| fwereade__ | niemeyer, yep, ok | 15:48 |
| niemeyer | fwereade__: Charms don't have endpoints.. they have relation names to uniquely identify the relation | 15:48 |
| fwereade__ | niemeyer, the other word is "relation", which is unhelpful in this context because the name relation is more tightly bound to state in my mind than it is t charm | 15:49 |
| fwereade__ | niemeyer, but it may be what we're after | 15:49 |
| fwereade__ | niemeyer, Peers/Provides/Requires are all map[string]Relation | 15:49 |
| niemeyer | fwereade__: Interesting | 15:49 |
| niemeyer | fwereade__: Okay | 15:50 |
| fwereade__ | niemeyer, the field and the key supply those 2 pieces of information | 15:50 |
| niemeyer | fwereade__: It's certainly not ideal, and I don't blame you for the confusion at all | 15:50 |
| niemeyer | fwereade__: I'm not clear enough myself | 15:50 |
| fwereade__ | niemeyer, but the Relation type itself feels like it would be more useful if it included them | 15:50 |
| niemeyer | fwereade__: Back to the point, though | 15:50 |
| fwereade__ | niemeyer, possible restatement: the unit of compatibility is the charm, not the service, and I am currently very interested in compatibility | 15:51 |
| niemeyer | fwereade__: How do we tell if a charm supports a relation that is compatible with what the state service is telling us? | 15:51 |
| niemeyer | fwereade__: What's the info that tells us whether we're good to go or not? | 15:51 |
| fwereade__ | niemeyer, maybe interface and role is all we *need* there? | 15:52 |
| niemeyer | fwereade__: We must take the name in consideration too | 15:52 |
| fwereade__ | niemeyer, ha, yes indeed, they need to match | 15:52 |
| niemeyer | fwereade__: Imagine cache-db vs. data-db | 15:52 |
| fwereade__ | niemeyer, I'm not clear on scope for some reason | 15:53 |
| fwereade__ | niemeyer, I don't think that's an issue of charm compatibility, I think that is a service-level thing | 15:53 |
| niemeyer | fwereade__: I think it matters too | 15:53 |
| niemeyer | fwereade__: If nothing else, because it means what is *established* needs to change | 15:54 |
| fwereade__ | niemeyer, ah ok at runtime? | 15:54 |
| niemeyer | fwereade__: Yes, I'm still keeping the problem statement in mind: | 15:54 |
| niemeyer | <niemeyer> fwereade__: Okay.. so the goal is knowing that the established relation is not in fact known to the current charm, even though it's known to the service | 15:54 |
| fwereade__ | niemeyer, feels like we just shouldn't allow upgrades that change the meanings of established relations at all | 15:55 |
| niemeyer | fwereade__: +1 | 15:55 |
| === hazmat is now known as kapilt | ||
| fwereade__ | niemeyer, (determining that is another use for the cabability I am touting) | 15:56 |
| niemeyer | fwereade__: And by established we mean non-Dead/removed | 15:56 |
| fwereade__ | niemeyer, yep | 15:56 |
| niemeyer | Awesome | 15:56 |
| niemeyer | fwereade__: So, problem solved? | 15:56 |
| niemeyer | fwereade__: Hmm.. no | 15:57 |
| niemeyer | fwereade__: Because we can still establish a new relation | 15:57 |
| fwereade__ | niemeyer, dunno -- you seem to be implicitly agreeing that the Name/Iface/Role/Scope quartet may be a sensible data type for several situations, but I'm not actually sure yu are | 15:57 |
| fwereade__ | niemeyer, ah yeah -- we can establish a new relation while old charms are still not upgraded | 15:58 |
| niemeyer | fwereade__: Uh.. I'm not agreeing or disagreeing with that | 15:58 |
| niemeyer | fwereade__: I'm still trying to see what is the problem we have and solve it | 15:58 |
| niemeyer | fwereade__: So what we use to determine if a relation is known to the current charm, so that it may be established, is its <name,iface,role,scope>... okay | 15:59 |
| fwereade__ | niemeyer, the problem is that we need to do compatibility-checking things with charms in several situations: determining possible endpoints; determining valid charm upgrades; ensuring sanity in an edge case on the uniter | 15:59 |
| niemeyer | fwereade__: I'm still trying to solve one single problem | 16:00 |
| fwereade__ | niemeyer, I am looking for APIs that makes sense for all these needs, which feel like different applications of what should be the same tools | 16:00 |
| niemeyer | fwereade__: Sorry, I'm slow.. | 16:00 |
| niemeyer | fwereade__: I cannot cover all needs at once.. we just determined that there should be no API changes at all for adding a relation | 16:01 |
| niemeyer | fwereade__: Now there's another case that I'm trying to follow up with you | 16:01 |
| niemeyer | <niemeyer> fwereade__: So what we use to determine if a relation is known to the current charm, so that it may be established, is its <name,iface,role,scope>... okay | 16:02 |
| fwereade__ | niemeyer, sorry, wait, I'm not sure I did agree with that 100% -- I agreed that RelationEndpoint is the right data to keep in state, not that it's the best way to express our desires to AddRelation | 16:02 |
| fwereade__ | niemeyer, I'm really not trying to be difficult here | 16:03 |
| niemeyer | fwereade__: That's not how it feels | 16:03 |
| fwereade__ | niemeyer, the difficulty is in relations that do not correspond to those declared in the charm | 16:04 |
| niemeyer | fwereade__: Sounds good.. I was trying to get the context for that statement, and just now I think I'm understanding what you're trying to do | 16:05 |
| niemeyer | fwereade__: When we add a relation, we do so against the latest charm | 16:05 |
| fwereade__ | niemeyer, sorry, I'm still feeling my way around it myself | 16:05 |
| niemeyer | fwereade__: that is associated with the services | 16:05 |
| niemeyer | fwereade__: We prevent upgrades that modify established relations | 16:06 |
| niemeyer | fwereade__: Which gives us a guarantee that any unit that has an *established* relation, has a charm with that specific relation matching that of the tip charm associated with the service | 16:07 |
| niemeyer | fwereade__: Which is comfortable and good and sane | 16:07 |
| fwereade__ | niemeyer, yes, agreed | 16:07 |
| niemeyer | fwereade__: What we cannot guarantee, though, is that when we establish a *new* relation, that relation may be established by all running units that are not up-to-date with the latest charm | 16:08 |
| fwereade__ | niemeyer, with a slight wrinkle in the case of the provider relation named juju-info, which is not declared explicitly by any charm, and it's not clear where it comes from | 16:08 |
| fwereade__ | niemeyer, yes, agreed | 16:08 |
| niemeyer | fwereade__: The important fact here, then, is that a *new* relation that was established may be *incompatible* with the charm the uniter is running, and compatibility as we agreed is determined by <name,iface,role,scope> | 16:09 |
| fwereade__ | niemeyer, yes, agreed | 16:10 |
| niemeyer | fwereade__: Awesome | 16:10 |
| niemeyer | fwereade__: Another important factor that is a consequence of some of these agreements, is that once we observe a relation in state, we have the guarantee that as long as that relation exists, it will remain compatible with the tip charm, whatever that charm is | 16:11 |
| fwereade__ | niemeyer, yes indeed | 16:11 |
| fwereade__ | niemeyer, (I *think* that actually *some* scope changes are safe... if the only existing relation is itself a downscoped global relation, it's safe for the underlying relation to go from global to container) | 16:14 |
| fwereade__ | niemeyer, but that is just a detail | 16:14 |
| niemeyer | fwereade__: The problem feels straightforward then.. | 16:15 |
| niemeyer | fwereade__: endpoint := relation.Endpoint(service) ; if endpoint supported by local charm { move on } | 16:16 |
| fwereade__ | niemeyer, agreed... | 16:17 |
| fwereade__ | niemeyer, the code I am trying to discuss is the " if endpoint supported by local charm" bit | 16:17 |
| fwereade__ | niemeyer, which is the same sort of question I will be asking about various "endpoints" and charms in several situations | 16:18 |
| niemeyer | fwereade__: Sorry, I thought that was part of the coverage above | 16:19 |
| niemeyer | fwereade__: ... and compatibility as we agreed is determined by <name,iface,role,scope> | 16:19 |
| niemeyer | fwereade__: endpoint.SupportedBy(charm) comparing <name,iface,role,scope>? | 16:20 |
| fwereade__ | niemeyer, ok, which we do not have collected into a handy type, other than RelationEndpoint, which has an extraneous service name -- if it didn't have that, it would live very happily as a type in the charm package | 16:21 |
| niemeyer | fwereade__: It's not extraneous.. it's part of the definition of what an endpoint is since we first used the endpoint term | 16:21 |
| niemeyer | fwereade__: and by charm I really mean *state.Charm | 16:22 |
| niemeyer | fwereade__: Or at least the charm interface | 16:22 |
| fwereade__ | niemeyer, why *state.Charm? all we *should* need to answer the important questions is charm.Charm | 16:23 |
| niemeyer | fwereade__: Which might work with both | 16:23 |
| fwereade__ | niemeyer, | 16:23 |
| fwereade__ | niemeyer, yeah, in fact it's just Meta() I think | 16:23 |
| niemeyer | fwereade__: Cool.. charm.Charm still feels good, though | 16:23 |
| fwereade__ | niemeyer, it does! | 16:23 |
| niemeyer | fwereade__: For docs, if nothing else | 16:23 |
| fwereade__ | niemeyer, and being able to answer these sorts of questions in the charm package feels good too :) | 16:23 |
| niemeyer | fwereade__: Feels irrelevant to any problem stated so far | 16:24 |
| fwereade__ | niemeyer, all the data is already available in the charm package... all the questions are purely about charm relation compatibility, divorced from service... it's just that we don't have a handy type in the charm package expressing it | 16:26 |
| fwereade__ | niemeyer, this seems strange to me | 16:27 |
| niemeyer | fwereade__: There are only so many battles we can win at a time | 16:27 |
| fwereade__ | niemeyer, when I consider what that type should look like, I see that it bears notable similarities to -- but is not the same as -- RE | 16:27 |
| niemeyer | fwereade__: If all we need is a trivial method on state.RelationEndpoint to say whether it is compatible with a charm or not, I don't see why we to break down the concept of endpoint we have today, split types, change the charm package, etc etc | 16:28 |
| fwereade__ | niemeyer, and a way to get all those endpoints from charms | 16:29 |
| niemeyer | fwereade__: Why? | 16:29 |
| niemeyer | fwereade__: I haven't seen that need so far | 16:29 |
| fwereade__ | niemeyer, add-relation foo bar | 16:29 |
| niemeyer | fwereade__: yes? | 16:30 |
| fwereade__ | niemeyer, we need to go through all possible combinations to determine whether or not it's ambiguous | 16:31 |
| niemeyer | fwereade__: Yes, and that's in state | 16:31 |
| niemeyer | fwereade__: Because all of the data this applies against is in state | 16:31 |
| niemeyer | fwereade__: endpoints, err := state.InferEndpoints("foo", "bar") | 16:32 |
| niemeyer | fwereade__: relation, err := state.AddRelation(endpoints) | 16:32 |
| niemeyer | fwereade__: Sorry, I'm starving.. will be back soon | 16:34 |
| fwereade__ | niemeyer, so at the very least we need to get the service twice and the charm twice for every service in a relation? | 16:34 |
| fwereade__ | niemeyer, np, might be a little longer myself | 16:34 |
| fwereade__ | niemeyer, ttyl | 16:35 |
| === kapilt is now known as hazmat | ||
| * wrtp is off for the evening. night all. | 17:53 | |
| niemeyer | wrtp: Night | 17:55 |
| wrtp | niemeyer: please can we have a discussion about tls certs tomorrow... | 18:14 |
| niemeyer | wrtp: Of course | 18:14 |
| === andrewsmedina is now known as fuicomprarumciga | ||
| fwereade__ | niemeyer, tyvm for reviews | 21:01 |
| fwereade__ | niemeyer, sorry that one was still a bit scrappy | 21:02 |
| fwereade__ | niemeyer, and fwiw I don't feel a strong need to pursue the not-actually-Endpoints discussion -- in initial sketches the code seemed to be telling me it wanted to do that, but there's nothing fundamentally wrong with keeping the functionality in state, and I will try to cast it from my mind ;) :-) | 21:04 |
| fwereade__ | niemeyer, ty for valuable discussion earlier :) | 21:05 |
| niemeyer | fwereade__: It was my pleasure | 21:18 |
| niemeyer | fwereade__: Also excited about the rest of the code | 21:18 |
| niemeyer | fwereade__: Lots of good stuff, and not much to change | 21:19 |
| fwereade__ | niemeyer, excellent :) | 21:19 |
| fwereade__ | niemeyer, a thought: is a container-scoped peer relation ever valid? | 21:27 |
| niemeyer | fwereade__: Wow.. | 21:28 |
| * niemeyer thinks | 21:28 | |
| fwereade__ | niemeyer, maybe with multi-endpoint peers it would be... although it sort of makes my brain hurt a little | 21:30 |
| fwereade__ | niemeyer, it actually sounds icky enough that I'd like to forbid it, and we can consider the implications at a later date if anyone wants to use to use it for anything | 21:31 |
| fwereade__ | niemeyer, I can't imagine any use for a container-scoped peer relation, even there, thant isn't better addressed as a separate pro/req relation | 21:33 |
| fwereade__ | niemeyer, ofc, my imagination is limited ;) | 21:33 |
| niemeyer | fwereade__: I think it'd be pretty bizarre | 21:33 |
| niemeyer | fwereade__: THe only way it could happen is to have two subordinates of the same type | 21:34 |
| niemeyer | fwereade__: Since naturally we cannot have two principals in the same container | 21:34 |
| fwereade__ | niemeyer, which I guess is not impossible, but pretty damn weird | 21:34 |
| niemeyer | fwereade__: Yeah | 21:34 |
| niemeyer | fwereade__: I'm not sure if we should prevent it actively, though | 21:35 |
| niemeyer | fwereade__: If we have to special case it to prevent, I'd say let's do nothing | 21:35 |
| niemeyer | fwereade__: If we have to special case to support, I'd say let's not support it | 21:35 |
| fwereade__ | niemeyer, sgtm, ++less-code | 21:36 |
| fwereade__ | niemeyer, btw, I was also just wondering if we really want to scan the hooks dir every time we read a charm... maybe it would be cleaner to check at bundle time? | 21:38 |
| fwereade__ | niemeyer, sorry, context is for disallowing juju* files in the hooks dir | 21:38 |
| fwereade__ | niemeyer, assuming that every charm we run has passed through a bundling stage does not seem unreasonable | 21:39 |
| fwereade__ | niemeyer, but maybe it's not sensible, they are just zip files | 21:40 |
| niemeyer | fwereade__: Hmm | 21:40 |
| niemeyer | fwereade__: Yeah | 21:40 |
| fwereade__ | niemeyer, scan-every-read then? | 21:43 |
| niemeyer | fwereade__: Sounds fine | 21:44 |
| fwereade__ | niemeyer, yeah, could be worse ;p | 21:44 |
| niemeyer | fwereade__: True :) | 21:45 |
| fwereade__ | niemeyer, I'm going to bed, but https://codereview.appspot.com/6713057/ should be nice and simple | 22:32 |
| niemeyer | fwereade__: Thanks much | 23:15 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!