Skip to content
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

docs: Add a "Creating derived configs" section #265

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

@cgwalters cgwalters force-pushed the doc-derivation branch 2 times, most recently from 2afa1c1 to 197d23d Compare July 27, 2021 17:35
@cgwalters
Copy link
Member Author

cgwalters commented Jul 27, 2021

Oh well that's just super cool how the docs are CI tested rustdoc style. Nice work! (edit: I mean, nice work whoever wrote the testing code)

Copy link
Contributor

@bgilbert bgilbert left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we should either move this to OCP docs, or substantially cut down the explanation. Outside of OCP this isn't an operation users should generally need to perform, because it assumes that (1) users are injecting machine-specific configuration fragments (which we should strongly discourage in favor of DHCP and DNS) and (2) the original worker.ign isn't under their control (which is only true if it's generated by an outside tool like openshift-install).

If we want to keep this here, we could drop most of the explanatory text and just give a couple examples:

  1. merging an external config over HTTP (preferred), and
  2. merging it from a local directory (if necessary).

docs/examples.md Outdated Show resolved Hide resolved
docs/examples.md Outdated Show resolved Hide resolved
test Outdated Show resolved Hide resolved
docs/examples.md Outdated Show resolved Hide resolved
@cgwalters
Copy link
Member Author

Outside of OCP this isn't an operation users should generally need to perform, because it assumes that (1) users are injecting machine-specific configuration fragments (which we should strongly discourage in favor of DHCP and DNS)

Sure, but we clearly need to support static IP addressing etc. too right? And if we support it it should be documented.

and (2) the original worker.ign isn't under their control (which is only true if it's generated by an outside tool like openshift-install).

It's an interesting topic. I could imagine this happening outside of OpenShift 4 too. Like a "base operating system" group maintaining their tweaked base config, and then for some special machines they derive from that config in a similar way.

Dunno. If you feel strongly I can move this just to the OCP docs for now.

@cgwalters
Copy link
Member Author

Comments addressed!

@cgwalters
Copy link
Member Author

Any further thoughts on this?

@bgilbert
Copy link
Contributor

bgilbert commented Aug 3, 2021

and (2) the original worker.ign isn't under their control (which is only true if it's generated by an outside tool like openshift-install).

It's an interesting topic. I could imagine this happening outside of OpenShift 4 too. Like a "base operating system" group maintaining their tweaked base config, and then for some special machines they derive from that config in a similar way.

Thinking about it some more, I think the doc as written (with ignition.config.merge.local) should go in OCP docs.

In general, we should encourage users to maintain a library of configs that can be merged by the root config, with any machine-specific configuration (e.g. static IP) placed directly in the root config. So the root might look like:

variant: fcos
version: 1.1.0
ignition:
  config:
    merge:
      - source: https://example.com/IT-department-baseline.ign
      - source: https://example.com/standard-compute-node.ign
      - source: https://example.com/node-with-two-hard-drives.ign
      - source: https://example.com/development-cluster-node.ign
storage:
  files:
    - path: /etc/hostname
      contents:
        inline: foo.example.com

The OCP case is a bit weird because openshift-install thinks it's generating the root config, but that belief turns out to be wrong. We don't want to disrupt the "just feed the root config to the machine" workflow and we don't want to tell the user to host the worker.ign on a web server, as they normally should with a library config. Thus we end up with a workflow where users generate a "super-root" config embedding the original "root". It makes sense within OCP constraints, but it's an awkward workflow outside of that context. For one thing, the resulting Ignition config obscures part of its contents inside a gzip+base64 blob.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants