I think what you're doing is super neat, but I'm curious to hear in more detail about your complaints with Jsonnet. I find it to be quite elegant, myself. (Though, as you know, I'm quite biased at this point.)
On Thursday, September 28, 2017 at 2:49:52 AM UTC-7, Mahieddine Cherif wrote: > Hi Keith > ksonnet like you already know is just a bunch of generated mixins on top of > jsonnet, this makes its templates hard to read and write, moreover the design > choices made for jsonnet didn't attract us. I mean we all know what happens > when you put a programming language inside a configuration file. > > > This is why we created ICL (https://github.com/archipaorg/icl), it's a > declarative configuration language inspired from nginx config file syntax and > written primarily for docker orchestrators' YAML file, it has the concept of > inheritance, class, mixins and libraries. > > > This is what it looks like if i write my "hello world app" manifest file in > ICL for k8s: > > > > > take github.com/k8s-icl/latest/v1beta1/deployment, > github.com/k8s-icl/latest/v1/containerport, > github.com/k8s-icl/latest/v1/container > > ::variable "container-port" apply ContainerPort @@name="nginx", > @@containerPort="8080" > ::variable "container-ports" [variable.container-port] > ::variable "container" apply Container @@image="nginx:1.13.0", > @@name="nginx", @@ports=variable.container-ports > ::variable "container-list" [variable.container] > ::variable "pod-spec" apply PodSpec @@containers=variable.container-list > ::variable "labels" table "app" = "nginx" > ::variable "pod-metadata" apply ObjectMeta @@labels=variable.labels > ::variable "template" apply PodTemplateSpec @@spec=variable.pod-spec, > @@metadata=variable.pod-metadata > ::variable "spec" apply DeploymentSpec @@replicas=5, > @@template=variable.template > ::variable "metadata" apply ObjectMeta @@name = "nginx" > > _ "_" apply Deployment @@metadata=variable.metadata, @@spec=variable.spec > > > Of course i could wrote a mixin to shorten the creation of a specific section > in my case, but the point is that even if no one knows what ICL is, everyone > can read and understand what's happening here.  > > > How does it compare to other approaches ? ICL is a JSON/YAML extension, it > has some OO concepts such as inheritance (multiple inheritance actually), > mixins, and class, but remember ICL's purpose is to make config files > modular, and easy to read. so there are no conditional, loop...instructions. > the point is that when a developer checks a config file he must be able to > see what he gets. > > > e.g. (:: in ICL means its a settings block library => no rendered) > > > > > > ::vegetable "fruit" as Fruit { > type = "fruit" > } > > ::color "green" as Green { > name = "apple" > } > > apple "green" from Fruit, Green { > > } > > > Output in YAML => > apple: > green: > name: apple > type: fruit > > > Whatever you write in JSON/YAML can be written in ICL and vice-versa. > > > > Hope it's clear for you > > > Regards, > Mahieddine > > On Thursday, September 28, 2017 at 10:15:23 AM UTC+2, Keith Burdis wrote:How > does this compare to ksonnet [1]? This is based on jsonnet [2] which has a > good comparison [3] with other approaches. > [1] http://ksonnet.heptio.com > [2] http://jsonnet.org > [3] http://jsonnet.org/language/comparisons.html -- You received this message because you are subscribed to the Google Groups "Kubernetes user discussion and Q&A" group. To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-users+unsubscr...@googlegroups.com. To post to this group, send email to kubernetes-users@googlegroups.com. Visit this group at https://groups.google.com/group/kubernetes-users. For more options, visit https://groups.google.com/d/optout.
