Open Stack

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:bmelande at 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" <hnakil at contrailsystems.com<mailto:hnakil at 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)" <bmelande at cisco.com<mailto:bmelande at 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 <hnakil at contrailsystems.com<mailto:hnakil at contrailsystems.com>>
Reply-To: OpenStack Development Mailing List <openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>>
Date: onsdag 9 oktober 2013 18:56
To: OpenStack Development Mailing List <openstack-dev at lists.openstack.org<mailto:openstack-dev at 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) <bmelande at cisco.com<mailto:bmelande at 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.regnier at intel.com<mailto:greg.j.regnier at intel.com>>
Reply-To: OpenStack Development Mailing List <openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>>
Date: tisdag 8 oktober 2013 23:48
To: "openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>" <openstack-dev at lists.openstack.org<mailto:openstack-dev at 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 at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

_______________________________________________
OpenStack-dev mailing list
OpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131010/119d7ef7/attachment-0001.html>