-
Notifications
You must be signed in to change notification settings - Fork 386
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
Traceflow spec update is not handled properly #5255
Comments
I think option 2 is more reasonable considering Traceflow is an ephemeral objects. I feel it's better to involve this change after Traceflow API promotion is done in #5108. |
I guess live-traffic traceflows are not always that "ephemeral". Someone may create a live-traffic traceflow using a yaml file, realize they made a typo in one of the filters, edit the yaml file and re-apply it. In this case, preventing spec updates would lead to a failure. However, even option 2 is better than the current behavior of ignoring user updates IMO. |
The behaviors of
|
This issue is stale because it has been open 90 days with no activity. Remove stale label or comment, or this will be closed in 90 days |
Currently, the traceflow update event handling only considers the cases where the controller and agent update the status, but it doesn't account for the scenario where the user actively updates the spec (e.g., modifying the destination pod in the traceflow spec).
I have two possible solutions:
Personally, I prefer the second solution because it is simpler and can avoid some problems. For example, if we adopt the first solution, if the traceflow is already in progress, should we preserve the collected data when changing the spec?
The text was updated successfully, but these errors were encountered: