[Container-tools] Atomic CLI + Atomicapp workflow

[Carl Trieloff]

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?
>
> 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.
>

Maybe a chat would be good.

As you state our goal is still the same with all the meta-data in the
'root' container nulecule or chained micro-service. however with Atomic
Cli doing stop on an instance we don't have that meta data, so there are
some issues/opportunities here that we need to think about.

Carl.