Open Stack

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>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
>
>
>
> On Tue, Oct 8, 2013 at 2:48 PM, Regnier, Greg J <greg.j.regnier at intel.com>wrote:
>
>>  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
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131009/889387d2/attachment.html>