| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-08-14 | |||
| 14:38:03 | dansmith | alex_xu: if you pass the list of instances on this host to init_host(), then you can get any instances that have xml but are not in that list, and do an independent query for those, which will be much smaller | |
| 14:38:40 | mriedem | sean-k-mooney: i agree it's some kind of misconfig and related to needing to tell the image to use systemd now | |
| 14:38:45 | dansmith | alex_xu: however, I would think that if you're just trying to figure out which namespaces are assigned, the xml should be enough, so I'm not sure why you need the instance from the db (but I haven't looked closely) | |
| 14:40:04 | alex_xu | dansmith: we need the flavor id. since we use (instance_uuid, flavor_id) to identify a claim. This is due to the same host resize. Both src and dest claim on the same host, we need a way to distinguish the claim | |
| 14:40:46 | alex_xu | the instance uuid I can get from the domain xml. the only trouble is the flavor id | |
| 14:41:39 | sean-k-mooney | mriedem: looking at the lxc buster(debian 10) images the symlink appear to be there. /sbin/init -> /lib/systemd/systemd | |
| 14:41:55 | sean-k-mooney | mriedem: so i think if we just use the right image it should just work | |
| 14:42:26 | mriedem | alex_xu: the flavor name is in the domain xml metadata | |
| 14:42:31 | mriedem | see https://logs.opendev.org/24/676024/5/experimental/nova-lxc/9c06394/controller/logs/screen-n-cpu.txt.gz#_Aug_13_23_16_20_055037 | |
| 14:42:39 | mriedem | <nova:flavor name="m1.nano"> | |
| 14:42:43 | dansmith | alex_xu: okay makes sense | |
| 14:42:56 | alex_xu | mriedem: can we ensure all the virt driver persistent the flavor name? or it is libvirt specific. | |
| 14:43:09 | mriedem | idk about the other drivers | |
| 14:43:13 | mriedem | but they aren't doing pmems either | |
| 14:43:16 | dansmith | alex_xu: mriedem you need more than that, you need the *actual* details of the flavor right? | |
| 14:43:18 | sean-k-mooney | alex_xu: i think the metadata is driver specific | |
| 14:43:30 | sean-k-mooney | alex_xu: it normally has the flavor uuid too | |
| 14:43:32 | dansmith | alex_xu: looking up the flavor by name after the instance is spawned won't work because it may have changed, you need instance.flavor I think | |
| 14:43:38 | mriedem | i'm wading into a conversation for which i don't have context of the problem, i'm just saying, the domain xml has flavor info | |
| 14:43:40 | alex_xu | dansmith: only need the id | |
| 14:44:01 | dansmith | alex_xu: what does that tell you? | |
| 14:44:35 | alex_xu | dansmith: I just want to distinguish the src claim and dest claim on the same host. so instance_uuid and flavor_id is enough | |
| 14:44:38 | mriedem | the domain xml metadata doesn't store the flavor id so i guess that won't help you | |
| 14:44:46 | sean-k-mooney | alex_xu: we generate teh metadtat here https://github.com/openstack/nova/blob/master/nova/virt/libvirt/config.py#L2860 | |
| 14:45:05 | alex_xu | sean-k-mooney: I'm thinking we have uuid for flavor...? | |
| 14:45:16 | mriedem | alex_xu: and this is because the move claim for pmems is moving to the driver, right? | |
| 14:45:19 | dansmith | alex_xu: okay I don't understand, since the flavor id won't tell you size or type or anything, but I guess I'll understand when I read | |
| 14:45:39 | sean-k-mooney | alex_xu: yes we do but we also have other info | |
| 14:45:41 | Tianhao_Hu | mriedem: Thank you for your advice and I will get someone to work with me trying to find out why the directory is left. | |
| 14:45:43 | mriedem | alex_xu: flavor.flavorid is the user-facing thing | |
| 14:46:03 | mriedem | flavorid is not necessarily a uuid, | |
| 14:46:12 | mriedem | but it must be unique | |
| 14:46:16 | sean-k-mooney | actully we might not have the uuid unesll we put it in the namve field | |
| 14:46:20 | alex_xu | dansmith: flavor id will tell you it is src or dest. the dest is new flavor, the src is old flavor | |
| 14:46:23 | luyao | dansmith: flavor id is used to mark a namespace is assigned to which instance with which flavor | |
| 14:46:34 | dansmith | luyao: I think that's a bad plan | |
| 14:46:39 | sean-k-mooney | alex_xu: you cal always add whatever you need to https://github.com/openstack/nova/blob/master/nova/virt/libvirt/config.py#L2902-L2930 | |
| 14:46:54 | dansmith | mriedem: IIRC, flavorid is unique, but only amongst non-deleted flavors, so if you delete and recreate a flavor it may be different right? | |
| 14:47:03 | alex_xu | mriedem: for same host resize, also note it is useful for vgpu | |
| 14:47:14 | mriedem | dansmith: flavors are no longer soft-deletable | |
| 14:47:16 | mriedem | since they moved to the api db | |
| 14:47:17 | mriedem | schema.UniqueConstraint("flavorid", name="uniq_flavors0flavorid"), | |
| 14:47:44 | sean-k-mooney | alex_xu: we are usign a custom xml namespace with a schema filt tha tis not avaliable anymore so you can extend it and ti wont be any more broken then it already is | |
| 14:47:45 | dansmith | mriedem: okay, right, but same point.. I can delete a flavor and recreate it and the flavors will be totally different | |
| 14:47:51 | alex_xu | dansmith: at least we not allow resize to same flavor(check by flavor id i think) | |
| 14:48:57 | mriedem | i don't know enough about the code or the problem here, | |
| 14:49:06 | mriedem | note there is also instance.instance_type_id which is the instance.flavor.id, | |
| 14:49:11 | mriedem | but not in the domain xml so likel ydoesn't help | |
| 14:49:16 | dansmith | but still, | |
| 14:49:17 | alex_xu | sean-k-mooney: it is late to add new info to the xml. the existed instance won't have that until a restart | |
| 14:49:33 | sean-k-mooney | alex_xu: what info do you need | |
| 14:49:48 | dansmith | I think they're making some assumptions that flavorid is permanent and never changes, such that considering two instances with the same pmem flavorid must be the same | |
| 14:49:48 | mriedem | alex_xu: existing instances won't have vpmems either | |
| 14:49:49 | alex_xu | mriedem: dansmith oops, sorry, I use the flavor.id, not the flavorid | |
| 14:50:05 | dansmith | alex_xu: so the integer id? | |
| 14:50:09 | alex_xu | dansmith: yes | |
| 14:50:24 | dansmith | alex_xu: okay, well, that's still not a good idea, but less problematic | |
| 14:50:24 | alex_xu | mriedem: nice point | |
| 14:52:08 | aspiers | Does anyone know why _get_guest_xml() has both instance and image_meta as params, rather than getting image_meta via instance.image_meta? I traced it back and found that prep_resize is called with image_meta from the request_spec, but I'm not sure why a request_spec would have different image_meta to the existing instance | |
| 14:52:14 | alex_xu | mriedem: but it should be a problem for vgpu | |
| 14:52:19 | alex_xu | mriedem: we already have vgpu instance | |
| 14:52:46 | alex_xu | dansmith: one more fun is we support same flavor same host cold migration :) | |
| 14:53:17 | alex_xu | dansmith: vmware virt driver is the only driver support that. the same host same flavor cold migration should make no sense for other virt driver | |
| 14:53:33 | mriedem | alex_xu: the vmware driver isn't supporting pmems | |
| 14:53:34 | dansmith | alex_xu: okay I'm really not sure why these are problematic cases | |
| 14:54:26 | luyao | dansmith: beacause when resize to same host ,we can't distinguish the two groups of assignment | |
| 14:54:48 | alex_xu | yea, same flavor.id | |
| 14:55:08 | mriedem | if you're doing a resize, the flavors have to be different, | |
| 14:55:14 | mriedem | if you're doing a cold migration, the flavors must be the same, | |
| 14:55:14 | dansmith | luyao: yeah I'm not sure why that's necessary, but it's also a good reason _not_ to use flavor, because it will depend on whether or not the flavor is changing, | |
| 14:55:16 | sean-k-mooney | alex_xu: but why do you need to get flaovr info form the xml. for resize we have teh flavor objects and we shoudl have them for cold migrate and live migratie | |
| 14:55:26 | mriedem | if you're doing a resize, you can do it on the same host with libvirt, | |
| 14:55:30 | dansmith | and building an assumption into this that same-host same-flavor migrations can't happen is a bad idea, IMHO | |
| 14:55:32 | mriedem | if you're doing a cold migration, you cannot do it on the same host with libvirt | |
| 14:55:42 | mriedem | and it seems folly to think any other driver is going to implement vpmem support | |
| 14:55:52 | dansmith | sean-k-mooney: they're talking about during host init, with instances in the middle of a migration | |
| 14:55:56 | mriedem | given how complicated this sounds even for libvirt | |
| 14:56:08 | sean-k-mooney | dansmith: ah thanks for the context | |
| 14:56:18 | dansmith | mriedem: we do same-host same-flavor migration on libvirt in the gate with a single worker yeah? | |
| 14:56:33 | mriedem | no | |
| 14:56:33 | sean-k-mooney | dansmith: i dont think so | |
| 14:56:36 | mriedem | resize yes | |
| 14:56:37 | mriedem | not cold migration | |
| 14:56:40 | mriedem | you literally can't | |
| 14:56:45 | dansmith | why not? | |
| 14:56:53 | aspiers | Hrm, sounds like my question might coincidentally be somewhat related to the ongoing conversation, except for image_meta instead of flavors | |
| 14:57:04 | sean-k-mooney | dansmith: the livrt driver does not report supprot for it | |
| 14:57:08 | alex_xu | sean-k-mooney: avoid db query in libvirt init | |
| 14:57:10 | mriedem | https://github.com/openstack/nova/blob/master/nova/virt/libvirt/driver.py#L314 | |
| 14:57:13 | mriedem | because ^ | |
| 14:57:28 | mriedem | remember the other day when we were talking about a workaround option to disallow cold migrating to the same source host as a scheduler option? | |
| 14:57:31 | mriedem | this is why | |
| 14:57:35 | alex_xu | same flavor same host cold migration means....you stop and start the instance again :) | |
| 14:57:36 | sean-k-mooney | alex_xu: why we will be hamming it anyway when the resouce tracker starts up | |
| 14:57:44 | dansmith | mriedem: either way, don't you think that making that assumption in the accounting for these is a bad plan, if that gets enabled in the future for whatever reason? | |
| 14:57:56 | dansmith | alex_xu: no it doesn't | |
| 14:58:14 | dansmith | mriedem: okay that's just because libvirt won't handle the disk copying properly because the names are all the same righht? | |
| 14:58:46 | mriedem | idk what cold migrating on the same host with libvirt would mean | |
| 14:58:58 | alex_xu | yea, same question | |
| 14:59:03 | dansmith | ages ago we had *some* CI system (not vmware) that could do same-host cold migration because it would find bugs in that, but maybe it was xen or smokestack or something | |