Re: [Engine-devel] [UX] how to design a bar/line chart?

[Lior Vernia]

On 07/11/13 09:26, Tomas Jelinek wrote:
> 
> 
> - Original Message -
>> From: "Lior Vernia" 
>> To: "Einav Cohen" 
>> Cc: "Eldan Hildesheim" , "engine-devel" 
>> , "info" 
>> Sent: Thursday, November 7, 2013 8:03:25 AM
>> Subject: Re: [Engine-devel] [UX] how to design a bar/line chart?
>>
>> Sorry, obviously I meant RAM usage...
>>
>> On 07/11/13 08:51, Lior Vernia wrote:
>>>
>>>
>>> On 06/11/13 16:26, Einav Cohen wrote:
 Hi Tomas,

 Like Itamar, I think that a line chart is a better idea, and that a
 chart per monitored fact (rather than a combined chart) is better.

>> the statistics readable enough. Maybe if you hover the chart it could
>> pop
>> up a bigger version of the chart? Or not needed?

 this is a nice-to-have, I think, definitely not needed.

>> - Would it be enough to have it in one color? Or should it be something
>> like "the bigger the utilization the more red"?

 question is what will happen when there are a lot of "jumps": let's say
 that the graph changes from 0% to 100% to 0% to 100% and so on... what
 will be painted red? the entire line, but only in the periods that it
 jumps to 100%? only the parts of line that are in 100%?
 maybe a single color is enough.

 I have another concern about this feature: currently, the GUI's most
 frequent
 refresh rate available is 5 seconds, which means that the line will
 "change"
 only every 5 seconds, which would be more noticeably slow when displayed
 in
 a form of a line chart (not even talking about lower frequencies).
 Moreover, I am not sure at what rate the VM statistics are pulled from
 VDSM,
 but if it is 10 seconds or 15 seconds, it means that the line in the GUI
 will
 be "flat" for every 2 reads / 3 reads, which is not so good, I think.

 any thoughts around that?

>>>
>>> If this is indeed an issue, it could be easily solved by delaying the
>>> presentation of the value obtained from VDSM, and at each moment present
>>> a linear interpolation of the value between the previous input and the
>>> current input.
>>>
>>> Formally put, let's say T is the measurement period time. If the value
>>> at time t is f(t), then at time t-T <= t' <= T we would display the
>>> value f(t-2T) + [f(t-T) - f(t-2T]*t'/T, where we control the increment
>>> rate of t'.
>>>
>>> For example, let's say we get a new value from VDSM every 15 seconds. 30
>>> seconds ago the CPU usage was 50MB, 15 seconds ago 100MB and now 200MB.
>>> We decided to update the graph every 3 seconds.
>>>
>>> 15 seconds ago we displayed 50MB (the value from 30 seconds ago). 12
>>> seconds ago we displayed 60MB, 9 seconds ago 70MB, 6 seconds ago 80MB, 3
>>> seconds ago 90MB, and now we display 100MB (which is again late by 15
>>> seconds). We will only display 200MB in 15 seconds, after increasing our
>>> displayed value by 20MB every 3 seconds.
> 
> Hey Lior,
> 
> good idea and certainly better than just draw the current value at each 
> refresh.
> We should certainly do this.

Just pointing out that it's not necessarily better, as we never actually
draw the current value, we're always late by T (otherwise we'd have
continuity issues as we don't know what future value is coming in the
next measurement). The added benefit is only the feel of constant
updates, at a time period that is independent of the VDSM update period.

It might be better to just add a dot whenever we get a new measurement,
and have the dots close enough together for it to look like a nice
graph, and not have it updated constantly.

> 
> But this is only one side of the problem - how to visualize it. The question 
> is
> how useful the data are if we sample them once in 15 secs. Imagine that you 
> have
> peeks every ~10 secs which uses 100% of your cpu for ~2 secs. With the 
> sampling 
> each 15 secs you will see any peek only by luck and certainly not all of them.

Yep, agreed.

> 
> But I'm sure we are not the first facing this problem - adding [now the 
> correct ;) ]
> Martin as CC:
> 
> @Martin: does the VdsUpdateRunTimeInfo receive the CPU/memory samples at each 
> 15 secs
> or it receives some sort of average since the last update?
> 
>>>
 - Original Message -
> From: "Itamar Heim" 
> To: "Tomas Jelinek" , "engine-devel"
> 
> Sent: Tuesday, November 5, 2013 10:10:34 AM
> Subject: Re: [Engine-devel] [UX] how to design a bar/line chart?
>
> On 11/05/2013 11:50 AM, Tomas Jelinek wrote:
>> Hi all,
>>
>> There is a feature request [1] which aims to replace the resource
>> utilization graphs (for example the cpu utilization from vm tab) by some
>> which shows not only
>> the actual percentage which is not so useful by some monitor graph.
>>
>> I have the following concerns:
>> - I can think of a bar chart or a line chart and not sure what would be
>> better.
>> - Not sure if replacing t

Re: [Engine-devel] [UX] how to design a bar/line chart?

[Tomas Jelinek]

- Original Message -
> From: "Lior Vernia" 
> To: "Einav Cohen" 
> Cc: "Eldan Hildesheim" , "engine-devel" 
> , "info" 
> Sent: Thursday, November 7, 2013 8:03:25 AM
> Subject: Re: [Engine-devel] [UX] how to design a bar/line chart?
> 
> Sorry, obviously I meant RAM usage...
> 
> On 07/11/13 08:51, Lior Vernia wrote:
> > 
> > 
> > On 06/11/13 16:26, Einav Cohen wrote:
> >> Hi Tomas,
> >>
> >> Like Itamar, I think that a line chart is a better idea, and that a
> >> chart per monitored fact (rather than a combined chart) is better.
> >>
>  the statistics readable enough. Maybe if you hover the chart it could
>  pop
>  up a bigger version of the chart? Or not needed?
> >>
> >> this is a nice-to-have, I think, definitely not needed.
> >>
>  - Would it be enough to have it in one color? Or should it be something
>  like "the bigger the utilization the more red"?
> >>
> >> question is what will happen when there are a lot of "jumps": let's say
> >> that the graph changes from 0% to 100% to 0% to 100% and so on... what
> >> will be painted red? the entire line, but only in the periods that it
> >> jumps to 100%? only the parts of line that are in 100%?
> >> maybe a single color is enough.
> >>
> >> I have another concern about this feature: currently, the GUI's most
> >> frequent
> >> refresh rate available is 5 seconds, which means that the line will
> >> "change"
> >> only every 5 seconds, which would be more noticeably slow when displayed
> >> in
> >> a form of a line chart (not even talking about lower frequencies).
> >> Moreover, I am not sure at what rate the VM statistics are pulled from
> >> VDSM,
> >> but if it is 10 seconds or 15 seconds, it means that the line in the GUI
> >> will
> >> be "flat" for every 2 reads / 3 reads, which is not so good, I think.
> >>
> >> any thoughts around that?
> >>
> > 
> > If this is indeed an issue, it could be easily solved by delaying the
> > presentation of the value obtained from VDSM, and at each moment present
> > a linear interpolation of the value between the previous input and the
> > current input.
> > 
> > Formally put, let's say T is the measurement period time. If the value
> > at time t is f(t), then at time t-T <= t' <= T we would display the
> > value f(t-2T) + [f(t-T) - f(t-2T]*t'/T, where we control the increment
> > rate of t'.
> > 
> > For example, let's say we get a new value from VDSM every 15 seconds. 30
> > seconds ago the CPU usage was 50MB, 15 seconds ago 100MB and now 200MB.
> > We decided to update the graph every 3 seconds.
> > 
> > 15 seconds ago we displayed 50MB (the value from 30 seconds ago). 12
> > seconds ago we displayed 60MB, 9 seconds ago 70MB, 6 seconds ago 80MB, 3
> > seconds ago 90MB, and now we display 100MB (which is again late by 15
> > seconds). We will only display 200MB in 15 seconds, after increasing our
> > displayed value by 20MB every 3 seconds.

Hey Lior,

good idea and certainly better than just draw the current value at each refresh.
We should certainly do this.

But this is only one side of the problem - how to visualize it. The question is
how useful the data are if we sample them once in 15 secs. Imagine that you have
peeks every ~10 secs which uses 100% of your cpu for ~2 secs. With the sampling 
each 15 secs you will see any peek only by luck and certainly not all of them.

But I'm sure we are not the first facing this problem - adding [now the correct 
;) ]
Martin as CC:

@Martin: does the VdsUpdateRunTimeInfo receive the CPU/memory samples at each 
15 secs
or it receives some sort of average since the last update?

> > 
> >> - Original Message -
> >>> From: "Itamar Heim" 
> >>> To: "Tomas Jelinek" , "engine-devel"
> >>> 
> >>> Sent: Tuesday, November 5, 2013 10:10:34 AM
> >>> Subject: Re: [Engine-devel] [UX] how to design a bar/line chart?
> >>>
> >>> On 11/05/2013 11:50 AM, Tomas Jelinek wrote:
>  Hi all,
> 
>  There is a feature request [1] which aims to replace the resource
>  utilization graphs (for example the cpu utilization from vm tab) by some
>  which shows not only
>  the actual percentage which is not so useful by some monitor graph.
> 
>  I have the following concerns:
>  - I can think of a bar chart or a line chart and not sure what would be
>  better.
>  - Not sure if replacing the current chart with a bar/line chart would
>  make
>  the statistics readable enough. Maybe if you hover the chart it could
>  pop
>  up a bigger version of the chart? Or not needed?
>  - Would it be enough to have it in one color? Or should it be something
>  like "the bigger the utilization the more red"?
> 
>  Please advise from the UX perspective. As soon as the final design will
>  be
>  a bit more clear I will provide a feature page.
> 
>  Thank you,
>  Tomas
> 
>  [1]: https://bugzilla.redhat.com/show_bug.cgi?id=803251
>  ___

Re: [Engine-devel] [UX] how to design a bar/line chart?

[Lior Vernia]

Sorry, obviously I meant RAM usage...

On 07/11/13 08:51, Lior Vernia wrote:
> 
> 
> On 06/11/13 16:26, Einav Cohen wrote:
>> Hi Tomas,
>>
>> Like Itamar, I think that a line chart is a better idea, and that a 
>> chart per monitored fact (rather than a combined chart) is better.
>>
 the statistics readable enough. Maybe if you hover the chart it could pop
 up a bigger version of the chart? Or not needed?
>>
>> this is a nice-to-have, I think, definitely not needed.
>>
 - Would it be enough to have it in one color? Or should it be something
 like "the bigger the utilization the more red"?
>>
>> question is what will happen when there are a lot of "jumps": let's say 
>> that the graph changes from 0% to 100% to 0% to 100% and so on... what 
>> will be painted red? the entire line, but only in the periods that it 
>> jumps to 100%? only the parts of line that are in 100%?
>> maybe a single color is enough.
>>
>> I have another concern about this feature: currently, the GUI's most 
>> frequent 
>> refresh rate available is 5 seconds, which means that the line will "change" 
>> only every 5 seconds, which would be more noticeably slow when displayed in 
>> a form of a line chart (not even talking about lower frequencies).
>> Moreover, I am not sure at what rate the VM statistics are pulled from VDSM, 
>> but if it is 10 seconds or 15 seconds, it means that the line in the GUI 
>> will 
>> be "flat" for every 2 reads / 3 reads, which is not so good, I think.
>>
>> any thoughts around that?
>>
> 
> If this is indeed an issue, it could be easily solved by delaying the
> presentation of the value obtained from VDSM, and at each moment present
> a linear interpolation of the value between the previous input and the
> current input.
> 
> Formally put, let's say T is the measurement period time. If the value
> at time t is f(t), then at time t-T <= t' <= T we would display the
> value f(t-2T) + [f(t-T) - f(t-2T]*t'/T, where we control the increment
> rate of t'.
> 
> For example, let's say we get a new value from VDSM every 15 seconds. 30
> seconds ago the CPU usage was 50MB, 15 seconds ago 100MB and now 200MB.
> We decided to update the graph every 3 seconds.
> 
> 15 seconds ago we displayed 50MB (the value from 30 seconds ago). 12
> seconds ago we displayed 60MB, 9 seconds ago 70MB, 6 seconds ago 80MB, 3
> seconds ago 90MB, and now we display 100MB (which is again late by 15
> seconds). We will only display 200MB in 15 seconds, after increasing our
> displayed value by 20MB every 3 seconds.
> 
>> - Original Message -
>>> From: "Itamar Heim" 
>>> To: "Tomas Jelinek" , "engine-devel" 
>>> 
>>> Sent: Tuesday, November 5, 2013 10:10:34 AM
>>> Subject: Re: [Engine-devel] [UX] how to design a bar/line chart?
>>>
>>> On 11/05/2013 11:50 AM, Tomas Jelinek wrote:
 Hi all,

 There is a feature request [1] which aims to replace the resource
 utilization graphs (for example the cpu utilization from vm tab) by some
 which shows not only
 the actual percentage which is not so useful by some monitor graph.

 I have the following concerns:
 - I can think of a bar chart or a line chart and not sure what would be
 better.
 - Not sure if replacing the current chart with a bar/line chart would make
 the statistics readable enough. Maybe if you hover the chart it could pop
 up a bigger version of the chart? Or not needed?
 - Would it be enough to have it in one color? Or should it be something
 like "the bigger the utilization the more red"?

 Please advise from the UX perspective. As soon as the final design will be
 a bit more clear I will provide a feature page.

 Thank you,
 Tomas

 [1]: https://bugzilla.redhat.com/show_bug.cgi?id=803251
 ___
 Engine-devel mailing list
 Engine-devel@ovirt.org
 http://lists.ovirt.org/mailman/listinfo/engine-devel

>>>
>>> a moving trend graph (just like fedora's system monitor for
>>> cpu/ram/network) is what i have in mind. so a line chart.
>>> you could have a single chart with different lines for cpu/ram/network,
>>> or what seems to be more common, a chart per monitored fact
>>> ___
>>> Engine-devel mailing list
>>> Engine-devel@ovirt.org
>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>>
>>>
>>>
>> ___
>> Engine-devel mailing list
>> Engine-devel@ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>
> ___
> Engine-devel mailing list
> Engine-devel@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 
___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel

Re: [Engine-devel] [UX] how to design a bar/line chart?

[Lior Vernia]

On 06/11/13 16:26, Einav Cohen wrote:
> Hi Tomas,
> 
> Like Itamar, I think that a line chart is a better idea, and that a 
> chart per monitored fact (rather than a combined chart) is better.
> 
>>> the statistics readable enough. Maybe if you hover the chart it could pop
>>> up a bigger version of the chart? Or not needed?
> 
> this is a nice-to-have, I think, definitely not needed.
> 
>>> - Would it be enough to have it in one color? Or should it be something
>>> like "the bigger the utilization the more red"?
> 
> question is what will happen when there are a lot of "jumps": let's say 
> that the graph changes from 0% to 100% to 0% to 100% and so on... what 
> will be painted red? the entire line, but only in the periods that it 
> jumps to 100%? only the parts of line that are in 100%?
> maybe a single color is enough.
> 
> I have another concern about this feature: currently, the GUI's most frequent 
> refresh rate available is 5 seconds, which means that the line will "change" 
> only every 5 seconds, which would be more noticeably slow when displayed in 
> a form of a line chart (not even talking about lower frequencies).
> Moreover, I am not sure at what rate the VM statistics are pulled from VDSM, 
> but if it is 10 seconds or 15 seconds, it means that the line in the GUI will 
> be "flat" for every 2 reads / 3 reads, which is not so good, I think.
> 
> any thoughts around that?
> 

If this is indeed an issue, it could be easily solved by delaying the
presentation of the value obtained from VDSM, and at each moment present
a linear interpolation of the value between the previous input and the
current input.

Formally put, let's say T is the measurement period time. If the value
at time t is f(t), then at time t-T <= t' <= T we would display the
value f(t-2T) + [f(t-T) - f(t-2T]*t'/T, where we control the increment
rate of t'.

For example, let's say we get a new value from VDSM every 15 seconds. 30
seconds ago the CPU usage was 50MB, 15 seconds ago 100MB and now 200MB.
We decided to update the graph every 3 seconds.

15 seconds ago we displayed 50MB (the value from 30 seconds ago). 12
seconds ago we displayed 60MB, 9 seconds ago 70MB, 6 seconds ago 80MB, 3
seconds ago 90MB, and now we display 100MB (which is again late by 15
seconds). We will only display 200MB in 15 seconds, after increasing our
displayed value by 20MB every 3 seconds.

> - Original Message -
>> From: "Itamar Heim" 
>> To: "Tomas Jelinek" , "engine-devel" 
>> 
>> Sent: Tuesday, November 5, 2013 10:10:34 AM
>> Subject: Re: [Engine-devel] [UX] how to design a bar/line chart?
>>
>> On 11/05/2013 11:50 AM, Tomas Jelinek wrote:
>>> Hi all,
>>>
>>> There is a feature request [1] which aims to replace the resource
>>> utilization graphs (for example the cpu utilization from vm tab) by some
>>> which shows not only
>>> the actual percentage which is not so useful by some monitor graph.
>>>
>>> I have the following concerns:
>>> - I can think of a bar chart or a line chart and not sure what would be
>>> better.
>>> - Not sure if replacing the current chart with a bar/line chart would make
>>> the statistics readable enough. Maybe if you hover the chart it could pop
>>> up a bigger version of the chart? Or not needed?
>>> - Would it be enough to have it in one color? Or should it be something
>>> like "the bigger the utilization the more red"?
>>>
>>> Please advise from the UX perspective. As soon as the final design will be
>>> a bit more clear I will provide a feature page.
>>>
>>> Thank you,
>>> Tomas
>>>
>>> [1]: https://bugzilla.redhat.com/show_bug.cgi?id=803251
>>> ___
>>> Engine-devel mailing list
>>> Engine-devel@ovirt.org
>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>>
>>
>> a moving trend graph (just like fedora's system monitor for
>> cpu/ram/network) is what i have in mind. so a line chart.
>> you could have a single chart with different lines for cpu/ram/network,
>> or what seems to be more common, a chart per monitored fact
>> ___
>> Engine-devel mailing list
>> Engine-devel@ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>
>>
>>
> ___
> Engine-devel mailing list
> Engine-devel@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 
___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel

Re: [Engine-devel] IMP: Regarding an issue while translating the error messages for gluster using ErrorTranslator class

[Shubhendu Tripathi]

On 11/06/2013 09:29 PM, Daniel Erez wrote:


- Original Message -

From: "Shubhendu Tripathi" 
To: "Daniel Erez" 
Cc: "engine-devel" , "Dusmant Pati" 
Sent: Wednesday, November 6, 2013 4:31:52 PM
Subject: Re: IMP: Regarding an issue while translating the error messages for 
gluster using ErrorTranslator class

On 11/06/2013 07:43 PM, Daniel Erez wrote:

- Original Message -

From: "Shubhendu Tripathi" 
To: de...@redhat.com, "engine-devel" 
Cc: "Dusmant Pati" 
Sent: Wednesday, November 6, 2013 12:07:34 PM
Subject: IMP: Regarding an issue while translating the error messages for
gluster using ErrorTranslator class

Hi,

In the case of Gluster, as there are no one to one mappings available
for all the error messages from Gluster, we set the error in the
VdcFault object as NULL.
We also populate the actual error from the Gluster as error message in
the fault object.

/getReturnValue().getExecuteFailedMessages().add(error);//
//getReturnValue().getFault().setMessage(error);//
//getReturnValue().getFault().setError(null);/

Because of above settings and the below code snippet in /Frontend.java/
class the error message as is gets displayed on the error dialog -
/
//public String translateVdcFault(final VdcFault fault) {//
//return
getVdsmErrorsTranslator().TranslateErrorTextSingle(fault.getError() ==
null//
//? fault.getMessage() : fault.getError().toString());//
//}//
/
Well and good till now !!

But while translation of the error messages, all the occurrences of "."
get replaced with "_".
This causes an issue for the gluster errors. If the error message sent
from gluster has "."s (say IP Address of a host or FQDN for a host),
that also gets replaced with "_" and the error message does not look
correct.

This mechanism of replacing [1] has been introduced to allow proper
message translation when retrieving a message key that contains dots.
E.g. AppErrors.properties -> VALIDATION.ROLES.NAME.MAX is translated
to VALIDATION_ROLES_NAME_MAX in AppErrors.java interface (as interface
signatures cannot contain dots. Note that this process shouldn't
address the message; i.e. only the key is examined for dots.

As you've mentioned VdsmErrorsTranslator I guess there's an issue
only when translating VdsmErrors messages.
Can you please send an example of a message usage?

One example of the error message which is shown on the dialog after
translation is as below -

/"Error while executin action Create Gluster Volume: Volume create
failed error: Staging failed on //*10_70_43_122_*//Error: /export/vol1-a
is already part of a volume"/

What are the keys that been sent from the engine (i.e. the message before 
translation)?
We set message code as NULL and error message is set as is whatever is 
received from VDSM. Message contains dots (".") as part of it.

Code snippet is shown below -

/getReturnValue().getExecuteFailedMessages().add(error);
getReturnValue().getFault().setMessage(error);
getReturnValue().getFault().setError(null);/



If you see the highlighted portion not only the dots in IP address but
also the full stop is changed to "_".

(and maybe try the same message using AppErrors instead)

There are no one to one mapping of these messages in AppErrors as they
arise randomly, so in such cases we throw the VDSM error message as is
on the dialog.

[1] ErrorTranslator -> translateErrorTextSingle()


Request your suggestion for handling such a case.

*PS: *One thing I can think of is, introducing a flag called
/isExternalError/ in /VdcFault/ class to identify if the source of the
fault is external. From Gluster we would set the flag as /true/, and
while replacement of "." with "_", if the flag is set it will not do the
replacements.

Regards,
Shubhendu





___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel

Re: [Engine-devel] [UX] how to design a bar/line chart?

[Einav Cohen]

Hi Malini,

> Why does the change in the line need to seem palpable every few seconds? I
> think the base requirement of how accurate the data is when a user looks at
> a grid has not changed.. just the data visualization. Right? So , if the
> refresh rate is not a problem today, why is it a problem now? Am I missing
> something?

Currently, we display only the "current" value (visualized by a bar), and if 
we will go with a line chart, which is displaying also some of the previous 
values and is sort-of "progressing" on each refresh, I think that it might 
look weird if it will progress slowly. 

typically, when looking at this sort of progressing line chart (like a 
performance/CPU monitor in your computer task manager or similar), you 
expect the frequency to be ~1 second or so. With a slower frequency, 
it may seem like the graph is occasionally "stuck". I agree that the 
current state is not ideal either, but it is definitely more "acceptable" 
than how I think it would be with a line chart.

Moreover, there's the non-sync'd frequencies that I mentioned earlier. I.e. 
if the GUI is refreshing every 5 seconds, but the statistics in the backend 
are refreshing every 15 seconds (and it doesn't really matter IMO if the new 
statistic are an average of some sort or single-point readings) - you are 
expected to have "flat" periods in the graph. so it may look something like:


*-*-* / 
 \   *-*-*
  \ /
   *-*-*

so only every 3rd GUI-refresh-cycle, the graph can potentially "change" the 
value, since every "1st" and "2nd" GUI-refresh-cycle, the value in the 
backend still hasn't changed (again, since the refresh rate on the backend 
side is lower than the one in the GUI).


Thanks,
Einav


- Original Message -
> From: "Malini Rao" 
> To: "Tomas Jelinek" 
> Cc: "Eldan Hildesheim" , "engine-devel" 
> , "info" 
> Sent: Wednesday, November 6, 2013 10:24:56 AM
> Subject: Re: [Engine-devel] [UX] how to design a bar/line chart?
> 
> Hey all,
> 
> Comments inline-
> 
> 
> 
> - Original Message -
> > From: "Tomas Jelinek" 
> > To: "Einav Cohen" 
> > Cc: "engine-devel" , "Eldan Hildesheim"
> > , "info" ,
> > "Malini Rao" , "Martin Polednik" 
> > Sent: Wednesday, November 6, 2013 9:58:03 AM
> > Subject: Re: [Engine-devel] [UX] how to design a bar/line chart?
> > 
> > Hi Einav,
> > 
> > - Original Message -
> > > From: "Einav Cohen" 
> > > To: "Tomas Jelinek" 
> > > Cc: "engine-devel" , "Eldan Hildesheim"
> > > , "info" ,
> > > "Malini Rao" 
> > > Sent: Wednesday, November 6, 2013 3:26:15 PM
> > > Subject: Re: [Engine-devel] [UX] how to design a bar/line chart?
> > > 
> > > Hi Tomas,
> > > 
> > > Like Itamar, I think that a line chart is a better idea, and that a
> > > chart per monitored fact (rather than a combined chart) is better.
> > 
> > OK
> 
> Based on the original request in the bug, it seems like Itamar is looking for
> a trend rather than just one data point. I think we are thinking along the
> correct lines here with a line graph but I think more specifically, we
> should consider sparklines -
> http://www.edwardtufte.com/bboard/q-and-a-fetch-msg?msg_id=0001OR. Agree
> that we should have one sparkline per fact but we may have to see how this
> looks when multiple sparklines reside in columns next to each other. See
> example of a grid where there are 2 sparklines next to each other -
> http://www.panopticon.com/Tables-Grids
> 
> > 
> > > 
> > > > > the statistics readable enough. Maybe if you hover the chart it could
> > > > > pop
> > > > > up a bigger version of the chart? Or not needed?
> > > 
> > > this is a nice-to-have, I think, definitely not needed.
> > 
> > OK
> 
> Agree. As shown in the glucose example in the Tufte link I posted above,
> maybe all we need is to indicate the acceptable range with a band and if the
> last point is in the range or outside, it will be clear to the user if they
> should pay attention to it.
> 
> 
> > 
> > > 
> > > > > - Would it be enough to have it in one color? Or should it be
> > > > > something
> > > > > like "the bigger the utilization the more red"?
> > > 
> > > question is what will happen when there are a lot of "jumps": let's say
> > > that the graph changes from 0% to 100% to 0% to 100% and so on... what
> > > will be painted red? the entire line, but only in the periods that it
> > > jumps to 100%? only the parts of line that are in 100%?
> > > maybe a single color is enough.
> > 
> > OK
> > 
> 
> One color with a dot to indicate the most recent or most relevant data and
> display its value next to the sparkline
> 
> 
> > > 
> > > I have another concern about this feature: currently, the GUI's most
> > > frequent
> > > refresh rate available is 5 seconds, which means that the line will
> > > "change"
> > > only every 5 seconds, which would be more noticeably slow when displayed
> > > in
> > > a form of a line cha

[Engine-devel] Permissions involved in using REST API

[Jonathan Daugherty]

Hi all,

I'm interested in setting up a non-administrative user account to be
used to access the oVirt REST API.  I have a user who is testing this
functionality by integrating some Vagrant-related software to talk to
oVirt.  The user's oVirt account is a non-admin account with enough
privileges to create and modify VMs on one of my clusters.

What we found is that the account is unable to make requests to, say,

  /api/vms

(he gets 401 or 404 responses) and instead gets a response indicating
that the account has "insufficient permissions."  My engine.log says of
the access only this:

  2013-11-06 14:50:28,158 ERROR
  [org.ovirt.engine.api.restapi.resource.AbstractBackendResource]
  (ajp--127.0.0.1-8702-13) Operation Failed: query execution faile
  d due to insufficient permissions.

and in server.log I have see Java tracebacks involving this[1]:

  2013-11-06 14:50:28,159 WARN
  [org.jboss.resteasy.core.SynchronousDispatcher]
  (ajp--127.0.0.1-8702-13) failed to execute:
  org.ovirt.engine.api.restapi.resource.BaseBackendResource$WebFaultException

Later we found that assigning an Admin role to the user's account at the
data center level with no permissions enabled permitted API access.  So
the user was able to make requests to /api/ URLs and get data and was
able to log into the oVirt administration portal but was unable to take
further action.

So my questions are:

 - Is this expected behavior?  Is there some smaller (less permissive)
   change in privileges I can use to bring about the same behavior?

 - Is there some place where such behavior is documented?  I couldn't
   find any.  The documentation on permissions on the RHEV docs only
   mentions the overall impact of using specific roles and permissions
   and says nothing about API access consequences or "Admin" roles with
   no permissions.

My initial assumption was that any user with credentials would be able
to make API requests, but that the corresponding API responses would be
filtered based on what the user had privileges to see just as with the
User Portal.

Thanks!

[1] A full trace can be found at http://pastebin.com/czcfQkYL

-- 
  Jonathan Daugherty
  Software Engineer
  Galois, Inc.
___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel

Re: [Engine-devel] [UX] how to design a bar/line chart?

[Itamar Heim]

On 11/06/2013 07:19 PM, Justin Hammond wrote:

Not directly related, but it would be good if the UI could also display disk 
activity per VM and overall for a host.

I've got a few disk intensive VM's or the occasional memory starved VM that 
kills disk throughput for other VM's. it's always a struggle to identify them , 
so something in the UI would help me as a admin


I suggest opening an RFE via bugzilla to track the request.
https://bugzilla.redhat.com/enter_bug.cgi?product=ovirt

___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel

Re: [Engine-devel] [UX] how to design a bar/line chart?

[Justin Hammond]

Not directly related, but it would be good if the UI could also display disk 
activity per VM and overall for a host. 

I've got a few disk intensive VM's or the occasional memory starved VM that 
kills disk throughput for other VM's. it's always a struggle to identify them , 
so something in the UI would help me as a admin

Sent from my iPhone

On 6 Nov, 2013, at 11:45 PM, "Alexander Wels"  wrote:

> I suppose we need to answer a few questions before we can go into which 
> library is better:
> 
> 1. Do we mind sending data over to Google so Google can render images for us.
> 2. Are we fine with just an image being displayed in the grid? If we aren't 
> okay with #1, we will have to create some sort of servlet to generate the 
> images.
> 3. Do we want the client to render the spark lines using javascript?
> 4. Do we want interactivity with these visualizations? For instance if I move 
> my mouse over the spark line, does the value displayed change?
> 5. Can we display whatever we choice in our current grid implementation? I 
> know the amount of javascript we can apply to it is somewhat limited right 
> now.
> 6. Any other consideration I am not thinking of? 
> 
> Alexander
> 
> On Wednesday, November 06, 2013 11:03:06 AM Malini Rao wrote:
>> Is this a possibility?  Looks nicer. http://style.org/chartapi/sparklines/
>> 
>> - Original Message -
>> From: "Alexander Wels" 
>> To: engine-devel@ovirt.org
>> Cc: "Malini Rao" , "Tomas Jelinek" ,
>> "Eldan Hildesheim" , "info"  Sent:
>> Wednesday, November 6, 2013 10:46:01 AM
>> Subject: Re: [Engine-devel] [UX] how to design a bar/line chart?
>> 
>> Maybe gchart is an option? Examples available here [1] one of the available
>> charts is a spark line. I just don't know how well that will play with our
>> grid implementation.
>> 
>> [1]
>> http://clientsidegchart.googlecode.com/svn/trunk/javadoc/com/googlecode/gcha
>> rt/client/package-summary.html#ChartGallery
>> On Wednesday, November 06, 2013 10:24:56 AM Malini Rao wrote:
>>> Hey all,
>>> 
>>> Comments inline-
>>> 
>>> 
>>> 
>>> - Original Message -
>>> 
 From: "Tomas Jelinek" 
 To: "Einav Cohen" 
 Cc: "engine-devel" , "Eldan Hildesheim"
 , "info" , "Malini Rao"
 , "Martin Polednik"  Sent:
 Wednesday, November 6, 2013 9:58:03 AM
 Subject: Re: [Engine-devel] [UX] how to design a bar/line chart?
 
 Hi Einav,
 
 - Original Message -
 
> From: "Einav Cohen" 
> To: "Tomas Jelinek" 
> Cc: "engine-devel" , "Eldan Hildesheim"
> , "info" ,
> "Malini Rao" 
> Sent: Wednesday, November 6, 2013 3:26:15 PM
> Subject: Re: [Engine-devel] [UX] how to design a bar/line chart?
> 
> Hi Tomas,
> 
> Like Itamar, I think that a line chart is a better idea, and that a
> chart per monitored fact (rather than a combined chart) is better.
 
 OK
>>> 
>>> Based on the original request in the bug, it seems like Itamar is looking
>>> for a trend rather than just one data point. I think we are thinking along
>>> the correct lines here with a line graph but I think more specifically, we
>>> should consider sparklines -
>>> http://www.edwardtufte.com/bboard/q-and-a-fetch-msg?msg_id=0001OR. Agree
>>> that we should have one sparkline per fact but we may have to see how this
>>> looks when multiple sparklines reside in columns next to each other. See
>>> example of a grid where there are 2 sparklines next to each other -
>>> http://www.panopticon.com/Tables-Grids
>>> 
>>> the statistics readable enough. Maybe if you hover the chart it
>>> could
>>> pop
>>> up a bigger version of the chart? Or not needed?
> 
> this is a nice-to-have, I think, definitely not needed.
 
 OK
>>> 
>>> Agree. As shown in the glucose example in the Tufte link I posted above,
>>> maybe all we need is to indicate the acceptable range with a band and if
>>> the last point is in the range or outside, it will be clear to the user if
>>> they should pay attention to it.
>>> 
>>> - Would it be enough to have it in one color? Or should it be
>>> something
>>> like "the bigger the utilization the more red"?
> 
> question is what will happen when there are a lot of "jumps": let's
> say
> that the graph changes from 0% to 100% to 0% to 100% and so on... what
> will be painted red? the entire line, but only in the periods that it
> jumps to 100%? only the parts of line that are in 100%?
> maybe a single color is enough.
 
 OK
>>> 
>>> One color with a dot to indicate the most recent or most relevant data and
>>> display its value next to the sparkline
>>> 
> I have another concern about this feature: currently, the GUI's most
> frequent
> refresh rate available is 5 seconds, which means that the line will
> "change"
> only every 5 seconds, which would be more noticeably slow when
> displayed
> in
> a form of a line chart (not even talking about lo

Re: [Engine-devel] [UX] how to design a bar/line chart?

[Alexander Wels]

I suppose we need to answer a few questions before we can go into which 
library is better:

1. Do we mind sending data over to Google so Google can render images for us.
2. Are we fine with just an image being displayed in the grid? If we aren't 
okay with #1, we will have to create some sort of servlet to generate the 
images.
3. Do we want the client to render the spark lines using javascript?
4. Do we want interactivity with these visualizations? For instance if I move 
my mouse over the spark line, does the value displayed change?
5. Can we display whatever we choice in our current grid implementation? I 
know the amount of javascript we can apply to it is somewhat limited right 
now.
6. Any other consideration I am not thinking of? 

Alexander

On Wednesday, November 06, 2013 11:03:06 AM Malini Rao wrote:
> Is this a possibility?  Looks nicer. http://style.org/chartapi/sparklines/
> 
> - Original Message -
> From: "Alexander Wels" 
> To: engine-devel@ovirt.org
> Cc: "Malini Rao" , "Tomas Jelinek" ,
> "Eldan Hildesheim" , "info"  Sent:
> Wednesday, November 6, 2013 10:46:01 AM
> Subject: Re: [Engine-devel] [UX] how to design a bar/line chart?
> 
> Maybe gchart is an option? Examples available here [1] one of the available
> charts is a spark line. I just don't know how well that will play with our
> grid implementation.
> 
> [1]
> http://clientsidegchart.googlecode.com/svn/trunk/javadoc/com/googlecode/gcha
> rt/client/package-summary.html#ChartGallery
> On Wednesday, November 06, 2013 10:24:56 AM Malini Rao wrote:
> > Hey all,
> > 
> > Comments inline-
> > 
> > 
> > 
> > - Original Message -
> > 
> > > From: "Tomas Jelinek" 
> > > To: "Einav Cohen" 
> > > Cc: "engine-devel" , "Eldan Hildesheim"
> > > , "info" , "Malini Rao"
> > > , "Martin Polednik"  Sent:
> > > Wednesday, November 6, 2013 9:58:03 AM
> > > Subject: Re: [Engine-devel] [UX] how to design a bar/line chart?
> > > 
> > > Hi Einav,
> > > 
> > > - Original Message -
> > > 
> > > > From: "Einav Cohen" 
> > > > To: "Tomas Jelinek" 
> > > > Cc: "engine-devel" , "Eldan Hildesheim"
> > > > , "info" ,
> > > > "Malini Rao" 
> > > > Sent: Wednesday, November 6, 2013 3:26:15 PM
> > > > Subject: Re: [Engine-devel] [UX] how to design a bar/line chart?
> > > > 
> > > > Hi Tomas,
> > > > 
> > > > Like Itamar, I think that a line chart is a better idea, and that a
> > > > chart per monitored fact (rather than a combined chart) is better.
> > > 
> > > OK
> > 
> > Based on the original request in the bug, it seems like Itamar is looking
> > for a trend rather than just one data point. I think we are thinking along
> > the correct lines here with a line graph but I think more specifically, we
> > should consider sparklines -
> > http://www.edwardtufte.com/bboard/q-and-a-fetch-msg?msg_id=0001OR. Agree
> > that we should have one sparkline per fact but we may have to see how this
> > looks when multiple sparklines reside in columns next to each other. See
> > example of a grid where there are 2 sparklines next to each other -
> > http://www.panopticon.com/Tables-Grids
> > 
> > > > > > the statistics readable enough. Maybe if you hover the chart it
> > > > > > could
> > > > > > pop
> > > > > > up a bigger version of the chart? Or not needed?
> > > > 
> > > > this is a nice-to-have, I think, definitely not needed.
> > > 
> > > OK
> > 
> > Agree. As shown in the glucose example in the Tufte link I posted above,
> > maybe all we need is to indicate the acceptable range with a band and if
> > the last point is in the range or outside, it will be clear to the user if
> > they should pay attention to it.
> > 
> > > > > > - Would it be enough to have it in one color? Or should it be
> > > > > > something
> > > > > > like "the bigger the utilization the more red"?
> > > > 
> > > > question is what will happen when there are a lot of "jumps": let's
> > > > say
> > > > that the graph changes from 0% to 100% to 0% to 100% and so on... what
> > > > will be painted red? the entire line, but only in the periods that it
> > > > jumps to 100%? only the parts of line that are in 100%?
> > > > maybe a single color is enough.
> > > 
> > > OK
> > 
> > One color with a dot to indicate the most recent or most relevant data and
> > display its value next to the sparkline
> > 
> > > > I have another concern about this feature: currently, the GUI's most
> > > > frequent
> > > > refresh rate available is 5 seconds, which means that the line will
> > > > "change"
> > > > only every 5 seconds, which would be more noticeably slow when
> > > > displayed
> > > > in
> > > > a form of a line chart (not even talking about lower frequencies).
> > > > Moreover, I am not sure at what rate the VM statistics are pulled from
> > > > VDSM,
> > > > but if it is 10 seconds or 15 seconds, it means that the line in the
> > > > GUI
> > > > will
> > > > be "flat" for every 2 reads / 3 reads, which is not so good, I think.
> > > > 
> > > > any thoughts around that?
> > > 
> > > Good p

Re: [Engine-devel] GWT DevMode plugin stopped working in Firefox 24+

[Daniel Erez]

- Original Message -
> From: "Greg Sheremeta" 
> To: "engine-devel" 
> Sent: Wednesday, November 6, 2013 6:27:57 PM
> Subject: [Engine-devel] GWT DevMode plugin stopped working in Firefox 24+
> 
> I submitted a bug. Please star it if this affects you.
> 
> https://code.google.com/p/google-web-toolkit/issues/detail?id=8423
> 
> Detailed description (please be as specific as possible):
> The DevMode plugin does not work (Development Mode requires the GWT Developer
> Plugin).
> I encountered this in Firefox 24. Upgraded to Firefox 25 and plugin 1.25,
> still doesn't work.
> 
> Workaround if you have one:
> roll back to Firefox 23.

+1
Didn't work for me also on ff23, ff21 ESR works fine.

> 
> Greg
> 
> 
> Greg Sheremeta
> Red Hat, Inc.
> Sr. Software Engineer, RHEV
> Cell: 919-807-1086
> gsher...@redhat.com
> ___
> Engine-devel mailing list
> Engine-devel@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 
___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel

[Engine-devel] GWT DevMode plugin stopped working in Firefox 24+

[Greg Sheremeta]

I submitted a bug. Please star it if this affects you.

https://code.google.com/p/google-web-toolkit/issues/detail?id=8423

Detailed description (please be as specific as possible):
The DevMode plugin does not work (Development Mode requires the GWT Developer 
Plugin).
I encountered this in Firefox 24. Upgraded to Firefox 25 and plugin 1.25, still 
doesn't work.

Workaround if you have one:
roll back to Firefox 23.

Greg


Greg Sheremeta
Red Hat, Inc.
Sr. Software Engineer, RHEV
Cell: 919-807-1086
gsher...@redhat.com
___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel

[Engine-devel] [QE] 3.3.2 Release tracker

[Sandro Bonazzola]

Hi,

as you may know, we're planning to build oVirt 3.3.2 beta really soon and 
release 3.3.2 by early December.
I have created a tracker bug 
(https://bugzilla.redhat.com/show_bug.cgi?id=1027349) for this release.
Beta build will be composed in 2 weeks.

The following is a list of the bugs with target 3.3.2 or 3.3:

Whiteboard  Bug ID  Summary
infra   987982  When adding a host through the REST API, the error message says 
that "rootPassword" is required...
infra   1017267 Plaintext user passwords in async_tasks database
infra   992883  VdsManager.OnTimer loads VDS instead of VdsDynamic
infra   1020344 Power Managent with cisco_ucs problem
infra   1009899 exportDbSchema scripts generates output file with wrong name
integration 1022440 AIO - configure the AIO host to be a gluster 
cluster/host
integration 1026926 engine-cleanup (and possible engine-setup) does not 
affect runtime value of shmmax
integration 902979  ovirt-live - firefox doesn't trust the installed engine
integration 1021805 oVirt Live - use motd to show the admin password
network 1019818 Support OpenStack Havana layer 2 agent integration
network 988002  [oVirt] [network] Add button shouldn't appear on specific 
network
network 987916  [oVirt] [provider] Dialog doesn't update unless focus lost
network 987999  [oVirt] [provider] Add button shouldn't appear on specific 
provider
storage 915753  Deadlock detected during creation vms in pool
storage 987917  [oVirt] [glance] API version not specified in provider dialog
storage 1024449 Check the performance with lvm-2.02.100-7
virt1007940 Cannot clone from snapshot while using GlusterFS as POSIX 
Storage Domain
?   991267  [RFE] Add TUI information to log file.


Please set the target to 3.3.2 and add the bug to the tracker if you think that 
3.3.2 should not be released without it fixed.

Please also update the target to 3.3.3 or any next release for bugs that won't 
be in 3.3.2: it will ease gathering the blocking bugs for next releases.

For those who want to help testing the bugs, I suggest to add yourself as QA 
contact for the bug.

-- 
Sandro Bonazzola
Better technology. Faster innovation. Powered by community collaboration.
See how it works at redhat.com
___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel

Re: [Engine-devel] [UX] how to design a bar/line chart?

[Malini Rao]

Is this a possibility?  Looks nicer. http://style.org/chartapi/sparklines/

- Original Message -
From: "Alexander Wels" 
To: engine-devel@ovirt.org
Cc: "Malini Rao" , "Tomas Jelinek" , 
"Eldan Hildesheim" , "info" 
Sent: Wednesday, November 6, 2013 10:46:01 AM
Subject: Re: [Engine-devel] [UX] how to design a bar/line chart?

Maybe gchart is an option? Examples available here [1] one of the available 
charts is a spark line. I just don't know how well that will play with our 
grid implementation.

[1] 
http://clientsidegchart.googlecode.com/svn/trunk/javadoc/com/googlecode/gchart/client/package-summary.html#ChartGallery


On Wednesday, November 06, 2013 10:24:56 AM Malini Rao wrote:
> Hey all,
> 
> Comments inline-
> 
> 
> 
> - Original Message -
> 
> > From: "Tomas Jelinek" 
> > To: "Einav Cohen" 
> > Cc: "engine-devel" , "Eldan Hildesheim"
> > , "info" , "Malini Rao"
> > , "Martin Polednik"  Sent:
> > Wednesday, November 6, 2013 9:58:03 AM
> > Subject: Re: [Engine-devel] [UX] how to design a bar/line chart?
> > 
> > Hi Einav,
> > 
> > - Original Message -
> > 
> > > From: "Einav Cohen" 
> > > To: "Tomas Jelinek" 
> > > Cc: "engine-devel" , "Eldan Hildesheim"
> > > , "info" ,
> > > "Malini Rao" 
> > > Sent: Wednesday, November 6, 2013 3:26:15 PM
> > > Subject: Re: [Engine-devel] [UX] how to design a bar/line chart?
> > > 
> > > Hi Tomas,
> > > 
> > > Like Itamar, I think that a line chart is a better idea, and that a
> > > chart per monitored fact (rather than a combined chart) is better.
> > 
> > OK
> 
> Based on the original request in the bug, it seems like Itamar is looking
> for a trend rather than just one data point. I think we are thinking along
> the correct lines here with a line graph but I think more specifically, we
> should consider sparklines -
> http://www.edwardtufte.com/bboard/q-and-a-fetch-msg?msg_id=0001OR. Agree
> that we should have one sparkline per fact but we may have to see how this
> looks when multiple sparklines reside in columns next to each other. See
> example of a grid where there are 2 sparklines next to each other -
> http://www.panopticon.com/Tables-Grids
> > > > > the statistics readable enough. Maybe if you hover the chart it
> > > > > could
> > > > > pop
> > > > > up a bigger version of the chart? Or not needed?
> > > 
> > > this is a nice-to-have, I think, definitely not needed.
> > 
> > OK
> 
> Agree. As shown in the glucose example in the Tufte link I posted above,
> maybe all we need is to indicate the acceptable range with a band and if
> the last point is in the range or outside, it will be clear to the user if
> they should pay attention to it.
> > > > > - Would it be enough to have it in one color? Or should it be
> > > > > something
> > > > > like "the bigger the utilization the more red"?
> > > 
> > > question is what will happen when there are a lot of "jumps": let's say
> > > that the graph changes from 0% to 100% to 0% to 100% and so on... what
> > > will be painted red? the entire line, but only in the periods that it
> > > jumps to 100%? only the parts of line that are in 100%?
> > > maybe a single color is enough.
> > 
> > OK
> 
> One color with a dot to indicate the most recent or most relevant data and
> display its value next to the sparkline
> > > I have another concern about this feature: currently, the GUI's most
> > > frequent
> > > refresh rate available is 5 seconds, which means that the line will
> > > "change"
> > > only every 5 seconds, which would be more noticeably slow when displayed
> > > in
> > > a form of a line chart (not even talking about lower frequencies).
> > > Moreover, I am not sure at what rate the VM statistics are pulled from
> > > VDSM,
> > > but if it is 10 seconds or 15 seconds, it means that the line in the GUI
> > > will
> > > be "flat" for every 2 reads / 3 reads, which is not so good, I think.
> > > 
> > > any thoughts around that?
> > 
> > Good point! AFAIK the VDSM is polled each 3 seconds for basic info (e.g.
> > the resource
> > usage not included) and than every 5th poll (e.g. every 15 seconds) for
> > full data
> > (with resource usage not included). This would indeed make the graph
> > pretty
> > useless.
> > 
> > Michal proposed to do some averages on the VDSM site from more frequent
> > sampling and
> > send this average back to engine when polled - so we would display an
> > average after each poll (15s).
> > 
> > I wonder if something like this is not already used on other places:
> > @Martin, do you know about something like this?
> 
> Why does the change in the line need to seem palpable every few seconds? I
> think the base requirement of how accurate the data is when a user looks at
> a grid has not changed.. just the data visualization. Right? So , if the
> refresh rate is not a problem today, why is it a problem now? Am I missing
> something?
> > > - Original Message -
> > > 
> > > > From: "Itamar Heim" 
> > > > To: "Tomas Jelinek" , "engine-devel"
> > > > 
> > > > Sen

Re: [Engine-devel] IMP: Regarding an issue while translating the error messages for gluster using ErrorTranslator class

[Daniel Erez]

- Original Message -
> From: "Shubhendu Tripathi" 
> To: "Daniel Erez" 
> Cc: "engine-devel" , "Dusmant Pati" 
> Sent: Wednesday, November 6, 2013 4:31:52 PM
> Subject: Re: IMP: Regarding an issue while translating the error messages for 
> gluster using ErrorTranslator class
> 
> On 11/06/2013 07:43 PM, Daniel Erez wrote:
> >
> > - Original Message -
> >> From: "Shubhendu Tripathi" 
> >> To: de...@redhat.com, "engine-devel" 
> >> Cc: "Dusmant Pati" 
> >> Sent: Wednesday, November 6, 2013 12:07:34 PM
> >> Subject: IMP: Regarding an issue while translating the error messages for
> >> gluster using ErrorTranslator class
> >>
> >> Hi,
> >>
> >> In the case of Gluster, as there are no one to one mappings available
> >> for all the error messages from Gluster, we set the error in the
> >> VdcFault object as NULL.
> >> We also populate the actual error from the Gluster as error message in
> >> the fault object.
> >>
> >> /getReturnValue().getExecuteFailedMessages().add(error);//
> >> //getReturnValue().getFault().setMessage(error);//
> >> //getReturnValue().getFault().setError(null);/
> >>
> >> Because of above settings and the below code snippet in /Frontend.java/
> >> class the error message as is gets displayed on the error dialog -
> >> /
> >> //public String translateVdcFault(final VdcFault fault) {//
> >> //return
> >> getVdsmErrorsTranslator().TranslateErrorTextSingle(fault.getError() ==
> >> null//
> >> //? fault.getMessage() : fault.getError().toString());//
> >> //}//
> >> /
> >> Well and good till now !!
> >>
> >> But while translation of the error messages, all the occurrences of "."
> >> get replaced with "_".
> >> This causes an issue for the gluster errors. If the error message sent
> >> from gluster has "."s (say IP Address of a host or FQDN for a host),
> >> that also gets replaced with "_" and the error message does not look
> >> correct.
> > This mechanism of replacing [1] has been introduced to allow proper
> > message translation when retrieving a message key that contains dots.
> > E.g. AppErrors.properties -> VALIDATION.ROLES.NAME.MAX is translated
> > to VALIDATION_ROLES_NAME_MAX in AppErrors.java interface (as interface
> > signatures cannot contain dots. Note that this process shouldn't
> > address the message; i.e. only the key is examined for dots.
> >
> > As you've mentioned VdsmErrorsTranslator I guess there's an issue
> > only when translating VdsmErrors messages.
> > Can you please send an example of a message usage?
> One example of the error message which is shown on the dialog after
> translation is as below -
> 
> /"Error while executin action Create Gluster Volume: Volume create
> failed error: Staging failed on //*10_70_43_122_*//Error: /export/vol1-a
> is already part of a volume"/

What are the keys that been sent from the engine (i.e. the message before 
translation)?

> 
> If you see the highlighted portion not only the dots in IP address but
> also the full stop is changed to "_".
> > (and maybe try the same message using AppErrors instead)
> There are no one to one mapping of these messages in AppErrors as they
> arise randomly, so in such cases we throw the VDSM error message as is
> on the dialog.
> >
> > [1] ErrorTranslator -> translateErrorTextSingle()
> >
> >> Request your suggestion for handling such a case.
> >>
> >> *PS: *One thing I can think of is, introducing a flag called
> >> /isExternalError/ in /VdcFault/ class to identify if the source of the
> >> fault is external. From Gluster we would set the flag as /true/, and
> >> while replacement of "." with "_", if the flag is set it will not do the
> >> replacements.
> >>
> >> Regards,
> >> Shubhendu
> >>
> 
> 
___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel

Re: [Engine-devel] [UX] how to design a bar/line chart?

[Alexander Wels]

Maybe gchart is an option? Examples available here [1] one of the available 
charts is a spark line. I just don't know how well that will play with our 
grid implementation.

[1] 
http://clientsidegchart.googlecode.com/svn/trunk/javadoc/com/googlecode/gchart/client/package-summary.html#ChartGallery


On Wednesday, November 06, 2013 10:24:56 AM Malini Rao wrote:
> Hey all,
> 
> Comments inline-
> 
> 
> 
> - Original Message -
> 
> > From: "Tomas Jelinek" 
> > To: "Einav Cohen" 
> > Cc: "engine-devel" , "Eldan Hildesheim"
> > , "info" , "Malini Rao"
> > , "Martin Polednik"  Sent:
> > Wednesday, November 6, 2013 9:58:03 AM
> > Subject: Re: [Engine-devel] [UX] how to design a bar/line chart?
> > 
> > Hi Einav,
> > 
> > - Original Message -
> > 
> > > From: "Einav Cohen" 
> > > To: "Tomas Jelinek" 
> > > Cc: "engine-devel" , "Eldan Hildesheim"
> > > , "info" ,
> > > "Malini Rao" 
> > > Sent: Wednesday, November 6, 2013 3:26:15 PM
> > > Subject: Re: [Engine-devel] [UX] how to design a bar/line chart?
> > > 
> > > Hi Tomas,
> > > 
> > > Like Itamar, I think that a line chart is a better idea, and that a
> > > chart per monitored fact (rather than a combined chart) is better.
> > 
> > OK
> 
> Based on the original request in the bug, it seems like Itamar is looking
> for a trend rather than just one data point. I think we are thinking along
> the correct lines here with a line graph but I think more specifically, we
> should consider sparklines -
> http://www.edwardtufte.com/bboard/q-and-a-fetch-msg?msg_id=0001OR. Agree
> that we should have one sparkline per fact but we may have to see how this
> looks when multiple sparklines reside in columns next to each other. See
> example of a grid where there are 2 sparklines next to each other -
> http://www.panopticon.com/Tables-Grids
> > > > > the statistics readable enough. Maybe if you hover the chart it
> > > > > could
> > > > > pop
> > > > > up a bigger version of the chart? Or not needed?
> > > 
> > > this is a nice-to-have, I think, definitely not needed.
> > 
> > OK
> 
> Agree. As shown in the glucose example in the Tufte link I posted above,
> maybe all we need is to indicate the acceptable range with a band and if
> the last point is in the range or outside, it will be clear to the user if
> they should pay attention to it.
> > > > > - Would it be enough to have it in one color? Or should it be
> > > > > something
> > > > > like "the bigger the utilization the more red"?
> > > 
> > > question is what will happen when there are a lot of "jumps": let's say
> > > that the graph changes from 0% to 100% to 0% to 100% and so on... what
> > > will be painted red? the entire line, but only in the periods that it
> > > jumps to 100%? only the parts of line that are in 100%?
> > > maybe a single color is enough.
> > 
> > OK
> 
> One color with a dot to indicate the most recent or most relevant data and
> display its value next to the sparkline
> > > I have another concern about this feature: currently, the GUI's most
> > > frequent
> > > refresh rate available is 5 seconds, which means that the line will
> > > "change"
> > > only every 5 seconds, which would be more noticeably slow when displayed
> > > in
> > > a form of a line chart (not even talking about lower frequencies).
> > > Moreover, I am not sure at what rate the VM statistics are pulled from
> > > VDSM,
> > > but if it is 10 seconds or 15 seconds, it means that the line in the GUI
> > > will
> > > be "flat" for every 2 reads / 3 reads, which is not so good, I think.
> > > 
> > > any thoughts around that?
> > 
> > Good point! AFAIK the VDSM is polled each 3 seconds for basic info (e.g.
> > the resource
> > usage not included) and than every 5th poll (e.g. every 15 seconds) for
> > full data
> > (with resource usage not included). This would indeed make the graph
> > pretty
> > useless.
> > 
> > Michal proposed to do some averages on the VDSM site from more frequent
> > sampling and
> > send this average back to engine when polled - so we would display an
> > average after each poll (15s).
> > 
> > I wonder if something like this is not already used on other places:
> > @Martin, do you know about something like this?
> 
> Why does the change in the line need to seem palpable every few seconds? I
> think the base requirement of how accurate the data is when a user looks at
> a grid has not changed.. just the data visualization. Right? So , if the
> refresh rate is not a problem today, why is it a problem now? Am I missing
> something?
> > > - Original Message -
> > > 
> > > > From: "Itamar Heim" 
> > > > To: "Tomas Jelinek" , "engine-devel"
> > > > 
> > > > Sent: Tuesday, November 5, 2013 10:10:34 AM
> > > > Subject: Re: [Engine-devel] [UX] how to design a bar/line chart?
> > > > 
> > > > On 11/05/2013 11:50 AM, Tomas Jelinek wrote:
> > > > > Hi all,
> > > > > 
> > > > > There is a feature request [1] which aims to replace the resource
> > > > > utilization graphs (for example the cpu util

Re: [Engine-devel] [UX] how to design a bar/line chart?

[Malini Rao]

Hey all, 

Comments inline-



- Original Message -
> From: "Tomas Jelinek" 
> To: "Einav Cohen" 
> Cc: "engine-devel" , "Eldan Hildesheim" 
> , "info" ,
> "Malini Rao" , "Martin Polednik" 
> Sent: Wednesday, November 6, 2013 9:58:03 AM
> Subject: Re: [Engine-devel] [UX] how to design a bar/line chart?
> 
> Hi Einav,
> 
> - Original Message -
> > From: "Einav Cohen" 
> > To: "Tomas Jelinek" 
> > Cc: "engine-devel" , "Eldan Hildesheim"
> > , "info" ,
> > "Malini Rao" 
> > Sent: Wednesday, November 6, 2013 3:26:15 PM
> > Subject: Re: [Engine-devel] [UX] how to design a bar/line chart?
> > 
> > Hi Tomas,
> > 
> > Like Itamar, I think that a line chart is a better idea, and that a
> > chart per monitored fact (rather than a combined chart) is better.
> 
> OK

Based on the original request in the bug, it seems like Itamar is looking for a 
trend rather than just one data point. I think we are thinking along the 
correct lines here with a line graph but I think more specifically, we should 
consider sparklines - 
http://www.edwardtufte.com/bboard/q-and-a-fetch-msg?msg_id=0001OR. Agree that 
we should have one sparkline per fact but we may have to see how this looks 
when multiple sparklines reside in columns next to each other. See example of a 
grid where there are 2 sparklines next to each other - 
http://www.panopticon.com/Tables-Grids

> 
> > 
> > > > the statistics readable enough. Maybe if you hover the chart it could
> > > > pop
> > > > up a bigger version of the chart? Or not needed?
> > 
> > this is a nice-to-have, I think, definitely not needed.
> 
> OK

Agree. As shown in the glucose example in the Tufte link I posted above, maybe 
all we need is to indicate the acceptable range with a band and if the last 
point is in the range or outside, it will be clear to the user if they should 
pay attention to it. 


> 
> > 
> > > > - Would it be enough to have it in one color? Or should it be something
> > > > like "the bigger the utilization the more red"?
> > 
> > question is what will happen when there are a lot of "jumps": let's say
> > that the graph changes from 0% to 100% to 0% to 100% and so on... what
> > will be painted red? the entire line, but only in the periods that it
> > jumps to 100%? only the parts of line that are in 100%?
> > maybe a single color is enough.
> 
> OK
> 

One color with a dot to indicate the most recent or most relevant data and 
display its value next to the sparkline


> > 
> > I have another concern about this feature: currently, the GUI's most
> > frequent
> > refresh rate available is 5 seconds, which means that the line will
> > "change"
> > only every 5 seconds, which would be more noticeably slow when displayed in
> > a form of a line chart (not even talking about lower frequencies).
> > Moreover, I am not sure at what rate the VM statistics are pulled from
> > VDSM,
> > but if it is 10 seconds or 15 seconds, it means that the line in the GUI
> > will
> > be "flat" for every 2 reads / 3 reads, which is not so good, I think.
> > 
> > any thoughts around that?
> 
> Good point! AFAIK the VDSM is polled each 3 seconds for basic info (e.g. the
> resource
> usage not included) and than every 5th poll (e.g. every 15 seconds) for full
> data
> (with resource usage not included). This would indeed make the graph pretty
> useless.
> 
> Michal proposed to do some averages on the VDSM site from more frequent
> sampling and
> send this average back to engine when polled - so we would display an average
> after each poll (15s).
> 
> I wonder if something like this is not already used on other places:
> @Martin, do you know about something like this?

Why does the change in the line need to seem palpable every few seconds? I 
think the base requirement of how accurate the data is when a user looks at a 
grid has not changed.. just the data visualization. Right? So , if the refresh 
rate is not a problem today, why is it a problem now? Am I missing something?


> 
> 
> > 
> > - Original Message -
> > > From: "Itamar Heim" 
> > > To: "Tomas Jelinek" , "engine-devel"
> > > 
> > > Sent: Tuesday, November 5, 2013 10:10:34 AM
> > > Subject: Re: [Engine-devel] [UX] how to design a bar/line chart?
> > > 
> > > On 11/05/2013 11:50 AM, Tomas Jelinek wrote:
> > > > Hi all,
> > > >
> > > > There is a feature request [1] which aims to replace the resource
> > > > utilization graphs (for example the cpu utilization from vm tab) by
> > > > some
> > > > which shows not only
> > > > the actual percentage which is not so useful by some monitor graph.
> > > >
> > > > I have the following concerns:
> > > > - I can think of a bar chart or a line chart and not sure what would be
> > > > better.
> > > > - Not sure if replacing the current chart with a bar/line chart would
> > > > make
> > > > the statistics readable enough. Maybe if you hover the chart it could
> > > > pop
> > > > up a bigger version of the chart? Or not needed?
> > > > - Would it be enough to have it in one color?

Re: [Engine-devel] [UX] how to design a bar/line chart?

[Tomas Jelinek]

Hi Einav,

- Original Message -
> From: "Einav Cohen" 
> To: "Tomas Jelinek" 
> Cc: "engine-devel" , "Eldan Hildesheim" 
> , "info" ,
> "Malini Rao" 
> Sent: Wednesday, November 6, 2013 3:26:15 PM
> Subject: Re: [Engine-devel] [UX] how to design a bar/line chart?
> 
> Hi Tomas,
> 
> Like Itamar, I think that a line chart is a better idea, and that a
> chart per monitored fact (rather than a combined chart) is better.

OK

> 
> > > the statistics readable enough. Maybe if you hover the chart it could pop
> > > up a bigger version of the chart? Or not needed?
> 
> this is a nice-to-have, I think, definitely not needed.

OK

> 
> > > - Would it be enough to have it in one color? Or should it be something
> > > like "the bigger the utilization the more red"?
> 
> question is what will happen when there are a lot of "jumps": let's say
> that the graph changes from 0% to 100% to 0% to 100% and so on... what
> will be painted red? the entire line, but only in the periods that it
> jumps to 100%? only the parts of line that are in 100%?
> maybe a single color is enough.

OK

> 
> I have another concern about this feature: currently, the GUI's most frequent
> refresh rate available is 5 seconds, which means that the line will "change"
> only every 5 seconds, which would be more noticeably slow when displayed in
> a form of a line chart (not even talking about lower frequencies).
> Moreover, I am not sure at what rate the VM statistics are pulled from VDSM,
> but if it is 10 seconds or 15 seconds, it means that the line in the GUI will
> be "flat" for every 2 reads / 3 reads, which is not so good, I think.
> 
> any thoughts around that?

Good point! AFAIK the VDSM is polled each 3 seconds for basic info (e.g. the 
resource
usage not included) and than every 5th poll (e.g. every 15 seconds) for full 
data
(with resource usage not included). This would indeed make the graph pretty 
useless.

Michal proposed to do some averages on the VDSM site from more frequent 
sampling and
send this average back to engine when polled - so we would display an average 
after each poll (15s).

I wonder if something like this is not already used on other places:
@Martin, do you know about something like this?


> 
> - Original Message -
> > From: "Itamar Heim" 
> > To: "Tomas Jelinek" , "engine-devel"
> > 
> > Sent: Tuesday, November 5, 2013 10:10:34 AM
> > Subject: Re: [Engine-devel] [UX] how to design a bar/line chart?
> > 
> > On 11/05/2013 11:50 AM, Tomas Jelinek wrote:
> > > Hi all,
> > >
> > > There is a feature request [1] which aims to replace the resource
> > > utilization graphs (for example the cpu utilization from vm tab) by some
> > > which shows not only
> > > the actual percentage which is not so useful by some monitor graph.
> > >
> > > I have the following concerns:
> > > - I can think of a bar chart or a line chart and not sure what would be
> > > better.
> > > - Not sure if replacing the current chart with a bar/line chart would
> > > make
> > > the statistics readable enough. Maybe if you hover the chart it could pop
> > > up a bigger version of the chart? Or not needed?
> > > - Would it be enough to have it in one color? Or should it be something
> > > like "the bigger the utilization the more red"?
> > >
> > > Please advise from the UX perspective. As soon as the final design will
> > > be
> > > a bit more clear I will provide a feature page.
> > >
> > > Thank you,
> > > Tomas
> > >
> > > [1]: https://bugzilla.redhat.com/show_bug.cgi?id=803251
> > > ___
> > > Engine-devel mailing list
> > > Engine-devel@ovirt.org
> > > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > >
> > 
> > a moving trend graph (just like fedora's system monitor for
> > cpu/ram/network) is what i have in mind. so a line chart.
> > you could have a single chart with different lines for cpu/ram/network,
> > or what seems to be more common, a chart per monitored fact
> > ___
> > Engine-devel mailing list
> > Engine-devel@ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > 
> > 
> > 
> 
___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel

Re: [Engine-devel] IMP: Regarding an issue while translating the error messages for gluster using ErrorTranslator class

[Shubhendu Tripathi]

On 11/06/2013 07:41 PM, Einav Cohen wrote:

but if the message is not a key, and would be displayed as-is, on "." to "_"
replacement should take place.

on -> no*
This solution looks fine. If the error message is not found in the map, 
we can revert back to original message which has the "."s.

Request comments from others as well.



- Original Message -
From: "Einav Cohen" 
Sent: Wednesday, November 6, 2013 9:10:09 AM


- Original Message -
From: "Alexander Wels" 
Sent: Wednesday, November 6, 2013 8:28:13 AM

Looking at the code, if you start the error message with a $ it will not do
the . to _ replacement. Not sure if your error message will now simply
start
with a $, but it is worth a try I guess.

AFAIK: the '$' prefix is for variable-value message.
e.g. if you have a message "cannot run VM ${vm-name}" and another one
"$vm-name vm1",
then their combination would eventually yield "cannot run VM vm1".
Also, I think that messages that begin with "$" cannot be displayed when they
are on their own.
i.e. if you will get message "$vm-name vm1" 'alone', nothing will eventually
be displayed.
but, as I mentioned, if you will get message "$vm-name vm1" along with
message "cannot run
VM ${vm-name}", eventually "cannot run VM vm1" will be displayed.

I think that the replacement of "." to "_" should be done only if the message
represents a *key* in the relevant resource (VdsmErrors in this case).
but if the message is not a key, and would be displayed as-is, on "." to "_"
replacement
should take place.
adding Derez for his thoughts (I think that he changed something around it a
while ago).


On Wednesday, November 06, 2013 03:37:34 PM Shubhendu Tripathi wrote:

Hi,

In the case of Gluster, as there are no one to one mappings available
for all the error messages from Gluster, we set the error in the
VdcFault object as NULL.
We also populate the actual error from the Gluster as error message in
the fault object.

/getReturnValue().getExecuteFailedMessages().add(error);//
//getReturnValue().getFault().setMessage(error);//
//getReturnValue().getFault().setError(null);/

Because of above settings and the below code snippet in /Frontend.java/
class the error message as is gets displayed on the error dialog -
/
//public String translateVdcFault(final VdcFault fault) {//
//return
getVdsmErrorsTranslator().TranslateErrorTextSingle(fault.getError() ==
null//
//? fault.getMessage() : fault.getError().toString());//
//}//
/
Well and good till now !!

But while translation of the error messages, all the occurrences of "."
get replaced with "_".
This causes an issue for the gluster errors. If the error message sent
from gluster has "."s (say IP Address of a host or FQDN for a host),
that also gets replaced with "_" and the error message does not look
correct.

Request your suggestion for handling such a case.

*PS: *One thing I can think of is, introducing a flag called
/isExternalError/ in /VdcFault/ class to identify if the source of the
fault is external. From Gluster we would set the flag as /true/, and
while replacement of "." with "_", if the flag is set it will not do the
replacements.

Regards,
Shubhendu

___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel


___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel





___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel

Re: [Engine-devel] IMP: Regarding an issue while translating the error messages for gluster using ErrorTranslator class

[Shubhendu Tripathi]

On 11/06/2013 07:43 PM, Daniel Erez wrote:


- Original Message -

From: "Shubhendu Tripathi" 
To: de...@redhat.com, "engine-devel" 
Cc: "Dusmant Pati" 
Sent: Wednesday, November 6, 2013 12:07:34 PM
Subject: IMP: Regarding an issue while translating the error messages for 
gluster using ErrorTranslator class

Hi,

In the case of Gluster, as there are no one to one mappings available
for all the error messages from Gluster, we set the error in the
VdcFault object as NULL.
We also populate the actual error from the Gluster as error message in
the fault object.

/getReturnValue().getExecuteFailedMessages().add(error);//
//getReturnValue().getFault().setMessage(error);//
//getReturnValue().getFault().setError(null);/

Because of above settings and the below code snippet in /Frontend.java/
class the error message as is gets displayed on the error dialog -
/
//public String translateVdcFault(final VdcFault fault) {//
//return
getVdsmErrorsTranslator().TranslateErrorTextSingle(fault.getError() ==
null//
//? fault.getMessage() : fault.getError().toString());//
//}//
/
Well and good till now !!

But while translation of the error messages, all the occurrences of "."
get replaced with "_".
This causes an issue for the gluster errors. If the error message sent
from gluster has "."s (say IP Address of a host or FQDN for a host),
that also gets replaced with "_" and the error message does not look
correct.

This mechanism of replacing [1] has been introduced to allow proper
message translation when retrieving a message key that contains dots.
E.g. AppErrors.properties -> VALIDATION.ROLES.NAME.MAX is translated
to VALIDATION_ROLES_NAME_MAX in AppErrors.java interface (as interface
signatures cannot contain dots. Note that this process shouldn't
address the message; i.e. only the key is examined for dots.

As you've mentioned VdsmErrorsTranslator I guess there's an issue
only when translating VdsmErrors messages.
Can you please send an example of a message usage?
One example of the error message which is shown on the dialog after 
translation is as below -


/"Error while executin action Create Gluster Volume: Volume create 
failed error: Staging failed on //*10_70_43_122_*//Error: /export/vol1-a 
is already part of a volume"/


If you see the highlighted portion not only the dots in IP address but 
also the full stop is changed to "_".

(and maybe try the same message using AppErrors instead)
There are no one to one mapping of these messages in AppErrors as they 
arise randomly, so in such cases we throw the VDSM error message as is 
on the dialog.


[1] ErrorTranslator -> translateErrorTextSingle()


Request your suggestion for handling such a case.

*PS: *One thing I can think of is, introducing a flag called
/isExternalError/ in /VdcFault/ class to identify if the source of the
fault is external. From Gluster we would set the flag as /true/, and
while replacement of "." with "_", if the flag is set it will not do the
replacements.

Regards,
Shubhendu



___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel

Re: [Engine-devel] [UX] how to design a bar/line chart?

[Einav Cohen]

Hi Tomas,

Like Itamar, I think that a line chart is a better idea, and that a 
chart per monitored fact (rather than a combined chart) is better.

> > the statistics readable enough. Maybe if you hover the chart it could pop
> > up a bigger version of the chart? Or not needed?

this is a nice-to-have, I think, definitely not needed.

> > - Would it be enough to have it in one color? Or should it be something
> > like "the bigger the utilization the more red"?

question is what will happen when there are a lot of "jumps": let's say 
that the graph changes from 0% to 100% to 0% to 100% and so on... what 
will be painted red? the entire line, but only in the periods that it 
jumps to 100%? only the parts of line that are in 100%?
maybe a single color is enough.

I have another concern about this feature: currently, the GUI's most frequent 
refresh rate available is 5 seconds, which means that the line will "change" 
only every 5 seconds, which would be more noticeably slow when displayed in 
a form of a line chart (not even talking about lower frequencies).
Moreover, I am not sure at what rate the VM statistics are pulled from VDSM, 
but if it is 10 seconds or 15 seconds, it means that the line in the GUI will 
be "flat" for every 2 reads / 3 reads, which is not so good, I think.

any thoughts around that?

- Original Message -
> From: "Itamar Heim" 
> To: "Tomas Jelinek" , "engine-devel" 
> 
> Sent: Tuesday, November 5, 2013 10:10:34 AM
> Subject: Re: [Engine-devel] [UX] how to design a bar/line chart?
> 
> On 11/05/2013 11:50 AM, Tomas Jelinek wrote:
> > Hi all,
> >
> > There is a feature request [1] which aims to replace the resource
> > utilization graphs (for example the cpu utilization from vm tab) by some
> > which shows not only
> > the actual percentage which is not so useful by some monitor graph.
> >
> > I have the following concerns:
> > - I can think of a bar chart or a line chart and not sure what would be
> > better.
> > - Not sure if replacing the current chart with a bar/line chart would make
> > the statistics readable enough. Maybe if you hover the chart it could pop
> > up a bigger version of the chart? Or not needed?
> > - Would it be enough to have it in one color? Or should it be something
> > like "the bigger the utilization the more red"?
> >
> > Please advise from the UX perspective. As soon as the final design will be
> > a bit more clear I will provide a feature page.
> >
> > Thank you,
> > Tomas
> >
> > [1]: https://bugzilla.redhat.com/show_bug.cgi?id=803251
> > ___
> > Engine-devel mailing list
> > Engine-devel@ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/engine-devel
> >
> 
> a moving trend graph (just like fedora's system monitor for
> cpu/ram/network) is what i have in mind. so a line chart.
> you could have a single chart with different lines for cpu/ram/network,
> or what seems to be more common, a chart per monitored fact
> ___
> Engine-devel mailing list
> Engine-devel@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 
> 
> 
___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel

Re: [Engine-devel] IMP: Regarding an issue while translating the error messages for gluster using ErrorTranslator class

[Daniel Erez]

- Original Message -
> From: "Shubhendu Tripathi" 
> To: de...@redhat.com, "engine-devel" 
> Cc: "Dusmant Pati" 
> Sent: Wednesday, November 6, 2013 12:07:34 PM
> Subject: IMP: Regarding an issue while translating the error messages for 
> gluster using ErrorTranslator class
> 
> Hi,
> 
> In the case of Gluster, as there are no one to one mappings available
> for all the error messages from Gluster, we set the error in the
> VdcFault object as NULL.
> We also populate the actual error from the Gluster as error message in
> the fault object.
> 
> /getReturnValue().getExecuteFailedMessages().add(error);//
> //getReturnValue().getFault().setMessage(error);//
> //getReturnValue().getFault().setError(null);/
> 
> Because of above settings and the below code snippet in /Frontend.java/
> class the error message as is gets displayed on the error dialog -
> /
> //public String translateVdcFault(final VdcFault fault) {//
> //return
> getVdsmErrorsTranslator().TranslateErrorTextSingle(fault.getError() ==
> null//
> //? fault.getMessage() : fault.getError().toString());//
> //}//
> /
> Well and good till now !!
> 
> But while translation of the error messages, all the occurrences of "."
> get replaced with "_".
> This causes an issue for the gluster errors. If the error message sent
> from gluster has "."s (say IP Address of a host or FQDN for a host),
> that also gets replaced with "_" and the error message does not look
> correct.

This mechanism of replacing [1] has been introduced to allow proper
message translation when retrieving a message key that contains dots.
E.g. AppErrors.properties -> VALIDATION.ROLES.NAME.MAX is translated
to VALIDATION_ROLES_NAME_MAX in AppErrors.java interface (as interface
signatures cannot contain dots. Note that this process shouldn't
address the message; i.e. only the key is examined for dots.

As you've mentioned VdsmErrorsTranslator I guess there's an issue
only when translating VdsmErrors messages.
Can you please send an example of a message usage?
(and maybe try the same message using AppErrors instead)

[1] ErrorTranslator -> translateErrorTextSingle()

> 
> Request your suggestion for handling such a case.
> 
> *PS: *One thing I can think of is, introducing a flag called
> /isExternalError/ in /VdcFault/ class to identify if the source of the
> fault is external. From Gluster we would set the flag as /true/, and
> while replacement of "." with "_", if the flag is set it will not do the
> replacements.
> 
> Regards,
> Shubhendu
> 
___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel

Re: [Engine-devel] IMP: Regarding an issue while translating the error messages for gluster using ErrorTranslator class

[Einav Cohen]

> but if the message is not a key, and would be displayed as-is, on "." to "_"
> replacement should take place.

on -> no*

> - Original Message -
> From: "Einav Cohen" 
> Sent: Wednesday, November 6, 2013 9:10:09 AM
> 
> > - Original Message -
> > From: "Alexander Wels" 
> > Sent: Wednesday, November 6, 2013 8:28:13 AM
> > 
> > Looking at the code, if you start the error message with a $ it will not do
> > the . to _ replacement. Not sure if your error message will now simply
> > start
> > with a $, but it is worth a try I guess.
> 
> AFAIK: the '$' prefix is for variable-value message.
> e.g. if you have a message "cannot run VM ${vm-name}" and another one
> "$vm-name vm1",
> then their combination would eventually yield "cannot run VM vm1".
> Also, I think that messages that begin with "$" cannot be displayed when they
> are on their own.
> i.e. if you will get message "$vm-name vm1" 'alone', nothing will eventually
> be displayed.
> but, as I mentioned, if you will get message "$vm-name vm1" along with
> message "cannot run
> VM ${vm-name}", eventually "cannot run VM vm1" will be displayed.
> 
> I think that the replacement of "." to "_" should be done only if the message
> represents a *key* in the relevant resource (VdsmErrors in this case).
> but if the message is not a key, and would be displayed as-is, on "." to "_"
> replacement
> should take place.
> adding Derez for his thoughts (I think that he changed something around it a
> while ago).
> 
> > 
> > On Wednesday, November 06, 2013 03:37:34 PM Shubhendu Tripathi wrote:
> > > Hi,
> > > 
> > > In the case of Gluster, as there are no one to one mappings available
> > > for all the error messages from Gluster, we set the error in the
> > > VdcFault object as NULL.
> > > We also populate the actual error from the Gluster as error message in
> > > the fault object.
> > > 
> > > /getReturnValue().getExecuteFailedMessages().add(error);//
> > > //getReturnValue().getFault().setMessage(error);//
> > > //getReturnValue().getFault().setError(null);/
> > > 
> > > Because of above settings and the below code snippet in /Frontend.java/
> > > class the error message as is gets displayed on the error dialog -
> > > /
> > > //public String translateVdcFault(final VdcFault fault) {//
> > > //return
> > > getVdsmErrorsTranslator().TranslateErrorTextSingle(fault.getError() ==
> > > null//
> > > //? fault.getMessage() : fault.getError().toString());//
> > > //}//
> > > /
> > > Well and good till now !!
> > > 
> > > But while translation of the error messages, all the occurrences of "."
> > > get replaced with "_".
> > > This causes an issue for the gluster errors. If the error message sent
> > > from gluster has "."s (say IP Address of a host or FQDN for a host),
> > > that also gets replaced with "_" and the error message does not look
> > > correct.
> > > 
> > > Request your suggestion for handling such a case.
> > > 
> > > *PS: *One thing I can think of is, introducing a flag called
> > > /isExternalError/ in /VdcFault/ class to identify if the source of the
> > > fault is external. From Gluster we would set the flag as /true/, and
> > > while replacement of "." with "_", if the flag is set it will not do the
> > > replacements.
> > > 
> > > Regards,
> > > Shubhendu
> > 
> > ___
> > Engine-devel mailing list
> > Engine-devel@ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > 
> ___
> Engine-devel mailing list
> Engine-devel@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 
___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel

Re: [Engine-devel] IMP: Regarding an issue while translating the error messages for gluster using ErrorTranslator class

[Einav Cohen]

> - Original Message -
> From: "Alexander Wels" 
> Sent: Wednesday, November 6, 2013 8:28:13 AM
> 
> Looking at the code, if you start the error message with a $ it will not do
> the . to _ replacement. Not sure if your error message will now simply start
> with a $, but it is worth a try I guess.

AFAIK: the '$' prefix is for variable-value message.
e.g. if you have a message "cannot run VM ${vm-name}" and another one "$vm-name 
vm1", 
then their combination would eventually yield "cannot run VM vm1".
Also, I think that messages that begin with "$" cannot be displayed when they 
are on their own.
i.e. if you will get message "$vm-name vm1" 'alone', nothing will eventually be 
displayed. 
but, as I mentioned, if you will get message "$vm-name vm1" along with message 
"cannot run 
VM ${vm-name}", eventually "cannot run VM vm1" will be displayed.

I think that the replacement of "." to "_" should be done only if the message 
represents a *key* in the relevant resource (VdsmErrors in this case). 
but if the message is not a key, and would be displayed as-is, on "." to "_" 
replacement 
should take place.
adding Derez for his thoughts (I think that he changed something around it a 
while ago).

> 
> On Wednesday, November 06, 2013 03:37:34 PM Shubhendu Tripathi wrote:
> > Hi,
> > 
> > In the case of Gluster, as there are no one to one mappings available
> > for all the error messages from Gluster, we set the error in the
> > VdcFault object as NULL.
> > We also populate the actual error from the Gluster as error message in
> > the fault object.
> > 
> > /getReturnValue().getExecuteFailedMessages().add(error);//
> > //getReturnValue().getFault().setMessage(error);//
> > //getReturnValue().getFault().setError(null);/
> > 
> > Because of above settings and the below code snippet in /Frontend.java/
> > class the error message as is gets displayed on the error dialog -
> > /
> > //public String translateVdcFault(final VdcFault fault) {//
> > //return
> > getVdsmErrorsTranslator().TranslateErrorTextSingle(fault.getError() ==
> > null//
> > //? fault.getMessage() : fault.getError().toString());//
> > //}//
> > /
> > Well and good till now !!
> > 
> > But while translation of the error messages, all the occurrences of "."
> > get replaced with "_".
> > This causes an issue for the gluster errors. If the error message sent
> > from gluster has "."s (say IP Address of a host or FQDN for a host),
> > that also gets replaced with "_" and the error message does not look
> > correct.
> > 
> > Request your suggestion for handling such a case.
> > 
> > *PS: *One thing I can think of is, introducing a flag called
> > /isExternalError/ in /VdcFault/ class to identify if the source of the
> > fault is external. From Gluster we would set the flag as /true/, and
> > while replacement of "." with "_", if the flag is set it will not do the
> > replacements.
> > 
> > Regards,
> > Shubhendu
> 
> ___
> Engine-devel mailing list
> Engine-devel@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 
___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel

Re: [Engine-devel] IMP: Regarding an issue while translating the error messages for gluster using ErrorTranslator class

[Alexander Wels]

Looking at the code, if you start the error message with a $ it will not do 
the . to _ replacement. Not sure if your error message will now simply start 
with a $, but it is worth a try I guess.

On Wednesday, November 06, 2013 03:37:34 PM Shubhendu Tripathi wrote:
> Hi,
> 
> In the case of Gluster, as there are no one to one mappings available
> for all the error messages from Gluster, we set the error in the
> VdcFault object as NULL.
> We also populate the actual error from the Gluster as error message in
> the fault object.
> 
> /getReturnValue().getExecuteFailedMessages().add(error);//
> //getReturnValue().getFault().setMessage(error);//
> //getReturnValue().getFault().setError(null);/
> 
> Because of above settings and the below code snippet in /Frontend.java/
> class the error message as is gets displayed on the error dialog -
> /
> //public String translateVdcFault(final VdcFault fault) {//
> //return
> getVdsmErrorsTranslator().TranslateErrorTextSingle(fault.getError() ==
> null//
> //? fault.getMessage() : fault.getError().toString());//
> //}//
> /
> Well and good till now !!
> 
> But while translation of the error messages, all the occurrences of "."
> get replaced with "_".
> This causes an issue for the gluster errors. If the error message sent
> from gluster has "."s (say IP Address of a host or FQDN for a host),
> that also gets replaced with "_" and the error message does not look
> correct.
> 
> Request your suggestion for handling such a case.
> 
> *PS: *One thing I can think of is, introducing a flag called
> /isExternalError/ in /VdcFault/ class to identify if the source of the
> fault is external. From Gluster we would set the flag as /true/, and
> while replacement of "." with "_", if the flag is set it will not do the
> replacements.
> 
> Regards,
> Shubhendu

___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel

Re: [Engine-devel] RFE: SPICE and VNC graphics at the same time

[Frantisek Kobzik]

No, just two  framebuffers.

- Original Message -
From: "Omer Frenkel" 
To: "Frantisek Kobzik" 
Cc: "engine-devel" 
Sent: Wednesday, November 6, 2013 1:20:42 PM
Subject: Re: [Engine-devel] RFE: SPICE and VNC graphics at the same time



- Original Message -
> From: "Frantisek Kobzik" 
> To: "engine-devel" 
> Sent: Wednesday, November 6, 2013 11:33:28 AM
> Subject: [Engine-devel] RFE: SPICE and VNC graphics at the same time
> 
> Dear devels,
> 
> I started working on a feature that allows user to run a VM with both SPICE
> and VNC graphics [1]. In the engine we derive the graphics server type
> (SPICE/VNC) from the video device (QXL/CIRRUS), which I think is wrong.
> These are two different things and should be treated separately. What I
> suggest is to split that configuration in vm_static into two fields:
>  1, (already existing) Display type with values QXL or CIRRUS
>  2, (new) Graphics types - enum or comma-separated string that indicates that
>  the VM should be run with 'spice'/'vnc'/'spice,vnc'/'auto' (the last means
>  that the type will be derived from the video device which is current
>  behavior.
> 

when choosing both, does this mean vm will have 2 video devices (cards)?

> The feature would consist of three patches:
>  - vdsm - add new field in vm.conf with information about graphics types of a
>  vm.
>  - engine backend - add graphics types to VM and corresponding entities,
>  adjust xml rpc communication.
>  - engine frontend - "only" adjust the ui.
> 
> The patches would be backwards compatible with older engine/vdsm versions.
> 
> There are some things that must be taken into account, mostly it's about
> differences in SPICE/VNC supported features (like multimonitors, single qxl,
> smartcard, migration...). e.g. if you run a vm with both graphic types
> together the engine should probably disallow some spice features. But this
> is more of an implementation detail.
> 
> Feel free to reply if you have anything to say about this feature.
> 
> Cheers,
> Franta.
> 
> 
> [1]: https://bugzilla.redhat.com/show_bug.cgi?id=976044
> ___
> Engine-devel mailing list
> Engine-devel@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 
___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel

Re: [Engine-devel] RFE: SPICE and VNC graphics at the same time

[Omer Frenkel]

- Original Message -
> From: "Frantisek Kobzik" 
> To: "engine-devel" 
> Sent: Wednesday, November 6, 2013 11:33:28 AM
> Subject: [Engine-devel] RFE: SPICE and VNC graphics at the same time
> 
> Dear devels,
> 
> I started working on a feature that allows user to run a VM with both SPICE
> and VNC graphics [1]. In the engine we derive the graphics server type
> (SPICE/VNC) from the video device (QXL/CIRRUS), which I think is wrong.
> These are two different things and should be treated separately. What I
> suggest is to split that configuration in vm_static into two fields:
>  1, (already existing) Display type with values QXL or CIRRUS
>  2, (new) Graphics types - enum or comma-separated string that indicates that
>  the VM should be run with 'spice'/'vnc'/'spice,vnc'/'auto' (the last means
>  that the type will be derived from the video device which is current
>  behavior.
> 

when choosing both, does this mean vm will have 2 video devices (cards)?

> The feature would consist of three patches:
>  - vdsm - add new field in vm.conf with information about graphics types of a
>  vm.
>  - engine backend - add graphics types to VM and corresponding entities,
>  adjust xml rpc communication.
>  - engine frontend - "only" adjust the ui.
> 
> The patches would be backwards compatible with older engine/vdsm versions.
> 
> There are some things that must be taken into account, mostly it's about
> differences in SPICE/VNC supported features (like multimonitors, single qxl,
> smartcard, migration...). e.g. if you run a vm with both graphic types
> together the engine should probably disallow some spice features. But this
> is more of an implementation detail.
> 
> Feel free to reply if you have anything to say about this feature.
> 
> Cheers,
> Franta.
> 
> 
> [1]: https://bugzilla.redhat.com/show_bug.cgi?id=976044
> ___
> Engine-devel mailing list
> Engine-devel@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 
___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel

Re: [Engine-devel] RFE: SPICE and VNC graphics at the same time

[Michal Skrivanek]

On Nov 6, 2013, at 10:33 , Frantisek Kobzik  wrote:

> Dear devels,
> 
> I started working on a feature that allows user to run a VM with both SPICE 
> and VNC graphics [1]. In the engine we derive the graphics server type 
> (SPICE/VNC) from the video device (QXL/CIRRUS), which I think is wrong. These 
> are two different things and should be treated separately. What I suggest is 
> to split that configuration in vm_static into two fields:
> 1, (already existing) Display type with values QXL or CIRRUS
> 2, (new) Graphics types - enum or comma-separated string that indicates that 
> the VM should be run with 'spice'/'vnc'/'spice,vnc'/'auto' (the last means 
> that the type will be derived from the video device which is current behavior.

pls take a look at http://gerrit.ovirt.org/#/c/18677/

> 
> The feature would consist of three patches:
> - vdsm - add new field in vm.conf with information about graphics types of a 
> vm.
> - engine backend - add graphics types to VM and corresponding entities, 
> adjust xml rpc communication.
> - engine frontend - "only" adjust the ui.
> 
> The patches would be backwards compatible with older engine/vdsm versions.
> 
> There are some things that must be taken into account, mostly it's about 
> differences in SPICE/VNC supported features (like multimonitors, single qxl, 
> smartcard, migration...). e.g. if you run a vm with both graphic types 
> together the engine should probably disallow some spice features. But this is 
> more of an implementation detail.
> 
> Feel free to reply if you have anything to say about this feature.
> 
> Cheers,
> Franta.
> 
> 
> [1]: https://bugzilla.redhat.com/show_bug.cgi?id=976044
> ___
> Engine-devel mailing list
> Engine-devel@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel

___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel

Re: [Engine-devel] daily oVirt 3.3.1 blocker status

[Eduardo Warszawski]

- Original Message -
> Hi,
> only one bloker remains to be fixed:
> Bug 1022961 - Running a VM from a gluster domain uses mount instead of
> gluster URI
> I don't see any activity about it.
> Can anybody join Eduardo for fixing it ASAP?
> 
I'm working on it. 
Hope soon we will have a fix.
Don't panic! :)

> 
> --
> Sandro Bonazzola
> Better technology. Faster innovation. Powered by community collaboration.
> See how it works at redhat.com
> 
___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel

[Engine-devel] IMP: Regarding an issue while translating the error messages for gluster using ErrorTranslator class

[Shubhendu Tripathi]

Hi,

In the case of Gluster, as there are no one to one mappings available 
for all the error messages from Gluster, we set the error in the 
VdcFault object as NULL.
We also populate the actual error from the Gluster as error message in 
the fault object.


/getReturnValue().getExecuteFailedMessages().add(error);//
//getReturnValue().getFault().setMessage(error);//
//getReturnValue().getFault().setError(null);/

Because of above settings and the below code snippet in /Frontend.java/ 
class the error message as is gets displayed on the error dialog -

/
//public String translateVdcFault(final VdcFault fault) {//
//return 
getVdsmErrorsTranslator().TranslateErrorTextSingle(fault.getError() == 
null//

//? fault.getMessage() : fault.getError().toString());//
//}//
/
Well and good till now !!

But while translation of the error messages, all the occurrences of "." 
get replaced with "_".
This causes an issue for the gluster errors. If the error message sent 
from gluster has "."s (say IP Address of a host or FQDN for a host), 
that also gets replaced with "_" and the error message does not look 
correct.


Request your suggestion for handling such a case.

*PS: *One thing I can think of is, introducing a flag called 
/isExternalError/ in /VdcFault/ class to identify if the source of the 
fault is external. From Gluster we would set the flag as /true/, and 
while replacement of "." with "_", if the flag is set it will not do the 
replacements.


Regards,
Shubhendu
___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel

[Engine-devel] RFE: SPICE and VNC graphics at the same time

[Frantisek Kobzik]

Dear devels,

I started working on a feature that allows user to run a VM with both SPICE and 
VNC graphics [1]. In the engine we derive the graphics server type (SPICE/VNC) 
from the video device (QXL/CIRRUS), which I think is wrong. These are two 
different things and should be treated separately. What I suggest is to split 
that configuration in vm_static into two fields:
 1, (already existing) Display type with values QXL or CIRRUS
 2, (new) Graphics types - enum or comma-separated string that indicates that 
the VM should be run with 'spice'/'vnc'/'spice,vnc'/'auto' (the last means that 
the type will be derived from the video device which is current behavior.

The feature would consist of three patches:
 - vdsm - add new field in vm.conf with information about graphics types of a 
vm.
 - engine backend - add graphics types to VM and corresponding entities, adjust 
xml rpc communication.
 - engine frontend - "only" adjust the ui.

The patches would be backwards compatible with older engine/vdsm versions.

There are some things that must be taken into account, mostly it's about 
differences in SPICE/VNC supported features (like multimonitors, single qxl, 
smartcard, migration...). e.g. if you run a vm with both graphic types together 
the engine should probably disallow some spice features. But this is more of an 
implementation detail.

Feel free to reply if you have anything to say about this feature.

Cheers,
Franta.


[1]: https://bugzilla.redhat.com/show_bug.cgi?id=976044
___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel