nav-ref:navref_051124
Differences
This shows you the differences between two versions of the page.
| Both sides previous revisionPrevious revisionNext revision | Previous revision | ||
| nav-ref:navref_051124 [2024/11/06 15:59] – første utkast til referat morten | nav-ref:navref_051124 [2025/03/12 06:31] (current) – ref til 3325 morten | ||
|---|---|---|---|
| Line 146: | Line 146: | ||
| * 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, | * 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, | ||
| * Morten påpeker at sistnevnte allerede er støttet i NAV ved å registrere en " | * Morten påpeker at sistnevnte allerede er støttet i NAV ved å registrere en " | ||
| - | * :!: **AKSJON:** Funksjonaliteten er dessverre ikke beskrevet noe annet sted enn i [[https:// | + | |
| + | * [[https:// | ||
| * UiT skal teste hvor godt denne funksjonaliteten dekker deres behov. | * 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. | * 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. | ||
| Line 152: | Line 153: | ||
| * 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. | * 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. | + | <del>:!: **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, | * UiT gjentar et ønske om støtte for Cisco ACI (Application Centric Infrastructure, | ||
| * En Cisco ACI-kontroller kan ses på som en avansert ruter. | * En Cisco ACI-kontroller kan ses på som en avansert ruter. | ||
| - | * :!: **AKSJON:** Lage et GitHub-issue om ACI og be UiT spe på med informasjon der. | + | * <del>:!: **AKSJON:** Lage et GitHub-issue om ACI og be UiT spe på med informasjon der.</ |
| + | * [[https:// | ||
| * UiT ønsker å trekke frem denne igjen: ([[https:// | * UiT ønsker å trekke frem denne igjen: ([[https:// | ||
| * 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. | * 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. | * 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 | + | * <del>:!: **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). | + | * [[https:// |
| + | * <del>:!: **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).</ | ||
| + | * Vi har laget en " | ||
| | | ||
| * UiT trekker fram et gammelt issue som ble forsøkt løst for mange år siden, men hvor endringen måtte rulles tilbake: ([[https:// | * UiT trekker fram et gammelt issue som ble forsøkt løst for mange år siden, men hvor endringen måtte rulles tilbake: ([[https:// | ||
| - | * :!: **AKSJON:** Kartlegg hva som skjedde sist dette ble forsøkt løst og legg inn som en kommentar på #2915 | + | * <del>:!: **AKSJON:** Kartlegg hva som skjedde sist dette ble forsøkt løst og legg inn som en kommentar på #2915</ |
| + | * Issue #2915 er egentlig et duplikat av et 12 år gammelt issue som ble forsøkt løst i to omganger, med svært uheldige resultater for NAV, og endringene ble derfor rullet tilbake. | ||
| * UiT ber også om oppmerksomhet for to bugs de tidligere har meldt inn: | * UiT ber også om oppmerksomhet for to bugs de tidligere har meldt inn: | ||
| * [[https:// | * [[https:// | ||
| Line 172: | Line 175: | ||
| * 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. | * 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, | * Vi diskuterte oss frem til en viss enighet om at slettede bokser ikke skal forsvinne i løse luften fra maintenance-tasks, | ||
| - | * :!: **AKSJON:** Utviklerteamet oppdaterer #2243 og lager et forslag til løsning/ | + | * <del>:!: **AKSJON:** Utviklerteamet oppdaterer #2243 og lager et forslag til løsning/</ |
| * Begge bugs ble lagt i backlog for inneværende sprint. | * Begge bugs ble lagt i backlog for inneværende sprint. | ||
| Line 182: | Line 185: | ||
| * CNaaS har også behov for ARP-innsamling fra Palo Alto-brannmurer, | * CNaaS har også behov for ARP-innsamling fra Palo Alto-brannmurer, | ||
| - | * :!: **AKSJON:** Utviklerne registrerer GitHub-issue på den aktuelle buggen i Palo Alto-pluginen i ipdevpoll. | + | * <del>:!: **AKSJON:** Utviklerne registrerer GitHub-issue på den aktuelle buggen i Palo Alto-pluginen i ipdevpoll.</ |
| + | * [[https:// | ||
| * CNaaS registrerer også at det fullstendig mangler informasjon om ruterporter fra Palo Alto-brannmurer. | * 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. | * Dette er formodentlig også fordi disse brannmurene heller ikke svare på de relevante MIB-ene med IP-informasjon. | ||
| Line 200: | Line 204: | ||
| * :!: **AKSJON:** Knut-Helge bør evt. kommentere på de punktene som allerede er observert under [[https:// | * :!: **AKSJON:** Knut-Helge bør evt. kommentere på de punktene som allerede er observert under [[https:// | ||
| * Oktett-tellere på porter blir i dag aggregert over tid med gjennomsnittsverdier. | * Oktett-tellere på porter blir i dag aggregert over tid med gjennomsnittsverdier. | ||
| - | * :!: **AKSJON:** Utviklerteamet lager et GitHub-issue og dokumenterer behovet for Graphite-research, | + | * <del>:!: **AKSJON:** Utviklerteamet lager et GitHub-issue og dokumenterer behovet for Graphite-research, |
| + | * [[https:// | ||
| * 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. | * 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. | ||
| - | * :!: **AKSJON:** Kilde for dette er visstnok Vidar Stokke, som også har noen MIB-referanser. | + | * <del>:!: **AKSJON:** Kilde for dette er visstnok Vidar Stokke, som også har noen MIB-referanser. |
| + | * [[https:// | ||
| * Ønsker muligheten for deling av dashboards mellom brukere | * Ønsker muligheten for deling av dashboards mellom brukere | ||
| * Allerede notert i [[https:// | * Allerede notert i [[https:// | ||
| Line 209: | Line 215: | ||
| * Ønsker støtte for VLAN-informasjon og CAM-data fra Aruba CX-switcher. | * Ø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 '' | * Dette fungerer ikke i NAV i dag, primært fordi Aruba CX ikke implementerer '' | ||
| - | * :!: **AKSJON:** Utviklerteamet registrerer GitHub-issue om Aruba CX. | + | * <del>:!: **AKSJON:** Utviklerteamet registrerer GitHub-issue om Aruba CX.</ |
| + | * [[https:// | ||
| * Ønsker støtte for VLAN-informasjon og CAM-data fra Dell Blade-switcher. | * Ønsker støtte for VLAN-informasjon og CAM-data fra Dell Blade-switcher. | ||
| * Denne problemstillingen er ny for utviklerteamet, | * Denne problemstillingen er ny for utviklerteamet, | ||
| - | * :!: **AKSJON:** Utviklerteamet registrerer GitHub-issue om Dell Blade-switcher | + | * <del>:!: **AKSJON:** Utviklerteamet registrerer GitHub-issue om Dell Blade-switcher</ |
| + | * [[https:// | ||
| * Til sist kom det inn et ønske med et bærekraftsperspektiv: | * Til sist kom det inn et ønske med et bærekraftsperspektiv: | ||
| * 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). | * 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). | ||
| Line 218: | Line 226: | ||
| * Om man samler inn effektforbruk hvert minutt kan man f.eks. estimere energifobruket for dette minuttet ved å multiplisere effektforbruket med en faktor på '' | * Om man samler inn effektforbruk hvert minutt kan man f.eks. estimere energifobruket for dette minuttet ved å multiplisere effektforbruket med en faktor på '' | ||
| * Hvordan er MIB-støtten for å hente ut slikt på forskjellig utstyr? | * Hvordan er MIB-støtten for å hente ut slikt på forskjellig utstyr? | ||
| - | * :!: **AKSJON:** Utviklerteamet kan registrere et GitHub-issue, | + | * <del>:!: **AKSJON:** Utviklerteamet kan registrere et GitHub-issue, |
| + | * [[https:// | ||
| + | * 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 | ||
| + | PSU 1 (JPSU-920W-AC-AFO | ||
| + | Power redundancy configuration | ||
| + | Total power supplied by all online PSUs : 1720 W | ||
| + | Base power reserved | ||
| + | Non-PoE power being consumed | ||
| + | Total power allocated for PoE : 1440 W | ||
| + | Total PoE power consumed | ||
| + | Total PoE power remaining | ||
| + | | ||
| === NTNU === | === NTNU === | ||
| * Gjentar ønsket om at NAV samler inn ytterligere port-data fra Cisco SDA (Software Defined Access). | * Gjentar ønsket om at NAV samler inn ytterligere port-data fra Cisco SDA (Software Defined Access). | ||
| - | * :!: **AKSJON:** Morten finner tilbake skjermbildet Nils-Arild oversendte den gangen og oppretter et GitHub-issue. | + | * <del>:!: **AKSJON:** Morten finner tilbake skjermbildet Nils-Arild oversendte den gangen og oppretter et GitHub-issue.</ |
| + | * [[https:// | ||
| * NTNU bruker aktivt søket '' | * NTNU bruker aktivt søket '' | ||
| - | * :!: **AKSJON:** Utviklerteamet lager et GitHub-issue og ber Nils-Arild kvalitetssikre det. | + | * <del>:!: **AKSJON:** Utviklerteamet lager et GitHub-issue og ber Nils-Arild kvalitetssikre det.</ |
| + | * [[https:// | ||
| * Ønsker seg muligheten til å begrense PortAdmin-brukere til å bare konfigurere port-description, | * Ønsker seg muligheten til å begrense PortAdmin-brukere til å bare konfigurere port-description, | ||
| - | * :!: **AKSJON:** Utviklerteamet lager et GitHub-issue og ber Nils-Arild kvalitetssikre det. | + | * <del>:!: **AKSJON:** Utviklerteamet lager et GitHub-issue og ber Nils-Arild kvalitetssikre det.</ |
| + | * [[https:// | ||
| * [[https:// | * [[https:// | ||
| * Ønsker også [[https:// | * Ønsker også [[https:// | ||
| Line 241: | Line 269: | ||
| * UiO støtter arbeidet med å komme opp på siste Debian Stable (python3.11-jobbinga). | * 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? | * 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. | + | * <del>:!: **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. |
| + | * Det virker som dette skyldes en misforståelse av hvordan NAVs room-tabell bruker romnavn som primærnøkler, | ||
| * // | * // | ||
| * 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. | * 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. | + | * <del>:!: **AKSJON:** Morten B leter opp om han har noe underlagsmateriale om transceiverterskler fra før.</ |
| + | * Har funnet en del underlagsmateriale some er *Juniper-spesifikt*, | ||
| * // | * // | ||
| * Morten B mener dette muligens allerede samles inn og grafes, i alle fall for Cisco. | * Morten B mener dette muligens allerede samles inn og grafes, i alle fall for Cisco. | ||
| Line 257: | Line 287: | ||
| === HiVolda === | === HiVolda === | ||
| - | Peder har ingenting spesielt å melde denne gangen, ut over at det blir hans siste nav-refmøte, | + | 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, | ||
| + | * 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 [[https:// | ||
| + | * https:// | ||
| + | |||
| + | Peder har ellers | ||
| Vi takker Peder for lang og tro tjeneste! | Vi takker Peder for lang og tro tjeneste! | ||
nav-ref/navref_051124.1730908743.txt.gz · Last modified: by morten