On Thu, Mar 10, 2016 at 7:18 AM, Burr Sutter <[email protected]> wrote:
> I like the proposal! :-) > > I agree we should encourage adoption, zero barriers, etc, but I think we should go in the other ​direction with the spec: - focus on the high-level definition of the application and service discovery, e.g. I want to deploy and connect 2 services - we push artifact generation AND parameterization[1] AND application lifecycle down to the platform, e.g. kubernetes and openshift. With this approach we add value to the platform without duplicating. We stop chasing low-level platform artifact/api changes. We help people compose and distribute applications. [1] by parameterization I mean the platform should have its own mechanism for parameterization that we simply hook into. > On Thursday, March 10, 2016, Ratnadeep Debnath <[email protected]> wrote: > >> Hi all, >> >> Till now, Nulecule's focus has been to be a spec to package and ship >> nested, composable multi container applications. Well, it helps us to >> focus on a smaller problem and solve it well. This also keeps >> implementation of Nulecule, e.g., atomicapp, lean and simple. >> >> However, is it enough? >> >> >> I will try to highlight a few shortcomings of the current Nulecule spec: >> >> - the spec file does not fully describe the architecture of the >> applications >> - it's difficult to get started with Nulecule as it requires knowledge >> of underlying providers >> - it's not possible to use the same Nulecule spec to deploy a Nulecule >> application across providers without writing artifacts for each >> provider >> >> >> So, we are thinking in the lines of extending Nulecule SPEC to >> describe a multi container application completely in the SPEC file, >> similar to Docker compose file. This will enable us to: >> >> - to automatically generate artifact files for underlying providers >> from the SPEC file >> - to override the generated artifact files, if needed >> >> >> The advantages of such a change would be: >> >> - zero barrier entry for developers >> - package once, in one language, and deploy anywhere >> >> >> This move will be beneficial to: >> >> - developers, with little knowledge about openshift, k8s, marathon, etc. >> - ISVs to package apps to run across multiple providers >> - switch seamlessly to another provider >> >> >> We're keen to hear your feedback on the above proposed changes. Will >> this help to make Nulecule more awesome and user friendly? Let us know >> what you think. >> >> >> Thanks, >> rtnpro >> -- >> Ratnadeep Debnath, >> https://www.waartaa.com >> GPG Fingerprint: 033C 8041 A0E9 CDBA 2E02 B785 2119 5486 F245 DFD6 >> >> _______________________________________________ >> Container-tools mailing list >> [email protected] >> https://www.redhat.com/mailman/listinfo/container-tools >> > > _______________________________________________ > Container-tools mailing list > [email protected] > https://www.redhat.com/mailman/listinfo/container-tools > >
_______________________________________________ Container-tools mailing list [email protected] https://www.redhat.com/mailman/listinfo/container-tools
