[ninux-dev] Diff della topologia

[Nemesis]

On 11/10/2014 10:45 AM, Clauz wrote:
> On 11/09/2014 11:34 PM, Nemesis wrote:
>> @Clauz: per quanto riguarda tutte le feature del vecchio parser, hai una
>> vaga idea di come potremo riportarle su questo nuovo? Ho paura che
>> alcune cose saranno toste perchè forse lo script che sta dentro nodeshot
>> 0.9 fa molte cose specifiche per noi... o sbaglio? Spero di sbagliarmi
>> ... :D
> La notte porta consiglio: forse abbiamo un problema di design. Provo a
> spiegarlo.
>
> Sulla rete di ninux Roma (ma non so quanto sia specifico di ninux Roma)
> abbiamo alcuni link wireless fatti in questo modo:
>  - da una parte del link wireless un apparato che NON parla OLSR, con
> indirizzo IP IP_A
>  - dall'altra parte del link wireless un apparato che parla OLSR e che
> annuncia in HNA una subnet che comprende IP_A
>
> Esempi di questo setup sono il link tra i nodi Namex (10.162.0.27) e
> Ninux (HNA 10.162.0.0/24), oppure tra Halnet-2 (10.135.4.254), Halnet-3
> (10.135.5.253) e Halnet (HNA 10.135.4.0/24 e HNA 10.135.5.0/24).
>

Ma questo caso che hai citato è la faccenda del link layer2? Quali altri
casi speciali ci sono?

In questo tipo di casi io si potrebbe dare la possibilità a nodeshot di
gestirli evitando di twistare netdiff.

Ad esempio: sul nuovo nodeshot potremmo creare i link speciali
manualmente e potremmo fare in modo che non vengano gestiti dal
componente che aggiorna la topologia. Poi magari dopo qualche tempo esce
fuori che un sacco di altra gente che usa netdiff ha lo stesso problema
e si implementa una soluzione direttamente in netdiff.

E' solo un esempio per rendere l'idea che non dobbiamo provare a
risolvere tutto subito, possiamo procedere un passo alla volta.

Per me i primi problemi da risolvere sono:

*netdiff*

 1. fare un diff che restituisce un json che dice quali link sono
    cambiati in una topologia OLSR, ignorando momentaneamente i casi
    speciali
 2. decidere la struttura del json che dice quali link sono cambiati
    (deve essere agnostico rispetto al protocollo di routing utilizzato)
 3. fare lo stesso con una topologia batman-adv
 4. fare una lista dei casi speciali (tipo quello spiegato da clauz
    nella mail precedente) - questo in realtà si può fare in parallelo
    ai punti precedenti

*nodeshot
*

 1. implementare una nuova django-app che usa netdiff per aggiornare il db
 2. far visualizzare i benedetti link su https://test.map.ninux.org/#/map

Il tutto con relativa documentazione, relativi unit tests, continous
integration testing su travis-ci.org, e facendo in modo che ognuno di
noi sappia come far girare i test sulla propria macchina o ambiente di
sviluppo (quindi evitando di sviluppare e testare cambiamenti su
sisttemi in produzione) e come scrivere nuovi test quando si aggiungono
nuove feature o si risolvono bug.

Se riusciamo a fare queste cose qui poi possiamo fare miglioramenti un
passo alla volta.

Nemesis

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://ml.ninux.org/pipermail/ninux-dev/attachments/20141110/12f8dbf8/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: OpenPGP digital signature
URL: <http://ml.ninux.org/pipermail/ninux-dev/attachments/20141110/12f8dbf8/attachment-0001.sig>