On 4/18/2018 11:57 AM, Jay Pipes wrote:
There is a compute REST API change proposed [1] which will allow users
to pass trusted certificate IDs to be used with validation of images
when creating or rebuilding a server. The trusted cert IDs are based
on certificates stored in some key manager, e.g. Barbican.
The full nova spec is here [2].
The main concern I have is that trusted certs will not be supported
for volume-backed instances, and some clouds only support
volume-backed instances.
Yes. And some clouds only support VMWare vCenter virt driver. And some
only support Hyper-V. I don't believe we should delay adding good
functionality to (large percentage of) clouds because it doesn't yet
work with one virt driver or one piece of (badly-designed) functionality.
Maybe it wasn't clear but I'm not advocating that we block the change
until volume-backed instances are supported with trusted certs. I'm
suggesting we add a policy rule which allows deployers to at least
disable it via policy if it's not supported for their cloud.
> The way the patch is written is that if the user attempts to
boot from volume with trusted certs, it will fail.
And... I think that's perfectly fine.
I agree. I'm the one that noticed the issue and pointed out in the code
review that we should explicitly fail the request if we can't honor it.
In thinking about a semi-discoverable/configurable solution, I'm
thinking we should add a policy rule around trusted certs to indicate
if they can be used or not. Beyond the boot from volume issue, the
only virt driver that supports trusted cert image validation is the
libvirt driver, so any cloud that's not using the libvirt driver
simply cannot support this feature, regardless of boot from volume. We
have added similar policy rules in the past for backend-dependent
features like volume extend and volume multi-attach, so I don't think
this is a new issue.
Alternatively we can block the change in nova until it supports boot
from volume, but that would mean needing to add trusted cert image
validation support into cinder along with API changes, effectively
killing the chance of this getting done in nova in Rocky, and this
blueprint has been around since at least Ocata so it would be good to
make progress if possible.
As mentioned above, I don't want to derail progress until (if ever?)
trusted certs achieves this magical
works-for-every-driver-and-functionality state. It's not realistic to
expect this to be done, IMHO, and just keeps good functionality out of
the hands of many cloud users.
Again, I'm not advocating that we block until boot from volume is
supported. However, we have a lot of technical debt for "good
functionality" added over the years that failed to consider
volume-backed instances, like rebuild, rescue, backup, etc and it's
painful to deal with that after the fact, as can be seen from the
various specs proposed for adding that support to those APIs.
--
Thanks,
Matt
_______________________________________________
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
