Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

NiFi v2 Behind Openshift Route

Aperta
#750 9 commenti 1 reazione 0 assegnatari Vedi su GitHub

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
35/100
Tipo di issue
Bug
Chiarezza
Da chiarire
Stato di attività
Ferma
Stack tecnologico
kubernetes
Ambito
infrastructure

Direzione di ricerca

Inizia tracciando il modo in cui l’operatore genera i valori di StatefulSet e ConfigMap per NODE_ADDRESS e nifi.properties, quindi confronta il comportamento di NiFi v2 con la route pass-through di OpenShift segnalata e l’errore Invalid SNI. Il lavoro è completato quando viene confermato se è possibile configurare un indirizzo pubblico compatibile con la route senza che questi valori generati dall’operatore vengano sovrascritti.

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

Descrizione

Perhaps this is just a request for guidance (if I am wrong), but I can't work out how to gracefully get a NiFi v2 container online behind an Openshift Route because of the "Invalid SNI" issue.

This issue (697) gave some hints using an ingress, but I haven't found a way using routes.

From tracing through the current solution what I think is happening is:

  • The operator creates a StatefulSet which forces NODE_ADDRESS to exist during startup, but builds the value itself based on a internal address.
  • This is overwriting attempts to set NODE_ADDRESS using a ConfigMap.
  • The nifi.properties loads NODE_ADDRESS into both nifi.cluster.node.address and nifi.web.https.host, with the whole file being drawn from a ConfigMap.
  • Attempts to edit nifi.properties in the ConfigMap are overwritten by the operator.
  • Attempts to edit the StatefulSet to adjust the CLI setting NODE_ADDRESS are overwritten by the operator.
  • TBF I expected those just noting them as opposed to... attempts to add new environment variables into the ConfigMap are not overwritten.

Would it be as simple as allowing the nifi.web.https.host to be overwritten by a new variable, like PUBLIC_ADDRESS that we can set in the ConfigMap? I gather this is what is causing Jetty to reject the traffic originating from the public route.

For NiFi v1.27.0, using a pass-through route 'just worked', but either upgrading or a fresh install of v2 are all failing. Unclear to me why the internal pod wants to perform this validation... and TBH I would love to disable it, but maybe it adds value. My last gasp is going to track down an admin that knows cert-fu and trying to switch to a Re-Encrypt route, but not looking forward to that.

Lingua principale
Rust
Stelle
48
Fork
12
Merge medio
11h 26m
PR unite (30g)
10

Guida per i contributori

Nessuna guida per i contributori indicizzata per questo repository

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 stackabletech/nifi-operator

Tutte le issue di stackabletech/nifi-operator

Issue simili

Altre issue su Rust

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.