Open Stack

Hi Jesse, thanks for reply.


On Tue, Jun 03, 2014 at 08:39:46AM +0200,
Jesse Pretorius <jesse.pretorius at gmail.com> wrote:

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

It also allows self-service use case. I.e. use is allowed to define
their own vm images and manipulate via openstack api.


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

With the current driver-based approach, each driver have to implement
their own life cycle logic. It results in code duplication and so on.
So it makes sense to provide common code base.


> 2) The reasons for splitting it out of Neutron are unclear, especially
> since it will remain under the Neutron programme. Can you clarify this?

Service instances in VMs is not always related to network.

Please refer to the thread of discussion
http://lists.openstack.org/pipermail/openstack-dev/2014-April/033291.html

thanks,

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

> _______________________________________________
> OpenStack-operators mailing list
> OpenStack-operators at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators


-- 
Isaku Yamahata <isaku.yamahata at gmail.com>