On 03/01/2016 11:01 PM, Josh Berkus wrote:
Folks,
So as of 1.0, we will have an excellent packager format for
Atomic/Nulecule apps and the Atomic platform. However, what we will not
have is a tool which makes it easier for developers to package their
applications. I think that's something we can do, but we'll need to
build 2.0 to do it. The goal is to have an atomic.app which saves
developers work, so that they *want* to use it.
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.
Here's the main areas I can see where we can make atomic.app better for
developers in priority order:
1. File Generation: right now atomic.app requires typing out/copying
multiple files in multiple locations, most of which are duplicative of
standard templates or each other. Really, we should be able to take
just a tree file alone from the user and generate all of the other
files, except in the "advanced" cases. All of the other files are
derivative of that tree file and 3rd-party APIs.
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.
2. Security and Permissions: we need a way for developers to be able to
use their chosen tools on their desktop, but still use atomic.app to
build apps (see prior email). As a bonus, we could offer the ability to
set SELinux permission requirements as part of the atomic.app format;
that would not only make atomic.app valuable, it would ease the tendency
of developers to just disable SELinux.
One thing we need here for the ADB is the ability to enter the atomicapp
workflow from the desktop ...
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?
regards,
bex
_______________________________________________
Container-tools mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/container-tools
