[ovirt-users] Unable to put Host into Maintenance mode

[Mark Steele]

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 | msteele at telvue.com | 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 <ykaul at redhat.com> wrote:

>
>
> On Feb 15, 2018 7:35 PM, "Christopher Cox" <ccox at endlessnow.com> 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
> Users at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/users
>
>
>
> _______________________________________________
> Users mailing list
> Users at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/users/attachments/20180216/93a7f7bd/attachment.html>