-
Notifications
You must be signed in to change notification settings - Fork 243
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
Exporting Ignition's renderConfig
functionality
#599
Comments
renderConfig
functionalityrenderConfig
functionality
This probably should be part of the For this use case, since there are no remote resources, having that functionality isn't a concern, but the logic still needs to be there for Ignition's use. Refactoring that out would be hairy. There is currently the exported |
Sorry @ajeddeloh , if I wasn't clear in my description. The user might define an ignition config for a set of machines, which indirects to remote source for its contents. We don't want our internal cluster ignition endpoint to serve this user's config as-is because we cannot ensure uniformity among the set if the contents of the remote url change. Therefore, we want to render the config once (fetching any remote configs if specified) in similar fashion to the This would mean both the |
Also couldn't find a |
Exporting both If we do end up needing to go down this path of exposing this functionality I think that the long talked about potential Ignition Stage 0, which fetches & creates the final config, would be the better entrypoint. Would a binary that you can run an Ignition config through that returns a finalized (fully rendered) config solve your problem? |
Oh, whoops. |
Whoops, I misunderstood the original bug. I thought you meant "I have a bunch of configs locally and want to render them into another local config". "Stage 0" is what you want. We should make it public (i.e. exported and not internal) when we implement it. It's been on the backburner of our minds for a while (with the possibility of moving it to another language that makes the translation process easier (i.e. Rust)). Rewriting stage 0 is a big task since it handles
Refactoring it out into it's own stage without rewriting is still a decent chunk of work but is doable in the short term. How urgently is this needed? It'd be nice to not have to implement stage 0 twice if possible. Are you wanting to consume a golang library? Would something with a C interface also work? Would a binary that just writes out a file work? The absolute fastest way to hack this up would be to fork Ignition and make the disks/files stages no-ops, then just use the Ignition binary to write it out to disk. |
We don't need this for 4.0, but I figured it would be a lot of work, so I wanted to get the ball rolling now.
Golang would be ideal, but we can always write a wrapper around a shared object or exec another process. |
Dropping this from the spec 3.0.0 milestone after some discussion with other teams. It's not spec related anyway |
Feature Request
Exporting Ignition's
renderConfig
functionality so that external agents can resolve Ignition configs same way as Ignition engines does on nodes.Desired Feature
Ignition uses renderConfig on machines to resolve remote sources for replace and append directives.
renderConfig
function is unexportedFetcher
struct used by renderConfig can be vendored as it is part ofinternal
package.Exporting the
renderConfig
function would allow external agents to render an Ignition config that is complaint with Ignition's behaviour.Specific Use Case
To manage the configuration for machines in Openshift clusters, there is plan to deploy an Ignition endpoint inside the cluster, that will serve Ignition config to machines. The config served to machines should be static and should have no remote sources.
Rendering the remote sources in the ignition config (that might have been provided by user) ensures that machines joining the cluster at a time in future continue to receive the same configuration even if the contents of the remote location have changed.
/cc: @crawford @yifan-gu
The text was updated successfully, but these errors were encountered: