<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 11/10/2014 10:45 AM, Clauz wrote:<br>
</div>
<blockquote cite="mid:5460892C.8020302@ninux.org" type="cite">
<pre wrap="">On 11/09/2014 11:34 PM, Nemesis wrote:
</pre>
<blockquote type="cite">
<pre wrap="">@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
</pre>
</blockquote>
<pre wrap="">
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).
</pre>
</blockquote>
<br>
Ma questo caso che hai citato è la faccenda del link layer2? Quali
altri casi speciali ci sono?<br>
<br>
In questo tipo di casi io si potrebbe dare la possibilità a nodeshot
di gestirli evitando di twistare netdiff.<br>
<br>
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.<br>
<br>
E' solo un esempio per rendere l'idea che non dobbiamo provare a
risolvere tutto subito, possiamo procedere un passo alla volta.<br>
<br>
Per me i primi problemi da risolvere sono:<br>
<br>
<b>netdiff</b><br>
<ol>
<li>fare un diff che restituisce un json che dice quali link sono
cambiati in una topologia OLSR, ignorando momentaneamente i casi
speciali<br>
</li>
<li>decidere la struttura del json che dice quali link sono
cambiati (deve essere agnostico rispetto al protocollo di
routing utilizzato)</li>
<li>fare lo stesso con una topologia batman-adv</li>
<li>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<br>
</li>
</ol>
<p><b>nodeshot<br>
</b></p>
<ol>
<li>implementare una nuova django-app che usa netdiff per
aggiornare il db</li>
<li>far visualizzare i benedetti link su
<a class="moz-txt-link-freetext" href="https://test.map.ninux.org/#/map">https://test.map.ninux.org/#/map</a></li>
</ol>
<p>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.<br>
</p>
<p>Se riusciamo a fare queste cose qui poi possiamo fare
miglioramenti un passo alla volta.<br>
</p>
Nemesis<br>
<br>
</body>
</html>