What if Developer has opinion to Traits?

[resouer]

It happens that a Dev may have some opinion about the Traits for this application.

More generally, the Dev (who understand how the app is developed in code level) may want to communicate with Ops (who generally understand the app but not so deeply as Dev) thru Hydra spec.

Let's say, a Dev has below opinion about scaler Trait:

My awesome application only need to scale when it is SUPER busy.

Note that this opinion deeply depends on the code of this app, so the Ops has no such knowledge unless a Dev tells him personally.

Below is available Traits in the platform:

traits:
  - name: SuperBusyScaler
     properties:
         cpuUsage: 90

traits:
  - name: LessBusyScaler
     properties:
         cpuUsage: 60

So ideally, the one who create ApplicationConfiguration is expected choose to use SuperBusyScaler Traits, while note that currently we have following practice:

Conceptually speaking, an application configuration is managed as part of the application operator role. It has three main sections:

Thus raise this issue we want to discuss here:

How application operator role know about operation opinions from app developer then?

[resouer]

A possible approach is related to "Application Architect" role Matt is proposing in #148 , it may be candidate for a role to coordinate app dev and app operator.

For example, app architect could own a group of Traits Class which is exposed to app dev, so app dev could define Traits Claim for certain class, and the app ops/platform could choose certain Traits to bind with the Claim.

[technosophos]

I believe @BharatNarasimman has an alternative to this that uses "policy" language: A developer can say "my component requires that some trait satisfy this policy" and a trait can list all of the policies it supports.

So in this case, the developer might add to the component a policy that says "policy.example.com/v1.SuperBusyScaler" and a trait my then say that it satisfies the policy "policy.example.com/v1.SuperBusyScaler"

[resouer]

From recent discussion around this issue w @vturecek , I think we may want to begin to formalize the "policy" in OAM component, specifically, if we want to make it part of spec.

/cc @technosophos

[wonderflow]

Ref Policy docs here https://docs.google.com/document/d/1d3kVBFyf7yf-YzmVqkL1hr_qcIVXf6BUJLWKu9NJwvE/edit#

-- by @ryanzhang-oss