| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-08-14 | |||
| 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 | mriedem | alex_xu: existing instances won't have vpmems either | |
| 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: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 | alex_xu | mriedem: nice point | |
| 14:50:24 | dansmith | alex_xu: okay, well, that's still not a good idea, but less problematic | |
| 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 | 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:14 | mriedem | if you're doing a cold migration, the flavors must be the same, | |
| 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 | sean-k-mooney | dansmith: i dont think so | |
| 14:56:33 | mriedem | no | |
| 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 | |
| 15:01:09 | dansmith | mriedem: but I don't understand why we need to correlate that with anything other than instance uuid, which is done in the xml, AFAIK | |
| 15:01:30 | mriedem | yeah....i thought the pmem "allocation" type data was stored in instance_extra or something | |
| 15:01:33 | mriedem | keyed by instance uuid | |
| 15:01:42 | alex_xu | for same host resize, we records the claim in memory. but when we confirm and revert the resize, we need unclaim for dst claim or src claim. to distinguish that, only the instance_uuid isn't enough. I use instance_uuid + flavor.id. | |
| 15:01:57 | alex_xu | dansmith: mriedem sean-k-mooney ^ | |
| 15:02:25 | dansmith | alex_xu: isn't the whole point of this pmem stuff that the contents get moved with the instance if it crosses to another host? | |
| 15:02:42 | dansmith | (tbh I don't know what the point of this is, but...) | |
| 15:02:48 | mriedem | if you're adding a new move claim interface to the virt driver, why wouldn't you just pass the information down to the driver that the RT already knows - i.e. the old and new flavor and if it's a same-host resize? | |
| 15:03:40 | mriedem | if we have to piece information together from what the hypervisor says in the domain xml, we screwed up somewhere in the design :) | |
| 15:03:42 | alex_xu | when you confirm resize, you neeed unclaim the assigment for the source host. But for the same host, if only use instance_uuid, when you unclaim by instance_uuid, both the source and dest claim will be unclaim | |
| 15:03:58 | alex_xu | same problem for revert resize | |
| 15:05:01 | dansmith | alex_xu: so change the source allocation to be by migration uuid like we do for allocations? | |
| 15:05:59 | alex_xu | dansmith: the problem is when we revert the migration uuid back to instance uuid. for the resize to different host, those claim on two host's memory, we can't change the migration uuid back to instance uuid when the resize finish | |
| 15:06:20 | dansmith | alex_xu: why not? | |
| 15:06:32 | dansmith | if you can change it from instance to migration, why can't you change it back? | |
| 15:08:10 | alex_xu | dansmith: we claim the vpmem on the dest host(prep_resize), at that point, we need to change the source host claim's instance_uuid to migration_uuid. | |
| 15:08:27 | dansmith | ...right | |
| 15:09:31 | alex_xu | yea...there is no way to change source host claim | |
| 15:11:26 | dansmith | are you saying there's no way to rename a pmem device or whatever you're naming (instance, flavor) ? | |
| 15:12:13 | artom | alex_xu, I feel like we should coordinate on the claim thing | |