Same principle on both technologies: every lab must be identifiable. Its owner, its project and the fact that it is a lab must be readable without having to ask anyone. Only the mechanics differ.
| Tag | Expected content | Check |
|---|---|---|
owner |
Person or team who created the lab | Denied if missing |
projectName |
Name of the project or lab | Denied if missing |
creationDate |
Creation date, in dd.MM.YYYY format |
Denied if missing |
expirationDate |
Planned expiry (at most +3 months) | Audited if missing (recommended) |
Client |
Client project concerned, for re-invoicing | No check (optional) |
Three tags are blocking, and only those three: owner, projectName and creationDate. Creating the resource is
denied if any of them is missing. A missing expirationDate doesn’t block anything, but it is flagged in the audit.
| Tag | Expected content |
|---|---|
lab |
Marks the resource as belonging to a lab |
owner-{trigramme} |
Identifies the consultant who owns it |
env-lab |
Confirms the environment is a lab |
In addition, YAML metadata must be filled in the Pool’s Notes/Description. It gives the administrators the lab’s context, purpose and owner during the monthly review.
The owner, projectName and creationDate (dd.MM.YYYY format) tags are required on the Resource Group and on every resource in it. Creation is denied if any of them is missing.
The expirationDate tag gives the planned end of the lab (3 months at most). Leaving it out does not block anything but is audited: set it to make end-of-life tracking easier.
The Client tag identifies the client project involved, so costs can be recharged. It is optional, neither enforced nor audited.
Required tags: lab, owner-{trigramme} and env-lab.
Fill in the YAML metadata in the Pool Notes/Description.
