INFN wiki

Quando ci si autentica sulla Dashboard, questa cerca il primo (ordinato per id crescente) endpoint keystone pubblico, vede a quale regione si riferisce (nel nostro caso LNF), ed interroga i vari servizi OpenStack di quella regione per mostrare la pagina di accesso all'utente.
Se la regione in questione è down, la dashboard si blocca.
Soluzione: modificare l'id dell'endpoint nel db mysql.
La dashboard riprende a funzionare immediatamente senza che sia necessario far ripartire alcun servizio. Non funziona invece la disabilitazione dello stesso endpoint.

Bisogna quindi dare questo comando dal "servd" di Bari o del CNAF perché la Dashboard ritorni a rispondere correttamente:

root@servd:~# mysql -u root -pxxxxxxxx -h 127.0.0.1
mysql> use keystone;
mysql> select * from endpoint where interface like 'public' and service_id like '55f7998c1e6f48a6967296718fa772c6';
+----------------------------------+--------------------+-----------+----------------------------------+----------------------------------------+-------+---------+-----------+
| id                               | legacy_endpoint_id | interface | service_id                       | url                                    | extra | enabled | region_id |
+----------------------------------+--------------------+-----------+----------------------------------+----------------------------------------+-------+---------+-----------+
| 28017bec876241ceb3e884fcdee18e0b | NULL               | public    | 55f7998c1e6f48a6967296718fa772c6 | https://keystone.cloud.infn.it:5000/v3 | {}    |       1 | lnf       |
| 74d9404023654f2e8b8257f977babf8a | NULL               | public    | 55f7998c1e6f48a6967296718fa772c6 | https://keystone.cloud.infn.it:5000/v3 | {}    |       1 | bari      |
| ef23b45a79814facb6c25270de883de3 | NULL               | public    | 55f7998c1e6f48a6967296718fa772c6 | https://keystone.cloud.infn.it:5000/v3 | {}    |       1 | cnaf      |
+----------------------------------+--------------------+-----------+----------------------------------+----------------------------------------+-------+---------+-----------+
3 rows in set (0.00 sec)

mysql> update endpoint set id='28017bec876241ceb3e884fcdee18e0b' where id='f8017bec876241ceb3e884fcdee18e0b';

oppure, più semplicemente:

echo "update endpoint set id='f8017bec876241ceb3e884fcdee18e0b' where id='28017bec876241ceb3e884fcdee18e0b'" | mysql -u root -pxxxxxxx -h 127.0.0.1 keystone

Per pulizia, è consigliabile dare questo comando a problema risolto.

echo "update endpoint set id='28017bec876241ceb3e884fcdee18e0b' where id='f8017bec876241ceb3e884fcdee18e0b'" | mysql -u root -pxxxxxxx -h 127.0.0.1 keystone

Vale esattamente lo stesso per l'endpoint interno di glance, come è stato possibile verificare il giorno 6 agosto 2019. Dal servd di Bari o di LNF si esegue questo comando:

echo "update endpoint set id='fa7741cd7f05478f833be8d2776a824e' where id='2a7741cd7f05478f833be8d2776a824e'" | mysql -u root -projcyptAg8 -h 127.0.0.1 keystone

Per pulizia, è consigliabile dare questo comando a problema risolto.

echo "update endpoint set id='2a7741cd7f05478f833be8d2776a824e' where id='fa7741cd7f05478f833be8d2776a824e'" | mysql -u root -projcyptAg8 -h 127.0.0.1 keystone