# Lime App Lime_Comunity file edition capabilies

La propuesta seria:
- la limeapp consume el archivo lime community en formato txt (a valorar, parsearlo a JSON)
- Lo parsea y muestra dejando editar las configuraciones q hay escritas
- Cuando hacemos start transaction mandamos como parametro el nuevo lime config
- Propagamos el nuevo lime config mediante shared state, metiendolo dentro de shared state solo en el estado del MAIN NODE o haciendo q se descarguen el archivo los otros nodos
- Iniciamos safe reboot copiando el lime community a pelo y ejecutando `lime config`

# sample lime comunity contents
https://github.com/libremesh/network-profiles/blob/master/calafou/outdoor_nongateway/root/etc/config/lime-community

https://github.com/libremesh/network-profiles/blob/master/LibremeshTestBed/indoor_omnidirectional_dualband/root/etc/config/lime-community

# sample lime comunity editable contents
proposed editable components

config lime wifi
option country 'ES'
option ap_ssid 'Calafou'
option apname_ssid 'Calafou/%H'
option ieee80211s_mesh_id 'libremesh'

config lime-wifi-band '5ghz'
option channel '36'

config lime-wifi-band '2ghz'
option channel '1'

the rest should be edited using the full file.

- Ideas, which is the best way to

to json:

{
    "lime wifi": {
        country: 'ES',
        ap_ssid: 'Calafou'
        //...
    },
    "lime-wifi-band '5ghz'":{
        channel: '36'
    },
    
    "lime-wifi-band '2ghz'":{
        channel: '1'
    }
}

To uci:

local uci = config.get_uci_cursor()
uci:set(config.UCI_COMMUNITY_NAME, 'lime wifi', 'country', 'ES')
uci:set(config.UCI_COMMUNITY_NAME, 'lime wifi', 'ap_ssid', 'Calafou')
uci:set(config.UCI_COMMUNITY_NAME, 'lime-wifi-band '5ghz'', 'channel', '36')
uci:commit(config.UCI_COMMUNITY_NAME)
utils.unsafe_shell("lime-config")

# Ubus api

NOTAS(kon):
- Necesito un endpoint para obtener la configuracion actual
get_comunity_config

- Necesito un endpoint q me dé una lista de configs y definicion de key values q se puedan editar (las configuraciones permitidas)

- Y si lo hacemos completamente sincrono? No via shared state, no es necesario usarlo!
- Hemos hablado de hacerlo todo completamente syncrono. Para ello simplemente consumiremos llamadas RPC que realizen toda la operación.

local methods = {
    become_main_node = {
        url = "value"
    },
    start_config_transaction = { --grabara un archivo temporal se calcula el hash y queda a disposición para arrancar se distribuye por SS 
        no_params = 0
    },
    get_comunity_config = {
        no_params = 0
    },
    set_new_comunity_config = {  --grabara un archivo temporal se calcula el hash y queda a disposición para arrancar -- no es necesaria
        no_params = 0
    },
    get_node_status = {
        no_params = 0
    },
    start_safe_reboot = {  --hace backup, pisa el nuevo config, configura el nuevo config y espera por el safe reboot
        confirm_timeout = 0,
        restart_delay = 0,
    },
    confirm_transaction = { -- desactiva el reboot
        no_params = 0
    },
    abort = {
        no_params = 0
    }

}

# Posible upgrade states enumeration

    upgrade_states = {
        DEFAULT = "DEFAULT", -- When no config has changed
        WORKING = "WORKING", -- when a user starts changing the config
        READY_FOR_APLY = "READY_FOR_UPGRADE" -- the config is set in the node and is ready to reboot 
        RESTART_SCHEDULED = "UPGRADE_SCHEDULED", -- the node will reboot in xx seconds 
        CONFIRMATION_PENDING = "CONFIRMATION_PENDING", -- the node rebooted and the configuration is not confirmed 
        CONFIRMED = "CONFIRMED", -- the configuration has been set and the user was able to confirm the change
        ERROR = "ERROR",
        ABORTED = "ABORTED"
    }

# Main node specific states

    main_node_states = {
        NO = "NO",
        STARTING = "STARTING",
        MAIN_NODE = "MAIN_NODE"
    },

# list of possible errors

    errors = {
        DOWNLOAD_FAILED = "download_failed",--???
        CONFIRMATION_TIME_OUT = "confirmation_timeout",
        ABORTED = "aborted",
        CONFIG_FAIL = "Fali while aplying the config",
        INVALID_CONFIG_FILE = "invalid_config_file"
    },

# shared state data (status)

{
    "LiMe-462895": {
        // "repo_url": "http://10.13.115.170/config/",
        "lime_config": "config lime network\n\toption main_ipv4_address '10.1.128.0/16/17'\n\toption anygw_dhcp_start '2562'\n\toption anygw_dhcp_limit '30205'\n\toption batadv_orig_interval '5000'\n",
        "safe_restart_remining": -1,
        "safe_restart_start_mark": 0,
        "transaction_state": "DEFAULT",
        "current_config_hash": "asdsadasd2331", // Hash de la configuracion actual (para saber si la configuracion actual del main node es distinta a la del nodo local y guardarla)
        "new_config_hash": "asdsadasd2331", // Hash de la nueva config (why?)
        "main_node": "NO",
        "node_ip": "10.13.40.149",
        "safe_restart_start_time_out": 0,
        "timestamp": 0,
        "error": "0",
        "retry_count": 0
    },
}

# Steps del algoritmo

1. Become main node (para q solo haya un nodo) sirviendo la nueva configuracion via archivo o en el shared state directamente
2. Si un nodo recibe q hay un main y una configuracion valida (validada via ??) se pone en estado ready for apply
en shared state aparecera toda la info, el nodo obtiene el texto genera un archivo temporal y lo valida, verifica el hash con el main
- Hacer backup del config. Si existe un un problema de sync q no coincide el current config hash guarda un backup extra persistente tipo lime-community.{hash}.back para poder recuperar si ha havido modificaciones manuales previas

4. Aplicar la nueva config:
- Pisar la config con el nuevo file
- Reiniciar despues del restart_delay
6. Confirmar y si no se confirma deshacer el backup

Nodo A

modificion manual
Recibe un lime upgrade -> Machacar de configuracion -> Si el current config hash es distinto
Se guarda la configuracion manual en un lime-community.hash

Node B

Main node

# POC
1. become_main_node

    tar -czf /overlay/upper/.etc.last-good.tgz -C /overlay/upper/etc/ .

2. get_comunity_config - get actual configuration all the file
the user changes lime community file

3. start_config_transaction - args: new community config file
1. write community config file
2. Start config transaction. Notify all members of the new config being served in this node

We have two options her to share the new configuration
a) write a file and share it on the same way as do the FBW or Mesh Upgrade
b) The MAIN_NODE share the configuration using shared state. The other nodes inform if they received
the configuration (if they are synched with a main node).

> **wait for everyone to fetch the new config** (sharedstate)
>
> **ask for everyone to fetch the new config** (async )
>
> become_bot_node
> ```bash
> tar -czf /overlay/upper/.etc.last-good.tgz -C /overlay/upper/etc/ .
> wget newconfig
>
> ```

5. start_safe_reboot **tell everyone to reboot**

    lime-config
    safe-reboot now

test the new config

6.a. confirm_transaction

safe-reboot cancel #to confirm successfull operation 

6.b. abort

safe-reboot discard # to abort or wait for restart