Re: [openstack-dev] [Magnum] Containers and networking
I agree, that is my take too. Russell, since you lead the OVN session in Vancouver, would it be possible to include the VLAN-aware-vms BP in that session? Thanks, Bob From: Ian Wells ijw.ubu...@cack.org.ukmailto:ijw.ubu...@cack.org.uk Reply-To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Date: fredag 3 april 2015 13:17 To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Magnum] Containers and networking This puts me in mind of a previous proposal, from the Neutron side of things. Specifically, I would look at Erik Moe's proposal for VM ports attached to multiple networks: https://blueprints.launchpad.net/neutron/+spec/vlan-aware-vms . I believe that you want logical ports hiding behind a conventional port (which that has); the logical ports attached to a variety of Neutron networks despite coming through the same VM interface (ditto); and an encap on the logical port with a segmentation ID (that uses exclusively VLANs, which probably suits here, though there's no particular reason why it has to be VLANs or why it couldn't be selectable). The original concept didn't require multiple ports attached to the same incoming subnetwork, but that's a comparatively minor adaptation. -- Ian. On 2 April 2015 at 11:35, Russell Bryant rbry...@redhat.commailto:rbry...@redhat.com wrote: On 04/02/2015 01:45 PM, Kevin Benton wrote: +1. I added a suggestion for a container networking suggestion to the etherpad for neutron. It would be sad if the container solution built yet another overlay on top of the Neutron networks with yet another network management workflow. By the time the packets are traveling across the wires, it would be nice not to have double encapsulation from completely different systems. Yeah, that's what I like about this proposal. Most of the existing work in this space seems to result in double encapsulation. Now we just need to finish building it ... -- Russell Bryant __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron]Anyone looking at support for VLAN-aware VMs in Liberty?
Hi Eric, Cisco is also interested in the kind of VLAN trunking feature that your VLAN-aware VM’s BP describe. If this could be achieved in Liberty it’d be great. Perhaps your BP could be brought up during one of the Neutron sessions in Vancouver, e.g., the one on OVN since there seems to be some similarities? Thanks Bob From: Erik Moe erik@ericsson.commailto:erik@ericsson.com Reply-To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Date: fredag 8 maj 2015 06:29 To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [neutron]Anyone looking at support for VLAN-aware VMs in Liberty? Hi, I have not been able to work with upstreaming of this for some time now. But now it looks like I may make another attempt. Who else is interested in this, as a user or to help contributing? If we get some traction we can have an IRC meeting sometime next week. Thanks, Erik From: Scott Drennan [mailto:sco...@nuagenetworks.net] Sent: den 4 maj 2015 18:42 To: openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Subject: [openstack-dev] [neutron]Anyone looking at support for VLAN-aware VMs in Liberty? VLAN-transparent or VLAN-trunking networks have landed in Kilo, but I don't see any work on VLAN-aware VMs for Liberty. There is a blueprint[1] and specs[2] which was deferred from Kilo - is this something anyone is looking at as a Liberty candidate? I looked but didn't find any recent work - is there somewhere else work on this is happening? No-one has listed it on the liberty summit topics[3] etherpad, which could mean it's uncontroversial, but given history on this, I think that's unlikely. cheers, Scott [1]: https://blueprints.launchpad.net/neutron/+spec/vlan-aware-vms [2]: https://review.openstack.org/#/c/94612 [3]: https://etherpad.openstack.org/p/liberty-neutron-summit-topics __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron][api] Extensions out, Micro-versions in
Hi Salvatore, Two questions/remarks below. From: Salvatore Orlando sorla...@nicira.commailto:sorla...@nicira.com Reply-To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Date: onsdag 6 maj 2015 00:13 To: OpenStack Development Mailing List openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Subject: [openstack-dev] [neutron][api] Extensions out, Micro-versions in #5 Plugin/Vendor specific APIs Neutron is without doubt the project with the highest number of 3rd party (OSS and commercial) integration. After all it was mostly vendors who started this project. Vendors [4] use the extension mechanism to expose features in their products not covered by the Neutron API or to provide some sort of value-added service. The current proposal still allows 3rd parties to attach extensions to the neutron API, provided that: - they're not considered part of the Neutron API, in terms of versioning, documentation, and client support BOB There are today vendor specific commands in the Neutron CLI client. Such commands are prepended with the name of the vendor, like cisco_command and nec_command. I think that makes it quite visible to the user that the command is specific to a vendor feature and not part of neutron core. Would it be possible to allow for that also going forward? I would think that from a user perspective it can be convenient to be able to access vendor add-on features using a single CLI client. - they do not redefine resources defined by the Neutron API. BOB Does “redefine here include extending a resource with additional attributes? - they do not live in the neutron source tree The aim of the provisions above is to minimize the impact of such extensions on API portability. Thanks for reading and thanks in advance for your feedback, Salvatore The title of this post has been inspired by [2] (the message in the banner may be unintelligible to readers not fluent in european football) [1] https://review.openstack.org/#/c/136760/ [2] http://a.espncdn.com/combiner/i/?img=/photo/2015/0502/fc-banner-jd-1296x729.jpgw=738site=espnfc [3] http://specs.openstack.org/openstack/nova-specs/specs/kilo/implemented/api-microversions.html [4] By vendor here we refer either to a cloud provider or a company providing Neutron integration for their products. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron] [nfv] VM-based VLAN trunking blueprints
What scares me a bit about the “let’s find a common solution for both external devices and VMs” approach is the challenge to reach an agreement. I remember a rather long discussion in the dev lounge in HongKong about trunking support that ended up going in all kinds of directions. I work on implementing services in VMs so my opinion is definitely colored by that. Personally, proposal C is the most appealing to me for the following reasons: It is “good enough”, a trunk port notion is semantically easy to take in (at least to me), by doing it all within the port resource Nova implications are minimal, it seemingly can handle multiple network types (VLAN, GRE, VXLAN, … they are all mapped to different trunk port local VLAN tags), DHCP should work to the trunk ports and its sub ports (unless I overlook something), the spec already elaborates a lot on details, there is also already code available that can be inspected. Thanks, Bob From: Ian Wells ijw.ubu...@cack.org.ukmailto:ijw.ubu...@cack.org.uk Reply-To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Date: torsdag 23 oktober 2014 23:58 To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [neutron] [nfv] VM-based VLAN trunking blueprints There are two categories of problems: 1. some networks don't pass VLAN tagged traffic, and it's impossible to detect this from the API 2. it's not possible to pass traffic from multiple networks to one port on one machine as (e.g.) VLAN tagged traffic (1) is addressed by the VLAN trunking network blueprint, XXX. Nothing else addresses this, particularly in the case that one VM is emitting tagged packets that another one should receive and Openstack knows nothing about what's going on. We should get this in, and ideally in quickly and in a simple form where it simply tells you if a network is capable of passing tagged traffic. In general, this is possible to calculate but a bit tricky in ML2 - anything using the OVS mechanism driver won't pass VLAN traffic, anything using VLANs should probably also claim it doesn't pass VLAN traffic (though actually it depends a little on the switch), and combinations of L3 tunnels plus Linuxbridge seem to pass VLAN traffic just fine. Beyond that, it's got a backward compatibility mode, so it's possible to ensure that any plugin that doesn't implement VLAN reporting is still behaving correctly per the specification. (2) is addressed by several blueprints, and these have overlapping ideas that all solve the problem. I would summarise the possibilities as follows: A. Racha's L2 gateway blueprint, https://blueprints.launchpad.net/neutron/+spec/gateway-api-extension, which (at its simplest, though it's had features added on and is somewhat OVS-specific in its detail) acts as a concentrator to multiplex multiple networks onto one as a trunk. This is a very simple approach and doesn't attempt to resolve any of the hairier questions like making DHCP work as you might want it to on the ports attached to the trunk network. B. Isaku's L2 gateway blueprint, https://review.openstack.org/#/c/100278/, which is more limited in that it refers only to external connections. C. Erik's VLAN port blueprint, https://blueprints.launchpad.net/neutron/+spec/vlan-aware-vms, which tries to solve the addressing problem mentioned above by having ports within ports (much as, on the VM side, interfaces passing trunk traffic tend to have subinterfaces that deal with the traffic streams). D. Not a blueprint, but an idea I've come across: create a network that is a collection of other networks, each 'subnetwork' being a VLAN in the network trunk. E. Kyle's very old blueprint, https://blueprints.launchpad.net/neutron/+spec/quantum-network-bundle-api - where we attach a port, not a network, to multiple networks. Probably doesn't work with appliances. I would recommend we try and find a solution that works with both external hardware and internal networks. (B) is only a partial solution. Considering the others, note that (C) and (D) add significant complexity to the data model, independently of the benefits they bring. (A) adds one new functional block to networking (similar to today's routers, or even today's Nova instances). Finally, I suggest we consider the most prominent use case for multiplexing networks. This seems to be condensing traffic from many networks to either a service VM or a service appliance. It's useful, but not essential, to have Neutron control the addresses on the trunk port subinterfaces. So, that said, I personally favour (A) is the simplest way to solve our current needs, and I recommend paring (A) right down to its basics: a block that has access ports that we tag with a VLAN ID, and one trunk port that has all of the access
Re: [openstack-dev] [neutron] [nfv] VM-based VLAN trunking blueprints
I suppose this BP also has some relevance to such a discussion. https://review.openstack.org/#/c/100278/ / Bob On 2014-10-22 15:42, Kyle Mestery mest...@mestery.com wrote: There are currently at least two BPs registered for VLAN trunk support to VMs in neutron-specs [1] [2]. This is clearly something that I'd like to see us land in Kilo, as it enables a bunch of things for the NFV use cases. I'm going to propose that we talk about this at an upcoming Neutron meeting [3]. Given the rotating schedule of this meeting, and the fact the Summit is fast approaching, I'm going to propose we allocate a bit of time in next Monday's meeting to discuss this. It's likely we can continue this discussion F2F in Paris as well, but getting a head start would be good. Thanks, Kyle [1] https://review.openstack.org/#/c/94612/ [2] https://review.openstack.org/#/c/97714 [3] https://wiki.openstack.org/wiki/Network/Meetings ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][L3] Agent manager customization
Hi Zzelle, Carl and others, We’ve been doing work on a more modular agent whose responsibilities are basically to: 1: apply configurations in devices when Neutron service resources (like Neutron Routers) are created or updated. 2: monitor the health of devices hosting such service resources Our starting point was the l3 agent which we’ve then evolved to become a configuration agent. It can perform configurations in remote devices so it does not have to run locally on the device it configures (this helps to reduce agent reporting traffic and thus the load on the Neutron service) It makes use of device drivers that knows how to instantiate/manipulate service resources in devices of the type that the driver handles. It also introduces what we call service helpers. Such a helper (a python class) essentially describes the workflow that should be used to create/update Neutron resources of a certain type. At the moment we have a single service helper for Neutron routing service but our thinking is to take this one step further and allow for different service helpers for each service. That would allow for pretty much completely different workflows to be used if a Neutron router is implemented in say a device of type A, vs if it is implemented in device of type B. Perhaps something like the config agent could help handling some of the complexities you bring up. In case your interested you can have a look at the BP for the config agent. The link for blueprint spec is: https://review.openstack.org/#/c/90729/ We hope to at least briefly be able to bring up the configuration agent in the design summit session on the service vm framework (on Friday, shared session with Isaku Yamahata) as that is the context in which we started this work. Thanks, Bob From: ZZelle zze...@gmail.commailto:zze...@gmail.com Reply-To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Date: torsdag 24 april 2014 00:34 To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Neutron][L3] Agent manager customization Hi Carl, A clear l3 agent manager interface with hookable methods would clearly simplify the understanding, the dev/support. Difficulties: 1. (un)deployment method names are associated to the triggering event not to performed action: - router deployment is done by _router_added - router gateway deployment/config is done by external_gateway_added - more generally (un)deployments are done by the associated *_added and *_removed methods It implies to fully understand the behaviour of the L3 agent manager in order to check that (un)deployment actions are done and only done by the associated triggering event methods. 2. Because docstrings are missing, i needed to double check previous check. 3. Customization testing is not really easy, because inherited manager implementation could change. So i preferred to perform only black box tests to reduce coupling between implementation and tests. 4. Support: extending a class without a contract/interface implies to perform some adaptations/checks (not so much in practice) simplified by previous tests But that's the topic ! 5. It's not possible currently to change l3 agent manager through configuration - so i must develop my own neutron-l3-agent binary implementation in order to allow providing a custom manager to main() - i must verify my binary was not erased during updates Awkward: 6. (un)deployment methods get the router RouterInfo using different strategies: - _router_added builds it and stores it in self.router_info cache - _router_removed get it from self.router_info cache - external_gateway/internal_network_added/removed get it through arguments 7._router_added and _process_routers have strange behaviours: - _process_routers calls _router_added will verifying to build router RouterInfo object - _router_added computes the router RouterInfo object and store it in self.router_info - _process_routers get it back from self.router_info IMHO, it seems more logical to let - _process_routers builds and stores router RouterInfo object and - _process_routers pass the object as an argument to _router_added The same might apply to _router_removed and _process_routers ? I must share with pcm about L3 Vendor plugins BPs to verify my understanding and possible synergies. But a priori [1] BP seems to be the only synergy candidate. Cedric [1] https://blueprints.launchpad.net/neutron/+spec/l3-svcs-vendor-validation On Tue, Apr 22, 2014 at 6:18 PM, Carl Baldwin c...@ecbaldwin.netmailto:c...@ecbaldwin.net wrote: Cedric, I'm just getting back from a short vacation. Please excuse the delayed reply. I have a feeling that this subject may have been discussed in the past before I was very active in Neutron. So, others may chime in if I'm missing
Re: [openstack-dev] Neutron Distributed Virtual Router
I agree. With your patch it ought to be possible to make the distributed router a provider type so to me it seems like a good match. Thanks, Bob From: Gary Duan gd...@varmour.commailto:gd...@varmour.com Reply-To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Date: måndag 23 december 2013 19:17 To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] Neutron Distributed Virtual Router Regarding using 'provider' in L3 router, for the BP 'L3 service integration with service framework', I've submitted some code for review, which is using 'provider' in a same notion as other advanced services. I am not sure if it can be reused to describe 'centralized' and 'distributed' behavior. https://review.openstack.org/#/c/59242/ Thanks, Gary On Wed, Dec 11, 2013 at 2:17 AM, Salvatore Orlando sorla...@nicira.commailto:sorla...@nicira.com wrote: I generally tend to agree that once the distributed router is available, nobody would probably want to use a centralized one. Nevertheless, I think it is correct that, at least for the moment, some advanced services would only work with a centralized router. There might also be unforeseen scalability/security issues which might arise from the implementation, so it is worth giving users a chance to choose what router's they'd like. In the case of the NSX plugin, this was provided as an extended API attribute in the Havana release with the aim of making it the default solution for routing in the future. One thing that is worth adding is that at the time it was explored the ability of leveraging service providers for having a centralized router provider and a distributed one; we had working code, but then we reverted to the extended attribute. Perhaps it would be worth exploring whether this is a feasible solution, and whether it might be even possible to define flavors which characterise how routers and advanced services are provided. Salvatore On 10 December 2013 18:09, Nachi Ueno na...@ntti3.commailto:na...@ntti3.com wrote: I'm +1 for 'provider'. 2013/12/9 Akihiro Motoki mot...@da.jp.nec.commailto:mot...@da.jp.nec.com: Neutron defines provider attribute and it is/will be used in advanced services (LB, FW, VPN). Doesn't it fit for a distributed router case? If we can cover all services with one concept, it would be nice. According to this thread, we assumes at least two types edge and distributed. Though edge and distributed is a type of implementations, I think they are some kind of provider. I just would like to add an option. I am open to provider vs distirbute attributes. Thanks, Akihiro (2013/12/10 7:01), Vasudevan, Swaminathan (PNB Roseville) wrote: Hi Folks, We are in the process of defining the API for the Neutron Distributed Virtual Router, and we have a question. Just wanted to get the feedback from the community before we implement and post for review. We are planning to use the “distributed” flag for the routers that are supposed to be routing traffic locally (both East West and North South). This “distributed” flag is already there in the “neutronclient” API, but currently only utilized by the “Nicira Plugin”. We would like to go ahead and use the same “distributed” flag and add an extension to the router table to accommodate the “distributed flag”. Please let us know your feedback. Thanks. Swaminathan Vasudevan Systems Software Engineer (TC) HP Networking Hewlett-Packard 8000 Foothills Blvd M/S 5541 Roseville, CA - 95747 tel: 916.785.0937tel:916.785.0937 fax: 916.785.1815tel:916.785.1815 email: swaminathan.vasude...@hp.commailto:swaminathan.vasude...@hp.com mailto:swaminathan.vasude...@hp.commailto:swaminathan.vasude...@hp.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.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] Service VM discussion - Use Cases
While specification of which networks a service VM has interfaces on indicates which tenant(s) it serves, that by itself does not allow setting constraints on which tenants that VM will accept to serve. Setting such constraints could be taken a long way, almost like ACL. However, I'm not proposing something that extensive. Ability to flag that a certain VM should only allow to serve a single tenant (but still multiple service instances for that tenant) would cover a requirement we've been given in work we've done. Thanks, Bob From: Sumit Naiksatam sumitnaiksa...@gmail.commailto:sumitnaiksa...@gmail.com Reply-To: OpenStack Development Mailing List openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Date: onsdag 9 oktober 2013 23:09 To: OpenStack Development Mailing List openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Neutron] Service VM discussion - Use Cases Thanks Bob, I agree this is an important aspect of the implementation. However, apart from being able to specify which network(s) the VM has interfaces on, what more needs to be done specifically in the proposed library to achieve the tenant level isolation? Thanks, ~Sumit. On Tue, Oct 8, 2013 at 11:34 PM, Bob Melander (bmelande) bmela...@cisco.commailto: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.commailto:greg.j.regn...@intel.com Reply-To: OpenStack Development Mailing List openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Date: tisdag 8 oktober 2013 23:48 To: openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org openstack-dev@lists.openstack.orgmailto: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.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] Service VM discussion - Use Cases
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.commailto:hna...@contrailsystems.com Reply-To: OpenStack Development Mailing List openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Date: onsdag 9 oktober 2013 18:56 To: OpenStack Development Mailing List openstack-dev@lists.openstack.orgmailto: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.commailto: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.commailto:greg.j.regn...@intel.com Reply-To: OpenStack Development Mailing List openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Date: tisdag 8 oktober 2013 23:48 To: openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org openstack-dev@lists.openstack.orgmailto: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.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] Common requirements for services' discussion
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.commailto:emag...@plumgrid.com Reply-To: OpenStack Development Mailing List openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Date: onsdag 9 oktober 2013 21:38 To: OpenStack List openstack-dev@lists.openstack.orgmailto: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.commailto:sumitnaiksa...@gmail.com Reply-To: OpenStack List openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Date: Tuesday, October 8, 2013 8:30 PM To: OpenStack List openstack-dev@lists.openstack.orgmailto: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.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] Service VM discussion - Use Cases
Possibly but not necessarily. Some VMs have a large footprint, have multi-service capability and physical devices with capabilities sufficient for tenant isolation are not that rare (especially if tenants can only indirectly control them through a cloud service API). My point is that if we take into account, in the design, the case where multiple service instances are hosted by a single service VM we'll be well positioned to support other use cases. But that is not to say the implementation effort should target that aspect initially. Thanks, Bob 10 okt 2013 kl. 15:12 skrev Harshad Nakil hna...@contrailsystems.commailto:hna...@contrailsystems.com: 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.commailto: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.commailto:hna...@contrailsystems.com Reply-To: OpenStack Development Mailing List openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Date: onsdag 9 oktober 2013 18:56 To: OpenStack Development Mailing List openstack-dev@lists.openstack.orgmailto: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.commailto: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.commailto:greg.j.regn...@intel.com Reply-To: OpenStack Development Mailing List openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Date: tisdag 8 oktober 2013 23:48 To: openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org openstack-dev@lists.openstack.orgmailto: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.orgmailto:OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev
Re: [openstack-dev] [Neutron] Service VM discussion - Use Cases
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.commailto:greg.j.regn...@intel.com Reply-To: OpenStack Development Mailing List openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Date: tisdag 8 oktober 2013 23:48 To: openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org openstack-dev@lists.openstack.orgmailto: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
