[Openstack-operators] ServiceVM/Device manager project useful for operators?

Jesse Pretorius jesse.pretorius at gmail.com
Tue Jun 3 06:39:46 UTC 2014


On 3 June 2014 06:18, Yamahata, Isaku <isaku.yamahata at intel.com> wrote:

> I'm wondering we want to tackle ServiceVM/Device life cycle management
> [1][2] because I am NOT SURE if the framework is valuable to
> operators/users. Here ServiceVM means VM that runs (network) services.
>

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.
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.

I'd like to understand a few things:
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?
2) The reasons for splitting it out of Neutron are unclear, especially
since it will remain under the Neutron programme. Can you clarify this?

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20140603/0e67afc6/attachment.html>


More information about the OpenStack-operators mailing list