We discussed wanting to be able to specify which context certain parts of the applier run with. Similar to our namespacing, I suggest we have a global default and then have the ability to specify additional contexts throughout the inventory. In cases where a global default isn't specified, we should just fallback to whatever is active
I noticed that in the current iteration of the design proposal we have path. I'm assuming that we don't want to throw out the possibility of just processing some arbitrary yaml that either lives locally or somewhere out on the web. Since I'd assume that these would still take two separate paths.. we probably still want to provide the ability to specify template vs file.
What does this PR do?
Adding some thoughts on the design proposal
We discussed wanting to be able to specify which context certain parts of the applier run with. Similar to our namespacing, I suggest we have a global default and then have the ability to specify additional contexts throughout the inventory. In cases where a global default isn't specified, we should just fallback to whatever is active
I noticed that in the current iteration of the design proposal we have
path. I'm assuming that we don't want to throw out the possibility of just processing some arbitrary yaml that either lives locally or somewhere out on the web. Since I'd assume that these would still take two separate paths.. we probably still want to provide the ability to specify template vs file.How should this be tested?
N/A
Is there a relevant Issue open for this?
N/A
Who would you like to review this?
cc: @redhat-cop/openshift-applier