Extend project-scoped lifecycle handling and separate monitoring readiness

Aperta
  • Qualcosa non va?
#3,522 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
30/100
Tipo di issue
Funzionalità
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
docker, docker-compose, shell
Ambito
devops, infrastructure

Direzione di ricerca

Start by reading .ci_cd/host_init/start.sh and trace its callers, then inspect deploy.sh and post_init.sh for the host-wide operations named in the issue. Review the linked prerequisite and integration issues before changing lifecycle behavior. Done means the acceptance criteria are covered, including isolated fixtures for unrelated projects and separate core and monitoring readiness results.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

Related spike: https://github.com/openremote/core/issues/2763

Prerequisites / integration: #3509; integrate selected modules and bundle mode as #3514/#3521 become available.

User Story

As a deployment maintainer, I want project-scoped lifecycle operations and an explicit monitoring readiness policy so that application failures are reported correctly and unrelated services retain their state.

Description

Build on .ci_cd/host_init/start.sh introduced by #3345. It already uses project-scoped Compose --wait with a 300-second timeout and injects manager -> deployment: service_completed_successfully. Preserve the existing two-argument interface, one-shot handling and diagnostic behaviour for legacy callers.

Add an explicitly selected readiness policy for the new composition: core application failures remain fatal; monitoring failures produce a distinct degraded-monitoring result without preventing core startup. Keep legacy all-selected-service waiting unchanged for existing callers. Optional application components can be required according to the selected composition. Services without health checks need an explicit readiness contract.

Audit remaining host-wide operations: the stop pre-check, all-image/all-container snapshots in deploy.sh, and volume/image pruning in post_init.sh. Scope application operations by project/ownership, retaining the or default and existing backup/restart/clean hooks. Host-wide maintenance belongs to a separate process with explicit ownership.

Define an opt-in telemetry network/endpoint convention without installing the monitoring stack or changing existing collection endpoints.

Acceptance Criteria

  • Existing single-file callers retain startup behaviour and timeout; new policy selection is explicit. The helper continues to support start.sh <compose-file> <project-name>.
  • Tests cover no deployment service, successful/failed one-shot initialization, already-populated deployment content, core unhealthy/timeout/exit, no health check and failed optional monitoring.
  • Core readiness and monitoring readiness are reported independently under the new policy; failure propagation cannot accidentally turn a core failure into success.
  • Every deployment-content consumer starts with correct content, both through direct Compose and through the helper; include/merge interaction with its stdin override is tested on each supported CLI.
  • An unrelated running and stopped fixture project survives application deploy, stop, content refresh and cleanup, with its state/images retained.
  • Application snapshots contain only intended project resources and exclude sensitive environment values. Project hooks cannot silently reintroduce host-wide cleanup in the supported composition.
  • Normal deployment preserves persistent database/Manager/certificate/extension volumes. Explicit clean-install semantics remain separate; no blanket down -v is introduced.
  • The external telemetry network has documented provisioning ownership and unique endpoint conventions. Only necessary services join; root/legacy deployments do not require it.
  • Host CloudWatch collection on localhost ports 8404/8405/8406 remains supported. Moving a collector into another project requires an explicit address/network migration.
  • Manager OTLP endpoints remain configurable without depending on collector health. Monitoring configuration/state never depends on the refreshed application deployment volume.

Implementation Notes

  • Extend the existing startup helper rather than reintroducing the removed host-wide health poll.
  • Initial lifecycle work depends on the compatibility baseline; module and bundle integration follows as those features become available.
  • Use synthetic examples and isolated fixtures without customer identifiers or production secrets.
Lingua principale
Java
Stelle
1.9k
Fork
478
Nessuna PR unita negli ultimi 30g

Preparare l'ambiente

Apri in Codespaces

Avvia il container di sviluppo del progetto nel browser, con il tuo account GitHub.

  • Include un Dockerfile o un file Docker Compose
  • Ha un modello di pull request
  • Nessuna guida per i contributori

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di openremote/openremote

Tutte le issue di openremote/openremote

Issue simili

Altre issue su Java

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.