Open Stack

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.garza at rackspace.com>
wrote:

>
> On Jul 20, 2014, at 6:32 AM, Evgeny Fedoruk <EvgenyF at 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 at lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Stephen Balukoff
Blue Box Group, LLC
(800)613-4305 x807
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140723/cf58bd7e/attachment.html>