[Proposal] Changes to application package definition

[Haishi2016]

1. The proposed object schema follows Kubernetes CRD style. However, the metadata section contains a number of extra fields (like author, icon, etc.) that are not compatible with Kubernetes object metadata schema. Propose to move these attributes under an "annotations" attribute (like in Kubernetes object metadata).

2. Both helm-chart and docker-compose are marked required attributes. This puts an unreasonable burden on developers because it forces an app developer to redeclare the application in two different formats. Proposal to keep them as optional. This section in theory should also be extensible so that other package formats can be used.

3. In the parameter section, schema and dataType are two separate fields. Propose to merge them into one schema field to reduce possible errors that a user choose a schema that is incompatible with a dataType - such as "maxLength" won't make sense for a boolean value.

4. In connection with item 2 above, the appliesTo attribute probably shouldn't be necessary.

5. Propose calling "value" "defaultValue" in parameter definition, because they are default values.

6. I guess the select validation rules apply only to arrays. Can it be used in combination with data type validation rules? If we mix multiple rules together it will be hard to parse, maybe to use an explicit "rules" collection under schema.

7. Possible sources of app definition include "local", "http", or "git", while "oci" is also used for hosting Helm charts in OCI registries. Propose to allow "oci://" protocol.

8. There's no way to supply authentication info for a private repo. Propose to add definitions to allow authentication to private Git repo, Oci registry or HTTP servers.

9. When an application package definition is served or retrieved from a URL, it needs to be packaged as a file such as a tar file. The spec should specify what are the supported package/compression formats.

[phil-abb]

1. The proposed object schema follows Kubernetes CRD style. However, the metadata section contains a number of extra fields (like author, icon, etc.) that are not compatible with Kubernetes object metadata schema. Propose to move these attributes under an "annotations" attribute (like in Kubernetes object metadata).

In these other proposals (issue and issue) we've changed the definition to not look like a CRD as well as updated the metadata section.

2. Both helm-chart and docker-compose are marked required attributes. This puts an unreasonable burden on developers because it forces an app developer to redeclare the application in two different formats. Proposal to keep them as optional. This section in theory should also be extensible so that other package formats can be used.

I think this is addressed with the changes in this PR. If you still think improvements can be made please comment on the other PR and we can make additional changes.

3. In the parameter section, schema and dataType are two separate fields. Propose to merge them into one schema field to reduce possible errors that a user choose a schema that is incompatible with a dataType - such as "maxLength" won't make sense for a boolean value.
4. In connection with item 2 above, the appliesTo attribute probably shouldn't be necessary.

This is still valid and should be considered as part of the discussion for the proposal under this issue

5. Propose calling "value" "defaultValue" in parameter definition, because they are default values.

This is addressed in the proposal under this issue.

6. I guess the select validation rules apply only to arrays. Can it be used in combination with data type validation rules? If we mix multiple rules together it will be hard to parse, maybe to use an explicit "rules" collection under schema.

The idea is that this would allow for either a single value (string, bool, int, etc.) or multiple values (array). I would think this would be a single rule because you provide the customer with the only options they can choose in the select list which all have to be the same data type. I guess the extension of this would be allowing them to either select from a defined list or provide their value which makes it more complex. We should discuss this more.

7. Possible sources of app definition include "local", "http", or "git", while "oci" is also used for hosting Helm charts in OCI registries. Propose to allow "oci://" protocol.

I think this is something that needs to be discussed/refined. With the updated proposal in this PR we've changed how things are defined and it talks about using "oci://" but we may need to allow other formats such as "https".

8. There's no way to supply authentication info for a private repo. Propose to add definitions to allow authentication to private Git repo, Oci registry or HTTP servers.

Agreed, I added a note to the upper part of the page in this PR that we need to cover this when we start doing the security review because it will be needed.

9. When an application package definition is served or retrieved from a URL, it needs to be packaged as a file such as a tar file. The spec should specify what are the supported package/compression formats.

I think this is something that needs to be discussed further with the working group. Right now the idea is to use a GitOps approach for the WOS to pull in the application definition package from the application vendor. If we stick with this I'm not sure if it's better to leave it unpackaged or to package it up. If it's not packaged up it would allow the WOS to see what specifically changed when there are updates if this is something that makes sense to do.