Update EdgeCloud_LcM.yaml

[gunjald]

Removing HELM from virtType as Helm is packaging format for k8s applications

[gainsley]

Helm needs to remain as an option here. The intent is to specify the binary type such that the system knows how to deploy it. Perhaps "virtType" should be renamed to something more appropriate.

[gainsley]

Or, alternatively we move this to a "imageType" field under "repository". Also in some cases they system may need to know if the VM image is of type QCOW2 or OVA/VMDK since underlying IaaS may not support certain file types, so the system may need to convert the image on the fly. So maybe the choices are really QCOW2/OVA/OVF/Container/Helm.

[gunjald]

Helm needs to remain as an option here. The intent is to specify the binary type such that the system knows how to deploy it. Perhaps "virtType" should be renamed to something more appropriate.

I think if we keep the "HELM" as an option then it is good to change the virtType field to indicate the correct meaning. In that case VM or Container or Helm indicate what kind of images the application comprises of. For container type of Helm it is implicit that the image is pointing to a container while VM could be QCOW2 image. In that case an alternative for virtType could be "imageType". But an issue see with including Helm alongside VM or container is that these names could suggest using a single QCOW2 or a docker container while Helm chart can contain multiple containers and the resource requirements. In that case to make a common interpretation the VM type or container type in the enum should point to an associated specification that will carry the additional details associated to the VMs or Containers that could carry the information about storage, CPU, GPU etc needed for the execution.

[nicolacdnll]

Totally in favor of keeping Helm and change virtType. Another option could be packageType which fits with all the options that Jon said - QCOW2/OVA/OVF/Container/Helm.
My opinion is purely biased by what wee see from ISV. In fact, we see more and more GA solutions packaged as Helm charts that deploy many containers.

The issue regarding Helm and resource doesn't really persist in my view. In fact, in k8s you can create a namespace with resource quotas and deploy the Helm chart in that namespace. So, also Helm charts can have the info "about storage, CPU, GPU etc needed for the execution".

[gunjald]

packageType sounds fine.

[gainsley]

I would also suggest to replace VM with QCOW2 and OVA. While it is possible for the system to detect the image type from the file using "qemu-img info", I think it's better to enumerate the supported VM image types in the enum because:

• to use qemu-img info to detect the file type, the system would need to download the file first, which may not be necessary if the user specifies the file type
• qemu-img info just reports "raw" for anything it doesn't understand, including OVA because OVA is just a tar file.
• having the supported file types in the spec makes it clear to both the user and the OP what VM image file types must be supported.

[gunjald]

I would also suggest to replace VM with QCOW2 and OVA. While it is possible for the system to detect the image type from the file using "qemu-img info", I think it's better to enumerate the supported VM image types in the enum because:

• to use qemu-img info to detect the file type, the system would need to download the file first, which may not be necessary if the user specifies the file type
• qemu-img info just reports "raw" for anything it doesn't understand, including OVA because OVA is just a tar file.
• having the supported file types in the spec makes it clear to both the user and the OP what VM image file types must be supported.

I think suggestion looks good. For now I would replace the VM with the 2 proposed options. In future we may slightly reorganize to introduce high-level categories to not mix multiple types of VM and container image formats.

[gunjald]

I propose to merge the changes as there are no further comments.

[gainsley]

Thanks!

[sergiofranciscoortiz]

Resolved conflicts with main before approving changes already approved by others.