-
Notifications
You must be signed in to change notification settings - Fork 169
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 bottlecap, an optional entry point #182
Conversation
Can you elaborate slightly on the usage of this? One would run it as root like |
bottlecap
Outdated
|
||
if [ "$dev" == 1 ]; then | ||
volumes+="-v $script_dir:/host/src " | ||
volumes+="-v $(go env GOCACHE):/root/.cache/go-build " |
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.
On a SELinux enabled system this assumes these are labeled too. Which may be OK, but will almost certainly bite people. (I try not to run containers accessing my /home
for example)
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.
hmm. the gocache is easy enough (just put it literally anywhere that will persist across container runs).
If we want to support local dev though we need to be able to bind in wherever the build scripts are coming from (which is right now, this repo)
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 TL;DR is that SELinux + docker/podman (as root anyways) want files to be labeled specially for containers. Trying to do -v /home/myuser:/home
for example will fail, and you don't want to relabel your /home
.
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.
(To pivot this topic though, while I haven't played with it the "rootless" podman should sidestep this issue; if we merge the bits to have this container not require privileges, just /dev/kvm
, that will work well for rootless too)
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.
another note here: we need to check if go env GOCACHE
reports a value before we try to mount it in:
$ ./bottlecap --build-dir /srv/ --dev --container ca build
./bottlecap: line 81: go: command not found
+ sudo podman run --rm --net=host -ti --privileged --userns=host -v /var/srv:/srv -v /var/sharedfolder/code/github.com/coreos/coreos-assembler:/host/src -v :/root/.cache/go-build --workdir /srv --entrypoint /host/src/bottlecap-shim ca d
invalid host path, must be an absolute path ""
Yeah, that's the idea. Basically allow an easy way to both work on the container itself and give an opinionated way to use it. Manually setting bash aliases is not ideal. The goal is also to keep Edit: shouldn't need root I don't think? |
956db3b
to
00af17e
Compare
@@ -0,0 +1,76 @@ | |||
#!/bin/sh | |||
|
|||
# bottlecap, 'cause it's kinda like cork... get it? |
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.
cork
is nice since it's 4 letters :) - I like cass
because it's also 4 letters, but I also like highlighting that this is the script vs an alias that someone has defined on the command line (since I like to define my alias as alias cass=
. So cass.sh
would be my suggestion here, but also takes us back to 7 characters so I'm a hypocrite :)
This was mostly just a thought excercise for me. We don't need to change anything unless you want to.
Not sure what to do about the selinux issue @cgwalters brought up (ideas?) but I switched to getopt parsing. |
one thing you could do for the selinux issue is detect and error (or warn). If system has selinux enabled and the label on the files aren't going to work then error/warn. For example tell them they could |
bottlecap
Outdated
echo " --container: which coreos-assembler container to use" | ||
echo " --help: print this help message" | ||
echo "Command to be executed:" | ||
runtime="echo $runtime" |
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 feel like the above two lines should be deleted.
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 could go either way. It's certainly been useful for debugging bottlecap
and I think it does a good job of illustrating that bottlecap
is just a thin wrapper. What about a ---dry-run
option instead?
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.
right now it doesn't actually output the command to be executed I don't think. It outputs Command to be executed:
and then sets the runtime
variable equal to "echo $runtime"
, which doesn't print anything to the screen.
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.
it sets runtime
to echo $runtime
because some of the args are not set when usage is called. Note it does not exit immediately after usage
.
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 see. Thanks for explaining. I did not understand what you were doing. We discussed that you could also achieve this with --dry-run
bottlecap
Outdated
|
||
usage() { | ||
echo "usage:" | ||
echo "bottlecap [--dev] [--runtime $runtime] [--build-dir $build_dir] [--container $container] assemblerargs..." |
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 to evaluate the above variables when we print stuff to the screen? If not then we should use single quotes and not double quotes here.
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 do. You can do bottlecap --build-dir foobar --help
and see your arg reflected in the help text, which I am a fan of personally.
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 see, I haven't seen that very much in practice, but seems OK
bottlecap
Outdated
build_dir="$(pwd)" | ||
container="quay.io/cgwalters/coreos-assembler" | ||
|
||
TEMP=$(getopt -o 'dr:b:c:h' --long 'dev,runtime:,build-dir:,container:,help' -- $@) |
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.
you need to check the exit code of getopt
and call usage() and exit if it failed.
bottlecap
Outdated
entrypoint="--entrypoint /host/src/bottlecap-shim" | ||
fi | ||
|
||
$runtime run --rm --net=host -ti --privileged --userns=host $volumes --workdir /srv $entrypoint $container $@ |
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.
maybe we should set -x
right above this command
also, do we expect users to run sudo ./bottlecap
?
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.
also, do we expect users to run sudo ./bottlecap
If needed. I'd rather leave that to the user to decide than than bake it into the 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.
maybe we should set -x right above this command
SGTM
a few style comments:
|
Will do on running it through shellcheck. And yeah, I do like tabs, let everyone decide their own indentation level (I typically like 8, which is far more than most people I think). |
0212211
to
4c30422
Compare
Fixed a lot of things, switch the gocache to just always use Passes shellcheck, with one exception where we actually do want glob expansion |
bottlecap
Outdated
rc=0 | ||
TEMP=$(getopt -o 'dr:b:c:h' --long 'dev,dry-run,runtime:,build-dir:,container:,help' -- "$@") || rc=$? | ||
if [ "$rc" -ne 0 ]; then | ||
echo "Bad arguments. getopt failed." |
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.
should the above go to stderr ?
bottlecap
Outdated
break | ||
;; | ||
*) | ||
echo "Error parsing args" |
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.
not sure if this section is needed any longer since we are using getopt
, but if we keep this let's spit that message to stderr
a few final comments in the code on stderr.. otherwise LGTM. will probably want to update this in a future PR to handle the 'unpriv' case, but we don't need to do that now |
Add bottlecap as the default entry point. It will handle launching the coreos-assembler container and optionally binding in and rebuilding certain aspects to aid development. This is in additon to the existing flows.
Made errors go to stdout, fixed shellcheck complaints in |
Add bottlecap as the default entry point. It will handle launching the
coreos-assembler container and optionally binding in and rebuilding
certain aspects to aid development. This is in additon to the existing
flows.
Putting this up as WIP to get some feedback, will add docs before final version