-
|
Flux v1 has an image update automation feature that is in widespread use. Flux v2 will need this to have parity with Flux v1 -- but of course we want it to work in the spirit of GitOps Toolkit. I have been prototyping a set of components that will do the image update automation as well as set the pattern for other kinds of automation. The design, in progress, is here: fluxcd/image-reflector-controller#5. The code is in https://github.com/squaremo/image-reflector-controller and https://github.com/squaremo/image-automation-controller. The main areas of uncertainty are:
Update: I have marked the kyaml setters design as the answer, since the implementation seems to work satisfactorily in practice. There are nonetheless lots of good ideas and points elsewhere in the discussion, and I'll be referring back here. Thanks everyone! |
Beta Was this translation helpful? Give feedback.
Replies: 13 comments 51 replies
-
|
There's now a run-through of the "working at all" implementation: https://github.com/squaremo/image-automation-controller#readme (The implementation is split into two controllers: image-reflector, which scans image repositories, and image-automation, which updates git by looking at the outcome of the scans) This is what the manifests look like: # image.yaml
# Declares an image repository to scan. This is where things like registry
# auth, and scan interval, would go, for example
apiVersion: image.fluxcd.io/v1alpha1
kind: ImageRepository
metadata:
name: app-image
spec:
image: squaremo/cuttlefacts-app# policy.yaml
# Defines a rule for "latest image" of some image repo. There could be
# different ways of filtering and ordering (similar to Flux v1, with glob and
# regexp, but potentially also things like "order by commit history")
apiVersion: image.fluxcd.io/v1alpha1
kind: ImagePolicy
metadata:
name: app-policy
spec:
imageRepository:
name: app-image
policy:
semver:
range: 1.x# repo.yaml
# This is a type from source-controller, but used here to give access to
# the git repository, for making updates.
apiVersion: source.fluxcd.io/v1alpha1
kind: GitRepository
metadata:
name: cuttlefacts-auto
spec:
url: ssh://git@github.com/squaremo/cuttlefacts-app-automated
interval: 1m
secretRef:
name: cuttlefacts-auto-deploy# update.yaml
# This defines an automated update to do; in this case, update files
# in the given repo to use the latest image as calculated by the given
# ImagePolicy. It also gives parameters for the commits that will be made;
# here you could tell it to push to a fresh branch, or even open a PR, say.
apiVersion: image.fluxcd.io/v1alpha1
kind: ImageUpdateAutomation
metadata:
name: update-app
spec:
gitRepository:
name: cuttlefacts-auto
update:
imagePolicy:
name: app-policy
commit:
authorName: Updatebot
authorEmail: bot@example.com
messageTemplate: |
Here look what I did
|
Beta Was this translation helpful? Give feedback.
-
|
Things that this sets out to solve:
|
Beta Was this translation helpful? Give feedback.
-
|
This has the resource mentioned in the README (though not exactly in the files given): https://github.com/squaremo/cuttlefacts-app-automated/tree/master/automation |
Beta Was this translation helpful? Give feedback.
-
|
Ah, inline -- yes good idea |
Beta Was this translation helpful? Give feedback.
-
|
Ok I'll try to post here a simple use-case based on your samples. |
Beta Was this translation helpful? Give feedback.
-
|
I've inlined the examples (or near enough) used in the README, above. |
Beta Was this translation helpful? Give feedback.
-
|
NB the implementation is sketchy and missing watches on various things -- you may occasionally need to delete and recreate objects to get it to do something. |
Beta Was this translation helpful? Give feedback.
-
Uses case: automated updates for a public container imageGit-to-cluster reconciliationHaving the following deployment in Git: apiVersion: apps/v1
kind: Deployment
metadata:
name: podinfo
namespace: default
spec:
selector:
matchLabels:
app: podinfo
template:
metadata:
labels:
app: podinfo
spec:
containers:
initContainers:
- name: init
image: stefanprodan/podinfo:4.0.0
command:
- sh
- -c
- "sleep 1"
- name: podinfod
image: docker.io/stefanprodan/podinfo:4.0.0
imagePullPolicy: IfNotPresent
ports:
- name: http
containerPort: 9898
protocol: TCP
command:
- ./podinfo
- --port=9898Having a GitRepository registered with a read-write deploy key: apiVersion: source.fluxcd.io/v1alpha1
kind: GitRepository
metadata:
name: podinfo
namespace: gitops-system
spec:
interval: 1m
url: ssh://git@github.com/stefanprodan/podinfo-deploy
secretRef:
name: ssh-podinfo
ref:
branch: masterHaving a Kustomization reconciling podinfo: apiVersion: kustomize.fluxcd.io/v1alpha1
kind: Kustomization
metadata:
name: podinfo
namespace: gitops-system
spec:
interval: 5m
sourceRef:
kind: GitRepository
name: podinfo
path: "./default/"
prune: true
healthChecks:
- kind: Deployment
name: podinfo
namespace: default
timeout: 2mImage update based on semver rangeRegister the podinfo container registry: apiVersion: image.fluxcd.io/v1alpha1
kind: ImageRepository
metadata:
name: podinfo
spec:
image: docker.io/stefanprodan/podinfoDefine the image updated policy using a semver range: apiVersion: image.fluxcd.io/v1alpha1
kind: ImagePolicy
metadata:
name: podinfo
spec:
imageRepository:
name: podinfo
policy:
semver:
range: ">=4.0.0 <5.0.0"Define the image update automation: apiVersion: image.fluxcd.io/v1alpha1
kind: ImageUpdateAutomation
metadata:
name: podinfo
spec:
gitRepository:
name: podinfo
update:
imagePolicy:
name: podinfo
commit:
authorName: fluxcdbot
authorEmail: fluxcdbot@@users.noreply.github.com
messageTemplate: |
Bump podinfo versionQuestions
|
Beta Was this translation helpful? Give feedback.
-
I've done the most basic spec that is useful -- replace every instance of a particular image. There's lots of ways to go from here:
.. and so on. I wouldn't expect to implement even all of those -- we need to figure out what is the simple, 80-90% solution.
That would go in the
It doesn't at present -- that's just me wanting to get something working and not colouring everything in properly. That's exactly the sort of thing that would go in the template though, yep. |
Beta Was this translation helpful? Give feedback.
-
Proposal: select targetsThe image update automation could target Kubernetes objects by label/namespace or target a kustomization.yaml file by path. Target Kubernetes objectsSelect a group of Kubernetes objects such as deployments, daemonsets, statefulsets, cronjobs, jobs or pods: kind: ImageUpdateAutomation
spec:
update:
imagePolicy:
name: app-policy
selector:
app: my-appSelect Kubernetes objects filtered by labels and namespaces: kind: ImageUpdateAutomation
spec:
update:
imagePolicy:
name: app-policy
selector:
app: my-app
namespaces:
- dev
- stagingThe above proposal addresses only Kubernetes native kinds and doesn't allow targeting a specific container/initContainer but all of them. I don't think there is valid use case for targeting containers. Target kustomizationsSelect a kind: ImageUpdateAutomation
spec:
gitRepository:
name: app-repo
kustomization:
path: "./deploy/overlays/dev" # <- kustomize edit set image app=app:semver |
Beta Was this translation helpful? Give feedback.
-
|
path: "./deploy/overlays/dev" -> I am guesssing this where kustomize edit set image will be run ?
|
Beta Was this translation helpful? Give feedback.
-
Yep, that's right. Naming the
Where do those environment variables come from?
It won't; they'd have to be patched, in place, or possibly (with a certain amount of extra fiddliness) as a JSON patch.
Maybe in the case of custom resources, yes. This is a property of the resource definition, I would think, but as a fallback it could go in annotations on each object. |
Beta Was this translation helpful? Give feedback.
-
I am expecting this to be same as how flux does currently, it gives some environment variables like in https://docs.fluxcd.io/en/1.17.1/references/fluxyaml-config-files.html#execution-context-of-commands. FLUX_WORKLOAD, FLUX_WL_NS |
Beta Was this translation helpful? Give feedback.
-
Agree as long as they can be dynamic using environment variables. Users having a specific folder pattern can patch those annotations itself using something like :
|
Beta Was this translation helpful? Give feedback.
-
I can see this being quite tricky to set up reliably, since so much is implicit. You would need a kustomization.yaml for each possible interpolated value of the path, then another kustomization.yaml to mention all of those others as bases so they'll be taken into account. In the case that you want to apply different image updates to different workloads via kustomizations, I think it'd be much simpler for the kustomization path to be static, and to use multiple automation objects to group the updates. |
Beta Was this translation helpful? Give feedback.
-
|
Chasing up a couple of things I mentioned ...
For example, naming several policies to dereference when doing an update. Pros: no need to have an automation object for each image policy; commits can group together changes. Cons: complication; using in combination with a single selector might not make much sense (in general, you'd want to pick out which policies apply to which workloads).
For example, a fixed value that is updated by hand.
Pros: simple, easy to use as a primitive for a higher layer. Cons: a proliferation of objects; you don't usually want to change the same image in lots of workloads, making selectors less useful. |
Beta Was this translation helpful? Give feedback.
-
|
Agree, the current setup looks slightly complicated and too many objects. Would be good to probably look at using regex patterns as well ? |
Beta Was this translation helpful? Give feedback.
-
|
Let's take the XKCD reference as read .. I would prefer to avoid regular expressions. Pros: terse. Cons: hard to write, especially if you are trying to include or exclude things that don't exist yet (e.g., files someone will add to your git repo in the future). |
Beta Was this translation helpful? Give feedback.
-
|
How about something like the below? apiVersion: image.fluxcd.io/v1alpha1
kind: ImageUpdateAutomation
metadata:
name: podinfo
spec:
gitRepository:
name: podinfo
policy:
semver:
range: ">=4.0.0 <5.0.0"
images:
registries:
- name: docker.io
include:
- docker.io/*
exclude:
- docker.io/library/*
commit:
authorName: fluxcdbot
authorEmail: fluxcdbot@@users.noreply.github.com
messageTemplate: |
Bump podinfo versionapiVersion: image.fluxcd.io/v1alpha1
kind: ImageRegistry
metadata:
name: docker.io
spec:
url: docker.io
secretRef: docker.io-auth
interval: 10m |
Beta Was this translation helpful? Give feedback.
-
|
This is an interesting, different factoring. Reading between the lines a little, this is how I think it would work:
I can see a pretty big downside here, if I've interpreted accurately: the semver range will apply to all the images found, which are likely to be on substantially different versions. It's difficult to see it working any way other than having a policy per image, however that's expressed in the custom resources. |
Beta Was this translation helpful? Give feedback.
-
|
I agree that a semver policy by range doesn't make much sense, but a semver policy by level is probably a better way of describing the intent: policy:
semver:
level: patch |
Beta Was this translation helpful? Give feedback.
-
|
I like the idea of giving level for semver updates, I hadn't thought of that. I guess this would be useful if you want to automate a lot of things at a time, but only ever bump the patch level. That seems like it might be a common requirement, though it's the only variation on it that makes much sense (you might want to bump the minor version if something is The general idea of giving selection rules in |
Beta Was this translation helpful? Give feedback.
-
|
To paraphrase some of the things that have been mentioned in the discussion above ... Limitations in the toytown implementationThe current implementation mentions a single image policy and a git repository, and updates every workload using the image in question, according to the policy. This is limited in several ways: You can't restrict it to updating only certain workloads, either by file path or by properties of the workload (e.g., its name, or labels) For some scenarios this is fine, since you'll only be automating the update of say, a few images you build in your own CI. But it might cause problems if there's different configs in the git repo, needing different policies -- say if you have different directories for staging vs production. You can only update one image at a time Some installations might have hundreds of images to be automated. That's 1. a lot of Taking these one at a time:
When applying a group of policies, it makes less sense to have narrow selection of workloads -- there is a tension between coarse-grained operations, and pin-pointing exactly what you want to change, because images often are close to 1-1 with workloads. Targeting kustomizationsKustomizations are explicitly supported by GOTK. To automate these, you have to target the kustomization.yaml file, rather than the YAMLs in the base. This would be an alternative to targeting specific files or workloads. In a design where you mark images for update (see above), ideally you would mark a field in the kustomization in the same way. Parameterising the location of the kustomization file @adusumillipraveen suggested that the path to the kustomization might be parameterised, similarly to how .flux.yaml commands receive various arguments in environment variables. This could end up being quite brittle, though; it's probably better to simply have automation objects for each of the variations you want (assuming the automation objects become a bit more expressive). Targeting custom resourcesIt's a reasonable expectation that
This requires either a blunt instrument (replace the image string wherever you see it; not useful if, say, the tag is in its own field), or a little language for pointing at fields that contain image references.
Kustomize knows how to update image fields of the usual Kubernetes types, but not how to patch the values in a HelmRelease file. A different factoring entirely, that focuses on which images to automate@moshloop suggested a different factoring of the definition of an automation; instead of naming This is quite close to how you might think of what you want as a user ("I want images in my own dockerhub org to be automated"). A potential downside is that it might become fiddly once you want to narrow down which workloads are affected, say. Another is that it may be hard to compose automation objects, since there's a lot of opportunity for specifications to overlap. |
Beta Was this translation helpful? Give feedback.
-
"[Different] configs in the git repo" is the strategy put forward in the Kubectl/Kustomize documentation https://kubectl.docs.kubernetes.io/pages/app_composition_and_deployment/structure_directories.html
Some of my thinking for this has been around labels, specifically, a LabelSelector I've looked at an "Application", which is really a namespace/LabelSelector combination, and all workloads (within a namespace) matching the LabelSelector are considered for image updates, this has some benefits in that you can be fairly targeted in your approach, with different policies for different LabelSelectors. Another option, would be to annotate objects that should be updated, simply you'd have One downside to this approach (annotating the resource), is the lack of places to store things like open-PRs to patch the changes that you've discovered in an early reconciliation (you need to store the set of images that the PR references, or, you'd have to parse the PR/diff), this is easier with a CR, which you can store the data in a Status field.
I've done a bit of this in my own work, being able to say Repo/Filename/key to be patched. For example, you might want to patch |
Beta Was this translation helpful? Give feedback.
-
Design: Automation via kyaml setters2In this design:
Target scenarios
Questions ...How does this translate into ImageRepository and ImagePolicy objects? There are some alternatives: A) Implicitly -- look at the current value for the setters, and perhaps some auxiliary information, and coalesce into objects. B) Higher-level description: the repositories and policies are defined in the same place as the setters (or define the setters), and they are created by the controller interpreting that (again, perhaps with auxiliary information, like credentials, from elsewhere) C) Explicitly -- there's a map from setter to image policy name, and the latter is assumed to exist. One question that might decide it is: if the markers are in the files, where do the setter definitions live? Is there any sense in having them as a resource, or should they just be in a file in the repo? There's no particular benefit to having another object over and above the automation object, so you might expect to put this information in the automation object. If the definitions live in a resource in the cluster, it is a little harder to make sure they are in sync with the markers in the files in git. If they live in a file or files in the repo, that's one extra file that needs to be maintained -- but maybe that's not too bad, since you need to set up the markers anyway. Providing credentials Making available the credentials for accessing a particular image registry or image repo is a runtime concern. This implies it should be an object in the cluster (even if it's synced from git). In the case C) above, image repository objects are created explicitly, and they will include (a reference to) the credentials. But in A) and B) above, the image repository objects may be created implicitly, and something will have to decide which credentials to use. ** Using tags vs whole image vs other bits .. ** Sometimes you might want to set only the tag, or set the tag and repo separately. This might need to be specified alongside the setter/policy, or perhaps synthetic names used e.g., Unanswered questions
Hypothetical user guide for C)You are here because you want to use Flux to automate updates in one or more git repositories. You might run the automation in the same cluster as you run your apps that are being automated; or you might run it in another cluster, or at least in a separate namespace. !!! note Unlike Flux v1, automation in Flux v2 does not require the workloads to be running in the same cluster.
To start the process, you'll have to give the automation access to your git repository. Create a GitRepository with the Flux command-line:
First we'll create a policy for updating a particular image; then we'll apply that policy in the deployment file for the app.
Now we have an image policy that yields a particular image with its tag, which we'll attach to a deployment.
The apiVersion: apps/v1
kind: Deployment
metadata:
name: helloworld
spec:
template:
spec:
containers:
- name: hello
- image: squaremo/helloworld:v1.0.0 # {"$ref": "app-image-policy"}
# ...Commit the change so it'll be seen by automation:
Lastly, create an automation object to tell the controller to run automation using this file: This will update any files under app/, so if you had other images to be updated, you could go through the above steps to create a policy and mark fields to be updated. You can monitor the automation object to see when the automation has run: |
Beta Was this translation helpful? Give feedback.
-
|
The format that supports the hypothetical user guide above needs to map setters (referred to in the markers put in files) with policies. There's different ways to do this. The marker could just use the policy name -- thus obviating the need for a mapping in a Fluxfile -- but any variation from that, needs a file to keep the names in sync. It's possible that some bookkeeping needs to go here as well, but I hope not, because that introduces the possibility of the substituted values (throughout the YAMLs) getting out of sync with the bookkeeping in the Fluxfile. apiVersion: update.fluxcd.io/v1alpha1 # not a k8s resource, just following the convention
kind: Fluxfile
automation:
images:
- policy: app-image-policy
setter: app-image-policy # the same because it wasn't supplied a name |
Beta Was this translation helpful? Give feedback.
-
|
I think we should use the convention that the marker has the same name as the policy and get rid of Fluxfile e.g.: |
Beta Was this translation helpful? Give feedback.
-
However, another purpose of the Fluxfile is to be the target for an automation object; i.e., it represents a chosen set of fields to be updated. So it may be useful to have it anyway, even if the information is otherwise redundant. Specifying a path is another way of restricting which updates are made, of course. |
Beta Was this translation helpful? Give feedback.
-
|
I've updated it to a simpler design in which the setter is assumed to have the name of the policy. |
Beta Was this translation helpful? Give feedback.
-
|
Can you please change the create commands and remove the The gotk CLI follows kubectl conventions: |
Beta Was this translation helpful? Give feedback.
-
|
Does this proposal include chart version update automation? I know the helm-controller has support for specifying a semver range already, but if you want more control/history/observability of your chart version updates than that, it would be useful to drive those through git commits (or even pull requests if you want to gate with human code review) instead. |
Beta Was this translation helpful? Give feedback.
-
|
Any Kubernetes YAML will be supported for image patching, here is a HelmRelease example: apiVersion: helm.toolkit.fluxcd.io/v2beta1
kind: HelmRelease
spec:
values:
image: repo/image:version # {"$ref": "gotk-system:app-image-policy"}And apiVersion: helm.toolkit.fluxcd.io/v2beta1
kind: HelmRelease
spec:
values:
image:
repository: repo/image
tag: version # {"$ref": "gotk-system:app-image-policy:tag"}As for chart versions, this is out of scope, the image-reflector-controller is specialised in container registries scanning. |
Beta Was this translation helpful? Give feedback.
-
|
If this turns out to work well for images, automating chart version automation could work in a very similar way. |
Beta Was this translation helpful? Give feedback.
-
|
any updates on this? I was wondering if it is now a feature. flux2 already supports helmrepositories so perhaps one could just replace imageRepositoryRef with helmRepositoryRef. |
Beta Was this translation helpful? Give feedback.
-
I think it would need to be a different kind, for a couple of reasons:
|
Beta Was this translation helpful? Give feedback.
-
|
(but no, no material progress on Helm chart automation, sorry!) |
Beta Was this translation helpful? Give feedback.
-
|
Any thoughts about supporting code review gating of the git updates? So rather than direct git commits, it would create pull requests / patchsets (gerrit terminology). If there is an open pull request when an update comes in it would update the existing pull request rather than creating a new one, so that outdated pull requests aren't left around. Note that this is similar to Dependabot. There have been requests there for container image, HelmRelease and Helm chart dependency versions. However those are not implemented yet, and Dependabot is specific to Github and doesn't support Gerrit for example. So it would be great to have that functionality in gotk. |
Beta Was this translation helpful? Give feedback.
-
|
I've left room in the automation spec for this; it's not in the set of things needed for Flux v1 parity, but it would certainly be a great improvement after that is met. |
Beta Was this translation helpful? Give feedback.
-
|
I was wondering if there was any thought around supporting other templating solutions here (i.e. not just helm or kustomize). In flux v1. the solution seems fairly generic (via This was useful because it basically overwrites whatever is in your rendered manifests (that seemed to meet our use-case). It seems like my question is similar to those around HelmRelease CRDs or Charts (although in my case, it's just Jsonnet). |
Beta Was this translation helpful? Give feedback.
-
|
fluxcd/kustomize-controller#253 proposes lexical interpolation. I'm advocating for structural editing via something like JSON Patch (which uses JSON Pointer). That is, rather than assuming that the input is lexical YAML, operate at the information model level: There are objects with fields, and arrays, and values of a few types, and we can point into such objects and arrays to indicate which values should be changed. The YAML comment that tells this controller to replace the container image name says, "Replace this value right here." I'm advocating for also being able to say, "Replace that value over there," for cases like JSON where you can't insert those directives into an object that conforms to an unforgiving schema. |
Beta Was this translation helpful? Give feedback.
-
|
Yep, I would prefer operating on data structures rather than pictures of data structures, all things being equal. The proposal in fluxcd/kustomize-controller#253 is a reasonable punt nonetheless, I think, because envsubst is dead simple, widely understood, and easy to troubleshoot when you inevitably drop quotes or confounding whitespace in the middle of some syntax. My point above was that I'm reluctant to introduce more ways of doing similar things -- with the envsubst proposal there is now
.. all of which interpolate values into manifests, but have different modes of use. Reasoning about how these are going to interact is challenging. That's why I'd prefer to go in the direction of envsubst, despite its pitfalls. However, possibly good news: Kustomize supports JSON Patch, and Flux v2 supports Kustomize -- so if JSON Patch is what you want, you already have the means. (Though to work with the automation as it is, you'd still need to use the marker comment in the patch ..) |
Beta Was this translation helpful? Give feedback.
-
|
And as of today, you can't use JSON Patch written in YAML with kustomize (per kptdev/kpt#1342 (comment)). |
Beta Was this translation helpful? Give feedback.
-
|
Inline patches won't work because they are encoded as strings. I tried this example which uses a patch in a separate file https://github.com/kubernetes-sigs/kustomize/blob/master/examples/jsonpatch.md, converting the patch file to YAML, and it seems to work. Am I missing a crucial detail? |
Beta Was this translation helpful? Give feedback.
-
|
Did you try to use a setter or substitution inside the patch file? |
Beta Was this translation helpful? Give feedback.
-
|
Is the ImagePolicy semver only? Or can I configure it to get the latest tag. So that the latest sha256 id of the image gets replaced by the setter? This would be my dev-environment use-case to always deploy the latest version of my app. |
Beta Was this translation helpful? Give feedback.
-
|
I mean "latest" in the sense of the most recently built image. I need Flux to force a redeployment every time a new image was created. |
Beta Was this translation helpful? Give feedback.
-
|
If I understand the "git revision policy" correct you require the image to be tagged with the git commit hash? |
Beta Was this translation helpful? Give feedback.
-
|
This is what Flux v1 attempts (unless told to use semver), but it has some flaws:
However, we'll probably have to implement the latter at some stage, since labels will be needed for the git ordering anyway. I've posted fluxcd/image-reflector-controller#43 for implementing build timestamp ordering.
No, although that's the most efficient way to do it. You can also label the image with the revision. |
Beta Was this translation helpful? Give feedback.
-
|
Is the current image-reflector-controller already runnable or do I have to wait for the integration into the flux2 project. |
Beta Was this translation helpful? Give feedback.
-
|
You can run it -- instructions for the whole shebang are given in the README for https://github.com/fluxcd/image-automation-controller. EDIT: made sure there are instructions right there. |
Beta Was this translation helpful? Give feedback.
-
|
Hello! Is there are roadmap for other policies in addition to semver? I'm thinking in the way flux v1 has regexp and glob with either full regexp or some simple patterns. Also, does semver work with prefix like vX.X.X? Or with suffixes like -mybuild ? |
Beta Was this translation helpful? Give feedback.
-
|
The development is moving fast, and roadmap does not currently reflect all the minute details about current implementation progress. (Roadmap is here: https://toolkit.fluxcd.io/roadmap/) Even the docs are not 100% current at this moment, as an example which I do not believe has yet surfaced in docs, regex filters are implemented in fluxcd/image-reflector-controller#75 and available in image-reflector-controller 0.3.0 and above, from 5 days ago. I just reviewed for the latest information, semver_test.go and I see tests indicating the "v" prefix is actually considered valid semver by the parser (not strict semver v2), on the other hand I do not see support for any suffixes. For the latest news in advance of the docs re-converging with the latest development, you can directly follow development efforts in image-reflector-controller. As of yesterday I learned from flux devs, the latest image automation supports includes, besides semver:
The semver support as it is implemented is apparently not strictly semver v2, eg. |
Beta Was this translation helpful? Give feedback.
Design: Automation via kyaml setters2
In this design:
https://github.com/kubernetes-sigs/kustomize/tree/master/kyaml/setters2 (but this is mostly transparent for the user)
Target scenarios
Questions ...
How does this translate into ImageRepository and ImagePolicy objects?
There are some alternatives:
A) Implicitly -- look at the current value for the setters, and perhaps some auxil…