[openstack-dev] [Neutron][LBaaS] Barbican Neutron LBaaS Integration Ideas

Clark, Robert Graham robert.clark at hp.com
Tue Jun 10 11:21:25 UTC 2014


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.Venkatachalam at citrix.com<mailto:Vijay.Venkatachalam at citrix.com>>
Reply-To: OpenStack List <openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>>
Date: Tuesday, 10 June 2014 05:48
To: OpenStack List <openstack-dev at lists.openstack.org<mailto:openstack-dev at 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:sbalukoff at 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 <clint at fewbar.com<mailto:clint at 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 at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



--
Stephen Balukoff
Blue Box Group, LLC
(800)613-4305 x807



More information about the OpenStack-dev mailing list