Open Stack

Hey everyone,

Per our IRC discussion yesterday I'd like to continue the discussion on
how Barbican and Neutron LBaaS will interact. There are currently two
ideas in play and both will work. If you have another idea please free to
add it so that we may evaluate all the options relative to each other.
Here are the two current ideas:

1. Create an eventing system for Barbican that Neutron LBaaS (and other
services) consumes to identify when to update/delete updated secrets from
Barbican. For those that aren't up to date with the Neutron LBaaS API
Revision, the project/tenant/user provides a secret (container?) id when
enabling SSL/TLS functionality.

* Example: If a user makes a change to a secret/container in Barbican then
Neutron LBaaS will see an event and take the appropriate action.

PROS:
 - Barbican is going to create an eventing system regardless so it will be
supported.
 - Decisions are made on behalf of the user which lessens the amount of
calls the user has to make.

CONS:
 - An eventing framework can become complex especially since we need to
ensure delivery of an event.
 - Implementing an eventing system will take more time than option #2ŠI
think.

2. Push orchestration decisions to API users. This idea comes with two
assumptions. The first assumption is that most providers' customers use
the cloud via a GUI, which in turn can handle any orchestration decisions
that need to be made. The second assumption is that power API users are
savvy and can handle their decisions as well. Using this method requires
services, such as LBaaS, to "register" in the form of metadata to a
barbican container.

* Example: If a user makes a change to a secret the GUI can see which
services are registered and opt to warn the user of consequences. Power
users can look at the registered services and make decisions how they see
fit.

PROS:
 - Very simple to implement. The only code needed to make this a reality
is at the control plane (API) level.
 - This option is more loosely coupled that option #1.

CONS:
 - Potential for services to not register/unregister. What happens in this
case?
 - Pushes complexity of decision making on to GUI engineers and power API
users.


I would like to get a consensus on which option to move forward with ASAP
since the hackathon is coming up and delivering Barbican to Neutron LBaaS
integration is essential to exposing SSL/TLS functionality, which almost
everyone has stated is a #1/#2 priority.

I'll start the decision making process by advocating for option #2. My
reason for choosing option #2 has to deal mostly with the simplicity of
implementing such a mechanism. Simplicity also means we can implement the
necessary code and get it approved much faster which seems to be a concern
for everyone. What option does everyone else want to move forward with?



Cheers,
--Jorge