`Kapply` needs a `Kedit` afterwards

[phmarek]

Hi,

first of all -- thanks a lot for this plugin!

One thing I'm always stumbling over is that when I edit some cluster resource and Kapply it, the metadata.resourceVersion changes in the cluster but not in the vim buffer - so when I do further changes and try to Kapply again, I get an error like

error when patching "STDIN": Operation cannot be fulfilled on buildconfigs.build.openshift.io "…": the object has been modified; please apply your changes to the latest version and try again

which means that my local changes are lost (unless I remember which lines I modified and/or write the buffer to some temp file or similar stuff).

Is there an easy way to fetch the new resourceVersion on Kapply and fix the buffer, or perhaps to replace the buffer contents with a new checkout, so that changes and a Kapply work immediately?

Thanks a lot!

[rottencandy]

Are you using Kapply on the resource buffer directly?(buffer name starts with kube://) Kapply is actually meant to be used with local files, so it doesn't modify the buffer after applying.

But if you're trying to apply a resource buffer, you can simply save it normally with :w after making changes, that should both apply the resource and update the buffer contents to the latest fetched resource manifest.

There's also a <leader>r mapping defined that can update the resource at any time, although this will discard any unsaved changes.

I hope that helps.

[phmarek]

Ah yeah, thanks! Seems I forgot about that because the cursor position is lost.

I guess when replacing the buffer contents the lines are removed for a short time, so the cursor moves to the first line - so the context is lost.

[phmarek]

Another reason why I didn't use :w is that when changing eg. a BuildConfig and using that to build an image, the metadata.generation number gets incremented as well.

So if I'm still in the buffer after the image was built, change something and do :w, I get the the object has been modified; please apply your changes to the latest version and try again error again...

Yeah, <leader>r helps here -right. I just have to remember what I did change...

Would it be a good idea to detect that and trying a merge? But there's only the current version and the user's version, no base for a 3-way-merge... Well, at least diff mode with the two contents should be possible.

[rottencandy]

I pushed a change that should fix the cursor reset issue 6b85ccc

[rottencandy]

The manifest updating on the cluster annoys me too, but I haven't been able to come up with a reliable method to detect changes so I've been managing with <leader>r. Might have to pick between repeatedly polling the resource at a regular interval, or using something like kubectl watch.

Opening diff mode during a conflict sounds interesting though, I'll try exploring that, thanks.

[phmarek]

Might have to pick between repeatedly polling the resource at a regular interval, or using something like kubectl watch.

No, please don't cause any load - not locally and not in the cluster. If there's a way to react to some trigger, that might be fine -- though that still leaves open the problem of merging!

Opening diff mode during a conflict sounds interesting though, I'll try exploring that, thanks.

I believe that detecting that object modified error, trying to merge some stuff automatically and showing the diff view is the sane approach. There's metadata.annotations[kubectl.kubernetes.io/last-applied-configuration], perhaps that helps for a 3-way merge?

[rottencandy]

The problem is that there's no way to parse yaml/json natively in vimscript so reading fields reliably is difficult. It can be done with external tools like jq but I'm not sure about adding another dependency to the plugin.

Maybe we could just detect failure on apply and then do a 3 way diff with last fetched version, edited version and latest cluster version.