Allow arguments to the atomic 'install', 'uninstall', 'start' and any additional container commans.

[markllama]

Arguments to the 'atomic (install|uninstall|start...) commands would be appended to the shell invocation which corresponds to the command.

IE: if installing a container which requires authentication to a remote service, allow the caller to append those arguments to the 'atomic install ' command.

atomic install ipa-client [atomic args] -- --server <...> --username <...> --password <..>

The double-hyphen marker indicates that arguments to the atomic install command itself are complete. Any arguments following are to be appended to the LABEL INSTALL="..." string embedded in the image when the INSTALL command string is invoked

[rhatdan]

We talked about potentially allowing environment variables to be passed into the container.

Something like
atomic install -e passwd="foo" -e username="bar" --e server=ipa.redhat.com

But I would like to have a conversation with upstream perhaps on the atomic-devel list about this.

[markllama]

In fact, I'd like both args and env, but I only opened the issue for one change.

Of course, then we may need a new LABEL DOC="" so that atomic info will show the appropriate inputs for each step.

Dang, we're re-inventing package management again....

[rhatdan]

Reason I want to bring this up for discussion, is some of Daniel Rieks original ideas was around having the install script ack questions, but then building a framework where the questions could be answered for automated installs.

[goern]

any news on the -e ?

[larsks]

I was just experimenting with the atomic run command and my very first use case required the ability to pass arguments (atomic run myimage command --option arg1 arg2). It also requires the ability to perform standard environment and and command substitution in the command line (LABEL RUN="...-v $PWD:/src -e TARGETUID=$(id -u) ...).

[rhatdan]

@larsks Atomic run myimage will execute the LABEL run command, you want to overide this with your own command or just execute it with additional options?

--options "-u username --password MyPassword"

command substitution works.

grep LABEL.*RUN Dockerfile
LABEL RUN echo '$PWD' '$(id -u)'

atomic run test
echo $PWD $(id -u)
/root 0

[fabiand]

I'd also like to be able to pass additional arguments to the install command. This is usefulw hen you want to set i.e. passwords inside the container during deployment,.

Currently I workaround this by relying on environment variables.

[rhatdan]

The latest atomic code allows additional arguments to be passed to the INSTALL and UNINSTALL command.

Any argument that comes after the IMAGE will get appended onto the INSTALL/UNINSTALL commands.

[markllama]

What is the rational for not allowing args to RUN unless the container is
already running?

On Fri, Jun 5, 2015 at 8:35 AM, Daniel J Walsh notifications@github.com
wrote:

Closed #24 #24.

—
Reply to this email directly or view it on GitHub
#24 (comment).

---

Mark Lamourine markllama@gmail.com
Dad, Hubbie, Software Developer, System Administrator, Road Cyclist

[rhatdan]

This was a design decision that we need to go back and look at. @sctweedie wanted to have multiple atmomic runs end up in the same container. This model works well for the "tools" container model like rhel-tools.

Basically the tool starts the container and then execs into the container. So changes in one rhel-tools container is seen by others when they run the container later or if multiple windows run the same container.

atomic run ends up being create the container if it does not exist and start/exec into it if it currently exists.

This seems to be confusing for people who want to build "single" run containers.

[purpleidea]

I think this is still an issue. Example:

$ atomic run spc-puppet-apply /home/vagrant/sync/docker/spc-puppet-apply/test.pp 
docker run --rm -it --privileged -v /etc:/etc -v /var:/var -v /run:/run --net=host spc-puppet-apply

note the args aren't passed to the run command. Label is:

LABEL RUN="docker run --rm -it --privileged -v /etc:/etc -v /var:/var -v /run:/run --net=host IMAGE"

[bexelbie]

@purpleidea I believe #65 is trying to fix this