Open Stack

>  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 <VIVEKJAIN at 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.eichberger at 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.miramontes at 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.wood at 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.Laribi at 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.miramontes at 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 at lists.openstack.org
> >>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >>
> >>_______________________________________________
> >>OpenStack-dev mailing list
> >>OpenStack-dev at lists.openstack.org
> >>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >>
> >>_______________________________________________
> >>OpenStack-dev mailing list
> >>OpenStack-dev at lists.openstack.org
> >>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> >
> >_______________________________________________
> >OpenStack-dev mailing list
> >OpenStack-dev at lists.openstack.org
> >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> >_______________________________________________
> >OpenStack-dev mailing list
> >OpenStack-dev at lists.openstack.org
> >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140608/011fdf8a/attachment.html>