// ============================================================================
// Docker Registry Configuration
// ============================================================================
//
// This file defines how Docker images are pulled from source registries and
// pushed to the local StarlingX registry for testing.
//
// Usage:
// - This file is used as the default by ConfigurationManager.get_docker_config(),
//   unless overridden via the --docker_config_file CLI option.
//
// - Registry endpoints, credentials, and manifest paths can be customized by
//   editing this file or providing an alternate JSON5 file via --docker_config_file.
//
// ----------------------------------------------------------------------------
// Fields:
// ----------------------------------------------------------------------------
// - "default_source_registry":
//     The global fallback registry name if no per-image or manifest mapping applies.
//
// - "image_manifest_files":
//     A list of YAML manifest files describing images, tags, and optional
//     source registries. This allows modular organization of test images
//     by domain, scenario, or team ownership.
//
// - "manifest_registry_map":
//     Optional mapping of manifest filenames to registry resolution rules.
//     Each entry can define:
//       - "manifest_registry": A registry to apply to all images in this manifest
//         if per-image definitions are not used.
//       - "override": If true, all images in the manifest use "manifest_registry"
//         regardless of any "source_registry" specified per image.
//
//     Although per-manifest mapping is optional, it is encouraged—even if
//     "manifest_registry" is set to null—for clarity and visibility.
//
// - "registries":
//     A dictionary of registry definitions including URLs, credentials, and optional path prefixes.
//     Each registry can define:
//       - "path_prefix": Optional path prefix prepended to image names during sync.
//         Enables organizational separation within the same registry host.
//         Trailing slash is optional and will be normalized automatically.
//         Examples:
//           - Harbor projects: "project-x/test" -> harbor.com/project-x/test/busybox
//           - Private registry namespaces: "team-a" -> registry.com/team-a/my-image
//
// ----------------------------------------------------------------------------
// Registry Resolution Behavior:
// ----------------------------------------------------------------------------
// For each image, the registry is resolved in this order:
//
// 1) If a manifest entry exists in "manifest_registry_map":
//    - If "override" is true:
//         The "manifest_registry" is always used for all images.
//    - If "override" is false:
//         a. If the image defines "source_registry", that is used.
//         b. Otherwise, if "manifest_registry" is defined (not null), it is used.
//         c. Otherwise, "default_source_registry" is used.
//
// 2) If the manifest is listed in "image_manifest_files" but does not have a corresponding
//    entry in "manifest_registry_map":
//    - If the image defines "source_registry", that is used.
//    - Otherwise, "default_source_registry" is used.
//
// ----------------------------------------------------------------------------
// Rationale:
// ----------------------------------------------------------------------------
// This design allows declarative, centralized control over where images are
// pulled from without requiring edits to the manifests themselves. It enables:
//
// - Reusing the same manifests across environments.
// - Overriding all sources (e.g., to pull from an internal or mirrored registry).
// - Per-image flexibility for mixed-registry scenarios.
// - Simplified configuration for air-gapped or network-restricted deployments.
//
// ----------------------------------------------------------------------------
// Notes:
// ----------------------------------------------------------------------------
// - Each registry must define a unique "registry_name", which acts as a logical key.
//   This key is referenced in "manifest_registry_map", per-image "source_registry",
//   and "default_source_registry".
// - Public registries (e.g., DockerHub, k8s, GCR) typically do not require credentials.
//   Use empty strings for "user_name" and "password" in these cases.
// - Private registries or internal mirrors (including "local_registry") must be configured
//   with valid credentials if authentication is required.
// - "path_prefix" is optional and only used when the registry organizes images using
//   path-based hierarchies (Harbor projects, private registry namespaces, etc.).
//   Public registries like DockerHub, k8s.io typically don't need path prefixes.
// ============================================================================

{
  "default_source_registry": "dockerhub",

  "image_manifest_files": [
    "resources/image_manifests/stx-test-images.yaml",
    "resources/image_manifests/stx-test-images-invalid.yaml",
    "resources/image_manifests/stx-third-party-images.yaml"
    // "resources/image_manifests/harbor-test-images.yaml",
    // "resources/stx-networking-images.yaml",
  ],

  "manifest_registry_map": {
    // Force all images in this manifest to come from DockerHub
    "resources/image_manifests/stx-test-images.yaml": {
      "manifest_registry": "dockerhub",
      "override": true,
    },
    "resources/image_manifests/stx-test-images-invalid.yaml": {
      "manifest_registry": "dockerhub",
      "override": false,
    },
    "resources/image_manifests/stx-third-party-images.yaml": {
      "manifest_registry": null, // No manifest fallback; each image uses its "source_registry" or "default_source_registry"
    },
    // // Use Harbor as the default for images in this manifest that do not specify "source_registry"
    // "resources/image_manifests/stx-sanity-images.yaml": {
    //   "manifest_registry": "harbor",
    //   "override": false,
    // },
    // // No manifest fallback is defined; each image will use its "source_registry" if set, or "default_source_registry".
    // "resources/stx-networking-images.yaml": {
    //   "manifest_registry": null,
    //   // "override": false,  // Not needed when manifest_registry is null (nothing to override with)
    // },
  },

  "registries": {
    "dockerhub": {
      "registry_name": "dockerhub",
      "registry_url": "docker.io",
      "user_name": "",
      "password": "",
    },

    "k8s": {
      "registry_name": "k8s",
      "registry_url": "registry.k8s.io",
      "user_name": "",
      "password": "",
    },

    "gcr": {
      "registry_name": "gcr",
      "registry_url": "gcr.io",
      "user_name": "",
      "password": "",
    },

    // Examples of registries with path_prefix for organizational separation:

    // Harbor with project-based organization
    // "harbor_project_x": {
    //   "registry_name": "harbor_project_x",
    //   "registry_url": "harbor.example.org:5000",
    //   "path_prefix": "project-x/test",
    //   "user_name": "robot_user",
    //   "password": "robot_token",
    // },

    // Same Harbor host, different project
    // "harbor_user": {
    //   "registry_name": "harbor_user",
    //   "registry_url": "harbor.example.org:5000",
    //   "path_prefix": "user-project", # Trailing slash is optional and will be normalized automatically
    //   "user_name": "harbor_username",
    //   "password": "harbor_password",
    // },

    // Private registry with namespace organization
    // "private_team_a": {
    //   "registry_name": "private_team_a",
    //   "registry_url": "registry.company.com:5000",
    // "path_prefix": "team-a/projects/",   # Trailing slash is optional and will be normalized automatically
    //   "user_name": "team_user",
    //   "password": "team_token",
    // },

    "local_registry": {
      "registry_name": "local_registry",
      "registry_url": "registry.local:9001",
      "user_name": "test_user",
      "password": "test_password",
    },
  },
}