To elaborate on the case where containers get deleted while LBaaS still
references it.
We think that the following approach will do:
* The end user can delete a container and leave a "dangling" reference
in LBaaS.
* It would be nice to allow adding meta data on the container so that
the user will be aware which listeners use this container. This is optional. It
can also be optional for LBaaS to implement adding the listeners ID
automatically into this metadata just for information.
* In LBaaS, if an update happens which requires to pull the container
from Barbican and if the ID references a non-existing container, the update
will fail and will indicate that the reference certificate does not exists any
more. This validation could be implemented on the LBaaS API itself as well as
also by the driver who will actually need the container.
Regards,
-Sam.
From: Evgeny Fedoruk
Sent: Tuesday, June 10, 2014 2:13 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron][LBaaS] TLS support RST document on Gerrit
Hi All,
Carlos, Vivek, German, thanks for reviewing the RST doc.
There are some issues I want to pinpoint final decision on them here, in ML,
before writing it down in the doc.
Other issues will be commented on the document itself.
1. Support/No support in JUNO
Referring to summit's etherpad
https://etherpad.openstack.org/p/neutron-lbaas-ssl-l7,
a. SNI certificates list was decided to be supported. Was decision made
not to support it?
Single certificate with multiple domains can only partly address the need for
SNI, still, different applications
on back-end will need different certificates.
b. Back-end re-encryption was decided to be supported. Was decision made
not to support it?
c. With front-end client authentication and back-end server
authentication not supported,
Should certificate chains be supported?
2. Barbican TLS containers
a. TLS containers are immutable.
b. TLS container is allowed to be deleted, always.
i. Even
when it is used by LBaaS VIP listener (or other service).
ii. Meta data
on TLS container will help tenant to understand that container is in use by
LBaaS service/VIP listener
iii. If every
VIP listener will "register" itself in meta-data while retrieving container,
how that "registration" will be removed when VIP listener stops using the
certificate?
Please comment on these points and review the document on gerrit
(https://review.openstack.org/#/c/98640)
I will update the document with decisions on above topics.
Thank you!
Evgeny
From: Evgeny Fedoruk
Sent: Monday, June 09, 2014 2:54 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [Neutron][LBaaS] TLS support RST document on Gerrit
Hi All,
A Spec. RST document for LBaaS TLS support was added to Gerrit for review
https://review.openstack.org/#/c/98640
You are welcome to start commenting it for any open discussions.
I tried to address each aspect being discussed, please add comments about
missing things.
Thanks,
Evgeny
_______________________________________________
OpenStack-dev mailing list
[email protected]
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
