| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2022-09-20 | |||
| 16:21:58 | sean-k-mooney | yep and even merging things but hold off on large refactors | |
| 16:22:05 | bauzas | (personnally, I should try to write some spec next week) | |
| 16:22:08 | sean-k-mooney | with that said i want to merge the new defaults change soon | |
| 16:22:27 | gibi | +1 to land the default changes soo | |
| 16:22:27 | gibi | n | |
| 16:22:35 | bauzas | we're officially entering the tick-tock cadence btw. | |
| 16:22:40 | sean-k-mooney | ill try and update that this week https://review.opendev.org/c/openstack/nova/+/830829 | |
| 16:22:49 | bauzas | so yeah, config changes seem appropriate to be done in Antelope | |
| 16:23:26 | bauzas | anyway, moving on | |
| 16:23:34 | bauzas | #link https://etherpad.opendev.org/p/nova-zed-rc-potential Zed RC tracking etherpad | |
| 16:23:45 | bauzas | I'll continue to ping a few people begging for reviews | |
| 16:23:55 | bauzas | but should be seamless | |
| 16:24:04 | bauzas | (just paperworking) | |
| 16:24:13 | bauzas | next topic, | |
| 16:24:20 | bauzas | #topic PTG planning | |
| 16:24:30 | bauzas | as a reminder | |
| 16:24:32 | bauzas | #link https://etherpad.opendev.org/p/nova-antelope-ptg Antelope PTG etherpad | |
| 16:24:40 | bauzas | #link https://ptg.opendev.org/ptg.html PTG schedule | |
| 16:25:09 | bauzas | people are welcome to add any topic they want to address at the PTG | |
| 16:25:33 | bauzas | the earlier we have a solid list of things to discuss, the better it will be for planning in advance when to discuss those | |
| 16:26:02 | bauzas | I have a question, | |
| 16:26:08 | bauzas | shall we use a separate etherpad for ops-friendly sessions on Tuesday and Wednesday ? | |
| 16:26:35 | bauzas | for the moment, in the list of etherpads, we have a specific etherpad for the nova-operator-hours https://etherpad.opendev.org/p/oct2022-ptg-operator-hour-nova | |
| 16:26:59 | bauzas | of course, I can rename it, change it... or point to our developer etherpad | |
| 16:27:22 | bauzas | I personnally feel a separate etherpad would be less scary for ops | |
| 16:27:26 | gibi | if we expect a lot of operator feedback than I think it is better to have it on a separate etherpad | |
| 16:27:36 | gibi | crosslinked with the main nova one | |
| 16:27:38 | bauzas | but in this case, that means we need to come up in advance with a list of topics to address | |
| 16:27:51 | bauzas | gibi: yup, I was thinking this | |
| 16:28:16 | bauzas | ok, looks like it's sold | |
| 16:28:21 | bauzas | noone is arguing | |
| 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 | sean-k-mooney | i have it as a review dashboard in gerrit | |
| 16:33:03 | bauzas | you're more than encouraged to do as well ! | |
| 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 | elodilles | #info stable/yoga is blocked by openstacksdk-functional-devstack job -- proposed fix: https://review.opendev.org/c/openstack/openstacksdk/+/858268 | |
| 16:35:24 | bauzas | :) | |
| 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 | obre | No? | |
| 16:42:21 | sean-k-mooney | to set those values no | |
| 16:42:22 | bauzas | correct ^ | |