| rogpeppe | davecheney: ping | 00:08 |
|---|---|---|
| mramm | rogpeppe: hey, you still around? | 00:16 |
| rogpeppe | no | 00:16 |
| rogpeppe | mramm: not really. it's late and i'm summoned. | 00:16 |
| mramm | ahh | 00:16 |
| mramm | ok | 00:16 |
| mramm | have a great evening | 00:16 |
| TheMue | Morning. | 07:42 |
| fwereade_ | heya TheMue | 07:59 |
| TheMue | fwereade_: Hi William | 08:02 |
| TheMue | fwereade_: You know http://hackingdistributed.com/2013/01/29/mongo-ft/? | 08:12 |
| fwereade_ | TheMue, haven't read that one tbh | 08:15 |
| TheMue | fwereade_: It's about MongoDB replication and how this can lead to problems. | 08:16 |
| fwereade_ | TheMue, it does not look unfamiliar though | 08:16 |
| fwereade_ | TheMue, most of it seems to be the usual whining about default settings | 08:17 |
| fwereade_ | TheMue, maybe I should read more closely? | 08:17 |
| TheMue | fwereade_: I'm also not through with it. It only attracted my attention due to mongo. | 08:18 |
| fwereade_ | TheMue, it kinda seems that there's a bit of a backlash against mongo going on at the moment, which is fine, it's the usual cycle of new tech | 08:19 |
| fwereade_ | TheMue, 1) it's the greatest thing ever and it solves all your problems! nosql!!!!!11!1! | 08:19 |
| fwereade_ | TheMue, 2) it's the worst thing ever and will destroy your life!!!!11!1! | 08:20 |
| fwereade_ | TheMue, 3) it's a tool and choosing to use it involves tradeoffs | 08:20 |
| TheMue | fwereade_: Well known as Gardner hype cycle ;) | 08:20 |
| fwereade_ | TheMue, yeah, indeed -- I just think we're in phase 2 re mongo at the moment | 08:21 |
| fwereade_ | TheMue, this is not to say that there will not be challenges wrtreplication | 08:21 |
| TheMue | fwereade_: I'm only interested in well known traps we can avoid in our further mongo usage. | 08:22 |
| fwereade_ | TheMue, yeah, it will be interesting trying to tune it as our needs grow | 08:22 |
| TheMue | fwereade_: If others detected probs and discovered ways to avoid them why not use their knowledge. ;) One way of re-use. | 08:23 |
| fwereade_ | TheMue, at the moment I mostly have the worst-case characteristics of mgo/txn on my mind :) | 08:23 |
| TheMue | fwereade_: Sure, wrt to scaling and HA it will get interesting. | 08:23 |
| TheMue | fwereade_: Yeah, you yesterday mentioned it. | 08:23 |
| TheMue | fwereade_: Would like to see a little paper with your current thoughts of possible probs, so that we can investigate in parallel and put our discoveries, thoughts etc into that paper. | 08:25 |
| fwereade_ | TheMue, wrt that particular article I look forward to his followup where he talks about subtle problems with replication | 08:26 |
| TheMue | fwereade_: Yeo | 08:27 |
| TheMue | Yep | 08:27 |
| fwereade_ | TheMue, my own concerns remain somewhat theoretical | 08:28 |
| TheMue | fwereade_: But still interesting as they exist. | 08:28 |
| TheMue | fwereade_: I would like to see my technical lead w/o concerns. :D | 08:29 |
| fwereade_ | TheMue, it's basically concern over precisley how txn sync points can propagate across the collections | 08:29 |
| fwereade_ | TheMue, I think the really interesting problem is service destruction | 08:29 |
| fwereade_ | TheMue, the way it's written now has some good properties and some bad ones and I don't know which will predominate in real usage scenarios | 08:30 |
| TheMue | fwereade_: So maybe we should start use case oriented. First UC: service destruction, below a short description on how on high level it works and then drilling down into how the DB is involved and which probs you might expect. | 08:31 |
| fwereade_ | TheMue, that is not an unreasonable request | 08:31 |
| TheMue | fwereade_: If the result shows that there's no problem that's the best we can get. ;) | 08:33 |
| fwereade_ | TheMue, well, just because I can't think of a problem doesn't mean it won't exist ;p | 08:33 |
| fwereade_ | TheMue, the trouble with documenting things is that the cost/benefit calulation is really simple | 08:34 |
| fwereade_ | TheMue, s/really/rarely/ | 08:34 |
| fwereade_ | TheMue, writing good docs is expensive re time; the docs quickly become out of date anyway; and there is also a strong tendency for developer docs to be write-only for some reason | 08:35 |
| fwereade_ | TheMue, I am firmly +1 on writing design specs | 08:35 |
| rogpeppe | fwereade_, TheMue: do you want to continue that meeting? | 08:36 |
| rogpeppe | (morning, BTW!) | 08:36 |
| TheMue | rogpeppe: Morning | 08:36 |
| fwereade_ | rogpeppe, TheMue: yeah, we probably should, would one of you start a hangout? I'll be there in 5 | 08:36 |
| TheMue | rogpeppe: Yep | 08:36 |
| rogpeppe | ok | 08:36 |
| TheMue | fwereade_: You read my mail about docs this morning? | 08:36 |
| rogpeppe | https://plus.google.com/hangouts/_/ba4d2795ce2498036f225614a2b0a488040d635f?authuser=0&hl=en-GB | 08:38 |
| fwereade_ | TheMue, yeah, the things I was just saying are closely connected | 08:40 |
| fwereade_ | TheMue, we could maybe touch on it live as well | 08:40 |
| fwereade_ | rogpeppe, TheMue, omw back | 10:44 |
| dimitern | https://plus.google.com/hangouts/_/8fe5a151e983bdd6459913720de0cc4817216bc5 | 11:58 |
| * niemeyer joins | 11:58 | |
| niemeyer | dimitern: I assume this is the constraint discussion? | 11:58 |
| dimitern | niemeyer: yes it is | 11:58 |
| fwereade_ | niemeyer, dimitern: I hope so | 11:58 |
| niemeyer | Mornings, btw! :-) | 11:58 |
| niemeyer | fwereade_, dimitern: Can you please invite the other me | 11:59 |
| * fwereade_ seems to be the only one in there | 11:59 | |
| dimitern | niemeyer: morning | 11:59 |
| dimitern | so that's not the one | 11:59 |
| dimitern | jam's creating a new one and will post a link | 11:59 |
| jam | https://plus.google.com/hangouts/_/1b96582d8713f383ef4b1477073f236fa504e77d?authuser=2&hl=en | 11:59 |
| niemeyer | jam: Can you please invite the other me? | 12:00 |
| TheMue | jam: Same here | 12:00 |
| jam | If I missed anyone, please just poke me, if the above link doesn't work automatically | 12:01 |
| === otubo1 is now known as otubo | ||
| rogpeppe | darn, i missed all the above reminders | 12:49 |
| rogpeppe | fwereade_: can you point me to the original constraints discussion document (where the constraint semantics were laid out) | 13:48 |
| rogpeppe | ? | 13:48 |
| rogpeppe | fwereade_: i'm relying on possibly dubious memory of what was arrived at | 13:48 |
| fwereade_ | rogpeppe, I think it's in the juju-doc project somewhere, let me poke around a bit | 13:49 |
| rogpeppe | fwereade_: ah! this one: https://juju.ubuntu.com/docs/constraints.html | 13:50 |
| fwereade_ | rogpeppe, that's not the spec I remember, it's the polished-up-for-users docs | 13:51 |
| fwereade_ | rogpeppe, but maybe that's what it evolved into | 13:51 |
| rogpeppe | fwereade_: yeah, i remember a different document too | 13:52 |
| rogpeppe | fwereade_: but that's good for going on with - it documents the user expectations which is probably the most important thing | 13:52 |
| fwereade_ | rogpeppe, actually, I think it is roughly the same | 14:00 |
| fwereade_ | rogpeppe, if you do a deep dive in deleted bits of the juju source itself you'll find earlier versions | 14:00 |
| rogpeppe | fwereade_: ok, cool | 14:00 |
| rogpeppe | fwereade_: are there any constraints that, when added, *increase* the number of machines available for allocation, rather than narrowing down the selection? | 14:20 |
| fwereade_ | rogpeppe, hmm, not according to my mental model -- wrt machines you just filter out the ones that don;t match | 14:21 |
| rogpeppe | fwereade_: that is, given a set of constraints C, and another set D, can i assume that availMachines(C) is a non-strict superset of availMachines(C+D) ? | 14:21 |
| rogpeppe | fwereade_: the example that brought this to mind was ec2-zone=any | 14:22 |
| fwereade_ | rogpeppe, I think the answer is in general no, but keep talking | 14:22 |
| fwereade_ | rogpeppe, but I'm not actually sure exactly what you're referring to when yu say "machines" | 14:23 |
| rogpeppe | fwereade_: s/machines/instances/ | 14:23 |
| rogpeppe | fwereade_: 'cos if you have C=(ec2-zone=us-east-1a) and D=(ec2-zone=any) then it seems that the above supposition is violated | 14:24 |
| fwereade_ | rogpeppe, what does "+" mean then? | 14:24 |
| rogpeppe | fwereade_: combined, as with environment-level and service-level constraints | 14:24 |
| fwereade_ | rogpeppe, ah, ok -- then I think the answer is "mu" | 14:25 |
| fwereade_ | rogpeppe, combining two sets of constraints can make them tighter than the original or looser than the original, and makes no difference wrt instances which always just match a single bunch of constraints | 14:26 |
| rogpeppe | fwereade_: yeah, that's true. but is that true even if you're combining constraints with no overlapping attributes? | 14:26 |
| fwereade_ | rogpeppe, so forget about combining sets then | 14:27 |
| fwereade_ | rogpeppe, or maybe not -- I'm sorry, I think I need a bit more context on what you're thinking about before I can answer with confidence | 14:29 |
| rogpeppe | fwereade_: more time required to think :-) | 14:29 |
| fwereade_ | rogpeppe, in general, I think that if a given constraint is not set it will not particpate in matches | 14:30 |
| fwereade_ | rogpeppe, and that the effect of every constraint check is to exclude some images/instances/instance-types from consideration | 14:30 |
| fwereade_ | rogpeppe, so adding a new check can only further narrow down the list and cannot grow it | 14:31 |
| fwereade_ | rogpeppe, but that it is not sane to filter first by env constraints and then by service constraints, because that will exclude machines that should not be if the service specifies things that overlap or conflict with the env | 14:32 |
| rogpeppe | fwereade_: i was wondering if there's a machine that has been started with constraint 'a=1 b=2', then we can be sure that the machine so allocated will also match a desired constraint 'a=1' | 14:32 |
| rogpeppe | fwereade_: yes, i agree with that | 14:32 |
| fwereade_ | rogpeppe, if it does not, then we should probably have words with whoever did the provider that reported that instance info | 14:33 |
| rogpeppe | fwereade_: yeah | 14:33 |
| rogpeppe | fwereade_: it could happen if the default value for a constraint was restrictive | 14:33 |
| rogpeppe | fwereade_: but i think that would be wrong. | 14:33 |
| fwereade_ | rogpeppe, I'm +-0 on the idea of defaults anyway, I don't want to introduce them unless I'm sure about them | 14:34 |
| rogpeppe | fwereade_: +1 | 14:34 |
| fwereade_ | rogpeppe, it may make more sense to charge the environ with doing sane things in response to empty constraints | 14:35 |
| fwereade_ | rogpeppe, figuring out a sane thing for all openstacks is not easy, but it's easier than doing so across all possible providers | 14:35 |
| === slank_away is now known as slank | ||
| rogpeppe | fwereade_: can you specify constraints on a subordinate service? | 14:36 |
| fwereade_ | rogpeppe, I'm inclined to say no for now | 14:37 |
| TheMue | fwereade_, rogpeppe: When talking about constraints with numbers, are they meant as an exact value, as an upper limit or as a lower limit? | 14:37 |
| fwereade_ | TheMue, in every case so far, lower limit | 14:37 |
| fwereade_ | TheMue, if we had a "cost" that would make sense as an upper limit | 14:37 |
| TheMue | fwereade_: So what if I want to limit it to a maximum, e.g. for cost control reasons? | 14:37 |
| TheMue | fwereade_: Yep. | 14:38 |
| fwereade_ | TheMue, nobody's actually expressed a desire for that | 14:38 |
| fwereade_ | TheMue, if they do we can figure something out -- say, "mem<=2G" | 14:39 |
| TheMue | fwereade_: What we're defining is a kind of DSL for constraints. "cpu > 4000 MIPS && ram > 2 GB || cpu < 4000 MIPS && ram > 4 GB". | 14:39 |
| fwereade_ | TheMue, I think I am trying hard not to do that | 14:39 |
| fwereade_ | ;) | 14:39 |
| TheMue | fwereade_: Hehe, can understand. | 14:39 |
| TheMue | fwereade_: But the discussion in some points reminds me of it. | 14:40 |
| fwereade_ | TheMue, although what you said is also perfectly correct -- that is what we are doing, we just don't want it to look like that | 14:40 |
| fwereade_ | TheMue, yet ;p | 14:40 |
| TheMue | fwereade_: From a user perspective, what are the demands? More than just say "tiny, small, medium, large, xxl"? | 14:41 |
| fwereade_ | TheMue, I think that those words are meaningless in a global context | 14:41 |
| TheMue | fwereade_: Together with a map what they mean for a given provider? | 14:42 |
| fwereade_ | TheMue, I think it will be rare for an environment to have instance types that map remotely neatly onto those things | 14:46 |
| TheMue | fwereade_: They don't have to map between providers IMHO. So tiny in EC2 isn't tiny in an OpenStack environment. But tiny is defined per environment. And the op can so choose the best matching one instead of fiddling with details. | 14:48 |
| fwereade_ | TheMue, if they don't map to something roughly equivalent across providers they're worthless | 14:49 |
| TheMue | fwereade_: Only some constraints may be hard due to software dependencies, like arch or gpu. | 14:49 |
| fwereade_ | TheMue, yeah, arch is an interesting one, we didn't hit that one in the call | 14:49 |
| TheMue | fwereade_: Why do you think they are worthless? | 14:50 |
| fwereade_ | TheMue, because their purpose is to enable sane cross-environment scripting | 14:50 |
| fwereade_ | TheMue, if you can't say "this should run on at least a medium" and have that mean something coherent regardless of provider, it's no help at all | 14:50 |
| TheMue | fwereade_: Ah, forgot the charm perspective. :/ | 14:52 |
| rogpeppe | fwereade_: RFC http://paste.ubuntu.com/1616827/ | 15:03 |
| fwereade_ | rogpeppe, looking | 15:03 |
| fwereade_ | rogpeppe, can't match against instance constraints | 15:04 |
| fwereade_ | rogpeppe, well we could, but it would be crap | 15:05 |
| fwereade_ | rogpeppe, we need to match against the properties of the actual instance | 15:05 |
| rogpeppe | fwereade_: i agree with that - see the 3rd last para | 15:05 |
| rogpeppe | fwereade_: in fact, yes, we can't do any matching *until* that's occurred, yeah | 15:06 |
| fwereade_ | rogpeppe, I guess I'm not seeing how this actually solves a problem though | 15:07 |
| rogpeppe | fwereade_: it seems like a reasonably simple scheme that means we can have provider-specific constraints in a coherent way | 15:08 |
| fwereade_ | rogpeppe, how does it address the problem of specifying "instance-type=m1.small" against an openstack environment? | 15:09 |
| fwereade_ | rogpeppe, it doesn't address the social problem | 15:09 |
| fwereade_ | rogpeppe, people will script them anyway | 15:09 |
| fwereade_ | rogpeppe, if the social problem is not a problem, we don't need to separate them at the UI level | 15:10 |
| fwereade_ | rogpeppe, and if it is, we still don't because it won;t help -- it's just layered complexity to no benefit | 15:10 |
| rogpeppe | fwereade_: in that case, you'd either get an error when you tried to specify that constrain (the juju command can check), or the constraint would fail | 15:11 |
| fwereade_ | rogpeppe, right, just as they would if the division didn't exist | 15:11 |
| rogpeppe | fwereade_: break for kanban? | 15:11 |
| rogpeppe | fwereade_: one advantage of the divide is that lots of the awkward logic (e.g. combining constraints) can be implemented in the state, and each provider only has to deal with it in one specific place (Environ.Constraints) | 15:25 |
| rogpeppe | fwereade_: also, from a user-facing point of view, the rules are more straightforward, i think - they don't have to worry about overlapping constraints | 15:26 |
| rogpeppe | fwereade_: also, it's easy to tell if someone is using provider-specific constraints, because they're tagged as such. | 15:28 |
| fwereade_ | rogpeppe, a question: is "arch" provider-specific? | 15:30 |
| rogpeppe | fwereade_: we would provide arch in the portable constraints | 15:31 |
| fwereade_ | rogpeppe, so you can't start an instance with a specific arch? | 15:31 |
| rogpeppe | fwereade_: sure you can | 15:32 |
| fwereade_ | rogpeppe, s/instance/instance type/ | 15:32 |
| fwereade_ | rogpeppe, how so? I thought you can't specify both | 15:32 |
| rogpeppe | fwereade_: the provider constraints could provide arch too, if it was appropriate | 15:32 |
| rogpeppe | fwereade_: the idea is that the provider-specific constraints embody exactly the constraint capabilities of that provider | 15:33 |
| fwereade_ | rogpeppe, having two ways of specifying arch does not seem to be a win simplicity-wise | 15:33 |
| rogpeppe | fwereade_: i think it's reasonable actually. | 15:34 |
| rogpeppe | fwereade_: the portable constraints and the provider-specific constraints live in different semantic spaces | 15:34 |
| rogpeppe | fwereade_: one provider might provide a more detailed level of "arch" | 15:35 |
| rogpeppe | fwereade_: whereas portable constraints might only understand amd64, i386, arm | 15:35 |
| fwereade_ | rogpeppe, then their portability is at best suspect | 15:36 |
| rogpeppe | fwereade_: in some providers, arch might not be orthogonal to instance type. | 15:37 |
| fwereade_ | rogpeppe, in some, it's already not | 15:37 |
| rogpeppe | fwereade_: quite so | 15:37 |
| rogpeppe | fwereade_: so we only have another way to specify "arch" if it's a concept that makes direct sense to a provider. | 15:38 |
| fwereade_ | rogpeppe, if the provider's expected to understand the portable arch as well, which surely it must, then it is always a concept that makes direct sense to the provider | 15:38 |
| rogpeppe | fwereade_: i think that almost all our difficulties when thinking about constraints come from trying to combine provider-specific and portable constraints. | 15:39 |
| rogpeppe | fwereade_: the only parts of the provider that understands the portable arch would be the Environ.Constraints method (mapping from portable to provider-specific) and Instance.Constraints (mapping the other way); this localises the necessary knowledge. | 15:40 |
| rogpeppe | fwereade_: and at no point does the provider have to decide how its constraints work *alongside* portable constraints | 15:42 |
| rogpeppe | fwereade_: it can choose a semantic model that fits the domain it has to work with | 15:42 |
| rogpeppe | fwereade_: i *think* this will produce a system where the results are more predictable and the model to the user is clearer, but i may well be wrong! | 15:44 |
| fwereade_ | rogpeppe, I still feel like we haven't had an answer to the question of what happens when you specify nonsensical provider constraints | 15:45 |
| rogpeppe | fwereade_: well, in the first instance, we can have the juju command call Constraints on the local environ to make sure it understands them | 15:46 |
| fwereade_ | rogpeppe, so we error out when incompatible constraints are specified? | 15:47 |
| fwereade_ | rogpeppe, just like would would anyway? | 15:47 |
| fwereade_ | rogpeppe, is this not the problem we are trying to resolve> | 15:47 |
| rogpeppe | fwereade_: using portable constraints, there are no incompatible constraints, right? | 15:48 |
| fwereade_ | rogpeppe, yes, if that's all you're using | 15:48 |
| rogpeppe | fwereade_: so we could make the environ give an error for incompatible provider-specific constraints (so that the user knows in advance that no machine will ever satisfy the constraint), but i don't *think* that's the essence of the problem we're trying to resolve | 15:51 |
| fwereade_ | rogpeppe, or we could just treat it as no-constraint-at-all, and then we'd do something useful to the best of our ability | 15:52 |
| rogpeppe | fwereade_: i'd prefer not to do that. if we have a constraint, i think it should be binding. | 15:53 |
| rogpeppe | fwereade_: but i think we should make it obvious in the status when a constraint cannot be satisfied. | 15:53 |
| fwereade_ | rogpeppe, +0, +1 | 15:54 |
| fwereade_ | rogpeppe, it depends chiefly on how you phrase it | 15:54 |
| fwereade_ | rogpeppe, what's your position on the prefer-near/prefer-far concept? | 15:54 |
| rogpeppe | fwereade_: remind me of that concept, please | 15:55 |
| rogpeppe | fwereade_: are you talking about placement? | 15:55 |
| fwereade_ | rogpeppe, it's a rough suggestion I made in response to the os-scheduler-hints business | 15:55 |
| fwereade_ | rogpeppe, no more than we have been already (in that constraints is about "placement" of machines on instances) | 15:56 |
| rogpeppe | fwereade_: ah, i'm not sure i saw it. | 15:56 |
| fwereade_ | rogpeppe, I think we had a discussion about the thread | 15:56 |
| fwereade_ | rogpeppe, maybe it was in a followup | 15:57 |
| rogpeppe | fwereade_: constraints, to me, is about constraining the capabilities of a given machine, irrespective of any other entities in the system. | 15:57 |
| fwereade_ | rogpeppe, tldr: it was confirmed that the use case that prompted os-scheduler-hints was "I want my instances to be exposed to different risks" | 15:57 |
| rogpeppe | fwereade_: placement, to me, is about constraining *where* a machine goes relative to some other machine | 15:58 |
| fwereade_ | rogpeppe, so what is your plan for expressing this use case? | 15:58 |
| rogpeppe | fwereade_: i think i wouldn't try to abuse the constraint syntax to do it | 15:58 |
| rogpeppe | fwereade_: currently the constraint language is entirely separate from the juju state namespace. with prefer-near etc, i don't think we'd want it to be. | 15:59 |
| rogpeppe | fwereade_: because you'd want to talk about these things in terms of juju concepts like units or services. | 15:59 |
| fwereade_ | rogpeppe, yes, exactly | 15:59 |
| fwereade_ | rogpeppe, of course we want to be able to express this use case in a clear and succinct way | 16:00 |
| rogpeppe | fwereade_: so i'd suggest that we don't try to shoehorn it into constraints, but design a specific feature to do it | 16:00 |
| fwereade_ | rogpeppe, it is your personal definition of constraints that makes the shoehorn necessary | 16:01 |
| fwereade_ | rogpeppe, constraints are the feature by which we expose the differing capabilities of the places where services' code is actually run | 16:01 |
| rogpeppe | fwereade_: we have nice simple rules for constraints: "this machine satisfies that constraint"; "this machine does not". with prefer-near etc, we're breaking that model. | 16:02 |
| fwereade_ | rogpeppe, so if people want to specify placement, we should expose a separate provider-specific vocabulary in order to do so? | 16:03 |
| rogpeppe | fwereade_: nope. i think we should have some portable syntax, e.g. deploy --near other-service | 16:03 |
| fwereade_ | rogpeppe, and new verbs for changing affinity and suchlike? | 16:04 |
| rogpeppe | fwereade_: that kind of thing, yes | 16:04 |
| fwereade_ | rogpeppe, so, from a user point of view, how is that different to a constraint other than in tedious difference in specification? | 16:05 |
| rogpeppe | fwereade_: it's a preference rather than a constraint | 16:06 |
| rogpeppe | fwereade_: and... does it make sense to have these attributes at an environment level? | 16:06 |
| fwereade_ | rogpeppe, probably not settable at, no | 16:07 |
| fwereade_ | rogpeppe, unsettable constraints are nothing new though | 16:07 |
| fwereade_ | rogpeppe, specifically, series | 16:07 |
| fwereade_ | rogpeppe, (apart from anything else, that is not a hardware constraint ;p) | 16:07 |
| rogpeppe | fwereade_: how is series unsettable? | 16:07 |
| fwereade_ | rogpeppe, how would you go about setting it? | 16:08 |
| fwereade_ | rogpeppe, it is determined by the charm, full stop | 16:08 |
| rogpeppe | fwereade_: ah, so it wouldn't be a constraint attribute at all, right? | 16:08 |
| rogpeppe | fwereade_: hmm, except when resolved in an actual instance. | 16:09 |
| fwereade_ | rogpeppe, ok, it's a separate thing that requires matching etc but is not a constraint | 16:09 |
| fwereade_ | rogpeppe, so far you have proposed two kinds of constraint that can share names, and two new mechanisms that look and smell very much like constraints to the average user | 16:09 |
| fwereade_ | rogpeppe, I do not think this is moving towards simplicity | 16:09 |
| rogpeppe | fwereade_: i think it is actually simpler, because responsibilities are clearly delineated | 16:10 |
| rogpeppe | fwereade_: and we don't need to try to understand what it means to combine m1.small with mem=32G | 16:11 |
| fwereade_ | rogpeppe, the user's goal AIUI is to specify things that are important to them about how their service is deployed, and to have those things happen | 16:11 |
| rogpeppe | fwereade_: yup | 16:12 |
| fwereade_ | rogpeppe, I do not believe that in the average user's mind there is a pre-existing crisp partition of these concepts | 16:13 |
| rogpeppe | fwereade_: the average user will never need to use provider-constraint | 16:14 |
| rogpeppe | fwereade_: it's a gateway for the more provider-savvy user | 16:14 |
| fwereade_ | rogpeppe, but what people actually do, AIUI, is to specify instance-type=m1.small and forget about cpu/mem | 16:15 |
| rogpeppe | fwereade_: i worry that if we include provider-specific constraints in the normal constraints, that people won't see the difference and will use non-portable constraints as a matter of course. | 16:15 |
| fwereade_ | rogpeppe, I don't think your suggestion does anything to solve that problem | 16:15 |
| rogpeppe | fwereade_: if they do that, i think they should be made aware that they're doing something non-portable | 16:15 |
| rogpeppe | fwereade_: i dunno. it's just a straw man. i'd like to see a counter proposal. | 16:17 |
| fwereade_ | rogpeppe, ok, opposing strawman: constraints that may have provider-specific meaning are prefixed "hint-", and are not guaranteed to work on all providers; invalid values for a particular provider are just ignored | 16:20 |
| fwereade_ | rogpeppe, hint-instance-type=m1.medium | 16:20 |
| rogpeppe | fwereade_: "hint" seems wrong there - it's a genuine constraint if we're running on ec2, not just a hint. | 16:21 |
| fwereade_ | rogpeppe, ok, hint-instance-type=m1.mdeium ;p | 16:21 |
| rogpeppe | fwereade_: ? | 16:22 |
| rogpeppe | fwereade_: ec2-instance-type=m1.medium ? | 16:22 |
| rogpeppe | fwereade_: and in general, <environ-type>-attr=val ? | 16:23 |
| fwereade_ | rogpeppe, ec2 is special | 16:23 |
| fwereade_ | rogpeppe, openstack-instance-type is no better off | 16:23 |
| rogpeppe | fwereade_: i don't understand, sorry | 16:23 |
| fwereade_ | rogpeppe, the hintiness is in that if you ask ec2 for crack, it ignores you | 16:23 |
| rogpeppe | fwereade_: hmm. i don't think that's right. i think that if you ask ec2 for crack, and it knows it, it should tell you asap | 16:24 |
| fwereade_ | rogpeppe, "hint-instance-type=m1.more-obvious-typo" will cause the provider to pick one and run with it | 16:24 |
| rogpeppe | fwereade_: but if i really have mistyped m1.medium, i don't want that to happen | 16:25 |
| fwereade_ | rogpeppe, ok, then the same applies for openstack, right? | 16:25 |
| rogpeppe | fwereade_: yup | 16:25 |
| fwereade_ | rogpeppe, so openstack-instance-type is non-portable across openstacks | 16:25 |
| rogpeppe | fwereade_: you can't always resolve all attributes in the client. | 16:25 |
| fwereade_ | rogpeppe, and does not fulfil the goal of gracefully ignoring irrelevant constraints -- it doesn't have the context to know that such a constraint is irrelevant rather than malformed | 16:26 |
| rogpeppe | fwereade_: and in the general case, the client can't resolve *anything*, because it doesn't have access to an Environ | 16:26 |
| * TheMue thinks about constraints for the local provider or colocation ... | 16:26 | |
| rogpeppe | fwereade_: if we had some way of telling provider-specific constraints, that would be possible | 16:26 |
| rogpeppe | fwereade_: e.g. a prefix that indicates a provider-specific constraint | 16:27 |
| fwereade_ | rogpeppe, they're really environ-specific, though, right? | 16:27 |
| rogpeppe | fwereade_: no, i don't think they are. | 16:27 |
| fwereade_ | rogpeppe, even in ec2 -- environs in different regions have different instance types available | 16:28 |
| rogpeppe | fwereade_: i think that a given provider should always provide the same set of attributes. | 16:28 |
| rogpeppe | fwereade_: the set of possible *values* is another matter | 16:28 |
| * fwereade_ approves of TheMue's thoughts, and observes that we must also be able to have a provider that coherently exposes no constraints at all, and still works without crazy special-casing everywhere | 16:28 | |
| fwereade_ | rogpeppe, yeah, the set of possible values is the question ;) | 16:29 |
| fwereade_ | rogpeppe, hum | 16:29 |
| fwereade_ | rogpeppe, a thought | 16:29 |
| fwereade_ | rogpeppe, *any* constraint could probably be usefully prefixed with a "hint-" prefix | 16:29 |
| rogpeppe | fwereade_: to impose some preference ordering on available instances? | 16:30 |
| fwereade_ | rogpeppe, or ignore it if it's hard to do in some specific case | 16:30 |
| fwereade_ | ;p | 16:31 |
| rogpeppe | fwereade_: i think it's awkward. if two different instances satisfy different "hint-" constraints, which one do you choose? it seems... arbitrary. | 16:31 |
| rogpeppe | fwereade_: and i don't really see the use case | 16:31 |
| rogpeppe | fwereade_: when would you want to use hints? | 16:31 |
| fwereade_ | rogpeppe, please state for me the problem you think we are trying to solve | 16:32 |
| rogpeppe | fwereade_: i have a service i want to run and each unit has certain requirements, then i want units of that service to run on sufficiently capable machines. | 16:33 |
| rogpeppe | fwereade_: meeting break - got a 1-1 | 16:33 |
| rogpeppe | fwereade_: back | 17:10 |
| fwereade_ | rogpeppe, heyhey | 17:16 |
| fwereade_ | rogpeppe, I think that it is unhelpful to restrict the scope of to "sufficiently capable machines" -- you're actually trying to specify the properties of your service | 17:19 |
| rogpeppe | fwereade_: you're trying to specify *sufficient* properties, no? otherwise it wouldn't be constraint, it would be specification | 17:20 |
| fwereade_ | rogpeppe, "always running with 4G of RAM" is one property, "distributed as widely as possible" is another | 17:20 |
| rogpeppe | fwereade_: that's an interesting take on it. that's not how i was thinking about constraints (i was thinking in terms of constraining potential machines) | 17:22 |
| fwereade_ | rogpeppe, I'm not sure I see a significant distinction between specifying that a solution must have X properties and constraining matters such that things without X properties are excluded | 17:23 |
| fwereade_ | rogpeppe, it is all still in service of manipulating precisely how the units of a service are deployed, because that is the clay we have to work with | 17:23 |
| rogpeppe | fwereade_: "distributed as widely as possible" isn't a property that's possible to check for on a machine in isolation | 17:24 |
| fwereade_ | rogpeppe, yeah, that is why I suggested *prefer*-near/far -- it is because I think it is a concept that maps clearly to a valuable feature, that different providers can and will interpret differently | 17:25 |
| rogpeppe | fwereade_: it seems to me that that's a fundamentally different kind of constraint | 17:25 |
| dimitern | is there in go a fast way to check if a key is within a map, without for range loop? | 17:25 |
| fwereade_ | rogpeppe, soft vs hard? | 17:25 |
| fwereade_ | dimitern, _, ok := m[k] | 17:26 |
| rogpeppe | dimitern: if x, ok := m[key]; ok { ... } | 17:26 |
| rogpeppe | fwereade_: i don't really know what a "soft" constraint means. | 17:26 |
| dimitern | of course! :) I must need a brake already :) | 17:26 |
| rogpeppe | fwereade_: does it mean some kind of preference-ordering? | 17:27 |
| fwereade_ | rogpeppe, The aim of constraint optimization is to find a solution to the problem whose cost, evaluated as the sum of the cost functions, is maximized or minimized. The regular constraints are called hard constraints, while the cost functions are called soft constraints. | 17:27 |
| rogpeppe | fwereade_: so each provider implements its own constraint optimiser? | 17:28 |
| fwereade_ | rogpeppe, well, no... just a cost function, surely? | 17:29 |
| dimitern | and given x, ok := m[k]; will changing x change m[k], assuming m is map[string][]T ? i.e. x = append(x, y) <=> m[k] = append(m[k], y) ? | 17:29 |
| rogpeppe | dimitern: no | 17:29 |
| rogpeppe | dimitern: same as slice range or function calls, the variable is a copy of the original | 17:29 |
| dimitern | rogpeppe: ok, tyvm | 17:30 |
| fwereade_ | rogpeppe, not even that, actually | 17:30 |
| fwereade_ | rogpeppe, Distance(inst1, inst2 Instance) float | 17:30 |
| rogpeppe | fwereade_: so the provider has to do an n^2 algorithm through all instances to find a result? | 17:31 |
| rogpeppe | fwereade_: istm that if we leave out soft constraints, we have a very simple system that's sufficient for a great many needs (and certainly for 13.04) | 17:33 |
| fwereade_ | rogpeppe, when would we want to do that? | 17:33 |
| rogpeppe | fwereade_: when optimising, no? | 17:33 |
| fwereade_ | rogpeppe, m*n where each of m and n will already be constrained, I think | 17:33 |
| fwereade_ | rogpeppe, I probably wouldn't recommend using them at serious scale | 17:34 |
| fwereade_ | rogpeppe, but I think it solves a problem that people are already having at a small scale | 17:35 |
| fwereade_ | rogpeppe, and it expresses it in a useful language | 17:35 |
| rogpeppe | fwereade_: could you put together some text that describes the same scenarios that my straw-man above did, (i.e. the flow of information from deploy specification to actual provider deployment)? | 17:36 |
| rogpeppe | fwereade_: i have a very concrete idea of how my idea would work, but am quite unclear about how your thoughts might pan out | 17:37 |
| fwereade_ | rogpeppe, sorry, for what scenario? this one right now? | 17:37 |
| fwereade_ | rogpeppe, of the flow of the whole thing? | 17:37 |
| fwereade_ | s/of the/or the/ | 17:38 |
| rogpeppe | fwereade_: the same kind of structure that i had in the above paste | 17:38 |
| rogpeppe | fwereade_: except that it should probably mention how prefer-near etc would work too | 17:38 |
| rogpeppe | fwereade_: i might post my straw man to juju-dev for all to knock down | 17:39 |
| fwereade_ | rogpeppe, ok -- I have to stop now, but I will try to write something :) | 17:41 |
| rogpeppe | fwereade_: thanks | 17:41 |
| rogpeppe1 | davecheney: yo! | 21:58 |
| rogpeppe1 | davecheney: ping | 22:14 |
| davecheney | hey | 22:17 |
| davecheney | ack | 22:17 |
| davecheney | two secs | 22:17 |
| davecheney | rogpeppe1: sorry, have to go afk for a bit (family stuff) | 22:29 |
| rogpeppe1 | davecheney: ok. any chance you'll be around for a chat in the next hour? | 22:29 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!