Improvements(?) to "atomic run"#429
Conversation
This simplifies the logic.
For consistency. We don't pass "--rm" in any of the other cases.
For consistency and because we already pass "-e NAME=NAME".
For improved maintainability.
It might be docker-latest.
And add the "--remain" option to override that.
Because reusing an already existing or running container is confusing. It is not what "docker run" does and unreliable in general. See https://bugzilla.redhat.com/show_bug.cgi?id=1299813.
|
The problem with this would be break the atomic run rhel-tools container/pet containers use case, correct? |
|
Here was the initial design document for the atomic run/install/uninstall command. I don't believe we can change the default behaviour. But I agree for people understanding the docker run behaviour it is strange. https://docs.google.com/document/d/14U03ggEjerBhG-PAdWhxJsnpLu04rVVzoHbXppjsHhk/edit |
I guess the pet container use case covers stuff like installing a new package into the container with yum and having it available from then on, right? This would be broken by "Use unique conainer names by default", yes. |
Thanks. How do you create an "interactive image"? |
|
Let's close this. I'll try to come up with something that preserves the pet container use case. |
2 participants
This makes "atomic run" behave more like "docker run" in that it doesn't reuse an existing container by default.
This is motivated by https://bugzilla.redhat.com/show_bug.cgi?id=1299813
It also addresses some potential inconsistencies:
atomic run --spcwould pass--rm, while the rest would notatomic run --spcwould not pass--name, while the rest wouldatomic runwith a RUN label might not run docker-latestIf one wants to use "atomic run" reliably without this, one can explicitly pass a unique "--name" option and delete the container explicitly afterwards. However, I think it would be nice if atomic run itself would offer a easy way to do the right thing, even if only optionally via explicit "--unique" and "--rm" options, say.