[Container-tools] Atomic CLI + Atomicapp workflow

[Daniel J Walsh]

On 11/05/2015 06:45 PM, Carl Trieloff 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?
>>
>> 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.
>
>
> _______________________________________________
> Container-tools mailing list
> Container-tools at redhat.com
> https://www.redhat.com/mailman/listinfo/container-tools
I am fine with that.  I will be back in the office next Wednesday on...