Buenos días… Actualmente nos encontramos con la versión de Huarpe_3.1.1 y queremos actualizar arai_usuarios y arai_documentos ya que nos encontramos en la la version arai_usuarios_3.1.9 y arai_documentos_1.3.3
Cuales serían las versiones compatibles con Huarpe_3.1.1 para actualizar ? y como se realizan las actualizaciones de los mismos?
Desde ya muchas gracias. Quedamos a la espera de su respuesta.
Saludos
Mirta Chicahuala
hola Mirta,
Desconozco el marco en el que están queriendo desplegar la versión de Huarpe ¿En el marco de implementar expediente electrónico integrado? ¿En el marco de tener un portal de autogestión propiamente dicho?¿En el marco de implementar algún otro circuito como el bundle de RRHH (con Mapuche) o actas digitales (con Guaraní)?
Conocer este marco nos ayuda en la respuesta que podamos darte.
Como respuesta genérica te puedo comentar en el marco de EEI es donde tenemos la compatibilidad de versiones testeadas y aprobadas, la última versión liberada v1.5.12, contiene las versiones:
Actualmente estamos trabajando en testear la versión EEI 1.6.0, pero todavía no está liberada, esta va a contener la versión de Huarpe por la que estás consultando (entre otras):
Saludos
Hola Facundo!
Mil gracias por responder a mi consulta.
Te comento que estamos queriendo desplegar Huarpe en el marco de implementar el Sistema de Expedientes electrónico Integrado con docker, para luego implementar el bundle de RRHH (con Mapuche).
Inicialmente comenzamos con la instalación de las siguientes versiones:
Huarpe v3.0.1
Usuarios v3.1.9
Documentos v1.3.3
Sudocu v1.3.6
Con estas versiones, ya hemos realizado la conexión de Mapuche 3.21.2 con Arai-Usuarios y ademas hemos realizado la migración de documentos de Nuxeo a Arai-Documentos.
Ahora lo que queremos realizar es la actualización de las versiones de huarpe, usuarios y documentos a los últimos releases que nos mencionas:
última versión liberada v1.5.12, que contiene las versiones:
Módulo Arai-usuarios v3.1.13
Módulo Arai-documentos v1.3.5
Módulo Huarpe v3.0.5
Módulo Sudocu v.1.4.5
Como seria el procedimiento para actualizar dichas versiones?
Desde ya muchas gracias. Quedamos a la espera de tu respuesta.
Saludos
Mirta Chicahuala
Hola Mirta,
Te paso en limpio algunos temas que conversamos.
La idea es que traten de avanzar en la migración por el lado de la documentación de EEI:
Espero con esto puedan avanzar y si tienen algún problema nos avisan.
Saludos
Buenos días Facundo
Te comento lo que estuvimos probando luego de la reunion mantenida en el dia de aye.
Siguiendo la documentación que nos pasaron: https://expedientes.siu.edu.ar/docs/1.4-to-1.5/, realizamos los siguientes pasos:
Borramos el stack de sudocu:
docker stack rm sudocu
Ejecutamos el comando:
docker run --rm --env SUDOCU_DB_HOST=192.168.xxx.xx --env SUDOCU_DB_NAME=sudocu --env SUDOCU_DB_PORT=5432 --env SUDOCU_DB_USER=postgres --env SUDOCU_DB_PASSWORD=xxxxxx ungs/sudocu-db-instalador:1.3.11
Ejecutamos el comando:
docker stack deploy --with-registry-auth --compose-file sudocu.yml sudocu
Cuando verificamos el estado del servicio vemos que la versión de los servicios de sudocu y postgres_db-sudocu siguen estando en la versión 1.3.6
Y además los servicios de los stacks de huarpe, usuarios y documentos siguen estando en las versiones anteriores.
Entonces realizamos las siguientes pruebas:
PRUEBA 1:
1- Modificamos la versión del instalador de sudocu en ungs/sudocu-db-instalador:1.4.5.
2- Repetimos los mismos pasos de bajar el stack de sudocu, ejecutar el comando de actualización de la base y desplegar sudocu.
3- Verificamos los servicios y siguen estando sudocu, huarpe, usuarios,documentos y postgres en la versión anterior.
PRUEBA 2:
1- Modificamos la versión del instalador de sudocu en ungs/sudocu-db-instalador:1.4.5.
2- Modificamos sudocu.yml colocando la versión 1.4.5
3- Repetimos los mismos pasos de bajar el stack de sudocu, ejecutar el comando de actualización de la base y desplegar sudocu.
4- Verificamos los servicios:
sudocu_api-server
sudocu_cache
sudocu_gestion
sudocu_login
sudocu_mpc
sudocu_mpd
sudocu_pdf
los mismos quedaron en la versión 1.4.5
Pero el servicio de postgres_db-sudocu quedo en la versión 1.3.6, al igual que huarpe, usuarios y documentos quedaron en las versiones anteriores.
5- Para que el servicio postgres_db-sudocu quede en la versión 1.4.5, modificamos el postgres.yml colocando en image la versión 1.4.5.
6- Bajamos el stack de postgres
7- Desplegamos el stack de postgres.
8. Verificamos y el servicio postgres_db-sudocu se actualizo a la versión 1.4.5 … pero huarpe, usuarios y documentos siguen estando en las versiones anteriores 3.0.1 - 3.1.9 - 1.3.3, respectivamente.
A partir de estas pruebas realizadas, nos surge la siguiente consulta:
1- Entendimos que al actualizar sudocu, íbamos a estar actualizando todo el paquete: huarpe, usuarios, documentos y sudocu. Es decir que al correr el comando:
docker run --rm --env SUDOCU_DB_HOST=192.168.xxx.xx --env SUDOCU_DB_NAME=sudocu --env SUDOCU_DB_PORT=5432 --env SUDOCU_DB_USER=postgres --env SUDOCU_DB_PASSWORD=xxxxxx ungs/sudocu-db-instalador:1.4.5
Nos quedarían las versiones:
Sudocu – 1.4.5
Huarpe – 3.0.5
Usuarios – 3.1.13
Documentos – 1.3.5
¿Lo que entendemos es correcto?
Porque si es correcto, como podrán observar en las pruebas realizadas no solo tuvimos que hacer los pasos que se mencionan en la documentación, sino también que modificar los .yml correspondientes.
Por otro lado les comentamos que para actualizar huarpe, realizamos los mismos pasos, es decir bajamos el stack, editamos el huarpe.yml con la versión 3.0.5 y desplegamos el stack de huarpe y ahí verificamos que se actualiza el stack a la versión correspondiente.
Ahora, cuando intentamos hacer lo mismo con usuarios, siguiendo el mismo criterio de modificar usuarios.yml y el postgres.yml con la versión 3.1.13, por un lado se levantan los servicios de: usuarios_api, usuarios_idm y usuarios_idp con la versión 3.1.13, pero el servicio postgres_db-siu no lo levanta y ya no podemos ingresar a huarpe.unpa.edu.ar
Es por ello, que antes de continuar con las pruebas de actualización, necesitamos que nos indiquen si la forma de actualizar es la correcta.
Otra duda que tenemos es si existen otros .ymls que nos estén faltando editar, como por ejemplo el ldap.yml
Buenas tardes Mirta,
si en el changelog de la versión muestra que actualiza el servicio de huarpe, documentos, usuarios y sudocu, se debe volver a deployar cada uno de esos servicios para que los cambios tomen efecto, es decir se debe borrar el stack y desplegar el stack nuevamente para cada caso:
docker stack rm usuarios
docker stack rm docs
docker stack rm huarpe
docker stack deploy --with-registry-auth -c usuarios.yml usuarios
docker stack deploy --with-registry-auth -c docs.yml docs
docker stack deploy --with-registry-auth -c huarpe.yml huarpe
docker stack rm sudocu
docker run --rm --env SUDOCU_DB_HOST=192.168.xxx.xx --env SUDOCU_DB_NAME=sudocu --env SUDOCU_DB_PORT=5432 --env SUDOCU_DB_USER=postgres --env SUDOCU_DB_PASSWORD=xxxxxx ungs/sudocu-db-instalador:1.4.5
docker stack deploy --with-registry-auth --compose-file sudocu.yml sudocu
en el caso de sudocu es necesario ejecutar también el comando
docker run --rm --env SUDOCU_DB_HOST=192.168.xxx.xx --env SUDOCU_DB_NAME=sudocu --env SUDOCU_DB_PORT=5432 --env SUDOCU_DB_USER=postgres --env SUDOCU_DB_PASSWORD=xxxxxx ungs/sudocu-db-instalador:1.4.5
este comando migra la versión de la base de datos de sudocu a la versión que se indique en ungs/sudocu-db-instalador:1.x.y
(no actualiza a los demás servicios) si la base de sudocu se encuentra en una versión anterior 1.w.z migrará con las versiones intermedias hasta llegar a la versión 1.x.y
cuando sale una nueva versión de SEEI los pasos a seguir son:
Buenos dias, gracias por la respuesta sobre como proceder con la actualización de sucodu, usuarios, huarpe y documentos. Aqui nos surgen unas nuevas dudas antes de probar nuevamente:
1) Subir sus cambios al repositorio (como explica aquí https://expedientes.siu.edu.ar/docs/repo-config/#modificar-localmente). ¿Que se sube exactamente con estos comandos? Todo lo que se aloje dentro del directorio …/expediente? Es decir por ejemplo un archivo php.ini que es llamado desde un .yml tambien se subiria?
2) descargar los cambios de la nueva versión (https://expedientes.siu.edu.ar/docs/repo-config/#actualizar-versión). Esta descarga implica que se bajaria el directorio expedientes en la versión 1.4.5?
3) Una vez que ejecutamos el paso 2. Aqui deberiamos proceder a borrar y bajar los stacks nuevamente?
docker stack rm usuarios
docker stack rm docs
docker stack rm huarpe
docker stack deploy --with-registry-auth -c usuarios.yml usuarios
docker stack deploy --with-registry-auth -c docs.yml docs
docker stack deploy --with-registry-auth -c huarpe.yml huarpe
docker stack rm sudocu
docker run --rm --env SUDOCU_DB_HOST=192.168.xxx.xx --env SUDOCU_DB_NAME=sudocu --env SUDOCU_DB_PORT=5432 --env SUDOCU_DB_USER=postgres --env SUDOCU_DB_PASSWORD=xxxxxx ungs/sudocu-db-instalador:1.4.5
docker stack deploy --with-registry-auth --compose-file sudocu.yml sudocu
4) reparar los conflictos en los archivos que indica en la consola (aquí indica los cambios que trae la nueva versión, se deben editar los archivos y guardar)
5) desplegar nuevamente los servicios que hayan tenido cambios (por ejemplo si se modificó el usuarios.yml se debe borrar el stack de usuarios y volver a levantar)
Otra consulta que nos surge es, notamos que los servicios de postgres siguen en versiones anteriores, estos hay que borrarlos y desplegarlos de nuevo? O no necesariamente?
Desde ya muchas gracias!
Saludos
Paola Vidal
UNPA
Buenas tardes Paola,
sobre las consultas:
git status permite ver el estado actual del repositorio
git add . permite agregar cambios al index
git commit -m "comentario" guarda los cambios que están en el index
git push sube una copia de los cambios locales al repositorio remoto
Descarga los cambios realizados en el repositorio remoto incluyendo la última versión
git fetch upstream descarga el contenido del repositorio remoto
git merge upstream/master intenta fusionar los cambios de la nueva versión con tus cambios, es probable que aparezcan conflictos, si hay un conflicto aparece un mensaje como el siguiente:
“CONFLICT (content): Merge conflict in prod/arai/huarpe.yml
Auto-merging docs/docs/CHANGELOG.md
Automatic merge failed; fix conflicts and then commit the result.”
en este caso se debe entrar a editar el archivo huarpe.yml, por ejemplo se verá una o varias secciones como esta:
configuración de la nueva versión
upstream/master
en este paso lo que deben hacer es ajustar el contenido de esas secciones: mantener las líneas que necesiten conservar como por ejemplo la configuración propias de la institución.
respecto a la versión de postgres, cual versión tienen en ese ambiente, es un ambiente de pruebas?
Buenas tardes gracias por tu respuesta.
Primeramente te confirmo que si nos encontramos en un entorno de prueba donde se instalo Expedientes Integrado en las versiones:
Módulo Arai-usuarios v3.1.9
Módulo Arai-documentos v1.3.3
Módulo Huarpe v3.0.1
Módulo Sudocu v.1.3.6
La idea es realizar la actualización de Expedientes Integrado a la última versión liberada v1.5.12, que contiene las versiones:
Módulo Arai-usuarios v3.1.13
Módulo Arai-documentos v1.3.5
Módulo Huarpe v3.0.5
Módulo Sudocu v.1.4.5
Para ello finalmente seguimos los siguientes pasos:
1- Creamos un repositorio propio y subimos alli nuestras configuraciones.
2- Descargamos la ultima versión del repo del SIU siguiendo la documentación https://expedientes.siu.edu.ar/docs/repo-config/#actualizar-versión.
3- Resolvimos los conflictos.
4- Subimos los cambios a nuestro repositorio propio.
5- Bajamos y desplegamos los stacks:
a-
docker stack rm docs
docker stack deploy --with-registry-auth -c docs.yml docs
b-
docker stack rm huarpe
docker stack deploy --with-registry-auth -c huarpe.yml huarpe
c-
docker stack rm usuarios
docker stack deploy --with-registry-auth -c usuarios.yml usuarios
d-
docker stack rm sudocu
docker run --rm --env SUDOCU_DB_HOST=192.168.xxx.xx --env SUDOCU_DB_NAME=sudocu --env SUDOCU_DB_PORT=5432 --env SUDOCU_DB_USER=postgres --env SUDOCU_DB_PASSWORD=xxxxxx ungs/sudocu-db-instalador:1.4.5
docker stack deploy --with-registry-auth --compose-file sudocu.yml sudocu
e-
docker stack rm ldap
docker stack deploy --with-registry-auth -c ldap.yml ldap
6- Verificamos el estado de los servicios y probamos ingresar a Huarpe sin inconvenientes.
LA UNICA duda que nos surge es respecto a los servicios de postgres, porque notamos que quedaron como:
postgres_db-docs hub.siu.edu.ar:5005/siu/expedientes/arai-documentos/db:1.3.0
postgres_db-siu hub.siu.edu.ar:5005/siu/expedientes/arai-usuarios/db:v3.1.9
postgres_db-sudocu ungs/sudocu-db:1.3.4
Y no sabiamos si en realidad debieran quedar asi:
postgres_db-docs hub.siu.edu.ar:5005/siu/expedientes/arai-documentos/db:1.3.5
postgres_db-siu hub.siu.edu.ar:5005/siu/expedientes/arai-usuarios/db:v3.1.13
postgres_db-sudocu ungs/sudocu-db:1.4.5
O no necesariamente? Porque no bajamos ni desplegamos el stack de postgres en ningun momento.
Salvando esa duda creemos que con los pasos que nos indicaron pudimos realizar la actualizacion satisfactoriamente.
Muchas gracias por la ayuda!!!
Paola
UNPA
Buen día Paola, buenísimo que hayan podido avanzar. Parece ser que este caso es el que estamos tratando en el GDS 64748 sobre los repositorios remotos, es asi?
si tienen un stack de postgres sucede igual, si al actualizar se producen cambios en postgres.yml, también se debe bajar y subir el stack de postgres para que tome los cambios. Según veo en la última versión de expedientes, en postgres.yml se encuentran estas versiones:
services:
db-siu:
image: hub.siu.edu.ar:5005/siu/expedientes/arai-usuarios/db:v3.1.0
db-docs:
image: hub.siu.edu.ar:5005/siu/expedientes/arai-documentos/db:1.3.0
db-sudocu:
image: ungs/sudocu-db:1.4.5
Espero sus comentarios
Saludos!
Buen dia Maria,
Como estas? Primero gracias por tu pronta respuesta. Pudimos realizar satisfactoriamente la actualizacion de EEI en nuestro entorno de prueba.
Te confirmo que el GDS 64748 fue subido para realizar consultas respecto a los repositorios remotos.
Ya pudimos crear nuestro repositorio remoto propio, para mantener nuestras configuraciones y ademas seguir los pasos que nos indicaron en la documentación, para agregar el repositorio remoto del SIU como upstream y poder actualizar nuestra version de EEI.
Muchisimas gracias por la ayuda!
Saludos!
Paola
UNPA
Buen día Paola, cómo estás?
excelente! entonces damos por solucionado este posteo y cerramos la solicitud.
Por las dudas dejo aquí la solución enviada por GDS para configurar los repositorios remotos en el caso en que se esté trabajando en un ambiente que aún no tenga agregado dicho repositorio para sincronizar con la configuración local (si bien en este caso se trata de un ambiente de pruebas es útil para mantener los cambios realizados y poder revertirlo en caso de necesitarlo)
Primero para consultar los repositorios remotos configurados se puede ejecutar el comando:
git remote -v
si no tienen configurados los repositorios, pueden crear un repositorio propio para utilizarlo en ese ambiente y agregarlo mediante unos comandos para poder realizar la sincronización.
Por ejemplo crear un repositorio https://gitlab-uunn.edu.ar/ambiente-testeo
agregar como upstream el repositorio del SIU con el comando:
git remote add upstream https://hub.siu.edu.ar/siu/expedientes.git
agregar su repositorio remoto donde subirán sus cambios:
git remote set-url origin https://gitlab-uunn.edu.ar/ambiente-testeo.git
luego si consultan los repositorios deberían ver algo como:
git remote -v
origin https://gitlab-uunn.edu.ar/ambiente-testeo.git (fetch)
origin https://gitlab-uunn.edu.ar/ambiente-testeo.git (push)
upstream https://hub.siu.edu.ar/siu/expedientes.git (fetch)
upstream https://hub.siu.edu.ar/siu/expedientes.git (push)
Cualquier consulta estamos en contacto. Saludos!