On Tue, Mar 8, 2016 at 6:20 AM, Tomas Kral <tk...@redhat.com> wrote: > > > On 03/08/2016 12:36 AM, Dusty Mabe wrote: > > > > We met earlier today to discuss the readiness of the Nulecule spec. This > was > > brought about because we were in motion to release a 1.0.0 release of > Atomic App > > because we have been in feature freeze/test mode for a while. > > > > Here are some important notes from the meeting: > > - We have thusly concentrated on the deployment story and not enough on > the > > developer story. We need to take a new look at the spec from a > developer point > > of view. > > - We would like to have more "users" attempt to create Apps so we can > fully vet > > Atomic App and Nulecule Spec before we approach 1.0.0 status. > > - We realize that soon we will need to make sure that we support (for > some time) > > the existing Nulecule spec version that Atomic App supports. We have a > short > > amount of time before that to change the spec, but even after that > point we have > > freedom to change the spec as long as we support backwards compat. > > - Development of Atomic App isn't tied to the ADB/CDK because Atomic App > isn't > > baked into the ADB and is delivered via a registry. So we may be more > free to > > iterate faster than previously thought. > > > > Conclusions: > > - We will leave the current versioning scheme in place for now; continue > on with > > 0.4.x, 0.5.x and so on.. Before we make any large changes to > versioning we > > should also discuss with marketing to make sure we have a good message. > > - For the time being we will go back to heavy/fundamental development > instead of > > just bug-fixing so we can attempt to address the issues with the spec > and with > > the developer story. > > > > Open Questions: > > - Do we need to continue to be generic and support all providers or > should we tailor > > our solution to Kubernetes/OpenShift? > > I can see benefits of tailoring our solution to Kubernetes/OpenShift. > But I'm also afraid that in this case we might end up with something > only slightly different than OpenShift templates. >
I agree on both counts. So how can we add value without duplication? Here are some suggestions: *Packaging*: this has yet to catch on. Have we considered playing with the S2I pattern and create a "packaging service" hosted on openshift? We need to somehow make this compelling and automated. *Parameterization*: currently we ask the developer to choose which params to expose during deployment. How can they choose? The dev doesn't actually know the extent to which ops might want to customize the deployment. Ops makes that determination. Shouldn't we allow ops to override ANY param and enable/disable objects (services)? This would be in keeping with our high-level view of the app and yet provide the flexibility ops should have. It should also provide a "snapshot" of a deployment that can be duplicated. *Portability:* The user is on a platform that they've chosen (or at least try out). They are going to use the artifacts (templates, etc) and deployment methods that the platform requires. Isn't our role just helping them distribute these artifacts between environments? As an ISV I want to give the end-user the artifacts they need to deploy. As a dev I want my (automated) build environment to hand off to the ops team. > > > > > > _______________________________________________ > > Container-tools mailing list > > Container-tools@redhat.com > > https://www.redhat.com/mailman/listinfo/container-tools > > > > _______________________________________________ > Container-tools mailing list > Container-tools@redhat.com > https://www.redhat.com/mailman/listinfo/container-tools >
_______________________________________________ Container-tools mailing list Container-tools@redhat.com https://www.redhat.com/mailman/listinfo/container-tools
