This cloud proposal is new and different, and it will redesign and likely recode the existing VCL core. Although it seems different, this experimental architecture is designed to accommodate the current roadmap through a different architecture implementation. The fundamental assumption is that the most reasonable way to implement the roadmap outlined here ( ) is have the VCL core become resource agnostic. I believe that a resource agnostic VCL core can schedule fluid resources more flexibly by revising the daemon portion of the VCL architecture to be event driven. This modification allows the core to be resource agnostic and schedule a variety of fundamentally different resources through the use of resource specific resource managers.

Moreover, with the 2.X code base, the frontend and backend components are inseparable through a single database. No component in the architecture can be rethought, modified, or redesigned because the architecture requires a very high level of integration between all components in the frontend, backend, and database. For example, as the developer of the ESX netboot provisioning module (, most of the time was spent compensating for the static data model of the VCL core. Additionally, this new architecture will include a secure database abstraction layer instead of the use of insecure SQL executed without the use of prepared statements and welded to MySQL as the current architecture is.

I'd like to suggest the reuse of the existing API enabled VCL 2.X code base as a bare-metal resource manager, which can be driven by this experimental branch of VCL code. The existing VCL 2.x is well fitted to managing bare-metal resources. Through the proposed VCL architecture, the existing VCL 2.X code would manage bare-metal resources while allowing the new core to aggregate a variety of new and unforeseen resource environments. For example, VCL could schedule fluid resources more efficiently such as ESX, KVM, or XEN, or specialized resources such as Storage, J2EE environments, python execution environments, mainframe Z environments, etc ...


Brian Bouterse
Secure Open Systems Initiative

On May 11, 2009, at 3:23 PM, Josh Thompson wrote:

Hash: SHA1


I haven't finished reading through all of the details in the document you created in the wiki, but it seems to be a design document for a new/ different cloud system. I didn't see anything explaining how it relates to VCL in its current form or a roadmap providing a migration path from the current form to
what you've designed.

That aside, can you explain further why you are proposing this? I think I'm seeing a bit of a cart before the horse issue here where you've designed out something new before there's been any discussion on this list about whether
or not large parts of VCL should be redesigned.

After explaining your reasoning further, I think it would be a good idea for us (the community) to have a discussion on this list about any areas of VCL
that are needing to be redesigned.


On Monday May 11, 2009, Brian Bouterse wrote:
I propose exploring an alternative VCL architecture through an
experimental code branch at  This code would be housed in
the svn at as a branch, and would be explored/developed in
parallel with the current 2.X branch.  The purpose of this branch is
to explore a VCL architecture that allows the following:

To allow VCL manage fluid resources (virtualized) more effectively
Increase modularity by decoupling VCL components from a single,
monolithic database via APIs
Manage storage resources
Create a database abstraction layer
Increase image library confidentiality and integrity

I've put a first-pass design document on the apache VCL wiki which
outlines the architecture proposed with some level of detail.  That
document is located here:

I'd like feedback of all kinds from the Apache VCL community to
explore the architecture's merits and challenges at both the
architectural and implementation levels.


Brian Bouterse
Secure Open Systems Initiative
- --
- -------------------------------
Josh Thompson
Systems Programmer
Virtual Computing Lab (VCL)
North Carolina State University

my GPG/PGP key can be found at
Version: GnuPG v1.4.6 (GNU/Linux)


Reply via email to