It looks like this has come full circle and we are back at the simplest case.
# Containers are immutable # Changing a cert means creating a new container and, when ready, pointing LBaaS at the new container This makes a lot of sense to me, it removes a lot of handholding and keeps Barbican and LBaaS nicely decoupled. It also keeps certificate lifecycle management firmly in the hands of the user, which imho is a good thing. With this model it’s fairly trivial to provide guidance / additional tooling for lifecycle management if required but at the same time the simplest case (I want a cert and I want LBaaS) is met without massive code overhead for edge-cases. From: Vijay Venkatachalam <vijay.venkatacha...@citrix.com<mailto:vijay.venkatacha...@citrix.com>> Reply-To: OpenStack List <openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>> Date: Tuesday, 10 June 2014 05:48 To: OpenStack List <openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>> Subject: Re: [openstack-dev] [Neutron][LBaaS] Barbican Neutron LBaaS Integration Ideas My vote is for option #2 (without the registration). It is simpler to start with this approach. How is delete handled though? Ex. What is the expectation when user attempts to delete a certificate/container which is referred by an entity like LBaaS listener? 1. Will there be validation in Barbican to prevent this? *OR* 2. LBaaS listener will have a dangling reference/pointer to certificate? Thanks, Vijay V. From: Stephen Balukoff [mailto:sbaluk...@bluebox.net] Sent: Tuesday, June 10, 2014 7:43 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Neutron][LBaaS] Barbican Neutron LBaaS Integration Ideas Weighing in here: I'm all for option #2 as well. Stephen On Mon, Jun 9, 2014 at 4:42 PM, Clint Byrum <cl...@fewbar.com<mailto:cl...@fewbar.com>> wrote: Excerpts from Douglas Mendizabal's message of 2014-06-09 16:08:02 -0700: > Hi all, > > I’m strongly in favor of having immutable TLS-typed containers, and very > much opposed to storing every revision of changes done to a container. I > think that storing versioned containers would add too much complexity to > Barbican, where immutable containers would work well. > Agree completely. Create a new one for new values. Keep the old ones while they're still active. > > I’m still not sold on the idea of registering services with Barbican, even > though (or maybe especially because) Barbican would not be using this data > for anything. I understand the problem that we’re trying to solve by > associating different resources across projects, but I don’t feel like > Barbican is the right place to do this. > Agreed also, this is simply not Barbican or Neutron's role. Be a REST API for secrets and networking, not all dancing all singing nannies that prevent any possibly dangerous behavior with said API's. > It seems we’re leaning towards option #2, but I would argue that > orchestration of services is outside the scope of Barbican’s role as a > secret-store. I think this is a problem that may need to be solved at a > higher level. Maybe an openstack-wide registry of dependend entities > across services? An optional openstack-wide registry of depended entities is called "Heat". _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org<mailto: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
