deployment vs. deployment.environment

[martinknechtel]

Hi,

I am wondering if the semantic convention for deployment_environment.yaml matches the intention. I would have expected

• deployment: descriping what a deployment is, hinting that it could be in a special case a ref:k8s.deployment
• deployment.id: string identifying the deployment
• deployment.environment: the deployment environment (aka. deployment tier) for example ['staging', 'production']

WDYT, should I open a PR for discussion?

Best,
Martin

[thomasjanke]

Probably, the general approach should be to put into the log spec as less as possible. More concretely this would mean to only add an id, which is then used as a reference into a "landscape management service" which provides all the additional information such as environment etc.

[joaopgrassi]

Aren't the k8s.deployment.name and k8s.deployment.uid essentially your 1 and 2 points above? The deployment.environment as I see, has a broader scope and it can be used for things not running in k8s.

Now, if deployment and deployment.id are concepts that also exist outside k8s then we may need to think more about it.

[martinknechtel]

Exactly, I argue for creating a separate deployment.yml containing deployment.id and either deployment.environment then stays as is in deployment_environment.yaml or (as Thomas suggested) is removed altogether.

[joaopgrassi]

I think we should be able to "rename" the existing file to deployment.yml file. Then we can add id and maybe name or description, and keep environment as is. If you think this has value, you can open a PR. Just make sure to consider the requirement levels of each new attribute, and maybe come up with examples for them e.g. how you envision they being used in reality.

[martinknechtel]

Thx for your support, I will open a PR and link it here.