Hi Sumit, Please see inline.
On Oct 9, 2013, at 2:03 PM, Sumit Naiksatam <sumitnaiksa...@gmail.com<mailto: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 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 <hna...@contrailsystems.com<mailto:hna...@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.regn...@intel.com<mailto:greg.j.regn...@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@lists.openstack.org<mailto:OpenStack-dev@lists.openstack.org> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org<mailto:OpenStack-dev@lists.openstack.org> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org<mailto:OpenStack-dev@lists.openstack.org> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
