[Container-tools] Rethinking Nulecule

[William Henry]

I still need to understand how Ansible effects the Nulecule efforts. I
understood people are looking into this. Is that happening?

It seems to me that there is potentially lots of overlap here. Who
from Ansible, if any, is working with the Nulecule folks to make sure
we aren't reinventing and re-implementing and making the best use of
an already very vibrant community? Particularly on the provider side
where Ansible has modules and playbooks to work with a variety of
providers.

William

William Henry
Senior Consulting Software Engineer
Red Hat, DevOps Strategy, Cloud Product Strategy
Colorado, USA.
GoogleVoice: +1 719 357-5446


On Thu, Mar 10, 2016 at 7:45 AM, Aaron Weitekamp <aweiteka at redhat.com> wrote:
> On Thu, Mar 10, 2016 at 4:29 AM, Ratnadeep Debnath <rtnpro at gmail.com> 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.
>
>
> I disagree that we can shoulder the burden of making openshift or kubernetes
> or anything else easier to use. We haven't been successful making our own
> tooling easy to use and adopt. The platform has to do this work.
>
>>
>> - 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
>> Container-tools at redhat.com
>> https://www.redhat.com/mailman/listinfo/container-tools
>
>
>
> _______________________________________________
> Container-tools mailing list
> Container-tools at redhat.com
> https://www.redhat.com/mailman/listinfo/container-tools
>