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
