Skip to content

Separate Scope resource for providers #108

@tronghn

Description

@tronghn

Ref. b2652a5:

A client without any scopes is disallowed; ideally we shouldn't even
create a Maskinporten client if the spec only defines scopes to be
exposed and none consumed.

This commit adds a default consumer scope for the Maskinporten client if
none are defined. Ideally, the "exposed scope" directive should be split out
into its own resource and reconciler rather than being tied directly to a
MaskinportenClient resource.

Other pain points with tying exposure of scopes to a single MaskinportenClient:

  • ownership becomes unclear:
    • multiple application manifests may define the same scope, but the source of truth is the last applied manifest
    • what happens if the same application in the same namespace, but in different clusters have the same exposed scope?
  • tracking desired and actual state becomes difficult (e.g. how do we determine that a scope should be deleted?)

The scopes we create via Digdirator today are also subject to some strange rules:

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething isn't working

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions