NAV referansegruppemøte 14. oktober 2014

NAV-ref Home

Tilstede:

• John-Magne Bredal, UNINETT
• Morten Brekkevold, UNINETT
• Børge Brunes, UiT
• Rune Kittelsen, UiA
• Jan Sigurd Refvik, UiO
• Peder Sefland, HiVolda
• Gro-Anita Vindheim, NTNU

Forfall:

• Vidar Faltinsen, UNINETT

Møtet ble avhold på NTNU Gløshaugen i Trondheim, og varte fra kl. 09-15, avbrutt av lunsj.

1. Status, NAV 4.1 / 4.2 med demo
2. NAVs fremtid
3. Konkrete innspill fra referansegruppen
4. Dato for neste møte

• Merk: Punker merket følges opp og vurderes som lanchpad bug. Da skrives bugnr. Når dette er fikset og sluppet skrives FIX RELASED

Møtet åpnet med en erkjennelse av at fremgangen siden vårens møte ikke hadde vært stor, grunnet ressurssituasjonen rundt verktøydrift og andre utviklingsprosjekter hos UNINETT. John-Magne fulgte deretter opp med en demonstrasjon av diverse ny funksjonalitet i NAV.

Først ute var demo av nytt grensesnitt for redigering av vilkårlige attributter på rom og organisasjonsenheter.

• Spørsmål fra forsamlingen om å bruke dette til å koble mot eksterne informasjonsverktøy.
• Ønske fra NTNU om å kunne begrense, gjennom konfigurasjon, hvilke attributter som skal være mulig å velge (i autocomplete/dropdownlister) for Org/Room

Deretter ble redesignet Netmap demonstrert.

• Filtrering på device group ble foreslått. Dette vil være noe annet enn filtrering på kategori, da det heller gjenspeiler at man vil se stier fra rutere og frem til utstyr som matcher gitte filter. Konkret use-case fra UiT, som ønsker å se et kart over alle skrivere og hvor de er koblet i nettet.
• Mulighet til å slå av/på visning av last (f.eks. når man ser VLAN-utbredelse) ble foreslått.
• Spørsmål om det er mulig å få URL-er som går direkte til spesifikke views. Dette var støttet før, og er sannsynligvis det fremdeles, vi er bare usikre på hvor disse URL-ene kan finnes.
• Ønske om mulighet til å skrive filtre i URL-en ble ytrete, slik at man f.eks. kan lenke fra Location/Room til et kart som bare viser innholdet i dette.

Til slutt fulgte en gjennomgang av bakgrunnen for at status-siden blir skrevet om, og en “prototype”-demonstrasjon av det some er gjort så langt.

• Peder bruker Device History nesten mer enn Status.
  • NTNU klager på at det ikke fins gode lenker noen steder i søkeresultatene i Device History
• Hver alarm i ny status-side behøver fremdeles lenker til Device History for historikk om lignende eller relaterte hendelser. Dette kan komme i egen popup.
• Ønske om filter for device groups.
• Enighet om at “subject” bør komme først av kolonnene, alert type som nummer to.
• Info-knappen bør være i siste kolonne.
• “Put on maintenance” bør utvides til å kunne gjøres i bulk, slik som andre actions på siden. Det bør også være mulig å legge ved en description til maintenance-tasken når man gjør det.
• maintenanceState-hendelser skal vises som de er. Bruker må selv velge å filtrere dem vekk.
• Det bør være et eget sett med negerte filtre.
• Eget filter (checkbox) for å ta vekk alarmer for ting som er på maintenance. Ingen konsensus på om default-verdi på denne.
• Hver alarm må ha en visuell indikasjon på om den har blitt ACKet eller om subject er på maintenance.

Flere innspill rundt Device History ble diskutert.

Lunsj ca. 11:40.

Møtets andre del var en åpen diskusjon rundt NAVs fremtid, både i UH-sektoren og forøvrig. Er NAVs posisjon truet? Fins det verktøy som ser mer fristende ut enn NAV som vi bør hente inspirasjon fra?

Punkter fra diskusjonen:

• Import/eksport og integrasjon med andre systemer er viktigere enn å bygge inn ny, urelatert funksjonalitet i NAV.
• Støtte for virtuelle switcher (både VSS og software-switcher til servervirtualisering) blir mer og mer aktuelt. Dette fins allerede på arbeidslisten, nevnt som LP#1169550.
• At NAV bare har to aktive utviklere kan være en svakhet, ift. hvor raskt vi kan utvikle nye features samtidig som vi driver vedlikehold av eksisterende kode.
• Flere i forsamlingen bruker Cisco Prime:
  • Brukes av forsamlingen primært for konfigurasjon og overvåkning av trådløskontrollere.
  • Cisco Prime er udugelig til overvåkning, delvis udugelig til template-basert konfigurasjon, og later til å bli mer og mer bloatware (sitat: “i god Cisco-tradisjon”).
  • Fremdeles ingen konsensus om at vi skal bruke allerede knappe ressurser på å utvikle lignende funksjonalitet i NAV.
    • Ikke nødvendigvis komplisert for Cisco, andre leverandører er ukjent.
  • Kan NAV måle PoE-forbruk rundt omkring (de fleste APer får strøm slik).
  • Kanskje estimere hvor mye det vil koste å utvikle funksjonalitet for Cisco
    • Registrere tilknyttede APer?
    • Maskinspore tilknyttete klienter?
    • Telle aktive brukere per stasjon og eller per kontroller?
  • 28. og 29. oktober er det trådløssamling på Værnes. Flere fra forsamlingen skal på denne - kan noen prøve å ta opp NAV og trådløst til diskusjon der?

• Børge mener UNINETTs verktøy ofte konsentrerer seg om langstrekk i forskningsnettet, mens institusjonene som regel har feilsøkingsbehov i sitt interne nettverk.
  • Eksempelvis nevnes SolarWinds, som kan settes opp til å sniffe på bestemte deler av nettet for å undersøke trafikk.
    • Målepunkt på vilkårlige steder i nettet, med strømming av pcap-data til den sentrale analysatoren (Solarwinds?)
  • Vil gjerne se målepåler for innsiden av campusnettet (Dette er visstnok et UNINETT-prosjekt i 2015, red.anm).
• NAV bør fremdeles fokusere mer på tjenestekvalitet. Prober og målinger på forskjellige punkter i topologien kan være en idé.

• Power-contrib (https://bitbucket.org/bredal/nav-contrib-powerstats)
  • Dagens versjon er høyst skreddersydd for UNINETTs nye serverrom.
  • Skal dette leve videre som contrib med noen forbedrede configmuligheter, eller skal vi gjøre det til en “fullkonfigurerbar” del av NAV?
    • Dette avstedkom en diskusjon om hvor konfigurerbart dette evt. måtte være for å være anvendelig for de fleste.
    • Den omdiskuterte løsningen innebærer konfigurasjon av et miljø-view for et rom. Dagens løsning er helautomatisk, mens løsningen som diskutert vil ha lite eller ingen automatikk - alt blir manuelt.
  • Skal man kunne legge inn fysisk rack-plassering for utstyr i NAV?
    • Kommentar: Dette er strengt tatt noe NAV ikke trenger å befatte seg med, men om man implementerer forslaget om å kunne legge til vilkårlige felter til Netbox-modellen, så kan man selv legge inn rack-informasjon i disse.
  • UiA ønsker støtte for miljøprober fra AKCP. UiT har visstnok også noen av disse. UiA har tidligere sendt aktuell MIB LP#1390073 - FIX RELEASED
• UiT har en del ønsker for Machine Tracker:
  • Sporing av overvåkede bokser i Machine Tracker (Ble diskutert på forrige møte, men mangler fra Launchpad) LP#1383624 - FIX RELASED!
  • Morten: Sporing av ifPhysAddress LP#1383625 - FIX RELASED!
  • Morten: Machine Tracker eller NAVbar search også på unrecognized neighbors? LP#1384262 - FIX RELASED!
• UiT: Er Nexus-switcher fullt støttet i NAV?
  • Motspørsmål: Hva er ikke støttet i dag?
• UiT: Kan vi få “Recurring maintenance tasks”? Har bokser som de vil ha på maintenance hver arbeidsdag mellom 08-16, men ellers ikke.
• UiA: Har NAT44-bokser fra UNINETT, men savner god overvåkning av disse.
  • Støtter de SNMP?
  • Interessert i klienttelling, oppetid og kanskje mer (UiA har sendt egen mail om dette i etterkant av møtet, red.anm.)

Neste møte satt til fredag 17. april, hos Universitetet i Tromsø. Dette har senere blitt flyttet til mandag 1. juni 2015.

• UiT: ønske om vilkårlige attributter også på Location og Netbox.
• Volda: Ønsker knapp for å kollapse footer
  • Generelt ønske om muligheten til å gå til et “fullscreen-view” på alle siden, som kollapser både header og footer
• UiT: Ønsker seg en MIB-browser der man kan velge å overvåke endringer i spesifikke objekter (idé fra “dude”, et overvåkningsverktøy fra Mikrotik som ble bruk av Børge under Sjakk-OL i Tromsø)
• Generiske lifecycle-alarmer har forsvunnet i nyere NAV-versjoner. (serialChanged, softwareChanged, etc.). De bør vel inn igjen?
• Device History: Netbox bør stå i første kolonne, location og room kan komme lengre bak (eller skjules i en “infoboks”)