Open Stack

As far as I understand the Current Barbican implementation is immutable.
Can anyone from Barbican comment on this?

-----Original Message-----
From: Jain, Vivek [mailto:VIVEKJAIN at ebay.com] 
Sent: Monday, June 09, 2014 8:34 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron][LBaaS] Barbican Neutron LBaaS Integration Ideas

+1 for the idea of making certificate immutable.
However, if Barbican allows updating certs/containers then versioning is a must.

Thanks,
Vivek


On 6/8/14, 11:48 PM, "Samuel Bercovici" <SamuelB at Radware.com> wrote:

>Hi,
>
>I think that option 2 should be preferred at this stage.
>I also think that certificate should be immutable, if you want a new 
>one, create a new one and update the listener to use it.
>This removes any chance of mistakes, need for versioning etc.
>
>-Sam.
>
>-----Original Message-----
>From: Jorge Miramontes [mailto:jorge.miramontes at RACKSPACE.COM]
>Sent: Friday, June 06, 2014 10:16 PM
>To: OpenStack Development Mailing List (not for usage questions)
>Subject: [openstack-dev] [Neutron][LBaaS] Barbican Neutron LBaaS 
>Integration Ideas
>
>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
>
>
>_______________________________________________
>OpenStack-dev mailing list
>OpenStack-dev at lists.openstack.org
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>_______________________________________________
>OpenStack-dev mailing list
>OpenStack-dev at lists.openstack.org
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


_______________________________________________
OpenStack-dev mailing list
OpenStack-dev at lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev