Migrasjonsplan for nytt produksjonsmiljø

1.1   Nytt miljø

Cerebrum-drift har ansvar for å bestille og sette opp nytt produksjonmiljø. Dette er dokumentert på drift sitt web-område.

1.2   Migrasjon av kodebase

I forbindelse med overgang til Python 2.7, er det blitt avdekket en del ukompatibel eller utdatert kode som må fikses, i tillegg til en del endringer som er ønsket ved overgang til nytt produksjonsmiljø. Disse endringene er Cerebrum-utvikling sitt ansvar.

Hittil har følgende blitt identifisert:

CRB-728

Advarsler fra Python - bedre ivaretaelse (og oppfølging) av warnings

CRB-727

cElementTree - Rydde opp i bruk av ElementTree og lxml

CRB-725

Psycopg2-modul – Fikse patching av PsycoPG2 som ikke er støttet i nyere versjoner

CRB-722

Fjern json frå extlib – Overgang til Pythons innebygde JSON-modul

CRB-721

Erstatt popen2 med subprocess – popen2 er foreldet

CRB-720

object __init__ – Kall til object.__init__ med argumenter er frarådet

CRB-719

String exceptions – raise "string" er ikke lenger støttet

CRB-723

Fjern argparse frå extlib – argparse er en del av standardbiblioteket i PY27

CRB-726

M2Crypto – Vedlikehold av biblioteket M2Crypto er ikke ønsket

lxml-modul

Generell opprydding i bruk av xml/lxml vurderes

Det har blitt opprettet en egen branch for utvikling av disse endringene, origin/python-27-pseudo-master. Før migrasjon startes, bør endringer fra origin/master taes inn i denne branchen.

2.1   Overordnet test

I praksis vil man utføre følgende:

1. Sette opp miljø * Installere siste versjon av Cerebrum (branch origin/python-27-pseudo-master)
2. Ta kopi av produksjonsdatabase * Konfigurere Cerebrum-installasjonen til å benytte database-kopi.
3. Kjøre alle importer * Kun importer som ikke tilbakefører data til kildesystem. * Ingen jobber som sender ut e-post eller SMS.
4. Kjøre alle eksporter * Ikke eksporter som kommuniserer direkte med målsystem
5. Sammenligne eksporter med eksporter fra gammelt produksjonsmiljø
6. Starte tjenester, verifisere at disse fungerer som forventet

4.1   Kontroll av resultat

Ved differanse i eksport-filer, vil vi måtte undersøke årsak. Dersom jobber kjører med samme data-grunnlag skal ikke eksporter ha differanse.

4.2   Konfigurasjon

For å hindre utilsiktet utsending av e-post eller SMS, samt annen utilsiktet kommunikasjon med systemer, bør nytt produksjonsmiljø settes opp uten nødvendig informasjon til å utføre disse oppgavene.

5.1   Instanser

Det foreslås at vi flytter en og en instans over i nytt produksjonsmiljø. Rekkefølgen er ikke fastslått, med det foreslås å starte med WebID, etterfulgt av UiO.

WebID er et godt startpunkt, da eventuelle feil ikke vil ha innvirkning på samarbeidspartnere, samt minst innvirkning av instansene på UiO.

UiO er en av de mer kompliserte instansene, og vil derfor kunne bidra til å oppdage eventuelle feil før vi fortsetter med instanser som driftes for samarbeidspartnere.

De resterende instansene vil kunne migreres fortløpende etter at eventuelle feil som blir oppdaget i løpet av testing og migrasjon har blitt rettet.

5.2   Tidsplan

For hver instans som migreres, bør testfasen startes minst tre dager før migrasjonen til nytt produksjonsmiljø utføres. Dette gir nok tid til å utføre en sleggetest av de største eksporter og importer, samt akseptansetest av den kjørende løsningen.

5.3   Estimert tidsbruk

Følgende tid er estimert brukt av èn drifter per instans. UAIT bør stille (minst) en utvikler per instans til disposisjon for å fikse eventuelle feil/utrede differanse på eksporter.

Overgang til nytt miljø for en instans:

>>> tpe = lambda a, m, b: (a + 4*m + b)/6.0
>>> tpe(3.875, 7.75, 15.5)
8.395833333333334

Sjekk for differanse i *LDIF etter SAP- og FS-import, samt differanse av DNS-eksport:

>>> tpe(2, 3, 5)
3.1666666666666665
>>>

I tillegg til estimater ovenfor kommer lesing av logg meldinger fra akseptansetesten. Dette er en oppgave som går løpende, og kan fortrinnsmessig bli utført av både drift og utvikling. 1 time per dag av akseptansetesten bør være nok til å utføre dette.