Open Stack

I agree with Sam.  We're under a strict timeline here and the simpler
the code the faster it will be implemented and reviewed.  Is there any
strong reason why this caching can't wait until K if it decided it is
really needed?

Thanks,
Brandon

On Tue, 2014-07-22 at 11:01 +0000, Samuel Bercovici wrote:
> 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>
> 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
> 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 at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev