I think that would defeat a big purpose for barbican; a user only has to store their secret in one central location for reuse with many services.
Thanks, Brandon On Sun, 2014-06-08 at 09:05 +0400, Eugene Nikanorov wrote: > > If a user makes a change to a secret > Can we just disable that by making LBaaS a separate user so it would > store secrets under LBaaS 'fake' tenant id? > > > Eugene. > > > On Sun, Jun 8, 2014 at 7:29 AM, Jain, Vivek <vivekj...@ebay.com> > wrote: > +1 for #2. > > In addition, I think it would be nice if barbican maintains > versioned data > on updates. Which means consumer of barbican APIs can request > for data > from older version if needed. This can address concerns > expressed by > German. For example if certificates were updated on barbican > but somehow > update is not compatible with load balancer device, then lbaas > API user > gets an option to fall back to older working certificate. That > will avoid > downtime of lbaas managed applications. > > Thanks, > Vivek > > On 6/6/14, 3: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 > > > > _______________________________________________ > 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
