NAV-ref Home

Tilstede:

• Peder Smart Sefland, HiVolda
• Rune Kittelsen, UiA
• Øyvind Nesland, UiA
• Børge Brunes, UiT
• Nils-Arild Grav, NTNU
• Sigurd Refvik, UiO
• Morten Werner Forsbring, UiO (Forlot møtet etter ca. 1 time)

• Vidar Faltinsen, Sikt
• Hanne Moa, Sikt
• Johanna England, Sikt
• Simon Oliver Tveit, Sikt
• Ilona Podliashanyk, Sikt
• Morten Brekkevold, Sikt

Forfall:

• Ingeborg Hellemo, UiT (Børge Brunes er stedfortreder)

Møtet blir avholdt som videokonferanse vha. Zoom, fra kl. 09:00 til 12:00.

Morten ønsker velkommen på vegne av Sikt.

Det har siden sist ikke skjedd stort på funksjonalitetsfronten i NAV. Utviklerteamet har i hele år vært i innspurt på andre prosjekter enn NAV, og det var også grunnen til at det ble et halvår mellom forrige møte og dette. Disse prosjektene begynner å komme i mål, og Sikt ønsker derfor fornyet satsing på NAV i 2025.

Teamet har fortsatt jobbet iherdig med å blitt kvitt teknisk gjeld, slik at NAV vil være i stand til å kjøre på Python 3.11 - og dermed også på OS-distribusjoner som fortsatt vil få sikkerhetsoppdateringer i tiden fremover. Imidlertid har vi siden sist møte funnet en fungerende strategi, og jobber med å bli kvitt avhengigheter som holder oss fast på gamle Python-versjoner.

Overordnet issue her er Make nav run on python3.11 #2788, men det forløsende arbeidet ligger i Get rid of crispy-forms #2794.

Vi har hatt sommerstudent Jørund på plass i hele sommer og på deltid i høst, til å jobbe med DHCP-statistikkinnsamling fra KEA DHCP-tjenere, og har kommet mye lenger i en brukbar definisjon av hvordan DHCP-statistikk skal se ut og integreres i NAV. Jørund ser i den forbindelse også på hvordan vi kan få inn management profiles for utstyr som støtter REST-API-er, noe som i første omgang er aktuelt å ta i bruk ifm. Palto Alto-bidraget fra UiT. Vi satser på at begge disse bidragene skal bli tiljgengelige i NAV 5.12 før året er omme.

På forrige møte ble det vedtatt et aksjonspunkt som vi dessverre ikke har fått jobbet med:

Sikt utarbeider en redegjørelse for status på, og evt. manglende
spesifikasjon av de enkelte punktene på arbeidslisten og sender ut denne til
nav-ref for vurdering i forkant av neste møte, slik at alle har et
utgangspunkt for å vurdere/revurdere hva som står på listen.

Vi foreslår å utsette dette til neste gang. Det tegner uansett til å bli behov for mer tid til å diskutere nye behov i NAV i dette møtet.

1 feature-release siden forrige møte: NAV 5.11.0

Sikt tilbød, på tampen av 2023, hele sektoren å få en gratis sky-deployment av Argus i 2024, som et slags pilotprosjekt. Ingen har meldt seg interessert i dette. Derimot har et par kunder uttrykt ønske om å få Argus på verktøykassen i stedet for i sky. Dette er noe vi vurderer for 2025.

Som tidligere nevnt har GÉANT NOC fattet interesse for Argus, og mye av 2024 har vært brukt på å bygge et nytt brukergrensesnitt til Argus, basert på HTMX. Dette er teknologi som hele utviklerteamet behersker, det gjør Argus-grensesnittet mer tilgjengelig for skreddersøm (som er den viktigste funksjonen for GÉANT) og det gjør det enklere å installere og drifte en Argus-installasjon.

• Hva er det konkrete behovet bak Log changes to IP Devices #1501? Hvordan skiller det seg fra Lifecycle events #1997?
• Forrige gang meldte UiT inn et ønske relatert til en ny generasjon miljøprober fra Comet. Det ble et aksjonspunkt på å dokumentere dette i issue-tracker, men det ble kanskje uklart hvem som utfører?

Runde rundt “bordet”. Skriftlig innmeldte saker tas først.

• Støtte for VRF
• ARP-innsamling fra Cisco ACI
• Cam-data blir ikke samlet inn fra SRV/OTHER ([BUG] CAM data not collected for devices of type SRV and OTHER #2915)
• Lage statusrapport for gitt tidsperiode (Status report for given time period #1666)
• Andre bugs som er meldt inn og trenger litt TLC:
  • [BUG] Alert profile filter - list_limit reached #2908
  • Deleted netboxes should be deleted from Maintenance tasks #2243

Sikts CNaaS-team har meldt inn sin egen prioriterte liste over ønsker/problemer i NAV:

1. Støtte for Palo Alto: ARP + ruterportliste m.m.
2. Topologiavledningen “fungerer ikke” - workshop for å se på konkrete case - og jakte bugs
3. Portadmin: config template / port profil
4. Portadmin: Se livedata - hvem er pålogget en port
5. Linkstat: ønsker å ha stat på peak-in og peak-out - altså samle på max verdier for historien
6. CPU-stat: se avg verdi over 5 min
7. Dashboard-deling som oppdateres når dashboard eier gjør endringer i sitt “master dashboard” (use case: vi setter opp et delt dashboard til CNaaS-kunder og så utvikler vi det dashboardet over tid)
8. PAT-statistikk - ønsker å se ledige TCP og UDP porter i NAT poolene
9. Støtte for Aruba CX-svitsjer (svitsjeporter, brotabell) (må kanskje bruke REST API?)
10. Støtte for Dell blade svitsjer (svitsjeporter, brotabell)
11. Hente inn faktisk strømforbruk fra power supplies på utstyr. Da kan vi regne på faktisk strømforbruk og det er interessant i disse bærekraftstider

1. Øyeblikksbilde/livedata av portstatus på SDA-svitsj (eks VRF (VN), VLAN, SGT, Autentisering, type utstyr, maskinnavn, IP, MAC, hastighet, link, portbeskrivelse)
2. Tilgangsstyring for kun tilgang til endring av portbeskrivelse
3. Mulighet for registrering av utstyr(MAC) for MAB-autentisering, ref iotroam-løsning presentert i tidligere NAV ref-gruppemøte
4. Dot1x-admin på Cisco-svitsjer utenfor SDA
5. Last seen-filteret - ønsker mulighet for også å kunne se alle porter med aktivitet nyere enn x dager. I dag er det kun mulighet til å vise porter som ikke er brukt etter mer enn x dager.
6. MFA-innlogging ønskes i NAV, ref #2613

Vi velger neste møtedato. Medio mars?

Morten ønsket velkommen på vegne av Sikt. To nye (avhengig av hvordan man ser det) fjes stilte i møtet, slik at møtet startet med en presentasjonsrunde.

• Rune Kittelsen (UiA) pensjonerer seg i 2025. Øyvind Nesland stilte som hans potensielle arvtaker i gruppen.
• Morten Werner Forsbring stilte i tillegg til Jan Sigurd Refsvik for UiO. Morten Werner er seksjonssjef for Nettdrift på UiO, og var også NAV-utvikler for mange år siden.
• Børge Brunes stilte som stedfortreder for Ingeborg Hellemo (UiT). Børge satt i nav-ref i flere år før Ingeborg tok over, så han kjenner allerede gruppen godt.
• Peder Smart Sefland meddelte at dette dessverre ble hans siste møte i referansegruppen, da han har sagt opp sin stilling ved HiVolda for å bli selvstendig næringsdrivende. Andreas Høydalsvik blir mest sannsynlig hans arvtaker i gruppen.

Morten gjorde rede for status på NAV og Argus, for det meste slik det fremkom av agenda.

Ingen i gruppen hadde tilbakemeldinger på hvordan Log changes to IP Devices #1501 egentlig skal fungere, gitt at Lifecycle events #1997 allerede ferdigstilt. Det kan tyde på at oppgaven er overflødig, men vi får se når vi tar en ny avstemning på arbeidslisten.

UiT har (som nevnt på forrige møte) kjøpt et nytt miljøprobe-produkt fra Comet, som dessverre ikke er støttet av NAV i dag (Comet er en leverandør som ser ut til å produsere en helt ny MIB for hvert produkt de lager). AKSJON UiT tar selv ansvar for å lage et NAV-issue med ønske om støtte for produktet, og dokumenterer ved å legge ved den relevante MIB-definisjonen.

UiT og Sikt/CNaaS sendte inn skriftlige punkter i forkant. NTNU la inn skriftlige punkter underveis i møtet.

• Ønsker støtte for VRF i NAV.
  • Litt uklart hva “støtte for VRF” egentlig vil si, og dette avstedkommer en liten diskusjon om hvordan forskjellige deltakere i gruppen bruker VRF-er.
  • Et aspekt som blir nevnt er at UiT ønsker å legge til alle virtuelle ruterinstanser som egne IP devices i NAV for å overvåke dem individuelt, men at man da helst vil unngå flerdobbel SNMP-belastning av de som er en og samme fysiske boks.
    • Morten påpeker at sistnevnte allerede er støttet i NAV ved å registrere en “master device” under Advanced options i SeedDB-siden for IP Devices.
      • AKSJON: Funksjonaliteten er dessverre ikke beskrevet noe annet sted enn i release notes for NAV 4.7, så dette bør nok dokumenteres bedre.
      • UiT skal teste hvor godt denne funksjonaliteten dekker deres behov.
  • Et annet aspekt som kanskje mangler er innsamling av data som bare fins på hver enkelt VRF. Dette fungerer kanskje fint så lenge man har en management-adresse per VRF og registrerer disse i NAV, men Knut-Helge kommenterer at CNaaS ikke gir egne management-adresser til VRF-er, og at NAV kanskje mangler ruting-informasjon for enkeltinstanser.
    • AKSJON: Uklart om VRF i CNaaS faktisk har problemer med NAV, om det i så fall er utstyrsspesifikt eller config-spesifikt. Må diskuteres internt.
  • UiT nevner også et behov eller manglende støtte for overvåkning på lag 3, dvs. logiske linker mellom VRF-er som går ned, selv om fysisk link mellom boksene er oppe. Det er litt uklart hva som egentlig mangler her, og det bør UiT greie ut for i en egen VRF-issue.

AKSJON: Lag et GitHub-issue for å kartlegge evt. nye behov for VRF-støtte i NAV og be de som er interessert i dette kommentere på issuet.

• UiT gjentar et ønske om støtte for Cisco ACI (Application Centric Infrastructure, en Cisco-implementasjon av SDN) i NAV. Dette har vært nevnt også i tidligere møter.
  • En Cisco ACI-kontroller kan ses på som en avansert ruter. Denne kommuniserer man fortrinnsvis med gjennom API-er, ikke gjennom SNMP.
  • AKSJON: Lage et GitHub-issue om ACI og be UiT spe på med informasjon der.
    • Fetch ARP data from Cisco ACI (Application Centric Infrastructure) API #3220
• UiT ønsker å trekke frem denne igjen: (Status report for given time period #1666)
  • Det er litt uklart hva dette skal inneholde, men prinsipielt skal Device History tilby slik funksjonalitet - men filtermulighetene her er ikke gode nok for UiT.
  • CNaaS har en custom SQL-rapport i NAVs rapportsystem for hendelser siste 24 timer. Siden dette ligger i SQL-rapportsystemet er det ikke veldig fleksibelt, men kan dekke opp for noe av behovet for UiT.
    • AKSJON: Denne rapporten bør distribueres med NAV så alle har et eksempel de eventuelt kan tilpasse selv
  • AKSJON: Vurdere å lage et eget GitHub-issue for å tenke nytt rundt Device History-verktøyet (i.e. ta idéer fra, eller smelte sammen med, status-verktøyet).

• UiT trekker fram et gammelt issue som ble forsøkt løst for mange år siden, men hvor endringen måtte rulles tilbake: ([BUG] CAM data not collected for devices of type SRV and OTHER #2915)
• AKSJON: Kartlegg hva som skjedde sist dette ble forsøkt løst og legg inn som en kommentar på #2915

• UiT ber også om oppmerksomhet for to bugs de tidligere har meldt inn:
  • [BUG] Alert profile filter - list_limit reached #2908
  • Deleted netboxes should be deleted from Maintenance tasks #2243
    • Det fremgår at det fremdeles var litt uklart hva beste løsning her egentlig er, da UiT og utviklerne er litt uenige om beste fremgangsmåte.
    • Vi diskuterte oss frem til en viss enighet om at slettede bokser ikke skal forsvinne i løse luften fra maintenance-tasks, men at tasks som ikke lenger har igjen gyldige komponenter i seg automatisk skal kanselleres av NAV.
    • AKSJON: Utviklerteamet oppdaterer #2243 og lager et forslag til løsning/
  • Begge bugs ble lagt i backlog for inneværende sprint. Det betyr ikke nødvendigvis at vi rekker over dem, men det øker teamets oppmerksomhet på dem.

• Til sist rekker Børge slenge inn et kommentar om at UiT gjerne skulle ønsket støtte for overvåkning av OSPF i NAV, men det blir ingen diskusjon om innholdet i forslaget, så UiT henvises til å poste et issue GitHub-trackeren om det.

Sikt/CNaaS raste gjennom sin egen ønskeliste uten at det ble noen større diskusjon om innhold eller løsningsforslag. Slik diskusjon kan evt. lett tas på “bakrommet”, da utviklerne stort sett har fysisk kontorsted i samme lokale som CNaaS-teamet.

• CNaaS har også behov for ARP-innsamling fra Palo Alto-brannmurer, etter å ha tatt over noen fra nye kunder. Men, det er dessverre bugs i tillegget som UiT bidro med.
  • AKSJON: Utviklerne registrerer GitHub-issue på den aktuelle buggen i Palo Alto-pluginen i ipdevpoll.
    • [BUG] ARP records from Palo Alto firewalls keep getting closed and re-opened #3252
• CNaaS registrerer også at det fullstendig mangler informasjon om ruterporter fra Palo Alto-brannmurer.
  • Dette er formodentlig også fordi disse brannmurene heller ikke svare på de relevante MIB-ene med IP-informasjon.
  • AKSJON: Lage GitHub-issue om støtte for ruterport-innhenting fra Palo Altos API.
• CNaaS-teamet opplever problemer med NAVs topologiavledning på en del kundenett.
  • Dette tas opp i en intern workshop, for det krever en litt interaktiv debug-sesjon med en interaktiv feedback-cycle mellom utviklere og nettverksingeniørene.
  • AKSJON: Knut-Helge tar initiativ til en workshop om topologiproblemer.
• CNaaS-teamet ønsker seg “portprofiler” i PortAdmin.
  • Dette er i prinsippet Support port profiles/templates in PortAdmin #2598. Kommentarer om implementasjonsvalg og design bør legges der.
  • AKSJON: Knut-Helge bør lese #2598 og kommentere der om han har noe konkret å tilføye, f.eks. for Juniper-utstyr, som CNaaS bruker.
• Kan tenke seg å se “live” portdata om 802.1X-tilstand på en port
  • F.eks.
    • Dynamisk valgt VLAN
      • NAVs VLAN-data for en port er potensielt opptil 6 timer gammelt, men er det noen grunn til at den VLAN-verdien NAV allerede samler ikke skulle være den samme som er dynamisk valgt av 802.1X?
    • Pålogget brukernavn
      • Er dette innafor personvernmessig sett, tro?
  • AKSJON: Knut-Helge bør evt. kommentere på de punktene som allerede er observert under Is it possible to show more information about 802.1X enabled ports? #1936
• Oktett-tellere på porter blir i dag aggregert over tid med gjennomsnittsverdier. Her ønsker CNaaS-teamet at det også ble aggregert minimums og maksimumsverdier (slik det ble gjort da NAV brukte rrdtool.
  • AKSJON: Utviklerteamet lager et GitHub-issue og dokumenterer behovet for Graphite-research, da Graphite ikke umiddelbart støtter multiple aggregeringsmetoder for samme metrikk. Fører formodentlig til tredobling av lagringsbehovet, om vi finner en løsning.
• Mener CPU-lastdatene som hentes inn av NAV i dag er et øyeblikksbilde som er kunstig forhøyet i innsamlingsøyeblikket pga. utstyrets arbeid med å besvare SNMP-forespørselen som henter dataene. Det påstås at det skal være mulig å hente ut gjennomsnittsverdier for siste 5-minuttersperiode i stedet.
  • AKSJON: Kilde for dette er visstnok Vidar Stokke, som også har noen MIB-referanser. Han bør snarest opprette et GitHuub-issue som dokumenterer behovet og aktuelle MIB-er.
• Ønsker muligheten for deling av dashboards mellom brukere
  • Allerede notert i Add shareable dashboards to NAV #2344
• Ønsker innsamling av Port-Address-Translation-data fra Juniper SRX-brannmurer. Uklart både hvordan dette skal fungere i NAV eller hvor dataene kan hentes fra.
  • AKSJON: Knut-Helge bes registrere issue på GitHub for å dokumentere behovet.
• Ønsker støtte for VLAN-informasjon og CAM-data fra Aruba CX-switcher.
  • Dette fungerer ikke i NAV i dag, primært fordi Aruba CX ikke implementerer Q-BRIDGE-MIB (slik de fleste leverandører gjør), men tilbyr i stedet IEEE8021-Q-BRIDGE-MIB.
  • AKSJON: Utviklerteamet registrerer GitHub-issue om Aruba CX.
• Ønsker støtte for VLAN-informasjon og CAM-data fra Dell Blade-switcher.
  • Denne problemstillingen er ny for utviklerteamet, så det er vanskelig å si hvorfor dette ikke fungerer i dag.
  • AKSJON: Utviklerteamet registrerer GitHub-issue om Dell Blade-switcher
• Til sist kom det inn et ønske med et bærekraftsperspektiv: Kan NAV hente inn informasjon om faktisk strømforbruk fra utstyr?
  • Litt uklart her hva som skal hentes inn. CLI gir formodentlig mulighet for å hente ut et øyeblikksbilde på effektforbruk (Watt), men dette sier jo ingenting om energiforbruk over tid (Watt-timer).
  • Effektforbruk kan grafes, men hvordan oppsummerer man best energiforbruk over tid?
    • Om man samler inn effektforbruk hvert minutt kan man f.eks. estimere energifobruket for dette minuttet ved å multiplisere effektforbruket med en faktor på 1/60 (en PSU som forbruker 1000W konstant i 60 sekunder har forbrukt ca. 16.7Wh).
  • Hvordan er MIB-støtten for å hente ut slikt på forskjellig utstyr?
  • AKSJON: Utviklerteamet kan registrere et GitHub-issue, men dette krever noe kartleggingsarbeid som CNaaS-teamet selv må fylle på med.
  • Chatlog fra Vidar F:

Eksempel her er en boks med to stykk strømforsyninger på 920W. Men den bruker faktisk bare 76+16W.

fpc 0:
-------------------------------------------------------------------------
            PSU 0    (JPSU-920W-AC-AFO   )           :     860 W   Online
            PSU 1    (JPSU-920W-AC-AFO   )           :     860 W   Online
            Power redundancy configuration           :     N+0
            Total power supplied by all online PSUs  :    1720 W
            Base power reserved                      :     120 W
            Non-PoE power being consumed             :      76 W
            Total power allocated for PoE            :    1440 W
            Total PoE power consumed                 :      16 W
            Total PoE power remaining                :    1424 W
  

• Gjentar ønsket om at NAV samler inn ytterligere port-data fra Cisco SDA (Software Defined Access). Sist nevnt på navref_050324
  • AKSJON: Morten finner tilbake skjermbildet Nils-Arild oversendte den gangen og oppretter et GitHub-issue.
    • Fetch switch port VN (VRF) and Security Group Tag (SGT) from Cisco SDA #3217
• NTNU bruker aktivt søket Last seen (days ago) under fanen Netbox interfaces i et Room-view (/search/room/<roomid>/#!netboxinterfaces) for å finne porter som ikke har vært i bruk de siste N dagene. Men, de kan også tenke seg et invertert søk, altså formodentlig at man kan vise alle porter som *har vært i bruk* de siste N dagene.
  • AKSJON: Utviklerteamet lager et GitHub-issue og ber Nils-Arild kvalitetssikre det.
• Ønsker seg muligheten til å begrense PortAdmin-brukere til å bare konfigurere port-description, ikke VLAN og andre ting.
  • AKSJON: Utviklerteamet lager et GitHub-issue og ber Nils-Arild kvalitetssikre det.
• Control over 802.1X options per port in PortAdmin #2164 er selvfølgelig fremdeles et ønske for NTNU, men det blir mindre og mindre relevant etter hvert som det nye nettet overtar for det gamle.
• Ønsker også Support for MFA (multi-factor authentication) #2248 på grunn av interne sikkerhetskrav.

UiA har ingen spesielle ønsker de vil trekke frem denne gang, ut over at de ønsker seg Argus som nytt verktøy på verktøykassen.

Morten Werner måtte forlate møtet tidlig, men etterlot seg en skriftlig liste som Jan Sigurd gikk gjennom.

• UiO støtter arbeidet med å komme opp på siste Debian Stable (python3.11-jobbinga).
• Databaseskjema - er det noen tanker med å se på hvordan man kobler sammen tabeller, overgang til relasjonell databasemodell?
  • AKSJON: Det var uklart for både møtet og Jan Sigurd hva Morten Werner mente med dette punktet, all den tid NAV alltid har brukt en relasjonsdatabase. Kan Werner klare opp i kommentaren?
• Overvåking av transceivere - hente ut alarmgrensene med alarmer ved overskridelse.
  • Morten B formoder dette dreier seg om at transceivere som regel kommer med egne hardkodete terskelverdier som kunne vært avlest og benyttet av terskelregler i NAV. Dette mener har i alle fall å huske har vært en diskusjon i stamnettsgruppa på Sikt.
  • AKSJON: Morten B leter opp om han har noe underlagsmateriale om transceiverterskler fra før.
• Overvåking av bias-spenning på tranceivere for å se at disse ikke endrer seg.
  • Morten B mener dette muligens allerede samles inn og grafes, i alle fall for Cisco. Dette registreres som sensorer på en boks, men det er ikke alltid garantert at NAV klarer å koble en sensor opp mot en spesifikk port på boksen, slik at den i stedet blir liggende i den generelle oversikten over sensorer som fins på boksen.
  • Jan Sigurd fant muligens en slik sensor da han så etter i egen NAV-installasjon, og det ble spørsmål om ikke NAV kunne tilby manuel kobling mellom en sensor og en port om ikke NAV oppdaget dette automatisk.
  • AKSJON:: Jan Sigurd eller Werner verifiserer om de finner de aktuelle datene i sin NAV-installasjon. Anbefales å opprette GitHub-issue om de ikke gjør det, eventuelt opprette issue på manuell kobling mellom sensorer og porter, som for så vidt er en god idé.
• Noe som har kommet opp ifm. Vikingtidsmuseet og grønt IT er mulighet for å gjøre noe med PoE-porter på kvelds- og nattestid (natt-senking eller skru helt av på kveld/natt), kanskje løst med kron på switchene. Ikke sikkert det er riktig å gjøre noe med dette i NAV, men greit å høre om dette er noe andre har tenkt på eller er interessert i.
• Litt diskusjon rundt dette avstedkom egentlig ingen gode svar, men heller ingen sterk mening om at dette hører hjemme i NAV.
• UiT mener at Cisco allerede har noe funksjonalitet som tar ned aksesspunkter via PoE der det er lite behov for dem. Dette har vært så irriterende at de har pleid å slå det av.
• Morten B foreslår at i den grad NAV har mulighet for å skru på PoE-options på utstyr (som PortAdmin i noen grad kan gjøre), haddet kanskje vært bedre om NAV tilbød et API for å gjøre dette utenifra, så UiO kunne bygd noe eget oppå dette.
• Foreslår at UiO heller tar opp dette på et senere tidspunkt om det fremdeles er aktuelt.

Peder meldte et par ting i Zoom-chatten i starten av møtet, før vi kom til runden rundt bordet:

• Innspill det med å bidra med kode til nav. Det er flott at det blir publisert en ferdig VM m/NAV. Men den er helt tom av data. Kunne vi også fått en versjon med syntetisk data, slik at vi kan teste på en ikke produksjonsdata?
  • Dette ble under møtet kanskje tolket annerledes enn det var skrevet, da VM-en (virtual appliance) vi tilbyr er mest for demo-formål, ikke for utviklingsformål. Det som ble diskutert var hvorvidt det var en god idé å tilby en demo-versjon av NAV på nett (i sky), ferdig populert med et simulert nettverk, slik at brukere som kan være interessert i å bruke NAV kan teste GUI-et uten å i det hele tatt måtte sette opp noe selv.
    • For ordens skyld kan vi legge til at utviklerne stadig bruker midlertidige kopier av produksjonsdata for testing og utvikling av funksjonalitet - i alle fall inntil det skal utvikles funksjonalitet som krever muligheten til å faktisk snakke med utstyr, da må vi ha tilgang til utstyr enten i labb eller produksjon.
• Ellers nevner Peder gjentatte ganger forslag om å utvide NAV-databasen (PostgreSQL) til en vector-database med pgvector. Hans entusiasme for dette er forståelig all den tid det er dette han bygger sin nye næringsvirksomhet på
  • https://www.youtube.com/watch?v=4IGolO3kf_Q

Peder har ellers ingenting spesielt å melde denne gangen, ut over at det blir hans siste nav-refmøte, ettersom han har sagt opp sin stilling på HiVolda. Andreas Høydalsvik blir mest sannsynlig hans arvtaker i gruppen, og bør formodentlig inn på epostlista.

Vi takker Peder for lang og tro tjeneste!

4. mars, kl. 09.00-12.00 (videokonferanse) ble valgt som neste møtedato.