Init manager checking unready targets with target-aware watchers#12035
Init manager checking unready targets with target-aware watchers#12035lizan merged 48 commits intoenvoyproxy:masterfrom
Conversation
Signed-off-by: ping sun <pingsun@google.com>
Signed-off-by: ping sun <pingsun@google.com>
|
CC @jplevyak |
Signed-off-by: ping sun <pingsun@google.com>
…view; targetHandle->name(); remove target_names_ vector Signed-off-by: pingsun <pingsun@google.com>
|
Thank you guys for the great reviews~ 'checkUnreadyTargets()' is just a basic function to check if the method could work. I am working on dumping the info to protobuf message and finally be used by admin handler. |
Signed-off-by: ping sun <pingsun@google.com>
Signed-off-by: ping sun <pingsun@google.com>
|
/wait |
lambdai
left a comment
There was a problem hiding this comment.
LGTM
Could you link the issue or address the follow up in description?
Signed-off-by: pingsun <pingsun@google.com>
Signed-off-by: pingsun <pingsun@google.com>
Sure, updated. |
Signed-off-by: pingsun <pingsun@google.com>
Signed-off-by: pingsun <pingsun@google.com>
|
New Design: |
Signed-off-by: pingsun <pingsun@google.com>
Signed-off-by: pingsun <pingsun@google.com>
Signed-off-by: pingsun <pingsun@google.com>
…r-query-unready-targets
Signed-off-by: pingsun <pingsun@google.com>
lizan
left a comment
There was a problem hiding this comment.
Thanks, this is on the right track.
…alize unreadyTargetsConfigDump Signed-off-by: pingsun <pingsun@google.com>
lizan
left a comment
There was a problem hiding this comment.
Can we split the init manager refactoring part to another PR?
But I don't think init manager's watcher
You mean 1 PR for TargetAwareWatcher and 1 PR for manager's onTargetReady? SGTM |
|
You can put both of Init manager / target to a single PR, I meant splitting this PR to the following two:
|
…r-query-unready-targets
Signed-off-by: pingsun <pingsun@google.com>
|
@lizan I've updated this PR and separated the config dump into another branch, please review the recent commit. |
|
Can you also update PR title and description? |
Signed-off-by: pingsun <pingsun@google.com>
Sure, updated. @lizan Please help review, and I will move on to the "unready target config dump" part. |
Signed-off-by: pingsun <pingsun@google.com>
I think everything is completed now~ |
|
Thanks! |
Description: Taking advantage of the new feature introduced in [#12035](#12035), which introduced quick visibility for init managers to check unready targets, this pull request adds protobuf message for unready targets and enables admin to dump configs of unready targets. An example of config dump for listeners’ unready targets is given in this pull request. Introduce ```InitDumpHandler``` with ```handlerInitDump``` method to help dump information of unready targets. Add ```dumpUnreadyTargets``` function for ```init::manager```. Risk Level: Low Docs Changes: protodoc Release Notes: Added Signed-off-by: pingsun <pingsun@google.com>
Description: Taking advantage of the new feature introduced in [#12035](envoyproxy/envoy#12035), which introduced quick visibility for init managers to check unready targets, this pull request adds protobuf message for unready targets and enables admin to dump configs of unready targets. An example of config dump for listeners’ unready targets is given in this pull request. Introduce ```InitDumpHandler``` with ```handlerInitDump``` method to help dump information of unready targets. Add ```dumpUnreadyTargets``` function for ```init::manager```. Risk Level: Low Docs Changes: protodoc Release Notes: Added Signed-off-by: pingsun <pingsun@google.com> Mirrored from https://github.com/envoyproxy/envoy @ 8aef76370877c66b09f7791f0577ca83aad7d608
Linked Issue: #11963
Description: The current init manager only knows how many registered targets are not ready via its
count_field. This pull request mainly helps init manager to check which specific targets are not ready.Key idea: Init manager stores the unready_target_name:count key-value pair in a hash map to check which registered targets are not ready. Enable passing target name into watcher's callback function.
When a new target is added into the targets list, increase the occurrence of the target's name in the hash map
++target_name_count_[target_name].When a target is ready, it informs the manager's watcher and finally, the watcher notifies the manager(that's why we need to pass a
string_view nameparameter to the manager's callback). And decrease the count of the target's name by 1.--target_name_count_[target_name].Most recent update:
[Latest Implementation] Wrapped the old ReadyFn type function into the new
TargetAwareReadyFn. NowWatcherImplcan take both types of function in its Ctor.[Outdated Implementation] Split WatcherImpl into two classes, the old one and a new
TargetAwareWatcherImpl. As we now limit thewatcher_insideManagerImplto receive astring_viewparameter, we declare it to be ofTargetAwareWatcherImpl.In the current code base, watchers are basically constructed with
std::function<void()>. In order to adopt the new feature(pass astring_viewparameter to the manager's callback, I wrote a new constructor forWatcherImplwithstd::function<void(absl::string_view)>parameter. In addition, I added aonTargetReadySendTargetName(string_view)adopted from the original callbackonTargetReady(). So now both types of callbacks are supported. I've also updated code in the constructor ofManagerImpl, and now thewatcher_of a manager is constructed with the new type of function(with string_view parameter). Therefore, the manager will always get target_name from the watcher's callback.Followup: Unready targets config dumps #12554
Risk Level: Low
The diagram below illustrates the outline of this PR
