Remove local-only resources at the last minute

[KnVerey]

This allows name references to local-only objects to be correctly resolved before the objects are removed from the set to be printed. The use case that made me think of this is the common Ingress situation from #4884, where there are several related values that are list items. If we can formally identify those values as names, then we can update them intelligently, even across multiple objects.

The side-effect is that local resources from a base will be exposed to overlays. Can you think of any reason that's undesirable? I was surprised it wasn't already the case, personally.

[natasha41575]

The side-effect is that local resources from a base will be exposed to overlays. Can you think of any reason that's undesirable? I was surprised it wasn't already the case, personally.

I don't see any reason why the local base resources shouldn't be exposed to overlays. I think this makes sense.

/lgtm
/approve

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: KnVerey, natasha41575

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [KnVerey,natasha41575]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[wyattanderson]

The side-effect is that local resources from a base will be exposed to overlays. Can you think of any reason that's undesirable? I was surprised it wasn't already the case, personally.

@KnVerey one side effect that we've now encountered is that a local-only configMapGenerator in a component used in multiple resources now has a name collision when those resources are combined into one kustomization. We're attempting to use replacements to change the registry domain of an image on a per-environment basis, and the only reason we use a configMapGenerator at all is because replacements can't reference constant values defined inline. Our approach works in 4.5.5, but breaks in 5.0.0 and above, I believe because of this change.

[mleklund]

I have the same issue with this a @wyattanderson. I am using replacements with a local-config confgiMapGenerator to differentiate blue/green deployments.

[annasong20]

We want to gather more information before making a decision on this change.

We're attempting to use replacements to change the registry domain of an image on a per-environment basis, and the only reason we use a configMapGenerator at all is because replacements can't reference constant values defined inline.

@wyattanderson please feel free to open your own issue on this regression. Are there any workarounds for your use case? For example, you can

• specify constant values with patches; though, it doesn't have the parsing abilities of replacements
• move the reference to your Component into the overlay