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?
I agree the terminology can be confusing. I intended the term 'Service VM' to mean the virtual machine that hosts one or more 'Service Instances', as Sumit points out is distinguished from the Neutron Logical (XaaS) Service. So a Neutron Logical Service may schedule a Service Instance on a new (or existing) Service VM. Greg Sumit Naiksatam sumitnaiksatam at gmail.com <mailto:openstack-dev%40lists.openstack.org?Subject=Re%3A%20%5Bopenstack-dev%5D%20%5BNeutron%5D%20Service%20VM%20discussion%20-%20Use%20Cases&In-Reply-To=%3CCAMWrLvhZtyc2v%2Bbh-98aVjhTw1kYek5MpCMPDWYWjGG1g-C1Pg%40mail.gmail.com%3E> Wed Oct 9 21:03:39 UTC 2013 * Previous message: [openstack-dev] [Neutron] Service VM discussion - Use Cases <http://lists.openstack.org/pipermail/openstack-dev/2013-October/016238.html> * Next message: [openstack-dev] [Neutron] Service VM discussion - Use Cases <http://lists.openstack.org/pipermail/openstack-dev/2013-October/016252.html> * Messages sorted by: [ date ]<http://lists.openstack.org/pipermail/openstack-dev/2013-October/date.html#16306> [ thread ]<http://lists.openstack.org/pipermail/openstack-dev/2013-October/thread.html#16306> [ subject ]<http://lists.openstack.org/pipermail/openstack-dev/2013-October/subject.html#16306> [ author ]<http://lists.openstack.org/pipermail/openstack-dev/2013-October/author.html#16306> 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 point on service templates, which I do agree is a helpful feature), we are not trying to introduce new tenant-facing abstractions in this blueprint. The work in this blueprint was envisioned to be a library module that will help service plugins to realize the service on VMs. Thanks, ~Sumit. On Tue, Oct 8, 2013 at 4:16 PM, Harshad Nakil <hnakil at contrailsystems.com<http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>>wrote: > 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" itself can be made up one or more virtual machines. > This will usually be case when you need to scale out services for > performance reasons > > Another thing that we have done is introduced a concept of service > template. Service template describes how the service can be deployed. Image > specified in the template can also be snapshot of VM with cookie cutter > configuration. > > service templates can be created by admins.Service instances are created > by tenants (if allowed) using a service templates. > > So a a single firewall instance from vendor can be packaged as transparent > L2 firewall in one template and in network L3 firewall in another template. > > Regards > -Harshad
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev