What do do about vcloud-director

[Adrian Cole <ad...@gmail.com>]

Hi, team.

Some of you know that the vcloud-director api originally aimed to
replace the aging vcloud one in main. The one is main is targeted at
version 1.0, and may no longer exist in the wild. The one in labs is
very behind, but it does target a version of vcloud api that still
exists (1.5)

Even after raising a couple rounds of cleanup PRs, I believe the
current vcloud-director in labs is unsustainable to complete in its
current form. It aims to cover a vast amount of scenarios, and has
various eras of test approaches, some of which never repeated.

Eventhough it doesn't yet have compute support it has a codebase
significantly larger than other large apis, such as OpenStack Nova.
However, unlike OpenStack, it has no feature work done since September
of 2012.

We have a decision to make. Either we throw the api completely out,
someone steps up (probably 2 people needed), or we delete everything
not needed to complete the ComputeService Api.

If we throw it out, at least folks like me won't waste hours on it,
and instead spend them elsewhere. Also, our users won't get led on
with a several year empty promise.

If we have folks raise hands to complete it as-is, we should put a
timebox on it, even if that timebox is very long, such as 6 months. We
should also consider what happens if that steward stops supporting it,
as the team would be left with probably the largest codebase again.

If we do the trim approach, we need to get it down to something that
is maintainable by someone with passing interest, as that would be
congruent with the passing interest it has seen in the last 2 years.
We can punt those who wish wide api support to the vcloud sdk, yet
still have basic support available for those who need it.

Thoughts?
-A

Re: What do do about vcloud-director

[Andrew Phillips <ap...@qrmedia.com>]

> Thoughts?

My personal preference would be:

* remove the outdated vcloud API from core
* call for volunteers to spend time on vcloud-director; if someone  
steps forward, discuss a sensible approach and goal with them based on  
the available time. If nobody steps forward, remove it from labs
* direct immediate committer energy towards getting vSphere [1] *into*  
labs, ensuring we ask the important questions of what is driving this  
contribution, what future plans are etc.

Since vSphere is actually an attempt at contributing something *new*,  
and so hopefully has at least a little momentum behind it, I think our  
chance of actually helping users is greatest here.

ap

[1] https://github.com/jclouds/jclouds-labs/pull/61