fyi, filed https://github.com/grpc/grpc/issues/40576
On Tuesday, August 12, 2025 at 5:23:16 PM UTC-7 Rameshreddy Mudhireddy
wrote:
> Hi Luwei,
>
> "all audit loggers that may be used should have been registered from the
> very beginning" is very rigid, also it is not possible to know beforehand
> because it comes from customer defined "policy.json" input and it doesn't
> play well with the "hitless restart of the grpc service for any
> configuration changes" design we have. Any possible work-around to deal
> with this is appreciated.
>
> P.S: sorry for delayed response (was on Vacation)
>
> Regards
> Ramesh
>
> On Monday, July 14, 2025 at 8:35:29 AM UTC-7 Luwei Ge wrote:
>
>> The intent of the Register... API is that all audit loggers that may be
>> used should have been registered from the very beginning, because custom
>> loggers can possibly be custom implementations which need to be compiled
>> and built into the application binary. So I think the correct way to run
>> your test is to register both "foo" and "bar" at the beginning of all test
>> cases. Let me know if there is any problem with that.
>>
>> Best,
>> Luwei
>>
>> On Friday, July 11, 2025 at 7:16:33 PM UTC-7 Rameshreddy Mudhireddy wrote:
>>
>>> Test case is:
>>>
>>> If the server is setup with the following config:
>>>
>>> "audit_logging_options": {
>>> "audit_condition": "ON_DENY_AND_ALLOW",
>>> "audit_loggers": [
>>> {
>>> "name": "foo"
>>> }
>>> ]
>>> }
>>>
>>> Any subsequent grpc service restarts will run into assert. That can be
>>> worked-around by applications by maintaining last registered "name" handle
>>> and only call into it if there is any update but that is not ideal. If the
>>> config is changing to
>>>
>>> "audit_logging_options": {
>>> "audit_condition": "ON_DENY",
>>> "audit_loggers": [
>>> {
>>> "name": "bar"
>>> }
>>> ]
>>> }
>>>
>>> then there is no way to avoid the assert. May be I am missing something?
>>>
>>> Thanks,
>>> Ramesh
>>>
>>> On Saturday, July 12, 2025 at 6:46:44 AM UTC+5:30 Rameshreddy Mudhireddy
>>> wrote:
>>>
>>>> Hi Luwei,
>>>>
>>>> "Are you restarting the gRPC server within your process?"
>>>> Yes
>>>>
>>>> "need to call RegisterAuditLoggerFactory again"
>>>> Yes, did call RegisterAuditLoggerFactory again and it is running into
>>>> the above mentioned grpc assert.
>>>>
>>>> Thank you for your attention on this.
>>>>
>>>> On Friday, July 11, 2025 at 11:52:40 PM UTC+5:30 Luwei Ge wrote:
>>>>
>>>>> Hi Ramesh,
>>>>>
>>>>> I am not sure if I fully understand your problem. Are you restarting
>>>>> the gRPC server within your process? If so, I think you need to call
>>>>> RegisterAuditLoggerFactory again, if you didn't.
>>>>>
>>>>> Best,
>>>>> Luwei
>>>>> On Sunday, July 6, 2025 at 5:24:32 PM UTC-7 Rameshreddy Mudhireddy
>>>>> wrote:
>>>>>
>>>>>> Hi grpc-team,
>>>>>>
>>>>>> we support hitless restart of the grpc service for any configuration
>>>>>> changes and policy audit logging interface has the following comment.
>>>>>>
>>>>>> // Registers an audit logger factory. This
>>>>>> *should only be called during // initialization*.
>>>>>> void RegisterAuditLoggerFactory(std::unique_ptr<AuditLoggerFactory>
>>>>>> factory);
>>>>>>
>>>>>> Hitless restart of the service for any changes in the policy audit
>>>>>> logging name is running into an assert and requires a process restart.
>>>>>>
>>>>>> Init sequence:
>>>>>> RegisterAuditLoggerFactory(...)
>>>>>> server_data = new ::pi::server::ServerData();
>>>>>>
>>>>>> server_data->builder.experimental().SetAuthorizationPolicyProvider(provider);
>>>>>> server_data->builder.BuildAndStart();
>>>>>>
>>>>>> shutdown sequence:
>>>>>> server_data->server->Shutdown(<5 sec deadline>);
>>>>>> delete server_data;
>>>>>>
>>>>>> Issue:
>>>>>> E0706 17:12:26.951911933 385451 audit_logging.cc:57]
>>>>>> ASSERTION FAILED: registry->logger_factories_map_.emplace(name,
>>>>>> std::move(factory)).second
>>>>>>
>>>>>> Is there any way to avoid process restart for any of the policy
>>>>>> audit logging config changes? Appreciate your input.
>>>>>>
>>>>>> Thank you,
>>>>>> Ramesh
>>>>>>
>>>>>
--
You received this message because you are subscribed to the Google Groups
"grpc.io" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion visit
https://groups.google.com/d/msgid/grpc-io/790bbcd9-4433-490f-a472-e573a9fe65a0n%40googlegroups.com.
