-
Notifications
You must be signed in to change notification settings - Fork 2.3k
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
Indicate in component readme if the component is stateful or stateless #18878
Comments
We already have a definition of statefulness in our docs on the standard warnings list and some components (not many) have this in a separate row example. I think we can use this issue to track adding that row for other components. |
This "Warnings" row seems to explicitly call out some risks of using the component, but is being statless or stateful something to warn about? |
Thanks for the tip, @mx-psi. I have a few thoughts/questions:
|
Maybe 'Warnings' is too strong of a word, but the intention was to list properties of a component that require special attention/restrict the kinds of deployments where it can be used. Statefulness usually means e.g. you have to ensure a given producer of telemetry data needs to send all their data to the same Collector instance, so it does require special attention and thus fits in there with the other 'warnings'. If you think there's a better name for this or that we should make a distinction between different kinds of warnings that would be great to improve, I am just trying to point out the existing work on this area.
We can iterate on the existing definition on the 'Statefulness' subsection here and spell out the implications more clearly.
Agreed that these are important, having notes about how a 'warning' applies to a component makes sense to me. cc @TylerHelmuth who may have opinions on this :) |
I would argue Statefulness is something to Warn about. Statefulness in a component has a huge impact on how you architect your collector deployments. If you use a Stateful component without understanding how it impacts your use of the collector you will most likely end up with flawed data. But the dangerous part of a stateful component is that it can't tell you that you're using it wrong. If you use the cumulativetodeltaprocessor in deployment with multiple pods and metrics end up on different pods it will never tell you that the math its performing isn't accurate anymore. Similarly if you use the tailsamplingprocessor and send spans to a different collectors the processor won't know that its missing spans. Instead in both situations you'll have to catch the issue at the place your exporting the data, which could be difficult. I think the Here are the 2 PRs where this worked started:
If Warnings is too strong we had started with |
I'm for the status quo, I quite like "warnings" here for the same reason @TylerHelmuth mentioned above. |
The issue I have with "Warnings" is that we wouldn't warn that a component is stateless. I would want to document that a component is stateless explicitly rather than just document that some are stateful to make it more uniform and also provide a strong signal to readers that committers have thought through this and want to signal this component is usable as stateless. If you don't say it's stateful or stateless, then I as a reader would make the assumption the developer has not spent the time to identify that characteristic. |
@atoulme thats fair, the danger is definitely with I have definitely been operating under the assumption that components are |
+1 |
OK. Can I negotiate something here? I’d like that beta components display the warning row as a requirement for beta accession, and make sure owners label state expectations then. So if nothing is listed, it’s default stateless and someone looked into it for sure as part of beta requirements. |
@atoulme I think that works. Are you free to bring this discussion to the SIG meeting tomorrow? |
I will be there. |
This issue has been inactive for 60 days. It will be closed in 60 days if there is no activity. To ping code owners by adding a component label, see Adding Labels via Comments, or if you are unsure of which component this issue relates to, please ping |
This issue has been inactive for 60 days. It will be closed in 60 days if there is no activity. To ping code owners by adding a component label, see Adding Labels via Comments, or if you are unsure of which component this issue relates to, please ping |
Should we close this in favor of #19172 ? |
I believe we can. |
Component(s)
No response
Is your feature request related to a problem? Please describe.
We want to document if a component is stateful ir stareless to help users make the best decision when scaling up the collector.
Describe the solution you'd like
I propose adding a state row to components README files indicating if they are stateless or stateful.
we also can define what stateless and stateful means in our docs or even at the specification level.
Describe alternatives you've considered
No response
Additional context
No response
The text was updated successfully, but these errors were encountered: