{"action":"closed","issue":{"url":"https://api.github.com/repos/fabric8io/fabric8/issues/5861","repository_url":"https://api.github.com/repos/fabric8io/fabric8","labels_url":"https://api.github.com/repos/fabric8io/fabric8/issues/5861/labels{/name}","comments_url":"https://api.github.com/repos/fabric8io/fabric8/issues/5861/comments","events_url":"https://api.github.com/repos/fabric8io/fabric8/issues/5861/events","html_url":"https://github.com/fabric8io/fabric8/issues/5861","id":142148525,"number":5861,"title":"alternative approach to generating JSON / YAML kubernetes resources","user":{"login":"jstrachan","id":30140,"avatar_url":"https://avatars.githubusercontent.com/u/30140?v=3","gravatar_id":"","url":"https://api.github.com/users/jstrachan","html_url":"https://github.com/jstrachan","followers_url":"https://api.github.com/users/jstrachan/followers","following_url":"https://api.github.com/users/jstrachan/following{/other_user}","gists_url":"https://api.github.com/users/jstrachan/gists{/gist_id}","starred_url":"https://api.github.com/users/jstrachan/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/jstrachan/subscriptions","organizations_url":"https://api.github.com/users/jstrachan/orgs","repos_url":"https://api.github.com/users/jstrachan/repos","events_url":"https://api.github.com/users/jstrachan/events{/privacy}","received_events_url":"https://api.github.com/users/jstrachan/received_events","type":"User","site_admin":false},"labels":[{"url":"https://api.github.com/repos/fabric8io/fabric8/labels/CD%20(Continuous%20Delivery)","name":"CD (Continuous Delivery)","color":"fbca04"},{"url":"https://api.github.com/repos/fabric8io/fabric8/labels/kubernetes","name":"kubernetes","color":"fbca04"},{"url":"https://api.github.com/repos/fabric8io/fabric8/labels/maven","name":"maven","color":"006b75"}],"state":"closed","locked":false,"assignee":null,"milestone":null,"comments":24,"created_at":"2016-03-20T10:26:40Z","updated_at":"2016-06-13T12:11:52Z","closed_at":"2016-06-13T12:11:52Z","body":"the current maven properties approach is a little bit cryptic & hard to tool. Its also totally maven centric - we need a more polyglot / poly-build-tool approach. I wonder if we can come up with a simpler to understand and easier to tool approach that can work for many languages? \r\n\r\nThe original main motivation was all the labels + selectors were error prone and we wanted to do a better job of adding smart defaults - and adding extra labels/annotations etc.\r\n\r\nHow about this as a strawman...\r\n\r\n* folks can create yaml/json files (yaml are probably easier for humans to write?) in `src/main/kubernetes` (different build systems / languages can use a different folder if they prefer).\r\n* folks can define very minimal contents in there. e.g. for an RC it could be this file `src/main/kubernetes/rc.yml`...\r\n\r\n```\r\n---\r\napiVersion: \"v1\"\r\nkind: \"ReplicationController\"\r\nmetadata:\r\n  name: \"foo\"\r\n  labels:\r\n    project: \"whatnot\"\r\n    version: \"${project.version}\"\r\n  annotations:\r\nspec:\r\n  template:\r\n    spec:\r\n      containers:\r\n      - image:  \"foo/bar:${project.version}\"\r\n```\r\n\r\nmostly its gonna require the image name really and the kind; everything else could be ommitted. e.g. we could default\r\n* the name\r\n* the labels\r\n* the labels can be replicated on an RC for the selector and pod templatess labels\r\n\r\ne.g. it could be this simple:\r\n```\r\n---\r\napiVersion: \"v1\"\r\nkind: \"ReplicationController\"\r\nmetadata:\r\n  labels:\r\n  annotations:\r\nspec:\r\n  template:\r\n    spec:\r\n      containers:\r\n      - image:  \"foo/bar:${project.version}\"\r\n```\r\n\r\nThen there's a natural place for folks to add labels / annotations as they require - or add any k8s stuff needed. \r\n\r\nThe same can be true of other resources like services. e.g. `src/main/kubernetes/service-http.yml` could be:\r\n\r\n```\r\n---\r\napiVersion: \"v1\"\r\nkind: \"Service\"\r\nspec:\r\n  ports:\r\n  - port: 80\r\n    targetPort: 8080\r\n  type: \"LoadBalancer\"\r\n```\r\n\r\nagain we can default the name, labels, selector of the resource along with the port name & protocol by default.\r\n\r\nWe can then add all the other generated annotations we add like icons, git commit, git URL, CI job and all that jazz too.\r\n\r\nThe basic idea is to have small simple YML files that users edit; with minimal required OOTB data to type. Most stuff can be generated (labels and whatnot) from project metadata. At any time folks can be specific in the files (e.g. add the exact labels required - possibly with variable filtering to refer to maven versions and stuff)- which then overrides the OOTB generated values. Then we can replicate labels in RCs / Services to selectors + pod template labels if they are not supplied.\r\n\r\ni.e. a convention over configuration approach; but the data folks type is actually put into the real YML file - so one day we could have a nice IDE / UI for editing it with validation / completion etc.\r\n\r\n\r\nWe'd need to also support generating OpenShift Templates. I do wonder if we'll just move to vanilla k8s resources and ConfigMap really though. But we should maybe allow a `src/main/kubernetes/template.yml` to be generated containing all the parameter definitions and default values (in which case all the other resources would be put inside the Template I guess).\r\n\r\nThoughts?"}}
{"actor":{"display_login":"jstrachan"}}