Hi, For your information G (ccd) is actively working on this topic. [1] He is in the best position to answer your questions as far as I know. :-)
[1] https://cwiki.apache.org/confluence/display/FLINK/FLIP-211%3A+Kerberos+delegation+token+framework On Tue, Jun 21, 2022 at 8:38 AM vtygoss <vtyg...@126.com> wrote: > Hi, flink community! > > > I don't know much details for KDC. Can different TaskManagers hold > different tokens? If so, driver and each worker can renew their tokens in > their respective DelegationTokenManager individually. > > > Thanks for your any replies. > > > Best Regards! > > > > 在 2022年6月21日 13:30，vtygoss<vtyg...@126.com> 写道： > > Hi, flink community! > > > I am trying to do some work on renewing DelegationToken periodically for > DelegtionTokenManager, and met some problems. > > > 1. Implementations of DelegationTokenProvider > > There seems to be only two implementations for testing defined by SPI > service: TestDelegationTokenProvider and > ExceptionThrowingDelegationTokenProvider, no hdfs or hbase. > > > 2. RPCGateway > > When the renewer thread of DelegationTokenManager in resource manager > renews tokens of all providers periodically, DelegationTokenManager > should update the tokens of all taskmanagers by RPCGateway that seems to be > the appropriate way for now. > > But the registered taskmanagers are managed by TaskExecutorManager in RM > which DelegationTokenManager don't have the pointer of. > > > So, how about using a global context to hold all necessary services, e.g. > RPCService, TaskExecutorManager or HA? > > > In my mind, RPCGateway seems to be a little clunky(just privately) for > extentions, why not thinking of the async typed message model between > driver and worker in design? > > > Thanks for any replies. > > > Best Regards! > > >
