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 Lync)

Gjesteopptreden:

• Ingeborg Hellemo, UiT

Forfall:

• Vidar Faltinsen, UNINETT

Møtet ble avhold 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)

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

• 25 minutter av møtet gikk med til teknisk plunder og heft med Lync-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.
  • 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 uttrykket ønske om fullskjermsvisning (f.eks. til bruk på infotavler)

• 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.

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.

• UiT
• Sitat Ingeborg: “Etter 14 år begynner dette å bli brukandes!”
• 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 on/offMaintenance-alarmer. Ligger visstnok i Launchpad allerede, og er kanskje forsøkt løst uten hell.

1. Børge jobber for tiden med “blåruss”-ting.
   1. “Hvor mange av netboksene våre er så så gamle”
   2. “Hvor mange SW er eldre enn syv år”
   3. Produksjonsår, uke og sted er kodet inn i serienummeret på

Cisco-utstyr. Kunne man laget en blårussrapport ut av dette?

1. HiVolda kommentar: Hvilke switcher kan gi PoE? Det er visst også

lesbart fra serienummer…

1. (red.adm: er RFC 3621 brukandes til noe?)

1. sysObjectID er ikke alltid entydig. I mange tilfeller finnes det

manger undertyper av bokser gjemt innenfor samme sysObjectID. Børge

      har en annen MIB som kanskje kan brukes til videre klassifisering.
      Ligger visstnok i MIB-II (har fått på mail av Børge).

1. Repeterende maintenance? Fins som LP-sak.
2. Rapporter med devicegroups har dårlig ytelse pga. oppetidsrapporter? Vi

har visstnok arbeidet med å gjøre det raskere i høst, men det må

    fremdeles gjerne gå fortere.

1. UiO
   1. Har en switch som er litt “rar”. Rapporterer 60 porter som ikke gir

mening. Cisco 2960.

1. Ellers ikke noen større ønsker.

1. HiVolda
   1. Rettigheter, PoE og Appflow var tre hovedpunkter som allerede er sneket

inn i løpet av dagens diskusjoner.

1. Ny IOS-release angir at det er fikset en bug ift. slow SNMP-response på

VSS.

1. NTNU
   1. Blåruss: Trender pr. modelltype (fins som egen LP-sak allerede: 1321249)
   2. PortAdmin: Skulle gjerne kunne satt speed på porter.
   3. “Yokohama”: Styre maks Y-verdi på grafer?

1. Blårussbehov:
   1. 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.

- Neste møte?

1. Fins det noen samlinger vi kan legge det inntil? Trådløssamlinger?

- SeedDB

1. Peder kunne tenkt seg en snarvei fra “Add netbox” for å opprette et nytt

rom i samme slengen.

1. Lett å navigere vekk fra “Add netbox” før man har lagret.

- device groups

1. Ingeborg etterlyser søk på devicegroup i kombinasjon med org.
2. Grupper av grupper?
3. Gruppesøk i API?

- Peder ønsker mer gradering av rettigheter. Eks. lærling som bare har lov til

å sette bestemte VLAN. Høres ut som Portadmins NTNU-mode.

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.