standard status for OAM object

[wonderflow]

OAM have spec which defines how to run an Application, while we also need a standard way to know whether the Application is running well and cooperate with another Application. In k8s, we usually use status of an object to do this kind of work.

So I think we need some standard way to define the status of OAM object.

[zhxu2]

would this be inferred by healthscope?

[wonderflow]

health scope didn't have standard status either. The status here not only including health, but also include all state of the current workload. For example, the real replica of the instance, the execution step/phase of the workload..

[zhxu2]

Missing of application status as well as rudr error codes is becoming a blocker for our next release.

For today we have status field such as:

status:
components:
helloworld-python-v1:
deployment/first-app-helloworld-python-v1: running
ingress/first-app-helloworld-python-v1-trait-ingress: created
service/first-app-helloworld-python-v1: created
phase: synced

periodically collecting workload meta data. We can think of how OAM object status can be inferred from the aboves. However any idea about how one application cooperates with another should work?

[zhxu2]

I think having checks on one app working with another is out of the scope at this point. However I will start working on adding error codes and put error msgs in status fields when app deployments runs into issues now. As of today if app config files fail validations, nothing helpful will get reported back to customers (I guess it will kind of overlaps with your admission controller)?

[wonderflow]

I think having checks on one app working with another is out of the scope at this point.

Yes, indeed，standard status should do the thing.

As of today if app config files fail validations, nothing helpful will get reported back to customers

Yeah, this should be solved by admission controller.

[wonderflow]

ping @technosophos @hongchaodeng , what do you think about this issue?

[technosophos]

I think a standard status object is a good idea. You are thinking something modeled more like a Deployment's status? (which tracks the health of things run via the replica set)

[zhxu2]

I think a standard status object is a good idea. You are thinking something modeled more like a Deployment's status? (which tracks the health of things run via the replica set)

Yes. Today we have OAM status. We also need a standard status as well as RudrErrorProvider

[wonderflow]

@technosophos so do we need to add this to OAM spec?

[zhxu2]

Also it's helpful to pass on the actual error code/msg as part of app cfg status.

E.x. a missing image will give "deployment/first-app-helloworld-python-v1: unavailable" in cfg status. Without having to go through a list of workloads it can show error codes directly like
Error: ImagePullBackOff Back-off pulling image "oamdev/helloworld-python:v100"