jclouds-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Duncan Johnston Watt <duncan.johnstonw...@cloudsoftcorp.com>
Subject Re: Removal vcloud and vcloud-director from jclouds in version 1.9.0
Date Fri, 28 Nov 2014 14:27:44 GMT

Reality is that VMware have failed to step up.

The guy we thought could be our internal champion at VMware has left!!

Cloudsoft intends to continue to provide VMware support for specific
customers but as Adrian has noted this will have to be done in a separate
fork or via alternative means.

VMware clearly has no respect for the community effort or the value of
jclouds which is a shocker especially compared with other folk like HP,
Google and Rackspace.



On 18 November 2014 at 16:19, Vineet Saini <switchcodes2@gmail.com> wrote:

> Not sure If I read it right, does this mean VCloud support will be removed
> in 1.8.x onward?
> This will be big dent for Jcloud users.
> On Sun, Nov 16, 2014 at 11:26 PM, Adrian Cole <adrian.f.cole@gmail.com>
> wrote:
>> TL;DR;
>> jclouds will stop maintaining vcloud in 1.8.x. We will remove vcloud
>> (and the vcloud-director labs provider) in version 1.9.0.
>> Our vcloud codebase is old, unsupported by cloud providers and a
>> crippling maintenance debt on the project. If we want jclouds to
>> endure, we have to make difficult decisions such as this.
>> The removal of vcloud is being tracked in the following jira
>> https://issues.apache.org/jira/browse/JCLOUDS-780
>> Best,
>> -A
>> Here's a copy of the description of JCLOUDS-780
>> For over a month, we've discussed the fate of vcloud [1]. For example,
>> we've already removed all vcloud providers as they no longer work with
>> version 1.0 [2]. Also users who contact us either run custom forks
>> [3], or also find features they need missing [4].
>> Eventhough the replacement code was supposed to be vcloud-director, it
>> has never left labs, and has too much technical debt to continue
>> attempting to support [5].
>> A couple stakeholders have offered they may be able to help [6], or
>> encourage vmware to add a new api to cover modern products [7].
>> Good wishes aside, the facts remain that we have 2 aging apis, that
>> are unsupportable in current form. Keeping vcloud and vcloud-director
>> codebases limits the project's ability to move forward, so we must
>> drop them.
>> Users who wish to continue on either codebase will need to maintain
>> their own fork.
>> When it comes time to start vcloud products again, we'll want to start
>> very small, with at least 2 champions, and some means to keep tests
>> passing. If we don't, we'll surely repeat history again.
>> [1] http://markmail.org/thread/4p22wkbrd4mncmss
>> [2] https://issues.apache.org/jira/browse/JCLOUDS-743
>> [3] http://markmail.org/message/gxcl37zq2pnn22sf
>> [4] http://markmail.org/thread/ligd5sbkmvoo7vdi
>> [5] http://markmail.org/thread/s5i6i4nr6f5k5wew
>> [6] http://markmail.org/thread/5fav2wa6ylxbqpdy
>> [7] http://markmail.org/thread/q4otznoqoygrz64b

Duncan Johnston-Watt
CEO | Cloudsoft Corporation

Twitter | @duncanjw
Mobile | +44 777 190 2653
Skype | duncan_johnstonwatt
Linkedin | www.linkedin.com/in/duncanjohnstonwatt

Cloudsoft Corporation Limited, Registered in Scotland No: SC349230.
Registered Office: 13 Dryden Place, Edinburgh, EH9 1RP

This e-mail message is confidential and for use by the addressee only. If
the message is received by anyone other than the addressee, please return
the message to the sender by replying to it and then delete the message
from your computer. Internet e-mails are not necessarily secure. Cloudsoft
Corporation Limited does not accept responsibility for changes made to this
message after it was sent.

Whilst all reasonable care has been taken to avoid the transmission of
viruses, it is the responsibility of the recipient to ensure that the
onward transmission, opening or use of this message and any attachments
will not adversely affect its systems or data. No responsibility is
accepted by Cloudsoft Corporation Limited in this regard and the recipient
should carry out such virus and other checks as it considers appropriate.

View raw message