Open axisofentropy opened 1 year ago
If getting or applying any of those values is difficult, just skip them! Literally anything will be better than what we have now.
Note that in addition to the label keys, values also have a restricted character set, so we'll probably need to modify them before use. https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/#syntax-and-character-set
Valid label value:
- must be 63 characters or less (can be empty),
- unless empty, must begin and end with an alphanumeric character ([a-z0-9A-Z]),
- could contain dashes (-), underscores (_), dots (.), and alphanumerics between.
Or maybe base64 encode some of them? But probably not. Emails are right out tho.
We're currently adding just a couple labels to
Pods
specified by customerDeployments
. https://github.com/UffizziCloud/uffizzi_controller/blob/3dec0f245f6e43a69b3c842cf75ecea79a35b2ae/internal/clients/kuber/requests.go#L48-L51We'd like to add some additional labels that can be used to later do more useful reporting.
Some suggestions and example values:
app.uffizzi.com/project-id: "3255"
app.uffizzi.com/project-name: "Example Project"
app.uffizzi.com/account-id: "3306"
app.uffizzi.com/account-name: "Example Account"
app.uffizzi.com/user-id: "3465"
(value ofdeployments.deployed_by_id
)app.uffizzi.com/user-email: "user+uffizzi@example.com"
app.uffizzi.com/deployment-id: "25505"
app.uffizzi.com/compose-file-id: "38128"
app.uffizzi.com/deployment-metadata: '{"labels": {"gitlab": {"repo": "example/apps/example", "merge_request": {"number": "2666"}}}}'
Note that all values are strings, not numbers!
This info should probably be accepted by the existing
ApplyContainers
endpoint https://github.com/UffizziCloud/uffizzi_controller/blob/3dec0f245f6e43a69b3c842cf75ecea79a35b2ae/internal/http/containers.go#L66But I think it should be optional. If this new information is not passed to the HTTP API endpoint, or if any values are
""
, then we should not add the labels to the Pod template.I'd love to see some GitHub and GitLab metadata too but that's less important and I'm not sure what the best schema would be. If we include this, we should probably copy this schema from flux, argocd, or someone else who's similarly automating.
This will enable new reporting use cases like: