| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-10-09 | |||
| 19:00:45 | dansmith | so, not a real helpful opinion, but....there it is | |
| 19:01:17 | mriedem | i can do it either way, it's mostly just a question of how gorby we want the RT resize_claim flow to become when we're unshelving during a cross-cell resize....since as noted we have to do some things manually if we're not doing an instance_claim | |
| 19:01:23 | mriedem | *gorpy | |
| 19:01:34 | dansmith | do we not have any places where we might need to look at a late-stage migration and know if it was cross-cell before we allow or disallow something? | |
| 19:02:18 | dansmith | well, fwiw, the migration context setting via instance_claim never made sense to me, and continues to confuse me and others when we try to remember where it gets set (and why not for things like live migration) | |
| 19:02:34 | mriedem | it's not set in instance_claim, it's in resize_claim | |
| 19:02:43 | dansmith | you know what I mean gdi :) | |
| 19:02:46 | dansmith | in the claim process | |
| 19:03:27 | mriedem | i'm not aware of late stage thingies that rely on the migration_context, maybe there are in the actual finish_resize/finish_revert_resize/confirm_resize flows...which i'm not using | |
| 19:03:49 | dansmith | I'm saying things we'd need to handle in this process, not existing ones | |
| 19:03:54 | mriedem | when we revert/confirm the API looks up the migration directly, not via the migration_context: https://review.openstack.org/#/c/603930/9/nova/compute/api.py@3244 | |
| 19:04:17 | dansmith | yeah, which is kinda silly | |
| 19:04:31 | mriedem | which, i guess ^ works because we have the finished status and then it goes to 'completed' or something in the compute | |
| 19:04:33 | dansmith | that would be much nicer as "get the instance and get the current migration" instead of "sort and assume the last one is legit" | |
| 19:04:35 | mriedem | which sound the same to me | |
| 19:05:09 | dansmith | I should just stop talking. No, I don't have any good reasons. | |
| 19:05:15 | mriedem | oh i guess on revert the migration status goes to 'reverted' | |
| 19:05:33 | mriedem | and 'confirmed' on confirm | |
| 19:05:51 | mriedem | alright, well, it's just a drop in the bucket of questions in here | |
| 19:06:00 | mriedem | i just wanted to plant the seed of doubt in someone else's mind about this | |
| 19:06:05 | mriedem | you're welcome | |
| 19:18:53 | sean-k-mooney | so can i ask a dumb question related to that converstation. | |
| 19:19:24 | sean-k-mooney | what is the difference logically between a migration context, a migtion object and migration_data | |
| 19:19:50 | sean-k-mooney | i know all three exists but not sure why there is not jsut one datastructure | |
| 19:20:14 | sean-k-mooney | mriedem: dansmith is the answer to ^ documented anywhere | |
| 19:20:52 | dansmith | migration context is attached to an instance and contains a link to the migration record (i.e. the current one) and some other current details | |
| 19:21:04 | dansmith | migration objects are the in-progress and archival history of an instance's movements | |
| 19:21:33 | dansmith | migrate data is transient virt-specific detailage about the low-level bits that is ferried back and forth but never persisted | |
| 19:22:25 | sean-k-mooney | oh ok that actully kind of makes sence. the nameing is unfortuate but the reason for having 3 distinct entities makes sense | |
| 19:23:15 | mriedem | migrate_data is also only for live migration | |
| 19:23:38 | mriedem | hence the name, LiveMigrateData | |
| 19:24:02 | dansmith | yeah, left that detail out | |
| 19:24:24 | sean-k-mooney | mriedem: yes but for cold migrtion we kindo of abuse the migration_context for associting claim with the active migration too right | |
| 19:25:59 | sean-k-mooney | so we dont actully stuff the resocetrack claims into the migration_context as far as i know but i think we must the uuid of the migration_context when claiming the resouce or somthing like that. | |
| 19:27:28 | mriedem | based on my questions above, i'm clearly not the person to ask about the intracacies of how the migration_context is used during resize | |
| 19:27:39 | mriedem | *intricacies even | |
| 19:27:48 | dansmith | sean-k-mooney: migration context has no uuid, it's attached to the instance | |
| 19:28:17 | mriedem | MigrationContext.migration_id could be used to find the migration object if needed | |
| 19:28:22 | mriedem | within the same cell | |
| 19:28:24 | sean-k-mooney | sorry the migrtion record/object reffrence by the migration_context has a uuid which we use | |
| 19:28:24 | dansmith | sean-k-mooney: it has things that we don't need to persist after completion, unlike things we store in the migration record for posterity, like what flavor it was and what flavor it is now | |
| 19:28:46 | dansmith | mriedem: I meant the context doesn't have its own identifier | |
| 19:28:57 | mriedem | ah yeah | |
| 19:29:25 | dansmith | and, unfortunate that we used the id there I guess, as it makes it potentially less helpful for the cross-cell case | |
| 19:29:26 | mriedem | laura is home, the 2:30 vacuuming has started | |
| 19:29:53 | mriedem | for cross-cell everything is scoped to the cell db, so it's not a big deal | |
| 19:30:04 | dansmith | well, | |
| 19:30:07 | mriedem | conductor orchestrates the db switching when needed | |
| 19:30:17 | dansmith | once we want cross-cell live migration it'll probably be relevant | |
| 19:30:47 | mriedem | i think i'll probably be back at ibm working on php / xenapi by the time that happens.. | |
| 19:31:03 | mriedem | you know, the up and coming tech | |
| 19:31:04 | dansmith | it's a thing people want though | |
| 19:31:27 | mriedem | yeah, huawei's public cloud has a beta for cross-cell live migration, | |
| 19:31:28 | dansmith | especially if it were to make it easier to migrate from an older cloud to a newer one by making one a cell of the other until it's emptied | |
| 19:31:30 | mriedem | i'm not sure how they do it but... | |
| 19:31:34 | dansmith | that's been requested since icehouse or so | |
| 19:32:52 | sean-k-mooney | dansmith: we all know livemigration never works :P also if i get sirov live migration working this cycle i have no plan to test cross cell, sriov, nuam aware live migration between different releases during upgrade :) | |
| 19:33:14 | openstackgerrit | Matt Riedemann proposed openstack/nova stable/rocky: WIP: Test report_ironic_standard_resource_class_inventory=False https://review.openstack.org/609107 | |
| 19:33:40 | mriedem | there is no cross cell live migration... | |
| 19:34:51 | sean-k-mooney | mriedem: didnt you jsut say huawei's public cloud has beta supprot. i would assume they will ask you to upstream it a some point or is that complete different devision form yours? | |
| 19:35:40 | mriedem | completely different | |
| 19:35:54 | mriedem | their public cloud is still using cascading, which is their proprietary cells v1 | |
| 19:36:17 | mriedem | they are working on migrating off that to cells v2 | |
| 19:36:22 | dansmith | that's more like cross-deployment live migration | |
| 19:36:50 | sean-k-mooney | dansmith: is that still an ask from the edge working group? | |
| 19:37:06 | dansmith | is what? cross-deployment live migration? | |
| 19:37:12 | dansmith | I'm sure it'll be on their list at some point | |
| 19:37:27 | dansmith | I can see the cross-cell thing being fine, but I dunno about cross-deploy | |
| 19:38:17 | sean-k-mooney | ya when i was in the edge room in dublin i spent 15 minute explaining why cross cloud inter hyperviror live migration was never going to be a thing and should not be in the phase 1 basic feature support for edge | |
| 19:39:15 | sean-k-mooney | they litrally wanted to live migrate form libvirt + ceph in one edge site to vmware on another | |
| 19:39:56 | jaypipes | dansmith, mriedem, melwitt: is there a reason we don't pass instance metadata to the RequestSpec? | |
| 19:40:18 | dansmith | jaypipes: why would we need to? | |
| 19:40:34 | jaypipes | dansmith: so that scheduler filters can look at the instance metadata? :) | |
| 19:40:40 | dansmith | they should never do that | |
| 19:40:46 | dansmith | instance metadata is owned by the user not nova | |
| 19:40:52 | jaypipes | dansmith: oh, but Oath disagrees strongly. ;) | |
| 19:40:54 | dansmith | looking at it, especially for placement would violate | |
| 19:40:58 | dansmith | jaypipes: -2 | |
| 19:41:02 | jaypipes | hehe | |
| 19:41:03 | melwitt | but what about... custom filters YALL | |
| 19:41:13 | jaypipes | dansmith: what melwitt said :) | |
| 19:41:17 | dansmith | yeah | |
| 19:41:19 | jaypipes | dansmith: example... | |
| 19:41:23 | sean-k-mooney | jaypipes: jay just stuff the info in a schduler hint and use the json fileter | |
| 19:41:57 | mriedem | the request spec has an instance_uuid on it, you can get the instance from that and pull the metadata off the instance; that won't work for multi-create, but you probably don't care at oath | |
| 19:42:11 | dansmith | yup | |
| 19:42:15 | jaypipes | dansmith: nova boot --property ytag=SOME_CUSTOM_YAHOO_GOOP; nova scheduler has a filter that does an external lookup to our inventory management system of the ytag to grab the availability zone (really, just a power domain) to send the instance to | |
| 19:42:22 | dansmith | or hint yourself to an external artifact, fetch it and go nuts | |
| 19:42:44 | dansmith | jaypipes: yep, I got it, but metadata is off limits | |
| 19:43:17 | dansmith | --hint ytag-fml -> look up fml externally, do a thing | |
| 19:43:19 | jaypipes | mriedem: you can't do that. the instance_uuid is for the mapping, but the metadata doesn't exist yet, so if you try to call Instance.get_by_uuid(instance_uuid) from the filter, that's a dead end. | |
| 19:43:34 | mriedem | jaypipes: get the build request then | |
| 19:43:43 | jaypipes | mriedem: build request doesn't store metadata. | |
| 19:43:44 | melwitt | last I heard, oath does use multi-create. there's auto-scale stuff that boots several instances at once | |
| 19:43:47 | mriedem | jaypipes: sure it does, | |
| 19:43:49 | mriedem | it stores the instance | |
| 19:43:52 | mriedem | which stores the metadata | |
| 19:44:23 | dansmith | right, that's how we know what to create when we've picked a host :) | |
| 19:44:27 | jaypipes | mriedem: https://github.com/openstack/nova/blob/stable/ocata/nova/compute/api.py#L1004-L1007 | |
| 19:44:39 | jaypipes | mriedem: where exactly does the build request store the instance metadata? | |