[Container-tools] Atomic CLI + Atomicapp workflow

[Daniel J Walsh]

On 11/05/2015 02:57 PM, Dusty Mabe wrote:
>
>
> On 11/05/2015 01:53 AM, Daniel J Walsh wrote:
>>
>> 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?
>
> Atomicapp runs applications in docker or kubernetes or openshift or
> <new provider here>. When you do `atomic run <atomicappimage>` it runs
> a docker container that then starts the application (using docker, or
> kube, etc) and then that docker container exits. At this point there
> are potentially many containers running the application.. What we have
> done in the past is run `atomic stop <atomicappimage>` and then the
> STOP label from that image gets run.. It picks up on what it needs to
> do to stop the application from some state files we have in the
> application directory.
>
> So.. yes, there is not a single container that is running on the
> system that we'd like to have atomic "check" to see if it is running.
>
Why not fix atomic stop to check if there is a container, if not check
if there is a stop label, and execute the STOP label.

It could always execute the STOP label. 
>>
>> 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.
>
> We do still have a goal of making `atomic run <atomicappname>` work,
> but for the other pieces of the workflow have the user's use atomicapp
> itself.
>
>>
>> I think we should be talking more to product management about this as
>> well as Daniel Riek.
> Sounds good to me. Want to set up a meeting?