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 [2025/02/26 10:53] – Lagt til 3298 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, | ||
| Line 161: | Line 162: | ||
| * 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 201: | 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 210: | 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 219: | 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: | * Chatlog fra Vidar F: | ||
| Line 243: | Line 251: | ||
| * [[https:// | * [[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, | ||
| * < | * < | ||
| Line 260: | 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. | ||
nav-ref/navref_051124.1740567209.txt.gz · Last modified: by morten