-
Notifications
You must be signed in to change notification settings - Fork 226
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Umbrella issue: Implement pipeline-aware function run workflows #1280
Comments
Imperative function run is now eval: https://kpt.dev/book/04-using-functions/02-imperative-function-execution Regarding metafunctions, modification of Kptfiles, and generation of pipelines: Per-function filters are discussed in #2364. krmignore is discussed in #1733 and #517. If Kptfile is not passed as part of the ResourceList by default, is it essentially like one of these other types of filters except that it's applied by default and disabled by --include-meta-resources? If --include-meta-resources is applied to kpt fn source, does it also need to be applied to kpt fn eval invocations that read from stdin? Is there a way to specify it in a declarative pipeline? Also, it's unclear whether ConfigMaps and pseudo-resources used for function inputs for particular functions via configPath can be passed in the ResourceList to other functions: Use cases that have come up include:
At least the first two cases also have needed top-down preprocessing (preorder execution) prior to bottom-up rendering (post-order execution) during declarative execution. |
cc @justinsb |
Thanks for the detailed comment @bgrant0607 . This is helpful as we are beginning the design for supporting filtering in Will try to answer part of the comment here:
this is fairly accurate in context of
I think both answers (yes, no) are possible in this case, but optimizing for the common CUJs should drive the answer. Quick thought suggests
I think the need for this has a big overlap with pre-processing step requirements I think. I need to think some more on the second part. |
Kind of related, I'd like kpt fn render to be able to take an entire package with a Kptfile with a pipeline from stdin. Why? Because I always want to re-run render after other mutations in order to enforce invariants. I want to treat the pipeline like mutating + validating admission control. |
Every time we clone a package to create a variant of the package, we need to specialize the variant somehow. The most basic thing that needs to be done in pretty much all cases is personalization: change the names of things: We do this for the Kptfile's metadata.name field automatically. I would like to use that as a standard input for a variant constructor pattern. This pattern would use the first mutator in the Kptfile to do the basic variant specialization required by the package. We may also want to think about how to use the name as input to other standard name-changing functions, such as set-namespace, ensure-name-substring, and so on. In general, for our use cases, I always want --include-meta-resources to be true, in source, eval, render, wherever. We need to be able to view and change the info in the Kptfile. It makes more sense to me to filter config objects in the SDKs or in function-specific filtering parameters. |
@phanimarupaka I described my use case above |
There is significant change in "kpt fn run" workflows with introduction of pipeline construct. Following tasks need to be accomplished:
The text was updated successfully, but these errors were encountered: