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

Vaclav Pavlin vpavlin at redhat.com
Fri Nov 27 11:31:20 UTC 2015


Hi,

On Thu, Nov 26, 2015 at 4:56 PM, Stephen C. Tweedie <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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/container-tools/attachments/20151127/3f097273/attachment.htm>


More information about the Container-tools mailing list