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 1423146 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 5d11f7c for the migration changes to the nee SDK alone.

Engineering Proposal: Translation Layer

All Submissions:

• Have you signed our CLA?

[github-actions]

https://app.codecov.io/github/mongodb/mongodb-atlas-kubernetes/commit/1f73fa3f1aca2d03dc87a533e532606ce04d14d8

[s-urbaniak]

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

[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.

[s-urbaniak]

suggestion: translayer implies two terms, "translation" and "layer". The latter is somewhat obvious as every package is a layer. How about just translation? That naming is pretty idiomatic and immediately implies what is done here, namely translating things.

[josvazg]

will rename, I will also rename the translation.go files to conversion.go

[josvazg]

coming on next PR update

[josvazg]

Add godoc on making a copy before calling, as this makes changes on input

[josvazg]

coming next