You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In the situation where a Ref is updated in a session the Locators will create two actions for most Resources, DELETE/REVERT and CREATE/MODIFY. This will trigger in the current setup a sequence of events:
read - revert - save - read - modify - save
In a lot of the cases like VirtualService, Gateway and DestinationRule this will recreate the exact same output. That means we could detect that both 'create' and 'delete' will happen to the same resource and likely to get away with a sequence of events like:
read - (revert - modify) - save?
Why
This will lower the amount of calls required to the API server and config flushes needed by istiod.
There is a slight chance that this will also fix a strange race like condition observed on the Brno cluster.
The text was updated successfully, but these errors were encountered:
What can be improved
In the situation where a Ref is updated in a session the Locators will create two actions for most Resources, DELETE/REVERT and CREATE/MODIFY. This will trigger in the current setup a sequence of events:
In a lot of the cases like VirtualService, Gateway and DestinationRule this will recreate the exact same output. That means we could detect that both 'create' and 'delete' will happen to the same resource and likely to get away with a sequence of events like:
read - (revert - modify) - save?
Why
This will lower the amount of calls required to the API server and config flushes needed by istiod.
There is a slight chance that this will also fix a strange race like condition observed on the Brno cluster.
The text was updated successfully, but these errors were encountered: