Support kubectl replace --force

[vigohe]

This PR will add a new feature to be able to execute a kubectl replace --force instead of a kubectl apply.

This feature it's important when you are applying large files. When you use kubectl apply with large files you will get a error like this metadata.annotations: Too long: must have at most 262144 bytes a workaround it's to use replace.

[jessequinn]

@vigohe why was the PR closed? It wasn't merged.

[vigohe]

@jessequinn I closed it because It crash when I re apply a second time when a value change, and I haven't got any time to fix it

[jessequinn]

@vigohe I tested your code:

    astarte-operator-crd-1 = {
      yaml_body        = file("assets/kubernetes/astarte-operator/api.astarte-platform.org_astartes_crd.yaml")
      force_new        = false
      force_replace    = true
      wait             = false
      wait_for_rollout = true
    }

and i received the following error (first time run):

Error: astartes.api.astarte-platform.org failed to run replace: unable to recognize "/tmp/110889547kubectl_manifest.yaml": Get https://xxx/api?timeout=32s: dial tcp xxx:443: i/o timeout

ok, I will try to find time to look at your code and see why this is happening. Probably requires a create on the first run and then replace on the second run.

[vigohe]

@jessequinn but that error it's a timeout did you configure the provider well ?

[jessequinn]

@vigohe

provider "kubectl" {
  apply_retry_count      = 15
  load_config_file       = false
  host                   = module.kubernetes.cluster_endpoint
  token                  = data.google_client_config.current.access_token
  client_certificate     = base64decode(module.kubernetes.cluster_client_certificate)
  client_key             = base64decode(module.kubernetes.cluster_client_key)
  cluster_ca_certificate = base64decode(module.kubernetes.cluster_cluster_ca_certificate)
}

I am unaware of any other option to help.

[jessequinn]

seems to work now. i haven't tested a modification on the CRD, but for us that wouldnt happen.

[vigohe]

seems to work now. i haven't tested a modification on the CRD, but for us that wouldnt happen.

Cool, I will try to fix it soon

[alon-dotan-starkware]

I also need this ability, any way I can help to push it forward?
Thanks,

[fernaspiazu]

News about this PR? I need this feature too 😄. Thanks in advance.
@vigohe

[vigohe]

@fernaspiazu did you try this? #118

[fernaspiazu]

I arrived here because I get the error: Too long: must have at most 262144 bytes from Solr operator's CRD, that I'm applying with this kubectl terraform provider.

Here the CRD: https://solr.apache.org/operator/downloads/crds/v0.5.0/all-with-dependencies.yaml I'm applying.

@vigohe Yes I did, but I have some problems with conflicts:

│ Error: solrclouds.solr.apache.org failed to run apply: Apply failed with 1 conflict: conflict with "Go-http-client" using apiextensions.k8s.io/v1: .spec.versions
│ Please review the fields above--they currently have other managers. Here
│ are the ways you can resolve this warning:
│ * If you intend to manage all of these fields, please re-run the apply
│   command with the `--force-conflicts` flag.
│ * If you do not intend to manage all of the fields, please edit your
│   manifest to remove references to the fields that should keep their
│   current managers.
│ * You may co-own fields by updating your manifest to match the existing
│   value; in this case, you'll become the manager if the other manager(s)
│   stop managing the field (remove it from their configuration).
│ See http://k8s.io/docs/reference/using-api/server-side-apply/#conflicts
│
│   with kubectl_manifest.solr-operator-crds[1],
│   on solr.tf line 5, in resource "kubectl_manifest" "solr-operator-crds":
│    5: resource "kubectl_manifest" "solr-operator-crds" {
│

server_side_apply = true works well, but in the case you upgrade a CRD, the conflict error above appears.

Do you have any suggestion to use a --force-conflict with server_side_apply option?

Thanks in advance.

[vigohe]

I arrived here because I get the error: Too long: must have at most 262144 bytes from Solr operator's CRD, that I'm applying with this kubectl terraform provider.

Here the CRD: https://solr.apache.org/operator/downloads/crds/v0.5.0/all-with-dependencies.yaml I'm applying.

@vigohe Yes I did, but I have some problems with conflicts:

│ Error: solrclouds.solr.apache.org failed to run apply: Apply failed with 1 conflict: conflict with "Go-http-client" using apiextensions.k8s.io/v1: .spec.versions
│ Please review the fields above--they currently have other managers. Here
│ are the ways you can resolve this warning:
│ * If you intend to manage all of these fields, please re-run the apply
│   command with the `--force-conflicts` flag.
│ * If you do not intend to manage all of the fields, please edit your
│   manifest to remove references to the fields that should keep their
│   current managers.
│ * You may co-own fields by updating your manifest to match the existing
│   value; in this case, you'll become the manager if the other manager(s)
│   stop managing the field (remove it from their configuration).
│ See http://k8s.io/docs/reference/using-api/server-side-apply/#conflicts
│
│   with kubectl_manifest.solr-operator-crds[1],
│   on solr.tf line 5, in resource "kubectl_manifest" "solr-operator-crds":
│    5: resource "kubectl_manifest" "solr-operator-crds" {
│

server_side_apply = true works well, but in the case you upgrade a CRD, the conflict error above appears.

Do you have any suggestion to use a --force-conflict with server_side_apply option?

Thanks in advance.

I haven't got time to finish this PR, last time I work on it, I did have an issue when you apply it on the second time if you change something