| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-02-23 | |||
| 13:58:14 | srf | Spazmotic : I've tried to adding ENABLED_SERVICES=placement-api but still error | |
| 14:05:33 | Spazmotic | Not too sure then, but i'm sure someone may have seen it before.. also again you may wish to ask in #openstack as that's more designed for deployment support | |
| 14:24:20 | Guest70 | hello | |
| 14:44:17 | openstackgerrit | Eric Berglund proposed openstack/nova master: WIP: PowerVM Driver: Network interface attach/detach https://review.openstack.org/546813 | |
| 14:45:08 | openstackgerrit | Theodoros Tsioutsias proposed openstack/nova master: WIP: Add the reaper entry point https://review.openstack.org/547450 | |
| 14:53:14 | bauwser | if folks have specs, I'm hungry to eat them | |
| 14:53:44 | bauwser | like, you're going to the PTG and would like to discuss about your spec, I'm your man | |
| 14:54:16 | figleaf | bauwser: after you eat them, you know what they turn into :) | |
| 14:54:44 | bauwser | if they are made of cheese, I'm +2 | |
| 14:55:16 | bauwser | even if https://www.thelocal.fr/20180223/french-cheese-wars-are-the-days-of-the-real-normandy-camembert-numbered | |
| 14:57:20 | figleaf | guess it will be like taking a microbrew beer and then mass-producing it | |
| 15:04:39 | dansmith | leakypipes: I'm really not the right person to answer detailed questions about that | |
| 15:15:33 | bauwser | dansmith: I don't know your current TZ, but it's Friday here :) | |
| 15:15:54 | dansmith | bauwser: I don't know my current TZ either, but I'm pretty sure it's not friday in my body | |
| 15:16:04 | bauwser | still on the air ? | |
| 15:16:16 | dansmith | no, you caught me, I know my current TZ | |
| 15:16:19 | dansmith | but my body doesn't | |
| 15:16:22 | bauwser | heh | |
| 15:19:11 | mriedem | why do we have https://github.com/openstack/nova/blob/ef4000a0d326deb004843ee51d18030224c5630f/nova/db/sqlalchemy/api_models.py#L409 ? | |
| 15:19:24 | mriedem | seems silly to have an entire table to hold one string | |
| 15:19:40 | mriedem | maybe it goes back to the idea that server groups would have >1 policy | |
| 15:19:42 | mriedem | but the API doesn't allow that | |
| 15:20:26 | mriedem | https://github.com/openstack/nova/blob/ef4000a0d326deb004843ee51d18030224c5630f/nova/api/openstack/compute/schemas/server_groups.py#L29-L39 | |
| 15:21:42 | dansmith | mriedem: yeah it's 1:N I think | |
| 15:21:47 | dansmith | not that we can do that, I don't think | |
| 15:22:09 | mriedem | the api doesn't allow it | |
| 15:22:14 | mriedem | but that's the legacy reason i guess, | |
| 15:22:23 | mriedem | the schema makes you pass a single-item list for the policy | |
| 15:22:44 | dansmith | but even still, none of the stuff we do to honor the policy considers multiple options right? | |
| 15:22:47 | mriedem | and it's called "policies" but doesn't allow >1 | |
| 15:22:54 | mriedem | correct | |
| 15:22:56 | mriedem | it's just weird | |
| 15:23:06 | leakypipes | cfriesen: am I gonna have to get out the beating stick for you? :P | |
| 15:23:26 | mriedem | dansmith: context is https://review.openstack.org/#/c/546925 which is tied to an old blueprint from sgordon | |
| 15:23:45 | leakypipes | cfriesen: well, I suppose we could rent a pair of those fake Sumo wrestler costumes and go at it. | |
| 15:25:02 | dansmith | mriedem: ah yes, affrinity | |
| 15:25:18 | mriedem | i'm currently in the process of ripping up the spec | |
| 15:26:00 | dansmith | mriedem: ugh, that max_number_per_host thing is just silly.. that's never going to do something useful, IMHO | |
| 15:27:58 | mriedem | i can see the use, | |
| 15:28:03 | mriedem | it makes the soft policy less soft | |
| 15:28:08 | mriedem | jello-like if you will | |
| 15:28:19 | dansmith | what's the point in that? | |
| 15:28:41 | mriedem | there is some nfv use case in the spec | |
| 15:29:04 | dansmith | I think from a modeling point of view, it'd be hard to reason about that unless you knew "I'm going to start ten of the exact same thing for throughput and I want those spread across three nodes" | |
| 15:29:20 | mriedem | anti-affinity to a point, so they don't need all VMs in the group on separate hosts, but they can only tolerate up to a limit of VMs on the same host | |
| 15:30:14 | mriedem | otherwise today if you have 10 VMs in a soft-anti-affinity group, and only 2 available hosts, you could get like 1 on 1 host and 9 on the other | |
| 15:30:19 | dansmith | right, so a more useful thing would be to say "instances in this group should spread across N hosts before considering doubling up" | |
| 15:30:31 | dansmith | that's an easier to reason-about model from the outside I think | |
| 15:30:44 | dansmith | and it doesn't depend on the size of the group | |
| 15:31:02 | mriedem | i can't say if that's easier to reason about from the outside or not, | |
| 15:31:04 | dansmith | it focuses on the amount of redundancy you need regardless | |
| 15:31:10 | mriedem | since i've had this in my head the way it's proposed | |
| 15:31:21 | mriedem | dansmith: mention it in the spec? | |
| 15:31:36 | mriedem | either way i need to bring it up at the ptg b/c of some questions about how to model the thing in the api and db | |
| 15:32:21 | dansmith | I really hate the idea of adding extra_specs to anything, but especially groups | |
| 15:32:44 | mriedem | i said that on the spec | |
| 15:34:48 | dansmith | I guess their use-case actually specifically requires this as the model | |
| 15:37:12 | mriedem | is sgordon still a man about town? | |
| 15:37:18 | mriedem | isn't he in the UK/Ireland area? | |
| 15:37:40 | sgordon | mriedem, nah canadia | |
| 15:37:44 | mriedem | drats | |
| 15:37:52 | mriedem | sgordon: can you take a look at that spec regardless of your physical location? | |
| 15:38:09 | mriedem | gibi might also have some input here since ericsson added the soft affinity stuff | |
| 15:38:09 | sgordon | mriedem, yeah i just got the email notification and opened it up | |
| 15:39:14 | sgordon | mriedem, i have to admit i havent had anyone clamouring for this in a fair while, but that may just mean folks are working around it using host aggregates and higher level orchestration | |
| 15:43:44 | bauwser | mriedem: dansmith: we have a clear distinction between filters which hard-check possibilities and weighers which soft-check | |
| 15:44:15 | bauwser | having some middleground is something more than just for affinity | |
| 15:44:22 | bauwser | tbc, I'm -2 on the spexc | |
| 15:45:26 | bauwser | mriedem: dansmith: but johnthetubaguy had an idea to deprecate filters/weighers and have a different semantic for saying "here I want to hard-stop or fail-safe" | |
| 15:46:09 | johnthetubaguy | bauwser: got a pointer to the new one | |
| 15:46:22 | johnthetubaguy | might be better than my previous re-write the world plan | |
| 15:46:24 | dansmith | bauwser: this is harder than soft | |
| 15:46:38 | bauwser | soft is weighting | |
| 15:46:43 | bauwser | hard is filtering | |
| 15:46:54 | bauwser | here they want to have a soft-but-hard | |
| 15:46:57 | dansmith | bauwser: right, this spec specifies something hard, which is filtering, | |
| 15:47:08 | bauwser | bref | |
| 15:47:12 | dansmith | but it weakens the normally hard anti-affinity for some value of allowed overlap | |
| 15:47:16 | dansmith | I really don't like it | |
| 15:47:20 | bauwser | it's unclear and I don't think modifying filters or weighers is a good thing | |
| 15:47:26 | bauwser | yeah exactly that | |
| 15:47:45 | bauwser | instead of hijacking what we currently have, we should discuss on a better approach | |
| 15:47:55 | bauwser | which is what was johnthetubaguy exactly trying to do | |
| 15:48:39 | bauwser | johnthetubaguy: what is the new proposal, tbh I haven't gone thru all specs yet | |
| 15:49:00 | mriedem | i'm not following you | |
| 15:49:25 | mriedem | you can do hard anti affinity and fail if you can't place the VMs on separate hosts, | |
| 15:49:35 | mriedem | you can do soft anti affinity and get more VMs on a host than you'd really like | |
| 15:49:48 | mriedem | this is saying, i want soft but i can only tolerate up to a limit | |
| 15:49:56 | mriedem | or, soft is ok but to a limit | |
| 15:50:00 | dansmith | mriedem: I see it as a variant of hard not soft | |
| 15:50:08 | mriedem | sure, it's in between | |
| 15:50:18 | dansmith | mriedem: it's the same filter has hard but instead of ==0, it's <=$max | |
| 15:50:27 | dansmith | you can't do this with a weigher is my point | |
| 15:50:30 | johnthetubaguy | dansmith: +1 | |
| 15:50:36 | dansmith | and that's what soft anti-affinity is | |
| 15:50:47 | mriedem | a weigher is not being proposed | |
| 15:50:52 | dansmith | I know | |
| 15:50:56 | bauwser | mriedem: soft anti-affinity should never hard-stop | |
| 15:51:19 | bauwser | hard anti-affinity is something we already have | |
| 15:51:21 | mriedem | umm | |