Skip to content
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

Make patch fail on "create" #5801

Open
2 tasks done
guettli opened this issue Nov 14, 2024 · 1 comment
Open
2 tasks done

Make patch fail on "create" #5801

guettli opened this issue Nov 14, 2024 · 1 comment
Labels
kind/feature Categorizes issue or PR as related to a new feature. needs-triage Indicates an issue or PR lacks a `triage/foo` label and requires one.

Comments

@guettli
Copy link
Contributor

guettli commented Nov 14, 2024

Eschewed features

  • This issue is not requesting templating, unstuctured edits, build-time side-effects from args or env vars, or any other eschewed feature.

What would you like to have added?

A kustomize patch can result into an "update" or a "create". It depends.

Example of a kustomize patch:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: foo
  namespace: foo-system
spec:
  template:
    spec:
      containers:
      - name: backend
        image: ghcr.io/foo/bar

there are two cases: there is already a container with name "backend", or there is no such container.

As an author of the kustomize patch, I want always to do an update.

Is there a way to get an error from kustomize if the patch would do a "create"?

Background: Names got changed, and then we had two containers in the deployment, because one place was not updated. I would like this to fail early the next time.

Why is this needed?

I don't want two containers in my deployment. I want to update an existing deployment.

Can you accomplish the motivating task without this feature, and if so, how?

I could use json-patch with "replace". But this is hard to read and write.

What other solutions have you considered?

.

Anything else we should know?

No response

Feature ownership

  • I am interested in contributing this feature myself! 🎉
@guettli guettli added the kind/feature Categorizes issue or PR as related to a new feature. label Nov 14, 2024
@k8s-ci-robot
Copy link
Contributor

This issue is currently awaiting triage.

SIG CLI takes a lead on issue triage for this repo, but any Kubernetes member can accept issues by applying the triage/accepted label.

The triage/accepted label can be added by org members by writing /triage accepted in a comment.

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-sigs/prow repository.

@k8s-ci-robot k8s-ci-robot added the needs-triage Indicates an issue or PR lacks a `triage/foo` label and requires one. label Nov 14, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/feature Categorizes issue or PR as related to a new feature. needs-triage Indicates an issue or PR lacks a `triage/foo` label and requires one.
Projects
None yet
Development

No branches or pull requests

2 participants