Even if they have no side effect, they aren't legal, since it would be
surprising if suddenly something new got added in one which then broke
the imports.
Fix a small panic that could happen if we had a bad clone, and make
visibility into this operation better. We also make room for future
context cancellation since the library now supports this.
If we've set the --module-path arg, then we expect to rebase that path
out of the deploy, and instead it should show up as /modules/ which is
the standard. Handle this scenario.
In 80e8c9cadc when this was ported, the
"Any" value diverged accidentally. This would cause some packages to not
be found, since they didn't match any arch.
Thanks to karpfen to digging into the issue.
This adds a new util package with some useful functionality which could
be implemented as pure mcl, but instead we add it here as a good place
to help with code reuse.
I regressed here when patching this. Here's the fix. Would be beautiful
to have hardware to run end-to-end testing on. If you want to sponsor
this, please let me know!
With the release of Fedora 41, I was getting lots of mirror errors.
Hopefully this helps make it more robust. It was failing repeatedly
while trying to download packages, and I kept having to restart things,
but once I added this option things worked. Hopefully they're related.
Here's a good first way to implement handoff. What's particularly
elegant about handoff here, is that this is the first form of it I know,
where handoff happens between a provisioning tool and a configuration
management tool and those are the same tool! As a result, this can allow
for some really elegant integration, and the end-user never has to deal
with the combinatorial explosion of the N * M scenario of gluing each
provisioning tool to each different configuration management tool.
We'll have other forms of handoff in the future, but this simple
approach is useful already.
This makes the current deploy available. This is likely not useful when
this is used from the embedded provisioner cli tool, since it would
contain cli functions that won't run, but it is useful when it's used as
a library.
This adds two new top-level commands: setup and firstboot.
Firstboot is pure-golang implementation of a service that runs some
commands once when a system first boots. You need to install this
service, and put the scripts to run in a special directory. This is
inspired by the virt-builder --firstboot mechanism.
Setup is a general purpose command that makes it easy to setup certain
facilities on a new machine. These include the mgmt package dependencies
it might need, a service to run it from, and the necessary service to
use the mgmt firstboot service as well.
All of this has been built to facilitate handoff between provisioning a
new machine and running configuration management on it.
