Open Stack

   The use case was that a cert inside the container could be updated while the private key stays the same. IE a new cert would be a resigning of the same old key. By immutable we mean to say that the same UUID would be used on the lbaas side. This is a heavy handed way of expecting the user to manually update their lbaas instances when they update a cert. 

    Yes we can live with an immutable container which seems to be the direction we are going now.

On Jun 9, 2014, at 2:54 PM, "Tiwari, Arvind" <arvind.tiwari at hp.com> wrote:

> As per current implementation, containers are immutable. 
> Do we have any use case to make it mutable? Can we live with new container instead of updating an existing container?
> 
> Arvind 
> 
> -----Original Message-----
> From: Samuel Bercovici [mailto:SamuelB at Radware.com] 
> Sent: Monday, June 09, 2014 1:31 PM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [Neutron][LBaaS] Barbican Neutron LBaaS Integration Ideas
> 
> 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
> 
> _______________________________________________
> 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