You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@superset.apache.org by "AdheipSingh (via GitHub)" <gi...@apache.org> on 2026/05/04 20:50:41 UTC
[I] Consider embedding v1.PodSpec instead of manually listing PodSpec fields [superset-kubernetes-operator]
AdheipSingh opened a new issue, #21:
URL: https://github.com/apache/superset-kubernetes-operator/issues/21
As i was going over the codebase, i found an issue regarding PodTemplate and ContainerTemplate in shared_types.go manually enumerate Kubernetes PodSpec fields (Affinity, Tolerations, NodeSelector, Volumes, etc.). Every time Kubernetes adds a new field to PodSpec, this operator needs a code change to expose it.
This is some even in druid operator we wan't to get rid of. Over the years the types will grow as upstream k8s will add more parameters.
I propose embedding v1.PodSpec directly (or v1.PodTemplateSpec) would inherit all current and future fields automatically, reducing maintenance burden.
cc @villebro . I'll be willing to submit a PR for this.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@superset.apache.org.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: notifications-unsubscribe@superset.apache.org
For additional commands, e-mail: notifications-help@superset.apache.org
Re: [I] Consider embedding v1.PodSpec instead of manually listing PodSpec fields [superset-kubernetes-operator]
Posted by "villebro (via GitHub)" <gi...@apache.org>.
villebro commented on issue #21:
URL: https://github.com/apache/superset-kubernetes-operator/issues/21#issuecomment-4374441644
Thanks @AdheipSingh. In this implementation we've deliberately wanted to gate introduction of new PodSpec fields to have a tightly curated set of fields. The initial list is based on those exposed by the current Helm chart. However, having said that, I'm not overly opinionated on this point, so if this is expected to become a pain point, and has proven to be such in other similar operators, I'm definitely open to relax that requirement. The only thing I ask is carefully considering any security implications of directly exposing PodSpec/PodTemplateSpec.
I think I got the gist of your improvement proposal, but if you can quickly explain your proposed schema changes here, we can iterate on it until we're all happy with the spec before getting started on the code.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@superset.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: notifications-unsubscribe@superset.apache.org
For additional commands, e-mail: notifications-help@superset.apache.org
Re: [I] Consider embedding v1.PodSpec instead of manually listing PodSpec fields [superset-kubernetes-operator]
Posted by "villebro (via GitHub)" <gi...@apache.org>.
villebro commented on issue #21:
URL: https://github.com/apache/superset-kubernetes-operator/issues/21#issuecomment-4374976654
@AdheipSingh thanks for raising this and for the references, they provide great context.
Our curated field set is based on years of Helm chart experience: it's actually a superset of what the Superset Helm chart exposes, and that core schema has been stable for several years now, which gives me confidence we've identified the main fields admins need. I feel the pain in those other projects was largely around missing basic fields: OTel didn't have `readinessProbe` or `securityContext`, Strimzi was missing `enableServiceLinks`. We already expose all of those, plus several fields that those operators don't appear have (like `dnsPolicy`, `dnsConfig`, `runtimeClassName`, `topologySpreadConstraints`, `lifecycle`). We also support full `Container` array based `initContainers` and `sidecars`.
Given that adding a new field to `PodTemplate`, `ContainerTemplate`, or even `DeploymentTemplate`, is essentially a one-line change (no merge logic updates, no new reconciliation code), I'd prefer to keep the curated approach and add fields as concrete needs arise. This gives us predictable merge semantics between top-level and per-component specs, smaller CRDs, and a clearer user guide and more contained/explicit schema.
That said, I appreciate the perspective: If we find ourselves fielding frequent requests for new fields, we can revisit the escape hatch idea. But for now I'd rather stay tight and responsive to individual asks.
Btw, if there's a specific field you feel we're missing today, I'm happy to review a PR that adds it.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@superset.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: notifications-unsubscribe@superset.apache.org
For additional commands, e-mail: notifications-help@superset.apache.org
Re: [I] Consider embedding v1.PodSpec instead of manually listing PodSpec fields [superset-kubernetes-operator]
Posted by "AdheipSingh (via GitHub)" <gi...@apache.org>.
AdheipSingh closed issue #21: Consider embedding v1.PodSpec instead of manually listing PodSpec fields
URL: https://github.com/apache/superset-kubernetes-operator/issues/21
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@superset.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: notifications-unsubscribe@superset.apache.org
For additional commands, e-mail: notifications-help@superset.apache.org
Re: [I] Consider embedding v1.PodSpec instead of manually listing PodSpec fields [superset-kubernetes-operator]
Posted by "AdheipSingh (via GitHub)" <gi...@apache.org>.
AdheipSingh commented on issue #21:
URL: https://github.com/apache/superset-kubernetes-operator/issues/21#issuecomment-4374592497
I agree, on the security part. Raw PodSpec exposes fields like hostNetwork, hostPIC etc. You can handle that either via validation webhook or some platform operators to enforce via other projects like Kyverno, OPA etc.
Proposed approach : embed corev1.PodSpec directly:
```
type PodTemplate struct {
corev1.PodSpec `json:",inline"`
}
```
Schema change for users none.
Same approach for ContainerTemplate
```
type ContainerTemplate struct {
corev1.Container `json:",inline"`
}
```
I have also seen other operator which do the same, example :
- [Clickhouse operator](https://github.com/Altinity/clickhouse-operator/blob/master/pkg/apis/clickhouse.altinity.com/v1/type_templates.go#L52)
- https://github.com/open-telemetry/opentelemetry-operator/issues/901 - users did raise the same issue.
- https://github.com/strimzi/strimzi-kafka-operator/issues/4800
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@superset.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: notifications-unsubscribe@superset.apache.org
For additional commands, e-mail: notifications-help@superset.apache.org