Open Stack

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131009/923d4893/attachment.html>