{"action":"created","issue":{"url":"https://api.github.com/repos/kubernetes/kubernetes/issues/23174","repository_url":"https://api.github.com/repos/kubernetes/kubernetes","labels_url":"https://api.github.com/repos/kubernetes/kubernetes/issues/23174/labels{/name}","comments_url":"https://api.github.com/repos/kubernetes/kubernetes/issues/23174/comments","events_url":"https://api.github.com/repos/kubernetes/kubernetes/issues/23174/events","html_url":"https://github.com/kubernetes/kubernetes/issues/23174","id":141756271,"number":23174,"title":"implement salt v2 (a.k.a. ansible) kube-up","user":{"login":"mikedanese","id":1787169,"avatar_url":"https://avatars.githubusercontent.com/u/1787169?v=3","gravatar_id":"","url":"https://api.github.com/users/mikedanese","html_url":"https://github.com/mikedanese","followers_url":"https://api.github.com/users/mikedanese/followers","following_url":"https://api.github.com/users/mikedanese/following{/other_user}","gists_url":"https://api.github.com/users/mikedanese/gists{/gist_id}","starred_url":"https://api.github.com/users/mikedanese/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/mikedanese/subscriptions","organizations_url":"https://api.github.com/users/mikedanese/orgs","repos_url":"https://api.github.com/users/mikedanese/repos","events_url":"https://api.github.com/users/mikedanese/events{/privacy}","received_events_url":"https://api.github.com/users/mikedanese/received_events","type":"User","site_admin":false},"labels":[{"url":"https://api.github.com/repos/kubernetes/kubernetes/labels/area/cluster-lifecycle","name":"area/cluster-lifecycle","color":"d4c5f9"},{"url":"https://api.github.com/repos/kubernetes/kubernetes/labels/team/node","name":"team/node","color":"d2b48c"}],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":23,"created_at":"2016-03-18T02:28:49Z","updated_at":"2016-05-04T15:08:21Z","closed_at":null,"body":"It's time to declare bankruptcy on `cluster/salt/`. It served us dutifully but has grown to be unmaintainable. Let's learn form our experience and start building v2.\r\n\r\nSome possible improvements I would like to see:\r\n* use ansible, the technology the community settled on\r\n* installation artifact of kubernetes should be packaged in docker. installation step should be `docker run install-k8s [node|master]`.\r\n* installation should be able to run over ssh or a chroot. ansible supports this.\r\n* as little as possible should be installed on hosts\r\n* (eventually) reduce configuration bits by implementing kubelet boostrap #23172\r\n* kubelet should be the only init unit that we install\r\n* use systemd in place of supervisord\r\n* kubelet is the only thing on the host but will eventually run in a container as well.\r\n* installation artifact, which is sperate from release artifact, should only package kubelet (until kubelet is run in a container) and various ansible config files. everything else should be pulled from an external docker registry.\r\n* run kube-proxy and fluentd as a static pod\r\n* less shell to format yaml\r\n* less shell in general\r\n* less jinja (especially to format json)\r\n* deploy kube-proxy and fluentd in daemonsets as addons\r\n* network plugins that require node agents should also run as daemonsets (depends on #20355)\r\n\r\nPlease let me know if you think I missed something or if you don't think we should do something on this list.\r\n\r\nOpen questions:\r\n* do we need a migration plan for current salt or wheter we should start fresh with a new kube-up, bring it up to speed, then deprecate the old?\r\n* do we require python on the host? do we require anything else?\r\n* how do we best reconcile v2 with the [cluster deployment](https://github.com/kubernetes/kubernetes/blob/master/docs/proposals/cluster-deployment.md) proposal?\r\n\r\nI will try to better formulate a plan of action with explicit steps and goals in the next couple of days.\r\n\r\ncc @davidopp @justinsb @fgrzadkowski @roberthbailey "},"comment":{"url":"https://api.github.com/repos/kubernetes/kubernetes/issues/comments/216895274","html_url":"https://github.com/kubernetes/kubernetes/issues/23174#issuecomment-216895274","issue_url":"https://api.github.com/repos/kubernetes/kubernetes/issues/23174","id":216895274,"user":{"login":"justinsb","id":100893,"avatar_url":"https://avatars.githubusercontent.com/u/100893?v=3","gravatar_id":"","url":"https://api.github.com/users/justinsb","html_url":"https://github.com/justinsb","followers_url":"https://api.github.com/users/justinsb/followers","following_url":"https://api.github.com/users/justinsb/following{/other_user}","gists_url":"https://api.github.com/users/justinsb/gists{/gist_id}","starred_url":"https://api.github.com/users/justinsb/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/justinsb/subscriptions","organizations_url":"https://api.github.com/users/justinsb/orgs","repos_url":"https://api.github.com/users/justinsb/repos","events_url":"https://api.github.com/users/justinsb/events{/privacy}","received_events_url":"https://api.github.com/users/justinsb/received_events","type":"User","site_admin":false},"created_at":"2016-05-04T15:08:21Z","updated_at":"2016-05-04T15:08:21Z","body":"@wstrange I would say no for the case which is most problematic for us; we define once how the canonical configuration maps to the various tools, but then as we change the canonical configuration we don't need to update each of the configurations (or change the mappings).\r\n\r\nHowever, if we define a new attribute, then yes, we would need to update the conversion to each of the tools.\r\n\r\nAs an example:\r\n\r\n*  for HA master we will likely put the master into an ASG on AWS/MIG on GCE.  We already have the mappings to the various tools defined, because we already use ASGs and MIGs for the nodes.  So we just update our canonical configuration, and we don't have to do anything for the generated configurations.\r\n* as an example of where we would have to update the mappings: if we decide to enable spot instances on AWS then yes, we would have to define a new field in the canonical representation, and then we would have to map that new field in the canonical representation to each of the output targets.  This is actually very straightforward though.  The machinery I've built is such that it will automatically compare the fields, so you just add the mapping from an existing ASG to the canonical representation, you define a mapping from the canonical representation to the AWS API, and you define a mapping from the canonical representation to each of our output targets terraform, cloudformation etc.  It is simply a matter of copying field values in most cases (i.e. this particular example is probably a 20 line change all-in)  "}}