[Container-tools] Atomic CLI + Atomicapp workflow

[Dusty Mabe]

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.