Ich versuche, OpenMPI von Octave aus zu verwenden, um andere Octave-Instanzen auf Remote-Rechnern zu starten. Wenn ich das Skript ausführe, das die verschiedenen Prozesse starten soll, beschwert es sich über veraltete Bibliotheken:
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
Dies wird für die verschiedenen Prozesse fortgesetzt, wobei sich einige der Bibliotheken unterscheiden, aber immer
opal_shmem_base_select failed
...
ompi_mpi_init: orte_init failed
Ich habe Kommentare gesehen, in denen stand, man solle die Kompilierflags bei OpenMPI ändern und neu kompilieren.
Ein Problem besteht darin, dass ich ein lokales Juju-Repository zur Bereitstellung der Maschinen verwende und nicht herausfinden kann, wo ich die Bibliotheken ablegen soll, damit sie beim Bereitstellen geladen werden und nicht die Version, die Juju derzeit verwendet. Ich weiß, dass die Pakete irgendwo gespeichert werden. Ich bin mir nicht sicher, ob sie sich auf der Juju-Statusmaschine, auf dem Juju-Server oder ob Juju als eigener Apt-Get-Passthrough-Kanal fungiert.
alle Ideen sind willkommen.
Hinzugefügt am 28.04.2015 1723PST – als Antwort auf Robie Basak---------------------------------------------------
Vielen Dank für die Prämie, Jorge Castro
Mein Cluster ist nicht mit dem Netz verbunden. Der MaaS-Controller ist derzeit verbunden, wird aber in Zukunft getrennt. Als ich juju eingerichtet habe, habe ich ein lokales Repository verwendet, wie in
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
Ich habe denselben Mechanismus für die Octave- und Octave-Controller-Charms verwendet. Wenn ich mir die Einheit ansehe....log-Dateien in /var/log/juju, auf einem der Knoten, sehe ich, dass viele Apts geladen werden. Diese werden irgendwo gespeichert, da der Knoten keinen Zugriff auf das Netz hat.
Einige davon werden als Ergebnis des Ladens des Charms geladen, daher scheint es, dass entweder MaaS oder Juju die Apt-Anforderungen für die Charms kennen. Ich habe einige Octave-Pakete zum Charm und zur Installation hinzugefügt, sodass Octave sie installiert hat, und plötzlich fehlen erforderliche Apts. Diese Apts werden offensichtlich vom Octave-Paket benötigt (open-mpi war eines davon, wie sich herausstellte). Ich habe es heruntergeladen, zum Charm hinzugefügt und installiert. Jetzt wird das MPI-Paket in Octave geladen, zeigt aber den Status an, den Sie oben sehen.
Antwort1
Kurze Antwort: Sie haben die Kontrolle; Sie können im installHook des Charms tun, was Sie möchten. Standardmäßig wird das Hauptarchiv von Ubuntu verwendet, wobei MAAS‘ squid-deb-proxy als Proxy-Cache fungiert; es ist kein separater Spiegel oder Repository aktiv.
Der MaaS-Controller ist derzeit verbunden, wird aber in Zukunft getrennt.
Ich glaube, Sie verwenden den von MAAS bereitgestellten Squid-Deb-Proxy, der Pakete zwischenspeichert, aber sonst nichts. Standardmäßig bedeutet dies, dass die Umgebung, die Ihr Charm-Installations-Hook sieht, so konfiguriert ist, dass sie den von MAAS bereitgestellten Squid-Deb-Proxy zum Herunterladen von Paketen verwendet, aber sources.listdennoch auf das Hauptarchiv von Ubuntu verweist. Ihre Pakete kommen also über MAAS als Paket-Cache aus dem Ubuntu-Archiv.
Um stattdessen ein benutzerdefiniertes Paket zu verwenden, müssen Sie Ihren Charms- installHook so ändern, dass er es verwendet, indem Sie zuerst Apt neu konfigurieren. Sie können beispielsweise ein PPA mit Ihrem geänderten Paket einrichten und dann Ihren installHook so einrichten, dass er es verwendet.
Ein allgemeines Beispiel hierfür finden Sie in der Implementierung der sourceCharm-Konfigurationsoption inKonfigurationsänderungs-Hook des MariaDB-Charms. Im Falle eines benutzerdefinierten Charms, der nicht generisch sein muss, können Sie einfach eine Zeile wie die folgende hinzufügen:
sudo add-apt-repository -y ppa:username/octave
bevor Sie das Paket in Ihrem installHook installieren, oder ein geeignetes Äquivalent, wenn Ihr Charm in einer anderen Sprache geschrieben ist.
Wenn Sie den MAAS-Rechner vom Internetzugriff trennen möchten, müssen Sie Ihr eigenes lokales Apt-Repository implementieren und dann entweder Squid-Deb-Proxy auf dem MAAS-Rechner so einrichten, dass es stattdessen verwendet wird archive.ubuntu.com(vorausgesetzt, Sie haben es gespiegelt), oder anderweitig dafür sorgen, dass Ihre Installations-Hooks Apt für die Verwendung konfigurieren.