I understand this concern and was advocating that a configuration option be available to disable or enable auto updating of SSL certificates. But since every one is in favor of storing meta data on the barbican container directly I guess this is a moot point now.
On Jun 6, 2014, at 5:52 PM, "Eichberger, German" <german.eichber...@hp.com> wrote: > Jorge + John, > > I am most concerned with a user changing his secret in barbican and then the > LB trying to update and causing downtime. Some users like to control when the > downtime occurs. > > For #1 it was suggested that once the event is delivered it would be up to a > user to enable an "auto-update flag". > > In the case of #2 I am a bit worried about error cases: e.g. uploading the > certificates succeeds but registering the loadbalancer(s) fails. So using the > barbican system for those warnings might not as fool proof as we are hoping. > > One thing I like about #2 over #1 is that it pushes a lot of the information > to Barbican. I think a user would expect when he uploads a new certificate to > Barbican that the system warns him right away about load balancers using the > old cert. With #1 he might get an e-mails from LBaaS telling him things > changed (and we helpfully updated all affected load balancers) -- which isn't > as immediate as #2. > > If we implement an "auto-update flag" for #1 we can have both. User's who > like #2 juts hit the flag. Then the discussion changes to what we should > implement first and I agree with Jorge + John that this should likely be #2. > > German > > -----Original Message----- > From: Jorge Miramontes [mailto:jorge.miramon...@rackspace.com] > Sent: Friday, June 06, 2014 3:05 PM > To: OpenStack Development Mailing List (not for usage questions) > Subject: Re: [openstack-dev] [Neutron][LBaaS] Barbican Neutron LBaaS > Integration Ideas > > Hey John, > > Correct, I was envisioning that the Barbican request would not be affected, > but rather, the GUI operator or API user could use the registration > information to do so should they want to do so. > > Cheers, > --Jorge > > > > > On 6/6/14 4:53 PM, "John Wood" <john.w...@rackspace.com> wrote: > >> Hello Jorge, >> >> Just noting that for option #2, it seems to me that the registration >> feature in Barbican would not be required for the first version of this >> integration effort, but we should create a blueprint for it nonetheless. >> >> As for your question about services not registering/unregistering, I >> don't see an issue as long as the presence or absence of registered >> services on a Container/Secret does not **block** actions from >> happening, but rather is information that can be used to warn clients >> through their processes. For example, Barbican would still delete a >> Container/Secret even if it had registered services. >> >> Does that all make sense though? >> >> Thanks, >> John >> >> ________________________________________ >> From: Youcef Laribi [youcef.lar...@citrix.com] >> Sent: Friday, June 06, 2014 2:47 PM >> To: OpenStack Development Mailing List (not for usage questions) >> Subject: Re: [openstack-dev] [Neutron][LBaaS] Barbican Neutron LBaaS >> Integration Ideas >> >> +1 for option 2. >> >> In addition as an additional safeguard, the LBaaS service could check >> with Barbican when failing to use an existing secret to see if the >> secret has changed (lazy detection). >> >> Youcef >> >> -----Original Message----- >> From: Jorge Miramontes [mailto:jorge.miramon...@rackspace.com] >> Sent: Friday, June 06, 2014 12: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
