Re: [openstack-dev] [python-neutronclient][neutron] sub-project client extensions
I started down the path of making a python-neutronclient extension, but got stuck on the lack of support for child resource extensions as described here https://bugs.launchpad.net/python-neutronclient/+bug/1446428. I submitted a bugfix here https://review.openstack.org/#/c/202597/?. Amir From: Fawad Khaliq fa...@plumgrid.com Sent: Tuesday, August 4, 2015 6:10 AM To: OpenStack Development Mailing List (not for usage questions) Subject: [openstack-dev] [python-neutronclient][neutron] sub-project client extensions Folks, In networking-plumgrid project, we intend to implement client side for some of the vendor specific extensions. Looking at the current implementation for client side for some vendors, I see the code is part of python-neutronclient tree [1]. I do see this change [2] talking about a way to load extensions through entry points, however, I could not find any example extension module. Has anyone gone through the route of implementing out of tree extensions for Neutron client, which extend python-neutronclient shell and load at run/install time? With decomposition phase II, it makes sense to keep the client side in the respective projects as well. [1] https://github.com/openstack/python-neutronclient/tree/master/neutronclient/neutron/v2_0 [2] https://review.openstack.org/#/c/148318/16 Thanks, Fawad Khaliq __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [RFC] Kilo release cycle schedule proposal
Instead of moving the Kilo cycle a week later (April 23 - April 30), would it be possible to move the L design summit a week ahead (May 18-22 - May 11-15). This would extend the L-cycle a week. Additionally, this would also help with return travel as the following Monday is Memorial Day; I'd expect return flights starting on Friday to be worse for the weekend of the 22nd, but I don't have data on that. Amir Sadoughi From: Thierry Carrez [thie...@openstack.org] Sent: Tuesday, September 23, 2014 9:54 AM To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [RFC] Kilo release cycle schedule proposal Sean Dague wrote: On 09/23/2014 02:56 AM, Thierry Carrez wrote: Hi everyone, Rather than waste a design summit session about it, I propose we review the proposed Kilo release cycle schedule on the mailing-list. See attached PDF for a picture of the proposal. The hard date the proposal is built around is the next (L) Design Summit week: May 18-22. That pushes back far into May (the farthest ever). However the M design summit being very likely to come back in October, the release date was set to April 23 to smooth the difference. That makes 3 full weeks between release and design summit (like in Hong-Kong), allowing for an official off-week on the week of May 4-8. Honestly, the off-week really isn't. If we're going to talk about throwing a stall week into the dev cycle for spacing, I'd honestly rather just push the release back, and be clear to folks that the summer cycle is going to be shorter. The off-week I think just causes us to lose momentum. Sure. I'm not adding it for the beauty of it. See below. The rest of the proposal is mostly a no-brainer. Like always, we allow a longer time for milestone 2, to take into account the end-of-year holidays. That gives: Kilo Design Summit: Nov 4-7 Kilo-1 milestone: Dec 11 The one thing that felt weird about the cadence of the 1st milestone in Havana last year was that it was super start / stop. Dec 11 means that we end up with 2 weeks until christmas, so many people are starting to wind down. My suggestion would be to push K1 to Dec 18, because I think you won't get much K2 content landed that week anyway. For US people at least this would change the Dec cadence from: * Holiday Week - Nov 28 is thanksgiving * Dev Week * Milestone Week * Dev Week * sort of Holiday Week * Holiday Week To: * Holiday Week * Dev Week * Dev Week * Milestone Week * sort of Holiday Week * Holiday Week Which I feel is going to get more done. If we take back the off week, we could just shift everything back a week, which makes K2 less split by christmas. So we /could/ do: Kilo Design Summit: Nov 4-7 Kilo-1 milestone: Dec 18 Kilo-2 milestone: Feb 5 Kilo-3 milestone, feature freeze: March 19 2015.1 (Kilo) release: Apr 30 L Design Summit: May 18-22 The main issue is that it would make a *very* short L cycle. Our best bet for the M design summit is the week of October 26, so L release would be Oct 8 or Oct 15. I placed Kilo release on April 23 on the original plan to try to limit the impact. If you think shorter is not an issue, I guess that's a valid option. -- Thierry Carrez (ttx) ___ 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] make mac address updatable: which plugins?
I agree with Kevin here. Just a note, don't bother with openvswitch and linuxbridge plugins as they are marked for deletion this cycle, imminently (already deprecated)[0]. Amir [0] http://eavesdrop.openstack.org/meetings/networking/2014/networking.2014-08-04-21.02.html Announcements 2e. From: Kevin Benton [blak...@gmail.com] Sent: Tuesday, August 05, 2014 2:40 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [neutron] make mac address updatable: which plugins? How are you implementing the change? It would be good to get to see some code in a review to get an idea of what needs to be updated. If it's just a change in the DB base plugin, just let those changes propagate to the plugins that haven't overridden the inherited behavior. On Tue, Aug 5, 2014 at 1:28 PM, Charles Carlino chuckjcarl...@gmail.commailto:chuckjcarl...@gmail.com wrote: Hi all, I need some help regarding a bug [1] I'm working on. The bug is basically a request to make the mac address of a port updatable. The use case is a baremetal (Ironic) node that has a bad NIC which must be replaced, resulting in a new mac address. The bad NIC has an associated neutron port which of course holds the NIC's IP address. The reason to make mac_address updatable (as opposed to having the user create a new port and delete the old one) is that during the recovery process the IP address must be retained and assigned to the new NIC/port, which is not guaranteed in the above work-around. I'm coding the changes to do this in the ml2, openvswitch, and linuxbridge plugins but I'm not sure how to handle the the other plugins since I don't know if the associated backends are prepared to handle such updates. My first thought is to disallow the update in the other plugins, but I would really appreciate your advice. Kind regards, Chuck Carlino [1] https://bugs.launchpad.net/neutron/+bug/1341268 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.orgmailto:OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Kevin Benton ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron] ovs-neutron-agent wipes out all flows on startup
Indeed a blueprint has been filed (on Launchpad, not neutron-specs) on this already[0], but there has been no work on this as far as I can tell. I think it would be worthwhile contribution. Amir [0] https://blueprints.launchpad.net/neutron/+spec/neutron-agent-soft-restart From: Paul Ward [wpw...@linux.vnet.ibm.com] Sent: Monday, June 30, 2014 2:11 PM To: OpenStack Development Mailing List Subject: [openstack-dev] [neutron] ovs-neutron-agent wipes out all flows on startup The current design for ovs-neutron-agent is that it will wipe out all flows configured on the system when it starts up, recreating them for each neutron port it's aware of. This has a not-so-desirable side effects that there's a temporary hiccup in network connectivity for the VMs on the host. My questions to the list: Is there a reason it was designed this way (other than Everything on the system must be managed by OpenStack)? Is there ongoing work to address this or would it be a worthwhile contribution from our side? ___ 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] blueprint ovs-firewall-driver: OVS implementation of security groups
Salvatore, The 80% distinction came from a discussion I had at summit, representing that the majority of features described by the current security groups could be implemented today with OVS without connection tracking. It’s not based on any mathematical calculation… more of a pseudo-application of Pareto’s principle. :) Correct, the OVS tcp_flags feature will be used to implement an emulated statefulness for TCP flows whereas non-TCP flows would use the source-port-range-min, source-port-range-max extended API to implement stateless flows. Performance measurements would have to come after implementations are made for the proposed blueprint. Although, benchmarks of the two existing FirewallDriver implementations can be done today. We can measure number of concurrent connections until failure, overall bandwidth as percentage of line rate, etc. Are there any other specific metrics you would like to see in the benchmark? Amir On Jun 3, 2014, at 2:51 AM, Salvatore Orlando sorla...@nicira.commailto:sorla...@nicira.com wrote: I would like to understand how did we get to this 80%/20% distinction. In other terms, it seems conntrack's RELATED features won't be supported for non-tcp traffic. What about the ESTABLISHED feature? The blueprint specs refers to tcp_flags=ack. Or will that be supported through the source port matching extension which is being promoted? More comments inline. On 3 June 2014 01:22, Amir Sadoughi amir.sadou...@rackspace.commailto:amir.sadou...@rackspace.com wrote: Hi all, In the Neutron weekly meeting today[0], we discussed the ovs-firewall-driver blueprint[1]. Moving forward, OVS features today will give us 80% of the iptables security groups behavior. Specifically, OVS lacks connection tracking so it won’t have a RELATED feature or stateful rules for non-TCP flows. (OVS connection tracking is currently under development, to be released by 2015[2]). To make the “20% difference more explicit to the operator and end user, we have proposed feature configuration to provide security group rules API validation that would validate based on connection tracking ability, for example. I am stilly generally skeptic of API changes which surface backend details on user-facing APIs. I understand why you are proposing this however, and I think it would be good to get first an assessment of the benefits brought by such a change before making a call on changing API behaviour to reflect security group implementation on the backend. Several ideas floated up during the chat today, I wanted to expand the discussion to the mailing list for further debate. Some ideas include: - marking ovs-firewall-driver as experimental in Juno - What does it mean to be marked as “experimental”? In this case experimental would be a way to say not 100% functional. You would not expect a public service provider exposing neutron APIs backed by this driver, but maybe in some private deployments where the missing features are not a concern it could be used. - performance improvements under a new OVS firewall driver untested so far (vthapar is working on this) From the last comment in your post it seems you already have proof of the performance improvement, perhaps you can add those to the Performance Impact section on the spec. - incomplete implementation will cause confusion, educational burden It's more about technical debt in my opinion, but this is not necessarily the case. - debugging OVS is new to users compared to debugging old iptables This won't be a concern as long as we have good documentation to back the implementation. As Neutron is usually sloppy with documentation - then it's a concern. - waiting for upstream OVS to implement (OpenStack K- or even L- cycle) In my humble opinion, merging the blueprint for Juno will provide us a viable, more performant security groups implementation than what we have available today. Amir [0] http://eavesdrop.openstack.org/meetings/networking/2014/networking.2014-06-02-21.01.log.html [1] https://review.openstack.org/#/c/89712/ [2] http://openvswitch.org/pipermail/dev/2014-May/040567.html ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.orgmailto:OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.orgmailto: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] blueprint ovs-firewall-driver: OVS implementation of security groups
Paul, Beyond explicit configuration for the cloud operator, documentation and API validation for the end user, is there anything specific you would like to see as a “warning label”? Does iptables do TCP sequence number validation? Where we can, we should strive to match iptables behavior. Regarding OVS flows and security groups, we can provide a tool to explain how security group rules are mapped to the integration bridge. In the proposed solution contained in the blueprint, security group rule flows would be distinguished from other agent’s flows via cookie. Regarding packet logging, I don’t know if OVS is capable of it. If iptables in Neutron does not currently support that feature, I don’t think Neutron should explicitly support out-of-tree features. Amir On Jun 3, 2014, at 6:59 AM, CARVER, PAUL pc2...@att.commailto:pc2...@att.com wrote: Amir Sadoughi wrote: Specifically, OVS lacks connection tracking so it won’t have a RELATED feature or stateful rules for non-TCP flows. (OVS connection tracking is currently under development, to be released by 2015 It definitely needs a big obvious warning label on this. A stateless firewall hasn’t been acceptable in serious security environments for at least a decade. “Real” firewalls do things like TCP sequence number validation to ensure that someone isn’t hi-jacking an existing connection and TCP flag validation to make sure that someone isn’t “fuzzing” by sending invalid combinations of flags in order to uncover bugs in servers behind the firewall. - debugging OVS is new to users compared to debugging old iptables This one is very important in my opinion. There absolutely needs to be a section in the documentation on displaying and interpreting the rules generated by Neutron. I’m pretty sure that if you tell anyone with Linux admin experience that Neutron security groups are iptables based, they should be able to figure their way around iptables –L or iptables –S without much help. If they haven’t touched iptables in a while, five minutes reading “man iptables” should be enough for them to figure out the important options and they can readily see the relationship between what they put in a security group and what shows up in the iptables chain. I don’t think there’s anywhere near that ease of use on how to list the OvS ruleset for a VM and see how it corresponds to the Neutron security group. Finally, logging of packets (including both dropped and permitted connections) is mandatory in many environments. Does OvS have the ability to do the necessary logging? Although Neutron security groups don’t currently enable logging, the capabilities are present in the underlying iptables and can be enabled with some work. If OvS doesn’t support logging of connections then this feature definitely needs to be clearly marked as “not a firewall substitute” so that admins are clearly informed that they still need a “real” firewall for audit compliance and may only consider OvS based Neutron security groups as an additional layer of protection behind the “real” firewall. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.orgmailto: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] blueprint ovs-firewall-driver: OVS implementation of security groups
Carl, You are correct in both distinctions. Like I mentioned to Paul, beyond explicit configuration for the cloud operator, documentation and API validation for the end user, is there anything specific you would like to see as a “warning label”? Amir On Jun 3, 2014, at 9:01 AM, Carl Baldwin c...@ecbaldwin.netmailto:c...@ecbaldwin.net wrote: How does ovs handle tcp flows? Does it include stateful tracking of tcp -- as your wording below implies -- or does it do stateless inspection of returning tcp packets? It appears it is the latter. This isn't the same as providing a stateful ESTABLISHED feature. Many users may not fully understand the differences. One of the most basic use cases, which is to ping an outside Ip address from inside a nova instance would not work without connection tracking with the default security groups which don't allow ingress except related and established. This may surprise many. Carl Hi all, In the Neutron weekly meeting today[0], we discussed the ovs-firewall-driver blueprint[1]. Moving forward, OVS features today will give us 80% of the iptables security groups behavior. Specifically, OVS lacks connection tracking so it won’t have a RELATED feature or stateful rules for non-TCP flows. (OVS connection tracking is currently under development, to be released by 2015[2]). To make the “20% difference more explicit to the operator and end user, we have proposed feature configuration to provide security group rules API validation that would validate based on connection tracking ability, for example. Several ideas floated up during the chat today, I wanted to expand the discussion to the mailing list for further debate. Some ideas include: - marking ovs-firewall-driver as experimental in Juno - What does it mean to be marked as “experimental”? - performance improvements under a new OVS firewall driver untested so far (vthapar is working on this) - incomplete implementation will cause confusion, educational burden - debugging OVS is new to users compared to debugging old iptables - waiting for upstream OVS to implement (OpenStack K- or even L- cycle) In my humble opinion, merging the blueprint for Juno will provide us a viable, more performant security groups implementation than what we have available today. Amir [0] http://eavesdrop.openstack.org/meetings/networking/2014/networking.2014-06-02-21.01.log.html [1] https://review.openstack.org/#/c/89712/ [2] http://openvswitch.org/pipermail/dev/2014-May/040567.html ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.orgmailto:OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.orgmailto: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] blueprint ovs-firewall-driver: OVS implementation of security groups
Hi all, In the Neutron weekly meeting today[0], we discussed the ovs-firewall-driver blueprint[1]. Moving forward, OVS features today will give us 80% of the iptables security groups behavior. Specifically, OVS lacks connection tracking so it won’t have a RELATED feature or stateful rules for non-TCP flows. (OVS connection tracking is currently under development, to be released by 2015[2]). To make the “20% difference more explicit to the operator and end user, we have proposed feature configuration to provide security group rules API validation that would validate based on connection tracking ability, for example. Several ideas floated up during the chat today, I wanted to expand the discussion to the mailing list for further debate. Some ideas include: - marking ovs-firewall-driver as experimental in Juno - What does it mean to be marked as “experimental”? - performance improvements under a new OVS firewall driver untested so far (vthapar is working on this) - incomplete implementation will cause confusion, educational burden - debugging OVS is new to users compared to debugging old iptables - waiting for upstream OVS to implement (OpenStack K- or even L- cycle) In my humble opinion, merging the blueprint for Juno will provide us a viable, more performant security groups implementation than what we have available today. Amir [0] http://eavesdrop.openstack.org/meetings/networking/2014/networking.2014-06-02-21.01.log.html [1] https://review.openstack.org/#/c/89712/ [2] http://openvswitch.org/pipermail/dev/2014-May/040567.html ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Neutron Migrations, service plugins and Grenade jobs
I know alembic is designed to be global, but could we extend it to track multiple histories for a given database. In other words, various branches for different namespaces on a single database. Would this feature ameliorate the issues? Amir On Apr 15, 2014, at 8:24 AM, Kyle Mestery mest...@noironetworks.commailto:mest...@noironetworks.com wrote: On Tue, Apr 15, 2014 at 7:03 AM, Salvatore Orlando sorla...@nicira.commailto:sorla...@nicira.com wrote: Thanks Anna. I've been following the issue so far, but I am happy to hand it over to you. I think the problem assessment is complete, but if you have more questions ping me on IRC. Regarding the solution, I think we already have a fairly wide consensus on the approach. There are however a few details to discuss: - Conflicting schemas. For instance two migrations for two distinct plugins might create tables with the same name but different columns. We first need to look at existing migrations to verify where this condition occurs, and then study a solution case by case. - Logic for corrective migrations. For instance a corrective migration for 569e98a8132b_metering is needed. However, such corrective migration should have logic for understanding whether the original migration has been executed or not. - Corrective actions for corrupted schemas. This would be the case, for instance, of somebody which enables metering while the database is at a migration rev higher than the one when metering was introduced. I reckon it might be the case of putting together a specification and push it to the newly created neutron-specs repo, assuming that we feel confident enough to start using this new process (Kyle and Mark might chime in on this point). Also, I would like to see this work completed by Juno-1, which I reckon is a reasonable target. I'm working to get this new specification approval process ready, hopefully by later today. Once this is done, I agree with Salvatore, pushing a gerrit review with the specification for this work will be the right approach. Of course I'm available for discussing design, implementation, reviewing and writing code. Thanks to Anna and Salvatore for taking this up! Kyle Salvatore On 15 April 2014 12:44, Anna Kamyshnikova akamyshnik...@mirantis.commailto:akamyshnik...@mirantis.com wrote: Hello everyone! I would like to try to solve this problem. I registered blueprint on this topic https://blueprints.launchpad.net/neutron/+spec/neutron-robust-db-migrations and I'm going to experiment with options to solve this. I'm welcome any suggestions and ready to talk about it via IRC (akamyshnikova). Regards Ann On Mon, Apr 14, 2014 at 9:39 PM, Sean Dague s...@dague.net wrote: On 04/14/2014 12:46 PM, Eugene Nikanorov wrote: Hi Salvatore, The described problem could be even worse if vendor drivers are considered. Doesn't #1 require that all DB tables are named differently? Otherwise it seems that user can't be sure in DB schema even if all tables are present. I think the big part of the problem is that we need to support both online and offline migrations. Without the latter things could be a little bit simpler. Also it seems to me that problem statement should be changed to the following: One need to migrate from (Config1, MigrationID1) to (Config2, MigrationID2), and currently our code only accounts for MigrationIDs. We may consider amending DB with configuration metadata, at least that will allow to run migration code with full knowledge of what happened before (if online mode is considered). In offline mode that will require providing old and current configurations. That was just thinking aloud, no concrete proposals yet. The root issue really is Migrations *must* be global, and config invariant. That's the design point in both sqlalchemy-migrate and alembic. The fact that there is one global migrations table per database, with a single value in it, is indicative of this fact. I think that design point got lost somewhere along the way, and folks assumed migrations were just a way to change schemas. They are much more constrained than that. It does also sound like the data model is going to need some serious reconsidering given what's allowed to be changed at the plugin or vendor driver model. Contrast this with Nova, were virt drivers don't get to define persistant data that's unique to them (only generic data that they fit into the grander nova model). The one time we had a driver which needed persistent data (baremetal) it managed it's own database entirely. -Sean -- Sean Dague Samsung Research America s...@dague.net / sean.da...@samsung.com http://dague.net ___ 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
Re: [openstack-dev] [Neutron] Status of ovs-firewall-driver blueprint?
Hi Vishal, I’ve restarted my work on the blueprint last week now that Juno is open for development and OVS 2.1.0 is available, targeting juno-1. My plan is to have a working implementation available by the summit design discussion to make sure we cover all our bases. Between the blueprint page you referenced[0], this wiki page[1], and the Gerrit review[2] site, that is all the up-to-date information. Outside of those links, any other updates will be on this mailing list or the ML2 weekly IRC meeting. I’m open to collaboration and interested in anything you are able to contribute. Do you have any existing work to share or feedback? Amir [0] https://blueprints.launchpad.net/neutron/+spec/ovs-firewall-driver [1] https://wiki.openstack.org/wiki/Neutron/blueprint_ovs-firewall-driver [2] https://review.openstack.org/#/q/topic:bp/ovs-firewall-driver,n,z On Apr 7, 2014, at 3:33 AM, Thapar, Vishal (HP Networking) vtha...@hp.commailto:vtha...@hp.com wrote: Hi, I am working on an OVS based implementation of Neutron Security Groups and came across this blueprint: https://blueprints.launchpad.net/neutron/+spec/ovs-firewall-driver I’ve gone through every mail, document and IRC chat log on this to get a good grasp of history on this, but couldn’t find any recent activity on this blueprint. It is listed on Meetings page on wiki but last meeting seems to have been held last year in December. I’ve just started working on prototyping this and would like to work with community to see it to completion. Could anyone suggest on how to proceed on this? Do I need to request a meeting for this? Thanks and Regards, Vishal. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.orgmailto:OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] Status of ovs-firewall-driver blueprint?
Kyle, Yes. I plan on getting all 4 existing patches up-to-date over the next 9 days. I’m not working on upstream 100% of the time so that’s not a hard commitment, but I think it’s definitely doable. Amir On Apr 7, 2014, at 11:42 AM, Kyle Mestery mest...@noironetworks.commailto:mest...@noironetworks.com wrote: On Mon, Apr 7, 2014 at 11:01 AM, Amir Sadoughi amir.sadou...@rackspace.commailto:amir.sadou...@rackspace.com wrote: Hi Vishal, I've restarted my work on the blueprint last week now that Juno is open for development and OVS 2.1.0 is available, targeting juno-1. My plan is to have a working implementation available by the summit design discussion to make sure we cover all our bases. Between the blueprint page you referenced[0], this wiki page[1], and the Gerrit review[2] site, that is all the up-to-date information. Outside of those links, any other updates will be on this mailing list or the ML2 weekly IRC meeting. I'm open to collaboration and interested in anything you are able to contribute. Do you have any existing work to share or feedback? Amir Amir, I looked at the review, and it's coming along nicely! Any chance you can post a rebased version this week to get a clean Jenkins run? Thanks! Kyle [0] https://blueprints.launchpad.net/neutron/+spec/ovs-firewall-driver [1] https://wiki.openstack.org/wiki/Neutron/blueprint_ovs-firewall-driver [2] https://review.openstack.org/#/q/topic:bp/ovs-firewall-driver,n,z On Apr 7, 2014, at 3:33 AM, Thapar, Vishal (HP Networking) vtha...@hp.commailto:vtha...@hp.com wrote: Hi, I am working on an OVS based implementation of Neutron Security Groups and came across this blueprint: https://blueprints.launchpad.net/neutron/+spec/ovs-firewall-driver I've gone through every mail, document and IRC chat log on this to get a good grasp of history on this, but couldn't find any recent activity on this blueprint. It is listed on Meetings page on wiki but last meeting seems to have been held last year in December. I've just started working on prototyping this and would like to work with community to see it to completion. Could anyone suggest on how to proceed on this? Do I need to request a meeting for this? Thanks and Regards, Vishal. ___ 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.orgmailto:OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.orgmailto: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] [Network] Allocate MAC and IP address for a VM instance
Hi all, In Rackspace's quark plugin (github.com/rackerlabs/quark), we’ve developed an extension for MAC address ranges (MARs) as a top-level resource. Thus, the Neutron service manages the MAC address allocation from a pool of ranges (as opposed to randomly generating a MAC address). However, we haven’t made a relationship between MARs and subnets/networks. Amir On Feb 18, 2014, at 11:24 AM, Tim Bell tim.b...@cern.ch wrote: Jay, We've got a similar requirement at CERN where we would like to have pools of ip/mac combinations for each subnet and have it so that the user is just allocated one (and for the same subnet that the hypervisor is on). We've not found a good solution so far. Tim -Original Message- From: Dong Liu [mailto:willowd...@gmail.com] Sent: 18 February 2014 18:12 To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Network] Allocate MAC and IP address for a VM instance Hi Jay, In neutron API, you could create port with specified mac_address and fix_ip, and then create vm with this port. But the mapping of them need to manage by yourself. 在 2014年2月18日，22:41，Jay Lau jay.lau@gmail.com 写道： Greetings, Not sure if it is suitable to ask this question in openstack-dev list. Here come a question related to network and want to get some input or comments from you experts. My case is as this: For some security issue, I want to put both MAC and internal IP address to a pool and when create VM, I can get MAC and its mapped IP address and assign the MAC and IP address to the VM. For example, suppose I have following MAC and IP pool: 1) 78:2b:cb:af:78:b0, 192.168.0.10 2) 78:2b:cb:af:78:b1, 192.168.0.11 3) 78:2b:cb:af:78:b2, 192.168.0.12 4) 78:2b:cb:af:78:b3, 192.168.0.13 Then I can create four VMs using above MAC and IP address, each row in above can be mapped to a VM. Does any of you have any idea for the solution of this? -- Thanks, Jay ___ 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] [Neturon] firewall_driver and ML2 and vif_security discussion
Hi all, I just want to make sure I understand the plan and its consequences. I’m on board with the YAGNI principle of hardwiring mechanism drivers to return their firewall_driver types for now. However, after (A), (B), and (C) are completed, to allow for Open vSwitch-based security groups (blueprint ovs-firewall-driver) is it correct to say: we’ll need to implement a method such that the ML2 mechanism driver is aware of its agents and each of the agents' configured firewall_driver? i.e. additional RPC communication? From yesterday’s meeting: http://eavesdrop.openstack.org/meetings/networking_ml2/2014/networking_ml2.2014-01-15-16.00.log.html 16:44:17 rkukura I've suggested that the L2 agent could get the vif_security info from its firewall_driver, and include this in its agents_db info 16:44:39 rkukura then the bound MD would return this as the vif_security for the port 16:45:47 rkukura existing agents_db RPC would send it from agent to server and store it in the agents_db table Does the above suggestion change with the plan as-is now? From Nachi’s response, it seemed like maybe we should support concurrent firewall_driver instances in a single agent. i.e. don’t statically configure firewall_driver in the agent, but let the MD choose the firewall_driver for the port based on what firewall_drivers the agent supports. Thanks, Amir On Jan 16, 2014, at 11:42 AM, Nachi Ueno na...@ntti3.com wrote: Hi Mathieu, Bob Thank you for your reply OK let's do (A) - (C) for now. (A) Remove firewall_driver from server side Remove Noop -- I'll write patch for this (B) update ML2 with extend_port_dict -- Bob will push new review for this (C) Fix vif_security patch using (1) and (2). -- I'll update the patch after (A) and (B) merged # config is hardwired for each mech drivers for now (Optional D) Rething firewall_driver config in the agent 2014/1/16 Robert Kukura rkuk...@redhat.com: On 01/16/2014 04:43 AM, Mathieu Rohon wrote: Hi, your proposals make sense. Having the firewall driver configuring so much things looks pretty stange. Agreed. I fully support proposed fix 1, adding enable_security_group config, at least for ml2. I'm not sure whether making this sort of change go the openvswitch or linuxbridge plugins at this stage is needed. Enabling security group should be a plugin/MD decision, not a driver decision. I'm not so sure I support proposed fix 2, removing firewall_driver configuration. I think with proposed fix 1, firewall_driver becomes an agent-only configuration variable, which seems fine to me, at least for now. The people working on ovs-firewall-driver need something like this to choose the between their new driver and the iptables driver. Each L2 agent could obviously revisit this later if needed. For ML2, in a first implementation, having vif security based on vif_type looks good too. I'm not convinced to support proposed fix 3, basing ml2's vif_security on the value of vif_type. It seems to me that if vif_type was all that determines how nova handles security groups, there would be no need for either the old capabilities or new vif_security port attribute. I think each ML2 bound MechanismDriver should be able to supply whatever vif_security (or capabilities) value it needs. It should be free to determine that however it wants. It could be made configurable on the server-side as Mathieu suggest below, or could be kept configurable in the L2 agent and transmitted via agents_db RPC to the MechanismDriver in the server as I have previously suggested. As an initial step, until we really have multiple firewall drivers to choose from, I think we can just hardwire each agent-based MechanismDriver to return the correct vif_security value for its normal firewall driver, as we currently do for the capabilities attribute. Also note that I really like the extend_port_dict() MechanismDriver methods in Nachi's current patch set. This is a much nicer way for the bound MechanismDriver to return binding-specific attributes than what ml2 currently does for vif_type and capabilities. I'm working on a patch taking that part of Nachi's code, fixing a few things, and extending it to handle the vif_type attribute as well as the current capabilities attribute. I'm hoping to post at least a WIP version of this today. I do support hardwiring the other plugins to return specific vif_security values, but those values may need to depend on the value of enable_security_group from proposal 1. -Bob Once OVSfirewallDriver will be available, the firewall drivers that the operator wants to use should be in a MD config file/section and ovs MD could bind one of the firewall driver during port_create/update/get. Best, Mathieu On Wed, Jan 15, 2014 at 6:29 PM, Nachi Ueno na...@ntti3.com wrote: Hi folks Security group for OVS agent (ovs plugin or ML2) is being broken. so we need vif_security port
Re: [openstack-dev] [Neturon] firewall_driver and ML2 and vif_security discussion
That also makes sense to me as the simplest option. Looking forward to all of your patches. Thanks, Amir On Jan 16, 2014, at 2:13 PM, Kyle Mestery mest...@siliconloons.commailto:mest...@siliconloons.com wrote: On Jan 16, 2014, at 1:37 PM, Nachi Ueno na...@ntti3.commailto:na...@ntti3.com wrote: Hi Amir 2014/1/16 Amir Sadoughi amir.sadou...@rackspace.commailto:amir.sadou...@rackspace.com: Hi all, I just want to make sure I understand the plan and its consequences. I’m on board with the YAGNI principle of hardwiring mechanism drivers to return their firewall_driver types for now. However, after (A), (B), and (C) are completed, to allow for Open vSwitch-based security groups (blueprint ovs-firewall-driver) is it correct to say: we’ll need to implement a method such that the ML2 mechanism driver is aware of its agents and each of the agents' configured firewall_driver? i.e. additional RPC communication? From yesterday’s meeting: http://eavesdrop.openstack.org/meetings/networking_ml2/2014/networking_ml2.2014-01-15-16.00.log.html 16:44:17 rkukura I've suggested that the L2 agent could get the vif_security info from its firewall_driver, and include this in its agents_db info 16:44:39 rkukura then the bound MD would return this as the vif_security for the port 16:45:47 rkukura existing agents_db RPC would send it from agent to server and store it in the agents_db table Does the above suggestion change with the plan as-is now? From Nachi’s response, it seemed like maybe we should support concurrent firewall_driver instances in a single agent. i.e. don’t statically configure firewall_driver in the agent, but let the MD choose the firewall_driver for the port based on what firewall_drivers the agent supports. Let's say we have OpenFlowBasedFirewallDriver and IptablesBasedFirewallDriver in future. I believe there is no usecase to let user to select such implementation detail by host. so it is enough if we have a config security_group_mode=(openflow or iptables) in OVS MD configuration, then update vif_security based on this value. I agree with your thinking here Nachi. Leaving this as a global configuration makes the most sense. Thanks, Amir On Jan 16, 2014, at 11:42 AM, Nachi Ueno na...@ntti3.commailto:na...@ntti3.com wrote: Hi Mathieu, Bob Thank you for your reply OK let's do (A) - (C) for now. (A) Remove firewall_driver from server side Remove Noop -- I'll write patch for this (B) update ML2 with extend_port_dict -- Bob will push new review for this (C) Fix vif_security patch using (1) and (2). -- I'll update the patch after (A) and (B) merged # config is hardwired for each mech drivers for now (Optional D) Rething firewall_driver config in the agent 2014/1/16 Robert Kukura rkuk...@redhat.commailto:rkuk...@redhat.com: On 01/16/2014 04:43 AM, Mathieu Rohon wrote: Hi, your proposals make sense. Having the firewall driver configuring so much things looks pretty stange. Agreed. I fully support proposed fix 1, adding enable_security_group config, at least for ml2. I'm not sure whether making this sort of change go the openvswitch or linuxbridge plugins at this stage is needed. Enabling security group should be a plugin/MD decision, not a driver decision. I'm not so sure I support proposed fix 2, removing firewall_driver configuration. I think with proposed fix 1, firewall_driver becomes an agent-only configuration variable, which seems fine to me, at least for now. The people working on ovs-firewall-driver need something like this to choose the between their new driver and the iptables driver. Each L2 agent could obviously revisit this later if needed. For ML2, in a first implementation, having vif security based on vif_type looks good too. I'm not convinced to support proposed fix 3, basing ml2's vif_security on the value of vif_type. It seems to me that if vif_type was all that determines how nova handles security groups, there would be no need for either the old capabilities or new vif_security port attribute. I think each ML2 bound MechanismDriver should be able to supply whatever vif_security (or capabilities) value it needs. It should be free to determine that however it wants. It could be made configurable on the server-side as Mathieu suggest below, or could be kept configurable in the L2 agent and transmitted via agents_db RPC to the MechanismDriver in the server as I have previously suggested. As an initial step, until we really have multiple firewall drivers to choose from, I think we can just hardwire each agent-based MechanismDriver to return the correct vif_security value for its normal firewall driver, as we currently do for the capabilities attribute. Also note that I really like the extend_port_dict() MechanismDriver methods in Nachi's current patch set. This is a much nicer way for the bound MechanismDriver to return binding-specific attributes than what ml2 currently does for vif_type and capabilities. I'm working on a patch taking
Re: [openstack-dev] [Neutron][ML2] Unit test coverage
I’ve run the tests again with `coverage report -m` to show the line-by-line numbers of statements that weren’t executed. (.venv)amir@dev:~/neutron$ git log HEAD --pretty=oneline | head -n 1 51bef83fecfd6ccf7bf1f9ba3d14bbab0c205949 Merge Midonet plugin: Fix source NAT” fox -e cover neutron.tests.unit.ml2: http://paste.openstack.org/show/55372/ tox -e cover neutron.tests.unit.openvswitch.test_ovs_neutron_agent: http://paste.openstack.org/show/55373/ tox -e cover neutron.tests.unit.linuxbridge.test_lb_neutron_agent: http://paste.openstack.org/show/55374/ fox -e cover neutron.tests.unit.ml2 (filtered, sorted): http://paste.openstack.org/show/55375/ Amir On Dec 12, 2013, at 4:48 PM, Amir Sadoughi amir.sadou...@rackspace.com wrote: Mathieu, Here are my results for running the unit tests for the agents. I ran `tox -e cover neutron.tests.unit.openvswitch.test_ovs_neutron_agent` at 3b4233873539bad62d202025529678a5b0add412 with the following result: Name Stmts Miss Branch BrMiss Cover … neutron/plugins/openvswitch/agent/ovs_neutron_agent639257 23712357% … and `tox -e cover neutron.tests.unit.linuxbridge.test_lb_neutron_agent` with the following result: ... neutron/plugins/linuxbridge/agent/linuxbridge_neutron_agent607134 255 7376% ... Amir On Dec 11, 2013, at 3:01 PM, Mathieu Rohon mathieu.ro...@gmail.com wrote: the coverage is quite good on the ML2 plugin. it looks like the biggest effort should be done on the ovs and lb agents, no? On Wed, Dec 11, 2013 at 9:00 PM, Amir Sadoughi amir.sadou...@rackspace.com wrote: From today’s ML2 meeting, I had an action item to produce coverage report for ML2 unit tests. Here is the command line output of the tests and report I produced: http://paste.openstack.org/show/54845/ Amir Sadoughi ___ 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] blueprint ovs-firewall-driver: Security groups extension API addition
Hi all, Monday at 2000 UTC I held an IRC meeting for blueprint ovs-firewall-driver to discuss implementation choices with the community. Only a handful of people attended so I wanted to open the discussion to the mailing list. (I’ve also uploaded this to the wiki https://wiki.openstack.org/wiki/Neutron/blueprint_ovs-firewall-driver#Security_groups_extension_API_addition_discussion.) tl;dr: To implement a performant OVS-based security groups solution in Neutron today, source port matching is a required addition to the security groups extension API. === Background === In Open vSwitch today, there are two best practice options of implementing firewalls[1]: 1. reflexive learn actions (available in OVS today) 2. stateless ACLs with tcp_flags=ack (available in OVS git, to be released in v2.1.0 - early 2014[6]) In the same e-mail thread[2], the tradeoffs between the two choices were discussed: - reflexive learning is not as performant as it cuts into how many flows a megaflow can wildcard, e.g. the less that can be wildcarded, the more OVS will have to hit userspace for flows - Using the learn action is strictly more correct, since it's only allowing return traffic that's in response to traffic that was previously seen. TCP flag matching allows reasonable megaflows, but just blocking on the SYN flags isn't as secure, since an attacker can get traffic through--they just can't initiate a new connection. My preferred implementation is 'stateless ACLs with tcp_flags=ack' to emulate stateful behavior (at least in TCP) because reflexive learning is not as performant. === Discussion: why? === Following through with the 'stateless ACLs with tcp_flags=ack' approach, UDP clients on the instance will need explicit security group rules to match source IP address and source port. Example 1. A remote UDP client connecting to an instance UDP server A. nw_src=$remote_ip, tp_src=random, nw_dst=$instance_ip, tp_dst=9987 B. nw_src=$instance_ip, tp_src=9987, nw_dst=$remote_ip, tp_src=random So, in the case of the instance being a UDP server and default security groups already allowing all egress, adding a rule to allow ingress on UDP destination port 9987 will behave as expected. Example 2. An instance UDP client connecting to a remote UDP server C. nw_src=$instance_ip, tp_src=random, nw_dst=$remote_ip, tp_dst=9987 D. nw_src=$remote_ip, tp_src=9987, nw_dst=$instance_ip, tp_dst=random In the case of the instance being a UDP client and default security groups already allowing all egress, we will need a new security group rule to allow ingress from source port 9987 from the remote UDP server in a stateless firewall. This is different behavior than the iptables-based stateful firewall implementation because it is able to add the reverse flow in its state table for a specific timeout length when it initially sees flow C. So, in security groups, we will need an additional rule that will define flow D (remote UDP server’s IP address, UDP source port 9987, and of course the instance’s IP address). However, if you look at the security groups API as it is today[3], you will see there is no match for source port (tp_src), only destination port (—port-range-min, —port-range-max). === Suggested change: how to fix it === So, to solve the lack of source port information, I propose the following addition to the security groups extension API to allow a match on source port: —source-port-range-min, —source-port-range-max. I already have WIP patches uploaded for neutron[4] and python-neutronclient[5] implementing these suggested additions. The security groups RPC API already has a field for source-port-range-min and source-port-range-max so this change would only affect the DB and frontend API. I’m open to any and all feedback. Thanks, Amir Sadoughi [1] e-mail thread on ovs-discuss mailing list. http://openvswitch.org/pipermail/discuss/2013-December/012425.html [2] http://openvswitch.org/pipermail/discuss/2013-December/012433.html [3] http://paste.openstack.org/show/55103/ [4] https://review.openstack.org/#/c/62129/ [5] https://review.openstack.org/#/c/62130/ [6] http://openvswitch.org/pipermail/discuss/2013-December/012457.html ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Neutron] blueprint ovs-firewall-driver follow-up meeting
Hello all, On Wednesday, at the ML2 meeting we had an agenda item[1] to discuss the blueprint ovs-firewall-driver’s progress and technical challenges. We didn’t have time to discuss everything, so at the suggestion of Bob K. I am scheduling a meeting for Monday. Looking at the calendar of OpenStack meetings[2], Monday at 2000 UTC (right before Neutron meeting) is open for #openstack-meeting. Looking forward to continue the discussion there. Thanks, Amir Sadoughi [1] https://wiki.openstack.org/wiki/Meetings/ML2#Meeting_Dec_11.2C_2013 [2] https://wiki.openstack.org/wiki/Meetings ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][ML2] Unit test coverage
Mathieu, Here are my results for running the unit tests for the agents. I ran `tox -e cover neutron.tests.unit.openvswitch.test_ovs_neutron_agent` at 3b4233873539bad62d202025529678a5b0add412 with the following result: Name Stmts Miss Branch BrMiss Cover … neutron/plugins/openvswitch/agent/ovs_neutron_agent639257 23712357% … and `tox -e cover neutron.tests.unit.linuxbridge.test_lb_neutron_agent` with the following result: ... neutron/plugins/linuxbridge/agent/linuxbridge_neutron_agent607134 255 7376% ... Amir On Dec 11, 2013, at 3:01 PM, Mathieu Rohon mathieu.ro...@gmail.com wrote: the coverage is quite good on the ML2 plugin. it looks like the biggest effort should be done on the ovs and lb agents, no? On Wed, Dec 11, 2013 at 9:00 PM, Amir Sadoughi amir.sadou...@rackspace.com wrote: From today’s ML2 meeting, I had an action item to produce coverage report for ML2 unit tests. Here is the command line output of the tests and report I produced: http://paste.openstack.org/show/54845/ Amir Sadoughi ___ 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] Why neutron-openvswitch-agent use linux-bridge?
Hi George, I’m working on a blueprint to implement OVS flows for security groups. https://blueprints.launchpad.net/neutron/+spec/ovs-firewall-driver Currently, neutron only implements security groups with iptables even when Open vSwitch is used. Amir On Nov 27, 2013, at 1:29 PM, George Shuklin george.shuk...@gmail.commailto: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 ovs-agent? Thanks. 27.11.2013 20:55 пользователь Lorin Hochstein lo...@nimbisservices.commailto:lo...@nimbisservices.com написал: Hi George: On Wed, Nov 27, 2013 at 1:45 PM, George Shuklin george.shuk...@gmail.commailto: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.comhttp://www.nimbisservices.com/ ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.orgmailto:OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.orgmailto: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] Reg : Security groups implementation using openflows in quantum ovs plugin
Yes, my work has been on ML2 with neutron-openvswitch-agent. I’m interested to see what Jun Park has. I might have something ready before he is available again, but would like to collaborate regardless. Amir On Nov 19, 2013, at 3:31 AM, Kanthi P pavuluri.kan...@gmail.commailto:pavuluri.kan...@gmail.com wrote: Hi All, Thanks for the response! Amir,Mike: Is your implementation being done according to ML2 plugin Regards, Kanthi On Tue, Nov 19, 2013 at 1:43 AM, Mike Wilson geekinu...@gmail.commailto:geekinu...@gmail.com wrote: Hi Kanthi, Just to reiterate what Kyle said, we do have an internal implementation using flows that looks very similar to security groups. Jun Park was the guy that wrote this and is looking to get it upstreamed. I think he'll be back in the office late next week. I'll point him to this thread when he's back. -Mike On Mon, Nov 18, 2013 at 3:39 PM, Kyle Mestery (kmestery) kmest...@cisco.commailto:kmest...@cisco.com wrote: On Nov 18, 2013, at 4:26 PM, Kanthi P pavuluri.kan...@gmail.commailto: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.orgmailto:OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.orgmailto:OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.orgmailto:OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.orgmailto: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] Reg : Security groups implementation using openflows in quantum ovs plugin
Hi Kanthi, I’ve already started the implementation (prototype phase) of such a blueprint, ovs-firewall-driver https://blueprints.launchpad.net/neutron/+spec/ovs-firewall-driver. Amir On Nov 18, 2013, at 4:26 PM, Kanthi P pavuluri.kan...@gmail.commailto: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 Thanks, Kanthi ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.orgmailto: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
