Re: [atomic-devel] [Container-tools] AtomicApp/Nulecule Design and Workflow

["Brian (bex) Exelbierd" <bex pobox com>]

On Nov 23, 2015, at 8:17 PM, Daniel J Walsh <dwalsh redhat com> wrote:
> 
> 
> 
> On 11/22/2015 11:09 AM, Brian (bex) Exelbierd wrote:
>>> On Nov 13, 2015, at 7:19 PM, Charlie Drage <cdrage redhat com> wrote:
>>> 
>>> Personally I'm on the fence on whether or not we should have two
>>> different CLI's, however, as Dan Walsh pointed out. It's confusing
>>> having two similarly named CLIs.
>>> 
>>> However... we should still keep the projects separate and rather
>>> "bridge" the two together by passing / using the atomicapp container.
>>> This coincides to Dusty's slides about how we could possibly add:
>>> 'atomic exe --label=unpack <image> COMMANDS' through a PR to atomic.
>>> 
>>> Currently we have to pass in --opt3 variables in order for params such
>>> as '--provider=docker' and  '--answers=/tmp/answers' to be used correctly. We
>>> could fix this atomicapp side by adding non-ordered arguments
>>> so they may be passed anywhere in the command line. 
>> 
>> Could the Atomic CLI make this easier by changing the way it parses arguments and manages labels?
>> 
>> Warning, immature ideas follow.
>> 
>> 1) `atomic XXX ...` just looks for a label called XXX and runs it.  That way arbitrary verbs are possible, when needed.  Standards and linters should help keep things clean.
> My problem with this is how would the user discover the verbs.

We could extend the atomic CLI to provide the verbs.  It could also provide some documentation encoded in the labels. 

>  We want
> to tell the user one way to install all applications,  The information
> on how to use an app should
> be inside the app image.  If we have to tell the user go to this web
> site and cut and paste a command like atomic foobar -xyz  Then we have
> failed.

While I agree with you, I believe we will never get away without documentation of some sort, including commands that could optionally be cut and pasted.

> If we want to have a new command in atomic CLI, then lets add it and
> justify it.

I will leave this to Dusty and friends for now.

>> 
>> 2) Could argument parsing in Atomic CLI be made more flexible than the current OPT system?  Could the parser learn how to manage arguments like this:
>> 
>> RUN: docker run -it $foo $bar:o container command $destination $*
>> 
>> This is an attempt to specify the following substitutions:
>> 
>> $foo = whatever the entirety of a --foo== or -foo= or -foo or --foo - required
>> $bar = the same as $foo for s/foo/bar/ but optional
>> $destination = same as $foo above with s/foo/destination/
>> $* anything left over
>> 
>> This fixes positional problems, add some error output, etc.
> I would prefer to see a real world examples.  We now allow environment
> variables to be passed and we have --opt1, --opt2, --opt3  Not sure
> what we can't do now, that you want added.

The goal with this suggestion isn't to add new functionality to make something possible, but to make the possible easier to understand.

For example:

RUN: docker run -it --rm  --privileged -v `pwd`:/atomicapp -v /run:/run -v /:/host --net=host --name ${NAME} -e NAME=${NAME} -e IMAGE=${IMAGE} ${IMAGE} -v ${OPT2} run /atomicapp

for a container needing a local mount would have to be invoked as:

OPT2=/some/dir/some/where atomic run image

However, a label like this:

RUN: docker run -it --rm  --privileged -v `pwd`:/atomicapp -v /run:/run -v /:/host --net=host --name ${NAME} -e NAME=${NAME} -e IMAGE=${IMAGE} ${IMAGE} $workdir run /atomicapp

could be invoked in a more friendly way like this:

atomic run image -workdir=/some/dir/some/where

Is this more clear?

regards,

bex