| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-09-04 | |||
| 16:54:58 | mriedem | which would be your easiest thing | |
| 16:55:06 | mriedem | in train the server create api takes a requested host | |
| 16:55:12 | mriedem | and runs it through the scheduler | |
| 16:55:37 | mriedem | otherwise you can use the JsonFilter like sean-k-mooney said or force the host of your choosing with admin creds | |
| 16:55:38 | sean-k-mooney | ya that is the best approch if you can use train. although nodepool wont supprot that | |
| 16:55:52 | mriedem | https://docs.openstack.org/nova/latest/admin/availability-zones.html | |
| 16:55:55 | mriedem | ^ forced host | |
| 16:56:03 | donnyd | sean-k-mooney: Not sure it will be using nodepool | |
| 16:56:20 | mriedem | heed the JsonFilter warnings https://docs.openstack.org/nova/latest/admin/configuration/schedulers.html#jsonfilter | |
| 16:56:53 | mriedem | JsonFilter is pretty common for putting a baremetal instance on a specific baremetal node | |
| 16:57:08 | mriedem | 2.74 avoids the need for the JsonFilter for that though, which is nice | |
| 16:57:46 | sean-k-mooney | yep | |
| 16:57:51 | donnyd | mriedem: that is quite precisely the use case. Trying to pick a specific metal host | |
| 16:58:26 | donnyd | in train will that work for metal and VM? | |
| 16:58:36 | mriedem | yes | |
| 16:58:41 | donnyd | nice | |
| 16:58:48 | mriedem | host = nova-compute service hostname | |
| 16:58:48 | donnyd | well then it will be worth the wait | |
| 16:58:50 | donnyd | :) | |
| 16:59:02 | mriedem | hypervisor_hostname = node name = ironic uuid | |
| 16:59:20 | mriedem | for kvm the host and hypervisor_hostname are the same thing | |
| 16:59:28 | sean-k-mooney | donnyd: by way do you openstack to reinstall the os on the ironic node | |
| 17:00:24 | sean-k-mooney | if you dont you can also use the static driver if you end up using node pool https://zuul-ci.org/docs/nodepool/configuration.html#static-driver | |
| 17:01:13 | sean-k-mooney | adding support to the new feature to the openstack driver however could be useful | |
| 17:02:12 | donnyd | sean-k-mooney: I openstack for everything in FN | |
| 17:37:35 | sean-k-mooney | artom: dansmit: sorry have been distracted by a headache that developed over the lst hour or two. | |
| 17:38:01 | sean-k-mooney | i finally gets master compute + artom code on contoler | |
| 17:38:13 | sean-k-mooney | the migration was the same as the pinned rpc. | |
| 17:38:23 | sean-k-mooney | actully its stil pinned ill unpin and check | |
| 17:38:39 | aspiers | sean-k-mooney: can you quickly advise me on where to add a check to refuse API requests to migrate/suspend SEV guests? is nova/compute/api.py the right place? | |
| 17:38:57 | aspiers | it's libvirt-specific so kind of feels like it belongs in the driver | |
| 17:39:23 | mriedem | aspiers: isn't it a generic trait in the flavor though? | |
| 17:39:47 | mriedem | failing in the driver kind of sucks if you flat out don't support migrating that type of instance | |
| 17:39:48 | sean-k-mooney | mriedem: well there is a generic resouce class | |
| 17:39:54 | aspiers | mriedem: no, typically the trait won't be used until Intel MKTME comes in | |
| 17:40:00 | mriedem | meaning you'll reschedule to another host that will also fail | |
| 17:40:07 | aspiers | mriedem: right, that's what I was worried about | |
| 17:40:19 | mriedem | what makes a sev instance a sev instance? | |
| 17:40:23 | mriedem | something in the flavor or image right? | |
| 17:40:25 | aspiers | yes | |
| 17:40:30 | aspiers | hw:mem_encryption | |
| 17:40:36 | sean-k-mooney | you could block it either in the api by checking for the flavor extra spec | |
| 17:40:47 | aspiers | sean-k-mooney: that's what I want to do, yep | |
| 17:40:47 | sean-k-mooney | or in a prifilter i guess | |
| 17:40:58 | aspiers | I'm just trying to find the right bit of code | |
| 17:41:09 | mriedem | pre-filter doesn't work since it doesn't have the context on you doing a move operatoin vs a server create | |
| 17:41:18 | sean-k-mooney | its the validate_flavor_image_nostatus funciton | |
| 17:41:22 | mriedem | so just failing fast in the api or conductor would be sufficient | |
| 17:41:25 | sean-k-mooney | or one that it calls | |
| 17:41:42 | aspiers | nova.compute.api.API.live_migrate()? | |
| 17:42:01 | mriedem | what about cold migrate? does that work? | |
| 17:42:07 | aspiers | no | |
| 17:42:08 | sean-k-mooney | aspiers: you can do it the way we do for sriov migration i guess. | |
| 17:42:12 | aspiers | need to also block suspend | |
| 17:42:13 | sean-k-mooney | aspiers: no? | |
| 17:42:23 | sean-k-mooney | why would cold migration not work | |
| 17:42:35 | sean-k-mooney | suspenmd i get | |
| 17:42:38 | aspiers | oh sorry | |
| 17:42:39 | mriedem | heh, you might as well just write a decorator then | |
| 17:42:42 | sean-k-mooney | its doing a managed save | |
| 17:42:47 | aspiers | yeah cold migration probably OK | |
| 17:42:54 | aspiers | http://specs.openstack.org/openstack/nova-specs/specs/train/approved/amd-sev-libvirt-support.html#limitations | |
| 17:43:08 | aspiers | yes, cold migration/shelve is OK | |
| 17:43:23 | aspiers | That's why I explicitly wrote that in the spec - cos I knew I'd forget later ;-) | |
| 17:44:06 | mriedem | def block_for_sev(func, context, instance, *args, **kwargs): if 'hw:mem_encryption' in instance.flavor.extra_specs: raise OperationNotSupportedForSev() | |
| 17:44:13 | sean-k-mooney | aspiers: if you do it in the conductor do it here. but if you eant to do it in the api. yuou need to do in a different location | |
| 17:44:16 | sean-k-mooney | https://github.com/openstack/nova/blob/master/nova/conductor/tasks/live_migrate.py#L318 | |
| 17:44:19 | mriedem | then just decorate the methods that don't support sev instances | |
| 17:44:20 | sean-k-mooney | ill see if i can find it | |
| 17:44:49 | mriedem | it would be nice to not duplicate the same checks all over the api and conductor... | |
| 17:44:53 | aspiers | agreed | |
| 17:44:59 | sean-k-mooney | ya | |
| 17:45:12 | sean-k-mooney | sicne we know this just wont work for sev instace right now i think the api is better | |
| 17:45:15 | aspiers | presumably better UX if it's done in the API? | |
| 17:45:17 | sean-k-mooney | just flat out block it | |
| 17:45:35 | sean-k-mooney | yes we will end up doing less work too | |
| 17:45:49 | aspiers | right, so is e.g. nova.compute.api.API.live_migrate() the right place? | |
| 17:46:01 | aspiers | using a decorator like mriedem suggested | |
| 17:46:31 | sean-k-mooney | the problem with doing it in the api is when another dirver starts support sev then we need to remove it and move it to the condocor or somethwer else that can be aware of the hypervior type | |
| 17:46:45 | openstackgerrit | Stephen Finucane proposed openstack/nova master: libvirt: Start reporting PCPU inventory to placement https://review.opendev.org/671793 | |
| 17:46:46 | openstackgerrit | Stephen Finucane proposed openstack/nova master: hardware: Differentiate between shared and dedicated CPUs https://review.opendev.org/671800 | |
| 17:46:46 | openstackgerrit | Stephen Finucane proposed openstack/nova master: libvirt: '_get_(v|p)cpu_total' to '_get_(v|p)cpu_available' https://review.opendev.org/672693 | |
| 17:46:47 | openstackgerrit | Stephen Finucane proposed openstack/nova master: Add support for translating CPU policy extra specs, image meta https://review.opendev.org/671801 | |
| 17:46:47 | openstackgerrit | Stephen Finucane proposed openstack/nova master: libvirt: Start reporting 'HW_CPU_HYPERTHREADING' trait https://review.opendev.org/675571 | |
| 17:46:48 | openstackgerrit | Stephen Finucane proposed openstack/nova master: objects: Add 'InstanceNUMATopology.cpu_pinning' property https://review.opendev.org/680106 | |
| 17:46:48 | openstackgerrit | Stephen Finucane proposed openstack/nova master: Add reshaper for PCPU https://review.opendev.org/674895 | |
| 17:46:49 | openstackgerrit | Stephen Finucane proposed openstack/nova master: objects: Add 'NUMACell.pcpuset' field https://review.opendev.org/680108 | |
| 17:46:49 | openstackgerrit | Stephen Finucane proposed openstack/nova master: Validate CPU config options against running instances https://review.opendev.org/680107 | |
| 17:47:01 | aspiers | sean-k-mooney: what other driver would start to support SEV? | |
| 17:47:17 | stephenfin | mriedem: If you're interested, there's the startup check I was talking about earlier https://review.opendev.org/680107 | |
| 17:47:18 | sean-k-mooney | hyperv maybe? vmware | |
| 17:47:35 | sean-k-mooney | i mean its not a kvm tech it hsould be usable on other hyperviors | |
| 17:47:36 | stephenfin | aspiers: Might be of interest to you, actually ^ | |
| 17:47:45 | stephenfin | It's a similar thing to what you need, I suspect | |
| 17:47:52 | stephenfin | sean-k-mooney can confirm | |
| 17:47:54 | sean-k-mooney | aspiers: what i would do is write a check in hardware.py | |
| 17:47:57 | stephenfin | though /me has to go | |
| 17:47:58 | sean-k-mooney | then call that form the api | |
| 17:48:02 | sean-k-mooney | and or conductor | |
| 17:48:09 | aspiers | sean-k-mooney: there is already a check in hardware.py | |