perfSONAR User Q&A and Other Discussion

[Andrew Lake <>]

Hi,

We don’t enjoy doing this type of thing either. We aren’t planning a change of this type at this magnitude again anytime soon. We knew it would annoy people but was a necessary evil in order to get our Debian and RedHat package inline with each other. Debian has stricter packaging guidelines which meant RedHat was conforming to those in most cases. We tried our best to minimize how annoying it would be and tried to keep the migration as transparent as possible to the average user. The average user shouldn’t have had to make any manual changes to have the update apply properly. That fact that it took almost 3 months for you to notice gives me some hope that at least that part of the process worked :) Obviously if you maintain your own documentation or run central configuration management software we couldn’t automatically modify that stuff for you, so you got the short-end of the stick. We have tried our best to be transparent about that fact. As with any change there is a cost and a benefit and we hope the long-term benefit will outweigh the short-term pain, but apologize for the inconvenience in the meantime. 

Thanks,

Andy

On May 23, 2016 at 1:14:39 PM, Brian Candler () wrote:

Hello,

I have just discovered that mesh_config binaries and configs have moved
and/or been renamed, e.g.
* /opt/perfsonar_ps/mesh_config/bin/build_json has become
/usr/lib/perfsonar/bin/build_json
* /opt/perfsonar_ps/mesh_config/etc/gui_agent_configuration.conf has
become /etc/perfsonar/meshconfig-guiagent.conf
* /opt/perfsonar_ps/mesh_config/bin/generate_gui_configuration has
become /usr/lib/perfsonar/bin/generate_gui_configuration
* ... and others

As a user, I'd just like to note that this is a real pain; it means that
internal documentation I've written about how to maintain the system has
become invalid, and requires me to dig around looking for the new
locations for things before I can make changes (and I have to update the
documentation as well)

Would it be possible to minimise this sort of change please? I really
want to leave auto-updates turned on, but this sort of
change-for-the-sake-of-it means there is an incentive to turn them off.

I wouldn't mind this for a major 3.x to 4.x transition (as long as there
was some overlap period), but wasn't expecting it to happen on a
"stable" 3.4 to 3.5.

Thanks,

Brian Candler.
________________________________
Brian Candler
Systems Architect
07974 231 451
________________________________

[CityFibre] [Follow CityFibre on Twitter] <http://www.twitter.com/CityFibre> [Follow CityFibre on LinkedIn] <http://www.linkedin.com/company/cityfibre> CityFibre,
15 Bedford Street,
London,
WC2E 9HE

0845 293 0774
Web: www.cityfibre.com<http://www.cityfibre.com>

Disclaimer
CityFibre Holdings Limited is incorporated in England (No. 07488363) and its registered office is 15 Bedford Street, London WC2E 9HE. This email, together with any attachments, is confidential and for use by the addressee(s) only. If you are not the intended recipient, please notify the sender immediately, delete the message from your system and do not copy, use, distribute or disclose the email, its contents or attachments for any purpose. CityFibre Holdings Ltd accepts no liability for damage caused to a recipient's system by this email nor for any unauthorised access to or interference with this email.