| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-08-14 | |||
| 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 | |
| 14:59:31 | dansmith | just seems like a terribly deep assumption to make | |
| 14:59:43 | mriedem | idk, the xenapi driver doesn't support it either https://github.com/openstack/nova/blob/master/nova/virt/xenapi/driver.py#L67 | |
| 14:59:53 | mriedem | only the vmware driver does | |
| 15:00:23 | mriedem | i also don't understand how init_host is connected to a move claim | |
| 15:00:33 | dansmith | alex_xu: explain again why you need to tie flavors to the pmem at all for accounting? | |
| 15:00:51 | dansmith | mriedem: this is for host restart, rebuilding state for what has been given to what | |