Xen Orchestra Upgrading
-
@Dashrender You mean without creating multiple backup jobs? (to avoid full disks multiplications?)
edit: final merge (ie during the import for restore purpose) is done inside XAPI and not offline.
The question is: is it possible to manage multiple/various backup time and retention by keeping only one full disk.
-
@olivier said:
@Dashrender You mean without creating multiple backup jobs? (to avoid full disks multiplications?)
Yes - Veeam and other backup vendors have this feature. I mention for example of how they do it.
-
Hmm.. Even in forever forward incremental?
edit: because we merge offline, the full disk will be modified accordingly. It will be correct for a "subjob", e.g every hour. But the base won't be anymore correct for another "subjob", let's say every day: because it's now modified by the other one.
edit: or they need to be synchronized (at the same time). Let's say every hour at the hour (3:00, 4:00) and another one every day, at 3:00. This way we could roll fully offline, by having a copy of the delta preserved for a longer time.
-
@DustinB3403 @olivier do these commands bring me to the latest stable build, or the latest beta build? I want to upgrade to the latest stable build. What folder do I run the command it or does it not matter? Do I have to run them in both folders?
-
@anonymous There is (mainly) 2 branches:
stable(which is stable
)next-release(which is like a beta branch)
To be sure you are on stable, go inside both
xo-webandxo-serverfolder and do agit checkout stable. Then, you need to rebuild withnpm iandnpm run build. -
@olivier Thanks! Now I just need to write a script and setup a cron job for automatic updates
-
@anonymous said:
@olivier Thanks! Now I just need to write a script and setup a cron job for automatic updates
Do share it when you have it built so we can vet it for you.
-
@anonymous I won't do that. Upgrade only when needed. If we change something in the DB structure, or if there is a
npmdependency problem, you Cron job could be dangerous. -
@olivier Thanks!
-
@olivier said:
@anonymous I won't do that. Upgrade only when needed. If we change something in the DB structure, or if there is a
npmdependency problem, you Cron job could be dangerous.I completely disagree. That is the entire point of a stable branch. If it is not stable, then remove the name.
-
@JaredBusch You don't get it. It's not about the XO code itself, it's all about dependencies.
Eg. by making a CRON job which
git pull(no problem) everyday but alsonpm i: that's the issue. If a related dependency changed, and even XO doesn't, you could break the software. We saw the issue recently with lodash team making a big mistake which affected a LOT of projects using it.edit: again, that's the point of XOA: packing something with QA on the software but also on dependencies. You can imagine this like a distro.
-
@olivier said:
@JaredBusch You don't get it. It's not about the XO code itself, it's all about dependencies.
Eg. by making a CRON job which
git pull(no problem) everyday but alsonpm i: that's the issue. If a related dependency changed, and even XO doesn't, you could break the software. We saw the issue recently with lodash team making a big mistake which affected a LOT of projects using it.edit: again, that's the point of XOA: packing something with QA on the software but also on dependencies.
Ok, that is more clear then. Your problem is other packages break your stuff.
This is the same problem I have with NodeBB.
-
Yes, random stuff is catching NodeBB quite often, although it has gotten loads better.
-
@JaredBusch That's a common problem is software development ^^ That's why Linux distributions exists: gathering a lot of small programs and making them working together.
-
@olivier said:
@JaredBusch That's a common problem is software development ^^ That's why Linux distributions exists: gathering a lot of small programs and making them working together.
The solution in my mind is then to have some method of controlling what
npm idoes with various versions. I believe that you can manually pull specific versions fornpmbut that is all something I only tinkered with to date. -
Yes, NPM can definitely be controlled.
-
We don't want to stick manually on version for each dependency (there is a lot of them). And what about dependencies of dependencies? That's a HUGE thing to manage manually.
-
@JaredBusch said in Xen Orchestra Upgrading:
All of @DustinB3403's fanboy enthusiasm aside, this is yet another reason why XO is not something ready for prime time in the SMB space. It is too much work.
By extension, this is also why XS is not ready for prime time in the SMB space. In this space we generally need ready built tools that take little to no fiddling to keep up to date and active.
As an ITSP, I can assure you that it is much more cost effective for my client to run Hyper-V and buy Veeam than to pay my rates setting up and maintaining something like XO.
The same goes for the in house lone wolf IT guy. His time is not free, no matter how some people look at salary employees.
Don't get me wrong, I like XS and XOA looks awesome, but for the price point, I will still recommend something stable that has been around longer (Veeam). Dropping the Price point means using XO and that is simply too much in man hours.
Just curious if @JaredBusch opinion is different or still the same?
-
Note this opinion is on XS + XO from the sources. If you pay for the turnkey version (appliance + updater + support) this comment is not relevant.
-
@olivier said in Xen Orchestra Upgrading:
Note this opinion is on XS + XO from the sources. If you pay for the turnkey version (appliance + updater + support) this comment is not relevant.
Sure, but the turnkey version for an SMB is significantly more expensive than the SMB pricing for Veeam, so....
