User Tools

Site Tools


nav-ref:navref_010615

NAV referansegruppemøte 1. juni 2015

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 (via Skype for Business)

Gjesteopptreden:

  • Ingeborg Hellemo, UiT

Forfall:

  • Vidar Faltinsen, UNINETT

Agenda

Møtet ble avholdt på Universitetet i Tromsø, og varte fra kl. 10-16, avbrutt av lunsj.

  1. Status, NAV 4.2 og 4.3 med demo
  2. Fokus for videre utvikling
  3. Nye innspill fra referansegruppen
  4. (Dato for neste møte)

Referat

  • Merk: Punkter merket :!: følges opp og vurderes som Launchpad-issue. Da skrives bugnr. Når dette er fikset og sluppet skrives FIX RELEASED.

Status, NAV 4.2 og 4.3 med demo

25 minutter av møtet gikk med til teknisk plunder og heft med Skype for Business-forbindelsen med Gro-Anita.

  • John-Magne demonstrerte ny funksjonalitet i webgrensesnittet fra NAV versjon 4.2 og 4.3 (generalprøve på det han skulle presentere på neste dags verktøysamling).
  • Endringene som er gjort i NAVs datamodell for å støtte virtuelle enheter ble diskutert.
    • Spørsmål fra UiT om multi-homing av tjenester på servere, men dette ligger allerede på arbeidslisten.
  • Geomap
    • UiT synes Geomap fremdeles er ubrukelig treg under NAV 4.2.
    • Børge etterlyser flercampus-løsning for Geomap. Litt usikkert hva dette innebærer (men MPLS mellom fusjonerte campus, levert av UNINETT, ble nevnt).
  • Netmap
    • UiT synes også Netmap er for treg. NAV bør ha disse verktøyene (og de bør være “kjappe”) for å gjøre de mer ikke-tekniske brukerne tilfredse med NAV.
  • Statussiden
    • Alle er enige i at modul- og chassis-status bør kjøres oftere enn hver 6. time :!: LP#1463724.
    • UiT ønsker å ha actions på alarmer i ipdevinfo recent alerts-fanen, på lik linje med statussiden :!:.
    • konsensus om at boksnavn bør komme først i Subject :!:
  • Frontpage med widgets
    • Forsamlingen uttrykte ønske om fullskjermsvisning (f.eks. til bruk på infotavler) :!:

Fokus for videre utvikling

  • Morten sa noen ord om hvordan utviklerne kunne tenkt seg å prioritere fremover.
    • NAV er portert til Django 1.7 på en egen gren, men mangler mer testing. 1.7 er brukt i siste Debian stable (Jessie)
    • Debian Jessie har kastet ut pynetsnmp, siden pakker ikke har en aktiv maintainer og ikke lenger ser ut til å være kompatibel med den versjonen av NET-SNMP som følger med i Jessie. Dette betyr at vi må begynne å se på kompatibilitet med en nyere versjon av pynetsnmp.
    • Hardware-støtte for Juniper
    • Transceivere som egen type
    • NETCONF (og kanskje SNMPv3)
    • BGP / IS-IS / etc. - Vil gjøre NAV mer salgbart i store lag 3-nett, inkludert UNINETT selv (og andre forskningsnett)
  • Børge nevner at Cisco har kjøpt SCI, som skal være Cisco sitt svar på SDN
    • Hvordan kan NAV bidra i en fremtid med økt fokus på SDN og skytjenester? Ingen svar fra salen.

Før lunsj kom en rekke innspill til ny eller forbedret funksjonalitet. Disse er oppsummert i referatet under “runde rundt bordet”.

Lunsj ca. 12:15.

Nye innspill fra referansegruppen

Dette forløp som en løs diskusjon i forlengelsen av forrige punkt på agendaen, før det gikk over i en “runde rundt bordet” for å få innspill fra hvert enkelt medlem.

  • Børge snakket om APIC-EM (usikker på hva koblingen var her, men Cisco Prime ble nevnt like i forkant). http://www.cisco.com/c/en/us/products/cloud-systems-management/application-policy-infrastructure-controller-enterprise-module/index.html
  • Peder snakket varmt om Appflow.
  • Diskusjon/kritikk av UNINETTs fremgangsmåte ved valg av nye verktøy, uten involvering fra sektoren. Helt konkret ble UNINETTs valg av Zabbix, men påfølgende mulige endringer på VK-plattformen diskutert.
    • Et poeng som ble nevnt var viktigheten av at NAV/VK hele tiden videreutvikles til å kunne overvåke de tjenestene som tilbys av UNINETT og er i bruk i sektoren, så ikke administratorene velger å bruke penger på andre, mer kommersielle verktøy i stedet.
  • Morten innledet en diskusjon om integrasjon på kryss og tvers.
    • Brannfakkel: Kanskje alarmkonsollet skal rives ut av NAV og bli et eget programvareprosjekt som vi integrerer flere verktøy inn i mot? Ingen respons på dette.
    • Ingeborg nevner at UiT gjerne vil ha døralarmer gjennom NAV, men får det ikke til. MailIn er ikke så enkelt som man skulle ha ønsket?
      • Morten oppfordrer UiT til å ta kontakt om døralarm-problemstillingen sin; det kan være grunnlag for å forbedre dokumentasjonen slik at det er lettere for folk å lage slike integrasjoner (eks. AKCP-probestøtte som ble brukt som grunnlaget for en howto-guide i høst).
    • NAV bør være i stand til å holde tilstand på alarmer fra eksterne systemer som ikke knytter seg til komponenter som er registrert i NAV fra før.

Runde rundt bordet:

  • UiA
    • Ønsker forbedret paginering i report. Dagens versjon har bare lenker til forrige og neste side, men Rune kan tenke seg en side-indeks så man kan hoppe til vilkårlige resultatsider LP#1466462.
  • UiT
    • Sitat Ingeborg: “Etter 14 år begynner dette å bli brukandes!”
    • Kunne tenkt seg en snarvei fra “Add netbox” i SeedDB for å opprette et nytt rom i samme slengen som man legger til en ny boks :!:.
    • Mener det er for lett å navigere vekk fra “Add netbox” før man har lagret, og dermed risikere å miste endringene sine. Advarsel ved forsøk på navigere vekk fra modifisert skjema? :!:
    • Ingeborg synes howto-guiden for implementasjon av ny sensor-hardware er for teknisk
      • Morten oppfordrer nok en gang til å ta kontakt. Dårlig dokumentasjon fortjener en bugrapport.
    • Bugrapport om maintenance. En jobb som ikke lenger har noen IP devices knyttet til seg driver og bomber med maintenance-alarmer. Ligger visstnok i Launchpad allerede, og er kanskje forsøkt løst uten hell.
    • Børge jobber for tiden med “blåruss”-ting, og vil gjerne ha rapporter som er nyttige her:
      • “Hvor mange av netboxene våre er så og så gamle”
      • “Hvor mange switcher er eldre enn syv år”
      • Kommentar fra Peder: Produksjonsår, uke, og muligens produksjonssted er kodet inn i serienummeret på Cisco-utstyr. Kunne man laget en blårussrapport ut av dette?
      • Peder mener det også skal være mulige å lese ut i fra serienummer hvorvidt switchen kan gi PoE.
      • Børge mener sysObjectID er ikke alltid entydig. I mange tilfeller finnes det manger undertyper av bokser gjemt innenfor samme sysObjectID. Børge har eksempel på en annen OID som kanskje kan brukes til videre klassifisering.
        • Red.anm: I ettertid viser deg seg at det er snakk om ENTITY-MIB::entPhysicalModelName for chassis-entities, som vi allerede samler inn i NAV 4.3. Forslag til rapport oversendt Børge.
    • Ingeborg ønsker seg repeterende maintenance tasks. Fins allerede som gammel sak på LP: https://bugs.launchpad.net/nav/+bug/300712
    • Ingeborg klager på dårlig ytelse i devicegroups-“rapporter”. John-Magne skal ha jobbet med dette i høst, men UiT antyder at det fremdeles er for tregt. Har sannsynligvis sammenheng med uthenting av data fra Graphite til oppetidstall.
      • JM: Rapport-definisjoner som gir vesentlig kjappere resultat oversendt UiT, foreløpig ingen tilbakemelding på om det var tilfredsstillende.
    • Ingeborg etterlyser kombinasjonssøk på devicegroup og organisasjon.
      • Red.anm.: Kan kanskje løses med et filter på devicegroups-siden?
    • Kunne kanskje tenkt seg “Grupper av grupper”?
    • Hva med “gruppesøk” i API?
  • UiO
    • Har en switch som er litt “rar”. Rapporterer 60 porter som ikke gir mening. Cisco 2960.
      • Morten oppfordrer til å sende bugrapport.
    • Ellers ikke noen større ønsker.
  • HiVolda
    • Ønsker mer gradering av rettigheter i PortAdmin. Eks. lærling som bare har lov til å sette bestemte VLAN. Høres ut som behovet dekkes av PortAdmins NTNU-modus. Peder bes undersøke dette før han evt. kommer tilbake til saken.

* Rettigheter, PoE og Appflow var tre hovedpunkter som allerede er sneket inn i løpet av dagens diskusjoner.

  • Til opplysning: Ny IOS-release angir at det er fikset en bug ift. slow SNMP-response på VSS (en sak vi har hatt gående lenge).
  • NTNU
    • Gro-Anita har også et blårussønske: Antallstrender pr. utstyrstype (fins som egen LP-sak allerede: LP#1321249)
    • “Yokohama”: Styre maks Y-verdi på grafer?
      • JM says: Vi innfører Rickshaw på relevante grafer i stedet. Rickshaw gir muligheten for selv å bestemme delen av grafen man vil se på, og dermed kan man se vekk fra spikes. Relevant LP wishthing: https://bugs.launchpad.net/nav/+bug/1350815

Runden rundt bordet avstedkom en generell diskusjon om “blårussrapporter”:

  • Forslag fra Morten om “Availability-report” som egen tool, med justeringsmuligheter som dagens SQL-rapport ikke kan tilby. Evt. som del av devicehistory - det er jo en slags oppsummering av rådata som devicehistory allerede viser.

Dato for neste møte

Foreløpige datoforslag var 4., 5., 11. og 12. november. Intet valg ble truffet i løpet av møtet, Foodle sendes ut i etterkant. Spørsmål om det fins noen andre UNINETT-samlinger rundt denne tiden av året som vi kan legge det inntil.

nav-ref/navref_010615.txt · Last modified: 2015/11/13 14:33 (external edit)