Add an edit command

[smarterclayton]

osc edit allows any resource on the server to be edited directly from
the CLI, which greatly simplifies the process of making changes to objects.
The edited object will be the API object in YAML format by default.

The behavior of this command is extremely similar to git commit or git rebase.

Examples:

$ osc edit svc/kubernetes
# in vim, add a label to kubernetes service

$ osc edit dc/mydeploymentconfig
# change the image, triggers a deployment automatically

$ osc edit -f <previously saved version of a resource>
# could update the resource version via 3 way diff

Errors will be captured to the comment at the top of the file and then
output to the user. Validation errors will allow the user to attempt
to edit the file a second time.

@jwforres review the experience, @deads2k the code

[smarterclayton]

@bgrant0607 after having done this (even with known limitations) this seems like something that would ease a lot of simple use cases in Kube, because you can edit labels, fields, and other structures quickly. It would be better if we had an annotating YAML encoder (where we can stitch both field descriptions and error locations alongside the output field, as well as include example sections for code that users don't specify), but it's not strictly necessary.

[smarterclayton]

Future features

• 3 way diff on the CLI to tell users what has changed and reapply patches after an edit
• Make it easier to recover from conflicts (need change detection so we know whether our patch applies cleanly on top of server changes).

[deads2k]

The defaultVersion is always the same. Move outside the loop to make that clear.

[bgrant0607]

I like it. I'd love to see this in kubectl.

It does a GET, allows the user to edit, and then a PUT? We need to put some energy into cleaning up objects in order to generate clean configs: scrub application of omitempty, convert more fields to pointers so we can distinguish unspecified from language defaults, strip out status, etc.

I agree that this could also work well with the config 3-way diff in the case that the edit were of a local config file rather than directly of the server object.

[smarterclayton]

On Apr 16, 2015, at 10:08 AM, Brian Grant notifications@github.com wrote:

I like it. I'd love to see this in kubectl.

It does a GET, allows the user to edit, and then a PUT?

Yes, very similar code path to get (same arguments)
We need to put some energy into cleaning up objects in order to generate clean configs: scrub application of omitempty, convert more fields to pointers so we can distinguish unspecified from language defaults, strip out status, etc.

One advantage of null over omitempty is you know something is there. But in general smaller is better. I would like to use this to focus on swagger becoming usable for indicating behavior (null status because user can't edit that, etc)
I agree that this could also work well with the config 3-way diff in the case that the edit were of a local config file rather than directly of the server object.

—
Reply to this email directly or view it on GitHub.

[bgrant0607]

Re. null vs. omitempty: Could we use swagger to generate a fully populated spec? By default, we could present the stripped-down spec, but could provide a --full flag or somesuch for the full spec. We could present commonly used fields by default when creating a new object (create --edit), but also provide --full in that case.

[smarterclayton]

Yeah probably. We need more flexibility in our output encoding to do that - the biggest thing I would want is annotations being added to a YAML stream so you could add inline comments, and then next to that it would be the decision to omit empty or continue.

----- Original Message -----

Re. null vs. omitempty: Could we use swagger to generate a fully populated
spec? By default, we could present the stripped-down spec, but could provide
a --full flag or somesuch for the full spec. We could present commonly used
fields by default when creating a new object (create --edit), but also
provide --full in that case.

---

Reply to this email directly or view it on GitHub:
#1758 (comment)

[deads2k]

If I edit improperly and end up back in this loop, then the second time I want to exit and rethink my life. This deletes my file so I can't review.

[deads2k]

Minor comments. I like it.

[smarterclayton]

Updated, ready for review. Conflict should be separate. See the upstream changes which I'll land today or something.

----- Original Message -----

Minor comments. I like it.

---

Reply to this email directly or view it on GitHub:
#1758 (comment)

[deads2k]

Any chance of getting this name updated: #1758 (comment)? It's not obvious from a quick scan that the meaning of info suddenly changed to something different, but related.

Otherwise, lgtm.

[smarterclayton]

Fixed

----- Original Message -----

Any chance of getting this name updated:
#1758 (comment)? It's
not obvious from a quick scan that the meaning of info suddenly changed to
something different, but related.

Otherwise, lgtm.

---

Reply to this email directly or view it on GitHub:
#1758 (comment)

[smarterclayton]

[merge]

[openshift-bot]

continuous-integration/openshift-jenkins/merge SUCCESS (https://ci.openshift.redhat.com/jenkins/job/merge_pull_requests_openshift3/1598/) (Image: devenv-fedora_1291)

[openshift-bot]

Evaluated for origin up to dde93d1