Hey -- is there any versioning for the Atomic command/utility? I think it might be useful to start doing release #'s so we can describe differences between Atomic in Fedora releases, CentOS rebuild/4-week, etc. since there may be times when a release from Fedora has a feature whereas the CentOS rebuild does not.

Thoughts?

After discussion with @sctweedie we agreed that atomic install example should be rewritten without suggesting to copy the systemd unit file to the host filesystem.

Although this is ok for SPCs which should serve as atomic host extension, it shouldn't be used for applications (like databases) and using docker run ... --restart=always in RUN label should be recommended instead.

which is expected, but makes it inconvenient to use. It's possible to use

-                atomic run ${TOOLSIMG} "$@"
+                sudo atomic run ${TOOLSIMG} "$@"

Is that a good idea?

When using the atomic command to download and install a privileged service container
And the image name is not fully qualified
Atomic/Docker executes the docker pull correctly, but then when attempting to run, fails to use the fully qualified image name (or fails to look up the possible matches for an unqualified name)

bash-4.2# atomic install mlamouri/rhel7-ipa-client
Pulling repository registry.access.redhat.com/mlamouri/rhel7-ipa-client
Pulling repository docker-registry.usersys.redhat.com/mlamouri/rhel7-ipa-client
7d348a345a5f: Download complete 
bef54b8f8a2f: Download complete 
...
2ad47aa4dc10: Download complete 
Status: Downloaded newer image for docker-registry.usersys.redhat.com/mlamouri/rhel7-ipa-client:latest
Traceback (most recent call last):
  File "/usr/bin/atomic", line 473, in <module>
    sys.exit(args.func())
  File "/usr/bin/atomic", line 338, in install
    self.inspect = self.d.inspect_image(self.image)
  File "/usr/lib/python2.7/site-packages/docker/client.py", line 709, in inspect_image
    True
  File "/usr/lib/python2.7/site-packages/docker/client.py", line 98, in _result
    self._raise_for_status(response)
  File "/usr/lib/python2.7/site-packages/docker/client.py", line 94, in _raise_for_status
    raise errors.APIError(e, response, explanation=explanation)
docker.errors.APIError: 404 Client Error: Not Found ("No such image: mlamouri/rhel7-ipa-client")

I'm trying to configure kubernetes cluster on a 5 node project atomic nodes and when i want to change the system file of the kubectl it warns me that you can't change a readonly file even if i want to change as a root user.

So is the mount point of /etc/systemd mounts as ro(readonly) if so what can be a workaround to change the values inside the service files.

Thanks,
Vamsi

Wouldn't be nice to use kexec to softreboot your atomic host instead a full reboot specially for baremetal atomic hosts?

Because I did not specify a NAME, it tried to set the container name to the IMAGE name and the IMAGE name has the special characters in it.

# docker pull docker-registry...com/vpavlin/rheltools 
94bcddfdb384: Download complete 
root@jerms-lab7: ~ # atomic run docker-registry...com/vpavlin/rheltools df
/usr/bin/docker run -t -i --rm -e CONFDIR=${CONFDIR} -e LOGDIR=${LOGDIR} -e DATADIR=${DATADIR} --name docker-registry.usersys.redhat.com/vpavlin/rheltools docker-registry.usersys.redhat.com/vpavlin/rheltools df
FATA[0000] Error response from daemon: Invalid container name (docker-registry...com/vpavlin/rheltools), only [a-zA-Z0-9][a-zA-Z0-9_.-] are allowed

Specify a -n flag to make it work:

# atomic run -n test docker-registry.usersys.redhat.com/vpavlin/rheltools bash
/usr/bin/docker run -t -i --rm -e CONFDIR=${CONFDIR} -e LOGDIR=${LOGDIR} -e DATADIR=${DATADIR} --name test docker-registry.usersys.redhat.com/vpavlin/rheltools bash
bash-4.2# exit
exit

Or tag the image:

# docker images | grep rheltools
docker-registry.usersys.redhat.com/vpavlin/rheltools   latest                94bcddfdb384        3 days ago          450.4 MB
# docker tag 94 rheltools
# atomic run --spc rheltools bash
/usr/bin/docker run -t -i --rm --privileged -v /:/host --net=host --ipc=host --pid=host -e HOST=/host -e NAME=rheltools -e IMAGE=rheltools -e CONFDIR=${CONFDIR} -e LOGDIR=${LOGDIR} -e DATADIR=${DATADIR} --name rheltools rheltools bash
bash-4.2# exit

I see its probably for backward compatibility, but how about to make this
compat-hack at least opt-in (or in the worst-case opt-out)?

I was really confused why DATADIR or OPT{1,2,3} variables are carried
through docker command by INSTALL="docker run -e DATADIR -e OPT1..." but
INSTALL="docker run -e NAME ..." has (usually) "no effect".

Implementation:

With #152, if we don't find the dbus bus for the openscap-daemon, we exit with error. The error should tell the user what image needs to be pulled from the redhat registry. As of now, that is still being defined. We may also additionally attempt to pull the image automatically should the 'scan' subcommand be pulled.

My intention is to install a container from image and then uninstall just that one container (without removing image itself).

#> atomic install -n myc1 --opt2='-e MYSQL_USER=myuser -e MYSQL_PASSWORD=mypass -e MYSQL_DATABASE=mydb' 60bfde38982e
#> atomic install -n myc1 60bfde38982e

First problem I have is that -n is not documented.

Second and more important is that using the above the command specified in UNINSTALL label is not run (in this context the systemd service file installed during atomic install is not removed).

Maybe I just don't understand how the atomic uninstall is intended to work, but I suspect the return at https://github.com/projectatomic/atomic/blob/master/Atomic/atomic.py#L482 is causing the issue.

Issues:

• Importing __version__ from Atomic package causes a race condition, where a new user cannot access setup.py without pre installing dependencies.
• python setup.py develop does not work.
• Install Python dependencies on running setup.py {develop,install}
• Fix linting errors

using atomic-1.1-1.git5f631c8.fc22.x86_64 but the changes since that revision seem insignificant re that issue.

$ atomic mount doesn_t_matter /path
Traceback (most recent call last):
  File "/bin/atomic", line 306, in <module>
    sys.exit(args.func())
  File "/usr/lib/python2.7/site-packages/Atomic/atomic.py", line 705, in mount
    self.args.live).mount(self.args.image, options)
  File "/usr/lib/python2.7/site-packages/Atomic/mount.py", line 268, in mount
    driver_mount_fn(identifier, options)
  File "/usr/lib/python2.7/site-packages/Atomic/mount.py", line 302, in _mount_devicemapper
    cid = self._identifier_as_cid(identifier)
  File "/usr/lib/python2.7/site-packages/Atomic/mount.py", line 214, in _identifier_as_cid
    if (__cname_matches(c, identifier) or
  File "/usr/lib/python2.7/site-packages/Atomic/mount.py", line 209, in __cname_matches
    return any([n for n in container['Names']
TypeError: 'NoneType' object is not iterable

The code in question does not check for a (docker's) container to have None as Names key, which apparently Dead container have:

>>> [c['Status'] for c in cli.containers(all=True) if c['Names'] is None ]
[u'Dead']

The code in question should maybe just skip these containers, i.e. (maybe non-idiomatic python following)

diff --git a/Atomic/mount.py b/Atomic/mount.py
index cf0ff07..7f1446e 100644
--- a/Atomic/mount.py
+++ b/Atomic/mount.py
@@ -214,7 +214,7 @@ class DockerMount(Mount):
         container and return its uuid.
         """
         def __cname_matches(container, identifier):
-            return any([n for n in container['Names']
+            return any([n for n in (container['Names'] or [])
                         if matches(n, '/' + identifier)])

         # Determine if identifier is a container

Use case.

I add a label with docker run to an image/Dockerfile

ex.

LABEL RUN="docker run -it --name NAME --privileged -e PS1="[\u@\h \W]$" -e PROJECT_DEFAULTS=ci-ops-projex/config/project_defaults -e SSH_KEYFILE=ci-factory/targets/keys/ci-ops-central -e RESOURCES_DIR=/root/workspace/ci_dev_env -v ${CI_DEV_ENV}:/root/workspace/ci_dev_env IMAGE"

On my system I then export CI_DEV_ENV=/home/ari/workspace

Then I do an atomic run it picks the variable and replaces it for the running container.

stc proposed adding a -D key=value for doing this with atomic run which makes sense.

Of course that's known (Atomic uses the docker api to mount after all).

Unfortunately that won't cover the use case of containers that need to be run before docker is up (networking containers, etc.)

I tried to shoehorn that into Atomic/mount.py, but it does not really belong there, being fundamentally different than the other way to mount.

So, what's the best way forward? Do you agree that use case is worth supporting?

Docker has docker push which takes an image and pushes it to a remote repository. Atomic has atomic upload which takes and image and pushed it to a remote system. These operations seems very similar. Obviously there are differences, since one of them is docker and one of them is atomic but I think using push in both cases would give a slightly more consistent user experience.

I am not sure what's causing this, but it is repeatable and it's not a connectivity thing.

Clean slate:

# docker images
REPOSITORY          TAG                 IMAGE ID            CREATED             VIRTUAL SIZE

First try:

# atomic run busybox sh
Traceback (most recent call last):
  File "/usr/bin/atomic", line 337, in <module>
    sys.exit(args.func())
  File "/usr/bin/atomic", line 145, in run
    inspect = self.d.inspect_image(self.image)["Config"]
  File "/usr/lib/python2.7/site-packages/docker/client.py", line 709, in inspect_image
    True
  File "/usr/lib/python2.7/site-packages/docker/client.py", line 98, in _result
    self._raise_for_status(response)
  File "/usr/lib/python2.7/site-packages/docker/client.py", line 94, in _raise_for_status
    raise errors.APIError(e, response, explanation=explanation)
docker.errors.APIError: 404 Client Error: Not Found ("No such image: busybox")

Second try:

# atomic run busybox sh
Traceback (most recent call last):
  File "/usr/bin/atomic", line 337, in <module>
    sys.exit(args.func())
  File "/usr/bin/atomic", line 145, in run
    inspect = self.d.inspect_image(self.image)["Config"]
  File "/usr/lib/python2.7/site-packages/docker/client.py", line 709, in inspect_image
    True
  File "/usr/lib/python2.7/site-packages/docker/client.py", line 98, in _result
    self._raise_for_status(response)
  File "/usr/lib/python2.7/site-packages/docker/client.py", line 94, in _raise_for_status
    raise errors.APIError(e, response, explanation=explanation)
docker.errors.APIError: 404 Client Error: Not Found ("No such image: busybox")

Third try:

# atomic run busybox sh
/usr/bin/docker run -t -i --rm -e CONFDIR=${CONFDIR} -e LOGDIR=${LOGDIR} -e DATADIR=${DATADIR} --name busybox busybox sh
/ # exit

Always seems to take 3 tries...

Hello.

I am trying to run a PostgreSQL container. The image have a volume in /var/lib/postgresql/data.

The command to run the container is : docker run -d postgres

The log: "chown: changing ownership of `/var/lib/postgresql/data': Permission denied"

I see that every operation over the volume directory is denied

The only way I have get to work is with the --privileged parameter in docker run command.

Perhaps SELinux is bloking the access?

This issue will be discovered every time when docker arguments for running/creating container are not static.

For example mysql image expects to set some docker options by users (-e MYSQL_USER=myuser) and thus we can't set those in INSTALL/RUN labels. For more background see sclorg/mysql-container#92.

We want to allow users to specify these arguments as atomic install <img> -e MYSQL_USER=myuser, so, what we do in mysql case to enable atomic support are basically two things:

• take all arguments and use them as docker options, rather than CMD + args, which is default
• prepare data directory (this parses also the arguments to find whether -u is used, so we can set proper permissions for the data dir)

I think similar issues will have other images as well, so atomic command could support them better.

Some quick proposal from top of my head:
Additional arguments are separated by -- to docker arguments and rest arguments:

atomic install <img> -e MYSQL_USER=myuser -u=1000 -- mysqld --help

Of course we can implement that in every image, but I think this could be the default behavior.

Please add a "stop" operation to compliment 'atomic run'. This command should issue the appropriate docker (or other) command to stop a system container that is running.

This will probably involve adding a check for a corresponding docker image LABEL directive: LABEL STOP='....'

The lifetime of a system container would then be:

atomic install
atomic run
(atomic update|stop ...)
atomic uninstall

Using atomic run to try to run a non-existent command and then trying to run a valid command is producing unexpected errors on the second try.

[cloud-user@atomic-20150125 ~]$ sudo atomic run rhel7 foobar
Pulling repository rhel7
bef54b8f8a2f: Download complete 
Status: Downloaded newer image for rhel7:latest
/usr/bin/docker run -t -i --rm --name rhel7 rhel7 foobar
exec: "foobar": executable file not found in $PATHFATA[0000] Error response from daemon: Cannot start container 1d13f7300872449002527f3a956415cf288466b6f5d1980f613053fb09f80fe6: exec: "foobar": executable file not found in $PATH 
[cloud-user@atomic-20150125 ~]$ sudo atomic run rhel7 /bin/bash
FATA[0000] Error response from daemon: Container rhel7 is not running 
Error response from daemon: Cannot start container rhel7: exec: "foobar": executable file not found in $PATH
FATA[0000] Error: failed to start one or more containers 
/usr/bin/docker run -t -i --rm --name rhel7 rhel7 /bin/bash
bash-4.2#

The same use case when using docker does not have a problem:

[cloud-user@atomic-20150125 ~]$ sudo docker run -it rhel7 foobar
Unable to find image 'rhel7:latest' locally
Pulling repository rhel7
bef54b8f8a2f: Download complete 
Status: Downloaded newer image for rhel7:latest
exec: "foobar": executable file not found in $PATHFATA[0021] Error response from daemon: Cannot start container a6c68632dda5aedd08defdb92dc406a1d4a32306f6250b96ea003cf40df5c20c: exec: "foobar": executable file not found in $PATH 
[cloud-user@atomic-20150125 ~]$ sudo docker run -it rhel7 /bin/bash
bash-4.2#

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

Hi All,
When your image uses VOLUMEN XXX and SELinux is enabled, there are some permission problems, for instance, if you use the following Dockerfile in RHEL 7.1 Atomic GA

FROM registry.access.redhat.com/rhel
MAINTAINER [email protected]
VOLUME /tmp/test
CMD [ "/usr/bin/bash" ]

docker run -ti -rm image_name

[root@32e2fa9abc8a tmp]# cd test/
[root@32e2fa9abc8a test]# touch uno
touch: cannot touch 'uno': Permission denied

What we see ...

1. Every VOLUMEN directory is created in /var/lib/docker/vfs/dir by the docker daemon.

2. The VOLUMEN directory is created with label docker_var_lib_t
   drwxr-xr-x. root root system_u:object_r:docker_var_lib_t:s0 ee4be774547890ff718f319ba1438fe2b8eda33680ce91518d5ce37bb5f2bee0

3. If you change the VOLUMEN label to "svirt_home_t", the command:
   "touch uno" Works OK, so at this point we have several questions ...

4. What are we doing wrong with VOLUMEN ?

5. The directories created in /var/lib/docker/vfs/dir should be label with "svirt_home_t", shouldn't be?

6. This permission problem when working with volumen is a bug or special security feature?

Many thanks.

I think that treating container labels -- at least as implemented in
Docker -- as being similar to RPM header info is going to bring us
trouble and confusion.

Docker images are layered, while RPMs are not. Docker images inherit
labels from parent images, which is going to lead to a variety of
problems largely concerning the accuracy of "provenance" information.
If one produces an image fedora/atomic-tools with:

LABEL Name=fedora-tools-docker
LABEL Vendor=Fedora Project, Inc.

And then I produce a new image from that with:

FROM fedora/atomic-tools

My new image will have the same labels, even if it does something
completely different. For someone not completely clued in to our
use of labels, this is going to result in the accumulation of crap
over time.

Having a "Name" label that is distinct from the name of the image is
also going to be a source of confusion. With this and the preceding
facts about label inheritance, I can have an image named
"larsks/diagnostics" that will return something like
"fedora-tools-docker-21.1-9" in response to "atomic version".

Being able to mark labels as "private" such that they would not be
inherited by subsequent images would mitigate many of these issues,
but that (a) requires core docker changes and (b) probably involves
substantial complications to what is currently a relatively simple
feature.

I'm also not sure that operational labels like "RUN" can be
sufficiently generic to be useful outside of the "atomic" command line
itself. Commands that involve volume mounts or access to the host
filesystem must necessarily make assumptions about the distribution in
place on the host. That's fine if we're producing Fedora images for
use on Fedora platforms (or more broadly X images for use on X
platforms), but doesn't really lend itself to any sort of standard.
For these I think it makes far more sense to adopt the upstream
suggestion of using namespace-prefixed labels (e.g.,
io.projectatomic.atomic.run, io.projectatomic.atomic.install, etc).

We should support e.g. atomic run -v /var/local:/var/local rhel7/rhel-tools so that people can easily transfer data.

Two options I see:

• Explicit support for a subset of docker run options
• Add --docker-opt=-v /var/local:/var/local rhel7/rhel-tools or so (ugly but avoids us having to know about all options)

And...does this override or extend docker options? (It seems like we'd have to know which options are singletons versus overridable...)

I'm leaning towards implementing -v specifically and adding --docker-opt as a generic escape hatch which would just append.

Speaking for myself, I've been moving away from "GPLv2+" by default for two reasons:

• It inhibits code motion to shared libraries
• The Apache 2.0 license is very popular, and incompatible with the GPLv2, which leads to GPLv3, which leads to a mess.

Any objections to using LGPLv2+?

Right now, with the addition of #152, the scan option does not leverage the other parts of atomic that can take an 'identifier' and resolve it to an image id or container id. There is currently function for this in atomic, but each of the functions already does additional things in it. This issue is to track the development of a function that can do the same but be leveraged by other code.

i.e. identifier can be:

• image id or partial
  • container id or partial
  • registery:name
  • part of name?
  • resolved without the registry, only name?
  • others?

Should we add functionality to create systemd unit files directly into atomic so that they are as simple as a proper label?

See manual effort described here: http://www.projectatomic.io/blog/2015/06/running-cockpit-as-a-service/

Kubernetes guestbook example now uses DNS which broke your current getting-started guide.

With #152, there is a new subcommand called 'scan' added. It should have help text assuming the other subcommands do as well.

Hi All,
After upgrading RHEL 7.1 Atomic GA to the latest version, some running containers were deleted.

Any idea ?

How can we troubleshoot this problem/bug? this problem seems to be very serious...

Many thanks.

Hi, atomic run ... doesn't work if the docker daemon was started with TCP connection

more /etc/sysconfig/docker
....
OPTIONS='--insecure-registry dockerregistry.jaja.corp:5000 --selinux-enabled -H [IP]:5320'
.....

-bash-4.2# atomic run registry.access.redhat.com/rhel7/rhel-tools
Unable to communicate with docker daemon: [Errno 2] No such file or directory

If I change to unix socket it works OK,

Bye.

It would be nice to be able to do something like

atomic run --display foo_container

and just see the actual docker command that will be executed without executing it.

Add an informational command to 'atomic' so that a user can determine the state of a system container.

atomic install
atomic run
atomic status [--quiet] [-output (none|text|json|yaml...)]

Status would return text or structured data via STDOUT which would indicate if a system container is correctly installed and running.

a shell return code of 0 would indicate that the container is running and has no status errors.
a non-zero return code would indicate that the container is not running or has some error status or both.

return code 0: running
return code 1: not running
return code N: >1 user defined

the --output .... option would indicate how to format the status output

text: format the output as human readable text
json: format the output as JSON encoded structured data
yaml: format the output as YAML encoded structured data.

The "status" command may require a new default behavior as well as a new Dockerfile LABEL directive:

LABEL STATUS="..."

The script provided in the STATUS label would be executed in response to the 'atomic status' command and the output and return code would be passed back to the caller.

If CONFIG_AUDITSYSCALL=y is not set in the kernel configuration, then the file /proc/self/loginuid will not exist, and all calls to Atomic.cmd_env() will fail when they try to read this file.

Looking at atomic code it looks like that it is not python3 ready - import ConfigParser at atomic/Atomic/config.py@2 , do you have any plans to fix Python3 incompatibilities (if there is more of them)? Or would you accept PR regarding this issue?

/bin/sh: 1: /usr/bin/echo: not found

on debian/ubuntu echo is located at /bin/echo

is there any reason that echo is /usr/bin/ech

 def display(self, cmd):
subprocess.check_call(
"/usr/bin/echo \"" + cmd + "\"", env=self.cmd_env, shell=True)

rather than

 def display(self, cmd):
subprocess.check_call(
"echo \"" + cmd + "\"", env=self.cmd_env, shell=True)

in atomic.py?

In the cmd_env(self) function the call to self.args.opt1 gives an error because stop doesn't have an opt1 arg.

[root@f22 foo]$ atomic  stop delloapache                                                                                                                                                                                                    
Traceback (most recent call last):
  File "/usr/bin/atomic", line 306, in <module>
    sys.exit(args.func())
  File "/usr/lib/python2.7/site-packages/Atomic/atomic.py", line 401, in stop
    self.display(cmd)
  File "/usr/lib/python2.7/site-packages/Atomic/atomic.py", line 759, in display
    "/usr/bin/echo \"" + cmd + "\"", env=self.cmd_env, shell=True)
  File "/usr/lib/python2.7/site-packages/Atomic/atomic.py", line 472, in cmd_env
    if self.args.opt1:
AttributeError: 'Namespace' object has no attribute 'opt1'

If ran PEP8 coding guidelines checker on code-base, it throws warnings.
Idea here is to fix those warnings and have code compliant with PEP8 coding guidelines.

Also should we add a gate for PEP8 check in the CI Job. @rhatdan : Thoughts?

Hi All,
I would like to undestand when I should use "atomic run" intead of "docker run" ?

It looks like atomic install/run command should be used for privileged container, shouldn't it ?

Many thanks.

The current default behavior is inconsistent for SPC and non-SPC invocations (see below).

In short, the default for atomic run --spc drops you into an interactive session. The default for atomic run is to create a running container that can later be used for commands.

PR #74 fixes this behavior.

However, I'd like us to rethink this. I believe a better solution would be something like this:

atomic run [--spc] image [command]:
if (CREATE LABEL present)
execute CREATE label passing command if present in an environment variable
if (RUN LABEL present)
execute RUN LABEL passing command if present in an environment variable
else
use docker create to launch the container and then docker exec with /bin/bash or command if present

atomic start [--spc] image [command]:
if (CREATE LABEL present)
execute CREATE label passing command if present in an environment variable
else
use docker create to launch the container passing command if present

Example of current behavior

./atomic run --spc busybox /bin/ps

Container 'busybox-spc' must be running before executing a command into it.
Execute the following to create the container:
./atomic run --spc --name busybox-spc busybox

./atomic run --spc busybox

/usr/bin/docker run -t -i --rm --privileged -v /:/host -v /run:/run -v /etc/localtime:/etc/localtime --net=host --ipc=host --pid=host -e HOST=/host -e NAME=${NAME} -e IMAGE=${IMAGE} ${IMAGE} /bin/sh

./atomic run busybox /bin/ps

Container 'busybox' must be running before executing a command into it.
Execute the following to create the container:
./atomic run busybox

./atomic run busybox

/usr/bin/docker create -t -i --name ${NAME} ${IMAGE} /bin/sh
busybox

docker ps

CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
e7f88fef782d busybox:latest "/bin/sh" 5 seconds ago Up 4 seconds busybox

LTD-Beget/ansible-modules-core@1c3f750

# atomic run docker-registry....com/vpavlin/rheltools df
Traceback (most recent call last):
  File "/usr/bin/atomic", line 337, in <module>
    sys.exit(args.func())
  File "/usr/bin/atomic", line 144, in run
    self.d.pull(self.image, stream=True)
  File "/usr/lib/python2.7/site-packages/docker/client.py", line 824, in pull
    repository, insecure=insecure_registry
  File "/usr/lib/python2.7/site-packages/docker/auth/auth.py", line 67, in resolve_repository_name
    return expand_registry_url(parts[0], insecure), parts[1]
  File "/usr/lib/python2.7/site-packages/docker/auth/auth.py", line 46, in expand_registry_url
    "HTTPS endpoint unresponsive and insecure mode isn't enabled."
docker.errors.DockerException: HTTPS endpoint unresponsive and insecure mode isn't enabled.

It seems --optX is missing from atomic stop

[vagrant@localhost ~ vagrant]
$ atomic install -h | egrep "opt1"
usage: atomic install [-h] [--opt1 OPT1] [--opt2 OPT2] [--opt3 OPT3] [-n NAME]
  --opt1 OPT1           additional arguments to be passed as ${OPT1} for
[vagrant@localhost ~ vagrant]
$ atomic uninstall -h | egrep "opt1"
usage: atomic uninstall [-h] [--opt1 OPT1] [--opt2 OPT2] [--opt3 OPT3]
  --opt1 OPT1           additional arguments to be passed as ${OPT1} for
[vagrant@localhost ~ vagrant]
$ atomic run -h | egrep "opt1"
usage: atomic run [-h] [--opt1 OPT1] [--opt2 OPT2] [--opt3 OPT3] [-n NAME]
  --opt1 OPT1           additional arguments to be passed as ${OPT1} for run
[vagrant@localhost ~ vagrant]
$ atomic stop -h | egrep "opt1"
[vagrant@localhost ~ vagrant]

Can it be added? I get

$ atomic stop projectatomic/helloapache
Traceback (most recent call last):
  File "/usr/bin/atomic", line 248, in <module>
    sys.exit(args.func())
  File "/usr/lib/python2.7/site-packages/Atomic/atomic.py", line 381, in stop
    self.display(cmd)
  File "/usr/lib/python2.7/site-packages/Atomic/atomic.py", line 719, in display
    subprocess.check_call("/usr/bin/echo \"" + cmd  + "\"", env=self.cmd_env, shell=True)
  File "/usr/lib/python2.7/site-packages/Atomic/atomic.py", line 453, in cmd_env
    if self.args.opt1:
AttributeError: 'Namespace' object has no attribute 'opt1'

are there any instructions for using kube-ui on atomic? it doesn't appear to be included in the distro, but i was wondering if there's any way it can be added or if there's any consideration for adding it?

Will atomic install grow a "default container" to pull ? How is a user supposed to know what to do here?

atomic list could list available images, or possibly only ones that have a LABEL that atomic knows about...

Right now I need to switch over to the docker command to see what images are available.

I am having issues with "atomic run" and also with LABEL RUN where the exposed ports in container are not being published to the host. I have following in Dockerfile:

LABEL RUN="docker run -d -p 4001:4001 -p 7001:7001 -p 2379:2379 -p 2380:2380 IMAGE"

Running the container:

#atomic run etcd
etcd
# docker ps -a
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
4804270b3b28 etcd "/usr/bin/etcd" About a minute ago Up 4 seconds 2379-2380/tcp, 4001/tcp, 7001/tcp etcd

In the above, the ports are not being published to the host.

However when I try docker run, the same container works as expected:

docker run -d -p 4001:4001 -p 7001:7001 -p 2379:2379 -p 2380:2380 etcd

754c29fcc2a0e2edb16981afbf4ba5b92a641099ab014a58bb7c213141cc07b6
Usage of loopback devices is strongly discouraged for production use. Either use --storage-opt dm.thinpooldev or use --storage-opt dm.no_warn_on_loop_devices=true to suppress this warning.

# docker ps -a
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
754c29fcc2a0 etcd "/usr/bin/etcd" 20 seconds ago Up 18 seconds 0.0.0.0:2379-2380->2379-2380/tcp, 0.0.0.0:4001->4001/tcp, 0.0.0.0:7001->7001/tcp modest_feynman

Here the ports are published to the host correctly.

I also tried another version of LABEL RUN with optional argument as follows:

LABEL RUN /usr/bin/docker run -d $OPT1 --name $NAME $IMAGE $OPT2 $OPT3

atomic run --opt1="-p 4001:4001 -p 7001:7001 -p 2379:2379 -p 2380:2380" etcd

etcd

docker ps -a

CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
b4f393cfbae4 etcd "/usr/bin/etcd" 50 seconds ago Up 7 seconds 2379-2380/tcp, 4001/tcp, 7001/tcp etcd

But here again it does not work as expected as ports not are being published to the host correctly.

For the CentOS7/Fedora23 Atomic test day (09/22/2015) there was a centos 7 atomic image where the tree in the image was newer than the remote the image referenced. When I tried to test atomic host upgrade it politely told me that the remote ref was older than what currently existed and then told me how to workaround. When I tried passing --allow-downgrade as suggested I got an error from atomic.

I know I can use rpm-ostree directly but I was told this was a bug by @cgwalters so I'm filing it here.

-bash-4.2# rpm-ostree status                                                                                                                                                                                                                
  TIMESTAMP (UTC)         VERSION        ID             OSNAME                 REFSPEC                                                     
* 2015-09-17 20:46:58     7.20150917     7c37828d3b     centos-atomic-host     centos-atomic-host:centos-atomic-host/7/x86_64/standard     
-bash-4.2# atomic host upgrade 
Updating from: centos-atomic-host:centos-atomic-host/7/x86_64/standard



GPG: Verification enabled, found 3 signatures:

  Signature made Tue 08 Sep 2015 10:01:32 PM UTC using RSA key ID F17E745691BA8335
  Good signature from "CentOS Atomic SIG <[email protected]>"

  Signature made Tue 08 Sep 2015 10:01:38 PM UTC using RSA key ID F17E745691BA8335
  Good signature from "CentOS Atomic SIG <[email protected]>"

  Signature made Tue 08 Sep 2015 10:25:23 PM UTC using RSA key ID F17E745691BA8335
  Good signature from "CentOS Atomic SIG <[email protected]>"


551 metadata, 2834 content objects fetched; 184857 KiB transferred in 62 seconds
error: Upgrade target revision '915aac3154ebf2280b2b646e3f9251805d397edf513bc9b3f3874369a860c90a' with timestamp 'Tue 08 Sep 2015 09:59:09 PM UTC' is chronologically older than current revision '7c37828d3b97aea158feac4475528c6f80cb0454532316df7d0a20b9a6fa9d0f' with timestamp 'Thu 17 Sep 2015 08:46:58 PM UTC'; use --allow-downgrade to permit
-bash-4.2# 
-bash-4.2# atomic host upgrade --allow-downgrade
/bin/atomic: unrecognized arguments: --allow-downgrade
Try 'atomic --help' for more information.

The atomic.sh script attempts to execute the following:

atomic run --spc ${TOOLSIMG} "$@"

With the current revision of the atomic script itself, this will fail with:

Container 'rhel-tools-spc' must be running before executing a command into it.
Execute the following to create the container:
atomic run --SPC --name rhel-tools-spc larsks/rhel-tools

...unless the container is already running. Fundamentally, I think we need to support atomic run <image> <command> regardless of whether or not the container is already running.

Hi,
I have deployed a RHEL Atomic 7.1 host, I would like to increase the docker storage, is there any document about this topic for Atomic host ?

Thanks.

Once PR 152 is merged, the report created with the --detail switch should be slightly cleaned up and tweaked for better formatting.