| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2025-01-08 | |||
| 14:41:29 | opendevreview | Dmitriy Chubinidze proposed openstack/placement master: Modification of placement-api.conf https://review.opendev.org/c/openstack/placement/+/938664 | |
| 14:44:16 | sean-k-mooney | dansmith: i think thats patch 5 in my queue for today but ill see if i can get to it today thanks for the reminder | |
| 14:44:36 | dansmith | sean-k-mooney: ack, just wanted to make sure it was in the queue somewhere :D | |
| 14:44:39 | sean-k-mooney | i have one watcher review then 3 placment reviews and then that | |
| 15:09:50 | opendevreview | Dmitriy Chubinidze proposed openstack/placement master: Modification of placement-api.conf https://review.opendev.org/c/openstack/placement/+/938664 | |
| 15:29:01 | opendevreview | ribaudr proposed openstack/nova-specs master: Enable VFIO devices with kernel variant drivers https://review.opendev.org/c/openstack/nova-specs/+/936407 | |
| 15:45:03 | opendevreview | Merged openstack/os-vif master: Integrate pre-commit https://review.opendev.org/c/openstack/os-vif/+/934240 | |
| 16:50:01 | opendevreview | Ivan Anfimov proposed openstack/nova master: doc: nova service_user wrong auth_url https://review.opendev.org/c/openstack/nova/+/938680 | |
| 17:00:06 | opendevreview | Ivan Anfimov proposed openstack/nova master: doc: nova service_user wrong auth_url https://review.opendev.org/c/openstack/nova/+/938680 | |
| 17:04:59 | opendevreview | ribaudr proposed openstack/nova-specs master: Migrate VFIO devices using kernel variant drivers https://review.opendev.org/c/openstack/nova-specs/+/937615 | |
| 17:09:10 | opendevreview | Ivan Anfimov proposed openstack/nova master: doc: nova service_user wrong auth_url https://review.opendev.org/c/openstack/nova/+/938680 | |
| 17:15:46 | opendevreview | Ivan Anfimov proposed openstack/nova master: doc: nova service_user wrong auth_url https://review.opendev.org/c/openstack/nova/+/938680 | |
| 17:39:16 | opendevreview | Douglas Viroel proposed openstack/nova master: WIP - Add support for showing scheduler_hints in server details https://review.opendev.org/c/openstack/nova/+/938604 | |
| 19:39:37 | opendevreview | Douglas Viroel proposed openstack/nova master: WIP - Add support for showing scheduler_hints in server details https://review.opendev.org/c/openstack/nova/+/938604 | |
| 19:41:53 | opendevreview | Alan Bishop proposed openstack/nova-specs master: Show swap_progress in attachment details https://review.opendev.org/c/openstack/nova-specs/+/937485 | |
| 21:21:18 | opendevreview | Merged openstack/os-vif master: Do not add taps in trunk bridges to the dead vlan https://review.opendev.org/c/openstack/os-vif/+/923036 | |
| 21:43:26 | opendevreview | Merged openstack/placement master: Add a global limit on the number of allocation candidates https://review.opendev.org/c/openstack/placement/+/936658 | |
| 21:44:29 | opendevreview | Merged openstack/placement master: Factor out allocation candidate generation strategy https://review.opendev.org/c/openstack/placement/+/937273 | |
| 22:59:47 | opendevreview | Dmitriy Chubinidze proposed openstack/nova master: Adding link for RabbitMQ installation during nova deployment on controller node. https://review.opendev.org/c/openstack/nova/+/938702 | |
| #openstack-nova - 2025-01-09 | |||
| 02:54:16 | opendevreview | Ghanshyam proposed openstack/nova-specs master: Propose API policy service and manager role spec https://review.opendev.org/c/openstack/nova-specs/+/937650 | |
| 08:29:52 | opendevreview | Balazs Gibizer proposed openstack/placement master: Add round-robin candidate generation strategy https://review.opendev.org/c/openstack/placement/+/936832 | |
| 08:29:53 | opendevreview | Balazs Gibizer proposed openstack/placement master: DNM: test with breadth-first in tempest https://review.opendev.org/c/openstack/placement/+/937274 | |
| 11:39:42 | opendevreview | Dmitriy Chubinidze proposed openstack/placement master: Modification of placement-api.conf https://review.opendev.org/c/openstack/placement/+/938664 | |
| 14:14:38 | s3rj1k | hi team, to iterate quickly on https://review.opendev.org/c/openstack/nova-specs/+/937185 maybe we should go with some very generic proposal for solving this issue? at least start drafting something up | |
| 15:09:50 | opendevreview | Merged openstack/nova-specs master: Enable VFIO devices with kernel variant drivers https://review.opendev.org/c/openstack/nova-specs/+/936407 | |
| 16:11:06 | opendevreview | Masahito Muroi proposed openstack/nova-specs master: Add spec for the network id query in server list and server details https://review.opendev.org/c/openstack/nova-specs/+/938823 | |
| 16:22:05 | masahito | Hi folks, if you have time please take a look https://review.opendev.org/c/openstack/nova-specs/+/938823. I know the deadline is today so my first proposal is late and the spec may require some iteration, though. | |
| 16:32:22 | opendevreview | Masahito Muroi proposed openstack/nova-specs master: Add spec for the network id query in server list and server details https://review.opendev.org/c/openstack/nova-specs/+/938823 | |
| 16:56:37 | gibi | melwitt: I've pushed a new revision for https://review.opendev.org/c/openstack/placement/+/936832 to fix sean-k-mooney's comments. So when you have time please re-review | |
| 16:58:49 | opendevreview | ribaudr proposed openstack/nova-specs master: Migrate VFIO devices using kernel variant drivers https://review.opendev.org/c/openstack/nova-specs/+/937615 | |
| 17:03:19 | sean-k-mooney | masahito: why not do a port list for the given network and just get the device-id form the port | |
| 17:04:15 | sean-k-mooney | oh becase you want more then just the uuids | |
| 17:04:24 | sean-k-mooney | you also want the other server details. | |
| 17:21:47 | melwitt | gibi: sure will do | |
| 17:22:00 | opendevreview | ribaudr proposed openstack/nova-specs master: Migrate VFIO devices using kernel variant drivers https://review.opendev.org/c/openstack/nova-specs/+/937615 | |
| 17:25:17 | masahito | sean-k-mooney: yes. we want to fetch more server info not only the uuids. The device-id is just a list of ids. | |
| 17:27:19 | sean-k-mooney | masahito: im not -2 on this but im kind of -1.5 | |
| 17:27:58 | sean-k-mooney | i think we woudl want the neutron team to weigh in on it too but there are a lot of other critira you could filter nova isntnace on even if we just consider neutorn | |
| 17:28:52 | sean-k-mooney | and im not sure it a good idea ot extend the nova api to support all or really any of them | |
| 17:30:43 | opendevreview | Artom Lifshitz proposed openstack/nova-specs master: vTPM live migration https://review.opendev.org/c/openstack/nova-specs/+/936775 | |
| 17:31:13 | sean-k-mooney | masahito: at present we do not supprot filterign server by the external identify or any resouce form any other service with the sole expction beign the keystone project and glance image uuid which are directly assocated with the instnace object | |
| 17:31:28 | artom | dansmith, melwitt, gibi, sean-k-mooney ^^ took longer than I wanted (had to manage car troubles), and there's still a couple of todo open questions, but I think it's close enough to push up | |
| 17:31:56 | sean-k-mooney | can you revert the tox.ini change | |
| 17:32:03 | artom | Doh, yeah. | |
| 17:32:12 | artom | It doesn't run locally with it, and I keep forgetting to clean it up. | |
| 17:32:24 | opendevreview | Artom Lifshitz proposed openstack/nova-specs master: vTPM live migration https://review.opendev.org/c/openstack/nova-specs/+/936775 | |
| 17:32:49 | sean-k-mooney | what you can do instead for future reference is you can create a py3.10 virtual env | |
| 17:32:55 | sean-k-mooney | activate that and then run tox form there | |
| 17:33:12 | sean-k-mooney | then it will use that version of python instaead fo your default system python | |
| 17:36:50 | masahito | Thank for the quick review. I see your point. The netowrk_id is not an server's attributes. I had same concern so that I needs Nova team's idea. | |
| 17:38:28 | sean-k-mooney | ya im not sure. im inclidne to say we shoudl not adress this pain point unless we see many opertoar bring it up | |
| 17:38:29 | masahito | One quick question, is there reason the list server API doesn't have id query param? like id=id1,id2,id3. If it's okay, the query can solve the current problem as I mentioned in the alternative. | |
| 17:39:06 | sean-k-mooney | hum ok that could work in some cases | |
| 17:39:18 | sean-k-mooney | so i belive the max url lenght is 256 | |
| 17:39:31 | sean-k-mooney | and each uuid is ~20-32 charters i dont recall | |
| 17:39:48 | sean-k-mooney | so that could allow you to have batches or 10 or so at a time | |
| 17:40:37 | sean-k-mooney | masahito: i suspec the max url lenght is the main reason list and show do not supprot multiple uuids | |
| 17:41:23 | masahito | haha, I got it. | |
| 17:41:30 | sean-k-mooney | masahito: out of interest what is the main usecase that motivates this | |
| 17:41:35 | melwitt | artom: IIRC yall discussed some stuff on a call yesterday or the day before, if there were any takeaways did anyone add comments on the review about them? | |
| 17:41:38 | sean-k-mooney | i.e. why woudl a user or admin want to do this | |
| 17:43:02 | masahito | Looks like apache allows almost 4,000 chars for the query param. It's not a big number as you mentiond. | |
| 17:44:17 | sean-k-mooney | it depend on the server and client | |
| 17:44:41 | sean-k-mooney | technially there is not max limit per RFC | |
| 17:44:57 | sean-k-mooney | but its typically less the 8k often 2k or 4k | |
| 17:45:21 | sean-k-mooney | but i have seen recommentions to never exceed 1024 | |
| 17:46:18 | sean-k-mooney | there are secirty implciations to allowign it to be arbairy large so often there is a soft or hard limit in diffent part of the tech stack | |
| 17:46:58 | masahito | It's not a big reason we want to have the network id filter. When the number of available ip become less, we want to list VM name which uses the network and ask VM user to delete VM if possible. | |
| 17:47:35 | sean-k-mooney | ah ok | |
| 17:48:04 | masahito | In order to contact the VM user, VM info, display_name, user, project and some info are needed. | |
| 17:48:18 | sean-k-mooney | i think we woudl be more ok with allwoing you to pass a list of uuid to server detail list if im being honest then network_id | |
| 17:48:52 | sean-k-mooney | well the user and project id you can get form the neutron port no? | |
| 17:50:35 | sean-k-mooney | the neurotn prot has both a tenant_id and project_id field wich both hold the keyston project id | |
| 17:51:09 | masahito | Yes. project info is available. But server name is not available. | |
| 17:51:32 | sean-k-mooney | is that needed cant you provide the the server uuid form the device_id filed instead | |
| 17:53:28 | sean-k-mooney | i guess you want to also know which suer created the vm/port rather then just which project it belongs too | |
| 17:54:19 | masahito | This is a problem the spec mentioned as a problem. We could give the uuid list to user, but user needs to convert uuid to hostname or display_name by themselves because uuid is not human readable. | |
| 17:54:31 | sean-k-mooney | servers are offilaly owned by the keyston porject not a user but we do recored the user id of the user that creted it | |
| 17:54:45 | sean-k-mooney | but that is not aviabel vaid neutorn only nova | |
| 17:55:02 | masahito | Yes, which user and which server is more important. | |
| 17:55:16 | opendevreview | ribaudr proposed openstack/nova-specs master: Migrate VFIO devices using kernel variant drivers https://review.opendev.org/c/openstack/nova-specs/+/937615 | |
| 17:56:03 | sean-k-mooney | masahito: ya so the least invaive change woudl be to allow server list to take a list of uuids | |
| 17:56:13 | sean-k-mooney | but im not sure if that somehtign others would supprot | |
| 17:57:50 | artom | melwitt, yeah, I guess the call was too early for you. The spec changed pretty drastically. It might actually be good that you read it with no further introduction by me, to see if I'm making sense to someone without the full context. | |
| 17:58:45 | masahito | Got it. Thank you for taking your time :) Let me update the spec tomorrow if there is no other comment following this talk. | |
| 18:00:38 | melwitt | artom: ah, gotcha. thanks, I'll read through | |
| 18:53:16 | sean-k-mooney | gibi: bauzas: Uggla i have +2'd https://review.opendev.org/c/openstack/nova-specs/+/937615 | |
| 18:54:00 | sean-k-mooney | i have one comment inlien regardign the trait and how we report it but im ok to resolve that in a follow up when we update the spec for the object field defineiton | |
| 18:55:01 | artom | dansmith, so just to be clear, you're saying add a new property into ImageMetaProps, call it something like hw_can_live_migrate, so that we can then check instance.image_meta.properties[hw_can_live_migrate]? | |
| 18:55:32 | dansmith | no | |
| 18:55:40 | artom | Yeah I'm confused then. | |
| 18:55:43 | dansmith | we cache the user's image metadata on the instance yeah? | |
| 18:55:58 | sean-k-mooney | in instnace_system_metadata | |
| 18:56:03 | sean-k-mooney | with a img_ prefix | |
| 18:56:16 | artom | OK... | |
| 18:56:32 | sean-k-mooney | artom: but to your questiong | |
| 18:56:52 | sean-k-mooney | we shoudl be addeing a flavg to the instnace.system_metadata | |
| 18:56:53 | dansmith | right, so I'm proposing we update the cached image meta with a new "traits required" as if they had set it on their image in the past already | |
| 18:57:07 | dansmith | sean-k-mooney: he's asking about my challenge to that | |
| 18:57:08 | sean-k-mooney | we coudl do that too yes | |