opensciencegrid / topology Goto Github PK

The Neurodesk stratum 0 has a DNS alias (reported in cvmfs-contrib/config-repo#242 (comment)) that should be used in place of the IP address in topology.

@efajardo @matyasselmeci

The hosted-ce34.grid.uchicago.edu is showing up in GRACC, a lot. But, it's listed as non-production in the topology, and therefore doesn't show up in the topology listing. Can we change this to production so the usage can be mapped?

(I accidentally first made this with no description)

I see a few topology/*/*/*erf*.yaml files that have names which have nothing to do with the site name. Sometimes those resource group names are just generically named with perfsonar in them:

topology/CBPF/GridLAFEX/PerfSONAR Services.yaml
topology/National Energy Research Scientific Computing Center/NERSC/Perfsonar Services.yaml
topology/Universidade de Sao Paulo/SAMPA/perfSONAR Services.yaml

Those should be renamed to have the facility name in there somehow.

This resource is missing from topology. I'm guessing KSU-Beocat-CE1 is a replacement for BEOCAT-SLATE?
https://github.com/opensciencegrid/topology/blob/master/topology/Kansas%20State%20University/Beocat/BEOCAT-SLATE.yaml

Looking here: https://github.com/opensciencegrid/topology/blob/master/virtual-organizations/CMS.yaml

Some thoughts:

1. Remove redundant contact entries on conversion.
2. Remove the contact IDs. We only need the IDs for cases where we can filter via the web.
3. Remove information (such as the list of resources) that can be calculated in other places. Since the resource YAML will include the membership info, we don't also need it here too.
4. Remove defaults entries.

This should drastically simplify the VO entries.

We currently have a list of service IDs in one of the YAML files:

https://github.com/opensciencegrid/topology/blob/master/topology/services.yaml

However, this is also duplicated here:

https://github.com/opensciencegrid/topology/blob/master/src/topology_utils.py#L112

We should consolidate it down to a single list of IDs.

I have these suggestions to osg-notify. I sent them to @bbockelm by slack but I don't know if he noticed.

1. I don't think that --recipients should be required if --oim-recipients is given
2. I think --oim-recipients should have an option to do both resources and vos, not just either
3. I think it would be helpful for the command to give a little feedback to the user upon success, such as the number of recipients that were sent the message.

There are many records that do not have a FieldOfScience field due to the lack of a cms project in topology.

@bbockelm asked me to create it, but I am not familiar with cms to input the correct values for a new project file.

warning: the following paths have collided (e.g. case-sensitive paths
on a case-insensitive filesystem) and only one from the same
colliding group is in the working tree:

'projects/XENON.yaml'
'projects/xenon.yaml'

To improve usability for our end-users, we should move all the sources under a src/ dir so that we have the following structure

projects/
src/
topology/
.gitignore
.travis.yml
virtual-organizations/
README.md
template-*.yaml

The filtering in MyOSG for OASIS attributes for VO queries is not replicated to the current VO responses.

We should implement this for OASIS attributes and the active attributes (if we don't already). I see we can additionally filter on support center ... it's not clear if that's necessary.

The following things are now hosted at University of Nebraska-Omaha:

• topology server
• osg-display
• software repos

@djw8605 , anything else?

We should create entries for them. Use the new "Topology Server" service type for the topology server; the other services already have service type entries.

The LIGO VO topology includes the https://scitokens.org/ligo token issuer. AFAIK we are transitioning to https://scitokens.org/igwn, which will include some new scopes etc for internal use.

Can we update the LIGO VO topology file to reference that issuer? I am listed as a VO Manager, so should I be the one to propose a Pull Request that implements that?

cc @josh-willis @rdt12 @jjg-123

At the very least, we should be able to get rid of the Gratia resources here:

https://github.com/opensciencegrid/topology/blob/master/topology/Fermi%20National%20Accelerator%20Laboratory/FermiGrid/GRATIA-OSG.yaml

There are quite a few resources associated with the GOC that should be either removed entirely if they won't have an effect on GRACC accounting (cc @djw8605 ) or deactivated and disabled.