NAV-ref Home

Tilstede:

• John-Magne Bredal, UNINETT
• Morten Brekkevold, UNINETT
• Vidar Faltinsen, UNINETT (frem til ca. 13:40)
• Rune Kittelsen, UiA
• Jan Sigurd Refvik, UiO
• Peder Sefland, HiVolda
• Gro-Anita Vindheim, NTNU

Forfall:

• Børge Brunes, UiT

Møtet var i Teknobyen, Trondheim og varte fra kl. 09-15, avbrutt av lunsj.

1. Status gjeldende arbeidsliste m/demo
2. Innspill til implementasjonsdetaljer.
3. Innspill fra referansegruppen, nye utfordringer
4. Dato for neste møte.

Møtet åpnet med en gjennomgang og demonstrasjon av fullførte punkter fra arbeidslisten. Noen av funksjonene som ble demonstrert, med tilbakemeldinger fra gruppen:

• Samlet infoside
  • NTNU: Søk kan gi veldig mange treff og VLAN-info, som er mest interessant for oss, havner nederst på siden og man må lete etter det. Hva kan gjøres med dette?
• Neighbors-kart i ipdevinfo
  • Gjentatt ønske: Mulighet for å kvittere vekk “kjente” ukjente bokser som NAV ikke skal bry seg om.
• Port details (ipdevinfo)
  • NTNU: Sortere VLAN i stigende rekkefølge
• Affected-fane i ipdevinfo
  • Kan tittelen endres fra “affected” til “What if?” ?
  • Kan overskriften “devices going down” endres til “devices unreachable”?
  • Trenger liste over affekterte organisasjoner (mulig det er der allerede, men at datagrunnlaget mangler fra demo-installasjonen)
    • I såfall, overskriften bør alltid være der, selv om listen er tom.
• IP Device groups erstatter subcategories,
  • Ønske om at grupper skal være søkbare i navbar
  • Utstyr i en gruppe må kunne redigeres på gruppens side i SeedDB, ikke som et helt separat grensesnitt som nå.
• Netmap
  • HiVolda: Hva kan vi gjøre om naboskap som vises ikke er riktig?
    • Svar: Følg howto for debugging av topologiproblemer før feilen rapporteres til utviklerne.
  • UiA: Indikeres linker som er nede i kartet?
    • Svar: Nei.
  • Diskusjon rundt hvordan man skal lastfargelegge der det er flere parallelle linker. Et vanskelig problem.
  • Spørsmål: Kan man filtrere kartet på organisasjon?
    • Svar: Hva skal man filtrere på? Boks-organisasjon eller VLAN-organisasjon? Forskjellige installasjoner bruker organisasjonstilknytninger på forskjellige måter i NAV.
  • Eksport til SVG fungerer bare i Chrome: Eksport-knappen er usynlig i andre nettlesere - det er ikke bra, den bør være synlig, men disablet i andre nettlesere.
• Opplasting av bilder pr. rom
  • Spørsmål/diskusjon rundt tilgangsmekanismer rundt de opplastede bildene.
• IP-adresseforbruksgrafer pr. VLAN
  • HiVolda: Gjenytrer ønske om bedret mulighet til å se små prefix i “subnet matrix”-verktøyet.

• Demo av hvordan vi så langt har integrert Graphite som erstatning for Cricket
  • Berettiget ønske om samlet inn/ut-trafikkgraf pr. port, og mulighet til å vise grafer for alle porter på en boks på samme side.
  • Spørsmål om hvorvidt ipdevpolls prioritering av jobber kan konfigureres på noe vis.
    • Svar: Nei, ipdevpoll har ingen spesiell prioritering overhodet.
    • Etterpåklokt svar: ipdevpoll sorterer jobber i kjøre etter hvor lenge siden sist de ble kjørt, slik at om flere jobber skal starte samtidig, starter de som har “ventet” lengst.
  • Spørsmål om utvidelse til flere teller pr interface
    • Svar: Dette var vanskelig med Cricket/rrdtool, problemfritt med Graphite.
  • Spørsmål om aggregering av statistikk
    • Svar: I motsetning til Cricket/rrdtool kan alle slike parametere konfigureres direkte inn i Graphite sin carbon-backend.
  • Spørsmål om migrering
    • Svar: Vi har skrevet script for migrering av RRD-data over til Graphite.

• Filtrert dumping og innrulling av data er implementert, og vil lette evt. uttesting av nye versjoner med produksjonsdata på midlertidige/virtuelle maskiner
  • Flere er mer interessert i å delta i betatesting med dette.

I neste bolk ba utviklerne om innspill til implementasjonsdetaljer.

• NAV mangler en “Unknown”-tilstand (LP#1062150 ). Dvs. når man legger til noe til overvåkning så blir det automatisk grønt, før NAV har sjekket noe som helst. Dersom sjekkingen ikke kjører som planlagt, forblir status grønn. NAV burde ha mulighet for å ha en “ukjent”-tilstand pr. overvåkede ting, som endrer seg først når man faktisk har sjekket tilstanden.
  • Hva om sjekk har kjørt, sjekk gir OK-status, og så stopper sjekkeren. Skal tilstanden gli over i “ukjent” igjen etter et tidsintervall? Holder det at watchdog-funksjonen vi planlegger varsler ting som har stoppet opp?
    • Tilbakemelding fra gruppen går på at watchdog bør holde.
• Virtuelle chassis og andre redundans-tiltak (LP#1169550). NAV skjønner f.eks. ikke Cisco VSS eller stackede Juniper-switcher i dag. Ved utfall/tap av redundans ser det ut som porter og moduler forsvinner ut av bokser, og NAV genererer flere alarmer for det.
  • Det idéelle hadde vært om NAV skjønte at en boks er satt sammen av flere chassis, og visste hvilke komponenter som hørte til hvilke chassis. Ved evt. utfall kunne NAV varslet tap av redundans, fremfor å varsle om alle fysiske komponenter som tilsynelatende forsvant i farta.
  • For Cisco VSS holder det antagelig med bedre tolkning av ENTITY-MIB. Verre for Juniper, hvor vi bare har ukjente, proprietære MIBer å støtte oss på.
• Ny statusside (LP#1063703)
• Kort NAVlets-demo, som løsningsforslag på LP#1061523
  • Tilbakemelding: Ton ned edit/remove-knapper eller flytt dem til en egen edit-modus for hele siden.
• Vi ønsker å sette opp et lite lab-/test-nett til åpen NAV-demo.

Siste del av dagen gikk til å diskutere nye utfordringer og innspill til/fra referansegruppen.

• Forslag fra utviklerne om ytelsesforbedringer på innsamlingssiden.
  • Morten la frem en del idéer for endringer i måten ipdevpoll muliggjør multiprocess-skalering, som blant annet kan føre til at innsamlingen kan skaleres horisontalt eller man kan realisere innsamling bak brannmurer eller NAT-løsninger.
  • Morten skal konkret se på ytelsesforbedringer i camloggeren, som spiser mye ressurser i dag.
  • Tomlene opp fra gruppen.
• Ny statusside bør støtte to nye mekanismer for alarmundertrykkelse:
  • “Acknowledge” - en kvittering for at alarmen er sett og kjent og jobbes med. Vil ikke fjerne alarmen, kun alarmens synlighet på statussiden. Statussiden skal likevel kunne vise kvitterte alarmer om brukeren ønsker.
  • “Force close” - tvangslukke en alarm som ikke er gyldig. Brukeren må gjøres oppmerksom på at dersom alarmen er reell, kan det komme en ny en ved å tvangslukke den.
• NETCONF blir mer aktuelt å støtte, i første omgang ved konfigurasjonsendringer fra Portadmin eller Arnold. Ciscos Nexus-plattform støtter snart ikke enkle konfigurasjonsendringer med SNMP writes, og da blir disse NAV-verktøyene ubrukelig for de som kjører Nexus i utstrakt grad (f.eks. NTNU)
• SNMPv3 har vært etterspurt, og burde kanskje vært støttet. Underliggende biblioteker støtter det, men NAV trenger nye måter å konfigurere/modellere “authentication credentials” som knyttes til nettbokser.
• Peder mener at Arnold/Portadmins “write mem”-kommando ved endringer på Cisco-utstyr ikke fungerer som den skal. Reboot av switcher fører til tap av endringer. Dette må sjekkes opp
• Det kommer en del spørsmål om mer fingranulert autorisasjon i Portadmin fra bl.a. Volda og NTNU, men disse er veldig vage. Utviklerne trenger detaljerte spesifikasjoner på hva som skal være støttet før man har mulighet til å se på implementasjon.

Ny møtedato ble ikke satt pga. knapp tid på slutten av møtet. Avtales på e-post ifm. avstemning over ny arbeidsliste. De to forslagene er:

• Tirsdag 1. april 2014
• Torsdag 3. april 2014

De innkomne momenter som er identifisert som store oppgaver som må opp på arbeidslisten står i neste avsnitt. Det som følger er stort sett småting som tar (fukt fingeren) fra 3 minutter til 3 timer å fikse.

• LP#1248078 - NAVbar search results should be grouped in tabs instead of multiple tables on a single page
• LP#1248082 - ipdevinfo port view should sort VLANs in ascending numerical order.
• LP#1248083 - ipdevinfo “affected” tab should be renamed to “what if”.
• LP#1248084 - the heading “devices going down” in ipdevinfo affected tab should be changed to “devices unreachable”
• LP#1248085 - ipdevinfo “affected” tab needs to properly list the affected organizations
  • the heading must always be visible, even if the organization list is empty
  • the “send e-mail” button should be greyed out when there are no e-mail addresses to send to
• LP#1248095 - device groups should be searchable in the NAVbar
• LP#1242868 - editing of device group members should be part of the device group SeedDB page, the current navigation path to this interface is unintuitive.
• LP#1248088 - Netmap's “export to SVG” button should be visible on all browsers, but disabled on those that don't support the export functionality

Disse to punktene knytter vi til en pågående sak som allerede ligger i arbeidslisten:

• LP#1063703 - New “acknowledge” action for individual alerts displayed in the status page will suppress future display of them in the status page
  • unless the user wants to specifically view acknowledged alerts.
• LP#1063703 - New “force close” action for individual alerts displayed in the status page will close active alert states.
  • User must be warned that closing real alerts may cause them to just be re-raised.

• LP#1248081 - New interface/tool to browse unrecognized neighbors and acknowledge individual devices that are known but are to be ignored (the ipdevinfo neighbor map must take these acknowledgements into account during display).
• LP#1248086 - alert on loss of redundancy in an aggregated (portchannel) link
• LP#744951 - allow for display of smaller subnets in the subnet matrix
  • the current limit is around /27 nets
• LP#1248090 - ipdevpoll's multiprocess mode should be rewritten to use generic worker processes that can be restarted without changing the scheduling
  • this may also allow for horizontal scaling of collector processes
• LP#1248092 - optimize ipdevpoll's cam plugin, it is currently an I/O and memory hog.
• LP#1248093 - A NETCONF implementation for NAV must be researched.
• LP#1248094 - Implement SNMPv3 support, in accordance with the underlying SNMP library.