Differences

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

--- nav-ref:navref_051124 [2024/11/05 09:00]
nagrav
+++ nav-ref:navref_051124 [2025/03/12 06:31] (current)
morten ref til 3325
@@ Line 4: / Line 4: @@
-Innkalt:
+Tilstede:
   * Peder Smart Sefland, //HiVolda//
   * Rune Kittelsen, //UiA//
   * Øyvind Nesland, //UiA//
-  * Ingeborg Hellemo, //UiT//
+  * Børge Brunes, //UiT//
   * Nils-Arild Grav, //NTNU//
   * Sigurd Refvik, //UiO//
-  * Morten Werner Forsbring, //UiO//
+  * Morten Werner Forsbring, //UiO// (Forlot møtet etter ca. 1 time)
   * Vidar Faltinsen, //Sikt//
@@ Line 20: / Line 20: @@
   * Ilona Podliashanyk, //Sikt//
   * Morten Brekkevold, //Sikt//
+Forfall:
+  * Ingeborg Hellemo, //UiT// (Børge Brunes er stedfortreder)
@@ Line 26: / Line 30: @@
 Møtet blir avholdt som videokonferanse vha. Zoom, fra kl. 09:00 til 12:00.
-=== 0. Velkommen/Innledning ===
+==== 0. Velkommen/Innledning ====
 Morten ønsker velkommen på vegne av Sikt.
-=== 1. Presentasjoner/Status ===
+==== 1. Presentasjoner/Status ====
-== NAV ==
+=== NAV ===
 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.
@@ Line 53: / Line 57: @@
 feature-release siden forrige møte: [[https://github.com/Uninett/nav/releases/tag/5.11.0|NAV 5.11.0]]
-== Argus ==
+=== Argus ===
 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.
@@ Line 59: / Line 63: @@
 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.
-=== 2. Fokus for videre utvikling/tilbakemelding ===
+==== 2. Fokus for videre utvikling/tilbakemelding ====
   * Hva er det konkrete behovet bak [[https://github.com/Uninett/nav/issues/1501|Log changes to IP Devices #1501]]?  Hvordan skiller det seg fra [[https://github.com/Uninett/nav/issues/1997|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?
-=== 3. Nye ønsker og innspill fra gruppen ===
+==== 3. Nye ønsker og innspill fra gruppen ====
 Runde rundt "bordet".  Skriftlig innmeldte saker tas først.
-== UiT ==
+=== UiT ===
   * Støtte for VRF
@@ Line 78: / Line 82: @@
     * [[https://github.com/Uninett/nav/issues/2243|Deleted netboxes should be deleted from Maintenance tasks #2243]]
-== Sikt/CNaaS ==
+=== Sikt/CNaaS ===
 Sikts CNaaS-team har meldt inn sin egen prioriterte liste over ønsker/problemer i NAV:
@@ Line 94: / Line 98: @@
   - 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
-== NTNU ==
+=== NTNU ===
-  - Live portstatus på SDA-svitsjer (eks VRF (VN), VLAN, SGT, Autentisering, type utstyr, maskinnavn, IP, MAC, hastighet, link, portbeskrivelse)
+  - Øyeblikksbilde/livedata av portstatus på SDA-svitsj (eks VRF (VN), VLAN, SGT, Autentisering, type utstyr, maskinnavn, IP, MAC, hastighet, link, portbeskrivelse)
   - Tilgangsstyring for kun tilgang til endring av portbeskrivelse
-  - Mulighet for registrering av utstyr(MAC) for MAB-autentisering, ref løsning presentert i tidligere NAV ref-gruppemøte
+  - Mulighet for registrering av utstyr(MAC) for MAB-autentisering, ref iotroam-løsning presentert i tidligere NAV ref-gruppemøte
   - Dot1x-admin på Cisco-svitsjer utenfor SDA
   - 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.
@@ Line 103: / Line 107: @@
-=== 4. Neste møte ===
+==== 4. Neste møte ====
 Vi velger neste møtedato.  Medio mars?
-===== Referat =====
+====== Referat ======
+==== 0. Velkommen/Innledning ====
+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.
+==== 1. Presentasjoner/Status ====
+Morten gjorde rede for status på NAV og Argus, for det meste slik det fremkom av agenda.
+==== 2. Fokus for videre utvikling/tilbakemelding ====
+=== Tilbakemeldinger på #1501 (Log changes to IP devices) ===
+Ingen i gruppen hadde tilbakemeldinger på hvordan [[https://github.com/Uninett/nav/issues/1501|Log changes to IP Devices #1501]] egentlig skal fungere, gitt at [[https://github.com/Uninett/nav/issues/1997|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.
+=== Støtte for ny type Comet-miljøprobe hos UiT ===
+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.
+==== 3. Nye ønsker og innspill fra gruppen ====
+UiT og Sikt/CNaaS sendte inn skriftlige punkter i forkant.  NTNU la inn skriftlige punkter underveis i møtet.
+=== UiT ===
+   * Ø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.
+         * <del>:!: **AKSJON:** Funksjonaliteten er dessverre ikke beskrevet noe annet sted enn i [[https://nav.readthedocs.io/en/latest/release-notes.html#avoiding-redundant-snmp-polling-for-virtual-device-contexts|release notes for NAV 4.7]], så dette bør nok dokumenteres bedre.</del>
+           * [[https://github.com/Uninett/nav/issues/3303|NAV's feature to avoid VRF polling redundancies using master/slave device registrations is not documented #3303]]
+         * 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.
+<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.</del>.  Vi har i stedet laget en GitHub discussion (som senere kan gjøres om til en issue, ved behov): [[https://github.com/Uninett/nav/discussions/3304| Add more "support" for VRF #3304 ]]
+  * 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.
+    * <del>:!: **AKSJON:** Lage et GitHub-issue om ACI og be UiT spe på med informasjon der.</del>
+      * [[https://github.com/Uninett/nav/issues/3220| Fetch ARP data from Cisco ACI (Application Centric Infrastructure) API #3220 ]]
+  * UiT ønsker å trekke frem denne igjen: ([[https://github.com/Uninett/nav/issues/1666|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.
+      * <del>:!: **AKSJON:** Denne rapporten bør distribueres med NAV så alle har et eksempel de eventuelt kan tilpasse selv</del>
+        * [[https://github.com/Uninett/nav/issues/3305|Add an "Events detected last 24 hours" SQL report #3305]]
+    * <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).</del>
+      * Vi har laget en "discussion" på dette her: [[https://github.com/Uninett/nav/discussions/3306| Revamp IP Device History tool #3306 ]]
+  * 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]])
+    * <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]]
+    * [[https://github.com/Uninett/nav/issues/2243|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.
+      * <del>:!: **AKSJON:** Utviklerteamet oppdaterer #2243 og lager et forslag til løsning/</del>
+    * 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 ===
+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.
+    * <del>:!: **AKSJON:** Utviklerne registrerer GitHub-issue på den aktuelle buggen i Palo Alto-pluginen i ipdevpoll.</del>
+      * [[https://github.com/Uninett/nav/issues/3252| [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 [[https://github.com/Uninett/nav/issues/2598|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 [[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''.
+    * <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.
+    * <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]]
+  * Ø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''.
+    * <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.
+    * <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).
+    * 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?
+    * <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:
+>  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
+=== NTNU ===
+  * Gjentar ønsket om at NAV samler inn ytterligere port-data fra Cisco SDA (Software Defined Access).  Sist nevnt på [[navref_050324]]
+    * <del>:!: **AKSJON:** Morten finner tilbake skjermbildet Nils-Arild oversendte den gangen og oppretter et GitHub-issue.</del>
+      * [[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.
+    * <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>
+      * [[https://github.com/Uninett/nav/issues/3298|Add option to restrict PortAdmin users to only setting port descriptions #3298]]
+  * [[https://github.com/Uninett/nav/issues/2164|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å [[https://github.com/Uninett/nav/issues/2248|Support for MFA (multi-factor authentication) #2248]] på grunn av interne sikkerhetskrav.
+=== UiA ===
+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.
+=== UiO ===
+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?
+    * <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.
+    * <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.
+    * 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.
+=== HiVolda ===
+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 [[https://github.com/pgvector/pgvector|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. Neste møte ====
+[[navref_040325|4. mars, kl. 09.00-12.00 (videokonferanse) ble valgt som neste møtedato]].
-Kommer.

NAV Wiki

User Tools

Site Tools

Differences

Page Tools