perfSONAR User Q&A and Other Discussion

[Mark Feit <>]

Mike Robbert writes:

 

… plpythonu … is a procedural language extension that is configured to get loaded from the backup file that came from CentOS 7. Since that extension isn’t available in EL 8 or 9 it appears that an import from that backup file will always fail on the new OS. The backup file also included plpython3u which is the new version, so I commented out the old version and manually imported my database.

 

Plpythonu  became unused in the 4.3.0 release (November, 2020) when we migrated from Python 2 to Python 3.  (EL7 supported both; EL8 dropped Python 2.)  The code that maintains the database between releases purged that module starting in 4.3.0 and still does to this day as a safety measure.  Your system has clearly been through at least one upgrade that should have removed it because plpython3u is present in your backup.  I’m curious about why yours still has is but I’d need the old system still intact to find out.

 

Unfortunately, after doing that I still have none of my previously configured tests in the dashboard and therefore no old graph data.

Am I misunderstanding what the migrate scripts are supposed to do, or did I miss something when I manually imported the database?

 

The database you imported was for pScheduler, which is one slice of a larger pie.  If that failed during the overall perfSONAR restore process, the restore would have stopped there and not reached MaDDash and pSConfig, which are what’s missing.

 

The quick, dirty, not-officially-supported way to get the remainder of the backup restored would be to grab a copy of the restore script (/usr/lib/perfsonar/scripts/ps-migrate-restore.sh), remove the section that does the pScheduler restore (lines 102-138) from the copy and run it again against the backup file.  Then pretend I never told you any of this.  :-)

 

--Mark