[Bug]: import requires access to github
sonalita opened this issue · 4 comments
Describe the bug
We are migrating from the old kubectl "gavinbunny" implementation to the newer flux bootstrap method, using terraform 1.6,6 and flux provider 1.3.0
I am using this guide
Our resource block looks like this (mild redactions):
resource "flux_bootstrap_git" "this" {
embedded_manifests = true
image_pull_secret = var.pull_secret_name
path = var.target_path
registry = var.registry
registry_credentials = "${var.username}:${var.api_key}"
}
However the terraform import fails for us as it tries to access github.com which we do not have whitelisted on our proxy. The import t is not respecting the embdedded_manifests flag
Error: Getting expected repository files
could not generate install manifests: failed to download manifests.tar.gz
from
https://github.com/fluxcd/flux2/releases/download/v2.3.0/manifests.tar.gz,
error: Get
https://github.com/fluxcd/flux2/releases/download/v2.3.0/manifests.tar.gz":
Forbidden
Adding the github.com domain to our proxy is not possible.
Is there anyway to work around this? Is it a bug that can be fixed?
I have a horrible alternative of hand editing the state file but I really do not want to do that.
Steps to reproduce
- Have an older Flux installation (or remove the flux_bootstrap_git from existing statefile)
- Ensure github.com is not reachable
- Define the flux_bootstrap resource to use embedded_manifests
- Run terraform import
Expected behavior
The resource should be imported into the statefile
Screenshots and recordings
See logs in description
Terraform and provider versions
Terraform 1.6.6 on linux_amd64
Flux provider 1.3.0
Terraform provider configurations
provider "flux" {
kubernetes = {
cluster_ca_certificate = base64decode(data.aws_eks_cluster.cluster.certificate_authority.0.data)
exec = {
api_version = local.cluster_config["aws_cli_client_authentication_api_version"]
args = local.aws_eks_get_token_command
command = "aws"
}
host = data.aws_eks_cluster.cluster.endpoint
}
git = {
author_name = var.azuredevops_secret_username_flux_config
branch = local.cluster_config["azuredevops_git_repo_branch_flux_config"]
http = {
username = var.azuredevops_secret_username_flux_config
password = var.azuredevops_personal_access_token
}
url = "${local.cluster_config["azuredevops_org_service_url"]}/${local.cluster_config["azuredevops_project_name"]}/_git/${local.cluster_config["azuredevops_git_repository_name_flux_config"]}"
}
}
flux_bootstrap_git resource
resource "flux_bootstrap_git" "this" {
embedded_manifests = true
image_pull_secret = var.pull_secret_name
path = var.target_path
registry = var.registry
registry_credentials = "${var.username}:${var.api_key}"
}
Flux version
flux: v2.3.0
Additional context
A clean install works fine - the issue is with the import not respecting the embedded_manifests property in the resource definition.
Code of Conduct
- I agree to follow this project's Code of Conduct
Would you like to implement a fix?
None
@stefanprodan Yes, this is the problem!!!
I already do use embedded_manifests in the resource definition and that works perfectly if Flux is not installed or was installed previously by the Flux provider's "flux_bootstrap" resource. BUT if Flux was installed by other means (i.e. an older version of the provider where the bootstrap resource was not available) then the migration guide says to use "terraform import" to import the existing configuration into the state file. THIS is the step that is broken. If I use "terraform import", embedded_manifests is not respected even though it is specified in the resource definition.
This is the crux of the bug report - terraform import of a flux_bootstrap resource needs to respect embedded_manifests which it currently does not do.
The import function can't use the embedded manifests, because those manifests are for the latest version, while the cluster is on an older version.
Hi @stefanprodan , are you saying there’s no migration path if we use embedded manifests? I.e. The import function used either as an import block or CLI tf import won’t work?
if so, any recommendations how to best achieve the migration please?