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

[Aaron Weitekamp]

On Mon, Nov 30, 2015 at 11:30 AM, Daniel J Walsh <dwalsh at redhat.com> wrote:

>
>
> 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>
> 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
>> 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.
>
>
​+1
​


> 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.
>
>
​Dusty and I started to prove out this very proposal. So far only blocker
was[1] so it might "just work" now for the non-openshift use case.

[1] https://github.com/projectatomic/atomicapp/pull/424
​
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/container-tools/attachments/20151130/029bb2c6/attachment.htm>