Skip to content

External operators can't import v1 API types as types and merge logic live in the same package as busines logic #1985

@Piroddi

Description

@Piroddi

Problem

The CRD types in pkg/apis/clickhouse.altinity.com/v1 live in the same Go package as the controller's template-merge business logic (type_templates.go, type_chi.go, type_configuration_chop.go). That logic depends on mergo.WithSliceDeepMerge, an option that only exists in a personal fork (github.com/sunsingerus/mergo).

Because Go compiles every file in an imported package, anyone importing your v1 types is forced to mirror this replace directive in their own go.mod

replace (
	github.com/emicklei/go-restful/v3 => github.com/emicklei/go-restful/v3 v3.10.0
	github.com/golang/glog => github.com/sunsingerus/glog v1.0.1-0.20220103184348-48242e35873d
	github.com/imdario/mergo => github.com/sunsingerus/mergo v0.0.0-20230507185449-fc6fffa94450
)

Adopting a personal fork as a transitive dependency or forcing a replacement of large upstream project is undesirable for any consumer project. The consequence is that external operators that build on CHI/CHK resources fall back to unstructured.Unstructured, losing compile-time type safety.

Proposal:

Move the merge logic into an internal package, leaving pkg/apis/clickhouse.altinity.com/v1/ containing only:

  • struct definitions (with kubebuilder:object markers)
  • generated deepcopy methods
  • scheme registration

This is the standard Kubebuilder layout. The operator reimports both packages so zero behavior change.
Happy to submit a PR if the proposal is approved.

previous issues: #1618

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions