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

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

ds some serious discussion. > 4. Yes. > > Thanks, > doug > > On 10/24/14, 3:47 PM, "Brandon Logan" wrote: > > >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

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

ive manner, instead of leveraging other work. And > >>>> there > >>>> are specific reasons for that. But, maybe we can at least take steps > >>>> to > >>>> not be incompatible about it. Or maybe there is a hierarchy of > >>>>

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

Any but the 1400 utc On Nov 4, 2014 8:48 AM, Doug Wiegley wrote: Hi LBaaS (and others), We’ve been talking about possibly re-schedulng the LBaaS meeting to a time to is less crazy early for those in the US. Alternately, we could also start alternating times. For now, let’s see if we can find a

Re: [openstack-dev] [neutron][lbaas] meeting day/time change

https://wiki.openstack.org/wiki/Meetings#LBaaS_meeting That is updated for lbaas and advanced services with the new times. Thanks, Brandon On Mon, 2014-11-10 at 11:07 +, Doug Wiegley wrote: > #openstack-meeting-4 > > > > On Nov 10, 2014, at 10:33 AM, Evgeny Fedoruk wrote: > > > > Thanks,

Re: [openstack-dev] [neutron] Reminder: No meeting this week

Congrats! Another little mestery in the world, scary! On Mon, 2014-11-10 at 12:22 -0600, Kyle Mestery wrote: > Since most folks are either freshly back from traveling, in the midst > of returning, or perhaps even with a new baby, we'll be skipping this > week's meeting. We'll resume next week at o

Re: [openstack-dev] [neutron][advanced services] Weekly IRC meeting day/time change

I think those of us who could attend were probably hoping to not get stagnant, but really its a waiting game at this point so wouldn't be much to talk about without everyone attending. Plus, I'm sure the TC hasn't had time to discuss this much less a decision. So you're probably right, but I c

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

Greetings all, I'd like to thank everyone who attended the LBaaS mid-cyle sprint for taking the time and effort to make the trip to San Antonio. This was a very productive sprint in all forms: direction, consensus, blueprints, documentation, and of course code. It was just great to be able to get

Re: [openstack-dev] [Octavia] PTL and core team members

I'm thinking we are going to need more than 2 on the core team at first but it is hard to tell exactly how many people will be contributing code at first. I know we've got a lot of interested parties and the possibility that some 10+ people are actively contributing. Of course, these things can o

Re: [openstack-dev] Should TLS settings for listener be set through separate API/model?

Vijay, I think the separate entity is still going to happen. I don't think it has remvoed. Or that is may just be my assumption. Thanks, Brandon On Mon, 2014-06-23 at 15:59 +, Vijay Venkatachalam wrote: > Hi: > > > In the “LBaaS TLS termination capability specification” proposal > > h

Re: [openstack-dev] Should TLS settings for listener be set through separate API/model?

#x27;t that already the case in many other > objects (not just in the Neutron LBaaS sub project)? > > > Thanks, > Stephen > > > > > > > On Mon, Jun 23, 2014 at 9:54 AM, Brandon Logan > wrote: > Vijay, > I think the separate entity is

Re: [openstack-dev] [Neutron][LBaaS] Should TLS settings for listener be set through separate API/model?

Whoops, [Neutron][LBaaS] got taken out of the subject line here. Putting it back in. On Mon, 2014-06-23 at 21:10 +, Brandon Logan wrote: > Okay so we've talked a bit about this in IRC and now I'm sending this > out as an update. Here are the options with pros and cons that

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

I think we missed this discussion at the meet-up but I'd like to bring it up here. To me having a status on all entities doesn't make much sense, and justing having a status on a load balancer (which would be a provisioning status) and a status on a member (which would be an operational status) ar

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

d the complexities that could arise from decisions made now. Perhaps it is the wrong way to look at it to some, but I don't think thinking about the future is a bad thing and should never be done. > > Thanks, > Doug > > > > > On 6/24/14, 11:23 AM, "Brandon Log

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

uestion (backend > could queue > for later, or error immediately, or let things run degraded, > orŠ) > > Thanks, > Doug > > > > > On 6/24/14, 11:23 AM, "Brandon Logan

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

object like LoadBalancer. So I think the status fields > should stay. > > > In this scenario, some entities' status could be > updated in lbaas proper, and some in the driver &g

Re: [openstack-dev] [Neutron][LBaaS] Should TLS settings for listener be set through separate API/model?

Date: Monday, June 23, 2014 at 5:25 PM > To: "OpenStack Development Mailing List (not for usage > questions)" > Subject: Re: [openstack-dev] [Neutron][LBaaS] Should > TLS settings for listener be set through separate >

Re: [openstack-dev] [Neutron][LBaaS] Analyzing the critical path

Hi Sam, I'll comment on what I know in-line. On Wed, 2014-07-02 at 15:29 +, Samuel Bercovici wrote: > To reiterate the Juno release plan from: > https://wiki.openstack.org/wiki/Juno_Release_Schedule > > Feature freeze is at: 21st August. > > > > I am listing tasks which we should consider

Re: [openstack-dev] [Neutron][LBaaS] Agenda for weekly IRC meeting

Some things I can think of for the agenda: New API - Are shim layers really needed for Juno? - If the old API and new API will coexist independently, why is a shim layer needed? - Has the caveat that the pools resource can exist independently in both APIs. This can be acco

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

With the new API and object model refactor there have been some issues arising dealing with the status of entities. The main issue is that Listener, Pool, Member, and Health Monitor can exist independent of a Load Balancer. The Load Balancer is the entity that will contain the information about w

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

ocess got stuck in that status and may be in a bad > >state from user perspective. I like the idea of QUEUED or similar to > >reference that the object has been accepted but not provisioned. > > > >Phil > > > >On 7/3/14 10:28 AM, "Brandon Logan" wrot

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

McClain" wrote: > >On Jul 4, 2014, at 5:27 PM, Brandon Logan >wrote: > >> Hi German, >> >> That actually brings up another thing that needs to be done. There is >> no DELETED state. When an entity is deleted, it is deleted from the >> datab

[openstack-dev] [Neutron][LBaaS] LBaaS API Version 2 WIP in gerrit

https://review.openstack.org/#/c/105331 It's a WIP and the shim layer still needs to be completed. Its a lot of code, I know. Please review it thoroughly and point out what needs to change. Thanks, Brandon ___ OpenStack-dev mailing list OpenStack-d

Re: [openstack-dev] [Neutron][LBaaS] LBaaS API Version 2 WIP in gerrit

are.com>> wrote: Hi Brandon I think the patch should be broken into few standalone sub patches. As for now it is huge and review is a challenge :) Thanks Avishay -Original Message- From: Brandon Logan [mailto:brandon.lo...@rackspace.com<mailto:brandon.lo...@rackspace.com>] Sen

Re: [openstack-dev] [Neutron][LBaaS] LBaaS API Version 2 WIP in gerrit

ks, Brandon From: Brandon Logan [brandon.lo...@rackspace.com] Sent: Tuesday, July 08, 2014 1:53 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Neutron][LBaaS] LBaaS API Version 2 WIP in gerrit Avishay, You're probably right about br

Re: [openstack-dev] [Neutron][LBaaS] Wednesday meeting agenda topics

My personal opinion is I prefer the IRC meetings right now. I, personally, don't get any more value out of a video chat than I would with an IRC meeting. However, I know others do get more out of it, and that includes people on my team at Rackspace. Basically, what I am saying is I'd be fine

Re: [openstack-dev] [Neutron][LBaaS] Weekly IRC Meeting Agenda

one more agenda item is shim vs agent refactor. I sent the email out just a second ago. From: Jorge Miramontes [jorge.miramon...@rackspace.com] Sent: Wednesday, July 09, 2014 4:58 PM To: OpenStack Development Mailing List (not for usage questions) Subject: [openst

[openstack-dev] [Neutron][LBaaS] Shim vs Agent Refactor

Shim will become quite complicated due to the fact we won't be able to actually send any load balancer information to the driver until a load balancer is linked to a listener, pool, and member. The reason is because for a vip to be created it needs attributes from a load balancer and listener.

Re: [openstack-dev] [Neutron][LBaaS] Shim vs Agent Refactor

;t think about, eh! Stephen On Wed, Jul 9, 2014 at 3:12 PM, Brandon Logan > wrote: Shim will become quite complicated due to the fact we won't be able to actually send any load balancer information to the driver until a load balancer is linked to a listener, pool, and member. The reason

Re: [openstack-dev] [Neutron][LBaaS] Shim vs Agent Refactor

s not usable for many deployments. -Dustin On Thu, Jul 10, 2014 at 1:37 PM, Brandon Logan mailto:brandon.lo...@rackspace.com>> wrote: Okay so after talking to Kyle, we've decided to forego creating a new version of the agent right away and just creating a new haproxy driv

[openstack-dev] [Neutron][LBaaS] Last Two Reviews In Gerrit for V2 API

These implement the Haproxy driver without an agent. It's a WIP right now until tests are complete and a few more issues are resolved, but its functional for the most part. We split it up into two reviews: https://review.openstack.org/#/c/108173/ https://review.openstack.org/#/c/108174/ If yo

[openstack-dev] [Neutron][LBaaS] Update on specs we needed approved

In reference to these 3 specs: TLS Termination - https://review.openstack.org/#/c/98640/ L7 Switching - https://review.openstack.org/#/c/99709/ Implementing TLS in reference Impl - https://review.openstack.org/#/c/100931/ Kyle has +2'ed all three and once Mark Mcclain +2's them then one of them w

Re: [openstack-dev] [Neutron][LBaaS] TLS capability - certificates data persistency

I agree with Sam. We're under a strict timeline here and the simpler the code the faster it will be implemented and reviewed. Is there any strong reason why this caching can't wait until K if it decided it is really needed? Thanks, Brandon On Tue, 2014-07-22 at 11:01 +, Samuel Bercovici wro

Re: [openstack-dev] FW: [Neutron][LBaaS] TLS capability - work division

@Evgeny: Did you intend on adding another patchset in the reviews I've been working on? If so I don't really see any changes, so if they're are some changes you needed in there let me know. @Doug: I think if the drivers see the TERMINATED_HTTPS protocol then they can throw an exception. I don't t

Re: [openstack-dev] [Neutron][LBaaS][Tempest] LBaaS V2 testing, partial results

Hey Miguel! Thanks for doing this. I'll look into the pool issue ASAP and get back to you. Thanks, Brandon On Sun, 2014-07-27 at 19:24 -0500, Miguel Lavalle wrote: > Hi, > > > I spent a few hours deploying LBaaS V2 to my devstack instance and > tested it with the Tempest api test developed a

Re: [openstack-dev] [Neutron][LBaaS][Tempest] LBaaS V2 testing, partial results

Hey Miguel, I just tried to reproduce what you got but couldn't. Have you pulled down code recently? I believe new code hit on Friday that probably fixed the issue you encountered. Let me know. Thanks, Brandon On Sun, 2014-07-27 at 19:24 -0500, Miguel Lavalle wrote: > Hi, > > > I spent a fe

[openstack-dev] [Neutron][LBaaS] Status and Expectations for Juno

There is going to be a mad rush to get many things into Neutron for Juno here in the last few weeks. Neutron is overly saturated with code reviews. So I'd like to list out some of the things LBaaS had planned for Juno, what the status each of those are, and my thoughts on the feasibility of actua

Re: [openstack-dev] [Neutron][LBaaS] Status and Expectations for Juno

gt;- Ref driver with agent, support old drivers, support new drivers > >>- UI, new and improved > >> > >>Š what we¹re now thinking of shipping: > >> > >>- Shiny new object model (base for some new features) > >>- TLS termination/offload > >&

Re: [openstack-dev] [Neutron] Managing change in gerrit which depends on multiple other changes in review

Hi Evgeny and Doug, So the thing to keep in mind is that Gerrit determines a new review by the change-id in the commit message. It then determines patch sets by the commit hashes. This is my understanding of it at least. A commit's hash gets changed on many actions such as cherry-picks, rebases

Re: [openstack-dev] [neutron] API confusion

Hi Mike, So that looks like those docs are for the v2 LBaaS API. The CLI changes for v2 are not in yet, and the v2 API implementation code is in review right now. I am a bit worried that I do not see the v1 docs anymore because v1 will still remain until its deprecated. In fact, I'm pretty sure

Re: [openstack-dev] [Neutron][LBaaS][Tempest] LBaaS API Tempest testing status update

Hey Miguel, I was able to reproduce the issue here and luckily it was an error in the driver. So that means I don't need to update the plugin. I fixed the issue in the driver, and pushed the change up. Everything should be working now. Thanks, Brandon On Sun, 2014-08-03 at 20:42 -0500, Miguel

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

Hello Vijay! Well this is a hold over from v1, but the status is a provisioning status. So yes, when something is deployed successfully it should be ACTIVE. The exception to this is the member status, in that it's status can be INACTIVE if a health check fails. Now this will probably cause edg

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

tus discussion - likely high bandwith to work all > of that out. > > German > > -Original Message- > From: Brandon Logan [mailto:brandon.lo...@rackspace.com] > Sent: Tuesday, August 05, 2014 8:27 AM > To: openstack-dev@lists.openstack.org > Subject: Re: [openstack-d

Re: [openstack-dev] [Octavia] Weekly meetings resuming + agenda

When is the plan to move the meeting to IRC? On Wed, 2014-08-06 at 15:30 -0700, Stephen Balukoff wrote: > Action items from today's Octavia meeting: > > > 1. We're going to hold off for a couple days on merging the > constitution and preliminary road map to give people (and in > particular Ebay)

Re: [openstack-dev] [Octavia] Weekly meetings resuming + agenda

t; > Stephen > > > On Wed, Aug 6, 2014 at 7:58 PM, Brandon Logan > wrote: > When is the plan to move the meeting to IRC? > > On Wed, 2014-08-06 at 15:30 -0700, Stephen Balukoff wrote: > > Action items from today's Octavia meeti

Re: [openstack-dev] [Octavia] Weekly meetings resuming + agenda

Those are definitely other big reasons, and probably the reason it is planned to move to IRC in the future, no matter what. I was just wondering how soon, if soon at all. On Thu, 2014-08-07 at 12:35 -0700, Stefano Maffulli wrote: > On Thu 07 Aug 2014 12:12:26 PM PDT, Brandon Logan wr

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

[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] 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,

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

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

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?

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

[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][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 _

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

- 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

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:

<    1   2   3   >