Issue identified.
@spelon If you're using XO from source, you can try this mra-fix-undici-xen-api branch, otherwise, feel free to open a tunnel so I can fix your XOA.
Issue identified.
@spelon If you're using XO from source, you can try this mra-fix-undici-xen-api branch, otherwise, feel free to open a tunnel so I can fix your XOA.
@acebmxer If you can open a support ticket with a tunnel, it would be nice. I am not able to reproduce in my lab nether on our QA lab
@acebmxer Thank you for your quick feedback.
Hi @acebmxer,
Can you test if the branch: fix_cloudinit_import fix your issue?
Edit: It is available on the master branch.
Hi @dvdwx,
RBAC is available only at the REST API level, not through the XO6 UI. UI compatibility with RBAC is currently under development.
For the topology, this is something that has been here for a long time, so I may be wrong since I don't have the full history. However, if I look at the code, creating the topology selector requires knowing how many CPUs are available in the pool.
Since a self-service user doesn't have visibility into the pool, they can't access this kind of information.
Hi @DevFlint,
tasks are now correctly visible in the swagger documentation
Hi @slavavrn,
FYI, its now possible to revert a snapshot via the REST API.
POST /vms/:id/actions/revert_snapshot
And the body of the endpoint:
{
"snapshotId": <snapshot-id>
"snapshotBefore": boolean (optional)
}
Hi @johnnezero and thanks for the post!
Just wanted to talk about PERMISSION SYNC.
In the REST API the "permission sync" pattern is actually handled natively by the RBAC system using selectors.
For example, if you want a role that allows a user to manage VM power state only for VMs tagged dev:
tags:devOnce done, the access is fully dynamic:
dev tag is included in the scopeThe key point is that RBAC evaluates privileges at request time based on selectors.
You can also base selectors on other VM properties, not only tags (for example power state, name patterns ...).
You can find the doc here
and a dedicated forum thread here
PS: For the moment the XO6 UI does not support the RBAC system, but we are working on it 
Hi @rzr,
When you say, "XO still showed host 2 needing patching", does that mean XO is still showing missing patches?
If so, can you run the following command: xe host-call-plugin host-uuid=<uuid-host2> plugin=updater.py fn=check_update
Hi @r0123456789,
GET /rest/v0/hosts/:id/stats is available in the REST API
Hi @dan89,
It is possible to create an authentication_token using the REST API.
POST /rest/v0/users/me/authentication_tokens
Hi @Steve_Sibilia,
FYI, ACL V2 / RBAC is now available in the REST API.
You can see the RBAC doc.
A dedicated thread is available on the forum thread, please feel free to share your feedback.
Thank you.
Hi @jedimarcus,
FYI, VIF creation is possible via the REST API POST /rest/v0/vifs
Hi, @14wkinnersley
We merged the PATCH /vms/:id endpoint onto the master branch
@acebmxer Hi
i am able to reproduce the dashboard issue locally now, so we can also investigate on our end.
Can you confirm, no dashboard issue on the commit : ee53cd072304a38e8bf816dceef9bc7277b776dc?
@acebmxer I remeber some users experiencing issues with XO6 due to a misconfigured NGINX reverse proxy (it was blocking SSE, which XO6 uses).
Is your reverse proxy configured correctly?
I won't have time to examine the script myself
@acebmxer Thank for your investigation.
install-xen-orchestra.sh, but the link seems dead. What is that script, it is a script provided by Vates?To reproduce dashbloard loading issues, we have to:
admin@admin.net, and create another useradmin@admin.net)Symptom: Every browser session token fails immediately after login. Seconds after logging in, xo-server logs
Only browser session that use the deleted account fails, or even sessions with untouched users?
After that, the issue occures even if we logout/login with the new user?
@acebmxer Thanks!
What's strange is that the previous log shows a 401 status code for the /schedules endpoint, but you can access it.
The xo:rest-api:listener ERROR cannot handle data for task list> error is also odd.
You say you only have one user, but it seems you had several before, right?
Could you try logging out and then logging back in?
Is there perhaps a bug during user deletion that would keep some active but malfunctioning authentication tokens?