<div dir="ltr">> <span style="font-family:arial,sans-serif;font-size:13px"> If a user makes a change to a secret</span><div><span style="font-family:arial,sans-serif;font-size:13px">Can we just disable that by making LBaaS a separate user so it would store secrets under LBaaS 'fake' tenant id?</span></div>
<div><span style="font-family:arial,sans-serif;font-size:13px"><br></span></div><div><span style="font-family:arial,sans-serif;font-size:13px">Eugene.</span></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">
On Sun, Jun 8, 2014 at 7:29 AM, Jain, Vivek <span dir="ltr"><<a href="mailto:VIVEKJAIN@ebay.com" target="_blank">VIVEKJAIN@ebay.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
+1 for #2.<br>
<br>
In addition, I think it would be nice if barbican maintains versioned data<br>
on updates. Which means consumer of barbican APIs can request for data<br>
from older version if needed. This can address concerns expressed by<br>
German. For example if certificates were updated on barbican but somehow<br>
update is not compatible with load balancer device, then lbaas API user<br>
gets an option to fall back to older working certificate. That will avoid<br>
downtime of lbaas managed applications.<br>
<br>
Thanks,<br>
Vivek<br>
<div class="HOEnZb"><div class="h5"><br>
On 6/6/14, 3:52 PM, "Eichberger, German" <<a href="mailto:german.eichberger@hp.com">german.eichberger@hp.com</a>> wrote:<br>
<br>
>Jorge + John,<br>
><br>
>I am most concerned with a user changing his secret in barbican and then<br>
>the LB trying to update and causing downtime. Some users like to control<br>
>when the downtime occurs.<br>
><br>
>For #1 it was suggested that once the event is delivered it would be up<br>
>to a user to enable an "auto-update flag".<br>
><br>
>In the case of #2 I am a bit worried about error cases: e.g. uploading<br>
>the certificates succeeds but registering the loadbalancer(s) fails. So<br>
>using the barbican system for those warnings might not as fool proof as<br>
>we are hoping.<br>
><br>
>One thing I like about #2 over #1 is that it pushes a lot of the<br>
>information to Barbican. I think a user would expect when he uploads a<br>
>new certificate to Barbican that the system warns him right away about<br>
>load balancers using the old cert. With #1 he might get an e-mails from<br>
>LBaaS telling him things changed (and we helpfully updated all affected<br>
>load balancers) -- which isn't as immediate as #2.<br>
><br>
>If we implement an "auto-update flag" for #1 we can have both. User's who<br>
>like #2 juts hit the flag. Then the discussion changes to what we should<br>
>implement first and I agree with Jorge + John that this should likely be<br>
>#2.<br>
><br>
>German<br>
><br>
>-----Original Message-----<br>
>From: Jorge Miramontes [mailto:<a href="mailto:jorge.miramontes@RACKSPACE.COM">jorge.miramontes@RACKSPACE.COM</a>]<br>
>Sent: Friday, June 06, 2014 3:05 PM<br>
>To: OpenStack Development Mailing List (not for usage questions)<br>
>Subject: Re: [openstack-dev] [Neutron][LBaaS] Barbican Neutron LBaaS<br>
>Integration Ideas<br>
><br>
>Hey John,<br>
><br>
>Correct, I was envisioning that the Barbican request would not be<br>
>affected, but rather, the GUI operator or API user could use the<br>
>registration information to do so should they want to do so.<br>
><br>
>Cheers,<br>
>--Jorge<br>
><br>
><br>
><br>
><br>
>On 6/6/14 4:53 PM, "John Wood" <<a href="mailto:john.wood@RACKSPACE.COM">john.wood@RACKSPACE.COM</a>> wrote:<br>
><br>
>>Hello Jorge,<br>
>><br>
>>Just noting that for option #2, it seems to me that the registration<br>
>>feature in Barbican would not be required for the first version of this<br>
>>integration effort, but we should create a blueprint for it nonetheless.<br>
>><br>
>>As for your question about services not registering/unregistering, I<br>
>>don't see an issue as long as the presence or absence of registered<br>
>>services on a Container/Secret does not **block** actions from<br>
>>happening, but rather is information that can be used to warn clients<br>
>>through their processes. For example, Barbican would still delete a<br>
>>Container/Secret even if it had registered services.<br>
>><br>
>>Does that all make sense though?<br>
>><br>
>>Thanks,<br>
>>John<br>
>><br>
>>________________________________________<br>
>>From: Youcef Laribi [<a href="mailto:Youcef.Laribi@citrix.com">Youcef.Laribi@citrix.com</a>]<br>
>>Sent: Friday, June 06, 2014 2:47 PM<br>
>>To: OpenStack Development Mailing List (not for usage questions)<br>
>>Subject: Re: [openstack-dev] [Neutron][LBaaS] Barbican Neutron LBaaS<br>
>>Integration Ideas<br>
>><br>
>>+1 for option 2.<br>
>><br>
>>In addition as an additional safeguard, the LBaaS service could check<br>
>>with Barbican when failing to use an existing secret to see if the<br>
>>secret has changed (lazy detection).<br>
>><br>
>>Youcef<br>
>><br>
>>-----Original Message-----<br>
>>From: Jorge Miramontes [mailto:<a href="mailto:jorge.miramontes@RACKSPACE.COM">jorge.miramontes@RACKSPACE.COM</a>]<br>
>>Sent: Friday, June 06, 2014 12:16 PM<br>
>>To: OpenStack Development Mailing List (not for usage questions)<br>
>>Subject: [openstack-dev] [Neutron][LBaaS] Barbican Neutron LBaaS<br>
>>Integration Ideas<br>
>><br>
>>Hey everyone,<br>
>><br>
>>Per our IRC discussion yesterday I'd like to continue the discussion on<br>
>>how Barbican and Neutron LBaaS will interact. There are currently two<br>
>>ideas in play and both will work. If you have another idea please free<br>
>>to add it so that we may evaluate all the options relative to each other.<br>
>>Here are the two current ideas:<br>
>><br>
>>1. Create an eventing system for Barbican that Neutron LBaaS (and other<br>
>>services) consumes to identify when to update/delete updated secrets<br>
>>from Barbican. For those that aren't up to date with the Neutron LBaaS<br>
>>API Revision, the project/tenant/user provides a secret (container?) id<br>
>>when enabling SSL/TLS functionality.<br>
>><br>
>>* Example: If a user makes a change to a secret/container in Barbican<br>
>>then Neutron LBaaS will see an event and take the appropriate action.<br>
>><br>
>>PROS:<br>
>> - Barbican is going to create an eventing system regardless so it will<br>
>>be supported.<br>
>> - Decisions are made on behalf of the user which lessens the amount of<br>
>>calls the user has to make.<br>
>><br>
>>CONS:<br>
>> - An eventing framework can become complex especially since we need to<br>
>>ensure delivery of an event.<br>
>> - Implementing an eventing system will take more time than option #2ŠI<br>
>>think.<br>
>><br>
>>2. Push orchestration decisions to API users. This idea comes with two<br>
>>assumptions. The first assumption is that most providers' customers use<br>
>>the cloud via a GUI, which in turn can handle any orchestration<br>
>>decisions that need to be made. The second assumption is that power API<br>
>>users are savvy and can handle their decisions as well. Using this<br>
>>method requires services, such as LBaaS, to "register" in the form of<br>
>>metadata to a barbican container.<br>
>><br>
>>* Example: If a user makes a change to a secret the GUI can see which<br>
>>services are registered and opt to warn the user of consequences. Power<br>
>>users can look at the registered services and make decisions how they<br>
>>see fit.<br>
>><br>
>>PROS:<br>
>> - Very simple to implement. The only code needed to make this a<br>
>>reality is at the control plane (API) level.<br>
>> - This option is more loosely coupled that option #1.<br>
>><br>
>>CONS:<br>
>> - Potential for services to not register/unregister. What happens in<br>
>>this case?<br>
>> - Pushes complexity of decision making on to GUI engineers and power<br>
>>API users.<br>
>><br>
>><br>
>>I would like to get a consensus on which option to move forward with<br>
>>ASAP since the hackathon is coming up and delivering Barbican to<br>
>>Neutron LBaaS integration is essential to exposing SSL/TLS<br>
>>functionality, which almost everyone has stated is a #1/#2 priority.<br>
>><br>
>>I'll start the decision making process by advocating for option #2. My<br>
>>reason for choosing option #2 has to deal mostly with the simplicity of<br>
>>implementing such a mechanism. Simplicity also means we can implement<br>
>>the necessary code and get it approved much faster which seems to be a<br>
>>concern for everyone. What option does everyone else want to move<br>
>>forward with?<br>
>><br>
>><br>
>><br>
>>Cheers,<br>
>>--Jorge<br>
>><br>
>><br>
>>_______________________________________________<br>
>>OpenStack-dev mailing list<br>
>><a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
>><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>><br>
>>_______________________________________________<br>
>>OpenStack-dev mailing list<br>
>><a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
>><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>><br>
>>_______________________________________________<br>
>>OpenStack-dev mailing list<br>
>><a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
>><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
><br>
>_______________________________________________<br>
>OpenStack-dev mailing list<br>
><a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
>_______________________________________________<br>
>OpenStack-dev mailing list<br>
><a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br></div>