<div dir="ltr">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.<div><br></div>
<div>First we need to get it working, then we need to make it work fast. :)</div><div><br></div><div>Stephen</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Jul 22, 2014 at 4:04 PM, Carlos Garza <span dir="ltr"><<a href="mailto:carlos.garza@rackspace.com" target="_blank">carlos.garza@rackspace.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5"><br>
On Jul 20, 2014, at 6:32 AM, Evgeny Fedoruk <EvgenyF@Radware.com> wrote:<br>
<br>
> Hi folks,<br>
><br>
> In a current version of TLS capabilities RST certificate SubjectCommonName and SubjectAltName information is cached in a database.<br>
> This may be not necessary and here is why:<br>
><br>
> 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.<br>
> This is relevant for both, default container and containers used for SNI.<br>
> 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<br>
> new containers only. This is stated in “Performance Impact” section of the RST, excepting the last statement that proposes persistency for SCN and SAN.<br>
> 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<br>
> “SNI certificates list management” section of the RST.<br>
> 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.<br>
> 5.       Back-end provisioning system may cache any certificate data, except private key, in case of a specific need of the vendor.<br>
><br>
> IMO, There is no real need to store certificates data in Neutron database and manage its life cycle.<br>
> Does anyone sees a reason why caching certificates’ data in Neutron database is critical?<br>
<br>
</div></div>    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.<br>

<div class="HOEnZb"><div class="h5"><br>
<br>
<br>
> Thank you,<br>
> Evg<br>
><br>
><br>
> _______________________________________________<br>
> OpenStack-dev mailing list<br>
> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><span></span>Stephen Balukoff
<br>Blue Box Group, LLC
<br>(800)613-4305 x807

</div>