Cannot module delete docker-registry when it was installed with custom cr-path and channel

[kwiatekus]

Description

It seems there is a bug in kyma alpha module delete command as it tries to locate moduletemplate matching the global release channel.

For example, when I install a module from channel experimental (overriden as global channel for this particular Kyma is fast) and with a custom CR then I cannot delete it via CLI

Expected result

After adding a module with custom CR and channel i should be able to remove module from Kyma CR with kyma CLI (having removed the custom CR first)

Actual result

kyma alpha module add docker-registry --channel experimental --cr-path custom-docker-registry.yaml

Then I cannot delete it using CLI

kubectl delete dockerregistries.operator.kyma-project.io -A --all
dockerregistry.operator.kyma-project.io "custom-dr" deleted

kyma alpha module delete docker-registry
Error:
  failed to get ModuleTemplate CR for module

Error Details:
  can't find ModuleTemplate CR for module docker-registry in version 0.6.1

☝ it seems like the logic is trying to find module template based on the kyma global channel, not the overridden one (experimental)

The same scenario works in kyma dashboard

Related issues
#1328

[halamix2]

Custom CR doesn't do anyhting in this scenario.

I think that the issue is because ModuleTemplate for old and new modules is different/broken/not documented enough.

In the new modules (template-operator, the ModuleTemplate.Spec Version field is filled, but Channel is empty.

In docker-registy, and most of the old modules (all of them?) the ModuleTemplate.Spec Version field is empty, but Channel is filled.

Currently, our code loops over all ModuleTemplates, and matches one based on the module name and version:

cli/internal/kube/kyma/kyma.go

Lines 83 to 86 in 50e5878

	if moduleTemplate.Spec.ModuleName == moduleName &&
	moduleTemplate.Spec.Version == moduleVersion {
	return &moduleTemplate, nil
	}

I think the question is:

• do we choose only to support one (old/new) approach
• support them both
• check why there are these differences in ModuleTemplates and fix them to have one approach

[kwiatekus]

I see that both "old" and "new" moduletemplate have
spec.descriptor.component.version populated

@kyma-project/jellyfish
Could we use that in kyma CLI to identify moduletemplate for module by name and version ?

[c-pius]

In the new modules (template-operator, the ModuleTemplate.Spec Version field is filled, but Channel is empty.

In docker-registy, and most of the old modules (all of them?) the ModuleTemplate.Spec Version field is empty, but Channel is filled.

This observation is correct. New module tempaltes always have spec.version, never have spec.channel. Old module templates always have spec.channel, never spec.version.

@kyma-project/jellyfish
Could we use that in kyma CLI to identify moduletemplate for module by name and version ?

May I ask about the use case to determine the template by version? As long as users still must install it via a channel, I think the lookup also should work via channel. In KLM, we have implemented this like we first check if there is an old module (kubectl get moduletemplate <module-name>-<channel>), if this is not found, we will lookup kubectl get modulereleasemeta <module-name> and take the version from the spec.channels[].version. With that we lookup the template by kubectl get moduletempalte <module-name>-<version>.

In the future, if it will be possible for the end user to install a module by version, then we could look it up by directly by kubectl get moduletemplate <module-name>-<version>. Once this is the case, we shouldn't have any old module templates not following this pattern anymore.