Thank you for this constructive argument
Have a nice day.
Thank you for this constructive argument
Have a nice day.
@markhewitt1978 Hi, thank you for your feedbacks!
We are aware that this limitation bothers a lot of users and we have plan to address that in the next major version of XO.
XO 5 was already a major improvement over its predecessor because it allows viewing and handling a much bigger infra.
XO 6 will go further in this direction by introducing a tree view and the possibility to edit and handle many objects at the same time.
@Danp That may not be directly to script but to the external environment: SMB works much better if cifs-utils
is installed on the system, something that is present on our doc but might be missing in some install scripts.
We have no animosity whatsoever regarding these scripts but we prefer our appliances (or even manual installs from our documentation) because we understand much better what's going on and it's easier to replicate and fix the issues
Regarding your idea of including the commit identifier for the source version, that's not a bad idea, a (as simple as possible) implementation in a PR would be welcome
@olivierlambert Done: https://github.com/vatesfr/xen-orchestra/commit/33b45d2eda2ce6d8071541da246bdcfd06b133b8
It's not perfect but that should help
Example:
vm.start
{
"id": "123e4f2b-498e-d0af-15ae-f835a1e9f59f",
"bypassMacAddressesCheck": false,
"force": false
}
{
"errors": [
"R620-L3: VM_REQUIRES_SR(OpaqueRef:21fa00fc-62ce-4694-8b49-fcecd600a89e, OpaqueRef:4dd615a7-9a8c-4698-aceb-c10f782321c8)",
"R620-L1: HOST_NOT_ENOUGH_FREE_MEMORY(216430280704, 18778341376)",
"R620-L2: VM_REQUIRES_SR(OpaqueRef:21fa00fc-62ce-4694-8b49-fcecd600a89e, OpaqueRef:4dd615a7-9a8c-4698-aceb-c10f782321c8)"
],
"message": "",
"name": "Error",
"stack": "Error:
at Xapi._startVm (file:///home/julien/dev/vatesfr/xen-orchestra/packages/xo-server/src/xapi/index.mjs:1358:15)
at Xapi.startVm (file:///home/julien/dev/vatesfr/xen-orchestra/packages/xo-server/src/xapi/index.mjs:1393:7)
at Api.callApiMethod (file:///home/julien/dev/vatesfr/xen-orchestra/packages/xo-server/src/xo-mixins/api.mjs:307:20)"
}
@stucamp I finally had time to investigate this, it should now be fixed
Thanks for your report!
https://github.com/vatesfr/xen-orchestra/commit/24cac9dcd5d83c3170175c9c874d0a3ae51f4e6d
Hello everyone,
We have been using Yarn 1 in XO because it had support for workspaces, which npm
lacked at the time.
But now that npm
has caught up, and Yarn 1 is frozen, I think it's time to get back to using it.
Also, we are thinking about using Turborepo instead of our own custom scripts to build the repository. This would, among others, bring caching, i.e. packages are no longer rebuilt if there were no changes.
I hope these changes will not introduce any problems (I'm thinking about https://xcp-ng.org/forum/post/54567).
I you want to test, please take a look at this PR: https://github.com/vatesfr/xen-orchestra/pull/6559
Keep me posted if you have encounter any issues
@maverick Aggressive (even passive) comments are not tolerated here.
We are doing what we can and are open to questions, suggestions and even better, contributions.
On your other thread, you are suggesting a solution, which is a better approach to this kind of problems, we'll try to look into it and if it's easy enough and does not cause other issues we may integrate it.
In the mean time, you can add the following setting to your xo-server
's config to keep the previous behavior:
[backups]
useGetDiskLegacy = true
Let us know if you have issues.
Thank you for your reports, we have pinpointed the issue and we'll fix it soon
@bberndt Thanks for your report.
I've pushed a fix: https://github.com/vatesfr/xen-orchestra/commit/ea4a888c5e73e022cf331545c8a02231cfa46f15
Please test and let me know if you have any other issues
@samgaw How did you install your XO?
@Flying9167 It's indeed not possible at this to filter which users are allowed to sign in with XO auth plugins.
At this time it should be handled at the authentication provider itself and it does not look like GitHub OAuth implementation supports it.
@mietek Hello, this is due to incompatibility between xo-cli and xo-server due a change introduced 6 months ago, you can resolve it by updating xo-server.
Another solution is to update xo-cli as the recent versions contains awork-around for old versions of xo-server.
@olivierlambert https://github.com/vatesfr/xen-orchestra/blob/master/packages/xo-server/src/fatfs-buffer.mjs
I don't remember the details exactly, but it would probably be harder to do it with a partition table.
@FabioRizzo I've updated my comment, please don't use this, it's broken and unnecessary.
@Gheppy It should be fixed, thanks for your report!
https://github.com/vatesfr/xen-orchestra/commit/b5578eadf7356098ac2fa4af63b75b18d34ba558
@prononext @mandrav The problem of empty username has been fixed in master
.
The support of email
for username field is currently in review in the PR linked in my previous message and will be available soon
Thanks for your help!
@mandrav I've just pushed a fix to prevent XO from creating users with an empty name.
Most likely your problem is that the plugin does not work with the setting username field set to email
.
Please test the branch fix-oidc-email
for a fix. Re-signing in the problematic user (if it has been created via OpenId Connect signin and has not been linked to another auth provider) should update the user name.
@hannes Full backup interval (and Force full backup in the schedule settings) forces the job to do a full export of the disk and not a delta based on a previous one.
It is not impacted by the retention as XO will always makes sure every chain has at least a full export at the beginning so that all backups are viable.
Which means you will have multiple full backups, always one at the beginning, and, those that have been triggered by the settings above.