Skip to content

Configure named VOSpace services for Science Platform Servers #151

Description

@shinybrar

Part of Integrate upstream vosfs and fsspec-cli as canfar data.

Summary

Add the configuration model that associates one or more named VOSpace services with each Science Platform Server. This ticket owns the domain/configuration shape only.

Required changes

  • Add VOSpaceService with:
    • uri: AnyUrl — registry resource identifier;
    • url: AnyHttpUrl — VOSpace base endpoint without /capabilities.
  • Add Server.storage: dict[str, VOSpaceService] with an empty default.
  • Keep Configuration schema version 1; existing files without storage must load unchanged.
  • Treat each nested key as a globally unique Storage Name.
  • Reserve local.
  • Apply upstream source-name constraints: non-empty; no colon, NUL, or newline; not starting with -.
  • Reject duplicate Storage Names across different servers.
  • Do not duplicate the mapping key as a required field inside VOSpaceService.
  • Add VOSpace Service and Storage Name to CONTEXT.md.

Acceptance criteria

  • Existing v1 configurations deserialize without migration or data loss.
  • Configuration JSON/YAML serialization includes stable nested storage mappings.
  • Multiple storage services may belong to one server and inherit its IDP.
  • Duplicate, reserved, and malformed Storage Names fail with actionable validation errors.
  • Built-in/default configuration can carry a primary service without changing Server Selection semantics.
  • Focused model/config tests cover round trips and every validation boundary.
  • Lint and deterministic tests pass; the type check adds no diagnostics beyond the explicitly accepted 22-warning main baseline.

Out of scope

Registry discovery, credential resolution, filesystem construction, CLI registration, storage-management commands, VOSpace protocol code, and public Python storage helpers.

Delivery

Implemented through ticket PR #216 on feat/vosfs-support. Configuration head: 5f75b131. The earlier optional-extra packaging decision is superseded by parent #150: #154 will promote vosfs and fsspec-cli to normal dependencies and remove canfar[data] before landing the full epic.


Amended 2026-07-25

The acceptance criteria above are preserved as originally written. The items
below changed after this issue was filed, at the maintainer's request, and
shipped in #217.

  • Existing configurations are healed on load. This qualifies "existing
    files without storage must load unchanged". Configuration restores the
    default CADC Storage Identifiers when a saved Server carries a legacy
    Server-Name key or no storage at all, so canfar data ls arc:/ works for
    installs predating arc/vault. The heal is scoped to the default Servers,
    leaves deliberate Storage Identifiers untouched, and normalizes in memory
    only; the file is rewritten when something independently calls save().

Metadata

Metadata

Assignees

Labels

enhancementNew feature or request

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions