Change some internal packages to be public so they can be used with the azurestack provider

[pbolduc]

The azurestack provider requires similar packages to the azurerm provider. For example, /terraform-provider-azurerm/azurerm/internal/locks. These packages need to be duplicated in the azurestack provider to be able to keep the datasources and resource code bases aligned. I have been trying to update the azurestack code base so that it is easier to implement missing features such as key vault or app services. Without the same or similar packages, the source code for the various data sources and resource will continue to diverge. At present, these packages could be make public.

• locks
• tags
• timeouts

There are probably more, but these are the ones I have been working with recently. Additional conversation on azurestack Converge changes from azurerm.

$ make build
==> Checking that code complies with gofmt requirements...
go install
azurestack\resource_arm_loadbalancer_backend_address_pool.go:12:2: use of internal package github.com/terraform-providers/terraform-provider-azurerm/azurerm/internal/locks not allowed
make: *** [build] Error 1

[tombuildsstuff]

hey @pbolduc

Thanks for opening this issue.

The internal packages in this repository are intentionally internal to prevent usage cross-package; since Go's autocomplete functionality has been suggesting using packages from AzureAD inside of AzureRM (and vica-versa) which has caused us sufficient build issues. Instead once the refactoring in this repository is further progressed we'll be porting some of these to the go-azure-helpers repository to allow them to be reused across the providers - but we're intentionally holding off doing so at this time.

Whilst certain functionality can be reused across Azure Stack and AzureRM - unfortunately there's significant differences in practice which means there's less code reusable than first appears. To use one example Validation within Azure (Public) depends on which region you're running on and which updates have been installed in that region, since breaking behavioural changes happen within API versions (including #4706 and #4707 this week). This is exacerbated within Azure Stack since the behaviour of the API depends on the version of Azure Stack being run and the version of the underlying Resource Provider (API) being run (note: I'm referring to 1.x.x of the Resource Provider version 2019-01-01, rather than 2017-01-01 vs 2019-01-01) which could diverge significantly from Azure Public.

With regard to the refactoring, we're still working through what makes sense for the Providers since we do want to encourage more code-reuse between them - however we're intentionally holding off backporting this refactoring to Azure Stack (and Azure AD) until this repository has stabilised further. That said in the interim it should be possible to port these packages across into Azure Stack to make that migration path easier (as you have done) which allows just updating the import path - and then we can refactor the rest (e.g. clients/resources into packages) later on if that eases porting resources?

Since we're planning to take a slightly different approach here (refactoring these into the common library once we've identified what can be shared) - I'm going to close this issue for the moment - however please let us know if there's anything else we can do in the interim to assist here :)

Thanks!

[pbolduc]

Thanks Tom. Look forward to seeing the Azure Stack provider get some love in the near future. Would be great to be able provision App Services and Key Vault into Azure Stack with Terraform.

[ghost]

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues.

If you feel this issue should be reopened, we encourage creating a new issue linking back to this one for added context. If you feel I made an error 🤖 🙉 , please reach out to my human friends 👉 hashibot-feedback@hashicorp.com. Thanks!