Hi folks, In a current version of TLS capabilities RST certificate SubjectCommonName and SubjectAltName information is cached in a database. This may be not necessary and here is why:
1. TLS containers are immutable, meaning once a container was associated to a listener and was validated, it's not necessary to validate the container anymore. This is relevant for both, default container and containers used for SNI. 2. LBaaS front-end API can check if TLS containers ids were changed for a listener as part of an update operation. Validation of containers will be done for new containers only. This is stated in "Performance Impact" section of the RST, excepting the last statement that proposes persistency for SCN and SAN. 3. Any interaction with Barbican API for getting containers data will be performed via a common module API only. This module's API is mentioned in "SNI certificates list management" section of the RST. 4. In case when driver really needs to extract certificate information prior to the back-end system provisioning, it will do it via the common module API. 5. Back-end provisioning system may cache any certificate data, except private key, in case of a specific need of the vendor. IMO, There is no real need to store certificates data in Neutron database and manage its life cycle. Does anyone sees a reason why caching certificates' data in Neutron database is critical? Thank you, Evg
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
