Re: [openstack-dev] [neutron][nova] New specs on routed networking
L3 routed network can support 1. broadcast/multicast 2. VRRP virtual MAC like technology For example OpenContrail does support both of these in fully L3 routed networks. Regards -Harshad On Tue, Oct 28, 2014 at 4:59 PM, Angus Lees g...@inodes.org wrote: On Tue, 28 Oct 2014 09:07:03 PM Rohit Agarwalla wrote: Agreed. The way I'm thinking about this is that tenants shouldn't care what the underlying implementation is - L2 or L3. As long as the connectivity requirements are met using the model/API, end users should be fine. The data center network design should be an administrators decision based on the implementation mechanism that has been configured for OpenStack. I don't know anything about Project Calico, but I have been involved with running a large cloud network previously that made heavy use of L3 overlays. Just because these points weren't raised earlier in this thread: In my experience, a move to L3 involves losing: - broadcast/multicast. It's possible to do L3 multicast/IGMP/etc, but that's a whole can of worms - so perhaps best to just say up front that this is a non-broadcast network. - support for other IP protocols. - various L2 games like virtual MAC addresses, etc that NFV/etc people like. We gain: - the ability to have proper hierarchical addressing underneath (which is a big one for scaling a single network). This itself is a tradeoff however - an efficient/strict hierarchical addressing scheme means VMs can't choose their own IP addresses, and VM migration is messy/limited/impossible. - hardware support for dynamic L3 routing is generally universal, through a small set of mostly-standard protocols (BGP, ISIS, etc). - can play various L3 games like BGP/anycast, which is super useful for geographically diverse services. It's certainly a useful tradeoff for many use cases. Users lose some generality in return for more powerful cooperation with the provider around particular features, so I sort of think of it like a step halfway up the IaaS- PaaS stack - except for networking. - Gus Thanks Rohit From: Kevin Benton blak...@gmail.commailto:blak...@gmail.com Reply-To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto: openstack-dev@lists.openstack.org Date: Tuesday, October 28, 2014 1:01 PM To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [neutron][nova] New specs on routed networking 1. Every packet L3 FIB Lookup : Radix Tree Search, instead of current L2 Hash/Index Lookup ? 2. Will there be Hierarchical network ? How much of the Routes will be imported from external world ? 3. Will there be Separate routing domain for overlay network ? Or it will be mixed with external/underlay network ? These are all implementation specific details. Different deployments and network backends can implement them however they want. What we need to discuss now is how this model will look to the end-user and API. 4. What will be the basic use case of this ? Thinking of L3 switching to support BGP-MPLS L3 VPN Scenario right from compute node ? I think the simplest use case is just that a provider doesn't want to deal with extending L2 domains all over their datacenter. On Tue, Oct 28, 2014 at 12:39 PM, A, Keshava keshav...@hp.commailto:keshav...@hp.com wrote: Hi Cory, Yes that is the basic question I have. OpenStack cloud is ready to move away from Flat L2 network ? 1. Every packet L3 FIB Lookup : Radix Tree Search, instead of current L2 Hash/Index Lookup ? 2. Will there be Hierarchical network ? How much of the Routes will be imported from external world ? 3. Will there be Separate routing domain for overlay network ? Or it will be mixed with external/underlay network ? 4. What will be the basic use case of this ? Thinking of L3 switching to support BGP-MPLS L3 VPN Scenario right from compute node ? Others can give their opinion also. Thanks Regards, keshava -Original Message- From: Cory Benfield [mailto:cory.benfi...@metaswitch.commailto:cory.benfi...@metaswitch.com ] Sent: Tuesday, October 28, 2014 10:35 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [neutron][nova] New specs on routed networking On Tue, Oct 28, 2014 at 07:44:48, A, Keshava wrote: Hi, Current Open-stack was built as flat network. With the introduction of the L3 lookup (by inserting the routing table in forwarding path) and separate 'VIF Route Type' interface: At what point of time in the packet processing decision will be made to lookup FIB during ? For each packet there will additional FIB lookup ? How about the impact on 'inter compute traffic', processed by DVR ? Here thinking OpenStack
Re: [openstack-dev] VPC Proposal
1. Feature is giving AWS VPC api compatibility with existing openstack structure 2. It does give full AWS compatibility (except for network ACL which was differed). Shared networks, FIP within scope of VPC is not some thing AWS provides. So it is not partial support. 3. IMO it would not be major change to go from what we are proposing to what JC is proposing as far as AWS VPC API(s) are concerned. 4. I can understand developers not liking AWS API(s) but many users of openstack will benefit 5. Multi tenant hierarchy and domains won't effect AWS API(s) in any way IMO there no need to differ this blueprint. On Tue, Feb 18, 2014 at 10:03 AM, Martin, JC jch.mar...@gmail.com wrote: There was a lot of emails on that thread, but I am not seeing the discussion converging. I would like to reiterate my concerns: - We are trying to implement an API on a feature that is not supported by openstack - As a result, the implementation is overloading existing construct without implementing full AWS capabilities and semantic (e.g. Shared network isolation from VPC, or Floating IP scoping to VPC). - Dependent blueprints are not implemented and have been deferred, resulting in the broken implementation (e.g. https://blueprints.launchpad.net/neutron/+spec/policy-extensions-for-neutron ) - this feature is only available through EC2 API, which is likely going to result in another implementation for general use. - users adopting the VPC model proposed through EC2 API will be stuck in an upgrade mess when the proper implementation comes along. - There are new constructs in work that are better suited for implementing this concept properly (Multi tenant hierarchy and domains). As you can guess, I'm not really a fan, but it seems that only few individuals are concerned. I would think that this topic would create more interest, specially on the network side. Maybe because of the subject tags. I will therefore copy this email with the Neutron tag. JC On Feb 17, 2014, at 10:10 PM, Rudra Rugge rru...@juniper.net wrote: I am not sure on how to dig out the archives. There were a couple of emails exchanged with Salvatore on the thread pertaining to the extensions we were referring to as part of this blueprint. There are a few notes on the whiteboard of the blueprint as well. Regards, Rudra On 2/17/14, 1:28 PM, jc Martin jch.mar...@gmail.com wrote: Thanks, Do you have the links for the discussions ? Thanks, JC Sent from my iPhone On Feb 17, 2014, at 11:29 AM, Rudra Rugge rru...@juniper.net wrote: JC, BP has been updated with the correct links. I have removed the abandoned review #3. Please review #1 and #2. 1. https://review.openstack.org/#/c/40071/ This is the active review. There is one comment by Sean regarding adding a knob when Neutron is not used. That will be addressed with the next path. 2. https://review.openstack.org/#/c/53171 This is the active review for tempest test cases as requested by Joe Gordon. Currently abandoned until #1 goes through. 3. https://review.openstack.org/#/c/53171 This review is not active. It was accidentally submitted with a new change-id. Regards, Rudra On 2/16/14, 9:25 AM, Martin, JC jch.mar...@gmail.com wrote: Harshad, I tried to find some discussion around this blueprint. Could you provide us with some notes or threads ? Also, about the code review you mention. which one are you talking about : https://review.openstack.org/#/c/40071/ https://review.openstack.org/#/c/49470/ https://review.openstack.org/#/c/53171 because they are all abandoned. Could you point me to the code, and update the BP because it seems that the links are not correct. Thanks, JC On Feb 16, 2014, at 9:04 AM, Allamaraju, Subbu su...@subbu.org wrote: Harshad, Thanks for clarifying. We started looking at this as some our customers/partners were interested in get AWS API compatibility. We have this blueprint and code review pending for long time now. We will know based on this thread wether the community is interested. But I assumed that community was interested as the blueprint was approved and code review has no -1(s) for long time now. Makes sense. I would leave it to others on this list to chime in if there is sufficient interest or not. To clarify, a clear incremental path from an AWS compatible API to an OpenStack model is not clear. In my mind AWS compatible API does not need new openstack model. As more discussion happen on JC's proposal and implementation becomes clear we will know how incremental is the path. But at high level there two major differences 1. New first class object will be introduced which effect all components 2. more than one project can be supported within VPC. But it does not change AWS API(s). So even in JC(s) model if you want AWS API then we will
Re: [openstack-dev] [keystone] role of Domain in VPC definition
Yes, [1] can be done without [2] and [3]. As you are well aware [2] is now merged with group policy discussions. IMHO all or nothing approach will not get us anywhere. By the time we line up all our ducks in row. New features/ideas/blueprints will keep Emerging. Regards -Harshad On Feb 16, 2014, at 2:30 AM, Salvatore Orlando sorla...@nicira.com wrote: It seems this work item is made of several blueprints, some of which are not yet approved. This is true at least for the Neutron blueprint regarding policy extensions. Since I first looked at this spec I've been wondering why nova has been selected as an endpoint for network operations rather than Neutron, but this probably a design/implementation details whereas JC here is looking at the general approach. Nevertheless, my only point here is that is seems that features like this need an all-or-none approval. For instance, could the VPC feature be considered functional if blueprint [1] is implemented, but not [2] and [3]? Salvatore [1] https://blueprints.launchpad.net/nova/+spec/aws-vpc-support [2] https://blueprints.launchpad.net/neutron/+spec/policy-extensions-for-neutron [3] https://blueprints.launchpad.net/keystone/+spec/hierarchical-multitenancy On 11 February 2014 21:45, Martin, JC jch.mar...@gmail.com wrote: Ravi, It seems that the following Blueprint https://wiki.openstack.org/wiki/Blueprint-aws-vpc-support has been approved. However, I cannot find a discussion with regard to the merit of using project vs. domain, or other mechanism for the implementation. I have an issue with this approach as it prevents tenants within the same domain sharing the same VPC to have projects. As an example, if you are a large organization on AWS, it is likely that you have a large VPC that will be shred by multiple projects. With this proposal, we loose that capability, unless I missed something. JC On Dec 19, 2013, at 6:10 PM, Ravi Chunduru ravi...@gmail.com wrote: Hi, We had some internal discussions on role of Domain and VPCs. I would like to expand and understand community thinking of Keystone domain and VPCs. Is VPC equivalent to Keystone Domain? If so, as a public cloud provider - I create a Keystone domain and give it to an organization which wants a virtual private cloud. Now the question is if that organization wants to have departments wise allocation of resources it is becoming difficult to visualize with existing v3 keystone constructs. Currently, it looks like each department of an organization cannot have their own resource management with in the organization VPC ( LDAP based user management, network management or dedicating computes etc.,) For us, Openstack Project does not match the requirements of a department of an organization. I hope you guessed what we wanted - Domain must have VPCs and VPC to have projects. I would like to know how community see the VPC model in Openstack. Thanks, -Ravi. ___ 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] VPC Proposal
Comments Inline Regards -Harshad On Sat, Feb 15, 2014 at 11:39 PM, Allamaraju, Subbu su...@subbu.org wrote: Harshad, Curious to know if there is a broad interest in an AWS compatible API in the community? We started looking at this as some our customers/partners were interested in get AWS API compatibility. We have this blueprint and code review pending for long time now. We will know based on this thread wether the community is interested. But I assumed that community was interested as the blueprint was approved and code review has no -1(s) for long time now. To clarify, a clear incremental path from an AWS compatible API to an OpenStack model is not clear. In my mind AWS compatible API does not need new openstack model. As more discussion happen on JC's proposal and implementation becomes clear we will know how incremental is the path. But at high level there two major differences 1. New first class object will be introduced which effect all components 2. more than one project can be supported within VPC. But it does not change AWS API(s). So even in JC(s) model if you want AWS API then we will have to keep VPC to project mapping 1:1, since the API will not take both VPC ID and project ID. As more users want to migrate from AWS or IaaS providers who want compete with AWS should be interested in this compatibility. There also seems to be terminology issue here Whats is definition of VPC if we assume what AWS implements is VPC then what JC is proposing VOS or VDC (virtual openstack or virtual DC) as all or most of current openstack features are available to user in this new Abstraction. I actually like this new abstraction. Subbu On Feb 15, 2014, at 10:04 PM, Harshad Nakil hna...@contrailsystems.com wrote: I agree with problem as defined by you and will require more fundamental changes. Meanwhile many users will benefit from AWS VPC api compatibility. ___ 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] VPC Proposal
IMHO I don't see two implementations. Since right now we have only one. As a community if we decide to add new abstractions then we will have to change software in every component where the new abstraction makes difference. That's normal software development process. Regards -Harshad On Feb 16, 2014, at 9:03 AM, Allamaraju, Subbu su...@subbu.org wrote: Harshad, Thanks for clarifying. We started looking at this as some our customers/partners were interested in get AWS API compatibility. We have this blueprint and code review pending for long time now. We will know based on this thread wether the community is interested. But I assumed that community was interested as the blueprint was approved and code review has no -1(s) for long time now. Makes sense. I would leave it to others on this list to chime in if there is sufficient interest or not. To clarify, a clear incremental path from an AWS compatible API to an OpenStack model is not clear. In my mind AWS compatible API does not need new openstack model. As more discussion happen on JC's proposal and implementation becomes clear we will know how incremental is the path. But at high level there two major differences 1. New first class object will be introduced which effect all components 2. more than one project can be supported within VPC. But it does not change AWS API(s). So even in JC(s) model if you want AWS API then we will have to keep VPC to project mapping 1:1, since the API will not take both VPC ID and project ID. As more users want to migrate from AWS or IaaS providers who want compete with AWS should be interested in this compatibility. IMHO that's a tough sell. Though an AWS compatible API does not need an OpenStack abstraction, we would end up with two independent ways of doing similar things. That would OpenStack repeating itself! Subbu ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] VPC Proposal
Comments Inline Regards -Harshad On Sat, Feb 15, 2014 at 3:18 PM, Martin, JC jch.mar...@gmail.com wrote: Harshad, Thanks, What happens when I create two VPC ? Beside the project private networks, what is isolated ? Since VPC is mapped to project. All the isolation provided by the project is available. What do you call DC admin ? I know two administrators : - Cloud administrators - VPC admnistrator I mean cloud administrator Are you saying that VPCs cannot have their own external gateways and NAT pools ? Yes conceptually as far as AWS API compatibility is concerned. Also, maybe more importantly, why try to build an AWS API before the function is available in openstack ? Why not wait to do it properly before defining the API mapping ? Actually as fas as AWS API is concerned we have all the proper building blocks in openstack. I agree with problem as defined by you and will require more fundamental changes. Meanwhile many users will benefit from AWS VPC api compatibility. JC On Feb 15, 2014, at 8:47 AM, Harshad Nakil hna...@contrailsystems.com wrote: EIP will be allocated from public pools. So in effect public pools and shared networks are only DC admin functions. Not available to VPC users. There is a implicit external gateway. When one creates NAT instance or VPN instance, external interfaces of these interfaces come from the shared network which can be configured by the DC admin. Regards -Harshad On Feb 14, 2014, at 10:07 PM, Martin, JC jch.mar...@gmail.com wrote: Harshad, I'm not sure to understand what you mean by : However many of these concepts are not exposed to a AWS customers and the API work well. So for example in : http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/elastic-ip-addresses-eip.html#VPC_EIP_EC2_Differences When it says : When you allocate an EIP, it's for use only in a VPC. Are you saying that the behavior of your API would be consistent without scoping the external networks to a VPC and using the public pool instead ? I believe that your api may work for basic features on a small deployments with only one VPC, but as soon as you have complex setups with external gateways that need to be isolated, I'm not sure that it will provide parity anyway with what EC2 provides. Maybe I missed something. JC On Feb 14, 2014, at 7:35 PM, Harshad Nakil hna...@contrailsystems.com wrote: Hi JC, You have put it aptly. Goal of the blueprint is to present facade for AWS VPC API as the name suggest. As per your definition of VPC, shared network will have issues. However many of these concepts are not exposed to a AWS customers and the API work well. While we work incrementally towards your definition of VPC we can maintain API compatibility to AWS API that we are proposing. As we are subset of your proposal and don't expose all features within VPC. Regards -Harshad On Feb 14, 2014, at 6:22 PM, Martin, JC jch.mar...@gmail.com wrote: Rudra, I do not agree that the current proposal provides the semantic of a VPC. If the goal is to only provide a facade through the EC2 API, it may address this, but unless you implement the basic features of a VPC, what good is it doing ? I do believe that the work can be done incrementally if we agree on the basic properties of a VPC, for example : - allowing projects to be created while using resources defined at the VPC level - preventing resources not explicitly defined at the VPC level to be used by a VPC. I do not see in the current proposal how resources are scoped to a VPC, and how, for example, you prevent shared network to be used within a VPC, or how you can define shared networks (or other shared resources) to only be scoped to a VPC. I think we already raised our concern to you several months ago, but it did not seem to have been addressed in the current proposal. thanks, JC On Feb 14, 2014, at 3:50 PM, Rudra Rugge rru...@juniper.net wrote: Hi JC, We agree with your proposed model of a VPC resource object. Proposal you are making makes sense to us and we would like to collaborate further on this. After reading your blueprint two things come to mind. 1. VPC vision for Openstack? (Your blueprint is proposing this vision) 2. Providing AWS VPC api compatibility with current constrains of openstack structure. The blueprint that we proposed targets #2. It gives a way to implement AWS VPC api compatible API. This helps subset of customers to migrate their workloads from AWS to openstack based clouds. In our implementation we tied VPC to project. That was easiest way to keep isolation with current structure. We agree that what you are proposing is more generic. One to way is to implement our current proposal to have one VPC to one project mapping. As your blueprint matures we will move VPC to multiple project mapping. We feel
Re: [openstack-dev] VPC Proposal
Hi JC, You have put it aptly. Goal of the blueprint is to present facade for AWS VPC API as the name suggest. As per your definition of VPC, shared network will have issues. However many of these concepts are not exposed to a AWS customers and the API work well. While we work incrementally towards your definition of VPC we can maintain API compatibility to AWS API that we are proposing. As we are subset of your proposal and don't expose all features within VPC. Regards -Harshad On Feb 14, 2014, at 6:22 PM, Martin, JC jch.mar...@gmail.com wrote: Rudra, I do not agree that the current proposal provides the semantic of a VPC. If the goal is to only provide a facade through the EC2 API, it may address this, but unless you implement the basic features of a VPC, what good is it doing ? I do believe that the work can be done incrementally if we agree on the basic properties of a VPC, for example : - allowing projects to be created while using resources defined at the VPC level - preventing resources not explicitly defined at the VPC level to be used by a VPC. I do not see in the current proposal how resources are scoped to a VPC, and how, for example, you prevent shared network to be used within a VPC, or how you can define shared networks (or other shared resources) to only be scoped to a VPC. I think we already raised our concern to you several months ago, but it did not seem to have been addressed in the current proposal. thanks, JC On Feb 14, 2014, at 3:50 PM, Rudra Rugge rru...@juniper.net wrote: Hi JC, We agree with your proposed model of a VPC resource object. Proposal you are making makes sense to us and we would like to collaborate further on this. After reading your blueprint two things come to mind. 1. VPC vision for Openstack? (Your blueprint is proposing this vision) 2. Providing AWS VPC api compatibility with current constrains of openstack structure. The blueprint that we proposed targets #2. It gives a way to implement AWS VPC api compatible API. This helps subset of customers to migrate their workloads from AWS to openstack based clouds. In our implementation we tied VPC to project. That was easiest way to keep isolation with current structure. We agree that what you are proposing is more generic. One to way is to implement our current proposal to have one VPC to one project mapping. As your blueprint matures we will move VPC to multiple project mapping. We feel that instead of throwing away all the work done we can take an incremental approach. Regards, Rudra On Feb 14, 2014, at 11:09 AM, Martin, JC jch.mar...@gmail.com wrote: There is a Blueprint targeted for Icehouse-3 that is aiming to implement the AWS VPC api. I don't think that this blueprint is providing the necessary constructs to really implement a VPC, and it is not taking into account the domains, or proposed multi tenant hierarchy. In addition, I could not find a discussion about this topic leading to the approval. For this reason, I wrote an 'umbrella' blueprint to hopefully start the discussion on how to really implement VPC, and eventually split it into multiple real blueprints for each area. Please, provide feedback on the following document, and on the best way to move this forward. https://wiki.openstack.org/wiki/Blueprint-VPC Thanks, JC. ___ 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] Openstack + OpenContrail
Sean, We have diff in three repositories. Nova, Neutron and devstack. Each review is requiring other to happen first. Do you have recommendation how do we deal with these dependencies? Regards -Harshad On Nov 16, 2013, at 9:11 AM, Sean Dague s...@dague.net wrote: For something to go in devstack, it has to be included in the base server project. So first step is to work on getting your code upstream into the relevant upstream. We don't preintegrate into devstack, because it's job is not to be a general installer, it's to be an opinionated development setup tool for the existing integrated projects, making it easier for people to develop and work with the whole stack. -Sean On 11/15/2013 07:35 PM, Deepinder Singh Setia wrote: I would like to add that the work in forked devstack is ongoing and not complete. I am trying to understand what would it take to push these changes upstream such as coding requirements, testing, code organization, documentation etc. Thanks Deepinder From: Deepinder Setia dse...@juniper.net mailto:dse...@juniper.net Reply-To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org mailto:openstack-dev@lists.openstack.org Date: Friday, November 15, 2013 4:25 PM To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org mailto:openstack-dev@lists.openstack.org Subject: [openstack-dev] Openstack + OpenContrail I forked devstack a few weeks ago to integrate with OpenContrail at https://github.com/dsetia/devstack. This installs and launches OpenContrail in addition to openstack components. OpenContrail provides network virtualization components - SDN controller, Virtual Router and analytics - via neutron and nova plugins along with other modules built and launched when stack.sh is run. Please see * https://github.com/dsetia/devstack/blob/master/contrail/README - * http://pedrormarques.wordpress.com/2013/11/14/using-devstack-plus-opencontrail/ * http://opencontrail.org/ Bulk of the work is done by new file lib/neutron_thirdparty/contrail such as cloning open contrail repo, building and launching contrail modules. I also have directory called contrail under devstack which includes: 1. sample localrc files for setting up single or multi node openstack + open contrail system 2. Support files and scripts needed by lib/neutron_thirdparty/contrail functions 3. Neutron and Nova patches needed by OpenStack. These plugins have been submitted for review. Once approved, I will get rid of code to patch them I would like to understand the procedure, requirements and logistics to push these changes upstream to devstack repository. Thanks Deepinder ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Sean Dague 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 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] Blueprint for Juniper OpenContrail vrouter nova vif driver support
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 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
Re: [openstack-dev] Bad review patterns
+1 Regards -Harshad On Nov 6, 2013, at 12:36 AM, Radomir Dopieralski openst...@sheep.art.pl wrote: Hello, I'm quite new in the OpenStack project, but I love it already. What is especially nifty is the automated review system -- I'm really impressed. I'm coming from a project in which we also did reviews of every change -- although it was mostly manual, and just one review was enough to merge -- and at some point in that project I noticed that it is very easy to give reviews that are unhelpful, frustrating and just get in the way of the actual work. I started paying attention to how I am reviewing code, and I managed to come up with several patterns that are bad. Once I know the patterns, it's easier to recognize when I'm doing something wrong and rethink the review. I would like to share the patterns that I noticed. Not sure if that works... = You see some suspicious piece of code, and you are not sure if it is correct or not. So you point it out in the review and -1 it, demanding that the author rechecks it and/or prove that it indeed works. It's your job as a reviewer to check such things, don't put all the effort on the author. They probably already checked that this code works, and possibly have even written tests for it. If you are not familiar with the technology enough to tell whether it's good or not, and have no means of testig it yourself, you shouldn't be reviewing it. If you do have the means to test it or can find the piece of documentation that says that it shouldn't be done -- do it as a part of the review. You ain't gonna need it. The code contains some parts that are potentially reusable later or in different areas, so you -1 it and tell the author to move them into reusable functions. The fact that you think something is reusable doesn't necessarily mean it is, and overly general code is harder to maintain. Let something repeat a couple of times just to be sure it actually is reusable. Once you find a repeating pattern, you can refactor the code to use a generalized function in its place -- in a separate change. There is an old bug here. = While you review the submitted code, you notice something wrong in the code not immediately related to the change you are reviewing. You -1 the change and tell the author to fix that bug, or formatting issue, or typo, or whatever. That fix has nothing to do with the change you are reviewing. The correct thing to do is to make a mental note of it, and fix it in a separate change -- possibly even finding more instances of it or coming up with a much better fix after seeing more code. Guess what I mean. == You notice a pep8 violation, or pep257 violation, or awkward wording of a comment or docstring, or a clumsy piece of code. You -1 the change and just tell author to fix it. It's not so easy to guess what you mean, and in case of a clumsy piece of code, not even that certain that better code can be used instead. So always provide an example of what you would rather want to see. So instead of pointing to indentation rules, just show properly indented code. Instead of talking about grammar or spelling, just type the corrected comment or docstring. Finally, instead of saying use list comprehension here or don't use has_key, just type your proposal of how the code should look like. Then we have something concrete to talk about. Of course, you can also say why you think this is better, but an example is very important. If you are not sure how the improved code would look like, just let it go, chances are it would look even worse. Not a complete fix. === The code fixes some problems (for example, fixes formatting and enables some flake8 checks), but leaves some other, related problems still not fixed. You -1 it and demand that the author adds fixes for the related problem. Don't live your coding career through the authors. If their fix is good and correct and improves the code, let it in, even if you see more opportunities to improve it. You can add those additional fixes yourself in a separate change. Or, if you don't have time or skill to do that, report a bug about the remaining problems and someone else will do it, but don't hold the author hostage with your review because you think he didn't do enough. Leaving a mark. === You review a change and see that it is mostly fine, but you feel that since you did so much work reviewing it, you should at least find *something* wrong. So you find some nitpick and -1 the change just so that they know you reviewed it. This is quite obvious. Just don't do it. It's OK to spend an hour reviewing something, and then leaving no comments on it, because it's simply fine, or because we had to means to test someting (see the first pattern). Those are the things I'm careful about myself. I'm
Re: [openstack-dev] [Neutron] Service VM discussion - Use Cases
Won't it be simpler to keep service instance as one or more VMs, rather than 1VM being many service instances? Usually a appliance is collectively (all it's functions) providing a service. Like firewall or load balancer. A appliance is packaged as VM. It will be easier to manage it will be easier for the provider to charge. It will be easier to control resource allocation. Once a appliance is physical device than you have all of the above issues and usually multi-tenancy implementation is weak in most of physical appliances. Regards -Harshad On Oct 10, 2013, at 12:44 AM, Bob Melander (bmelande) bmela...@cisco.com wrote: Harshad, By service instance I referred to the logical entities that Neutron creates (e.g. Neutron's router). I see a service VM as a (virtual) host where one or several service instances can be placed. The service VM (at least if managed through Nova) will belong to a tenant and the service instances are owned by tenants. If the service VM tenant is different from service instance tenants (which is a simple way to hide the service VM from the tenants owning the service instances) then it is not clear to me how the existing access control in openstack will support pinning the service VM to a particular tenant owning a service instance. Thanks, Bob From: Harshad Nakil hna...@contrailsystems.com Reply-To: OpenStack Development Mailing List openstack-dev@lists.openstack.org Date: onsdag 9 oktober 2013 18:56 To: OpenStack Development Mailing List openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Neutron] Service VM discussion - Use Cases Admin creating service instance for a tenant could common use case. But ownership of service can be controlled via already existing access control mechanism in openstack. If the service instance belonged to a particular project then other tenants should by definition should not be able to use this instance. On Tue, Oct 8, 2013 at 11:34 PM, Bob Melander (bmelande) bmela...@cisco.com wrote: For use case 2, ability to pin an admin/operator owned VM to a particular tenant can be useful. I.e., the service VMs are owned by the operator but a particular service VM will only allow service instances from a single tenant. Thanks, Bob From: Regnier, Greg J greg.j.regn...@intel.com Reply-To: OpenStack Development Mailing List openstack-dev@lists.openstack.org Date: tisdag 8 oktober 2013 23:48 To: openstack-dev@lists.openstack.org openstack-dev@lists.openstack.org Subject: [openstack-dev] [Neutron] Service VM discussion - Use Cases Hi, ** ** Re: blueprint: https://blueprints.launchpad.net/neutron/+spec/adv-services-in-vms Before going into more detail on the mechanics, would like to nail down use cases. Based on input and feedback, here is what I see so far. ** ** Assumptions: - a 'Service VM' hosts one or more 'Service Instances' - each Service Instance has one or more Data Ports that plug into Neutron networks - each Service Instance has a Service Management i/f for Service management (e.g. FW rules) - each Service Instance has a VM Management i/f for VM management (e.g. health monitor) Use case 1: Private Service VM Owned by tenant VM hosts one or more service instances Ports of each service instance only plug into network(s) owned by tenant** ** Use case 2: Shared Service VM Owned by admin/operator VM hosts multiple service instances The ports of each service instance plug into one tenants network(s) Service instance provides isolation from other service instances within VM Use case 3: Multi-Service VM Either Private or Shared Service VM Support multiple service types (e.g. FW, LB, …) ** ** - Greg ___ 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] Common requirements for services' discussion
Agree, I like what AWS had done. Have a concept of NAT instance. 90 % use cases are solved by just specifying Inside and outside networks for the NAT instance. If one wants fancier NAT config they can always use NATaas API(s) To configure this instance. There is a blueprint for bringing Amazon VPC API compatibility to nova and related extensions to quantum already propose concept of NAT instance. How the NAT instance is implemented is left to the plugin. Regards -Harshad On Oct 10, 2013, at 1:47 AM, Salvatore Orlando sorla...@nicira.com wrote: Can I just ask you to not call it NATaas... if you want to pick a name for it, go for Natasha :) By the way, the idea of a NAT service plugin was first introduced at the Grizzly summit in San Diego. One hurdle, not a big one however, would be that the external gateway and floating IP features of the L3 extension already implicitly implements NAT. It will be important to find a solution to ensure NAT can be configured explicitly as well while allowing for configuring external gateway and floating IPs through the API in the same way that we do today. Apart from this, another interesting aspect would be to be see if we can come up with an approach which will result in an API which abstracts as much as possible networking aspects. In other words, I would like to avoid an API which ends up being iptables over rest, if possible. Regards, Salvatore On 10 October 2013 09:55, Bob Melander (bmelande) bmela...@cisco.comwrote: Hi Edgar, I'm also interested in a broadening of NAT capability in Neutron using the evolving service framework. Thanks, Bob From: Edgar Magana emag...@plumgrid.com Reply-To: OpenStack Development Mailing List openstack-dev@lists.openstack.org Date: onsdag 9 oktober 2013 21:38 To: OpenStack List openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Neutron] Common requirements for services' discussion Hello all, Is anyone working on NATaaS? I know we have some developer working on Router as a Service and they probably want to include NAT functionality but I have some interest in having NAT as a Service. Please, response is somebody is interested in having some discussions about it. Thanks, Edgar From: Sumit Naiksatam sumitnaiksa...@gmail.com Reply-To: OpenStack List openstack-dev@lists.openstack.org Date: Tuesday, October 8, 2013 8:30 PM To: OpenStack List openstack-dev@lists.openstack.org Subject: [openstack-dev] [Neutron] Common requirements for services' discussion Hi All, We had a VPNaaS meeting yesterday and it was felt that we should have a separate meeting to discuss the topics common to all services. So, in preparation for the Icehouse summit, I am proposing an IRC meeting on Oct 14th 22:00 UTC (immediately after the Neutron meeting) to discuss common aspects related to the FWaaS, LBaaS, and VPNaaS. We will begin with service insertion and chaining discussion, and I hope we can collect requirements for other common aspects such as service agents, services instances, etc. as well. Etherpad for service insertion chaining can be found here: https://etherpad.openstack.org/icehouse-neutron-service-insertion-chaining Hope you all can join. Thanks, ~Sumit. ___ 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] [Neutron] Service VM discussion - Use Cases
Hello Greg, Blueprint you have put together is very much in line what we have done in openContrail virtual services implementation. One thing that we have done is Service instance is a single type of service provided by virtual appliance. e.g. firewall or load-balancer etc Service instance itself can be made up one or more virtual machines. This will usually be case when you need to scale out services for performance reasons Another thing that we have done is introduced a concept of service template. Service template describes how the service can be deployed. Image specified in the template can also be snapshot of VM with cookie cutter configuration. service templates can be created by admins.Service instances are created by tenants (if allowed) using a service templates. So a a single firewall instance from vendor can be packaged as transparent L2 firewall in one template and in network L3 firewall in another template. Regards -Harshad On Tue, Oct 8, 2013 at 2:48 PM, Regnier, Greg J greg.j.regn...@intel.comwrote: Hi, ** ** Re: blueprint: https://blueprints.launchpad.net/neutron/+spec/adv-services-in-vms Before going into more detail on the mechanics, would like to nail down use cases. Based on input and feedback, here is what I see so far. ** ** Assumptions: - a 'Service VM' hosts one or more 'Service Instances' - each Service Instance has one or more Data Ports that plug into Neutron networks - each Service Instance has a Service Management i/f for Service management (e.g. FW rules) - each Service Instance has a VM Management i/f for VM management (e.g. health monitor) Use case 1: Private Service VM Owned by tenant VM hosts one or more service instances Ports of each service instance only plug into network(s) owned by tenant** ** Use case 2: Shared Service VM Owned by admin/operator VM hosts multiple service instances The ports of each service instance plug into one tenants network(s) Service instance provides isolation from other service instances within VM Use case 3: Multi-Service VM Either Private or Shared Service VM Support multiple service types (e.g. FW, LB, …) ** ** **- **Greg ___ 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
