Open Stack

> Hmm, I hadn't realised it would be quite this restricted. Although
> this could make it work, it does seem to be baking more ironic
> specifics into nova.

Well, that's what virt drivers are for. In the simplest implementation,
you have the Ironic virt driver's migrate_disk_and_power_off do the
restrictive checking (all the information you need should be available
to that method) and fail if necessary.

That sucks a little bit because the failure is late (at compute vs.
conductor or API). But that seems acceptable for something this limited,
and is really no different than e.g. the libvirt driver failing if you
try to resize the ephemeral disk down [1].

> There is an issue of standardisation here. Currently we do not have
> standard traits to describe these things, instead we use custom
> traits. The reason for this has been discussed earlier in this thread,
> essentially that we need to encode configuration key and value into
> the trait, and use the lack of a trait as 'don't care'. We did briefly
> discuss an alternative approach, but we're a fair way off having that.

I'm not sure that should really matter. If the logic lives in the virt
driver as suggested above, you can do whatever fancy parsing and
interpretation you like.

efried

P.S. I'll continue to repeat this disclaimer: I'm just spitballing here,
no idea if this approach would have the support of Nova maintainers at
large, or if there are major architectural blockers I'm not thinking of.

[1]
https://opendev.org/openstack/nova/src/branch/master/nova/virt/libvirt/driver.py#L8908-L8911