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 
<sbaluk...@bluebox.net<mailto:sbaluk...@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.eichber...@hp.com<mailto:german.eichber...@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:sbaluk...@bluebox.net<mailto:sbaluk...@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.miramon...@rackspace.com<mailto:jorge.miramon...@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 <samu...@radware.com<mailto:samu...@radware.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>>
Date: Thursday, May 1, 2014 12:39 PM
To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org<mailto:openstack-dev@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@lists.openstack.org<mailto:OpenStack-dev@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@lists.openstack.org<mailto:OpenStack-dev@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@lists.openstack.org<mailto:OpenStack-dev@lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Reply via email to