-
Notifications
You must be signed in to change notification settings - Fork 604
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
add "dependency" provisioning mode #1105
add "dependency" provisioning mode #1105
Conversation
I may need to think about this some more, but my gut feeling would be that the I don't know if there is a need to potentially disable the default package installation, but that would then also require a mechanism to disable the corresponding requirements checks ( |
I think that the essential requirements should still be the same, but I do see the benefit in having another flag in limayaml to disable default requirement checks. The most customizable approach would probably be something like:
|
Please squash commits |
775657e
to
3eb8a5d
Compare
apk add ${pkgs} | ||
fi | ||
else | ||
echo "LIMA_CIDATA_USE_DEFAULT_DEPENDENCY_RESOLUTION set, skipping regular dependency installation" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Did you mean
echo "LIMA_CIDATA_USE_DEFAULT_DEPENDENCY_RESOLUTION set, skipping regular dependency installation" | |
echo "LIMA_CIDATA_USE_DEFAULT_DEPENDENCY_RESOLUTION != 1, skipping regular dependency installation" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, good catch. I think changing it to "skip" also makes more sense, like your other comment suggested.
The default value of "false" is easier to reason about, since most users won't interact with this option. Just pushed an update to rebase, address both comments, and also update the default example yaml
pkg/limayaml/defaults.go
Outdated
y.UseDefaultDependencyResolution = o.UseDefaultDependencyResolution | ||
} | ||
if y.UseDefaultDependencyResolution == nil { | ||
y.UseDefaultDependencyResolution = pointer.Bool(true) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Wondering this should be rather inverted to SkipDefaultDependencyPackages
with the default value false
6c15c5f
to
575e0f1
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks
@jandubois LGTY? |
Sorry, needs another rebase |
575e0f1
to
e128e1e
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks
@lima-vm/maintainers Let me know if we can merge this. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm generally fine with this PR, but have some stylistic feedback.
I think marking it as experimental gives us some wiggle-room to still change how we configure it in the future.
examples/default.yaml
Outdated
# the regular dependency resolution workflow in pkg/cidata/cidata.TEMPLATE.d/boot/30-install-packages.sh | ||
# and provide a fully customizable replacement | ||
# 🟢 Builtin default: false | ||
# skipDefaultDependencyResolution: true |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is quite a mouthful, and also feels somewhat disconnected here. I'm wondering if this would make more sense to make this an option on the dependency
provisioning script.
I don't have strong opinions, it just feels a bit clunky to have this weirdly-named option at the top level, that only makes sense when you also have some other bits of configuration defined.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good point, addressed in latest revision. I added a new field to the Provisioning scripts in general, but invalidate it when used on non-dependency scripts.
for f in "${LIMA_CIDATA_MNT}"/provision.dependency/*; do | ||
echo "Executing $f" | ||
if ! "$f"; then | ||
echo "Failed to execute $f" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there a reason we don't want to exit 1
here? The rest of the script runs under set -e
, so any error return would immediately exit the script.
On the other hand, in boot.sh
, we set CODE=1
when a provisioning script fails, and then exit $CODE
at the end.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Makes sense. Changed it to collect all errors in a CODE var and exit if its 1 after all dependency scripts, to match boot.sh behavior
if [ "${LIMA_CIDATA_SKIP_DEFAULT_DEPENDENCY_RESOLUTION}" = 1 ]; then | ||
echo "LIMA_CIDATA_SKIP_DEFAULT_DEPENDENCY_RESOLUTION is set, skipping regular dependency installation" | ||
else |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The conditionals are already nested too deeply in this file for my taste, so adding a 140 line else
clause does not feel appealing.
I would rather do an early exit here, and then move the 2 actions at the bottom of the script (setting up DNS, and updating fuse_conf) into a separate script.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wasn't a big fan of the nesting either. Split the file into two and exit early now
Signed-off-by: Justin Alvarez <alvajus@amazon.com>
e128e1e
to
8e7efed
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks
@jandubois LGTY? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks, LGTM.
I think having the comment on the error exit would be nice, but I'm also fine with merging as-is.
CODE=1 | ||
fi | ||
done | ||
if [ $CODE != 0 ]; then |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think adding a log message that we are exiting early would be nice to have (as we do in boot.sh
):
if [ $CODE != 0 ]; then | |
if [ $CODE -ne 0 ]; then | |
echo "Exiting with code $CODE" |
Adds a new provisioning script mode that allows users to customize the workflow of
pkg/cidata/cidata.TEMPLATE.d/boot/30-install-packages.sh
.This can be useful in the case where a user wants to override the default behavior to (for example) add repositories before attempting to install system dependencies.
Another option is to add a flag to limayaml to allow running dependency provisioning scripts in addition to the default logic (instead of bypassing the default logic), please comment if that's more preferable.
More details in #1093