Differences

This shows you the differences between two versions of the page.

--- nav-ref:navref_051124 [2025/02/26 15:07] – 2243 er lukket morten
+++ nav-ref:navref_051124 [2025/03/12 06:31] (current) – ref til 3325 morten
@@ Line 168: / Line 168: @@
   * UiT trekker fram et gammelt issue som ble forsøkt løst for mange år siden, men hvor endringen måtte rulles tilbake: ([[https://github.com/Uninett/nav/issues/2915|[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
+    * <del>:!: **AKSJON:** Kartlegg hva som skjedde sist dette ble forsøkt løst og legg inn som en kommentar på #2915</del>
+         * 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.  Issue-historikk er kommentert på #2915.
   * UiT ber også om oppmerksomhet for to bugs de tidligere har meldt inn:
     * [[https://github.com/Uninett/nav/issues/2908|[BUG] Alert profile filter - list_limit reached #2908]]
@@ Line 204: / Line 204: @@
     * :!: **AKSJON:** Knut-Helge bør evt. kommentere på de punktene som allerede er observert under [[https://github.com/Uninett/nav/issues/1936| 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.
+    * <del>:!: **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.</del>
+      * [[https://github.com/Uninett/nav/issues/3309][Research how Graphite can support multiple aggregation methods for a single metric #3309]]
   * 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.
+    * <del>:!: **AKSJON:** Kilde for dette er visstnok Vidar Stokke, som også har noen MIB-referanser.  Han bør snarest opprette et GitHub-issue som dokumenterer behovet og aktuelle MIB-er.</del>
+      * [[https://github.com/Uninett/nav/issues/3325|Collect and graph system metrics for CPU utilization avg 1, 5 and 15 minutes on Juniper SRX #3325]]
   * Ønsker muligheten for deling av dashboards mellom brukere
     * Allerede notert i [[https://github.com/Uninett/nav/issues/2344|Add shareable dashboards to NAV #2344]]
@@ Line 213: / Line 215: @@
   * Ø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.
+    * <del>:!: **AKSJON:** Utviklerteamet registrerer GitHub-issue om Aruba CX.</del>
+      * [[https://github.com/Uninett/nav/issues/3310|Support VLAN (802.1Q) information on Aruba CX switches #3310]]
   * Ø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
+    * <del>:!: **AKSJON:** Utviklerteamet registrerer GitHub-issue om Dell Blade-switcher</del>
+      * [[https://github.com/Uninett/nav/issues/3311|Support VLAN (802.1Q) and CAM information on Dell Blade switches #3311]]
   * 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).
@@ Line 222: / 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å ''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.
+    * <del>:!: **AKSJON:** Utviklerteamet kan registrere et GitHub-issue, men dette krever noe kartleggingsarbeid som CNaaS-teamet selv må fylle på med.</del>
+      * [[https://github.com/Uninett/nav/issues/3312|Collect and graph device power usage #3312]]
     * Chatlog fra Vidar F:
@@ Line 246: / Line 251: @@
       * [[https://github.com/Uninett/nav/issues/3217| 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.
+    * <del>:!: **AKSJON:** Utviklerteamet lager et GitHub-issue og ber Nils-Arild kvalitetssikre det.</del>
+      * [[https://github.com/Uninett/nav/issues/3313|Add complementary activity search to "Last seen" view in the Room view interfaces list #3313]]
   * Ønsker seg muligheten til å begrense PortAdmin-brukere til å bare konfigurere port-description, ikke VLAN og andre ting.
     * <del>:!: **AKSJON:** Utviklerteamet lager et GitHub-issue og ber Nils-Arild kvalitetssikre det.</del>
@@ Line 263: / Line 269: @@
   * 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?
+    * <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.  Kan Werner klare opp i kommentaren?</del>
+      * Det virker som dette skyldes en misforståelse av hvordan NAVs room-tabell bruker romnavn som primærnøkler, og at det egentlig dreier seg om de punktene nav-ref har diskutert før om muligheten til å ha ikke-unike romnavn.
   * //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.
+    * <del>:!: **AKSJON:** Morten B leter opp om han har noe underlagsmateriale om transceiverterskler fra før.</del>
+      * Har funnet en del underlagsmateriale some er *Juniper-spesifikt*, der optikkterskler fins å lese av fra kolonner i ''JUNIPER-DOM-MIB::jnxDomCurrentTable'', som NAV allerede har delvis støtte for.
   * //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.