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

[Brandon Logan]

+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 well
> as a former co-PTL for Octavia.  Work dynamics required him to step
> away
> from the project for a period of time, but now he has moved back into
> a
> position that allows him to contribute to Octavia.  His review
> numbers are
> back in line with other core reviewers [1] and I feel he would be a
> solid
> asset to the core reviewing team.
> 
> Current Octavia cores, please respond with your +1 vote or an
> objections.
> 
> Michael
> 
> [1] http://stackalytics.com/report/contribution/octavia-group/90
> 
> 
> _
> _
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubs
> cribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Brandon Logan]

+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 same time, I'd like to propose Brian Haley as our next Chief
> L3 Officer. Both of them have worked with Carl Baldwin extensively
> and that can only be a guarantee of quality.
> 
> Cheers,
> Armando 
> 
> [1] https://review.openstack.org/#/c/411531/
> _
> _
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubs
> cribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Brandon Logan]

+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 the service
> framework, the agent framework and other bits and pieces. At this
> point, entrusting them with the responsibility is almost a formality.
> 
> Cheers,
> Armando
> 
> [1] https://review.openstack.org/#/c/411536/
> _
> _
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubs
> cribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Brandon Logan]

+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 Akihiro [1].

This not only will help speed up our transition to OSC CLI, but also improve 
the number of folks who can effectively liasion with the OSC team, and look 
after the needs of neutron's client repo.

Many thanks,
Armando

[1] https://review.openstack.org/#/c/410485/

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Brandon Logan]

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.
> So, during this work the code will be transitioning repositories and
> you will need to carefully synchronize and/or manage the changes in
> both places.
> Currently the API changes have patchsets up in the Octavia
> repository.
> However, the old namespace driver has not yet been migrated over.
I know I've talked about using the namespace driver as a guinea pig for
the nlbaas to octavia shim driver layer, but I didn't know it would be
fully supported in octavia.  This will require a bit more work because
of the callbacks the agent expects to be able to call.

> 
> Michael
> 
> 
> On Tue, Dec 6, 2016 at 8:46 AM, Kosnik, Lubosz  om> wrote:
> > Hello Zhi,
> > So currently we’re working on dropping LBasSv2 support.
> > Octavia is a big-tent project providing lbass in OpenStack and
> > after merging
> > LBasS v2 API in Octavia we will deprecate that project and in next
> > 2
> > releases we’re planning to completely wipe out that code
> > repository. If you
> > would like to help with LBasS in OpenStack you’re more than welcome
> > to start
> > working with us on Octavia.
> > 
> > Cheers,
> > Lubosz Kosnik
> > Cloud Software Engineer OSIC
> > 
> > On Dec 6, 2016, at 6:04 AM, Gary Kotton  wrote:
> > 
> > Hi,
> > I think that there is a move to Octavia. I suggest reaching out to
> > that
> > community and see how these changes can be added. Sounds like a
> > nice
> > addition
> > Thanks
> > Gary
> > 
> > From: zhi 
> > Reply-To: OpenStack List 
> > Date: Tuesday, December 6, 2016 at 11:06 AM
> > To: OpenStack List 
> > Subject: [openstack-dev] [neutron][lbaas] New extensions for
> > HAProxy driver
> > based LBaaSv2
> > 
> > Hi, all
> > 
> > I am considering add some new extensions for HAProxy driver based
> > Neutron
> > LBaaSv2.
> > 
> > Extension 1, multi subprocesses supported. By following this
> > document[1], I
> > think we can let our HAProxy based LBaaSv2 support this feature. By
> > adding
> > this feature, we can enhance loadbalancers performance.
> > 
> > Extension 2, http keep-alive supported. By following this
> > document[2], we
> > can make our loadbalancers more effective.
> > 
> > 
> > Any comments are welcome!
> > 
> > Thanks
> > Zhi Chang
> > 
> > 
> > [1]: http://cbonte.github.io/haproxy-dconv/1.6/configuration.html#c
> > pu-map
> > [2]:
> > http://cbonte.github.io/haproxy-dconv/1.6/configuration.html#option
> > %20http-keep-alive
> > ___
> > ___
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsu
> > bscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> > 
> > 
> > 
> > ___
> > ___
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsu
> > bscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> > 
> 
> _
> _
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubs
> cribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Brandon Logan]

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 to keep up with my duties as a Neutron core
> reviewer, L3 lieutenant, and drivers team member. My participation
> has dropped off considerably since Newton was released and I think it
> is fair to step down and leave an opening for others to fill. There
> is no shortage of talent in Neutron and Openstack and I know I'm
> leaving it in good hands.
> 
> I will be more than happy to come back to full participation in
> Openstack and Neutron in the future if things change again in that
> direction. This is a great community and I've had a great time
> participating and learning with you all.
> 
> Well, I don't want to drag this out. I will still be around on IRC
> and will be happy to help out where I am able. Feel free to ping me.
> 
> Carl
> _
> _
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubs
> cribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Brandon Logan]

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  
> > breakages.
> 
> ^ the step depends on how far we want to go with the adoption. If
> it’s just  
> changing import paths, then it will be easy but will give wrong
> signal to  
> subprojects that the whole practice of them piggy-backing on
> neutron  
> options is acceptable. On the other hand, we could help them get off
> the  
> hook, by working in scope of neutron-lib to expose whatever they
> *really*  
> need (and switch off neutron options completely where there is no
> clear  
> semantic requirement for the option value to be shared).
> 
> While the latter path is not as easy, I would prefer it any time. It
> is in  
> line with the neutron-lib effort goal to decouple stadium subprojects
> from  
> neutron code base.

Yeah this is pretty much the real question of this thread.  How much
impact to subprojects is acceptable in getting to the 100% decoupled
state?

> 
> > 3) Use the patch and make it needed-by the neutron changes.
> > 4) Evangelize patch 2 one more time on the ML.
> > 5) We'll bring this up at the team meeting, for another form or
> > record.
> > 6) Wait another few days for projects to catch up.
> > 7) Merge the patch in neutron.
> > 8) We all move on.
> 
> _
> _
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubs
> cribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Brandon Logan]

On Tue, 2016-11-01 at 13:13 +0100, Ihar Hrachyshka wrote:
> Brandon Logan <brandon.lo...@rackspace.com> 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 and
> > have
> > come across a few that would cause issues with other projects that
> > are
> > importing these options, especially stadium projects.  High level
> > view
> > of the issue:
> > 
> > [1] would cause at least 22 projects to need to be fixed based on
> > [2]
> > [3] would cause at least 12 projects to need to be fixed based on
> > [4]
> > 
> > [5] looks to affect many other projects as well (I'm being lazy and
> > not  counting them right now)
> > 
> > Initially, the thinking was that moving the config options around
> > would
> > cause some breakage with projects outside of neutron, but that
> > would be
> > fine because projects shouldn't really be using neutron as a
> > library
> > and using it to register config options.  However, with these 3
> > patches, I definitely don't feel comfortable breaking the amount of
> > projects these would break.  It also makes me think that maybe
> > these
> > options should be in neutron-lib since they're consumed so widely.
> 
> Definitely not neutron-lib material (unless carefully hidden behind
> clearly  
> public API).
> 
> There is a reason why oslo folks explicitly deny any support for  
> configuration option names and locations their libraries expose
> [1].  
> Options are for operators to change in configuration files, but not
> to  
> access them or set programmatically. If there are options that
> subprojects  
> need access to, we should expose them via explicitly public API, like
> we  
> did with global_physnet_mtu [2].
> 
> [1]  
> http://docs.openstack.org/developer/oslo.config/faq.html#why-are-conf
> iguration-options-not-part-of-a-library-s-api
> [2]  
> https://github.com/openstack/neutron/blob/181bdb374fc0c944b1168f27ac7
> b5cbb0ff0f3c3/neutron/plugins/common/utils.py#L43

Yeah allowing the options to be imported directly from code outside the
repo doesn't make sense.  When you talk about a public API in neutron-
lib for these options, are only talking about READ access as the
example you gave? OR are you also talking about being able to register
these options as well via functions that require no access to the
options?  If that is the case, then these centralize config option
patches are basically doing that, except not in neutron-lib.  Do you
think we should move these to neutron-lib instead?  This would mean the
config options themselves would then probably end up living in neutron-
lib (though I guess they wouldn't have to).  We'll still have to figure
out what to do with the subprojects though, but having them in neutron-
lib and neutron at the same time during a transition period might make
this easier.

> 
> > Anyway, I've come up with some possible options to deal with this,
> > but
> > would like to hear others' opinions on this:
> > 
> > 1) Let the patches merge and break those projects as a signal that
> > importing these shouldn't be done.  The affected projects can
> > choose to
> > push fixes that continue importing the neutron config options or
> > defining their own config options.
> > 2) Deprecate the old locations for some timeframe, and then remove
> > later.
> > 3) Texas Three-Step: change the neutron patches to keep pointers in
> > the
> > old locations to the new, and then push patches to the affected
> > repos
> > with Depends-On directives.  Once all patches merge, push up one
> > more
> > patch to neutron to remove the old location.
> > 4) Abandon these reviews and do nothing.
> > 5) Move these config options to neutron-lib so that they can be
> > used by
> > any project.  This still requires doing one of the above options,
> > however.
> > 6) Any others I can't think of?
> 
> Whatever makes subprojects stop accessing neutron configuration
> options  
> programmatically. If we indeed identify something that plugins MUST
> have  
> access to, then let’s work in scope of neutron-lib to expose those
> options  
> through public API (not CONF object!)
> 
> I believe it's subprojects who should identify and vouch for and
> propose  
> neutron-lib patches to expose values they may need in their
> extensions;  
> Neutron should of course give a notice about its plans; we could
> broadly  
> target those changes to early Pike if we th

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

[Brandon Logan]

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 to fix for them, so that is another
option.  

Thanks,
Brandon

On Fri, 2016-10-28 at 15:19 +, Sean M. Collins wrote:
> It appears though that from the code search that it's all just based
> on
> unit tests, and overriding some configuration stuff.
> 
> Since a lot of these unit test classes inherit from
> Ml2PluginV2TestCase,
> and it looks like there is a lot of copy & paste / cargo-cult that
> occurred where the same line was copied across the stadium[1] to just
> change some configuration before running unit tests, maybe we should
> provide an attribute in Ml2PluginV2TestCase to get the oslo.config
> instance so that overrides can be called?
> 
> This is assuming I grok the problem, I've only had one cup of coffee
> so
> far
> 
> [2]: http://codesearch.openstack.org/?q=ml2_config.cfg.CONF.set_overr
> ide=nope==
> 
> 
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Brandon Logan]

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 view
of the issue:

[1] would cause at least 22 projects to need to be fixed based on [2]

[3] would cause at least 12 projects to need to be fixed based on [4]

[5] looks to affect many other projects as well (I'm being lazy and
not  counting them right now)

Initially, the thinking was that moving the config options around would
cause some breakage with projects outside of neutron, but that would be
fine because projects shouldn't really be using neutron as a library
and using it to register config options.  However, with these 3
patches, I definitely don't feel comfortable breaking the amount of
projects these would break.  It also makes me think that maybe these
options should be in neutron-lib since they're consumed so widely. 
Anyway, I've come up with some possible options to deal with this, but
would like to hear others' opinions on this:

1) Let the patches merge and break those projects as a signal that
importing these shouldn't be done.  The affected projects can choose to
push fixes that continue importing the neutron config options or
defining their own config options.
2) Deprecate the old locations for some timeframe, and then remove
later.
3) Texas Three-Step: change the neutron patches to keep pointers in the
old locations to the new, and then push patches to the affected repos
with Depends-On directives.  Once all patches merge, push up one more
patch to neutron to remove the old location.
4) Abandon these reviews and do nothing.
5) Move these config options to neutron-lib so that they can be used by
any project.  This still requires doing one of the above options,
however.
6) Any others I can't think of?



[1] https://review.openstack.org/#/c/343045/
[2] http://codesearch.openstack.org/?q=from%20neutron.agent.common%20im
port%20config=nope==

[3] https://review.openstack.org/#/c/340228/
[4] http://codesearch.openstack.org/?q=neutron.plugins.ml2%20import%20c
onfig=nope==

[5] https://review.openstack.org/#/c/347867/
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Brandon Logan]

+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 of our community.  He regularly attends our weekly
> meetings, contributes good code, and provides solid reviews.
> 
> Overall I think Lubosz would make a great addition to the core review
> team.
> 
> Current Octavia cores, please respond with +1/-1.
> 
> Michael
> 
> [1] http://stackalytics.com/report/contribution/octavia/90
> 
> _
> _
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubs
> cribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Brandon Logan]

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, release and
> oslo liaison (I am sure I am forgetting some other capacity he is in)
> is going to put him at great comfort in the newly appointed role, and
> help him grow and become wise even further.
> 
> Even though we have not been meeting regularly lately we will resume
> our Thursday meetings soon [2], and having Ihar onboard by then will
> be highly beneficial. 
> 
> Please, join me in welcome Ihar to the team.
> 
> Cheers,
> Armando 
> 
> [1] http://docs.openstack.org/developer/neutron/policies/neutron-team
> s.html#drivers-team
> [2] https://wiki.openstack.org/wiki/Meetings/NeutronDrivers
> _
> _
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubs
> cribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Brandon Logan]

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 filters into  
> plugins; same for plugins returning random fields: API layer should filter  
> unknown data out. We already have attribute maps defined for extensions, so  
> it should be relatively easy to implement that without making plugin layer  
> forgiving to those kinds of requests.
> 
> Ihar

This is possible for most resources, but the resources that use member
actions do not have those attributes mapped out I don't believe so there
won't be a generic way to do this for those.  There aren't many of those
though.  The other one is the extensions that define their own
controllers, like agent reschedulers.  That can be modified in the
controllers themselves though and wouldn't be too big of a deal.

> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Brandon Logan]

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-encryption will be introduced in
> later phase. Is the ssl re-encryption feature available in the mitaka
> release? I understand ssl offload is available, but I want to try the
> ssl re-encryption on octavia lbaas. 
> This link refers to v1
> probably https://wiki.openstack.org/wiki/Neutron/LBaaS/SSL. Please
> redirect me to any documentation if ssl re-encryption is there.
> 
> 
> Thanks
> Akshay Sanghai
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Brandon Logan]

+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, Jul
> > 22, 2016 at 2:36 AM, Doug Wiegley 
> > 
> > From: Oleg Bondarev 
> > To: "OpenStack Development Mailing List (not for usage questions)"
> > 
> > Date: 22/07/2016 09:13
> > Subject: Re: [openstack-dev] [Neutron] Proposing Jakub Libosvar for
> > testing core
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > +1
> > 
> > On Fri, Jul 22, 2016 at 2:36 AM, Doug Wiegley
> >  wrote:
> > +1
> > On Jul 21, 2016, at 5:13 PM, Kevin Benton
> >  wrote:
> > 
> > +1
> > 
> > On Thu, Jul 21, 2016 at 2:41 PM, Carl
> > Baldwin  wrote:
> > +1 from me
> > 
> > On Thu, Jul 21, 2016 at 1:35 PM, Assaf
> > Muller  wrote:
> > As Neutron's so called testing
> > lieutenant I would like to propose
> > Jakub Libosvar to be a core in the
> > testing area.
> > 
> > Jakub has demonstrated his inherent
> > interest in the testing area over
> > the last few years, his reviews are
> > consistently insightful and his
> > numbers [1] are in line with others
> > and I know will improve if given
> > the responsibilities of a core
> > reviewer. Jakub is deeply involved
> > with
> > the project's testing
> > infrastructures and CI systems.
> > 
> > As a reminder the expectation from
> > cores is found here [2], and
> > specifically for cores interesting
> > in helping out shaping Neutron's
> > testing story:
> > 
> > * Guide community members to craft a
> > testing strategy for features [3]
> > * Ensure Neutron's testing
> > infrastructures are sufficiently
> > sophisticated to achieve the above.
> > * Provide leadership when
> > determining testing Do's & Don'ts
> > [4]. What
> > makes for an effective test?
> > * Ensure the gate stays consistently
> > green
> > 
> > And more tactically we're looking at
> > finishing the Tempest/Neutron
> > tests dedup [5] and to provide
> > visual graphing for historical
> > control
> > and data plane performance results
> > similar to [6].
> > 
> > [1]
> > 
> > http://stackalytics.com/report/contribution/neutron/90
> > [2]
> > 
> > http://docs.openstack.org/developer/neutron/policies/neutron-teams.html
> > [3]
> > 
> > http://docs.openstack.org/developer/neutron/devref/development.environment.html#testing-neutron
> > [4]
> > 
> > https://assafmuller.com/2015/05/17/testing-lightning-talk/
> > [5]
> > 
> > https://etherpad.openstack.org/p/neutron-tempest-defork
> > [6]
> > 
> > https://www.youtube.com/watch?v=a0qlsH1hoKs=youtu.be=24m22s
> >  

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

[Brandon Logan]

pybrctl repo is at: https://github.com/udragon/pybrctl
It is in pypi.

Looks like a wrapper around the shell brctl commands.  I don't think it
would buy us anything more than what moving neutron's current
implementation of doing brctl commands to neutron-lib would do.  In
fact, it might end up costing more.  That's just my very uninformed
opinion though.

Thanks,
Brandon

On Thu, 2016-07-07 at 23:59 +, Bhatia, Manjeet S wrote:
> Hi,
>  
> There is work in progress for pure python driven linux network
> configuration. I think most
> of work will be done with this patch https://review.openstack.org/#/c
> /155631/ . The only
> thing left after this will be linux bridge configuration, Which I
> would like to discuss with
> community. There are two ways at the moment I can think to do that
> implementation,
> First, use pybrctl which may 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 to neutron-lib, which I think is
> better solution. I would
> like to have views of community, especially people working neutron-
> lib about moving
> python code for executing brctl commands to neutron-lib.
>  
>  
> Thanks and Regards !
> Manjeet Singh Bhatia
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Brandon Logan]

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 I'll keep my comments in case I'm wrong.  My brain is
not working well today, sorry :(

Thanks,
Brandon

On Wed, 2016-06-29 at 18:14 +0200, Ihar Hrachyshka wrote:
> Hi all,
> 
> I was looking lately at upgrades for octavia images. This includes using new 
> images for new loadbalancers, as well as for existing balancers.
> 
> For the first problem, the amp_image_tag option that I added in Mitaka seems 
> to do the job: all new balancers are created with the latest image that is 
> tagged properly.
> 
> As for balancers that already exist, the only way to get them use a new image 
> is to trigger an instance failure, that should rebuild failed nova instance, 
> using the new image. AFAIU the failover process is not currently automated, 
> requiring from the user to set the corresponding port to DOWN and waiting for 
> failover to be detected. I’ve heard there are plans to introduce a specific 
> command to trigger a quick-failover, that would streamline the process and 
> reduce the time needed for the process because the failover would be 
> immediately detected and processed instead of waiting for keepalived failure 
> mode to occur. Is it on the horizon? Patches to review?

Not that I know of and with all the work slated for Newton, I'm 99% sure
it won't be done in Newton.  Perhaps Ocata.
> 
> While the approach seems rather promising and may be applicable for some 
> environments, I have several concerns about the failover approach that we may 
> want to address.
> 
> 1. HA assumption. The approach assumes there is another node running 
> available to serve requests while instance is rebuilding. For non-HA 
> amphoras, it’s not the case, meaning the image upgrade process has a 
> significant downtime.
> 
> 2. Even if we have HA, for the time of instance rebuilding, the balancer 
> cluster is degraded to a single node.
> 
> 3. (minor) during the upgrade phase, instances that belong to the same HA 
> amphora may run different versions of the image.
> 
> What’s the alternative?
> 
> One idea I was running with for some time is moving the upgrade complexity 
> one level up. Instead of making Octavia aware of upgrade intricacies, allow 
> it to do its job (load balance), while use neutron floating IP resource to 
> flip a switch from an old image to a new one. Let me elaborate.
I'm not sure I like the idea of tying this to floating IP as there are
deployers who do not use floating IPs.  Then again, we are currently
depending on allowed address pairs which is also an extension, but I
suspect its probably deployed in more places.  I have no proof of this
though.
> 
> Let’s say we have a load balancer LB1 that is running Image1. In this 
> scenario, we assume that access to LB1 VIP is proxied through a floating ip 
> FIP that points to LB1 VIP. Now, the operator uploaded a new Image2 to glance 
> registry and tagged it for octavia usage. The user now wants to migrate the 
> load balancer function to using the new image. To achieve this, the user 
> follows the steps:
> 
> 1. create an independent clone of LB1 (let’s call it LB2) that has exact same 
> attributes (members) as LB1.
> 2. once LB2 is up and ready to process requests incoming to its VIP, redirect 
> FIP to the LB2 VIP.
> 3. now all new flows are immediately redirected to LB2 VIP, no downtime (for 
> new flows) due to atomic nature of FIP update on the backend (we use 
> iptables-save/iptables-restore to update FIP rules on the router).
Will this sever any existing connections? Is there a way to drain
connections? Or is that already done?
> 4. since LB1 is no longer handling any flows, we can deprovision it. LB2 is 
> now the only balancer handling members.
> 
> With that approach, 1) we provide for consistent downtime expectations 
> irrelevant to amphora architecture chosen (HA or not); 2) we flip the switch 
> when the clone is up and ready, so no degraded state for the balancer 
> function; 3) all instances in an HA amphora run the same image.
> 
> Of course, it won’t provide no downtime for existing flows that may already 
> be handled by the balancer function. That’s a limitation that I believe is 
> shared by all approaches currently at the table.
> 
> As a side note, the approach would work for other lbaas drivers, like 
> namespaces, f.e. in case we want to update haproxy.
> 
> Several questions in regards to the topic:
> 
> 1. are there any drawbacks with the approach? can we consider it an 
> alternative way of doing image upgrades that could find its way into official 
> documentation?

Echoing my comment above of being tightly coupled with floating IPs is a
draw back.

Another way would be to make use of the allowed address pairs:
1) spin up a 

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

[Brandon Logan]

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 image if it was the first.
On Wed, 2016-06-29 at 10:35 -0600, Doug Wiegley wrote:
> > On Jun 29, 2016, at 10:25 AM, Ihar Hrachyshka  wrote:
> > 
> > 
> >> On 29 Jun 2016, at 18:10, Doug Wiegley  
> >> wrote:
> >> 
> >> Interesting discussion, but the first question I’d ask is ‘why’ ?
> >> 
> >> Unlike openstack server software, the amphora are meant to be black box 
> >> appliance images, so why do we want to run different distros on them? Is 
> >> there a deployment scenario you’re concerned with, or other use case?
> > 
> > Because vendors want to keep control for the contents of the image. For 
> > one, Company X may not be particularly happy about shipping and supporting 
> > Ubuntu based images through its channels. And without it, there is no 
> > end-to-end support story for load balancers that the company could sell to 
> > its customers. The company may also want to specialize the image contents 
> > in some way, f.e. inject additional vendor specific security mechanisms, or 
> > ship a new better version of haproxy. 
> > 
> > I believe it’s self evident, but for completeness: Company X engineers 
> > would not support Ubuntu bits because 1. they don’t have expertise in 
> > Ubuntu. 2. it would give a really twisted message to customers.
> 
> Fair enough, and that’s the reply that I was expecting. So either we make the 
> amphora driver distro aware, or multiple amphora drivers/images. I presume 
> that “company x” is willing to devote resources to this?
> 
> Thanks,
> doug
> 
> > 
> > Ihar
> > __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Brandon Logan]

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
> services are running/enabled has been replaced with checks for if an API
> extension is available. The point being, the Networking API should be
> discoverable and features should be determined based on what extensions
> are available, instead of some DevStack-y bits.
> 
> Neutron controls what API extensions are loaded via the
> `api_extensions_path`[2]
> 
> https://github.com/openstack/neutron/blob/master/neutron/common/config.py#L46
> 
> So by default Neutron loads up every extension that is included in tree.
> 
> But what if a deployment doesn't want to support an API extension?
> 
> With third party CI, prior to https://review.openstack.org/#/c/318145 -
> systems could get away with it by not enabling services - like q-l3 - and
> that would stop subnets and routers being created. After that patch,
> well that's not the case.
> 
> So is there a way to configure what API extensions are available, so that
> if a CI system doesn't want to provide the ability to create Neutron
> routers, they can disable the router API extension in some manner more
> graceful than rm'ing the extension file?
> 
> I know at least in one deployment I was involved with, we didn't deploy
> the L3 agent, but I don't believe we disabled or deleted the router API
> extension, so users would try and create routers and other resources
> then wonder why nothing would ever work.
> 
> From a discoverability standpoint - do we provide fine-grained a way for 
> deployers to enable/disable specific API extensions?

As far as I know, you can disable an extension by moving it out of that
api_extensions_path, renaming it with an _ in front of it, or the core
plugin or any loaded service plugins do not support it via the
support_extension_aliases variable.  I don't know of any easier way to
do that.  Hopefully I'm just not aware of one that exists.

> 
> 
> Further reading:
> 
> http://lists.openstack.org/pipermail/openstack-dev/2016-May/095323.html
> http://lists.openstack.org/pipermail/openstack-dev/2016-May/095349.html
> http://lists.openstack.org/pipermail/openstack-dev/2016-May/095361.html
> 
> 
> [1]: http://lists.openstack.org/pipermail/openstack-dev/2016-May/095095.html
> [2]: 
> https://github.com/openstack/neutron/blob/master/neutron/common/config.py#L46
> 


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Brandon Logan]

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 quite confusing to a user, especially if they get a
message saying that a particular subnet is preventing the deletion and
the owner can't even see that subnet exists.

One thing I may not be thinking about is shared networks and/or rbac.
 I'm not sure some tenant/project can even create a subnet on another
tenant/project's shared/rbac'ed network.  I just attempted to do it
quickly on the CLI and it failed, but the error message was a big
policy splat.  I doubt that's even meant to happen, so perhaps this
case hasn't been thought about.

Thanks,
Brandon

On Fri, 2016-06-03 at 12:16 -0500, Darek Smigiel wrote:
> Hello,
> Doing reviews I noticed, that Liu Yong submitted a bug [1] where we
> have a problem with removing subnets.
> 
> In short: if tenant wants to delete network with subnets, where at
> least one of subnets is created by admin, he’s not able to do this.
> Liu also prepared bugfix for it [2], but now it’s starting to be much
> more complicated.
> 
> What is desired solution in this case?
> One of suggestions is to elevate context, remove all subnets and nuke
> everything. It can cause a problem, when one tenant can remove
> others’ tenant subnets.
> The other is to just show info to tenant, that he’s not allowed to
> delete network. But in the same time, it could be strange, that owner
> is not able to just get rid of *his* network and subnets.
> 
> If you have any opinions, suggestions, please feel free to share
> 
> [1] https://bugs.launchpad.net/neutron/+bug/1588228
> [2] https://review.openstack.org/#/c/324617/
> 
> 
> Darek
> _
> _
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubs
> cribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Brandon Logan]

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-facing installation guide for
> neutron-lbaas. I asked that because Magnum is working on an
> installation guide [1] and neutron-lbaas is a dependency of Magnum. We
> want to link to an official lbaas guide so that our users will have a
> completed instruction. Any pointer?
> 
>  
> 
> [1] https://review.openstack.org/#/c/319399/
> 
>  
> 
> Best regards,
> 
> Hongbin
> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Brandon Logan]

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 scheduling these in the context of a segment could be
> >> useful.
> >
> > Segments could be L2 adjacent, but I think it would be pretty uncommon for a
> > DHCP agent to have access to multiple L2 adjacent segments for the same
> > network. But even if that happens, the main use case I see for the scheduler
> > API is taking networks off of dead agents, agents going under maintenance,
> > or agents under heavy load. With the introduction of segments, all of those
> > are still possible via the network-based API.
> 
> I think I agree with this.  Let's not change the API at all to begin
> with.  I do think this means that the current API should work with or
> without segments.  I'm not sure that the current approach of doing
> scheduling for segments completely independently of scheduling for
> networks works for this.  Does it?
> 

I still think it does, but we can make it work without making them
separate.  My original plan was to keep them together, but that ended up
causing some unclean code and also the possibility of requiring an
interface change, which would break out-of-tree schedulers like bgp,
that just got moved out of tree.  If I can devise an alternative to
breaking that interface, then I'll go forward without separate
schedulers.

> >>Do you feel like it'd be beneficial to show what segment a dhcp agent is
> >> bound to in the API?
> >
> > Probably useful in some cases. This will already be possible by showing the
> > port details for the DHCP agent's port, but it might be worth adding in just
> > to eliminate the extra steps.
> 
> ++

This one is a lower priority, but I agree it could be beneficial.

> 
> Carl
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Brandon Logan]

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.
> 
> > resume the dhcp service by adding another subnet, but I don't think it is
> > a good way. Do we need to consider bind dhcp port to another segment when
> > deleting the existing one?
> 
> Where would you bind the port?  DHCP requires L2 connectivity to the
> segment which it serves.  But, you deleted the segment.  So, it makes
> sense that it wouldn't work.
> 
> Brandon is working on DHCP scheduling which should take care of this.
> DHCP should be scheduled to all of the segments with DHCP enabled
> subnets.  It should have a port for each of these segments.  So, if a
> segment (and its ports) are deleted, I think the right thing to do is
> to make sure that DHCP scheduling removes DHCP from that segment.  I
> would expect this to happen automatically when the subnet is deleted.
> We should check with Brandon to make sure this works (or will work
> when his work merges).

This is definitely something I've thought about, basically I'm treating
each segment as its own network, so in this case the rules that apply to
the network will be carried over for each segment with dhcp enabled
subnets.

> 
> Carl
> 
> > [1] https://review.openstack.org/#/c/317358


Thanks,
Brandon
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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.

[Brandon Logan]

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 that are ACTIVE to provide High Availability to the VMs.
> 
>  
> 
> This use case is being heavily used by Octavia.
> 
>  
> 
> Based on the request and the current DVR design I have put together an
> RFE and I need the community input to proceed further with your
> feedback and thoughts.
> 
>  
> 
> https://bugs.launchpad.net/neutron/+bug/1583694
> 
>  
> 
> Please provide your feedback on thoughts on the RFE.
> 
>  
> 
> Thanks.
> 
>  
> 
> Swaminathan Vasudevan
> 
> Systems Software Engineer (TC)
> 
>  
> 
>  
> 
> HP Networking
> 
> Hewlett-Packard
> 
> 8000 Foothills Blvd
> 
> M/S 5541
> 
> Roseville, CA - 95747
> 
> tel: 916.785.0937
> 
> fax: 916.785.1815
> 
> email: swaminathan.vasude...@hp.com
> 
>  
> 
>  
> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Brandon Logan]

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.
> 
> 
> Actually, you can specify multiple providers, but these configuration
> directives are repeatable and are not comma-separated. That's mean you
> should add the another service_provider in the [service_providers]
> section as a separate line.
> 
> 
> And yes, you can try to pass parameter 'provider' to create a
> loadbalancer of specific driver (according to code of lbaas).
> 
> 
> --
> Best Regards,
> Sergey Belous
> 
> > On 20 May 2016, at 11:47, Wilence Yao  wrote:
> > 
> > 
> > 
> > Hi all,
> > 
> > 
> > Can I enable multiple service_providers for lbaas v2  at the same
> > time?
> > such as
> > 
> > 
> > ```
> > service_provider=LOADBALANCER:Haproxy:neutron_lbaas.services.loadbalancer.drivers.haproxy.plugin_driver.HaproxyOnHostPluginDriver:default,
> >  
> > LOADBALANCER:radware:neutron_lbaas.services.loadbalancer.drivers.radware.driver.LoadBalancerDriver
> > ```
> > 
> > 
> > Then pass parameter 'provider' to create a loadbalancer of specific
> > driver
> > 
> > 
> > ```
> > neutron lbaas-loadbalancer-create --provider radware
> > 
> > ```
> > 
> > 
> > Thanks for any help
> > 
> > 
> > Wilence Yao
> > 
> > 
> > __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> > 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Brandon Logan]

On Tue, 2016-05-17 at 13:29 -0700, Kevin Benton wrote:
> I'm leaning towards option A because it keeps things cleanly
> separated. Also, if a cloud is using a plugin that supports segments,
> an operator could use the new API for everything (including single
> segment networks) so it shouldn't be that unfriendly. 
> 
> 
> However...
> 
> 
> >If there's some other option that I somehow missed please suggest it.
> 
> 
> The other option is to not make an API for this at all. In a
> multi-segment use-case, a DHCP agent will normally have access to only
> one segment of a network. By using the current API we can still
> assign/un-assign an agent from a network and leave the segment
> selection details to the scheduler. What is the use case for exposing
> this all of the way up to the operator?

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 scheduling these in the context of a segment
could be useful.  However, if that is not the case I fully agree that
those calls are not needed and it can 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, 2016 at 1:07 PM, Brandon Logan
> <brandon.lo...@rackspace.com> wrote:
> 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: {"networks": [{...}]}
> 
> - List agents hosting a network - GET /network
> - GET /networks/{network_id}/dhcp-agents
> - Response Body: {"agents": [{...}]}
> 
> - Add a network to an agent
> - POST /agents/{agent_id}/dhcp-networks
> - Request Body: {"network_id": "NETWORK_UUID"}
> 
> - Remove a network from an agent
> - DELETE /agents/{agent_id}/dhcp-networks/{network_id}
> 
> This same functionality needs to also be exposed for working
> with
> segments.  We need some opinions on the best way to do this.
> The
> options are:
> 
> A) Expose new resources for segment dhcp agent manipulation
> - GET /agents/{agent_id}/dhcp-segments
> - GET /segments/{segment_id}/dhcp-agents
> - POST /agents/{agent_id}/dhcp-segments
> - DELETE /agents/{agent_id}/dhcp-segments/{segment_id}
> 
> B) Allow segment info gathering and manipulation via the
> current network
> dhcp agent API resources. No new API resources.
> 
> C) Some combination of A and B.
> 
> My current opinion is that option C shouldn't even be an
> option but I
> just put it on here just in case someone has a strong
> argument.  If
> we're going to add new resources, we may as well do it all the
> way,
> which is what C implies would happen.
> 
> Option B would be great to use if segment support could easily
> be added
> in while maintaining backwards compatibility.  I'm not sure if
> that is
> going to be possible in a clean way.  Regardless, an extension
> will have
> to be created for this.
> 
> Option A is the cleanest strategy IMHO.  It may not be the
> most user
> friendly though because some networks may have multiple
> segments while
> others may not.  If a network is made up of just a single
> segment then
> the current network dhcp agent calls will be fine.  However,
> once a
> network is made up of multiple segments, it wouldn't make
> sense for the
> current network dhcp agent calls to be valid, they'd need to
> be made to
> the new segment resources.  This same line of thinking would
> probably
> have to be considered with Option B as well, so it may be a
> problem for
> both.
> 
> Anyway, I'd like to gather suggestions and opinions on this.
> If there's
> some other option that I someh

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

[Brandon Logan]

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: {"networks": [{...}]}

- List agents hosting a network - GET /network
- GET /networks/{network_id}/dhcp-agents
- Response Body: {"agents": [{...}]}

- Add a network to an agent
- POST /agents/{agent_id}/dhcp-networks
- Request Body: {"network_id": "NETWORK_UUID"}

- Remove a network from an agent
- DELETE /agents/{agent_id}/dhcp-networks/{network_id}

This same functionality needs to also be exposed for working with
segments.  We need some opinions on the best way to do this.  The
options are:

A) Expose new resources for segment dhcp agent manipulation
- GET /agents/{agent_id}/dhcp-segments
- GET /segments/{segment_id}/dhcp-agents
- POST /agents/{agent_id}/dhcp-segments
- DELETE /agents/{agent_id}/dhcp-segments/{segment_id}

B) Allow segment info gathering and manipulation via the current network
dhcp agent API resources. No new API resources.

C) Some combination of A and B.

My current opinion is that option C shouldn't even be an option but I
just put it on here just in case someone has a strong argument.  If
we're going to add new resources, we may as well do it all the way,
which is what C implies would happen.

Option B would be great to use if segment support could easily be added
in while maintaining backwards compatibility.  I'm not sure if that is
going to be possible in a clean way.  Regardless, an extension will have
to be created for this.

Option A is the cleanest strategy IMHO.  It may not be the most user
friendly though because some networks may have multiple segments while
others may not.  If a network is made up of just a single segment then
the current network dhcp agent calls will be fine.  However, once a
network is made up of multiple segments, it wouldn't make sense for the
current network dhcp agent calls to be valid, they'd need to be made to
the new segment resources.  This same line of thinking would probably
have to be considered with Option B as well, so it may be a problem for
both.

Anyway, I'd like to gather suggestions and opinions on this.  If there's
some other option that I somehow missed please suggest it.

Thanks,
Brandon

[1]
https://specs.openstack.org/openstack/neutron-specs/specs/newton/routed-networks.html#dhcp-scheduling

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Brandon Logan]

+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] [neutron][stable] proposing Brian Haley
> for neutron-stable-maint
> 
>  
> 
> +1 for both
> 
> 
>  
> 
> On Tue, May 17, 2016 at 5:57 AM, Kyle Mestery 
> wrote:
> 
> +1 (Also +1 for Cedric).
> 
> 
> On Tue, May 17, 2016 at 6:07 AM, Ihar Hrachyshka
>  wrote:
> > Hi stable-maint-core and all,
> >
> > I would like to propose Brian for neutron specific stable
> team.
> >
> > His stats for neutron stable branches are (last 120 days):
> >
> > mitaka: 19 reviews; liberty: 68 reviews (3rd place in the
> top); kilo: 16 reviews.
> >
> > Brian helped the project with stabilizing liberty
> neutron/DVR jobs, and with other L3 related stable matters. In
> his stable reviews, he shows attention to details.
> >
> > If Brian is added to the team, I will make sure he is aware
> of all stable policy intricacies.
> >
> > Side note: recently I added another person to the team
> (Cedric Brandilly), and now I realize that I haven’t followed
> the usual approval process. That said, the person also has
> decent stable review stats, and is aware of the policy. If
> someone has doubts about that addition to the team, please
> ping me and we will discuss how to proceed.
> >
> > Ihar
> >
> 
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> >
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> 
>  
> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Brandon Logan]

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 also be able to continue having a repository for your
plugin/driver in the openstack namespace.  Combine that with everything
else Doug said, it seems fairly logical unless I've missed something.

Thanks,
Brandon

On Sat, 2016-04-30 at 14:42 -0600, Doug Wiegley wrote:
> 
> > On Apr 30, 2016, at 1:24 PM, Fawad Khaliq 
> > wrote:
> > 
> > Hi folks,
> > 
> > Hope everyone had a great summit in Austin and got back safe! :)
> > 
> > At the design summit, we had a Neutron stadium evolution session,
> > which needs your immediate attention as it will impact many
> > stakeholders of Neutron.
> > 
> > To summarize for everyone, our Neutron leadership made the following
> > proposal for the “greater-good” of Neutron to improve and reduce
> > burden on the Neutron PTL and core team to avoid managing more
> > Neutron drivers:
> > 
> > Quoting the etherpad [1]
> > 
> > "No request for inclusion are accepted for projects focussed solely
> > on implementations and/or API extensions to non-open solutions.”
> 
> 
> Let’s be clear about official openstack projects versus in the
> ecosystem versus whatever, which is defined by the TC, not
> neutron: 
> https://governance.openstack.org/reference/new-projects-requirements.html
> 
> > 
> > To summarize for everyone what this means is that all Neutron
> > drivers, which implement non open source networking backends are
> > instantly out of the Neutron stadium and are marked as
> > "unofficial/unsupported/remotely affiliated" and rest are capable of
> > being tagged as "supported/official”.
> > 
> 
> 
> So, before we throw around statements like “supported” vs
> “unsupported”, let’s take a look at what the stadium governance change
> really entails:
> 
> 
> - The neutron core team won’t review/merge/maintain patches for your
> plugin/driver. In many cases, this was already true.
> - The neutron release team won’t handle tagging your releases. In many
> cases, this was already true.
> - The neutron PTL is no longer involved in your repository’s
> governance. In many cases, this was effectively already true.
> 
> 
> It doesn’t mean it isn’t a valid project that supports neutron
> interfaces.
> 
> 
> In or out of the stadium, all plugins have these challenges:
> 
> 
> - If you’re not using a stable interface, you’ll break a lot.
> - If you are using a stable interface, you’ll still break some
> (standard rot).
> - Vendors will need to support and test their own code.
> 
> 
> Every time this comes up, people get upset that neutron is closing its
> doors, or somehow invalidating all the existing plugins. Let’s review:
> 
> 
> - The neutron api and plugin interfaces are not going away.
> - There is ongoing work to libify more interfaces, for the sake of
> plugins/drivers.
> - There is a strong push for more documentation to make integrating
> better.
> - Non-stadium projects still have access to their infra repos and CI
> resources.
> 
> 
> Armando’s proposal was about recognizing reality, not some huge change
> in how things actually work. What is the point of having a project
> governed by Neutron that isn’t doing anything but consuming neutron
> interfaces, and is otherwise uninvolved? How can you expect neutron to
> vouch for those? What is your proposal?
> 
> 
> Thanks,
> doug
> 
> 
> 
> > 
> > This eliminates all commercial Neutron drivers developed for many
> > service providers and enterprises who have deployed OpenStack
> > successfully with these drivers. It’s unclear how the OpenStack
> > Foundation will communicate its stance with all the users but
> > clearly this is a huge set back for OpenStack and Neutron. Neutron
> > will essentially become closed to all existing, non-open drivers,
> > even if these drivers have been compliant with Neutron API for years
> > and users have them deployed in production, forcing users to
> > re-evaluate their options.
> > 
> > Furthermore, this proposal will erode confidence in Neutron and
> > OpenStack, and destroy much of the value that the community has
> > worked so hard to build over the years.
> > 
> > As a representative and member of the OpenStack community and
> > maintainer of a Neutron driver (since Grizzly), I am deeply
> > disappointed and disagree with this statement [2]. Tossing out all
> > the non-open solutions is not in the best interest of the end user
> > companies that have built working OpenStack clusters. This proposal
> > will lead OpenStack end users who deployed different drivers to
> > think twice about OpenStack communities’ commitment to deliver
> > solutions they need. Furthermore, this proposal punishes OpenStack
> > companies who developed commercial backend drivers to help end users
> > bring up 

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

[Brandon Logan]

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 that the microversion is the best approach to  
> > solve the backwards compat,
> > and the neutron is also going to adopt it [1]. But it will take a long  
> > time to totally introduce it into neutron I think.
> > So IMO, we can continue this discussion and then implement this feature  
> > in parallel with the microversion.
> >
> > Actually, according to the design [2], only a slight change will be done  
> > once the microversion landed, i.e.
> > replace the ' new header ' with the microversion to control the final  
> > format about the error message in the wsgi interface.
> >
> > [1] https://review.openstack.org/#/c/136760/
> > [2] https://review.openstack.org/#/c/298704
> 
> If no one is going to help with microversioning, it won’t ever happen. I  
> suggest we consolidate whichever resources we have to get it done, instead  
> of working on small API iterations as proposed in the thread.
> 
> Ihar
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Brandon Logan]

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 to
> callback before considering a port failed to be wired. The time this
> will take will depend quite a bit on how heavily loaded the system is.
> We can certainly try to get rid of it, but it means that we have to
> force assumptions about how quickly a system should give up waiting
> for wiring. It would be similar to getting rid of the option to choose
> a timeout value for the API clients.
> 
> 
> 
> >[3]: 
> >https://github.com/openstack-dev/devstack/blob/master/lib/neutron-legacy#L162
> >[4]: 
> >https://github.com/openstack/neutron/blob/master/neutron/common/config.py#L53
> 
> 
> Neutron does not need to be deployed with keystone. This is how you
> disable it. Some operators do not have Neutron exposed to tenants so
> keystone is stripped away for performance since the only things
> communicating with Neutron are internal trusted services.

This is correct. In a large deployment the number of requests going to
keystone dramatically affects performance.  Do you think this needs to
be a devstack config option though?  I kind of don't think it does for
no better reason than it's easy to just change the option in the
neutron.conf and restart.

> 
> On Mon, Apr 11, 2016 at 12:42 PM, Hirofumi Ichihara
>  wrote:
> I agree. Throughout I was reviewing Devstack over 3 cycles,
> I thought the same thing. Devstack often accepted patches just
> adding option although we're not sure who really needs the
> options.
> There are many useless stuff in the options.
> For example, default value of devstack option is the same
> value as
> default in Projects. Please look at [1] and [2], [3] and [4].
> Who uses these options?
> 
> We can see such options in devstack throughout. I agree we
> will adjust default configurations and
> that documents in Neutron side. However, let's eliminate such
> options are clearly useless first.
> And then we should do after we made necessary options clear.
> 
> [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
> [3]:
> 
> https://github.com/openstack-dev/devstack/blob/master/lib/neutron-legacy#L162
> [4]:
> 
> https://github.com/openstack/neutron/blob/master/neutron/common/config.py#L53
> 
> Thanks,
> Hirofumi
> 
> 
> On 2016/04/09 0:07, Sean M. Collins wrote:
> Prior to the introduction of local.conf, the only way
> to configure
> OpenStack components was to introduce code directly
> into DevStack, so
> that DevStack would pick it up then inject it into the
> configuration
> file.
> 
> This was because DevStack writes out new configuration
> files on each
> run, so it wasn't possible for you to make changes to
> any configuration
> file (nova.conf, neutron.conf, ml2_plugin.ini, etc..).
> 
> So, someone who wanted to set the Linux Bridge Agent's
> physical_interface_mappings setting for Neutron would
> have to use
> $LB_INTERFACE_MAPPINGS in DevStack, which would then
> be invoked by
> DevStack[1].
> 
> The local.conf functionality was introduced quite a
> while back, and
> I think it's time to have a conversation about why we
> should start
> moving away from the previous practice of declaring
> variables in
> DevStack, and then having them injected into the
> configuration files.
> 
> The biggest issue is: There is a disconnect between
> the developers
> using DevStack and someone who is an operator or who
> has been editing
> OpenStack conf files directly. So, for example I can
> tell you all about
> how DevStack has a bunch of variables for configuring
> Neutron (which is
> Not a Good Thing™), and how those go into DevStack and
> then end up coming
> out the other side in a Neutron configuration file.
> 
> Really, I would 

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

[Brandon Logan]

+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:
> 
> I don't know if my vote counts in this area,
> but +1!
> 
> What the gentleman said ^, +1.
> 
> 
> "me too ^" , +1 ! 
> 
> 
> 
> 
>  
> 
> __
> OpenStack Development Mailing List (not for usage
> questions)
> Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> 
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> 
> 
> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> 
> 
> 
> 
> -- 
> Regards,
> Ann Kamyshnikova
> Mirantis, Inc
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Brandon Logan]

+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
> insight and quality of his reviews.
> 
> Current Octavia cores, please vote by replying to this e-mail.
> 
> Michael
> 
> 
> [1] http://stackalytics.com/report/contribution/octavia/90
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Brandon Logan]

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.
> 
> >
> > Frankly I had just assumed he had core privileges for our repo anyway
> > via an inherited ACL.
> 
> Full disclosure: I had all -*aas core privileges before [not thru inherited  
> ACLs though]. It’s just that lately I lost some of them, probably due to  
> some cleanup.
> 
> To all: it’s not my plan to abuse the powers for anything that is not  
> required for general success of the current stadium. If I ever decide to  
> get more involved into a specific *-aas subproject strategically, I will  
> get back to the corresponding *-aas team for additional approval before I  
> use the powers for anything beyond those immediate goals set by PTL.
> 
> Ihar
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Brandon Logan]

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 attributes into the same validation schema.

The other problem with v1 and v2 running together was only occurring
when the v1 agent driver and v2 agent driver were both in use at the
same time.  This may actually have been fixed with some agent updates in
neutron, since that is common code.  It needs to be tested out though.

Thanks,
Brandon

On Thu, 2016-03-03 at 22:14 +, Fox, Kevin M wrote:
> Just because you had thought no one was using it outside of a PoC doesn't 
> mean folks aren''t using it in production.
> 
> We would be happy to migrate to Octavia. We were planning on doing just that 
> by running both v1 with haproxy namespace, and v2 with Octavia and then pick 
> off upgrading lb's one at a time, but the reuse of the v1 tables really was 
> an unfortunate decision that blocked that activity.
> 
> We're still trying to figure out a path forward.
> 
> We have an outage window next month. after that, it could be about 6 months 
> before we could try a migration due to production load picking up for a 
> while. I may just have to burn out all the lb's switch to v2, then rebuild 
> them by hand in a marathon outage :/
> 
> And then there's this thingy that also critically needs fixing:
> https://bugs.launchpad.net/neutron/+bug/1457556
> 
> Thanks,
> Kevin
> 
> From: Eichberger, German [german.eichber...@hpe.com]
> Sent: Thursday, March 03, 2016 12:47 PM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [Neutron][LBaaS]Removing LBaaS v1 - are weready?
> 
> Kevin,
> 
>  If we are offering a migration tool it would be namespace -> namespace (or 
> maybe Octavia since [1]) — given the limitations nobody should be using the 
> namespace driver outside a PoC so I am a bit confused why customers can’t 
> self migrate. With 3rd party Lbs I would assume vendors proving those scripts 
> to make sure their particular hardware works with those. If you indeed need a 
> migration from LBaaS V1 namespace -> LBaaS V2 namespace/Octavia please file 
> an RfE with your use case so we can discuss it further…
> 
> Thanks,
> German
> 
> [1] https://review.openstack.org/#/c/286380
> 
> From: "Fox, Kevin M" >
> Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
> >
> Date: Wednesday, March 2, 2016 at 5:17 PM
> To: "OpenStack Development Mailing List (not for usage questions)" 
> >
> Subject: Re: [openstack-dev] [Neutron][LBaaS]Removing LBaaS v1 - are weready?
> 
> no removal without an upgrade path. I've got v1 LB's and there still isn't a 
> migration script to go from v1 to v2.
> 
> Thanks,
> Kevin
> 
> 
> 
> From: Stephen Balukoff [sbaluk...@bluebox.net]
> Sent: Wednesday, March 02, 2016 4:49 PM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [Neutron][LBaaS]Removing LBaaS v1 - are weready?
> 
> I am also on-board with removing LBaaS v1 as early as possible in the Newton 
> cycle.
> 
> On Wed, Mar 2, 2016 at 9:44 AM, Samuel Bercovici 
> > wrote:
> Thank you all for your response.
> 
> In my opinion given that UI/HEAT will make Mitaka and will have one cycle to 
> mature, it makes sense to remove LBaaS v1 in Newton.
> Do we want do discuss an upgrade process in the summit?
> 
> -Sam.
> 
> 
> From: Bryan Jones [mailto:jone...@us.ibm.com]
> Sent: Wednesday, March 02, 2016 5:54 PM
> To: 
> openstack-dev@lists.openstack.org
> 
> Subject: Re: [openstack-dev] [Neutron][LBaaS]Removing LBaaS v1 - are weready?
> 
> And as for the Heat support, the resources have made Mitaka, with additional 
> functional tests on the way soon.
> 
> blueprint: https://blueprints.launchpad.net/heat/+spec/lbaasv2-suport
> gerrit topic: https://review.openstack.org/#/q/topic:bp/lbaasv2-suport
> BRYAN M. JONES
> Software Engineer - OpenStack Development
> Phone: 1-507-253-2620
> E-mail: jone...@us.ibm.com
> 
> 
> - Original message -
> From: Justin Pomeroy 
> >
> To: 
> openstack-dev@lists.openstack.org
> Cc:
> Subject: Re: [openstack-dev] [Neutron][LBaaS]Removing LBaaS v1 - are we ready?
> Date: Wed, Mar 2, 2016 9:36 AM
> 
> As for the horizon support, much of it will make Mitaka.  See the 

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

[Brandon Logan]

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-02-24 at 16:43 -0800, surekha saharan wrote:
> Hello All,
> 
> 
> I can't find the "device_id" anywhere the port in vip returns.
> 
> Below is the details of a vip, note the port_id
> "03a12958-656f-492b-8114-65d037ad6743"
> 
> neutron lb-vip-show b2b11f89-48fc-4fd4-99f9-6f26977f353a
> 
> +-+--+
> 
> | Field| Value |
> 
> +-+--+
> 
> | address  | 30.0.0.138|
> 
> | admin_state_up   | True  |
> 
> | connection_limit | -1|
> 
> | description  |   |
> 
> | id   | b2b11f89-48fc-4fd4-99f9-6f26977f353a |
> 
> | name | vip2  |
> 
> | pool_id  | 4e0a1909-08f9-4124-94c0-ef0650b36512 |
> 
> | port_id  | 03a12958-656f-492b-8114-65d037ad6743 |
> 
> | protocol | HTTP  |
> 
> | protocol_port| 80|
> 
> | session_persistence |   |
> 
> | status   | ACTIVE|
> 
> | status_description  |   |
> 
> | subnet_id| 61ed9305-7b15-484a-b843-cb759aebc163 |
> 
> | tenant_id| 3418d53683654d37b47caa1b66b72a21 |
> 
> +-+--+
> 
> 
> 
> 
> 
> Now, if I get the details of the above port, I get the device_id "
> 724fc160-2b2e-597e-b9ed-7f65313cd73f". 
> The id of the vip is part of name attribute
> "vip-b2b11f89-48fc-4fd4-99f9-6f26977f353a "
> 
> 
> 
> 
> neutron port-show 03a12958-656f-492b-8114-65d037ad6743
> 
> +---+---+
> 
> | Field  | Value
> |
> 
> +---+---+
> 
> | admin_state_up | True
> |
> 
> | allowed_address_pairs |
> |
> 
> | binding:host_id| ubuntu
> |
> 
> | binding:profile| {}
> |
> 
> | binding:vif_details   | {"port_filter": true, "ovs_hybrid_plug":
> true} |
> 
> | binding:vif_type   | ovs
> |
> 
> | binding:vnic_type | normal
> |
> 
> | device_id  | 724fc160-2b2e-597e-b9ed-7f65313cd73f
> |
> 
> | device_owner   | neutron:LOADBALANCER
> |
> 
> | extra_dhcp_opts|
> |
> 
> | fixed_ips  | {"subnet_id":
> "61ed9305-7b15-484a-b843-cb759aebc163", "ip_address": "30.0.0.138"} |
> 
> | id | 03a12958-656f-492b-8114-65d037ad6743
> |
> 
> | mac_address| fa:16:3e:ec:2e:3b
> |
> 
> | name   | vip-b2b11f89-48fc-4fd4-99f9-6f26977f353a
> |
> 
> | network_id | ef132b57-edc1-4d64-9591-38b80f73e23f
> |
> 
> | security_groups| 3365e9e0-4038-4800-b6b3-364b34e177d1
> |
> 
> | status | ACTIVE
> |
> 
> | tenant_id  | 3418d53683654d37b47caa1b66b72a21
> |
> 
> +---+---+
> 
> 
> 
> I cannot find the device_id anywhere as part of "nova list" or any
> other neutron command, what is this device_id referring to.
> 
> 
> Appreciate any response on this.
> 
> 
> Regards,
> 
> Surekha
> 
> 
> 
> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Brandon Logan]

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 in nova to mention specific endpoint?
> 
> On Sat, Feb 6, 2016 at 4:49 PM, pn kk  wrote:
> Hi,
> 
> 
> We want to have a deployment in which we use a single keystone
> instance, but multiple controllers having other openstack
> services(glance/nova/neutron...) running on each of the
> controllers.
> 
> 
> All these services would register their endpoints with single
> keystone.
> 
> 
> Please suggest a way in which I can point openstack clients to
> specific endpoint and access its services (don't want to use
> regions).
> 
> 
> Is this supported?
> 
> 
> I saw that heat, neutron APIs can take endpoint urls. Can I
> use these APIs to solve my purpose?
> 
> 
> >>> from heatclient.client import Client
> >>> heat = Client('1', endpoint=heat_url, token=auth_token)
> >>> from neutronclient.v2_0 import client
> >>> neutron = 
> client.Client(endpoint_url='http://192.168.206.130:9696/',
> token='d3f9226f27774f338019aa262ef6')
> Could you please also share the APIs of nova/glance which can
> take endpoint_urls?
> 
> 
> -Thanks
> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Brandon Logan]

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 large deployments but for large
deployers, custom tooling would probably be written for that.

3. Right now in devstack, the mgmt net is a single tenant network owned
by the octavia service account.  This means that a lot of deployments
would be limited to ~250 ports on that network (at least from our own
experience and other's we have talked to).  Deployers can also specify
that the mgmt network is a provider network which may not have that port
restriction.

Alternatively, we could create a mgmt net for each load balancer or each
tenant.  I feel like this would have scaling issues but I haven't
thought about it enough honestly.  Oh, one reason would be because,
right now, all controllers would have to be connected to all the mgmt
nets.  We've actually talked about how to solve this internally, but it
was more just impromptu whiteboarding sessions.

Thanks,
Brandon

On Mon, 2016-02-08 at 12:34 -0800, Michael Johnson wrote:
> 1. Octavia can run under it's own account with the required roles
> added to that account.
> 2. Currently the process would be to update the amphora image in
> glance and trigger a failover of the amphora.
> 3. It is required.  It is a private network between the Octavia
> controller and the amphora.  We would like to put the haproxy instance
> in it's own namespace be we are not there yet.
> 
> Michael
> 
> On Mon, Feb 8, 2016 at 7:55 AM, Major Hayden  wrote:
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA256
> >
> > Hey there,
> >
> > I've been doing some work to research how best to implement LBaaSv2 and 
> > Octavia within the OpenStack-Ansible project.  During that research, I've 
> > come up with a few questions.
> >
> > 1) Is it possible for octavia to operate without providing it with admin 
> > credentials?
> >
> > 2) If a user has amphora LB's deployed and a serious vulnerability is 
> > released for OpenSSL/haproxy, what should the user do to patch those load 
> > balancers?
> >
> > 3) Is a load balancer management network required?  Putting a LB onto an 
> > admin tenant network as well as a customer tenant network is challenging 
> > and bridging those networks could allow an attacker to gain access to other 
> > things on that admin tenant network.
> >
> > Thanks in advance for your time.
> >
> > - --
> > Major Hayden
> > -BEGIN PGP SIGNATURE-
> > Version: GnuPG v2
> >
> > iQIcBAEBCAAGBQJWuLpuAAoJEHNwUeDBAR+xSF8P/j/KBH2320xB/dGWmy6xOMuJ
> > DRQCcpEEljIu3O4pU8sF6yGEZX/CIoI3WXGaOBR2g0phWxEus5lhy0DdkPw4ctAa
> > +UJ7da/s0C7fDbbl09TvWDe3eBoohIunLOm6ABpMT48YipfM0zJLLDEy9kQpDcFg
> > qg68S5xgtC9zP9CeK1Gvsq5EwjwyX6Mt0a3+G1NMFbUoARLpDDof06YHrNFw73Td
> > 25AxqToR09yRRXsJfadrjjP9/lGWNBF5f5Oh5WoPnEAiThqN08Ico3geHKIr9s2r
> > Ift5NueWovCI5MUzOzqwsazKgnVgQXrgaaQwRotl5WdZbstUfWJLO+2If5/z4z8d
> > AArWLXwsCgIv+I6ZyJ4R3YzJVP3KBY8+8gDswjdMV4Jfy7YV9aragy96ofCEwjuH
> > p6QOGAKJZASD3cQpOdqVqQt4BaWBXMqm70sNDjfzKRBwweuOZgpNRInluDMbhngs
> > Yqdj2LGUhuij50gQLa21cYJ5pcuA6yY7KNoiiPLkNbFDJtQo6cjVt/McVFPxN3mu
> > RKRXpZNBgzf5UAKtrMIyPbw1wioAhbt7lgevfvCOLxHCmu0VxsLzRmOdiON5Exmg
> > vopL518GJSUx93GhA0cwnqT/ilcTvDxFxPXQrvQK/XPtEQq4U3wBF/kZALK1/4tu
> > 7hi/GjugHBcixIZGE5sI
> > =XI9V
> > -END PGP SIGNATURE-
> >
> > __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Brandon Logan]

What have we done?

On Fri, 2016-02-05 at 10:30 -0800, Stephen Balukoff wrote:
> Thanks guys! I appreciate the support and vote of confidence!
> 
> On Fri, Feb 5, 2016 at 9:16 AM, Michael Johnson <johnso...@gmail.com>
> wrote:
> That is quorum from the Octavia cores.
> 
> Congratulations Stephen!
> 
> Michael
> 
> On Fri, Feb 5, 2016 at 9:10 AM, Eichberger, German
> <german.eichber...@hpe.com> wrote:
> > +1
> >
> > From: Bertrand LALLAU
> <bertrand.lal...@gmail.com<mailto:bertrand.lal...@gmail.com>>
> > Reply-To: "OpenStack Development Mailing List (not for usage
> questions)"
> 
> <openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>>
> > Date: Friday, February 5, 2016 at 12:26 AM
> > To: "OpenStack Development Mailing List (not for usage
> questions)"
> 
> <openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>>
> > Subject: Re: [openstack-dev] [lbaas] [octavia] Proposing
> Stephen Balukoff as Octavia Core
> >
> > +1
> >
> > On Fri, Feb 5, 2016 at 3:10 AM, Doug Wiegley
>     <doug...@parksidesoftware.com<mailto:doug...@parksidesoftware.com>> 
> wrote:
> > +1
> >
> > Doug
> >
> >
> >> On Feb 4, 2016, at 7:06 PM, Brandon Logan
> <brandon.lo...@rackspace.com<mailto:brandon.lo...@rackspace.com>> 
> wrote:
> >>
> >> +1
> >>
> >>> On Fri, 2016-02-05 at 01:07 +, Adam Harwell wrote:
> >>> +1 from me!
> >>> 
> >>> From: Michael Johnson
> <johnso...@gmail.com<mailto:johnso...@gmail.com>>
> >>> Sent: Thursday, February 4, 2016 7:03 PM
> >>> To: OpenStack Development Mailing List (not for usage
> questions)
> >>> Subject: [openstack-dev] [lbaas] [octavia] Proposing
> Stephen Balukoff as Octavia Core
> >>>
> >>> Octavia Team,
> >>>
> >>> I would like to nominate Stephen Balukoff as a core
> reviewer for the
> >>> OpenStack Octavia project.  His contributions[1] are in
> line with
> >>> other cores and he has been an active member of our
> community.
> >>>
> >>> Octavia cores please vote by replying to this e-mail.
> >>>
> >>> Michael
> >>>
> >>> [1] http://stackalytics.com/report/contribution/octavia/90
> >>>
> >>>
> 
> __
> >>> OpenStack Development Mailing List (not for usage
> questions)
> >>> Unsubscribe:
> 
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe<http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe>
> >>>
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >>>
> >>>
> 
> __
> >>> OpenStack Development Mailing List (not for usage
> questions)
> >>> Unsubscribe:
> 
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe<http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe>
> >>>
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >>
> >>
> 
> __
> >> OpenStack Development Mailing List (not for usage
> questions)
> >> Unsubscribe:
> 
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe<http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe>
> >>
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> >
> 
> __
> > OpenStack Development Mailing List (not for usage questions)
>

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

[Brandon Logan]

+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] Proposing Stephen Balukoff as 
> Octavia Core
> 
> Octavia Team,
> 
> I would like to nominate Stephen Balukoff as a core reviewer for the
> OpenStack Octavia project.  His contributions[1] are in line with
> other cores and he has been an active member of our community.
> 
> Octavia cores please vote by replying to this e-mail.
> 
> Michael
> 
> [1] http://stackalytics.com/report/contribution/octavia/90
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Brandon Logan]

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 the os-interfaces one fails, then I think that'd be
best.

Thanks,
Brandon

On Fri, 2016-01-29 at 23:37 +, Eichberger, German wrote:
> 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 gather feedback 
> if there are cloud operators which don’t have/won't  the nova interface 
> extension enabled and need us to support os-networks in Mitaka and beyond.
> 
> Thanks,
> German
> 
> [1] https://review.openstack.org/#/c/273733/4
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Brandon Logan]

I could see it being interesting, but that would have to be something
vetted by other drivers and appliances because they may not support
that.

On Mon, 2016-01-25 at 21:37 +, Fox, Kevin M wrote:
> We are using a neutron v1 lb that has external to the cloud members in a lb 
> used by a particular tenant in production. It is working well. Hoping to do 
> the same thing once we get to Octavia+LBaaSv2.
> 
> Being able to tweak the routes of the load balancer would be an interesting 
> feature, though I don't think I'd ever need to. Maybe that should be an 
> extension? 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-dev@lists.openstack.org
> Subject: Re: [openstack-dev] [Neutron][LBaaS][Octavia] Should subnet be 
> optional on member create?
> 
> Any additional thoughts and opinions people want to share on this.  I
> don't have a horse in this race as long as we don't make dangerous
> assumptions about what the user wants.  So I am fine with making
> subnet_id optional.
> 
> Michael, how strong would your opposition for this be?
> 
> Thanks,
> Brandon
> 
> On Tue, 2016-01-19 at 20:49 -0800, Stephen Balukoff wrote:
> > Michael-- I think you're assuming that adding an external subnet ID
> > means that the load balancing service will route requests to out an
> > interface with a route to said external subnet. However, the model we
> > have is actually too simple to convey this information to the load
> > balancing service. This is because while we know the member's IP and a
> > subnet to which the load balancing service should connect to
> > theoretically talk to said IP, we don't have any kind of actual
> > routing information for the IP address (like, say a default route for
> > the subnet).
> >
> >
> > Consider this not far-fetched example: Suppose a tenant wants to add a
> > back-end member which is reachable only over a VPN, the gateway for
> > which lives on a tenant internal subnet. If we had a more feature-rich
> > model to work with here, the tenant could specify the member IP, the
> > subnet containing the VPN gateway and the gateway's IP address. In
> > theory the load balancing service could add local routing rules to
> > make sure that communication to that member happens on the tenant
> > subnet and gets routed to the VPN gateway.
> >
> >
> > If we want to support this use case, then we'd probably need to add an
> > optional gateway IP parameter to the member object. (And I'd still be
> > in favor of assuming the subnet_id on the member is optional, and that
> > default routing should be used if not specified.)
> >
> >
> > Let me see if I can break down several use cases we could support with
> > this model. Let's assume the member model contains (among other
> > things) the following attributes:
> >
> >
> > ip_address (member IP, required)
> > subnet_id (member or gateway subnet, optional)
> > gateway_ip (VPN or other layer-3 gateway that should be used to access
> > the member_ip. optional)
> >
> >
> > Expected behaviors:
> >
> >
> > Scenario 1:
> > ip_address specified, subnet_id and gateway_ip are None:  Load
> > balancing service assumes member IP address is reachable through
> > default routing. Appropriate for members that are not part of the
> > local cloud that are accessible from the internet.
> >
> >
> >
> > Scenario 2:
> > ip_address and subnet_id specified, gateway_ip is None: Load balancing
> > service assumes it needs an interface on subnet_id to talk directly to
> > the member IP address. Appropriate for members that live on tenant
> > networks. member_ip should exist within the subnet specified by
> > subnet_id. This is the only scenario supported under the current model
> > if we make subnet_id a required field and don't add a gateway_ip.
> >
> >
> > Scenario 3:
> > ip_address, subnet_id and gateway_ip are all specified:  Load
> > balancing service assumes it needs an interface on subnet_id to talk
> > to the gateway_ip. Load balancing service should add local routing
> > rule (ie. to the host and / or local network namespace context of the
> > load balancing service itself, not necessarily to Neutron or anything)
> > to route any packets destined for member_ip to the gateway_ip.
> > gateway_ip should exist within the subnet specified by subnet_id.
> > Appropriate for members that are on the other

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

[Brandon Logan]

Hi Kevin,

On Tue, 2016-01-26 at 19:48 +, Kevin Carter wrote:
> Seems like a sensible change however I'd love to see it written up as a spec. 
> Also do we know if there are any scenario tests in tempest for octavia or 
> would we need to develop them/something?

There aren't any tempest tests specific to Octavia right now but they
are being worked on.  We've been using the tempest tests written for
neutron-lbaas for this and its been okay but it leaves many gaps because
neutron-lbaas tests should not be aware of how a driver implements what
it does.  Tempest tests just for octavia would fill in all those gaps
and make the product much more stable.

There is an effort going on to create the tempest tests right now
though.  I hope we can get some in by M3 but its uncertain right now.

>  
> 
> As for adding Octavia as a new service within OpenStack Ansible this makes 
> sense. Another approach may be to add octavia to the existing neutron-agent 
> container which would making coordinating some of the services easier while 
> ensuring the service deployment is simpler but that has isolation and 
> segmentation drawback so i have no strong opinions on whats best. 
> 
> I personally think it'd be great to see this feature in OSA and I look 
> forward to reviewing the spec.
> 
> --
> 
> Kevin Carter
> IRC: cloudnull
> 
> 
> 
> From: Major Hayden <ma...@mhtx.net>
> Sent: Tuesday, January 26, 2016 1:40 PM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: [openstack-dev] [openstack-ansible] LBaaSv2 / Octavia support
> 
> Hey there,
> 
> After poking around a bit at LBaaS in OpenStack-Ansible, I discovered that 
> LBaaS v2[1] was available in Liberty and Mitaka.  At first, I thought it 
> involved switching agents from neutron-lbaas-agent to neutron-lbaasv2-agent, 
> but things are a little bit more involved.
> 
> LBaaS v1 works by configuring HAProxy within agent containers.  However, 
> LBaaS v2 creates virtual machines to hold load balancers and attaches those 
> virtual machines to the appropriate subnet.  It offers some active/passive 
> failover capabilities, but a single load balancer is the default.  One of the 
> biggest benefits of v2 is that you can put multiple 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
>   * Create members in the pool
> 
> Many thanks to Brandon Logan (blogan) for sitting down with me this morning 
> to go over it.  It looks like we'd need to do the following to get LBaaS v2 
> into OpenStack-Ansible:
> 
>   1) Build a new container to hold an Octavia venv
> 
>   2) Run four new daemons in that container:
> 
> * octavia-api
> * octavia-worker
> * octavia-housekeeping
> * octavia-health-manager
> 
>   3) Ensure that neutron-lbaas-agent isn't running at the same time as the 
> octavia stack
> 
>   4) Create a new RabbitMQ queue for octavia along with credentials
> 
>   5) Create a new MariaDB database for octavia along with credentials
> 
> At this moment, LBaaS v2 panels are planned for Horizon in Mitaka, but 
> they're not available as of right now.  It seems like a spec would be 
> necessary for this effort.
> 
> Are there users/deployers who would like to have this feature available?
> 
> [1] 
> http://docs.openstack.org/developer/devstack/guides/devstack-with-lbaas-v2.html
> 
> --
> Major Hayden
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Thanks,
Brandon
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Brandon Logan]

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 different agents which woudl have caused a much
larger refactor.  The v1 OR v2 requirement was basically a hack to get
around that.  Now that Octavia is the reference implementation and the
default, relaxing this restriction shouldn't cause any problems really.
Although, I don't want to 100% guarantee that because it's been a while
since I was in that world.

If that were relaxed, the v2 agent and v1 agent could still be run at
the same time which is something to think about.  Come to think about
it, we might want to revisit whether the v2 and v1 agent running
together is something that can be easily fixed because many things have
improved since then AND my knowledge has obviously improved a lot since
that time.

Glad yall brought this up.

Thanks,
Brandon


On Tue, 2016-01-26 at 14:07 -0600, Major Hayden wrote:
> On 01/26/2016 02:01 PM, Fox, Kevin M wrote:
> > I believe lbaas v1 and v2 are different then every other openstack api 
> > version in that while you can run v1 and v2 at the same time but they are 
> > completely different systems that just share a name. A lb created in v1 
> > doesn't show up in v2 or vis a versa. But being able to enable both at once 
> > gives users a migration path. If you don't do this, all their lb's will 
> > just disappear when going to octavia. :/
> 
> I tend to agree, but I'm hearing that it's not possible to run both versions 
> concurrently.  Brandon might be able to share a little more about the reasons 
> why.
> 
> --
> Major Hayden
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Brandon Logan]

I think you'll like that there will soon be a single create call for the
entire graph/tree of a load balancer so you can get those subnets up
front.  However, the API will still allow creating each entity
individually which you don't like. I have a feeling most clients and UIs
will use the single create call once its available over creating each
individual entity independently.  That should help out mostly.

Thanks,
Brandon

On Sun, 2016-01-17 at 09:05 +, Samuel Bercovici wrote:
> Btw.
> 
> I am still in favor on associating the subnets to the LB and then not specify 
> them per node at all.
> 
> -Sam.
> 
> 
> -Original Message-
> From: Samuel Bercovici [mailto:samu...@radware.com] 
> 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
> Subnet should be mandatory
> 
> The only thing this makes supporting load balancing servers which are not 
> running in the cloud more challenging to support.
> But I do not see this as a huge user story (lb in cloud load balancing IPs 
> outside the cloud)
> 
> -Sam.
> 
> -Original Message-
> From: Brandon 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 
> 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 vip on that 
> subnet, then the user does not need to specify the subnet for new member if 
> that new member is on one of those subnets.
> 
> At the midcycle we discussed it and we had an informal agreement that it 
> required too many assumptions on the part of the end user, neutron lbaas, and 
> driver.
> 
> If anyone wants to voice their opinion on this matter, do so on the bug 
> report, review, or in response to this thread.  Otherwise, it'll probably be 
> abandoned and not done at some point.
> 
> Thanks,
> Brandon
> 
> [1] https://bugs.launchpad.net/neutron/+bug/1426248
> [2] https://review.openstack.org/#/c/267935/
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Brandon Logan]

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 am fine with making
subnet_id optional.

Michael, how strong would your opposition for this be?

Thanks,
Brandon

On Tue, 2016-01-19 at 20:49 -0800, Stephen Balukoff wrote:
> Michael-- I think you're assuming that adding an external subnet ID
> means that the load balancing service will route requests to out an
> interface with a route to said external subnet. However, the model we
> have is actually too simple to convey this information to the load
> balancing service. This is because while we know the member's IP and a
> subnet to which the load balancing service should connect to
> theoretically talk to said IP, we don't have any kind of actual
> routing information for the IP address (like, say a default route for
> the subnet).
> 
> 
> Consider this not far-fetched example: Suppose a tenant wants to add a
> back-end member which is reachable only over a VPN, the gateway for
> which lives on a tenant internal subnet. If we had a more feature-rich
> model to work with here, the tenant could specify the member IP, the
> subnet containing the VPN gateway and the gateway's IP address. In
> theory the load balancing service could add local routing rules to
> make sure that communication to that member happens on the tenant
> subnet and gets routed to the VPN gateway.
> 
> 
> If we want to support this use case, then we'd probably need to add an
> optional gateway IP parameter to the member object. (And I'd still be
> in favor of assuming the subnet_id on the member is optional, and that
> default routing should be used if not specified.)
> 
> 
> Let me see if I can break down several use cases we could support with
> this model. Let's assume the member model contains (among other
> things) the following attributes:
> 
> 
> ip_address (member IP, required)
> subnet_id (member or gateway subnet, optional)
> gateway_ip (VPN or other layer-3 gateway that should be used to access
> the member_ip. optional)
> 
> 
> Expected behaviors:
> 
> 
> Scenario 1:
> ip_address specified, subnet_id and gateway_ip are None:  Load
> balancing service assumes member IP address is reachable through
> default routing. Appropriate for members that are not part of the
> local cloud that are accessible from the internet.
> 
> 
> 
> Scenario 2:
> ip_address and subnet_id specified, gateway_ip is None: Load balancing
> service assumes it needs an interface on subnet_id to talk directly to
> the member IP address. Appropriate for members that live on tenant
> networks. member_ip should exist within the subnet specified by
> subnet_id. This is the only scenario supported under the current model
> if we make subnet_id a required field and don't add a gateway_ip.
> 
> 
> Scenario 3:
> ip_address, subnet_id and gateway_ip are all specified:  Load
> balancing service assumes it needs an interface on subnet_id to talk
> to the gateway_ip. Load balancing service should add local routing
> rule (ie. to the host and / or local network namespace context of the
> load balancing service itself, not necessarily to Neutron or anything)
> to route any packets destined for member_ip to the gateway_ip.
> gateway_ip should exist within the subnet specified by subnet_id.
> Appropriate for members that are on the other side of a VPN links, or
> reachable via other local routing within a tenant network or local
> cloud.
> 
> 
> Scenario 4:
> ip_address and gateway_ip are specified, subnet_id is None: This is an
> invalid configuration.
> 
> 
> 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, so I'm fine with not supporting that kind of topology if nobody
> else wants it. I'm still in favor of making subnet_id optional, as
> this supports both Scenarios 1 and 2 above.
> 
> 
> Stephen
> 
> 
> 
> On Tue, Jan 19, 2016 at 7:09 PM, Brandon Logan
> <brandon.lo...@rackspace.com> wrote:
> So it really comes down to driver (or driver's appliance)
> implementation.  Here's some scenarios to consider:
> 
> 1) vip on tenant network, members on tenant network
> - if a user wants to add an external IP to this configuration,
> how do we
> handle that?  If the subnet is optional the it just uses the
> default
> routing, then it won't ever get external unless the backend
> implementation sets up routing to extern

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

[Brandon Logan]

t;>> specify them per node at all.
> >>>> 
> >>>> -Sam.
> >>>> 
> >>>> 
> >>>> -Original Message-
> >>>> From: Samuel Bercovici [mailto:samu...@radware.com]
> >>>> Sent: Sunday, January 17, 2016 10:14 AM
> >>>> To: OpenStack Development Mailing List (not for usage questions)
> >>>> Subject: Re: [openstack-dev] [Neutron][LBaaS][Octavia] Should subnet be
> >>>> optional on member create?
> >>>> 
> >>>> +1
> >>>> Subnet should be mandatory
> >>>> 
> >>>> The only thing this makes supporting load balancing servers which are not
> >>>> running in the cloud more challenging to support.
> >>>> But I do not see this as a huge user story (lb in cloud load balancing
> >>>> IPs outside the cloud)
> >>>> 
> >>>> -Sam.
> >>>> 
> >>>> -Original Message-
> >>>> From: Brandon 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 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 vip on 
> >>>> that
> >>>> subnet, then the user does not need to specify the subnet for new member 
> >>>> if
> >>>> that new member is on one of those subnets.
> >>>> 
> >>>> At the midcycle we discussed it and we had an informal agreement that it
> >>>> required too many assumptions on the part of the end user, neutron lbaas,
> >>>> and driver.
> >>>> 
> >>>> If anyone wants to voice their opinion on this matter, do so on the bug
> >>>> report, review, or in response to this thread.  Otherwise, it'll 
> >>>> probably be
> >>>> abandoned and not done at some point.
> >>>> 
> >>>> Thanks,
> >>>> Brandon
> >>>> 
> >>>> [1] https://bugs.launchpad.net/neutron/+bug/1426248
> >>>> [2] https://review.openstack.org/#/c/267935/
> >>> 
> >>>>> __
> >>>> OpenStack Development Mailing List (not for usage questions)
> >>>> Unsubscribe:
> >>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> >>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >>>> 
> >>> 
> >>>>> __
> >>>> OpenStack Development Mailing List (not for usage questions)
> >>>> Unsubscribe:
> >>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> >>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >>>> 
> >>> 
> >>>>> __
> >>>> OpenStack Development Mailing List (not for usage questions)
> >>>> Unsubscribe:
> >>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> >>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >>> __
> >>> OpenStack Development Mailing List (not for usage questions)
> >>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >> 
> >> 
> >> 
> >> 
> >> --
> >> Stephen Balukoff
> >> Principal Technologist
> >> Blue Box, An IBM Company
> >> www.blueboxcloud.com
> >> sbaluk...@blueboxcloud.com
> >> 206-607-0660 x807
> >> 
> >> __
> >> OpenStack Development Mailing List (not for usage questions)
> >> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >> 
> > 
> > __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Brandon Logan]

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 vip on
that subnet, then the user does not need to specify the subnet for new
member if that new member is on one of those subnets.

At the midcycle we discussed it and we had an informal agreement that it
required too many assumptions on the part of the end user, neutron
lbaas, and driver.

If anyone wants to voice their opinion on this matter, do so on the bug
report, review, or in response to this thread.  Otherwise, it'll
probably be abandoned and not done at some point.

Thanks,
Brandon

[1] https://bugs.launchpad.net/neutron/+bug/1426248
[2] https://review.openstack.org/#/c/267935/
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Brandon Logan]

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!
> 
> Based on the fact that we have a spec for a v2 API - the question
> becomes - how do we not break all this?
> 
> I see that LBaaS went the route of
> 
> v1 api = "/lb"
> v2 api = "/lbaas"
> 
> https://github.com/openstack/neutron-lbaas/blob/master/neutron_lbaas/extensions/loadbalancer.py#L32
> 
> https://github.com/openstack/neutron-lbaas/blob/master/neutron_lbaas/extensions/loadbalancerv2.py#L34
> 

Yeah, this was kind of a best bad option at the time.

> So - I guess we take the same route with FwaaS - maybe have the endpoint
> at "/fwaas" and then hopefully we can implement microversioning[3]? That
> way, we never have to make another endpoint like "/firewall" if we come up 
> with a v3 API in the 2020s.

I hope too that microversioning will fix this as well, but I'm not so
sure it will as it is proposed.  I might be overlooking something but I
can't seem how a neutron microversion can handle both neutron's api and
a fwaas/lbaas/vpnaas api that may or may not be enabled.

Definitely needs more discussion though, because it would be nice if it
does solve this problem.

> 
> [1]: http://tech.paulcz.net/2016/01/openstacks-and-ecosystems/
> 
> [2]: https://terraform.io/docs/providers/openstack/r/fw_firewall_v1.html
> 
> [3]: 
> http://specs.openstack.org/openstack/nova-specs/specs/kilo/implemented/api-microversions.html
> 

Thanks,
Brandon
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Brandon Logan]

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 the allowed values for each of
> provisioning_status and operating status. Here it seems the
> documentation is ambiguous. [1] provides a list of possible statuses,
> but does not mention if they are options for provisioning_status or
>  operating_status. [2] provides much clearer options for each status,
> but does not show the INACTIVE status mention in [1]. Should INACTIVE
> be included in the possible options for one of the statuses, or should
> it be removed from [1] altogether?

Yeah this needs to be better documented.  I would say all of those
statuses in the docs pertain to provisioning_status, except for
INACTIVE, which I'm actually not sure where that is being used.  I have
to plead ignorance on this.  I was initially thinking operating_status
but I don't see it being used.  So that probably needs to just be pulled
out of the docs entirely.  The operating_status statuses are listed in
code here [1].  They are pretty self explanatory, except for maybe
DEGRADED.  DEGRADED basically means that one or more of its descendants
are in an OFFLINE operating_status.  NO_MONITOR means no health monitor
so operating_status can't be evaluated.  DISABLED means admin_state_up
on that entity is set to False.

> 
> Second, [1] also mentions that an error_details attribute will be
> provided if the status is ERROR. I do not see any error_details
> attribute in the LoadBalancer code [3], so I am wondering where that
> attribute comes from?

This is actually something that was in v1 (status_description) that we
have not added to v2.  It would be nice to have but its not there yet.
The docs should be updated to remove this.
> 
> Finally, I'm curious what operations can be performed on the
> LoadBalancer if the operating_status is OFFLINE and the
> provisioning_status is ACTIVE. First is this state possible? And
> second, can the LoadBalancer be manipulated (i.e. add a Listener to
> the LoadBalancer) if it is in this state?

Operations on a load balancer are only restricted based on the
provisioning_status.  operating_status is purely for information.  If
the load balancer's provisioning status is ACTIVE then you can do any
operation on it, regardless of operating_status.

I don't know of a current scenario where ACTIVE/OFFLINE status is
actually possible for a load balancer, but a driver could decide to do
that, though I'd like to understand that use case first.

> 
> [1]
> http://developer.openstack.org/api-ref-networking-v2-ext.html#lbaas-v2.0
> [2]
> http://developer.openstack.org/api-ref-networking-v2-ext.html#showLoadBalancerv2
> [3]
> https://github.com/openstack/neutron-lbaas/blob/master/neutron_lbaas/services/loadbalancer/data_models.py#L503
> 
> Thanks,
> 
> BRYAN JONES
> Software Engineer - OpenStack Development
> 
> ___
> Phone: 1-507-253-2620
> E-mail: jone...@us.ibm.com
> Find me on: LinkedIn:
> http://www.linkedin.com/in/bjones17/
> IBM
> 
>   3605 Hwy 52 N
>Rochester, MN 55901-1407
>   United States
> 
> 
> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


[1]
https://github.com/openstack/neutron-lbaas/blob/master/neutron_lbaas/services/loadbalancer/constants.py#L100

Thanks,
Brandon
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Brandon Logan]

Looks like that is only for v1 though.

On Tue, 2015-12-15 at 05:38 +, Phillip Toohill wrote:
> >Yeah this needs to be better documented.  I would say all of those
> >statuses in the docs pertain to provisioning_status, except for
> >INACTIVE, which I'm actually not sure where that is being used. ...
> 
> There is this patch to utilize the INACTIVE status: 
> https://review.openstack.org/#/c/255875/ 
> 
> 
> ________
> From: Brandon Logan <brandon.lo...@rackspace.com>
> Sent: Monday, December 14, 2015 6:25 PM
> To: openstack-dev@lists.openstack.org
> Subject: 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 the allowed values for each of
> > provisioning_status and operating status. Here it seems the
> > documentation is ambiguous. [1] provides a list of possible statuses,
> > but does not mention if they are options for provisioning_status or
> >  operating_status. [2] provides much clearer options for each status,
> > but does not show the INACTIVE status mention in [1]. Should INACTIVE
> > be included in the possible options for one of the statuses, or should
> > it be removed from [1] altogether?
> 
> Yeah this needs to be better documented.  I would say all of those
> statuses in the docs pertain to provisioning_status, except for
> INACTIVE, which I'm actually not sure where that is being used.  I have
> to plead ignorance on this.  I was initially thinking operating_status
> but I don't see it being used.  So that probably needs to just be pulled
> out of the docs entirely.  The operating_status statuses are listed in
> code here [1].  They are pretty self explanatory, except for maybe
> DEGRADED.  DEGRADED basically means that one or more of its descendants
> are in an OFFLINE operating_status.  NO_MONITOR means no health monitor
> so operating_status can't be evaluated.  DISABLED means admin_state_up
> on that entity is set to False.
> 
> >
> > Second, [1] also mentions that an error_details attribute will be
> > provided if the status is ERROR. I do not see any error_details
> > attribute in the LoadBalancer code [3], so I am wondering where that
> > attribute comes from?
> 
> This is actually something that was in v1 (status_description) that we
> have not added to v2.  It would be nice to have but its not there yet.
> The docs should be updated to remove this.
> >
> > Finally, I'm curious what operations can be performed on the
> > LoadBalancer if the operating_status is OFFLINE and the
> > provisioning_status is ACTIVE. First is this state possible? And
> > second, can the LoadBalancer be manipulated (i.e. add a Listener to
> > the LoadBalancer) if it is in this state?
> 
> Operations on a load balancer are only restricted based on the
> provisioning_status.  operating_status is purely for information.  If
> the load balancer's provisioning status is ACTIVE then you can do any
> operation on it, regardless of operating_status.
> 
> I don't know of a current scenario where ACTIVE/OFFLINE status is
> actually possible for a load balancer, but a driver could decide to do
> that, though I'd like to understand that use case first.
> 
> >
> > [1]
> > http://developer.openstack.org/api-ref-networking-v2-ext.html#lbaas-v2.0
> > [2]
> > http://developer.openstack.org/api-ref-networking-v2-ext.html#showLoadBalancerv2
> > [3]
> > https://github.com/openstack/neutron-lbaas/blob/master/neutron_lbaas/services/loadbalancer/data_models.py#L503
> >
> > Thanks,
> >
> > BRYAN JONES
> > Software Engineer - OpenStack Development
> >
> > ___
> > Phone: 1-507-253-2620
> > E-mail: jone...@us.ibm.com
> > Find me on: LinkedIn:
> > http://www.linkedin.com/in/bjones17/
> > IBM
> >
> >   3605 Hwy 52 N
> >Rochester, MN 55901-1407
> >   United States
> >
> >
> >
> >
> > __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lis

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

[Brandon Logan]

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 collect all releasenotes there. But I think it makes sense to
> have releasenotes in the *aaS repositories as well.
> 
> What I'm going to propose is we cut Neutron M-1 as-is now, with any
> *aaS releasenotes done in the main repository. Once Neutron M-1 is
> cut, I'll add the releasenotes stuff into the *aaS repositories, and
> we can start using releasenotes independently in those repositories.
> 
> If anyone has issues with this approach please reply on this thread.
> 
> Thanks!
> Kyle
> 
> [1] https://review.openstack.org/#/c/251959/
> [2] https://review.openstack.org/241758
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Brandon Logan]

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 Astara driver:
>   https://review.openstack.org/#/c/230699/
> 
> Add tap-as-a-service:
>   https://review.openstack.org/#/c/229869/
> 
> On 11/30/2015 07:56 PM, Armando M. wrote:
> > I would like to suggest that we evolve the structure of the Neutron
> > governance, so that most of the deliverables that are now part of the
> > Neutron stadium become standalone projects that are entirely
> > self-governed (they have their own core/release teams, etc). In order to
> > denote the initiatives that are related to Neutron I would like to
> > present two new tags that projects can choose to label themselves with:
> > 
> >   * 'is-neutron-subsystem': this means that the project provides
> > networking services by implementing an integral part (or parts) of
> > an end-to-end neutron system. Examples are: a service plugin, an ML2
> > mech driver, a monolithic plugin, an agent etc. It's something an
> > admin has to use in order to deploy Neutron in a certain configuration.
> >   * 'use-neutron-system': this means that the project provides
> > networking services by using a pre-deployed end-to-end neutron
> > system as is. No modifications whatsoever.
> 
> I just want to clarify the proposal.  IIUC, you propose splitting most
> of what is currently separately deliverables of the Neutron team and
> making them separate projects in terms of OpenStack governance.  When I
> originally proposed including networking-ovn under Neutron (and more
> generally, making room for all drivers to be included), making them
> separate projects was one of the options on the table, but it didn't
> seem best at the time.  For reference, that thread was here:
> 
> http://lists.openstack.org/pipermail/openstack-dev/2015-April/062310.html
> 
> When I was originally proposing this, I was only thinking about Neutron
> drivers, the stuff that connects Neutron to some other system to make
> Neutron do something.  The list has grown to include other things, as well.
> 
> I'm not sure where you propose the line to be, but for the sake of
> discussion, let's assume every deliverable in the governance definition
> for Neutron is under consideration for being split out with the
> exception of neutron, neutron-specs, and python-neutronclient.  The
> remaining deliverables are:
> 
> dragonflow:
> kuryr:
> networking-ale-omniswitch:
> networking-arista:
> networking-bgpvpn:
> networking-calico:
> networking-cisco:
> networking-fortinet:
> networking-hpe:
> networking-hyperv:
> networking-infoblox:
> networking-fujitsu:
> networking-l2gw:
> networking-lenovo:
> networking-midonet:
> networking-odl:
> networking-ofagent:
> networking-onos:
> networking-ovn:
> networking-plumgrid:
> networking-powervm:
> networking-sfc:
> networking-vsphere:
> octavia:
> python-neutron-pd-driver:
> vmware-nsx:
> 
> I think it's helpful to break these into categories, because the answer
> may be different for each group.  Here's my attempt at breaking this
> list into some categories:
> 
> 1) A consumer of Neutron
> 
> kuryr
> 
> IIUC, kuryr is a consumer of Neutron.  Its interaction with Neutron is
> via using Neutron's REST APIs.  You could think of kuryr's use of
> Neutron as architecturally similar to how Nova uses Neutron.
> 
> I think this project makes a ton of sense to become independent.
> 
> 2) Implementation of a networking technology
> 
> dragonflow
> 
> The dragonflow repo includes a couple of things.  It includes dragonflow
> itself, and the Neutron driver to connect to it.  Using Astara as an
> example to follow, dragonflow itself could be an independent project.
> 
> Following that, the built-in ML2/ovs or ML2/lb control plane could be
> separate, too, though that's much more painful and complex in practice.
> 
> octavia
> 
> Octavia also seems to fall into this category, just for LBaaS.  It's not
> just a driver, it's a LBaaS service VM orchestrator (which is in part
> what Astara is, too).

Actually I would put Octavia in #1 as it only interacts with neutron
through its REST API.  There is a neutron-lbaas octavia driver that
simply just calls the Octavia REST API, but it lives in the
neutron-lbaas tree.  Octavia is standalone and consumes all openstack
services through their REST APIs.

> 
> It seems reasonable to propose these as independent projects.
> 
> 3) New APIs
> 
> There are some repos that are implementing new REST APIs for Neutron.
> They're independent enough to need their own driver layer, but coupled
> with Neutron enough to still need to run inside of Neutron as they can't
> do everything they need to do by only 

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

[Brandon Logan]

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


On 24 November 2015 at 21:46, Akihiro Motoki 
> wrote:
Hi,

Neutron has now various subprojects and some of them would like to
implement Horizon supports. Most of them are additional features.
I would like to start the discussion where we should have horizon support.

[Background]
Horizon team introduced a plugin mechanism and we can add horizon panels
from external repositories. Horizon team is recommending external repos for
additional services for faster iteration and features.
We have various horizon related repositories now [1].

In Neutron related world, we have neutron-lbaas-dashboard and
horizon-cisco-ui repos.

[Possible options]
There are several possible options for neutron sub-projects.
My current vote is (b), and the next is (a). It looks a good balance to me.
I would like to gather broader opinions,

(a) horizon in-tree repo
- [+] It was a legacy approach and there is no initial effort to setup a repo.
- [+] Easy to share code conventions.
- [-] it does not scale. Horizon team can be a bottleneck.

(b) a single dashboard repo for all neutron sub-projects
- [+] No need to set up a repo by each sub-project
- [+] Easier to share the code convention. Can get horizon reviewers.
- [-] who will be a core reviewer of this repo?

(c) neutron sub-project repo

All circumstances considered, I think c) is the only viable one.

+1

- [+] Each sub-project can develop a dashboard fast.
- [-] It is doable, but the directory tree can be complicated.

why? do you envision something else other than /horizon directory in the tree?

- [-] Lead to too many repos and the horizon team/liaison cannot cover all.

If that's true for horizon, shouldn't the same be true for the neutron team :)? 
IMO, the level of feedback/oversight provided is always going to be constant 
(you can't clone people) no matter how the efforts are distributed. I'd rather 
empower the individual projects.

+1000

Option C seems like the way forward here.


(d) a separate repo per neutron sub-project
Similar to (c)
- [+] A dedicate repo for dashboard simplifies the directory tree.
- [-] Need to setup a separate repo.
- [-] Lead to too many repos and the horizon team/liaison cannot cover all.

Note that this mail is not intended to move the current neutron
support in horizon
to outside of horizon tree. I would like to discuss Horizon support of
additional features.

Akihiro

[1] http://docs.openstack.org/developer/horizon/plugins.html

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


 I have to agree with C) as well.  I do worry about the scope of the projects 
becoming way too large though.  If this continues these projects are going to 
need to have people that are SMEs in all things OR implement something like the 
Lt system main neutron has right now.  I'm OK crossing that bridge when we get 
to it though.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Brandon Logan]

+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 sub project. His 
> contributions [1] are in line with other cores and he has been an active 
> member of our community. Current cores please vote by replying to this e-mail.
> 
> Thanks,
> German 
> 
> 
> [1] http://stackalytics.com/?project_type=openstack=octavia
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Brandon Logan]

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 Octavia the project it is 
> today. Brandon will be dedicating more of his time to other parts of Neutron 
> and I will be splitting my time between FWaaS, Octavia, and internal 
> projects. 
> 
> Doug (cc’d )has graciously agreed to hold the election and will send out 
> details on voting in due time. We are encouraging everyone who wants to be 
> considered to submit his/her candidacy to the ML. The Octavia team has a deep 
> talent pool and two great candidates Michael and Stephen already stepped 
> forward [1]. We are excited to work with the new PTL in the future.
> 
> Lastly, due to the Thanksgiving Holidays we are skipping next week meeting.
> 
> Happy Holidays,
> German + Brandon
> 
> [1] 
> http://eavesdrop.openstack.org/meetings/octavia/2015/octavia.2015-11-18-20.00.log.html
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Brandon Logan]

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, 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 Octavia the project it is 
> today. Brandon will be dedicating more of his time to other parts of Neutron 
> and I will be splitting my time between FWaaS, Octavia, and internal 
> projects. 
> 
> Doug (cc’d )has graciously agreed to hold the election and will send out 
> details on voting in due time. We are encouraging everyone who wants to be 
> considered to submit his/her candidacy to the ML. The Octavia team has a deep 
> talent pool and two great candidates Michael and Stephen already stepped 
> forward [1]. We are excited to work with the new PTL in the future.
> 
> Lastly, due to the Thanksgiving Holidays we are skipping next week meeting.
> 
> Happy Holidays,
> German + Brandon
> 
> [1] 
> http://eavesdrop.openstack.org/meetings/octavia/2015/octavia.2015-11-18-20.00.log.html
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Brandon Logan]

+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 determined that the tests fail because they
> >>> assume
> >>> neutron/liberty code, but actually run against neutron/master (that does
> >>> not
> >>> have that neutron.plugins.embrane.* namespace because the plugin was
> >>> removed
> >>> in Mitaka).
> >>>
> >>> I then compared how we fetch neutron in gate and in periodic jobs, and I
> >>> see
> >>> that ZUUL branch is not set in the latter jobs.
> >>
> >> [...]
> >>
> >> Short answer is that the periodic trigger in Zuul is changeless and
> >> thus branchless. It just wakes up at the specified time and starts a
> >> list of jobs associated with that pipeline for any projects. This is
> >> why the working periodic jobs have different names than their gerrit
> >> triggered pipeline equivalents... they need to hard-code a branch
> >> (usually as a JJB parameter).
> >> --
> >> Jeremy Stanley
> >
> >
> > UPD: we discussed the matter with Jeremy in irc in more details and came up
> > to agreement that the best way is actually modifying tools/tox_install.sh in
> > neutron-lbaas (and other projects affected) to set ZUUL_BRANCH if not passed
> > from Jenkins.
> >
> > For neutron-lbaas, I came up with the following patch:
> > https://review.openstack.org/#/c/24/
> >
> > Once it’s validated and reviewed, I will propose some more for other
> > projects (I believe at least vpnaas should be affected).
> >
> > Once it’s merged in master, I will propose backports for Liberty.
> 
> Great work Ihar, thanks for taking this on.
> 
> >
> > Ihar
> > __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Brandon Logan]

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 the meeting to 16:00 UTC on Wednesday. Please respond to this e-mail
> if you have alternate suggestions. I will send out another e-mail
> announcing the new time and the date we will start with that.
> 
> Thanks,
> German
> 
> [1] 
> http://eavesdrop.openstack.org/meetings/octavia/2015/octavia.2015-09-23-20.
> 00.log.html
> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Brandon Logan]

There is some overlap, but there was some incompatible differences when
we started designing v2.  I'm sure the same issues will arise this time
around so new resources sounds like the path to go.  However, I do not
know much about Heat and the resources so I'm speaking on a very
uneducated level here.

Thanks,
Brandon
On Tue, 2015-09-22 at 18:38 +, Fox, Kevin M wrote:
> We're using the v1 resources...
> 
> If the v2 ones are compatible and can seamlessly upgrade, great
> 
> Otherwise, make new ones please.
> 
> Thanks,
> Kevin
> 
> __
> From: Banashankar KV [banvee...@gmail.com]
> Sent: Tuesday, September 22, 2015 10:07 AM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [neutron][lbaas] - Heat support for
> 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 22, 2015 at 9:18 AM, Brandon Logan
> <brandon.lo...@rackspace.com> wrote:
> 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 starting the work on heat to support
> LBaasV2,  Is
> > there any concerns about that?
> >
> >
> > I don't know if it is the right time to bring this up :D .
> >
> > Thanks,
> > Banashankar (bana_k)
> >
> >
> 
> >
> 
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> >
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Brandon Logan]

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 starting the work on heat to support LBaasV2,  Is
> there any concerns about that?
> 
> 
> I don't know if it is the right time to bring this up :D . 
> 
> Thanks,
> Banashankar (bana_k)
> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Brandon Logan]

I do like Doug's suggestion of namespace change.  One day lbaas will no
longer be an extension of neutron (at least that is my hope and it seems
to be going in that direction), and thus the only reason to be
considered part of neutron is just a logical grouping of networking
services.

Cutting the rant short, is that namespace change enough to avoid all
naming collisions between v1 and v2?

Thanks,
Brandon
On Tue, 2015-09-22 at 17:00 -0700, Banashankar KV wrote:
> But whatever it is, I think we can't run the current heat template  as
> it is for v2, those things must be ported no matter what.  
> So I think our main concern here is coexistence of v1 and v2 heat
> support. 
> 
> 
> Please correct me if I am wrong.
> 
> Thanks 
> Banashankar
> 
> 
> 
> On Tue, Sep 22, 2015 at 4:53 PM, Doug Wiegley
> <doug...@parksidesoftware.com> wrote:
> The other option would be to change the namespace.  (Os::Lbaas
> instead of Os::Neutron).  The neutron CLI does something
> similar with neutron-lb-* versus neutron-lbaas-*, e.g.
> 
> 
> One wrinkle with heat supporting both is that neutron doesn’t
> support both running at the same time, which certainly hurts
> the migration strategy. I think the answer at the time was
> that you could have different api servers running each
> version. Is that something that heat can deal with?
> 
> 
> (I still don’t like that I can’t run both at the same time,
> and would love to re-litigate that argument.  :-)  ).
> 
> 
> Thanks,
> doug
> 
> 
> 
> 
> > On Sep 22, 2015, at 5:40 PM, Banashankar KV
> > <banvee...@gmail.com> wrote:
> > 
> > Ok, sounds good. So now the question is how should we name
> > the new V2 resources ?
> > 
> > 
> > 
> > Thanks 
> > Banashankar
> > 
> > 
> > 
> > On Tue, Sep 22, 2015 at 4:33 PM, Fox, Kevin M
> > <kevin@pnnl.gov> wrote:
> > Yes, hence the need to support the v2 resources as
> > seperate things. Then I can rewrite the templates to
> > include the new resources rather then the old
> > resources as appropriate. IE, it will be a porting
> > effort to rewrite them. Then do a heat update on the
> > stack to migrate it from lbv1 to lbv2. Since they
> > are different resources, it should create the new
> > and delete the old.
> > 
> > Thanks,
> > Kevin
> > 
> > 
> > 
> > From: Banashankar KV [banvee...@gmail.com]
> > Sent: Tuesday, September 22, 2015 4:16 PM
> > 
> > To: OpenStack Development Mailing List (not for
> > usage questions)
> > Subject: Re: [openstack-dev] [neutron][lbaas] - Heat
> > support for LbaasV2
> > 
> > 
> > 
> > 
> > But I think, V2 has introduced some new components
> > and whole association of the resources with each
> > other is changed, we should be still able to do what
> > Kevin has mentioned ?
> > 
> > Thanks  
> > Banashankar
> > 
> > 
> > 
> > On Tue, Sep 22, 2015 at 3:39 PM, Fox, Kevin M
> > <kevin@pnnl.gov> wrote:
> > There needs to be a way to have both v1 and
> > v2 supported in one engine
> > 
> > Say I have templates that use v1 already in
> > 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
> > path.
> >  

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

[Brandon Logan]

So for the API v1s api is of the structure:

/lb/(vip|pool|member|health_monitor)

V2s is:
/lbaas/(loadbalancer|listener|pool|healthmonitor)

member is a child of pool, so it would go down one level.

The only difference is the lb for v1 and lbaas for v2.  Not sure if that
is enough of a different.

Thanks,
Brandon
On Tue, 2015-09-22 at 23:48 +, Fox, Kevin M wrote:
> Thats the problem. :/
> 
> I can't think of a way to have them coexist without: breaking old
> templates, including v2 in the name, or having a flag on the resource
> saying the version is v2. And as an app developer I'd rather not have
> my existing templates break.
> 
> I haven't compared the api's at all, but is there a required field of
> v2 that is different enough from v1 that by its simple existence in
> the resource you can tell a v2 from a v1 object? Would something like
> that work? PoolMember wouldn't have to change, the same resource could
> probably work for whatever lb it was pointing at I'm guessing.
> 
> Thanks,
> Kevin
> 
> 
> 
> __
> From: Banashankar KV [banvee...@gmail.com]
> Sent: Tuesday, September 22, 2015 4:40 PM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [neutron][lbaas] - Heat support for
> LbaasV2
> 
> 
> 
> Ok, sounds good. So now the question is how should we name the new V2
> resources ? 
> 
> 
> 
> Thanks  
> Banashankar
> 
> 
> 
> On Tue, Sep 22, 2015 at 4:33 PM, Fox, Kevin M <kevin@pnnl.gov>
> wrote:
> Yes, hence the need to support the v2 resources as seperate
> things. Then I can rewrite the templates to include the new
> resources rather then the old resources as appropriate. IE, it
> will be a porting effort to rewrite them. Then do a heat
> update on the stack to migrate it from lbv1 to lbv2. Since
> they are different resources, it should create the new and
> delete the old.
> 
> Thanks,
> Kevin
> 
> 
> __
> From: Banashankar KV [banvee...@gmail.com]
> Sent: Tuesday, September 22, 2015 4:16 PM 
> 
> To: OpenStack Development Mailing List (not for usage
> questions)
> Subject: Re: [openstack-dev] [neutron][lbaas] - Heat support
> for LbaasV2
> 
> 
> 
> 
> But I think, V2 has introduced some new components and whole
> association of the resources with each other is changed, we
> should be still able to do what Kevin has mentioned ?
> 
> Thanks  
> Banashankar
> 
> 
> 
> On Tue, Sep 22, 2015 at 3:39 PM, Fox, Kevin M
> <kevin@pnnl.gov> wrote:
> There needs to be a way to have both v1 and v2
> supported in one engine
> 
> Say I have templates that use v1 already in 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 path.
> 
> Thanks,
> Kevin
> 
> From: Brandon Logan [brandon.lo...@rackspace.com]
> Sent: Tuesday, September 22, 2015 3:22 PM
> To: openstack-dev@lists.openstack.org
> Subject: Re: [openstack-dev] [neutron][lbaas] - Heat
> support for LbaasV2
> 
> Well I'd hate to have the V2 postfix on it because V1
> will be deprecated
> and removed, which means the V2 being there would be
> lame.  Is there any
> kind of precedent set for for how to handle this?
> 
> Thanks,
> Brandon
> On Tue, 2015-09-22 at 14:49 -0700, Banashankar KV
> wrote:
> > So are we thinking of making it as ?
> > OS::Neutron::LoadBalancerV2
> >
> > OS::Neutron::ListenerV2
> >
> > OS::Neutron::PoolV2
> >
> > OS::Neutron::PoolMemberV2
> >
> > OS::Neutron::HealthMonitorV2
>  

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

[Brandon Logan]

Well I'd hate to have the V2 postfix on it because V1 will be deprecated
and removed, which means the V2 being there would be lame.  Is there any
kind of precedent set for for how to handle this?

Thanks,
Brandon
On Tue, 2015-09-22 at 14:49 -0700, Banashankar KV wrote:
> So are we thinking of making it as ?
> OS::Neutron::LoadBalancerV2
> 
> OS::Neutron::ListenerV2
> 
> OS::Neutron::PoolV2
> 
> OS::Neutron::PoolMemberV2
> 
> OS::Neutron::HealthMonitorV2
> 
> 
> 
> and add all those into the loadbalancer.py of heat engine ?
> 
> Thanks 
> Banashankar
> 
> 
> 
> On Tue, Sep 22, 2015 at 12:52 PM, Sergey Kraynev
> <skray...@mirantis.com> wrote:
> Brandon.
> 
> 
> As I understand we v1 and v2 have differences also in list of
> objects and also in relationships between them.
> So I don't think that it will be easy to upgrade old resources
> (unfortunately). 
> I'd agree with second Kevin's suggestion about implementation
> new resources in this case.
> 
> 
> I see, that a lot of guys, who wants to help  with it :) And I
> suppose, that me and Rabi Mishra may try to help with it,
> because we was involvement in implementation of v1 resources
> in Heat.
> Follow the list of v1 lbaas resources in Heat:
> 
> 
> 
> http://docs.openstack.org/developer/heat/template_guide/openstack.html#OS::Neutron::LoadBalancer
> 
> http://docs.openstack.org/developer/heat/template_guide/openstack.html#OS::Neutron::Pool
> 
> 
> http://docs.openstack.org/developer/heat/template_guide/openstack.html#OS::Neutron::PoolMember
> 
> 
> http://docs.openstack.org/developer/heat/template_guide/openstack.html#OS::Neutron::HealthMonitor
> 
> 
> 
> Also, I suppose, that it may be discussed during summit
> talks :)
>     Will add to etherpad with potential sessions.
> 
> 
> 
> Regards,
> Sergey.
> 
> On 22 September 2015 at 22:27, Brandon Logan
> <brandon.lo...@rackspace.com> wrote:
> There is some overlap, but there was some incompatible
> differences when
> we started designing v2.  I'm sure the same issues
> will arise this time
> around so new resources sounds like the path to go.
> However, I do not
> know much about Heat and the resources so I'm speaking
> on a very
> uneducated level here.
> 
> Thanks,
> Brandon
> On Tue, 2015-09-22 at 18:38 +, Fox, Kevin M wrote:
> > We're using the v1 resources...
> >
> > If the v2 ones are compatible and can seamlessly
> upgrade, great
> >
> > Otherwise, make new ones please.
> >
> > Thanks,
> > Kevin
> >
> >
> 
> __
> > From: Banashankar KV [banvee...@gmail.com]
> > Sent: Tuesday, September 22, 2015 10:07 AM
> > To: OpenStack Development Mailing List (not for
> usage questions)
> > Subject: Re: [openstack-dev] [neutron][lbaas] - Heat
> support for
> > 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 22, 2015 at 9:18 AM, Brandon Logan
> > <brandon.lo...@rackspace.com> wrote:
> > Hi Banashankar,
> > I think it'd be great if you got this going.
> One of those
> > things we
> >  

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

[Brandon Logan]

Forgive my ignorance on this, but by resources are we talking about API
resources? If so I would hate V2 to be in the names because backwards
compatibility means keeping that around.  If they're not API resources,
then if we named appended the resources with V2 right now, will we be
able to remove the V2 once V1 gets removed?

Thanks,
Brandon
On Tue, 2015-09-22 at 16:40 -0700, Banashankar KV wrote:
> Ok, sounds good. So now the question is how should we name the new V2
> resources ?
> 
> 
> 
> Thanks 
> Banashankar
> 
> 
> 
> On Tue, Sep 22, 2015 at 4:33 PM, Fox, Kevin M <kevin@pnnl.gov>
> wrote:
> Yes, hence the need to support the v2 resources as seperate
> things. Then I can rewrite the templates to include the new
> resources rather then the old resources as appropriate. IE, it
> will be a porting effort to rewrite them. Then do a heat
> update on the stack to migrate it from lbv1 to lbv2. Since
> they are different resources, it should create the new and
> delete the old.
> 
> Thanks,
> Kevin
> 
> 
> __
> From: Banashankar KV [banvee...@gmail.com]
> Sent: Tuesday, September 22, 2015 4:16 PM
> 
> To: OpenStack Development Mailing List (not for usage
> questions)
> Subject: Re: [openstack-dev] [neutron][lbaas] - Heat support
> for LbaasV2
> 
> 
> 
> 
> But I think, V2 has introduced some new components and whole
> association of the resources with each other is changed, we
> should be still able to do what Kevin has mentioned ?
> 
> Thanks  
> Banashankar
> 
> 
> 
> On Tue, Sep 22, 2015 at 3:39 PM, Fox, Kevin M
> <kevin@pnnl.gov> wrote:
> There needs to be a way to have both v1 and v2
> supported in one engine
> 
> Say I have templates that use v1 already in 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 path.
> 
> Thanks,
> Kevin
> 
> From: Brandon Logan [brandon.lo...@rackspace.com]
> Sent: Tuesday, September 22, 2015 3:22 PM
> To: openstack-dev@lists.openstack.org
> Subject: Re: [openstack-dev] [neutron][lbaas] - Heat
> support for LbaasV2
> 
> Well I'd hate to have the V2 postfix on it because V1
> will be deprecated
> and removed, which means the V2 being there would be
> lame.  Is there any
> kind of precedent set for for how to handle this?
> 
> Thanks,
> Brandon
> On Tue, 2015-09-22 at 14:49 -0700, Banashankar KV
> wrote:
> > So are we thinking of making it as ?
> > OS::Neutron::LoadBalancerV2
> >
> > OS::Neutron::ListenerV2
> >
> > OS::Neutron::PoolV2
> >
> > OS::Neutron::PoolMemberV2
> >
> > OS::Neutron::HealthMonitorV2
> >
> >
> >
> > and add all those into the loadbalancer.py of heat
> engine ?
> >
> > Thanks
> > Banashankar
> >
> >
> >
> > On Tue, Sep 22, 2015 at 12:52 PM, Sergey Kraynev
> > <skray...@mirantis.com> wrote:
> > Brandon.
> >
> >
> > As I understand we v1 and v2 have
> differences also in list of
> > objects and also in relationships between
> them.
> > So I don't think that it will be easy to
> upgrade old resources
> > (unfortunately).
> > I'd agree with second Kev

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

[Brandon Logan]

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 be a 
>member of the neutron-lbaas core reviewer team.
>
>Review stats are in line with other cores[2], and Michael has been 
>instrumental in both neutron-lbaas and octavia.
>
>Existing cores, please vote +1/-1 for his addition to the team (that’s 
>Brandon, Phil, Al, and Kyle.)
>
>Thanks,
>doug
>
>1. 
>http://docs.openstack.org/developer/neutron/policies/core-reviewers.html#core-review-hierarchy
>2. http://stackalytics.com/report/contribution/neutron-lbaas/90
>
>
>__
>OpenStack Development Mailing List (not for usage questions)
>Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Brandon Logan]

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 not plan to run for Neutron
> PTL for a fourth cycle. Being a PTL is a rewarding but difficult job,
> as Morgan recently put it in his non-candidacy email [1]. But it goes
> further than that for me. As Flavio put it in his post about "Being a
> PTL" [2], it's a full time job. In the case of Neutron, it's more than
> a full time job, it's literally an always on job.
> 
> I've tried really hard over my three cycles as PTL to build a stronger
> web of trust so the project can grow, and I feel that's been
> accomplished. We have a strong bench of future PTLs and leaders ready
> to go, I'm excited to watch them lead and help them in anyway I can.
> 
> 
> As was said by Zane in a recent email [3], while Heat may have
> pioneered the concept of rotating PTL duties with each cycle, I'd like
> to highly encourage Neutron and other projects to do the same. Having
> a deep bench of leaders supporting each other is important for the
> future of all projects.
> 
> 
> See you all in Tokyo!
> 
> Kyle
> 
> [1]
> http://lists.openstack.org/pipermail/openstack-dev/2015-September/074157.html
> [1]
> http://lists.openstack.org/pipermail/openstack-dev/2015-September/073986.html
> [2]
> http://lists.openstack.org/pipermail/openstack-dev/2015-September/074242.html
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Brandon Logan]

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_dashboard/dashboards/project/ ?
 
 
 Thanks,
 Vivek
 
 
 From: Evgeny Fedoruk evge...@radware.com
 Reply-To: OpenStack Development Mailing List (not for usage
 questions) openstack-dev@lists.openstack.org
 Date: Sunday, August 30, 2015 at 3:37 AM
 To: OpenStack Development Mailing List (not for usage questions)
 openstack-dev@lists.openstack.org
 Subject: Re: [openstack-dev] [neutron][lbaas] Horizon support for
 neutron-lbaas v2
 
 
 
 Hi Vivek
 
  
 
 I merged the repo into openstack-dashboard and restated the apache2,
 new panel did not show up.
 
 Any special things that should be done for getting it?
 
  
 
 Regards,
 
 Evg
 
  
 
 From: Jain, Vivek [mailto:vivekj...@ebay.com] 
 Sent: Monday, August 03, 2015 6:09 PM
 To: OpenStack Development Mailing List (not for usage questions)
 Subject: Re: [openstack-dev] [neutron][lbaas] Horizon support for
 neutron-lbaas v2
 
 
  
 
 For now, take this code and merge with exiting horizon setup
 (openstack_dashbord) and restart horizon. With that you will see
 loadbalancers_v2 panel on the left pane.
 
 
  
 
 
 Thanks,
 
 
 Vivek
 
 
  
 
 
 From:santosh sharma chitr.praya...@gmail.com
 Reply-To: OpenStack Development Mailing List (not for usage
 questions) openstack-dev@lists.openstack.org
 Date: Monday, August 3, 2015 at 5:44 AM
 To: OpenStack Development Mailing List (not for usage questions)
 openstack-dev@lists.openstack.org
 Subject: Re: [openstack-dev] [neutron][lbaas] Horizon support for
 neutron-lbaas v2
 
 
  
 
 
 Hi Vivek, 
 
 How to get the lbaas v2 UI up with mentioned changelist?
 
 
  
 
 
  
 
 
 Thanks
 
 
 Santosh
 
 
  
 
 On Wed, Jul 29, 2015 at 8:24 AM, Jain, Vivek vivekj...@ebay.com
 wrote:
 
 Initial code for horizon lbaas v2 dashboard submitted:
 
 
  
 
 
 https://review.openstack.org/#/c/206797
 
 
  
 
 
 Thanks,
 
 
 vivek
 
 
  
 
 
 From:Jain, Vivek vivekj...@ebay.com
 Reply-To: OpenStack Development Mailing List (not for usage
 questions) openstack-dev@lists.openstack.org
 Date: Tuesday, July 28, 2015 at 6:19 PM 
 
 
 To: OpenStack Development Mailing List (not for usage questions)
 openstack-dev@lists.openstack.org
 Cc: Tonse, Milan mto...@ebay.com
 Subject: Re: [openstack-dev] [neutron][lbaas] Horizon support for
 neutron-lbaas v2
 
 
  
 
 
 Hi Folks,
 
 
  
 
 
 Screenshots are uploaded. Please review and leave your feedback:
 
 
  
 
 
 https://openstack.invisionapp.com/d/main#/projects/4237816
 
 
  
 
 
 Thanks,
 
 
 vivek
 
 
  
 
 
 From:Jain, Vivek vivekj...@ebay.com
 Reply-To: OpenStack Development Mailing List (not for usage
 questions) openstack-dev@lists.openstack.org
 Date: Tuesday, July 28, 2015 at 4:14 PM
 To: OpenStack Development Mailing List (not for usage questions)
 openstack-dev@lists.openstack.org
 Cc: Tonse, Milan mto...@ebay.com
 Subject: Re: [openstack-dev] [neutron][lbaas] Horizon support for
 neutron-lbaas v2
 
 
  
 
 
 Thanks Doug. We are planning to submit initial review version by end
 of day today.
 
 
  
 
 
 Also, we will be uploading LBaaS wireframes for review here:
 
 
 https://openstack.invisionapp.com/d/main#/projects/4237816
 
 
  
 
 
 Thanks,
 
 
 Vivek
 
 
  
 
 
  
 
 
 From:Doug Wiegley doug...@parksidesoftware.com
 Reply-To: OpenStack Development Mailing List (not for usage
 questions) openstack-dev@lists.openstack.org
 Date: Tuesday, July 28, 2015 at 4:04 PM
 To: OpenStack Development Mailing List (not for usage questions)
 openstack-dev@lists.openstack.org
 Cc: Tonse, Milan mto...@ebay.com
 Subject: Re: [openstack-dev] [neutron][lbaas] Horizon support for
 neutron-lbaas v2
 
 
  
 
 
 The repo is now live.  Initial review is
 here: https://review.openstack.org/#/c/206757 , please make any
 near-term reviews dependent on that, unless you’re replacing the
 skeleton. Vivek, when do you think we can get some initial code in
 there to start iterating on? 
 
  
 
 
 Thanks,
 
 
 doug
 
 
  
 
 
  
 
 On Jul 16, 2015, at 6:27 AM, Jain, Vivek vivekj...@ebay.com
 wrote:
 
 
  
 
 A quick reminder that we will be meeting today at 16:00UTC
 (9:00 am PDT) in #openstack-lbaas to discuss Horizon LBaaS v2
 UI.
 
 
  
 
 
 Thanks,
 
 
 Vivek
 
 
  
 
 
 From:Balle, Susanne susanne.ba...@hp.com
 Reply-To: OpenStack Development Mailing List (not for usage
 questions) openstack-dev@lists.openstack.org
 Date: Wednesday, July 15, 2015 at 10:35 AM
 To: Eichberger, German german.eichber...@hp.com,
 OpenStack Development Mailing List (not for usage questions)
 

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

[Brandon Logan]

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 more
 patches to deal with some of the big TODOs (e.g. bulk). Then we can
 rename it and see if we can review the merge.
 
 
 I don't intend to have it fully replace our built-in WSGI solution in
 Liberty. It's too late in the cycle to make that drastic of a switch.
 I just want to have it in the main tree and have the option of trying
 it out in Liberty.
 
 On Fri, Aug 28, 2015 at 4:11 PM, Salvatore Orlando
 salv.orla...@gmail.com wrote:
 I'll leave to Kevin's more informed judgment to comment on
 whether it is appropriate to merge:
 
 
 [1] is a list of patches still under review on the feature
 branch. Some of them fix issues (like executing API actions),
 or implement TODOs
 
 
 This is the current list of TODOs:
 salvatore@ubuntu:/opt/stack/neutron$ find ./neutron/newapi/
 -name \*.py | xargs grep -n TODO
 ./neutron/newapi/hooks/context.py:50:#
 TODO(kevinbenton): is_admin logic
 ./neutron/newapi/hooks/notifier.py:22:# TODO(kevinbenton):
 implement
 ./neutron/newapi/hooks/member_action.py:28:#
 TODO(salv-orlando): This hook must go. Handling actions like
 this is
 ./neutron/newapi/hooks/quota_enforcement.py:33:#
 TODO(salv-orlando): This hook must go when adaptin the pecan
 code to
 ./neutron/newapi/hooks/attribute_population.py:59:
  # TODO(kevinbenton): the parent_id logic currently in base.py
 ./neutron/newapi/hooks/ownership_validation.py:34:#
 TODO(salvatore-orlando): consider whether this check can be
 folded
 ./neutron/newapi/app.py:40:#TODO(kevinbenton): error
 templates
 ./neutron/newapi/controllers/root.py:150:#
 TODO(kevinbenton): allow fields after policy enforced fields
 present
 ./neutron/newapi/controllers/root.py:160:#
 TODO(kevinbenton): bulk!
 ./neutron/newapi/controllers/root.py:190:#
 TODO(kevinbenton): bulk?
 ./neutron/newapi/controllers/root.py:197:#
 TODO(kevinbenton): bulk?
 
 
 In my opinion the pecan API now is working-ish; however we
 know it is not yet 100% functionally equivalent; but most
 importantly we don't know how it works. So far a few corners
 have bet cut when it comes to testing.
 Even if it works it is therefore probably usable.
 Unfortunately I don't know what are the criteria the core team
 evaluates for merging it back (and I'm sure that for this
 release at least the home grown WSGI won't be replaced).
 
 
 Salvatore
 
 
 [1] https://review.openstack.org/#/q/status:open
 +project:openstack/neutron+branch:feature/pecan,n,z
 
 
 On 28 August 2015 at 22:51, Kyle Mestery mest...@mestery.com
 wrote:
 
 Folks:
 
 
 Kevin wants to merge the pecan stuff, and I agree with
 him. I'm on vacation next week during Liberty-3, so
 Armando, Carl and Doug are running the show while I'm
 out. I would guess that if Kevin thinks it's ok to
 merge it in before Liberty-3, I'd go with his opinion
 and let it happen. If not, it can get an FFE and we
 can do it post Liberty-3.
 
 
 I'm sending this to the broader openstack-dev list so
 that everyone can be aware of this plan, and so that
 Ihar can help collapse things back next week with Doug
 on this.
 
 
 Thanks!
 
 Kyle
 
 
 
 
 __
 OpenStack Development Mailing List (not for usage
 questions)
 Unsubscribe:
 openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 
 
 
 
 
 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe:
 openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 

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

[Brandon Logan]

?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 to be the source of truth of the data stored, instead of 
it being the service plugin database.


First, let me address the possibility of a solution using one service plugin 
and multiple drivers per type:


I think that you can overcome #1 in the instantiation of the service plugin to 
check if there are more than 1 provider active, if so you can just throw an 
exception saying you can only have 1.  I'd have to look at it more to see if 
there are any caveats to this, but I think that would work.


For #2, assuming #1 works, then the drivers that are defined can have some 
boolean that they set that will tell the plugin whether they are the source of 
truth or not, and depending on that you can store the data in the service 
plugin's db or just pass the data along, also pass GET requests to the drivers 
as well.


As for making a service plugin for each type, I don't see why that wouldn't 
work.  It seems a bit overkill to me though because you'd probably end up 
having 2 base classes for every service plugin type, one for using the service 
plugin database and another for the data source of truth being external.  
Probably a better way to do this, I'm sure I'm oversimplifying.  I don't see 
much technical reasons why you couldn't do this, though.  It's just 
inconsistent and might cause some confusion.  I'd need to spend some time on it 
to really have an educated opinion.


Thanks,
Brandon


From: Mathieu Rohon mathieu.ro...@gmail.com
Sent: Tuesday, August 18, 2015 7:13 AM
To: OpenStack Development Mailing List
Subject: [openstack-dev] [Neutron][bgpvpn] Service Plugin vs Service driver

Adding the related subject :)

On Tue, Aug 18, 2015 at 10:35 AM, Mathieu Rohon 
mathieu.ro...@gmail.commailto:mathieu.ro...@gmail.com wrote:
Hi all,

The current bgpvpn implementation is using the service type framework, with a 
service plugin and one or more service providers.

After registering the bug [1], I wonder if we would rather use a service plugin 
per implementation type (bagpipe, ODL, OpenContrail, Nuage...) which handles 
API calls, instead of having one service plugin which forwards API calls to a 
service driver depending on the provider chosen by the end user.

I would like to better understand what would be the main drawbacks of such a 
move apart from the fact that a deployment would be tightly coupled to a bgpvpn 
plugin, and multiple implementations of the plugin couldn't coexist.

Thanks,

Mathieu

[1]https://bugs.launchpad.net/bgpvpn/+bug/1485515

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Brandon Logan]

?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 made to not maintain that 
same path for v2.  There's no reason to keep that path for v2 as v1 will be 
deprecated and eventually removed and we did not want to be stuck with that 
path.  Eventually the plugin.py module will have to be moved to the root 
directory as well from services/loadbalancer but thats a minor change.


Thanks,

Brandon


From: Gareth academicgar...@gmail.com
Sent: Thursday, August 13, 2015 9:38 PM
To: OpenStack Development Mailing List
Subject: [openstack-dev] [Neutron] neutron-lbaas code structure problem

Dear neutron guys.

[0] https://github.com/openstack/neutron-lbaas/tree/master/neutron_lbaas/drivers
[1] 
https://github.com/openstack/neutron-lbaas/tree/master/neutron_lbaas/services/loadbalancer/drivers

the codes under these two paths are 'same' (implement same things with v1 and 
v2), but why use two different code paths here?

--
Gareth

Cloud Computing, OpenStack, Distributed Storage, Fitness, Basketball
OpenStack contributor, kun_huang@freenode
My promise: if you find any spelling or grammar mistakes in my email from Mar 1 
2013, notify me
and I'll donate $1 or ?1 to an open organization you specify.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Brandon Logan]

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 correctly when 
soemthing fails).


I'm not going to be having a lot of time to get this done, even though it is 
something I've wanted.  I just wouldn't be able to get to it until some time 
after the Liberty feature freeze.  I'm emailing this out to get some feelers if 
someone in the community would be willing to give this an attempt.  I'd 
definitely help out on it and collaboratively brainstorm when necessary.


Let me know.


Thanks,
Brandon
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Brandon Logan]

?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 Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Brandon Logan]

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, before the update 
mock would allow this method to run as it allowed any method calls to be run.  
Now with the update, only actual assert methods can be used, so that broke 
these tests.  Changing the method to something like self.assertEquals(1, 
mocked_object.call_count) failed as well because the call_count was not 
actually 1.  As such, I've pushed up a review to skip these tests.  It would be 
great if radware folks could fix these tests and unskip them as I didn't have 
the time to look into actually figuring out if the call count discrepancy is a 
real issue or not.


https://review.openstack.org/#/c/200616/?


Thanks,
Brandon
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Brandon Logan]

congrats Al!

On Jul 6, 2015 1:06 PM, Paul Michali p...@michali.net wrote:
Great to have you as a LBass core Al!

On Mon, Jul 6, 2015 at 1:29 PM Doug Wiegley 
doug...@parksidesoftware.commailto: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 Jul 5, 2015, at 6:27 PM, Kyle Mestery 
mest...@mestery.commailto:mest...@mestery.com wrote:

+1 for Al!

On Thu, Jul 2, 2015 at 5:16 PM, Doug Wiegley 
doug...@parksidesoftware.commailto:doug...@parksidesoftware.com wrote:
Hi all,

As the Lieutenant of the advanced services, I would like to nominate Al Miller 
to be a member of the neutron-lbaas core reviewer team.

Review stats are in line with other cores[2] and feedback on patches has been 
great. Additionally, he has been instrumental in our devstack support and 
octavia work.

Existing cores, please vote +1/-1 for his addition to the team (that's Brandon, 
Phil, and Kyle.)

Thanks,
doug

1. 
http://docs.openstack.org/developer/neutron/policies/core-reviewers.html#core-review-hierarchy
2. http://stackalytics.com/report/contribution/neutron-lbaas/90
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://openstack-dev-requ...@lists.openstack.org/?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.orgmailto:openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Brandon Logan]

+1 for me.  Phil your message did not come through.

On 7/2/15, 6:32 PM, Phillip Toohill phillip.tooh...@rackspace.com
wrote:



Phillip V. Toohill III
Software Developer

phone: 210-312-4366
mobile: 210-440-8374



From: Eichberger, German [german.eichber...@hp.com]
Sent: Thursday, July 2, 2015 5:24 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [neutron][lbaas] Proposing Al Miller for
neutron-lbaas core team

Al has been a great asset to LBaaS. Well deserved! +1000

German
+1

On 7/2/15, 3:16 PM, Doug Wiegley doug...@parksidesoftware.com wrote:

Hi all,

As the Lieutenant of the advanced services, I would like to nominate Al
Miller to be a member of the neutron-lbaas core reviewer team.

Review stats are in line with other cores[2] and feedback on patches has
been great. Additionally, he has been instrumental in our devstack
support and octavia work.

Existing cores, please vote +1/-1 for his addition to the team (that¹s
Brandon, Phil, and Kyle.)

Thanks,
doug

1.
http://docs.openstack.org/developer/neutron/policies/core-reviewers.html#
c
ore-review-hierarchy
2. http://stackalytics.com/report/contribution/neutron-lbaas/90
_
_
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Brandon Logan]

I believe XML support got removed from the API last cycle.

From: Jay Pipes jaypi...@gmail.com
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. Collins wrote:
 Hi,

 Within each API extension in the neutron tree, there is a method:

  def get_namespace(cls):

 Which returns a string, containing a URL.

snip

 I believe that they all 404.

 A dumb question to start, then progressively smarter questions:

 * What is the purpose of the URLs?

They are the sad detritus left from XML support.

 * Should the URL point to documentation?

Perhaps.

 * What shall we do about the actual URLs 404'ing?

Honestly, I'd prefer the namespaces just be removed, but I'm not sure
what Neutron's position is about XML and the REST API...

Best,
-jay

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Brandon Logan]

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 kevin@pnnl.gov wrote:
Have a look here:
http://git.openstack.org/cgit/openstack/neutron-lbaas/tree/neutron_lbaas/drivers

Thanks,
Kevin

From: Wanjing Xu [wanjing...@hotmail.com]
Sent: Monday, June 01, 2015 4:52 PM
To: OpenStack Development Mailing List not for usage questions
Subject: [openstack-dev] [Neutron][LBaaS] No LBaaS agent?

Is there a way to add an LBaaS service without having to use neutron 
plugin/agent framework?

I want to add a LBaaS service without  an LBaaS agent running and still want to 
have lb cli and horizon.  When the user configure loadbalance via cli or 
horizon, neutron will send the events(pool, member, vip create/delete event)in 
the notification info queue and our application will listen to the queue and 
program  the LBaaS box.  So far, I have tried to enable the built-in HAProxy 
LBaaS(enable the service_plugin to be LoadBalancerPlugin and service provider 
to be haproxy).  By doing that , horizon and cli are all enabled and our 
application can successfully program LBaaS box using the notification events.  
The problem with that is that there is a haproxy agent running in the 
background although we are not using its function.  But if I don't enable the 
agent, we can not use horizon.  Currently we don't want to write a LBaaS agent 
of our own.  Is there a way to not to use LBaaS agent and still  be able to use 
horizon/cli to configure loadbalance?  During openstack summit at vancouver, I 
saw paypal loadbalance presentation, they use two providers, one is agent , the 
other is agentless controller, not sure how that controller works, could not 
find it through googling.

Regards
Wanjing Xu


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Brandon Logan]

Works for me too

From: Hayes, Graham graham.ha...@hp.com
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 OK for everyone else?

- Sent from my phone

On 28 May 2015 8:39 pm, Doug Wiegley doug...@parksidesoftware.com wrote:

 On May 28, 2015, at 12:47 PM, Hayes, Graham graham.ha...@hp.com wrote:

 On 28/05/15 19:38, Adam Harwell wrote:
 I haven’t seen any responses from my team yet, but I know we’d be
 interested as well — we have done quite a bit of work on this in the
 past, including dealing with the Designate team on this very subject. We
 can be available most hours between 9am-6pm Monday-Friday CST.

 --Adam

 https://keybase.io/rm_you


 From: Rakesh Saha rsahaos...@gmail.com mailto:rsahaos...@gmail.com
 Reply-To: OpenStack Development Mailing List (not for usage questions)
 openstack-dev@lists.openstack.org
 mailto:openstack-dev@lists.openstack.org
 Date: Thursday, May 28, 2015 at 12:22 PM
 To: OpenStack Development Mailing List (not for usage questions)
 openstack-dev@lists.openstack.org
 mailto:openstack-dev@lists.openstack.org
 Subject: Re: [openstack-dev] [designate] and [lbaas] - GSLB API and
 backend support

Hi Kunal,
I would like to participate as well.
Mon-Fri morning US Pacific time works for me.

Thanks,
Rakesh Saha

On Tue, May 26, 2015 at 8:45 PM, Vijay Venkatachalam
vijay.venkatacha...@citrix.com
mailto:vijay.venkatacha...@citrix.com wrote:

We would like to participate as well.

__ __

Monday-Friday Morning US time works for me..

__ __

Thanks,

Vijay V.

__ __

*From:*Samuel Bercovici [mailto:samu...@radware.com
mailto:samu...@radware.com]
*Sent:* 26 May 2015 21:39


*To:* OpenStack Development Mailing List (not for usage questions)
*Cc:* kunalhgan...@gmail.com mailto:kunalhgan...@gmail.com;
v.jain...@gmail.com mailto:v.jain...@gmail.com;
do...@a10networks.com mailto:do...@a10networks.com
*Subject:* Re: [openstack-dev] [designate] and [lbaas] - GSLB
API and backend support

__ __

Hi,

__ __

I would also like to participate.

Friday is a non-working day in Israel (same as Saturday for most
of you).

So Monday- Thursday works best for me.

__ __

-Sam.

__ __

__ __

*From:*Doug Wiegley [mailto:doug...@parksidesoftware.com]
*Sent:* Saturday, May 23, 2015 8:45 AM
*To:* OpenStack Development Mailing List (not for usage questions)
*Cc:* kunalhgan...@gmail.com mailto:kunalhgan...@gmail.com;
v.jain...@gmail.com mailto:v.jain...@gmail.com;
do...@a10networks.com mailto:do...@a10networks.com
*Subject:* Re: [openstack-dev] [designate] and [lbaas] - GSLB
API and backend support

__ __

Of those two options, Friday would work better for me.

__ __

Thanks,

doug

__ __

On May 22, 2015, at 9:33 PM, ki...@macinnes.ie
mailto:ki...@macinnes.ie wrote:

__ __

Hi Kunal,

Thursday/Friday works for me - early morning PT works best,
as I'm based in Ireland.

I'll find some specific times the Designate folks are
available over the next day or two and provide some
options.. 

Thanks,
Kiall

On 22 May 2015 7:24 pm, Gandhi, Kunal
kunalhgan...@gmail.com mailto:kunalhgan...@gmail.com
wrote:

Hi All

__ __

I wanted to start a discussion about adding support for GSLB
to neutron-lbaas and designate. To be brief for folks who
are new to GLB, GLB stands for Global Load Balancing and we
use it for load balancing traffic across various
geographical regions. A more detail description of GLB can
be found at my talk at the summit this week here
https://www.youtube.com/watch?v=fNR0SW3vj_s.

__ __

To my understanding, there are two sides to a GSLB - DNS
side and LB side. 

__ __

DNS side

 Most of the GSLB’s provided by various vendors
are DNS servers and are authoritative for the GLB domains.
The global fqdn’s that belong the GLB domains resolve to
multiple public VIP’s across various regions based on
various configurations on the global fqdn on the GLB.

__ __

LBaaS side

 A few of the common 

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

[Brandon Logan]

?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 a loadbalancer has listeners on 
ports 80 and 443, the vip ports will only allow traffic on those ports.  It 
shouldn't allow other traffic.


Thanks,

Brandon


From: Doug Wiegley doug...@parksidesoftware.com
Sent: Thursday, May 21, 2015 12:49 AM
To: maishsk+openst...@maishsk.com; OpenStack Development Mailing List (not for 
usage questions); Maish Saidel-Keesing
Subject: Re: [openstack-dev] [lbaas] [octavia] [barbican] Relationship between 
Octavia and Barbican and Octavia 1.0 questions

Hi Maish,

Thanks for the feedback, some answers below.  Please also be aware of the lbaas 
use cases session tomorrow at 9am (yuck, I know), 
https://etherpad.openstack.org/p/YVR-neutron-lbaas-use-cases


On May 19, 2015, at 12:05 AM, Maish Saidel-Keesing 
mais...@maishsk.commailto:mais...@maishsk.com wrote:

Hello all,

Going over today's presentation Load Balancing as a Service, Kilo and 
Beyond[1] (great presentation!!) - there are a few questions I have regarding 
the future release:

For Octavia 1.0:

1. Can someone explain to me how the flow would work for spinning up a a new 
Amphora with regards to interaction between Neutron, LBaaS and Barbican?
Same question as well regarding how the standby is created and its relationship 
with Barbican.

The lbaas API runs inside neutron-server.  The general flow is:

- User interacts with neutron CLI/API or horizon (in liberty), and creates an 
LB.
- Lbaas plugin in neutron creates logical models, fetches cert data from 
barbican, and calls the backend lbaas driver.
- The backend driver does what it needs to to instantiate the LB. Today this is 
a synchronous call that waits for the nova boot, but by Liberty, it will likely 
be an async call to the octavia controller to finish the job.

Once Octavia has control, it is doing:

- Get REST calls for objects,
- Talk to nova, spin up an amphora image,
- Talk to neutron, plumb in the networks,
- Send the amphora its config.


2. Will the orchestration (Heat) also be implemented when Octavia 1.0 is 
released or only further down the line?
If not what would you suggest be the way to orchestrate LBaaS until this is 
ready?

We need to talk to the Heat folks and coordinate this, which we are planning to 
do soon.


3. Is there some kind of hook into Security groups also planned for the Amphora 
to also protect the Load Balancer?

Not at present, but I recorded this in the feature list on the etherpad above.


I think that based on the answers to these questions above - additional 
questions will follow.

Thanks

[1] https://www.youtube.com/watch?v=-eAKur8lErU
--
Best Regards,
Maish Saidel-Keesing
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.orgmailto:openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Brandon Logan]

?Right now its all or nothing as far as tcp ports go.  It currently does not 
have the functionality of white/black listinging traffic originating from a 
specific network.


From: Maish Saidel-Keesing mais...@maishsk.com
Sent: Thursday, May 21, 2015 7:45 AM
To: openstack-dev@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 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 a loadbalancer has listeners on 
ports 80 and 443, the vip ports will only allow traffic on those ports.  It 
shouldn't allow other traffic.

That is great to hear. I assume that if we are using security groups we will 
also be able to define rules regarding which networks the listeners are allowed 
to accept traffic from?

Is that assumption correct?


Thanks,

Brandon


From: Doug Wiegley 
doug...@parksidesoftware.commailto:doug...@parksidesoftware.com
Sent: Thursday, May 21, 2015 12:49 AM
To: maishsk+openst...@maishsk.commailto:maishsk+openst...@maishsk.com; 
OpenStack Development Mailing List (not for usage questions); Maish 
Saidel-Keesing
Subject: Re: [openstack-dev] [lbaas] [octavia] [barbican] Relationship between 
Octavia and Barbican and Octavia 1.0 questions

Hi Maish,

Thanks for the feedback, some answers below.  Please also be aware of the lbaas 
use cases session tomorrow at 9am (yuck, I know), 
https://etherpad.openstack.org/p/YVR-neutron-lbaas-use-cases


On May 19, 2015, at 12:05 AM, Maish Saidel-Keesing 
mais...@maishsk.commailto:mais...@maishsk.com wrote:

Hello all,

Going over today's presentation Load Balancing as a Service, Kilo and 
Beyond[1] (great presentation!!) - there are a few questions I have regarding 
the future release:

For Octavia 1.0:

1. Can someone explain to me how the flow would work for spinning up a a new 
Amphora with regards to interaction between Neutron, LBaaS and Barbican?
Same question as well regarding how the standby is created and its relationship 
with Barbican.

The lbaas API runs inside neutron-server.  The general flow is:

- User interacts with neutron CLI/API or horizon (in liberty), and creates an 
LB.
- Lbaas plugin in neutron creates logical models, fetches cert data from 
barbican, and calls the backend lbaas driver.
- The backend driver does what it needs to to instantiate the LB. Today this is 
a synchronous call that waits for the nova boot, but by Liberty, it will likely 
be an async call to the octavia controller to finish the job.

Once Octavia has control, it is doing:

- Get REST calls for objects,
- Talk to nova, spin up an amphora image,
- Talk to neutron, plumb in the networks,
- Send the amphora its config.


2. Will the orchestration (Heat) also be implemented when Octavia 1.0 is 
released or only further down the line?
If not what would you suggest be the way to orchestrate LBaaS until this is 
ready?

We need to talk to the Heat folks and coordinate this, which we are planning to 
do soon.


3. Is there some kind of hook into Security groups also planned for the Amphora 
to also protect the Load Balancer?

Not at present, but I recorded this in the feature list on the etherpad above.


I think that based on the answers to these questions above - additional 
questions will follow.

Thanks

[1] https://www.youtube.com/watch?v=-eAKur8lErU
--
Best Regards,
Maish Saidel-Keesing
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.orgmailto:openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


--
Best Regards,
Maish Saidel-Keesing
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Brandon Logan]

?+1 from me


From: Kyle Mestery mest...@mestery.com
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 
german.eichber...@hp.commailto:german.eichber...@hp.com wrote:
Hi,

I am proposing that Octavia is joining the Networking program as a project
under the Services area.

Octavia is the open scalable reference implementation for Neutron LBaaS V2
and has always seen itself as part of the networking program. We have
adopted most governance rules from the Networking program, sharing the
same build structure, and are organized like an OpenDStack project.


This sounds fine to me German. To proceed here, propose something similar to 
what Russell has proposed for OVN here [1], and ping me on IRC with the review 
so I can ack it. The TC can then approve it at a future meeting.

Thanks!
Kyle

[1] https://review.openstack.org/#/c/175954/

Thanks,
German



__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Brandon Logan]

?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 operationgs (POST, PUT, GET) 
should show operating status as DISABLED, and it is not.  This is a bug, and I 
believe it would be quite simple to fix.  You won't need to call the statuses 
method as that is just the method that is called when the /statuses resource is 
called.  The create_loadbalancer, get_loadbalancer, get_loadbalancers, and 
update_loadbalancer methods will just need to change the operating_status to 
DISABLED if admin_state_up is False.  Should be a very simple change actually.


Let me know if I am articulating the problem correctly.


Thanks,

Brandon


From: Madhusudhan Kandadai madhusudhan.openst...@gmail.com
Sent: Tuesday, April 28, 2015 3:23 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] Neutron Lbaas v2 not showing operating_status as 
inactive

Hi Anand,

There is an api which calls 'statuses' method.. I could see the status 
'DISABLED' in: GET /lbaas/loadbalancers/loadbalancer_id/statuses.

Maybe we need to correct the doc to reflect the right URL to avoid confusion. 
If that is the right API call, I shall update the bug and mark it as fixed.

Regards,
Madhu



On Tue, Apr 28, 2015 at 12:28 PM, Anand shanmugam 
anand1...@outlook.commailto:anand1...@outlook.com wrote:
Hi ,

I am working on the bug https://bugs.launchpad.net/neutron/+bug/1449286

In this bug the admin_state_up is made to false when creating a lbaas v2 
loadbalancer.The operating_state should become DISABLED for the created 
loadbalancer but it is showing as online.

I can see that there is a method statuses which takes care of disabling the 
opensrting_status ( 
https://github.com/openstack/neutron-lbaas/blob/master/neutron_lbaas/services/loadbalancer/plugin.py#L971)
 but I cannot find the method which will call this 'satuses' method.

I feel this statuses method is not called at all when creating or updating a 
loadbalancer.Could someone please help me if there is any other api to call 
this method?

Regards,
Anand S

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Brandon Logan]

?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: Brandon Logan brandon.lo...@rackspace.com
Sent: Monday, April 27, 2015 8:40 PM
To: OpenStack Development Mailing List not for usage questions
Subject: 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 optional, and if 
not specified then it's assumed that member can be reached with whatever has 
already been setup.?  Another option is pool could get a subnet_id field in the 
future and all members that are created without subnet_id are assumed to be on 
the pool's subnet_id, but I'm getting ahead of myself and this has no bearing 
on your current issue.


Could you tell me how you are making your requests? CLI? REST directly?


From: Wanjing Xu wanjing...@hotmail.com
Sent: Monday, April 27, 2015 12:57 PM
To: OpenStack Development Mailing List not for usage questions
Subject: [openstack-dev] [Neutron][LBaaS] Why do we need to select subnet when 
creating a pool?

So when I use Haproxy for LBaaS for Juno, there is a subnet mandatary field 
that I need to fill in when creating a pool, and later on when I add members, I 
can use a different subnet(or simply just enter the ip of the member), when 
adding vip, I can still select a third subnet.  So what is the usage of the 
first subnet that I used to create pool?  There is no port created for this 
pool subnet.  I can see that a port is created for the vip subnet that the 
loadbalancer instance is binding to.

Regards!

Wanjing Xu
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Brandon Logan]

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 optional, and if 
not specified then it's assumed that member can be reached with whatever has 
already been setup.?  Another option is pool could get a subnet_id field in the 
future and all members that are created without subnet_id are assumed to be on 
the pool's subnet_id, but I'm getting ahead of myself and this has no bearing 
on your current issue.


Could you tell me how you are making your requests? CLI? REST directly?


From: Wanjing Xu wanjing...@hotmail.com
Sent: Monday, April 27, 2015 12:57 PM
To: OpenStack Development Mailing List not for usage questions
Subject: [openstack-dev] [Neutron][LBaaS] Why do we need to select subnet when 
creating a pool?

So when I use Haproxy for LBaaS for Juno, there is a subnet mandatary field 
that I need to fill in when creating a pool, and later on when I add members, I 
can use a different subnet(or simply just enter the ip of the member), when 
adding vip, I can still select a third subnet.  So what is the usage of the 
first subnet that I used to create pool?  There is no port created for this 
pool subnet.  I can see that a port is created for the vip subnet that the 
loadbalancer instance is binding to.

Regards!

Wanjing Xu
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Brandon Logan]

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 
Networking/Neutron project.  Other than that it sounds like nothing much would 
change.​  Is this to solve the whole issue regarding projects graduating to 
become openstack projects?  If so, it sounds like those issues might just be 
shuffled to the decision of whether a project should graduate to a better 
tag.  I'm sure this has come up in the tags discussions, and its a bit out of 
scope of this email, but it's just a concern I have.


Thanks,

Brandon


From: Fox, Kevin M kevin@pnnl.gov
Sent: Wednesday, April 22, 2015 2:49 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron] A big tent home for Neutron backend code

+1

I was in the middle of writing an email asking about the possibility of 
splitting out the reference implementation. you beat me to it. :)

I also like the idea of having the PTL on top to help pass up/down ideas where 
code can be shared, benefiting everyone.

Thanks,
Kevin

From: Kyle Mestery [mest...@mestery.com]
Sent: Wednesday, April 22, 2015 12:30 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron] A big tent home for Neutron backend code

On Wed, Apr 22, 2015 at 1:19 PM, Russell Bryant 
rbry...@redhat.commailto:rbry...@redhat.com wrote:
Hello!

A couple of things I've been working on lately are project governance
issues as a TC member and also implementation of a new virtual
networking alternative with a Neutron driver.  So, naturally I started
thinking about how the Neutron driver code fits in to OpenStack governance.

Thanks for starting this conversation Russell.

There are basically two areas with a lot of movement related to this issue.

1) Project governance has moved to a big tent model [1].  The vast
majority of projects that used to be in Stackforge are being folded in
to a larger definition of the OpenStack project.  Projects making this
move meet the following criteria as being one of us:

http://governance.openstack.org/reference/new-projects-requirements.html

Official project teams are tracked in this file along with the git repos
they are responsible for:

http://git.openstack.org/cgit/openstack/governance/tree/reference/projects.yaml

which is also reflected here:

http://governance.openstack.org/reference/projects/

The TC has also been working through defining a system to help
differentiate efforts by using a set of tags [4].  So far, we have
tags describing the release handling for a repository, as well as a tag
for team diversity.  We've also had a lot of discussion about tags to
help describe maturity, but that is still a work in progress.


2) In Neutron, some fairly significant good changes are being made to
help scale the development process.  Advanced services were split out
into their own repos [2].  Most of the plugin and driver code has also
been split out into repos [3].

In terms of project teams, the Neutron team is defined as owning the
following repos:

  http://governance.openstack.org/reference/projects/neutron.html

 - openstack/neutron
 - openstack/neutron-fwaas
 - openstack/neutron-lbaas
 - openstack/neutron-vpnaas
 - openstack/neutron-specs
 - openstack/python-neutronclient

The advanced services split is reflected by the fwaas, lbaas, and vpnaas
repos.

We also have a large set of repositories related to Neutron backend code:

  http://git.openstack.org/cgit/?q=stackforge%2Fnetworking

 - stackforge/networking-arista
 - stackforge/networking-bagpipe-l2
 - stackforge/networking-bgpvpn
 - stackforge/networking-bigswitch
 - stackforge/networking-brocade
 - stackforge/networking-cisco
 - stackforge/networking-edge-vpn
 - stackforge/networking-hyperv
 - stackforge/networking-ibm
 - stackforge/networking-l2gw
 - stackforge/networking-midonet
 - stackforge/networking-mlnx
 - stackforge/networking-nec
 - stackforge/networking-odl
 - stackforge/networking-ofagent
 - stackforge/networking-ovn
 - stackforge/networking-ovs-dpdk
 - stackforge/networking-plumgrid
 - stackforge/networking-portforwarding
 - stackforge/networking-vsphere

Note that not all of these are equivalent.  This is just a list of
stackforge/networking-*.

In some cases there is a split between code in the Neutron tree and in
this repo.  In those cases, a shim is in the Neutron tree, but most of
the code is in the external repo.  It's also possible to have all of the
code in the external repo.

There's also a big range of maturity.  Some are quite mature and are
already used in production.  networking-ovn as an example is quite new
and being developed in parallel with OVN in the Open vSwitch project.


So, my question is: 

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

[Brandon Logan]

Welcome Phil!

From: Doug Wiegley doug...@parksidesoftware.com
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 Apr 13, 2015, at 2:39 PM, Doug Wiegley doug...@parksidesoftware.com 
 wrote:

 Hi all,

 I'd like to nominate Philip Toohill as a neutron-lbaas core. Good guy, did a 
 bunch of work on the ref impl for lbaasv2, and and I'll let the numbers[1] 
 speak for themselves.

 Existing lbaas cores, please vote.  All three of us.  :-)

 [1] http://stackalytics.com/report/contribution/neutron-lbaas/30

 Thanks,
 doug




__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Brandon Logan]

?+1


From: Kyle Mestery mest...@mestery.com
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 
doug...@parksidesoftware.commailto:doug...@parksidesoftware.com wrote:
Hi all,

I'd like to nominate Philip Toohill as a neutron-lbaas core. Good guy, did a 
bunch of work on the ref impl for lbaasv2, and and I'll let the numbers[1] 
speak for themselves.

Existing lbaas cores, please vote.  All three of us.  :-)

+1

[1] http://stackalytics.com/report/contribution/neutron-lbaas/30

Thanks,
doug



__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Brandon Logan]

I'm of the opinion, which may not be the popular opinion, that barbican is the 
secret store for openstack.  It is in openstack, it is meant to be used by 
other openstack services.  v1 lives in the same code base as v2.  Version 
transitions such as these are going to end up having requirements only for one 
version.  I don't think think that is a bad thing as v1 will eventually be 
deprecated.  I am not, however, a packager so I do not know the pains you have 
nor the perspective.  Sounds like you are okay with leaving it in, which is my 
preference, but I can obviously be swayed.

Thanks,
Brandon

From: Ihar Hrachyshka ihrac...@redhat.com
Sent: Monday, April 13, 2015 9:40 AM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [neutron][lbaas][barbican] default certificate 
manager

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 04/10/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 though it isn't used?


I package neutron for RDO, so I use requirements.txt as a suggestion.
My main problem was that python-barbicanclient was not packaged for
RDO when I started looking into the issue, but now that it's packaged
in Fedora [1], the issue is not that significant to me. Of course it's
a wasted dependency installed for nothing (plus its own dependencies),
but that's not a disaster, and if upstream team thinks it's the right
thing to do, let it be so, and I'm happy to abandon the change.

[1]: https://bugzilla.redhat.com/show_bug.cgi?id=1208454

/Ihar
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQEcBAEBAgAGBQJVK9VFAAoJEC5aWaUY1u57dCkH/R73ECDlHVl2ocBWfTk4BEqi
R8j/wpCCSz3x9uffWR9F8mJoqEnvekIvTtoaHaleiVfZTAhGRDRoxT7nOuMBFBDp
ynmeJEicualeiAFX1z6//KA4L6y5hqGaV71axCRmAT/c0P5fuK08WIMBOkzQRyuo
JmJbej5pOOlDRos0+PJd2+7qxAVU2CAuVBrJIVsJoG4zuISNDalxeOIaYKHU0+Tu
/r7bztTrjkbcs6jiHrvv8MugsivrV1hGEBDsIVgC/Fsgy19f0X2aEjbh7G6lioab
Vm6G+fDCFJVVQ6Xbc9qQPs1geRrocVAb7ZGeuhT/RdoMFTxBR8EJnPqWHXkYWuA=
=O4Ll
-END PGP SIGNATURE-

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Brandon Logan]

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 explicitly documented that the local cert manager was an 
insecure option and should not be used in a production environment.  So that's 
not a huge deal, but still a factor.  Without these fields, the local cert 
manager is useless because a user can't store anything.  

2) If #1 was allowed then the listener would have to accept those fields along 
with a tls_container_id.  That in itself can be confusing, but it could be 
overcome with documentation.  

3) If barbican was in use then it would be expected that the neutron-lbaas API 
would accept the raw secrets, and then its up to the system to store those 
secrets in barbican.  Who should those secrets be owned by?
a) If we make them owned by the user then you run into the issue of 
them re-using the secrets in some other system.  What happens when the user 
deletes the listener that the secrets were originally created for?
b) If we make them owned by the system then a user can't reuse the same 
secrets, which is a big reason to use barbican.

4) Time.  The options above could definitely have been done, but along with not 
being clear as to which is the best option (if there is one), there wasn't much 
time to actually implement them. 

So given all of that, I think defaulting to barbican was the lesser of many 
evils.  LBaaS v2 is marked as experimental in the docs so that gives us some 
leeway to make some backwards incompatible changes, though the options above 
wouldn't be backwards incompatible.  It's still a signal to users/operators 
that its experimental.

Thanks,
Brandon  



From: Ihar Hrachyshka ihrac...@redhat.com
Sent: Thursday, April 9, 2015 10:29 AM
To: openstack-dev
Subject: [openstack-dev] [neutron][lbaas][barbican] default certificate manager

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi lbaas folks,

I've realized recently that the default certificate manager for lbaas
advanced service is now barbican based. Does it mean that to make
default configuration working as is, users will need to deploy
barbican service? If that's really the case, the default choice seems
to be unfortunate. I think it would be better not to rely on external
service in default setup, using local certificate manager.

Is there a particular reason behind the default choice?

Thanks,
/Ihar
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBAgAGBQJVJprKAAoJEC5aWaUY1u57OEcIANdh8uBUcHKxBqjYFwQWoJRx
jLLlH6uxivP3i9nBiYFTZG8uwFhwCzL5rl9uatB7+Wsu41uOTJZeUlCM4dN+xOIz
J9KujLv1oGD/FvgpVGP/arJ6SoCeiINmezwQAziid6dmtH1iYePFCCTCJedbMmND
KampF+RXmHIwXvwVN1jK/tDfGsMHOoGKjy4jmgw48jBWFch1PBWQnRn4ooxZDbmI
VGQvSbpDwkQ3+N3ELZHx0m7l9kGmRKQl/8Vwml6pJKtcrGObkQGGGPeTPYj8Y/NO
Peht83x+HkrIupXZpkm3ybyHWSQdJw+RdKquGWKPTrcNGL1zZTl46rHWF79rhxA=
=C8+6
-END PGP SIGNATURE-

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Brandon Logan]

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‎ ‎2015 ‎20‎:‎20
 To: OpenStack Development Mailing List (not for usage questions)
 
 
 Make sense to me. Susanne
 
 On Thu, Mar 19, 2015 at 5:49 PM, Doug Wiegley
 doug...@parksidesoftware.com wrote:
 Hi lbaas'ers,
 
 Now that lbaasv2 has shipped, the need for a regular weekly
 meeting is greatly reduced. I propose that we cancel the
 regular meeting, and discuss neutron-y things during the
 neutron on-demand agenda, and octavia things in the already
 existing octavia meetings.
 
 Any objections/alternatives?
 
 Thanks,
 doug
 
 
 
 
 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe:
 openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 
 
 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Brandon Logan]

?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


From: Doug Wiegley doug...@parksidesoftware.com
Sent: Thursday, March 19, 2015 11:01 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron] Neutron extenstions

Hi Gary,

First I'm seeing these, but I don't see that they're required on input, unless 
I'm mis-reading those reviews.  Additional of new output fields to a json 
object, or adding optional inputs, is not generally considered to be backwards 
incompatible behavior in an API. Does OpenStack have a stricter standard on 
that?

Thanks,
doug


On Mar 19, 2015, at 6:37 AM, Gary Kotton 
gkot...@vmware.commailto:gkot...@vmware.com wrote:

Hi,
Changed the subject so that it may draw a little attention.
There were 2 patches approved that kind of break the API (in my humble opinion):
https://review.openstack.org/#/c/154921/ and 
https://review.openstack.org/#/c/158420/
In both of these two new fields were added to the base attributes - mtu and 
vlan_transparency
Reverts for them are:
https://review.openstack.org/165801 (mtu) and 
https://review.openstack.org/165776 (vlan transparency).
In my opinion these should be added as separate extensions.
Thanks
Gary

From: Gary Kotton gkot...@vmware.commailto:gkot...@vmware.com
Reply-To: OpenStack List 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Date: Thursday, March 19, 2015 at 2:32 PM
To: OpenStack List 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [Neutron] VLAN transparency support

Hi,
This patch has the same addition too - 
https://review.openstack.org/#/c/154921/. We should also revert that one.
Thanks
Gary

From: Gary Kotton gkot...@vmware.commailto:gkot...@vmware.com
Reply-To: OpenStack List 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Date: Thursday, March 19, 2015 at 1:14 PM
To: OpenStack List 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Subject: [openstack-dev] [Neutron] VLAN transparency support

Hi,
It appears that https://review.openstack.org/#/c/158420/ update the base 
attributes for the networks. Is there any reason why this was not added as a 
separate extension like all others.
I do not think that this is the correct way to go and we should do this as all 
other extensions have been maintained. I have posted a revert 
(https://review.openstack.org/#/c/165776/) - please feel free to knack if it is 
invalid.
Thanks
Gary
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.orgmailto:openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Brandon Logan]

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 rattenpal.amand...@tcs.com wrote:
Hi Team

As per V2 API specification load balancer healthmonitor has a parameter type
which can not be parsed by JSON parser.
So, it must be replaced by healthmonitor_type as per the OpenDayLight Bug-
( https://bugs.opendaylight.org/show_bug.cgi?id=1674 )

I reported a bug related to this 
(https://bugs.launchpad.net/neutron/+bug/1415336 )
Should i make changes on the health monitor parameter ..?

Thanks
Amandeep
Mail to: rattenpal.amand...@tcs.com

=-=-=
Notice: The information contained in this e-mail
message and/or attachments to it may contain
confidential or privileged information. If you are
not the intended recipient, any dissemination, use,
review, distribution, printing or copying of the
information contained in this e-mail message
and/or attachments to it are strictly prohibited. If
you have received this communication in error,
please notify us by reply e-mail or telephone and
immediately and permanently delete the message
and any attachments. Thank you
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Brandon Logan]

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 mest...@mestery.com
 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 changes to the core team. Reviews are the most important
 part of being a core reviewer, so we need to ensure cores are
 doing reviews. The stats for the 90 day period [2] indicate
 some changes are needed for core reviewers who are no longer
 reviewing on pace with the other core reviewers.
 
 
 First of all, I'm removing Sumit Naiksatam from neutron-core.
 Sumit has been a core reviewer for a long time, and his past
 contributions are very much thanked by the entire OpenStack
 Neutron team. If Sumit jumps back in with thoughtful reviews
 in the future, we can look at getting him back as a Neutron
 core reviewer. But for now, his stats indicate he's not
 reviewing at a level consistent with the rest of the Neutron
 core reviewers.
 
 
 As part of the change, I'd like to propose Doug Wiegley as a
 new Neutron core reviewer. Doug has been actively reviewing
 code across not only all the Neutron projects, but also other
 projects such as infra. His help and work in the services
 split in December were the reason we were so successful in
 making that happen. Doug has also been instrumental in the
 Neutron LBaaS V2 rollout, as well as helping to merge code in
 the other neutron service repositories.
 
 I'd also like to take this time to remind everyone that
 reviewing code is a responsibility, in Neutron the same as
 other projects. And core reviewers are especially beholden to
 this responsibility. I'd also like to point out that +1/-1
 reviews are very useful, and I encourage everyone to continue
 reviewing code even if you are not a core reviewer.
 
 Existing neutron cores, please vote +1/-1 for the addition of
 Doug to the core team.
 
 
 It's been a week, and Doug has received plenty of support. Welcome to
 the Neutron Core Review team Doug!
 
 Kyle
  
 
 Thanks!
 Kyle
 
 [1]
 
 http://lists.openstack.org/pipermail/openstack-dev/2014-December/051986.html
 [2]
 http://russellbryant.net/openstack-stats/neutron-reviewers-90.txt
 
 
 
 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Brandon Logan]

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:
Show the statuses directly on the entity.

Option 2-A:
Show a status tree only on the load balancer object, but not on any entities.

Option 2-B:
Expose a resource for a GET request that will return that status tree.

Example:
GET /lbaas/loadbalancers/{LB_UUID}/statuses


Option 1 is probably what most people are used to but it doesn't allow for 
sharing of
objects, and when/if sharing is enabled, it will cause a break in contract and 
a new
version of the API.  So it would essentially disallow object sharing.  This 
requires
a lot less work to implement.

Option 2-* can be done with or without sharing, and when/if object sharing is 
enabled
it wont break contract.  This will require more work to implement.

My personal opinion is in favor of Option 2-B, but wouldn't argue with 2-A 
either.

Thanks,
Brandon


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Brandon Logan]

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
 brandon.lo...@rackspace.com wrote:
 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!
 
 
 Hi all,
 
 
 I've fixed the logged
 bug: https://bugs.launchpad.net/openstack-manuals/+bug/1412944
 
 
 Longer explanation, the referenced link [1] is to a source document
 that is going to openstack-attic as soon as the infra team does their
 scheduled gerrit downtime. [2] Also, since our build jobs don't delete
 old files, I had to manually delete the outdated docs. Once this spec
 is complete this particular issue won't happen any more. [3] 
 
 
 
 Thanks,
 Anne
 
 
 1. http://docs.openstack.org/api/openstack-network/2.0/content/lbaas_ext.html
 2. https://review.openstack.org/#/c/145289/
 3. 
 http://specs.openstack.org/openstack-infra/infra-specs/specs/doc-publishing.html
 
 
  
 
 Thanks,
 Brandon
 
 On Tue, 2015-01-20 at 12:03 +0530, Shreshtha Joshi wrote:
  Hi,
 
 
  The openstack documentation for LBaaS Neutron v2 APIs does
 not clearly
  define way to associate a HealthMonitor with a pool.
* Will it be done via pool update - put method at
  /v2.0/pools/{pool_id}.
* Or it will be done via post method at
  /v2.0/lb/pools/{pool_id}/health_monitors
  Any other link detailing LBaaS v2 APIs will be great help.
  Thanks in advance.
 
 
  Regards
  Shreshtha Joshi
 
 
  =-=-=
  Notice: The information contained in this e-mail
  message and/or attachments to it may contain
  confidential or privileged information. If you are
  not the intended recipient, any dissemination, use,
  review, distribution, printing or copying of the
  information contained in this e-mail message
  and/or attachments to it are strictly prohibited. If
  you have received this communication in error,
  please notify us by reply e-mail or telephone and
  immediately and permanently delete the message
  and any attachments. Thank you
 
 
 
 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe:
 openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 
 
 
 
 -- 
 Anne Gentle
 annegen...@justwriteclick.com
 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Brandon Logan]

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:03 +0530, Shreshtha Joshi wrote:
 Hi,
 
 
 The openstack documentation for LBaaS Neutron v2 APIs does not clearly
 define way to associate a HealthMonitor with a pool.
   * Will it be done via pool update - put method at
 /v2.0/pools/{pool_id}.
   * Or it will be done via post method at
 /v2.0/lb/pools/{pool_id}/health_monitors
 Any other link detailing LBaaS v2 APIs will be great help.
 Thanks in advance. 
 
 
 Regards
 Shreshtha Joshi
 
 
 =-=-=
 Notice: The information contained in this e-mail
 message and/or attachments to it may contain 
 confidential or privileged information. If you are 
 not the intended recipient, any dissemination, use, 
 review, distribution, printing or copying of the 
 information contained in this e-mail message 
 and/or attachments to it are strictly prohibited. If 
 you have received this communication in error, 
 please notify us by reply e-mail or telephone and 
 immediately and permanently delete the message 
 and any attachments. Thank you
 

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Brandon Logan]

Yeah before we get those stats in we'll need to finalize v2 because that
will affect how the API shows those types of stats to the user.

On Mon, 2015-01-19 at 22:33 -0800, Varun Lodaya wrote:
 Hey Brandon,
 
 Thanks for the response. My bad. Seems there is a small bug in horizon.
 The moment you configure a health monitor, it shows up in the pool. I
 thought it automatically got associated. But when I checked via CLI, it
 was not. After associating it via CLI (not able to associate it via
 horizon, the drop down for health-monitors doesn¹t seem to work), it seems
 to work fine :).
 
 As per stats, ideally, it¹s good to get counters like:
 ICMP successful requests: x
 ICMP response  timeouts: y
 ICMP response failures: z
 
 HTTP successful responses: a
 HTTP timeouts: b
 .
 .
 .
 
 
 Just an initial thought, this sort of verifies that monitors are working
 as expected. Like in current situation, I had to manually login to the
 server to see if the server is catering to any health-monitoring requests.
 
 Even getting haproxy stats is not very straightforward, as you need to
 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 brandon.lo...@rackspace.com wrote:
 
 Hi Varun,
 
 Could you tell me which driver you are using? If you're running the
 HaproxyOnHostPluginDriver then that should do a check every 6 seconds
 for members being down.  However, other drivers may not do this.  It's
 up to the driver.
 
 As for providing health monitor stats, those currently are not being
 provided.  There haven't been any plans for that yet because everyone
 has been focused on getting the v2 API out.  Which is almost complete
 and plan for that to be completed for Kilo-3.  If you'd like to be able
 to retrieve some health stats, please list them and let us know.  We'll
 hopefully be able to get them in after v2 has completed.
 
 Thanks,
 Brandon
 
 On Mon, 2015-01-19 at 14:42 -0800, Varun Lodaya wrote:
  Hi All,
  
  
  I am trying to get LBaaS running on stable Juno. I can get all the
  LBaaS components correctly installed and working as expected. But I am
  facing some issues with the health-monitor. I am not quite sure if
  it¹s working as expected.
  
  
  I have 2 ubuntu servers as members of http-pool and I have stopped
  apache process on 1 of the servers. I have HTTP health-monitor
  configured on the pool which runs every 1 min and checks for 200
  response code on HTTP GET. I was expecting it to FAIL after 3 retries
  and make the status ³INACTIVE² for the member where apache is not
  running. But for some reason, it¹s always ACTIVE.
  
  
  Can somebody help me with how is it suppose to work and if it¹s a bug?
  
  
  Also, currently I don¹t see any health monitor stats with neutron. Is
  there any plan to get health monitor stats in future releases?
  
  
  Thanks,
  Varun
  
 _
 _
  OpenStack Development Mailing List (not for usage questions)
  Unsubscribe: 
 openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 
 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 
 
 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Brandon Logan]

Hi Varun,

Could you tell me which driver you are using? If you're running the
HaproxyOnHostPluginDriver then that should do a check every 6 seconds
for members being down.  However, other drivers may not do this.  It's
up to the driver.

As for providing health monitor stats, those currently are not being
provided.  There haven't been any plans for that yet because everyone
has been focused on getting the v2 API out.  Which is almost complete
and plan for that to be completed for Kilo-3.  If you'd like to be able
to retrieve some health stats, please list them and let us know.  We'll
hopefully be able to get them in after v2 has completed.

Thanks,
Brandon

On Mon, 2015-01-19 at 14:42 -0800, Varun Lodaya wrote:
 Hi All,
 
 
 I am trying to get LBaaS running on stable Juno. I can get all the
 LBaaS components correctly installed and working as expected. But I am
 facing some issues with the health-monitor. I am not quite sure if
 it’s working as expected.
 
 
 I have 2 ubuntu servers as members of http-pool and I have stopped
 apache process on 1 of the servers. I have HTTP health-monitor
 configured on the pool which runs every 1 min and checks for 200
 response code on HTTP GET. I was expecting it to FAIL after 3 retries
 and make the status “INACTIVE” for the member where apache is not
 running. But for some reason, it’s always ACTIVE. 
 
 
 Can somebody help me with how is it suppose to work and if it’s a bug?
 
 
 Also, currently I don’t see any health monitor stats with neutron. Is
 there any plan to get health monitor stats in future releases?
 
 
 Thanks,
 Varun
 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron] Next week's meeting is cancelled (and some other notes)

[Brandon Logan]

I'm pretty sure you just destroyed everyone's vision with that.

On Fri, 2015-01-16 at 21:23 +, Doug Wiegley wrote:
 It’s not pretty, but if the topic has been set correctly, this finds
 everything open with a Kilo-2 blueprint:
 
 
 https://review.openstack.org/#/q/project:openstack/neutron+status:open
 +(topic:bp/wsgi-pecan-switch+OR+topic:bp/plugin-interface-perestroika
 +OR+topic:bp/reorganize-unit-test-tree+OR
 +topic:bp/restructure-l2-agent+OR+topic:bp/rootwrap-daemon-mode+OR
 +topic:bp/retargetable-functional-testing+OR
 +topic:bp/refactor-iptables-firewall-driver+OR+topic:bp/vsctl-to-ovsdb
 +OR+topic:bp/lbaas-api-and-objmodel-improvement+OR
 +topic:bp/restructure-l3-agent+OR+topic:bp/neutron-ovs-dvr-vlan+OR
 +topic:bp/allow-specific-floating-ip-address+OR
 +topic:bp/ipset-manager-refactor+OR
 +topic:bp/agent-child-processes-status+OR
 +topic:bp/extra-dhcp-opts-ipv4-ipv6+OR
 +topic:bp/ipsec-strongswan-driver+OR+topic:bp/ofagent-bridge-setup+OR
 +topic:bp/arp-spoof-patch-ebtables+OR+topic:bp/report-ha-router-master
 +OR+topic:bp/conntrack-in-security-group+OR
 +topic:bp/allow-mac-to-be-updated+OR+topic:bp/specify-router-ext-ip+OR
 +topic:bp/a10-lbaas-v2-driver+OR+topic:bp/brocade-vyatta-fwaas-plugin
 +OR+topic:bp/netscaler-lbaas-v2-driver+OR+topic:bp/ofagent-sub-driver
 +OR+topic:bp/ml2-cisco-nexus-mechdriver-providernet+OR
 +topic:bp/ofagent-flow-based-tunneling+OR
 +topic:bp/ml2-ovs-portsecurity+OR+topic:bp/fwaas-cisco+OR
 +topic:bp/freescale-fwaas-plugin+OR
 +topic:bp/rpc-docs-and-namespace),n,z
 
 
 
 
 
 
 From: Kyle Mestery mest...@mestery.com
 Reply-To: OpenStack Development Mailing List (not for usage
 questions) openstack-dev@lists.openstack.org
 Date: Friday, January 16, 2015 at 1:33 PM
 To: OpenStack Development Mailing List (not for usage questions)
 openstack-dev@lists.openstack.org
 Subject: [openstack-dev] [neutron] Next week's meeting is cancelled
 (and some other notes)
 
 
 
 Folks:
 
 
 It's a holiday in the US next Monday [1], so I'm going to cancel the
 weekly Neutron team meeting. We'll reconvene per the normal schedule
 [2] next on Tuesday, January 27 (my birthday!) at 1400 UTC.
 
 One thing I'd like to mention here is on the topic of reviewing code.
 When reviewing code in Neutron, please make sure you're looking at
 approved BPs for reviews. In this case, we should be actively
 reviewing Kilo-2 BPs [3]. The links to the reviews are in the BPs
 themselves. Until someone builds a better integrated dashboard for
 gerrit that takes into account the LP priority, this is the best I can
 offer you. But I encourage people to please prioritize their reviews
 by looking at BPs approved rather than just popping gerrit up and
 starting at the top of what it presents you.
 
 Thanks, have a great weekend everyone!
 
 Kyle
 
 [1] http://en.wikipedia.org/wiki/Martin_Luther_King,_Jr._Day
 [2] https://wiki.openstack.org/wiki/Network/Meetings
 [3] https://launchpad.net/neutron/+milestone/kilo-2
 
 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev