Is there a way to get default values for PodTemplate?

[beyondbill]

I'm writing an operator where the PodTemplate of a custom resource should be compared to its dependent ReplicaSet during reconciliation. To help easier understanding, think of this custom resource as the native Deployment.

What I encounter is that when the dependent ReplicaSet is generated, Kubernetes always adds default values to some fields in its PodTemplate that aren't set from the custom resource's PodTemplate. One example is that the generated dependent ReplicaSet has spec.schedulerName: default-scheduler in its PodTemplate even though its parent custom resource passes its PodTemplate to the ReplicaSet without that field set.

This is the expected behavior with Kubernetes. However it's an issue when the operator tries to detect changes of PodTemplate between the custom resource and the dependent ReplicaSet. Even though there's no actual change, a simple diff between the two would still show diffs because Kubernetes automatically adds the default values to the dependent ReplicaSet's PodTemplate.

I would love to find a way to get all the default values for a PodTemplate and then merge the custom resource's PodTemplate with these default values before comparing with the PodTemplate from its dependent ReplicaSet. Appreciate if anyone can provide me how to do it with Fabric8. Thanks!

[manusa]

I'm not sure that client-wise we can do anything here.

Maybe you can set those default values yourself so that Kubernetes doesn't do it for you, but this is just me thinking out loud.

/cc @metacosm @csviri

[metacosm]

Are you using the Java Operator SDK?

[beyondbill]

@metacosm I am using Java Operator SDK

[beyondbill]

Maybe you can set those default values yourself so that Kubernetes doesn't do it for you, but this is just me thinking out loud.

@manusa Yeah this would be the last resort. But I hope not to hard code all the default values for pod template specs as part of my operator code.

[metacosm]

@metacosm I am using Java Operator SDK

Are you using the dependent feature? If not, you might want to consider it 😉. If yes, your implementation of the desired method could take care of this (and, if I'm not mistaken, the default implementation provided for Kubernetes dependents should also take care of this problem).

[pjankovsky]

(I work with @beyondbill)

We are indeed using the dependent resource model for this; the BulkDependentResource interface in particular.

However it's an issue when the operator tries to detect changes of PodTemplate between the custom resource and the dependent ReplicaSet.

This is where we get stuck with it. We use context.getSecondaryResources(ReplicaSet.class) to get all the dependent ReplicaSets, then we filter for the "active" one and try to see if the change in our CRD would require a new ReplicaSet. We make specific checks for some fields (spec.replicas for example) where we can edit the ReplicaSet, but we are not sure how to determine if we need to replace the ReplicaSet because the PodTemplate changed.

With the standard dependent resource model (1:1), how would this work anyway? Would the operator code try to update the replicaset and hit an error? Or is there a catch for the error that would result in the replicaset being replaced?

[metacosm]

@pjankovsky do you have a way to replicate the issue?

[stale[bot]]

This issue has been automatically marked as stale because it has not had any activity since 90 days. It will be closed if no further activity occurs within 7 days. Thank you for your contributions!