Re: [openstack-dev] [octavia] Nominating German Eichberger for Octavia core reviewer

+1, yes welcome back German. On Fri, 2017-01-20 at 09:41 -0800, Michael Johnson wrote: > Hello Octavia Cores, > > I would like to nominate German Eichberger (xgerman) for > reinstatement as an > Octavia core reviewer. > > German was previously a core reviewer for Octavia and neutron-lbaas > as we

Re: [openstack-dev] [neutron] proposing Miguel Lavalle as neutron core and Brian Haley as L3 Lt

+1! On Fri, 2016-12-16 at 00:14 +0100, Armando M. wrote: > Hi neutrinos, > > Miguel Lavalle has been driving the project forward consistently and > reliably. I would like to propose him to be entrusted with +2/+A > rights in the areas he's been most prolific, which are L3 and DHCP.  > > At the s

Re: [openstack-dev] [neutron] proposing Ryan Tidwell and Nate Johnston as service LTs

+1! On Fri, 2016-12-16 at 00:58 +0100, Armando M. wrote: > Hi neutrinos, > > I would like to propose Ryan and Nate as the go-to fellows for > service-related patches. > > Both are core in their repos of focus, namely neutron-dynamic-routing > and neutron-fwaas, and have a good understanding of

Re: [openstack-dev] [neutron] Proposing Abhishek Raut as neutronclient core

+1 On Wed, 2016-12-14 at 02:22 +0100, Armando M. wrote: Hi folks, Abhishek Raut's recent involvement in OSC and python-neutronclient has helped moving a few efforts along in the right direction. I would like to suggest we double down on core firepower for the neutronclient repo alongside Akihir

Re: [openstack-dev] [neutron][lbaas] New extensions for HAProxy driver based LBaaSv2

On Wed, 2016-12-07 at 06:50 -0800, Michael Johnson wrote: > Lubosz, > > I would word that very differently.  We are not dropping LBaaSv2 > support.  It is not going away.  I don't want there to be confusion > on > this point. > > We are however, moving/merging the API from neutron into Octavia. >

Re: [openstack-dev] [Neutron] Stepping down from core

Sorry to hear this Carl. You've been a great asset to openstack. Good luck to your future endeavors! Thanks, Brandon On Thu, 2016-11-17 at 11:42 -0700, Carl Baldwin wrote: > Neutron (and Openstack), > > It is with regret that I report that my work situation has changed > such that I'm not able

Re: [openstack-dev] [Neutron] Centralizing some config options will break many stadium projects

On Tue, 2016-11-01 at 13:17 +0100, Ihar Hrachyshka wrote: > Armando M. wrote: > > > > Slight variation, call it option 6: > > > > 1) Identify the most impacted (coupled) project affected by these > > changes. > > 2) Fix it in order to provide folks with a recipe for how to > > address the   > >

Re: [openstack-dev] [Neutron] Centralizing some config options will break many stadium projects

On Tue, 2016-11-01 at 13:13 +0100, Ihar Hrachyshka wrote: > Brandon Logan wrote: > > > Hello Neutrinos, > > I've come across an issue that I'd like to get input/opinions > > on.  I've > > been reviewing some of the centralize config options reviews

Re: [openstack-dev] [Neutron] Centralizing some config options will break many stadium projects

Yeah most of them are unit tests, but since the particular reviews I linked are actually moving the module they're importing, once that review merges it'll break their tests. So there would still need to be some decision made on how this is done. Doing the oslo.config attribute may make it easier

[openstack-dev] [Neutron] Centralizing some config options will break many stadium projects

Hello Neutrinos, I've come across an issue that I'd like to get input/opinions on. I've been reviewing some of the centralize config options reviews and have come across a few that would cause issues with other projects that are importing these options, especially stadium projects. High level vie

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

+1 On Mon, 2016-10-10 at 13:06 -0700, Michael Johnson wrote: > Greetings Octavia and developer mailing list folks, > > I propose that we add Lubosz Kosnik (diltram) as an OpenStack Octavia > core reviewer. > > His contributions [1] are in line with other cores and he has been an > active member

Re: [openstack-dev] [Neutron] Adding ihrachys to the neutron-drivers team

Congrats Ihar! On Sat, 2016-09-17 at 09:40 -0700, Armando M. wrote: > Hi folks, > > I would like to propose Ihar to become a member of the Neutron > drivers team [1]. > > Ihar wide knowledge of the Neutron codebase, and his longstanding > duties as stable core, downstream package whisperer, rele

Re: [openstack-dev] [neutron][api] Passing random filters on neutron API calls

On Thu, 2016-07-28 at 19:24 +0200, Ihar Hrachyshka wrote: > Kevin Benton wrote: > > > Too late. That's a backwards incompatible change that can mess with > > clients putting on cache busting nonce tokens and who knows what else. > > Ideally, API layer would at least avoid passing those unknown

Re: [openstack-dev] [octavia] ssl re-encryption in octavia

I do not believe it is in it and I don't know if anyone is working on it. I believe it has pushed down the priority stack, but someone might correct me if I'm wrong. Thanks, Brandon On Fri, 2016-07-22 at 16:00 -0700, Akshay Kumar Sanghai wrote: > Hi, > I saw in specs of kilo that ssl re-encryptio

Re: [openstack-dev] [Neutron] Proposing Jakub Libosvar for testingcore

+1 On Fri, 2016-07-22 at 09:19 -0500, Darek Śmigiel wrote: > I’m not a core, so treat this as +0 but I think Jakub will be good > addition to core team. > > > So +1 > > > On Jul 22, 2016, at 3:20 AM, Martin Hickey > > wrote: > > > > +1 > > > > Oleg Bondarev ---22/07/2016 09:13:16---+1 On Fri

Re: [openstack-dev] [neutron][linux bridge]

y need some changes in library itself in > order for full support. > It will clean up the code from neutron. But looking pybrctl code > which is just executing > Shell commands, another solution which Brandon Logan discussed is > move the existing > Code for executing those commands

Re: [openstack-dev] [octavia][upgrades] upgrade loadbalancer to new amphora image

Hi Ihar, thanks for starting this discussion. Comments in-line. After writing my comments in line, I might now realize that you're just talking about documenting a way for a user to do this, and not have Octavia handle it at all. If that's the case I apologize for my reading comprehension, but

Re: [openstack-dev] [lbaas][octavia] suggestion for today's meeting agenda: How to make the Amphora-agent support additional Linux flavors

I think we always expected other distros to be allowed, we just went with ubuntu/debian in the beginning bc most of us were comfortable with it. It would be nice to also get an image working with a micro version of "Company X" distro, if thats available. I'd gladly accept taht as the default imag

Re: [openstack-dev] [Neutron] Enabling/Disabling specific API extensions

On Tue, 2016-06-07 at 19:17 +, Sean M. Collins wrote: > The patch that switches DevStack over to using the Neutron API to > discover what features are available has landed. > > https://review.openstack.org/#/c/318145/7 > > The quick summary is that things like Q_L3_ENABLED[1] and if certain >

Re: [openstack-dev] [Neutron] Elevating context to remove subnets created by admin

To me, it seems more appropriate to delete all the subnets no matter who they're owned by if the owner of the network decided they wanted to delete it.  If there is a subnet associated with their network that they do not see, then the delete network call would have to fail.  That's going to be quit

Re: [openstack-dev] [magnum][lbaas] Operator-facing installation guide

Call me ignorance, but I'm surprised at neutron-lbaas being a dependency of magnum. Why is this? Sorry if it has been asked before and I've just missed that answer? Thanks, Brandon On Wed, 2016-06-01 at 14:39 +, Hongbin Lu wrote: > Hi lbaas team, > > > > I wonder if there is an operator-

Re: [openstack-dev] [neutron][oslo] Mitaka neutron-*aas are broken when --config-dir is passed

+1 This sounds like a sane plane. That magical config load caused me some problems in the past when I didn't know about it, would be glad to see it go. I thought it being deprecated and removed was planned anyway, and honestly didn't think it was still in the code base because I hadn't run into

Re: [openstack-dev] [neutron] DHCP Agent Scheduling for Segments

On Thu, 2016-05-19 at 14:16 -0600, Carl Baldwin wrote: > On Wed, May 18, 2016 at 1:36 PM, Kevin Benton wrote: > >>I may have wrongly assumed that segments MAY have the possibility of being > >> l2 adjacent, even if the entire network they are in is not, which would > >> mean > >> that viewing and

Re: [openstack-dev] [Neutron][ML2][Routed Networks]

On Wed, 2016-05-18 at 15:29 -0600, Carl Baldwin wrote: > On Wed, May 18, 2016 at 5:24 AM, Hong Hui Xiao wrote: > > I update [1] to auto delete dhcp port if there is no other ports. But > > after the dhcp port is deleted, the dhcp service is not usable. I can > > I think this is what I expect. >

Re: [openstack-dev] Neutron: Octavia: LBaaS: RFE created for DVR support for unbound allowed_address_pair port with FIP which are associated with multiple VMs that are active.

Thanks for putting that up, very detailed! On Thu, 2016-05-19 at 16:43 +, Vasudevan, Swaminathan (PNB Roseville) wrote: > Hi Folks, > > There has been recently a lot of requests for Neutron DVR to support > unbound allowed_address_pair port with FIP which are associated with > multiple VMs th

Re: [openstack-dev] [neutron-lbaas] Multiple back-end support for lbaas v2

What Sergey said is absolutely correct. Additionally, if a user does not provide "provider" in the request to create a load balancer than the service_provider that is tagged with the default flag will be chosen. Thanks, Brandon On Fri, 2016-05-20 at 12:23 +0300, Sergey Belous wrote: > Hi. > > >

Re: [openstack-dev] [neutron] DHCP Agent Scheduling for Segments

n just be left up to the scheduler to do that. Do you feel like it'd be beneficial to show what segment a dhcp agent is bound to in the API? I have no use case, but I wonder if operators may want that knowledge since they will be able to list segments. > > > > On Tue, May 17,

[openstack-dev] [neutron] DHCP Agent Scheduling for Segments

As part of the routed networks work [1], the DHCP agent and scheduling needs to be segment aware. Right now, the dhcpagentscheduler extension exposes API resources to manage networks: - List networks hosted by an agent - GET /agents/{agent_id}/dhcp-networks - Response Body: {"netw

Re: [openstack-dev] [neutron][stable] proposing Brian Haley for neutron-stable-maint

+1 +1 On Tue, 2016-05-17 at 18:58 +, Vasudevan, Swaminathan (PNB Roseville) wrote: > +1 for both. > > > > From: Kevin Benton [mailto:ke...@benton.pub] > Sent: Tuesday, May 17, 2016 11:06 AM > To: OpenStack Development Mailing List (not for usage questions) > > Subject: Re: [openstack-dev]

Re: [openstack-dev] [neutron][tc] Neutron stadium evolution from Austin

I have to agree with Doug. This proposal isn't saying you can't have a neutron plugin/driver, it's just that it won't be under governance of neutron. As long as the plugin and driver interfaces are there and relatively stable, you'll be able to use it. Also, if I understood correctly, you'll als

Re: [openstack-dev] [neutron] [API]Make API errors conform to the common error message without microversion

As a note, there will be a design session around the API refactor efforts going on. Microversioning will be a topic. On Tue, 2016-04-12 at 14:59 +0200, Ihar Hrachyshka wrote: > Xianshan wrote: > > > Hi, Duncan & michael, > > Thanks a lot for your replies. > > > > Definitely I agree with you tha

Re: [openstack-dev] [devstack][neutron] Eliminating the DevStack layer

On Mon, 2016-04-11 at 15:30 -0700, Kevin Benton wrote: > >[1]: > >https://github.com/openstack-dev/devstack/blob/master/lib/neutron-legacy#L178 > >[2]: > >https://github.com/openstack/nova/blob/master/nova/conf/virt.py#L164-L166 > > > This is a Nova option to decide how long to wait for Neutron

Re: [openstack-dev] [Neutron] Proposing Hirofumi Ichihara to Neutron Core Reviewer Team

+1 On Fri, 2016-04-08 at 13:04 +0300, Anna Kamyshnikova wrote: > +1 > > On Fri, Apr 8, 2016 at 12:49 PM, Miguel Angel Ajo Pelayo > wrote: > > > On Fri, Apr 8, 2016 at 11:28 AM, Ihar Hrachyshka > wrote: > Kevin Benton wrote: > >

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

+1 On Wed, 2016-03-30 at 13:56 -0700, Michael Johnson wrote: > I would like to nominate Bharath Munirajulu (bharathm) as a OpenStack > Octavia core reviewer. > His contributions [1] are in line with other cores and he has been an > active member of our community. I have been impressed with the >

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

I had the same assumption! Either way, welcome Ihar, your skills and wisdom will be a great benefit. Thanks, Brandon On Thu, 2016-03-10 at 10:33 +0100, Ihar Hrachyshka wrote: > Sean M. Collins wrote: > > > I probably speak for all FwaaS cores when I say - "Welcome!” > > …back! Thanks. > > >

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

Just for clarity, V2 did not reuse tables, all the tables it uses are only for it. The main problem is that v1 and v2 both have a pools resource, but v1 and v2's pool resource have different attributes. With the way neutron wsgi works, if both v1 and v2 are enabled, it will combine both sets of a

Re: [openstack-dev] Fwd: [Juno] LBaaS v1.0 mystery device_id

I do believe it is just an arbitrary uuid. I don't know the decision behind doing it this way, but I'm sure there were reasons. Or maybe not :) https://github.com/openstack/neutron-lbaas/blob/stable/kilo/neutron_lbaas/services/loadbalancer/drivers/common/agent_driver_base.py#L195 On Wed, 2016-

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

Adding my own input: 1. You should be able to add a specific role that the service accounts octavia will have. Then that role can be added to neutron and nova's policy.json. I have not tested this out but that is just a quick off the top of my head solution. 2. What johnsom said. Not ideal for

Re: [openstack-dev] [heat][nova][neutron] Using specific endpoints

Not sure about the heatclient, but if you use the keystone session you should be able to provide endpoint_override kwarg to any instantiation of a client that takes the session in. At least I think thats the case. Thanks, Brandon On Sat, 2016-02-06 at 22:51 +0530, pn kk wrote: > Can bypass_url i

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

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

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

+1 On Fri, 2016-02-05 at 01:07 +, Adam Harwell wrote: > +1 from me! > > From: Michael Johnson > Sent: Thursday, February 4, 2016 7:03 PM > To: OpenStack Development Mailing List (not for usage questions) > Subject: [openstack-dev] [lbaas] [octavia] Pro

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?

xtension? I'm guessing a lot of lb plugins won't be able to support it at > all. > > Thanks, > Kevin > > ____ > From: Brandon Logan [brandon.lo...@rackspace.com] > Sent: Monday, January 25, 2016 1:03 PM > To: openstack-de

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

Oh lbaas versioning was a big deal in the beginning. Versioning an advanced service is a whole other topic and exposed many "interesting" issues with the neutron extension and service plugin framework. The reason v1 and v2 cannot be run together are mainly to get over an issue we had with the 2 d

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

listeners on the same > load balancer. For example, you could host a website on ports 80 and 443 on > the same VIP and floating IP address. > > The provisioning would look like this for v2: > > * Create a load balancer > * Create a listener > * Create a pool > *

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

uration. > > > So what do y'all think of this? Am I smoking crack with how this > should work? > > > For what it's worth, I think the "member is on the other side of a > VPN" scenario is not one our customers are champing at the bit to > have,

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

ser 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 > Subject: [openstack-de

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

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

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

On Sat, 2016-01-02 at 22:23 +, Sean M. Collins wrote: > I was on Twitter and got linked to this blog post[1], and then got > linked over to Terraform's docs, and of course I went and checked out > its support for OpenStack. > > Well, what do you know? It has support for Firewall[2]! Yay! > >

Re: [openstack-dev] [Neutron][LBaaS] Regarding v2 LoadBalancer's status(es)

ure where that is being used. ... > > There is this patch to utilize the INACTIVE status: > https://review.openstack.org/#/c/255875/ > > > ________ > From: Brandon Logan > Sent: Monday, December 14, 2015 6:25 PM > To: openstack-dev

Re: [openstack-dev] [Neutron][LBaaS] Regarding v2 LoadBalancer's status(es)

Hi Bryan, On Mon, 2015-12-14 at 15:19 -0600, Bryan Jones wrote: > Hi All, > > I had a few issues/questions regarding the statuses > (provisioning_status and operating_status) of a v2 LoadBalancer. To > preface these, I am working on the LBaaS v2 support in Heat. > > The first question regards th

Re: [openstack-dev] [neutron] Release Notes for *aaS projects

Makes complete sense. On Wed, 2015-12-02 at 10:38 -0600, Kyle Mestery wrote: > We're hoping to cut Neutron M-1 this week [1]. We have implemented > release notes in the main Neutron repository [2] , but not in the *aaS > repositories. At the time, I thought this was a good approach and we > could

Re: [openstack-dev] [Neutron] Evolving the stadium concept

On Mon, 2015-11-30 at 23:11 -0500, Russell Bryant wrote: > Some additional context: there are a few proposals for additional git > repositories for Neutron that have been put on hold while we sort this out. > > Add networking-bagpipe: > https://review.openstack.org/#/c/244736/ > > Add the Astar

Re: [openstack-dev] [Horizon][Neutron] dashboard repository for neutron subprojects

Sent from Nine From: Kyle Mestery Sent: Nov 25, 2015 8:18 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Horizon][Neutron] dashboard repository for neutron subprojects On Wed, Nov 25, 2015 at 1:06 AM, Armando M. mai

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

+1 On Thu, 2015-11-19 at 17:35 +, Eichberger, German wrote: > 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

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

Oh and just to be clear, I'll still be doing work in octavia and neutron-lbaas throughout the rest of the year, but more and more focus will be diverted to other things neutron at the beginning of next year. Although, this reshifting of focus has already happened some. Thanks, Brandon On Wed, 201

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

Also, if anyone else wants to throw their hat in the ring now would be the time. Thanks, Brandon On Wed, 2015-11-18 at 23:41 +, Eichberger, German wrote: > 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 Oc

Re: [openstack-dev] [stable][infra][neutron] ZUUL_BRANCH not set for periodic stable jobs

+1 thanks for being on top of this Ihar On Mon, 2015-11-09 at 20:10 -0500, Assaf Muller wrote: > On Mon, Nov 9, 2015 at 5:30 PM, Ihar Hrachyshka wrote: > > Jeremy Stanley wrote: > > > >> On 2015-11-09 17:31:00 +0100 (+0100), Ihar Hrachyshka wrote: > >> [...] > >>> > >>> From the failure log, I d

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

Is there a lot of people requesting this meeting change? Thanks, Brandon On Fri, 2015-09-25 at 23:58 +, Eichberger, German wrote: > All, > > In our last meeting [1] we discussed moving the meeting earlier to > accommodate participants from the EMEA region. I am therefore proposing to > move

Re: [openstack-dev] [neutron][lbaas] - Heat support for LbaasV2

(I do), and I want to be able to heat stack update on > them one at a time to v2. This will replace the v1 lb > with v2, migrating the floating ip from the v1 lb to > the v2 one. This gives a smoothish upgrade path. >

Re: [openstack-dev] [neutron][lbaas] - Heat support for LbaasV2

existence (I do), and I want to be able to > > heat stack update on them one at a time to > > v2. This will replace the v1 lb with v2, > > migrating the floating ip from the v1 lb to > > the v2 one. This gives a smoothish upgrade >

Re: [openstack-dev] [neutron][lbaas] - Heat support for LbaasV2

This will replace the v1 lb > with v2, migrating the floating ip from the v1 lb to > the v2 one. This gives a smoothish upgrade path. > > Thanks, > Kevin > > From:

Re: [openstack-dev] [neutron][lbaas] - Heat support for LbaasV2

- Heat > support for > > LbaasV2 > > > > > > > > Hi Brandon, > > Work in progress, but need some input on the way we > want them, like > > replace the existing lba

Re: [openstack-dev] [neutron][lbaas] - Heat support for LbaasV2

> LbaasV2 > > > > Hi Brandon, > Work in progress, but need some input on the way we want them, like > replace the existing lbaasv1 or we still need to support them ? > > > > > > > > Thanks > Banashankar > > > > On Tue, Sep 2

Re: [openstack-dev] [neutron][lbaas] - Heat support for LbaasV2

Hi Banashankar, I think it'd be great if you got this going. One of those things we want to have and people ask for but has always gotten a lower priority due to the critical things needed. Thanks, Brandon On Mon, 2015-09-21 at 17:57 -0700, Banashankar KV wrote: > Hi All, > I was thinking of star

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

I'm off today so my +1 is more like a +2 On Sep 17, 2015 12:59 PM, Edgar Magana wrote: Not a core but I would like to share my +1 about Michael. Cheers, Edgar On 9/16/15, 3:33 PM, "Doug Wiegley" wrote: >Hi all, > >As the Lieutenant of the advanced services, I nominate Michael Johnson to b

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

Kyle, This news saddens me, but I completely understand. You've been a great PTL and I appreciate everything you have done for Neutron. Enjoy your new found free time after this. Thanks, Brandon On Fri, 2015-09-11 at 16:12 -0500, Kyle Mestery wrote: > I'm writing to let everyone know that I do n

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

Vivek, Is there a wiki or some document somewhere that explains how to get this running? Sorry if it's been posted somewhere else and I missed it. On Sun, 2015-08-30 at 18:36 +, Jain, Vivek wrote: > Hi Evgeny, > Did you add “loadbalancerv2" dir next to “loadbalancer” under > openstack_dashboa

Re: [openstack-dev] [neutron] Pecan and Liberty-3

I'm also going to be working on this and pushing one or more patches so it can load service plugins with extensions. Testing with neutron lbaas has yielded no success so far. On Fri, 2015-08-28 at 16:25 -0700, Kevin Benton wrote: > This weekend or early next week I will be pushing a couple of mo

Re: [openstack-dev] [Neutron][bgpvpn] Service Plugin vs Service driver

?So let me make sure I understand this. You want to do a separate service plugin for what would normally be separate drivers under one service plugin. The reasons for this are: 1. You dont want users the ability to choose the type, you want it always to be the same one 2. Some types do want

Re: [openstack-dev] [Neutron] neutron-lbaas code structure problem

?Hi Gareth, The reason for this is because lbaas v1 is in the services/loadbalancer/drivers path. This path was maintained from when neutron-lbaas was just another directory in the neutron repo. Once we moved to neutron-lbaas as its own repo and going forward with lbaas v2, the decision was m

Re: [openstack-dev] [neutron][lbaas] Help on single create call

One of the features we were hoping to get into Liberty for neutron-lbaas v2 was a single create call. This call would be one that would accept an entire configuration tree of loadbalancer, listeners, pools, members, and health montiors in the API and create all of it (and also rolling back corr

Re: [openstack-dev] [neutron][lbaasv2] Radware CI failure

?Evgeny/Sam/Radware, https://os-ci-logs.radware.com/179818_27_2015-07-18_10-08-37/lbaas_v2_tempest_tests.log The test_members module changed names. Should be as easy as just renaming the import. I'd also check for other module renames as well. Thanks, Brandon _

[openstack-dev] [neutron][lbaas] Radware unit test issues

python's mock library had an update yesterday that exposed some issues with unit tests that are using the mock assert calls. The radware tests were using a method called assert_called_once, which actually is not a real assert method off a mock. assert_called_once_with is, though. However, bef

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

congrats Al! On Jul 6, 2015 1:06 PM, Paul Michali wrote: Great to have you as a LBass core Al! On Mon, Jul 6, 2015 at 1:29 PM Doug Wiegley mailto:doug...@parksidesoftware.com>> wrote: Since all cores have responded, I'm going to end this early. Welcome to the core team, Al. Thanks, doug On

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

+1 for me. Phil your message did not come through. On 7/2/15, 6:32 PM, "Phillip Toohill" wrote: > > >Phillip V. Toohill III >Software Developer > >phone: 210-312-4366 >mobile: 210-440-8374 > > > >From: Eichberger, German [german.eichber...@hp.com] >Sent:

Re: [openstack-dev] [Neutron] API Extensions - Namespace URLs

I believe XML support got removed from the API last cycle. From: Jay Pipes Sent: Tuesday, June 9, 2015 1:08 PM To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Neutron] API Extensions - Namespace URLs On 06/08/2015 05:10 PM, Sean M. Coll

Re: [openstack-dev] [Neutron][LBaaS] No LBaaS agent?

For v2 there is the logging noop driver that does not use an agent and just logs. v1 sits not have this though. I do wonder why you don't just build a simple driver to do what you are currently doing when acting upon events in the notification queue. On Jun 1, 2015 7:09 PM, "Fox, Kevin M" wr

Re: [openstack-dev] [designate] and [lbaas] - GSLB API and backend support

Works for me too From: Hayes, Graham Sent: Thursday, May 28, 2015 2:49 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [designate] and [lbaas] - GSLB API and backend support That works for me. Is that

Re: [openstack-dev] [lbaas] [octavia] [barbican] Relationship between Octavia and Barbican and Octavia 1.0 questions

@lists.openstack.org Subject: Re: [openstack-dev] [lbaas] [octavia] [barbican] Relationship between Octavia and Barbican and Octavia 1.0 questions Thanks Brandon On 05/20/15 22:58, Brandon Logan wrote: ?Just to add a few things, Barbican is not yet implemented in Octavia, though the code is there, we

Re: [openstack-dev] [lbaas] [octavia] [barbican] Relationship between Octavia and Barbican and Octavia 1.0 questions

?Just to add a few things, Barbican is not yet implemented in Octavia, though the code is there, we just need to spend a few hours hooking it all up and testing it out. Also, the security groups are used by octavia right now so that only the ports on the listener are accessible. Basically if

Re: [openstack-dev] [Neutron][LBaaS] Clarification required

Hi Madhu,? You won't see any pool details from a GET of a loadbalancer. For every entity, you'll only be shown minor information from their parent (if one exists) and their children (if any exist). We may one day have a call to just show everything under a loadbalancer, but thats not there ye

Re: [openstack-dev] [octavia] Joining Neutron under the big tent

?+1 from me From: Kyle Mestery Sent: Friday, May 1, 2015 8:53 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [octavia] Joining Neutron under the big tent On Thu, Apr 30, 2015 at 5:17 PM, Eichberger, German mailto

Re: [openstack-dev] Neutron Lbaas v2 not showing operating_status as inactive

?So that is the right URL for the statuses call. As I understand the issue the statuses call is correctly changing the operating status to DISABLED correct? The problem is when you do an operationg on a loadbalancer and admin_state_up = False. In that case the body returned for those operatio

Re: [openstack-dev] [Neutron][LBaaS] Why do we need to select subnet when creating a pool?

?So someone pointed out that you were using lbaas for Juno, which would mean you aren't using LBaaS V2. So you're using V1. V1 member's do not take subnet_id as an attribute. Let me know how you are making your requests. Thanks, Brandon ____ From

Re: [openstack-dev] [Neutron][LBaaS] Why do we need to select subnet when creating a pool?

I'm assuming you are using LBaaS V2. With that assumption, I'm not sure how you are having to select subnet on the pool. It's not supposed to be a field at all on the pool object. subnet_id is required on the member object right now, but that's something I and others think should just be opti

Re: [openstack-dev] [Neutron] A big tent home for Neutron backend code

I prefer option a) as well. It does seem like most of the projects would really see no change at all other than being officially sanctioned as an Openstack project with some kind of tag. There's also the possibility the PTL may request some changes to improve the bigger picture of the Networki

Re: [openstack-dev] [neutron][lbaas] adding lbaas core

Welcome Phil! From: Doug Wiegley Sent: Tuesday, April 21, 2015 11:54 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [neutron][lbaas] adding lbaas core It’s been a week, welcome Phil. Thanks, doug > On Ap

Re: [openstack-dev] [neutron][lbaas][barbican] default certificate manager

2015 09:18 PM, Brandon Logan wrote: > Hi Ihar, I'm not against the lazy loading solution, just wondering > what the real issue is here. Is your problem with this that > python-barbicanclient needs to be in the requirements.txt? Or is > the problem that v1 will import it even

Re: [openstack-dev] [neutron][lbaas] adding lbaas core

?+1 From: Kyle Mestery Sent: Monday, April 13, 2015 3:44 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [neutron][lbaas] adding lbaas core On Mon, Apr 13, 2015 at 3:39 PM, Doug Wiegley mailto:doug...@parksidesoft

Re: [openstack-dev] [neutron][lbaas][barbican] default certificate manager

Hi Ihar, So that decision was indeed hastily done but I still think it was the right one. Let me break down the reasons: 1) To use the local cert manager, the API would have to accept the raw secrets (certificate, private key, etc). We'd have to store that some place, but it would have been e

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

That is correct. On Fri, 2015-03-20 at 15:11 +, Vijay Venkatachalam wrote: > > > +1 For on demand meeting. > > > On demand lbaas meetings will happen in neutron meeting and not in > Octavia meetings, right? > > > Sent from Surface > > > From: Susanne Balle > Sent: ‎Friday‎, ‎20‎ ‎March

Re: [openstack-dev] [Neutron] Neutron extenstions

?Isn't this argument as to whether those fields should be turned off/on, versus just always being on? Are there any guidelines as to what fields are allowed to be added in that base resource attr map? If ML2 needs these and other fields, should they just always be on? Thanks, Brandon _

Re: [openstack-dev] [neutron] [lbaas] Querries Regarding Health Monitor parameter in loadbalancer

Hi Rattenpal, Could you elaborate on this more. I haven't seen any issues with the API being able to parse "type". it's using the json standard library. Is this in regard to another json parser? thanks, brandon On Feb 19, 2015 11:24 PM, Rattenpal Amandeep wrote: Hi Team As per V2 API speci

[openstack-dev] [neutron][lbaas] Object statuses

So I am resurrecting this topic now because we put this discussion on a a brief hold, but are now discussing it again and need to decide asap. We've all agreed we need a provisioning_status and operating_status fields. We now need to decide where to show these statuses to the user. Option 1: S

Re: [openstack-dev] [neutron] Changes to the core team

Congratulations Doug! On Thu, 2015-01-22 at 11:21 -0600, Kyle Mestery wrote: > On Thu, Jan 15, 2015 at 4:31 PM, Kyle Mestery > wrote: > The last time we looked at core reviewer stats was in December > [1]. In looking at the current stats, I'm going to propose > some change

Re: [openstack-dev] [neutron][lbaas] Health Monitor association with pool

Thanks for your quick work on this Anne! On Tue, 2015-01-20 at 15:54 -0600, Anne Gentle wrote: > > > On Tue, Jan 20, 2015 at 12:49 PM, Brandon Logan > wrote: > Hmm that is for lbaas v2 docs which shouldn't be in the docs > yet because > it is n

Re: [openstack-dev] [neutron][lbaas] Pool member status 'ACTIVE' even on health check failure

> open a unix socket in haproxy cfg and restart the haproxy instance which > might not be possible in production sometimes. > > Thanks, > Varun > > > > On 1/19/15, 8:21 PM, "Brandon Logan" wrote: > > >Hi Varun, > > > >Could you tell

Re: [openstack-dev] [neutron][lbaas] Health Monitor association with pool

Hmm that is for lbaas v2 docs which shouldn't be in the docs yet because it is not ready. We will need to file a bug with the docs team to get the v1 docs back in until v2 is ready to be used (which should be relatively soon). Thanks for letting us know! Thanks, Brandon On Tue, 2015-01-20 at 12

  1   2   3   >