Child pages
  • 2011-06-29 møde i Odense
Skip to end of metadata
Go to start of metadata

Tidspunkt: Onsdag 2011-06-29 9:15 - 14:50

Sted: Odense

Med beslutningrefereat

Praktisk:

  • Indgang om morgenen: Indgangsdøren ved Østre Stationsvej 23 (mellem Sunset Boulevard og Blockbuster video). Dørtelefon skal benyttes.
  • SB'erne ( Kåre, Bolette og Mikis) ankommer til Odense ca. kl. 9.04 (afgang Århus 7:28 og skal afsted med toget 15.07 med ankomst til Århus 16.40 .
  • KB'ere (Jonas, Eld og Christian) ankommer til Odense kl. 9.05 (afgang Kbh H 7.50) og skal afsted med toget 15.08 med ankomst til Kbh H. 16.32. (Eld og Jonas tager toget, hvor pladsbilletterne er skaffet og klippekort til Odense er bestilt. Christian benytter anden transport.)
  • SA'er (Jun og Jonas): ankommer til Odense kl. 9.00 (afgang Kbh H 7.30) og skal afsted med toget 15.15 med ankomst til Kbh H. 16.49. (Vi kører med almindelig Intercity med stop i Roskilde, så vi kan følges.)

Agenda

  1. Agenda ok?
  2. Designdiskussioner (Indtil frokost ~ 12:00 med 1 pause undervejs):
    •  Diskussion af Bit Repository instance indholdet.

      Vi nåede ikke igennem dette punkt, men der blev diskuteret en masse i forbindelse med de gennemgående punkter. Resten af punkterne tager vi på mailing liste/næste møde. Følgende ting blev aftalt:

      • HTTP server settings er ikke med i collection settings da den ikke kan forventes at være en del af klienterne (og ikke er det i reference implementationen). Mikis tilføjer en note om dette på Bit Repository instance siden.
      • Messagebus url skal ændres til Message bus configuration.
      • Det er svært at finde et brugbart mål for timeouts på meddelser, specielt dem som involvere file overførsler. Vi indfører dog en settings for forventet pillar båndbrede i klient side settings. Ellers må klienten nøjes med den timeToDeliver den får i identify responses til at sætte en timeout for et evt. progressResponse.
      • Certificater skal præciseres til at det drejer sig om en user/operation matrice af certificater.
      • En pillar har et certificate.
      • Det skal præciseres om collection settings er public (dvs. distribueres), f.eks. public certificater, eller de er private (ligger lokalt hos en klient/pillar) som f.eks. den private del af et certificate. Konkrete gøres dette ved at at introducere public/private underkapitler.
      • Da vi gerne vil have information om hvilken bruger der har kaldt en given operation med i audit trail har vi bruge for at få tilføjet disse informationer til alle meddelser, så de er til rådighed for audit trails. Konkrete gøres dette ved at der tilføjes et 'audit info' til message core xsd'en. Mikis opretter opgave.
      • Vi skal have koblet konkrete navne på de forskellige settings. Mikis opretter opgave.
      • Vi inkludere forsat information på klientsiden om de pillars der forventes at være en del af en collection.
      • Final responses er mandatory.
      • Information om Progress responses kan forventes er specific for de enkelte pillars.
      • Lad os i første omgang inkludere information om hvilke checksum typer de enkelte pillars understøtter i klient side settings, denne viden er trods alt tilgængelig i den aftale der er lavet. Hvad den lige skal bruges til er ikke så klart.

      Mikis sørger lige for at alt det ovenstående bliver lavet.

    • Diskussion af mail fra Eld omkring repository splits.

      Konklusionen var at vi ikke skal have denne funktionalitet implementeret direkte i Bitmagasin protokollen. Til gengæld har vi følgende afledte actions:

      • Mikis laver udkast til af overordnet use case omkring tværgående idNamespace scenarie. Eld konsolidere dete hvis der er tid.
    • Diskussion af Undo af replace/delete logik.

      Konklusionen var at vi ikke skal have denne funktionalitet implementeret direkte i Bitmagasin protokollen. Til gengæld har vi følgende afledte actions:

      • Vi skal have defineret en manuel procedure til at 'retain'e' data på benene i en periode efter de er slettet, så man har mulighed for at restore data ved at kontakte pillar drift direkte. Mikis oprettet opgave.
      • En ekstra relevant sikkerhed vi bør indbygge er validering af checksum i deleteRequests for at sikre at det er den rigtige fil der slettes.
      • Eld er utryg ved at man ved flere collections på den samme pillar med potentielt forskellige aftaler for retention kan komme til at slette data uden den aftalt retention, hvis der ikke er 100% styre på, hvad der skal gemmes, hvor længe.
    • Skabe bedre split mellem generalt Bit Repository information (Protocol) og Det Danske Bitmagasin information (Infrastruktur). Resultatet skulle gerne vise sig i en opdateret dokumentationsstruktur.

      Alle var meget glad for Kåres forslag til denne opsplitning af hensyn. Dvs. Protocolen ophøjes til at være den helt generalle indgang for Bitrepository information. Lidt mere konkret har vi Det Nationale Bitmagasin ,som basere sig på et konkret arkitektur valg beskrevet under 'Architectur'. På et endnu mere konkret niveau har vi reference klienter og vores pillars.

      Kåre opdater wiki strukturen til at afspejle denne separation af hensyn.

    • Diskussion af mail fra Kåre omkring Protokol-præciseringer.

      Nåede vi ikke, så vi fortsætter diskussionen på mailing listen.

  1. General projektstatus diskussion (ca. 12:30 - knap 15:00  med 1 pause undervejs).
    • Opnå konsensus om indhold af pilot ved start. Se Pilot scope analysis.
      • Nåede vi ikke igennem. Den delvise placering af features på pilot/prod blev opdateret direkte på wiki'en. De resterende features sender Mikis en mail om på mailing listen, hvor vi forhåbentligt kan opnå enighed om vigtigheden af disse i pilot/prod.
      • Vigtigheden af at piloten bliver kørt som et drift system med formaliseret samarbejde mellem udviklings og drift organisationerne (ingen udvikler ssh'er til lige at skrue på drifts maskiner). Disse hensyn mente Mikis dog allerede var dækket af M7 Pilot in operation beskrivelse.
      • Vi skal have tilføjet en productionslignende load og stress test af systemet til pilot formål.
      • Vi skal have defineret vores forskellige miljøer klarer (development (nuværende), integration/test, pilot/stage og production. Mikis laver beskrivelse.
      • Vi skal have dokumenteret vores broker strategi/scenarier (opsætning, antal, placering).
      • Vi skal have taget hul på et sted at have vores Nationale Bitmagasin drift informationer (dokumentation opgaver). Dette kan i første omgang ligge på denne wiki, men skal på den længere bane flyttes til sit eget (lukkede) projekt, a.la. Netarkivet.
    • Status i forhold til Prioritized implementation list.

      Nåede vi ikke. Det vigtigste var også at få scopet udeståender til pilot.

    • Input til opdatering af Milestone plan. Her er det mest interessant om pilotdrift og endelig drift tidspunkterne er realistiske.

      Nåede vi ikke. Det vigtigste var også at få scopet udeståender til pilot.

  2. I9 status.

    Nåede vi ikke.

  3. Næste møde? 10 august.

    Nej, onsdag d.6.7 11-12

  4. Evt.
  • No labels