Merged t
[master](http://git-wip-us.apache.org/repos/asf/jclouds/commit/b76a594e)
([labs](http://git-wip-us.apache.org/repos/asf/jclouds-labs/commit/331fd685))
and [2.1.x](http://git-wip-us.apache.org/repos/asf/jclouds/commit/3878e6a6)
Closed #1210.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/1210#event-1639491145
andreaturli approved this pull request.
lgtm, thanks @nacx
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/1210#pullrequestreview-121530457
FTR: [JCLOUDS-1421](https://issues.apache.org/jira/browse/JCLOUDS-1421)
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/1210#issuecomment-390135482
Some context about what @nacx is talking about
https://stackoverflow.com/questions/50068324/azure-arm-api-returns-locations-with-inconsistent-case
It affects also other of the new regions (not only CanadaEast) and working on
it we discovered some unrelated issues like this one with the default
Well, yes and no :) @danielestevez is working on fixing jclouds to properly
support Azure CanadaEast region. The issue is that the Azure API sometimes
returns the region name lowercase, sometimes camelcase, etc, and that messes
things up when it comes to filter by location and do several
@nacx that sounds like a decent amount of work, I think we should file a jira
issue and properly track the change in the next release notes (ideally with a
blog post!) - wdyt?
didn't have time yet to review the PR, I'll do asap!
--
You are receiving this because you are subscribed to this
Good to know!
Then i guess it's again another problem with the caseInsensitive feature since
i always try in one of the problematic regions **CanadaEast**
Will investigate further
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on
>However testImageIsRemovedFromCacheAfterDeletion still fails it
>testSpawnNodeFromImage is enabled but that's a different issue.
I've just run the `AzureComputeImageExtensionLiveTest` in `northeurope` and
with this change all pass:
```bash
Running
nacx commented on this pull request.
> + // Otherwise fallback to the image default credentials strategy
+ if (template instanceof CloneImageTemplate) {
+ final CloneImageTemplate cloneImageTemplate = (CloneImageTemplate)
template;
+ future = Futures.transform(future,
@nacx pushed 1 commit.
3d44352 Add default credentials for all ImageTemplate types
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
danielestevez commented on this pull request.
> + // Otherwise fallback to the image default credentials strategy
+ if (template instanceof CloneImageTemplate) {
+ final CloneImageTemplate cloneImageTemplate = (CloneImageTemplate)
template;
+ future =
Tried and fixes the issues with the missing credentials in
_testSpawnNodeFromImage_ :+1:
However _testImageIsRemovedFromCacheAfterDeletion_ still fails it
_testSpawnNodeFromImage_ is enabled but that's a different issue.
--
You are receiving this because you are subscribed to this thread.
By default, when listing images the ComputeServiceAdapter adds the default
credentials for each image. This is not done when images are created by the
image extension, and NPEs can appear in code that assumes the default
credentials are there, as the field is not nullable.
This change tries to
14 matches
Mail list logo
