| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2023-11-07 | |||
| 16:53:58 | gibi | sean-k-mooney: no DB change is needed afaik | |
| 16:54:03 | bauzas | and this is per-computes ? | |
| 16:54:06 | dansmith | gibi: cool, ++ for specless BP from me | |
| 16:54:16 | gibi | bauzas: this is per compute for the incoming migrations | |
| 16:54:19 | sean-k-mooney | dont we look up the remote systme "connection" info via fiels in the obejct | |
| 16:54:22 | sean-k-mooney | that are stored in teh db | |
| 16:54:28 | gibi | it is in the migration object | |
| 16:54:32 | gibi | we store the IP there today | |
| 16:54:34 | gibi | as a string | |
| 16:54:39 | dansmith | but it's just a string, AFAIK | |
| 16:54:43 | sean-k-mooney | right so will the content of that change | |
| 16:54:44 | bauzas | yeah | |
| 16:54:46 | gibi | now it will be either IP or a hostname | |
| 16:54:54 | sean-k-mooney | ok that is what i was wondering about | |
| 16:55:12 | bauzas | and we said it was opt-in | |
| 16:55:18 | sean-k-mooney | ok provided we dont assume that its an ip anywhere today | |
| 16:55:19 | bauzas | so this is not a breaking upgrade change | |
| 16:55:23 | sean-k-mooney | and given its opt in | |
| 16:55:30 | gibi | it is opt-in the default of the new config is to use my_ip as before | |
| 16:55:30 | sean-k-mooney | i think im fine with that as specless | |
| 16:55:35 | bauzas | yeah, so I'm favor of approving it | |
| 16:55:44 | bauzas | any concerns ? | |
| 16:56:07 | sean-k-mooney | the only thing we need to do is docuemnt that you shoudl not set the new config option until the cloud is fully upgraded | |
| 16:56:21 | sean-k-mooney | it will likely work with the hostname | |
| 16:56:41 | sean-k-mooney | and old nova | |
| 16:56:43 | gibi | I can add a reno | |
| 16:56:53 | sean-k-mooney | ack then all good form me | |
| 16:56:56 | gibi | and amend the config doc with a warning | |
| 16:56:59 | dansmith | I bet it works even with old ones | |
| 16:57:05 | gibi | it depends | |
| 16:57:09 | sean-k-mooney | provided its resolveable it likely will | |
| 16:57:13 | gibi | yeah | |
| 16:57:17 | sean-k-mooney | but it will depend on dns and /etc/hosts | |
| 16:57:35 | bauzas | I mean, that will depend on how the cloud is configured, but old computes can work | |
| 16:57:37 | bauzas | for sure | |
| 16:57:42 | sean-k-mooney | gibi: and just to clarify it can be an fqdn right (ip, hostname or fqdn) | |
| 16:57:52 | sean-k-mooney | it being the new config option | |
| 16:58:25 | gibi | it can be IP, it is defulted to my_ip, it can be a user defined FQDN or hostname, or it can be "%s" which will be replaced with the hostname of the node | |
| 16:58:34 | sean-k-mooney | +1 | |
| 16:58:37 | dansmith | yup | |
| 16:58:42 | bauzas | okay, if you don't mind, | |
| 16:58:51 | gibi | the last is the most useful for me in my deployment work | |
| 16:59:00 | bauzas | #agreed https://blueprints.launchpad.net/nova/+spec/libvirt-migrate-with-hostname-instead-of-ip is approved as a specless BP | |
| 16:59:07 | bauzas | we're on time | |
| 16:59:14 | bauzas | any last min question ? | |
| 16:59:28 | Uggla_ | yep | |
| 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 | bauzas | #endmeeting | |
| 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 | opendevmeet | Minutes: https://meetings.opendev.org/meetings/nova/2023/nova.2023-11-07-16.02.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 | Log: https://meetings.opendev.org/meetings/nova/2023/nova.2023-11-07-16.02.log.html | |
| 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 | bauzas | Uggla_: can you check ? | |
| 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: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? | |