-
Notifications
You must be signed in to change notification settings - Fork 1.5k
azurestackprivate Terraform Provider #5103
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: The full list of commands accepted by this bot can be found here. DetailsNeeds approval from an approver in each of these files:Approvers can indicate their approval by writing |
|
I will address the linting/vetting errors. The main piece of tech debt this would incur is that we would not be able to use our fork of azure-sdk-for-go without resolving these issues. We don't use our fork at the moment, so this is a hypothetical problem. |
a1e53c7 to
e6a1bce
Compare
|
Refactored a little which should hopefully make the go-vet test pass. Still need to fix go-lint. Was able to reduce the amount of code we are copying directly into the provider. |
e6a1bce to
40c7707
Compare
|
/retest |
f13f0c8 to
1a8320b
Compare
|
Depends on #5084 for the TF config |
8dc16ef to
99a262c
Compare
Adds support for an azurestack Terraform provider in order to upload a local RHCOS VHD OS image to an Azure Stack storage blob. This provider makes use of azure-vhd-utils to speed up download, because an RHCOS VHD is a fixed 16GB size but most of that is zero-padding. The azure-vhd-utils determines the amount of data that needs to be uploaded and cuts out the empty ranges, which in effect results in a 2.5GB upload rather than 16GB. Unfortunately the azure-vhd-utils library is quite old and uses version 5 of the azure-sdk-for-go (currently we are on version 55). Version 5 of the sdk was created before semantic versioning was in place in the repo, therefore there is no graceful way to import version 5 of the SDK because other parts of the installer depend on later versions of the SDK. To work around this issue, I have incorporated the upload package from the azure-vhd-utils directly into the terraform provider and updated it to import the openshift fork of the azure-sdk-for go, pinned to version 5. This technical debt would need to be incurred until the azure-vhd-utils is updated to a newer version of the SDK, which may never happen. The config.go is modeled after the azurestack provider, so the majority of the original work is in the resource_vhd_blob.go and then some wiring in azurestackprivate.go and provider.go.
Updates the image asset to retrieve the correct image URL for Azure Stack Hub.
This is preliminary work to create two paths, one for downloading and uploading the RHCOS image to an ASH environment, the other for using an existing image in the ASH environment. This creates the variables to determine whether the image should be from a local path.
Creates Terraform configurations to upload an RHCOS image when a local path is specified or use a storage blub URI when the URI is in the same ASH environment.
azure-vhd-utils, used by the azurestackprivate terraform provider, uses an ancient version (v5) of the azure-sdk-for-go from before semantic versioning. Therefore there is no clean way to import v5 without breaking all other azure-sdk-for-go imports. To get around this limitation, we bring the relevant code from azure-vhd-utils into the private terraform provider and update the imports to point to the openshift fork pinned at version 5.
99a262c to
5f1fb89
Compare
|
@patrickdillon: PR needs rebase. DetailsInstructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
| blobServiceBaseURL := strings.TrimPrefix(armClient.environment.ResourceManagerEndpoint, "https://management.") | ||
| storageClient, err := storage.NewClient(storageAccountName, storageAccountKey, blobServiceBaseURL, apiProfileVersion, true) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
perhaps there's a better way to do this
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you elaborate on this comment?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Was wondering if there was a programmatic way to pull that baseURL directly with string manipulation.
Should also make sure that the blobServiceBaseURL will always equal the base url of the ARM endpoint.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is it armClient.environment.StorageEndpointSuffix?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That seems correct.
|
Using the env var |
|
/cc @staebler Particularly need feedback around the kludge described in 50e5301 and 5f1fb89 Let me know if it is not clear and I can try to explain better. |
staebler
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Patrick and I had a discussion about exploring the possibility of embedding a azure-vhd-utils binary that could be run as part of a local-exec resource rather than having to bring into and own the azure-hvd-utils code in the installer repo.
| storageBaseURL := strings.TrimPrefix(armEndpoint, "https://management.") | ||
|
|
||
| // If the URL for the image is in the ASH environment we don't want to upload a local VHD. | ||
| if strings.Contains(imageURL, storageBaseURL) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we can get a little more precise with this by checking that storageBaseURL is the end of the host of imageURL.
|
@patrickdillon: The following tests failed, say
Full PR test history. Your PR dashboard. DetailsInstructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here. |
|
/close We will add a field in the install config for an image URL but we expect users to upload first. Hopefully the burden will be mitigated in the future by making the images available in the Azure marketplace. |
|
@patrickdillon: Closed this PR. DetailsIn response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
This PR creates a private terraform provider for uploading RHCOS images to Azure Stack Hub environments as part of the install process. Based on the azurestack terraform provider and the azure-vhd-utils project, the majority of the original work here is in the /pkg/terraform/exec/plugins/azurestackprivate/resource_vhd_blob.go, particularly the
resourceArmVHDBlobCreatefunction.The main piece of feedback needed is regarding updating azure-vhd-utils to import openshift/azure-sdk-for-go to get around the antiquated version dependency. This is described in detail in the commit messages.
Status: This PR stands on its own and can be reviewed/merged but the overall image upload process still needs to be completed