Re: [openstack-dev] [neutron] Core status

[Bhatia, Manjeet S]

Good luck for new role !

From: Gary Kotton [mailto:gkot...@vmware.com]
Sent: Wednesday, September 19, 2018 11:20 AM
To: OpenStack List 
Subject: [openstack-dev] [neutron] Core status

Hi,
I have recently transitioned to a new role where I will be working on other 
parts of OpenStack. Sadly I do not have the necessary cycles to maintain my 
core responsibilities in the neutron community. Nonetheless I will continue to 
be involved.
Thanks
Gary
__
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] [router] status bug

[Bhatia, Manjeet S]

Hi neutrinos,

I was looking at Bug [1], and noticed that router status stays ACTIVE even 
after -disable ?

-openstack router -set disable router1

/opt/stack/neutron$ openstack router set --disable routerr1
vagrant@allinone:/opt/stack/neutron$ neutron router-show router1
neutron CLI is deprecated and will be removed in the future. Use openstack CLI 
instead.
+-+--+
| Field   | Value|
+-+--+
| admin_state_up  | False|
| availability_zone_hints |  |
| availability_zones  |  |
| created_at  | 2018-09-08T00:30:46Z |
| description |  |
| distributed | True |
| external_gateway_info   |  |
| flavor_id   |  |
| ha  | False|
| id  | 6f88b5f4-dc94-44bd-89cd-9c0f2b374f79 |
| name| router1   |
| project_id  | 05d72b0eff534ccf81e37b5d6e3402f6 |
| revision_number | 1|
| routes  |  |
| status  | ACTIVE   |
| tags|  |
| tenant_id   | 05d72b0eff534ccf81e37b5d6e3402f6 |
| updated_at  | 2018-09-08T00:31:18Z |





Shouldn't it update the status to DOWN  ? before I open a ticket for bug I just 
wanted to confirm it ?

[1]. https://bugs.launchpad.net/neutron/+bug/1789434



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] [neutron] Port mirroring for SR-IOV VF to VF mirroring

[Bhatia, Manjeet S]

Hi,

Yes, we need to refine spec for sure, once a consensus is reached focus will be 
on implementation,
Here’s implementation patch (WIP) https://review.openstack.org/#/c/584892/ , we 
can’t really
review api part until spec if finalized but, other stuff like config and common 
issues can
still be pointed out and progress can be made until consensus on api is 
reached. Miguel, I think
this will be added to etherpad for PTG discussions as well ?

Thanks and Regards !
Manjeet




From: Miguel Lavalle [mailto:mig...@mlavalle.com]
Sent: Tuesday, July 31, 2018 10:26 AM
To: Zhao, Forrest 
Cc: OpenStack Development Mailing List 
Subject: Re: [openstack-dev] [neutron] Port mirroring for SR-IOV VF to VF 
mirroring

Hi Forrest,

Yes, in my email, I was precisely referring to the work around 
https://review.openstack.org/#/c/574477.
 Now that we are wrapping up Rocky, I wanted to raise the visibility of this 
spec. I am glad you noticed. This week we are going to cut our RC-1 and I don't 
anticipate that we will will have a RC-2 for Rocky. So starting next week, 
let's go back to the spec and refine it, so we can start implementing in Stein 
as soon as possible. Depending on how much progress we make in the spec, we may 
need to schedule a discussion during the PTG in Denver, September 10 - 14, in 
case face to face time is needed to reach an agreement. I know that Manjeet is 
going to attend the PTG and he has already talked to me about this spec in the 
recent past. So maybe Manjeet could be the conduit to represent this spec in 
Denver, in case we need to talk about it there

Best regards

Miguel

On Tue, Jul 31, 2018 at 4:12 AM, Zhao, Forrest 
mailto:forrest.z...@intel.com>> wrote:
Hi Miguel,

In your mail “PTL candidacy for the Stein cycle”, it mentioned that “port 
mirroring for SR-IOV VF to VF mirroring” is within Stein goal.

Could you tell where is the place to discuss the design for this feature? 
Mailing list, IRC channel, weekly meeting or others?

I was involved in its spec review at https://review.openstack.org/#/c/574477/; 
but it has not been updated for a while.

Thanks,
Forrest

__
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] Bug deputy report 07/10/2018 - 07/16/2018

[Bhatia, Manjeet S]

Hi,

There were total of 6 new bugs reported. I guess everyone was busy following 
soccer finals, so not a huge amount of bugs I see were
Reported. The only Bug which I marked High priority was a documentation, which 
lacked the information about allowed dscp marking
Values.


High Priority

1.  https://bugs.launchpad.net/neutron/+bug/1781915 QoS (DSCP Mark IDs) - 
No correlation between the implemented functionality and design

looks like this bug is due to incomplete documentation, I marked it as high 
priority, since document is confusing operators about allowed

dscp marking. Some fixes to docs were proposed 
https://review.openstack.org/#/c/582979/ , 
https://review.openstack.org/#/c/582974/

Bugs of Medium importance

2.  https://bugs.launchpad.net/neutron/+bug/1781129 linuxbridge-agent 
missed updated device sometimes

fix to this also proposed https://review.openstack.org/#/c/582084/

3.  https://bugs.launchpad.net/neutron/+bug/1781179 [RFE] Send "update" 
instead of "remove" notification for dvr rescheduling

This was reported as RFE, however it didn't look like rfe to me, so I removed 
the tag, and marked it as medium

Patch was proposed and approved (https://review.openstack.org/#/c/581658/ )


Bugs Need more discussion

4.  https://bugs.launchpad.net/neutron/+bug/1781354 VPNaaS: IPsec 
siteconnection status DOWN while using IKE v2

I couldn't confirm this bug, since I did not have VPnaas setup locally, but 
this need more discussion and a fix

Is also proposed https://review.openstack.org/#/c/582113/

5.  https://bugs.launchpad.net/neutron/+bug/1782026 Routed provider network 
- DHCP agent failure

I think someone expert in routed provider network can take a look and confirm 
this.
Bugs marked Invalid or Incomplete

6.  https://bugs.launchpad.net/neutron/+bug/1782001 marked invalid



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

[openstack-dev] [neutron] Bug deputy report june 5 - June 10

[Bhatia, Manjeet S]

Hi,

There were total of 15 new bugs reported I categorized below depending on if 
they are related to CI or neutron-client or RFE. Only one
Was critical bug 1775183 for which fixed is released. There's one high priority 
 bug 1775220 confirmed. Some bugs were marked invalid
and incomplete and also listed at the bottom. Some of bugs are still not marked 
confirmed need further confirmation from related members of
Neutron community.

Bugs !


1.  https://bugs.launchpad.net/neutron/+bug/1775146 found some flow tables 
of br-int will be missing After I restarted neutron-openvswitch-agent.

2.  https://bugs.launchpad.net/neutron/+bug/1775183 Fullstack test 
neutron.tests.fullstack.test_l3_agent.TestHAL3Agent. 
test_ha_router_restart_agents_no_packet_lost fails often

3.  https://bugs.launchpad.net/neutron/+bug/1775382 
neutron-openvswitch-agent cannot start on Windows

4.  https://bugs.launchpad.net/neutron/+bug/1775496 agentschedulers: 
concurrent port delete on unscheduling may cause unscheduling to fail.

5.  https://bugs.launchpad.net/neutron/+bug/1775644 Neutron fwaas v2 group 
port binding failed

6.  https://bugs.launchpad.net/bugs/1775797 The mac table size of neutron 
bridges (br-tun, br-int, br-*) is too small by default and eventually makes 
openvswitch explode

7.  https://bugs.launchpad.net/neutron/+bug/1776160 'burst' does not take 
effect for neutron egress  qos bindlimit by ovs

RFE reported as Bug

8.  https://bugs.launchpad.net/neutron/+bug/1775250 Implement DVR-aware 
announcement of fixed IP's in neutron-dynamic-routing


Neutron CI related bugs !

9.  https://bugs.launchpad.net/neutron/+bug/1775947 
tempest.api.compute.servers.test_device_tagging.TaggedAttachmentsTest failing.

10.   https://bugs.launchpad.net/neutron/+bug/1775220 Unit test 
neutron.tests.unit.objects.test_ports.PortBindingLevelDbObjectTestCase. 
test_get_objects_queries_constant fails often.

Neutron-client

11.   https://bugs.launchpad.net/python-neutronclient/+bug/1775922 neutron 
net-list with pagination fails on too many subnets

Bugs marked Invalid or Incomplete

12.   https://bugs.launchpad.net/neutron/+bug/1775310 Unused namespace is 
appeared.

13.   https://bugs.launchpad.net/neutron/+bug/1775415 pagination for list 
operations behaves inconsistently

14.   https://bugs.launchpad.net/bugs/1775580 Networking Option 2: Self-service 
networks in Neutron

15.   https://bugs.launchpad.net/neutron/+bug/1775758 Deprecated auth_url 
entries in Neutron Queen's install guide


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

[openstack-dev] [neutron][l3][flavors][floatingip] FFE request for patch no 523257 and 532993

[Bhatia, Manjeet S]

Hello all !

I'd like to request a FFE for patch 523257 [1] that adds new resources and 
events to handle operations
For routers if L3 flavors framework is used. The neutron-lib part is already 
merged [lib] thanks to Boden and
Miguel for quick reviews on that. The second patch 53993 [2] adds the missing 
notifications for floatingip update
and delete events without which l3 flavor drivers Backends isn't able to 
perform the update and delete operations
on floatingip's correctly. These two patches are needed for L3 flavors driver 
in networking-odl [nodll3].


[1]. https://review.openstack.org/#/c/523257
[2]. https://review.openstack.org/#/c/532993

[lib] https://review.openstack.org/#/c/535512/
[nodll3] https://review.openstack.org/#/c/504182/


Sorry for 2nd email on this I forgot to add [openstack-dev] subject in last one.


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

[openstack-dev] [neutron][l3][flavors] FFE request for patch no 523257 and 532993

[Bhatia, Manjeet S]

Hello all !

I'd like to request a FFE for patch 523257 [1] that adds new resources and 
events to handle operations
For routers if L3 flavors framework is used. The neutron-lib part is already 
merged [lib] thanks to Boden and
Miguel for quick reviews on that. The second patch 53993 [2] adds the missing 
notifications for floatingip update
and delete events without which l3 flavor drivers Backends isn't able to 
perform the update and delete operations
on floatingip's correctly. These two patches are needed for L3 flavors driver 
in networking-odl [nodll3].


[1]. https://review.openstack.org/#/c/523257
[2]. https://review.openstack.org/#/c/532993

[lib] https://review.openstack.org/#/c/535512/
[nodll3] https://review.openstack.org/#/c/504182/


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

[openstack-dev] [neutron][l3][flavors][floatingip]

[Bhatia, Manjeet S]

Hi Neutrinos,

I am working on L3 flavors driver implementation for ODL backend, In l3 
Flavor's driver there is need to fetch flavors id on floatingip operations,
So that if floatingip is not for association with router of that flavor, driver 
can ignore the operation and return, but I noticed there's router_id
None In floatingip payload sent to driver in networking-odl by neutron.

What I did was


1.   Create an router of xyz flavor.

2.   Added public-subnet interface to that router.

3.   Created floatingip on that public network.

I see None router_id being sent in payload [a]. for floatingip operation. I am 
not sure if this is intended, I think it is a bug otherwise I don't see
Other way of discarding floating ip operation by l3 flavors driver if it is not 
gonna be associated with router of that flavor.


[a]. http://paste.openstack.org/show/646543/


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] [neutron][networking-odl]

[Bhatia, Manjeet S]

> -Original Message-
> From: Takashi Yamamoto [mailto:yamam...@midokura.com]
> Sent: Tuesday, November 7, 2017 10:13 PM
> To: Bhatia, Manjeet S <manjeet.s.bha...@intel.com>
> Cc: openstack-dev@lists.openstack.org
> Subject: Re: [openstack-dev] [neutron][networking-odl]
> 
> hi,
> 
> On Thu, Nov 2, 2017 at 9:01 AM, Bhatia, Manjeet S
> <manjeet.s.bha...@intel.com> wrote:
> > Hello Neutrinos,
> >
> >
> >
> > I’ve been trying service profile flavors for L3 in neutron to register
> > the driver,
> >
> > the method I’ve been using is below
> >
> >
> >
> > I have this added to neutron.conf
> >
> > [service_providers]
> >
> > service_provider =
> > L3_ROUTER_NAT:ODL:networking_odl.l3.l3_flavor.ODLL3ServiceProvider:def
> > ault
> 
> where do you have this driver?

In networking-odl local repo as WIP. 

> 
> >
> >
> >
> > and then tried creating flavor profile
> >
> > [a]. openstack network flavor profile create --driver
> > networking_odl.l3.l3_flavor.ODLL3ServiceProvider
> >
> >
> >
> > It returns NotFoundException: Not Found (HTTP 404) (Request-ID:
> > req-6991a8ab-b785-4160-96d6-e496d7667f15), Service Profile driver
> > networking_odl.l3.l3_flavor.ODLL3ServiceProvider could not be found.
> >
> >
> >
> > Here is trace from log http://paste.openstack.org/show/625178/ seems
> > like resource not found,
> >
> >
> >
> > But I also noticed in [1]. self.config is {}
> >
> >
> >
> >
> >
> > [1].
> > https://github.com/openstack/neutron/blob/master/neutron/db/servicetyp
> > e_db.py#L55
> >
> >
> >
> >
> >
> > Any pointers what’s being done wrong is it the enabling of service
> > profiles flavor or something else ?
> >
> >
> >
> >
> >
> >
> >
> > Thanks and regards !
> >
> > Manjeet
> >
> >
> >
> >
> >
> >
> >
> >
__
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][networking-odl]

[Bhatia, Manjeet S]

Hello Neutrinos,

I've been trying service profile flavors for L3 in neutron to register the 
driver,
the method I've been using is below

I have this added to neutron.conf
[service_providers]
service_provider = 
L3_ROUTER_NAT:ODL:networking_odl.l3.l3_flavor.ODLL3ServiceProvider:default

and then tried creating flavor profile
[a]. openstack network flavor profile create --driver 
networking_odl.l3.l3_flavor.ODLL3ServiceProvider

It returns NotFoundException: Not Found (HTTP 404) (Request-ID: 
req-6991a8ab-b785-4160-96d6-e496d7667f15), Service Profile driver 
networking_odl.l3.l3_flavor.ODLL3ServiceProvider could not be found.

Here is trace from log http://paste.openstack.org/show/625178/ seems like 
resource not found,

But I also noticed in [1]. self.config is {}


[1]. 
https://github.com/openstack/neutron/blob/master/neutron/db/servicetype_db.py#L55


Any pointers what's being done wrong is it the enabling of service profiles 
flavor or something else ?



Thanks and regards !
Manjeet




__
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][horizon] FWaaS/VPNaaS dashboard split out from horizon

[Bhatia, Manjeet S]

> -Original Message-
> From: Akihiro Motoki [mailto:amot...@gmail.com]
> Sent: Wednesday, May 31, 2017 6:13 AM
> To: OpenStack Development Mailing List 
> Subject: [openstack-dev] [neutron][horizon] FWaaS/VPNaaS dashboard split
> out from horizon
> 
> Hi all,
> 
> As discussed last month [1], we agree that each neutron-related dashboard has
> its own repository.
> I would like to move this forward on FWaaS and VPNaaS as the horizon team
> plans to split them out as horizon plugins.
> 
> A couple of questions hit me.
> 
> (1) launchpad project
> Do we create a new launchpad project for each dashboard?
> At now, FWaaS and VPNaaS projects use 'neutron' for their bug tracking from
> the historical reason, it sometimes There are two choices: the one is to 
> accept
> dashboard bugs in 'neutron' launchpad, and the other is to have a separate
> launchpad project.

+1 for separating Launchpad we can one for each and each can cover all the 
issues related
To it. 

> My vote is to create a separate launchpad project.
> It allows users to search and file bugs easily.
> 
> (2) repository name
> 
> Are neutron-fwaas-dashboard / neutron-vpnaas-dashboard good repository
> names for you?
> Most horizon related projects use -dashboard or -ui as their repo
> names.
> I personally prefers to -dashboard as it is consistent with the OpenStack
> dashboard (the official name of horizon). On the other hand, I know some folks
> prefer to -ui as the name is shorter enough.
> Any preference?

Both looks good, but using ui will make it shorter so +1 for ui

> (3) governance
> neutron-fwaas project is under the neutron project.
> Does it sound okay to have neutron-fwaas-dashboard under the neutron
> project?
> This is what the neutron team does for neutron-lbaas-dashboard before and
> this model is adopted in most horizon plugins (like trove, sahara or others).

IMO, we can have it under neutron project for now but for simplicity and
maintenance I'd suggest to branch it out from neutron.

> (4) initial core team
> 
> My thought is to have neutron-fwaas/vpnaas-core and horizon-core as the
> initial core team.
> The release team and the stable team follow what we have for neutron-
> fwaas/vpnaas projects.
> Sounds reasonable?
> 
> 
> Finally, I already prepare the split out version of FWaaS and VPNaaS
> dashboards in my personal github repos.
> Once we agree in the questions above, I will create the repositories under
> git.openstack.org.
> 
> [1] http://lists.openstack.org/pipermail/openstack-dev/2017-
> April/thread.html#115200
> 
> _
> _
> 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][all] So long, and thanks for all the fish

[Bhatia, Manjeet S]

Good luck !! it was nice working with you. 

> -Original Message-
> From: John Davidge [mailto:john.davi...@rackspace.com]
> Sent: Tuesday, May 2, 2017 3:08 AM
> To: OpenStack Development Mailing List (not for usage questions)  d...@lists.openstack.org>
> Subject: [openstack-dev] [neutron][all] So long, and thanks for all the fish
> 
> Friends and colleagues,
> 
> It is with a heavy heart that I write to say my adventure in the OpenStack
> community is coming to an end. It began in 2012 with my first job as an intern
> at Cisco, and ends here as the Technical Lead for Neutron in the OpenStack
> Innovation Center at Rackspace.
> 
> In that time I’ve worked with a great many wonderful people from all corners
> of this community, on a variety of projects that I’m proud to include my name
> in the commit logs. Thank you all for creating an exciting place to work, to
> debate, and occasionally to argue about the incredible democratizing power
> that is OpenStack. Your passion and expertise are an inspiration to the world.
> 
> Regretfully, I’m leaving a void in both the Neutron team and the OpenStack
> Manuals team. Neutron will need a new Docs liaison, and OpenStack Manuals
> will need a new lead for the Networking Guide. The cross-project work we’ve
> done together over the last couple of cycles has been engaging and fulfilling,
> and I encourage anyone interested in either or both roles to get in touch with
> Kevin Benton and Alexandra Settle.
> 
> Good luck and best wishes to all of you in the future.
> 
> Until we meet again,
> 
> John
> 
> 
> 
> Rackspace Limited is a company registered in England & Wales (company
> registered number 03897010) whose registered office is at 5 Millington Road,
> Hyde Park Hayes, Middlesex UB3 4AZ. Rackspace Limited privacy policy can be
> viewed at www.rackspace.co.uk/legal/privacy-policy - This e-mail message may
> contain confidential or privileged information intended for the recipient. Any
> dissemination, distribution or copying of the enclosed material is 
> prohibited. If
> you receive this transmission in error, please notify us immediately by 
> e-mail at
> ab...@rackspace.com and delete the original message. Your cooperation is
> appreciated.
> _
> _
> 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][qos] qos service enabling in test env

[Bhatia, Manjeet S]

Hi neutrinos,

I reported a bug in plugin been sending stale data to mechanism driver [1].
Which was fixed by [2].  I am trying to write a test case as well, but seems 
like
I am unable to see success for enabling qos service properly in test environment

In neutron/tests/unit/plugins/ml2/test_plugin.TestMl2NetworksV2

What I did to enable it was, in setup() I've added.
  config.cfg.CONF.set_override('service_plugins', ['qos'])
  config.cfg.CONF.set_override('extension_drivers',
['qos', 
'port_security'], 'ml2')


When I create network without qos_policy_id in data, the request 
self.new_create_request('networks',  data)
Does not show qos_policy_id in it, but when I call 
self.new_create_request('networks',  data) and data
has qos_policy_id from policy created via QoSPlugin it returns response bad 
request 400.

I believe it is because of qos not being enabled in test environment properly ? 
any idea what is wrong with
Enabling qos ? or anything I am missing to enable it in test env ?


[1]. https://bugs.launchpad.net/neutron/+bug/1675135
[2]. https://review.openstack.org/#/c/448754/

__
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][gate-grenade-linuxbridge-multinode] experimenting gate-grenade-linuxbridge-multinode job

[Bhatia, Manjeet S]

Hi neutrinos,

I've been experimenting with 
gate-grenade-dsvm-neutron-linuxbridge-multinode-ubuntu-xenial-nv
 job,
So far I've tried forcing tempest concurrency, as depends on tag not work with 
project config, I have a
Experimental patch in devstack-gate [1]. On which depends on will work I 
believe. My observation is
Job is failing when scheduled on rax-node cloud, from timestamps I see 
difference b/w case when it pass [2],
Case when it fails [3]. Looking at timestamps it seems like it is taking more 
time for some reason.

I have increased the OS_TEST_TIMEOUT in [1]. which 500 by default in tempest. I 
need some volunteers
To add a tag Depends-On: changeId of [1].  I'd really appreciate if 2 or 3 
patches can do that.
I can also chose patches randomly if no one has any objection.

[1]. https://review.openstack.org/#/c/448218/
[2]. 
http://logs.openstack.org/25/338625/39/check/gate-grenade-dsvm-neutron-linuxbridge-multinode-ubuntu-xenial-nv/2398bd7/logs/grenade.sh.txt.gz#_2017-03-22_06_26_18_485
[3]. 
http://logs.openstack.org/25/338625/38/check/gate-grenade-dsvm-neutron-linuxbridge-multinode-ubuntu-xenial-nv/59034b8/logs/grenade.sh.txt.gz#_2017-03-22_00_19_32_894


Thanks and Regards !
Manjeet
__
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] - Team photo

[Bhatia, Manjeet S]

+1

From: Kevin Benton [mailto:ke...@benton.pub]
Sent: Friday, February 17, 2017 3:08 PM
To: openstack-dev@lists.openstack.org
Subject: [openstack-dev] [neutron] - Team photo

Hello!

Is everyone free Thursday at 11:20AM (right before lunch break) for 10 minutes 
for a group photo?

Cheers,
Kevin Benton
__
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 team social in Atlanta on Thursday

[Bhatia, Manjeet S]

+1

From: Kevin Benton [mailto:ke...@benton.pub]
Sent: Friday, February 17, 2017 11:19 AM
To: openstack-dev@lists.openstack.org
Subject: [openstack-dev] [neutron] - Neutron team social in Atlanta on Thursday

Hi all,

I'm organizing a Neutron social event for Thursday evening in Atlanta somewhere 
near the venue for dinner/drinks. If you're interested, please reply to this 
email with a "+1" so I can get a general count for a reservation.

Cheers,
Kevin Benton
__
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] [horizon] [neutron] Horizon support for Neutron Trunks - PTL approval needed

[Bhatia, Manjeet S]

My opinion is separate UI repo for just a feature would be hard to maintain,
I like the idea to either create entire neutron-UI but that again raise the
question will there be enough contributors or maintainers ? so horizon is the 
best place
To have the UI part.

-Manjeet
From: Akihiro Motoki [mailto:amot...@gmail.com]
Sent: Monday, February 6, 2017 5:18 AM
To: OpenStack Development Mailing List (not for usage questions) 

Subject: Re: [openstack-dev] [horizon] [neutron] Horizon support for Neutron 
Trunks - PTL approval needed

I have the same opinion as Kevin,
UI support for a feature in the neutron repo should be in the main horizon repo.

I believe this improves usability too.
If I have a neutron deployment (it is a typical deployment now),
I would like to use neutron feature support only after installing the main 
horizon
(though there are several feature gaps).

Akihiro


2017-02-06 19:50 GMT+09:00 Kevin Benton 
>:
Well the UIs for the extensions inside the main Neutron repo are in the main 
horizon repo so far (e.g. routers, floating IPs, security groups, etc). LBaaS 
is a separate repo with separate devs so it makes sense to me that it would 
have its own UI repo.

Trunks would be the the first extension that lives in the Neutron tree that 
would have its own UI repo living somewhere else. I don't see how we could 
avoid bitrot (or find UI contributors in the first place) if every upstream 
feature will be expected to have its own UI repo, core team, bug tracker, and 
release management. That will be a huge overhead to adding support for new 
neutron features.


On Feb 6, 2017 03:36, "Rob Cresswell (rcresswe)" 
> wrote:
Core Neutron features should be within Horizon, with extensions outside. This 
is a little hazy since even the default behaviour in Neutron is still a plugin, 
but thats the general idea. There are already some features outside, like the 
lbaas dashboard. Personally, I’d keep them in their own repo; makes it much 
easier to manage scope. It’d be a huge pain if one extensions UI holds up 
others at release time due to broken tests etc.

Rob

> On 6 Feb 2017, at 07:02, Richard Jones 
> > wrote:
>
> That idea has merit, though I don't know what the scope for such a
> 'neutron-ui' might be. I'm definitely supportive of the Neutron Trunks
> UI efforts, but it'd be good to get an answer on this scope question
> before rolling along and creating the project.
>
>
>Richard
>
> On 6 February 2017 at 12:14, Kevin Benton 
> > wrote:
>> If the horizon team would like neutron features to live outside, I wonder if
>> it would make more sense to create a new 'neutron-ui' repo instead of it
>> being trunk specific. That way we don't have to come up with a new repo for
>> every new feature that needs a horizon UI.
>>
>> On Feb 3, 2017 09:26, "Bence Romsics" 
>> > wrote:
>>>
>>> Hi All,
>>>
>>> I'd like to add support for Neutron Trunks [1][2] into Horizon
>>> together with a few colleagues in the Pike cycle. We thought of
>>> writing a new Horizon plugin [3] for that purpose. That way I hope to
>>> keep it optional for deployment and minimize the maintenance cost for
>>> the Horizon core team. Of course we'd welcome all review feedback,
>>> especially from the Horizon and Neutron teams.
>>>
>>> To host the work I'd like create a new project: openstack/neutron-trunk-ui
>>>
>>> Following the Project Creator's Guide, here's a proposed new project
>>> config:
>>>
>>> https://review.openstack.org/428730
>>>
>>> And the corresponding governance change:
>>>
>>> https://review.openstack.org/428796
>>>
>>> Please review them and if you agree approve. Or guide me to a better
>>> change.
>>>
>>> Thanks in advance,
>>> Bence Romsics
>>>
>>> [1]
>>> https://github.com/openstack/openstack-manuals/blob/master/doc/networking-guide/source/config-trunking.rst
>>> [2] https://wiki.openstack.org/wiki/Neutron/TrunkPort
>>> [3] http://docs.openstack.org/developer/horizon/tutorials/plugin.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
>>
>
> 

[openstack-dev] FW: [neutron][all] Intermittent gate failures across multiple projects

[Bhatia, Manjeet S]

Hi neutrinos !

There is an Intermittent failure observed on gate jobs,
I saw same failure of one of my patches, It was on keystone
Phase for twice I checked.

Thanks and Regards !
Manjeet Singh Bhatia

From: John Villalovos [mailto:openstack@sodarock.com]
Sent: Thursday, December 22, 2016 3:41 PM
To: openstack-dev 
Subject: [openstack-dev] [all] Intermittent gate failures across multiple 
projects

Gate jobs seem to be intermittently broken across all of OpenStack.

Bug filed:
https://bugs.launchpad.net/openstack-gate/+bug/1652186
They appear during the keystone phase of devstack and look like this:

http://logs.openstack.org/39/414339/2/check/gate-tempest-dsvm-ironic-ipa-partition-pxe_snmp-tinyipa-ubuntu-xenial-nv/1d5e63d/logs/devstacklog.txt.gz#_2016-12-22_22_25_10_787

2016-12-22 
22:25:08.607
 | 2016-12-22 22:25:08.606 31714 INFO keystone.cmd.cli 
[req-f336127d-0628-4b9d-bcc7-a87863c3127e - - - - -] Created domain default

2016-12-22 
22:25:08.637
 | 2016-12-22 22:25:08.637 31714 INFO keystone.cmd.cli 
[req-f336127d-0628-4b9d-bcc7-a87863c3127e - - - - -] Created project admin

2016-12-22 
22:25:08.657
 | 2016-12-22 22:25:08.656 31714 DEBUG passlib.registry 
[req-f336127d-0628-4b9d-bcc7-a87863c3127e - - - - -] registered 'sha512_crypt' 
handler:  
register_crypt_handler 
/usr/local/lib/python2.7/dist-packages/passlib/registry.py:294

2016-12-22 
22:25:08.684
 | 2016-12-22 22:25:08.684 31714 INFO keystone.cmd.cli 
[req-f336127d-0628-4b9d-bcc7-a87863c3127e - - - - -] Created user admin

2016-12-22 
22:25:08.700
 | 2016-12-22 22:25:08.699 31714 INFO keystone.cmd.cli 
[req-f336127d-0628-4b9d-bcc7-a87863c3127e - - - - -] Created role admin

2016-12-22 
22:25:08.714
 | 2016-12-22 22:25:08.714 31714 INFO keystone.cmd.cli 
[req-f336127d-0628-4b9d-bcc7-a87863c3127e - - - - -] Granted admin on admin to 
user admin.

2016-12-22 
22:25:08.731
 | 2016-12-22 22:25:08.730 31714 INFO keystone.cmd.cli 
[req-f336127d-0628-4b9d-bcc7-a87863c3127e - - - - -] Created region RegionOne

2016-12-22 
22:25:08.763
 | 2016-12-22 22:25:08.763 31714 INFO keystone.cmd.cli 
[req-f336127d-0628-4b9d-bcc7-a87863c3127e - - - - -] Created admin endpoint 
http://15.184.67.84/identity_admin

2016-12-22 
22:25:08.775
 | 2016-12-22 22:25:08.774 31714 INFO keystone.cmd.cli 
[req-f336127d-0628-4b9d-bcc7-a87863c3127e - - - - -] Created internal endpoint 
http://15.184.67.84/identity

2016-12-22 
22:25:08.787
 | 2016-12-22 22:25:08.787 31714 INFO keystone.cmd.cli 
[req-f336127d-0628-4b9d-bcc7-a87863c3127e - - - - -] Created public endpoint 
http://15.184.67.84/identity

2016-12-22 
22:25:08.793
 | 2016-12-22 22:25:08.793 31714 INFO keystone.assignment.core 
[req-f336127d-0628-4b9d-bcc7-a87863c3127e - - - - -] Creating the default role 
9fe2ff9ee4384b1894a90878d3e92bab because it does not exist.

2016-12-22 
22:25:08.923
 | + ./stack.sh:main:1065

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

[Bhatia, Manjeet S]

Henry,

Sad to see you stepping down, it was great learning experience working
With you. Thanks for all your help.

Best wishes !

Manjeet
> -Original Message-
> From: Henry Gessau [mailto:hen...@gessau.net]
> Sent: Thursday, December 1, 2016 2:51 PM
> To: OpenStack Development Mailing List 
> Subject: [openstack-dev] [Neutron] Stepping down from core
> 
> I've already communicated this in the neutron meeting and in some neutron
> policy patches, but yesterday the PTL actually updated the gerrit ACLs so I
> thought I'd drop a note here too.
> 
> My work situation has changed and leaves me little time to keep up with my
> duties as core reviewer, DB lieutenant, and drivers team member.
> 
> Working with the diverse and very talented contributors to Neutron has been
> the best experience of my career (which started before many of you were
> born).
> Thank you all for making the team such a great community. Because of you the
> project is thriving and will continue to be successful!
> 
> I will still be around on IRC, contribute some small patches here and there, 
> and
> generally try to keep abreast of Neutron's progress. Don't hesitate to ping 
> me.
> 
> _
> _
> 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] proper cleanup of l3 resources (neutron-netns-cleanup)

[Bhatia, Manjeet S]

Hi,

Approach I am following is not cleaning blindly, there is utility in cleanup 
which I’ll use
To get eligible namespace candidates for cleanup (need to deep dive this logic 
how effective is that)
Then will extract id from namespace either using namespace manager or l3 agent 
code,
And call on l3 agent to cleanup respective namespaces.

and to check cleanup, I am creating a router and setting just a gateway which 
create namespace,
don’t add any interface, I see it cleans up qrouter-namespace but and I can 
still see router when I do router-list, which shouldn’t be there, people having 
knowledge on this pls correct me if I am wrong ?

Thanks and Regards !
Manjeet Singh Bhatia

From: Sergey Belous [mailto:sbel...@mirantis.com]
Sent: Tuesday, October 11, 2016 3:54 AM
To: OpenStack Development Mailing List (not for usage questions) 

Subject: Re: [openstack-dev] [neutron] proper cleanup of l3 resources 
(neutron-netns-cleanup)

Hi, Miguel.

As I can see, Manjeet Singh Bhatia already proposed the change on review 
[1]—this patch adds the invoking a cleanup provided by l3-agent.
Actually, I like the option 2. And I'm going to implement it and compare to 
Manjeet's solution.
But can anybody suggest me, how can I manually reproduce the situation where 
netns-clean is needed to run for cleanup l3 namespaces? In which state should 
be these namespaces?

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

On 7 Oct 2016, at 15:38, Miguel Angel Ajo Pelayo 
> wrote:

Hi Sergey!,

This was my point of view on a possible solution:

https://bugs.launchpad.net/neutron/+bug/1403455/comments/12

"""
After much thinking (and quite little doing) I believe the option "2"
I proposed is a rather reasonable one:

2) Before cleaning a namespace blindly in the end, identify any
network service in the namespace (via netstat), kill those processes,
so they aren't orphaned, and then, kill the namespace.

Any process should be safely killed that way, and if it's not, we can
complicate our lifes and code with "1":
1) Use stevedore HookManager to let out-of-tree repos register netns
prefixes declaration, and netns cleaners,
   so every piece of code (in-tree or out-of-tree) declare which
netns prefixes they use, and provide a netns cleanup
   hook to be called.

"""

Let me know what you think

On Fri, Oct 7, 2016 at 2:15 PM, Sergey Belous 
> wrote:

Hello everyone.

I’m very interesting in this one
https://bugs.launchpad.net/neutron/+bug/1403455
Can anybody tell me, what is the current status of this bug? Is anybody
working on it now?
And as I can see, there are some options, that was discussed in comments to
this bug and… did anybody decide which solution is the best?


--
Best Regards,
Sergey Belous


__
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

--
Best Regards,
Sergey Belous

__
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] clean up your git checkout!

[Bhatia, Manjeet S]

> -Original Message-
> From: Ihar Hrachyshka [mailto:ihrac...@redhat.com]
> Sent: Friday, September 30, 2016 7:03 AM
> To: OpenStack Development Mailing List (not for usage questions)  d...@lists.openstack.org>
> Subject: [openstack-dev] [neutron] clean up your git checkout!
> 
> Hi all,
> 
> today we landed https://review.openstack.org/#/c/269658/ (huge!) that
> removed neutron/objects/network/ directory and replaced it with
> neutron/objects/network.py file. Though it makes python that sees old .pyc
> files sad:
> 
> Failed to import test module: neutron.tests.unit.objects.test_network
> Traceback (most recent call last):
>File "/home/vagrant/git/neutron/.tox/py27/lib/python2.7/site-
> packages/unittest2/loader.py", line 456, in _find_test_path
>  module = self._get_module_from_name(name)
>File "/home/vagrant/git/neutron/.tox/py27/lib/python2.7/site-
> packages/unittest2/loader.py", line 395, in _get_module_from_name
>  __import__(name)
>File "neutron/tests/unit/objects/test_network.py", line 23, in 
>  obj_test_base.BaseObjectIfaceTestCase):
>File "neutron/tests/unit/objects/test_network.py", line 24, in
> NetworkPortSecurityIfaceObjTestCase
>  _test_class = network.NetworkPortSecurity
> AttributeError: 'module' object has no attribute 'NetworkPortSecurity'
> The test run didn't actually run any tests

Because of it I screwed a review, I was getting exact same error. 
> 
> Please run git clean -f -x in your checkout to remove all .pyc files. This 
> should
> solve any import issues you may experience due to the new patch.
> 
> Cheers,
> 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]midcycle slide deck for upgrades

[Bhatia, Manjeet S]

Ihar,

 +1 good informative, slides !!  

-Original Message-
From: Ihar Hrachyshka [mailto:ihrac...@redhat.com] 
Sent: Wednesday, August 17, 2016 9:28 AM
To: OpenStack Development Mailing List (not for usage questions) 

Subject: [openstack-dev] [neutron]midcycle slide deck for upgrades

Hi all,

I delivered some introduction into upgrade matters, specifically focusing on 
versioned objects fitting into the strategy, at midcycle today. Several people 
asked me to share the slide deck with them. I should probably just share it 
with everyone, in case someone can make use of it.

https://docs.google.com/presentation/d/18sqjQhNU_SnzNPy4WGJ4pH9-kaPvzJUVnYOo0Vc9AwU/edit?usp=sharing

Hope this helps.

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

[Bhatia, Manjeet S]

Ihar Hrachyshka  wrote:
> Manjeet S  wrote:
> 
>> Hello Team,
>>
>> I have a question regarding centralizing all db models in neutron. As 
>> you all know Oslo versioned object work is under progress and I also 
>> had a ticket opened for refactoring Db models. 
>> (https://bugs.launchpad.net/neutron/+bug/1597913). There are three 
>> way I can do this, 1, move all models to db/models_v2.py 2, create a 
>> new dir db/models/ and move whatever models are giving issue Of 
>> cyclic import to db_models.py under db/models/ tree but all in same 
>> file, 3rd is move into different files under Same tree db/models. I 
>> liked second way better, please let me know which one according to 
>> experienced developers is better, I’ll do that way.
> 
> I don’t think 2. is the best way forward because it still keeps all 
> models in a single file with no classification. I prefer we split 
> models by topic, so option 3.
> 
> I took the approach for security groups here:  
> https://review.openstack.org/#/c/284738/49/neutron/db/models/securityg
> roup.py

>I also prefer this organization (option 3).

Ok thanks will follow 3.


__
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][db][models]

[Bhatia, Manjeet S]

Hello Team,

I have a question regarding centralizing all db models in neutron. As you all 
know
Oslo versioned object work is under progress and I also had a ticket opened for 
refactoring
Db models. (https://bugs.launchpad.net/neutron/+bug/1597913). There are three 
way I can do this,
1, move all models to db/models_v2.py 2, create a new dir db/models/ and move 
whatever models are giving issue
Of cyclic import to db_models.py under db/models/ tree but all in same file, 
3rd is move into different files under
Same tree db/models. I liked second way better, please let me know which one 
according to experienced developers
is better, I'll do that way.


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] [Neutron] Proposing Jakub Libosvar for testingcore

[Bhatia, Manjeet S]

Ofcourse insightful reviewers will make development fast.

So ++

From: Darek Śmigiel [mailto:smigiel.dari...@gmail.com]
Sent: Friday, July 22, 2016 7:20 AM
To: OpenStack Development Mailing List (not for usage questions) 

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

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

__
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 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] [neutron][linux bridge]

[Bhatia, Manjeet S]

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