So - to get this back on track - I was able to remove the host entirely from HostedEngine using ovirt-shell - but now cannot add it back for the same reason as not being able to add ANY hosts to this cluster (there is another email thread on this):
*** *Mark Steele* CIO / VP Technical Operations | TelVue Corporation TelVue - We Share Your Vision 16000 Horizon Way, Suite 100 | Mt. Laurel, NJ 08054 800.885.8886 x128 | [email protected] | http://www.telvue.com twitter: http://twitter.com/telvue | facebook: https://www.facebook.com/telvue On Fri, Feb 16, 2018 at 3:30 PM, Yaniv Kaul <[email protected]> wrote: > > > On Feb 15, 2018 7:35 PM, "Christopher Cox" <[email protected]> wrote: > > On 02/15/2018 11:10 AM, Michal Skrivanek wrote: > ..snippity... with regards to oVirt 3.5 > > >> that’s a really old version…. >> > > 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? > > I know, I know, FOSS... the only thing worse than running today's code is > running yesterday's. > > 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. > > With that said, 3.5 isn't exactly on the "stable line" to Red Hat > Virtualization, that was 3.4 and then 3.6. > > > Red Hat doesn't support 3.x anymore, unless its 3.6 with specific > subscription that extends its support. > > > Some people can't afford major (downtime) upgrades every 3-6 months or > so. But, arguably, maybe we shouldn't be running oVirt. Maybe it's not > designed for "production". > > > 3.4,5,6 are minor releases of 3.x. > The same way that 4.1 and 4.2 are minor releases of 4.x. > I agree that with lots of changing landscape (for example, the move from > EL6 to EL7) and with the number of features introduced, they don't seem > that minor. But there's an ongoing effort to both keep backwards > compatibility as well continously improve quality - which regretfully, > requires updating from time to time. > > > I guess oVirt isn't really for production by definition, but many of us > are doing so. > > 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. > > 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! > > > Or a warning sign that upgrade is not yet easy as it should be. I believe > we've improved the experience and quality of the upgrade flow over time, > but we can certainly do a better job. > > I also think there are two additional factors : > 1. Don't fix what ain't broken - it works, why bother? Not much the oVirt > community can do here. > 2. Newer versions do not provide enough incentive to upgrade. This is a > tougher one - I believe they do, both in terms of quality as well as new > features that bring value to different use-cases. However, we may not be > doing enough 'marketing' work around them, or they are not documented well > enough, etc. > Y. > > > > > _______________________________________________ > Users mailing list > [email protected] > http://lists.ovirt.org/mailman/listinfo/users > > > > _______________________________________________ > Users mailing list > [email protected] > http://lists.ovirt.org/mailman/listinfo/users > >
_______________________________________________ Users mailing list [email protected] http://lists.ovirt.org/mailman/listinfo/users
