[FEATURE] Add support for experimental codecs

[mgodwan]

Is your feature request related to a problem?

Coming from #122 (comment)

Given custom-codecs plugin is out of sandbox, any new codecs introduced should get some bake time to be tried by users before it can be marked ready for production usage. We should add some setting to allow-list a codec to be generally available. Codecs like zstd have been existing for quite a few versions, and already have seen backward compatibility handled and working. As new codecs are added (e.g. qat based), it would be helpful to enable them for production usage only after they have been vetted through some community feedback as well.

What solution would you like?

Introduce a setting which allows a codec to be marked experimental, and enabled on demand.

What alternatives have you considered?

Introduce codecs in new sandboxed plugins

[reta]

Coming from opensearch-project/OpenSearch#13992 (comment), I think we have an agreement to:

• we want to limit enable / disable controls to the custom-codecs plugin only
• we want to have enable / disable controls on individual codecs level

We have separate sources of codecs:

• Codecs SPI (that come from Apache Lucene)
• CodecService that manages codecs on OS side

The CodecService is provided by custom-codecs and it is easy to implement enable / disable controls on individual codecs level (using plugin specific settings fe). On the other side, Codecs SPI of Apache Lucene does not support any kind of codecs filtering but its usage (and impact) is somewhat limited (to be confirmed during implementation).

[sarthakaggarwal97]

@reta I think that's a good summary. Do you have an approach in mind on how to restrict the changes to custom-codecs?

[reta]

@reta I think that's a good summary. Do you have an approach in mind on how to restrict the changes to custom-codecs?

@sarthakaggarwal97 sorry for delay, I didn't forget about it but there are quite related discussions happening around the same mechanism but different subjects (opensearch-project/OpenSearch#14479), will suggest the solution once we settle on the approach.

[dblock]

Catch All Triage - 1 2 3 4 5 6

[backslasht]

Did we decide on the approach for this? We need to introduce this sooner to avoid bugs like #168.

[andrross]

I think we can introduce an allowlist-style setting in custom-codecs that gates codecs in the same way that a gate was added for the QAT codecs that checks for hardware compatibility. @reta @sarthakaggarwal97 what do you think?

[backslasht]

@andrross - While code level gate definitely helps for platform specific codecs, in addition to that can we introduce the concept of experimental feature for codecs as well?

[mgodwan]

+1 to what @backslasht and @andrross suggest here.

I think with the fix for issue #168, we've a way to define gating self contained within the plugin. We can build a List setting which contains the experimental codecs for the distro, and gate in code accordingly.

I still think we should have a way to govern this from core as well so that any new implementation need to explicitly mark them as out of experimental.