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