[Container-tools] Atomic CLI + Atomicapp workflow

[Daniel J Walsh]

On 11/04/2015 01:38 PM, Dusty Mabe wrote:
>
>
> On 11/04/2015 06:25 AM, Lalatendu Mohanty wrote:
>> On 11/04/2015 07:15 AM, Dusty Mabe wrote:
>>> Hi all,
>>>
>>> I've had conversations over the past few weeks with many of you
>>> about atomicapp and running it through Atomic CLI. Basically the
>>> problem is that the INSTALL/RUN/STOP labels are a bit fragile and we
>>> have seen breakage a few times as a result. In the discussions we
>>> have talked about better alternatives and I think this is what we'd
>>> like to go with in the future:
>>>
>>> 1 - the only case where atomic cli needs to work is for running
>>> `atomic run <appname>` any other piece of the puzzle WILL be handled
>>> by the atomicapp cli (excludes openshift use case)
>>> 2 - people can use the atomicapp cli to do
>>> unpack/install/run/uninstall/etc... whatever the tool supports they
>>> can do it
>>> 3 - people can use atomicapp cli from an installed rpm OR from an
>>> alias that runs a docker container to run the cli
>>>
>>> An example of the alias would be:
>>> alias atomicapp='docker run -it --rm  --privileged -v
>>> $(pwd):/atomicapp -v /run:/run -v /:/host --net=host --name
>>> atomicapp projectatomic/atomicapp:latest'
>>> OR in the future may be:
>>> alias atomicapp='atomic run projectatomic/atomicapp'
>>>
>>> The idea is that you would use the alias just like if atomicapp were
>>> installed on the system:
>>> atomicapp install dusty/helloapache
>>> cd /var/lib/atomicapp/dusty-helloapache-9cb2a3704f1d
>>> atomicapp run --provider docker ./
>>> curl localhost
>>> atomicapp stop ./
>>>
>>
>> From a user point of view, just using atomic command wold be
>> relatively easy thing. As it is part of atomic hosts.  What is the
>> possibility of improvement in atomic  command line labels in future?
>> So if it improves in future, should we again consider using it for
>> other labels.
>>
>
> Well the thing is that Atomic CLI assumes some things about the
> arguments you are passing it. For example 'atomic stop' assumes you
> are passing it the name of a running container and tries to detect if
> the container is running and gives an error if not. This doesn't
> really work for us and I anticipate stuff like this will crop up in
> the future as Atomic CLI gets more features.
>
> _______________________________________________
> Container-tools mailing list
> Container-tools at redhat.com
> https://www.redhat.com/mailman/listinfo/container-tools
What does atomicapp expect to happen when  you do an atomic stop?  You
want the STOP label to run even if there is no container?  You don't
want to specify a container?

My fear now is that we are breaking this up to where atomic and
atomicapp will compete against each other.  And users will need to know
for this type of container I run atomicapp and for this other type of
container I run atomic.

We are loosing the original goal where the developer could embed all of
the knowledge of how to run an application into the container image.

I think we should be talking more to product management about this as
well as Daniel Riek.