Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Namespace-scoped operators #32

Closed
10 of 11 tasks
kopf-archiver bot opened this issue Aug 18, 2020 · 0 comments
Closed
10 of 11 tasks

Namespace-scoped operators #32

kopf-archiver bot opened this issue Aug 18, 2020 · 0 comments
Labels
archive enhancement New feature or request

Comments

@kopf-archiver
Copy link

kopf-archiver bot commented Aug 18, 2020

An issue by nolar at 2019-04-21 19:12:41+00:00
Original URL: zalando-incubator/kopf#32
 

Current Behaviour

Currently, --namespace= option is used only to limit the watch-event to the objects belonging to that namespace, and ignoring objects in other namespaces.

However, the framework continues to use the cluster-wide watching calls, and cluster-wide peering objects. The peering objects are now cluster-scoped by definition (in CRD), and there are no namespace-scoped peering objects at all.

Expected behaviour

As an operator developer, if I provide --namespace=something, I expect that the operator limits all its activities to that namespace only, and does not even request for the cluster-wide objects/queries — as they can be e.g. restricted by the permissions.

If I provide --namespace=something --peering=somepeering, I expect that the namespace-scoped peering object kind is used, not the cluster-scoped one.

Use-cases

The intended use-case 1: If an operator is a part of the application's deployment, and there are few instances of the same application deployed with different versions, but isolated by the namespaces. As a particular example: running a production, staging, and maybe experimental operators of the same application in different namespaces.

The intended use-case 2: Running in a cluster with strict RBAC rules, with no access to the cluster objects, restricted to one namespace only.

Steps to Reproduce the Problem

  1. Create a RBAC service account with only the namespace permissions.
  2. Deploy any of the example operators with --namespace=default (or any other namespace).
  3. Observe how it fails on api.list_cluster_custom_object() (in queueing.py/watching.py).
    • for kopfexamples
    • for kopfpeerings

Acceptance Criteria

  • Served objects:
    • with --namespace=, it uses the namespace-scoped watching api.list_namespaced_custom_object()
    • with no --namespace=, it uses the cluster-scoped watching api.list_cluster_custom_object()
  • Peering objects:
    • KopfPeering is separated to ClusterKopfPeering & KopfPeering or NamespacedKopfPeering (keep backward compatibility if possible, but align with the existing convention of Role/ClusterRole, etc.)
    • with --namespace=, the namespace-scoped peering object is used.
    • with no --namespace=, the cluster-scoped peering object is used.
    • --peering= option only specifies the peering name, but not the listing/watching mechanics.
  • Documentation:
    • RBAC configuration and deployment pattern.
    • CLI reference page.
    • Peering page.
    • A new page for cluster-vs-namespace separation ("Features" section).
  • Tests.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
archive enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

0 participants