Thanks Eduard! I will have a look at the PR later today/tomorrow. It is quite big, so it may take some time to review and I want to make sure I have time to review it properly.
Regarding the issue, there was already JCLOUDS-664 [1] to track this. As mentioned in previous threads, there are a couple contributors that were already working on Azure and their work is being tracked there. I think it would be better to have both approaches (the MS SDK and the rest api one) tracked on the same issue, so people have the whole context and understand why there are two implementations. If you're OK with this, I'll close JCLOUDS-818 as a duplicate. Thanks! Ignasi [1] https://issues.apache.org/jira/browse/JCLOUDS-664 On 9 February 2015 at 20:50, Eduard Koller (MS OPEN TECH) <edua...@microsoft.com> wrote: > 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
