Change the install data format to keep a list of containers for each
image installed, so that multiple containers for the same image can be
installed and uninstalled.
Closes: https://bugzilla.redhat.com/show_bug.cgi?id=1559935
Signed-off-by: Giuseppe Scrivano <gscrivan@redhat.com>
Closes: #1214
Approved by: baude
do not reload the list of all the images every time we check if an image
is dangling. This makes "images list" extremely slow when used on the
Docker backend.
On my system (with ~100 images), this patch brings down the wall clock
from ~10 seconds to ~0.5 seconds:
$ /usr/bin/time -v ./atomic images list -a 2>&1 | grep "wall clock"
Elapsed (wall clock) time (h:mm:ss or m:ss): 0:09.84
to:
$ /usr/bin/time -v ./atomic images list -a 2>&1 | grep "wall clock"
Elapsed (wall clock) time (h:mm:ss or m:ss): 0:00.58
Signed-off-by: Giuseppe Scrivano <gscrivan@redhat.com>
Closes: #1200
Approved by: rhatdan
use the implementation of validate_image_manifest and
adapt it to be used in place of validate_layer.
Signed-off-by: Giuseppe Scrivano <gscrivan@redhat.com>
Closes: #1150
Approved by: rhatdan
More advanced functions in the atomic cli need to have the backend functions
for things like has_container and inspect_container working correctly.
Signed-off-by: baude <bbaude@redhat.com>
Closes: #1093
Approved by: rhatdan
Enable tagging as a function on the backend. This gives c-s parity
with the other backends where needed.
Signed-off-by: baude <bbaude@redhat.com>
Closes: #1092
Approved by: rhatdan
Originally an AttributeError was raised:
Unable to find an image named net-snmpp in ostree
Traceback (most recent call last):
File "./atomic/Atomic/backends/_ostree.py", line 168, in run
name = iobject.name
AttributeError: 'NoneType' object has no attribute 'name'
Now the user is told why run failed:
$ sudo atomic run --name=test --storage ostree --display net-snmp true
$ sudo atomic run --name=test --storage ostree --display idontexist true
Unable to find an image named idontexist in ostree
$
Closes: #1075
Approved by: ashcrow
Differently than the Docker implementation, it allows
to run commands even if the container is not running yet.
Signed-off-by: Giuseppe Scrivano <gscrivan@redhat.com>
Closes: #1075
Approved by: ashcrow
Fix test failures after updating papr to test with f26 atomic/cloud
images instead of f25, with the following changes:
1. Remove dependency on docker hub tester image. Instead, mimic
what ostree/rpm-ostree does and use a recursive .papr.sh script
to install the necessary packages to the base f26 image in the
fedora registry. This fixes tests on the atomic host since python3.6
is being used, and prevents future tests from testing the wrong
version. (Note this is slightly slower due to having to install
packages during the test rather than using a pre-built image).
2. Fix some pylint errors, and mask others for now
3. Fix failing integration tests due to inter-test interference
4. Remove unnecessary deepcopy in container filter
5. Add compatibility for both c-s-s and d-s-s in storage
6. Update expected sha256 values for dockertar test
Remaining issues:
1. test_storage should possibly be reworked. The current test
setup is conflicting with the new default of overlay as a driver.
For now, the test for generated d-s-s is disabled.
2. some storage commands are still using "docker-storage-setup"
instead of "container-storage-setup". There is a backward
compatible check in place that should be reworked in the future
3. some masked pylint errors should be further investigated
4. keep the dockerfile for the project atomic tester image for now
(bump to 26), since its a little easier and faster to set up with
Signed-off-by: Yu Qi Zhang <jerzhang@redhat.com>
Closes: #1076
Approved by: baude
When wanting to run a command in a already running container,
a NoneType error was being thrown when the image lookup
failed.
This was reported in BZ #1481967
Closes: #1069
Approved by: rhatdan
A new backend is being added to the Atomic CLI called "Containers Storage". This commit
covers the addition of the backend itself. The backend is only made available in the
atomic CLI if an export variable called 'DEV' is found. For example:
sudo DEV=true atomic images list -a
Each method in the backend (with the exceptionof def available) raises an
UnderDevelopment Exception. As the methods are developed, the exceptions will be removed.
Closes: #1038
Approved by: rhatdan
A bug was reported in issue #1022 where if the atomic install data failed,
the installation data was still written allowing the user to proceed
with an atomic run.
Disabling test_install.sh until i can follow up with Thomas.
Closes: #1025
Approved by: baude
As pointed out in issue #1023, when you run an interactive
container and then subsequently run it with commands, you can
get a case where the container is running. If you run another
image that will end up using the same container name but is born
of a different image, you get confusion.
In this case, we adopt the --replace function as we did with earlier
run/image mix-ups.
Closes: #1026
Approved by: baude
There were two primary cases where a secondary atomic run with a command
would trigger an exception. The first was reported in
https://github.com/projectatomic/atomic/issues/1006. Basically it can
be summarized as:
```
atomic run registry.fedoraproject.org/fedora:25 date # works fine
atomic run registry.fedoraproject.org/fedora:26 date # tries to run in the existing f25 container
```
The second case is as simple as:
```
atomic run registry.fedoraproject.org/fedora:25 date # works fine
atomic run registry.fedoraproject.org/fedora:25 date # fails
```
This fails because atomic starts the stopped f25 container and then attempts a docker exec. The
exec fails because the 'date' command is short-lived and the container exits prior to the exec
being run.
We now catch those exceptions and notify the user. We added a `--replace` option to run where
atomic will now delete the container in question and re-run it from the correct image.
Closes: #1019
Approved by: baude
The atomic tag function was not working correctly for docker images
in the dockerd. Also, when attempting to tag an image from one
backend into another, we didn't handle the error correctly. This should
not work.
Add integration tests for tagging invalid images, dockerd, and ostree.
This should fix BZ #1454656.
Closes: #1014
Approved by: baude
If a shortname is used to run an image, we need to transform the short
name into the fq-name when doing the lookup in the installed images
data.
Reported in BZ #1454292
Closes: #1010
Approved by: baude
Bugzilla #1430708 recommends that if an atomic user attempts to pull
an image that is already present, we should not exit with a '1' which
indicates a failure; rather a 0.
Closes: #997
Approved by: baude
As requested in BZ #1447848, if a ostree mount is desired, we should
not block on requiring an active dockerd. Same for unmount.
Closes: #998
Approved by: baude
For some reason when shorthand is used to add a list and str/unicode,
a type Error is not thrown where shorthand is cmd += foo versus
cmd = cmd + foo. Reverting to the long hand appears to resolve issue
https://github.com/projectatomic/atomic/issues/986
Closes: #987
Approved by: baude
We need to make sure the atomic_dbus_client code works and if something
in atomic_dbus.py changes, the client should either be updated or still
work.
Closes: #975
Approved by: rhatdan
and add the implementation for the Docker and the OSTree backends.
Signed-off-by: Giuseppe Scrivano <gscrivan@redhat.com>
Closes: #958
Approved by: rhatdan
Bugzilla 1437447 has brought up an issue where if a user runs:
atomic pull rhel7
The resulting image in dockerd is docker.io/rhel7. The Atomic CLI
does tell skopeo the right information"
/usr/bin/skopeo --debug --policy=/etc/containers/policy.json --debug copy --remove-signatures docker://registry.access.redhat.com/rhel7:latest docker-daemon:rhel7:latest
But somewhere along the line, we think in skopeo, docker.io is prepending to the destination
image name. One way to resolve this is to always use the fq name for the destination and not
what the user wanted.
This is a change in the default behaviour of atomic and I am not sure I am confortable with this. But
given that we have several folks on PTO or travelling, I'm putting this PR together so that
if we decide this is the proper route for fixing, it will be done.
Closes: #959
Approved by: baude
When installing an image, we now write a small bit of json
to /var/lib/atomic/install.json. The json format is:
{
<image_name>: {
id: <image_id>,
install_date: <install_date_in_utc
}
}
This will be used in update, run, etc to ensure that any image
with an INSTALL label is first installed.
Closes: #950
Approved by: giuseppe
When running an image with atomic run, if the container already exists,
we were accidently displaying a message stating that the container's
image was old. This was due to an invalid comparison between the container's
image id and the image's id. The comparison was failing because we were
comparing two different variables and not the ids.
This was reported in bugzilla https://bugzilla.redhat.com/show_bug.cgi?id=1434430
Closes: #945
Approved by: rhatdan
If the image is built (and updated) locally, we need to handle this
differently than if the image came from a registry. We now
can try/except our way through things and properly handle.
Closes: #938
Approved by: rhatdan
Prior to refactoring, we had a check_latest method that would check
to see if the image being used by container was the latest image
by simply comparing hash IDs.
Adding this back in and refactoring into docker.py.
Closes: #938
Approved by: rhatdan
An exception was being thrown when trying to run a command inside
an already running container. For example:
sudo atomic run foobar echo true
The problem was a lack of a setter for user_command in the container
object as well as some mishandled string <-> list conversions.
Closes: #938
Approved by: rhatdan
The following integration tests have been added:
* ScanList
* ImagePull
* ImageUpdate
* ImageUpate when at latest
* ImagePull when already at latest
* Run
* ContainersDelete
* ContainersDelete when container doesnt exist
Closes: #904
Approved by: rhatdan
