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:sbaluk...@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 <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? > > > > Thank you, > > Evg > > > > > > _______________________________________________ > 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 _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev