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

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

Hello, I have the following setup: Neutron - Newton version Octavia - Ocata version Neutron LBaaS had the following configuration in services_lbaas.conf: [octavia] .. # Interval in seconds to poll octavia when an entity is created, updated, or # deleted. (integer value)

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

t;OpenStack Development Mailing List (not for usage questions)" <openstack-dev@lists.openstack.org> Date: Tuesday, January 3, 2017 at 3:37 AM To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev@lists.openstack.org> Subject: Re: [openstack-

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

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

When running neutron_lbaas scenarios tests with the latest tempest version we fail because of https://bugs.launchpad.net/octavia/+bug/1649083. I would like if anyone can go over the patch that fixes the problem and merge it, so our automation will succeed. The patch is

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

9:16 PM To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev@lists.openstack.org> Subject: [openstack-dev] [neutron-lbaas][octavia] Error when creating load balancer Hi, All, I failed creating a load balancer on a subnet. The detailed info o

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

Hi, All, I failed creating a load balancer on a subnet. The detailed info of o-cw.log is pasted in the link http://paste.openstack.org/show/593492/. Look forward to your valuable comments. Thank you. Best regards, Yipei __

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

ot;OpenStack Development Mailing List (not for usage questions)" <openstack-dev@lists.openstack.org> 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 restricti

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

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

I have stable/metaka Octavia which has been running OK until today, whenever I created loadbalancer, the amphorae vm is created with mgmt nic. But look like vip plugin failed. I can ping to amphorae mgmt. NIC from controller(where Octavia process is running), but look like some rest api call

[openstack-dev] [neutron-lbaas][octavia] New time proposal for weekly meeting

Hi, As some project members are based outside of the US, I’d like to propose time change for the weekly meeting, which will more friendly to non-US based members. Please post your preferences/info in the etherpad below. https://etherpad.openstack.org/p/octavia-weekly-meeting-time

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

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:

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

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

ack List <openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>> Date: Wednesday, November 9, 2016 at 11:43 PM To: OpenStack List <openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>> Subject: Re: [openstack-dev] [neutron] [lbaa

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

lt;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 > even leaving in a shim on the

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

, November 9, 2016 at 11:43 PM To: OpenStack List <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 even leaving in a shim o

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

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

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

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

, 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 Kotton <gkot...@vmware.com> wrote: > &

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

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 <gkot...@vmware.com<mailto:gkot...@vmware.com>> wrote: Hi, What about neutron-lbaas project? Is this project s

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

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

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

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

Ocata LBaaS retrospective and next steps recap -- This session lightly touched on the work in the newton cycle, but primarily focused on planning for the Ocata release and the LBaaS spin out of neutron and merge into the octavia

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 >

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

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

Added more related topics to the original email. -- Forwarded message -- From: Jiahao Liang (Frankie) Date: Fri, Jun 17, 2016 at 4:30 PM Subject: [openstack-dev][Octavia]In amphora plugin_vip(), why cidr and gateway are required but not used? To:

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

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

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

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

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 done so that people will know about this new feature and use

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

[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] [Neutron][LBaaS][Octavia] Should subnet be optional on member create?

; > > >> to get to such an IP address via its default gateway, > > unless it has a more > > > >> specific route. > > > >> > > > >> As far as I'm aware, this use case is still valid and > >

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?

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

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

> >> On Mon, Jan 18, 2016 at 11:14 AM, Jain, Vivek > <vivekj...@ebay.com> wrote: > > >>> > > >>> If member port (IP address) is allocated by neutron, > then why do we need > > >>>

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

@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 about what the user wants. So I

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

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

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

On 1/17/16, 1:05 AM, "Samuel Bercovici" <samu...@radware.com> wrote: >> >> >Btw. >> > >> >I am still in favor on associating the subnets to the LB and then not >> > specify them per node at all. >> > >> >-Sam. >>

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

can be derived by LBaaS driver implicitly. > >>> > >>> Thanks, > >>> Vivek > >>> > >>> > >>> > >>> > >>> > >>> > >>> On 1/17/16, 1:05 AM, "Samuel Bercovici" <

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

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

>But I do not see this as a huge user story (lb in cloud load balancing IPs >outside the cloud) > >-Sam. > >-Original Message- >From: Brandon Logan [mailto:brandon.lo...@rackspace.com] >Sent: Saturday, January 16, 2016 6:56 AM >To: openstack-dev@lists.openstack.org

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

[mailto:samu...@radware.com] > >Sent: Sunday, January 17, 2016 10:14 AM > >To: OpenStack Development Mailing List (not for usage questions) > >Subject: Re: [openstack-dev] [Neutron][LBaaS][Octavia] Should subnet be > optional on member create? > > > >+1 > >Su

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?

: Brandon Logan [mailto:brandon.lo...@rackspace.com] Sent: Saturday, January 16, 2016 6:56 AM To: openstack-dev@lists.openstack.org Subject: [openstack-dev] [Neutron][LBaaS][Octavia] Should subnet be optional on member create? I filed a bug [1] a while ago that subnet_id should be an optional parameter

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

I filed a bug [1] a while ago that subnet_id should be an optional parameter for member creation. Currently it is required. Review [2] is makes it optional. The original thinking was that if the load balancer is ever connected to that same subnet, be it by another member on that subnet or the

[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

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

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 doug...@parksidesoftware.com wrote: lbaas v1: This is the original

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

Hi all, I'm trying to gather more info about the differences between Neutron LBaaS v1 Neutron LBaaS v2 Octavia I know Octavia is still not marked production but on the other hand i keep hearing inside my organization that Neutron LBaaS is missing few critical pieces so i'd very much appreciate

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

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 german.eichber...@hp.com wrote: All, Let's decide on a logo tomorrow so we

[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][Octavia] Usage Requirements

: [openstack-dev] [Neutron][LBaaS][Octavia] Usage Requirements 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

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

[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

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

@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Neutron][LBaaS][Octavia] Usage Requirements 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

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

, October 22, 2014 2:41 PM To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Neutron][LBaaS][Octavia] Usage Requirements Hi Jorge, Good discussion so far + glad to have you back J I am not a big fan of using logs

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

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] Octavia's API becoming spun out LBaaS

On Mon, Oct 27, 2014 at 12:15 AM, Sumit Naiksatam sumitnaiksa...@gmail.com 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

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

On Sun, Oct 26, 2014 at 8:01 PM, Doug Wiegley do...@a10networks.com 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

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

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

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 mest...@mestery.com wrote: On Mon, Oct 27, 2014 at 12:15 AM, Sumit Naiksatam

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

On Mon, Oct 27, 2014 at 11:48 AM, Mandeep Dhami dh...@noironetworks.com 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

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 jaypi...@gmail.com wrote: Sorry for top-posting, but where can the API working group see the

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 jaypi...@gmail.com wrote:

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

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

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

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

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

Hi Doug: On 10/26/14, 6:01 PM, Doug Wiegley do...@a10networks.com 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,

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

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

With the recent talk about advanced services spinning out of Neutron, and the fact most of the LBaaS community has wanted LBaaS to spin out of Neutron, I wanted to bring up a possibility and gauge interest and opinion on this possibility. Octavia is going to (and has) an API. The current

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,

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

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

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

Mailing List (not for usage questions) openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Neutron][LBaaS][Octavia] Usage Requirements Hi Jorge, Good discussion so far + glad to have you back J I am not a big fan of using logs for billing information since ultimately (at least

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

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

:04 AM To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Neutron][LBaaS][Octavia] Usage Requirements Hi Jorge! Welcome back, eh! You've been missed. Anyway, I just wanted to say

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

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

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

driver. Thanks, Vjay From: Vijay 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

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

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] [Neutron][LBaaS][Octavia

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

@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Neutron][LBaaS][Octavia] Floating IP management I'm unsure the meaning of hosting FLIP directly on the LB. There can be LB appliances (usually physical appliance) that sit at the edge and is connected to receive

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

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

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 phillip.tooh...@rackspace.com wrote: Hello all, Heres some additional diagrams and docs. Not

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 phillip.tooh...@rackspace.commailto:phillip.tooh...@rackspace.com wrote: Diagrams in jpeg format.. On 10/12/14 10:06 PM, Phillip Toohill

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

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

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

Hello All, I wanted to start a discussion on floating IP management and ultimately decide how the LBaaS group wants to handle the association. There is a need to utilize floating IPs(FLIP) and its API calls to associate a FLIP to the neutron port that we currently spin up. See DOCS here:

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]

questions) openstack-dev@lists.openstack.org Date: Friday, August 29, 2014 9:19 AM To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [neutron][lbaas][octavia

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

questions) openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [neutron][lbaas][octavia] Stephen See inline comments. Susanne

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

@lists.openstack.org Subject: Re: [openstack-dev] [neutron][lbaas][octavia] Stephen See inline comments. Susanne - Susanne

  1   2   >