Hi! Many thanks for reaching us and for willing to help with Azure. We really look forward to having good support for it, so all contributions are very welcome.
As you already summarized, the right place to start is in jclouds-labs. There we can discuss all the implementation details and start testing and using the provider while it is under development, and once it is in a good shape, it will get promoted to the main repo. To make that happen, the following must happen: * It is being maintained: This usually means that we need to be able to run live tests against the provider and someone takes care of it. In the case of Azure this shouldn't be an issue, as Microsoft provides limited free accounts for ASF committers that are enough to run the tests and hack on the provider. I've been using such an account while helping Adrian when he started the Azure compute provider, and it provides all we need, so I'd say this won't be an issue. * It has an abstraction. This is the important point. We need the ComputeService abstraction implemented in order promote the provider. jclouds is all about the abstractions and common interfaces, and this is the one that has to be implemented. That means: - The interface itself has to be implemented, like in other compute providers. - The AzureComputeServiceLiveTest must be created and should extend the BaseComputeServiceLiveTest [1]. You can look at the DigitalOcean one [2] for an example. - The AzureTemplateBuilderLiveTest must be created and should extend the BaseTemplateBuilderLiveTest [3]. You can have a look at the HPCloud one [4] for an example. These test classes are the "ComputeService contract". Once those live tests are passing, we know the abstraction is properly implemented and working as expected. * Code is up-to-date (tests, style, best practices). This is also important, and is especially relevant the fact that your implementation is currently using the Azure SDK. I completely understand that it can be more convenient to use it, but I have to say that the implementation should use the existing jclouds HTTP layer in order to be promoted. It is not just because "we do it this way"; there are several reasons behind this: - jclouds provides a driver mechanism that allows users to choose their preferred HTTP driver. Currently we support the Java default HttpUrlConnection, the Apache HTTP Client, and OkHttp. This one allows us to be Android friendly and use PATCH verbs and other stuff that is not supported in the default JRE implementation, so we need to make sure that users still have this choice when using Azure. The driver mechanism must work. - jclouds also provides a generic way of handling failure at the HTTP layer. It provides a generic fallback mechanism that allows every provider to configure the behavior when failure happens. This fallback delegation is generic and all providers benefit from it, and Azure shouldn't be an exception. We should be able to provide custom fallbacks to customize the behavior upon failure. - jclouds provides a generic retry policy that allows users to configure how and when failed request are retried. There are several implementations, but users can configure a more convenient one, if needed. - It also provides a generic way to configure request timeouts "per API method". Users can configure the timeout for each call, if they need to. These are the most relevant points (there are more but I think there's no need to enumerate everything here) that illustrate why we *need* and *require* providers and apis to use the jclouds built-in HTTP layer. Using the Azure SDK would mean that none of the above would be available, and that is something we can't justify just because "Azure was developed that way". So, to summarize, the development of the provider should be started in jclouds-labs, and the goals should be to implement the ComputeService interface and have the mentioned tests passing. Once that is working, we can safely say the provider works as expected. Regarding the usage of the Azure API, I'd say we can live with it in labs, but changing the provider to use the jclouds HTTP mechanisms is a must to have it promoted. I don't really know what is the best way to proceed: have the provider "as-is" now merged into labs and start working from there, or adapt what you already have and contribute to the existing azure provider. Take into account that we are trying to use the "labs" repo just for development, and providers should have a limited TTL there. We should try to avoid partially developed providers from staying there forever, so let's use this thread to come up with a plan to put Azure in the path to promotion Thanks again for your intereset! And please, don't take this email as a "no" or "not this way at all". I've just tried to explain the reasons behind what we require. We really look forward to having Azure in and your intereset in contributing is very much appreciated. I'll be more than happy to help with the development of the provider, provide guidance, and to align the code with what jclouds needs. Thanks! Ignasi [1] https://github.com/jclouds/jclouds/blob/master/compute/src/test/java/org/jclouds/compute/internal/BaseComputeServiceLiveTest.java [2] https://github.com/jclouds/jclouds-labs/blob/master/digitalocean/src/test/java/org/jclouds/digitalocean/compute/DigitalOceanComputeServiceLiveTest.java [3] https://github.com/jclouds/jclouds/blob/master/compute/src/test/java/org/jclouds/compute/internal/BaseTemplateBuilderLiveTest.java [4] https://github.com/jclouds/jclouds/blob/master/providers/hpcloud-compute/src/test/java/org/jclouds/hpcloud/compute/compute/HPCloudComputeTemplateBuilderLiveTest.java On 5 February 2015 at 07:29, Ross Gardler (MS OPEN TECH) <ross.gard...@microsoft.com> wrote: > Great thanks for the pointer. Even more thanks to Zack who took the time to > summarize that thread (if only more folks did that in other projects I work > on, including me!) > > Zacks summary, for the purposes of the archives is: > > Currently, most of us agree that the following criteria should be met, at a > minimum, before an API is promoted to jclouds/jclouds: > - It is being maintained > - It has an abstraction > - Code is up-to-date (tests, style, best practices) > > This all seems sensible. I don't want to start that thread again but I would > point out that the first criteria (it is being maintained) might be true on > promotion to core but no longer be true in x months time. Not a problem > today, but one day it is possible there will need to be a process for > retirement from core too. For the Azure support we'll focus on getting it > into core though :-) > > Looking at other modules that are in core I see there isn't a consistent > level of support for compute and storage (our current area of focus). Is > there a minimum bar at this point? Perhaps a test suite? No problem if this > is still being defined, we can use the Azure support as a use case for > defining that minimum bar if it is appropriate. > > Ross > > -----Original Message----- > From: Andrew Phillips [mailto:aphill...@qrmedia.com] > Sent: Wednesday, February 4, 2015 4:31 PM > To: dev@jclouds.apache.org > Subject: RE: Contributing Azure support > > Hi Ross > >> Thanks for the pointer John. Why is Blob in core and Compute in >> Labs? What is the criteria for leaving labs? > > See http://markmail.org/thread/zvsytdvzfeg4w2zi. In short, it's still an > ongoing discussion, but support for one of the abstraction layers (which is > true for both Azure BlobStore and Compute) is likely to be one of the key > ones. > > Great to see interest from your side in contributing! > > Regards > > ap
