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:
On Jul 20, 2014, at 6:32 AM, Evgeny Fedoruk 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, mea
>
>
>
> 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
>
&
(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
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
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
