Open Stack

Hi Sumit,

Please see inline.


On Oct 9, 2013, at 2:03 PM, Sumit Naiksatam <sumitnaiksatam at gmail.com<mailto:sumitnaiksatam at 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 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.

[Rudra] How do we handle interdependency between services within a service VM.
Since the ordering of services is often in the same order in most deployments (inbound
firewall/VPN, LB, gateway, outbound FW) it would be better if the template specifies most
of this information. Services in the pipeline may be turned on or off.

Based on the blueprint we already have the insertion modes: L2, routed, tap etc. The
interface count and interface connections to networks should be specified here. In
addition if a service plugin needs scaling then its not convenient for the plugin to
launch another service VM and manage the networking aspects.

Hence a template model can contain most of the information (image info, services offered,
service ordering, interface count and names, scaling, insertion mode etc). Launching of
service VMs (containing services) is then associated to template definition.

Thanks,
Rudra


Thanks,
~Sumit.


On Tue, Oct 8, 2013 at 4:16 PM, Harshad Nakil <hnakil at contrailsystems.com<mailto: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<mailto: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<mailto: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<mailto: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<mailto: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/5687d756/attachment.html>