Alpha module list#2884
Conversation
✅ Proposed changes verification passedThis pull request comes with up-to-date documentation and no illegal standard output usages. Find more detailed information in the |
✅ Proposed changes verification passedThis pull request comes with up-to-date documentation and no illegal standard output usages. Find more detailed information in the |
✅ Proposed changes verification passedThis pull request comes with up-to-date documentation and no illegal standard output usages. Find more detailed information in the |
| for i, status := range kymaCR.Status.Modules { | ||
| raw := kyma.KymaModuleInfo{Status: status} | ||
| for _, spec := range kymaCR.Spec.Modules { | ||
| if spec.Name == status.Name { | ||
| raw.Spec = spec | ||
| break | ||
| } | ||
| } |
There was a problem hiding this comment.
Module entry in kyma.spec.modules comes from a user and the entry in status is populated by the lifecycle manager. When lifecycle manager fails somehow and won't populate the status we might lose information that user wanted to enable the module (i.e. module will be present in spec and will be missing in status). I'm not saying it's very probable scenario but I think it's safer to iterate over the module spec in the first place
There was a problem hiding this comment.
Ok, I've just realized that when we remove entry from the spec then we are still going to have entry in the status as it's going to be in Deleting state for some time, so it goes both ways:
- user adds entry in the
spec- for some time we might have entry only in thespecand not instatusbefore lifecycle manager gets to reconcile the module - user removes entry from the
spec- then for some time we have entry only in thestatusas it's in theDeletingstate
So I believe we should iterate separately the status and spec collections and compose the result
| ModuleState: module.ModuleState, | ||
| Managed: module.IsManaged(), | ||
| CustomResourcePolicy: module.CustomResourcePolicy, | ||
| InstallationState: installationState, |
There was a problem hiding this comment.
With that approach we've detached the installationState from the moduleInstallation. I think the installationState should live in the moduleInstallation and population of it's value should be handled in the NewModuleInstallationFromRaw.
| return &moduleInstallationStateRepository{kubeClient: kubeClient} | ||
| } | ||
|
|
||
| func (r *moduleInstallationStateRepository) GetInstallationState(ctx context.Context, module entities.ModuleInstallation) (string, error) { |
There was a problem hiding this comment.
This is implementation of a separate repository for a single string value that I believe should live in the ModuleInstallation as the installation state belongs to the moduleInstallation. I see however that there's lot of extraction logic that might bloat the original repository.
I think we could introduce some kind of extractors or converters package that could live in the repository package that could have specialized classes responsible for such data transformations
|
There's some discrepancy in how |
…solveInstallationState
✅ Proposed changes verification passedThis pull request comes with up-to-date documentation and no illegal standard output usages. Find more detailed information in the |
Description
Changes proposed in this pull request:
Related issue(s)
See also: