Hinweise zum Umzug von Device Access auf das acc7-Cluster

Inhalt

Erweiterte Scripts und Makefiles

Folgende Scripts und Makefiles wurden für acc7 erweitert:

/common/usr/cscofe/scripts/eqpact
/common/usr/cscofe/scripts/asl/eqpaslv01
/common/usr/cscofe/scripts/asl/sysaslv01
/common/usr/cscofe/scripts/vme/prepmake
/common/usr/cscofe/scripts/vme/prepmakeeqms
/common/usr/cscofe/scripts/vme/eqpvmev10
/common/usr/cscofe/scripts/vme/sysvmev10
/common/usr/cscofe/scripts/vme/ecmlinkcreate
/common/usr/cscofe/scripts/vme/releqms
~/workspace/utilities/uti/Makefile
~/workspace/utilities/utiasl/Makefile
~/workspace/utilities/utivme/Makefile

Synchronisierte Produktions-Verzeichnisse

Die Struktur der Produktions-Verzeichnisse ist auf acc6 und acc7 die gleiche. Daher kann man, solange die Entwicklung noch auf acc6 stattfindet, nach Anpassung und Release obiger Scripts und Makefiles (auf acc6), die acc7-Verzeichnisse mit den acc6-Verzeichnissen synchronisieren.

ssh -X asl740.acc.gsi.de

cd /common/usr/cscofe
rsync -avz asl730:/common/usr/cscofe/bin .
rsync -avz asl730:/common/usr/cscofe/scripts .
rsync -avz asl730:/common/usr/cscofe/doc .
rsync -avz asl730:/common/usr/cscofe/opt .
rsync -avz asl730:/common/usr/cscofe/etc .
rsync -avz asl730:/common/usr/cscofe/var .
rsync -avz asl730:/common/usr/cscofe/htdocs .
rsync -avz asl730:/common/usr/cscofe/lib/java ./lib
rsync -avz asl730:/common/usr/cscofe/lib/python2.6/site-packages ./lib/python2.7
rsync -avz asl730:/common/usr/cscofe/opt/devacc/sys/m68k ./opt/devacc/sys

cd /common/usr/cscofe/opt/devacc
rsync -avz asl730:/common/usr/cscofe/opt/devacc/etc .
rsync -avz asl730:/common/usr/cscofe/opt/devacc/var .

Achtung! Das ist nur ein erster Schritt. Wurde Software direkt auf acc7 released, sollte man in der Regel danach kein rsync mehr machen!

Symbolische Links

Auf acc6 hatten wir Python 2.6, auf acc7 haben wir Python 2.7.

cd /common/usr/cscofe
ln -s lib/python2.7/site-packages python

cd /common/usr/cscofe/opt/devacc/eqp
ln -s /common/usr/cscofe/lib/python2.7/site-packages/eqmods eqmodpy

Java CORBA Interface

Java 11, das zur Zeit (Jan. 2019) auf acc7 eingeführt wird, unterstützt kein CORBA mehr. Die Gruppe SER (Vitaliy) testet gerade Glassfish als Ersatz. Erste Ergebnisse sehen gut aus. Nichtsdestotrotz muss perspektivisch eine generelle Lösung für den Device Access Communication Layer überlegt werden. CORBA stirbt langsam aus.

Python CORBA Stubs

Die müssen für acc7 explizit generiert werden. Importiert man das auf acc6 generierte Python-Modul devacc, dann bekommt man den Fehler

asl740$ python
>>> import devacc
...
ImportError: Stubs not compatible with omniORBpy version 4.2.

Im Nexus kann eine Version des Python-Artefakts also entweder für acc6 oder für acc7 gelten, aber nicht für beide! Also etwa

• framework-python 10.26.06 -> gilt nur für acc6
• framework-python 10.27.00 -> gilt nur für acc7

Die Generierung der Stubs geschieht, wenn man das Framework generiert. Das Modul ist .../framework/devacc_python.

assembly.xml

Für Releases der FEC-Software wird jeweils ein assembly.xml benötigt, welches die notwendigen allgemeinen Libraries wie omniORB und boost mit ins Zip packt. Da es auf acc6 und acc7 verschiedene ELDKs gibt, sind auch die Versionen dieser Libs unterschiedlich.

Für die Software-Generierung auf acc7 müssen die Versionen in den assembly.xml angepasst werden. Dazu auf einem acc7-Rechner (asl740) unter fecs/templates das Script show-libs.sh benutzten und libs-acc7.txt lesen.

Offene Fragen

• Versionierung:
  • Auf acc7 mit Framework-Version 10.27.00 weitermachen?
  • Wie dann eqmodels/eqdrivers entsprechend versionieren?
• Wie weiter mit 32Bit-SV-Programmen? => FE/SV
• 64Bit-Artefakte für FeDB-Zugriffe des Nameservers getrennt für acc6 und acc7 generieren und ins Nexus (csco nicht csco-snapshot) hochladen. Siehe dazu die jeweilige Oracle-Dependency in
  • ./framework/nameservice/server/x86_64/pom.xml und
  • ./framework/nameservice/server/fedbupdate/x86_64/pom.xml.
• M68k-Compilerbug auf acc7, wie weiter? Ist (vorläufig) erledigt!
  • Auf acc7 ist nun, wie auch auf acc6, m68k-elf-g++ (GCC) 4.3.3 installiert.
  • Zusätzlich wurde ein Problem des von ecmlinkcreate generierten Linkerscripts ecmlink.ld behoben.

Schlussfolgerung

Bedingt durch die neuere Umgebung (omniORB, Python, Oracle) und die notwendigen Änderungen in den POM-Dateien ist für die Generierung der Software kein gleitender Übergang zwischen acc6 und acc7 möglich.

Die komplette Software muss auf acc7 generiert werden. Ist diese released (Subversion, Nexus), ist der Rückweg nicht unmöglich, aber schwierig.

Eine Ausnahme könnte die SE-Software (ECM, EQMs) darstellen. Das ist aber noch zu verifizieren.