It's nicer for branding the command. The more correct thing would be
to add it to the rpm-ostree daemon and pass through there, but we have
more important problems to fix for the production code path. This is
just for local development, so the slightly dirty way is just fine.
Laymen users who are told to run a image may not understand
the docker run switches that have security implications. We
now look for the following switches:
* --privileged
* --cap-add
* --security-opt label:disable
* --net=host
* --pid=host
* --ipc=host
and output an appropriate security message.
Also, moved def run() from Atomic/atomic.py to Atomic/run.py
to reduce the size and the number of definitions in
Atomic/atomic.py.
Images or containers can now have an associated
man-like help page to help users understand more
about the image. Typical information included
are things like a longer description, if the image
needs to be installed, security implications, steps
to upgrade, etc.
The default behavior is for atomic to display
a file called help.1 (in man format) located in
the / of the docker object. This default
can be overriden with the HELP LABEL. The
HELP LABEL needs to be a fully qualified
command to work correctly.
Basic tests for atomic diff and top which should catch
basic code regressions.
In top.py, added -n for number of iterations. And added
tty detection so that tests can pass in a jenkins environment
where there is no tty.
Adding a new atomic sub-command that behaves like GNU top
but for processes being run for containers. It currently
displays the container id, container name,
pid, cpu% (as reported by docker
top), mem% (as reported by docker top), and the command.
You can optionally pass in -o ppid, stime, time to collect
more data on the processes themselves.
While in the interactive display, you can also sort on
the columns to re-organize the data as needed.
You can define an interval for refreshing the process
information.
atomic top can be run without any additional
parameters. If that is the case, it will by default
show processes for all active containers. You can also
add one or more container_ids for exclusive process
monitoring by container.
Also added an AtomicDocker class to atomic.py which
allows for custom docker, python-api calls without
having to re-invent the wheel.
Allow users to diff between two docker images|container. There
are two types of diffs that can be run -- a file diff or an
RPM diff. The file diff is always the default. The RPM diff
can be added with -r. The file diff can be excluded with -n.
Added a push-to-satellite function, might have gotten the config stuff to work. Jenny Ramseyer
refactoring and adding documentation
rechecked API calls. More documentation
it builds. Still not sure the config file parser is going to work--need to check section headings, but it builds. Jenny Ramseyer
switched false to true in config.py
debugging the REST API calls
more bug fixing. May have fixed payload, need to check. Have to decide what to do about publish
Fixed. It should work now. Need to fiddle around with create_repo more, but the rest should be good. Thanks to David Davis for help with uploading an image.
debugging create_repo
fixing build error.
fixing some build errors. Still can't push to Satellite or Pulp. Not sure why, working on that. Jenny Ramseyer
more bug fixing, cleaning up CLI
minor tweaks
fixed the push to pulp/satellite problem! Thanks to Alec and Will for the help! Now new error
Seems to be working now
Hooray it works. Now we're getting connection errors, which I will try to debug. But I think it works. Might have messed up an API call, which is why it won't connect? Or maybe it is a server problem? I will investigate. --Jenny Ramseyer
committing before merge
Sending in this as a pull request.
satellite and pulp are now mutually exclusive arguments
Fixed the authentication problems in the code.
Debugging upload calls
Added debug mode
Figured out how to get content view id, org id, repo id, etc. This relies on the user knowing their activation key, which I am not sure we can count on, but I think we can. Currently it has the problem that we automatically take the first product id, which is wrong in many cases. But, we can't let the user input the product id (they don't have it--the satellite web UI gives them a product id, but it is different from the internal product ids). The other option would be to have the user input the name of the desired product, but that relies on them inputting it exactly as in the json output, which seems unlikely. Also not very elegant.
Fixed the post request such that now, when we send a no-data post request, the _no data_ is seen as a json file, so the request goes through (this was to fix the problem where the server was rejecting our requests to get an upload id)
Note: you need to run this with sudo, which means that you need the admin file on your root directory (at least, in my case I needed to run it that way)
Turns out that, while the user doesn't see the activation key number on the website, it is in the URL of the activation key page
updated manpage
fixed some bugs, upload still doesn't work
Switched to multipart request
Fixed the uploading bug. Now I have a different uploading bug, but it seems much more tractable. Will update as progress continues
Now I get a 405 method not allowed error. Not sure what's happening with that, but I will keep investigating
Now we require the user to pass in both the repo and the activation key. This is standard for Satellite, and saves us from the horrible hacks I did before. More robust code. Problem is that both of these numbers are only available in the URL to their respective pages in the Satellite UI
Added to man page. Also added better error handling for uploading
It works now. Hooray
fixed it so we don't actually need to take a tar file.
Better error handling
fixed upgroup, haven't fixed bash yet
got bash completion working.
Moving push image to satellite/pulp to their respective files, instead of util
adding helpful configuration comment
making everything pep8 compatible
reverting back to old system
modified to make pep8 compatible
Signed-off-by: jramseye <jramseye@redhat.com>
Use --display to view run or install commands without
executing the commands. This is useful when working with custom images
with LABEL methods defined.
Signed-off-by: Sally O'Malley <somalley@redhat.com>
This command takes an image and checks the local images for newer version, if one
exists it tells the user to run it. It also searches through all of the layers to
find any layers which might have a newer image, and then reports on them.
atomic verify test
Image 'test' contains a layer 'Apache:1.0:1' that is out of date image version 'Apache:1.0:2' is available.
You should rebuild the 'test' image useing docker build, it could be vulnerable.
Want to be able to display atomic version including layers ID, NAME:VERSION:RELEASE Repository/Tag
Will also display recursively all layers in the image.
atomic version test
afecc5f6a3c4d8f2326901c94cdf84aab0890ea827c38f2b0d2e2a4ba5ace7d6 Apache:1.0:1 test:latest
Another feature I have added is, the ability to recurse though all of the layers of the image.
atomic version -r test
afecc5f6a3c4d8f2326901c94cdf84aab0890ea827c38f2b0d2e2a4ba5ace7d6 Apache:1.0:1 test:latest
21b2d6e4171b024cb48bb2d02d626481e37724a6e03dac7962e44cc8612fbf22 Apache:1.0:1
83202d54cf27439381b3d668d02f3a21cb75ebba4623d86e1fdbad614660424e Apache:1.0:1
90ff7403d883c0ccde72bf630cb77e224fd6b517fc4b61b84f8d9739dab93c9f Apache:1.0:1
12f19f77bc52483d902727b6c142f20cc79109ad45e36869f30c15228534eb5b Apache:1.0:1
4bcd0ad4dbe8c39f49094c3f13c8aa517efe6c76de1aacb6fca413ee3372dd98 Apache:1.0:1
fabaf6ef3297a7d6006ee24034aa2ba525f064f108580d4b44944e24b1581513 Apache:1.0:1
eb10dd5ab6a2a649d5e069c67fdd71506db0b0a1e4a5b5680c1d3f317bfa320a Apache:1.0:1
b0bc3c982c88037a5e7b6e7e6de900981c9f90516014b7071fe860ca39a22d02 Apache:1.0:1
99878fca96575b6ccac2fa54a2f2a44ad85d94344e8fbde5ae2350e3b5eec98b Apache:1.0:
fc8782dfd543be2a582cf8ee7eff4e39c46a980f212891342ac4c6c6917ee211 Apache
cf6c210ea5b979204df75ad4aeaa3dcb971589c2399d79e6c2a71e7588e95cd9
4dab839254d036da5ad52f459d6602b1a84f379fe94c722bd969db14e119189a
011c13014fd9ede3e53119f380e20b88af2e8bd40afb1b3925ed39cbd067e453
834629358fe214f210b0ed606fba2c17827d7a46dd74bd3309afc2a103ad0e89 fedora:21
00a0c78eeb6d81442efcd1d7c02e8b141745e3a06f1ee3458e1bae628e0067d3
511136ea3c5a64f264b78b5433614aec563103b4d4702f3ba7d4d2698e22c158
