Re: [openstack-dev] [Openstack] Plugin Blueprint and ML2 Plugin
Hi Naveen: The sooner you submit your blueprint the better, as Neutron core devs can comment on it and help answer questions for you. You can implement an ML2 MechanismDriver or a monolithic plugin, but if you file the BP we can help you decide which may be better for your environment. Keep in mind there are new 3rd party requirements in neutron for plugins now [1], the key one being external Tempest testing. Thanks, Kyle [1] http://lists.openstack.org/pipermail/openstack-dev/2013-November/019219.html On Dec 3, 2013, at 9:50 AM, John Smith lbalba...@gmail.com wrote: Hi, Im not sure, but this may be more appropriate for the developers mailing list: openstack-dev@lists.openstack.org Regards, John Smith On Tue, Dec 3, 2013 at 3:36 PM, NAVEEN R K REDDY naveen.kunare...@gmail.com wrote: Hi All, I have couple of questions wrt to plugin blueprint and ml2 plugin, 1. We are planning to submit the plugin into Openstack Icehouse release. The question we have is there any deadline for the plugin blueprint submission ? 2. Is there anything like mandatory for everyone need to implement ML2 plugin instead of monolithic plugin ? Thanks in advance. Regards, Naveen. ___ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openst...@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack ___ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openst...@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Plugin Blueprint and ML2 Plugin
On Dec 3, 2013, at 10:13 AM, NAVEEN R K REDDY naveen.kunare...@gmail.com wrote: Hi All, I have couple of questions wrt to plugin blueprint and ml2 plugin, 1. We are planning to submit the plugin into Openstack Icehouse release. The question we have is there any deadline for the plugin blueprint submission ? 2. Is there anything like mandatory for everyone need to implement ML2 plugin instead of monolithic plugin ? Thanks in advance. Hi Naveen: Here is my reply on the other thread, copied here in case people want to continue the discussion on this thread: The sooner you submit your blueprint the better, as Neutron core devs can comment on it and help answer questions for you. You can implement an ML2 MechanismDriver or a monolithic plugin, but if you file the BP we can help you decide which may be better for your environment. Keep in mind there are new 3rd party requirements in neutron for plugins now [1], the key one being external Tempest testing. Thanks, Kyle [1] http://lists.openstack.org/pipermail/openstack-dev/2013-November/019219.html On Dec 3, 2013, at 9:50 AM, John Smith lbalba...@gmail.com wrote: Hi, Im not sure, but this may be more appropriate for the developers mailing list: openstack-dev@lists.openstack.org Regards, John Smith On Tue, Dec 3, 2013 at 3:36 PM, NAVEEN R K REDDY naveen.kunare...@gmail.com wrote: Hi All, I have couple of questions wrt to plugin blueprint and ml2 plugin, 1. We are planning to submit the plugin into Openstack Icehouse release. The question we have is there any deadline for the plugin blueprint submission ? 2. Is there anything like mandatory for everyone need to implement ML2 plugin instead of monolithic plugin ? Thanks in advance. Regards, Naveen. ___ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openst...@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack ___ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openst...@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Regards, Naveen. ___ 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] [ml2] Proposing a new time for the ML2 sub-team meeting
FYI: I have moved the ML2 meeting per my email below. The new timeslot per the meeting page [1] is Wednesday at 1600UTC on #openstack-meeting-alt. Thanks! Kyle [1] https://wiki.openstack.org/wiki/Meetings#ML2_Network_sub-team_meeting On Nov 26, 2013, at 9:26 PM, Kyle Mestery (kmestery) kmest...@cisco.com wrote: Folks: I'd like to propose moving the weekly ML2 meeting [1]. The new proposed time is Wednesdays at 1600 UTC, and will be in the #openstack-meeting-alt channel. Please respond back if this time conflicts for you, otherwise starting next week on 12-4-2013 we'll have the meeting at the new time. We will have a short meeting tomorrow at 1400 UTC in the #openstack-meeting channel to cover action items from last week and some proposed VIF changes. Thanks! Kyle [1] https://wiki.openstack.org/wiki/Meetings/ML2 ___ 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][qa] Parallel testing update
Yes, this is all great Salvatore and Armando! Thank you for all of this work and the explanation behind it all. Kyle On Dec 2, 2013, at 2:24 PM, Eugene Nikanorov enikano...@mirantis.com wrote: Salvatore and Armando, thanks for your great work and detailed explanation! Eugene. On Mon, Dec 2, 2013 at 11:48 PM, Joe Gordon joe.gord...@gmail.com wrote: On Dec 2, 2013 9:04 PM, Salvatore Orlando sorla...@nicira.com wrote: Hi, As you might have noticed, there has been some progress on parallel tests for neutron. In a nutshell: * Armando fixed the issue with IP address exhaustion on the public network [1] * Salvatore has now a patch which has a 50% success rate (the last failures are because of me playing with it) [2] * Salvatore is looking at putting back on track full isolation [3] * All the bugs affecting parallel tests can be queried here [10] * This blueprint tracks progress made towards enabling parallel testing [11] - The long story is as follows: Parallel testing basically is not working because parallelism means higher contention for public IP addresses. This was made worse by the fact that some tests created a router with a gateway set but never deleted it. As a result, there were even less addresses in the public range. [1] was already merged and with [4] we shall make the public network for neutron a /24 (the full tempest suite is still showing a lot of IP exhaustion errors). However, this was just one part of the issue. The biggest part actually lied with the OVS agent and its interactions with the ML2 plugin. A few patches ([5], [6], [7]) were already pushed to reduce the number of notifications sent from the plugin to the agent. However, the agent is organised in a way such that a notification is immediately acted upon thus preempting the main agent loop, which is the one responsible for wiring ports into networks. Considering the high level of notifications currently sent from the server, this becomes particularly wasteful if one consider that security membership updates for ports trigger global iptables-save/restore commands which are often executed in rapid succession, thus resulting in long delays for wiring VIFs to the appropriate network. With the patch [2] we are refactoring the agent to make it more efficient. This is not production code, but once we'll get close to 100% pass for parallel testing this patch will be split in several patches, properly structured, and hopefully easy to review. It is worth noting there is still work to do: in some cases the loop still takes too long, and it has been observed ovs commands taking even 10 seconds to complete. To this aim, it is worth considering use of async processes introduced in [8] as well as leveraging ovsdb monitoring [9] for limiting queries to ovs database. We're still unable to explain some failures where the network appears to be correctly wired (floating IP, router port, dhcp port, and VIF port), but the SSH connection fails. We're hoping to reproduce this failure patter locally. Finally, the tempest patch for full tempest isolation should be made usable soon. Having another experimental job for it is something worth considering as for some reason it is not always easy reproducing the same failure modes exhibited on the gate. Regards, Salvatore Awesome work, thanks for the update. [1] https://review.openstack.org/#/c/58054/ [2] https://review.openstack.org/#/c/57420/ [3] https://review.openstack.org/#/c/53459/ [4] https://review.openstack.org/#/c/58284/ [5] https://review.openstack.org/#/c/58860/ [6] https://review.openstack.org/#/c/58597/ [7] https://review.openstack.org/#/c/58415/ [8] https://review.openstack.org/#/c/45676/ [9] https://bugs.launchpad.net/neutron/+bug/1177973 [10] https://bugs.launchpad.net/neutron/+bugs?field.tag=neutron-parallelfield.tags_combinator=ANY [11] https://blueprints.launchpad.net/neutron/+spec/neutron-tempest-parallel ___ 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] VMware Workstation / Fusion / Player Nova driver
On Dec 1, 2013, at 4:10 PM, Alessandro Pilotti apilo...@cloudbasesolutions.com wrote: Hi all, At Cloudbase we are heavily using VMware Workstation and Fusion for development, demos and PoCs, so we thought: why not replacing our automation scripts with a fully functional Nova driver and use OpenStack APIs and Heat for the automation? :-) Here’s the repo for this Nova driver project: https://github.com/cloudbase/nova-vix-driver/ The driver is already working well and supports all the basic features you’d expect from a Nova driver, including a VNC console accessible via Horizon. Please refer to the project README for additional details. The usage of CoW images (linked clones) makes deploying images particularly fast, which is a good thing when you develop or run demos. Heat or Puppet, Chef, etc make the whole process particularly sweet of course. The main idea was to create something to be used in place of solutions like Vagrant, with a few specific requirements: 1) Full support for nested virtualization (VMX and EPT). For the time being the VMware products are the only ones supporting Hyper-V and KVM as guests, so this became a mandatory path, at least until EPT support will be fully functional in KVM. This rules out Vagrant as an option. Their VMware support is not free and beside that they don’t support nested virtualization (yet, AFAIK). Other workstation virtualization options, including VirtualBox and Hyper-V are currently ruled out due to the lack of support for this feature as well. Beside that Hyper-V and VMware Workstation VMs can work side by side on Windows 8.1, all you need is to fire up two nova-compute instances. 2) Work on Windows, Linux and OS X workstations Here’s a snapshot of Nova compute running on OS X and showing Novnc connected to a Fusion VM console: https://dl.dropboxusercontent.com/u/9060190/Nova-compute-os-x.png 3) Use OpenStack APIs We wanted to have a single common framework for automation and bring OpenStack on the workstations. Beside that, dogfooding is a good thing. :-) 4) Offer a free alternative for community contributions VMware Player is fair enough, even with the “non commercial use” limits, etc. Communication with VMware components is based on the freely available Vix SDK libs, using ctypes to call the C APIs. The project provides a library to easily interact with the VMs, in case it sould be needed, e.g.: from vix import vixutils with vixutils.VixConnection() as conn: with conn.open_vm(vmx_path) as vm: vm.power_on() We though about using libvirt, since it has support for those APIs as well, but it was way easier to create a lightweight driver from scratch using the Vix APIs directly. TODOs: 1) A minimal Neutron agent for attaching networks (now all networks are attached to the NAT interface). 2) Resize disks on boot based on the flavor size 3) Volume attach / detach (we can just reuse the Hyper-V code for the Windows case) 4) Same host resize Live migration is not making particularly sense in this context, so the implementation is not planned. Note: we still have to commit the unit tests. We’ll clean them during next week and push them. As usual, any idea, suggestions and especially contributions are highly welcome! We’ll follow up with a blog post with some additional news related to this project quite soon. This is very cool Alessandro, thanks for sharing! Any plans to try and get this nova driver upstreamed? Thanks, Kyle Thanks, Alessandro ___ 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] [ml2] Today's ML2 meeting is canceled
Some of the key people cannot make the meeting today, so we're canceling it for today. I would ask that people review the following two patches this week and we'll discuss them in detail next week if they haven't merged by then: https://review.openstack.org/#/c/21946/ https://review.openstack.org/#/c/37893/ Thanks! Kyle ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron] Why neutron-openvswitch-agent use linux-bridge?
On Nov 27, 2013, at 1:29 PM, George Shuklin george.shuk...@gmail.com wrote: Thank you for reply! Few more question: AFAIK bridge tools is not very fast (compare to OVS), so adding them between OVS and tap (instead of yet another OVS switch) is kinda slow everything down. Why just not use yet another openvswitch switch to connect tap to veth devices? Why iptables, not internal openvswitch flow rules? Those rules allows to filter packets on L2-L4 headers and operates very fast. Is some iptables-only features used in ova-agent? George: There is work ongoing now to implement security groups using OVS flow rules in the OVS agent with the ML2 plugin. That would do what you're looking at above. Stay tuned on this, the authors of these patches hope to have some WIP code available soon. Thanks, Kyle Thanks. 27.11.2013 20:55 пользователь Lorin Hochstein lo...@nimbisservices.com написал: Hi George: On Wed, Nov 27, 2013 at 1:45 PM, George Shuklin george.shuk...@gmail.com wrote: Good day. I looking at the internals of bridge layout of openvswitch agent at http://docs.openstack.org/network-admin/admin/content/figures/2/figures/under-the-hood-scenario-1-ovs-compute.png and wondering, why this scheme is so complicated and why it use linux bridge and vethes with openvswitch together? Why no just plug tap device directly to openvswitch bridge without intermediate brctl bridge? I guess that was caused by some important consideration, but I unable to find any documents about this. If someone know reasons for that complex construction with different bridges, please response. If you look a little further down on the page with that figure, the documentation reads Ideally, the TAP device vnet0 would be connected directly to the integration bridge, br-int. Unfortunately, this isn't possible because of how OpenStack security groups are currently implemented. OpenStack uses iptables rules on the TAP devices such as vnet0 to implement security groups, and Open vSwitch is not compatible with iptables rules that are applied directly on TAP devices that are connected to an Open vSwitch port. Take care, Lorin -- Lorin Hochstein Lead Architect - Cloud Services Nimbis Services, Inc. www.nimbisservices.com ___ 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] [neutron] [ml2] Proposing a new time for the ML2 sub-team meeting
Folks: I'd like to propose moving the weekly ML2 meeting [1]. The new proposed time is Wednesdays at 1600 UTC, and will be in the #openstack-meeting-alt channel. Please respond back if this time conflicts for you, otherwise starting next week on 12-4-2013 we'll have the meeting at the new time. We will have a short meeting tomorrow at 1400 UTC in the #openstack-meeting channel to cover action items from last week and some proposed VIF changes. Thanks! Kyle [1] https://wiki.openstack.org/wiki/Meetings/ML2 ___ 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] Handling of ovs command errors
On Nov 25, 2013, at 8:28 AM, Salvatore Orlando sorla...@nicira.com wrote: Hi, I've been recently debugging some issues I've had with the OVS agent, and I found out that in many cases (possibly every case) the code just logs errors from ovs-vsctl and ovs-ofctl without taking any action in the control flow. For instance, the routine which should do the wiring for a port, port_bound [1], does not react in any way if it fails to configure the local vlan, which I guess means the port would not be able to send/receive any data. I'm pretty sure there's a good reason for this which I'm missing at the moment. I am asking because I see a pretty large number of ALARM_CLOCK errors returned by OVS commands in gate logs (see bug [2]), and I'm not sure whether it's ok to handle them as the OVS agent is doing nowadays. Thanks for bringing this up Salvatore. It looks like the underlying run_vstcl [1] provides an ability to raise exceptions on errors, but this is not used by most of the callers of run_vsctl. Do you think we should be returning the exceptions back up the stack to callers to handle? I think that may be a good first step. Thanks, Kyle [1] https://github.com/openstack/neutron/blob/master/neutron/agent/linux/ovs_lib.py#L52 Regards, Salvatore [1] https://github.com/openstack/neutron/blob/master/neutron/plugins/openvswitch/agent/ovs_neutron_agent.py#L599 [2] https://bugs.launchpad.net/neutron/+bug/1254520 ___ 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] [policy] Logs and notes from first Neutron Policy IRC meeting
HI all! The Neutron Policy sub-team had it's first IRC meeting today [1]. Relevant logs from the meeting are here [2]. We're hoping to continue the discussion going forward. I've noted action items in both the meeting logs and on the wiki page. We'll cover those for the next meeting we have. Note: We'll not meet next week due to the Thanksgiving holiday in the US. Hope to see everyone on #openstack-meeting-alt at 1600 UTC on Thursday December 5th! In the meantime, please continue the discussion in IRC on #openstack-neutron and on the openstack-dev mailing list. Thanks, Kyle [1] https://wiki.openstack.org/wiki/Meetings/Neutron_Group_Policy [2] http://eavesdrop.openstack.org/meetings/networking_policy/2013/ ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Introducing myself - looking for a IPv6 topology
On Nov 19, 2013, at 7:23 PM, Martinx - ジェームズ thiagocmarti...@gmail.com wrote: One more thing... I'm thinking about the use case for Floating IPs in a NAT-less IPv6 OpenStack environment. I can think in two use cases in a IPv6-Only Tenant Subnet: 1- the Floating IP might be used to allocate more IPv6 address for an Instance (since there is no plans for NAT66, I believe it is not desired) but, instead of allocating it from the allocation pool, get it from the tenant subnet directly. This way, the IPv6 Floating IP will appear within the Instance it self, not at the L3 Namespace Router as it is with IPv4 today. 2- we can provide a IPv4 Floating IP address (for a IPv6-Only tenant) and the L3 Namespace Router will do the NAT46. This way, the old Internet will be able to seamless reach a IPv6-Only network. What do you guys have in mind / roadmap?! Cheers! Thiago Hi Thiago: An IPV6 subteam in Neutron was formed for the Icehouse release. The team will have weekly meetings in #openstack-meeting-alt on freenode Thursday's at 2100 UTV. See the meeting page here [1]. If you're planning to work on IPV6 in any form, it would be great to participate in these and help shape the IPV6 direction for Neutron. Thanks, and welcome aboard! Kyle [1] https://wiki.openstack.org/wiki/Meetings/Neutron-IPv6-Subteam On 19 November 2013 22:57, Martinx - ジェームズ thiagocmarti...@gmail.com wrote: Hello Stackers! I'm Thiago and I'm here on dev list mostly to watch you guys... Nevertheless, I want to say that I would love to test in deep, the IPv6 support in OpenStack IceHouse. At at glance, what I'm looking for is more or less specified here, as follows: ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] Plugin and Driver Inclusion Requirements
Yong, if you read Mark's proposal closely, the third party tests will only run when the specific third party code is touched, or when the Jenkins user submits code. On Nov 17, 2013, at 11:50 PM, Yongsheng Gong gong...@unitedstack.com wrote: For third party testing, I am afraid these tests will make the patch merge process much longer since each patch, which even has nothing to do with the specific plugins, will triggers the unwanted third party testing jobs. On Fri, Nov 15, 2013 at 4:20 AM, Mark McClain mark.mccl...@dreamhost.com wrote: tl;dr - The Neutron team has experienced tremendous growth in vendor plugins and drivers over the last few cycles. As a result of the growth, the Neutron team is implementing new requirements for plugin and driver code for Icehouse cycle to ensure continued code quality and stability. - Each third party plugin/driver shall designate a point of contact for the coordinated release cycle. - To be designated as compatible, a third-party plugin and/or driver code must implement external third party integration testing. - Policy is in effect immediately for new plugin/drivers. - Existing plugin/drivers have until Icehouse-2 to become compliant. Introduction --- Ensuring release quality through proper testing is an important tenant of the OpenStack community and Neutron team wants to do our part. We are introducing changes below provide more visibility into the quality and stability of vendor plugin and driver code. The policies described here are in effect immediately. Rationale Code proposals for third party plugins have always presented a review challenge for the Neutron core team. In the early days, code was often proposed by core project contributors and our review process only validated whether the requirements were met for community coding style and unit testing. As Neutron has added new resources via extensions, it has become more difficult for Neutron reviewers to ensure the proposed code is functional. Many of the plugins and/or drivers require proprietary hardware and/or software to conduct such testing. In addition to testing changes, the Neutron team is revising the requirements for the point of contact for third party code. The changes bring the written expectations for contacts in line with current practice. Point of Contact Requirements - Each third party plugin and/or driver shall designate a point of contact for each coordinated release cycle. The contact will serve as a liaison between the Neutron core team and the vendor or community supporting the plugin or driver. The contact shall: - Attend weekly Neutron team IRC meetings - Be an active reviewer and contributor - Be an active participant on openstack-dev mailing list - Assist the core team with triaging bugs specific to the plugin and/or driver - Ensure OpenStack development deadlines are properly communicated back to their company and/or community NOTE: The this information can be maintained here: https://wiki.openstack.org/wiki/Neutron_Plugins_and_Drivers Testing Requirements - To be designated as compatible, a third-party plugin and/or driver code must implement external third party testing. The testing should be Tempest executed against a Devstack build with the proposed code changes. The environment managed by the vendor should be configured to incorporate the plugin and/or driver solution. The OpenStack Infrastructure team has provided details on how to integrate 3rd party testing at: http://ci.openstack.org/third_party.html and Tempest can be found at: https://github.com/openstack/tempest The Neutron team expects that the third party testing will provide a +/-1 verify vote for all changes to a plugin or driver’s code. In addition, the Neutron team expects that the third party test will also vote on all code submissions by the jenkins user. The jenkins user regularly submits requirements changes and the Neutron team hopes to catch any possible regressions as early as possible. Existing Plugin and Drivers - Plugins and drivers currently in the Neutron project repository will be given a grace period until the Icehouse-2 milestone to implement external third party testing. At that time, the Neutron team will release a list of the compatible plugins and drivers (i.e. those that meet the testing requirements). Plugins and drivers that do not have external testing will be deprecated at the Icehouse release and will be candidates for removal when the J-release cycle opens. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev
Re: [openstack-dev] Reg : Security groups implementation using openflows in quantum ovs plugin
On Nov 18, 2013, at 4:26 PM, Kanthi P pavuluri.kan...@gmail.com wrote: Hi All, We are planning to implement quantum security groups using openflows for ovs plugin instead of iptables which is the case now. Doing so we can avoid the extra linux bridge which is connected between the vnet device and the ovs bridge, which is given as a work around since ovs bridge is not compatible with iptables. We are planning to create a blueprint and work on it. Could you please share your views on this Hi Kanthi: Overall, this idea is interesting and removing those extra bridges would certainly be nice. Some people at Bluehost gave a talk at the Summit [1] in which they explained they have done something similar, you may want to reach out to them since they have code for this internally already. The OVS plugin is in feature freeze during Icehouse, and will be deprecated in favor of ML2 [2] at the end of Icehouse. I would advise you to retarget your work at ML2 when running with the OVS agent instead. The Neutron team will not accept new features into the OVS plugin anymore. Thanks, Kyle [1] http://www.openstack.org/summit/openstack-summit-hong-kong-2013/session-videos/presentation/towards-truly-open-and-commoditized-software-defined-networks-in-openstack [2] https://wiki.openstack.org/wiki/Neutron/ML2 Thanks, Kanthi ___ 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] [ml2] ML2 meeting agenda this week
Folks: The agenda for this week's ML2 meeting has been posted. I'd like to focus 30 minutes or so on ML2 testing, and the rest on the TypeDriver Summit Session. We need to add Tempest tests around the main Open Source components of ML2. What is lacking now is LinuxBridge and L2 Population Tempest tests, and OpenDaylight is coming soon and will require the same. Look forward to a lively discussion and the continuing evolution of ML2 in Icehouse! Thanks, Kyle [1] https://wiki.openstack.org/wiki/Meetings/ML2 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron] [ml2] ML2 meeting agenda this week
One other note: The meeting is still at 1400UTC, which for people in most parts of the US means it's an hour earlier now. If this meeting time isn't good for folks, we can discuss moving this to a different time. Thanks, Kyle On Nov 18, 2013, at 8:49 PM, Kyle Mestery (kmestery) kmest...@cisco.com wrote: Folks: The agenda for this week's ML2 meeting has been posted. I'd like to focus 30 minutes or so on ML2 testing, and the rest on the TypeDriver Summit Session. We need to add Tempest tests around the main Open Source components of ML2. What is lacking now is LinuxBridge and L2 Population Tempest tests, and OpenDaylight is coming soon and will require the same. Look forward to a lively discussion and the continuing evolution of ML2 in Icehouse! Thanks, Kyle [1] https://wiki.openstack.org/wiki/Meetings/ML2 ___ 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] Neutron Tempest code sprint - 2nd week of January, Montreal, QC, Canada
On Nov 15, 2013, at 9:36 AM, Russell Bryant rbry...@redhat.com wrote: On 11/13/2013 11:10 AM, Anita Kuno wrote: Neutron Tempest code sprint In the second week of January in Montreal, Quebec, Canadathere will be a Neutron Tempest code sprint to improve the status of Neutron tests in Tempest and to add new tests. First off, I think anything regarding putting more effort into this is great. However, I *beg* the Neutron team not to wait until this week to make significant progress. To be clear, IMO, this is already painfully late. It's one of the largest items blocking deprecation of nova-network and moving forward with Neutron. This spring is just a couple weeks before icehouse-2. Come i2, mid-cycle, we're going to have make a call on whether or not nova-network deprecation seems likely. If not, we really can't wait around and I will probably propose un-freezing nova-network. The event will be vendor neutral. We will talk to each other based on who we are and our interests, not based on who signs our paycheque. If folks arrive with logoed shirts (I don't know which logos are work logos and which aren't, so I will request no logos please) I will issue you a white T-shirt to wear. We need to work collaboratively to effectlvely make progress during the code sprint. I'm all for promoting a culture of individuals and vendor neutrality. However, I think this requirement is bizarre and unnecessary. From a practical standpoint, many people (myself included) get a ton of shirts at conferences, so a lot of my clothes have tech company logos. If you actually get people to show up to an event dedicated to working on testing, who cares what shirt they have on? I will issue you a white T-shirt?! Are you serious? Someone at the summit choose not to wear footwear at the event. If you want to come to the code sprint please plan on wearing appropriate footwear in the public areas at the code sprint. For two reasons: 1. It will be cold. 2. The event is meant to facilitate mutual respect between us to increase communication, both at the event and afterwards. I feel wearing appropriate footwear supports this goal. It's Winter in Canada... I'd be quite surprised if someone went without shoes. I love the idea, but this stuff is just a big turn-off. Huge +1 from me as well. The sprint and Tempest work is great, the clothing requirements are going to make people not take this seriously. I feel these were not necessary. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron] Group-based Policy Sub-team Meetings
On Nov 14, 2013, at 9:38 AM, Mohammad Banikazemi m...@us.ibm.com wrote: Kyle, Thank you for organizing this. I think the original email you sent out did not solicit any comments (except for possibly proposing a different time for the weekly meetings). So that is probably why you have not heard from anybody (including me). So we are ready to have the meeting but if the consensus is that people need more time to prepare that is fine too. Lets go with the time slot I've proposed, as no one objected. I think we need to set an agenda for our meeting (similar to what you do for the ML2 calls) so we have a better idea of what we need to do during the meeting. In the proposal, we have identified new object resources. Should we start making those definitions and their relationship with other objects more precise. Just a suggestion. Can you add this to the agenda [1] for next week? Thanks, Kyle [1] https://wiki.openstack.org/wiki/Meetings/Neutron_Group_Policy Thanks, Mohammad graycol.gifKyle Mestery (kmestery) ---11/13/2013 01:09:02 PM---On Nov 13, 2013, at 10:36 AM, Stephen Wong s3w...@midokura.com wrote: From: Kyle Mestery (kmestery) kmest...@cisco.com To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org, Date: 11/13/2013 01:09 PM Subject: Re: [openstack-dev] [neutron] Group-based Policy Sub-team Meetings On Nov 13, 2013, at 10:36 AM, Stephen Wong s3w...@midokura.com wrote: Hi Kyle, So no meeting this Thursday? I am inclined to skip this week's meeting due to the fact I haven't heard many replies yet. I think a good starting point for people would be to review the BP [1] and Design Document [2] and provide feedback where appropriate. We should start to formalize what the APIs will look like at next week's meeting, and the Design Document has a first pass at this. Thanks, Kyle [1] https://blueprints.launchpad.net/neutron/+spec/group-based-policy-abstraction [2] https://docs.google.com/document/d/1ZbOFxAoibZbJmDWx1oOrOsDcov6Cuom5aaBIrupCD9E/edit?usp=sharing Thanks, - Stephen On Wed, Nov 13, 2013 at 7:11 AM, Kyle Mestery (kmestery) kmest...@cisco.com wrote: On Nov 13, 2013, at 8:58 AM, Stein, Manuel (Manuel) manuel.st...@alcatel-lucent.com wrote: Kyle, I'm afraid your meeting vanished from the Meetings page [2] when user amotiki reworked neutron meetings ^.^ Is the meeting for Thu 1600 UTC still on? Ack, thanks for the heads up here! I have re-added the meeting. I only heard back from one other person other than yourself, so at this point I'm inclined to wait until next week to hold our first meeting unless I hear back from others. A few heads-up questions (couldn't attend the HK design summit Friday meeting): 1) In the summit session Etherpad [3], ML2 implementation mentions insertion of arbitrary metadata to hint to underlying implementation. Is that (a) the plug-ing reporting its policy-bound realization? (b) the user further specifying what should be used? (c) both? Or (d) none of that but just some arbitrary message of the day? I believe that would be (a). 2) Would policies _always_ map to the old Neutron entities? E.g. when I have policies in place, can I query related network/port, subnet/address, router elements on the API or are there no equivalents created? Would the logical topology created under the policies be exposed otherwise? for e.g. monitoring/wysiwyg/troubleshoot purposes. No, this is up to the plugin/MechanismDriver implementation. 3) Do the chain identifier in your policy rule actions match to Service Chain UUID in Service Insertion, Chaining and API [4] That's one way to look at this, yes. 4) Are you going to describe L2 services the way group policies work? I mean, why would I need a LoadBalancer or Firewall instance before I can insert it between two groups when all that load balancing/firewalling requires is nothing but a policy for group communication itself? - regardless the service instance used to carry out the service. These are things I'd like to discuss at the IRC meeting each week. The goal would be to try and come up with some actionable items we can drive towards in both Icehouse-1 and Icehouse-2. Given how close the closing of Icehouse-1 is, we need to focus on this very fast if we want to have a measurable impact in Icehouse-1. Thanks, Kyle Best, Manuel [2] https://wiki.openstack.org/wiki/Meetings#Neutron_Group_Policy_Sub-Team_Meeting [3] https://etherpad.openstack.org/p/Group_Based_Policy_Abstraction_for_Neutron [4] https://docs.google.com/document/d/1fmCWpCxAN4g5txmCJVmBDt02GYew2kvyRsh0Wl3YF2U/edit# -Original Message- From: Kyle Mestery (kmestery) [mailto:kmest...@cisco.com] Sent: Montag, 11. November 2013 19:41 To: OpenStack
Re: [openstack-dev] [neutron] Group-based Policy Sub-team Meetings
On Nov 13, 2013, at 10:36 AM, Stephen Wong s3w...@midokura.com wrote: Hi Kyle, So no meeting this Thursday? I am inclined to skip this week's meeting due to the fact I haven't heard many replies yet. I think a good starting point for people would be to review the BP [1] and Design Document [2] and provide feedback where appropriate. We should start to formalize what the APIs will look like at next week's meeting, and the Design Document has a first pass at this. Thanks, Kyle [1] https://blueprints.launchpad.net/neutron/+spec/group-based-policy-abstraction [2] https://docs.google.com/document/d/1ZbOFxAoibZbJmDWx1oOrOsDcov6Cuom5aaBIrupCD9E/edit?usp=sharing Thanks, - Stephen On Wed, Nov 13, 2013 at 7:11 AM, Kyle Mestery (kmestery) kmest...@cisco.com wrote: On Nov 13, 2013, at 8:58 AM, Stein, Manuel (Manuel) manuel.st...@alcatel-lucent.com wrote: Kyle, I'm afraid your meeting vanished from the Meetings page [2] when user amotiki reworked neutron meetings ^.^ Is the meeting for Thu 1600 UTC still on? Ack, thanks for the heads up here! I have re-added the meeting. I only heard back from one other person other than yourself, so at this point I'm inclined to wait until next week to hold our first meeting unless I hear back from others. A few heads-up questions (couldn't attend the HK design summit Friday meeting): 1) In the summit session Etherpad [3], ML2 implementation mentions insertion of arbitrary metadata to hint to underlying implementation. Is that (a) the plug-ing reporting its policy-bound realization? (b) the user further specifying what should be used? (c) both? Or (d) none of that but just some arbitrary message of the day? I believe that would be (a). 2) Would policies _always_ map to the old Neutron entities? E.g. when I have policies in place, can I query related network/port, subnet/address, router elements on the API or are there no equivalents created? Would the logical topology created under the policies be exposed otherwise? for e.g. monitoring/wysiwyg/troubleshoot purposes. No, this is up to the plugin/MechanismDriver implementation. 3) Do the chain identifier in your policy rule actions match to Service Chain UUID in Service Insertion, Chaining and API [4] That's one way to look at this, yes. 4) Are you going to describe L2 services the way group policies work? I mean, why would I need a LoadBalancer or Firewall instance before I can insert it between two groups when all that load balancing/firewalling requires is nothing but a policy for group communication itself? - regardless the service instance used to carry out the service. These are things I'd like to discuss at the IRC meeting each week. The goal would be to try and come up with some actionable items we can drive towards in both Icehouse-1 and Icehouse-2. Given how close the closing of Icehouse-1 is, we need to focus on this very fast if we want to have a measurable impact in Icehouse-1. Thanks, Kyle Best, Manuel [2] https://wiki.openstack.org/wiki/Meetings#Neutron_Group_Policy_Sub-Team_Meeting [3] https://etherpad.openstack.org/p/Group_Based_Policy_Abstraction_for_Neutron [4] https://docs.google.com/document/d/1fmCWpCxAN4g5txmCJVmBDt02GYew2kvyRsh0Wl3YF2U/edit# -Original Message- From: Kyle Mestery (kmestery) [mailto:kmest...@cisco.com] Sent: Montag, 11. November 2013 19:41 To: OpenStack Development Mailing List (not for usage questions) Subject: [openstack-dev] [neutron] Group-based Policy Sub-team Meetings Hi folks! Hope everyone had a safe trip back from Hong Kong. Friday afternoon in the Neutron sessions we discussed the Group-based Policy Abstraction BP [1]. It was decided we would try to have a weekly IRC meeting to drive out further requirements with the hope of coming up with a list of actionable tasks to begin working on by December. I've tentatively set the meeting [2] for Thursdays at 1600 UTC on the #openstack-meeting-alt IRC channel. If there are serious conflicts with this day and time, please speak up soon. Otherwise, we'll host our first meeting on Thursday this week. Thanks! Kyle [1] https://blueprints.launchpad.net/neutron/+spec/group-based-pol icy-abstraction [2] https://wiki.openstack.org/wiki/Meetings#Neutron_Group_Policy_ Sub-Team_Meeting ___ 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
Re: [openstack-dev] [neutron] Group-based Policy Sub-team Meetings
On Nov 13, 2013, at 12:57 PM, Tim Hinrichs thinri...@vmware.com wrote: Are there plans for a concrete policy language (e.g. a grammar and semantics) to be part of the proposal, or does each plugin to Neutron supply its own policy language? There are no concrete plans for this right now, though I suspected this would come up. I'm trying to envision how Heat would utilize the policy API. If there's a concrete policy language, then Heat can take an app template, extract the networking-relevant policy, and express that policy in the concrete language. Then whatever plugin we're using for Neutron can implement that policy in any way it sees fit as long as it obeys the policy's semantics (according to the language--the semantics Heat intended). But if there's no concrete policy language, how does Heat know which policy statements to send? It doesn't know which plugin is being used for Neutron. So it doesn't even know which strings are valid policy statements. Or are we assuming that Heat knows which plugin is being used for Neutron? Or am I missing something? The APIs alone provide a mechanism for utilizing the new constructs, but the specific policy intent is left to the underlying plugin. This would be a good thing to discuss at our meeting next week. Thanks, Kyle Thanks, Tim - Original Message - | From: Kyle Mestery (kmestery) kmest...@cisco.com | To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org | Sent: Wednesday, November 13, 2013 9:57:54 AM | Subject: Re: [openstack-dev] [neutron] Group-based Policy Sub-team Meetings | | On Nov 13, 2013, at 10:36 AM, Stephen Wong s3w...@midokura.com | wrote: | | Hi Kyle, | | So no meeting this Thursday? | | I am inclined to skip this week's meeting due to the fact I haven't | heard many | replies yet. I think a good starting point for people would be to | review the | BP [1] and Design Document [2] and provide feedback where | appropriate. | We should start to formalize what the APIs will look like at next | week's meeting, | and the Design Document has a first pass at this. | | Thanks, | Kyle | | [1] | https://blueprints.launchpad.net/neutron/+spec/group-based-policy-abstraction | [2] | https://docs.google.com/document/d/1ZbOFxAoibZbJmDWx1oOrOsDcov6Cuom5aaBIrupCD9E/edit?usp=sharing | | Thanks, | - Stephen | | On Wed, Nov 13, 2013 at 7:11 AM, Kyle Mestery (kmestery) | kmest...@cisco.com wrote: | On Nov 13, 2013, at 8:58 AM, Stein, Manuel (Manuel) | manuel.st...@alcatel-lucent.com wrote: | | Kyle, | | I'm afraid your meeting vanished from the Meetings page [2] when | user amotiki reworked neutron meetings ^.^ | Is the meeting for Thu 1600 UTC still on? | | Ack, thanks for the heads up here! I have re-added the meeting. I | only heard | back from one other person other than yourself, so at this point | I'm inclined | to wait until next week to hold our first meeting unless I hear | back from others. | | A few heads-up questions (couldn't attend the HK design summit | Friday meeting): | | 1) In the summit session Etherpad [3], ML2 implementation | mentions insertion of arbitrary metadata to hint to underlying | implementation. Is that (a) the plug-ing reporting its | policy-bound realization? (b) the user further specifying what | should be used? (c) both? Or (d) none of that but just some | arbitrary message of the day? | | I believe that would be (a). | | 2) Would policies _always_ map to the old Neutron entities? | E.g. when I have policies in place, can I query related | network/port, subnet/address, router elements on the API or are | there no equivalents created? Would the logical topology created | under the policies be exposed otherwise? for e.g. | monitoring/wysiwyg/troubleshoot purposes. | | No, this is up to the plugin/MechanismDriver implementation. | | 3) Do the chain identifier in your policy rule actions match to | Service Chain UUID in Service Insertion, Chaining and API [4] | | That's one way to look at this, yes. | | 4) Are you going to describe L2 services the way group policies | work? I mean, why would I need a LoadBalancer or Firewall | instance before I can insert it between two groups when all that | load balancing/firewalling requires is nothing but a policy for | group communication itself? - regardless the service instance | used to carry out the service. | | These are things I'd like to discuss at the IRC meeting each week. | The goal | would be to try and come up with some actionable items we can | drive towards | in both Icehouse-1 and Icehouse-2. Given how close the closing of | Icehouse-1 | is, we need to focus on this very fast if we want to have a | measurable impact in | Icehouse-1. | | Thanks, | Kyle | | | Best, Manuel | | [2
Re: [openstack-dev] [nova] Blueprint for Juniper OpenContrail vrouter nova vif driver support
On Nov 12, 2013, at 5:26 PM, Prasad Miriyala pmiriy...@juniper.net wrote: Hi All, A blueprint has been registered to add Nova vif driver support for Juniper vrouter. The Juniper OpenContrail Controller is a logically centralized but physically distributed Software Defined Networking (SDN) controller that is responsible for providing the management, control, and analytics functions of the virtualized network. The Juniper OpenContrail vRouter is a forwarding plane (of a distributed router) that runs in the hypervisor of a virtualized server. It extends the network from the physical routers and switches in a data center into a virtual overlay network hosted in the virtualized servers. The OpenContrail vRouter is conceptually similar to existing commercial and open source vSwitches such as for example the Open vSwitch (OVS) but it also provides routing and higher layer services. The OpenContrail Controller provides the logically centralized control plane and management plane of the system and orchestrates the vRouters. Blueprint https://blueprints.launchpad.net/nova/+spec/juniper-opencontrail-vrouter-nova-vif-driver Associated contrail neutron plugin blueprint https://blueprints.launchpad.net/neutron/+spec/juniper-plugin-with-extensions Please review blueprint, all comments are welcome. Regards, Prasad Hi Prasad: We have seen the BP and review. The problem that we Neutron core are currently looking at is something which was discussed at the Summit in Hong Kong last week: The requirement of having Smokestack/Tempest tests for plugins. As a core team, we haven't decided yet if new plugins will require these tests before being added to the tree. All plugins will require these tests by Icehouse-2, so IMHO requiring new plugins to have them before they are submitted makes sense. I suspect we will cover this next week at the weekly Neutron IRC meeting, so stay tuned. 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
Re: [openstack-dev] [nova] Blueprint for Juniper OpenContrail vrouter nova vif driver support
On Nov 12, 2013, at 10:02 PM, Harshad Nakil hna...@contrailsystems.com wrote: Kyle, These requirement should also be required for existing third plugins. Will you allow new patches to existing plugins without this requirement? I hope we don't end up creating multiple classes of citizens. Regards -Harshad All plugins will require the Smokestack/Tempest tests to be claimed as supported. This will be required by Icehouse-2. The only thing I am bringing up here is whether or not we allow new plugins into the tree without the tests, given we're already in the Icehouse development cycle. That's what I suspect we need more input on from the rest of the Neutron core team. Thanks, Kyle On Nov 12, 2013, at 7:08 PM, Kyle Mestery (kmestery) kmest...@cisco.com wrote: On Nov 12, 2013, at 5:26 PM, Prasad Miriyala pmiriy...@juniper.net wrote: Hi All, A blueprint has been registered to add Nova vif driver support for Juniper vrouter. The Juniper OpenContrail Controller is a logically centralized but physically distributed Software Defined Networking (SDN) controller that is responsible for providing the management, control, and analytics functions of the virtualized network. The Juniper OpenContrail vRouter is a forwarding plane (of a distributed router) that runs in the hypervisor of a virtualized server. It extends the network from the physical routers and switches in a data center into a virtual overlay network hosted in the virtualized servers. The OpenContrail vRouter is conceptually similar to existing commercial and open source vSwitches such as for example the Open vSwitch (OVS) but it also provides routing and higher layer services. The OpenContrail Controller provides the logically centralized control plane and management plane of the system and orchestrates the vRouters. Blueprint https://blueprints.launchpad.net/nova/+spec/juniper-opencontrail-vrouter-nova-vif-driver Associated contrail neutron plugin blueprint https://blueprints.launchpad.net/neutron/+spec/juniper-plugin-with-extensions Please review blueprint, all comments are welcome. Regards, Prasad Hi Prasad: We have seen the BP and review. The problem that we Neutron core are currently looking at is something which was discussed at the Summit in Hong Kong last week: The requirement of having Smokestack/Tempest tests for plugins. As a core team, we haven't decided yet if new plugins will require these tests before being added to the tree. All plugins will require these tests by Icehouse-2, so IMHO requiring new plugins to have them before they are submitted makes sense. I suspect we will cover this next week at the weekly Neutron IRC meeting, so stay tuned. 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 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [neutron] Group-based Policy Sub-team Meetings
Hi folks! Hope everyone had a safe trip back from Hong Kong. Friday afternoon in the Neutron sessions we discussed the Group-based Policy Abstraction BP [1]. It was decided we would try to have a weekly IRC meeting to drive out further requirements with the hope of coming up with a list of actionable tasks to begin working on by December. I've tentatively set the meeting [2] for Thursdays at 1600 UTC on the #openstack-meeting-alt IRC channel. If there are serious conflicts with this day and time, please speak up soon. Otherwise, we'll host our first meeting on Thursday this week. Thanks! Kyle [1] https://blueprints.launchpad.net/neutron/+spec/group-based-policy-abstraction [2] https://wiki.openstack.org/wiki/Meetings#Neutron_Group_Policy_Sub-Team_Meeting ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] IPv6 sub-team?
On Nov 5, 2013, at 5:50 PM, Collins, Sean (Contractor) sean_colli...@cable.comcast.com wrote: Hi, Is there any interest in organizing a IPv6 sub-team, similar to how there are sub-teams for FwaaS, VPNaas, ML2, etc? +1, lets do it! ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Heat] Network topologies
On Nov 2, 2013, at 3:12 PM, Salvatore Orlando sorla...@nicira.com wrote: Hi. I looked at the detailed API specification submitted by Edgar. I think that the document Edgar shared does a fine job in discussion how an API for managing logical topologies should work. On the other hand, there are two aspects which still need some clarification, and which perhaps are at the source of the confusion regarding whether it belongs to neutron, heat, or anywhere else. First, the use cases section merely re-states the objective session. I think that section should somehow address the questions why do we need this API? How having an API for storing network topologies would be useful for us. The other aspect is that - and I might be terribly wrong here - I think that one of the goals Neutron API was already supposed to abstract the complexity of network topologies - if we need another API (or perhaps more aptly an extension of the Neutron API) to satisfy this goal, does this mean the Neutron API is failing in one of its main goals? Not to hijack this thread, but this is exactly the reason Cisco, IBM, Juniper, Nuage Networks, Plexxi, Red Hat and others are proposing the following BP at the Summit this week [1]. I think as you will read in the BP the abstractions of the Neutron API can be extended such that it removes some of the complexity for API users. We have a session Friday afternoon in the Neutron track to discuss these in fact. Looking forwarding to a lively discussion! Thanks, Kyle [1] https://docs.google.com/document/d/1ZbOFxAoibZbJmDWx1oOrOsDcov6Cuom5aaBIrupCD9E/edit?pli=1 Finally it would be interesting to have a few more details concerning how topologies created with this new API would be reflected on the existing data model. While this appears easy for bridges and routers, it is not immediate for other 'nfds' such as dhcp services. Salvatore On 29 October 2013 19:48, Aaron Rosen aro...@nicira.com wrote: Hi Edgar, I definitely see the usecase for the idea that you propose. In my opinion, I don't see the reason for moving the management of topology into neutron, Heat already provides this functionality (besides for the part of taking an existing deployment and generating a template file). Also, I wanted to point out that in a way you will have to do orchestration as you're topology manager will have to call the neutron api in order to create the topology and tear it down. Best, Aaron On Tue, Oct 29, 2013 at 11:33 AM, Edgar Magana emag...@plumgrid.com wrote: Tim, You statement building an api that manages a network topology more than one that needs to build out the dependencies between resources to help create the network topology Is exactly what we are proposing, and this is why we believe this is not under Heat domain. This is why we are NOT proposing to manage any dependency between network elements, that part is what I call intelligence of the orchestration and we are not proposing any orchestration system, you are already have that in place :-) So, we simple want an API that tenats may use to save, retrieve and share topologies. For instance, tenant A creates a topology with two networks (192.168.0.0/24 and 192.168.1.0/24) both with dhcp enabled and a router connecting them. So, we first create it using CLI commands or Horizon and then we call the API to save the topology for that tenant, that topology can be also share between tenants if the owner wanted to do that, the same concept that we have in Neutron for share networks, So Tenant B or any other Tenants, don't need to re-create the whole topology, just open the shared topology from tenant A. Obviously, overlapping IPs will be a must requirement. I am including in this thread to Mark McClain who is the Neutron PTL and the main guy expressing concerns in not having overlapping functionalities between Neutron and Heat or any other project. I am absolutely, happy to discuss further with you but if you are ok with this approach we could start the development in Neutron umbrella, final thoughts? Thanks, Edgar On 10/29/13 8:23 AM, Tim Schnell tim.schn...@rackspace.com wrote: Hi Edgar, It seems like this blueprint is related more to building an api that manages a network topology more than one that needs to build out the dependencies between resources to help create the network topology. If we are talking about just an api to save, duplicate, and share these network topologies then I would agree that this is not something that Heat currently does or should do necessarily. I have been focusing primarily on front-end work for Heat so I apologize if these questions have already been answered. How is this API related to the existing network topology in Horizon? The existing network topology can already define the relationships and dependencies using Neutron I'm assuming so there is no apparent need to use
Re: [openstack-dev] [Heat] Network topologies
On Nov 4, 2013, at 7:31 PM, Clint Byrum cl...@fewbar.com wrote: Excerpts from Kyle Mestery (kmestery)'s message of 2013-11-05 06:35:04 +0800: On Nov 2, 2013, at 3:12 PM, Salvatore Orlando sorla...@nicira.com wrote: Hi. I looked at the detailed API specification submitted by Edgar. I think that the document Edgar shared does a fine job in discussion how an API for managing logical topologies should work. On the other hand, there are two aspects which still need some clarification, and which perhaps are at the source of the confusion regarding whether it belongs to neutron, heat, or anywhere else. First, the use cases section merely re-states the objective session. I think that section should somehow address the questions why do we need this API? How having an API for storing network topologies would be useful for us. The other aspect is that - and I might be terribly wrong here - I think that one of the goals Neutron API was already supposed to abstract the complexity of network topologies - if we need another API (or perhaps more aptly an extension of the Neutron API) to satisfy this goal, does this mean the Neutron API is failing in one of its main goals? Not to hijack this thread, but this is exactly the reason Cisco, IBM, Juniper, Nuage Networks, Plexxi, Red Hat and others are proposing the following BP at the Summit this week [1]. I think as you will read in the BP the abstractions of the Neutron API can be extended such that it removes some of the complexity for API users. We have a session Friday afternoon in the Neutron track to discuss these in fact. Looking forwarding to a lively discussion! Thanks, Kyle [1] https://docs.google.com/document/d/1ZbOFxAoibZbJmDWx1oOrOsDcov6Cuom5aaBIrupCD9E/edit?pli=1 Hi Kyle, can you copy this to etherpad.openstack.org and link it from https://wiki.openstack.org/wiki/Summit/Icehouse/Etherpads Hi Clint: I've already posted an etherpad there, it's in fact at this link [1]. I've copied some notes there, it's hard to translate the diagrams but what I've put in there is enough to get the discussion going on Friday. Thanks, Kyle [1] https://etherpad.openstack.org/p/Group_Based_Policy_Abstraction_for_Neutron Thanks! ___ 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] VLAN aware VMs
How about if we do a developers lounge chat at 2PM Thursday? On Nov 4, 2013, at 10:20 PM, Yi Sun beyo...@gmail.com wrote: Guys, I just checked the schedule of unconference sessions. There are no free slots anymore. Yi On Tuesday, October 29, 2013, Isaku Yamahata wrote: Hi Erik and Li. Unconference at the next summit? On Mon, Oct 28, 2013 at 02:34:28PM -0700, beyounn beyo...@gmail.com wrote: Hi Erik, While we were discussing about the service VM framework, the trunk port support was also mentioned. I think people do see the needs for it. I have seen someone have mentioned another BP https://blueprints.launchpad.net/neutron/+spec/quantum-network-bundle-api in your BP already. Maybe it is same as what you are doing. And the trunk port use case can also impact how the zone being constructed in the fwaas context (when a firewall VM uses a trunk port to connect multiple networks). The basic question is how we should present a trunk port and the vlan on a trunk port to Neutron. Yi From: Erik Moe [mailto:emoe...@gmail.com] Sent: Monday, October 28, 2013 1:56 PM To: openstack-dev@lists.openstack.org Subject: [openstack-dev] [Neutron] VLAN aware VMs Hi! We are looking into how to make it possible for tenant VMs to use VLAN tagged traffic to connect to different Neutron networks. The VID on frames sent/received will determine which Neutron network the frames are connected to. https://blueprints.launchpad.net/neutron/+spec/vlan-aware-vms I would like to find others that also see the need for this kind of functionality and would like to discuss this. Regards, Erik ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Isaku Yamahata isaku.yamah...@gmail.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Android-x86 http://www.android-x86.org ___ 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] When is it okay for submitters to say 'I don't want to add tests' ?
On Oct 31, 2013, at 8:56 AM, Clint Byrum cl...@fewbar.com wrote:
Excerpts from Mark McLoughlin's message of 2013-10-31 06:30:32 -0700:
On Thu, 2013-10-31 at 15:37 +1300, Robert Collins wrote:
This is a bit of a social norms thread
I've been consistently asking for tests in reviews for a while now,
and I get the occasional push-back. I think this falls into a few
broad camps:
A - there is no test suite at all, adding one in unreasonable
B - this thing cannot be tested in this context (e.g. functional tests
are defined in a different tree)
C - this particular thing is very hard to test
D - testing this won't offer benefit
E - other things like this in the project don't have tests
F - submitter doesn't know how to write tests
G - submitter doesn't have time to write tests
Nice breakdown.
Now, of these, I think it's fine not add tests in cases A, B, C in
combination with D, and D.
I don't think E, F or G are sufficient reasons to merge something
without tests, when reviewers are asking for them. G in the special
case that the project really wants the patch landed - but then I'd
expect reviewers to not ask for tests or to volunteer that they might
be optional.
I totally agree with the sentiment but, especially when it's a newcomer
to the project, I try to put myself in the shoes of the patch submitter
and double-check whether what we're asking is reasonable.
Even with a long time contributor, empathy is an important part of
constructing reviews. We could make more robotic things that review for
test coverage, but we haven't, because this is a gray area. The role of
a reviewer isn't just get patches merged and stop defects. It is also to
grow the other developers.
For example, if someone shows up to Nova with their first OpenStack
contribution, it fixes something which is unquestionably a bug - think
typo like raise NotFund('foo') - and testing this code patch requires
more than adding a simple new scenario to existing tests ...
This goes back to my recent suggestion to help the person not with a -1
or a +2, but with an additional patch that fixes it.
That, for me, is an example of -1, we need a test! untested code is
broken! is really shooting the messenger, not valuing the newcomers
contribution and risks turning that person off the project forever.
Reviewers being overly aggressive about this where the project doesn't
have full test coverage to begin with really makes us seem unwelcoming.
In cases like that, I'd be of a mind to go +2 Awesome! Thanks for
catching this! It would be great to have a unit test for this, but it's
clear the current code is broken so I'm fine with merging the fix
without a test. You could say it's now the reviewers responsibility to
merge a test, but if that requirement then turns off reviewers even
reviewing such a patch, then that doesn't help either.
I understand entirely why you choose this, and I think that is fine. I,
however, see this as a massive opportunity to teach. That code was only
broken because it was allowed it to be merged without tests. By letting
that situation continue, we only fix it today. The next major refactoring
has a high chance now of breaking that part of the code again.
So, rather than +2, I suggest -1 with compassion. Engage with the
submitter. If you don't know them, take a look at how hard it would be
to write a test for the behavior and give pointers to the exact test
suite that would need to be changed, or suggest a new test suite and
point at a good example to copy.
So, with all of this, let's make sure we don't forget to first
appreciate the effort that went into submitting the patch that lacks
tests.
I'm not going to claim that I've always practiced -1 with compassion,
so thanks for reminding us all that we're not just reviewing code, we
are having a dialog with real live people.
I think this is the key thing here, thanks for bringing this up Clint. At the
end of the day, patches are submitted by real people. If we want to grow
the committer base and help people to become better reviewers, taking
the time to show them the ropes is part of the game. I'd argue that is in
fact part of what being a core is about in fact.
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
Re: [openstack-dev] welcoming new committers (was Re: When is it okay for submitters to say 'I don't want to add tests' ?)
On Oct 31, 2013, at 1:49 PM, Stefano Maffulli stef...@openstack.org wrote: On 10/31/2013 07:05 AM, Kyle Mestery (kmestery) wrote: [...] If we want to grow the committer base and help people to become better reviewers, taking the time to show them the ropes is part of the game. hijacking the thread using Kyle's comment as an excuse. Hey, glad to provide you an opening Stef! It's not an 'if' but a 'since': since we are growing the committer base at an incredible pace we should help them become also good reviewers as rapidly possible. One thing I already mentioned and I'll start doing this week in the weekly Newsletter is to give a shoutout to those that do their first review this week. Another idea that Tom suggested is to use gerrit automation to send back to first time committers something in addition to the normal 'your patch is waiting for review' message. The message could be something like: thank you for your first contribution to OpenStack. Your patch will now be tested automatically by OpenStack testing frameworks and once the automatic tests pass, it will be reviewed by other friendly developers. They will give you comments and may require you to refine it. Nobody gets his patch approved at first try so don't be concerned when someone will require you to do more iterations. Patches usually take 3 to 7 days to be approved so be patient and be available on IRC to ask and answer questions about your work. The more you participate in the community the more rewarding it is for you. You may also notice that the more you get to know people and get to be known, the faster your patches will be reviewed and eventually approved. Get to know others and be known by doing code reviews: anybody can and should do it. With links to the wiki for more details, of course. This sort of messaging may help all the people that contribute tactically, those that are asked by their manager to land a patch in here and are simply lightly involved (not committed) in OpenStack. These are the ones that may have an incorrect perception of how easy it is to have patches landed in OpenStack as opposed to other large projects, like the kernel or android and complain about our time to traverse the review system. What do you think? How can we instruct gerrit to do this? I think this is a really good idea. I've seen occasions were new committers get antsy after waiting a few days (some even a few hours) and wondering why their patch isn't getting reviewed. Something like this would set the expectation for them correctly, and help to guide them to IRC to engage. Thanks, Kyle /stef PS I put the text on https://etherpad.openstack.org/p/welcome-new-committers for refinements. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] welcoming new committers (was Re: When is it okay for submitters to say 'I don't want to add tests' ?)
On Oct 31, 2013, at 3:21 PM, Monty Taylor mord...@inaugust.com wrote: On 10/31/2013 04:15 PM, Kyle Mestery (kmestery) wrote: On Oct 31, 2013, at 1:49 PM, Stefano Maffulli stef...@openstack.org wrote: On 10/31/2013 07:05 AM, Kyle Mestery (kmestery) wrote: [...] If we want to grow the committer base and help people to become better reviewers, taking the time to show them the ropes is part of the game. hijacking the thread using Kyle's comment as an excuse. Hey, glad to provide you an opening Stef! It's not an 'if' but a 'since': since we are growing the committer base at an incredible pace we should help them become also good reviewers as rapidly possible. One thing I already mentioned and I'll start doing this week in the weekly Newsletter is to give a shoutout to those that do their first review this week. Another idea that Tom suggested is to use gerrit automation to send back to first time committers something in addition to the normal 'your patch is waiting for review' message. The message could be something like: thank you for your first contribution to OpenStack. Your patch will now be tested automatically by OpenStack testing frameworks and once the automatic tests pass, it will be reviewed by other friendly developers. They will give you comments and may require you to refine it. Nobody gets his patch approved at first try so don't be concerned when someone will require you to do more iterations. Patches usually take 3 to 7 days to be approved so be patient and be available on IRC to ask and answer questions about your work. The more you participate in the community the more rewarding it is for you. You may also notice that the more you get to know people and get to be known, the faster your patches will be reviewed and eventually approved. Get to know others and be known by doing code reviews: anybody can and should do it. With links to the wiki for more details, of course. This sort of messaging may help all the people that contribute tactically, those that are asked by their manager to land a patch in here and are simply lightly involved (not committed) in OpenStack. These are the ones that may have an incorrect perception of how easy it is to have patches landed in OpenStack as opposed to other large projects, like the kernel or android and complain about our time to traverse the review system. What do you think? How can we instruct gerrit to do this? I think this is a really good idea. I've seen occasions were new committers get antsy after waiting a few days (some even a few hours) and wondering why their patch isn't getting reviewed. Something like this would set the expectation for them correctly, and help to guide them to IRC to engage. I agree! I think this is an excelent idea, and I think it's totally implementable. I'm not sure what all the details will be of that implementation, but I'm certain it can be done. Awesome, thanks Monty! We're all crazy with summit - could you file a bug at bugs.launchpad.net/openstack-ci so that we don't lose track of it? Done: https://bugs.launchpad.net/openstack-ci/+bug/1246879 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
Re: [openstack-dev] About ryu neutron plugin
Yong: It's been a while, but I've had success with Ryu in the past. As Kaneko points out, explaining the details of the issues you're hitting would help us narrow things down. Thanks, Kyle On Oct 27, 2013, at 5:09 AM, Yoshihiro Kaneko ykaneko0...@gmail.com wrote: Hi Yong, Could you explain the details of your problem? Thanks, Kaneko 2013/10/27 Yongsheng Gong gong...@unitedstack.com: Hi, I am trying to set up a deployment via neutron ryu plugin, but it seems there is no way to set up it right with the latest neutron code and the latest ryu code . And the document about ryu with openstack is not updated for a long time. https://github.com/osrg/ryu/wiki/OpenStack Who is maintaining the neutron ryu plugin can help me with it? Thanks Yong Sheng Gong ___ 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] VLAN aware VMs
I think the trunk port BP referenced below (and registered by myself) would likely solve this use case. There is no design summit session to discuss this, but I hope to have an unconference slot in Hong Kong to discuss this with folks who are interested. Thanks, Kyle On Oct 28, 2013, at 4:34 PM, beyounn beyo...@gmail.com wrote: Hi Erik, While we were discussing about the service VM framework, the trunk port support was also mentioned. I think people do see the needs for it. I have seen someone have mentioned another BP https://blueprints.launchpad.net/neutron/+spec/quantum-network-bundle-api in your BP already. Maybe it is same as what you are doing. And the trunk port use case can also impact how the zone being constructed in the fwaas context (when a firewall VM uses a trunk port to connect multiple networks). The basic question is how we should present a trunk port and the vlan on a trunk port to Neutron. Yi From: Erik Moe [mailto:emoe...@gmail.com] Sent: Monday, October 28, 2013 1:56 PM To: openstack-dev@lists.openstack.org Subject: [openstack-dev] [Neutron] VLAN aware VMs Hi! We are looking into how to make it possible for tenant VMs to use VLAN tagged traffic to connect to different Neutron networks. The VID on frames sent/received will determine which Neutron network the frames are connected to. https://blueprints.launchpad.net/neutron/+spec/vlan-aware-vms I would like to find others that also see the need for this kind of functionality and would like to discuss this. Regards, Erik ___ 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] [ml2] Canceling today's ML2 meeting
Hi folks: We don't really have an agenda today, so we're going to cancel the ML2 meeting today. Depending on what ML2 items get selected for the Summit, we'll likely meet next week to plan the discussions around those. One other note: Please keep an eye open for any bug fixes we should backport to the first stable release of Havana which fix issues in ML2. Thanks! Kyle ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Merge multiple OVS bridges ?
On Oct 22, 2013, at 2:21 AM, Gopi Krishna B gopi97...@gmail.com wrote: Hi Currently in Neutron the integration bridge (br-int) and other bridges configured over each physical nic (e.g. br-eth0, br-eth1 etc) are being configured in Compute and Network nodes. What is the logic behind or advantages having 2 OVS bridges in the physical host? Can we have only one bridge for each physical NIC, similar to what linux bridge setup has. And configure/modify the flows such that VLAN conversion is appropriately setup for ingress and egress traffic within the single bridge. Thus also eliminating the veth pairs used to connect the bridges together. Is this a feasible proposal, and can it be worked on? Sure, please file a blueprint and submit a patch for this, I would review this for sure! :) There are optimizations underway around this area. For example, we're looking at possibly collapsing the individual Linuxbridge and OVS agents into a single agent. In the context of ML2, this makes sense. I've thought a bit about collapsing the bridges from two to one and this is something which seems quite doable frankly. Thanks, Kyle -- Regards Gopi Krishna ___ 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] Distributed Virtual Router Discussion
Count me in on this discussion as well. May make sense to have a lightning talk at the summit, or an unconference slot. On Oct 22, 2013, at 1:50 PM, Vasudevan, Swaminathan (PNB Roseville) swaminathan.vasude...@hp.com wrote: Hi Folks, Thanks for your interests in the DVR feature. We should get together to start discussing the details in the DVR. Please let me know who else is interested, probably the time slot and we can start nailing down the details. https://blueprints.launchpad.net/neutron/+spec/neutron-ovs-dvr https://wiki.openstack.org/wiki/Distributed_Router_for_OVS Thanks Swami From: Robin Wang [mailto:cloudbe...@gmail.com] Sent: Tuesday, October 22, 2013 11:45 AM To: Artem Dmytrenko; yong sheng gong (gong...@unitedstack.com); OpenStack Development Mailing List; Vasudevan, Swaminathan (PNB Roseville) Subject: Re: Re: [openstack-dev] [Neutron] Distributed Virtual Router Discussion Hi Artem, Very happy to see more stackers working on this feature. : ) Note that the images in your document are badly corrupted - maybe my questions could already be answered by your diagrams. I met the same issue at first. Downloading the doc and open it locally may help. It works for me. Also, a wiki page for DVR/VDR feature is created, including some interesting performance test output. Thanks. https://wiki.openstack.org/wiki/Distributed_Router_for_OVS Best, Robin Wang From: Artem Dmytrenko Date: 2013-10-22 02:51 To: yong sheng gong \(gong...@unitedstack.com\); cloudbe...@gmail.com; OpenStack Development Mailing List Subject: Re: [openstack-dev] Distributed Virtual Router Discussion Hi Swaminathan. I work for a virtual networking startup called Midokura and I'm very interested in joining the discussion. We currently have distributed router implementation using existing Neutron API. Could you clarify why distributed vs centrally located routing implementation need to be distinguished? Another question is that are you proposing distributed routing implementation for tenant routers or for the router connecting the virtual cloud to the external network? The reason that I'm asking this question is because our company would also like to propose a router implementation that would eliminate a single point uplink failures. We have submitted a couple blueprints on that topic (https://blueprints.launchpad.net/neutron/+spec/provider-router-support, https://blueprints.launchpad.net/neutron/+spec/bgp-dynamic-routing) and would appreciate an opportunity to collaborate on making it a reality. Note that the images in your document are badly corrupted - maybe my questions could already be answered by your diagrams. Could you update your document with legible diagrams? Looking forward to further discussing this topic with you! Sincerely, Artem Dmytrenko On Mon, 10/21/13, Vasudevan, Swaminathan (PNB Roseville) swaminathan.vasude...@hp.com wrote: Subject: [openstack-dev] Distributed Virtual Router Discussion To: yong sheng gong (gong...@unitedstack.com) gong...@unitedstack.com, cloudbe...@gmail.com cloudbe...@gmail.com, OpenStack Development Mailing List (openstack-dev@lists.openstack.org) openstack-dev@lists.openstack.org Date: Monday, October 21, 2013, 12:18 PM Hi Folks, I am currently working on a blueprint for Distributed Virtual Router. If anyone interested in being part of the discussion please let me know. I have put together a first draft of my blueprint and have posted it on Launchpad for review. https://blueprints.launchpad.net/neutron/+spec/neutron-ovs-dvr Thanks. Swaminathan Vasudevan Systems Software Engineer (TC) HP Networking Hewlett-Packard 8000 Foothills Blvd M/S 5541 Roseville, CA - 95747 tel: 916.785.0937 fax: 916.785.1815 email: swaminathan.vasude...@hp.com -Inline Attachment Follows- ___ 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] [neutron] [ml2] Canceling today's ML2 meeting
Folks: A few of the key people cannot make today's ML2 meeting, so I'm going to cancel it today. If you haven't filed your design summit sessions on ML2, please do so by tomorrow! We have a list of them on the ML2 meeting page here [1] which we collected over the past two weeks. Also, Sukhdev has posted a review [2] of the updated Installation Guide which includes ML2 plugin information. Getting some eyes on that would be great as well! Thanks, and we'll see everyone at next week's Neutron ML2 meeting! Kyle [1] https://wiki.openstack.org/wiki/Meetings/ML2 [2] ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron] [ml2] Canceling today's ML2 meeting
Whoops, hit send too quickly. The Url for [2] is: https://review.openstack.org/#/c/51992/ On Oct 16, 2013, at 8:19 AM, Kyle Mestery (kmestery) kmest...@cisco.com wrote: Folks: A few of the key people cannot make today's ML2 meeting, so I'm going to cancel it today. If you haven't filed your design summit sessions on ML2, please do so by tomorrow! We have a list of them on the ML2 meeting page here [1] which we collected over the past two weeks. Also, Sukhdev has posted a review [2] of the updated Installation Guide which includes ML2 plugin information. Getting some eyes on that would be great as well! Thanks, and we'll see everyone at next week's Neutron ML2 meeting! Kyle [1] https://wiki.openstack.org/wiki/Meetings/ML2 [2] ___ 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] OVS Agent and VxLan UDP Ports
On Oct 8, 2013, at 4:01 AM, P Balaji-B37839 b37...@freescale.com wrote: Hi, Current OVS Agent is creating tunnel with dst_port as the port configured in INI file on Compute Node. If all the compute nodes on VXLAN network are configured for DEFAULT port it is fine. When any of the Compute Nodes are configured for CUSTOM udp port as VXLAN UDP Port, Then how does the tunnel will be established with remote IP. It is observed that the fan-out RPC message is not having the destination port information. Balaji, is this with the ML2 or OVS plugin? Regards, Balaji.P ___ 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] [ml2] devstack now defaults to the ML2 plugin
Folks: Just an update regarding the change to move devstack to default to the ML2 Neutron plugin instead of the OVS plugin. The patch [1] merged yesterday. Full tempest tests were passed with this, but just a heads up for those using devstack without specifying a Neutron plugin specifically. Thanks, Kyle [1] https://review.openstack.org/#/c/47837/ ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [neutron] [ml2] Next week's ML2 meeting
Hi! Next week at our regularly scheduled ML2 meeting [1] Wednesday at 1400 UTC we'll be spending the majority of the meeting brainstorming topics for the Icehouse Design Summit. I've added this to the agenda [2] with a couple of high-level items that have already come up. If you have ideas for how to improve ML2 in Icehouse, please add your ideas to the agenda and come prepared to discuss them at the meeting. We'll try to spend 20 minutes on bugs/documentation at the start and the remainder of the meeting discussing the enhancements for Icehouse. Thanks! Kyle [1] https://wiki.openstack.org/wiki/Meetings#ML2_Network_sub-team_meeting [2] https://wiki.openstack.org/wiki/Meetings/ML2 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] New Plug-in development for Neutron
On Sep 10, 2013, at 4:05 AM, P Balaji-B37839 b37...@freescale.com wrote: Hi, We have gone through the below link for new plug-in development. https://wiki.openstack.org/wiki/NeutronDevelopment#Developing_a_Neutron_Plugin Just want to confirm that is it mandatory to be Core Neutron Developer for submitting a new plug-in.? It's not necessary for you to have a core developer from your company, but you will need an existing core developer to support your plugin upstream. When you file the blueprint, let us know and we'll work with you on this one Balaji. Thanks, Kyle How do we get a reviewer for this like Can we approach any Core Neutron developer for review our plugin? We are developing new plug-in for our product and want to make it upstream to Neutron Core. Any information on this will be helpful!. Regards, Balaji.P ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Nova] nova-api won't start in devstack
On Aug 6, 2013, at 1:33 PM, Edgar Magana emag...@plumgrid.com wrote: I just downloaded devstack and I am getting this error: 2013-08-06 11:28:28.938 TRACE nova Traceback (most recent call last): 2013-08-06 11:28:28.938 TRACE nova File /usr/local/bin/nova-api, line 10, in module 2013-08-06 11:28:28.938 TRACE nova sys.exit(main()) 2013-08-06 11:28:28.938 TRACE nova File /opt/stack/nova/nova/cmd/api.py, line 51, in main 2013-08-06 11:28:28.938 TRACE nova server = service.WSGIService(api, use_ssl=should_use_ssl) 2013-08-06 11:28:28.938 TRACE nova File /opt/stack/nova/nova/service.py, line 311, in __init__ 2013-08-06 11:28:28.938 TRACE nova self.app = self.loader.load_app(name) 2013-08-06 11:28:28.938 TRACE nova File /opt/stack/nova/nova/wsgi.py, line 488, in load_app 2013-08-06 11:28:28.938 TRACE nova return deploy.loadapp(config:%s % self.config_path, name=name) 2013-08-06 11:28:28.938 TRACE nova File /usr/lib/python2.7/dist-packages/paste/deploy/loadwsgi.py, line 247, in loadapp 2013-08-06 11:28:28.938 TRACE nova return loadobj(APP, uri, name=name, **kw) 2013-08-06 11:28:28.938 TRACE nova File /usr/lib/python2.7/dist-packages/paste/deploy/loadwsgi.py, line 272, in loadobj 2013-08-06 11:28:28.938 TRACE nova return context.create() 2013-08-06 11:28:28.938 TRACE nova File /usr/lib/python2.7/dist-packages/paste/deploy/loadwsgi.py, line 710, in create 2013-08-06 11:28:28.938 TRACE nova return self.object_type.invoke(self) 2013-08-06 11:28:28.938 TRACE nova File /usr/lib/python2.7/dist-packages/paste/deploy/loadwsgi.py, line 144, in invoke 2013-08-06 11:28:28.938 TRACE nova **context.local_conf) 2013-08-06 11:28:28.938 TRACE nova File /usr/lib/python2.7/dist-packages/paste/deploy/util.py, line 56, in fix_call 2013-08-06 11:28:28.938 TRACE nova val = callable(*args, **kw) 2013-08-06 11:28:28.938 TRACE nova File /opt/stack/nova/nova/api/openstack/urlmap.py, line 160, in urlmap_factory 2013-08-06 11:28:28.938 TRACE nova app = loader.get_app(app_name, global_conf=global_conf) 2013-08-06 11:28:28.938 TRACE nova File /usr/lib/python2.7/dist-packages/paste/deploy/loadwsgi.py, line 350, in get_app 2013-08-06 11:28:28.938 TRACE nova name=name, global_conf=global_conf).create() 2013-08-06 11:28:28.938 TRACE nova File /usr/lib/python2.7/dist-packages/paste/deploy/loadwsgi.py, line 710, in create 2013-08-06 11:28:28.938 TRACE nova return self.object_type.invoke(self) 2013-08-06 11:28:28.938 TRACE nova File /usr/lib/python2.7/dist-packages/paste/deploy/loadwsgi.py, line 144, in invoke 2013-08-06 11:28:28.938 TRACE nova **context.local_conf) 2013-08-06 11:28:28.938 TRACE nova File /usr/lib/python2.7/dist-packages/paste/deploy/util.py, line 56, in fix_call 2013-08-06 11:28:28.938 TRACE nova val = callable(*args, **kw) 2013-08-06 11:28:28.938 TRACE nova File /opt/stack/nova/nova/api/auth.py, line 59, in pipeline_factory 2013-08-06 11:28:28.938 TRACE nova app = loader.get_app(pipeline[-1]) 2013-08-06 11:28:28.938 TRACE nova File /usr/lib/python2.7/dist-packages/paste/deploy/loadwsgi.py, line 350, in get_app 2013-08-06 11:28:28.938 TRACE nova name=name, global_conf=global_conf).create() 2013-08-06 11:28:28.938 TRACE nova File /usr/lib/python2.7/dist-packages/paste/deploy/loadwsgi.py, line 710, in create 2013-08-06 11:28:28.938 TRACE nova return self.object_type.invoke(self) 2013-08-06 11:28:28.938 TRACE nova File /usr/lib/python2.7/dist-packages/paste/deploy/loadwsgi.py, line 146, in invoke 2013-08-06 11:28:28.938 TRACE nova return fix_call(context.object, context.global_conf, **context.local_conf) 2013-08-06 11:28:28.938 TRACE nova File /usr/lib/python2.7/dist-packages/paste/deploy/util.py, line 56, in fix_call 2013-08-06 11:28:28.938 TRACE nova val = callable(*args, **kw) 2013-08-06 11:28:28.938 TRACE nova File /opt/stack/nova/nova/api/openstack/__init__.py, line 251, in factory 2013-08-06 11:28:28.938 TRACE nova return cls() 2013-08-06 11:28:28.938 TRACE nova File /opt/stack/nova/nova/api/openstack/compute/__init__.py, line 141, in __init__ 2013-08-06 11:28:28.938 TRACE nova super(APIRouterV3, self).__init__(init_only) 2013-08-06 11:28:28.938 TRACE nova File /opt/stack/nova/nova/api/openstack/__init__.py, line 323, in __init__ 2013-08-06 11:28:28.938 TRACE nova missing_apis=missing_core_extensions) 2013-08-06 11:28:28.938 TRACE nova CoreAPIMissing: Core API extensions are missing: set(['flavors', 'limits', 'consoles', 'servers', 'ips', 'server-metadata', 'extensions']) 2013-08-06 11:28:28.938 TRACE nova 2013-08-06 11:28:28.999 INFO nova.openstack.common.service [-] Parent process has died unexpectedly, exiting 2013-08-06 11:28:28.999 INFO nova.wsgi [-] Stopping WSGI server. My localrc is: disable_service n-net enable_service q-svc enable_service q-agt
[openstack-dev] [neutron] [ml2] [devstack] Per MechanismDriver configuration for ML2 in devstack
Neutron and devstack folks: I've written up some notes [1] on how I'd like to add per-MechanismDriver support into devstack for ML2. This will be very nice to have as the number of ML2 MechanismDrivers increase. My approach for this will allow for complex configurations via localrc variables with very minimal changes to the existing ML2 devstack code (likely a handful of lines). I'd appreciate some reviews of this. I've filed a BP in devstack [2] for this as well, and I should have an initial implementation of this by tomorrow. We'll discuss this in more detail at the ML2 sub-team meeting tomorrow. Thanks, Kyle [1] https://docs.google.com/document/d/1vvfey4SCFA5Ih9e6VUdjnRAVj6YIusfXlbPT8yxVOvY/edit?usp=sharing [2] https://blueprints.launchpad.net/devstack/+spec/ml2-devstack-mechanism-driver ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [neutron] [ml2] Configuration file sections for MechanismDrivers
While working on the OpenDaylight ML2 MechanismDriver, one thing which cropped up was configuration file options for MechanismDrivers and were those should be stored. I was initially of the opinion we should put all configuration sections into the ml2 configuration file, but this could get crowded, and would make the sample one confusing. The other option is to create them in separate configuration files per-MechanismDriver, and pass those on the command line when starting the Neutron server. This keeps things tidy from the perspective that you would only need to modify the ones you plan to run with Ml2. So my question is, which route do people prefer here? I'll have to make some changes to the ML2 devstack configuration to support this no matter which way we go forward, as it currently doesn't support the concept of separate configuration sections for MechanismDrivers. Thanks, Kyle ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] Network Information Sharing with OpenFlow Controller
On Aug 4, 2013, at 1:20 AM, P Balaji-B37839 b37...@freescale.com wrote: Hi, Anyone in the community is working on the OpenStack Controller and OpenFlow Controller Integration for Network and VM Information sharing. High level approach on this is attached to this mail as PPT. Idea is to share the Network and VM information to OpenFlow Controller for DC Network OpenFlow Switches. Based on this Network/VM information OpenFlow Controller can add flows to these OF-Switches based on the shared Network/Port Information. This use case is for Data Centre Networks where OpenStack Controller deployed for SDN Network. Any comments or thoughts on this are appreciated. Hi Balaji.P: There is already integration with Ryu [1] which has been upstream as a Quantum/Neutron plugin since Folsom. And we are currently working on integration with OpenDaylight [2] as well. Both of those are capable of being OpenFlow controllers. Can you explain how your design is different or could build upon either of those? Thanks, Kyle [1] https://github.com/osrg/ryu/wiki/OpenStack [2] http://www.opendaylight.org/ Regards, Balaji.P -Original Message- From: P Balaji-B37839 Sent: Friday, August 02, 2013 4:41 PM To: OpenStack Development Mailing List Cc: Addepalli Srini-B22160; B Veera-B37207; Mannidi Purandhar Sairam-B39209; Lingala Srikanth Kumar-B37208; Somanchi Trinath-B39208; Vetcha Sarat Babu-B37147 Subject: [openstack-dev] [Neutron] OpenStack Controller and OpenFlow Controller Network Information Sharing Hi, Please find that attachment to this mail as high level architecture of OpenStack and OpenFlow Controller Integration for Network/VM/Network Services Information sharing, We are planning to publish blue-print for this. Let us know your comments and suggestions. Regards, Balaji.P OSC-OFC-Integration.pptx___ 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] OVS Agent and OF bridges
On Aug 2, 2013, at 7:02 AM, Addepalli Srini-B22160 b22...@freescale.com wrote: Hi, As I understand, current OVS Quantum agent is assuming that there are two Openflow bridges (br-int and br-tun). “br_tun”, I think, is introduced to take care of overlay tunnels. With flow based tunnel selection and tunnel parameters definition, I think br-tun is no longer required. Removal of br-tun increases the performance as one less OF bridge in the packet path. Is there any interest in community to remove br-tun? If so, we can work on it and provide a blue print and the code. Thanks Srini Hi Srini: I am very interested in this, and I think this would be a nice performance improvement. We'd have to maintain backwards compatibility with the existing code, since only version of OVS = 1.10 have flow-based tunneling code. If you want, I'd be happy to review your BP and code for this, or even work with you on this. 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
Re: [openstack-dev] [Openstack] devstack with neutron/quantum
On Jul 31, 2013, at 2:28 PM, Remo Mattei r...@mattei.org wrote: Hi everyone, I wonder if anyone has seen this error where neutron does not start. here is the error I get with devstack. Any suggestions are welcomed. Remo remo@openstack-ub:~/devstack$ cd /opt/stack/neutron python = /usr/local/bin/neutron-l3-agent --config-file /etc/neutron/neutron.conf = --config-file=3D/etc/neutron/l3_agent.ini || touch = /opt/stack/status/stack/q-l3.failure 2013-07-31 13:05:07.698 18378 INFO neutron.common.config [-] Logging = enabled! 2013-07-31 13:05:07.703 18378 ERROR neutron.common.legacy [-] Skipping = unknown group key: firewall_driver 2013-07-31 13:05:07.703 18378 DEBUG neutron.common.utils [-] Reloading = cached file /etc/neutron/policy.json read_cached_file = /opt/stack/neutron/neutron/common/utils.py:55 2013-07-31 13:05:07.704 18378 DEBUG neutron.policy [-] loading policies = from file: /etc/neutron/policy.json _set_rules = /opt/stack/neutron/neutron/policy.py:88 2013-07-31 13:05:07.705 18378 CRITICAL neutron [-] 2013-07-31 13:05:07.705 18378 TRACE neutron Traceback (most recent call = last): 2013-07-31 13:05:07.705 18378 TRACE neutron File = /usr/local/bin/neutron-l3-agent, line 10, in module 2013-07-31 13:05:07.705 18378 TRACE neutron sys.exit(main()) 2013-07-31 13:05:07.705 18378 TRACE neutron File = /opt/stack/neutron/neutron/agent/l3_agent.py, line 833, in main 2013-07-31 13:05:07.705 18378 TRACE neutron = manager=3D'neutron.agent.l3_agent.L3NATAgentWithStateReport') 2013-07-31 13:05:07.705 18378 TRACE neutron File = /opt/stack/neutron/neutron/service.py, line 204, in create 2013-07-31 13:05:07.705 18378 TRACE neutron = periodic_fuzzy_delay=3Dperiodic_fuzzy_delay) 2013-07-31 13:05:07.705 18378 TRACE neutron File = /opt/stack/neutron/neutron/service.py, line 137, in __init__ 2013-07-31 13:05:07.705 18378 TRACE neutron self.manager =3D = manager_class(host=3Dhost, *args, **kwargs) 2013-07-31 13:05:07.705 18378 TRACE neutron File = /opt/stack/neutron/neutron/agent/l3_agent.py, line 756, in __init__ 2013-07-31 13:05:07.705 18378 TRACE neutron = super(L3NATAgentWithStateReport, self).__init__(host=3Dhost, conf=3Dconf) 2013-07-31 13:05:07.705 18378 TRACE neutron File = /opt/stack/neutron/neutron/agent/l3_agent.py, line 213, in __init__ 2013-07-31 13:05:07.705 18378 TRACE neutron = self._destroy_router_namespaces(self.conf.router_id) 2013-07-31 13:05:07.705 18378 TRACE neutron File = /opt/stack/neutron/neutron/agent/l3_agent.py, line 228, in = _destroy_router_namespaces 2013-07-31 13:05:07.705 18378 TRACE neutron root_ip =3D = ip_lib.IPWrapper(self.root_helper) 2013-07-31 13:05:07.705 18378 TRACE neutron File = /opt/stack/neutron/neutron/agent/linux/ip_lib.py, line 82, in __init__ 2013-07-31 13:05:07.705 18378 TRACE neutron namespace=3Dnamespace) 2013-07-31 13:05:07.705 18378 TRACE neutron File = /opt/stack/neutron/neutron/agent/linux/ip_lib.py, line 39, in __init__ 2013-07-31 13:05:07.705 18378 TRACE neutron self.force_root =3D = cfg.CONF.ip_lib_force_root 2013-07-31 13:05:07.705 18378 TRACE neutron File = /opt/stack/oslo.config/oslo/config/cfg.py, line 1626, in __getattr__ 2013-07-31 13:05:07.705 18378 TRACE neutron raise AttributeError 2013-07-31 13:05:07.705 18378 TRACE neutron AttributeError 2013-07-31 13:05:07.705 18378 TRACE neutron= I'm seeing this error with the latest neutron and devstack as well, and I haven't figured out a way around it now. Moving this to the openstack-dev list to get some additional eyes on this as well. Kyle ___ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openst...@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [devstack] [neutron] [ml2] ML2 is now fully supported in devstack, please go forth with trying it out!
It is with great news I'm happy to report the Modular Layer 2 Neutron plugin [1] is now fully supported in devstack. Instructions for configuring devstack with ML2 are located here [2]. The ML2 team would greatly appreciate people trying out ML2 with Neutron and devstack and reporting any issues found to on the mailing list or on #openstack-neutron in freenode. ML2 will work in VLAN mode, and also in GRE or VXLAN tunnel mode. VXLAN tunnel mode is supported using Open vSwitch = 1.10, including the upstream Open vSwitch kernel module. Thanks! Kyle [1] https://wiki.openstack.org/wiki/Neutron/ML2 [2] https://wiki.openstack.org/wiki/Neutron/ML2#Using_ML2_in_Devstack ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Revert Pass instance host-id to Quantum using port bindings extension.
On Jul 18, 2013, at 5:16 PM, Aaron Rosen aro...@nicira.com wrote: Hi, I wanted to raise another design failure of why creating the port on nova-compute is bad. Previously, we have encountered this bug (https://bugs.launchpad.net/neutron/+bug/1160442). What was causing the issue was that when nova-compute calls into quantum to create the port; quantum creates the port but fails to return the port to nova and instead timesout. When this happens the instance is scheduled to be run on another compute node where another port is created with the same device_id and when the instance boots it will look like it has two ports. This is still a problem that can occur today in our current implementation (!). I think in order to move forward with this we'll need to compromise. Here is my though on how we should proceed. 1) Modify the quantum API so that mac addresses can now be updated via the api. There is no reason why we have this limitation (especially once the patch that uses dhcp_release is merged as it will allow us to update the lease for the new mac immediately). We need to do this in order for bare metal support as we need to match the mac address of the port to the compute node. I don't understand how this relates to creating a port through nova-compute. I'm not saying this is a bad idea, I just don't see how it relates to the original discussion point on this thread around Yong's patch. 2) move the port-creation from nova-compute to nova-api. This will solve a number of issues like the one i pointed out above. This seems like a bad idea. So now a Nova API call will implicitly create a Neutron port? What happens on failure here? The caller isn't aware the port was created in Neutron if it's implicit, so who cleans things up? Or if the caller is aware, than all we've done is move an API the caller would have done (nova-compute in this case) into nova-api, though the caller is now still aware of what's happening. 3) For now, i'm okay with leaving logic on the compute node that calls update-port if the port binding extension is loaded. This will allow the vif type to be correctly set as well. And this will also still pass in the hostname the VM was booted on? To me, this thread seems to have diverged a bit from the original discussion point around Yong's patch. Yong's patch makes sense, because it's passing the hostname the VM is booted on during port create. It also updates the binding during a live migration, so that case is covered. Any change to this behavior should cover both those cases and not involve any sort of agent polling, IMHO. Thanks, Kyle Thoughts/Comments? Thanks, Aaron On Mon, Jul 15, 2013 at 2:45 PM, Aaron Rosen aro...@nicira.com wrote: On Mon, Jul 15, 2013 at 1:26 PM, Robert Kukura rkuk...@redhat.com wrote: On 07/15/2013 03:54 PM, Aaron Rosen wrote: On Sun, Jul 14, 2013 at 6:48 PM, Robert Kukura rkuk...@redhat.com mailto:rkuk...@redhat.com wrote: On 07/12/2013 04:17 PM, Aaron Rosen wrote: Hi, On Fri, Jul 12, 2013 at 6:47 AM, Robert Kukura rkuk...@redhat.com mailto:rkuk...@redhat.com mailto:rkuk...@redhat.com mailto:rkuk...@redhat.com wrote: On 07/11/2013 04:30 PM, Aaron Rosen wrote: Hi, I think we should revert this patch that was added here (https://review.openstack.org/#/c/29767/). What this patch does is when nova-compute calls into quantum to create the port it passes in the hostname on which the instance was booted on. The idea of the patch was that providing this information would allow hardware device vendors management stations to allow them to segment the network in a more precise manager (for example automatically trunk the vlan on the physical switch port connected to the compute node on which the vm instance was started). In my opinion I don't think this is the right approach. There are several other ways to get this information of where a specific port lives. For example, in the OVS plugin case the agent running on the nova-compute node can update the port in quantum to provide this information. Alternatively, quantum could query nova using the port.device_id to determine which server the instance is on. My motivation for removing this code is I now have the free cycles to work on https://blueprints.launchpad.net/nova/+spec/nova-api-quantum-create-port discussed here (http://lists.openstack.org/pipermail/openstack-dev/2013-May/009088.html) . This was about moving the quantum port creation from the
[openstack-dev] [neutron] [ml2] [devstack] ML2 devstack changes for tunneling
I've pushed out a review [1] to enable support for setting additional ML2 options when running with devstack. Since H2, ML2 has now added support for both GRE and VXLAN tunnels, and the patch below allows for this configuration when running with devstack. Feedback from folks on the Neutron ML2 sub-team and devstack developers would be appreciated! Thanks! Kyle [1] https://review.openstack.org/37963 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Revert Pass instance host-id to Quantum using port bindings extension.
On Jul 19, 2013, at 6:01 PM, Aaron Rosen aro...@nicira.com wrote: On Fri, Jul 19, 2013 at 3:37 PM, Ian Wells ijw.ubu...@cack.org.uk wrote: [arosen] - sure, in this case though then we'll have to add even more queries between nova-compute and quantum as nova-compute will need to query quantum for ports matching the device_id to see if the port was already created and if not try to create them. The cleanup job doesn't look like a job for nova-compute regardless of the rest. Moving the create may for other reasons be a good idea (because compute would *always* deal with ports and *never* with networks - a simpler API) - but it's nothing to do with solving this problem. [arosen] - It does solve this issue because it moves the quantum port-create calls outside of the retry schedule logic on that compute node. Therefore if the port fails to create the instance goes to error state. Moving networks out of the nova-api will also solve this issue for us as the client then won't rely on nova anymore to create the port. I'm wondering if creating an additional network_api_class like nova.network.quantumv2.api.NoComputeAPI is the way to prove this out. Most of the code in there would inherit from nova.network.quantumv2.api.API . OK, so if we were to say that: - nova-api creates the port with an expiry timestamp to catch orphaned autocreated ports I don't think we want to put a timestamp there. We can figure out which ports are orphaned by checking if a port's device_id in quantum is still an active instance_id in nova (which currently isn't true but would be if the port-create is moved out of compute to api) and that device_owner is nova:compute. - nova-compute always uses port-update (or, better still, have a distinct call that for now works like port-update but clearly represents an attach or detach and not a user-initiated update, improving the plugin division of labour, but that can be a separate proposal) and *never* creates a port; attaching to an apparently-attached port attached to the same instance should ensure that a previous attachment is destroyed, which should cover the multiple-schedule lost-reply case agree - nova-compute is always talked to in terms of ports, and never in terms of networks (a big improvement imo) agree! - nova-compute attempts to remove autocreated ports on detach - a cleanup job in nova-api (or nova-conductor?) cleans up expired autocreated ports with no attachment or a broken attachment (which would catch failed detachments as well as failed schedules) how does that work for people? It seems to improve the internal interface and the transactionality, it means that there's not the slightly nasty (and even faintly race-prone) create-update logic in nova-compute, it even simplifies the nova-compute interface - though we would need to consider how an upgrade path would work, there; newer API with older compute should work fine, the reverse not so much. I agree, ensuring backwards compatibility if the compute nodes are updated and not the api nodes would be slightly tricky. I'd hope we could get away with releasing noting that you need to update the api nodes first. This all sounds good to me as well. And release noting the update procedure seems reasonable for upgrades as well. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Revert Pass instance host-id to Quantum using port bindings extension.
I agree with Andre's concerns around the implications of polling in what Aaron is proposing, and in fact, this is one reason the existing change is so nice. The ML2 sub-team talked about this at a recent meeting, and we liked the approach which Yong had taken with the patch. But as Andre says, we're all for working to simplify things, keeping the goals he mentioned in mind. What are your thoughts Aaron? Thanks, Kyle On Jul 11, 2013, at 8:44 PM, Andre Pech ap...@aristanetworks.com wrote: Hey Aaron, As an interested party in the change, figured I'd take a stab at responding. I've talked with people at BigSwitch and Cisco about this change, so I know others are interested in this as well, but I'll let them give their perspective. At a high level, our goal at Arista is similar to what you mention. We want to integrate the provisioning of the physical network within Neutron in conjunction with the virtual network. We have no interest in controlling the virtual switch layer, and so we'd like to do this in a way that does not tie us to any particular virtual switching technology (should work just as well with OVS, LinuxBridge, or whatever future virtual switch technology a customer may choose to use). And it needs the chance to be inline - the provisioning of the physical network has to happen alongside the virtual network, so that failures to provision the physical network can be propogated to the user in the same way as a failure to set up the virtual network. The thing I like most about the current solution is that it's event-driven. There's no polling of the information out of band from nova (I'm not sure how accepted it would be to poll this info directly from neutron, which would then force you to do it from an outside system). It also doesn't require any coordination with agents running on the compute side (in line with the goal of working across multiple virtual switching technologies). I'd be really happy with another solution, but I'd be great to see those properties preserved. I have reservations about the alternatives you're proposing. Happy to hop on a call with other interested parties to come up with a better middleground that allows you to do the simplification you're proposing while still giving Neutron an explicit hook to learn about the host a VM was placed on. Andre On Thu, Jul 11, 2013 at 1:30 PM, Aaron Rosen aro...@nicira.com wrote: Hi, I think we should revert this patch that was added here (https://review.openstack.org/#/c/29767/). What this patch does is when nova-compute calls into quantum to create the port it passes in the hostname on which the instance was booted on. The idea of the patch was that providing this information would allow hardware device vendors management stations to allow them to segment the network in a more precise manager (for example automatically trunk the vlan on the physical switch port connected to the compute node on which the vm instance was started). In my opinion I don't think this is the right approach. There are several other ways to get this information of where a specific port lives. For example, in the OVS plugin case the agent running on the nova-compute node can update the port in quantum to provide this information. Alternatively, quantum could query nova using the port.device_id to determine which server the instance is on. My motivation for removing this code is I now have the free cycles to work on https://blueprints.launchpad.net/nova/+spec/nova-api-quantum-create-port discussed here (http://lists.openstack.org/pipermail/openstack-dev/2013-May/009088.html) . This was about moving the quantum port creation from the nova-compute host to nova-api if a network-uuid is passed in. This will allow us to remove all the quantum logic from the nova-compute nodes and simplify orchestration. Thoughts? Best, Aaron ___ 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] Embrane's Neutron Plugin
On Jul 10, 2013, at 1:17 PM, Salvatore Orlando sorla...@nicira.com wrote: Hi Ivar, thanks for your interest in Openstack and Neutron. A few replies inline; I hope you'll find them useful. Salvatore On 10 July 2013 02:40, Ivar Lazzaro i...@embrane.com wrote: Hi, My name is Ivar Lazzaro, I’m an Italian developer currently employed at Embrane. Embrane provides L3 to L7 network services, (including routing, load balancing, SSL offloads, firewalls and IPsec VPNs), and we have developed a Neutron plugin that we would like to share and contribute to Openstack[1]. That would be great! the current policy for Neutron plugins is that each plugin should have a member of the core team which will act as a 'maintainer'; this figure is not required to be an 'expert' of the specific plugin technology. His duties are mainly those of keeping track of bugs/blueprints, review code, and interact with the developers. My experience with OpenStack started with the Essex edition, which I deployed and managed as a user. Embrane leverages any existing form of L2 to offer connectivity at L3 and above, and therefore our interest in contributing to OpenStack grew as L3 (and above) capabilities started to be added to Neutron, leading to the realization of a Neutron plugin. I'd like to talk about it with you before blindly requesting a review, and get your feedback and advice in order to improve it at the most! Sounds a very sensible approach, since we're already halfway through the release cycle, and finding resources for reviewing code might not be the easiest thing. The idea is to provide L3 connectivity in Openstack through our software platform, called heleos, obviously using a plugin to follow the Neutron workflow.Since we don't provide L2 connectivity (which is part of the core APIs as well) our plugin is going to work together with one of the existing, which will manage L2 connectivity and share all the information needed. Therefore, whenever a user chooses to use Embrane's Neutron plugin, he specifies one of the supported existing plugins in the configuration file, and L2 connectivity will be provided by that specific choice. At the current state, for instance, our plugin is able to work with the OpenVSwitch's so that: -create_network() will call OVS plugin; -create_port() will call OVS plugin; -crate_router() will call Embrane's which will use knowledge from the OVS plugin in order to provide L3 connectivity. It looks like your plugin is pretty much a derivative of the OVS plugin, which replaces the L3 agent with Embrane's heleos. I think this approach makes some sense, but in the medium/long term you would like to be able to run your plugin on top of any L2 plugin. There is a Neutron blueprint for that, and that is https://blueprints.launchpad.net/neutron/+spec/quantum-l3-routing-plugin That blueprint is unfortunately a bit stuck at the moment. It would be good for the whole community to understand whether we can actually still merge it during the Havana timeframe. I believe Bob is going to resurrect this work now, though he's on PTO at the moment. Expect a new version of this relatively soon Salvatore, and I was going to let Ivar know this work that Bob is doing would allow the Helios platform to work with any L2 plugin. Thanks, Kyle and so forth... The calls can be asynchronous (using Router status in a way similar to the LBaaS extension). Without going too much into details, that's all about the L3 plugin that we would like to share. We are also interested in sharing a LBaaS service plugin, but I'll do a different blueprint for that one. I think it won't harm pushing your code as a draft on gerrit. All your feedback and comments are welcome :) Thanks, Ivar. [1] https://blueprints.launchpad.net/neutron/+spec/embrane-neutron-plugin ___ 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] Campus Network Blueprint
On Jul 9, 2013, at 11:18 AM, Filipe Manco filipe.ma...@gmail.com wrote: Hi all, Just published a blueprint for some work I'm starting right now. I would appreciate if someone can take a look and give some comments. https://blueprints.launchpad.net/neutron/+spec/campus-network Thank you Hi Filipe: At first glance, there appears to be a lot of overlap with ML2 here. Have you looked at the ML2 blueprints, and the specific use case of multi-segment networks? The ML2 team is working hard to close ML2 blueprints in H2/H3, perhaps some of your ideas could be incorporated here? Here is the ML2 Meeting page which has links to the blueprints we're tracking: https://wiki.openstack.org/wiki/Meetings/ML2 Thanks, Kyle Filipe Manco http://about.me/fmanco ___ 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] [jenkins] [tempest] Trouble with a patch
Also the ML2 Mechansim Driver review from Andre: https://review.openstack.org/#/c/33201/ http://logs.openstack.org/33201/15/check/gate-tempest-devstack-vm-neutron/1140/console.html Thanks, Kyle On Jul 9, 2013, at 5:12 PM, Nachi Ueno na...@ntti3.com wrote: Hi Kyle I'm facing same trouble also. [1] https://review.openstack.org/#/c/33148/ [2] http://logs.openstack.org/33148/19/check/gate-tempest-devstack-vm-neutron/1144/console.html Thanks Nachi 2013/7/9 Kyle Mestery (kmestery) kmest...@cisco.com: I'm currently hitting issues with a patch [1] not passing Jenkins due to a Horizon python-keystonclient dependency issue in no way related to my change. I've rerun the patch twice, and it still fails the same way. See the bottom of the console output here [2]. I need some guidance here, as this particular error doesn't appear to be related at all to my change and is blocking my patch. Thanks, Kyle [1] https://review.openstack.org/#/c/35384/ [2] http://logs.openstack.org/35384/8/check/gate-tempest-devstack-vm-neutron/1136/console.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
[openstack-dev] [neutron] [ml2] ML2 Sub-Team Meeting tomorrow
Just a reminder, we have our weekly ML2 sub team meeting Wednesday at 1400UTC. The agenda is on the meeting page here: https://wiki.openstack.org/wiki/Meetings/ML2 We have a number of ML2 related blueprints in review with a hope of getting them in for H2 tomorrow, we'll focus on those in the meeting tomorrow for the most part. Thanks! Kyle ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] Campus Network Blueprint
On Jul 9, 2013, at 8:40 PM, Filipe Manco filipe.ma...@gmail.com wrote: Hi Kyle I already looked at the blueprints and I want to integrate my work with ML2, mainly because I want users to able to keep the traditional networking models working in parallel (and I think ML2 is the best way to do this comparing with the meta plugin). To be honest, the integration with Neutron and the ML2 was what took most of the time when writing the blueprint, but although I talk about it on the blueprint I still not sure about the best way to do it. About the concept of segments I don't think they fit. From what I understand a segment, in the context of ML2, represents part of the virtual network that uses some technology to connect a set of VMs, so if I delete a segment those VMs will loose connectivity. In the context of my blueprint a segment (or cSegment as I called it) represents a domain where I can create virtual links across a set of nodes. If I delete a cSegment that doesn't mean any VM will loose connectivity, what will happen is that the network is remapped and the traffic will cross another cSegment or another set of cSegments. I think what you've mentioned here is valid, yes, and is a slight deviation between the way segments in ML2 work on your cSegments. It looks like we would need to add your new constructs into the ML2 API to achieve what you're looking for. Something that I would like you (or other guys from ML2) to comment is how to integrate new operations (beyond the ones related with the base data model) in the ML2 interfaces. The MechanismDriver interface supports operations on ports and networks, but as you can see I have new entities. My idea is that there should be no changes to the original interfaces, because this are specific to a type of network. What do you think? I'll have a look at this tomorrow and give you more detailed feedback. If you want, you can join us in the ML2 meeting at 1400UTV meeting on #openstack-meeting and I'll save some time at the end of the meeting to discuss your blueprint. Thanks! Kyle It would help me if you have the time to take a look at the blueprint and comment on the ML2 parts. Thanks for your help! Filipe Manco http://about.me/fmanco 2013/7/9 Kyle Mestery (kmestery) kmest...@cisco.com On Jul 9, 2013, at 11:18 AM, Filipe Manco filipe.ma...@gmail.com wrote: Hi all, Just published a blueprint for some work I'm starting right now. I would appreciate if someone can take a look and give some comments. https://blueprints.launchpad.net/neutron/+spec/campus-network Thank you Hi Filipe: At first glance, there appears to be a lot of overlap with ML2 here. Have you looked at the ML2 blueprints, and the specific use case of multi-segment networks? The ML2 team is working hard to close ML2 blueprints in H2/H3, perhaps some of your ideas could be incorporated here? Here is the ML2 Meeting page which has links to the blueprints we're tracking: https://wiki.openstack.org/wiki/Meetings/ML2 Thanks, Kyle Filipe Manco http://about.me/fmanco ___ 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] [neutron] [ml2] Review of OVS Agent Changes Document
Folks: I've written up some design notes [1] on the changes I'm making to the OVS Agent, with the end result being something which functions with both the existing standalone OVS Plugin, as well as in the context of ML2 where we can support multiple plugins and tunneling technologies concurrently. This came out of the review for the tunnel_types change [2]. Please review and provide feedback. I'm going to go all the way in the review mentioned here and deprecate enable_tunneling in the server, and and pass down the tunnel_type from server to agent, and validate this on the agent itself. Thanks! Kyle [1] https://docs.google.com/a/mestery.com/document/d/1NT3JVn2lNk_Hp7lP7spc3ysWgSyHa4V0pYELAiePD1s/edit#heading=h.4grgudkj8ei3 [2] https://review.openstack.org/#/c/33107/ ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [networking] Changes to the OVS agent tunneling
Fixed, sorry about that! On Jul 2, 2013, at 11:14 AM, Edgar Magana emag...@plumgrid.com wrote: Hi Kyle, It seems that the document is locked, could you provide the access code? Thanks, Edgar On 7/2/13 8:32 AM, Kyle Mestery (kmestery) kmest...@cisco.com wrote: I've been spending a fair amount of time working with the OVS agent recently, and I've written up a small Google Document [1] detailing the end goal of all of this work. The short story is that I am introducing changes into the OVS agent to add support for multiple tunnel_types when the agent is run with the ML2 plugin. The ML2 plugin will support both GRE and VXLAN tunnels at the same time, for example. I'd appreciate feedback from folks on this document. Thanks, Kyle [1] https://docs.google.com/a/mestery.com/document/d/1NT3JVn2lNk_Hp7lP7spc3ysW gSyHa4V0pYELAiePD1s/edit?usp=sharing ___ 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] Issues with git review for a dependent commit
On Jul 2, 2013, at 4:18 PM, Salvatore Orlando sorla...@nicira.com wrote: Kyle, is this commit basically a rebase on top of 91e0850? In that case the diff with the previous patchset would be empty. I recall I had a similar issue; I just tweaked a comment line in my commit to let gerrit think it was a different patchset. Salvatore Hi Salvatore: Actually, no. 91e0850 is actually the implementation for bp/ml2-gre, and my commit implements bp/ml2-vxlan. Since there was some shared code, the first commit implemented that, thus requiring my commit to be dependent on this other commit. Thanks, Kyle On 2 July 2013 23:05, Kyle Mestery (kmestery) kmest...@cisco.com wrote: On Jul 2, 2013, at 3:52 PM, Jeremy Stanley fu...@yuggoth.org wrote: On 2013-07-02 20:14:35 + (+), Kyle Mestery (kmestery) wrote: I'm trying to submit a gerrit review for a commit which is dependent on another person's commit [1]. [...] ! [remote rejected] HEAD - refs/publish/master/bp/ml2-vxlan (no changes made) [...] I want to say I've seen this recently when someone copy-pasted from one commit message to another and included an existing Change-Id header, so you might amend and clear that line from the top commit before reviewing again (it'll get regenerated fresh). Thanks Jeremy, this was it! For some reason, the top commit had the same Change-ID as the bottom commit. Once I cleared it, I was able to push, though with the issue seen here: [kmestery@fedora-mac quantum]$ git review -R You have more than one commit that you are about to submit. The outstanding commits are: 6cca2cf (HEAD, bp/ml2-vxlan) Add VXLAN tunneling support for the ML2 plugin 91e0850 Add gre tunneling support for the ML2 plugin Is this really what you meant to do? Type 'yes' to confirm: yes Enter passphrase for key '/home/kmestery/.ssh/id_rsa': remote: Resolving deltas: 100% (32/32) remote: Processing changes: new: 1, updated: 1, refs: 1, done remote: remote: New Changes: remote: https://review.openstack.org/35384 remote: To ssh://mest...@review.openstack.org:29418/openstack/quantum.git ! [remote rejected] HEAD - refs/publish/master/bp/ml2-vxlan (no changes made) error: failed to push some refs to 'ssh://mest...@review.openstack.org:29418/openstack/quantum.git' [kmestery@fedora-mac quantum]$ In addition, my commit seen at the review URL above does not show the dependancy. Any ideas now? Thanks! Kyle If that doesn't work, could you push your working branch to somewhere I could pull from so I can test it myself? Feel free to follow up with me in private or open a bug against git-review on Launchpad if you don't want to run through troubleshooting back-and-forth on the list.o ___ 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
