@flaxking Thanks, I'll see what Pluralsight has on the topics I need to catch up on

@obsolesce said in Diving into a completely new tech stack:

So I think it really depends on what the focus is. Is it SMB only trends? Large enterprise? Both?

Is ML only about SMB? Then I might have picked the wrong site to lurk on, haven't done SMB in years, and don't really intend to

@pete-s said in Diving into a completely new tech stack:

mangolassi

explain

@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

@jmoore yeah, I always try to find a fresh book or CBT or both on the topic too. The problem is, sometimes, some of the fresher releases tend to be hard to consume, while something older might be easier and better delivered. So it's a tradeoff.

And the main problem with either is that it lacks the ability to quickly drop you into being able to at least do some basic things with the new tech, there's always a long intro, history and etc. If I need to get into a new tech fast, I really wish there was a way to remove the extra chars from the books, and concentrate on the important bits

@obsolesce said in Testing oVirt...:

So then CentOS 8 too? Is that a reasonable assumption?

If dnf is in RHEL8, it will also be in CentOS8, no doubt.

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

@travisdh1 said in Testing oVirt...:

I actually agree with you that fedup was 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 dnf is going to be in EL8 (afaik)

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

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

@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

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

@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 yeah, my visits were to Detroit (ugh, just ugh.) and Boston, which was actually pretty good, including pastries. I'll be in San Francisco next month, will see what I find there. Here in Canada, coffee and pastries aren't anything to write home about, but you need to know the right places - chains are notably bad, but some mom-and-pop shops can turn out to be very decent, and I'm pretty sure it's the same in the US (at least that was the case in Boston)

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

@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 fedup on 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 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?

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

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