John Belamaric

I'm trying to avoid package-specific APIs. The idea of injection is to allow the package to advertise how it can be configured. Another term @justinsb used for a similar concept...

Extending the idea above, we can also allow it to inject resources from other packages, encompassing the "binding" concept. So, it would look something like: ``` injection: # example of...

Oh, I misunderstood your PackageVariantContext thing - you were suggesting the naming instead of `injection`? "Context" might be a good word, yes, let's think about names that may give that...

Also, in Nephio we found a need to inject multiple resources of the same type. For example, we use a sentinel CR to represent a demand for a certain set...

> "Context" might be a good word, yes, let's think about names that may give that flavor. Another point on this, "context" here makes sense in some cases, but I...

Another way to think about this, after a discussion with @liamfallon is to use an analogy to programming. You can think of each binding point name as a variable name....

Another thought based on @tliron's tko demo: should we allow (at least) the "direct" binding to be a *patch* as opposed to a complete resource? This allows more flexibility around...

> It would also be nice to have this capability for offline use (meaning just with kpt). We have scenarios where we have a common package we want to be...

I don't think the fix for #4023 will be in there, that upstream fix is not in any released version yet. My still be worth doing this though.

Was this done intentionally? What would happen if we fix it? I have an auto-approve controller, but it won't touch the package revision until it has "aged" appropriately (that in...