<div dir="ltr"><div class="gmail_extra">On Mon, Nov 30, 2015 at 11:30 AM, Daniel J Walsh <span dir="ltr"><<a href="mailto:dwalsh@redhat.com" target="_blank">dwalsh@redhat.com</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF"><div><div class="h5">
<br>
<br>
<div>On 11/27/2015 06:31 AM, Vaclav Pavlin
wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">Hi,
<div class="gmail_extra"><br>
<div class="gmail_quote">On Thu, Nov 26, 2015 at 4:56 PM,
Stephen C. Tweedie <span dir="ltr"><<a href="mailto:sct@redhat.com" target="_blank"></a><a href="mailto:sct@redhat.com" target="_blank">sct@redhat.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi,<br>
<span><br>
On Tue, 2015-11-24 at 16:47 -0500, Dusty Mabe wrote:<br>
> I have had a few discussions with Dan and with the
Atomic App core<br>
> team over the past few weeks. We have recognized
some changes that we<br>
> can make to Atomic App to make the integration go
easier. Below is one<br>
> proposed change:<br>
><br>
> - atomicapp will now manage instances of
applications in a similar<br>
> manner to the way docker does by using IDs rather
than the backing<br>
> directory locations as arguments to atomicapp. This
means that rather<br>
> than the atomicapp software notifying you of a
directory path where<br>
> your application can be managed from, it will now
hand you an ID you<br>
> can use to manage it:<br>
><br>
> ```<br>
> atomic install helloapache<br>
> --> <idxyz><br>
> atomic edit <idxyz><br>
> --> will open up text editor for answers.conf
file<br>
</span>...<br>
<br>
Sounds good so far.<br>
<span><br>
> As part of this we'd like to make Atomic CLI able
to detect if a user<br>
> has provided an id or name of an existing
"installed" atomicapp. One<br>
> crude way to do this is to simply use the directory
structure that is<br>
> used to manage the atomicapps and making it have a
predictable naming<br>
> scheme.<br>
<br>
</span>Do we have, or want, a local directory structure in
all cases, though?<br>
Eg. if I'm installing a nulecule to the k8s provider, I'm
not installing<br>
locally at all, I'm installing to the cluster.<br>
</blockquote>
<div><br>
</div>
<div>That's correct, though we need 2 things</div>
<div><br>
</div>
<div>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</div>
<div>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</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>In other words, with what we have right now, I think we
need to store some bits locally.</div>
<div><br>
</div>
<div>Cheers,</div>
<div>Vašek</div>
<div><br>
</div>
<div><br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<span><font color="#888888"><br>
--Stephen<br>
</font></span>
<div>
<div><br>
<br>
_______________________________________________<br>
Container-tools mailing list<br>
<a href="mailto:Container-tools@redhat.com" target="_blank">Container-tools@redhat.com</a><br>
<a href="https://www.redhat.com/mailman/listinfo/container-tools" rel="noreferrer" target="_blank">https://www.redhat.com/mailman/listinfo/container-tools</a><br>
</div>
</div>
</blockquote>
</div>
<br>
<br clear="all">
<div><br>
</div>
-- <br>
<div>
<div dir="ltr">
<div>
<div dir="ltr">Architect - Senior Software Engineer<br>
Developer Experience<br>
Brno, Czech Republic<br>
Phone: <a href="tel:%2B420%20739%20666%20824" value="+420739666824" target="_blank">+420 739 666 824</a><br>
</div>
</div>
</div>
</div>
</div>
</div>
</blockquote></div></div>
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.<br>
<br></div></blockquote><div><br><div class="gmail_default" style="font-size:small;display:inline">+1<br></div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div text="#000000" bgcolor="#FFFFFF">
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.<br>
<br>
The label for INSTALL could be something like<br>
<br>
docker run atomicapp --options $IMAGE<br>
<br>
atomic run myapp<br>
<br>
Would then run<br>
<br>
docker run atomicapp --options helloworldapp<br>
This command could then pull down the "atomicapp" container and run
it passing in the container image named hellowworldapp to execute.<br>
<br>
atomicapp then could examine and use hellowworldapp to run the
application.<br>
<br>
atomic mount helloworldapp /mnt<br>
<br>
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<br>
nulecule container image, so the emacs/vi/gedit would need to come
from the host or from another containers.<br>
<br>
This would allow users to do a <br>
docker commit helloworldapp myhelloworldapp <br>
and create a new helloworldapp container which he could push to the
registry.<br>
<br>
Now he could run <br>
`atomic run myhelloworldapp`<br>
<br>
anywhere in his infrastructure and get his anwers file preanswered.<br>
<br></div></blockquote><div><br><div class="gmail_default" style="font-size:small;display:inline">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.<br><br>[1] <a href="https://github.com/projectatomic/atomicapp/pull/424">https://github.com/projectatomic/atomicapp/pull/424</a><br></div> </div></div><br></div></div>