| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2022-09-20 | |||
| 16:28:22 | bauzas | but, | |
| 16:28:56 | bauzas | this also means I feel we should do a bit of team brainstorm about what we'd like to discuss with ops at those hours | |
| 16:29:09 | bauzas | don't tell me "pain points" this is the easiest | |
| 16:29:22 | gibi | <del> <del> <del> | |
| 16:29:46 | bauzas | anyway, I'll draft something before next week | |
| 16:29:54 | bauzas | and we could discuss this then | |
| 16:30:01 | gibi | open an etherpad and ping us with it I can put in some questions | |
| 16:30:11 | bauzas | #action bauzas to draft some agenda for nova-operator-hours etherpad | |
| 16:30:30 | bauzas | gibi: etherpad is already created, I just left the standard url | |
| 16:30:35 | gibi | ack | |
| 16:30:49 | bauzas | (the foundation pre-creates all the PTG project etherpads) | |
| 16:31:08 | bauzas | well, "precreates" is actually just a matter of generating an URL | |
| 16:31:37 | bauzas | anyway, moving on | |
| 16:31:50 | bauzas | #topic Review priorities | |
| 16:31:57 | bauzas | #link https://review.opendev.org/q/status:open+(project:openstack/nova+OR+project:openstack/placement+OR+project:openstack/os-traits+OR+project:openstack/os-resource-classes+OR+project:openstack/os-vif+OR+project:openstack/python-novaclient+OR+project:openstack/osc-placement)+(label:Review-Priority%252B1+OR+label:Review-Priority%252B2) | |
| 16:32:44 | bauzas | I'm happy to see sean-k-mooney using it :) | |
| 16:32:50 | bauzas | and takashi too | |
| 16:33:03 | bauzas | you're more than encouraged to do as well ! | |
| 16:33:03 | sean-k-mooney | i have it as a review dashboard in gerrit | |
| 16:33:20 | bauzas | sean-k-mooney: yeah, that's one possibility | |
| 16:33:47 | sean-k-mooney | i have two i use commonly to look for reviews | |
| 16:33:57 | bauzas | anyway, nothing to mention here ? | |
| 16:34:02 | sean-k-mooney | the nova-priorty one and another one i got form stephen year ago | |
| 16:34:38 | sean-k-mooney | nothing that cant wait until we are out of rc period | |
| 16:34:52 | bauzas | cool | |
| 16:35:01 | bauzas | #topic Stable Branches | |
| 16:35:05 | bauzas | elodilles: shoot | |
| 16:35:07 | elodilles | yes | |
| 16:35:12 | elodilles | i had a quick look, | |
| 16:35:18 | elodilles | so here is a quick update :) | |
| 16:35:24 | bauzas | :) | |
| 16:35:24 | elodilles | #info stable/yoga is blocked by openstacksdk-functional-devstack job -- proposed fix: https://review.opendev.org/c/openstack/openstacksdk/+/858268 | |
| 16:35:28 | elodilles | new fix ^^^ | |
| 16:35:36 | elodilles | #info stable/stein (and older) are blocked: grenade and other devstack based jobs fail with the same timeout issue as stable/train was previously | |
| 16:35:47 | elodilles | #info stable branch status / gate failures tracking etherpad: https://etherpad.opendev.org/p/nova-stable-branch-ci | |
| 16:35:56 | elodilles | and that's it :X | |
| 16:36:34 | bauzas | thanks | |
| 16:36:39 | elodilles | np | |
| 16:37:08 | bauzas | last topic | |
| 16:37:13 | bauzas | #topic Open discussion | |
| 16:37:22 | bauzas | Add support for setting min/max unit for the VCPU and MEMORY_MB resource-providers in placement to values other than 1/all. Can configuration-options be OK for this, or are other approaches prefferred? See suggested use of configuration-options at https://review.opendev.org/c/openstack/nova/+/857595 | |
| 16:37:41 | bauzas | unfortunately, the write hasn't written his nick | |
| 16:37:44 | bauzas | but we can guess | |
| 16:37:47 | obre | Its me :) | |
| 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 | |