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:
