> 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 <[email protected]> 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" <[email protected]> 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:[email protected]] > >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" <[email protected]> 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 [[email protected]] > >>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:[email protected]] > >>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 > >>[email protected] > >>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >> > >>_______________________________________________ > >>OpenStack-dev mailing list > >>[email protected] > >>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >> > >>_______________________________________________ > >>OpenStack-dev mailing list > >>[email protected] > >>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > > >_______________________________________________ > >OpenStack-dev mailing list > >[email protected] > >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > >_______________________________________________ > >OpenStack-dev mailing list > >[email protected] > >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > _______________________________________________ > OpenStack-dev mailing list > [email protected] > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
_______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
