You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In anticipation of #3: in places where the original name of a resource is modified, the name should be updated wherever it's used.
For example, a generated ConfigMap has a static name give in the config, which is used wherever it's referred to in other resources e.g., as a volume in some file deployment.yaml. But the name of the ConfigMap when it's printed out will (by default) have a hash appended to it, and that name has to then be the one used in deployment.yaml when it is printed out.
The text was updated successfully, but these errors were encountered:
Sketch: an invocation of overlay should return a map of the names to the transformed names; at the top level of composition, all resources then get traversed and any fields which have a LocalObjectRef are replaced. It may make bookkeeping easier to make the return value Map name resource (rather than returning the map and the resources separately).
This raises some questions about how renaming is supposed to work, though:
the most basic question is do renames get piled up when you compose overlays? (e.g., you might add -dev to all the names in one overlay, then prepend clusterA- in another -- do you end up with clusterA-foobar-dev? I think so).
if you have not assigned a namespace to a resource, how is it addressed by other transformations? Will a patch that mentions a namespace be applied, either before or after an overlay gives the resource a namespace? Can the namespace be changed by an intervening overlay?
These can all surely be elucidated with some experiments.
In anticipation of #3: in places where the original name of a resource is modified, the name should be updated wherever it's used.
For example, a generated ConfigMap has a static name give in the config, which is used wherever it's referred to in other resources e.g., as a volume in some file deployment.yaml. But the name of the ConfigMap when it's printed out will (by default) have a hash appended to it, and that name has to then be the one used in deployment.yaml when it is printed out.
The text was updated successfully, but these errors were encountered: