[Container-tools] Improving the atomic.app developer experience

[Josh Berkus]

All,

Many responses, see below ...

On 03/02/2016 12:10 AM, Vaclav Pavlin wrote:
> What is tree file?

The Nulecule file.

On 03/02/2016 05:09 AM, Vaclav Pavlin wrote:
 > btw..I've noticed there will be ".app" domain made available this year,
 > maybe we should register for http://atomic.app :D

Domain pre-reservation made.

On 03/02/2016 05:18 AM, Brian (bex) Exelbierd wrote:
 > As I recall there was some discussion around devconf.cz about taking
 > nulecule in a direction of more sensible defaults and simplification to
 > try and make the files easier to comprehend and generate.

I have to admit that to me it's a bit unclear on what's defined by 
Nulecule as opposed to atomic.app.

 > This is some of what I took away from the conversation I reference
 > above.  I think that we need to think about what kind of
 > stubbing/scaffolding support we want to assist developers with in
 > general.  We could easily extend Atomic App to do this, but it needs to
 > be in a way that is accessible to everyone on all platforms.

 >> 3. Integrated Image Build: as the next step, it would really help
 >> developers if we could build their images (e.g. myuser/mywebapp),
 >> register them, and then deploy them via atomic app as one command.  This
 >> would mean that users would just provide a tree file and a set of source
 >> code repos (with dockerfiles) and one command would do the rest.
 >
 > I believe this is a key feature and benefit of using OpenShift.  Does it
 > make sense for the use cases to add s2i like functionality to other
 > situations such as pure docker or kubernetes?

Does S2I do multi-container apps?  If not, then this is a great place 
for collaboration on features.

On 03/02/2016 07:50 AM, Dusty Mabe wrote:

 > So basically 'automatically' generating provider config files
 > (kubernetes, openshift, mesos/marathon, etc..). Is that correct?

Yes, unless the user needs something fairly wonky.
 >> 3. Integrated Image Build: as the next step, it would really help
 >> developers if we could build their images (e.g. myuser/mywebapp),
 >> register them, and then deploy them via atomic app as one command.  This
 >> would mean that users would just provide a tree file and a set of source
 >> code repos (with dockerfiles) and one command would do the rest.
 >
 > +1 - I've thought about this myself. Basically we specify a git
 > repo where the Dockerfile + context directory live as part of the
 > Nulecule. Atomic App doesn't have to be the tool that is capable of
 > interpreting this information and doing the build, but being able to
 > specify it in the spec is interesting.
 >
 > Atomic App probably could pull off the "build" part in the case of a
 > local kubernetes or basic docker provider but in cases where you have
 > to push to a registry it might get more complicated.
 >
 > Either way.. having the ability to take a Nulecule and not "rely" on
 > any images being built and basically putting it in the oven and
 > building everything to completion and then running would be
 > attractive. It would also make it easier to confirm that the source
 > bits that exist out there still work and haven't rotted in some way.

It would also provide a justification to the developer as to why it's 
worth doing all of this config stuff to create the Nulecule in the first 
place.  They're only going to do that if it saves them work overall.

Howver, see Bex's comments above.


-- 
--
Josh Berkus
Project Atomic
Red Hat OSAS