Enhance VO mapping via project properties

[tdviet]

Initial checklist

• [X] I read the support docs
• [X] I read the contributing guide
• [X] I agree to follow the code of conduct
• [X] I searched issues and couldn’t find anything (or linked relevant results below)

Problem

Fedcloudclient relies on site configuration files from fedcloud-catchall-operations for mapping local Openstack tenants to VOs. This is cumbersome and difficult to maintain, it must rely on sources from external projects.

Solution

There is ongoing discussion in EGI FedCloud, initiated by Alvaro Lopez, for adding VOs as properties of Openstack tenants. Fedcloudclient should use the properties to VO mapping instead of site configuration files.

Alternatives

A combined approach (site configuration files and auto discovery) could be used

[enolfc]

See also https://github.com/IFCA/caso/issues/109

[alvarolopez]

Should we align on the property naming? Is VO enough for the property? Shall we use a namespace like EGI:VO

[tdviet]

During the last fedcloud meeting, some sites report that they use caso for accounting non-EGI projects.

If we want to have prefix, I would propose FEDCLOUD:VO, that is little more generic

[enolfc]

I feel adding prefixes removes any potential generic part of it. So if the issue is that local VOs are not so easily attributable to EGI and that's a bad prefix, then FEDCLOUD is equally misleading (i.e. local vs federation).

I would add a prefix only if there is a risk of clashes, if VO is something that has no meanings outside of this world, I would go for it.

[alvarolopez]

I am fine with both, should we go with VO then?

[tdviet]

OK for me