On 20 May 2016 at 11:46, Ignasi Barrera <n...@apache.org> wrote:
> 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
