Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

[Feature] Separate user deprovisioning from verified tenant data purge

Đang mở
  • Có gì không ổn?
#215 0 bình luận 0 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 1 ngày

Chưa có ai nhận issue này.

Đánh giá

Độ khó
5/5
Thời gian dự kiến
Hơn một tuần
Mức phù hợp với người mới
25/100
Loại issue
Tính năng
Độ rõ ràng
Khá rõ ràng
Mức độ hoạt động
Ít trao đổi
Công nghệ
kubernetes, mongodb, postgresql, python, redis
Lĩnh vực
backend, cli, databases, devops

Hướng nghiên cứu

Bắt đầu từ bề mặt task quản trị và CLI của apache/openserverless-task, đặc biệt là deleteuser, sau đó kiểm tra quá trình reconciliation/finalization của WhiskUser và các handler dọn dẹp backend trong apache/openserverless-operator. So sánh hành vi hiện tại với contract deprovision/purge được đề xuất; được xem là hoàn thành khi có ngữ nghĩa được ghi trong tài liệu và các test tự động cho dry-run, xác nhận, retry và postcondition của backend, bao quát các service được liệt kê.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

enhancement

Feature request

Define explicit and safe lifecycle semantics for tenant removal. Today, deleting a user mixes identity deprovisioning with partial backend cleanup, while the command name suggests that all tenant data is removed.

Current behavior

Depending on the task/operator version, ops admin deleteuser <username> deletes the WhiskUser and then attempts local CLI config cleanup. The operator cleanup is not an atomic, verified tenant purge:

  • the OpenWhisk subject/auth document is removed, while tenant entities such as actions can remain;
  • Redis cleanup removes the ACL user, while keys under the tenant prefix can remain;
  • cleanup is attempted for other enabled services, but the command does not expose a reliable per-backend postcondition report;
  • recreating a tenant with the same namespace reuses the same logical identifiers and can make surviving data visible again.

In one observed environment, after delete and recreate, dozens of OpenWhisk actions and more than 1,000 tenant-prefixed Redis keys were still present. Only aggregate counts were inspected; no tenant data content was read.

This makes it difficult for an administrator to know whether the requested operation means "revoke access but preserve data" or "irreversibly erase the tenant".

Proposed command model

Introduce two distinct operations:

  1. ops admin deprovisionuser <username>

    • revoke credentials, routes and service identities;
    • preserve tenant data for recovery or retention;
    • report which resources remain.

  2. ops admin purgeuser <username> --confirm=<username>

    • irreversibly delete all resources owned by the tenant;
    • verify every postcondition before reporting success;
    • return non-zero when residual resources remain.

For compatibility, deleteuser could remain as an alias for deprovisioning with a clear deprecation/message, rather than silently changing its destructive semantics.

The proposed purgeuser command does not currently exist.

Purge contract

A purge should cover enabled tenant resources, including:

  • OpenWhisk packages, actions, triggers, rules and applicable activation data;
  • Redis keys selected by the exact authorized tenant prefix, followed by ACL user removal;
  • object storage buckets, objects and service user;
  • MongoDB/FerretDB, PostgreSQL and Milvus tenant databases, schemas or collections;
  • generated ingress/routes, static hosting resources and operator metadata.

Custom or out-of-band resources should be discovered and reported, but not deleted blindly.

Safety and operability

  • Add --dry-run to inventory affected resources without mutation.
  • Require an explicit confirmation that includes the namespace name.
  • Treat already-missing resources as success so retries are idempotent.
  • Produce a structured per-backend summary with deleted, preserved, skipped, failed and residual states.
  • Verify postconditions for each enabled backend.
  • Avoid logging credentials, secrets or the complete WhiskUser specification.
  • Optionally support retention/preserve flags and a pre-purge backup hook.

Acceptance criteria

  • Deprovisioning and purge have documented, unambiguous semantics.
  • Recreating a deprovisioned namespace can intentionally recover preserved data.
  • Recreating a successfully purged namespace starts empty.
  • Partial failures return non-zero and identify the affected backend/resources.
  • Re-running purge after partial failure completes safely.
  • Dry-run and confirmation behavior have automated tests.
  • Tests cover OpenWhisk entities, Redis prefixed keys and each optional data service enabled in CI.

Affected components

This likely spans:

  • apache/openserverless-task admin task and CLI surface;
  • apache/openserverless-operator WhiskUser reconciliation/finalization and backend cleanup handlers;
  • downstream task distributions that expose ops admin deleteuser.

Environment where observed

  • ops CLI: 0.9.1-2607121109.dev
  • task branch: apache/openserverless-task:0.9.1
  • operator image: apache/openserverless-operator:0.1.0-incubating.2512151437
Ngôn ngữ chính
Python
Star
576
Fork
29
Merge trung bình
3 giờ 26 phút
Pull request đã merge (30 ngày)
12

Chuẩn bị môi trường

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của apache/openserverless

Tất cả issue của apache/openserverless

Issue tương tự

Thêm issue về Python

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.