Re: [openstack-dev] [neutron-lbaas][octavia]Octavia request poll interval not respected

Hi Mihaela, The polling logic that the neutron-lbaas octavia driver uses to update the neutron database is as follows: Once a Create/Update/Delete action is executed against a load balancer using the Octavia driver a polling thread is created. On every request_poll_interval the thread queries the

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

iling List (not for usage questions)" Date: Tuesday, January 3, 2017 at 3:37 AM To: "OpenStack Development Mailing List (not for usage questions)" Subject: Re: [openstack-dev] [neutron-lbaas][octavia] I would like to emphasize the importance of this issue. Currently, all te LBa

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

I would like to emphasize the importance of this issue. Currently, all te LBaaS/Octavia gates are up on running (touch wood). Nevertheless, this bug will become more apparent (aka broken gates) in the next release of tempest (if we don't merge this fix beforehand). The reason is that the issue oc

Re: [openstack-dev] [neutron-lbaas][octavia] Error when creating load balancer

Based on this logs. I can tell you that problem is with plugging VIP address. You need to show us also n-cpu logs. There should be some info what happened because we can see in logs in line 22 that client failed with error 500 on attaching network adapter. Maybe you’re out of IP’s in this subnet

Re: [openstack-dev] [neutron-lbaas] [octavia]vip failed to be plugged in to the amphorae vm

questions)" Subject: Re: [openstack-dev] [neutron-lbaas] [octavia]vip failed to be plugged in to the amphorae vm Plugging VIP worked without any problems. Log is telling that you have very restrictive timeout configuration. 7 retries is very low configuration. Please reconfigure this to much

Re: [openstack-dev] [neutron-lbaas] [octavia]vip failed to be plugged in to the amphorae vm

Plugging VIP worked without any problems. Log is telling that you have very restrictive timeout configuration. 7 retries is very low configuration. Please reconfigure this to much bigger value. Regards, Lubosz Kosnik Cloud Software Engineer OSIC lubosz.kos...@intel.com

Re: [openstack-dev] [neutron-lbaas][octavia] About running Neutron LBaaS

Hi, Micheal, Thanks a lot for your help. I am trying your solution. Best regards, Yipei On Sun, Nov 20, 2016 at 1:46 PM, Yipei Niu wrote: > Hi, Micheal, > > Thanks a lot for your comments. > > Please find the errors of o-cw.log in link http://paste.openstack. > org/show/589806/

Re: [openstack-dev] [neutron-lbaas][octavia] About running Neutron LBaaS

Hi Yipei, That error means the controller worker process was not able to reach the amphora REST API. I am guessing this is the issue with diskimage-builder which we have patches up for, but not all of them have merged yet [1][2]. Try running my script: https://gist.github.com/michjohn/a7cd582fc1

Re: [openstack-dev] [neutron-lbaas][octavia] About running Neutron LBaaS

Hi, Micheal, Thanks a lot for your comments. Please find the errors of o-cw.log in link http://paste.openstack.org/ show/589806/ . Hope it will help. About the lb-mgmt-net, I just follow the guide of running LBaaS. If I create a ordinary subnet with neutr

Re: [openstack-dev] [neutron-lbaas][octavia] About playing Neutron LBaaS

Hi Yipei, A note, that you probably want to use the tags [neutron-lbaas] and [octavia] instead of [tricicle] to catch the LBaaS team attention. Since you are using the octavia driver, can you please include a link to your o-cw.log? This will tell us why the load balancer create failed. Also, I

Re: [openstack-dev] [neutron] [lbaas] [octavia] Ocata LBaaS retrospective and next steps recap

k.org>> Date: Wednesday, November 9, 2016 at 11:43 PM To: OpenStack List mailto:openstack-dev@lists.openstack.org>> Subject: Re: [openstack-dev] [neutron] [lbaas] [octavia] Ocata LBaaS retrospective and next steps recap The people working on the migration are ensuring API compatibility and are

Re: [openstack-dev] [neutron] [lbaas] [octavia] Ocata LBaaS retrospective and next steps recap

t this and I feel that it will cause > production problems. > > > > From: Kevin Benton > Reply-To: OpenStack List > Date: Wednesday, November 9, 2016 at 11:43 PM > To: OpenStack List > > > Subject: Re: [openstack-dev] [neutron] [lbaas] [octavia] Ocata LBa

Re: [openstack-dev] [neutron] [lbaas] [octavia] Ocata LBaaS retrospective and next steps recap

From: Armando M. [arma...@gmail.com<mailto:arma...@gmail.com>] Sent: Wednesday, November 09, 2016 8:05 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [neutron] [lbaas] [octavia] Ocata LBaaS retrospective and next steps recap On 9 November 2016 at 05:

Re: [openstack-dev] [neutron] [lbaas] [octavia] Ocata LBaaS retrospective and next steps recap

..@gmail.com] > Sent: Wednesday, November 09, 2016 8:05 AM > To: OpenStack Development Mailing List (not for usage questions) > Subject: Re: [openstack-dev] [neutron] [lbaas] [octavia] Ocata LBaaS > retrospective and next steps recap > > > > On 9 November 2016 at 05:50, Gary K

Re: [openstack-dev] [neutron] [lbaas] [octavia] Ocata LBaaS retrospective and next steps recap

Ok. cool. thanks. :) Kevin From: Kevin Benton [ke...@benton.pub] Sent: Wednesday, November 09, 2016 1:43 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [neutron] [lbaas] [octavia] Ocata LBaaS retrospective and

Re: [openstack-dev] [neutron] [lbaas] [octavia] Ocata LBaaS retrospective and next steps recap

8:05 AM > *To:* OpenStack Development Mailing List (not for usage questions) > *Subject:* Re: [openstack-dev] [neutron] [lbaas] [octavia] Ocata LBaaS > retrospective and next steps recap > > > > On 9 November 2016 at 05:50, Gary Kotton wrote: > >> Hi, >> What about

Re: [openstack-dev] [neutron] [lbaas] [octavia] Ocata LBaaS retrospective and next steps recap

iling List (not for usage questions) Subject: Re: [openstack-dev] [neutron] [lbaas] [octavia] Ocata LBaaS retrospective and next steps recap On 9 November 2016 at 05:50, Gary Kotton mailto:gkot...@vmware.com>> wrote: Hi, What about neutron-lbaas project? Is this project still alive and k

Re: [openstack-dev] [neutron] [lbaas] [octavia] Ocata LBaaS retrospective and next steps recap

Hi Gary, Our intent is to merge neutron-lbaas into the Octavia project. When this is complete, the neutron-lbaas project will remain for some time as a light weight shim/proxy that provides the legacy neutron endpoint experience. The database models are already very similar to the existing neutr

Re: [openstack-dev] [neutron] [lbaas] [octavia] Ocata LBaaS retrospective and next steps recap

On 9 November 2016 at 05:50, Gary Kotton wrote: > Hi, > What about neutron-lbaas project? Is this project still alive and kicking > to the merge is done or are we going to continue to maintain it? I feel > like we are between a rock and a hard place here. LBaaS is in production > and it is not cl

Re: [openstack-dev] [neutron] [lbaas] [octavia] Ocata LBaaS retrospective and next steps recap

Hi, What about neutron-lbaas project? Is this project still alive and kicking to the merge is done or are we going to continue to maintain it? I feel like we are between a rock and a hard place here. LBaaS is in production and it is not clear the migration process. Will Octavia have the same DB

Re: [openstack-dev] [neutron] [lbaas] [octavia] Ocata LBaaS retrospective and next steps recap

thanks very much for the update! Cheers, Lingxian Kong (Larry) On Tue, Nov 8, 2016 at 12:36 PM, Michael Johnson wrote: > Ocata LBaaS retrospective and next steps recap > -- > > This session lightly touched on the work in the n

Re: [openstack-dev] [Neutron][LBaaS][Octavia]In amphora plugin_vip(), why cidr and gateway are required but not used?

Thank you the info Lubosz. On Fri, Jun 17, 2016 at 5:01 PM, Kosnik, Lubosz wrote: > Here is a bug for that - https://bugs.launchpad.net/octavia/+bug/1585804 > You’re more than welcome to fix this issue. > > Lubosz Kosnik > Cloud Software Engineer OSIC > lubosz.kos...@intel.com > > On Jun 17, 201

Re: [openstack-dev] [Neutron][LBaaS][Octavia]In amphora plugin_vip(), why cidr and gateway are required but not used?

Here is a bug for that - https://bugs.launchpad.net/octavia/+bug/1585804 You’re more than welcome to fix this issue. Lubosz Kosnik Cloud Software Engineer OSIC lubosz.kos...@intel.com On Jun 17, 2016, at 6:37 PM, Jiahao Liang mailto:jiahao.li...@oneconvergence.com

Re: [openstack-dev] [Neutron][LBaaS][Octavia][Docs] Need experienced contributor documentation best-practices and how-tos

On 3 March 2016 at 18:35, Stephen Balukoff wrote: > Hi Armando, > > Please rest assured that I really am a fan of requiring. I realize that > sarcasm doesn't translate to text, so you'll have to trust me when I say > that I am not being sarcastic by saying that. > > However, I am not a fan of bei

Re: [openstack-dev] [Neutron][LBaaS][Octavia][Docs] Need experienced contributor documentation best-practices and how-tos

Hi Armando, Please rest assured that I really am a fan of requiring. I realize that sarcasm doesn't translate to text, so you'll have to trust me when I say that I am not being sarcastic by saying that. However, I am not a fan of being given nebulous requirements and then being accused of lazines

Re: [openstack-dev] [Neutron][LBaaS][Octavia][Docs] Need experienced contributor documentation best-practices and how-tos

On 3 March 2016 at 16:56, Stephen Balukoff wrote: > Hello! > > I have a problem I'm hoping someone can help with: I have gone through the > task of completing a shiny new feature for an openstack project, and now > I'm trying to figure out how to get that last all-important documentation > step d

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

Yeah our public cloud does not support that call. We actually have a different endpoint that is almost just like the os-interfaces one! Except the openstack nova client doesn't know about it, of course. If for the time being we can temporarily support the os-networks way as a fall back method if

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

epted though. -Original Message- From: Brandon Logan [mailto:brandon.lo...@rackspace.com] Sent: Thursday, January 28, 2016 6:49 AM To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Neutron][LBaaS][Octavia] Should subnet be optional on member create? I could see it

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

outside the local cloud. The assumption, then, would be > > that this IP address > > > >> should be reachable through standard routing from > > wherever the load balancer > > > >> happens to live on the network. That is to

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

PM To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Neutron][LBaaS][Octavia] Should subnet be optional on member create? Any additional thoughts and opinions people want to share on this. I don't have a horse in this race as long as we don't make dangerous assumptions ab

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

hen > > >> > > >> On Mon, Jan 18, 2016 at 11:14 AM, Jain, Vivek > wrote: > > >>> > > >>> If member port (IP address) is allocated by neutron, > then why do we need > > >>> to spec

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

> them per node at all. > > -Sam. > > > -Original Message- > From: Samuel Bercovici [mailto:samu...@radware.com] > Sent: Sunday, January 17, 2016 10:14 AM > To: OpenStack Development Mailing List (not for usage questions) > Subject: Re: [openstack-dev] [Neut

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

>>> > > >>> If member port (IP address) is allocated by neutron, then why do we > need > > >>> to specify it explicitly? It can be derived by LBaaS driver > implicitly. > > >>> > > >>> Thanks, > > >>> Vivek > >

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

plicitly. > >>> > >>> Thanks, > >>> Vivek > >>> > >>> > >>> > >>> > >>> > >>> > >>> On 1/17/16, 1:05 AM, "Samuel Bercovici" wrote: > >>> > >

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

t; >>> Thanks, >>> Vivek >>> >>> >>> >>> >>> >>> >>> On 1/17/16, 1:05 AM, "Samuel Bercovici" wrote: >>> >>>> Btw. >>>> >>>> I am still in favor on associating the su

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

vici" wrote: >> >> >Btw. >> > >> >I am still in favor on associating the subnets to the LB and then not >> > specify them per node at all. >> > >> >-Sam. >> > >> > >> >-Original Message- >&g

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

wrote: > > >Btw. > > > >I am still in favor on associating the subnets to the LB and then not > specify them per node at all. > > > >-Sam. > > > > > >-Original Message- > >From: Samuel Bercovici [mailto:samu...@radware.com]

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

the LB and then not specify >them per node at all. > >-Sam. > > >-Original Message- >From: Samuel Bercovici [mailto:samu...@radware.com] >Sent: Sunday, January 17, 2016 10:14 AM >To: OpenStack Development Mailing List (not for usage questions) >Subject: Re: [opens

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

questions) Subject: Re: [openstack-dev] [Neutron][LBaaS][Octavia] Should subnet be optional on member create? +1 Subnet should be mandatory The only thing this makes supporting load balancing servers which are not running in the cloud more challenging to support. But I do not see this as a huge user

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

+1 Subnet should be mandatory The only thing this makes supporting load balancing servers which are not running in the cloud more challenging to support. But I do not see this as a huge user story (lb in cloud load balancing IPs outside the cloud) -Sam. -Original Message- From: Brandon

Re: [openstack-dev] [neutron][lbaas][octavia] what are the main differences between the two

You’re definitely stuck on lbaas v1 until you upgrade to Kilo, but… But, it would be possible to write an lbaasv1 driver for octavia, though octavia likely won’t be mature enough to be useful for that until the end of Liberty or so. Also, though “vendor” is a bad word in openstack (and that’s o

Re: [openstack-dev] [neutron][lbaas][octavia] what are the main differences between the two

Thanks a bunch Doug, very clear & helpful info. so with that said those who run IceHouse or Juno are (more or less :) ) dead in the water as the only option is v1 ...hmm Dani On Mon, May 4, 2015 at 10:21 PM, Doug Wiegley wrote: > lbaas v1: > > This is the original Neutron LBaaS, and what you s

Re: [openstack-dev] [neutron][lbaas][octavia] what are the main differences between the two

lbaas v1: This is the original Neutron LBaaS, and what you see in Horizon or in the neutron CLI as “lb-*”. It has an haproxy backend, and a few vendors supporting it. Feature-wise, it’s basically a byte pump. lbaas v2: This is the “new” Neutron LBaaS, and is in the neutron CLI as “lbaas-*” (i

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

I have a couple proposals done up on paper that I'll have available shortly, I'll reply with a link. - Trevor J. Vardeman - trevor.varde...@rackspace.com - (210) 312 - 4606 On 4/14/15, 5:34 PM, "Eichberger, German" wrote: >All, > >Let's decide on a logo tomorrow so we can print stickers i

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

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

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

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 Requiremen

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

e 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

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

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 Requi

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

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

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

On Tue, 28 Oct 2014 04:42:27 PM Jorge Miramontes wrote: > Thanks for the reply Angus, > > DDoS attacks are definitely a concern we are trying to address here. My > assumptions are based on a solution that is engineered for this type of > thing. Are you more concerned with network I/O during a DoS

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

Thanks for the reply Angus, DDoS attacks are definitely a concern we are trying to address here. My assumptions are based on a solution that is engineered for this type of thing. Are you more concerned with network I/O during a DoS attack or storing the logs? Under the idea I had, I wanted to make

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

On Wed, 22 Oct 2014 11:29:27 AM Robert van Leeuwen wrote: > > 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

Re: [openstack-dev] [Neutron][LBaaS][Octavia] Octavia's API becoming spun out LBaaS

Hi Jay, Just so you have some information on the API before the meeting here is the spec for it: https://review.openstack.org/#/c/122338/ I'm sure there is a lot of details that might be missing but it should give you a decent idea. Sorry for the markup/markdown being dumb if you try to build wi

Re: [openstack-dev] [Neutron][LBaaS][Octavia] Octavia's API becoming spun out LBaaS

Yup, can do! :) -jay On 10/27/2014 01:55 PM, Doug Wiegley wrote: Hi Jay, Let’s add that as an agenda item at our Weekly IRC meeting. Can you make this timeslot? https://wiki.openstack.org/wiki/Octavia#Meetings Thanks, Doug On 10/27/14, 11:27 AM, "Jay Pipes" wrote: Sorry for top-postin

Re: [openstack-dev] [Neutron][LBaaS][Octavia] Octavia's API becoming spun out LBaaS

Hi Jay, Let’s add that as an agenda item at our Weekly IRC meeting. Can you make this timeslot? https://wiki.openstack.org/wiki/Octavia#Meetings Thanks, Doug On 10/27/14, 11:27 AM, "Jay Pipes" wrote: >Sorry for top-posting, but where can the API working group see the >proposed Octavia API

Re: [openstack-dev] [Neutron][LBaaS][Octavia] Octavia's API becoming spun out LBaaS

Sorry for top-posting, but where can the API working group see the proposed Octavia API specification or documentation? I'd love it if the API WG could be involved in reviewing the public REST API. Best, -jay On 10/27/2014 10:01 AM, Kyle Mestery wrote: On Sun, Oct 26, 2014 at 8:01 PM, Doug Wi

Re: [openstack-dev] [Neutron][LBaaS][Octavia] Octavia's API becoming spun out LBaaS

Got it. So we will be discussing this in the 2PM meeting today. Correct? Regards, Mandeep On Mon, Oct 27, 2014 at 10:02 AM, Kyle Mestery wrote: > On Mon, Oct 27, 2014 at 11:48 AM, Mandeep Dhami > wrote: > > Hi Kyle: > > > > Are you scheduling an on-demand meeting, or are you proposing that the

Re: [openstack-dev] [Neutron][LBaaS][Octavia] Octavia's API becoming spun out LBaaS

On Mon, Oct 27, 2014 at 11:48 AM, Mandeep Dhami wrote: > Hi Kyle: > > Are you scheduling an on-demand meeting, or are you proposing that the > agenda for next neutron meeting include this as an on-demand item? > Per my email to the list recently [1], the weekly rotating Neutron meeting is now an o

Re: [openstack-dev] [Neutron][LBaaS][Octavia] Octavia's API becoming spun out LBaaS

Hi Kyle: Are you scheduling an on-demand meeting, or are you proposing that the agenda for next neutron meeting include this as an on-demand item? Regards, Mandeep On Mon, Oct 27, 2014 at 6:56 AM, Kyle Mestery wrote: > On Mon, Oct 27, 2014 at 12:15 AM, Sumit Naiksatam > wrote: > > Several pe

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

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

Re: [openstack-dev] [Neutron][LBaaS][Octavia] Octavia's API becoming spun out LBaaS

On Sun, Oct 26, 2014 at 8:01 PM, Doug Wiegley wrote: > Hi Brandon, > >> 4. I brought this up now so that we can decide whether we want to >> discuss it at the advanced services spin out session. I don't see the >> harm in opinions being discussed before the summit, during the summit, >> and more

Re: [openstack-dev] [Neutron][LBaaS][Octavia] Octavia's API becoming spun out LBaaS

On Mon, Oct 27, 2014 at 12:15 AM, Sumit Naiksatam wrote: > Several people have been requesting that we resume the Advanced > Services' meetings [1] to discuss some of the topics being mentioned > in this thread. Perhaps it might help people to have a focussed > discussion on the topic of "advanced

Re: [openstack-dev] [Neutron][LBaaS][Octavia] Octavia's API becoming spun out LBaaS

Several people have been requesting that we resume the Advanced Services' meetings [1] to discuss some of the topics being mentioned in this thread. Perhaps it might help people to have a focussed discussion on the topic of "advanced services' spin-out" prior to the design summit session [2] in Par

Re: [openstack-dev] [Neutron][LBaaS][Octavia] Octavia's API becoming spun out LBaaS

Hi Doug: On 10/26/14, 6:01 PM, "Doug Wiegley" wrote: >Hi Brandon, > >> 4. I brought this up now so that we can decide whether we want to >> discuss it at the advanced services spin out session. I don't see the >> harm in opinions being discussed before the summit, during the summit, >> and more

Re: [openstack-dev] [Neutron][LBaaS][Octavia] Octavia's API becoming spun out LBaaS

Hi Brandon, > 4. I brought this up now so that we can decide whether we want to > discuss it at the advanced services spin out session. I don't see the > harm in opinions being discussed before the summit, during the summit, > and more thoroughly after the summit. I agree with this sentiment. I

Re: [openstack-dev] [Neutron][LBaaS][Octavia] Octavia's API becoming spun out LBaaS

Good questions Doug. My answers are as follows: 1. Yes 2. Some time after Kilo (same as I don't know when) 3. The main reason a spin out makes sense from Neutron is that the scope for Neutron is too large for the attention advances services needs from the Neutron Core. If all of advanced service

Re: [openstack-dev] [Neutron][LBaaS][Octavia] Octavia's API becoming spun out LBaaS

Hi all, Before we get into the details of which API goes where, I’d like to see us answer the questions of: 1. Are we spinning out? 2. When? 3. With or without the rest of advanced services? 4. Do we want to wait until we (the royal “we” of “the Neutron team”) have had the Paris summit discussion

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

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 cla

Re: [openstack-dev] [Neutron][LBaaS][Octavia] Octavia's API becoming spun out LBaaS

+1 to this, eh! Though it sounds more like you're talking about spinning the Octavia user API out of Octavia to become it's own thing (ie. "Openstack LBaaS"), and then ensuring a standardized driver interface that vendors (including Octavia) will interface with. It's sort of a half-dozen of one, s

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

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

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

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

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

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 prop

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

> 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: Just request from the operator side of things: Plea

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

Re: [openstack-dev] [Neutron][LBaaS][Octavia] Floating IP management

to:vijay.venkatacha...@citrix.com>> Reply-To: "OpenStack Development Mailing List (not for usage questions)" mailto:openstack-dev@lists.openstack.org>> Date: Wednesday, October 15, 2014 9:38 AM To: "OpenStack Development Mailing List (not for usage questions)" mailto:o

Re: [openstack-dev] [Neutron][LBaaS][Octavia] Floating IP management

ning, LB appliance is now the "owner" of the FLIP and will be responding to ARPs. Thanks, Vijay V. From: Phillip Toohill [mailto:phillip.tooh...@rackspace.com] Sent: 15 October 2014 23:16 To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Neutr

Re: [openstack-dev] [Neutron][LBaaS][Octavia] Floating IP management

usage questions)" mailto:openstack-dev@lists.openstack.org>> Date: Wednesday, October 15, 2014 9:38 AM To: "OpenStack Development Mailing List (not for usage questions)" mailto:openstack-dev@lists.openstack.org>> Subject: Re: [openstack-dev] [Neutron][LBaaS][Octavia] Floating IP manageme

Re: [openstack-dev] [Neutron][LBaaS][Octavia] Floating IP management

st (not for usage questions)" mailto:openstack-dev@lists.openstack.org>> Subject: Re: [openstack-dev] [Neutron][LBaaS][Octavia] Floating IP management Hi Phillip, Adding my thoughts below. I’ll first answer the questions you raised with what I think should be done, and then give my explanations to

Re: [openstack-dev] [Neutron][LBaaS][Octavia] Floating IP management

Venkatachalam [mailto:vijay.venkatacha...@citrix.com] Sent: 15 October 2014 05:38 To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Neutron][LBaaS][Octavia] Floating IP management Thanks for the doc. The floating IP could be hosted directly by the lb backend/lb

Re: [openstack-dev] [Neutron][LBaaS][Octavia] Floating IP management

Hi Phillip, Adding my thoughts below. I’ll first answer the questions you raised with what I think should be done, and then give my explanations to reason through with those views. 1. Do we want to add logic in the plugin to call the FLIP association API? >> We should implement the logic in

Re: [openstack-dev] [Neutron][LBaaS][Octavia] Floating IP management

: [openstack-dev] [Neutron][LBaaS][Octavia] Floating IP management Nice diagrams. :-) Thanks. Susanne On Mon, Oct 13, 2014 at 4:18 PM, Phillip Toohill mailto:phillip.tooh...@rackspace.com>> wrote: Diagrams in jpeg format.. On 10/12/14 10:06 PM, "Phillip Toohill" mai

Re: [openstack-dev] [Neutron][LBaaS][Octavia] Floating IP management

Nice diagrams. :-) Thanks. Susanne On Mon, Oct 13, 2014 at 4:18 PM, Phillip Toohill < phillip.tooh...@rackspace.com> wrote: > Diagrams in jpeg format.. > > On 10/12/14 10:06 PM, "Phillip Toohill" > wrote: > > >Hello all, > > > >Heres some additional diagrams and docs. Not incredibly detailed, bu

Re: [openstack-dev] [Neutron][LBaaS][Octavia] Floating IP management

Hello all, Heres some additional diagrams and docs. Not incredibly detailed, but should get the point across. Feel free to edit if needed. Once we come to some kind of agreement and understanding I can rewrite these more to be thorough and get them in a more official place. Also, I understand t

Re: [openstack-dev] [Neutron][LBaaS][Octavia] Floating IP management

I'll add some more info to this as well: Neutron LBaaS creates the neutron port for the VIP in the plugin layer before drivers ever have any control. In the case of an async driver, it will then call the driver's create method, and then return to the user the vip info. This means the user will k

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

I am not for this if Octavia is merged into the incubator when LBaaS V2 is, assuming LBaaS V2 will be merged into it before the summit. I'd rather Octavia get merged into whatever repository it is destined to whenever it is much more mature. If Octavia is merged into the incubator too soon, I thi

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

Hi Kyle, IMO, that depends entirely on how the incubator project is run. For now, I'm in favor of remaining separate and letting someone else be the guinea pig. :/ I think we'll (all) be more productive this way. Also keep in mind that the LBaaS v2 code is mostly there (just waiting on reviews),

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

me other >>> > backend? Sure, though I’m not sure I’d see the point. >>> > There are quite a few synergies with other efforts, and we’re >>> > monitoring them, but not waiting for any of them. >>> > >>> > &

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

Sure, though I’m not sure I’d see the point. >>> > There are quite a few synergies with other efforts, and we’re >>> > monitoring them, but not waiting for any of them. >>> > >>> > >>> > And I agree with Brandon’

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

doug > > > > > From: Salvatore Orlando > > Reply-To: "OpenStack Development Mailing List (not for usage > questions)" > > Date: Tuesday, September 2, 2014 at 9:05 AM >

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

ribe octavia’s > backends. Feel free to chime in > here: https://review.openstack.org/#/c/117701/ > > > Thanks, > doug > > > > > From: Salvatore Orlando > Reply-To: "OpenStack Development Mailing List (not for usage > questions)" >

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

Orlando > > Reply-To: "OpenStack Development Mailing List (not for usage questions)" < > openstack-dev@lists.openstack.org> > Date: Tuesday, September 2, 2014 at 9:05 AM > > To: "OpenStack Development Mailing List (not for usage questions)" < > opens

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

your related points: >>> >> >>> >> >>> >> [Susanne] To me Octavia is a driver so it is very hard to me >>> >> to think of it as a standalone project. It needs the new >>> >> Neutron LBaaS v2 to function whi

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

ilar to the way the A10 > > driver is a separate bit of code from the A10 appliance. To do > > that though, we need Octavia to be fairly close to fully > > functional. I believe we can do this because even though the > > ref

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

ersation, and I have noticed that quite >> >> a few people are having the same issue differentiating. In a >> >> small group, having quite a few people not on the same page is >> >> a bit scary, so maybe we need to really sit d

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

Octavia being the refenece implementation for OpenStack LBaaS > >> (whatever that is). Has that changed while I was on vacation? > >> > >> > >> [Adam] I believe that having the Octavia "driver" (not the > >>

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

imilar to the way the A10 >> driver is a separate bit of code from the A10 appliance. To do >> that though, we need Octavia to be fairly close to fully >> functional. I believe we can do this because even though the >> reference driver would then r

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

+1 -Original Message- From: Brandon Logan [mailto:brandon.lo...@rackspace.com] Sent: Tuesday, September 02, 2014 8:13 AM To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [neutron][lbaas][octavia] Hi Susanne and everyone, My opinions are that keeping it in stackforge

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

n) available as part of OpenStack core. > > > --Adam > > > https://keybase.io/rm_you > > > > > From: Susanne Ba

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

nne Balle > Reply-To: "OpenStack Development Mailing List (not for usage questions)" < > openstack-dev@lists.openstack.org> > Date: Friday, August 29, 2014 9:19 AM > To: "OpenStack Development Mailing List (not for usa

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

ist (not for usage questions)" mailto:openstack-dev@lists.openstack.org>> Subject: Re: [openstack-dev] [neutron][lbaas][octavia] Stephen See inline comments. Susanne - Susanne-- I think you are conflating the difference between "OpenStac

  1   2   >