Re: [openstack-dev] [Neutron] Service VM discussion - Use Cases
Hi, Are we having IRC meeting every week. Can anyone please update me on the current plan based on the discussions we had at Havana Design Summit. Thanks in advance. Regards, Balaji.P From: Regnier, Greg J [mailto:greg.j.regn...@intel.com] Sent: Friday, October 11, 2013 3:30 AM To: OpenStack Development Mailing List Subject: 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]mailto:[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
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] 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] 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
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
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
Re: [openstack-dev] [Neutron] Service VM discussion - Use Cases
What about also allowing a specific service to request a port to be created on a requested server for an arbitrary service like a physical machine? I think we should think more in terms of s/VM/Instance where instance can really be either a VM or a Physical host since it really doesn't matter.. Endre 2013/10/9 Bob Melander (bmelande) bmela...@cisco.com 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
Re: [openstack-dev] [Neutron] Service VM discussion - Use Cases
Hi Rudra, We tried to separate policy from mechanism for this blueprint, and are trying to address the latter. I believe the logic for scaling, and or clustering multiple service VMs to map to a logical service instance would lie in the service plugin which realizes the logical service instance. Can you please elaborate on the service/use-case where you would need to plug the VM into different networks? Thanks, ~Sumit. On Tue, Oct 8, 2013 at 3:48 PM, Rudra Rugge rru...@juniper.net wrote: Hi Greg, Is there any discussion so far on the scaling of VMs as in launching multiple VMs for the same service. It would also have impact on the VIF scheme. How can we plug these services into different networks - is that still being worked on? Thanks, Rudra On Oct 8, 2013, at 2:48 PM, Regnier, Greg J greg.j.regn...@intel.com wrote: 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] Service VM discussion - Use Cases
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 hna...@contrailsystems.comwrote: 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 ___ 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
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.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
Re: [openstack-dev] [Neutron] Service VM discussion - Use Cases
Hi Sumit, I also got confused with service VM and service instance definition. I assumed both being the same and hence the networks question. Rudra On Oct 9, 2013, at 1:54 PM, Sumit Naiksatam sumitnaiksa...@gmail.commailto:sumitnaiksa...@gmail.com wrote: Hi Rudra, We tried to separate policy from mechanism for this blueprint, and are trying to address the latter. I believe the logic for scaling, and or clustering multiple service VMs to map to a logical service instance would lie in the service plugin which realizes the logical service instance. Can you please elaborate on the service/use-case where you would need to plug the VM into different networks? Thanks, ~Sumit. On Tue, Oct 8, 2013 at 3:48 PM, Rudra Rugge rru...@juniper.netmailto:rru...@juniper.net wrote: Hi Greg, Is there any discussion so far on the scaling of VMs as in launching multiple VMs for the same service. It would also have impact on the VIF scheme. How can we plug these services into different networks - is that still being worked on? Thanks, Rudra On Oct 8, 2013, at 2:48 PM, Regnier, Greg J greg.j.regn...@intel.commailto:greg.j.regn...@intel.com wrote: 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.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
Hi Sumit, Please see inline. On Oct 9, 2013, at 2:03 PM, Sumit Naiksatam sumitnaiksa...@gmail.commailto:sumitnaiksa...@gmail.com wrote: 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. [Rudra] How do we handle interdependency between services within a service VM. Since the ordering of services is often in the same order in most deployments (inbound firewall/VPN, LB, gateway, outbound FW) it would be better if the template specifies most of this information. Services in the pipeline may be turned on or off. Based on the blueprint we already have the insertion modes: L2, routed, tap etc. The interface count and interface connections to networks should be specified here. In addition if a service plugin needs scaling then its not convenient for the plugin to launch another service VM and manage the networking aspects. Hence a template model can contain most of the information (image info, services offered, service ordering, interface count and names, scaling, insertion mode etc). Launching of service VMs (containing services) is then associated to template definition. Thanks, Rudra Thanks, ~Sumit. On Tue, Oct 8, 2013 at 4:16 PM, Harshad Nakil hna...@contrailsystems.commailto:hna...@contrailsystems.com wrote: 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.commailto:greg.j.regn...@intel.com wrote: 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.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
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
Re: [openstack-dev] [Neutron] Service VM discussion - Use Cases
Hi Greg, Is there any discussion so far on the scaling of VMs as in launching multiple VMs for the same service. It would also have impact on the VIF scheme. How can we plug these services into different networks - is that still being worked on? Thanks, Rudra On Oct 8, 2013, at 2:48 PM, Regnier, Greg J greg.j.regn...@intel.commailto:greg.j.regn...@intel.com wrote: 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
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
