admin: downgrade identical-license log from info to debug

[david-yu]

Problem

When an operator re-applies the same enterprise license via PUT /v1/features/license, the handler detects it is a no-op (the loaded license is identical to the one in the request) and returns 200 OK without invoking the feature manager. This idempotency behaviour is intentional.

However, the log emitted on this path was at info level:

admin_api_server - server.cc:2631 - Attempted to load identical license, doing nothing: [Version: 0, Organization: Deloitte, Type: enterprise, Expiry(epoch): 1807834065]

Clusters that periodically re-apply their license (e.g. via an operator or automation script) generate this message on every application, filling customer logs with what looks like a warning even though nothing went wrong. Several customers have flagged this as noise.

Solution

Downgrade the log from info to debug. Operators who want visibility into the idempotency path can enable debug logging for admin_api_server; production logs are clean by default.

Related

This change supersedes the operator-side approach explored in redpanda-data/redpanda-operator#1408, which was closed after analysis concluded: it would save a bit on API calls potentially, while adding to storage and moving the hashing logic client-side. Since core already handles the update as a no-op, the less logic we put in the operator and the more we leverage it mainly for lifecycle orchestration, the better and less brittle it is. Fixing the log level here in core is the simpler, more appropriate fix.

Test plan

• New unit test feature_table_identical_license_idempotency in //src/v/features/tests:feature_table_test verifies the license-equality comparison that gates this path: same license matches, mutated license does not
• bazel test //src/v/features/tests:feature_table_test passes
• bazel build //src/v/redpanda/admin:admin passes

Release Notes

Improvements

• Downgrade the Attempted to load identical license, doing nothing admin API log from info to debug to reduce log noise when operators or automation re-apply the same enterprise license on a schedule.

Generated with Claude Code

[david-yu]

Marking ready for review based on discussion in help-core.

[david-yu]

Ok not to backport as this is a behavior change.

[WillemKauf]

The historical reason for this log line being at INFO is documented in #8195:

Fix for an issue that manifested to a customer in newer versions of redpanda, where licenses could not be re-uploaded. The cause occurres when comparing two security::licenses via operator==.

So if there was still a bug here, it would go un-reported/undetectable to the user based on the 200 response back from the server. Or, if the user was trying to load a new license but accidentally provided the wrong (previous) license.

I don't have a strong enough feeling that this is a huge issue and we can't just merge this, but I do think that its a tricky situation to solve for all cases (even with say, a rate limited log line) and the potential user pitfall with silencing this log line is going to be present.