Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[BUG] ISM Allocation action does not match Opensearch server expectation #591

Closed
kellen-miller opened this issue Jul 17, 2024 · 1 comment · Fixed by #609
Closed

[BUG] ISM Allocation action does not match Opensearch server expectation #591

kellen-miller opened this issue Jul 17, 2024 · 1 comment · Fixed by #609
Labels
bug Something isn't working

Comments

@kellen-miller
Copy link
Contributor

kellen-miller commented Jul 17, 2024

What is the bug?

I'm attempting to unmarshal a json file containing an ISM policy into the ism.Policy struct. The documentation for the allocation action specifies that the require value be of type string. This is also the type that the go struct's require value is.

However in the example in the docs, it shows that the value really should be an object.

    "allocation": {
      "require": { "temp": "warm" }
    }

and this is also what is expected by the Opensearch server.

If I encode the json as a string, i.e. "{ \"temp\": \"warm\" }", I can then marshal it into the go struct, but the server will then throw a parsing error saying that it expects an Object, not a String.

A similar thing happens with the wait_for field. The docs and go struct specify it needs to be a string, but the server expects a bool.

How can one reproduce the bug?

Attempt to json marshal the below json into an ism.Policy struct.

policyContent

{
    "policy": {
        "description": "hot warm workflow",
        "default_state": "hot",
        "schema_version": 1,
        "states": [
            {
                "name": "hot",
                "actions": [
                    {
                        "rollover": {
                            "min_index_age": "1d",
                            "min_size": "1gb"
                        }
                    }
                ],
                "transitions": [
                    {
                        "state_name": "warm",
                        "conditions": {
                            "min_rollover_age": "1m"
                        }
                    }
                ]
            },
            {
                "name": "warm",
                "actions": [
                    {
                        "allocation": {
                            "require": {
                                "temp": "warm"
                            },
                            "wait_for": false
                        }
                    }
                ]
            }
        ],
        "ism_template": [
            {
                "index_patterns": [
                    "myindex*"
                ],
                "priority": 100
            }
        ]
    }
}

What is the expected behavior?

The above json is what the opensearch server expects. If you directly send the above json to the server like so, it will succeed.

        // create ism client, open policy json file above and load policyContents
        
	req, err := opensearch.BuildRequest(http.MethodPut,
		"/_plugins/_ism/policies/myindex_policy",
		strings.NewReader(policyContents),
		nil, nil)
	if err != nil {
		return fmt.Errorf("failed to create ISM policy request for myindex: %w", err)
	}

	resp, err := ismClient.Client.Perform(req)
	if err != nil {
		return fmt.Errorf("failed to create ISM policy for myindex: %w", err)
	}
	if resp.StatusCode == http.StatusCreated {
		return nil
	}

I think the documentation needs to be updated to say that it accepts an object, which would allow the go struct value to be a type of map[string]string or json.RawMessage or whatever is deemed fit.

What is your host/environment?

Operating system, version.

Do you have any screenshots?

If applicable, add screenshots to help explain your problem.

Do you have any additional context?

Add any other context about the problem.

@kellen-miller kellen-miller added bug Something isn't working untriaged labels Jul 17, 2024
@dblock dblock removed the untriaged label Aug 5, 2024
@dblock
Copy link
Member

dblock commented Aug 5, 2024

[Catch All Triage - 1, 2, 3]

There's an effort to generate some of this from spec @kellen-miller, see #284. Would be helpful if you want to ensure these APIs are present and properly documented in the spec itself?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants