Add vSphere support #61
Conversation
|
jclouds » jclouds-labs #1029 FAILURE |
| @@ -0,0 +1,132 @@ | |||
| <?xml version="1.0" encoding="UTF-8"?> | |||
| <!-- | |||
| Copyright 2014 Cisco Systems, Inc | |||
There was a problem hiding this comment.
As per the ASF guidelines, there cannot be a copyright statement here, as far as I understand. Would you be able to remove this, @igreenfield?
Agree that this looks like a BuildHive problem again, @igreenfield. Let's wait to see what the DEV@cloud builder says... |
|
jclouds-labs-pull-requests #148 UNSTABLE |
This looks like a real test failure? There's also a bunch of Checkstyle violations. Could you possibly have a look at those, @igreenfield? If there are any questions about the test failure or the Checkstyle complaints, of course please let us know! |
|
I removed the copyright. |
|
jclouds » jclouds-labs #1031 FAILURE |
|
jclouds-labs-pull-requests #149 FAILURE |
|
@demobox After remove the copyright: Unapproved licenses: /scratch/jenkins/workspace/jclouds/jclouds-labs/vsphere/pom.xml |
|
jclouds » jclouds-labs #1032 SUCCESS |
|
jclouds-labs-pull-requests #150 SUCCESS |
|
jclouds » jclouds-labs #1033 SUCCESS |
|
jclouds-labs-pull-requests #151 SUCCESS |
|
Thanks for the contribution @igreenfield! Before going through the code to review it, there are a couple things to consider: Licensing Authorship attribution There have been several discussions in the ASF about the proper way to give credit to the submitted code. One of the points mentioned in that discussions was the convenience of including the To make sure your work here and Andrea's one is properly referenced, could you remove the |
|
Could you explain the Licensing section? |
|
Sure. This contribution you're submitting falls in the "Source File Headers for Code Developed at the ASF" category of the mentioned policy. Please, read the link in my comment. I assume you are the author of that code (regardless of if it is based on Andrea's one), so it is not a "third party submission". According to this, you should take care of addressing all points under the "Source File Headers for Code Developed at the ASF" category. Could you please do that? |
|
I am working on this code on my time at CISCO LTD. and I need to add this some where, where I can add this? |
|
Contributions made to the ASF must be under the terms of the Contributor License Agreements. That agreement implies a copyright and patent grant to the Apache Software Foundation for all software you and your employer contributes to the ASF. This means that the actual copyright owner of the software will be the ASF, and there's no need to include other copyright notices. NOTICE files are meant to reflect licensing and copyright details that must be kept for legal reasons (for example details from third party dependencies that are used by the project), but should not duplicate the terms of the LICENSE or include what it is already covered in the License Agreement. In this case, the first steps to get everything in place so this contribution can be properly merged should be:
|
|
We've been discussing the licensing thing in the dev mailing list (please, read the entire thread) to clarify how your contribution should be properly licensed. There is no need to send a CCLA, because the contribution terms are already covered in section 5 of the license. The copyright note in the header files, though, must be removed to meet the header policy. Regarding the "where you can add the copyright" question, and Quoting David:
If you or your company want the attribution note to be explicitly present, you could add it to a NOTICE file in the root of the project. But as per David's comment, we'd encourage you and your employer not to do that and just remove it from the header file, as all other individuals and companies that have contributed to jclouds have done. |
|
Thank you for your detailed research on the licensing topic, @nacx! |
|
jclouds-labs-pull-requests #290 FAILURE |
|
jclouds » jclouds-labs #1609 SUCCESS |
|
Hi @igreenfield! Thanks for sticking with this for so long! I'd briefly like to step back from the code for a second and get a better understanding of the background to the PR:
|
|
Getting a working working, supported vSphere support is very compelling for doing integration and automation in environments that have no IaaS support...which is most vCenter deployments. The vSphere API is extremely complicated and unpleasant to use. |
codefromthecrypt
force-pushed
the
master
branch
from
bcec4f6
to
c005ff7
Compare
|
Hi @demobox
|
|
jclouds-labs-pull-requests #328 FAILURE |
|
jclouds » jclouds-labs #1727 SUCCESS |
|
Hi @nacx , |
* Add checking configuration of devices.
|
jclouds-labs-pull-requests #332 FAILURE |
|
jclouds » jclouds-labs #1742 SUCCESS |
|
@demobox jdk1.7.0_72 solve the build problem |
|
Hi @igreenfield @if6was9 , I understand that the merge can be urgent, but many of the comments have still not being addressed (for example, the interfaces coupled to vijava). There have been recently several discussions about the providers in labs. You'll have seen that we've removed many of them, such as virtualbox, fcgp, jenkins, opsource-servers, and more. This is due to the fact that the labs repo has become a place where obsolete providers remain forever without maintenance, and make it really difficult to evolve the jclouds core and the main providers. Furthermore, several providers in labs are being used also in production, which makes it impossible to us to address major refactors without breaking many legacy (and unmaintained) code. The jclouds-labs repository should be a temporal place where providers can be tested, but with a limited TTL to be promoted to the main repo, or removed. This will improve the overall quality of jclouds itself, and users will have a clear understanding on the state of each provider. This said, I hope you understand that we can't merge providers in a state that is unlikely to be aligned with the way things are done in jclouds in a reasonable amount of time. I really appreciate all the effort that is being put in this PR, and I hope the reviews helped, but a project in this structure has no hope of being promoted out of labs. I suggest you host this code and publish your own snapshots. We will gladly send contributors your way if asked, but our only sustainable support for vsphere are cloud controllers such as cloudstack and openstack nova. See also: |
|
OK, From: Ignasi Barrera [mailto:notifications@github.com] Hi @igreenfieldhttps://github.com/igreenfield @if6was9https://github.com/if6was9 , I understand that the merge can be urgent, but many of the comments have still not being addressed (for example, the interfaces coupled to vijava). There have been recently several discussions about the providers in labs. You'll have seen that we've removed many of them, such as virtualbox, fcgp, jenkins, opsource-servers, and more. This is due to the fact that the labs repo has become a place where obsolete providers remain forever without maintenance, and make it really difficult to evolve the jclouds core and the main providers. Furthermore, several providers in labs are being used also in production, which makes it impossible to us to address major refactors without breaking many legacy (and unmaintained) code. The jclouds-labs repository should be a temporal place where providers can be tested, but with a limited TTL to be promoted to the main repo, or removed. This will improve the overall quality of jclouds itself, and users will have a clear understanding on the state of each provider. This said, I hope you understand that we can't merge providers in a state that is unlikely to be aligned with the way things are done in jclouds in a reasonable amount of time. I really appreciate all the effort that is being put in this PR, and I hope the reviews helped, but a project in this structure has no hope of being promoted out of labs. I suggest you host this code and publish your own snapshots. We will gladly send contributors your way if asked, but our only sustainable support for vsphere are cloud controllers such as cloudstack and openstack nova. See also: — |
|
My apologies for that. The "recover the labs essence" discussion was started after this PR was initially reviewed, and although the initial expectations have changed I hope people will understand that the change is for the benefit of jclouds. I really appreciate all the effort here and hope te review process has helped to put the vSphere provider in a better status. |
* move to Guava 1.7 * Fix BUG in getting host parameters.
|
jclouds-labs-pull-requests #355 FAILURE |
|
jclouds-labs-pull-requests #358 FAILURE |
|
jclouds » jclouds-labs #1809 SUCCESS |
|
jclouds-labs-pull-requests #360 FAILURE |
|
jclouds » jclouds-labs #1813 SUCCESS |
|
Thanks @igreenfield and agreed that we should have especially been careful around the vijava thing as this was attempted and rejected in the past. You'll notice we've also just dropped virtualbox for similar reasons. I'll point anyone who asks about jclouds vsphere to you, and thanks for giving it a go! |
No description provided.