| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-08-14 | |||
| 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 | |
| 15:12:41 | artom | Because IIUC your series touches on the same points as NUMA LM | |
| 15:12:59 | alex_xu | dansmith: when nova-compute startup, we populate all the assignment of vpmem and vgpu into memory, store those devices claim in the memory. key by (instance, flavor) | |
| 15:13:15 | alex_xu | artom: yea | |
| 15:13:38 | sean-k-mooney | alex_xu: well why dont we just store them with the instance as teh key | |
| 15:13:51 | alex_xu | sean-k-mooney: back to the same host resize problem :) | |
| 15:13:51 | dansmith | alex_xu: are the pmem devices actually named something specific in linux? or are they just /dev/pmem/2 and we maintain the mapping between them and the instance? | |
| 15:14:10 | artom | alex_xu, what's your series? I'm having trouble searching gerrit for patches you own | |
| 15:14:11 | mriedem | (instance, flavor) is redundant because we have instance.flavor | |
| 15:14:28 | alex_xu | dansmith: they are just /dev/pmem, but I don't get what relationship with the vpmem name at here | |
| 15:14:51 | sean-k-mooney | alex_xu: then use instace+flavor_name which is in the xml or add the uuid to the xml | |
| 15:14:52 | dansmith | alex_xu: okay so I don't understand why you have a problem accounting things with migration uuid vs. instance uuid at any given point | |
| 15:15:01 | mriedem | i think dan is saying, you claim the new_flavor devices on the dest host with the instance, and claim the old_flavor devices on the source host with the migration | |
| 15:15:26 | dansmith | sean-k-mooney: it's not a matter of storing that data, and further, flavor is an object that exists and is keyed in another database, so I think using it as a key here is a bad idea as well | |
| 15:15:33 | dansmith | mriedem: right | |
| 15:15:34 | mriedem | and by "claim the old_flavor devices on the source host with the migration" i mean, swap the mapping for the old_flavor device claim on the source host with the migration for the instance | |