-
-
Notifications
You must be signed in to change notification settings - Fork 223
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
Placement scriptlet not called when moving instances between projects #1207
Comments
Btw, I know that consistency cannot be enforced everywhere. But it seems projects are designed to have different rules for consistency and moving between them should at least recheck those rules at least once. So it would make sense to call the placement scriptlet as if enforces general rules. |
Now gives:
The relocation event is what sets the final location, then the actual copy re-enters the placement logic (as it's effectively a new instance from our point of view) but this time with the fixed location. |
I just tested the move on incus 6.6 and on a move between projects, Btw, I decided not to create a new issue since it's related to this one. Should I create a new one or just keep the discussion here? |
Something is odd and I still can't quite put my finger on it. In the start of my scriptlet I have the following to print the request, the candidate members and the project.
When I copy between projects with the following
I get logged
So the project is correct and the candidate members as well. When I move between projects with the following
I get logged
So the target project is correct but the candidate members is not. When I move or copy to another project things are different. Using
in which everything is correct. Using
In which I get an incorrect list of candidate members and an incorrect request.project (which is the current project). |
When moving an instance between projects and a placement scriptlet is defined through
instances.placement.scriptlet
, it is not called to place the instance in the new project. This can lead to inconsistent configurations similar to #589 if the consistency of a configuration is checked through the placement scriptlet and user keys instead of through incus defined keys.The text was updated successfully, but these errors were encountered: