[addons] Renaming of addons in order to indicate more clear the purpose of the addon

[krotz-dieter]

In order to indicate more clearer the purpose some addons need to be renamed. The proposal is to have for the addons the following structure: USECASE-IMPLEMENTATION(optional, only in case of two different implementations)

The addons would look like this with this rule:

• dashboard
• ingress-nginx
• ingress-traefik -> needs to be renamed from traefik to ingress-traefik
• gateway-nginx
• exthttpaccess
• logging
• monitoring
• kubevirt
• gpu-node
• registry
• storage-smb -> needs to be renamed to smb-share to storage-smb (later we would like to have other storage-* solutions)
• metrics-server

NEW planned for next versions:

• security
• autoscaling
• dicom
• viewer
• fhir
• ai-text
• ai-image
• ...

[jgriegershs]

See Discussion #335.

[krotz-dieter]

After discussion Discussion #335 here is a latest proposal:

• dashboard
• ingress-nginx -> needs to be renamed to ingress and merged with ingress-traefik
• ingress-traefik -> needs to be renamed to ingress and merged with ingress-nginx
• gateway-nginx -> needs to be renamed to gateway-api
• exthttpaccess
• logging
• monitoring
• kubevirt
• gpu-node
• registry
• storage-smb -> needs to be renamed to storage
• metrics-server -> needs to be renamed to metrics

The k2s addons enable ... command should get a general flag:

-i --implementation [default|implementation1|implementation2]

example: k2s addons enable ingress -i nginx for enabling the nginx implementation for the ingress addon.

Some addons can enable multiple implementations also:

-i --implementation [default|implementation1|implementation2|implementation1,implementation2] example: k2s addons enable storage -i smb,ceph