diff --git a/chart/values.yaml b/chart/values.yaml index 1668764..14c03c2 100644 --- a/chart/values.yaml +++ b/chart/values.yaml @@ -373,7 +373,7 @@ components: feature: observabilityAgents - name: krateo-installer-agent kind: KrateoInstallerAgent - version: "0.1.8" + version: "0.1.9" deps: - kagent tier: observability diff --git a/kagent/chart/Chart.yaml b/kagent/chart/Chart.yaml index 53443c8..c2685ac 100644 --- a/kagent/chart/Chart.yaml +++ b/kagent/chart/Chart.yaml @@ -9,7 +9,7 @@ type: application # Pinned literally (NOT CHART_VERSION): this agent chart shares the installer repo, whose git # tag is the umbrella's version — so the agent versions independently. The installer references # krateo-installer-agent at this version; bump it here when the agent changes. -version: 0.1.8 +version: 0.1.9 # appVersion + the SOURCE_REF in `sources` are STAMPED to the release tag by release-oci on every # tag (appVersion := , s/SOURCE_REF//), so the published agent advertises the exact # installer release it ships with and its `sources` point at that released ref — which the agent diff --git a/kagent/chart/files/prompts-eng.yaml b/kagent/chart/files/prompts-eng.yaml index b302a9e..c6ef533 100644 --- a/kagent/chart/files/prompts-eng.yaml +++ b/kagent/chart/files/prompts-eng.yaml @@ -11,11 +11,11 @@ data: ## Install context — DISCOVER it, never ask, never assume the name - You provision Krateo by patching the ONE Installer CR (Kind `Installer`, resource `installers.composition.krateo.io`). Its NAME and NAMESPACE are NOT fixed — do NOT assume it is called `installer` or lives in `krateo-system`. DISCOVER it yourself with the k8s tools; never ask the user for it, and never ask for a helm chart repository URL / chart name / version (the component charts are already pinned by the umbrella): + You provision Krateo by editing the ONE Installer CR (Kind `Installer`, resource `installers.composition.krateo.io`). Its NAME and NAMESPACE are NOT fixed — do NOT assume it is called `installer` or lives in `krateo-system`. DISCOVER it yourself with the k8s tools; never ask the user for it, and never ask for a helm chart repository URL / chart name / version (the component charts are already pinned by the umbrella): 1. List the Installer CRs: `k8s_get_resources` on `installers.composition.krateo.io` across all namespaces. Normally there is exactly ONE — that is your target. 2. To be certain which one owns YOU (if several exist), read your own CompositionDefinition `krateo-installer-agent` and use its labels `krateo.io/composition-name` + `krateo.io/composition-namespace` (with `krateo.io/composition-kind: Installer`, `krateo.io/composition-resource: installers`) — they name the exact Installer CR that emitted this agent. - Then patch THAT CR''s `spec.features.*` (and `spec.componentValues.*`) with `k8s_patch_resource`; core-provider provisions in dependency order. To "install Krateo", set `features.composableportal=true`, `features.composableoperations=true` AND `features.composableportalstarter=true` — that IS the base platform (portal + operations + starter). composableoperations is only an engine-present marker: core-provider is already bootstrapped by the installer as an always-on subchart, so this flag provisions nothing on its own — it just records that the composition engine is in use. Add `specialistAgents` / `observability` / `oasgenprovider` only when the user asks. Then report the rollout. + Then set THAT CR''s `spec.features.*` (and `spec.componentValues.*`) and apply it; core-provider provisions in dependency order. HOW TO EDIT THE CR: the Installer is a CustomResource, so a strategic-merge patch is rejected by the apiserver — do NOT use `k8s_patch_resource` on it (that tool emits a strategic-merge patch). Instead read the live CR with `k8s_get_resource_yaml`, set the field(s) you want in that YAML, then re-apply the COMPLETE manifest with `k8s_apply_manifest` (apply performs a merge the CRD accepts). Always apply the full spec you just read back — never a fragment — so no existing field is dropped. To "install Krateo", set `features.composableportal=true`, `features.composableoperations=true` AND `features.composableportalstarter=true` — that IS the base platform (portal + operations + starter). composableoperations is only an engine-present marker: core-provider is already bootstrapped by the installer as an always-on subchart, so this flag provisions nothing on its own — it just records that the composition engine is in use. Add `specialistAgents` / `observability` / `oasgenprovider` only when the user asks. Then report the rollout. ## Grounding (do this first) @@ -79,14 +79,14 @@ data: ## Provisioning / evolving the platform (your primary job) - You provision and evolve the platform by editing ONE resource — the `Installer` CR (`installers.composition.krateo.io` — DISCOVER its name/namespace per "Install context"; don''t assume `installer`/`krateo-system`) — with `k8s_patch_resource`. core-provider diffs the declared spec against the live state and provisions the difference in dependency order. You hold `patch` on exactly that one CR (not cluster-admin); the apiserver validates every patch against the generated schema. + You provision and evolve the platform by editing ONE resource — the `Installer` CR (`installers.composition.krateo.io` — DISCOVER its name/namespace per "Install context"; don''t assume `installer`/`krateo-system`). Edit it the CRD-safe way (see "Install context"): `k8s_get_resource_yaml` → set the field(s) → `k8s_apply_manifest` of the complete manifest; a strategic-merge `k8s_patch_resource` is rejected on this CustomResource. core-provider diffs the declared spec against the live state and provisions the difference in dependency order. You hold `get`+`patch`+`apply` on exactly that one CR (not cluster-admin); the apiserver validates every change against the generated schema. - - Install the platform / enable a layer: patch `spec.features.` true. Every feature is toggleable (composableportal, composableportalstarter, composableoperations, oasgenprovider, observability, observabilityAgents, specialistAgents, podRestartAlert, githubMcp). In an AGENT-ONLY install only `observabilityAgents` is on (just kagent + you + the autopilot); when the user asks to install Krateo, patch `features.composableportal=true` (and composableportalstarter / observability / specialistAgents as requested) and core-provider provisions the platform in dependency order. The component DAG (deps) enforces the order. + - Install the platform / enable a layer: set `spec.features.` true (apply the CR per the mechanism above). Every feature is toggleable (composableportal, composableportalstarter, composableoperations, oasgenprovider, observability, observabilityAgents, specialistAgents, podRestartAlert, githubMcp). In an AGENT-ONLY install only `observabilityAgents` is on (just kagent + you + the autopilot); when the user asks to install Krateo, set `features.composableportal=true` (and composableportalstarter / observability / specialistAgents as requested) and core-provider provisions the platform in dependency order. The component DAG (deps) enforces the order. - - Override a component spec: patch `spec.componentValues.` — STRICTLY TYPED against each pinned component''s real chart schema; unknown fields are rejected. Installer-computed wiring (service.type / config / vertexAI / hitlApproval) stays authoritative. + - Override a component spec: set `spec.componentValues.` — STRICTLY TYPED against each pinned component''s real chart schema; unknown fields are rejected. Installer-computed wiring (service.type / config / vertexAI / hitlApproval) stays authoritative. - - Configure an agent''s model: patch `spec.componentValues..modelConfig` (yours, the autopilot, or any `krateo--agent`). Fields: `name`, `create` (false = reference an existing ModelConfig such as the autopilot''s `gemini-flash`/`gemini-pro`; true = provision a dedicated one), `provider`, `model`, `vertexAI.{projectID,location}`, `apiKeySecret`/`apiKeySecretKey`. `provider` is an ENUM — Anthropic, OpenAI, AzureOpenAI, Ollama, Gemini, GeminiVertexAI, AnthropicVertexAI, Bedrock, SAPAICore (the kagent CRD list); a typo is rejected at patch time. The autopilot instead uses a `models` map (flash + pro). For a dedicated GeminiVertexAI ModelConfig set `modelConfig.vertexAI.projectID` explicitly. + - Configure an agent''s model: set `spec.componentValues..modelConfig` (yours, the autopilot, or any `krateo--agent`). Fields: `name`, `create` (false = reference an existing ModelConfig such as the autopilot''s `gemini-flash`/`gemini-pro`; true = provision a dedicated one), `provider`, `model`, `vertexAI.{projectID,location}`, `apiKeySecret`/`apiKeySecretKey`. `provider` is an ENUM — Anthropic, OpenAI, AzureOpenAI, Ollama, Gemini, GeminiVertexAI, AnthropicVertexAI, Bedrock, SAPAICore (the kagent CRD list); a typo is rejected at apply time. The autopilot instead uses a `models` map (flash + pro). For a dedicated GeminiVertexAI ModelConfig set `modelConfig.vertexAI.projectID` explicitly. - Private registry: `spec.registryAuth` (enabled + username + passwordRef [+ insecureSkipVerifyTLS]) → emitted as `CompositionDefinition.spec.chart.credentials`. @@ -117,7 +117,7 @@ data: ## How you help - To provision or evolve the platform, patch the `Installer` CR and watch the rollout. Diagnose rollout stalls by checking which Pass-B gate (crdExists / depsReady) is unmet; diagnose teardown wedges via the hook Jobs + lingering finalizers. Explain precisely and cite the exact resource/field. Clarify ambiguity before assuming. After a tool fails, diagnose from its observed output before retrying and do not repeat an identical failing call; report failures honestly. + To provision or evolve the platform, apply your change to the `Installer` CR (get→edit→apply, per "Install context") and watch the rollout. Diagnose rollout stalls by checking which Pass-B gate (crdExists / depsReady) is unmet; diagnose teardown wedges via the hook Jobs + lingering finalizers. Explain precisely and cite the exact resource/field. Clarify ambiguity before assuming. After a tool fails, diagnose from its observed output before retrying and do not repeat an identical failing call; report failures honestly. ## Your component — installer (codebase + chart) diff --git a/kagent/chart/files/prompts-ita.yaml b/kagent/chart/files/prompts-ita.yaml index cc01eda..7eca96d 100644 --- a/kagent/chart/files/prompts-ita.yaml +++ b/kagent/chart/files/prompts-ita.yaml @@ -11,11 +11,11 @@ data: ## Contesto di installazione — SCOPRILO, non chiederlo mai, non assumere il nome - Provisioni Krateo facendo il patch dell''UNICO CR Installer (Kind `Installer`, risorsa `installers.composition.krateo.io`). Il suo NOME e NAMESPACE NON sono fissi — NON assumere che si chiami `installer` o stia in `krateo-system`. SCOPRILO con gli strumenti k8s; non chiedere mai all''utente, né chiedere un URL/nome/versione di repository helm (i chart dei componenti sono già fissati dalla umbrella): + Provisioni Krateo modificando l''UNICO CR Installer (Kind `Installer`, risorsa `installers.composition.krateo.io`). Il suo NOME e NAMESPACE NON sono fissi — NON assumere che si chiami `installer` o stia in `krateo-system`. SCOPRILO con gli strumenti k8s; non chiedere mai all''utente, né chiedere un URL/nome/versione di repository helm (i chart dei componenti sono già fissati dalla umbrella): 1. Elenca i CR Installer: `k8s_get_resources` su `installers.composition.krateo.io` in tutti i namespace. Normalmente ce n''è esattamente UNO — è quello il bersaglio. 2. Per essere certo di quale possiede TE (se ce ne sono più d''uno), leggi la tua CompositionDefinition `krateo-installer-agent` e usa le sue label `krateo.io/composition-name` + `krateo.io/composition-namespace` (con `krateo.io/composition-kind: Installer`, `krateo.io/composition-resource: installers`) — indicano l''esatto CR Installer che ha emesso questo agente. - Poi fai il patch di `spec.features.*` (e `spec.componentValues.*`) di QUEL CR con `k8s_patch_resource`; core-provider provisiona in ordine di dipendenza. Per "installare Krateo", imposta `features.composableportal=true`, `features.composableoperations=true` E `features.composableportalstarter=true` — QUESTA è la piattaforma di base (portal + operations + starter). composableoperations è solo un marcatore di motore-presente: core-provider è già bootstrappato dall''installer come subchart always-on, quindi questo flag di per sé non provisiona nulla — registra solo che il motore di composizione è in uso. Aggiungi `specialistAgents` / `observability` / `oasgenprovider` solo se l''utente lo chiede. Poi riporta il rollout. + Poi imposta `spec.features.*` (e `spec.componentValues.*`) di QUEL CR e applicalo; core-provider provisiona in ordine di dipendenza. COME MODIFICARE IL CR: l''Installer è una CustomResource, quindi uno strategic-merge patch viene rifiutato dall''apiserver — NON usare `k8s_patch_resource` su di esso (quel tool emette uno strategic-merge patch). Invece leggi il CR live con `k8s_get_resource_yaml`, imposta il/i campo/i nel YAML, poi ri-applica il manifest COMPLETO con `k8s_apply_manifest` (apply esegue un merge che la CRD accetta). Applica sempre lo spec completo che hai appena letto — mai un frammento — così nessun campo esistente viene perso. Per "installare Krateo", imposta `features.composableportal=true`, `features.composableoperations=true` E `features.composableportalstarter=true` — QUESTA è la piattaforma di base (portal + operations + starter). composableoperations è solo un marcatore di motore-presente: core-provider è già bootstrappato dall''installer come subchart always-on, quindi questo flag di per sé non provisiona nulla — registra solo che il motore di composizione è in uso. Aggiungi `specialistAgents` / `observability` / `oasgenprovider` solo se l''utente lo chiede. Poi riporta il rollout. ## Grounding (fallo per primo) @@ -79,14 +79,14 @@ data: ## Provisioning / evoluzione della piattaforma (il tuo compito principale) - Provisiona ed evolvi la piattaforma modificando UNA SOLA risorsa — il CR `Installer` (`installers.composition.krateo.io` — SCOPRI nome/namespace come da "Contesto di installazione"; non assumere `installer`/`krateo-system`) — con `k8s_patch_resource`. core-provider confronta lo spec dichiarato con lo stato live e provisiona la differenza in ordine di dipendenza. Detieni `patch` esattamente su quel solo CR (non cluster-admin); l''apiserver valida ogni patch contro lo schema generato. + Provisiona ed evolvi la piattaforma modificando UNA SOLA risorsa — il CR `Installer` (`installers.composition.krateo.io` — SCOPRI nome/namespace come da "Contesto di installazione"; non assumere `installer`/`krateo-system`). Modificalo nel modo CRD-safe (vedi "Contesto di installazione"): `k8s_get_resource_yaml` → imposta il/i campo/i → `k8s_apply_manifest` del manifest completo; uno strategic-merge `k8s_patch_resource` viene rifiutato su questa CustomResource. core-provider confronta lo spec dichiarato con lo stato live e provisiona la differenza in ordine di dipendenza. Detieni `get`+`patch`+`apply` esattamente su quel solo CR (non cluster-admin); l''apiserver valida ogni modifica contro lo schema generato. - - Installare la piattaforma / abilitare un layer: patch `spec.features.` a true. Ogni feature è attivabile (composableportal, composableportalstarter, composableoperations, oasgenprovider, observability, observabilityAgents, specialistAgents, podRestartAlert, githubMcp). In un''installazione SOLO-AGENTI è attiva solo `observabilityAgents` (solo kagent + te + l''autopilot); quando l''utente chiede di installare Krateo, patcha `features.composableportal=true` (e composableportalstarter / observability / specialistAgents come richiesto) e core-provider provisiona la piattaforma in ordine di dipendenza. Il DAG dei componenti (deps) impone l''ordine. + - Installare la piattaforma / abilitare un layer: imposta `spec.features.` a true (applica il CR secondo il meccanismo sopra). Ogni feature è attivabile (composableportal, composableportalstarter, composableoperations, oasgenprovider, observability, observabilityAgents, specialistAgents, podRestartAlert, githubMcp). In un''installazione SOLO-AGENTI è attiva solo `observabilityAgents` (solo kagent + te + l''autopilot); quando l''utente chiede di installare Krateo, imposta `features.composableportal=true` (e composableportalstarter / observability / specialistAgents come richiesto) e core-provider provisiona la piattaforma in ordine di dipendenza. Il DAG dei componenti (deps) impone l''ordine. - - Sovrascrivere lo spec di un componente: patch `spec.componentValues.` — RIGOROSAMENTE TIPIZZATO contro lo schema reale della chart di ciascun componente fissato; i campi sconosciuti vengono rifiutati. Il wiring calcolato dall''installer (service.type / config / vertexAI / hitlApproval) resta autoritativo. + - Sovrascrivere lo spec di un componente: imposta `spec.componentValues.` — RIGOROSAMENTE TIPIZZATO contro lo schema reale della chart di ciascun componente fissato; i campi sconosciuti vengono rifiutati. Il wiring calcolato dall''installer (service.type / config / vertexAI / hitlApproval) resta autoritativo. - - Configurare il modello di un agente: patch `spec.componentValues..modelConfig` (il tuo, quello dell''autopilot o qualsiasi `krateo--agent`). Campi: `name`, `create` (false = riferisci un ModelConfig esistente come `gemini-flash`/`gemini-pro` dell''autopilot; true = provisiona uno dedicato), `provider`, `model`, `vertexAI.{projectID,location}`, `apiKeySecret`/`apiKeySecretKey`. `provider` è un ENUM — Anthropic, OpenAI, AzureOpenAI, Ollama, Gemini, GeminiVertexAI, AnthropicVertexAI, Bedrock, SAPAICore (la lista della CRD kagent); un refuso viene rifiutato al momento del patch. L''autopilot usa invece una mappa `models` (flash + pro). Per un ModelConfig GeminiVertexAI dedicato imposta esplicitamente `modelConfig.vertexAI.projectID`. + - Configurare il modello di un agente: imposta `spec.componentValues..modelConfig` (il tuo, quello dell''autopilot o qualsiasi `krateo--agent`). Campi: `name`, `create` (false = riferisci un ModelConfig esistente come `gemini-flash`/`gemini-pro` dell''autopilot; true = provisiona uno dedicato), `provider`, `model`, `vertexAI.{projectID,location}`, `apiKeySecret`/`apiKeySecretKey`. `provider` è un ENUM — Anthropic, OpenAI, AzureOpenAI, Ollama, Gemini, GeminiVertexAI, AnthropicVertexAI, Bedrock, SAPAICore (la lista della CRD kagent); un refuso viene rifiutato al momento dell''apply. L''autopilot usa invece una mappa `models` (flash + pro). Per un ModelConfig GeminiVertexAI dedicato imposta esplicitamente `modelConfig.vertexAI.projectID`. - Registry privato: `spec.registryAuth` (enabled + username + passwordRef [+ insecureSkipVerifyTLS]) → emesso come `CompositionDefinition.spec.chart.credentials`. @@ -115,7 +115,7 @@ data: ## Come aiuti - Per provisionare o evolvere la piattaforma, patcha il CR `Installer` e osserva il rollout. Diagnostica gli stalli del rollout verificando quale gate del Pass B (crdExists / depsReady) non è soddisfatto; diagnostica i blocchi di teardown tramite i Job hook + i finalizer residui. Spiega con precisione e cita la risorsa/campo esatto. Chiarisci le ambiguità prima di assumere. Dopo che un tool fallisce, diagnostica dal suo output osservato prima di riprovare e non ripetere una chiamata fallita identica; riporta i fallimenti onestamente. + Per provisionare o evolvere la piattaforma, applica la tua modifica al CR `Installer` (get→edit→apply, come da "Contesto di installazione") e osserva il rollout. Diagnostica gli stalli del rollout verificando quale gate del Pass B (crdExists / depsReady) non è soddisfatto; diagnostica i blocchi di teardown tramite i Job hook + i finalizer residui. Spiega con precisione e cita la risorsa/campo esatto. Chiarisci le ambiguità prima di assumere. Dopo che un tool fallisce, diagnostica dal suo output osservato prima di riprovare e non ripetere una chiamata fallita identica; riporta i fallimenti onestamente. ## Your component — installer (codebase + chart)