DB User Translation Layer & SDK migration

[josvazg]

Sample Translation layer for your consideration:

• The packages under internal/translation contain per Altas resource translation layers for users and deployments.

• Files in the controller package should not import the SDK library to call the API or use its types.

• All translations and upgrades are confined to the translation code.

• Contract tests would use the translation layer directly.

• This layout also enforces proper translations and comparisons, no more funky CMP or JSONCopies.

• See commit 142314606ac35d3d5d5568c1f6acccdf10c87bc8 for a version when the translation layer is on an atlas.go file within the same package using the old Go API client

• See commit 5d11f7cf28ca20b62e7e589356798a80fc4318de for the migration changes to the nee SDK alone.

Engineering Proposal: Translation Layer

All Submissions:

• [X] Have you signed our CLA?

[github-actions[bot]]

https://app.codecov.io/github/mongodb/mongodb-atlas-kubernetes/commit/48087a9725ff6f5811cfaad6833e2850e7f5ea84

[josvazg]

general question: how does the "contract" look like which the translation layer seems to be a prerequisite for?

The contract is not really fully defined until you have the tests with the validations that check precisely the contract behavior. Here we only have the shape of the interactions in the service methods and the translations we make.

This is NOT the contract test PoC, just the translation layer, which is probably more than half the code required.

What is left now is the helper code to be able to put the API side in the state required to be able to test the API calls in the service in the situations that define the contract with the Atlas. Those tests inform how and when the service calls defined in the translation layer should be called from the controller to achieve the expected results. Which would allow to test the reconciliation without the API with a great deal of confidence, other than if something changes on the API side, which the contract tests will detect.

Client Contract Tests do NOT need to cover all API behaviours, just the ones our client cares about.

[josvazg]

general question: how does the "contract" look like which the translation layer seems to be a prerequisite for?

The contract is the Service interface. On the other PoC I made that a explicit Interface type, on this I will add the interface now.

The only requisite of the contract is that it only accepts and returns internal or Kubernetes types, it completely encapsulates Atlas SDK types as a lower protocol layer.

[josvazg]

Will draft this until I rebase and add the unit tests and other suggested fixes

[josvazg]

Lesson learned: This PR is bigger and took way longer than I thought it would or should. Here is what I should instead have done in hindsight:

1. TDD the translation layer alone in isolation, do not connect it yet.
2. Have another branch on top experimenting with the usage from the rest of the code, keep it as draft only.
3. Post the translation layer PR alone in the internal package, unused but fully tested with both unit tests and contract tests.
4. Merge translation later.
5. Rebase the branch using it as a new PR including unit tests and post that.

Even though it seems to have more steps, the reality I ended up covering most of those things in a reactive manner. Changing the order and slicing would have been easier to debug and review, so the whole process would have been faster in comparison IMHO.