Open Stack

Stephen,

This will increase the complexity of the code since it will add managing the cache lifecycle in tandem with the barbican back end and the fact that containers may be shared by multiple listeners.
At this stage, I think that it serves us all to keep the code at this stage as small and simple as possible.

Let’s judge if presenting this information on the fly (ex: in the Web UI) becomes a performance issue and if it does, we can fix it then.

-Sam.


From: Stephen Balukoff [mailto:sbalukoff at bluebox.net]
Sent: Tuesday, July 22, 2014 3:43 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron][LBaaS] TLS capability - certificates data persistency

Evgeny--

The only reason I see for storing certificate information in Neutron (and not private key information-- just the certificate) is to aid in presenting UI information to the user. Especially GUI users don't care about a certificate's UUID, they care about which hostnames it's valid for. Yes, this can be loaded on the fly whenever public certificate information is accessed, but the perception was that it would be a significant performance increase to cache it.

Stephen

On Sun, Jul 20, 2014 at 4:32 AM, Evgeny Fedoruk <EvgenyF at radware.com<mailto: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?

Thank you,
Evg


_______________________________________________
OpenStack-dev mailing list
OpenStack-dev at lists.openstack.org<mailto: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/20140722/c1192cb9/attachment.html>