[Bitrepository-devel] Undo af replace/delete logik

[Kåre Fiedler Christiansen]

Hej alle,

Jeg er selvfølgelig enig med Eld i, at jeg ikke ønsker at nogen skal
kunne uopretteligt slette noget af kulturarven som jeg har gemt i min
sikre bitbevaring. Det må ikke kunne ske ved en teknisk fejl, og det må
heller ikke kunne ske ved at jeg følger de rette procedurer ved en fejl.

Men, jeg er ikke enig i at det er det eneste use case der findes for
bitbevaring. Jeg kan uden videre finde på usecases for bitbevaring, hvor
det er et krav at jeg kan slette noget så det IKKE kan genoprettes.


Der er lagt op til at alle pillars skal understøtte undo. Men det er
ikke det mindst mulige krav, for at opfylde Elds og mine behov. Jeg kan
komme i tanke om flere alternative muligheder:
 * Man kan stille krav i SLA om at delete og replace ikke skal 
   understøttes i protokollen.
 * Man kan stille krav til pillars om at sletninger ikke må slette filer
helt, og de skal kunne genskabes udfra udefinerede manuelle procedurer
ved henvendelse fra ejeren.
 * Man kan lade "Undelete" være en frivillig operation at understøtte
for en pillar, og blot vælge pillars der understøtter operationen.
 * Man kan kræve tilstrækkeligt voldsomme credentials. F.eks. ved at
lade certifikatet til at tillade delete være delt i tre som ligger ved
henholdvis samlingsejer, pillarejer og i direktørens pengeskab.


Der er også et par issues yderligere jeg synes er relevante at rejse:
 * Undo er en næsten lige så farlig operation som Delete - ikke mindst
for Replace. Begge dele piller i de bitbevarede data.
 * Det er, hvor ondt det end gør, en reel mulighed at vi kommer til at
skulle kassere i den digitale kulturarv, ligesåvel som det sker for den
analoge. Det er en reel mulighed at man efter en migrering må kassere
originalerne af økonomiske årsager.
 * Hvis man ved en fejl ingester en stor mængde fejlbehæftede filer,
ønsker man at slette dem permanent.
 * Hvis vi _IKKE_ understøtter den totale delete, så er der reelle
risici for at det vil blive foretaget alligevel bagom systemet, ved
direkte henvendelse til de enkelte pillars. Det kan være en fordel i
stedet at have kontrol over processen.


I forhold til two-face-commit vil jeg gerne vedkende mig at det er et
dårligt ord, da det leder tanken hen på transaktioner m.v. I
strategi-projektet gav det udelukkende mulighed for rollback eller
commit på en enkelt operation, og formålet var mest at give mulighed for
at der kunne ske andre procedurer mellem det første kald af operationen
og det endelige commit; samt at kunne kræve forskellige credentials til
de to operationer. På den måde var det faktisk en "simpel
undo/replace-mekanisme". Efter at two-face-commit har muteret lidt i
dette projekt, er jeg ikke længere helt klar over hvad det dækker over.


Min konklusion i forhold til delete/replace:
 * Delete og Replace er reelle behov. Jeg synes de skal understøttes.
 * Undo er en mekanisme til at modvirke fejl. jeg synes den kan
understøttes, men jeg synes ikke den er essentiel at understøtte i
protokollen.
 * Credentials til at foretage en Delete eller Replace skal ikke tages
for let på. 
 * Det er vigtigt at man i sine SLA'er med pillars bliver enige om
hvordan Delete og Replace skal håndteres.


Dermed kan jeg godt understøtte en pilot uden undo. Til gengæld synes
jeg at vi har behov for at diskutere graduerede credentials.

Hilsen
  Kåre

On Thu, 2011-06-23 at 13:06 +0200, Eld Zierau wrote:
> Lille kommentar:
> 
>  
> 
> Som Jun skriver så går det også meget på hvad der er definitionen på
> opgaven two-phase commit. 
> 
>  
> 
> Her er så kommentarer der går lidt mere på delete og replace:
> 
>  
> 
> Til delete kunne der også være organisatoriske procedurer som gjorde
> at man ikke måtte slette uden sådanne procedurer var overholdt.
> 
> Spørgsmålet er så hvor meget der skal være i protokollen. 
> 
>  
> 
> Delete er noget frygteligt noget at have i bitbevaring – så skal vi
> have bitbevaring, så går den ikke uden undo og/eller stopklods!!! Jeg
> må indrømme at spike versionen (uden stopklods eller undo) er en der
> gipper i mig af samme grund – for den afspejler en funktion som ikke
> kan accepteres i sidste ende.
> 
>  
> 
> Replace er næsten lige så slem … men cases (til repair) er primært i
> brug på enkelt pillars og denne betragtning kan tages med i eventuelle
> procedurer for hvor meget der kan replaces ad gangen.
> 
>  
> 
> Mvh. Eld
> 
>  
> 
> Fra: bitrepository-devel-bounces at ml.sbforge.org
> [mailto:bitrepository-devel-bounces at ml.sbforge.org] På vegne af Jun
> Petersen Yoneyama
> Sendt: 23. juni 2011 12:21
> Til: List for the Bitrepositorys developers
> Emne: [Bitrepository-devel] Undo af replace/delete logik
> 
> 
>  
> 
> Kære alle
> 
> 
>  
> 
> 
> Eld har forklaret mig hvilke behov hun har i implementering af delete
> og replace.
> 
> 
> Min opgave her var at se om de kunne løses med two-phase commit.
> 
> 
> Jeg har skrevet argumenter og konklusioner ned efter et telefonmøde,
> så alle forbehold for, om jeg nu har forstået og nedskrevet tingene
> korrekt.
> 
> 
>  
> 
> 
>  
> 
> 
> Delete / replace logik:
> 
> 
> Eld vil gerne have at alle delete og replace aktioner kan fortrydes af
> brugeren.
> 
> 
> Use cases er
> 
> 
>       * at man starter en sletning og overser, at det er den gale fil
>         man har angivet. 
>       * at en medarbejder bevidst søger at slette data som hævn eller
>         sabotage
>  
> 
> 
> Vores forslag er, at alle pillars har en undo facilitet for delete og
> replace handlinger.
> 
> 
> Undo kan aktiveres af brugeren/kunden indenfor en periode.
> 
> 
> Som alternativ kunne man vise en ”Slet eller fortryd” dialogboks, men
> i praksis medfører det blot, at brugeren tvinges
> 
> 
> til at tage afgørelsen her-og-nu. Det sidste vil jeg umiddelbart tro
> er vanskeligere at integrere ind i en organisatorisk implementation.
> 
> 
> For at gennemføre en ”undo” bør brugeren have adgang til at aktivere
> tilstrækkelige credentials.
> 
> 
> Uanset hvor tydeligt det vises på klientsiden, bør Undo altid logges
> på audit.
> 
> 
>  
> 
> 
> Eld mener, at det skal være muligt at undo enhver delete/replace på
> enhver pillar i Bitmagasinet.
> 
> 
> Vores konklusion blev derfor, at dette skal implementeres i form af et
> nyt krav til alle pillars (understøtte undo)
> 
> 
> og en udvidelse af protokollen (selve undo beskeden).
> 
> 
>  
> 
> 
> Det ovenstående kan i princippet også løses med en almindelig
> two-phase commit, da klientprogrammer som regel har mulighed for at
> afslutte en transaktion enten med commit eller med rollback. I den
> forstand har klientprogrammet derfor en sidste chance for at fortryde
> en eller flere operationer, der er pakket ind i en two-phase commit
> mekanisme.
> 
> 
>  
> 
> 
> Men overheaded i krav til pillars er urimelig stort.
> 
> 
> Det er en ”dyr” fortrydelsesmekanisme, da two-phase commit er beregnet
> til, at koordinere en distribueret transaktion, så den kun gennemføres
> hvis alle distribuerede operationer gik godt. Uden at gå ned i alle
> detaljer af en two-phase commit, så skal alle pillars mindst
> opretholde:
> 
> 
>       * låsninger på alle involverede objekter 
>       * opretholde data til at undo alle ændringer
>       * og kunne afgive en stemme til afstemningsproceduren
> Bortset fra undo er alt det andet ikke nødvendig til en konfirmation
> af delete/replace.
> 
> 
>  
> 
> 
> Hertil kommer, at vi nok ikke kan leve med låsninger ned i storage i
> længere tid.
> 
> 
> En two-phase commit vil derfor i praksis tvinge programmøren til at
> ”slette eller fortryde” umiddelbart efter gennemførslen.
> 
> 
> Så, en stemme på en simpel undo herfra.
> 
> 
>  
> 
> 
>  
> 
> 
>  
> 
> 
>  
> 
> 
> Audit: Hvem trykker på undo knappen?
> 
> 
> På audit bør alle loggede operationer så vidt muligt logges med en
> individuel bruger ID.
> 
> 
> Hvordan gør vi det? På mødet i onsdag nåede vi (næsten) frem til, at
> det er tilstrækkeligt med credentials.
> 
> 
>  
> 
> 
>  
> 
> 
> Mvh Jun
> 
> 
>  
> 
> 
>  
> 
> 
>  
> 
> 
>  
> 
> 
>  
> 
> 
>  
> 
> 
>  
> 
> 
>  
> 
> 
>  
> 
> 
>  
> 
> 
>  
> 
> 
>  
> 
> 
>  
> 
> 
>  
> 
> 
>  
> 
> 
>  
> 
> 
>  
> 
> 
>  
> 
> 
>  
> 
> 
>  
> 
> 
>  
> 
> 
>  
> 
> 
>  
> 
> 
>  
> 
> 
>  
> 
> 
>  
> 
> 
>  
> 
> 
>  
> 
> 
>  
> 
> 
>  
> 
> 
>  
> 
>