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

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

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

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

Re: [openstack-dev] Validation of IP

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

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

- 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

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

, 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

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

- 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

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

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

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

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

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

+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

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

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

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

- 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

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

- 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

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

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

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

(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

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

- 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

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

- 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

Re: [openstack-dev] q-agt error

- 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

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

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

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

://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

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

- 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

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

- 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

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

- 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

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

- 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

Re: [openstack-dev] contribute

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

Re: [openstack-dev] Request for comments for a possible solution

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

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

- 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

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

- 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

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

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

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

- 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

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

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

Re: [openstack-dev] [neutron] How neutron calculate routing path

- 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

Re: [openstack-dev] [neutron] Neutron agent internal data structures

- 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

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

), 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

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

- 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

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

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

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

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

Re: [openstack-dev] [Neutron] VLAN trunking network for NFV

- 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

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

- 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

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

- 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

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

-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

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

- 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

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

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

Re: [openstack-dev] [neutron][L3] IPAM alternate refactoring

- 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

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

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,

Re: [openstack-dev] [neutron] replace external ip monitor

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

Re: [openstack-dev] [Nova][Neutron] Linuxbridge as the default in DevStack [was: Status of the nova-network to Neutron migration work]

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

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

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

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

- 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

Re: [openstack-dev] [neutron] Proposing Assaf Muller for the Neutron Core Reviewer Team

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

Re: [openstack-dev] Interconnecting projects

, 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

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

- 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

Re: [openstack-dev] Proposing Brian Haley to Neutron L3 Core Reviewer Team

+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

Re: [openstack-dev] [Neutron] Proposing Rossella Sblendido for the Control Plane core team

+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

Re: [openstack-dev] [Networking] Support for multiple gateways in neutron/nova-net subnets for provider networks

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

Re: [openstack-dev] Interconnecting projects

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

Re: [openstack-dev] [Neutron] - breaking changes for plugins/drivers

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

Re: [openstack-dev] [neutron] - Proposing Miguel Angel Ajo for the Control Plane core team

+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

Re: [openstack-dev] [Neutron] Proposing YAMAMOTO Takashi for the Control Plane core team

+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

Re: [openstack-dev] Why need br-int and br-tun in openstack neutron

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

Re: [openstack-dev] Why need br-int and br-tun in openstack neutron

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

Re: [openstack-dev] Why need br-int and br-tun in openstack neutron

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

Re: [openstack-dev] [Neutron] binding information for networks

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

Re: [openstack-dev] [Neutron] Etherpad from the Ops Meetup

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

Re: [openstack-dev] [neutron] Expected cli behavior when ovs-agent is down

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

Re: [openstack-dev] [neutron][dvr][ha] DVR-HA router is not working.

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

Re: [openstack-dev] how to debug neutron using eclipse pydev?

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.

Re: [openstack-dev] [Neutron][L3] Representing a networks connected by routers

- 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

Re: [openstack-dev] how to debug neutron using eclipse pydev?

+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

Re: [openstack-dev] [Neutron][L3] Representing a networks connected by routers

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

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

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

Re: [openstack-dev] [Neutron][L3] Representing a networks connected by routers

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

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

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.

Re: [openstack-dev] [Neutron][L3] Representing a networks connected by routers

- 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

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

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,

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

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

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

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,

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

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, &

Re: [openstack-dev] [neutron][stable] proactive backporting

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

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

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

Re: [openstack-dev] [neutron] New cycle started. What are you up to, folks?

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:

Re: [openstack-dev] [stable][neutron] How we handle Kilo backports

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

Re: [openstack-dev] [neutron] 40% failure on neutron python3.4 tests in the gate

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

Re: [openstack-dev] [neutron] 40% failure on neutron python3.4 tests in the gate

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

Re: [openstack-dev] [neutron][networking-ovn][tempest] devstack: gate-tempest-dsvm-networking-ovn failures in Openstack CI

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.

Re: [openstack-dev] How to run fw testcases which are recently moved from tempest to neutron.

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

Re: [openstack-dev] [nova] [neutron] [rally] Neutron or nova degradation?

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

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

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

Re: [openstack-dev] [nova][neutron][devstack] New proposed 'default' network model

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

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

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

Re: [openstack-dev] [magnum] Associating patches with bugs/bps (Please don't hurt me)

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

Re: [openstack-dev] [all] -1 due to line length violation in commit messages

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

Re: [openstack-dev] Openvswitch agent unit tests

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

Re: [openstack-dev] [all] -1 due to line length violation in commit messages

ease 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

Re: [openstack-dev] Openvswitch agent unit tests

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

Re: [openstack-dev] [neutron] 40% failure on neutron python3.4 tests in the gate

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

[openstack-dev] [Neutron] DVR + L3 HA + L2pop - Mapping out the work

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

[openstack-dev] [Neutron][QA] New testing guidelines

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

Re: [openstack-dev] [Neutron][QA] New testing guidelines

e 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

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

M, 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 >> >meta

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

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

  1   2   >