@olivierlambert
I've finally had time to sit down and do some more troubleshooting.
It seems that the issue is somehow tied to the backup-jobs themselves.
Deploying XOA and subsequently importing XO-config from my XOCE instance. I continued to see several issues between both instances.
These issues pretty much went away, when I re-did the backup-jobs from scratch. And are now much more in-line with what I'm excepting to see. This was done on both XOA Stable, Latest and XOCE

I am no longer able to repoduce this at all.
So my guess is that a bug of some sort got introduced with this being a constantly updated from source instance.

Marking as solved. As I don't believe there is much more to do at this time.

@McHenry
Differences could be things such as:

• Amount of cores between hosts for migrations
• Guarantee performance between guests. So that they don't affect each other as much.

Same with overprovisioning dynamic RAM

@McHenry
Differences could be things such as:

• Amount of cores between hosts for migrations
• Guarantee performance between guests. So that they don't affect each other as much.

Same with overprovisioning dynamic RAM

@olivierlambert
I've finally had time to sit down and do some more troubleshooting.
It seems that the issue is somehow tied to the backup-jobs themselves.
Deploying XOA and subsequently importing XO-config from my XOCE instance. I continued to see several issues between both instances.
These issues pretty much went away, when I re-did the backup-jobs from scratch. And are now much more in-line with what I'm excepting to see. This was done on both XOA Stable, Latest and XOCE

I am no longer able to repoduce this at all.
So my guess is that a bug of some sort got introduced with this being a constantly updated from source instance.

Marking as solved. As I don't believe there is much more to do at this time.

Experimenting in the lab.
Using
XCP-NG: 8.3 (yum upgraded)
XO Source: a5967

I have Rolling Snapshots set. And it seems that regardless of what the retention is set too. Older snapshots are not cleaned up/removed.
In the screenshots below you'll see that I have set it to 2. But the number of [XO Backup Rolling Snapshot] are more than that.

Am I doing something wrong? Am I misunderstanding something on a fundamental level? Or is this just not working as expected?

I am all ears.

Good morning

Anyone with a working SAML configuration that uses Google as the IdentityProvider? Looking more specifically to what to enter each of the field with (on both XO Source and the SAML-section on Google Workspace SAML app).

I tried somewhat yesterday, but couldn't really get it to work.

I'll be trying more during the week. But if someone could help out, it would be greatly apreciated.

PS: I've decided to not use the auth-google plugin. Since this requires to setup via the GCP-console. And I'd like to keep my SSO's consolidated in (mostly) one place.

@john-c
well, me too. But since it gets neither at the moment. And being realistic in that they can't be excpected to keep up with every distro in existance. I'll take what I reasonably can get

Update: Let me clarify. If there could be Distro specific logos, then that would be awesome. However, if we could get a generic Tux for Linux in general. Then that would cover a large part of the variants out there.

Hi

Sorry for necroposting this one.
But it felt relevant, to ask if maybe we could put some Rocky in there are well?

On my lab VMs I'm running Rocy8.9 at the moment. But If we could just get "rocky" in general with a generic Tux as the symbol, then that would be more than good enough.

xe vm-param-list uuid=LARGESTRING | grep distro
                            os-version (MRO): name: Rocky Linux release 8.9 (Green Obsidian); uname: 4.18.0-513.11.1.el8_9.0.1.x86_64; distro: rocky; major: 8; minor: 9

@olivierlambert
I am

Update:
Correction.. I run this script I pasted above. That builds the entire code AFAIK. As to what specific portions of the code that acctually get recompile. I do not know.

@julien-f
Hi,

No. I'm saying that sometimes the "About"-section in XO (source version). Doesn't show the actual commit being used. And is instead lagging behind. Even though the acctual code being compile is on the newest commit.
Removing the node_modules folder, cleared this issue. So there is some cache that doesn't always get updated with new commit versions.

@jr-m4 said in Xen Orchestra has stopped updating commits:

Hi,
Sorry for necroposting here. But just wanted to bump and let y'all know that this is still an issue.
Where right now, the About section will say that I'm on commit 7e66a. With 8 commits behind master 51f95

But doing a (several) full update according to installation instructions in the docs. git show -s, tells me that I'm on

commit 51f95b3c8590492164be38a77ad2c7bf5dc42451

Quick update:
After clearing/deleting the folder node_modules completely along with another upgrade, solved the symptom for me. However, it is quite obvious that the underlying issue isn't fixed.
It might be superfical at first glace. But as @olivierlambert said, it is quite beneficial to know which is the actual commit being used/applied.

Also for completeness sake:
I do my updates through a short script that goes through the commands listed in the official installation docs. Along with me using it as a systemd service

#!/bin/bash
git checkout . &&\
git pull --ff-only &&\
yarn &&\
yarn build &&\
systemctl restart xo-server

Hi,
Sorry for necroposting here. But just wanted to bump and let y'all know that this is still an issue.
Where right now, the About section will say that I'm on commit 7e66a. With 8 commits behind master 51f95

But doing a (several) full update according to installation instructions in the docs. git show -s, tells me that I'm on

commit 51f95b3c8590492164be38a77ad2c7bf5dc42451