[ninux-dev] Nodeshot e netdiff, problemi implementativi

Nemesis nemesis at ninux.org
Wed May 13 09:28:54 CEST 2015


On 05/13/2015 04:13 AM, Gabriel wrote:
> Sto tentando di implementare un sistema per usare netdiff per
> aggiungere dinamicamente i link nel database di nodeshot.
>
> Per ora ho creato un modello chiamato Topology.
> Il concetto è simile a un Layer, ma per i Link anziche i nodi.
> Questo modello contiene :
>
> il tipo di parser netdiff da usare,
> il protocollo di routing,
> l'url da cui scaricare la topologia,
> un nome,
> un riferimento al layer di appartenenza(forse è inutile).

Se è inutile lascialo subito fuori, aggiungilo solo quando ne hai
estremente bisogno.
Te lo dico per esperienza, ho fatto questo errore più volte.

> Stavo guardando un po la struttura che hai dato alle informazioni di
> rete in Nodeshot. E' molto strutturata, ma mi sembra di aver capito che
> ip -> interface -> device -> node -> layer
> dove -> è 1-as-many
>
> Il primo problema che mi è venuto in mente
> Dove mettere il riferimento topology?
> Inizialmente pensavo tra layer e nodi, ma parecchi casi di routing
> complesso (nodo dual stack/nodo con due protocolli/ supernodi)
> rimarrebbero male implementabili.

(parlando di un prototipo da migliorare nelle iterazioni successive)

Metti il riferimento a Topology sul modello Link
(nodeshot.networking.links.models.Link).

è la cosa più semplice, un link fa parte di una topologia.

Quando parsi la topologia per ogni link nel JSON hai due ID, mac o ip.

Se è un mac fai una query su Interface, se è un ip fai una query su Ip.

L'importante è che le informazioni degli IP e dei MAC siano nel DB, in
questo modo puoi ignorare la questione alias.

Risali alle interfacce, quindi:

se devi aggiungere: crea un Link da interface_a ad interface_b, setta il
tipo di link, fai full_clean e salva, il resto viene creato da solo
se devi rimuovere: recupera il link che ha le due interfacce (l'ordine
può essere invertito)

Le oprazioni che aggiornano la topologia (aggiungono, rimuovono), creano
un netjson a partire da quello che è nel DB, e simili dovrebbero essere
funzioni che potrebbero stare in nodeshot.networking.links.utils.

Per aiutarti puoi fare un django management command chiamato
"update_topology" o simile, che chiama le funzioni in utils.

Lo stesso andrebbe fatto per creare un celery task "update_topology" che
può essere messo nella configurazione di celery-beat e può girare in
background ogni X minuti.

Nemesis

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: <http://ml.ninux.org/pipermail/ninux-dev/attachments/20150513/0a7e852f/attachment-0001.sig>


More information about the ninux-dev mailing list