Cloud Computing

Eso facilitaría además la exportación de variables, pudiendo estar todas en el bashrc ¿no?

Hago de abogado del diablo:

Si en casi toda la documentación indica esos usuarios, por algo será. Es decir, me parece lógico lo de los usuarios de la base de datos, no creo que sea necesario tener uno para cada servicio, sin embargo los usuarios de keystone me parece que no es tan complicado ponerlo y hacemos el sistema más flexible. ¿Y si más adelante hay que tratar de forma distinta (autorizaciones, políticas diferentes en diferentes proyectos,...) a cada usuario de cada servicio).

Yo opinó que no nos quitamos mucho trabajo, y que sin embargo más adelante nos podemos arrepentir.

Por lo tanto voto por reducir el número de base de datos, pero dejar la configuración de keystone como se nos sugiere (usuarios, roles, tnenats).

Hay que decidirlo.

Un saludo

No os sigo, ¿qué tiene que ver que los servicios estén o no en el mismo equipo?

Yo prefiero usuarios separados, de esta forma cada servicio tiene sus credenciales de autenticación. ¿Qué ventajas tiene reducir el número de usuarios?

Otra cosa, como la creación de usuarios en Keystone es un coñazo, he preparado un pequeño script que lo hace todo.

Sed libres de utilizarlo, modificarlo, mejorarlo o simplemente descartarlo. Lo he hecho porque ya van cuatro las veces que he seguido el procedimiento manual, y me aburre bastante :)

Es simplemente por simplificar todo. De forma general se permite crear diferentes usuarios para cada base de datos y diferentes usuarios de keystone para cada componente. Si a cada usuario le ponemos una contraseña de verdad y diferente, se complica la gestión inicial, y si le ponemos la misma, ¿para qué distinguimos el usuario?

Nosotros hemos optado por crear:

1 usuario en la BBDD

2 usuarios con el rol admin en keystone (uno para el tenant admin y otro para el tenant service)

Total: 3 contraseñas.