Hi everyone, I created the following JIRA issue and pull request for the initial contribution
https://issues.apache.org/jira/browse/JCLOUDS-818 https://github.com/jclouds/jclouds-labs/pull/132 Thank you, Eduard -----Original Message----- From: Ross Gardler (MS OPEN TECH) [mailto:ross.gard...@microsoft.com] Sent: Friday, February 6, 2015 8:55 AM To: dev@jclouds.apache.org Subject: RE: Contributing Azure support At this time we have no intention of migrating to REST, that may change, but I'm not able to guarantee it at this time. If the community want to do the REST work then we'll work alongside that. This is a tried and tested mechanisms in Apache projects to allow parallel approaches are explored simultaneously. One approach will win out, either we'll agree REST is the way to go, our we'll agree there are other approaches that work. We could spend thousands of words on discussing this in the abstract case, but I'd rather get the code out there and discuss it in concrete form. There are very good reasons for doing it using the SDK, there are very good reasons for insisting on the REST approach. We should address each of these reasons as they come up in code. I don't believe it is helpful to make a blanket statement of x is better than y. Internally we are evaluating the REST vs SDK approach. Once that evaluation is complete we can engage in productive discussion about the best approach. But, at this time, I don't want to imply it is a given that we will spend our time contributing to a REST implementation. It isn't clear that such an approach is the right thing for JClouds (it's also unclear whether or approach is the right thing in the general case). What I am committing to is spending time addressing the issues at hand, in the most open and constructive way possible. I hope the JClouds community will be equally open to this approach. Together we will find the optimal approach. I believe our goal is the same as yours. A truly valuable implementation of JClouds Azure, where value is measured in terms of both code maintenance and usability. Ross Sent from my Windows Phone ________________________________ From: Ignasi Barrera<mailto:n...@apache.org> Sent: 2/6/2015 1:24 AM To: dev@jclouds.apache.org<mailto:dev@jclouds.apache.org> Subject: Re: Contributing Azure support The only thing that worries me about the SDK vs REST api is the uncertainity of "when" that change (required for promotion) will be made. We have always stated and made efforts to make it clear that providers in labs are not production ready. We can make non-backwards compatible changes there, completely refactor the interfaces, or even drop providers if there is no hope they can be promoted. However, despite all these well-known statements, people still uses providers in labs, and we have to (up to a certain level) care about that. As Andrea said, Apache Brooklyn will use the Azure support and, as other users, it will need it to be "jclouds compliant"; it will expect to provide the same feature set and architecture than other providers. We can live without this while in labs, but... when would the change/refactor to the rest API happen? This uncertainity is my only worry. As you said, in X months the initial contributors might not be active maintainers (it is ok, we can maintain and evolve it as long as we have a testing account), but if at that point the provider still uses the SDK, we'll be at a difficult position: we might not be able to assume the effort to rework the provider but there might be active users of it. We'll have a provider with very little hope to be promoted, but users depending on it, and would be bad for everyone. Experience shows that we should work on the tough parts when everyone is full of energy, and that moment is now, when starting the development. Also there are being active contributions to the existing Azure compute, and Andrea and Bhathiya are working on it now. They're doing a good job and I think we have to take that into account too, so I would propose the following: * Raise a pull request to add your provider to labs. This way we can see the ComputeService implementation and discuss it. * Use that implementation as a reference of "what we want", and the API calls that are needed to implement it. * Then implement those REST api calls in the existing azure compute provider. * And finally migrate the existing ComputeService implementation to use those rest api calls. This way I think we can join efforts: Andrea and Bhathiya already have good knowledge of how jclouds works, and them (and I) can start building the rest api calls based on the discussions of the ComputeService implementation. With your knowledge of how Azure works and how it should be used we can build the requirements for the ComputeService implementation, and join forces to build the underlying layer. Does this sound like a good plan? On 5 February 2015 at 19:18, Andrew Phillips <aphill...@qrmedia.com> wrote: >> Eduard (who has also joined this list) will work on the initial >> contribution in the coming days and we can start doing concrete stuff. > > > Great! Looking forward to seeing the code doing the talking ;-) > > Regards > > ap
