Description of problem: Go to Grid -> Overview -> Summary and click on "Show time series chart". SubBug 1: I have 2 slots. Both are unclaimed. I expect that line will be on the level of number 2. As you can see on picture it is not. SubBug2: It is not possible to have 1.47 or 0.73 of slot. I think graph should have this axis in integer numbers. SubBug3: I think it is not useful have on time axis information "6 min" for every value. I think there should be reasonable values like 1min, 2min, 3min and so on. SubBug4: I'm able to make graph empty just by randomly changing ranges of time axis. Refresh of the webpage is not solution because it cleans my choices in graph. I don't see any Javascript error in Firebug console or in Cumin logs. Cleaned graph is visible on second picture. I suggest: a) add button which will completely refresh only data in graph b) fix the problem Version-Release number of selected component (if applicable): condor-7.8.7-0.6.el6_3.x86_64 condor-aviary-7.8.7-0.6.el6_3.x86_64 condor-classads-7.8.7-0.6.el6_3.x86_64 condor-debuginfo-7.8.7-0.6.el6_3.x86_64 condor-plumage-7.8.7-0.6.el6_3.x86_64 condor-qmf-7.8.7-0.6.el6_3.x86_64 condor-wallaby-base-db-1.25-1.el6_3.noarch condor-wallaby-client-5.0.4-1.el6_3.noarch condor-wallaby-tools-5.0.4-1.el6_3.noarch cumin-0.1.5564-1.el6_3.noarch python-condorutils-1.5-6.el6.noarch python-qpid-0.18-4.el6.noarch python-qpid-qmf-0.18-12.el6_3.x86_64 python-wallaby-0.16.1-2.el6.noarch python-wallabyclient-5.0.4-1.el6_3.noarch qpid-cpp-client-0.18-12.el6_3.x86_64 qpid-cpp-client-devel-0.18-12.el6_3.x86_64 qpid-cpp-client-devel-docs-0.18-12.el6_3.noarch qpid-cpp-server-0.18-12.el6_3.x86_64 qpid-cpp-server-cluster-0.18-12.el6_3.x86_64 qpid-cpp-server-devel-0.18-12.el6_3.x86_64 qpid-cpp-server-store-0.18-12.el6_3.x86_64 qpid-cpp-server-xml-0.18-12.el6_3.x86_64 qpid-java-client-0.18-5.el6.noarch qpid-java-common-0.18-5.el6.noarch qpid-java-example-0.18-5.el6.noarch qpid-qmf-0.18-12.el6_3.x86_64 qpid-qmf-debuginfo-0.18-12.el6_3.x86_64 qpid-qmf-devel-0.18-12.el6_3.x86_64 qpid-tools-0.18-7.el6_3.noarch ruby-condor-wallaby-5.0.4-1.el6_3.noarch ruby-qpid-qmf-0.18-12.el6_3.x86_64 ruby-wallaby-0.16.1-2.el6.noarch wallaby-0.16.1-2.el6.noarch wallaby-utils-0.16.1-2.el6.noarch Mozilla/5.0 (X11; Linux x86_64; rv:10.0.11) Gecko/20100101 Firefox/10.0.11 How reproducible: All subbugs 100%
SubBug 1: I have 2 slots. Both are unclaimed. I expect that line will be on the level of number 2. As you can see on picture it is not. [Chad] Actually, it is....if you look at the tooltip, you can see that the value is "2". The way that the charting library handles padding of the chart results in the "2" hashmark being above the actual "2" value....confusing...yes. The "2" hashmark is actually above the real "2" value. The library tries to space-out the tick marks evenly (per the options I've given it). The artifact here is that it is obviously off a bit for small values. SubBug2: It is not possible to have 1.47 or 0.73 of slot. I think graph should have this axis in integer numbers. [Chad] Slightly related to the previous issue. This is another artifact of how the library handles generating the tick values. For many of our charts, non integer values are useful on the y-axis (as we display values like 25.3k, etc). I wouldn't mind seeing an RFE that requests more appropriate tuning for each individual chart. SubBug3: I think it is not useful have on time axis information "6 min" for every value. I think there should be reasonable values like 1min, 2min, 3min and so on. [Chad] Looks like you have zoomed in to a very narrow slice of the graph here. We could display values like 6.1min, 6.2min, etc, but we quickly run out of space if we go to more decimal places. It will always be possible to zoom narrow enough to cause this sort of artifact. We can turn off zooming entirely, but I think it is still useful even with this artifact. The tooltips can still be used to get the precise time values. I'm going to recommend a future RFE for these items. Ideally, as the underlying charting library gets more mature, we will have better options available to us.
What about SubBug4?
Sorry.... I have a hunch that SubBug4 may be a side-effect of zooming to a very small slice of time. Can you try double-clicking on the graph when you have it in this state. Double-clicking resets the zoom level and I'm thinking that this may solve the problem.
SubBug4: Yes, that is true. But I think it should work always, so it is a bug. And yes, there is workaround.
MRG-Grid is in maintenance and only customer escalations will be considered. This issue can be reopened if a customer escalation associated with it occurs.