[Container-tools] Atomic CLI + Atomicapp workflow
Daniel J Walsh
dwalsh at redhat.com
Sat Nov 7 05:17:27 UTC 2015
I think we need to discuss this carefully before we make this decision.
I also want other parties involved, including Daniel Riek and Subhendu.
On 11/06/2015 10:42 AM, Vaclav Pavlin wrote:
>
> On Fri, Nov 6, 2015 at 8:55 AM, Daniel J Walsh <dwalsh at redhat.com
> <mailto: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 <mailto: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 <mailto: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 <mailto: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/20151107/3f3fed7f/attachment.htm>
More information about the Container-tools
mailing list