three VOMS servers for each VO supported by UK VOMS servers

[CatalinCondurache]

There are currently three VOMS servers (voms.gridpp.ac.uk, voms02.gridpp.rl.ac.uk, voms03.gridpp.rl.ac.uk) used by various VOs supported by the UK VOMS service.

Only one VO (t2k.org) is correctly and fully configured within the template-library-grid/vo/params/t2k.org.pan template, the rest of them (babar, camont, comet.j-parc.jp, gridpp, mice, minos.vo.gridpp.ac.uk, na62.vo.gridpp.ac.uk, neurogrid.incf.org, ngs.ac.uk, pheno, snoplus.snolab.ca, supernemo.vo.eu-egee.org, vo.helio-vo.eu, vo.landslides.mossaic.org, vo.londongrid.ac.uk, vo.northgrid.ac.uk, vo.southgrid.ac.uk) are using only voms.gridpp.rl.ac.uk VOMS server.

This need to be corrected in order to improve the service resilience (there are situations when voms.gridpp.ac.uk server doesn't serve requests properly)

Thanks,
Catalin

[Pansanel]

Hi Catalin,
The templates are generated by the external/ant/bin/ant vo.update.config command, therefore they are not actively maintained on the trunk.
If, after running the above command, the VOMS are not correctly configured, then it means that the VO ID card is not correctly filled on the operation portal.
Cheers,
Jerome

[CatalinCondurache]

Hi Jerome,

Not sure if I understand (or agree with you).
Have a look at https://operations-portal.egi.eu/vo/view/voname/snoplus.snolab.ca
All three UK voms servers are listed there, however the snoplus.snolab.ca.pan file contains only one.

Then have a look at https://operations-portal.egi.eu/vo/view/voname/t2k.org
Also all three UK voms servers are listed there, but this time the t2k.org.pan file includes all of them.

Something is missing here.

Regards,
Catalin

[jrha]

If we don't expect the templates in master to be valid then we shouldn't distribute them there, we should make this clear in the documentation.
Alternatively we should regularly run vo.update.config and push the results to this repo.

[ned21]

@jouvin @guillaume-philippon Any thoughts on this one?

[Pansanel]

@jrha : we can have a set of default templates, but we should make clear in the documentation to run the vo.update.config command to be sure to have an updated version of the files.

[jrha]

@Pansanel the problem for us is that the vo.update.config command is an SCDB ant task and is not present with Aquilon.

[jrha]

Also see quattor/scdb-ant-utils#19

[jouvin]

As discussed at the Gent workshop, updating the VO templates in the template library is difficult as the upgrade is not necessarily backward compatible (it can change the group/role pool account mapping if the VO removes some group/role or add them in the middle of the list). The proposal is to remove them from the template library and document how to use VOConfig to generate them as site templates, maintained by the site.

[Pansanel]

It is probably the best way. It will also prevent to have up to several copies of VOMS configurations an be sure that all are synchronized.

[CatalinCondurache]

And I won’t be surprised if many sites are already maintaining their templates with their own supported VOs Catalin

[Pansanel]

@jouvin : I will start to write a voms-tools to get data from the ops portal and generate the site templates. Should I create a new project within Quattor (named voms-tools) or use an already existing project?

[jrha]

As discussed, open a PR against the newly renamed "tools" repository.

[jouvin]

@Pansanel thanks! Tools repo (formerly aquilon-tools despite is was intended for Aquilon and SCDB tools) is probably the most appropriate one.