Monitoring Console: Inconsistent documentation and behaviour of monitoringConsoleRef

未关闭
  • 哪里不对？
#1,887 0 条评论 0 个 reaction 已指派 0 人 在 GitHub 查看

还没有人认领这个 Issue。

评估

难度
4/5
预计耗时
3-5 天
新手友好度
45/100
Issue 类型
缺陷
描述清晰度
基本清楚
活跃度
活跃
技术栈
go, kubernetes
领域
backend, documentation

调研方向

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.

由索引模型根据 Issue 内容生成。

描述

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.

主要语言
Go
星标
260
派生
134
30 天内没有已合并 PR

环境准备

从这里开始

  1. 先读完整个 Issue，再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库，在一个分支上完成修改。
  4. 提交 Pull Request，并在描述里引用这个 Issue 编号。

splunk/splunk-operator 的其他 Issue

查看 splunk/splunk-operator 的全部 Issue

相似的 Issue

更多 Go Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。