I understand how this could be helpful, but I still don’t understand why this is Barbican’s problem to solve.
>From Jorge’s original email: >> Using this method requires services, such as LBaaS, to "register" in >>the form of metadata to a barbican container. If our assumptions are that the GUI can handle information, and that power users are savvy. Then how does that require Barbican to store the metadata? I would argue that the GUI can store its own metadata, and that Power Users should be savvy enough to update their LBs (via PUT or whatever) after uploading a new certificate. -Doug On 6/9/14, 6:10 PM, "John Wood" <john.w...@rackspace.com> wrote: >The impression I have from this thread is that Containers should remain >immutable, but it would be helpful to allow services like LBaaS to >register as interested in a given Container. This could be the full URI >to the load balancer instance for example. This information would allow >clients to see what services (and load balancer instances in this >example) are using a Container, so they can update them if a new >Container replaces the old one. They could also see what services depend >on a Container before trying to remove the Container. > >A blueprint submission to Barbican tomorrow should provide more details >on this, and let the Barbican and LBaaS communities weigh in on this >feature. > >Thanks, >John > > >________________________________________ >From: Tiwari, Arvind [arvind.tiw...@hp.com] >Sent: Monday, June 09, 2014 2:54 PM >To: OpenStack Development Mailing List (not for usage questions) >Subject: Re: [openstack-dev] [Neutron][LBaaS] Barbican Neutron LBaaS >Integration Ideas > >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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev