[openstack-dev] [Neutron][LBaaS]User Stories and sruvey

Carlos Garza carlos.garza at rackspace.com
Fri May 2 02:24:11 UTC 2014


     Balukoff I'm liking your API spec so far but can you elaborate on what this loadbalancer object you refer to is. on page You declare its immutable and refer to it like an actual primitive object yet I don't
see a schema for it. I see loadbalancer_id in the vip request that reference. The top part of the doc declares a loadbalancer is is the first object created according to the definition in the glossary.
https://wiki.openstack.org/wiki/Neutron/LBaaS/Glossary#Loadbalancer where it is defined as the root Object that is first created or can be fully populated but in you API proposal it looks like the vip object is the created top level primitive with flavor attribute is apart of a VIP. Are you intending to rename what we call a loadbalancer to a VIP? Could you provide a work flow of a created loadbalancer. It looks good either way.

Is it cool if we rename ca_certificate_id to client_ca or client_ca_certificate to make it clear the purpose of the CA is to snub clients. Later on if we need to do encryption to back end pool members that have x509s signed by their own CA we can then use a parameter like reencryption_ca_certificate.

Consider the following cases.

The user wants SSL_ID based persistence on an HTTPS LoadBalancer where the loadbalancer does not know the key or cert but has access to the unencrypted RFC5246: 7.4.1.2 uncrypted Session ID
to identify persistence to the back end HTTPS pool member?

On the pool side of the loadbalaancer can a loadbalancer still encrypt if no ca_certificate_id or client_certificate_id is present? How would they signal to the api that they extend to encrypt with out host name validation or even vert validation at all. Not sure why they would want to other then they don't feel the need to pay for certs on their backend nodes or worse yes pay for a signing cert.

The user feels secure on their network and wants SSL termination at the loadbalancer so the loadbalancer has the Cert and Key and extends to use plain old HTTP to the pool members with some headers injected. What would the protocol on the listener be "HTTPS" and would placing a CERT and KEY imply deception should happen.

Also I've been burned in an earlier project when I started noticing some CA's were using ECDSA certs instead of RSA? should we take non RSA x509s into account as well? Right now it looks like the API assumes everything is RSA.


By placing
On May 1, 2014, at 5:35 PM, Stephen Balukoff <sbalukoff at bluebox.net<mailto:sbalukoff at bluebox.net>> wrote:

German,

They certainly are essential-- but as far as I can tell, we haven't been concentrating on them, so the list there is likely very incomplete.

Stephen


On Thu, May 1, 2014 at 1:04 PM, Eichberger, German <german.eichberger at hp.com<mailto:german.eichberger at hp.com>> wrote:
Stephen,

I would prefer if we can vote on them, too. They are essential and I would like to make sure they are considered first-class citizen when it comes to use cases.

Thanks,
German

From: Stephen Balukoff [mailto:sbalukoff at bluebox.net<mailto:sbalukoff at bluebox.net>]
Sent: Thursday, May 01, 2014 12:52 PM

To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron][LBaaS]User Stories and sruvey


Yep, I'm all for this as well!

Note: We're just talking about "user" use cases in this survey, correct?  (We'll leave the operator use cases for later when we have more of a story and/or model to work with on how we're going to approach those, yes?)

Thanks,
Stephen

On Thu, May 1, 2014 at 11:54 AM, Jorge Miramontes <jorge.miramontes at rackspace.com<mailto:jorge.miramontes at rackspace.com>> wrote:
That sounds good to me. The only thing I would caution is that we have prioritized certain requirements (like HA and SSL Termination) and I want to ensure we use the survey to compliment what we have already mutually agreed upon. Thanks for spearheading this!

Cheers,
--Jorge

From: Samuel Bercovici <SamuelB at Radware.com<mailto:SamuelB at Radware.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>>
Date: Thursday, May 1, 2014 12:39 PM
To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>>
Subject: [openstack-dev] [Neutron][LBaaS]User Stories and sruvey

Hi Everyone!

To assist in evaluating the use cases that matter and since we now have ~45 use cases, I would like to propose to conduct a survey using something like surveymonkey.
The idea is to have a non-anonymous survey listing the use cases and ask you identify and vote.
Then we will publish the results and can prioritize based on this.

To do so in a timely manner, I would like to freeze the document for editing and allow only comments by Monday May 5th 08:00AMUTC and publish the survey link to ML ASAP after that.

Please let me know if this is acceptable.

Regards,
                -Sam.




_______________________________________________
OpenStack-dev mailing list
OpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



--
Stephen Balukoff
Blue Box Group, LLC
(800)613-4305 x807<tel:%28800%29613-4305%20x807>

_______________________________________________
OpenStack-dev mailing list
OpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




--
Stephen Balukoff
Blue Box Group, LLC
(800)613-4305 x807
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev at lists.openstack.org<mailto: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/20140502/21fc13ba/attachment.html>


More information about the OpenStack-dev mailing list