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

[umbrella issue] bash in kubernetes #78702

Open
cblecker opened this issue Jun 4, 2019 · 10 comments

Comments

6 participants
@cblecker
Copy link
Member

commented Jun 4, 2019

So Apple is deprecating bash as their default shell in their upcoming macOS 10.16, and moving to zsh. We have had many problems supporting multiple bash versions, and I think might be the right cue to move away from bashisms and onto either python or go code.

We had a lengthy discussion in Slack about this, and the rough draft plan is:

  • Establish firm ownership of hack/ and build/ (it's fuzzy testing/release world right now)
  • Write a style guide
  • Make python code sustainable
  • Find what doesn't conform
  • Migrate bash stuff to go/python

In summary, the goals would be:

  • POSIX sh is okay for short, simple, or bootstrapping scripts
  • Anything that's more complicated (function calls, arrays, etc) should be either python or go
  • We need dependency management for python

cc: @Katharine @BenTheElder @michelle192837 @thockin @dims @tpepper @stevekuznetsov

@cblecker

This comment has been minimized.

Copy link
Member Author

commented Jun 4, 2019

@BenTheElder

This comment has been minimized.

Copy link
Member

commented Jun 4, 2019

[adding a note that we've also recently had a bunch of issues with bash version compatibility issues on linux, on really commonly installed versions]

For a lot of this tooling, if we do this, we should really consider wholly new tooling. E.G. we have a lot of complexity in the build attempting to "cache" that predates go 1.10, or the rsync stuff which is a bit less necessary now.

@thockin

This comment has been minimized.

Copy link
Member

commented Jun 4, 2019

The rsync stuff is because MacOS performance is terrible for docker volumes. I would love to drop it, but last I looked we just couldn't.

I don't disagree that bash may be at the end of it's runway, but I question python as an alternative.

@BenTheElder

This comment has been minimized.

Copy link
Member

commented Jun 4, 2019

The rsync stuff is because MacOS performance is terrible for docker volumes. I would love to drop it, but last I looked we just couldn't.

The performance got better over time, and with a few tweaks we can drastically reduce the I/O required anyhow. If we can actually leverage go's cache with modules enabled we can also cache the modules within a docker volume instead of bind mounting vendor and aggressively cache most of the build.

This runs regularly on a mac building a go binary w/ caching and achieves roughly native performance on mac, incremental compiles are very quick.

I don't disagree that bash may be at the end of it's runway, but I question python as an alternative.

FWIW the Google shell style guide does suggest using python when you shouldn't use bash... And we hit every point on when it suggests to switch 🙃

Go is another possibility in the OP.

@jberkus

This comment has been minimized.

Copy link

commented Jun 4, 2019

Just a note that Python is not installed on Windows by default. So this would make installing python a requirement for Kubernetes Windows users.

/cc @kubernetes/sig-windows-misc

@cblecker

This comment has been minimized.

Copy link
Member Author

commented Jun 4, 2019

Contributors, not users. This is focused on the development and build systems. We already have some python in the repo, so a make verify will fail in any environment that lacks python.

@PatrickLang PatrickLang added this to Backlog in SIG-Windows Jun 4, 2019

@stevekuznetsov

This comment has been minimized.

Copy link
Contributor

commented Jun 4, 2019

POSIX is a fairly onerous and difficult standard to adhere to. Why?

@BenTheElder

This comment has been minimized.

Copy link
Member

commented Jun 4, 2019

Also note that none of our builds work on default installs. They require some mixture of docker, bash, make, go, bazel, etc. I don't think Docker is installed by default on most operating systems...

I also don't think there's been any real effort to build from Windows, but we build to Windows from Linux in CI. This shouldn't affect users.

@BenTheElder

This comment has been minimized.

Copy link
Member

commented Jun 4, 2019

POSIX is a fairly onerous and difficult standard to adhere to. Why?

It's not particularly onerous for small scripts. Anything not small probably shouldn't be in shell.

@stevekuznetsov

This comment has been minimized.

Copy link
Contributor

commented Jun 4, 2019

It's not particularly onerous for small scripts. Anything not small probably shouldn't be in shell.

Right but, as an example, why disallow [[ and all the niceties of it and force everyone to use the POSIX-compliant [ or test? The latter have gotchas that make using them tricky.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.