Earlier  
Posted Nick Remark
#openstack-nova - 2022-09-20
16:20:02 sean-k-mooney master is Antelope currently
16:20:12 bauzas sean-k-mooney: from a git PoV, yes
16:20:23 sean-k-mooney and form a schdule point of view
16:20:30 bauzas sean-k-mooney: from an official release calendar, we aren't :D
16:20:31 sean-k-mooney that is why i asked you to update launachpad
16:20:46 bauzas https://releases.openstack.org/antelope/schedule.html
16:20:59 bauzas we're in a grey period of time
16:21:04 bauzas but anyway
16:21:22 bauzas we're in a strong consensus, nothing prevents us to move forward and propose specs and blueprints
16:21:52 bauzas this is said
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 n
16:22:27 gibi +1 to land the default changes soo
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 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 :)

Earlier   Later