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 <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>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 >> 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 > >
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
