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

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

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

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

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

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" mailto:kevin@pnnl.gov>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Date: Wednesday, March 2, 2016 at 5:17 PM
To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] [Neutron][LBaaS]Removing LBaaS v1 - are weready?

no removal without an upgrade path. I've got v1 LB's and there still isn't a 
migration script to go from v1 to v2.

Thanks,
Kevin



From: Stephen Balukoff [sbaluk...@bluebox.net]
Sent: Wednesday, March 02, 2016 4:49 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron][LBaaS]Removing LBaaS v1 - are weready?

I am also on-board with removing LBaaS v1 as early as possible in the Newton 
cycle.

On Wed, Mar 2, 2016 at 9:44 AM, Samuel Bercovici 
mailto:samu...@radware.com>> wrote:
Thank you all for 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 
mailto:jpom...@linux.vnet.ibm.com>>
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 
mailto:samu...@radware.com>> wrote:

Hi,

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

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

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

-Sam.







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

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 configuration for
>:>_most_ servers. The

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: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http

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

[Eichberger, German]

+1

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

+1

On Fri, Feb 5, 2016 at 3:10 AM, Doug Wiegley 
mailto:doug...@parksidesoftware.com>> wrote:
+1

Doug


> On Feb 4, 2016, at 7:06 PM, Brandon Logan 
> mailto:brandon.lo...@rackspace.com>> wrote:
>
> +1
>
>> On Fri, 2016-02-05 at 01:07 +, Adam Harwell wrote:
>> +1 from me!
>> 
>> From: Michael Johnson mailto:johnso...@gmail.com>>
>> 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 
mailto:doug...@parksidesoftware.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Date: Tuesday, February 2, 2016 at 7:01 PM
To: "OpenStack Development Mailing List (not for usage questions)" 
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 
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" 
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";mailto:blak...@gmail.com>>;
Send time: Wednesday, Feb 3, 2016 8:55 AM
To: "OpenStack Development Mailing List (not for usage 
questions)"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" 
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 
mailto:doug...@parksidesoftware.com><mailto:doug...@parksidesoftware.com<mailto:doug...@parksidesoftware.com>>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
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)" 
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 
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 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 reschedu

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 
mailto:doug...@parksidesoftware.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Date: Monday, February 1, 2016 at 8:17 PM
To: "OpenStack Development Mailing List (not for usage questions)" 
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 
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 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 mailto:oguzyarimt...@gmail.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Date: Monday, November 23, 2015 at 5:01 AM
To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
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 
mailto:germy.l...@gmail.com>> 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 
mailto:trinath.soman...@freescale.com>> 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) 
mailto:openstack-dev@lists.openstack.org>>
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&module=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 
mailto:madhusudhan.openst...@gmail.com>>
Reply-To: OpenStack List 
mailto:openstack-dev@lists.openstack.org>>
Date: Thursday, November 12, 2015 at 7:28 AM
To: OpenStack List 
mailto:openstack-dev@lists.openstack.org>>
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 
mailto:mest...@mestery.com>> wrote:
On Thu, Nov 12, 2015 at 9:56 AM, Paul Michali 
mailto:p...@michali.net>> 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 mailto:gkot...@vmware.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Date: Wednesday, November 4, 2015 at 5:24 AM
To: OpenStack Development Mailing List 
mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] [neutron][stable] should we open gate for per 
sub-project stable-maint teams?



From: "mest...@mestery.com" 
mailto:mest...@mestery.com>>
Reply-To: OpenStack List 
mailto:openstack-dev@lists.openstack.org>>
Date: Tuesday, November 3, 2015 at 7:09 PM
To: OpenStack List 
mailto:openstack-dev@lists.openstack.org>>
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 
mailto:ihrac...@redhat.com>> 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 mailto:oguzyarimt...@gmail.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Date: Tuesday, October 13, 2015 at 7:58 AM
To: 
"openstack-dev@lists.openstack.org" 
mailto: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"  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 mailto:blak...@gmail.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Date: Friday, September 11, 2015 at 2:35 PM
To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
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 
mailto:mest...@mestery.com>> 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 mailto:bhar...@brocade.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Date: Wednesday, September 2, 2015 at 9:21 AM
To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
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 mailto:evge...@radware.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Date: Tuesday, August 25, 2015 at 9:33 AM
To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Subject: [openstack-dev] [neutron][lbaas] L7 - Tasks

Hello

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


Regards,
Evg


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

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 mailto:p...@michali.net>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Date: Sunday, August 23, 2015 at 2:04 PM
To: "OpenStack Development Mailing List (not for usage questions)" 
mailto: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 
mailto: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 
mailto: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 
mailto: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.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][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.com" 
mailto:jiangshan0...@139.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Date: Monday, July 20, 2015 at 11:06 PM
To: Yingjun Li mailto:liyingjun1...@gmail.com>>, 
"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

Thanks a lot.


jiangshan0...@139.com

From: Yingjun Li
Date: 2015-07-21 10:07
To: OpenStack Development Mailing List (not for usage 
questions)
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.com 
mailto: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: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] 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

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" mailto:vivekj...@ebay.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Date: Tuesday, July 14, 2015 at 10:22 AM
To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Cc: "Balle Balle, Susanne" mailto:susanne.ba...@hp.com>>, 
"Tonse, Milan" mailto:mto...@ebay.com>>
Subject: Re: [openstack-dev] [neutron][lbaas] Horizon support for neutron-lbaas 
v2

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

Thanks,
Vivek

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

Another option is to create a project under openstack.
designate-dashboard project takes this approach,
and the core team of the project is both horizon-core and 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 
mailto: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 
> mailto: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" 
> mailto: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" 
>> mailto:vivekj...@ebay.com><mailto:vivekj...@ebay.com<mailto:vivekj...@ebay.com>>>
>> Reply-To: "OpenStack Development Mailing List (not for usage questions)"
>> mailto:openstack-dev@lists.openstack.org><mailto:openstack-...@lists.openstack.or<mailto:openstack-...@lists.openstack.or>
>> g>>
>> Date: Wednesday, April 8, 2015 at 3:32 PM
>> To: "OpenStack Development Mailing List (not for usage questions)"
>> mailto:openstack-dev@lists.openstack.org><mailto:openstack-...@lists.openstack.or<mailto:openstack-...@lists.openstack.or>
>> g>>
>> Cc: "Balle Balle, Susanne"
>> mailto:susanne.ba...@hp.com><mailto:susanne.ba...@hp.com<mailto:susanne.ba...@hp.com>>>,
>>  "Tonse, Milan"
>> mailto:mto...@ebay.com><mailto:mto...@ebay.com<mailto: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: , German
>> mailto:german.eichber...@hp.com><mailto:german.eichber...@hp.com<mailto:german.eichber...@hp.com>>>
>> Reply-To: "OpenStack Development Mailing List (not for usage questions)&q

[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" mailto:vivekj...@ebay.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Date: Wednesday, April 8, 2015 at 3:32 PM
To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Cc: "Balle Balle, Susanne" mailto:susanne.ba...@hp.com>>, 
"Tonse, Milan" mailto:mto...@ebay.com>>
Subject: Re: [openstack-dev] [neutron][lbaas] Horizon support for neutron-lbaas 
v2

Thanks 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: , German 
mailto:german.eichber...@hp.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Date: Wednesday, April 8, 2015 at 11:24 AM
To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Cc: "Balle, Susanne" mailto: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 
mailto:phillip.tooh...@rackspace.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Date: Tuesday, April 7, 2015 at 7:50 AM
To: "OpenStack Development Mailing List (not for usage questions)" 
mailto: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 mailto: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
__
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"  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 
mailto:sameer.sat...@outlook.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Date: Thursday, May 28, 2015 at 5:30 PM
To: OpenStack Development Mailing List not for usage questions 
mailto: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.com
> To: 
> 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.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"  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

Re: [openstack-dev] [Neutron][Keystone] [Nova] How to validate teanant-id for admin operation

[Eichberger, German]

Hi Brant,

Sorry, for being confusing earlier. We have operations an 
administrator/operator is performing on behalf of a user, e.g. “Create 
Loadbalancer X for user tenant-id 123”. Now we are not checking the tenant-id 
and are wondering how to make the operation more robust with kesyone’s help.

Thanks,
German

From: Brant Knudson [mailto:b...@acm.org]
Sent: Friday, April 24, 2015 11:43 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron][Keystone] [Nova] How to validate 
teanant-id for admin operation



On Fri, Apr 24, 2015 at 11:53 AM, Eichberger, German 
mailto:german.eichber...@hp.com>> wrote:
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).

Not to long ago we got support in the auth_token middleware for a "service" 
token in addition to the user's token. The user token is sent in the 
x-auth-token header and the service token is sent in the x-service-token, and 
then fields from both tokens are available to the application (e.g., the user 
project is in HTTP_X_PROJECT_ID and the service token roles are in 
HTTP_X_SERVICE_ROLES). So you could potentially have a policy rule on the 
server for the operation that required the service token to have the 'service' 
role, and what neutron could do is send the original user token in x-auth-token 
and send its own token as the service token. This seems to be what you're 
asking for here.

- Brant

Thanks,
German

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe<http://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][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 
mailto:phillip.tooh...@rackspace.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Date: Tuesday, April 7, 2015 at 7:50 AM
To: "OpenStack Development Mailing List (not for usage questions)" 
mailto: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 mailto: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] Shared Objects in LBaaS - Use Cases that led us to adopt this.

[Eichberger, German]

Hi Brandon + Stephen,

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

German

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

Hi Brandon,

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

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

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

Stephen



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

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

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

lb1
lb2
listener1
listener2
pool1
pool2
member1
member2

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

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

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

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

Thanks,
Brandon

On Thu, 2014-11-27 at 08:52 +, Samuel Bercovici wrote:
> Brandon, can you please explain further (1) bellow?
>
> -Original Message-
> From: Brandon Logan 
> [mailto:brandon.lo...@rackspace.com]
> Sent: Tuesday, November 25, 2014 12:23 AM
> To: 
> openstack-dev@lists.openstack.org
> Subject: Re: [openstack-dev] [neutron][lbaas] Shared Objects in LBaaS - Use 
> Cases that led us to adopt this.
>
> My impression is that the statuses of each entity will be shown on a detailed 
> info request of a loadbalancer.  The root level objects would not have any 
> statuses.  For example a user makes a GET request to /loadbalancers/{lb_id} 
> and the status of every child of that load balancer is show in a 
> "status_tree" json object.  For example:
>
> {"name": "loadbalancer1",
>  "status_tree":
>   {"listeners":
> [{"name": "listener1", "operating_status": "ACTIVE",
>   "default_pool":
> {"name": "pool1", "status": "ACTIVE",
>  "members":
>[{"ip_address": "10.0.0.1", "status": "OFFLINE"}]}}
>
> Sam, correct me if I am wrong.
>
> I generally like this idea.  I do have a few reservations with this:
>
> 1) Creating and updating a load balancer requires a full tree configuration 
> with the current extension/plugin logic in neutron.  Since updates will 
> require a full tree, it means the user would have to know the full tree 
> configuration just to simply update a name.  Solving this would require 
> nested child resources in the URL, which the current neutron extension/plugin 
> does not allow.  Maybe the new one will.
>
> 2) The status_

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  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 am still not convinced that we need to use logging for usage metrics. We can 
also use the haproxy stats interface (which the haproxy team is willing to 
improve based on our input) and/or iptables as Stephen suggested. That said 
this probably needs more exploration.

>From an HP perspective the full logs on the load balancer are mostly 
>interesting for the user of the loadbalancer - we only care about aggregates 
>for our metering. That said we would be happy to just move them on demand to a 
>place the user can access.

Thanks,
German


From: Jorge Miramontes [mailto:jorge.miramon...@rackspace.com]
Sent: Tuesday, November 04, 2014 8:20 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron][LBaaS][Octavia] Usage Requirements

Hi Susanne,

Thanks for the reply. As Angus pointed out, the one big item that needs to be 
addressed with this method is network I/O of raw logs. One idea to mitigate 
this concern is to store the data locally for the operator-configured 
granularity, process it and THEN send it to cielometer, etc. If we can't 
engineer a way to deal with the high network I/O that will inevitably occur we 
may have to move towards a polling approach. Thoughts?

Cheers,
--Jorge

From: Susanne Balle mailto:sleipnir...@gmail.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Date: Tuesday, November 4, 2014 11:10 AM
To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] [Neutron][LBaaS][Octavia] Usage Requirements

Jorge

I understand your use cases around capturing of metrics, etc.

Today we mine the logs for usage information on our Hadoop cluster. In the 
future we'll capture all the metrics via ceilometer.

IMHO the amphorae should have an interface that allow for the logs to be moved 
to various backends such as an elastic search, hadoop HDFS, Swift, etc as well 
as by default (but with the option to disable it) ceilometer. Ceilometer is the 
metering defacto for OpenStack so we need to support it. We would like the 
integration with Ceilometer to be based on Notifications. I believe German send 
a reference to that in another email. The pre-processing will need to be 
optional and the amount of data aggregation configurable.

What you describe below to me is usage gathering/metering. The billing is 
independent since companies with private clouds might not want to bill but 
still need usage reports for capacity planning etc. Billing/Charging is just 
putting a monetary value on the various form of usage,

I agree with all points.

> - 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 the logs": This is what we would use log forwarding to either Swift or 
Elastic Search, etc.

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

It looks like we are in agreement so I am not sure why it sounded like we were 
in disagreement on the IRC. I am not sure why but it sounded like you were 
talking about something else when you were talking about the real time 
processing. If we are just taking about moving the logs to your Hadoop cluster 
or any backedn a scalable way we agree.

Susanne


On Thu, Oct 23, 2014 at 6:30 PM, Jorge Miramontes 
mailto:jorge.miramon...@rackspace.com>> wrote:
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

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:  , German 
Reply-To:  "OpenStack Development Mailing List (not for usage questions)"

Date:  Wednesday, October 22, 2014 2:41 PM
To:  "OpenStack Development Mailing List (not for usage questions)"

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, October 22, 2014 6:51 AM
>To: OpenStack Development Mailing List (not f

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 mailto:sbaluk...@bluebox.net>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Date: Wednesday, October 22, 2014 4:04 AM
To: "OpenStack Development Mailing List (not for usage questions)" 
mailto: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 
mailto: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 issues. Auditing will
also be easier with raw logs.

4) Enabling logs for all load balancers will help mitigat

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 
mailto: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. it

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 
mailto: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 ca

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

[Eichberger, German]

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

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

2.   If we render configuration files on the VM we only support one upgrade 
model (replacing the VM) which might simplify development as opposed to the 
driver model where we need to write code to push out configuration changes to 
all VMs for minor changes + write code to failover VMs for major changes

3.   I am afraid that half baked drivers will break the controller and I 
feel it’s easier to shoot VMs with half baked renderers  than the controllers.

4.   The main advantage by using an Octavia format to talk to VMs is that 
we can mix and match VMs with different properties (e.g. nginx, haproxy) on the 
same controller because the implementation detail (which file to render) is 
hidden

5.   The major difference in The API between Stephen and me would be that I 
would send json files which get rendered on the VM into a haproxy file whereas 
he would send an haproxy file. We still need to develop an interface on the VM 
to report stats and health in Octavia format. It is conceivable with Stephen’s 
design that drivers would exist which would translate stats and health from a 
proprietary format into the Octavia one. I am not sure how we would get the 
proprietary VMs to emit the UDP health packets… In any case a lot of logic 
could end up in a driver – and fanning that processing out to the VMs might 
allow for less controllers.

Overall, if I don’t like to take advantage of the minor update model the main 
difference between me and Stephen is in the haproxy case to ship json instead 
of haproxy config. I understand that the minor update capability is a make or 
break for Stephen though in my experience configuration changes without other 
updates are rare (and my experience might not be representative).

In any case there certainly is some advantage for appliances which not 
necessarily speak the Octavia protocol by allowing custom drivers. However, 
given our plan to use an Ocatvia UDP package to emit health messages from the 
VMs to the controller and since controller provision VMs in Nova it might be a 
better integration point for appliances to have custom controllers. I am just 
not convinced that a custom driver is sufficient for all cases –

German


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

Hello!

At today's Octavia meeting, one of the questions briefly discussed was where, 
in the Octavia architecture, haproxy configuration files should be rendered. 
This discussion went long and we decided to take it to the mailing list for 
more thorough discussion and to gather alternate ideas.

Anyway, the two main ideas are to render the configuration in the back-end 
(haproxy) driver, and push complete configs out to the VMs/containers running 
the haproxy software via API, or to use the back-end API to push out 
configuration updates and have the VMs/containers render them themselves.

I'm in favor of rendering haproxy configs in the driver, and will present 
arguments in favor of this architecture. I understand German @ HP is the main 
proponent of rendering the configs on the back-end VMs/containers and will let 
him speak to his own points there, and respond to mine below.

Why we should render haproxy configurations within the driver:


  *   This is analogous to how other back-end drivers for proprietary virtual 
machines will do it. This means our reference implementation is easier used as 
a model for 3rd party vendors who want to use Octavia for managing their own 
appliance images.
  *   This keeps the back-end API simpler, as the back-end Octavia VM / 
container doesn't need to know anything about how to render a configuration, it 
just needs to know how to run it.
  *   Simpler back-end API means fewer failure scenarios to have to plan for. 
Either the config pushed out works or it doesn't.
  *   Minor bugfixes, configuration-related security fixes, and minor feature 
improvements can be done centrally without having to update potentially 10's of 
thousands of back-end VMs/containers. (The alternative is to have to do this 
for even the smallest of updates using the other model.)
  *   Major bugfixes and changes will still need to touch all back-end 
VMs/containers, but this is no different than the other model.
  *   If an operator wants to deliver service using another set of load 
balancing software (eg. 

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

[Eichberger, German]

+1

On Sep 2, 2014 12:59 PM, Kyle Mestery  wrote:
On Tue, Sep 2, 2014 at 1:28 PM, Salvatore Orlando  wrote:
> Inline.
> Salvatore
>
> On 2 September 2014 19:46, Stephen Balukoff  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
>>  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 
>>> > 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 migh

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

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 
mailto: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.net<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 
mailto: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.com<mailto:brandon.lo...@rackspace.com>]
> Sent: Sunday, August 17, 2014 8:57 PM
> To: 
> openstack-dev@lists.openstack.org<mailto: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
> > mailto: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

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 
mailto: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.com<mailto:brandon.lo...@rackspace.com>]
> Sent: Sunday, August 17, 2014 8:57 PM
> To: 
> openstack-dev@lists.openstack.org<mailto: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
> > mailto: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 

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

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

[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] 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 
mailto: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
> mailto: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.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" 
> mailto:samu...@radware.com>>
> wrote:
>
> >Hi Doug,
> >
> >In some implementations Driver !== Device. I think this is
> also true
> >for HA Proxy.
> >T

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 - SubjectAlternativeNames (SAN)

[Eichberger, German]

It's also worth pointing out that some UIs will definitely want to show SAN 
>> information and the like, so either having this available as part of the 
>> API, or as a standard library we write which then gets used by multiple 
>> drivers is going to be necessary.
>> 
>> If we're extracting the Subject Common Name in any place in the code then we 
>> also need to be extracting the Subject Alternative Names at the same place. 
>> From the perspective of the SNI standard, there's no difference in how these 
>> fields should be treated, and if we were to treat SANs differently then 
>> we're both breaking the standard and setting a bad precedent.
>> 
>> Stephen
>> 
>> 
>> On Tue, Jul 15, 2014 at 9:35 AM, Carlos Garza  
>> wrote:
>> 
>> On Jul 15, 2014, at 10:55 AM, Samuel Bercovici 
>> wrote:
>> 
>>> Hi,
>>> 
>>> 
>>> Obtaining the domain name from the x509 is probably more of a 
>>> driver/backend/device capability, it would make sense to have a library 
>>> that could be used by anyone wishing to do so in their driver code.
>> 
>>You can do what ever you want in *your* driver. The code to extract this 
>> information will be apart of the API and needs to be mentioned in the spec 
>> now. PyOpenSSL with PyASN1 are the most likely candidates.
>> 
>> Carlos D. Garza
>>> 
>>> -Sam.
>>> 
>>> 
>>> 
>>> From: Eichberger, German [mailto:german.eichber...@hp.com]
>>> Sent: Tuesday, July 15, 2014 6:43 PM
>>> To: OpenStack Development Mailing List (not for usage questions)
>>> Subject: Re: [openstack-dev] [Neutron][LBaaS] TLS capability - SNI - 
>>> Extracting SubjectCommonName and/or SubjectAlternativeNames from 
>>> X509
>>> 
>>> Hi,
>>> 
>>> My impression was that the frontend would extract the names and hand them 
>>> to the driver.  This has the following advantages:
>>> 
>>> * We can be sure all drivers can extract the same names
>>> * No duplicate code to maintain
>>> * If we ever allow the user to specify the names on UI rather in 
>>> the certificate the driver doesn't need to change.
>>> 
>>> I think I saw Adam say something similar in a comment to the code.
>>> 
>>> Thanks,
>>> German
>>> 
>>> From: Evgeny Fedoruk [mailto:evge...@radware.com]
>>> Sent: Tuesday, July 15, 2014 7:24 AM
>>> To: OpenStack Development Mailing List (not for usage questions)
>>> Subject: [openstack-dev] [Neutron][LBaaS] TLS capability - SNI - 
>>> Extracting SubjectCommonName and/or SubjectAlternativeNames from 
>>> X509
>>> 
>>> Hi All,
>>> 
>>> Since this issue came up from TLS capabilities RST doc review, I opened a 
>>> ML thread for it to make the decision.
>>> Currently, the document says:
>>> 
>>> "
>>> For SNI functionality, tenant will supply list of TLS containers in 
>>> specific Order.
>>> In case when specific back-end is not able to support SNI 
>>> capabilities, its driver should throw an exception. The exception 
>>> message should state that this specific back-end (provider) does not 
>>> support SNI capability.
>>> The clear sign of listener's requirement for SNI capability is a 
>>> none empty SNI container ids list.
>>> However, reference implementation must support SNI capability.
>>> 
>>> Specific back-end code may retrieve SubjectCommonName and/or 
>>> altSubjectNames from the certificate which will determine the 
>>> hostname(s) the certificate is associated with.
>>> 
>>> The order of SNI containers list may be used by specific back-end 
>>> code, like Radware's, for specifying priorities among certificates.
>>> In case when two or more uploaded certificates are valid for the 
>>> same DNS name and the tenant has specific requirements around which 
>>> one wins this collision, certificate ordering provides a mechanism 
>>> to define which cert wins in the event of a collision.
>>> Employing the order of certificates list is not a common requirement 
>>> for all back-end implementations.
>>> "
>>> 
>>> The question is about SCN and SAN extraction from X509.
>>> 1.   Extraction of SCN/ SAN should be done while provisioning and not 
>>> during TLS handshake
>>> 2.   Every back-end code/driver must(?) extract SCN and(?) SAN and use 
>>> it for certificate determination for host
>>> 
>>> Please give your feedback
>>> 
>>> Thanks,
>>> Evg
>>> ___
>>> OpenStack-dev mailing list
>>> OpenStack-dev@lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> 
>> 
>> ___
>> OpenStack-dev mailing list
>> OpenStack-dev@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> 
>> 
>> 
>> --
>> Stephen Balukoff
>> Blue Box Group, LLC
>> (800)613-4305 x807
>> ___
>> OpenStack-dev mailing list
>> OpenStack-dev@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 


___
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 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 
mailto: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 independent load bala

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 
mailto: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.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: 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 
mailto: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.com<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 
mailto: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 
> mailto:sleipnir...@gmail.com>> wrote:
>>
>> +1
>>
>>
>> On Wed, Jul 2, 2014 at 10:12 PM, Kyle Mestery
>> mailto: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

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  
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  wrote:
>>
>> +1
>>
>>
>> On Wed, Jul 2, 2014 at 10:12 PM, Kyle Mestery 
>> 
>> 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] 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" 
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"  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][LBaaS] Agenda for weekly IRC meeting

[Eichberger, German]

Hi,

Please take the time to fill out the weekly standup info: 
https://etherpad.openstack.org/p/neutron-lbaas-weekly-standup

Thanks,
German

From: Jorge Miramontes [mailto:jorge.miramon...@rackspace.com]
Sent: Wednesday, July 02, 2014 1:20 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [Neutron][LBaaS] Agenda for weekly IRC meeting

Hey LBaaS folks!

Please send me any agenda items you would like discussed tomorrow so I can 
organize the meeting. And as usual, please update the weekly standup etherpad. 
Everything should be organized on the main wiki page now ==> 
https://wiki.openstack.org/wiki/Neutron/LBaaS :)

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

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

[Eichberger, German]

Hi,

I second Stephen's suggestion with the status matrix. I have heard of 
(provisional) status, operational status, admin status -- I am curious what 
states exists and how an object would transition between them. 

Libra uses only one status field and it transitions as follows:

BUILDING -> ACTIVE|ERROR
ACTIVE -> DEGARDED|ERROR|DELETED
DEGRADED -> ACTIVE|ERROR|DELETED
ERROR -> DELETED

That said I don't think admin status is that important for me as an operator 
since my user's usually delete lbs and re-create them. But I am curious how 
other operators feel.

Thanks,
German

-Original Message-
From: Brandon Logan [mailto:brandon.lo...@rackspace.com] 
Sent: Tuesday, June 24, 2014 8:46 PM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [Neutron][LBaaS] Which entities need status

Alright y'all have convinced me for now.  How the status is show on shared 
entities is still yet to be determined.  However, we don't have any shared 
entities (unless we really want health monitors shareable right now) at this 
point so the status won't get complicated for this first iteration. 

Thanks,
Brandon

On Wed, 2014-06-25 at 01:10 +, Doug Wiegley wrote:
> Hi Stephen,
> 
> 
> > Ultimately, as we will have several objects which have many-to-many
> relationships with other objects, the 'status' of an object that is 
> shared between what will ultimately be two separate physical entities 
> on the back-end should be represented by a dictionary, and any 
> 'reduction' of this on behalf of the user should happen within the UI.
> It does make things more complex to deal with in certain kinds of 
> failure scenarios, but we don't help ourselves at all by trying to 
> hide, say, when a member of a pool referenced by one listener is 'UP'
> and the same member of the same pool referenced by a different 
> listener is 'DOWN'.  :/
> 
> 
> For M:N, that’s actually an additional status field that rightly 
> belongs as another column in the join table, if at all (allow me to 
> queue up all of my normal M:N objections here in this case, I’m just 
> talking normal db representation.)  The bare object itself still has 
> status of its own.
> 
> 
> Doug
> 
> 
> 
> 
> 
> 
> From: Stephen Balukoff 
> Reply-To: "OpenStack Development Mailing List (not for usage 
> questions)" 
> Date: Tuesday, June 24, 2014 at 6:02 PM
> To: "OpenStack Development Mailing List (not for usage questions)"
> 
> Subject: Re: [openstack-dev] [Neutron][LBaaS] Which entities need 
> status
> 
> 
> 
> Ultimately, as we will have several objects which have many-to-many 
> relationships with other objects, the 'status' of an object that is 
> shared between what will ultimately be two separate physical entities 
> on the back-end should be represented by a dictionary, and any 
> 'reduction' of this on behalf of the user should happen within the UI.
> It does make things more complex to deal with in certain kinds of 
> failure scenarios, but we don't help ourselves at all by trying to 
> hide, say, when a member of a pool referenced by one listener is 'UP'
> and the same member of the same pool referenced by a different 
> listener is 'DOWN'.  :/
> 
> 
> Granted, our version 1 implementation of these objects is going to be 
> simplified, but it doesn't hurt to think about where we're headed with 
> this API and object model.
> 
> 
> I think it would be worthwhile for someone to produce a status matrix 
> showing which kinds of status are available for each object type, and 
> what the possible values of those statuses are, and what they mean.
> Given the question of what 'status' means is very complicated indeed, 
> I think this is the only way we're going to actually make forward 
> progress in this discussion.
> 
> 
> Stephen
> 
> 
> 
> 
> On Tue, Jun 24, 2014 at 4:02 PM, Dustin Lundquist 
>  wrote:
> I think there is significant value in having status on the
> listener object even in the case of HAProxy. While HAProxy can
> support multiple listeners in a single process, there is no
> reason it needs to be deployed that way. Additionally in the
> case of updating a configuration with an additional listener,
> the other listeners and the load balancer object are not in an
> unavailable or down state before the configuration is applied,
> only the new listener object is down or building. In the case
> of the HAProxy namespace driver, one could map the namespace
> creation and HAProxy process to the load balancer object
> status, but each listener can have its own status based on the
> availability of members in its pools. 
> 
> 
> For the initial version of our new object model we be
> pragmatic and minimize complexity and change, we can preform a
> reduction across all listeners to generate an overall load
> balancer status.
> 
> 
> 
> 
> -Dustin
>  

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

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

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

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

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

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 
mailto: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 listene

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]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 
 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 mailto:enikano...@mirantis.com>>
Reply-To: 
"openstack-dev@lists.openstack.org" 
mailto:openstack-dev@lists.openstack.org>>
Date: Thursday, May 15, 2014 at 9:55 AM
To: 
"openstack-dev@lists.openstack.org" 
mailto: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 
mailto: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.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.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 
mailto: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" 
mailto:sleipnir...@gmail.com><mailto:sleipnir...@gmail.com<mailto: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

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]

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

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

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

-Rob

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


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

Hi John,

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

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

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

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

-Rob

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


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

Hi John,

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

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





-Sam.



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

Hello Samuel,

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

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 
mailto:jorge.miramon...@rackspace.com>> wrote:
That sounds good to me. The only thing I would caution is that we have 
prioritized certain requirements (like HA and SSL Termination) and I want to 
ensure we use the survey to compliment what we have already mutually agreed 
upon. Thanks for spearheading this!

Cheers,
--Jorge

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

Hi Everyone!

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

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

Please let me know if this is acceptable.

Regards,
-Sam.




___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
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 
mailto: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" 
mailto: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 g

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 
mailto: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 
mailto:german.eichber...@hp.com>> wrote:
Sam,

The use cases where pretty complete the last time I checked so let's move them 
to gerrit so we can all vote.

Echoing Kyle I would love to see us focusing on getting things ready for the 
summit.

German

-Original Message-
From: Samuel Bercovici [mailto:samu...@radware.com<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<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 
mailto: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 

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 
mailto:german.eichber...@hp.com>> wrote:
Sam,

The use cases where pretty complete the last time I checked so let's move them 
to gerrit so we can all vote.

Echoing Kyle I would love to see us focusing on getting things ready for the 
summit.

German

-Original Message-
From: Samuel Bercovici [mailto:samu...@radware.com<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<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