Monitoring Console: Inconsistent documentation and behaviour of monitoringConsoleRef

Đang mở
  • Có gì không ổn?
#1,887 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.

Đánh giá

Độ khó
4/5
Thời gian dự kiến
3-5 ngày
Mức phù hợp với người mới
45/100
Loại issue
Lỗi
Độ rõ ràng
Khá rõ ràng
Mức độ hoạt động
Sôi nổi
Công nghệ
go, kubernetes
Lĩnh vực
backend, documentation

Hướng nghiên cứu

Start with the monitoringConsoleRef docs in docs/operate/CustomResources.md and its CRD schema in config/crd/bases/enterprise.splunk.com_standalones.yaml, then trace how SPLUNK_MONITORING_CONSOLE_REF is populated and consumed. The issue leaves the intended same-namespace or cross-namespace behavior undecided; clarify that behavior and align the documentation, schema, and implementation so a reference works as specified.

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

Mô tả

monitoring console
Please select the type of request

Bug

Tell us more

Describe the request
The documentation and actual implementation of monitoringConsoleRef is inconsistent and the intended behavior is unclear.

Per documentation the monitoringConsoleRef is a string with the following specification:

Logical name assigned to the Monitoring Console pod. You can set the name before or after the MC pod creation.

In contrast to the object type keys licenseManagerRef and clusterManagerRef this suggests, that only references to MonitoringConsole resources within the same namespace are intended.

However, the CRDs actually implement both name and namespace keys:

 monitoringConsoleRef:
  description: MonitoringConsoleRef refers to a Splunk Enterprise monitoring
    console managed by the operator within Kubernetes
  properties:
    apiVersion:
      description: API version of the referent.
      type: string
    fieldPath:
      description: |-
        If referring to a piece of an object instead of an entire object, this string
        should contain a valid JSON/Go field access statement, such as desiredState.manifest.containers[2].
        For example, if the object reference is to a container within a pod, this would take on a value like:
        "spec.containers{name}" (where "name" refers to the name of the container that triggered
        the event) or if no container name is specified "spec.containers[2]" (container with
        index 2 in this pod). This syntax is chosen only to have some well-defined way of
        referencing a part of an object.
      type: string
    kind:
      description: |-
        Kind of the referent.
        More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds
      type: string
    name:
      description: |-
        Name of the referent.
        More info: https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#names
      type: string
    namespace:
      description: |-
        Namespace of the referent.
        More info: https://kubernetes.io/docs/concepts/overview/working-with-objects/namespaces/
      type: string
    resourceVersion:
      description: |-
        Specific resourceVersion to which this reference is made, if any.
        More info: https://git.k8s.io/community/contributors/devel/sigapi-conventions.md#concurrency-control-and-consistency
      type: string
    uid:
      description: |-
        UID of the referent.
        More info: https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#uids
      type: string
  type: object
  x-kubernetes-map-type: atomic

When the namespace key is actually used, the reference is not setup properly, as env var SPLUNK_MONITORING_CONSOLE_REF only holds the targeted name, not the namespace or the service URI like it is used for e.g. SPLUNK_LICENSE_MASTER_URL.

In contrast, the MonitoringConsole tries to automatically setup monitoring for instances in other namespaces (and fails). See issue https://github.com/splunk/splunk-operator/issues/1886

Expected behavior
Make sure that documentation and specification match and the intended behavior is specified precisely.

K8s environment
SOK 3.2.0
k8s v1.36.5

Proposed changes(optional)
Best case would be to actually implement cross-namespace references for monitoringConsoleRef. At least, make sure that all documentation and behavior is consitent.

Ngôn ngữ chính
Go
Star
260
Fork
134
Không có pull request nào được merge trong 30 ngày

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 splunk/splunk-operator

Tất cả issue của splunk/splunk-operator

Issue tương tự

Thêm issue về Go

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.