[proposal] Component and Trait Dependency

[hongchaodeng]

Background

This is an extension from oam-dev/spec#326. Create the issue here to acquire more interest. We also have an implementation in our fork so we would like to merge them together.

Let me start with three use cases here.

1. Web app depends on database

An applicationConfiguration consists of two components: web and db. Web component should not be created until db component is created and ready, including database account and public endpoint created and ready.

2. ML app workflow

An ML applicationConfiguration has three components:

• preprocess
• training
• serving

They have strict ordering as follows:

  preprocess -> training -> serving

Without the previous stage finished, the next could not start due to lack of data.
Today, ML framework including Tensorflow would not handle such dependency health. They rely on external platform to handle it.

3. Service binding trait

More background info on service binding can be found here: slides.
A service binding trait needs to be applied before creating the component.
Moreover, this trait ordering use case is quite general and applies to many other traits we have.

[hongchaodeng]

cc @vturecek @negz @artursouza @resouer @wonderflow @ryanzhang-oss

[wonderflow]

Totally agree! Component and Trait Dependency are really important and needed! Let me add one more scenario.

Scenario : workload which can run without everything is ready

Let's say we have a containerized workload and log collector trait.

The log collector trait will collect audit log from containerized workload, the containerized workload itself will rotate it's log.

If we don't have trait order, the containerized workload will get start first and then the log collector trait will start after that.

The workload could run smoothly even if the log collector isn't ready. Then we could possibly miss some audit logs.

If these logs are really important, we must need the trait to start before the workload start.

[allenhaozi]

We are building new machine learning scenarios internally, We call it Hypercycle ML
a completed hypercycle requires multiple services composed and these services is ordered
this dependency can help us build a lighter infrastructure and low coupling platform

[wonderflow]

closing as proposal has been merged and implemented https://github.com/crossplane/oam-kubernetes-runtime/blob/master/design/resource-dependency.md