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

add "dependency" provisioning mode #1105

Merged
merged 1 commit into from
May 22, 2023

Conversation

pendo324
Copy link
Contributor

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

@jandubois
Copy link
Member

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.

I may need to think about this some more, but my gut feeling would be that the dependencies scripts should always be run in addition to, and not instead of the default installation.

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 (pkg/hostagent/requirements.go), doesn't it?

@pendo324
Copy link
Contributor Author

pendo324 commented Oct 14, 2022

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 (pkg/hostagent/requirements.go), doesn't it?

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:

  • dependency mode provisioning scripts to run in addition to the default 30-install-packages.sh
    • these scripts actually don't have to be limited to the "dependency" scope, naming them something like "early" or "pre-installation" mode would also make sense
  • new option like skipDefaultDependencyInstallation to skip the default dependency installation
  • new option like skipDefaultRequirements to skip the default requirements in pkg/hostagent/requirements.go

skipDefaultDependencyInstallation could also be overloaded to skip default requirements too, if we think that two new options would be too much/unnecessary

@AkihiroSuda
Copy link
Member

Please squash commits

@AkihiroSuda AkihiroSuda added this to the v0.14 (tentative) milestone Nov 2, 2022
apk add ${pkgs}
fi
else
echo "LIMA_CIDATA_USE_DEFAULT_DEPENDENCY_RESOLUTION set, skipping regular dependency installation"
Copy link
Member

Choose a reason for hiding this comment

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

Did you mean

Suggested change
echo "LIMA_CIDATA_USE_DEFAULT_DEPENDENCY_RESOLUTION set, skipping regular dependency installation"
echo "LIMA_CIDATA_USE_DEFAULT_DEPENDENCY_RESOLUTION != 1, skipping regular dependency installation"

Copy link
Contributor Author

@pendo324 pendo324 Nov 8, 2022

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

y.UseDefaultDependencyResolution = o.UseDefaultDependencyResolution
}
if y.UseDefaultDependencyResolution == nil {
y.UseDefaultDependencyResolution = pointer.Bool(true)
Copy link
Member

@AkihiroSuda AkihiroSuda Nov 7, 2022

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

@pendo324 pendo324 force-pushed the dependency-provisioning-mode branch 2 times, most recently from 6c15c5f to 575e0f1 Compare November 8, 2022 19:29
AkihiroSuda
AkihiroSuda previously approved these changes Nov 9, 2022
Copy link
Member

@AkihiroSuda AkihiroSuda left a comment

Choose a reason for hiding this comment

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

Thanks

@AkihiroSuda
Copy link
Member

@jandubois LGTY?

@AkihiroSuda
Copy link
Member

Sorry, needs another rebase

AkihiroSuda
AkihiroSuda previously approved these changes May 4, 2023
Copy link
Member

@AkihiroSuda AkihiroSuda left a comment

Choose a reason for hiding this comment

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

Thanks

@AkihiroSuda
Copy link
Member

@lima-vm/maintainers Let me know if we can merge this.
Do we want to treat this as an experimental feature?

Copy link
Member

@jandubois jandubois left a 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.

# 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
Copy link
Member

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.

Copy link
Contributor Author

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"
Copy link
Member

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.

Copy link
Contributor Author

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

Comment on lines 42 to 44
if [ "${LIMA_CIDATA_SKIP_DEFAULT_DEPENDENCY_RESOLUTION}" = 1 ]; then
echo "LIMA_CIDATA_SKIP_DEFAULT_DEPENDENCY_RESOLUTION is set, skipping regular dependency installation"
else
Copy link
Member

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.

Copy link
Contributor Author

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>
Copy link
Member

@AkihiroSuda AkihiroSuda left a comment

Choose a reason for hiding this comment

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

Thanks

@AkihiroSuda
Copy link
Member

@jandubois LGTY?

Copy link
Member

@jandubois jandubois left a 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
Copy link
Member

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):

Suggested change
if [ $CODE != 0 ]; then
if [ $CODE -ne 0 ]; then
echo "Exiting with code $CODE"

@AkihiroSuda AkihiroSuda merged commit 28cf48d into lima-vm:master May 22, 2023
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.

3 participants