Long term sustainability of VESPA will be supported on the data service side by a set of VESPA hubs: structures that host service definition, maintain them, and possibly substitute to the original provider in case of problem. This will help workaround difficulties ranging from IT policy in provider institutes to evolving requirements on VESPA side and lack of maintenance by the original provider.
Three such hubs are scheduled: Paris Observatory (PADC), Trieste Observatory (OATS), and Heidelberg University.

The exact infrastructure is being assessed and optimized on first test services (as of March 2021):

• A common gitlab facility is installed in ObsParis, reserved for VO activities (currently only from Europlanet): https://voparis-gitlab.obspm.fr/vespa
This gitlab is accessible through authentication via GÉANT, i.e. users are asked to register once in the VESPA-Cloud Virtual Organization at eduTEAMS (with authorizations based on VESPA-cloud groups).
The data tree distinguishes service files and servers configurations, and groups services by provider institute then data server in different directories, as described here: Individual Repository for VESPA Service Resource Descriptor in DaCHS. In practice, various servers in the same institute are separated (e.g., currently for ObsParis: planeto, helio, and maser).

• Only service definition files (resource descriptor, scripts, sample data when required/feasible…) are stored there, in general data are not. 
The use of this gitlab is greatly encouraged also during VESPA implementation workshops and training sessions, as to keep track of past / on-going developments.

The default policy is that any service file is open to registered users, so as to constitute a database of working examples. In case of sensitive material, providers are asked to specify access limitations to one of the team in charge. Conversely, service files can be open publicly if desired.

• The three supporting teams (ObsParis, OATS/INAF and Heidelberg Uni) use the gitlab to help data providers define and improve their services. A main contact team is identified for each service project. Comments are provided as gitlab issues, with separated issues for each topic (ie: topics are split to elemental level, to ensure correct processing and monitoring). 

• As interaction progresses, the data providers are requested to update their services definition files in the gitlab.

• Resources of general interest for data servers are also made available here, such as server settings and awstats configuration files (to produce uniform access statistics on all VESPA servers, as required in Europlanet-2024). 

Action items:

  • Sharing of existing resources between the 3 VESPA hubs to be discussed.
  • Design of repository tree (addressed below: VESPA-Hub Repository Architecture)
  • Finalize gitlab in ObsParis
  • Real life assessment, internal and external services
  • Write / update docs

  • No labels