Re: [openstack-dev] [Neutron] Service VM discussion - Use Cases
The use cases defined (so far) cover these cases: Single service instance in a single service VM (agree this avoids complexity pointed out by Harshad) Multiple service instances on a single service VM (provides flexibility, extensibility) Not explicitly covered is the case of a logical service across 1 VM. This seems like a potentially common case, and can be added. But implementation-wise, when a service wants to span multiple service VMs, it seems that is a policy and scheduling decision to be made by the service plugin. Question: Does the multiple VM use case put any new requirements on this framework (within its scope as a helper library for service plugins)? Thx, Greg From: Bob Melander (bmelande) [mailto:bmela...@cisco.com] Sent: Thursday, October 10, 2013 12:48 PM To: OpenStack Development Mailing List Cc: OpenStack Development Mailing List Subject: 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
Re: [openstack-dev] [Neutron] Service VM discussion - Use Cases
Hi, The original use cases I called out include multiple service instances within a single VM, but not your use case of a single logical service spread across multiple VMs for scale-out. Have you identified requirements for these VMs that might be specified within the scope of this blueprint? I agree the terminology can be confusing. I intended the term 'Service VM' to mean the virtual machine that hosts one or more 'Service Instances', as Sumit points out is distinguished from the Neutron Logical (XaaS) Service. So a Neutron Logical Service may schedule a Service Instance on a new (or existing) Service VM. Greg Sumit Naiksatam sumitnaiksatam at gmail.com mailto:openstack-dev%40lists.openstack.org?Subject=Re%3A%20%5Bopenstack-dev%5D%20%5BNeutron%5D%20Service%20VM%20discussion%20-%20Use%20CasesIn-Reply-To=%3CCAMWrLvhZtyc2v%2Bbh-98aVjhTw1kYek5MpCMPDWYWjGG1g-C1Pg%40mail.gmail.com%3E Wed Oct 9 21:03:39 UTC 2013 * Previous message: [openstack-dev] [Neutron] Service VM discussion - Use Cases http://lists.openstack.org/pipermail/openstack-dev/2013-October/016238.html * Next message: [openstack-dev] [Neutron] Service VM discussion - Use Cases http://lists.openstack.org/pipermail/openstack-dev/2013-October/016252.html * Messages sorted by: [ date ]http://lists.openstack.org/pipermail/openstack-dev/2013-October/date.html#16306 [ thread ]http://lists.openstack.org/pipermail/openstack-dev/2013-October/thread.html#16306 [ subject ]http://lists.openstack.org/pipermail/openstack-dev/2013-October/subject.html#16306 [ author ]http://lists.openstack.org/pipermail/openstack-dev/2013-October/author.html#16306 Hi Harshad, I agree with you that the service instance terminology might be a little confusing here. The way it was phrased in the original email, I believe it was meant to suggest an association with the corresponding Neutron logical service (the XaaS to be precise). That said (and to your point on service templates, which I do agree is a helpful feature), we are not trying to introduce new tenant-facing abstractions in this blueprint. The work in this blueprint was envisioned to be a library module that will help service plugins to realize the service on VMs. Thanks, ~Sumit. On Tue, Oct 8, 2013 at 4:16 PM, Harshad Nakil hnakil at contrailsystems.comhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-devwrote: 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 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[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] [Neutron] Re: Service VM discussion - mgmt ifs
RE: vlan trunking support for network tunnels Copying to dev mailing list. - Greg -Original Message- From: Kyle Mestery (kmestery) [mailto:kmest...@cisco.com] Sent: Thursday, October 03, 2013 6:33 AM To: Bob Melander (bmelande) Cc: Regnier, Greg J Subject: Re: Service VM discussion - mgmt ifs On Oct 3, 2013, at 1:56 AM, Bob Melander (bmelande) bmela...@cisco.com wrote: The N1kv plugin only uses VXLAN but for that tunneling method the VLAN trunking is supported. The way it works is that each VXLAN is mapped to a *link local* VLAN. That technique is pretty much amenable to any tunneling method. There is a blueprint for trunking support in Neutron written by Kyle (https://blueprints.launchpad.net/neutron/+spec/quantum-network-bundle-api). I think that it would be very useful for the service VM framework if at least the ML2 and OVS plugins would implement the above blueprint. I think this blueprint would be worth shooting for in Icehouse. I can flesh it out a bit more so there is more to see on it and we can target it for Icehouse if you guys think this makes sense. I think not only would it help the service VM approach being taken here, but for running OpenStack on OpenStack deployments, having a trunk port to the VM makes a lot of sense and enables more networking options for that type of testing. Thanks, Kyle We actually have an implementation also for the OVS plugin that supports its tunneling methods. But we have not yet attempted to upstream it. Thanks, Bob Ps. Thanks for inserting the email comments into the document. If we can extend it further in the coming weeks to get a full(er) picture then during summit we can identify/discuss suitable pieces to implement in phases during Iceberg timeframe. 3 okt 2013 kl. 01:13 skrev Regnier, Greg J greg.j.regn...@intel.com: Hi Bob, Does the VLAN trunking solution work with tenant networks that use (VxLAN, NVGRE) tunnels? Thanks, Greg From: Bob Melander (bmelande) [mailto:bmela...@cisco.com] Sent: Wednesday, September 25, 2013 2:57 PM To: Regnier, Greg J; Sumit Naiksatam; Rudrajit Tapadar (rtapadar); David Chang (dwchang); Joseph Swaminathan; Elzur, Uri; Marc Benoit; Sridar Kandaswamy (skandasw); Dan Florea (dflorea); Kanzhe Jiang; Kuang-Ching Wang; Gary Duan; Yi Sun; Rajesh Mohan; Maciocco, Christian; Kyle Mestery (kmestery) Subject: Re: Service VM discussion - mgmt ifs ... The service VM framework scheduler should preferably also allow selection of VIFs to host a logical resource's logical interfaces. To clarify the last statement, one use case could be to spin up a VM with more VIFs than are needed initially (e.g., if the VM does not support vif hot-plugging). Another use case is if the plugin supports VLAN trunking and attachement of the logical resource's logical interface to a network corresponds to trunking of a network on a VIF. There are at least three (or four) ways to dynamically plug a logical service resource inside a VM to networks: - Create a VM VIF on demand for the logical interface of the service resource (hot-plugging) - Pre-populate the VM with a set of VIFs that can be allocated to logical interfaces of the service resources - Create a set of VM VIFs (on demand or during VM creation) that carry VLAN trunks for which logical (VLAN) interfaces are created and allocated to service resources. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
