<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 3 June 2014 06:18, Yamahata, Isaku <span dir="ltr"><<a href="mailto:isaku.yamahata@intel.com" target="_blank">isaku.yamahata@intel.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I'm wondering we want to tackle ServiceVM/Device life cycle management<br>
[1][2] because I am NOT SURE if the framework is valuable to<br>
operators/users. Here ServiceVM means VM that runs (network) services.<br></blockquote><div><br></div><div>As I understand it, this is a project which aims to allow the deployment of 'service instances' for particular needs (eg: firewall appliance, load balancing appliance, anti-spam appliance, security probe appliance, monitoring proxy appliance, backup proxy appliance, etc) which are either dedicated or shared by projects but are invisible to end-users. In other words, they will consume a service exposed via an API (and a GUI in Horizon) but will not interact directly with the appliance.</div>
<div>This essentially makes room for making use of specialised appliances by vendors to provide network services - eg: A load balancing appliance from a vendor, rather than using HAProxy.</div><div><br></div><div>I'd like to understand a few things:</div>
<div>1) What is wrong with the current driver-based approach within the existing, for example, Neutron project. Currently we're able to deploy vendor appliances and expose their features by using drivers. How does the ServiceVM approach differ and what are the advantages of it?<br>
</div><div>2) The reasons for splitting it out of Neutron are unclear, especially since it will remain under the Neutron programme. Can you clarify this?</div><div><br></div><div>I'd like to say that I support the intent of the project. In our use-cases we would certainly find this useful - even if it would actually be to use as a framework/facility to develop other services which are still based on open source tooling. I just think that the current descriptions don't make it clear enough what the reasons are for going for this approach and it also doesn't make it clear enough what the typical use-cases would be.</div>
</div></div></div>