Create symbolic links in deploy-wmagent

[todor-ivanov]

Fixes #9805

Status

ready

Description

In order to be able to test different combinations of rpm packages and dependencies, we need to have the ability to build and upload them in our personal repositories in cmsrep [1]. While deploying from such a repository (adding the option -r comp=comp.<user> to the deployment script) the deployment area changes from /data/srv/wmagent/current/sw to /data/srv/wmagent/current/sw.`, this needs to be properly reflected in the set of symbolic links we create during the installation process.

Another change that this PR introduces is a symbolic link fixing the different path to the manage script embedded in the $manage variable when it comes to deployment of the wmagentpy3 package (adding the option --py3 to the deployment script)

[1]
http://cmsrep.cern.ch/cgi-bin/repos/comp.tivanov/slc7_amd64_gcc630

Is it backward compatible (if not, which system it affects?)

YES

Related PRs

<If it's a follow up work; or porting a fix from a different branch, please mention them here.>

External dependencies / deployment changes

<Does it require deployment changes? Does it rely on third-party libraries?>

[cmsdmwmbot]

Jenkins results:

• Unit tests: succeeded
• Pylint check: succeeded
• Pylint py3k check: succeeded
  • 0 errors and warnings that should be fixed
  • 0 warnings
  • 0 comments to review
• Pycodestyle check: succeeded
• Python3 compatibility checks: succeeded
  • there are suggested fixes for newer python3 idioms

Details at https://cmssdt.cern.ch/dmwm-jenkins/view/All/job/DMWM-WMCore-PR-test/11628/artifact/artifacts/PullRequestReport.html

[amaltaro]

Thanks for providing this patch, Todor.

However, I wonder if we really need the symlink for sw? Is it related to the init.sh script which adds libraries to the environment? That setup.sh/init.sh works fine for python2-based specs, so I would expect it to be the same for python3 as well.

[todor-ivanov]

Hi @amaltaro,
Yes, one of the places where this link is needed is exactly the sourcing of init.sh, but it is not related to the python3 migration only. This is something which is related to the fact that whenever you deploy from your personal repository (e.g. comp.amaltaro) the deployment area directory name suddenly changes from sw to sw.amaltaro regardless of the python version. So anything which relates to sw does not work equally bad in both python2 and python3.

[amaltaro]

It has always been like this. In other words, there is nothing that needs to be fixed IMO (if you saw anything breaking, then please provide further details). It's just a matter of explicitly demonstrating from where your software has been deployed from.

[todor-ivanov]

Thanks for your comment @amaltaro

It's just a matter of explicitly demonstrating from where your software has been deployed from.

No one questions the reason behind this naming convention. It is simply that the rest of the environment we run the service in is not compatible with this. And the link is the way to fix this.

I did not preserve the logs, but IIRC even the deployment process of a MySQL based agent was having troubles to complete, without applying this patch to the deployment script.

[todor-ivanov]

Hi @amaltaro I just pushed the shortest possible fix tho this softlink creation as we discussed yesterday, which should make this point to the right deployment even for deployments from private repositories. Would you take a look please?

[cmsdmwmbot]

Jenkins results:

• Unit tests: succeeded
• Pylint check: succeeded
• Pylint py3k check: succeeded
  • 0 errors and warnings that should be fixed
  • 0 warnings
  • 0 comments to review
• Pycodestyle check: succeeded
• Python3 compatibility checks: succeeded
  • there are suggested fixes for newer python3 idioms

Details at https://cmssdt.cern.ch/dmwm-jenkins/view/All/job/DMWM-WMCore-PR-test/11640/artifact/artifacts/PullRequestReport.html

[amaltaro]

Thanks Todor, it looks pretty good now!