[openstack-dev] [Neutron][LBaaS] Barbican Neutron LBaaS Integration Ideas

Douglas Mendizabal douglas.mendizabal at RACKSPACE.COM
Mon Jun 9 23:24:16 UTC 2014


I understand how this could be helpful, but I still don’t understand why
this is Barbican’s problem to solve.

>From Jorge’s original email:

>> Using this method requires services, such as LBaaS, to "register" in
>>the form of metadata to a barbican container.

If our assumptions are that the GUI can handle information, and that power
users are savvy.  Then how does that require Barbican to store the
metadata?  I would argue that the GUI can store its own metadata, and that
Power Users should be savvy enough to update their LBs (via PUT or
whatever) after uploading a new certificate.


-Doug

On 6/9/14, 6:10 PM, "John Wood" <john.wood at RACKSPACE.COM> wrote:

>The impression I have from this thread is that Containers should remain
>immutable, but it would be helpful to allow services like LBaaS to
>register as interested in a given Container. This could be the full URI
>to the load balancer instance for example. This information would allow
>clients to see what services (and load balancer instances in this
>example) are using a Container, so they can update them if a new
>Container replaces the old one. They could also see what services depend
>on a Container before trying to remove the Container.
>
>A blueprint submission to Barbican tomorrow should provide more details
>on this, and let the Barbican and LBaaS communities weigh in on this
>feature.
>
>Thanks,
>John
>
>
>________________________________________
>From: Tiwari, Arvind [arvind.tiwari at hp.com]
>Sent: Monday, June 09, 2014 2:54 PM
>To: OpenStack Development Mailing List (not for usage questions)
>Subject: Re: [openstack-dev] [Neutron][LBaaS] Barbican Neutron LBaaS
>Integration Ideas
>
>As per current implementation, containers are immutable.
>Do we have any use case to make it mutable? Can we live with new
>container instead of updating an existing container?
>
>Arvind
>
>-----Original Message-----
>From: Samuel Bercovici [mailto:SamuelB at Radware.com]
>Sent: Monday, June 09, 2014 1:31 PM
>To: OpenStack Development Mailing List (not for usage questions)
>Subject: Re: [openstack-dev] [Neutron][LBaaS] Barbican Neutron LBaaS
>Integration Ideas
>
>As far as I understand the Current Barbican implementation is immutable.
>Can anyone from Barbican comment on this?
>
>-----Original Message-----
>From: Jain, Vivek [mailto:VIVEKJAIN at ebay.com]
>Sent: Monday, June 09, 2014 8:34 PM
>To: OpenStack Development Mailing List (not for usage questions)
>Subject: Re: [openstack-dev] [Neutron][LBaaS] Barbican Neutron LBaaS
>Integration Ideas
>
>+1 for the idea of making certificate immutable.
>However, if Barbican allows updating certs/containers then versioning is
>a must.
>
>Thanks,
>Vivek
>
>
>On 6/8/14, 11:48 PM, "Samuel Bercovici" <SamuelB at Radware.com> wrote:
>
>>Hi,
>>
>>I think that option 2 should be preferred at this stage.
>>I also think that certificate should be immutable, if you want a new
>>one, create a new one and update the listener to use it.
>>This removes any chance of mistakes, need for versioning etc.
>>
>>-Sam.
>>
>>-----Original Message-----
>>From: Jorge Miramontes [mailto:jorge.miramontes at RACKSPACE.COM]
>>Sent: Friday, June 06, 2014 10: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 --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5660 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140609/7cdcf3af/attachment.bin>


More information about the OpenStack-dev mailing list