Plan for sleggemetoden

I samanheng med overgang til git treng vi å oppgradere alle instansar til HEAD med cerebrum-kodetreet. For å teste at oppgraderinga vil fungere treng vi å køyre ein manuell test av alle jobbar som køyrer for dei ulike instansane, for å sikre oss at det ikkje oppstår problem ved oppgradering. Populert kalla sleggemetoden.

Dette dokumentet inneheld ei liste over alle jobbar som skal testast per instans.

1   Før du begynner

Dokumentet kan oppdaterast om du oppdager feil undervegs i testinga, til dømes om det er feil rekkefølge på visse jobbar.

Vi har splitta opp jobbane i importar, eksportar og jobbar som ikkje kan testast før vi begynner prodsettinga. Sjå Sleggemetoden [PDF] for korleis testprosessen utførast.

Nokre jobbar er blitt utelatte frå testinga, til dømes statistikk og rapportar som sendast ut på e-post. Desse skal fungere, og har liten risiko om dei vert feil første gangen etter oppgradering.

Kommandoane for å køyre dei ulike jobbane finn du i scheduled_jobs.py. Du kan, for dei instansane som har fått dette lagt til, kunne køyre:

python scheduled_jobs.py -v

For å bl.a. liste ut alle jobbar sine parameter. Legg til -h for meir info.

2   Instansane

2.1   NIH

2.1.1   Importar

  1. FS_merge_xml
  2. FS_update_fnr
  3. FS_import_OU
  4. FS_import_FS
  5. process_students
  6. deactivate_quarantined_accounts - dryrun og sjekk logg.
  7. SAP_import_ou_id
  8. SAP_import_person
  9. SAP_process_affiliations

2.1.2   Eksportar

  • Cristin-eksport
  • OrgLDIF
  • Bofhd - start og køyr nokre enkle kommandoar.

AD-synkar må testast i dryrun når ein går i prod - sjekk av loggfil.

2.1.3   Test ved prodsetting

  • ABC-eksport
  • FS_import_from_FS - samanlikn filer ved prodsetting, skal vere like.
  • Individuation
  • update_FS_mailadr, sjekke logg ved dryrun.
  • AD

2.2   Giske

Obs: Giske liknar på ØFK, men er mykje mindre, så denne treng vi ikkje å køyre eige testmiljø for.

2.2.1   Importar

Må kopiere over abc_giske.xml frå produksjonsmiljøet.

  • import_abc_data
  • proc_entity

2.2.2   Eksportar

  • OrgLDIF
  • Bofhd - start og køyr nokre enkle kommandoar.

2.2.3   Test ved prodsetting

  • AD, quick og fullsynk. Obs: Har vore nede ei god stund no, så får ikkje verifisert om det fungerer eller ikkje.

2.3   HiH

Obs: Denne instansen skal ikkje vere nødvendig å køyre testopplegget for, då den har lite som er unikt for seg. Er feil blitt fiksa hos dei andre, skal denne også mest truleg vere ok, og kan heller berre testast når ein går i produksjon.

2.3.1   Importar

  1. FS_merge_xml
  2. FS_update_fnr
  3. FS_import_ou
  4. FS_import
  5. process_students
  6. deactivate_quarantined_students
  7. pop_fronter_groups
  8. SAP_import_ou_id
  9. SAP_import_person
  10. SAP_process_affiliations
  11. set_lms_spread_ans
  12. set_lms_spread_stud
  13. set_bewator_spread_ans
  14. set_bewator_spread_stud
  15. set_bewator_spread_tilk

2.3.2   Eksportar

  • ABC_generate_export
  • bewator_generate_files
  • Cristin
  • gen_fronter
  • generate_entitlements_pickle - kan sjekke pickle-fila ved å køyre python inline, importere dei med pickle.loads() og køyre djupare samanlikning.
  • OrgLDIF
  • ldif_generate_users
  • Bofhd - start og køyr nokre enkle kommandoar.

2.3.3   Test ved prodsetting

  • AD, full og quick, grupper, distribusjonsgruppe. Obs: Mange ulike domener!
  • individuation
  • update_fs - dryrun, sjekk logg.
  • FS_import_from_fs - samanlikn filer ved prodsetting, skal vere like.
  • sap_data_to_fs (hr2fs-person.py) - dryrun, sjekk logg.

2.4   HiNesna

2.4.1   Importar

  1. FS_merge_xml
  2. FS_update_fnr
  3. FS_import_ou
  4. FS_import
  5. generate_acounts_from_FS
  6. SAP_import_ou_id
  7. SAP_import_person
  8. SAP_process_affilations
  9. generate_accounts_from_SAP
  10. send_welcome_sms: Obs: berre i dryrun, elles står du i fare for å sende ut SMS om du har tilgang til SMS-gatewayen frå testmiljøet.

2.4.2   Eksportar

  • Bofhd - start og køyr nokre enkle kommandoar.
  • OrgLDIF
  • ldif_samson3_generate

2.4.3   Test ved prodsetting

  • individuation
  • FS_import_from_fs - samanlikn filer ved prodsetting, skal vere like.

2.5   HiØ (hiof)

2.5.1   Importar

  1. merge_fs_xml
  2. update_fnr
  3. import_ou
  4. import_fs
  5. process_students
  6. import_sap_ou_id
  7. import_sap_person
  8. process_sap_affs
  9. sap_sync_auto_groups
  10. process_ad_attrs
  11. process_ad_spread_adm
  12. process_ad_spread_fag
  13. process_ad_spread_stud
  14. process_ad_spread_adm_rep
  15. process_ad_spread_fag_rep
  16. process_ad_spread_stud_rep
  17. send_welcome_sms: Obs: berre i dryrun, elles står du i fare for å sende ut SMS om du har tilgang til SMS-gatewayen frå testmiljøet.
  18. pop_fronter_groups
  19. quar_accounts OBS OBS OBS! Kjør med dryrun argument! (-d eller --dryrun (les koden)), ellers sender du masse mail!!
  20. deactivate_accounts

2.5.2   Eksportar

  • cristin_generate_file
  • Bofhd - start og køyr nokre enkle kommandoar.
  • generate_email_dump
  • gen_fronter_xml
  • OrgLDIF
  • ldif_users

2.5.3   Test ved prodsetting

  • Individuation
  • abc_generate_file
    • import_from_fs - samanlikn filer før og etter oppgradering, skal vere like.
  • update_fs - dryrun, sjekk logg
  • AD. Obs: mange domener.

2.6   NMH

2.6.1   Importar

  1. merge_fs_xml - Filer[#nmh_dump]_: person.xml, nettpublisering.xml
  2. update_fnr - Fil[#nmh_dump]_: fnr_update.xml
  3. import_ou - Fil[#nmh_dump]_: ou.xml
  4. import_fs - Filer[#nmh_dump]_: studieprog.xml, emner.xml
  5. process_students
  6. SAP_import_ou_id - Fil[#nmh_dump]_: ou.xml
  7. SAP_import_person - Fil[#nmh_dump]_: feide_persondata.txt
  8. SAP_process_affs - Filer[#nmh_dump]_: feide_persondata.txt, feide_persti.txt
  9. SAP_import_utvalg - Fil[#nmh_dump]_: feide_perutvalg.txt
[1]Filene hentes fra produksjonsmiljø før import startes

2.6.2   Eksportar

  • ldif_org
  • Bofhd - start og køyr nokre enkle kommandoar.

2.6.3   Test ved prodsetting

  • FS_import_from_fs - samanlikn filer ved prodsetting, skal vere like.
  • update_fs - dryrun, sjekk logg
  • export_abc
  • generate_lms_export_file
  • Individuation
  • AD sync (ad_user_sync, ad_pwd_sync, ad_group_sync)

2.7   Øfk

2.7.1   Importar

  1. import_abc_data: Fil[#ofk_dump]_: abc_enterprise-ofk.xml
  2. process_entity
  3. update_ou_groups ?
  4. db_clean_changelog?
[2]Filene hentes fra produksjonsmiljø før import startes

2.7.2   Eksportar

  • Bofhd - start og køyr nokre enkle kommandoar.
  • gen_fronter
  • make_kvern_file
  • ldif_org

2.7.3   Test ved prodsetting

  • AD sync (ad_usersync, ad_pwdsync, ad_groupsync)
  • Individuation

2.8   WebID

WebID treng ikkje å køyre i test, men kan testast direkte når den går i produksjon. Instansen er såpass liten, og tåler noko meir nedetid enn dei andre tenestene.

2.8.1   Test ved prodsetting

  1. grim_reaper
  2. ldif_all
  • bofhd - start og køyr nokre enkle kommandoar
  • CIS: SoapGroupPublish - start, sjekk at den køyrer
  • CIS: SoapVirthomeServer - start, sjekk at den køyrer

2.9   UiA

2.9.1   Importar

  1. merge_fs_xml - Fil[#uia_dump]_: person.xml
  2. update_fnr - Fil[#uia_dump]_: fnr_update.xml
  3. import_ou - Fil[#uia_dump]_: ou.xml
  4. import_fs - Fil[#uia_dump]_: studieprog.xml
  5. process_students
  6. populate_external_groups
  7. SAP_import_ou_id - Fil[#uia_dump]_: ou.xml
  8. SAP_import_person - Fil[#uia_dump]_: feide_persondata.txt
  9. SAP_process_affs - Filer[#uia_dump]_: feide_persondata.txt, feide_persti.txt
  10. populate_auto_groups
  11. terminate_old_guests
  12. update_affiliation_groups
  13. process_deleted
  14. clean_cl
[3]Filene hentes fra produksjonsmiljø før import startes

2.9.2   Eksportar

  • bofhd - start og køyr nokre enkle kommandoar
  • cristin_generate
  • abc_generate_file
  • generate_fronter_file
  • ldif_mail
  • ldif_org
  • ldif_posix
  • ldif_radius
  • gen_passwd
  • gen_group
  • gen_ng_user

2.9.3   Test ved prodsetting

  • AD sync (ad2_usersync, ad2_passwordsync, ad2_groupsync, ad_maillistsync, ad_guestsync)
  • Individuation
  • send_welcome_sms -- i dryrun, sjekk logg
  • update_fs - dryrun, sjekk logg

2.10   UiO

2.10.1   Importar

  1. FS_merge_fs_xml
  2. update_fnr
  3. FS_import_fs
  4. FS_import_fs_pq_data
  5. process_students
  6. SAP_convert_file
  7. SAP_import_ou
  8. SAP_import_persons
  9. SAP_update_employees
  10. SAP_sync_auto_groups
  11. import_folk_URLs
  12. quota_calc
  13. email_server_weights
  14. update_publication_reservations
  15. dns_subnet_import
  16. ephorte_symlink_steder
  17. ephorte_populate
  18. LMS_build_groups_from_fs
  19. process_bofhd_request - berre at den starter og avslutter, vanskeleg å teste

System Message: WARNING/2 ({DAVSYNC3}git/sleggeplan.rst, line 540)

Enumerated list ends without a blank line; unexpected unindent.
den skikkeleg utan aktivitet, så det må gjerast etter prodsetting.
  1. release_guests
  2. db_clean_passwords
  3. db_clean_changelog
  4. tag_student_disks

2.10.2   Eksportar

  • Bofhd - start og køyr nokre enkle kommandoar

  • cis_individuation - Køyr mot testmiljø, w3utv-ws01.

  • bofhd_epay - Treng å få Nettskjema-folka til å få testa denne.

  • pq - Dette er ein "webservice". Treng å få utskrift-drift til å få testa og verifisert at denne fungerer som den skal.

  • DNS-drift må verifisere output frå visse jobbar, dersom det er endringar:

    • dns_dhcp_generate_dump
    • dns_build_uio_no
    • dns_build_129_240
    • dns_build_2001_0700_0100
    • dns_build_trofast_uio_no
    • dns_build_151_157
    • dns_build_158_36
    • dns_build_193_157
    • dns_build_ping

  • unix-drift må verifisere output frå enkelte jobbar, dersom det er endringar:

    • dns_nis_mng
    • dns_nis_hosts_map
    • nis_gen_passwd
    • nis_gen_group
    • nis_gen_ng_user

  • ecommerce_gen_export - BASWARE må verifisere eventuelle endringar.

  • ephorte_generate_export - Arkiv må verifisere eventuelle endringar, men då treng vi i så fall å synke til testmiljøet deira.

  • ephorte_symlink_export - Arkiv må verifisere eventuelle endringar, men då treng vi i så fall å synke til testmiljøet deira.

  • cristin_generate_file

  • fronter_generate_full - Ved endringar i output må DML (td. Knut Augedal) verifisere at endringane er ok. Dette gjerast ved at dei oppretter eit testmiljø hos fronter.com, og vi overfører XML-fila dit med tilhøyrande kode.

  • check_userdisks_gen_cache

  • hostpolicy_generate_dump - unix-drift må verifisere eventuelle endringar.

  • hpc_gen_group

  • hpc_gen_md5pwd

  • ifi_auto

  • ifi_gen_passwd

  • ifi_gen_group

  • ifi_gen_ng_user

  • ldif_group

  • ldif_org

  • ldif_posix

  • ldif_hostgroup

  • ldif_mail

  • ldif_mail_cyrus_hack

  • ldif_mail_dns

  • ldif_kurs

  • ldif_subnets

  • ldif_voip

  • ldif_automount

  • ldif_hosts

  • ldif_isf

  • medfak_generate_map_* (fleire jobbar her)

  • pwd_name_dictionary

  • generate_employee_ids

  • SAP_generate_BAS2SAP_exportfile

  • dump_sidegjoremal_data

  • money2paper

  • list_disk_quotas

  • ua_export

  • populate_valg

2.10.3   Test ved prodsetting

  • FS_import_from_fs - Sjå til at FS-filene ikkje har endra seg. Merk at FS endrer seg fort i arbeidstid, så du vil kunne få ein del endringar avhengig av kor lenge det var mellom pre- og post-oppgraderingsfiler.

  • update_fs - Køyr i dryrun og sjekk loggen for endringar.

  • FS_update_from_SAP - Køyr i dryrun og sjekk loggen for endringar.

  • AD: AD_usersync, AD_groupsync - Køyr i dryrun og sjekk loggen for endringar.

  • cis_individuation - Testast ved å gå til https://brukerinfo.uio.no/forgotten/ og legge inn både riktig og feil data. Treng tilgang til ein studentbrukar utan tilgangar for å teste at heile passordbytteprosessen, alternativt endre på koden for å få tilgang.

  • web_postmaster - kan sjekkast ved å gå til https://brukerinfo.uio.no/postmaster/ og hente ut ei liste eller to.

  • Ephorte-eksportar: Desse treng vi ikkje å teste dersom vi har verifisert at XML-filene produsert av ephorte-eksportane ikkje har forandra seg. Dersom det er endringar vil det kreve at vi koordinerer med Arkiv, eventuelt også trofast-drift.

    • ephorte_sync_test - ePhorte sitt test-miljø, mest sannsynleg minst kritisk.
    • ephorte_sync_kurs - For kursing, vil kunne testast når det ikkje går kurs.
    • ephorte_sync_prod - Dei andre eksportane må ha blitt verifiserte først.

  • build_homedirs - Må be unix-drift om å verifisere at endringar på heimeområder fungerer etter oppgradering.

  • Notes - Fleire jobbar. Køyr i dryrun og sjekk loggar. Notes-drift må verifisere om notes-id-filer ser ok ut. Det er ikkje sikkert vi treng å teste dette, sidan vi har migrert frå Notes.

  • Exchange: Jo og postmaster bør sjå over dette. Mest sannsynleg ingen endringar, då det meste skal allereie vere i HEAD.

  • send_welcome_sms - dryrun først, sjekk loggen.

  • dbfg_update - Krever tilgang til prod-databaser. Køyr i dryrun først.

  • dbfg_expire - Krever tilgang til prod-databaser. Køyr i dryrun først.

2.10.4   Test etter prodsetting

  • notify_change_password
  • process_bofhd_request
  • process_bofhd_req_mail

3   Felles

Tenester som må testast (meir) i produksjon:

  • bofhd - Tenesta må startast, og du kan logge på med bootstrap_account og køyre ulike kommandoar.
  • cis - Tenesta må startast, og tenesta som bruker den må gåast gjennom. For individuation til dømes må du gå til gløymd-passord-tenesta og legge inn både ekte og falske data og sjå at du får reelle resultat.
  • AD-synk - AD-jobbar må startast i dryrun, og loggen må bli sett over for å sjå kva som eventuelt endrast. Det skal vere ingen eller minimalt med endringar.
  • pq - printerquota-service på UiO - treng at dei som jobber med utskriftstenesta køyrer ein test mot denne under oppgradering.
  • update_FS_mailadr - Sidan den gjer endringar i FS må den køyrast i dryrun. Sjekk loggen, skal vere ingen eller minimalt med endringar.

Tenester som må testast etter migrering:

  • notify_change_password - køyrer ein gang i veka, så har nokre dagar på oss til å sjekke at denne er ok.
  • BofhdRequest - Vanskeleg å teste utan å vere i produksjon.

3.1   Prodsettingsrutine

Ei felles sjekkliste som kan brukast for prodsetting av kvar instans.

  1. Send e-post til instansen om at vi tek ned Cerebrum.

  2. Varsle unix-drift si ukevakt om at vi tek ned instansen, så dei kan ignorere feil frå Nagios i perioden. TODO: Eller kan vi sjølv slå av Nagios-varsling midlertidig? Cerebrum drift kan dette. :)

  3. Stopp instansen på vanleg måte, som beskreve i driftsrutinene. Vent til alt er nede. Ingen jobbar skal køyre for instansen.

  4. Be DBA-drift om å ta ein kopi av databasen, i tilfelle vi må rulle tilbake.

  5. Ta ein kopi av ~/src/cerebrum, så det vert enklare å eventuelt rulle tilbake.

  6. Sjå til at det ikkje er lokale endringar i svn- og csv-trea. Desse bør enten bli reverterte eller bli sjekka inn.

  7. Køyr alle importar og eksportar. Dette er beskreve i planen over. Ta vare på eksportfilene.

    TODO: Skal vi lage ein sqldump, for å kunne samanlikne databasen også?

  8. Køyr alle jobbar som ikkje kunne bli testa i testmiljøet, til dømes AD.

  9. Køyr svn up og cvs up.

  10. Installer filene med: setup.py.

  11. Legg inn nye eventuelle konstantar med: makedb.py --update-codes

  12. Køyr alle importar og eksportar på nytt. Pass på å ikkje overskrive tidlegare data. Samanlikn resultatet med gamle data.

  13. Køyr i dryrun alle synkar som ikkje har kunne blitt køyrd i test. Sjå over loggen. Det skal vere minimalt med endringar.

  14. Start bofhd på ein beskytta port, logg på og sjå til at dei viktigaste kommandoane fungerer.

  15. Dersom alt er ok: Start Cerebrum-instansen att, som beskreve i driftsrutinene.

  16. Send e-post til instansen om at Cerebrum er oppe att. Be dei også varsle oss om dei oppdager feil.

3.2   Prodsettingsrutine for UiO

For UiO må vi gjere litt meir ved oppgradering.

  1. Send e-post til cerebrum-uio-varsel@usit.uio.no om at vi tek ned Cerebrum.

  2. Legg ut eller oppdater driftsmeldinga.

  3. Varsle unix-drift si ukevakt om at vi tek ned instansen, så dei kan ignorere feil frå Nagios i perioden. TODO: Eller kan vi sjølv slå av Nagios-varsling midlertidig? Cerebrum drift kan dette. :)

  4. Stopp instansen på vanleg måte, som beskreve i driftsrutinene. Vent til alt er nede. Ingen jobbar skal køyre for instansen.

  5. Be DBA-drift om å ta ein kopi av databasen. Dette så vi kan rulle tilbake i tilfelle problem.

  6. Legg til en "Header" merknad i webklientfilene for brukerinfo/Glemtpassord tjenesten TODO: flere sluttbrukerorienterte tjenester som vi bør huske å flagge som nede på en høfelig måte og teknisksett mener ikke å huske hvordan dette skal gjøres: hvilken indeksfil skal endres midlertidig osv. .

  7. Ta ein kopi av ~/src/cerebrum.

  8. Sjå til at det ikkje er lokale endringar i svn- og csv-trea. Desse bør enten bli reverterte eller bli sjekka inn.

  9. Køyr alle importar og eksportar. Dette er beskreve i planen over. Ta vare på eksportfilene.

    TODO: Skal vi lage ein sqldump, for å kunne samanlikne databasen også?

  10. Køyr alle jobbar som ikkje kunne bli testa i testmiljøet, til dømes AD.

  11. Oppgrader miljøet og migrer git:

    1. Køyr: cvs up ~/src/cerebrum_sites

    2. Flytt mappa: mv ~/src/cerebrum ~/src/cerebrum.old

    3. Køyr: svn up ~/src/cerebrum.old

    4. Sjekk ut Git-repoet:

      git clone https://utv.uio.no/stash/scm/crb/cerebrum.git ~/src/cerebrum

      Sjå til at mappa ikkje differ frå ~/src/cerebrum.old. Det vil vere nokre skilnader i modular som AD2, men som ikkje er i bruk for UiO. Diffen kan sjåast med:

      diff -rN ~/src/cerebrum ~/src/cerebrum.old

  12. Installer Cerebrum med setup.py.

  13. Legg inn nye eventuelle konstantar med: makedb.py --debug --update-codes

  14. Køyr alle importar og eksportar på nytt. Pass på å ikkje overskrive tidlegare data. Samanlikn resultatet med gamle data.

  15. Køyr i dryrun alle synkar som ikkje har kunne blitt køyrd i test. Sjå over loggen. Det skal vere minimalt med endringar.

  16. Start bofhd på ein beskytta port, logg på og sjå til at dei viktigaste kommandoane fungerer.

  17. Dersom alt er ok: Start Cerebrum-instansen att, som beskreve i driftsrutinene.

  18. Send e-post til instansen om at Cerebrum er oppe att. Be dei også varsle oss om dei oppdager feil.

  19. Skru på jobben notify_change_password i scheduled_jobs som var skrudd av (kommentert ut) for denne omgangen den skulle ha kjørt før vedlikeholdsvinduet i helgen.

TODO: Fyll ut med meir som må gjerast!

Av jokim
Publisert 2. apr. 2014 15:34
Del på e-post