Problema ao executar oitava com openmpi em juju

Problema ao executar oitava com openmpi em juju

Estou tentando usar o openmpi da oitava para iniciar outras instâncias da oitava em máquinas remotas. Quando executo o script que deve iniciar os diversos processos, ele reclama que as bibliotecas estão desatualizadas:

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

Continua isto para os vários processos, algumas das bibliotecas diferentes, mas sempre tendo

opal_shmem_base_select failed
...
ompi_mpi_init: orte_init failed

Tenho visto comentários que dizem alterar os sinalizadores de compilação no openmpi e recompilar.

Um problema é que estou usando um repositório juju local para provisionar as máquinas e não consigo descobrir onde colocar as bibliotecas para que sejam carregadas quando o provisionamento ocorrer, em vez da versão que o juju está usando atualmente. Eu sei que os pacotes ficam armazenados em algum lugar. Não tenho certeza se eles estão na máquina de estado juju, no servidor juju ou se o juju atua como seu próprio canal de passagem do apt-get.

quaisquer idéias apreciadas.

Adicionado 2015.04.28 1723PST-em resposta a Robie Basak------------------------------------------------------ ------------

Obrigado pela recompensa, Jorge Castro

Meu cluster não está conectado à rede. O controlador MaaS está conectado por enquanto, mas será desconectado no futuro. Quando configurei o juju, usei um repositório local, como em

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

Usei o mesmo mecanismo para os botões de oitava e controlador de oitava. Quando olho para os arquivos unit....log em/var/log/juju, em um dos nós, vejo muitos apts sendo carregados. Eles são armazenados em algum lugar, pois o nó não tem acesso à rede.

Alguns deles são carregados como resultado do carregamento do charme, então parece que o MaaS ou o juju estão cientes dos requisitos adequados para os encantos. Eu adicionei alguns pacotes de oitava no charme e na instalação, de modo que a oitava os instalou e, de repente, faltam apts necessários. Esses apts são obviamente exigidos pelo pacote octave (open-mpi era um deles, como se constatou). Baixei, adicionei ao charm e instalei. Agora o pacote MPI carrega em oitava, mas fornece o status que você vê acima.

Responder1

Resposta curta: você está no controle; você pode fazer o que quiser no installgancho do amuleto. O padrão é usar o arquivo principal do Ubuntu com o squid-deb-proxy do MAAS atuando como um cache proxy; não há espelho ou repositório separado ativo.

O controlador MaaS está conectado por enquanto, mas será desconectado no futuro.

Acho que você está usando o squid-deb-proxy fornecido pelo MAAS, que armazena pacotes em cache, mas nada mais. Por padrão, isso significa que o ambiente que seu gancho de instalação charm vê está configurado para usar o squid-deb-proxy fornecido pelo MAAS para baixar pacotes, mas sources.listainda apontando para o arquivo principal do Ubuntu. Portanto, seus pacotes vêm do arquivo Ubuntu via MAAS como um cache de pacotes.

Para organizar o uso de um pacote personalizado, você deseja modificar seu installgancho de charms para usá-lo reconfigurando o apt primeiro. Por exemplo, você pode configurar um PPA com seu pacote modificado e então providenciar para que seu installgancho o use.

Você pode ver um exemplo genérico disso na implementação da sourceopção de configuração charm emGancho de configuração alterada do mariadb charm. No caso de um pingente personalizado que não precisa ser genérico, basta adicionar uma linha como:

 sudo add-apt-repository -y ppa:username/octave

antes de instalar o pacote em seu installgancho, ou um equivalente adequado se seu charme estiver escrito em um idioma diferente.

Se você deseja desconectar a máquina MAAS do acesso à Internet, então você precisará implementar seu próprio repositório apt local e então organizar o squid-deb-proxy na máquina MAAS para usá-lo a favor archive.ubuntu.com(assumindo que você o tenha espelhado), ou caso contrário, organize seus ganchos de instalação para configurá-los para usá-los.

informação relacionada