Re: [openstack-dev] [Neutron] Service VM discussion - Use Cases

2013-11-21 Thread Balaji P
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

Re: [openstack-dev] [Neutron] Service VM discussion - Use Cases

2013-10-10 Thread Bob Melander (bmelande)
: 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

Re: [openstack-dev] [Neutron] Service VM discussion - Use Cases

2013-10-10 Thread Bob Melander (bmelande)
: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

Re: [openstack-dev] [Neutron] Service VM discussion - Use Cases

2013-10-10 Thread Harshad Nakil
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

Re: [openstack-dev] [Neutron] Service VM discussion - Use Cases

2013-10-10 Thread Bob Melander (bmelande)
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

Re: [openstack-dev] [Neutron] Service VM discussion - Use Cases

2013-10-10 Thread Regnier, Greg J
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

Re: [openstack-dev] [Neutron] Service VM discussion - Use Cases

2013-10-09 Thread Bob Melander (bmelande)
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

Re: [openstack-dev] [Neutron] Service VM discussion - Use Cases

2013-10-09 Thread Endre Karlson
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..

Re: [openstack-dev] [Neutron] Service VM discussion - Use Cases

2013-10-09 Thread Sumit Naiksatam
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.

Re: [openstack-dev] [Neutron] Service VM discussion - Use Cases

2013-10-09 Thread Sumit Naiksatam
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

Re: [openstack-dev] [Neutron] Service VM discussion - Use Cases

2013-10-09 Thread Sumit Naiksatam
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

Re: [openstack-dev] [Neutron] Service VM discussion - Use Cases

2013-10-09 Thread Rudra Rugge
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

Re: [openstack-dev] [Neutron] Service VM discussion - Use Cases

2013-10-09 Thread Rudra Rugge
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

Re: [openstack-dev] [Neutron] Service VM discussion - Use Cases

2013-10-09 Thread Regnier, Greg J
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?

Re: [openstack-dev] [Neutron] Service VM discussion - Use Cases

2013-10-08 Thread Rudra Rugge
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,

Re: [openstack-dev] [Neutron] Service VM discussion - Use Cases

2013-10-08 Thread Harshad Nakil
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