cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Huang <Alex.Hu...@citrix.com>
Subject RE: [ASFCS40] [DISCUSS] System VM strategy
Date Wed, 15 Aug 2012 04:20:17 GMT
> 
> We also have floated the idea of enabling anyone to create a valid system
> VM image, by defining the interface and operational requirements (perhaps
> also by providing puppet configuration manifests).  I really like this idea, and
> some of the work required to make that a possibility might be required to
> deal with ASF restrictions, so options like that should be on the table as well.
> 
> Thoughts? Comments? (even solutions would be good... ;-) )

I am firmly in this camp.  I believe this is what CloudStack is created to do but really have
not done a very good job of to this date.  Obviously, we can't do it by 4.0 but I believe
we should do the following.

1. Define the current functions provided by CloudStack as Services.  So that would be Virtual
Routing Service, Template Service (SSVM), and Console Proxy Service.  There will be more to
come but that's for later.
2. Define that a service can be launch in three manners:
	a. As a process auto-launched by the management server in a dev environment
	b. As a process launched by the administrator
	c. As a process running inside a Service VM (read current system vm) launched by cloud stack.
3. When the service completes boot process, it self-registers with a service directory (provided
by cloudstack)
4. CloudStack can only utilize functions related to a service if the Service Directory has
a service registered to use it.  (In case c, cloudstack can decide at that time to auto-scale
or let the admin scale the service vms.  In cases a and b, there's no scaling).
5. The template for the Service VM will have the following properties
	a. Should contain generic scripts to let it download and provision the service it is meant
to deploy with from cloudstack.
	b. Should be any linux based OS (too restrictive?)
                c. may not be part of the deployment.
	d. Can be put onto CS after CS starts by the administrator. 

This has the following benefits.
- Decouple the VM OS from the Services provided.
- Allow others to add more services to CloudStack without need to understand the CloudStack
code.
- Allow the VM OS to be deployed outside of the normal distribution as to not conflict with
the licensing.

Please comment.

--Alex

Mime
View raw message