-
Notifications
You must be signed in to change notification settings - Fork 908
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
Remove dependency on bash #5120
Conversation
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.
first bleary eyed look, found only a typo
ca18d74
to
0654f15
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.
This generally LGTM. I think there's some further cleanup we could do here around the old implementation, but it's not necessary for this PR.
Only comment I think needs to be addressed here is the extra unused variable and IFS in the new implementation.
@@ -356,29 +448,18 @@ def varprinter(vlist): | |||
+ varprinter(allvars) | |||
+ "{\n%s\n\n:\n} > /dev/null\n" % content | |||
+ "unset IFS\n" | |||
+ varprinter(keylist) | |||
+ varprinter(allvars) |
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.
Does this version even work? If I look at the printf
on line 428, it's missing a newline so we'll get a bunch of variables crammed onto a single line. Is there a reason we can't replace the whole varprinter mess with set -o posix; set
?
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.
Does this version even work?
I think so. I had to tear it apart to rebuild it in posix shell, and I recall that this did what I think it was supposed to. I think that the line containing: for line in output.split("\x00"):
is crucial to null-delimited parsing stuff.
Is there a reason we can't replace the whole varprinter mess with set -o posix; set?
I was trying to avoid disturbing sleeping dragons with excessive changes, but I just checked[1] and bash's set
output multi-line strings rather than ansi-c strings, so it probably would work. We'd just need to unset that -o posix
if it wasn't already set. Bash stores shell options in SHELLOPTS
, so I think we have all of the bits required to make this a single codepath.
I previously thought that ansi-c multi-line strings was technically posix-compliant[2] and possible output from set
as "appropriate quoting". Posix shells like dash and ash certainly understand them. However, digging further it seems that maybe it's actually an extension that was backported into these shells for support, which is probably why -o posix
disables this output format.
[1] bash with posix -o
$ bash -c "TEST=$'multi-\nline'; set" | grep TEST
...
TEST=$'multi-\nline'
$ bash -c "TEST=$'multi-\nline'; set -o posix; set" | grep -A 1 TEST
...
TEST='multi-
line'
[2] the spec
If no options or arguments are specified, set shall write the names and values of all shell variables in the collation sequence of the current locale. Each name shall start on a separate line, using the format:
"%s=%s\n", ,
The value string shall be written with appropriate quoting; see the description of shell quoting in Quoting. The output shall be suitable for reinput to the shell, setting or resetting, as far as possible, the variables that are currently set; read-only variables cannot be reset.
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 can't replace the whole varprinter mess with set -o posix; set?
It looks like that works. See the latest commit which consolidates the bash and posix shell codepaths into a single one using set -o posix
62bf14f
to
53ef8a5
Compare
@TheRealFalcon I think I've addressed all of your comments (and I tested on alpine), ready for re-review. |
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.
LGTM! Great cleanup here.
Thanks @TheRealFalcon! I'll wait to merge in case @dermotbradley has feedback. |
It seems fine to me and the modified testcases still pass on Alpine. |
53ef8a5
to
e866104
Compare
A hard dependency on bash is undesirable for many reasons. Use 'set' for getting environment variables, rather than bash features. This also works with bash in posix mode. Note: The choice to make the datasource configuration implementation a bash script was highly unusual. Unfortunately the format is in OpenNebula's control, not cloud-init's. Still, adding posix shell support to cloud-init's implementation is an incremental improvement. [1] by outputting ansi-c strings - $'' - rather than multi-line strings
e866104
to
41fc899
Compare
Thanks @dermotbradley! I just squashed the extra commits and updated commit messages, will merge shortly. |
Context
This change removes cloud-init's dependency on
bash
in both runtime code and in unittests.There are two runtime changes in this PR:
It standardizes the failure path and tests for systems that don't include GNU date. This fallback path to GNU date isn't used in 99.99% of cases. It is only exercised when a user has set a custom datetime format in their logs which Python code doesn't understand. GNU date offers a parsing capability which is used only in these cases.
The main change in this PR is adding support for posix shell in the OpenNebula datasource. It is of course possible for the OpenNebula cloud (or the end user) to pass non-posix shell data to cloud-init, but with this change at least cloud-init codepaths exist for posix shell.
cc @dermotbradley @igalic
Test Steps
also see the ci report in this pr which adds alpine to ci
Merge type