-
Notifications
You must be signed in to change notification settings - Fork 25k
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
[Transform] Transforms with unattended flag don't create destination index unless all conditions/fields exist in source index #104146
Comments
Pinging @elastic/ml-core (Team:ML) |
Hi,
Confirm, that's the correct behavior with
That's true. In case of
In case of
I understand your concern here. Without explicit destination index creation, it is less predictable when exactly the destination index (and its aliases) will be set up.
Confirm, working as intended.
I'll need to think how such a change would fit the current codebase. |
@susan-shu-c, it seems you can achieve what you need by reverting the transform to non-unattended.
This way the transform will not be unattended (so it will create destination index just like it used to) but at the same time it will retry most of the failures indefinitely (without limit). Are there any reasons (other than indefinite retry limit) that made you switch to |
Pasting our Slack conversation for reference:
(as requested by Sophie Chang, not going to link it here as it was an internal GitHub discussion) |
I was able to reproduce the issue locally. |
FYI: I have opened a PR with the fix (#105499). |
Awesome, thank you! So with #105499 we can install packages with |
Not exactly. Creating destination index before source indices are ready is a more complex topic that we want to tackle too, but we won't have any solution for it in |
For Unattended Transforms, if we fail to create the destination index on the first run, we will retry the transformation iteration, but we will not retry the destination index creation on that next iteration. This change stops the Unattended Transform from progressing beyond the 0th checkpoint, so all retries will include the destination index creation. Fix #105683 Relate #104146
For Unattended Transforms, if we fail to create the destination index on the first run, we will retry the transformation iteration, but we will not retry the destination index creation on that next iteration. This change stops the Unattended Transform from progressing beyond the 0th checkpoint, so all retries will include the destination index creation. Fix elastic#105683 Relate elastic#104146
For Unattended Transforms, if we fail to create the destination index on the first run, we will retry the transformation iteration, but we will not retry the destination index creation on that next iteration. This change stops the Unattended Transform from progressing beyond the 0th checkpoint, so all retries will include the destination index creation. Fix #105683 Relate #104146
Description
We added the
unattended
flag to transforms shipped in integration packages (example: elastic/integrations#8320).In the past, without the
unattended
flag, once the package is installed on a fresh cluster:.latest
and.all
aliases for the destination index is created (see [ML][Fleet] Update Transform installation mechanism to support upgrade paths kibana#142920 )Now, with the
unattended
flag, on a fresh cluster:After testing on
v8.11.1
(so that this fix #101627 would be there), transforms with theunattended
flag don't seem to create the destination index like without theunattended
flag.It turns out, the destination index is only created when there is exact data that matches the criteria (e.g. fields
host.name
,destination.ip
, etc. exist inlogs-*
) for the transform to run, compared to before, the destination index can be created regardless. This gives the impression that the package hasn't fully been installed.What we want to clarify is: Is this expected behavior with the
unattended
flag?If so, can it be implemented so the behavior is the same as before (create destination index regardless of available data) so that it's clearer to users when the transform and associated indices have been created?
Related links
The text was updated successfully, but these errors were encountered: