Modulutredning

Innledning

Fra Jira:

Som utviklar treng eg å finne ut kva i Cerebrum som kan gjerast om til modular, og kva som tilhøyrer core. Dette så eg kan refaktorere og skille det ut frå Cerebrum core.

Hva er egentlig en modul?

Saken bruker ordet modul, og det er et ord med flere betydninger. Modul i Cerebrum-sammenheng er her litt løst definert, for Python definerer modul som det samme som i C++ ville hett kompileringsenhet, altså mer eller mindre det samme som en fil. Men moduler er også brukt som valgfrie tillegg til Cerebrum-core, som også kan ha egne databasetabeller. Disse modulene har så en egen versjonering.

Parallelt med denne utredningen er det blitt implementert en proof of consept for modulbasert Cerebrum. denne har ikke bygget ut modulene, men sørget for:

  • Definere core som en modul
  • Pluggbar factory
  • Ulike moduler kan settes inn
  • Moduler kan avhenge av andre moduler
  • Eksempel på modul

I så måte er en modul definert av et eget objekt som vet hvilke mixins osv. som modulen setter inn. (I dag gjøres dette manuelt for hver enkelt komponent i cereconf)

En modul bør så også organiseres slik at koden tilhørende en modul er logisk samlet (foruten ev. tester og konfigurasjon).

Cerebrum core

Cerebrum core er i dag:

  • Database-håndtering - Metainfo (versjonering)
  • Entity-treet: - Entity - Account - Person - Group - Disk - OU (med struktur)
  • Tilbehør - quarantine - account home - entity name - person name - External id - spread - contact info - address - name med språk - affiliations - account type - account authentication
  • Utils (her factory)
  • Constants + Change log constants
  • Dummy-kode for change log
  • Config
  • Client API

I tillegg kommer scripts for installasjon og database (setup.py og makedb.py).

Det finnes også gammelt rask:

  • extlib (eksterne biblioteker)
  • clients (tidlig forsøk på serverabstraksjon?)

Det er dog vanskelig å se for seg Cerebrum uten change log og loggeren.

Changelog

mod_changelog er i dag ikke en del av core, men fordi changeloggingen må gjøres også i core, er tilhørende konstanter det. Men changelog-konstantene skal egentlig bare være i CLConstants, uten at dette er godt nok implementert. En mixin til Database aktiverer CL-funksjoner: CLDatabase. Men disse funksjonene brukes ukritisk av så godt som alt som skriver til basen, inkl. makedb.py. Dette kan skilles ut ved

  • CLConstants har bare changelogattributter
  • Vanlig Constants har ikke
  • Default for CLConstants er en __getattr__() som returnerer noe når changelog ikke finnes.
  • CLDatabase-funksjonene bør inn i database

Dette løser dog ikke noe, da en del moduler trenger changelogstøtte.

Uansett bør vi skille CLConstants fra Constants og slå sammen CLDatabase med Database? Kanskje bør CL være core? Man kan vel iallfall slette CL-classene og integrere noop-kallene i core?

Hva kan gå?

Et core bør være en minste brukbare Cerebrum. Vi har spesielle versjoner av Cerebrum, som TSD og Virthome, som viser at mange konsepter er overflødige. Sånn sett kan man ta utgangspunkt i at Cerebrum er et brukeradministrasjonssystem, og da trengs account, group og person. I tillegg trengs:

  • entity name
  • spread
  • account authentication
  • external id
  • quarantine (kanskje)

I tillegg trengs det vel ikke nevnes database, constants, config og utils. Change log og logging er diskutert over. External id og person bør her også være med da Cerebrums hovedstyrke er å kombinere data fra diverse kildesystemer.

Quarantine

Karantenehåndtering kan kanskje flyttes ut av core. Tabellene quarantine_code og entity_qurantine kan isåfall flyttes ut i egen modul med klassen EntityQuarantine fra Cerebrum.Entity og filen QuarantineHandler. Note: klassene Account, Group, Person og OU arver fra EntityQuarantine.

Harde avhengigheter:

  • Stort sett alle instansspesifikke greier
  • Cerebrum.modules.ad2.ADSync (kun QuarantineHandler)
  • Cerebrum.modules.PosixExport
  • Cerebrum.modules.PosixLDIF
  • Cerebrum.modules.PasswordNotifier
  • Cerebrum.modules.xmlutils.object2cerebrum
  • bofhd_guest_cmds
  • cis.auth og cis.Individuation
  • OrgLDIF

Alle metodene har «_entity_quarantine» i navnet eller bruker Cerebrum.QuarantineHandler.

OU

Organisasjonsstrukturen i OU kan fint skilles ut. OU tar også med seg affiliations og account types, og har dermed avhengigheter i person og account. Vi har også ting som stedkode som igjen avhenger av OU. OU kan flyttes til egen modul, men om dette er hensiktsmessig, er jeg usikker på. mod_ou vil isåfall ta med seg affiliations og account types, og dermed vil man endre både Cerebrum.Person.py og Cerebrum.Account.py for å ta ut dette i egen modul.

Host og Disk

Disse klassene ser ut til å være i core fordi konti jo trenger en hjemmekatalog. Men gjør de det? Vi har wifi-konti og webid, som motbeviser tesen. Med DNS-modulen er kanskje også konseptet host i core noe forvirrende? Ønsker å flytte denne til en homedir-modul.

Diverse

Modulen Cerebrum.Cache inneholder smarte cache-løsninger. Kan enkelt flyttes til en modul. Avhengigheter: Cerebrum.Database og bofhd-kommandoer.

Cerebrum.https Cerebrum.SqlScanner

Filen Cerebrum.CLDatabase inneholder felleskonsepter for ulike databaseimplementasjoner. Dette kan fint skilles ut i en modul som ulike CL-implementasjoner bruker (om nødvendig).

Factory

Factory har disse komponentene:

  • primærcore

    • Database
    • Constants
    • Entity
    • Person
    • Account
    • Group
    • DBDriver

  • sekundærcore

    • OU
    • Host
    • Disk
    • CLConstants
    • ChangeLog

  • annet

    • EmailTarget
    • OrgLDIF
    • EmailLDAP
    • PosixExport
    • PosixLDIF
    • PosixUser
    • PosixGroup
    • DistributionGroup
    • Project
    • Allocation
    • AllocationPeriod
    • LMSImport
    • LMSExport

I branch for konseptuell modulstøtte tas DBDriver ut av factory. I tillegg foreslår jeg å fjerne konseptet CLConstants, samt å slå CLDatabase-funksjonene inn i Database. Det nye modulrammeverket vil også kunne sette inn komponenter ved behov.

Avhengigheter

En enkel måte å lage feil på er ved å introdusere nye uavhengigheter uten å angi dette. F.eks. er det enkelt å glemme å vedlikeholde versjoneringen av databasemoduler i Cerebrum (må angis i sql-fil, python-modul og tabell i makedb.py). Med moduler blir det enklere, da makedb blir mer intelligent. Moduler kan også angi avhengigheter, og det bør også være mulig for scripts å si noe i retning av require modulnavn, og dette kan dermed sjekkes dynamisk.

I tillegg foreslås det å lage et script som sjekker

  • import statements og
  • bruk av metoder fra mixins i scripts

mot kjente moduler. Dette vil da lett kunne rapportere manglende require-angivelser.

Konklusjon

OU, Host og Disk kan ryddes ut av core. Changelog bør integreres tettere, men det er ikke gitt at tabellen change_log skal inn i core.

Publisert 27. sep. 2018 19:25
Del på e-post