Testing oVirt...



  • @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.

    https://ovirt.org/release/4.2.6/

    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.



  • CentOS is great, but we moved from CentOS to Fedora for stability and reliability reasons. We found that CentOS so often had issues that causes us to no longer be able to keep apps working (without doing things that defeated the purpose of CentOS, like bolting on Fedora updates) or just could not keep our OS updated, that we moved as much production as possible to Fedora.

    Fedora fixed common CentOS stability issues immediately.



  • @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. 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.

    I'd have to disagree with you. In my experience, CentOS is just broken in many cases, always badly out of date, and performance is bad (specifically PHP 5.X still). Staying with the current Fedora version is less work than making things work with CentOS/RedHat, unless you're only using RedHat supported software.



  • @travisdh1 said in Testing oVirt...:

    @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. 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.

    I'd have to disagree with you. In my experience, CentOS is just broken in many cases, always badly out of date, and performance is bad (specifically PHP 5.X still). Staying with the current Fedora version is less work than making things work with CentOS/RedHat, unless you're only using RedHat supported software.

    The big issue isn't CentOS supporting itself, but CentOS (or any LTS release) supporting the "world around it." The world moves on, and the OS doesn't. Making for breaking changes in relation to the real world. CentOS 7 is rock solid, as long as you don't want to run current software on it from third parties.



  • @scottalanmiller with a short lifecycle cadence, changes will keep dropping in very frequently. No manual QA will mean all the corner use cases will be unchecked (I've seen startup who don't even bother to do automatic functional testing, just unit tests, and then push to production). It is much easier to standardise on an OS, maintain it for a few years, and make changes after those few years once, than to keep hacking at new wonderful surprises every few weeks.

    It's a conservative approach, but it ends up saving money for the business, even if it contradicts the current devopsy hype. Besides, I'd rather develop a release pipeline instead of having to constantly fix it because someone upstream didn't care to read the docs and broke the APIs I rely on. Seen it happen way too often



  • @scottalanmiller anything specific you could give as an example? Unless you're running something extremely bleeding edge (and that, these days is usually done in a container, not on the baremetal OS), you shouldn't see such problems at all. The version numbers in EL are misleading, because they do not show the amount of various backports that went into them.



  • @travisdh1 having no PHP5.x isn't about performance, it's about not having this specific version packaged for the OS. Why you would be running something so fresh on CentOS and not in a container with Alpine or somesuch, I don't know, but the container should be running on docker or some sort of CRI engine on a stable distribution. That's how it's done in large enterprise environments at least



  • @dyasny said in Testing oVirt...:

    @scottalanmiller with a short lifecycle cadence, changes will keep dropping in very frequently.

    Right, that's exactly what I want. Lots of small, regular changes.

    Fedora doesn't really have "more" changes than CentOS. It just gets them a little at a time, rather than all at once.

    So that "many frequent changes" is the very reason that I want it. To avoid irregular massive changes.

    That and keeping up to date so that software still works.



  • @dyasny said in Testing oVirt...:

    It is much easier to standardise on an OS, maintain it for a few years, and make changes after those few years once, than to keep hacking at new wonderful surprises every few weeks.

    Easier, yes, for lazy developers. I don't want software from vendors that are going out of date and might easily never manage to support the next release. That's risky with software. Many products do it, but it worries me that they are just stagnating and really worries me that they'll never support the next release.

    Fedora releases every six months, not weeks. So those aren't worries here. That's Tumbleweed.



  • @dyasny said in Testing oVirt...:

    It's a conservative approach, but it ends up saving money for the business, even if it contradicts the current devopsy hype.

    I say the opposite. It's not conservative at all. It's recklessly out of date. Very liberal application of "not keeping up to date." I would say that it costs the business money, mostly through the creation of unnecessary risk. Conservative to me would be Fedora here, it's the tried and true process that takes the cautious approach.

    As someone who has run software dev shops for years, we choose Fedora and Ubuntu Current for exactly this reason. Regular, progressive steps and cautious, planned updates all the time. Making staying current part of the normal routine, rather than making updating a huge scary irregular undertaking.



  • @scottalanmiller you're missing the long cycle of backports while maintaining compatibility and all the QA that goes into an EL release. I've worked in Red Hat's QE for a few years, there's a huge amount of stuff that gets found, fixed and ironed out of an upstream build before it gets into an EL release



  • @dyasny said in Testing oVirt...:

    @scottalanmiller anything specific you could give as an example? Unless you're running something extremely bleeding edge (and that, these days is usually done in a container, not on the baremetal OS), you shouldn't see such problems at all. The version numbers in EL are misleading, because they do not show the amount of various backports that went into them.

    Fedora is NOT bleeding edge, it's just reasonably current.

    Anything that runs on PHP, which is a LOT of stuff. For example.

    Basically anything that needs good third party apps of any sort.



  • @scottalanmiller I think developers should focus on the product they are developing, and not on keeping up with the changes in the underlying OS



  • @dyasny said in Testing oVirt...:

    @travisdh1 having no PHP5.x isn't about performance, it's about not having this specific version packaged for the OS. Why you would be running something so fresh on CentOS and not in a container with Alpine or somesuch, I don't know, but the container should be running on docker or some sort of CRI engine on a stable distribution. That's how it's done in large enterprise environments at least

    If you don't use the OS as intended, what is the purpose? We've had this discussion here about LTSs in the past. IF you are bolting fedora or random third party libraries on to replace the core OS components, I see that as clear admission that Fedora was the right choice and only politics to keep using CentOS.

    We run everything fresh, we don't want to run old, abandoned software. So "why something so fresh" applies to literally all workloads.



  • @scottalanmiller Fedora is as close to bleeding edge as it can be, that's the point of the distribution.



  • @dyasny said in Testing oVirt...:

    @scottalanmiller I think developers should focus on the product they are developing, and not on keeping up with the changes in the underlying OS

    That's really bad for me as a customer. It means i never know if the product will keep working and I know that they aren't prepared for updating it when the time comes.

    As a software developer, that would mean I'm not consider my production for production. This is something we specifically fear from developers, that they focus on the code for themselves and forget that there are customers who actually need to run it in the real world.