Re: [openstack-dev] [neutron] Rotating the weekly Neutron meeting

[Assaf Muller]

This is fantastic, thank you.

- Original Message -
 +1
 
 PCM (Paul Michali)
 
 MAIL …..…. p...@cisco.com
 IRC ……..… pcm_ (irc.freenode.com)
 TW ………... @pmichali
 GPG Key … 4525ECC253E31A83
 Fingerprint .. 307A 96BB 1A4C D2C7 931D 8D2D 4525 ECC2 53E3 1A83
 
 
 
 On Aug 13, 2014, at 10:05 AM, Kyle Mestery mest...@mestery.com wrote:
 
  Per this week's Neutron meeting [1], it was decided that offering a
  rotating meeting slot for the weekly Neutron meeting would be a good
  thing. This will allow for a much easier time for people in
  Asia/Pacific timezones, as well as for people in Europe.
  
  So, I'd like to propose we rotate the weekly as follows:
  
  Monday 2100UTC
  Tuesday 1400UTC
  
  If people are ok with these time slots, I'll set this up and we'll
  likely start with this new schedule in September, after the FPF.
  
  Thanks!
  Kyle
  
  [1]
  http://eavesdrop.openstack.org/meetings/networking/2014/networking.2014-08-11-21.00.html
  
  ___
  OpenStack-dev mailing list
  OpenStack-dev@lists.openstack.org
  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 
 
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron] Juno-3 BP meeting

[Assaf Muller]

Good for me.

- Original Message -
 Works perfect for me. I will join.
 
 Sent from my Android phone using TouchDown ( www.nitrodesk.com )
 
 
 -Original Message-
 From: Carl Baldwin [c...@ecbaldwin.net]
 Received: Wednesday, 27 Aug 2014, 5:07
 To: OpenStack Development Mailing List [openstack-dev@lists.openstack.org]
 Subject: Re: [openstack-dev] [neutron] Juno-3 BP meeting
 
 
 
 
 Kyle,
 
 These are three good ones. I've been reviewing the HA ones and have had an
 eye on the other two.
 
 1300 is a bit early but I'll plan to be there.
 
 Carl
 On Aug 26, 2014 4:04 PM, Kyle Mestery  mest...@mestery.com  wrote:
 
 
 I'd like to propose a meeting at 1300UTC on Thursday in
 #openstack-meeting-3 to discuss Neutron BPs remaining for Juno at this
 point. We're taking specifically about medium and high priority ones,
 with a focus on these three:
 
 https://blueprints.launchpad.net/neutron/+spec/l3-high-availability )
 https://blueprints.launchpad.net/neutron/+spec/add-ipset-to-security )
 https://blueprints.launchpad.net/neutron/+spec/security-group-rules-for-devices-rpc-call-refactor
 )
 
 These three BPs will provide a final push for scalability in a few
 areas and are things we as a team need to work to merge this week. The
 meeting will allow for discussion of final issues on these patches
 with the goal of trying to merge them by Feature Freeze next week. If
 time permits, we can discuss other medium and high priority community
 BPs as well.
 
 Let me know if this works by responding on this thread and I hope to
 see people there Thursday!
 
 Thanks,
 Kyle
 
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Validation of IP

[Assaf Muller]

You can instead use netaddr:
import netaddr
try:
netaddr.IPAddress(input)
except AddrFormatError:
logging.error('Nope!')
else:
doSomethingWith(input)

You could also:
if netaddr.IPAddress('10.0.0.1') in netaddr.IPNetwork('10.0.0.0/8'):
logging.error('Yup!')


Assaf Muller, Cloud Networking Engineer 
Red Hat 

- Original Message -
From: iKhan ik.ibadk...@gmail.com
To: openstack-dev openstack-dev@lists.openstack.org
Sent: Tuesday, January 21, 2014 4:55:05 AM
Subject: [openstack-dev] Validation of IP

Hi, 

I am planning to validate an IP which is accepted part of input from user in 
cinder, I need to verify if IP address is valid and it is up in the network. 
The dirty way or only way that I know as of now is to create a socket object 
and perform inet_aton() and gethostbyaddr() 

Jut worried if these operations are safe to perform. 

-- 
Thanks, 
Ibad Khan 
9686594607 

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Openstack-dev][All] tox 1.7.0 error while running tests

[Assaf Muller]

- Original Message -
 From: Swapnil Kulkarni swapnilkulkarni2...@gmail.com
 To: OpenStack Development Mailing List (not for usage questions) 
 openstack-dev@lists.openstack.org
 Sent: Tuesday, February 11, 2014 11:26:29 AM
 Subject: [openstack-dev] [Openstack-dev][All] tox 1.7.0 error while running   
 tests
 
 Hello,
 
 I created a new devstack environment today and installed tox 1.7.0, and
 getting error tox.ConfigError: ConfigError: substitution key 'posargs' not
 found.
 
 Details in [1].
 
 Anybody encountered similar error before? Any workarounds/updates needed?

It's a known issue, and for a workaround personally I downgraded to tox 1.6.1.

 
 [1] http://paste.openstack.org/show/64178/
 
 
 Best Regards,
 Swapnil Kulkarni
 irc : coolsvap
 
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Neutron] DVR blueprint document locked / private

[Assaf Muller]

Regarding the DVR blueprint [1], I noticed that its corresponding Google Doc [2]
has been private / blocked for nearly a week now. It's very difficult to 
participate
in upstream design discussions when the document is literally locked.

I would appreciate the re-opening of the document, especially considering the 
recent
face to face meeting and the contested discussion points that were raised.

[1] https://blueprints.launchpad.net/neutron/+spec/neutron-ovs-dvr
[2] 
https://docs.google.com/document/d/1iXMAyVMf42FTahExmGdYNGOBFyeA4e74sAO3pvr_RjA/edit


Thank you,
Assaf Muller, Cloud Networking Engineer 
Red Hat 

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron]Can somebody describe the all the rolls about networks' admin_state_up

[Assaf Muller]

- Original Message -
 Hi,
 
 I want to know the admin_state_up attribute about networks but I
 have not found any describes.
 
 Can you help me to understand it? Thank you very much.
 

There's a discussion about this in this bug [1].
From what I gather, nobody knows what admin_state_up is actually supposed
to do with respect to networks.

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

 
 Regard,
 
 Lee Li
 
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Neutron] L3 HA VRRP concerns

[Assaf Muller]

Hi everyone,

A few concerns have popped up recently about [1] which I'd like to share and 
discuss,
and would love to hear your thoughts Sylvain.

1) Is there a way through the API to know, for a given router, what agent is 
hosting
the active instance? This might be very important for admins to know.

2) The current approach is to create an administrative network and subnet for 
VRRP traffic per router group /
per router. Is this network counted in the quota for the tenant? (Clearly it 
shouldn't). Same
question for the HA ports created for each router instance.

3) The administrative network is created per router and takes away from the 
VLAN ranges if using
VLAN tenant networks (For a tunneling based deployment this is a non-issue). 
Maybe we could
consider a change that creates an administrative network per tenant (Which 
would then limit
the solution to up to 255 routers because of VRRP'd group limit), or an admin 
network per 255
routers?

4) Maybe the VRRP hello and dead times should be configurable? I can see admins 
that would love to
up or down these numbers.

5) The administrative / VRRP networks, subnets and ports that are created - 
Will they be marked in any way
as an 'internal' network or some equivalent tag? Otherwise they'd show up when 
running neutron net-list,
in the Horizon networks listing as well as the graphical topology drawing 
(Which, personally, is what
bothers me most about this). I'd love them tagged and hidden from the normal 
net-list output,
and something like a 'neutron net-list --all' introduced.

6) The IP subnet chosen for VRRP traffic is specified in neutron.conf. If a 
tenant creates a subnet
with the same range, and attaches a HA router to that subnet, the operation 
will fail as the router
cannot have different interfaces belonging to the same subnet. Nir suggested to 
look into using
the 169.254.0.0/16 range as the default because we know it will (hopefully) not 
be allocated by tenants.

[1] https://blueprints.launchpad.net/neutron/+spec/l3-high-availability


Assaf Muller, Cloud Networking Engineer 
Red Hat 

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Neutron ML2 and openvswitch agent

[Assaf Muller]

- Original Message -
 Hi
 
 Hope this helps
 
 http://fr.slideshare.net/mestery/modular-layer-2-in-openstack-neutron
 
 ___
 
 Trinath Somanchi
 
 _
 From: Sławek Kapłoński [sla...@kaplonski.pl]
 Sent: Tuesday, February 25, 2014 9:24 PM
 To: openstack-dev@lists.openstack.org
 Subject: [openstack-dev] Neutron ML2 and openvswitch agent
 
 Hello,
 
 I have question to You guys. Can someone explain me (or send to link
 with such explanation) how exactly ML2 plugin which is working on
 neutron server is communicating with compute hosts with openvswitch
 agents?

Maybe this will set you on your way:
ml2/plugin.py:Ml2Plugin.update_port uses _notify_port_updated, which then uses
ml2/rpc.py:AgentNotifierApi.port_update, which makes an RPC call with the topic
stated in that file.

When the message is received by the OVS agent, it calls:
neutron/plugins/openvswitch/agent/ovs_neutron_agent.py:OVSNeutronAgent.port_update.

 I suppose that this is working with rabbitmq queues but I need
 to add own function which will be called in this agent and I don't know
 how to do that. It would be perfect if such think will be possible with
 writing for example new mechanical driver in ML2 plugin (but how?).
 Thanks in advance for any help from You :)
 
 --
 Best regards
 Slawek Kaplonski
 sla...@kaplonski.pl
 
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 
 
 
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron][L3] FFE request: L3 HA VRRP

[Assaf Muller]

+1

- Original Message -
 +1
 
 On Fri, Mar 7, 2014 at 2:42 AM, Édouard Thuleau thul...@gmail.com wrote:
  +1
  I though it must merge as experimental for IceHouse, to let the community
  tries it and stabilizes it during the Juno release. And for the Juno
  release, we will be able to announce it as stable.
 
  Furthermore, the next work, will be to distribute the l3 stuff at the edge
  (compute) (called DVR) but this VRRP work will still needed for that [1].
  So if we merge L3 HA VRRP as experimental in I to be stable in J, will
  could
  also propose an experimental DVR solution for J and a stable for K.
 
  [1]
  https://docs.google.com/drawings/d/1GGwbLa72n8c2T3SBApKK7uJ6WLTSRa7erTI_3QNj5Bg/edit
 
  Regards,
  Édouard.
 
 
  On Thu, Mar 6, 2014 at 4:27 PM, Sylvain Afchain
  sylvain.afch...@enovance.com wrote:
 
  Hi all,
 
  I would like to request a FFE for the following patches of the L3 HA VRRP
  BP :
 
  https://blueprints.launchpad.net/neutron/+spec/l3-high-availability
 
  https://review.openstack.org/#/c/64553/
  https://review.openstack.org/#/c/66347/
  https://review.openstack.org/#/c/68142/
  https://review.openstack.org/#/c/70700/
 
  These should be low risk since HA is not enabled by default.
  The server side code has been developed as an extension which minimizes
  risk.
  The agent side code introduces a bit more changes but only to filter
  whether to apply the
  new HA behavior.
 
  I think it's a good idea to have this feature in Icehouse, perhaps even
  marked as experimental,
  especially considering the demand for HA in real world deployments.
 
  Here is a doc to test it :
 
 
  https://docs.google.com/document/d/1P2OnlKAGMeSZTbGENNAKOse6B2TRXJ8keUMVvtUCUSM/edit#heading=h.xjip6aepu7ug
 
  -Sylvain
 
 
  ___
  OpenStack-dev mailing list
  OpenStack-dev@lists.openstack.org
  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 
 
 
  ___
  OpenStack-dev mailing list
  OpenStack-dev@lists.openstack.org
  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 
 
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Fuel][Neutron] Networking Discussions last week

[Assaf Muller]

- Original Message -
 Hi all,
 we had a number of discussions last week in Moscow, with participation of
 guys from Russia, Ukraine and Poland.
 That was a great time!! Thanks everyone who participated.
 
 Special thanks to Przemek for great preparations, including the following:
 https://docs.google.com/a/mirantis.com/presentation/d/115vCujjWoQ0cLKgVclV59_y1sLDhn2zwjxEDmLYsTzI/edit#slide=id.p
 
 I've searched over blueprints which require update after meetings:
 https://blueprints.launchpad.net/fuel/+spec/multiple-cluster-networks
 https://blueprints.launchpad.net/fuel/+spec/fuel-multiple-l3-agents
 https://blueprints.launchpad.net/fuel/+spec/fuel-storage-networks
 https://blueprints.launchpad.net/fuel/+spec/separate-public-floating
 https://blueprints.launchpad.net/fuel/+spec/advanced-networking
 
 We will need to create one for UI.
 
 Neutron blueprints which are in the interest of large and thus complex
 deployments, with the requirements of scalability and high availability:
 https://blueprints.launchpad.net/neutron/+spec/l3-high-availability
 https://blueprints.launchpad.net/neutron/+spec/quantum-multihost
 
 The last one was rejected... there is might be another way of achieving same
 use cases? Use case, I think, was explained in great details here:
 https://wiki.openstack.org/wiki/NovaNeutronGapHighlights
 Any thoughts on this?
 

https://blueprints.launchpad.net/neutron/+spec/neutron-ovs-dvr
This is the up the date blueprint, called Distributed virtual
router, or DVR. It's in early implementation reviews and is
targeted for the Juno release.

 Thanks,
 --
 Mike Scherbakov
 #mihgen
 
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Nova]{neutron] Mid cycle sprints

[Assaf Muller]

- Original Message -
 Hi,
 There is the mid cycle sprint in July for Nova and Neutron. Anyone interested
 in maybe getting one together in Europe/Middle East around the same dates?
 If people are willing to come to this part of the world I am sure that we
 can organize a venue for a few days. Anyone interested. If we can get a
 quorum then I will be happy to try and arrange things.

+1 on an Israel sprint :)

 Thanks
 Gary
 
 
 
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [OpenStack-dev][neutron] whether vm's port in use could be deleted?

[Assaf Muller]

- Original Message -
 
 
 Hi, folks,
 
 
 
 My usecase follows:
 
 1. create two vms A and B by using the ports that have been created.
 
 2. vm A can ping vm B
 
 3. Delete one port of A or B
 
 4. vm A can still ping vm B
 
 
 
 IMO, ping should not be ok when vm's port have been deleted.
 
 
 
 Two alternative solution:
 
 1. do more restriction in def prevent_l3_port_deletion(self, context,
 port_id), we should not allow to delete the ports in use.
 
 2.permit to delete the port but notify ovs-agent to unbind the port.
 

I think option 2 is better. Implementing option 1 within Neutron would imply
getting the device_id, and sending an API call to Nova to see if it's in use or 
not.
Introducing more Neutron -- Nova interactions seems like a really bad idea.

Additionally, I'm trying to lead an effort of cleaning up tenant resources when
one is deleted. Here's the spec for Neutron:
https://review.openstack.org/#/c/98097/

If and when Nova implement something similar, prevention of deletion of in-use 
ports
would imply a dependency/order between projects when deleting a tenant.

 
 
 Any thoughts? Looking forward to your response.
 
 
 
 Cheers,
 
 XuRong Yang
 
 
 
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] Status of A/A HA for neutron-metadata-agent?

[Assaf Muller]

Hey Marios, comments inline.

- Original Message -
 Hi all,
 
 I have been asked by a colleague about the status of A/A HA for
 neutron-* processes. From the 'HA guide' [1], l3-agent and
 metadata-agent are the only neutron components that can't be deployed in
 A/A HA (corosync/pacemaker for a/p is documented as available 'out of
 the box' for both).
 
 The l3-agent work is approved for J3 [4] but I am unaware of any work on
 the metadata-agent and can't see any mention in [2][3]. Is this someone
 has looked at, or is planning to (though ultimately K would be the
 earliest right?)?
 

With L3 HA turned on you can run the metadata agent on all network nodes.
The active instance of each router will have the proxy up in its namespace
and it will forward it to the agent as expected.

 thanks! marios
 
 [1] http://docs.openstack.org/high-availability-guide/content/index.html
 [2] https://wiki.openstack.org/wiki/NeutronJunoProjectPlan
 [3] https://launchpad.net/neutron/+milestone/juno-3
 [4]
 http://git.openstack.org/cgit/openstack/neutron-specs/tree/specs/juno/l3-high-availability.rst
 
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Nova] [Neutron] heal_instance_info_cache_interval - Can we kill it?

[Assaf Muller]

Dear Nova aficionados,

Please make sure I understand this correctly:
Each nova compute instance selects a single VM out of all of the VMs
that it hosts, and every heal_instance_info_cache_interval seconds
queries Neutron for all of its networking information, then updates
Nova's DB.

If the information above is correct, then I fail to see how that
is in anyway useful. For example, for a compute node hosting 20 VMs,
it would take 20 minutes to update the last one. Seems unacceptable
to me.

Considering Icehouse's Neutron to Nova notifications, my question
is if we can change the default to 0 (Disable the feature), deprecate
it, then delete it in the K cycle. Is there a good reason not to do this?


Assaf Muller, Cloud Networking Engineer 
Red Hat 

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron][L3][ To Learn VM prefix to have reachability in the cloud using routing protocol ..

[Assaf Muller]

- Original Message -
 
 
 Hi,
 
 My Name is Keshava who was talking about using IGP to learn VM prefix and
 advertise to have reachability within the cloud in the last Atlanta summit.
 

Is there a document that could explain the use cases for something like this?

 Instead of running BGP below are the thoughts to use OSPF routing protocol
 which support hierarchical network design also.
 
 Here are my thoughts about the same.
 
 
 
 1. OSPF will be running in each of the Nodes under that TOR/switch for a
 particular Area.
 
 2. Tennant VM prefix needs to added as static route
 
 3. Each of the Nodes will form adjacency with each other in that area.
 
 a. If it is broadcast network then of the OSPF router will become ‘Designated
 router/DR’ on behalf all others in that area .
 
 4. L-1 switch/Nodes acting as Area-border router ( ABR) will connect to
 L2-switch which is Area-0.
 
 This will help for
 
 Route-aggregation,
 
 Avoid flooding of routes if any Node is going down.
 
 If any of the Node/Router is of higher/low capacity it is possible to say
 ‘forwarding option to other router’ for egress traffic.
 
 
 
 Let us know peoples opinion about the same.
 
 
 
 
 
 
 
 
 
 
 
 Thanks  regards,
 
 Keshava.A
 
 
 
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Policy for linking bug or bp in commit message

[Assaf Muller]

- Original Message -
 Hi folks
 
 I believed we should link bug or bp for any commit except automated
 commit by infra.

I think that stuff like refactors should be exempt, if for the simple
truth that often there's no bug involved.

 However, I found also there is no written policy for this.
 so may be, I'm wrong for here.
 
 The reason, we need bug or bp linked , is
 
 (1) Triage for core reviewing
 (2) Avoid duplication of works
 (3) Release management
 
 IMO, generally, the answer is yes.
 
 However, how about small 5-6 nit change?
 so such patch will be exception or not?
 
 I wanna ask community opinion, and I'll update gerrit workflow page based on
 this discussion.
 
 Best
 Nachi
 
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] q-agt error

[Assaf Muller]

- Original Message -
 Hi
 
 I'm trying to run my q-agt service and getting following error ...
 

You've stumbled on the development mailing list. You will have better
luck with ask.openstack.org or the users mailing list.

Good luck!

 
 -05-28 02:00:51.205 15377 DEBUG neutron.agent.linux.utils [-]
 Command: ['ip', '-o', 'link', 'show', 'br-int']
 Exit code: 0
 Stdout: '28: br-int: BROADCAST,UP,LOWER_UP mtu 1500 qdisc noqueue state
 UNKNOWN mode DEFAULT \\ link/ether 3a:ed:a9:bd:14:19 brd
 ff:ff:ff:ff:ff:ff\n'
 Stderr: '' execute /opt/stack/neutron/neutron/agent/linux/utils.py:74
 2014-05-28 02:00:51.209 15377 CRITICAL neutron [-] Policy configuration
 policy.json could not be found
 2014-05-28 02:00:51.209 15377 TRACE neutron Traceback (most recent call
 last):
 2014-05-28 02:00:51.209 15377 TRACE neutron File
 /usr/local/bin/neutron-openvswitch-agent, line 10, in module
 2014-05-28 02:00:51.209 15377 TRACE neutron sys.exit(main())
 2014-05-28 02:00:51.209 15377 TRACE neutron File
 /opt/stack/neutron/neutron/plugins/openvswitch/agent/ovs_neutron_agent.py,
 line 1485, in main
 2014-05-28 02:00:51.209 15377 TRACE neutron agent =
 OVSNeutronAgent(**agent_config)
 2014-05-28 02:00:51.209 15377 TRACE neutron File
 /opt/stack/neutron/neutron/plugins/openvswitch/agent/ovs_neutron_agent.py,
 line 207, in __init__
 
 Please help regarding this.
 
 
 Thanks
 Abhishek Jain
 
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Nova] [Neutron] heal_instance_info_cache_interval - Can we kill it?

[Assaf Muller]

- Original Message -
 Hi,
 
 Sorry somehow I missed this email. I don't think you want to disable it,
 though we can definitely have it run less often. The issue with disabling it
 is if one of the notifications from neutron-nova never gets sent
 successfully to nova (neutron-server is restarted before the event is sent
 or some other internal failure). Nova will never update it's cache if the
 heal_instance_info_cache_interval is set to 0.

The thing is, this periodic healing doesn't imply correctness either.
In the case where you lose a notification and the compute node hosting
the VM is hosting a non-trivial amount of VMs it can take (With the default
of 60 seconds) dozens of minutes to update the cache, since you only
update a VM a minute. I could understand the use of a sanity check if it
was performed much more often, but as it is now it seems useless to me
since you can't really rely on it.

What I'm trying to say is that with the inefficiency of the implementation,
coupled with Neutron's default plugin inability to cope with a large
amount of API calls, I feel like the disadvantages outweigh the
advantages when it comes to the cache healing.

How would you feel about disabling it, optimizing the implementation
(For example by introducing a new networking_for_instance API verb to Neutron?)
then enabling it again?

 The neutron-nova events help
 to ensure that the nova info_cache is up to date sooner by having neutron
 inform nova whenever a port's data has changed (@Joe Gordon - this happens
 regardless of virt driver).
 
 If you're using the libvirt virt driver the neutron-nova events will also be
 used to ensure that the networking is 'ready' before the instance is powered
 on.
 
 Best,
 
 Aaron
 
 P.S: we're working on making the heal_network call to neutron a lot less
 expensive as well in the future.
 
 
 
 
 On Tue, May 27, 2014 at 7:25 PM, Joe Gordon  joe.gord...@gmail.com  wrote:
 
 
 
 
 
 
 On Wed, May 21, 2014 at 6:21 AM, Assaf Muller  amul...@redhat.com  wrote:
 
 
 Dear Nova aficionados,
 
 Please make sure I understand this correctly:
 Each nova compute instance selects a single VM out of all of the VMs
 that it hosts, and every heal_instance_info_cache_interval seconds
 queries Neutron for all of its networking information, then updates
 Nova's DB.
 
 If the information above is correct, then I fail to see how that
 is in anyway useful. For example, for a compute node hosting 20 VMs,
 it would take 20 minutes to update the last one. Seems unacceptable
 to me.
 
 Considering Icehouse's Neutron to Nova notifications, my question
 is if we can change the default to 0 (Disable the feature), deprecate
 it, then delete it in the K cycle. Is there a good reason not to do this?
 
 Based on the patch that introduced this function [0] you may be on to
 something, but AFAIK unfortunately the neutron to nova notifications only
 work in libvirt right now [1], so I don' think we can fully deprecate this
 periodic task. That being said turning it off by default may be an option.
 Have you tried disabling this feature and seeing what happens (in the gate
 and/or in production)?
 

We've disabled it in a scale lab and didn't observe any black holes forming
or other catastrophes.

 
 [0] https://review.openstack.org/#/c/4269/
 [1] https://wiki.openstack.org/wiki/ReleaseNotes/Icehouse
 
 
 
 
 Assaf Muller, Cloud Networking Engineer
 Red Hat
 
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 
 
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 
 
 
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Keystone] Should Keystone emit notifications by default?

[Assaf Muller]

Hello everyone,

Keystone started emitting notifications [1] for users and tenants being created 
/ updated /
deleted during the Havana cycle. This was in response to bug [2], the fact that 
OpenStack
doesn't clean up after itself when tenants are deleted. Currently, Keystone 
does not emit
these notifications by default, and I propose it should. According to the 
principle of least
surprise, I would imagine that if an admin deleted a tenant he would expect 
that all of its
resources would be deleted, making the default configuration values in Keystone 
and the other
projects very important. I wouldn't want to rely on the different deployment 
tools to change
the needed configuration values.

I was hoping to get some feedback from operators regarding this.


[1] Keystone blueprint - 
https://blueprints.launchpad.net/keystone/+spec/notifications
[2] Resources not cleaned up bug - 
https://bugs.launchpad.net/keystone/+bug/967832
[3] Neutron spec - https://review.openstack.org/#/c/98097/


Assaf Muller, Cloud Networking Engineer 
Red Hat 

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Ironic] A mascot for Ironic

[Assaf Muller]

- Original Message -
 Hi Ironickers,
 
 I was thinking this weekend: All the cool projects does have a mascot
 so I thought that we could have one for Ironic too.
 
 The idea about what the mascot would be was easy because the RAX guys
 put bear metal their presentation[1] and that totally rocks! So I
 drew a bear. It also needed an instrument, at first I thought about a
 guitar, but drums is actually my favorite instrument so I drew a pair
 of drumsticks instead.
 
 The drawing thing wasn't that hard, the problem was to digitalize it.
 So I scanned the thing and went to youtube to watch some tutorials
 about gimp and inkspace to learn how to vectorize it. Magic, it
 worked!
 
 Attached in the email there's the original draw, the vectorized
 version without colors and the final version of it (with colors).
 
 Of course, I know some people does have better skills than I do, so I
 also attached the inkspace file of the final version in case people
 want to tweak it :)
 
 So, what you guys think about making this little drummer bear the
 mascot of the Ironic project?
 

Totally awesome.

 Ahh he also needs a name. So please send some suggestions and we can
 vote on the best name for him.
 

Metal is kind of obvious.

What would it take for you to give Neutron a mascot as well? We need all
the PR we can get :)

 [1] http://www.youtube.com/watch?v=2Oi2T2pSGDU#t=90
 
 Lucas
 
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron] force_gateway_on_subnet, please don't deprecate

[Assaf Muller]

- Original Message -
 
 My proposal here, is, _let’s not deprecate this setting_, as it’s a valid use
 case of a gateway configuration, and let’s provide it on the reference
 implementation.

I agree. As long as the reference implementation works with the setting off
there's no need to deprecate it. I still think the default should be set to True
though.

Keep in mind that the DHCP agent will need changes as well.

 
 TL;DR
 
 I’ve been looking at this yesterday, during a test deployment
 on a site where they provide external connectivity with the
 gateway outside subnet.
 
 And I needed to switch it of, to actually be able to have any external
 connectivity.
 
 https://github.com/openstack/neutron/blob/master/etc/neutron.conf#L121
 
 This is handled by providing an on-link route to the gateway first,
 and then adding the default gateway.
 
 It looks to me very interesting (not only because it’s the only way to work
 on that specific site [2][3][4]), because you can dynamically wire RIPE
 blocks to your server, without needing to use an specific IP for external
 routing or broadcast purposes, and instead use the full block in openstack.
 
 
 I have a tiny patch to support this on the neutron l3-agent [1] I yet need to
 add the logic to check “gateway outside subnet”, then add the “onlink”
 route.
 
 
 [1]
 
 diff --git a/neutron/agent/linux/interface.py
 b/neutron/agent/linux/interface.py
 index 538527b..5a9f186 100644
 --- a/neutron/agent/linux/interface.py
 +++ b/neutron/agent/linux/interface.py
 @@ -116,15 +116,16 @@ class LinuxInterfaceDriver(object):
 namespace=namespace,
 ip=ip_cidr)
 
 - if gateway:
 - device.route.add_gateway(gateway)
 -
 new_onlink_routes = set(s['cidr'] for s in extra_subnets)
 + if gateway:
 + new_onlink_routes.update([gateway])
 existing_onlink_routes = set(device.route.list_onlink_routes())
 for route in new_onlink_routes - existing_onlink_routes:
 device.route.add_onlink_route(route)
 for route in existing_onlink_routes - new_onlink_routes:
 device.route.delete_onlink_route(route)
 + if gateway:
 + device.route.add_gateway(gateway)
 
 def delete_conntrack_state(self, root_helper, namespace, ip):
 Delete conntrack state associated with an IP address.
 
 [2] http://www.soyoustart.com/
 [3] http://www.ovh.co.uk/
 [4] http://www.kimsufi.com/
 
 
 Miguel Ángel Ajo
 
 
 
 
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] UniqueConstraint for name and tenant_id in security group

[Assaf Muller]

- Original Message -
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA512
 
 I was (rightfully) asked to share my comments on the matter that I
 left in gerrit here. See below.
 
 On 12/12/14 22:40, Sean Dague wrote:
  On 12/12/2014 01:05 PM, Maru Newby wrote:
  
  On Dec 11, 2014, at 2:27 PM, Sean Dague s...@dague.net wrote:
  
  On 12/11/2014 04:16 PM, Jay Pipes wrote:
  On 12/11/2014 04:07 PM, Vishvananda Ishaya wrote:
  On Dec 11, 2014, at 1:04 PM, Jay Pipes jaypi...@gmail.com
  wrote:
  On 12/11/2014 04:01 PM, Vishvananda Ishaya wrote:
  
  On Dec 11, 2014, at 8:00 AM, Henry Gessau
  ges...@cisco.com wrote:
  
  On Thu, Dec 11, 2014, Mark McClain m...@mcclain.xyz
  wrote:
  
  On Dec 11, 2014, at 8:43 AM, Jay Pipes
  jaypi...@gmail.com mailto:jaypi...@gmail.com
  wrote:
  
  I'm generally in favor of making name attributes
  opaque, utf-8 strings that are entirely
  user-defined and have no constraints on them. I
  consider the name to be just a tag that the user
  places on some resource. It is the resource's ID
  that is unique.
  
  I do realize that Nova takes a different approach
  to *some* resources, including the security group
  name.
  
  End of the day, it's probably just a personal
  preference whether names should be unique to a
  tenant/user or not.
  
  Maru had asked me my opinion on whether names
  should be unique and I answered my personal
  opinion that no, they should not be, and if
  Neutron needed to ensure that there was one and
  only one default security group for a tenant,
  that a way to accomplish such a thing in a
  race-free way, without use of SELECT FOR UPDATE,
  was to use the approach I put into the pastebin
  on the review above.
  
  
  I agree with Jay.  We should not care about how a
  user names the resource. There other ways to
  prevent this race and Jay’s suggestion is a good
  one.
  
  However we should open a bug against Horizon because
  the user experience there is terrible with duplicate
  security group names.
  
  The reason security group names are unique is that the
  ec2 api supports source rule specifications by
  tenant_id (user_id in amazon) and name, so not
  enforcing uniqueness means that invocation in the ec2
  api will either fail or be non-deterministic in some
  way.
  
  So we should couple our API evolution to EC2 API then?
  
  -jay
  
  No I was just pointing out the historical reason for
  uniqueness, and hopefully encouraging someone to find the
  best behavior for the ec2 api if we are going to keep the
  incompatibility there. Also I personally feel the ux is
  better with unique names, but it is only a slight
  preference.
  
  Sorry for snapping, you made a fair point.
  
  Yeh, honestly, I agree with Vish. I do feel that the UX of
  that constraint is useful. Otherwise you get into having to
  show people UUIDs in a lot more places. While those are good
  for consistency, they are kind of terrible to show to people.
  
  While there is a good case for the UX of unique names - it also
  makes orchestration via tools like puppet a heck of a lot simpler
  - the fact is that most OpenStack resources do not require unique
  names.  That being the case, why would we want security groups to
  deviate from this convention?
  
  Maybe the other ones are the broken ones?
  
  Honestly, any sanely usable system makes names unique inside a
  container. Like files in a directory.
 
 Correct. Or take git: it does not use hashes to identify objects, right?
 
  In this case the tenant is the container, which makes sense.
  
  It is one of many places that OpenStack is not consistent. But I'd
  rather make things consistent and more usable than consistent and
  less.
 
 Are we only proposing to make security group name unique? I assume
 that, since that's what we currently have in review. The change would
 make API *more* inconsistent, not less, since other objects still use
 uuid for identification.
 
 You may say that we should move *all* neutron objects to the new
 identification system by name. But what's the real benefit?
 
 If there are problems in UX (client, horizon, ...), we should fix the
 view and not data models used. If we decide we want users to avoid
 using objects with the same names, fine, let's add warnings in UI
 (probably with an option to disable it so that we don't push the
 validation into their throats).
 
 Finally, I have concern about us changing user visible object
 attributes like names during db migrations, as it's proposed in the
 patch discussed here. I think such behaviour can be quite unexpected
 for some users, if not breaking their workflow and/or scripts.
 
 My belief is that responsible upstream does not apply ad-hoc changes
 to API to fix a race condition that is easily solvable in other ways
 (see Assaf's proposal to introduce a new DefaultSecurityGroups table
 in patchset 12 comments).
 

As usual you explain yourself better than I can... I think my main
original objection to the patch is that it 

Re: [openstack-dev] Fwd: [Neutron][DVR]Neutron distributed SNAT

[Assaf Muller]

- Original Message -
 Has there been any work to use conntrack synchronization similar to L3 HA in
 DVR so failover is fast on the SNAT node?
 

https://review.openstack.org/#/c/139686/
https://review.openstack.org/#/c/143169/

These changes have taken a back seat to improving the DVR job reliability
and L3 agent refactoring. Michael and Rajeev could expand.

 On Sat, Feb 14, 2015 at 1:31 PM, Carl Baldwin  c...@ecbaldwin.net  wrote:
 
 
 
 
 
 On Feb 10, 2015 2:36 AM, Wilence Yao  wilence@gmail.com  wrote:
  
  
  Hi all,
  After OpenStack Juno, floating ip is handled by dvr, but SNAT is still
  handled by l3agent on network node. The distributed SNAT is in future
  plans for DVR. In my opinion, SNAT can move to DVR as well as floating ip.
  I have searched in blueprint, there is little about distributed SNAT. Is
  there any different between distributed floating ip and distributed SNAT?
 
 The difference is that a shared snat address is shared among instances on
 multiple compute nodes. A floating ip is exclusive to a single instance on
 one compute node. I'm interested to hear your ideas for distributing it.
 
 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
 
 
 
 
 --
 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
 

__
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] contribute

[Assaf Muller]

- Original Message -
 hello folks,
 myself shailendra, i am willing to contribute in openstack. i am final year
 student of B.Tech and have sufficient skills to do some here. plz guide me
 

Take a look at the different OpenStack projects. Is there a field you're more
interested in? Compute, networking, storage, etc? Do you have a background
in any of these fields?

If you've found something that looks nice, I'd start by setting up devstack
and reading up all of the documentation of that project. Once you 
kind-of-sort-of
understand *what* is that project supposed to be doing, and you've played with
a devstack installation sufficiently to your liking (You can create a VM,
you understand most major portions of the UI and what's everything supposed
to be doing. i.e. what's a router and what's a volume) I would start looking
at your project's code. You can find the project's IRC channel and ask if
there are any good beginner bugs. You can look for bugs tagged with low hanging
fruit. You can help with the project's testing efforts (Add coverage, add
functional tests, add tests in Tempest).

Good luck!

 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] Request for comments for a possible solution

[Assaf Muller]

- Original Message -
 Hi Mike,
 
 after reviewing your latest patch [1], I  think that a possible solution
 could be to add a new entry in fdb RPC message.
 This entry would specify whether the port is multi-bound or not.
 The new fdb message would look like this :
 {net_id:
   {port:
     {agent_ip:
   {mac, ip, multi-bound }
     }
   }
    network_type:
  vxlan,
    segment_id:
      id
  }
 
 When the multi-bound option would be set, the ARP responder would be
 provisioned but the underlying module (ovs or kernel vxlan) would be
 provisioned to flood the packet to every tunnel concerned by this overlay
 segment, and not only the tunnel to agent that is supposed to host the port.
 In the LB world, this means not adding fdb entry for the MAC of the
 multi-bound port, whereas in the OVS world, it means not adding a flow that
 send the trafic that matches the MAC of the multi-bound port to only one
 tunnel port, but to every tunnel port of this overlay segment.
 
 This way, traffic to multi-bound port will behave as unknown unicast traffic.
 First packet will be flood to every tunnel and local bridge will learn the
 correct tunnel for the following packets based on which tunnel received the
 answer.
 Once learning occurs with first ingress packet, following packets would be
 sent to the correct tunnel and not flooded anymore.
 
 I've tested this with linuxbridge and it works fine. Based on code overview,
 this should work correctly with OVS too. I'll test it ASAP.
 
 I know that DVR team already add such a flag in RPC messages, but they revert
 it in later patches. I would be very interested in having their opinion on
 this proposal.
 It seems that DVR port could also use this flag. This would result in having
 ARP responder activated for DVR port too.
 
 This shouldn't need a bump in RPC versioning since this flag would be
 optionnal. So their shouldn't have any issue with backward compatibility.
 

Mike and I discussed this idea, and our concern was backwards compatability
because we *need* a solution that could be backported to Juno. If we can
still backport this kind of solution, because as you say an optional new
parameter is indeed backward compatable, and this solves LB as well, that's
a pretty big win!

 Regards,
 
 Mathieu
 
 [1] https://review.openstack.org/#/c/141114/2
 
 On Sun, Dec 21, 2014 at 12:14 PM, Narasimhan, Vivekanandan 
 vivekanandan.narasim...@hp.com  wrote:
 
 
 Hi Mike,
 
 Just one comment [Vivek]
 
 -Original Message-
 From: Mike Kolesnik [mailto: mkole...@redhat.com ]
 Sent: Sunday, December 21, 2014 11:17 AM
 To: OpenStack Development Mailing List (not for usage questions)
 Cc: Robert Kukura
 Subject: Re: [openstack-dev] [Neutron][L2Pop][HA Routers] Request for
 comments for a possible solution
 
 Hi Mathieu,
 
 Comments inline
 
 Regards,
 Mike
 
 - Original Message -
  Mike,
  
  I'm not even sure that your solution works without being able to bind
  a router HA port to several hosts.
  What's happening currently is that you :
  
  1.create the router on two l3agent.
  2. those l3agent trigger the sync_router() on the l3plugin.
  3. l3plugin.sync_routers() will trigger l2plugin.update_port(host=l3agent).
  4. ML2 will bind the port to the host mentioned in the last update_port().
  
  From a l2pop perspective, this will result in creating only one tunnel
  to the host lastly specified.
  I can't find any code that forces that only the master router binds
  its router port. So we don't even know if the host which binds the
  router port is hosting the master router or the slave one, and so if
  l2pop is creating the tunnel to the master or to the slave.
  
  Can you confirm that the above sequence is correct? or am I missing
  something?
 
 Are you referring to the alternative solution?
 
 In that case it seems that you're correct so that there would need to be
 awareness of the master router at some level there as well.
 I can't say for sure as I've been thinking on the proposed solution with no
 FDBs so there would be some issues with the alternative that need to be
 ironed out.
 
  
  Without the capacity to bind a port to several hosts, l2pop won't be
  able to create tunnel correctly, that's the reason why I was saying
  that a prerequisite for a smart solution would be to first fix the bug
  :
  https://bugs.launchpad.net/neutron/+bug/1367391
  
  DVR Had the same issue. Their workaround was to create a new
  port_binding tables, that manages the capacity for one DVR port to be
  bound to several host.
  As mentioned in the bug 1367391, this adding a technical debt in ML2,
  which has to be tackle down in priority from my POV.
 
 I agree that this would simplify work but even without this bug fixed we can
 achieve either solution.
 
 We have already knowledge of the agents hosting a router so this is
 completely doable without waiting for fix for bug 1367391.
 
 Also from my understanding the bug 1367391 is targeted at DVR only, not at 

Re: [openstack-dev] [Neutron] client noauth deprecation

[Assaf Muller]

- Original Message -
 The option to disable keystone authentication in the neutron client was
 marked for deprecation in August as part of a Keystone support upgrade.[1]
 
 What was the reason for this? As far as I can tell, Neutron works fine in the
 'noauth' mode and there isn't a lot of code that tightly couples neutron to
 Keystone that I can think of.
 

It was actually broken until John fixed it in:
https://review.openstack.org/#/c/125022/

We plan on using it in the Neutron in-tree full-stack testing. I'd appreciate
if the functionality was not removed or otherwise broken :)

 
 1.
 https://github.com/openstack/python-neutronclient/commit/2203b013fb66808ef280eff0285318ce21d9bc67#diff-ba2e4fad85e66d9aabb6193f222fcc4cR438
 
 --
 Kevin Benton
 
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] Lack of low-hanging-fruit Neutron bugs

[Assaf Muller]

- Original Message -
 Dear Neutron developers,
 
 I have been playing with OpenStack Neutron since Grizzly but never
 committed a bug upstream. I want to fix a neutron bug and do not see
 any unassigned low-hanging-fruit starter bug in
 https://bugs.launchpad.net/neutron/+bugs?field.tag=low-hanging-fruit.
 I was not able to get info about unassigned low-hanging-fruit bugs in
 the Neutron meetings webpage
 https://wiki.openstack.org/wiki/Network/Meetings either. Clearly, I do
 not know where to look. Hence, sending this email :)
 
 I do not know which bug to pick from
 https://bugs.launchpad.net/neutron. I need help to pick one please.
 
 I have experience with Neutron, namespaces, OVS bridge, agents (dhcp-
 agent [dnsmasq], L3-agent, LBaaS), reading Neutron¹s Python code,
 Linux, DevStack, git, gerrit, *.ini config files, REST, etc.
 
 I prefer a Low/Medium importance bug. ŒLow¹ would be best as it will
 be my first Neutron bug. I would like to fix a bug in neutron-server/
 neutron-agents rather than a bug in Neutron clients (like Neutron CLI,
 python-neutron-client).
 
 Can anyone please give me a bug to fix :) I may ask help if needed
 once I start fixing it.

Hello Vikram,

I went through our new bugs and set one as low hanging fruit:
https://bugs.launchpad.net/neutron/+bug/1417633

Have at it :)

 
 Thanks a lot!
 
 Regards,
 Vikram Hosakote   |  vhosakot at cisco dot com
 Cloud and Virtualization Group
 Cisco Systems   |  Boxborough MA (snow is melting!)
 
 __
 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] Deprecating the use_namespaces option - Now's the time to speak up!

[Assaf Muller]

Hello everyone,

The use_namespaces option in the L3 and DHCP Neutron agents controls if you
can create multiple routers and DHCP networks managed by a single L3/DHCP agent,
or if the agent manages only a single resource.

Are the setups out there *not* using the use_namespaces option? I'm curious as
to why, and if it would be difficult to migrate such a setup to use namespaces.

I'm asking because use_namespaces complicates Neutron code for what I gather
is an option that has not been relevant for years. I'd like to deprecate the 
option
for Kilo and remove it in Liberty.


Assaf Muller, Cloud Networking Engineer
Red Hat

__
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] Deprecating the use_namespaces option - Now's the time to speak up!

[Assaf Muller]

- Original Message -
 Assaf Muller amul...@redhat.com writes:
 
  Hello everyone,
 
 Hi Assaf,
 
  The use_namespaces option in the L3 and DHCP Neutron agents controls if you
  can create multiple routers and DHCP networks managed by a single L3/DHCP
  agent,
  or if the agent manages only a single resource.
 
  Are the setups out there *not* using the use_namespaces option? I'm curious
  as
  to why, and if it would be difficult to migrate such a setup to use
  namespaces.
 
  I'm asking because use_namespaces complicates Neutron code for what I
  gather
  is an option that has not been relevant for years. I'd like to deprecate
  the option
  for Kilo and remove it in Liberty.
 
 I'm not clear what you're proposing.  After the option is removed, will
 the code always behave as it used to when use_namespaces was False, or
 as when it was True?

I'm sorry, I should have specified: I propose to remove the option and
keep the default behavior, which is True.

 
 FWIW, my project Calico [1] uses a modified Neutron DHCP agent, where
 the behaviour for use_namespaces = False is closer to what we need.  So
 we effectively arrange to ignore the use_namespaces setting, and behave
 as though it was False [2].
 
 However, that isn't the only change we need, and it's also not clear
 that patching the Neutron DHCP agent in this way (or looking at
 upstreaming such a patch) will be our long term approach.  Hence this
 case probably shouldn't be a significant one for deciding on your
 proposal.
 
 Regards,
 Neil
 
 [1] http://www.projectcalico.org/
 [2]
 https://github.com/Metaswitch/calico-neutron/commit/af2f613368239e2a86b6312bae6e5e70a53d1396
 

__
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] Deprecating the use_namespaces option - Now's the time to speak up!

[Assaf Muller]

- Original Message -
 Tempest tests fail when not using namespaces, so I'm not sure how well we're
 even testing that codepath anymore.

Hrmph, I meant to mention that the code path is basically untested but forgot
to do that when I sent the email.

 
 doug
 
 
  On Mar 20, 2015, at 3:19 PM, Brian Haley brian.ha...@hp.com wrote:
  
  On 03/20/2015 02:57 PM, Assaf Muller wrote:
  Hello everyone,
  
  The use_namespaces option in the L3 and DHCP Neutron agents controls if
  you
  can create multiple routers and DHCP networks managed by a single L3/DHCP
  agent,
  or if the agent manages only a single resource.
  
  Are the setups out there *not* using the use_namespaces option? I'm
  curious as
  to why, and if it would be difficult to migrate such a setup to use
  namespaces.
  
  This is a recent Neutron bug where someone is not using namespaces, so they
  exist:
  
  https://bugs.launchpad.net/neutron/+bug/1428007
  
  I'm asking because use_namespaces complicates Neutron code for what I
  gather
  is an option that has not been relevant for years. I'd like to deprecate
  the option
  for Kilo and remove it in Liberty.
  
  +1 from me for deprecation.
  
  -Brian
  
  
  __
  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] How neutron calculate routing path

[Assaf Muller]

- Original Message -
 The L3 agent uses ARP and static routes like a normal router would. The L2
 agent is where there might be differences depending on the network type
 used. If it's a tunnel overlay, the L2 agent may perform an ARP offload from
 information it has learned via the L2 population mechanism.
 

To expand on what Kevin is saying, the L3 agent currently does not support any
sort of dynamic routing, and a Neutron virtual router may only have access
to up to one external network. It can be (Directly) connected to many internal 
networks
and performs static routing. If you connect a router to one external network
(8.8.8.0/24) and two internal networks (10.0.1.0/24, 10.0.2.0/24) then you
can observe the router's routing table and see that it has three routes
to said network, as well as a default gateway (The external network's gateway).

 On Sat, Mar 7, 2015 at 4:02 AM, Leo Y  minh...@gmail.com  wrote:
 
 
 
 Hello, I am looking to learn how neutron agent (probably L3) calculates a new
 routing path when VM on compute node wants to communicate with some
 destination. Does it use neutron API to learn about network topology or it
 uses its internal structures to simulate path resolving like in real
 network? If the latter is correct, then what happens when a network topology
 is changed in neutron DB (due user intervention for by other actions) and
 the local data is invalid?

When a router is updated (Internal/external interface added/removed, floating 
IPs
added or removed) then an update is sent to the relevant L3 agent which adds
or removes the interface or floating IP.

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

__
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 agent internal data structures

[Assaf Muller]

- Original Message -
 Thank you. I am looking to read this state and compare it with neutron DB. If
 there are agents that do it already, I would like only to learn if I can
 change the polling period. Can you advise about the most efficient way to
 learn which agent does it and which doesn't?

The L3 agent has a periodic task (60 seconds, non-configurable, see neutron/
agent/l3/agent.py.L3NATAgent.periodic_sync_routers_task) that gets all of
the routers hosted on the agent from the DB, IF some error condition is met,
i.e. this periodic task doesn't do anything at all unless an error occurred
during the configuration of a router. It only performs a full-sync (Get all
routers from Neutron DB and configure them locally) when it starts up.

The DHCP and OVS agents are similar in that they don't actually get the state 
from the
Neutron DB in a periodic manner unless an error has occurred.

 
 Leonid
 
 On Sun, Mar 8, 2015 at 12:02 AM, Salvatore Orlando  sorla...@nicira.com 
 wrote:
 
 
 
 Hi Leo,
 
 Every agent keeps anyway an in-memory state throughout its execution.
 The agents indeed have no persistent storage - at least not in the usual form
 of a database. They however rely on data other than the neutron database.
 
 For instance for the l2 agent, ovsdb itself is a source of information. The
 agent periodically scans it to detect interfaces which are brought up or
 down.
 As another example the dhcp agent stores its current state a 'data' directory
 (if you're using devstack it's usually /opt/stack/data/neutron/dhcp)
 
 Hope this helps,
 Salvatore
 
 
 
 
 
 On 7 March 2015 at 13:05, Leo Y  minh...@gmail.com  wrote:
 
 
 
 
 
 Hello,
 
 Where within the code of neutron agents I can find structure(s) that store
 network information? The agent has to know all current networks and ports in
 use by all VMs that are running in its compute node. Does anyone know where
 this information is stored except for neutron DB?
 
 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
 
 
 
 __
 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,
 Leo
 -
 I enjoy the massacre of ads. This sentence will slaughter ads without a messy
 bloodbath
 
 __
 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] Issue when upgrading from Juno to Kilo due to agent report_state RPC namespace patch

[Assaf Muller]

I've filed a bug here:
https://bugs.launchpad.net/neutron/+bug/1430984

I've outlined the path I'd like to take in the bug description.

- Original Message -
 +1 on avoiding changes that break rolling upgrade.
 
 Rolling upgrade has been working so far (at least from my perspective), and
 as openstack adoption spreads, it will be important for more and more users.
 
 How do we make rolling upgrade a supported part of Neutron?

Finding a sane way to test it would be a start. I'm still looking...

 
 - Jack
 
  -Original Message-
  From: Assaf Muller [mailto:amul...@redhat.com]
  Sent: Thursday, March 05, 2015 11:59 AM
  To: OpenStack Development Mailing List (not for usage questions)
  Subject: Re: [openstack-dev] [Neutron] Issue when upgrading from Juno to
  Kilo due
  to agent report_state RPC namespace patch
  
  
  
  - Original Message -
   To turn this stuff off, you don't need to revert.  I'd suggest just
   setting the namespace contants to None, and that will result in the same
   thing.
  
  
  http://git.openstack.org/cgit/openstack/neutron/tree/neutron/common/constants.py#
  n152
  
   It's definitely a non-backwards compatible change.  That was a conscious
   choice as the interfaces are a bit of a tangled mess, IMO.  The
   non-backwards compatible changes were simpler so I went that route,
   because as far as I could tell, rolling upgrades were not supported.  If
   they do work, it's due to luck.  There's multiple things including the
   lack of testing this scenario to lack of data versioning that make it a
   pretty shaky area.
  
   However, if it worked for some people, I totally get the argument
   against breaking it intentionally.  As mentioned before, a quick fix if
   needed is to just set the namespace constants to None.  If someone wants
   to do something to make it backwards compatible, that's even better.
  
  
  I sent out an email to the operators list to get some feedback:
  http://lists.openstack.org/pipermail/openstack-operators/2015-March/006429.html
  
  And at least one operator reported that he performed a rolling Neutron
  upgrade
  from I to J successfully. So, I'm agreeing with you agreeing with me that
  we
  probably don't want to mess this up knowingly, even though there is no
  testing
  to make sure that it keeps working.
  
  I'll follow up on IRC with you to figure out who's doing what.
  
   --
   Russell Bryant
  
   On 03/04/2015 11:50 AM, Salvatore Orlando wrote:
To put in another way I think we might say that change 154670 broke
backward compatibility on the RPC interface.
To be fair this probably happened because RPC interfaces were organised
in a way such that this kind of breakage was unavoidable.
   
I think the strategy proposed by Assaf is a viable one. The point about
being able to do rolling upgrades only from version N to N+1 is a
sensible one, but it has more to do with general backward compability
rules for RPC interfaces.
   
In the meanwhile this is breaking a typical upgrade scenario. If a fix
allowing agent state updates both namespaced and not is available today
or tomorrow, that's fine. Otherwise I'd revert just to be safe.
   
By the way, we were supposed to have already removed all server rpc
callbacks in the appropriate package... did we forget out this one or
is
there a reason for which it's still in neutron.db?
   
Salvatore
   
On 4 March 2015 at 17:23, Miguel Ángel Ajo majop...@redhat.com
mailto:majop...@redhat.com wrote:
   
I agree with Assaf, this is an issue across updates, and
we may want (if that’s technically possible) to provide
access to those functions with/without namespace.
   
Or otherwise think about reverting for now until we find a
migration strategy
   
   
  https://review.openstack.org/#/q/status:merged+project:openstack/neutron+branch:m
  aster+topic:bp/rpc-docs-and-namespaces,n,z
   
   
Best regards,
Miguel Ángel Ajo
   
On Wednesday, 4 de March de 2015 at 17:00, Assaf Muller wrote:
   
Hello everyone,
   
I'd like to highlight an issue with:
https://review.openstack.org/#/c/154670/
   
According to my understanding, most deployments upgrade the
controllers first
and compute/network nodes later. During that time period, all
agents will
fail to report state as they're sending the report_state message
outside
of any namespace while the server is expecting that message in a
namespace.
This is a show stopper as the Neutron server will think all of its
agents are dead.
   
I think the obvious solution is to modify the Neutron server code
so that
it accepts the report_state method both in and outside of the
report_state
RPC namespace and chuck that code away in L (Assuming we support
rolling upgrades

Re: [openstack-dev] [neutron] Generic question about synchronizing neutron agent on compute node with DB

[Assaf Muller]

- Original Message -
  However, I briefly looked through the L2 agent code and didn't see a
  periodic task to resync the port information to protect from a neutron
  server that failed to send a notification because it crashed or lost its
  amqp connection. The L3 agent has a period sync routers task that helps in
  this regard.

The L3 agent periodic sync is only if the full_sync flag was turned on, which
is a result of an error.

  Maybe another neutron developer more familiar with the L2
  agent can chime in here if I'm missing anything.
 
 i don't think you are missing anything.
 periodic sync would be a good improvement.
 
 YAMAMAOTO Takashi
 
 __
 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] Issue when upgrading from Juno to Kilo due to agent report_state RPC namespace patch

[Assaf Muller]

- Original Message -
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1
 
 Should we target it for Kilo? It does not seem right to allow it
 slipping into the next release while we know there are operators
 relying on the feature.

Of course, this will be fixed for Kilo.

This is the immediate fix, which should be merged right away:
https://review.openstack.org/#/c/163676/

I pushed a patch to support servers with multiple namespaces to Oslo
messaging:
https://review.openstack.org/#/c/163673/

Once that gains momentum I'll send a patch to Neutron that re-enables
namespaces for RPC servers (Along with the null namespace) and enable
fallbacks for clients.

 
 On 03/11/2015 08:42 PM, Assaf Muller wrote:
  I've filed a bug here:
  https://bugs.launchpad.net/neutron/+bug/1430984
  
  I've outlined the path I'd like to take in the bug description.
  
  - Original Message -
  +1 on avoiding changes that break rolling upgrade.
  
  Rolling upgrade has been working so far (at least from my
  perspective), and as openstack adoption spreads, it will be
  important for more and more users.
  
  How do we make rolling upgrade a supported part of Neutron?
  
  Finding a sane way to test it would be a start. I'm still
  looking...
  
  
  - Jack
  
  -Original Message- From: Assaf Muller
  [mailto:amul...@redhat.com] Sent: Thursday, March 05, 2015
  11:59 AM To: OpenStack Development Mailing List (not for usage
  questions) Subject: Re: [openstack-dev] [Neutron] Issue when
  upgrading from Juno to Kilo due to agent report_state RPC
  namespace patch
  
  
  
  - Original Message -
  To turn this stuff off, you don't need to revert.  I'd
  suggest just setting the namespace contants to None, and that
  will result in the same thing.
  
  
  http://git.openstack.org/cgit/openstack/neutron/tree/neutron/common/constants.py#
 
  
 n152
  
  It's definitely a non-backwards compatible change.  That was
  a conscious choice as the interfaces are a bit of a tangled
  mess, IMO.  The non-backwards compatible changes were simpler
  so I went that route, because as far as I could tell, rolling
  upgrades were not supported.  If they do work, it's due to
  luck.  There's multiple things including the lack of testing
  this scenario to lack of data versioning that make it a
  pretty shaky area.
  
  However, if it worked for some people, I totally get the
  argument against breaking it intentionally.  As mentioned
  before, a quick fix if needed is to just set the namespace
  constants to None.  If someone wants to do something to make
  it backwards compatible, that's even better.
  
  
  I sent out an email to the operators list to get some
  feedback:
  http://lists.openstack.org/pipermail/openstack-operators/2015-March/006429.html
 
 
  
 And at least one operator reported that he performed a rolling Neutron
  upgrade from I to J successfully. So, I'm agreeing with you
  agreeing with me that we probably don't want to mess this up
  knowingly, even though there is no testing to make sure that it
  keeps working.
  
  I'll follow up on IRC with you to figure out who's doing what.
  
  -- Russell Bryant
  
  On 03/04/2015 11:50 AM, Salvatore Orlando wrote:
  To put in another way I think we might say that change
  154670 broke backward compatibility on the RPC interface.
  To be fair this probably happened because RPC interfaces
  were organised in a way such that this kind of breakage was
  unavoidable.
  
  I think the strategy proposed by Assaf is a viable one. The
  point about being able to do rolling upgrades only from
  version N to N+1 is a sensible one, but it has more to do
  with general backward compability rules for RPC
  interfaces.
  
  In the meanwhile this is breaking a typical upgrade
  scenario. If a fix allowing agent state updates both
  namespaced and not is available today or tomorrow, that's
  fine. Otherwise I'd revert just to be safe.
  
  By the way, we were supposed to have already removed all
  server rpc callbacks in the appropriate package... did we
  forget out this one or is there a reason for which it's
  still in neutron.db?
  
  Salvatore
  
  On 4 March 2015 at 17:23, Miguel Ángel Ajo
  majop...@redhat.com mailto:majop...@redhat.com wrote:
  
  I agree with Assaf, this is an issue across updates, and we
  may want (if that’s technically possible) to provide access
  to those functions with/without namespace.
  
  Or otherwise think about reverting for now until we find a
  migration strategy
  
  
  https://review.openstack.org/#/q/status:merged+project:openstack/neutron+branch:m
 
  
 aster+topic:bp/rpc-docs-and-namespaces,n,z
  
  
  Best regards, Miguel Ángel Ajo
  
  On Wednesday, 4 de March de 2015 at 17:00, Assaf Muller
  wrote:
  
  Hello everyone,
  
  I'd like to highlight an issue with:
  https://review.openstack.org/#/c/154670/
  
  According to my understanding, most deployments upgrade
  the controllers first and compute/network nodes later.
  During

Re: [openstack-dev] [neutron] [metadata] metadata service when NOT using name space

[Assaf Muller]

Can you explain why are you not using namespaces? (I'm really curious).

I've been thinking of proposing to deprecate that option only for the simple
truth that it's not tested and we have no idea if it works anymore, or if anyone
actually uses it.

- Original Message -
 When use_namespaces is True, there will be a namespace metadata proxy
 launched for either dhcp or router namespace, this proxy will accept metada
 service request , and then proxy the request to metadata server via metadata
 agent. But when use_namespaces is False, there is no namespace metadata
 proxy running, how is the request from vm going to get to matadata server
 then? I also checked that there is no NAT rule in the iptables. So do we
 support metadata service with no namespace? If we do , how is it supposed to
 work? This is Juno.
 
 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
 

__
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] VLAN trunking network for NFV

[Assaf Muller]

- Original Message -
  *From:* Ian Wells [mailto: ijw.ubuntu at cack.org.uk ]  *Sent:* Wednesday,
  March 25, 2015 2:18 AM   That spec ensures that you can tell what the
  plugin is doing.  You can ask  for a VLAN transparent network, but the
  cloud may tell you it can't make  one.   If you want to use a VLAN
  trunk using the current code, I recommend VXLAN  or GRE along with the
  Linuxbridge driver, both of which support VLAN  transparent networking.
  If they're configured and you ask for a VLAN trunk  you'll be told you
  got one.
 The linuxbridge agent does not support GRE.
 I tried sending tagged packets over linuxbridge+VxLAN and it did not work - I
 didn't look into it any further.

This was a strong premise of the spec when it was under discussion, that we
at least some part of the reference implementation (LB + VXLAN was cited)
that works. If it doesn't, I think it's problematic to introduce new API
without a reference implementation.

 I also tried over linuxbridge+FLAT - this works when the physical switch
 ports are trunks - they would need to permit all VLAN ids to be fully VLAN
 transparent.
 I think linuxbridge+VLAN would work too, as along as the switch ports are
 also configured for Q-in-Q.
 Currently the linuxbridge mechanism driver cannot know if a Neutron network
 is VLAN transparent or not.
 
 
 __
 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] [Nova][Neutron] Status of the nova-network to Neutron migration work

[Assaf Muller]

- Original Message -
 On 03/27/2015 11:48 AM, Assaf Muller wrote:
  
  
  - Original Message -
  On 03/27/2015 05:22 AM, Thierry Carrez wrote:
  snip
  Part of it is corner (or simplified) use cases not being optimally
  served by Neutron, and I think Neutron could more aggressively address
  those. But the other part is ignorance and convenience: that Neutron
  thing is a scary beast, last time I looked into it I couldn't make sense
  of it, and nova-network just works for me.
 
  That is why during the Ops Summit we discussed coming up with a
  migration guide that would explain the various ways you can use Neutron
  to cover nova-network use cases, demystify a few dark areas, and outline
  the step-by-step manual process you can go through to migrate from one
  to the other.
 
  We found a dev/ops volunteer for writing that migration guide but he was
  unfortunately not allowed to spend time on this. I heard we have new
  volunteers, but I'll let them announce what their plans are, rather than
  put words in their mouth.
 
  This migration guide can happen even if we follow the nova-net spinout
  plan (for the few who want to migrate to Neutron), so this is a
  complementary solution rather than an alternative. Personally I doubt
  there would suddenly be enough people interested in nova-net development
  to successfully spin it out and maintain it. I also agree with Russell
  that long-term fragmentation at this layer of the stack is generally not
  desirable.
 
  I think if you boil everything down, you end up with 3 really important
  differences.
 
  1) neutron is a fleet of services (it's very micro service) and every
  service requires multiple and different config files. Just configuring
  the fleet is a beast if it not devstack (and even if it is)
 
  2) neutron assumes a primary interesting thing to you is tenant secured
  self service networks. This is actually explicitly not interesting to a
  lot of deploys for policy, security, political reasons/restrictions.
 
  3) neutron open source backend defaults to OVS (largely because #2). OVS
  is it's own complicated engine that you need to learn to debug. While
  Linux bridge has challenges, it's also something that anyone who's
  worked with Linux  Virtualization for the last 10 years has some
  experience with.
 
  (also, the devstack setup code for neutron is a rats nest, as it was
  mostly not paid attention to. This means it's been 0 help in explaining
  anything to people trying to do neutron. For better or worse devstack is
  our executable manual for a lot of these things)
 
  so that being said, I think we need to talk about minimum viable
  neutron as a model and figure out how far away that is from n-net. This
  week at the QA Sprint, Dean, Sean Collins, and I have spent some time
  hashing it out, hopefully with something to show the end of the week.
  This will be the new devstack code for neutron (the old lib/neutron is
  moved to lib/neutron-legacy).
 
  Default setup will be provider networks (which means no tenant
  isolation). For that you should only need neutron-api, -dhcp, and -l2.
  So #1 is made a bunch better. #2 not a thing at all. And for #3 we'd
  like to revert back to linux bridge for the base case (though first code
  will probably be OVS because that's the happy path today).
 
  
  Looking at the latest user survey, OVS looks to be 3 times as popular as
  Linux bridge for production deployments. Having LB as the default seems
  like an odd choice. You also wouldn't want to change the default before
  LB is tested at the gate.
 
 Sure, actually testing defaults is presumed here. I didn't think it
 needed to be called out separately.

Quick update about OVS vs LB:
Sean M. Collins pushed up a patch that runs CI on Tempest with LB:
https://review.openstack.org/#/c/168423/

So far it's failing pretty badly.

 
   -Sean
 
 --
 Sean Dague
 http://dague.net
 
 
 __
 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] [Nova][Neutron] Status of the nova-network to Neutron migration work

[Assaf Muller]

- Original Message -
 On 03/30/2015 09:25 AM, Assaf Muller wrote:
  
  
  - Original Message -
  On 03/27/2015 11:48 AM, Assaf Muller wrote:
 
 
  - Original Message -
  On 03/27/2015 05:22 AM, Thierry Carrez wrote:
  snip
  Part of it is corner (or simplified) use cases not being optimally
  served by Neutron, and I think Neutron could more aggressively address
  those. But the other part is ignorance and convenience: that Neutron
  thing is a scary beast, last time I looked into it I couldn't make
  sense
  of it, and nova-network just works for me.
 
  That is why during the Ops Summit we discussed coming up with a
  migration guide that would explain the various ways you can use Neutron
  to cover nova-network use cases, demystify a few dark areas, and
  outline
  the step-by-step manual process you can go through to migrate from one
  to the other.
 
  We found a dev/ops volunteer for writing that migration guide but he
  was
  unfortunately not allowed to spend time on this. I heard we have new
  volunteers, but I'll let them announce what their plans are, rather
  than
  put words in their mouth.
 
  This migration guide can happen even if we follow the nova-net spinout
  plan (for the few who want to migrate to Neutron), so this is a
  complementary solution rather than an alternative. Personally I doubt
  there would suddenly be enough people interested in nova-net
  development
  to successfully spin it out and maintain it. I also agree with Russell
  that long-term fragmentation at this layer of the stack is generally
  not
  desirable.
 
  I think if you boil everything down, you end up with 3 really important
  differences.
 
  1) neutron is a fleet of services (it's very micro service) and every
  service requires multiple and different config files. Just configuring
  the fleet is a beast if it not devstack (and even if it is)
 
  2) neutron assumes a primary interesting thing to you is tenant secured
  self service networks. This is actually explicitly not interesting to a
  lot of deploys for policy, security, political reasons/restrictions.
 
  3) neutron open source backend defaults to OVS (largely because #2). OVS
  is it's own complicated engine that you need to learn to debug. While
  Linux bridge has challenges, it's also something that anyone who's
  worked with Linux  Virtualization for the last 10 years has some
  experience with.
 
  (also, the devstack setup code for neutron is a rats nest, as it was
  mostly not paid attention to. This means it's been 0 help in explaining
  anything to people trying to do neutron. For better or worse devstack is
  our executable manual for a lot of these things)
 
  so that being said, I think we need to talk about minimum viable
  neutron as a model and figure out how far away that is from n-net. This
  week at the QA Sprint, Dean, Sean Collins, and I have spent some time
  hashing it out, hopefully with something to show the end of the week.
  This will be the new devstack code for neutron (the old lib/neutron is
  moved to lib/neutron-legacy).
 
  Default setup will be provider networks (which means no tenant
  isolation). For that you should only need neutron-api, -dhcp, and -l2.
  So #1 is made a bunch better. #2 not a thing at all. And for #3 we'd
  like to revert back to linux bridge for the base case (though first code
  will probably be OVS because that's the happy path today).
 
 
  Looking at the latest user survey, OVS looks to be 3 times as popular as
  Linux bridge for production deployments. Having LB as the default seems
  like an odd choice. You also wouldn't want to change the default before
  LB is tested at the gate.
 
  Sure, actually testing defaults is presumed here. I didn't think it
  needed to be called out separately.
  
  Quick update about OVS vs LB:
  Sean M. Collins pushed up a patch that runs CI on Tempest with LB:
  https://review.openstack.org/#/c/168423/
  
  So far it's failing pretty badly.
 That is the nature of development.
 
 Let's also note that is patchset 1 of a patch marked work in progress.
 
 If we start to make decisions about whether or not a direction is a
 reasonable direction on a patch which is expected to fail this early in
 the development process we serious injure our ability to foster development.
 
 Please understand and respect the development process prior to expecting
 others to make decisions prematurely.
 

I was providing a status report, nothing more.

 Thank you,
 Anita.
  
 
 -Sean
 
  --
  Sean Dague
  http://dague.net
 
 
  __
  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

Re: [openstack-dev] [Neutron] Issue when upgrading from Juno to Kilo due to agent report_state RPC namespace patch

[Assaf Muller]

- Original Message -
 To turn this stuff off, you don't need to revert.  I'd suggest just
 setting the namespace contants to None, and that will result in the same
 thing.
 
 http://git.openstack.org/cgit/openstack/neutron/tree/neutron/common/constants.py#n152
 
 It's definitely a non-backwards compatible change.  That was a conscious
 choice as the interfaces are a bit of a tangled mess, IMO.  The
 non-backwards compatible changes were simpler so I went that route,
 because as far as I could tell, rolling upgrades were not supported.  If
 they do work, it's due to luck.  There's multiple things including the
 lack of testing this scenario to lack of data versioning that make it a
 pretty shaky area.
 
 However, if it worked for some people, I totally get the argument
 against breaking it intentionally.  As mentioned before, a quick fix if
 needed is to just set the namespace constants to None.  If someone wants
 to do something to make it backwards compatible, that's even better.
 

I sent out an email to the operators list to get some feedback:
http://lists.openstack.org/pipermail/openstack-operators/2015-March/006429.html

And at least one operator reported that he performed a rolling Neutron upgrade
from I to J successfully. So, I'm agreeing with you agreeing with me that we
probably don't want to mess this up knowingly, even though there is no testing
to make sure that it keeps working.

I'll follow up on IRC with you to figure out who's doing what.

 --
 Russell Bryant
 
 On 03/04/2015 11:50 AM, Salvatore Orlando wrote:
  To put in another way I think we might say that change 154670 broke
  backward compatibility on the RPC interface.
  To be fair this probably happened because RPC interfaces were organised
  in a way such that this kind of breakage was unavoidable.
  
  I think the strategy proposed by Assaf is a viable one. The point about
  being able to do rolling upgrades only from version N to N+1 is a
  sensible one, but it has more to do with general backward compability
  rules for RPC interfaces.
  
  In the meanwhile this is breaking a typical upgrade scenario. If a fix
  allowing agent state updates both namespaced and not is available today
  or tomorrow, that's fine. Otherwise I'd revert just to be safe.
  
  By the way, we were supposed to have already removed all server rpc
  callbacks in the appropriate package... did we forget out this one or is
  there a reason for which it's still in neutron.db?
  
  Salvatore
  
  On 4 March 2015 at 17:23, Miguel Ángel Ajo majop...@redhat.com
  mailto:majop...@redhat.com wrote:
  
  I agree with Assaf, this is an issue across updates, and
  we may want (if that’s technically possible) to provide
  access to those functions with/without namespace.
  
  Or otherwise think about reverting for now until we find a
  migration strategy
  
  
  https://review.openstack.org/#/q/status:merged+project:openstack/neutron+branch:master+topic:bp/rpc-docs-and-namespaces,n,z
  
  
  Best regards,
  Miguel Ángel Ajo
  
  On Wednesday, 4 de March de 2015 at 17:00, Assaf Muller wrote:
  
  Hello everyone,
 
  I'd like to highlight an issue with:
  https://review.openstack.org/#/c/154670/
 
  According to my understanding, most deployments upgrade the
  controllers first
  and compute/network nodes later. During that time period, all
  agents will
  fail to report state as they're sending the report_state message
  outside
  of any namespace while the server is expecting that message in a
  namespace.
  This is a show stopper as the Neutron server will think all of its
  agents are dead.
 
  I think the obvious solution is to modify the Neutron server code
  so that
  it accepts the report_state method both in and outside of the
  report_state
  RPC namespace and chuck that code away in L (Assuming we support
  rolling upgrades
  only from version N to N+1, which while is unfortunate, is the
  behavior I've
  seen in multiple places in the code).
 
  Finally, are there additional similar issues for other RPC methods
  placed in a namespace
  this cycle?
 
 
  Assaf Muller, Cloud Networking Engineer
  Red Hat
 
  
  __
  OpenStack Development Mailing List (not for usage questions)
  Unsubscribe:
  openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
  mailto: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

Re: [openstack-dev] [Nova][Neutron] Status of the nova-network to Neutron migration work

[Assaf Muller]

- Original Message -
 On 03/27/2015 05:22 AM, Thierry Carrez wrote:
 snip
  Part of it is corner (or simplified) use cases not being optimally
  served by Neutron, and I think Neutron could more aggressively address
  those. But the other part is ignorance and convenience: that Neutron
  thing is a scary beast, last time I looked into it I couldn't make sense
  of it, and nova-network just works for me.
  
  That is why during the Ops Summit we discussed coming up with a
  migration guide that would explain the various ways you can use Neutron
  to cover nova-network use cases, demystify a few dark areas, and outline
  the step-by-step manual process you can go through to migrate from one
  to the other.
  
  We found a dev/ops volunteer for writing that migration guide but he was
  unfortunately not allowed to spend time on this. I heard we have new
  volunteers, but I'll let them announce what their plans are, rather than
  put words in their mouth.
  
  This migration guide can happen even if we follow the nova-net spinout
  plan (for the few who want to migrate to Neutron), so this is a
  complementary solution rather than an alternative. Personally I doubt
  there would suddenly be enough people interested in nova-net development
  to successfully spin it out and maintain it. I also agree with Russell
  that long-term fragmentation at this layer of the stack is generally not
  desirable.
 
 I think if you boil everything down, you end up with 3 really important
 differences.
 
 1) neutron is a fleet of services (it's very micro service) and every
 service requires multiple and different config files. Just configuring
 the fleet is a beast if it not devstack (and even if it is)
 
 2) neutron assumes a primary interesting thing to you is tenant secured
 self service networks. This is actually explicitly not interesting to a
 lot of deploys for policy, security, political reasons/restrictions.
 
 3) neutron open source backend defaults to OVS (largely because #2). OVS
 is it's own complicated engine that you need to learn to debug. While
 Linux bridge has challenges, it's also something that anyone who's
 worked with Linux  Virtualization for the last 10 years has some
 experience with.
 
 (also, the devstack setup code for neutron is a rats nest, as it was
 mostly not paid attention to. This means it's been 0 help in explaining
 anything to people trying to do neutron. For better or worse devstack is
 our executable manual for a lot of these things)
 
 so that being said, I think we need to talk about minimum viable
 neutron as a model and figure out how far away that is from n-net. This
 week at the QA Sprint, Dean, Sean Collins, and I have spent some time
 hashing it out, hopefully with something to show the end of the week.
 This will be the new devstack code for neutron (the old lib/neutron is
 moved to lib/neutron-legacy).
 
 Default setup will be provider networks (which means no tenant
 isolation). For that you should only need neutron-api, -dhcp, and -l2.
 So #1 is made a bunch better. #2 not a thing at all. And for #3 we'd
 like to revert back to linux bridge for the base case (though first code
 will probably be OVS because that's the happy path today).
 

Looking at the latest user survey, OVS looks to be 3 times as popular as
Linux bridge for production deployments. Having LB as the default seems
like an odd choice. You also wouldn't want to change the default before
LB is tested at the gate.

 Mixin #1: NEUTRON_BRIDGE_WITH=OVS
 
 First optional layer being flip from linuxbridge - ovs. That becomes
 one bite sized thing to flip over once you understand it.
 
 Mixin #2: self service networks
 
 This will be off in the default case, but can be enabled later.
 
 ... and turtles all the way up.
 
 
 Provider networks w/ Linux bridge are really close to the simplicity on
 the wire people expected with n-net. The only last really difference is
 floating ips. And the problem here was best captured by Sean Collins on
 Wed, Floating ips in nova are overloaded. They are both elastic ips, but
 they are also how you get public addresses in a default environment.
 Dean shared that that dual purpose is entirely due to constraints of the
 first NASA cloud which only had a /26 of routable IPs. In neutron this
 is just different, you don't need floating ips to have public addresses.
 But the mental model has stuck.
 
 
 Anyway, while I'm not sure this is going to solve everyone's issues, I
 think it's a useful exercise anyway for devstack's neutron support to
 revert to a minimum viable neutron for learning purposes, and let you
 layer on complexity manually over time. And I'd be really curious if a
 n-net - provider network side step (still on linux bridge) would
 actually be a more reasonable transition for most environments.
 
   -Sean
 
 --
 Sean Dague
 http://dague.net
 
 
 __
 OpenStack Development Mailing List 

Re: [openstack-dev] [Openstack-operators] [Neutron] Deprecating the use_namespaces option - Now's the time to speak up!

[Assaf Muller]

Note that https://review.openstack.org/#/c/166888/ has been merged.
This means that the option has been deprecated for K and will be
removed in L. Anyone using the non-default value of False will be looking
at errors in his logs.

- Original Message -
 
 
 On 3/23/2015 3:56 AM, Miguel Ángel Ajo wrote:
  I see you point Van,
 
  In the other hand, removing it, cleans up lot of conditional code parts
  (moving parts at the other side),
  and also the non-netns case is not tested by upstream CI, AFAIK, so it
  could be broken anytime
  and we would not notice it.
 
 
 
  Miguel Ángel Ajo
 
  On Monday, 23 de March de 2015 at 9:25, Van Leeuwen, Robert wrote:
 
  I think there are valid reasons to not use namespaces:
 
* Fewer moving parts == less can potentialy fail
* Troubleshooting is easier due to less places to look / need no
  familiarity with namespaces  tools
* If I remember correctly setting up a namespace can get really
  slow when you have a lot of them on a single machine
 
 
   IMHO, those shouldn’t be valid reasons anymore, since they were due
   iproute, or sudo issues
   that have been corrected long ago, and all distros installing neutron
   are supporting netns at this
 
  Well, you exactly made my point:
  There is lots that can and will go wrong with more moving parts.
  That they are fixed at the moment does not mean that there will not be
  a new bug in the future…
 
  Cheers,
  Robert van Leeuwen
  ___
  OpenStack-operators mailing list
  openstack-operat...@lists.openstack.org
  mailto:openstack-operat...@lists.openstack.org
  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
 
 
 
  __
  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
 
 
 FWIW we were doing CI without namespaces before Kilo simply due to RHEL
 6.5 not having the support w/o a kernel patch.
 
 Since Kilo dropped py26 support we moved to RHEL 7* for py27 and that
 has namespace support so it's no longer an issue for us.
 
 --
 
 Thanks,
 
 Matt Riedemann
 
 
 __
 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][L3] IPAM alternate refactoring

[Assaf Muller]

- Original Message -
 I think removing all occurrences of create_port inside of another transaction
 is something we should be doing for a couple of reasons.

The issues you're pointing out are very much real. It's a *huge* pain to 
workaround
this issue and you can look for an example here:
https://github.com/openstack/neutron/blob/master/neutron/db/l3_hamode_db.py#L303

The thing is, is that you *should* be able to call core_plugin.create_port in a
transaction. I think that the correct thing to do is to eliminate the issue with
create_port, and not work around the issue with awful patterns such as the one
in the link above. There's a few different acute issues with that pattern:
1) We have no automated way to tell if create_port is being called in a 
transaction
   or not, currently it's left up to reviewers to spot such occurrences and 
prevent
   them from being merged.
2) The mental load it adds to read that code is not trivial.
3) Transactions are awesome... I'd very much like to group up 
core_plugin.create_port
   and create_ha_port_binding in a single transaction and avoid having to deal 
with
   edge cases manually.
4) Sometimes you can't use the try/except/manual cleanup approach (If you 
delete a resource
   in transaction A, then transaction B fails, good luck re-creating the 
resource you already
   deleted).

The better long term approach would be to introduce a framework at the API 
layer that queues
up notifications (Both HTTP to vendor servers and RPC to agents) at the start 
of an API or RPC call.
You're then free to use a single huge transaction (Fun!), and finally all 
queued up notifications
will be sent for you automagically. That's the simplest approach, I haven't 
thought this through
and I'm sure there will be issues but it should be possible. We're still left 
with questions such
as: What happens if I commit a mega-transaction and then all (Or even more 
complicated, one) of
the notifications fails, but this isn't a new problem.

 
 First, it's a recipe for the cherished lock wait timeout deadlocks because
 create_port makes yielding calls. These are awful to troubleshoot and are
 pretty annoying for users (request takes ~60 seconds and then blows up).
 
 Second, create_port in ML2 expects the transaction to be committed to the DB
 by the time it's done with pre-commit phase, which we break by opening a
 parent transaction before calling it so the failure handling semantics may
 be messed up.
 
 
 
 On Mon, Apr 13, 2015 at 9:48 AM, Carl Baldwin  c...@ecbaldwin.net  wrote:
 
 
 Have we found the last of them? I wonder. I suppose any higher level
 service like a router that needs to create ports under the hood (under
 the API) will have this problem. The DVR fip namespace creation comes
 to mind. It will create a port to use as the external gateway port
 for that namespace. This could spring up in the context of another
 create_port, I think (VM gets new port bound to a compute host where a
 fip namespace needs to spring in to existence).
 
 Carl
 
 On Mon, Apr 13, 2015 at 10:24 AM, John Belamaric
  jbelama...@infoblox.com  wrote:
  Thanks Pavel. I see an additional case in L3_NAT_dbonly_mixin, where it
  starts the transaction in create_router, then eventually gets to
  create_port:
  
  create_router (starts tx)
  -self._update_router_gw_info
  -_create_gw_port
  -_create_router_gw_port
  -create_port(plugin)
  
  So that also would need to be unwound.
  
  On 4/13/15, 10:44 AM, Pavel Bondar  pbon...@infoblox.com  wrote:
  
 Hi,
  
 I made some investigation on the topic[1] and see several issues on this
 way.
  
 1. Plugin's create_port() is wrapped up in top level transaction for
 create floating ip case[2], so it becomes more complicated to do IPAM
 calls outside main db transaction.
  
 - for create floating ip case transaction is initialized on
 create_floatingip level:
 create_floatingip(l3_db)-create_port(plugin)-create_port(db_base)
 So IPAM call should be added into create_floatingip to be outside db
 transaction
  
 - for usual port create transaction is initialized on plugin's
 create_port level, and John's change[1] cover this case:
 create_port(plugin)-create_port(db_base)
  
 Create floating ip work-flow involves calling plugin's create_port,
 so IPAM code inside of it should be executed only when it is not wrapped
 into top level transaction.
  
 2. It is opened question about error handling.
 Should we use taskflow to manage IPAM calls to external systems?
 Or simple exception based model is enough to handle rollback actions on
 third party systems in case of failing main db transaction.
  
 [1] https://review.openstack.org/#/c/172443/
 [2] neutron/db/l3_db.py: line 905
  
 Thanks,
 Pavel
  
 On 10.04.2015 21:04, openstack-dev-requ...@lists.openstack.org wrote:
  L3 Team,
  
  I have put up a WIP [1] that provides an approach that shows the ML2
 create_port method refactored to use the IPAM driver prior to initiating
 the database transaction. Details 

Re: [openstack-dev] [Openstack-operators] [Neutron] The specs process, effective operators feedback and product management

[Assaf Muller]

Just to offer some closure, it seems like the voting idea was shot down with
the energy of a trillion stars, yet the general idea of offering an easy way
for users to request features makes sense. Expect to see ideas of how
to implement this soon...

- Original Message -
 
  On Apr 10, 2015, at 11:04 AM, Boris Pavlovic bo...@pavlovic.me wrote:
  
  Hi,
  
  I believe that specs are too detailed and too dev oriented for managers,
  operators and devops.
  They actually don't want/have time to write/read all the stuff in specs and
  that's why the communication between dev  operators community is a
  broken.
  
  I would recommend to think about simpler approaches like making mechanism
  for proposing features/changes in projects.
  Like we have in Rally:
  https://rally.readthedocs.org/en/latest/feature_requests.html
  
  This is similar to specs but more concentrate on WHAT rather than HOW.
 
 +1
 
 I think the line between HOW and WHAT are too often blurred in Neutron.
 Unless we’re able to improve our ability to communicate at an appropriate
 level of abstraction with non-dev stakeholders, meeting their needs will
 continue to be a struggle.
 
 
 Maru
 __
 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] replace external ip monitor

[Assaf Muller]

.

- Original Message -
 …
 
 Hello.
 
 I would like to discuss the possibility to replace external ip monitor
 in the neutron code [1] with an internal native Python code [2]
 
 The issues of the current implementation:
 * an external process management
 * text output parsing (possibly buffered)
 
 The proposed library:
 * pure Python code
 * threadless (by default) socket-like objects to work with netlink
 * optional eventlet optimization
 * netlink messages as native python objects
 * compatible license
 

How's packaging looking on all supported platforms?

On a related note, ip_monitor.py is 87 lines of code, I'd be wary of getting
rid of it and using a full blown library instead. Then again, using pyroute2,
we might want to replace other pieces of code (Such as parts of ip_lib).

 If it's ok, I would prepare a patchset this week.
 
 [1] neutron/agent/linux/ip_monitor.py
 [2] https://github.com/svinota/pyroute2
 
 --
 Peter V. Saveliev
 
 __
 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] [Nova][Neutron] Linuxbridge as the default in DevStack [was: Status of the nova-network to Neutron migration work]

[Assaf Muller]

- Original Message -
 if linux bridge was a viable nova-network multi-host HA replacement, you'd
 be OK with this change?
 
 I'd be much more in favor of it. yes. Though I think its a long way from
 being there...
 
 planet openstack has a nice set of articles on how dvr works right now,

Thank you :)

 and having read through, I think its going to be very difficult to implement
 that way with linuxbridge. It uses flow tables pretty heavily. LinuxBridge
 has nothing like that as far as I know.

To be brutally honest I think that any solution that tries to implement DVR
with Linux bridge will be shot down by the Neutron community. We're already
struggling to maintain DVR, polish it and have it well tested. Adding more
complexity seems outright insane to me and I suspect that others will share
the sentiment.

 
 Because of that, I would expect that as DVR matures, the LinuxBridge
 implementation will wither further on the vine. :/
 
 Just my 2 cents. Ops will probably need to consider the complexity
 necessary, just like the linux kernel is complex but in the end, the
 complexity is well worth it.

That's what Neutron developers are likely to say.

 
 To get a truly scalable NaaS, which I think is critical, you need advanced
 SDN and I'm not convinced LinuxBridge is advanced enough to work long
 term...
 
 Thanks,
 Kevin
 
 
 From: Tom Fifield [t...@openstack.org]
 Sent: Wednesday, April 15, 2015 7:09 PM
 To: openstack-dev@lists.openstack.org
 Subject: Re: [openstack-dev] [Nova][Neutron] Linuxbridge as the default in
 DevStack [was: Status of the nova-network to Neutron migration work]
 
 On 16/04/15 10:54, Fox, Kevin M wrote:
  Yes, but if stuff like dvr is the only viable replacement to
  nova-network in production, then learning the non representitive config
  of neutron with linuxbridge might be misleading/counter productive since
  ovs looks very very different.
 
 Sure, though on the other hand, doesn't current discussion seem to
 indicate that OVS with DVR is not a viable replacement for nova-network
 multi-host HA (eg due to complexity), and this is why folks were working
 towards linux bridge?
 
 In essence: if linux bridge was a viable nova-network multi-host HA
 replacement, you'd be OK with this change?
 
 
  Kevin *
  *
  
  *From:* Tom Fifield
  *Sent:* Wednesday, April 15, 2015 5:58:43 PM
  *To:* openstack-dev@lists.openstack.org
  *Subject:* Re: [openstack-dev] [Nova][Neutron] Linuxbridge as the
  default in DevStack [was: Status of the nova-network to Neutron
  migration work]
 
 
 
  On 14/04/15 23:36, Dean Troyer wrote:
  On Tue, Apr 14, 2015 at 7:02 AM, Miguel Angel Ajo Pelayo
  mangel...@redhat.com mailto:mangel...@redhat.com wrote:
 
  Why would operators install from devstack? that’s not going to be
  the case.
 
 
  If they do they need more help than we can give...
 
  So, ummm, there is actually a valid use case for ops on devstack: it's
  part of the learning process.
 
  In my rounds, I've had feedback from more than a few whose first
  OpenStack experience was to run up a devstack, so they could run ps
  aufx, brctl, iptables, etc just to see what was going on under the
  covers before moving on to something more 'proper'.
 
 
  While acknowledging that the primary purpose and audience of devstack is
  and should remain development and developers, if there is something we
  can do to improve the experience for those ops first-timers that doesn't
  have a huge impact on devs, it would be kinda nice.
 
  After all, one of the reasons this thread exists is because of problems
  with that ramp up process, no?
 
 
 
  I believe we should have both LB  OVS well tested, if LB is a good
  option for
  some operators willing to migrate from nova, that’s great, let’s
  make sure LB
  is perfectly tested upstream.
 
 
  +1
 
  But by doing such change we can’t let OVS code rot and we would be
  neglecting
  a big customer base which is now making use of the openvswitch
  mechanism.
  (may be I’m miss understanding  the scope of the change).
 
 
  Changing DevStack's default doesn't remove anything OVS-related, nor
  does it by itself remove any OVS jobs.  It gives everyone who is happy
  with nova-net (or more correctly doesn't think about it) a new default
  that changes their experience the least for when nova-net disappears.
 
  dt
 
  --
 
  Dean Troyer
  dtro...@gmail.com mailto:dtro...@gmail.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 

[openstack-dev] [Neutron] The specs process, effective operators feedback and product management

[Assaf Muller]

The Neutron specs process was introduced during the Juno timecycle. At the time 
it
was mostly a bureaucratic bottleneck (The ability to say no) to ease the pain 
of cores
and manage workloads throughout a cycle. Perhaps this is a somewhat naive 
outlook,
but I see other positives, such as more upfront design (Some is better than 
none),
less high level talk during the implementation review process and more focus on 
the details,
and 'free' documentation for every major change to the project (Some would say 
this
is kind of a big deal; What better way to write documentation than to force the 
developers
to do it in order for their features to get merged).

That being said, you can only get a feature merged if you propose a spec, and 
the only
people largely proposing specs are developers. This ingrains the open source 
culture of
developer focused evolution, that, while empowering and great for developers, 
is bad
for product managers, users (That are sometimes under-presented, as is the case 
I'm trying
to make) and generally causes a lack of a cohesive vision. Like it or not, the 
specs process
and the driver's team approval process form a sort of product management, 
deciding what
features will ultimately go in to Neutron and in what time frame.

We shouldn't ignore the fact that we clearly have people and product managers 
pulling the strings
in the background, often deciding where developers will spend their time and 
what specs to propose,
for the purpose of this discussion. I argue that managers often don't have the 
tools to understand
what is important to the project, only to their own customers. The Neutron 
drivers team, on the other hand,
don't have a clear incentive (Or I suspect the will) to spend enormous amounts 
of time doing 'product management',
as being a driver is essentially your third or fourth job by this point, and 
are the same people
solving gate issues, merging code, triaging bugs and so on. I'd like to avoid 
to go in to a discussion of what's
wrong with the current specs process as I'm sure people have heard me complain 
about this in
#openstack-neutron plenty of times before. Instead, I'd like to suggest a 
system that would perhaps
get us to implement specs that are currently not being proposed, and give an 
additional form of
input that would make sure that the development community is spending it's time 
in the right places.

While 'super users' have been given more exposure, and operators summits give 
operators
an additional tool to provide feedback, from a developer's point of view, the 
input is
non-empiric and scattered. I also have a hunch that operators still feel their 
voice is not being heard.

I propose an upvote/downvote system (Think Reddit), where everyone (Operators 
especially) would upload
paragraph long explanations of what they think is missing in Neutron. The 
proposals have to be actionable
(So 'Neutron sucks', while of great humorous value, isn't something I can do 
anything about),
and I suspect the downvote system will help self-regulate that anyway. The 
proposals are not specs, but are
like product RFEs, so for example there would not be a 'testing' section, as 
these proposals will not
replace the specs process anyway but augment it as an additional form of input. 
Proposals can range
from new features (Role based access control for Neutron resources, dynamic 
routing,
Neutron availability zones, QoS, ...) to quality of life improvements (Missing 
logs, too many
DEBUG level logs, poor trouble shooting areas with an explanation of what could 
be improved, ...)
to long standing bugs, Nova network parity issues, and whatever else may be 
irking the operators community.
The proposals would have to be moderated (Closing duplicates, low quality 
submissions and implemented proposals
for example) and if that is a concern then I volunteer to do so.

This system will also give drivers a 'way out': The last cycle we spent time 
refactoring this and that,
and developers love doing that so it's easy to get behind. I think that as in 
the next cycles we move back to features,
friction will rise and the process will reveal its flaws.

Something to consider: Maybe the top proposal takes a day to implement. Maybe 
some low priority bug is actually
the second highest proposal. Maybe all of the currently marked 'critical' bugs 
don't even appear on the list.
Maybe we aren't spending our time where we should be.

And now a word from our legal team: In order for this to be viable, the system 
would have to be a
*non binding*, *additional* form of input. The top proposal *could* be declined 
for the same reasons
that specs are currently being declined. It would not replace any of our 
current systems or processes.


Assaf Muller, Cloud Networking Engineer
Red Hat

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org

Re: [openstack-dev] [Neutron] L3 agent rescheduling issue

[Assaf Muller]

- Original Message -
 One reason for not sending the heartbeat from a separate greenthread could be
 that the agent is already doing it [1].
 The current proposed patch addresses the issue blindly - that is to say
 before declaring an agent dead let's wait for some more time because it
 could be stuck doing stuff. In that case I would probably make the
 multiplier (currently 2x) configurable.
 
 The reason for which state report does not occur is probably that both it and
 the resync procedure are periodic tasks. If I got it right they're both
 executed as eventlet greenthreads but one at a time. Perhaps then adding an
 initial delay to the full sync task might ensure the first thing an agent
 does when it comes up is sending a heartbeat to the server?

There's a patch that is related to this issue:
https://review.openstack.org/#/c/186584/

I made a comment there where, at least to me, it makes a lot of sense to insert
a report_state call in the after_start method, right after the agent initializes
but before it performs the first full sync. So, right here before line 560:
https://github.com/openstack/neutron/blob/master/neutron/agent/l3/agent.py#L560

That should help *some* of the issues discussed in this thread, but not all.

 
 On the other hand, while doing the initial full resync, is the agent able to
 process updates? If not perhaps it makes sense to have it down until it
 finishes synchronisation.
 
 Salvatore
 
 [1]
 http://git.openstack.org/cgit/openstack/neutron/tree/neutron/agent/l3/agent.py#n587
 
 On 4 June 2015 at 16:16, Kevin Benton  blak...@gmail.com  wrote:
 
 
 
 
 Why don't we put the agent heartbeat into a separate greenthread on the agent
 so it continues to send updates even when it's busy processing changes?
 On Jun 4, 2015 2:56 AM, Anna Kamyshnikova  akamyshnik...@mirantis.com 
 wrote:
 
 
 
 Hi, neutrons!
 
 Some time ago I discovered a bug for l3 agent rescheduling [1]. When there
 are a lot of resources and agent_down_time is not big enough neutron-server
 starts marking l3 agents as dead. The same issue has been discovered and
 fixed for DHCP-agents. I proposed a change similar to those that were done
 for DHCP-agents. [2]
 
 There is no unified opinion on this bug and proposed change, so I want to ask
 developers whether it worth to continue work on this patch or not.
 
 [1] - https://bugs.launchpad.net/neutron/+bug/1440761
 [2] - https://review.openstack.org/171592
 
 --
 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
 
 
 
 __
 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 Assaf Muller for the Neutron Core Reviewer Team

[Assaf Muller]

Thank you.

We have a lot of work ahead of us :)


- Original Message -
 It's a been a week since I proposed this, with no objections. Welcome to the
 Neutron core reviewer team as the new QA Lieutenant Assaf!
 
 On Tue, Jun 2, 2015 at 12:35 PM, Maru Newby  ma...@redhat.com  wrote:
 
 
 +1 from me, long overdue!
 
 
  On May 28, 2015, at 9:42 AM, Kyle Mestery  mest...@mestery.com  wrote:
  
  Folks, I'd like to propose Assaf Muller to be a member of the Neutron core
  reviewer team. Assaf has been a long time contributor in Neutron, and he's
  also recently become my testing Lieutenant. His influence and knowledge in
  testing will be critical to the team in Liberty and beyond. In addition to
  that, he's done some fabulous work for Neutron around L3 HA and DVR. Assaf
  has become a trusted member of our community. His review stats place him
  in the pack with the rest of the Neutron core reviewers.
  
  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 Assaf to the
  core reviewer team.
  
  Thanks!
  Kyle
  
  [1] http://stackalytics.com/report/contribution/neutron-group/180
  __
  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] Interconnecting projects

[Assaf Muller]

I'll defer to Kevin, the spec author, but you should know that the
implementation is not merged yet.

- Original Message -
 Hi Assaf,
 
 Now reading the rbac network specs carefully, I believe it does allow private
 networks to be shared to other tenants by non-admin users.
 
 So the command  neutron rbac create  net - uuid | net - name  -- type
 network -- tenant - id  tenant - uuid  -- action access_a
 s_shared  - can this be only used by an admin ? From the specs, it did not
 seem so.
 
 Also is the action access_as_external available now ?
 
 
 
 
 
 
 
 
 
 
 
 
 
 On Tue, Jun 2, 2015 at 9:14 PM, Assaf Muller  amul...@redhat.com  wrote:
 
 
 Check out:
 http://specs.openstack.org/openstack/neutron-specs/specs/liberty/rbac-networks.html
 If I understand correctly, what Anik is probably asking for is way to connect
 two OpenStack projects together from a network point of view, where a
 private network in Project1 can be connected to a Router in Project2. AFAIK,
 I don't think we are planning to expose such model in RBAC where a tenant
 (non-admin) has a way control who can see/connect-to his/her resources.
 
 @Anik, please correct me if I am wrong.
 
 
 
 
 Kevin is trying to solve exactly this problem. We're really hoping to land it
 in
 time for Liberty.
 
 - Original Message -
  Hi,
  
  Trying to understand if somebody has come across the following scenario:
  
  I have a two projects: Project 1 and Project 2
  
  I have a neutron private network in Project 1, that I want to connect that
  private network to a neutron port in Project 2.
  
  This does not seem to be possible without using admin credentials. I am not
  talking about a shared provider network here.
  
  It seems that the problem lies in the fact that there is no data model
  today
  that lets one Project have knowledge about any other Project inside the
  same
  OpenStack region.
  
  Any pointers there will be helpful.
  Regards,
  Anik
 
  
  __
  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

Re: [openstack-dev] [Neutron][DevStack] Standing on the shoulders of giants - Linux Bridge testing at the gate

[Assaf Muller]

- Original Message -
 On Fri, Jun 19, 2015 at 2:20 AM, Sean M. Collins  s...@coreitpro.com 
 wrote:
 
 
 Hi,
 
 I wanted to give a quick update on the new experimental job for testing
 the Linux Bridge mechanism driver for Neutron.
 
 I believe that there is only one patch that needs to be merged, in order to
 get the job to a point where we could move from experimental to
 non-voting.
 
 https://review.openstack.org/#/c/192906/
 
 Which is a fix that Dr. Jens Rosenboom authored quite a long time ago,
 and I stared at for enough time that it is embarrassing - hence the
 subject line of this message. Dr. Rosenboom did the majority of the
 work to make all this happen in a previous review, centered around
 Neutron being the default in DevStack - it just took me a long time
 to understand what he did - and then shuffle some code around so that
 configuration that we needed at the gate didn't end up in DevStack, and
 instead would go into the Linux Bridge job configuration.
 
 You can see the results pretty clearly in this review:
 
 https://review.openstack.org/#/c/187235/
 
 When that patch is not applied, we fail all the tempest scenario tests.
 When we apply it, we pass all the tempest scenario tests.
 
 Anyway, I'm quite excited about the status of things, and also wanted to
 publicly thank Dr. Jens Rosenboom for the work that I borrowed
 from him.
 
 
 Great work Sean and Jens! This is fantastic and helps get us to a point where
 we're able to test Linuxbridge on parity with OVS.

I hope to have Linux Bridge tested on par with OVS in the upcoming full stack
tests as well.

 
 Thanks,
 Kyle
 
 
 
 --
 Sean M. Collins
 
 __
 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] Proposing Brian Haley to Neutron L3 Core Reviewer Team

[Assaf Muller]

+1

- Original Message -
 Folks,
 
 As the Neutron L3 Lieutenant [1] under the PTL, Kyle, I'd like to
 propose Brian Haley as a member of the Neutron L3 core reviewer team.
 Brian has been a long time contributor in Neutron showing expertise
 particularly in IPv6, iptables, and Linux kernel matters.  His
 knowledge and involvement will be very important especially in this
 area.  Brian has become a trusted member of our community.  His review
 stats [2][3][4] place him comfortably with other Neutron core
 reviewers.  He regularly runs proposed patches himself and gives
 insightful feedback.  He has shown a lot of interest in the success of
 Neutron.
 
 Existing Neutron core reviewers from the L3 area of focus, please vote
 +1/-1 for the addition of Brian to the core reviewer team.
 Specifically, I'm looking for votes from Henry, Assaf, and Mark.
 
 Thanks!
 Carl
 
 [1]
 http://docs.openstack.org/developer/neutron/policies/core-reviewers.html#adding-or-removing-core-reviewers
 [2]
 https://review.openstack.org/#/q/reviewer:%22Brian+Haley+%253Cbrian.haley%2540hp.com%253E%22,n,z
 [3] http://stackalytics.com/report/contribution/neutron-group/90
 [4] http://stackalytics.com/?user_id=brian-haleymetric=marks
 
 __
 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 Rossella Sblendido for the Control Plane core team

[Assaf Muller]

+1

- Original Message -
 Excellent news! +1
 
 Cheers,
 
 Edgar
 
 
 On Jun 12, 2015, at 12:50 PM, Kevin Benton  blak...@gmail.com  wrote:
 
 
 
 
 Hello!
 
 As the Lieutenant of the built-in control plane[1], I would like Rossella
 Sblendido to be a member of the control plane core reviewer team.
 
 Her review stats are in line with other cores[2] and her feedback on patches
 related to the agents has been great. Additionally, she has been working
 quite a bit on the blueprint to restructure the L2 agent code so she is very
 familiar with the agent code and the APIs it leverages.
 
 Existing cores that have spent time working on the reference implementation
 (agents and AMQP code), please vote +1/-1 for her addition to the team.
 Aaron, Gary, Assaf, Maru, Kyle, Armando, Carl and Oleg; you have all been
 reviewing things in these areas recently so I would like to hear from you
 specifically.
 
 1.
 http://docs.openstack.org/developer/neutron/policies/core-reviewers.html#core-review-hierarchy
 2. http://stackalytics.com/report/contribution/neutron-group/30
 
 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
 
 __
 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] [Networking] Support for multiple gateways in neutron/nova-net subnets for provider networks

[Assaf Muller]

I think Shraddha was talking about the gateway IP the DHCP server will respond
with. Different VMs will get different gateways.

- Original Message -
 That logic is contained in the virtual machine. We have no control over that.
 
 On Thu, Jun 11, 2015 at 3:34 PM, Shraddha Pandhe 
 spandhe.openst...@gmail.com  wrote:
 
 
 
 The idea is to round-robin between gateways by using some sort of mod
 operation
 
 So logically it can look something like:
 
 idx = len(gateways) % ip
 gateway = gateways[idx]
 
 
 This is just one idea. I am open to more ideas.
 
 
 
 
 On Thu, Jun 11, 2015 at 3:10 PM, Kevin Benton  blak...@gmail.com  wrote:
 
 
 
 
 What gateway address do you give to regular clients via dhcp when you have
 multiple?
 
 
 On Jun 11, 2015 12:29 PM, Shraddha Pandhe  spandhe.openst...@gmail.com 
 wrote:
  
  Hi,
  Currently, the Subnets in Neutron and Nova-Network only support one
  gateway. For provider networks in large data centers, quite often, the
  architecture is such a way that multiple gateways are configured per
  subnet. These multiple gateways are typically spread across backplanes so
  that the production traffic can be load-balanced between backplanes.
  This is just my use case for supporting multiple gateways, but other folks
  might have more use cases as well and also want to take the community's
  opinion about this feature. Is this something that's going to help a lot
  of users?
  I want to open up a discussion on this topic and figure out the best way to
  handle this.
  1. Should this be done in a same way as dns-nameserver, with a separate
  table with two columns: gateway_ip, subnet_id.
  2. Should Gateway field be converted to a List instead of String?
  I have also opened a bug for Neutron here:
  https://bugs.launchpad.net/neutron/+bug/1464361
  
  
  __
  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
 
 
 
 
 --
 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
 

__
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] Interconnecting projects

[Assaf Muller]

Check out:
http://specs.openstack.org/openstack/neutron-specs/specs/liberty/rbac-networks.html

Kevin is trying to solve exactly this problem. We're really hoping to land it in
time for Liberty.

- Original Message -
 Hi,
 
 Trying to understand if somebody has come across the following scenario:
 
 I have a two projects: Project 1 and Project 2
 
 I have a neutron private network in Project 1, that I want to connect that
 private network to a neutron port in Project 2.
 
 This does not seem to be possible without using admin credentials. I am not
 talking about a shared provider network here.
 
 It seems that the problem lies in the fact that there is no data model today
 that lets one Project have knowledge about any other Project inside the same
 OpenStack region.
 
 Any pointers there will be helpful.
 Regards,
 Anik
 201-245-1569
 
 __
 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] - breaking changes for plugins/drivers

[Assaf Muller]

- Original Message -
 
 
 I think we need to revisit the test infrastructure requirement. We have a lot
 of logic to setup and test plugins/drivers and making each repo duplicate
 all of that is a pretty big waste of effort. Maybe some base stuff should go
 in neutron lib?

Absolutely.

 On Jul 1, 2015 12:32 PM, Doug Wiegley  doug...@parksidesoftware.com 
 wrote:
 
 
 
 
 
 
 
 On Jun 30, 2015, at 11:22 PM, Kevin Benton  blak...@gmail.com  wrote:
 
 Hi,
 
 We have had at least two breaking changes merge this week for out-of-tree
 drivers/plugins. These are just the two I noticed that broke the Big Switch
 CI (the one I keep an eye on since I had set it up):
 
 1. Removed test_lib that changes config files.
 https://review.openstack.org/#/c/196583/
 2. Removed the loopingcall common util with no deprecation cycle or
 announcement. https://review.openstack.org/#/c/192999/
 
 I proposed a revert for 1 that merged, but I don't particularly want to keep
 fighting this. What is our current policy on this? Just change whatever we
 want and tell plugin maintainers this is just the way things work?
 
 So, this is a big hairy bit of suck right now. We expected some of this
 fallout with the services split and plugin decomp (in fact, we counted on it
 to move this ball forward), and we had adopted these guideilnes:
 
 1. Other repos should not rely on oslo-incubated modules.
 (neutron/openstack/…)
 2. Other repos should not rely on neutron’s test infrastructure.
 (neutron/tests/…)
 3. For changes in any other area, they should be additive, or have a
 backwards compatibility shim or a big warning notice (the last being the
 suckiest answer.)
 4. When we start getting “stable” interfaces in neutron/lib/…, which has the
 proviso of NO breaking changes without a shim or deprecation cycle, we get
 rid of restriction #3.
 
 We’ve been regularly merging code that breaks #3 and we have plugins that use
 code from #1 and #2 today.
 
 IMO, the core review team needs to be aware that neutron is now a library,
 and refactors and gratuitous cleanups have a pretty hefty cost. Especially
 in Liberty, be careful.
 
 Thanks,
 doug
 
 
 
 
 
 
 
 
 --
 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
 
 
 __
 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] - Proposing Miguel Angel Ajo for the Control Plane core team

[Assaf Muller]

+1!

- Original Message -
 A huge +1
 
 From: Kevin Benton  blak...@gmail.com 
 Reply-To: OpenStack List  openstack-dev@lists.openstack.org 
 Date: Monday, July 6, 2015 at 1:02 PM
 To: OpenStack List  openstack-dev@lists.openstack.org 
 Subject: [openstack-dev] [neutron] - Proposing Miguel Angel Ajo for the
 Control Plane core team
 
 
 
 Hello!
 
 As the Lieutenant of the built-in control plane[1], I am proposing to add
 Miguel Angel Ajo to the control plane core reviewer team.
 
 His review stats are inline with the other core reviewers[2], and his work on
 improving the stability/performance of the agents over the last year has
 been important in making the reference implementation reliable.
 
 Existing cores, please vote +1/-1 for his addition to the team.
 
 Cheers!
 
 1. http://docs.openstack.org/developer/neutron/policies/core-reviewers.html
 2. http://stackalytics.com/report/contribution/neutron/30
 http://stackalytics.com/report/contribution/neutron/60
 http://stackalytics.com/report/contribution/neutron/90
 
 --
 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
 

__
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 YAMAMOTO Takashi for the Control Plane core team

[Assaf Muller]

+1

- Original Message -
 Hello all!
 
 As the Lieutenant of the built-in control plane[1], I would like YAMAMOTO
 Takashi to be a member of the control plane core reviewer team.
 
 He has been extensively reviewing the entire codebase[2] and his feedback on
 patches related to the reference implementation has been very useful. This
 includes everything ranging from the AMPQ API to OVS flows.
 
 Existing cores that have spent time working on the reference implementation
 (agents and AMQP code), please vote +1/-1 for his addition to the team.
 Aaron, Gary, Assaf, Maru, Kyle, Armando, Carl and Oleg; you have all been
 reviewing things in these areas recently so I would like to hear from you
 specifically.
 
 1.
 http://docs.openstack.org/developer/neutron/policies/core-reviewers.html#core-review-hierarchy
 2. http://stackalytics.com/report/contribution/neutron-group/90
 
 
 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
 

__
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] Why need br-int and br-tun in openstack neutron

[Assaf Muller]

The OVS agent has been implemented under the assumption that you're working 
with two bridges, it's a requirement. It creates the tunneling bridge if you 
enable tunneling, you can't have it any other way.



 On 24 במאי 2015, at 03:52, Daniel Comnea comnea.d...@gmail.com wrote:
 
 
 
 On Sat, May 23, 2015 at 12:43 PM, Assaf Muller amul...@redhat.com wrote:
 There's no real reason as far as I'm aware, just an implementation decision.
 [DC]: in this case wouldn't this bee seen suitable as best practicies vs what 
 every blog/ manual is suggesting? 
 
 
 
 On 21 במאי 2015, at 01:48, Na Zhu na...@cn.ibm.com wrote:
 
 Dear,
 
 
 When OVS plugin is used with GRE option in Neutron, I see that each compute 
 node has br-tun and br-int bridges created. 
 
 I'm trying to understand why we need the additional br-tun bridge here. 
 Can't we create tunneling ports in br-int bridge, and have br-int relay 
 traffic between VM ports and tunneling ports directly? Why do we have to 
 introduce another br-tun bridge?  
 
 
 Regards,
 Juno Zhu
 Staff Software Engineer, System Networking
 China Systems and Technology Lab (CSTL), IBM Wuxi
 Email: na...@cn.ibm.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
 
 __
 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] Why need br-int and br-tun in openstack neutron

[Assaf Muller]

Comments in-line.

- Original Message -
 On 23 May 2015 at 04:43, Assaf Muller  amul...@redhat.com  wrote:
 
 
 
 There's no real reason as far as I'm aware, just an implementation decision.
 
 This is inaccurate. There is a reason(s), and this has been asked before:
 
 http://lists.openstack.org/pipermail/openstack/2014-March/005950.html

This link is to a thread asking why do we connect a Linux bridge between a tap
device and br-int (For security groups).

 http://lists.openstack.org/pipermail/openstack/2014-April/006865.html

This link is to this thread itself.

 
 In a nutshell, the design decision that led to the existing architecture is
 due to the way OVS handles packets and interact with netfilter.

I think you're talking about the bridge between a tap device and br-int and
not about br-tun.

 
 The fact that we keep asking the same question clearly shows lack of
 documentation, both developer and user facing.
 
 I'll get this fixed once and for all.

Thank you.

 
 Thanks,
 Armando
 
 
 
 
 
 
 On 21 במאי 2015, at 01:48, Na Zhu  na...@cn.ibm.com  wrote:
 
 
 
 
 
 
 Dear,
 
 
 When OVS plugin is used with GRE option in Neutron, I see that each compute
 node has br-tun and br-int bridges created.
 
 I'm trying to understand why we need the additional br-tun bridge here.
 Can't we create tunneling ports in br-int bridge, and have br-int relay
 traffic between VM ports and tunneling ports directly? Why do we have to
 introduce another br-tun bridge?
 
 
 Regards,
 Juno Zhu
 Staff Software Engineer, System Networking
 China Systems and Technology Lab (CSTL), IBM Wuxi
 Email: na...@cn.ibm.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
 
 
 
 __
 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] Why need br-int and br-tun in openstack neutron

[Assaf Muller]

There's no real reason as far as I'm aware, just an implementation decision.



 On 21 במאי 2015, at 01:48, Na Zhu na...@cn.ibm.com wrote:
 
 Dear,
 
 
 When OVS plugin is used with GRE option in Neutron, I see that each compute 
 node has br-tun and br-int bridges created. 
 
 I'm trying to understand why we need the additional br-tun bridge here. 
 Can't we create tunneling ports in br-int bridge, and have br-int relay 
 traffic between VM ports and tunneling ports directly? Why do we have to 
 introduce another br-tun bridge?  
 
 
 Regards,
 Juno Zhu
 Staff Software Engineer, System Networking
 China Systems and Technology Lab (CSTL), IBM Wuxi
 Email: na...@cn.ibm.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] binding information for networks

[Assaf Muller]

On Wed, Aug 19, 2015 at 2:34 PM, Gal Sagie gal.sa...@gmail.com wrote:

 Hello all,

 Recently i have came across two use cases that having binding
 information, or metadata
 for networks can be useful. (similar to the port binding profile for that
 matter)

 For example:

 1) In project Kuryr we want to have a binding information which maps the
 Neutron network
 to docker network (And we might want to do it prior to the docker
 network being created,
 that is assign a network that is ready to be attached) so this field
 also needs to be editable
 (just like the port binding profile)

 2) For multi site OpenStack (multi cloud) use cases we might want to share
 information which
 binds logically same network that is created at each OpenStack cloud
 site (and hence the ID's
 are different).
 (Something like this could be useful for project Tricircle for example)

 3) Use cases for multi controllers environments? (each controller manage
 different networks?)

 I believe adding such optional field to the network API is really low risk
 due to its being optional
 and i believe other use cases can be found to leverage it.


I wonder if we should just add a key/pair tuples tags or metadata
generic field instead. There's
been similar requests floating about that could also use a place to dump
their data in.



 Feel free to share ideas/comments.

 If there are no strong objections to it, i will add an RFE/Spec to add
 this ability.

 Thanks
 Gal.



 __
 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] Etherpad from the Ops Meetup

[Assaf Muller]

On Wed, Aug 19, 2015 at 2:52 PM, Edgar Magana edgar.mag...@workday.com
wrote:

 Folks,

 I just want to share with you the feedback collected today during the
 networking session on Ops Meet-up:
 https://etherpad.openstack.org/p/PAO-ops-network-model

 Special thanks to Ryan and Doug for helping on some questions.


The only action items for Neutron developers that I can spot are:

   1. Linux bridge + DVR / multi host
   2. Prevent data loss when restarting the OVS agent (The patch [1] is
   very close to merge anyway, nothing more to do here)
   3. Work as described by [2] (Big deployers team)

The rest is either polling (Who uses what feature / plugin / etc) or
generic comments with no actionable bugs or RFEs.
Did I miss anything?

[1] https://review.openstack.org/#/c/182920/
[2] https://etherpad.openstack.org/p/Network_Segmentation_Usecases

Cheers,

 Edgar

 __
 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] Expected cli behavior when ovs-agent is down

[Assaf Muller]

On Sat, Aug 22, 2015 at 5:08 AM, shihanzhang ayshihanzh...@126.com wrote:

 hi Vikas Choudhary, when ovs-agent service recover(ovs-agent process
 restart), the dhcp port will not re-binding successfully?





 At 2015-08-22 14:26:08, Vikas Choudhary choudharyvika...@gmail.com
 wrote:

 Hi Everybody,

 I want to discuss on https://bugs.launchpad.net/neutron/+bug/1348589.This
 is there for more than a year and no discussion i could find on this.

 *Scenario:*
 ovs-agent is down and then a network and subnet under this newly created
 network are created using cli. No error visible to user, but following
 irregularities are found.

 *Discrepancies:*
 1. neutron port-show dhcp-port shows:
  binding:vif_type  | binding_failed
 2. Running ovs-ofctl dump-flows br-tun, no of-flow got added
 3. Running ovs-vsctl show br-int, no tag for dhcp-port.

 neutron db will have all the attributes required to retry vif binding.My
 query is when should we trigger this rebinding.Two approaches i could think
 of are:
 1 At neutron server restart, for all ports with vif_type as
  binding_failed plugins/ml2/drivers/mech_agent.bind_port can be invoked
 as a sync up activity.


Or when you start the OVS agent again. Check out this patch:
https://review.openstack.org/#/c/162260/.



 2 In neutron port update api,
 http://developer.openstack.org/api-ref-networking-v2-ext.html , could be
 enhanced to receive vif binding related options also and then
 eventually plugins/ml2/drivers/mech_agent.bind_port can be
 invoked.Corresponding changes will be made to 'port update cli' also.

 Please suggest.



 夏日畅销榜大牌美妆只要1元
 http://r.mail.163.com/r.jsp?url=http%3A%2F%2F1.163.com%2Fhd%2Foneact%2Fhdframe.do%3Fid%3D21%26from%3Dfooter_beautysign=817593681_r_ignore_statId=7_13_79_48_r_ignore_uid=n...@163.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][dvr][ha] DVR-HA router is not working.

[Assaf Muller]

Adding the author of the patches. This reinforces the need to hold on
merging these patches until they have an in-tree integration test.

On Tue, Aug 11, 2015 at 4:13 PM, Korzeniewski, Artur 
artur.korzeniew...@intel.com wrote:

 Hi,

 I’ve been playing around with DVR-HA patches [1][2], have them applied on
 Mondays master branch.

 The problem is that the dvr-ha router is not working with SNAT and
 floating ips.



 My setup:

 Devstack-34 – all in one (controller, compute, DVR agent, DHCP node)

 Devstack-35 – compute node and DVR agent

 Devstack-36 – network node (SNAT)

 Devstack-37 – network node 2 (SNAT)



 External interface (router_gateway) is down for created dvr-ha router. The
 snat port (router_centralized_snat) is also down after connecting the
 tenant network.

 I’m not sure where is the problem, can someone look at the logs and point
 me the place where to look for the answer why the ports are not reported as
 UP?

 Add default gateway for DVR-HA router, log from active network node:
 http://pastebin.com/S7rYpDns

 Add default gateway for DVR-HA router, log from neutron server node:
 http://pastebin.com/WpcV1g09



 The external gateway IP is not reachable from external network, and VMs
 are not able to ping default gateway  (10.2.2.1)…

 I have to add, that on the same setup the usual DVR router is working fine
 (hosted on the same network node)



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

 [2] https://review.openstack.org/#/c/143169



 Regards,

 Artur Korzeniewski

 

 Intel Technology Poland sp. z o.o.

 KRS 101882

 ul. Slowackiego 173, 80-298 Gdansk



 __
 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] how to debug neutron using eclipse pydev?

[Assaf Muller]

We need to update that page. I haven't used PyDev in years, I use PyCharm.
There's an option in PyCharm called 'Enable Gevent debugging' (Gevent is
a green threads library very similar to eventlet, which is what we use
in OpenStack). I read that PyDev 3.7+ has support for Gevent debugging
as well. Can you check if simply enabling that (And not editing any code)
solves your issue? If so I can update the wiki with your conclusions.

- Original Message -
 Hi,All
 
 I follow the wiki page:
 https://wiki.openstack.org/wiki/NeutronDevelopment
 
 
 * Eclipse pydev - Free. It works! (Thanks to gong yong sheng ). You need
 to modify quantum-server and __init__.py as following: From:
 eventlet.monkey_patch() To: eventlet.monkey_patch(os=False,
 thread=False)
 
 but instruction about Eclipse pydev is invalid,as the file has changed,no
 mokey_patch any more.
 so what can i do?
 
 --
 Regards,
 kkxue
 
 __
 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][L3] Representing a networks connected by routers

[Assaf Muller]

- Original Message -
 
 On 7/23/15, 9:42 AM, Carl Baldwin c...@ecbaldwin.net wrote:
 
 On Wed, Jul 22, 2015 at 3:21 PM, Kevin Benton blak...@gmail.com wrote:
  The issue with the availability zone solution is that we now force
  availability zones in Nova to be constrained to network configuration.
 In
  the L3 ToR/no overlay configuration, this means every rack is its own
  availability zone. This is pretty annoying for users to deal with
 because
  they have to choose from potentially hundreds of availability zones and
 it
  rules out making AZs based on other things (e.g.  current phase, cooling
  systems, etc).
 
  I may be misunderstanding and you could be suggesting to not expose this
  availability zone to the end user and only make it available to the
  scheduler. However, this defeats one of the purposes of availability
 zones
  which is to let users select different AZs to spread their instances
 across
  failure domains.
 
 I was actually talking with some guys at dinner during the Nova
 mid-cycle last night (Andrew ??, Robert Collins, Dan Smith, probably
 others I can't remember) about the relationship of these network
 segments to AZs and cells.  I think we were all in agreement that we
 can't confine segments to AZs or cells nor the other way around.
 
 
 I just want to +1 this one from the operators’ perspective.  Network
 segments, availability zones, and cells are all separate constructs which
 are used for different purposes.  We prefer to not have any relationships
 forced between them.

I agree, which is why I later corrected to expose physical_networks details
via the API instead, and feed that info to the Nova scheduler.

 
 Mike
 
 __
 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] how to debug neutron using eclipse pydev?

[Assaf Muller]

+1

- Original Message -
 We should have the Wiki page redirect, or link to:
 
 https://github.com/openstack/neutron/blob/master/TESTING.rst#debugging
 
 And then update that RST file it to add any info we have about
 debugging under IDEs. Generally, I dislike wikis because they go stale
 very quick and aren't well maintained, compared to files in the code repo
 (hopefully).
 
 
 --
 Sean M. Collins
 
 __
 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][L3] Representing a networks connected by routers

[Assaf Muller]

I added a summary of my thoughts about the enhancements I think we could
make to the Nova scheduler in order to better support the Neutron provider
networks use case.

- Original Message -
 On Tue, Jul 21, 2015 at 1:11 PM, John Belamaric jbelama...@infoblox.com
 wrote:
  Wow, a lot to digest in these threads. If I can summarize my understanding
  of the two proposals. Let me know whether I get this right. There are a
  couple problems that need to be solved:
 
   a. Scheduling based on host reachability to the segments
   b. Floating IP functionality across the segments. I am not sure I am clear
  on this one but it sounds like you want the routers attached to the
  segments
  to advertise routes to the specific floating IPs. Presumably then they
  would
  do NAT or the instance would assign both the fixed IP and the floating IP
  to
  its interface?
 
  In Proposal 1, (a) is solved by associating segments to the front network
  via a router - that association is used to provide a single hook into the
  existing API that limits the scope of segment selection to those associated
  with the front network. (b) is solved by tying the floating IP ranges to
  the
  same front network and managing the reachability with dynamic routing.
 
  In Proposal 2, (a) is solved by tagging each network with some meta-data
  that the IPAM system uses to make a selection. This implies an IP
  allocation
  request that passes something other than a network/port to the IPAM
  subsystem. This fine from the IPAM point of view but there is no
  corresponding API for this right now. To solve (b) either the IPAM system
  has to publish the routes or the higher level management has to ALSO be
  aware of the mappings (rather than just IPAM).
 
 John, from your summary above, you seem to have the best understanding
 of the whole of what I was weakly attempting to communicate.  Thank
 you for summarizing.
 
  To throw some fuel on the fire, I would argue also that (a) is not
  sufficient and address availability needs to be considered as well (as
  described in [1]). Selecting a host based on reachability alone will fail
  when addresses are exhausted. Similarly, with (b) I think there needs to be
  consideration during association of a floating IP to the effect on routing.
  That is, rather than a huge number of host routes it would be ideal to
  allocate the floating IPs in blocks that can be associated with the backing
  networks (though we would want to be able to split these blocks as small as
  a /32 if necessary - but avoid it/optimize as much as possible).
 
 Yes, address availability is a factor and must be considered in either
 case.  My email was getting long already and I thought that could be
 considered separately since I believe it applies regardless of the
 outcome of this thread.  But, since it seems to be an essential part
 of this conversation, let me say something about it.
 
 Ultimately, we need to match up the host scheduled by Nova to the
 addresses available to that host.  We could do this by delaying
 address assignment until after host binding or we could do it by
 including segment information from Neutron during scheduling.  The
 latter has the advantage that we can consider IP availability during
 scheduling.  That is why GoDaddy implemented it that way.
 
  In fact, I think that these proposals are more or less the same - it's just
  in #1 the meta-data used to tie the backing networks together is another
  network. This allows it to fit in neatly with the existing APIs. You would
  still need to implement something prior to IPAM or within IPAM that would
  select the appropriate backing network.
 
 They are similar but to say they're the same is going a bit too far.
 If they were the same then we'd be done with this conversation.  ;)
 
  As a (gulp) third alternative, we should consider that the front network
  here is in essence a layer 3 domain, and we have modeled layer 3 domains as
  address scopes in Liberty. The user is essentially saying give me an
  address that is routable in this scope - they don't care which actual
  subnet it gets allocated on. This is conceptually more in-line with [2] -
  modeling L3 domain separately from the existing Neutron concept of a
  network
  being a broadcast domain.
 
 I will consider this some more.  This is an interesting thought.
 Address scopes and subnet pools could play a role here.  I don't yet
 see how it can all fit together but it is worth some thought.
 
 One nit:  the neutron network might have been conceived as being just
 a broadcast domain but, in practice, it is L2 and L3.  The Neutron
 subnet is not really an L3 construct; it is just a cidr and doesn't
 make sense on its own without considering its association with a
 network and the other subnets associated with the same network.
 
  Fundamentally, however we associate the segments together, this comes down
  to a scheduling problem. Nova needs to be able to incorporate data from
  

Re: [openstack-dev] [neutron] why do we gate tempest using q-vpn not q-l3?

[Assaf Muller]

It's a remnant of pre-*aaS split times - We have to reexamine our
testing strategy post-split.

- Original Message -
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA256
 
 Hi all,
 
 I've stumbled on this one. It turns out we gate neutron against
 openstack installation that runs vpn-agent instead of l3-agent [1]. Is
 it really what we want to do? I would expect that gate validates l3
 agent as is, as is usually found on usual installations that do not
 need vpn connections.
 
 Or is it the neat way we make sure we don't break vpn-agent?
 
 [1]:
 https://git.openstack.org/cgit/openstack-infra/devstack-gate/tree/test-f
 eatures.sh#n21
 
 Ihar
 -BEGIN PGP SIGNATURE-
 Version: GnuPG v2
 
 iQEcBAEBCAAGBQJVsN1RAAoJEC5aWaUY1u57eZ0IAI9oJIikbvD5dxGPoB7wm7mX
 9OE583CAjn+hGUIMGa0kpVSBeDQmkQdp92ginFOo1lvXQZVT30OCOJau5YVoGE77
 Nl1d9TX6xO8vDkBNT5A69vHfZGxjL620+HvOHjupTYimqWiilj6fu0oUge2DNtI7
 do8TgL7SpDx31z9pF70zxqfHbARXq3HOb/AMfTz8jBRcnZmuvOQLt4Q/Xri6KFUw
 uW8XaEZ+3xJYsaFsWna8YIEQY/R4TDqnyStGvRqzX9CGRDkzc/0gWalBSAkXewdQ
 sOwN4MhhxJcWMXRVwPp+auvBOKQJ8Bq5uIR0WRIDhAaUtDNHstDefFnCBzmX8nc=
 =kxs2
 -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][L3] Representing a networks connected by routers

[Assaf Muller]

- Original Message -
 
 
 The issue with the availability zone solution is that we now force
 availability zones in Nova to be constrained to network configuration. In
 the L3 ToR/no overlay configuration, this means every rack is its own
 availability zone. This is pretty annoying for users to deal with because
 they have to choose from potentially hundreds of availability zones and it
 rules out making AZs based on other things (e.g. current phase, cooling
 systems, etc).
 
 I may be misunderstanding and you could be suggesting to not expose this
 availability zone to the end user and only make it available to the
 scheduler. However, this defeats one of the purposes of availability zones
 which is to let users select different AZs to spread their instances across
 failure domains.

No, you understood me correctly. You're right that it is problematic tying
AZs to network availability. We should introduce a new Neutron API then to
expose physnet mappings: For a given network, spit out all of the hosts
that can reach that network (Internally the Neutron server persists the physnet 
mappings
we get from agent reports). That API call will serve as a Nova filter in
case a network/port_id was requested when booting a VM. If a network/port_id
was not satisfied, another API call will be used for the inverse: Return a list
of possible networks for a given host, or the mappings between all hosts
and their networks reachability. So, for example:
neutron list-host-networks (Mappings between hosts and their networks)
neutron show-hosts-networks (Mapping between a host and its networks)
neutron show-network-hosts (Mapping between a network and what hosts can reach 
it).
neutron list-networks-hosts (Mapping between networks and their hosts).

Everything else I wrote remains the same.


 On Jul 22, 2015 2:41 PM, Assaf Muller  amul...@redhat.com  wrote:
 
 
 I added a summary of my thoughts about the enhancements I think we could
 make to the Nova scheduler in order to better support the Neutron provider
 networks use case.
 
 - Original Message -
  On Tue, Jul 21, 2015 at 1:11 PM, John Belamaric  jbelama...@infoblox.com 
  wrote:
   Wow, a lot to digest in these threads. If I can summarize my
   understanding
   of the two proposals. Let me know whether I get this right. There are a
   couple problems that need to be solved:
   
   a. Scheduling based on host reachability to the segments
   b. Floating IP functionality across the segments. I am not sure I am
   clear
   on this one but it sounds like you want the routers attached to the
   segments
   to advertise routes to the specific floating IPs. Presumably then they
   would
   do NAT or the instance would assign both the fixed IP and the floating IP
   to
   its interface?
   
   In Proposal 1, (a) is solved by associating segments to the front network
   via a router - that association is used to provide a single hook into the
   existing API that limits the scope of segment selection to those
   associated
   with the front network. (b) is solved by tying the floating IP ranges to
   the
   same front network and managing the reachability with dynamic routing.
   
   In Proposal 2, (a) is solved by tagging each network with some meta-data
   that the IPAM system uses to make a selection. This implies an IP
   allocation
   request that passes something other than a network/port to the IPAM
   subsystem. This fine from the IPAM point of view but there is no
   corresponding API for this right now. To solve (b) either the IPAM system
   has to publish the routes or the higher level management has to ALSO be
   aware of the mappings (rather than just IPAM).
  
  John, from your summary above, you seem to have the best understanding
  of the whole of what I was weakly attempting to communicate. Thank
  you for summarizing.
  
   To throw some fuel on the fire, I would argue also that (a) is not
   sufficient and address availability needs to be considered as well (as
   described in [1]). Selecting a host based on reachability alone will fail
   when addresses are exhausted. Similarly, with (b) I think there needs to
   be
   consideration during association of a floating IP to the effect on
   routing.
   That is, rather than a huge number of host routes it would be ideal to
   allocate the floating IPs in blocks that can be associated with the
   backing
   networks (though we would want to be able to split these blocks as small
   as
   a /32 if necessary - but avoid it/optimize as much as possible).
  
  Yes, address availability is a factor and must be considered in either
  case. My email was getting long already and I thought that could be
  considered separately since I believe it applies regardless of the
  outcome of this thread. But, since it seems to be an essential part
  of this conversation, let me say something about it.
  
  Ultimately, we need to match up the host scheduled by Nova to the
  addresses available to that host. We

Re: [openstack-dev] [neutron]: provider network use case supported?

[Assaf Muller]

You can mark the network as shared and have it exposed to all of your
tenants.

- Original Message -
 Hi,
 
 I'm running openstack ( IceHouse ) configured for provider networks.
 
 For a tenant i've created the network/ subnet using the below commands and
 everything works as expected.
 
 neutron net-create --tenant-id f557a3f5303d4e7c9218c5539456eb37
 --provider:physical_network=physnet2 --provider:network_type= vlan
 --provider:segmentation_id=315 ih - lwr - ci -provider-vlan315
 
 neutron subnet -create Openstack -External-vlan55 10.82.42.0/24 --name
 Openstack -External-vlan55- subnet --no-gateway --host-route destination=
 0.0.0.0/0 , nexthop =10.82.42.1 --allocation-pool
 start=10.82.42.223,end=10.82.42.254
 
 Now my questions/ use cases are:
 
 1. For a 2nd tenant, can i map it to the same subnet created for tenant
 1? If the answer is to create same net/ subnet (same segmentation_id -
 i.e vlans ) for tenant 2, how will dhcp agent avoid IP duplication.
 2. Is having multiple tenants pointing to same provider network (net/
 subnet / vlan ) is not possible what options do i have? Only to create a
 new net/ subnet based on new vlan and allocated to tenant 2?
 
 
 
 
 
 Cheers,
 
 Dani
 
 
 
 
 __
 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][L3] Representing a networks connected by routers

[Assaf Muller]

- Original Message -
 I'm looking for feedback from anyone interest but, in particular, I'd
 like feedback from the following people for varying perspectives:
 Mark McClain (proposed alternate), John Belamaric (IPAM), Ryan Tidwell
 (BGP), Neil Jerram (L3 networks), Aaron Rosen (help understand
 multi-provider networks) and you if you're reading this list of names
 and thinking he forgot me!
 
 We have been struggling to develop a way to model a network which is
 composed of disjoint L2 networks connected by routers.  The intent of
 this email is to describe the two proposals and request input on the
 two in attempt to choose a direction forward.  But, first:
 requirements.
 
 Requirements:
 
 The network should appear to end users as a single network choice.
 They should not be burdened with choosing between segments.  It might
 interest them that L2 communications may not work between instances on
 this network but that is all.  This has been requested by numerous
 operators [1][4].  It can be useful for external networks and provider
 networks.

I think that [1] and [4] are conflating the problem statement with the
proposed solutions, and lacking some lower level details regarding the
problem statement, which makes it a lot harder to engage in a discussion.

I'm looking at [4]:
What I don't see explicitly mentioned is: Does the same CIDR extend across 
racks,
or would each rack get its own CIDR(s)? I understand this can differ according 
to
the architectural choices you make in your data center, and that changes the
choices we'd need to make to Neutron in order to satisfy that requirement.

To clarify, option (1) means that a subnet is contained to a rack. Option (2)
means that a subnet may span across racks. I don't think we need to change the 
network/subnet
model at all to satisfy case (1). Each rack would have its own network/subnet
(Or perhaps multiple, if more than a single VLAN or other characteristic is 
desired).
Each network would be tagged with an AZ (This ties in nicely to the already 
proposed Neutron AZ spec),
and the Nova scheduler would become aware of Neutron network AZs. In this model
you don't want to connect to a network, you want Nova to schedule the VM and 
then have Nova choose
the network on that rack. If you want more than a single network in a rack, 
then there's
some difference between those networks that could be expressed in tags (Think: 
Network flavors),
such as the security zone. You'd then specify a tag that should be satisfied by 
the
network that the VM ends up connecting to, so that the tag may be added to the 
list
of Nova scheduler filters. Again, this goes back to keeping the Neutron network 
and subnet
just as they are but doing some work with AZs, tagging and the Nova scheduler.
We've known that the Nova scheduler must become Network aware for the past few 
years,
perhaps it's time to finally tackle that.

I can see why option (2) may require a fundamental change to how Neutron models 
networks/subnets.
I think it's essentially a different problem, and we'd have to see how we model
Neutron networks/subnets so that something like Calico would feel better. That 
being said,
if option (1) is worth pursuing, that would be a reasonable first step because 
any changes required
by option (2) are, I think, unrelated.

 
 The model needs to be flexible enough to support two distinct types of
 addresses:  1) address blocks which are statically bound to a single
 segment and 2) address blocks which are mobile across segments using
 some sort of dynamic routing capability like BGP or programmatically
 injecting routes in to the infrastructure's routers with a plugin.
 
 Overlay networks are not the answer to this.  The goal of this effort
 is to scale very large networks with many connected ports by doing L3
 routing (e.g. to the top of rack) instead of using a large continuous
 L2 fabric.  Also, the operators interested in this work do not want
 the complexity of overlay networks [4].
 
 Proposal 1:
 
 We refined this model [2] at the Neutron mid-cycle a couple of weeks
 ago.  This proposal has already resonated reasonably with operators,
 especially those from GoDaddy who attended the Neutron sprint.  Some
 key parts of this proposal are:
 
 1.  The routed super network is called a front network.  The segments
 are called back(ing) networks.
 2.  Backing networks are modeled as admin-owned private provider
 networks but otherwise are full-blown Neutron networks.
 3.  The front network is marked with a new provider type.
 4.  A Neutron router is created to link the backing networks with
 internal ports.  It represents the collective routing ability of the
 underlying infrastructure.
 5.  Backing networks are associated with a subset of hosts.
 6.  Ports created on the front network must have a host binding and
 are actually created on a backing network when all is said and done.
 They carry the ID of the backing network in the DB.
 
 Using Neutron networks to 

Re: [openstack-dev] Couldn't ping/ssh cirros instance using its floating ip

[Assaf Muller]

You will have a much better time on ask.openstack.org - It's a super
active Q site
for questions exactly like this one. You posted your question to a
developers mailing list
where we choose release names and make other ultra important mission
critical decisions.

On Mon, Nov 9, 2015 at 6:34 PM, Aishwarya Thangappa_Professional
 wrote:
> Hi there,
>
> In a fresh devstack(master branch) install,
>
> 1. I booted up a cirros instance and associated it with a floating ip.
> 2. Created a security group rule to allow tcp port 22 and associated it with
> the nova instance
> 3. From the qrouter namespace, I can ping both the private and fip address
> of the instance.
> 4. But, couldn’t ssh into the instance from the external network using its
> fip.
>
>
> neutron net-list
> +--+-+--+
> | id   | name| subnets
> |
> +--+-+--+
> | 376357b1-6abe-46c1-844b-548a051391d5 | public  |
> 41b86431-41d6-4503-8329-767f84bad4d5 172.24.4.0/24   |
> |  | |
> 79f0bf72-8c98-478b-a463-b6e3a101e6b7 2001:db8::/64   |
> | ebe713c9-5064-48ec-9094-e44e150d36ad | private |
> c7ebd45c-5a1f-4d97-a90e-b221f19c7177 10.0.0.0/24 |
> |  | |
> d7aac86f-0b2c-4dd4-88cf-246bfb58006e fd69:7a94:27b7::/64 |
> +--+-+—-+
>
> $ neutron router-list
> +--+-++-+---+
> | id   | name| external_gateway_info
> | distributed | ha|
> +--+-++-+---+
> | 46715086-3f9c-4fb1-91b4-b41da24baa2f | router1 | {"network_id":
> "376357b1-6abe-46c1-844b-548a051391d5", "enable_snat": true,
> "external_fixed_ips": [{"subnet_id": "41b86431-41d6-4503-8329-767f84bad4d5",
> "ip_address": "172.24.4.2"}, {"subnet_id":
> "79f0bf72-8c98-478b-a463-b6e3a101e6b7", "ip_address": "2001:db8::1"}]} |
> True| False |
> +--+-++-+---+
>
> $ neutron security-group-rule-list
> +--++---+---+---+-+
> | id   | security_group | direction |
> ethertype | protocol/port | remote  |
> +--++---+---+---+-+
> | 1cfb9a69-61e0-4df3-b04c-f9f9f4a54cc3 | default| egress| IPv4
> | any   | any |
> | 4afe5008-c192-4582-95c8-21b1f64ab2a5 | default| ingress   | IPv6
> | any   | default (group) |
> | 5ce1e34d-7b9d-41d8-9a15-94711824ae68 | secgroup1  | ingress   | IPv4
> | 22/tcp| any |
> | 6b3a8008-b446-4004-a72a-6ea2c9bbf375 | default| egress| IPv6
> | any   | any |
> | 7feb5969-5f9d-4525-93a3-a108db59f65b | default| egress| IPv6
> | any   | any |
> | 7ff6a82f-6c8c-4bb5-b893-d06272b0d69b | default| ingress   | IPv4
> | any   | default (group) |
> | 90f385c9-de19-4ede-b4ef-bf199537b49b | secgroup1  | egress| IPv6
> | any   | any |
> | c21ed80d-fbee-4db6-8518-60a1070aff20 | secgroup1  | egress| IPv4
> | 22/tcp| any |
> | c3d1f6ea-b7c4-47ea-ace3-f9b3b1bf8d25 | default| egress| IPv4
> | any   | any |
> | dc09a10a-37db-4a33-9abc-00798221254e | secgroup1  | egress| IPv4
> | any   | any |
> | df4d7930-6ce0-43c8-996f-ced126c7cba0 | default| ingress   | IPv4
> | any   | default (group) |
> | e0d84fea-e47c-48f6-a29b-d41231674256 | default| ingress   | IPv6
> | any   | default (group) |
> 

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

[Assaf Muller]

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

Re: [openstack-dev] [Neutron] [Tempest] where fwaas tempest tests should be?

[Assaf Muller]

On Thu, Oct 15, 2015 at 7:25 AM, Takashi Yamamoto 
wrote:

> hi,
>
> i'm looking in fwaas tempest tests and have a question about code location.
>
> currently,
>
> - fwaas api tests and its rest client are in neutron repo
> - there are no fwaas scenario tests
>
> eventually,
>
> - fwaas api tests should be moved into neutron-fwaas repo
> - fwaaa scenario tests should be in neutron-fwaas repo too.
>

I believe scenario tests that invoke APIs outside of Neutron should
stay (Or be introduced to) Tempest.


> - the rest client will be in tempest-lib
>
> is it right?
>
> __
> 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] [Tempest] where fwaas tempest tests should be?

[Assaf Muller]

On Thu, Oct 15, 2015 at 10:22 AM, Matthew Treinish <mtrein...@kortar.org>
wrote:

> On Thu, Oct 15, 2015 at 09:02:22AM -0400, Assaf Muller wrote:
> > On Thu, Oct 15, 2015 at 7:25 AM, Takashi Yamamoto <yamam...@midokura.com
> >
> > wrote:
> >
> > > hi,
> > >
> > > i'm looking in fwaas tempest tests and have a question about code
> location.
> > >
> > > currently,
> > >
> > > - fwaas api tests and its rest client are in neutron repo
> > > - there are no fwaas scenario tests
> > >
> > > eventually,
> > >
> > > - fwaas api tests should be moved into neutron-fwaas repo
> > > - fwaaa scenario tests should be in neutron-fwaas repo too.
> > >
> >
> > I believe scenario tests that invoke APIs outside of Neutron should
> > stay (Or be introduced to) Tempest.
>
> So testing the neutron advanced services was actually one of the first
> things
> we decided was out of scope for tempest. (like well over a year ago) It
> took
> some time to get equivalent testing setup elsewhere, but tests and support
> for
> the advanced services were removed from tempest on purpose.


This is for both *aaS API tests and scenario tests?


> I'd suggest that
> you look at the tempest plugin interface:
>
> http://docs.openstack.org/developer/tempest/plugin.html
>
> if you'd like to make the fwaas tests (or any other adv. service tests)
> integrate more cleanly with the rest of tempest.
>
> -Matt Treinish
>
> __
> 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][stable] proactive backporting

[Assaf Muller]

On Fri, Oct 16, 2015 at 5:32 PM, Kevin Benton  wrote:

> We can't put in code and just hope for testing later. The tests are even
> more important in back-ports because there could be unexpected differences
> in the stable branch that make the patch not work correctly.
>
> However, we do need to make sure that people aren't complaining about the
> testing methodology in the back-ports because it's too late for that.
>

I am quick to point out testing deficiencies so I hope I wasn't too tired
and unknowingly did the unspeakable that which you speak of (I think people
can fail to notice the branch the patch is submitted against). Reviewing a
backport should be 90% about backport procedures: Does the commit message
contain everything it should? Does the patch meet backport criteria? (Any
DB, RPC, configuration or API changes? Is it a new feature or a high value
/ low risk bug risk? Will this somehow break users on upgrade?) A backport
should be ideally identical to its master counterpart, so I agree that
commenting on spelling mistakes, comments, code placement, design and the
like should be avoided. If that bothers you so much, send a patch to master
to fix the grave error you spotted!


>
> On Fri, Oct 16, 2015 at 2:23 PM, Fox, Kevin M  wrote:
>
>> It would also help if the process could split out bug fixes from unit
>> tests. I had a bug fix get stuck while the unit tests were bikesheded for a
>> while, and then the delay of not getting quickly backported to the stable
>> branches then kicked in. All the while I had to patch production clouds by
>> hand with a non upstreamed fix. I'm all for having unit tests to ensure the
>> bugs don't creep back in, but regression bugs should be fixed as quickly as
>> possible.
>>
>> Thanks,
>> Kevin
>> 
>> From: Edgar Magana [edgar.mag...@workday.com]
>> Sent: Friday, October 16, 2015 2:04 PM
>> To: OpenStack Development Mailing List (not for usage questions)
>> Subject: Re: [openstack-dev] [neutron][stable] proactive backporting
>>
>> + 2 and total support for it.
>>
>> Looking forward to reviewing the first set of them.
>>
>> Edgar
>>
>>
>>
>> On 10/16/15, 5:33 AM, "Ihar Hrachyshka"  wrote:
>>
>> >Hi all,
>> >
>> >I’d like to introduce a new initiative around stable branches for
>> neutron official projects (neutron, neutron-*aas, python-neutronclient)
>> that is intended to straighten our backporting process and make us more
>> proactive in fixing bugs in stable branches. ‘Proactive' meaning: don’t
>> wait until a known bug hits a user that consumes stable branches, but
>> backport fixes in advance quickly after they hit master.
>> >
>> >The idea is simple: every Fri I walk thru the new commits merged into
>> master since last check; produce lists of bugs that are mentioned in
>> Related-Bug/Closes-Bug; paste them into:
>> >
>> >https://etherpad.openstack.org/p/stable-bug-candidates-from-master
>> >
>> >Then I click thru the bug report links to determine whether it’s worth a
>> backport and briefly classify them. If I have cycles, I also request
>> backports where it’s easy (== a mere 'Cherry-Pick to' button click).
>> >
>> >After that, those interested in maintaining neutron stable branches can
>> take those bugs one by one and handle them, which means: checking where it
>> really applies for backport; creating backport reviews (solving conflicts,
>> making tests pass). After it’s up for review for all branches affected and
>> applicable, the bug is removed from the list.
>> >
>> >I started on that path two weeks ago, doing initial swipe thru all
>> commits starting from stable/liberty spin off. If enough participants join
>> the process, we may think of going back into git history to backport
>> interesting fixes from stable/liberty into stable/kilo.
>> >
>> >Don’t hesitate to ask about details of the process, and happy
>> backporting,
>> >
>> >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
>>
>
>
>
> --
> 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
>
>
__
OpenStack Development Mailing List (not for usage 

Re: [openstack-dev] Merging DVR-HA into Liberty release

[Assaf Muller]

On Mon, Oct 5, 2015 at 2:15 PM, Korzeniewski, Artur <
artur.korzeniew...@intel.com> wrote:

> Hi Code Reviewers,
>
> I would like to ask if DVR-HA patches can be merged into Liberty release:
>
> https://bugs.launchpad.net/neutron/+bug/1365473
>
> https://review.openstack.org/#/c/196893
>
> https://review.openstack.org/#/c/143169
>
>
>
> The proper patches has been implemented, the reviews has been addressed,
> the patches are working and all found issues has been fixed.
>
>
>
> Would it be possible to merge it into Liberty release?
>

Here's the OpenStack backport policy:
https://wiki.openstack.org/wiki/StableBranch#Stable_branch_policy

The relevant part:
"Some types of changes are completely forbidden:

   - New features"


So, per our policy, the answer is sadly no.


>
>
> Regards,
>
> Artur Korzeniewski
>
> 
>
> Intel Technology Poland sp. z o.o.
>
> KRS 101882
>
> ul. Slowackiego 173, 80-298 Gdansk
>
>
>
__
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] New cycle started. What are you up to, folks?

[Assaf Muller]

On Wed, Oct 7, 2015 at 5:44 AM, Anna Kamyshnikova <
akamyshnik...@mirantis.com> wrote:

> I can' say that I have any great plans for this cycle, but I would like
> look into L3 HA (L3 HA + DVR) feature,
>

The agent side patch was merged yesterday, and the server side patch needs
reviews: https://review.openstack.org/#/c/143169/.
Your work in L3 HA land is greatly appreciated :)


> probably some bugfixes in this area and online data migration as logical
> continuation of online migration support that was done in Liberty.
>
> On Tue, Oct 6, 2015 at 8:34 PM, Ihar Hrachyshka 
> wrote:
>
>> > On 06 Oct 2015, at 19:10, Thomas Goirand  wrote:
>> >
>> > On 10/01/2015 03:45 PM, Ihar Hrachyshka wrote:
>> >> Hi all,
>> >>
>> >> I talked recently with several contributors about what each of us
>> plans for the next cycle, and found it’s quite useful to share thoughts
>> with others, because you have immediate yay/nay feedback, and maybe find
>> companions for next adventures, and what not. So I’ve decided to ask
>> everyone what you see the team and you personally doing the next cycle, for
>> fun or profit.
>> >>
>> >> That’s like a PTL nomination letter, but open to everyone! :) No
>> commitments, no deadlines, just list random ideas you have in mind or in
>> your todo lists, and we’ll all appreciate the huge pile of awesomeness no
>> one will ever have time to implement even if scheduled for Xixao release.
>> >>
>> >> To start the fun, I will share my silly ideas in the next email.
>> >>
>> >> Ihar
>> >
>> > Could we have oslo-config-generator flat neutron.conf as a release goal
>> > for Mitaka as well? The current configuration layout makes it difficult
>> > for distributions to catch-up with working by default config.
>>
>> Good idea. I think we had some patches for that. I will try to keep it on
>> my plate for M.
>>
>> 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
>>
>>
>
>
> --
> 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] [stable][neutron] How we handle Kilo backports

[Assaf Muller]

On Wed, Nov 18, 2015 at 12:38 PM, Carl Baldwin  wrote:
> On Wed, Nov 18, 2015 at 9:44 AM, Ihar Hrachyshka  wrote:
>> Hi all,
>>
>> as per [1] I imply that all projects under stable-maint-core team
>> supervision must abide the stable policy [2] which limits the types of
>> backports for N-2 branches (now it’s stable/kilo) to "Only critical bugfixes
>> and security patches”. With that, I remind all stable core members about the
>> rule.
>>
>> Since we are limited to ‘critical bugfixes’ only, and since there is no
>> clear definition of what ‘critical’ means, I guess we should define it for
>> ourselves.
>>
>> In Neutron world, we usually use Critical importance for those bugs that
>> break gate. High is used for those bugs that have high impact production
>> wise. With that in mind, I suggest we define ‘critical’ bugfixes as Critical
>> + High in LP. Comments on that?
>
> I was wondering about this today too.  Ihar is correct about how we
> use Critical importance in launchpad for Neutron bugs.  The number of
> Critical neutron bugs is very small and most of them are not relevant
> to stable releases because they are targeted at gate breakage incurred
> by new development in master.
>
> I'll +1 that we should extend this to Critical + High in launchpad.
> Otherwise, we would severely limit our ability to backport important
> bug fixes to a stable release that is only 6 months old and many
> deployers are only beginning to turn their attention to it.

+1

In many ways stable/kilo is more important than stable/liberty today.

>
>> (My understanding is that we can also advocate for the change in the global
>> policy if we think the ‘critical only’ rule should be relaxed, but till then
>> it makes sense to stick to what policy says.)
>
> +1
>
> 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] 40% failure on neutron python3.4 tests in the gate

[Assaf Muller]

On Fri, Aug 28, 2015 at 9:12 AM, Neil Jerram neil.jer...@metaswitch.com
wrote:

 On 28/08/15 13:39, Kevin Benton wrote:
  For the py34 failures, they seem to have started around the same time
  as a change was merged that adjusted the way they were ran so I
  proposed a revert for that patch
  here: https://review.openstack.org/218244
 
 

 Which leads on to https://review.openstack.org/#/c/217379/6.


Armando reported the py34 Neutron gate issues a few hours after they
started,
and I pushed that fix a few hours after that. Sadly it's taking time to get
that
through the gate.



 Which is itself failing to merge for various dvsm-functional reasons,
 including failure of test_restart_wsgi_on_sighup_multiple_workers [1].
 There's a bug for that at
 https://bugs.launchpad.net/neutron/+bug/1478190, but that doesn't show
 any activity for the last few days.

 [1]

 http://logs.openstack.org/79/217379/6/gate/gate-neutron-dsvm-functional/2991b11/testr_results.html.gz

 Regards,
 Neil



 __
 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] 40% failure on neutron python3.4 tests in the gate

[Assaf Muller]

To recap, we had three issues impacting the gate queue:

1) The neutron functional job has had a high failure rate for a while now.
Since it's impacting the gate,
I've removed it from the gate queue but kept it in the Neutron check queue:
https://review.openstack.org/#/c/218302/

If you'd like to help, the the list of bugs impacting the Neutron
functional job is linked in that patch.

2) A new Tempest scenario test was added that caused the DVR job failure
rate to sky rocket to over 50%.
It actually highlighted a legit bug with DVR and legacy routers. Kevin
proposed a patch that skips that test
entirely until we can resolve the bug in Neutron:
https://review.openstack.org/#/c/218242/ (Currently it tries to skip the
test conditionally, the next PS will skip the test entirely).

3) The Neutron py34 job has been made unstable due to a recent change (By
me, yay) that made the tests
run with multiple workers. This highlighted an issue with the Neutron unit
testing infrastructure, which is fixed here:
https://review.openstack.org/#/c/217379/

With all three patches merged we should be good to go.

On Fri, Aug 28, 2015 at 9:37 AM, Sean Dague s...@dague.net wrote:

 On 08/28/2015 09:22 AM, Assaf Muller wrote:
 
 
  On Fri, Aug 28, 2015 at 9:12 AM, Neil Jerram neil.jer...@metaswitch.com
  mailto:neil.jer...@metaswitch.com wrote:
 
  On 28/08/15 13:39, Kevin Benton wrote:
   For the py34 failures, they seem to have started around the same
 time
   as a change was merged that adjusted the way they were ran so I
   proposed a revert for that patch
   here: https://review.openstack.org/218244
  
  
 
  Which leads on to https://review.openstack.org/#/c/217379/6.
 
 
  Armando reported the py34 Neutron gate issues a few hours after they
  started,
  and I pushed that fix a few hours after that. Sadly it's taking time to
  get that
  through the gate.

 When issues like these arrise, please bring them to the infra team in
 #openstack-infra. They can promote fixes that unbreak things.

 -Sean

 --
 Sean Dague
 http://dague.net

 __
 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][networking-ovn][tempest] devstack: gate-tempest-dsvm-networking-ovn failures in Openstack CI

[Assaf Muller]

On Tue, Aug 25, 2015 at 2:15 PM, Russell Bryant rbry...@redhat.com wrote:

 On 08/25/2015 01:26 PM, Amitabha Biswas wrote:
  Russell suggested removing the MYSQL_DRIVER=MySQL-python declaration
  from local.conf https://review.openstack.org/#/c/216413/which results in
  PyMySQL as the default.
 
  With the above change the above DB errors are no longer seen in my local
  setup,

 It's great to hear that resolved the errors you saw!

   1. Is there any impact of using PyMySQL for the Jenkins check and gates.

 As Jeremy mentioned, this is what everything else is using (and what OVN
 was automatically already using in OpenStack CI).

   2. Why is the gate-networking-ovn-python27**failing (the past couple of
  commits) in {0}
 
  
 networking_ovn.tests.unit.test_ovn_plugin.TestOvnPlugin.test_create_port_security
  [0.194020s] ... FAILED. Do we need another conversation to track
 this?

 This is a separate issue.  The networking-ovn git repo has been pretty
 quiet the last few weeks and it seems something has changed that made
 our tests break.  We inherit a lot of base plugin tests from neutron, so
 it's probably some change in Neutron that we haven't synced with yet.  I
 haven't had time to dig into it yet.


This patch was recently merged to Neutron:
https://review.openstack.org/#/c/201141/

Looks like that unit test is trying to create a port with an invalid MAC
address.
I pushed a fix here:
https://review.openstack.org/#/c/216837/



 --
 Russell Bryant

 __
 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] How to run fw testcases which are recently moved from tempest to neutron.

[Assaf Muller]

I just go to the Neutron dir and use: tox -e api.

On Wed, Sep 2, 2015 at 11:37 AM, bharath  wrote:

> Hi ,
>
> How to run FW testcases which are under neutron using tempest?
>
> If i am trying to list cases from tempest(sudo -u stack -H testr
> list-tests neutron.api
> ), its resulting to empty list
>
>
>
> Thanks,
> bharath
>
> __
> 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] [nova] [neutron] [rally] Neutron or nova degradation?

[Assaf Muller]

On Thu, Sep 3, 2015 at 8:43 AM, Andrey Pavlov  wrote:

> Hello,
>
> We have rally job with fake virt driver. And we run it periodically.
> This job runs 200 servers and measures 'show' operations.
>
> On 18.08 it was run well[1]. But on 21.08 it was failed by timeout[2].
> I tried to understand what happens.
> I tried to check this job with 20 servers only[3]. It passed but I see
> that
> operations with neutron take more time now (list subnets, list network
> interfaces).
> and as result start and show instances take more time also.
>
> Maybe anyone knows what happens?
>

Looking at the merged Neutron patches between the 18th and 21st, there's a
lot of
candidates, including QoS and work around quotas.

I think the best way to find out would be to run a profiler against Neutron
from the 18th,
and Neutron from the 21st while running the Rally tests, and finding out if
the major
bottlenecks moved. Last time I profiled Neutron I used GeventProfiler:
https://pypi.python.org/pypi/GreenletProfiler

Ironically I was having issued with the profiler that comes with Eventlet.


>
>
> [1]
> http://logs.openstack.org/13/211613/6/experimental/ec2-api-rally-dsvm-fakevirt/fac263e/
> [2]
> http://logs.openstack.org/74/213074/7/experimental/ec2-api-rally-dsvm-fakevirt/91d0675/
> [3]
> http://logs.openstack.org/46/219846/1/experimental/ec2-api-rally-dsvm-fakevirt/dad98f0/
>
> --
> Kind regards,
> Andrey Pavlov.
>
> __
> 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

[Assaf Muller]

Kyle, you've really done a fantastic job during your time. The community is
now much more welcoming, and I think that working on Neutron is now much
easier. We've grown to be a very positive and constructive community and
that's not always been the case. I distinctly remember many conversations
with a wide range of people about this exact topic over the last year and a
half, all praising the changes you've been leading. Kudos.

On 11 בספט׳ 2015, at 17:13, 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] [nova][neutron][devstack] New proposed 'default' network model

[Assaf Muller]

On Tue, Sep 15, 2015 at 5:09 PM, Fox, Kevin M  wrote:

> Unfortunately, I haven't had enough chance to play with ipv6 yet.
>
> I still think ipv6 with floating ip's probably makes sense though.
>
> In ipv4, the floating ip's solve one particular problem:
>
> End Users want to be able to consume a service provided by a VM. They have
> two options:
> 1. contact the ip directly
> 2. use DNS.
>
> DNS is preferable, since humans don't remember ip's very well. IPv6 is
> much harder to remember then v4 too.
>
> DNS has its own issues, mostly, its usually not very quick to get a DNS
> entry updated.  At our site (and I'm sure, others), I'm afraid to say in
> some cases it takes as long as 24 hours to get updates to happen. Even if
> that was fixed, caching can bite you too.
>

I'm curious if you tried out Designate / DNSaaS.


>
> So, when you register a DNS record, the ip that its pointing at, kind of
> becomes a set of state. If it can't be separated from a VM its a bad thing.
> You can move it from VM to VM and your VM is not a pet. But, if your IP is
> allocated to the VM specifically, as non Floating IP's are, you run into
> problems if your VM dies and you have to replace it. If your unlucky, it
> dies, and someone else gets allocated the fixed ip, and now someone else's
> server is sitting on your DNS entry! So you are very unlikely to want to
> give up your VM, turning it into a pet.
>
> I'd expect v6 usage to have the same issues.
>
> The floating ip is great in that its an abstraction of a contactable
> address, separate from any VM it may currently be bound to.
>
> You allocate a floating ip. You can then register it with DNS, and another
> tenant can not get accidentally assigned it. You can move it from vm to vm
> until your done with it. You can Unregister it from DNS, and then it is
> safe to return to others to use.
>
> To me, the NAT aspect of it is a secondary thing. Its primary importance
> is in enabling things to be more cattleish and helping with dns security.
>
> Thanks,
> Kevin
>
>
>
>
>
>
> 
> From: Clark Boylan [cboy...@sapwetik.org]
> Sent: Tuesday, September 15, 2015 1:06 PM
> To: openstack-dev@lists.openstack.org
> Subject: Re: [openstack-dev] [nova][neutron][devstack] New proposed
> 'default' network model
>
> On Tue, Sep 15, 2015, at 11:00 AM, Fox, Kevin M wrote:
> > We run several clouds where there are multiple external networks. the
> > "just run it in on THE public network" doesn't work. :/
> Maybe this would be better expressed as "just run it on an existing
> public network" then?
> >
> > I also strongly recommend to users to put vms on a private network and
> > use floating ip's/load balancers. For many reasons. Such as, if you
> > don't, the ip that gets assigned to the vm helps it become a pet. you
> > can't replace the vm and get the same IP. Floating IP's and load
> > balancers can help prevent pets. It also prevents security issues with
> > DNS and IP's. Also, for every floating ip/lb I have, I usually have 3x or
> > more the number of instances that are on the private network. Sure its
> > easy to put everything on the public network, but it provides much better
> > security if you only put what you must on the public network. Consider
> > the internet. would you want to expose every device in your house
> > directly on the internet? No. you put them in a private network and poke
> > holes just for the stuff that does. we should be encouraging good
> > security practices. If we encourage bad ones, then it will bite us later
> > when OpenStack gets a reputation for being associated with compromises.
> There are a few issues with this. Neutron IPv6 does not support floating
> IPs. So now you have to use two completely different concepts for
> networking on a single dual stacked VM. IPv4 goes on a private network
> and you attach a floating IP. IPv6 is publicly routable. If security and
> DNS and not making pets were really the driving force behind floating
> IPs we would see IPv6 support them too. These aren't the reasons
> floating IPs exist, they exist because we are running out of IPv4
> addresses and NAT is everyones preferred solution to that problem. But
> that doesn't make it a good default for a cloud; use them if you are
> affected by an IP shortage.
>
> Nothing prevents you from load balancing against public IPs to address
> the DNS and firewall rule concerns (basically don't make pets). This
> works great and is how OpenStack's git mirrors work.
>
> It is also easy to firewall public IPs using Neutron via security groups
> (and possibly the firewall service? I have never used it and don't
> know). All this to say I think it is reasonable to use public shared
> networks by default particularly since IPv6 does not have any concept of
> a floating IP in Neutron so using them is just odd unless you really
> really need them and you aren't actually any less secure.
>
> Not to get too off topic, but I would 

Re: [openstack-dev] [dragonflow] Low OVS version for Ubuntu

[Assaf Muller]

Another issue is that the gate is running with Ubuntu 14.04, which is
running OVS 2.0. This means we can't test
certain features in Neutron (For example, the OVS ARP responder).

On Thu, Sep 17, 2015 at 4:17 AM, Gal Sagie  wrote:

> Hello Li Ma,
>
> Dragonflow uses OpenFlow1.3 to communicate with OVS and thats why we need
> OVS 2.3.1.
> As suggested you can build it from source.
> For Fedora 21 OVS2.3.1 is part of the default yum repository.
>
> You can ping me on IRC (gsagie at freenode) if you need any additional
> help how
> to compile OVS.
>
> Thanks
> Gal.
>
> On Thu, Sep 17, 2015 at 10:24 AM, Sudipto Biswas <
> sbisw...@linux.vnet.ibm.com> wrote:
>
>>
>>
>> On Thursday 17 September 2015 12:22 PM, Li Ma wrote:
>>
>>> Hi all,
>>>
>>> I tried to run devstack to deploy dragonflow, but I failed with lower
>>> OVS version.
>>>
>>> I used Ubuntu 14.10 server, but the official package of OVS is 2.1.3
>>> which is much lower than the required version 2.3.1+?
>>>
>>> So, can anyone provide a Ubuntu repository that contains the correct
>>> OVS packages?
>>>
>>
>> Why don't you just build the OVS you want from here:
>> http://openvswitch.org/download/
>>
>> 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
>>
>
>
>
> --
> Best Regards ,
>
> The G.
>
> __
> 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] [magnum] Associating patches with bugs/bps (Please don't hurt me)

[Assaf Muller]

On Thu, Sep 17, 2015 at 4:09 PM, Jeff Peeler  wrote:

>
> On Thu, Sep 17, 2015 at 3:28 PM, Fox, Kevin M  wrote:
>
>> I agree. Lots of projects have this issue. I submitted a bug fix once
>> that literally was 3 characters long, and it took:
>> A short commit message, a long commit message, and a full bug report
>> being filed and cross linked. The amount of time writing it up was orders
>> of magnitude longer then the actual fix.
>>
>> Seems a bit much...
>>
>> Looking at this review, I'd go a step farther and argue that code
>> cleanups like this one should be really really easy to get through. No one
>> likes to do them, so we should be encouraging folks that actually do it.
>> Not pile up roadblocks.
>
>
> It is indeed frustrating. I've had a few similar reviews (in other
> projects - hopefully it's okay I comment here) as well. Honestly, I think
> if a given team is willing to draw the line as for what is permissible to
> commit without bug creation, then they should be permitted that freedom.
>
> However, that said, I'm sure somebody is going to point out that come
> release time having the list of bugs fixed in a given release is handy,
> spelling errors included.
>

We've had the same debate in Neutron and we relaxed the rules. We don't
require bugs for trivial changes. In fact, my argument has always been:
Come release
time, when we say that the Neutron community fixed so and so bugs, we would
be lying if we were to include fixing spelling issues in comments. That's
not a bug.


>
> __
> 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] [all] -1 due to line length violation in commit messages

[Assaf Muller]

On Mon, Sep 28, 2015 at 12:40 PM, Zane Bitter  wrote:

> On 28/09/15 05:47, Gorka Eguileor wrote:
>
>> On 26/09, Morgan Fainberg wrote:
>>
>>> As a core (and former PTL) I just ignored commit message -1s unless
>>> there is something majorly wrong (no bug id where one is needed, etc).
>>>
>>> I appreciate well formatted commits, but can we let this one go? This
>>> discussion is so far into the meta-bike-shedding (bike shedding about bike
>>> shedding commit messages) ... If a commit message is *that* bad a -1 (or
>>> just fixing it?) Might be worth it. However, if a commit isn't missing key
>>> info (bug id? Bp? Etc) and isn't one long incredibly unbroken sentence
>>> moving from topic to topic, there isn't a good reason to block the review.
>>>
>>
> +1
>
> It is not worth having a bot -1 bad commits or even having gerrit muck
>>> with them. Let's do the job of the reviewer and actually review code
>>> instead of going crazy with commit messages.
>>>
>>
> +1
>
> Sent via mobile
>>>
>>>
>> I have to disagree, as reviewers we have to make sure that guidelines
>> are followed, if we have an explicit guideline that states that
>> the limit length is 72 chars, I will -1 any patch that doesn't follow
>> the guideline, just as I would do with i18n guideline violations.
>>
>
> Apparently you're unaware of the definition of the word 'guideline'. It's
> a guide. If it were a hard-and-fast rule then we would have a bot enforcing
> it already.
>
> Is there anything quite so frightening as a large group of people blindly
> enforcing rules with total indifference to any sense of overarching purpose?
>
> A reminder that the reason for this guideline is to ensure that none of
> the broad variety of tools that are available in the Git ecosystem
> effectively become unusable with the OpenStack repos due to wildly
> inconsistent formatting. And of course, even that goal has to be balanced
> against our other goals, such as building a healthy community and
> occasionally shipping some software.
>
> There are plenty of ways to achieve that goal other than blanket drive-by
> -1's for trivial inconsistencies in the formatting of individual commit
> messages.


The actual issue is that we as a community (Speaking of the Neutron
community at least) are stat-crazed. We have a fair number of contributors
that -1 for trivial issues to retain their precious stats with alarming
zeal. That is the real issue. All of these commit message issues,
translation mishaps,
comment typos etc are excuses for people to boost their stats without
contributing their time or energy in to the project. I am beyond bitter
about this
issue at this point.

I'll say what I've always said about this issue: The review process is
about collaboration. I imagine that the author is sitting next to me, and
we're going
through the patch together for the purpose of improving it. Review comments
should be motivated by a thirst to improve the proposed code in a real way,
not by your want or need to improve your stats on stackalytics. The latter
is an enormous waste of your time.


> A polite comment and a link to the guidelines is a great way to educate
> new contributors. For core reviewers especially, a comment like that and a
> +1 review will *almost always* get you the change you want in double-quick
> time. (Any contributor who knows they are 30s work away from a +2 is going
> to be highly motivated.)
>
> Typos are a completely different matter and they should not be grouped
>> together with guideline infringements.
>>
>
> "Violations"? "Infringements"? It's line wrapping, not a felony case.
>
> I agree that it is a waste of time and resources when you have to -1 a
>> patch for this, but there multiple solutions, you can make sure your
>> editor does auto wrapping at the right length (I have mine configured
>> this way), or create a git-enforce policy with a client-side hook, or do
>> like Ihar is trying to do and push for a guideline change.
>>
>> I don't mind changing the guideline to any other length, but as long as
>> it is 72 chars I will keep enforcing it, as it is not the place of
>> reviewers to decide which guidelines are worthy of being enforced and
>> which ones are not.
>>
>
> Of course it is.
>
> If we're not here to use our brains, why are we here? Serious question.
> Feel free to use any definition of 'here'.
>
> Cheers,
>> Gorka.
>>
>>
>>
>> On Sep 26, 2015, at 21:19, Ian Wells  wrote:

 Can I ask a different question - could we reject a few simple-to-check
 things on the push, like bad commit messages?  For things that take 2
 seconds to fix and do make people's lives better, it's not that they're
 rejected, it's that the whole rejection cycle via gerrit review (push/wait
 for tests to run/check website/swear/find change/fix/push again) is out of
 proportion to the effort taken to fix it.

>>>
> I would welcome a confirmation step - but *not* an outright rejection -
> 

Re: [openstack-dev] Openvswitch agent unit tests

[Assaf Muller]

On Tue, Sep 29, 2015 at 5:00 PM, Sławek Kapłoński <sla...@kaplonski.pl>
wrote:

> Hello,
>
> Thx for Your tips. So I should focus more on write new functional tests
> for ovs agent if there are missing some rather then doing unit tests for
> it?
>

If a method is conceivably testable with unit tests (Without over relying
on mock), that is preferable.
Failing that, functional tests are the way to go. The general idea is to
test bottom up: Lots of unit
tests, fewer functional tests, fewer API/integration/fullstack tests, and
even fewer Tempest scenario
tests. In the case of the OVS agent (And other Neutron agents that interact
with the underlying hypervisor)
it is difficult to test the agent with unit tests effectively, which is why
I encourage developers to test
via functional, mock-less tests, like the tests I linked you in my previous
email.


>
> --
> Best regards / Pozdrawiam
> Sławek Kapłoński
> sla...@kaplonski.pl
>
> On Mon, 28 Sep 2015, Assaf Muller wrote:
>
> > Generally speaking, testing agent methods that interact with the system
> > heavily with unit tests provide very little,
> > and arguably negative value to the project. Mocking internal methods and
> > asserting that they were called is a
> > clear anti-pattern to my mind. In Neutron-land we prefer to test agent
> code
> > with functional tests.
> > Since 'functional tests' is a very over-loaded term, what I mean by that
> is
> > specifically running the actual unmocked
> > code on the system and asserting the expected behavior.
> >
> > Check out:
> > neutron/tests/functional/agent/test_ovs_lib
> > neutron/tests/functional/agent/test_l2_ovs_agent
> >
> > On Mon, Sep 28, 2015 at 3:45 PM, Sławek Kapłoński <sla...@kaplonski.pl>
> > wrote:
> >
> > > Hello,
> > >
> > > I'm new developer who want to start contributing to neutron. I have
> some
> > > small experience with neutron already but I didn't do anything which I
> > > could push to upstream for now. So I searched for some bug on launchpad
> > > and I found such bug which I took:
> > > https://bugs.launchpad.net/neutron/+bug/1285893 and I started to
> > > checking how I can write new tests (I think that it is quite easy job
> to
> > > do for the beginning but maybe I'm wrong).
> > > Now I have some questions to You:
> > > 1. From test-coverage I can see that for example there is missing
> > > coverage like in lines 349-350 in method _restore_local_vlan_map(self)
> -
> > > should
> > > I create new test and call that metod to check if proper exception will
> > > be raised? or maybe it is not neccessary at all and such "one lines"
> > > missing coverage is not really needed to be checked? Or maybe it should
> > > be done in some different way?
> > >
> > > 2. What about tests for methods like: "_local_vlan_for_flat" which is
> > > not checked at all? should be created new test for such method? or
> maybe
> > > it should be covered by some different test?
> > >
> > > Thanks in advance for any advice and tips how to write such unit tests
> > > properly :)
> > >
> > > --
> > > Best regards / Pozdrawiam
> > > Sławek Kapłoński
> > > sla...@kaplonski.pl
> > >
> > >
> > >
> __
> > > 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] [all] -1 due to line length violation in commit messages

[Assaf Muller]

On Mon, Sep 28, 2015 at 5:29 PM, Kevin Benton <blak...@gmail.com> wrote:

> I think a blanket statement about what people's motivations are is not
> fair. We've seen in this thread that some people want to enforce the limit
> of 72 chars and it's not about padding their stats.
>

I took this golden opportunity to kidnap the thread and invoke a general
rant, it's not specific to the 72 characters git commit title discussion.


>
> The issue here is that we have a guideline with a very specific number. If
> we don't care to enforce it, why do we even bother? "Please do this, unless
> you don't feel like it", is going to be hard for many people to review in a
> way that pleases everyone.
>
> On Mon, Sep 28, 2015 at 11:00 PM, Assaf Muller <amul...@redhat.com> wrote:
>
>>
>>
>> On Mon, Sep 28, 2015 at 12:40 PM, Zane Bitter <zbit...@redhat.com> wrote:
>>
>>> On 28/09/15 05:47, Gorka Eguileor wrote:
>>>
>>>> On 26/09, Morgan Fainberg wrote:
>>>>
>>>>> As a core (and former PTL) I just ignored commit message -1s unless
>>>>> there is something majorly wrong (no bug id where one is needed, etc).
>>>>>
>>>>> I appreciate well formatted commits, but can we let this one go? This
>>>>> discussion is so far into the meta-bike-shedding (bike shedding about bike
>>>>> shedding commit messages) ... If a commit message is *that* bad a -1 (or
>>>>> just fixing it?) Might be worth it. However, if a commit isn't missing key
>>>>> info (bug id? Bp? Etc) and isn't one long incredibly unbroken sentence
>>>>> moving from topic to topic, there isn't a good reason to block the review.
>>>>>
>>>>
>>> +1
>>>
>>> It is not worth having a bot -1 bad commits or even having gerrit muck
>>>>> with them. Let's do the job of the reviewer and actually review code
>>>>> instead of going crazy with commit messages.
>>>>>
>>>>
>>> +1
>>>
>>> Sent via mobile
>>>>>
>>>>>
>>>> I have to disagree, as reviewers we have to make sure that guidelines
>>>> are followed, if we have an explicit guideline that states that
>>>> the limit length is 72 chars, I will -1 any patch that doesn't follow
>>>> the guideline, just as I would do with i18n guideline violations.
>>>>
>>>
>>> Apparently you're unaware of the definition of the word 'guideline'.
>>> It's a guide. If it were a hard-and-fast rule then we would have a bot
>>> enforcing it already.
>>>
>>> Is there anything quite so frightening as a large group of people
>>> blindly enforcing rules with total indifference to any sense of overarching
>>> purpose?
>>>
>>> A reminder that the reason for this guideline is to ensure that none of
>>> the broad variety of tools that are available in the Git ecosystem
>>> effectively become unusable with the OpenStack repos due to wildly
>>> inconsistent formatting. And of course, even that goal has to be balanced
>>> against our other goals, such as building a healthy community and
>>> occasionally shipping some software.
>>>
>>> There are plenty of ways to achieve that goal other than blanket
>>> drive-by -1's for trivial inconsistencies in the formatting of individual
>>> commit messages.
>>
>>
>> The actual issue is that we as a community (Speaking of the Neutron
>> community at least) are stat-crazed. We have a fair number of contributors
>> that -1 for trivial issues to retain their precious stats with alarming
>> zeal. That is the real issue. All of these commit message issues,
>> translation mishaps,
>> comment typos etc are excuses for people to boost their stats without
>> contributing their time or energy in to the project. I am beyond bitter
>> about this
>> issue at this point.
>>
>> I'll say what I've always said about this issue: The review process is
>> about collaboration. I imagine that the author is sitting next to me, and
>> we're going
>> through the patch together for the purpose of improving it. Review
>> comments should be motivated by a thirst to improve the proposed code in a
>> real way,
>> not by your want or need to improve your stats on stackalytics. The
>> latter is an enormous waste of your time.
>>
>>
>>> A polite comment and a link to the guidelines is a great way to educate
>>> new contributors. For core reviewers especially, a comm

Re: [openstack-dev] Openvswitch agent unit tests

[Assaf Muller]

Generally speaking, testing agent methods that interact with the system
heavily with unit tests provide very little,
and arguably negative value to the project. Mocking internal methods and
asserting that they were called is a
clear anti-pattern to my mind. In Neutron-land we prefer to test agent code
with functional tests.
Since 'functional tests' is a very over-loaded term, what I mean by that is
specifically running the actual unmocked
code on the system and asserting the expected behavior.

Check out:
neutron/tests/functional/agent/test_ovs_lib
neutron/tests/functional/agent/test_l2_ovs_agent

On Mon, Sep 28, 2015 at 3:45 PM, Sławek Kapłoński 
wrote:

> Hello,
>
> I'm new developer who want to start contributing to neutron. I have some
> small experience with neutron already but I didn't do anything which I
> could push to upstream for now. So I searched for some bug on launchpad
> and I found such bug which I took:
> https://bugs.launchpad.net/neutron/+bug/1285893 and I started to
> checking how I can write new tests (I think that it is quite easy job to
> do for the beginning but maybe I'm wrong).
> Now I have some questions to You:
> 1. From test-coverage I can see that for example there is missing
> coverage like in lines 349-350 in method _restore_local_vlan_map(self) -
> should
> I create new test and call that metod to check if proper exception will
> be raised? or maybe it is not neccessary at all and such "one lines"
> missing coverage is not really needed to be checked? Or maybe it should
> be done in some different way?
>
> 2. What about tests for methods like: "_local_vlan_for_flat" which is
> not checked at all? should be created new test for such method? or maybe
> it should be covered by some different test?
>
> Thanks in advance for any advice and tips how to write such unit tests
> properly :)
>
> --
> Best regards / Pozdrawiam
> Sławek Kapłoński
> sla...@kaplonski.pl
>
>
> __
> 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] 40% failure on neutron python3.4 tests in the gate

[Assaf Muller]

On Fri, Aug 28, 2015 at 1:50 PM, Salvatore Orlando salv.orla...@gmail.com
wrote:



 On 28 August 2015 at 16:57, Sean Dague s...@dague.net wrote:

 On 08/28/2015 11:20 AM, Assaf Muller wrote:
  To recap, we had three issues impacting the gate queue:
 
  1) The neutron functional job has had a high failure rate for a while
  now. Since it's impacting the gate,
  I've removed it from the gate queue but kept it in the Neutron check
 queue:
  https://review.openstack.org/#/c/218302/
 
  If you'd like to help, the the list of bugs impacting the Neutron
  functional job is linked in that patch.
 
  2) A new Tempest scenario test was added that caused the DVR job failure
  rate to sky rocket to over 50%.
  It actually highlighted a legit bug with DVR and legacy routers. Kevin
  proposed a patch that skips that test
  entirely until we can resolve the bug in Neutron:
  https://review.openstack.org/#/c/218242/ (Currently it tries to skip
 the
  test conditionally, the next PS will skip the test entirely).
 
  3) The Neutron py34 job has been made unstable due to a recent change
  (By me, yay) that made the tests
  run with multiple workers. This highlighted an issue with the Neutron
  unit testing infrastructure, which is fixed here:
  https://review.openstack.org/#/c/217379/
 
  With all three patches merged we should be good to go.

 Well, with all 3 of these we should be much better for sure. There are
 probably additional issues causing intermittent failures which should be
 looked at. These 3 are definitely masking anything else.


 Sadly, since the issues are independent, it is very likely for one of the
 patch to fail jenkins tests for one of the other two issues.
 If the situation persists is it crazy to conside switching neutron-py34
 and neutron-functional to non-voting until these patches merge.
 Neutron cores might abstain from approving patches (unless trivial or
 documentation) while these jobs are non-voting.


We have two of the three merged. The Neutron functional tests are no longer
part of the gate queue, only the check queue,
and the Tempest router_reschedule test will no longer fail as part of the
DVR job. This means that the py34 patch now has
a better chance of going in.





 https://etherpad.openstack.org/p/gate-fire-2015-08-28 is a set of
 patches to promote for things causing races in the gate (we've got a
 cinder one was well). If other issues are known with fixes posted,
 please feel free to add them with comments.





 -Sean

 --
 Sean Dague
 http://dague.net

 __
 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] DVR + L3 HA + L2pop - Mapping out the work

[Assaf Muller]

There's a patch up for review to integrate DVR and L3 HA:
https://review.openstack.org/#/c/143169/

Let me outline all of the work that has to happen before that patch
would be useful:

In order for DVR + L3 HA to work in harmony, each feature would have
to be stable on its own. DVR has its share of problems, and this is
being tackled full on, with more folks joining the good fight soon. L3
HA also has its own problems:

* https://review.openstack.org/#/c/238122/
* https://review.openstack.org/#/c/230481/
* https://review.openstack.org/#/c/250040/

DVR requires l2pop, and l2pop on its own is also problematic
(Regardless if DVR or L3 HA is turned on). One notable issue is that
it screws up live migration:
https://bugs.launchpad.net/neutron/+bug/1443421.
I'd really like to see more focus on Vivek's patch that attempts to
resolve this issue:
https://review.openstack.org/#/c/175383/

Finally the way L3 HA integrates with l2pop is not something I would
recommend in production, as described here:
https://bugs.launchpad.net/neutron/+bug/1522980. If I cannot find an
owner for this work I will reach out to some folks soon.

__
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][QA] New testing guidelines

[Assaf Muller]

Today we merged [1] which adds content to the Neutron testing guidelines:
http://docs.openstack.org/developer/neutron/devref/development.environment.html#testing-neutron

The document details Neutron's different testing infrastructures:
* Unit
* Functional
* Fullstack (Integration testing with services deployed by the testing
infra itself)
* In-tree Tempest

The new documentation provides:
* Examples
* Do's and don'ts
* Good and bad usage of mock
* The anatomy of a good unit test

And primarily the advantages and use cases for each testing framework.

It's short - I encourage developers to go through it. Reviewers may
use it as reference / link when testing anti-pattern pop up.

Please send feedback on this thread or better yet in the form of a
devref patch. Thank you!


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

__
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][QA] New testing guidelines

[Assaf Muller]

On Wed, Dec 16, 2015 at 2:32 PM, Boris Pavlovic <bo...@pavlovic.me> wrote:
> Assaf,
>
> We can as well add Rally testing for scale/performance/regression testing.

There's mention of it in the doc but not the rationale of using it like for the
other testing frameworks. I'd appreciate it if a Rally dev could send the patch
and add me as a reviewer.

>
> Best regards,
> Boris Pavlovic
>
> On Wed, Dec 16, 2015 at 7:00 AM, Fawad Khaliq <fa...@plumgrid.com> wrote:
>>
>> Very useful information. Thanks, Assaf.
>>
>> Fawad Khaliq
>>
>>
>> On Thu, Dec 10, 2015 at 6:26 AM, Assaf Muller <amul...@redhat.com> wrote:
>>>
>>> Today we merged [1] which adds content to the Neutron testing guidelines:
>>>
>>> http://docs.openstack.org/developer/neutron/devref/development.environment.html#testing-neutron
>>>
>>> The document details Neutron's different testing infrastructures:
>>> * Unit
>>> * Functional
>>> * Fullstack (Integration testing with services deployed by the testing
>>> infra itself)
>>> * In-tree Tempest
>>>
>>> The new documentation provides:
>>> * Examples
>>> * Do's and don'ts
>>> * Good and bad usage of mock
>>> * The anatomy of a good unit test
>>>
>>> And primarily the advantages and use cases for each testing framework.
>>>
>>> It's short - I encourage developers to go through it. Reviewers may
>>> use it as reference / link when testing anti-pattern pop up.
>>>
>>> Please send feedback on this thread or better yet in the form of a
>>> devref patch. Thank you!
>>>
>>>
>>> [1] https://review.openstack.org/#/c/245984/
>>>
>>>
>>> __
>>> 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 metadata-agent HA

[Assaf Muller]

The L3 agent monitors the metadata proxies it spawns and restarts them
automatically. You should be using an external tool to restart the
metadata *agent* in case that crashes.

On Sun, Dec 13, 2015 at 7:49 AM, Gary Kotton <gkot...@vmware.com> wrote:
>
>
> From: Eugene Nikanorov <enikano...@mirantis.com>
> Reply-To: OpenStack List <openstack-dev@lists.openstack.org>
> Date: Sunday, December 13, 2015 at 12:09 PM
> To: OpenStack List <openstack-dev@lists.openstack.org>
> Subject: Re: [openstack-dev] neutron metadata-agent HA
>
> It is as 'single' as active L3 router that is handling traffic at current
> point of time.
>
> [Gary] But if the l3 agent is up and running and the metadataproxy is not
> then all of the instances using that agent will not be able to get their
> metadata.
>
> On Sun, Dec 13, 2015 at 11:13 AM, Gary Kotton <gkot...@vmware.com> wrote:
>>
>>
>>
>>
>>
>>
>> On 12/12/15, 10:44 PM, "Assaf Muller" <amul...@redhat.com> wrote:
>>
>> >The neutron metadata agent is stateless. It takes requests from the
>> >metadata proxies running in the router namespaces and moves the
>> >requests on to the nova server. If you're using HA routers, start the
>> >neutron-metadata-agent on every machine the L3 agent runs, and just
>> >make sure that the metadata-agent is restarted in case it crashes and
>> >you're done.
>>
>> So does this mean that it could be the single point of failure?
>>
>> >Nothing else you need to do.
>> >
>> >On Fri, Dec 11, 2015 at 3:24 PM, Fabrizio Soppelsa
>> ><fsoppe...@mirantis.com> wrote:
>> >>
>> >> On Dec 10, 2015, at 12:56 AM, Alvise Dorigo <alvise.dor...@pd.infn.it>
>> >> wrote:
>> >>
>> >> So my question is: is there any progress on this topic ? is there a way
>> >> (something like a cronjob script) to make the metadata-agent redundant
>> >> without involving the clustering software Pacemaker/Corosync ?
>> >>
>> >>
>> >> Reason for such a dirty solution instead of rely onto pacemaker?
>> >>
>> >> I’m not aware of such initiatives - just checked the blueprints in
>> >> Neutron
>> >> and I found no relevant. I can suggest to file a proposal to the
>> >> correspondent launchpad page, by elaborating your idea.
>> >>
>> >> F.
>> >>
>> >>
>> >> __
>> >> 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

Re: [openstack-dev] neutron metadata-agent HA

[Assaf Muller]

The neutron metadata agent is stateless. It takes requests from the
metadata proxies running in the router namespaces and moves the
requests on to the nova server. If you're using HA routers, start the
neutron-metadata-agent on every machine the L3 agent runs, and just
make sure that the metadata-agent is restarted in case it crashes and
you're done. Nothing else you need to do.

On Fri, Dec 11, 2015 at 3:24 PM, Fabrizio Soppelsa
 wrote:
>
> On Dec 10, 2015, at 12:56 AM, Alvise Dorigo 
> wrote:
>
> So my question is: is there any progress on this topic ? is there a way
> (something like a cronjob script) to make the metadata-agent redundant
> without involving the clustering software Pacemaker/Corosync ?
>
>
> Reason for such a dirty solution instead of rely onto pacemaker?
>
> I’m not aware of such initiatives - just checked the blueprints in Neutron
> and I found no relevant. I can suggest to file a proposal to the
> correspondent launchpad page, by elaborating your idea.
>
> F.
>
> __
> 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