stackabletech / stackabletech/documentation

Create ADR on options for an operator to manage stackable components

Đang mở
#271 0 bình luận 0 reaction 0 người được giao Xem trên GitHub

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

Ngôn ngữ chính
CSS
Star
13
Fork
14
Merge trung bình
4 ngày 8 giờ
Pull request đã merge (30 ngày)
10

Mô tả

This was triggered to a certain extent by a discussion around OpenShift and how we cannot currently certify the secret and listener operator, because these need to be deployed a a DaemonSet, which is not supported by Operator Lifecycle Manager.

The best practice / workaround here seems to be to create an operator which in turn deploys the necessary DaemonSets and then certify that operator - which in turns allows us to specify this as a dependency for the rest of our operators.
We had similar discussions a while ago / the topic comes up every now and then, whether we want a stackable operator that is in charge of updating our components / internal configmaps etc. Sort of like a k8s internal stackablectl.

I think it is worth writing an ADR and evaluating the various options that we have to
a) solve the concrete matter of getting secret and listener operator OpenShift certifiable
b) look at this from a bit further away and consider if we need a stackable operator

We briefly discussed this in the openshift slack channel: https://stackable-workspace.slack.com/archives/C03DGUK815E/p1662631718184049 and came up with these options as an initial list (there will probably be more, this is not a conclusive list):

  1. Have Stackable operator that works somewhat analogue to stackablectl but from inside the cluster
  2. Create an operator specifically for openshift to become compliant, leave everything else as is
  3. Rework secret and listener operator minimally to simply deploy one pod which then in turn deploys the daemonset
  4. 3 but have that "one pod" be the commons operator

This is done when:

  • The ADR is approved and merged and an option was chosen
  • Follow up tickets for the chosen option have been created

Hướng dẫn đóng góp

Chưa lập chỉ mục được hướng dẫn đóng góp cho kho mã nguồn này

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.

Hướng nghiên cứu

Bắt đầu bằng việc xem lại cuộc thảo luận trên OpenShift Slack và bốn phương án được đề xuất, sau đó kiểm tra các ADR hiện có trong kho tài liệu để hiểu cấu trúc dự kiến và quy trình phê duyệt. Đánh giá các lựa chọn cho chứng nhận OpenShift và một Stackable operator có phạm vi rộng hơn, và coi công việc là hoàn tất khi một ADR được phê duyệt và merge, một lựa chọn được chọn và các ticket tiếp theo được tạo.

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

Đánh giá

Công nghệ
kubernetes
Lĩnh vực
devops, documentation, infrastructure
Loại issue
Tài liệu
Độ khó
5/5
Thời gian dự kiến
Hơn một tuần
Mức độ hoạt động
Đình trệ
Độ rõ ràng
Khá rõ ràng
Mức phù hợp với người mới
25/100

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.