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"  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"  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

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) 

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"  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: Eich

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"  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'

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" mailto:kevin@pnnl.gov>>
> Reply-To: "OpenStack Development Mailing List (not for usage 
> questions)" 
> 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)" 
> 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 
> mailto:samu...@radware.com>> wrote:
> Thank you all for 

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 
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 
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]

 as there are
> > too many
> > > > 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
> >  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
> >  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"
> >  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
> > > >&g

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 
mailto:liyong.q...@intel.com>> 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 mailto:evge...@radware.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Date: Tuesday, August 25, 2015 at 9:33 AM
To: "OpenStack Development Mailing List (not for usage questions)" 
mailto: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" mailto:vivekj...@ebay.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Date: Tuesday, July 28, 2015 at 6:19 PM
To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Cc: "Tonse, Milan" mailto: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" mailto:vivekj...@ebay.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Date: Tuesday, July 28, 2015 at 4:14 PM
To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Cc: "Tonse, Milan" mailto: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 
mailto:doug...@parksidesoftware.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Date: Tuesday, July 28, 2015 at 4:04 PM
To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Cc: "Tonse, Milan" mailto: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 
mailto: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" mailto:susanne.ba...@hp.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Date: Wednesday, July 15, 2015 at 10:35 AM
To: "Eichberger, German" 
mailto:german.eichber...@hp.com>>, "OpenStack 
Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Cc: "Tonse, Milan" mailto: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" mailto:vivekj...@ebay.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Date: Tuesday, July 14, 2015 at 10:22 AM
To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Cc: "Balle Balle, Susanne" mailto:susanne.ba...@hp.com>>, 
"Tonse, Milan" mailto: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 mailto:amot...@gmail.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Date: Tuesday, July 14, 2015 at 10:09 AM
To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Cc: "Balle, Susanne" mailto:susanne.ba...@hp.com>>, 
"Tonse, Milan" mailto:mto...@ebay.com>>
Subject: Re: [openstack-dev] [neutron][lbaas] Horizon support for neutron-lbaas 
v2

Another option is to create a project under openstack.
designate-dashboard project takes this approach,
and the core team of the project is both horizon-core and designat

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 
mailto: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 
mailto: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 
mailto: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 
mailto: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 
mailto: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 mailto:rsahaos...@gmail.com<mailto:rsahaos...@gmail.com%20%0b%3cmailto:rsahaos...@gmail.com>>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)"
mailto:openstack-dev@lists.openstack.org<mailto: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)"
mailto:openstack-dev@lists.openstack.org<mailto: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
mailto:vijay.venkatacha...@citrix.com<mailto: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.com><mailto: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.com<mailto:kunalhgan...@gmail.com> 
<mailto:kunalhgan...@gmail.com>;
   v.jain...@gmail.com<mailto:v.jain...@gmail.com> <mailto:v.jain...@gmail.com>;
   do...@a10networks.com<mailto: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 

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  
> 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  
>> 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  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  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 >>>> <mailto:rsahaos...@gmail.com>>
>>>>> Reply-To: "OpenStack Development Mailing List (not for usage questions)"
>>>>> >>>> <mailto:openstack-dev@lists.openstack.org>>
>>>>> Date: Thursday, May 28, 2015 at 12:22 PM
>>>>> To: "OpenStack Development Mailing List (not for usage questions)"
>>>>> >>>> <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 
>>>>> >>>> <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 s

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  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 > <mailto:rsahaos...@gmail.com>>
>> Reply-To: "OpenStack Development Mailing List (not for usage questions)"
>> > <mailto:openstack-dev@lists.openstack.org>>
>> Date: Thursday, May 28, 2015 at 12:22 PM
>> To: "OpenStack Development Mailing List (not for usage questions)"
>> > <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
>>><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"
>>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 

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 
mailto: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 mailto:mais...@maishsk.com>>
Sent: Thursday, May 21, 2015 7:45 AM
To: 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 

Sent: Thursday, May 21, 2015 12:49 AM
To: 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 
mailto: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-re

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.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" 
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.

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.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 mailto:mais...@maishsk.com>>
Sent: Thursday, May 21, 2015 7:45 AM
To: 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 

Sent: Thursday, May 21, 2015 12:49 AM
To: 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 
mailto: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.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] [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 Bercovici<mailto: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 
Fedoruk<mailto:evge...@radware.com>, Adam 
Harwell<mailto:adam.harw...@rackspace.com>, Kyle 
Mestery<mailto:mest...@mestery.com>, Brandon 
Logan<mailto:brandon.lo...@rackspace.com>, Johnson, Michael (HP Cloud - 
Corvallis)<mailto:michael.d.john...@hp.com>, Doug 
Wiegley<mailto:do...@a10networks.com>, Samuel 
Bercovici<mailto: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 Bercovici<mailto: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 
Fedoruk<mailto:evge...@radware.com>, Adam 
Harwell<mailto:adam.harw...@rackspace.com>, Kyle 
Mestery<mailto:mest...@mestery.com>, Brandon 
Logan<mailto:brandon.lo...@rackspace.com>, Johnson, Michael (HP Cloud - 
Corvallis)<mailto:michael.d.john...@hp.com>, Doug 
Wiegley<mailto:do...@a10networks.com>, Samuel 
Bercovici<mailto: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]

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 Bercovici<mailto: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 
Fedoruk<mailto:evge...@radware.com>, Adam 
Harwell<mailto:adam.harw...@rackspace.com>, Kyle 
Mestery<mailto:mest...@mestery.com>, Brandon 
Logan<mailto:brandon.lo...@rackspace.com>, Johnson, Michael (HP Cloud - 
Corvallis)<mailto:michael.d.john...@hp.com>, Doug 
Wiegley<mailto:do...@a10networks.com>, Samuel 
Bercovici<mailto: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  
> 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 
mailto:samu...@radware.com>> wrote:
+1


From: Stephen Balukoff 
[mailto:sbaluk...@bluebox.net<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 
mailto: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.net<mailto: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 
mailto: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 proble

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 
mailto: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.net<mailto: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 
mailto: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.com<mailto:brandon.lo...@rackspace.com>]
> Sent: Tuesday, November 25, 2014 12:23 AM
> To: 
> openstack-dev@lists.openstack.org<mailto: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&

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 
>  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

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

[Samuel Bercovici]

 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 
>  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 

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 
mailto: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)--&g

[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 
mailto: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.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 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"  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] 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] 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 
mailto: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.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 
 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 
mailto:carlos.ga...@rackspace.com>> wrote:

On Jul 15, 2014, at 10:55 AM, Samuel Bercovici 
mailto: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.com<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<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 determina

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]

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 
mailto: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.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 
>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
>
Date: Thursday, July 10, 2014 at 10:36 AM
To: "OpenStack Development Mailing List (not for usage questions)" 
>
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 
>
 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.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 mailto:samu...@radware.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Date: Thursday, July 10, 2014 at 10:36 AM
To: "OpenStack Development Mailing List (not for usage questions)" 
mailto: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 
mailto: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.org<mailto:OpenStack-dev@lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



--
Stephen Balukoff
Blue Box Group, LLC
(800)613-4305 x807
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
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 
mailto: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.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] Wednesday meeting agenda topics

[Samuel Bercovici]

I prefer IRC only.
As I am located in Israel and so are other Radware people, it is easier for us 
to use IRC which is also more available from more devices and locations.
OpenStack has chosen IRC as a way to allow different people from different 
places and different speaking capabilities to work together and this has proven 
fine till now.


-Sam.


From: Brandon Logan [mailto:brandon.lo...@rackspace.com]
Sent: Wednesday, July 09, 2014 10:44 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron][LBaaS] Wednesday meeting agenda topics

My personal opinion is I prefer the IRC meetings right now.  I, personally, 
don't get any more value out of a video chat than I would with an IRC meeting.  
However, I know others do get more out of it, and that includes people on my 
team at Rackspace.  Basically, what I am saying is I'd be fine with only doing 
the IRC meeting, at least for now.  Once more focus is put on Octavia, then it 
would need its own meeting.

Thanks,
Brandon

From: Doug Wiegley [do...@a10networks.com]
Sent: Wednesday, July 09, 2014 11:39 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron][LBaaS] Wednesday meeting agenda topics
Have the IRC meetings been time constrained or unproductive?  Having a 
pre-meeting before the IRC meeting risks being exclusionary to the folks that 
can't make it for that timezone, and I haven't seen that the IRC meetings are 
having communication/decision issues, beyond it being bloody dang early.

The webex time slot is open for whatever, and if this is what the group wants 
to use it for, by all means go for it.  But IMO, just cloning the IRC meeting 
is something that doesn't sound right to me.

Thanks,
doug

From: Trevor Vardeman 
mailto:trevor.varde...@rackspace.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Date: Wednesday, July 9, 2014 at 9:34 AM
To: "OpenStack Development Mailing List (not for usage questions) 
[openstack-dev@lists.openstack.org]" 
mailto:openstack-dev@lists.openstack.org>>
Subject: [openstack-dev] [Neutron][LBaaS] Wednesday meeting agenda topics

Hello all!

Earlier in the meetings we discussed using the Wednesday meeting for only 
Octavia discussions.  One of my teammates would like to allocate the Wednesday 
meeting time for face-to-face discussions of the same meeting topics we have on 
Thursday morning.  I think its a good idea to use the time that way at least 
until Octavia is more of a priority.  Does anyone else share this same concern? 
 Do we think that's a good use of that time?

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

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  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-dev] [Neutron][LBaaS] TLS support RST document on Gerrit

[Samuel Bercovici]

nk you really 
gain anything from all the complexity you’re proposing to add to Barbican.

-Douglas M.



On 6/11/14, 12:57 PM, "Doug Wiegley" 
mailto: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" 
>mailto: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.com<mailto: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 
>>> mailto: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] [

Re: [openstack-dev] [Neutron][LBaaS] Weekly Standup Trial

[Samuel Bercovici]

Thank you for this. I think it can stream line the meeting!

From: Jorge Miramontes [mailto:jorge.miramon...@rackspace.com]
Sent: Thursday, June 12, 2014 1:57 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [Neutron][LBaaS] Weekly Standup Trial

Hey Neutron LBaaS folks!

I created the following etherpad in an effort to mitigate the visibility issue 
some of us have been trying to address. Please update it before tomorrow's 
weekly IRC meeting if possible so that the community is aware of what every 
team is currently engaged on. This will definitely help us not duplicate 
efforts and help allocate our combined resources more effectively on a weekly 
basis. Let's try it out and see how it works. Let's take it for a spin tomorrow 
at the weekly meeting! I took the first step and added my team's items.

https://etherpad.openstack.org/p/neutron-lbaas-weekly-standup

Until tomorrow,
--Jorge
___
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 support RST document on Gerrit

[Samuel Bercovici]

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).

 ii.  Meta data 
on TLS container will help tenant to understand that container is in use by 
LBaaS service/VIP listener

iii.  If every 
VIP listener will "register" itself in meta-data while retrieving container, 
how that "registration" will be removed when VIP listener stops using the 
certificate?

Please comment on these points and review the document on gerrit 
(https://review.openstack.org/#/c/98640)
I will update the document with decisions on above topics.

Thank you!
Evgeny


From: Evgeny Fedoruk
Sent: Monday, June 09, 2014 2:54 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [Neutron][LBaaS] TLS support RST document on Gerrit


Hi All,



A Spec. RST  document for LBaaS TLS support was added to Gerrit for review

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



You are welcome to start commenting it for any open discussions.

I tried to address each aspect being discussed, please add comments about 
missing things.



Thanks,

Evgeny

___
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"  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] [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

[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] 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] 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]

+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 
 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

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 
 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

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

[Samuel Bercovici]

Hi Everone,

I would like to defer addressing client authentication and back-end-server 
authentication for a 2nd phase - after Juno.
This means that from looking on 
https://etherpad.openstack.org/p/neutron-lbaas-ssl-l7 , under the "SSL/TLS 
Termination capabilities", not addressing 2.2 and 3.
I think that this would reduce the "effort" of storing certificates information 
to the actual ones used for the termination.
We will leave the discussion on storing the required trusted certificates and 
CA chains for later.

Any objections?

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 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]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]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]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" 
mailto: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 
mailto: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 
mailto: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.org<mailto:OpenStack-dev@lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



--
Stephen Balukoff
Blue Box Group, LLC
(800)613-4305 x807

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




--
Stephen Balukoff
Blue Box Group, LLC
(800)613-4305 x807
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org<mailto:OpenStack-dev@lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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" 
mailto: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 
mailto: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 
mailto: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.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 demar

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]User Stories and sruvey

[Samuel Bercovici]

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



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

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 
mailto: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.com<http://RACKSPACE.COM>]
Sent: Thursday, May 01, 2014 11:28 PM
To: OpenStack Development Mailing List (not for usage questions); 
os.v...@gmail.com<mailto: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<mailto:samu...@radware.com>]
Sent: Thursday, May 01, 2014 12:50 PM
To: OpenStack Development Mailing List (not for usage questions); 
os.v...@gmail.com<mailto: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 secr

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][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.com<mailto: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 anoth

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

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 mailto:samu...@radware.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Date: Tuesday, May 6, 2014 2:56 AM
To: "OpenStack Development Mailing List (not for usage questions)" 
mailto: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]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"  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]

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,

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 
mailto: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=0Ar1FuMFYRhgadDVXZ25NM2NfbGtLTkR0TDFNUWJQUWc&usp=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.com<http://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.htm<http://mysite.com/hello/index.htm>" and direct it 
to Pool A, while "mysite.com/hello/nope.htm<http://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.com<http://mysite.com>" ] } directs to Pool B
In that case, it would match 
"mysite.com/hello/nope.htm<http://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 
mailto: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 n

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" 
mailto: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 mailto:sbaluk...@bluebox.net>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Date: Thursday, May 1, 2014 6:52 PM
To: "OpenStack Development Mailing List (not for usage questions)" 
mailto: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 
mailto: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 de

Re: [openstack-dev] [Neutron][LBaaS] Use Case Question

[Samuel Bercovici]

Usually session timeouts is global value per device.
It should not be specified per listener.

Regards,
   -Sam.

On 2 במאי 2014, at 05:32, "Carlos Garza" 
mailto:carlos.ga...@rackspace.com>> wrote:

   our stingray nodes don't allow you to specify. Its just an enable or disable 
option.
On May 1, 2014, at 7:35 PM, Stephen Balukoff 
mailto:sbaluk...@bluebox.net>>
 wrote:

Question for those of you using the SSL session ID for persistency: About how 
long do you typically set these sessions to persist?

Also, I think this is a cool way to handle this kind of persistence 
efficiency-- I'd never seen it done that way before, eh!

It should also almost go without saying that of course in the case where the 
SSL session is not terminated on the load balancer, you can't do anything else 
with the content (like insert X-Forwarded-For headers or do anything else that 
has to do with L7).

Stephen


On Wed, Apr 30, 2014 at 9:39 AM, Samuel Bercovici 
mailto:samu...@radware.com>> wrote:
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<mailto:trevor.varde...@rackspace.com>]
Sent: Thursday, April 24, 2014 7:26 PM
To: openstack-dev@lists.openstack.org<mailto: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<mailto:OpenStack-dev@lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




--
Stephen Balukoff
Blue Box Group, LLC
(800)613-4305 x807
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org<mailto:OpenStack-dev@lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

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" 
mailto: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 
mailto: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.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][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

[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

[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-rules
 are children of 
security-groups,
 the capability to create a security group with its children in a single call 
is not possible.

b.   The capability to create 
security-group-rules
 using the following URI path 
v2.0/security-groups/{SG-ID}/security-group-rules
 is not supported

c.The capability to update 
security-group-rules
 using the following URI path 
v2.0/security-groups/{SG-ID}/security-group-rules/{SGR-ID}
 is not supported

d.   The notion of creating 
security-group-rules
 (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] 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

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  
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.)

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]

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  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 
>  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] 

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  
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

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



--
Stephen Balukoff
Blue Box Group, LLC
(800)613-4305 x807
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
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  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 your

[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

[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]

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

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

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

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  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 


___
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] [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.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] [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] 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 
mailto: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