[EPIC] New spec! #205

cdrage · 2016-04-13T16:42:03Z

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.

smarterclayton · 2016-04-13T17:00:37Z

Nulecule.yaml

+# We will also figure out a way to interpolate with manual and automatic generation. For ex. params such as ports can be converted to default answers.conf params when built. This will be the hard part.
+
+# Redis EXAMPLE
+redis:


Please don't invent a new API syntax here for Kube objects - that's not a nulecule only direction and needs to be done in concert with APIs in OpenShift and Kubernetes.

I was thinking of either going the pure 100% kubernetes/openshift API route (since most people would be using Nulecule/Atomic App with those providers).

Or a universal standard route but interpreted for Kubernetes (for ex. https://github.com/skippbox/kompose).

I went with the later as the problem is solving the high-learning curve of creating kubernetes rc, svc, pods, etc, so using a simpler syntax may be more ideal where the syntax is converted to their respective kubernetes/openshift/marathon/possibly nomad/etc. files

Another reason being is that ideally, if the user already knows what goes on in the kubernetes/openshift artifact files, they'd be choosing the manual route. Using the automatic generation would create standard containers (for example, a redis master/slave) using a much simpler context.

We've discussed this pretty frequently in other contexts but we are not going to create a simpler syntax for Kube resources without creating a new Kube or OpenShift API object - all transformation introduces gaps in abstraction, and if it's an important abstraction it would be a product abstraction.

Conversion from compose -> Kube or OpenShift is valuable and important, but shouldn't be done by nulecule without explicit support from those projects.

@smarterclayton do you suggest creating a converter like compose -> Kube rather than changing the Nulecule spec itself?

I think @smarterclayton is absolutely right - we do need to investigate simpler formats for kube, but we need to do that in the kubernetes ecosystem (i.e. in kubernetes) not in a third party tool.

We also need X -> kuber converters, but I'm not sure they would/should involve nulecule at all.

We've discussed this pretty frequently in other contexts but we are not going to create a simpler syntax for Kube resources without creating a new Kube or OpenShift API object - all transformation introduces gaps in abstraction, and if it's an important abstraction it would be a product abstraction.

@smarterclayton is there a tracker for this? This might be something we can help design and/or help build when the time comes.

I'm not convinced that Nulecule is the right place to specify this, as it's primary focus is on allowing different container orchestration systems to work together, which I think is a different focus that allowing a developer to simply specify how their service should work on their local development machine. I do think a better approach here is to work with the OpenShift team and the Kubernetes team to help improve Kubernetes for this use case.

Just wanted to note that this was just an experiment / suggestion and there's no promises that it'll be in Nulecule. I just found the idea of auto-generating artifacts for each perspective provider a good way to ease a user into further deploying their containers on an orchestrator.

One suggestion to @smarterclayton 's comments is using the kubernetes api syntax as he said, directly in Nulecule and convert it for any future providers that we want to implement. For example, we would add a k8s syntax -> Marathon converter, k8s syntax -> Nomad, etc. Makes it so that the user only has to learn one api (in this case k8s).

Nulecule will extract the appropriate information in the syntax (for ex. nodeport: 80, labe: foo) and convert it to a param as per the Nulecule spec for usage in portable containers.

rtnpro · 2016-04-13T17:07:31Z

@cdrage 👍 for kicking off the discussions.

surajssd · 2016-04-13T17:15:21Z

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

cdrage · 2016-04-13T17:17:51Z

@surajssd Bit confused what you mean, sorry 😛 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 · 2016-04-13T17:26:15Z

@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?

concaf · 2016-04-13T17:40:20Z

Nulecule.yaml

+  name: Hello World
+  id: helloworld
+  appversion: 0.0.1
+  spec: 1.0.0


Hi @cdrage, does the user need to write the spec version in each Nulecule file? In fact, most of the things in metadata.
Can it be something like, we set all the sensible default values for each field, such that if the user specifies the fields in his/her Nulecule, those will be overridden, but even if he does not, it's fine, the defaults are already set!

yeah, you're right, spec is still needed.

@cdrage and by defaults I mean that if my Nulecule is as minimal as the following, that should be fine. We can have defaults for everything set and just deploy it, if the user is not specifying anything.

<wordpress> provider = kubernetes name = mariadb-centos7-atomicapp source = projectatomic/mariadb-centos7-atomicapp name = wordpress image = wordpress </wordpress>

cdrage · 2016-04-13T17:43:03Z

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 · 2016-04-13T17:44:14Z

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

surajssd · 2016-04-13T17:45:03Z

Nulecule.yaml

+    openshift:
+      - file://artifacts/openshift/etherpad-rc.yaml
+      - file://artifacts/openshift/etherpad-svc.yaml
+


If auto-generating is gonna be a real thing then I think this is not necessary?

See comments above, you specify build: manual or build: auto. Like mentioned in the comments, manual is ideal for people who want to do it manually and not have atomic app interpret it.

okay so we give choice to user as to what they want, people will surely choose auto for everything, at-least for starters.

@cdrage IMO auto example should be here. We are to see how easy Nulecule can become

concaf · 2016-04-13T18:15:28Z

@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 · 2016-04-13T18:18:09Z

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

goern · 2016-04-13T19:54:00Z

@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 · 2016-04-13T20:05:41Z

@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.

LalatenduMohanty · 2016-04-13T21:03:57Z

Nulecule.yaml

+  # Other possible providers:
+  # source: rkt://projectatomic/mariadb:latest
+  # source: file://foo/bar/container
+  # source: https://localhost/container.tar.gz


aweiteka · 2016-04-13T21:24:01Z

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?

dharmit · 2016-04-14T09:20:16Z

Nulecule.yaml

+  params: 
+    image:
+      description: Container image
+      default: centos/etherpad


Probably shooting in the dark but, instead of

params: image: description: Container image default: centos/etherpad

is it possible to have something simple like

image: centos/etherpad

The only problem is if we require to ask the user for a value :( for ex. if image is blank.

image: centos/etherpad - default: test

Which I don't think is valid ^^

vs

image: description: foobar default: test value: test

cdrage · 2016-04-14T17:59:24Z

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 🎉 !

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.

vpavlin · 2016-04-16T07:01:39Z

examples/helloapache/Nulecule.yaml

+  spec: 1.0.0
+  description: Hello world!
+
+provider:


I find the use of the key provider multiple times quite unfortunate. Wouldn't it make sense to rename this to something like provider_config?

If we do provider-config we could eliminate having to have provider-token to token, etc.

surajssd · 2016-04-18T10:38:02Z

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!

concaf · 2016-04-18T10:47:19Z

examples/etherpad/Nulecule.yaml

+                    - name: DB_PORT
+                      value: '3306'
+                    - name: DB_USER
+                      value: $db_user


@cdrage this is reaching 4-5 levels of indentation deep after including other providers' artifacts in the same file, will it not be a bit difficult to write? I liked the previous idea of having a single definition at one place and parsing it and deploying everywhere. Are we not doing that anymore?

Yeah! It's just piping in the file. The example I used had the artifacts as .yaml so that's why it looks messy. Have a look at the helloapache example below :)

cdrage · 2016-05-16T18:35:15Z

@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 · 2016-05-18T15:03:35Z

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 · 2016-05-18T15:33:10Z

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

bexelbie · 2016-05-19T09:12:33Z

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

cdrage · 2016-05-19T11:59:15Z

@bexelbie The artifacts of the:

provider:
  default: kubernetes

?

bexelbie · 2016-05-19T12:18:10Z

@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 · 2016-05-19T12:20:26Z

@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 · 2016-06-15T13:58:03Z

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.

New spec

b756bdb

cdrage force-pushed the new-spec branch from 254dec4 to b756bdb Compare April 13, 2016 16:42

smarterclayton reviewed Apr 13, 2016
View reviewed changes

concaf reviewed Apr 13, 2016
View reviewed changes

surajssd reviewed Apr 13, 2016
View reviewed changes

LalatenduMohanty reviewed Apr 13, 2016
View reviewed changes

dharmit reviewed Apr 14, 2016
View reviewed changes

cdrage force-pushed the new-spec branch from 0d2e8fd to 224e4cf Compare April 14, 2016 18:13

vpavlin reviewed Apr 16, 2016
View reviewed changes

concaf reviewed Apr 18, 2016
View reviewed changes

cdrage force-pushed the new-spec branch 2 times, most recently from e238d4c to 4a4669e Compare May 12, 2016 16:21

Revision 2

d9ae6e7

cdrage force-pushed the new-spec branch from 4a4669e to d9ae6e7 Compare May 16, 2016 18:34

cdrage closed this Jun 15, 2016

[EPIC] New spec! #205

[EPIC] New spec! #205

Conversation

cdrage commented Apr 13, 2016

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

rtnpro commented Apr 13, 2016

surajssd commented Apr 13, 2016

cdrage commented Apr 13, 2016

surajssd commented Apr 13, 2016

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

cdrage commented Apr 13, 2016

surajssd commented Apr 13, 2016

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

concaf commented Apr 13, 2016

cdrage commented Apr 13, 2016

goern commented Apr 13, 2016

cdrage commented Apr 13, 2016

Choose a reason for hiding this comment

aweiteka commented Apr 13, 2016

Choose a reason for hiding this comment

Choose a reason for hiding this comment

cdrage commented Apr 14, 2016

Revision two!

Choose a reason for hiding this comment

cdrage Apr 18, 2016 • edited Loading

Choose a reason for hiding this comment

surajssd commented Apr 18, 2016

concaf Apr 18, 2016 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

cdrage commented May 16, 2016

bexelbie commented May 18, 2016

cdrage commented May 18, 2016

bexelbie commented May 19, 2016

cdrage commented May 19, 2016

bexelbie commented May 19, 2016

cdrage commented May 19, 2016

cdrage commented Jun 15, 2016

cdrage Apr 18, 2016 •

edited

Loading

concaf Apr 18, 2016 •

edited

Loading