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/202e9a3b-3e3a-4696-bf20-6930aed3a9f8n%40googlegroups.com.
