Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2025-01-09
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
18:57:34 artom Are the required traits already stored in there?
18:57:36 dansmith I'm suggesting we *not* create another thing we have to track that might be out of sync or different and just use the same thing the user would have used, had it existed before this
18:57:48 dansmith so that if we snapshot it's automatic both here and in the future
18:57:48 sean-k-mooney dansmith: altought we woudl have to merge that with any traits request actully from the image
18:57:54 dansmith sean-k-mooney: yep
18:58:41 sean-k-mooney i think we are mixing two diffent uescases
18:59:05 sean-k-mooney that or artoms naming is confusing
18:59:14 sean-k-mooney im just rereading the spec by the way
18:59:46 dansmith yeah maybe read the spec and my comments before litigating what we're talking about :)
18:59:55 sean-k-mooney when we chatted the other day i was saying that we coudl have a flag in instnace_system_matadata ot report if the instance is live migratable
19:00:05 sean-k-mooney btu that has nothign to do with the triat
19:00:06 dansmith that's not what we're talking about
19:00:11 sean-k-mooney ok
19:00:35 sean-k-mooney so "instance.image_meta.properties[hw_can_live_migrate]" was just confusing me then
19:01:07 sean-k-mooney https://review.opendev.org/c/openstack/nova-specs/+/936775/11/specs/2025.1/approved/vtpm-live-migration.rst#168 this?
19:01:51 artom Yeah, I think dansmith is saying - don't actually persist the security policy anywhere except as the required trait in the instance image meta
19:02:01 artom (Which I don't actually know where those are)
19:02:02 sean-k-mooney ya we can encode the tpm seciryt policy in the traits request rather then a seperate key in the system_metadata
19:02:10 dansmith I'm saying don't persist it in two places
19:02:29 sean-k-mooney to me its less clean to do it in the image metadata
19:02:33 opendevreview Dmitriy Chubinidze proposed openstack/placement master: Modification of placement-api.conf https://review.opendev.org/c/openstack/placement/+/938664
19:02:35 dansmith it has to be persisted in the image meta cache, so no need to add a *second* place and always just do it in the one place it has to be
19:02:45 sean-k-mooney well as a fake request in the cached image data
19:02:56 sean-k-mooney dansmith: it does not need to be there at all
19:03:03 artom OK fine, so kill the system_metadata key
19:03:19 artom (Again, I'm assuming image required traits are already saved in there)
19:03:19 sean-k-mooney why do you say it has to be in the image meta cache?
19:03:37 sean-k-mooney artom: they are
19:03:49 dansmith that's my suggestion, because you'll have to look in both places if it's in two places
19:04:12 artom So then how do we indicate to owners - "the operator has chosen a policy for you, do something with your instance to confirm or do nothing/delete your instance to refuse" - IOW, L286
19:04:20 dansmith once for initial boot, then the other place for the other, and if they ever get out of sync, you'll be doing the wrong thing, a snapshot will have the wrong thing, a snapshot-boot will behave differently than you expect, etc
19:04:25 sean-k-mooney but peopel wont normlly set this on an image
19:04:43 sean-k-mooney they could it they want to express a policy i guess
19:04:58 dansmith can we gmeet? my keyboard is starting to feel my frustration :)
19:05:05 artom Sure
19:05:22 dansmith meet.google.com/vub-zvsa-khm
19:42:00 opendevreview Merged openstack/placement master: Add round-robin candidate generation strategy https://review.opendev.org/c/openstack/placement/+/936832
20:20:35 sean-k-mooney frickler: so based on https://review.opendev.org/c/openstack/requirements/+/933257 now that the oslo releas has been done it looks like we have a path forwoard on the eventlet bump
20:20:56 sean-k-mooney frickler: that does mean we need to get https://review.opendev.org/c/openstack/nova/+/933365 into a mergeable state however

Earlier   Later