rogpeppedavecheney: ping00:08
mrammrogpeppe: hey, you still around?00:16
rogpeppemramm: not really. it's late and i'm summoned.00:16
mrammhave a great evening00:16
fwereade_heya TheMue07:59
TheMuefwereade_: Hi William08:02
TheMuefwereade_: You know http://hackingdistributed.com/2013/01/29/mongo-ft/?08:12
fwereade_TheMue, haven't read that one tbh08:15
TheMuefwereade_: It's about MongoDB replication and how this can lead to problems.08:16
fwereade_TheMue, it does not look unfamiliar though08:16
fwereade_TheMue, most of it seems to be the usual whining about default settings08:17
fwereade_TheMue, maybe I should read more closely?08:17
TheMuefwereade_: 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 tech08: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 tradeoffs08:20
TheMuefwereade_: Well known as Gardner hype cycle ;)08:20
fwereade_TheMue, yeah, indeed -- I just think we're in phase 2 re mongo at the moment08:21
fwereade_TheMue, this is not to say that there will not be challenges wrtreplication08:21
TheMuefwereade_: 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 grow08:22
TheMuefwereade_: 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
TheMuefwereade_: Sure, wrt to scaling and HA it will get interesting.08:23
TheMuefwereade_: Yeah, you yesterday mentioned it.08:23
TheMuefwereade_: 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 replication08:26
TheMuefwereade_: Yeo08:27
fwereade_TheMue, my own concerns remain somewhat theoretical08:28
TheMuefwereade_: But still interesting as they exist.08:28
TheMuefwereade_: I would like to see my technical lead w/o concerns. :D08:29
fwereade_TheMue, it's basically concern over precisley how txn sync points can propagate across the collections08:29
fwereade_TheMue, I think the really interesting problem is service destruction08: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 scenarios08:30
TheMuefwereade_: 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 request08:31
TheMuefwereade_: 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 ;p08:33
fwereade_TheMue, the trouble with documenting things is that the cost/benefit calulation is really simple08: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 reason08:35
fwereade_TheMue, I am firmly +1 on writing design specs08:35
rogpeppefwereade_, TheMue: do you want to continue that meeting?08:36
rogpeppe(morning, BTW!)08:36
TheMuerogpeppe: Morning08:36
fwereade_rogpeppe, TheMue: yeah, we probably should, would one of you start a hangout? I'll be there in 508:36
TheMuerogpeppe: Yep08:36
TheMuefwereade_: You read my mail about docs this morning?08:36
fwereade_TheMue, yeah, the things I was just saying are closely connected08:40
fwereade_TheMue, we could maybe touch on it live as well08:40
fwereade_rogpeppe, TheMue, omw back10:44
* niemeyer joins11:58
niemeyerdimitern: I assume this is the constraint discussion?11:58
dimiternniemeyer: yes it is11:58
fwereade_niemeyer, dimitern: I hope so11:58
niemeyerMornings, btw! :-)11:58
niemeyerfwereade_, dimitern: Can you please invite the other me11:59
* fwereade_ seems to be the only one in there11:59
dimiternniemeyer: morning11:59
dimiternso that's not the one11:59
dimiternjam's creating a new one and will post a link11:59
niemeyerjam: Can you please invite the other me?12:00
TheMuejam: Same here12:00
jamIf I missed anyone, please just poke me, if the above link doesn't work automatically12:01
=== otubo1 is now known as otubo
rogpeppedarn, i missed all the above reminders12:49
rogpeppefwereade_: can you point me to the original constraints discussion document (where the constraint semantics were laid out)13:48
rogpeppefwereade_: i'm relying on possibly dubious memory of what was arrived at13:48
fwereade_rogpeppe, I think it's in the juju-doc project somewhere, let me poke around a bit13:49
rogpeppefwereade_: ah! this one: https://juju.ubuntu.com/docs/constraints.html13:50
fwereade_rogpeppe, that's not the spec I remember, it's the polished-up-for-users docs13:51
fwereade_rogpeppe, but maybe that's what it evolved into13:51
rogpeppefwereade_: yeah, i remember a different document too13:52
rogpeppefwereade_: but that's good for going on with - it documents the user expectations which is probably the most important thing13:52
fwereade_rogpeppe, actually, I think it is roughly the same14:00
fwereade_rogpeppe, if you do a deep dive in deleted bits of the juju source itself you'll find earlier versions14:00
rogpeppefwereade_: ok, cool14:00
rogpeppefwereade_: 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 match14:21
rogpeppefwereade_: 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
rogpeppefwereade_: the example that brought this to mind was ec2-zone=any14:22
fwereade_rogpeppe, I think the answer is in general no, but keep talking14:22
fwereade_rogpeppe, but I'm not actually sure exactly what you're referring to when yu say "machines"14:23
rogpeppefwereade_: s/machines/instances/14:23
rogpeppefwereade_: 'cos if you have C=(ec2-zone=us-east-1a) and D=(ec2-zone=any) then it seems that the above supposition is violated14:24
fwereade_rogpeppe, what does "+" mean then?14:24
rogpeppefwereade_: combined, as with environment-level and service-level constraints14: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 constraints14:26
rogpeppefwereade_: 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 then14: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 confidence14:29
rogpeppefwereade_: 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 matches14:30
fwereade_rogpeppe, and that the effect of every constraint check is to exclude some images/instances/instance-types from consideration14:30
fwereade_rogpeppe, so adding a new check can only further narrow down the list and cannot grow it14: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 env14:32
rogpeppefwereade_: 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
rogpeppefwereade_: yes, i agree with that14:32
fwereade_rogpeppe, if it does not, then we should probably have words with whoever did the provider that reported that instance info14:33
rogpeppefwereade_: yeah14:33
rogpeppefwereade_: it could happen if the default value for a constraint was restrictive14:33
rogpeppefwereade_: 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 them14:34
rogpeppefwereade_: +114:34
fwereade_rogpeppe, it may make more sense to charge the environ with doing sane things in response to empty constraints14:35
fwereade_rogpeppe, figuring out a sane thing for all openstacks is not easy, but it's easier than doing so across all possible providers14:35
=== slank_away is now known as slank
rogpeppefwereade_: can you specify constraints on a subordinate service?14:36
fwereade_rogpeppe, I'm inclined to say no for now14:37
TheMuefwereade_, 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 limit14:37
fwereade_TheMue, if we had a "cost" that would make sense as an upper limit14:37
TheMuefwereade_: So what if I want to limit it to a maximum, e.g. for cost control reasons?14:37
TheMuefwereade_: Yep.14:38
fwereade_TheMue, nobody's actually expressed a desire for that14:38
fwereade_TheMue, if they do we can figure something out -- say, "mem<=2G"14:39
TheMuefwereade_: 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 that14:39
TheMuefwereade_: Hehe, can understand.14:39
TheMuefwereade_: 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 that14:40
fwereade_TheMue, yet ;p14:40
TheMuefwereade_: 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 context14:41
TheMuefwereade_: 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 things14:46
TheMuefwereade_: 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 worthless14:49
TheMuefwereade_: 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 call14:49
TheMuefwereade_: Why do you think they are worthless?14:50
fwereade_TheMue, because their purpose is to enable sane cross-environment scripting14: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 all14:50
TheMuefwereade_: Ah, forgot the charm perspective. :/14:52
rogpeppefwereade_: RFC http://paste.ubuntu.com/1616827/15:03
fwereade_rogpeppe, looking15:03
fwereade_rogpeppe, can't match against instance constraints15:04
fwereade_rogpeppe, well we could, but it would be crap15:05
fwereade_rogpeppe, we need to match against the properties of the actual instance15:05
rogpeppefwereade_: i agree with that - see the 3rd last para15:05
rogpeppefwereade_: in fact, yes, we can't do any matching *until* that's occurred, yeah15:06
fwereade_rogpeppe, I guess I'm not seeing how this actually solves a problem though15:07
rogpeppefwereade_: it seems like a reasonably simple scheme that means we can have provider-specific constraints in a coherent way15: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 problem15:09
fwereade_rogpeppe, people will script them anyway15:09
fwereade_rogpeppe, if the social problem is not a problem, we don't need to separate them at the UI level15:10
fwereade_rogpeppe, and if it is, we still don't because it won;t help -- it's just layered complexity to no benefit15:10
rogpeppefwereade_: 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 fail15:11
fwereade_rogpeppe, right, just as they would if the division didn't exist15:11
rogpeppefwereade_: break for kanban?15:11
rogpeppefwereade_: 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
rogpeppefwereade_: also, from a user-facing point of view, the rules are more straightforward, i think - they don't have to worry about overlapping constraints15:26
rogpeppefwereade_: 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
rogpeppefwereade_: we would provide arch in the portable constraints15:31
fwereade_rogpeppe, so you can't start an instance with a specific arch?15:31
rogpeppefwereade_: sure you can15:32
fwereade_rogpeppe, s/instance/instance type/15:32
fwereade_rogpeppe, how so? I thought you can't specify both15:32
rogpeppefwereade_: the provider constraints could provide arch too, if it was appropriate15:32
rogpeppefwereade_: the idea is that the provider-specific constraints embody exactly the constraint capabilities of that provider15:33
fwereade_rogpeppe, having two ways of specifying arch does not seem to be a win simplicity-wise15:33
rogpeppefwereade_: i think it's reasonable actually.15:34
rogpeppefwereade_: the portable constraints and the provider-specific constraints live in different semantic spaces15:34
rogpeppefwereade_: one provider might provide a more detailed level of "arch"15:35
rogpeppefwereade_: whereas portable constraints might only understand amd64, i386, arm15:35
fwereade_rogpeppe, then their portability is at best suspect15:36
rogpeppefwereade_: in some providers, arch might not be orthogonal to instance type.15:37
fwereade_rogpeppe, in some, it's already not15:37
rogpeppefwereade_: quite so15:37
rogpeppefwereade_: 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 provider15:38
rogpeppefwereade_: i think that almost all our difficulties when thinking about constraints come from trying to combine provider-specific and portable constraints.15:39
rogpeppefwereade_: 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
rogpeppefwereade_: and at no point does the provider have to decide how its constraints work *alongside* portable constraints15:42
rogpeppefwereade_: it can choose a semantic model that fits the domain it has to work with15:42
rogpeppefwereade_: 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 constraints15:45
rogpeppefwereade_: well, in the first instance, we can have the juju command call Constraints on the local environ to make sure it understands them15: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
rogpeppefwereade_: using portable constraints, there are no incompatible constraints, right?15:48
fwereade_rogpeppe, yes, if that's all you're using15:48
rogpeppefwereade_: 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 resolve15: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 ability15:52
rogpeppefwereade_: i'd prefer not to do that. if we have a constraint, i think it should be binding.15:53
rogpeppefwereade_: but i think we should make it obvious in the status when a constraint cannot be satisfied.15:53
fwereade_rogpeppe, +0, +115:54
fwereade_rogpeppe, it depends chiefly on how you phrase it15:54
fwereade_rogpeppe, what's your position on the prefer-near/prefer-far concept?15:54
rogpeppefwereade_: remind me of that concept, please15:55
rogpeppefwereade_: are you talking about placement?15:55
fwereade_rogpeppe, it's a rough suggestion I made in response to the os-scheduler-hints business15:55
fwereade_rogpeppe, no more than we have been already (in that constraints is about "placement" of machines on instances)15:56
rogpeppefwereade_: ah, i'm not sure i saw it.15:56
fwereade_rogpeppe, I think we had a discussion about the thread15:56
fwereade_rogpeppe, maybe it was in a followup15:57
rogpeppefwereade_: 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
rogpeppefwereade_: placement, to me, is about constraining *where* a machine goes relative to some other machine15:58
fwereade_rogpeppe, so what is your plan for expressing this use case?15:58
rogpeppefwereade_: i think i wouldn't try to abuse the constraint syntax to do it15:58
rogpeppefwereade_: 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
rogpeppefwereade_: because you'd want to talk about these things in terms of juju concepts like units or services.15:59
fwereade_rogpeppe, yes, exactly15:59
fwereade_rogpeppe, of course we want to be able to express this use case in a clear and succinct way16:00
rogpeppefwereade_: so i'd suggest that we don't try to shoehorn it into constraints, but design a specific feature to do it16:00
fwereade_rogpeppe, it is your personal definition of constraints that makes the shoehorn necessary16:01
fwereade_rogpeppe, constraints are the feature by which we expose the differing capabilities of the places where services' code is actually run16:01
rogpeppefwereade_: 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
rogpeppefwereade_: nope. i think we should have some portable syntax, e.g. deploy --near other-service16:03
fwereade_rogpeppe, and new verbs for changing affinity and suchlike?16:04
rogpeppefwereade_: that kind of thing, yes16: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
rogpeppefwereade_: it's a preference rather than a constraint16:06
rogpeppefwereade_: and... does it make sense to have these attributes at an environment level?16:06
fwereade_rogpeppe, probably not settable at, no16:07
fwereade_rogpeppe, unsettable constraints are nothing new though16:07
fwereade_rogpeppe, specifically, series16:07
fwereade_rogpeppe, (apart from anything else, that is not a hardware constraint ;p)16:07
rogpeppefwereade_: 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 stop16:08
rogpeppefwereade_: ah, so it wouldn't be a constraint attribute at all, right?16:08
rogpeppefwereade_: 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 constraint16: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 user16:09
fwereade_rogpeppe, I do not think this is moving towards simplicity16:09
rogpeppefwereade_: i think it is actually simpler, because responsibilities are clearly delineated16:10
rogpeppefwereade_: and we don't need to try to understand what it means to combine m1.small with mem=32G16: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 happen16:11
rogpeppefwereade_: yup16:12
fwereade_rogpeppe, I do not believe that in the average user's mind there is a pre-existing crisp partition of these concepts16:13
rogpeppefwereade_: the average user will never need to use provider-constraint16:14
rogpeppefwereade_: it's a gateway for the more provider-savvy user16:14
fwereade_rogpeppe, but what people actually do, AIUI, is to specify instance-type=m1.small and forget about cpu/mem16:15
rogpeppefwereade_: 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 problem16:15
rogpeppefwereade_: if they do that, i think they should be made aware that they're doing something non-portable16:15
rogpeppefwereade_: 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 ignored16:20
fwereade_rogpeppe, hint-instance-type=m1.medium16:20
rogpeppefwereade_: "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 ;p16:21
rogpeppefwereade_: ?16:22
rogpeppefwereade_: ec2-instance-type=m1.medium ?16:22
rogpeppefwereade_: and in general, <environ-type>-attr=val ?16:23
fwereade_rogpeppe, ec2 is special16:23
fwereade_rogpeppe, openstack-instance-type is no better off16:23
rogpeppefwereade_: i don't understand, sorry16:23
fwereade_rogpeppe, the hintiness is in that if you ask ec2 for crack, it ignores you16:23
rogpeppefwereade_: 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 asap16:24
fwereade_rogpeppe, "hint-instance-type=m1.more-obvious-typo" will cause the provider to pick one and run with it16:24
rogpeppefwereade_: but if i really have mistyped m1.medium, i don't want that to happen16:25
fwereade_rogpeppe, ok, then the same applies for openstack, right?16:25
rogpeppefwereade_: yup16:25
fwereade_rogpeppe, so openstack-instance-type is non-portable across openstacks16:25
rogpeppefwereade_: 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 malformed16:26
rogpeppefwereade_: and in the general case, the client can't resolve *anything*, because it doesn't have access to an Environ16:26
* TheMue thinks about constraints for the local provider or colocation ...16:26
rogpeppefwereade_: if we had some way of telling provider-specific constraints, that would be possible16:26
rogpeppefwereade_: e.g. a prefix that indicates a provider-specific constraint16:27
fwereade_rogpeppe, they're really environ-specific, though, right?16:27
rogpeppefwereade_: no, i don't think they are.16:27
fwereade_rogpeppe, even in ec2 -- environs in different regions have different instance types available16:28
rogpeppefwereade_: i think that a given provider should always provide the same set of attributes.16:28
rogpeppefwereade_: the set of possible *values* is another matter16: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 everywhere16:28
fwereade_rogpeppe, yeah, the set of possible values is the question ;)16:29
fwereade_rogpeppe, hum16:29
fwereade_rogpeppe, a thought16:29
fwereade_rogpeppe, *any* constraint could probably be usefully prefixed with a "hint-" prefix16:29
rogpeppefwereade_: to impose some preference ordering on available instances?16:30
fwereade_rogpeppe, or ignore it if it's hard to do in some specific case16:30
rogpeppefwereade_: i think it's awkward. if two different instances satisfy different "hint-" constraints, which one do you choose? it seems... arbitrary.16:31
rogpeppefwereade_: and i don't really see the use case16:31
rogpeppefwereade_: when would you want to use hints?16:31
fwereade_rogpeppe, please state for me the problem you think we are trying to solve16:32
rogpeppefwereade_: 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
rogpeppefwereade_: meeting break - got a 1-116:33
rogpeppefwereade_: back17:10
fwereade_rogpeppe, heyhey17: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 service17:19
rogpeppefwereade_: you're trying to specify *sufficient* properties, no? otherwise it wouldn't be constraint, it would be specification17:20
fwereade_rogpeppe, "always running with 4G of RAM" is one property, "distributed as widely as possible" is another17:20
rogpeppefwereade_: 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 excluded17: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 with17:23
rogpeppefwereade_: "distributed as widely as possible" isn't a property that's possible to check for on a machine in isolation17: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 differently17:25
rogpeppefwereade_: it seems to me that that's a fundamentally different kind of constraint17:25
dimiternis 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
rogpeppedimitern: if x, ok := m[key]; ok { ... }17:26
rogpeppefwereade_: i don't really know what a "soft" constraint means.17:26
dimiternof course! :) I must need a brake already :)17:26
rogpeppefwereade_: 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
rogpeppefwereade_: so each provider implements its own constraint optimiser?17:28
fwereade_rogpeppe, well, no... just a cost function, surely?17:29
dimiternand 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
rogpeppedimitern: no17:29
rogpeppedimitern: same as slice range or function calls, the variable is a copy of the original17:29
dimiternrogpeppe: ok, tyvm17:30
fwereade_rogpeppe, not even that, actually17:30
fwereade_rogpeppe, Distance(inst1, inst2 Instance) float17:30
rogpeppefwereade_: so the provider has to do an n^2 algorithm through all instances to find a result?17:31
rogpeppefwereade_: 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
rogpeppefwereade_: when optimising, no?17:33
fwereade_rogpeppe, m*n where each of m and n will already be constrained, I think17:33
fwereade_rogpeppe, I probably wouldn't recommend using them at serious scale17:34
fwereade_rogpeppe, but I think it solves a problem that people are already having at a small scale17:35
fwereade_rogpeppe, and it expresses it in a useful language17:35
rogpeppefwereade_: 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
rogpeppefwereade_: i have a very concrete idea of how my idea would work, but am quite unclear about how your thoughts might pan out17: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
rogpeppefwereade_: the same kind of structure that i had in the above paste17:38
rogpeppefwereade_: except that it should probably mention how prefer-near etc would work too17:38
rogpeppefwereade_: i might post my straw man to juju-dev for all to knock down17:39
fwereade_rogpeppe, ok -- I have to stop now, but I will try to write something :)17:41
rogpeppefwereade_: thanks17:41
rogpeppe1davecheney: yo!21:58
rogpeppe1davecheney: ping22:14
davecheneytwo secs22:17
davecheneyrogpeppe1: sorry, have to go afk for a bit (family stuff)22:29
rogpeppe1davecheney: 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!