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

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

Re: [openstack-dev] [neutron] work on Common Flow Classifier and OVS Agent extension for Newton cycle

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

Re: [openstack-dev] [lbaas] [octavia] Proposing Bharath Munirajulu as Octavia Core

+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

Re: [openstack-dev] [Neutron] Ihar as *-aas core reviewer

+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

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

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

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

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

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

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

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

gt;> 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 f

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

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

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

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

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

Re: [openstack-dev] [lbaas][octavia] Security/networking questions

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

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

+1 From: Bertrand LALLAU > Reply-To: "OpenStack Development Mailing List (not for usage questions)" > Date: Friday, February 5, 2016 at 12:26 AM To: "OpenStack

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

lt;openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>>; Subject: Re: [openstack-dev] [neutron] - L3 flavors and issues with usecases for multiple L3 backends Choosing from multiple drivers for the same flavor is scheduling. I didn't mean automatically sel

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

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

[openstack-dev] [Neutron][LBaaS][Octavia] Using nova interface extension instead of networks extension

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

Re: [openstack-dev] [openstack-ansible] LBaaSv2 / Octavia support

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

Re: [openstack-dev] [Neutron] Versioning of the fwaas API

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

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

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 +

Re: [openstack-dev] [neutron][fwaas] No IRC meeting due to US holiday

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

Re: [openstack-dev] [neutron][fwaas]some architectural advice on fwaas driver writing

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…

Re: [openstack-dev] [lbaas] [octavia] Proposing Bertrand Lallau as Octavia Core

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

Re: [openstack-dev] [lbaas] [octavia] German + Brandon stepping down, Call for Candidates, and No Meeting 11/25

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

Re: [openstack-dev] [neutron][qos][fwaas] service groups vs. traffic classifiers

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

Re: [openstack-dev] [neutron][vpnaas] VPNaaS project status

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

Re: [openstack-dev] [neutron][qos][fwaas] service groups vs. traffic classifiers

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

Re: [openstack-dev] [neutron][stable] should we open gate for per sub-project stable-maint teams?

This seems we will get some more velocity which is good!! +1 German From: Gary Kotton > Reply-To: "OpenStack Development Mailing List (not for usage questions)" > Date:

Re: [openstack-dev] [Neutron] [Tempest] where fwaas tempest tests should be?

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

Re: [openstack-dev] [neutron][fwaas] fwaas driver development steps

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

Re: [openstack-dev] [lbaas] [octavia] Proposing new meeting time Wednesday 16:00 UTC

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

Re: [openstack-dev] [lbaas] [octavia] Proposing new meeting time Wednesday 16:00 UTC

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

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

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:

Re: [openstack-dev] [neutron] PTL Non-Candidacy

I am with Kevin — we will just write you into the ballot! Kyle, you rock! Thanks for all the support and help — and hit me up if you are short on gin :-) German From: Kevin Benton > Reply-To: "OpenStack Development Mailing List (not for usage

Re: [openstack-dev] [Neutron][horizon][neutron][L3][dvr][fwaas] FWaaS

Hi Bharath, I am wondering if you can file this as a launchpad bug, please. Thanks, German From: bharath > Reply-To: "OpenStack Development Mailing List (not for usage questions)"

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

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

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

Congratulations Brandon and Russell!! And I agree with Doug — I expect a grande venue ;-) German From: Paul Michali p...@michali.netmailto:p...@michali.net Reply-To: OpenStack Development Mailing List (not for usage questions)

Re: [openstack-dev] [neutron][lbaasv2]How to configure lbaasv2 in devstack

Please make sure to check the previous discussion about the effort Vivek is leading [1] [1] https://www.mail-archive.com/openstack-dev@lists.openstack.org/msg58328.html From: jiangshan0...@139.commailto:jiangshan0...@139.com jiangshan0...@139.commailto:jiangshan0...@139.com Reply-To:

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

. If you have any documentation for flows, please share those too. I will work with my team at ebay to publish wireframes for design we are working on. It will be mostly along the lines I demo’ed in Paris. Thanks, Vivek From: Eichberger, German german.eichber...@hp.commailto:german.eichber

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

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

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

at ebay to publish wireframes for design we are working on. It will be mostly along the lines I demo’ed in Paris. Thanks, Vivek From: Eichberger, German german.eichber...@hp.commailto:german.eichber...@hp.com Reply-To: OpenStack Development Mailing List (not for usage questions) openstack-dev

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

Al has been a great asset to LBaaS. Well deserved! +1000 German On 7/2/15, 3:16 PM, Doug Wiegley doug...@parksidesoftware.com wrote: Hi all, As the Lieutenant of the advanced services, I would like to nominate Al Miller to be a member of the neutron-lbaas core reviewer team. Review stats are

Re: [openstack-dev] [neutron] [fwaas] - Collecting use cases for API improvements - Closing 7/14

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

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

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:

Re: [openstack-dev] [nova][trove][neutron][octavia] Protected openstack resources

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

[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

[openstack-dev] [neutron][lbaas][octavia] No Octavia meeting 5/20/15

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)

[openstack-dev] [neutron][lbaas][octavia] No Octavia meeting today

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

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

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

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

[openstack-dev] [Neutron][LBaaS][Octavia] Logo for Octavia project

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

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

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

such as this == http://cbonte.github.io/haproxy-dconv/configuration-1.5.html#9. From: Eichberger, German german.eichber...@hp.commailto:german.eichber...@hp.com Reply-To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Date

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

Hi, I like 16.00 UTC. German On Nov 3, 2014 11:42 PM, Doug Wiegley do...@a10networks.com wrote: Hi LBaaS (and others), We’ve been talking about possibly re-schedulng the LBaaS meeting to a time to is less crazy early for those in the US. Alternately, we could also start alternating times.

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

working on a spec. Cheers, --Jorge P.S. Real-time stats is a different beast and I envision there being an API call that returns real-time data such as this == http://cbonte.github.io/haproxy-dconv/configuration-1.5.html#9. From: Eichberger, German german.eichber...@hp.com Reply-To: OpenStack

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

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

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

[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

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

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

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

] Question about where to render haproxy configurations Hi German, Responses in-line: On Fri, Sep 5, 2014 at 2:31 PM, Eichberger, German german.eichber...@hp.commailto:german.eichber...@hp.com wrote: Hi Stephen, I think this is a good discussion to have and will make it more clear why we chose

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

, Eichberger, German german.eichber...@hp.commailto:german.eichber...@hp.com wrote: Hi, Stephen visited us today (the joy of spending some days in Seattle☺) and we discussed that further (and sorry for using VM – not sure what won): Looks like Amphora won, so I'll start using that terminology below

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

+1 On Sep 2, 2014 12:59 PM, Kyle Mestery mest...@mestery.com wrote: On Tue, Sep 2, 2014 at 1:28 PM, Salvatore Orlando sorla...@nicira.com wrote: Inline. Salvatore On 2 September 2014 19:46, Stephen Balukoff sbaluk...@bluebox.net wrote: For what it's worth in this discussion, I agree that

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

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

Re: [openstack-dev] [Octavia] Minutes from 8/13/2014 meeting

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

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

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

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

. 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

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

that. (And yes, we commonly see deployments with listeners on port 80 and port 443 on the same virtual IP address.) Stephen On Mon, Aug 18, 2014 at 2:16 PM, Eichberger, German german.eichber...@hp.commailto:german.eichber...@hp.com wrote: Hi Steven, In my example we don’t share anything except

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

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

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

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

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

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

Re: [openstack-dev] [Neutron][LBaaS] status in entities

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

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

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

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

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

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.

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

let's resolve it separately. Thanks, Eugene. On Fri, Jul 4, 2014 at 3:07 AM, Eichberger, German german.eichber...@hp.commailto:german.eichber...@hp.com wrote: I am actually a bit bummed that Extensions are postponed. In LBaaS we are working hard on L7 and TLS extensions which we (the operators

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

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

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

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:

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

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

Re: [openstack-dev] [Neutron][LBaaS] Great Mid-cycle Sprint

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

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

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

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

, 11:43 AM, Clark, Robert Graham robert.cl...@hp.com wrote: Users have to be able to delete their secrets from Barbican, it's a fundamental key-management requirement. -Original Message- From: Eichberger, German Sent: 11 June 2014 17:43 To: OpenStack Development Mailing List

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

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

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

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

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

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

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

All, Susanne and I had a demonstration of life code by HP's Barbican team today for certificate storage. The code is submitted for review in the Barbican project. Barbican will be able to store all the certificate parts (cert, key, pwd) in a secure container. We will follow up with more

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

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

Re: [openstack-dev] [Neutron][LBaaS] Updated Object Model?

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]

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

-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

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

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)

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

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

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

and VPN On May 8, 2014, at 1:41 PM, Eichberger, German german.eichber...@hp.commailto:german.eichber...@hp.com wrote: Hi, Some of our users are not that organized and certificate expirations seem to sneak up on them. So they are looking for a single place where they can manage

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

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

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

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

Re: [openstack-dev] [Neutron][LBaaS] BBG edit of new API proposal

doing here, eh! Note also that so far these are only user use cases; It doesn't look like admin/operator use cases have been filled out at all yet. Thanks, Stephen On Mon, Apr 28, 2014 at 2:12 PM, Eichberger, German german.eichber...@hp.commailto:german.eichber...@hp.com wrote: Sam, The use

Re: [openstack-dev] [Neutron][LBaaS] BBG edit of new API proposal

...@gmail.commailto:os.v...@gmail.com wrote: Hi Sam, Evgeny, I've reviewed https://review.openstack.org/#/c/74031 with my comments. I am not sure if there is a request with code newer than this link - please do let me know if that is the case. Thanks, Regards, Vijay On Mon, Apr 28, 2014 at 2:12 PM, Eichberger

Re: [openstack-dev] [Neutron][LBaaS] BBG edit of new API proposal

Sam, The use cases where pretty complete the last time I checked so let's move them to gerrit so we can all vote. Echoing Kyle I would love to see us focusing on getting things ready for the summit. German -Original Message- From: Samuel Bercovici [mailto:samu...@radware.com] Sent:

Re: [openstack-dev] [Neutron][LBaaS] SSL re-encryption scenario question

to host a name server that maps hosts to the X509s subject CN fields. Users should be free to validate back end hostnames, just the subject name and key or no validation at all. It should be up to them. It's a bit of a rabbit hole, eh. Stephen On Fri, Apr 18, 2014 at 10:21 AM, Eichberger

Re: [openstack-dev] [Neutron][LBaaS] SSL re-encryption scenario question

Hi Stephen, The use case is that the Load Balancer needs to look at the HTTP requests be it to add an X-Forward field or change the timeout – but the network between the load balancer and the nodes is not completely private and the sensitive information needs to be again transmitted encrypted.

Re: [openstack-dev] [Neutron][LBaas] Single call API discussion

Hi Stephen, 1. Could you please explain what you understand single-call API functionality to be? From my perspective most of our users will likely create load balancers via a web interface. Thought not necessary, having a single API call makes it easier to develop the web interface. For the

Re: [openstack-dev] [Neutron][LBaaS]Clarification in regards to https://docs.google.com/a/mirantis.com/spreadsheet/ccc?key=0Ar1FuMFYRhgadDVXZ25NM2NfbGtLTkR0TDFNUWJQUWc#gid=1

Comments inline. German From: Susanne Balle [mailto:sleipnir...@gmail.com] Sent: Wednesday, April 09, 2014 2:54 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Neutron][LBaaS]Clarification in regards to