Tilstades
- jsama
- tvl
- kvaade
- estephaz
fhl- jokim (ref)
Sak 1: Stagingmiljø
Vi diskuterer korleis vi kan få til det nye stagingmiljøet, etter slik vi har tidligare planlagt at det skal bli.
Vi kom fram til
- Utviklingsmaskiner har namneformatet: cere-utv*
- Stagingsmaskiner har namneformatet: cere-test*
- Vi bruker samme db-server, dbpg-cere-utv.uio.no, for både utvikling og staging. Alle veit at dei ikkje skal tukle med stagingsdatabasar
- Alle utviklarar og driftarar skal ha tilgang til alle stagingmaskiner. Alle veit kva dei ikkje skal tukle med.
- For å redusere risiko for manuelle feil og tukling i stagingmiljøa:
- Alt skal ligge i git, både kode og konfig. Det skal ikkje vere lagt inn manuelle endringar i eit stagingmiljø.
- Vi lager rutiner etterkvart som vi får behov for det
- Oppsettet av eit stagingmiljø skal, på sikt, automatiserast mest mogeleg, og med logging, som i prod.
- Vi treng overvåking av miljøa (zabbix)
- Namnet på databasar for staging skal reflektere at det gjeld staging
Utviklingsmaskiner
- cere-utv01 (RHEL5) - denne er gamal, fysisk og skal leggast ned
- cere-utv02 (RHEL6, må oppgraderast) - brukast i dag av Jenkins, og skal difor ikkje ha tilgang til prod-data, enn så lenge dette ikkje er avklart
- cere-utv03 (RHEL6, må oppgraderast)
- cere-utv04 (RHEL7) - hovudmaskina for utviklarane i dag
Prodmiljøet må automatisk overføre alt frå cache/ (tidlegare dumps/) til alle utviklingsmaskiner, med unntak av den som Jenkins har tilgang til. Dette må skje dagleg.
Det er ikkje lenger behov for overføring av config og kode, sidan vi forventer at master brukast.
Cerebrum drift må enkelt kunne overføre logs og anna debug-info, for Jira-saker, til cere-utv04 ved behov. (ref: Etter møtet kom det fram at det kan vere lurt om utviklarane får fortløpande tilgang også til loggar)
Kva som må gjerast:
- Oppgradere alle utviklingsmaskinene til RHEL7
- Sette opp automatisk overføring av cache/ frå prod til utviklingsmaskinene
- Sjekke ut Jenkins og tilgangar til prod-data
Stagingmaskiner
- cere-test01 (RHEL5, må oppgraderast!)
Oppsettet av stagingmiljø vil måtte vere fleksibelt, då det er behov for fleire ulike oppsett. Nokre miljø vil kunne ha behov for at databasen vert oppgradert frå prodmiljøet dagleg, andre vil evt. ha behov for å køyre importar frå td. SAP og FS. Det vil vere ulike brukargrupper som vil måtte kunne få tilgang til td. bofhd. Nokre vil måtte kunne snakke med andre system som er i prod, andre vil måtte snakke med andre stagingsystem. Vi må automatisere det vi kan, men unngå å begrense oss.
Cerebrum drift oppretter nye stagingmaskiner når det vert behov for det, til dømes grunna nye OS-versjonar. Sidan ein bruker virtualenv kan vi sette opp fleire, isolerte stagingmiljø på samme maskina.
Kva som må gjerast:
- Oppgradere cere-test01 til RHEL7
- Definere oppsett av stagingmiljø, gjort så det liknar mest mulig på prod, og så det kan eksistere mange stagingmiljø på samme maskin.
- Sette opp overvåking i Zabbix, og gjere det enkelt å utvide med overvåking når det settast opp nye stagingmiljø.
- Skrive ned rutiner, første versjon
Notatar frå tavla i løpet av møtet:
Sak 2: Oppsett av synk frå cerebrum test til ephorte kurs
Vi skal, fram til integrasjonen fungerer, oppdatere ePhorte sin kursbase gjennom den nye integrasjonen, som "staging". Vi ser på oppsettet av synk mot ePhorte kurs konkret. Kven gjer kva, og når.
Vi set opp ny ePhorte-integrasjon på cere-test01, og bruker dette som ein verifikasjon på at oppsettet som lagast fungerer.
Kva | Kven | Frist |
---|---|---|
Informerer eSAK om status | jokim | Fortløpande |
Merge master inn i EIS-branch, så koden fungerer for python2.7 | jsama | Gjort |
Oppdatere konfig, cerebrum_config for EIS for python2.7 | jsama | 30. okt |
Sette opp testmiljø på cere-test01: CRBD-293 | tvl | 26. nov |
Avklar om Jenkins må isolerast frå prod-data | jokim | 1. des |