| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2022-09-20 | |||
| 16:38:20 | gibi | obre: o/ | |
| 16:38:31 | bauzas | obre: yeah I was looking for your nick | |
| 16:38:32 | obre | The use-case is basicly to allow restricting some compute-nodes to not get VM's using too many of its VCPU's. | |
| 16:38:52 | obre | To better spread out load. | |
| 16:39:06 | obre | I tested that changing these values give the desired outcome. | |
| 16:39:11 | gibi | so I quickly dicussed with obre before and suggested extending provider.yaml but that might be a bigger work than what obre's use case needs | |
| 16:39:36 | bauzas | I'm not fan of adding yet another knob to this | |
| 16:39:51 | bauzas | so, yeah, provider.yaml or accepting that inventories can change from a client perspective | |
| 16:40:05 | obre | It is a similar knob to the one we have setting over-provisioning of resources. | |
| 16:40:23 | bauzas | obre: sure, but we designed placement for avoiding such knobs :) | |
| 16:40:49 | sean-k-mooney | so we really shoudl not allow this to be configurable | |
| 16:40:58 | gibi | bauzas: I'm not sure but I assume that today nova would periodically overwirte max_unit in placement for inventories its own | |
| 16:41:09 | bauzas | gibi: correct | |
| 16:41:10 | obre | I can confirm that assumption :) | |
| 16:41:17 | gibi | obre: thanks :) | |
| 16:41:38 | obre | So that logic needs to change then; in addition to allowing setting other inventorys than CUSTOM_* | |
| 16:41:43 | sean-k-mooney | so the usecase here is to limit the max size of a flavor | |
| 16:41:47 | bauzas | gibi: that's why I was saying that if operators want this to be tunable thru API calls, some efforts have to be done | |
| 16:41:48 | sean-k-mooney | that can land on a host | |
| 16:41:52 | obre | Either max or min. | |
| 16:42:11 | sean-k-mooney | so we can do that today | |
| 16:42:18 | sean-k-mooney | using provider.yaml | |
| 16:42:21 | sean-k-mooney | to set those values no | |
| 16:42:21 | obre | No? | |
| 16:42:22 | bauzas | correct ^ | |
| 16:42:38 | bauzas | we have a configurable | |
| 16:42:41 | bauzas | not an API call | |
| 16:42:41 | gibi | I think we cannot set those value on standard resources | |
| 16:42:51 | obre | You are only allowed to set CUSTOM_*. Setting VCPUs for instance would make nova-compute refuse to start. | |
| 16:42:56 | sean-k-mooney | gibi: i would be ok with lifting that restriction | |
| 16:43:00 | bauzas | hah, my bad then | |
| 16:43:05 | sean-k-mooney | but not adding a new config to nova for this | |
| 16:43:07 | bauzas | sean-k-mooney: yeah, me too | |
| 16:43:10 | bauzas | and yeah | |
| 16:43:32 | bauzas | if operators want to play with nova inventories, I'm OK with this | |
| 16:43:39 | gibi | sean-k-mooney: yepp, that was my suggestion to obre too, lift the provider.yamls restriction | |
| 16:43:43 | bauzas | placement was designed for such usecases | |
| 16:43:48 | obre | But then you would like to lift that restriction, and then have nova-compute check its inventories before setting the default-values if none exists? | |
| 16:44:34 | sean-k-mooney | yes nova compute | |
| 16:44:46 | sean-k-mooney | would instead of hardcoding its min/max/step values | |
| 16:44:51 | gibi | yepp | |
| 16:44:51 | obre | Basicly similar to how we do allocation_ratios; just without the config-file option. | |
| 16:44:52 | sean-k-mooney | get tehm form provider.yaml | |
| 16:45:26 | obre | Im not entirly sure I am able to figure all this out by myself; but Ill give it a try; and see if I can manage to write such a patch :) | |
| 16:45:59 | gibi | obre: feel free to ping me here with questions. I can try to look at the code and help | |
| 16:46:43 | obre | gibi: Thanks! | |
| 16:46:46 | obre | gibi: I probably will. | |
| 16:46:48 | gibi | I'm sure we have some unit / functional test coveragae on provider.yaml to play with | |
| 16:47:07 | sean-k-mooney | we will need to modify the schma | |
| 16:47:23 | bauzas | looks like we have an agreement and further steps to | |
| 16:47:37 | sean-k-mooney | and introduce a new adjective(exisitng) https://specs.openstack.org/openstack/nova-specs/specs/ussuri/approved/provider-config-file.html#provider-config-file-schema | |
| 16:47:43 | bauzas | obre: the next step for you I guess is to write a blueprint | |
| 16:48:01 | sean-k-mooney | and then lift the resticion on the resouce_class startign with CUSTOM_ | |
| 16:48:07 | sean-k-mooney | so this would likely need a spec | |
| 16:48:15 | bauzas | I was debating it | |
| 16:48:16 | sean-k-mooney | to spell it out clearly | |
| 16:48:39 | sean-k-mooney | it will need a new schema_version at a minium | |
| 16:49:00 | gibi | I agree to have a small spec if we need to figure out a new schema | |
| 16:49:02 | sean-k-mooney | i think there is enough of a change required that a spec would be helpful for documentation if nothing elses | |
| 16:49:09 | bauzas | #agreed sounds a valid usecase that requires a blueprint and a spec to be filled in order to address how to properly manage inventories override by placement.yaml file | |
| 16:49:33 | bauzas | obre: do you feel comfortable with this process ? do you need help ? | |
| 16:49:50 | bauzas | or is that whole think old greek to you ? | |
| 16:49:55 | bauzas | thing* | |
| 16:50:03 | obre | bauzas: Ill probably need a bit of help yes. | |
| 16:50:11 | bauzas | obre: you got my nick | |
| 16:50:20 | obre | bauzas: Im not really a developer; more a sysadmin :P | |
| 16:50:22 | bauzas | obre: ping me tomorrow and I'll point you some docs and examples | |
| 16:50:32 | obre | bauzas: Whats your timezone? | |
| 16:50:41 | bauzas | obre: well, specs are formal textfiles, so you shouldn't be afraid :) | |
| 16:50:50 | bauzas | obre: CEST | |
| 16:51:06 | bauzas | that matches then | |
| 16:51:09 | obre | So then the workdays probably sync up :P | |
| 16:51:20 | bauzas | I'm more than happy to help you | |
| 16:51:26 | obre | bauzas: Great! | |
| 16:51:41 | bauzas | our processes can look a bit scary but those are just design documents | |
| 16:52:11 | obre | Ill sorta understand why we need the formal process; Its just that I would have preffered an easier solution for _my_ problems :P | |
| 16:52:11 | bauzas | basically, the idea is just to identify all potential design concerns (upgrades or others) before they come up at review time | |
| 16:52:18 | obre | But its fine :P | |
| 16:52:32 | gibi | :) | |
| 16:52:34 | bauzas | obre: you're litterally at the very beginning of the cycle :) | |
| 16:52:45 | bauzas | so, you wouldn't hear 'sorry, too late' | |
| 16:53:08 | bauzas | the point is, you have gibi and me for helping you out | |
| 16:53:14 | obre | \o/ | |
| 16:53:16 | sean-k-mooney | obre: one thing to think about is do you want this to be config driven. api driven or both | |
| 16:53:25 | sean-k-mooney | we will need to document tha tin the spec | |
| 16:53:29 | bauzas | sean-k-mooney: I tought we said config-driven | |
| 16:53:33 | bauzas | as provider.yaml | |
| 16:53:46 | sean-k-mooney | yes but provide.yaml can say -1 | |
| 16:53:51 | sean-k-mooney | which means this is api contoled | |
| 16:53:57 | sean-k-mooney | or something like that if we care about that usecase | |
| 16:54:02 | bauzas | making it api-driven means we accept our inventories to be changed thru osc-placement | |
| 16:54:09 | sean-k-mooney | so im assuming config driven is enough | |
| 16:54:12 | obre | I think it makes sense to be as close to the way we do CUSTOM_* today as possible? | |
| 16:54:16 | sean-k-mooney | and if so the that simple | |
| 16:54:27 | bauzas | stick to the bare minimum requirements :) | |
| 16:54:45 | bauzas | people could come up with api-driven needs later if they want to :) | |
| 16:54:54 | sean-k-mooney | ok just that was going to be one of the question si would ask in the spec review | |
| 16:55:01 | sean-k-mooney | so i didnt want it to come out of the blue | |
| 16:55:16 | bauzas | sean-k-mooney good point, stating that api-driven is out of the spec seems reasonable | |
| 16:55:39 | sean-k-mooney | yep we can state is as not a usecase we want to enabel now in the alternitives | |