Good find, Alan – that implements most of the spec, in ~200 LoC. There are some gaps/considerations around it, which I documented at the end of the spec.
Here’s what the inputs/outputs of (most of) the spec’s example looks like in a Replacement Transformer world:
https://github.com/mattmceuen/replacement-transformer-example
Have a good weekend, all.
Matt
From: MEADOWS, ALAN <am240k@att.com>
Sent: Thursday, February 20, 2020 5:59 PM
To: MCEUEN, MATT <MM9745@att.com>; airship-discuss@lists.airshipit.org
Subject: Re: [Airship-discuss] [SIG-YAML] Draft substitution spec
I have made a few comments in the document.
Most notably, have we examined the Kustomize ReplacementTransformer plugin? One of the examples in the pull request:
https://github.com/kubernetes-sigs/kustomize/pull/1631
Namely, substitute the whole containers.
replacements:
- from:
objref:
kind: Deployment
name: deploy
fieldref: spec.template.spec.containers
to:
target:
kind: Deployment
name: deploy2
fieldrefs:
- spec.template.spec.containers
Seems to align quite well to our need to support pulling in trees.
There appears to be some diamond import handling as well:
Alan Meadows
From: MATT MCEUEN <MM9745@att.com>
Date: Thursday, February 20, 2020 at 2:34 PM
To: "airship-discuss@lists.airshipit.org" <airship-discuss@lists.airshipit.org>
Subject: [Airship-discuss] [SIG-YAML] Draft substitution spec
***Security Advisory: This Message Originated Outside of AT&T ***
Reference http://cso.att.com/EmailSecurity/IDSP.html for more information.
Airship SIG-YAML team,
As discussed in Monday’s call: although Kustomize supports great layering capabilities that fit Airship’s need for overriding YAML values at for different use cases, operators, and sites, it does not offer a clean approach to achieve variable
resolution / substitution that we need to avoid copying and pasting of values that should be shared across multiple resources (e.g. images, endpoints, certificates). We decided to continue using Kustomize for layering, and to explore alternatives for substitution.
I’ve put up a draft spec we can use as a strawman, to see whether it fits the bill and whether any alternatives would be preferable. We’ll discuss this coming Monday, but feedback in the doc would be welcome if you get time before then!
https://docs.google.com/document/d/1Z_DzbKZLjT-etddOVwQDEH7Yi9QyLIQw572Nx4ugmZk/edit#
Thanks,
Matt