I'm willing to go with simpler code that gets us this feature faster, and re-evaluating whether storing some extra data on certificates locally makes significant performance gains later on.
First we need to get it working, then we need to make it work fast. :) Stephen On Tue, Jul 22, 2014 at 4:04 PM, Carlos Garza <carlos.ga...@rackspace.com> wrote: > > On Jul 20, 2014, at 6:32 AM, Evgeny Fedoruk <evge...@radware.com> wrote: > > > 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? > > Its not so much caching the certificate. Lets just say when an lb > change comes into the API that wants to add an X509 then we need to parse > the subjectNames and SubjectAltNames from the previous X509s which aren't > available to us so we must grab them all from barbican over the rest > interface. Like I said in an earlier email its a balancing act between > "Single Source of Truth" vs how much lag were willing to deal with. > > > > > Thank you, > > Evg > > > > > > _______________________________________________ > > OpenStack-dev mailing list > > OpenStack-dev@lists.openstack.org > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Stephen Balukoff Blue Box Group, LLC (800)613-4305 x807
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev