Hi Janne,
Currently there is no way for a provider code to access another one,
as we haven't had such a use case yet. The main issue here is one
context having to contact a different api (different endpoint,
credentials, configuration properties, etc). There are two approaches
that come to my mind to make this possible:
1. Let the provider use the context builder to create a connection to
the other api.
- This means that when creating the context we should have to
supply all the info (endpoint, credentials, properties) required for
the additional API.
- We cannot reuse standard properties (identity, credential, and
others such as timeouts) as they could require different values for
each context.
- We'd also have to pass the list of modules that the second
context would need.
I see this option as very problematic, as there is many information
and possible conflicts that may appear between the two contexts.
2. Make one context "aware" of the existence of others, and let those
others be injected in the classes of the first provider. Something
like:
View one = ContextBuilder.newBuilder("..."). ... .build();
View two = ContextBuilder.newBuilder("...").linkedTo(one). ... .build();
And then make that context (or list of contexts) passed to the context
builder injectable in the code. In your case in the Azure
ImageExtension. Users should be responsible of properly creating and
closing each context, and they would be isolated.
The ComputeService now returns an Optional<ImageExtension> which value
is computed by testing the presence of an implementation of the
interface. In the case of Azure that will have to be changed to check
for the implementation *and* for the existence of the required "linked
context".
If this proposal looks OK, I'll work on it and try to open a PR with
the changes required in core asap.
(We really want this to be as generic as possible to let other
providers take benefit from this. For example the OpenStack Nova
ComputeService implemenation could look for a linked neutron context
and, if present, use neutron to perform all networking operations, and
fallback to nova networks otherwise.)
I.
On 19 May 2016 at 16:04, Janne Koskinen <j...@iki.fi> wrote:
> Hi Folks!
>
> I am Azure Compute ARM developer and currently working on ImageExtensionAPI.
> Creating custom images is straight forward with Azure but when Image is done,
> the listImages method of compute adapter is not listing these custom images.
> Only way to list custom images is to use Azure Blob Rest API which has own
> authentication and own endpoint and it is not related to Compute REST API.
>
> Best available option is to use jClouds Blob API to list the images but that
> will make blob API dependency to Azure Compute API. Is that problem? If
> answer is yes, what do you recommend?
>
> Br,
> Janne
