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

[Daniel J Walsh <dwalsh redhat com>]

On 11/16/2015 03:17 PM, Dusty Mabe wrote:
>
>
> 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.
>
I have no problem doing both.  But the problem with doing the atomic app
in a container, you end up having to manage the managers container
image.  If we just merged the basics into atomic, then most  use cases
would just work, without having to tell user to build a special
container image based off of an OS.  I have always been concerned about
having multiple atomicapps, one for RHEL, Fedora and Centos.  As a
developer which package to I choose?  Now as we go forward how do I
handle updates to vulnerabilities in the base image? 

Moving to a standard tool on the host, the size of the META Image
shrinks  since all it would need to bring is the nulecule application
specifications and labels, or in some cases the actual application.
>>
>> 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?
>
Should be a LABEL that indicates this is a NULECULE app.  You can look
at the remote image if you want, but I think in most cases you need to
install the image.  Not sure of when  you would not need to install an
image, even if the image does not include an application.
> 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.
>
That makes the user have to understand versus the application
developer.  I don't think we want to have to document that this
application runs with atomic app install versus atomic install.  Atomic
tool should figure this out, and the developer of the application should
specify it for the atomic CLI.
> 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.
>
I believe this should be part of the container image, or should be
prompted by the application. 
> Thoughts?
>
> Dusty
>
>
>
>
>