Open kminder opened 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.
Yes, totally agree! We also have this plan to add.
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.
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
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?
@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?
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.
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.
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.