-
Notifications
You must be signed in to change notification settings - Fork 8
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
feat: Kyma stats receiver #45
Conversation
Co-authored-by: Nina Hingerl <[email protected]>
…try-collector-components into kymastats-receiver
…try-collector-components into kymastats-receiver
/hold |
return nil, &fieldNotFoundError{"state"} | ||
} | ||
|
||
unstructuredConds, found, err := unstructured.NestedSlice(status, "conditions") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
are conditions really mandatory (included in the kyma module contract)?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There is no kyma module contract about the status conditions
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
And with that they are not mandatory
return nil, errors.New("condition is not a map") | ||
} | ||
|
||
condType, found, err := unstructured.NestedString(condMap, "type") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
all the following code is based on the expectation that the conditions implement fields similar to metav1.conditions. This is not mandatory. We should not fail if a module either does not implement conditions at all, or if those conditions do not follow the same patterns as metav1.conditions (even though it is recommended that conditions are based on metav1)
Here are all requirements that i could find: https://github.com/kyma-project/template-operator?tab=readme-ov-file#api-definition-steps
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We assume that the CR has metav1.condition
implementation. When a CR has no metav1.condition
implementation is not scrapeable
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
so in the end, even though there is no real contract (and it would be quite simple for us to exclude the conditions for such modules) we just fail with scraping for those modules?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In case a module doe not have conditions or is not following the conventions, we should just skip that part, the same way as we skip when we cannot find a resource for a module CRD
Description
Changes proposed in this pull request (what was done and why):
kymastatsreceiver
Telemetry
module status, and emit two metricskyma.module.status.conditions
andkyma.module.status.state
Changes refer to particular issues, PRs or documents:
Traceability
area
andkind
label.Related Issues
section.