# MESHWINDE TODOS

## BACKEND TODO

- revisar los tiempos con Gio

Errores encontrados durante el test de mesh upgrade

- Necesito alguna forma de saber cuanto rato queda para q se ejecute el upgrade. Q tal a q hora se ha dado la orden (la de la limeapp o la del router??) y cuanto timeout tiene configurado?

DONE (jj): en el node status agregar el remining de los dos timers

- Cuando hace el schedule, shared state no alcanza a recibir el cambio de estado.

- Si falla la download de eupgrade el estado se queda en STARTING_MAIN_NODE

{
  "1": {
    "eupgradestate": "download-failed",
    "retry_count": 0,
    "safeupgrade_start_remining":0,
    "confirm_remining":0,  
    "upgrade_state": "ERROR",
    "current_fw": "LibreRouterOs 1.5 r0+11434-e93615c947",
    "main_node": "STARTING",
    "node_ip": "10.1.243.246",
    "board_name": "librerouter-v1",
    "timestamp": 0,
    "error": "download_failed"
  }
}

TODO (jj)... cambiar a NO starting main node

- Al reiniciar, conserva el estado, lo q significa x ejemplo, q igual se piensa q es main node pero en realidad no lo es ya q no tiene la iso en /tmp, o q si esta en scheduled pero se reinicia antes de hacer perform upgrade pues se sigue viendo scheduled

TODO (jj)... cambiar a NO starting main node y pasa a error // validar cada estado
Done (jj) ... main node aborta... todos abortamos. por shared state... leeento

- Si se descarga una imagen q no es la suya o esta rota no se puede hacer sysupgrade pero no cambia el estado a ERROR se queda en READY_FOR_UPGRADE

TODO(jj) : una vez que se descarga debo hacer sysupgrade veryfy para pasar a READY_FOR_UPGRADE
DONE (JJ)

- Reboot y config file (nota mental para el Javi del futuro)
TODOS(jj) se pone en error si el estado no es correcto.
(kon) si esta en estado de error deberia poder arrancar una nueva
Done (jj) cuando reinicia y no tiene el firmware se pasa a error.

aborttt??? via RPC a main node -> shared state, via RPC uno a uno o via RPC a todos (??)

DONE: Aborted es un estado en si mismo. Es un estado por el q pasar para rearrancar

- Error al hacer schedule upgrade. Tiene pinta q no sean compatibles con safe upgrade. Quizas se tendria q hacer un check al principio de todo en las primeras funciones q diga q si no hay safe upgrade no es compatible (en cuanto intentes hacer cualquier cosa, antes de ser main node y tmb cuando la info del shared state, q haya algo q sea `safe-upgrade: true` y q si no es true directamente ni le enviemos nada y lo muestre en el shared state)
DONE(JJ): pusimos dependencia en el make file

root@LiMe-5a866f:~# ubus call lime-mesh-upgrade get_node_status '{}'
Command failed: No response
root@LiMe-5a866f:~# echo '{}' | /usr/libexec/rpcd/lime-mesh-upgrade call get_node_status
sh: safe-upgrade: not found
lua: /usr/lib/lua/lime-mesh-upgrade.lua:469: attempt to compare number with nil
stack traceback:
	/usr/lib/lua/lime-mesh-upgrade.lua:469: in function 'get_node_status'
	/usr/libexec/rpcd/lime-mesh-upgrade:31: in function 'get_node_status'
	/usr/libexec/rpcd/lime-mesh-upgrade:84: in main chunk
	[C]: ?
root@LiMe-5a866f:~# safe-upgrade confirm-remaining
-ash: safe-upgrade: not found

- Al hacer una fresh install y actualizar los packs de mesh upgrade al hacer `shared-state` `getFromSharedState` `mesh_wide_upgrade`, devuelve error. Testo en librerouterv1
DONE(jj) tenemos nueva interfaz

root@LiMe-1f73f6:~# echo '{"data_type": "mesh_wide_upgrade" }' | /usr/libexec/rpcd/shared-stat
e call getFromSharedState 
[] 
root@LiMe-1f73f6:~# ubus -S call shared-state getFromSharedState '{"data_type": "mesh_wide_upgrade" }'

todo: revisar para entender como funciona
done: es necesario llamar a shared-state-publish-all ... esto sucede automaticamente despues de un tiempo.

---probar con dos shared state
- Cada vez q tengo un error en descarga, para asegurarme q todo vuelvea su estado anterior, tengo q hacer un `sysupgrade -n` ejectuar, cargar los paquetes,, y reiniciar el router otra vez para evitar el bug anterior

- Si las ips rotan con cada reinicio, podria ocurrir q al hacer el reboot todo se rompiera..? Es decir, cuando se hace el sysupgrade, o cuando se vuelve a la version anterior
todo(kon) quedarse con el nombre del nodo y esperar la nueva ip por shared state
(jj) que pasa si cambia el nombre del nodo ?

- Si no se confirma vuelve al estado anterior pero el shared state esta en el estado transaction started.
(esto esta y quedaria en estado de error)
DONE

- A tener en cuenta de q el FW se ha perdido en el reinicio, asi q no tiene sentido estar en el modo transaction started. Ademas, habria q hacer la comprobacion de q el estado es el correcto cada vez, para comprovar q no se haya perdido el firmware, x ejemplo

- Se queda siempre en confirmed, asta cuando deberia estar asi?
apaaa....

## FRONTEND TODO

- ~~Si esta en download failed de el status del nodo se queda en downloading~~

- el boton de "confirmar" inicial esta bien pero en la ventana emergente diche shcedule (copy paste ? ) mando captura al telegram

- Si this node esta undefined y tiene un error, deberia salir q tiene un error pero se queda en loading

- ~~Implementar ABORT syncrono al nodo main solamente de momento~~

- ~~Si esta en estado de abort o error deberia poder volver a inicar el proceso entero.~~

- ~~Implementar guardar el estado de shared state antes de hacer el schedule upgrade para ver si todos los nodos estan levantados~~

JJ: Cuando todavia no tiene datos, acaba de reiniciar el nodo muestra error sobre los datos de async deberia decir espere ?

kon: Sobre esto no veo claro hacerlo en esta itreacion. Creo q deberiamos tener lo minimo para q funcioneel mesh upgrade.
Hacer tests sobre el estado anterior o posterior para mi es una feature nueva. Implica el diseño de ux/ui q puedan haber
errores y bugs etc...

Lo dejaria para futuras iteraciones y q ahora la comprobación de q la red está funcional se realize manualmente.

Realmente, guardar el estado de la red una vez echo el schedule upgrade es senzillo pero luego, como lo mostramos? En la pantalla
donde aparecen los nodos, dividirla en dos o poner una pestaña para ver el estado anterior cuando estas en awaiting to confirm, x ej.

jj:Tenemos problemas porque cambian ips y nombres de nodos (los nombres de nodos por defecto de libremesh)... calculo que macs tambien ... asi que va a ser dificil.

Si lo vemos necesario y hay tiempo lo implemento pero ahora voy a pasar a otras cosas importantes

kon: 100% deacuerdo

- cuando reinicia la app se demora un monton en actualizar el estado del nodo

- JJ Es necesario poder abortar un nodo en particular para que pueda volver a sumarse a una "fiesta" en curso