| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-09-04 | |||
| 16:42:10 | sean-k-mooney | but both the availablity zone and json filters can technically do it | |
| 16:42:25 | aspiers | efried, kashyap: nits with q35 check addressed | |
| 16:42:50 | donnyd | With the json filter, will it fail if it cannot find the specific host? | |
| 16:42:59 | sean-k-mooney | yes | |
| 16:43:14 | donnyd | ok, I think both of those two options will work for this case | |
| 16:43:20 | donnyd | much appreciated sean-k-mooney | |
| 16:44:04 | sean-k-mooney | donnyd: the json filter basicaly allows you to match on anything in this object https://github.com/openstack/nova/blob/master/nova/scheduler/host_manager.py#L109-L159 so you can be very specific | |
| 16:46:49 | sean-k-mooney | donnyd: you might be able to use https://zuul-ci.org/docs/nodepool/configuration.html#attr-providers.[openstack].pools.labels.instance-properties | |
| 16:46:56 | sean-k-mooney | but you defintely can use https://zuul-ci.org/docs/nodepool/configuration.html#attr-providers.[openstack].pools.availability-zones | |
| 16:47:23 | sean-k-mooney | well i have never tired it | |
| 16:52:54 | mriedem | ewww jsonfilter | |
| 16:53:13 | mriedem | i'm not sure how that helps with linking hosts with a given trait | |
| 16:53:40 | sean-k-mooney | mriedem: it does not. donnyd wanted a way per vm to selct a given host | |
| 16:53:43 | mriedem | donnyd: you can use the placement CLI to filter providers with required traits as well https://docs.openstack.org/osc-placement/latest/cli/index.html#resource-provider-list | |
| 16:53:51 | donnyd | ask placement for host that matches x trait and then place request in for Host that is returned | |
| 16:54:05 | mriedem | donnyd: which version of nova? | |
| 16:54:20 | donnyd | .latest atm | |
| 16:54:35 | sean-k-mooney | latest as in stien not master | |
| 16:54:38 | donnyd | This isn't for FN, its for a different CI I am working on | |
| 16:54:49 | mriedem | so stein or master? | |
| 16:54:52 | mriedem | b/c train has https://docs.openstack.org/nova/latest/reference/api-microversion-history.html#id66 | |
| 16:54:56 | donnyd | Probably going to be train | |
| 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 | |