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

[Dusty Mabe]

On 11/13/2015 11:40 AM, Daniel J Walsh wrote:
>
> On 11/12/2015 06:19 PM, Dusty Mabe wrote:
>> Hey All,
>>
>> We've been having conversations recently about the current
>> architecture of Atomicapp and the way we have envisioned people using
>> it. I prepared a presentation for a meeting we had today about this
>> and was asked to share it with atomic-devel and container-tools (see
>> attached).
>>
>>  From the meeting it seems that we all agree there are some
>> improvements we can make in the existing workflow of developing and
>> deploying Atomic Apps and we are going to pursue investigating a
>> deeper integration between Atomic CLI and Atomic App with respect to
>> deploying Nulecule applications.
>>
>> We also explored a 2nd option during the meeting (covered in the
>> slides) which relates to changing the current model of packaging a
>> Nulecule along with the Atomic App software in a single container to a
>> model where the Nulecule lives on it's own, separate from Atomic App
>> sofwtare. It was agreed in the meeting that this proposal could
>> provide benefits over the current model and we will explore it further.
>>
>> We'd like to ask interested parties to get involved if you have a
>> stake in this and collaborate with us on helping us make the
>> architecture and the user experience better for creating and deploying
>> Nuleculized applications via Atomic App.
>>
>> Thanks,
>> Dusty
> In my opinion we need to stop the confusion when talking about atomic
> app versus atomic cli.  These tools need to be merged together.

So do you mean completely merging them together or just having a tight 
integration? I would prefer to still deliver atomicapp code as a 
container so that we have flexibility of versions that we use (and the 
version used could be controlled by an env var or a value in 
/etc/sysconfig/atomic). Also delivering via container would mean that we 
could change to a go version more easily once we are ready for that.

>
> We need to make the atomic command understand nulecule specifications so
> that you could package up a nulecule app spec into a container
> and atomic could just install and run it.
>
> Since both tools are currently written in Python merging them together
> should not be that difficult.

So looking a little bit at the code a few questions come to mind 
regarding argument parsing and switching between running "atomicapp" 
code to deploy a nuleculized application vs just running an INSTALL 
label on a normal container:

1 - If we make the change transparent to the user then atomic CLI needs 
to do some extra checks on invocation. Since the options/args to 
"install" may be different for traditional install vs "atomicapp" 
install in order to check the arguments we first need to know if we are 
operating on an atomicapp or not and we might have to download the 
container image first in order to find out. What should we do about this?

1a - An alternative to making it transparent to the user is having an 
"atomic app" submodule, similar to the "atomic host" submodule for 
rpm-ostree. As part of this we could also modify Atomic CLI to detect a 
Nulecule when it is run with traditional install and recommend to the 
user to use the "atomic app" submodule for nuleculized applications.

2 - It is valid and sometimes required for a user to provide a path to a 
directory as the location of Nulecule.. For atomic CLI we will need to 
check if a provided argument is a path to a directory with a Nulecule in 
it and act accordingly. Is this acceptable? Note.. using the "app" 
submodule would not require this.

Thoughts?

Dusty