Add support for atomic command #83

hhorak · 2015-08-25T05:33:44Z

Atomic command is standard way to run containers on Atomic host. This adds support for running this image on such a system using atomic install/uninstall/run, as described at https://github.com/projectatomic/atomic/.

@omron93 @hanzz have you got to something similar to that?

openshift-bot · 2015-08-25T05:35:01Z

Can one of the admins verify this patch?

bparees · 2015-08-25T23:46:26Z

5.5/Dockerfile

+      \${OPT1} \${IMAGE} /usr/share/container-layer/mysql/atomic/uninstall.sh
+LABEL RUN docker run -t -i --rm --name=\${NAME} -e OPT1 -e OPT2 -e OPT3 \${OPT2} \
+      \${IMAGE}
+


you can do these all as a single layer to save build time.

in fact combine them into the label statement above.

Ok, will do.

Actually I'd rather just merge them together, but let all the Atomic labels as one LABEL instruction. The time saved might be 1s but the Dockerfile will be better readable.

bparees · 2015-08-25T23:50:20Z

couple nits, mostly looks good to me.
[test]

jankaluza · 2015-08-28T06:27:22Z

@hhorak

Petr Pisar had some opinion on my atomic install.sh script, which could be valid also for your install.sh, so I'm forwarding it here:

Just from security point of view, the script will have to be much uglier. All
the variables should be quoted and many of them sanitized against leading
hyphens and docker or systemd special keywords.

hhorak · 2015-08-28T08:19:48Z

@hanzz Thanks for pointing to that, will use quotes more :)

mfojtik · 2015-09-02T08:48:44Z

5.5/Dockerfile

@@ -20,10 +20,23 @@ LABEL io.k8s.description="MySQL is a multi-user, multi-threaded SQL database ser
      io.openshift.expose-services="3306:mysql" \
      io.openshift.tags="database,mysql,mysql55"

+# Support for atomic run/install/uninstall
+LABEL INSTALL="docker run -t -i --rm --privileged -u 0:0 -v /:/host --net=host \


this is incredibly ugly :-) @vpavlin are there any plans to make this crypto commands more human-friendly?

Why ugly? This is transparent for the user, so why does it matter? Anyway, this may be raised in the atomic itself (https://github.com/projectatomic/atomic/), I don't think we can do anything differently in this image.

@hhorak just from looking at this, does it seem readable to you? It matters because we want users to build the images that will run on Atomic. Users will eventually copy the patterns we have here. My concern which this pattern is that many users will not really understand what this magic options are for and will end up copying this blindly.

I don't think we can solve this here and now, that is what I tagged @vpavlin to provide his thoughts.

cc @bparees

@hhorak also, I don't want to block this PR from being merged, just want to have discussion about these labels.

@mfojtik No, I didn't say we don't know the story. Just that it might not be obvious for the first glance. The story is to let user run the image properly without being forced to search for READMEs and How-tos. He just needs to know that there is an atomic command which is able to run images that support it.

Also, I didn't say it's ok that users copy random stuff and run it (Hey, have you tried to use Kubernetes and run examples without knowing what that lines mean?:) ). What I am saying is that users just do it that way and the only thing we can do is to provide them with accessible and straightforward documentation.

Your questions about backward compatibilty are very good, but you are asking wrong people at wrong place. @rhatdan is trying to get attention to this for some time already at https://github.com/projectatomic/ContainerApplicationGenericLabels

You need to write out the service file here. Or some configuration (f.e. in case of rsyslog image).

I like @hanzz's proposal/idea but again - this is a wrong place to solve it because not all interested people are following this particular pull request:-)

$OPTx is not only for environment variables, but for modifying the command overall. Let's say you have the --verbose switch which is off by default, but you can turn it on if there is $OPTx on the right place.

Images should work without these options being used, but they should let you tweak the behaviour of image in special cases (like debuging as I described above)

The $OPTx in this image are used to get user/pass/dbname from user, which are required to create a container. I don't have any other way to get those data except $OPTx, do I?
@hanzz not sure I got your crazy idea correctly, but when I tried something like atomic install --unknown ..., then I got /bin/atomic: unrecognized arguments: --unknown...

I totally agree with @mfojtik reading this is hurting my eyes. We've (OpenShift team) put a lot of effort to simplify how to create builder images, with this addition I'm more than 100% sure people will refuse to build those by themselves. One big questions that comes into my head is:
if these are directives for atomic command, can't these just point the necessary information (dirs, ports, etc.) you'll pass down to container engine (be that docker or rocket in the future) and atomic will know how to call docker/rkt run etc. Similarly to how we do with s2i build, we don't put entire logic into the builder image, we just put the necessary bits there to run the command, can't atomic do the same?

@hanzz not sure I got your crazy idea correctly, but when I tried something like atomic install --unknown ..., then I got /bin/atomic: unrecognized arguments: --unknown...

I was proposing the way how atomic could work in the future. It's not implemented like that right now :).

rhatdan · 2015-09-02T11:47:22Z

Perhaps it would be better to create a BlueJeans meeting to discuss these issues.

I am open to ideas on how to fix these issues. I think Vaclav has done a good idea describing what the goal was.

BTW Current atomic will allow you to append content on to the end of the INSTALL/RUN/UNINSTALL lines

atomic install mysql --user=dwalsh --passwd=foobar

Should endup taking the INSTALL line and appending --user=dwalsh --passwd=foobar to the end.

mfojtik · 2015-09-02T14:07:28Z

@rhatdan +1 (I will schedule something for next week, what day suits you best?)

mfojtik · 2015-09-02T14:10:08Z

@hhorak can you rebase this?

hhorak · 2015-09-02T14:30:29Z

@mfojtik as for one of you comments above.. "4) Having this labels in one liner saves some time during a build, but parsing this just with eyes is very hard. I mean I completely missed RUN ;-)" -- that was how it looked first time and i made one command from it after feedback here. If you prefer one command per LABEL, so as I do, shouldn't we return to the previous variant?

mfojtik · 2015-09-02T14:33:29Z

No, I think it is fine (it makes the build faster)... We should work on
better solution than using Docker labels. Lets discuss that next week with
Dan.

On Wed, Sep 2, 2015 at 4:30 PM, Honza Horak notifications@github.com
wrote:

@mfojtik https://github.com/mfojtik as for one of you comments above..
"4) Having this labels in one liner saves some time during a build, but
parsing this just with eyes is very hard. I mean I completely missed RUN
;-)" -- that was how it looked first time and i made one command from it
after feedback here. If you prefer one command per LABEL, so as I do,
shouldn't we return to the previous variant?

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

Michal Fojtik <mi@mifo.sk mfojtik@mifo.sk>
Red Hat OpenShift, Engineering

Conflicts: 5.5/Dockerfile 5.5/Dockerfile.rhel7 5.6/Dockerfile 5.6/Dockerfile.rhel7

rhatdan · 2015-09-02T15:29:40Z

Monday is Holiday in US. Tuesday After 10-15 EDT is open. Also have scattered time Wednesday-Friday

mfojtik · 2015-09-03T08:24:18Z

5.6/atomic-contrib/include.sh

@@ -0,0 +1,12 @@
+# Check whether all required variables are set


@hhorak cab you rename this file to "variables.sh" or "vars.sh" ? As this file really just define variables used by other scripts.

mfojtik · 2015-09-03T08:26:18Z

one renaming suggestion, otherwise LGTM, we will discuss the labels/format on Tuesday.

mnagy · 2015-09-08T14:06:59Z

How would you run this image with atomic and specify a location for the data volume (/var/lib/mysql/data)?

mnagy · 2015-09-08T14:19:27Z

OK, I see that you can use OPT2, I guess.

However, that's just weird and kind of defeats the purpose of making this generic for atomic. I can understand if the labels are meant to be used from shell, for example. But if you are running atomic {run,install,uninstall}, you should be able to use some "normal" metadata for guessing how to run it, no? For example, the metadata might say you need to mount the host rootfs, run privileged and execute a given script (or have a standard location for an atomic install script, so this would be unnecessary). You would get the VOLUME metadata for free.

hhorak · 2015-09-08T14:39:09Z

@mnagy atomic should already contain some feature that allows to use the rest (or unknown) arguments in the docker command. I haven't investigated that yet, but that's what @rhatdan mentioned.

rhatdan · 2015-09-08T17:06:08Z

OPT1, OPT2 and OPT3 should not be used unless the user/tester wants to override the atomic command.

We want

atomic install mariadb

To just work.

If the user wanted to do something like

atomic install --opt1="--debug" mariadb

Then it could replace $OPT1 in the LABEL with "--debug" when it executes the command and potentially run the command in debug mode. But OPT1,OPT2, OPT3 should not be part of the standard command that users execute.

How would you run this image with atomic and specify a location for the data volume (/var/lib/mysql/data)?

The developer of mariadb would just specify the RUN LABEL to be

LABEL RUN "docker run -v /var/lib/mysql:/var/lib/mysql ..."

You might have LABEL INSTALL command do something like running myslqd init to create content in the hosts /var/lib/mysql directory.

If you wanted to support multiple versions of mariadb you could do it based on $NAME

LABEL RUN "docker run -v /var/lib/\${NAME}/mysql:/var/lib/mysql ..."

Which would allow you to run multiple containers with different names.

atomic install --name=mariadb1 mariadb
atomic install --name=mariadb2 mariadb
atomic run --name=mariadb1 mariadb
atomic run --name=mariadb2 mariadb

mnagy · 2015-09-08T17:17:28Z

@rhatdan would it be a normal use-case for atomic to have a DB on host? Would a user running atomic run mariadb expect that behaviour? If so, then the RUN label really should be mounting the volume.

The database is initialized automatically, when none is detected, so there should be no need for the install label to handle this.

rhatdan · 2015-09-08T18:14:33Z

Well you would not have a /var/lib/mysql on the host unless you do an install.

hhorak · 2015-09-09T12:08:43Z

@rhatdan Thanks for the feedback, I've tried to take all that into account when creating reworked version at #92, but there is one difference from your description (except the fact that some environment variables are compulsory in mysql image now, so running just atomic install --name=mariadb2 mariadb won't work and user is required to set MYSQL_USER and other stuff).

The difference is caused by projectatomic/atomic#151 and especially by not using systemd unit for watching the container. How @vpavlin explained me it should work (correct me if I'm wrong) is that atomic install should create the container (docker create) and atomic run should just start that container:

atomic install -n mysql1 mysql-55-centos7
atomic run mysql1
atomic stop mysql1
atomic uninstall

(this workflow defines RUN label as docker start ..., so it makes it impossible to use atomic run without prior atomic install)

However, from what I see in atomic docs, it looks like the atomic run was supposed to be run also standalone (without atomic install first). Then we'd either need something like atomic start which would do what basically docker start does or we can point user not to use atomic to start already installed container and just advise this workflow:

atomic install -n mysql1 mysql-55-centos7
docker start mysql1
docker stop mysql1
atomic uninstall

Any advise which way is better here?

rhatdan · 2015-09-09T13:41:04Z

atomic run will do a start if the container exists, if it does not exists it will execute the LABEL RUN

rhatdan · 2015-09-09T13:44:19Z

I think these would all work.

atomic install -n mysql1 mysql-55-centos7
atomic run -n mysql1 mysql-55-centos7
atomic stop mysql1
atomic uninstall -n mysql1 mysql-55-centos7

hhorak · 2015-09-09T15:26:55Z

I still struggle with some elegant implementation for atomic run -n mysql1 mysql-55-centos7 being run without running atomic install before (which I understood is valid use case as well). The thing is the mysql image won't work unless we specify several -e options. Those options must go before image name in the docker call, otherwise those are not taken as docker options, but rather as CMD + args.

So, for example in case we call

atomic run -n mysql1 mysql-55-centos7 -e MYSQL_USER=myuser1

then what we get is

docker run  -n mysql1 mysql-55-centos7 -e MYSQL_USER=myuser1

while what we need is

docker run  -n mysql1 -e MYSQL_USER=myuser1 mysql-55-centos7

The easiest idea to fix this was to use script similar to install.sh, something like this:

$ cat run.sh
#!/bin/bash
docker run --name "${NAME}" "$@" "${IMAGE}"

and having RUN label like this:

LABEL RUN="docker run --rm \${IMAGE} cat /usr/share/container-layer/mysql/atomic/run.sh | bash -s --"

but I got the following error:

$ atomic run  -n myc4 mysql-55-rhel7 -p 3306:3306 -e MYSQL_USER=user -e MYSQL_PASSWORD=secretpass -e MYSQL_DATABASE=db1
Container 'myc4' must be running before executing a command into it.
Execute the following to create the container:
/usr/bin/atomic run --name myc4 mysql-55-rhel7

Any idea?

rhatdan · 2015-09-09T15:54:50Z

This should probably be in the label.
-p 3306:3306

Why not have the User name and password passed after the command on the run, they will get appended as options on the command.

$ atomic run -n myc4 mysql-55-rhel7 --user=user --password=secretpass --db=db1

rhatdan · 2015-09-09T15:55:58Z

Then the setup script could use these parameters or prompt for them if they are not given.

BTW this is the goal of nulecule/atomicapp to handle problems like this.

@vpavlin @markllama

hhorak · 2015-09-09T20:03:33Z

Why not have the User name and password passed after the command on the run, they will get appended as options on the command.

Now I see why it didn't work for me, I simply had too old version of atomic..

hhorak · 2015-09-10T11:57:25Z

Closing this one in favor of #92, the same feature is gonna be done by that new PR.

Add cgroup utility functions

Add support for atomic command

dbb050f

hhorak mentioned this pull request Aug 25, 2015

atomic uninstall does not run what is in UNINSTALL label projectatomic/atomic#128

Closed

hhorak added 2 commits August 25, 2015 08:57

Include atomic scripts into separate directory

7dbc0cd

Change atomic scripts also in 5.6, forgetten in previous commit.

a3b1bf5

bparees reviewed Aug 25, 2015
View reviewed changes

Fix small issues reported at sclorg#83

2d3c8e5

hhorak added 3 commits August 28, 2015 10:21

Adding quotes to prevent some unneeded variables expansions

7ea10a7

Adding quotes to prevent some unneeded variables expansions even in 5.6

b521575

Fix version in systemd unit template file

3a03ac3

mfojtik reviewed Sep 2, 2015
View reviewed changes

Merge branch 'master' into atomic-support

162fa5f

Conflicts: 5.5/Dockerfile 5.5/Dockerfile.rhel7 5.6/Dockerfile 5.6/Dockerfile.rhel7

mfojtik reviewed Sep 3, 2015
View reviewed changes

Rename include.sh to variables.sh

5e932ba

hhorak mentioned this pull request Sep 9, 2015

WIP: Add support for atomic command without systemd unit file #92

Closed

mfojtik mentioned this pull request Sep 10, 2015

Add Atomic labels openshift/source-to-image#287

Closed

hhorak closed this Sep 10, 2015

hhorak pushed a commit to hhorak/mysql-container that referenced this pull request May 23, 2018

Merge pull request sclorg#83 from mnagy/cgroup_util_functions

e140245

Add cgroup utility functions

		@@ -0,0 +1,12 @@
		# Check whether all required variables are set

Add support for atomic command #83

Add support for atomic command #83

Conversation

hhorak commented Aug 25, 2015

openshift-bot commented Aug 25, 2015

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

bparees commented Aug 25, 2015

jankaluza commented Aug 28, 2015

hhorak commented Aug 28, 2015

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

rhatdan commented Sep 2, 2015

mfojtik commented Sep 2, 2015

mfojtik commented Sep 2, 2015

hhorak commented Sep 2, 2015

mfojtik commented Sep 2, 2015

rhatdan commented Sep 2, 2015

Choose a reason for hiding this comment

mfojtik commented Sep 3, 2015

mnagy commented Sep 8, 2015

mnagy commented Sep 8, 2015

hhorak commented Sep 8, 2015

rhatdan commented Sep 8, 2015

mnagy commented Sep 8, 2015

rhatdan commented Sep 8, 2015

hhorak commented Sep 9, 2015

rhatdan commented Sep 9, 2015

rhatdan commented Sep 9, 2015

hhorak commented Sep 9, 2015

rhatdan commented Sep 9, 2015

rhatdan commented Sep 9, 2015

hhorak commented Sep 9, 2015

hhorak commented Sep 10, 2015