Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

refactor(providers)!: make provider behavior explicit in imported profiles

Abierto
#3,442 0 comentarios 1 reacción 0 asignados Ver en GitHub

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
35/100
Tipo de issue
Refactorización
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
rust

Línea de trabajo

Comienza con ProviderRegistry::new e inject_env_for_profile_id en crates/openshell-providers/src/lib.rs; después inspecciona google_cloud.rs, vertex.rs, proto/openshell.proto y el punto de entrada de los servicios de middleware. Haz un inventario de cada comportamiento compilado y decide cómo tratarlo antes de cambiar el esquema o la documentación. El trabajo estará terminado cuando los IDs de perfil bifurcados conserven su comportamiento, los adaptadores ausentes fallen de forma cerrada, se resuelvan las APIs de discovery obsoletas y se documente la clasificación del middleware.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

state:triage-needed

Sub-issue of #3171 (provider boundary in step 5). Follows #3299 / PR #3383, which made provider profiles import-only. Coordinated pre-0.1.0 breaking change under #2565.

User Story

As an operator, I want an imported provider profile to declare every behavior it activates, so I can inspect, fork, and rename the profile without silently changing the sandbox environment.

Problem Statement

#3299 removed the compiled provider profile catalog, but two compiled adapters remain:

  • google-cloud projects provider config into GCP SDK variables and sets GCE_METADATA_HOST.
  • google-vertex-ai projects project and region config into GCP and Vertex variables and sets a GOOSE_PROVIDER default.

ProviderRegistry::inject_env_for_profile_id selects these adapters by the resolved profile ID. Importing the same profile as google-cloud and acme-gcp therefore produces different environments even though the imported definitions are identical.

Other provider-specific behavior is also compiled rather than declared: Vertex discovery scans a fixed list of config variables, and child-environment preparation contains GCP-specific metadata and non-secret configuration handling. ProviderProfile can declare credential environment variables, but not non-secret config projection, fixed non-secret values, discovery config keys, or a required platform adapter.

Impact / Why This Matters

An imported profile is not currently its complete definition. Operators must preserve canonical IDs and know release-specific implementation details, or provider creation succeeds while the workload later fails because expected SDK configuration is absent. This contradicts the import-only contract and makes profile forks unsafe.

Proposed Design

Inventory every compiled provider behavior reachable from an imported profile and give it one disposition:

  1. Express in the profile. Add bounded declarative fields for generic non-secret behavior such as config-to-environment projection, fixed values, and discovery config keys. Do not introduce templating or scripting.
  2. Declare a platform adapter. If behavior is genuinely platform-specific, the profile names the required adapter. Import or attachment fails with a bounded diagnostic when the adapter is unavailable.
  3. Remove it. Delete behavior or APIs with no remaining caller, including ProviderDiscoverySpec and discover_with_spec unless a supported use is identified.

Projection must preserve the existing rule that caller-supplied environment values win. Linting must reject collisions between non-secret projection and credential env_vars.

Update the Google Cloud and Vertex examples so their YAML describes their complete environment and discovery effects. A fork imported under a different ID must behave identically to the canonical example.

Credential refresh strategies are out of scope because profiles already declare them.

Acceptance Criteria

  • Every compiled provider behavior reachable from an imported profile is inventoried as profile-declared, named platform adapter, or removed.
  • No provider behavior activates from the profile ID alone.
  • The Google Cloud and Vertex examples declare their complete non-secret environment and discovery effects.
  • A profile forked under another ID produces the same sandbox environment and discovery behavior as the canonical profile.
  • Environment projection never overwrites an existing value.
  • Import or attachment fails with a bounded diagnostic when a declared platform adapter is unavailable.
  • Profile lint rejects unknown adapters and collisions between non-secret projection and credential environment variables.
  • ProviderDiscoverySpec and discover_with_spec are removed or have a documented supported caller.
  • ProviderProfile.source and resource_version documentation no longer refers to built-in profiles or builtin provenance.
  • Provider examples, architecture/user documentation, and 0.1.0 migration notes describe the resulting contract.
  • Tests cover profile/proto round trips, forked-ID equivalence, collision handling, non-overwrite semantics, and unavailable adapters.

Alternatives Considered

  • Delete both adapters: restores a clean boundary but breaks existing GCP and Vertex workloads at upgrade.
  • Document ID-keyed behavior only: leaves profile forks behaviorally different and the binary authoritative for part of the profile definition.
  • Add a general templating language: unnecessarily turns reviewable profile data into executable configuration; bounded projection covers the observed generic cases.
  • Restore aliases: cannot support an unbounded operator catalog and reintroduces hidden ID coupling.

Technical Notes

  • crates/openshell-providers/src/lib.rs: ProviderRegistry registers the two remaining adapters and selects them by exact profile ID.
  • crates/openshell-providers/src/discovery.rs: discover_from_profile special-cases google-vertex-ai config keys.
  • crates/openshell-core/src/provider_credentials.rs: child environment preparation contains GCP-specific metadata and non-secret resolution.
  • crates/openshell-server/src/grpc/provider.rs: provider environment assembly and key-collision validation are the runtime integration points.
  • proto/openshell.proto and crates/openshell-providers/src/profiles.rs: the public profile schema and YAML/protobuf conversion currently lack this declaration surface.

Checklist

  • Existing issues and architecture documentation reviewed
  • Design proposal; implementation planning follows human disposition
Lenguaje dominante
Rust
Estrellas
8.7k
Forks
1.3k
Merge medio
2 d 6 h
PR fusionados (30 d)
297

Guía de contribución

Abrir la guía de contribución

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de NVIDIA/OpenShell

Todos los issues de NVIDIA/OpenShell

Issues similares

Más issues de Rust

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.