Conversation
There's no need to generate it dynamically, so let's just split it out to be more explicit and easier to hack on.
From the comment block of the unit:
This target is reached when Ignition finishes running. Note that it
gets activated *only* on first boot (or if ignition.firstboot=1 is
provided). Thus, it is also an API for units to use so that they
are activated only on first boot. Simply add a link under
ignition-complete.target.requires in the initrd.
Thus, units themselves don't need to add explicit `Requires=`; the
canonical way to get pulled into the transaction is through
`ignition-complete.target`.
This will also be used by the upcoming CoreOS units that are required
for separate `/var` support.
jlebon
force-pushed
the
pr/ignition-target
branch
from
53bc163 to
f545dad
Compare
|
OK, renamed to |
ajeddeloh
left a comment
ajeddeloh
left a comment
There was a problem hiding this comment.
LGTM, though I haven't tested it.
|
LGTM |
|
Second commit LGTM. Re the first commit, how do you plan to differentiate ignition-setup behavior on live PXE systems? |
Can we use unit overrides for this? My main goal here was keeping things clean and easy to follow by making |
|
Could do. It might be cleaner to get an |
|
It's possible, depending on how we implement things, that we won't need a separate behaving ignition-setup.service in the future. Maybe we just cross that bridge when we add live PXE support? |
|
Are we good to merge this then? |
|
👍 Fine by me |
4 participants
From the comment block of the unit:
Thus, units themselves don't need to add explicit
Requires=; thecanonical way to get pulled into the transaction is through
ignition-complete.target.This will also be used by the upcoming CoreOS units that are required
for separate
/varsupport.