Move apis package to a sub-module

[iypetrov]

Description:
This is a continuation of PR #4989. The apis package is moved to a dedicated sub-module.

Link to tracking Issue(s):

• Resolves partially: APIs package should not import github.com/goccy/go-yaml #4362

Testing:
No new tests are added, just adapt some of the existing ones

[iypetrov]

hey @swiatekm, quick question about apis/v1alpha1/convert.go - right now OpenTelemetryCollector implements the Convertible interface from sigs.k8s.io/controller-runtime/pkg/conversion. This creates a direct dependency on controller-runtime in the API submodule, which could be problematic for users who only want to consume the opentelemetry-operator CRDs without pulling in the full controller-runtime stack. Would it be possible to decouple this? For example, by moving the conversion logic into an internal package or refactoring it into standalone helper functions (which would be my preference)? wdyt?

[swiatekm]

hey @swiatekm, quick question about apis/v1alpha1/convert.go - right now OpenTelemetryCollector implements the Convertible interface from sigs.k8s.io/controller-runtime/pkg/conversion. This creates a direct dependency on controller-runtime in the API submodule, which could be problematic for users who only want to consume the opentelemetry-operator CRDs without pulling in the full controller-runtime stack. Would it be possible to decouple this? For example, by moving the conversion logic into an internal package or refactoring it into standalone helper functions (which would be my preference)? wdyt?

I'm fine moving or refactoring it. We're going to be dropping v1alpha1 Collectors soon either way.

[iypetrov]

I'm fine moving or refactoring it. We're going to be dropping v1alpha1 Collectors soon either way.

@swiatekm I moved the conversion functions into helper functions and now the OpenTelemetryCollector doesn't implement the Convertible interface.

[swiatekm]

I'm fine moving or refactoring it. We're going to be dropping v1alpha1 Collectors soon either way.

@swiatekm I moved the conversion functions into helper functions and now the OpenTelemetryCollector doesn't implement the Convertible interface.

Looks pretty good to me. I think we can even move the conversion code completely into internal/webhook/conversion.go. There isn't any good reason for it to live in the api module. WDYT @open-telemetry/operator-approvers ?

[iypetrov]

Looks pretty good to me. I think we can even move the conversion code completely into internal/webhook/conversion.go. There isn't any good reason for it to live in the api module. WDYT @open-telemetry/operator-approvers ?

I'm okay with it, if others are okay with it will commit the change.

[github-actions]

E2E Test Results

 38 files  261 suites   2h 20m 12s ⏱️
110 tests 109 ✅ 1 💤 0 ❌
283 runs  279 ✅ 4 💤 0 ❌

Results for commit 4232c2e.

♻️ This comment has been updated with latest results.

[iypetrov]

Looks pretty good to me. I think we can even move the conversion code completely into internal/webhook/conversion.go. There isn't any good reason for it to live in the api module. WDYT @open-telemetry/operator-approvers ?

P.S. I already moved it. If v1alpha1 is going to be removed anyway, I think it’s fine to merge this beforehand.

[swiatekm]

The changes look good to me. I think we're also going to need dependabot config updates so we can keep the shared dependencies synchronized, but that can happen in a follow-up.

Since this is a major change, I'm going to need more approvals here, with at least one more maintainer approval. @open-telemetry/operator-approvers if you're opposed to this, this is your last chance to speak up.

[iypetrov]

The changes look good to me. I think we're also going to need dependabot config updates so we can keep the shared dependencies synchronized, but that can happen in a follow-up.

Since this is a major change, I'm going to need more approvals here, with at least one more maintainer approval. @open-telemetry/operator-approvers if you're opposed to this, this is your last chance to speak up.

Is there some example dependabot config for such case?

[swiatekm]

The changes look good to me. I think we're also going to need dependabot config updates so we can keep the shared dependencies synchronized, but that can happen in a follow-up.
Since this is a major change, I'm going to need more approvals here, with at least one more maintainer approval. @open-telemetry/operator-approvers if you're opposed to this, this is your last chance to speak up.

Is there some example dependabot config for such case?

I'm honestly not sure if it supports this very well. If not, we'll move Go dependency updates to renovate, which I'm confident is capable of it. We'd wanted to do this for a while anyway and just never got around to it.

The api package specifically has few enough dependencies that it's not going to be a big deal even if we need to do some manual syncing until we figure it out.

[pavolloffay]

Could we also move the v1alpha1 to keep all the APIs in one place? the v1alpha1 hosts more than just the collector.