[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [atomic-devel] AtomicApp/Nulecule Design and Workflow



Personally I'm on the fence on whether or not we should have two
different CLI's, however, as Dan Walsh pointed out. It's confusing
having two similarly named CLIs.

However... we should still keep the projects separate and rather
"bridge" the two together by passing / using the atomicapp container.
This coincides to Dusty's slides about how we could possibly add:
'atomic exe --label=unpack <image> COMMANDS' through a PR to atomic.

Currently we have to pass in --opt3 variables in order for params such
as '--provider=docker' and  '--answers=/tmp/answers' to be used correctly. We
could fix this atomicapp side by adding non-ordered arguments
so they may be passed anywhere in the command line. 


On 11/13, Jason Brooks wrote:
> 
> 
> ----- Original Message -----
> > From: "Daniel J Walsh" <dwalsh redhat com>
> > To: "Dusty Mabe" <dusty dustymabe com>, atomic-devel projectatomic io, container-tools redhat com
> > Sent: Friday, November 13, 2015 8:40:07 AM
> > Subject: Re: [atomic-devel] AtomicApp/Nulecule Design and Workflow
> > 
> > 
> > 
> > On 11/12/2015 06:19 PM, Dusty Mabe wrote:
> > > Hey All,
> > >
> > > We've been having conversations recently about the current
> > > architecture of Atomicapp and the way we have envisioned people using
> > > it. I prepared a presentation for a meeting we had today about this
> > > and was asked to share it with atomic-devel and container-tools (see
> > > attached).
> > >
> > > From the meeting it seems that we all agree there are some
> > > improvements we can make in the existing workflow of developing and
> > > deploying Atomic Apps and we are going to pursue investigating a
> > > deeper integration between Atomic CLI and Atomic App with respect to
> > > deploying Nulecule applications.
> > >
> > > We also explored a 2nd option during the meeting (covered in the
> > > slides) which relates to changing the current model of packaging a
> > > Nulecule along with the Atomic App software in a single container to a
> > > model where the Nulecule lives on it's own, separate from Atomic App
> > > sofwtare. It was agreed in the meeting that this proposal could
> > > provide benefits over the current model and we will explore it further.
> > >
> > > We'd like to ask interested parties to get involved if you have a
> > > stake in this and collaborate with us on helping us make the
> > > architecture and the user experience better for creating and deploying
> > > Nuleculized applications via Atomic App.
> > >
> > > Thanks,
> > > Dusty
> > In my opinion we need to stop the confusion when talking about atomic
> > app versus atomic cli.  These tools need to be merged together.
> 
> +1 atomicapp needs atomic (practically) to work -- it'd be simpler if
> they were combined. What's the downside?
> 
> Jason
> 
> > 
> > We need to make the atomic command understand nulecule specifications so
> > that you could package up a nulecule app spec into a container
> > and atomic could just install and run it.
> > 
> > Since both tools are currently written in Python merging them together
> > should not be that difficult.
> > 
> > 
> 

-- 

Charlie Drage
Red Hat - OSAS Team / Project Atomic
4096R / 0x9B3B446C
http://pgp.mit.edu/pks/lookup?op=get&search=0x622CDF119B3B446C


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]