Plan for sleggetest

1.1   Importere OUer

python ~/projects/cerebrum/cerebrum/contrib/no/generate_OU_xml_orgreg.py /site/h/dfo/orgreg_ou4.xml
python ~/projects/cerebrum/cerebrum/contrib/no/import_OU.py --clean --file system_orgreg:/site/h/dfo/orgreg_ou4.xml --file system_lt:/uio/kant/usit-uait-u1/h/projects/cerebrum/crb-config-uio/etc/cerebrum/eksterne_steder.xml --target-system=system_orgreg --logger-name tee --logger-level DEBUG

1.2   Importere personer (CRB-3659)

python ~/projects/cerebrum/cerebrum_hacks/migrate_to_dfo_ansattnr.py
python ~/projects/cerebrum/cerebrum_hacks/uio/dfo/queue_update_from_dfo_sap.py --file /site/h/dfo/ans_nummer_mapping.csv -c ~/projects/cerebrum/test_hacks/dfo-sap/hr-import-process.yml --commit --logger-name tee
python ~/projects/cerebrum/cerebrum/contrib/hr-import/process-tasks.py --config ~/projects/cerebrum/test_hacks/dfo-sap/hr-import-process.yml --logger-level DEBUG --commit --logger-name tee

1.3   Databasekopier

For å unngå å gjøre dobbeltarbeid med importer, så går det an å kopiere eksisterende databaser for eget bruk.

• cerebrum_uio_before_sap_import ("gammel" database slik den så ut før noen importer har blitt gjort)

• cerebrum_uio_after_orgreg_import_20210430 (database etter fullført orgreg-import)

• cerebrum_uio_after_sap_import_20210502 (ny cerebrum_uio_after_dfo_import_20210503)

  Database etter fullført hr-import. Det mangler fremdeles (minst) 152 ansatte. Noen av grunnene til det er:

  • Ansatte ved OU som ikke fins i orgreg (dfo_ou_id=10016752), eller som ikke har blitt importert (dfo_ou_id: 10017442 -> 10017444).
  • Ansatte som mangler fødselsnummer og passnummer (men har VAT-nummer).
  • Ansatte som ikke finnes (ennå) i DFØ-SAP selv om de var med i mappingen over ansatte som vi fikk.

  2777 ansatte har fremtidige endringer, som gjør at de må importeres på nytt senere.

2.1   Først

• [X] Sjekk importerte OU'er Sjekke diff av loggen fra kjøring av import_OU.py med logg fra kjøring som tilsvarer den som nå ligger i scheduled_jobs.py.

  Testet å legge inn nye endringer med kildesystem SAP slik at vi lettere kan diffe endringer via changelog.

  Resultat:

  • 200 OU'er har blitt opprettet
  • 224 OU'er har ny parent (inkludert nye OU'er)
  • 8 OU'er satt i karantene
  • Joakim har godkjent endringene

• [X] Kjør update_automatic_group_structure.py med ny og gammel database (CRB-3658) Sjekk diff av loggene, og verifiser at endringene gir mening.

  Resultat: ser ok ut. Mange endringer men gjenspeiler data fra OrgReg

• [X] Sjekk importerte personer (CRB-3666)

  Forslag til framgangsmåte: Køyr "fullsynk" av alle personar frå DFØ-SAP, og sjå i change_log over kva som har skjedd. Nokre elementer å sjekke:

  • [X] Antal nye personar. Er det under 100? (Ja, ingen nye personer)
  • [X] Antal nye affiliations: Tilsvarer det med antalet vi har frå SAPUiO?
  • [X] Antal endringar på person, til dømes namn: Kva er antalet? Viser stikkprøver at det er mindre endringar, eller er det totalt endra namn?
  • [X] Antal feilregistrerte som vert ignorert av Cerebrum: Mangler data? Desse bør evt. sendast til Mottak (Tone) for vidare feilsøking. (108 stk mangler data i DFØ, sendt videre til joakim/tvl)

Resultat: Ser ok ut.

Ingen nye personer. 8065 nye affiliations.

Antall aff lagt inn ved fullsync:

  status_str   | count
---------------+-------
 tekadm        |  3034
 vitenskapelig |  5022

Antall aff fra SAP:

  status_str   | count
---------------+-------
 tekadm        |  3800
 vitenskapelig |  5655
 ekst_stip     |   182
 emeritus      |  1072
 gjesteforsker |  2644
 ekst_partner  |   780
 innkjoper     |    24
 komitemedlem  |     5

Kun tekadm/vitenskaplige i DFØ sap i dag. Diff i tall er som forventet. Stikkprøver av endringer viser ingen eller små endringer. 108 personer mangler data i DFØ (Tone skal dobbeltsjekk om dette er folk som har sluttet).

• [ ] Kjør generate_accounts.py etter HR-import (CRB-3660)

  Forslag til fremgangsmåte: Se i scheduled_jobs på jobben generate_employee_accounts for hint om hvordan den kan kjøres. Diff med change_log:

  • Hvor mange personer er det som har fått opprettet minst en ny bruker? Viss det er over 100 kan det tyde på problemer. Er det (mye) færre enn antallet nye personer som fikk affiliation ANSATT oppretta av HR-importen, kan det også tyde på problemer. Samsvarer resultatet med hva man kan forvente ut ifra antallet nye importerte personer?

  Resultat:

  • Vi må bytte til å bruke DEFAULT_OU_PERSPECTIVE = 'OrgReg-tree' viss denne skal funke etter overgangen til DFØ-SAP.

• [X] Kjør populate-automatic-groups.py etter HR-import og OrgReg-import (CRB-3657)

  Forslag til fremgangsmåte: Kjør jobben og bruk change_log for å diffe resultat.

  • Antallet nye grupper av hver type (meta-ansatt, ansatt, tilknyttet) bør være mindre eller lik antallet nye OU-er som har blitt oppretta av OrgReg-importen.
  • Viser stikkprøver at de som får endra medlemskapet sitt har blitt meldt inn i grupper de har tilknytning til?

  Resultat: ser ok ut

  • Kjørt med argumenter --perspective OrgReg-tree --source-system system_dfo_sap, og ellers som i prod.
  • Det opprettes totalt 595 nye grupper, men for hver OU opprettes det 4 grupper gitt at det fins ansatte og tilknyttede. 595 / 4 = 150 som er mindre 200 som er det totale antallet nye OU'er. Antallet virker altså OK.
  • Stikkprøver viser at personer har blitt meldt inn i riktig gruppe.
  • 4 grupper slettes. Alle tilhører stedkode 170002. Dette er nok som forventet. Det var få OU'er (ca 8) som ble satt i karantene ved import fra OrgReg. Virker riktig at kun 1 av disse hadde gjenstående aktive ansatte.

2.2   Etterpå

Når vi har gjort alt fra forrige steg så bør det opprettes en ny databasekopi hvor alle endringene er med. Da kan hver person branche ut fra den databasen. Det kan være lurt å først kjøre scripts med "gammel" database først (dvs cerebrum_uio_before_sap_import), og lagre loggen fra kjøringen. Da kan man etterpå kjøre scriptet med oppdatert database og argumenter. Å endre argumenter består stort sett i å bytte perspective til OrgReg-tree og bytte source-system til DFO-SAP. Da kan man diffe loggene fra kjøringene (gjerne sorter linjene i loggfilen først), og se hvor mange endringer det er, og om disse er som forventet.

Ting å se etter:

• Kjører eksporten uten Exception, ERROR og WARNING?
• Har det blitt opprettet veldig mange nye personer/brukere (over 100) kontra kjøring med "gammel" database?
• Har det blitt slettet mange brukere, personer, grupper etc kontra kjøring med "gammel" database?
• Ta et par stikkprøver, og verifiser at endringen er som forventet basert på affiliations, brukerkonto, gruppemedlemsskap etc.

Oppgaver som må gjøres:

• [X] Kjør AD-eksport med ny og gammel database (CRB-3667)

  Denne oppgaven er stor og kan muligens deles av flere. Vi bør kjøre så mange av AD-jobbene som mulig, spesielt fullsyncer.

  Tips som kanskje er nyttige:

  • Noen AD-syncer har mulighet for å synce mot mock (de som bruker skriptet sync.py). Da kan man kjøre en mock sync med --store-mock-state med "gammel" database først, for så å kjøre med --load-mock-state etterpå. Da vil loggen gjenspeile endringer som blir gjort.

  Resultater:

  • Fullsync av grupper ser ut til å fungere som ventet. Det opprettes mange flere automatiske ansatt-grupper når man kjører med ny database kontra gammel. I tillegg opprettes det noe færre tilknyttet grupper. Stikkprøver viser at de tilknyttet-gruppene som ikke blir opprettet hører til OU'er som ikke har tilknyttede fra DFØ-SAP. Dette stemmer også med at det totalt sett er færre tilknyttede fra DFØ-SAP (1746) kontra gamle SAP (4707).
  • Fullsync av accounts ser ut til å fungere som ventet. Det opprettes flere kontoer med ny database kontra gammel database. Det ser ikke ut til at noen av kontoene som ble syncet med gammel database utelates.
  • ad2_xpand_groupsync gir få forskjeller, men det blir noen færre brukere (ca 20 stk) når syncen kjøres med ny database.
  • ad2_consent_gsuitesync gir ingen forskjeller.
  • ad2_affiliationsync gir ingen forskjeller.
  • Ingen av quicksyncene har blitt kjørt.

• [ ] Kjør LDAP-eksport og gå over endringene (CRB-3668)

  Denne oppgaven er stor og kan muligens deles av flere. Vi bør kjøre så mange av LDAP-jobbene som mulig (spesielt ldif_org, ldif_group, ldif_posix etc)

  Tips som kanskje er nyttige:

  • Filer som blir generert bør sammenlignes med den tilsvarende filen som ligger på cere-utv04 under /cerebrum/uio/var/cache/LDAP
  • Noen av LDAP-skriptene (feks generate_groups_ldif.py) har mulighet for å generere cache-fil på json-format som man kan bruke til å sammenligne endringene.
  • De fleste av skriptene tar argumentet --max-change, og bruker SimilarSizeWriter som vi kan bruke til å verifisere at endringen i filstørrelse ikke blir for stor.

2.3   Til slutt

Hvert skript i scheduled_jobs som bruker perspective_sap eller system_sap må endres til å heller bruker perspective_orgreg_tree og system_dfo_sap. Før vi gjør hver endring i produksjon så bør (ideelt sett) hvert skript først kjøres på cere-utv04, og loggene verifiseres.