Introduce rfc-0009-supply-chain-switches-template-on-flag

[waciumawanjohi]

Readable

[squeedee]

We're landing ytt support. Wondering if it invalidates this approach as we can switch in template on different sources, or does that make it "more than break glass" ?

[DanieldeR]

Bumping the milestone on this to 1.0+ as this is achievable with YTT.

[netlify]

✔️ Deploy Preview for elated-stonebraker-105904 canceled.

🔨 Explore the source changes: 547f596

🔍 Inspect the deploy log: https://app.netlify.com/sites/elated-stonebraker-105904/deploys/61f2ce4ea26dd000074302d0

[martyspiewak]

Not necessary to resolve this question to approve this RFC but just a thought:
This model seems to push users towards larger blueprints with far more templates referenced in them, where only a subset of those templates will be relevant for a given owner. Perhaps we will need to re-think our informers for templates, then.

The way our informers work currently, if a template referenced in a blueprint changes, any owner that matched the blueprint will be re-reconciled. After this RFC is implemented, it is plausible that there will be a significant number of templates in a blueprint that are irrelevant to a given owner, and it doesn't seem worth re-reconciling all of those owners when those templates change.

Again, definitely not necessary to address this as part of this RFC, but just wanted to document the thought for posterity if the RFC is approved.

[waciumawanjohi]

After this RFC is implemented, it is plausible that there will be a significant number of templates in a blueprint that are irrelevant to a given owner, and it doesn't seem worth re-reconciling all of those owners when those templates change.

Sounds like another good quality of deterministic supply chains. As long as we can calculate which templates in a supply chain will be chosen for a workload, we can avoid unnecessary reconciles. (Though that does beg the question, how expensive will that calculation be, will we need to cache the calculation somehow?)

[squeedee]

In/NotIn is probably insufficent for a numeric json type
Boolean types could be better matched with boolean operators too. Propose:

• Exists DoesNotExist are generic (as they do not expect a values)
• In NotIn are suitable for strings, with a values field
• LessThan, GreaterThan, Equal, NotEqual, LessThanOrEqual, GreaterThanOrEqual (and/or) <, >, ==, !=, <=, >= for numeric types on a field called value
• Is (and perhaps IsNot against a value field that can only be true or false for booleans.

[squeedee]

Also I don't think this has to be resolved/implemented immediately. We could support a jsonType in the spec, but throw a not implemented error for anything non-string, and work through a healthy design for matchers to implement later.

[emmjohnson]

@sclevine do you approve? Wanting to get as many maintainers approvals since we have no formal process (yet).

[cirocosta]

I might be missing something, so please correct me if I'm wrong, but it feels like this approach could actually be a separate rule for options. e.g., one could make use of both proposals with something like

  resources:
    - name: source-provider
      templateRef:
        kind: ClusterSourceTemplate
        options: 
        - name: git-template
          selector:
            matchFields:
              - key: workload.spec.source.git       # would match if the workload has this field filled in
                operator: Exists
        - name: imgpkg-bundle-template
          selector:
            matchLabels:   # or the label set below
              app.tanzu.vmware.com/source-type: imgpkg-bundle

although mixing like in the example I provided does seem like an odd approach to designing a supplychain imo

[rawlingsj]

LGTM - I'm not on the maintainers list but wanted to express my +1. I like the approach and praise for finding a solution that keeps the current developer UX consistent, i.e. avoiding adding extra labels to the workload to help select the platform specific resources.

[scothis]

I didn't see anything describing how this path is defined, is it JSON Path?

[scothis]

Is the options field mutually exclusive with name, or is name removed and the the options list must be used even when there is a single choice?

[waciumawanjohi]

Mutually exclusive. This will not present a breaking change.

[scothis]

I fully expect use of ytt to manage conditional output to still be in very wide spread use. What this RFC is enabling is the ability to avoid a root level if/else where there is otherwise little commonality. In some cases a template may be able to shift away from using ytt, but I don't expect that to be common.

ytt remains the only meaningful way to:

• conditionally add/remove a field
• iterate over values
• coerce types
• apply logic
• do anything dynamic other than plain substitution

[waciumawanjohi]

ytt is useful. But there would be advantages to eliminating its use. For example.

ytt remains the only meaningful way to:

Enumerating these uses is valuable! We can begin to observe which are the most common and prioritize developing Cartographer native alternatives!

[squeedee]

@waciumawanjohi do you mind merging this?