incubator-cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Huang <>
Subject RE: [RFC] Refactoring CloudStack
Date Wed, 14 Nov 2012 15:19:44 GMT
> Could you elaborate a bit on the new deployment plans (slides 19-21). It
> seems that you are aiming for more independent zones and a more reliable
> management layer, but I could not quite picture how you would actually
> deploy this.

The storyboard for deployment will look like this.

- Deploy CloudStack Cloud-Engine

- Cloud-Engine only has API, a CLI, and a very minimalistic UI.  You can registers zones,
pods, clusters, hosts, etc, just like before with Cloud-Engine but Cloud-Engine expects that
all setup to be done by you.  You are registering these things to use by Cloud-Engine but
Cloud-Engine doesn't know how to set it up.  If you're doing setup this way, you are basically
saying I can use something like chef to setup the physical resource.  After registering all
the appropriate pieces, you can launch VMs using the CLI talking to the API.

- On the UI is the options to launch Cloud-Management, Cloud-API, Cloud-Access(ACL), Cloud-Console(console-proxy),
and Cloud-Templates (SSVM).  More can be added via the plugin mechanism.  Upon launch, Cloud-Engine
will detect if physical resources have been registered.  If it has, then Cloud-Engine asks
the admin if they want to launch this as a web app on the same server or as a webapp hosted
by another VM.  If no hardware resource has been registered, then the only option is to launch
as a webapp on the same server.  Once the service has been launched, it has to register back
with Cloud-Engine in order for it to be used.

- Upon launch Cloud-Management:  Cloud-Management has the API, CLI, and current UI for OAMP
purposes.  It also supports a plugin mechanism that allows others to deploy helpful automation
scripts.  Once this is launched, then the user can use the normal UI approach to manage the
system.  Adding a host for example will be like before where Cloud-Management actually setups
up the host with what's needed to run CloudStack and then registers host to Cloud-Engine for

- Cloud-Management can probably be further dissected into three services: Service-provider
management service that handles support for the service-provider functionalities such as setting
up offerings and support for the end user, A system admin management service that handles
true system OAMP, and finally a service that is a container for different automation.  Currently
the plan is to have it all in Cloud-Management. 

- Upon launch Cloud-Access:  Cloud-Access contains the APIs for authentication, account access,
and ACL.  Launching this requires the admin to give it details on how to access the database.
 Cloud-Access database should be duplicated across zones.  That can be done in various ways
(for example, a  single master with multiple readers deployment of mysql) but the important
point here is that Cloud-Access is isolated from Cloud-Engine and its method of resilience
is different.  I suspect most will have it patch into their own db/ldap/ad backend which already
have some other way to do resilience.  Again Cloud-Access registers with Cloud-Engine for
it to be used by other components.

- Upon launching Cloud-API: Cloud-API contains API, CLI, and UI for the end user to use. 
Launching Cloud-API means providing it the Cloud-Engines it should plugin to.  Cloud-API then
connects to all the Cloud-Engines to gather the end user data and becomes the actual front-end.
 When Cloud-API says it is ready to be added into the API cluster, the admin adds it to the
GSLB service.

> On the componentization: I think it's great, but will this result in separate
> applications (like we AWSAPI now) ? and will these components still be
> tightly integrated from a packaging installation point of view ? My concern
> being that we should still aim for a "one-click" install of CloudStack versus
> several recipe to integrate many different components.

So it becomes several clicks rather than one click but you can see from above it should still
be rather painless.  I absolutely agree with you that we should not take away the ease of
deployment feature of CloudStack today and we will strive to make that a better experience
in fact.

> Last thing, which is really a software implementation choice, I was talking to
> the Java User Group in Geneva and mentioned that the community was
> looking at moving to the Spring framework, some folks were a little surprised,
> suggesting that there was better frameworks that could be used.

That's something being talked about in the OSGi and threads Kelven have started.  Please let
them know in those threads on what the suggestions are.


View raw message