Open Stack

Hey German,

I agree with you. I don't really want to go with option #1 because making
decisions on behalf of the user (especially when security is involved) can
be quite tricky and dangerous. Your concerns are valid for option #2 but I
still think it is the better option to go with. I believe Carlos and Adam
are working with our Barbican team on a blueprint for option #2 so it
would be nice if you could take a look at that and see how we can
implement it to mitigate the concerns you laid out. While it would be nice
for us to figure out how to ensure registration/unregistration at least
the API user has the necessary info to ensure it themselves if need be.

I'm not sure if I like the "auto-update" flag concept after all as it adds
a layer of complexity depending on what the user has set.  I'd prefer
either an "LBaaS makes all decisions on behalf of the user" or "LBaaS
makes no deacons on behalf of the user" approach with the latter being my
preference. In one of my earlier emails I asked the fundamental question
of whether "flexibility" is worthwhile at the cost of complexity. I prefer
to start off simple since we don't have any real validation on whether
these "flexible" features will actually be used. Once we have a product
that is being widely deployed should "flexible" feature necessity become
evident.

Cheers,
--Jorge




On 6/6/14 5: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