8:16 a.m.
Hi all,
In the link below there is a wiki page describing the requirements and
design of the SPM Priority feature.
The feature allows the admin to define priorities between hosts
regarding the SPM selection process
http://www.ovirt.org/wiki/Features/SPMPriority
Please feel free to share your comments.
Thanks,
Muli
10:22 a.m.
Few points:
- From requirement perspective - 0-10 scale is OK too.
- There is an RFE to allow manual SPM selection, let's make sure that we clarify how
we do that in the scenarios.
- There is a case were all Hosts are set as "no SPM" (-1), user should be notify
(on the last host?)
- Need to be able to view in the GUI:
- the SPM priority for all Hosts, on the GRID?
- would love to have the spm-priority avail in the search criteria, so I would serach
for all hosts that spm-priority==0/-1
Miki
----- Original Message -----
From: "Muli Salem" <msalem(a)redhat.com>
To: engine-devel(a)ovirt.org
Sent: Tuesday, December 27, 2011 3:16:46 PM
Subject: [Engine-devel] SPM Priority Design - Wiki Page
Hi all,
In the link below there is a wiki page describing the requirements
and
design of the SPM Priority feature.
The feature allows the admin to define priorities between hosts
regarding the SPM selection process
http://www.ovirt.org/wiki/Features/SPMPriority
Please feel free to share your comments.
Thanks,
Muli
_______________________________________________
Engine-devel mailing list
Engine-devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
11:21 a.m.
On 12/27/2011 05:22 PM, Miki Kenneth wrote:
Few points:
- From requirement perspective - 0-10 scale is OK too.
- There is an RFE to allow manual SPM selection, let's make sure that we clarify how
we do that in the scenarios.
- There is a case were all Hosts are set as "no SPM" (-1), user should be
notify (on the last host?)
Hi Miki,
Can you please elaborate on this validation.
When we edit a host it is currently a requirement that the host will be
in maintenance.
So what do you think the validation should be?
Livnat
- Need to be able to view in the GUI:
- the SPM priority for all Hosts, on the GRID?
- would love to have the spm-priority avail in the search criteria, so I would serach
for all hosts that spm-priority==0/-1
Miki
----- Original Message -----
> From: "Muli Salem" <msalem(a)redhat.com>
> To: engine-devel(a)ovirt.org
> Sent: Tuesday, December 27, 2011 3:16:46 PM
> Subject: [Engine-devel] SPM Priority Design - Wiki Page
>
> Hi all,
>
> In the link below there is a wiki page describing the requirements
> and
> design of the SPM Priority feature.
> The feature allows the admin to define priorities between hosts
> regarding the SPM selection process
>
> http://www.ovirt.org/wiki/Features/SPMPriority
>
> Please feel free to share your comments.
>
> Thanks,
> Muli
> _______________________________________________
> 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
12:33 a.m.
Send from my iPhone .
On 28 בדצמ 2011, at 18:21, Livnat Peer <lpeer(a)redhat.com> wrote:
On 12/27/2011 05:22 PM, Miki Kenneth wrote:
> Few points:
> - From requirement perspective - 0-10 scale is OK too.
> - There is an RFE to allow manual SPM selection, let's make sure that we clarify
how we do that in the scenarios.
> - There is a case were all Hosts are set as "no SPM" (-1), user should be
notify (on the last host?)
Hi Miki,
Can you please elaborate on this validation.
When we edit a host it is currently a requirement that the host will be
in maintenance.
So what do you think the validation should be?
That there is at least one host in the cluster that can become spm.
Livnat
> - Need to be able to view in the GUI:
> - the SPM priority for all Hosts, on the GRID?
> - would love to have the spm-priority avail in the search criteria, so I would
serach for all hosts that spm-priority==0/-1
>
>
>
> Miki
>
>
> ----- Original Message -----
>> From: "Muli Salem" <msalem(a)redhat.com>
>> To: engine-devel(a)ovirt.org
>> Sent: Tuesday, December 27, 2011 3:16:46 PM
>> Subject: [Engine-devel] SPM Priority Design - Wiki Page
>>
>> Hi all,
>>
>> In the link below there is a wiki page describing the requirements
>> and
>> design of the SPM Priority feature.
>> The feature allows the admin to define priorities between hosts
>> regarding the SPM selection process
>>
>> http://www.ovirt.org/wiki/Features/SPMPriority
>>
>> Please feel free to share your comments.
>>
>> Thanks,
>> Muli
>> _______________________________________________
>> 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
4:02 a.m.
On 29/12/11 07:33, Miki Kenneth wrote:
Send from my iPhone .
On 28 בדצמ 2011, at 18:21, Livnat Peer <lpeer(a)redhat.com> wrote:
> On 12/27/2011 05:22 PM, Miki Kenneth wrote:
>> Few points:
>> - From requirement perspective - 0-10 scale is OK too.
>> - There is an RFE to allow manual SPM selection, let's make sure that we
clarify how we do that in the scenarios.
>> - There is a case were all Hosts are set as "no SPM" (-1), user should
be notify (on the last host?)
>
> Hi Miki,
> Can you please elaborate on this validation.
> When we edit a host it is currently a requirement that the host will be
> in maintenance.
> So what do you think the validation should be?
That there is at least one host in the cluster that can become spm.
What does the last host means? it is in maintenance mode, not taking
part as SPM candidate ATM ?!
It can be in the process of moving to another DC, for example.
Until the host is activated there is no value in validating it's SPM
priority. When the host is activated there is no point in this
validation as we simply add a host to the DC, I don't think failing
host-activation because of it's SPM priority is a valid flow.
in short - I don't see where this validation can be valuable.
>
>
> Livnat
>
>> - Need to be able to view in the GUI:
>> - the SPM priority for all Hosts, on the GRID?
>> - would love to have the spm-priority avail in the search criteria, so I would
serach for all hosts that spm-priority==0/-1
>>
>>
>>
>> Miki
>>
>>
>> ----- Original Message -----
>>> From: "Muli Salem" <msalem(a)redhat.com>
>>> To: engine-devel(a)ovirt.org
>>> Sent: Tuesday, December 27, 2011 3:16:46 PM
>>> Subject: [Engine-devel] SPM Priority Design - Wiki Page
>>>
>>> Hi all,
>>>
>>> In the link below there is a wiki page describing the requirements
>>> and
>>> design of the SPM Priority feature.
>>> The feature allows the admin to define priorities between hosts
>>> regarding the SPM selection process
>>>
>>> http://www.ovirt.org/wiki/Features/SPMPriority
>>>
>>> Please feel free to share your comments.
>>>
>>> Thanks,
>>> Muli
>>> _______________________________________________
>>> 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
>
2:25 p.m.
On 12/27/2011 05:22 PM, Miki Kenneth wrote:
Few points:
- From requirement perspective - 0-10 scale is OK too.
UI-wise Isn't High-Medium-Low enough? Unless we are going to credit some
with extra points (for example, for having a bond) or take off points
(for not being connected to the ISO domain, for example) ?
We can set in the engine 'High=8, Medium=5, Low=2' and have the API set
finer granularity if desired.
BTW, I'd do the 2nd order by latency to the master domain, not random.
Y.
- There is an RFE to allow manual SPM selection, let's make sure
that we clarify how we do that in the scenarios.
- There is a case were all Hosts are set as "no SPM" (-1), user should be
notify (on the last host?)
- Need to be able to view in the GUI:
- the SPM priority for all Hosts, on the GRID?
- would love to have the spm-priority avail in the search criteria, so I would serach
for all hosts that spm-priority==0/-1
Miki
----- Original Message -----
> From: "Muli Salem"<msalem(a)redhat.com>
> To: engine-devel(a)ovirt.org
> Sent: Tuesday, December 27, 2011 3:16:46 PM
> Subject: [Engine-devel] SPM Priority Design - Wiki Page
>
> Hi all,
>
> In the link below there is a wiki page describing the requirements
> and
> design of the SPM Priority feature.
> The feature allows the admin to define priorities between hosts
> regarding the SPM selection process
>
> http://www.ovirt.org/wiki/Features/SPMPriority
>
> Please feel free to share your comments.
>
> Thanks,
> Muli
> _______________________________________________
> 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
5:41 a.m.
On 12/27/2011 05:22 PM, Miki Kenneth wrote:
Few points:
- From requirement perspective - 0-10 scale is OK too.
- There is an RFE to allow manual SPM selection, let's make sure that we clarify how
we do that in the scenarios.
- There is a case were all Hosts are set as "no SPM" (-1), user should be
notify (on the last host?)
SPM is DC level, not cluster level.
- Need to be able to view in the GUI:
- the SPM priority for all Hosts, on the GRID?
isn't this cluttering the hosts grid? general subtab maybe?
9:05 a.m.
On 12/29/2011 12:41 PM, Itamar Heim wrote:
On 12/27/2011 05:22 PM, Miki Kenneth wrote:
> Few points:
> - From requirement perspective - 0-10 scale is OK too.
> - There is an RFE to allow manual SPM selection, let's make sure that
> we clarify how we do that in the scenarios.
> - There is a case were all Hosts are set as "no SPM" (-1), user
> should be notify (on the last host?)
SPM is DC level, not cluster level.
> - Need to be able to view in the GUI:
> - the SPM priority for all Hosts, on the GRID?
isn't this cluttering the hosts grid? general subtab maybe?
Unless you re-use the currently almost useless 'SPM status' column,
renaming it to 'SPM priority' and have it with High/Low/Med/SPM values.
Y.
_______________________________________________
Engine-devel mailing list
Engine-devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
9:11 a.m.
----- Original Message -----
From: "Yaniv Kaul" <ykaul(a)redhat.com>
To: "Itamar Heim" <iheim(a)redhat.com>
Cc: "Miki Kenneth" <mkenneth(a)redhat.com>, engine-devel(a)ovirt.org
Sent: Thursday, December 29, 2011 4:05:05 PM
Subject: Re: [Engine-devel] SPM Priority Design - Wiki Page
On 12/29/2011 12:41 PM, Itamar Heim wrote:
> On 12/27/2011 05:22 PM, Miki Kenneth wrote:
>> Few points:
>> - From requirement perspective - 0-10 scale is OK too.
>> - There is an RFE to allow manual SPM selection, let's make sure
>> that
>> we clarify how we do that in the scenarios.
>> - There is a case were all Hosts are set as "no SPM" (-1), user
>> should be notify (on the last host?)
>
> SPM is DC level, not cluster level.
So?
>
>> - Need to be able to view in the GUI:
>> - the SPM priority for all Hosts, on the GRID?
>
> isn't this cluttering the hosts grid? general subtab maybe?
Unless you re-use the currently almost useless 'SPM status' column,
renaming it to 'SPM priority' and have it with High/Low/Med/SPM
values.
You need to see the SPM priority (for the DC) in one view in order to
compare between Hosts,
Otherwise, you will have to switch between all hosts in order to make sure you have
selected the correct Hosts from all the rest.
It can be sub-tab if we have search....
Y.
> _______________________________________________
> Engine-devel mailing list
> Engine-devel(a)ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
9:13 a.m.
On 12/29/2011 04:11 PM, Miki Kenneth wrote:
----- Original Message -----
> From: "Yaniv Kaul"<ykaul(a)redhat.com>
> To: "Itamar Heim"<iheim(a)redhat.com>
> Cc: "Miki Kenneth"<mkenneth(a)redhat.com>, engine-devel(a)ovirt.org
> Sent: Thursday, December 29, 2011 4:05:05 PM
> Subject: Re: [Engine-devel] SPM Priority Design - Wiki Page
>
> On 12/29/2011 12:41 PM, Itamar Heim wrote:
>> On 12/27/2011 05:22 PM, Miki Kenneth wrote:
>>> Few points:
>>> - From requirement perspective - 0-10 scale is OK too.
>>> - There is an RFE to allow manual SPM selection, let's make sure
>>> that
>>> we clarify how we do that in the scenarios.
>>> - There is a case were all Hosts are set as "no SPM" (-1), user
>>> should be notify (on the last host?)
>> SPM is DC level, not cluster level.
So?
>>> - Need to be able to view in the GUI:
>>> - the SPM priority for all Hosts, on the GRID?
>> isn't this cluttering the hosts grid? general subtab maybe?
>
> Unless you re-use the currently almost useless 'SPM status' column,
> renaming it to 'SPM priority' and have it with High/Low/Med/SPM
> values.
You need to see the SPM priority (for the DC) in one view in order to compare between
Hosts,
Otherwise, you will have to switch between all hosts in order to make sure you have
selected the correct Hosts from all the rest.
It can be sub-tab if we have search....
My suggestion allows you to see the SPM priority for the DC. Simply be
on the relevant DC on the tree, and you should be able to sort by 'SPM'
column the hosts.
Y.
> Y.
>
>> _______________________________________________
>> Engine-devel mailing list
>> Engine-devel(a)ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>
9:16 a.m.
----- Original Message -----
From: "Yaniv Kaul" <ykaul(a)redhat.com>
To: "Miki Kenneth" <mkenneth(a)redhat.com>
Cc: engine-devel(a)ovirt.org, "Itamar Heim" <iheim(a)redhat.com>
Sent: Thursday, December 29, 2011 4:13:26 PM
Subject: Re: [Engine-devel] SPM Priority Design - Wiki Page
On 12/29/2011 04:11 PM, Miki Kenneth wrote:
>
> ----- Original Message -----
>> From: "Yaniv Kaul"<ykaul(a)redhat.com>
>> To: "Itamar Heim"<iheim(a)redhat.com>
>> Cc: "Miki Kenneth"<mkenneth(a)redhat.com>, engine-devel(a)ovirt.org
>> Sent: Thursday, December 29, 2011 4:05:05 PM
>> Subject: Re: [Engine-devel] SPM Priority Design - Wiki Page
>>
>> On 12/29/2011 12:41 PM, Itamar Heim wrote:
>>> On 12/27/2011 05:22 PM, Miki Kenneth wrote:
>>>> Few points:
>>>> - From requirement perspective - 0-10 scale is OK too.
>>>> - There is an RFE to allow manual SPM selection, let's make sure
>>>> that
>>>> we clarify how we do that in the scenarios.
>>>> - There is a case were all Hosts are set as "no SPM" (-1),
user
>>>> should be notify (on the last host?)
>>> SPM is DC level, not cluster level.
> So?
>>>> - Need to be able to view in the GUI:
>>>> - the SPM priority for all Hosts, on the GRID?
>>> isn't this cluttering the hosts grid? general subtab maybe?
>>
>> Unless you re-use the currently almost useless 'SPM status'
>> column,
>> renaming it to 'SPM priority' and have it with High/Low/Med/SPM
>> values.
> You need to see the SPM priority (for the DC) in one view in order
> to compare between Hosts,
> Otherwise, you will have to switch between all hosts in order to
> make sure you have selected the correct Hosts from all the rest.
> It can be sub-tab if we have search....
My suggestion allows you to see the SPM priority for the DC. Simply
be
on the relevant DC on the tree, and you should be able to sort by
'SPM'
column the hosts.
I like it (was thinking about it myself.... :)
Y.
>> Y.
>>
>>> _______________________________________________
>>> Engine-devel mailing list
>>> Engine-devel(a)ovirt.org
>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>
9:34 a.m.
----- Original Message -----
From: "Itamar Heim" <iheim(a)redhat.com>
To: "Miki Kenneth" <mkenneth(a)redhat.com>
Cc: engine-devel(a)ovirt.org
Sent: Thursday, December 29, 2011 5:41:41 AM
Subject: Re: [Engine-devel] SPM Priority Design - Wiki Page
On 12/27/2011 05:22 PM, Miki Kenneth wrote:
> Few points:
> - From requirement perspective - 0-10 scale is OK too.
> - There is an RFE to allow manual SPM selection, let's make sure
> that we clarify how we do that in the scenarios.
> - There is a case were all Hosts are set as "no SPM" (-1), user
> should be notify (on the last host?)
I don't agree with/understand the requirements
<snip>
- Enable setting a priority between -1 and 100 for a host (100 is the highest, -1 means
never to choose this host).
- When SPM selection process takes place, use the SPM priority to select an SPM.
- Default for upgrading ovirt will be 50.
</snip>
Here we are asking the user to define priorities for the SPM selection. A user should be
able to influence the selection but the actual choice should come down to runtime status.
If Host A us running 100 VMs and host B is running 50 then it seems more efficient for B
to be the SPM rather than A
If Host C has multiple storage paths to the LUN then it seems a better fit than host B
that has only one path.
We need to step back and review the requirements here.
Today SPM selection is random, that certainly needs to change but a user defining
priorities is overly complex and won't solve the runtime selection issue.
We need to start by defining an algorithm for selecting the SPM independent of user
input.
At selection time I'd suggest that we at least need to consider number of paths to the
storage (for block based) number of VMs on that host, perhaps #cores?
Perhaps we should dynamically create a score for a host that takes these factors into
account, each may get higher rating - eg. maybe # storage paths is more important that #
cores ?
On top of this we can add some user defined preference that plays into the score. For
example a user can say "this host can NEVER be an SPM" or can set a preference -
eg. "Preferred SPM" or perhaps even "always SPM"
This algorithm would apply for automated selection of SPMs but a user should be allowed to
override this and at runtime say "make this node the SPM now"
SPM is DC level, not cluster level.
> - Need to be able to view in the GUI:
> - the SPM priority for all Hosts, on the GRID?
isn't this cluttering the hosts grid? general subtab maybe?
_______________________________________________
Engine-devel mailing list
Engine-devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
9:47 a.m.
On 12/29/2011 04:34 PM, Andrew Cathrow wrote:
----- Original Message -----
> From: "Itamar Heim"<iheim(a)redhat.com>
> To: "Miki Kenneth"<mkenneth(a)redhat.com>
> Cc: engine-devel(a)ovirt.org
> Sent: Thursday, December 29, 2011 5:41:41 AM
> Subject: Re: [Engine-devel] SPM Priority Design - Wiki Page
>
> On 12/27/2011 05:22 PM, Miki Kenneth wrote:
>> Few points:
>> - From requirement perspective - 0-10 scale is OK too.
>> - There is an RFE to allow manual SPM selection, let's make sure
>> that we clarify how we do that in the scenarios.
>> - There is a case were all Hosts are set as "no SPM" (-1), user
>> should be notify (on the last host?)
I don't agree with/understand the requirements
<snip>
- Enable setting a priority between -1 and 100 for a host (100 is the highest, -1 means
never to choose this host).
- When SPM selection process takes place, use the SPM priority to select an SPM.
- Default for upgrading ovirt will be 50.
</snip>
Here we are asking the user to define priorities for the SPM selection. A user should be
able to influence the selection but the actual choice should come down to runtime status.
If Host A us running 100 VMs and host B is running 50 then it seems more efficient for B
to be the SPM rather than A
If Host C has multiple storage paths to the LUN then it seems a better fit than host B
that has only one path.
We need to step back and review the requirements here.
Today SPM selection is random, that certainly needs to change but a user defining
priorities is overly complex and won't solve the runtime selection issue.
We need to start by defining an algorithm for selecting the SPM independent of user
input.
At selection time I'd suggest that we at least need to consider number of paths to
the storage (for block based) number of VMs on that host, perhaps #cores?
Paths to which storage domain? the master? all? on average?
Do you prefer 2x10Gb iSCSI connection, or 4x1Gb?
- What about available bandwidth to the storage (assuming it may be
capped and compete with VM IO traffic) ?
- Latency?
Perhaps we should dynamically create a score for a host that takes
these factors into account, each may get higher rating - eg. maybe # storage paths is more
important that # cores ?
This is why I've suggested High(8)-Med(5)-Low(2) and add dynamically the
system scoring, with whatever params we get to eventually. 'Never' could
be 0, 'Always' could be '10'.
Y.
On top of this we can add some user defined preference that plays into the score. For
example a user can say "this host can NEVER be an SPM" or can set a preference -
eg. "Preferred SPM" or perhaps even "always SPM"
This algorithm would apply for automated selection of SPMs but a user should be allowed
to override this and at runtime say "make this node the SPM now"
> SPM is DC level, not cluster level.
>
>> - Need to be able to view in the GUI:
>> - the SPM priority for all Hosts, on the GRID?
> isn't this cluttering the hosts grid? general subtab maybe?
> _______________________________________________
> 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
9:51 a.m.
----- Original Message -----
From: "Yaniv Kaul" <ykaul(a)redhat.com>
To: "Andrew Cathrow" <acathrow(a)redhat.com>
Cc: engine-devel(a)ovirt.org
Sent: Thursday, December 29, 2011 9:47:24 AM
Subject: Re: [Engine-devel] SPM Priority Design - Wiki Page
On 12/29/2011 04:34 PM, Andrew Cathrow wrote:
>
> ----- Original Message -----
>> From: "Itamar Heim"<iheim(a)redhat.com>
>> To: "Miki Kenneth"<mkenneth(a)redhat.com>
>> Cc: engine-devel(a)ovirt.org
>> Sent: Thursday, December 29, 2011 5:41:41 AM
>> Subject: Re: [Engine-devel] SPM Priority Design - Wiki Page
>>
>> On 12/27/2011 05:22 PM, Miki Kenneth wrote:
>>> Few points:
>>> - From requirement perspective - 0-10 scale is OK too.
>>> - There is an RFE to allow manual SPM selection, let's make sure
>>> that we clarify how we do that in the scenarios.
>>> - There is a case were all Hosts are set as "no SPM" (-1), user
>>> should be notify (on the last host?)
> I don't agree with/understand the requirements
> <snip>
> - Enable setting a priority between -1 and 100 for a host (100 is
> the highest, -1 means never to choose this host).
> - When SPM selection process takes place, use the SPM priority to
> select an SPM.
> - Default for upgrading ovirt will be 50.
> </snip>
>
> Here we are asking the user to define priorities for the SPM
> selection. A user should be able to influence the selection but
> the actual choice should come down to runtime status.
> If Host A us running 100 VMs and host B is running 50 then it seems
> more efficient for B to be the SPM rather than A
> If Host C has multiple storage paths to the LUN then it seems a
> better fit than host B that has only one path.
>
> We need to step back and review the requirements here.
>
> Today SPM selection is random, that certainly needs to change but a
> user defining priorities is overly complex and won't solve the
> runtime selection issue.
>
> We need to start by defining an algorithm for selecting the SPM
> independent of user input.
> At selection time I'd suggest that we at least need to consider
> number of paths to the storage (for block based) number of VMs on
> that host, perhaps #cores?
Paths to which storage domain? the master? all? on average?
Do you prefer 2x10Gb iSCSI connection, or 4x1Gb?
- What about available bandwidth to the storage (assuming it may be
capped and compete with VM IO traffic) ?
- Latency?
Yep, exactly - we need to use these kind of inputs into the algorithm and these can change
hence the need to do this more dynamically rather than user selection which is invariably
wrong.
> Perhaps we should dynamically create a score for a host that takes
> these factors into account, each may get higher rating - eg. maybe
> # storage paths is more important that # cores ?
This is why I've suggested High(8)-Med(5)-Low(2) and add dynamically
the
system scoring, with whatever params we get to eventually. 'Never'
could
be 0, 'Always' could be '10'.
Yep, the big change that I'm suggesting is that these scores are only an input to the
algorithm not the whole basis for selection.
Y.
>
>
> On top of this we can add some user defined preference that plays
> into the score. For example a user can say "this host can NEVER be
> an SPM" or can set a preference - eg. "Preferred SPM" or perhaps
> even "always SPM"
>
> This algorithm would apply for automated selection of SPMs but a
> user should be allowed to override this and at runtime say "make
> this node the SPM now"
>
>
>
>> SPM is DC level, not cluster level.
>>
>>> - Need to be able to view in the GUI:
>>> - the SPM priority for all Hosts, on the GRID?
>> isn't this cluttering the hosts grid? general subtab maybe?
>> _______________________________________________
>> 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
8:15 a.m.
New subject: [Engine-devel] restapi - removing template from a specified storage-domain
I'm about to implement removing template from a specified storage-domain.
A template is meta-data + disks. The meta-data is in the ovirt-engine database, the disks
are (potentially) scattered across several storage-domains. Removing a template from a
specified storage domain means removing that template's disks from that
storage-domain. API-wise, it's better to enable the deletion at the single-disk level,
otherwise rollback and all sorts of unnecessary complexities enter the picture. So what I
would like to go forward with is the following API:
DELETE /api/templates/{template_xxx}/disks/{disk_yyy}
<storage_domain id="domain_zzz"/>
This means: "delete the disk 'disk_yyy' (which belongs to template
'template_xxx' from the storage-domain 'domain_zzz'.
Any comments?
Thanks,
Ori.
10:59 a.m.
New subject: [Engine-devel] restapi - removing template from a specified storage-domain
----- Original Message -----
From: "Ori Liel" <oliel(a)redhat.com>
To: engine-devel(a)ovirt.org
Sent: Sunday, January 1, 2012 3:15:18 PM
Subject: [Engine-devel] restapi - removing template from a specified storage-domain
I'm about to implement removing template from a specified
storage-domain.
A template is meta-data + disks. The meta-data is in the ovirt-engine
database, the disks are (potentially) scattered across several
storage-domains. Removing a template from a specified storage domain
means removing that template's disks from that storage-domain.
API-wise, it's better to enable the deletion at the single-disk
level, otherwise rollback and all sorts of unnecessary complexities
enter the picture. So what I would like to go forward with is the
following API:
DELETE /api/templates/{template_xxx}/disks/{disk_yyy}
<storage_domain id="domain_zzz"/>
This means: "delete the disk 'disk_yyy' (which belongs to template
'template_xxx' from the storage-domain 'domain_zzz'.
Any comments?
just that CURRENT backend only allows removing per storage domain(s),
this functionallity is in plan, though (if that was what you meant..)
Thanks,
Ori.
_______________________________________________
Engine-devel mailing list
Engine-devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
2:44 p.m.
New subject: [Engine-devel] restapi - removing template from a specified storage-domain
On 01/01/2012 05:59 PM, Omer Frenkel wrote:
----- Original Message -----
> From: "Ori Liel"<oliel(a)redhat.com>
> To: engine-devel(a)ovirt.org
> Sent: Sunday, January 1, 2012 3:15:18 PM
> Subject: [Engine-devel] restapi - removing template from a specified storage-domain
>
> I'm about to implement removing template from a specified
> storage-domain.
>
> A template is meta-data + disks. The meta-data is in the ovirt-engine
> database, the disks are (potentially) scattered across several
> storage-domains. Removing a template from a specified storage domain
> means removing that template's disks from that storage-domain.
> API-wise, it's better to enable the deletion at the single-disk
> level, otherwise rollback and all sorts of unnecessary complexities
> enter the picture. So what I would like to go forward with is the
> following API:
>
> DELETE /api/templates/{template_xxx}/disks/{disk_yyy}
>
> <storage_domain id="domain_zzz"/>
>
> This means: "delete the disk 'disk_yyy' (which belongs to template
> 'template_xxx' from the storage-domain 'domain_zzz'.
>
> Any comments?
just that CURRENT backend only allows removing per storage domain(s),
this functionallity is in plan, though (if that was what you meant..)
I think the implementation for this can/should wait for the new support
in the backend if makes more sense api-wise, rather than implementing
based on the current limitations and later changing the api.
the question is with the move to multiple storage domains, will an
atomic[1] verb to delete all disks from a specific storage domain (per
vm/template) will be provided, or only per disk.
[1] well, delete is rollforward, so not sure i understand Ori's point
about rollback. OTOH, the API should probably behave the same for
move/copy of disks, etc.
4:29 a.m.
New subject: [Engine-devel] restapi - removing template from a specified storage-domain
----- Original Message -----
From: "Itamar Heim" <iheim(a)redhat.com>
To: "Omer Frenkel" <ofrenkel(a)redhat.com>
Cc: "Ori Liel" <oliel(a)redhat.com>, engine-devel(a)ovirt.org, "Geert
Jansen" <gjansen(a)redhat.com>
Sent: Sunday, January 1, 2012 9:44:47 PM
Subject: Re: [Engine-devel] restapi - removing template from a specified storage-domain
On 01/01/2012 05:59 PM, Omer Frenkel wrote:
>
>
> ----- Original Message -----
>> From: "Ori Liel"<oliel(a)redhat.com>
>> To: engine-devel(a)ovirt.org
>> Sent: Sunday, January 1, 2012 3:15:18 PM
>> Subject: [Engine-devel] restapi - removing template from a
specified storage-domain
>>
>> I'm about to implement removing template from a specified
>> storage-domain.
>>
>> A template is meta-data + disks. The meta-data is in the ovirt-engine
>> database, the disks are (potentially) scattered across several
>> storage-domains. Removing a template from a specified storage domain
>> means removing that template's disks from that storage-domain.
>> API-wise, it's better to enable the deletion at the single-disk
>> level, otherwise rollback and all sorts of unnecessary complexities
>> enter the picture. So what I would like to go forward with is the
>> following API:
>>
>> DELETE /api/templates/{template_xxx}/disks/{disk_yyy}
>>
>> <storage_domain id="domain_zzz"/>
>>
>> This means: "delete the disk 'disk_yyy' (which belongs to template
>> 'template_xxx' from the storage-domain 'domain_zzz'.
>>
>> Any comments?
>
> just that CURRENT backend only allows removing per storage domain(s),
> this functionallity is in plan, though (if that was what you meant..)
I think the implementation for this can/should wait for the new support
in the backend if makes more sense api-wise, rather than implementing
based on the current limitations and later changing the api.
the question is with the move to multiple storage domains, will an
atomic[1] verb to delete all disks from a specific storage domain (per
vm/template) will be provided, or only per disk.
[1] well, delete is rollforward, so not sure i understand Ori's point
about rollback. OTOH, the API should probably behave the same for
move/copy of disks, etc.
What I meant by rollback issues is: how do we handle a scenario in which
deletion of disk1 succeeds, but then deletion of disk2 fails?
When you say 'delete is rollforward', I assume you mean that delete
operations don't require roll-back, and that even if only partial deletion
was done - that's ok (I'm verifying because I'm not familiar with the term
roll-forward).
Assuming this is what you meant, I still prefer the per-disk deletion,
because the scenario of partial success still requires extra handling:
1) Backend would have to generate a complex message that disk1 was
deleted but disk2 not.
2) REST-API user might resend the same request to retry - and fail because
this time disk1 does not exist.
11:17 a.m.
On 12/29/2011 04:34 PM, Andrew Cathrow wrote:
----- Original Message -----
> From: "Itamar Heim"<iheim(a)redhat.com>
> To: "Miki Kenneth"<mkenneth(a)redhat.com>
> Cc: engine-devel(a)ovirt.org
> Sent: Thursday, December 29, 2011 5:41:41 AM
> Subject: Re: [Engine-devel] SPM Priority Design - Wiki Page
>
> On 12/27/2011 05:22 PM, Miki Kenneth wrote:
>> Few points:
>> - From requirement perspective - 0-10 scale is OK too.
>> - There is an RFE to allow manual SPM selection, let's make sure
>> that we clarify how we do that in the scenarios.
>> - There is a case were all Hosts are set as "no SPM" (-1), user
>> should be notify (on the last host?)
I don't agree with/understand the requirements
<snip>
- Enable setting a priority between -1 and 100 for a host (100 is the highest, -1 means
never to choose this host).
- When SPM selection process takes place, use the SPM priority to select an SPM.
- Default for upgrading ovirt will be 50.
</snip>
Here we are asking the user to define priorities for the SPM selection. A user should be
able to influence the selection but the actual choice should come down to runtime status.
If Host A us running 100 VMs and host B is running 50 then it seems more efficient for B
to be the SPM rather than A
If Host C has multiple storage paths to the LUN then it seems a better fit than host B
that has only one path.
We need to step back and review the requirements here.
Today SPM selection is random, that certainly needs to change but a user defining
priorities is overly complex and won't solve the runtime selection issue.
We need to start by defining an algorithm for selecting the SPM independent of user
input.
At selection time I'd suggest that we at least need to consider number of paths to
the storage (for block based) number of VMs on that host, perhaps #cores?
Perhaps we should dynamically create a score for a host that takes these factors into
account, each may get higher rating - eg. maybe # storage paths is more important that #
cores ?
On top of this we can add some user defined preference that plays into the score. For
example a user can say "this host can NEVER be an SPM" or can set a preference -
eg. "Preferred SPM" or perhaps even "always SPM"
This algorithm would apply for automated selection of SPMs but a user should be allowed
to override this and at runtime say "make this node the SPM now"
or we limit this to only allowing for now "allow using this host as SPM"
checkbox, but keep the values as integer rather than boolean to allow
this in the future easily, but for now only allow to flag which hosts
should not become SPMs.
>
> SPM is DC level, not cluster level.
>
>> - Need to be able to view in the GUI:
>> - the SPM priority for all Hosts, on the GRID?
>
> isn't this cluttering the hosts grid? general subtab maybe?
> _______________________________________________
> 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
4741
days inactive
4747
days old
18 comments
8 participants
participants (8)
-
Andrew Cathrow -
Itamar Heim -
Livnat Peer -
Miki Kenneth -
Muli Salem -
Omer Frenkel -
Ori Liel -
Yaniv Kaul