Hi Brian,

I have some additional concerns.

Don't take this the wrong way, it's great to think ahead, but I not sure this is the right time for such a major proposal.

As you know the apache VCL project is still in incubation stage and we're struggling to get off the ground, grow the community, cut the first release, name change issues, etc. Proposing a major Architecture change at this time is probably not the best approach in working through the other tasks, it's going to muddy the waters even more. As Josh mentioned maybe a better approach is to start discussions on the list around areas of improvement for the existing VCL code base before jumping directly to a redesign/architecture change. If the improvements require an architecture change then great, else if the changes can be added in to existing code base also great.

Best Regards,

--On May 11, 2009 3:23:23 PM -0400 Josh Thompson <josh_thomp...@ncsu.edu> 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 Apache.org.  This code would be housed in
the svn at apache.org 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:
tur e+Document

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 pgp.mit.edu
Version: GnuPG v1.4.6 (GNU/Linux)


Aaron Peeler
OIT Advanced Computing
College of Engineering-NCSU

Reply via email to