| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-09-04 | |||
| 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 | donnyd | well then it will be worth the wait | |
| 16:58:48 | mriedem | host = nova-compute service hostname | |
| 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 | sean-k-mooney | or in a prifilter i guess | |
| 17:40:47 | aspiers | sean-k-mooney: that's what I want to do, yep | |
| 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 | |