Add higher-level defaults for tag filters

[bboreham]

Suppose you build all your images with a tag pattern like branch-commithash, then you might want to set a cluster-wide default filter of master-*.

Possibly you might want a per-namespace default.

[aaron7]

#1046 adds support for namespace tags however a good point @leth brought up is how this applies to third party containers. For example, consul with a v release version tag instead of a master-* tag.

One option would be to continue with namespace tag approach and override all containers which don't follow. Does this sound resonable?

Does anyone have ideas of other options we could explore?

cc @weaveworks/wolfrocketcyborgninja

[foot]

We could add batch tag filter changes onto the deploy-status table.

• Wouldn't cover clusters w/ lots of workload churn as you'd have to keep coming back and setting them for new workloads.

[samb1729]

A tree of filters sounds like a reasonable idea. Two things to consider:

• Suppose we want a cluster-wide default filter. Where do we put it?
• Should filters override what's above them, or should they compose? Probably the former for this one, but worth mentioning.

[bboreham]

how this applies to third party containers

I note we lock all of our third-party containers, individually, so maybe this indicates the need for a separate higher-level setting?

Some 3rd-party images use semver, which we should probably support directly.

[leth]

Does anyone have ideas of other options we could explore?

We could combine a tag filter with a repo filter: e.g. repo quay.io/weaveworks/* + tag master-*
So that the tag filter would only apply where the repo filter matched.

[rade]

Related: #1054

[squaremo]

I note we lock all of our third-party containers, individually, so maybe this indicates the need for a separate higher-level setting?

This use of locking is an approximation to pinning the individual containers to specific images (which could be done by setting the filter to an exact image tag). I don't think this indicates a requirement for a more broad setting, so much as a more obvious way to automate some images/containers and not others.

Some 3rd-party images use semver, which we should probably support directly.

Yeah, supporting semver would be nice: #706.

[squaremo]

Does anyone have ideas of other options we could explore?

Options (not alternatives):

• specify automation policy as a separate piece of config, rather than using annotations
• attach automation policy to images, rather than containers
• attach automation policy to some other (possibly cluster-scoped) resource, then refer to it

[bboreham]

Note that the incident triggering this issue was in the context of a manual "update all" operation, i.e. not the Flux automation feature per se. I expected tag filters to apply to that.

FWIW I am thinking of the "update all" operation as similar to full automation, but with a little bit of human mediation.

[rade]

Note that the incident triggering this issue was in the context of a manual "update all" operation. ... I expected tag filters to apply to that.

Hence #1054

[kingdonb]

This would be a new feature, so unlikely to be considered for merge, as:

• Flux v1 is in maintenance mode #3320