The last release that includes vcloud is jclouds 1.8.1 and the version it supports is 1.0. El 04/03/2015 18:21, "Vineet Saini" <switchcod...@gmail.com> escribió:
> If I have to use jcloud with vcloud, what version of jcloud I can use? > What was last release that supported Vcloud Director and api version? > > > On Wed, Mar 4, 2015 at 9:56 AM, Ignasi Barrera <n...@apache.org> wrote: > >> Vineet, if there is such resource we've never heared form it. >> Currently, vcloud is not supported in jclouds. we removed it for the >> already mentioned issues, and there is no plan to add it back. >> >> >> (Note, I've removed Adrian from the thread as he's no longer >> contributing to jclouds). >> >> >> On 4 March 2015 at 16:52, Vineet Saini <switchcod...@gmail.com> wrote: >> > + Adrian >> > >> > On Fri, Feb 27, 2015 at 9:16 AM, Vineet Saini <switchcod...@gmail.com> >> > wrote: >> >> >> >> >> >> At some point I read that got some resource from vmware to finally >> support >> >> vcloud with Jcloud? Not able to find that communication, is that true >> or we >> >> still continuing with deprecating support for vcloud? >> >> >> >> Also for my solution, I need to support it to work with VCloud >> Director. >> >> Any recommendation on jcloud version where to start with? This is for >> >> private VCloud setup. >> >> >> >> I have limited requirement to use jcloud api to create/delete node on >> >> demand and perform configuration accordingly. >> >> >> >> Vineet >> >> >> >> On Fri, Nov 28, 2014 at 8:27 AM, Duncan Johnston Watt >> >> <duncan.johnstonw...@cloudsoftcorp.com> wrote: >> >>> >> >>> Vineet >> >>> >> >>> 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. >> >>> >> >>> Best >> >>> >> >>> Duncan >> >>> >> >>> On 18 November 2014 at 16:19, Vineet Saini <switchcod...@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.c...@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. >> >> >> >> >> > >> > >
