Problemi con Migrate_from_s3

Contribuisci Bug
1

When migrating from S3 to local storage, we see a number of issues.

The main issue is that the migrate_from_s3 rake task is not taking the Uploads table as a starting point, but the posts. This causes it to skip a lot of uploads which are being left on S3.

  • uploads used as logo’s because they are not referenced in a post
  • uploads for avatars because they are not referenced in a post
  • uploads that are (for some reason) referenced by their CDN URL in raw because they do not match the regex that is being used to identify the uploads
  • uploads that are on non-AWS S3 storage because they do not match the regex because it requires amazonaws in the URL
  • uploads that for some reason do not match the second, different regex (we’re seeing this with non-image uploads like mp3 files, not sure why this is happening)
2 Mi Piace
How to turn off S3 storage?
Upload remapping is a bit too enthousiastic
Set up file and image uploads to S3
Rake uploads:migrate_from_s3 fails
MKJ's Opinionated Discourse Deployment Configuration
Disabling CDN & S3, returning to local storage for images - best practice?
2

We’re working on improving the way we associate uploads to posts (by using the upload:// scheme) that will make these storage migrations much more bulletproof. There’s little point to fixing these rake tasks before that’s done.

7 Mi Piace
3

Recentemente ho aperto una nuova PR per consentire la migrazione di un numero minore di post alla volta (ad esempio, testandone uno alla volta) e ho aggiunto dei test per l’attività.

Mi sembra sensato iniziare con i post, dato che si desidera rigenerare i post per aggiornare l’URL nel contenuto del post dopo ogni migrazione; migrare tutti gli allegati e poi avviare le rigenerazioni lascerebbe il sito molto rotto per potenzialmente molto tempo in caso di siti di grandi dimensioni (devo migrare circa 100 GB da S3 a locale, quindi mi interessa). Tuttavia, quanto ho scritto potrebbe aiutare a iniziare a scrivere un’attività migrate_uploads_from_s3 da eseguire dopo migrate_from_s3 per pulire gli allegati che non facevano parte dei post.

@zogstrip Qual è lo stato attuale di “Stiamo lavorando su…” — è ancora in evoluzione o questa migrazione merita ora attenzione?

5 Mi Piace
4

Abbiamo svolto molto lavoro nell’area dei caricamenti per garantire associazioni migliori tra post e caricamenti.

Questi task di migrazione possono essere migliorati a piacere :+1:

2 Mi Piace
5

Scoprirò se vale la pena dedicare tempo all’esplorazione dei caricamenti non post dopo aver potuto utilizzare i caricamenti in batch per migrare il mio sito durante gli orari di chiusura! :smiling_face: Grazie per la revisione della PR!

1 Mi Piace
6

Ho due cose da affrontare di seguito: la prima è che il limite è utile ma si applica solo allo spazio di ricerca; successivamente voglio poter specificare un numero massimo di post da modificare. Quindi aggiungerò un numero massimo di post da modificare, oltre a un limite per la query.

Inoltre, quando si specifica max, ha senso essere espliciti su ciò che viene elaborato a scopo di debug, quindi vorrei rendere l’output verboso se max non è nil — questo permetterà agli utenti di validare il processo prima di procedere, dato che questo è il caso d’uso principale di questo lavoro.

Penso che specificherò max come primo argomento e un limite opzionale come secondo, perché in realtà max è la cosa più importante; il limite serve solo a rendere più economica l’esecuzione “un ping alla volta”.

La seconda cosa riguarda i non-upload: gli upload. Circa un anno fa, ho provato a caricare un video sul sito Discourse a cui stavo aderendo, mentre ero confuso nel cercare di capire come scrivere la migrazione da Google+ a Discourse, e ho visto che ciò che era stato scritto era https://#{SiteSettings.absolute_base_url}/original/3X/b/a/ba9e06ebc2f4397f26793bb5cd4e169308dd371d.mp4

Oggi, quando carico un video, ottengo qualcosa del tipo ![file_example_MP4_480_1_5MG|video](upload://caJ9ykkpshw3PFK4464VUIPWJ4l.mp4).

Almeno nel mio test più recente, migrate_from_s3 ha completamente storpiato quegli URL, rendendoli non più nemmeno degli URL validi, quindi questo va assolutamente corretto. Poi, penso che in pratica questo compito abbia poche probabilità di incontrare ![testo](non-upload-url-to-migrate), quindi come primo approccio vorrei semplicemente aggiungere la sintassi markdown del link attorno al protocollo magico upload, piuttosto che far gestire entrambi i casi alla regex, rendendola di conseguenza ancora più difficile da leggere. Potrei però cambiare idea su questo punto.

Sembra che il tag video o audio venga aggiunto in JavaScript tramite una corrispondenza regex, quindi dovrò copiare le regex da app/assets/javascripts/discourse/app/lib/uploads.js all’interno del task per identificarle correttamente. Includerò l’origine delle regex in modo che la prossima persona che le trova sappia da dove aggiornarle. :stuck_out_tongue:

…

Stasera ho trovato un po’ di tempo per lavorare su questo e ho già una bozza di PR in corso. Non è ancora completata; so che ci sono ancora dei bug. Non credo di aver modificato alcun comportamento per gli URL del pseudo-protocollo upload: (normali per le immagini) fino a questo punto, anche se ho aggiunto un controllo di coerenza.

Con le modifiche in questa PR, ho migrato con successo sia i normali upload del pseudo-protocollo upload: che i video attualmente referenziati esplicitamente tramite S3 (nel mio caso, DigitalOcean Spaces). Sto usando questo per modificare un solo post alla volta con questo comando:

bin/rake uploads:batch_migrate_from_s3[1,1000]

Nota che questo non andrà oltre i primi 1000 post restituiti in modo piuttosto casuale dalla query al database; il limite basso serve solo per velocizzare la query mentre si migra un solo post alla volta, si verifica il corretto comportamento di quel post e poi si ricomincia per trovarne un altro. Questo comando funziona in questo modo solo con la PR su cui sto lavorando attualmente!

…

Continuo ad aggiungere output diagnostico mentre lavoro su questo, e sto iniziando a pensare che sia importante non solo per lo sviluppo. Sto riscontrando molti fallimenti temporanei di download da DigitalOcean Spaces, dove alcuni ma non tutti i download in un post vengono migrati, il che nell’originale stampa solo un . e continua, per poi dire Done, ma in realtà il task non sarà completato. Ho dovuto fare circa cinque o sei passate su un solo post prima che venissero migrati tutti i file. (Non stavo contando perché pensavo di stare debuggando un bug locale all’inizio.) Mi aspetto di dover eseguire questa migrazione ripetutamente con lo stesso limite finché i diagnostici non saranno puliti. Pertanto, sto rendendo la stampa verbosa del progresso attiva solo se max è impostato, ma stampando messaggi di avviso utili in ogni caso.

Al momento, sto usando questo hack per i download intermittenti falliti da Discourse Spaces, che nella pratica ha migliorato enormemente il mio tasso di successo (3 tentativi sono stati completamente sufficienti su centinaia di post migrati finora).

https://github.com/johnsonm/discourse/commit/7dfac12a2ea6ec04ba4e0616b4e0dbd1d806cff7

Inoltre, ho scoperto che in qualche modo siamo finiti con video più grandi del limite che avevo impostato quando ho importato da Google+ — ho dovuto aumentare temporaneamente sia SiteSettings.max_image_size_kb che SiteSettings.max_attachment_size_kb mentre facevo migrazioni one-shot di alcuni video troppo grandi, di cui non è chiaro come siano finiti sul sito, ma non voglio romperli ora… Non so se il bug che permetteva upload di dimensioni eccessive fosse nel mio script di importazione, in Discourse, o semplicemente nella mia memoria di quali modifiche ho apportato alle impostazioni nel tempo. :wink:

Poiché gran parte di ciò che sto migrando proviene da un’importazione da G+, alcuni dei miei post hanno fallito le convalida attuali. Ho ricevuto alcuni errori Unhandled failure: Validation failed: Sorry, new users can only put one image in a post e inizialmente non ho capito perché non si ripetessero. Si è scoperto che gli upload sono stati spostati con successo in locale e tutti utilizzavano il pseudo-protocollo upload:, quindi il raw non è cambiato. Tuttavia, post.save! falliva comunque con quell’errore durante le convalide, impedendo a post.rebake! di essere eseguito, quindi ho alcuni post su 30K con immagini che devono essere ribakeati; purtroppo, non ho traccia di quali siano quei post. Ora sono passato a post.save!(validate: false) come altra soluzione, quindi questo particolare problema non dovrebbe ripetersi. Sono molto contento di aver fatto sì che la migrazione si interrompesse sugli errori non gestiti, altrimenti avrebbe potenzialmente causato molti più danni di qualche solo post.

…

Per mantenere il mio sito utilizzabile, inclusa la consegna delle notifiche, durante l’esecuzione della migrazione, non voglio intasare le code di Sidekiq. So che nominare le cose è uno dei due problemi più difficili nell’informatica, insieme all’invalidazione della cache e agli errori di off-by-one, ma propongo DISCOURSE_MIGRATION_MAX_ENQUEUED come variabile d’ambiente per indicare quanti slot totali della coda (non slot di lavoro) sono consentiti come riempiti quando si procede a migrare un altro elemento dopo un rebake durante una migrazione, per evitare di intasare le code, in modo che il sito continui a funzionare. Ho una patch che aggiunge questa funzionalità, con valore predefinito zero, per tutti i rebake per post in lib/tasks/uploads.rake. Sto usando questo nella mia migrazione di produzione.

https://github.com/discourse/discourse/blob/59a761851b9c8786d3a9692f8c595372b0534f77/lib/tasks/uploads.rake

4 Mi Piace
7

@zogstrip Ti dispiace rivedere questa PR dato che hai il contesto dalla recente revisione della mia precedente in quest’area? FIX: Make migrations from S3 more robust; fix bare URL migration by johnsonm · Pull Request #10093 · discourse/discourse · GitHub

Ho incluso le correzioni che ho apportato mentre eseguivo questa migrazione relativamente grande. Non ho cercato di aggiungere test per ogni correzione; non sono sicuro di come iniettare ogni forma di errore. Ma almeno la nuova funzionalità è testata.

@RGJ Penso che la mia PR, così com’è ora, possa gestire tutti i punti tranne i primi due, tranne che per quanto riguarda il CDN. Il mio sito utilizzava il CDN e ha migrato video con URL CDN, ma ciò potrebbe essere stato un effetto collaterale della denominazione con gli spazi di Discourse. Se hai casi aggiuntivi, spero che la mia PR ti fornisca una struttura semplice per aggiungere al regex e creare casi di test per le variazioni aggiuntive.

Credo che sia corretto migrare prima per post, perché dopo aver migrato gli upload in un post, quest’ultimo deve essere rigenerato (rebaked) affinché il post elaborato (cooked) contenga gli URL corretti. Dopo aver completato la migrazione dei miei post (che potrebbe richiedere meno di due settimane ora che ho modificato il limitatore di velocità per controllare direttamente la lunghezza della coda), mi occuperò di eventuali lavori residui da completare.

Poiché più post possono condividere riferimenti allo stesso contenuto se più di una persona carica lo stesso file, è necessario un secondo passaggio che controlli i dati elaborati (cooked) per gli URL vecchi e rigeneri quei post per acquisire la nuova posizione. Può utilizzare lo stesso limitatore di velocità per evitare di saturare le code.

Probabilmente non vedrò loghi rotti su makerforums perché abbiamo modificato il branding dopo aver smesso di inserire nuovo contenuto in “s3” (per noi, DigitalOcean Spaces), ma probabilmente vedrò molti upload ancora su S3, almeno per gli avatar. La migrazione di upload non associati a un post dovrebbe essere avviata solo dopo che tutti i post sono stati migrati, e probabilmente dovrò scriverne dopo aver completato la migrazione degli upload nei post.

@pfaffman Ho visto Bizarre Problems with migrate_from_s3 - #5 che descrive errori che non si sono ripetuti. Senza le mie correzioni nella PR corrente, gli errori vengono silenziosamente assorbiti, inclusi i fallimenti di convalida. Credo che il lavoro qui svolto affronti almeno alcuni dei problemi che hai riscontrato allora.

@hosna i problemi che hai sollevato in https://meta.discourse.org/t/what-does-rake-uploads-migrate-from-s3-exactly-do/97285 sono parzialmente o completamente risolti finora in questa PR. Se non sono completamente risolti, ho aggiunto test che renderanno più semplice aggiungere ulteriori test per convalidare correzioni aggiuntive.

@sam dato che hai applicato l’etichetta 2.6 alla PR, presumo che non verrà unita (merged) per almeno alcuni giorni; dovrei integrare nel PR il mio lavoro sul limitatore di velocità insieme alle correzioni? O preferisci tenere correzioni e lavoro sulle funzionalità in PR separate? Posso fare entrambe le cose. La funzionalità di limitazione della velocità funziona molto bene; sto migrando circa tre volte più velocemente, senza impatti sulla disponibilità del sito, ora che sto attendendo che la coda di Sidekiq si svuoti, quindi ha senso integrarla, penso, se è qualcosa che di solito viene accettato nelle PR. Altrimenti, devo attendere l’unione della PR su cui si basa il lavoro, quindi in entrambi i casi sarebbe utile ricevere un feedback.

..

Ho eliminato la duplicazione (DRYed) della mia patch per il limitatore di velocità della migrazione e l’ho integrata nella PR. Funziona nella pratica e sar mi dice che sto riscontrando quasi zero tempo di inattività continuo, mentre il sito continua a funzionare, durante la migrazione live. Un vantaggio della modalità batch è che posso controllare nuove versioni di Discourse dopo ogni batch completo di migrazioni; ho aggiornato il mio sito alla versione 2.6.0beta1 alla prima opportunità dopo il suo rilascio e ho eseguito con successo le migrazioni su 2.6.0beta1 con la mia PR di migrazione applicata sopra dall’aggiornamento.

Credo che la PR sia ora pronta per la revisione; intendo presentare un’altra PR per le ultime fasi, ma ottenere questa in posizione migliorerà l’esperienza generale di migrazione per tutti, anche prima che io completi gli ultimi pezzi.

5 Mi Piace
8

Beh, è stato molto tempo fa…

Non vedo l’ora che venga risolto. Al momento ho diversi siti su multisite che devono recuperare immagini da S3 (al momento, credo che alcune immagini siano locali e altre su S3) e poi inviarle a S3.

1 Mi Piace
9

@pfaffman Probabilmente è una buona cosa che, quando ho iniziato il mio progetto di migrazione, non sapessi quello che penso di aver capito da allora. Sembra che se avessi usato il client minio per copiare tutto il bucket S3 nella cartella locale degli upload, modificato tutti gli Upload.url su nil nella console di Rails e rigenerato il sito, tutto sarebbe stato migrato in poche ore senza dover rigenerare tutte le immagini. (Invece, sono limitato dalla velocità di esecuzione di tutte le conversioni delle immagini di nuovo, come se la CPU locale fosse più economica rispetto al semplice copia di tutte le immagini elaborate da S3.)

E poi, se fosse stato così semplice, non avrei fatto tutto questo lavoro per rendere le migrazioni più affidabili in generale, e nessun altro ne avrebbe tratto beneficio. :smiling_face:

4 Mi Piace
10

Ah. Sembra proprio quello che volevo sapere. Forse ci provo.

1 Mi Piace
11

Io… farei sicuramente un backup prima di provare quella strada, dato che sto solo ipotizzando. Non voglio trarti in inganno.

Ah, e un’altra cosa: quella soluzione avrebbe fallito completamente per i caricamenti di audio e video, e non me ne sarei accorto fino a dopo, momento in cui avrei cercato di capire il problema e scritto codice personalizzato. Quindi, se hai caricamenti di audio e video, è assolutamente necessario partire da lì; non funzionerà correttamente senza la PR attualmente aperta, che non verrà unita al ramo principale fino dopo il rilascio della versione 2.5, poiché @sam l’ha etichettata come 2.6.

2 Mi Piace
12

Scusa per essermi unito alla conversazione così tardi. Ho appena dato un’occhiata alla tua PR e mi chiedo perché stai ricreando il modello Upload invece di modificare semplicemente il suo URL? E perché non iterare semplicemente su OptimizedImages facendo la stessa cosa?

2 Mi Piace
13

@RGJ Non ho modificato nulla del genere; ricreare Upload è stato un fix di bug da parte di @zogstrip in Cannot execute the rake uploads:migrate_from_s3 - #11

Sto solo cercando di far funzionare il codice che era già presente, e non conosco bene gli interni di Discourse; mi sono trovato a barcollare al buio molte volte. La mia unica esperienza con Ruby è costituita dai pochi PR che ho realizzato per Discourse. Seguire il pattern del codice esistente sembra davvero non essere la via più efficiente (vedi la mia conversazione con @pfaffman sopra riguardo all’intercettazione breve), sono completamente d’accordo. Come puoi notare dal fatto che stamattina non avevo nemmeno realizzato che OptimizedImages.url avrebbe dovuto essere modificato anch’esso in un percorso /uploads e che etag dovesse essere impostato su nil (e non so cosa altro), sto ancora volando alla cieca.

Devo ancora iterare sui post, almeno per correggere gli URL letterali vecchi nei post. Devo ancora applicare alcune delle altre correzioni, come non rivalidare i post e non ingoiare silenziosamente gli errori. Penso ancora che sia necessario introdurre un limite di frequenza (rate limiting) per limitare l’impatto sui siti in produzione.

Per le tue prime due preoccupazioni relative agli aggiornamenti non relativi ai post, ecco il mio lavoro in corso, non ancora testato su un sito in produzione (commit) che potrebbe aiutare, ma che non testerò sul mio sito in produzione finché la migrazione degli upload dei post non sarà completata.

Modificare qualcosa che funzionava prima era tutto ciò che avevo voglia di fare. Se desideri eseguire una migrazione più veloce, sono totalmente favorevole; potrebbe avere senso unire il mio lavoro più lento ma almeno migliore come miglioramento di Pareto, e poi potresti sostituirlo completamente con qualcosa di molto migliore. Sarei il primo a festeggiare, anche se in quel momento non sarò più nella posizione di utilizzarlo.

1 Mi Piace
14

@mcdanlj Grazie per la tua spiegazione. Stavo semplicemente facendo una domanda, non volevo insinuare che ci siano problemi al momento. Non so se il metodo che ho suggerito sia affatto “migliore”; forse introdurrebbe molti nuovi problemi. Presumo che il codice, così com’è ora, indipendentemente da chi lo abbia scritto, lo sia per una ragione.

3 Mi Piace
15

@RGJ allo stesso modo, sono sincero nel dire che se qualcuno sa con certezza come evitare la follia di ricostruire tutte le immagini, sono tutto orecchie; e se fossi uno sviluppatore Discourse esperto e sapessi come farlo facilmente, probabilmente l’avrei già fatto in un primo momento.

Immagino che la migrazione lontano da S3 non sia un caso comune per chi ha molte immagini, quindi potrebbe non valere la pena di dedicarci tempo, rispetto allo sviluppo di funzionalità più generalmente utili per Discourse. Avevo circa 100 GB di caricamenti importati da Google+ su MakerForums e abbiamo scelto S3 pensando che molte persone potessero trasferirsi da quelle community a MakerForums, ma alla fine solo poche community si sono trasferite attivamente, quindi la crescita continua non ha giustificato il permanere su S3. Mi aspetto che questo sia un caso piuttosto estremo e che la ric elaborazione delle immagini sia un costo una tantum.

Infine, sono molto grato per aver aperto questo argomento, perché altrimenti avrei potuto facilmente perdere i caricamenti non relativi ai post.

…

@RGJ hai chiaramente ragione: distruggere e ricreare non è una buona soluzione. Ho aggiunto un controllo, raise "Errore: l'URL di upload #{url} è cambiato in #{new_upload.short_url}, dovrebbe rimanere invariato." if url != new_upload.short_url, che almeno segnala problemi con sorgenti corrotte. L’incidente di oggi su Digital Ocean Spaces mi ha inviato dati corrotti, innescando questo errore per molti caricamenti — non so quanti. Ma poiché il vecchio upload era già stato distrutto, ora ho alcune pagine corrotte e non me ne sono accorto finché non ho perso lo storico dei log che indicava quali pagine erano danneggiate, quindi non posso nemmeno intervenire manualmente per correggerle da un backup.

Quindi, sebbene il mio lavoro rappresenti un miglioramento rispetto al metodo precedente perché almeno segnala alcuni errori, sarebbe molto meglio scaricare i file, verificare gli SHA1 dei file scaricati e scriverli su file locali. Nel frattempo, ho modificato la mia PR per fermare la migrazione in caso di qualsiasi errore non gestito, al fine di limitare almeno la perdita di dati.

Ritengo ancora che il mio lavoro dovrebbe essere unito al progetto principale come un miglioramento di Pareto, poiché non peggiora la situazione e anzi la migliora, ma sarebbe decisamente meglio farlo nel modo corretto. Credo che la soluzione giusta sia scrivere lib/file_store/from_s3_migration.rb in parallelo a lib/file_store/to_s3_migration.rb, ma non mi sento all’altezza del compito.

Poiché la mia PR non è ancora stata revisionata, ho aggiunto altro lavoro. Ho aggiunto un task uploads:report_missing_uploads che esamina raw per trovare istanze di upload://... in cui l’oggetto upload non è presente. Almeno nel mio caso, con i backup, potrò esaminare le mie copie di backup, trovare i file orfani e ripristinarli sul sito, quindi rigenerare i post per ripristinare le immagini mancanti. Ne ho trovati 678 da cercare nei backup, di cui finora ho recuperati tutti tranne 10, quindi sono contento di aver scritto il test! Dovrò occuparmene prima di passare alla fase di rigenerazione dei post rimanenti.

…

Ho completato la prima fase della migrazione, escludendo la rigenerazione dei post interessati con caricamenti condivisi e i caricamenti non relativi ai post. Dopo aver completato un altro backup remoto, prevedo di testare anche quelle funzionalità e aggiungerle alla mia PR.

…

Ho ora iniziato a testare le fasi successive della migrazione, ovvero la rigenerazione e la migrazione dei caricamenti non relativi ai post. La prima lezione è stata che la rigenerazione come passo successivo fallisce a causa di avatar non relativi ai post presenti in post citati, quindi la rigenerazione dei post deve essere l’ultimo passaggio.

Prossima scoperta: grazie ai vincoli di chiave esterna! Durante la migrazione dei caricamenti non relativi ai post, ho scoperto che devo migrare almeno i profili prima di migrare generalmente i caricamenti non relativi ai post.

ActiveRecord::InvalidForeignKey: PG::ForeignKeyViolation: ERROR:  update or delete on table "uploads" violates foreign key constraint "fk_rails_1d362f2e97" on table "user_profiles"

La migrazione dei profili è stata complessa perché dovevo migrare due caricamenti associati al profilo, ma in alcuni casi le persone hanno utilizzato la stessa immagine per entrambi, quindi ho dovuto svolgere questo lavoro in tre fasi. Ho migrato con successo tutti i profili del mio sito con URL S3.

Ho migrato tutti i caricamenti non relativi ai post e non ai profili. @RGJ, se vuoi provare il ramo che ho pubblicato, è aggiornato con il mio lavoro. Tutto ciò che contiene è stato utilizzato per una migrazione completa del sito.

…

@cvx Non so quando avrai modo di revisionare, ma senza la mia PR, migrate_from_s3 è sicuramente pieno di bug di distruzione silenziosa dei dati. Quello che ho fatto non è perfetto, ma protegge contro molti bug che ho riscontrato nella pratica.

Ho completato tutto il lavoro che intendo fare qui al momento. Ho migrato il mio sito, il che significa che non posso nemmeno valutare efficacemente eventuali modifiche richieste. Se respingete questa PR, vi suggerisco vivamente di eliminare la migrazione esistente, poiché distruggerà silenziosamente i dati degli utenti.

Per quanto riguarda la PR, a volte ricevo fallimenti nei test in CI (nella versione corrente) qualcosa del genere:

7867 esempi, 0 fallimenti, 11 in sospeso, 1 errore verificatosi al di fuori degli esempi

##[error]Processo completato con codice di uscita 1.

Questo non si riproduce localmente (per quanto ne so) e non vedo informazioni nei log di CI che indichino cosa non va, quindi non voglio perdere altro tempo cercando di esplorare l’output di CI per trovare informazioni nascoste.

Un’ultima nota: dopo aver completato la migrazione, abbiamo scoperto che le immagini dei profili di alcuni utenti sono state perse durante la migrazione e le stanno ripristinando manualmente. Immagino che sarebbe stato necessario del codice aggiuntivo per riuscirci, ma poiché non l’ho scoperto fino a quando non era troppo tardi, non ho un caso di test per convalidarlo. Quindi questo è un bug residuo che potrebbe causare problemi in alcune configurazioni, ma non sono più nella posizione di scrivere la correzione aggiuntiva.

5 Mi Piace
16

Visto che la mia PR che corregge la corruzione silenziosa dei dati in migrate_from_s3 non ha ricevuto nemmeno uno sguardo, si può almeno documentare migrate_to_s3 come una strada a senso unico?

Al momento, francamente, è una trappola per i principianti.

@cvx @zogstrip Qual è la vostra preferenza? Esaminare la PR o rimuovere semplicemente migrate_from_s3 e essere onesti sul fatto che si tratta di una strada a senso unico?

5 Mi Piace
Rebaking old posts won't pull new S3 CDN URL after S3 bucket rename
17

Scusa, la colpa è mia. Rivedrò la PR questa settimana.

7 Mi Piace
18

Il contenuto della recensione sostanzialmente affermava che l’attuale approccio è così completamente errato da dover essere ricostruito da zero e in modo diverso; che il tentativo di correggerlo come era stato scritto in precedenza non è accettabile. Non sono disposto a farlo, quindi ritengo davvero che migrate_from_s3 debba essere rimosso completamente e che migrate_to_s3 venga contrassegnato come una porta a senso unico, da accettare con la certezza di volerla mantenere per sempre. Al momento, avere migrate_from_s3 nel codice sorgente rappresenta un problema di integrità dei dati in Discourse.

Non ho ricevuto una revisione tempestiva mentre lavoravo al processo di migrazione, e ora che ho già completato la migrazione (con alcuni risultati rovinati, come alcuni avatar danneggiati), non ho più un ambiente di test significativo. Non ho alcuna fiducia di riuscire a farlo correttamente, quindi ho deciso di ritirarmi da questa battaglia. Toccherà al prossimo sfortunato che penserà sia una buona idea spostare le immagini in un servizio di object storage simile a S3 risolvere il problema. Scusa!

2 Mi Piace
19

@CxV Dato che hai respinto la migrazione precedente come eseguita completamente in modo errato e che richiedeva di essere ricominciata da capo, ti preghiamo di revisionare e unire questa rimozione del bug di corruzione dei dati:

2 Mi Piace
20

Come già notato, ho riscontrato alcuni problemi con la migrazione che ho eseguito. Questo conferma quanto affermato da @cvx: ho scritto la migrazione in modo completamente errato e, finché qualcuno non la correggerà, la rimozione della migrazione esistente, piena di corruzione silenziosa dei dati, dovrebbe essere assolutamente unita al ramo principale. (È una patch molto semplice, la revisione dovrebbe essere banale. Prima verrà unita, meno probabile sarà che qualcuno distrugga il proprio sito tentando di tornare indietro attraverso una porta a senso unico. Non so come poter sostenere con più forza la necessità di unire questa patch; se ci fosse un modo migliore, lo farei. Modifica: Grazie a @cvx per l’approvazione, l’unione e il follow-up per assicurarsi che la migrazione di massa sia contrassegnata come irreversibile.)

Ecco i problemi noti che ho riscontrato:

  • L’avatar di discobot non si è mostrato almeno in un caso; tutta la partecipazione di discobot ha mostrato l’avatar generico di una persona (testa e spalle grigio chiaro su sfondo bianco).
  • Gli avatar di alcune altre persone non sono stati migrati correttamente. Molti sono stati corretti manualmente.
  • Durante la configurazione del sito, l’amministratore originale ha sperimentato modifiche alla configurazione “S3” (nel nostro caso, Digital Ocean Spaces, con e senza CDN), portando alla creazione di alcune immagini ottimizzate orfane che non sono state corrette durante la migrazione.

Per chiunque abbia provato a usare il mio ramo e abbia visto scomparire alcune immagini come descritto, ho eseguito un hack nella console di Rails che ha risolto alcuni problemi. Questo non è il modo corretto di procedere; semplicemente non conosco abbastanza il modello per farlo nel modo giusto. Le mie competenze in Ruby sono molto deboli; non tocco Ruby al di fuori dei miei piccoli contributi a Discourse.

Tuttavia, per quanto sia, questo terribile hack ha risolto le immagini rotte (dovute agli errori iniziali di configurazione) e ha almeno riportato l’avatar di discobot (e forse altri, ma tutti quelli di cui ero a conoscenza erano già stati riparati).

Ciò che non appare qui è tutto ciò che ho fatto tra un passaggio e l’altro, esaminando ogni insieme man mano che procedevo. Questa era parte di una sessione di “esplorazione di ciò che c’è nella console di Rails” e non uno script che ho scritto ed eseguito. Non c’è gestione degli errori e ho effettuato un backup completo del sito prima di iniziare qualsiasi lavoro.

Non so come poter dire con più forza che questo codice non è il modo idiomatico di Ruby on Rails per eseguire questa riparazione. Volevo solo condividere come ho riparato almeno parte del danno che mi sono causato nel mio precedente tentativo di migrare il mio sito da Digital Ocean Spaces.

require 'set'

uploadids = Set.new
optimizedimages = Set.new
OptimizedImage.where("url like '%UNIQUEPARTOFS3URL%'").each do |oi|
  uploadids.add(oi.upload_id)
  optimizedimages.add(oi)
end

postids = Set.new
uploadids.each do |u|
  PostUpload.where(upload_id: u).each do |pu|
    postids.add(pu.post_id)
  end
end

optimizedimages.each do |oi|
  oi.delete
end

postids.each do |pid|
  Post.where(id: pid).each do |p|
    p.rebake!
  end
end
2 Mi Piace