Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

allow for the inclusion of arbitrary key / value metadata #236

Merged
merged 2 commits into from
Mar 25, 2024

Conversation

BertHartm
Copy link
Contributor

When working with lots of SLO / SLI objects at scale, it can be helpful to be able to add arbitrary metadata to indicate things like:

  • ownership
  • association to certain projects
  • criticality or other ways that teams might need to organize their SLOs, SLIs, and Datasources.

Allowing for key value pairs in the spec directly avoids having to do workarounds like depend on naming schemes.

When working with lots of SLO / SLI objects at scale, it can be helpful to be able to add arbitrary metadata to indicate things like:
- ownership
- association to certain projects
- criticality
or other ways that teams might need to organize their SLOs, SLIs, and Datasources.

Allowing for key value pairs in the spec directly avoids having to do workarounds like depend on naming schemes.

Some prior discussion is in OpenSLO#179
@BertHartm
Copy link
Contributor Author

Some prior discussion is in #179

I was unsure of the best syntax to indicate an optional object of keys with string values, so I grabbed this based on the k8s CRD spec, but if something else is preferred let me know.

@BertHartm
Copy link
Contributor Author

additionally, having metadata in the Objectives objects for the SLO would be helpful. Those don't currently appear to be specificed in this file, but I can add that spec.

@nieomylnieja
Copy link
Member

@BertHartm you can open a separate PR for objectives' metadata, I think this suggestion also makes a lot of sense :)

@BertHartm
Copy link
Contributor Author

@BertHartm you can open a separate PR for objectives' metadata, I think this suggestion also makes a lot of sense :)

Thanks, filed #237 for that specifically

@nieomylnieja nieomylnieja added the v2alpha1 Incompatible changes proposed for the next major release label Nov 23, 2023
Copy link
Member

@nieomylnieja nieomylnieja left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

On the last community meeting we've agreed on merging this to v2alpha :) thanks a lot for this contribution!

Side note: We also decided to change the labels to adhere with k8s schema, but this will get done in a different PR.

@nieomylnieja
Copy link
Member

@BertHartm could please resolve the conflict? Thanks!

@BertHartm
Copy link
Contributor Author

@BertHartm could please resolve the conflict? Thanks!

updated, please review

@fourstepper
Copy link
Contributor

I think that this ties into the discussion around Kubernetes compatibility a bit.

If we chose to use the Kubernetes ObjectMeta v1 meta, we would get this and more for free

@nieomylnieja
Copy link
Member

@fourstepper, as discussed, let's merge it anyway and follow up with proposals of bringing metadata in sync with k8s metadata

@nieomylnieja nieomylnieja merged commit 18dfec1 into OpenSLO:main Mar 25, 2024
1 check passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
v2alpha1 Incompatible changes proposed for the next major release
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants