Support scopes as an application configuration spec level attribute

[kminder]

In the current OAM spec (v0.2.1) scopes supported as an attribute of component. I believe that the most common use case for a scope will be to apply the scope to all components of a given application configuration. The current schema will require that the scope be duplicated for every component within the application configuration. While this will work it will be annoying to author and maintain.

Below is a sketch of what this might look if scopes was also supported within application configuration's spec.

apiVersion: core.oam.dev/v1alpha2
kind: ApplicationConfiguration
metadata:
  ...
spec:
  scopes:
    - scopeRef:
        ...
  components:
    ...

Having made this suggestion there is one issue that would need to be addressed. Applying a scope to all components may be desirable but being able to exclude/override a few components may be desirable as well. Since only once scope reference for the same GVK is allowed, overrides would be straight forward. However "opting out" of a scope for a specific component is not. A "special" scope instance name of NONE is used below as a possible "opt out" mechanism.

apiVersion: core.oam.dev/v1alpha2
kind: ApplicationConfiguration
metadata:
  ...
spec:
  scopes:
    - scopeRef:
        apiVersion: some-scope-group/some-scope-version
        kind: SomeScope
        name: some-scope-instance
  components:
    - componentsName: some-component
        scopes:
          - scopeRef: 
              apiVersion: some-scope-group/some-scope-version
              kind: SomeScope
              name: NONE
            

In other issues I see scopes referenced within application configuration's spec. It isn't clear if this support once existed but has been removed.

[resouer]

apply the scope to all components of a given application configuration.

Fully +1 to solve this, it has been annoyed us for a while.

[wonderflow]

Yes, totally agree! We also have this plan to add.

[captainroy-hy]

While applying AppConfig level Scopes to all components, is it possible to allow assign specific Components with specific Scopes, just like how the current implementation of Scope works? That would make the enhancement backward compatible.

If so, furthermore, Component level Scope assignments should have higher priority than AppConfig level ones when it comes across allowComponentOverlap=false Scopes.

[wonderflow]

is it possible to allow assign specific Components with specific Scopes, just like how the current implementation of Scope works?

Of course, and it will overwrite what specified in AppConfig level scopes if there's conflict.

If so, furthermore, Component level Scope assignments should have higher priority than AppConfig level ones when it comes across allowComponentOverlap=false Scopes.

Yes

[kminder]

I agree that the component level scope reference should override the application level scope reference. So yes I believe this would be backwards compatible. Do others have proposals for overriding the application scope reference with NO scope reference?

[resouer]

@kminder I personally prefer a specific field to fix this instead of a special scope, for example:

apiVersion: core.oam.dev/v1alpha2
kind: ApplicationConfiguration
metadata:
  ...
spec:
  scopes: # maybe `globalScopes:`?
    - scopeRef:
        apiVersion: some-scope-group/some-scope-version
        kind: SomeScope
        name: some-scope-instance
  components:
    - componentsName: some-component
        scopes:
          - scopeRef: 
                apiVersion: some-scope-group/some-scope-version
                kind: SomeScope
                optout: true

It could be even neater if we leverage definition object of scope:

apiVersion: core.oam.dev/v1alpha2
kind: ScopeDefinition
metadata:
  name: somescope # type of this scope, for example: healthscope
spec:
  definitionRef:
    name: healthscopes.core.oam.dev
  workloadRefsPath: spec.workloadRefs
  allowComponentOverlap: true

apiVersion: core.oam.dev/v1alpha2
kind: ApplicationConfiguration
metadata:
  ...
spec:
  scopes: # maybe `globalScopes:`?
    - scopeRef:
        type: somescope # the name of its scope definition object
        name: some-scope-instance
  components:
    - componentsName: some-component
        scopes:
          - scopeRef: 
                type: somescope # the name of its scope definition object
                optout: true

WDYT?