Estoy intentando usar openmpi desde octava para iniciar otras instancias de octava en máquinas remotas. Cuando ejecuto el script que debería iniciar los distintos procesos, se queja de que las bibliotecas están desactualizadas:
Running octave in parallel on /opt/data/octave/test using 24 processors
[pleasant-increase:13959] Warning: could not find environment variable "LD_PRELOAD"
[octave-controller:15259] mca: base: component_find: unable to open /usr/lib/openmpi/lib/openmpi/mca_paffinity_hwloc: perhaps a missing symbol, or compiled for a different ver$
[octave-controller:15259] mca: base: component_find: unable to open /usr/lib/openmpi/lib/openmpi/mca_carto_auto_detect: perhaps a missing symbol, or compiled for a different v$
[octave-controller:15259] mca: base: component_find: unable to open /usr/lib/openmpi/lib/openmpi/mca_carto_file: perhaps a missing symbol, or compiled for a different version $
[octave-controller:15259] mca: base: component_find: unable to open /usr/lib/openmpi/lib/openmpi/mca_shmem_mmap: perhaps a missing symbol, or compiled for a different version $
[octave-controller:15259] mca: base: component_find: unable to open /usr/lib/openmpi/lib/openmpi/mca_shmem_posix: perhaps a missing symbol, or compiled for a different version$
[octave-controller:15259] mca: base: component_find: unable to open /usr/lib/openmpi/lib/openmpi/mca_shmem_sysv: perhaps a missing symbol, or compiled for a different version $
--------------------------------------------------------------------------
It looks like opal_init failed for some reason; your parallel process is
likely to abort. There are many reasons that a parallel process can
fail during opal_init; some of which are due to configuration or
environment problems. This failure appears to be an internal failure;
here's some additional information (which may only be relevant to an
Open MPI developer):
opal_shmem_base_select failed
--> Returned value -1 instead of OPAL_SUCCESS
--------------------------------------------------------------------------
[octave-controller:15259] [[INVALID],INVALID] ORTE_ERROR_LOG: Error in file runtime/orte_init.c at line 79
--------------------------------------------------------------------------
It looks like MPI_INIT failed for some reason; your parallel process is
likely to abort. There are many reasons that a parallel process can
fail during MPI_INIT; some of which are due to configuration or environment
problems. This failure appears to be an internal failure; here's some
additional information (which may only be relevant to an Open MPI
developer):
ompi_mpi_init: orte_init failed
--> Returned "Error" (-1) instead of "Success" (0)
--------------------------------------------------------------------------
*** An error occurred in MPI_Init
*** on a NULL communicator
*** MPI_ERRORS_ARE_FATAL: your MPI job will now abort
Continúa esto para los diversos procesos, algunas de las bibliotecas difieren, pero siempre tienen
opal_shmem_base_select failed
...
ompi_mpi_init: orte_init failed
He visto comentarios que dicen cambiar los indicadores de compilación en openmpi y volver a compilar.
Un problema es que estoy usando un repositorio local de juju para aprovisionar las máquinas y no puedo saber dónde colocar las bibliotecas para que se carguen cuando se produzca el aprovisionamiento, en lugar de la versión que juju está usando actualmente. Sé que los packahes se almacenan en alguna parte. No estoy seguro de si están en la máquina de estado de juju, en el servidor de juju o si juju actúa como su propio canal de paso apt-get.
Se agradece cualquier idea.
Agregado el 28/04/2015 a las 1723PST en respuesta a Robie Basak----------------------------------------------- ------------
Gracias por la recompensa, Jorge Castro.
Mi clúster no está conectado a la red. El controlador MaaS está conectado por ahora, pero se desconectará en el futuro. Cuando configuré juju, utilicé un repositorio local, como en
juju sync-tools -e maas --local-dir="~/.juju/sync-tools"
juju bootstrap -e mass --debug --upload-tools=true --metadata-source="~/.juju/sync-tools" --to jujuBS.maas
juju deploy --repository=".juju/charms" local:juju-gui --to 0
juju expose juju-gui
Utilicé el mismo mecanismo para los amuletos de octava y controlador de octava. Cuando miro los archivos de registro de la unidad en /var/log/juju, en uno de los nodos, veo que se cargan muchos aptos. Estos se almacenan en algún lugar, ya que el nodo no tiene acceso a la red.
Algunos de estos se cargan como resultado de la carga de accesos, por lo que parece que MaaS o juju conocen los requisitos adecuados para los accesos. Agregué algunos paquetes de octava al acceso y a la instalación, de modo que octava los instaló y, de repente, faltan apts requeridos. Estos apts obviamente son requeridos por el paquete octave (resulta que open-mpi era uno). Lo descargué, lo agregué al charm y lo instalé. Ahora el paquete MPI se carga en octava, pero muestra el estado que ve arriba.
Respuesta1
Respuesta corta: tú tienes el control; puedes hacer lo que quieras en el installgancho del amuleto. El valor predeterminado es utilizar el archivo principal de Ubuntu con el squid-deb-proxy de MAAS actuando como caché de proxy; no hay ningún espejo o repositorio separado activo.
El controlador MaaS está conectado por ahora, pero se desconectará en el futuro.
Creo que estás usando squid-deb-proxy proporcionado por MAAS, que almacena en caché los paquetes pero nada más. De forma predeterminada, esto significa que el entorno que ve su gancho de instalación de Charm está configurado para usar el squid-deb-proxy proporcionado por MAAS para descargar paquetes, pero sources.listaún apunta al archivo principal de Ubuntu. Entonces sus paquetes provienen del archivo de Ubuntu a través de MAAS como caché de paquetes.
Para organizar el uso de un paquete personalizado, desea modificar su installgancho de accesos para usarlo reconfigurando apt primero. Por ejemplo, podría configurar un PPA con su paquete modificado y luego hacer arreglos para que su installgancho lo use.
Puedes ver un ejemplo genérico de esto en la implementación de la sourceopción de configuración de acceso enGancho modificado en la configuración de mariadb charm. En el caso de un acceso personalizado que no necesita que sea genérico, simplemente puede agregar una línea como:
sudo add-apt-repository -y ppa:username/octave
antes de instalar el paquete en su installgancho, o un equivalente adecuado si su encanto está escrito en un idioma diferente.
Si desea desconectar la máquina MAAS del acceso a Internet, deberá implementar su propio repositorio apt local y luego organizar squid-deb-proxy en la máquina MAAS para usarlo a favor archive.ubuntu.com(suponiendo que lo haya duplicado), o de lo contrario, haga arreglos para que sus ganchos de instalación se configuren de manera adecuada para usarlo.