jclouds-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ryan Shoemaker <ryan.shoema...@enterprisedb.com>
Subject Re: warning during BlobStore.getBlobStore()
Date Tue, 18 Apr 2017 15:55:04 GMT
Thanks Ignasi.  So, it sounds like if I specify a region in our code, 
then these warnings will go away. Would I have to use 
RegionScopedBlobStoreContext?

--Ryan

On Apr16 5:39 AM, Ignasi Barrera wrote:
> Hi Ryan,
>
> The warning you're getting is particular to OpenStack. jclouds
> provides several internal classes to provide the existing regions,
> region ids, their corresponding URIs, etc. A group of those classes is
> what we call the "implicit" location suppliers, that just return the
> information of one location (region, szone, whatever), that will be
> used if the user does not specify a region when interacting with the
> cloud provider.
>
> Those implicit location suppliers are always initialized, and the
> default implementation looks for a region that has the same URI as the
> provider endpoint. In the case of OpenStack, the endpoint is always
> the Keystone endpoint, and that default logic does not "fit well",
> thus the warning you get. It just says that there is no better way to
> determine a "default/fallback" region than picking the first one.
>
> To be more specific, jclouds loads a Map of known region ids to
> endpoints, and then looking for the default region, it inspects that
> map and looks for the endpoint configured when creating the context.
> In the case of OpenStack, that map is built by inspecting the Service
> Catalog returned by Keystone, so the right endpoint for the service
> (swift, nova, etc) is configured for each region. That is done by
> using a custom implementation of the supplier that builds the
> mentioned map. You can read the implementation used for Keystone here
> [1]. I hope reading it will make more sense and show why you get he
> values you get in the map.
>
> Regarding that "FOO" key. It is just a convenience use of a Guava
> cache. There is an utility method to memoize a Supplier for a given
> amount of time, and short-circuiting any AuthenticationException to
> avoid having the supplier call the provider APIs when we already know
> authentication will fail (and this preventing potential account
> locks). The implementation of that supplier internally uses a Cache to
> deal with concurrency. It will actually hold just one value (the
> memoized one), and completely ignore any key (FOO) that is provided
> when client code asks for the cached value. I couldn't say why the
> Guava's LoadingCache is used instead of manually implementing the
> locking, or why the "Suppliers.memoizeWithExpiration" isn't used
> instead, which is thread-safe too.
>
>
>
> HTH!
>
> I.
>
>
> [1] https://github.com/jclouds/jclouds/blob/master/apis/openstack-keystone/src/main/java/org/jclouds/openstack/keystone/v2_0/suppliers/LocationIdToURIFromAccessForTypeAndVersion.java
>
> On 14 April 2017 at 00:28, Ryan Shoemaker
> <ryan.shoemaker@enterprisedb.com> wrote:
>> Hi,
>>
>> I've been seeing this warning pop out of my code for awhile and have finally
>> gotten around to investigating it:
>>
>> org.jclouds.location.suppliers.implicit.GetRegionIdMatchingProviderURIOrNull|_ThreadID=10;_ThreadName=Thread-2;|failed
>> to find key for value http://keystone.domainname.com:5000/v2.0 in
>> {uk=http://swift.domainname.com:8080/v1/AUTH_813b8f3ec69a460caf6efc2ea32bafb8};
>> choosing first: uk
>>
>> Why is there a mismatch between the uri and what's in the map?  The uri is
>> pointing to our keystone service and the map contains our swift service.
>> The actual log message appears to be coming from:
>>
>> org.jclouds.suppliers.SupplyKeyMatchingValueOrNull.get()
>>
>> As I was debugging this, I noticed this code on the stack:
>>
>> org.jclouds.rest.suppliers.MemoizedRetryOnTimeOutButNotOnAuthorizationExceptionSupplier.get()
>> (line 150)
>>
>> @Override
>> public T get() {
>>     try {
>>        return cache.get("FOO").orNull();
>>     } catch (UncheckedExecutionException e) {
>>        throw propagate(e.getCause());
>>     } catch (ExecutionException e) {
>>        throw propagate(e.getCause());
>>     }
>> }
>>
>> What's going on with that key name? Here's the calling code in my app - we
>> have a method to get the storage context:
>>
>> public BlobStoreContext getStorageContext(@Nullable String tenant) {
>>      String providerOrApi = ProviderFactory.getSupportedProviderFromId(
>>          user.getServiceProvider()).getObjectStorageProvider();
>>      Properties overrides = new Properties();
>>      overrides.setProperty(KeystoneProperties.CREDENTIAL_TYPE,
>> CredentialTypes.PASSWORD_CREDENTIALS);
>>
>>      ContextBuilder builder = ContextBuilder.newBuilder(providerOrApi)
>>          .credentials(tenant + ":" + serviceLogin, servicePassword)
>>          .endpoint(identityServiceEndpoint)
>>          .modules(ImmutableSet.of(new JDKLoggingModule(), new
>> JschSshClientModule()))
>>          .overrides(overrides);
>>
>>      return builder.buildView(BlobStoreContext.class);
>> }
>>
>> And then code grabs the context and calls getBlobStore() on it - this is
>> what causes the warning to be printed:
>>
>> BlobStoreContext storageContext = getStorageContext(firstTenant);
>> if (storageContext != null) {
>>      BlobStore blobStore = storageContext.getBlobStore();
>>      etc...
>>
>> We're running jclouds 2.0.0 on OpenStack.  Despite the warning, everything
>> appears to work fine. Thanks! --Ryan


Mime
View raw message