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 <[email protected]> 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 <[email protected]> wrote: > > + Adrian > > > > On Fri, Feb 27, 2015 at 9:16 AM, Vineet Saini <[email protected]> > > 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 > >> <[email protected]> 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 <[email protected]> > >>> 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 < > [email protected]> > >>>> 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. > >> > >> > > >
