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
