Re: [openstack-dev] EXT: [octavia] scheduling webex to discuss flavor spec (https://review.openstack.org/#/c/392485/)

[Samuel Bercovici]

Carlos,

We are in Israel and would like the meeting to happen at a more favorable time 
to us, for example 9:00AM CDT.

-Sam.


From: Carlos Puga [mailto:carlos.p...@walmart.com]
Sent: Monday, June 26, 2017 7:04 PM
To: OpenStack Development Mailing List (not for usage questions) 

Subject: [openstack-dev] EXT: [octavia] scheduling webex to discuss flavor spec 
(https://review.openstack.org/#/c/392485/)

Octavia Team,

As per our last octavia meeting, I'm scheduling a webex so that we may speak 
through the teams preference on the design of the flavor spec.  I'd like to 
purpose we meet up on Thursday 3pm CDT.  If this day/time doesn't work for most 
please let me know and I can change it to best accommodate as many as possible.

Thank you,
Carlos Puga



__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron][LBaaS]Removing LBaaS v1 - are weready?

[Samuel Bercovici]

So this looks like only a database migration, right?

-Original Message-
From: Eichberger, German [mailto:german.eichber...@hpe.com] 
Sent: Tuesday, March 08, 2016 12:28 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron][LBaaS]Removing LBaaS v1 - are weready?

Ok, for what it’s worth we have contributed our migration script: 
https://review.openstack.org/#/c/289595/ — please look at this as a starting 
point and feel free to fix potential problems…

Thanks,
German




On 3/7/16, 11:00 AM, "Samuel Bercovici" <samu...@radware.com> wrote:

>As far as I recall, you can specify the VIP in creating the LB so you will end 
>up with same IPs.
>
>-Original Message-
>From: Eichberger, German [mailto:german.eichber...@hpe.com]
>Sent: Monday, March 07, 2016 8:30 PM
>To: OpenStack Development Mailing List (not for usage questions)
>Subject: Re: [openstack-dev] [Neutron][LBaaS]Removing LBaaS v1 - are weready?
>
>Hi Sam,
>
>So if you have some 3rd party hardware you only need to change the 
>database (your steps 1-5) since the 3rd party hardware will just keep 
>load balancing…
>
>Now for Kevin’s case with the namespace driver:
>You would need a 6th step to reschedule the loadbalancers with the V2 
>namespace driver — which can be done.
>
>If we want to migrate to Octavia or (from one LB provider to another) it might 
>be better to use the following steps:
>
>1. Download LBaaS v1 information (Tenants, Flavors, VIPs, Pools, Health 
>Monitors , Members) into some JSON format file(s) 2. Delete LBaaS v1 3. 
>Uninstall LBaaS v1 4. Install LBaaS v2 5. Transform the JSON format 
>file into some scripts which recreate the load balancers with your 
>provider of choice —
>
>6. Run those scripts
>
>The problem I see is that we will probably end up with different VIPs 
>so the end user would need to change their IPs…
>
>Thanks,
>German
>
>
>
>On 3/6/16, 5:35 AM, "Samuel Bercovici" <samu...@radware.com> wrote:
>
>>As for a migration tool.
>>Due to model changes and deployment changes between LBaaS v1 and LBaaS v2, I 
>>am in favor for the following process:
>>
>>1. Download LBaaS v1 information (Tenants, Flavors, VIPs, Pools, 
>>Health Monitors , Members) into some JSON format file(s) 2. Delete LBaaS v1 3.
>>Uninstall LBaaS v1 4. Install LBaaS v2 5. Import the data from 1 back 
>>over LBaaS v2 (need to allow moving from falvor1-->flavor2, need to 
>>make room to some custom modification for mapping between v1 and v2
>>models)
>>
>>What do you think?
>>
>>-Sam.
>>
>>
>>
>>
>>-Original Message-
>>From: Fox, Kevin M [mailto:kevin@pnnl.gov]
>>Sent: Friday, March 04, 2016 2:06 AM
>>To: OpenStack Development Mailing List (not for usage questions)
>>Subject: Re: [openstack-dev] [Neutron][LBaaS]Removing LBaaS v1 - are weready?
>>
>>Ok. Thanks for the info.
>>
>>Kevin
>>
>>From: Brandon Logan [brandon.lo...@rackspace.com]
>>Sent: Thursday, March 03, 2016 2:42 PM
>>To: openstack-dev@lists.openstack.org
>>Subject: Re: [openstack-dev] [Neutron][LBaaS]Removing LBaaS v1 - are weready?
>>
>>Just for clarity, V2 did not reuse tables, all the tables it uses are only 
>>for it.  The main problem is that v1 and v2 both have a pools resource, but 
>>v1 and v2's pool resource have different attributes.  With the way neutron 
>>wsgi works, if both v1 and v2 are enabled, it will combine both sets of 
>>attributes into the same validation schema.
>>
>>The other problem with v1 and v2 running together was only occurring when the 
>>v1 agent driver and v2 agent driver were both in use at the same time.  This 
>>may actually have been fixed with some agent updates in neutron, since that 
>>is common code.  It needs to be tested out though.
>>
>>Thanks,
>>Brandon
>>
>>On Thu, 2016-03-03 at 22:14 +, Fox, Kevin M wrote:
>>> Just because you had thought no one was using it outside of a PoC doesn't 
>>> mean folks aren''t using it in production.
>>>
>>> We would be happy to migrate to Octavia. We were planning on doing just 
>>> that by running both v1 with haproxy namespace, and v2 with Octavia and 
>>> then pick off upgrading lb's one at a time, but the reuse of the v1 tables 
>>> really was an unfortunate decision that blocked that activity.
>>>
>>> We're still trying to figure out a path forward.
>>>
>>> We have an outage window next month. after that, it could be about 6 
>>> months before

Re: [openstack-dev] [Neutron][LBaaS]Removing LBaaS v1 - are weready?

[Samuel Bercovici]

Same with Radware. Hence my proposal.

-Original Message-
From: Vijay Venkatachalam [mailto:vijay.venkatacha...@citrix.com] 
Sent: Tuesday, March 08, 2016 3:42 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron][LBaaS]Removing LBaaS v1 - are weready?

Hi German,

>> So if you have some 3rd party hardware you only need to change the 
>> database (your steps 1-5) since the 3rd party hardware will just keep 
>> load balancing…

This is not the case with NetScaler it has to go through a Delete of V1 
followed by Create in V2 if a smooth migration is required. 

Thanks,
Vijay V.
-Original Message-
From: Eichberger, German [mailto:german.eichber...@hpe.com]
Sent: 08 March 2016 00:00
To: OpenStack Development Mailing List (not for usage questions) 
<openstack-dev@lists.openstack.org>
Subject: Re: [openstack-dev] [Neutron][LBaaS]Removing LBaaS v1 - are weready?

Hi Sam,

So if you have some 3rd party hardware you only need to change the database 
(your steps 1-5) since the 3rd party hardware will just keep load balancing…

Now for Kevin’s case with the namespace driver:
You would need a 6th step to reschedule the loadbalancers with the V2 namespace 
driver — which can be done.

If we want to migrate to Octavia or (from one LB provider to another) it might 
be better to use the following steps:

1. Download LBaaS v1 information (Tenants, Flavors, VIPs, Pools, Health 
Monitors , Members) into some JSON format file(s) 2. Delete LBaaS v1 3. 
Uninstall LBaaS v1 4. Install LBaaS v2 5. Transform the JSON format file into 
some scripts which recreate the load balancers with your provider of choice — 

6. Run those scripts

The problem I see is that we will probably end up with different VIPs so the 
end user would need to change their IPs… 

Thanks,
German



On 3/6/16, 5:35 AM, "Samuel Bercovici" <samu...@radware.com> wrote:

>As for a migration tool.
>Due to model changes and deployment changes between LBaaS v1 and LBaaS v2, I 
>am in favor for the following process:
>
>1. Download LBaaS v1 information (Tenants, Flavors, VIPs, Pools, Health 
>Monitors , Members) into some JSON format file(s) 2. Delete LBaaS v1 3.
>Uninstall LBaaS v1 4. Install LBaaS v2 5. Import the data from 1 back 
>over LBaaS v2 (need to allow moving from falvor1-->flavor2, need to 
>make room to some custom modification for mapping between v1 and v2
>models)
>
>What do you think?
>
>-Sam.
>
>
>
>
>-Original Message-
>From: Fox, Kevin M [mailto:kevin@pnnl.gov]
>Sent: Friday, March 04, 2016 2:06 AM
>To: OpenStack Development Mailing List (not for usage questions)
>Subject: Re: [openstack-dev] [Neutron][LBaaS]Removing LBaaS v1 - are weready?
>
>Ok. Thanks for the info.
>
>Kevin
>
>From: Brandon Logan [brandon.lo...@rackspace.com]
>Sent: Thursday, March 03, 2016 2:42 PM
>To: openstack-dev@lists.openstack.org
>Subject: Re: [openstack-dev] [Neutron][LBaaS]Removing LBaaS v1 - are weready?
>
>Just for clarity, V2 did not reuse tables, all the tables it uses are only for 
>it.  The main problem is that v1 and v2 both have a pools resource, but v1 and 
>v2's pool resource have different attributes.  With the way neutron wsgi 
>works, if both v1 and v2 are enabled, it will combine both sets of attributes 
>into the same validation schema.
>
>The other problem with v1 and v2 running together was only occurring when the 
>v1 agent driver and v2 agent driver were both in use at the same time.  This 
>may actually have been fixed with some agent updates in neutron, since that is 
>common code.  It needs to be tested out though.
>
>Thanks,
>Brandon
>
>On Thu, 2016-03-03 at 22:14 +, Fox, Kevin M wrote:
>> Just because you had thought no one was using it outside of a PoC doesn't 
>> mean folks aren''t using it in production.
>>
>> We would be happy to migrate to Octavia. We were planning on doing just that 
>> by running both v1 with haproxy namespace, and v2 with Octavia and then pick 
>> off upgrading lb's one at a time, but the reuse of the v1 tables really was 
>> an unfortunate decision that blocked that activity.
>>
>> We're still trying to figure out a path forward.
>>
>> We have an outage window next month. after that, it could be about 6 
>> months before we could try a migration due to production load picking 
>> up for a while. I may just have to burn out all the lb's switch to 
>> v2, then rebuild them by hand in a marathon outage :/
>>
>> And then there's this thingy that also critically needs fixing:
>> https://bugs.launchpad.net/neutron/+bug/1457556
>>
>> Thanks,
>> Kevin
>> ___

Re: [openstack-dev] [Neutron][LBaaS]Removing LBaaS v1 - are weready?

[Samuel Bercovici]

As far as I recall, you can specify the VIP in creating the LB so you will end 
up with same IPs.

-Original Message-
From: Eichberger, German [mailto:german.eichber...@hpe.com] 
Sent: Monday, March 07, 2016 8:30 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron][LBaaS]Removing LBaaS v1 - are weready?

Hi Sam,

So if you have some 3rd party hardware you only need to change the database 
(your steps 1-5) since the 3rd party hardware will just keep load balancing…

Now for Kevin’s case with the namespace driver:
You would need a 6th step to reschedule the loadbalancers with the V2 namespace 
driver — which can be done.

If we want to migrate to Octavia or (from one LB provider to another) it might 
be better to use the following steps:

1. Download LBaaS v1 information (Tenants, Flavors, VIPs, Pools, Health 
Monitors , Members) into some JSON format file(s) 2. Delete LBaaS v1 3. 
Uninstall LBaaS v1 4. Install LBaaS v2 5. Transform the JSON format file into 
some scripts which recreate the load balancers with your provider of choice — 

6. Run those scripts

The problem I see is that we will probably end up with different VIPs so the 
end user would need to change their IPs… 

Thanks,
German



On 3/6/16, 5:35 AM, "Samuel Bercovici" <samu...@radware.com> wrote:

>As for a migration tool.
>Due to model changes and deployment changes between LBaaS v1 and LBaaS v2, I 
>am in favor for the following process:
>
>1. Download LBaaS v1 information (Tenants, Flavors, VIPs, Pools, Health 
>Monitors , Members) into some JSON format file(s) 2. Delete LBaaS v1 3. 
>Uninstall LBaaS v1 4. Install LBaaS v2 5. Import the data from 1 back 
>over LBaaS v2 (need to allow moving from falvor1-->flavor2, need to 
>make room to some custom modification for mapping between v1 and v2 
>models)
>
>What do you think?
>
>-Sam.
>
>
>
>
>-Original Message-
>From: Fox, Kevin M [mailto:kevin@pnnl.gov]
>Sent: Friday, March 04, 2016 2:06 AM
>To: OpenStack Development Mailing List (not for usage questions)
>Subject: Re: [openstack-dev] [Neutron][LBaaS]Removing LBaaS v1 - are weready?
>
>Ok. Thanks for the info.
>
>Kevin
>
>From: Brandon Logan [brandon.lo...@rackspace.com]
>Sent: Thursday, March 03, 2016 2:42 PM
>To: openstack-dev@lists.openstack.org
>Subject: Re: [openstack-dev] [Neutron][LBaaS]Removing LBaaS v1 - are weready?
>
>Just for clarity, V2 did not reuse tables, all the tables it uses are only for 
>it.  The main problem is that v1 and v2 both have a pools resource, but v1 and 
>v2's pool resource have different attributes.  With the way neutron wsgi 
>works, if both v1 and v2 are enabled, it will combine both sets of attributes 
>into the same validation schema.
>
>The other problem with v1 and v2 running together was only occurring when the 
>v1 agent driver and v2 agent driver were both in use at the same time.  This 
>may actually have been fixed with some agent updates in neutron, since that is 
>common code.  It needs to be tested out though.
>
>Thanks,
>Brandon
>
>On Thu, 2016-03-03 at 22:14 +, Fox, Kevin M wrote:
>> Just because you had thought no one was using it outside of a PoC doesn't 
>> mean folks aren''t using it in production.
>>
>> We would be happy to migrate to Octavia. We were planning on doing just that 
>> by running both v1 with haproxy namespace, and v2 with Octavia and then pick 
>> off upgrading lb's one at a time, but the reuse of the v1 tables really was 
>> an unfortunate decision that blocked that activity.
>>
>> We're still trying to figure out a path forward.
>>
>> We have an outage window next month. after that, it could be about 6 
>> months before we could try a migration due to production load picking 
>> up for a while. I may just have to burn out all the lb's switch to 
>> v2, then rebuild them by hand in a marathon outage :/
>>
>> And then there's this thingy that also critically needs fixing:
>> https://bugs.launchpad.net/neutron/+bug/1457556
>>
>> Thanks,
>> Kevin
>> 
>> From: Eichberger, German [german.eichber...@hpe.com]
>> Sent: Thursday, March 03, 2016 12:47 PM
>> To: OpenStack Development Mailing List (not for usage questions)
>> Subject: Re: [openstack-dev] [Neutron][LBaaS]Removing LBaaS v1 - are weready?
>>
>> Kevin,
>>
>>  If we are offering a migration tool it would be namespace -> 
>> namespace (or maybe Octavia since [1]) - given the limitations nobody 
>> should be using the namespace driver outside a PoC so I am a bit 
>> confused why customers can't self migrate. With 3

Re: [openstack-dev] [Neutron][LBaaS]Removing LBaaS v1 - are weready?

[Samuel Bercovici]

As for a migration tool.
Due to model changes and deployment changes between LBaaS v1 and LBaaS v2, I am 
in favor for the following process:

1. Download LBaaS v1 information (Tenants, Flavors, VIPs, Pools, Health 
Monitors , Members) into some JSON format file(s)
2. Delete LBaaS v1 
3. Uninstall LBaaS v1
4. Install LBaaS v2
5. Import the data from 1 back over LBaaS v2 (need to allow moving from 
falvor1-->flavor2, need to make room to some custom modification for mapping 
between v1 and v2 models)

What do you think?

-Sam.




-Original Message-
From: Fox, Kevin M [mailto:kevin@pnnl.gov] 
Sent: Friday, March 04, 2016 2:06 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron][LBaaS]Removing LBaaS v1 - are weready?

Ok. Thanks for the info.

Kevin

From: Brandon Logan [brandon.lo...@rackspace.com]
Sent: Thursday, March 03, 2016 2:42 PM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [Neutron][LBaaS]Removing LBaaS v1 - are weready?

Just for clarity, V2 did not reuse tables, all the tables it uses are only for 
it.  The main problem is that v1 and v2 both have a pools resource, but v1 and 
v2's pool resource have different attributes.  With the way neutron wsgi works, 
if both v1 and v2 are enabled, it will combine both sets of attributes into the 
same validation schema.

The other problem with v1 and v2 running together was only occurring when the 
v1 agent driver and v2 agent driver were both in use at the same time.  This 
may actually have been fixed with some agent updates in neutron, since that is 
common code.  It needs to be tested out though.

Thanks,
Brandon

On Thu, 2016-03-03 at 22:14 +, Fox, Kevin M wrote:
> Just because you had thought no one was using it outside of a PoC doesn't 
> mean folks aren''t using it in production.
>
> We would be happy to migrate to Octavia. We were planning on doing just that 
> by running both v1 with haproxy namespace, and v2 with Octavia and then pick 
> off upgrading lb's one at a time, but the reuse of the v1 tables really was 
> an unfortunate decision that blocked that activity.
>
> We're still trying to figure out a path forward.
>
> We have an outage window next month. after that, it could be about 6 
> months before we could try a migration due to production load picking 
> up for a while. I may just have to burn out all the lb's switch to v2, 
> then rebuild them by hand in a marathon outage :/
>
> And then there's this thingy that also critically needs fixing:
> https://bugs.launchpad.net/neutron/+bug/1457556
>
> Thanks,
> Kevin
> 
> From: Eichberger, German [german.eichber...@hpe.com]
> Sent: Thursday, March 03, 2016 12:47 PM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [Neutron][LBaaS]Removing LBaaS v1 - are weready?
>
> Kevin,
>
>  If we are offering a migration tool it would be namespace -> 
> namespace (or maybe Octavia since [1]) - given the limitations nobody 
> should be using the namespace driver outside a PoC so I am a bit 
> confused why customers can't self migrate. With 3rd party Lbs I would 
> assume vendors proving those scripts to make sure their particular 
> hardware works with those. If you indeed need a migration from LBaaS 
> V1 namespace -> LBaaS V2 namespace/Octavia please file an RfE with 
> your use case so we can discuss it further...
>
> Thanks,
> German
>
> [1] https://review.openstack.org/#/c/286380
>
> From: "Fox, Kevin M" <kevin@pnnl.gov<mailto:kevin@pnnl.gov>>
> Reply-To: "OpenStack Development Mailing List (not for usage 
> questions)" 
> <openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstac
> k.org>>
> Date: Wednesday, March 2, 2016 at 5:17 PM
> To: "OpenStack Development Mailing List (not for usage questions)" 
> <openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstac
> k.org>>
> Subject: Re: [openstack-dev] [Neutron][LBaaS]Removing LBaaS v1 - are weready?
>
> no removal without an upgrade path. I've got v1 LB's and there still isn't a 
> migration script to go from v1 to v2.
>
> Thanks,
> Kevin
>
>
> 
> From: Stephen Balukoff 
> [sbaluk...@bluebox.net<mailto:sbaluk...@bluebox.net>]
> Sent: Wednesday, March 02, 2016 4:49 PM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [Neutron][LBaaS]Removing LBaaS v1 - are weready?
>
> I am also on-board with removing LBaaS v1 as early as possible in the Newton 
> cycle.
>
> On Wed, Mar 2, 2016 at 9:44 AM, Samuel Bercovici 
> <samu...@radware.com

Re: [openstack-dev] [Neutron][LBaaS]Removing LBaaS v1 - are weready?

[Samuel Bercovici]

Thank you all for your response.

In my opinion given that UI/HEAT will make Mitaka and will have one cycle to 
mature, it makes sense to remove LBaaS v1 in Newton.
Do we want do discuss an upgrade process in the summit?

-Sam.


From: Bryan Jones [mailto:jone...@us.ibm.com]
Sent: Wednesday, March 02, 2016 5:54 PM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [Neutron][LBaaS]Removing LBaaS v1 - are weready?

And as for the Heat support, the resources have made Mitaka, with additional 
functional tests on the way soon.

blueprint: https://blueprints.launchpad.net/heat/+spec/lbaasv2-suport
gerrit topic: https://review.openstack.org/#/q/topic:bp/lbaasv2-suport
BRYAN M. JONES
Software Engineer - OpenStack Development
Phone: 1-507-253-2620
E-mail: jone...@us.ibm.com<mailto:jone...@us.ibm.com>


- Original message -
From: Justin Pomeroy 
<jpom...@linux.vnet.ibm.com<mailto:jpom...@linux.vnet.ibm.com>>
To: openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>
Cc:
Subject: Re: [openstack-dev] [Neutron][LBaaS]Removing LBaaS v1 - are we ready?
Date: Wed, Mar 2, 2016 9:36 AM

As for the horizon support, much of it will make Mitaka.  See the blueprint and 
gerrit topic:

https://blueprints.launchpad.net/horizon/+spec/horizon-lbaas-v2-ui
https://review.openstack.org/#/q/topic:bp/horizon-lbaas-v2-ui,n,z

- Justin

On 3/2/16 9:22 AM, Doug Wiegley wrote:
Hi,

A few things:

- It’s not proposed for removal in Mitaka. That patch is for Newton.
- HEAT and Horizon are planned for Mitaka (see neutron-lbaas-dashboard for the 
latter.)
- I don’t view this as a “keep or delete” question. If sufficient folks are 
interested in maintaining it, there is a third option, which is that the code 
can be maintained in a separate repo, by a separate team (with or without the 
current core team’s blessing.)

No decisions have been made yet, but we are on the cusp of some major 
maintenance changes, and two deprecation cycles have passed. Which path forward 
is being discussed at today’s Octavia meeting, or feedback is of course 
welcomed here, in IRC, or anywhere.

Thanks,
doug

On Mar 2, 2016, at 7:06 AM, Samuel Bercovici 
<samu...@radware.com<mailto:samu...@radware.com>> wrote:

Hi,

I have just notices the following change: 
https://review.openstack.org/#/c/286381 which aims to remove LBaaS v1.
Is this planned for Mitaka or for Newton?

While LBaaS v2 is becoming the default, I think that we should have the 
following before we replace LBaaS v1:
1.  Horizon Support – was not able to find any real activity on it
2.  HEAT Support – will it be ready in Mitaka?

Do you have any other items that are needed before we get rid of LBaaS v1?

-Sam.







__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org<mailto:openstack-dev-requ...@lists.openstack.org>?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe<mailto:openstack-dev-requ...@lists.openstack.org?subject:unsubscribe>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe<mailto:openstack-dev-requ...@lists.openstack.org?subject:unsubscribe>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Neutron][LBaaS]Removing LBaaS v1 - are we ready?

[Samuel Bercovici]

Hi,

I have just notices the following change: 
https://review.openstack.org/#/c/286381 which aims to remove LBaaS v1.
Is this planned for Mitaka or for Newton?

While LBaaS v2 is becoming the default, I think that we should have the 
following before we replace LBaaS v1:

1.  Horizon Support - was not able to find any real activity on it

2.  HEAT Support - will it be ready in Mitaka?

Do you have any other items that are needed before we get rid of LBaaS v1?

-Sam.







__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Octavia (LBaaS) license question

[Samuel Bercovici]

OpenStack is using KVM and Linux as reference implementation, both are GPL.

From: Gal Sagie [mailto:gal.sa...@gmail.com]
Sent: Sunday, February 14, 2016 8:47 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] Octavia (LBaaS) license question

Hello All,

I recently started looking at Octavia and i noticed it uses HAProxy as its 
reference
implementation.
I also noticed that HAProxy is GPL license so i am wondering how is this 
working?

Just interested to know if there is a special exemption ?

Thanks
Gal.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron][LBaaS][Octavia] Should subnet be optional on member create?

[Samuel Bercovici]

t; ambiguity issues due to overlapping subnets and multiple
> > routes.
> > > > In the case of an IP being outside of the tenant networks,
> > the user
> > > > would specify an external network that has the appropriate
> > routes.  We
> > > > cannot always assume which tenant network with an external
> > (or VPN)
> > > > route is the appropriate one to use.
> > > >
> > > > Michael
> > > >
> > > > On Mon, Jan 18, 2016 at 2:45 PM, Stephen Balukoff
> > <sbaluk...@bluebox.net> wrote:
> > > >> Vivek--
> > > >>
> > > >> "Member" in this case refers to an IP address that
> > (probably) lives on a
> > > >> tenant back-end network. We can't specify just the IP
> > address when talking
> > > >> to such an IP since tenant subnets may use overlapping IP
> > ranges (ie. in
> > > >> this case, subnet is required). In the case of the
> > namespace driver and
> > > >> Octavia, we use the subnet parameter for all members to
> > determine which
> > > >> back-end networks the load balancing software needs a
> > port on.
> > > >>
> > > >> I think the original use case for making subnet optional
> > was the idea that
> >     > >> sometimes a tenant would like to add a "member" IP that
> > is not part of their
> > > >> tenant networks at all--  this is more than likely an IP
> > address that lives
> > > >> outside the local cloud. The assumption, then, would be
> > that this IP address
> > > >> should be reachable through standard routing from
> > wherever the load balancer
> > > >> happens to live on the network. That is to say, the load
> > balancer will try
> > > >> to get to such an IP address via its default gateway,
> > unless it has a more
> > > >> specific route.
> > > >>
> > > >> As far as I'm aware, this use case is still valid and
> > being asked for by
> > > >> tenants. Therefore, I'm in favor of making member subnet
> > optional.
> > > >>
> > > >> Stephen
> > > >>
> > > >> On Mon, Jan 18, 2016 at 11:14 AM, Jain, Vivek
> > <vivekj...@ebay.com> wrote:
> > > >>>
> > > >>> If member port (IP address) is allocated by neutron,
> > then why do we need
> > > >>> to specify it explicitly? It can be derived by LBaaS
> > driver implicitly.
> > > >>>
> > > >>> Thanks,
> > > >>> Vivek
> > > >>>
> > > >>>
> > > >>>
> > > >>>
> > > >>>
> > > >>>
> > > >>> On 1/17/16, 1:05 AM, "Samuel Bercovici"
> > <samu...@radware.com> wrote:
> > > >>>
> > > >>>> Btw.
> > > >>>>
> > > >>>> I am still in favor on associating the subnets to the
> > LB and then not
> > > >>>> specify them per node at all.
> > > >>>>
> > > >>>> -Sam.
> > > >>>>
> > > >>>>
> > > >>>> -Original Message-
> > > >>>> From: Samuel Bercovici [mailto:samu...@radware.com]
> > > >>>> Sent: Sunday, January 17, 2016 10:14 AM
> > > >>>> To: OpenStack Development Mailing List (not for usage
> > questions)
> > > >>>> Subject: Re: [openstack-dev] [Neutron][LBaaS][Octavia]
> > Should subnet be
> > > >>>> optional on member create?
> > > >>>>
> > > >>>> +1
> > > >>>> Subnet should be mandatory
> >   

Re: [openstack-dev] [Neutron][LBaaS][Octavia] Should subnet be optional on member create?

[Samuel Bercovici]

Btw.

I am still in favor on associating the subnets to the LB and then not specify 
them per node at all.

-Sam.


-Original Message-
From: Samuel Bercovici [mailto:samu...@radware.com] 
Sent: Sunday, January 17, 2016 10:14 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron][LBaaS][Octavia] Should subnet be 
optional on member create?

+1
Subnet should be mandatory

The only thing this makes supporting load balancing servers which are not 
running in the cloud more challenging to support.
But I do not see this as a huge user story (lb in cloud load balancing IPs 
outside the cloud)

-Sam.

-Original Message-
From: Brandon Logan [mailto:brandon.lo...@rackspace.com] 
Sent: Saturday, January 16, 2016 6:56 AM
To: openstack-dev@lists.openstack.org
Subject: [openstack-dev] [Neutron][LBaaS][Octavia] Should subnet be optional on 
member create?

I filed a bug [1] a while ago that subnet_id should be an optional parameter 
for member creation.  Currently it is required.  Review [2] is makes it 
optional.

The original thinking was that if the load balancer is ever connected to that 
same subnet, be it by another member on that subnet or the vip on that subnet, 
then the user does not need to specify the subnet for new member if that new 
member is on one of those subnets.

At the midcycle we discussed it and we had an informal agreement that it 
required too many assumptions on the part of the end user, neutron lbaas, and 
driver.

If anyone wants to voice their opinion on this matter, do so on the bug report, 
review, or in response to this thread.  Otherwise, it'll probably be abandoned 
and not done at some point.

Thanks,
Brandon

[1] https://bugs.launchpad.net/neutron/+bug/1426248
[2] https://review.openstack.org/#/c/267935/
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron][LBaaS][Octavia] Should subnet be optional on member create?

[Samuel Bercovici]

+1
Subnet should be mandatory

The only thing this makes supporting load balancing servers which are not 
running in the cloud more challenging to support.
But I do not see this as a huge user story (lb in cloud load balancing IPs 
outside the cloud)

-Sam.

-Original Message-
From: Brandon Logan [mailto:brandon.lo...@rackspace.com] 
Sent: Saturday, January 16, 2016 6:56 AM
To: openstack-dev@lists.openstack.org
Subject: [openstack-dev] [Neutron][LBaaS][Octavia] Should subnet be optional on 
member create?

I filed a bug [1] a while ago that subnet_id should be an optional parameter 
for member creation.  Currently it is required.  Review [2] is makes it 
optional.

The original thinking was that if the load balancer is ever connected to that 
same subnet, be it by another member on that subnet or the vip on that subnet, 
then the user does not need to specify the subnet for new member if that new 
member is on one of those subnets.

At the midcycle we discussed it and we had an informal agreement that it 
required too many assumptions on the part of the end user, neutron lbaas, and 
driver.

If anyone wants to voice their opinion on this matter, do so on the bug report, 
review, or in response to this thread.  Otherwise, it'll probably be abandoned 
and not done at some point.

Thanks,
Brandon

[1] https://bugs.launchpad.net/neutron/+bug/1426248
[2] https://review.openstack.org/#/c/267935/
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron][heat] LBaaS of Neutron

[Samuel Bercovici]

Another option is to implement health monitor that will fail on P nodes and 
will succeed on A nodes.

From: Sergey Kraynev [mailto:skray...@mirantis.com]
Sent: Monday, November 16, 2015 9:15 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [neutron][heat] LBaaS of Neutron

On 16 November 2015 at 09:46, Qiao,Liyong 
> wrote:
hi, I have some questions about neutorn LBaas.

seen from the wiki, the load balancer only support:



Table 4.6. Load Balancing Algorithms
Name

LEAST_CONNECTIONS

ROUND_ROBIN


https://wiki.openstack.org/wiki/Neutron/LBaaS/API

think about if I have a A-P mode HA

VIP : 192.168.0.10

master-1 192.168.0.100 (A)
master-2 192.168.0.101 (P)

if I want to use VIP to alway connect with master-1(since it is A mode),
only switch to master-2 when master-1 down. what should I do?
any plan to support more algorithms for neutron lbaas?

BTW, the usage is from heat:

  etcd_pool:
type: OS::Neutron::Pool
properties:
  protocol: HTTP
  monitors: [{get_resource: etcd_monitor}]
  subnet: {get_resource: fixed_subnet}
  lb_method: ROUND_ROBIN
  vip:
protocol_port: 2379



thanks,
Eli.


--

BR, Eli(Li Yong)Qiao

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Hi, Qiao,Liyong

I can not say about LBaaS team plans for supporting some additional algorithms 
:)
AFAIK, they do not plan add it to v1 API.
As I understand it may be discussed as part of v2 API [1]

In the Heat we have related BP [2], with several patches on review. So if it 
will be implemented on Neutron side, we may add such functionality too.

[1] http://developer.openstack.org/api-ref-networking-v2-ext.html#lbaas-v2.0
[2] https://blueprints.launchpad.net/heat/+spec/lbaasv2-suport

--
Regards,
Sergey.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron][lbaas] Proposing Michael Johnson for neutron-lbaas core team

[Samuel Bercovici]

And then they were 6 =D>


-Sam.

-Original Message-
From: Doug Wiegley [mailto:doug...@parksidesoftware.com] 
Sent: Thursday, September 17, 2015 1:34 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [neutron][lbaas] Proposing Michael Johnson for 
neutron-lbaas core team

Hi all,

As the Lieutenant of the advanced services, I nominate Michael Johnson to be a 
member of the neutron-lbaas core reviewer team.

Review stats are in line with other cores[2], and Michael has been instrumental 
in both neutron-lbaas and octavia.

Existing cores, please vote +1/-1 for his addition to the team (that’s Brandon, 
Phil, Al, and Kyle.)

Thanks,
doug

1. 
http://docs.openstack.org/developer/neutron/policies/core-reviewers.html#core-review-hierarchy
2. http://stackalytics.com/report/contribution/neutron-lbaas/90


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron][lbaas] L7 - Tasks

[Samuel Bercovici]

Hi,

I think that Evgeny is trying to complete everything bedsides the reference 
implementation (API, CLI, Tempest, etc.).
Evgeny will join the Octavia IRC meeting so it could be a good opportunity to 
get status and sync activities.
As far as I know 8/31 is feature freeze and not code complete. Please correct 
me, if I am wrong.

-Sam.



-Original Message-
From: Eichberger, German [mailto:german.eichber...@hp.com] 
Sent: Wednesday, August 26, 2015 2:46 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [neutron][lbaas] L7 - Tasks

Hi Evgeny,

Of course we would love to have L7 in Liberty but that window is closing on 
8/31. We usually monitor the progress (via Stephen) at the weekly Octavia 
meeting. Stephen indicated that we won't get it before the L3 deadline and with 
all the open items it might still be tight. I am wondering if you can advise on 
that.

Thanks,
German

From: Evgeny Fedoruk evge...@radware.commailto:evge...@radware.com
Reply-To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Date: Tuesday, August 25, 2015 at 9:33 AM
To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Subject: [openstack-dev] [neutron][lbaas] L7 - Tasks

Hello

I would like to know if there is a plan for L7 extension work for Liberty There 
is an extension patch-set here https://review.openstack.org/#/c/148232/
We will also need to do a CLI work which I started to do and will commit 
initial patch-set soon Reference implementation was started by Stephen here 
https://review.openstack.org/#/c/204957/
and tempest tests update should be done as well I do not know if it was 
discussed at IRC meetings.
Please share your thought about it.


Regards,
Evg


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron][lbaas] Horizon support for neutron-lbaas v2

[Samuel Bercovici]

Hi,
How do I sign  in to this?
I am asked for credentials.
-Sam.


From: Jain, Vivek [mailto:vivekj...@ebay.com]
Sent: Wednesday, July 29, 2015 5:54 AM
To: OpenStack Development Mailing List (not for usage questions)
Cc: Tonse, Milan
Subject: Re: [openstack-dev] [neutron][lbaas] Horizon support for neutron-lbaas 
v2

Initial code for horizon lbaas v2 dashboard submitted:

https://review.openstack.org/#/c/206797

Thanks,
vivek

From: Jain, Vivek vivekj...@ebay.commailto:vivekj...@ebay.com
Reply-To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Date: Tuesday, July 28, 2015 at 6:19 PM
To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Cc: Tonse, Milan mto...@ebay.commailto:mto...@ebay.com
Subject: Re: [openstack-dev] [neutron][lbaas] Horizon support for neutron-lbaas 
v2

Hi Folks,

Screenshots are uploaded. Please review and leave your feedback:

https://openstack.invisionapp.com/d/main#/projects/4237816

Thanks,
vivek

From: Jain, Vivek vivekj...@ebay.commailto:vivekj...@ebay.com
Reply-To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Date: Tuesday, July 28, 2015 at 4:14 PM
To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Cc: Tonse, Milan mto...@ebay.commailto:mto...@ebay.com
Subject: Re: [openstack-dev] [neutron][lbaas] Horizon support for neutron-lbaas 
v2

Thanks Doug. We are planning to submit initial review version by end of day 
today.

Also, we will be uploading LBaaS wireframes for review here:
https://openstack.invisionapp.com/d/main#/projects/4237816

Thanks,
Vivek


From: Doug Wiegley 
doug...@parksidesoftware.commailto:doug...@parksidesoftware.com
Reply-To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Date: Tuesday, July 28, 2015 at 4:04 PM
To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Cc: Tonse, Milan mto...@ebay.commailto:mto...@ebay.com
Subject: Re: [openstack-dev] [neutron][lbaas] Horizon support for neutron-lbaas 
v2

The repo is now live.  Initial review is here: 
https://review.openstack.org/#/c/206757 , please make any near-term reviews 
dependent on that, unless you’re replacing the skeleton. Vivek, when do you 
think we can get some initial code in there to start iterating on?

Thanks,
doug


On Jul 16, 2015, at 6:27 AM, Jain, Vivek 
vivekj...@ebay.commailto:vivekj...@ebay.com wrote:

A quick reminder that we will be meeting today at 16:00UTC (9:00 am PDT) in 
#openstack-lbaas to discuss Horizon LBaaS v2 UI.

Thanks,
Vivek

From: Balle, Susanne susanne.ba...@hp.commailto:susanne.ba...@hp.com
Reply-To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Date: Wednesday, July 15, 2015 at 10:35 AM
To: Eichberger, German 
german.eichber...@hp.commailto:german.eichber...@hp.com, OpenStack 
Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Cc: Tonse, Milan mto...@ebay.commailto:mto...@ebay.com
Subject: Re: [openstack-dev] [neutron][lbaas] Horizon support for neutron-lbaas 
v2

I agree with German. Let’s keep things together for now. Susanne

From: Eichberger, German
Sent: Wednesday, July 15, 2015 1:31 PM
To: OpenStack Development Mailing List (not for usage questions)
Cc: Balle, Susanne; Tonse, Milan
Subject: Re: [openstack-dev] [neutron][lbaas] Horizon support for neutron-lbaas 
v2

Hi,

Let’s move it into the LBaaS repo that seems like the right place for me —

Thanks,
German

From: Jain, Vivek vivekj...@ebay.commailto:vivekj...@ebay.com
Reply-To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Date: Tuesday, July 14, 2015 at 10:22 AM
To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Cc: Balle Balle, Susanne susanne.ba...@hp.commailto:susanne.ba...@hp.com, 
Tonse, Milan mto...@ebay.commailto:mto...@ebay.com
Subject: Re: [openstack-dev] [neutron][lbaas] Horizon support for neutron-lbaas 
v2

Thanks Akihiro. Currently lbaas panels are part of horizon repo. If there is a 
easy way to de-couple lbaas dashboard from horizon? I think that will simplify 
development efforts. What does it take to separate lbaas dashboard from horizon?

Thanks,
Vivek

From: Akihiro Motoki amot...@gmail.commailto:amot...@gmail.com
Reply-To: OpenStack Development Mailing List (not for usage questions) 

Re: [openstack-dev] [designate] and [lbaas] - GSLB API and backend support

[Samuel Bercovici]

Hi Kunal,

Did you also include use cases per our last discussion on IRC?
I prefer to start with use cases before we dive into APIs.

Thanks,
-Sam.


-Original Message-
From: Gandhi, Kunal [mailto:kunalhgan...@gmail.com] 
Sent: Wednesday, June 24, 2015 6:47 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [designate] and [lbaas] - GSLB API and backend 
support

Hi All,

I have a very draft for the GSLB API and would like to upload it somewhere for 
discussion. What is the best place to upload and collaborate the draft ? Since 
the API docs have a lot of JSON payloads in it, I am not sure whether Google 
Docs will be appropriate for that.

Regards
Kunal

 On Jun 15, 2015, at 10:03 PM, Doug Wiegley doug...@parksidesoftware.com 
 wrote:
 
 Hi all,
 
 We don’t have a rough draft API doc yet, so I’m suggesting that we postpone 
 tomorrow morning’s meeting until next week. Does anyone have any other agenda 
 items, or want the meeting tomorrow?
 
 Thanks,
 doug
 
 
 On Jun 2, 2015, at 10:52 AM, Doug Wiegley doug...@parksidesoftware.com 
 wrote:
 
 Hi all,
 
 The initial meeting logs can be found at 
 http://eavesdrop.openstack.org/meetings/gslb/2015/ , and we will be having 
 another meeting next week, same time, same channel.
 
 Thanks,
 doug
 
 
 On May 31, 2015, at 1:27 AM, Samuel Bercovici samu...@radware.com wrote:
 
 Good for me - Tuesday at 1600UTC
 
 
 -Original Message-
 From: Doug Wiegley [mailto:doug...@parksidesoftware.com]
 Sent: Thursday, May 28, 2015 10:37 PM
 To: OpenStack Development Mailing List (not for usage questions)
 Subject: Re: [openstack-dev] [designate] and [lbaas] - GSLB API and 
 backend support
 
 
 On May 28, 2015, at 12:47 PM, Hayes, Graham graham.ha...@hp.com wrote:
 
 On 28/05/15 19:38, Adam Harwell wrote:
 I haven't seen any responses from my team yet, but I know we'd be 
 interested as well - we have done quite a bit of work on this in 
 the past, including dealing with the Designate team on this very subject.
 We can be available most hours between 9am-6pm Monday-Friday CST.
 
 --Adam
 
 https://keybase.io/rm_you
 
 
 From: Rakesh Saha rsahaos...@gmail.com 
 mailto:rsahaos...@gmail.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 28, 2015 at 12:22 PM
 To: OpenStack Development Mailing List (not for usage questions)
 openstack-dev@lists.openstack.org
 mailto:openstack-dev@lists.openstack.org
 Subject: Re: [openstack-dev] [designate] and [lbaas] - GSLB API 
 and backend support
 
 Hi Kunal,
 I would like to participate as well.
 Mon-Fri morning US Pacific time works for me.
 
 Thanks,
 Rakesh Saha
 
 On Tue, May 26, 2015 at 8:45 PM, Vijay Venkatachalam 
 vijay.venkatacha...@citrix.com 
 mailto:vijay.venkatacha...@citrix.com wrote:
 
 We would like to participate as well.
 
 __ __
 
 Monday-Friday Morning US time works for me..
 
 __ __
 
 Thanks,
 
 Vijay V.
 
 __ __
 
 *From:*Samuel Bercovici [mailto:samu...@radware.com
 mailto:samu...@radware.com]
 *Sent:* 26 May 2015 21:39
 
 
 *To:* OpenStack Development Mailing List (not for usage questions)
 *Cc:* kunalhgan...@gmail.com mailto:kunalhgan...@gmail.com;
 v.jain...@gmail.com mailto:v.jain...@gmail.com;
 do...@a10networks.com mailto:do...@a10networks.com
 *Subject:* Re: [openstack-dev] [designate] and [lbaas] - GSLB
 API and backend support
 
 __ __
 
 Hi,
 
 __ __
 
 I would also like to participate.
 
 Friday is a non-working day in Israel (same as Saturday for most
 of you).
 
 So Monday- Thursday works best for me.
 
 __ __
 
 -Sam.
 
 __ __
 
 __ __
 
 *From:*Doug Wiegley [mailto:doug...@parksidesoftware.com]
 *Sent:* Saturday, May 23, 2015 8:45 AM
 *To:* OpenStack Development Mailing List (not for usage questions)
 *Cc:* kunalhgan...@gmail.com mailto:kunalhgan...@gmail.com;
 v.jain...@gmail.com mailto:v.jain...@gmail.com;
 do...@a10networks.com mailto:do...@a10networks.com
 *Subject:* Re: [openstack-dev] [designate] and [lbaas] - GSLB
 API and backend support
 
 __ __
 
 Of those two options, Friday would work better for me.
 
 __ __
 
 Thanks,
 
 doug
 
 __ __
 
 On May 22, 2015, at 9:33 PM, ki...@macinnes.ie
 mailto:ki...@macinnes.ie wrote:
 
 __ __
 
 Hi Kunal,
 
 Thursday/Friday works for me - early morning PT works best,
 as I'm based in Ireland.
 
 I'll find some specific times the Designate folks are
 available over the next day or two and provide some
 options.. 
 
 Thanks,
 Kiall
 
 On 22 May 2015 7:24 pm, Gandhi, Kunal
 kunalhgan...@gmail.com mailto:kunalhgan...@gmail.com

Re: [openstack-dev] [designate] and [lbaas] - GSLB API and backend support

[Samuel Bercovici]

Great!
Thanks you. I have missed this one.

From: Gandhi, Kunal [mailto:kunalhgan...@gmail.com]
Sent: Wednesday, June 24, 2015 12:21 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [designate] and [lbaas] - GSLB API and backend 
support

Hi Sam

Yes. we discussed the use cases 2 weeks ago on irc. The IRC logs can be found 
here 
http://eavesdrop.openstack.org/meetings/gslb/2015/gslb.2015-06-09-16.00.log.html
and the use case document can be found here 
https://docs.google.com/document/d/1016shVnPaK8l8HxMpjADiYtY2O94p4g7JxjuIA-qv7w/edit?usp=sharing

Regards
Kunal


On Jun 24, 2015, at 12:35 AM, Samuel Bercovici 
samu...@radware.commailto:samu...@radware.com wrote:

Hi Kunal,

Did you also include use cases per our last discussion on IRC?
I prefer to start with use cases before we dive into APIs.

Thanks,
-Sam.


-Original Message-
From: Gandhi, Kunal [mailto:kunalhgan...@gmail.com]
Sent: Wednesday, June 24, 2015 6:47 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [designate] and [lbaas] - GSLB API and backend 
support

Hi All,

I have a very draft for the GSLB API and would like to upload it somewhere for 
discussion. What is the best place to upload and collaborate the draft ? Since 
the API docs have a lot of JSON payloads in it, I am not sure whether Google 
Docs will be appropriate for that.

Regards
Kunal


On Jun 15, 2015, at 10:03 PM, Doug Wiegley 
doug...@parksidesoftware.commailto:doug...@parksidesoftware.com wrote:

Hi all,

We don’t have a rough draft API doc yet, so I’m suggesting that we postpone 
tomorrow morning’s meeting until next week. Does anyone have any other agenda 
items, or want the meeting tomorrow?

Thanks,
doug



On Jun 2, 2015, at 10:52 AM, Doug Wiegley 
doug...@parksidesoftware.commailto:doug...@parksidesoftware.com wrote:

Hi all,

The initial meeting logs can be found at 
http://eavesdrop.openstack.org/meetings/gslb/2015/ , and we will be having 
another meeting next week, same time, same channel.

Thanks,
doug



On May 31, 2015, at 1:27 AM, Samuel Bercovici 
samu...@radware.commailto:samu...@radware.com wrote:

Good for me - Tuesday at 1600UTC


-Original Message-
From: Doug Wiegley [mailto:doug...@parksidesoftware.com]
Sent: Thursday, May 28, 2015 10:37 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [designate] and [lbaas] - GSLB API and
backend support



On May 28, 2015, at 12:47 PM, Hayes, Graham 
graham.ha...@hp.commailto:graham.ha...@hp.com wrote:

On 28/05/15 19:38, Adam Harwell wrote:

I haven't seen any responses from my team yet, but I know we'd be
interested as well - we have done quite a bit of work on this in
the past, including dealing with the Designate team on this very subject.
We can be available most hours between 9am-6pm Monday-Friday CST.

--Adam

https://keybase.io/rm_you


From: Rakesh Saha rsahaos...@gmail.com
mailto:rsahaos...@gmail.commailto:rsahaos...@gmail.com%20%0b%3cmailto:rsahaos...@gmail.com
Reply-To: OpenStack Development Mailing List (not for usage questions)
openstack-dev@lists.openstack.org
mailto:openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org%0b%3cmailto:openstack-dev@lists.openstack.org
Date: Thursday, May 28, 2015 at 12:22 PM
To: OpenStack Development Mailing List (not for usage questions)
openstack-dev@lists.openstack.org
mailto:openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org%0b%3cmailto:openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [designate] and [lbaas] - GSLB API
and backend support

Hi Kunal,
I would like to participate as well.
Mon-Fri morning US Pacific time works for me.

Thanks,
Rakesh Saha

On Tue, May 26, 2015 at 8:45 PM, Vijay Venkatachalam
vijay.venkatacha...@citrix.com
mailto:vijay.venkatacha...@citrix.commailto:vijay.venkatacha...@citrix.com%20%0b%3cmailto:vijay.venkatacha...@citrix.com
 wrote:

   We would like to participate as well.

   __ __

   Monday-Friday Morning US time works for me..

   __ __

   Thanks,

   Vijay V.

   __ __

   *From:*Samuel Bercovici [mailto:samu...@radware.com
   mailto:samu...@radware.commailto:samu...@radware.com%0b   
%3cmailto:samu...@radware.com%3e]
   *Sent:* 26 May 2015 21:39


   *To:* OpenStack Development Mailing List (not for usage questions)
   *Cc:* kunalhgan...@gmail.commailto:kunalhgan...@gmail.com 
mailto:kunalhgan...@gmail.com;
   v.jain...@gmail.commailto:v.jain...@gmail.com mailto:v.jain...@gmail.com;
   do...@a10networks.commailto:do...@a10networks.com 
mailto:do...@a10networks.com
   *Subject:* Re: [openstack-dev] [designate] and [lbaas] - GSLB
   API and backend support

   __ __

   Hi,

   __ __

   I would also like to participate.

   Friday is a non-working day in Israel (same as Saturday for most
   of you).

   So Monday- Thursday works best for me.

   __ __

   -Sam

Re: [openstack-dev] [designate] and [lbaas] - GSLB API and backend support

[Samuel Bercovici]

Good for me - Tuesday at 1600UTC


-Original Message-
From: Doug Wiegley [mailto:doug...@parksidesoftware.com] 
Sent: Thursday, May 28, 2015 10:37 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [designate] and [lbaas] - GSLB API and backend 
support


 On May 28, 2015, at 12:47 PM, Hayes, Graham graham.ha...@hp.com wrote:
 
 On 28/05/15 19:38, Adam Harwell wrote:
 I haven't seen any responses from my team yet, but I know we'd be 
 interested as well - we have done quite a bit of work on this in the 
 past, including dealing with the Designate team on this very subject. 
 We can be available most hours between 9am-6pm Monday-Friday CST.
 
 --Adam
 
 https://keybase.io/rm_you
 
 
 From: Rakesh Saha rsahaos...@gmail.com 
 mailto:rsahaos...@gmail.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 28, 2015 at 12:22 PM
 To: OpenStack Development Mailing List (not for usage questions)
 openstack-dev@lists.openstack.org
 mailto:openstack-dev@lists.openstack.org
 Subject: Re: [openstack-dev] [designate] and [lbaas] - GSLB API and 
 backend support
 
Hi Kunal,
I would like to participate as well.
Mon-Fri morning US Pacific time works for me.
 
Thanks,
Rakesh Saha
 
On Tue, May 26, 2015 at 8:45 PM, Vijay Venkatachalam
vijay.venkatacha...@citrix.com
mailto:vijay.venkatacha...@citrix.com wrote:
 
We would like to participate as well.
 
__ __
 
Monday-Friday Morning US time works for me..
 
__ __
 
Thanks,
 
Vijay V.
 
__ __
 
*From:*Samuel Bercovici [mailto:samu...@radware.com
mailto:samu...@radware.com]
*Sent:* 26 May 2015 21:39
 
 
*To:* OpenStack Development Mailing List (not for usage questions)
*Cc:* kunalhgan...@gmail.com mailto:kunalhgan...@gmail.com;
v.jain...@gmail.com mailto:v.jain...@gmail.com;
do...@a10networks.com mailto:do...@a10networks.com
*Subject:* Re: [openstack-dev] [designate] and [lbaas] - GSLB
API and backend support
 
__ __
 
Hi,
 
__ __
 
I would also like to participate.
 
Friday is a non-working day in Israel (same as Saturday for most
of you).
 
So Monday- Thursday works best for me.
 
__ __
 
-Sam.
 
__ __
 
__ __
 
*From:*Doug Wiegley [mailto:doug...@parksidesoftware.com]
*Sent:* Saturday, May 23, 2015 8:45 AM
*To:* OpenStack Development Mailing List (not for usage questions)
*Cc:* kunalhgan...@gmail.com mailto:kunalhgan...@gmail.com;
v.jain...@gmail.com mailto:v.jain...@gmail.com;
do...@a10networks.com mailto:do...@a10networks.com
*Subject:* Re: [openstack-dev] [designate] and [lbaas] - GSLB
API and backend support
 
__ __
 
Of those two options, Friday would work better for me.
 
__ __
 
Thanks,
 
doug
 
__ __
 
On May 22, 2015, at 9:33 PM, ki...@macinnes.ie
mailto:ki...@macinnes.ie wrote:
 
__ __
 
Hi Kunal,
 
Thursday/Friday works for me - early morning PT works best,
as I'm based in Ireland.
 
I'll find some specific times the Designate folks are
available over the next day or two and provide some
options.. 
 
Thanks,
Kiall
 
On 22 May 2015 7:24 pm, Gandhi, Kunal
kunalhgan...@gmail.com mailto:kunalhgan...@gmail.com
wrote:
 
Hi All
 
__ __
 
I wanted to start a discussion about adding support for GSLB
to neutron-lbaas and designate. To be brief for folks who
are new to GLB, GLB stands for Global Load Balancing and we
use it for load balancing traffic across various
geographical regions. A more detail description of GLB can
be found at my talk at the summit this week here
https://www.youtube.com/watch?v=fNR0SW3vj_s.
 
__ __
 
To my understanding, there are two sides to a GSLB - DNS
side and LB side. 
 
__ __
 
DNS side
 
 Most of the GSLB's provided by various vendors
are DNS servers and are authoritative for the GLB domains.
The global fqdn's that belong the GLB domains resolve to
multiple public VIP's across various regions based on
various configurations on the global fqdn on the GLB.
 
__ __
 
LBaaS side
 
 A few of the common functionalities provided by
a standard GSLB provides are health

Re: [openstack-dev] [designate] and [lbaas] - GSLB API and backend support

[Samuel Bercovici]

Hi,

I would also like to participate.
Friday is a non-working day in Israel (same as Saturday for most of you).
So Monday- Thursday works best for me.

-Sam.


From: Doug Wiegley [mailto:doug...@parksidesoftware.com]
Sent: Saturday, May 23, 2015 8:45 AM
To: OpenStack Development Mailing List (not for usage questions)
Cc: kunalhgan...@gmail.com; v.jain...@gmail.com; do...@a10networks.com
Subject: Re: [openstack-dev] [designate] and [lbaas] - GSLB API and backend 
support

Of those two options, Friday would work better for me.

Thanks,
doug

On May 22, 2015, at 9:33 PM, ki...@macinnes.iemailto:ki...@macinnes.ie wrote:

Hi Kunal,
Thursday/Friday works for me - early morning PT works best, as I'm based in 
Ireland.
I'll find some specific times the Designate folks are available over the next 
day or two and provide some options..
Thanks,
Kiall
On 22 May 2015 7:24 pm, Gandhi, Kunal 
kunalhgan...@gmail.commailto:kunalhgan...@gmail.com wrote:
Hi All

I wanted to start a discussion about adding support for GSLB to neutron-lbaas 
and designate. To be brief for folks who are new to GLB, GLB stands for Global 
Load Balancing and we use it for load balancing traffic across various 
geographical regions. A more detail description of GLB can be found at my talk 
at the summit this week herehttps://www.youtube.com/watch?v=fNR0SW3vj_s.

To my understanding, there are two sides to a GSLB - DNS side and LB side.

DNS side
Most of the GSLB’s provided by various vendors are DNS servers and 
are authoritative for the GLB domains. The global fqdn’s that belong the GLB 
domains resolve to multiple public VIP’s across various regions based on 
various configurations on the global fqdn on the GLB.

LBaaS side
A few of the common functionalities provided by a standard GSLB 
provides are health monitoring on the public VIP’s and the local LB’s on which 
these public VIP’s sit on. Some additional features that a GSLB can provide are 
configuring admin status and weights on your public VIP’s. Based on these 
configurations and settings, the GLB returns the appropriate number of public 
VIP’s to any DNS resolve queries for the global fqdn’s.

I would like to have the designate and lbaas to start a discussion on GSLB and 
discuss the following topics:


  *   What parts of GSLB belongs to Designate and LBaaS ?
  *   Once we have an understanding of the above, my team at eBay/PayPal would 
like work with the community on submitting a blueprint for this.


To kick start this conversation, I would like to schedule an irc meeting 
regarding this with folks from designate and neutron-lbaas. Please let me know 
a time and day that works for you guys. I am available on Thursday and Friday 
next week.


Regards
Kunal


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.orgmailto:openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [lbaas] [octavia] [barbican] Relationship between Octavia and Barbican and Octavia 1.0 questions

[Samuel Bercovici]

We are considering adding network classes “rules” to LBaaS.
In this case, such network classes could als be used to white/black list 
traffic.

From: Brandon Logan [mailto:brandon.lo...@rackspace.com]
Sent: Friday, May 22, 2015 12:46 AM
To: openstack-dev@lists.openstack.org; maishsk+openst...@maishsk.com
Subject: Re: [openstack-dev] [lbaas] [octavia] [barbican] Relationship between 
Octavia and Barbican and Octavia 1.0 questions


​Right now its all or nothing as far as tcp ports go.  It currently does not 
have the functionality of white/black listinging traffic originating from a 
specific network.


From: Maish Saidel-Keesing mais...@maishsk.commailto:mais...@maishsk.com
Sent: Thursday, May 21, 2015 7:45 AM
To: openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [lbaas] [octavia] [barbican] Relationship between 
Octavia and Barbican and Octavia 1.0 questions

Thanks Brandon
On 05/20/15 22:58, Brandon Logan wrote:

​Just to add a few things,

Barbican is not yet implemented in Octavia, though the code is there, we just 
need to spend a few hours hooking it all up and testing it out.



Also, the security groups are used by octavia right now so that only the ports 
on the listener are accessible.  Basically if a loadbalancer has listeners on 
ports 80 and 443, the vip ports will only allow traffic on those ports.  It 
shouldn't allow other traffic.
That is great to hear. I assume that if we are using security groups we will 
also be able to define rules regarding which networks the listeners are allowed 
to accept traffic from?

Is that assumption correct?




Thanks,

Brandon


From: Doug Wiegley 
doug...@parksidesoftware.commailto:doug...@parksidesoftware.com
Sent: Thursday, May 21, 2015 12:49 AM
To: maishsk+openst...@maishsk.commailto:maishsk+openst...@maishsk.com; 
OpenStack Development Mailing List (not for usage questions); Maish 
Saidel-Keesing
Subject: Re: [openstack-dev] [lbaas] [octavia] [barbican] Relationship between 
Octavia and Barbican and Octavia 1.0 questions

Hi Maish,

Thanks for the feedback, some answers below.  Please also be aware of the lbaas 
use cases session tomorrow at 9am (yuck, I know), 
https://etherpad.openstack.org/p/YVR-neutron-lbaas-use-cases


On May 19, 2015, at 12:05 AM, Maish Saidel-Keesing 
mais...@maishsk.commailto:mais...@maishsk.com wrote:

Hello all,

Going over today's presentation Load Balancing as a Service, Kilo and 
Beyond[1] (great presentation!!) - there are a few questions I have regarding 
the future release:

For Octavia 1.0:

1. Can someone explain to me how the flow would work for spinning up a a new 
Amphora with regards to interaction between Neutron, LBaaS and Barbican?
Same question as well regarding how the standby is created and its relationship 
with Barbican.

The lbaas API runs inside neutron-server.  The general flow is:

- User interacts with neutron CLI/API or horizon (in liberty), and creates an 
LB.
- Lbaas plugin in neutron creates logical models, fetches cert data from 
barbican, and calls the backend lbaas driver.
- The backend driver does what it needs to to instantiate the LB. Today this is 
a synchronous call that waits for the nova boot, but by Liberty, it will likely 
be an async call to the octavia controller to finish the job.

Once Octavia has control, it is doing:

- Get REST calls for objects,
- Talk to nova, spin up an amphora image,
- Talk to neutron, plumb in the networks,
- Send the amphora its config.



2. Will the orchestration (Heat) also be implemented when Octavia 1.0 is 
released or only further down the line?
If not what would you suggest be the way to orchestrate LBaaS until this is 
ready?

We need to talk to the Heat folks and coordinate this, which we are planning to 
do soon.



3. Is there some kind of hook into Security groups also planned for the Amphora 
to also protect the Load Balancer?

Not at present, but I recorded this in the feature list on the etherpad above.



I think that based on the answers to these questions above - additional 
questions will follow.

Thanks

[1] https://www.youtube.com/watch?v=-eAKur8lErU
--
Best Regards,
Maish Saidel-Keesing
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.orgmailto:openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


--
Best Regards,
Maish Saidel-Keesing
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [lbaas] [octavia] [barbican] Relationship between Octavia and Barbican and Octavia 1.0 questions

[Samuel Bercovici]

Hi Dani,

Can you please explain further the 3rd use case (Multiple FIPs….)?

Regards,
-Sam.

From: Daniel Comnea [mailto:comnea.d...@gmail.com]
Sent: Friday, May 22, 2015 10:09 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [lbaas] [octavia] [barbican] Relationship between 
Octavia and Barbican and Octavia 1.0 questions

My $0.2 cents:

I echo what Maish said with regards to functionality:
- integration with HEAT is a must from Day -1 (if there is anything like this 
:) ) otherwise will be hard to gain operators traction. Look it as the entry 
point for everyone trying to move from Neutron LB
- white/ black listing traffic based on source port/ network/IP
- multiple FIPs associated with 1 LB, the use case is: say i have 1 LB open for 
port tcp 80  udp 88 listening on 2 FIPs (even registered into a DNS) and 2 
different set of clients consuming this interfaces - frontend and backend
Dani

Dani

On Thu, May 21, 2015 at 10:45 PM, Brandon Logan 
brandon.lo...@rackspace.commailto:brandon.lo...@rackspace.com wrote:

​Right now its all or nothing as far as tcp ports go.  It currently does not 
have the functionality of white/black listinging traffic originating from a 
specific network.


From: Maish Saidel-Keesing mais...@maishsk.commailto:mais...@maishsk.com
Sent: Thursday, May 21, 2015 7:45 AM
To: openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org

Subject: Re: [openstack-dev] [lbaas] [octavia] [barbican] Relationship between 
Octavia and Barbican and Octavia 1.0 questions

Thanks Brandon
On 05/20/15 22:58, Brandon Logan wrote:

​Just to add a few things,

Barbican is not yet implemented in Octavia, though the code is there, we just 
need to spend a few hours hooking it all up and testing it out.



Also, the security groups are used by octavia right now so that only the ports 
on the listener are accessible.  Basically if a loadbalancer has listeners on 
ports 80 and 443, the vip ports will only allow traffic on those ports.  It 
shouldn't allow other traffic.
That is great to hear. I assume that if we are using security groups we will 
also be able to define rules regarding which networks the listeners are allowed 
to accept traffic from?

Is that assumption correct?




Thanks,

Brandon


From: Doug Wiegley 
doug...@parksidesoftware.commailto:doug...@parksidesoftware.com
Sent: Thursday, May 21, 2015 12:49 AM
To: maishsk+openst...@maishsk.commailto:maishsk+openst...@maishsk.com; 
OpenStack Development Mailing List (not for usage questions); Maish 
Saidel-Keesing
Subject: Re: [openstack-dev] [lbaas] [octavia] [barbican] Relationship between 
Octavia and Barbican and Octavia 1.0 questions

Hi Maish,

Thanks for the feedback, some answers below.  Please also be aware of the lbaas 
use cases session tomorrow at 9am (yuck, I know), 
https://etherpad.openstack.org/p/YVR-neutron-lbaas-use-cases


On May 19, 2015, at 12:05 AM, Maish Saidel-Keesing 
mais...@maishsk.commailto:mais...@maishsk.com wrote:

Hello all,

Going over today's presentation Load Balancing as a Service, Kilo and 
Beyond[1] (great presentation!!) - there are a few questions I have regarding 
the future release:

For Octavia 1.0:

1. Can someone explain to me how the flow would work for spinning up a a new 
Amphora with regards to interaction between Neutron, LBaaS and Barbican?
Same question as well regarding how the standby is created and its relationship 
with Barbican.

The lbaas API runs inside neutron-server.  The general flow is:

- User interacts with neutron CLI/API or horizon (in liberty), and creates an 
LB.
- Lbaas plugin in neutron creates logical models, fetches cert data from 
barbican, and calls the backend lbaas driver.
- The backend driver does what it needs to to instantiate the LB. Today this is 
a synchronous call that waits for the nova boot, but by Liberty, it will likely 
be an async call to the octavia controller to finish the job.

Once Octavia has control, it is doing:

- Get REST calls for objects,
- Talk to nova, spin up an amphora image,
- Talk to neutron, plumb in the networks,
- Send the amphora its config.



2. Will the orchestration (Heat) also be implemented when Octavia 1.0 is 
released or only further down the line?
If not what would you suggest be the way to orchestrate LBaaS until this is 
ready?

We need to talk to the Heat folks and coordinate this, which we are planning to 
do soon.



3. Is there some kind of hook into Security groups also planned for the Amphora 
to also protect the Load Balancer?

Not at present, but I recorded this in the feature list on the etherpad above.



I think that based on the answers to these questions above - additional 
questions will follow.

Thanks

[1] https://www.youtube.com/watch?v=-eAKur8lErU
--
Best Regards,
Maish Saidel-Keesing
__
OpenStack 

Re: [openstack-dev] [neutron][lbaas]LBaaSv2 movies / links

[Samuel Bercovici]

Was thinking 1-2 minutes. Tomorrow would be fine.

From: Vijay Venkatachalam [mailto:vijay.venkatacha...@citrix.com]
Sent: Friday, May 15, 2015 6:03 PM
To: OpenStack Development Mailing List (not for usage questions); Evgeny 
Fedoruk; Adam Harwell; Kyle Mestery; Brandon Logan; Johnson, Michael (HP Cloud 
- Corvallis); Doug Wiegley; Samuel Bercovici
Subject: Re: [openstack-dev] [neutron][lbaas]LBaaSv2 movies / links

Hi Sam,
Thanks for probing. How many seconds/mins you have thought per vendor? By when 
do you need this? Will tomorrow work fine?


Thanks,
Vijay V.

Sent from Surface

From: Samuel Bercovicimailto:samu...@radware.com
Sent: ‎Friday‎, ‎15‎ ‎May‎ ‎2015 ‎00‎:‎30
To: OpenStack Development Mailing List (not for usage 
questions)mailto:openstack-dev@lists.openstack.org, Evgeny 
Fedorukmailto:evge...@radware.com, Adam 
Harwellmailto:adam.harw...@rackspace.com, Kyle 
Mesterymailto:mest...@mestery.com, Brandon 
Loganmailto:brandon.lo...@rackspace.com, Johnson, Michael (HP Cloud - 
Corvallis)mailto:michael.d.john...@hp.com, Doug 
Wiegleymailto:do...@a10networks.com, Samuel 
Bercovicimailto:samu...@radware.com

Hi Everyone,

As you may be aware, we have a speaking slot on the Vancouver summit to discuss 
“LBaaS v2, Kilo and beyond” on Monday 
https://openstacksummitmay2015vancouver.sched.org/event/3f1e9e24f36238152749afea9c21a264#.VVTwCPmqqko

We are considering to show vendors demos or list/link such movies.
Please let us know if you have such so we can list/include in the talk.

Regards,
-Sam.

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron][lbaas]LBaaSv2 movies / links

[Samuel Bercovici]

Here is an example: https://filepile.radware.com/files/5ba-e02-c39


From: Samuel Bercovici [mailto:samu...@radware.com]
Sent: Friday, May 15, 2015 7:06 PM
To: Vijay Venkatachalam; OpenStack Development Mailing List (not for usage 
questions); Evgeny Fedoruk; Adam Harwell; Kyle Mestery; Brandon Logan; Johnson, 
Michael (HP Cloud - Corvallis); Doug Wiegley
Subject: Re: [openstack-dev] [neutron][lbaas]LBaaSv2 movies / links

Was thinking 1-2 minutes. Tomorrow would be fine.

From: Vijay Venkatachalam [mailto:vijay.venkatacha...@citrix.com]
Sent: Friday, May 15, 2015 6:03 PM
To: OpenStack Development Mailing List (not for usage questions); Evgeny 
Fedoruk; Adam Harwell; Kyle Mestery; Brandon Logan; Johnson, Michael (HP Cloud 
- Corvallis); Doug Wiegley; Samuel Bercovici
Subject: Re: [openstack-dev] [neutron][lbaas]LBaaSv2 movies / links

Hi Sam,
Thanks for probing. How many seconds/mins you have thought per vendor? By when 
do you need this? Will tomorrow work fine?


Thanks,
Vijay V.

Sent from Surface

From: Samuel Bercovicimailto:samu...@radware.com
Sent: ‎Friday‎, ‎15‎ ‎May‎ ‎2015 ‎00‎:‎30
To: OpenStack Development Mailing List (not for usage 
questions)mailto:openstack-dev@lists.openstack.org, Evgeny 
Fedorukmailto:evge...@radware.com, Adam 
Harwellmailto:adam.harw...@rackspace.com, Kyle 
Mesterymailto:mest...@mestery.com, Brandon 
Loganmailto:brandon.lo...@rackspace.com, Johnson, Michael (HP Cloud - 
Corvallis)mailto:michael.d.john...@hp.com, Doug 
Wiegleymailto:do...@a10networks.com, Samuel 
Bercovicimailto:samu...@radware.com

Hi Everyone,

As you may be aware, we have a speaking slot on the Vancouver summit to discuss 
“LBaaS v2, Kilo and beyond” on Monday 
https://openstacksummitmay2015vancouver.sched.org/event/3f1e9e24f36238152749afea9c21a264#.VVTwCPmqqko

We are considering to show vendors demos or list/link such movies.
Please let us know if you have such so we can list/include in the talk.

Regards,
-Sam.

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron][lbaas]LBaaSv2 movies / links

[Samuel Bercovici]

Bad link. Here is the correct one: 
https://filepile.radware.com/files/2cd-953-809


From: Samuel Bercovici [mailto:samu...@radware.com]
Sent: Friday, May 15, 2015 7:48 PM
To: OpenStack Development Mailing List (not for usage questions); Vijay 
Venkatachalam; Evgeny Fedoruk; Adam Harwell; Kyle Mestery; Brandon Logan; 
Johnson, Michael (HP Cloud - Corvallis); Doug Wiegley
Subject: Re: [openstack-dev] [neutron][lbaas]LBaaSv2 movies / links

Here is an example: https://filepile.radware.com/files/5ba-e02-c39


From: Samuel Bercovici [mailto:samu...@radware.com]
Sent: Friday, May 15, 2015 7:06 PM
To: Vijay Venkatachalam; OpenStack Development Mailing List (not for usage 
questions); Evgeny Fedoruk; Adam Harwell; Kyle Mestery; Brandon Logan; Johnson, 
Michael (HP Cloud - Corvallis); Doug Wiegley
Subject: Re: [openstack-dev] [neutron][lbaas]LBaaSv2 movies / links

Was thinking 1-2 minutes. Tomorrow would be fine.

From: Vijay Venkatachalam [mailto:vijay.venkatacha...@citrix.com]
Sent: Friday, May 15, 2015 6:03 PM
To: OpenStack Development Mailing List (not for usage questions); Evgeny 
Fedoruk; Adam Harwell; Kyle Mestery; Brandon Logan; Johnson, Michael (HP Cloud 
- Corvallis); Doug Wiegley; Samuel Bercovici
Subject: Re: [openstack-dev] [neutron][lbaas]LBaaSv2 movies / links

Hi Sam,
Thanks for probing. How many seconds/mins you have thought per vendor? By when 
do you need this? Will tomorrow work fine?


Thanks,
Vijay V.

Sent from Surface

From: Samuel Bercovicimailto:samu...@radware.com
Sent: ‎Friday‎, ‎15‎ ‎May‎ ‎2015 ‎00‎:‎30
To: OpenStack Development Mailing List (not for usage 
questions)mailto:openstack-dev@lists.openstack.org, Evgeny 
Fedorukmailto:evge...@radware.com, Adam 
Harwellmailto:adam.harw...@rackspace.com, Kyle 
Mesterymailto:mest...@mestery.com, Brandon 
Loganmailto:brandon.lo...@rackspace.com, Johnson, Michael (HP Cloud - 
Corvallis)mailto:michael.d.john...@hp.com, Doug 
Wiegleymailto:do...@a10networks.com, Samuel 
Bercovicimailto:samu...@radware.com

Hi Everyone,

As you may be aware, we have a speaking slot on the Vancouver summit to discuss 
“LBaaS v2, Kilo and beyond” on Monday 
https://openstacksummitmay2015vancouver.sched.org/event/3f1e9e24f36238152749afea9c21a264#.VVTwCPmqqko

We are considering to show vendors demos or list/link such movies.
Please let us know if you have such so we can list/include in the talk.

Regards,
-Sam.

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [neutron][lbaas]LBaaSv2 movies / links

[Samuel Bercovici]

Hi Everyone,

As you may be aware, we have a speaking slot on the Vancouver summit to discuss 
LBaaS v2, Kilo and beyond on Monday 
https://openstacksummitmay2015vancouver.sched.org/event/3f1e9e24f36238152749afea9c21a264#.VVTwCPmqqko

We are considering to show vendors demos or list/link such movies.
Please let us know if you have such so we can list/include in the talk.

Regards,
-Sam.

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron][lbaas] adding lbaas core

[Samuel Bercovici]

Congratulations Phil!
Thank you for your work so far.

-Sam.

-Original Message-
From: Doug Wiegley [mailto:doug...@parksidesoftware.com] 
Sent: Tuesday, April 21, 2015 7:55 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [neutron][lbaas] adding lbaas core

It’s been a week, welcome Phil.

Thanks,
doug


 On Apr 13, 2015, at 2:39 PM, Doug Wiegley doug...@parksidesoftware.com 
 wrote:
 
 Hi all,
 
 I'd like to nominate Philip Toohill as a neutron-lbaas core. Good guy, did a 
 bunch of work on the ref impl for lbaasv2, and and I'll let the numbers[1] 
 speak for themselves.
 
 Existing lbaas cores, please vote.  All three of us.  :-)
 
 [1] http://stackalytics.com/report/contribution/neutron-lbaas/30
 
 Thanks,
 doug
 
 


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [neutron][lbaas]Topics and possible fomats for LBaaS in OpenStack/Vancouver

[Samuel Bercovici]

Hi Everyone,

Based on the last IRC, I thought we could start a discussion on ML on topics 
and then maybe on how we want to discuss durin the summit.
Follows some items we may wish to discuss:

1.   LBaaS API additions (assuming TLS and L7 will be there):

a.   L3 based traffic routing - LB, listener, pool selection based on 
source IP network classes

b.  TLS phase 2:

   i.  Client 
side re-encryption

 ii.  Client 
certificates

c.   Service Insertion models (in addition to proxy based)

   i.  
Transparent mode

d.  Object sharing (yes/no)

   i.  Pools

e.  Monitoring APIs

   i.  
Integration with Ceilometer

f.Batch updates - create a full configuration graph and control when it 
get scheduled

2.   Quota support (ex: max number of LBs, listeners, TLS certificates, 
etc.)

3.   HEAT integration

4.   Horizon Support

5.   LBaaS API extensions - ability to add experimental and vendor APIs

Regards,
-Sam.


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron][lbaas] Object statuses

[Samuel Bercovici]

+1
I also prefer option 2 in general with slight inclination to 2-B

-Original Message-
From: Brandon Logan [mailto:brandon.lo...@rackspace.com] 
Sent: Friday, January 23, 2015 9:21 AM
To: openstack-dev@lists.openstack.org
Subject: [openstack-dev] [neutron][lbaas] Object statuses


So I am resurrecting this topic now because we put this discussion on a a brief 
hold, but are now discussing it again and need to decide asap. We've all agreed 
we need a provisioning_status and operating_status fields. We now need to 
decide where to show these statuses to the user.

Option 1:
Show the statuses directly on the entity.

Option 2-A:
Show a status tree only on the load balancer object, but not on any entities.

Option 2-B:
Expose a resource for a GET request that will return that status tree.

Example:
GET /lbaas/loadbalancers/{LB_UUID}/statuses


Option 1 is probably what most people are used to but it doesn't allow for 
sharing of objects, and when/if sharing is enabled, it will cause a break in 
contract and a new version of the API.  So it would essentially disallow object 
sharing.  This requires a lot less work to implement.

Option 2-* can be done with or without sharing, and when/if object sharing is 
enabled it wont break contract.  This will require more work to implement.

My personal opinion is in favor of Option 2-B, but wouldn't argue with 2-A 
either.

Thanks,
Brandon


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron][lbaas] Shared Objects in LBaaS - Use Cases that led us to adopt this.

[Samuel Bercovici]

Hi,

I agree that the most important thing is to conclude how status properties are 
being managed and handled so it will remain consistent as we move along.
I am fine with starting with a simple model and expending as need to be.
The L7 implementation is ready waiting for the rest of the model to get in so 
pool sharing under a listener is something that we should solve now.
I think that pool sharing under listeners connected to the same LB is more 
common that what you describe.

-Sam.


From: Stephen Balukoff [mailto:sbaluk...@bluebox.net]
Sent: Tuesday, December 09, 2014 12:23 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [neutron][lbaas] Shared Objects in LBaaS - Use 
Cases that led us to adopt this.

So...  I should probably note that I see the case where a user actually shares 
object as being the exception. I expect that 90% of deployments will never need 
to share objects, except for a few cases--  those cases (of 1:N) relationships 
are:

* Loadbalancers must be able to have many Listeners
* When L7 functionality is introduced, L7 policies must be able to refer to the 
same Pool under a single Listener. (That is to say, sharing Pools under the 
scope of a single Listener makes sense, but only after L7 policies are 
introduced.)

I specifically see the following kind of sharing having near zero demand:

* Listeners shared across multiple loadbalancers
* Pools shared across multiple listeners
* Members shared across multiple pools

So, despite the fact that sharing doesn't make status reporting any more or 
less complex, I'm still in favor of starting with 1:1 relationships between 
most kinds of objects and then changing those to 1:N or M:N as we get user 
demand for this. As I said in my first response, allowing too many many to many 
relationships feels like a solution to a problem that doesn't really exist, and 
introduces a lot of unnecessary complexity.

Stephen

On Sun, Dec 7, 2014 at 11:43 PM, Samuel Bercovici 
samu...@radware.commailto:samu...@radware.com wrote:
+1


From: Stephen Balukoff 
[mailto:sbaluk...@bluebox.netmailto:sbaluk...@bluebox.net]
Sent: Friday, December 05, 2014 7:59 PM

To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [neutron][lbaas] Shared Objects in LBaaS - Use 
Cases that led us to adopt this.

German-- but the point is that sharing apparently has no effect on the number 
of permutations for status information. The only difference here is that 
without sharing it's more work for the user to maintain and modify trees of 
objects.

On Fri, Dec 5, 2014 at 9:36 AM, Eichberger, German 
german.eichber...@hp.commailto:german.eichber...@hp.com wrote:
Hi Brandon + Stephen,

Having all those permutations (and potentially testing them) made us lean 
against the sharing case in the first place. It’s just a lot of extra work for 
only a small number of our customers.

German

From: Stephen Balukoff 
[mailto:sbaluk...@bluebox.netmailto:sbaluk...@bluebox.net]
Sent: Thursday, December 04, 2014 9:17 PM

To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [neutron][lbaas] Shared Objects in LBaaS - Use 
Cases that led us to adopt this.

Hi Brandon,

Yeah, in your example, member1 could potentially have 8 different statuses (and 
this is a small example!)...  If that member starts flapping, it means that 
every time it flaps there are 8 notifications being passed upstream.

Note that this problem actually doesn't get any better if we're not sharing 
objects but are just duplicating them (ie. not sharing objects but the user 
makes references to the same back-end machine as 8 different members.)

To be honest, I don't see sharing entities at many levels like this being the 
rule for most of our installations-- maybe a few percentage points of 
installations will do an excessive sharing of members, but I doubt it. So 
really, even though reporting status like this is likely to generate a pretty 
big tree of data, I don't think this is actually a problem, eh. And I don't see 
sharing entities actually reducing the workload of what needs to happen behind 
the scenes. (It just allows us to conceal more of this work from the user.)

Stephen



On Thu, Dec 4, 2014 at 4:05 PM, Brandon Logan 
brandon.lo...@rackspace.commailto:brandon.lo...@rackspace.com wrote:
Sorry it's taken me a while to respond to this.

So I wasn't thinking about this correctly.  I was afraid you would have
to pass in a full tree of parent child representations to /loadbalancers
to update anything a load balancer it is associated to (including down
to members).  However, after thinking about it, a user would just make
an association call on each object.  For Example, associate member1 with
pool1, associate pool1 with listener1, then associate loadbalancer1 with
listener1.  Updating is just as simple as updating each entity.

This does bring up another problem though.  If a listener can

Re: [openstack-dev] [neutron][lbaas] Shared Objects in LBaaS - Use Cases that led us to adopt this.

[Samuel Bercovici]

+1


From: Stephen Balukoff [mailto:sbaluk...@bluebox.net]
Sent: Friday, December 05, 2014 7:59 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [neutron][lbaas] Shared Objects in LBaaS - Use 
Cases that led us to adopt this.

German-- but the point is that sharing apparently has no effect on the number 
of permutations for status information. The only difference here is that 
without sharing it's more work for the user to maintain and modify trees of 
objects.

On Fri, Dec 5, 2014 at 9:36 AM, Eichberger, German 
german.eichber...@hp.commailto:german.eichber...@hp.com wrote:
Hi Brandon + Stephen,

Having all those permutations (and potentially testing them) made us lean 
against the sharing case in the first place. It’s just a lot of extra work for 
only a small number of our customers.

German

From: Stephen Balukoff 
[mailto:sbaluk...@bluebox.netmailto:sbaluk...@bluebox.net]
Sent: Thursday, December 04, 2014 9:17 PM

To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [neutron][lbaas] Shared Objects in LBaaS - Use 
Cases that led us to adopt this.

Hi Brandon,

Yeah, in your example, member1 could potentially have 8 different statuses (and 
this is a small example!)...  If that member starts flapping, it means that 
every time it flaps there are 8 notifications being passed upstream.

Note that this problem actually doesn't get any better if we're not sharing 
objects but are just duplicating them (ie. not sharing objects but the user 
makes references to the same back-end machine as 8 different members.)

To be honest, I don't see sharing entities at many levels like this being the 
rule for most of our installations-- maybe a few percentage points of 
installations will do an excessive sharing of members, but I doubt it. So 
really, even though reporting status like this is likely to generate a pretty 
big tree of data, I don't think this is actually a problem, eh. And I don't see 
sharing entities actually reducing the workload of what needs to happen behind 
the scenes. (It just allows us to conceal more of this work from the user.)

Stephen



On Thu, Dec 4, 2014 at 4:05 PM, Brandon Logan 
brandon.lo...@rackspace.commailto:brandon.lo...@rackspace.com wrote:
Sorry it's taken me a while to respond to this.

So I wasn't thinking about this correctly.  I was afraid you would have
to pass in a full tree of parent child representations to /loadbalancers
to update anything a load balancer it is associated to (including down
to members).  However, after thinking about it, a user would just make
an association call on each object.  For Example, associate member1 with
pool1, associate pool1 with listener1, then associate loadbalancer1 with
listener1.  Updating is just as simple as updating each entity.

This does bring up another problem though.  If a listener can live on
many load balancers, and a pool can live on many listeners, and a member
can live on many pools, there's lot of permutations to keep track of for
status.  you can't just link a member's status to a load balancer bc a
member can exist on many pools under that load balancer, and each pool
can exist under many listeners under that load balancer.  For example,
say I have these:

lb1
lb2
listener1
listener2
pool1
pool2
member1
member2

lb1 - [listener1, listener2]
lb2 - [listener1]
listener1 - [pool1, pool2]
listener2 - [pool1]
pool1 - [member1, member2]
pool2 - [member1]

member1 can now have a different statuses under pool1 and pool2.  since
listener1 and listener2 both have pool1, this means member1 will now
have a different status for listener1 - pool1 and listener2 - pool2
combination.  And so forth for load balancers.

Basically there's a lot of permutations and combinations to keep track
of with this model for statuses.  Showing these in the body of load
balancer details can get quite large.

I hope this makes sense because my brain is ready to explode.

Thanks,
Brandon

On Thu, 2014-11-27 at 08:52 +, Samuel Bercovici wrote:
 Brandon, can you please explain further (1) bellow?

 -Original Message-
 From: Brandon Logan 
 [mailto:brandon.lo...@rackspace.commailto:brandon.lo...@rackspace.com]
 Sent: Tuesday, November 25, 2014 12:23 AM
 To: 
 openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
 Subject: Re: [openstack-dev] [neutron][lbaas] Shared Objects in LBaaS - Use 
 Cases that led us to adopt this.

 My impression is that the statuses of each entity will be shown on a detailed 
 info request of a loadbalancer.  The root level objects would not have any 
 statuses.  For example a user makes a GET request to /loadbalancers/{lb_id} 
 and the status of every child of that load balancer is show in a 
 status_tree json object.  For example:

 {name: loadbalancer1,
  status_tree:
   {listeners:
 [{name: listener1, operating_status: ACTIVE,
   default_pool:
 {name: pool1, status: ACTIVE,
  members

Re: [openstack-dev] [neutron][lbaas] Shared Objects in LBaaS - Use Cases that led us to adopt this.

[Samuel Bercovici]

 an haproxy perspective, sharing pools within a single 
 listener actually isn't a problem. That is to say, having the same 
 L7Policy pointing at the same pool is OK, so I personally don't have a 
 problem allowing sharing of objects within the scope of parent 
 objects. What do the rest of y'all think?
 
 
 Stephen
 
 
 
 On Sat, Nov 22, 2014 at 11:06 PM, Samuel Bercovici 
 samu...@radware.com wrote:
 Hi Stephen,
 
  
 
 1.  The issue is that if we do 1:1 and allow status/state
 to proliferate throughout all objects we will then get an
 issue to fix it later, hence even if we do not do sharing, I
 would still like to have all objects besides LB be treated as
 logical.
 
 2.  The 3rd use case bellow will not be reasonable without
 pool sharing between different policies. Specifying different
 pools which are the same for each policy make it non-started
 to me. 
 
  
 
 -Sam.
 
  
 
  
 
  
 
 From: Stephen Balukoff [mailto:sbaluk...@bluebox.net] 
 Sent: Friday, November 21, 2014 10:26 PM
 To: OpenStack Development Mailing List (not for usage
 questions)
 Subject: Re: [openstack-dev] [neutron][lbaas] Shared Objects
 in LBaaS - Use Cases that led us to adopt this.
 
  
 
 I think the idea was to implement 1:1 initially to reduce the
 amount of code and operational complexity we'd have to deal
 with in initial revisions of LBaaS v2. Many to many can be
 simulated in this scenario, though it does shift the burden of
 maintenance to the end user. It does greatly simplify the
 initial code for v2, in any case, though.
 
 
  
 
 
 Did we ever agree to allowing listeners to be shared among
 load balancers?  I think that still might be a N:1
 relationship even in our latest models.
 
  
 
 
 There's also the difficulty introduced by supporting different
 flavors:  Since flavors are essentially an association between
 a load balancer object and a driver (with parameters), once
 flavors are introduced, any sub-objects of a given load
 balancer objects must necessarily be purely logical until they
 are associated with a load balancer.  I know there was talk of
 forcing these objects to be sub-objects of a load balancer
 which can't be accessed independently of the load balancer
 (which would have much the same effect as what you discuss:
 State / status only make sense once logical objects have an
 instantiation somewhere.) However, the currently proposed API
 treats most objects as root objects, which breaks this
 paradigm.
 
 
  
 
 
 How we handle status and updates once there's an instantiation
 of these logical objects is where we start getting into real
 complexity.
 
 
  
 
 
 It seems to me there's a lot of complexity introduced when we
 allow a lot of many to many relationships without a whole lot
 of benefit in real-world deployment scenarios. In most cases,
 objects are not going to be shared, and in those cases with
 sufficiently complicated deployments in which shared objects
 could be used, the user is likely to be sophisticated enough
 and skilled enough to manage updating what are essentially
 copies of objects, and would likely have an opinion about
 how individual failures should be handled which wouldn't
 necessarily coincide with what we developers of the system
 would assume. That is to say, allowing too many many to many
 relationships feels like a solution to a problem that doesn't
 really exist, and introduces a lot of unnecessary complexity.
 
 
  
 
 
 In any case, though, I feel like we should walk before we run:
 Implementing 1:1 initially is a good idea to get us rolling.
 Whether we then implement 1:N or M:N after that is another
 question entirely. But in any case, it seems like a bad idea
 to try to start with M:N.
 
 
  
 
 
 Stephen
 
 
  
 
 
  
 
 On Thu, Nov 20, 2014 at 4:52 AM, Samuel Bercovici
 samu...@radware.com wrote:
 
 Hi,
 
 Per discussion I had at OpenStack Summit/Paris with Brandon
 and Doug, I would like to remind everyone why we choose to
 follow a model where pools and listeners are shared (many to
 many

Re: [openstack-dev] [neutron][lbaas] Shared Objects in LBaaS - Use Cases that led us to adopt this.

[Samuel Bercovici]

Brandon, can you please explain further (1) bellow?

-Original Message-
From: Brandon Logan [mailto:brandon.lo...@rackspace.com] 
Sent: Tuesday, November 25, 2014 12:23 AM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [neutron][lbaas] Shared Objects in LBaaS - Use 
Cases that led us to adopt this.

My impression is that the statuses of each entity will be shown on a detailed 
info request of a loadbalancer.  The root level objects would not have any 
statuses.  For example a user makes a GET request to /loadbalancers/{lb_id} and 
the status of every child of that load balancer is show in a status_tree json 
object.  For example:

{name: loadbalancer1,
 status_tree:
  {listeners: 
[{name: listener1, operating_status: ACTIVE,
  default_pool:
{name: pool1, status: ACTIVE,
 members:
   [{ip_address: 10.0.0.1, status: OFFLINE}]}}

Sam, correct me if I am wrong.

I generally like this idea.  I do have a few reservations with this:

1) Creating and updating a load balancer requires a full tree configuration 
with the current extension/plugin logic in neutron.  Since updates will require 
a full tree, it means the user would have to know the full tree configuration 
just to simply update a name.  Solving this would require nested child 
resources in the URL, which the current neutron extension/plugin does not 
allow.  Maybe the new one will.

2) The status_tree can get quite large depending on the number of listeners and 
pools being used.  This is a minor issue really as it will make horizon's (or 
any other UI tool's) job easier to show statuses.

Thanks,
Brandon

On Mon, 2014-11-24 at 12:43 -0800, Stephen Balukoff wrote:
 Hi Samuel,
 
 
 We've actually been avoiding having a deeper discussion about status 
 in Neutron LBaaS since this can get pretty hairy as the back-end 
 implementations get more complicated. I suspect managing that is 
 probably one of the bigger reasons we have disagreements around object 
 sharing. Perhaps it's time we discussed representing state correctly 
 (whatever that means), instead of a round-a-bout discussion about 
 object sharing (which, I think, is really just avoiding this issue)?
 
 
 Do you have a proposal about how status should be represented 
 (possibly including a description of the state machine) if we collapse 
 everything down to be logical objects except the loadbalancer object?
 (From what you're proposing, I suspect it might be too general to, for 
 example, represent the UP/DOWN status of members of a given pool.)
 
 
 Also, from an haproxy perspective, sharing pools within a single 
 listener actually isn't a problem. That is to say, having the same 
 L7Policy pointing at the same pool is OK, so I personally don't have a 
 problem allowing sharing of objects within the scope of parent 
 objects. What do the rest of y'all think?
 
 
 Stephen
 
 
 
 On Sat, Nov 22, 2014 at 11:06 PM, Samuel Bercovici 
 samu...@radware.com wrote:
 Hi Stephen,
 
  
 
 1.  The issue is that if we do 1:1 and allow status/state
 to proliferate throughout all objects we will then get an
 issue to fix it later, hence even if we do not do sharing, I
 would still like to have all objects besides LB be treated as
 logical.
 
 2.  The 3rd use case bellow will not be reasonable without
 pool sharing between different policies. Specifying different
 pools which are the same for each policy make it non-started
 to me. 
 
  
 
 -Sam.
 
  
 
  
 
  
 
 From: Stephen Balukoff [mailto:sbaluk...@bluebox.net] 
 Sent: Friday, November 21, 2014 10:26 PM
 To: OpenStack Development Mailing List (not for usage
 questions)
 Subject: Re: [openstack-dev] [neutron][lbaas] Shared Objects
 in LBaaS - Use Cases that led us to adopt this.
 
  
 
 I think the idea was to implement 1:1 initially to reduce the
 amount of code and operational complexity we'd have to deal
 with in initial revisions of LBaaS v2. Many to many can be
 simulated in this scenario, though it does shift the burden of
 maintenance to the end user. It does greatly simplify the
 initial code for v2, in any case, though.
 
 
  
 
 
 Did we ever agree to allowing listeners to be shared among
 load balancers?  I think that still might be a N:1
 relationship even in our latest models.
 
  
 
 
 There's also the difficulty introduced by supporting different
 flavors:  Since flavors are essentially an association between
 a load balancer object and a driver (with parameters), once
 flavors are introduced, any sub-objects of a given load

Re: [openstack-dev] [neutron][lbaas] Shared Objects in LBaaS - Use Cases that led us to adopt this.

[Samuel Bercovici]

Hi Stephen,


1.   The issue is that if we do 1:1 and allow status/state to proliferate 
throughout all objects we will then get an issue to fix it later, hence even if 
we do not do sharing, I would still like to have all objects besides LB be 
treated as logical.

2.   The 3rd use case bellow will not be reasonable without pool sharing 
between different policies. Specifying different pools which are the same for 
each policy make it non-started to me.

-Sam.



From: Stephen Balukoff [mailto:sbaluk...@bluebox.net]
Sent: Friday, November 21, 2014 10:26 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [neutron][lbaas] Shared Objects in LBaaS - Use 
Cases that led us to adopt this.

I think the idea was to implement 1:1 initially to reduce the amount of code 
and operational complexity we'd have to deal with in initial revisions of LBaaS 
v2. Many to many can be simulated in this scenario, though it does shift the 
burden of maintenance to the end user. It does greatly simplify the initial 
code for v2, in any case, though.

Did we ever agree to allowing listeners to be shared among load balancers?  I 
think that still might be a N:1 relationship even in our latest models.

There's also the difficulty introduced by supporting different flavors:  Since 
flavors are essentially an association between a load balancer object and a 
driver (with parameters), once flavors are introduced, any sub-objects of a 
given load balancer objects must necessarily be purely logical until they are 
associated with a load balancer.  I know there was talk of forcing these 
objects to be sub-objects of a load balancer which can't be accessed 
independently of the load balancer (which would have much the same effect as 
what you discuss: State / status only make sense once logical objects have an 
instantiation somewhere.) However, the currently proposed API treats most 
objects as root objects, which breaks this paradigm.

How we handle status and updates once there's an instantiation of these logical 
objects is where we start getting into real complexity.

It seems to me there's a lot of complexity introduced when we allow a lot of 
many to many relationships without a whole lot of benefit in real-world 
deployment scenarios. In most cases, objects are not going to be shared, and in 
those cases with sufficiently complicated deployments in which shared objects 
could be used, the user is likely to be sophisticated enough and skilled enough 
to manage updating what are essentially copies of objects, and would likely 
have an opinion about how individual failures should be handled which wouldn't 
necessarily coincide with what we developers of the system would assume. That 
is to say, allowing too many many to many relationships feels like a solution 
to a problem that doesn't really exist, and introduces a lot of unnecessary 
complexity.

In any case, though, I feel like we should walk before we run: Implementing 1:1 
initially is a good idea to get us rolling. Whether we then implement 1:N or 
M:N after that is another question entirely. But in any case, it seems like a 
bad idea to try to start with M:N.

Stephen


On Thu, Nov 20, 2014 at 4:52 AM, Samuel Bercovici 
samu...@radware.commailto:samu...@radware.com wrote:
Hi,

Per discussion I had at OpenStack Summit/Paris with Brandon and Doug, I would 
like to remind everyone why we choose to follow a model where pools and 
listeners are shared (many to many relationships).

Use Cases:
1. The same application is being exposed via different LB objects.
For example: users coming from the internal private organization network, 
have an LB1(private_VIP) -- Listener1(TLS) --Pool1 and user coming from the 
internet, have LB2(public_vip)--Listener1(TLS)--Pool1.
This may also happen to support ipv4 and ipv6: LB_v4(ipv4_VIP) -- 
Listener1(TLS) --Pool1 and LB_v6(ipv6_VIP) -- Listener1(TLS) --Pool1
The operator would like to be able to manage the pool membership in cases of 
updates and error in a single place.

2. The same group of servers is being used via different listeners optionally 
also connected to different LB objects.
For example: users coming from the internal private organization network, 
have an LB1(private_VIP) -- Listener1(HTTP) --Pool1 and user coming from the 
internet, have LB2(public_vip)--Listener2(TLS)--Pool1.
The LBs may use different flavors as LB2 needs TLS termination and may prefer a 
different stronger flavor.
The operator would like to be able to manage the pool membership in cases of 
updates and error in a single place.

3. The same group of servers is being used in several different L7_Policies 
connected to a listener. Such listener may be reused as in use case 1.
For example: LB1(VIP1)--Listener_L7(TLS)
|
+--L7_Policy1(rules..)--Pool1

[openstack-dev] [neutron][lbaas] Shared Objects in LBaaS - Use Cases that led us to adopt this.

[Samuel Bercovici]

Hi,

Per discussion I had at OpenStack Summit/Paris with Brandon and Doug, I would 
like to remind everyone why we choose to follow a model where pools and 
listeners are shared (many to many relationships).

Use Cases:
1. The same application is being exposed via different LB objects. 
For example: users coming from the internal private organization network, 
have an LB1(private_VIP) -- Listener1(TLS) --Pool1 and user coming from the 
internet, have LB2(public_vip)--Listener1(TLS)--Pool1. 
This may also happen to support ipv4 and ipv6: LB_v4(ipv4_VIP) -- 
Listener1(TLS) --Pool1 and LB_v6(ipv6_VIP) -- Listener1(TLS) --Pool1
The operator would like to be able to manage the pool membership in cases of 
updates and error in a single place.

2. The same group of servers is being used via different listeners optionally 
also connected to different LB objects.
For example: users coming from the internal private organization network, 
have an LB1(private_VIP) -- Listener1(HTTP) --Pool1 and user coming from the 
internet, have LB2(public_vip)--Listener2(TLS)--Pool1. 
The LBs may use different flavors as LB2 needs TLS termination and may prefer a 
different stronger flavor.
The operator would like to be able to manage the pool membership in cases of 
updates and error in a single place.

3. The same group of servers is being used in several different L7_Policies 
connected to a listener. Such listener may be reused as in use case 1.
For example: LB1(VIP1)--Listener_L7(TLS)
|
+--L7_Policy1(rules..)--Pool1
|
+--L7_Policy2(rules..)--Pool2
|
+--L7_Policy3(rules..)--Pool1
|
+--L7_Policy3(rules..)--Reject


I think that the key issue handling correctly the provisioning state and 
the operation state in a many to many model.
This is an issue as we have attached status fields to each and every object in 
the model. 
A side effect of the above is that to understand the provisioning/operation 
status one needs to check many different objects.

To remedy this, I would like to turn all objects besides the LB to be logical 
objects. This means that the only place to manage the status/state will be on 
the LB object.
Such status should be hierarchical so that logical object attached to an LB, 
would have their status consumed out of the LB object itself (in case of an 
error).
We also need to discuss how modifications of a logical object will be 
rendered to the concrete LB objects.
You may want to revisit 
https://docs.google.com/document/d/1D-1n8nCEFurYzvEBxIRfXfffnImcIPwWSctAG-NXonY/edit#heading=h.3rvy5drl5b5r
 the Logical Model + Provisioning Status + Operation Status + Statistics for 
a somewhat more detailed explanation albeit it uses the LBaaS v1 model as a 
reference.

Regards,
-Sam.





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

Re: [openstack-dev] [neutron][lbaas] rescheduling meeting

[Samuel Bercovici]

For us in Israel, the earlier the better.
The current meeting time is very good for us, although I understand it too 
early for some.

-Sam.

From: Gregory Lebovitz [mailto:gregory.i...@gmail.com]
Sent: Wednesday, November 05, 2014 1:10 PM
To: OpenStack Development Mailing List (not for usage questions); Doug Wiegley
Subject: Re: [openstack-dev] [neutron][lbaas] rescheduling meeting

I'm just a lurker, so pls don't optimize for me. FWIW, here's my reply, in 
order of pref:

wed 1600 UTC
wed 1800 UTC
wed 1700 UTC

On Mon, Nov 3, 2014 at 11:42 PM, Doug Wiegley 
do...@a10networks.commailto:do...@a10networks.com wrote:
Hi LBaaS (and others),

We’ve been talking about possibly re-schedulng the LBaaS meeting to a time
to is less crazy early for those in the US.  Alternately, we could also
start alternating times.  For now, let’s see if we can find a slot that
works every week.  Please respond with any time slots that you can NOT
attend:

Monday, 1600UTC
Monday, 1700UTC
Tuesday, 1600UTC (US pacific, 8am)
Tuesday, 1700UTC
Tuesday, 1800UTC
Wednesday, 1600UTC (US pacific, 8am)
Wednesday, 1700UTC
Wednesday, 1800UTC
Thursday, 1400UTC (US pacific, 6am)


Note that many of these slots will require the approval of the
#openstack-meeting-4 channel:

https://review.openstack.org/#/c/132629/

https://review.openstack.org/#/c/132630/


Thanks,
Doug

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



--

Open industry-related email from
Gregory M. Lebovitz
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron][LBaaS] Continuing on Calling driver interface on every API request

[Samuel Bercovici]

Hi,

Validations such as timeout  delay should be performed on the API level 
before it reaches the driver.

For a configuration tree (lb, listeners, pools, etc.), there should be one 
provider.
Having provider defined in multiple places does not make sense.


-San.


From: Vijay Venkatachalam [mailto:vijay.venkatacha...@citrix.com]
Sent: Monday, August 11, 2014 2:43 PM
To: OpenStack Development Mailing List (openstack-dev@lists.openstack.org)
Subject: [openstack-dev] [Neutron][LBaaS] Continuing on Calling driver 
interface on every API request

Hi:

Continuing from last week's LBaaS meeting...

Currently an entity cannot be sent to driver unless it is linked to 
loadbalancer because loadbalancer is the root object and driver information is 
only available with loadbalancer.

The request to the driver is delayed because of which error propagation becomes 
tricky.

Let's say a monitor was configured with timeout  delay there would be no error 
then.
When a listener is configured there will be a monitor creation/deployment error 
like timeout configured greater than delay.

Unless the error is very clearly crafted the user won't be able to understand 
the error.

I am half-heartedly OK with current approach.

But, I would prefer Brandon's Solution - make provider an attribute in each of 
the entities to get rid of this problem.

What do others think?

Thanks,
Vijay V.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron][LBaaS] Continuing on Calling driver interface on every API request

[Samuel Bercovici]

Hi Doug,

In some implementations Driver !== Device. I think this is also true for HA 
Proxy.
This might mean that there is a difference between creating a logical object 
and when there is enough information to actually schedule/place this into a 
device.
The ability to express such errors (detecting an error on a logical object 
after it was created but when it actually get scheduled) should be discussed 
and addressed anyway.

-Sam.


-Original Message-
From: Doug Wiegley [mailto:do...@a10networks.com] 
Sent: Monday, August 11, 2014 6:55 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron][LBaaS] Continuing on Calling driver 
interface on every API request

Hi all,

 Validations such as ³timeout  delay² should be performed on the API 
level before it reaches the driver.
For a configuration tree (lb, listeners, pools, etc.), there should be one 
provider.

You¹re right, but I think the point of Vijay¹s example was to highlight the 
combo error problem with populating all of the driver objects at once (in 
short, the driver interface isn¹t well suited to that model.)  That his one 
example can be covered by API validators is irrelevant.  Consider a backend 
that does not support APP_COOKIE¹s, or HTTPS_TERMINATED (but has multiple 
listeners) instead.  Should the entire load balancer create fail, or should it 
offer degraded service?  Do all drivers have to implement a transaction 
rollback; wait, the interface makes that very hard.  That¹s his point.  The 
driver is no longer just glue code between interfaces; it¹s now a mini-object 
error handler.


 Having provider defined in multiple places does not make sense.

Channeling Brandon, who can yell if I get this wrong, the point is not to have 
a potentially different provider on each object.  It¹s to allow a provider to 
be assigned when the first object in the tree is created, so that future 
related objects will always get routed to the same provider.
Not knowing which provider should get all the objects is why we have to wait 
until we see a LoadBalancer object.


All of this sort of edge case nonsense is because we (the royal we, the 
community), wanted all load balancer objects to be ³root² objects, even though 
only one of them is an actual root today, to support many-to-many relationships 
among all of them, at some future date, without an interface change.  If my 
bias is showing that I¹m not a fan of adding this complexity for that, I¹m not 
surprised.

Thanks,
doug


On 8/11/14, 7:57 AM, Samuel Bercovici samu...@radware.com wrote:

Hi,
 
Validations such as ³timeout  delay² should be performed on the API 
level before it reaches the driver.
 
For a configuration tree (lb, listeners, pools, etc.), there should be 
one provider.

Having provider defined in multiple places does not make sense.
 
 
-San.
 
 
From: Vijay Venkatachalam [mailto:vijay.venkatacha...@citrix.com]

Sent: Monday, August 11, 2014 2:43 PM
To: OpenStack Development Mailing List 
(openstack-dev@lists.openstack.org)
Subject: [openstack-dev] [Neutron][LBaaS] Continuing on Calling driver 
interface on every API request


 
Hi:
 
Continuing from last week¹s LBaaS meetingŠ
 
Currently an entity cannot be sent to driver unless it is linked to 
loadbalancer because loadbalancer is the root object and driver 
information is only available with loadbalancer.

 
The request to the driver is delayed because of which error propagation 
becomes tricky.
 
Let¹s say a monitor was configured with timeout  delay there would be 
no error then.
When a listener is configured there will be a monitor 
creation/deployment error like ³timeout configured greater than delay².
 
Unless the error is very clearly crafted the user won¹t be able to 
understand the error.
 
I am half-heartedly OK with current approach.

 
But, I would prefer Brandon¹s Solution ­ make provider an attribute in 
each of the entities to get rid of this problem.

 
What do others think?
 
Thanks,
Vijay V.



___
OpenStack-dev mailing list
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

Re: [openstack-dev] [Neutron][LBaaS] TLS capability - certificates data persistency

[Samuel Bercovici]

Stephen,

This will increase the complexity of the code since it will add managing the 
cache lifecycle in tandem with the barbican back end and the fact that 
containers may be shared by multiple listeners.
At this stage, I think that it serves us all to keep the code at this stage as 
small and simple as possible.

Let’s judge if presenting this information on the fly (ex: in the Web UI) 
becomes a performance issue and if it does, we can fix it then.

-Sam.


From: Stephen Balukoff [mailto:sbaluk...@bluebox.net]
Sent: Tuesday, July 22, 2014 3:43 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron][LBaaS] TLS capability - certificates 
data persistency

Evgeny--

The only reason I see for storing certificate information in Neutron (and not 
private key information-- just the certificate) is to aid in presenting UI 
information to the user. Especially GUI users don't care about a certificate's 
UUID, they care about which hostnames it's valid for. Yes, this can be loaded 
on the fly whenever public certificate information is accessed, but the 
perception was that it would be a significant performance increase to cache it.

Stephen

On Sun, Jul 20, 2014 at 4:32 AM, Evgeny Fedoruk 
evge...@radware.commailto:evge...@radware.com wrote:
Hi folks,

In a current version of TLS capabilities RST certificate SubjectCommonName and 
SubjectAltName information is cached in a database.
This may be not necessary and here is why:


1.   TLS containers are immutable, meaning once a container was associated 
to a listener and was validated, it’s not necessary to validate the container 
anymore.
This is relevant for both, default container and containers used for SNI.

2.   LBaaS front-end API can check if TLS containers ids were changed for a 
listener as part of an update operation. Validation of containers will be done 
for
new containers only. This is stated in “Performance Impact” section of the RST, 
excepting the last statement that proposes persistency for SCN and SAN.

3.   Any interaction with Barbican API for getting containers data will be 
performed via a common module API only. This module’s API is mentioned in
“SNI certificates list management” section of the RST.

4.   In case when driver really needs to extract certificate information 
prior to the back-end system provisioning, it will do it via the common module 
API.

5.   Back-end provisioning system may cache any certificate data, except 
private key, in case of a specific need of the vendor.

IMO, There is no real need to store certificates data in Neutron database and 
manage its life cycle.
Does anyone sees a reason why caching certificates’ data in Neutron database is 
critical?

Thank you,
Evg


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.orgmailto: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
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron][LBaaS] Milestone and Due Dates

[Samuel Bercovici]

Hi,

Please note that if the following will not get approved this week they will not 
be done in Juno which is a pity considering their almost final state.
https://review.openstack.org/#/c/98640/ - TLS termination
https://review.openstack.org/#/c/99709/ - L7 Content Switching

Please see if there is anything really critical at this stage that can't be 
commented later during the code review. 
Otherwise, please review and +1 so we can get final approval from Neutron cores.

Thanks,
-Sam.




-Original Message-
From: Kyle Mestery [mailto:mest...@mestery.com] 
Sent: Saturday, July 19, 2014 5:52 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron][LBaaS] Milestone and Due Dates

On Fri, Jul 18, 2014 at 4:40 PM, Jorge Miramontes 
jorge.miramon...@rackspace.com wrote:
 Hey Kyle (and anyone else that may know the answers to my questions),

 There are several blueprints that don't have Juno milestones attached 
 to them and was wondering if we could assign them so the broader 
 community is aware of the work the LBaaS folks are working on. These 
 are the blueprints that are currently being worked on but do not have an 
 assigned milestone:

 https://blueprints.launchpad.net/neutron/+spec/lbaas-ref-impl-tls-supp
 ort
 (no milestone)
 https://blueprints.launchpad.net/neutron/+spec/lbaas-ssl-termination ('next'
 milestone. Not sure if this means juno-2 or juno-3) 
 https://blueprints.launchpad.net/neutron/+spec/lbaas-l7-rules (no 
 milestone) 
 https://blueprints.launchpad.net/neutron/+spec/neutron-flavor-framewor
 k (no
 milestone)
 https://blueprints.launchpad.net/neutron/+spec/lbaas-l7-rules (no 
 milestone)

These do not have a milestone set in LP yet because the specs are not approved. 
It's unclear if all of these will be approved for Juno-3 at this point, though 
I suspect at least a few will be. I'm actively reviewing final specs for 
approval before Spec Approval Deadline on Sunday, 7-20.

 Also, please let me know if I left something out everyone.

 Lastly, what are the definitive spec/implementation dates that the 
 LBaaS community should be aware of? A lot of us are confused on exact 
 dates and I wanted to make sure we were all on the same page so that 
 we can put resources on items that are more time sensitive.

Per above, SAD is this Sunday. The Juno release schedule is on the wiki here 
[1].

Thanks,
Kyle

[1] https://wiki.openstack.org/wiki/Juno_Release_Schedule

 Cheers,
 --Jorge

 ___
 OpenStack-dev mailing list
 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

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

Re: [openstack-dev] [Neutron][LBaaS] TLS capability - SNI - Extracting SubjectCommonName and/or SubjectAlternativeNames from X509

[Samuel Bercovici]

OK.

Let me be more precise, extracting the information for view sake / validation 
would be good.
Providing values that are different than what is in the x509 is what I am 
opposed to.

+1 for Carlos on the library and that it should be ubiquitously used.

I will wait for Vijay to speak for himself in this regard…

-Sam.


From: Stephen Balukoff [mailto:sbaluk...@bluebox.net]
Sent: Tuesday, July 15, 2014 8:35 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron][LBaaS] TLS capability - SNI - Extracting 
SubjectCommonName and/or SubjectAlternativeNames from X509

+1 to German's and  Carlos' comments.

It's also worth pointing out that some UIs will definitely want to show SAN 
information and the like, so either having this available as part of the API, 
or as a standard library we write which then gets used by multiple drivers is 
going to be necessary.

If we're extracting the Subject Common Name in any place in the code then we 
also need to be extracting the Subject Alternative Names at the same place. 
From the perspective of the SNI standard, there's no difference in how these 
fields should be treated, and if we were to treat SANs differently then we're 
both breaking the standard and setting a bad precedent.

Stephen

On Tue, Jul 15, 2014 at 9:35 AM, Carlos Garza 
carlos.ga...@rackspace.commailto:carlos.ga...@rackspace.com wrote:

On Jul 15, 2014, at 10:55 AM, Samuel Bercovici 
samu...@radware.commailto:samu...@radware.com
 wrote:

 Hi,


 Obtaining the domain name from the x509 is probably more of a 
 driver/backend/device capability, it would make sense to have a library that 
 could be used by anyone wishing to do so in their driver code.
You can do what ever you want in *your* driver. The code to extract this 
information will be apart of the API and needs to be mentioned in the spec now. 
PyOpenSSL with PyASN1 are the most likely candidates.

Carlos D. Garza

 -Sam.



 From: Eichberger, German 
 [mailto:german.eichber...@hp.commailto:german.eichber...@hp.com]
 Sent: Tuesday, July 15, 2014 6:43 PM
 To: OpenStack Development Mailing List (not for usage questions)
 Subject: Re: [openstack-dev] [Neutron][LBaaS] TLS capability - SNI - 
 Extracting SubjectCommonName and/or SubjectAlternativeNames from X509

 Hi,

 My impression was that the frontend would extract the names and hand them to 
 the driver.  This has the following advantages:

 · We can be sure all drivers can extract the same names
 · No duplicate code to maintain
 · If we ever allow the user to specify the names on UI rather in the 
 certificate the driver doesn’t need to change.

 I think I saw Adam say something similar in a comment to the code.

 Thanks,
 German

 From: Evgeny Fedoruk [mailto:evge...@radware.commailto:evge...@radware.com]
 Sent: Tuesday, July 15, 2014 7:24 AM
 To: OpenStack Development Mailing List (not for usage questions)
 Subject: [openstack-dev] [Neutron][LBaaS] TLS capability - SNI - Extracting 
 SubjectCommonName and/or SubjectAlternativeNames from X509

 Hi All,

 Since this issue came up from TLS capabilities RST doc review, I opened a ML 
 thread for it to make the decision.
 Currently, the document says:

 “
 For SNI functionality, tenant will supply list of TLS containers in specific
 Order.
 In case when specific back-end is not able to support SNI capabilities,
 its driver should throw an exception. The exception message should state
 that this specific back-end (provider) does not support SNI capability.
 The clear sign of listener's requirement for SNI capability is
 a none empty SNI container ids list.
 However, reference implementation must support SNI capability.

 Specific back-end code may retrieve SubjectCommonName and/or altSubjectNames
 from the certificate which will determine the hostname(s) the certificate
 is associated with.

 The order of SNI containers list may be used by specific back-end code,
 like Radware's, for specifying priorities among certificates.
 In case when two or more uploaded certificates are valid for the same DNS name
 and the tenant has specific requirements around which one wins this collision,
 certificate ordering provides a mechanism to define which cert wins in the
 event of a collision.
 Employing the order of certificates list is not a common requirement for
 all back-end implementations.
 “

 The question is about SCN and SAN extraction from X509.
 1.   Extraction of SCN/ SAN should be done while provisioning and not 
 during TLS handshake
 2.   Every back-end code/driver must(?) extract SCN and(?) SAN and use it 
 for certificate determination for host

 Please give your feedback

 Thanks,
 Evg
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.orgmailto:OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


___
OpenStack

Re: [openstack-dev] [Neutron][LBaaS] TLS capability - SNI - Extracting SubjectCommonName and/or SubjectAlternativeNames from X509

[Samuel Bercovici]

Hi,

I think that the discussion have asked that obtaining information out of the 
x509 via the SAN field will not be defined as mandatory.

For example Radware's backend extracts this information from the x509 in the 
(virtual) device itself, specifying dns values different than what exists in 
the x509 is not relevant.
I think that NetScaler case, is similar with the exception (if I understand 
correctly) that it does not extract the values from the SAN field. Also in this 
case, if the front end will provide the domain name outside the x509 it will 
not matter.

Obtaining the domain name from the x509 is probably more of a 
driver/backend/device capability, it would make sense to have a library that 
could be used by anyone wishing to do so in their driver code.

-Sam.



From: Eichberger, German [mailto:german.eichber...@hp.com]
Sent: Tuesday, July 15, 2014 6:43 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron][LBaaS] TLS capability - SNI - Extracting 
SubjectCommonName and/or SubjectAlternativeNames from X509

Hi,

My impression was that the frontend would extract the names and hand them to 
the driver.  This has the following advantages:


* We can be sure all drivers can extract the same names

* No duplicate code to maintain

* If we ever allow the user to specify the names on UI rather in the 
certificate the driver doesn't need to change.

I think I saw Adam say something similar in a comment to the code.

Thanks,
German

From: Evgeny Fedoruk [mailto:evge...@radware.com]
Sent: Tuesday, July 15, 2014 7:24 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [Neutron][LBaaS] TLS capability - SNI - Extracting 
SubjectCommonName and/or SubjectAlternativeNames from X509

Hi All,

Since this issue came up from TLS capabilities RST doc review, I opened a ML 
thread for it to make the decision.
Currently, the document says:


For SNI functionality, tenant will supply list of TLS containers in specific
Order.
In case when specific back-end is not able to support SNI capabilities,
its driver should throw an exception. The exception message should state
that this specific back-end (provider) does not support SNI capability.
The clear sign of listener's requirement for SNI capability is
a none empty SNI container ids list.
However, reference implementation must support SNI capability.

Specific back-end code may retrieve SubjectCommonName and/or altSubjectNames
from the certificate which will determine the hostname(s) the certificate
is associated with.

The order of SNI containers list may be used by specific back-end code,
like Radware's, for specifying priorities among certificates.
In case when two or more uploaded certificates are valid for the same DNS name
and the tenant has specific requirements around which one wins this collision,
certificate ordering provides a mechanism to define which cert wins in the
event of a collision.
Employing the order of certificates list is not a common requirement for
all back-end implementations.


The question is about SCN and SAN extraction from X509.

1.   Extraction of SCN/ SAN should be done while provisioning and not 
during TLS handshake

2.   Every back-end code/driver must(?) extract SCN and(?) SAN and use it 
for certificate determination for host

Please give your feedback

Thanks,
Evg
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron][LBaaS] Shim vs Agent Refactor

[Samuel Bercovici]

This is also my understanding.


From: Stephen Balukoff [mailto:sbaluk...@bluebox.net]
Sent: Thursday, July 10, 2014 6:30 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron][LBaaS] Shim vs Agent Refactor

Per the IRC discussion this morning, I believe it was decided that we would 
prioritize creating a v2 agent which should run in parallel with the v1 agent. 
Further, for any subsequent driver shim layer, this should happen after the v2 
agent is functional.

... or I may have misunderstood what was decided in the meeting. :)  In any 
case, y'all should feel free to correct me here and/or raise other concerns we 
didn't think about, eh!

Stephen

On Wed, Jul 9, 2014 at 3:12 PM, Brandon Logan 
brandon.lo...@rackspace.commailto:brandon.lo...@rackspace.com wrote:
Shim will become quite complicated due to the fact we won't be able to actually 
send any load balancer information to the driver until a load balancer is 
linked to a listener, pool, and member.  The reason is because for a vip to be 
created it needs attributes from a load balancer and listener.  A vip also has 
a required attribute of pool_id in the old API so all the old driver are 
expecting a pool_id.  So this means we need a pool first.  Since the subnet_id 
has been moved off the pool and onto the pool member, we will need to have a 
pool with at least one member before we can send all that information to the 
driver.

Now once that is done, it will probably get even crazier with updates and 
deletes to each one of those entities.

So should time and effort be spent on the shim, which is temporary and 
eventually thrown away. Or should time be spent on creating a new version of 
the agent and namspace driver based off the new driver interface, which will 
need to be done anyway?

Doing the shim could end up being faster than creating a new version of the 
agent, but since there are going to be a lot of crazy edge cases, I question 
the stability of it and the time it may take for it to become stable.

One problem with not doing the shim is the older drivers cannot be used with 
the new API and will have to be updated.  To this, I would argue that there is 
no benefit to using the new API with an old driver versus using the Old API 
with the old driver, right now.  Once L7 and TLS get in then yes there would be.

I'd just like to get people's ideas on this.

Thanks,
Brandon

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.orgmailto: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
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron][LBaaS] Shim vs Agent Refactor

[Samuel Bercovici]

New/updated v2 driver could be done without an agent (same as was possible in 
v1).

From: Doug Wiegley [mailto:do...@a10networks.com]
Sent: Thursday, July 10, 2014 8:06 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron][LBaaS] Shim vs Agent Refactor

Modified slightly, my read on the decision was:

  *   Create a v2 agent, and make the ref haproxy driver use the v2 agent and 
v2 obj model.
  *   At a lower priority, work on a shim for non-agent older drivers.  This is 
de-coupled from the haproxy ref driver, and could happen in parallel if we had 
extra resources.  This shim will have odd corner cases (a second listener on a 
vip, e.g.), which will chuck errors.
The ref haproxy driver is highest priority, and thus the v2 agent, as lbaas v2 
goes nowhere without it.

Doug



From: Samuel Bercovici samu...@radware.commailto:samu...@radware.com
Reply-To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Date: Thursday, July 10, 2014 at 10:36 AM
To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [Neutron][LBaaS] Shim vs Agent Refactor

This is also my understanding.


From: Stephen Balukoff [mailto:sbaluk...@bluebox.net]
Sent: Thursday, July 10, 2014 6:30 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron][LBaaS] Shim vs Agent Refactor

Per the IRC discussion this morning, I believe it was decided that we would 
prioritize creating a v2 agent which should run in parallel with the v1 agent. 
Further, for any subsequent driver shim layer, this should happen after the v2 
agent is functional.

... or I may have misunderstood what was decided in the meeting. :)  In any 
case, y'all should feel free to correct me here and/or raise other concerns we 
didn't think about, eh!

Stephen

On Wed, Jul 9, 2014 at 3:12 PM, Brandon Logan 
brandon.lo...@rackspace.commailto:brandon.lo...@rackspace.com wrote:
Shim will become quite complicated due to the fact we won't be able to actually 
send any load balancer information to the driver until a load balancer is 
linked to a listener, pool, and member.  The reason is because for a vip to be 
created it needs attributes from a load balancer and listener.  A vip also has 
a required attribute of pool_id in the old API so all the old driver are 
expecting a pool_id.  So this means we need a pool first.  Since the subnet_id 
has been moved off the pool and onto the pool member, we will need to have a 
pool with at least one member before we can send all that information to the 
driver.

Now once that is done, it will probably get even crazier with updates and 
deletes to each one of those entities.

So should time and effort be spent on the shim, which is temporary and 
eventually thrown away. Or should time be spent on creating a new version of 
the agent and namspace driver based off the new driver interface, which will 
need to be done anyway?

Doing the shim could end up being faster than creating a new version of the 
agent, but since there are going to be a lot of crazy edge cases, I question 
the stability of it and the time it may take for it to become stable.

One problem with not doing the shim is the older drivers cannot be used with 
the new API and will have to be updated.  To this, I would argue that there is 
no benefit to using the new API with an old driver versus using the Old API 
with the old driver, right now.  Once L7 and TLS get in then yes there would be.

I'd just like to get people's ideas on this.

Thanks,
Brandon

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.orgmailto: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
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron][LBaaS] Shim vs Agent Refactor

[Samuel Bercovici]

The haproxy reference is dependent on the agent.
Radware’s solution does not use an agent.
I was making sure that solutions such as ours will be possible.

From: Dustin Lundquist [mailto:dus...@null-ptr.net]
Sent: Thursday, July 10, 2014 8:51 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron][LBaaS] Shim vs Agent Refactor

Samuel,

I've heard this mentioned before, but looking at the code the haproxy namespace 
driver uses the agent driver interface rather the the abstract driver 
interface. Are you sure the HAProxy driver can be used without the agent, if so 
could you explain how?

Thanks,


Dustin Lundquist


On Thursday, July 10, 2014, Samuel Bercovici 
samu...@radware.commailto:samu...@radware.com wrote:
New/updated v2 driver could be done without an agent (same as was possible in 
v1).

From: Doug Wiegley 
[mailto:do...@a10networks.comjavascript:_e(%7B%7D,'cvml','do...@a10networks.com');]
Sent: Thursday, July 10, 2014 8:06 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron][LBaaS] Shim vs Agent Refactor

Modified slightly, my read on the decision was:

  *   Create a v2 agent, and make the ref haproxy driver use the v2 agent and 
v2 obj model.
  *   At a lower priority, work on a shim for non-agent older drivers.  This is 
de-coupled from the haproxy ref driver, and could happen in parallel if we had 
extra resources.  This shim will have odd corner cases (a second listener on a 
vip, e.g.), which will chuck errors.
The ref haproxy driver is highest priority, and thus the v2 agent, as lbaas v2 
goes nowhere without it.

Doug



From: Samuel Bercovici 
samu...@radware.comjavascript:_e(%7B%7D,'cvml','samu...@radware.com');
Reply-To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.orgjavascript:_e(%7B%7D,'cvml','openstack-dev@lists.openstack.org');
Date: Thursday, July 10, 2014 at 10:36 AM
To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.orgjavascript:_e(%7B%7D,'cvml','openstack-dev@lists.openstack.org');
Subject: Re: [openstack-dev] [Neutron][LBaaS] Shim vs Agent Refactor

This is also my understanding.


From: Stephen Balukoff 
[mailto:sbaluk...@bluebox.netjavascript:_e(%7B%7D,'cvml','sbaluk...@bluebox.net');]
Sent: Thursday, July 10, 2014 6:30 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron][LBaaS] Shim vs Agent Refactor

Per the IRC discussion this morning, I believe it was decided that we would 
prioritize creating a v2 agent which should run in parallel with the v1 agent. 
Further, for any subsequent driver shim layer, this should happen after the v2 
agent is functional.

... or I may have misunderstood what was decided in the meeting. :)  In any 
case, y'all should feel free to correct me here and/or raise other concerns we 
didn't think about, eh!

Stephen

On Wed, Jul 9, 2014 at 3:12 PM, Brandon Logan 
brandon.lo...@rackspace.comjavascript:_e(%7B%7D,'cvml','brandon.lo...@rackspace.com');
 wrote:
Shim will become quite complicated due to the fact we won't be able to actually 
send any load balancer information to the driver until a load balancer is 
linked to a listener, pool, and member.  The reason is because for a vip to be 
created it needs attributes from a load balancer and listener.  A vip also has 
a required attribute of pool_id in the old API so all the old driver are 
expecting a pool_id.  So this means we need a pool first.  Since the subnet_id 
has been moved off the pool and onto the pool member, we will need to have a 
pool with at least one member before we can send all that information to the 
driver.

Now once that is done, it will probably get even crazier with updates and 
deletes to each one of those entities.

So should time and effort be spent on the shim, which is temporary and 
eventually thrown away. Or should time be spent on creating a new version of 
the agent and namspace driver based off the new driver interface, which will 
need to be done anyway?

Doing the shim could end up being faster than creating a new version of the 
agent, but since there are going to be a lot of crazy edge cases, I question 
the stability of it and the time it may take for it to become stable.

One problem with not doing the shim is the older drivers cannot be used with 
the new API and will have to be updated.  To this, I would argue that there is 
no benefit to using the new API with an old driver versus using the Old API 
with the old driver, right now.  Once L7 and TLS get in then yes there would be.

I'd just like to get people's ideas on this.

Thanks,
Brandon

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.orgjavascript:_e(%7B%7D,'cvml','OpenStack-dev@lists.openstack.org');
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



--
Stephen Balukoff
Blue

Re: [openstack-dev] [Neutron][LBaaS] Status of entities that do not exist in a driver backend

[Samuel Bercovici]

Hi,

For logical objects that were deleted but the backend did not execute on, there 
is a PENDING_DELETE state.
So currently there is PENDING_CREATE -- CREATE, PENDING_UPDATE--UPDATE and 
PENDING_DELETE--object is removed from the database.
If an error occurred that the object is in ERROR state.

So in this case if a listener is not yet  configured in the backend, it will 
have a PENDING_CREATE state.

-Sam.



-Original Message-
From: Mark McClain [mailto:mmccl...@yahoo-inc.com] 
Sent: Monday, July 07, 2014 5:33 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron][LBaaS] Status of entities that do not 
exist in a driver backend


On Jul 4, 2014, at 5:27 PM, Brandon Logan brandon.lo...@rackspace.com wrote:

 Hi German,
 
 That actually brings up another thing that needs to be done.  There is 
 no DELETED state.  When an entity is deleted, it is deleted from the 
 database.  I'd prefer a DELETED state so that should be another 
 feature we implement afterwards.
 
 Thanks,
 Brandon
 

This is an interesting discussion since we would create an API inconsistency 
around possible status values.  Traditionally, status has been be fabric status 
and we have not always well defined what the values should mean to tenants.  
Given that this is an extension, I think that adding new values would be ok 
(Salvatore might have a different opinion than me).

Right we've never had a deleted state because the record has been removed 
immediately in most implementations even if the backend has not fully cleaned 
up.  I was thinking for the v3 core we should have a DELETING state that is set 
before cleanup is dispatched to the backend driver/worker.  The record can then 
be deleted when the backend has cleaned up.

For unattached objects, I'm -1 on QUEUED because some will interpret that the 
system is planning to execute immediate operations on the resource (causing 
customer queries/complaints about why it has not transitioned).  Maybe use 
something like DEFERRED, UNBOUND, or VALIDATED? 

mark
___
OpenStack-dev mailing list
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

[openstack-dev] [Neutron][LBaaS] Analyzing the critical path

[Samuel Bercovici]

To reiterate the Juno release plan from: 
https://wiki.openstack.org/wiki/Juno_Release_Schedule
Feature freeze is at: 21st August.

I am listing tasks which we should consider to be done for Juno and who should 
handle them.

The following might be considered as critical path to get anything for Juno:

1.   LBaaS Plugin, API, DB - when is a code commit expected?

2.   CLI

3.   LBaaS Driver Interfaces - done - 
https://review.openstack.org/#/c/100690/

4.   Connecting the Plugin calls to the drive - I have not seen any 
reference to this. I think we should use the provider capabilities until 
flavor gets implemented. Is this addressed by item 1 above or does it 
required an additional task?

5.   HA proxy reference implementation - when is a code commit expected?

6.   Tempest Tests

Additional Core features

1.   Horizon UI

2.   Quota update/fix

3.   API Compatibility

a.   Connecting the OLD API Plugin calls to old/new drivers. Is this 
still planned?

4.   Driver Compatibility

a.   Connecting the Plugin calls to old drivers. Is this still planned?

In addition/parallel

1.   TLS  -

a.   BP is approved.

b.  WIP code was committed and waiting for the code of the basic API/model 
to be available for start of review.

c.   HA Proxy reference implementation

d.  CLI

e.  Horizon Support

f.Tempest Tests

2.   L7 context switching

a.   BP in review

b.  WIP code in progress and waiting for the code of the basic API/model to 
be available for initial commit

c.   HA Proxy reference implementation

d.  CLI

e.  Horizon Support

f.Tempest Tests

Anything else?


Regards,
-Sam.

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

Re: [OpenStack-Infra] Hosting your CI logs at dropbox is not acceptable

[Samuel Bercovici]

Hi Anita,

When you mention opens source solution, please point to an available open 
source hosting that we can use to push the log files into?
The alternative would be to put the 3rd party testing CI system behind a public 
IP and this will most likely going to take time.

Regards,
-Sam.


-Original Message-
From: Anita Kuno [mailto:ante...@anteaya.info] 
Sent: Monday, June 23, 2014 5:51 PM
To: Avishay Balderman
Cc: Samuel Bercovici; Izik Penso; openstack-infra@lists.openstack.org
Subject: Re: Hosting your CI logs at dropbox is not acceptable

On 06/23/2014 10:35 AM, Avishay Balderman wrote:
 Hi
 Thanks for your detailed answer.
 Is the following  link  valid for logs hosting?
 (download is not needed, works fine under Chrome and FF)
 
 https://www.dropbox.com/sh/wl2i5kbofvpbgm9/AADj8qye3nU05Y2ZKNwRQNIWa
 
 Thanks
 
 Avishay
Well it isn't open source for starters, and so far while it isn't a requirment, 
use of non open source options is discouraged.

Secondly, go to the link yourself and click. See long you you have to wait 
until the log file is served, then do the same for the second file.
Now imagine 30 files, some of which you have to go back and look at a second 
time. Now imagine a patch where the developer has 5 or more systems reporting 
on a given patch (some patches have more but lets go with 5). All the log 
hosting systems meet the letter of the requirements but all are in a different 
format. The developer has to spend at least an hour going through 6 different 
sets of logs (including the OpenStack
set) for one patchset to see where there is a problem. They are going to get 
frustrated because this takes too much of their time to figure out what the 
problem is. The system that takes so long to render logs is going to get a 
complaint, I field the complaint and act on the behalf of the developer. Then I 
have to make up a new rule so that third party ci systems more closely match 
our system (which the devlopers are used to) but without saying do what we do.

So in short, I prefer open source solutions and I would get frustrated waiting 
for the log files to render.

Thanks Avishay,
Anita.
 
 -Original Message-
 From: Anita Kuno [mailto:ante...@anteaya.info]
 Sent: Monday, June 23, 2014 5:16 PM
 To: Avishay Balderman
 Cc: Samuel Bercovici; Izik Penso; openstack-infra@lists.openstack.org
 Subject: Re: Hosting your CI logs at dropbox is not acceptable
 
 On 06/22/2014 07:10 AM, Avishay Balderman wrote:
 Hi Anita
 Can you please point us to the specification explaining how the 3rd party 
 test results should be hosted?

 What is the main feature for the hosting?
 As far as we understand the files should be visible via browser (Chrome,FF).

 Anything else?

 Thanks

 Avishay

 Hi Avishay:
 
 In opensource we have less of an emphasis on specifications and more of an 
 emphasis on discussion. Yes I can point you to at least one discussion so far 
 on log hosting and invite you and members of your group to more discussions 
 on the topic.
 http://eavesdrop.openstack.org/irclogs/%23openstack-infra/%23openstack
 -infra.2014-06-19.log
 timestamp 2014-06-19T13:49:43
 
 Currently we have this documentation around third party testing
 requirements: http://ci.openstack.org/third_party.html
 Also in light of recent discussions there are two patches in review 
 for changes to that document: https://review.openstack.org/#/c/101013/ 
 and https://review.openstack.org/#/c/101227/
 
 We also have a weekly third party meeting that takes place on Mondays 
 at
 1800 utc in the #openstack-meeting channel on the freenode network 
 where we discuss current practices, any questions, identify issues and 
 work to address them as well as share information among openstack 
 programs and third party ci systems: 
 https://wiki.openstack.org/wiki/Meetings/ThirdParty
 
 Opensource is a living entity and the more you participate in the discussions 
 that result in documentation, the more you have a say in what happens and the 
 better informed you are.
 
 The main feature for the hosting is that it most closely matches the workflow 
 that the developers already use with gerrit. The more familiar you are with 
 gerrit, the easier it is to get hosting right. Now we will create and amend 
 documents as we need to to refine communication around hosting of logs (as 
 well as all other aspects of third party ci) but the docs will only ever be 
 looking to address behaviour that we never imagined anyone would do (or omit) 
 in the first place. I strongly encourage you to participate in the third 
 party meetings as well as in the irc channel for the project you are testing 
 to talk with the developers who are getting the comments from your system on 
 their patches and hear from them what you system needs to do to make them 
 happy.
 
 Also if I email you in future and cc the openstack-infra mailing list, please 
 cc the openstack-infra mailing list in your reply. I have done so in my reply.
 
 Thanks

Re: [openstack-dev] [Neutron][LBaaS] TLS support RST document on Gerrit

[Samuel Bercovici]

 the complexity you’re proposing to add to Barbican.

-Douglas M.



On 6/11/14, 12:57 PM, Doug Wiegley 
do...@a10networks.commailto:do...@a10networks.com wrote:

There are other fundamental things about secrets, like relying on their
presence, and not encouraging a proliferation of a dozen
mini-secret-stores everywhere to get around that fact, which makes it
less secret.  Have you considered a ³force² delete flag, required if
some service is using the secret, sort of ³rm² vs ³rm -f², to avoid the
obvious foot-shooting use cases, but still allowing the user to nuke it
if necessary?

Thanks,
Doug


On 6/11/14, 11:43 AM, Clark, Robert Graham 
robert.cl...@hp.commailto:robert.cl...@hp.com wrote:

Users have to be able to delete their secrets from Barbican, it's a
fundamental key-management requirement.

 -Original Message-
 From: Eichberger, German
 Sent: 11 June 2014 17:43
 To: OpenStack Development Mailing List (not for usage questions)
 Subject: Re: [openstack-dev] [Neutron][LBaaS] TLS support RST
 document on Gerrit

 Sorry, I am late to the party. Holding the shadow copy in the
 backend
is a
 fine solution.

 Also, if containers are immutable can they be deleted at all? Can we
make a
 requirement that a user can't delete a container in Barbican?

 German

 -Original Message-
 From: Eichberger, German
 Sent: Wednesday, June 11, 2014 9:32 AM
 To: OpenStack Development Mailing List (not for usage questions)
 Subject: Re: [openstack-dev] [Neutron][LBaaS] TLS support RST
 document on Gerrit

 Hi,

 I think the previous solution is easier for a user to understand.
 The referenced container got tampered/deleted we throw an error -
 but keep existing load balancers intact.

 With the shadow container we get additional complexity and the user
might
 be confused where the values are coming from.

 German

 -Original Message-
 From: Carlos Garza 
 [mailto:carlos.ga...@rackspace.commailto:carlos.ga...@rackspace.com]
 Sent: Tuesday, June 10, 2014 12:18 PM
 To: OpenStack Development Mailing List (not for usage questions)
 Subject: Re: [openstack-dev] [Neutron][LBaaS] TLS support RST
 document on Gerrit

 See adams message re: Re: [openstack-dev] [Neutron][LBaaS] Barbican
 Neutron LBaaS Integration Ideas.
 He's advocating keeping a shadow copy of the private key that is
 owned
by
 the LBaaS service so that incase a key is tampered with during an LB
update
 migration etc we can still check with the shadow backup and compare
 it
to
 the user owned TLS container in case its not their it can be used.

 On Jun 10, 2014, at 12:47 PM, Samuel Bercovici 
 samu...@radware.commailto:samu...@radware.com
  wrote:

  To elaborate on the case where containers get deleted while LBaaS
still
 references it.
  We think that the following approach will do:
  * The end user can delete a container and leave a dangling
 reference in LBaaS.
  * It would be nice to allow adding meta data on the
container so that
 the user will be aware which listeners use this container. This is
optional. It
 can also be optional for LBaaS to implement adding the listeners ID
 automatically into this metadata just for information.
  * In LBaaS, if an update happens which requires to pull the
container
 from Barbican and if the ID references a non-existing container, the
update
 will fail and will indicate that the reference certificate does not
exists any
 more. This validation could be implemented on the LBaaS API itself
 as
well
 as also by the driver who will actually need the container.
 
  Regards,
  -Sam.
 
 
  From: Evgeny Fedoruk
  Sent: Tuesday, June 10, 2014 2:13 PM
  To: OpenStack Development Mailing List (not for usage questions)
  Subject: Re: [openstack-dev] [Neutron][LBaaS] TLS support RST
document
  on Gerrit
 
  Hi All,
 
  Carlos, Vivek, German, thanks for reviewing the RST doc.
  There are some issues I want to pinpoint final decision on them
here, in
 ML, before writing it down in the doc.
  Other issues will be commented on the document itself.
 
  1.   Support/No support in JUNO
  Referring to summit's etherpad
 https://etherpad.openstack.org/p/neutron-lbaas-ssl-l7,
  a.   SNI certificates list was decided to be supported. Was
decision made
 not to support it?
  Single certificate with multiple domains can only partly address
  the need for SNI, still, different applications on back-end will
  need
different
 certificates.
  b.  Back-end re-encryption was decided to be supported. Was
decision
 made not to support it?
  c.   With front-end client authentication and back-end server
 authentication not supported,
  Should certificate chains be supported?
  2.   Barbican TLS containers
  a.   TLS containers are immutable.
  b.  TLS container is allowed to be deleted, always.
 i.
Even when it is used by LBaaS VIP
 listener (or other service

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

[Samuel Bercovici]

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.miramon...@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@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

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

[Samuel Bercovici]

As far as I understand the Current Barbican implementation is immutable.
Can anyone from Barbican comment on this?

-Original Message-
From: Jain, Vivek [mailto:vivekj...@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 samu...@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.miramon...@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@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


___
OpenStack-dev mailing list
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

Re: [openstack-dev] Your suggestions in the BP

[Samuel Bercovici]

Hi Brandon Eugene and Everyone,

Eugene, please comment on the migration process bellow.

I think that closing down the status handling should be done in phase 1. 
Missing to do so, will create tests and other depending workflows that assume 
the current status field, which will add  a technology debt to this new code.

Migration and co-existence:
I think that it would be better to have the new object model and API done in a 
way that does not break existing code, and then switch the old api to 
redirect to the new api.
This might be done in one of the two ways bellow:
1. Rename all objects in the new api so you have a clear demarcation point. 
This might be sufficient.
2. Copy the existing LBaaS extension and create a new-lbaas extension with 
new object names, then create a new old lbaas extension that has the old 
API but redirect to the new API

Doing 2, can allow co-existence of old code with old drivers until new code 
with new drivers can take its place.

Regards,
-Sam.




-Original Message-
From: Brandon Logan [mailto:brandon.lo...@rackspace.com] 
Sent: Friday, May 30, 2014 6:38 PM
To: Samuel Bercovici
Subject: Your suggestions in the BP

Hi Sam!

Thanks for the suggestions.  I don't think the different statuses should be 
addressed in the blueprint.  I think it would be better left to have its own 
focus in its own blueprint.  I feel the same way about the subnet_id.  I think 
if this blueprint focuses just on the object model change and the migration to 
it, it would be better.

As for having a v2 version of all the table or entirely new tables.  Are you 
suggesting just keeping the old API going to the old object models and database 
tables?  Also, if say I renamed the pool object to nodepool (I prefer that over 
group), then are you also suggesting the new API will have a /nodepools 
resource along with the object model NodePool and database table nodepool?  I'm 
intrigued by this idea, but wasn't totally clear on what you were suggesting.  

Thanks,
Brandon


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

[openstack-dev] [Neutron][LBaaS] object model migration discussion

[Samuel Bercovici]

-Original Message-
From: Samuel Bercovici 
Sent: Sunday, June 01, 2014 10:19 AM
To: 'Brandon Logan'; OpenStack Development Mailing List (not for usage 
questions); Eugene Nikanorov (enikano...@mirantis.com)
Subject: RE: Your suggestions in the BP

Hi Brandon Eugene and Everyone,

Eugene, please comment on the migration process bellow.

I think that closing down the status handling should be done in phase 1. 
Missing to do so, will create tests and other depending workflows that assume 
the current status field, which will add  a technology debt to this new code.

Migration and co-existence:
I think that it would be better to have the new object model and API done in a 
way that does not break existing code, and then switch the old api to 
redirect to the new api.
This might be done in one of the two ways bellow:
1. Rename all objects in the new api so you have a clear demarcation point. 
This might be sufficient.
2. Copy the existing LBaaS extension and create a new-lbaas extension with 
new object names, then create a new old lbaas extension that has the old 
API but redirect to the new API

Doing 2, can allow co-existence of old code with old drivers until new code 
with new drivers can take its place.

Regards,
-Sam.




-Original Message-
From: Brandon Logan [mailto:brandon.lo...@rackspace.com] 
Sent: Friday, May 30, 2014 6:38 PM
To: Samuel Bercovici
Subject: Your suggestions in the BP

Hi Sam!

Thanks for the suggestions.  I don't think the different statuses should be 
addressed in the blueprint.  I think it would be better left to have its own 
focus in its own blueprint.  I feel the same way about the subnet_id.  I think 
if this blueprint focuses just on the object model change and the migration to 
it, it would be better.

As for having a v2 version of all the table or entirely new tables.  Are you 
suggesting just keeping the old API going to the old object models and database 
tables?  Also, if say I renamed the pool object to nodepool (I prefer that over 
group), then are you also suggesting the new API will have a /nodepools 
resource along with the object model NodePool and database table nodepool?  I'm 
intrigued by this idea, but wasn't totally clear on what you were suggesting.  

Thanks,
Brandon


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

Re: [openstack-dev] [Neutron][LBaaS]TLS API support for authentication

[Samuel Bercovici]

+1 to Carlos.

In addition, there should be possible for LBaaS (It might only be just the 
LBaaS drivers) to get the information including the private key back so that 
the backend can use it.
This means that a trusted communication channel between the driver and 
Barbican needs to be established so that such information will be passed.
I am waiting for the code review in barbican to check that such capabilities 
will be available.

Regards,
-Sam.



-Original Message-
From: Carlos Garza [mailto:carlos.ga...@rackspace.com] 
Sent: Wednesday, May 28, 2014 7:03 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron][LBaaS]TLS API support for authentication


On May 27, 2014, at 9:13 PM, Stephen Balukoff sbaluk...@bluebox.net
 wrote:

 Hi y'all!
 
 I would advocate that if the user asks the front-end API for the private key 
 information (ie. GET request), what they get back is the key's modulus and 
 nothing else. This should work to verify whether a given key matches a given 
 cert, and doesn't break security requirements for those who are never allowed 
 to actually touch private key data. And if a user added the key themselves 
 through the front-end API, I think it's safe to assume the responsibility for 
 keeping a copy of the key they can access lies with the user.

I'm thinking at this point all user interaction with their cert and key be 
handled by barbican directly instead of through our API. It seems like we've 
punted everything but the IDs to barbican. Returning the modulus is still RSA 
centric though. 


 
 Having said this, of course anything which spins up virtual appliances, or 
 configures physical appliances is going to need access to the actual private 
 key. So any back-end API(s) will probably need to have different behavior 
 here.
 
 One thing I do want to point out is that with the 'transient' nature of 
 back-end guests / virtual servers, it's probably going to be important to 
 store the private key data in something non-volatile, like barbican's store. 
 While it may be a good idea to add a feature that generates a private key and 
 certificate signing request via our API someday for certain organizations' 
 security requirements, one should never have the only store for this private 
 key be a single virtual server. This is also going to be important if a 
 certificate + key combination gets re-used in another listener in some way, 
 or when horizontal scaling features get added.

I don't think our API needs to handle the CSRs it looks like barbican 
aspires to do this so our API really is pretty insulated.

 
 Thanks,
 Stephen
 
 -- 
 Stephen Balukoff 
 Blue Box Group, LLC 
 (800)613-4305 x807
 ___
 OpenStack-dev mailing list
 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

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

[openstack-dev] [Neutron][LBaaS] dealing with M:N relashionships for Pools and Listeners

[Samuel Bercovici]

Before solving everything, I would like first to itemize the things we should 
solve/consider.
So pleas focus first on what is it that we need to pay attention for and less 
on how to solve such issues.

Follows the list of items:

· Provisioning status/state

o   Should it only be on the loadblancer?

o   Do we need a more granular status per logical child object?

o   Update process

§  What happens when a logical child object is modified?

§  Where can a user check the success of the update?

· Operation status/state - this refers to information returning from 
the load balancing back end / driver

o   How is member status that failed health monitor reflected, on which LBaaS 
object and how can a user understand the failure?

· Administrator state management

o   How is a change in admin_state on member, pool, listener get managed

o   Do we expect a change in the operation state to reflect this?

· Statistics consumption

o   From which object will the user poll to get statistics for the different 
sub objects in the model (ex: load balancer)?

o   How can statistics from a shared logical object be obtained in context of 
the load balancer (ex: pool statistics for a specific listener in a specific 
load balancer)?

· Deletion of shared objects

o   Do we support deletion of shared objects that will cascade delete?

Regards,
-Sam.


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

Re: [openstack-dev] [Neutron][LBaaS]TLS API support for authentication

[Samuel Bercovici]

This very good news.
Please point to the code review in gerrit.

-Sam.


-Original Message-
From: Eichberger, German [mailto:german.eichber...@hp.com] 
Sent: Saturday, May 24, 2014 12:54 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron][LBaaS]TLS API support for authentication

All,

Susanne and I had a demonstration of life code by HP's Barbican team today for 
certificate storage. The code is submitted for review in the Barbican project.

Barbican will be able to store all the certificate parts (cert, key, pwd) in a 
secure container. We will follow up with more details next week -- 

So in short all we need to store in LBaaS is the container-id. The rest will 
come from Barbican and the user will interact straight with Barbican to 
upload/manage his certificates, keys, pwd...

This functionality/use case also is considered in the Marketplace / Murano 
project -- making the need for a central certificate storage in OpenStack a bit 
more pressing.

German

-Original Message-
From: Carlos Garza [mailto:carlos.ga...@rackspace.com]
Sent: Friday, May 23, 2014 1:25 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron][LBaaS]TLS API support for authentication

Right so are you advocating that the front end API never return a private 
key back to the user once regardless if the key was generated on the back end 
or sent in to the API from the user? We kind of are already are implying that 
they can refer to the key via a private key id.


On May 23, 2014, at 9:11 AM, John Dennis jden...@redhat.com
 wrote:

 Using standard formats such as PEM and PKCS12 (most people don't use
 PKCS8 directly) is a good approach.

We had to deal with PKCS8 manually in our CLB1.0 offering at rackspace. Too 
many customers complained.

 Be mindful that some cryptographic
 services do not provide *any* direct access to private keys (makes 
 sense, right?). Private keys are shielded in some hardened container 
 and the only way to refer to the private key is via some form of name 
 association.

Were anticipating referring the keys via a barbican key id which will be 
named later.


 Therefore your design should never depend on having access to a 
 private key and

But we need access enough to transport the key to the back end 
implementation though.

 should permit having the private key stored in some type of secure key 
 storage.

   A secure repository for the private key is already a requirement that we are 
attempting to meat with barbican.


 --
 John
 
 ___
 OpenStack-dev mailing list
 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

___
OpenStack-dev mailing list
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

Re: [openstack-dev] [Neutron][LBaaS]LBaaS 2nd Session etherpad

[Samuel Bercovici]

Hi Everyone,

https://etherpad.openstack.org/p/neutron-lbaas-ssl-l7

Feel free to modify and update, please make sure you use your name so we will 
know who have added the modification.

Regards,
-Sam.

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

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

[Samuel Bercovici]

11 people have responded so far.
Please note that tomorrow is the last day to do the survey.
I will close the survey and publish the results sometimes tomorrow night.

Regards,
   -Sam.

On 9 במאי 2014, at 15:59, Stephen Balukoff 
sbaluk...@bluebox.netmailto:sbaluk...@bluebox.net wrote:

Sam,

That deadline seems reasonable to me. I should have time later today or later 
this weekend to fill it out.

Thanks,
Stephen


On Fri, May 9, 2014 at 9:21 AM, Samuel Bercovici 
samu...@radware.commailto:samu...@radware.com wrote:
Hi,

9 people have filled the survey so far.
See attached pdf.

Regards,
-Sam.


From: Samuel Bercovici
Sent: Thursday, May 08, 2014 2:51 PM

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

Hi everyone,

I think that it is a good feedback to prioritize features.
I can publish the results in time for the 2nd LBaaS meeting (so deadline would 
be end of 15th May “summit time”)
Is this acceptable?

-Sam.



From: Stephen Balukoff [mailto:sbaluk...@bluebox.net]
Sent: Thursday, May 08, 2014 2:17 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron][LBaaS]User Stories and sruvey

Hi Samuel--

I've been heads down working on API proposal review documentation, and haven't 
had time to fill it out yet. Do you have a deadline by which we should have 
filled out the survey to get our voices heard?

Thanks,
Stephen

On Wed, May 7, 2014 at 2:16 PM, Samuel Bercovici 
samu...@radware.commailto:samu...@radware.com wrote:

6 people have completed the survey so far.


From: Samuel Bercovici
Sent: Tuesday, May 06, 2014 10:56 AM

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

Hi Everyone,

The survey is now live via: http://eSurv.org?u=lbaas_project_user
The password is: lbaas

The survey includes all the tenant facing use cases from 
https://docs.google.com/document/d/1Ewl95yxAMq2fO0Z6Dz6fL-w2FScERQXQR1-mXuSINis/edit?usp=sharing
Please try and fill the survey this week so we can have enough information to 
base decisions next week.

Regards,
-Sam.



From: Samuel Bercovici
Sent: Monday, May 05, 2014 4:52 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron][LBaaS]User Stories and sruvey

Hi,

I will not freeze the document to allow people to work on requirements which 
are not tenant facing (ex: operator, etc.)
I think that we have enough use cases for tenant facing capabilities to reflect 
most common use cases.
I am in the process of creation a survey in surveymonkey for tenant facing use 
cases and hope to send it to ML ASAP.

Regards,
-Sam.


From: Samuel Bercovici
Sent: Thursday, May 01, 2014 8:40 PM
To: OpenStack Development Mailing List (not for usage questions)
Cc: Samuel Bercovici
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.orgmailto:OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



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

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.orgmailto: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.orgmailto: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

Re: [openstack-dev] [Neutron][LBaaS]LBaaS 1st Session etherpad

[Samuel Bercovici]

Hi Everyone,

https://etherpad.openstack.org/p/juno-lbaas-design-session

Feel free to modify and update, please make sure you use your name so we will 
know who have added the modification.

Regards,
-Sam.

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

Re: [openstack-dev] [Neutron][LBaaS]LBaaS 1st Session etherpad

[Samuel Bercovici]

Hi,

If a tenant wishes to expose his application (listener, pool(s), etc.) via 
multiple different virtual IP addresses you can do so.

-Sam.

From: Vijay Venkatachalam [mailto:vijay.venkatacha...@citrix.com]
Sent: Thursday, May 15, 2014 12:21 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron][LBaaS]LBaaS 1st Session etherpad

Hi,

I see the following statement in the doc.

multiple loadbalancers may referenece the same listener

Does this mean listeners are independent of loadbalancer?

Thanks,
Vijay V.

From: Samuel Bercovici [mailto:samu...@radware.com]
Sent: Thursday, May 15, 2014 9:26 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron][LBaaS]LBaaS 1st Session etherpad

Hi Everyone,

https://etherpad.openstack.org/p/juno-lbaas-design-session

Feel free to modify and update, please make sure you use your name so we will 
know who have added the modification.

Regards,
-Sam.


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

Re: [openstack-dev] [Neutron][LBaaS] Meetup?

[Samuel Bercovici]

During our brief meeting today, we tentatively scheduled to meet today at 5:30 
PM.
Is this still on?
Where should we meet?

Regards,
 -Sam.

On May 12, 2014, at 1:10 PM, Adam Harwell 
adam.harw...@rackspace.commailto:adam.harw...@rackspace.com wrote:


Some of us are at a table towards the back by the B3b door (and a large 
restrooms sign).

On May 12, 2014 12:24 PM, Adam Harwell 
adam.harw...@rackspace.commailto:adam.harw...@rackspace.com wrote:

Yeah, I guess we'll try to catch people after this session (lunch officially 
starts at 12:45 apparently).

On May 12, 2014 11:48 AM, Eugene Nikanorov 
enikano...@mirantis.commailto:enikano...@mirantis.com wrote:

I'm going to attend the next nw session @b103, we can meet in between. Im in 
b103 too.

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.orgmailto: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

Re: [openstack-dev] [Neutron][LBaaS] Multiple VIPs per loadbalancer

[Samuel Bercovici]

Brandon,

Can you please provide statistics on the distribution between the relationships 
between load balancer and VIPs in your environment?

-Sam.


-Original Message-
From: Brandon Logan [mailto:brandon.lo...@rackspace.com] 
Sent: Friday, May 09, 2014 6:40 PM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [Neutron][LBaaS] Multiple VIPs per loadbalancer

Yes, Rackspace has users that have multiple IPv4 and IPv6 VIPs on a single load 
balancer.  However, I don't think it is a matter of it being needed.  It's a 
matter of having an API that makes sense to a user.
Just because the API has multiple VIPs doesn't mean every VIP needs its own 
port.  In fact creating a port is an implementation detail (you know that 
phrase that everyone throws out to stonewall any discussions?).
The user doesn't care how many neutron ports are set up underneath, they
only care about the VIPs.   

Also, the load balancer wouldn't just be a container, the load balancer would 
have flavor, affinity, and other metadata on it.  Plus, a user will expect to 
get a load balancer back.  Since this object can only be described as a load 
balancer, the name of it shouldn't be up for debate.

The API is meant to be a generic language that can be translated into a working 
load balancer and should be driver agnostic.  We believe this is the most 
generic and flexible API structure.  Each driver will be able to translate this 
into what makes sense for that product.

On a side note, if this is too disruptive for the current LBaaS then why 
couldn't this go into Neutron V3?  I thought that was the plan all along anyway 
with redesigning the API.

Thanks,
Brandon  

On Fri, 2014-05-09 at 14:30 +0400, Eugene Nikanorov wrote:
 Hi folks,
 
 
 I'm pulling this question out of another discussion:
 
 
 Is there a need to have multiple VIPs (e.g. multiple L2 ports/IP
 addresses) per logical loadbalancer?
 If so, we need the description of such cases to evaluate them.
 
 
 Thanks,
 Eugene.
 ___
 OpenStack-dev mailing list
 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

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

Re: [openstack-dev] [Neutron][LBaaS] API proposal review thoughts

[Samuel Bercovici]

It boils down to two aspects:

1.   How common is it for tenant to care about affinity or have more than a 
single VIP used in a way that adding an additional (mandatory) construct makes 
sense for them to handle?

For example if 99% of users do not care about affinity or will only use a 
single VIP (with multiple listeners). In this case does adding an additional 
object that tenants need to know about makes sense?

2.   Scheduling this so that it can be handled efficiently by different 
vendors and SLAs. We can elaborate on this F2F next week.

Can providers share their statistics to assist to understand how common are 
those use cases?

Regards,
-Sam.



From: Stephen Balukoff [mailto:sbaluk...@bluebox.net]
Sent: Friday, May 09, 2014 9:26 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron][LBaaS] API proposal review thoughts

Hi Eugene,

This assumes that 'VIP' is an entity that can contain both an IPv4 address and 
an IPv6 address. This is how it is in the API proposal and corresponding object 
model that I suggested, but it is a slight re-definition of the term virtual 
IP as it's used in the rest of the industry. (And again, we're not yet in 
agreement that 'VIP' should actually contain two ip addresses like this.)

In my mind, the main reasons I would like to see the container object are:


  *   It solves the colocation / apolcation (or affinity / anti-affinity) 
problem for VIPs in a way that is much more intuitive to understand and less 
confusing for users than either the hints included in my API, or something 
based off the nova blueprint for doing the same for virtual servers/containers. 
(Full disclosure: There probably would still be a need for some anti-affinity 
logic at the logical load balancer level as well, though at this point it would 
be an operator concern only and expressed to the user in the flavor of the 
logical load balancer object, and probably be associated with different billing 
strategies. The user wants a dedicated physical load balancer? Then he should 
create one with this flavor, and note that it costs this much more...)
  *   From my experience, users are already familiar with the concept of what a 
logical load balancer actually is (ie. something that resembles a physical or 
virtual appliance from their perspective). So this probably fits into their 
view of the world better.
  *   It makes sense for Load Balancer as a Service to hand out logical load 
balancer objects. I think this will aid in a more intuitive understanding of 
the service for users who otherwise don't want to be concerned with operations.
  *   This opens up the option for private cloud operators / providers to bill 
based on number of physical load balancers used (if the logical load balancer 
happens to coincide with physical load balancer appliances in their 
implementation) in a way that is going to be seen as more fair and more 
predictable to the user because the user has more control over it. And it 
seems to me this is accomplished without producing any undue burden on public 
cloud providers, those who don't bill this way, or those for whom the logical 
load balancer doesn't coincide with physical load balancer appliances.
  *   Attaching a flavor attribute to a logical load balancer seems like a 
better idea than attaching it to the VIP. What if the user wants to change the 
flavor on which their VIP is deployed (ie. without changing IP addresses)? What 
if they want to do this for several VIPs at once? I can definitely see this 
happening in our customer base through the lifecycle of many of our customers' 
applications.
  *   Having flavors associated with load balancers and not VIPs also allows 
for operators to provide a lot more differing product offerings to the user in 
a way that is simple for the user to understand. For example:

 *   Flavor A is the cheap load balancer option, deployed on a shared 
platform used by many tenants that has fewer guarantees around performance and 
costs X.
 *   Flavor B is guaranteed to be deployed on vendor Q's Super Special 
Product (tm) but to keep down costs, may be shared with other tenants, though 
not among a single tenant's load balancers unless the tenant uses the same 
load balancer id when deploying their VIPs (ie. user has control of affinity 
among their own VIPs, but no control over whether affinity happens with other 
tenants). It may experience variable performance as a result, but has higher 
guarantees than the above and costs a little more.
 *   Flavor C is guaranteed to be deployed on vendor P's Even Better 
Super Special Product (tm) and is also guaranteed not to be shared among 
tenants. This is essentially the dedicated load balancer option that gets you 
the best guaranteed performance, but costs a lot more than the above.
 *   ...and so on.

  *   A logical load balancer object is a great demarcation point 

Re: [openstack-dev] [Neutron] [LBaaS][VPN][Barbican] SSL cert implementation for LBaaS and VPN

[Samuel Bercovici]

Hi,

Please note as commented also by other XaaS services that managing SSL 
certificates is not a sole LBaaS challenge.
This calls for either an OpenStack wide service or at least a Neutron wide 
service to implement such use cases.

So it here are the options as far as I have seen so far.

1.   Barbican as a central service to store and retrieve SSL certificates. 
I think the Certificates generation is currently a lower priority requirement

2.   Using Heat as a centralized service

3.   Implementing such service in Neutron

4.   LBaaS private implementation

BTW, on all the options above, Barbican can optionally be used to store the 
certificates or the private part of the certificates.

I think that we either follow option 3 if SSL management is only a Neutron 
requirement (LBaaS, VPNaaS, FWaaS) and maybe as a transition project to an 
OpenStack wide solution (1 or 2).
Option 1 or 2 might be the ultimate goal.

Regards,
-Sam.





From: Clark, Robert Graham [mailto:robert.cl...@hp.com]
Sent: Thursday, May 08, 2014 12:43 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron] [LBaaS][VPN][Barbican] SSL cert 
implementation for LBaaS and VPN

The certificate management that LBaaS requires might be slightly different to 
the normal flow of things in OpenStack services, after all you are talking 
about externally provided certificates and private keys.

There's already a standard for a nice way to bundle those two elements 
together, it's described in PKCS#12 and you've likely come across it in the 
form of '.pfx' files. I'd suggest that perhaps it would make sense for LBaaS to 
store pfx files in the LBaaS DB and store the key for the pfx files in 
Barbican. You could probably store them together in Barbican, using containers 
if you really wanted to 
(https://blueprints.launchpad.net/barbican/+spec/crud-endpoints-secret-container)

-Rob

From: Carlos Garza [mailto:carlos.ga...@rackspace.com]
Sent: 08 May 2014 04:30
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron] [LBaaS][VPN][Barbican] SSL cert 
implementation for LBaaS and VPN


On May 7, 2014, at 10:53 AM, Samuel Bercovici 
samu...@radware.commailto:samu...@radware.com wrote:

Hi John,

If the user already has an SSL certificate that was acquired outside of the 
barbican Ordering system, how can he store it securely in Barbican as a SSL 
Certificate?
The Container stored this information in a very generic way, I think that there 
should be an API that formalizes a specific way in which SSL certificates can 
be stored and read back as SSL Certificates and not as loosely coupled 
container structure.
This such API should have RBAC that allows getting back only the public part of 
an SSL certificate vs. allowing to get back all the details of the SSL 
certificate.

Why the need for that complexity? The X509s are public by nature and don't 
need to be stored in Barbican so there isn't really a private part of the 
certificate. The actual private key itself is what needs to be secured so I 
would advocate that the private key is what will be stored in barbican. I also 
think we should also declare that the private key need not be an RSA key as 
x509 supports other asymmetric encryption types so storing as a generic blob in 
barbican is probably a good idea.





-Sam.



From: John Wood [mailto:john.w...@rackspace.comhttp://RACKSPACE.COM]
Sent: Thursday, May 01, 2014 11:28 PM
To: OpenStack Development Mailing List (not for usage questions); 
os.v...@gmail.commailto:os.v...@gmail.com
Subject: Re: [openstack-dev] [Neutron] [LBaaS][VPN][Barbican] SSL cert 
implementation for LBaaS and VPN

Hello Samuel,

Just noting that the link below shows current-state Barbican. We are in the 
process of designing SSL certificate support for Barbican via blueprints such 
as this one: 
https://wiki.openstack.org/wiki/Barbican/Blueprints/ssl-certificates
We intend to discuss this feature in Atlanta to enable coding in earnest for 
Juno.

The Container resource is intended to capture/store the final certificate 
details.

Thanks,
John



From: Samuel Bercovici [samu...@radware.commailto:samu...@radware.com]
Sent: Thursday, May 01, 2014 12:50 PM
To: OpenStack Development Mailing List (not for usage questions); 
os.v...@gmail.commailto:os.v...@gmail.com
Subject: Re: [openstack-dev] [Neutron] [LBaaS][VPN][Barbican] SSL cert 
implementation for LBaaS and VPN
Hi Vijay,

I have looked at the Barbican APIs 
-https://github.com/cloudkeep/barbican/wiki/Application-Programming-Interface
I was no able to see a native API that will accept an SSL certificate 
(private key, public key, CSR, etc.) and will store it.
We can either store the whole certificate as a single file as a secret or use a 
container and store all the certificate parts as secrets.

I think that having LBaaS reference Certificates as IDs using some

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

[Samuel Bercovici]

The survey is not anonymous and I plan to publish it with its raw data we can 
then discuss how to interpret.
Each use case has an accompanying text field so that you can add any comments 
you wish.
At least I did add comments to most use cases when I responded :-)


-Sam.


-Original Message-
From: Jorge Miramontes [mailto:jorge.miramon...@rackspace.com] 
Sent: Tuesday, May 06, 2014 10:16 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron][LBaaS]User Stories and sruvey

I agree that everyone's thoughts should be in it. I don't see why a 
representative vote does not allow for that. Sam put a text box on each use 
case to capture extra thoughts.

I would hope that no organization would be so confused as to have widely 
varying viewpoints on *what their customers want*, since that is the supposed 
purpose of all of this, right? We're supposed to be deciding which use-cases 
matter *to our customers*, so there should be no real variance for what I would 
vote versus what my teammates would vote, since we have the same customersŠ


Also, if we are using this as a type of voting mechanism then interests of 
large/vocal organizations drown out smaller organizations. If this is being 
used as a voting mechanism then how do you suggest we weight votes for smaller 
companies so that we do not alienate them from further voting/discussions?

Cheers,
--Jorge




On 5/6/14 1:52 PM, Jay Pipes jaypi...@gmail.com wrote:

On 05/06/2014 02:42 PM, Jorge Miramontes wrote:
 Sam,

 I'm assuming you want one person from each company to answer correct?
 I'm pretty sure people in each organization will vote the sameŠat 
 least I'd hope!

I'd hope not! :)

Even within the same organization or company, we all have different 
ideas on use cases, the appropriateness of certain things in the 
cloud, and the role of a load balancer service in the general mix of 
things.

I certainly would hope that lots of Mirantis engineers other than 
myself fill out the use case survey and offer their own insights.

Best,
-jay

___
OpenStack-dev mailing list
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

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

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

[Samuel Bercovici]

Jorge,

It's your call. I prefer to gather information for now, if multiple people from 
the same organization will have drastically different answers, than this should 
also be considered.

-Sam.


From: Jorge Miramontes [mailto:jorge.miramon...@rackspace.com]
Sent: Tuesday, May 06, 2014 9:42 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron][LBaaS]User Stories and sruvey

Sam,

I'm assuming you want one person from each company to answer correct? I'm 
pretty sure people in each organization will vote the same...at least I'd hope!

Cheers,
--Jorge

From: Samuel Bercovici samu...@radware.commailto:samu...@radware.com
Reply-To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Date: Tuesday, May 6, 2014 2:56 AM
To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [Neutron][LBaaS]User Stories and sruvey

Hi Everyone,

The survey is now live via: http://eSurv.org?u=lbaas_project_user
The password is: lbaas

The survey includes all the tenant facing use cases from 
https://docs.google.com/document/d/1Ewl95yxAMq2fO0Z6Dz6fL-w2FScERQXQR1-mXuSINis/edit?usp=sharing
Please try and fill the survey this week so we can have enough information to 
base decisions next week.

Regards,
-Sam.



From: Samuel Bercovici
Sent: Monday, May 05, 2014 4:52 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron][LBaaS]User Stories and sruvey

Hi,

I will not freeze the document to allow people to work on requirements which 
are not tenant facing (ex: operator, etc.)
I think that we have enough use cases for tenant facing capabilities to reflect 
most common use cases.
I am in the process of creation a survey in surveymonkey for tenant facing use 
cases and hope to send it to ML ASAP.

Regards,
-Sam.


From: Samuel Bercovici
Sent: Thursday, May 01, 2014 8:40 PM
To: OpenStack Development Mailing List (not for usage questions)
Cc: Samuel Bercovici
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
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron][LBaaS][FWaaS][VPNaaS] Advanced Services (particularly LBaaS) and Neutron

[Samuel Bercovici]

Hi,
I have added to https://etherpad.openstack.org/p/AdvancedServices_and_Neutron a 
note recalling two  technical challenges that do not exists when LBaaS runs as 
a Neutron extension.
-Sam.


From: Susanne Balle [mailto:sleipnir...@gmail.com]
Sent: Wednesday, May 07, 2014 2:45 PM
To: OpenStack Development Mailing List (not for usage questions)
Cc: Balle, Susanne
Subject: [openstack-dev] [Neutron][LBaaS][FWaaS][VPNaaS] Advanced Services 
(particularly LBaaS) and Neutron

Hi Advanced Services/LBaaS Stackers,

We are setting up a meeting to discuss if it makes sense to separate the 
advanced services (LBaaS, FW, VPNaaS) from Neutron into separate projects. We 
want a healthy discussion around  the pros and cons of separating the advanced 
services from Neutron and its short or long term feasibility.

The meeting is planned for:
Tuesday May 13th at 2pm in the Neutron pod.

There will be a designated pod for each of the official programs at: 
https://wiki.openstack.org/wiki/Programs
Some programs share a pod. There will be a map at the center of the space, as 
well as signage up to help find the relevant pod.

Based on discussions with Rackspace, Mirantis, and others it is clear that the 
advanced services (i.e. LBaaS) in Neutron are not getting the attention and the 
support to move forward and create a first in class load-balancer service; from 
a service provider or operator's perspective. We currently have a lot of 
momentum and energy behind the LBaaS effort but are being told that the focus 
for Neutron is bug fixing given the instability in Neutron itself. While the 
latter is totally understandable, as a high priority for Neutron it leaves the 
advanced services out in the cold with no way to make progress in developing 
features that are needed to support the many companies that rely on LBaaS for 
large scale deployments.

The current Neutron LB API and feature set meet minimum requirements for 
small-medium private cloud deployments, but does not meet the needs of larger, 
provider (or operator) deployments that include hundreds if not thousands of 
load balancers and multiple domain users (discrete customer organizations). The 
OpenStack LBaaS community looked at requirements and noted that the following 
operator-focused requirements are currently missing:

• Scalability
• SSL Certificate management – for an operator-based service, SSL 
certificate management is a much more important function that is currently not 
addressed in the current API or blueprint
• Metrics Collection – a very limited set of metrics are currently 
provided by the current API.
• Separate admin API for NOC and support operations
• Minimal downtime when migrating to newer versions
• Ability to migrate load balancers (SW to HW, etc.)
• Resiliency functions like HA and failover
• Operator-based load balancer health checks
• Support multiple, simultaneous drivers.

We have had great discussions on the LBaaS mailing list and on IRC about all 
the things we want to do, the new APIs, the User use cases, requirements and 
priorities, the operator requirements for LBaaS, etc. and I am at this point 
wondering if Neutron LBaaS as a sub-project of Neutron can fulfill our 
requirements.

I would like this group to discuss the pros and cons of separating the advanced 
services, including LB, VPN, and FW, out of Neutron and allow for each of the 
three currently existing advanced services to become stand-alone projects or 
one standalone project.

This should be done under the following assumptions:
• Keep backwards compatibility with the current Neutron LBaaS 
plugin/driver API (to some point) so that existing drivers/plug-ins continues 
to work for people who have already invested in Neutron LBaaS
• Migration strategy.

We have a precedence in OpenStack of splitting up services that are becoming 
too big or where sub-services deserve to become an entity of its own e.g. 
baremetal Nova and Ironic, Nova-network and Neutron, nova-scheduler is being 
worked into the Gantt project, etc.

At a high-level I see the following steps/blueprints needing to be carried out:
• Identify and create a library similar in concept to OpenStack core 
that contains the common components pieces needed by the advanced services in 
order to minimize code duplication between the advanced services and Neutron. 
This library should be consumable by external projects and will allow for 
cleaner code reuse by not only the three existing advanced services but by new 
services as well.
• Start a new repo for the standalone LBaaS
o   http://git.openstack.org/cgit/openstack-dev/cookiecutter/tree/
• Write a patch to bridge Neutron LBaaS with the standalone LBaaS for 
backwards compatibility. Longer term we can deprecate Neutron LBaaS  which will 
be possible once the new LBaaS service is a graduated OpenStack service.

Some of the background 

Re: [openstack-dev] [Neutron] [LBaaS][VPN][Barbican] SSL cert implementation for LBaaS and VPN

[Samuel Bercovici]

Hi John,

If the user already has an SSL certificate that was acquired outside of the 
barbican Ordering system, how can he store it securely in Barbican as a SSL 
Certificate?
The Container stored this information in a very generic way, I think that there 
should be an API that formalizes a specific way in which SSL certificates can 
be stored and read back as SSL Certificates and not as loosely coupled 
container structure.
This such API should have RBAC that allows getting back only the public part of 
an SSL certificate vs. allowing to get back all the details of the SSL 
certificate.



-Sam.



From: John Wood [mailto:john.w...@rackspace.com]
Sent: Thursday, May 01, 2014 11:28 PM
To: OpenStack Development Mailing List (not for usage questions); 
os.v...@gmail.com
Subject: Re: [openstack-dev] [Neutron] [LBaaS][VPN][Barbican] SSL cert 
implementation for LBaaS and VPN

Hello Samuel,

Just noting that the link below shows current-state Barbican. We are in the 
process of designing SSL certificate support for Barbican via blueprints such 
as this one: 
https://wiki.openstack.org/wiki/Barbican/Blueprints/ssl-certificates
We intend to discuss this feature in Atlanta to enable coding in earnest for 
Juno.

The Container resource is intended to capture/store the final certificate 
details.

Thanks,
John



From: Samuel Bercovici [samu...@radware.com]
Sent: Thursday, May 01, 2014 12:50 PM
To: OpenStack Development Mailing List (not for usage questions); 
os.v...@gmail.commailto:os.v...@gmail.com
Subject: Re: [openstack-dev] [Neutron] [LBaaS][VPN][Barbican] SSL cert 
implementation for LBaaS and VPN
Hi Vijay,

I have looked at the Barbican APIs - 
https://github.com/cloudkeep/barbican/wiki/Application-Programming-Interface
I was no able to see a native API that will accept an SSL certificate 
(private key, public key, CSR, etc.) and will store it.
We can either store the whole certificate as a single file as a secret or use a 
container and store all the certificate parts as secrets.

I think that having LBaaS reference Certificates as IDs using some service is 
the right way to go so this might be achived by either:

1.   Adding to Barbican and API to store / generate certificates

2.   Create a new module that might start by being hosted in neutron or 
keystone that will allow to manage certificates and will use Barbican behind 
the scenes to store them.

3.   Decide on a container structure to use in Babican but implement the 
way to access and arrange it as a neutron library

Was any decision made on how to proceed?

Regards,
-Sam.




From: Vijay B [mailto:os.v...@gmail.com]
Sent: Wednesday, April 30, 2014 3:24 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [Neutron] [LBaaS][VPN] SSL cert implementation for 
LBaaS and VPN

Hi,

It looks like there are areas of common effort in multiple efforts that are 
proceeding in parallel to implement SSL for LBaaS as well as VPN SSL in neutron.

Two relevant efforts are listed below:


https://review.openstack.org/#/c/74031/   
(https://wiki.openstack.org/wiki/Neutron/LBaaS/SSL)

https://review.openstack.org/#/c/58897/   
(https://blueprints.launchpad.net/openstack/?searchtext=neutron-ssl-vpn)



Both VPN and LBaaS will use SSL certificates and keys, and this makes it better 
to implement SSL entities as first class citizens in the OS world. So, three 
points need to be discussed here:

1. The VPN SSL implementation above is putting the SSL cert content in a 
mapping table, instead of maintaining certs separately and referencing them 
using IDs. The LBaaS implementation stores certificates in a separate table, 
but implements the necessary extensions and logic under LBaaS. We propose that 
both these implementations move away from this and refer to SSL entities using 
IDs, and that the SSL entities themselves are implemented as their own 
resources, serviced either by a core plugin or a new SSL plugin (assuming 
neutron; please also see point 3 below).

2. The actual data store where the certs and keys are stored should be 
configurable at least globally, such that the SSL plugin code will singularly 
refer to that store alone when working with the SSL entities. The data store 
candidates currently are Barbican and a sql db. Each should have a separate 
backend driver, along with the required config values. If further evaluation of 
Barbican shows that it fits all SSL needs, we should make it a priority over a 
sqldb driver.

3. Where should the primary entries for the SSL entities be stored? While the 
actual certs themselves will reside on Barbican or SQLdb, the entities 
themselves are currently being implemented in Neutron since they are being 
used/referenced there. However, we feel that implementing them in keystone 
would be most appropriate. We could also follow a federated model where a 
subset of keys can reside on another service such as Neutron. We

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

[Samuel Bercovici]

6 people have completed the survey so far.


From: Samuel Bercovici
Sent: Tuesday, May 06, 2014 10:56 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron][LBaaS]User Stories and sruvey

Hi Everyone,

The survey is now live via: http://eSurv.org?u=lbaas_project_user
The password is: lbaas

The survey includes all the tenant facing use cases from 
https://docs.google.com/document/d/1Ewl95yxAMq2fO0Z6Dz6fL-w2FScERQXQR1-mXuSINis/edit?usp=sharing
Please try and fill the survey this week so we can have enough information to 
base decisions next week.

Regards,
-Sam.



From: Samuel Bercovici
Sent: Monday, May 05, 2014 4:52 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron][LBaaS]User Stories and sruvey

Hi,

I will not freeze the document to allow people to work on requirements which 
are not tenant facing (ex: operator, etc.)
I think that we have enough use cases for tenant facing capabilities to reflect 
most common use cases.
I am in the process of creation a survey in surveymonkey for tenant facing use 
cases and hope to send it to ML ASAP.

Regards,
-Sam.


From: Samuel Bercovici
Sent: Thursday, May 01, 2014 8:40 PM
To: OpenStack Development Mailing List (not for usage questions)
Cc: Samuel Bercovici
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
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Samuel Bercovici]

Hi Everyone,

The survey is now live via: http://eSurv.org?u=lbaas_project_user
The password is: lbaas

The survey includes all the tenant facing use cases from 
https://docs.google.com/document/d/1Ewl95yxAMq2fO0Z6Dz6fL-w2FScERQXQR1-mXuSINis/edit?usp=sharing
Please try and fill the survey this week so we can have enough information to 
base decisions next week.

Regards,
-Sam.



From: Samuel Bercovici
Sent: Monday, May 05, 2014 4:52 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron][LBaaS]User Stories and sruvey

Hi,

I will not freeze the document to allow people to work on requirements which 
are not tenant facing (ex: operator, etc.)
I think that we have enough use cases for tenant facing capabilities to reflect 
most common use cases.
I am in the process of creation a survey in surveymonkey for tenant facing use 
cases and hope to send it to ML ASAP.

Regards,
-Sam.


From: Samuel Bercovici
Sent: Thursday, May 01, 2014 8:40 PM
To: OpenStack Development Mailing List (not for usage questions)
Cc: Samuel Bercovici
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
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron][LBaaS]L7 conent switching APIs

[Samuel Bercovici]

Hi Stephen,

For Icehouse we did not go into L7 content modification as the general feeling 
was that it might not be exactly the same as content switching and we wanted to 
tackle content switching fiest.

L7 content switching and L7 content modification are different, I prefer to be 
explicit and declarative and use different objects.
This will make the API more readable.
What do you think?

I plan to look deeper into L7 content modification later this week to propose a 
list of capabilities.

-Sam.


From: Stephen Balukoff [mailto:sbaluk...@bluebox.net]
Sent: Saturday, May 03, 2014 1:33 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron][LBaaS]L7 conent switching APIs

Hi Adam and Samuel!

Thanks for the questions / comments! Reactions in-line:

On Thu, May 1, 2014 at 8:14 PM, Adam Harwell 
adam.harw...@rackspace.commailto:adam.harw...@rackspace.com wrote:
Stephen, the way I understood your API proposal, I thought you could 
essentially combine L7Rules in an L7Policy, and have multiple L7Policies, 
implying that the L7Rules would use AND style combination, while the L7Policies 
themselves would use OR combination (I think I said that right, almost seems 
like a tongue-twister while I'm running on pure caffeine). So, if I said:

Well, my goal wasn't to create a whole DSL for this (or anything much 
resembling this) because:

  1.  Real-world usage of the L7 stuff is generally pretty primitive. Most 
L7Policies will consist of 1 rule. Those that consist of more than one rule are 
almost always the sort that need a simple sort. This is based off the usage 
data collected here (which admittedly only has Blue Box's data-- because 
apparently nobody else even offers L7 right now?)  
https://docs.google.com/spreadsheet/ccc?key=0Ar1FuMFYRhgadDVXZ25NM2NfbGtLTkR0TDFNUWJQUWcusp=sharing
  2.  I was trying to keep things as simple as possible to make it easier for 
load balancer vendors to support. (That is to say, I wouldn't expect all 
vendors to provide the same kind of functionality as HAProxy ACLs, for example.)
Having said this, I think yours and Sam's clarification that different 
L7Policies can be used to effective OR conditions together makes sense, and 
therefore assuming all the Rules in a given policy are ANDed together makes 
sense.

If we do this, it therefore also might make sense to expose other criteria on 
which L7Rules can be made, like HTTP method used for the request and whatnot.

Also, should we introduce a flag to say whether a given Rule's condition should 
be negated?  (eg. HTTP method is GET and URL is *not* /api) This would get 
us closer to being able to use more sophisticated logic for L7 routing.

Does anyone foresee the need to offer this kind of functionality?

 * The policy { rules: [ rule1: match path REGEX .*index.*, rule2: match path 
REGEX hello/.* ] } directs to Pool A
 * The policy { rules: [ rule1: match hostname EQ 
mysite.comhttp://mysite.com ] } directs to Pool B
then order would matter for the policies themselves. In this case, if they ran 
in the order I listed, it would match 
mysite.com/hello/index.htmhttp://mysite.com/hello/index.htm and direct it 
to Pool A, while mysite.com/hello/nope.htmhttp://mysite.com/hello/nope.htm 
would not match BOTH rules in the first policy, and would be caught by the 
second policy, directing it to Pool B. If I had wanted the first policy to use 
OR logic, I would have just specified two separate policies both pointing to 
Pool A:

Clarification on this: There is an 'order' attribute to L7Policies. :) But 
again, if all the L7Rules in a given policy are ANDed together, then order 
doesn't matter within the rules that make up an L7Policy.

 * The policy { rules: [ rule1: match path REGEX .*index.* ] } directs to 
Pool A
 * The policy { rules: [ rule1: match path REGEX hello/.* ] } directs to Pool 
A
 * The policy { rules: [ rule1: match hostname EQ 
mysite.comhttp://mysite.com ] } directs to Pool B
In that case, it would match 
mysite.com/hello/nope.htmhttp://mysite.com/hello/nope.htm on the second 
policy, still directing to Pool A.
In both cases, mysite.com/hi/http://mysite.com/hi/ would only be caught by 
the last policy, directing to Pool B.
Maybe I was making some crazy jumps of logic, and that's not how you intended 
it? That said, even if that wasn't your intention, could it work that way? It 
seems like that allows a decent amount of options… :)

 --Adam



 On Fri, May 2, 2014 at 4:59 AM, Samuel Bercovici 
samu...@radware.commailto:samu...@radware.com wrote:
Adam, you are correct to show why order matters in policies.
It is a good point to consider AND between rules.
If you really want to OR rules you can use different policies.

Stephen, the need for order contradicts using content modification with the 
same API since for modification you would really want to evaluate the whole 
list.

Hi Sam, I was a bit confused on this point since we don't see users often using 
both

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

[Samuel Bercovici]

Hi,

I will not freeze the document to allow people to work on requirements which 
are not tenant facing (ex: operator, etc.)
I think that we have enough use cases for tenant facing capabilities to reflect 
most common use cases.
I am in the process of creation a survey in surveymonkey for tenant facing use 
cases and hope to send it to ML ASAP.

Regards,
-Sam.


From: Samuel Bercovici
Sent: Thursday, May 01, 2014 8:40 PM
To: OpenStack Development Mailing List (not for usage questions)
Cc: Samuel Bercovici
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
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron][LBaaS] Use-Cases with VPNs Distinction

[Samuel Bercovici]

I think that associating a VIP subnet and list of member subnets is a good 
choice.
This is declaratively saying to where is the configuration expecting layer 2 
proximity.
The minimal would be the VIP subnet which in essence means the VIP and members 
are expected on the same subnet.

Any member outside the specified subnets is supposedly accessible via routing.

It might be an option to state the static route to use to access such member(s).
On many cases the needed static routes could also be computed automatically.

Regards,
   -Sam.

On 2 במאי 2014, at 03:50, Stephen Balukoff 
sbaluk...@bluebox.netmailto:sbaluk...@bluebox.net wrote:

Hi Trevor,

I was the one who wrote that use case based on discussion that came out of the 
question I wrote the list last week about SSL re-encryption:  Someone had 
stated that sometimes pool members are local, and sometimes they are hosts 
across the internet, accessible either through the usual default route, or via 
a VPN tunnel.

The point of this use case is to make the distinction that if we associate a 
neutron_subnet with the pool (rather than with the member), then some members 
of the pool that don't exist in that neutron_subnet might not be accessible 
from that neutron_subnet.  However, if the behavior of the system is such that 
attempting to reach a host through the subnet's default route still works 
(whether that leads to communication over a VPN or the usual internet routes), 
then this might not be a problem.

The other option is to associate the neutron_subnet with a pool member. But in 
this case there might be problems too. Namely:

  *   The device or software that does the load balancing may need to have an 
interface on each of the member subnets, and presumably an IP address from 
which to originate requests.
  *   How does one resolve cases where subnets have overlapping IP ranges?

In the end, it may be simpler not to associate neutron_subnet with a pool at 
all. Maybe it only makes sense to do this for a VIP, and then the assumption 
would be that any member addresses one adds to pools must be accessible from 
the VIP subnet.  (Which is easy, if the VIP exists on the same neutron_subnet. 
But this might require special routing within Neutron itself if it doesn't.)

This topology question (ie. what is feasible, what do people actually want to 
do, and what is supported by the model) is one of the more difficult ones to 
answer, especially given that users of OpenStack that I've come in contact with 
barely understand the Neutron networking model, if at all.

In our case, we don't actually have any users in the scenario of having members 
spread across different subnets that might not be be routable, so the use case 
is somewhat contrived, but I thought it was worth mentioning based on what 
people were saying in the SSL re-encryption discussion last week.


On Thu, May 1, 2014 at 1:52 PM, Trevor Vardeman 
trevor.varde...@rackspace.commailto:trevor.varde...@rackspace.com wrote:
Hello,

After going back through the use-cases to double check some of my
understanding, I realized I didn't quite understand the ones I had
already answered.  I'll use a specific use-case as an example of my
misunderstanding here, and hopefully the clarification can be easily
adapted to the rest of the use-cases that are similar.

Use Case 13:  A project-user has an HTTPS application in which some of
the back-end servers serving this application are in the same subnet,
and others are across the internet, accessible via VPN. He wants this
HTTPS application to be available to web clients via a single IP
address.

In this use-case, is the Load Balancer going to act as a node in the
VPN?  What I mean here, is the Load Balancer supposed to establish a
connection to this VPN for the client, and simulate itself as a computer
on the VPN?  If this is not the case, wouldn't the VPN have a subnet ID,
and simply be added to a pool during its creation?  If the latter is
accurate, would this not just be a basic HTTPS Load Balancer creation?
After looking through the VPNaaS API, you would provide a subnet ID to
the create VPN service request, and it establishes a VPN on said subnet.
Couldn't this be provided to the Load Balancer pool as its subnet?

Forgive me for requiring so much distinction here, but what may be clear
to the creator of this use-case, it has left me confused.  This same
type of clarity would be very helpful across many of the other
VPN-related use-cases.  Thanks again!

-Trevor
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.orgmailto: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.orgmailto:OpenStack-dev@lists.openstack.org

Re: [openstack-dev] [Neutron][LBaaS]L7 conent switching APIs

[Samuel Bercovici]

Adam, you are correct to show why order matters in policies.
It is a good point to consider AND between rules.
If you really want to OR rules you can use different policies.

Stephen, the need for order contradicts using content modification with the 
same API since for modification you would really want to evaluate the whole 
list.

Regards,
   -Sam.

On 2 במאי 2014, at 06:15, Adam Harwell 
adam.harw...@rackspace.commailto:adam.harw...@rackspace.com wrote:

My thoughts are inline (in red, since I can't figure out how to get Outlook to 
properly format the email the way I want).

From: Stephen Balukoff sbaluk...@bluebox.netmailto:sbaluk...@bluebox.net
Reply-To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Date: Thursday, May 1, 2014 6:52 PM
To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [Neutron][LBaaS]L7 conent switching APIs

Hi Samuel,

We talked a bit in chat about this, but I wanted to reiterate a few things here 
for the rest of the group.  Comments in-line:


On Wed, Apr 30, 2014 at 6:10 AM, Samuel Bercovici 
samu...@radware.commailto:samu...@radware.com wrote:
Hi,

We have compared the API the is in the blue print to the one described in 
Stephen documents.
Follows the differences we have found:

1)  L7PolicyVipAssoc is gone, this means that L7 policy reuse is not 
possible. I have added use cases 42 and 43 to show where such reuse makes sense.

Yep, my thoughts were that:

  *   The number of times L7 policies will actually get re-used is pretty 
minimal. And in the case of use cases 42 and 43, these can be accomplished by 
duplicating the L7policies and rules (with differing actions) for each type of 
connection.
  *   Fewer new objects is usually better and less confusing for the user. 
Having said this, a user advanced enough to use L7 features like this at all is 
likely going to be able to understand what the 'association' policy does.

The main counterpoint you shared with me was (if I remember correctly):

  *   For different load balancer vendors, it's much easier to code for the 
case where a specific entire feature set that isn't available (ie. L7 switching 
or content modification functionality) by making that entire feature set 
modular. A driver in this case can simply return with a feature not supported 
error if anyone tries using L7 policies at all.

 I agree that re-use should not be required for L7 policies, which should 
simplify things.

2)  There is a mix between L7 content switching and L7 content 
modification, the API in the blue print only addresses L7 content switching. I 
think that we should separate the APIs from each other. I think that we should 
review/add use cases targeting L7 content modifications to the use cases 
document.

Fair enough. There aren't many such use cases in there yet.

a.   You can see this in L7Policy: APPEND_HEADER, DELETE_HEADER 
actions

3)  The action to redirect to a URL is missing in Stephen’s document. The 
'redirect' action in Stephen’s document is equivalent to the “pool” action in 
the blue print/code.

Yep it is. But this is actually pretty easily added.  We would just add the 
'action' of URL_REDIRECT and the action_argument would then be the URL to 
which to redirect.


4)  All the objects have their parent id as an optional argument 
(L7Rule.l7_policy_id, L7Policy.listener_id), is this a mistake?

That's actually not a mistake--  a user can create orphaned rules in this 
model. However, the point was raised earlier by Brandon that it may make sense 
for members to be child objects of a specific pool since they can't be shared. 
If we do this for members, it also makes sense to do it for L7Rules since they 
also can't be shared. At which point the API for manipulating L7Rules would 
shift to:

/l7_policy/{policy_uuid}/l7_rules

And in this case, the parent L7Policy ID would be implicit.

(I'm all for this change, by the way.)

Sounds good to me too!

5)  There is also the additional behavior based on L3 information (matching 
the client/source IP to a subnet). This is addressed by L7Rule.type with a 
value of 'CLIENT_IP' and L7Rule.compare_type with a value of 'SUBNET'. I think 
that using Layer 3 type information should not be part of L7 content switching 
as the use cases I am aware of, might require more than just selecting a 
different pool (ex: user with ip from internet browsing to an https based 
application, might need to be secured using 2K SSL keys while internal users 
could use weaker keys)

While it's true that having a way to manipulate this without being part of an 
HTTP or unwrapped HTTPS session is also useful--  it's still useful to be able 
to create L7 rules which also make decisions based on subnet.  (Notice also 
with TLS_SNI_Policies

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

[Samuel Bercovici]

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
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] [LBaaS][VPN][Barbican] SSL cert implementation for LBaaS and VPN

[Samuel Bercovici]

Hi Vijay,

I have looked at the Barbican APIs – 
https://github.com/cloudkeep/barbican/wiki/Application-Programming-Interface
I was no able to see a “native” API that will accept an SSL certificate 
(private key, public key, CSR, etc.) and will store it.
We can either store the whole certificate as a single file as a secret or use a 
container and store all the certificate parts as secrets.

I think that having LBaaS reference Certificates as IDs using some service is 
the right way to go so this might be achived by either:

1.   Adding to Barbican and API to store / generate certificates

2.   Create a new “module” that might start by being hosted in neutron or 
keystone that will allow to manage certificates and will use Barbican behind 
the scenes to store them.

3.   Decide on a container structure to use in Babican but implement the 
way to access and arrange it as a neutron library

Was any decision made on how to proceed?

Regards,
-Sam.




From: Vijay B [mailto:os.v...@gmail.com]
Sent: Wednesday, April 30, 2014 3:24 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [Neutron] [LBaaS][VPN] SSL cert implementation for 
LBaaS and VPN

Hi,

It looks like there are areas of common effort in multiple efforts that are 
proceeding in parallel to implement SSL for LBaaS as well as VPN SSL in neutron.

Two relevant efforts are listed below:


https://review.openstack.org/#/c/74031/   
(https://wiki.openstack.org/wiki/Neutron/LBaaS/SSL)

https://review.openstack.org/#/c/58897/   
(https://blueprints.launchpad.net/openstack/?searchtext=neutron-ssl-vpn)



Both VPN and LBaaS will use SSL certificates and keys, and this makes it better 
to implement SSL entities as first class citizens in the OS world. So, three 
points need to be discussed here:

1. The VPN SSL implementation above is putting the SSL cert content in a 
mapping table, instead of maintaining certs separately and referencing them 
using IDs. The LBaaS implementation stores certificates in a separate table, 
but implements the necessary extensions and logic under LBaaS. We propose that 
both these implementations move away from this and refer to SSL entities using 
IDs, and that the SSL entities themselves are implemented as their own 
resources, serviced either by a core plugin or a new SSL plugin (assuming 
neutron; please also see point 3 below).

2. The actual data store where the certs and keys are stored should be 
configurable at least globally, such that the SSL plugin code will singularly 
refer to that store alone when working with the SSL entities. The data store 
candidates currently are Barbican and a sql db. Each should have a separate 
backend driver, along with the required config values. If further evaluation of 
Barbican shows that it fits all SSL needs, we should make it a priority over a 
sqldb driver.

3. Where should the primary entries for the SSL entities be stored? While the 
actual certs themselves will reside on Barbican or SQLdb, the entities 
themselves are currently being implemented in Neutron since they are being 
used/referenced there. However, we feel that implementing them in keystone 
would be most appropriate. We could also follow a federated model where a 
subset of keys can reside on another service such as Neutron. We are fine with 
starting an initial implementation in neutron, in a modular manner, and move it 
later to keystone.


Please provide your inputs on this.


Thanks,
Regards,
Vijay
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron][LBaaS]L7 conent switching APIs

[Samuel Bercovici]

Hi,

We have compared the API the is in the blue print to the one described in 
Stephen documents.
Follows the differences we have found:

1)  L7PolicyVipAssoc is gone, this means that L7 policy reuse is not 
possible. I have added use cases 42 and 43 to show where such reuse makes sense.

2)  There is a mix between L7 content switching and L7 content 
modification, the API in the blue print only addresses L7 content switching. I 
think that we should separate the APIs from each other. I think that we should 
review/add use cases targeting L7 content modifications to the use cases 
document.

a.   You can see this in L7Policy: APPEND_HEADER, DELETE_HEADER 
actions

3)  The action to redirect to a URL is missing in Stephen’s document. The 
'redirect' action in Stephen’s document is equivalent to the “pool” action in 
the blue print/code.

4)  All the objects have their parent id as an optional argument 
(L7Rule.l7_policy_id, L7Policy.listener_id), is this a mistake?

5)  There is also the additional behavior based on L3 information (matching 
the client/source IP to a subnet). This is addressed by L7Rule.type with a 
value of 'CLIENT_IP' and L7Rule.compare_type with a value of 'SUBNET'. I think 
that using Layer 3 type information should not be part of L7 content switching 
as the use cases I am aware of, might require more than just selecting a 
different pool (ex: user with ip from internet browsing to an https based 
application, might need to be secured using 2K SSL keys while internal users 
could use weaker keys)

I would like to state that although the WIKI describes the solution from a high 
level it is not totally in sync with the actual code.
The key thing which is missing is that, L7 Policies in a specific listener/vip 
are ordered (ordered list) and are processed in order so that the 1st policy 
that has a match will be activated and traversal of the L7 policy list is 
topped as the processing is final (ex: redirect, pool, reject).
This in effect means that L7 Policy form an ‘or’ condition between them.
L7 Policies have an ordered list of L7 Rules, L7 Rules are processed by this 
order and also form an ‘or’ condition.

Regards,
-Avishay, Evgeny and Sam



From: Samuel Bercovici [mailto:samu...@radware.com]
Sent: Sunday, April 27, 2014 1:53 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron][LBaaS]SSL and L7 conent switching APIs

Hi,

The work to design the APIs concerning L7 content switching and SSL termination 
has started a bit before the Icehouse summit, it involved the ML in a very 
active fashion.
The ML was silent on this because we have completed the discussion and moved to 
implementation.
We got to a very advanced state in completing the code which got stopped due to 
the discussion about the core model (VIPs, Pools, etc.)
The blue prints WIKIs and code are public 
(https://blueprints.launchpad.net/neutron/+spec/lbaas-l7-rules and 
https://blueprints.launchpad.net/neutron/+spec/lbaas-ssl-termination ).
Please take the time to review and discuss on ML if something is missing so we 
can talk about this at the summit.

-Sam.


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

Re: [openstack-dev] [Neutron][LBaaS] BBG edit of new API proposal

[Samuel Bercovici]

I have seen many use casses added lately with me also adding additional 2 for 
L7 and will probably add a few more tomorrow for SSL termination

-Original Message-
From: Eichberger, German [mailto:german.eichber...@hp.com] 
Sent: Tuesday, April 29, 2014 12:12 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron][LBaaS] BBG edit of new API proposal

Sam,

The use cases where pretty complete the last time I checked so let's move them 
to gerrit so we can all vote.

Echoing Kyle I would love to see us focusing on getting things ready for the 
summit. 

German

-Original Message-
From: Samuel Bercovici [mailto:samu...@radware.com]
Sent: Monday, April 28, 2014 11:44 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron][LBaaS] BBG edit of new API proposal

Hi,

I was just working to push the use cases into the new format .rst but I agree 
that using google doc would be more intuitive.
Let me know what you prefer to do with the use cases document:
1. leave it at google docs at - 
https://docs.google.com/document/d/1Ewl95yxAMq2fO0Z6Dz6fL-w2FScERQXQR1-mXuSINis/edit?pli=1
2. Move it to the new format under - 
http://git.openstack.org/cgit/openstack/neutron-specs, I have already files a 
blue print https://blueprints.launchpad.net/neutron/+spec/lbaas-use-cases and 
can complete the .rst process by tomorrow.

Regards,
-Sam.






-Original Message-
From: Kyle Mestery [mailto:mest...@noironetworks.com]
Sent: Monday, April 28, 2014 4:33 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron][LBaaS] BBG edit of new API proposal

Folks, sorry for the top post here, but I wanted to make sure to gather 
people's attention in this thread.

I'm very happy to see all the passion around LBaaS in Neutron for this cycle. 
As I've told a few people, seeing all the interest from operators and providers 
is fantastic, as it gives us valuable input from that side of things before we 
embark on designing and coding.
I've also attended the last few LBaaS IRC meetings, and I've been catching up 
on the LBaaS documents and emails. There is a lot of great work and passion by 
many people. However, the downside of what I've seen is that there is a logjam 
around progress here. Given we're two weeks out from the Summit, I'm going to 
start running the LBaaS meetings with Eugene to try and help provide some focus 
there.
Hopefully we can use this week and next week's meetings to drive to a 
consistent Summit agenda and lay the groundwork for LBaaS in Juno and beyond.

Also, while our new neutron-specs BP repository has been great so far for 
developers, based on feedback from operators, it may not be ideal for those who 
are not used to contributing using gerrit. I don't want to lose the voice of 
those people, so I'm pondering what to do. This is really affecting the LBaaS 
discussion at the moment. I'm thinking that we should ideally try to use Google 
Docs for these initial discussions and then move the result of that into a BP 
on neutron-specs. What do people think of that?

If we go down this path, we need to decide on a single Google Doc for people to 
collaborate on. I don't want to put Stephen on the spot, but his document may 
be a good starting point.

I'd like to hear what others think on this plan as well.

Thanks,
Kyle


On Sun, Apr 27, 2014 at 6:06 PM, Eugene Nikanorov enikano...@mirantis.com 
wrote:
 Hi,


 You knew from the action items that came out of the IRC meeting of 
 April
 17 that my team would be working on an API revision proposal. You 
 also knew that this proposal was to be accompanied by an object model 
 diagram and glossary, in order to clear up confusion. You were in 
 that meeting, you saw the action items being created. Heck, you even 
 added the to prepare API for SSL and L7 directive for my team yourself!

 The implied but not stated assumption about this work was that it 
 would be fairly evaluated once done, and that we would be given a short 
 window (ie.
 about a week) in which to fully prepare and state our proposal.

 Your actions, though, were apparently to produce your own version of 
 the same in blueprint form without notifying anyone in the group that 
 you were going to be doing this, let alone my team. How could you 
 have given my API proposal a fair shake prior to publishing your 
 blueprint, if both came out on the same day? (In fact, I'm lead to 
 believe that you and other Neutron LBaaS developers hadn't even 
 looked at my proposal before the meeting on 4/24, where y'all started 
 determining product direction, apparently by
 edict.)


 Therefore, looking honestly at your actions on this and trying to 
 give you the benefit of the doubt, I still must assume that you never 
 intended to seriously consider our proposal.

 That's strange to hear because the spec on review is a part of what is 
 proposed

Re: [openstack-dev] [Neutron][LBaaS] Use Case Question

[Samuel Bercovici]

Hi,

As stated, this could either be handled by SSL session ID persistency or by SSL 
termination and using cookie based persistency options.
If there is no need to inspect the content hence to terminate the SSL 
connection on the load balancer for this sake, than using SSL session ID based 
persistency is obviously a much more efficient way.
The reference to source client IP changing was to negate the use of source IP 
as the stickiness algorithm.


-Sam.


From: Trevor Vardeman [mailto:trevor.varde...@rackspace.com]
Sent: Thursday, April 24, 2014 7:26 PM
To: openstack-dev@lists.openstack.org
Subject: [openstack-dev] [Neutron][LBaaS] Use Case Question

Hey,

I'm looking through the use-cases doc for review, and I'm confused about one of 
them.  I'm familiar with HTTP cookie based session persistence, but to satisfy 
secure-traffic for this case would there be decryption of content, injection of 
the cookie, and then re-encryption?  Is there another session persistence type 
that solves this issue already?  I'm copying the doc link and the use case 
specifically; not sure if the document order would change so I thought it would 
be easiest to include both :)

Use Cases:  
https://docs.google.com/document/d/1Ewl95yxAMq2fO0Z6Dz6fL-w2FScERQXQR1-mXuSINis

Specific Use Case:  A project-user wants to make his secured web based 
application (HTTPS) highly available. He has n VMs deployed on the same private 
subnet/network. Each VM is installed with a web server (ex: apache) and 
content. The application requires that a transaction which has started on a 
specific VM will continue to run against the same VM. The application is also 
available to end-users via smart phones, a case in which the end user IP might 
change. The project-user wishes to represent them to the application users as a 
web application available via a single IP.

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

[openstack-dev] [Neutron][LBaaS]Conforming to Open Stack API style in LBaaS

[Samuel Bercovici]

Hi Everyone,

During the last few days I have looked into the different LBaaS API proposals.
I have also looked on the API style used in Neutron. I wanted to see how 
Neutron APIs addressed tree like object models.
Follows my observation:

1.   Security groups -  
http://docs.openstack.org/api/openstack-network/2.0/content/security-groups-ext.html)
 -

a.   
security-group-ruleshttp://docs.openstack.org/api/openstack-network/2.0/content/GET_security-groups-v2.0_listSecGroupRules_v2.0_security-group-rules_security-groups-ext.html
 are children of 
security-groupshttp://docs.openstack.org/api/openstack-network/2.0/content/GET_security-groups-v2.0_listSecGroups_v2.0_security-groups_security-groups-ext.html,
 the capability to create a security group with its children in a single call 
is not possible.

b.   The capability to create 
security-group-ruleshttp://docs.openstack.org/api/openstack-network/2.0/content/GET_security-groups-v2.0_listSecGroupRules_v2.0_security-group-rules_security-groups-ext.html
 using the following URI path 
v2.0/security-groupshttp://docs.openstack.org/api/openstack-network/2.0/content/GET_security-groups-v2.0_listSecGroups_v2.0_security-groups_security-groups-ext.html/{SG-ID}/security-group-ruleshttp://docs.openstack.org/api/openstack-network/2.0/content/GET_security-groups-v2.0_listSecGroupRules_v2.0_security-group-rules_security-groups-ext.html
 is not supported

c.The capability to update 
security-group-ruleshttp://docs.openstack.org/api/openstack-network/2.0/content/GET_security-groups-v2.0_listSecGroupRules_v2.0_security-group-rules_security-groups-ext.html
 using the following URI path 
v2.0/security-groupshttp://docs.openstack.org/api/openstack-network/2.0/content/GET_security-groups-v2.0_listSecGroups_v2.0_security-groups_security-groups-ext.html/{SG-ID}/security-group-ruleshttp://docs.openstack.org/api/openstack-network/2.0/content/GET_security-groups-v2.0_listSecGroupRules_v2.0_security-group-rules_security-groups-ext.html/{SGR-ID}
 is not supported

d.   The notion of creating 
security-group-ruleshttp://docs.openstack.org/api/openstack-network/2.0/content/GET_security-groups-v2.0_listSecGroupRules_v2.0_security-group-rules_security-groups-ext.html
 (child object) without providing the parent {SG-ID} is not supported

2.   Firewall as a service - 
http://docs.openstack.org/api/openstack-network/2.0/content/fwaas_ext.html - 
the API to manage firewall_policy and firewall_rule which have parent child 
relationships behaves the same way as Security groups

3.   Group Policy - this is work in progress - 
https://wiki.openstack.org/wiki/Neutron/GroupPolicy - If I understand 
correctly, this API has a complex object model while the API adheres to the way 
other neutron APIs are done (ex: flat model, granular api, etc.)

How critical is it to preserve a consistent API style for LBaaS?
Should this be a consideration when evaluating API proposals?

Regards,
-Sam.


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

Re: [openstack-dev] [Neutron][LBaaS] BBG edit of new API proposal

[Samuel Bercovici]

Hi,

I think it is a good idea to have the use cases in a different document that 
API proposals (Stephen's, included)
Once we declare the uses cases done for Juno, I will move it to the BP 
repository.
I would also like to see operator's use cases flushed out in the document.

Stephen, could you please open the document also for editing?

Regards,
-Sam.




-Original Message-
From: Kyle Mestery [mailto:mest...@noironetworks.com] 
Sent: Tuesday, April 29, 2014 5:27 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron][LBaaS] BBG edit of new API proposal

On Mon, Apr 28, 2014 at 6:23 PM, Stephen Balukoff sbaluk...@bluebox.net wrote:
 Hi guys,

 Sorry for all the drama on the list lately.

Not a problem. Like I said, the passion from all sides is great, and I'm 
especially happy to see all the operators engaging with Neutron for LBaaS.

 Kyle: I appreciate the sentiment. I'd also be happy to open up my API 
 doc for general editing by people on the internet (and not just 
 comments) if you think that would help.

My main reason for asking this was in case the gerrit bar was too high for new 
people to Neutron and LBaaS in particular. I want to make sure we capture 
everyone's ideas and allow everyone a chance to comment.
The gerrit BP process does this nicely, but I just want to ensure it's not too 
high of a bar for people new to the entire process.

 For us new-comers to the OpenStack project environment, what do people 
 usually use for discussing potential design changes (and especially 
 large design changes)?  (From my perspective, Blue prints seem mostly 
 useful as collections of links to other documents, without having an 
 obvious way to discuss things in the blueprint directly. Gerrit seems 
 like it's mostly github workflow with CI baked in-- ie. useful for 
 specific smaller code changes, but not as much for design-level 
 discussions. I suppose etherpads might duplicate much of the 
 functionality we're currently using google docs to accomplish (though 
 I don't think etherpads have the ability to do spreadsheets, from what I can 
 tell).

I think it's fine to use the gdoc for now, with the idea being we will then 
converge on work items formed into multiple BPs out of the gdoc.
So perhaps it does make sense to use your document as the communal starting 
point for this. But I'm open to what others may say as well.

 As far as the meetings go: It might help if you could share with us 
 what you hope to accomplish prior to the summit, and what kinds of 
 things you'd like us to be prepared to discuss at the summit. (Is 
 there an LBaaS meeting of some kind scheduled there yet?)

I've given LBaaS 2 40 minute sessions. What I'd like us to do is come to come 
to a consensus on what needs discussing in person vs. what everyone is agreeing 
on and we don't need to discuss in those sessions. If we need time to discuss 
the object model and API in Atlanta, that's fine too.

 For my part, I plan on concentrating on filling out more use cases and 
 then returning to the software load balancer virtual appliance porting 
 project that's been on the back-burner for way too long for me.

Perfect! How about if we try to close the use case gap for this week's LBaaS 
meeting. Then, next week we can at least make a stab at the object model and 
API which satisfies as many use cases as we come up with.

 Samuel and German: I've gone ahead and added around 20 new use cases 
 to the google doc you linked. More will be on the way, but I'm happy 
 to add these to gerrit myself if you'd prefer, so long as I can see 
 how you're doing this for the first use cases and can follow your 
 template. Let me know if you'd like me to change what I've been doing 
 here, eh! Note also that so far these are only user use cases; It 
 doesn't look like admin/operator use cases have been filled out at all yet.

Getting the admin/operator use cases in there would be good as well Stephen.

Thanks,
Kyle

 Thanks,
 Stephen




 On Mon, Apr 28, 2014 at 2:12 PM, Eichberger, German 
 german.eichber...@hp.com wrote:

 Sam,

 The use cases where pretty complete the last time I checked so let's 
 move them to gerrit so we can all vote.

 Echoing Kyle I would love to see us focusing on getting things ready 
 for the summit.

 German

 -Original Message-
 From: Samuel Bercovici [mailto:samu...@radware.com]
 Sent: Monday, April 28, 2014 11:44 AM
 To: OpenStack Development Mailing List (not for usage questions)
 Subject: Re: [openstack-dev] [Neutron][LBaaS] BBG edit of new API 
 proposal

 Hi,

 I was just working to push the use cases into the new format .rst but 
 I agree that using google doc would be more intuitive.
 Let me know what you prefer to do with the use cases document:
 1. leave it at google docs at -
 https://docs.google.com/document/d/1Ewl95yxAMq2fO0Z6Dz6fL-w2FScERQXQR
 1-mXuSINis/edit?pli=1
 2. Move it to the new format under -
 http://git.openstack.org

Re: [openstack-dev] [Neutron][LBaaS] BBG edit of new API proposal

[Samuel Bercovici]

Hi,

I was just working to push the use cases into the new format .rst but I agree 
that using google doc would be more intuitive.
Let me know what you prefer to do with the use cases document:
1. leave it at google docs at - 
https://docs.google.com/document/d/1Ewl95yxAMq2fO0Z6Dz6fL-w2FScERQXQR1-mXuSINis/edit?pli=1
2. Move it to the new format under - 
http://git.openstack.org/cgit/openstack/neutron-specs, I have already files a 
blue print https://blueprints.launchpad.net/neutron/+spec/lbaas-use-cases and 
can complete the .rst process by tomorrow.

Regards,
-Sam.






-Original Message-
From: Kyle Mestery [mailto:mest...@noironetworks.com] 
Sent: Monday, April 28, 2014 4:33 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron][LBaaS] BBG edit of new API proposal

Folks, sorry for the top post here, but I wanted to make sure to gather 
people's attention in this thread.

I'm very happy to see all the passion around LBaaS in Neutron for this cycle. 
As I've told a few people, seeing all the interest from operators and providers 
is fantastic, as it gives us valuable input from that side of things before we 
embark on designing and coding.
I've also attended the last few LBaaS IRC meetings, and I've been catching up 
on the LBaaS documents and emails. There is a lot of great work and passion by 
many people. However, the downside of what I've seen is that there is a logjam 
around progress here. Given we're two weeks out from the Summit, I'm going to 
start running the LBaaS meetings with Eugene to try and help provide some focus 
there.
Hopefully we can use this week and next week's meetings to drive to a 
consistent Summit agenda and lay the groundwork for LBaaS in Juno and beyond.

Also, while our new neutron-specs BP repository has been great so far for 
developers, based on feedback from operators, it may not be ideal for those who 
are not used to contributing using gerrit. I don't want to lose the voice of 
those people, so I'm pondering what to do. This is really affecting the LBaaS 
discussion at the moment. I'm thinking that we should ideally try to use Google 
Docs for these initial discussions and then move the result of that into a BP 
on neutron-specs. What do people think of that?

If we go down this path, we need to decide on a single Google Doc for people to 
collaborate on. I don't want to put Stephen on the spot, but his document may 
be a good starting point.

I'd like to hear what others think on this plan as well.

Thanks,
Kyle


On Sun, Apr 27, 2014 at 6:06 PM, Eugene Nikanorov enikano...@mirantis.com 
wrote:
 Hi,


 You knew from the action items that came out of the IRC meeting of 
 April
 17 that my team would be working on an API revision proposal. You 
 also knew that this proposal was to be accompanied by an object model 
 diagram and glossary, in order to clear up confusion. You were in 
 that meeting, you saw the action items being created. Heck, you even 
 added the to prepare API for SSL and L7 directive for my team yourself!

 The implied but not stated assumption about this work was that it 
 would be fairly evaluated once done, and that we would be given a short 
 window (ie.
 about a week) in which to fully prepare and state our proposal.

 Your actions, though, were apparently to produce your own version of 
 the same in blueprint form without notifying anyone in the group that 
 you were going to be doing this, let alone my team. How could you 
 have given my API proposal a fair shake prior to publishing your 
 blueprint, if both came out on the same day? (In fact, I'm lead to 
 believe that you and other Neutron LBaaS developers hadn't even 
 looked at my proposal before the meeting on 4/24, where y'all started 
 determining product direction, apparently by
 edict.)


 Therefore, looking honestly at your actions on this and trying to 
 give you the benefit of the doubt, I still must assume that you never 
 intended to seriously consider our proposal.

 That's strange to hear because the spec on review is a part of what is 
 proposed in the document made by you and your team.
 Once again I'm not sure what this heated discussion is all about. The 
 doc does good job and we will continue discussing it, while a part of 
 it (spec about VIPs/Listeners/Pools) is on review where we, as lbaas 
 subteam, actually can finalize a part of it.


 Do you now understand why I find this offensive? Can you also 
 understand how others, seeing how this was handled, might now be 
 reluctant to participate?

 People may find different things to be offensive. I can also say much 
 on this, but would not like not continue the conversation in this direction.


 Right, so *if* we decide to go with my proposal, we need to first 
 decide which parts we're actually going to go with--

  I don't expect my proposal to be complete or perfect by any means, 
 and we need to have honest discussion of this first. Then, once we've 

Re: [openstack-dev] [Neutron][LBaaS]SSL and L7 conent switching APIs

[Samuel Bercovici]

Hi,

The work to design the APIs concerning L7 content switching and SSL termination 
has started a bit before the Icehouse summit, it involved the ML in a very 
active fashion.
The ML was silent on this because we have completed the discussion and moved to 
implementation.
We got to a very advanced state in completing the code which got stopped due to 
the discussion about the core model (VIPs, Pools, etc.)
The blue prints WIKIs and code are public 
(https://blueprints.launchpad.net/neutron/+spec/lbaas-l7-rules and 
https://blueprints.launchpad.net/neutron/+spec/lbaas-ssl-termination ).
Please take the time to review and discuss on ML if something is missing so we 
can talk about this at the summit.

-Sam.


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

Re: [openstack-dev] [Neutron][LBaaS] Use cases document

[Samuel Bercovici]

Stephen you can edit the google doc directly.
Please add your use cases to there.


From: Stephen Balukoff [mailto:sbaluk...@bluebox.net]
Sent: Thursday, April 24, 2014 3:52 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron][LBaaS] Use cases document

Hi Samuel,

I'm a little confused what you're asking for: Do you want us to add use cases 
to the document directly, or discuss them here first and then someone 
(presumably you?) adds them to the document after it's agreed it's a valid use 
case?

It sounds like one or more of the use cases you've collected so far might have 
gone missing. Does it make sense to move the list of use cases to the wiki, 
then, where everyone can edit and there's history kept so mistakes can be 
rolled back easily?

(I ask, because I've been thinking of new use cases all week as I've been 
working on the API revision proposal, and I'd like to get them recorded and / 
or discussed.)

Stephen

On Tue, Apr 22, 2014 at 1:26 AM, Samuel Bercovici 
samu...@radware.commailto:samu...@radware.com wrote:
Hi,

I have seen a few addition to 
https://docs.google.com/document/d/1Ewl95yxAMq2fO0Z6Dz6fL-w2FScERQXQR1-mXuSINis/edit?pli=1
I think that it would make sense to keep this document with uses cases that 
were discussed in ML.
A use case that I have seen and is missing is related to availability zones.
Please feel free to update this and add your own to the document.

I have also added sections for Cloud Admin/Cloud Operator use cases. Please add 
additional use cases based on your experience.

Regards,
-Sam.


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.orgmailto: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
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Neutron][LBaaS] Use cases document

[Samuel Bercovici]

Hi,

I have seen a few addition to 
https://docs.google.com/document/d/1Ewl95yxAMq2fO0Z6Dz6fL-w2FScERQXQR1-mXuSINis/edit?pli=1
I think that it would make sense to keep this document with uses cases that 
were discussed in ML.
A use case that I have seen and is missing is related to availability zones.
Please feel free to update this and add your own to the document.

I have also added sections for Cloud Admin/Cloud Operator use cases. Please add 
additional use cases based on your experience.

Regards,
-Sam.

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

Re: [openstack-dev] [Neutron][LBaaS] SSL re-encryption scenario question

[Samuel Bercovici]

Hi,

The work on SSL termination has started and is very near completion.
the blue print is in 
https://blueprints.launchpad.net/neutron/+spec/lbaas-ssl-termination and wiki 
is in https://wiki.openstack.org/wiki/Neutron/LBaaS/SSL
Do you see anything missing there?


Regards,
-Sam.




-Original Message-
From: Carlos Garza [mailto:carlos.ga...@rackspace.com] 
Sent: Saturday, April 19, 2014 2:47 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron][LBaaS] SSL re-encryption scenario 
question


On Apr 18, 2014, at 10:21 AM, Stephen Balukoff sbaluk...@bluebox.net wrote:

 Howdy, folks!
 
 Could someone explain to me the SSL usage scenario where it makes 
 sense to re-encrypt traffic traffic destined for members of a back-end 
 pool?  SSL termination on the load balancer makes sense to me, but I'm 
 having trouble understanding why one would be concerned about then 
 re-encrypting the traffic headed toward a back-end app server. (Why 
 not just use straight TCP load balancing in this case, and save the 
 CPU cycles on the load balancer?)
 

1. Some customers want their servers to be external from our data centers for 
example the loadbalancer is in Chicago with rackspace hosting the loadbalancers 
and the back end pool members being on Amazon AWS servers. (We don't know why 
they would do this but a lot are doing it). They can't can't simply just audit 
the links between AWS and our DataCenters for PCI lots of backbones being 
crossed. so they just want encryption to their backend pool members. Also take 
note that amazon has chosen to support encryption 
http://aws.amazon.com/about-aws/whats-new/2011/10/04/amazon-s3-announces-server-side-encryption-support/
They've had it for a while now and for what ever reason a lot of customers are 
now demanding it from us as well.  

I agree they could simply just use HTTPS load balancing but they seem to think 
providers that don't offer encryption are inferior feature wise.

2. User that are on providers that are incapable of One Armed With Source Nat 
load balancing capabilities (See link below) are at the mercy of using 
X-forwarded for style headers to determine the original  source of a 
connection. (A must if they want to know where abusive connections are coming 
from). Under traditional NAT routing the source ip will always be the 
loadbalancers ip so X-Forwarded for has been the traditional method of show the 
server this(This applies to HTTP load balancing as well). But in the case of 
SSL the loadbalancer unless its decrypting traffic won't be able to inject 
these headers in. and when the pool members are on an external network it is 
prudent to allow for encryption, this pretty much forces them to use a trusted 
LoadBalancer as a man in the middle to decrypt add X-forwarded for, then 
encrypting to the back end. 

http://docwiki.cisco.com/wiki/Basic_Load_Balancing_Using_One_Arm_Mode_with_Source_NAT_on_the_Cisco_Application_Control_Engine_Configuration_Example


3. Unless I'm mistaken it looks like encryption was already apart of the API or 
was accepted as a requirement for neutron lbaas.
https://wiki.openstack.org/wiki/Neutron/LBaaS/SSL#Current_design
is this document still valid?

4. We also assumed we were expected to support the use cases described in
https://docs.google.com/document/d/1Ewl95yxAMq2fO0Z6Dz6fL-w2FScERQXQR1-mXuSINis/edit?pli=1
where case 7 specifically is asking for Re-encryption.


 We terminate a lot of SSL connections on our load balancers, but have 
 yet to have a customer use this kind of functionality.  (We've had a 
 few ask about it, usually because they didn't understand what a load 
 balancer is supposed to do-- and with a bit of explanation they went 
 either with SSL termination on the load balancer + clear text on the 
 back-end, or just straight TCP load balancing.)

We terminate a lot of SSL connections on our loadbalancers as well and we 
get a lot of pressure for this kind of functionality.  I think you have no 
customers using that functionality because you are unable to offer it  which is 
the case for us as well. But due to a significant amount of pressure we have a 
solution already ready and waiting for testing on our CLB1.0 offering. 

We wished this was the case for us that only a few users are requesting 
this feature  but we have customers that really do want their backend pool 
members on a separate non secure network or worse want this as a more advance 
form of HTTPS passthrough(TCP load balancing as your describing it). 

Providers may be able to secure their loadbalancers but they may not always 
be able to secure their back and forward connections. Users still want end to 
end encrypted connectivity but want the loadbalancer to be capable of making 
intelligent decisions(requiring decryption at the loadbalancer) as well as 
inject useful headers going to the back end pool member still need encryption 
functionality.

 When 

Re: [openstack-dev] [Neutron][LBaaS] Load balancing use cases and web ui screen captures

[Samuel Bercovici]

Hi Eugene,

As far as I recall people wanted to balance how a common case would be used 
vs. an advanced case.
For this I have created a range of use cases listed in the document so that 
people can go over, make sure they agree (ex: the question about availability 
zones) and then we can select two that represent the simple case and the 
advanced case.
I also think that the one you have listed below stands a very good case of 
being used for the advanced case.

Regards,
-Sam.


From: Eugene Nikanorov [mailto:enikano...@mirantis.com]
Sent: Monday, April 07, 2014 6:15 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron][LBaaS] Load balancing use cases and web 
ui screen captures

Hi Sam,

I find google doc a little bit too heavy for ML discussion.
So I'd like to extract the gist of the overall use case that we want to use 
when discussing an API (for ex, single-call API).
Here it is as I see it (Sam, correct me if I'm wrong):

User wants to setup web application that is available both via HTTP and HTTPS 
protocols and consists of various parts.
One part http://ip-addr/part1 is only available via HTTP, another part 
http://ip-addr//part2http://ip-addr/part2 is available via both HTTP and 
HTTPS.
Webapp parts part1 and part2 are served with two different group of nodes which 
reside on different (option: same) private networks.

Please provide a call or a set of calls that would allow to configure balancing 
for such app. Consider additional options like HA.

Thanks,
Eugene.


On Mon, Apr 7, 2014 at 4:12 PM, Alun Champion 
p...@achampion.netmailto:p...@achampion.net wrote:
Yes, to ensure availability the same application could be deployed
across multiple availability zones/cells, as these can offer some
level of independence of risk. The use-cases seemed to expect same
network, which may not be achievable given the above, but ideally
should be able to load-balance across zones/cells. Other cloud
management solutions have moved to name based LB because of the above,
is this something being considered?

On 7 April 2014 05:27, Samuel Bercovici 
samu...@radware.commailto:samu...@radware.com wrote:
 Please elaborate, do you mean that the nodes could be on different 
 zones/cells or something else?


 -Original Message-
 From: Alun Champion [mailto:p...@achampion.netmailto:p...@achampion.net]
 Sent: Sunday, April 06, 2014 4:51 PM
 To: OpenStack Development Mailing List (not for usage questions)
 Subject: Re: [openstack-dev] [Neutron][LBaaS] Load balancing use cases and 
 web ui screen captures

 How do these use-cases relate to availability zones or cells, is the 
 assumption that the same private network is available across both? An 
 application owner could look to protect availability not just provide 
 scalability.

 On 6 April 2014 07:51, Samuel Bercovici 
 samu...@radware.commailto:samu...@radware.com wrote:
 Per the last LBaaS meeting.



 1.   Please find a list of use cases.

 https://docs.google.com/document/d/1Ewl95yxAMq2fO0Z6Dz6fL-w2FScERQXQR1
 -mXuSINis/edit?usp=sharing



 a)  Please review and see if you have additional ones for the
 project-user

 b)  We can then chose 2-3 use cases to play around with how the CLI,
 API, etc. would look



 2.   Please find a document to place screen captures of web UI. I took
 the liberty to place a few links showing ELB.

 https://docs.google.com/document/d/10EOCTej5CvDfnusv_es0kFzv5SIYLNl0uH
 erSq3pLQA/edit?usp=sharing





 Regards,

 -Sam.










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


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

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

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.orgmailto: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

[openstack-dev] [Neutron][LBaaS]Clarification in regards to https://docs.google.com/a/mirantis.com/spreadsheet/ccc?key=0Ar1FuMFYRhgadDVXZ25NM2NfbGtLTkR0TDFNUWJQUWc#gid=1

[Samuel Bercovici]

Hi,

I have looked at 
https://docs.google.com/a/mirantis.com/spreadsheet/ccc?key=0Ar1FuMFYRhgadDVXZ25NM2NfbGtLTkR0TDFNUWJQUWc#gid=1
 and have a few questions:

1.   Monitoring Tab:

a.   Are there users that use load balancing who do not monitor members? 
Can you share the use cases where this makes sense?

b.  Does it make sense to define the different type of monitors (ex: TCP, 
HTTP HTTPS)?

c.   Does any existing cloud service besides the current implementation of 
the LBaaS API supports using multiple monitors on the same pool? Is this a 
required feature?

2.   Logging Tab:

a.   What is logging use for?

b.  How does the tenant consume the logs?

3.   SSL Tab:

a.   Please explain if SSL means passing SSL traffic through the load 
balancer or using the load balancer to terminate certificates.

b.  Does it make sense to separate those (SSL termination and non HTTPS 
terminated traffic) as different rows?

c.   Can anyone explain the use cases for SSL_MIXED?

4.   HA Tab:

a.   Is this a tenant facing option or is it the way the operator chose to 
implement the service

5.   Content Caching Tab:

a.   Is this a load balancer feature or a CDN like feature.

6.   L7

a.   Does any cloud provider support L7 switching and L7 content 
modifications?

b.  If so can you please add a tab noting how much such features are used?

c.   If not, can anyone attest to whether this feature was requested by 
customers?

Thanks!
-Sam.

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

Re: [openstack-dev] [Neutron][LBaaS] Load balancing use cases and web ui screen captures

[Samuel Bercovici]

Please elaborate, do you mean that the nodes could be on different zones/cells 
or something else?


-Original Message-
From: Alun Champion [mailto:p...@achampion.net] 
Sent: Sunday, April 06, 2014 4:51 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron][LBaaS] Load balancing use cases and web 
ui screen captures

How do these use-cases relate to availability zones or cells, is the assumption 
that the same private network is available across both? An application owner 
could look to protect availability not just provide scalability.

On 6 April 2014 07:51, Samuel Bercovici samu...@radware.com wrote:
 Per the last LBaaS meeting.



 1.   Please find a list of use cases.

 https://docs.google.com/document/d/1Ewl95yxAMq2fO0Z6Dz6fL-w2FScERQXQR1
 -mXuSINis/edit?usp=sharing



 a)  Please review and see if you have additional ones for the
 project-user

 b)  We can then chose 2-3 use cases to play around with how the CLI,
 API, etc. would look



 2.   Please find a document to place screen captures of web UI. I took
 the liberty to place a few links showing ELB.

 https://docs.google.com/document/d/10EOCTej5CvDfnusv_es0kFzv5SIYLNl0uH
 erSq3pLQA/edit?usp=sharing





 Regards,

 -Sam.










 ___
 OpenStack-dev mailing list
 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

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

[openstack-dev] [Neutron][LBaaS] Load balancing use cases and web ui screen captures

[Samuel Bercovici]

Per the last LBaaS meeting.


1.   Please find a list of use cases.
https://docs.google.com/document/d/1Ewl95yxAMq2fO0Z6Dz6fL-w2FScERQXQR1-mXuSINis/edit?usp=sharing


a)  Please review and see if you have additional ones for the project-user

b)  We can then chose 2-3 use cases to play around with how the CLI, API, 
etc. would look


2.   Please find a document to place screen captures of web UI. I took the 
liberty to place a few links showing ELB.
https://docs.google.com/document/d/10EOCTej5CvDfnusv_es0kFzv5SIYLNl0uHerSq3pLQA/edit?usp=sharing


Regards,
-Sam.




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

Re: [openstack-dev] [Neutron][LBaaS] Requirements Wiki

[Samuel Bercovici]

+1

-Original Message-
From: Ryan O'Hara [mailto:roh...@redhat.com] 
Sent: Wednesday, March 19, 2014 2:37 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron][LBaaS] Requirements Wiki

On Tue, Mar 18, 2014 at 10:57:15PM +, Jorge Miramontes wrote:
 Hey Neutron LBaaS folks,
 
 Per last week's IRC meeting I have created a preliminary requirements 
  use case wiki page. I requested adding such a page since there 
 appears to be a lot of new interest in load balancing and feel that we 
 need a structured way to align everyone's interest in the project. 
 Furthermore, it appears that understanding everyone's requirements and 
 use cases will aid in the current object model discussion we all have 
 been having. That being said, this wiki is malleable and open to 
 discussion. I have added some preliminary requirements from my team's 
 perspective in order to start the discussion. My vision is that people 
 add requirements and use cases to the wiki for what they envision 
 Neutron LBaaS becoming. That way, we can all discuss as a group, 
 figure out what should and shouldn't be a requirement and prioritize 
 the rest in an effort to focus development efforts. ReadyŠsetŠgo!
 
 Here is the link to the wiki ==
 https://wiki.openstack.org/wiki/Neutron/LBaaS/requirements
 
 Cheers,
 --Jorge

Thank you for creating this page. I suggest that links be added to existing 
blueprints when applicable. Thoughts?

Ryan


___
OpenStack-dev mailing list
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

Re: [openstack-dev] [Neutron][LBaaS][FWaaS][VPN] Admin status vs operational status

[Samuel Bercovici]

Discussing some radical concepts...

I also agree that there should be different attribute to reflect the 
administrator state, operation state and the provisioning state.
This is already reflected in 
https://docs.google.com/document/d/1D-1n8nCEFurYzvEBxIRfXfffnImcIPwWSctAG-NXonY/edit?usp=sharing
 as three different  properties admin_state_up, Provisioning Status and 
Operation Status.

The problem with the provisioning status is that it is not reentrant
Many of the APIs are a-sync so if we do a few a-sync calls, it is not clear 
which of those call's status we see in the status property.
A better API might be that when doing an a-sync call, the call retunes a 
token and  the status of the token reflects how the a-sync call was 
completed.

Regards,
-sam.


-Original Message-
From: Itsuro ODA [mailto:o...@valinux.co.jp] 
Sent: Tuesday, March 18, 2014 1:45 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron][LBaaS][FWaaS][VPN] Admin status vs 
operational status

Hi,

With my understanding, it should be:

* 'status' is a read only attribute which shows to users whether 
  the service is available or not.
  So for example, VIP status is ACTIVE but the loadblancing service
  is not available is not allowed.
  (Actually our customers want to fix this strongly.)

* 'admin_state_up' is an attribute for an administrator to set
  whether the service is available or not.
  As a result 'status' of the resource and the associated resources
  become ACTIVE or DOWN. 
  (If it does not work so, it is a problem of the implementation.)

Thanks
-- 
Itsuro ODA o...@valinux.co.jp


___
OpenStack-dev mailing list
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

Re: [openstack-dev] [Neutron][LBaaS] Subteam meeting Thursday, 14-00 UTC

[Samuel Bercovici]

Hi Eugene,

I am with Evgeny on a business trip so we will not be able to join this time.
I have not seen any progress on the model side. Did I miss anything?
Will look for the meeting summary

Regards,
-Sam.


From: Eugene Nikanorov [mailto:enikano...@mirantis.com]
Sent: Wednesday, March 12, 2014 10:21 PM
To: OpenStack Development Mailing List
Subject: [openstack-dev] [Neutron][LBaaS] Subteam meeting Thursday, 14-00 UTC

Hi neutron and lbaas folks,

Let's keep our regular meeting on Thursday, at 14-00 UTC at #openstack-meeting

We'll update on current status and continue object model discussion.
We have many new folks that are recently showed the interest in lbaas project 
asking for mini summit. I think it would be helpful for everyone interested in 
lbaas to join the meeting.

Thanks,
Eugene.

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

Re: [openstack-dev] [LBaaS] API spec for SSL Support

[Samuel Bercovici]

Hi,

The wiki is updated to reflect the APIs.

Regards,
-Sam.



From: Palanisamy, Anand [mailto:apalanis...@paypal.com]
Sent: Thursday, March 06, 2014 3:26 AM
To: OpenStack Development Mailing List
Subject: [openstack-dev] [LBaaS] API spec for SSL Support

Hi All,

Please let us know if we have the blueprint or the proposal for the LBaaS SSL 
API specification. We see only the workflow documented here 
https://wiki.openstack.org/wiki/Neutron/LBaaS/SSL.

Thanks
Anand

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

Re: [openstack-dev] [Neutron][LBaaS] Health monitoring and statistics for complex LB configurations.

[Samuel Bercovici]

Hi,

As an example you can look at 
https://docs.google.com/document/d/1D-1n8nCEFurYzvEBxIRfXfffnImcIPwWSctAG-NXonY/edit?usp=sharing
Under the “Logical Model + Provisioning Status + Operation Status + Statistics” 
there are some details on thoughts on how to implement this.

Regards,
-Sam.


From: John Dewey [mailto:j...@dewey.ws]
Sent: Thursday, March 06, 2014 2:34 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron][LBaaS] Health monitoring and statistics 
for complex LB configurations.

On Wednesday, March 5, 2014 at 12:41 PM, Eugene Nikanorov wrote:
Hi community,

Another interesting questions were raised during object model discussion about 
how pool statistics and health monitoring should be used in case of multiple 
vips sharing one pool.

Right now we can query statistics for the pool, and some data like in/out bytes 
and request count will be returned.
If we had several vips sharing the pool, what kind of statistics would make 
sense for the user?
The options are:

1) aggregated statistics for the pool, e.g. statistics of all requests that has 
hit the pool through any VIP
2) per-vip statistics for the pool.
Would it be crazy to offer both?  We can return stats for each pool associated 
with the VIP as you described below.  However, we also offer an aggregated 
section for those interested.

IMO, having stats broken out per-pool seem more helpful than only aggregated, 
while both would be ideal.

John

Depending on the answer, the statistics workflow will be different.

The good option of getting the statistics and health status could be to query 
it through the vip and get it for the whole logical instance, e.g. a call like:
 lb-vip-statistics-get --vip-id vip_id
the would result in json that returns statistics for every pool associated with 
the vip, plus operational status of all members for the pools associated with 
that VIP.

Looking forward to your feedback.

Thanks,
Eugene.

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.orgmailto: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

Re: [openstack-dev] [Neutron][LBaaS] Object Model discussion

[Samuel Bercovici]

Hi,

In 
https://docs.google.com/document/d/1D-1n8nCEFurYzvEBxIRfXfffnImcIPwWSctAG-NXonY/edit?usp=sharing
 referenced by the Wiki, I have added the section that address the items raised 
on the last irc meeting.

Regards,
-Sam.


From: Samuel Bercovici
Sent: Wednesday, February 26, 2014 7:06 PM
To: OpenStack Development Mailing List (not for usage questions)
Cc: Samuel Bercovici; Eugene Nikanorov (enikano...@mirantis.com); Evgeny 
Fedoruk; Avishay Balderman
Subject: RE: [openstack-dev] [Neutron][LBaaS] Object Model discussion

Hi,

I have added to the wiki page: 
https://wiki.openstack.org/wiki/Neutron/LBaaS/LoadbalancerInstance/Discussion#1.1_Turning_existing_model_to_logical_model
 that points to a document that includes the current model + L7 + SSL.
Please review.

Regards,
-Sam.


From: Samuel Bercovici
Sent: Monday, February 24, 2014 7:36 PM
To: OpenStack Development Mailing List (not for usage questions)
Cc: Samuel Bercovici
Subject: RE: [openstack-dev] [Neutron][LBaaS] Object Model discussion

Hi,

I also agree that the model should be pure logical.
I think that the existing model is almost correct but the pool should be made 
pure logical. This means that the vip pool relationships needs also to 
become any to any.
Eugene, has rightfully pointed that the current state management will not 
handle such relationship well.
To me this means that the state management is broken and not the model.
I will propose an update to the state management in the next few days.

Regards,
-Sam.




From: Mark McClain [mailto:mmccl...@yahoo-inc.com]
Sent: Monday, February 24, 2014 6:32 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron][LBaaS] Object Model discussion


On Feb 21, 2014, at 1:29 PM, Jay Pipes 
jaypi...@gmail.commailto:jaypi...@gmail.com wrote:

I disagree on this point. I believe that the more implementation details
bleed into the API, the harder the API is to evolve and improve, and the
less flexible the API becomes.

I'd personally love to see the next version of the LBaaS API be a
complete breakaway from any implementation specifics and refocus itself
to be a control plane API that is written from the perspective of the
*user* of a load balancing service, not the perspective of developers of
load balancer products.

I agree with Jay.  We the API needs to be user centric and free of 
implementation details.  One of my concerns I've voiced in some of the IRC 
discussions is that too many implementation details are exposed to the user.

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

Re: [openstack-dev] [Neutron] Flavor Framework

[Samuel Bercovici]

Hi,

The discussion about advanced services and scheduling was primarily around 
choosing backbends based on capabilities.
AFAIK, the Nova flavor specify capacity.
So I think that using the term flavor might not match what is intended.
A better word might be capability or group of capabilities.

Is the following what we want to achieve?

* A tenant creates a vip and requires high-available with advanced L7 
and SSL capabilities for production.

* Another tenant creates a vip that requires advanced L7 and SSL 
capabilities for development.

The admin or maybe even the tenant might group such capabilities (ha, L7, SSL) 
and name them advanced-adc and another group of capabilities (no-ha, L7, SSL) 
and name them adc-for-testing.

This leads to an abbreviation of:

* Tenant creates a vip that requires advanced-adc.

* Tenant creates a vip the requires adc-for-testing.

Regards,
-Sam.







From: Eugene Nikanorov [mailto:enikano...@mirantis.com]
Sent: Thursday, February 27, 2014 12:12 AM
To: OpenStack Development Mailing List
Subject: [openstack-dev] [Neutron] Flavor Framework

Hi neutron folks,

I know that there are patches on gerrit for VPN, FWaaS and L3 services that are 
leveraging Provider Framework.
Recently we've been discussing more comprehensive approach that will allow user 
to choose service capabilities rather than vendor or provider.

I've started creating design draft of Flavor Framework, please take a look:
https://wiki.openstack.org/wiki/Neutron/FlavorFramework

It also now looks clear to me that the code that introduces providers for vpn, 
fwaas, l3 is really necessary to move forward to Flavors with one exception: 
providers should not be exposed to public API.
While provider attribute could be visible to administrator (like 
segmentation_id of network), it can't be specified on creation and it's not 
available to a regular user.

Looking forward to get your feedback.

Thanks,
Eugene.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron] Significance of subnet_id for LBaaS Pool

[Samuel Bercovici]

Rabi,

This is correct.
The API does allow you to do so.

-Sam.

-Original Message-
From: Rabi Mishra [mailto:ramis...@redhat.com] 
Sent: Wednesday, February 26, 2014 1:53 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [neutron] Significance of subnet_id for LBaaS Pool


- Original Message -
 From: Mark McClain mmccl...@yahoo-inc.com
 To: OpenStack Development Mailing List (not for usage questions) 
 openstack-dev@lists.openstack.org
 Sent: Wednesday, February 26, 2014 3:43:59 AM
 Subject: Re: [openstack-dev] [neutron] Significance of subnet_id for 
 LBaaS Pool
 
 
 On Feb 25, 2014, at 1:06 AM, Rabi Mishra ramis...@redhat.com wrote:
 
  Hi All,
  
  'subnet_id' attribute of LBaaS Pool resource has been documented as 
  The network that pool members belong to
  
  However, with 'HAProxy' driver, it allows to add members belonging 
  to different subnets/networks to a lbaas Pool.
  
 Rabi-
 
 The documentation is a bit misleading here.  The subnet_id in the pool 
 is used to create the port that the load balancer instance uses to 
 connect with the members.

I assume then the validation in horizon to force the VIP ip from this pool 
subnet is incorrect. i.e VIP address can be from a different subnet.

 
 mark
 
 
 ___
 OpenStack-dev mailing list
 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

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

Re: [openstack-dev] [Neutron][LBaaS] Object Model discussion

[Samuel Bercovici]

+1

From: Youcef Laribi [mailto:youcef.lar...@citrix.com]
Sent: Thursday, February 27, 2014 10:11 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron][LBaaS] Object Model discussion

Hi Eugene,

Thanks for the provided detail. See my comments below.

The point is to be able to share IP address, it really means that two VIPs(as 
we understand them in current model) need to reside within same backend 
(technically they need to share neutron port).

Aren't we leaking some implementation detail here? Why is it that 2 VIPs using 
the same IP address have to be implemented on the same backend? Isn't this a 
driver/technology capability? If a certain driver *requires* that VIPs sharing 
the same IP address have to be on the same backend (whatever a backend 
means), it just needs to ensure that this is the case, but another driver might 
be able to support VIPs sharing the same IP to be on different backends. The 
user really shouldn't care. Did I miss some important detail? It feels like it, 
so please be patient with me :)

I'm sorry this all creates so much confusion.
In order to understand why we need additional entity, you need to keep in mind 
the following things:
 1) We have a notion of root object. From user perspective it represents 
logical instance, from implementation perspective it also represents how that 
instance is mapped to a backend (agent, device), which flavor/provider/driver 
it has, etc
 2) We're trying to change vip-pool relationship to m:n, if vip or pool remain 
the root object, that creates inconsistency because root object can be 
connected to another root object with different parameters.

I'm not against introducing a wrapper entity that correlates the different 
config objects that logically make up one LB config, but I don't think it is 
needed from the logical object model pov IMO. Yes, it might make the 
implementation of the object model for some drivers easier, and I'm OK with 
having it, if it helps. But strictly speaking it is not needed, because a 
driver doesn't have to choose a backend when the pool is created or when a vip 
is created, if it doesn't have enough info yet. It can wait until a vip/pool 
are created and attached to each other, then it would have a clearer idea of 
the backends eligible to host that whole LB configuration. Another driver 
though, might be able to perform the configuration on its backend 
straight-away on each API call, and still be able to comply with the object 
model.

Youcef

On Thu, Feb 27, 2014 at 5:20 AM, Youcef Laribi 
youcef.lar...@citrix.commailto:youcef.lar...@citrix.com wrote:
Hi Eugene,

1) In order to allow real multiple 'vips' per pool feature, we need the 
listener concept.
It's not just a different tcp port, but also a protocol, so session persistence 
and all ssl-related parameters should move to listener.

Why do we need a new 'listener' concept? Since as Sam pointed out, we are 
removing the reference to a pool from the VIP in the current model, isn't this 
enough by itself to allow the model to support multiple VIPs per pool now?

lb-pool-create   --$POOL-1
lb-vip-create .$VIP_ADDRESS,$TCP_PORT, default_pool=$POOL-1... -- $VIP-1
lb-vip-create .$VIP_ADDRESS,$TCP_PORT, default_pool=$POOL-1... -- $VIP-2


Youcef





From: Eugene Nikanorov 
[mailto:enikano...@mirantis.commailto:enikano...@mirantis.com]
Sent: Wednesday, February 26, 2014 1:26 PM
To: Samuel Bercovici
Cc: OpenStack Development Mailing List (not for usage questions)

Subject: Re: [openstack-dev] [Neutron][LBaaS] Object Model discussion

Hi Sam,

I've looked over the document, couple of notes:

1) In order to allow real multiple 'vips' per pool feature, we need the 
listener concept.
It's not just a different tcp port, but also a protocol, so session persistence 
and all ssl-related parameters should move to listener.

2) ProviderResourceAssociation - remains on the instance object (our instance 
object is VIP) as a relation attribute.
Though it is removed from public API, so it could not be specified on creation.
Remember provider is needed for REST call dispatching. The value of provider 
attribute (e.g. ProviderResourceAssociation) is result of scheduling.

3) As we discussed before, pool-vip relation will be removed, but pool reuse 
by different vips (e.g. different backends) will be forbidden for 
implementation simplicity, because this is definitely not a priority right now.
I think it's a fair limitation that can be removed later.

On workflows:
WFs #2 and #3 are problematic. First off, sharing the same IP is not possible 
for other vip for the following reason:
vip is created (with new model) with flavor (or provider) and scheduled to a 
provider (and then to a particular backend), doing so for 2 vips makes address 
reuse impossible if we want to maintain logical API, or otherwise we would need 
to expose implementation details that will allow us to connect two vips to the 
same backend

Re: [openstack-dev] [Neutron][LBaaS] Object Model discussion

[Samuel Bercovici]

From: Eugene Nikanorov [mailto:enikano...@mirantis.com]
Sent: Thursday, February 27, 2014 11:12 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron][LBaaS] Object Model discussion


The point is to be able to share IP address, it really means that two VIPs(as 
we understand them in current model) need to reside within same backend 
(technically they need to share neutron port).

Aren't we leaking some implementation detail here?
I see IP address sharing as user intent, not an implementation detail. Same 
backend could be not only the only obstacle here.
The backend is not exposed anyhow by the API, by the way.
When you create root object with flavor - you really can't control to which 
driver it will be scheduled.
So even if there is driver that is somehow (how?) will allow same IP on 
different backends, user just will not be able to create 2 vips that share IP 
address.

Eugene, is your point that the logical model addresses the capability for IP 
sharing but that it can't be scheduled correctly?


I'm not against introducing a wrapper entity that correlates the different 
config objects that logically make up one LB config, but I don't think it is 
needed from the logical object model pov IMO. Yes, it might make the 
implementation of the object model for some drivers easier, and I'm OK with 
having it, if it helps. But strictly speaking it is not needed, because a 
driver doesn't have to choose a backend when the pool is created or when a vip 
is created, if it doesn't have enough info yet.
That is just not so simple. If you create vip and the pool - this or that way 
it is ready configuration that needs to be deployed, so driver chooses the 
backend. Then you need to add objects to this configuration, by say, adding a 
vip with the same IP on different port.
I don't understand the issue described here.

Currently there is no way you can specify this through the API.
You can specify same IP address and another tcp port, but that call will just 
fail.
Correct, as I have described, the current implementation allocates a 
neutron-port on the first VIP hence the second VIP will fail.
This is an implementation detail, we can discuss how to address. In the logical 
model I have removed the reference to the neutron port and noted this for 
further discussion.

E.g. we'll have subtle limitation in the API instead of consistency.

It can wait until a vip/pool are created and attached to each other, then it 
would have a clearer idea of the backends eligible to host that whole LB 
configuration. Another driver though, might be able to perform the 
configuration on its backend straight-away on each API call, and still be 
able to comply with the object model.
API will not let user to control drivers, that's one of the reasons why it's 
not possible from design standpoint.
I do not see how this relates to controlling drivers. It is the driver 
implementation, the user should not need to control it.

Youcef, can we chat over IRC? I think we could clarify lot more than over ML.

Thanks,
Eugene.


Youcef

On Thu, Feb 27, 2014 at 5:20 AM, Youcef Laribi 
youcef.lar...@citrix.commailto:youcef.lar...@citrix.com wrote:
Hi Eugene,

1) In order to allow real multiple 'vips' per pool feature, we need the 
listener concept.
It's not just a different tcp port, but also a protocol, so session persistence 
and all ssl-related parameters should move to listener.

Why do we need a new 'listener' concept? Since as Sam pointed out, we are 
removing the reference to a pool from the VIP in the current model, isn't this 
enough by itself to allow the model to support multiple VIPs per pool now?

lb-pool-create   --$POOL-1
lb-vip-create .$VIP_ADDRESS,$TCP_PORT, default_pool=$POOL-1... -- $VIP-1
lb-vip-create .$VIP_ADDRESS,$TCP_PORT, default_pool=$POOL-1... -- $VIP-2


Youcef





From: Eugene Nikanorov 
[mailto:enikano...@mirantis.commailto:enikano...@mirantis.com]
Sent: Wednesday, February 26, 2014 1:26 PM
To: Samuel Bercovici
Cc: OpenStack Development Mailing List (not for usage questions)

Subject: Re: [openstack-dev] [Neutron][LBaaS] Object Model discussion

Hi Sam,

I've looked over the document, couple of notes:

1) In order to allow real multiple 'vips' per pool feature, we need the 
listener concept.
It's not just a different tcp port, but also a protocol, so session persistence 
and all ssl-related parameters should move to listener.

2) ProviderResourceAssociation - remains on the instance object (our instance 
object is VIP) as a relation attribute.
Though it is removed from public API, so it could not be specified on creation.
Remember provider is needed for REST call dispatching. The value of provider 
attribute (e.g. ProviderResourceAssociation) is result of scheduling.

3) As we discussed before, pool-vip relation will be removed, but pool reuse 
by different vips (e.g. different backends) will be forbidden for 
implementation simplicity, because

Re: [openstack-dev] [Neutron][LBaaS] Object Model discussion

[Samuel Bercovici]

Hi,

I have added to the wiki page: 
https://wiki.openstack.org/wiki/Neutron/LBaaS/LoadbalancerInstance/Discussion#1.1_Turning_existing_model_to_logical_model
 that points to a document that includes the current model + L7 + SSL.
Please review.

Regards,
-Sam.


From: Samuel Bercovici
Sent: Monday, February 24, 2014 7:36 PM
To: OpenStack Development Mailing List (not for usage questions)
Cc: Samuel Bercovici
Subject: RE: [openstack-dev] [Neutron][LBaaS] Object Model discussion

Hi,

I also agree that the model should be pure logical.
I think that the existing model is almost correct but the pool should be made 
pure logical. This means that the vip pool relationships needs also to 
become any to any.
Eugene, has rightfully pointed that the current state management will not 
handle such relationship well.
To me this means that the state management is broken and not the model.
I will propose an update to the state management in the next few days.

Regards,
-Sam.




From: Mark McClain [mailto:mmccl...@yahoo-inc.com]
Sent: Monday, February 24, 2014 6:32 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron][LBaaS] Object Model discussion


On Feb 21, 2014, at 1:29 PM, Jay Pipes 
jaypi...@gmail.commailto:jaypi...@gmail.com wrote:

I disagree on this point. I believe that the more implementation details
bleed into the API, the harder the API is to evolve and improve, and the
less flexible the API becomes.

I'd personally love to see the next version of the LBaaS API be a
complete breakaway from any implementation specifics and refocus itself
to be a control plane API that is written from the perspective of the
*user* of a load balancing service, not the perspective of developers of
load balancer products.

I agree with Jay.  We the API needs to be user centric and free of 
implementation details.  One of my concerns I've voiced in some of the IRC 
discussions is that too many implementation details are exposed to the user.

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