Distribuzione FUSS » Octofuss » octonet

Solo per escludere l'ovvio, visto l'errore generato, quegli utenti non esistevano gia' quando hai provato la procedura di importazione?

Ok, grazie, verifichiamo.

Potete riprovare dopo aver aggiornato octofussd (8.0.17-1) e soprattutto octonet (0.2.3-1) ponendo l'attenzione su queste cose:

• Che gli utenti che si sta cercando di importare non esistano già (questo accade anche se si fa l'importazione due volte con lo stesso file CSV. La prima volta funziona correttamente, la seconda volta no)
• Il problema degli utenti già esistenti si può presentare anche nel caso in cui siano due persone a usare l'interfaccia: la prima che fa l'import avrà l'esito positivo, la seconda che lo fa (anche un secondo dopo) avrà l'esito negativo.
• Che le colonne siano selezionate correttamente prima di iniziare l'import (dato che l'importer cerca di fare automaticamente l'assegnamento delle colonne, ma può sbagliare)

• La home nei miei test in locale adesso viene importata correttamente (problema segnalato nel ticket)
• Non veniva importato il controller group, ora invece nei miei test in locale questo viene importato correttamente

octonet 0.2.3-1
octofussd 8.0.17-1

Questo problema è ancora diverso, sembra che ci sia stato un import parziale degli utenti e che poi la connessione si sia interrotta/resettata per qualche motivo.

Indago.

Rivoluzionato il backend dopo analisi con Simone e Christopher riguardo anche a octofussd (c'è un grosso problema sul numero delle connessioni create verso LDAP), e di conseguenza anche il frontend è cambiato.

• Ora il POST del CSV è fatto via AJAX
• E' stata scritta una nuova view, e quella vecchia è diventata una TemplateView dato che non gestisce POST ma deve soltanto renderizzare un template, e il suo codice di form_valid() è stato usato come base per il codice di post() della nuova view AJAX
• La view di backend ovviamente inizia a creare gli utenti solo se il CSV non ha problemi (cioè se è stato configurato correttamente l'import rispetto alle colonne da importare, se gli utenti da importare non esistono, se i gruppi a cui aggiungere gli utenti esistono già, eccetera).
• In presenza di anche un solo errore e non viene importato nessun utente, per evitare import parziali (come era già anche prima, del resto)
• La view di backend AJAX in caso di successo invia una StreamingHttpResponse con la percentuale di utenti creati rispetto al totale degli utenti da importare
• Se tutto è ok, l'import inizia e viene mostrata una finestra modale con alcuni messaggi (è FONDAMENTALE non chiudere la finestra modale, né la finestra del browser, finché non viene dato il messaggio di importazione effettuata, altrimenti in questo caso sì che ci saranno import parziali. Il processo può impiegare davvero molti minuti, dipendentemente dal numero di utenti importati)
• La percentuale di completamento dell'import inviata via StreamingHttpResponse viene usata per aggiornare una barra di progresso nella finestra modale.
• Alla fine dell'import viene mostrato, sempre nella finestra modale, un messaggio di fine processo e un bottone che rimanda alla lista utenti, dove si potrà appurare che l'import è riuscito.

• In caso di errori la finestra modale viene nascosta e vengono mostrati gli errori, senza un reload della pagina (ma modificando il DOM via javascript).
• I messaggi di errore hanno la stessa forma che avevano prima
• Prima vengono considerati gli errori di conformità del form (ad esempio non si può chiedere di importare Full Name e uno o entrambi Name e Surname), dato che questi controlli non necessitano di LDAP
• Se il form è ok, vengono effettuati i controlli lato LDAP (gruppi non esistenti, utenti esistenti, ecc...)
• A ogni segnalazione di errore, il form resta compilato e funzionale, in questo modo è possibile fare le correzioni e procedere all'upload rapidamente (ad esempio se l'unico errore è "Gruppo non esistente", si può aprire un secondo tab in cui si crea il gruppo, poi tornare al tab dell'upload e premere Upload senza dover rifare tutta la procedura di selezione file e ordinamento colonne)

Nel frattempo sono state aggiunte alcune cose (ad esempio il controllo dell'esistenza del gruppo controller, che prima non veniva effettuato esplicitamente), e corretti alcuni particolari qua e là (typo, eccetera)

Codice pushato nel branch t231 e NON mergiato in master.

Io ho modificato il codice di octonet, il cui pacchetto quindi è da rifare.

Uploadati i pacchetti

• octofussd 8.0.19
• octonet 0.2.5

che includono tutto il fix della procedura di importazione.

L'import è sempre parziale, anche riducendo il numero degli utenti da importare.
Allego il cvs e output di octofussd.log.

root@serverfuss:~# dpkg -l octonet
Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) ||/ Name Version Architecture Description
+++-==============-============-============-=================================
ii octonet 0.2.5-1 all OctoNet
root@serverfuss:~# dpkg -l octofussd
Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) ||/ Name Version Architecture Description
+++-==============-============-============-=================================
ii octofussd 8.0.19-1 all server for remote computer lab ad

Michael cosa vedi nella finestra del browser? Si apre il dialog con la progress bar, poi quando si ferma? vedi errori o qualcosa del genere? Perche' guardando il log che hai allegato, si vede che non riceve piu' richieste, come se la finestra e/o il browser fossero stati chiusi, oppure si sia lasciata la pagina con il dialog della progress bar.

allego lo screenshot.
Riallego il file cvs.
Riallego octofussd.log
l'import sembra andare a buon fine, nessun errore (all users where imported!)

Non so se così si possa fare, vista la StreamingHttpResponse.

Ho provato a wrappare la creazione e return della StreamingHttpResponse in un try, con la restituzione di una normale JsonResponse nell'except, contenente il messaggio dell'eccezione e gli utenti importati fin lì, ma non viene catchata/restituita, probabilmente perché la Streaming appena inizia a venir inviata poi impedisce di fare return di altro.

Continuo l'indagine e gli esperimenti

Ok, aggiornami dei risultati.

• Incapsulata una specie di protocollo all'interno dello streaming
• Gli errori di validazione sul form (ad es. username non scelto tra le colonne da importare) e sul CSV (ad es. utenti già esistenti) sono rimasti con la stessa gestione precedente
• Il nuovo errore (cioè l'eccezione nel backend durante l'import quando tutto il resto è ok (colonne scelte correttamente e nessun utente duplicato)) viene gestito per forza diversamente
• users_generator() è tutto dentro un try: [...] except Exception as e: in modo che prenda su qualsiasi eccezione. In questo caso invia una stringa JSONabile contenente status="error", il testo dell'eccezione, la percentuale, e gli utenti correttamente importati fino a quel punto
• Questa viene presa dal frontend, parsata in un JSON, e usata per compilare il template con un messaggio di errore che indica il problema nel backend, il testo dell'eccezione, e l'elenco degli utenti correttamente importati (così in questo modo l'utente può rimuoverli dal CSV e procedere con una nuova procedura di import, se è il caso.

• Mostrare l'elenco degli utenti non importati era più problematico
• Questo mi è sembrato (anche con il supporto di Enrico) l'unico workaround per dare una UX un pochino usabile e chiara, visto il limite intrinseco di HTTP e StreamingHTTPResponse (Una volta che la streaming inizia, dà già 200 e non si può far restituire una response diversa a quel punto).

Dai miei esperimenti/test mi pare che sia possibile fare un po' tutto: import completamente corretti, import parziali per eccezione (c'è il raise commentato nel codice della view, se serve), prova di errori per utenti già presenti, o per errori di validazione form (cioè errori di scelta colonne da importare), anche uno di seguito all'altro (cioè provare import erronei dopo import corretti o viceversa, ecc...)

Codice pushato in t231 e non mergiato.

Pubblicato octonet 0.2.7 che include anche questo fix.

Portroppo anche dopo l'ultimo aggiornamento la situazione non è cambiata.
Provo ad importare i 200 utenti da file import_1.cvs, la statusbar non raggiunge 100%, octonet riporta di aver importato tutti gli utenti.
octofussd.log riporta 115 utenti creati e non da nessun errore.

Versioni installati:
octonet 0.2.10-1
octofuss 8.0.28-1

riallego il il file di importazione, octofussdlog

Attualmente con le versioni octofussd 8.0.30-1 e octonet 0.2.10-1 non riusciamo a riprodurre il problema, abbiamo importato il file CSV allegato a questo messaggio (con quasi 1300 utenti) senza problemi.

Ho fatto un test con il CSV fornito da Mark. Allego il mio octofussd.log.

Ho pubblicato nuova versione del pacchetto octonet, 0.2.13. Dopo aver riprodotto il problema, con questa soluzione non si ripresenta. Non e' un problema dell'applicazione, ma del demone che la fa girare (gunicorn).

Quando puoi, puoi verificare con questa nuova versione?

Ho fatto l'aggiornamento di octonet sul nostro server ed ho testato con successo l'upload di tutte le 1292 utenze dal file https://work.fuss.bz.it/attachments/download/686/test_import.csv

Il ticket per me potrebbe essere chiuso. Lo passo comunque a Michael se vuole provare a fare un test anche lui prima della chiusura definitiva.

Grazie.

Chiudo il ticket, la problematica durante l'import non si ripresenta più.

Grazie