Testing oVirt...
-
@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.
-
@dyasny said in Testing oVirt...:
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 fedup on a server every 6 months?
It's not like Windows where they have a whole team of people going over every bit of the OS.
It's Fedora Linux, it's not "Fedora" who is QAing every package. That's up to Apache to QA Apache stuff... not Fedora. That goes for just about every package that makes up a GNU/Linux OS if you know what I mean.
Fedora verify it's working smoothing together, picking stable releases of every package that goes in to it, and making sure they are happy together. It's not as involved, still a process, but not like it is with Windows where it needs years of testing, QA, etc..
-
@travisdh1 dnf or yum or whatever, it's just a utility name, you know what I'm talking about, that's what's important
Frankly, knowing how often this (
fedy) procedure breaks things or leaves muddy tracks all over the carpets, if you will, I'd hate to be responsible for a production setup where this is common practice. In disposable VMs - sure, who cares, just spawn some more if it dies. But on production platform machines - I like to be able to have weekends and see my family sometimes too much -
@obsolesce How many opensource OS and related products have you overseen from upstream ingestion to release?
Windows, actually, doesn't have much QA done, they release as soon as they stabilize, this is why no Windows is usable until SP1 at least. That's how they killed Netware, where the QA cycle was around 18 months, but the OS came out absolutely solid and bulletproof. And nothing changes since, except the adoption of the DevOps methodologies, which speed release up even more.
-
@dyasny said in Testing oVirt...:
@obsolesce How many opensource OS and related products have you overseen from upstream ingestion to release?
Windows, actually, doesn't have much QA done, they release as soon as they stabilize, this is why no Windows is usable until SP1 at least. That's how they killed Netware, where the QA cycle was around 18 months, but the OS came out absolutely solid and bulletproof. And nothing changes since, except the adoption of the DevOps methodologies, which speed release up even more.
Ya obviously there's no good QA at Microsoft or their stuff wouldn't be broken every month. I get that lol.
But that wasn't my point at all.
-
@obsolesce it just seems to me (and I might be wrong here of course) that you are speaking as an end user, a consumer of an opensource solution, and you do not know what is happening before the solution is released to the end user. Hence my question, which you ignored.
I'll make it clear though - for an enterprise level product to be released, even if it pulls in upstream code, everything has to be retested, both the functionality and the integration with the downstream stack. It would not be an enterprise product otherwise. And yes, this is no theory, I've been a part of this process in various capacities for over a decade now.
-
@dyasny said in Testing oVirt...:
@travisdh1 dnf or yum or whatever, it's just a utility name, you know what I'm talking about, that's what's important
:thumbs_up:
Frankly, knowing how often this (
fedy) procedure breaks things or leaves muddy tracks all over the carpets, if you will, I'd hate to be responsible for a production setup where this is common practice. In disposable VMs - sure, who cares, just spawn some more if it dies. But on production platform machines - I like to be able to have weekends and see my family sometimes too muchI actually agree with you that
fedupwas bad, which is why it was only around for a short time. The dnf tooling has been rock solid since they moved to it. -
@dyasny said in Testing oVirt...:
...everything has to be retested, both the functionality and the integration with the downstream stack.
That is exactly how I "summed it up" here in children's terms:
@obsolesce said in Testing oVirt...:
Fedora verify it's working smoothing together, picking stable releases of every package that goes in to it, and making sure they are happy together.
-
@dyasny said in Testing oVirt...:
I'll make it clear though - for an enterprise level product to be released, even if it pulls in upstream code, everything has to be retested, both the functionality and the integration with the downstream stack. It would not be an enterprise product otherwise. And yes, this is no theory, I've been a part of this process in various capacities for over a decade now.
But nobody does this for every package included in a repository for every release that I know of. That would mean billions of tests for a modern distribution!
-
@travisdh1 said in Testing oVirt...:
I actually agree with you that
fedupwas bad, which is why it was only around for a short time. The dnf tooling has been rock solid since they moved to it.Which is why
dnfis going to be in EL8 (afaik) -
@dyasny said in Testing oVirt...:
@travisdh1 said in Testing oVirt...:
I actually agree with you that
fedupwas bad, which is why it was only around for a short time. The dnf tooling has been rock solid since they moved to it.Which is why
dnfis going to be in EL8 (afaik)So then CentOS 8 too? Is that a reasonable assumption?
-
@travisdh1 said in Testing oVirt...:
But nobody does this for every package included in a repository for every release that I know of. That would mean billions of tests for a modern distribution!
The Red Hat moto has always been "if we ship it, we support it", and to support something they have to test it. This is why the EL repos aren't as full of stuff as the upstream, you are correct it is impossible to test the whole world.
-
@obsolesce said in Testing oVirt...:
So then CentOS 8 too? Is that a reasonable assumption?
If
dnfis in RHEL8, it will also be in CentOS8, no doubt. -
@dyasny said in Testing oVirt...:
@travisdh1 said in Testing oVirt...:
But nobody does this for every package included in a repository for every release that I know of. That would mean billions of tests for a modern distribution!
The Red Hat moto has always been "if we ship it, we support it", and to support something they have to test it. This is why the EL repos aren't as full of stuff as the upstream, you are correct it is impossible to test the whole world.
Even Red Hat can't test every combination of every package in their repository. Which is what brought on my previous statement.
-
@travisdh1 said in Testing oVirt...:
Even Red Hat can't test every combination of every package in their repository. Which is what brought on my previous statement.
There is hardly need to test every package separately, they usually constitute a product of a stack, which is tested, extensively
-
@obsolesce said in Testing oVirt...:
@dyasny said in Testing oVirt...:
@travisdh1 said in Testing oVirt...:
I actually agree with you that
fedupwas bad, which is why it was only around for a short time. The dnf tooling has been rock solid since they moved to it.Which is why
dnfis going to be in EL8 (afaik)So then CentOS 8 too? Is that a reasonable assumption?
They are one and the same. There are no packages different.
-
@dyasny said in Testing oVirt...:
@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.
Containers != Enterprise software deployments. And it's a fad. If this is the basis for RHEL being seen as enterprise and Fedora not, I feel that makes me feel more confident, rather than less.
Fedora is rock solid on containers too, but with later tech. If we don't care about the packages that come with the OS, and only the most basic pieces, Fedora blows CentOS out of the water.
If containers are the current standard for "enterprise", then I'm again, in the Fedora camp. I've seen the problems and instability with containers (presuming you mean Docker, not LXC) and yeah, that's what the kids trying to get jobs based on resume words do, but for enterprise workloads that actually matter, that's anything but the norm.
Containers are great for testing things, and sometimes great for internally controlled software. But for deploying other peoples' code... see all the threads where we've discussed how they aren't reliable because Docker just doesn't address compatibility issues in the real world. They put on a good marketing blitz, but it doesn't hold up in practice. Maybe someday, but "someday" comes several years earlier on Fedora than on CentOS / RHEL.
