Testing oVirt...
-
@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.
-
@scottalanmiller calling EL "abandoned" is really strange, don't you think? All that software is supported by a major software vendor for 10 years, not just something a code-kiddy put out on github, which is what usually gets abandoned
-
@dyasny said in Testing oVirt...:
@scottalanmiller Fedora is as close to bleeding edge as it can be, that's the point of the distribution.
Not even close. That's Tumbleweed. Fedora is a six month release cycle, non-bleeding edge. It's very conservative. VERY.
It only "feels" like it is on any edge at all, because CentOS is so ridiculously stagnant. If you don't have the CentOS experience, then Fedora looks like a very conservative option.
THings like Tumbleweed are called rolling releases and their purpose is cutting edge. Even Tumbleweed is only cutting, not bleeding, edge. No mainline distro touches bleeding edge.
-
@dyasny said in Testing oVirt...:
@scottalanmiller calling EL "abandoned" is really strange, don't you think? All that software is supported by a major software vendor for 10 years, not just something a code-kiddy put out on github, which is what usually gets abandoned
I didn't, I called software that doesn't keep up to date and leverages ancient libraries and doesn't consider the next update to be the starting path of abandonment.
-
CentOS is a great product designed to be an excellent platform to handle bad software practices from third parties. The use of CentOS itself is not the concern, it's software that requires it that is the concern.
-
@scottalanmiller wait, you expect software to be supported beyond a 10 year cadence? It can be extended to 20 for a customer, actually.
What you describe is exactly what you are opposing here - always latest, always at the edge, and if development slows down even a bit, the entire product is worthless. Are you sure that's what you want to rely on?
-
@scottalanmiller 6 months is ridiculously fast for such a huge project. You can barely test it in any capacity, which is why it barely gets any real testing at all. If a package compiles - it's good enough. Not very reliable, IMO
-
@dyasny said in Testing oVirt...:
@scottalanmiller wait, you expect software to be supported beyond a 10 year cadence? It can be extended to 20 for a customer, actually.
I want it supported currently. I want software actually being still developed today. Not that will "continue to run" twenty years after the developers quit and bugs just remain forever.
-
@dyasny said in Testing oVirt...:
@scottalanmiller 6 months is ridiculously fast for such a huge project. You can barely test it in any capacity, which is why it barely gets any real testing at all. If a package compiles - it's good enough. Not very reliable, IMO
Processes aside, we find it MORE reliable in real world usage. And logically it makes sense, because third parties targetting it are "alive" doing active development. Not resting on "things not changing" and panicking when they finally do.
-
@scottalanmiller said in Testing oVirt...:
I didn't, I called software that doesn't keep up to date and leverages ancient libraries and doesn't consider the next update to be the starting path of abandonment.
But a package that relies on a stable LTS API doesn't need to be old. It can be updated as frequently as you like, the difference being - no need to constantly keep changing the way it works with the underlying OS, you can focus on the actual functionality of the app
-
@scottalanmiller said in Testing oVirt...:
@dyasny said in Testing oVirt...:
@scottalanmiller wait, you expect software to be supported beyond a 10 year cadence? It can be extended to 20 for a customer, actually.
I want it supported currently. I want software actually being still developed today. Not that will "continue to run" twenty years after the developers quit and bugs just remain forever.
Zmanda comes to mind as an example of this exact issue. You really don't want that with a backup vendor!
-
@scottalanmiller said in Testing oVirt...:
I want it supported currently. I want software actually being still developed today. Not that will "continue to run" twenty years after the developers quit and bugs just remain forever.
Why should it not be current, only because it relies on a stable OS?
