oam-dev / spec

Open Application Model (OAM).
https://oam.dev
Other
3.04k stars 246 forks source link

Support scopes as an application configuration spec level attribute #412

Open kminder opened 3 years ago

kminder commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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

captainroy-hy commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

@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?