dba_qcfilter should be disabled by dfault

[dcesari]

Json plugin has dba_qcfilter enabled by default; dba_qcfilter may take a lot of cpu time and it cannot be disabled (-q skip) by arkiweb interface, so it is dangerous on a public arkiweb server with json plugin. Moreover not all bufr dataset are suitable for dba_qcfilter quality control, so it would be reasonable to either disable it by default in the json postptocessor or allow the system administrator to disable it without touching the package files.

Another similar but less serious issue is the geojson format (this one controllable by web interface) which is very verbose and can result in huge downloads even for small datasets.

[edigiacomo]

We could create a configuration file in /etc/arkimet-postprocess-json to set the default behaviour. However, disabling some options means that the postprocessor could be inconsistent with the Arkiweb interface (e.g. what happens when a user set the geojson format in Arkiweb interface and this option is disabled in the postprocessor?).

[pat1]

I suggest to have two postprocessor for json, one with dba_qcfilter enabled an the other no. We can choose plugin on dataset base. Or we can find other solution to enable dba_qcfilter on dataset base. User do not have to disable dba_qcfilter on standard observation data.

[dcesari]

Yesterday i faced again this problem after upgrade, I propose to add a second selector in arkiweb.js to set the argument -q skip|none|preserve to json. BTW "skip" for me is misleading (skip quality control or skip data?) maybe "eliminate|preserve|none" ?

[edigiacomo]

Moreover not all bufr dataset are suitable for dba_qcfilter quality control, so it would be reasonable to either disable it by default in the json postptocessor or allow the system administrator to disable it without touching the package files.

Or we can find other solution to enable dba_qcfilter on dataset base. User do not have to disable dba_qcfilter on standard observation data.

I propose to add a second selector in arkiweb.js to set the argument -q skip|none|preserve to json.

To sum up, there are two issues to solve:

1. The user can set the quality control option (from arkiweb GUI too) or the option -q is removed from the plugin.
2. The default value is hard-coded in the plugin or it can be set by the administrator. In the latter case, the default value is global or depending on the dataset.

BTW "skip" for me is misleading (skip quality control or skip data?) maybe "eliminate|preserve|none" ?

I agree, skip is quite ambiguous.

[dcesari]

Si, più o meno è così, passo all'italiano, schematizzo la mia visione in una tabella, le 2 issue sono i due assi della tabella, correggimi se sbaglio:

X	l'utente non può cambiare il default, nota 1	l'utente può cambiare il default a linea di comando e curl	l'utente può cambiare il default anche da web interattivo, nota 2
default prefissato per tutti i ds	NO	al momento è così, NO	SI, nota 4
default prefissato per tutti i ds, modificabile in /etc/..., nota 1	NI, nota 5	NI, nota 6	SI
default dipendente da ds, nota 3	SI	SI	SI

nota 1. è una modifica poco invasiva in arkimet-postprocessor-suite nota 2. è una modifica poco invasiva in arkiweb, modifiche limitate in arkimet.js nota 3. richiederebbe interventi forti e molto ad-hoc a livello di codice arkimet (prevedere una chiave di config specifica per qc in postprocess json) nota 4. più delle altre questa combinazione richiede che la cosa sia documentata per l'utente in modo da guidarlo nella scelta giusta nota 5. NI perché è restrittivo, impone che su un server tutti i ds siano di tipo noQC o siQC nota 6. come nota 5, ma più accettabile, la restrizione è solo a livello di interfaccia web

[dcesari]

Secondo me è ragionevole implementare "l'utente può cambiare il default anche da web interattivo" + eventualmente "default prefissato per tutti i ds, modificabile in /etc/..."

[edigiacomo]

Ok. Peraltro, pensandoci meglio avere un default dipendente dal dataset non saprei nemmeno come implementarlo senza modifiche ad arkimet, perché i postprocessatori non hanno informazione del nome del dataset - e non so nemmeno quanto sarebbe facile implementarlo.

@pat1 se la proposta di Davide è per te accettabile, applico le modifiche.

[edigiacomo]

Questa issue è stata chiusa per inattività. Nel caso in cui sia un argomento ancora rilevante, si prega di riaprirla con una motivazione che tenga conto delle modifiche applicate nel corso degli anni al progetto.