-
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
Flesh out the input data model and patterns #3396
Comments
Related: When gathering inputs, we may need to allow network access: #2450. And probably a way to provide credentials. |
It's also worth mentioning kustomize components: |
Do we need to solve this in the CLI case / with kpt functions? That is, could more complex cases like this be handled instead only in the Porch incarnation of CaD, where we can build controllers that interact with other systems in any way we want? If an interactive CLI based session requires network reach out, then it can more easily fail, for example. Also, there are interactions we will never be able to handle that way - for example, imagine that getting an input requires filing a ticket, which a human then responds to. In the controller case, we can handle this sort of arbitrary-time-delay without any trouble. But it won't work at all in the interactive |
@johnbelamaric I don't expect inputs to be generated during the kpt fn render pipeline, in general. It may consume the inputs. Input generation / gathering likely needs to be decoupled. Interactive forms or prompts is one such example. Your ticket example is a good one, thanks. If you think of others, post them here. |
A few quick thoughts, all slight variations on "fetch from external system":
|
Not all of these are necessarily only "function inputs". They could simply be ways of setting field values. For the example in the IPAM case, I can imagine a couple different approaches (this applies to others too, probably).
Reading that over, the second approach is probably more maintainable and flexible. |
CMDB is an example use case for dynamic inventory in ansible, such as via inventory plugins and inventory scripts. In addition to querying inputs dynamically, adapting input data locations / schemas to expected function input locations / schemas (or, in the case of IaC, to parameters of off-the-shelf packages) appears to be one of the other core / common issues. |
Example from slack: https://kubernetes.slack.com/archives/C0155NSPJSZ/p1658760504705309 How to provide information to packages automatically. |
The idea of "decorations" was discussed in the app config issue: kubectl expose and autoscale are examples of this. Resource creation might be imperative, but this does raise the issue of using information from resources themselves as function inputs. In the ghost package, we're experimenting with that approach as a way to propagate the host name: We could also use the approach to read resource requests and set application resource-dependent settings accordingly: In order to be understandable there probably needs to be an intuitive source of truth. A potential advantage of the approach is that the source of truth could be well known, as opposed to an input to an arbitrary function. However, if multiple locations disagreed and the source of truth were ambiguous, then the user would need to be asked to resolve the inconsistency, as when providing multiple values in an undiscriminated union. This approach could have implications for update strategies. |
A Tekton example from Slack: https://github.com/marniks7/chaos-catalog Slack message: https://kubernetes.slack.com/archives/C0155NSPJSZ/p1661457969525029?thread_ts=1661311193.053569&cid=C0155NSPJSZ |
Topic that needs more work.
We've figured out some aspects and requirements of package / function inputs:
But we don't have a fully fleshed out model or recommended patterns yet.
kpt isn't the first config tool to encounter these issues. We should look at data-oriented, non-package-parameter-based models for inspiration.
Some examples:
Additional thoughts or findings should be posted back here.
cc @justinsb @johnbelamaric @droot @yuwenma
The text was updated successfully, but these errors were encountered: