Open Stack

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>
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>
Reply-To: OpenStack Development Mailing List <
openstack-dev at lists.openstack.org>
Date: onsdag 9 oktober 2013 18:56
To: OpenStack Development Mailing List <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
> 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>
> Reply-To: OpenStack Development Mailing List <
> openstack-dev at lists.openstack.org>
> Date: tisdag 8 oktober 2013 23:48
> To: "openstack-dev at lists.openstack.org" <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
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
   _______________________________________________
OpenStack-dev mailing list
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/fe846380/attachment.html>