refactor(providers)!: make provider behavior explicit in imported profiles
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
- Área
- backend, backend-api-design, cli, documentation
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
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-cloudprojects provider config into GCP SDK variables and setsGCE_METADATA_HOST.google-vertex-aiprojects project and region config into GCP and Vertex variables and sets aGOOSE_PROVIDERdefault.
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:
- 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.
- 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.
- Remove it. Delete behavior or APIs with no remaining caller, including
ProviderDiscoverySpecanddiscover_with_specunless 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.
-
ProviderDiscoverySpecanddiscover_with_specare removed or have a documented supported caller. -
ProviderProfile.sourceandresource_versiondocumentation no longer refers to built-in profiles orbuiltinprovenance. - Provider examples, architecture/user documentation, and
0.1.0migration 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:ProviderRegistryregisters the two remaining adapters and selects them by exact profile ID.crates/openshell-providers/src/discovery.rs:discover_from_profilespecial-casesgoogle-vertex-aiconfig 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.protoandcrates/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
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de NVIDIA/OpenShell
-
area:docs
Dificultad 1/5 Menos de una hora Aptitud para principiantes 88/100
-
state:triage-needed
Dificultad 2/5 1-3 horas Aptitud para principiantes 82/100
-
area:cli state:validated
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
-
state:triage-needed
Dificultad 1/5 Menos de una hora Aptitud para principiantes 90/100
-
area:build spike state:review-ready state:stale
Dificultad 2/5 Medio día Aptitud para principiantes 68/100
Todos los issues de NVIDIA/OpenShell
Issues similares
-
bug github_actions
Dificultad 2/5 1-3 horas Aptitud para principiantes 75/100
registrystack/registry-stack#1393 ·
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 75/100
longbridge/gpui-kit#3223 ·
-
bug engine
Dificultad 2/5 1-3 horas Aptitud para principiantes 65/100
rocky-data/rocky#2181 ·
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 70/100
oasisprotocol/oasis-sdk#2523 ·
-
[indexer] [QA] Add a focused test for the new NonRetryableError / assertSocketAlive() behavior. Abiertobot:ai-assisted component:indexer QA-roadmap status:untriaged
Dificultad 2/5 1-3 horas Aptitud para principiantes 75/100
midnightntwrk/midnight-indexer#1557 ·