| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2023-11-07 | |||
| 16:59:34 | Uggla_ | looking at https://bugs.launchpad.net/nova/+bug/2039381 | |
| 16:59:59 | Uggla_ | do you think it could be linked to a configuration (service token) issue ? | |
| 17:00:21 | bauzas | oh dman, forgot | |
| 17:00:22 | bauzas | I'll end the meeting now, we'll discuss this right after | |
| 17:00:29 | Uggla_ | ok | |
| 17:00:43 | bauzas | thanks all | |
| 17:00:48 | opendevmeet | Log: https://meetings.opendev.org/meetings/nova/2023/nova.2023-11-07-16.02.log.html | |
| 17:00:48 | opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/nova/2023/nova.2023-11-07-16.02.txt | |
| 17:00:48 | opendevmeet | Minutes: https://meetings.opendev.org/meetings/nova/2023/nova.2023-11-07-16.02.html | |
| 17:00:48 | opendevmeet | Meeting ended Tue Nov 7 17:00:48 2023 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | |
| 17:00:48 | bauzas | #endmeeting | |
| 17:00:56 | bauzas | dvo-plv: you have the logs there^ | |
| 17:01:07 | bauzas | Uggla_: so | |
| 17:02:04 | bauzas | Uggla_: did they do the service token thing ? | |
| 17:02:18 | bauzas | now that's mandatory ? | |
| 17:03:09 | Uggla_ | I don't know. But do we do it on devstack ? | |
| 17:04:31 | bauzas | I bet we do | |
| 17:04:57 | bauzas | https://docs.openstack.org/nova/latest/admin/configuration/service-user-token.html | |
| 17:05:05 | gmann | bauzas: FYI, with daylight saving things, nova meeting time conflict with my other appointment so I would not be able to join. If anything for me during meeting, please ping me and i will reply later. | |
| 17:05:05 | bauzas | Uggla_: can you check ? | |
| 17:05:25 | bauzas | gmann: no worries | |
| 17:05:36 | bauzas | DST sucks | |
| 17:05:46 | gmann | yeah :) | |
| 17:06:51 | Uggla_ | bauzas, yes the section is part of my nova.conf (devstack). | |
| 17:07:29 | bauzas | dansmith: sean-k-mooney: very briefly because today is spec review day and you both have other urgencies, please note that none of https://review.opendev.org/q/topic:bug%252F2041519-new actually works since we don't delete existing Resource Providers | |
| 17:07:55 | bauzas | so we need some logic like https://review.opendev.org/c/openstack/nova/+/899625 in order to clean up the no-longer needed RPs | |
| 17:08:25 | bauzas | (talking of upgrades, for sure a greenfields deployment with no existing RPs will correctly create the only needed RPs) | |
| 17:09:21 | dansmith | bauzas: yeah understand we need to clean up the current situation | |
| 17:09:47 | bauzas | anyway, let's not discuss this for now, this is more a fyi | |
| 17:09:53 | bauzas | and we'll revisit that later | |
| 17:11:21 | elodilles | sean-k-mooney: when you'll have time could you please have a quick look at this pip-23.1-support / PBR related patch? https://review.opendev.org/c/openstack/releases/+/900053/7 | |
| 17:14:05 | clarkb | elodilles: see scrollback in #openstack-infra | |
| 17:33:51 | dvo-plv | bauzas, sean-k-mooney, densmith I read logs and my conclusion that we do not have final decision, how I need to managed this? Ping you tomorrow or add this topic to some another meeting? | |
| 17:34:30 | bauzas | usually we let people chime in on Gerrit | |
| 17:35:03 | bauzas | IMHO we clarified exactly the usecases so all people should understand others' concerns | |
| 17:35:08 | elodilles | clarkb: looking | |
| 17:36:58 | dvo-plv | So i need just wait for discussion in the spec comments ? | |
| 17:46:10 | bauzas | dvo-plv: fwiw, sean-k-mooney and I already commented | |
| 17:46:38 | bauzas | maybe dansmith could add his thoughts once he has time (later today or tomorrow) | |
| 17:46:52 | bauzas | in the mean, this doesn't really change what you wrote, | |
| 17:47:00 | bauzas | only the scheduling part may be reworked | |
| 17:47:03 | dansmith | I thought we were going to have a discussion about it? | |
| 17:47:13 | bauzas | dansmith: you had other prios | |
| 17:47:31 | bauzas | if you have time, sean-k-mooney and I are debating on the need for a trait | |
| 17:47:38 | bauzas | I captured my thoughts in gerrit | |
| 17:47:52 | bauzas | I just can't wait for the next feature coming by and asking for the same | |
| 17:48:09 | bauzas | "hey, I wanna be sure we land on libvirt node" | |
| 17:49:06 | bauzas | so my question is, shall we create a trait for every single image property or flavor extra spec that matches a specific libvirt feature ? | |
| 17:49:12 | bauzas | (and a prefilter of course) | |
| 17:50:12 | dansmith | yeah, honestly for a thing that is just based on libvirt version, and especially a thing in a version from the past, I'd hate to get into the habit of doing a new trait for each of those things because it's such a heavyweight process | |
| 17:50:34 | dansmith | so I think I'm leaning more heavily towards a service version and a hypervisor filter for this kind of stuff | |
| 17:50:44 | bauzas | in the past, we left people to configure their clouds the way they wanted if they had mixed virt drivers | |
| 17:50:46 | dansmith | however, gibi also approved the spec with the trait, so might be good to get him to weigh in there | |
| 17:51:05 | bauzas | the spec never got approved, right? | |
| 17:51:50 | dansmith | bauzas: yeah, it's approved | |
| 17:51:50 | dansmith | so I guess I'm less concerned about that specifically | |
| 17:51:50 | dansmith | bauzas: right the mixed hypervisor thing is definitely a concern, but this is also the sort of thing where a flavor isn't likely to work between ironic and libvirt anyway, | |
| 17:51:50 | bauzas | oh my bad, no | |
| 17:52:10 | bauzas | in the past, we leaned towards saying it's the operator responsibility to make the matching that works | |
| 17:52:24 | bauzas | we had aggregates | |
| 17:52:44 | bauzas | so I'm surprised that we now all go full steam on adding traits for such things | |
| 17:53:04 | dvo-plv | yeah, unfortinatelly i did not get finnal decision how I should move with my solution according to your thoughts | |
| 17:53:37 | dansmith | bauzas: yeah I mean sean-k-mooney's point of *not* making it "some assembly required" definitely resonates with me- I want us to do the right thing when we can | |
| 17:54:28 | dansmith | and I do not think we assert that all the extra specs are schedulable | |
| 17:54:28 | bauzas | dvo-plv: I'm sorry I went into trampling your previous approval, but I guess my disapproval is more about the pattern we follow than your own spec itself | |
| 17:54:28 | dansmith | but a trait is pretty heavy for each "just need a new libvirt version" sort of thing, | |
| 17:54:53 | bauzas | dansmith: yeah, so let's do some kind of automatic filter that would say 'I'm libvirt specific, please give me a libvirt thingies' | |
| 17:55:16 | bauzas | if we reconsider the operator experience and the burden of setting aggregates | |
| 17:56:36 | dansmith | I gotta jump to my next thing, but yeah I think I agree | |
| 17:57:54 | bauzas | fwiw, we have filters that do mappings between flavors/images and aggregates | |
| 17:59:03 | bauzas | operators could just amend their 'libvirt' aggregates by adding an agg property equal to hw:virtio_packed_ring and problem is solved | |
| 17:59:27 | bauzas | but that's adding some operator burden I don't disagree | |
| 17:59:31 | dvo-plv | its okay, never mind | |
| 19:17:15 | sean-k-mooney | bauzas: i think a post schduler filter is far to heavy weight for this | |
| 19:17:58 | sean-k-mooney | we can do a min compute server version check if we really want | |
| 19:18:23 | sean-k-mooney | i feel like that is the midel gorund we can all live with but that means makign this feature unaviabel during the upgrade to caracal | |
| 19:18:43 | sean-k-mooney | i think that is an ok requirement but its somethign we could have supproted via the trait if we wanted too | |
| 19:28:36 | bauzas | you know what ? I'm tired of this, so let's just use the trait | |
| 19:30:01 | bauzas | I'll just don't +2 the spec | |
| 21:11:55 | gmann | sean-k-mooney: just in case you missed these virt driver deprecation backport https://review.opendev.org/q/topic:deprecate-virt-drivers+status:open | |
| #openstack-nova - 2023-11-08 | |||
| 02:16:13 | opendevreview | Merged openstack/nova stable/victoria: reenable greendns in nova. https://review.opendev.org/c/openstack/nova/+/833436 | |
| 08:25:36 | zigo | stephenfin: Hi there! How are you? | |
| 08:25:37 | zigo | Where is tracked the SQLAlchemy 2.x patches, so I can attempt backporting them to Bobcat in Debian? | |
| 08:41:12 | bauzas | zigo: I can help, all changes for support SQLA2 'language' in SQL1.4 are in this gerrit topic https://review.opendev.org/q/topic:sqlalchemy-20 | |
| 08:42:09 | zigo | Ah, thanks a lot, will try. | |
| 08:42:37 | zigo | Gosh... too many... how do I know what's missing from Bobcat? | |
| 08:46:32 | bauzas | what do you exactly want to backport ? | |
| 08:46:46 | bauzas | sqla changes that were merged after Bobcat RC1 ? | |
| 08:46:59 | zigo | Yeah. | |
| 08:47:18 | bauzas | all projects or just nova ?. | |
| 08:47:23 | zigo | All projects. | |
| 08:47:32 | zigo | Maybe I can just use the date of last change ... | |
| 08:47:51 | bauzas | well, the RC1 date is different for every project, that's the point | |
| 08:48:02 | bauzas | sec | |
| 08:48:02 | bauzas | but I can filter out the gerrit query | |
| 08:48:33 | zigo | Oh, there's a way to know with a simple Gerrit query? :) | |
| 08:50:51 | bauzas | for sure | |
| 08:51:28 | bauzas | I was looking at some query field that would be 'includedin' but I can't find it so I'll just use mergedafter | |
| 08:51:58 | bauzas | and you'll just compare with the list of merged patches to see whether we missed any patch during the RC period | |
| 08:52:35 | zigo | I can just compare the code, yeah ... | |