Testing oVirt...
-
@dyasny said in Testing oVirt...:
@fateknollogee take a look at vprotect. They know what they are doing
I already did.
I'm waiting to test the next release (ETA is 2 weeks).
The new release will do incremental on standalone KVM hosts. -
@dyasny How, if I may ask, do you know about vProtect?
-
Also waiting for this beta to drop: https://www.trilio.io/triliovault/
-
@fateknollogee I used to be very involved with everything RHEV and oVirt a while ago. From the time they were called SolidIce in fact
-
@dyasny said in Testing oVirt...:
@fateknollogee I used to be very involved with everything RHEV and oVirt a while ago. From the time they were called SolidIce in fact
You say "used to", does that mean you are currently not?
-
@dyasny said in Testing oVirt...:
@fateknollogee I used to be very involved with everything RHEV and oVirt a while ago. From the time they were called SolidIce in fact
What's your take on oVirt?
-
@fateknollogee I left the project a few years ago, moved on to Openstack and the k8s related stuff. And right now I'm into big data and nosql
-
@fateknollogee I'm not objective, being there almost from the start. I know people who have been running it for almost a decade now in production and are quite happy with it though. It would really depend on your use case and budget of course
-
Thanks for the honesty.
-
@fateknollogee if you have a specific use case in mind I can help with that.
-
@dyasny said in Testing oVirt...:
@fateknollogee if you have a specific use case in mind I can help with that.
My plan it to migrate all my workloads from Hyper-V to oVirt.
Everything from basic servers, SQL, VOIP etc. -
@fateknollogee you will have to plan the setup properly if you don't want surprises. I'd be keeping away from gluster and hosted engine for example, especially in a large setup.
-
@dyasny All my testing has been HE & gluster!
-
@fateknollogee well, there you go then
-
@fateknollogee said in Testing oVirt...:
@aaronstuder said in Testing oVirt...:
@fateknollogee said in Testing oVirt...:
In the next release (which will 4.2.7), you'll be able to deploy a single node install from Cockpit UI.
But not on Fedora
No Fedora support
Regretfully, Fedora is not supported anymore, and RPMs for it are not provided. These are still built for the master branch, so users that want to test them, can use the nightly snapshot. At this point, we only try to fix problems specific to Fedora if they affect developers. For some of the work to be done to restore support for Fedora, see also tracker bug 1460625.oVirt Node 4.3 will have Fedora.
Finally, woot!
-
@scottalanmiller why this obsession with Fedora? If you are building a production cluster, CentOS is the obvious choice
-
@dyasny said in Testing oVirt...:
@scottalanmiller why this obsession with Fedora? If you are building a production cluster, CentOS is the obvious choice
I'd say the opposite. The more critical the workload, the more I want regular updates. I don't see long term releases as being as production ready these days.
https://www.smbitjournal.com/2017/04/rethinking-long-term-support-releases/
-
The last thing that I want for a production system is something with a long release schedule and big, often breaking, updates every few years. I want regular, small updates that we can "roll" on a regular basis.
-
@scottalanmiller I disagree. The last thing I want in production is to deal with tons of bugs and losing API compatibility, having to overhaul my automation all the time to readjust. I've had enough of that when I was working on Openstack, and the product was changed every 6 months so that my code had to be updated for every version over and over again. Fedora is great (I'm typing this message on F28 right now), it has been my desktop OS for the past 10 years, but as a server - no. CentOS is stable and predictable and is a very easy solution if your business intends to grow enough to move on to RHEL.
-
@dyasny said in Testing oVirt...:
@scottalanmiller I disagree. The last thing I want in production is to deal with tons of bugs and losing API compatibility, having to overhaul my automation all the time to readjust.
Never seen that in Fedora, but seen it more in CentOS. The big "few years in between" overhauls are exactly where I see that happen. Your reason is exactly why I want smaller, regular updates. Not fewer giant ones.
