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.
--On May 11, 2009 3:23:23 PM -0400 Josh Thompson <josh_thomp...@ncsu.edu>
-----BEGIN PGP SIGNED MESSAGE-----
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:
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.
Secure Open Systems Initiative
Virtual Computing Lab (VCL)
North Carolina State University
my GPG/PGP key can be found at pgp.mit.edu
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
-----END PGP SIGNATURE-----
OIT Advanced Computing
College of Engineering-NCSU