WIP Ensure ActiveGate is Enabled for Extensions

[wepudt]

Description

see K8S-10118

ActiveGate is also created when Extensions are enabled in the DynaKube. No other AG capabilities are needed.

Dynakube v1beta2 is manually converted to v1beta3 in all cases when dynakube.NeedsActiveGate() or NeedsActiveGateService() is called.

How can this be tested?

1. Unittests.
2. Apply dynakubes below. ActiveGate pod should be always created.
   Check enabled capabilities on the AG pod using:

kubectl -n dynatrace get -o yaml pod/dynakube-activegate-0 -o jsonpath="{.spec.containers[0].env[0]}"

a)
dynakube:

spec:
  activeGate:
    capabilities:
      - routing
    replicas: 1
  extensions:
    prometheus:
      enabled: true
  oneAgent:
    cloudNativeFullStack: {}

capabilities:

{"name":"DT_CAPABILITIES","value":"MSGrouter,extension_controller"}

b)
dynakube:

spec:
  activeGate:
    replicas: 1
  extensions:
    prometheus:
      enabled: true
  oneAgent:
    cloudNativeFullStack: {}

capabilities:

{"name":"DT_CAPABILITIES","value":"extension_controller"}

c)
dynakube:

spec:
  extensions:
    prometheus:
      enabled: true
  oneAgent:
    cloudNativeFullStack: {}

capabilities:

{"name":"DT_CAPABILITIES","value":"extension_controller"}

[codecov-commenter]

⚠️ Please install the to ensure uploads and comments are reliably processed by Codecov.

Codecov Report

Attention: Patch coverage is 74.31694% with 94 lines in your changes missing coverage. Please review.

Project coverage is 57.13%. Comparing base (79211a9) to head (0b753a4).

Files	Patch %	Lines
...mocks/pkg/controllers/dynakube/istio/reconciler.go	13.33%	12 Missing and 1 partial ⚠️
...cks/pkg/controllers/dynakube/version/reconciler.go	33.33%	12 Missing ⚠️
cmd/troubleshoot/image.go	16.66%	9 Missing and 1 partial ⚠️
.../dynakube/deploymentmetadata/deploymentmetadata.go	37.50%	10 Missing ⚠️
...ntrollers/dynakube/oneagent/oneagent_reconciler.go	37.50%	6 Missing and 4 partials ⚠️
pkg/controllers/dynakube/controller.go	73.07%	5 Missing and 2 partials ⚠️
pkg/api/v1beta3/dynakube/properties.go	0.00%	6 Missing ⚠️
pkg/controllers/dynakube/injection/reconciler.go	62.50%	3 Missing and 3 partials ⚠️
...s/dynakube/processmoduleconfigsecret/reconciler.go	25.00%	6 Missing ⚠️
pkg/controllers/dynakube/phase.go	84.00%	2 Missing and 2 partials ⚠️
... and 5 more

❗ Your organization needs to install the Codecov GitHub app to enable full functionality.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #3361      +/-   ##
==========================================
- Coverage   57.23%   57.13%   -0.11%     
==========================================
  Files         344      344              
  Lines       19781    19849      +68     
==========================================
+ Hits        11322    11340      +18     
- Misses       7221     7256      +35     
- Partials     1238     1253      +15     

Flag	Coverage Δ
unittests	57.13% <74.31%> (-0.11%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

mistake

[0sewa0]

IMO, if you use 2 versions, use 2 aliases

[0sewa0]

I read through more of the code, and it always comes back up.
And I started to ask my self: "What is the benefit of handling 2 versions in a package?"

It is just confusing, and will only cause more work, because when we move away from the older version, all of these packages need to be changed.
There is no information loss when converting between the versions, so what the old-version had the new-version also has. So doing this "use double the version, and sometimes pass in 2 dynakubes" are just asking for mistakes caused by confusion.

IMO The biggest flaw with this whole approach (converting at "random" places) is that we like to pass the DynaKube via reference, and we expect the Status part to be mutated as we pass it around, but the moment you introduce conversions in places, and not handle the mutation carefully, some data may be lost

How I would do it is:

• Only 1 version is allowed in a package (conversion and main dk-controller is exempt, maybe troubleshoot and istio aswell)
• If a package uses the new-version in any way, the input for that package should be the new-version
  • The caller of the package will do the convertTo and From, so it will own the reference that is passed it, so no changes to the Status should be lost.

[albertogdd]

While I agree with you, I think we should focus on unblocking this PR (because Werner is on vacation, many stories depends on this and it's getting stucked) and then start switching to beta3 everywhere. We will have to do it anyways with the oncoming stories so we can do it in small increments, or maybe do it all at once after this is merged?

I'm just trying to find the most painless way of moving forward with this.

[aorcholski]

new PR based on v1beta3 branch will be created