perfSONAR User Q&A and Other Discussion

[Mike Robbert <>]

Mark,

Thanks for your reply. I did forget to pop all the way back up the stack after going in deep yesterday. I did as you suggested and that didn’t change anything. It looks like there are only 2 commands that were missed and we’re not running MadDash so it really only ran one of them and that is documented in the script as being for a 4.0 to 4.1 migration. Looking closer at things I don’t see where these scripts even work with the logstash/opensearch data.

Since they aren’t documented on the website I’m wondering if these scripts aren’t even production ready for the current release. If not let me know and I’ll drop the whole issue and we’ll grab screenshots of our current data and start from scratch on the new OS. If this is supposed to work then I would like to see if I can still resurrect the data from the host that I already tried to migrate, but even if we can’t I’d like to figure out what when wrong so we can get it correct on the other host we have. To that end I did look at our host that is still running CentOS 7 and it does have the package providing plpythonu (postgresql10-plpython-10.17-1PGDG.el7.x86_64) and if I try to remove it the dependency resolution tries to remove most of my perfsonar packages. That package is required by postgresql-init which is required by pscheduler-server.

 

Mike Robbert

Cyberinfrastructure Specialist, Cyberinfrastructure and Advanced Research Computing

Information and Technology Solutions (ITS)

303-273-3786 |   

 

On 5/15/24, 11:51, "Mark Feit" <> wrote:

 

CAUTION: This email originated from outside of the Colorado School of Mines organization. Do not click on links or open attachments unless you recognize the sender and know the content is safe.

 

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

 

 

Attachment: smime.p7s
Description: S/MIME cryptographic signature