If we need that extra server in Production DC (for hosted engine redundancy and to allow maintenance) then lets take the lower end new servers from 17-26 and replace it with the strong one.
We need to utilize our servers, I don't think we're at 50% utilization even, looking at the memory consumption last time i checked when all slaves were working

the problem is that we won't have live migration in the Production cluster if we add
the new hosts there(because of the multi node NUMA mismatch), we could put 2 new
hosts in the Production cluster but then we would have to schedule a downtime

in order to move them.

I think that coupling the engine upgrade with the new slaves is not necessary.

we can start by installing the hook on ovirt-srv11 and spinning up new slaves,

that way we can also test the hook in production. because there is no NFS involved,

and live migration isn't working with the hook, the host is pretty much self-contained

and this can't harm anything.

On Thu, May 12, 2016 at 4:59 PM, Anton Marchukov <amarchuk@redhat.com> wrote:

I was talking about using the hooks before installing the ssds, but if that can
be done reliably also before the upgrade it's also a solution that will help
scratch our current itches sooner.

That's about it. The hook in 3.6 contains the patch I submitted. It does not work without it at all.
Although you can use rpm from 3.5 in 3.6.

^ well, the machines being slaves I think there's no problem having to stop
them to migrate them, we have already experience with both fabric and jenkins
so I guess it should not be hard to automate with those tools ;)

Yes there is no problem with that. But I am not aware about "stop all slaves on the host" feature in
oVirt so that would be either manually clicking or we need to fabricate it. Not a big deal too.

--
Anton Marchukov
Senior Software Engineer - RHEV CI - Red Hat

_______________________________________________
Infra mailing list
Infra@ovirt.org
http://lists.ovirt.org/mailman/listinfo/infra