On Mon, Nov 30, 2015 at 11:30 AM, Daniel J Walsh <dwa...@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 < <s...@redhat.com> > s...@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-to...@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
