[lifecycle&health] Meeting Minutes

[ramceb]

Minutes 2025-09-03

• Wait and ready conditions
• how could we signal a ready condition:
  • Signaling via an dedicated API (Managed processes)
  • Availability of a certain file
  • Process has terminated succesfully
  • Process was properly started and is properly started (default, Unmanaged processes)

Minutes 2025-09-17

• Feedback PLMS
• PR ready conditions docs: Add ready condiditions #1738
• Incubation repository available: https://github.com/eclipse-score/inc_lifecycle

Minutes 2025-09-24

• Timeline availability of PLMS
• Presentation of qorix @vinodreddy-g
  • Link to contribution request epic
• Walk-through open issues
• @odra to present concept for an implementation on linux

Minutes 2025-10-01

• Realization on linux @odra
• Status planned contributions

Minutes 2025-10-15

• Preparation architecture workshop 4-6.11.2025
• Status planned contributions
  • qorix will present the health monitor library including integration with systemd
    • Implemention in rust with C++ frontend
    • qnx solution would be integrated on top of plms
  • bmw will present the lifecycle API aka mw::lifecycle
    • C++ Implementation
  • redhat will present concept based on systemd
    • pur linux solution
  • etas will present a complete solution (launch_manager + healthmonitor)
    • C++ Implementation no rust support so far
    • Solution supports qnx and linux
      @NicolasFussberger: Please present etas concept next week
      @ALL: please check open source status of your planned contribution.
      @vinodreddy-g : please invite colleague of epam for concept presentation next week.
• Alignment on evaluation criteria for contributions based on how to contribute
  @ramceb create evaluation proposal for discussion.

Minutes 2025-10-22

• Presentation etas contribution
• Presentation epam contribution
• Proposal of scenarios to be evaluated:
  • Szenario
    1. qorix contribution (health monitor) + plms (launch_manager) + mw::lifecycle (lifecycle api)
    2. redhat contribution (launch_manager) + qorix(health monitor) + mw::lifecycle (lifecycle api)
    3. etas contribution (launch_manager, health monitor) + mw::lifecycle (lifecycle api)
    4. epam (launch_manager) + qorix contribution (health monitor) + mw::lifecycle (lifecycle api)
  • Additional evaluation criteria:
    • Availability of solution on QNX and on Linux

Minutes 2025-10-28

criterion	szenario 1	szenario 2	szenario 3	szenario 4
Alignment with the Feature Request.	++	++	++	- (uC based sv
Availability of the Source Code	0 (plms closed src)	++ (oss solution)	++	++
Technical Maturity	+ (health mon. POC)	0 (integration as POC	++	0 (QM only)
Initial Impact Assessment:	+	+ (libdbus needed)	+	--
Supporting Artifacts:	-- not for plms	-- not yet available	++	-- (QM only)
Availability for QNX and Linux	- QNX only	- Linux only	++	- Linux only
Maintainer available	+	++	++	-

Minutes 2025-11-12

• Wrap-up architecture workshop
• Provide detailed design documentation for etas contribution
• Step 0: Add NOTICTE and LICENSE files to inc_lifecycle @FScholPer
• Step 1: Merge etas contribution to main of inc_lifecycle --> done
• Step 2: Integrate mw::lifecycle API @ramceb
• Step 3: Create PR to integrate qorix library. @S-MOHAMD
• Step 4: Rebase bazel_deps to 0.5. @S-MOHAMD
• Step 5: Migrate to score dev-container @S-MOHAMD

[NicolasFussberger]

These are the slides shown for ETAS contribution in the meeting on 2025-10-22:
Lifecycle_Health_Monitoring_ETAS.pdf

[bucci-kawabuchi]

Here is the diagram of existing AosCore of AosEdge platform, shown for EPAM contribution in the meeting on 2025-10-22:
#1904 (comment)

[FScholPer]

Question is the Scenario 1 same as a and 2 same as b??

[vinodreddy-g]

supporting artifacts for scenario 2 could be made "0" instead of "--".

[anmittag]

can you also use a new comment field for every new meeting as in other function teams please?

[FScholPer]

@S-MOHAMD can you please define some default maintainer(or nominate a developer to become a committer). Currently we do not have anyone who does the pr reviews in the incubator repo

[S-MOHAMD]

@FScholPer I would prefer to name two to avoid blocking in case of absence. I suggest:

• Myself @S-MOHAMD - Maintainer
• @NicolasFussberger - Committer

[FScholPer]

Issues created Lifecycle & Health. Assigned to Andreas Mittag as you both are neither contributors nor committers

[FScholPer]

2025-11-19

Participants

@S-MOHAMD
@FScholPer
@vinodreddy-g
@NicolasFussberger
Toma-Florin Ungureanu

Agenda Points

• Project with the created tickets from last meeting

Meeting Minutes

• Create PR to integrate qorix library #2047 Integration of Qorix AI
• Agreement to accept to use Rust with the risks that the certification is not there.
• Committer election needed for the maintainers
• Ask @ramceb if we switch
• Align with module template dir #2050 add reference repo to start with
• Licences and notice file will come this week

[S-MOHAMD]

Request for an agenda point for next meeting:

• Requirements discussion & clarification ~15 min's
  • basic terms understanding (run targets Vs run-states, ...)
  • alive supervision from within the app process

[ramceb]

2025-11-26

Participants

@S-MOHAMD
@FScholPer
@vinodreddy-g
@NicolasFussberger
Toma-Florin Ungureanu
@ramceb

Agenda Points

• Migration to qorix library

Meeting Minutes

• we can only migrate to the rust library as soon as we know how to qualify it.
• Until we know how to qualify the rust library we want to keep the deadline and logical supervision in the daemon.
• Investigate qualification of rust code @TomaUngureanu
• Prepare discussion on alive monitoring of apps use case for next meeting @S-MOHAMD

[pawelrutkaq]

Here we track Rust certification Rust certification (view)

[TomaUngureanu]

@ramceb, @S-MOHAMD, do we have some way forward regarding this discussion or a meeting proposal to discuss and clarify the technical details? If the meeting already took place, can you please point me to the meeting minutes and/or the action points to be taken?

[ramceb]

Hi, IMHO we will discuss this on wednesday in the weekly sync.

[S-MOHAMD]

03-12-2025

Participants

@S-MOHAMD
@FScholPer
@NicolasFussberger
@Toma-Florin Ungureanu
@ramceb
@pawelrutkaq

Agenda:

• Alignment on next steps about the health lib
  • Rust certification is in progress, we can assume that the it is certifiable by end of 2026
    • some used libstd modules can be relaced in case was not certified
  • Qorix will commit to provide both C++/Rust API's and in case of a decision against rust eventually then Qorix is to adapt the needed internal changes to C++ ()
  • Group agreed to move directly to Version 2 in the above comment
  • Qorix is to bring the current PR in smaller reviewable changes

Topics for next round

• Alive supervision API usage by application
• Configuration model initial ideas

[pawelrutkaq]

Proposal for a way forward we discussed on today's meeting:
Way forward for Version 2 solution of lifecycle.pptx

[ramceb]

2025-12-10

Participants

Agenda

• Org: Availability next week?
  • Meeting on 2025-12-17 will take place
• Integration of health library
  • decision is to implement first version based on existing API
  • Before we do further rework we introduce basic tests:
• Alive supervision within application
  • 1. supervisor_api: There shall be an alive supervision per process: launch_manager supervises the application process. ==> implemented in launch_manager.
  • 2. alive_api: There shall also be a more fine-grained alive supervision within application. e.g. to supervise single threads. ==> implemented in health libs. @pawelrutkaq to come up with a proposal.
• Configuration model

[ramceb]

2025-12-17

Particpants

@ramceb
@pawelrutkaq
@jaakkoaho
@S-MOHAMD
@SimonKozik
@TimoSteuerwaldETAS

Agenda

• Design Review health monitor
  • Feedback will be incorporated unitl 2025-12-18
  • @ALL please review before holidays
  • Open topic: calculation of cycle-time for launch_manager supervision. ==> For now we stick to the approach to apply the supervision parameters as config parameters
  • Next meeting: Discussion of spatial FFI concept for health monitor.
• Movement of feature requirements
• Integration mw::lifecycle
  • @FScholPer move existing contribution to src/lifecycle_client_lib and merge the PR. Afterwards we start the integration with existing implementation