Curator logging weirdness

[elasticus]

Curator logs 'no actionable items in list' as an ERROR - I don't see this as an 'error' and would like to suppress it?
Also - Curator logs the index it will reallocate routing (hot to warm) on a dry-run - useful - but not on the actual run - not so useful.

Curious if anyone has come up with a way of handling either or both of the above.

[theuntergeek (Aaron Mildenstein)]

@elasticus

I don't see this as an 'error' and would like to suppress it?

Curious if anyone has come up with a way of handling either or both of the above.

You can go around this in Curator with the ignore_empty_list option.

This option was added expressly for the cases where you want Curator to continue even if no indices were in a list. This separation had to be made from the regular continue_if_exception which catches all other kinds of exceptions. However, the truth is, to Curator, an empty list condition is an error. It cannot proceed without the ignore_empty_list option. There is no way to suppress this message, or change it to not be an error.

@elasticus

Also - Curator logs the index it will reallocate routing (hot to warm) on a dry-run - useful - but not on the actual run - not so useful.

A dry_run needs to show the user exactly what will happen with a dry run. The disparity comes from the fact that the dry_run does its own iteration over the values, separate from the regular action. They do not share the same code

The allocate action does still log what's happening when it does the action, but the appearance is different from the dry_run output because it is applying the settings in a batch, rather than index by index.

[elasticus]

Thanks - indeed I found the ignore_empty_list option (which I was already using within my delete action.
I guess If I really really really want the indices that will be moved etc captured in the log I could always just run a dry-run immediately before the actual run

[theuntergeek (Aaron Mildenstein)]

I can also add logging inside the loop and show the body and index list, but that will only be debug-level, as it is very noisy. I could also put "non-dry-run" logging in there to show what's about to happen. I worry a bit about doing that users will think that the action is happening when it sees the logs, but it could be useful to see.