[Container-tools] Atomic CLI + Atomicapp workflow

Fri Nov 6 09:42:50 UTC 2015

On Fri, Nov 6, 2015 at 8:55 AM, Daniel J Walsh <dwalsh at redhat.com> wrote:

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

Interesting..we already had this discussion here
https://github.com/projectatomic/atomic/pull/54

and it got solved here https://github.com/projectatomic/atomic/pull/56

Did it break again?

> >>
> >> 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...
>
> _______________________________________________
> Container-tools mailing list
> Container-tools at redhat.com
> https://www.redhat.com/mailman/listinfo/container-tools
>

My perception is that users are fine using new tools if they ease their
life. From my POV we always struggled to with atomic'S restrictions for
labels, missing ability to pass arguments etc. They got all fixed somehow
over the time, but it's still hard to get our workflow in a such narrow
frame.

That's why I like Dusty's proposal - lets make atomic run some-app work
seamlessly so that users that don't really care about the rest of the
workflow can use it, but let's leave the rest of workflow on the atomicapp
itself.

That will let us add more features easily and make the workflow simple and
digestible for users.

Cheers,
Vašek
-- 
Architect - Senior Software Engineer
Developer Experience
Brno, Czech Republic
Phone: +420 739 666 824
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/container-tools/attachments/20151106/94d8ec4a/attachment.htm>