-
Notifications
You must be signed in to change notification settings - Fork 107
Server Side Apply #123
Comments
Do you have any links to the HTTP API for server side apply? |
I'm unable to find the spec for it. I used kubectl to apply (to my gke 1.16 cluster) and turned on debugging. kubectl apply --v=9 --server-side -f ~/Desktop/test.yaml
|
I started hacking around and I feel like I'm close. It's saying the following.
I think I need to set the apiVersion on the object I'm sending as part of the request body. I'm about to go drinking, so I thought I'd post my progress now. :) |
Getting closer. I have a "hello world" service I'm deploying for testing. It consists of a configmap, deployment, autoscaler, and service. I'm printing the marshaled json before it's sent to the API server. I was reading some other issues and it looks like it's a non-goal of this client to be able to marshal json. Looks like the API server supports some sort-of extra fancyness where fields can be multiple different types. Like with a resource.Quantity it accepts a string, integer, or float. That's currently where the code I have barfs. I'm trying to figure out if the server-side-apply supports accepting the patch as protobuf now. My high-level goal is to be able to declare all of my configuration in go, so I can parameterize it in go. Updated the draft PR with the latest code. Code is a total mess, but at this point I'm just figuring out how to get this working, not focused on making the code nice.
|
I spend a lot of time searching for how to send the patch as protobuf. I didn't come up with anything. I decided to ask the apply working group for advice. :) https://groups.google.com/forum/#!topic/kubernetes-wg-apply/YdgP7a2gfjM |
Thanks for asking the group, we're looking into it. We'll provide a response soon :-) |
The intorstring and resource.Quantity values in your patch are not serialized correctly. They should be formatted like: |
How are you creating the marshaled JSON? |
liggitt, I was attempting to encode with "encoding/json" which I have learned is not correct. During this issue is when I became aware of the special json encoding requirements that Kubernetes expects. Those special requirements increase serialization complexity. It looks like the best way to handle this encoding is to depend on kubernetes/api (1) which pulls in a ton of transitive dependencies. This client is about avoiding dependencies so it will be unable to use that package. It seems like the approach of this client is to stick with protobuf serialization, which is simpler, since protobufs are strictly about marshaling datastructures and aren't increasing serialization complexity to make human interaction with the serialized format easier. [rant] (Eric Chaing should feel free to correct me if I'm not fully understanding the goals of this client) |
So as server-side-apply currently can't support proto and proto to json won't generate a valid result, I don't think it's possible to use server-side apply with this client right now. If your objects were generated based on the openapispec instead of proto I think they would be compatible with server-side-apply. But that doesn't sound like the scope of this client. |
Thanks all for the help! I believe I understand now. Conclusion is that it's technically infeasible for server side apply to support protobufs due to the requirement of patch to make a distinction between present and nil, vs not present. Looks like this client can't support marshaling yaml, but we can give the user a choice to specify already-marshaled yaml. I like this idea Eric had here to add RawResource. I'll experiment with this in the context of server-side-apply. |
I'm going to completely stop working on this. Moving my configuration into go isn't working out well enough. |
GKE just released 1.16 to rapid. I'd like to use server-side-apply. Generally, I'd like to declare protobufs in go, then use the new serve-side-apply feature.
Are there any design choices blocking this working in this client? If not, what implementation work would be required to get this working. Maybe it's something I can help out with.
Thanks!
The text was updated successfully, but these errors were encountered: