Adding ObjectRef to custom resources

[zlepper]

According to the documentation here: https://kube.rs/controllers/relations/#watched-relations it looks it is possible to add an ObjectRef to my custom resource defintion, however that doesn't work as it implements neither Serialize and JsonSchema. Is there a full example for that code or am i completely misunderstanding something?

I can create the objectRef by hand based on a custom struct, so no stress, i'm just curious if i'm overcomplicating something that is supposed to be easy?

[clux]

You can look at the rust doc examples for more info about the types to get things to build. In particular, see Controller::watches doc or Controller::watches_stream doc as those things will compile (the hashes in the code indicate the lines are used for compilation but not displayed in the example)

If you are getting missing impls you probably get those from elsewhere (like on the main crd perhaps). If you are creating the runtime variant of an ObjectRef things should just work.

[zlepper]

Yeah, that part as mentioned i could get working, so let me try to add some code example what i expect i might be able to do based on the code example in the docs i linked in my original post.

Basically i have a "main resource":

#[derive(CustomResource, Serialize, Deserialize, Debug, PartialEq, Clone, JsonSchema)]
#[kube(
    group = "postgres.digizuite.com",
    version = "v1alpha1",
    kind = "PgBouncer",
    plural = "pgbouncers",
    derive = "PartialEq",
    namespaced
)]
#[serde(rename_all = "camelCase")]
pub struct PgBouncerSpec {
  // Stuff goes here...
}

And a resource that i want to have referencing that resource:

#[derive(CustomResource, Serialize, Deserialize, Debug, PartialEq, Clone, JsonSchema)]
#[kube(
    group = "postgres.digizuite.com",
    version = "v1alpha1",
    kind = "PgBouncerDatabase",
    plural = "pgbouncerdatabases",
    derive = "PartialEq",
    namespaced
)]
#[serde(rename_all = "camelCase")]
pub struct PgBouncerDatabaseSpec {
     pub main: ObjectRef<PgBouncer>
}

When i do that i get this error:

the trait bound `kube_runtime::reflector::ObjectRef<types::pg_bouncer::PgBouncer>: postgres_password::_::_serde::Serialize` is not satisfied [E0277] the trait `postgres_password::_::_serde::Serialize` is not implemented for `kube_runtime::reflector::ObjectRef<types::pg_bouncer::PgBouncer>`

and

the trait bound `kube_runtime::reflector::ObjectRef<types::pg_bouncer::PgBouncer>: schemars::JsonSchema` is not satisfied [E0277] Help: the following other types implement trait `schemars::JsonSchema`:

Both of which are correct, ObjectRef doesn't implement either.

I can create my own ref type, so it's not really a problem, i just wanted to confirm if this was something that was supposed to be possible, or if i was misreading the names in the linked doc :)

[clux]

oh, interesting. yeah. you are nesting an ObjectRef (which does not derive JsonSchema) inside your struct and thus it's not even possible to derive JsonSchema for PgBouncerDatabaseSpec

the annoying part is that the more schematically correct ObjectReference which we normally generate from Resource::object_ref does implement this 🙃

[clux]

Might be worth revisiting #812 on our end (to make it easier to convert between the different objectref flavours).

[zlepper]

Yes, i did also take a look at ObjectReference, but it seemed to contain a lot of information that i had hoped that ObjectRef could imply based on the generic. But fair enough, i have a solution, just wanted to confirm :)

Maybe worth visiting the "Watched relations" documentation and get it up to snuff to save someone else being confused in the future :D

And thank you so much for taking the time to answer :)

[clux]

Yeah, I'll root around in there to try and make it nicer.

Note that there is actually an easy way to convert an ObjectRef<K: Resource> into ObjectReference so that you have something serializable (and better to store on your CRD struct) using this From impl (it just doesn't show up on docs.rs for some reason - would have expected it here: https://docs.rs/kube/latest/kube/runtime/reflector/struct.ObjectRef.html#trait-implementations )

[nightkr]

It's.. a bit of a mess. I agree that ObjectRef<K> is theoretically preferable as a generic identifier type, but it was originally designed as "whatever reflector/controller needs" (hence also why it lives in kube::runtime rather than kube::core, and why Api doesn't use it).

There are also some aspects that make both awkward for API interfaces. When you're storing a reference to an object, the API version is part of how the user would interact with the object, rather than of the reference itself (for example: a Pod would be owned by an apps/ReplicaSet, not an apps/v1/ReplicaSet, but a Pod projects the attributes of a certain API version of itself into environment variables).

On the other hand, you clearly need to know the version as well in order to be able to perform any API actions on it. It can also be very helpful for troubleshooting, when you want to be able to see an object as your operator sees it.

On the third, there's also a clear convention that namespaced objects should not be able to refer to objects in other namespaces, in order to enforce tenant isolation.

Kubernetes itself gets around this by effectively inventing bespoke reference types for each use case (ObjectReference, TypedObjectReference, OwnerReference, SecretReference, String), but that's also not very satisfying.