On Dec 11, 2013, at 08:53 , Oved Ourfalli <ovedo(a)redhat.com> wrote:
----- Original Message -----
> From: "Michal Skrivanek" <michal.skrivanek(a)redhat.com>
> To: "Oved Ourfalli" <ovedo(a)redhat.com>
> Cc: "Sandro Bonazzola" <sbonazzo(a)redhat.com>, "Roy Golan"
<rgolan(a)redhat.com>, "engine-devel"
> <engine-devel(a)ovirt.org>
> Sent: Wednesday, December 11, 2013 8:45:41 AM
> Subject: Re: [Engine-devel] Setting cluster CPU
>
>
> On Dec 11, 2013, at 08:18 , Oved Ourfalli <ovedo(a)redhat.com> wrote:
>
>>
>>
>> ----- Original Message -----
>>> From: "Michal Skrivanek" <michal.skrivanek(a)redhat.com>
>>> To: "Oved Ourfalli" <ovedo(a)redhat.com>, "Sandro
Bonazzola"
>>> <sbonazzo(a)redhat.com>
>>> Cc: "Roy Golan" <rgolan(a)redhat.com>,
"engine-devel"
>>> <engine-devel(a)ovirt.org>
>>> Sent: Tuesday, December 10, 2013 8:01:08 PM
>>> Subject: Re: [Engine-devel] Setting cluster CPU
>>>
>>>
>>> On Dec 10, 2013, at 09:14 , Oved Ourfalli <ovedo(a)redhat.com> wrote:
>>>
>>>>
>>>>
>>>> ----- Original Message -----
>>>>> From: "Sandro Bonazzola" <sbonazzo(a)redhat.com>
>>>>> To: "Michal Skrivanek" <michal.skrivanek(a)redhat.com>,
"Oved Ourfalli"
>>>>> <ovedo(a)redhat.com>, "Roy Golan"
>>>>> <rgolan(a)redhat.com>
>>>>> Cc: "engine-devel" <engine-devel(a)ovirt.org>
>>>>> Sent: Tuesday, December 10, 2013 9:12:14 AM
>>>>> Subject: Re: [Engine-devel] Setting cluster CPU
>>>>>
>>>>> Il 09/12/2013 19:37, Michal Skrivanek ha scritto:
>>>>>>
>>>>>>
>>>>>>> On 09 Dec 2013, at 18:58, Oved Ourfalli
<ovedo(a)redhat.com> wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> ----- Original Message -----
>>>>>>>> From: "Michal Skrivanek"
<michal.skrivanek(a)redhat.com>
>>>>>>>> To: "Sandro Bonazzola"
<sbonazzo(a)redhat.com>, "Roy Golan"
>>>>>>>> <rgolan(a)redhat.com>
>>>>>>>> Cc: "engine-devel"
<engine-devel(a)ovirt.org>
>>>>>>>> Sent: Monday, December 9, 2013 5:50:49 PM
>>>>>>>> Subject: Re: [Engine-devel] Setting cluster CPU
>>>>>>>>
>>>>>>>>
>>>>>>>>> On Dec 9, 2013, at 16:01 , Sandro Bonazzola
<sbonazzo(a)redhat.com>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>> Hi,
>>>>>>>>> I'm trying to set the cluster CPU type while
adding the first host
>>>>>>>>> to
>>>>>>>>> the
>>>>>>>>> Default cluster.
>>>>>>>>>
>>>>>>>>> I know how to set the CPU type on a new cluster,
since I'll do that
>>>>>>>>> in
>>>>>>>>> AIO
>>>>>>>>> plugin.
>>>>>>>>> But I'm not sure to understand how to set the CPU
on an existing
>>>>>>>>> cluster.
>>>>>>>>>
>>>>>>>>> Should it be enough to specify cpu arg while adding
the host to the
>>>>>>>>> cluster?
>>>>>>>>> (before adding an host, cpu is None on the cluster)
>>>>>>>>> Because I'm trying to do that without success
(obtaining a
>>>>>>>>> sandybridge
>>>>>>>>> cluster while specifying westmere cpu).
>>>>>>>>
>>>>>>>> The CPU should be set from the first host if None. That
is needed for
>>>>>>>> the
>>>>>>>> PPC
>>>>>>>> support. Roy, we talked about it recently, where are we
with this
>>>>>>>> patch.
>>>>>>>
>>>>>>> We already support modifying the CPU level of an existing
cluster. If
>>>>>>> changing it to a higher level then we just change it.
>>>>>>> If changing it to a lower level, and there are running VMs on
the
>>>>>>> cluster,
>>>>>>> then we warn the user that some VMs might not be
migrate-able, as we
>>>>>>> added a scheduling filter to filter out hosts with improper
CPU level.
>>>>>>>
>>>>>>> Unless I'm missing something, that covers the use-case,
isn't it?
>>>>>>
>>>>>> Not sure. I thought this is None to something, where it should
work
>>>>>> automatically without specifying anything. Just add an
operational host
>>>>>
>>>>> Well, here the issue is that while deploying hosted-engine VM,
I'm on a
>>>>> SandyBridge host, with 1 VM running on it (the hosted engine VM).
>>>>> That VM has been created with CPU model Westmere to be able to
migrate
>>>>> it
>>>>> to
>>>>> other hosts Westmere compatible.
>>>>> But the Default cluster is automatically set to SandyBridge when I
add
>>>>> the
>>>
>>> because it's created with None in the first place, and then set by the
>>> first
>>> host. If you'd create it with Westmere initially the joining host would
>>> not
>>> change it
>>> IMHO the setting should be done during the installation not via calling
>>> SDK
>>> on already created empty cluster but directly in the db when the db is
>>> deployed. Unless I'm missing the sequence of deployment.
>>>
>>
>> The hosted engine setup doesn't access the DB, so no reason to access it if
>> it is possible to do that via the SDK.
>> Didn't test that, but see no reason for it not to work.
>>
>>>>> host also if I specify Westmere as CPU family in Host parameter.
>>>>> We may be able to set manually the CPU level later somehow, but
since
>>>>> we've
>>>>> already asked the user about the CPU level I think we should avoid
to
>>>>> ask
>>>>> the user to change it again later. See Bug 1034821 - Hosted-setup
asks
>>>>> for
>>>>> CPU type but it doesn't set cluster to that CPU Level
>>>>>
>>>>
>>>> You can set the CPU level through the SDK, after you add the host
(didn't
>>>> check that, but see no reason it won't work).
>>>
>>> why so late in the process?
>>>
>>
>> why does it matter? The setup is still running, so, imo, the order is less
>> relevant, as long as the result is okay.
>
>
> depends. if hosted engine is part of the installation, it should do the
> modifications during installation the same way as anything else, forcefully,
> and not depend on working sdk or any other precondition
> if it is something you are/should be able to deploy over an existing setup
> it's better via sdk...
>
Well... it is somewhere in between.
One of the steps in the hosted engine setup is to start a VM in which the user needs to
install the engine.
So, adding the host is done via the SDK after the engine installation is completed.
ah, ok, I thought it's before that, as the host is the one your engine is at, so I
thought it can be created right at the beginning
then it all makes sense:)
That's why I thought it would be best to change the CPU level
also after the engine installation is complete, and not during it.
In addition, it will probably also help covering the use-case of migrating an existing
engine to a hosted engine environment (although I'm not familiar enough with the
current proposed solution for this use-case).
>>>>
>>>>>
>>>>>>
>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> michal
>>>>>>>>
>>>>>>>>>
>>>>>>>>> Michael, can you take a look at
http://gerrit.ovirt.org/22129 and
>>>>>>>>> advise?
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Sandro Bonazzola
>>>>>>>>> Better technology. Faster innovation. Powered by
community
>>>>>>>>> collaboration.
>>>>>>>>> See how it works at
redhat.com
>>>>>>>>> _______________________________________________
>>>>>>>>> Engine-devel mailing list
>>>>>>>>> Engine-devel(a)ovirt.org
>>>>>>>>>
http://lists.ovirt.org/mailman/listinfo/engine-devel
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> Engine-devel mailing list
>>>>>>>> Engine-devel(a)ovirt.org
>>>>>>>>
http://lists.ovirt.org/mailman/listinfo/engine-devel
>>>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Sandro Bonazzola
>>>>> Better technology. Faster innovation. Powered by community
>>>>> collaboration.
>>>>> See how it works at
redhat.com
>>>>> _______________________________________________
>>>>> Engine-devel mailing list
>>>>> Engine-devel(a)ovirt.org
>>>>>
http://lists.ovirt.org/mailman/listinfo/engine-devel
>>>>>
>>>
>>>
>
>