Re: [openstack-dev] [lbaas] [octavia] Proposing Lubosz Kosnik (diltram) as Octavia Core

[Eichberger, German]

+1 (even if it doesn’t matter)

From: Stephen Balukoff 
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 

Date: Monday, October 10, 2016 at 4:39 PM
To: "OpenStack Development Mailing List (not for usage questions)" 

Subject: Re: [openstack-dev] [lbaas] [octavia] Proposing Lubosz Kosnik 
(diltram) as Octavia Core

I agree whole-heartedly with johnsom's assessment of diltram's contributions. 
+1 from me!

On Mon, Oct 10, 2016 at 1:06 PM, Michael Johnson 
> wrote:
Greetings Octavia and developer mailing list folks,

I propose that we add Lubosz Kosnik (diltram) as an OpenStack Octavia
core reviewer.

His contributions [1] are in line with other cores and he has been an
active member of our community.  He regularly attends our weekly
meetings, contributes good code, and provides solid reviews.

Overall I think Lubosz would make a great addition to the core review team.

Current Octavia cores, please respond with +1/-1.

Michael

[1] http://stackalytics.com/report/contribution/octavia/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] work on Common Flow Classifier and OVS Agent extension for Newton cycle

[Eichberger, German]

Just to echo others: FWaaS would be interested in this as well so please keep 
us in the loop.

Thanks,
German




On 4/14/16, 7:12 AM, "Sean M. Collins"  wrote:

>Vikram Choudhary wrote:
>> Hi Cathy,
>> 
>> A project called "neutron-classifier [1]" is also there addressing the same
>> use case. Let's sync up and avoid work duplicity.
>> 
>> [1] https://github.com/openstack/neutron-classifier
>
>Agree with Vikram - we have a small git repo that we're using to futz
>around with ideas around how to store classifiers in a way that is
>re-usable by other projects, and create a decent object model.
>
>It's very very rough, and the API is ... kind of ugly right now. That's
>what you get when I steal like 4 Red Bulls and do an all-night coding
>session in Tokyo.
>
>So, It'd be great to get other people involved, get an API hashed out
>that doesn't expose all the nitty gritty DB details (like it currently
>is) and move forward.
>
>-- 
>Sean M. Collins
>
>__
>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] Proposing Bharath Munirajulu as Octavia Core

[Eichberger, German]

+1

Great work Bharath!!



On 3/30/16, 1:56 PM, "Michael Johnson"  wrote:

>I would like to nominate Bharath Munirajulu (bharathm) as a OpenStack
>Octavia core reviewer.
>His contributions [1] are in line with other cores and he has been an
>active member of our community.  I have been impressed with the
>insight and quality of his reviews.
>
>Current Octavia cores, please vote by replying to this e-mail.
>
>Michael
>
>
>[1] http://stackalytics.com/report/contribution/octavia/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] Ihar as *-aas core reviewer

[Eichberger, German]

+1

Glad to have Ihar in *aaS. Much needed help!

Thanks,
German




On 3/10/16, 7:34 AM, "Brandon Logan"  wrote:

>I had the same assumption!  Either way, welcome Ihar, your skills and
>wisdom will be a great benefit.
>
>Thanks,
>Brandon
>
>On Thu, 2016-03-10 at 10:33 +0100, Ihar Hrachyshka wrote:
>> Sean M. Collins  wrote:
>> 
>> > I probably speak for all FwaaS cores when I say - "Welcome!”
>> 
>> …back! Thanks.
>> 
>> >
>> > Frankly I had just assumed he had core privileges for our repo anyway
>> > via an inherited ACL.
>> 
>> Full disclosure: I had all -*aas core privileges before [not thru inherited  
>> ACLs though]. It’s just that lately I lost some of them, probably due to  
>> some cleanup.
>> 
>> To all: it’s not my plan to abuse the powers for anything that is not  
>> required for general success of the current stadium. If I ever decide to  
>> get more involved into a specific *-aas subproject strategically, I will  
>> get back to the corresponding *-aas team for additional approval before I  
>> use the powers for anything beyond those immediate goals set by PTL.
>> 
>> Ihar
>> 
>> __
>> 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]Removing LBaaS v1 - are weready?

[Eichberger, German]

Yes, it’s Database only — though we changed the agent driver in the DB from V1 
to V2 — so if you bring up a V2 with that database it should reschedule all 
your load balancers on the V2 agent driver.

German




On 3/8/16, 3:13 AM, "Samuel Bercovici" <samu...@radware.com> wrote:

>So this looks like only a database migration, right?
>
>-Original Message-
>From: Eichberger, German [mailto:german.eichber...@hpe.com] 
>Sent: Tuesday, March 08, 2016 12:28 AM
>To: OpenStack Development Mailing List (not for usage questions)
>Subject: Re: [openstack-dev] [Neutron][LBaaS]Removing LBaaS v1 - are weready?
>
>Ok, for what it’s worth we have contributed our migration script: 
>https://review.openstack.org/#/c/289595/ — please look at this as a starting 
>point and feel free to fix potential problems…
>
>Thanks,
>German
>
>
>
>
>On 3/7/16, 11:00 AM, "Samuel Bercovici" <samu...@radware.com> wrote:
>
>>As far as I recall, you can specify the VIP in creating the LB so you will 
>>end up with same IPs.
>>
>>-Original Message-
>>From: Eichberger, German [mailto:german.eichber...@hpe.com]
>>Sent: Monday, March 07, 2016 8:30 PM
>>To: OpenStack Development Mailing List (not for usage questions)
>>Subject: Re: [openstack-dev] [Neutron][LBaaS]Removing LBaaS v1 - are weready?
>>
>>Hi Sam,
>>
>>So if you have some 3rd party hardware you only need to change the 
>>database (your steps 1-5) since the 3rd party hardware will just keep 
>>load balancing…
>>
>>Now for Kevin’s case with the namespace driver:
>>You would need a 6th step to reschedule the loadbalancers with the V2 
>>namespace driver — which can be done.
>>
>>If we want to migrate to Octavia or (from one LB provider to another) it 
>>might be better to use the following steps:
>>
>>1. Download LBaaS v1 information (Tenants, Flavors, VIPs, Pools, Health 
>>Monitors , Members) into some JSON format file(s) 2. Delete LBaaS v1 3. 
>>Uninstall LBaaS v1 4. Install LBaaS v2 5. Transform the JSON format 
>>file into some scripts which recreate the load balancers with your 
>>provider of choice —
>>
>>6. Run those scripts
>>
>>The problem I see is that we will probably end up with different VIPs 
>>so the end user would need to change their IPs…
>>
>>Thanks,
>>German
>>
>>
>>
>>On 3/6/16, 5:35 AM, "Samuel Bercovici" <samu...@radware.com> wrote:
>>
>>>As for a migration tool.
>>>Due to model changes and deployment changes between LBaaS v1 and LBaaS v2, I 
>>>am in favor for the following process:
>>>
>>>1. Download LBaaS v1 information (Tenants, Flavors, VIPs, Pools, 
>>>Health Monitors , Members) into some JSON format file(s) 2. Delete LBaaS v1 
>>>3.
>>>Uninstall LBaaS v1 4. Install LBaaS v2 5. Import the data from 1 back 
>>>over LBaaS v2 (need to allow moving from falvor1-->flavor2, need to 
>>>make room to some custom modification for mapping between v1 and v2
>>>models)
>>>
>>>What do you think?
>>>
>>>-Sam.
>>>
>>>
>>>
>>>
>>>-Original Message-
>>>From: Fox, Kevin M [mailto:kevin@pnnl.gov]
>>>Sent: Friday, March 04, 2016 2:06 AM
>>>To: OpenStack Development Mailing List (not for usage questions)
>>>Subject: Re: [openstack-dev] [Neutron][LBaaS]Removing LBaaS v1 - are weready?
>>>
>>>Ok. Thanks for the info.
>>>
>>>Kevin
>>>
>>>From: Brandon Logan [brandon.lo...@rackspace.com]
>>>Sent: Thursday, March 03, 2016 2:42 PM
>>>To: openstack-dev@lists.openstack.org
>>>Subject: Re: [openstack-dev] [Neutron][LBaaS]Removing LBaaS v1 - are weready?
>>>
>>>Just for clarity, V2 did not reuse tables, all the tables it uses are only 
>>>for it.  The main problem is that v1 and v2 both have a pools resource, but 
>>>v1 and v2's pool resource have different attributes.  With the way neutron 
>>>wsgi works, if both v1 and v2 are enabled, it will combine both sets of 
>>>attributes into the same validation schema.
>>>
>>>The other problem with v1 and v2 running together was only occurring when 
>>>the v1 agent driver and v2 agent driver were both in use at the same time.  
>>>This may actually have been fixed with some agent updates in neutron, since 
>>>that is common code.  It needs to be tested out though.
>>>
>>>Thanks,
>>>Brandon
>>>
>>

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

[Eichberger, German]

Hi Kevin,

Floating IP will work in V2 as well :-)

Thanks,
German




On 3/7/16, 2:47 PM, "Fox, Kevin M" <kevin@pnnl.gov> wrote:

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

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

[Eichberger, German]

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

Thanks,
German




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

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

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

[Eichberger, German]

Hi Sam,

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

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

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

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

6. Run those scripts

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

Thanks,
German



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

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

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

[Eichberger, German]

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" >
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
>
Date: Wednesday, March 2, 2016 at 5:17 PM
To: "OpenStack Development Mailing List (not for usage questions)" 
>
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]
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 
> wrote:
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


- Original message -
From: Justin Pomeroy 
>
To: 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 
> 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?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 

Re: [openstack-dev] [neutron] - Changing the Neutron default security group rules

[Eichberger, German]

Hi Jon,

As part of our FWaaS V2 efforts [1] we have been rethinking FWaaS and Security 
Groups. The idea is that eventually to augment Security Groups with some richer 
functionality and provide a default FWaaS policy to add to the (vm) port. 
Furthermore there is a way to “share” Firewall rules with others so you could 
have a set the user could pick from. I think one of the problems highlighted in 
this thread is that we can’t think independently of securing a VM port and the 
perimeter security. To use the example the user wants to have ssh access to his 
VM and he does’t care if it’s blocked at the vm, the router, or some perimeter 
firewall — it should just work. So just looking at Security Groups as this 
thread has done si probably too limited and we likely need a bigger effort to 
unify network security in OpenStack…

Thanks,
German




[1] 
https://www.openstack.org/summit/tokyo-2015/videos/presentation/openstack-neutron-fwaas-roadmap

On 3/3/16, 7:12 AM, "Jonathan Proulx"  wrote:

>On Wed, Mar 02, 2016 at 10:19:50PM +, James Denton wrote:
>:My opinion is that the current stance of ‘deny all’ is probably the safest 
>bet for all parties (including users) at this point. It’s been that way for 
>years now, and is a substantial change that may result in little benefit. 
>After all, you’re probably looking at most users removing the default rule(s) 
>just to add something that’s more restrictive and suits their organization’s 
>security posture. If they aren’t, then it’s possible they’re introducing 
>unnecessary risk. 
>
>
>I agree whole heartedly that reversing the default would be
>disasterous.
>
>It would be good if a site could define their own default, so I could
>say allow ssh from 'our' networks by default (but not the whole
>internet). Or maybe even further restrict egress traffic so that it
>could only talk to internal hosts.
>
>To go a little further down my wish list I'd really like to do be able
>to offer a standard selection of security groups for my site no tjust
>'default', but that may be a bit off this topic.  Briefly my
>motivation is that 'internal' here includes a number of differnt
>netblock some with pretty weird masks so users tend to use 0.0.0.0/0
>when they don't really meant to just to save some rather tedious
>typing at setup time.
>
>-Jon
>
>
>:
>:There should be some onus put on the provider and/or the user/project/tenant 
>to develop a default security policy that meets their needs, even going so far 
>as to make the configuration of their default security group the first thing 
>they do once the project is created. Maybe some changes to the workflow in 
>Horizon could help mitigate some issues users are experiencing with limited 
>access to instances by allowing them to apply some rules at the time of 
>instance creation rather than associating groups consisting of unknown rules. 
>Or allowing changes to the default security group rules of a project when that 
>project is created. There are some ways to enable providers/users to help 
>themselves rather than a blanket default change across all environments. If 
>I’m a user utilizing multiple OpenStack providers, I’m probably bringing my 
>own security groups and rules with me anyway and am not relying on any 
>provider defaults.
>: 
>:
>:James
>:
>:
>:
>:
>:
>:
>:
>:On 3/2/16, 3:47 PM, "Jeremy Stanley"  wrote:
>:
>:>On 2016-03-02 21:25:25 + (+), Sean M. Collins wrote:
>:>> Jeremy Stanley wrote:
>:>> > On 2016-03-03 07:49:03 +1300 (+1300), Xav Paice wrote:
>:>> > [...]
>:>> > > In my mind, the default security group is there so that as people
>:>> > > are developing their security policy they can at least start with
>:>> > > a default that offers a small amount of protection.
>:>> > 
>:>> > Well, not a small amount of protection. The instances boot
>:>> > completely unreachable from the global Internet, so this is pretty
>:>> > significant protection if you consider the most secure system is one
>:>> > which isn't connected to anything.
>:>> 
>:>> This is only if you are booting on a v4 network, which has NAT enabled.
>:>> Many public providers, the network you attach to is publicly routed, and
>:>> with the move to IPv6 - this will become more common. Remember, NAT is
>:>> not a security device.
>:>
>:>I agree that address translation is a blight on the Internet, useful
>:>in some specific circumstances (such as virtual address load
>:>balancing) but otherwise an ugly workaround for dealing with address
>:>exhaustion and connecting conflicting address assignments. I'll be
>:>thrilled when its use trails off to the point that newcomers cease
>:>thinking that's what connectivity with the Internet is supposed to
>:>be like.
>:>
>:>What I was referring to in my last message was the default security
>:>group policy, which blocks all ingress traffic. My point was that
>:>dropping all inbound connections, while a pretty secure
>:>configuration, is unlikely to be the desired 

Re: [openstack-dev] [neutron] Postgres support in (fwaas) tests

[Eichberger, German]

All,

The FWaaS gate hook had implicit support for the postures database which was 
failing in the gate since postgres wasn’t available. Madhu proposed patch [1] 
to remove postgres support. This leads to the wider question if we want to 
support/test postgres with the Neutron gates. I haven’t seen postgres in other 
gate hooks nor do my deployments rely on it so I am in favor of removing/not 
supporting it - but I wanted to check with other before making that 
determination.

Thanks,
German


[1] https://review.openstack.org/#/c/279339/3
__
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] Security/networking questions

[Eichberger, German]

All,

Some more color on (3) our plan was to allow for multiple management nets (and 
I was advocating strongly for that) but that somehow got lost in the 
implementation. 

For (2) we are still working on our operator API which will include that 
functionality once we get there :-)

German



On 2/8/16, 2:17 PM, "Brandon Logan"  wrote:

>Adding my own input:
>
>1. You should be able to add a specific role that the service accounts
>octavia will have.  Then that role can be added to neutron and nova's
>policy.json.  I have not tested this out but that is just a quick off
>the top of my head solution.
>
>2. What johnsom said.  Not ideal for large deployments but for large
>deployers, custom tooling would probably be written for that.
>
>3. Right now in devstack, the mgmt net is a single tenant network owned
>by the octavia service account.  This means that a lot of deployments
>would be limited to ~250 ports on that network (at least from our own
>experience and other's we have talked to).  Deployers can also specify
>that the mgmt network is a provider network which may not have that port
>restriction.
>
>Alternatively, we could create a mgmt net for each load balancer or each
>tenant.  I feel like this would have scaling issues but I haven't
>thought about it enough honestly.  Oh, one reason would be because,
>right now, all controllers would have to be connected to all the mgmt
>nets.  We've actually talked about how to solve this internally, but it
>was more just impromptu whiteboarding sessions.
>
>Thanks,
>Brandon
>
>On Mon, 2016-02-08 at 12:34 -0800, Michael Johnson wrote:
>> 1. Octavia can run under it's own account with the required roles
>> added to that account.
>> 2. Currently the process would be to update the amphora image in
>> glance and trigger a failover of the amphora.
>> 3. It is required.  It is a private network between the Octavia
>> controller and the amphora.  We would like to put the haproxy instance
>> in it's own namespace be we are not there yet.
>> 
>> Michael
>> 
>> On Mon, Feb 8, 2016 at 7:55 AM, Major Hayden  wrote:
>> > -BEGIN PGP SIGNED MESSAGE-
>> > Hash: SHA256
>> >
>> > Hey there,
>> >
>> > I've been doing some work to research how best to implement LBaaSv2 and 
>> > Octavia within the OpenStack-Ansible project.  During that research, I've 
>> > come up with a few questions.
>> >
>> > 1) Is it possible for octavia to operate without providing it with admin 
>> > credentials?
>> >
>> > 2) If a user has amphora LB's deployed and a serious vulnerability is 
>> > released for OpenSSL/haproxy, what should the user do to patch those load 
>> > balancers?
>> >
>> > 3) Is a load balancer management network required?  Putting a LB onto an 
>> > admin tenant network as well as a customer tenant network is challenging 
>> > and bridging those networks could allow an attacker to gain access to 
>> > other things on that admin tenant network.
>> >
>> > Thanks in advance for your time.
>> >
>> > - --
>> > Major Hayden
>> > -BEGIN PGP SIGNATURE-
>> > Version: GnuPG v2
>> >
>> > iQIcBAEBCAAGBQJWuLpuAAoJEHNwUeDBAR+xSF8P/j/KBH2320xB/dGWmy6xOMuJ
>> > DRQCcpEEljIu3O4pU8sF6yGEZX/CIoI3WXGaOBR2g0phWxEus5lhy0DdkPw4ctAa
>> > +UJ7da/s0C7fDbbl09TvWDe3eBoohIunLOm6ABpMT48YipfM0zJLLDEy9kQpDcFg
>> > qg68S5xgtC9zP9CeK1Gvsq5EwjwyX6Mt0a3+G1NMFbUoARLpDDof06YHrNFw73Td
>> > 25AxqToR09yRRXsJfadrjjP9/lGWNBF5f5Oh5WoPnEAiThqN08Ico3geHKIr9s2r
>> > Ift5NueWovCI5MUzOzqwsazKgnVgQXrgaaQwRotl5WdZbstUfWJLO+2If5/z4z8d
>> > AArWLXwsCgIv+I6ZyJ4R3YzJVP3KBY8+8gDswjdMV4Jfy7YV9aragy96ofCEwjuH
>> > p6QOGAKJZASD3cQpOdqVqQt4BaWBXMqm70sNDjfzKRBwweuOZgpNRInluDMbhngs
>> > Yqdj2LGUhuij50gQLa21cYJ5pcuA6yY7KNoiiPLkNbFDJtQo6cjVt/McVFPxN3mu
>> > RKRXpZNBgzf5UAKtrMIyPbw1wioAhbt7lgevfvCOLxHCmu0VxsLzRmOdiON5Exmg
>> > vopL518GJSUx93GhA0cwnqT/ilcTvDxFxPXQrvQK/XPtEQq4U3wBF/kZALK1/4tu
>> > 7hi/GjugHBcixIZGE5sI
>> > =XI9V
>> > -END PGP SIGNATURE-
>> >
>> > __
>> > 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
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 

Re: [openstack-dev] [lbaas] [octavia] Proposing Stephen Balukoff as Octavia Core

[Eichberger, German]

+1

From: Bertrand LALLAU 
>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
>
Date: Friday, February 5, 2016 at 12:26 AM
To: "OpenStack Development Mailing List (not for usage questions)" 
>
Subject: Re: [openstack-dev] [lbaas] [octavia] Proposing Stephen Balukoff as 
Octavia Core

+1

On Fri, Feb 5, 2016 at 3:10 AM, Doug Wiegley 
> wrote:
+1

Doug


> On Feb 4, 2016, at 7:06 PM, Brandon Logan 
> > wrote:
>
> +1
>
>> On Fri, 2016-02-05 at 01:07 +, Adam Harwell wrote:
>> +1 from me!
>> 
>> From: Michael Johnson >
>> Sent: Thursday, February 4, 2016 7:03 PM
>> To: OpenStack Development Mailing List (not for usage questions)
>> Subject: [openstack-dev] [lbaas] [octavia] Proposing Stephen Balukoff as 
>> Octavia Core
>>
>> Octavia Team,
>>
>> I would like to nominate Stephen Balukoff as a core reviewer for the
>> OpenStack Octavia project.  His contributions[1] are in line with
>> other cores and he has been an active member of our community.
>>
>> Octavia cores please vote by replying to this e-mail.
>>
>> Michael
>>
>> [1] http://stackalytics.com/report/contribution/octavia/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
>
> __
> 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] - L3 flavors and issues with usecases for multiple L3 backends

[Eichberger, German]

+1 – Good discussion in this thread.

We once had the plan to go with Gantt (https://wiki.openstack.org/wiki/Gantt) 
rather than re-invent that wheel but… in any case we have a simple framework to 
start experimenting ;-)

German

From: Doug Wiegley 
<doug...@parksidesoftware.com<mailto:doug...@parksidesoftware.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>>
Date: Tuesday, February 2, 2016 at 7:01 PM
To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] [neutron] - L3 flavors and issues with usecases 
for multiple L3 backends

The lbaas use case was something like having one flavor with hardware SSL 
offload and one that doesn’t, e.g. You can easily have multiple backends that 
can do both (in fact, you might even want to let the lower flavor provision 
onto the higher, if you have spare capacity on one and not the other.) And the 
initial “scheduler” in such cases was supposed to be a simple round robin or 
hash, to be revisted later, including the inevitable rescheduling problem, or 
oversubscription issue. It quickly becomes as the same hairy wart that nova has 
to deal with, and all are valid use cases.

doug


On Feb 2, 2016, at 6:43 PM, Kevin Benton 
<blak...@gmail.com<mailto:blak...@gmail.com>> wrote:


So flavors are for routers with different behaviors that you want the user to 
be able to choose from (e.g. High performance, slow but free, packet logged, 
etc). Multiple drivers are for when you have multiple backends providing the 
same flavor (e.g. The high performance flavor has several drivers for various 
bare metal routers).

On Feb 2, 2016 18:22, "rzang" 
<rui.z...@foxmail.com<mailto:rui.z...@foxmail.com>> wrote:
What advantage can we get from putting multiple drivers into one flavor over 
strictly limit one flavor one driver (or whatever it is called).

Thanks,
Rui

-- Original --
From:  "Kevin Benton";<blak...@gmail.com<mailto:blak...@gmail.com>>;
Send time: Wednesday, Feb 3, 2016 8:55 AM
To: "OpenStack Development Mailing List (not for usage 
questions)"<openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>>;
Subject:  Re: [openstack-dev] [neutron] - L3 flavors and issues with usecases 
for multiple L3 backends


Choosing from multiple drivers for the same flavor is scheduling. I didn't mean 
automatically selecting other flavors.

On Feb 2, 2016 17:53, "Eichberger, German" 
<german.eichber...@hpe.com<mailto:german.eichber...@hpe.com>> wrote:
Not that you could call it scheduling. The intent was that the user could pick 
the best flavor for his task (e.g. a gold router as opposed to a silver one). 
The system then would “schedule” the driver configured for gold or silver. 
Rescheduling wasn’t really a consideration…

German

From: Doug Wiegley 
<doug...@parksidesoftware.com<mailto:doug...@parksidesoftware.com><mailto:doug...@parksidesoftware.com<mailto:doug...@parksidesoftware.com>>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org><mailto:openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>>>
Date: Monday, February 1, 2016 at 8:17 PM
To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org><mailto:openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>>>
Subject: Re: [openstack-dev] [neutron] - L3 flavors and issues with use cases 
for multiple L3 backends

Yes, scheduling was a big gnarly wart that was punted for the first pass. The 
intention was that any driver you put in a single flavor had equivalent 
capabilities/plumbed to the same networks/etc.

doug


On Feb 1, 2016, at 7:08 AM, Kevin Benton 
<blak...@gmail.com<mailto:blak...@gmail.com><mailto:blak...@gmail.com<mailto:blak...@gmail.com>>>
 wrote:


Hi all,

I've been working on an implementation of the multiple L3 backends RFE[1] using 
the flavor framework and I've run into some snags with the use-cases.[2]

The first use cases are relatively straightforward where the user requests a 
specific flavor and that request gets dispatched to a driver associated with 
that flavor via a service profile. However, several of the use-cases are based 
around the idea that there is a single flavor with multiple drivers and a 
specific driver will need to be used depending on the placement of the router 
interfaces. i.e. a router cannot be bound to a driver until an

Re: [openstack-dev] [neutron] - L3 flavors and issues with use cases for multiple L3 backends

[Eichberger, German]

Not that you could call it scheduling. The intent was that the user could pick 
the best flavor for his task (e.g. a gold router as opposed to a silver one). 
The system then would “schedule” the driver configured for gold or silver. 
Rescheduling wasn’t really a consideration…

German

From: Doug Wiegley 
>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
>
Date: Monday, February 1, 2016 at 8:17 PM
To: "OpenStack Development Mailing List (not for usage questions)" 
>
Subject: Re: [openstack-dev] [neutron] - L3 flavors and issues with use cases 
for multiple L3 backends

Yes, scheduling was a big gnarly wart that was punted for the first pass. The 
intention was that any driver you put in a single flavor had equivalent 
capabilities/plumbed to the same networks/etc.

doug


On Feb 1, 2016, at 7:08 AM, Kevin Benton 
> wrote:


Hi all,

I've been working on an implementation of the multiple L3 backends RFE[1] using 
the flavor framework and I've run into some snags with the use-cases.[2]

The first use cases are relatively straightforward where the user requests a 
specific flavor and that request gets dispatched to a driver associated with 
that flavor via a service profile. However, several of the use-cases are based 
around the idea that there is a single flavor with multiple drivers and a 
specific driver will need to be used depending on the placement of the router 
interfaces. i.e. a router cannot be bound to a driver until an interface is 
attached.

This creates some painful coordination problems amongst drivers. For example, 
say the first two networks that a user attaches a router to can be reached by 
all drivers because they use overlays so the first driver chosen by the 
framework works  fine. Then the user connects to an external network which is 
only reachable by a different driver. Do we immediately reschedule the entire 
router at that point to the other driver and interrupt the traffic between the 
first two networks?

Even if we are fine with a traffic interruption for rescheduling, what should 
we do when a failure occurs half way through switching over because the new 
driver fails to attach to one of the networks (or the old driver fails to 
detach from one)? It would seem the correct API experience would be switch 
everything back and then return a failure to the caller trying to add an 
interface. This is where things get messy.

If there is a failure during the switch back, we now have a single router's 
resources smeared across two drivers. We can drop the router into the ERROR 
state and re-attempt the switch in a periodic task, or maybe just leave it 
broken.

How should we handle this much orchestration? Should we pull in something like 
taskflow, or maybe defer that use case for now?

What I want to avoid is what happened with ML2 where error handling is still a 
TODO in several cases. (e.g. Any post-commit update or delete failures in 
mechanism drivers will not trigger a revert in state.)

1. https://bugs.launchpad.net/neutron/+bug/1461133
2. 
https://etherpad.openstack.org/p/neutron-modular-l3-router-plugin-use-cases

--
Kevin Benton

__
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][Octavia] Using nova interface extension instead of networks extension

[Eichberger, German]

All,

In a recent patch [1] Bharath and I proposed to replace the call to the nova 
os-networks extension with a call to the nova-interface extension. Apparently 
os-networks is geared towards nova networks and us being neutron I see no 
reason to continue to support it. I have taken to the ML to gather feedback if 
there are cloud operators which don’t have/won't  the nova interface extension 
enabled and need us to support os-networks in Mitaka and beyond.

Thanks,
German

[1] https://review.openstack.org/#/c/273733/4
__
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] [openstack-ansible] LBaaSv2 / Octavia support

[Eichberger, German]

Hi,

As Brandon pointed out you can’t run V1 and V2 at the same time because they 
share the same database tables and interpret columns differently. Hence, at HPE 
we have some proprietary script which takes the V1 database tables and migrates 
them to the V2 format. After that the v2 agent based driver will pick it up and 
create those load balancers.

To migrate agent based driver to Octavia we are thinking self migration since 
people van use the same (ansible) scripts and point them at Octavia.

Thanks,
German



On 1/26/16, 12:40 PM, "Fox, Kevin M"  wrote:

>I assumed they couldn't run on the same host, but would work on different 
>hosts. maybe I was wrong?
>
>I've got a production cloud that's heavily using v1. Having a flag day where 
>we upgrade all from v1 to v2 might be possible, but will be quite painful. If 
>they can be made to co'exist, that would be substantially better.
>
>Thanks,
>Kevin
>
>From: Brandon Logan [brandon.lo...@rackspace.com]
>Sent: Tuesday, January 26, 2016 12:19 PM
>To: openstack-dev@lists.openstack.org
>Subject: Re: [openstack-dev] [openstack-ansible] LBaaSv2 / Octavia support
>
>Oh lbaas versioning was a big deal in the beginning.  Versioning an
>advanced service is a whole other topic and exposed many "interesting"
>issues with the neutron extension and service plugin framework.
>
>The reason v1 and v2 cannot be run together are mainly to get over an
>issue we had with the 2 different agents which woudl have caused a much
>larger refactor.  The v1 OR v2 requirement was basically a hack to get
>around that.  Now that Octavia is the reference implementation and the
>default, relaxing this restriction shouldn't cause any problems really.
>Although, I don't want to 100% guarantee that because it's been a while
>since I was in that world.
>
>If that were relaxed, the v2 agent and v1 agent could still be run at
>the same time which is something to think about.  Come to think about
>it, we might want to revisit whether the v2 and v1 agent running
>together is something that can be easily fixed because many things have
>improved since then AND my knowledge has obviously improved a lot since
>that time.
>
>Glad yall brought this up.
>
>Thanks,
>Brandon
>
>
>On Tue, 2016-01-26 at 14:07 -0600, Major Hayden wrote:
>> On 01/26/2016 02:01 PM, Fox, Kevin M wrote:
>> > I believe lbaas v1 and v2 are different then every other openstack api 
>> > version in that while you can run v1 and v2 at the same time but they are 
>> > completely different systems that just share a name. A lb created in v1 
>> > doesn't show up in v2 or vis a versa. But being able to enable both at 
>> > once gives users a migration path. If you don't do this, all their lb's 
>> > will just disappear when going to octavia. :/
>>
>> I tend to agree, but I'm hearing that it's not possible to run both versions 
>> concurrently.  Brandon might be able to share a little more about the 
>> reasons why.
>>
>> --
>> Major Hayden
>> __
>> 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
__
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] Versioning of the fwaas API

[Eichberger, German]

In LBaaS with going with two distinct endpoints we were sort of skirting the 
backwards compatibility problem, e.g. People need to go full V2 with their 
infrastructure or stay at V1. This was informed by our understanding that 
nobody in his right mind would run V1… but believe me people are crazy :-)

IN LBaaS we also didn’t allow to run V1 and V2 side-by-side aka you had to 
choose only one for your installation. I think we could technically achieve 
that (especially if we have a new DB for V2) but I am not sure if it’s worth 
the hassle...

For LBaaS doing the hard break had side effects: Despite the API being around 
for two cycles we still don’t have Horizon support in LBaaS V2 (which is 
changing) - so if we can avoid the hard break in FWaaS and invest in some API 
compatibility layer all those things like Horizon, Heat, etc. can update at 
their leisure while still working with V2. That is the first thing which needs 
to be decided.

Secondly, if we decide that we allow the use of both versions side-by-side that 
will ask for a different design than if we would just do a hard breaK. So let’s 
assume we have an API compatibility layer than I would think the [3] would work 
with the new stuff using the custom header and the old stuff would not. 

German



On 1/2/16, 4:03 PM, "Brandon Logan"  wrote:

>On Sat, 2016-01-02 at 22:23 +, Sean M. Collins wrote:
>> I was on Twitter and got linked to this blog post[1], and then got
>> linked over to Terraform's docs, and of course I went and checked out
>> its support for OpenStack.
>> 
>> Well, what do you know? It has support for Firewall[2]! Yay!
>> 
>> Based on the fact that we have a spec for a v2 API - the question
>> becomes - how do we not break all this?
>> 
>> I see that LBaaS went the route of
>> 
>> v1 api = "/lb"
>> v2 api = "/lbaas"
>> 
>> https://github.com/openstack/neutron-lbaas/blob/master/neutron_lbaas/extensions/loadbalancer.py#L32
>> 
>> https://github.com/openstack/neutron-lbaas/blob/master/neutron_lbaas/extensions/loadbalancerv2.py#L34
>> 
>
>Yeah, this was kind of a best bad option at the time.
>
>> So - I guess we take the same route with FwaaS - maybe have the endpoint
>> at "/fwaas" and then hopefully we can implement microversioning[3]? That
>> way, we never have to make another endpoint like "/firewall" if we come up 
>> with a v3 API in the 2020s.
>
>I hope too that microversioning will fix this as well, but I'm not so
>sure it will as it is proposed.  I might be overlooking something but I
>can't seem how a neutron microversion can handle both neutron's api and
>a fwaas/lbaas/vpnaas api that may or may not be enabled.
>
>Definitely needs more discussion though, because it would be nice if it
>does solve this problem.
>
>> 
>> [1]: http://tech.paulcz.net/2016/01/openstacks-and-ecosystems/
>> 
>> [2]: https://terraform.io/docs/providers/openstack/r/fw_firewall_v1.html
>> 
>> [3]: 
>> http://specs.openstack.org/openstack/nova-specs/specs/kilo/implemented/api-microversions.html
>> 
>
>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

[openstack-dev] [lbaas] [octavia] Michael Johnson new Subteam PTL

[Eichberger, German]

All,

We are congratulating Michael Johnson (johnsom) as new STPTL [1]. We are 
excited to work with him the next cycle. We would also like to thank Stephen 
Balukoff for his candidacy. Lastly, we would like to thank dougwig for 
conducting/overseeing the election.

Happy Holidays,
German + Brandon



[1] http://civs.cs.cornell.edu/cgi-bin/results.pl?id=E_cf118bc0186899ff
__
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][fwaas] No IRC meeting due to US holiday

[Eichberger, German]

In the meantime please keep reviewing the FWaaS V2 API spec - 
https://review.openstack.org/#/c/243873/7 - so we can close on that next 
Wednesday.

Thanks,
German



On 11/25/15, 6:01 AM, "Sean M. Collins"  wrote:

>We'll start again next week at the 18:30 UTC time
>-- 
>Sean M. Collins
>
>__
>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][fwaas]some architectural advice on fwaas driver writing

[Eichberger, German]

Oğuz,

Eventually service chaining will help but if you need something to work now 
(and most vendors do) focus on how the other drivers are done. Usually copying 
the other drivers will work best. On the LBaaS side things are often integrated 
with tagged vLans but I haven’ read much of the code…

German

From: Oğuz Yarımtepe >
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
>
Date: Monday, November 23, 2015 at 5:01 AM
To: "OpenStack Development Mailing List (not for usage questions)" 
>
Subject: Re: [openstack-dev] [neutron][fwaas]some architectural advice on fwaas 
driver writing

I am checking the vyatta driver now and they replaced l3 agent with their own 
agent and also using a vrouter image for router creation. Our appliance is not 
virtual :)
So for the linkage between services, can service chaining help me?

On Mon, Nov 23, 2015 at 8:25 AM, Germy Lure 
> wrote:
Hi,
Under current FWaaS architecture or framework, only integrating hardware 
firewall is not easy. That requires neutron support service level multiple 
vendors. In another word, vendors must fit each other for their services while 
currently vendors just provides all services through controller.

I think the root cause is Neutron just doesn't known how the network devices 
connect each other.  Neutron provides FW, LB, VPN and other advanced network 
functionalists as services. But as the implementation layer, Neutron needs TOPO 
info to make right decision, routing traffic to the right device. For example, 
from namespace router to hardware firewall, Neutron should add some internal 
routes even extra L3 interfaces according to the connection relationship 
between them. If the firewall service is integrated with router, like Vyatta, 
it's simple. The only thing you need to do is just enable the firewall itself.

All in all, it requires linkage between services, especially between advanced 
services and L3 router.

Germy
.

On Fri, Nov 20, 2015 at 9:19 PM, Somanchi Trinath 
> wrote:
Hi-

As I understand you are not sure on “How to locate the Hardware Appliance” 
which you have as your FW?

Am I right?  If so you can look into, 
https://github.com/jumpojoy/generic_switch kind of approach.

-
Trinath



From: Oguz Yarimtepe 
[mailto:oguzyarimt...@gmail.com]
Sent: Friday, November 20, 2015 5:52 PM
To: OpenStack Development Mailing List (not for usage questions) 
>
Subject: Re: [openstack-dev] [neutron][fwaas]some architectural advice on fwaas 
driver writing

I created a sample driver by looking at vArmour driver that is at the Github 
FWaaS repo. I am planning to call the FW's REST API from the suitable functions.

The problem is, i am still not sure how to locate the hardware appliance. One 
of the FWaaS guy says that Service Chaining can help, any body has an idea or 
how to insert the fw to OpenStack?
On 11/02/2015 02:36 PM, Somanchi Trinath wrote:
Hi-

I’m confused. Do you really have an PoC implementation of what is to be 
achieved?

As I look into these type of Implementations, I would prefer to have proxy 
driver/plugin to get the configuration from Openstack to external 
controller/device and do the rest of the magic.

-
Trinath


__
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




--
Oğuz Yarımtepe
http://about.me/oguzy
__
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] Proposing Bertrand Lallau as Octavia Core

[Eichberger, German]

All,



As I said in a previous e-mail I am really excited about the deep talent in the 
Octavia sub-project. So it is my pleasure to propose Bertrand Lallau (irc 
blallau) as a new core for the OpenStack Neutron Octavia sub project. His 
contributions [1] are in line with other cores and he has been an active member 
of our community. Current cores please vote by replying to this e-mail.

Thanks,
German 


[1] http://stackalytics.com/?project_type=openstack=octavia
__
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] German + Brandon stepping down, Call for Candidates, and No Meeting 11/25

[Eichberger, German]

All,

Brandon and I have decided to step down as Octavia Sub-Team-Leads (STL) [1] and 
we want to thank everybody who helped make Octavia the project it is today. 
Brandon will be dedicating more of his time to other parts of Neutron and I 
will be splitting my time between FWaaS, Octavia, and internal projects. 

Doug (cc’d )has graciously agreed to hold the election and will send out 
details on voting in due time. We are encouraging everyone who wants to be 
considered to submit his/her candidacy to the ML. The Octavia team has a deep 
talent pool and two great candidates Michael and Stephen already stepped 
forward [1]. We are excited to work with the new PTL in the future.

Lastly, due to the Thanksgiving Holidays we are skipping next week meeting.

Happy Holidays,
German + Brandon

[1] 
http://eavesdrop.openstack.org/meetings/octavia/2015/octavia.2015-11-18-20.00.log.html
__
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][qos][fwaas] service groups vs. traffic classifiers

[Eichberger, German]

Ihar,

The Service Group API will be added to FWaaS only and remain experimental in M. 
If the community finds it useful for other areas it can be added to Neutron 
core once it is matures. I think incubating it inside FWaaS will give us the 
velocity to iterate quickly and once it matures a strong API for adoption in 
the wider Neutron.

On the other hand if classifiers mature more quickly/provide the same 
functionality more elegantly we can quickly pivot to that. Since we are trying 
to address an immediate need I would like to experiment with Service Groups 
inside FWaaS first and then use that to shape the classifier API discussion. 
Also, as Sean suggested, we might use the classifier data models under the hood 
— so despite being a different API at first we might arrive at the same shared 
implementation…

Thanks,
German



On 11/13/15, 1:12 AM, "Ihar Hrachyshka"  wrote:

>Paul Carver  wrote:
>
>> On 11/12/2015 3:50 PM, Ihar Hrachyshka wrote:
>>> All I am saying is that IF we merge some classifier API into neutron
>>> core and start using it for core, non-experimental, features, we cannot
>>> later move to some newer version of this API [that you will iterate on]
>>> without leaving a huge pile of compatibility code that would not exist
>>> in the first place if only we thought about proper API in advance. If
>>> that’s what you envision, fine; but I believe it will make adoption of
>>> the ‘evolving’ API a lot slower than it could otherwise be.
>>
>> I don't think I disagree at all. But we don't have a classifier API in  
>> neutron core (unless we consider security groups to be it) and I don't  
>> think anyone is saying that the classifier in networking-sfc should be  
>> merged straight into core as-is. In fact I think we're saying exactly the  
>> opposite, that *a* classifier will sit in networking-sfc, outside of core  
>> neutron, until *some* classifier is merged into core neutron.
>>
>
>That’s why I raised service groups spec in this thread: it seems it’s  
>planned to be added into core, with all compatibility guarantees; and was  
>planned for adoption for the new fwaas API (as per summit sessions). At  
>least I haven’t found anything in their spec that would suggest it’s  
>experimental.
>
>It may mean that at the moment when you arrive to some classifier API that  
>you can claim the best we can get, there can be a rival classifier API in  
>the core tree already.
>
>> The point of networking-sfc isn't the classifier. A classifier is simply  
>> a prerequisite. So by all means let's work on defining and merging into  
>> core neutron a classifier that we can consider non-experimental and  
>> stable for all features to share and depend on, but we don't want SFC to  
>> be non-functional while we wait for that to happen. We can call the  
>> networking-sfc classifier experimental a slap a warning on that it'll be  
>> replaced with the core neutron classifier once such a thing has been  
>> implemented.
>
>__
>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][vpnaas] VPNaaS project status

[Eichberger, German]

Thanks for your hard work. Really appreciated!!

Looking forward what you tackle next :-)

All the best.
German

From: "Sridar Kandaswamy (skandasw)"
Reply-To: "OpenStack Development Mailing List (not for usage questions)"
Date: Thursday, November 12, 2015 at 7:55 AM
To: "OpenStack Development Mailing List (not for usage questions)"
Subject: Re: [openstack-dev] [neutron][vpnaas] VPNaaS project status

Could not agree more. Thanks very much Paul.  And thanks also for always being 
a sounding board for common things across FWaaS and VPNaaS.

Thanks

Sridar

From: Madhusudhan Kandadai 
>
Reply-To: OpenStack List 
>
Date: Thursday, November 12, 2015 at 7:28 AM
To: OpenStack List 
>
Subject: Re: [openstack-dev] [neutron][vpnaas] VPNaaS project status

Thanks Paul for leading over the previous releases. Looking forward to have 
your guidance in neutron.

On Thu, Nov 12, 2015 at 8:48 PM, Kyle Mestery 
> wrote:
On Thu, Nov 12, 2015 at 9:56 AM, Paul Michali 
> wrote:
Neutron community,

During the past several releases, while leading the VPNaaS project, I've seen 
many great enhancements and features added to the VPNaaS project by the 
community, including support for StrongSwan, Libreswan, completion of the 
project split out, functional and rally tests, endpoint groups, multiple local 
subnets, vendor drivers, etc.

There is still work needed (certificate support the most important, followed by 
documentation and scale testing), but there is a solid (in my bias and 
subjective opinion :) foundation in place for people to play with this 
capability.

As I mentioned to Armando at the summit, it's time for me to move on to other 
areas of Neutron, and as such, I'm stepping down as VPNaaS chair and wrapping 
up work on the project over the next few weeks. I'll still try to review VPNaaS 
commits as much as possible, and be available to advise in this area.

Towards that end, I've updated the VPNaaS wiki page 
(https://wiki.openstack.org/wiki/Meetings/VPNaaS) to list what I think are 
outstanding work that can be done in this area, from important to wish items.  
Meetings have transitioned to on-demand, and future meetings can either be done 
as an on-demand topic in the Neutron IRC meeting, or as an on-demand special 
meeting.

I'll go through the VPNaaS bugs in Launchpad and comment on them, as to my 
opinion of importance, priority, relevance, etc.

Regards,


Thanks for all your hard work over the previous releases Paul! Looking forward 
to what you'll be doing next in Neutron.

Thanks,
Kyle

PCM (pc_m)

__
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][qos][fwaas] service groups vs. traffic classifiers

[Eichberger, German]

Sean and Mickey +1

As much as I like us using the same API to create classifiers (users only need 
to learn one way) I think for the short term we should work with our own 
constructs and rely on a common data model. That will allow us to iterate 
faster on the REST API level and not have premature constraints (as Mickey 
mentions).

Midterm we should create some common API which is a superset of the 
functionality of all projects using it.

German



On 11/10/15, 5:30 AM, "Sean M. Collins"  wrote:

>On Mon, Nov 09, 2015 at 07:58:34AM EST, Jay Pipes wrote:
>> In short, my preference, in order, would be:
>> 
>> 1) Enhance/evolve the existing security-groups and security-group-rules API
>> in Neutron to support more generic classification of traffic from L2 to L7,
>> using mostly the modeling that Sean has put together in his PoC library.
>
>
>
>> 2) Keep the security-group API as-is to keep outward compatibility with AWS.
>> Create a single, new service-groups and service-group-rules API for L2 to L7
>> traffic classification using mostly the modeling that Sean has put together.
>> Remove the networking-sfc repo and obselete the classifier spec. Not sure
>> what should/would happen to the FWaaS API, frankly.
>> 
>
>I'd prefer that since we're already redesigning the Firewall API that we
>go ahead and make the Firewall API more expressive, so users can
>classify L2 to L7 traffic and then make filtering decisions. Let's not
>complicate the Security Group API with more advanced features that we
>just bolt on. So my vote is for #2 - with slight adjustments. I still
>think the networking-sfc repo should stay around, and that collaboration
>on the common classifier framework should happen, so that we can start
>both projects (sfc and fwaas) with a common datamodel for the classifier
>piece.
>
>As to the REST-ful API for creating classifiers, I don't know if it
>should reside in the networking-sfc project. It's a big enough piece
>that it will most likely need to be its own endpoint and repo, and have
>stakeholders from other projects, not just networking-sfc. That will
>take time and quite a bit of wrangling, so I'd like to defer that for a
>bit and just work on all the services having the same data model, where
>we can make changes quickly, since they are not visible to API
>consumers.
>
>-- 
>Sean M. Collins
>
>__
>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][stable] should we open gate for per sub-project stable-maint teams?

[Eichberger, German]

This seems we will get some more velocity which is good!!
+1

German

From: Gary Kotton >
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
>
Date: Wednesday, November 4, 2015 at 5:24 AM
To: OpenStack Development Mailing List 
>
Subject: Re: [openstack-dev] [neutron][stable] should we open gate for per 
sub-project stable-maint teams?



From: "mest...@mestery.com" 
>
Reply-To: OpenStack List 
>
Date: Tuesday, November 3, 2015 at 7:09 PM
To: OpenStack List 
>
Subject: Re: [openstack-dev] [neutron][stable] should we open gate for per 
sub-project stable-maint teams?

On Tue, Nov 3, 2015 at 10:49 AM, Ihar Hrachyshka 
> wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi all,

currently we have a single neutron-wide stable-maint gerrit group that
maintains all stable branches for all stadium subprojects. I believe
that in lots of cases it would be better to have subproject members to
run their own stable maintenance programs, leaving
neutron-stable-maint folks to help them in non-obvious cases, and to
periodically validate that project wide stable policies are still honore
d.

I suggest we open gate to creating subproject stable-maint teams where
current neutron-stable-maint members feel those subprojects are ready
for that and can be trusted to apply stable branch policies in
consistent way.

Note that I don't suggest we grant those new permissions completely
automatically. If neutron-stable-maint team does not feel safe to give
out those permissions to some stable branches, their feeling should be
respected.

I believe it will be beneficial both for subprojects that would be
able to iterate on backports in more efficient way; as well as for
neutron-stable-maint members who are often busy with other stuff, and
often times are not the best candidates to validate technical validity
of backports in random stadium projects anyway. It would also be in
line with general 'open by default' attitude we seem to embrace in
Neutron.

If we decide it's the way to go, there are alternatives on how we
implement it. For example, we can grant those subproject teams all
permissions to merge patches; or we can leave +W votes to
neutron-stable-maint group.

I vote for opening the gates, *and* for granting +W votes where
projects showed reasonable quality of proposed backports before; and
leaving +W to neutron-stable-maint in those rare cases where history
showed backports could get more attention and safety considerations
[with expectation that those subprojects will eventually own +W votes
as well, once quality concerns are cleared].

If we indeed decide to bootstrap subproject stable-maint teams, I
volunteer to reach the candidate teams for them to decide on initial
lists of stable-maint members, and walk them thru stable policies.

Comments?


As someone who spends a considerable amount of time reviewing stable backports 
on a regular basis across all the sub-projects, I'm in favor of this approach. 
I'd like to be included when selecting teams which are approproate to have 
their own stable teams as well. Please include me when doing that.

+1


Thanks,
Kyle

Ihar
-BEGIN PGP SIGNATURE-

iQEcBAEBAgAGBQJWOOWkAAoJEC5aWaUY1u57sVIIALrnqvuj3t7c25DBHvywxBZV
tCMlRY4cRCmFuVy0VXokM5DxGQ3VRwbJ4uWzuXbeaJxuVWYT2Kn8JJ+yRjdg7Kc4
5KXy3Xv0MdJnQgMMMgyjJxlTK4MgBKEsCzIRX/HLButxcXh3tqWAh0oc8WW3FKtm
wWFZ/2Gmf4K9OjuGc5F3dvbhVeT23IvN+3VkobEpWxNUHHoALy31kz7ro2WMiGs7
GHzatA2INWVbKfYo2QBnszGTp4XXaS5KFAO8+4H+HvPLxOODclevfKchOIe6jthH
F1z4JcJNMmQrQDg1WSqAjspAlne1sqdVLX0efbvagJXb3Ju63eSLrvUjyCsZG4Q=
=HE+y
-END PGP SIGNATURE-

__
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] [Tempest] where fwaas tempest tests should be?

[Eichberger, German]

Hi,

Just moving the tests is not sufficient since the gate jobs also need
adjustment.

German

On 10/16/15, 1:50 AM, "Takashi Yamamoto"  wrote:

>hi,
>
>On Thu, Oct 15, 2015 at 11:17 PM, Matthew Treinish 
>wrote:
>> On Thu, Oct 15, 2015 at 08:25:40PM +0900, Takashi Yamamoto wrote:
>>> hi,
>>>
>>> i'm looking in fwaas tempest tests and have a question about code
>>>location.
>>>
>>> currently,
>>>
>>> - fwaas api tests and its rest client are in neutron repo
>>
>> This is a bad situation because it means that we're directly coupling
>>fwaas to
>> the neutron repo. Everything that depends on fwaas should be separate
>>and self
>> contained outside of the neutron repo. The longer that things are like
>>this it
>> will just lead to more headaches down the road.
>>
>>> - there are no fwaas scenario tests
>>>
>>> eventually,
>>>
>>> - fwaas api tests should be moved into neutron-fwaas repo
>>> - fwaaa scenario tests should be in neutron-fwaas repo too.
>>
>> This is definitely the right direction.
>
>if i move fwaas tests from neutron to neutron-fwaas, [1]
>is there easy way to run them together with the rest of neutron api tests
>for gate-neutron-dsvm-api job?
>
>[1] https://review.openstack.org/#/c/235790/
>
>>
>>> - the rest client will be in tempest-lib
>>
>> The discussion on which clients are in scope for tempest-lib hasn't
>>fully
>> happened yet. For right now we're taking a conservative approach and
>>the clients
>> can live in tempest-lib if there are tests in the tempest tree using
>>them.
>> (which is not fwaas) This might change eventually, (there will be a
>>summit
>> session on it) but for right now I'd say the fwaas clients should live
>>in the
>> fwaas repo. (they can and likely should still be based on the
>>tempest-lib rest
>> client)
>>
>> -Matt Treinish
>>
>> 
>>_
>>_
>> 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][fwaas] fwaas driver development steps

[Eichberger, German]

Hi Oğuz,

Thank you for starting to contribute to Neutron FWaaS. We just got together as 
a new core team and we are still learning the ropes there. Please be also 
advised that we are planning some changes in future versions (especially now as 
the API has been deprecated).

In any case a good place to start is looking at the other drivers as well as 
attending our weekly irc meetings to ask questions. We also have an irc channel 
where you can ask questions as well.

Hope that points you in the right direction,
German

From: Oğuz Yarımtepe >
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
>
Date: Tuesday, October 13, 2015 at 7:58 AM
To: 
"openstack-dev@lists.openstack.org" 
>
Subject: [openstack-dev] [neutron][fwaas] fwaas driver development steps

Hi,

I need to write a driver for our friewall hardware to integrate it to our 
Openstack environment. I checked the Neutron Development wiki page, FWaaS wiki 
page, fwaas driver codes written at the Github. Since there is no clear 
documentation about howto write a direwall driver for Neutron i need some 
guidance. The firewall driver will have a REST API that can be used to 
configure it so what i need now is how i will debug and develop neutron while 
writing the driver. What is the suggested way? Which functions should be 
implemented? I had seen the abstract functions like, create_friewall, 
update_firewall, the question is what are the context of the parameters coming 
there. So either i should debug one of them step by step like the iptables 
driver or some clear definition i should have.

What is the right way to do it?



--
Oğuz Yarımtepe
http://about.me/oguzy
__
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] Proposing new meeting time Wednesday 16:00 UTC

[Eichberger, German]

Brandon,

We had some requests in the past and I just wanted to float the idea on
the ML since we are starting a new cycle...

Thanks,
German

On 9/27/15, 10:12 PM, "Brandon Logan" <brandon.lo...@rackspace.com> wrote:

>Is there a lot of people requesting this meeting change?
>
>Thanks,
>Brandon
>
>On Fri, 2015-09-25 at 23:58 +, Eichberger, German wrote:
>> All,
>> 
>> In our last meeting [1] we discussed moving the meeting earlier to
>> accommodate participants from the EMEA region. I am therefore proposing
>>to
>> move the meeting to 16:00 UTC on Wednesday. Please respond to this
>>e-mail
>> if you have alternate suggestions. I will send out another e-mail
>> announcing the new time and the date we will start with that.
>> 
>> Thanks,
>> German
>> 
>> [1] 
>> 
>>http://eavesdrop.openstack.org/meetings/octavia/2015/octavia.2015-09-23-2
>>0.
>> 00.log.html
>> 
>> 
>> 
>>_
>>_
>> 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] [lbaas] [octavia] Proposing new meeting time Wednesday 16:00 UTC

[Eichberger, German]

All,

In our last meeting [1] we discussed moving the meeting earlier to
accommodate participants from the EMEA region. I am therefore proposing to
move the meeting to 16:00 UTC on Wednesday. Please respond to this e-mail
if you have alternate suggestions. I will send out another e-mail
announcing the new time and the date we will start with that.

Thanks,
German

[1] 
http://eavesdrop.openstack.org/meetings/octavia/2015/octavia.2015-09-23-20.
00.log.html


__
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

[Eichberger, German]

Great news! From the Octavia end I totally support that choiceŠ

German

On 9/16/15, 3:40 PM, "Al Miller"  wrote:

>+1
>
>Al
>
>
>> -Original Message-
>> From: Doug Wiegley [mailto:doug...@parksidesoftware.com]
>> Sent: Wednesday, September 16, 2015 3:34 PM
>> 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


__
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] PTL Non-Candidacy

[Eichberger, German]

I am with Kevin — we will just write you into the ballot!

Kyle, you rock! Thanks for all the support and help — and hit me up if you are 
short on gin :-)

German


From: Kevin Benton >
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
>
Date: Friday, September 11, 2015 at 2:35 PM
To: "OpenStack Development Mailing List (not for usage questions)" 
>
Subject: Re: [openstack-dev] [neutron] PTL Non-Candidacy

This has the works "PTL" and "Candidacy" in the subject. I think that's enough 
to make it on the ballot!

On Fri, Sep 11, 2015 at 2:12 PM, Kyle Mestery 
> wrote:
I'm writing to let everyone know that I do not plan to run for Neutron PTL for 
a fourth cycle. Being a PTL is a rewarding but difficult job, as Morgan 
recently put it in his non-candidacy email [1]. But it goes further than that 
for me. As Flavio put it in his post about "Being a PTL" [2], it's a full time 
job. In the case of Neutron, it's more than a full time job, it's literally an 
always on job.

I've tried really hard over my three cycles as PTL to build a stronger web of 
trust so the project can grow, and I feel that's been accomplished. We have a 
strong bench of future PTLs and leaders ready to go, I'm excited to watch them 
lead and help them in anyway I can.

As was said by Zane in a recent email [3], while Heat may have pioneered the 
concept of rotating PTL duties with each cycle, I'd like to highly encourage 
Neutron and other projects to do the same. Having a deep bench of leaders 
supporting each other is important for the future of all projects.

See you all in Tokyo!
Kyle

[1] 
http://lists.openstack.org/pipermail/openstack-dev/2015-September/074157.html
[1] 
http://lists.openstack.org/pipermail/openstack-dev/2015-September/073986.html
[2] 
http://lists.openstack.org/pipermail/openstack-dev/2015-September/074242.html

__
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




--
Kevin Benton

__
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][horizon][neutron][L3][dvr][fwaas] FWaaS

[Eichberger, German]

Hi Bharath,

I am wondering if you can file this as a launchpad bug, please.

Thanks,
German

From: bharath >
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
>
Date: Wednesday, September 2, 2015 at 9:21 AM
To: "OpenStack Development Mailing List (not for usage questions)" 
>
Subject: [openstack-dev] [Neutron][horizon][neutron][L3][dvr][fwaas] FWaaS

Hi,

Horizon seems to be broken.

When i try to add new firewall rule , horizon broken with "'NoneType' object 
has no attribute 'id'" Error.
This was fine about 10 hours back. Seems one of the  latest commit broken it.


Traceback in horizon:


2015-09-02 16:15:35.337872 return nodelist.render(context)
2015-09-02 16:15:35.337877   File 
"/usr/local/lib/python2.7/dist-packages/django/template/base.py", line 903, in 
render
2015-09-02 16:15:35.337893 bit = self.render_node(node, context)
2015-09-02 16:15:35.337899   File 
"/usr/local/lib/python2.7/dist-packages/django/template/debug.py", line 79, in 
render_node
2015-09-02 16:15:35.337903 return node.render(context)
2015-09-02 16:15:35.337908   File 
"/usr/local/lib/python2.7/dist-packages/django/template/debug.py", line 89, in 
render
2015-09-02 16:15:35.337913 output = self.filter_expression.resolve(context)
2015-09-02 16:15:35.337917   File 
"/usr/local/lib/python2.7/dist-packages/django/template/base.py", line 647, in 
resolve
2015-09-02 16:15:35.337922 obj = self.var.resolve(context)
2015-09-02 16:15:35.337927   File 
"/usr/local/lib/python2.7/dist-packages/django/template/base.py", line 787, in 
resolve
2015-09-02 16:15:35.337931 value = self._resolve_lookup(context)
2015-09-02 16:15:35.337936   File 
"/usr/local/lib/python2.7/dist-packages/django/template/base.py", line 825, in 
_resolve_lookup
2015-09-02 16:15:35.337940 current = getattr(current, bit)
2015-09-02 16:15:35.337945   File 
"/opt/stack/horizon/openstack_dashboard/wsgi/../../horizon/utils/html.py", line 
59, in attr_string
2015-09-02 16:15:35.337950 return flatatt(self.get_final_attrs())
2015-09-02 16:15:35.337954   File 
"/opt/stack/horizon/openstack_dashboard/wsgi/../../horizon/utils/html.py", line 
42, in get_final_attrs
2015-09-02 16:15:35.337959 final_attrs['class'] = self.get_final_css()
2015-09-02 16:15:35.337964   File 
"/opt/stack/horizon/openstack_dashboard/wsgi/../../horizon/utils/html.py", line 
47, in get_final_css
2015-09-02 16:15:35.337981 default = " ".join(self.get_default_classes())
2015-09-02 16:15:35.337986   File 
"/opt/stack/horizon/openstack_dashboard/wsgi/../../horizon/tables/base.py", 
line 792, in get_default_classes
2015-09-02 16:15:35.337991 if not self.url:
2015-09-02 16:15:35.337995   File 
"/opt/stack/horizon/openstack_dashboard/wsgi/../../horizon/tables/base.py", 
line 756, in url
2015-09-02 16:15:35.338000 url = self.column.get_link_url(self.datum)
2015-09-02 16:15:35.338004   File 
"/opt/stack/horizon/openstack_dashboard/wsgi/../../horizon/tables/base.py", 
line 431, in get_link_url
2015-09-02 16:15:35.338009 return self.link(datum)
2015-09-02 16:15:35.338014   File 
"/opt/stack/horizon/openstack_dashboard/wsgi/../../openstack_dashboard/dashboards/project/firewalls/tables.py",
 line 261, in get_policy_link
2015-09-02 16:15:35.338019 kwargs={'policy_id': datum.policy.id})
2015-09-02 16:15:35.338023 AttributeError: 'NoneType' object has no attribute 
'id'



Thanks,
bharath

__
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

[Eichberger, German]

Hi Evgeny,

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

Thanks,
German

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

Hello

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


Regards,
Evg


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

Re: [openstack-dev] [neutron] I am pleased to propose two new Neutron API/DB/RPC core reviewers!

[Eichberger, German]

Congratulations Brandon and Russell!!

And I agree with Doug — I expect a grande venue ;-)

German

From: Paul Michali p...@michali.netmailto:p...@michali.net
Reply-To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Date: Sunday, August 23, 2015 at 2:04 PM
To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [neutron] I am pleased to propose two new Neutron 
API/DB/RPC core reviewers!

Congratulations Brandon and Russell!

On Sat, Aug 22, 2015 at 6:36 PM Doug Wiegley 
doug...@parksidesoftware.commailto:doug...@parksidesoftware.com wrote:
New guys have to plan the liberty summit get together, right? :)


Doug


On Aug 22, 2015, at 2:06 PM, Kyle Mestery 
mest...@mestery.commailto:mest...@mestery.com wrote:

It's been over a week, so I'd like to welcome Brandon and Russell to the 
API/DB/RPC team in Neutron!

Kyle

On Wed, Aug 12, 2015 at 6:45 AM, Kyle Mestery 
mest...@mestery.commailto:mest...@mestery.com wrote:
It gives me great pleasure to propose Russell Bryant and Brandon Logan as core 
reviewers in the API/DB/RPC area of Neutron. Russell and Brandon have both been 
incredible contributors to Neutron for a while now. Their expertise has been 
particularly helpful in the area they are being proposed in. Their review stats 
[1] place them both comfortably in the range of existing Neutron core 
reviewers. I expect them to continue working with all community members to 
drive Neutron forward for the rest of Liberty and into Mitaka.

Existing DB/API/RPC core reviewers (and other Neutron core reviewers), please 
vote +1/-1 for the addition of Russell and Brandon.

Thanks!
Kyle

[1] http://stackalytics.com/report/contribution/neutron-group/90

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.orgmailto:openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://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][lbaasv2]How to configure lbaasv2 in devstack

[Eichberger, German]

Please make sure to check the previous discussion about the effort Vivek is 
leading [1]

[1] https://www.mail-archive.com/openstack-dev@lists.openstack.org/msg58328.html



From: jiangshan0...@139.commailto:jiangshan0...@139.com 
jiangshan0...@139.commailto:jiangshan0...@139.com
Reply-To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Date: Monday, July 20, 2015 at 11:06 PM
To: Yingjun Li liyingjun1...@gmail.commailto:liyingjun1...@gmail.com, 
OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [neutron][lbaasv2]How to configure lbaasv2 in 
devstack

Thanks a lot.


jiangshan0...@139.commailto:jiangshan0...@139.com

From: Yingjun Limailto:liyingjun1...@gmail.com
Date: 2015-07-21 10:07
To: OpenStack Development Mailing List (not for usage 
questions)mailto:openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [neutron][lbaasv2]How to configure lbaasv2 in 
devstack

Currently horizon doesn’t support LBaaS v2, there is a blueprint related but it 
doesn’t implement yet: 
https://blueprints.launchpad.net/horizon/+spec/lbaas-v2-panel

2015-07-21 9:49 GMT+08:00 jiangshan0...@139.commailto:jiangshan0...@139.com 
jiangshan0...@139.commailto:jiangshan0...@139.com:
Hi all,

 I have configured these lines in my devstack localrc

# Load the external LBaaS plugin.
enable_plugin neutron-lbaas 
https://git.openstack.org/openstack/neutron-lbaas

## Neutron - Load Balancing
ENABLED_SERVICES+=,q-lbaasv2

# Horizon (Dashboard UI) - (always use the trunk)
ENABLED_SERVICES+=,horizon

# Neutron - Networking Service
# If Neutron is not declared the old good nova-network will be used
ENABLED_SERVICES+=,q-svc,q-agt,q-dhcp,q-l3,q-meta,neutron


And I can use lbaasv2 through CLI. But do not have the loadbalance 
pages in dashboard（the other pages like routers, networks are all right).

Is there anything wrong in my configuration? Or maybe some 
configuration need to be done in horizon to use lbaasv2?

Thanks a lot for your help!




__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://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

[Eichberger, German]

Hi,

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

Thanks,
German

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

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

Thanks,
Vivek

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

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 designate-core.
We can do the similar approach. Thought?

I have one question.
Do we have a separate place forever or do we want to merge horizon repo
once the implementation are available.
If we have a separate repo for LBaaS v2 panel, we need to release it separately.

I am not sure I am available at LBaaS meeting, but I would like to help
this efforts as a core from horizon and neutron.

Akihiro


2015-07-15 1:52 GMT+09:00 Doug Wiegley 
doug...@parksidesoftware.commailto:doug...@parksidesoftware.com:
I’d be good submitting it to the neutron-lbaas repo, under a horizon/ 
directory. We can iterate there, and talk with the Horizon team about how best 
to integrate. Would that work?

Thanks,
doug

 On Jul 13, 2015, at 3:05 PM, Jain, Vivek 
 vivekj...@ebay.commailto:vivekj...@ebay.com wrote:

 Hi German,

 We integrated UI with LBaaS v2 GET APIs. We have created all panels for
 CREATE and UPDATE as well.
 Plan is to share our code with community on stackforge for more
 collaboration from the community.

 So far Ganesh from cisco has shown interest in helping with some work. It
 will be great if we can get more hands.

 Q: what is the process for hosting in-progress project on stackforge? Can
 someone help me here?

 Thanks,
 Vivek

 On 7/10/15, 11:40 AM, Eichberger, German 
 german.eichber...@hp.commailto:german.eichber...@hp.com
 wrote:

 Hi Vivek,

 Hope things are well. With the Midccyle next week I am wondering if you
 made any progress and/or how we can best help with the panels.

 Thanks,
 German

 From: Jain, Vivek 
 vivekj...@ebay.commailto:vivekj...@ebay.commailto:vivekj...@ebay.commailto:vivekj...@ebay.com
 Reply-To: OpenStack Development Mailing List (not for usage questions)
 openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.orgmailto:openstack-...@lists.openstack.ormailto:openstack-...@lists.openstack.or
 g
 Date: Wednesday, April 8, 2015 at 3:32 PM
 To: OpenStack Development Mailing List (not for usage questions)
 openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.orgmailto:openstack-...@lists.openstack.ormailto:openstack-...@lists.openstack.or
 g
 Cc: Balle Balle, Susanne
 susanne.ba...@hp.commailto:susanne.ba...@hp.commailto:susanne.ba...@hp.commailto:susanne.ba...@hp.com,
  Tonse, Milan
 mto...@ebay.commailto:mto...@ebay.commailto:mto...@ebay.commailto:mto...@ebay.com
 Subject: Re: [openstack-dev] [neutron][lbaas] Horizon support for
 neutron-lbaas v2

 Thanks German for the etherpad link. If you have any documentation for
 flows, please share those too.

 I will work with my team at ebay to publish wireframes for design we are
 working on. It will be mostly along the lines I demo’ed in Paris.

 Thanks,
 Vivek

 From: Eichberger, German
 german.eichber...@hp.commailto:german.eichber...@hp.commailto:german.eichber...@hp.commailto:german.eichber...@hp.com
 Reply-To: OpenStack Development Mailing List (not for usage questions)
 openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.orgmailto:openstack-...@lists.openstack.ormailto:openstack-...@lists.openstack.or
 g
 Date: Wednesday, April 8, 2015 at 11:24 AM
 To: OpenStack Development Mailing List (not for usage questions)
 openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.orgmailto:openstack

[openstack-dev] [lbaas] [octavia] No meeting today 7/15

[Eichberger, German]

All,

This week is the L4-L7 mid cycle so we will skip today¹s meeting ‹

German


__
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] Horizon support for neutron-lbaas v2

[Eichberger, German]

Hi Vivek,

Hope things are well. With the Midccyle next week I am wondering if you made 
any progress and/or how we can best help with the panels.

Thanks,
German

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

Thanks German for the etherpad link. If you have any documentation for flows, 
please share those too.

I will work with my team at ebay to publish wireframes for design we are 
working on. It will be mostly along the lines I demo’ed in Paris.

Thanks,
Vivek

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

Hi,

We briefly talked about it a few Neutron meetings back (LBaaS is now on demand) 
and created an etherpad to track things: 
https://etherpad.openstack.org/p/LBaaS_Horizon_Use_Cases

Susanne and I met with HP’s UX designer to work on the design for some flows 
for the Horizon panel (cc’d) but I am glad that Vivek is taking the lead. 
Please check that etherpad for more information and feel free to update as 
things happen…

Thanks,
German


From: Jain, Vivek [mailto:vivekj...@ebay.com]
Sent: Tuesday, April 07, 2015 9:01 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [neutron][lbaas] Horizon support for neutron-lbaas 
v2

Hi Evgeny,
We have just started working on Horizon lbaasv2 support. I have to sync up with 
my team on the time-line but it is not targeted for Kilo release.
Since it is a major effort, we will need more hands. Let me know if anyone is 
interested to contribute.

On a related note, Do we have a sample code which uses neutronclient lbaas v2 
methods? That will greatly speedup our horizon integration.

Thanks,
Vivek

From: Phillip Toohill 
phillip.tooh...@rackspace.commailto:phillip.tooh...@rackspace.com
Reply-To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Date: Tuesday, April 7, 2015 at 7:50 AM
To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [neutron][lbaas] Horizon support for neutron-lbaas 
v2


​Hey Evgeny,



I believe Vivek is working on Horizon lbaasv2 support. We werent given a 
timeline or anything but sounds like its being actively worked on. I would 
reach out to him to get better timelines if concerned.


Phillip V. Toohill III
Software Developer
[http://600a2794aa4ab5bae6bd-8d3014ab8e4d12d3346853d589a26319.r53.cf1.rackcdn.com/signatures/images/rackspace_logo.png]
phone: 210-312-4366
mobile: 210-440-8374


From: Evgeny Fedoruk evge...@radware.commailto:evge...@radware.com
Sent: Tuesday, April 7, 2015 5:50 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [neutron][lbaas] Horizon support for neutron-lbaas v2

Hi guys,

LBaaS v2 has no horizon support as for now and I want to know if this work is 
planned to be done and , if yes, in what time frame.
Is there a plan to develop it for Kilo or for L release?

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

Re: [openstack-dev] [neutron][lbaas] Proposing Al Miller for neutron-lbaas core team

[Eichberger, German]

Al has been a great asset to LBaaS. Well deserved! +1000

German

On 7/2/15, 3:16 PM, Doug Wiegley doug...@parksidesoftware.com wrote:

Hi all,

As the Lieutenant of the advanced services, I would like to nominate Al
Miller to be a member of the neutron-lbaas core reviewer team.

Review stats are in line with other cores[2] and feedback on patches has
been great. Additionally, he has been instrumental in our devstack
support and octavia work.

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

Thanks,
doug

1. 
http://docs.openstack.org/developer/neutron/policies/core-reviewers.html#c
ore-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] [fwaas] - Collecting use cases for API improvements - Closing 7/14

[Eichberger, German]

All,

Thank you for submitting use cases. We now have critical mass in [1] 
(https://etherpad.openstack.org/p/fwaas_use_cases). I am wondering if everybody 
interested to review them by 7/14. Our plan is to ratify them in the FWaaS IRC 
meeting on 7/15 so we can move on to the next step which is mapping them to the 
existing API and identifying gaps…

Thanks,
German

From: Sameer Satyam 
sameer.sat...@outlook.commailto:sameer.sat...@outlook.com
Reply-To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Date: Thursday, May 28, 2015 at 5:30 PM
To: OpenStack Development Mailing List not for usage questions 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [neutron] [fwaas] - Collecting use cases for API 
improvements

German,

Thanks for the initiative. From a Rackspace perspective, we would love to 
participate and provide inputs on the use cases. As discussed during the 
meeting at the summit (and as you alluded to in your email), it's about user 
experience and clear separation of use cases between FWaaS and SG as well as 
any any necessary reconciliation between the two sets of APIs to make the 
distinctions (or integration points if needed) obvious to the user.

Thanks,
Sameer

 From: german.eichber...@hp.commailto:german.eichber...@hp.com
 To: 
 openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
 Date: Wed, 27 May 2015 22:36:47 +
 Subject: [openstack-dev] [neutron] [fwaas] - Collecting use cases for API 
 improvements

 All,


 During the FWaaS session in Vancouver [1] it became apparent that both the 
 FWaaS API and the Security Groups API are lacking in functionality and the 
 connection between the two is not well defined.


 For instance if a cloud user opens up all ports in the security groups they 
 still can’t connect and might figure out days later that there is a second 
 API (FWaaS) which prevents him from connecting to his service. This will 
 probably make for a frustrating experience.


 Similarly, the operators I spoke to all said that the current FWaaS 
 implementation isn’t going far enough and needs a lot of missing 
 functionality added to fulfill their requirements on a Firewall 
 implementation.


 With that backdrop I am proposing to take a step back and assemble a group of 
 operators and users to collect use cases for the firewall service – both 
 FWaaS and Security Groups based. I believe it is important at this juncture 
 to really focus on the users and less on technical limitations. I also think 
 this reset is necessary to make a service which meets the needs of operators 
 and users better.


 Once we have collected the use cases we can evaluate our current API’s and 
 functionality and start making the necessary improvements to turn FWaaS into 
 a service which covers most of the use cases and requirements.


 Please join me in this effort. We have set up an etherpad [2] to start 
 collecting the use cases and will discuss them in an upcoming meeting.


 Thanks,

 German





 [1] https://etherpad.openstack.org/p/YVR-neutron-sg-fwaas-future-direction

 [2] https://etherpad.openstack.org/p/fwaas_use_cases


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

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

Re: [openstack-dev] [lbaas] [octavia] No meeting this week, 6/24

[Eichberger, German]

All,

With this week the Neutron mid cycle happening we will skip the meeting 
tomorrow. We will be back next week, 7/1/15 —

Thanks,
German

__
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] [nova][trove][neutron][octavia] Protected openstack resources

[Eichberger, German]

Amrith,

Thanks for spearheading that work. In the Octavia project we are
interested in the shadow tenant to solve some of the scalability issues we
have encountered with one service tenant:

* There is probably a limit how many Vms a tenant can have
* We have been running out of ipsec rules in our tenant
* There is a limit how many ports a tenant can have (somebody mentioned
200 to me)

A lot of that we still have to validate but I think for various reason
sharding over multiple tenants and networks is interesting to us.

Thanks,
German 

On 6/4/15, 6:45 AM, Doug Hellmann d...@doughellmann.com wrote:

Excerpts from Amrith Kumar's message of 2015-06-04 12:46:37 +:
 John,
 
 Thanks for your note. I've updated the review at
https://review.openstack.org/#/c/186357/ with answers to some of your
questions (and I added you to that review).
 
 Trove's use-case like some of the other projects listed is different
from Glance in that Trove has a guest agent. I've tried to explain that
in more detail in patch set 5. I'd appreciate your comments.

We solved this in Akanda by placing the service VMs in a special
tenant, isolating them with security group rules, and then giving
the agent running in the VM a REST API connected to a private
management network owned by the same tenant that owns the VM. All
communication with the agent starts from a service on the outside,
through that management network. The VMs act as routers, so they
are also attached to the cloud-user's networks, but the agent doesn't
respond on those networks.

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] [fwaas] - Collecting use cases for API improvements

[Eichberger, German]

All,


During the FWaaS session in Vancouver [1] it became apparent that both the 
FWaaS API and the Security Groups API are lacking in functionality and the 
connection between the two is not well defined.


For instance if a cloud user opens up all ports in the security groups they 
still can’t connect and might figure out days later that there is a second API 
(FWaaS) which prevents him from connecting to his service. This will probably 
make for a frustrating experience.


Similarly, the operators I spoke to all said that the current FWaaS 
implementation isn’t going far enough and needs a lot of missing functionality 
added to fulfill their requirements on a Firewall implementation.


With that backdrop I am proposing to take a step back and assemble a group of 
operators and users to collect use cases for the firewall service – both FWaaS 
and Security Groups based. I believe it is important at this juncture to really 
focus on the users and less on technical limitations. I also think this reset 
is necessary to make a service which meets the needs of operators and users 
better.


Once we have collected the use cases we can evaluate our current API’s and 
functionality and start making the necessary improvements to turn FWaaS into a 
service which covers most of the use cases and requirements.


Please join me in this effort. We have set up an etherpad [2] to start 
collecting the use cases and will discuss them in an upcoming meeting.


Thanks,

German





[1] https://etherpad.openstack.org/p/YVR-neutron-sg-fwaas-future-direction

[2] https://etherpad.openstack.org/p/fwaas_use_cases


__
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][octavia] No Octavia meeting 5/20/15

[Eichberger, German]

All,

We won¹t have an Octavia meeting next week due to the OpenStack summit but
we will have a few sessions there ‹ so please make sure to say hiŠ

German


__
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][octavia] No Octavia meeting today

[Eichberger, German]

All,

In order to work on the demo for Vancouver we will be skipping todays, 5/6/15 
meeting. We will have another meeting on 5/13 to finalize for the summit --

If you have questions you can find us in the channel — and again please keep up 
the good work with reviews!

Thanks,
German


__
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] [octavia] Joining Neutron under the big tent

[Eichberger, German]

Hi,

I am proposing that Octavia is joining the Networking program as a project
under the Services area.

Octavia is the open scalable reference implementation for Neutron LBaaS V2
and has always seen itself as part of the networking program. We have
adopted most governance rules from the Networking program, sharing the
same build structure, and are organized like an OpenDStack project.

Thanks,
German 



__
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][Keystone] [Nova] How to validate teanant-id for admin operation

[Eichberger, German]

All,

Following up from the last Neutron meeting:

If Neutron is performing an operation as an admin on behalf of a user that 
user's tenant-id (or project-id) isn't validated - in particular an admin can 
mistype and create object on behalf of non existent users. I am wondering how 
other projects (e.g. Nova) deal with that and if there is some API support in 
keystone to save us a round trip (e.g. authenticate admin + validate additional 
user-id).

Thanks,
German

__
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][Octavia] Logo for Octavia project

[Eichberger, German]

All,

Let's decide on a logo tomorrow so we can print stickers in time for Vancouver. 
Here are some designs to consider: http://bit.ly/Octavia_logo_vote

We will discuss more at tomorrow's meeting - Agenda: 
https://wiki.openstack.org/wiki/Octavia/Weekly_Meeting_Agenda#Meeting_2015-04-15
 - but please come prepared with one of your favorite designs...

Thanks,
German

__
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

[Eichberger, German]

Hi,

We briefly talked about it a few Neutron meetings back (LBaaS is now on demand) 
and created an etherpad to track things: 
https://etherpad.openstack.org/p/LBaaS_Horizon_Use_Cases

Susanne and I met with HP’s UX designer to work on the design for some flows 
for the Horizon panel (cc’d) but I am glad that Vivek is taking the lead. 
Please check that etherpad for more information and feel free to update as 
things happen…

Thanks,
German


From: Jain, Vivek [mailto:vivekj...@ebay.com]
Sent: Tuesday, April 07, 2015 9:01 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [neutron][lbaas] Horizon support for neutron-lbaas 
v2

Hi Evgeny,
We have just started working on Horizon lbaasv2 support. I have to sync up with 
my team on the time-line but it is not targeted for Kilo release.
Since it is a major effort, we will need more hands. Let me know if anyone is 
interested to contribute.

On a related note, Do we have a sample code which uses neutronclient lbaas v2 
methods? That will greatly speedup our horizon integration.

Thanks,
Vivek

From: Phillip Toohill 
phillip.tooh...@rackspace.commailto:phillip.tooh...@rackspace.com
Reply-To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Date: Tuesday, April 7, 2015 at 7:50 AM
To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [neutron][lbaas] Horizon support for neutron-lbaas 
v2


​Hey Evgeny,



I believe Vivek is working on Horizon lbaasv2 support. We werent given a 
timeline or anything but sounds like its being actively worked on. I would 
reach out to him to get better timelines if concerned.


Phillip V. Toohill III
Software Developer
[http://600a2794aa4ab5bae6bd-8d3014ab8e4d12d3346853d589a26319.r53.cf1.rackcdn.com/signatures/images/rackspace_logo.png]
phone: 210-312-4366
mobile: 210-440-8374


From: Evgeny Fedoruk evge...@radware.commailto:evge...@radware.com
Sent: Tuesday, April 7, 2015 5:50 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [neutron][lbaas] Horizon support for neutron-lbaas v2

Hi guys,

LBaaS v2 has no horizon support as for now and I want to know if this work is 
planned to be done and , if yes, in what time frame.
Is there a plan to develop it for Kilo or for L release?

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

Re: [openstack-dev] [Neutron][LBaaS][Octavia] Usage Requirements

[Eichberger, German]

. If a customer turns
on the connection logging feature for their load balancer it will already
have a history. One important aspect of this is that customers (at least
ours) tend to turn on logging after they realize they need it (usually
after a tragic lb event). By already capturing the logs I'm sure customers
will be extremely happy to see that there are already X days worth of logs
they can immediately sift through.
B) Operators and their support teams can leverage logs when providing
service to their customers. This is huge for finding issues and resolving
them quickly.
C) Albeit a minor point, building support for logs from the get-go
mitigates capacity management uncertainty. My example earlier was the
extreme case of every customer turning on logging at the same time. While
unlikely, I would hate to manage that!

I agree that there are other ways to capture billing metrics but, from my
experience, those tend to be more complex than what I am advocating and
without the added benefits listed above. An understanding of HP's desires
on this matter will hopefully get this to a point where we can start
working on a spec.

Cheers,
--Jorge

P.S. Real-time stats is a different beast and I envision there being an
API call that returns real-time data such as this ==
http://cbonte.github.io/haproxy-dconv/configuration-1.5.html#9.


From:  Eichberger, German 
german.eichber...@hp.commailto:german.eichber...@hp.com
Reply-To:  OpenStack Development Mailing List (not for usage questions)
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Date:  Wednesday, October 22, 2014 2:41 PM
To:  OpenStack Development Mailing List (not for usage questions)
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Subject:  Re: [openstack-dev] [Neutron][LBaaS][Octavia] Usage Requirements


Hi Jorge,

Good discussion so far + glad to have you back
J

I am not a big fan of using logs for billing information since ultimately
(at least at HP) we need to pump it into ceilometer. So I am envisioning
either the
 amphora (via a proxy) to pump it straight into that system or we collect
it on the controller and pump it from there.

Allowing/enabling logging creates some requirements on the hardware,
mainly, that they can handle the IO coming from logging. Some operators
might choose to
 hook up very cheap and non performing disks which might not be able to
deal with the log traffic. So I would suggest that there is some rate
limiting on the log output to help with that.


Thanks,
German

From: Jorge Miramontes 
[mailto:jorge.miramon...@rackspace.commailto:jorge.miramon...@rackspace.com]

Sent: Wednesday, October 22, 2014 6:51 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron][LBaaS][Octavia] Usage Requirements



Hey Stephen (and Robert),



For real-time usage I was thinking something similar to what you are
proposing. Using logs for this would be overkill IMO so your suggestions
were what I was
 thinking of starting with.



As far as storing logs is concerned I was definitely thinking of
offloading these onto separate storage devices. Robert, I totally hear
you on the scalability
 part as our current LBaaS setup generates TB of request logs. I'll start
planning out a spec and then I'll let everyone chime in there. I just
wanted to get a general feel for the ideas I had mentioned. I'll also
bring it up in today's meeting.



Cheers,

--Jorge






From:
Stephen Balukoff sbaluk...@bluebox.netmailto:sbaluk...@bluebox.net
Reply-To: OpenStack Development Mailing List (not for usage questions)
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Date: Wednesday, October 22, 2014 4:04 AM
To: OpenStack Development Mailing List (not for usage questions)
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [Neutron][LBaaS][Octavia] Usage Requirements



Hi Jorge!



Welcome back, eh! You've been missed.



Anyway, I just wanted to say that your proposal sounds great to me, and
it's good to finally be closer to having concrete requirements for
logging, eh. Once this
 discussion is nearing a conclusion, could you write up the specifics of
logging into a specification proposal document?



Regarding the discussion itself: I think we can ignore UDP for now, as
there doesn't seem to be high demand for it, and it certainly won't be
supported in v 0.5
 of Octavia (and maybe not in v1 or v2 either, unless we see real
demand).



Regarding the 'real-time usage' information: I have some ideas regarding
getting this from a combination of iptables and / or the haproxy stats
interface. Were
 you thinking something different that involves on-the-fly analysis of
the logs or something?  (I tend to find that logs are great for non-real
time data, but can often be lacking if you need, say, a gauge like
'currently open connections' or something.)



One other thing: If there's a chance

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

[Eichberger, German]

Hi,

I like 16.00 UTC.

German

On Nov 3, 2014 11:42 PM, Doug Wiegley 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

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

Re: [openstack-dev] [Neutron][LBaaS][Octavia] Usage Requirements

[Eichberger, German]

Hi Jorge,

I agree completely with the points you make about the logs. We still feel that 
metering and logging are two different problems. The ceilometers community has 
a proposal on how to meter lbaas (see 
http://specs.openstack.org/openstack/ceilometer-specs/specs/juno/lbaas_metering.html)
 and we at HP think that those values are be sufficient for us for the time 
being. 

I think our discussion is mostly about connection logs which are emitted some 
way from amphora (e.g. haproxy logs). Since they are customer's logs we need to 
explore on our end the privacy implications (I assume at RAX you have controls 
in place to make sure that there is no violation :-). Also I need to check if 
our central logging system is scalable enough and we can send logs there 
without creating security holes.

Another possibility is to log like syslog our apmphora agent logs to a central 
system to help with trouble shooting debugging. Those could be sufficiently 
anonymized to avoid privacy issue. What are your thoughts on logging those?

Thanks,
German

-Original Message-
From: Jorge Miramontes [mailto:jorge.miramon...@rackspace.com] 
Sent: Thursday, October 23, 2014 3:30 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron][LBaaS][Octavia] Usage Requirements

Hey German/Susanne,

To continue our conversation from our IRC meeting could you all provide more 
insight into you usage requirements? Also, I'd like to clarify a few points 
related to using logging.

I am advocating that logs be used for multiple purposes, including billing. 
Billing requirements are different that connection logging requirements. 
However, connection logging is a very accurate mechanism to capture billable 
metrics and thus, is related. My vision for this is something like the 
following:

- Capture logs in a scalable way (i.e. capture logs and put them on a separate 
scalable store somewhere so that it doesn't affect the amphora).
- Every X amount of time (every hour, for example) process the logs and send 
them on their merry way to cielometer or whatever service an operator will be 
using for billing purposes.
- Keep logs for some configurable amount of time. This could be anything from 
indefinitely to not at all. Rackspace is planing on keeping them for a certain 
period of time for the following reasons:

A) We have connection logging as a planned feature. If a customer turns 
on the connection logging feature for their load balancer it will already have 
a history. One important aspect of this is that customers (at least
ours) tend to turn on logging after they realize they need it (usually after a 
tragic lb event). By already capturing the logs I'm sure customers will be 
extremely happy to see that there are already X days worth of logs they can 
immediately sift through.
B) Operators and their support teams can leverage logs when providing 
service to their customers. This is huge for finding issues and resolving them 
quickly.
C) Albeit a minor point, building support for logs from the get-go 
mitigates capacity management uncertainty. My example earlier was the extreme 
case of every customer turning on logging at the same time. While unlikely, I 
would hate to manage that!

I agree that there are other ways to capture billing metrics but, from my 
experience, those tend to be more complex than what I am advocating and without 
the added benefits listed above. An understanding of HP's desires on this 
matter will hopefully get this to a point where we can start working on a spec.

Cheers,
--Jorge

P.S. Real-time stats is a different beast and I envision there being an API 
call that returns real-time data such as this == 
http://cbonte.github.io/haproxy-dconv/configuration-1.5.html#9.


From:  Eichberger, German german.eichber...@hp.com
Reply-To:  OpenStack Development Mailing List (not for usage questions)
openstack-dev@lists.openstack.org
Date:  Wednesday, October 22, 2014 2:41 PM
To:  OpenStack Development Mailing List (not for usage questions)
openstack-dev@lists.openstack.org
Subject:  Re: [openstack-dev] [Neutron][LBaaS][Octavia] Usage Requirements


Hi Jorge,
 
Good discussion so far + glad to have you back J
 
I am not a big fan of using logs for billing information since 
ultimately (at least at HP) we need to pump it into ceilometer. So I am 
envisioning either the  amphora (via a proxy) to pump it straight into 
that system or we collect it on the controller and pump it from there.
 
Allowing/enabling logging creates some requirements on the hardware, 
mainly, that they can handle the IO coming from logging. Some operators 
might choose to  hook up very cheap and non performing disks which 
might not be able to deal with the log traffic. So I would suggest that 
there is some rate limiting on the log output to help with that.

 
Thanks,
German
 
From: Jorge Miramontes [mailto:jorge.miramon...@rackspace.com]

Sent: Wednesday

Re: [openstack-dev] [Neutron][LBaaS][Octavia] Usage Requirements

[Eichberger, German]

Hi Jorge,

Good discussion so far + glad to have you back :)

I am not a big fan of using logs for billing information since ultimately (at 
least at HP) we need to pump it into ceilometer. So I am envisioning either the 
amphora (via a proxy) to pump it straight into that system or we collect it on 
the controller and pump it from there.

Allowing/enabling logging creates some requirements on the hardware, mainly, 
that they can handle the IO coming from logging. Some operators might choose to 
hook up very cheap and non performing disks which might not be able to deal 
with the log traffic. So I would suggest that there is some rate limiting on 
the log output to help with that.

Thanks,
German

From: Jorge Miramontes [mailto:jorge.miramon...@rackspace.com]
Sent: Wednesday, October 22, 2014 6:51 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron][LBaaS][Octavia] Usage Requirements

Hey Stephen (and Robert),

For real-time usage I was thinking something similar to what you are proposing. 
Using logs for this would be overkill IMO so your suggestions were what I was 
thinking of starting with.

As far as storing logs is concerned I was definitely thinking of offloading 
these onto separate storage devices. Robert, I totally hear you on the 
scalability part as our current LBaaS setup generates TB of request logs. I'll 
start planning out a spec and then I'll let everyone chime in there. I just 
wanted to get a general feel for the ideas I had mentioned. I'll also bring it 
up in today's meeting.

Cheers,
--Jorge

From: Stephen Balukoff sbaluk...@bluebox.netmailto:sbaluk...@bluebox.net
Reply-To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Date: Wednesday, October 22, 2014 4:04 AM
To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [Neutron][LBaaS][Octavia] Usage Requirements

Hi Jorge!

Welcome back, eh! You've been missed.

Anyway, I just wanted to say that your proposal sounds great to me, and it's 
good to finally be closer to having concrete requirements for logging, eh. Once 
this discussion is nearing a conclusion, could you write up the specifics of 
logging into a specification proposal document?

Regarding the discussion itself: I think we can ignore UDP for now, as there 
doesn't seem to be high demand for it, and it certainly won't be supported in v 
0.5 of Octavia (and maybe not in v1 or v2 either, unless we see real demand).

Regarding the 'real-time usage' information: I have some ideas regarding 
getting this from a combination of iptables and / or the haproxy stats 
interface. Were you thinking something different that involves on-the-fly 
analysis of the logs or something?  (I tend to find that logs are great for 
non-real time data, but can often be lacking if you need, say, a gauge like 
'currently open connections' or something.)

One other thing: If there's a chance we'll be storing logs on the amphorae 
themselves, then we need to have log rotation as part of the configuration 
here. It would be silly to have an amphora failure just because its ephemeral 
disk fills up, eh.

Stephen

On Wed, Oct 15, 2014 at 4:03 PM, Jorge Miramontes 
jorge.miramon...@rackspace.commailto:jorge.miramon...@rackspace.com wrote:
Hey Octavia folks!


First off, yes, I'm still alive and kicking. :)

I,d like to start a conversation on usage requirements and have a few
suggestions. I advocate that, since we will be using TCP and HTTP/HTTPS
based protocols, we inherently enable connection logging for load
balancers for several reasons:

1) We can use these logs as the raw and granular data needed to track
usage. With logs, the operator has flexibility as to what usage metrics
they want to bill against. For example, bandwidth is easy to track and can
even be split into header and body data so that the provider can choose if
they want to bill on header data or not. Also, the provider can determine
if they will bill their customers for failed requests that were the fault
of the provider themselves. These are just a few examples; the point is
the flexible nature of logs.

2) Creating billable usage from logs is easy compared to other options
like polling. For example, in our current LBaaS iteration at Rackspace we
bill partly on average concurrent connections. This is based on polling
and is not as accurate as it possibly can be. It's very close, but it
doesn't get more accurate that the logs themselves. Furthermore, polling
is more complex and uses up resources on the polling cadence.

3) Enabling logs for all load balancers can be used for debugging, support
and audit purposes. While the customer may or may not want their logs
uploaded to swift, operators and their support teams can still use this
data to help customers out with billing and setup 

Re: [openstack-dev] [Neutron][LBaaS] Interaction with Barbican and Keystone

[Eichberger, German]

Hi Adam,

For me the thing needs to be user friendly. So my main question is how do 
things look in Horizon? Will there just be a popup saying Establish Trust 
(Y/N). I am wondering as you how other teams are handling that...

Thanks,
German

-Original Message-
From: Adam Harwell [mailto:adam.harw...@rackspace.com] 
Sent: Thursday, September 18, 2014 3:16 PM
To: OpenStack Development Mailing List (not for usage questions)
Cc: sbaluk...@bluebox.net; Doug Wiegley; Eichberger, German; Adam Young; Balle, 
Susanne; Douglas Mendizabal
Subject: [openstack-dev] [Neutron][LBaaS] Interaction with Barbican and Keystone

I've made an attempt at mapping out exactly how Neutron Advanced Services will 
communicate with Barbican to retrieve Certificate/Key info for TLS purposes. 
This is far from solidified, since there are some issues that I'll go over 
momentarily. First, here is a *high level* diagram of the process flow:

http://i.imgur.com/VQcbGJS.png (I use the term hijack purposefully)


And here is a more detailed flow, including each and every operation:

http://goo.gl/Wc8oIj

There are some valid concerns about this workflow, and at least one issue that 
may be a blocker.

Following are the two main issues that I've run into:

1) Possible blocker: Keystone won't allow Trust creation using a Trust Token. 
Example: A user creates a Trust for Heat, and gives Heat their TrustID. The 
user configures Heat to spin up Load Balancers. Heat contacts LBaaS on behalf 
of the user with a Trust Token. LBaaS contacts Keystone to create a Trust using 
the token received from Heat. LBaaS would be unable to create a Trust because 
the Token we're trying to use doesn't have the ability to create Trusts, and 
our operation would fail.

2) Security concern: If the Neutron/LBaaS config contains a Service Account's 
user/pass and Database URI/user/pass, then anyone with access to the config 
file would be able to connect to the DB, pull out TrustIDs, and use the Neutron 
Service Account to execute them. Essentially, the only difference between 
storing private keys directly in the database and storing them in Barbican is 
that there's one additional (trivial) step to get the key data (contact the 
Barbican API).

The keystone folks I talked to (primarily Adam Young) suggested that the 
solution to issue #1 is to require the user to create the Trust beforehand in 
Keystone, then pass the TrustID to Neutron/LBaaS along with the ContainerID. 
This could originally be based on a template we provide to the user, probably 
in the form of a suggested JSON body and keystone URI.
Eventually, there could/should/might be a system in place to allow services to 
pre-define a Trust with Keystone and the user would just need to tell Keystone 
that they accept that Trust. Either way, this would require action by the user 
before they could create a TLS Terminated LB. I don't particularly LIKE that 
option, but if 90% of our users come through Horizon anyway, it should be as 
simple as having Horizon pop up a Yes/No box prompting to enable the Trust when 
the user creates their first TLS LB.

As for issue #2, I don't really have a solution to propose. There was some talk 
about the Postern project, but there isn't really any usable code yet, or even 
solid specs from what I can tell -- it looks like the project was proposed and 
never went past the PoC stage.
https://github.com/cloudkeep/postern

I know there are some other teams looking into very similar issues, so I have a 
bit of research to do on that front, but in the meantime, what are people's 
thoughts? I've cc'd a few of the people who were already in the IRC version of 
this discussion (I may have missed anyone who wasn't already in my address 
book, sorry), but I'd love to hear from anyone who has ideas on the subject.

--Adam


https://keybase.io/rm_you


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

[openstack-dev] [Octavia] Which threading library?

[Eichberger, German]

Hi,

I think the standard threading library for OpenStack is eventlet - however, 
it seems that Oslo is spearheading efforts to get to a more compatible one (see 
http://techs.enovance.com/6562/asyncio-openstack-python3) I am now wondering 
since we are starting fresh if we should embrace (a potential) future or stick 
with eventlet and all its flaws?

Thoughts?

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

Re: [openstack-dev] [Octavia] Question about where to render haproxy configurations

[Eichberger, German]

Hi Steven,

Thanks for taking the time to lay out the components clearly. I think we are 
pretty much on the same page ☺

Driver vs, Driver-less
I strongly believe that REST is a cleaner interface/integration point – but  if 
even Brandon believes that drivers are the better approach (having suffered 
through the LBaaS v1 driver world which is not an advertisement for this 
approach) I will concede on that front. Let’s hope nobody makes an asynchronous 
driver and/or writes straight to the DB ☺ That said I still believe that adding 
the driver interface now will lead to some more complexity and I am not sure we 
will get the interface right in the first version: so let’s agree to develop 
with a driver in mind but don’t allow third party drivers before the interface 
has matured. I think that is something we already sort of agreed to, but I just 
want to make that explicit.

Multiple drivers/version for the same Controller
This is a really contentious point for us at HP: If we allow say drivers or 
even different versions of the same driver, e.g. A, B, C to run in parallel, 
testing will involve to test all the possible (version) combination to avoid 
potential side effects. That can get extensive really quick. So HP is 
proposing, given that we will have 100s of controllers any way, to limit the 
number of drivers per controller to 1 to aide testing. We can revisit that at a 
future time when our testing capabilities have improved but for now I believe 
we should choose that to speed things up. I personally don’t see the need for 
multiple drivers per controller – in an operator grade environment we likely 
don’t need to “save” on the number of controllers ;-) The only reason we might 
need two drivers on the same controller is if an Amphora for whatever reason 
needs to be talked to by two drivers. (e.g. you install nginx and haproxy  and 
have a driver for each). This use case scares me so we should not allow it.
We also see some operational simplifications from supporting only one driver 
per controller: If we have an update for driver A we don’t need to touch any 
controller running Driver B. Furthermore we can keep the old version running 
but make sure no new Amphora gets scheduled there to let it wind down with 
attrition and then stop that controller when it doesn’t have any more Amphora 
to serve.

Lastly, I interpreted the word “VM driver” in the spec along the lines what we 
have in libra: A driver interface on the Amphora agent that abstracts 
starting/stopping the haproxy if we end up on some different and abstracts 
writing the haproxy file. But that is for the agent on the Amphora. I am sorry 
I got confused  that way when reading the 0.5 spec and I am therefore happy we 
can have that discussion to make things more clear.

German

From: Stephen Balukoff [mailto:sbaluk...@bluebox.net]
Sent: Friday, September 05, 2014 6:26 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Octavia] Question about where to render haproxy 
configurations

Hi German,

Responses in-line:

On Fri, Sep 5, 2014 at 2:31 PM, Eichberger, German 
german.eichber...@hp.commailto:german.eichber...@hp.com wrote:
Hi Stephen,

I think this is a good discussion to have and will make it more clear why we 
chose a specific design. I also believe by having this discussion we will make 
the design stronger.  I am still a little bit confused what the 
driver/controller/amphora agent roles are. In my driver-less design we don’t 
have to worry about the driver which most likely in haproxy’s case will be 
split to some degree between controller and amphora device.

Yep, I agree that a good technical debate like this can help both to get many 
people's points of view and can help determine the technical merit of one 
design over another. I appreciate your vigorous participation in this process. 
:)

So, the purpose of the controller / driver / amphora and the responsibilities 
they have are somewhat laid out in the Octavia v0.5 component design document, 
but it's also possible that there weren't enough specifics in that document to 
answer the concerns brought up in this thread. So, to that end in my mind, I 
see things like the following:

The controller:
* Is responsible for concerns of the Octavia system as a whole, including the 
intelligence around interfacing with the networking, virtualization, and other 
layers necessary to set up the amphorae on the network and getting them 
configured.
* Will rarely, if ever, talk directly to the end-systems or -services (like 
Neutron, Nova, etc.). Instead it goes through a clean driver interface for 
each of these.
* The controller has direct access to the database where state is stored.
* Must load at least one driver, may load several drivers and choose between 
them based on configuration logic (ex. flavors, config file, etc.)

The driver:
* Handles all communication to or from the amphorae
* Is loaded by the controller (ie. its interface

Re: [openstack-dev] [Octavia] Question about where to render haproxy configurations

[Eichberger, German]

Hi Stephen,

I think this is a good discussion to have and will make it more clear why we 
chose a specific design. I also believe by having this discussion we will make 
the design stronger.  I am still a little bit confused what the 
driver/controller/amphora agent roles are. In my driver-less design we don’t 
have to worry about the driver which most likely in haproxy’s case will be 
split to some degree between controller and amphora device.

So let’s try to sum up what we want a controller to do:

-  Provision new amphora devices

-  Monitor/Manage health

-  Gather stats

-  Manage/Perform configuration changes

The driver as described would be:

-  Render configuration changes in a specific format, e.g. haproxy

Amphora Device:

-  Communicate with the driver/controller to make things happen

So as Doug pointed out I can make a very thin driver which basically passes 
everything through to the Amphora Device or on the other hand of the spectrum I 
can make a very thick driver which manages all aspects from the amphora life 
cycle to whatever (aka kitchen sink). I know we are going for uttermost 
flexibility but I believe:

-  With building an haproxy centric controller we don’t really know 
which things should be controller/which thing should be driver. So my shortcut 
is not to build a driver at all ☺

-  The more flexibility increases complexity and makes it confusing for 
people to develop components. Should this concern go into the controller, the 
driver, or the amphora VM? Two of them? Three of them? Limiting choices makes 
it simpler to achieve that.

HPs worry is that by creating the potential to run multiple (version of 
drivers) drivers, on multiple versions of controllers, on multiple versions of 
amphora devices creates a headache for testing. For example does the version 
4.1 haproxy driver work with the cersion 4.2 controller on an 4.0 amphora 
device? Which compatibility matrix do we need to build/test? Limiting one 
driver to one controller can help with making that manageable.

Thanks,
German

From: Stephen Balukoff [mailto:sbaluk...@bluebox.net]
Sent: Friday, September 05, 2014 10:44 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Octavia] Question about where to render haproxy 
configurations

Hi German,

Thanks for your reply! My responses are in-line below, and of course you should 
feel free to counter my counter-points. :)

For anyone else paying attention and interested in expressing a voice here, 
we'll probably be voting on this subject at next week's Octavia meeting.

On Thu, Sep 4, 2014 at 9:13 PM, Eichberger, German 
german.eichber...@hp.commailto:german.eichber...@hp.com wrote:
Hi,

Stephen visited us today (the joy of spending some days in Seattle☺) and we 
discussed that  further (and sorry for using VM – not sure what won):

Looks like Amphora won, so I'll start using that terminology below.


1.   We will only support one driver per controller, e.g. if you upgrade a 
driver you deploy a new controller with the new driver and either make him take 
over existing VMs (minor change) or spin  up new ones (major change) but keep 
the “old” controller in place until it doesn’t serve any VMs any longer
Why? I agree with the idea of one back-end type per driver, but why shouldn't 
we support more than one driver per controller?

I agree that you probably only want to support one version of each driver per 
controller, but it seems to me it shouldn't be that difficult to write a driver 
that knows how to speak different versions of back-end amphorae. Off the top of 
my head I can think of two ways of doing this:

1. For each new feature or bugfix added, keep track of the minimal version of 
the amphora required to use that feature/bugfix. Then, when building your 
configuration, as various features are activated in the configuration, keep a 
running track of the minimal amphora version required to meet that 
configuration. If the configuration version is higher than the version of the 
amphora you're going to update, you can pre-emptively return an error detailing 
an unsupported configuration due to the back-end amphora being too old. (What 
you do with this error-- fail, recycle the amphora, whatever-- is up to the 
operator's policy at this point, though I would probably recommend just 
recycling the amphora.) If a given user's configuration never makes use of 
advanced features later on, there's no rush to upgrade their amphoras, and new 
controllers can push configs that work with the old amphoras indefinitely.

2. If the above sounds too complicated, you can forego that and simply build 
the config, try to push it to the amphora, and see if you get an error 
returned.  If you do, depending on the nature of the error you may decide to 
recycle the amphora or take other actions. As there should never be a case 
where you deploy a controller that generates

Re: [openstack-dev] [neutron][lbaas][octavia]

[Eichberger, German]

+1

On Sep 2, 2014 12:59 PM, Kyle Mestery mest...@mestery.com wrote:
On Tue, Sep 2, 2014 at 1:28 PM, Salvatore Orlando sorla...@nicira.com wrote:
 Inline.
 Salvatore

 On 2 September 2014 19:46, Stephen Balukoff sbaluk...@bluebox.net wrote:

 For what it's worth in this discussion, I agree that the possible futures
 of Octavia already discussed (where it lives, how it relates to Neutron
 LBaaS, etc.) are all possible. What actually happens here is going to depend
 both on the Octavia team, the Neutron team (especially when it comes to how
 the neutron-incubator is practically managed), and anyone else interested in
 contributing to these projects.

 Again, for now, I think it's most important to get involved, write code,
 and start delivering on the immediate, obvious things that need to be done
 for Octavia.


 Probably... at least we'll be speculating about something which actually
 exists.

To me what makes sense here is that we merge the Octavia code into the
neutron-incubator when the LBaaS V2 code is merged there. If the end
goal is to spin the LBaaS V2 stuff out into a separate git repository
and project (under the networking umbrella), this would allow for the
Octavia driver to be developed alongside the V2 API code, and in fact
help satisfy one of the requirements around Neutron incubation
graduation: Having a functional driver. And it also allows for the
driver to continue to live on next to the API.

What do people think about this?

Thanks,
Kyle



 In my mind, there are too many unknowns to predict exactly where things
 will end up in the long run. About the only thing I am certain of is that
 everyone involving themselves in the Octavia project wants to see it become
 a part of OpenStack (in whatever way that happens), and that that will
 certainly not happen if we aren't able to build the operator-scale load
 balancer we all want.


 Beyond that, I don't see a whole lot of point to the speculation here. :/
 (Maybe someone can enlighten me to this point?)


 I have speculated only to the extent that it was needed for me to understand
 what's the interface between the two things.
 Beyond that, I agree and have already pointed out that there is no urgency
 for prolonging this discussion, unless the lbaas and octavia team feel this
 will have a bearing on short term developments. I don't think so but I do
 not have the full picture.

 Talking about pointless things you might want to ensure the name 'octavia'
 is not trademarked before writing lots of code! Renames are painful and some
 openstack projects (like neutron and zaqar) know something about that.



 Stephen



 On Tue, Sep 2, 2014 at 9:40 AM, Brandon Logan
 brandon.lo...@rackspace.com wrote:

 Hi Susanne,

 I believe the options for Octavia are:
 1) Merge into the LBaaS tree (wherever LBaaS is)
 2) Become its own openstack project
 3) Remains in stackforge for eternity

 #1 Is dependent on these options
 1) LBaaS V2 graduates from the incubator into Neutron. V1 is deprecated.
 2) LBaaS V2 remains in incubator until it can be spun out.  V1 in
 Neutron is deprecated.
 3) LBaaS V2 is abandoned in the incubator and LBaaS V1 remains.  (An
 unlikely option)

 I don't see any other feasible options.

 On Tue, 2014-09-02 at 12:06 -0400, Susanne Balle wrote:
  Doug
 
 
  I agree with you but I need to understand the options. Susanne
 
 
   And I agree with Brandon’s sentiments.  We need to get something
  built before I’m going to worry too
   much about where it should live.  Is this a candidate to get sucked
  into LBaaS?  Sure.  Could the reverse
   happen?  Sure.  Let’s see how it develops.
 
 
 
  On Tue, Sep 2, 2014 at 11:45 AM, Doug Wiegley do...@a10networks.com
  wrote:
  Hi all,
 
 
   On the other hand one could also say that Octavia is the ML2
  equivalent of LBaaS. The equivalence here is very loose.
  Octavia would be a service-VM framework for doing load
  balancing using a variety of drivers. The drivers ultimately
  are in charge of using backends like haproxy or nginx running
  on the service VM to implement lbaas configuration.
 
 
  This, exactly.  I think it’s much fairer to define Octavia as
  an LBaaS purpose-built service vm framework, which will use
  nova and haproxy initially to provide a highly scalable
  backend. But before we get into terminology misunderstandings,
  there are a bunch of different “drivers” at play here, exactly
  because this is a framework:
* Neutron lbaas drivers – what we all know and love
* Octavia’s “network driver” - this is a piece of glue
  that exists to hide internal calls we have to make
  into Neutron until clean interfaces exist.  It might
  be a no-op in the case of an actual neutron lbaas
  driver, which could serve that function instead.
* Octavia’s “vm driver” - this 

Re: [openstack-dev] [neutron][lbaas][octavia]

[Eichberger, German]

Kyle,

I am confused. So basically you (and Mark) are saying:

1) We deprecate Neutron LBaaS v1
2) We spin out Neutron LBaaS v2 into it's own project in stackforge
3) Users don't have an OpenStack LBaaS any longer until we graduate from 
OpenStack incubation (as opposed Neutron incubation)

I am hoping you can clarify how this will be shaping up - 

Thanks,
German


-Original Message-
From: Kyle Mestery [mailto:mest...@mestery.com] 
Sent: Thursday, August 28, 2014 6:48 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [neutron][lbaas][octavia]

On Thu, Aug 28, 2014 at 5:55 PM, Kevin Benton blak...@gmail.com wrote:
 I think we need some clarification here too about the difference 
 between the general OpenStack Incubation and the Neutron incubation. 
 From my understanding, the Neutron incubation isn't the path to a 
 separate project and independence from Neutron. It's a process to get 
 into Neutron. So if you want to keep it as a separate project with its 
 own cores and a PTL, Neutron incubation would not be the way to go.

That's not true, there are 3 ways out of incubation: 1) The project withers and 
dies on it's own. 2) The project is spun back into Neutron. 3) The project is 
spun out into it's own project.

However, it's worth noting that if the project is spun out into it's own 
entity, it would have to go through incubation to become a fully functioning 
OpenStack project of it's own.



 On Thu, Aug 28, 2014 at 3:04 PM, Susanne Balle sleipnir...@gmail.com
 wrote:

 Just for us to learn about the incubator status, here are some of the 
 info on incubation:

 https://wiki.openstack.org/wiki/Governance/Approved/Incubation
 https://wiki.openstack.org/wiki/Governance/NewProjects

 Susanne


 On Thu, Aug 28, 2014 at 5:57 PM, Susanne Balle 
 sleipnir...@gmail.com
 wrote:

  I would like to discuss the pros and cons of putting Octavia into 
 the Neutron LBaaS incubator project right away. If it is going to be 
 the reference implementation for LBaaS v 2 then I believe Octavia 
 belong in Neutron LBaaS v2 incubator.

 The Pros:
 * Octavia is in Openstack incubation right away along with the lbaas 
 v2 code. We do not have to apply for incubation later on.
 * As incubation project we have our own core and should be able ot 
 commit our code
 * We are starting out as an OpenStack incubated project

 The Cons:
 * Not sure of the velocity of the project
 * Incubation not well defined.

 If Octavia starts as a standalone stackforge project we are assuming 
 that it would be looked favorable on when time is to move it into 
 incubated status.

 Susanne




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




 --
 Kevin Benton

 ___
 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] [Octavia] Minutes from 8/13/2014 meeting

[Eichberger, German]

Hi,

Just to be clear: We all think the incubator is a great idea and if some things 
are ironed out will be a good way to onboard new projects to Neutron. What 
bothers me is the timing. Without warning we were put in an incubator in the 
span of like 8 days. This makes it difficult to plan and adds unnecessary 
uncertainty. Who is guaranteeing that if I tell my management LBaaS v2 will be 
in Kilo that nobody will throw a wrench in five months time? 

What I like to see from the Neutron Core team is timely communication with 
proper transition plans: For example if there is a change in how things are 
done it should be implemented at the beginning of a cycle and projects started 
before the change should have a grace period where things are done the old way. 
I understand that some things might have to be retroactively but that should be 
kept to a minimum - 

I also want to reiterate that we are quite happy and pleased with the Neutron 
core team --

To Doug's argument about displacing LBaaS v1: I am convinced that the reference 
implementation/driver absolutely belongs into the incubator. It is frankly 
unusable. The API itself has its problems but I agree for people with hardware 
load balancers there might be some value. However, the mechanics of Neutron (we 
need an open source reference driver) leave us with basically two bad choices: 
Leave an unusable driver in Neutron or pull everything out. I am not sure what 
the lesser evil is but from an operator perspective I am happy to just toss the 
whole thing into the incubator.

Thanks,
German

-Original Message-
From: Doug Wiegley [mailto:do...@a10networks.com] 
Sent: Monday, August 18, 2014 7:05 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Octavia] Minutes from 8/13/2014 meeting

So now that is two people on this thread that are treating moving lbaas v1 to 
incubator as an of course, duh kind of thing.  I do not agree.

Insofar as most of neutron advanced services is feeling the velocity and 
maturity pain, sure.  But lbaas v2 has NO dependency on v1, it's stable, been 
shipping for several cycles, has users. it would be odd to just up and 
disappear in Juno.  Seems to make more sense to let it continue in maintenance, 
likely deprecated in Kilo, and be removed as part of a normal lifecycle.

v2 is nowhere near as far along, partly because we jumped through some extra 
hoops, but whatever, they are not in identical situations.

Thanks,
Doug



On 8/18/14, 7:49 PM, Stephen Balukoff sbaluk...@bluebox.net wrote:

I agree pretty strongly with Brandon's and Doug's comments as well.


And I did want to clarify that I certainly don't hate the Neutron cores 
either. I feel like we (those working on Neutron LBaaS and the Cores) 
made commitments to each other both at the Atlanta summit and the 
mid-cycle hackathon, including taking on additional  work we otherwise 
wouldn't have done in order to work with the Neutron team in good 
faith. I feel like we upheld our end of the deal, but without getting 
the reviews we need to get into Juno, and with LBaaS becoming the 
poster child (or proof of concept, or  guinea pig, depending on your 
level of cynicism) for projects that should go into Neutron 
Incubator...  well, here we are about to hit
Juno-3 and there's essentially zero chance we're going to get in.


All that is to say, I think the cores we've been working with embarked 
on this in good faith, but unexpected happenings in the Neutron 
community have necessitated the events as they are happening. I think I 
understand
*why* things have happened as they
 have, but I can't help but feel like our team was betrayed here. And 
it's certainly not going to be any easier to convince our bosses that 
our time working on Neutron LBaaS over the last few months was well 
spent when the features and changes we need are no  closer to becoming 
part of the official, accepted code base. (Heck, if Brandon is the 
voice of Optimism in our defacto team, then you can call me the voice 
of Skepticism in it:  It's also conceivable that with the extra 
complication of neutron-incubator graduation  being worked through, it 
is likely that we will not see our changes get into Kilo either!)


I do hope that they take our previously voiced concerns about 
neutron-incubator very seriously (particularly the ones about moving 
Neutron LBaaS v1 into incubator, and taking meaningful, tangible steps 
to solve the core reviewer bandwidth problem that  I think is the 
*real* reason it takes so long to get major changes into
Neutron.) At this time, though, I feel like prudence demands we spend 
time making Octavia happen--  after all, we can only go through so many 
cycles where we effectively have nothing to  show for our work before 
we'll all be out of our jobs. :/


On joining the weekly meetings and otherwise contributing:


We'd love to have you attend Salvatore! If you (or anyone else
interested) are free at 20:00 UTC on 

Re: [openstack-dev] [Octavia] Object Model and DB Structure

[Eichberger, German]

Hi,

My 2 cents for the multiple listeners per load balancer discussion: We have 
customers who like to have a listener on port 80 and one on port 443 on the 
same VIP (we had to patch libra to allow two listeners in one single haproxy) 
- so having that would be great.

I like the proposed status :-)

Thanks,
German

-Original Message-
From: Brandon Logan [mailto:brandon.lo...@rackspace.com] 
Sent: Sunday, August 17, 2014 8:57 PM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [Octavia] Object Model and DB Structure

Oh hello again!

You know the drill!

On Sat, 2014-08-16 at 11:42 -0700, Stephen Balukoff wrote:
 Hi Brandon,
 
 
 Responses in-line:
 
 On Fri, Aug 15, 2014 at 9:43 PM, Brandon Logan 
 brandon.lo...@rackspace.com wrote:
 Comments in-line
 
 On Fri, 2014-08-15 at 17:18 -0700, Stephen Balukoff wrote:
  Hi folks,
 
 
  I'm OK with going with no shareable child entities
 (Listeners, Pools,
  Members, TLS-related objects, L7-related objects, etc.).
 This will
  simplify a lot of things (like status reporting), and we can
 probably
  safely work under the assumption that any user who has a use
 case in
  which a shared entity is useful is probably also technically
 savvy
  enough to not only be able to manage consistency problems
 themselves,
  but is also likely to want to have that level of control.
 
 
  Also, an haproxy instance should map to a single listener.
 This makes
  management of the configuration template simpler and the
 behavior of a
  single haproxy instance more predictable. Also, when it
 comes to
  configuration updates (as will happen, say, when a new
 member gets
  added to a pool), it's less risky and error prone to restart
 the
  haproxy instance for just the affected listener, and not for
 all
  listeners on the Octavia VM. The only down-sides I see are
 that we
  consume slightly more memory, we don't have the advantage of
 a shared
  SSL session cache (probably doesn't matter for 99.99% of
 sites using
  TLS anyway), and certain types of persistence wouldn't carry
 over
  between different listeners if they're implemented poorly by
 the
  user. :/  (In other words, negligible down-sides to this.)
 
 
 This is fine by me for now, but I think this might be
 something we can
 revisit later after we have the advantage of hindsight.  Maybe
 a
 configurable option.
 
 
 Sounds good, as long as we agree on a path forward. In the mean time, 
 is there anything I'm missing which would be a significant advantage 
 of having multiple Listeners configured in a single haproxy instance?
 (Or rather, where a single haproxy instance maps to a loadbalancer
 object?)

No particular reason as of now.  Just feel like that could be something that 
could hinder a particular feature or even performance in the future.  It's not 
rooted in any fact or past experience.

  
 I have no problem with this. However, one thing I often do
 think about
 is that it's not really ever going to be load balancing
 anything with
 just a load balancer and listener.  It has to have a pool and
 members as
 well.  So having ACTIVE on the load balancer and listener, and
 still not
 really load balancing anything is a bit odd.  Which is why I'm
 in favor
 of only doing creates by specifying the entire tree in one
 call
 (loadbalancer-listeners-pool-members).  Feel free to
 disagree with me
 on this because I know this not something everyone likes.  I'm
 sure I am
 forgetting something that makes this a hard thing to do.  But
 if this
 were the case, then I think only having the provisioning
 status on the
 load balancer makes sense again.  The reason I am advocating
 for the
 provisioning status on the load balancer is because it still
 simpler,
 and only one place to look to see if everything were
 successful or if
 there was an issue.
 
 
 Actually, there is one case where it makes sense to have an ACTIVE 
 Listener when that listener has no pools or members:  Probably the 2nd 
 or 3rd most common type of load balancing service we deploy is just 
 an HTTP listener on port 80 that redirects all requests to the HTTPS 
 listener on port 443. While this can be done using a (small) pool of 
 back-end servers responding to the port 80 requests, there's really no 
 point in not having the haproxy instance do this redirect directly for 
 sites that want all access to happen over 

Re: [openstack-dev] [Octavia] Object Model and DB Structure

[Eichberger, German]

Hi Steven,

In my example we don’t share anything except the VIP ☺ So my motivation is if 
we can have two listeners share the same VIP. Hope that makes sense.

German

From: Stephen Balukoff [mailto:sbaluk...@bluebox.net]
Sent: Monday, August 18, 2014 1:39 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Octavia] Object Model and DB Structure

Yes, I'm advocating keeping each listener in a separate haproxy configuration 
(and separate running instance). This includes the example I mentioned: One 
that listens on port 80 for HTTP requests and redirects everything to the HTTPS 
listener on port 443.  (The port 80 listener is a simple configuration with no 
pool or members, and it doesn't take much to have it run on the same host as 
the port 443 listener.)

I've not explored haproxy's new redirect scheme capabilities in 1.5 yet. Though 
I doubt it would have a significant impact on the operational model where each 
listener is a separate haproxy configuration and instance.

German: Are you saying that the port 80 listener and port 443 listener would 
have the exact same back-end configuration? If so, then what we're discussing 
here with no sharing of child entities, would mean that the customer has to set 
up and manage these duplicate pools and members. If that's not acceptable, now 
is the time to register that opinion, eh!

Stephen

On Mon, Aug 18, 2014 at 11:37 AM, Brandon Logan 
brandon.lo...@rackspace.commailto:brandon.lo...@rackspace.com wrote:
Hi German,
I don't think it is a requirement that those two frontend sections (or
listen sections) have to live in the same config.  I thought if they
were listening on the same IP but different ports it could be in two
different haproxy instances.  I could be wrong though.

Thanks,
Brandon

On Mon, 2014-08-18 at 17:21 +, Eichberger, German wrote:
 Hi,

 My 2 cents for the multiple listeners per load balancer discussion: We have 
 customers who like to have a listener on port 80 and one on port 443 on the 
 same VIP (we had to patch libra to allow two listeners in one single 
 haproxy) - so having that would be great.

 I like the proposed status :-)

 Thanks,
 German

 -Original Message-
 From: Brandon Logan 
 [mailto:brandon.lo...@rackspace.commailto:brandon.lo...@rackspace.com]
 Sent: Sunday, August 17, 2014 8:57 PM
 To: 
 openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
 Subject: Re: [openstack-dev] [Octavia] Object Model and DB Structure

 Oh hello again!

 You know the drill!

 On Sat, 2014-08-16 at 11:42 -0700, Stephen Balukoff wrote:
  Hi Brandon,
 
 
  Responses in-line:
 
  On Fri, Aug 15, 2014 at 9:43 PM, Brandon Logan
  brandon.lo...@rackspace.commailto:brandon.lo...@rackspace.com wrote:
  Comments in-line
 
  On Fri, 2014-08-15 at 17:18 -0700, Stephen Balukoff wrote:
   Hi folks,
  
  
   I'm OK with going with no shareable child entities
  (Listeners, Pools,
   Members, TLS-related objects, L7-related objects, etc.).
  This will
   simplify a lot of things (like status reporting), and we can
  probably
   safely work under the assumption that any user who has a use
  case in
   which a shared entity is useful is probably also technically
  savvy
   enough to not only be able to manage consistency problems
  themselves,
   but is also likely to want to have that level of control.
  
  
   Also, an haproxy instance should map to a single listener.
  This makes
   management of the configuration template simpler and the
  behavior of a
   single haproxy instance more predictable. Also, when it
  comes to
   configuration updates (as will happen, say, when a new
  member gets
   added to a pool), it's less risky and error prone to restart
  the
   haproxy instance for just the affected listener, and not for
  all
   listeners on the Octavia VM. The only down-sides I see are
  that we
   consume slightly more memory, we don't have the advantage of
  a shared
   SSL session cache (probably doesn't matter for 99.99% of
  sites using
   TLS anyway), and certain types of persistence wouldn't carry
  over
   between different listeners if they're implemented poorly by
  the
   user. :/  (In other words, negligible down-sides to this.)
 
 
  This is fine by me for now, but I think this might be
  something we can
  revisit later after we have the advantage of hindsight.  Maybe
  a
  configurable option.
 
 
  Sounds good, as long as we agree on a path forward. In the mean time,
  is there anything I'm missing which would be a significant advantage
  of having multiple Listeners configured

Re: [openstack-dev] [Octavia] Object Model and DB Structure

[Eichberger, German]

No, I mean with VIP the original meaning more akin to a Floating IP…

German

From: Stephen Balukoff [mailto:sbaluk...@bluebox.net]
Sent: Monday, August 18, 2014 2:43 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Octavia] Object Model and DB Structure

German--

By 'VIP' do you mean something roughly equivalent to 'loadbalancer' in the 
Neutron LBaaS object model (as we've discussed in the past)?  That is to say, 
is this thingy a parent object to the Listener in the hierarchy? If so, then 
what we're describing definitely accommodates that.

(And yes, we commonly see deployments with listeners on port 80 and port 443 on 
the same virtual IP address.)

Stephen

On Mon, Aug 18, 2014 at 2:16 PM, Eichberger, German 
german.eichber...@hp.commailto:german.eichber...@hp.com wrote:
Hi Steven,

In my example we don’t share anything except the VIP ☺ So my motivation is if 
we can have two listeners share the same VIP. Hope that makes sense.

German

From: Stephen Balukoff 
[mailto:sbaluk...@bluebox.netmailto:sbaluk...@bluebox.net]
Sent: Monday, August 18, 2014 1:39 PM
To: OpenStack Development Mailing List (not for usage questions)

Subject: Re: [openstack-dev] [Octavia] Object Model and DB Structure

Yes, I'm advocating keeping each listener in a separate haproxy configuration 
(and separate running instance). This includes the example I mentioned: One 
that listens on port 80 for HTTP requests and redirects everything to the HTTPS 
listener on port 443.  (The port 80 listener is a simple configuration with no 
pool or members, and it doesn't take much to have it run on the same host as 
the port 443 listener.)

I've not explored haproxy's new redirect scheme capabilities in 1.5 yet. Though 
I doubt it would have a significant impact on the operational model where each 
listener is a separate haproxy configuration and instance.

German: Are you saying that the port 80 listener and port 443 listener would 
have the exact same back-end configuration? If so, then what we're discussing 
here with no sharing of child entities, would mean that the customer has to set 
up and manage these duplicate pools and members. If that's not acceptable, now 
is the time to register that opinion, eh!

Stephen

On Mon, Aug 18, 2014 at 11:37 AM, Brandon Logan 
brandon.lo...@rackspace.commailto:brandon.lo...@rackspace.com wrote:
Hi German,
I don't think it is a requirement that those two frontend sections (or
listen sections) have to live in the same config.  I thought if they
were listening on the same IP but different ports it could be in two
different haproxy instances.  I could be wrong though.

Thanks,
Brandon

On Mon, 2014-08-18 at 17:21 +, Eichberger, German wrote:
 Hi,

 My 2 cents for the multiple listeners per load balancer discussion: We have 
 customers who like to have a listener on port 80 and one on port 443 on the 
 same VIP (we had to patch libra to allow two listeners in one single 
 haproxy) - so having that would be great.

 I like the proposed status :-)

 Thanks,
 German

 -Original Message-
 From: Brandon Logan 
 [mailto:brandon.lo...@rackspace.commailto:brandon.lo...@rackspace.com]
 Sent: Sunday, August 17, 2014 8:57 PM
 To: 
 openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
 Subject: Re: [openstack-dev] [Octavia] Object Model and DB Structure

 Oh hello again!

 You know the drill!

 On Sat, 2014-08-16 at 11:42 -0700, Stephen Balukoff wrote:
  Hi Brandon,
 
 
  Responses in-line:
 
  On Fri, Aug 15, 2014 at 9:43 PM, Brandon Logan
  brandon.lo...@rackspace.commailto:brandon.lo...@rackspace.com wrote:
  Comments in-line
 
  On Fri, 2014-08-15 at 17:18 -0700, Stephen Balukoff wrote:
   Hi folks,
  
  
   I'm OK with going with no shareable child entities
  (Listeners, Pools,
   Members, TLS-related objects, L7-related objects, etc.).
  This will
   simplify a lot of things (like status reporting), and we can
  probably
   safely work under the assumption that any user who has a use
  case in
   which a shared entity is useful is probably also technically
  savvy
   enough to not only be able to manage consistency problems
  themselves,
   but is also likely to want to have that level of control.
  
  
   Also, an haproxy instance should map to a single listener.
  This makes
   management of the configuration template simpler and the
  behavior of a
   single haproxy instance more predictable. Also, when it
  comes to
   configuration updates (as will happen, say, when a new
  member gets
   added to a pool), it's less risky and error prone to restart
  the
   haproxy instance for just the affected listener, and not for
  all
   listeners on the Octavia VM. The only

Re: [openstack-dev] [Octavia] Object Model and DB Structure

[Eichberger, German]

--Basically no shareable entities.
+1

That will make me insanely happy :-)

Regarding Listeners: I was assuming that a LoadBalancer would map to an haproxy 
instance - and a listener would be part of that haproxy. But I heard Stephen 
say that this so not so clear cut. So maybe listeners map to haproxy 
instances...

German

-Original Message-
From: Brandon Logan [mailto:brandon.lo...@rackspace.com] 
Sent: Thursday, August 14, 2014 10:17 PM
To: openstack-dev@lists.openstack.org
Subject: [openstack-dev] [Octavia] Object Model and DB Structure

So I've been assuming that the Octavia object model would be an exact copy of 
the neutron lbaas one with additional information for Octavia.
However, after thinking about it I'm not sure this is the right way to go 
because the object model in neutron lbaas may change in the future, and Octavia 
can't just change it's object model when neutron lbaas/openstack lbaas changes 
it's object model.  So if there are any lessons learned we would like to apply 
to Octavia's object model now is the time.

Entity name changes are also on the table if people don't really like some of 
the names.  Even adding new entities or removing entities if there are good 
reasons isn't out of the question.

Anyway here are a few of my suggestions.  Please add on to this if you want.  
Also, just flat out tell me I'm wrong on some of htese suggestions if you feel 
as such.

A few improvements I'd suggest (using the current entity names):
-A real root object that is the only top level object (loadbalancer).
--This would be 1:M relationship with Listeners, but Listeners would only be 
children of loadbalancers.
--Pools, Members, and Health Monitors would follow the same workflow.
--Basically no shareable entities.

-Provisioning status only on the root object (loadbalancer).
--PENDING_CREATE, PENDING_UPDATE, PENDING_DELETE, ACTIVE (No need for a 
DEFEERRED status! YAY!) --Also maybe a DELETED status.

-Operating status on other entities
--ACTIVE or ONLINE, DEGRADED, INACTIVE or OFFLINE --Pools and Members 
--Listeners have been mentioned but I'd like to hear more details on that.

-Adding status_description field in, or something similar.  Would only eixst on 
loadbalancer entity if loadbalancer is the only top level object.

Thanks,
Brandon
___
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

[Eichberger, German]

Hi,

I think we are debating some edge-case. An important part of the flavor 
framework is the ability of me the operator to say failover from Octavia to an 
F5. So as an operator I would ensure to only offer the features in that flavor 
which both support. So in order to arrive at Brandon’s example I would have 
misconfigured my environment and rightfully would get errors at the drive level 
– which might be hard to understand for end users but hopefully pretty clear 
for me the operator…

German

From: Eugene Nikanorov [mailto:enikano...@mirantis.com]
Sent: Monday, August 11, 2014 9:56 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

Well, that exactly what we've tried to solve with tags in the flavor.

Considering your example with whole configuration being sent to the driver - i 
think it will be fine to not apply unsupported parts of configuration (like 
such HM) and mark the HM object with error status/status description.

Thanks,
Eugene.

On Tue, Aug 12, 2014 at 12:33 AM, Brandon Logan 
brandon.lo...@rackspace.commailto:brandon.lo...@rackspace.com wrote:
Hi Eugene,
An example of the HM issue (and really this can happen with any entity)
is if the driver the API sends the configuration to does not actually
support the value of an attribute.

For example: Provider A support PING health monitor type, Provider B
does not.  API allows the PING health monitor type to go through.  Once
a load balancer has been linked with that health monitor and the
LoadBalancer chose to use Provider B, that entire configuration is then
sent to the driver.  The driver errors out not on the LoadBalancer
create, but on the health monitor create.

I think that's the issue.

Thanks,
Brandon

On Tue, 2014-08-12 at 00:17 +0400, Eugene Nikanorov wrote:
 Hi folks,


 That actually going in opposite direction to what flavor framework is
 trying to do (and for dispatching it's doing the same as providers).
 REST call dispatching should really go via the root object.


 I don't quite get the issue with health monitors. If HM is incorrectly
 configured prior to association with a pool - API layer should handle
 that.
 I don't think driver implementations should be different at
 constraints to HM parameters.


 So I'm -1 on adding provider (or flavor) to each entity. After all, it
 looks just like data denormalization which actually will affect lots
 of API aspects in negative way.


 Thanks,
 Eugene.




 On Mon, Aug 11, 2014 at 11:20 PM, Vijay Venkatachalam
 vijay.venkatacha...@citrix.commailto:vijay.venkatacha...@citrix.com wrote:

 Yes, the point was to say the plugin need not restrict and
 let driver decide what to do with the API.

 Even if the call was made to driver instantaneously, I
 understand, the driver might decide to ignore
 first and schedule later. But, if the call is present, there
 is scope for validation.
 Also, the driver might be scheduling an async-api to backend,
 in which case  deployment error
 cannot be shown to the user instantaneously.

 W.r.t. identifying a provider/driver, how would it be to make
 tenant the default root object?
 tenantid is already associated with each of these entities,
 so no additional pain.
 For the tenant who wants to override let him specify provider
 in each of the entities.
 If you think of this in terms of the UI, let's say if the
 loadbalancer configuration is exposed
 as a single wizard (which has loadbalancer, listener, pool,
 monitor properties) then provider
  is chosen only once.

 Curious question, is flavour framework expected to address
 this problem?

 Thanks,
 Vijay V.

 -Original Message-
 From: Doug Wiegley 
 [mailto:do...@a10networks.commailto:do...@a10networks.com]

 Sent: 11 August 2014 22:02
 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 Sam,

 Very true.  I think that Vijay’s objection is that we are
 currently imposing a logical structure on the driver, when it
 should be a driver decision.  Certainly, it goes both ways.

 And I also agree that the mechanism for returning multiple
 errors, and the ability to specify whether those errors are
 fatal or not, individually, is currently weak.

 Doug


 On 8/11/14, 10:21 AM, Samuel Bercovici 
 samu...@radware.commailto:samu...@radware.com
 wrote:

 Hi Doug,
 
 In some implementations Driver !== Device. I think this is
 also true
 for HA Proxy.
 This might mean that there is a 

[openstack-dev] [Neutron] [LBaaS] Followup on Service Ports and IP Allocation - IPAM from LBaaS Mid Cycle meeting

[Eichberger, German]

Hi Mark,

Going through the notes from our midcycle meeting   (see 
https://etherpad.openstack.org/p/juno-lbaas-mid-cycle-hackathon) I noticed your 
name next to the Service Port and IPAM:
Service Ports

* Owner: Mark

* Nova hacks

* Nova port that nova borrows but doesn't destroy when VM is

IP allocation - IPAM

* TBD: Large task: Owner: Mark

* ability to assoc an IP that is not associated with a port/vm

* can we create a faster way of moving IP's? (Susanne)

With all the other LBaaS work we sort of lost track on that but now as we 
started work on planning for Octavia I am wondering if there is any progress on 
those topics.

Thanks a dozen,
German
___
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 in entities

[Eichberger, German]

There was also talk about a third administrative status like ON/OFF...

We really need a deeper status discussion - likely high bandwith to work all of 
that out.

German

-Original Message-
From: Brandon Logan [mailto:brandon.lo...@rackspace.com] 
Sent: Tuesday, August 05, 2014 8:27 AM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [Neutron][LBaaS] status in entities


Hello Vijay!

Well this is a hold over from v1, but the status is a provisioning status.  So 
yes, when something is deployed successfully it should be ACTIVE.  The 
exception to this is the member status, in that it's status can be INACTIVE if 
a health check fails.  Now this will probably cause edge cases when health 
checks and updates are happening to the same member.  It's been talked about 
before, but we need to really have two types of status fields, provisioning and 
operational.  IMHO, that should be something we try to get into K.

Thanks,
Brandon

On Tue, 2014-08-05 at 09:28 +, Vijay Venkatachalam wrote:
 Hi:
 
I think we had some discussions around ‘status’
 attribute earlier, I don’t recollect the conclusion.
 
 Does it reflect the deployment status?
 
Meaning, if the status of an entity is ACTIVE, the user 
 has to infer that the entity is deployed successfully in the 
 backend/loadbalancer.
 
 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
___
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

[Eichberger, German]

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] Flavor framework proposal

[Eichberger, German]

Hi Eugene,

I understand the argument with preferring tags over extensions to turn/features 
on and off since that is more fine grained. Now you are bringing up the policy 
framework to actually controlling which features are available. So let’s look 
at this example:

As an operator I want to offer a load balancer without TLS – so based on my 
understanding of flavors I would

· Create a flavor which does not have a TLS extension/tags

· Add some description on my homepage “Flavor Bronze - the reliable TLS 
less load balancer”

· Use profiles to link that flavor to some haproxy and also some 
hardware load balancer aka F6

o   Set parameters in my profile to disable TLS for the F6 LB

Now, the user  asks for a “Bronze: load balancer and I give him an F6. So he 
can go ahead and enable TLS via the TLS API (since flavors don’t control API 
restrictions) and go his merry way – unless I also use some to-be-developed 
policy extension to restrict access to certain API features.

I am just wondering if this is what we are trying to build – and then why would 
we need tags and extensions if the heavy lifting is done with the policy 
framework…

German

From: Eugene Nikanorov [mailto:enikano...@mirantis.com]
Sent: Tuesday, July 15, 2014 2:07 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron] Flavor framework proposal

Hi Stephen,

So, as was discussed, existing proposal has some aspects which better to be 
postponed, like extension list on the flavor (instead of tags).
Particularly that idea has several drawbacks:
 - it makes public API inflexible
 - turning features on/off is not what flavors should be doing, it's a task for 
policy framework and not flavors
 - flavor-based rest call dispatching is quite complex solution giving no 
benefits for service plugins
While this is not explicitly written in proposal - that's what implied there.
I think that one is a major blocker of the proposal right now, it deserves 
future discussion and not essential to the problem flavors are supposed to 
solve.
Other than that, I personally don't have much disagreements on the proposal.

The question about service type on the flavor is minor IMO. We can allow it to 
be NULL, which would mean multiservice flavor.
However, multiservice flavors may put some minor requirements to driver API 
(that's mainly because of how flavor plugin interacts with service plugins)

Thanks,
Eugene.

On Tue, Jul 15, 2014 at 11:21 PM, Stephen Balukoff 
sbaluk...@bluebox.netmailto:sbaluk...@bluebox.net wrote:
Hi folks!

I've noticed progress on the flavor framework discussion slowing down over the 
last week. We would really like to see this happen for Juno because it's 
critical for many of the features we'd also like to get into Juno for LBaaS. I 
understand there are other Neutron extensions which will need it too.

The proposal under discussion is here:

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

One of the things I've seen come up frequently in the comments is the idea that 
a single flavor would apply to more than one service type (service type being 
'LBaaS', 'FWaaS', 'VPNaaS', etc.). I've commented extensively on this, and my 
opinion is that this doesn't make a whole lot of sense.  However, there are 
people who have a different view on this, so I would love to hear from them:

Could you describe a specific usage scenario where this makes sense? What are 
the characteristics of a flavor that applies to more than one service type?

Let's see if we can come to some conclusions on this so that we can get flavors 
into Juno, please!

Thanks,
Stephen

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

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

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

Re: [openstack-dev] [Neutron] Flavor framework proposal

[Eichberger, German]

Hi Stephen,

+1

Admittedly,  since Stephen and I come from an operator centric world we have 
sometimes trouble grasping other use cases so I am wondering if you can provide 
one which would help us understand the need for grouping multiple different 
devices (LB, VPN, FW) under a single flavor.

Thanks,
German


From: Stephen Balukoff [mailto:sbaluk...@bluebox.net]
Sent: Tuesday, July 15, 2014 3:06 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron] Flavor framework proposal

Hi Salvatore and Eugene,

Responses inline:

On Tue, Jul 15, 2014 at 12:59 PM, Salvatore Orlando 
sorla...@nicira.commailto:sorla...@nicira.com wrote:
I think I've provided some examples in the review.

I was hoping for specific examples. The discussion I've seen so far has been 
vague enough that it's difficult to see what people mean. It's also possible 
you gave specific examples but these were buried in comments on previous 
revisions (one of my biggest gripes with the way Gerrit works. :P ) Could you 
please give a specific example of what you mean, as well as how it simplifies 
the user experience?

However, the point is mostly to simplify usage from a user perspective - 
allowing consumers of the neutron API to use the same flavour object for 
multiple services.

Actually, I would argue the having a single flavor valid for several different 
services complicates the user experience (and vastly complicates the operator 
experience). This is because:

* Flavors are how Operators will provide different service levels, or different 
feature sets for similar kinds of service. Users interested in paying for those 
services are likely to be more confused if a single flavor lists features for 
several different kinds of service.
* Billing becomes more incomprehensible when the same flavor is used for 
multiple kinds of service. Users and Operators should not expect to pay the 
same rate for a Gold FWaaS instance and Gold VPNaaS instance, so why 
complicate things by putting them under the same flavor?
* Because of the above concerns, it's likely that Operators will only deploy 
service profiles in a flavor for a single type of service anyway. But from the 
user's perspective, it's not apparent when looking at the list of flavors, 
which are valid for which kinds of service. What if a user tries to deploy a 
LBaaS service using a flavor that only has FWaaS service profiles associated 
with it? Presumably, the system must respond with an error indicating that no 
valid service profiles could be found for that service in that flavor. But this 
isn't very helpful to the user and is likely to lead to increased support load 
for the Operator who will need to explain this.
* A single-service flavor is going to be inherently easier to understand than a 
multi-service flavor.
* Single-service flavors do not preclude the ability for vendors to have 
multi-purpose appliances serve multiple roles in an OpenStack cloud.

There are other considerations which could be made, but since they're dependent 
on features which do not yet exist (NFV, service insertion, chaining and 
steering) I think there is no point in arguing over it.

Agreed. Though, I don't think single-service flavors paint us into a corner 
here at all. Again, things get complicated enough when it comes to service 
insertion, chaining, steering, etc. that what we'll really need at that point 
is actual orchestration. Flavors alone will not solve these problems, and 
orchestration can work with many single-service flavors to provide the illusion 
of multi-service flavors.

In conclusion I think the idea makes sense, and is a minor twist in the current 
design which should not either make the feature too complex neither prevent any 
other use case for which the flavours are being conceived. For the very same 
reason however, it is worth noting that this is surely not an aspect which will 
cause me or somebody else to put a veto on this work item.

I don't think this is a minor twist in the current design, actually:
* We'll have to deal with cases like the above where no valid service profiles 
can be found for a given kind of flavor (which we can avoid entirely if a 
flavor can have service profiles valid for only one kind of service).
* When and if tags/capabilities/extensions get introduced, we would need to 
provide an additional capabilities list on the service profiles in order to be 
able to select which service profiles provide the capabilities requested.
* The above point makes things much more complicated when it comes to 
scheduling algorithms for choosing which service profile to use when multiple 
can meet the need for a given service. What does 'weight' mean if all but two 
low-weight service profiles get eliminated as not suitable?

Another aspect to consider is how the flavours will work when the advanced 
service type they refer to is not consumable through the neutron API, which 
would be the case with an 

Re: [openstack-dev] [neutron] Flavor framework: Conclusion

[Eichberger, German]

Hi Eugene,

My understanding of the flavor framework is the following:

Say I have an F5 load balancer supporting TLS, L7, and standard loadbalancing. 
For business reasons I want to offer a Bronze (“standard load balancing”), 
silver (“Standard” + TLS), and gold (silver + L7) at different price points. 
What I absolutely don’t want is users getting Bronze load balancers and using 
TLS and L7 on them.

My understanding of the flavor framework was that by specifying (or not 
specifying) extensions I can create a diverse offering meeting my business 
needs. The way you are describing it the user selects, say a bronze flavor, and 
the system might or might not put it on a load balancer with TLS. This will 
lead to users asking for 10 Bronze  load balancers test them and discard the 
ones which don’t support TLS – this is something as a provider I would like to 
avoid.

Furthermore, in your example, say if I don’t have any TLS capable load 
balancers left and the user requests them  it will take until scheduling for 
the user to discover that we can’t accommodate him.

I can live with extensions coming in a later release but I am confused how your 
design will support above use case.

Thanks,
German

From: Eugene Nikanorov [mailto:enikano...@mirantis.com]
Sent: Thursday, July 03, 2014 10:10 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [neutron] Flavor framework: Conclusion

German,

First of all extension list looks lbaas-centric right now.
Secondly, TLS and L7 are such APIs which objects should not require 
loadbalancer or flavor to be created (like pool or healthmonitor that are pure 
db objects).
Only when you associate those objects with loadbalancer (or its child objects), 
driver may tell if it supports them.
Which means that you can't really turn those on or off, it's a generic API.
From user perspective flavor description (as interim) is sufficient to show 
what is supported by drivers behind the flavor.

Also, I think that turning extensions on/off is a bit of side problem to a 
service specification, so let's resolve it separately.


Thanks,
Eugene.

On Fri, Jul 4, 2014 at 3:07 AM, Eichberger, German 
german.eichber...@hp.commailto:german.eichber...@hp.com wrote:
I am actually a bit bummed that Extensions are postponed. In LBaaS we are 
working hard on L7 and TLS extensions which we (the operators) like to switch 
on and off with different flavors...

German

-Original Message-
From: Kyle Mestery 
[mailto:mest...@noironetworks.commailto:mest...@noironetworks.com]
Sent: Thursday, July 03, 2014 2:00 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [neutron] Flavor framework: Conclusion

Awesome, thanks for working on this Eugene and Mark! I'll still leave an item 
on Monday's meeting agenda to discuss this, hopefully it can be brief.

Thanks,
Kyle

On Thu, Jul 3, 2014 at 10:32 AM, Eugene Nikanorov 
enikano...@mirantis.commailto:enikano...@mirantis.com wrote:
 Hi,

 Mark and me has spent some time today discussing existing proposals
 and I think we got to a consensus.
 Initially I had two concerns about Mark's proposal which are
 - extension list attribute on the flavor
 - driver entry point on the service profile

 The first idea (ext list) need to be clarified more as we get more
 drivers that needs it.
 Right now we have FWaaS/VPNaaS which don't have extensions at all and
 we have LBaaS where all drivers support all extensions.
 So extension list can be postponed until we clarify how exactly we
 want this to be exposed to the user and how we want it to function on
 implementation side.

 Driver entry point which implies dynamic loading per admin's request
 is a important discussion point (at least, previously this idea
 received negative opinions from some cores) We'll implement service
 profiles, but this exact aspect of how driver is specified/loadede
 will be discussed futher.

 So based on that I'm going to start implementing this.
 I think that implementation result will allow us to develop in
 different directions (extension list vs tags, dynamic loading and
 such) depending on more information about how this is utilized by deployers 
 and users.

 Thanks,
 Eugene.



 On Thu, Jul 3, 2014 at 5:57 PM, Susanne Balle 
 sleipnir...@gmail.commailto:sleipnir...@gmail.com wrote:

 +1


 On Wed, Jul 2, 2014 at 10:12 PM, Kyle Mestery
 mest...@noironetworks.commailto:mest...@noironetworks.com
 wrote:

 We're coming down to the wire here with regards to Neutron BPs in
 Juno, and I wanted to bring up the topic of the flavor framework BP.
 This is a critical BP for things like LBaaS, FWaaS, etc. We need
 this work to land in Juno, as these other work items are dependent on it.
 There are still two proposals [1] [2], and after the meeting last
 week [3] it appeared we were close to conclusion on this. I now see
 a bunch of comments on both proposals.

 I'm going to again suggest we spend some time

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

[Eichberger, German]

Hi Jorge,

+1 for QUEUED and DETACHED

I would suggest to make the time how long we keep entities in DELETED state 
configurable. We use something like 30 days, too, but we have made it 
configurable to adapt to changes...

German

-Original Message-
From: Jorge Miramontes [mailto:jorge.miramon...@rackspace.com] 
Sent: Thursday, July 03, 2014 11:59 AM
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

+1 to QUEUED status.

For entities that have the concept of being attached/detached why not have a 
'DETACHED' status to indicate that the entity is not provisioned at all (i.e. 
The config is just stored in the DB). When it is attached during provisioning 
then we can set it to 'ACTIVE' or any of the other provisioning statuses such 
as 'ERROR', 'PENDING_UPDATE', etc. Lastly, it wouldn't make much sense to have 
a 'DELETED' status on these types of entities until the user actually issues a 
DELETE API request (not to be confused with detaching). Which begs another 
question, when items are deleted how long should the API return responses for 
that resource? We have a 90 day threshold for this in our current 
implementation after which the API returns 404's for the resource.

Cheers,
--Jorge




On 7/3/14 10:39 AM, Phillip Toohill phillip.tooh...@rackspace.com
wrote:

If the objects remain in 'PENDING_CREATE' until provisioned it would 
seem that the process got stuck in that status and may be in a bad 
state from user perspective. I like the idea of QUEUED or similar to 
reference that the object has been accepted but not provisioned.

Phil

On 7/3/14 10:28 AM, Brandon Logan brandon.lo...@rackspace.com wrote:

With the new API and object model refactor there have been some issues 
arising dealing with the status of entities.  The main issue is that 
Listener, Pool, Member, and Health Monitor can exist independent of a 
Load Balancer.  The Load Balancer is the entity that will contain the 
information about which driver to use (through provider or flavor).  
If a Listener, Pool, Member, or Health Monitor is created without a 
link to a Load Balancer, then what status does it have?  At this point 
it only exists in the database and is really just waiting to be 
provisioned by a driver/backend.

Some possibilities discussed:
A new status of QUEUED, PENDING_ACTIVE, SCHEDULED, or some other name 
Entities just remain in PENDING_CREATE until provisioned by a driver 
Entities just remain in ACTIVE until provisioned by a driver

Opinions and suggestions?
___
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] Flavor framework: Conclusion

[Eichberger, German]

I am actually a bit bummed that Extensions are postponed. In LBaaS we are 
working hard on L7 and TLS extensions which we (the operators) like to switch 
on and off with different flavors...  

German

-Original Message-
From: Kyle Mestery [mailto:mest...@noironetworks.com] 
Sent: Thursday, July 03, 2014 2:00 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [neutron] Flavor framework: Conclusion

Awesome, thanks for working on this Eugene and Mark! I'll still leave an item 
on Monday's meeting agenda to discuss this, hopefully it can be brief.

Thanks,
Kyle

On Thu, Jul 3, 2014 at 10:32 AM, Eugene Nikanorov enikano...@mirantis.com 
wrote:
 Hi,

 Mark and me has spent some time today discussing existing proposals 
 and I think we got to a consensus.
 Initially I had two concerns about Mark's proposal which are
 - extension list attribute on the flavor
 - driver entry point on the service profile

 The first idea (ext list) need to be clarified more as we get more 
 drivers that needs it.
 Right now we have FWaaS/VPNaaS which don't have extensions at all and 
 we have LBaaS where all drivers support all extensions.
 So extension list can be postponed until we clarify how exactly we 
 want this to be exposed to the user and how we want it to function on 
 implementation side.

 Driver entry point which implies dynamic loading per admin's request 
 is a important discussion point (at least, previously this idea 
 received negative opinions from some cores) We'll implement service 
 profiles, but this exact aspect of how driver is specified/loadede 
 will be discussed futher.

 So based on that I'm going to start implementing this.
 I think that implementation result will allow us to develop in 
 different directions (extension list vs tags, dynamic loading and 
 such) depending on more information about how this is utilized by deployers 
 and users.

 Thanks,
 Eugene.



 On Thu, Jul 3, 2014 at 5:57 PM, Susanne Balle sleipnir...@gmail.com wrote:

 +1


 On Wed, Jul 2, 2014 at 10:12 PM, Kyle Mestery 
 mest...@noironetworks.com
 wrote:

 We're coming down to the wire here with regards to Neutron BPs in 
 Juno, and I wanted to bring up the topic of the flavor framework BP.
 This is a critical BP for things like LBaaS, FWaaS, etc. We need 
 this work to land in Juno, as these other work items are dependent on it.
 There are still two proposals [1] [2], and after the meeting last 
 week [3] it appeared we were close to conclusion on this. I now see 
 a bunch of comments on both proposals.

 I'm going to again suggest we spend some time discussing this at the 
 Neutron meeting on Monday to come to a closure on this. I think 
 we're close. I'd like to ask Mark and Eugene to both look at the 
 latest comments, hopefully address them before the meeting, and then 
 we can move forward with this work for Juno.

 Thanks for all the work by all involved on this feature! I think 
 we're close and I hope we can close on it Monday at the Neutron meeting!

 Kyle

 [1] https://review.openstack.org/#/c/90070/
 [2] https://review.openstack.org/102723
 [3]
 http://eavesdrop.openstack.org/meetings/networking_advanced_services
 /2014/networking_advanced_services.2014-06-27-17.30.log.html

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

Re: [openstack-dev] [Neutron][LBaaS] Which entities need status

[Eichberger, German]

Hi Doug  Brandon,

1) +1 Doug -- I like the status Building but that's a personal preference. 
It's entirely up to the driver (but it should be reasonable) and we should pick 
the states up front (as we already do with constants)

2) We actually touched upon that with the distinction between status and 
operational status -- that should take care of that.

German

-Original Message-
From: Doug Wiegley [mailto:do...@a10networks.com] 
Sent: Tuesday, June 24, 2014 11:53 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron][LBaaS] Which entities need status

Hi Brandon,

I think just one status is overloading too much onto the LB object (which is 
perhaps something that a UI should do for a user, but not something an API 
should be doing.)

 1) If an entity exists without a link to a load balancer it is purely 
 just a database entry, so it would always be ACTIVE, but not really 
 active in a technical sense.

Depends on the driver.  I don¹t think this is a decision for lbaas proper.


 2) If some of these entities become shareable then how does the status 
 reflect that the entity failed to create on one load balancer but was 
 successfully created on another.  That logic could get overly complex.

That¹s a status on the join link, not the object, and I could argue multiple 
ways in which that should be one way or another based on the backend, which to 
me, again implies driver question (backend could queue for later, or error 
immediately, or let things run degraded, orŠ)

Thanks,
Doug




On 6/24/14, 11:23 AM, Brandon Logan brandon.lo...@rackspace.com wrote:

I think we missed this discussion at the meet-up but I'd like to bring 
it up here.  To me having a status on all entities doesn't make much 
sense, and justing having a status on a load balancer (which would be a 
provisioning status) and a status on a member (which would be an 
operational status) are what makes sense because:

1) If an entity exists without a link to a load balancer it is purely 
just a database entry, so it would always be ACTIVE, but not really 
active in a technical sense.

2) If some of these entities become shareable then how does the status 
reflect that the entity failed to create on one load balancer but was 
successfully created on another.  That logic could get overly complex.

I think the best thing to do is to have the load balancer status 
reflect the provisioning status of all of its children.  So if a health 
monitor is updated then the load balancer that health monitor is linked 
to would have its status changed to PENDING_UPDATE.  Conversely, if a 
load balancer or any entities linked to it are changed and the load 
balancer's status is in a non-ACTIVE state then that update should not 
be allowed.

Thoughts?

Thanks,
Brandon


___
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] Great Mid-cycle Sprint

[Eichberger, German]

+ 1

I was also very happy that Doug came – he was adding a much needed lb 
manufacturer perspective.

Thanks to Rackspace and especially Brandon for hosting. This was a great event. 
And many thanks to Kyle and Mark for coming out and the great guidance they 
provided.

Great to see you all –
German

From: Stephen Balukoff [mailto:sbaluk...@bluebox.net]
Sent: Friday, June 20, 2014 5:37 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron][LBaaS] Great Mid-cycle Sprint

+1 to what Brandon just said. :)

Seriously, though-- this week was nothing short of amazing! It's great to have 
such a wonderful team to work with, eh! And yes-- special thanks to Mark 
McClain and Kyle Mestery for being willing to come out and work so hard with us 
to make so much progress in such little time.

LBaaS in Juno is going to kick ass!

Stephen

On Thu, Jun 19, 2014 at 9:17 PM, Brandon Logan 
brandon.lo...@rackspace.commailto:brandon.lo...@rackspace.com wrote:
Greetings all,
I'd like to thank everyone who attended the LBaaS mid-cyle sprint for
taking the time and effort to make the trip to San Antonio.  This was a
very productive sprint in all forms: direction, consensus, blueprints,
documentation, and of course code.  It was just great to be able to get
so much done and have a clearer idea on the direction this project is
headed.

I'd like to especially thank Kyle Mestery and Mark Mcclain for taking
the time out of their busy schedules to direct, teach, and giving us
help where and when we needed.  The fact that they managed to have the
patience for three full days of this is just amazing.  Actually, them
having the patience over the last few months and still willing to help
is just short of miraculous.  Thanks again guys, you are great!

I look forward to continuing to work with everyone on this and other
projects.  We've got a lot to do but we'll be able to accomplish
everything we want if we continue to work together.  Thanks again to all
involved!

Brandon

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



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

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

[Eichberger, German]

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] 
Sent: Tuesday, June 10, 2014 12:18 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron][LBaaS] TLS support RST document on Gerrit

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

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

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


___
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

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

[Eichberger, German]

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]
Sent: Tuesday, June 10, 2014 12:18 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron][LBaaS] TLS support RST document on Gerrit

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

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

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

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

[Eichberger, German]

From an LBaaS view we have two use cases we access the certs:

1) When a new LB is build, an LB is changed, etc. -- we throw an error if the 
certificate is missing, broken, etc,

2) When we want to failover -- we use the last good certificate from a safe 
place (aka local copy, barbican copy, etc.)

Establishing a safe place outside Barbican has its drawbacks, e.g. a user's 
cert is compromised and he rather wants failover, etc. to fail then run any 
longer with the compromised cert --

So and that is a question back to Barbican. Can the normal delete just be a 
flag, e.g. deleted but still preserves the certificate and LBaaS can decide if 
they throw an error or utilize the deleted cert.

And then we have an rm -f which nukes it and has side effects...

German

-Original Message-
From: Doug Wiegley [mailto:do...@a10networks.com] 
Sent: Wednesday, June 11, 2014 10:57 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron][LBaaS] TLS support RST document on Gerrit

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

Thanks,
Doug


On 6/11/14, 11:43 AM, Clark, Robert Graham robert.cl...@hp.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]
 Sent: Tuesday, June 10, 2014 12:18 PM
 To: OpenStack Development Mailing List (not for usage questions)
 Subject: Re: [openstack-dev] [Neutron][LBaaS] TLS support RST 
 document on Gerrit
 
 See adams message re: Re: [openstack-dev] [Neutron][LBaaS] Barbican 
 Neutron LBaaS Integration Ideas.
 He's advocating keeping a shadow copy of the private key that is 
 owned
by
 the LBaaS service so that incase a key is tampered with during an LB
update
 migration etc we can still check with the shadow backup and compare 
 it
to
 the user owned TLS container in case its not their it can be used.
 
 On Jun 10, 2014, at 12:47 PM, Samuel Bercovici samu...@radware.com
  wrote:
 
  To elaborate on the case where containers get deleted while LBaaS
still
 references it.
  We think that the following approach will do:
  * The end user can delete a container and leave a dangling
 reference in LBaaS.
  * It would be nice to allow adding meta data on the
container so that
 the user will be aware which listeners use this container. This is
optional. It
 can also be optional for LBaaS to implement adding the listeners ID 
 automatically into this metadata just for information.
  * In LBaaS, if an update happens which requires to pull the
container
 from Barbican and if the ID references a non-existing container, the
update
 will fail and will indicate that the reference certificate does not
exists any
 more. This validation could be implemented on the LBaaS API itself as
well
 as also by the driver who will actually need the container.
 
  Regards,
  -Sam.
 
 
  From: Evgeny Fedoruk
  Sent: Tuesday, June 10, 2014 2:13 PM
  To: OpenStack Development Mailing List (not for usage questions)
  Subject: Re: [openstack-dev] [Neutron][LBaaS] TLS support RST
document
  on Gerrit
 
  Hi All,
 
  Carlos, Vivek, German, thanks for reviewing the RST doc.
  There are some issues I want to pinpoint final decision on them
here, in
 ML, before writing it down in the doc.
  Other issues will be commented on the document itself.
 
  1.   Support/No support in JUNO
  Referring to summit's etherpad
 https://etherpad.openstack.org/p/neutron-lbaas-ssl-l7

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

[Eichberger, German]

Jorge + John,

I am most concerned with a user changing his secret in barbican and then the LB 
trying to update and causing downtime. Some users like to control when the 
downtime occurs.

For #1 it was suggested that once the event is delivered it would be up to a 
user to enable an auto-update flag.

In the case of #2 I am a bit worried about error cases: e.g. uploading the 
certificates succeeds but registering the loadbalancer(s) fails. So using the 
barbican system for those warnings might not as fool proof as we are hoping. 

One thing I like about #2 over #1 is that it pushes a lot of the information to 
Barbican. I think a user would expect when he uploads a new certificate to 
Barbican that the system warns him right away about load balancers using the 
old cert. With #1 he might get an e-mails from LBaaS telling him things changed 
(and we helpfully updated all affected load balancers) -- which isn't as 
immediate as #2. 

If we implement an auto-update flag for #1 we can have both. User's who like 
#2 juts hit the flag. Then the discussion changes to what we should implement 
first and I agree with Jorge + John that this should likely be #2.

German

-Original Message-
From: Jorge Miramontes [mailto:jorge.miramon...@rackspace.com] 
Sent: Friday, June 06, 2014 3:05 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron][LBaaS] Barbican Neutron LBaaS 
Integration Ideas

Hey John,

Correct, I was envisioning that the Barbican request would not be affected, but 
rather, the GUI operator or API user could use the registration information to 
do so should they want to do so.

Cheers,
--Jorge




On 6/6/14 4:53 PM, John Wood john.w...@rackspace.com wrote:

Hello Jorge,

Just noting that for option #2, it seems to me that the registration 
feature in Barbican would not be required for the first version of this 
integration effort, but we should create a blueprint for it nonetheless.

As for your question about services not registering/unregistering, I 
don't see an issue as long as the presence or absence of registered 
services on a Container/Secret does not **block** actions from 
happening, but rather is information that can be used to warn clients 
through their processes. For example, Barbican would still delete a 
Container/Secret even if it had registered services.

Does that all make sense though?

Thanks,
John


From: Youcef Laribi [youcef.lar...@citrix.com]
Sent: Friday, June 06, 2014 2:47 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron][LBaaS] Barbican Neutron LBaaS 
Integration Ideas

+1 for option 2.

In addition as an additional safeguard, the LBaaS service could check 
with Barbican when failing to use an existing secret to see if the 
secret has changed (lazy detection).

Youcef

-Original Message-
From: Jorge Miramontes [mailto:jorge.miramon...@rackspace.com]
Sent: Friday, June 06, 2014 12: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 

Re: [openstack-dev] [Neutron][LBaaS] Requirements around statistics and billing

[Eichberger, German]

Hi Stephen,

We would like all those numbers as well ☺

Additionally, we measure:

· When a lb instance was created, deleted, etc.

· For monitoring we “ping” a load balancers health check and report/act 
on the results

· For user’s troubleshooting we make the haproxy logs available. Which 
contain connection information like from, to, duration, protocol, status 
(though we frequently have been told that this is not really useful for 
debugging…) and of course having that more gui-fied would be neat

German



From: Stephen Balukoff [mailto:sbaluk...@bluebox.net]
Sent: Tuesday, May 27, 2014 8:22 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [Neutron][LBaaS] Requirements around statistics and 
billing

Hi folks!

We have yet to have any kind of meaningful discussion on this list around load 
balancer stats (which, I presume to include data that will eventually need to 
be consumed by a billing system). I'd like to get the discussion started here, 
as this will have significant meaning for how we both make this data available 
to users, and how we implement back-end systems to be able to provide this data.

So!  What kinds of data are people looking for, as far as load balancer 
statistics.

For our part, as an absolute minimum we need the following per loadbalancer + 
listener combination:

* Total bytes transferred in for a given period
* Total bytes transferred out for a given period

Our product and billing people I'm sure would like the following as well:

* Some kind of peak connections / second data (95th percentile or average over 
a period, etc.)
* Total connections for a given period
* Total HTTP / HTTPS requests served for a given period

And the people who work on UIs and put together dashboards would like:

* Current requests / second (average for last X seconds, either on-demand, or 
simply dumped regularly).
* Current In/Out bytes throughput

And our monitoring people would like this:

* Errors / second
* Current connections / second and bytes throughput secant slope (ie. like 
derivative but easier to calculate from digital data) for last X seconds (ie. 
detecting massive spikes or drops in traffic, potentially useful for detecting 
a problem before it becomes critical)

And some of our users would like all of the above data per pool, and not just 
for loadbalancer + listener. Some would also like to see it per member (though 
I'm less inclined to make this part of our standard).

I'm also interested in hearing vendor capabilities here, as it doesn't make 
sense to design stats that most can't implement, and I imagine vendors also 
have valuable data on what their customer ask for / what stats are most useful 
in troubleshooting.

What other statistics data for load balancing are meaningful and hopefully not 
too arduous to calculate? What other data are your users asking for or 
accustomed to seeing?

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

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

[Eichberger, German]

Hi,

From deep below in the e-mail chain:
Same here. Cascade-deleting of shared objects should not be allowed in any case.

Being able to delete all lbs and related constructs after a customer leaves 
and/or for tests is a pretty important requirements for us. It does not 
necessarily have to be accomplished by a cascading delete on the user api (we 
could use an admin api for that) but it is important in  our data model to 
avoid  constraint violation when we want to clean everything out…

I am still with Jorge that sharing of objects in whatever form might confuse 
customers who will then use up costly customer support time and hence not 
entirely in the interest of us public cloud providers. The examples with the 
status is another example for that…

German

From: Stephen Balukoff [mailto:sbaluk...@bluebox.net]
Sent: Friday, May 30, 2014 9:44 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron][LBaaS] dealing with M:N relashionships 
for Pools and Listeners

Hi y'all!

Re-responses inline:

On Fri, May 30, 2014 at 8:25 AM, Brandon Logan 
brandon.lo...@rackspace.commailto:brandon.lo...@rackspace.com wrote:

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




 Depending on the object... either the status of the child object
 itself or all of its affected parent(s). Since we're allowing reusing
 of the pool object, when getting the status of a pool, maybe it makes
 sense to produce a list showing the status of all the pool's members,
 as well as the update status of all the listeners using the pool?
This is confusing to me.  Will there be a separate provisioning status
field on the loadbalancer and just a generic status on the child
objects?  I get the idea of a pool having a status the reflects the
state of all of its members.  Is that what you mean by status of a child
object?

It seems to me that we could use the 'generic status' field on the load 
balancer to show provisioning status as well. :/  Is there a compelling reason 
we couldn't do this? (Sam?)

And yes, I think that's what I mean with one addition. For example:

If I have Listener A and B which use pool X which has members M and N...  if I 
set member 'M' to be 'ADMIN_STATE_DISABLED', then what I would expect to see, 
if I ask for the status of pool X immediately after this change is:
* An array showing N is 'UP' and 'M' is in state 'ADMIN_STATE_DISABLED' and
* An array showing that listeners 'A' and 'B' are in 'PENDING_UPDATE' state (or 
something similar).

I would also expect listeners 'A' and 'B' to go back to 'UP' state shortly 
thereafter.

Does this make sense?

Note that there is a problem with my suggestion: What does the status of a 
member mean when the member is referenced indirectly by several listeners?  
(For example, listener A could see member N as being UP, whereas listener B 
could see member N as being DOWN.)  Should member statuses also be an array 
from the perspective of each listener? (in other words, we'd have a 
two-dimensional array here.)

If we do this then perhaps the right thing to do is just list the pool members' 
statuses in context of the listeners.  In other words, if we're reporting this 
way, then given the same scenario above, if we set member 'M' to be 
'ADMIN_STATE_DISABLED', then asking for the status of pool X immediately after 
this change is:
* (Possibly?) an array for each listener status showing them as 'PENDING_UPDATE'
* An array for member statuses which contain:
** An array which shows member N is 'UP' for listener 'A' and 'DOWN' for 
listener 'B'
** An array which shows member M is 'PENDING_DISABLED' for both listener 'A' 
and 'B'

...and then shortly thereafter we would see member M's status for each listener 
change to 'DISABLED' at the same time the listeners' statuses change to 'UP'.

So... this second way of looking at it is less intuitive to me, though it is 
probably more correct. Isn't object re-use fun?



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


 Assuming you're not talking about an alert which would be generated by
 a back-end load balancer and get routed to some notification system...
 I think you should be able to get the status of a member by just
 checking the member status directly (ie.  GET /members/[UUID]) or, if
 people like my suggestion above, by checking the status of the pool to
 which the member belongs (ie. GET /pools/[UUID]).


 ·Administrator state management

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


 I'm thinking that disabling members, pools, and listeners should
 propagate to all parent objects. (For example, disabling a member
 should propagate to all affected pools and listeners, which
 

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

[Eichberger, German]

All,

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

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

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

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

German

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

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


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

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

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

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

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


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

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

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

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


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


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

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

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

[Eichberger, German]

Hi Sam,

I totally agree - this will definitely reduce our scope and increase the chance 
of getting this in.

I am still (being influenced by Unix methodology) thinking that we should 
explore service chaining more for that. As I said earlier, re-encryption feels 
more like a VPN type thing than a load balancer. Hence, I can imagine a very 
degenerated VPN service which re-encrypts things with SSL. But, admittedly, I 
am looking at that as a software engineer and not a network engineer :)

German

From: Samuel Bercovici [mailto:samu...@radware.com]
Sent: Thursday, May 22, 2014 11:44 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [Neutron][LBaaS]TLS API support for authentication

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] Updated Object Model?

[Eichberger, German]

Hi,

I agree with Logan I am wondering if you can share a use case with multiple 
health monitors.

German

From: Brandon Logan [mailto:brandon.lo...@rackspace.com]
Sent: Thursday, May 15, 2014 5:41 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron][LBaaS] Updated Object Model?

I have concerns about multiple health monitors on the same pool.  Is this 
always going to be the same type of health monitor?  There's also ambiguity in 
the case where one health monitor fails and another doesn't.  Is it an AND or 
OR that determines whether the member is down or not?

Thanks,
Brandon Logan

From: Eugene Nikanorov enikano...@mirantis.commailto:enikano...@mirantis.com
Reply-To: 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Date: Thursday, May 15, 2014 at 9:55 AM
To: 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [Neutron][LBaaS] Updated Object Model?

Vijay,

Pools-monitors are still many to many, if it's not so on the picture - we'll 
fix that.
I brought this up as an example of how we dealt with m:n via API.

Thanks,
Eugene.

On Thu, May 15, 2014 at 6:43 PM, Vijay Venkatachalam 
vijay.venkatacha...@citrix.commailto:vijay.venkatacha...@citrix.com wrote:
Thanks for the clarification. Eugene.

A tangential point since you brought healthmon and pool.

There will be an additional entity called 'PoolMonitorAssociation' which 
results in a many to many relationship between pool and monitors. Right?

Now, the model is indicating a pool can have only one monitor. So a minor 
correction is required to indicate the many to many relationship via 
PoolMonitorAssociation.

Thanks,
Vijay V.


From: Eugene Nikanorov 
[mailto:enikano...@mirantis.commailto:enikano...@mirantis.com]
Sent: Thursday, May 15, 2014 7:36 PM

To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron][LBaaS] Updated Object Model?

Hi Vijay,


When you say API is not available, it means this should not be considered like 
a resource/entity. Correct?

But then, there would be API like a bind API, that accepts loadbalancer_id  
listener_id,  which creates this object.
And also, there would be an API that will be used to list the listeners of a 
LoadBalancer.

Right?
Right, that's the same as health monitors and pools work right now: there are 
separate REST action to associate healthmon to a pool


Thanks,
Eugene.

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

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

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

[Eichberger, German]

Hi,

The pods are actually in level 2.

Thanks,
German

From: Susanne Balle [mailto:sleipnir...@gmail.com]
Sent: Monday, May 12, 2014 11:45 AM
To: OpenStack Development Mailing List (not for usage questions)
Cc: Monty Taylor; Jay Pipes; Nachi Ueno; Sumit Naiksatam; Kyle Mestery; 
mmccl...@yahoo-inc.com; Barclay, Alex (HPCS Seattle); Adam Harwell; Eugene 
Nikanorov; jorge.miramon...@rackspace.com; Stephen Balukoff; Eichberger, 
German; Cuddy, Tim
Subject: Re: [openstack-dev] [Neutron][LBaaS][FWaaS][VPNaaS] Advanced Services 
(particularly LBaaS) and Neutron

I apologize if you received this email already 

Reminder that we plan to meet tomorrow

Tuesday May 13 at 2pm at the Neutron pod on level 3.

Susanne

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.

On Mon, May 12, 2014 at 12:40 PM, Balle, Susanne 
susanne.ba...@hp.commailto:susanne.ba...@hp.com wrote:
Reminder that we plan to meet tomorrow

Tuesday May 13 at 2pm at the Neutron pod on level 3.

Susanne

Sent from my iPhone

On May 7, 2014, at 7:45 AM, Susanne Balle 
sleipnir...@gmail.commailto:sleipnir...@gmail.commailto:sleipnir...@gmail.commailto:sleipnir...@gmail.com
 wrote:

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

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

[Eichberger, German]

Our current HP LBaaS implementation only supports one VIP (aka one IP address). 
So statistics of multiple VIPs will be hard to find. We have been asked for use 
cases to support IPv4 and IPv6 as Rackspace. 

I have heard of some use cases where a load balancer (loosely defined as 
container) might have an Intranet IP and a public IP... admittedly that can be 
solved with two load balancers so that might not be too big an issue...

German


-Original Message-
From: Samuel Bercovici [mailto:samu...@radware.com] 
Sent: Friday, May 09, 2014 1:41 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron][LBaaS] Multiple VIPs per loadbalancer

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

___
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

[Eichberger, German]

Hi,

Some of our users are not that organized and certificate expirations seem to 
sneak up on them. So they are looking for a single place where they can 
manage their certificates. I am not sure if splitting storage between 
Barbican and Neutron will allow that. I am also wondering if Barbican is 
aspiring to become that central place...

German

From: Carlos Garza [mailto:carlos.ga...@rackspace.com]
Sent: Thursday, May 08, 2014 9:54 AM
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 8, 2014, at 5:19 AM, Samuel Bercovici 
samu...@radware.commailto:samu...@radware.com
 wrote:


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.

   Is your statement equivalent to On all the options above, Babican can 
optionally be used to store the (X509,private_key) or just the private_key.
If thats what you mean then we are on the same page. private part of a 
certificate is not a valid statement for me since x509 certs don't contain 
private parts.

I'm advocating the latter where barbican stores the key only and we store the 
X509 on our own database.


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.comhttp://hp.com]
Sent: Thursday, May 08, 2014 12:43 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron] [LBaaS][VPN][Barbican] SSL cert 
implementation for LBaaS and VPN

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

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

-Rob

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


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

Hi John,

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

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





-Sam.



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

Hello Samuel,

Just noting that the link below shows current-state Barbican. We are in the 
process of 

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

[Eichberger, German]

Carlos,

+1

My impression of barbican is that they indeed see themselves as sending updates 
to the LBs/VPN/X - but I am not too excited about that. Any marginally 
sophisticated user wants to control when we burst out new certificates so they 
can tie that to their maintenance window (in case client certs need to be 
updated).

German

From: Carlos Garza [mailto:carlos.ga...@rackspace.com]
Sent: Thursday, May 08, 2014 11:54 AM
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 8, 2014, at 1:41 PM, Eichberger, German 
german.eichber...@hp.commailto:german.eichber...@hp.com
 wrote:


Hi,

Some of our users are not that organized and certificate expirations seem to 
sneak up on them. So they are looking for a single place where they can 
manage their certificates. I am not sure if splitting storage between 
Barbican and Neutron will allow that. I am also wondering if Barbican is 
aspiring to become that central place...

Ok but in our implementation we may decide to duplicate the X509s in our 
database so that we can search and do searches on them with out going over a 
separate API service. So we don't mind storing them in both locations. We just 
worry about case were people update their (x509,priv_key) via barbican but 
existing loadbalancers in neutron would then be unaware of the new updated 
cert. This would seem to imply that barbican would need to trigger an update on 
neutron/lbaas. :(




German

From: Carlos Garza [mailto:carlos.ga...@rackspace.comhttp://rackspace.com]
Sent: Thursday, May 08, 2014 9:54 AM
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 8, 2014, at 5:19 AM, Samuel Bercovici 
samu...@radware.commailto:samu...@radware.com
 wrote:



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.

   Is your statement equivalent to On all the options above, Babican can 
optionally be used to store the (X509,private_key) or just the private_key.
If thats what you mean then we are on the same page. private part of a 
certificate is not a valid statement for me since x509 certs don't contain 
private parts.

I'm advocating the latter where barbican stores the key only and we store the 
X509 on our own database.



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.comhttp://hp.com]
Sent: Thursday, May 08, 2014 12:43 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron] [LBaaS][VPN][Barbican] SSL cert 
implementation for LBaaS and VPN

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

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

-Rob

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


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

Hi John,

If the user already has an SSL certificate that was acquired outside of the 
barbican Ordering system, how can he store it securely in Barbican as a SSL 
Certificate?
The Container stored this information in a very generic way, I think that there 
should be an API that formalizes a specific way

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

[Eichberger, German]

Stephen,

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

Thanks,
German

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

Yep, I'm all for this as well!

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

Thanks,
Stephen

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

Cheers,
--Jorge

From: Samuel Bercovici samu...@radware.commailto:samu...@radware.com
Reply-To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Date: Thursday, May 1, 2014 12:39 PM
To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Subject: [openstack-dev] [Neutron][LBaaS]User Stories and sruvey

Hi Everyone!

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

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

Please let me know if this is acceptable.

Regards,
-Sam.




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



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

Re: [openstack-dev] [Neutron][LBaaS] Thoughts on current process

[Eichberger, German]

Hi ,

As Stephen +1 to everything Jorge said. Another concern is that some decisions 
impacting LBaaS operator requirements (e.g SSL, flavor framework, service 
chaining) are discussed/decided in the advanced services group (see 
https://wiki.openstack.org/wiki/Neutron/AdvancedServices). Vijay did an 
excellent job involving us in LBaaS in the SSL discussion. Thanks, Vijay!

I am wondering how the process is supposed to work between the two groups. 
There is a lot of overlap right now and decisions in the areas currently 
discussed in Advanced Services impact our operator requirements for load 
balancing a great deal. Kyle, I am wondering if you can provide some guidance 
what your vision is how LBaaS operator requirements get considered in other 
parts of Neutron.

Thanks,
German

From: Stephen Balukoff [mailto:sbaluk...@bluebox.net]
Sent: Wednesday, April 30, 2014 5:07 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron][LBaaS] Thoughts on current process

Hi Jorge!

+1 to everything you just said. In fact, I think you said essentially what I 
was trying to last week with 100% less drama.

I'll work to add workflows to my proposal, but please note it's late on a 
Wednesday and tomorrow's IRC meeting is awfully early in my time zone. I 
probably won't have workflow documentation done in time.

Thanks,
Stephen


On Wed, Apr 30, 2014 at 3:26 PM, Jorge Miramontes 
jorge.miramon...@rackspace.commailto:jorge.miramon...@rackspace.com wrote:
Oops! Everywhere I said Samuel I meant Stephen. Sorry you both have SB as
you initials so I got confused. :)

Cheers,
--Jorge




On 4/30/14 5:17 PM, Jorge Miramontes 
jorge.miramon...@rackspace.commailto:jorge.miramon...@rackspace.com
wrote:

Hey everyone,

I agree that we need to be preparing for the summit. Using Google docs
mixed with Openstack wiki works for me right now. I need to become more
familiar the gerrit process and I agree with Samuel that it is not
conducive to large design discussions. That being said I'd like to add
my thoughts on how I think we can most effectively get stuff done.

As everyone knows there are many new players from across the industry that
have an interest in Neutron LBaaS. Companies I currently see
involved/interested are Mirantis, Blue Box Group, HP, PNNL, Citrix,
eBay/Paypal and Rackspace. We also have individuals involved as well. I
echo Kyle's sentiment on the passion everyone is bringing to the project!
Coming into this project a few months ago I saw that a few things needed
to be done. Most notably, I realized that gathering everyone's
expectations on what they wanted Neutron LBaaS to be was going to be
crucial. Hence, I created the requirements document. Written requirements
are important within a single organization. They are even more important
when multiple organizations are working together because everyone is
spread out across the world and every organization has a different
development process. Again, my goal with the requirements document is to
make sure that everyone's voice in the community is taken into
consideration. The benefit I've seen from this document is that we ask
Why? to each other, iterate on the document and in the end have a clear
understanding of everyone's motives. We also learn from each other by
doing this which is one of the great benefits of open source.

Now that we have a set of requirements the next question to ask is, How
doe we prioritize requirements so that we can start designing and
implementing them? If this project were a completely new piece of
software I would argue that we iterate on individual features based on
anecdotal information. In essence I would argue an agile approach.
However, most of the companies involved have been operating LBaaS for a
while now. Rackspace, for example, has been operating LBaaS for the better
part of 4 years. We have a clear understanding of what features our
customers want and how to operate at scale. I believe other operators of
LBaaS have the same understanding of their customers and their operational
needs. I guess my main point is that, collectively, we have data to back
up which requirements we should be working on. That doesn't mean we
preclude requirements based on anecdotal information (i.e. Our customers
are saying they want new shiny feature X). At the end of the day I want
to prioritize the community's requirements based on factual data and
anecdotal information.

Assuming requirements are prioritized (which as of today we have a pretty
good idea of these priorities) the next step is to design before laying
down any actual code. I agree with Samuel that pushing the cart before the
horse is a bad idea in this case (and it usually is the case in software
development), especially since we have a pretty clear idea on what we need
to be designing for. I understand that the current code base has been
worked on by many individuals and the work done thus far is the reason why
so many new faces are 

Re: [openstack-dev] [Neutron][LBaaS] BBG edit of new API proposal

[Eichberger, German]

Stephen + Sam,

I have added some of the operator use cases. We also created a document earlier 
(https://docs.google.com/spreadsheet/ccc?key=0Ar1FuMFYRhgadDVXZ25NM2NfbGtLTkR0TDFNUWJQUWc#gid=0)
 listing all the features we consider essential (and everybody voted with real 
world data) for the LB users. I have added them to the document though not 
turned them into nice user stories. I also added a link.

German

From: Stephen Balukoff [mailto:sbaluk...@bluebox.net]
Sent: Monday, April 28, 2014 4:24 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron][LBaaS] BBG edit of new API proposal

Hi guys,

Sorry for all the drama on the list lately.

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.

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

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

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.

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.

Thanks,
Stephen



On Mon, Apr 28, 2014 at 2:12 PM, Eichberger, German 
german.eichber...@hp.commailto:german.eichber...@hp.com wrote:
Sam,

The use cases where pretty complete the last time I checked so let's move them 
to gerrit so we can all vote.

Echoing Kyle I would love to see us focusing on getting things ready for the 
summit.

German

-Original Message-
From: Samuel Bercovici [mailto:samu...@radware.commailto: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.commailto: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

Re: [openstack-dev] [Neutron][LBaaS] BBG edit of new API proposal

[Eichberger, German]

Vijay,

SSL and certificate management is a major requirement from a cloud operator 
perspective. The VPN part of Neutron is looking into using Barbican and I am 
surprised that LB is going a different way/implementing their own store. Just 
for the record I prefer Barbican ☺

Furthermore, we are still discussing the API and have several proposals so I am 
not sure how the SSL API/implementation you are proposing fits into that.

German

From: Vijay B [mailto:os.v...@gmail.com]
Sent: Tuesday, April 29, 2014 2:30 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron][LBaaS] BBG edit of new API proposal

Also, a section for the API specification for the newly created SSL extensions 
needs to be added to https://wiki.openstack.org/wiki/Neutron/LBaaS/SSL.

Regards,
Vijay

On Tue, Apr 29, 2014 at 1:55 PM, Vijay B 
os.v...@gmail.commailto:os.v...@gmail.com wrote:
Hi Sam, Evgeny,

I've reviewed https://review.openstack.org/#/c/74031 with my comments. I am not 
sure if there is a request with code newer than this link - please do let me 
know if that is the case.

Thanks,
Regards,
Vijay

On Mon, Apr 28, 2014 at 2:12 PM, Eichberger, German 
german.eichber...@hp.commailto:german.eichber...@hp.com wrote:
Sam,

The use cases where pretty complete the last time I checked so let's move them 
to gerrit so we can all vote.

Echoing Kyle I would love to see us focusing on getting things ready for the 
summit.

German

-Original Message-
From: Samuel Bercovici [mailto:samu...@radware.commailto: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.commailto:mest...@noironetworks.com]
Sent: Monday, April 28, 2014 4:33 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron][LBaaS] BBG edit of new API proposal

Folks, sorry for the top post here, but I wanted to make sure to gather 
people's attention in this thread.

I'm very happy to see all the passion around LBaaS in Neutron for this cycle. 
As I've told a few people, seeing all the interest from operators and providers 
is fantastic, as it gives us valuable input from that side of things before we 
embark on designing and coding.
I've also attended the last few LBaaS IRC meetings, and I've been catching up 
on the LBaaS documents and emails. There is a lot of great work and passion by 
many people. However, the downside of what I've seen is that there is a logjam 
around progress here. Given we're two weeks out from the Summit, I'm going to 
start running the LBaaS meetings with Eugene to try and help provide some focus 
there.
Hopefully we can use this week and next week's meetings to drive to a 
consistent Summit agenda and lay the groundwork for LBaaS in Juno and beyond.

Also, while our new neutron-specs BP repository has been great so far for 
developers, based on feedback from operators, it may not be ideal for those who 
are not used to contributing using gerrit. I don't want to lose the voice of 
those people, so I'm pondering what to do. This is really affecting the LBaaS 
discussion at the moment. I'm thinking that we should ideally try to use Google 
Docs for these initial discussions and then move the result of that into a BP 
on neutron-specs. What do people think of that?

If we go down this path, we need to decide on a single Google Doc for people to 
collaborate on. I don't want to put Stephen on the spot, but his document may 
be a good starting point.

I'd like to hear what others think on this plan as well.

Thanks,
Kyle


On Sun, Apr 27, 2014 at 6:06 PM, Eugene Nikanorov 
enikano...@mirantis.commailto:enikano...@mirantis.com wrote:
 Hi,


 You knew from the action items that came out of the IRC meeting of
 April
 17 that my team would be working on an API revision proposal. You
 also knew that this proposal was to be accompanied by an object model
 diagram and glossary, in order to clear up confusion. You were in
 that meeting, you saw the action items being created. Heck, you even
 added the to prepare API for SSL and L7 directive for my team yourself!

 The implied but not stated assumption about this work was that it
 would be fairly evaluated

Re: [openstack-dev] [Neutron][LBaaS] BBG edit of new API proposal

[Eichberger, German]

Sam,

The use cases where pretty complete the last time I checked so let's move them 
to gerrit so we can all vote.

Echoing Kyle I would love to see us focusing on getting things ready for the 
summit. 

German

-Original Message-
From: Samuel Bercovici [mailto:samu...@radware.com] 
Sent: Monday, April 28, 2014 11:44 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron][LBaaS] BBG edit of new API proposal

Hi,

I was just working to push the use cases into the new format .rst but I agree 
that using google doc would be more intuitive.
Let me know what you prefer to do with the use cases document:
1. leave it at google docs at - 
https://docs.google.com/document/d/1Ewl95yxAMq2fO0Z6Dz6fL-w2FScERQXQR1-mXuSINis/edit?pli=1
2. Move it to the new format under - 
http://git.openstack.org/cgit/openstack/neutron-specs, I have already files a 
blue print https://blueprints.launchpad.net/neutron/+spec/lbaas-use-cases and 
can complete the .rst process by tomorrow.

Regards,
-Sam.






-Original Message-
From: Kyle Mestery [mailto:mest...@noironetworks.com] 
Sent: Monday, April 28, 2014 4:33 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron][LBaaS] BBG edit of new API proposal

Folks, sorry for the top post here, but I wanted to make sure to gather 
people's attention in this thread.

I'm very happy to see all the passion around LBaaS in Neutron for this cycle. 
As I've told a few people, seeing all the interest from operators and providers 
is fantastic, as it gives us valuable input from that side of things before we 
embark on designing and coding.
I've also attended the last few LBaaS IRC meetings, and I've been catching up 
on the LBaaS documents and emails. There is a lot of great work and passion by 
many people. However, the downside of what I've seen is that there is a logjam 
around progress here. Given we're two weeks out from the Summit, I'm going to 
start running the LBaaS meetings with Eugene to try and help provide some focus 
there.
Hopefully we can use this week and next week's meetings to drive to a 
consistent Summit agenda and lay the groundwork for LBaaS in Juno and beyond.

Also, while our new neutron-specs BP repository has been great so far for 
developers, based on feedback from operators, it may not be ideal for those who 
are not used to contributing using gerrit. I don't want to lose the voice of 
those people, so I'm pondering what to do. This is really affecting the LBaaS 
discussion at the moment. I'm thinking that we should ideally try to use Google 
Docs for these initial discussions and then move the result of that into a BP 
on neutron-specs. What do people think of that?

If we go down this path, we need to decide on a single Google Doc for people to 
collaborate on. I don't want to put Stephen on the spot, but his document may 
be a good starting point.

I'd like to hear what others think on this plan as well.

Thanks,
Kyle


On Sun, Apr 27, 2014 at 6:06 PM, Eugene Nikanorov enikano...@mirantis.com 
wrote:
 Hi,


 You knew from the action items that came out of the IRC meeting of 
 April
 17 that my team would be working on an API revision proposal. You 
 also knew that this proposal was to be accompanied by an object model 
 diagram and glossary, in order to clear up confusion. You were in 
 that meeting, you saw the action items being created. Heck, you even 
 added the to prepare API for SSL and L7 directive for my team yourself!

 The implied but not stated assumption about this work was that it 
 would be fairly evaluated once done, and that we would be given a short 
 window (ie.
 about a week) in which to fully prepare and state our proposal.

 Your actions, though, were apparently to produce your own version of 
 the same in blueprint form without notifying anyone in the group that 
 you were going to be doing this, let alone my team. How could you 
 have given my API proposal a fair shake prior to publishing your 
 blueprint, if both came out on the same day? (In fact, I'm lead to 
 believe that you and other Neutron LBaaS developers hadn't even 
 looked at my proposal before the meeting on 4/24, where y'all started 
 determining product direction, apparently by
 edict.)


 Therefore, looking honestly at your actions on this and trying to 
 give you the benefit of the doubt, I still must assume that you never 
 intended to seriously consider our proposal.

 That's strange to hear because the spec on review is a part of what is 
 proposed 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 

Re: [openstack-dev] [Neutron][LBaaS] SSL re-encryption scenario question

[Eichberger, German]

 are you referring to the end users X509 Certificate 
(To be rejected by the backend server)or are you referring to the back end 
servers X509Certificate which the loadbalancer would reject if it discovered 
the back end server had a bad signature or mismatched key? I am speaking of the 
case where the user wants re-encryption but wants to be able to install CA 
certificates that sign backend servers Keys via PKIX path building. I would 
even like to offer the customer the ability to skip hostname validation since 
not every one wants to expose DNS entries for IPs that are not publicly 
routable anyways. Unless your suggesting that we should force this on the user 
which likewise forces us to host a name server that maps hosts to the X509s 
subject CN fields.  Users should be free to validate back end hostnames, just 
the subject name and key or no validation at all. It should be up to them.





It's a bit of a rabbit hole, eh.
Stephen


On Fri, Apr 18, 2014 at 10:21 AM, Eichberger, German 
german.eichber...@hp.commailto:german.eichber...@hp.com wrote:
Hi Stephen,

The use case is that the Load Balancer needs to look at the HTTP requests be it 
to add an X-Forward field or change the timeout – but the network between the 
load balancer and the nodes is not completely private and the sensitive 
information needs to be again transmitted encrypted. This is admittedly an edge 
case but we had to implement a similar scheme for HP Cloud’s swift storage.

German

From: Stephen Balukoff 
[mailto:sbaluk...@bluebox.netmailto:sbaluk...@bluebox.net]
Sent: Friday, April 18, 2014 8:22 AM

To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [Neutron][LBaaS] SSL re-encryption scenario question


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

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

Thanks,
Stephen


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

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



--
Stephen Balukoff
Blue Box Group, LLC
(800)613-4305 x807tel:%28800%29613-4305%20x807
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.orgmailto:OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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



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

Re: [openstack-dev] [Neutron][LBaaS] SSL re-encryption scenario question

[Eichberger, German]

Hi Stephen,

The use case is that the Load Balancer needs to look at the HTTP requests be it 
to add an X-Forward field or change the timeout – but the network between the 
load balancer and the nodes is not completely private and the sensitive 
information needs to be again transmitted encrypted. This is admittedly an edge 
case but we had to implement a similar scheme for HP Cloud’s swift storage.

German

From: Stephen Balukoff [mailto:sbaluk...@bluebox.net]
Sent: Friday, April 18, 2014 8:22 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [Neutron][LBaaS] SSL re-encryption scenario question

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

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

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

Re: [openstack-dev] [Neutron][LBaas] Single call API discussion

[Eichberger, German]

Hi Stephen,

1. Could you please explain what you understand single-call API functionality 
to be?
From my perspective most of our users will likely create load balancers via  a 
web interface. Thought not necessary, having a single API call makes it easier 
to develop the web interface.

For the “expert” users I envision them to create a load balancer, tweak with 
the settings, and when they arrive at the load balancer they need to automate 
the creation of it. So if they have to create several objects with multiple 
calls in a particular order that is far too complicated and makes the learning 
curve very steep from the GUI to the API. Hence, I like being able to do one 
call and get a functioning load balancer. I like that aspect from Jorge’s 
proposal. On the other hand making a single API call contain all possible 
settings might make it too complex for the casual user who just wants some 
feature activated the GUI doesn’t provide….


2. Could you describe the simplest use case that uses single-call API in your 
environment right now?
Please be very specific--  ideally, a couple examples of specific CLI commands 
a user might run, or API (along with specific configuration data) would be 
great.

http://libra.readthedocs.org/en/latest/api/rest/load-balancer.html#create-a-new-load-balancer

3. Could you describe the most complicated use case that your single-call API 
supports? Again, please be very specific here.

Our API doesn’t have that many features so calls don’t get complicated.

4. What percentage of your customer base are used to using single-call 
functionality, and what percentage are used to manipulating primitives?

We only offer the single call to create a load balancer so 100% of our 
customers use it. (So this is not a good number)

5. Should single-call stuff work for the lifecycle of a load balancing 
service? That is to say, should delete functionality also clean up all 
primitives associated with the service?

Yes. If a customer doesn’t like a load balancer any longer one call will remove 
it. This makes a lot of things easier:

-  GUI development – one call does it all

-  Cleanup scripts: If a customer leaves us we just need to run delete 
on a list of load balancers – ideally if the API had a call to delete all load 
balancers of a specific user/project that would be even better ☺

-  The customer can tear down test/dev/etc. load balancer very quickly


German

From: Stephen Balukoff [mailto:sbaluk...@bluebox.net]
Sent: Thursday, April 17, 2014 12:11 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron][LBaas] Single call API discussion

Oh! One other question:

5. Should single-call stuff work for the lifecycle of a load balancing 
service? That is to say, should delete functionality also clean up all 
primitives associated with the service?

On Thu, Apr 17, 2014 at 11:44 AM, Stephen Balukoff 
sbaluk...@bluebox.netmailto:sbaluk...@bluebox.net wrote:
Hi Sri,

Yes, the meeting minutes  etc. are all available here, usually a few minutes 
after the meeting is over:  
http://eavesdrop.openstack.org/meetings/neutron_lbaas/2014/

(You are also, of course, welcome to join!)

Stephen

On Thu, Apr 17, 2014 at 11:34 AM, Sri 
sri.networ...@gmail.commailto:sri.networ...@gmail.com wrote:
hello Stephen,


I am interested in LBaaS and want to know if we post the weekly meeting's
chat transcripts online?
or may be update an etherpad?


Can you please share the links?

thanks,
SriD



--
View this message in context: 
http://openstack.10931.n7.nabble.com/Neutron-LBaas-Single-call-API-discussion-tp38533p38542.html
Sent from the Developer mailing list archive at Nabble.com.

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



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



--
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]Clarification in regards to https://docs.google.com/a/mirantis.com/spreadsheet/ccc?key=0Ar1FuMFYRhgadDVXZ25NM2NfbGtLTkR0TDFNUWJQUWc#gid=1

[Eichberger, German]

Comments inline.

German

From: Susanne Balle [mailto:sleipnir...@gmail.com]
Sent: Wednesday, April 09, 2014 2:54 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron][LBaaS]Clarification in regards to 
https://docs.google.com/a/mirantis.com/spreadsheet/ccc?key=0Ar1FuMFYRhgadDVXZ25NM2NfbGtLTkR0TDFNUWJQUWc#gid=1

See inline, Susanne

On Wed, Apr 9, 2014 at 4:49 PM, Jorge Miramontes 
jorge.miramon...@rackspace.commailto:jorge.miramon...@rackspace.com wrote:
Answers inlined. Thanks for the questions! They forced me to think about 
certain features.

Cheers,
--Jorge

From: Samuel Bercovici samu...@radware.commailto:samu...@radware.com
Reply-To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Date: Wednesday, April 9, 2014 6:10 AM
To: OpenStack Development Mailing List 
(openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org) 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Subject: [openstack-dev] [Neutron][LBaaS]Clarification in regards to 
https://docs.google.com/a/mirantis.com/spreadsheet/ccc?key=0Ar1FuMFYRhgadDVXZ25NM2NfbGtLTkR0TDFNUWJQUWc#gid=1

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?
This is a good question. In our case we supply static ip addresses so some 
users have only one backend node. With one node it isn't necessary. Another 
case I can think of is lbs that are being used for non-critical environments 
(i.e. dev or testing environment). For the most part it would make sense to 
have monitoring.

b.  Does it make sense to define the different type of monitors (ex: TCP, 
HTTP HTTPS)?
Yes it does. Http monitoring, for example, allows you to monitor specific 
URI's. I just put total utilization for all three to get some data out.

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?
I would think multiple monitors wouldn't make sense as they could potentially 
conflict. How would a decision be made in such a case?

2.   Logging Tab:

a.   What is logging use for?
This is specifically connection logging. It allows the user to see all of the 
requests that went through the load balancer. It is mostly used for big data 
and troubleshooting.

b.  How does the tenant consume the logs?
For our offering, we send their logs in a compressed format to swift. However, 
I am open to discussion on how to handle this in a more flexible manner.

[Susanne] in our case logs are forwarded to a centralized logging system e.g. 
Logstash/Elastic Search/Kibana/etc.
[German] The internal operator logs get to kibana as Susanne described. We also 
offer a way for customers to get their logs uploaded to Swift.

3.   SSL Tab:

a.   Please explain if SSL means passing SSL traffic through the load 
balancer or using the load balancer to terminate certificates.
SSL termination. I updated the tab.

b.  Does it make sense to separate those (SSL termination and non HTTPS 
terminated traffic) as different rows?
Blue Box added a few extra rows. I identified lbs that terminate only secure 
traffic and lbs that allow both secure and insecure traffic.

c.   Can anyone explain the use cases for SSL_MIXED?
A lot of web sites have mixed content. The lb terminates the secure traffic. 
The insecure traffic passes through normally.

4.   HA Tab:

a.   Is this a tenant facing option or is it the way the operator chose to 
implement the service
For us, this is operator implementation. However, since most lbs are considered 
mission critical almost all production users require HA. I could see this being 
a toggable feature from the tenant side if they wanted to use a lb for testing 
or something non mission critical.

[Susanne] Same for us. It is very important for use as service provider  that 
the LB be resilient so the user doesn't have a choice. It is resilient by 
default.

5.   Content Caching Tab:

a.   Is this a load balancer feature or a CDN like feature.
This is a lb feature. However, depending on the amount of content you'd like to 
cache using a CDN may be overkill. Here is a link that may shed some light: 
http://www.rackspace.com/knowledge_center/article/content-caching-for-cloud-load-balancers

6.   L7

a.   Does any cloud provider support L7 switching and L7 content 
modifications?
We currently do not.
[German] We currently do not have this feature though some customers have 
written small programs which simulate L7 monitoring by reporting the result on 
an arbitrary TCP port on the node. Our LB can