Problema executando oitava com openmpi em juju

Question

Eu estou tentando usar o openmpi de oitava para iniciar outras instâncias de oitava em máquinas remotas. Quando executo o script que deve iniciar os vários 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 diferem, mas sempre tendo

opal_shmem_base_select failed
...
ompi_mpi_init: orte_init failed

Eu 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 elas sejam carregadas quando ocorre o provisionamento, em vez da versão que o juju está usando atualmente. Eu sei que os pacotes são 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 age como seu próprio canal pass-through.

quaisquer ideias 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 eu configurei o juju, eu 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

Eu usei o mesmo mecanismo para os encantos de oitava e controlador de oitava. Quando eu olho para a unidade .... arquivos de log em / var / log / juju, em um dos nós, vejo muitos apts sendo carregados. Estes são armazenados em algum lugar, pois o nó não tem acesso à rede.

Alguns destes são carregados como resultado do carregamento de charme, então parece que tanto o MaaS quanto o juju estão cientes dos requisitos aptos para os encantos. Eu adicionei alguns pacotes de oitava no charme e na instalação, de modo que a oitava os instalasse e, de repente, houvesse aptos faltando. Estes aptos são obviamente requeridos pelo pacote da oitava (open-mpi era um, como se constata). Eu baixei, adicionei ao charme e instalei. Agora o pacote MPI carrega em oitava, mas dá o status que você vê acima.

    

Answer 1

Resposta curta: você está no controle; você pode fazer o que quiser no gancho install do charme. O padrão é usar o arquivo principal do Ubuntu com o squid-deb-proxy do MAAS atuando como um cache proxy; não há nenhum 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 como fornecido pelo MAAS, que armazena os pacotes em cache, mas nada mais. Por padrão, isso significa que o ambiente que seu hook de instalação de charme vê está configurado para usar o proxy squid-deb fornecido pelo MAAS para fazer download de pacotes, mas sources.list ainda aponta para o repositório principal do Ubuntu. Então seus pacotes estão vindo do repositório Ubuntu via MAAS como um cache de pacotes.

Para organizar o uso de um pacote personalizado, você deseja modificar seu charms install hook para usá-lo reconfigurando o apt primeiro. Por exemplo, você pode configurar um PPA com o pacote modificado e, em seguida, organizar o seu install hook para usá-lo.

Você pode ver um exemplo genérico disso na implementação da opção de configuração source charme em gancho alterado de configuração do charme do mariadb . No caso de um encanto personalizado que você não precisa ser genérico, basta adicionar uma linha como:

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

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

Se você quiser desconectar a máquina MAAS do acesso à Internet, 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 em favor de archive.ubuntu.com (supondo que você espelhou-o), ou então providencie para que seus ganchos de instalação configurem o apt para usá-lo.