<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div></div><div><br></div><div><br>On 15 Feb 2018, at 18:34, Christopher Cox <<a href="mailto:ccox@endlessnow.com">ccox@endlessnow.com</a>> wrote:<br><br></div><blockquote type="cite"><div><span>On 02/15/2018 11:10 AM, Michal Skrivanek wrote:</span><br><span>..snippity... with regards to oVirt 3.5</span><br><blockquote type="cite"><span>that’s a really old version….</span><br></blockquote><span></span><br><span>I know I'll catch heat for this, but by "old" you mean like December of 2015? Just trying put things into perspective. Thus it goes with the ancient and decrepit Red Hat Ent. 7.1 days, right?</span><br></div></blockquote><div><br></div>Hehe. It’s not about using it, rather I was referring to the fact that we stopped developing it, stopped fixing even critical security issues. Same for 3.6, and 4.0.<div><br><blockquote type="cite"><div><span></span><span>I know, I know, FOSS... the only thing worse than running today's code is running yesterday's.</span><br></div></blockquote><div><br></div>Well, there is only a limited amount of resources you can devote to actively maintain branches/releases</div><div>We typically do that for two versions, covering roughly 1,5 years</div><div><br><blockquote type="cite"><div><span></span><span>We still run a 3.5 oVirt in our dev lab, btw. But I would not have set that up (not that I would have recommended oVirt to begin with), preferring 3.4 at the time. I would have waited for 3.6.</span><br><span></span><br><span>With that said, 3.5 isn't exactly on the "stable line" to Red Hat Virtualization, that was 3.4 and then 3.6.</span><br><span></span><br><span>Some people can't afford major (downtime) upgrades every 3-6 months or so. </span></div></blockquote><div><br></div>That’s why we do not really require it and still support 3.6 cluster compat in 4.2, so that does give you longer time to update. And even the cluster upgrades are rolling, we do not require any real downtime other than for rebooting individual VMs and some spare capacity to migrate workloads to during host upgrade.</div><div><br></div><div><br><blockquote type="cite"><div><span>But, arguably, maybe we shouldn't be running oVirt. Maybe it's not designed for "production".</span><br><span></span><br><span>I guess oVirt isn't really for production by definition, but many of us are doing so.</span></div></blockquote><blockquote type="cite"><div><span></span><br><span>So... not really a "ding" against oVirt developers, it's just a rapidly moving target with the normal risks that come with that. People just need to understand that.</span><br></div></blockquote><div><br></div>Absolutely. People should understand the difference between a GA and a zstream update 6 months later. Every sw has bugs. </div><div>But I would argue we do actually have quite a long supported versions, when compared to a $random project. </div><div>And then yes, we do have a longer support for Red Hat Virtualization, but again in general I would doubt you can find many similar commercial products being _actively_ supported for more than few years</div><div><br><blockquote type="cite"><div><span></span><br><span>And with that said, the fact that many of us are running those ancient decrepit evil versions of oVirt in production today, is actually a testimony to its quality. Good job devs!</span><br></div></blockquote><div><br></div>Thanks!</div><div><br></div><div><blockquote type="cite"><div><span></span><br><span></span><br><span>_______________________________________________</span><br><span>Users mailing list</span><br><span><a href="mailto:Users@ovirt.org">Users@ovirt.org</a></span><br><span><a href="http://lists.ovirt.org/mailman/listinfo/users">http://lists.ovirt.org/mailman/listinfo/users</a></span><br></div></blockquote></div></body></html>