Support for Azure storage in module source

[fmuntean]

I could not find any information on how to create my own source for modules.
I see some are already built in but for example there is no support for Azure Storage where there is support for AWS storage.
Can someone point me on the http url implementation ? and the S3:: implementation?
I need to build my own that will allow me to call specific APIs which requires headers.
I do not see how headers like API Keys can be passed using the HTTP URLs: https://www.terraform.io/language/modules/sources#http-urls

I like the approach done for S3 bucket where it is using the prefix s3:: but how can I handle my own prefix ?

[jbardin]

Hello,

We use GitHub issues for tracking bugs and enhancements, rather than for questions. While we can sometimes help with certain simple problems here, it's better to use the community forum where there are more people ready to help.

Thanks!

[fmuntean]

I think this is an enhancement request to bring the module source up to pair between AWS and Azure.
It is not fair to support AWS storage but not the azure storage.
It looks that you prefer the AWS over the Azure for module sources.

[jbardin]

Sorry @fmuntean, I did not notice that on first read. In the future it would help to use the provided issue templates, which definitely aide in the triage process.

In this case however, there are existing issues open with the go-getter package which handles the underlying connections for fetching modules. We can link hashicorp/go-getter#33 and hashicorp/go-getter#373 from here, and mark this as upstream to see what can be done.

Thanks!

[bgmonroe]

It looks like there is a PR submitted last year (hashicorp/go-getter#395) waiting for approval/merge that will fix the upstream dependancy. Not sure what the holdup is.

[larsmaes-sogeti]

My PR has been open for some time, but no one is doing anything with it. I do not know why and I do not know who to reach out for...

[crw]

@larsmaes-sogeti The basic problem is that go-getter is being used by multiple projects, and changes are made as discreetly as possible to avoid breaking something that winds up broken in all projects. In this case, as a result of the conversation on this issue I asked the Azure Provider team to review your PR. However, I can't guarantee they will get to it soon or approve. On the plus side, at least it is getting a little attention. We are aware of how shared libraries like go-getter often slow progress on some of these issues and have discussed solutions, but nothing specific to report on that right now.