Add documentation for new API for Node analyzers

[lukas-vlcek]

trafficstars

Description

This commit introduces documentation for new extension of Nodes API that exposes names of analysis components available on cluster node(s).

This commit also contains additional changes:

• It makes strict distinction between terms: "token" and "term".
• It replaces the term "Normalize" in analysis part because it has special meaning in this context
• It introduces a dedicated pages for Normalization (which is a specific type of analysis)

In addition to this, this PR contains two commits where the commit with title "Fix broken links" fixes some broken links on the plugin page and might be a good candidate for pack-porting.

Issues Resolved

This issue is part of https://github.com/opensearch-project/OpenSearch/pull/10296 Do not merge it if ^^ is not merged as well.

Checklist

• [x] By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license and subject to the Developers Certificate of Origin. For more information on following Developer Certificate of Origin and signing off your commits, please check here.

[lukas-vlcek]

Note: Depending on when (or if) the related PR in OpenSearch is merged then we need to update the v2.11.?? in the documentation.

[hdhalter]

Thanks, @lukas-vlcek ! This is addressing this issue, right? https://github.com/opensearch-project/documentation-website/issues/5426. Is it ready for a doc review?

We can look at the additional fixes, and backport them. Thanks for catching and fixing them!

[lukas-vlcek]

Thanks, @lukas-vlcek ! This is addressing this issue, right? #5426. Is it ready for a doc review?

@hdhalter Please see my response https://github.com/opensearch-project/documentation-website/issues/5426#issuecomment-1919374135 It is currently not part of _cat API.

[hdhalter]

Thanks, @lukas-vlcek ! This is addressing this issue, right? #5426. Is it ready for a doc review?

@hdhalter Please see my response #5426 (comment) It is currently not part of _cat API.

Thanks, @lukas-vlcek, I closed the issue related to _cat API. For this node API PR, is it going out in 2.12?

[lukas-vlcek]

@kolchfa-aws Thanks for detailed review. I updated the PR and marked all comments as resolved.

[kolchfa-aws]

Thank you, @lukas-vlcek! I'll move the PR to editorial review.

[kolchfa-aws]

@lukas-vlcek Just a couple of more suggestions to reword the headings. Thanks!

[lukas-vlcek]

@kolchfa-aws @natebower Thanks for all the reviews and feedback! I think the PR is ready and can be merged once https://github.com/opensearch-project/OpenSearch/pull/10296 is merged.

[kolchfa-aws]

Thank you, @lukas-vlcek! I will mark is as ready to merge and we'll merge this PR when the dev PR is merged.

[hdhalter]

@lukas-vlcek - Should we put this back in tech review (or draft) until you have a chance to modify it?

[lukas-vlcek]

@hdhalter I am going to update this PR. It will have two parts. One part will be general and can go upstream as soon as the docs review is finished. The second part will be relevant only to a new functionality and that can go in after the relevant code PR is merged. I will leave it up to you how you want to process this from the review process point – if you think putting it back to draft mode is way to go then let's do it. If you think it is better to handle it differently please let me know.

To me it sounds like I should open a new PR for the general part (this can go in anytime). And then I will update this PR and leave only content that is relevant to a new functionality.

[hdhalter]

@hdhalter I am going to update this PR. It will have two parts. One part will be general and can go upstream as soon as the docs review is finished. The second part will be relevant only to a new functionality and that can go in after the relevant code PR is merged. I will leave it up to you how you want to process this from the review process point – if you think putting it back to draft mode is way to go then let's do it. If you think it is better to handle it differently please let me know.

To me it sounds like I should open a new PR for the general part (this can go in anytime). And then I will update this PR and leave only content that is relevant to a new functionality.

Your suggestion to put this in draft and create a new PR for general changes sounds good to me. Thanks so much, really appreciate your support!

[lukas-vlcek]

@hdhalter Please see https://github.com/opensearch-project/documentation-website/pull/6415 That is a new PR that contains all changes except those related to a new functionality (i.e. node analyzers).

I am going to update this PR and it will contain only the node analyzers part and can be merged once the upstream code PR is merged as well (that code PR needs similar update, I will move changes note directly relevant to node changes to separated code PRs).

[lukas-vlcek]

I updated this PR. Now, it contains only part relevant to the new functionality. All the other changes has been already merged in #6415.

I have only two comments:

1. The text states that the functionality was (will be) introduced in 2.12.1. This needs to be verified before merging.
2. I am considering making the JSON response example block closed by default. It is quite a long output. I think I can only remove the open attribute of the detail element. Let me know what you think.

//cc @kolchfa-aws @hdhalter

[kolchfa-aws]

@lukas-vlcek Thanks for doing this! We'll update the version text before merging. I agree with making long requests/responses closed by default. You can change "open" to "closed' to achieve that.

[lukas-vlcek]

@kolchfa-aws

You can change "open" to "closed' to achieve that.

I was inspecting the life HTML document in chrome and it seemed that there is no closed option added to the details element when it is closed. There was either open or nothing... just nitpicking... the FORMATTING_GUIDE.md#collapsible-blocks does not specify this situation either.

[lukas-vlcek]

BTW, WRT the version, the feature seems to be scheduled for 2.13, see https://github.com/opensearch-project/OpenSearch/issues/5481#event-11779857606

[kolchfa-aws]

You're right. It's closed by default and you add the open state to have it open. https://developer.mozilla.org/en-US/docs/Web/HTML/Element/details. I'll add it to the formatting guide.

[lukas-vlcek]

@kolchfa-aws I updated the details element, removed the open attribute.

[kolchfa-aws]

@lukas-vlcek Do you think this feature will be included in 2.13?

[lukas-vlcek]

@kolchfa-aws Unfortunately not, I did not make it. Sorry about that. Let's plan it for 2.14.

[Naarcha-AWS]

@lukas-vlcek: Is this still targeting 2.14?

[kolchfa-aws]

@Naarcha-AWS I'm back so I'll take this PR from here. Thank you!

[kolchfa-aws]

@lukas-vlcek Do you know if this is going into 2.15?

[hdhalter]

Assuming this is not going in 2.15, since @reta removed the 2.15 label from https://github.com/opensearch-project/OpenSearch/pull/10296.