Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Make Api::apply as an alias for Api::patch with server-side mode #174

Closed
clux opened this issue Mar 8, 2020 · 4 comments
Closed

Make Api::apply as an alias for Api::patch with server-side mode #174

clux opened this issue Mar 8, 2020 · 4 comments
Labels
api Api abstraction related apply patch or server-side apply

Comments

@clux
Copy link
Member

clux commented Mar 8, 2020

So we have a nice interface to server-side apply (limit to kubernetes version >=1.16)

@clux clux added the api Api abstraction related label Mar 8, 2020
@clux clux added this to the kubecon-eu-2020 milestone Mar 8, 2020
clux added a commit that referenced this issue Mar 8, 2020
currently broken due to #176
@clux clux added the apply patch or server-side apply label Mar 8, 2020
@clux
Copy link
Member Author

clux commented Mar 8, 2020

Perhaps Api::update would also be a useable name, given there are two ways to do it.

clux added a commit that referenced this issue Mar 22, 2020
currently broken due to #176
@clux
Copy link
Member Author

clux commented Mar 22, 2020

A potential, require the whole K and have as a shorthand replacement for Api::replace:

    /// Server side apply a yaml patch over a named resource
    ///
    pub async fn apply(&self, name: &str, patch: &K) -> Result<K>
    where
        K: Serialize,
    {
        // TODO: ApplyParams shorthand? for now...
        use crate::api::PatchStrategy;
        let ssapply = PatchParams {
            patch_strategy: PatchStrategy::Apply,
            // always override on conflicts
            force: true,
            // owner of the fields: (us)
            field_manager: Some(env!("CARGO_PKG_NAME").into()),
            ..Default::default()
        };
        let bytes = serde_yaml::to_vec(&patch)?;
        let req = self.api.patch(name, &ssapply, bytes)?;
        self.client.request::<K>(req).await
    }

Now of course this does not let people supply partial patches like the PatchParams::default (json merge) lets you. But this is actually kind of good at the moment, because kubernetes will force any optionals on our K to null if we leave them out (even if they are missing from the serialization). I.e.
you actually force options to None even if they were set before if you miss them out.

So lacking a good solution to #129 (which I think would let us customize that behaviour / hook it into our serde skip_serialize behavior), it's not a good plan to let people supply partial yaml to server side apply on CRDs. If they need partial application, they need to stick with json merge until we have support for that.

clux added a commit that referenced this issue Mar 22, 2020
currently broken due to #176
clux added a commit that referenced this issue Mar 22, 2020
@clux
Copy link
Member Author

clux commented Apr 8, 2020

This is probably a mistake. Going to just do this with a constructor alias on PatchParams.

@clux clux closed this as completed in 909487c Apr 8, 2020
@nightkr
Copy link
Member

nightkr commented Apr 8, 2020

Yeah.. apply and patch have vastly different types (Partial<K> and JsonPatch<K> respectively, though neither can be expressed natively in Rust today).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
api Api abstraction related apply patch or server-side apply
Projects
None yet
Development

No branches or pull requests

2 participants