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.tiw...@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:samu...@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:vivekj...@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" <samu...@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.miramon...@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@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
