Earlier  
Posted Nick Remark
#openstack-nova - 2023-01-10
16:53:42 bauzas #topic Open discussion
16:53:46 bauzas (bauzas) As a reminder, Summit proposals deadline is today 11:59pm PT
16:53:57 elodilles so if we release now zed, then the operators who uses zed, need to update their configs to have NOT to change how nova works
16:53:59 bauzas you have the very last minute to add your topics
16:54:26 bauzas fwiw, I proposed two forum sessions about nova onboarding and operator meet&greet
16:54:41 bauzas if someone wants to co-host the onboarding forum session, let me know
16:55:19 bauzas gmann: correct me but forum proposal deadline is on april ?
16:55:37 bauzas I'm confused by the fact they added the forum proposals in the tool
16:55:42 gmann bauzas: I hope so. I asked Erin in email but no reply yet. But from form it shows april
16:55:54 bauzas yup, hence my confusion
16:56:31 kashyap Oh, come on...after all the jobs passed, one "tempest-integrated-compute" job times out :( https://zuul.opendev.org/t/openstack/build/8b07fa0b71c94fb6abb2b350c5c84c74
16:56:31 bauzas I just hope we won't get like Berlin some Forum sessions that very look like Summit sessions with slides and one-sided discussions
16:56:44 bauzas kashyap: on our meeting atm
16:56:45 kashyap Oops, sorry for that random chime in.
16:56:52 kashyap bauzas: Yeah, only realized it just now (sorry)
16:56:56 bauzas np
16:57:00 bauzas (gmann) updates on switching the RBAC(scope and new defaults) defaults in nova
16:57:08 gibi bauzas: if you need a co-host for the onboarding then you can write me up
16:57:09 bauzas you have 3 mins
16:57:36 bauzas gibi: noted. I'm used to do some onboarding and I have ideas but having a co-speaker is somehow better
16:57:44 gibi sure
16:58:07 bauzas looks like gmann is gone and our meeting will end
16:58:14 gmann patch is ready for review #link https://review.opendev.org/c/openstack/nova/+/866218/12
16:58:19 bauzas cool thanks
16:58:40 bauzas gmann: I've seen your ping, I just didn't had time to review it yet
16:58:44 gmann please check and it need placement test fixture change too which is depends-on on nova change #link https://review.opendev.org/c/openstack/placement/+/869525/3
16:59:05 gmann do not want to delay the switching at the end of cycle
16:59:32 bauzas I've just said review-prio +2
16:59:44 gmann Tempest already run integration job with new RBAC on Nova, glance, neutron and cinder and it is passing finw
16:59:48 gmann thanks
16:59:51 bauzas \o/
17:00:03 opendevreview Pavlo Shchelokovskyy proposed openstack/nova master: Process all nodes when host aggregate changes https://review.opendev.org/c/openstack/nova/+/869687
17:00:15 bauzas ok, we're on time
17:00:16 bauzas thanks all
17:00:20 opendevmeet Log: https://meetings.opendev.org/meetings/nova/2023/nova.2023-01-10-16.00.log.html
17:00:20 opendevmeet Minutes (text): https://meetings.opendev.org/meetings/nova/2023/nova.2023-01-10-16.00.txt
17:00:20 opendevmeet Minutes: https://meetings.opendev.org/meetings/nova/2023/nova.2023-01-10-16.00.html
17:00:20 opendevmeet Meeting ended Tue Jan 10 17:00:20 2023 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
17:00:20 bauzas #endmeeting
17:00:22 gibi o/ thanks'
17:00:43 elodilles thanks o/
17:00:58 gmann thanks o/
17:01:18 clarkb re nox it is definitely worth careful consideration and discussion. I like to bring it up ecause I've found many people aren't aware there is an alternative. As far as why I think it is worth considering the main thing is that it is simpler and uses simple building blocks instead of a bunch of custom rewrites of standard tools like build
17:01:30 clarkb when you install things you just run pip basically.
17:01:45 clarkb and you aren't getting custom wheel building like with tox for example
17:02:44 gmann bauzas: dansmith: this is tempest job enabling new rbac and passing fine. I am adding same in nova side too in 866218 https://zuul.openstack.org/builds?job_name=tempest-full-enforce-scope-new-defaults&skip=0
17:04:13 sean-k-mooney johnthetubaguy: can you review this ironic hostaggreate change https://review.opendev.org/c/openstack/nova/+/869687
17:04:31 sean-k-mooney bauzas: ^ also good for you to look at
17:04:57 sean-k-mooney bauzas: did we settel on ironic is not supprot for host aggreates a while ago when chatting downstream
17:06:35 bauzas sean-k-mooney: I thought we said given we only support hostnames in aggregates (and not nodenames), I hardly understand how this can work
17:07:15 bauzas but you can target a specific nova-compute using aggregates so that can still work with sharded ironic nodes
17:07:41 sean-k-mooney when you add a comptue host to thet api https://docs.openstack.org/api-ref/compute/?expanded=add-host-detail#add-host
17:07:46 sean-k-mooney you are adding the comptue service
17:07:59 sean-k-mooney and ironic is currently loadbalanceing compute nodes between compute services
17:09:37 bauzas agreed, that's what I said
17:09:51 bauzas but you can't target a node, that's my point
17:10:19 bauzas the good news is that placement aggregates support nodes
17:10:45 sean-k-mooney right so what they are trying to do in that patch is incluse all the ironic RPs created for the ironic servier in the the placement aggreate
17:10:50 bauzas so theorically, you could do some flavorey query about it
17:11:16 sean-k-mooney you coudl but if we proceed with this patch we are baissly saying we now supprot host aggrates with ironic again
17:11:29 sean-k-mooney im pretty sure we did in the past and that broke at some point
17:11:59 sean-k-mooney where somepoint is a long long time ago
17:12:47 bauzas long long time ago, we were not having placement aggregates
17:13:09 bauzas and if I blame the existing add_host_to_agg code, I don't think I'll see a difference
17:14:02 sean-k-mooney didnt we used to have multipel compute services for ironic ndoes or something
17:15:40 bauzas I don't think so but I could be wrong
17:16:43 sean-k-mooney ok your right we did not
17:16:45 sean-k-mooney https://specs.openstack.org/openstack/nova-specs/specs/juno/implemented/add-ironic-driver.html#proposed-change
17:16:53 sean-k-mooney it was intially one compute service
17:17:20 sean-k-mooney then we supported muple in newton https://specs.openstack.org/openstack/nova-specs/specs/newton/implemented/ironic-multiple-compute-hosts.html
17:20:56 sean-k-mooney i guess based on https://specs.openstack.org/openstack/nova-specs/specs/newton/implemented/cells-aggregate-api-db.html
17:21:11 sean-k-mooney the aggreate api si ment ot be aggreate to compute node mappings
17:21:21 sean-k-mooney in which case then yes ironci shoudl work
17:21:37 sean-k-mooney you just need to add each node by the ironic uuid
17:21:49 sean-k-mooney however that is what we tried downstream and it did not seam to work
17:21:58 sean-k-mooney and i recal that that used to work before
17:23:19 bauzas that's what I remember when we discussed about placement aggs
17:23:41 bauzas in general, we only support the first node
17:23:48 sean-k-mooney well for nova aggreates ignoring placment that is what used to work in newton
17:24:10 sean-k-mooney we coudl map compute nodes to aggates by the host key
17:24:30 sean-k-mooney which presumable was hypervior_hostname
17:24:39 bauzas no
17:24:51 bauzas host was in general the Host conf opt
17:25:03 sean-k-mooney that would have been the compute service then not the comptue node
17:25:08 bauzas always
17:25:14 sean-k-mooney the usecase says "Operators wish to apply the same host aggregate to compute nodes in multiple cells."
17:25:25 bauzas that was always the service
17:25:42 bauzas because hostname key is about the n-cpu service
17:25:55 sean-k-mooney the spec does not say service. an by the way im agreein gi tought this was also the service not the comptue node
17:26:45 sean-k-mooney so the problem is context the pec that created the db table repataly says compute node
17:26:55 sean-k-mooney so maybe the spec is wrong or not what we implemnted
17:27:15 bauzas "Aggregates may be applied to compute nodes in multiple cells and are a global concept."
17:27:20 bauzas this phrase is wrong
17:27:40 sean-k-mooney right but this spec neverf mention compute services
17:27:40 bauzas Placement aggregates relate to resource providers
17:27:43 sean-k-mooney only compute nodes
17:27:52 bauzas Nova aggregates related to nova-compute services
17:27:57 sean-k-mooney so if i read the spec the intent seams to be to mapp compute nodes
17:28:00 bauzas relate*
17:28:20 bauzas sean-k-mooney: the intent of that spec was to put the aggregates table to the API DB

Earlier   Later