feat(acme): support redis namespace

[catbro666]

Summary

This PR relies on fffonion/lua-resty-acme#101

namespace will be treated as a prefix of key and is default to empty string "" for backward compatibility. namespace must not be prefixed with any of the reserved words.

Checklist

• The Pull Request has tests
• There's an entry in the CHANGELOG
• There is a user-facing docs PR against docs(acme): support redis namespace docs.konghq.com#5366

Full changelog

• Acme plugin now supports configuring namespace for redis storage which is default to empty string for backward compatibility.

Issue reference

KAG-615

[fffonion]

let's make sure to communicate with koko team on this constraint to ensure it doesn't get missed

[catbro666]

OK, will inform the koko team on the JIRA ticket.

[fffonion]

merge on green

[hbagdi]

@fffonion @hanshuebner @catbro666 Why was this PR merged without a corresponding documentation PR?

[hbagdi]

@catbro666 Please open the corresponding EE PR.

[catbro666]

Opened the corresponding EE/DOC PR.

[hbagdi]

@hanshuebner @catbro666 Why was this commit merged without any tests that assert that the namespace parameter is used and takes effect or not?

[catbro666]

@hbagdi Because the storage_config is passed directly to the bottom library. There's nothing special about the namespace parameter compared to the other parameters. So I think the current tests can ensure that it takes effect.

[hbagdi]

Is there a test that proves that the configuration parameter is correctly passed down to the library?

[hbagdi]

ping @catbro666

[catbro666]

@hbagdi Sorry, I may have misunderstood you before.

any tests that assert that the namespace parameter is used and takes effect or not?

I think this test can cover this. It creates 3 namespaces, one default and two specified. They can work independently and don't interfere with each other.

[hbagdi]

That test tests that the library can take namespace as an input and that there is isolation between namespaces.
It doesn't prove that if a user configures a 'namespace' in the acme plugin configuration, the code in this repository will indeed configure the library accordingly.
In other words, there is no test that would fail if the namespace configuration input is ignored by Kong and not passed into the underlying library.

Does that make sense?

[catbro666]

It doesn't prove that if a user configures a 'namespace' in the acme plugin configuration, the code in this repository will indeed configure the library accordingly.

@hbagdi Indeed, that test can't prove this. But this part is a common logic shared by all storage and independent of the specific storage implementation. The storage configuration is transparent to the plugin, the plugin just simply passes it down to the library. As for proving the storage_config can be successfully passed to the library, we already have corresponding tests in 01-client_spec.lua and 03_access_spec.lua.

In my opinion, if the parts of a system are orthogonal to each other, we can test them individually. If we test everything at the top level, the number of combinations will explode.

[hbagdi]

As for proving the storage_config can be successfully passed to the library, we already have corresponding tests in 01-client_spec.lua and 03_access_spec.lua.

I'm struggling so please bear with me.
I don't see a unit test that ensures that the configuration from the schema is translated into the configuration table passed down to the underlying library correctly.

[catbro666]

@hbagdi Added tests in this PR to ensure that the namespace parameter is used and takes effect.