[rule based autotagging] Add Create Rule API Logic

[ruai0511]

Description

This PR introduces the create Rule API Logic.

An exampe API request is:

curl -XPUT "localhost:9200/_rules/workload_group"  -H 'Content-Type: application/json' -d '     
{
    "description": "description",
     "index_pattern": ["log*", "event*"],
     "workload_group": "EITBzjFkQ6CA-semNWGtRQ"
}'

And the return would be

{
   "_id":"Kqqra5YBzZOW_5Q0ALDc",
   "description":"description",
   "index_pattern":["log*", "event*"],
   "workload_group":"EITBzjFkQ6CA-semNWGtRQ",
   "updated_at":"2025-04-25T06:38:10.787Z"
}

Rule Schema PR:
#17238
RFC:
#16797

Check List

• Functionality includes testing.
• API changes companion pull request created, if applicable.
• Public documentation issue/PR created, if applicable.

[github-actions]

❌ Gradle check result for 90e2b4c: FAILURE

Please examine the workflow log, locate, and copy-paste the failure(s) below, then iterate to green. Is the failure a flaky test unrelated to your change?

[github-actions]

❌ Gradle check result for 85ea24e: FAILURE

Please examine the workflow log, locate, and copy-paste the failure(s) below, then iterate to green. Is the failure a flaky test unrelated to your change?

[github-actions]

❌ Gradle check result for e215963: FAILURE

Please examine the workflow log, locate, and copy-paste the failure(s) below, then iterate to green. Is the failure a flaky test unrelated to your change?

[github-actions]

❌ Gradle check result for e0c9c06: FAILURE

Please examine the workflow log, locate, and copy-paste the failure(s) below, then iterate to green. Is the failure a flaky test unrelated to your change?

[github-actions]

❌ Gradle check result for c6e7250: FAILURE

Please examine the workflow log, locate, and copy-paste the failure(s) below, then iterate to green. Is the failure a flaky test unrelated to your change?

[github-actions]

✅ Gradle check result for dbe2e18: SUCCESS

[kaushalmahi12]

Some minor comments, LGTM! overall. We should focus on test coverage though

[kaushalmahi12]

lets replace query_group with workload_group wherever applicable

[kaushalmahi12]

We are chaining a lot of method calls in this statement, this can potentially result in NPE. Have we thought of the scenarios when this can be null ?

[kaushalmahi12]

[NIT] name change

[kaushalmahi12]

I think DuplicateRuleChecker is more appropriate name.

[kaushalmahi12]

Lets add more context for this class. I think this is not a simple string format and length checker but rather it validates the value against the pre-stored feature values (index, cluster state ....etc).

[kaushalmahi12]

I think we can write this in a better way, Lot of action listener chaining is unnecessary

if (indexDoesNotExist) {
    createIndex(listener); //this is a method listener
} else {
    saveRule(listener);
}

private void createIndex(ActionListener<CreateRuleResponse> listener) {
     final CreateIndexRequest request = new CreateIndexRequest(indexName).settings(indexSettings);
            client.admin().indices().create(request, new ActionListener<>() {
                @Override
                public void onResponse(CreateIndexResponse response) {
                    if (!response.isAcknowledged()) {
                      throwError;
                    } else {
                        saveRule(listener);
                    }
                }

                @Override
                public void onFailure(Exception e) {
                    if (e instanceof ResourceAlreadyExistsException) {
                       saveRule(rule, listener);
                    } else {
                        logger.error("Failed to create index {}: {}", indexName, e.getMessage());
                        listener.onFailure(e);
                    }
                }
            });
}

[github-actions]

❌ Gradle check result for 9a706c2: FAILURE

Please examine the workflow log, locate, and copy-paste the failure(s) below, then iterate to green. Is the failure a flaky test unrelated to your change?

[kaushalmahi12]

LGTM! just need to address/answer the two questions

[kaushalmahi12]

I believe it will be abnormal behavior when feature validator is null hence we should at least log the instance or throw exception.

[ruai0511]

Right. Yesterday, I thought it made sense for featureValueValidator to be null if a feature type didn’t need any validation. But thinking about it more now, it’s better if featureValueValidator is always present. If a feature type doesn’t actually need validation, its validate() method can just do nothing or return null (although i doubt if any feature value doesn't need validation)

[kaushalmahi12]

Will we always get only this exception if the index already exists or e can be something different as well

[ruai0511]

Based on this I believe it'll always be ResourceAlreadyExistsException

[github-actions]

❌ Gradle check result for d70aa32: FAILURE

Please examine the workflow log, locate, and copy-paste the failure(s) below, then iterate to green. Is the failure a flaky test unrelated to your change?