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

resident_on information in task at change watch shows in pool always the master #3870

Open
Winteriver opened this issue May 19, 2019 · 5 comments · Fixed by #4022
Open

resident_on information in task at change watch shows in pool always the master #3870

Winteriver opened this issue May 19, 2019 · 5 comments · Fixed by #4022

Comments

@Winteriver
Copy link

When watching changes with the xapi, all hosts of a pool receive all informations from every other host in that pool.

For example, when a snapshot is made at a slave of a Pool, the slave(s) and the master receive a task like:

{
allowed_operations: []
backtrace: "()"
created: "20190519T19:39:24Z"
current_operations: {}
error_info: []
finished: ""
name_description: ""
name_label: "VM.snapshot"
other_config: {}
progress: 1
resident_on: "OpaqueRef:36d4e8fd-7a8f-49c1-a9e8-4e38940a1302"
result: ""
status: "pending"
subtask_of: "OpaqueRef:NULL"
subtasks: []
type: "<none/>"
uuid: "65ace88c-b425-2b16-e6f8-1f7d407dcfbb"
}

Here - after my opinion - "resident_on" should display on which hosts that task has been started, like the documentation says:
http://xapi-project.github.io/xen-api/classes/task.html
"host ref resident_on - the host on which the task is running"

So "resident_on" should be the OpaqueRef of the slave, but it always shows the OpaqueRef of the master. This way it is not possible to assign the tasks to the right host.

The "resident_on" is working at the VMs and other stuff, but not with the tasks. Why? Is this a bug, or a feature? :D

@lindig
Copy link
Contributor

lindig commented May 20, 2019

I suspect resident_on is set here:

https://github.com/xapi-project/xen-api/blob/master/ocaml/xapi/taskHelper.ml#L43

It is set to the localhost where it is created and not modified, as far as I can see. I agree that this would provide more value when it would point to the host that executes a task.

@Winteriver
Copy link
Author

Thank you very much for you response!
When you agree that it would provide more value when it would point to the host that executes a task, would you be so kind to put it on the agenda for a upcoming version? I really wish I had the possibility to sort the tasks to the correct hosts. That would be a dream.
Thanks in advice and thanks for providing us this wonderful piece of Software.

@lindig
Copy link
Contributor

lindig commented May 21, 2019

I'll raise (tomorrow) an internal ticket to track this. However, the best way to get this done would be to work on this and raise a pull request.

@Winteriver
Copy link
Author

Winteriver commented May 21, 2019

Thanks for your (fast) response and for raising a ticket!
I'm a (backend) developer for node.js using typescript. I do this for a few years now - I wrote lines of Java, know how to handle Python, and C(#) (Google is your friend...) and I would even give this thing a try but before that I have some questions :D
Please do not kill me but, *.ml is not C#, what language is this, F#?
You said:
"It is set to the localhost where it is created and not modified"
Why is the task for a slave even created on the master and not on the slave itself?

@lindig
Copy link
Contributor

lindig commented May 22, 2019

I have created ticket CA-319021 for internal discussion and tracking.

@lindig lindig linked a pull request Feb 7, 2020 that will close this issue
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants