[Container-tools] [atomic-devel] Atomicapp changes for Atomic CLI: use UUIDs for management

[Daniel J Walsh]

On 11/27/2015 06:31 AM, Vaclav Pavlin wrote:
> Hi,
>
> On Thu, Nov 26, 2015 at 4:56 PM, Stephen C. Tweedie <sct at redhat.com
> <mailto:sct at redhat.com>> wrote:
>
>     Hi,
>
>     On Tue, 2015-11-24 at 16:47 -0500, Dusty Mabe wrote:
>     > I have had a few discussions with Dan and with the Atomic App core
>     > team over the past few weeks. We have recognized some changes
>     that we
>     > can make to Atomic App to make the integration go easier. Below
>     is one
>     > proposed change:
>     >
>     > - atomicapp will now manage instances of applications in a similar
>     > manner to the way docker does by using IDs rather than the backing
>     > directory locations as arguments to atomicapp. This means that
>     rather
>     > than the atomicapp software notifying you of a directory path where
>     > your application can be managed from, it will now hand you an ID you
>     > can use to manage it:
>     >
>     > ```
>     > atomic install helloapache
>     > --> <idxyz>
>     > atomic edit <idxyz>
>     > --> will open up text editor for answers.conf file
>     ...
>
>     Sounds good so far.
>
>     > As part of this we'd like to make Atomic CLI able to detect if a
>     user
>     > has provided an id or name of an existing "installed" atomicapp. One
>     > crude way to do this is to simply use the directory structure
>     that is
>     > used to manage the atomicapps and making it have a predictable
>     naming
>     > scheme.
>
>     Do we have, or want, a local directory structure in all cases, though?
>     Eg. if I'm installing a nulecule to the k8s provider, I'm not
>     installing
>     locally at all, I'm installing to the cluster.
>
>
> That's correct, though we need 2 things
>
> 1) Nulecule is a template and we need ideally the exact version of
> that template for the lifetime  of the application - that's why we
> unpack to /var/lib
> 2) Template needs to be filled with data - that's what answers file is
> for - and that needs to be stored as well as it represents the actual
> application instance
>
> We can potentially skip 1) as long as the Nulecule app is accessible
> in a specific version in registry. We cannot skip 2) completely, but
> we can potentially replace it with some kind of metadata service which
> will be accessible for the deployer and will carry the information
> needed to instantiate the application.
>
> In other words, with what we have right now, I think we need to store
> some bits locally.
>
> Cheers,
> Vašek
>
>
>
>     --Stephen
>
>
>     _______________________________________________
>     Container-tools mailing list
>     Container-tools at redhat.com <mailto:Container-tools at redhat.com>
>     https://www.redhat.com/mailman/listinfo/container-tools
>
>
>
>
> -- 
> Architect - Senior Software Engineer
> Developer Experience
> Brno, Czech Republic
> Phone: +420 739 666 824
Why can't we leave everything inside of the container?  Why not leave
the answers file their and allows users to docker commit the image to
create  a new app with answers answered.

One of the things that Dusty suggested is we have a meta container,
which just contains Nulecule specifications and answer content, as well
as labels.

The label for INSTALL could be something like

docker run atomicapp --options $IMAGE

atomic run myapp

Would then run

docker run atomicapp --options helloworldapp
This command could then pull down the "atomicapp" container and run it
passing in the container image named hellowworldapp to execute.

atomicapp then could examine and use hellowworldapp to run the application.

atomic mount helloworldapp /mnt

Would allow you to mount the myapp specification, and then edit the
answers file as you see fit.  We don't want to imbed any code into the
nulecule container image, so the emacs/vi/gedit would need to come from
the host or from another containers.

This would allow users to do a
docker commit helloworldapp myhelloworldapp
and create a new helloworldapp container which he could push to the
registry.

Now he could run
`atomic run myhelloworldapp`

 anywhere in his infrastructure and get his anwers file preanswered.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/container-tools/attachments/20151130/41cb69ec/attachment.htm>