| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-10-23 | |||
| 20:14:03 | cdent | artom: yup | |
| 20:14:19 | jaypipes | mriedem: right after I shoot myself in the head from looking at Chef recipe bullshit. | |
| 20:17:34 | melwitt | mriedem: just so I'm clear, does the initial allocation ratios spec cover the ability to set per aggregate allocation ratios? https://review.openstack.org/552105 I mean, I know it's not called out in the spec, but does the spec allow it to work as a side effect? | |
| 20:18:11 | melwitt | or is there more work or another spec we would need to restore per aggregate allocation ratio abilities? | |
| 20:19:38 | sean-k-mooney | melwitt: i think that would be a different spec. but if the desire for aggragate allocation ratios was just to be able to set it via an api then plament does that | |
| 20:20:43 | melwitt | yeah, that's what I mean, if it's already possible to set allocation ratio per aggregate in placement, then I guess after the spec I linked is implemented, users will have what they need to do it | |
| 20:21:56 | sean-k-mooney | melwitt: well no thats not possible but you can prgramtclly set an allocation via the api. you would have to loop over the RPs in the placement aggreate to set them via the placemetn api to get the same effect as nova old aggreate allocation ratios | |
| 20:22:15 | mriedem | melwitt: no | |
| 20:22:29 | mriedem | melwitt: you're looking for https://review.openstack.org/544683 | |
| 20:22:32 | mriedem | which doesn't have an owner | |
| 20:22:38 | mriedem | and is contentious in implementation | |
| 20:22:45 | melwitt | urgh | |
| 20:23:07 | sean-k-mooney | cdent: misusing your spec to help with ^ | |
| 20:23:42 | sean-k-mooney | any opion on /resource_providers?having=VCPU&member-of=Y | |
| 20:24:26 | sean-k-mooney | so that in osc-placement we could say somthing like " set allocation ration for all resocue class X in aggreate Y" | |
| 20:24:55 | mriedem | t aggregates, this would build on that for mirroring the allocation ratios as well if *_allocation_ratio was set on a compute host aggregate in nova. | |
| 20:24:55 | mriedem | melwitt: i think the summary on https://review.openstack.org/#/c/544683/ is that it's all possible outside of nova; adding it within nova was desirable as a proxy since we have a host aggregates API already with rbac, which placement didn't have until rocky. in dublin we said a simple meta CLI could be added to osc-placement to do this for people, but that didn't happen. but since we mirror the compute host aggregates to plac | |
| 20:27:03 | melwitt | ok, so that's what the "proxy" talk was about. so the proxy would still have to set a ratio per RP, there's no concept of an aggregate spanning ratio | |
| 20:27:06 | sean-k-mooney | mriedem: the meta cli being somting like "openstack placement allocation ratio set 1.0 --class VCPU --mem-of <my aggreate>" | |
| 20:27:38 | mriedem | melwitt: correct | |
| 20:27:53 | mriedem | resource provider aggregates in placement are just a group of linked providers, there is no metadata about the aggregate | |
| 20:27:53 | openstackgerrit | Merged openstack/nova-specs master: Add .idea folder to .gitignore https://review.openstack.org/581611 | |
| 20:28:36 | mriedem | so the upside to nova doing the proxy is you get back to what we had before we broke this, and you only have to set aggregate allocation ratios in one place, rather than both nova and placement separately. | |
| 20:28:37 | melwitt | hm. trying to think how the old filters worked, how did operators express the per aggregate ratio /me looks for it | |
| 20:28:42 | mriedem | the downside is it's more proxy stuff in the comptue API | |
| 20:28:54 | mriedem | they do it with metadata on the host aggregate | |
| 20:29:12 | melwitt | ok, I understand now | |
| 20:29:17 | mriedem | https://docs.openstack.org/nova/latest/admin/configuration/schedulers.html#aggregateramfilter | |
| 20:29:51 | mriedem | "If the host is in more than one aggregate and thus more than one value is found, the minimum value will be used." | |
| 20:29:56 | mriedem | i don't know if jay's spec deals with that | |
| 20:32:11 | melwitt | thinking... | |
| 20:32:46 | melwitt | if you're only interested in per aggregate ratios, then you'd only need to set them in placement and not nova, I think | |
| 20:33:30 | melwitt | so maybe the scenario of "set them in both nova and placement separately" would be a rare one | |
| 20:34:12 | jaypipes | melwitt: as long as nova doesn't overwrite them over and over again.. | |
| 20:34:35 | melwitt | you're either going to be setting them in nova, or in placement, depending on whether you want to do it per compute (or via conf) or per aggregate (or via API) | |
| 20:34:38 | mriedem | right, so if you manage this via the api you don't set the config overrides (iweb case) | |
| 20:34:44 | mriedem | if you're cern, you only use config and not the api | |
| 20:34:48 | mriedem | but we don't support both | |
| 20:34:52 | mriedem | if set, config takes precedence | |
| 20:34:57 | melwitt | right. and if you're oath, you'd use only the api and not the conf | |
| 20:35:06 | jaypipes | mriedem, melwitt: my light at the end of this tunnel is that jules is making kielbasa and cabbage for dinner, which is one of my favorites. yum. | |
| 20:35:17 | mriedem | i can smell your house from here | |
| 20:35:29 | jaypipes | mriedem: you'll be able to smell it in the morning too. | |
| 20:35:29 | melwitt | ok, I see. based on this, I think maybe we shouldn't try to proxy. it doesn't seem like it would buy much even for users | |
| 20:35:34 | mriedem | hi-o | |
| 20:35:37 | jaypipes | lol | |
| 20:35:54 | mriedem | melwitt: well you probably want to run that by mgagne | |
| 20:36:06 | melwitt | and penick | |
| 20:36:43 | melwitt | yeah, I'm just speculating here. will definitely want to talk to them and see if they would be ok with a placement CLI that can fan out to aggregate RPs | |
| 20:37:12 | melwitt | or if being able to set the aggregate metadata is really that valuable to them | |
| 20:37:27 | jaypipes | mriedem: how will melwitt get ahold of penick, though? | |
| 20:37:39 | jaypipes | mriedem: he is a tough cookie to track down. | |
| 20:37:40 | mriedem | paper airplane? | |
| 20:37:45 | jaypipes | hehe | |
| 20:37:47 | melwitt | yeah, that part will be tough. I don't know him that well | |
| 20:38:01 | jaypipes | melwitt: you can set five upon him. | |
| 20:38:37 | jaypipes | for some reason I always think of He-Man's Attack Cat when I picture Five... | |
| 20:38:45 | mriedem | melwitt: it is important to mgagne because they allow non-admin users access to set host aggregate allocation ratios via the API | |
| 20:38:55 | melwitt | jaypipes: lol battlecat, that's awesome | |
| 20:38:56 | mriedem | that's why the RBAC need was big in placement for mgagne | |
| 20:39:04 | jaypipes | melwitt: battlecat, right :) | |
| 20:39:16 | melwitt | I had a battlecat, so cool | |
| 20:40:19 | melwitt | jaypipes: have you watched that "toys that made us" show on netflix? they have one that has the he-man toy line. I found it really interesting | |
| 20:40:44 | melwitt | mriedem: ahhh ok | |
| 20:42:08 | jaypipes | melwitt: hmm, no... sounds like it would be good to watch, though! | |
| 20:42:40 | melwitt | there's only like 4 episodes, I watched em all | |
| 20:44:12 | melwitt | the more I think about it, I'm like proxying isn't so terrible either is it? being that we're already mirroring aggregates anyway. setting the ratios would be a small extra step, it seems. but if placement has RBAC, then would mgagne be happy... hrm. | |
| 20:49:45 | jaypipes | all that hard work I did this morning from 3:30am - 8am in reducing my browser tab count by 63 tabs has been slowly destroyed again. | |
| 20:50:13 | melwitt | you were working at 3:30am?? | |
| 20:51:58 | mriedem | cdent: if you have people internally that still care about these https://review.openstack.org/#/c/552190/ https://review.openstack.org/#/c/549067/ you might want to kick them to update them for stein | |
| 20:52:14 | cdent | mriedem: i've kicked them several times to no avail | |
| 20:52:23 | mriedem | shall i drop the abandon hammer then? | |
| 20:52:29 | mriedem | that way you're not the bad guy | |
| 20:52:51 | cdent | mriedem: meh, I'd let them ride a bit longer, might still be a chance | |
| 20:53:42 | jaypipes | melwitt: yeah, couldn't sleep. | |
| 20:53:59 | mriedem | overcommitting a dedicated pcpu... https://review.openstack.org/#/c/599957/ seems...odd | |
| 20:54:08 | jaypipes | BTW, I have COMPLETELY failed in my sean-k-mooney spellchecker powers today. | |
| 20:54:11 | mriedem | isn't that an oxymoron? | |
| 20:54:45 | mriedem | oxymoron = overcommitted dedicated pcpu | |
| 20:54:48 | melwitt | thinking about that hurts my brain | |
| 20:54:54 | jaypipes | mriedem: yeah, it is, and I chatted with tpatil about that in Denver | |
| 20:55:14 | melwitt | definitely sounds contradictory | |
| 20:55:31 | jaypipes | mriedem: mostly they just need the whole "allow a single compute host to have dedicated stuff and non-dedicated stuff on the same box" thing | |
| 20:55:48 | jaypipes | mriedem: I doubt Tushar will follow up on that spec. | |
| 20:55:53 | mriedem | and then PCPU inventory has an allocation_ratio>1.0? | |
| 20:56:48 | mriedem | b/c this spec https://review.openstack.org/#/c/599957/ is all about many new config options | |
| 20:56:54 | mriedem | which kinda sucks | |
| 21:00:38 | melwitt | they're saying two of the options (cpu_dedicated_set, cpu_shared_set) come from a different spec though, `Standardize CPU resource tracking` | |
| 21:02:22 | melwitt | so only the cpu_pinning_allocation_ratio would be new. which really I guess is meaning pcpu_allocation_ratio, whereas the existing cpu_allocation_ratio technically means vcpu_allocation_ratio? | |
| 21:03:18 | melwitt | so that they separate handling of vcpu vs pcpu | |
| 21:05:38 | melwitt | also interesting, it says based on the prereq spec https://review.openstack.org/#/c/555081 that PCPU inventory will be created with hardcoded allocation ratio of 1.0 and they want to be able to change it/overcommit it. so wouldn't that just be a call to the placement API? | |
| 21:06:45 | melwitt | but I guess they want to be able to set it the same way as is possible for VCPU | |
| 21:06:55 | melwitt | via nova.conf | |
| 21:36:09 | mriedem | edleafe: all sorts of API gross for you to munch on here https://review.openstack.org/#/c/580336/4 | |
| 21:41:09 | cfriesen | I think my question about the "overcommit PCPUs" idea is what does it buy you that a low CPU overcommit ratio (with non-dedicated cpus) wouldn't? | |
| 21:46:40 | sean-k-mooney | jaypipes: haha was there a partical pharse that exausted the spellchecking ablity today :) | |
| 21:48:53 | sean-k-mooney | cfriesen: over commiting pinned cpus i think would be less objectionable but the fact we choose hw:cpu_policy=dedicated|shared and not hw:cpu_policy=pinned|floating makes me dislike the idea | |
| 21:49:16 | edleafe | mriedem: gee thanks! | |
| 21:52:29 | cfriesen | sean-k-mooney: once you have more than one instance using a cpu, it's shared. I don't see what this would buy us compared to just using a shared CPU | |
| 21:54:45 | sean-k-mooney | cfriesen: well i very limited cases it may improve you performance as pinning will result in numa affinity for leagacy reasons but i would personally prefer hw:cpu_policy=share + hw:numa_nodes=1 | |