Canonicalize the fetch stage as the only stage during which Ignition fetches configs #950
Comments
|
Related: coreos/fedora-coreos-tracker#436 |
|
Also related: #903 |
…n units Since we are tearing down the networking using an ExecStop we need to make sure we run the ExecStop *after* any other ignition*.service unit's ExecStop. The only other one right now is ignition-mount that has an ExecStop for doing an unmount. Since the ordering for ExecStop is the opposite of ExecStart we need to use `Before=ignition-mount.service`. Partial fix for coreos/fedora-coreos-tracker#440 This would most likely not be necessary if Ignition cached an empty result: coreos/ignition#950
|
though another question to ask is should ignition try to fetch configs in multiple stages at all? It seems like there should only be one stage that ever tries to fetch and condense an ignition config for the system. All other stages use that initial stage's output (let's say it's a written local file) as their input. |
|
i.e. instead of solving this problem of "Ignition shouldn't try to refetch empty configs" we restate it to "Ignition should only ever try to fetch configs in one stage". |
|
@dustymabe I think that's fair. The current stage structure evolved over time, and now that we have a distinct fetch stage, we don't need to think of |
|
Yup, agreed with the above. Keeping it to the |
…n units We want to run the teardown after all other Ignition stages have run because some platforms (like Packet) do remote status reporting for each Ignition stage. Since we are tearing down the networking using an ExecStop we need to make sure we run the ExecStop *after* any other ignition*.service unit's ExecStop. The only other one right now is ignition-mount that has an ExecStop for doing an unmount. Since the ordering for ExecStop is the of ExecStart we # need to use `Before=ignition-mount.service`. Partial fix for coreos/fedora-coreos-tracker#440 This would most likely not be necessary if Ignition cached an empty result: coreos/ignition#950
…n units We want to run the teardown after all other Ignition stages have run because some platforms (like Packet) do remote status reporting for each Ignition stage. Since we are tearing down the networking using an ExecStop we need to make sure we run the ExecStop *after* any other ignition*.service unit's ExecStop. The only other one right now is ignition-mount that has an ExecStop for doing an unmount. Since the ordering for ExecStop is the opposite of ExecStart we # need to use `Before=ignition-mount.service`. Partial fix for coreos/fedora-coreos-tracker#440 This would most likely not be necessary if Ignition cached an empty result: coreos/ignition#950
…n units We want to run the teardown after all other Ignition stages have run because some platforms (like Packet) do remote status reporting for each Ignition stage. Since we are tearing down the networking using an ExecStop we need to make sure we run the ExecStop *after* any other ignition*.service unit's ExecStop. The only other one right now is ignition-mount that has an ExecStop for doing an unmount. Since the ordering for ExecStop is the opposite of ExecStart we need to use `Before=ignition-mount.service`. Partial fix for coreos/fedora-coreos-tracker#440 This would most likely not be necessary if Ignition cached an empty result: coreos/ignition#950
jlebon
changed the title
Yeah, I think you're right in that it simplifies the "only emit a message once" bit. Though I expect this issue will mostly be about moving code around, so I told @sohankunkerkar to keep working with what he has and we can rebase changes needed for this issue on top of his work. |
|
This ticket got closed, so are we now guaranteeing that "Ignition fetches the configuration only once in the fetch stage"? |
|
Yes, 88013e5 changed the acquire logic to ensure that. |
|
Sorry about that @lucab, in hindsight I should have updated the commit message for that commit to make it more obvious that it was now doing more than just always writing the cache config. |
|
this issue is referenced here: https://github.com/coreos/ignition/pull/958/files#diff-e3491b7c0e160811ce6761d5a1117558R95 |
Follow-up in #1075. |
Noticed this while examining the logs for a different reason. It looks like Ignition doesn't cache the fact that an Ignition config wasn't provided when it gets HTTP 200 with an empty body. So it ends up trying to refetch the config on each stage.
We should cache it instead (e.g. as just
{}in/run/ignition.json?) and avoid spamming the metadata server.The text was updated successfully, but these errors were encountered: