| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2023-11-07 | |||
| 16:43:43 | sean-k-mooney | bauzas: i really dislike that direction as i feel our schduler shoudl ensure you land on a host that can supprot the request feature without additonal admin intervention | |
| 16:44:25 | sean-k-mooney | dansmith: in this partical case if we dont have the trait it will be non critical only in that on older host it willl be ignored | |
| 16:44:26 | bauzas | only if you have mixed hypervisors, right? | |
| 16:44:41 | sean-k-mooney | bauzas: no even with a singel hypervior | |
| 16:44:45 | bauzas | and in that case, you probably already did the setup in order to shard your cloiud | |
| 16:44:51 | dansmith | sean-k-mooney: right, it just seems like a best-effort sort of thing compared to some others | |
| 16:45:06 | bauzas | sean-k-mooney: still talking of the 'I want a compute with libvirt recent enough' then ? | |
| 16:45:15 | bauzas | again, doesn't sound to me worth adding a trait for this | |
| 16:45:19 | sean-k-mooney | dansmith: if its a flavor extra spec we shoudl always guarentee it abel to work on the slected host | |
| 16:45:43 | sean-k-mooney | so if we are fine with rejecting it on the compute node sure | |
| 16:45:47 | bauzas | anyway, I feel we're arguing right, but the time flies and we're on a meeting | |
| 16:45:49 | sean-k-mooney | im not ok with allowing the vm to boot | |
| 16:46:04 | bauzas | can we drop this until the end of this meeting | |
| 16:46:06 | bauzas | ? | |
| 16:46:10 | dansmith | yep | |
| 16:46:14 | sean-k-mooney | sure or to thet spec review | |
| 16:46:18 | bauzas | and we could try to find a way forward just after | |
| 16:46:29 | bauzas | cool, moving on then | |
| 16:47:13 | bauzas | #topic Review Priorities | |
| 16:47:18 | bauzas | still an action item on me | |
| 16:47:33 | bauzas | I have to create an etherpad as we agreed at PTG | |
| 16:47:46 | dvo-plv | I have some issue with electricity, battery dead, so ping me and i will answer later when I will be back online | |
| 16:47:46 | bauzas | so I'll keep this bullet until I'm set | |
| 16:48:11 | bauzas | #action bauzas to create a tracking etherpad for this cycle | |
| 16:48:38 | bauzas | dvo-plv: np, we also captured this conversation in the meeting logs that'll show up once we end the meeting | |
| 16:48:57 | bauzas | #topic Stable Branches | |
| 16:49:03 | bauzas | elodilles: your time | |
| 16:49:12 | elodilles | #info stable gates don't seem blocked | |
| 16:49:20 | elodilles | (stable/victoria's nova-ceph-multistore looked suspicious as it failed with POST_FAILURE a couple of times, but it has passed now) | |
| 16:49:35 | elodilles | #info stable release patches proposed: https://review.opendev.org/q/project:openstack/releases+is:open+intopic:nova | |
| 16:50:03 | elodilles | last time we agreed to wait for some patches to merge ^^^ | |
| 16:50:24 | elodilles | feel free to update the patch when they are merged | |
| 16:50:27 | bauzas | yeah and noonedeadpunk proposed backports | |
| 16:50:35 | elodilles | ++ | |
| 16:50:38 | bauzas | related to the RPC fixes we wanted to land | |
| 16:50:42 | bauzas | so, we need reviews | |
| 16:50:54 | bauzas | I surely can review things I wrote | |
| 16:51:03 | elodilles | ACK, will review them then :) | |
| 16:51:18 | elodilles | #info stable branch status / gate failures tracking etherpad: https://etherpad.opendev.org/p/nova-stable-branch-ci | |
| 16:51:30 | elodilles | and that's all from my side | |
| 16:51:35 | bauzas | elodilles: ping me if you need the change numbers | |
| 16:51:41 | bauzas | cool, thanks | |
| 16:51:53 | bauzas | rushing, we have a few time left | |
| 16:51:57 | bauzas | #topic Open discussion | |
| 16:52:07 | bauzas | (gibi): Seeking for specless approval https://blueprints.launchpad.net/nova/+spec/libvirt-migrate-with-hostname-instead-of-ip based on the PTG discussion https://etherpad.opendev.org/p/nova-caracal-ptg#L815. I have a proposed impl https://review.opendev.org/c/openstack/nova/+/900203 | |
| 16:52:17 | gibi | so | |
| 16:52:44 | gibi | as we discussed on the PTG I would like to make it possible for the libvirt driver to use hostnames during cold migration instead of IP addresses | |
| 16:52:45 | noonedeadpunk | bauzas: fwiw, backport to Zed is failing unit tests | |
| 16:52:53 | noonedeadpunk | so some look there is appreciated | |
| 16:53:09 | gibi | the live migration already uses hostnames by default | |
| 16:53:15 | dansmith | gibi: ++ | |
| 16:53:30 | gibi | this specless bp propose a new config option to make the new behavior opt in | |
| 16:53:31 | dansmith | gibi: no new RPC or object stuff needed, just a change on which thing we advertise to the remote side right? | |
| 16:53:31 | bauzas | noonedeadpunk: I have a clue, but let's not discuss this now (I guess this is the rpc version check unittest that fails) | |
| 16:53:46 | sean-k-mooney | dansmith: we might need a db change | |
| 16:53:47 | gibi | no rpc, no object, just a config option for the libvirt driver | |
| 16:53:56 | dansmith | sean-k-mooney: why/ | |
| 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 | sean-k-mooney | i think im fine with that as specless | |
| 16:55:30 | gibi | it is opt-in the default of the new config is to use my_ip as before | |
| 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 | |