[EPIC] New spec!

[cdrage]

So.. There's been quite a discussion on how we can improve the spec of Nulecule.

Not only removing the problems with the high learning-curve of Nulecule but also to make it a lot easier to use and understand intuitively without having to consult the documentation every second line.

We are ideally looking at universal format for Atomic App where not only is it simple to use but also simple to understand right-off-the-bat.

Personally, I learn by example, and here, I've created an example file for what a new Nulecule may look like with all the bells-and-whistles of a new spec.

There are some MAJOR changes which would majorly change the landscape of Nulecule, but these changes I believe will make Nulecule what we envisioned it to be.

I've made this as a pull-request for discussion so we can easily comment line-by-line on each part of the "example" and cultivate a new spec (and look!) for Nulecule.

P.S. Please be kind as I may have not encompassed / implemented everything that's suppose to be in it yet.

[rtnpro]

@cdrage :+1: for kicking off the discussions.

[surajssd]

@cdrage if I write a single Nulecule.yaml does that mean I don't have to write any other configuration file?

[cdrage]

@surajssd Bit confused what you mean, sorry :stuck_out_tongue: This is a spec re-write, just ignore the Nulecule.yaml file name. I'm not proposing any changes to removing /artifact folder, Dockerfile, etc.

[surajssd]

@cdrage with this new spec I only have to write a single Nulecule file and Atomic App will read my Nulecule file and auto-generate the Kubernetes and OpenShift artifacts? or will it be like the current workflow where I write Nulecule and Kubernetes artifacts both?

[cdrage]

Ah yes. With this new spec (if people like the auto build idea) you would not need to write any kubernetes/openshift/mesosphere specific artifact files. Same for Docker too. Although I made this PR so we can figure out how we can structure it for all providers. (In my opinion, similar to docker-compose, or maybe the same, but with extra params such as replicas, etc, added)

[surajssd]

@cdrage nice job! I like the auto-building idea.

[concaf]

@cdrage, also, if my Nulecule file looks something like this, then as a user I do not have to worry about missed whitespaces or unclosed brackets in yaml/json.

<wordpress>

provider = kubernetes

name = mariadb-centos7-atomicapp
source = projectatomic/mariadb-centos7-atomicapp

name = wordpress
image = wordpress
params = db_user , db_pass, db_host = 127.0.0.1, port = 8080

</wordpress>

Maybe we can accept multiple formats as input, so besides yaml/json, how about .ini and others with which a user is much more familiar with?

[cdrage]

@containscafeine answers.conf is in ini, maybe it won't be that hard to add it to Nulecule too.

[goern]

@cdrage cool stuff, feels like someone picked up the 'auto generate idea' again, even though it is not part of the spec itself but a feature of Atomic App.

Restructuring the Spec is a good idea, I always emphasized that the spec is super open and we can put in anything we want as an experiment and use Atomic App to implement that experimental extensions to the spec.

As a first shot I would see the provider section you have proposed, should we extract that out into a sep change and get that in fast?

[cdrage]

@goern the provider section does sound good and would be a good place to start in order to emphasize the portability of nulecule. esp. since it's a new section and won't break anything previously.

Although unfortunately my experience with encrpytion isn't that good so we would need someone who knows they're stuff on how to encrypt the secrets on build so none of that information is leaked when the portable container is passed around.

in regards to the other sections removing "graph" and adding the whole app-name-as-an-object idea (see the example) we can further discuss that and add it too.

[aweiteka]

Could someone respond to how this might relate to helm/deployment manager? How is the kubernetes community developing around that initiative? What is the overlap? Is there opportunity here?

[cdrage]

Revision two!

I've made a revision two of the proposed changes adapted from the comments of this PR as well as another suggestion I've put in.

At the moment, a Nuleculized container contains: /artifacts folder with multiple /artifacts/kubernetes/pod etc. folders. We also include Nulecule, Dockerfile and README.md.

I've proposed including the artifact files within the Nulecule itself. This make clarity a lot easier for the user, as well as simplifies portability. This means that the only thing that a developer needs is the Nulecule file and that's it. Provider credentials are encrypted. Artifact folders are included.

They can pick whatever implmentation tool they wish, whether it be atomicapp in Python or atomicapp-go in Go, use the Nulecule file and :tada: !

I've converted two examples: etherpad and helloapache from our nulecule-library as examples using this new spec.

etherpad example includes ALL changes I propose for the spec and is in all intensive purposes a full example.

helloapache is a simplified example to showcase the clarity of the spec.

P.S. I've left out the 'automated' idea for now.. I'm going to think this over and re-visit this later after further discussion with contributors.

[surajssd]

Single file with all the artifacts will be easier to write only if its minimal, with all the bells and whistles its becoming more complicated than it is!

[cdrage]

@rtnpro @surajssd @vpavlin @goern @dustymabe @aweiteka

I slightly updated the Nulecule spec with this PR. Could I possibly get another review / thoughts then we could move forward into integrating it and then integrating into Atomic App? :)

[bexelbie]

It'd be great to get a minimal example that stripped out everything that was optional. This could also show what auto-generation might look like from a config perspective.

[cdrage]

@bexelbie i did this with the helloapache example on this PR

[bexelbie]

@cdrage that example still felt heavier than I expected. I was thinking provider would be completely absent ...

[cdrage]

@bexelbie The artifacts of the:

provider:
  default: kubernetes

?

[bexelbie]

@cdrage

  provider: 

    # Pipe in the command (pref if it's short)
    docker:
      - run: | 
        docker run -d -p $hostport:80 $image
    # Grab from the artifact folder
    kubernetes:
      - pod: file://artifacts/kubernetes/pod.yaml

    # Grab from https
    marathon:
      - container: https://github.com/cdrage/marathon-examples/helloapache/container.json

    openshift:
      inherit: kubernetes

[cdrage]

@bexelbie We will still be keeping that, no auto-generation with Nulecule. That'll be something separate.

Focusing on packaging + deployment.

From what I've been told / gathered from all the meetings, we're going to still keep the artifact inclusion / using file://, etc.

[cdrage]

I'm going to close this and re-open this in submitted segments.

I've already tried with the inclusion of using an app-name instead of graph and that PR was closed / linked to the previous issue as to why it did not work.

I'll create a new PR to possibly integrate the provider section.