Monitoring Console: Inconsistent documentation and behaviour of monitoringConsoleRef

Aperta
  • Qualcosa non va?
#1,887 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
45/100
Tipo di issue
Bug
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
go, kubernetes
Ambito
backend, documentation

Direzione di ricerca

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.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

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.

Lingua principale
Go
Stelle
260
Fork
134
Nessuna PR unita negli ultimi 30g

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di splunk/splunk-operator

Tutte le issue di splunk/splunk-operator

Issue simili

Altre issue su Go

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.