Open Stack

Sylvain and I were reviewing https://review.openstack.org/#/c/479949/ 
today and I'm at least a bit confused over how the 
enable_certificate_validation config option is meant to be used.

The current logic during driver.spawn() on the compute is going to be:

if the user supplied trusted certs or verify_glance_signatures:
     ...
     if user supplied trusted certs:
         # validate the user supplied trusted certs
     elif enable_certificate_validation:
         raise error because the user did not provide certs
     else:
         noop

I realize from the API change later in the series that if the user does 
not provide trusted certs when creating or rebuilding a server, and 
verify_glance_signatures=True, enable_certificate_validation=True and 
default_trusted_certificate_ids=[something], we use the configured 
default_trusted_certificate_ids so once we get down to the compute to 
verify the image signature it will look like the user supplied trusted 
certs (even if we are using the default_trusted_certificate_ids from 
config).

Is the point that, as an operator, I can say:

verify_glance_signatures=True - yes verify image signatures (at least on 
a subset of compute hosts)

enable_certificate_validation - yes verify certs (at least on a subset 
of compute hosts)

default_trusted_certificate_ids=[] - but I don't want to provide default 
trusted cert IDs, which forces my users to provider their own certs (at 
least on a subset of compute hosts)

In this scenario, if the user fails to provide trusted certs when 
creating or rebuilding a server, it's going to result in a build abort 
exception (NoValidHost) from the compute. Is that the intention?

Also, the enable_certificate_validation option is deprecated and meant 
for "transition" but what transition is that? And when will we drop the 
enable_certificate_validation option?

I'm trying to understand some of the upgrade flow here.

-- 

Thanks,

Matt