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
-
@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?
-
@dyasny said in Testing oVirt...:
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?
This isn't Fedora. Fedora is not on the edge. It's stable, conservative. Just being updated regularly is in no way the same as being on the edge.
You could update daily, but have a year of testing before release. The frequency of release has no bearing on the "edginess" of the release. Those are two different factors.
CentOS could release once a decade, but be bleeding edge at release time. They aren't, but they could.
-
@dyasny said in Testing oVirt...:
@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?
You have to stop saying one is stable and one is on the edge. That's simply not what we are talking about. We are talking about a really slow update cycle, and a smaller update but more regular cycle.
In my mind, I want stable. So that means Fedora. CentOS is unstable, so I don't want software that demands it.
Your reasons make sense, but draw me to the opposite conclusion.
-
@scottalanmiller said in Testing oVirt...:
This isn't Fedora. Fedora is not on the edge. It's stable, conservative. Just being updated regularly is in no way the same as being on the edge.
It is actually. 6 months is a very short time for QA to tackle an OS release, so it doesn't really. And updated regularly? Come on, do you do a
fedupon a server every 6 months?You could update daily, but have a year of testing before release. The frequency of release has no bearing on the "edginess" of the release. Those are two different factors.
I can update CentOS as soon as updates arrive. They do arrive, and often enough.
CentOS could release once a decade, but be bleeding edge at release time. They aren't, but they could.
EL is pretty close to the current Fedora at release time in many ways. All the bits that are deemed important are backported, do NOT look at the versions, those numbers are really there to show the initial version of a package things started at, not the update level the backports took the package to atm
-
@scottalanmiller I'm sorry, but your perception is really skewed here. Fedora is there to bring all the latest upstream code into an RPM oriented build, every few years, a Fedora version is frozen, and starts going through testing, bugfixing and retesting cycles very intensively. As more features arrive in the newer Fedora builds, those get backported into the frozen version, until it end up as an EL distribution. Not everything goes into EL (notably joystick drivers are skipped), but the stuff that is important for the enterprise use case all gets backported and yes tested and retested.
-
@dyasny said in Testing oVirt...:
@scottalanmiller I'm sorry, but your perception is really skewed here. Fedora is there to bring all the latest upstream code into an RPM oriented build, every few years, a Fedora version is frozen, and starts going through testing, bugfixing and retesting cycles very intensively. As more features arrive in the newer Fedora builds, those get backported into the frozen version, until it end up as an EL distribution. Not everything goes into EL (notably joystick drivers are skipped), but the stuff that is important for the enterprise use case all gets backported and yes tested and retested.
ALl of that I've written about in that article. So you know I'm aware of it and talk about it.
But stuff needed for enterprise use in CentOS is NOT back ported. It just never arrives. CentOS is simply too stagnant for most real world applications. And anyone relying on it is the concern. Not CentOS itself, but the applications.
-
@dyasny said in Testing oVirt...:
@scottalanmiller said in Testing oVirt...:
This isn't Fedora. Fedora is not on the edge. It's stable, conservative. Just being updated regularly is in no way the same as being on the edge.
It is actually. 6 months is a very short time for QA to tackle an OS release, so it doesn't really. And updated regularly? Come on, do you do a
fedupon a server every 6 months?You could update daily, but have a year of testing before release. The frequency of release has no bearing on the "edginess" of the release. Those are two different factors.
I can update CentOS as soon as updates arrive. They do arrive, and often enough.
CentOS could release once a decade, but be bleeding edge at release time. They aren't, but they could.
EL is pretty close to the current Fedora at release time in many ways. All the bits that are deemed important are backported, do NOT look at the versions, those numbers are really there to show the initial version of a package things started at, not the update level the backports took the package to atm
"deemed important", but not to end users.
-
@dyasny said in Testing oVirt...:
@scottalanmiller said in Testing oVirt...:
This isn't Fedora. Fedora is not on the edge. It's stable, conservative. Just being updated regularly is in no way the same as being on the edge.
It is actually. 6 months is a very short time for QA to tackle an OS release, so it doesn't really. And updated regularly? Come on, do you do a
fedupon a server every 6 months?Yes we do. My standard images both have daily updates applied automatically (I have a Fedora and a Debian that I use.) The only thing I have to kick off myself is the twice a year system upgrade, and that's so much easier than any CentOS system update I've ever had to do.
Nitpicking time: It's not longer
fedup, it was usingdnfup to 28. I don't know what the update mechanism for 28 is/will be yet. -
@scottalanmiller EL is a platform, with the current container craze, all it really needs to be good at is running containers and supporting hardware well. That is already there and always was. All the bleeding edge development stuff is usually available not packaged for an OS but in the distribution channel for the specific language or platform (think pip, cpan, spark-packages.org or ansible-galaxy) or even easier - on dockerhub. So the apps can get support if they need it, and quite easily so. And in the modern, common use case of a cloud or k8s - what you have is a stable EL running the platform and your dev/test/stage/prod stuff in specific VMs or lightweight containers.
Software that has to run on the metal is usually of the same philosophy as EL itself
-
@scottalanmiller said in Testing oVirt...:
"deemed important", but not to end users.
As an ex-product manager at RHT, I've sat through meetings with end users who laid out what was important for them, and then oversaw backports being made exactly for those features.
