kops edit opens up vim and expects a human to edit the file. There should be a way to automate these steps so a script could set or change values.
@justinsb don't we have another feature that does this??
https://github.com/kubernetes/kops/blob/master/cmd/kops/replace.go
replace -f with a yaml file?
@dkaplan-pivotal I work around this by once creating my cluster 'manually' (kops create, kops edit) and then exporting to yaml (kops get cluster -oyaml > cluster.yaml, kops get ig master -oyaml > master.yaml, kops get ig nodes -oyaml > nodes.yaml), from there you can destroy your cluster and recreate only using the yaml files:
Concatenate all the .yaml files into one large yaml file (internally separate each one with "---" as per yaml standard), let's call it kops-full-cluster.yaml. Then you can modify that file for templating, seding, etc.
I script this sequence to make any changes to the yaml idempotent:
kops create -f kops-full-cluster.yaml
kops replace -f kops-full-cluster.yaml
kops update cluster --yes
...poll for API availability...
kops rolling-update cluster --yes
Regarding "Then you can modify that file for templating, seding, etc.", this is this ticket:
https://github.com/kubernetes/kops/issues/2404
Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
Prevent issues from auto-closing with an /lifecycle frozen comment.
If this issue is safe to close now please do so with /close.
Send feedback to sig-testing, kubernetes/test-infra and/or @fejta.
/lifecycle stale
This is fixed a bunch of different ways now... closing
For what it's worth, I'm abusing the EDITOR environment variable to accomplish this. It's not really clear to me how kops toolbox template would help me script edits to an existing cluster. Maybe help me out?
Scripting edits to an existing cluster could be achieved with something like:
kops get cluster -o yaml | yourscript | kops replace -f -; kops update cluster --yes
or
kops get cluster -o yaml > manifest.yaml; yourscript --file manifest.yaml; kops replace -f manifest.yaml; kops update cluster --yes.
though its highly recommended to instead always use a version controlled manifest as a source of truth, in which case you're pipeline just becomes kops replace -f manifest.yaml; kops update cluster --yes with your script modifying your manifest.yaml as appropriate.
Most helpful comment
@dkaplan-pivotal I work around this by once creating my cluster 'manually' (kops create, kops edit) and then exporting to yaml (
kops get cluster -oyaml > cluster.yaml,kops get ig master -oyaml > master.yaml,kops get ig nodes -oyaml > nodes.yaml), from there you can destroy your cluster and recreate only using the yaml files:Concatenate all the .yaml files into one large yaml file (internally separate each one with "---" as per yaml standard), let's call it
kops-full-cluster.yaml. Then you can modify that file for templating,seding, etc.I script this sequence to make any changes to the yaml idempotent:
kops create -f kops-full-cluster.yamlkops replace -f kops-full-cluster.yamlkops update cluster --yes...poll for API availability...
kops rolling-update cluster --yes