frontend SRR directly uses info-provider.* option and apparently the wrong one

[calestyo]

Hey.

On 7.2.10.

It seems that the SRR output from the REST interface uses info-provider.se-unique-id in order to determine is storageservice/id field.

1. Wasn't it always the general policy that each service uses only options from either dcache.* or it's own service.* namespace? If there are services which do not obey this, then changing any options is like lottery and one never knows what other services break or have behaviour changed, if on changes a seemingly unrelated option.

2. Even there, it seems to use the wrong option. According to info-provider.properties:

#   The following section has configuration that directly affects the
#   output from the info-provider.  Some properties affect only the
#   GLUE v1.3 output, others only affect the GLUE 2.0 output and the
#   remaining affect both.  The affected versions of GLUE are
#   indicated in square brackets.
#
#   GlueSiteUniqueID [1.3, 2.0] a unique reference for your site.
#   This must match the GlueSiteUniqueID defined in other services.
#
#   The default value is not valid, so this property must be
#   configured.
#
info-provider.site-unique-id=EXAMPLESITE-ID

#   GlueSEUniqueID [1.3, 2.0] your dCache's Unique ID.  Currently,
#   this MUST be the FQDN of your SRM end-point.
#
#   The default value is not valid, so this property must be
#   configured.
#
info-provider.se-unique-id=dcache-srm.example.org

And that's also what GLUE data really seems to expect (i.e. se-unique-id = domainname).

However, info-provider.se-unique-id and not info-provider.site-unique-id seems to be used for generating the JSON. At least, ugly workarounding this issue by setting the former per domain, as in:

[frontend]
info-provider.se-unique-id=LRZ-LMU
[frontend/frontend]
frontend.net.listen=localhost
frontend.authn.protocol=http
frontend.authz.anonymous-operations=READONLY
frontend.authz.unlimited-operation-visibility=true

seems to let it use the right ID.

Chris.