Format for a CNF to expose it's dependencies

[sronanrh]

How should each CNF expose any dependencies it has on both infrastructure and other CNFs thus that it can know it will operate properly within a given environment?

[cristicalin]

Can we have a provides and consumes type of manifest in a way that would allow to create relations between CNFs? In that way K8S itself can provide some resources while CNFs can consume resources from K8S or other providers while also providing something for consumption by others.

Today, relations in K8S are kind of hard to map, they are mainly expressed through labels and are missing a quantitative measure. Are they enough to express dependencies? Can we define something else? Are operators the proper frameworks to express these relationships?

[electrocucaracha]

@sronanrh Are you suggesting to expose dependency information as metadata for consumers (like using annotations or labels) or as information used by the system to operate(like requests and limits)? From my understanding the reason to don't express dependencies in K8s is to encourage the API communication among components.

[sronanrh]

I think the way @cristicalin describes the manifest is something along the lines of what I was describing, but I would also add a 'requires' option. But I wouldn't limit these values to just other APIs, it may require, or consume physical resources, like hardware acceleration, etc.

[cristicalin]

Maybe something along the line of resources.requests and resources.limits from pod spec ?

I think we rely just on that mechanism for physical resources since it is already how SR-IOV vfs are consumed today and probably more to come.

[electrocucaracha]

My only concern with expose and/or manage dependencies is the increase of complexity which can result using chaos engineering techniques