nav-ref:navref_231018
Differences
This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision Next revision | Previous revision Next revision Both sides next revision | ||
|
nav-ref:navref_231018 [2018/10/24 08:14] morten referat del 1 |
nav-ref:navref_231018 [2018/10/24 10:41] morten Uit |
||
|---|---|---|---|
| Line 8: | Line 8: | ||
| * Morten Brekkevold, //Uninett// | * Morten Brekkevold, //Uninett// | ||
| * Hanne Moa, //Uninett// | * Hanne Moa, //Uninett// | ||
| - | * Sigurd Refvik, //UiO// | + | * Sigurd Refvik, //UiO// |
| * Peder Magne Sefland, //HiVolda// | * Peder Magne Sefland, //HiVolda// | ||
| * Rune Kittelsen, //UiA// | * Rune Kittelsen, //UiA// | ||
| Line 29: | Line 29: | ||
| ==== 1. Presentasjoner/Status ==== | ==== 1. Presentasjoner/Status ==== | ||
| + | |||
| === Hva har blitt gjort siden sist === | === Hva har blitt gjort siden sist === | ||
| Line 92: | Line 92: | ||
| ===== Referat ===== | ===== Referat ===== | ||
| - | === Del 1 - Presentasjoner/Status === | + | ==== Del 1 - Presentasjoner/Status ==== |
| Morten ønsket velkommen og begynte med å gå gjennom noen nyheter siden forrige møte (inkludert listen over nye versjoner som er sluppet siden sist). | Morten ønsket velkommen og begynte med å gå gjennom noen nyheter siden forrige møte (inkludert listen over nye versjoner som er sluppet siden sist). | ||
| Line 101: | Line 101: | ||
| * UiT lurer på om nytt byggesystem vil løse problematikken med at konfigurasjonsfiler blir overskrevet under installasjon fra kildekode. Svaret er at det vil det for så vidt, men at håndtering av konfigurasjonsfiler forøvrig anses som et anliggende for pakkesystemet/OS. | * UiT lurer på om nytt byggesystem vil løse problematikken med at konfigurasjonsfiler blir overskrevet under installasjon fra kildekode. Svaret er at det vil det for så vidt, men at håndtering av konfigurasjonsfiler forøvrig anses som et anliggende for pakkesystemet/OS. | ||
| + | * Ang. nye "interface browser": | ||
| + | * Mangler sortering på last used | ||
| + | * Det var ikke helt klart for alle hva kolonnen "Admin" representerer. Kan tittelen forbedres? | ||
| + | * Det burde vært mulig å slå på PoE-informasjon i tabellen. | ||
| + | * Ett ønske om fargegradering på kolonnen "Last used", i tråd med den gamle "switch port activity"-fanen i ipdevinfo. | ||
| Det ble en diskusjon rundt ressurssituasjonen i Uninett og Nettadministrasjons-aktiviteten, nå som John-Magne har sluttet. Planlegging av neste års aktivitet er underveis, og det er foreløpig budsjettert med samme antall timer i 2019 som i 2018 (men endelig budsjett er ikke godkjent enda). Det er gjort nyansettelser i Avdeling for system og mellomvare, men det er enda ikke 100% klart hvilke ressurser som kan/skal levere alle utviklingstimene. Det er også fremdeles uklart hvordan Uninett er organisert fra 1. januar. | Det ble en diskusjon rundt ressurssituasjonen i Uninett og Nettadministrasjons-aktiviteten, nå som John-Magne har sluttet. Planlegging av neste års aktivitet er underveis, og det er foreløpig budsjettert med samme antall timer i 2019 som i 2018 (men endelig budsjett er ikke godkjent enda). Det er gjort nyansettelser i Avdeling for system og mellomvare, men det er enda ikke 100% klart hvilke ressurser som kan/skal levere alle utviklingstimene. Det er også fremdeles uklart hvordan Uninett er organisert fra 1. januar. | ||
| Line 108: | Line 112: | ||
| SUNET og Uninett har sammen pitchet idéen om **CNaaS** (//Campus Network as a Service//) til Géant og fått denne antatt i en work package for GN4-3, som starter opp i 2019. Kort forklart ønsker denne aktiviteten å utvikle verktøy for at NREN skal kunne tilby drift av campusnettverk som en tjeneste til sine kunder, noe både SUNET og Uninett ønsker å levere. NAV vil være et sentralt verktøy i denne tjenesten, og Morten vil få et større timeantall finansiert gjennom denne aktiviten for å utvikle forbedret funksjonalitet i NAV. | SUNET og Uninett har sammen pitchet idéen om **CNaaS** (//Campus Network as a Service//) til Géant og fått denne antatt i en work package for GN4-3, som starter opp i 2019. Kort forklart ønsker denne aktiviteten å utvikle verktøy for at NREN skal kunne tilby drift av campusnettverk som en tjeneste til sine kunder, noe både SUNET og Uninett ønsker å levere. NAV vil være et sentralt verktøy i denne tjenesten, og Morten vil få et større timeantall finansiert gjennom denne aktiviten for å utvikle forbedret funksjonalitet i NAV. | ||
| + | |||
| + | ==== Del 2 - Fokus for videre utvikling/tilbakemelding ==== | ||
| + | |||
| + | Den [[https://nav.uninett.no/wiki/nav-ref:nav-ref-arbeidsliste|stående arbeidslisten]] ble gjennomgått og kommentert. | ||
| + | |||
| + | Kommentarer til arbeidslisten: | ||
| + | * [[https://github.com/UNINETT/nav/issues/1176|#1176]] - NETCONF support in NAV | ||
| + | * Morten presiserte at denne oppgaven innbefatter mer enn selve NETCONF-protokollen. RESTCONF er like aktuelt - det som er viktig er de nye YANG-datamodellene. Alle protokoller som benyttes av leverandørene til å utveksle YANG-informasjon bør støttes av NAV. | ||
| + | * <del>[[https://github.com/UNINETT/nav/issues/1242|#1242]] - Power over ethernet (POE) interfaces</del> | ||
| + | * **[[https://github.com/UNINETT/nav/issues/new|ISSUE]]** Det ble igjen uttrykt ønske om å få informasjon om strømforbruk per port. | ||
| + | * Usikkert hvorvidt de gjeldende MIB-er kan gi så detaljert informasjon på dette nivået. | ||
| + | * Det ble også vist til at en Cisco C2960 gir andre PoE-tall med SNMP enn i CLI | ||
| + | * Rune pekte på en spesifikk switch hos UiA som utviser dette problemet. Kan undersøkes i etterkant av møtet. | ||
| + | * <del>[[https://github.com/UNINETT/nav/issues/1232|#1232]] - Collect DOM-data</del> | ||
| + | * Det er fremdeles usikkert hvorvidt tilfredstillende DOM-informasjon blir samlet inn for HP-utstyr. | ||
| + | |||
| + | |||
| + | ==== Del 3 - Nye ønsker og innspill fra gruppen ==== | ||
| + | |||
| + | UiT fikk begynne runden rundt bordet, med sine skriftlig innmeldte innspill: | ||
| + | |||
| + | * [[https://github.com/Uninett/nav/issues/1779|#1779]] Support for Powertek PDU | ||
| + | * [[https://github.com/Uninett/nav/issues/1777|#1777]] PDU-widget, support for more PDUs | ||
| + | * NAV støtter innsamling fra f.eks. Raritan-PDU-er, men widgeten er spesifikk for APC-PDUer. Kan vi lage en mer generisk widget? | ||
| + | * [[https://github.com/Uninett/nav/issues/1743|#1743]] Change attributes in router interface description | ||
| + | * Det ble usikkert hva UiT egentlig ønsker at NAV skal gjøre med eventuell location-informasjon i ruterport-descriptions, så Ingeborg skal med seg saken tilbake til sine kollegaer for utdyping. | ||
| + | * [[https://github.com/Uninett/nav/issues/1725|#1725]] Env sensor support for Watchdog15 and Geist | ||
| + | * [[https://github.com/Uninett/nav/issues/1668|#1668]] A link has two ends - can both endpoints own link events | ||
| + | * To måter å løse dette på: | ||
| + | * "Enkel" måte: Lage separat alarm for hver ende av linken. Ulempen er at alle linkalarmer blir to forskjellige alarmer. I tillegg trengs en egen type alarm for degradert link til en server, da man på serversiden ikke har et interface å knytte alarmen til. | ||
| + | * Vanskelig måte: Endre alertsystemet i NAV fullstendig for å tillate å koble multiple objekter til enkeltalarmer. | ||
| + | * [[https://github.com/Uninett/nav/issues/1667|#1667]] Status widget - more info for linkState | ||
| + | * Dette kan fås i dag i Status tool, men av en eller annen grunn liker folk å bruke status widget i stedet. Status widget er trang og har ikke plass til utvidet informasjon. | ||
| + | * Et forslag fra John-Magne i trackeren er å benytte seg av hover/tooltip til utvidet informasjon om alarmer i widgeten. Referanse til en WIP-issue for interface-info her. | ||
| + | * [[https://github.com/Uninett/nav/issues/1666|#1666]] Status report for given time period | ||
| + | * En gjenganger: Dette fins allerede i Device History, men Device History virker utdatert ift. nye Status tool. Device History bør egentlig ses på som et supersett av Status tool, hvor man kan velge tidsperiode selv (mot Status, som bare viser alarmer som ikke er avsluttet). | ||
| + | * UiT ville ha en diskusjon om Cisco DNA Center (som de mener vil få utbredelse) og alt som ellers rører seg i "skjulte" eller proprietære nettskyer (som f.eks. i VMWare-nett) hvor nettet ikke kan observeres med SNMP. Cisco DNA Center har et API som kan brukes til å se alt som er samlet inn - kunne NAV evt. hentet ut data fra et slikt API? | ||
| + | * Håpet var å få i gang en diskusjon med NTNU her, da de også har tatt i bruk Cisco DNA Center, men NTNU hadde meldt forfall. | ||
| + | * Ingeborg håper denne idéen sår et frø som kanskje modner til en diskusjon på neste møte. | ||
| + | * **[[https://github.com/UNINETT/nav/issues/new|ISSUE]]** Ut i fra diskusjonen om utstyrsstøtte, ble det ytret ønske om bedre dokumentasjon av hvilke typer utstyr som er støttet. Ikke bare i sentral dokumentasjon, men f.eks. der man har en PDU-widget som strengt tatt bare støtter APC-PDU-er, så burde den informasjonen være tilgjengelig direkte i eller i forbindelse med widgeten-en i grensesnittet. | ||
| + | * **[[https://github.com/UNINETT/nav/issues/new|ISSUE]]** Ønske om at feilmeldinger fra feilende ipdevpoll-jobber tilgjengeliggjøres i webgrensesnittet (så man eksempelvis slipper å lete i logger når man har en rød jobb-lampe i ipdevinfo) | ||
| + | |||
| + | UiA ønsket å diskutere følgende punkter: | ||
nav-ref/navref_231018.txt · Last modified: 2018/10/24 11:31 by hmpf
Page Tools
