[feature request] Support of Ordered Container Start

[mathieu-benoit]

Support of Ordered Container Start coming from this new Spec version:

• Issue: [FEATURE] Ordered Container Start in Score spec#104
• PR: Ordered Container Start in Score - containers.*.before.containers|ready spec#136

The Spec itself is not yet released, the goal is to use the Spec version from this specific branch first: https://github.com/kai-kystverket/spec/tree/feat/add-before-field-to-containers and this needs to integrated in a temporary score-go version with this: score-spec/score-go#118.

depends_on is the essential ingredient here: https://github.com/compose-spec/compose-spec/blob/main/05-services.md#depends_on. Compose supports waiting for started, ready, or completed. However we are inverting the depends_on to be "before". This should be fine.

These should be caught when running score-xyz generate.

• cyclic relationship container-a.before.containers = [container-b]; container-b.before.containers = [container-a]
• unknown links container-a.before.containers = [unknown]
• Some Score implementations may not support any kind of ready field.

containers:
  init-one:
    ...
    before:
      containers:
      - init-two
  init-two:
    ...
    before:
      containers:
      - main
  main:
    ...

containers:
  init:
    ...
    before:
      ready: complete # implicit default
      containers:
      - main
  sidecar:
    ...
    before:
      containers:
      - main
      ready: started
  main:
    ....

[mathieu-benoit]

@astromechza, like discussed, let's clarify what we want here, thanks!

[mathieu-benoit]

JFYI score-go's branch/PR now in place: score-spec/score-go#121

[mathieu-benoit]

@chris-stephenson, like discussed, could you please help better document this issue (directly edit the description) with detailed information to integrate this branch score-spec/score-go#121 and describe the things to do here in score-compose based on this? Based on this, it will be a good candidate for a good first issue. Thanks!

[Abhishek9639]

Hi @mathieu-benoit,

I'd like to take a stab at this one. I went through the spec PR (spec#136), the examples in the issue, and score-go#121 to understand the full picture.

Here's how I'm thinking about the implementation for score-compose.

1. Parsing: Use the before fields from score-go#121 it already parses containers.*.before.containers and before.ready.

2. Inversion to depends_on: Since Score uses before (forward-looking) and Compose uses depends_on (backward-looking), we'd need to invert.

• If container init has before.containers: [main], then in the generated compose file, main gets depends_on: init.

3. Condition mapping.

• started → service_started
• complete → service_completed_successfully
• ready → service_healthy (this one needs a healthcheck to be defined)

4. Validation during generate.

• Build a directed graph from all before entries and check for cycles.
• Error on references to containers that don't exist in the workload.

A couple of things I'm not sure about.

• For the ready → service_healthy mapping, should score-compose require a healthcheck to be defined, or should we just emit a warning if one is missing?
• Is score-go#121 ready to be used as a dependency, or should I wait for it to be merged first?

Happy to discuss here or on #score-dev. Would love to get this assigned if you're good with the approach.
Thanks

[mathieu-benoit]

Thanks @Abhishek9639, I just assigned it to you, I think you are good to start with what you have described and captured so far.

FYI, you will need to use the not-yet-released score-go version from this branch https://github.com/score-spec/score-go/tree/ordered-containers, as we won't release score-go until it's validated in your score-compose branch/PR.

In the meantime, pinging @chris-stephenson to validate the approach and answer your opened questions.

[Abhishek9639]

Thanks @mathieu-benoit,
I'll use the score-go ordered-containers branch for the implementation. I'll wait for @chris-stephenson to weigh in on the open questions before finalizing the ready → service_healthy behavior. Will get started on the branch in the meantime.