New application entity (v0.3.0)

[dhiguero]

What does this PR do?

• Updates the specification of the Application entity according to the v0.3.0 spec proposal.

Where should the reviewer start?

• Review 7.application.md for most changes.

What is missing?

Any background context you want to provide?

What are the associated tickets?

• OAM Spec v0.3.0 Working Draft - #443
• Tasks for v0.3.0 - #445

Questions

• Section Component instances and revisions of component has been updated with components, but this is closely related to how the runtime is expected to operate. Is this still the intended behavior? I think it is necessary to create a component instance since we are referencing components by type and assigning them a new name, which I suppose will be used to name the component instance.

[ghost]

All CLA requirements met.

[ghost]

Thank you for your submission, we really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.

❌ dhiguero sign now
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

[hongchaodeng]

lgtm after nit

[hongchaodeng]

What's this line?

[hongchaodeng]

Maybe leave a comment here indicating that the name of the trait will be the same as the component?

[dhiguero]

Hi! I have been testing deploying an Application in Kubevela following the proposed changes and it seems that there is a mismatch related to how scopes are specified. In the previous version, we used a scopeRef as:

      scopes:
        - scopeRef:
            apiVersion: core.oam.dev/v1alpha2
            kind: HealthScope
            name: app-health # An application level health scope including both components.

However it seems that the new runtime expects a map as:

      scopes:
        "healthscopes.core.oam.dev": "app-health"

@resouer, @hongchaodeng Could you please check which one is the expected one? I will update the example accordingly before merging the PR.

[wonderflow]

In application, I hope we can use this way as it's more convenient:

      scopes:
        "healthscopes.core.oam.dev": "app-health"

The healthscopes.core.oam.dev will refer to a ScopeDefinition which will refer to the information:

            apiVersion: core.oam.dev/v1alpha2
            kind: HealthScope

[resouer]

+1 to @wonderflow 's approach. Note that this also implies the ScopeDefinition is named as healthscopes.core.oam.dev and references the real resource schema (HealthScope GVK), similar to workload definition.

[dhiguero]

@resouer , @wonderflow I have uploaded the changes related to the scope.

[dhiguero]

New revision available. Thanks @kminder for the awesome review.

[kminder]

Approved

[wonderflow]

Thanks, great job!