From jenkins at ovirt.org Fri Nov 1 00:04:13 2013 From: jenkins at ovirt.org (Jenkins ci oVirt Server) Date: Fri, 1 Nov 2013 00:04:13 +0000 (GMT) Subject: [Engine-devel] [oVirt jenkins] Weekly report on open tasks for ovirt-engine Message-ID: <1240822811.143.1383264257476.JavaMail.jenkins@jenkins.ovirt.org> An HTML attachment was scrubbed... URL: From ecohen at redhat.com Sun Nov 3 17:01:28 2013 From: ecohen at redhat.com (Einav Cohen) Date: Sun, 3 Nov 2013 12:01:28 -0500 (EST) Subject: [Engine-devel] ovirt live 1.1: 'local_vm' stuck in Wait For Launch In-Reply-To: <29052610.18228574.1383497424276.JavaMail.root@redhat.com> Message-ID: <1741418377.18229108.1383498088938.JavaMail.root@redhat.com> Hi All, In my ovirt live 1.1 system (ran as-is, done no alterations to the system once "installed"), after attempting to run the default 'local_vm' VM, it is getting stuck on 'Wait For Launch'. I tried running the ovirt live 1.1 system for ~5 times, only in one of these times the VM has actually moved to the Powering Up / Up state when attempting to run it. Any ideas? [attached engine.log, vdsm.log] Many thanks in advance! ---- Regards, Einav -------------- next part -------------- A non-text attachment was scrubbed... Name: vdsm.log Type: text/x-log Size: 38609 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: engine.log Type: text/x-log Size: 3546 bytes Desc: not available URL: From danken at redhat.com Sun Nov 3 22:42:11 2013 From: danken at redhat.com (Dan Kenigsberg) Date: Sun, 3 Nov 2013 22:42:11 +0000 Subject: [Engine-devel] ovirt live 1.1: 'local_vm' stuck in Wait For Launch In-Reply-To: <1741418377.18229108.1383498088938.JavaMail.root@redhat.com> References: <29052610.18228574.1383497424276.JavaMail.root@redhat.com> <1741418377.18229108.1383498088938.JavaMail.root@redhat.com> Message-ID: <20131103224211.GH25997@redhat.com> On Sun, Nov 03, 2013 at 12:01:28PM -0500, Einav Cohen wrote: > Hi All, > > In my ovirt live 1.1 system (ran as-is, done no alterations to the system once "installed"), > after attempting to run the default 'local_vm' VM, it is getting stuck on 'Wait For Launch'. > I tried running the ovirt live 1.1 system for ~5 times, only in one of these times the VM > has actually moved to the Powering Up / Up state when attempting to run it. > Any ideas? > > [attached engine.log, vdsm.log] > > Many thanks in advance! > > ---- > Regards, > Einav snip > > libvirtEventLoop::DEBUG::2013-11-03 11:52:26,383::vm::4724::vm.Vm::(_onLibvirtLifecycleEvent) vmId=`1f0a2763-5c40-4fa3-a51c-ed98276b8e6d`::event Started detail 0 opaque None > Thread-126::DEBUG::2013-11-03 11:52:26,465::sampling::285::vm.Vm::(start) vmId=`1f0a2763-5c40-4fa3-a51c-ed98276b8e6d`::Start statistics collection > Thread-128::DEBUG::2013-11-03 11:52:26,479::sampling::314::vm.Vm::(run) vmId=`1f0a2763-5c40-4fa3-a51c-ed98276b8e6d`::Stats thread started > Thread-128::DEBUG::2013-11-03 11:52:26,480::task::579::TaskManager.Task::(_updateState) Task=`06de0c6d-28e6-4c20-9139-90c3f440dc6b`::moving from state init -> state preparing > Thread-128::INFO::2013-11-03 11:52:26,480::logUtils::44::dispatcher::(wrapper) Run and protect: getVolumeSize(sdUUID='5b5e5322-df22-4516-860b-361f00c46233', spUUID='9b476274-7c1c-4762-8cb4-699c2729b152', imgUUID='a544c2c3-cf3a-42c7-8e20-371344ad22da', volUUID='bcabc2ba-b7e1-47f9-9098-bbe19b096ad5', options=None) > Thread-128::DEBUG::2013-11-03 11:52:26,483::fileVolume::520::Storage.Volume::(validateVolumePath) validate path for bcabc2ba-b7e1-47f9-9098-bbe19b096ad5 > Thread-128::INFO::2013-11-03 11:52:26,485::logUtils::47::dispatcher::(wrapper) Run and protect: getVolumeSize, Return response: {'truesize': '139264', 'apparentsize': '262144'} > Thread-128::DEBUG::2013-11-03 11:52:26,485::task::1168::TaskManager.Task::(prepare) Task=`06de0c6d-28e6-4c20-9139-90c3f440dc6b`::finished: {'truesize': '139264', 'apparentsize': '262144'} > Thread-128::DEBUG::2013-11-03 11:52:26,485::task::579::TaskManager.Task::(_updateState) Task=`06de0c6d-28e6-4c20-9139-90c3f440dc6b`::moving from state preparing -> state finished > Thread-128::DEBUG::2013-11-03 11:52:26,485::resourceManager::939::ResourceManager.Owner::(releaseAll) Owner.releaseAll requests {} resources {} > Thread-128::DEBUG::2013-11-03 11:52:26,485::resourceManager::976::ResourceManager.Owner::(cancelAll) Owner.cancelAll requests {} > Thread-128::DEBUG::2013-11-03 11:52:26,491::task::974::TaskManager.Task::(_decref) Task=`06de0c6d-28e6-4c20-9139-90c3f440dc6b`::ref 0 aborting False > Thread-126::DEBUG::2013-11-03 11:52:26,507::vmChannels::194::vds::(register) Add fileno 45 to listener's channels. > Thread-126::WARNING::2013-11-03 11:52:26,522::vm::3326::vm.Vm::(_readPauseCode) vmId=`1f0a2763-5c40-4fa3-a51c-ed98276b8e6d`::_readPauseCode unsupported by libvirt vm > Thread-126::DEBUG::2013-11-03 11:52:26,552::vm::2036::vm.Vm::(_startUnderlyingVm) vmId=`1f0a2763-5c40-4fa3-a51c-ed98276b8e6d`::_ongoingCreations released Is this a log of a successful or of a failed attempt? "_ongoingCreations released" (should) mean that the Vm is "Up" as much as Vdsm concerns. Could you verify that Vdsm reports "Wait For Launch" via vdsClient? Could you attach libvirtd.log from a failed attempt? Which kernel and qemu-kvm are you using? From sbonazzo at redhat.com Mon Nov 4 08:05:19 2013 From: sbonazzo at redhat.com (Sandro Bonazzola) Date: Mon, 04 Nov 2013 09:05:19 +0100 Subject: [Engine-devel] daily oVirt 3.3.1 blocker status In-Reply-To: <52720B88.9080001@redhat.com> References: <52720B88.9080001@redhat.com> Message-ID: <5277553F.3010807@redhat.com> Il 31/10/2013 08:49, Sandro Bonazzola ha scritto: > Hi, > The following blockers are still not fixed: > VDSM: > Bug 1022961 - Running a VM from a gluster domain uses mount instead of gluster URI > Bug 1022975 - [vdsm] storage domain upgrade fails with attributeError > > Federico, Eduardo, can you provide an ETA for those? Still not fixed with no ETA. > I'm not aware of other blockers. > If you're aware of any other blocker, please add it to the tracker bug (Bug 1019391 - Tracker: oVirt 3.3.1 release) -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com From danken at redhat.com Mon Nov 4 09:26:00 2013 From: danken at redhat.com (Dan Kenigsberg) Date: Mon, 4 Nov 2013 09:26:00 +0000 Subject: [Engine-devel] daily oVirt 3.3.1 blocker status In-Reply-To: <5277553F.3010807@redhat.com> References: <52720B88.9080001@redhat.com> <5277553F.3010807@redhat.com> Message-ID: <20131104092600.GB27545@redhat.com> On Mon, Nov 04, 2013 at 09:05:19AM +0100, Sandro Bonazzola wrote: > Il 31/10/2013 08:49, Sandro Bonazzola ha scritto: > > Hi, > > The following blockers are still not fixed: > > VDSM: > > Bug 1022961 - Running a VM from a gluster domain uses mount instead of gluster URI > > Bug 1022975 - [vdsm] storage domain upgrade fails with attributeError > > > > Federico, Eduardo, can you provide an ETA for those? > > Still not fixed with no ETA. WWIW, Bug 1022975 is solved by http://gerrit.ovirt.org/20721; waiting only for a formal verification. From vszocs at redhat.com Mon Nov 4 11:27:46 2013 From: vszocs at redhat.com (Vojtech Szocs) Date: Mon, 4 Nov 2013 06:27:46 -0500 (EST) Subject: [Engine-devel] [Engine-patches] Change in ovirt-engine[master]: packaging: build: perform python validations during build In-Reply-To: References: Message-ID: <214262738.17580229.1383564466090.JavaMail.root@redhat.com> Hi Alon, I'm getting an error after this patch got merged: $ make clean install-dev PREFIX="$OVIRT_OUT" JBOSS_HOME="$JBOSS_HOME" ... if [ "1" != 0 ]; then \ build/python-check.sh; \ fi build/python-check.sh: line 16: pyflakes: command not found build/python-check.sh: line 17: pep8: command not found make[1]: *** [python-validation] Error 1 make[1]: Leaving directory `/home/vszocs/work/ovirt-engine' make: *** [all-dev] Error 2 I assume "pyflakes" and "pep8" are Python packages, shouldn't README.developer mention they're required now (?) I was able to fix my problem by doing: # yum install python-pip # pip install pyflakes # pip install pep8 Vojtech ----- Original Message ----- > From: "Alon Bar-Lev" > Cc: "Alon Bar-Lev" > Sent: Sunday, November 3, 2013 1:39:24 PM > Subject: [Engine-patches] Change in ovirt-engine[master]: packaging: build: perform python validations during build > > Alon Bar-Lev has uploaded a new change for review. > > Change subject: packaging: build: perform python validations during build > ...................................................................... > > packaging: build: perform python validations during build > > Change-Id: Ie4ee9bf80b8a8a75464338bc047dd16e22f0e63b > Signed-off-by: Alon Bar-Lev > --- > M .gitignore > M Makefile > A build/python-check.sh.in > M ovirt-engine.spec.in > D packaging/check.sh > 5 files changed, 35 insertions(+), 15 deletions(-) > > > git pull ssh://gerrit.ovirt.org:29418/ovirt-engine refs/changes/27/20827/1 > > diff --git a/.gitignore b/.gitignore > index fb33e33..bc736d2 100644 > --- a/.gitignore > +++ b/.gitignore > @@ -43,6 +43,7 @@ > # Files generated from templates > ########################### > ovirt-engine.spec > +build/python-check.sh > packaging/bin/engine-prolog.sh > packaging/bin/ovirt-engine-log-setup-event.sh > packaging/bin/pki-common.sh > diff --git a/Makefile b/Makefile > index 6047d31..b6063ad 100644 > --- a/Makefile > +++ b/Makefile > @@ -31,6 +31,7 @@ > BUILD_DEV=0 > BUILD_UT=1 > EXTRA_BUILD_FLAGS= > +BUILD_PYTHON_VALIDATION=1 > DEV_REBUILD=1 > DEV_BUILD_GWT_DRAFT=0 > DEV_EXTRA_BUILD_FLAGS= > @@ -41,6 +42,8 @@ > MVN=mvn > RPMBUILD=rpmbuild > PYTHON=python > +PYFLAKES=pyflakes > +PEP8=pep8 > PREFIX=/usr/local > LOCALSTATE_DIR=$(PREFIX)/var > BIN_DIR=$(PREFIX)/bin > @@ -147,11 +150,14 @@ > -e "s|@PACKAGE_VERSION@|$(PACKAGE_VERSION)|g" \ > -e "s|@DISPLAY_VERSION@|$(DISPLAY_VERSION)|g" \ > -e "s|@JBOSS_HOME@|$(JBOSS_HOME)|g" \ > + -e "s|@PEP8@|$(PEP8)|g" \ > + -e "s|@PYFLAKES@|$(PYFLAKES)|g" \ > $< > $@ > > # List of files that will be generated from templates: > GENERATED = \ > ovirt-engine.spec \ > + build/python-check.sh \ > packaging/bin/engine-prolog.sh \ > packaging/bin/ovirt-engine-log-setup-event.sh \ > packaging/bin/pki-common.sh \ > @@ -184,11 +190,13 @@ > > all: \ > generated-files \ > + python-validation \ > dbscripts-validations \ > $(BUILD_FILE) \ > $(NULL) > > generated-files: $(GENERATED) > + chmod a+x build/python-check.sh > chmod a+x packaging/services/ovirt-engine/ovirt-engine.sysv > chmod a+x > packaging/services/ovirt-engine-notifier/ovirt-engine-notifier.sysv > chmod a+x > packaging/services/ovirt-websocket-proxy/ovirt-websocket-proxy.sysv > @@ -300,6 +308,11 @@ > [ -x "$(SOURCEDIR)/$${f}" ] && MASK=0755 || MASK=0644; \ > install -m "$${MASK}" "$(SOURCEDIR)/$${f}" "$$(dirname > "$(TARGETDIR)/$${f}")"; \ > done > + > +python-validation: > + if [ "$(BUILD_PYTHON_VALIDATION)" != 0 ]; then \ > + build/python-check.sh; \ > + fi > > dbscripts-validations: > test/dbscripts/check_for_duplicate_upgrade_scripts.sh > @@ -417,6 +430,7 @@ > $(MAKE) \ > install \ > BUILD_DEV=1 \ > + BUILD_PYTHON_VALIDATION=0 \ > PYTHON_DIR="$(PREFIX)$(PYTHON_SYS_DIR)" \ > $(NULL) > > diff --git a/build/python-check.sh.in b/build/python-check.sh.in > new file mode 100755 > index 0000000..d13c820 > --- /dev/null > +++ b/build/python-check.sh.in > @@ -0,0 +1,19 @@ > +#!/bin/sh > + > +PEP8="@PEP8@" > +PYFLAKES="@PYFLAKES@" > +SRCDIR="$(dirname "$0")/.." > + > +cd "${SRCDIR}" > + > +ret=0 > +FILES="$( > + find build packaging -name '*.py' | while read f; do > + [ -e "${f}.in" ] || echo "${f}" > + done > +)" > + > +"${PYFLAKES}" ${FILES} || ret=1 > +"${PEP8}" ${FILES} || ret=1 > + > +exit ${ret} > diff --git a/ovirt-engine.spec.in b/ovirt-engine.spec.in > index af2a9c9..c06faf2 100644 > --- a/ovirt-engine.spec.in > +++ b/ovirt-engine.spec.in > @@ -110,6 +110,7 @@ > BUILD_GWT=%{ovirt_build_gwt} \\\ > BUILD_LOCALES=%{ovirt_build_locales} \\\ > BUILD_UT=%{ovirt_build_ut} \\\ > + BUILD_PYTHON_VALIDATION=0 \\\ > PACKAGE_NAME=%{name} \\\ > RPM_VERSION=%{version} \\\ > RPM_RELEASE=%{release} \\\ > diff --git a/packaging/check.sh b/packaging/check.sh > deleted file mode 100755 > index ef6e0d6..0000000 > --- a/packaging/check.sh > +++ /dev/null > @@ -1,15 +0,0 @@ > -#!/bin/sh > - > -BASE="$(dirname "$0")" > - > -FILES="$( > - find "${BASE}" -name '*.py' | while read f; do > - [ -e "${f}.in" ] || echo "${f}" > - done > -)" > - > -ret=0 > -pyflakes ${FILES} || ret=1 > -pep8 ${FILES} || ret=1 > - > -exit "${ret}" > > > -- > To view, visit http://gerrit.ovirt.org/20827 > To unsubscribe, visit http://gerrit.ovirt.org/settings > > Gerrit-MessageType: newchange > Gerrit-Change-Id: Ie4ee9bf80b8a8a75464338bc047dd16e22f0e63b > Gerrit-PatchSet: 1 > Gerrit-Project: ovirt-engine > Gerrit-Branch: master > Gerrit-Owner: Alon Bar-Lev > _______________________________________________ > Engine-patches mailing list > Engine-patches at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-patches > From alonbl at redhat.com Mon Nov 4 11:40:28 2013 From: alonbl at redhat.com (Alon Bar-Lev) Date: Mon, 4 Nov 2013 06:40:28 -0500 (EST) Subject: [Engine-devel] [Engine-patches] Change in ovirt-engine[master]: packaging: build: perform python validations during build In-Reply-To: <214262738.17580229.1383564466090.JavaMail.root@redhat.com> References: <214262738.17580229.1383564466090.JavaMail.root@redhat.com> Message-ID: <899627606.12018557.1383565228969.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Vojtech Szocs" > To: "Alon Bar-Lev" > Cc: "engine-devel" > Sent: Monday, November 4, 2013 1:27:46 PM > Subject: Re: [Engine-patches] Change in ovirt-engine[master]: packaging: build: perform python validations during > build > > Hi Alon, I'm getting an error after this patch got merged: > > $ make clean install-dev PREFIX="$OVIRT_OUT" JBOSS_HOME="$JBOSS_HOME" > > ... > if [ "1" != 0 ]; then \ > build/python-check.sh; \ > fi > build/python-check.sh: line 16: pyflakes: command not found > build/python-check.sh: line 17: pep8: command not found > make[1]: *** [python-validation] Error 1 > make[1]: Leaving directory `/home/vszocs/work/ovirt-engine' > make: *** [all-dev] Error 2 > > I assume "pyflakes" and "pep8" are Python packages, shouldn't > README.developer mention they're required now (?) > > I was able to fix my problem by doing: > > # yum install python-pip > # pip install pyflakes > # pip install pep8 Hi! Thanks! For some reason I assumed these tools are installed while they are not. I made this optional per[1] Workaround, add BUILD_PYTHON_VALIDATION=0 to make for now. Regards, Alon Bar-Lev [1] http://gerrit.ovirt.org/#/c/20851/ > Vojtech > > > ----- Original Message ----- > > From: "Alon Bar-Lev" > > Cc: "Alon Bar-Lev" > > Sent: Sunday, November 3, 2013 1:39:24 PM > > Subject: [Engine-patches] Change in ovirt-engine[master]: packaging: build: > > perform python validations during build > > > > Alon Bar-Lev has uploaded a new change for review. > > > > Change subject: packaging: build: perform python validations during build > > ...................................................................... > > > > packaging: build: perform python validations during build > > > > Change-Id: Ie4ee9bf80b8a8a75464338bc047dd16e22f0e63b > > Signed-off-by: Alon Bar-Lev > > --- > > M .gitignore > > M Makefile > > A build/python-check.sh.in > > M ovirt-engine.spec.in > > D packaging/check.sh > > 5 files changed, 35 insertions(+), 15 deletions(-) > > > > > > git pull ssh://gerrit.ovirt.org:29418/ovirt-engine > > refs/changes/27/20827/1 > > > > diff --git a/.gitignore b/.gitignore > > index fb33e33..bc736d2 100644 > > --- a/.gitignore > > +++ b/.gitignore > > @@ -43,6 +43,7 @@ > > # Files generated from templates > > ########################### > > ovirt-engine.spec > > +build/python-check.sh > > packaging/bin/engine-prolog.sh > > packaging/bin/ovirt-engine-log-setup-event.sh > > packaging/bin/pki-common.sh > > diff --git a/Makefile b/Makefile > > index 6047d31..b6063ad 100644 > > --- a/Makefile > > +++ b/Makefile > > @@ -31,6 +31,7 @@ > > BUILD_DEV=0 > > BUILD_UT=1 > > EXTRA_BUILD_FLAGS= > > +BUILD_PYTHON_VALIDATION=1 > > DEV_REBUILD=1 > > DEV_BUILD_GWT_DRAFT=0 > > DEV_EXTRA_BUILD_FLAGS= > > @@ -41,6 +42,8 @@ > > MVN=mvn > > RPMBUILD=rpmbuild > > PYTHON=python > > +PYFLAKES=pyflakes > > +PEP8=pep8 > > PREFIX=/usr/local > > LOCALSTATE_DIR=$(PREFIX)/var > > BIN_DIR=$(PREFIX)/bin > > @@ -147,11 +150,14 @@ > > -e "s|@PACKAGE_VERSION@|$(PACKAGE_VERSION)|g" \ > > -e "s|@DISPLAY_VERSION@|$(DISPLAY_VERSION)|g" \ > > -e "s|@JBOSS_HOME@|$(JBOSS_HOME)|g" \ > > + -e "s|@PEP8@|$(PEP8)|g" \ > > + -e "s|@PYFLAKES@|$(PYFLAKES)|g" \ > > $< > $@ > > > > # List of files that will be generated from templates: > > GENERATED = \ > > ovirt-engine.spec \ > > + build/python-check.sh \ > > packaging/bin/engine-prolog.sh \ > > packaging/bin/ovirt-engine-log-setup-event.sh \ > > packaging/bin/pki-common.sh \ > > @@ -184,11 +190,13 @@ > > > > all: \ > > generated-files \ > > + python-validation \ > > dbscripts-validations \ > > $(BUILD_FILE) \ > > $(NULL) > > > > generated-files: $(GENERATED) > > + chmod a+x build/python-check.sh > > chmod a+x packaging/services/ovirt-engine/ovirt-engine.sysv > > chmod a+x > > packaging/services/ovirt-engine-notifier/ovirt-engine-notifier.sysv > > chmod a+x > > packaging/services/ovirt-websocket-proxy/ovirt-websocket-proxy.sysv > > @@ -300,6 +308,11 @@ > > [ -x "$(SOURCEDIR)/$${f}" ] && MASK=0755 || MASK=0644; \ > > install -m "$${MASK}" "$(SOURCEDIR)/$${f}" "$$(dirname > > "$(TARGETDIR)/$${f}")"; \ > > done > > + > > +python-validation: > > + if [ "$(BUILD_PYTHON_VALIDATION)" != 0 ]; then \ > > + build/python-check.sh; \ > > + fi > > > > dbscripts-validations: > > test/dbscripts/check_for_duplicate_upgrade_scripts.sh > > @@ -417,6 +430,7 @@ > > $(MAKE) \ > > install \ > > BUILD_DEV=1 \ > > + BUILD_PYTHON_VALIDATION=0 \ > > PYTHON_DIR="$(PREFIX)$(PYTHON_SYS_DIR)" \ > > $(NULL) > > > > diff --git a/build/python-check.sh.in b/build/python-check.sh.in > > new file mode 100755 > > index 0000000..d13c820 > > --- /dev/null > > +++ b/build/python-check.sh.in > > @@ -0,0 +1,19 @@ > > +#!/bin/sh > > + > > +PEP8="@PEP8@" > > +PYFLAKES="@PYFLAKES@" > > +SRCDIR="$(dirname "$0")/.." > > + > > +cd "${SRCDIR}" > > + > > +ret=0 > > +FILES="$( > > + find build packaging -name '*.py' | while read f; do > > + [ -e "${f}.in" ] || echo "${f}" > > + done > > +)" > > + > > +"${PYFLAKES}" ${FILES} || ret=1 > > +"${PEP8}" ${FILES} || ret=1 > > + > > +exit ${ret} > > diff --git a/ovirt-engine.spec.in b/ovirt-engine.spec.in > > index af2a9c9..c06faf2 100644 > > --- a/ovirt-engine.spec.in > > +++ b/ovirt-engine.spec.in > > @@ -110,6 +110,7 @@ > > BUILD_GWT=%{ovirt_build_gwt} \\\ > > BUILD_LOCALES=%{ovirt_build_locales} \\\ > > BUILD_UT=%{ovirt_build_ut} \\\ > > + BUILD_PYTHON_VALIDATION=0 \\\ > > PACKAGE_NAME=%{name} \\\ > > RPM_VERSION=%{version} \\\ > > RPM_RELEASE=%{release} \\\ > > diff --git a/packaging/check.sh b/packaging/check.sh > > deleted file mode 100755 > > index ef6e0d6..0000000 > > --- a/packaging/check.sh > > +++ /dev/null > > @@ -1,15 +0,0 @@ > > -#!/bin/sh > > - > > -BASE="$(dirname "$0")" > > - > > -FILES="$( > > - find "${BASE}" -name '*.py' | while read f; do > > - [ -e "${f}.in" ] || echo "${f}" > > - done > > -)" > > - > > -ret=0 > > -pyflakes ${FILES} || ret=1 > > -pep8 ${FILES} || ret=1 > > - > > -exit "${ret}" > > > > > > -- > > To view, visit http://gerrit.ovirt.org/20827 > > To unsubscribe, visit http://gerrit.ovirt.org/settings > > > > Gerrit-MessageType: newchange > > Gerrit-Change-Id: Ie4ee9bf80b8a8a75464338bc047dd16e22f0e63b > > Gerrit-PatchSet: 1 > > Gerrit-Project: ovirt-engine > > Gerrit-Branch: master > > Gerrit-Owner: Alon Bar-Lev > > _______________________________________________ > > Engine-patches mailing list > > Engine-patches at ovirt.org > > http://lists.ovirt.org/mailman/listinfo/engine-patches > > > From vszocs at redhat.com Mon Nov 4 11:55:33 2013 From: vszocs at redhat.com (Vojtech Szocs) Date: Mon, 4 Nov 2013 06:55:33 -0500 (EST) Subject: [Engine-devel] Major frontend refactoring landed into master In-Reply-To: <1691738987.17588451.1383565760817.JavaMail.root@redhat.com> Message-ID: <12263819.17589393.1383566133094.JavaMail.root@redhat.com> Hey guys, I've just merged patch "frontend refactor phase 2" [http://gerrit.ovirt.org/#/c/17356/] into master branch. This is the second patch in a series dedicated to improving parts of frontend code responsible for communication with Engine backend: http://www.ovirt.org/Features/Design/FrontendRefactor If you find any issues related to GUI (WebAdmin, UserPortal) - just let Alex (CC'ed) or me know and we'll fix them. Regards, Vojtech From djasa at redhat.com Tue Nov 5 00:01:52 2013 From: djasa at redhat.com (David =?UTF-8?Q?Ja=C5=A1a?=) Date: Tue, 05 Nov 2013 01:01:52 +0100 Subject: [Engine-devel] Missing: Always up-to-date documentation of oVirt Message-ID: <1383609712.22352.79.camel@cihla.usersys.redhat.com> Hi, The oVirt project made a great progress in last two releases, who doesn't believe, check Itamar's talk from recent KVM Forum. :) There is a downside to that positive trend though: oVirt has become too large for one person to know all its feautures in detail (save for full-time managers of course). The only sources currently are feature pages that tend to get outdated fairly quickly after their respective feature initial implementation, and release notes. This means that user evaluating oVirt or user looking for particular feature has to cycle through release notes of several versions, go through prospective feature pages or try luck with hopefully suitable full text query. RHEV/RHS documentation is good but not perfect either because it may lack some feature available upstream and it also has some for latest features. oVirt should present itself better than now in this respect. Full-blown documentation such as the one for RHEV/RHS is out of question IMO as it requires steady effort of handful of people to keep it up-to date and covered. What IMO is feasible though is something like what libvirt does - keep page/pages such as [1] that enumerates features with a short description and note of version since when the feature was available. It is feasible because the required run-time effort on single person is quite low: when the feature is added or heavily modified, a description of similar size to DocText of RFE bug has to be added/updated in the documentation page. There is just one problem in getting there: agree if the problem really exists and devote resources to record current state of affairs. There is also one technical catch: if the documentation is to be consumable by downstreams, the "available since" notes have to be in common format that can be machine-converted downstream to matching d/s versions. I personally can't do much more than spin up a discussion and probably write about area I know, so I hope that this email can trigger actual actions by Someone Else leading to ultimate goal.... Cheers, David [1] http://libvirt.org/formatdomain.html -- David Ja?a, RHCE SPICE QE based in Brno GPG Key: 22C33E24 Fingerprint: 513A 060B D1B4 2A72 7F0D 0278 B125 CD00 22C3 3E24 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5727 bytes Desc: not available URL: From sbonazzo at redhat.com Tue Nov 5 09:39:29 2013 From: sbonazzo at redhat.com (Sandro Bonazzola) Date: Tue, 05 Nov 2013 10:39:29 +0100 Subject: [Engine-devel] daily oVirt 3.3.1 blocker status In-Reply-To: <20131104092600.GB27545@redhat.com> References: <52720B88.9080001@redhat.com> <5277553F.3010807@redhat.com> <20131104092600.GB27545@redhat.com> Message-ID: <5278BCD1.3030808@redhat.com> Il 04/11/2013 10:26, Dan Kenigsberg ha scritto: > On Mon, Nov 04, 2013 at 09:05:19AM +0100, Sandro Bonazzola wrote: >> Il 31/10/2013 08:49, Sandro Bonazzola ha scritto: >>> Hi, >>> The following blockers are still not fixed: >>> VDSM: >>> Bug 1022961 - Running a VM from a gluster domain uses mount instead of gluster URI >>> Bug 1022975 - [vdsm] storage domain upgrade fails with attributeError >>> >>> Federico, Eduardo, can you provide an ETA for those? >> >> Still not fixed with no ETA. > > WWIW, Bug 1022975 is solved by http://gerrit.ovirt.org/20721; waiting > only for a formal verification. patch merged and pushed to 3.3 branch http://gerrit.ovirt.org/#/c/20891/ the patch has been verified so it just need to be merged for closing Bug 1022975 - [vdsm] storage domain upgrade fails with attributeError I don't see any activity about Bug 1022961 - Running a VM from a gluster domain uses mount instead of gluster URI still no ETA for this? -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com From tjelinek at redhat.com Tue Nov 5 09:50:02 2013 From: tjelinek at redhat.com (Tomas Jelinek) Date: Tue, 5 Nov 2013 04:50:02 -0500 (EST) Subject: [Engine-devel] [UX] how to design a bar/line chart? In-Reply-To: <811559693.18401152.1383643528560.JavaMail.root@redhat.com> Message-ID: <157528892.18409921.1383645002815.JavaMail.root@redhat.com> 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 From iheim at redhat.com Tue Nov 5 13:56:38 2013 From: iheim at redhat.com (Itamar Heim) Date: Tue, 05 Nov 2013 15:56:38 +0200 Subject: [Engine-devel] gerrit 2.7 Message-ID: <5278F916.8080408@redhat.com> the only change i see interesting in gerrit 2.7 is: - New copyMaxScore setting for labels. Labels can be configured to copy approvals forward to the next patch set. but it's not clear on its scope, considering the mentioned changes in 2.8 release notes on same topic. I plan to upgrade gerrit to 2.7 in a couple of weeks, mainly to prepare for the 2.8 upgrade later on. gerrit 2.8 (not released yet) has these interesting changes: - Configurable external robots.txt file. (courtesy of juan hernandez) as well as: - Labels can be configured to copy scores forward to new patch sets if there is no code change. - Labels can be configured to copy scores forward to new patch sets for trivial rebases. - New button to cherry-pick the change to another branch. - When issuing a rebase via the Web UI, the committer is now the logged in user, rather than "Gerrit Code Review". - Copy reviewed flag to new patch sets for identical files. If a user has already seen and reviewed a file, the reviewed flag is forwarded on to the next patch set when the content of the file in the next patch set is identical to the reviewed file. other interesting changes in 2.8: - New change screen with completely redesigned UI and fully using the REST API. - Secondary indexing with Lucene and Solr. - Lots of new REST API endpoints. - New UI extension and JavaScript API for plugins. From iheim at redhat.com Tue Nov 5 14:45:26 2013 From: iheim at redhat.com (Itamar Heim) Date: Tue, 05 Nov 2013 16:45:26 +0200 Subject: [Engine-devel] Missing: Always up-to-date documentation of oVirt In-Reply-To: <1383609712.22352.79.camel@cihla.usersys.redhat.com> References: <1383609712.22352.79.camel@cihla.usersys.redhat.com> Message-ID: <52790486.3080401@redhat.com> On 11/05/2013 02:01 AM, David Ja?a wrote: > Hi, > > The oVirt project made a great progress in last two releases, who > doesn't believe, check Itamar's talk from recent KVM Forum. :) There is > a downside to that positive trend though: oVirt has become too large for > one person to know all its feautures in detail (save for full-time > managers of course). > > The only sources currently are feature pages that tend to get outdated > fairly quickly after their respective feature initial implementation, > and release notes. This means that user evaluating oVirt or user looking > for particular feature has to cycle through release notes of several > versions, go through prospective feature pages or try luck with > hopefully suitable full text query. > > RHEV/RHS documentation is good but not perfect either because it may > lack some feature available upstream and it also has some for latest > features. > > oVirt should present itself better than now in this respect. Full-blown > documentation such as the one for RHEV/RHS is out of question IMO as it > requires steady effort of handful of people to keep it up-to date and > covered. > > What IMO is feasible though is something like what libvirt does - keep > page/pages such as [1] that enumerates features with a short description > and note of version since when the feature was available. It is feasible > because the required run-time effort on single person is quite low: when > the feature is added or heavily modified, a description of similar size > to DocText of RFE bug has to be added/updated in the documentation page. > > There is just one problem in getting there: agree if the problem really > exists and devote resources to record current state of affairs. There is > also one technical catch: if the documentation is to be consumable by > downstreams, the "available since" notes have to be in common format > that can be machine-converted downstream to matching d/s versions. > > I personally can't do much more than spin up a discussion and probably > write about area I know, so I hope that this email can trigger actual > actions by Someone Else leading to ultimate goal.... > > Cheers, > > David > > [1] http://libvirt.org/formatdomain.html > > > > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > "if you build it, they will come" - create a wiki with place holders, and relevant folks will fill it up... probably worth to do by sections (storage, network, virt, sla, node, ux, infra, integration, gluster, ppc). and a sample of format per feature featur name [version number available from] feature text (or something like that). Thanks, Itamar From iheim at redhat.com Tue Nov 5 15:10:34 2013 From: iheim at redhat.com (Itamar Heim) Date: Tue, 05 Nov 2013 17:10:34 +0200 Subject: [Engine-devel] [UX] how to design a bar/line chart? In-Reply-To: <157528892.18409921.1383645002815.JavaMail.root@redhat.com> References: <157528892.18409921.1383645002815.JavaMail.root@redhat.com> Message-ID: <52790A6A.9000808@redhat.com> 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 at 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 From sbonazzo at redhat.com Wed Nov 6 07:28:32 2013 From: sbonazzo at redhat.com (Sandro Bonazzola) Date: Wed, 06 Nov 2013 08:28:32 +0100 Subject: [Engine-devel] daily oVirt 3.3.1 blocker status In-Reply-To: <5278BCD1.3030808@redhat.com> References: <52720B88.9080001@redhat.com> <5277553F.3010807@redhat.com> <20131104092600.GB27545@redhat.com> <5278BCD1.3030808@redhat.com> Message-ID: <5279EFA0.2030309@redhat.com> 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? -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com From fkobzik at redhat.com Wed Nov 6 09:33:28 2013 From: fkobzik at redhat.com (Frantisek Kobzik) Date: Wed, 6 Nov 2013 04:33:28 -0500 (EST) Subject: [Engine-devel] RFE: SPICE and VNC graphics at the same time In-Reply-To: <1020399021.17985600.1383724908178.JavaMail.root@redhat.com> Message-ID: <90408678.18122905.1383730408156.JavaMail.root@redhat.com> 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 From shtripat at redhat.com Wed Nov 6 10:07:34 2013 From: shtripat at redhat.com (Shubhendu Tripathi) Date: Wed, 06 Nov 2013 15:37:34 +0530 Subject: [Engine-devel] IMP: Regarding an issue while translating the error messages for gluster using ErrorTranslator class Message-ID: <527A14E6.8010809@redhat.com> 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From ewarszaw at redhat.com Wed Nov 6 07:36:08 2013 From: ewarszaw at redhat.com (Eduardo Warszawski) Date: Wed, 6 Nov 2013 02:36:08 -0500 (EST) Subject: [Engine-devel] daily oVirt 3.3.1 blocker status In-Reply-To: <5279EFA0.2030309@redhat.com> References: <52720B88.9080001@redhat.com> <5277553F.3010807@redhat.com> <20131104092600.GB27545@redhat.com> <5278BCD1.3030808@redhat.com> <5279EFA0.2030309@redhat.com> Message-ID: <932728766.19142551.1383723368752.JavaMail.root@redhat.com> ----- 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 > From michal.skrivanek at redhat.com Wed Nov 6 12:19:46 2013 From: michal.skrivanek at redhat.com (Michal Skrivanek) Date: Wed, 6 Nov 2013 13:19:46 +0100 Subject: [Engine-devel] RFE: SPICE and VNC graphics at the same time In-Reply-To: <90408678.18122905.1383730408156.JavaMail.root@redhat.com> References: <90408678.18122905.1383730408156.JavaMail.root@redhat.com> Message-ID: 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 at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel From ofrenkel at redhat.com Wed Nov 6 12:20:42 2013 From: ofrenkel at redhat.com (Omer Frenkel) Date: Wed, 6 Nov 2013 07:20:42 -0500 (EST) Subject: [Engine-devel] RFE: SPICE and VNC graphics at the same time In-Reply-To: <90408678.18122905.1383730408156.JavaMail.root@redhat.com> References: <90408678.18122905.1383730408156.JavaMail.root@redhat.com> Message-ID: <2129144810.20736298.1383740442469.JavaMail.root@redhat.com> ----- 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 at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > From fkobzik at redhat.com Wed Nov 6 12:25:30 2013 From: fkobzik at redhat.com (Frantisek Kobzik) Date: Wed, 6 Nov 2013 07:25:30 -0500 (EST) Subject: [Engine-devel] RFE: SPICE and VNC graphics at the same time In-Reply-To: <2129144810.20736298.1383740442469.JavaMail.root@redhat.com> References: <90408678.18122905.1383730408156.JavaMail.root@redhat.com> <2129144810.20736298.1383740442469.JavaMail.root@redhat.com> Message-ID: <240750548.18325239.1383740730603.JavaMail.root@redhat.com> 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 at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > From awels at redhat.com Wed Nov 6 13:28:13 2013 From: awels at redhat.com (Alexander Wels) Date: Wed, 06 Nov 2013 08:28:13 -0500 Subject: [Engine-devel] IMP: Regarding an issue while translating the error messages for gluster using ErrorTranslator class In-Reply-To: <527A14E6.8010809@redhat.com> References: <527A14E6.8010809@redhat.com> Message-ID: <2115335.RGeYIF2D09@awels> 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 From ecohen at redhat.com Wed Nov 6 14:10:09 2013 From: ecohen at redhat.com (Einav Cohen) Date: Wed, 6 Nov 2013 09:10:09 -0500 (EST) Subject: [Engine-devel] IMP: Regarding an issue while translating the error messages for gluster using ErrorTranslator class In-Reply-To: <2115335.RGeYIF2D09@awels> References: <527A14E6.8010809@redhat.com> <2115335.RGeYIF2D09@awels> Message-ID: <1082228530.20856483.1383747009016.JavaMail.root@redhat.com> > ----- 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 at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > From ecohen at redhat.com Wed Nov 6 14:11:53 2013 From: ecohen at redhat.com (Einav Cohen) Date: Wed, 6 Nov 2013 09:11:53 -0500 (EST) Subject: [Engine-devel] IMP: Regarding an issue while translating the error messages for gluster using ErrorTranslator class In-Reply-To: <1082228530.20856483.1383747009016.JavaMail.root@redhat.com> References: <527A14E6.8010809@redhat.com> <2115335.RGeYIF2D09@awels> <1082228530.20856483.1383747009016.JavaMail.root@redhat.com> Message-ID: <1395352625.20859205.1383747113095.JavaMail.root@redhat.com> > 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 at ovirt.org > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > From derez at redhat.com Wed Nov 6 14:13:30 2013 From: derez at redhat.com (Daniel Erez) Date: Wed, 6 Nov 2013 09:13:30 -0500 (EST) Subject: [Engine-devel] IMP: Regarding an issue while translating the error messages for gluster using ErrorTranslator class In-Reply-To: <527A14E6.8010809@redhat.com> References: <527A14E6.8010809@redhat.com> Message-ID: <1626430710.26900628.1383747210835.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Shubhendu Tripathi" > To: derez at 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 > From ecohen at redhat.com Wed Nov 6 14:26:15 2013 From: ecohen at redhat.com (Einav Cohen) Date: Wed, 6 Nov 2013 09:26:15 -0500 (EST) Subject: [Engine-devel] [UX] how to design a bar/line chart? In-Reply-To: <52790A6A.9000808@redhat.com> References: <157528892.18409921.1383645002815.JavaMail.root@redhat.com> <52790A6A.9000808@redhat.com> Message-ID: <1596552383.20866728.1383747975841.JavaMail.root@redhat.com> 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 at 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 at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > From shtripat at redhat.com Wed Nov 6 14:31:52 2013 From: shtripat at redhat.com (Shubhendu Tripathi) Date: Wed, 06 Nov 2013 20:01:52 +0530 Subject: [Engine-devel] IMP: Regarding an issue while translating the error messages for gluster using ErrorTranslator class In-Reply-To: <1626430710.26900628.1383747210835.JavaMail.root@redhat.com> References: <527A14E6.8010809@redhat.com> <1626430710.26900628.1383747210835.JavaMail.root@redhat.com> Message-ID: <527A52D8.9040700@redhat.com> On 11/06/2013 07:43 PM, Daniel Erez wrote: > > ----- Original Message ----- >> From: "Shubhendu Tripathi" >> To: derez at 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 >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From shtripat at redhat.com Wed Nov 6 14:33:53 2013 From: shtripat at redhat.com (Shubhendu Tripathi) Date: Wed, 06 Nov 2013 20:03:53 +0530 Subject: [Engine-devel] IMP: Regarding an issue while translating the error messages for gluster using ErrorTranslator class In-Reply-To: <1395352625.20859205.1383747113095.JavaMail.root@redhat.com> References: <527A14E6.8010809@redhat.com> <2115335.RGeYIF2D09@awels> <1082228530.20856483.1383747009016.JavaMail.root@redhat.com> <1395352625.20859205.1383747113095.JavaMail.root@redhat.com> Message-ID: <527A5351.7060203@redhat.com> 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 at ovirt.org >>> http://lists.ovirt.org/mailman/listinfo/engine-devel >>> >> _______________________________________________ >> Engine-devel mailing list >> Engine-devel at ovirt.org >> http://lists.ovirt.org/mailman/listinfo/engine-devel >> > From tjelinek at redhat.com Wed Nov 6 14:58:03 2013 From: tjelinek at redhat.com (Tomas Jelinek) Date: Wed, 6 Nov 2013 09:58:03 -0500 (EST) Subject: [Engine-devel] [UX] how to design a bar/line chart? In-Reply-To: <1596552383.20866728.1383747975841.JavaMail.root@redhat.com> References: <157528892.18409921.1383645002815.JavaMail.root@redhat.com> <52790A6A.9000808@redhat.com> <1596552383.20866728.1383747975841.JavaMail.root@redhat.com> Message-ID: <424101873.19454345.1383749883282.JavaMail.root@redhat.com> 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 at 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 at ovirt.org > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > > > > > From mrao at redhat.com Wed Nov 6 15:24:56 2013 From: mrao at redhat.com (Malini Rao) Date: Wed, 6 Nov 2013 10:24:56 -0500 (EST) Subject: [Engine-devel] [UX] how to design a bar/line chart? In-Reply-To: <424101873.19454345.1383749883282.JavaMail.root@redhat.com> References: <157528892.18409921.1383645002815.JavaMail.root@redhat.com> <52790A6A.9000808@redhat.com> <1596552383.20866728.1383747975841.JavaMail.root@redhat.com> <424101873.19454345.1383749883282.JavaMail.root@redhat.com> Message-ID: <1306019229.17661019.1383751496579.JavaMail.root@redhat.com> 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? 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 at 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 at ovirt.org > > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > > > > > > > > > > From awels at redhat.com Wed Nov 6 15:46:01 2013 From: awels at redhat.com (Alexander Wels) Date: Wed, 06 Nov 2013 10:46:01 -0500 Subject: [Engine-devel] [UX] how to design a bar/line chart? In-Reply-To: <1306019229.17661019.1383751496579.JavaMail.root@redhat.com> References: <157528892.18409921.1383645002815.JavaMail.root@redhat.com> <424101873.19454345.1383749883282.JavaMail.root@redhat.com> <1306019229.17661019.1383751496579.JavaMail.root@redhat.com> Message-ID: <10671894.E7RLZxpxmS@awels> 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 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 at 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 at ovirt.org > > > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel From derez at redhat.com Wed Nov 6 15:59:22 2013 From: derez at redhat.com (Daniel Erez) Date: Wed, 6 Nov 2013 10:59:22 -0500 (EST) Subject: [Engine-devel] IMP: Regarding an issue while translating the error messages for gluster using ErrorTranslator class In-Reply-To: <527A52D8.9040700@redhat.com> References: <527A14E6.8010809@redhat.com> <1626430710.26900628.1383747210835.JavaMail.root@redhat.com> <527A52D8.9040700@redhat.com> Message-ID: <1514562916.26958300.1383753561998.JavaMail.root@redhat.com> ----- 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: derez at 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 > >> > > From mrao at redhat.com Wed Nov 6 16:03:06 2013 From: mrao at redhat.com (Malini Rao) Date: Wed, 6 Nov 2013 11:03:06 -0500 (EST) Subject: [Engine-devel] [UX] how to design a bar/line chart? In-Reply-To: <10671894.E7RLZxpxmS@awels> References: <157528892.18409921.1383645002815.JavaMail.root@redhat.com> <424101873.19454345.1383749883282.JavaMail.root@redhat.com> <1306019229.17661019.1383751496579.JavaMail.root@redhat.com> <10671894.E7RLZxpxmS@awels> Message-ID: <845594321.17693417.1383753786397.JavaMail.root@redhat.com> Is this a possibility? Looks nicer. http://style.org/chartapi/sparklines/ ----- Original Message ----- From: "Alexander Wels" To: engine-devel at 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" > > > > > > > > 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 at 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 at ovirt.org > > > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel From sbonazzo at redhat.com Wed Nov 6 16:11:10 2013 From: sbonazzo at redhat.com (Sandro Bonazzola) Date: Wed, 06 Nov 2013 17:11:10 +0100 Subject: [Engine-devel] [QE] 3.3.2 Release tracker Message-ID: <527A6A1E.7060606@redhat.com> 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 virt 1007940 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 From gshereme at redhat.com Wed Nov 6 16:27:57 2013 From: gshereme at redhat.com (Greg Sheremeta) Date: Wed, 6 Nov 2013 11:27:57 -0500 (EST) Subject: [Engine-devel] GWT DevMode plugin stopped working in Firefox 24+ In-Reply-To: <1927309046.13117454.1383755256504.JavaMail.root@redhat.com> Message-ID: <1167246611.13117565.1383755277542.JavaMail.root@redhat.com> 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 gshereme at redhat.com From derez at redhat.com Wed Nov 6 16:43:07 2013 From: derez at redhat.com (Daniel Erez) Date: Wed, 6 Nov 2013 11:43:07 -0500 (EST) Subject: [Engine-devel] GWT DevMode plugin stopped working in Firefox 24+ In-Reply-To: <1167246611.13117565.1383755277542.JavaMail.root@redhat.com> References: <1167246611.13117565.1383755277542.JavaMail.root@redhat.com> Message-ID: <1741128331.26985922.1383756187264.JavaMail.root@redhat.com> ----- 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 > gshereme at redhat.com > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > From awels at redhat.com Wed Nov 6 16:45:36 2013 From: awels at redhat.com (Alexander Wels) Date: Wed, 06 Nov 2013 11:45:36 -0500 Subject: [Engine-devel] [UX] how to design a bar/line chart? In-Reply-To: <845594321.17693417.1383753786397.JavaMail.root@redhat.com> References: <157528892.18409921.1383645002815.JavaMail.root@redhat.com> <10671894.E7RLZxpxmS@awels> <845594321.17693417.1383753786397.JavaMail.root@redhat.com> Message-ID: <4799215.PFXHvLDZXl@awels> 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 at 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 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? 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 at 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 at ovirt.org > > > > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > > _______________________________________________ > > Engine-devel mailing list > > Engine-devel at ovirt.org > > http://lists.ovirt.org/mailman/listinfo/engine-devel From justin at dynam.ac Wed Nov 6 17:19:40 2013 From: justin at dynam.ac (=?utf-8?Q?Justin_Hammond?=) Date: Wed, 6 Nov 2013 17:19:40 +0000 Subject: [Engine-devel] [UX] how to design a bar/line chart? Message-ID: 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 at 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 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? 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 at 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 at ovirt.org >>>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel >>> >>> _______________________________________________ >>> Engine-devel mailing list >>> Engine-devel at ovirt.org >>> http://lists.ovirt.org/mailman/listinfo/engine-devel > > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel From iheim at redhat.com Wed Nov 6 21:01:33 2013 From: iheim at redhat.com (Itamar Heim) Date: Wed, 06 Nov 2013 23:01:33 +0200 Subject: [Engine-devel] [UX] how to design a bar/line chart? In-Reply-To: References: Message-ID: <527AAE2D.4020707@redhat.com> 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 From jtd at galois.com Wed Nov 6 23:34:01 2013 From: jtd at galois.com (Jonathan Daugherty) Date: Wed, 6 Nov 2013 15:34:01 -0800 Subject: [Engine-devel] Permissions involved in using REST API Message-ID: <20131106233401.GG73898@galois.com> 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. From ecohen at redhat.com Thu Nov 7 01:07:08 2013 From: ecohen at redhat.com (Einav Cohen) Date: Wed, 6 Nov 2013 20:07:08 -0500 (EST) Subject: [Engine-devel] [UX] how to design a bar/line chart? In-Reply-To: <1306019229.17661019.1383751496579.JavaMail.root@redhat.com> References: <157528892.18409921.1383645002815.JavaMail.root@redhat.com> <52790A6A.9000808@redhat.com> <1596552383.20866728.1383747975841.JavaMail.root@redhat.com> <424101873.19454345.1383749883282.JavaMail.root@redhat.com> <1306019229.17661019.1383751496579.JavaMail.root@redhat.com> Message-ID: <402162040.21801612.1383786428588.JavaMail.root@redhat.com> 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 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? 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 at 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 at ovirt.org > > > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > > > > > > > > > > > > > > > > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > From shtripat at redhat.com Thu Nov 7 06:31:57 2013 From: shtripat at redhat.com (Shubhendu Tripathi) Date: Thu, 07 Nov 2013 12:01:57 +0530 Subject: [Engine-devel] IMP: Regarding an issue while translating the error messages for gluster using ErrorTranslator class In-Reply-To: <1514562916.26958300.1383753561998.JavaMail.root@redhat.com> References: <527A14E6.8010809@redhat.com> <1626430710.26900628.1383747210835.JavaMail.root@redhat.com> <527A52D8.9040700@redhat.com> <1514562916.26958300.1383753561998.JavaMail.root@redhat.com> Message-ID: <527B33DD.1000405@redhat.com> 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: derez at 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 >>>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From lvernia at redhat.com Thu Nov 7 06:51:22 2013 From: lvernia at redhat.com (Lior Vernia) Date: Thu, 07 Nov 2013 08:51:22 +0200 Subject: [Engine-devel] [UX] how to design a bar/line chart? In-Reply-To: <1596552383.20866728.1383747975841.JavaMail.root@redhat.com> References: <157528892.18409921.1383645002815.JavaMail.root@redhat.com> <52790A6A.9000808@redhat.com> <1596552383.20866728.1383747975841.JavaMail.root@redhat.com> Message-ID: <527B386A.1050805@redhat.com> 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 at 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 at ovirt.org >> http://lists.ovirt.org/mailman/listinfo/engine-devel >> >> >> > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > From lvernia at redhat.com Thu Nov 7 07:03:25 2013 From: lvernia at redhat.com (Lior Vernia) Date: Thu, 07 Nov 2013 09:03:25 +0200 Subject: [Engine-devel] [UX] how to design a bar/line chart? In-Reply-To: <527B386A.1050805@redhat.com> References: <157528892.18409921.1383645002815.JavaMail.root@redhat.com> <52790A6A.9000808@redhat.com> <1596552383.20866728.1383747975841.JavaMail.root@redhat.com> <527B386A.1050805@redhat.com> Message-ID: <527B3B3D.5090707@redhat.com> 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 at 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 at ovirt.org >>> http://lists.ovirt.org/mailman/listinfo/engine-devel >>> >>> >>> >> _______________________________________________ >> Engine-devel mailing list >> Engine-devel at ovirt.org >> http://lists.ovirt.org/mailman/listinfo/engine-devel >> > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > From tjelinek at redhat.com Thu Nov 7 07:26:25 2013 From: tjelinek at redhat.com (Tomas Jelinek) Date: Thu, 7 Nov 2013 02:26:25 -0500 (EST) Subject: [Engine-devel] [UX] how to design a bar/line chart? In-Reply-To: <527B3B3D.5090707@redhat.com> References: <157528892.18409921.1383645002815.JavaMail.root@redhat.com> <52790A6A.9000808@redhat.com> <1596552383.20866728.1383747975841.JavaMail.root@redhat.com> <527B386A.1050805@redhat.com> <527B3B3D.5090707@redhat.com> Message-ID: <1287617536.19813483.1383809185017.JavaMail.root@redhat.com> ----- 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 > >>>> _______________________________________________ > >>>> Engine-devel mailing list > >>>> Engine-devel at 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 at ovirt.org > >>> http://lists.ovirt.org/mailman/listinfo/engine-devel > >>> > >>> > >>> > >> _______________________________________________ > >> Engine-devel mailing list > >> Engine-devel at ovirt.org > >> http://lists.ovirt.org/mailman/listinfo/engine-devel > >> > > _______________________________________________ > > Engine-devel mailing list > > Engine-devel at ovirt.org > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > From lvernia at redhat.com Thu Nov 7 07:35:55 2013 From: lvernia at redhat.com (Lior Vernia) Date: Thu, 07 Nov 2013 09:35:55 +0200 Subject: [Engine-devel] [UX] how to design a bar/line chart? In-Reply-To: <1287617536.19813483.1383809185017.JavaMail.root@redhat.com> References: <157528892.18409921.1383645002815.JavaMail.root@redhat.com> <52790A6A.9000808@redhat.com> <1596552383.20866728.1383747975841.JavaMail.root@redhat.com> <527B386A.1050805@redhat.com> <527B3B3D.5090707@redhat.com> <1287617536.19813483.1383809185017.JavaMail.root@redhat.com> Message-ID: <527B42DB.5080403@redhat.com> 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 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 at 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 at ovirt.org >>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel >>>>> >>>>> >>>>> >>>> _______________________________________________ >>>> Engine-devel mailing list >>>> Engine-devel at ovirt.org >>>> http://lists.ovirt.org/mailman/listinfo/engine-devel >>>> >>> _______________________________________________ >>> Engine-devel mailing list >>> Engine-devel at ovirt.org >>> http://lists.ovirt.org/mailman/listinfo/engine-devel >>> >> _______________________________________________ >> Engine-devel mailing list >> Engine-devel at ovirt.org >> http://lists.ovirt.org/mailman/listinfo/engine-devel >> From ovedo at redhat.com Thu Nov 7 08:26:42 2013 From: ovedo at redhat.com (Oved Ourfalli) Date: Thu, 7 Nov 2013 03:26:42 -0500 (EST) Subject: [Engine-devel] Permissions involved in using REST API In-Reply-To: <20131106233401.GG73898@galois.com> References: <20131106233401.GG73898@galois.com> Message-ID: <307109400.18301343.1383812802255.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Jonathan Daugherty" > To: engine-devel at ovirt.org > Cc: "Trevor Elliott" > Sent: Thursday, November 7, 2013 1:34:01 AM > Subject: [Engine-devel] Permissions involved in using REST API > > 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? > Yes. That's the expected behavior. However, when accessing the API you can set the "filter" header parameter to "true", and that will get you to the user-level API. Let me know if you need technical assistance with that. > - 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. > Unfortunately I didn't find any documentation on that on the ovirt wiki. Michael - do you know if such documentation exists somewhere? > 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 at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > From mrao at redhat.com Thu Nov 7 15:40:35 2013 From: mrao at redhat.com (Malini Rao) Date: Thu, 7 Nov 2013 10:40:35 -0500 (EST) Subject: [Engine-devel] [UX] how to design a bar/line chart? In-Reply-To: <527B42DB.5080403@redhat.com> References: <157528892.18409921.1383645002815.JavaMail.root@redhat.com> <52790A6A.9000808@redhat.com> <1596552383.20866728.1383747975841.JavaMail.root@redhat.com> <527B386A.1050805@redhat.com> <527B3B3D.5090707@redhat.com> <1287617536.19813483.1383809185017.JavaMail.root@redhat.com> <527B42DB.5080403@redhat.com> Message-ID: <1256716135.18537721.1383838835580.JavaMail.root@redhat.com> While the technical discussion carries on, I want to go back to the user requirement here one more time - What is of most value to the user - the current value accurate to the second level in time ( in which case why do we want line chart/ sparklines etc) or a trend of how this entity is doing in the last x hours including a 'sense' of where it is at this time? If a second to second difference is important to be obvious, then sparklines or any other small charting method is possibly not the best way to go. We may need to design an entire monitoring view with more detailed graphs for various measures etc. My impression with this requirement was that it is valuable for the user to get a sense of the trend for the measure on the entity just by looking at the shape of the line and the end point gives you an 'idea' of where the entity is at so that you can decide if any investigation is needed or base your decisions on it. I have a hard time wrapping my head around the possibility that decisions will be influenced by data delays of a few secs. In my mind, this is not like a stock ticker... is it? ----- Original Message ----- From: "Lior Vernia" To: "Tomas Jelinek" Cc: "Eldan Hildesheim" , "engine-devel" , "info" Sent: Thursday, November 7, 2013 2:35:55 AM Subject: Re: [Engine-devel] [UX] how to design a bar/line chart? 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 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 at 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 at ovirt.org >>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel >>>>> >>>>> >>>>> >>>> _______________________________________________ >>>> Engine-devel mailing list >>>> Engine-devel at ovirt.org >>>> http://lists.ovirt.org/mailman/listinfo/engine-devel >>>> >>> _______________________________________________ >>> Engine-devel mailing list >>> Engine-devel at ovirt.org >>> http://lists.ovirt.org/mailman/listinfo/engine-devel >>> >> _______________________________________________ >> Engine-devel mailing list >> Engine-devel at ovirt.org >> http://lists.ovirt.org/mailman/listinfo/engine-devel >> _______________________________________________ Engine-devel mailing list Engine-devel at ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel From ewoud+ovirt at kohlvanwijngaarden.nl Thu Nov 7 16:44:07 2013 From: ewoud+ovirt at kohlvanwijngaarden.nl (Ewoud Kohl van Wijngaarden) Date: Thu, 7 Nov 2013 17:44:07 +0100 Subject: [Engine-devel] [UX] how to design a bar/line chart? In-Reply-To: <4799215.PFXHvLDZXl@awels> References: <157528892.18409921.1383645002815.JavaMail.root@redhat.com> <10671894.E7RLZxpxmS@awels> <845594321.17693417.1383753786397.JavaMail.root@redhat.com> <4799215.PFXHvLDZXl@awels> Message-ID: <20131107164407.GB31469@bogey.xentower.nl> On Wed, Nov 06, 2013 at 11:45:36AM -0500, 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. I'd say no. Even from a reliability point of view since users may have systems that aren't connected to the internet. (Though I don't know how well oVirt handles this currently.) From bob at doolittle.us.com Thu Nov 7 17:08:05 2013 From: bob at doolittle.us.com (Bob Doolittle) Date: Thu, 07 Nov 2013 12:08:05 -0500 Subject: [Engine-devel] Browsing source repository Message-ID: <527BC8F5.3020801@doolittle.us.com> Hi folks, Do we have gitweb installed for the ovirt-engine repo, or is there any other way of browsing the source repository without cloning the entire thing? Is there a description of the various branches in the ovirt-engine repository? If I wanted to build the 3.3 source is the ovirt-engine-3.3 branch sufficient? I'm afraid I am new to git and also to general source/build conventions in place for Linux community projects, so sorry if my questions are naive (I come from a long Unix development background but no FOSS projects so far). I'm familiar with sccs, cvs, svn, and a little hg, but not git (yet). Thanks, Bob P.S. I'll be studying the User Portal primarily From ewoud+ovirt at kohlvanwijngaarden.nl Thu Nov 7 17:14:09 2013 From: ewoud+ovirt at kohlvanwijngaarden.nl (Ewoud Kohl van Wijngaarden) Date: Thu, 7 Nov 2013 18:14:09 +0100 Subject: [Engine-devel] Browsing source repository In-Reply-To: <527BC8F5.3020801@doolittle.us.com> References: <527BC8F5.3020801@doolittle.us.com> Message-ID: <20131107171409.GC31469@bogey.xentower.nl> On Thu, Nov 07, 2013 at 12:08:05PM -0500, Bob Doolittle wrote: > Do we have gitweb installed for the ovirt-engine repo, or is there > any other way of browsing the source repository without cloning the > entire thing? Yes, if you go to http://gerrit.ovirt.org/#/admin/projects/ you'll see gitweb URLs. I'll admit it's not that fast, but we do mirror a few on github: https://github.com/ovirt. Note that we treat github as a mirror, not a place to do pull requests. From jtd at galois.com Thu Nov 7 17:20:27 2013 From: jtd at galois.com (Jonathan Daugherty) Date: Thu, 7 Nov 2013 09:20:27 -0800 Subject: [Engine-devel] Permissions involved in using REST API In-Reply-To: <307109400.18301343.1383812802255.JavaMail.root@redhat.com> References: <20131106233401.GG73898@galois.com> <307109400.18301343.1383812802255.JavaMail.root@redhat.com> Message-ID: <20131107172027.GA58872@galois.com> > > - Is this expected behavior? Is there some smaller (less > > permissive) change in privileges I can use to bring about the same > > behavior? > > > > Yes. That's the expected behavior. However, when accessing the API you > can set the "filter" header parameter to "true", and that will get you > to the user-level API. Let me know if you need technical assistance > with that. Thanks! The Filter header works for me. While it's good to have some means of controlling which users can access the API, I think that the current means is very misleading and alarming. It's misleading because it presumes I think admin users are the only ones who should access the API (I don't) and it is alarming because if I have to set the admin bit on users to let them do this, I'm not sure whether I'm inadvertently granting them rights to do other things (I don't want to). In any case it certainly isn't how I would imagine some people think about this sort of use case; for example, if I want my Jenkins CI system to be able to talk to oVirt via the API, I don't think of that as administrative access. I would love to see a new permission checkbox added, e.g., "REST API access", which I could check or uncheck on a per-user or per-group basis. Unfortunately I can't volunteer to do this work myself and even if I could it isn't yet clear whether such a new feature somehow conflicts with other design decisions the engine developers have made. So now my next question is: if I create an admin account without any privileges as I have described, are there any hidden privileges other than API access which I need to know that user has? Thanks! -- Jonathan Daugherty Software Engineer Galois, Inc. From iheim at redhat.com Thu Nov 7 18:37:21 2013 From: iheim at redhat.com (Itamar Heim) Date: Thu, 07 Nov 2013 20:37:21 +0200 Subject: [Engine-devel] Browsing source repository In-Reply-To: <20131107171409.GC31469@bogey.xentower.nl> References: <527BC8F5.3020801@doolittle.us.com> <20131107171409.GC31469@bogey.xentower.nl> Message-ID: <527BDDE1.1060502@redhat.com> On 11/07/2013 07:14 PM, Ewoud Kohl van Wijngaarden wrote: > On Thu, Nov 07, 2013 at 12:08:05PM -0500, Bob Doolittle wrote: >> Do we have gitweb installed for the ovirt-engine repo, or is there >> any other way of browsing the source repository without cloning the >> entire thing? > > Yes, if you go to http://gerrit.ovirt.org/#/admin/projects/ you'll see > gitweb URLs. I'll admit it's not that fast, but we do mirror a few on > github: https://github.com/ovirt. Note that we treat github as a mirror, > not a place to do pull requests. > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > wrt to branches, branch are "work place" still moving. so ovirt-engine-3.3 is currently for patches going into 3.3.2. ovirt-engine-3.3.1 is to stabilize 3.3.1 which is in beta/rc phase. a released version is tagged (and usually the branch to create it is deleted. From awels at redhat.com Thu Nov 7 21:18:35 2013 From: awels at redhat.com (Alexander Wels) Date: Thu, 07 Nov 2013 16:18:35 -0500 Subject: [Engine-devel] [UX] how to design a bar/line chart? In-Reply-To: <20131107164407.GB31469@bogey.xentower.nl> References: <157528892.18409921.1383645002815.JavaMail.root@redhat.com> <4799215.PFXHvLDZXl@awels> <20131107164407.GB31469@bogey.xentower.nl> Message-ID: <2606018.IDFKTiKoX7@awels> On Thursday, November 07, 2013 05:44:07 PM Ewoud Kohl van Wijngaarden wrote: > On Wed, Nov 06, 2013 at 11:45:36AM -0500, 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. > I'd say no. Even from a reliability point of view since users may have > systems that aren't connected to the internet. (Though I don't know how > well oVirt handles this currently.) That would eliminate the entire Google charting api as that requires an active connection to at least retrieve some stuff from www.google.com/jsapi. From vszocs at redhat.com Thu Nov 7 22:21:21 2013 From: vszocs at redhat.com (Vojtech Szocs) Date: Thu, 7 Nov 2013 17:21:21 -0500 (EST) Subject: [Engine-devel] oVirt UI plugins feature announcements In-Reply-To: <178536552.20185214.1383857236550.JavaMail.root@redhat.com> Message-ID: <827052122.20224553.1383862881105.JavaMail.root@redhat.com> Hello everyone, I'd like to share some important updates on oVirt UI plugins feature. First of all, UI plugins wiki [1] is finally complete. API reference (application events, API functions, API options, entity types) now includes all the details and snippets of example code. I've also added section "Why load plugins via iframe element?" explaining reasons behind this design decision. [1] http://www.ovirt.org/Features/UIPlugins You might have noticed the changes in oVirt Engine URI layout [2], these are already reflected in UI plugins wiki. For existing plugins, this means changing URLs like this: /webadmin/webadmin/plugin/ExamplePlugin/start.html to this: /ovirt-engine/webadmin/plugin/ExamplePlugin/start.html [2] http://gerrit.ovirt.org/#/c/20473/ We're planning to merge patch "Improve UI Plugin vs. REST API integration" [http://gerrit.ovirt.org/#/c/20404/] soon, please review the change outlined in commit message, let me know if you have any questions. Last but not least, oVirt Space Shooter (a.k.a UI plugins crash course) wiki [3] has been updated to reflect changes mentioned above. [3] http://www.ovirt.org/Tutorial/UIPlugins/CrashCourse Regards, Vojtech From danken at redhat.com Fri Nov 8 00:28:45 2013 From: danken at redhat.com (Dan Kenigsberg) Date: Fri, 8 Nov 2013 00:28:45 +0000 Subject: [Engine-devel] [vdsm] daily oVirt 3.3.1 blocker status In-Reply-To: <932728766.19142551.1383723368752.JavaMail.root@redhat.com> References: <52720B88.9080001@redhat.com> <5277553F.3010807@redhat.com> <20131104092600.GB27545@redhat.com> <5278BCD1.3030808@redhat.com> <5279EFA0.2030309@redhat.com> <932728766.19142551.1383723368752.JavaMail.root@redhat.com> Message-ID: <20131108002845.GP16597@redhat.com> On Wed, Nov 06, 2013 at 02:36:08AM -0500, Eduardo Warszawski wrote: > > 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! :) It's not the /real thing/ that Eduardo wanted, but it's something and it's working. Please review and verify http://gerrit.ovirt.org/#/c/21059/ gluster prepareImage: return gluster-sepecific information From shtripat at redhat.com Fri Nov 8 06:37:30 2013 From: shtripat at redhat.com (Shubhendu Tripathi) Date: Fri, 08 Nov 2013 12:07:30 +0530 Subject: [Engine-devel] REST-API: Problem with additional DELETE action at collection level In-Reply-To: <527C7DDF.2050308@redhat.com> References: <527C7DDF.2050308@redhat.com> Message-ID: <527C86AA.7010904@redhat.com> Hi All, There is a DELETE action defined at collection level for Gluster Bricks with signature - /@DELETE public////Response//remove//(//GlusterBricks//bricks//);/ Recently we had needed a commit action to remove migrated bricks. After multiple rounds of discussion on introducing a commit action to remove migrated bricks we introduced a DELETE action [1] which accepts a boolean parameter isForce. If the parameter is set to /true/, forced deletion of bricks happens without any data migration. And if the parameter is not set or set to /false,/ the deletion is meant for a brick on which migration has already taken place. To achieve the above functionality we introduced another DELETE action with new signature as below and also marked the first action as deprecated - /@DELETE public////Response//remove//(//Action//action//);/ The problem arises now as the new api works fine for all possible scenarios with below input structure - / //// // true/false// // // // // // //brick1-name// // brick2-name// // // // // /// BUT after these change backward compatibility is broken and the old api does not work. If we try invoking old DELETE with bricks as input parameter as below, it still invokes the new api and gives an error saying "Invalid parameter". / // // / Kindly suggest a solution around the same. *PS:* Both the actions are defined at collection level (//api/clusters//glustervolumes//bricks/) [1]: http://gerrit.ovirt.org/#/c/21043/ Thanks and Regards, Shubhendu -------------- next part -------------- An HTML attachment was scrubbed... URL: From shtripat at redhat.com Fri Nov 8 05:59:59 2013 From: shtripat at redhat.com (Shubhendu Tripathi) Date: Fri, 08 Nov 2013 11:29:59 +0530 Subject: [Engine-devel] REST-API: Problem with additional DELETE action at collection level Message-ID: <527C7DDF.2050308@redhat.com> Hi All, There is a DELETE action defined at collection level for Gluster Bricks with signature - /@DELETE public////Response//remove//(//GlusterBricks//bricks//);/ Recently we had needed a commit action to remove migrated bricks. After multiple rounds of discussion on introducing a commit action to remove migrated bricks we introduced a DELETE action [1] which accepts a boolean parameter isForce. If the parameter is set to /true/, forced deletion of bricks happens without any data migration. And if the parameter is not set or set to /false,/ the deletion is meant for a brick on which migration has already taken place. To achieve the above functionality we introduced another DELETE action with new signature as below and also marked the first action as deprecated - /@DELETE public////Response//remove//(//Action//action//);/ The problem arises now as the new api works fine for all possible scenarios with below input structure - / //// // true/false// // // // // // //brick1-name// // brick2-name// // // // // /// BUT after these change backward compatibility is broken and the old api does not work. If we try invoking old DELETE with bricks as input parameter as below, it still invokes the new api and gives an error saying "Invalid parameter". / // // / Kindly suggest a solution around the same. *PS:* Both the actions are defined at collection level (//api/clusters//glustervolumes//bricks/) [1]: http://gerrit.ovirt.org/#/c/21043/ Thanks and Regards, Shubhendu -------------- next part -------------- An HTML attachment was scrubbed... URL: From emesika at redhat.com Fri Nov 8 07:25:25 2013 From: emesika at redhat.com (Eli Mesika) Date: Fri, 8 Nov 2013 02:25:25 -0500 (EST) Subject: [Engine-devel] oVirt UI plugins feature announcements In-Reply-To: <827052122.20224553.1383862881105.JavaMail.root@redhat.com> References: <827052122.20224553.1383862881105.JavaMail.root@redhat.com> Message-ID: <352502279.21152789.1383895525567.JavaMail.root@redhat.com> Kudos for the nice wiki and the detailed information. ----- Original Message ----- > From: "Vojtech Szocs" > To: "engine-devel" > Sent: Friday, November 8, 2013 12:21:21 AM > Subject: [Engine-devel] oVirt UI plugins feature announcements > > Hello everyone, > > I'd like to share some important updates on oVirt UI plugins feature. > > First of all, UI plugins wiki [1] is finally complete. API reference > (application events, API functions, API options, entity types) now includes > all the details and snippets of example code. I've also added section "Why > load plugins via iframe element?" explaining reasons behind this design > decision. > > [1] http://www.ovirt.org/Features/UIPlugins > > You might have noticed the changes in oVirt Engine URI layout [2], these are > already reflected in UI plugins wiki. For existing plugins, this means > changing URLs like this: > > /webadmin/webadmin/plugin/ExamplePlugin/start.html > > to this: > > /ovirt-engine/webadmin/plugin/ExamplePlugin/start.html > > [2] http://gerrit.ovirt.org/#/c/20473/ > > We're planning to merge patch "Improve UI Plugin vs. REST API integration" > [http://gerrit.ovirt.org/#/c/20404/] soon, please review the change outlined > in commit message, let me know if you have any questions. > > Last but not least, oVirt Space Shooter (a.k.a UI plugins crash course) wiki > [3] has been updated to reflect changes mentioned above. > > [3] http://www.ovirt.org/Tutorial/UIPlugins/CrashCourse > > Regards, > Vojtech > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > From tjelinek at redhat.com Fri Nov 8 07:55:51 2013 From: tjelinek at redhat.com (Tomas Jelinek) Date: Fri, 8 Nov 2013 02:55:51 -0500 (EST) Subject: [Engine-devel] [UX] how to design a bar/line chart? In-Reply-To: <1256716135.18537721.1383838835580.JavaMail.root@redhat.com> References: <157528892.18409921.1383645002815.JavaMail.root@redhat.com> <52790A6A.9000808@redhat.com> <1596552383.20866728.1383747975841.JavaMail.root@redhat.com> <527B386A.1050805@redhat.com> <527B3B3D.5090707@redhat.com> <1287617536.19813483.1383809185017.JavaMail.root@redhat.com> <527B42DB.5080403@redhat.com> <1256716135.18537721.1383838835580.JavaMail.root@redhat.com> Message-ID: <1718332967.20374444.1383897351819.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Malini Rao" > To: "Lior Vernia" > Cc: "Tomas Jelinek" , "Eldan Hildesheim" , "engine-devel" > , "info" > Sent: Thursday, November 7, 2013 4:40:35 PM > Subject: Re: [Engine-devel] [UX] how to design a bar/line chart? > > While the technical discussion carries on, I want to go back to the user > requirement here one more time - What is of most value to the user - the > current value accurate to the second level in time ( in which case why do we > want line chart/ sparklines etc) or a trend of how this entity is doing in > the last x hours including a 'sense' of where it is at this time? If a > second to second difference is important to be obvious, then sparklines or > any other small charting method is possibly not the best way to go. We may > need to design an entire monitoring view with more detailed graphs for > various measures etc. My impression with this requirement was that it is > valuable for the user to get a sense of the trend for the measure on the > entity just by looking at the shape of the line and the end point gives you > an 'idea' of where the entity is at so that you can decide if any > investigation is needed or base your decisions on it. I have a hard time > wrapping my head around the possibility that decisions will be influenced by > data delays of a few secs. In my mind, this is not like a stock ticker... is > it? The requirement here (AFAIU) is to have an idea on how the entity is doing - the trend and the actual value so you can take appropriate actions if something is suspicious. The problem with the 15 sec sampling is not the delay but the completely lost information. It would not be a problem if the resource usage would be rather stable (e.g. the whole 15 sec interval the CPU usage is 40%) than we can take the sample once in 15 sec, present it to the user and he/she will know if this is OK or not. But this is unfortunately not true (or does not have to be) and the resource usage pretty much jumps up and down. If you take a sample each 15 sec you present one random value to the user and he/she can not know what the actual usage is. Imagine this example: sec 1: 100% sec 2: 100% ... sec 10: 100% sec 11: 0% sec 12: 0% sec 13: 0% sec 14: 0% sec 15: 0% <- sample sec 16: 100% ... And this pattern repeats. You will present a user that the CPU usage is stable 0% completely useless (and also incorrect, but mostly useless ;) ). What you want to present instead is stable 66% (which is also incorrect but much more useful). > > > ----- Original Message ----- > From: "Lior Vernia" > To: "Tomas Jelinek" > Cc: "Eldan Hildesheim" , "engine-devel" > , "info" > Sent: Thursday, November 7, 2013 2:35:55 AM > Subject: Re: [Engine-devel] [UX] how to design a bar/line chart? > > > > 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 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 at 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 at ovirt.org > >>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel > >>>>> > >>>>> > >>>>> > >>>> _______________________________________________ > >>>> Engine-devel mailing list > >>>> Engine-devel at ovirt.org > >>>> http://lists.ovirt.org/mailman/listinfo/engine-devel > >>>> > >>> _______________________________________________ > >>> Engine-devel mailing list > >>> Engine-devel at ovirt.org > >>> http://lists.ovirt.org/mailman/listinfo/engine-devel > >>> > >> _______________________________________________ > >> Engine-devel mailing list > >> Engine-devel at ovirt.org > >> http://lists.ovirt.org/mailman/listinfo/engine-devel > >> > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > From sbonazzo at redhat.com Fri Nov 8 09:47:07 2013 From: sbonazzo at redhat.com (Sandro Bonazzola) Date: Fri, 08 Nov 2013 10:47:07 +0100 Subject: [Engine-devel] [QE] bug scrubing / triaging Message-ID: <527CB31B.2030705@redhat.com> Hi, Looking at bugzilla, there are 366 bugs without a target release. Some of them are in POST state but I'm pretty sure they should be in ON_QA or CLOSED state. A lot of them haven't a whiteboard set. Please review the bug list and help to scrub and triage them: https://bugzilla.redhat.com/buglist.cgi?bug_status=NEW&bug_status=ASSIGNED&bug_status=POST&classification=Community&columnlist=product%2Ccomponent%2Cassigned_to%2Cbug_status%2Cresolution%2Cshort_desc%2Ctarget_release%2Cstatus_whiteboard&list_id=1883279&product=oVirt&query_based_on=&query_format=advanced&target_release=--- Thanks -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com From mrao at redhat.com Fri Nov 8 14:42:11 2013 From: mrao at redhat.com (Malini Rao) Date: Fri, 8 Nov 2013 09:42:11 -0500 (EST) Subject: [Engine-devel] [UX] how to design a bar/line chart? In-Reply-To: <1718332967.20374444.1383897351819.JavaMail.root@redhat.com> References: <157528892.18409921.1383645002815.JavaMail.root@redhat.com> <1596552383.20866728.1383747975841.JavaMail.root@redhat.com> <527B386A.1050805@redhat.com> <527B3B3D.5090707@redhat.com> <1287617536.19813483.1383809185017.JavaMail.root@redhat.com> <527B42DB.5080403@redhat.com> <1256716135.18537721.1383838835580.JavaMail.root@redhat.com> <1718332967.20374444.1383897351819.JavaMail.root@redhat.com> Message-ID: <1686898888.19254680.1383921731791.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Tomas Jelinek" > To: "Malini Rao" > Cc: "Eldan Hildesheim" , "engine-devel" , "info" > Sent: Friday, November 8, 2013 2:55:51 AM > Subject: Re: [Engine-devel] [UX] how to design a bar/line chart? > > > > ----- Original Message ----- > > From: "Malini Rao" > > To: "Lior Vernia" > > Cc: "Tomas Jelinek" , "Eldan Hildesheim" > > , "engine-devel" > > , "info" > > Sent: Thursday, November 7, 2013 4:40:35 PM > > Subject: Re: [Engine-devel] [UX] how to design a bar/line chart? > > > > While the technical discussion carries on, I want to go back to the user > > requirement here one more time - What is of most value to the user - the > > current value accurate to the second level in time ( in which case why do > > we > > want line chart/ sparklines etc) or a trend of how this entity is doing in > > the last x hours including a 'sense' of where it is at this time? If a > > second to second difference is important to be obvious, then sparklines or > > any other small charting method is possibly not the best way to go. We may > > need to design an entire monitoring view with more detailed graphs for > > various measures etc. My impression with this requirement was that it is > > valuable for the user to get a sense of the trend for the measure on the > > entity just by looking at the shape of the line and the end point gives you > > an 'idea' of where the entity is at so that you can decide if any > > investigation is needed or base your decisions on it. I have a hard time > > wrapping my head around the possibility that decisions will be influenced > > by > > data delays of a few secs. In my mind, this is not like a stock ticker... > > is > > it? > > The requirement here (AFAIU) is to have an idea on how the entity is doing - > the trend and the actual value > so you can take appropriate actions if something is suspicious. > > The problem with the 15 sec sampling is not the delay but the completely > lost information. It would not be a problem if the resource usage would be > rather stable (e.g. the whole 15 > sec interval the CPU usage is 40%) than we can take the sample once in 15 > sec, present it to the user and > he/she will know if this is OK or not. But this is unfortunately not true (or > does not have to be) and the > resource usage pretty much jumps up and down. If you take a sample each 15 > sec you present one random value > to the user and he/she can not know what the actual usage is. > Imagine this example: > sec 1: 100% > sec 2: 100% > ... > sec 10: 100% > sec 11: 0% > sec 12: 0% > sec 13: 0% > sec 14: 0% > sec 15: 0% <- sample > > sec 16: 100% > ... > And this pattern repeats. I thought the system would not just report the sec 15 value but update the sparkline with sec 1- 15 at sec 16 and sec 16- 30 at sec 31. So no info is lost. No? Is it possible that a change in pattern is not detected until 15 secs later.. yes. But the question is if that delay is critical and if the action/ decision to address it happens in the 15 secs before the next refresh. > > You will present a user that the CPU usage is stable 0% completely useless > (and also incorrect, but mostly useless ;) ). > What you want to present instead is stable 66% (which is also incorrect but > much more useful). > > > > > > > ----- Original Message ----- > > From: "Lior Vernia" > > To: "Tomas Jelinek" > > Cc: "Eldan Hildesheim" , "engine-devel" > > , "info" > > Sent: Thursday, November 7, 2013 2:35:55 AM > > Subject: Re: [Engine-devel] [UX] how to design a bar/line chart? > > > > > > > > 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 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 at 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 at ovirt.org > > >>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel > > >>>>> > > >>>>> > > >>>>> > > >>>> _______________________________________________ > > >>>> Engine-devel mailing list > > >>>> Engine-devel at ovirt.org > > >>>> http://lists.ovirt.org/mailman/listinfo/engine-devel > > >>>> > > >>> _______________________________________________ > > >>> Engine-devel mailing list > > >>> Engine-devel at ovirt.org > > >>> http://lists.ovirt.org/mailman/listinfo/engine-devel > > >>> > > >> _______________________________________________ > > >> Engine-devel mailing list > > >> Engine-devel at ovirt.org > > >> http://lists.ovirt.org/mailman/listinfo/engine-devel > > >> > > _______________________________________________ > > Engine-devel mailing list > > Engine-devel at ovirt.org > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > From tjelinek at redhat.com Fri Nov 8 15:40:36 2013 From: tjelinek at redhat.com (Tomas Jelinek) Date: Fri, 8 Nov 2013 10:40:36 -0500 (EST) Subject: [Engine-devel] [UX] how to design a bar/line chart? In-Reply-To: <1686898888.19254680.1383921731791.JavaMail.root@redhat.com> References: <157528892.18409921.1383645002815.JavaMail.root@redhat.com> <527B386A.1050805@redhat.com> <527B3B3D.5090707@redhat.com> <1287617536.19813483.1383809185017.JavaMail.root@redhat.com> <527B42DB.5080403@redhat.com> <1256716135.18537721.1383838835580.JavaMail.root@redhat.com> <1718332967.20374444.1383897351819.JavaMail.root@redhat.com> <1686898888.19254680.1383921731791.JavaMail.root@redhat.com> Message-ID: <353554209.20765391.1383925236468.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Malini Rao" > To: "Tomas Jelinek" > Cc: "Eldan Hildesheim" , "engine-devel" , "info" > Sent: Friday, November 8, 2013 3:42:11 PM > Subject: Re: [Engine-devel] [UX] how to design a bar/line chart? > > > ----- Original Message ----- > > From: "Tomas Jelinek" > > To: "Malini Rao" > > Cc: "Eldan Hildesheim" , "engine-devel" > > , "info" > > Sent: Friday, November 8, 2013 2:55:51 AM > > Subject: Re: [Engine-devel] [UX] how to design a bar/line chart? > > > > > > > > ----- Original Message ----- > > > From: "Malini Rao" > > > To: "Lior Vernia" > > > Cc: "Tomas Jelinek" , "Eldan Hildesheim" > > > , "engine-devel" > > > , "info" > > > Sent: Thursday, November 7, 2013 4:40:35 PM > > > Subject: Re: [Engine-devel] [UX] how to design a bar/line chart? > > > > > > While the technical discussion carries on, I want to go back to the user > > > requirement here one more time - What is of most value to the user - the > > > current value accurate to the second level in time ( in which case why do > > > we > > > want line chart/ sparklines etc) or a trend of how this entity is doing > > > in > > > the last x hours including a 'sense' of where it is at this time? If a > > > second to second difference is important to be obvious, then sparklines > > > or > > > any other small charting method is possibly not the best way to go. We > > > may > > > need to design an entire monitoring view with more detailed graphs for > > > various measures etc. My impression with this requirement was that it is > > > valuable for the user to get a sense of the trend for the measure on the > > > entity just by looking at the shape of the line and the end point gives > > > you > > > an 'idea' of where the entity is at so that you can decide if any > > > investigation is needed or base your decisions on it. I have a hard time > > > wrapping my head around the possibility that decisions will be influenced > > > by > > > data delays of a few secs. In my mind, this is not like a stock ticker... > > > is > > > it? > > > > The requirement here (AFAIU) is to have an idea on how the entity is doing > > - > > the trend and the actual value > > so you can take appropriate actions if something is suspicious. > > > > The problem with the 15 sec sampling is not the delay but the completely > > lost information. It would not be a problem if the resource usage would be > > rather stable (e.g. the whole 15 > > sec interval the CPU usage is 40%) than we can take the sample once in 15 > > sec, present it to the user and > > he/she will know if this is OK or not. But this is unfortunately not true > > (or > > does not have to be) and the > > resource usage pretty much jumps up and down. If you take a sample each 15 > > sec you present one random value > > to the user and he/she can not know what the actual usage is. > > Imagine this example: > > sec 1: 100% > > sec 2: 100% > > ... > > sec 10: 100% > > sec 11: 0% > > sec 12: 0% > > sec 13: 0% > > sec 14: 0% > > sec 15: 0% <- sample > > > > sec 16: 100% > > ... > > And this pattern repeats. > > I thought the system would not just report the sec 15 value but update the > sparkline with sec 1- 15 at sec 16 and sec 16- 30 at sec 31. So no info is > lost. No? No :) It will just update this one value. Now the question is how often and what value will you get. I will look into this deeper and get back to this list. > Is it possible that a change in pattern is not detected until 15 > secs later.. yes. But the question is if that delay is critical and if the > action/ decision to address it happens in the 15 secs before the next > refresh. > > > > > You will present a user that the CPU usage is stable 0% completely useless > > (and also incorrect, but mostly useless ;) ). > > What you want to present instead is stable 66% (which is also incorrect but > > much more useful). > > > > > > > > > > > ----- Original Message ----- > > > From: "Lior Vernia" > > > To: "Tomas Jelinek" > > > Cc: "Eldan Hildesheim" , "engine-devel" > > > , "info" > > > Sent: Thursday, November 7, 2013 2:35:55 AM > > > Subject: Re: [Engine-devel] [UX] how to design a bar/line chart? > > > > > > > > > > > > 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 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 at 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 at ovirt.org > > > >>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel > > > >>>>> > > > >>>>> > > > >>>>> > > > >>>> _______________________________________________ > > > >>>> Engine-devel mailing list > > > >>>> Engine-devel at ovirt.org > > > >>>> http://lists.ovirt.org/mailman/listinfo/engine-devel > > > >>>> > > > >>> _______________________________________________ > > > >>> Engine-devel mailing list > > > >>> Engine-devel at ovirt.org > > > >>> http://lists.ovirt.org/mailman/listinfo/engine-devel > > > >>> > > > >> _______________________________________________ > > > >> Engine-devel mailing list > > > >> Engine-devel at ovirt.org > > > >> http://lists.ovirt.org/mailman/listinfo/engine-devel > > > >> > > > _______________________________________________ > > > Engine-devel mailing list > > > Engine-devel at ovirt.org > > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > > > > From ecohen at redhat.com Fri Nov 8 20:50:10 2013 From: ecohen at redhat.com (Einav Cohen) Date: Fri, 8 Nov 2013 15:50:10 -0500 (EST) Subject: [Engine-devel] [UX] how to design a bar/line chart? In-Reply-To: <20131107164407.GB31469@bogey.xentower.nl> References: <157528892.18409921.1383645002815.JavaMail.root@redhat.com> <10671894.E7RLZxpxmS@awels> <845594321.17693417.1383753786397.JavaMail.root@redhat.com> <4799215.PFXHvLDZXl@awels> <20131107164407.GB31469@bogey.xentower.nl> Message-ID: <312159812.23706941.1383943810196.JavaMail.root@redhat.com> > ----- Original Message ----- > From: "Ewoud Kohl van Wijngaarden" > Sent: Thursday, November 7, 2013 11:44:07 AM > > On Wed, Nov 06, 2013 at 11:45:36AM -0500, 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. > > I'd say no. Even from a reliability point of view since users may have > systems that aren't connected to the internet. +1 > (Though I don't know how well oVirt handles this currently.) AFAIK - oVirt is handling it ('it' == having no internet connection) well. From shtripat at redhat.com Sat Nov 9 09:07:44 2013 From: shtripat at redhat.com (Shubhendu Tripathi) Date: Sat, 09 Nov 2013 14:37:44 +0530 Subject: [Engine-devel] IMP: Regarding an issue while translating the error messages for gluster using ErrorTranslator class In-Reply-To: <1082228530.20856483.1383747009016.JavaMail.root@redhat.com> References: <527A14E6.8010809@redhat.com> <2115335.RGeYIF2D09@awels> <1082228530.20856483.1383747009016.JavaMail.root@redhat.com> Message-ID: <527DFB60.6020709@redhat.com> On 11/06/2013 07:40 PM, Einav Cohen wrote: >> ----- 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). There is an upstream patch according to Einav's suggestion above. http://gerrit.ovirt.org/#/c/21083/ > >> 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 at ovirt.org >> http://lists.ovirt.org/mailman/listinfo/engine-devel >> > From ehildesh at redhat.com Sun Nov 10 14:56:57 2013 From: ehildesh at redhat.com (Eldan Hildesheim) Date: Sun, 10 Nov 2013 09:56:57 -0500 (EST) Subject: [Engine-devel] [UX] how to design a bar/line chart? In-Reply-To: <312159812.23706941.1383943810196.JavaMail.root@redhat.com> References: <157528892.18409921.1383645002815.JavaMail.root@redhat.com> <10671894.E7RLZxpxmS@awels> <845594321.17693417.1383753786397.JavaMail.root@redhat.com> <4799215.PFXHvLDZXl@awels> <20131107164407.GB31469@bogey.xentower.nl> <312159812.23706941.1383943810196.JavaMail.root@redhat.com> Message-ID: <1591156023.26916611.1384095417884.JavaMail.root@redhat.com> Hello all, We use to have a good solution in the period pre-WPF. A line chart (used to be in flash) that works like a plotter: The Line Bar (not bar) had a small animation that shifted all the bar to the left. When a new data arrived it just added a new line (to the right) and as I said before, in parallel it always shifted slowly to the left. The animation gives the impression that data is streaming and when a real new data arrives the user gets it very fast. We have to sync between the animation and the rate of the arrival of the data but this is easy. If we can't find a good framework it can be created from scratch with JS, svg or canvas. Now regarding its position: Rollover is good but not enough, we should somehow put it in the lower panel under general or even another tab - (live data). We could later on have a (live data Tab) in other places as well like host, cluster... Eldan ----- Original Message ----- From: "Einav Cohen" To: "Ewoud Kohl van Wijngaarden" Cc: "Alexander Wels" , "Eldan Hildesheim" , engine-devel at ovirt.org, "info" Sent: Friday, November 8, 2013 10:50:10 PM Subject: Re: [Engine-devel] [UX] how to design a bar/line chart? > ----- Original Message ----- > From: "Ewoud Kohl van Wijngaarden" > Sent: Thursday, November 7, 2013 11:44:07 AM > > On Wed, Nov 06, 2013 at 11:45:36AM -0500, 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. > > I'd say no. Even from a reliability point of view since users may have > systems that aren't connected to the internet. +1 > (Though I don't know how well oVirt handles this currently.) AFAIK - oVirt is handling it ('it' == having no internet connection) well. From masayag at redhat.com Sun Nov 10 17:36:08 2013 From: masayag at redhat.com (Moti Asayag) Date: Sun, 10 Nov 2013 12:36:08 -0500 (EST) Subject: [Engine-devel] REST-API: Problem with additional DELETE action at collection level In-Reply-To: <527C86AA.7010904@redhat.com> References: <527C7DDF.2050308@redhat.com> <527C86AA.7010904@redhat.com> Message-ID: <25153947.26941766.1384104968045.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Shubhendu Tripathi" > To: "engine-devel" , "Michael Pasternak" , oliel at redhat.com > Sent: Friday, November 8, 2013 8:37:30 AM > Subject: [Engine-devel] REST-API: Problem with additional DELETE action at collection level > > Hi All, > > There is a DELETE action defined at collection level for Gluster Bricks with > signature - > > @DELETE > public Response remove ( GlusterBricks bricks ); > > Recently we had needed a commit action to remove migrated bricks. > After multiple rounds of discussion on introducing a commit action to remove > migrated bricks we introduced a DELETE action [1] which accepts a boolean > parameter isForce. > If the parameter is set to true , forced deletion of bricks happens without > any data migration. > And if the parameter is not set or set to false, the deletion is meant for a > brick on which migration has already taken place. > > To achieve the above functionality we introduced another DELETE action with > new signature as below and also marked the first action as deprecated - > > @DELETE > public Response remove ( Action action ); > > The problem arises now as the new api works fine for all possible scenarios > with below input structure - > > > true/false > > > brick1-name > brick2-name > > > > > BUT after these change backward compatibility is broken and the old api does > not work. > If we try invoking old DELETE with bricks as input parameter as below, it > still invokes the new api and gives an error saying " Invalid parameter ". > Maybe I've missed it some where, but i wasn't able to find the new 'force' parameter in the rsdl, and specifically not in optionalArguments list of: - name: /api/clusters/{cluster:id}/glustervolumes/{glustervolume:id}/bricks|rel=delete and perhaps the correct approach will be to deprecate this signature and introduce a new one with the 'force' in the 'mandatoryArguments' section. > > > > > > Kindly suggest a solution around the same. > > PS: Both the actions are defined at collection level ( > /api/clusters//glustervolumes//bricks ) > > [1]: http://gerrit.ovirt.org/#/c/21043/ > > Thanks and Regards, > Shubhendu > > > > > > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > From shtripat at redhat.com Mon Nov 11 05:00:31 2013 From: shtripat at redhat.com (Shubhendu Tripathi) Date: Mon, 11 Nov 2013 10:30:31 +0530 Subject: [Engine-devel] REST-API: Problem with additional DELETE action at collection level In-Reply-To: <25153947.26941766.1384104968045.JavaMail.root@redhat.com> References: <527C7DDF.2050308@redhat.com> <527C86AA.7010904@redhat.com> <25153947.26941766.1384104968045.JavaMail.root@redhat.com> Message-ID: <5280646F.2050903@redhat.com> On 11/10/2013 11:06 PM, Moti Asayag wrote: > > ----- Original Message ----- >> From: "Shubhendu Tripathi" >> To: "engine-devel" , "Michael Pasternak" , oliel at redhat.com >> Sent: Friday, November 8, 2013 8:37:30 AM >> Subject: [Engine-devel] REST-API: Problem with additional DELETE action at collection level >> >> Hi All, >> >> There is a DELETE action defined at collection level for Gluster Bricks with >> signature - >> >> @DELETE >> public Response remove ( GlusterBricks bricks ); >> >> Recently we had needed a commit action to remove migrated bricks. >> After multiple rounds of discussion on introducing a commit action to remove >> migrated bricks we introduced a DELETE action [1] which accepts a boolean >> parameter isForce. >> If the parameter is set to true , forced deletion of bricks happens without >> any data migration. >> And if the parameter is not set or set to false, the deletion is meant for a >> brick on which migration has already taken place. >> >> To achieve the above functionality we introduced another DELETE action with >> new signature as below and also marked the first action as deprecated - >> >> @DELETE >> public Response remove ( Action action ); >> >> The problem arises now as the new api works fine for all possible scenarios >> with below input structure - >> >> >> true/false >> >> >> brick1-name >> brick2-name >> >> >> >> >> BUT after these change backward compatibility is broken and the old api does >> not work. >> If we try invoking old DELETE with bricks as input parameter as below, it >> still invokes the new api and gives an error saying " Invalid parameter ". >> > Maybe I've missed it some where, but i wasn't able to find the new 'force' parameter > in the rsdl, and specifically not in optionalArguments list of: > > - name: /api/clusters/{cluster:id}/glustervolumes/{glustervolume:id}/bricks|rel=delete > > and perhaps the correct approach will be to deprecate this signature and introduce a new > one with the 'force' in the 'mandatoryArguments' section. Moti, I have introduced another methods remove of DELETE type which takes Action as input. I pass list of bricks and force as parameter in the same Action. Also, I tried marking the old method deprecated and introduced the new one BUT as mentioned above, after introduction of new DELETE with Action parameter old one STOPS working. Is it OK to stop working for a method if its deprecated?? I don't feel so. Please comment. > >> >> >> >> >> >> Kindly suggest a solution around the same. >> >> PS: Both the actions are defined at collection level ( >> /api/clusters//glustervolumes//bricks ) >> >> [1]: http://gerrit.ovirt.org/#/c/21043/ >> >> Thanks and Regards, >> Shubhendu >> >> >> >> >> >> _______________________________________________ >> Engine-devel mailing list >> Engine-devel at ovirt.org >> http://lists.ovirt.org/mailman/listinfo/engine-devel >> From shtripat at redhat.com Mon Nov 11 06:20:41 2013 From: shtripat at redhat.com (Shubhendu Tripathi) Date: Mon, 11 Nov 2013 11:50:41 +0530 Subject: [Engine-devel] Error message while trying to delete default cluster Message-ID: <52807739.30303@redhat.com> Hi, While trying to delete the Default cluster in oVirt it shows the below error message - "Cannot remove default Host Cluster. Cannot remove Cluster. One or more Template(s) are still associated with it" But in the case of RHSC, Templates are not used and this message is not relevant. [1]. Can we opt for not installing the templates while engine setup? And would it be having any impact/consequences ? Kindly provide your thoughts and possibility of the same. Thanks and Regards, Shubhendu PS: [1]: https://bugzilla.redhat.com/show_bug.cgi?id=1019838 From mkolesni at redhat.com Mon Nov 11 07:49:33 2013 From: mkolesni at redhat.com (Mike Kolesnik) Date: Mon, 11 Nov 2013 02:49:33 -0500 (EST) Subject: [Engine-devel] Custom properties per device + vNIC profile = not working (< 3.3) In-Reply-To: <1460357966.29104754.1384153989435.JavaMail.root@redhat.com> Message-ID: <1480148973.29121435.1384156173916.JavaMail.root@redhat.com> Hi, I came across a situation where I wanted to define custom properties on a vNIC profile sitting under a network in a 3.2 data center. >From what I saw the configuration value for custom properties (CustomDeviceProperties) is split into 4, one per each version (3.0, 3.1, 3.2, 3.3). Since vNIC profile is located under the DC tree, it takes the DC version - 3.2 in this specific case. I tried to set the config value for 3.2 but got: $ engine-config -s CustomDeviceProperties="{type=interface;prop={myProp=[a-zA-Z0-9-]+}}" --cver=3.2 Cannot set value {type=interface;prop={myProp=[a-zA-Z0-9-]+}} to key CustomDeviceProperties. Device custom properties are not supported in version 3.2 This is already not very good, since in a 3.2 DC there can be 3.3 clusters with 3.3 hosts that do support custom device properties. I also tried to alter the config value in the DB directly, but the custom properties code ignored it since custom properties are not supported in 3.2. So, de facto, I have no reasonable way as a user to define custom device properties to use for my vNIC profiles in DC < 3.3. I opened the bug https://bugzilla.redhat.com/show_bug.cgi?id=1028757 for this, however I also want to discuss the situation: 1. As a user, I can't set custom properties for level < 3.3 which is not good. Removing the blocking, and loading custom properties for all versions would fix the bug and allow using custom device properties for older versions, the reasonable place to block this would be running a VM (or plugging a device). Basically this is the lesser issue.. 2. I just don't see the added value of splitting the definition of the properties per level.. The custom properties are extensions which might or might not be available to a certain VM, I don't see how having different sets of custom properties per version (what version, DC version, cluster version?) would make any difference - either the VM can utilize the extension given some state of the system, or it can't, but the determining factor is not the version but rather the availability of the extension. For example, I can have a hook for vNIC altering some property installed on host A and not host B, if the VM runs on host A it will get this capability and on host B it won't, regardless the DC version the VM is in. This is not to say we shouldn't block custom properties on the engine-VDSM API level since it's only available since 3.3, but this is handled by another config value (SupportCustomDeviceProperties) which is not alterable by the user. So basically, I think splitting the value per version is over complication and see no added value to the users, just more maintenance should they choose to use this feature. Your thoughts please. Regards, Mike -------------- next part -------------- An HTML attachment was scrubbed... URL: From sbonazzo at redhat.com Mon Nov 11 09:26:19 2013 From: sbonazzo at redhat.com (Sandro Bonazzola) Date: Mon, 11 Nov 2013 10:26:19 +0100 Subject: [Engine-devel] [vdsm] daily oVirt 3.3.1 blocker status In-Reply-To: <20131108002845.GP16597@redhat.com> References: <52720B88.9080001@redhat.com> <5277553F.3010807@redhat.com> <20131104092600.GB27545@redhat.com> <5278BCD1.3030808@redhat.com> <5279EFA0.2030309@redhat.com> <932728766.19142551.1383723368752.JavaMail.root@redhat.com> <20131108002845.GP16597@redhat.com> Message-ID: <5280A2BB.40601@redhat.com> Il 08/11/2013 01:28, Dan Kenigsberg ha scritto: > On Wed, Nov 06, 2013 at 02:36:08AM -0500, Eduardo Warszawski wrote: >>> 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! :) > > It's not the /real thing/ that Eduardo wanted, but it's something and > it's working. Please review and verify > > http://gerrit.ovirt.org/#/c/21059/ > gluster prepareImage: return gluster-sepecific information > Hi, Bug 1022961 - Running a VM from a gluster domain uses mount instead of gluster URI is the only bug blocking 3.3.1 and is on POST. the related patch http://gerrit.ovirt.org/21059 is marked as verified and has two +1. Can you merge the patch and build VDSM for having it under testing so we can try to release 3.3.1 this week? -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com From mperina at redhat.com Mon Nov 11 09:38:01 2013 From: mperina at redhat.com (Martin Perina) Date: Mon, 11 Nov 2013 04:38:01 -0500 (EST) Subject: [Engine-devel] Fwd: Custom properties per device + vNIC profile = not working (< 3.3) In-Reply-To: <1043647659.27242521.1384160190166.JavaMail.root@redhat.com> References: <1480148973.29121435.1384156173916.JavaMail.root@redhat.com> <1043647659.27242521.1384160190166.JavaMail.root@redhat.com> Message-ID: <391769945.27298763.1384162681266.JavaMail.root@redhat.com> Hi Mike, ----- Original Message ----- > From: "Mike Kolesnik" > To: "engine-devel" > Cc: "Barak Azulay" , "Martin Perina" , "Livnat Peer" , > "Itamar Heim" > Sent: Monday, November 11, 2013 8:49:33 AM > Subject: Custom properties per device + vNIC profile = not working (< 3.3) > > Hi, > > I came across a situation where I wanted to define custom properties on a > vNIC profile sitting under a network in a 3.2 data center. > From what I saw the configuration value for custom properties > (CustomDeviceProperties) is split into 4, one per each version (3.0, 3.1, > 3.2, 3.3). > Since vNIC profile is located under the DC tree, it takes the DC version - > 3.2 in this specific case. Custom Device Properties were designed to be specified for each cluster version independently, it doesn't care about DC version. AFAIK cluster version defines what features are available ... > > I tried to set the config value for 3.2 but got: > $ engine-config -s > CustomDeviceProperties="{type=interface;prop={myProp=[a-zA-Z0-9-]+}}" > --cver=3.2 > Cannot set value {type=interface;prop={myProp=[a-zA-Z0-9-]+}} to key > CustomDeviceProperties. Device custom properties are not supported in > version 3.2 > > This is already not very good, since in a 3.2 DC there can be 3.3 clusters > with 3.3 hosts that do support custom device properties. Specify your properties for 3.3 version, since they will be used in 3.3 clusters ... > > I also tried to alter the config value in the DB directly, but the custom > properties code ignored it since custom properties are not supported in 3.2. > So, de facto, I have no reasonable way as a user to define custom device > properties to use for my vNIC profiles in DC < 3.3. There are two configuration properties for Custom Device Properties: 1) SupportCustomDeviceProperties - defines in what version properties are supported - cannot be altered by users of course 2) CustomDeviceProperties - holds properties specification for each version - can be defined using engine-config > > I opened the bug https://bugzilla.redhat.com/show_bug.cgi?id=1028757 for > this, however I also want to discuss the situation: I looked at the bug and the problem is, that management network profile is bound to DC and not the Cluster. And that's something we never thought of ... > > 1. As a user, I can't set custom properties for level < 3.3 which is not > good. Well, it's 3.3 feature, so it looks OK for me > Removing the blocking, and loading custom properties for all versions would > fix the bug and allow using custom device properties for older versions, the > reasonable place to block this would be running a VM (or plugging a device). > Basically this is the lesser issue.. > > 2. I just don't see the added value of splitting the definition of the > properties per level.. The idea behind the version splitting was: 1) We have a device with a feature that doesn't work correctly with version 3.3, but it's fixed in 3.4 2) By specifying custom property per version we cane disable this feature for 3.3 and enable for 3.4 > The custom properties are extensions which might or might not be available to > a certain VM, I don't see how having different sets of custom properties per > version (what version, DC version, cluster version?) would make any > difference - either the VM can utilize the extension given some state of the > system, or it can't, but the determining factor is not the version but > rather the availability of the extension. > For example, I can have a hook for vNIC altering some property installed on > host A and not host B, if the VM runs on host A it will get this capability > and on host B it won't, regardless the DC version the VM is in. > > This is not to say we shouldn't block custom properties on the engine-VDSM > API level since it's only available since 3.3, but this is handled by > another config value (SupportCustomDeviceProperties) which is not alterable > by the user. > So basically, I think splitting the value per version is over complication > and see no added value to the users, just more maintenance should they > choose to use this feature. > > Your thoughts please. AFAIK only network and storage team wanted to use device custom properties in 3.3 version, but I'm not sure what's current usage status. But IMHO it's too late for 3.3 to change specification ... Martin From mkolesni at redhat.com Mon Nov 11 09:48:40 2013 From: mkolesni at redhat.com (Mike Kolesnik) Date: Mon, 11 Nov 2013 04:48:40 -0500 (EST) Subject: [Engine-devel] Fwd: Custom properties per device + vNIC profile = not working (< 3.3) In-Reply-To: <391769945.27298763.1384162681266.JavaMail.root@redhat.com> References: <1480148973.29121435.1384156173916.JavaMail.root@redhat.com> <1043647659.27242521.1384160190166.JavaMail.root@redhat.com> <391769945.27298763.1384162681266.JavaMail.root@redhat.com> Message-ID: <2080457776.29191617.1384163320455.JavaMail.root@redhat.com> ----- Original Message ----- > Hi Mike, > > ----- Original Message ----- > > From: "Mike Kolesnik" > > To: "engine-devel" > > Cc: "Barak Azulay" , "Martin Perina" > > , "Livnat Peer" , > > "Itamar Heim" > > Sent: Monday, November 11, 2013 8:49:33 AM > > Subject: Custom properties per device + vNIC profile = not working (< 3.3) > > > > Hi, > > > > I came across a situation where I wanted to define custom properties on a > > vNIC profile sitting under a network in a 3.2 data center. > > From what I saw the configuration value for custom properties > > (CustomDeviceProperties) is split into 4, one per each version (3.0, 3.1, > > 3.2, 3.3). > > Since vNIC profile is located under the DC tree, it takes the DC version - > > 3.2 in this specific case. > > Custom Device Properties were designed to be specified for each cluster > version > independently, it doesn't care about DC version. AFAIK cluster version > defines > what features are available ... > > > > > I tried to set the config value for 3.2 but got: > > $ engine-config -s > > CustomDeviceProperties="{type=interface;prop={myProp=[a-zA-Z0-9-]+}}" > > --cver=3.2 > > Cannot set value {type=interface;prop={myProp=[a-zA-Z0-9-]+}} to key > > CustomDeviceProperties. Device custom properties are not supported in > > version 3.2 > > > > This is already not very good, since in a 3.2 DC there can be 3.3 clusters > > with 3.3 hosts that do support custom device properties. > > Specify your properties for 3.3 version, since they will be used in 3.3 > clusters ... > But the effective version is the DC version as I explained. In a DC 3.0-3.3 I can have clusters which the minimal version is the DC version, and the maximal version is 3.3. For example I can have the following: DC - version 3.0 + Cluster 1 - version 3.0 + Cluster 2 - version 3.1 + Cluster 3 - version 3.2 + Cluster 4 - version 3.3 In this constellation, I could use custom device properties only on Cluster 4, but it's not possible to define them since the vNIC profile is using the DC version 3.0. So effectively this feature is not usable to me unless I use a 3.3 DC. > > > > I also tried to alter the config value in the DB directly, but the custom > > properties code ignored it since custom properties are not supported in > > 3.2. > > So, de facto, I have no reasonable way as a user to define custom device > > properties to use for my vNIC profiles in DC < 3.3. > > There are two configuration properties for Custom Device Properties: > > 1) SupportCustomDeviceProperties > - defines in what version properties are supported > - cannot be altered by users of course > > 2) CustomDeviceProperties > - holds properties specification for each version > - can be defined using engine-config > > > > > I opened the bug https://bugzilla.redhat.com/show_bug.cgi?id=1028757 for > > this, however I also want to discuss the situation: > > I looked at the bug and the problem is, that management network profile > is bound to DC and not the Cluster. And that's something we never thought of > ... > > > > > 1. As a user, I can't set custom properties for level < 3.3 which is not > > good. > > Well, it's 3.3 feature, so it looks OK for me > > > Removing the blocking, and loading custom properties for all versions would > > fix the bug and allow using custom device properties for older versions, > > the > > reasonable place to block this would be running a VM (or plugging a > > device). > > Basically this is the lesser issue.. > > > > 2. I just don't see the added value of splitting the definition of the > > properties per level.. > > The idea behind the version splitting was: > > 1) We have a device with a feature that doesn't work correctly with version > 3.3, > but it's fixed in 3.4 > 2) By specifying custom property per version we cane disable this feature for > 3.3 > and enable for 3.4 Custom properties is not for specifying which features are enabled, there is a whole other mechanism for that.. Custom properties is for hooks (and other possible extensions), which by definition are not something that is guaranteed to exist so I see no point to force the user to update multiple configurations and cause confusion for him.. > > > The custom properties are extensions which might or might not be available > > to > > a certain VM, I don't see how having different sets of custom properties > > per > > version (what version, DC version, cluster version?) would make any > > difference - either the VM can utilize the extension given some state of > > the > > system, or it can't, but the determining factor is not the version but > > rather the availability of the extension. > > For example, I can have a hook for vNIC altering some property installed on > > host A and not host B, if the VM runs on host A it will get this capability > > and on host B it won't, regardless the DC version the VM is in. > > > > This is not to say we shouldn't block custom properties on the engine-VDSM > > API level since it's only available since 3.3, but this is handled by > > another config value (SupportCustomDeviceProperties) which is not alterable > > by the user. > > So basically, I think splitting the value per version is over complication > > and see no added value to the users, just more maintenance should they > > choose to use this feature. > > > > Your thoughts please. > > AFAIK only network and storage team wanted to use device custom properties > in 3.3 version, but I'm not sure what's current usage status. > > But IMHO it's too late for 3.3 to change specification ... Since I can have cluster 3.3 in a DC < 3.3, and this is the upgrade path for existing users, I'd argue that the bug is severe enough and should be fixed asap even for 3.3 versions. > > Martin > > > > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > From shtripat at redhat.com Mon Nov 11 10:00:34 2013 From: shtripat at redhat.com (Shubhendu Tripathi) Date: Mon, 11 Nov 2013 15:30:34 +0530 Subject: [Engine-devel] REST-API: Problem with additional DELETE action at collection level In-Reply-To: <5280646F.2050903@redhat.com> References: <527C7DDF.2050308@redhat.com> <527C86AA.7010904@redhat.com> <25153947.26941766.1384104968045.JavaMail.root@redhat.com> <5280646F.2050903@redhat.com> Message-ID: <5280AAC2.6010805@redhat.com> Self and Ori had a detailed discussion on the topic. Points discussed - 1. Ori mentioned that Michael and Ori did not mean to have a separate DELETE action for the purpose of commit in previous discussions. 2. Ori tried to understand the intention behind the separate commit command in gluster and suggested that ideally gluster should remember that a migration of data is started on the set of bricks, and if there is a delete fired on the same bricks it should perform a commit action because commit is nothing but a delete action 3. Ori suggested that in an ideal situation APIs needed would be - start migrate - stop migrate - delete bricks - retain bricks 4. As suggested by Ori, the remove bricks action should internally decide if there was a data migration, started on the set of bricks. If so, it should effectively fire a commit for the set of bricks. And if there was not occurrence of data migration it should behave like a normal force remove action. Ori, please add your comments if I have missed out anything here. Sahina, request your comments on the same. Thanks and Regards, Shubhendu On 11/11/2013 10:30 AM, Shubhendu Tripathi wrote: > On 11/10/2013 11:06 PM, Moti Asayag wrote: >> >> ----- Original Message ----- >>> From: "Shubhendu Tripathi" >>> To: "engine-devel" , "Michael Pasternak" >>> , oliel at redhat.com >>> Sent: Friday, November 8, 2013 8:37:30 AM >>> Subject: [Engine-devel] REST-API: Problem with additional DELETE >>> action at collection level >>> >>> Hi All, >>> >>> There is a DELETE action defined at collection level for Gluster >>> Bricks with >>> signature - >>> >>> @DELETE >>> public Response remove ( GlusterBricks bricks ); >>> >>> Recently we had needed a commit action to remove migrated bricks. >>> After multiple rounds of discussion on introducing a commit action >>> to remove >>> migrated bricks we introduced a DELETE action [1] which accepts a >>> boolean >>> parameter isForce. >>> If the parameter is set to true , forced deletion of bricks happens >>> without >>> any data migration. >>> And if the parameter is not set or set to false, the deletion is >>> meant for a >>> brick on which migration has already taken place. >>> >>> To achieve the above functionality we introduced another DELETE >>> action with >>> new signature as below and also marked the first action as deprecated - >>> >>> @DELETE >>> public Response remove ( Action action ); >>> >>> The problem arises now as the new api works fine for all possible >>> scenarios >>> with below input structure - >>> >>> >>> true/false >>> >>> >>> brick1-name >>> brick2-name >>> >>> >>> >>> >>> BUT after these change backward compatibility is broken and the old >>> api does >>> not work. >>> If we try invoking old DELETE with bricks as input parameter as >>> below, it >>> still invokes the new api and gives an error saying " Invalid >>> parameter ". >>> >> Maybe I've missed it some where, but i wasn't able to find the new >> 'force' parameter >> in the rsdl, and specifically not in optionalArguments list of: >> >> - name: >> /api/clusters/{cluster:id}/glustervolumes/{glustervolume:id}/bricks|rel=delete >> >> and perhaps the correct approach will be to deprecate this signature >> and introduce a new >> one with the 'force' in the 'mandatoryArguments' section. > Moti, I have introduced another methods remove of DELETE type which > takes Action as input. > I pass list of bricks and force as parameter in the same Action. > > Also, I tried marking the old method deprecated and introduced the new > one BUT as mentioned above, after introduction of new DELETE with > Action parameter old one STOPS working. > Is it OK to stop working for a method if its deprecated?? I don't feel > so. Please comment. >> >>> >>> >>> >>> >>> >>> Kindly suggest a solution around the same. >>> >>> PS: Both the actions are defined at collection level ( >>> /api/clusters//glustervolumes//bricks ) >>> >>> [1]: http://gerrit.ovirt.org/#/c/21043/ >>> >>> Thanks and Regards, >>> Shubhendu >>> >>> >>> >>> >>> >>> _______________________________________________ >>> Engine-devel mailing list >>> Engine-devel at ovirt.org >>> http://lists.ovirt.org/mailman/listinfo/engine-devel >>> > > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > > From danken at redhat.com Mon Nov 11 10:02:25 2013 From: danken at redhat.com (Dan Kenigsberg) Date: Mon, 11 Nov 2013 10:02:25 +0000 Subject: [Engine-devel] [vdsm] daily oVirt 3.3.1 blocker status In-Reply-To: <5280A2BB.40601@redhat.com> References: <52720B88.9080001@redhat.com> <5277553F.3010807@redhat.com> <20131104092600.GB27545@redhat.com> <5278BCD1.3030808@redhat.com> <5279EFA0.2030309@redhat.com> <932728766.19142551.1383723368752.JavaMail.root@redhat.com> <20131108002845.GP16597@redhat.com> <5280A2BB.40601@redhat.com> Message-ID: <20131111100225.GA26033@redhat.com> On Mon, Nov 11, 2013 at 10:26:19AM +0100, Sandro Bonazzola wrote: > Il 08/11/2013 01:28, Dan Kenigsberg ha scritto: > > On Wed, Nov 06, 2013 at 02:36:08AM -0500, Eduardo Warszawski wrote: > >>> 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! :) > > > > It's not the /real thing/ that Eduardo wanted, but it's something and > > it's working. Please review and verify > > > > http://gerrit.ovirt.org/#/c/21059/ > > gluster prepareImage: return gluster-sepecific information > > > > Hi, > Bug 1022961 - Running a VM from a gluster domain uses mount instead of gluster URI > is the only bug blocking 3.3.1 and is on POST. > the related patch http://gerrit.ovirt.org/21059 is marked as verified and has two +1. > Can you merge the patch and build VDSM for having it under testing so we can try to release 3.3.1 this week? I'd love to merge this in, but given this being my own code, I prefer another core developer ack it, even though no one really likes it. Eduardo dislikes the fact that this patch maintains the awkward API of prepareImage returning this 'info' dictionary on top of the simple 'path' it used to return before the glusterSD effort. Federico dislikes the fact that this patch adds gluster-specific code into our top-level class HSM. To relieve this, I am now suggesting three other cleanup patches http://gerrit.ovirt.org/21122 http://gerrit.ovirt.org/21123 http://gerrit.ovirt.org/21124 but I would like to take the simple fix first. Unbreaking a major feature in master and ovirt-3.3.1 should have precedence over architectural debates. Dan. From tjelinek at redhat.com Mon Nov 11 10:03:15 2013 From: tjelinek at redhat.com (Tomas Jelinek) Date: Mon, 11 Nov 2013 05:03:15 -0500 (EST) Subject: [Engine-devel] [UX] how to design a bar/line chart? In-Reply-To: <1591156023.26916611.1384095417884.JavaMail.root@redhat.com> References: <157528892.18409921.1383645002815.JavaMail.root@redhat.com> <10671894.E7RLZxpxmS@awels> <845594321.17693417.1383753786397.JavaMail.root@redhat.com> <4799215.PFXHvLDZXl@awels> <20131107164407.GB31469@bogey.xentower.nl> <312159812.23706941.1383943810196.JavaMail.root@redhat.com> <1591156023.26916611.1384095417884.JavaMail.root@redhat.com> Message-ID: <1307970395.21470536.1384164195241.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Eldan Hildesheim" > To: "Einav Cohen" > Cc: "info" , engine-devel at ovirt.org > Sent: Sunday, November 10, 2013 3:56:57 PM > Subject: Re: [Engine-devel] [UX] how to design a bar/line chart? > > Hello all, > We use to have a good solution in the period pre-WPF. > A line chart (used to be in flash) that works like a plotter: > The Line Bar (not bar) had a small animation that shifted all the bar to the > left. > When a new data arrived it just added a new line (to the right) and as I said > before, in parallel it always shifted slowly to the left. Any chance you still have some screenshot or mockup so I can imagine it better? > The animation gives the impression that data is streaming and when a real new > data arrives the user gets it very fast. > We have to sync between the animation and the rate of the arrival of the data > but this is easy. > If we can't find a good framework it can be created from scratch with JS, svg > or canvas. We need to be careful about what we will use. oVirt is supposed to work on FF 17 [1] but the HTML5 canvas works only since FF23 [2]. @Einav: Is there a chance that we could start support only FF23+ and IE9+ (this one is already OK) because of this feature? > Now regarding its position: > Rollover is good but not enough, we should somehow put it in the lower panel > under general or even another tab - (live data). This is a bit different requirement. The point of this specific is to give a better overview in the main tab. If it will be done we can decide if we want to give more details in sub tabs. > We could later on have a (live data Tab) in other places as well like host, > cluster... > Eldan [1]: http://www.ovirt.org/Download [2]: http://caniuse.com/#feat=canvas > > ----- Original Message ----- > From: "Einav Cohen" > To: "Ewoud Kohl van Wijngaarden" > Cc: "Alexander Wels" , "Eldan Hildesheim" > , engine-devel at ovirt.org, "info" > Sent: Friday, November 8, 2013 10:50:10 PM > Subject: Re: [Engine-devel] [UX] how to design a bar/line chart? > > > ----- Original Message ----- > > From: "Ewoud Kohl van Wijngaarden" > > Sent: Thursday, November 7, 2013 11:44:07 AM > > > > On Wed, Nov 06, 2013 at 11:45:36AM -0500, 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. > > > > I'd say no. Even from a reliability point of view since users may have > > systems that aren't connected to the internet. > > +1 > > > (Though I don't know how well oVirt handles this currently.) > > AFAIK - oVirt is handling it ('it' == having no internet connection) well. > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > From mperina at redhat.com Mon Nov 11 10:20:07 2013 From: mperina at redhat.com (Martin Perina) Date: Mon, 11 Nov 2013 05:20:07 -0500 (EST) Subject: [Engine-devel] Fwd: Custom properties per device + vNIC profile = not working (< 3.3) In-Reply-To: <2080457776.29191617.1384163320455.JavaMail.root@redhat.com> References: <1480148973.29121435.1384156173916.JavaMail.root@redhat.com> <1043647659.27242521.1384160190166.JavaMail.root@redhat.com> <391769945.27298763.1384162681266.JavaMail.root@redhat.com> <2080457776.29191617.1384163320455.JavaMail.root@redhat.com> Message-ID: <409907173.27488350.1384165207749.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Mike Kolesnik" > To: "Martin Perina" > Cc: engine-devel at ovirt.org > Sent: Monday, November 11, 2013 10:48:40 AM > Subject: Re: [Engine-devel] Fwd: Custom properties per device + vNIC profile = not working (< 3.3) > > > ----- Original Message ----- > > Hi Mike, > > > > ----- Original Message ----- > > > From: "Mike Kolesnik" > > > To: "engine-devel" > > > Cc: "Barak Azulay" , "Martin Perina" > > > , "Livnat Peer" , > > > "Itamar Heim" > > > Sent: Monday, November 11, 2013 8:49:33 AM > > > Subject: Custom properties per device + vNIC profile = not working (< > > > 3.3) > > > > > > Hi, > > > > > > I came across a situation where I wanted to define custom properties on a > > > vNIC profile sitting under a network in a 3.2 data center. > > > From what I saw the configuration value for custom properties > > > (CustomDeviceProperties) is split into 4, one per each version (3.0, 3.1, > > > 3.2, 3.3). > > > Since vNIC profile is located under the DC tree, it takes the DC version > > > - > > > 3.2 in this specific case. > > > > Custom Device Properties were designed to be specified for each cluster > > version > > independently, it doesn't care about DC version. AFAIK cluster version > > defines > > what features are available ... > > > > > > > > I tried to set the config value for 3.2 but got: > > > $ engine-config -s > > > CustomDeviceProperties="{type=interface;prop={myProp=[a-zA-Z0-9-]+}}" > > > --cver=3.2 > > > Cannot set value {type=interface;prop={myProp=[a-zA-Z0-9-]+}} to key > > > CustomDeviceProperties. Device custom properties are not supported in > > > version 3.2 > > > > > > This is already not very good, since in a 3.2 DC there can be 3.3 > > > clusters > > > with 3.3 hosts that do support custom device properties. > > > > Specify your properties for 3.3 version, since they will be used in 3.3 > > clusters ... > > > > But the effective version is the DC version as I explained. > > In a DC 3.0-3.3 I can have clusters which the minimal version is the DC > version, and the maximal version is 3.3. > For example I can have the following: > DC - version 3.0 > + Cluster 1 - version 3.0 > + Cluster 2 - version 3.1 > + Cluster 3 - version 3.2 > + Cluster 4 - version 3.3 > > In this constellation, I could use custom device properties only on Cluster > 4, but it's not possible to define them since the vNIC profile is using the > DC version 3.0. > So effectively this feature is not usable to me unless I use a 3.3 DC. No, it's not usable for you, because you are not using device custom properties in a way that they were designed. You want to specify custom device properties per DC version (or general version), but they were designed to be specified per cluster level. Because currently currently if you specify properties for cluster version 3.3, they can be used for all clusters with version 3.3 regardless of DC version they are members of ... > > > > > > > I also tried to alter the config value in the DB directly, but the custom > > > properties code ignored it since custom properties are not supported in > > > 3.2. > > > So, de facto, I have no reasonable way as a user to define custom device > > > properties to use for my vNIC profiles in DC < 3.3. > > > > There are two configuration properties for Custom Device Properties: > > > > 1) SupportCustomDeviceProperties > > - defines in what version properties are supported > > - cannot be altered by users of course > > > > 2) CustomDeviceProperties > > - holds properties specification for each version > > - can be defined using engine-config > > > > > > > > I opened the bug https://bugzilla.redhat.com/show_bug.cgi?id=1028757 for > > > this, however I also want to discuss the situation: > > > > I looked at the bug and the problem is, that management network profile > > is bound to DC and not the Cluster. And that's something we never thought > > of > > ... > > > > > > > > 1. As a user, I can't set custom properties for level < 3.3 which is not > > > good. > > > > Well, it's 3.3 feature, so it looks OK for me > > > > > Removing the blocking, and loading custom properties for all versions > > > would > > > fix the bug and allow using custom device properties for older versions, > > > the > > > reasonable place to block this would be running a VM (or plugging a > > > device). > > > Basically this is the lesser issue.. > > > > > > 2. I just don't see the added value of splitting the definition of the > > > properties per level.. > > > > The idea behind the version splitting was: > > > > 1) We have a device with a feature that doesn't work correctly with version > > 3.3, > > but it's fixed in 3.4 > > 2) By specifying custom property per version we cane disable this feature > > for > > 3.3 > > and enable for 3.4 > > Custom properties is not for specifying which features are enabled, there is > a whole other mechanism for that.. > > Custom properties is for hooks (and other possible extensions), which by > definition are not something that is guaranteed to exist so I see no point > to force the user to update multiple configurations and cause confusion for > him.. > > > > > > The custom properties are extensions which might or might not be > > > available > > > to > > > a certain VM, I don't see how having different sets of custom properties > > > per > > > version (what version, DC version, cluster version?) would make any > > > difference - either the VM can utilize the extension given some state of > > > the > > > system, or it can't, but the determining factor is not the version but > > > rather the availability of the extension. > > > For example, I can have a hook for vNIC altering some property installed > > > on > > > host A and not host B, if the VM runs on host A it will get this > > > capability > > > and on host B it won't, regardless the DC version the VM is in. > > > > > > This is not to say we shouldn't block custom properties on the > > > engine-VDSM > > > API level since it's only available since 3.3, but this is handled by > > > another config value (SupportCustomDeviceProperties) which is not > > > alterable > > > by the user. > > > So basically, I think splitting the value per version is over > > > complication > > > and see no added value to the users, just more maintenance should they > > > choose to use this feature. > > > > > > Your thoughts please. > > > > AFAIK only network and storage team wanted to use device custom properties > > in 3.3 version, but I'm not sure what's current usage status. > > > > But IMHO it's too late for 3.3 to change specification ... > > Since I can have cluster 3.3 in a DC < 3.3, and this is the upgrade path for > existing users, > I'd argue that the bug is severe enough and should be fixed asap even for 3.3 > versions. Don't get wrong, we can discuss changes if it's needed. But I don't like the approach to redesign feature when we are at stabilization stage ... No to mention that I noticed today, that there are already patches merged in ovirt-engine-3.3 branch that bypasses device custom properties version handling: http://gerrit.ovirt.org/21032 http://gerrit.ovirt.org/21033 So why didn't you asked for a change earlier? You have to know for a quite time that current custom device properties functionality doesn't suite you needs ... From oliel at redhat.com Mon Nov 11 10:38:46 2013 From: oliel at redhat.com (Ori Liel) Date: Mon, 11 Nov 2013 05:38:46 -0500 (EST) Subject: [Engine-devel] REST-API: Problem with additional DELETE action at collection level In-Reply-To: <5280AAC2.6010805@redhat.com> References: <527C7DDF.2050308@redhat.com> <527C86AA.7010904@redhat.com> <25153947.26941766.1384104968045.JavaMail.root@redhat.com> <5280646F.2050903@redhat.com> <5280AAC2.6010805@redhat.com> Message-ID: <463738104.27509428.1384166326211.JavaMail.root@redhat.com> >----- Original Message ----- >From: "Shubhendu Tripathi" >To: oliel at redhat.com, "Michael Pasternak" , "Sahina Bose" >Cc: "Dusmant Pati" , "engine-devel" >Sent: Monday, November 11, 2013 12:00:34 PM >Subject: Re: [Engine-devel] REST-API: Problem with additional DELETE action at collection level > >Self and Ori had a detailed discussion on the topic. > >Points discussed - > >1. Ori mentioned that Michael and Ori did not mean to have a separate >DELETE action for the purpose of commit in previous discussions. That's right - no need for a new delete signature; existing signatures are enough. >2. Ori tried to understand the intention behind the separate commit >command in gluster and suggested that ideally gluster should remember >that a migration of data is started on the set of bricks, and if there >is a delete fired on the same bricks it should perform a commit action >because commit is nothing but a delete action >3. Ori suggested that in an ideal situation APIs needed would be > - start migrate > - stop migrate > - delete bricks > - retain bricks >4. As suggested by Ori, the remove bricks action should internally >decide if there was a data migration, started on the set of bricks. If >so, it should effectively fire a commit for the set of bricks. And if >there was not occurrence of data migration it should behave like a >normal force remove action. > >Ori, please add your comments if I have missed out anything here. I agree with what you wrote, let me sort of say it again in my words: I don't like requiring two consecutive commands from the API user, to perform migrate. If the user only does 'migrate', and doesn't do the second step, we are in a state of corruption. But Shubhendu explained to me that there's no way around this; the administrator *must* take a look and decide; it is simply not possible to make this decision in advance. So I accepted this heavy-heartedly. Then we were left with the decision of how to model this two step operation. I tried to look at it from the point of view of the user; what would be the simplest way to 'tell him the story?' - If you want to migrate a brick, run 'migrate' on it. - If you want to stop migration of the brick, run 'stopMigrate' on it. - If you want to resume the migration of the brick, simply run 'migrate' on it again. After migration is done: - if you want to remove the brick, DELETE it (regular delete). - if you want to keep using the brick, run 'reactivate' on it. And that's the whole story. The advantages are: * In simple English, not bound to Gluster terms, the administrator has to decide whether to get rid of the brick, remove it, when migration is done. So what would be more natural than to delete it? It makes sense, and there's no need for a new 'action'. On the Gluster side, if user tried to delete a brick which is undergoing migration - simply don't allow it. This is something you have to do anyway; a user might try to delete a brick which is undergoing migration and you have to stop him from doing so. So 0 extra work here. * Instead of stopMigrate meaning two different things in two different contexts, we now have stopMigration mean exactly what its name suggests: it stops the migration, and 'reactive' mean exactly what it suggests - mark this brick as active again, allow it to be used. > >Sahina, request your comments on the same. > >Thanks and Regards, >Shubhendu On 11/11/2013 10:30 AM, Shubhendu Tripathi wrote: > On 11/10/2013 11:06 PM, Moti Asayag wrote: >> >> ----- Original Message ----- >>> From: "Shubhendu Tripathi" >>> To: "engine-devel" , "Michael Pasternak" >>> , oliel at redhat.com >>> Sent: Friday, November 8, 2013 8:37:30 AM >>> Subject: [Engine-devel] REST-API: Problem with additional DELETE >>> action at collection level >>> >>> Hi All, >>> >>> There is a DELETE action defined at collection level for Gluster >>> Bricks with >>> signature - >>> >>> @DELETE >>> public Response remove ( GlusterBricks bricks ); >>> >>> Recently we had needed a commit action to remove migrated bricks. >>> After multiple rounds of discussion on introducing a commit action >>> to remove >>> migrated bricks we introduced a DELETE action [1] which accepts a >>> boolean >>> parameter isForce. >>> If the parameter is set to true , forced deletion of bricks happens >>> without >>> any data migration. >>> And if the parameter is not set or set to false, the deletion is >>> meant for a >>> brick on which migration has already taken place. >>> >>> To achieve the above functionality we introduced another DELETE >>> action with >>> new signature as below and also marked the first action as deprecated - >>> >>> @DELETE >>> public Response remove ( Action action ); >>> >>> The problem arises now as the new api works fine for all possible >>> scenarios >>> with below input structure - >>> >>> >>> true/false >>> >>> >>> brick1-name >>> brick2-name >>> >>> >>> >>> >>> BUT after these change backward compatibility is broken and the old >>> api does >>> not work. >>> If we try invoking old DELETE with bricks as input parameter as >>> below, it >>> still invokes the new api and gives an error saying " Invalid >>> parameter ". >>> >> Maybe I've missed it some where, but i wasn't able to find the new >> 'force' parameter >> in the rsdl, and specifically not in optionalArguments list of: >> >> - name: >> /api/clusters/{cluster:id}/glustervolumes/{glustervolume:id}/bricks|rel=delete >> >> and perhaps the correct approach will be to deprecate this signature >> and introduce a new >> one with the 'force' in the 'mandatoryArguments' section. > Moti, I have introduced another methods remove of DELETE type which > takes Action as input. > I pass list of bricks and force as parameter in the same Action. > > Also, I tried marking the old method deprecated and introduced the new > one BUT as mentioned above, after introduction of new DELETE with > Action parameter old one STOPS working. > Is it OK to stop working for a method if its deprecated?? I don't feel > so. Please comment. >> >>> >>> >>> >>> >>> >>> Kindly suggest a solution around the same. >>> >>> PS: Both the actions are defined at collection level ( >>> /api/clusters//glustervolumes//bricks ) >>> >>> [1]: http://gerrit.ovirt.org/#/c/21043/ >>> >>> Thanks and Regards, >>> Shubhendu >>> >>> >>> >>> >>> >>> _______________________________________________ >>> Engine-devel mailing list >>> Engine-devel at ovirt.org >>> http://lists.ovirt.org/mailman/listinfo/engine-devel >>> > > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > > From shtripat at redhat.com Mon Nov 11 11:03:53 2013 From: shtripat at redhat.com (Shubhendu Tripathi) Date: Mon, 11 Nov 2013 16:33:53 +0530 Subject: [Engine-devel] REST-API: Problem with additional DELETE action at collection level In-Reply-To: <463738104.27509428.1384166326211.JavaMail.root@redhat.com> References: <527C7DDF.2050308@redhat.com> <527C86AA.7010904@redhat.com> <25153947.26941766.1384104968045.JavaMail.root@redhat.com> <5280646F.2050903@redhat.com> <5280AAC2.6010805@redhat.com> <463738104.27509428.1384166326211.JavaMail.root@redhat.com> Message-ID: <5280B999.6000605@redhat.com> On 11/11/2013 04:08 PM, Ori Liel wrote: >> ----- Original Message ----- >> From: "Shubhendu Tripathi" >> To: oliel at redhat.com, "Michael Pasternak" , "Sahina Bose" >> Cc: "Dusmant Pati" , "engine-devel" >> Sent: Monday, November 11, 2013 12:00:34 PM >> Subject: Re: [Engine-devel] REST-API: Problem with additional DELETE action at collection level >> >> Self and Ori had a detailed discussion on the topic. >> >> Points discussed - >> >> 1. Ori mentioned that Michael and Ori did not mean to have a separate >> DELETE action for the purpose of commit in previous discussions. > That's right - no need for a new delete signature; existing signatures are enough. > >> 2. Ori tried to understand the intention behind the separate commit >> command in gluster and suggested that ideally gluster should remember >> that a migration of data is started on the set of bricks, and if there >> is a delete fired on the same bricks it should perform a commit action >> because commit is nothing but a delete action >> 3. Ori suggested that in an ideal situation APIs needed would be >> - start migrate >> - stop migrate >> - delete bricks >> - retain bricks >> 4. As suggested by Ori, the remove bricks action should internally >> decide if there was a data migration, started on the set of bricks. If >> so, it should effectively fire a commit for the set of bricks. And if >> there was not occurrence of data migration it should behave like a >> normal force remove action. >> >> Ori, please add your comments if I have missed out anything here. > I agree with what you wrote, let me sort of say it again in my words: > > I don't like requiring two consecutive commands from the API user, to perform migrate. > If the user only does 'migrate', and doesn't do the second step, we are in a state of > corruption. But Shubhendu explained to me that there's no way around this; the > administrator *must* take a look and decide; it is simply not possible to make this > decision in advance. So I accepted this heavy-heartedly. > > Then we were left with the decision of how to model this two step operation. I tried to > look at it from the point of view of the user; what would be the simplest way to 'tell him > the story?' > > - If you want to migrate a brick, run 'migrate' on it. > - If you want to stop migration of the brick, run 'stopMigrate' on it. > - If you want to resume the migration of the brick, simply run 'migrate' on it again. > After migration is done: > - if you want to remove the brick, DELETE it (regular delete). > - if you want to keep using the brick, run 'reactivate' on it. > > And that's the whole story. > > The advantages are: > > * In simple English, not bound to Gluster terms, the administrator has to decide whether to > get rid of the brick, remove it, when migration is done. So what would be more natural than > to delete it? It makes sense, and there's no need for a new 'action'. On the Gluster side, > if user tried to delete a brick which is undergoing migration - simply don't allow it. This > is something you have to do anyway; a user might try to delete a brick which is undergoing > migration and you have to stop him from doing so. So 0 extra work here. > > * Instead of stopMigrate meaning two different things in two different contexts, we now > have stopMigration mean exactly what its name suggests: it stops the migration, and 'reactive' > mean exactly what it suggests - mark this brick as active again, allow it to be used. Thanks Ori for the detailed mail. So now the final set of APIs are - - migrate - stopmigrate - delete (existing delete to be enabled for commit) - reactivate Will go ahead with this and raise the patches accordingly. Thanks and Regards, Shubhendu >> Sahina, request your comments on the same. >> >> Thanks and Regards, >> Shubhendu > On 11/11/2013 10:30 AM, Shubhendu Tripathi wrote: >> On 11/10/2013 11:06 PM, Moti Asayag wrote: >>> ----- Original Message ----- >>>> From: "Shubhendu Tripathi" >>>> To: "engine-devel" , "Michael Pasternak" >>>> , oliel at redhat.com >>>> Sent: Friday, November 8, 2013 8:37:30 AM >>>> Subject: [Engine-devel] REST-API: Problem with additional DELETE >>>> action at collection level >>>> >>>> Hi All, >>>> >>>> There is a DELETE action defined at collection level for Gluster >>>> Bricks with >>>> signature - >>>> >>>> @DELETE >>>> public Response remove ( GlusterBricks bricks ); >>>> >>>> Recently we had needed a commit action to remove migrated bricks. >>>> After multiple rounds of discussion on introducing a commit action >>>> to remove >>>> migrated bricks we introduced a DELETE action [1] which accepts a >>>> boolean >>>> parameter isForce. >>>> If the parameter is set to true , forced deletion of bricks happens >>>> without >>>> any data migration. >>>> And if the parameter is not set or set to false, the deletion is >>>> meant for a >>>> brick on which migration has already taken place. >>>> >>>> To achieve the above functionality we introduced another DELETE >>>> action with >>>> new signature as below and also marked the first action as deprecated - >>>> >>>> @DELETE >>>> public Response remove ( Action action ); >>>> >>>> The problem arises now as the new api works fine for all possible >>>> scenarios >>>> with below input structure - >>>> >>>> >>>> true/false >>>> >>>> >>>> brick1-name >>>> brick2-name >>>> >>>> >>>> >>>> >>>> BUT after these change backward compatibility is broken and the old >>>> api does >>>> not work. >>>> If we try invoking old DELETE with bricks as input parameter as >>>> below, it >>>> still invokes the new api and gives an error saying " Invalid >>>> parameter ". >>>> >>> Maybe I've missed it some where, but i wasn't able to find the new >>> 'force' parameter >>> in the rsdl, and specifically not in optionalArguments list of: >>> >>> - name: >>> /api/clusters/{cluster:id}/glustervolumes/{glustervolume:id}/bricks|rel=delete >>> >>> and perhaps the correct approach will be to deprecate this signature >>> and introduce a new >>> one with the 'force' in the 'mandatoryArguments' section. >> Moti, I have introduced another methods remove of DELETE type which >> takes Action as input. >> I pass list of bricks and force as parameter in the same Action. >> >> Also, I tried marking the old method deprecated and introduced the new >> one BUT as mentioned above, after introduction of new DELETE with >> Action parameter old one STOPS working. >> Is it OK to stop working for a method if its deprecated?? I don't feel >> so. Please comment. >>>> >>>> >>>> >>>> >>>> >>>> Kindly suggest a solution around the same. >>>> >>>> PS: Both the actions are defined at collection level ( >>>> /api/clusters//glustervolumes//bricks ) >>>> >>>> [1]: http://gerrit.ovirt.org/#/c/21043/ >>>> >>>> Thanks and Regards, >>>> Shubhendu >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> Engine-devel mailing list >>>> Engine-devel at ovirt.org >>>> http://lists.ovirt.org/mailman/listinfo/engine-devel >>>> >> _______________________________________________ >> Engine-devel mailing list >> Engine-devel at ovirt.org >> http://lists.ovirt.org/mailman/listinfo/engine-devel >> >> > > From ehildesh at redhat.com Mon Nov 11 12:33:23 2013 From: ehildesh at redhat.com (Eldan Hildesheim) Date: Mon, 11 Nov 2013 07:33:23 -0500 (EST) Subject: [Engine-devel] [UX] how to design a bar/line chart? In-Reply-To: <1307970395.21470536.1384164195241.JavaMail.root@redhat.com> References: <157528892.18409921.1383645002815.JavaMail.root@redhat.com> <10671894.E7RLZxpxmS@awels> <845594321.17693417.1383753786397.JavaMail.root@redhat.com> <4799215.PFXHvLDZXl@awels> <20131107164407.GB31469@bogey.xentower.nl> <312159812.23706941.1383943810196.JavaMail.root@redhat.com> <1591156023.26916611.1384095417884.JavaMail.root@redhat.com> <1307970395.21470536.1384164195241.JavaMail.root@redhat.com> Message-ID: <827048560.27692438.1384173203565.JavaMail.root@redhat.com> I will try to make an animation. ----- Original Message ----- From: "Tomas Jelinek" To: "Eldan Hildesheim" Cc: "Einav Cohen" , "info" , engine-devel at ovirt.org Sent: Monday, November 11, 2013 12:03:15 PM Subject: Re: [Engine-devel] [UX] how to design a bar/line chart? ----- Original Message ----- > From: "Eldan Hildesheim" > To: "Einav Cohen" > Cc: "info" , engine-devel at ovirt.org > Sent: Sunday, November 10, 2013 3:56:57 PM > Subject: Re: [Engine-devel] [UX] how to design a bar/line chart? > > Hello all, > We use to have a good solution in the period pre-WPF. > A line chart (used to be in flash) that works like a plotter: > The Line Bar (not bar) had a small animation that shifted all the bar to the > left. > When a new data arrived it just added a new line (to the right) and as I said > before, in parallel it always shifted slowly to the left. Any chance you still have some screenshot or mockup so I can imagine it better? > The animation gives the impression that data is streaming and when a real new > data arrives the user gets it very fast. > We have to sync between the animation and the rate of the arrival of the data > but this is easy. > If we can't find a good framework it can be created from scratch with JS, svg > or canvas. We need to be careful about what we will use. oVirt is supposed to work on FF 17 [1] but the HTML5 canvas works only since FF23 [2]. @Einav: Is there a chance that we could start support only FF23+ and IE9+ (this one is already OK) because of this feature? > Now regarding its position: > Rollover is good but not enough, we should somehow put it in the lower panel > under general or even another tab - (live data). This is a bit different requirement. The point of this specific is to give a better overview in the main tab. If it will be done we can decide if we want to give more details in sub tabs. > We could later on have a (live data Tab) in other places as well like host, > cluster... > Eldan [1]: http://www.ovirt.org/Download [2]: http://caniuse.com/#feat=canvas > > ----- Original Message ----- > From: "Einav Cohen" > To: "Ewoud Kohl van Wijngaarden" > Cc: "Alexander Wels" , "Eldan Hildesheim" > , engine-devel at ovirt.org, "info" > Sent: Friday, November 8, 2013 10:50:10 PM > Subject: Re: [Engine-devel] [UX] how to design a bar/line chart? > > > ----- Original Message ----- > > From: "Ewoud Kohl van Wijngaarden" > > Sent: Thursday, November 7, 2013 11:44:07 AM > > > > On Wed, Nov 06, 2013 at 11:45:36AM -0500, 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. > > > > I'd say no. Even from a reliability point of view since users may have > > systems that aren't connected to the internet. > > +1 > > > (Though I don't know how well oVirt handles this currently.) > > AFAIK - oVirt is handling it ('it' == having no internet connection) well. > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > -------------- next part -------------- A non-text attachment was scrubbed... Name: bar_chart.jpg Type: image/jpeg Size: 10042 bytes Desc: not available URL: From ehildesh at redhat.com Mon Nov 11 13:01:07 2013 From: ehildesh at redhat.com (Eldan Hildesheim) Date: Mon, 11 Nov 2013 08:01:07 -0500 (EST) Subject: [Engine-devel] [UX] how to design a bar/line chart? In-Reply-To: <1307970395.21470536.1384164195241.JavaMail.root@redhat.com> References: <157528892.18409921.1383645002815.JavaMail.root@redhat.com> <10671894.E7RLZxpxmS@awels> <845594321.17693417.1383753786397.JavaMail.root@redhat.com> <4799215.PFXHvLDZXl@awels> <20131107164407.GB31469@bogey.xentower.nl> <312159812.23706941.1383943810196.JavaMail.root@redhat.com> <1591156023.26916611.1384095417884.JavaMail.root@redhat.com> <1307970395.21470536.1384164195241.JavaMail.root@redhat.com> Message-ID: <12476140.27720889.1384174867933.JavaMail.root@redhat.com> Throw this gif into a browser. This is more or less what I thought. Eldan ----- Original Message ----- From: "Tomas Jelinek" To: "Eldan Hildesheim" Cc: "Einav Cohen" , "info" , engine-devel at ovirt.org Sent: Monday, November 11, 2013 12:03:15 PM Subject: Re: [Engine-devel] [UX] how to design a bar/line chart? ----- Original Message ----- > From: "Eldan Hildesheim" > To: "Einav Cohen" > Cc: "info" , engine-devel at ovirt.org > Sent: Sunday, November 10, 2013 3:56:57 PM > Subject: Re: [Engine-devel] [UX] how to design a bar/line chart? > > Hello all, > We use to have a good solution in the period pre-WPF. > A line chart (used to be in flash) that works like a plotter: > The Line Bar (not bar) had a small animation that shifted all the bar to the > left. > When a new data arrived it just added a new line (to the right) and as I said > before, in parallel it always shifted slowly to the left. Any chance you still have some screenshot or mockup so I can imagine it better? > The animation gives the impression that data is streaming and when a real new > data arrives the user gets it very fast. > We have to sync between the animation and the rate of the arrival of the data > but this is easy. > If we can't find a good framework it can be created from scratch with JS, svg > or canvas. We need to be careful about what we will use. oVirt is supposed to work on FF 17 [1] but the HTML5 canvas works only since FF23 [2]. @Einav: Is there a chance that we could start support only FF23+ and IE9+ (this one is already OK) because of this feature? > Now regarding its position: > Rollover is good but not enough, we should somehow put it in the lower panel > under general or even another tab - (live data). This is a bit different requirement. The point of this specific is to give a better overview in the main tab. If it will be done we can decide if we want to give more details in sub tabs. > We could later on have a (live data Tab) in other places as well like host, > cluster... > Eldan [1]: http://www.ovirt.org/Download [2]: http://caniuse.com/#feat=canvas > > ----- Original Message ----- > From: "Einav Cohen" > To: "Ewoud Kohl van Wijngaarden" > Cc: "Alexander Wels" , "Eldan Hildesheim" > , engine-devel at ovirt.org, "info" > Sent: Friday, November 8, 2013 10:50:10 PM > Subject: Re: [Engine-devel] [UX] how to design a bar/line chart? > > > ----- Original Message ----- > > From: "Ewoud Kohl van Wijngaarden" > > Sent: Thursday, November 7, 2013 11:44:07 AM > > > > On Wed, Nov 06, 2013 at 11:45:36AM -0500, 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. > > > > I'd say no. Even from a reliability point of view since users may have > > systems that aren't connected to the internet. > > +1 > > > (Though I don't know how well oVirt handles this currently.) > > AFAIK - oVirt is handling it ('it' == having no internet connection) well. > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > -------------- next part -------------- A non-text attachment was scrubbed... Name: bar_graph_ani.gif Type: image/gif Size: 26620 bytes Desc: not available URL: From iheim at redhat.com Mon Nov 11 12:18:26 2013 From: iheim at redhat.com (Itamar Heim) Date: Mon, 11 Nov 2013 14:18:26 +0200 Subject: [Engine-devel] Permissions involved in using REST API In-Reply-To: <20131107172027.GA58872@galois.com> References: <20131106233401.GG73898@galois.com> <307109400.18301343.1383812802255.JavaMail.root@redhat.com> <20131107172027.GA58872@galois.com> Message-ID: <5280CB12.40505@redhat.com> On 11/07/2013 07:20 PM, Jonathan Daugherty wrote: >>> - Is this expected behavior? Is there some smaller (less >>> permissive) change in privileges I can use to bring about the same >>> behavior? >>> >> >> Yes. That's the expected behavior. However, when accessing the API you >> can set the "filter" header parameter to "true", and that will get you >> to the user-level API. Let me know if you need technical assistance >> with that. > > Thanks! The Filter header works for me. > > While it's good to have some means of controlling which users can access > the API, I think that the current means is very misleading and alarming. > It's misleading because it presumes I think admin users are the only > ones who should access the API (I don't) and it is alarming because if I > have to set the admin bit on users to let them do this, I'm not sure > whether I'm inadvertently granting them rights to do other things (I > don't want to). In any case it certainly isn't how I would imagine some > people think about this sort of use case; for example, if I want my > Jenkins CI system to be able to talk to oVirt via the API, I don't think > of that as administrative access. > > I would love to see a new permission checkbox added, e.g., "REST API > access", which I could check or uncheck on a per-user or per-group > basis. Unfortunately I can't volunteer to do this work myself and even > if I could it isn't yet clear whether such a new feature somehow > conflicts with other design decisions the engine developers have made. > > So now my next question is: if I create an admin account without any > privileges as I have described, are there any hidden privileges other > than API access which I need to know that user has? the main difference between an 'admin' and a 'user' is that admin has read-only permission to see all objects in the system, and a user can only see objects they have permissions on. the 'right' way should have been that the default access would be for user mode, and an admin would have to set 'admin:true' rather than user set 'filter:true'. but admin api pre-dates user mode, and we didn't want to break backward compatibility. michael/juan - thoughts on how to make this more, well, sensible? From iheim at redhat.com Mon Nov 11 12:32:46 2013 From: iheim at redhat.com (Itamar Heim) Date: Mon, 11 Nov 2013 14:32:46 +0200 Subject: [Engine-devel] Fwd: Custom properties per device + vNIC profile = not working (< 3.3) In-Reply-To: <2080457776.29191617.1384163320455.JavaMail.root@redhat.com> References: <1480148973.29121435.1384156173916.JavaMail.root@redhat.com> <1043647659.27242521.1384160190166.JavaMail.root@redhat.com> <391769945.27298763.1384162681266.JavaMail.root@redhat.com> <2080457776.29191617.1384163320455.JavaMail.root@redhat.com> Message-ID: <5280CE6E.1060608@redhat.com> On 11/11/2013 11:48 AM, Mike Kolesnik wrote: > > ----- Original Message ----- >> Hi Mike, >> >> ----- Original Message ----- >>> From: "Mike Kolesnik" >>> To: "engine-devel" >>> Cc: "Barak Azulay" , "Martin Perina" >>> , "Livnat Peer" , >>> "Itamar Heim" >>> Sent: Monday, November 11, 2013 8:49:33 AM >>> Subject: Custom properties per device + vNIC profile = not working (< 3.3) >>> >>> Hi, >>> >>> I came across a situation where I wanted to define custom properties on a >>> vNIC profile sitting under a network in a 3.2 data center. >>> From what I saw the configuration value for custom properties >>> (CustomDeviceProperties) is split into 4, one per each version (3.0, 3.1, >>> 3.2, 3.3). >>> Since vNIC profile is located under the DC tree, it takes the DC version - >>> 3.2 in this specific case. >> >> Custom Device Properties were designed to be specified for each cluster >> version >> independently, it doesn't care about DC version. AFAIK cluster version >> defines >> what features are available ... >> >>> >>> I tried to set the config value for 3.2 but got: >>> $ engine-config -s >>> CustomDeviceProperties="{type=interface;prop={myProp=[a-zA-Z0-9-]+}}" >>> --cver=3.2 >>> Cannot set value {type=interface;prop={myProp=[a-zA-Z0-9-]+}} to key >>> CustomDeviceProperties. Device custom properties are not supported in >>> version 3.2 >>> >>> This is already not very good, since in a 3.2 DC there can be 3.3 clusters >>> with 3.3 hosts that do support custom device properties. >> >> Specify your properties for 3.3 version, since they will be used in 3.3 >> clusters ... >> > > But the effective version is the DC version as I explained. > > In a DC 3.0-3.3 I can have clusters which the minimal version is the DC version, and the maximal version is 3.3. > For example I can have the following: > DC - version 3.0 > + Cluster 1 - version 3.0 > + Cluster 2 - version 3.1 > + Cluster 3 - version 3.2 > + Cluster 4 - version 3.3 > > In this constellation, I could use custom device properties only on Cluster 4, but it's not possible to define them since the vNIC profile is using the DC version 3.0. > So effectively this feature is not usable to me unless I use a 3.3 DC. > >>> >>> I also tried to alter the config value in the DB directly, but the custom >>> properties code ignored it since custom properties are not supported in >>> 3.2. >>> So, de facto, I have no reasonable way as a user to define custom device >>> properties to use for my vNIC profiles in DC < 3.3. >> >> There are two configuration properties for Custom Device Properties: >> >> 1) SupportCustomDeviceProperties >> - defines in what version properties are supported >> - cannot be altered by users of course >> >> 2) CustomDeviceProperties >> - holds properties specification for each version >> - can be defined using engine-config >> >>> >>> I opened the bug https://bugzilla.redhat.com/show_bug.cgi?id=1028757 for >>> this, however I also want to discuss the situation: >> >> I looked at the bug and the problem is, that management network profile >> is bound to DC and not the Cluster. And that's something we never thought of >> ... >> >>> >>> 1. As a user, I can't set custom properties for level < 3.3 which is not >>> good. >> >> Well, it's 3.3 feature, so it looks OK for me >> >>> Removing the blocking, and loading custom properties for all versions would >>> fix the bug and allow using custom device properties for older versions, >>> the >>> reasonable place to block this would be running a VM (or plugging a >>> device). >>> Basically this is the lesser issue.. >>> >>> 2. I just don't see the added value of splitting the definition of the >>> properties per level.. >> >> The idea behind the version splitting was: >> >> 1) We have a device with a feature that doesn't work correctly with version >> 3.3, >> but it's fixed in 3.4 >> 2) By specifying custom property per version we cane disable this feature for >> 3.3 >> and enable for 3.4 > > Custom properties is not for specifying which features are enabled, there is a whole other mechanism for that.. > > Custom properties is for hooks (and other possible extensions), which by definition are not something that is guaranteed to exist so I see no point to force the user to update multiple configurations and cause confusion for him.. as martin explained, we have predefined custom properties, which are based on the vdsm version, and hence are actually features we know to expose or not to expose. user-defined custom properties - are up to the admin, but we let these be at cluster level as well to allow more granularity. > >> >>> The custom properties are extensions which might or might not be available >>> to >>> a certain VM, I don't see how having different sets of custom properties >>> per >>> version (what version, DC version, cluster version?) would make any >>> difference - either the VM can utilize the extension given some state of >>> the >>> system, or it can't, but the determining factor is not the version but >>> rather the availability of the extension. >>> For example, I can have a hook for vNIC altering some property installed on >>> host A and not host B, if the VM runs on host A it will get this capability >>> and on host B it won't, regardless the DC version the VM is in. >>> >>> This is not to say we shouldn't block custom properties on the engine-VDSM >>> API level since it's only available since 3.3, but this is handled by >>> another config value (SupportCustomDeviceProperties) which is not alterable >>> by the user. >>> So basically, I think splitting the value per version is over complication >>> and see no added value to the users, just more maintenance should they >>> choose to use this feature. >>> >>> Your thoughts please. >> >> AFAIK only network and storage team wanted to use device custom properties >> in 3.3 version, but I'm not sure what's current usage status. >> >> But IMHO it's too late for 3.3 to change specification ... > > Since I can have cluster 3.3 in a DC < 3.3, and this is the upgrade path for existing users, > I'd argue that the bug is severe enough and should be fixed asap even for 3.3 versions. please note that if you expose this at cluster level and not DC level, you need to make sure to verify it when moving a VM between clusters in same DC. also, if this is somehow related to logical networks, not vnic specific, than logical networks are DC level entities. From ecohen at redhat.com Mon Nov 11 15:13:13 2013 From: ecohen at redhat.com (Einav Cohen) Date: Mon, 11 Nov 2013 10:13:13 -0500 (EST) Subject: [Engine-devel] [UX] how to design a bar/line chart? In-Reply-To: <1307970395.21470536.1384164195241.JavaMail.root@redhat.com> References: <157528892.18409921.1383645002815.JavaMail.root@redhat.com> <10671894.E7RLZxpxmS@awels> <845594321.17693417.1383753786397.JavaMail.root@redhat.com> <4799215.PFXHvLDZXl@awels> <20131107164407.GB31469@bogey.xentower.nl> <312159812.23706941.1383943810196.JavaMail.root@redhat.com> <1591156023.26916611.1384095417884.JavaMail.root@redhat.com> <1307970395.21470536.1384164195241.JavaMail.root@redhat.com> Message-ID: <1467962025.812771.1384182793453.JavaMail.root@redhat.com> > @Einav: > Is there a chance that we could start support only FF23+ and IE9+ (this one > is already OK) > because of this feature? According to [1], FF17 EOL is expected to be at the beginning of December 2013. >From this point on, I don't think that there is a reason that we should "support" FF17 - we will probably move to "supporting" FF24, which is the next/current ESR (other users can correct me if I am wrong - maybe I am missing something). Need to keep in mind that in the user portal we are still being "friendly" to IE8 users, so as long as our plans for this feature (at least for the near future) are for the web-admin only, we are good. [1] http://en.wikipedia.org/wiki/Firefox_release_history ----- Original Message ----- > From: "Tomas Jelinek" > To: "Eldan Hildesheim" > Cc: "Einav Cohen" , "info" , engine-devel at ovirt.org > Sent: Monday, November 11, 2013 5:03:15 AM > Subject: Re: [Engine-devel] [UX] how to design a bar/line chart? > > > > ----- Original Message ----- > > From: "Eldan Hildesheim" > > To: "Einav Cohen" > > Cc: "info" , engine-devel at ovirt.org > > Sent: Sunday, November 10, 2013 3:56:57 PM > > Subject: Re: [Engine-devel] [UX] how to design a bar/line chart? > > > > Hello all, > > We use to have a good solution in the period pre-WPF. > > A line chart (used to be in flash) that works like a plotter: > > The Line Bar (not bar) had a small animation that shifted all the bar to > > the > > left. > > When a new data arrived it just added a new line (to the right) and as I > > said > > before, in parallel it always shifted slowly to the left. > > Any chance you still have some screenshot or mockup so I can imagine it > better? > > > The animation gives the impression that data is streaming and when a real > > new > > data arrives the user gets it very fast. > > We have to sync between the animation and the rate of the arrival of the > > data > > but this is easy. > > If we can't find a good framework it can be created from scratch with JS, > > svg > > or canvas. > > We need to be careful about what we will use. oVirt is supposed to work on FF > 17 [1] > but the HTML5 canvas works only since FF23 [2]. > > @Einav: > Is there a chance that we could start support only FF23+ and IE9+ (this one > is already OK) > because of this feature? > > > Now regarding its position: > > Rollover is good but not enough, we should somehow put it in the lower > > panel > > under general or even another tab - (live data). > > This is a bit different requirement. The point of this specific is to give a > better > overview in the main tab. If it will be done we can decide if we want to give > more > details in sub tabs. > > > We could later on have a (live data Tab) in other places as well like host, > > cluster... > > Eldan > > [1]: http://www.ovirt.org/Download > [2]: http://caniuse.com/#feat=canvas > > > > > ----- Original Message ----- > > From: "Einav Cohen" > > To: "Ewoud Kohl van Wijngaarden" > > Cc: "Alexander Wels" , "Eldan Hildesheim" > > , engine-devel at ovirt.org, "info" > > Sent: Friday, November 8, 2013 10:50:10 PM > > Subject: Re: [Engine-devel] [UX] how to design a bar/line chart? > > > > > ----- Original Message ----- > > > From: "Ewoud Kohl van Wijngaarden" > > > Sent: Thursday, November 7, 2013 11:44:07 AM > > > > > > On Wed, Nov 06, 2013 at 11:45:36AM -0500, 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. > > > > > > I'd say no. Even from a reliability point of view since users may have > > > systems that aren't connected to the internet. > > > > +1 > > > > > (Though I don't know how well oVirt handles this currently.) > > > > AFAIK - oVirt is handling it ('it' == having no internet connection) well. > > _______________________________________________ > > Engine-devel mailing list > > Engine-devel at ovirt.org > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > From mrao at redhat.com Mon Nov 11 15:15:50 2013 From: mrao at redhat.com (Malini Rao) Date: Mon, 11 Nov 2013 10:15:50 -0500 (EST) Subject: [Engine-devel] [UX] how to design a bar/line chart? In-Reply-To: <12476140.27720889.1384174867933.JavaMail.root@redhat.com> References: <157528892.18409921.1383645002815.JavaMail.root@redhat.com> <845594321.17693417.1383753786397.JavaMail.root@redhat.com> <4799215.PFXHvLDZXl@awels> <20131107164407.GB31469@bogey.xentower.nl> <312159812.23706941.1383943810196.JavaMail.root@redhat.com> <1591156023.26916611.1384095417884.JavaMail.root@redhat.com> <1307970395.21470536.1384164195241.JavaMail.root@redhat.com> <12476140.27720889.1384174867933.JavaMail.root@redhat.com> Message-ID: <272602576.20237573.1384182950117.JavaMail.root@redhat.com> Is this going to fit in a row of a table? Or are we talking of a more detailed view? ----- Original Message ----- From: "Eldan Hildesheim" To: "Tomas Jelinek" Cc: "info" , engine-devel at ovirt.org Sent: Monday, November 11, 2013 8:01:07 AM Subject: Re: [Engine-devel] [UX] how to design a bar/line chart? Throw this gif into a browser. This is more or less what I thought. Eldan ----- Original Message ----- From: "Tomas Jelinek" To: "Eldan Hildesheim" Cc: "Einav Cohen" , "info" , engine-devel at ovirt.org Sent: Monday, November 11, 2013 12:03:15 PM Subject: Re: [Engine-devel] [UX] how to design a bar/line chart? ----- Original Message ----- > From: "Eldan Hildesheim" > To: "Einav Cohen" > Cc: "info" , engine-devel at ovirt.org > Sent: Sunday, November 10, 2013 3:56:57 PM > Subject: Re: [Engine-devel] [UX] how to design a bar/line chart? > > Hello all, > We use to have a good solution in the period pre-WPF. > A line chart (used to be in flash) that works like a plotter: > The Line Bar (not bar) had a small animation that shifted all the bar to the > left. > When a new data arrived it just added a new line (to the right) and as I said > before, in parallel it always shifted slowly to the left. Any chance you still have some screenshot or mockup so I can imagine it better? > The animation gives the impression that data is streaming and when a real new > data arrives the user gets it very fast. > We have to sync between the animation and the rate of the arrival of the data > but this is easy. > If we can't find a good framework it can be created from scratch with JS, svg > or canvas. We need to be careful about what we will use. oVirt is supposed to work on FF 17 [1] but the HTML5 canvas works only since FF23 [2]. @Einav: Is there a chance that we could start support only FF23+ and IE9+ (this one is already OK) because of this feature? > Now regarding its position: > Rollover is good but not enough, we should somehow put it in the lower panel > under general or even another tab - (live data). This is a bit different requirement. The point of this specific is to give a better overview in the main tab. If it will be done we can decide if we want to give more details in sub tabs. > We could later on have a (live data Tab) in other places as well like host, > cluster... > Eldan [1]: http://www.ovirt.org/Download [2]: http://caniuse.com/#feat=canvas > > ----- Original Message ----- > From: "Einav Cohen" > To: "Ewoud Kohl van Wijngaarden" > Cc: "Alexander Wels" , "Eldan Hildesheim" > , engine-devel at ovirt.org, "info" > Sent: Friday, November 8, 2013 10:50:10 PM > Subject: Re: [Engine-devel] [UX] how to design a bar/line chart? > > > ----- Original Message ----- > > From: "Ewoud Kohl van Wijngaarden" > > Sent: Thursday, November 7, 2013 11:44:07 AM > > > > On Wed, Nov 06, 2013 at 11:45:36AM -0500, 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. > > > > I'd say no. Even from a reliability point of view since users may have > > systems that aren't connected to the internet. > > +1 > > > (Though I don't know how well oVirt handles this currently.) > > AFAIK - oVirt is handling it ('it' == having no internet connection) well. > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > _______________________________________________ Engine-devel mailing list Engine-devel at ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel From ecohen at redhat.com Mon Nov 11 15:18:12 2013 From: ecohen at redhat.com (Einav Cohen) Date: Mon, 11 Nov 2013 10:18:12 -0500 (EST) Subject: [Engine-devel] IMP: Regarding an issue while translating the error messages for gluster using ErrorTranslator class In-Reply-To: <527DFB60.6020709@redhat.com> References: <527A14E6.8010809@redhat.com> <2115335.RGeYIF2D09@awels> <1082228530.20856483.1383747009016.JavaMail.root@redhat.com> <527DFB60.6020709@redhat.com> Message-ID: <1134168809.817930.1384183092189.JavaMail.root@redhat.com> > ----- Original Message ----- > From: "Shubhendu Tripathi" > Sent: Saturday, November 9, 2013 4:07:44 AM > > On 11/06/2013 07:40 PM, Einav Cohen wrote: > >> ----- 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). > There is an upstream patch according to Einav's suggestion above. > http://gerrit.ovirt.org/#/c/21083/ Many thanks, Shubhendu. @Derez - any chance that you can take a look (as you probably understand best this particular code/logic)? > > > > >> 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 at ovirt.org > >> http://lists.ovirt.org/mailman/listinfo/engine-devel > >> > > > > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > From tjelinek at redhat.com Mon Nov 11 15:23:09 2013 From: tjelinek at redhat.com (Tomas Jelinek) Date: Mon, 11 Nov 2013 10:23:09 -0500 (EST) Subject: [Engine-devel] [UX] how to design a bar/line chart? In-Reply-To: <272602576.20237573.1384182950117.JavaMail.root@redhat.com> References: <157528892.18409921.1383645002815.JavaMail.root@redhat.com> <4799215.PFXHvLDZXl@awels> <20131107164407.GB31469@bogey.xentower.nl> <312159812.23706941.1383943810196.JavaMail.root@redhat.com> <1591156023.26916611.1384095417884.JavaMail.root@redhat.com> <1307970395.21470536.1384164195241.JavaMail.root@redhat.com> <12476140.27720889.1384174867933.JavaMail.root@redhat.com> <272602576.20237573.1384182950117.JavaMail.root@redhat.com> Message-ID: <851109864.21655806.1384183389575.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Malini Rao" > To: "Eldan Hildesheim" > Cc: "Tomas Jelinek" , "info" , engine-devel at ovirt.org > Sent: Monday, November 11, 2013 4:15:50 PM > Subject: Re: [Engine-devel] [UX] how to design a bar/line chart? > > Is this going to fit in a row of a table? Or are we talking of a more > detailed view? it should fit into one cell of the table > > ----- Original Message ----- > From: "Eldan Hildesheim" > To: "Tomas Jelinek" > Cc: "info" , engine-devel at ovirt.org > Sent: Monday, November 11, 2013 8:01:07 AM > Subject: Re: [Engine-devel] [UX] how to design a bar/line chart? > > Throw this gif into a browser. This is more or less what I thought. > Eldan > > ----- Original Message ----- > From: "Tomas Jelinek" > To: "Eldan Hildesheim" > Cc: "Einav Cohen" , "info" , > engine-devel at ovirt.org > Sent: Monday, November 11, 2013 12:03:15 PM > Subject: Re: [Engine-devel] [UX] how to design a bar/line chart? > > > > ----- Original Message ----- > > From: "Eldan Hildesheim" > > To: "Einav Cohen" > > Cc: "info" , engine-devel at ovirt.org > > Sent: Sunday, November 10, 2013 3:56:57 PM > > Subject: Re: [Engine-devel] [UX] how to design a bar/line chart? > > > > Hello all, > > We use to have a good solution in the period pre-WPF. > > A line chart (used to be in flash) that works like a plotter: > > The Line Bar (not bar) had a small animation that shifted all the bar to > > the > > left. > > When a new data arrived it just added a new line (to the right) and as I > > said > > before, in parallel it always shifted slowly to the left. > > Any chance you still have some screenshot or mockup so I can imagine it > better? > > > The animation gives the impression that data is streaming and when a real > > new > > data arrives the user gets it very fast. > > We have to sync between the animation and the rate of the arrival of the > > data > > but this is easy. > > If we can't find a good framework it can be created from scratch with JS, > > svg > > or canvas. > > We need to be careful about what we will use. oVirt is supposed to work on FF > 17 [1] > but the HTML5 canvas works only since FF23 [2]. > > @Einav: > Is there a chance that we could start support only FF23+ and IE9+ (this one > is already OK) > because of this feature? > > > Now regarding its position: > > Rollover is good but not enough, we should somehow put it in the lower > > panel > > under general or even another tab - (live data). > > This is a bit different requirement. The point of this specific is to give a > better > overview in the main tab. If it will be done we can decide if we want to give > more > details in sub tabs. > > > We could later on have a (live data Tab) in other places as well like host, > > cluster... > > Eldan > > [1]: http://www.ovirt.org/Download > [2]: http://caniuse.com/#feat=canvas > > > > > ----- Original Message ----- > > From: "Einav Cohen" > > To: "Ewoud Kohl van Wijngaarden" > > Cc: "Alexander Wels" , "Eldan Hildesheim" > > , engine-devel at ovirt.org, "info" > > Sent: Friday, November 8, 2013 10:50:10 PM > > Subject: Re: [Engine-devel] [UX] how to design a bar/line chart? > > > > > ----- Original Message ----- > > > From: "Ewoud Kohl van Wijngaarden" > > > Sent: Thursday, November 7, 2013 11:44:07 AM > > > > > > On Wed, Nov 06, 2013 at 11:45:36AM -0500, 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. > > > > > > I'd say no. Even from a reliability point of view since users may have > > > systems that aren't connected to the internet. > > > > +1 > > > > > (Though I don't know how well oVirt handles this currently.) > > > > AFAIK - oVirt is handling it ('it' == having no internet connection) well. > > _______________________________________________ > > Engine-devel mailing list > > Engine-devel at ovirt.org > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > From oliel at redhat.com Mon Nov 11 15:47:36 2013 From: oliel at redhat.com (Ori Liel) Date: Mon, 11 Nov 2013 10:47:36 -0500 (EST) Subject: [Engine-devel] REST-API: Problem with additional DELETE action at collection level In-Reply-To: <5280B999.6000605@redhat.com> References: <527C7DDF.2050308@redhat.com> <527C86AA.7010904@redhat.com> <25153947.26941766.1384104968045.JavaMail.root@redhat.com> <5280646F.2050903@redhat.com> <5280AAC2.6010805@redhat.com> <463738104.27509428.1384166326211.JavaMail.root@redhat.com> <5280B999.6000605@redhat.com> Message-ID: <1378916650.28031202.1384184856755.JavaMail.root@redhat.com> Guys, I apologize, but after considering it some more, I think there's a basic problem in what I've suggested. What I described would be great, if there would never be a need to delete a brick during the process of its migration, or in other words to force its deletion. But since we must have such an option, in case migration goes wrong and we decide to get rid of the brick at all cost, then we must be ablechoose force=true or force=false. We've already had this discussion, and the original conclusion was right: this does require another signature for DELETE, one which receives an Action object and sets force=true or force=false inside it - just like what Shubhendu described that he tried to do in his email. Telling you, Shubhendu, that another signature is unnecessary was wrong, took you a step back and waisted of your time. I hope you haven't spent much effort implementing what we said yet, as we reached an agreement relatively late in your working day... So my sincere apologies for that. I am well aware that as it is a lot of time has been invested in agreeing on the correct API. I will now revisit your original question, Shubehendu, and soon reply to that, addressing the technical difficulty that you encountered. Ori. ----- Original Message ----- From: "Shubhendu Tripathi" To: "Ori Liel" Cc: "Michael Pasternak" , "Sahina Bose" , "Dusmant Pati" , "engine-devel" Sent: Monday, November 11, 2013 1:03:53 PM Subject: Re: [Engine-devel] REST-API: Problem with additional DELETE action at collection level On 11/11/2013 04:08 PM, Ori Liel wrote: >> ----- Original Message ----- >> From: "Shubhendu Tripathi" >> To: oliel at redhat.com, "Michael Pasternak" , "Sahina Bose" >> Cc: "Dusmant Pati" , "engine-devel" >> Sent: Monday, November 11, 2013 12:00:34 PM >> Subject: Re: [Engine-devel] REST-API: Problem with additional DELETE action at collection level >> >> Self and Ori had a detailed discussion on the topic. >> >> Points discussed - >> >> 1. Ori mentioned that Michael and Ori did not mean to have a separate >> DELETE action for the purpose of commit in previous discussions. > That's right - no need for a new delete signature; existing signatures are enough. > >> 2. Ori tried to understand the intention behind the separate commit >> command in gluster and suggested that ideally gluster should remember >> that a migration of data is started on the set of bricks, and if there >> is a delete fired on the same bricks it should perform a commit action >> because commit is nothing but a delete action >> 3. Ori suggested that in an ideal situation APIs needed would be >> - start migrate >> - stop migrate >> - delete bricks >> - retain bricks >> 4. As suggested by Ori, the remove bricks action should internally >> decide if there was a data migration, started on the set of bricks. If >> so, it should effectively fire a commit for the set of bricks. And if >> there was not occurrence of data migration it should behave like a >> normal force remove action. >> >> Ori, please add your comments if I have missed out anything here. > I agree with what you wrote, let me sort of say it again in my words: > > I don't like requiring two consecutive commands from the API user, to perform migrate. > If the user only does 'migrate', and doesn't do the second step, we are in a state of > corruption. But Shubhendu explained to me that there's no way around this; the > administrator *must* take a look and decide; it is simply not possible to make this > decision in advance. So I accepted this heavy-heartedly. > > Then we were left with the decision of how to model this two step operation. I tried to > look at it from the point of view of the user; what would be the simplest way to 'tell him > the story?' > > - If you want to migrate a brick, run 'migrate' on it. > - If you want to stop migration of the brick, run 'stopMigrate' on it. > - If you want to resume the migration of the brick, simply run 'migrate' on it again. > After migration is done: > - if you want to remove the brick, DELETE it (regular delete). > - if you want to keep using the brick, run 'reactivate' on it. > > And that's the whole story. > > The advantages are: > > * In simple English, not bound to Gluster terms, the administrator has to decide whether to > get rid of the brick, remove it, when migration is done. So what would be more natural than > to delete it? It makes sense, and there's no need for a new 'action'. On the Gluster side, > if user tried to delete a brick which is undergoing migration - simply don't allow it. This > is something you have to do anyway; a user might try to delete a brick which is undergoing > migration and you have to stop him from doing so. So 0 extra work here. > > * Instead of stopMigrate meaning two different things in two different contexts, we now > have stopMigration mean exactly what its name suggests: it stops the migration, and 'reactive' > mean exactly what it suggests - mark this brick as active again, allow it to be used. Thanks Ori for the detailed mail. So now the final set of APIs are - - migrate - stopmigrate - delete (existing delete to be enabled for commit) - reactivate Will go ahead with this and raise the patches accordingly. Thanks and Regards, Shubhendu >> Sahina, request your comments on the same. >> >> Thanks and Regards, >> Shubhendu > On 11/11/2013 10:30 AM, Shubhendu Tripathi wrote: >> On 11/10/2013 11:06 PM, Moti Asayag wrote: >>> ----- Original Message ----- >>>> From: "Shubhendu Tripathi" >>>> To: "engine-devel" , "Michael Pasternak" >>>> , oliel at redhat.com >>>> Sent: Friday, November 8, 2013 8:37:30 AM >>>> Subject: [Engine-devel] REST-API: Problem with additional DELETE >>>> action at collection level >>>> >>>> Hi All, >>>> >>>> There is a DELETE action defined at collection level for Gluster >>>> Bricks with >>>> signature - >>>> >>>> @DELETE >>>> public Response remove ( GlusterBricks bricks ); >>>> >>>> Recently we had needed a commit action to remove migrated bricks. >>>> After multiple rounds of discussion on introducing a commit action >>>> to remove >>>> migrated bricks we introduced a DELETE action [1] which accepts a >>>> boolean >>>> parameter isForce. >>>> If the parameter is set to true , forced deletion of bricks happens >>>> without >>>> any data migration. >>>> And if the parameter is not set or set to false, the deletion is >>>> meant for a >>>> brick on which migration has already taken place. >>>> >>>> To achieve the above functionality we introduced another DELETE >>>> action with >>>> new signature as below and also marked the first action as deprecated - >>>> >>>> @DELETE >>>> public Response remove ( Action action ); >>>> >>>> The problem arises now as the new api works fine for all possible >>>> scenarios >>>> with below input structure - >>>> >>>> >>>> true/false >>>> >>>> >>>> brick1-name >>>> brick2-name >>>> >>>> >>>> >>>> >>>> BUT after these change backward compatibility is broken and the old >>>> api does >>>> not work. >>>> If we try invoking old DELETE with bricks as input parameter as >>>> below, it >>>> still invokes the new api and gives an error saying " Invalid >>>> parameter ". >>>> >>> Maybe I've missed it some where, but i wasn't able to find the new >>> 'force' parameter >>> in the rsdl, and specifically not in optionalArguments list of: >>> >>> - name: >>> /api/clusters/{cluster:id}/glustervolumes/{glustervolume:id}/bricks|rel=delete >>> >>> and perhaps the correct approach will be to deprecate this signature >>> and introduce a new >>> one with the 'force' in the 'mandatoryArguments' section. >> Moti, I have introduced another methods remove of DELETE type which >> takes Action as input. >> I pass list of bricks and force as parameter in the same Action. >> >> Also, I tried marking the old method deprecated and introduced the new >> one BUT as mentioned above, after introduction of new DELETE with >> Action parameter old one STOPS working. >> Is it OK to stop working for a method if its deprecated?? I don't feel >> so. Please comment. >>>> >>>> >>>> >>>> >>>> >>>> Kindly suggest a solution around the same. >>>> >>>> PS: Both the actions are defined at collection level ( >>>> /api/clusters//glustervolumes//bricks ) >>>> >>>> [1]: http://gerrit.ovirt.org/#/c/21043/ >>>> >>>> Thanks and Regards, >>>> Shubhendu >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> Engine-devel mailing list >>>> Engine-devel at ovirt.org >>>> http://lists.ovirt.org/mailman/listinfo/engine-devel >>>> >> _______________________________________________ >> Engine-devel mailing list >> Engine-devel at ovirt.org >> http://lists.ovirt.org/mailman/listinfo/engine-devel >> >> > > From oliel at redhat.com Mon Nov 11 16:20:46 2013 From: oliel at redhat.com (Ori Liel) Date: Mon, 11 Nov 2013 11:20:46 -0500 (EST) Subject: [Engine-devel] REST-API: Problem with additional DELETE action at collection level In-Reply-To: <527C7DDF.2050308@redhat.com> References: <527C7DDF.2050308@redhat.com> Message-ID: <2101667553.28083459.1384186846646.JavaMail.root@redhat.com> Shubhendu, The problem you're describing stems from the fact that BackendGlusterBricksResource already has an implementation of 'remove' which recieves an object (GlusterBricks). This creates ambiguity that RestEasy can't resolve: it has no way of deciding whether to deserialize the XML data into an 'Action' object or into a 'GlusterBricks' object. Within the current limitation of RestEasy, this problem is unsolvable. To overcome this, we can take a different approach: pass 'force' as a URL matrix parameter. In order to see how this is achieved technically, I refer you to BackendResource.isAsync() method. 'async' is a URL matrix parameter, and this simple method shows how it's fetched from the URL. Implementing something similar for force should be easy. On our side, I will deprecate all current uses of 'force' in the API and move them all to be URL matrix parameters, so that we'll be aligned with you. Michael will be here tomorrow, and on Wednesday I'll also be available again, to help and/or review. Thanks, Ori. ----- Original Message ----- From: "Shubhendu Tripathi" To: "engine-devel" , "Michael Pasternak" , oliel at redhat.com Cc: "Dusmant Pati" Sent: Friday, November 8, 2013 7:59:59 AM Subject: REST-API: Problem with additional DELETE action at collection level Hi All, There is a DELETE action defined at collection level for Gluster Bricks with signature - /@DELETE public////Response//remove//(//GlusterBricks//bricks//);/ Recently we had needed a commit action to remove migrated bricks. After multiple rounds of discussion on introducing a commit action to remove migrated bricks we introduced a DELETE action [1] which accepts a boolean parameter isForce. If the parameter is set to /true/, forced deletion of bricks happens without any data migration. And if the parameter is not set or set to /false,/ the deletion is meant for a brick on which migration has already taken place. To achieve the above functionality we introduced another DELETE action with new signature as below and also marked the first action as deprecated - /@DELETE public////Response//remove//(//Action//action//);/ The problem arises now as the new api works fine for all possible scenarios with below input structure - / //// // true/false// // // // // // //brick1-name// // brick2-name// // // // // /// BUT after these change backward compatibility is broken and the old api does not work. If we try invoking old DELETE with bricks as input parameter as below, it still invokes the new api and gives an error saying "Invalid parameter". / // // / Kindly suggest a solution around the same. *PS:* Both the actions are defined at collection level (//api/clusters//glustervolumes//bricks/) [1]: http://gerrit.ovirt.org/#/c/21043/ Thanks and Regards, Shubhendu From jtd at galois.com Mon Nov 11 18:08:21 2013 From: jtd at galois.com (Jonathan Daugherty) Date: Mon, 11 Nov 2013 10:08:21 -0800 Subject: [Engine-devel] Permissions involved in using REST API In-Reply-To: <5280CB12.40505@redhat.com> References: <20131106233401.GG73898@galois.com> <307109400.18301343.1383812802255.JavaMail.root@redhat.com> <20131107172027.GA58872@galois.com> <5280CB12.40505@redhat.com> Message-ID: <20131111180821.GA97966@galois.com> > the main difference between an 'admin' and a 'user' is that admin has > read-only permission to see all objects in the system, and a user can > only see objects they have permissions on. But this distinction does not apply to API access, apparently; regular users cannot access the API at all as far as I can tell. I wouldn't mind giving API users 'admin' status if that's what it takes, but I'm concerned about the meaning of 'admin' changing in the future. I think the trouble here is that by doing it this way oVirt is presuming what the access policy is by baking rights into the 'admin' status. On a site-by-site basis the definition of 'admin' is going to vary. Thanks, -- Jonathan Daugherty Software Engineer Galois, Inc. From iheim at redhat.com Mon Nov 11 18:11:01 2013 From: iheim at redhat.com (Itamar Heim) Date: Mon, 11 Nov 2013 13:11:01 -0500 Subject: [Engine-devel] Permissions involved in using REST API In-Reply-To: <20131111180821.GA97966@galois.com> References: <20131106233401.GG73898@galois.com> <307109400.18301343.1383812802255.JavaMail.root@redhat.com> <20131107172027.GA58872@galois.com> <5280CB12.40505@redhat.com> <20131111180821.GA97966@galois.com> Message-ID: <52811DB5.5010308@redhat.com> On 11/11/2013 01:08 PM, Jonathan Daugherty wrote: >> the main difference between an 'admin' and a 'user' is that admin has >> read-only permission to see all objects in the system, and a user can >> only see objects they have permissions on. > > But this distinction does not apply to API access, apparently; regular > users cannot access the API at all as far as I can tell. I wouldn't > mind giving API users 'admin' status if that's what it takes, but I'm > concerned about the meaning of 'admin' changing in the future. regular users *can* access the API, they just need to pass the filter:true in the request header. > > I think the trouble here is that by doing it this way oVirt is presuming > what the access policy is by baking rights into the 'admin' status. On > a site-by-site basis the definition of 'admin' is going to vary. > > Thanks, > From jtd at galois.com Mon Nov 11 18:16:39 2013 From: jtd at galois.com (Jonathan Daugherty) Date: Mon, 11 Nov 2013 10:16:39 -0800 Subject: [Engine-devel] Permissions involved in using REST API In-Reply-To: <52811DB5.5010308@redhat.com> References: <20131106233401.GG73898@galois.com> <307109400.18301343.1383812802255.JavaMail.root@redhat.com> <20131107172027.GA58872@galois.com> <5280CB12.40505@redhat.com> <20131111180821.GA97966@galois.com> <52811DB5.5010308@redhat.com> Message-ID: <20131111181639.GB97966@galois.com> > regular users *can* access the API, they just need to pass the > filter:true in the request header. Oh, so it does. It wasn't clear from the earlier mention whether it applied only to admins and it never occurred to me to try it this way. Thanks! It seems to me this should be unnecessary, though. Can't the engine detect whether filtering should be enabled implicitly based on the user's status? Also: can we get this documented somewhere? Thanks! -- Jonathan Daugherty Software Engineer Galois, Inc. From iheim at redhat.com Mon Nov 11 18:18:31 2013 From: iheim at redhat.com (Itamar Heim) Date: Mon, 11 Nov 2013 13:18:31 -0500 Subject: [Engine-devel] Permissions involved in using REST API In-Reply-To: <20131111181639.GB97966@galois.com> References: <20131106233401.GG73898@galois.com> <307109400.18301343.1383812802255.JavaMail.root@redhat.com> <20131107172027.GA58872@galois.com> <5280CB12.40505@redhat.com> <20131111180821.GA97966@galois.com> <52811DB5.5010308@redhat.com> <20131111181639.GB97966@galois.com> Message-ID: <52811F77.1070609@redhat.com> On 11/11/2013 01:16 PM, Jonathan Daugherty wrote: >> regular users *can* access the API, they just need to pass the >> filter:true in the request header. > > Oh, so it does. It wasn't clear from the earlier mention whether it > applied only to admins and it never occurred to me to try it this way. > Thanks! It seems to me this should be unnecessary, though. Can't the > engine detect whether filtering should be enabled implicitly based on > the user's status? idea is an admin can also be a user. the default should just have been reverse behavior if we could. > > Also: can we get this documented somewhere? it should be, but if you can't find it easily on the wiki, please create a page elaborting this. From gshereme at redhat.com Tue Nov 12 02:06:55 2013 From: gshereme at redhat.com (Greg Sheremeta) Date: Mon, 11 Nov 2013 21:06:55 -0500 (EST) Subject: [Engine-devel] GWT DevMode plugin stopped working in Firefox 24+ In-Reply-To: <1741128331.26985922.1383756187264.JavaMail.root@redhat.com> References: <1167246611.13117565.1383755277542.JavaMail.root@redhat.com> <1741128331.26985922.1383756187264.JavaMail.root@redhat.com> Message-ID: <913754319.14553289.1384222015703.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Daniel Erez" > To: "Greg Sheremeta" > Cc: "engine-devel" > Sent: Wednesday, November 6, 2013 11:43:07 AM > Subject: Re: [Engine-devel] GWT DevMode plugin stopped working in Firefox 24+ > > > > ----- 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. > It's some kind of packaging problem. I tried to debug with strace, ldd, etc., but no luck. However, downloading FF 25 from ftp://ftp.mozilla.org/pub/firefox/releases/25.0/linux-x86_64/en-US/ and using that worked. (I prepped by yum removing firefox and xulrunner, and for good measure deleting my ~/.firefox directory.) So at least we have a workaround to run the latest FF. > > > > Greg > > > > > > Greg Sheremeta > > Red Hat, Inc. > > Sr. Software Engineer, RHEV > > Cell: 919-807-1086 > > gshereme at redhat.com > > _______________________________________________ > > Engine-devel mailing list > > Engine-devel at ovirt.org > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > From tjelinek at redhat.com Tue Nov 12 10:18:23 2013 From: tjelinek at redhat.com (Tomas Jelinek) Date: Tue, 12 Nov 2013 05:18:23 -0500 (EST) Subject: [Engine-devel] [UX] how to design a bar/line chart? In-Reply-To: <851109864.21655806.1384183389575.JavaMail.root@redhat.com> References: <157528892.18409921.1383645002815.JavaMail.root@redhat.com> <20131107164407.GB31469@bogey.xentower.nl> <312159812.23706941.1383943810196.JavaMail.root@redhat.com> <1591156023.26916611.1384095417884.JavaMail.root@redhat.com> <1307970395.21470536.1384164195241.JavaMail.root@redhat.com> <12476140.27720889.1384174867933.JavaMail.root@redhat.com> <272602576.20237573.1384182950117.JavaMail.root@redhat.com> <851109864.21655806.1384183389575.JavaMail.root@redhat.com> Message-ID: <1987882715.22201500.1384251503600.JavaMail.root@redhat.com> So we have looked into the resource usage sampling with mbetak and also with Michal and it seems that for the CPU usage: - VDSM polls libvirt to get the runtime statistics of the VM regularly. The pooling interval is configured in vdsm.conf as vm_sample_cpu_interval and by default it is 15 seconds - libvirt returns something we than use to calculate the average CPU usage since the last poll - engine polls VDSM once in 15 seconds to get the current statistics (the same 15 seconds is just a coincidence and we can not count on this) - than the frontend polls the engine each 5-60 seconds (depends on the refresh rate) and gets the current value from the engine - the user can press the refresh button anytime to poll the engine again For network usage: - it should be pretty much the same as the CPU just the VDSM poll interval is configured as vm_sample_net_interval and by default it is 5 seconds For memory usage: - guest agent sends a message to VDSM with the memory usage regularly. The interval is set in ovirt-guest-agent.conf as heart_beat_rate and by default it is 5 seconds - the actual value sent by ovirt-guest-agent is the actual value at the time when the value is sent (e.g. for Linux taken from "cat /proc/meminfo") - vdsm is doing no statistics on top of it, just remembers the last value taken from ovirt-guest-agent - the rest of the poling is the same So, visualizing this in some usable form will be quite challenging ;) I see the following problems: - if the VDSM gets the data faster than the engine polls it (and most often it does) than the info in between will be lost. The question is how big this problem is and if it is worth solving (I would say not for CPU which are averages but maybe yes for memory). Other question if there is a way how to solve it since the VDSM can be polled by anyone and it does not really care if someone polls it... (Michal?) - we can lost some data between frontend<->engine if the polling interval of the FE is slower than the polling interval of the engine. This is something not really worth solving because the user can set this according to the level of detail he/she wants - since we will get new info once in ~15 seconds, and the polling of the FE is by default 5 seconds, do we want to do some interpolation? Or just show the same value 3 times? Or be smart and show only changed values? (this is tricky since there is a chance that it did not change - e.g. constant 0 mem usage if you have no guest agent) - What if the user starts clicking to the refresh button? Do we want to keep appending the same value if the engine still has only the old ones? Tomas ----- Original Message ----- > From: "Tomas Jelinek" > To: "Malini Rao" > Cc: "Eldan Hildesheim" , engine-devel at ovirt.org, "info" > Sent: Monday, November 11, 2013 4:23:09 PM > Subject: Re: [Engine-devel] [UX] how to design a bar/line chart? > > > > ----- Original Message ----- > > From: "Malini Rao" > > To: "Eldan Hildesheim" > > Cc: "Tomas Jelinek" , "info" , > > engine-devel at ovirt.org > > Sent: Monday, November 11, 2013 4:15:50 PM > > Subject: Re: [Engine-devel] [UX] how to design a bar/line chart? > > > > Is this going to fit in a row of a table? Or are we talking of a more > > detailed view? > > it should fit into one cell of the table > > > > > ----- Original Message ----- > > From: "Eldan Hildesheim" > > To: "Tomas Jelinek" > > Cc: "info" , engine-devel at ovirt.org > > Sent: Monday, November 11, 2013 8:01:07 AM > > Subject: Re: [Engine-devel] [UX] how to design a bar/line chart? > > > > Throw this gif into a browser. This is more or less what I thought. > > Eldan > > > > ----- Original Message ----- > > From: "Tomas Jelinek" > > To: "Eldan Hildesheim" > > Cc: "Einav Cohen" , "info" , > > engine-devel at ovirt.org > > Sent: Monday, November 11, 2013 12:03:15 PM > > Subject: Re: [Engine-devel] [UX] how to design a bar/line chart? > > > > > > > > ----- Original Message ----- > > > From: "Eldan Hildesheim" > > > To: "Einav Cohen" > > > Cc: "info" , engine-devel at ovirt.org > > > Sent: Sunday, November 10, 2013 3:56:57 PM > > > Subject: Re: [Engine-devel] [UX] how to design a bar/line chart? > > > > > > Hello all, > > > We use to have a good solution in the period pre-WPF. > > > A line chart (used to be in flash) that works like a plotter: > > > The Line Bar (not bar) had a small animation that shifted all the bar to > > > the > > > left. > > > When a new data arrived it just added a new line (to the right) and as I > > > said > > > before, in parallel it always shifted slowly to the left. > > > > Any chance you still have some screenshot or mockup so I can imagine it > > better? > > > > > The animation gives the impression that data is streaming and when a real > > > new > > > data arrives the user gets it very fast. > > > We have to sync between the animation and the rate of the arrival of the > > > data > > > but this is easy. > > > If we can't find a good framework it can be created from scratch with JS, > > > svg > > > or canvas. > > > > We need to be careful about what we will use. oVirt is supposed to work on > > FF > > 17 [1] > > but the HTML5 canvas works only since FF23 [2]. > > > > @Einav: > > Is there a chance that we could start support only FF23+ and IE9+ (this one > > is already OK) > > because of this feature? > > > > > Now regarding its position: > > > Rollover is good but not enough, we should somehow put it in the lower > > > panel > > > under general or even another tab - (live data). > > > > This is a bit different requirement. The point of this specific is to give > > a > > better > > overview in the main tab. If it will be done we can decide if we want to > > give > > more > > details in sub tabs. > > > > > We could later on have a (live data Tab) in other places as well like > > > host, > > > cluster... > > > Eldan > > > > [1]: http://www.ovirt.org/Download > > [2]: http://caniuse.com/#feat=canvas > > > > > > > > ----- Original Message ----- > > > From: "Einav Cohen" > > > To: "Ewoud Kohl van Wijngaarden" > > > Cc: "Alexander Wels" , "Eldan Hildesheim" > > > , engine-devel at ovirt.org, "info" > > > Sent: Friday, November 8, 2013 10:50:10 PM > > > Subject: Re: [Engine-devel] [UX] how to design a bar/line chart? > > > > > > > ----- Original Message ----- > > > > From: "Ewoud Kohl van Wijngaarden" > > > > Sent: Thursday, November 7, 2013 11:44:07 AM > > > > > > > > On Wed, Nov 06, 2013 at 11:45:36AM -0500, 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. > > > > > > > > I'd say no. Even from a reliability point of view since users may have > > > > systems that aren't connected to the internet. > > > > > > +1 > > > > > > > (Though I don't know how well oVirt handles this currently.) > > > > > > AFAIK - oVirt is handling it ('it' == having no internet connection) > > > well. > > > _______________________________________________ > > > Engine-devel mailing list > > > Engine-devel at ovirt.org > > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > > > > > _______________________________________________ > > Engine-devel mailing list > > Engine-devel at ovirt.org > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > From michal.skrivanek at redhat.com Tue Nov 12 10:49:12 2013 From: michal.skrivanek at redhat.com (Michal Skrivanek) Date: Tue, 12 Nov 2013 11:49:12 +0100 Subject: [Engine-devel] [UX] how to design a bar/line chart? In-Reply-To: <1987882715.22201500.1384251503600.JavaMail.root@redhat.com> References: <157528892.18409921.1383645002815.JavaMail.root@redhat.com> <20131107164407.GB31469@bogey.xentower.nl> <312159812.23706941.1383943810196.JavaMail.root@redhat.com> <1591156023.26916611.1384095417884.JavaMail.root@redhat.com> <1307970395.21470536.1384164195241.JavaMail.root@redhat.com> <12476140.27720889.1384174867933.JavaMail.root@redhat.com> <272602576.20237573.1384182950117.JavaMail.root@redhat.com> <851109864.21655806.1384183389575.JavaMail.root@redhat.com> <1987882715.22201500.1384251503600.JavaMail.root@redhat.com> Message-ID: <75820DAB-D86C-4309-B6BE-8B3FA7E7E16D@redhat.com> On Nov 12, 2013, at 11:18 , Tomas Jelinek wrote: > So we have looked into the resource usage sampling with mbetak and also with Michal and it seems that > > for the CPU usage: > - VDSM polls libvirt to get the runtime statistics of the VM regularly. The pooling interval is configured in > vdsm.conf as vm_sample_cpu_interval and by default it is 15 seconds > - libvirt returns something we than use to calculate the average CPU usage since the last poll > - engine polls VDSM once in 15 seconds to get the current statistics (the same 15 seconds is just a coincidence and we can not count on this) > - than the frontend polls the engine each 5-60 seconds (depends on the refresh rate) and gets the current value from the engine > - the user can press the refresh button anytime to poll the engine again > > For network usage: > - it should be pretty much the same as the CPU just the VDSM poll interval is configured as vm_sample_net_interval and by default it is 5 seconds Dan, since we poll only every 15s and cpu info is 15s wouldn't it make sense to change the default for network monitoring to 15s as well? it's 2 libvirt rounds trip for nothing really. Or does it serve some other purpose? > For memory usage: > - guest agent sends a message to VDSM with the memory usage regularly. The interval is set in ovirt-guest-agent.conf as heart_beat_rate > and by default it is 5 seconds > - the actual value sent by ovirt-guest-agent is the actual value at the time when the value is sent (e.g. for Linux taken from "cat /proc/meminfo") > - vdsm is doing no statistics on top of it, just remembers the last value taken from ovirt-guest-agent which is fine, it doesn't change so often and there are typically no spikes > - the rest of the poling is the same > > So, visualizing this in some usable form will be quite challenging ;) > I see the following problems: > - if the VDSM gets the data faster than the engine polls it (and most often it does) than the info in between will be lost. > The question is how big this problem is and if it is worth solving (I would say not for CPU which are averages but maybe yes for memory). > Other question if there is a way how to solve it since the VDSM can be polled by anyone and it does not really care if someone polls it... (Michal?) I'd say not solve it and try to keep it in sync on vdsm side with engine poll, to save unnecessary libvirt calls > - we can lost some data between frontend<->engine if the polling interval of the FE is slower than the polling interval of the engine. This is something > not really worth solving because the user can set this according to the level of detail he/she wants well, you should average the values in engine in case the FE refresh is >15s. Or add (refresh/15) of them > - since we will get new info once in ~15 seconds, and the polling of the FE is by default 5 seconds, do we want to do some interpolation? Or just show the > same value 3 times? Or be smart and show only changed values? (this is tricky since there is a chance that it did not change - e.g. constant 0 mem usage if you have no guest agent) > - What if the user starts clicking to the refresh button? Do we want to keep appending the same value if the engine still has only the old ones? just add a new line/point every 15s should be ok Thanks, michal > > Tomas > > ----- Original Message ----- >> From: "Tomas Jelinek" >> To: "Malini Rao" >> Cc: "Eldan Hildesheim" , engine-devel at ovirt.org, "info" >> Sent: Monday, November 11, 2013 4:23:09 PM >> Subject: Re: [Engine-devel] [UX] how to design a bar/line chart? >> >> >> >> ----- Original Message ----- >>> From: "Malini Rao" >>> To: "Eldan Hildesheim" >>> Cc: "Tomas Jelinek" , "info" , >>> engine-devel at ovirt.org >>> Sent: Monday, November 11, 2013 4:15:50 PM >>> Subject: Re: [Engine-devel] [UX] how to design a bar/line chart? >>> >>> Is this going to fit in a row of a table? Or are we talking of a more >>> detailed view? >> >> it should fit into one cell of the table >> >>> >>> ----- Original Message ----- >>> From: "Eldan Hildesheim" >>> To: "Tomas Jelinek" >>> Cc: "info" , engine-devel at ovirt.org >>> Sent: Monday, November 11, 2013 8:01:07 AM >>> Subject: Re: [Engine-devel] [UX] how to design a bar/line chart? >>> >>> Throw this gif into a browser. This is more or less what I thought. >>> Eldan >>> >>> ----- Original Message ----- >>> From: "Tomas Jelinek" >>> To: "Eldan Hildesheim" >>> Cc: "Einav Cohen" , "info" , >>> engine-devel at ovirt.org >>> Sent: Monday, November 11, 2013 12:03:15 PM >>> Subject: Re: [Engine-devel] [UX] how to design a bar/line chart? >>> >>> >>> >>> ----- Original Message ----- >>>> From: "Eldan Hildesheim" >>>> To: "Einav Cohen" >>>> Cc: "info" , engine-devel at ovirt.org >>>> Sent: Sunday, November 10, 2013 3:56:57 PM >>>> Subject: Re: [Engine-devel] [UX] how to design a bar/line chart? >>>> >>>> Hello all, >>>> We use to have a good solution in the period pre-WPF. >>>> A line chart (used to be in flash) that works like a plotter: >>>> The Line Bar (not bar) had a small animation that shifted all the bar to >>>> the >>>> left. >>>> When a new data arrived it just added a new line (to the right) and as I >>>> said >>>> before, in parallel it always shifted slowly to the left. >>> >>> Any chance you still have some screenshot or mockup so I can imagine it >>> better? >>> >>>> The animation gives the impression that data is streaming and when a real >>>> new >>>> data arrives the user gets it very fast. >>>> We have to sync between the animation and the rate of the arrival of the >>>> data >>>> but this is easy. >>>> If we can't find a good framework it can be created from scratch with JS, >>>> svg >>>> or canvas. >>> >>> We need to be careful about what we will use. oVirt is supposed to work on >>> FF >>> 17 [1] >>> but the HTML5 canvas works only since FF23 [2]. >>> >>> @Einav: >>> Is there a chance that we could start support only FF23+ and IE9+ (this one >>> is already OK) >>> because of this feature? >>> >>>> Now regarding its position: >>>> Rollover is good but not enough, we should somehow put it in the lower >>>> panel >>>> under general or even another tab - (live data). >>> >>> This is a bit different requirement. The point of this specific is to give >>> a >>> better >>> overview in the main tab. If it will be done we can decide if we want to >>> give >>> more >>> details in sub tabs. >>> >>>> We could later on have a (live data Tab) in other places as well like >>>> host, >>>> cluster... >>>> Eldan >>> >>> [1]: http://www.ovirt.org/Download >>> [2]: http://caniuse.com/#feat=canvas >>> >>>> >>>> ----- Original Message ----- >>>> From: "Einav Cohen" >>>> To: "Ewoud Kohl van Wijngaarden" >>>> Cc: "Alexander Wels" , "Eldan Hildesheim" >>>> , engine-devel at ovirt.org, "info" >>>> Sent: Friday, November 8, 2013 10:50:10 PM >>>> Subject: Re: [Engine-devel] [UX] how to design a bar/line chart? >>>> >>>>> ----- Original Message ----- >>>>> From: "Ewoud Kohl van Wijngaarden" >>>>> Sent: Thursday, November 7, 2013 11:44:07 AM >>>>> >>>>> On Wed, Nov 06, 2013 at 11:45:36AM -0500, 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. >>>>> >>>>> I'd say no. Even from a reliability point of view since users may have >>>>> systems that aren't connected to the internet. >>>> >>>> +1 >>>> >>>>> (Though I don't know how well oVirt handles this currently.) >>>> >>>> AFAIK - oVirt is handling it ('it' == having no internet connection) >>>> well. >>>> _______________________________________________ >>>> Engine-devel mailing list >>>> Engine-devel at ovirt.org >>>> http://lists.ovirt.org/mailman/listinfo/engine-devel >>>> >>> >>> _______________________________________________ >>> Engine-devel mailing list >>> Engine-devel at ovirt.org >>> http://lists.ovirt.org/mailman/listinfo/engine-devel >>> >> _______________________________________________ >> Engine-devel mailing list >> Engine-devel at ovirt.org >> http://lists.ovirt.org/mailman/listinfo/engine-devel >> From didi at redhat.com Tue Nov 12 11:38:40 2013 From: didi at redhat.com (Yedidyah Bar David) Date: Tue, 12 Nov 2013 06:38:40 -0500 (EST) Subject: [Engine-devel] Migrating an existing installation to hosted engine In-Reply-To: <292728432.29929102.1384255154815.JavaMail.root@redhat.com> Message-ID: <1599883010.29941308.1384256320402.JavaMail.root@redhat.com> Hi all, A message with the same subject was sent to arch around a month ago, see [1]. In short, it suggested two approaches: 1. Use p2v (or v2v) 2. Clean install of OS/engine software and use backup/restore. Following that, I pushed a few changes for engine-backup and engine-setup, with the intention of doing, briefly: 1. hosted-engine --deploy on new host 2. Install OS/software on new vm 3. backup on old engine machine 4. On new vm, do restore, which only restores the database and files, followed by engine-setup, which will fix whatever else needs to be fixed. Some of the changes are still pending, and are under some controversy. See [2], [3], [4]. A more detailed description of the suggested migration path is in [5]. What do you think? Should engine-setup do as little as possible to the system, or as much as needed to save the admin from any manual work? Should engine-setup doing an upgrade do the same as a new setup, or just whatever that's needed to adapt the config/database to the new code? A specific example: if admin chose during initial setup to automatically configure the firewall (iptables/firewalld), should upgrade update it again, or not touch it? Should engine-backup do all these things when doing a restore? Should we have some other utility to do these things? Should we merely document them and let the admin do this manually? [1] http://lists.ovirt.org/pipermail/arch/2013-October/001677.html [2] https://bugzilla.redhat.com/1024707 [3] http://gerrit.ovirt.org/20736 [4] http://gerrit.ovirt.org/20737 [5] http://www.ovirt.org/Migrate_to_Hosted_Engine -- Didi From vszocs at redhat.com Tue Nov 12 11:40:18 2013 From: vszocs at redhat.com (Vojtech Szocs) Date: Tue, 12 Nov 2013 06:40:18 -0500 (EST) Subject: [Engine-devel] Weird behavior of multiple SetVmTicket query In-Reply-To: <1416897.Cty3puulVa@awels> References: <1405029090.20090071.1384159399724.JavaMail.root@redhat.com> <1757293.UZ46spY3rU@awels> <989864807.20226412.1384181602956.JavaMail.root@redhat.com> <1416897.Cty3puulVa@awels> Message-ID: <630563857.22230004.1384256418496.JavaMail.root@redhat.com> Forwarding this email to engine-devel so that backend maintainers are aware of this issue. Looking at the code: - MultipleActionsRunner#Execute first creates and "validates" all commands: A. the "for" block which iterates over getParameters() 1-> validate correlation ID, if OK create and add command, otherwise add returnValue B the "if" block which tests getCommands().size() 1-> if single command to execute, add its "canDoActionOnly" returnValue, which is returnValue with canDoAction but without actual result object 2-> if multi commands to execute, execute chunks of max. 10 threads (sequentially, ThreadPoolUtil.invokeAll returns after all threads complete), same returnValue as above C. the "if" block which tests canRunActions 1-> all commands are executed within SINGLE THREAD due to ThreadPoolUtil.execute(Runnable), which is kind of weird comapred to how returnValues are prepared (see B2) 2-> when executing command, code DOES NOT CARE about its returnValue, i.e. returnValue was already prepared (see B) and command execution should just update it The problem (I think) is that C1 starts a different thread (to execute all commands) and immediately returns, i.e. code doesn't wait for thread to complete. This is why returnValues are observed on frontend as inconsistent. Additionally, we're also mixing of two different things: canDoAction processing and returnValues processing. IMHO this should be refactored to make code easier to read. Changes done by Alex (patch attached): X1. returnValues changed to Collections.synchronizedList -> this means all access to returnValues is now serial -> iteration over synchronizedList should also be enclosed in "synchronized (list)" block, so this: for (VdcReturnValueBase value : returnValues) ... should be this: synchronized (returnValues) { for (VdcReturnValueBase value : returnValues) ... } X2. commented-out original command execution via ThreadPoolUtil.execute(Runnable) -> new RunCommands method invokes all commands each in separate thread via ThreadPoolUtil.invokeAll -> returnValues list is explicitly updated Guys, what do you think? Vojtech ----- Original Message ----- > From: "Alexander Wels" > To: "Frantisek Kobzik" > Cc: "Vojtech Szocs" > Sent: Monday, November 11, 2013 9:19:08 PM > Subject: Re: Weird behavior of multiple SetVmTicket query > > Hi, > > I did some debugging, and the problem is a race condition in the > MultipleActions class. The whole class seems to have a lot of multi-threading > issues but if I modify the code to wait for the results of the actions to > return before returning the return value, everything works fine. > > I am attaching a patch that solves the issue at hand, but should not be > considered a real patch. It is just to show the issue is in the back-end not > the front-end code. The front-end code is just exposing an issue in the back- > end > > Alexander > > On Monday, November 11, 2013 09:53:22 AM you wrote: > > Ok, thank you very much! > > > > ----- Original Message ----- > > From: "Alexander Wels" > > To: "Frantisek Kobzik" > > Sent: Monday, November 11, 2013 2:15:43 PM > > Subject: Re: Weird behavior of multiple SetVmTicket query > > > > Frantisek, > > > > I had seen this before, let me test and fix it for you, it is very likely > > my > > patch broke that. > > > > Alexander > > > > On Monday, November 11, 2013 03:43:19 AM you wrote: > > > Hi Alex, > > > > > > recently I noticed problems with invoking console for multiple VMs > > > (select > > > more VMs in webadmin and then hit the console btn). I was sure it worked > > > in > > > past so i git-bisected the master branch and I discovered that this > > > problem > > > is apparently caused by patch [1]. For single vm console invocation it > > > works fine, but for multiple VMs it doesn't. > > > > > > I did some closer investigation with a debugger and it seems that > > > getSucceeded() on the return val of SetVmTicket command returns false in > > > case of multiple execution despite the fact SetVmTicketCommand sets this > > > value to true. I suppose there is some problem with propagation of > > > command > > > return value from BE to FE. The same goes for the encapsulated > > > returnValue > > > attribute (it contains value of the generated ticket). When invoking > > > multiple consoles it is null (although it has been filled on backend). > > > Weird. > > > > > > Tomas told me you did some optimizations for multiple command executions, > > > do you know it might cause it? Please let me know if you have any idea... > > > > > > Cheers, > > > F. > > > > > > [1]: http://gerrit.ovirt.org/#/c/17356/ > -------------- next part -------------- A non-text attachment was scrubbed... Name: thread_wait.patch Type: text/x-patch Size: 4373 bytes Desc: not available URL: From awels at redhat.com Tue Nov 12 13:55:15 2013 From: awels at redhat.com (Alexander Wels) Date: Tue, 12 Nov 2013 08:55:15 -0500 Subject: [Engine-devel] UI Refresh synchronization Message-ID: <1681170.mkF7sXr2iu@awels> Hi guys, I am working on providing our users with a better experience in regards to refresh synchronization. Quite often it will happen that you as a user will do a particular action, and it takes a whole refresh cycle for you to see the UI updated in response to that action. For instance if you remove a VM in the webadmin and click the ok button in the UI, the grid will still show the VM until the next refresh cycle, not when the VM is actually removed. I have created a wiki page that outlines the issues, and the ways we are intending to solve these issues [1]. Feel free to comment/e-mail/etc to let me know what you guys think. Alexander [1] http://www.ovirt.org/Features/Design/UIRefreshSynchronization From tjelinek at redhat.com Tue Nov 12 14:25:34 2013 From: tjelinek at redhat.com (Tomas Jelinek) Date: Tue, 12 Nov 2013 09:25:34 -0500 (EST) Subject: [Engine-devel] [UX] how to design a bar/line chart? In-Reply-To: <75820DAB-D86C-4309-B6BE-8B3FA7E7E16D@redhat.com> References: <157528892.18409921.1383645002815.JavaMail.root@redhat.com> <1591156023.26916611.1384095417884.JavaMail.root@redhat.com> <1307970395.21470536.1384164195241.JavaMail.root@redhat.com> <12476140.27720889.1384174867933.JavaMail.root@redhat.com> <272602576.20237573.1384182950117.JavaMail.root@redhat.com> <851109864.21655806.1384183389575.JavaMail.root@redhat.com> <1987882715.22201500.1384251503600.JavaMail.root@redhat.com> <75820DAB-D86C-4309-B6BE-8B3FA7E7E16D@redhat.com> Message-ID: <1565095771.22322614.1384266334031.JavaMail.root@redhat.com> Hey all, let me conclude what has been written in this thread to one proposal: == From the UX perspective the behavior == - each time the FE will receive new data and this data are different from the old ones, visualize it in the chart It means if you will keep pressing the refresh button but the data will not change, no new data will be visualized (an exception will be the 0 usage) - the amount of data visualized will depend on the size of the widget (since the tables are resizable). It means that if you make the widget bigger you will not see the same chart bigger but more data. - If you make the widget bigger, only then the amount of data will start to increase: e.g. before resize: | /-------\ | |/ \| after resize: | /-------\ | |/ \ | and only now the new data will start to appear == From FE technical point of view == - since I have not found any GWT library which would be acceptable (e.g. actively developed and without the need to connect to google servers) and given that the required chart is quite simple I guess it would be ok to write it by myself. - according to Einav's mail it is ok to use HTML5 canvas so I would go with writing a new widget using HTML5 canvas == From L&F point of view == - would look pretty much like the one proposed by Malini: http://style.org/chartapi/sparklines/ == From data point of view == - do not do any averages on VDSM side (since it already does them for CPU and network and the memory is stable enough) - do not do any averages on engine side (since would have to be done for each FE separately and stored in session which is a bit overcomplicated. If the user wants to see more accurate data, he/she can change the refresh rate) - do not do any interpolation since the data are already averaged and we will show only new ones @Malini,Einav,Eldan,Michal what do you think? Tomas ----- Original Message ----- > From: "Michal Skrivanek" > To: "Tomas Jelinek" , "Dan Kenigsberg" > Cc: "Malini Rao" , "Eldan Hildesheim" , engine-devel at ovirt.org, "info" > > Sent: Tuesday, November 12, 2013 11:49:12 AM > Subject: Re: [Engine-devel] [UX] how to design a bar/line chart? > > > On Nov 12, 2013, at 11:18 , Tomas Jelinek wrote: > > > So we have looked into the resource usage sampling with mbetak and also > > with Michal and it seems that > > > > for the CPU usage: > > - VDSM polls libvirt to get the runtime statistics of the VM regularly. The > > pooling interval is configured in > > vdsm.conf as vm_sample_cpu_interval and by default it is 15 seconds > > - libvirt returns something we than use to calculate the average CPU usage > > since the last poll > > - engine polls VDSM once in 15 seconds to get the current statistics (the > > same 15 seconds is just a coincidence and we can not count on this) > > - than the frontend polls the engine each 5-60 seconds (depends on the > > refresh rate) and gets the current value from the engine > > - the user can press the refresh button anytime to poll the engine again > > > > For network usage: > > - it should be pretty much the same as the CPU just the VDSM poll interval > > is configured as vm_sample_net_interval and by default it is 5 seconds > > Dan, since we poll only every 15s and cpu info is 15s wouldn't it make sense > to change the default for network monitoring to 15s as well? it's 2 libvirt > rounds trip for nothing really. Or does it serve some other purpose? > > > > For memory usage: > > - guest agent sends a message to VDSM with the memory usage regularly. The > > interval is set in ovirt-guest-agent.conf as heart_beat_rate > > and by default it is 5 seconds > > - the actual value sent by ovirt-guest-agent is the actual value at the > > time when the value is sent (e.g. for Linux taken from "cat > > /proc/meminfo") > > - vdsm is doing no statistics on top of it, just remembers the last value > > taken from ovirt-guest-agent > > which is fine, it doesn't change so often and there are typically no spikes > > > - the rest of the poling is the same > > > > So, visualizing this in some usable form will be quite challenging ;) > > I see the following problems: > > - if the VDSM gets the data faster than the engine polls it (and most often > > it does) than the info in between will be lost. > > The question is how big this problem is and if it is worth solving (I > > would say not for CPU which are averages but maybe yes for memory). > > Other question if there is a way how to solve it since the VDSM can be > > polled by anyone and it does not really care if someone polls it... > > (Michal?) > > I'd say not solve it and try to keep it in sync on vdsm side with engine > poll, to save unnecessary libvirt calls > > > - we can lost some data between frontend<->engine if the polling interval > > of the FE is slower than the polling interval of the engine. This is > > something > > not really worth solving because the user can set this according to the > > level of detail he/she wants > > well, you should average the values in engine in case the FE refresh is >15s. > Or add (refresh/15) of them It is not that simple since you can have more frontends and not sure if it would be a good idea to put this into the session... > > > - since we will get new info once in ~15 seconds, and the polling of the FE > > is by default 5 seconds, do we want to do some interpolation? Or just show > > the > > same value 3 times? Or be smart and show only changed values? (this is > > tricky since there is a chance that it did not change - e.g. constant 0 > > mem usage if you have no guest agent) > > - What if the user starts clicking to the refresh button? Do we want to > > keep appending the same value if the engine still has only the old ones? > > just add a new line/point every 15s should be ok > > Thanks, > michal > > > > > Tomas > > > > ----- Original Message ----- > >> From: "Tomas Jelinek" > >> To: "Malini Rao" > >> Cc: "Eldan Hildesheim" , engine-devel at ovirt.org, > >> "info" > >> Sent: Monday, November 11, 2013 4:23:09 PM > >> Subject: Re: [Engine-devel] [UX] how to design a bar/line chart? > >> > >> > >> > >> ----- Original Message ----- > >>> From: "Malini Rao" > >>> To: "Eldan Hildesheim" > >>> Cc: "Tomas Jelinek" , "info" , > >>> engine-devel at ovirt.org > >>> Sent: Monday, November 11, 2013 4:15:50 PM > >>> Subject: Re: [Engine-devel] [UX] how to design a bar/line chart? > >>> > >>> Is this going to fit in a row of a table? Or are we talking of a more > >>> detailed view? > >> > >> it should fit into one cell of the table > >> > >>> > >>> ----- Original Message ----- > >>> From: "Eldan Hildesheim" > >>> To: "Tomas Jelinek" > >>> Cc: "info" , engine-devel at ovirt.org > >>> Sent: Monday, November 11, 2013 8:01:07 AM > >>> Subject: Re: [Engine-devel] [UX] how to design a bar/line chart? > >>> > >>> Throw this gif into a browser. This is more or less what I thought. > >>> Eldan > >>> > >>> ----- Original Message ----- > >>> From: "Tomas Jelinek" > >>> To: "Eldan Hildesheim" > >>> Cc: "Einav Cohen" , "info" , > >>> engine-devel at ovirt.org > >>> Sent: Monday, November 11, 2013 12:03:15 PM > >>> Subject: Re: [Engine-devel] [UX] how to design a bar/line chart? > >>> > >>> > >>> > >>> ----- Original Message ----- > >>>> From: "Eldan Hildesheim" > >>>> To: "Einav Cohen" > >>>> Cc: "info" , engine-devel at ovirt.org > >>>> Sent: Sunday, November 10, 2013 3:56:57 PM > >>>> Subject: Re: [Engine-devel] [UX] how to design a bar/line chart? > >>>> > >>>> Hello all, > >>>> We use to have a good solution in the period pre-WPF. > >>>> A line chart (used to be in flash) that works like a plotter: > >>>> The Line Bar (not bar) had a small animation that shifted all the bar to > >>>> the > >>>> left. > >>>> When a new data arrived it just added a new line (to the right) and as I > >>>> said > >>>> before, in parallel it always shifted slowly to the left. > >>> > >>> Any chance you still have some screenshot or mockup so I can imagine it > >>> better? > >>> > >>>> The animation gives the impression that data is streaming and when a > >>>> real > >>>> new > >>>> data arrives the user gets it very fast. > >>>> We have to sync between the animation and the rate of the arrival of the > >>>> data > >>>> but this is easy. > >>>> If we can't find a good framework it can be created from scratch with > >>>> JS, > >>>> svg > >>>> or canvas. > >>> > >>> We need to be careful about what we will use. oVirt is supposed to work > >>> on > >>> FF > >>> 17 [1] > >>> but the HTML5 canvas works only since FF23 [2]. > >>> > >>> @Einav: > >>> Is there a chance that we could start support only FF23+ and IE9+ (this > >>> one > >>> is already OK) > >>> because of this feature? > >>> > >>>> Now regarding its position: > >>>> Rollover is good but not enough, we should somehow put it in the lower > >>>> panel > >>>> under general or even another tab - (live data). > >>> > >>> This is a bit different requirement. The point of this specific is to > >>> give > >>> a > >>> better > >>> overview in the main tab. If it will be done we can decide if we want to > >>> give > >>> more > >>> details in sub tabs. > >>> > >>>> We could later on have a (live data Tab) in other places as well like > >>>> host, > >>>> cluster... > >>>> Eldan > >>> > >>> [1]: http://www.ovirt.org/Download > >>> [2]: http://caniuse.com/#feat=canvas > >>> > >>>> > >>>> ----- Original Message ----- > >>>> From: "Einav Cohen" > >>>> To: "Ewoud Kohl van Wijngaarden" > >>>> Cc: "Alexander Wels" , "Eldan Hildesheim" > >>>> , engine-devel at ovirt.org, "info" > >>>> Sent: Friday, November 8, 2013 10:50:10 PM > >>>> Subject: Re: [Engine-devel] [UX] how to design a bar/line chart? > >>>> > >>>>> ----- Original Message ----- > >>>>> From: "Ewoud Kohl van Wijngaarden" > >>>>> Sent: Thursday, November 7, 2013 11:44:07 AM > >>>>> > >>>>> On Wed, Nov 06, 2013 at 11:45:36AM -0500, 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. > >>>>> > >>>>> I'd say no. Even from a reliability point of view since users may have > >>>>> systems that aren't connected to the internet. > >>>> > >>>> +1 > >>>> > >>>>> (Though I don't know how well oVirt handles this currently.) > >>>> > >>>> AFAIK - oVirt is handling it ('it' == having no internet connection) > >>>> well. > >>>> _______________________________________________ > >>>> Engine-devel mailing list > >>>> Engine-devel at ovirt.org > >>>> http://lists.ovirt.org/mailman/listinfo/engine-devel > >>>> > >>> > >>> _______________________________________________ > >>> Engine-devel mailing list > >>> Engine-devel at ovirt.org > >>> http://lists.ovirt.org/mailman/listinfo/engine-devel > >>> > >> _______________________________________________ > >> Engine-devel mailing list > >> Engine-devel at ovirt.org > >> http://lists.ovirt.org/mailman/listinfo/engine-devel > >> > > From awels at redhat.com Tue Nov 12 14:33:56 2013 From: awels at redhat.com (Alexander Wels) Date: Tue, 12 Nov 2013 09:33:56 -0500 Subject: [Engine-devel] [UX] how to design a bar/line chart? In-Reply-To: <1565095771.22322614.1384266334031.JavaMail.root@redhat.com> References: <157528892.18409921.1383645002815.JavaMail.root@redhat.com> <75820DAB-D86C-4309-B6BE-8B3FA7E7E16D@redhat.com> <1565095771.22322614.1384266334031.JavaMail.root@redhat.com> Message-ID: <2016662.grIZKjIgyW@awels> On Tuesday, November 12, 2013 09:25:34 AM Tomas Jelinek wrote: > Hey all, > > let me conclude what has been written in this thread to one proposal: > > == From the UX perspective the behavior == > - each time the FE will receive new data and this data are different from > the old ones, visualize it in the chart It means if you will keep pressing > the refresh button but the data will not change, no new data will be > visualized (an exception will be the 0 usage) - the amount of data > visualized will depend on the size of the widget (since the tables are > resizable). It means that if you make the widget bigger you will not see > the same chart bigger but more data. - If you make the widget bigger, only > then the amount of data will start to increase: e.g. > > before resize: > | /-------\ | > | > |/ \| > > after resize: > | /-------\ | > | > |/ \ | > > and only now the new data will start to appear > > == From FE technical point of view == > - since I have not found any GWT library which would be acceptable (e.g. > actively developed and without the need to connect to google servers) and > given that the required chart is quite simple I guess it would be ok to > write it by myself. - according to Einav's mail it is ok to use HTML5 > canvas so I would go with writing a new widget using HTML5 canvas > Just to throw out something to think about, we could also in theory generate an image on the server side and simply display that image inside the grid (so no need for HTML5 canvas or other things like that). The idea being basically that when the grid refreshes it makes a request for a new image on the back- end with the appropriate timeframe and the back-end generates the image which is easy to embed inside the grid. pros: * Easy to embed inside grid (just an image tag). * Works on all browsers, even ones without HTML5 canvas support. cons: * More load on the back-end. * Extra round trips to back-end on refresh. * Not 'hot' like HTML5 canvas. * No interactivity if that is something we are interested in. > == From L&F point of view == > - would look pretty much like the one proposed by Malini: > http://style.org/chartapi/sparklines/ > > == From data point of view == > - do not do any averages on VDSM side (since it already does them for CPU > and network and the memory is stable enough) - do not do any averages on > engine side (since would have to be done for each FE separately and stored > in session which is a bit overcomplicated. If the user wants to see more > accurate data, he/she can change the refresh rate) - do not do any > interpolation since the data are already averaged and we will show only new > ones > > @Malini,Einav,Eldan,Michal what do you think? > > Tomas > > ----- Original Message ----- > > > From: "Michal Skrivanek" > > To: "Tomas Jelinek" , "Dan Kenigsberg" > > Cc: "Malini Rao" , "Eldan > > Hildesheim" , engine-devel at ovirt.org, "info" > > > > Sent: Tuesday, November 12, 2013 11:49:12 AM > > Subject: Re: [Engine-devel] [UX] how to design a bar/line chart? > > > > On Nov 12, 2013, at 11:18 , Tomas Jelinek wrote: > > > So we have looked into the resource usage sampling with mbetak and also > > > with Michal and it seems that > > > > > > for the CPU usage: > > > - VDSM polls libvirt to get the runtime statistics of the VM regularly. > > > The > > > pooling interval is configured in > > > > > > vdsm.conf as vm_sample_cpu_interval and by default it is 15 seconds > > > > > > - libvirt returns something we than use to calculate the average CPU > > > usage > > > since the last poll > > > - engine polls VDSM once in 15 seconds to get the current statistics > > > (the > > > same 15 seconds is just a coincidence and we can not count on this) > > > - than the frontend polls the engine each 5-60 seconds (depends on the > > > refresh rate) and gets the current value from the engine > > > - the user can press the refresh button anytime to poll the engine again > > > > > > For network usage: > > > - it should be pretty much the same as the CPU just the VDSM poll > > > interval > > > is configured as vm_sample_net_interval and by default it is 5 seconds > > > > Dan, since we poll only every 15s and cpu info is 15s wouldn't it make > > sense to change the default for network monitoring to 15s as well? it's 2 > > libvirt rounds trip for nothing really. Or does it serve some other > > purpose?> > > > For memory usage: > > > - guest agent sends a message to VDSM with the memory usage regularly. > > > The > > > interval is set in ovirt-guest-agent.conf as heart_beat_rate > > > > > > and by default it is 5 seconds > > > > > > - the actual value sent by ovirt-guest-agent is the actual value at the > > > time when the value is sent (e.g. for Linux taken from "cat > > > /proc/meminfo") > > > - vdsm is doing no statistics on top of it, just remembers the last > > > value > > > taken from ovirt-guest-agent > > > > which is fine, it doesn't change so often and there are typically no > > spikes > > > > > - the rest of the poling is the same > > > > > > So, visualizing this in some usable form will be quite challenging ;) > > > I see the following problems: > > > - if the VDSM gets the data faster than the engine polls it (and most > > > often > > > it does) than the info in between will be lost. > > > > > > The question is how big this problem is and if it is worth solving (I > > > would say not for CPU which are averages but maybe yes for memory). > > > Other question if there is a way how to solve it since the VDSM can be > > > polled by anyone and it does not really care if someone polls it... > > > (Michal?) > > > > I'd say not solve it and try to keep it in sync on vdsm side with engine > > poll, to save unnecessary libvirt calls > > > > > - we can lost some data between frontend<->engine if the polling > > > interval > > > of the FE is slower than the polling interval of the engine. This is > > > something > > > > > > not really worth solving because the user can set this according to the > > > level of detail he/she wants > > > > well, you should average the values in engine in case the FE refresh is > > >15s. Or add (refresh/15) of them > > It is not that simple since you can have more frontends and not sure if it > would be a good idea to put this into the session... > > > > - since we will get new info once in ~15 seconds, and the polling of the > > > FE > > > is by default 5 seconds, do we want to do some interpolation? Or just > > > show > > > the > > > > > > same value 3 times? Or be smart and show only changed values? (this is > > > tricky since there is a chance that it did not change - e.g. constant 0 > > > mem usage if you have no guest agent) > > > > > > - What if the user starts clicking to the refresh button? Do we want to > > > keep appending the same value if the engine still has only the old ones? > > > > just add a new line/point every 15s should be ok > > > > Thanks, > > michal > > > > > Tomas > > > > > > ----- Original Message ----- > > > > > >> From: "Tomas Jelinek" > > >> To: "Malini Rao" > > >> Cc: "Eldan Hildesheim" , engine-devel at ovirt.org, > > >> "info" > > >> Sent: Monday, November 11, 2013 4:23:09 PM > > >> Subject: Re: [Engine-devel] [UX] how to design a bar/line chart? > > >> > > >> > > >> > > >> ----- Original Message ----- > > >> > > >>> From: "Malini Rao" > > >>> To: "Eldan Hildesheim" > > >>> Cc: "Tomas Jelinek" , "info" , > > >>> engine-devel at ovirt.org > > >>> Sent: Monday, November 11, 2013 4:15:50 PM > > >>> Subject: Re: [Engine-devel] [UX] how to design a bar/line chart? > > >>> > > >>> Is this going to fit in a row of a table? Or are we talking of a more > > >>> detailed view? > > >> > > >> it should fit into one cell of the table > > >> > > >>> ----- Original Message ----- > > >>> From: "Eldan Hildesheim" > > >>> To: "Tomas Jelinek" > > >>> Cc: "info" , engine-devel at ovirt.org > > >>> Sent: Monday, November 11, 2013 8:01:07 AM > > >>> Subject: Re: [Engine-devel] [UX] how to design a bar/line chart? > > >>> > > >>> Throw this gif into a browser. This is more or less what I thought. > > >>> Eldan > > >>> > > >>> ----- Original Message ----- > > >>> From: "Tomas Jelinek" > > >>> To: "Eldan Hildesheim" > > >>> Cc: "Einav Cohen" , "info" , > > >>> engine-devel at ovirt.org > > >>> Sent: Monday, November 11, 2013 12:03:15 PM > > >>> Subject: Re: [Engine-devel] [UX] how to design a bar/line chart? > > >>> > > >>> > > >>> > > >>> ----- Original Message ----- > > >>> > > >>>> From: "Eldan Hildesheim" > > >>>> To: "Einav Cohen" > > >>>> Cc: "info" , engine-devel at ovirt.org > > >>>> Sent: Sunday, November 10, 2013 3:56:57 PM > > >>>> Subject: Re: [Engine-devel] [UX] how to design a bar/line chart? > > >>>> > > >>>> Hello all, > > >>>> We use to have a good solution in the period pre-WPF. > > >>>> A line chart (used to be in flash) that works like a plotter: > > >>>> The Line Bar (not bar) had a small animation that shifted all the bar > > >>>> to > > >>>> the > > >>>> left. > > >>>> When a new data arrived it just added a new line (to the right) and > > >>>> as I > > >>>> said > > >>>> before, in parallel it always shifted slowly to the left. > > >>> > > >>> Any chance you still have some screenshot or mockup so I can imagine > > >>> it > > >>> better? > > >>> > > >>>> The animation gives the impression that data is streaming and when a > > >>>> real > > >>>> new > > >>>> data arrives the user gets it very fast. > > >>>> We have to sync between the animation and the rate of the arrival of > > >>>> the > > >>>> data > > >>>> but this is easy. > > >>>> If we can't find a good framework it can be created from scratch with > > >>>> JS, > > >>>> svg > > >>>> or canvas. > > >>> > > >>> We need to be careful about what we will use. oVirt is supposed to > > >>> work > > >>> on > > >>> FF > > >>> 17 [1] > > >>> but the HTML5 canvas works only since FF23 [2]. > > >>> > > >>> @Einav: > > >>> Is there a chance that we could start support only FF23+ and IE9+ > > >>> (this > > >>> one > > >>> is already OK) > > >>> because of this feature? > > >>> > > >>>> Now regarding its position: > > >>>> Rollover is good but not enough, we should somehow put it in the > > >>>> lower > > >>>> panel > > >>>> under general or even another tab - (live data). > > >>> > > >>> This is a bit different requirement. The point of this specific is to > > >>> give > > >>> a > > >>> better > > >>> overview in the main tab. If it will be done we can decide if we want > > >>> to > > >>> give > > >>> more > > >>> details in sub tabs. > > >>> > > >>>> We could later on have a (live data Tab) in other places as well like > > >>>> host, > > >>>> cluster... > > >>>> Eldan > > >>> > > >>> [1]: http://www.ovirt.org/Download > > >>> [2]: http://caniuse.com/#feat=canvas > > >>> > > >>>> ----- Original Message ----- > > >>>> From: "Einav Cohen" > > >>>> To: "Ewoud Kohl van Wijngaarden" > > >>>> Cc: "Alexander Wels" , "Eldan Hildesheim" > > >>>> , engine-devel at ovirt.org, "info" > > >>>> > > >>>> Sent: Friday, November 8, 2013 10:50:10 PM > > >>>> Subject: Re: [Engine-devel] [UX] how to design a bar/line chart? > > >>>> > > >>>>> ----- Original Message ----- > > >>>>> From: "Ewoud Kohl van Wijngaarden" > > >>>>> > > >>>>> Sent: Thursday, November 7, 2013 11:44:07 AM > > >>>>> > > >>>>> On Wed, Nov 06, 2013 at 11:45:36AM -0500, 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. > > >>>>> > > >>>>> I'd say no. Even from a reliability point of view since users may > > >>>>> have > > >>>>> systems that aren't connected to the internet. > > >>>> > > >>>> +1 > > >>>> > > >>>>> (Though I don't know how well oVirt handles this currently.) > > >>>> > > >>>> AFAIK - oVirt is handling it ('it' == having no internet connection) > > >>>> well. > > >>>> _______________________________________________ > > >>>> Engine-devel mailing list > > >>>> Engine-devel at ovirt.org > > >>>> http://lists.ovirt.org/mailman/listinfo/engine-devel > > >>> > > >>> _______________________________________________ > > >>> Engine-devel mailing list > > >>> Engine-devel at ovirt.org > > >>> http://lists.ovirt.org/mailman/listinfo/engine-devel > > >> > > >> _______________________________________________ > > >> Engine-devel mailing list > > >> Engine-devel at ovirt.org > > >> http://lists.ovirt.org/mailman/listinfo/engine-devel > > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel From danken at redhat.com Tue Nov 12 14:45:06 2013 From: danken at redhat.com (Dan Kenigsberg) Date: Tue, 12 Nov 2013 14:45:06 +0000 Subject: [Engine-devel] [UX] how to design a bar/line chart? In-Reply-To: <75820DAB-D86C-4309-B6BE-8B3FA7E7E16D@redhat.com> References: <157528892.18409921.1383645002815.JavaMail.root@redhat.com> <20131107164407.GB31469@bogey.xentower.nl> <312159812.23706941.1383943810196.JavaMail.root@redhat.com> <1591156023.26916611.1384095417884.JavaMail.root@redhat.com> <1307970395.21470536.1384164195241.JavaMail.root@redhat.com> <12476140.27720889.1384174867933.JavaMail.root@redhat.com> <272602576.20237573.1384182950117.JavaMail.root@redhat.com> <851109864.21655806.1384183389575.JavaMail.root@redhat.com> <1987882715.22201500.1384251503600.JavaMail.root@redhat.com> <75820DAB-D86C-4309-B6BE-8B3FA7E7E16D@redhat.com> Message-ID: <20131112144506.GR17187@redhat.com> On Tue, Nov 12, 2013 at 11:49:12AM +0100, Michal Skrivanek wrote: > > On Nov 12, 2013, at 11:18 , Tomas Jelinek wrote: > > > So we have looked into the resource usage sampling with mbetak and also with Michal and it seems that > > > > for the CPU usage: > > - VDSM polls libvirt to get the runtime statistics of the VM regularly. The pooling interval is configured in > > vdsm.conf as vm_sample_cpu_interval and by default it is 15 seconds > > - libvirt returns something we than use to calculate the average CPU usage since the last poll > > - engine polls VDSM once in 15 seconds to get the current statistics (the same 15 seconds is just a coincidence and we can not count on this) > > - than the frontend polls the engine each 5-60 seconds (depends on the refresh rate) and gets the current value from the engine > > - the user can press the refresh button anytime to poll the engine again > > > > For network usage: > > - it should be pretty much the same as the CPU just the VDSM poll interval is configured as vm_sample_net_interval and by default it is 5 seconds > > Dan, since we poll only every 15s and cpu info is 15s wouldn't it make > sense to change the default for network monitoring to 15s as well? > it's 2 libvirt rounds trip for nothing really. Or does it serve some > other purpose? I see no motivation for Vdsm to poll libvirt faster than Engine polls Vdsm. Maybe Federico, who's improved scalability back in https://bugzilla.redhat.com/show_bug.cgi?id=661321 [vdsm] [scale] vdsm CPU consumption goes between 180-400 when running 100 vms remembers a reason. I'm for changing the default to 15. From tjelinek at redhat.com Tue Nov 12 14:50:07 2013 From: tjelinek at redhat.com (Tomas Jelinek) Date: Tue, 12 Nov 2013 09:50:07 -0500 (EST) Subject: [Engine-devel] [UX] how to design a bar/line chart? In-Reply-To: <2016662.grIZKjIgyW@awels> References: <157528892.18409921.1383645002815.JavaMail.root@redhat.com> <75820DAB-D86C-4309-B6BE-8B3FA7E7E16D@redhat.com> <1565095771.22322614.1384266334031.JavaMail.root@redhat.com> <2016662.grIZKjIgyW@awels> Message-ID: <875734149.22345891.1384267807860.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Alexander Wels" > To: engine-devel at ovirt.org > Cc: "Tomas Jelinek" , "Michal Skrivanek" , "Eldan Hildesheim" > , "info" > Sent: Tuesday, November 12, 2013 3:33:56 PM > Subject: Re: [Engine-devel] [UX] how to design a bar/line chart? > > On Tuesday, November 12, 2013 09:25:34 AM Tomas Jelinek wrote: > > Hey all, > > > > let me conclude what has been written in this thread to one proposal: > > > > == From the UX perspective the behavior == > > - each time the FE will receive new data and this data are different from > > the old ones, visualize it in the chart It means if you will keep pressing > > the refresh button but the data will not change, no new data will be > > visualized (an exception will be the 0 usage) - the amount of data > > visualized will depend on the size of the widget (since the tables are > > resizable). It means that if you make the widget bigger you will not see > > the same chart bigger but more data. - If you make the widget bigger, only > > then the amount of data will start to increase: e.g. > > > > before resize: > > | /-------\ | > > | > > |/ \| > > > > after resize: > > | /-------\ | > > | > > |/ \ | > > > > and only now the new data will start to appear > > > > == From FE technical point of view == > > - since I have not found any GWT library which would be acceptable (e.g. > > actively developed and without the need to connect to google servers) and > > given that the required chart is quite simple I guess it would be ok to > > write it by myself. - according to Einav's mail it is ok to use HTML5 > > canvas so I would go with writing a new widget using HTML5 canvas > > > > Just to throw out something to think about, we could also in theory generate > an image on the server side and simply display that image inside the grid (so > no need for HTML5 canvas or other things like that). The idea being basically > that when the grid refreshes it makes a request for a new image on the back- > end with the appropriate timeframe and the back-end generates the image which > is easy to embed inside the grid. > > pros: > * Easy to embed inside grid (just an image tag). > * Works on all browsers, even ones without HTML5 canvas support. > cons: > * More load on the back-end. > * Extra round trips to back-end on refresh. > * Not 'hot' like HTML5 canvas. > * No interactivity if that is something we are interested in. some more cons: * need to remember the statistics on server in the memory. For thousands of VMs it is not something we would like to do * lots of overhead to retrieve all the images on each refresh. If you have 100 VMs on a page and refresh each 5 seconds, it is 100 images transmitted from engine to frontend each 5 seconds per one client (and we can have more of them of course) * FE logic on Server is in general not awesome > > > == From L&F point of view == > > - would look pretty much like the one proposed by Malini: > > http://style.org/chartapi/sparklines/ > > > > == From data point of view == > > - do not do any averages on VDSM side (since it already does them for CPU > > and network and the memory is stable enough) - do not do any averages on > > engine side (since would have to be done for each FE separately and stored > > in session which is a bit overcomplicated. If the user wants to see more > > accurate data, he/she can change the refresh rate) - do not do any > > interpolation since the data are already averaged and we will show only new > > ones > > > > @Malini,Einav,Eldan,Michal what do you think? > > > > Tomas > > > > ----- Original Message ----- > > > > > From: "Michal Skrivanek" > > > To: "Tomas Jelinek" , "Dan Kenigsberg" > > > Cc: "Malini Rao" , "Eldan > > > Hildesheim" , engine-devel at ovirt.org, "info" > > > > > > Sent: Tuesday, November 12, 2013 11:49:12 AM > > > Subject: Re: [Engine-devel] [UX] how to design a bar/line chart? > > > > > > On Nov 12, 2013, at 11:18 , Tomas Jelinek wrote: > > > > So we have looked into the resource usage sampling with mbetak and also > > > > with Michal and it seems that > > > > > > > > for the CPU usage: > > > > - VDSM polls libvirt to get the runtime statistics of the VM regularly. > > > > The > > > > pooling interval is configured in > > > > > > > > vdsm.conf as vm_sample_cpu_interval and by default it is 15 seconds > > > > > > > > - libvirt returns something we than use to calculate the average CPU > > > > usage > > > > since the last poll > > > > - engine polls VDSM once in 15 seconds to get the current statistics > > > > (the > > > > same 15 seconds is just a coincidence and we can not count on this) > > > > - than the frontend polls the engine each 5-60 seconds (depends on the > > > > refresh rate) and gets the current value from the engine > > > > - the user can press the refresh button anytime to poll the engine > > > > again > > > > > > > > For network usage: > > > > - it should be pretty much the same as the CPU just the VDSM poll > > > > interval > > > > is configured as vm_sample_net_interval and by default it is 5 seconds > > > > > > Dan, since we poll only every 15s and cpu info is 15s wouldn't it make > > > sense to change the default for network monitoring to 15s as well? it's 2 > > > libvirt rounds trip for nothing really. Or does it serve some other > > > purpose?> > > > > For memory usage: > > > > - guest agent sends a message to VDSM with the memory usage regularly. > > > > The > > > > interval is set in ovirt-guest-agent.conf as heart_beat_rate > > > > > > > > and by default it is 5 seconds > > > > > > > > - the actual value sent by ovirt-guest-agent is the actual value at the > > > > time when the value is sent (e.g. for Linux taken from "cat > > > > /proc/meminfo") > > > > - vdsm is doing no statistics on top of it, just remembers the last > > > > value > > > > taken from ovirt-guest-agent > > > > > > which is fine, it doesn't change so often and there are typically no > > > spikes > > > > > > > - the rest of the poling is the same > > > > > > > > So, visualizing this in some usable form will be quite challenging ;) > > > > I see the following problems: > > > > - if the VDSM gets the data faster than the engine polls it (and most > > > > often > > > > it does) than the info in between will be lost. > > > > > > > > The question is how big this problem is and if it is worth solving (I > > > > would say not for CPU which are averages but maybe yes for memory). > > > > Other question if there is a way how to solve it since the VDSM can be > > > > polled by anyone and it does not really care if someone polls it... > > > > (Michal?) > > > > > > I'd say not solve it and try to keep it in sync on vdsm side with engine > > > poll, to save unnecessary libvirt calls > > > > > > > - we can lost some data between frontend<->engine if the polling > > > > interval > > > > of the FE is slower than the polling interval of the engine. This is > > > > something > > > > > > > > not really worth solving because the user can set this according to > > > > the > > > > level of detail he/she wants > > > > > > well, you should average the values in engine in case the FE refresh is > > > >15s. Or add (refresh/15) of them > > > > It is not that simple since you can have more frontends and not sure if it > > would be a good idea to put this into the session... > > > > > > - since we will get new info once in ~15 seconds, and the polling of > > > > the > > > > FE > > > > is by default 5 seconds, do we want to do some interpolation? Or just > > > > show > > > > the > > > > > > > > same value 3 times? Or be smart and show only changed values? (this is > > > > tricky since there is a chance that it did not change - e.g. constant > > > > 0 > > > > mem usage if you have no guest agent) > > > > > > > > - What if the user starts clicking to the refresh button? Do we want to > > > > keep appending the same value if the engine still has only the old > > > > ones? > > > > > > just add a new line/point every 15s should be ok > > > > > > Thanks, > > > michal > > > > > > > Tomas > > > > > > > > ----- Original Message ----- > > > > > > > >> From: "Tomas Jelinek" > > > >> To: "Malini Rao" > > > >> Cc: "Eldan Hildesheim" , engine-devel at ovirt.org, > > > >> "info" > > > >> Sent: Monday, November 11, 2013 4:23:09 PM > > > >> Subject: Re: [Engine-devel] [UX] how to design a bar/line chart? > > > >> > > > >> > > > >> > > > >> ----- Original Message ----- > > > >> > > > >>> From: "Malini Rao" > > > >>> To: "Eldan Hildesheim" > > > >>> Cc: "Tomas Jelinek" , "info" , > > > >>> engine-devel at ovirt.org > > > >>> Sent: Monday, November 11, 2013 4:15:50 PM > > > >>> Subject: Re: [Engine-devel] [UX] how to design a bar/line chart? > > > >>> > > > >>> Is this going to fit in a row of a table? Or are we talking of a more > > > >>> detailed view? > > > >> > > > >> it should fit into one cell of the table > > > >> > > > >>> ----- Original Message ----- > > > >>> From: "Eldan Hildesheim" > > > >>> To: "Tomas Jelinek" > > > >>> Cc: "info" , engine-devel at ovirt.org > > > >>> Sent: Monday, November 11, 2013 8:01:07 AM > > > >>> Subject: Re: [Engine-devel] [UX] how to design a bar/line chart? > > > >>> > > > >>> Throw this gif into a browser. This is more or less what I thought. > > > >>> Eldan > > > >>> > > > >>> ----- Original Message ----- > > > >>> From: "Tomas Jelinek" > > > >>> To: "Eldan Hildesheim" > > > >>> Cc: "Einav Cohen" , "info" , > > > >>> engine-devel at ovirt.org > > > >>> Sent: Monday, November 11, 2013 12:03:15 PM > > > >>> Subject: Re: [Engine-devel] [UX] how to design a bar/line chart? > > > >>> > > > >>> > > > >>> > > > >>> ----- Original Message ----- > > > >>> > > > >>>> From: "Eldan Hildesheim" > > > >>>> To: "Einav Cohen" > > > >>>> Cc: "info" , engine-devel at ovirt.org > > > >>>> Sent: Sunday, November 10, 2013 3:56:57 PM > > > >>>> Subject: Re: [Engine-devel] [UX] how to design a bar/line chart? > > > >>>> > > > >>>> Hello all, > > > >>>> We use to have a good solution in the period pre-WPF. > > > >>>> A line chart (used to be in flash) that works like a plotter: > > > >>>> The Line Bar (not bar) had a small animation that shifted all the > > > >>>> bar > > > >>>> to > > > >>>> the > > > >>>> left. > > > >>>> When a new data arrived it just added a new line (to the right) and > > > >>>> as I > > > >>>> said > > > >>>> before, in parallel it always shifted slowly to the left. > > > >>> > > > >>> Any chance you still have some screenshot or mockup so I can imagine > > > >>> it > > > >>> better? > > > >>> > > > >>>> The animation gives the impression that data is streaming and when a > > > >>>> real > > > >>>> new > > > >>>> data arrives the user gets it very fast. > > > >>>> We have to sync between the animation and the rate of the arrival of > > > >>>> the > > > >>>> data > > > >>>> but this is easy. > > > >>>> If we can't find a good framework it can be created from scratch > > > >>>> with > > > >>>> JS, > > > >>>> svg > > > >>>> or canvas. > > > >>> > > > >>> We need to be careful about what we will use. oVirt is supposed to > > > >>> work > > > >>> on > > > >>> FF > > > >>> 17 [1] > > > >>> but the HTML5 canvas works only since FF23 [2]. > > > >>> > > > >>> @Einav: > > > >>> Is there a chance that we could start support only FF23+ and IE9+ > > > >>> (this > > > >>> one > > > >>> is already OK) > > > >>> because of this feature? > > > >>> > > > >>>> Now regarding its position: > > > >>>> Rollover is good but not enough, we should somehow put it in the > > > >>>> lower > > > >>>> panel > > > >>>> under general or even another tab - (live data). > > > >>> > > > >>> This is a bit different requirement. The point of this specific is to > > > >>> give > > > >>> a > > > >>> better > > > >>> overview in the main tab. If it will be done we can decide if we want > > > >>> to > > > >>> give > > > >>> more > > > >>> details in sub tabs. > > > >>> > > > >>>> We could later on have a (live data Tab) in other places as well > > > >>>> like > > > >>>> host, > > > >>>> cluster... > > > >>>> Eldan > > > >>> > > > >>> [1]: http://www.ovirt.org/Download > > > >>> [2]: http://caniuse.com/#feat=canvas > > > >>> > > > >>>> ----- Original Message ----- > > > >>>> From: "Einav Cohen" > > > >>>> To: "Ewoud Kohl van Wijngaarden" > > > >>>> Cc: "Alexander Wels" , "Eldan Hildesheim" > > > >>>> , engine-devel at ovirt.org, "info" > > > >>>> > > > >>>> Sent: Friday, November 8, 2013 10:50:10 PM > > > >>>> Subject: Re: [Engine-devel] [UX] how to design a bar/line chart? > > > >>>> > > > >>>>> ----- Original Message ----- > > > >>>>> From: "Ewoud Kohl van Wijngaarden" > > > >>>>> > > > >>>>> Sent: Thursday, November 7, 2013 11:44:07 AM > > > >>>>> > > > >>>>> On Wed, Nov 06, 2013 at 11:45:36AM -0500, 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. > > > >>>>> > > > >>>>> I'd say no. Even from a reliability point of view since users may > > > >>>>> have > > > >>>>> systems that aren't connected to the internet. > > > >>>> > > > >>>> +1 > > > >>>> > > > >>>>> (Though I don't know how well oVirt handles this currently.) > > > >>>> > > > >>>> AFAIK - oVirt is handling it ('it' == having no internet > > > >>>> connection) > > > >>>> well. > > > >>>> _______________________________________________ > > > >>>> Engine-devel mailing list > > > >>>> Engine-devel at ovirt.org > > > >>>> http://lists.ovirt.org/mailman/listinfo/engine-devel > > > >>> > > > >>> _______________________________________________ > > > >>> Engine-devel mailing list > > > >>> Engine-devel at ovirt.org > > > >>> http://lists.ovirt.org/mailman/listinfo/engine-devel > > > >> > > > >> _______________________________________________ > > > >> Engine-devel mailing list > > > >> Engine-devel at ovirt.org > > > >> http://lists.ovirt.org/mailman/listinfo/engine-devel > > > > _______________________________________________ > > Engine-devel mailing list > > Engine-devel at ovirt.org > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > From awels at redhat.com Tue Nov 12 15:03:14 2013 From: awels at redhat.com (Alexander Wels) Date: Tue, 12 Nov 2013 10:03:14 -0500 Subject: [Engine-devel] [UX] how to design a bar/line chart? In-Reply-To: <875734149.22345891.1384267807860.JavaMail.root@redhat.com> References: <157528892.18409921.1383645002815.JavaMail.root@redhat.com> <2016662.grIZKjIgyW@awels> <875734149.22345891.1384267807860.JavaMail.root@redhat.com> Message-ID: <1562637.RCtmcDAuT8@awels> On Tuesday, November 12, 2013 09:50:07 AM Tomas Jelinek wrote: > ----- Original Message ----- > > > From: "Alexander Wels" > > To: engine-devel at ovirt.org > > Cc: "Tomas Jelinek" , "Michal Skrivanek" > > , "Eldan Hildesheim" , > > "info" > > Sent: Tuesday, November 12, 2013 3:33:56 PM > > Subject: Re: [Engine-devel] [UX] how to design a bar/line chart? > > > > On Tuesday, November 12, 2013 09:25:34 AM Tomas Jelinek wrote: > > > Hey all, > > > > > > let me conclude what has been written in this thread to one proposal: > > > > > > == From the UX perspective the behavior == > > > - each time the FE will receive new data and this data are different > > > from > > > the old ones, visualize it in the chart It means if you will keep > > > pressing > > > the refresh button but the data will not change, no new data will be > > > visualized (an exception will be the 0 usage) - the amount of data > > > visualized will depend on the size of the widget (since the tables are > > > resizable). It means that if you make the widget bigger you will not see > > > the same chart bigger but more data. - If you make the widget bigger, > > > only > > > then the amount of data will start to increase: e.g. > > > > > > before resize: > > > | /-------\ | > > > | > > > |/ \| > > > > > > after resize: > > > | /-------\ | > > > | > > > |/ \ | > > > > > > and only now the new data will start to appear > > > > > > == From FE technical point of view == > > > - since I have not found any GWT library which would be acceptable (e.g. > > > actively developed and without the need to connect to google servers) > > > and > > > given that the required chart is quite simple I guess it would be ok to > > > write it by myself. - according to Einav's mail it is ok to use HTML5 > > > canvas so I would go with writing a new widget using HTML5 canvas > > > > Just to throw out something to think about, we could also in theory > > generate an image on the server side and simply display that image inside > > the grid (so no need for HTML5 canvas or other things like that). The > > idea being basically that when the grid refreshes it makes a request for > > a new image on the back- end with the appropriate timeframe and the > > back-end generates the image which is easy to embed inside the grid. > > > > pros: > > * Easy to embed inside grid (just an image tag). > > * Works on all browsers, even ones without HTML5 canvas support. > > cons: > > * More load on the back-end. > > * Extra round trips to back-end on refresh. > > * Not 'hot' like HTML5 canvas. > > * No interactivity if that is something we are interested in. > > some more cons: > * need to remember the statistics on server in the memory. For thousands of > VMs it is not something we would like to do * lots of overhead to retrieve > all the images on each refresh. If you have 100 VMs on a page and refresh > each 5 seconds, it is 100 images transmitted from engine to frontend each 5 > seconds per one client (and we can have more of them of course) * FE logic > on Server is in general not awesome > I would expect the statistics to be stored in the database somewhere, that way we can pull them for reports and things of that nature (like charts). Obviously we wouldn't do 100 round trips for the image, we would generate a single image sprite that would contain all the images in a single request and display the appropriate part of the image in the grid. You are right in general front-end logic is not done on the back-end. However we must consider if we are really doing front end logic here, or if we are just displaying some reporting information as part of the grid. If we are not storing the statistics anywhere, then this is a terrible plan, and we should do the logic on the client, but if we are, it is something to consider. > > > == From L&F point of view == > > > - would look pretty much like the one proposed by Malini: > > > http://style.org/chartapi/sparklines/ > > > > > > == From data point of view == > > > - do not do any averages on VDSM side (since it already does them for > > > CPU > > > and network and the memory is stable enough) - do not do any averages on > > > engine side (since would have to be done for each FE separately and > > > stored > > > in session which is a bit overcomplicated. If the user wants to see more > > > accurate data, he/she can change the refresh rate) - do not do any > > > interpolation since the data are already averaged and we will show only > > > new > > > ones > > > > > > @Malini,Einav,Eldan,Michal what do you think? > > > > > > Tomas > > > > > > ----- Original Message ----- > > > > > > > From: "Michal Skrivanek" > > > > To: "Tomas Jelinek" , "Dan Kenigsberg" > > > > Cc: "Malini Rao" , "Eldan > > > > Hildesheim" , engine-devel at ovirt.org, "info" > > > > > > > > Sent: Tuesday, November 12, 2013 11:49:12 AM > > > > Subject: Re: [Engine-devel] [UX] how to design a bar/line chart? > > > > > > > > On Nov 12, 2013, at 11:18 , Tomas Jelinek wrote: > > > > > So we have looked into the resource usage sampling with mbetak and > > > > > also > > > > > with Michal and it seems that > > > > > > > > > > for the CPU usage: > > > > > - VDSM polls libvirt to get the runtime statistics of the VM > > > > > regularly. > > > > > The > > > > > pooling interval is configured in > > > > > > > > > > vdsm.conf as vm_sample_cpu_interval and by default it is 15 seconds > > > > > > > > > > - libvirt returns something we than use to calculate the average CPU > > > > > usage > > > > > since the last poll > > > > > - engine polls VDSM once in 15 seconds to get the current statistics > > > > > (the > > > > > same 15 seconds is just a coincidence and we can not count on this) > > > > > - than the frontend polls the engine each 5-60 seconds (depends on > > > > > the > > > > > refresh rate) and gets the current value from the engine > > > > > - the user can press the refresh button anytime to poll the engine > > > > > again > > > > > > > > > > For network usage: > > > > > - it should be pretty much the same as the CPU just the VDSM poll > > > > > interval > > > > > is configured as vm_sample_net_interval and by default it is 5 > > > > > seconds > > > > > > > > Dan, since we poll only every 15s and cpu info is 15s wouldn't it make > > > > sense to change the default for network monitoring to 15s as well? > > > > it's 2 > > > > libvirt rounds trip for nothing really. Or does it serve some other > > > > purpose?> > > > > > > > > > For memory usage: > > > > > - guest agent sends a message to VDSM with the memory usage > > > > > regularly. > > > > > The > > > > > interval is set in ovirt-guest-agent.conf as heart_beat_rate > > > > > > > > > > and by default it is 5 seconds > > > > > > > > > > - the actual value sent by ovirt-guest-agent is the actual value at > > > > > the > > > > > time when the value is sent (e.g. for Linux taken from "cat > > > > > /proc/meminfo") > > > > > - vdsm is doing no statistics on top of it, just remembers the last > > > > > value > > > > > taken from ovirt-guest-agent > > > > > > > > which is fine, it doesn't change so often and there are typically no > > > > spikes > > > > > > > > > - the rest of the poling is the same > > > > > > > > > > So, visualizing this in some usable form will be quite challenging > > > > > ;) > > > > > I see the following problems: > > > > > - if the VDSM gets the data faster than the engine polls it (and > > > > > most > > > > > often > > > > > it does) than the info in between will be lost. > > > > > > > > > > The question is how big this problem is and if it is worth solving > > > > > (I > > > > > would say not for CPU which are averages but maybe yes for memory). > > > > > Other question if there is a way how to solve it since the VDSM can > > > > > be > > > > > polled by anyone and it does not really care if someone polls it... > > > > > (Michal?) > > > > > > > > I'd say not solve it and try to keep it in sync on vdsm side with > > > > engine > > > > poll, to save unnecessary libvirt calls > > > > > > > > > - we can lost some data between frontend<->engine if the polling > > > > > interval > > > > > of the FE is slower than the polling interval of the engine. This is > > > > > something > > > > > > > > > > not really worth solving because the user can set this according to > > > > > the > > > > > level of detail he/she wants > > > > > > > > well, you should average the values in engine in case the FE refresh > > > > is > > > > > > > > >15s. Or add (refresh/15) of them > > > > > > It is not that simple since you can have more frontends and not sure if > > > it > > > would be a good idea to put this into the session... > > > > > > > > - since we will get new info once in ~15 seconds, and the polling of > > > > > the > > > > > FE > > > > > is by default 5 seconds, do we want to do some interpolation? Or > > > > > just > > > > > show > > > > > the > > > > > > > > > > same value 3 times? Or be smart and show only changed values? (this > > > > > is > > > > > tricky since there is a chance that it did not change - e.g. > > > > > constant > > > > > 0 > > > > > mem usage if you have no guest agent) > > > > > > > > > > - What if the user starts clicking to the refresh button? Do we want > > > > > to > > > > > keep appending the same value if the engine still has only the old > > > > > ones? > > > > > > > > just add a new line/point every 15s should be ok > > > > > > > > Thanks, > > > > michal > > > > > > > > > Tomas > > > > > > > > > > ----- Original Message ----- > > > > > > > > > >> From: "Tomas Jelinek" > > > > >> To: "Malini Rao" > > > > >> Cc: "Eldan Hildesheim" , > > > > >> engine-devel at ovirt.org, > > > > >> "info" > > > > >> Sent: Monday, November 11, 2013 4:23:09 PM > > > > >> Subject: Re: [Engine-devel] [UX] how to design a bar/line chart? > > > > >> > > > > >> > > > > >> > > > > >> ----- Original Message ----- > > > > >> > > > > >>> From: "Malini Rao" > > > > >>> To: "Eldan Hildesheim" > > > > >>> Cc: "Tomas Jelinek" , "info" > > > > >>> , > > > > >>> engine-devel at ovirt.org > > > > >>> Sent: Monday, November 11, 2013 4:15:50 PM > > > > >>> Subject: Re: [Engine-devel] [UX] how to design a bar/line chart? > > > > >>> > > > > >>> Is this going to fit in a row of a table? Or are we talking of a > > > > >>> more > > > > >>> detailed view? > > > > >> > > > > >> it should fit into one cell of the table > > > > >> > > > > >>> ----- Original Message ----- > > > > >>> From: "Eldan Hildesheim" > > > > >>> To: "Tomas Jelinek" > > > > >>> Cc: "info" , engine-devel at ovirt.org > > > > >>> Sent: Monday, November 11, 2013 8:01:07 AM > > > > >>> Subject: Re: [Engine-devel] [UX] how to design a bar/line chart? > > > > >>> > > > > >>> Throw this gif into a browser. This is more or less what I > > > > >>> thought. > > > > >>> Eldan > > > > >>> > > > > >>> ----- Original Message ----- > > > > >>> From: "Tomas Jelinek" > > > > >>> To: "Eldan Hildesheim" > > > > >>> Cc: "Einav Cohen" , "info" , > > > > >>> engine-devel at ovirt.org > > > > >>> Sent: Monday, November 11, 2013 12:03:15 PM > > > > >>> Subject: Re: [Engine-devel] [UX] how to design a bar/line chart? > > > > >>> > > > > >>> > > > > >>> > > > > >>> ----- Original Message ----- > > > > >>> > > > > >>>> From: "Eldan Hildesheim" > > > > >>>> To: "Einav Cohen" > > > > >>>> Cc: "info" , engine-devel at ovirt.org > > > > >>>> Sent: Sunday, November 10, 2013 3:56:57 PM > > > > >>>> Subject: Re: [Engine-devel] [UX] how to design a bar/line chart? > > > > >>>> > > > > >>>> Hello all, > > > > >>>> We use to have a good solution in the period pre-WPF. > > > > >>>> A line chart (used to be in flash) that works like a plotter: > > > > >>>> The Line Bar (not bar) had a small animation that shifted all the > > > > >>>> bar > > > > >>>> to > > > > >>>> the > > > > >>>> left. > > > > >>>> When a new data arrived it just added a new line (to the right) > > > > >>>> and > > > > >>>> as I > > > > >>>> said > > > > >>>> before, in parallel it always shifted slowly to the left. > > > > >>> > > > > >>> Any chance you still have some screenshot or mockup so I can > > > > >>> imagine > > > > >>> it > > > > >>> better? > > > > >>> > > > > >>>> The animation gives the impression that data is streaming and > > > > >>>> when a > > > > >>>> real > > > > >>>> new > > > > >>>> data arrives the user gets it very fast. > > > > >>>> We have to sync between the animation and the rate of the arrival > > > > >>>> of > > > > >>>> the > > > > >>>> data > > > > >>>> but this is easy. > > > > >>>> If we can't find a good framework it can be created from scratch > > > > >>>> with > > > > >>>> JS, > > > > >>>> svg > > > > >>>> or canvas. > > > > >>> > > > > >>> We need to be careful about what we will use. oVirt is supposed to > > > > >>> work > > > > >>> on > > > > >>> FF > > > > >>> 17 [1] > > > > >>> but the HTML5 canvas works only since FF23 [2]. > > > > >>> > > > > >>> @Einav: > > > > >>> Is there a chance that we could start support only FF23+ and IE9+ > > > > >>> (this > > > > >>> one > > > > >>> is already OK) > > > > >>> because of this feature? > > > > >>> > > > > >>>> Now regarding its position: > > > > >>>> Rollover is good but not enough, we should somehow put it in the > > > > >>>> lower > > > > >>>> panel > > > > >>>> under general or even another tab - (live data). > > > > >>> > > > > >>> This is a bit different requirement. The point of this specific is > > > > >>> to > > > > >>> give > > > > >>> a > > > > >>> better > > > > >>> overview in the main tab. If it will be done we can decide if we > > > > >>> want > > > > >>> to > > > > >>> give > > > > >>> more > > > > >>> details in sub tabs. > > > > >>> > > > > >>>> We could later on have a (live data Tab) in other places as well > > > > >>>> like > > > > >>>> host, > > > > >>>> cluster... > > > > >>>> Eldan > > > > >>> > > > > >>> [1]: http://www.ovirt.org/Download > > > > >>> [2]: http://caniuse.com/#feat=canvas > > > > >>> > > > > >>>> ----- Original Message ----- > > > > >>>> From: "Einav Cohen" > > > > >>>> To: "Ewoud Kohl van Wijngaarden" > > > > >>>> > > > > >>>> Cc: "Alexander Wels" , "Eldan Hildesheim" > > > > >>>> , engine-devel at ovirt.org, "info" > > > > >>>> > > > > >>>> Sent: Friday, November 8, 2013 10:50:10 PM > > > > >>>> Subject: Re: [Engine-devel] [UX] how to design a bar/line chart? > > > > >>>> > > > > >>>>> ----- Original Message ----- > > > > >>>>> From: "Ewoud Kohl van Wijngaarden" > > > > >>>>> > > > > >>>>> Sent: Thursday, November 7, 2013 11:44:07 AM > > > > >>>>> > > > > >>>>> On Wed, Nov 06, 2013 at 11:45:36AM -0500, 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. > > > > >>>>> > > > > >>>>> I'd say no. Even from a reliability point of view since users > > > > >>>>> may > > > > >>>>> have > > > > >>>>> systems that aren't connected to the internet. > > > > >>>> > > > > >>>> +1 > > > > >>>> > > > > >>>>> (Though I don't know how well oVirt handles this currently.) > > > > >>>> > > > > >>>> AFAIK - oVirt is handling it ('it' == having no internet > > > > >>>> connection) > > > > >>>> well. > > > > >>>> _______________________________________________ > > > > >>>> Engine-devel mailing list > > > > >>>> Engine-devel at ovirt.org > > > > >>>> http://lists.ovirt.org/mailman/listinfo/engine-devel > > > > >>> > > > > >>> _______________________________________________ > > > > >>> Engine-devel mailing list > > > > >>> Engine-devel at ovirt.org > > > > >>> http://lists.ovirt.org/mailman/listinfo/engine-devel > > > > >> > > > > >> _______________________________________________ > > > > >> Engine-devel mailing list > > > > >> Engine-devel at ovirt.org > > > > >> http://lists.ovirt.org/mailman/listinfo/engine-devel > > > > > > _______________________________________________ > > > Engine-devel mailing list > > > Engine-devel at ovirt.org > > > http://lists.ovirt.org/mailman/listinfo/engine-devel From tjelinek at redhat.com Tue Nov 12 15:21:15 2013 From: tjelinek at redhat.com (Tomas Jelinek) Date: Tue, 12 Nov 2013 10:21:15 -0500 (EST) Subject: [Engine-devel] [UX] how to design a bar/line chart? In-Reply-To: <1562637.RCtmcDAuT8@awels> References: <157528892.18409921.1383645002815.JavaMail.root@redhat.com> <2016662.grIZKjIgyW@awels> <875734149.22345891.1384267807860.JavaMail.root@redhat.com> <1562637.RCtmcDAuT8@awels> Message-ID: <709457129.22382323.1384269675421.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Alexander Wels" > To: "Tomas Jelinek" > Cc: engine-devel at ovirt.org, "Michal Skrivanek" , "Eldan Hildesheim" > , "info" > Sent: Tuesday, November 12, 2013 4:03:14 PM > Subject: Re: [Engine-devel] [UX] how to design a bar/line chart? > > On Tuesday, November 12, 2013 09:50:07 AM Tomas Jelinek wrote: > > ----- Original Message ----- > > > > > From: "Alexander Wels" > > > To: engine-devel at ovirt.org > > > Cc: "Tomas Jelinek" , "Michal Skrivanek" > > > , "Eldan Hildesheim" , > > > "info" > > > Sent: Tuesday, November 12, 2013 3:33:56 PM > > > Subject: Re: [Engine-devel] [UX] how to design a bar/line chart? > > > > > > On Tuesday, November 12, 2013 09:25:34 AM Tomas Jelinek wrote: > > > > Hey all, > > > > > > > > let me conclude what has been written in this thread to one proposal: > > > > > > > > == From the UX perspective the behavior == > > > > - each time the FE will receive new data and this data are different > > > > from > > > > the old ones, visualize it in the chart It means if you will keep > > > > pressing > > > > the refresh button but the data will not change, no new data will be > > > > visualized (an exception will be the 0 usage) - the amount of data > > > > visualized will depend on the size of the widget (since the tables are > > > > resizable). It means that if you make the widget bigger you will not > > > > see > > > > the same chart bigger but more data. - If you make the widget bigger, > > > > only > > > > then the amount of data will start to increase: e.g. > > > > > > > > before resize: > > > > | /-------\ | > > > > | > > > > |/ \| > > > > > > > > after resize: > > > > | /-------\ | > > > > | > > > > |/ \ | > > > > > > > > and only now the new data will start to appear > > > > > > > > == From FE technical point of view == > > > > - since I have not found any GWT library which would be acceptable > > > > (e.g. > > > > actively developed and without the need to connect to google servers) > > > > and > > > > given that the required chart is quite simple I guess it would be ok to > > > > write it by myself. - according to Einav's mail it is ok to use HTML5 > > > > canvas so I would go with writing a new widget using HTML5 canvas > > > > > > Just to throw out something to think about, we could also in theory > > > generate an image on the server side and simply display that image inside > > > the grid (so no need for HTML5 canvas or other things like that). The > > > idea being basically that when the grid refreshes it makes a request for > > > a new image on the back- end with the appropriate timeframe and the > > > back-end generates the image which is easy to embed inside the grid. > > > > > > pros: > > > * Easy to embed inside grid (just an image tag). > > > * Works on all browsers, even ones without HTML5 canvas support. > > > cons: > > > * More load on the back-end. > > > * Extra round trips to back-end on refresh. > > > * Not 'hot' like HTML5 canvas. > > > * No interactivity if that is something we are interested in. > > > > some more cons: > > * need to remember the statistics on server in the memory. For thousands of > > VMs it is not something we would like to do * lots of overhead to retrieve > > all the images on each refresh. If you have 100 VMs on a page and refresh > > each 5 seconds, it is 100 images transmitted from engine to frontend each 5 > > seconds per one client (and we can have more of them of course) * FE logic > > on Server is in general not awesome > > > > I would expect the statistics to be stored in the database somewhere, that > way > we can pull them for reports and things of that nature (like charts). > Obviously we wouldn't do 100 round trips for the image, we would generate a > single image sprite that would contain all the images in a single request and > display the appropriate part of the image in the grid. > > You are right in general front-end logic is not done on the back-end. However > we must consider if we are really doing front end logic here, or if we are > just displaying some reporting information as part of the grid. > > If we are not storing the statistics anywhere, then this is a terrible plan, > and we should do the logic on the client, but if we are, it is something to > consider. We store only the actual value. The statistics are stored only by DWH but that is a different application. Engine itself does not have it so we would have to implement it. > > > > > == From L&F point of view == > > > > - would look pretty much like the one proposed by Malini: > > > > http://style.org/chartapi/sparklines/ > > > > > > > > == From data point of view == > > > > - do not do any averages on VDSM side (since it already does them for > > > > CPU > > > > and network and the memory is stable enough) - do not do any averages > > > > on > > > > engine side (since would have to be done for each FE separately and > > > > stored > > > > in session which is a bit overcomplicated. If the user wants to see > > > > more > > > > accurate data, he/she can change the refresh rate) - do not do any > > > > interpolation since the data are already averaged and we will show only > > > > new > > > > ones > > > > > > > > @Malini,Einav,Eldan,Michal what do you think? > > > > > > > > Tomas > > > > > > > > ----- Original Message ----- > > > > > > > > > From: "Michal Skrivanek" > > > > > To: "Tomas Jelinek" , "Dan Kenigsberg" > > > > > Cc: "Malini Rao" , "Eldan > > > > > Hildesheim" , engine-devel at ovirt.org, "info" > > > > > > > > > > Sent: Tuesday, November 12, 2013 11:49:12 AM > > > > > Subject: Re: [Engine-devel] [UX] how to design a bar/line chart? > > > > > > > > > > On Nov 12, 2013, at 11:18 , Tomas Jelinek > > > > > wrote: > > > > > > So we have looked into the resource usage sampling with mbetak and > > > > > > also > > > > > > with Michal and it seems that > > > > > > > > > > > > for the CPU usage: > > > > > > - VDSM polls libvirt to get the runtime statistics of the VM > > > > > > regularly. > > > > > > The > > > > > > pooling interval is configured in > > > > > > > > > > > > vdsm.conf as vm_sample_cpu_interval and by default it is 15 > > > > > > seconds > > > > > > > > > > > > - libvirt returns something we than use to calculate the average > > > > > > CPU > > > > > > usage > > > > > > since the last poll > > > > > > - engine polls VDSM once in 15 seconds to get the current > > > > > > statistics > > > > > > (the > > > > > > same 15 seconds is just a coincidence and we can not count on this) > > > > > > - than the frontend polls the engine each 5-60 seconds (depends on > > > > > > the > > > > > > refresh rate) and gets the current value from the engine > > > > > > - the user can press the refresh button anytime to poll the engine > > > > > > again > > > > > > > > > > > > For network usage: > > > > > > - it should be pretty much the same as the CPU just the VDSM poll > > > > > > interval > > > > > > is configured as vm_sample_net_interval and by default it is 5 > > > > > > seconds > > > > > > > > > > Dan, since we poll only every 15s and cpu info is 15s wouldn't it > > > > > make > > > > > sense to change the default for network monitoring to 15s as well? > > > > > it's 2 > > > > > libvirt rounds trip for nothing really. Or does it serve some other > > > > > purpose?> > > > > > > > > > > > For memory usage: > > > > > > - guest agent sends a message to VDSM with the memory usage > > > > > > regularly. > > > > > > The > > > > > > interval is set in ovirt-guest-agent.conf as heart_beat_rate > > > > > > > > > > > > and by default it is 5 seconds > > > > > > > > > > > > - the actual value sent by ovirt-guest-agent is the actual value at > > > > > > the > > > > > > time when the value is sent (e.g. for Linux taken from "cat > > > > > > /proc/meminfo") > > > > > > - vdsm is doing no statistics on top of it, just remembers the last > > > > > > value > > > > > > taken from ovirt-guest-agent > > > > > > > > > > which is fine, it doesn't change so often and there are typically no > > > > > spikes > > > > > > > > > > > - the rest of the poling is the same > > > > > > > > > > > > So, visualizing this in some usable form will be quite challenging > > > > > > ;) > > > > > > I see the following problems: > > > > > > - if the VDSM gets the data faster than the engine polls it (and > > > > > > most > > > > > > often > > > > > > it does) than the info in between will be lost. > > > > > > > > > > > > The question is how big this problem is and if it is worth solving > > > > > > (I > > > > > > would say not for CPU which are averages but maybe yes for > > > > > > memory). > > > > > > Other question if there is a way how to solve it since the VDSM > > > > > > can > > > > > > be > > > > > > polled by anyone and it does not really care if someone polls > > > > > > it... > > > > > > (Michal?) > > > > > > > > > > I'd say not solve it and try to keep it in sync on vdsm side with > > > > > engine > > > > > poll, to save unnecessary libvirt calls > > > > > > > > > > > - we can lost some data between frontend<->engine if the polling > > > > > > interval > > > > > > of the FE is slower than the polling interval of the engine. This > > > > > > is > > > > > > something > > > > > > > > > > > > not really worth solving because the user can set this according > > > > > > to > > > > > > the > > > > > > level of detail he/she wants > > > > > > > > > > well, you should average the values in engine in case the FE refresh > > > > > is > > > > > > > > > > >15s. Or add (refresh/15) of them > > > > > > > > It is not that simple since you can have more frontends and not sure if > > > > it > > > > would be a good idea to put this into the session... > > > > > > > > > > - since we will get new info once in ~15 seconds, and the polling > > > > > > of > > > > > > the > > > > > > FE > > > > > > is by default 5 seconds, do we want to do some interpolation? Or > > > > > > just > > > > > > show > > > > > > the > > > > > > > > > > > > same value 3 times? Or be smart and show only changed values? > > > > > > (this > > > > > > is > > > > > > tricky since there is a chance that it did not change - e.g. > > > > > > constant > > > > > > 0 > > > > > > mem usage if you have no guest agent) > > > > > > > > > > > > - What if the user starts clicking to the refresh button? Do we > > > > > > want > > > > > > to > > > > > > keep appending the same value if the engine still has only the old > > > > > > ones? > > > > > > > > > > just add a new line/point every 15s should be ok > > > > > > > > > > Thanks, > > > > > michal > > > > > > > > > > > Tomas > > > > > > > > > > > > ----- Original Message ----- > > > > > > > > > > > >> From: "Tomas Jelinek" > > > > > >> To: "Malini Rao" > > > > > >> Cc: "Eldan Hildesheim" , > > > > > >> engine-devel at ovirt.org, > > > > > >> "info" > > > > > >> Sent: Monday, November 11, 2013 4:23:09 PM > > > > > >> Subject: Re: [Engine-devel] [UX] how to design a bar/line chart? > > > > > >> > > > > > >> > > > > > >> > > > > > >> ----- Original Message ----- > > > > > >> > > > > > >>> From: "Malini Rao" > > > > > >>> To: "Eldan Hildesheim" > > > > > >>> Cc: "Tomas Jelinek" , "info" > > > > > >>> , > > > > > >>> engine-devel at ovirt.org > > > > > >>> Sent: Monday, November 11, 2013 4:15:50 PM > > > > > >>> Subject: Re: [Engine-devel] [UX] how to design a bar/line chart? > > > > > >>> > > > > > >>> Is this going to fit in a row of a table? Or are we talking of a > > > > > >>> more > > > > > >>> detailed view? > > > > > >> > > > > > >> it should fit into one cell of the table > > > > > >> > > > > > >>> ----- Original Message ----- > > > > > >>> From: "Eldan Hildesheim" > > > > > >>> To: "Tomas Jelinek" > > > > > >>> Cc: "info" , engine-devel at ovirt.org > > > > > >>> Sent: Monday, November 11, 2013 8:01:07 AM > > > > > >>> Subject: Re: [Engine-devel] [UX] how to design a bar/line chart? > > > > > >>> > > > > > >>> Throw this gif into a browser. This is more or less what I > > > > > >>> thought. > > > > > >>> Eldan > > > > > >>> > > > > > >>> ----- Original Message ----- > > > > > >>> From: "Tomas Jelinek" > > > > > >>> To: "Eldan Hildesheim" > > > > > >>> Cc: "Einav Cohen" , "info" , > > > > > >>> engine-devel at ovirt.org > > > > > >>> Sent: Monday, November 11, 2013 12:03:15 PM > > > > > >>> Subject: Re: [Engine-devel] [UX] how to design a bar/line chart? > > > > > >>> > > > > > >>> > > > > > >>> > > > > > >>> ----- Original Message ----- > > > > > >>> > > > > > >>>> From: "Eldan Hildesheim" > > > > > >>>> To: "Einav Cohen" > > > > > >>>> Cc: "info" , engine-devel at ovirt.org > > > > > >>>> Sent: Sunday, November 10, 2013 3:56:57 PM > > > > > >>>> Subject: Re: [Engine-devel] [UX] how to design a bar/line chart? > > > > > >>>> > > > > > >>>> Hello all, > > > > > >>>> We use to have a good solution in the period pre-WPF. > > > > > >>>> A line chart (used to be in flash) that works like a plotter: > > > > > >>>> The Line Bar (not bar) had a small animation that shifted all > > > > > >>>> the > > > > > >>>> bar > > > > > >>>> to > > > > > >>>> the > > > > > >>>> left. > > > > > >>>> When a new data arrived it just added a new line (to the right) > > > > > >>>> and > > > > > >>>> as I > > > > > >>>> said > > > > > >>>> before, in parallel it always shifted slowly to the left. > > > > > >>> > > > > > >>> Any chance you still have some screenshot or mockup so I can > > > > > >>> imagine > > > > > >>> it > > > > > >>> better? > > > > > >>> > > > > > >>>> The animation gives the impression that data is streaming and > > > > > >>>> when a > > > > > >>>> real > > > > > >>>> new > > > > > >>>> data arrives the user gets it very fast. > > > > > >>>> We have to sync between the animation and the rate of the > > > > > >>>> arrival > > > > > >>>> of > > > > > >>>> the > > > > > >>>> data > > > > > >>>> but this is easy. > > > > > >>>> If we can't find a good framework it can be created from scratch > > > > > >>>> with > > > > > >>>> JS, > > > > > >>>> svg > > > > > >>>> or canvas. > > > > > >>> > > > > > >>> We need to be careful about what we will use. oVirt is supposed > > > > > >>> to > > > > > >>> work > > > > > >>> on > > > > > >>> FF > > > > > >>> 17 [1] > > > > > >>> but the HTML5 canvas works only since FF23 [2]. > > > > > >>> > > > > > >>> @Einav: > > > > > >>> Is there a chance that we could start support only FF23+ and IE9+ > > > > > >>> (this > > > > > >>> one > > > > > >>> is already OK) > > > > > >>> because of this feature? > > > > > >>> > > > > > >>>> Now regarding its position: > > > > > >>>> Rollover is good but not enough, we should somehow put it in the > > > > > >>>> lower > > > > > >>>> panel > > > > > >>>> under general or even another tab - (live data). > > > > > >>> > > > > > >>> This is a bit different requirement. The point of this specific > > > > > >>> is > > > > > >>> to > > > > > >>> give > > > > > >>> a > > > > > >>> better > > > > > >>> overview in the main tab. If it will be done we can decide if we > > > > > >>> want > > > > > >>> to > > > > > >>> give > > > > > >>> more > > > > > >>> details in sub tabs. > > > > > >>> > > > > > >>>> We could later on have a (live data Tab) in other places as well > > > > > >>>> like > > > > > >>>> host, > > > > > >>>> cluster... > > > > > >>>> Eldan > > > > > >>> > > > > > >>> [1]: http://www.ovirt.org/Download > > > > > >>> [2]: http://caniuse.com/#feat=canvas > > > > > >>> > > > > > >>>> ----- Original Message ----- > > > > > >>>> From: "Einav Cohen" > > > > > >>>> To: "Ewoud Kohl van Wijngaarden" > > > > > >>>> > > > > > >>>> Cc: "Alexander Wels" , "Eldan Hildesheim" > > > > > >>>> , engine-devel at ovirt.org, "info" > > > > > >>>> > > > > > >>>> Sent: Friday, November 8, 2013 10:50:10 PM > > > > > >>>> Subject: Re: [Engine-devel] [UX] how to design a bar/line chart? > > > > > >>>> > > > > > >>>>> ----- Original Message ----- > > > > > >>>>> From: "Ewoud Kohl van Wijngaarden" > > > > > >>>>> > > > > > >>>>> Sent: Thursday, November 7, 2013 11:44:07 AM > > > > > >>>>> > > > > > >>>>> On Wed, Nov 06, 2013 at 11:45:36AM -0500, 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. > > > > > >>>>> > > > > > >>>>> I'd say no. Even from a reliability point of view since users > > > > > >>>>> may > > > > > >>>>> have > > > > > >>>>> systems that aren't connected to the internet. > > > > > >>>> > > > > > >>>> +1 > > > > > >>>> > > > > > >>>>> (Though I don't know how well oVirt handles this currently.) > > > > > >>>> > > > > > >>>> AFAIK - oVirt is handling it ('it' == having no internet > > > > > >>>> connection) > > > > > >>>> well. > > > > > >>>> _______________________________________________ > > > > > >>>> Engine-devel mailing list > > > > > >>>> Engine-devel at ovirt.org > > > > > >>>> http://lists.ovirt.org/mailman/listinfo/engine-devel > > > > > >>> > > > > > >>> _______________________________________________ > > > > > >>> Engine-devel mailing list > > > > > >>> Engine-devel at ovirt.org > > > > > >>> http://lists.ovirt.org/mailman/listinfo/engine-devel > > > > > >> > > > > > >> _______________________________________________ > > > > > >> Engine-devel mailing list > > > > > >> Engine-devel at ovirt.org > > > > > >> http://lists.ovirt.org/mailman/listinfo/engine-devel > > > > > > > > _______________________________________________ > > > > Engine-devel mailing list > > > > Engine-devel at ovirt.org > > > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > From awels at redhat.com Tue Nov 12 15:52:12 2013 From: awels at redhat.com (Alexander Wels) Date: Tue, 12 Nov 2013 10:52:12 -0500 Subject: [Engine-devel] [UX] how to design a bar/line chart? In-Reply-To: <709457129.22382323.1384269675421.JavaMail.root@redhat.com> References: <157528892.18409921.1383645002815.JavaMail.root@redhat.com> <1562637.RCtmcDAuT8@awels> <709457129.22382323.1384269675421.JavaMail.root@redhat.com> Message-ID: <346089019.FDH9RSlcBF@awels> On Tuesday, November 12, 2013 10:21:15 AM Tomas Jelinek wrote: > ----- Original Message ----- > > > From: "Alexander Wels" > > To: "Tomas Jelinek" > > Cc: engine-devel at ovirt.org, "Michal Skrivanek" > > , "Eldan Hildesheim" , > > "info" > > Sent: Tuesday, November 12, 2013 4:03:14 PM > > Subject: Re: [Engine-devel] [UX] how to design a bar/line chart? > > > > On Tuesday, November 12, 2013 09:50:07 AM Tomas Jelinek wrote: > > > ----- Original Message ----- > > > > > > > From: "Alexander Wels" > > > > To: engine-devel at ovirt.org > > > > Cc: "Tomas Jelinek" , "Michal Skrivanek" > > > > , "Eldan Hildesheim" > > > > , > > > > "info" > > > > Sent: Tuesday, November 12, 2013 3:33:56 PM > > > > Subject: Re: [Engine-devel] [UX] how to design a bar/line chart? > > > > > > > > On Tuesday, November 12, 2013 09:25:34 AM Tomas Jelinek wrote: > > > > > Hey all, > > > > > > > > > > let me conclude what has been written in this thread to one > > > > > proposal: > > > > > > > > > > == From the UX perspective the behavior == > > > > > - each time the FE will receive new data and this data are different > > > > > from > > > > > the old ones, visualize it in the chart It means if you will keep > > > > > pressing > > > > > the refresh button but the data will not change, no new data will be > > > > > visualized (an exception will be the 0 usage) - the amount of data > > > > > visualized will depend on the size of the widget (since the tables > > > > > are > > > > > resizable). It means that if you make the widget bigger you will not > > > > > see > > > > > the same chart bigger but more data. - If you make the widget > > > > > bigger, > > > > > only > > > > > then the amount of data will start to increase: e.g. > > > > > > > > > > before resize: > > > > > | /-------\ | > > > > > | > > > > > |/ \| > > > > > > > > > > after resize: > > > > > | /-------\ | > > > > > | > > > > > |/ \ | > > > > > > > > > > and only now the new data will start to appear > > > > > > > > > > == From FE technical point of view == > > > > > - since I have not found any GWT library which would be acceptable > > > > > (e.g. > > > > > actively developed and without the need to connect to google > > > > > servers) > > > > > and > > > > > given that the required chart is quite simple I guess it would be ok > > > > > to > > > > > write it by myself. - according to Einav's mail it is ok to use > > > > > HTML5 > > > > > canvas so I would go with writing a new widget using HTML5 canvas > > > > > > > > Just to throw out something to think about, we could also in theory > > > > generate an image on the server side and simply display that image > > > > inside > > > > the grid (so no need for HTML5 canvas or other things like that). The > > > > idea being basically that when the grid refreshes it makes a request > > > > for > > > > a new image on the back- end with the appropriate timeframe and the > > > > back-end generates the image which is easy to embed inside the grid. > > > > > > > > pros: > > > > * Easy to embed inside grid (just an image tag). > > > > * Works on all browsers, even ones without HTML5 canvas support. > > > > cons: > > > > * More load on the back-end. > > > > * Extra round trips to back-end on refresh. > > > > * Not 'hot' like HTML5 canvas. > > > > * No interactivity if that is something we are interested in. > > > > > > some more cons: > > > * need to remember the statistics on server in the memory. For thousands > > > of > > > VMs it is not something we would like to do * lots of overhead to > > > retrieve > > > all the images on each refresh. If you have 100 VMs on a page and > > > refresh > > > each 5 seconds, it is 100 images transmitted from engine to frontend > > > each 5 > > > seconds per one client (and we can have more of them of course) * FE > > > logic > > > on Server is in general not awesome > > > > I would expect the statistics to be stored in the database somewhere, that > > way > > we can pull them for reports and things of that nature (like charts). > > Obviously we wouldn't do 100 round trips for the image, we would generate > > a > > single image sprite that would contain all the images in a single request > > and display the appropriate part of the image in the grid. > > > > You are right in general front-end logic is not done on the back-end. > > However we must consider if we are really doing front end logic here, or > > if we are just displaying some reporting information as part of the grid. > > > > If we are not storing the statistics anywhere, then this is a terrible > > plan, and we should do the logic on the client, but if we are, it is > > something to consider. > > We store only the actual value. The statistics are stored only by DWH > but that is a different application. Engine itself does not have it so we > would have to implement it. > Which as you mentioned is not a desirable thing to do for thousands of VMs, but does bring up the question, if we only aggregate the statistics on the client, do we care if that information is lost when the user logs out/switches tab/etc. Since essentially we stop requesting that information from the back- end if the current active tab is not the VM main tab. > > > > > == From L&F point of view == > > > > > - would look pretty much like the one proposed by Malini: > > > > > http://style.org/chartapi/sparklines/ > > > > > > > > > > == From data point of view == > > > > > - do not do any averages on VDSM side (since it already does them > > > > > for > > > > > CPU > > > > > and network and the memory is stable enough) - do not do any > > > > > averages > > > > > on > > > > > engine side (since would have to be done for each FE separately and > > > > > stored > > > > > in session which is a bit overcomplicated. If the user wants to see > > > > > more > > > > > accurate data, he/she can change the refresh rate) - do not do any > > > > > interpolation since the data are already averaged and we will show > > > > > only > > > > > new > > > > > ones > > > > > > > > > > @Malini,Einav,Eldan,Michal what do you think? > > > > > > > > > > Tomas > > > > > > > > > > ----- Original Message ----- > > > > > > > > > > > From: "Michal Skrivanek" > > > > > > To: "Tomas Jelinek" , "Dan Kenigsberg" > > > > > > Cc: "Malini Rao" , "Eldan > > > > > > Hildesheim" , engine-devel at ovirt.org, "info" > > > > > > > > > > > > Sent: Tuesday, November 12, 2013 11:49:12 AM > > > > > > Subject: Re: [Engine-devel] [UX] how to design a bar/line chart? > > > > > > > > > > > > On Nov 12, 2013, at 11:18 , Tomas Jelinek > > > > > > > > > > > > wrote: > > > > > > > So we have looked into the resource usage sampling with mbetak > > > > > > > and > > > > > > > also > > > > > > > with Michal and it seems that > > > > > > > > > > > > > > for the CPU usage: > > > > > > > - VDSM polls libvirt to get the runtime statistics of the VM > > > > > > > regularly. > > > > > > > The > > > > > > > pooling interval is configured in > > > > > > > > > > > > > > vdsm.conf as vm_sample_cpu_interval and by default it is 15 > > > > > > > seconds > > > > > > > > > > > > > > - libvirt returns something we than use to calculate the average > > > > > > > CPU > > > > > > > usage > > > > > > > since the last poll > > > > > > > - engine polls VDSM once in 15 seconds to get the current > > > > > > > statistics > > > > > > > (the > > > > > > > same 15 seconds is just a coincidence and we can not count on > > > > > > > this) > > > > > > > - than the frontend polls the engine each 5-60 seconds (depends > > > > > > > on > > > > > > > the > > > > > > > refresh rate) and gets the current value from the engine > > > > > > > - the user can press the refresh button anytime to poll the > > > > > > > engine > > > > > > > again > > > > > > > > > > > > > > For network usage: > > > > > > > - it should be pretty much the same as the CPU just the VDSM > > > > > > > poll > > > > > > > interval > > > > > > > is configured as vm_sample_net_interval and by default it is 5 > > > > > > > seconds > > > > > > > > > > > > Dan, since we poll only every 15s and cpu info is 15s wouldn't it > > > > > > make > > > > > > sense to change the default for network monitoring to 15s as well? > > > > > > it's 2 > > > > > > libvirt rounds trip for nothing really. Or does it serve some > > > > > > other > > > > > > purpose?> > > > > > > > > > > > > > For memory usage: > > > > > > > - guest agent sends a message to VDSM with the memory usage > > > > > > > regularly. > > > > > > > The > > > > > > > interval is set in ovirt-guest-agent.conf as heart_beat_rate > > > > > > > > > > > > > > and by default it is 5 seconds > > > > > > > > > > > > > > - the actual value sent by ovirt-guest-agent is the actual value > > > > > > > at > > > > > > > the > > > > > > > time when the value is sent (e.g. for Linux taken from "cat > > > > > > > /proc/meminfo") > > > > > > > - vdsm is doing no statistics on top of it, just remembers the > > > > > > > last > > > > > > > value > > > > > > > taken from ovirt-guest-agent > > > > > > > > > > > > which is fine, it doesn't change so often and there are typically > > > > > > no > > > > > > spikes > > > > > > > > > > > > > - the rest of the poling is the same > > > > > > > > > > > > > > So, visualizing this in some usable form will be quite > > > > > > > challenging > > > > > > > ;) > > > > > > > I see the following problems: > > > > > > > - if the VDSM gets the data faster than the engine polls it (and > > > > > > > most > > > > > > > often > > > > > > > it does) than the info in between will be lost. > > > > > > > > > > > > > > The question is how big this problem is and if it is worth > > > > > > > solving > > > > > > > (I > > > > > > > would say not for CPU which are averages but maybe yes for > > > > > > > memory). > > > > > > > Other question if there is a way how to solve it since the VDSM > > > > > > > can > > > > > > > be > > > > > > > polled by anyone and it does not really care if someone polls > > > > > > > it... > > > > > > > (Michal?) > > > > > > > > > > > > I'd say not solve it and try to keep it in sync on vdsm side with > > > > > > engine > > > > > > poll, to save unnecessary libvirt calls > > > > > > > > > > > > > - we can lost some data between frontend<->engine if the polling > > > > > > > interval > > > > > > > of the FE is slower than the polling interval of the engine. > > > > > > > This > > > > > > > is > > > > > > > something > > > > > > > > > > > > > > not really worth solving because the user can set this > > > > > > > according > > > > > > > to > > > > > > > the > > > > > > > level of detail he/she wants > > > > > > > > > > > > well, you should average the values in engine in case the FE > > > > > > refresh > > > > > > is > > > > > > > > > > > > >15s. Or add (refresh/15) of them > > > > > > > > > > It is not that simple since you can have more frontends and not sure > > > > > if > > > > > it > > > > > would be a good idea to put this into the session... > > > > > > > > > > > > - since we will get new info once in ~15 seconds, and the > > > > > > > polling > > > > > > > of > > > > > > > the > > > > > > > FE > > > > > > > is by default 5 seconds, do we want to do some interpolation? Or > > > > > > > just > > > > > > > show > > > > > > > the > > > > > > > > > > > > > > same value 3 times? Or be smart and show only changed values? > > > > > > > (this > > > > > > > is > > > > > > > tricky since there is a chance that it did not change - e.g. > > > > > > > constant > > > > > > > 0 > > > > > > > mem usage if you have no guest agent) > > > > > > > > > > > > > > - What if the user starts clicking to the refresh button? Do we > > > > > > > want > > > > > > > to > > > > > > > keep appending the same value if the engine still has only the > > > > > > > old > > > > > > > ones? > > > > > > > > > > > > just add a new line/point every 15s should be ok > > > > > > > > > > > > Thanks, > > > > > > michal > > > > > > > > > > > > > Tomas > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > > > > > > > >> From: "Tomas Jelinek" > > > > > > >> To: "Malini Rao" > > > > > > >> Cc: "Eldan Hildesheim" , > > > > > > >> engine-devel at ovirt.org, > > > > > > >> "info" > > > > > > >> Sent: Monday, November 11, 2013 4:23:09 PM > > > > > > >> Subject: Re: [Engine-devel] [UX] how to design a bar/line > > > > > > >> chart? > > > > > > >> > > > > > > >> > > > > > > >> > > > > > > >> ----- Original Message ----- > > > > > > >> > > > > > > >>> From: "Malini Rao" > > > > > > >>> To: "Eldan Hildesheim" > > > > > > >>> Cc: "Tomas Jelinek" , "info" > > > > > > >>> , > > > > > > >>> engine-devel at ovirt.org > > > > > > >>> Sent: Monday, November 11, 2013 4:15:50 PM > > > > > > >>> Subject: Re: [Engine-devel] [UX] how to design a bar/line > > > > > > >>> chart? > > > > > > >>> > > > > > > >>> Is this going to fit in a row of a table? Or are we talking of > > > > > > >>> a > > > > > > >>> more > > > > > > >>> detailed view? > > > > > > >> > > > > > > >> it should fit into one cell of the table > > > > > > >> > > > > > > >>> ----- Original Message ----- > > > > > > >>> From: "Eldan Hildesheim" > > > > > > >>> To: "Tomas Jelinek" > > > > > > >>> Cc: "info" , engine-devel at ovirt.org > > > > > > >>> Sent: Monday, November 11, 2013 8:01:07 AM > > > > > > >>> Subject: Re: [Engine-devel] [UX] how to design a bar/line > > > > > > >>> chart? > > > > > > >>> > > > > > > >>> Throw this gif into a browser. This is more or less what I > > > > > > >>> thought. > > > > > > >>> Eldan > > > > > > >>> > > > > > > >>> ----- Original Message ----- > > > > > > >>> From: "Tomas Jelinek" > > > > > > >>> To: "Eldan Hildesheim" > > > > > > >>> Cc: "Einav Cohen" , "info" > > > > > > >>> , > > > > > > >>> engine-devel at ovirt.org > > > > > > >>> Sent: Monday, November 11, 2013 12:03:15 PM > > > > > > >>> Subject: Re: [Engine-devel] [UX] how to design a bar/line > > > > > > >>> chart? > > > > > > >>> > > > > > > >>> > > > > > > >>> > > > > > > >>> ----- Original Message ----- > > > > > > >>> > > > > > > >>>> From: "Eldan Hildesheim" > > > > > > >>>> To: "Einav Cohen" > > > > > > >>>> Cc: "info" , engine-devel at ovirt.org > > > > > > >>>> Sent: Sunday, November 10, 2013 3:56:57 PM > > > > > > >>>> Subject: Re: [Engine-devel] [UX] how to design a bar/line > > > > > > >>>> chart? > > > > > > >>>> > > > > > > >>>> Hello all, > > > > > > >>>> We use to have a good solution in the period pre-WPF. > > > > > > >>>> A line chart (used to be in flash) that works like a plotter: > > > > > > >>>> The Line Bar (not bar) had a small animation that shifted all > > > > > > >>>> the > > > > > > >>>> bar > > > > > > >>>> to > > > > > > >>>> the > > > > > > >>>> left. > > > > > > >>>> When a new data arrived it just added a new line (to the > > > > > > >>>> right) > > > > > > >>>> and > > > > > > >>>> as I > > > > > > >>>> said > > > > > > >>>> before, in parallel it always shifted slowly to the left. > > > > > > >>> > > > > > > >>> Any chance you still have some screenshot or mockup so I can > > > > > > >>> imagine > > > > > > >>> it > > > > > > >>> better? > > > > > > >>> > > > > > > >>>> The animation gives the impression that data is streaming and > > > > > > >>>> when a > > > > > > >>>> real > > > > > > >>>> new > > > > > > >>>> data arrives the user gets it very fast. > > > > > > >>>> We have to sync between the animation and the rate of the > > > > > > >>>> arrival > > > > > > >>>> of > > > > > > >>>> the > > > > > > >>>> data > > > > > > >>>> but this is easy. > > > > > > >>>> If we can't find a good framework it can be created from > > > > > > >>>> scratch > > > > > > >>>> with > > > > > > >>>> JS, > > > > > > >>>> svg > > > > > > >>>> or canvas. > > > > > > >>> > > > > > > >>> We need to be careful about what we will use. oVirt is > > > > > > >>> supposed > > > > > > >>> to > > > > > > >>> work > > > > > > >>> on > > > > > > >>> FF > > > > > > >>> 17 [1] > > > > > > >>> but the HTML5 canvas works only since FF23 [2]. > > > > > > >>> > > > > > > >>> @Einav: > > > > > > >>> Is there a chance that we could start support only FF23+ and > > > > > > >>> IE9+ > > > > > > >>> (this > > > > > > >>> one > > > > > > >>> is already OK) > > > > > > >>> because of this feature? > > > > > > >>> > > > > > > >>>> Now regarding its position: > > > > > > >>>> Rollover is good but not enough, we should somehow put it in > > > > > > >>>> the > > > > > > >>>> lower > > > > > > >>>> panel > > > > > > >>>> under general or even another tab - (live data). > > > > > > >>> > > > > > > >>> This is a bit different requirement. The point of this > > > > > > >>> specific > > > > > > >>> is > > > > > > >>> to > > > > > > >>> give > > > > > > >>> a > > > > > > >>> better > > > > > > >>> overview in the main tab. If it will be done we can decide if > > > > > > >>> we > > > > > > >>> want > > > > > > >>> to > > > > > > >>> give > > > > > > >>> more > > > > > > >>> details in sub tabs. > > > > > > >>> > > > > > > >>>> We could later on have a (live data Tab) in other places as > > > > > > >>>> well > > > > > > >>>> like > > > > > > >>>> host, > > > > > > >>>> cluster... > > > > > > >>>> Eldan > > > > > > >>> > > > > > > >>> [1]: http://www.ovirt.org/Download > > > > > > >>> [2]: http://caniuse.com/#feat=canvas > > > > > > >>> > > > > > > >>>> ----- Original Message ----- > > > > > > >>>> From: "Einav Cohen" > > > > > > >>>> To: "Ewoud Kohl van Wijngaarden" > > > > > > >>>> > > > > > > >>>> Cc: "Alexander Wels" , "Eldan Hildesheim" > > > > > > >>>> , engine-devel at ovirt.org, "info" > > > > > > >>>> > > > > > > >>>> Sent: Friday, November 8, 2013 10:50:10 PM > > > > > > >>>> Subject: Re: [Engine-devel] [UX] how to design a bar/line > > > > > > >>>> chart? > > > > > > >>>> > > > > > > >>>>> ----- Original Message ----- > > > > > > >>>>> From: "Ewoud Kohl van Wijngaarden" > > > > > > >>>>> > > > > > > >>>>> Sent: Thursday, November 7, 2013 11:44:07 AM > > > > > > >>>>> > > > > > > >>>>> On Wed, Nov 06, 2013 at 11:45:36AM -0500, 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. > > > > > > >>>>> > > > > > > >>>>> I'd say no. Even from a reliability point of view since > > > > > > >>>>> users > > > > > > >>>>> may > > > > > > >>>>> have > > > > > > >>>>> systems that aren't connected to the internet. > > > > > > >>>> > > > > > > >>>> +1 > > > > > > >>>> > > > > > > >>>>> (Though I don't know how well oVirt handles this currently.) > > > > > > >>>> > > > > > > >>>> AFAIK - oVirt is handling it ('it' == having no internet > > > > > > >>>> connection) > > > > > > >>>> well. > > > > > > >>>> _______________________________________________ > > > > > > >>>> Engine-devel mailing list > > > > > > >>>> Engine-devel at ovirt.org > > > > > > >>>> http://lists.ovirt.org/mailman/listinfo/engine-devel > > > > > > >>> > > > > > > >>> _______________________________________________ > > > > > > >>> Engine-devel mailing list > > > > > > >>> Engine-devel at ovirt.org > > > > > > >>> http://lists.ovirt.org/mailman/listinfo/engine-devel > > > > > > >> > > > > > > >> _______________________________________________ > > > > > > >> Engine-devel mailing list > > > > > > >> Engine-devel at ovirt.org > > > > > > >> http://lists.ovirt.org/mailman/listinfo/engine-devel > > > > > > > > > > _______________________________________________ > > > > > Engine-devel mailing list > > > > > Engine-devel at ovirt.org > > > > > http://lists.ovirt.org/mailman/listinfo/engine-devel From tjelinek at redhat.com Wed Nov 13 07:21:56 2013 From: tjelinek at redhat.com (Tomas Jelinek) Date: Wed, 13 Nov 2013 02:21:56 -0500 (EST) Subject: [Engine-devel] [UX] how to design a bar/line chart? In-Reply-To: <346089019.FDH9RSlcBF@awels> References: <157528892.18409921.1383645002815.JavaMail.root@redhat.com> <1562637.RCtmcDAuT8@awels> <709457129.22382323.1384269675421.JavaMail.root@redhat.com> <346089019.FDH9RSlcBF@awels> Message-ID: <1174264806.22909547.1384327316441.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Alexander Wels" > To: "Tomas Jelinek" > Cc: engine-devel at ovirt.org, "Michal Skrivanek" , "Eldan Hildesheim" > , "info" > Sent: Tuesday, November 12, 2013 4:52:12 PM > Subject: Re: [Engine-devel] [UX] how to design a bar/line chart? > > On Tuesday, November 12, 2013 10:21:15 AM Tomas Jelinek wrote: > > ----- Original Message ----- > > > > > From: "Alexander Wels" > > > To: "Tomas Jelinek" > > > Cc: engine-devel at ovirt.org, "Michal Skrivanek" > > > , "Eldan Hildesheim" , > > > "info" > > > Sent: Tuesday, November 12, 2013 4:03:14 PM > > > Subject: Re: [Engine-devel] [UX] how to design a bar/line chart? > > > > > > On Tuesday, November 12, 2013 09:50:07 AM Tomas Jelinek wrote: > > > > ----- Original Message ----- > > > > > > > > > From: "Alexander Wels" > > > > > To: engine-devel at ovirt.org > > > > > Cc: "Tomas Jelinek" , "Michal Skrivanek" > > > > > , "Eldan Hildesheim" > > > > > , > > > > > "info" > > > > > Sent: Tuesday, November 12, 2013 3:33:56 PM > > > > > Subject: Re: [Engine-devel] [UX] how to design a bar/line chart? > > > > > > > > > > On Tuesday, November 12, 2013 09:25:34 AM Tomas Jelinek wrote: > > > > > > Hey all, > > > > > > > > > > > > let me conclude what has been written in this thread to one > > > > > > proposal: > > > > > > > > > > > > == From the UX perspective the behavior == > > > > > > - each time the FE will receive new data and this data are > > > > > > different > > > > > > from > > > > > > the old ones, visualize it in the chart It means if you will keep > > > > > > pressing > > > > > > the refresh button but the data will not change, no new data will > > > > > > be > > > > > > visualized (an exception will be the 0 usage) - the amount of data > > > > > > visualized will depend on the size of the widget (since the tables > > > > > > are > > > > > > resizable). It means that if you make the widget bigger you will > > > > > > not > > > > > > see > > > > > > the same chart bigger but more data. - If you make the widget > > > > > > bigger, > > > > > > only > > > > > > then the amount of data will start to increase: e.g. > > > > > > > > > > > > before resize: > > > > > > | /-------\ | > > > > > > | > > > > > > |/ \| > > > > > > > > > > > > after resize: > > > > > > | /-------\ | > > > > > > | > > > > > > |/ \ | > > > > > > > > > > > > and only now the new data will start to appear > > > > > > > > > > > > == From FE technical point of view == > > > > > > - since I have not found any GWT library which would be acceptable > > > > > > (e.g. > > > > > > actively developed and without the need to connect to google > > > > > > servers) > > > > > > and > > > > > > given that the required chart is quite simple I guess it would be > > > > > > ok > > > > > > to > > > > > > write it by myself. - according to Einav's mail it is ok to use > > > > > > HTML5 > > > > > > canvas so I would go with writing a new widget using HTML5 canvas > > > > > > > > > > Just to throw out something to think about, we could also in theory > > > > > generate an image on the server side and simply display that image > > > > > inside > > > > > the grid (so no need for HTML5 canvas or other things like that). The > > > > > idea being basically that when the grid refreshes it makes a request > > > > > for > > > > > a new image on the back- end with the appropriate timeframe and the > > > > > back-end generates the image which is easy to embed inside the grid. > > > > > > > > > > pros: > > > > > * Easy to embed inside grid (just an image tag). > > > > > * Works on all browsers, even ones without HTML5 canvas support. > > > > > cons: > > > > > * More load on the back-end. > > > > > * Extra round trips to back-end on refresh. > > > > > * Not 'hot' like HTML5 canvas. > > > > > * No interactivity if that is something we are interested in. > > > > > > > > some more cons: > > > > * need to remember the statistics on server in the memory. For > > > > thousands > > > > of > > > > VMs it is not something we would like to do * lots of overhead to > > > > retrieve > > > > all the images on each refresh. If you have 100 VMs on a page and > > > > refresh > > > > each 5 seconds, it is 100 images transmitted from engine to frontend > > > > each 5 > > > > seconds per one client (and we can have more of them of course) * FE > > > > logic > > > > on Server is in general not awesome > > > > > > I would expect the statistics to be stored in the database somewhere, > > > that > > > way > > > we can pull them for reports and things of that nature (like charts). > > > Obviously we wouldn't do 100 round trips for the image, we would generate > > > a > > > single image sprite that would contain all the images in a single request > > > and display the appropriate part of the image in the grid. > > > > > > You are right in general front-end logic is not done on the back-end. > > > However we must consider if we are really doing front end logic here, or > > > if we are just displaying some reporting information as part of the grid. > > > > > > If we are not storing the statistics anywhere, then this is a terrible > > > plan, and we should do the logic on the client, but if we are, it is > > > something to consider. > > > > We store only the actual value. The statistics are stored only by DWH > > but that is a different application. Engine itself does not have it so we > > would have to implement it. > > > > Which as you mentioned is not a desirable thing to do for thousands of VMs, > but does bring up the question, if we only aggregate the statistics on the > client, do we care if that information is lost when the user logs > out/switches > tab/etc. Since essentially we stop requesting that information from the back- > end if the current active tab is not the VM main tab. I would say it is not a problem. The VM tab is not for detailed statistics or history data. For this kind of data we have the reports portal. On the other hand it may be painful to go to the VM tab and see no statistics and get them updated each 15 seconds. So after couple of minutes you will maybe see something useful. Just don't click on any other tab, otherwise you will loose that all :) @Michal,Einav: Is this acceptable? > > > > > > > == From L&F point of view == > > > > > > - would look pretty much like the one proposed by Malini: > > > > > > http://style.org/chartapi/sparklines/ > > > > > > > > > > > > == From data point of view == > > > > > > - do not do any averages on VDSM side (since it already does them > > > > > > for > > > > > > CPU > > > > > > and network and the memory is stable enough) - do not do any > > > > > > averages > > > > > > on > > > > > > engine side (since would have to be done for each FE separately and > > > > > > stored > > > > > > in session which is a bit overcomplicated. If the user wants to see > > > > > > more > > > > > > accurate data, he/she can change the refresh rate) - do not do any > > > > > > interpolation since the data are already averaged and we will show > > > > > > only > > > > > > new > > > > > > ones > > > > > > > > > > > > @Malini,Einav,Eldan,Michal what do you think? > > > > > > > > > > > > Tomas > > > > > > > > > > > > ----- Original Message ----- > > > > > > > > > > > > > From: "Michal Skrivanek" > > > > > > > To: "Tomas Jelinek" , "Dan Kenigsberg" > > > > > > > Cc: "Malini Rao" , "Eldan > > > > > > > Hildesheim" , engine-devel at ovirt.org, "info" > > > > > > > > > > > > > > Sent: Tuesday, November 12, 2013 11:49:12 AM > > > > > > > Subject: Re: [Engine-devel] [UX] how to design a bar/line chart? > > > > > > > > > > > > > > On Nov 12, 2013, at 11:18 , Tomas Jelinek > > > > > > > > > > > > > > wrote: > > > > > > > > So we have looked into the resource usage sampling with mbetak > > > > > > > > and > > > > > > > > also > > > > > > > > with Michal and it seems that > > > > > > > > > > > > > > > > for the CPU usage: > > > > > > > > - VDSM polls libvirt to get the runtime statistics of the VM > > > > > > > > regularly. > > > > > > > > The > > > > > > > > pooling interval is configured in > > > > > > > > > > > > > > > > vdsm.conf as vm_sample_cpu_interval and by default it is 15 > > > > > > > > seconds > > > > > > > > > > > > > > > > - libvirt returns something we than use to calculate the > > > > > > > > average > > > > > > > > CPU > > > > > > > > usage > > > > > > > > since the last poll > > > > > > > > - engine polls VDSM once in 15 seconds to get the current > > > > > > > > statistics > > > > > > > > (the > > > > > > > > same 15 seconds is just a coincidence and we can not count on > > > > > > > > this) > > > > > > > > - than the frontend polls the engine each 5-60 seconds (depends > > > > > > > > on > > > > > > > > the > > > > > > > > refresh rate) and gets the current value from the engine > > > > > > > > - the user can press the refresh button anytime to poll the > > > > > > > > engine > > > > > > > > again > > > > > > > > > > > > > > > > For network usage: > > > > > > > > - it should be pretty much the same as the CPU just the VDSM > > > > > > > > poll > > > > > > > > interval > > > > > > > > is configured as vm_sample_net_interval and by default it is 5 > > > > > > > > seconds > > > > > > > > > > > > > > Dan, since we poll only every 15s and cpu info is 15s wouldn't it > > > > > > > make > > > > > > > sense to change the default for network monitoring to 15s as > > > > > > > well? > > > > > > > it's 2 > > > > > > > libvirt rounds trip for nothing really. Or does it serve some > > > > > > > other > > > > > > > purpose?> > > > > > > > > > > > > > > > For memory usage: > > > > > > > > - guest agent sends a message to VDSM with the memory usage > > > > > > > > regularly. > > > > > > > > The > > > > > > > > interval is set in ovirt-guest-agent.conf as heart_beat_rate > > > > > > > > > > > > > > > > and by default it is 5 seconds > > > > > > > > > > > > > > > > - the actual value sent by ovirt-guest-agent is the actual > > > > > > > > value > > > > > > > > at > > > > > > > > the > > > > > > > > time when the value is sent (e.g. for Linux taken from "cat > > > > > > > > /proc/meminfo") > > > > > > > > - vdsm is doing no statistics on top of it, just remembers the > > > > > > > > last > > > > > > > > value > > > > > > > > taken from ovirt-guest-agent > > > > > > > > > > > > > > which is fine, it doesn't change so often and there are typically > > > > > > > no > > > > > > > spikes > > > > > > > > > > > > > > > - the rest of the poling is the same > > > > > > > > > > > > > > > > So, visualizing this in some usable form will be quite > > > > > > > > challenging > > > > > > > > ;) > > > > > > > > I see the following problems: > > > > > > > > - if the VDSM gets the data faster than the engine polls it > > > > > > > > (and > > > > > > > > most > > > > > > > > often > > > > > > > > it does) than the info in between will be lost. > > > > > > > > > > > > > > > > The question is how big this problem is and if it is worth > > > > > > > > solving > > > > > > > > (I > > > > > > > > would say not for CPU which are averages but maybe yes for > > > > > > > > memory). > > > > > > > > Other question if there is a way how to solve it since the > > > > > > > > VDSM > > > > > > > > can > > > > > > > > be > > > > > > > > polled by anyone and it does not really care if someone polls > > > > > > > > it... > > > > > > > > (Michal?) > > > > > > > > > > > > > > I'd say not solve it and try to keep it in sync on vdsm side with > > > > > > > engine > > > > > > > poll, to save unnecessary libvirt calls > > > > > > > > > > > > > > > - we can lost some data between frontend<->engine if the > > > > > > > > polling > > > > > > > > interval > > > > > > > > of the FE is slower than the polling interval of the engine. > > > > > > > > This > > > > > > > > is > > > > > > > > something > > > > > > > > > > > > > > > > not really worth solving because the user can set this > > > > > > > > according > > > > > > > > to > > > > > > > > the > > > > > > > > level of detail he/she wants > > > > > > > > > > > > > > well, you should average the values in engine in case the FE > > > > > > > refresh > > > > > > > is > > > > > > > > > > > > > > >15s. Or add (refresh/15) of them > > > > > > > > > > > > It is not that simple since you can have more frontends and not > > > > > > sure > > > > > > if > > > > > > it > > > > > > would be a good idea to put this into the session... > > > > > > > > > > > > > > - since we will get new info once in ~15 seconds, and the > > > > > > > > polling > > > > > > > > of > > > > > > > > the > > > > > > > > FE > > > > > > > > is by default 5 seconds, do we want to do some interpolation? > > > > > > > > Or > > > > > > > > just > > > > > > > > show > > > > > > > > the > > > > > > > > > > > > > > > > same value 3 times? Or be smart and show only changed values? > > > > > > > > (this > > > > > > > > is > > > > > > > > tricky since there is a chance that it did not change - e.g. > > > > > > > > constant > > > > > > > > 0 > > > > > > > > mem usage if you have no guest agent) > > > > > > > > > > > > > > > > - What if the user starts clicking to the refresh button? Do we > > > > > > > > want > > > > > > > > to > > > > > > > > keep appending the same value if the engine still has only the > > > > > > > > old > > > > > > > > ones? > > > > > > > > > > > > > > just add a new line/point every 15s should be ok > > > > > > > > > > > > > > Thanks, > > > > > > > michal > > > > > > > > > > > > > > > Tomas > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > > > > > > > > > >> From: "Tomas Jelinek" > > > > > > > >> To: "Malini Rao" > > > > > > > >> Cc: "Eldan Hildesheim" , > > > > > > > >> engine-devel at ovirt.org, > > > > > > > >> "info" > > > > > > > >> Sent: Monday, November 11, 2013 4:23:09 PM > > > > > > > >> Subject: Re: [Engine-devel] [UX] how to design a bar/line > > > > > > > >> chart? > > > > > > > >> > > > > > > > >> > > > > > > > >> > > > > > > > >> ----- Original Message ----- > > > > > > > >> > > > > > > > >>> From: "Malini Rao" > > > > > > > >>> To: "Eldan Hildesheim" > > > > > > > >>> Cc: "Tomas Jelinek" , "info" > > > > > > > >>> , > > > > > > > >>> engine-devel at ovirt.org > > > > > > > >>> Sent: Monday, November 11, 2013 4:15:50 PM > > > > > > > >>> Subject: Re: [Engine-devel] [UX] how to design a bar/line > > > > > > > >>> chart? > > > > > > > >>> > > > > > > > >>> Is this going to fit in a row of a table? Or are we talking > > > > > > > >>> of > > > > > > > >>> a > > > > > > > >>> more > > > > > > > >>> detailed view? > > > > > > > >> > > > > > > > >> it should fit into one cell of the table > > > > > > > >> > > > > > > > >>> ----- Original Message ----- > > > > > > > >>> From: "Eldan Hildesheim" > > > > > > > >>> To: "Tomas Jelinek" > > > > > > > >>> Cc: "info" , engine-devel at ovirt.org > > > > > > > >>> Sent: Monday, November 11, 2013 8:01:07 AM > > > > > > > >>> Subject: Re: [Engine-devel] [UX] how to design a bar/line > > > > > > > >>> chart? > > > > > > > >>> > > > > > > > >>> Throw this gif into a browser. This is more or less what I > > > > > > > >>> thought. > > > > > > > >>> Eldan > > > > > > > >>> > > > > > > > >>> ----- Original Message ----- > > > > > > > >>> From: "Tomas Jelinek" > > > > > > > >>> To: "Eldan Hildesheim" > > > > > > > >>> Cc: "Einav Cohen" , "info" > > > > > > > >>> , > > > > > > > >>> engine-devel at ovirt.org > > > > > > > >>> Sent: Monday, November 11, 2013 12:03:15 PM > > > > > > > >>> Subject: Re: [Engine-devel] [UX] how to design a bar/line > > > > > > > >>> chart? > > > > > > > >>> > > > > > > > >>> > > > > > > > >>> > > > > > > > >>> ----- Original Message ----- > > > > > > > >>> > > > > > > > >>>> From: "Eldan Hildesheim" > > > > > > > >>>> To: "Einav Cohen" > > > > > > > >>>> Cc: "info" , engine-devel at ovirt.org > > > > > > > >>>> Sent: Sunday, November 10, 2013 3:56:57 PM > > > > > > > >>>> Subject: Re: [Engine-devel] [UX] how to design a bar/line > > > > > > > >>>> chart? > > > > > > > >>>> > > > > > > > >>>> Hello all, > > > > > > > >>>> We use to have a good solution in the period pre-WPF. > > > > > > > >>>> A line chart (used to be in flash) that works like a > > > > > > > >>>> plotter: > > > > > > > >>>> The Line Bar (not bar) had a small animation that shifted > > > > > > > >>>> all > > > > > > > >>>> the > > > > > > > >>>> bar > > > > > > > >>>> to > > > > > > > >>>> the > > > > > > > >>>> left. > > > > > > > >>>> When a new data arrived it just added a new line (to the > > > > > > > >>>> right) > > > > > > > >>>> and > > > > > > > >>>> as I > > > > > > > >>>> said > > > > > > > >>>> before, in parallel it always shifted slowly to the left. > > > > > > > >>> > > > > > > > >>> Any chance you still have some screenshot or mockup so I can > > > > > > > >>> imagine > > > > > > > >>> it > > > > > > > >>> better? > > > > > > > >>> > > > > > > > >>>> The animation gives the impression that data is streaming > > > > > > > >>>> and > > > > > > > >>>> when a > > > > > > > >>>> real > > > > > > > >>>> new > > > > > > > >>>> data arrives the user gets it very fast. > > > > > > > >>>> We have to sync between the animation and the rate of the > > > > > > > >>>> arrival > > > > > > > >>>> of > > > > > > > >>>> the > > > > > > > >>>> data > > > > > > > >>>> but this is easy. > > > > > > > >>>> If we can't find a good framework it can be created from > > > > > > > >>>> scratch > > > > > > > >>>> with > > > > > > > >>>> JS, > > > > > > > >>>> svg > > > > > > > >>>> or canvas. > > > > > > > >>> > > > > > > > >>> We need to be careful about what we will use. oVirt is > > > > > > > >>> supposed > > > > > > > >>> to > > > > > > > >>> work > > > > > > > >>> on > > > > > > > >>> FF > > > > > > > >>> 17 [1] > > > > > > > >>> but the HTML5 canvas works only since FF23 [2]. > > > > > > > >>> > > > > > > > >>> @Einav: > > > > > > > >>> Is there a chance that we could start support only FF23+ and > > > > > > > >>> IE9+ > > > > > > > >>> (this > > > > > > > >>> one > > > > > > > >>> is already OK) > > > > > > > >>> because of this feature? > > > > > > > >>> > > > > > > > >>>> Now regarding its position: > > > > > > > >>>> Rollover is good but not enough, we should somehow put it in > > > > > > > >>>> the > > > > > > > >>>> lower > > > > > > > >>>> panel > > > > > > > >>>> under general or even another tab - (live data). > > > > > > > >>> > > > > > > > >>> This is a bit different requirement. The point of this > > > > > > > >>> specific > > > > > > > >>> is > > > > > > > >>> to > > > > > > > >>> give > > > > > > > >>> a > > > > > > > >>> better > > > > > > > >>> overview in the main tab. If it will be done we can decide if > > > > > > > >>> we > > > > > > > >>> want > > > > > > > >>> to > > > > > > > >>> give > > > > > > > >>> more > > > > > > > >>> details in sub tabs. > > > > > > > >>> > > > > > > > >>>> We could later on have a (live data Tab) in other places as > > > > > > > >>>> well > > > > > > > >>>> like > > > > > > > >>>> host, > > > > > > > >>>> cluster... > > > > > > > >>>> Eldan > > > > > > > >>> > > > > > > > >>> [1]: http://www.ovirt.org/Download > > > > > > > >>> [2]: http://caniuse.com/#feat=canvas > > > > > > > >>> > > > > > > > >>>> ----- Original Message ----- > > > > > > > >>>> From: "Einav Cohen" > > > > > > > >>>> To: "Ewoud Kohl van Wijngaarden" > > > > > > > >>>> > > > > > > > >>>> Cc: "Alexander Wels" , "Eldan Hildesheim" > > > > > > > >>>> , engine-devel at ovirt.org, "info" > > > > > > > >>>> > > > > > > > >>>> Sent: Friday, November 8, 2013 10:50:10 PM > > > > > > > >>>> Subject: Re: [Engine-devel] [UX] how to design a bar/line > > > > > > > >>>> chart? > > > > > > > >>>> > > > > > > > >>>>> ----- Original Message ----- > > > > > > > >>>>> From: "Ewoud Kohl van Wijngaarden" > > > > > > > >>>>> > > > > > > > >>>>> Sent: Thursday, November 7, 2013 11:44:07 AM > > > > > > > >>>>> > > > > > > > >>>>> On Wed, Nov 06, 2013 at 11:45:36AM -0500, 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. > > > > > > > >>>>> > > > > > > > >>>>> I'd say no. Even from a reliability point of view since > > > > > > > >>>>> users > > > > > > > >>>>> may > > > > > > > >>>>> have > > > > > > > >>>>> systems that aren't connected to the internet. > > > > > > > >>>> > > > > > > > >>>> +1 > > > > > > > >>>> > > > > > > > >>>>> (Though I don't know how well oVirt handles this > > > > > > > >>>>> currently.) > > > > > > > >>>> > > > > > > > >>>> AFAIK - oVirt is handling it ('it' == having no internet > > > > > > > >>>> connection) > > > > > > > >>>> well. > > > > > > > >>>> _______________________________________________ > > > > > > > >>>> Engine-devel mailing list > > > > > > > >>>> Engine-devel at ovirt.org > > > > > > > >>>> http://lists.ovirt.org/mailman/listinfo/engine-devel > > > > > > > >>> > > > > > > > >>> _______________________________________________ > > > > > > > >>> Engine-devel mailing list > > > > > > > >>> Engine-devel at ovirt.org > > > > > > > >>> http://lists.ovirt.org/mailman/listinfo/engine-devel > > > > > > > >> > > > > > > > >> _______________________________________________ > > > > > > > >> Engine-devel mailing list > > > > > > > >> Engine-devel at ovirt.org > > > > > > > >> http://lists.ovirt.org/mailman/listinfo/engine-devel > > > > > > > > > > > > _______________________________________________ > > > > > > Engine-devel mailing list > > > > > > Engine-devel at ovirt.org > > > > > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > From jhernand at redhat.com Wed Nov 13 10:27:11 2013 From: jhernand at redhat.com (Juan Hernandez) Date: Wed, 13 Nov 2013 11:27:11 +0100 Subject: [Engine-devel] Question about Engine user session timeout In-Reply-To: <547034966.6308959.1382442271276.JavaMail.root@redhat.com> References: <798767402.5733756.1382363701499.JavaMail.root@redhat.com> <526618D0.9060700@redhat.com> <1591715216.6236208.1382433169405.JavaMail.root@redhat.com> <526651D6.2020900@redhat.com> <547034966.6308959.1382442271276.JavaMail.root@redhat.com> Message-ID: <528353FF.4060705@redhat.com> On 10/22/2013 01:44 PM, Vojtech Szocs wrote: > > ----- Original Message ----- >> From: "Itamar Heim" >> To: "Vojtech Szocs" >> Cc: "engine-devel" >> Sent: Tuesday, October 22, 2013 12:22:14 PM >> Subject: Re: [Engine-devel] Question about Engine user session timeout >> >> On 10/22/2013 10:12 AM, Vojtech Szocs wrote: >>> However, as we have two distinct values for Engine session timeout, I guess >>> my best shot is to do >>> "min(UserSessionTimeOutInterval,UserSessionTimeOutInvalidationInterval)" >>> and expose both via admin-only GetConfigurationValue query, but I'm not >>> sure this is the best approach.. >> >> shouldn't that be sum() rather than min? > > IIUC, the first config value (UserSessionTimeOutInterval) represents the delay between Engine startup and first "cleanExpiredUsersSessions" job execution. The second config value (UserSessionTimeOutInvalidationInterval) is the delay between subsequent executions of this job. This is why I thought it should be min() out of these two; user could open WebAdmin right after Engine startup or anytime after that. > > Both config values have validValues=-1,1..100000 so -1 could disable first (UserSessionTimeOutInterval) or subsequent (UserSessionTimeOutInvalidationInterval) job execution. I'm still confused why we have two values, though.. > >> I may be wrong, but I would bet that the reason for having two configuration options is that the method of the scheduler that we use requires those two parameters. As far as I can tell the only real value of the first parameter (UserSessionTimeOutInterval) is to disable completely session cleanup if the value is negative, and that seems mostly useless, as doing so would generate a memory leak. I would suggest to completely remove the first parameter. I will then be clear that for your purpose the only relevant one is the second. -- Direcci?n Comercial: C/Jose Bardasano Baos, 9, Edif. Gorbea 3, planta 3?D, 28016 Madrid, Spain Inscrita en el Reg. Mercantil de Madrid ? C.I.F. B82657941 - Red Hat S.L. From tjelinek at redhat.com Wed Nov 13 13:42:40 2013 From: tjelinek at redhat.com (Tomas Jelinek) Date: Wed, 13 Nov 2013 08:42:40 -0500 (EST) Subject: [Engine-devel] [UX] how to design a bar/line chart? In-Reply-To: <1174264806.22909547.1384327316441.JavaMail.root@redhat.com> References: <157528892.18409921.1383645002815.JavaMail.root@redhat.com> <1562637.RCtmcDAuT8@awels> <709457129.22382323.1384269675421.JavaMail.root@redhat.com> <346089019.FDH9RSlcBF@awels> <1174264806.22909547.1384327316441.JavaMail.root@redhat.com> Message-ID: <827199354.23137395.1384350160740.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Tomas Jelinek" > To: awels at redhat.com > Cc: "Eldan Hildesheim" , engine-devel at ovirt.org, "info" > Sent: Wednesday, November 13, 2013 8:21:56 AM > Subject: Re: [Engine-devel] [UX] how to design a bar/line chart? > > > > ----- Original Message ----- > > From: "Alexander Wels" > > To: "Tomas Jelinek" > > Cc: engine-devel at ovirt.org, "Michal Skrivanek" > > , "Eldan Hildesheim" > > , "info" > > Sent: Tuesday, November 12, 2013 4:52:12 PM > > Subject: Re: [Engine-devel] [UX] how to design a bar/line chart? > > > > On Tuesday, November 12, 2013 10:21:15 AM Tomas Jelinek wrote: > > > ----- Original Message ----- > > > > > > > From: "Alexander Wels" > > > > To: "Tomas Jelinek" > > > > Cc: engine-devel at ovirt.org, "Michal Skrivanek" > > > > , "Eldan Hildesheim" > > > > , > > > > "info" > > > > Sent: Tuesday, November 12, 2013 4:03:14 PM > > > > Subject: Re: [Engine-devel] [UX] how to design a bar/line chart? > > > > > > > > On Tuesday, November 12, 2013 09:50:07 AM Tomas Jelinek wrote: > > > > > ----- Original Message ----- > > > > > > > > > > > From: "Alexander Wels" > > > > > > To: engine-devel at ovirt.org > > > > > > Cc: "Tomas Jelinek" , "Michal Skrivanek" > > > > > > , "Eldan Hildesheim" > > > > > > , > > > > > > "info" > > > > > > Sent: Tuesday, November 12, 2013 3:33:56 PM > > > > > > Subject: Re: [Engine-devel] [UX] how to design a bar/line chart? > > > > > > > > > > > > On Tuesday, November 12, 2013 09:25:34 AM Tomas Jelinek wrote: > > > > > > > Hey all, > > > > > > > > > > > > > > let me conclude what has been written in this thread to one > > > > > > > proposal: > > > > > > > > > > > > > > == From the UX perspective the behavior == > > > > > > > - each time the FE will receive new data and this data are > > > > > > > different > > > > > > > from > > > > > > > the old ones, visualize it in the chart It means if you will keep > > > > > > > pressing > > > > > > > the refresh button but the data will not change, no new data will > > > > > > > be > > > > > > > visualized (an exception will be the 0 usage) - the amount of > > > > > > > data > > > > > > > visualized will depend on the size of the widget (since the > > > > > > > tables > > > > > > > are > > > > > > > resizable). It means that if you make the widget bigger you will > > > > > > > not > > > > > > > see > > > > > > > the same chart bigger but more data. - If you make the widget > > > > > > > bigger, > > > > > > > only > > > > > > > then the amount of data will start to increase: e.g. > > > > > > > > > > > > > > before resize: > > > > > > > | /-------\ | > > > > > > > | > > > > > > > |/ \| > > > > > > > > > > > > > > after resize: > > > > > > > | /-------\ | > > > > > > > | > > > > > > > |/ \ | > > > > > > > > > > > > > > and only now the new data will start to appear > > > > > > > > > > > > > > == From FE technical point of view == > > > > > > > - since I have not found any GWT library which would be > > > > > > > acceptable > > > > > > > (e.g. > > > > > > > actively developed and without the need to connect to google > > > > > > > servers) > > > > > > > and > > > > > > > given that the required chart is quite simple I guess it would be > > > > > > > ok > > > > > > > to > > > > > > > write it by myself. - according to Einav's mail it is ok to use > > > > > > > HTML5 > > > > > > > canvas so I would go with writing a new widget using HTML5 canvas > > > > > > > > > > > > Just to throw out something to think about, we could also in theory > > > > > > generate an image on the server side and simply display that image > > > > > > inside > > > > > > the grid (so no need for HTML5 canvas or other things like that). > > > > > > The > > > > > > idea being basically that when the grid refreshes it makes a > > > > > > request > > > > > > for > > > > > > a new image on the back- end with the appropriate timeframe and the > > > > > > back-end generates the image which is easy to embed inside the > > > > > > grid. > > > > > > > > > > > > pros: > > > > > > * Easy to embed inside grid (just an image tag). > > > > > > * Works on all browsers, even ones without HTML5 canvas support. > > > > > > cons: > > > > > > * More load on the back-end. > > > > > > * Extra round trips to back-end on refresh. > > > > > > * Not 'hot' like HTML5 canvas. > > > > > > * No interactivity if that is something we are interested in. > > > > > > > > > > some more cons: > > > > > * need to remember the statistics on server in the memory. For > > > > > thousands > > > > > of > > > > > VMs it is not something we would like to do * lots of overhead to > > > > > retrieve > > > > > all the images on each refresh. If you have 100 VMs on a page and > > > > > refresh > > > > > each 5 seconds, it is 100 images transmitted from engine to frontend > > > > > each 5 > > > > > seconds per one client (and we can have more of them of course) * FE > > > > > logic > > > > > on Server is in general not awesome > > > > > > > > I would expect the statistics to be stored in the database somewhere, > > > > that > > > > way > > > > we can pull them for reports and things of that nature (like charts). > > > > Obviously we wouldn't do 100 round trips for the image, we would > > > > generate > > > > a > > > > single image sprite that would contain all the images in a single > > > > request > > > > and display the appropriate part of the image in the grid. > > > > > > > > You are right in general front-end logic is not done on the back-end. > > > > However we must consider if we are really doing front end logic here, > > > > or > > > > if we are just displaying some reporting information as part of the > > > > grid. > > > > > > > > If we are not storing the statistics anywhere, then this is a terrible > > > > plan, and we should do the logic on the client, but if we are, it is > > > > something to consider. > > > > > > We store only the actual value. The statistics are stored only by DWH > > > but that is a different application. Engine itself does not have it so we > > > would have to implement it. > > > > > > > Which as you mentioned is not a desirable thing to do for thousands of VMs, > > but does bring up the question, if we only aggregate the statistics on the > > client, do we care if that information is lost when the user logs > > out/switches > > tab/etc. Since essentially we stop requesting that information from the > > back- > > end if the current active tab is not the VM main tab. > > I would say it is not a problem. The VM tab is not for detailed statistics or > history data. > For this kind of data we have the reports portal. > > On the other hand it may be painful to go to the VM tab and see no statistics > and get them updated > each 15 seconds. So after couple of minutes you will maybe see something > useful. Just don't click on any > other tab, otherwise you will loose that all :) > > @Michal,Einav: Is this acceptable? OK, after some more discussions with Michal about the idea of having some history data in our DB it starts to look like a really good idea. What about this solution: Let's store the last N results of VDSM poll in the vm_dynamic table instead of the last one only (where the N would be configured in vdc_options and by default something like 10). Let's send this to client so the client will be able to draw a nice chart out of all the values which are available. It would have this advantages: Technical: - no lost data caused by slower polling of engine by FE than is the polling of the VDSM by engine - consequently no need to do any interpolations because the data are already averaged by VDSM and I have no "holes" in between - also no problems to "ignore" updates caused by faster refresh of engine by FE than the poll of VDSM by engine UX: - after the first load of the VM tab the data shown in this tab would already be useful - no need to wait couple of refresh cycles until I get enough poll results - I can freely jump from tab to tab without the fear to loose all precious data I have in this tab collected Disadvantage is that we would have to store a bit more data on the server (but not much more since we would remember only couple of polls) and a bit more data transferred to client. What do you guys think? > > > > > > > > > > == From L&F point of view == > > > > > > > - would look pretty much like the one proposed by Malini: > > > > > > > http://style.org/chartapi/sparklines/ > > > > > > > > > > > > > > == From data point of view == > > > > > > > - do not do any averages on VDSM side (since it already does them > > > > > > > for > > > > > > > CPU > > > > > > > and network and the memory is stable enough) - do not do any > > > > > > > averages > > > > > > > on > > > > > > > engine side (since would have to be done for each FE separately > > > > > > > and > > > > > > > stored > > > > > > > in session which is a bit overcomplicated. If the user wants to > > > > > > > see > > > > > > > more > > > > > > > accurate data, he/she can change the refresh rate) - do not do > > > > > > > any > > > > > > > interpolation since the data are already averaged and we will > > > > > > > show > > > > > > > only > > > > > > > new > > > > > > > ones > > > > > > > > > > > > > > @Malini,Einav,Eldan,Michal what do you think? > > > > > > > > > > > > > > Tomas > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > > > > > > > > > From: "Michal Skrivanek" > > > > > > > > To: "Tomas Jelinek" , "Dan Kenigsberg" > > > > > > > > Cc: "Malini Rao" , "Eldan > > > > > > > > Hildesheim" , engine-devel at ovirt.org, > > > > > > > > "info" > > > > > > > > > > > > > > > > Sent: Tuesday, November 12, 2013 11:49:12 AM > > > > > > > > Subject: Re: [Engine-devel] [UX] how to design a bar/line > > > > > > > > chart? > > > > > > > > > > > > > > > > On Nov 12, 2013, at 11:18 , Tomas Jelinek > > > > > > > > > > > > > > > > wrote: > > > > > > > > > So we have looked into the resource usage sampling with > > > > > > > > > mbetak > > > > > > > > > and > > > > > > > > > also > > > > > > > > > with Michal and it seems that > > > > > > > > > > > > > > > > > > for the CPU usage: > > > > > > > > > - VDSM polls libvirt to get the runtime statistics of the VM > > > > > > > > > regularly. > > > > > > > > > The > > > > > > > > > pooling interval is configured in > > > > > > > > > > > > > > > > > > vdsm.conf as vm_sample_cpu_interval and by default it is 15 > > > > > > > > > seconds > > > > > > > > > > > > > > > > > > - libvirt returns something we than use to calculate the > > > > > > > > > average > > > > > > > > > CPU > > > > > > > > > usage > > > > > > > > > since the last poll > > > > > > > > > - engine polls VDSM once in 15 seconds to get the current > > > > > > > > > statistics > > > > > > > > > (the > > > > > > > > > same 15 seconds is just a coincidence and we can not count on > > > > > > > > > this) > > > > > > > > > - than the frontend polls the engine each 5-60 seconds > > > > > > > > > (depends > > > > > > > > > on > > > > > > > > > the > > > > > > > > > refresh rate) and gets the current value from the engine > > > > > > > > > - the user can press the refresh button anytime to poll the > > > > > > > > > engine > > > > > > > > > again > > > > > > > > > > > > > > > > > > For network usage: > > > > > > > > > - it should be pretty much the same as the CPU just the VDSM > > > > > > > > > poll > > > > > > > > > interval > > > > > > > > > is configured as vm_sample_net_interval and by default it is > > > > > > > > > 5 > > > > > > > > > seconds > > > > > > > > > > > > > > > > Dan, since we poll only every 15s and cpu info is 15s wouldn't > > > > > > > > it > > > > > > > > make > > > > > > > > sense to change the default for network monitoring to 15s as > > > > > > > > well? > > > > > > > > it's 2 > > > > > > > > libvirt rounds trip for nothing really. Or does it serve some > > > > > > > > other > > > > > > > > purpose?> > > > > > > > > > > > > > > > > > For memory usage: > > > > > > > > > - guest agent sends a message to VDSM with the memory usage > > > > > > > > > regularly. > > > > > > > > > The > > > > > > > > > interval is set in ovirt-guest-agent.conf as heart_beat_rate > > > > > > > > > > > > > > > > > > and by default it is 5 seconds > > > > > > > > > > > > > > > > > > - the actual value sent by ovirt-guest-agent is the actual > > > > > > > > > value > > > > > > > > > at > > > > > > > > > the > > > > > > > > > time when the value is sent (e.g. for Linux taken from "cat > > > > > > > > > /proc/meminfo") > > > > > > > > > - vdsm is doing no statistics on top of it, just remembers > > > > > > > > > the > > > > > > > > > last > > > > > > > > > value > > > > > > > > > taken from ovirt-guest-agent > > > > > > > > > > > > > > > > which is fine, it doesn't change so often and there are > > > > > > > > typically > > > > > > > > no > > > > > > > > spikes > > > > > > > > > > > > > > > > > - the rest of the poling is the same > > > > > > > > > > > > > > > > > > So, visualizing this in some usable form will be quite > > > > > > > > > challenging > > > > > > > > > ;) > > > > > > > > > I see the following problems: > > > > > > > > > - if the VDSM gets the data faster than the engine polls it > > > > > > > > > (and > > > > > > > > > most > > > > > > > > > often > > > > > > > > > it does) than the info in between will be lost. > > > > > > > > > > > > > > > > > > The question is how big this problem is and if it is worth > > > > > > > > > solving > > > > > > > > > (I > > > > > > > > > would say not for CPU which are averages but maybe yes for > > > > > > > > > memory). > > > > > > > > > Other question if there is a way how to solve it since the > > > > > > > > > VDSM > > > > > > > > > can > > > > > > > > > be > > > > > > > > > polled by anyone and it does not really care if someone > > > > > > > > > polls > > > > > > > > > it... > > > > > > > > > (Michal?) > > > > > > > > > > > > > > > > I'd say not solve it and try to keep it in sync on vdsm side > > > > > > > > with > > > > > > > > engine > > > > > > > > poll, to save unnecessary libvirt calls > > > > > > > > > > > > > > > > > - we can lost some data between frontend<->engine if the > > > > > > > > > polling > > > > > > > > > interval > > > > > > > > > of the FE is slower than the polling interval of the engine. > > > > > > > > > This > > > > > > > > > is > > > > > > > > > something > > > > > > > > > > > > > > > > > > not really worth solving because the user can set this > > > > > > > > > according > > > > > > > > > to > > > > > > > > > the > > > > > > > > > level of detail he/she wants > > > > > > > > > > > > > > > > well, you should average the values in engine in case the FE > > > > > > > > refresh > > > > > > > > is > > > > > > > > > > > > > > > > >15s. Or add (refresh/15) of them > > > > > > > > > > > > > > It is not that simple since you can have more frontends and not > > > > > > > sure > > > > > > > if > > > > > > > it > > > > > > > would be a good idea to put this into the session... > > > > > > > > > > > > > > > > - since we will get new info once in ~15 seconds, and the > > > > > > > > > polling > > > > > > > > > of > > > > > > > > > the > > > > > > > > > FE > > > > > > > > > is by default 5 seconds, do we want to do some interpolation? > > > > > > > > > Or > > > > > > > > > just > > > > > > > > > show > > > > > > > > > the > > > > > > > > > > > > > > > > > > same value 3 times? Or be smart and show only changed > > > > > > > > > values? > > > > > > > > > (this > > > > > > > > > is > > > > > > > > > tricky since there is a chance that it did not change - e.g. > > > > > > > > > constant > > > > > > > > > 0 > > > > > > > > > mem usage if you have no guest agent) > > > > > > > > > > > > > > > > > > - What if the user starts clicking to the refresh button? Do > > > > > > > > > we > > > > > > > > > want > > > > > > > > > to > > > > > > > > > keep appending the same value if the engine still has only > > > > > > > > > the > > > > > > > > > old > > > > > > > > > ones? > > > > > > > > > > > > > > > > just add a new line/point every 15s should be ok > > > > > > > > > > > > > > > > Thanks, > > > > > > > > michal > > > > > > > > > > > > > > > > > Tomas > > > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > > > > > > > > > > > >> From: "Tomas Jelinek" > > > > > > > > >> To: "Malini Rao" > > > > > > > > >> Cc: "Eldan Hildesheim" , > > > > > > > > >> engine-devel at ovirt.org, > > > > > > > > >> "info" > > > > > > > > >> Sent: Monday, November 11, 2013 4:23:09 PM > > > > > > > > >> Subject: Re: [Engine-devel] [UX] how to design a bar/line > > > > > > > > >> chart? > > > > > > > > >> > > > > > > > > >> > > > > > > > > >> > > > > > > > > >> ----- Original Message ----- > > > > > > > > >> > > > > > > > > >>> From: "Malini Rao" > > > > > > > > >>> To: "Eldan Hildesheim" > > > > > > > > >>> Cc: "Tomas Jelinek" , "info" > > > > > > > > >>> , > > > > > > > > >>> engine-devel at ovirt.org > > > > > > > > >>> Sent: Monday, November 11, 2013 4:15:50 PM > > > > > > > > >>> Subject: Re: [Engine-devel] [UX] how to design a bar/line > > > > > > > > >>> chart? > > > > > > > > >>> > > > > > > > > >>> Is this going to fit in a row of a table? Or are we talking > > > > > > > > >>> of > > > > > > > > >>> a > > > > > > > > >>> more > > > > > > > > >>> detailed view? > > > > > > > > >> > > > > > > > > >> it should fit into one cell of the table > > > > > > > > >> > > > > > > > > >>> ----- Original Message ----- > > > > > > > > >>> From: "Eldan Hildesheim" > > > > > > > > >>> To: "Tomas Jelinek" > > > > > > > > >>> Cc: "info" , engine-devel at ovirt.org > > > > > > > > >>> Sent: Monday, November 11, 2013 8:01:07 AM > > > > > > > > >>> Subject: Re: [Engine-devel] [UX] how to design a bar/line > > > > > > > > >>> chart? > > > > > > > > >>> > > > > > > > > >>> Throw this gif into a browser. This is more or less what I > > > > > > > > >>> thought. > > > > > > > > >>> Eldan > > > > > > > > >>> > > > > > > > > >>> ----- Original Message ----- > > > > > > > > >>> From: "Tomas Jelinek" > > > > > > > > >>> To: "Eldan Hildesheim" > > > > > > > > >>> Cc: "Einav Cohen" , "info" > > > > > > > > >>> , > > > > > > > > >>> engine-devel at ovirt.org > > > > > > > > >>> Sent: Monday, November 11, 2013 12:03:15 PM > > > > > > > > >>> Subject: Re: [Engine-devel] [UX] how to design a bar/line > > > > > > > > >>> chart? > > > > > > > > >>> > > > > > > > > >>> > > > > > > > > >>> > > > > > > > > >>> ----- Original Message ----- > > > > > > > > >>> > > > > > > > > >>>> From: "Eldan Hildesheim" > > > > > > > > >>>> To: "Einav Cohen" > > > > > > > > >>>> Cc: "info" , engine-devel at ovirt.org > > > > > > > > >>>> Sent: Sunday, November 10, 2013 3:56:57 PM > > > > > > > > >>>> Subject: Re: [Engine-devel] [UX] how to design a bar/line > > > > > > > > >>>> chart? > > > > > > > > >>>> > > > > > > > > >>>> Hello all, > > > > > > > > >>>> We use to have a good solution in the period pre-WPF. > > > > > > > > >>>> A line chart (used to be in flash) that works like a > > > > > > > > >>>> plotter: > > > > > > > > >>>> The Line Bar (not bar) had a small animation that shifted > > > > > > > > >>>> all > > > > > > > > >>>> the > > > > > > > > >>>> bar > > > > > > > > >>>> to > > > > > > > > >>>> the > > > > > > > > >>>> left. > > > > > > > > >>>> When a new data arrived it just added a new line (to the > > > > > > > > >>>> right) > > > > > > > > >>>> and > > > > > > > > >>>> as I > > > > > > > > >>>> said > > > > > > > > >>>> before, in parallel it always shifted slowly to the left. > > > > > > > > >>> > > > > > > > > >>> Any chance you still have some screenshot or mockup so I > > > > > > > > >>> can > > > > > > > > >>> imagine > > > > > > > > >>> it > > > > > > > > >>> better? > > > > > > > > >>> > > > > > > > > >>>> The animation gives the impression that data is streaming > > > > > > > > >>>> and > > > > > > > > >>>> when a > > > > > > > > >>>> real > > > > > > > > >>>> new > > > > > > > > >>>> data arrives the user gets it very fast. > > > > > > > > >>>> We have to sync between the animation and the rate of the > > > > > > > > >>>> arrival > > > > > > > > >>>> of > > > > > > > > >>>> the > > > > > > > > >>>> data > > > > > > > > >>>> but this is easy. > > > > > > > > >>>> If we can't find a good framework it can be created from > > > > > > > > >>>> scratch > > > > > > > > >>>> with > > > > > > > > >>>> JS, > > > > > > > > >>>> svg > > > > > > > > >>>> or canvas. > > > > > > > > >>> > > > > > > > > >>> We need to be careful about what we will use. oVirt is > > > > > > > > >>> supposed > > > > > > > > >>> to > > > > > > > > >>> work > > > > > > > > >>> on > > > > > > > > >>> FF > > > > > > > > >>> 17 [1] > > > > > > > > >>> but the HTML5 canvas works only since FF23 [2]. > > > > > > > > >>> > > > > > > > > >>> @Einav: > > > > > > > > >>> Is there a chance that we could start support only FF23+ > > > > > > > > >>> and > > > > > > > > >>> IE9+ > > > > > > > > >>> (this > > > > > > > > >>> one > > > > > > > > >>> is already OK) > > > > > > > > >>> because of this feature? > > > > > > > > >>> > > > > > > > > >>>> Now regarding its position: > > > > > > > > >>>> Rollover is good but not enough, we should somehow put it > > > > > > > > >>>> in > > > > > > > > >>>> the > > > > > > > > >>>> lower > > > > > > > > >>>> panel > > > > > > > > >>>> under general or even another tab - (live data). > > > > > > > > >>> > > > > > > > > >>> This is a bit different requirement. The point of this > > > > > > > > >>> specific > > > > > > > > >>> is > > > > > > > > >>> to > > > > > > > > >>> give > > > > > > > > >>> a > > > > > > > > >>> better > > > > > > > > >>> overview in the main tab. If it will be done we can decide > > > > > > > > >>> if > > > > > > > > >>> we > > > > > > > > >>> want > > > > > > > > >>> to > > > > > > > > >>> give > > > > > > > > >>> more > > > > > > > > >>> details in sub tabs. > > > > > > > > >>> > > > > > > > > >>>> We could later on have a (live data Tab) in other places > > > > > > > > >>>> as > > > > > > > > >>>> well > > > > > > > > >>>> like > > > > > > > > >>>> host, > > > > > > > > >>>> cluster... > > > > > > > > >>>> Eldan > > > > > > > > >>> > > > > > > > > >>> [1]: http://www.ovirt.org/Download > > > > > > > > >>> [2]: http://caniuse.com/#feat=canvas > > > > > > > > >>> > > > > > > > > >>>> ----- Original Message ----- > > > > > > > > >>>> From: "Einav Cohen" > > > > > > > > >>>> To: "Ewoud Kohl van Wijngaarden" > > > > > > > > >>>> > > > > > > > > >>>> Cc: "Alexander Wels" , "Eldan > > > > > > > > >>>> Hildesheim" > > > > > > > > >>>> , engine-devel at ovirt.org, "info" > > > > > > > > >>>> > > > > > > > > >>>> Sent: Friday, November 8, 2013 10:50:10 PM > > > > > > > > >>>> Subject: Re: [Engine-devel] [UX] how to design a bar/line > > > > > > > > >>>> chart? > > > > > > > > >>>> > > > > > > > > >>>>> ----- Original Message ----- > > > > > > > > >>>>> From: "Ewoud Kohl van Wijngaarden" > > > > > > > > >>>>> > > > > > > > > >>>>> Sent: Thursday, November 7, 2013 11:44:07 AM > > > > > > > > >>>>> > > > > > > > > >>>>> On Wed, Nov 06, 2013 at 11:45:36AM -0500, 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. > > > > > > > > >>>>> > > > > > > > > >>>>> I'd say no. Even from a reliability point of view since > > > > > > > > >>>>> users > > > > > > > > >>>>> may > > > > > > > > >>>>> have > > > > > > > > >>>>> systems that aren't connected to the internet. > > > > > > > > >>>> > > > > > > > > >>>> +1 > > > > > > > > >>>> > > > > > > > > >>>>> (Though I don't know how well oVirt handles this > > > > > > > > >>>>> currently.) > > > > > > > > >>>> > > > > > > > > >>>> AFAIK - oVirt is handling it ('it' == having no internet > > > > > > > > >>>> connection) > > > > > > > > >>>> well. > > > > > > > > >>>> _______________________________________________ > > > > > > > > >>>> Engine-devel mailing list > > > > > > > > >>>> Engine-devel at ovirt.org > > > > > > > > >>>> http://lists.ovirt.org/mailman/listinfo/engine-devel > > > > > > > > >>> > > > > > > > > >>> _______________________________________________ > > > > > > > > >>> Engine-devel mailing list > > > > > > > > >>> Engine-devel at ovirt.org > > > > > > > > >>> http://lists.ovirt.org/mailman/listinfo/engine-devel > > > > > > > > >> > > > > > > > > >> _______________________________________________ > > > > > > > > >> Engine-devel mailing list > > > > > > > > >> Engine-devel at ovirt.org > > > > > > > > >> http://lists.ovirt.org/mailman/listinfo/engine-devel > > > > > > > > > > > > > > _______________________________________________ > > > > > > > Engine-devel mailing list > > > > > > > Engine-devel at ovirt.org > > > > > > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > > > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > From ecohen at redhat.com Wed Nov 13 13:59:48 2013 From: ecohen at redhat.com (Einav Cohen) Date: Wed, 13 Nov 2013 08:59:48 -0500 (EST) Subject: [Engine-devel] [UX] how to design a bar/line chart? In-Reply-To: <827199354.23137395.1384350160740.JavaMail.root@redhat.com> References: <157528892.18409921.1383645002815.JavaMail.root@redhat.com> <1562637.RCtmcDAuT8@awels> <709457129.22382323.1384269675421.JavaMail.root@redhat.com> <346089019.FDH9RSlcBF@awels> <1174264806.22909547.1384327316441.JavaMail.root@redhat.com> <827199354.23137395.1384350160740.JavaMail.root@redhat.com> Message-ID: <911310920.3581484.1384351188944.JavaMail.root@redhat.com> > ----- Original Message ----- > From: "Tomas Jelinek" > Sent: Wednesday, November 13, 2013 8:42:40 AM > > > > ----- Original Message ----- > > From: "Tomas Jelinek" > > To: awels at redhat.com > > Cc: "Eldan Hildesheim" , engine-devel at ovirt.org, > > "info" > > Sent: Wednesday, November 13, 2013 8:21:56 AM > > Subject: Re: [Engine-devel] [UX] how to design a bar/line chart? > > > > > > > > ----- Original Message ----- > > > From: "Alexander Wels" > > > To: "Tomas Jelinek" > > > Cc: engine-devel at ovirt.org, "Michal Skrivanek" > > > , "Eldan Hildesheim" > > > , "info" > > > Sent: Tuesday, November 12, 2013 4:52:12 PM > > > Subject: Re: [Engine-devel] [UX] how to design a bar/line chart? > > > > > > On Tuesday, November 12, 2013 10:21:15 AM Tomas Jelinek wrote: > > > > ----- Original Message ----- > > > > > > > > > From: "Alexander Wels" > > > > > To: "Tomas Jelinek" > > > > > Cc: engine-devel at ovirt.org, "Michal Skrivanek" > > > > > , "Eldan Hildesheim" > > > > > , > > > > > "info" > > > > > Sent: Tuesday, November 12, 2013 4:03:14 PM > > > > > Subject: Re: [Engine-devel] [UX] how to design a bar/line chart? > > > > > > > > > > On Tuesday, November 12, 2013 09:50:07 AM Tomas Jelinek wrote: > > > > > > ----- Original Message ----- > > > > > > > > > > > > > From: "Alexander Wels" > > > > > > > To: engine-devel at ovirt.org > > > > > > > Cc: "Tomas Jelinek" , "Michal Skrivanek" > > > > > > > , "Eldan Hildesheim" > > > > > > > , > > > > > > > "info" > > > > > > > Sent: Tuesday, November 12, 2013 3:33:56 PM > > > > > > > Subject: Re: [Engine-devel] [UX] how to design a bar/line chart? > > > > > > > > > > > > > > On Tuesday, November 12, 2013 09:25:34 AM Tomas Jelinek wrote: > > > > > > > > Hey all, > > > > > > > > > > > > > > > > let me conclude what has been written in this thread to one > > > > > > > > proposal: > > > > > > > > > > > > > > > > == From the UX perspective the behavior == > > > > > > > > - each time the FE will receive new data and this data are > > > > > > > > different > > > > > > > > from > > > > > > > > the old ones, visualize it in the chart It means if you will > > > > > > > > keep > > > > > > > > pressing > > > > > > > > the refresh button but the data will not change, no new data > > > > > > > > will > > > > > > > > be > > > > > > > > visualized (an exception will be the 0 usage) - the amount of > > > > > > > > data > > > > > > > > visualized will depend on the size of the widget (since the > > > > > > > > tables > > > > > > > > are > > > > > > > > resizable). It means that if you make the widget bigger you > > > > > > > > will > > > > > > > > not > > > > > > > > see > > > > > > > > the same chart bigger but more data. - If you make the widget > > > > > > > > bigger, > > > > > > > > only > > > > > > > > then the amount of data will start to increase: e.g. > > > > > > > > > > > > > > > > before resize: > > > > > > > > | /-------\ | > > > > > > > > | > > > > > > > > |/ \| > > > > > > > > > > > > > > > > after resize: > > > > > > > > | /-------\ | > > > > > > > > | > > > > > > > > |/ \ | > > > > > > > > > > > > > > > > and only now the new data will start to appear > > > > > > > > > > > > > > > > == From FE technical point of view == > > > > > > > > - since I have not found any GWT library which would be > > > > > > > > acceptable > > > > > > > > (e.g. > > > > > > > > actively developed and without the need to connect to google > > > > > > > > servers) > > > > > > > > and > > > > > > > > given that the required chart is quite simple I guess it would > > > > > > > > be > > > > > > > > ok > > > > > > > > to > > > > > > > > write it by myself. - according to Einav's mail it is ok to use > > > > > > > > HTML5 > > > > > > > > canvas so I would go with writing a new widget using HTML5 > > > > > > > > canvas > > > > > > > > > > > > > > Just to throw out something to think about, we could also in > > > > > > > theory > > > > > > > generate an image on the server side and simply display that > > > > > > > image > > > > > > > inside > > > > > > > the grid (so no need for HTML5 canvas or other things like that). > > > > > > > The > > > > > > > idea being basically that when the grid refreshes it makes a > > > > > > > request > > > > > > > for > > > > > > > a new image on the back- end with the appropriate timeframe and > > > > > > > the > > > > > > > back-end generates the image which is easy to embed inside the > > > > > > > grid. > > > > > > > > > > > > > > pros: > > > > > > > * Easy to embed inside grid (just an image tag). > > > > > > > * Works on all browsers, even ones without HTML5 canvas support. > > > > > > > cons: > > > > > > > * More load on the back-end. > > > > > > > * Extra round trips to back-end on refresh. > > > > > > > * Not 'hot' like HTML5 canvas. > > > > > > > * No interactivity if that is something we are interested in. > > > > > > > > > > > > some more cons: > > > > > > * need to remember the statistics on server in the memory. For > > > > > > thousands > > > > > > of > > > > > > VMs it is not something we would like to do * lots of overhead to > > > > > > retrieve > > > > > > all the images on each refresh. If you have 100 VMs on a page and > > > > > > refresh > > > > > > each 5 seconds, it is 100 images transmitted from engine to > > > > > > frontend > > > > > > each 5 > > > > > > seconds per one client (and we can have more of them of course) * > > > > > > FE > > > > > > logic > > > > > > on Server is in general not awesome > > > > > > > > > > I would expect the statistics to be stored in the database somewhere, > > > > > that > > > > > way > > > > > we can pull them for reports and things of that nature (like charts). > > > > > Obviously we wouldn't do 100 round trips for the image, we would > > > > > generate > > > > > a > > > > > single image sprite that would contain all the images in a single > > > > > request > > > > > and display the appropriate part of the image in the grid. > > > > > > > > > > You are right in general front-end logic is not done on the back-end. > > > > > However we must consider if we are really doing front end logic here, > > > > > or > > > > > if we are just displaying some reporting information as part of the > > > > > grid. > > > > > > > > > > If we are not storing the statistics anywhere, then this is a > > > > > terrible > > > > > plan, and we should do the logic on the client, but if we are, it is > > > > > something to consider. > > > > > > > > We store only the actual value. The statistics are stored only by DWH > > > > but that is a different application. Engine itself does not have it so > > > > we > > > > would have to implement it. > > > > > > > > > > Which as you mentioned is not a desirable thing to do for thousands of > > > VMs, > > > but does bring up the question, if we only aggregate the statistics on > > > the > > > client, do we care if that information is lost when the user logs > > > out/switches > > > tab/etc. Since essentially we stop requesting that information from the > > > back- > > > end if the current active tab is not the VM main tab. > > > > I would say it is not a problem. The VM tab is not for detailed statistics > > or > > history data. > > For this kind of data we have the reports portal. > > > > On the other hand it may be painful to go to the VM tab and see no > > statistics > > and get them updated > > each 15 seconds. So after couple of minutes you will maybe see something > > useful. Just don't click on any > > other tab, otherwise you will loose that all :) > > > > @Michal,Einav: Is this acceptable? > > OK, after some more discussions with Michal about the idea of having some > history data in our DB it starts to look like a really good idea. > > What about this solution: > Let's store the last N results of VDSM poll in the vm_dynamic table instead > of the last one only > (where the N would be configured in vdc_options and by default something like > 10). > Let's send this to client so the client will be able to draw a nice chart out > of all the values which are available. > > It would have this advantages: > Technical: > - no lost data caused by slower polling of engine by FE than is the polling > of the VDSM by engine > - consequently no need to do any interpolations because the data are already > averaged by VDSM and I have no "holes" in between > - also no problems to "ignore" updates caused by faster refresh of engine by > FE than the poll of VDSM by engine > > UX: > - after the first load of the VM tab the data shown in this tab would already > be useful - no need to wait couple of refresh cycles until I get enough poll > results > - I can freely jump from tab to tab without the fear to loose all precious > data I have in this tab collected > > Disadvantage is that we would have to store a bit more data on the server > (but not much more since we would remember only couple of polls) and a bit > more data transferred to client. > > What do you guys think? +1 on this suggestion, I like it a lot. I am concerned about one thing that you mentioned yesterday (which I don't think is relevant anymore with this new suggestion, but just in case): """ == From the UX perspective the behavior == - each time the FE will receive new data and this data are different from the old ones, visualize it in the chart It means if you will keep pressing the refresh button but the data will not change, no new data will be visualized (an exception will be the 0 usage) """ IIUC, it means that if the CPU is constantly 5% and it spikes to 100% once an hour, we will see a graph of 5%-100%-5%-100% (over a *long* period of time though), which may seem like the VM is spiking half of its time, which is misleading. But with the new approach of persisting the "historic" info in the DB, this will not be the case anymore, correct? > > > > > > > > > > > > > > == From L&F point of view == > > > > > > > > - would look pretty much like the one proposed by Malini: > > > > > > > > http://style.org/chartapi/sparklines/ > > > > > > > > > > > > > > > > == From data point of view == > > > > > > > > - do not do any averages on VDSM side (since it already does > > > > > > > > them > > > > > > > > for > > > > > > > > CPU > > > > > > > > and network and the memory is stable enough) - do not do any > > > > > > > > averages > > > > > > > > on > > > > > > > > engine side (since would have to be done for each FE separately > > > > > > > > and > > > > > > > > stored > > > > > > > > in session which is a bit overcomplicated. If the user wants to > > > > > > > > see > > > > > > > > more > > > > > > > > accurate data, he/she can change the refresh rate) - do not do > > > > > > > > any > > > > > > > > interpolation since the data are already averaged and we will > > > > > > > > show > > > > > > > > only > > > > > > > > new > > > > > > > > ones > > > > > > > > > > > > > > > > @Malini,Einav,Eldan,Michal what do you think? > > > > > > > > > > > > > > > > Tomas > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > > > > > > > > > > > From: "Michal Skrivanek" > > > > > > > > > To: "Tomas Jelinek" , "Dan Kenigsberg" > > > > > > > > > Cc: "Malini Rao" , > > > > > > > > > "Eldan > > > > > > > > > Hildesheim" , engine-devel at ovirt.org, > > > > > > > > > "info" > > > > > > > > > > > > > > > > > > Sent: Tuesday, November 12, 2013 11:49:12 AM > > > > > > > > > Subject: Re: [Engine-devel] [UX] how to design a bar/line > > > > > > > > > chart? > > > > > > > > > > > > > > > > > > On Nov 12, 2013, at 11:18 , Tomas Jelinek > > > > > > > > > > > > > > > > > > > > > > > > > > > wrote: > > > > > > > > > > So we have looked into the resource usage sampling with > > > > > > > > > > mbetak > > > > > > > > > > and > > > > > > > > > > also > > > > > > > > > > with Michal and it seems that > > > > > > > > > > > > > > > > > > > > for the CPU usage: > > > > > > > > > > - VDSM polls libvirt to get the runtime statistics of the > > > > > > > > > > VM > > > > > > > > > > regularly. > > > > > > > > > > The > > > > > > > > > > pooling interval is configured in > > > > > > > > > > > > > > > > > > > > vdsm.conf as vm_sample_cpu_interval and by default it is > > > > > > > > > > 15 > > > > > > > > > > seconds > > > > > > > > > > > > > > > > > > > > - libvirt returns something we than use to calculate the > > > > > > > > > > average > > > > > > > > > > CPU > > > > > > > > > > usage > > > > > > > > > > since the last poll > > > > > > > > > > - engine polls VDSM once in 15 seconds to get the current > > > > > > > > > > statistics > > > > > > > > > > (the > > > > > > > > > > same 15 seconds is just a coincidence and we can not count > > > > > > > > > > on > > > > > > > > > > this) > > > > > > > > > > - than the frontend polls the engine each 5-60 seconds > > > > > > > > > > (depends > > > > > > > > > > on > > > > > > > > > > the > > > > > > > > > > refresh rate) and gets the current value from the engine > > > > > > > > > > - the user can press the refresh button anytime to poll the > > > > > > > > > > engine > > > > > > > > > > again > > > > > > > > > > > > > > > > > > > > For network usage: > > > > > > > > > > - it should be pretty much the same as the CPU just the > > > > > > > > > > VDSM > > > > > > > > > > poll > > > > > > > > > > interval > > > > > > > > > > is configured as vm_sample_net_interval and by default it > > > > > > > > > > is > > > > > > > > > > 5 > > > > > > > > > > seconds > > > > > > > > > > > > > > > > > > Dan, since we poll only every 15s and cpu info is 15s > > > > > > > > > wouldn't > > > > > > > > > it > > > > > > > > > make > > > > > > > > > sense to change the default for network monitoring to 15s as > > > > > > > > > well? > > > > > > > > > it's 2 > > > > > > > > > libvirt rounds trip for nothing really. Or does it serve some > > > > > > > > > other > > > > > > > > > purpose?> > > > > > > > > > > > > > > > > > > > For memory usage: > > > > > > > > > > - guest agent sends a message to VDSM with the memory usage > > > > > > > > > > regularly. > > > > > > > > > > The > > > > > > > > > > interval is set in ovirt-guest-agent.conf as > > > > > > > > > > heart_beat_rate > > > > > > > > > > > > > > > > > > > > and by default it is 5 seconds > > > > > > > > > > > > > > > > > > > > - the actual value sent by ovirt-guest-agent is the actual > > > > > > > > > > value > > > > > > > > > > at > > > > > > > > > > the > > > > > > > > > > time when the value is sent (e.g. for Linux taken from "cat > > > > > > > > > > /proc/meminfo") > > > > > > > > > > - vdsm is doing no statistics on top of it, just remembers > > > > > > > > > > the > > > > > > > > > > last > > > > > > > > > > value > > > > > > > > > > taken from ovirt-guest-agent > > > > > > > > > > > > > > > > > > which is fine, it doesn't change so often and there are > > > > > > > > > typically > > > > > > > > > no > > > > > > > > > spikes > > > > > > > > > > > > > > > > > > > - the rest of the poling is the same > > > > > > > > > > > > > > > > > > > > So, visualizing this in some usable form will be quite > > > > > > > > > > challenging > > > > > > > > > > ;) > > > > > > > > > > I see the following problems: > > > > > > > > > > - if the VDSM gets the data faster than the engine polls it > > > > > > > > > > (and > > > > > > > > > > most > > > > > > > > > > often > > > > > > > > > > it does) than the info in between will be lost. > > > > > > > > > > > > > > > > > > > > The question is how big this problem is and if it is worth > > > > > > > > > > solving > > > > > > > > > > (I > > > > > > > > > > would say not for CPU which are averages but maybe yes for > > > > > > > > > > memory). > > > > > > > > > > Other question if there is a way how to solve it since the > > > > > > > > > > VDSM > > > > > > > > > > can > > > > > > > > > > be > > > > > > > > > > polled by anyone and it does not really care if someone > > > > > > > > > > polls > > > > > > > > > > it... > > > > > > > > > > (Michal?) > > > > > > > > > > > > > > > > > > I'd say not solve it and try to keep it in sync on vdsm side > > > > > > > > > with > > > > > > > > > engine > > > > > > > > > poll, to save unnecessary libvirt calls > > > > > > > > > > > > > > > > > > > - we can lost some data between frontend<->engine if the > > > > > > > > > > polling > > > > > > > > > > interval > > > > > > > > > > of the FE is slower than the polling interval of the > > > > > > > > > > engine. > > > > > > > > > > This > > > > > > > > > > is > > > > > > > > > > something > > > > > > > > > > > > > > > > > > > > not really worth solving because the user can set this > > > > > > > > > > according > > > > > > > > > > to > > > > > > > > > > the > > > > > > > > > > level of detail he/she wants > > > > > > > > > > > > > > > > > > well, you should average the values in engine in case the FE > > > > > > > > > refresh > > > > > > > > > is > > > > > > > > > > > > > > > > > > >15s. Or add (refresh/15) of them > > > > > > > > > > > > > > > > It is not that simple since you can have more frontends and not > > > > > > > > sure > > > > > > > > if > > > > > > > > it > > > > > > > > would be a good idea to put this into the session... > > > > > > > > > > > > > > > > > > - since we will get new info once in ~15 seconds, and the > > > > > > > > > > polling > > > > > > > > > > of > > > > > > > > > > the > > > > > > > > > > FE > > > > > > > > > > is by default 5 seconds, do we want to do some > > > > > > > > > > interpolation? > > > > > > > > > > Or > > > > > > > > > > just > > > > > > > > > > show > > > > > > > > > > the > > > > > > > > > > > > > > > > > > > > same value 3 times? Or be smart and show only changed > > > > > > > > > > values? > > > > > > > > > > (this > > > > > > > > > > is > > > > > > > > > > tricky since there is a chance that it did not change - > > > > > > > > > > e.g. > > > > > > > > > > constant > > > > > > > > > > 0 > > > > > > > > > > mem usage if you have no guest agent) > > > > > > > > > > > > > > > > > > > > - What if the user starts clicking to the refresh button? > > > > > > > > > > Do > > > > > > > > > > we > > > > > > > > > > want > > > > > > > > > > to > > > > > > > > > > keep appending the same value if the engine still has only > > > > > > > > > > the > > > > > > > > > > old > > > > > > > > > > ones? > > > > > > > > > > > > > > > > > > just add a new line/point every 15s should be ok > > > > > > > > > > > > > > > > > > Thanks, > > > > > > > > > michal > > > > > > > > > > > > > > > > > > > Tomas > > > > > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > > > > > > > > > > > > > >> From: "Tomas Jelinek" > > > > > > > > > >> To: "Malini Rao" > > > > > > > > > >> Cc: "Eldan Hildesheim" , > > > > > > > > > >> engine-devel at ovirt.org, > > > > > > > > > >> "info" > > > > > > > > > >> Sent: Monday, November 11, 2013 4:23:09 PM > > > > > > > > > >> Subject: Re: [Engine-devel] [UX] how to design a bar/line > > > > > > > > > >> chart? > > > > > > > > > >> > > > > > > > > > >> > > > > > > > > > >> > > > > > > > > > >> ----- Original Message ----- > > > > > > > > > >> > > > > > > > > > >>> From: "Malini Rao" > > > > > > > > > >>> To: "Eldan Hildesheim" > > > > > > > > > >>> Cc: "Tomas Jelinek" , "info" > > > > > > > > > >>> , > > > > > > > > > >>> engine-devel at ovirt.org > > > > > > > > > >>> Sent: Monday, November 11, 2013 4:15:50 PM > > > > > > > > > >>> Subject: Re: [Engine-devel] [UX] how to design a bar/line > > > > > > > > > >>> chart? > > > > > > > > > >>> > > > > > > > > > >>> Is this going to fit in a row of a table? Or are we > > > > > > > > > >>> talking > > > > > > > > > >>> of > > > > > > > > > >>> a > > > > > > > > > >>> more > > > > > > > > > >>> detailed view? > > > > > > > > > >> > > > > > > > > > >> it should fit into one cell of the table > > > > > > > > > >> > > > > > > > > > >>> ----- Original Message ----- > > > > > > > > > >>> From: "Eldan Hildesheim" > > > > > > > > > >>> To: "Tomas Jelinek" > > > > > > > > > >>> Cc: "info" , engine-devel at ovirt.org > > > > > > > > > >>> Sent: Monday, November 11, 2013 8:01:07 AM > > > > > > > > > >>> Subject: Re: [Engine-devel] [UX] how to design a bar/line > > > > > > > > > >>> chart? > > > > > > > > > >>> > > > > > > > > > >>> Throw this gif into a browser. This is more or less what > > > > > > > > > >>> I > > > > > > > > > >>> thought. > > > > > > > > > >>> Eldan > > > > > > > > > >>> > > > > > > > > > >>> ----- Original Message ----- > > > > > > > > > >>> From: "Tomas Jelinek" > > > > > > > > > >>> To: "Eldan Hildesheim" > > > > > > > > > >>> Cc: "Einav Cohen" , "info" > > > > > > > > > >>> , > > > > > > > > > >>> engine-devel at ovirt.org > > > > > > > > > >>> Sent: Monday, November 11, 2013 12:03:15 PM > > > > > > > > > >>> Subject: Re: [Engine-devel] [UX] how to design a bar/line > > > > > > > > > >>> chart? > > > > > > > > > >>> > > > > > > > > > >>> > > > > > > > > > >>> > > > > > > > > > >>> ----- Original Message ----- > > > > > > > > > >>> > > > > > > > > > >>>> From: "Eldan Hildesheim" > > > > > > > > > >>>> To: "Einav Cohen" > > > > > > > > > >>>> Cc: "info" , engine-devel at ovirt.org > > > > > > > > > >>>> Sent: Sunday, November 10, 2013 3:56:57 PM > > > > > > > > > >>>> Subject: Re: [Engine-devel] [UX] how to design a > > > > > > > > > >>>> bar/line > > > > > > > > > >>>> chart? > > > > > > > > > >>>> > > > > > > > > > >>>> Hello all, > > > > > > > > > >>>> We use to have a good solution in the period pre-WPF. > > > > > > > > > >>>> A line chart (used to be in flash) that works like a > > > > > > > > > >>>> plotter: > > > > > > > > > >>>> The Line Bar (not bar) had a small animation that > > > > > > > > > >>>> shifted > > > > > > > > > >>>> all > > > > > > > > > >>>> the > > > > > > > > > >>>> bar > > > > > > > > > >>>> to > > > > > > > > > >>>> the > > > > > > > > > >>>> left. > > > > > > > > > >>>> When a new data arrived it just added a new line (to the > > > > > > > > > >>>> right) > > > > > > > > > >>>> and > > > > > > > > > >>>> as I > > > > > > > > > >>>> said > > > > > > > > > >>>> before, in parallel it always shifted slowly to the > > > > > > > > > >>>> left. > > > > > > > > > >>> > > > > > > > > > >>> Any chance you still have some screenshot or mockup so I > > > > > > > > > >>> can > > > > > > > > > >>> imagine > > > > > > > > > >>> it > > > > > > > > > >>> better? > > > > > > > > > >>> > > > > > > > > > >>>> The animation gives the impression that data is > > > > > > > > > >>>> streaming > > > > > > > > > >>>> and > > > > > > > > > >>>> when a > > > > > > > > > >>>> real > > > > > > > > > >>>> new > > > > > > > > > >>>> data arrives the user gets it very fast. > > > > > > > > > >>>> We have to sync between the animation and the rate of > > > > > > > > > >>>> the > > > > > > > > > >>>> arrival > > > > > > > > > >>>> of > > > > > > > > > >>>> the > > > > > > > > > >>>> data > > > > > > > > > >>>> but this is easy. > > > > > > > > > >>>> If we can't find a good framework it can be created from > > > > > > > > > >>>> scratch > > > > > > > > > >>>> with > > > > > > > > > >>>> JS, > > > > > > > > > >>>> svg > > > > > > > > > >>>> or canvas. > > > > > > > > > >>> > > > > > > > > > >>> We need to be careful about what we will use. oVirt is > > > > > > > > > >>> supposed > > > > > > > > > >>> to > > > > > > > > > >>> work > > > > > > > > > >>> on > > > > > > > > > >>> FF > > > > > > > > > >>> 17 [1] > > > > > > > > > >>> but the HTML5 canvas works only since FF23 [2]. > > > > > > > > > >>> > > > > > > > > > >>> @Einav: > > > > > > > > > >>> Is there a chance that we could start support only FF23+ > > > > > > > > > >>> and > > > > > > > > > >>> IE9+ > > > > > > > > > >>> (this > > > > > > > > > >>> one > > > > > > > > > >>> is already OK) > > > > > > > > > >>> because of this feature? > > > > > > > > > >>> > > > > > > > > > >>>> Now regarding its position: > > > > > > > > > >>>> Rollover is good but not enough, we should somehow put > > > > > > > > > >>>> it > > > > > > > > > >>>> in > > > > > > > > > >>>> the > > > > > > > > > >>>> lower > > > > > > > > > >>>> panel > > > > > > > > > >>>> under general or even another tab - (live data). > > > > > > > > > >>> > > > > > > > > > >>> This is a bit different requirement. The point of this > > > > > > > > > >>> specific > > > > > > > > > >>> is > > > > > > > > > >>> to > > > > > > > > > >>> give > > > > > > > > > >>> a > > > > > > > > > >>> better > > > > > > > > > >>> overview in the main tab. If it will be done we can > > > > > > > > > >>> decide > > > > > > > > > >>> if > > > > > > > > > >>> we > > > > > > > > > >>> want > > > > > > > > > >>> to > > > > > > > > > >>> give > > > > > > > > > >>> more > > > > > > > > > >>> details in sub tabs. > > > > > > > > > >>> > > > > > > > > > >>>> We could later on have a (live data Tab) in other places > > > > > > > > > >>>> as > > > > > > > > > >>>> well > > > > > > > > > >>>> like > > > > > > > > > >>>> host, > > > > > > > > > >>>> cluster... > > > > > > > > > >>>> Eldan > > > > > > > > > >>> > > > > > > > > > >>> [1]: http://www.ovirt.org/Download > > > > > > > > > >>> [2]: http://caniuse.com/#feat=canvas > > > > > > > > > >>> > > > > > > > > > >>>> ----- Original Message ----- > > > > > > > > > >>>> From: "Einav Cohen" > > > > > > > > > >>>> To: "Ewoud Kohl van Wijngaarden" > > > > > > > > > >>>> > > > > > > > > > >>>> Cc: "Alexander Wels" , "Eldan > > > > > > > > > >>>> Hildesheim" > > > > > > > > > >>>> , engine-devel at ovirt.org, "info" > > > > > > > > > >>>> > > > > > > > > > >>>> Sent: Friday, November 8, 2013 10:50:10 PM > > > > > > > > > >>>> Subject: Re: [Engine-devel] [UX] how to design a > > > > > > > > > >>>> bar/line > > > > > > > > > >>>> chart? > > > > > > > > > >>>> > > > > > > > > > >>>>> ----- Original Message ----- > > > > > > > > > >>>>> From: "Ewoud Kohl van Wijngaarden" > > > > > > > > > >>>>> > > > > > > > > > >>>>> Sent: Thursday, November 7, 2013 11:44:07 AM > > > > > > > > > >>>>> > > > > > > > > > >>>>> On Wed, Nov 06, 2013 at 11:45:36AM -0500, 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. > > > > > > > > > >>>>> > > > > > > > > > >>>>> I'd say no. Even from a reliability point of view since > > > > > > > > > >>>>> users > > > > > > > > > >>>>> may > > > > > > > > > >>>>> have > > > > > > > > > >>>>> systems that aren't connected to the internet. > > > > > > > > > >>>> > > > > > > > > > >>>> +1 > > > > > > > > > >>>> > > > > > > > > > >>>>> (Though I don't know how well oVirt handles this > > > > > > > > > >>>>> currently.) > > > > > > > > > >>>> > > > > > > > > > >>>> AFAIK - oVirt is handling it ('it' == having no > > > > > > > > > >>>> internet > > > > > > > > > >>>> connection) > > > > > > > > > >>>> well. > > > > > > > > > >>>> _______________________________________________ > > > > > > > > > >>>> Engine-devel mailing list > > > > > > > > > >>>> Engine-devel at ovirt.org > > > > > > > > > >>>> http://lists.ovirt.org/mailman/listinfo/engine-devel > > > > > > > > > >>> > > > > > > > > > >>> _______________________________________________ > > > > > > > > > >>> Engine-devel mailing list > > > > > > > > > >>> Engine-devel at ovirt.org > > > > > > > > > >>> http://lists.ovirt.org/mailman/listinfo/engine-devel > > > > > > > > > >> > > > > > > > > > >> _______________________________________________ > > > > > > > > > >> Engine-devel mailing list > > > > > > > > > >> Engine-devel at ovirt.org > > > > > > > > > >> http://lists.ovirt.org/mailman/listinfo/engine-devel > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > Engine-devel mailing list > > > > > > > > Engine-devel at ovirt.org > > > > > > > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > > > > > > _______________________________________________ > > Engine-devel mailing list > > Engine-devel at ovirt.org > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > From michal.skrivanek at redhat.com Wed Nov 13 14:15:02 2013 From: michal.skrivanek at redhat.com (Michal Skrivanek) Date: Wed, 13 Nov 2013 15:15:02 +0100 Subject: [Engine-devel] Migrating an existing installation to hosted engine In-Reply-To: <1599883010.29941308.1384256320402.JavaMail.root@redhat.com> References: <1599883010.29941308.1384256320402.JavaMail.root@redhat.com> Message-ID: On Nov 12, 2013, at 12:38 , Yedidyah Bar David wrote: > Hi all, > > A message with the same subject was sent to arch around a month ago, see [1]. > > In short, it suggested two approaches: > 1. Use p2v (or v2v) > 2. Clean install of OS/engine software and use backup/restore. > > Following that, I pushed a few changes for engine-backup and engine-setup, > with the intention of doing, briefly: > 1. hosted-engine --deploy on new host > 2. Install OS/software on new vm > 3. backup on old engine machine > 4. On new vm, do restore, which only restores the database and files, > followed by engine-setup, which will fix whatever else needs to be fixed. > > Some of the changes are still pending, and are under some controversy. See > [2], [3], [4]. > > A more detailed description of the suggested migration path is in [5]. > > What do you think? > > Should engine-setup do as little as possible to the system, or as much as > needed to save the admin from any manual work? > > Should engine-setup doing an upgrade do the same as a new setup, or just > whatever that's needed to adapt the config/database to the new code? > > A specific example: if admin chose during initial setup to automatically > configure the firewall (iptables/firewalld), should upgrade update it again, > or not touch it? > > Should engine-backup do all these things when doing a restore? I think using the same tool for both tasks(backup, migration to hosted engine) has an advantage that you only address issues (like missing item to backup/restore) once and both usecases benefit from a fix > > Should we have some other utility to do these things? > > Should we merely document them and let the admin do this manually? > > [1] http://lists.ovirt.org/pipermail/arch/2013-October/001677.html > [2] https://bugzilla.redhat.com/1024707 > [3] http://gerrit.ovirt.org/20736 > [4] http://gerrit.ovirt.org/20737 > [5] http://www.ovirt.org/Migrate_to_Hosted_Engine > -- > Didi > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel From sbonazzo at redhat.com Wed Nov 13 14:41:30 2013 From: sbonazzo at redhat.com (Sandro Bonazzola) Date: Wed, 13 Nov 2013 15:41:30 +0100 Subject: [Engine-devel] [Users] [QE] bug scrubing / triaging In-Reply-To: <527CB31B.2030705@redhat.com> References: <527CB31B.2030705@redhat.com> Message-ID: <52838F9A.5030506@redhat.com> Il 08/11/2013 10:47, Sandro Bonazzola ha scritto: > Hi, > Looking at bugzilla, there are 366 bugs without a target release. > Some of them are in POST state but I'm pretty sure they should be in ON_QA or CLOSED state. > A lot of them haven't a whiteboard set. > > Please review the bug list and help to scrub and triage them: > https://bugzilla.redhat.com/buglist.cgi?bug_status=NEW&bug_status=ASSIGNED&bug_status=POST&classification=Community&columnlist=product%2Ccomponent%2Cassigned_to%2Cbug_status%2Cresolution%2Cshort_desc%2Ctarget_release%2Cstatus_whiteboard&list_id=1883279&product=oVirt&query_based_on=&query_format=advanced&target_release=--- Thanks to those helping scrubing the bugs, we have now 307 unscrubbed bugs: http://red.ht/17pazhH Please continue scrubing / triaging them, setting target release or FutureFeature keyword on those not targeted to 3.3 or 3.4. Thanks -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com From tjelinek at redhat.com Wed Nov 13 15:39:57 2013 From: tjelinek at redhat.com (Tomas Jelinek) Date: Wed, 13 Nov 2013 10:39:57 -0500 (EST) Subject: [Engine-devel] [UX] how to design a bar/line chart? In-Reply-To: <911310920.3581484.1384351188944.JavaMail.root@redhat.com> References: <157528892.18409921.1383645002815.JavaMail.root@redhat.com> <1562637.RCtmcDAuT8@awels> <709457129.22382323.1384269675421.JavaMail.root@redhat.com> <346089019.FDH9RSlcBF@awels> <1174264806.22909547.1384327316441.JavaMail.root@redhat.com> <827199354.23137395.1384350160740.JavaMail.root@redhat.com> <911310920.3581484.1384351188944.JavaMail.root@redhat.com> Message-ID: <860297983.23217198.1384357197009.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Einav Cohen" > To: "Tomas Jelinek" > Cc: awels at redhat.com, "Eldan Hildesheim" , engine-devel at ovirt.org, "info" > Sent: Wednesday, November 13, 2013 2:59:48 PM > Subject: Re: [Engine-devel] [UX] how to design a bar/line chart? > > > ----- Original Message ----- > > From: "Tomas Jelinek" > > Sent: Wednesday, November 13, 2013 8:42:40 AM > > > > > > > > ----- Original Message ----- > > > From: "Tomas Jelinek" > > > To: awels at redhat.com > > > Cc: "Eldan Hildesheim" , engine-devel at ovirt.org, > > > "info" > > > Sent: Wednesday, November 13, 2013 8:21:56 AM > > > Subject: Re: [Engine-devel] [UX] how to design a bar/line chart? > > > > > > > > > > > > ----- Original Message ----- > > > > From: "Alexander Wels" > > > > To: "Tomas Jelinek" > > > > Cc: engine-devel at ovirt.org, "Michal Skrivanek" > > > > , "Eldan Hildesheim" > > > > , "info" > > > > Sent: Tuesday, November 12, 2013 4:52:12 PM > > > > Subject: Re: [Engine-devel] [UX] how to design a bar/line chart? > > > > > > > > On Tuesday, November 12, 2013 10:21:15 AM Tomas Jelinek wrote: > > > > > ----- Original Message ----- > > > > > > > > > > > From: "Alexander Wels" > > > > > > To: "Tomas Jelinek" > > > > > > Cc: engine-devel at ovirt.org, "Michal Skrivanek" > > > > > > , "Eldan Hildesheim" > > > > > > , > > > > > > "info" > > > > > > Sent: Tuesday, November 12, 2013 4:03:14 PM > > > > > > Subject: Re: [Engine-devel] [UX] how to design a bar/line chart? > > > > > > > > > > > > On Tuesday, November 12, 2013 09:50:07 AM Tomas Jelinek wrote: > > > > > > > ----- Original Message ----- > > > > > > > > > > > > > > > From: "Alexander Wels" > > > > > > > > To: engine-devel at ovirt.org > > > > > > > > Cc: "Tomas Jelinek" , "Michal Skrivanek" > > > > > > > > , "Eldan Hildesheim" > > > > > > > > , > > > > > > > > "info" > > > > > > > > Sent: Tuesday, November 12, 2013 3:33:56 PM > > > > > > > > Subject: Re: [Engine-devel] [UX] how to design a bar/line > > > > > > > > chart? > > > > > > > > > > > > > > > > On Tuesday, November 12, 2013 09:25:34 AM Tomas Jelinek wrote: > > > > > > > > > Hey all, > > > > > > > > > > > > > > > > > > let me conclude what has been written in this thread to one > > > > > > > > > proposal: > > > > > > > > > > > > > > > > > > == From the UX perspective the behavior == > > > > > > > > > - each time the FE will receive new data and this data are > > > > > > > > > different > > > > > > > > > from > > > > > > > > > the old ones, visualize it in the chart It means if you will > > > > > > > > > keep > > > > > > > > > pressing > > > > > > > > > the refresh button but the data will not change, no new data > > > > > > > > > will > > > > > > > > > be > > > > > > > > > visualized (an exception will be the 0 usage) - the amount of > > > > > > > > > data > > > > > > > > > visualized will depend on the size of the widget (since the > > > > > > > > > tables > > > > > > > > > are > > > > > > > > > resizable). It means that if you make the widget bigger you > > > > > > > > > will > > > > > > > > > not > > > > > > > > > see > > > > > > > > > the same chart bigger but more data. - If you make the widget > > > > > > > > > bigger, > > > > > > > > > only > > > > > > > > > then the amount of data will start to increase: e.g. > > > > > > > > > > > > > > > > > > before resize: > > > > > > > > > | /-------\ | > > > > > > > > > | > > > > > > > > > |/ \| > > > > > > > > > > > > > > > > > > after resize: > > > > > > > > > | /-------\ | > > > > > > > > > | > > > > > > > > > |/ \ | > > > > > > > > > > > > > > > > > > and only now the new data will start to appear > > > > > > > > > > > > > > > > > > == From FE technical point of view == > > > > > > > > > - since I have not found any GWT library which would be > > > > > > > > > acceptable > > > > > > > > > (e.g. > > > > > > > > > actively developed and without the need to connect to google > > > > > > > > > servers) > > > > > > > > > and > > > > > > > > > given that the required chart is quite simple I guess it > > > > > > > > > would > > > > > > > > > be > > > > > > > > > ok > > > > > > > > > to > > > > > > > > > write it by myself. - according to Einav's mail it is ok to > > > > > > > > > use > > > > > > > > > HTML5 > > > > > > > > > canvas so I would go with writing a new widget using HTML5 > > > > > > > > > canvas > > > > > > > > > > > > > > > > Just to throw out something to think about, we could also in > > > > > > > > theory > > > > > > > > generate an image on the server side and simply display that > > > > > > > > image > > > > > > > > inside > > > > > > > > the grid (so no need for HTML5 canvas or other things like > > > > > > > > that). > > > > > > > > The > > > > > > > > idea being basically that when the grid refreshes it makes a > > > > > > > > request > > > > > > > > for > > > > > > > > a new image on the back- end with the appropriate timeframe and > > > > > > > > the > > > > > > > > back-end generates the image which is easy to embed inside the > > > > > > > > grid. > > > > > > > > > > > > > > > > pros: > > > > > > > > * Easy to embed inside grid (just an image tag). > > > > > > > > * Works on all browsers, even ones without HTML5 canvas > > > > > > > > support. > > > > > > > > cons: > > > > > > > > * More load on the back-end. > > > > > > > > * Extra round trips to back-end on refresh. > > > > > > > > * Not 'hot' like HTML5 canvas. > > > > > > > > * No interactivity if that is something we are interested in. > > > > > > > > > > > > > > some more cons: > > > > > > > * need to remember the statistics on server in the memory. For > > > > > > > thousands > > > > > > > of > > > > > > > VMs it is not something we would like to do * lots of overhead to > > > > > > > retrieve > > > > > > > all the images on each refresh. If you have 100 VMs on a page and > > > > > > > refresh > > > > > > > each 5 seconds, it is 100 images transmitted from engine to > > > > > > > frontend > > > > > > > each 5 > > > > > > > seconds per one client (and we can have more of them of course) * > > > > > > > FE > > > > > > > logic > > > > > > > on Server is in general not awesome > > > > > > > > > > > > I would expect the statistics to be stored in the database > > > > > > somewhere, > > > > > > that > > > > > > way > > > > > > we can pull them for reports and things of that nature (like > > > > > > charts). > > > > > > Obviously we wouldn't do 100 round trips for the image, we would > > > > > > generate > > > > > > a > > > > > > single image sprite that would contain all the images in a single > > > > > > request > > > > > > and display the appropriate part of the image in the grid. > > > > > > > > > > > > You are right in general front-end logic is not done on the > > > > > > back-end. > > > > > > However we must consider if we are really doing front end logic > > > > > > here, > > > > > > or > > > > > > if we are just displaying some reporting information as part of the > > > > > > grid. > > > > > > > > > > > > If we are not storing the statistics anywhere, then this is a > > > > > > terrible > > > > > > plan, and we should do the logic on the client, but if we are, it > > > > > > is > > > > > > something to consider. > > > > > > > > > > We store only the actual value. The statistics are stored only by DWH > > > > > but that is a different application. Engine itself does not have it > > > > > so > > > > > we > > > > > would have to implement it. > > > > > > > > > > > > > Which as you mentioned is not a desirable thing to do for thousands of > > > > VMs, > > > > but does bring up the question, if we only aggregate the statistics on > > > > the > > > > client, do we care if that information is lost when the user logs > > > > out/switches > > > > tab/etc. Since essentially we stop requesting that information from the > > > > back- > > > > end if the current active tab is not the VM main tab. > > > > > > I would say it is not a problem. The VM tab is not for detailed > > > statistics > > > or > > > history data. > > > For this kind of data we have the reports portal. > > > > > > On the other hand it may be painful to go to the VM tab and see no > > > statistics > > > and get them updated > > > each 15 seconds. So after couple of minutes you will maybe see something > > > useful. Just don't click on any > > > other tab, otherwise you will loose that all :) > > > > > > @Michal,Einav: Is this acceptable? > > > > OK, after some more discussions with Michal about the idea of having some > > history data in our DB it starts to look like a really good idea. > > > > What about this solution: > > Let's store the last N results of VDSM poll in the vm_dynamic table instead > > of the last one only > > (where the N would be configured in vdc_options and by default something > > like > > 10). > > Let's send this to client so the client will be able to draw a nice chart > > out > > of all the values which are available. > > > > It would have this advantages: > > Technical: > > - no lost data caused by slower polling of engine by FE than is the polling > > of the VDSM by engine > > - consequently no need to do any interpolations because the data are > > already > > averaged by VDSM and I have no "holes" in between > > - also no problems to "ignore" updates caused by faster refresh of engine > > by > > FE than the poll of VDSM by engine > > > > UX: > > - after the first load of the VM tab the data shown in this tab would > > already > > be useful - no need to wait couple of refresh cycles until I get enough > > poll > > results > > - I can freely jump from tab to tab without the fear to loose all precious > > data I have in this tab collected > > > > Disadvantage is that we would have to store a bit more data on the server > > (but not much more since we would remember only couple of polls) and a bit > > more data transferred to client. > > > > What do you guys think? > > +1 on this suggestion, I like it a lot. > > I am concerned about one thing that you mentioned yesterday (which I don't > think > is relevant anymore with this new suggestion, but just in case): > > """ > == From the UX perspective the behavior == > - each time the FE will receive new data and this data are different from the > old ones, visualize it in the chart > It means if you will keep pressing the refresh button but the data will not > change, no new data will be visualized (an exception will be the 0 usage) > """ > > IIUC, it means that if the CPU is constantly 5% and it spikes to 100% once an > hour, > we will see a graph of 5%-100%-5%-100% (over a *long* period of time though), > which > may seem like the VM is spiking half of its time, which is misleading. > > But with the new approach of persisting the "historic" info in the DB, this > will > not be the case anymore, correct? correct, you will see the correct values. > > > > > > > > > > > > > > > > > > > > == From L&F point of view == > > > > > > > > > - would look pretty much like the one proposed by Malini: > > > > > > > > > http://style.org/chartapi/sparklines/ > > > > > > > > > > > > > > > > > > == From data point of view == > > > > > > > > > - do not do any averages on VDSM side (since it already does > > > > > > > > > them > > > > > > > > > for > > > > > > > > > CPU > > > > > > > > > and network and the memory is stable enough) - do not do any > > > > > > > > > averages > > > > > > > > > on > > > > > > > > > engine side (since would have to be done for each FE > > > > > > > > > separately > > > > > > > > > and > > > > > > > > > stored > > > > > > > > > in session which is a bit overcomplicated. If the user wants > > > > > > > > > to > > > > > > > > > see > > > > > > > > > more > > > > > > > > > accurate data, he/she can change the refresh rate) - do not > > > > > > > > > do > > > > > > > > > any > > > > > > > > > interpolation since the data are already averaged and we will > > > > > > > > > show > > > > > > > > > only > > > > > > > > > new > > > > > > > > > ones > > > > > > > > > > > > > > > > > > @Malini,Einav,Eldan,Michal what do you think? > > > > > > > > > > > > > > > > > > Tomas > > > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > > > > > > > > > > > > > From: "Michal Skrivanek" > > > > > > > > > > To: "Tomas Jelinek" , "Dan Kenigsberg" > > > > > > > > > > Cc: "Malini Rao" , > > > > > > > > > > "Eldan > > > > > > > > > > Hildesheim" , engine-devel at ovirt.org, > > > > > > > > > > "info" > > > > > > > > > > > > > > > > > > > > Sent: Tuesday, November 12, 2013 11:49:12 AM > > > > > > > > > > Subject: Re: [Engine-devel] [UX] how to design a bar/line > > > > > > > > > > chart? > > > > > > > > > > > > > > > > > > > > On Nov 12, 2013, at 11:18 , Tomas Jelinek > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > wrote: > > > > > > > > > > > So we have looked into the resource usage sampling with > > > > > > > > > > > mbetak > > > > > > > > > > > and > > > > > > > > > > > also > > > > > > > > > > > with Michal and it seems that > > > > > > > > > > > > > > > > > > > > > > for the CPU usage: > > > > > > > > > > > - VDSM polls libvirt to get the runtime statistics of the > > > > > > > > > > > VM > > > > > > > > > > > regularly. > > > > > > > > > > > The > > > > > > > > > > > pooling interval is configured in > > > > > > > > > > > > > > > > > > > > > > vdsm.conf as vm_sample_cpu_interval and by default it is > > > > > > > > > > > 15 > > > > > > > > > > > seconds > > > > > > > > > > > > > > > > > > > > > > - libvirt returns something we than use to calculate the > > > > > > > > > > > average > > > > > > > > > > > CPU > > > > > > > > > > > usage > > > > > > > > > > > since the last poll > > > > > > > > > > > - engine polls VDSM once in 15 seconds to get the current > > > > > > > > > > > statistics > > > > > > > > > > > (the > > > > > > > > > > > same 15 seconds is just a coincidence and we can not > > > > > > > > > > > count > > > > > > > > > > > on > > > > > > > > > > > this) > > > > > > > > > > > - than the frontend polls the engine each 5-60 seconds > > > > > > > > > > > (depends > > > > > > > > > > > on > > > > > > > > > > > the > > > > > > > > > > > refresh rate) and gets the current value from the engine > > > > > > > > > > > - the user can press the refresh button anytime to poll > > > > > > > > > > > the > > > > > > > > > > > engine > > > > > > > > > > > again > > > > > > > > > > > > > > > > > > > > > > For network usage: > > > > > > > > > > > - it should be pretty much the same as the CPU just the > > > > > > > > > > > VDSM > > > > > > > > > > > poll > > > > > > > > > > > interval > > > > > > > > > > > is configured as vm_sample_net_interval and by default it > > > > > > > > > > > is > > > > > > > > > > > 5 > > > > > > > > > > > seconds > > > > > > > > > > > > > > > > > > > > Dan, since we poll only every 15s and cpu info is 15s > > > > > > > > > > wouldn't > > > > > > > > > > it > > > > > > > > > > make > > > > > > > > > > sense to change the default for network monitoring to 15s > > > > > > > > > > as > > > > > > > > > > well? > > > > > > > > > > it's 2 > > > > > > > > > > libvirt rounds trip for nothing really. Or does it serve > > > > > > > > > > some > > > > > > > > > > other > > > > > > > > > > purpose?> > > > > > > > > > > > > > > > > > > > > > For memory usage: > > > > > > > > > > > - guest agent sends a message to VDSM with the memory > > > > > > > > > > > usage > > > > > > > > > > > regularly. > > > > > > > > > > > The > > > > > > > > > > > interval is set in ovirt-guest-agent.conf as > > > > > > > > > > > heart_beat_rate > > > > > > > > > > > > > > > > > > > > > > and by default it is 5 seconds > > > > > > > > > > > > > > > > > > > > > > - the actual value sent by ovirt-guest-agent is the > > > > > > > > > > > actual > > > > > > > > > > > value > > > > > > > > > > > at > > > > > > > > > > > the > > > > > > > > > > > time when the value is sent (e.g. for Linux taken from > > > > > > > > > > > "cat > > > > > > > > > > > /proc/meminfo") > > > > > > > > > > > - vdsm is doing no statistics on top of it, just > > > > > > > > > > > remembers > > > > > > > > > > > the > > > > > > > > > > > last > > > > > > > > > > > value > > > > > > > > > > > taken from ovirt-guest-agent > > > > > > > > > > > > > > > > > > > > which is fine, it doesn't change so often and there are > > > > > > > > > > typically > > > > > > > > > > no > > > > > > > > > > spikes > > > > > > > > > > > > > > > > > > > > > - the rest of the poling is the same > > > > > > > > > > > > > > > > > > > > > > So, visualizing this in some usable form will be quite > > > > > > > > > > > challenging > > > > > > > > > > > ;) > > > > > > > > > > > I see the following problems: > > > > > > > > > > > - if the VDSM gets the data faster than the engine polls > > > > > > > > > > > it > > > > > > > > > > > (and > > > > > > > > > > > most > > > > > > > > > > > often > > > > > > > > > > > it does) than the info in between will be lost. > > > > > > > > > > > > > > > > > > > > > > The question is how big this problem is and if it is > > > > > > > > > > > worth > > > > > > > > > > > solving > > > > > > > > > > > (I > > > > > > > > > > > would say not for CPU which are averages but maybe yes > > > > > > > > > > > for > > > > > > > > > > > memory). > > > > > > > > > > > Other question if there is a way how to solve it since > > > > > > > > > > > the > > > > > > > > > > > VDSM > > > > > > > > > > > can > > > > > > > > > > > be > > > > > > > > > > > polled by anyone and it does not really care if someone > > > > > > > > > > > polls > > > > > > > > > > > it... > > > > > > > > > > > (Michal?) > > > > > > > > > > > > > > > > > > > > I'd say not solve it and try to keep it in sync on vdsm > > > > > > > > > > side > > > > > > > > > > with > > > > > > > > > > engine > > > > > > > > > > poll, to save unnecessary libvirt calls > > > > > > > > > > > > > > > > > > > > > - we can lost some data between frontend<->engine if the > > > > > > > > > > > polling > > > > > > > > > > > interval > > > > > > > > > > > of the FE is slower than the polling interval of the > > > > > > > > > > > engine. > > > > > > > > > > > This > > > > > > > > > > > is > > > > > > > > > > > something > > > > > > > > > > > > > > > > > > > > > > not really worth solving because the user can set this > > > > > > > > > > > according > > > > > > > > > > > to > > > > > > > > > > > the > > > > > > > > > > > level of detail he/she wants > > > > > > > > > > > > > > > > > > > > well, you should average the values in engine in case the > > > > > > > > > > FE > > > > > > > > > > refresh > > > > > > > > > > is > > > > > > > > > > > > > > > > > > > > >15s. Or add (refresh/15) of them > > > > > > > > > > > > > > > > > > It is not that simple since you can have more frontends and > > > > > > > > > not > > > > > > > > > sure > > > > > > > > > if > > > > > > > > > it > > > > > > > > > would be a good idea to put this into the session... > > > > > > > > > > > > > > > > > > > > - since we will get new info once in ~15 seconds, and the > > > > > > > > > > > polling > > > > > > > > > > > of > > > > > > > > > > > the > > > > > > > > > > > FE > > > > > > > > > > > is by default 5 seconds, do we want to do some > > > > > > > > > > > interpolation? > > > > > > > > > > > Or > > > > > > > > > > > just > > > > > > > > > > > show > > > > > > > > > > > the > > > > > > > > > > > > > > > > > > > > > > same value 3 times? Or be smart and show only changed > > > > > > > > > > > values? > > > > > > > > > > > (this > > > > > > > > > > > is > > > > > > > > > > > tricky since there is a chance that it did not change - > > > > > > > > > > > e.g. > > > > > > > > > > > constant > > > > > > > > > > > 0 > > > > > > > > > > > mem usage if you have no guest agent) > > > > > > > > > > > > > > > > > > > > > > - What if the user starts clicking to the refresh button? > > > > > > > > > > > Do > > > > > > > > > > > we > > > > > > > > > > > want > > > > > > > > > > > to > > > > > > > > > > > keep appending the same value if the engine still has > > > > > > > > > > > only > > > > > > > > > > > the > > > > > > > > > > > old > > > > > > > > > > > ones? > > > > > > > > > > > > > > > > > > > > just add a new line/point every 15s should be ok > > > > > > > > > > > > > > > > > > > > Thanks, > > > > > > > > > > michal > > > > > > > > > > > > > > > > > > > > > Tomas > > > > > > > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > > > > > > > > > > > > > > > >> From: "Tomas Jelinek" > > > > > > > > > > >> To: "Malini Rao" > > > > > > > > > > >> Cc: "Eldan Hildesheim" , > > > > > > > > > > >> engine-devel at ovirt.org, > > > > > > > > > > >> "info" > > > > > > > > > > >> Sent: Monday, November 11, 2013 4:23:09 PM > > > > > > > > > > >> Subject: Re: [Engine-devel] [UX] how to design a > > > > > > > > > > >> bar/line > > > > > > > > > > >> chart? > > > > > > > > > > >> > > > > > > > > > > >> > > > > > > > > > > >> > > > > > > > > > > >> ----- Original Message ----- > > > > > > > > > > >> > > > > > > > > > > >>> From: "Malini Rao" > > > > > > > > > > >>> To: "Eldan Hildesheim" > > > > > > > > > > >>> Cc: "Tomas Jelinek" , "info" > > > > > > > > > > >>> , > > > > > > > > > > >>> engine-devel at ovirt.org > > > > > > > > > > >>> Sent: Monday, November 11, 2013 4:15:50 PM > > > > > > > > > > >>> Subject: Re: [Engine-devel] [UX] how to design a > > > > > > > > > > >>> bar/line > > > > > > > > > > >>> chart? > > > > > > > > > > >>> > > > > > > > > > > >>> Is this going to fit in a row of a table? Or are we > > > > > > > > > > >>> talking > > > > > > > > > > >>> of > > > > > > > > > > >>> a > > > > > > > > > > >>> more > > > > > > > > > > >>> detailed view? > > > > > > > > > > >> > > > > > > > > > > >> it should fit into one cell of the table > > > > > > > > > > >> > > > > > > > > > > >>> ----- Original Message ----- > > > > > > > > > > >>> From: "Eldan Hildesheim" > > > > > > > > > > >>> To: "Tomas Jelinek" > > > > > > > > > > >>> Cc: "info" , engine-devel at ovirt.org > > > > > > > > > > >>> Sent: Monday, November 11, 2013 8:01:07 AM > > > > > > > > > > >>> Subject: Re: [Engine-devel] [UX] how to design a > > > > > > > > > > >>> bar/line > > > > > > > > > > >>> chart? > > > > > > > > > > >>> > > > > > > > > > > >>> Throw this gif into a browser. This is more or less > > > > > > > > > > >>> what > > > > > > > > > > >>> I > > > > > > > > > > >>> thought. > > > > > > > > > > >>> Eldan > > > > > > > > > > >>> > > > > > > > > > > >>> ----- Original Message ----- > > > > > > > > > > >>> From: "Tomas Jelinek" > > > > > > > > > > >>> To: "Eldan Hildesheim" > > > > > > > > > > >>> Cc: "Einav Cohen" , "info" > > > > > > > > > > >>> , > > > > > > > > > > >>> engine-devel at ovirt.org > > > > > > > > > > >>> Sent: Monday, November 11, 2013 12:03:15 PM > > > > > > > > > > >>> Subject: Re: [Engine-devel] [UX] how to design a > > > > > > > > > > >>> bar/line > > > > > > > > > > >>> chart? > > > > > > > > > > >>> > > > > > > > > > > >>> > > > > > > > > > > >>> > > > > > > > > > > >>> ----- Original Message ----- > > > > > > > > > > >>> > > > > > > > > > > >>>> From: "Eldan Hildesheim" > > > > > > > > > > >>>> To: "Einav Cohen" > > > > > > > > > > >>>> Cc: "info" , engine-devel at ovirt.org > > > > > > > > > > >>>> Sent: Sunday, November 10, 2013 3:56:57 PM > > > > > > > > > > >>>> Subject: Re: [Engine-devel] [UX] how to design a > > > > > > > > > > >>>> bar/line > > > > > > > > > > >>>> chart? > > > > > > > > > > >>>> > > > > > > > > > > >>>> Hello all, > > > > > > > > > > >>>> We use to have a good solution in the period pre-WPF. > > > > > > > > > > >>>> A line chart (used to be in flash) that works like a > > > > > > > > > > >>>> plotter: > > > > > > > > > > >>>> The Line Bar (not bar) had a small animation that > > > > > > > > > > >>>> shifted > > > > > > > > > > >>>> all > > > > > > > > > > >>>> the > > > > > > > > > > >>>> bar > > > > > > > > > > >>>> to > > > > > > > > > > >>>> the > > > > > > > > > > >>>> left. > > > > > > > > > > >>>> When a new data arrived it just added a new line (to > > > > > > > > > > >>>> the > > > > > > > > > > >>>> right) > > > > > > > > > > >>>> and > > > > > > > > > > >>>> as I > > > > > > > > > > >>>> said > > > > > > > > > > >>>> before, in parallel it always shifted slowly to the > > > > > > > > > > >>>> left. > > > > > > > > > > >>> > > > > > > > > > > >>> Any chance you still have some screenshot or mockup so > > > > > > > > > > >>> I > > > > > > > > > > >>> can > > > > > > > > > > >>> imagine > > > > > > > > > > >>> it > > > > > > > > > > >>> better? > > > > > > > > > > >>> > > > > > > > > > > >>>> The animation gives the impression that data is > > > > > > > > > > >>>> streaming > > > > > > > > > > >>>> and > > > > > > > > > > >>>> when a > > > > > > > > > > >>>> real > > > > > > > > > > >>>> new > > > > > > > > > > >>>> data arrives the user gets it very fast. > > > > > > > > > > >>>> We have to sync between the animation and the rate of > > > > > > > > > > >>>> the > > > > > > > > > > >>>> arrival > > > > > > > > > > >>>> of > > > > > > > > > > >>>> the > > > > > > > > > > >>>> data > > > > > > > > > > >>>> but this is easy. > > > > > > > > > > >>>> If we can't find a good framework it can be created > > > > > > > > > > >>>> from > > > > > > > > > > >>>> scratch > > > > > > > > > > >>>> with > > > > > > > > > > >>>> JS, > > > > > > > > > > >>>> svg > > > > > > > > > > >>>> or canvas. > > > > > > > > > > >>> > > > > > > > > > > >>> We need to be careful about what we will use. oVirt is > > > > > > > > > > >>> supposed > > > > > > > > > > >>> to > > > > > > > > > > >>> work > > > > > > > > > > >>> on > > > > > > > > > > >>> FF > > > > > > > > > > >>> 17 [1] > > > > > > > > > > >>> but the HTML5 canvas works only since FF23 [2]. > > > > > > > > > > >>> > > > > > > > > > > >>> @Einav: > > > > > > > > > > >>> Is there a chance that we could start support only > > > > > > > > > > >>> FF23+ > > > > > > > > > > >>> and > > > > > > > > > > >>> IE9+ > > > > > > > > > > >>> (this > > > > > > > > > > >>> one > > > > > > > > > > >>> is already OK) > > > > > > > > > > >>> because of this feature? > > > > > > > > > > >>> > > > > > > > > > > >>>> Now regarding its position: > > > > > > > > > > >>>> Rollover is good but not enough, we should somehow put > > > > > > > > > > >>>> it > > > > > > > > > > >>>> in > > > > > > > > > > >>>> the > > > > > > > > > > >>>> lower > > > > > > > > > > >>>> panel > > > > > > > > > > >>>> under general or even another tab - (live data). > > > > > > > > > > >>> > > > > > > > > > > >>> This is a bit different requirement. The point of this > > > > > > > > > > >>> specific > > > > > > > > > > >>> is > > > > > > > > > > >>> to > > > > > > > > > > >>> give > > > > > > > > > > >>> a > > > > > > > > > > >>> better > > > > > > > > > > >>> overview in the main tab. If it will be done we can > > > > > > > > > > >>> decide > > > > > > > > > > >>> if > > > > > > > > > > >>> we > > > > > > > > > > >>> want > > > > > > > > > > >>> to > > > > > > > > > > >>> give > > > > > > > > > > >>> more > > > > > > > > > > >>> details in sub tabs. > > > > > > > > > > >>> > > > > > > > > > > >>>> We could later on have a (live data Tab) in other > > > > > > > > > > >>>> places > > > > > > > > > > >>>> as > > > > > > > > > > >>>> well > > > > > > > > > > >>>> like > > > > > > > > > > >>>> host, > > > > > > > > > > >>>> cluster... > > > > > > > > > > >>>> Eldan > > > > > > > > > > >>> > > > > > > > > > > >>> [1]: http://www.ovirt.org/Download > > > > > > > > > > >>> [2]: http://caniuse.com/#feat=canvas > > > > > > > > > > >>> > > > > > > > > > > >>>> ----- Original Message ----- > > > > > > > > > > >>>> From: "Einav Cohen" > > > > > > > > > > >>>> To: "Ewoud Kohl van Wijngaarden" > > > > > > > > > > >>>> > > > > > > > > > > >>>> Cc: "Alexander Wels" , "Eldan > > > > > > > > > > >>>> Hildesheim" > > > > > > > > > > >>>> , engine-devel at ovirt.org, "info" > > > > > > > > > > >>>> > > > > > > > > > > >>>> Sent: Friday, November 8, 2013 10:50:10 PM > > > > > > > > > > >>>> Subject: Re: [Engine-devel] [UX] how to design a > > > > > > > > > > >>>> bar/line > > > > > > > > > > >>>> chart? > > > > > > > > > > >>>> > > > > > > > > > > >>>>> ----- Original Message ----- > > > > > > > > > > >>>>> From: "Ewoud Kohl van Wijngaarden" > > > > > > > > > > >>>>> > > > > > > > > > > >>>>> Sent: Thursday, November 7, 2013 11:44:07 AM > > > > > > > > > > >>>>> > > > > > > > > > > >>>>> On Wed, Nov 06, 2013 at 11:45:36AM -0500, 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. > > > > > > > > > > >>>>> > > > > > > > > > > >>>>> I'd say no. Even from a reliability point of view > > > > > > > > > > >>>>> since > > > > > > > > > > >>>>> users > > > > > > > > > > >>>>> may > > > > > > > > > > >>>>> have > > > > > > > > > > >>>>> systems that aren't connected to the internet. > > > > > > > > > > >>>> > > > > > > > > > > >>>> +1 > > > > > > > > > > >>>> > > > > > > > > > > >>>>> (Though I don't know how well oVirt handles this > > > > > > > > > > >>>>> currently.) > > > > > > > > > > >>>> > > > > > > > > > > >>>> AFAIK - oVirt is handling it ('it' == having no > > > > > > > > > > >>>> internet > > > > > > > > > > >>>> connection) > > > > > > > > > > >>>> well. > > > > > > > > > > >>>> _______________________________________________ > > > > > > > > > > >>>> Engine-devel mailing list > > > > > > > > > > >>>> Engine-devel at ovirt.org > > > > > > > > > > >>>> http://lists.ovirt.org/mailman/listinfo/engine-devel > > > > > > > > > > >>> > > > > > > > > > > >>> _______________________________________________ > > > > > > > > > > >>> Engine-devel mailing list > > > > > > > > > > >>> Engine-devel at ovirt.org > > > > > > > > > > >>> http://lists.ovirt.org/mailman/listinfo/engine-devel > > > > > > > > > > >> > > > > > > > > > > >> _______________________________________________ > > > > > > > > > > >> Engine-devel mailing list > > > > > > > > > > >> Engine-devel at ovirt.org > > > > > > > > > > >> http://lists.ovirt.org/mailman/listinfo/engine-devel > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > Engine-devel mailing list > > > > > > > > > Engine-devel at ovirt.org > > > > > > > > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > > > > > > > > > _______________________________________________ > > > Engine-devel mailing list > > > Engine-devel at ovirt.org > > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > > > _______________________________________________ > > Engine-devel mailing list > > Engine-devel at ovirt.org > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > > > > > From iheim at redhat.com Wed Nov 13 19:44:23 2013 From: iheim at redhat.com (Itamar Heim) Date: Wed, 13 Nov 2013 14:44:23 -0500 Subject: [Engine-devel] [UX] how to design a bar/line chart? In-Reply-To: <1467962025.812771.1384182793453.JavaMail.root@redhat.com> References: <157528892.18409921.1383645002815.JavaMail.root@redhat.com> <10671894.E7RLZxpxmS@awels> <845594321.17693417.1383753786397.JavaMail.root@redhat.com> <4799215.PFXHvLDZXl@awels> <20131107164407.GB31469@bogey.xentower.nl> <312159812.23706941.1383943810196.JavaMail.root@redhat.com> <1591156023.26916611.1384095417884.JavaMail.root@redhat.com> <1307970395.21470536.1384164195241.JavaMail.root@redhat.com> <1467962025.812771.1384182793453.JavaMail.root@redhat.com> Message-ID: <5283D697.3010806@redhat.com> On 11/11/2013 10:13 AM, Einav Cohen wrote: >> @Einav: >> Is there a chance that we could start support only FF23+ and IE9+ (this one >> is already OK) >> because of this feature? > > According to [1], FF17 EOL is expected to be at the beginning of December 2013. > From this point on, I don't think that there is a reason that we should "support" > FF17 - we will probably move to "supporting" FF24, which is the next/current ESR > (other users can correct me if I am wrong - maybe I am missing something). > Need to keep in mind that in the user portal we are still being "friendly" to IE8 > users, so as long as our plans for this feature (at least for the near future) are > for the web-admin only, we are good. being friendly to IE8 doesn't mean we can't do this to only work on IE9 and just not have the monitor subtab with this chart for IE8 user portal users. From ecohen at redhat.com Wed Nov 13 23:09:15 2013 From: ecohen at redhat.com (Einav Cohen) Date: Wed, 13 Nov 2013 18:09:15 -0500 (EST) Subject: [Engine-devel] [UX] how to design a bar/line chart? In-Reply-To: <1306019229.17661019.1383751496579.JavaMail.root@redhat.com> References: <157528892.18409921.1383645002815.JavaMail.root@redhat.com> <52790A6A.9000808@redhat.com> <1596552383.20866728.1383747975841.JavaMail.root@redhat.com> <424101873.19454345.1383749883282.JavaMail.root@redhat.com> <1306019229.17661019.1383751496579.JavaMail.root@redhat.com> Message-ID: <858746798.4081108.1384384154972.JavaMail.root@redhat.com> > ... but we may have to see how this looks when multiple sparklines > reside in columns next to each other. > ... > ... > Is this going to fit in a row of a table? Or are we talking of a > more detailed view? > ... a concern on which I happened to briefly discuss with Eldan / Malini and actually somewhat raised here earlier in the thread (see above): Since we are adding another information "dimension" (time), we are actually going to display a lot more information to the user within the CPU/MEM/NET columns, and there is a chance that the view will become too overloaded/confusing, and we will end up with a view that is less clear than the current one. Just so we will have a general idea of how it will look like eventually, so we will be able to do a slightly more educated decision, I am attaching a mock-up of how it looks now compared to how it may look once this feature is implemented. * In my mock-up, I followed Malini's guideline from earlier in the thread: """ One color with a dot to indicate the most recent or most relevant data and display its value next to the sparkline """ * keep in mind that the view is dynamic and keeps updating once it receives new statistics from the backend. Thoughts? ----- Original Message ----- > From: "Malini Rao" > To: "Tomas Jelinek" > Cc: "Einav Cohen" , "engine-devel" , "Eldan Hildesheim" > , "info" , "Martin Polednik" > 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 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? 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 at 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 at ovirt.org > > > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > > > > > > > > > > > > > > > > -------------- next part -------------- A non-text attachment was scrubbed... Name: trendline-mockup.png Type: image/png Size: 705133 bytes Desc: not available URL: From zhshzhou at linux.vnet.ibm.com Thu Nov 14 06:57:19 2013 From: zhshzhou at linux.vnet.ibm.com (Zhou Zheng Sheng) Date: Thu, 14 Nov 2013 14:57:19 +0800 Subject: [Engine-devel] Things to be done to support Ubuntu hosts Message-ID: <5284744F.6010404@linux.vnet.ibm.com> Hi, Recently Ubuntu support is added to VDSM, and .deb binray packages can be downloaded from launchpad.net PPA [1]. Most of the key features such as storage management and VM lifecycle work on Ubuntu. The cross distribution network management patches are upstream as well. One big piece left is making ovirt-host-deploy support Ubuntu, so that we can manage Ubuntu hosts from Engine, thus close the gap on host side. In May 2013 I made some hacks to ovirt-host-deploy and otopi. I made it skipped parts not supported on Ubuntu and configure the environment manually, and successfully added Ubuntu host to Engine [2]. Unfortunately I have no plans to continue on it, but I'd like to make a summary of the things I hacked to help anyone who wants to submit patches in future. I was to add a WIKI page but I found there were not many items, so a mail would be enough. 1. Package management operations Both otopi and ovirt-host-deploy query for dependency packages and install them on demand. The otopi package management just supports yum, we need to add apt-get support. Package names are different in Ubuntu, so I made a list mapping the names. The list in in VDSM source directory, debian/dependencyMap.txt . 2. Network configuration operations ovirt-host-deploy asks VDSM's configNetwork.py to create bridge network. Cross distribution support patches for configNetwork.py are under review. ovirt-host-deploy supports Ubuntu bridge configuration as long as they are merged. [1] https://launchpad.net/~zhshzhou/+archive/vdsm-ubuntu [2] http://www.ovirt.org/images/5/57/Shanghai-VDSM-on-Ubuntu.pdf Here goes the detailed hack patch. The hack was base on v1.0.1, I rebased it to the latest master. The rebased patch are not tested. If you find this email useless, it's actually a good news, which means there is not a lot of work and problems ahead ;-) Hack patch for ovirt-host-deploy. >From 120493a242046d19794ef3da83b32486d372aa39 Mon Sep 17 00:00:00 2001 From: Zhou Zheng Sheng Date: Wed, 13 Nov 2013 18:02:26 +0800 Subject: [PATCH] Ubuntu Hacks Change-Id: Ifb4ebc829101c92d06475619b1b5986e87b83d57 Signed-off-by: Zhou Zheng Sheng --- src/plugins/ovirt-host-deploy/gluster/packages.py | 17 +++++---- src/plugins/ovirt-host-deploy/tune/tuned.py | 3 +- src/plugins/ovirt-host-deploy/vdsm/bridge.py | 45 ++++++++++++----------- src/plugins/ovirt-host-deploy/vdsm/packages.py | 9 +++-- src/plugins/ovirt-host-deploy/vdsm/pki.py | 3 +- src/plugins/ovirt-host-deploy/vdsm/software.py | 2 + src/plugins/ovirt-host-deploy/vdsm/vdsmid.py | 3 +- 7 files changed, 45 insertions(+), 37 deletions(-) diff --git a/src/plugins/ovirt-host-deploy/gluster/packages.py b/src/plugins/ovirt-host-deploy/gluster/packages.py index 1fecfda..eb37744 100644 --- a/src/plugins/ovirt-host-deploy/gluster/packages.py +++ b/src/plugins/ovirt-host-deploy/gluster/packages.py @@ -60,13 +60,13 @@ class Plugin(plugin.PluginBase): ), ) def _validation(self): - if not self.packager.queryPackages(patterns=('vdsm-gluster',)): - raise RuntimeError( - _( - 'Cannot locate gluster packages, ' - 'possible cause is incorrect channels' - ) - ) + # if not self.packager.queryPackages(patterns=('vdsm-gluster',)): + # raise RuntimeError( + # _( + # 'Cannot locate gluster packages, ' + # 'possible cause is incorrect channels' + # ) + # ) self._enabled = True @plugin.event( @@ -74,7 +74,8 @@ class Plugin(plugin.PluginBase): condition=lambda self: self._enabled, ) def _packages(self): - self.packager.installUpdate(('vdsm-gluster',)) + # self.packager.installUpdate(('vdsm-gluster',)) + pass @plugin.event( stage=plugin.Stages.STAGE_CLOSEUP, diff --git a/src/plugins/ovirt-host-deploy/tune/tuned.py b/src/plugins/ovirt-host-deploy/tune/tuned.py index d8e00c5..d0dcea5 100644 --- a/src/plugins/ovirt-host-deploy/tune/tuned.py +++ b/src/plugins/ovirt-host-deploy/tune/tuned.py @@ -70,7 +70,8 @@ class Plugin(plugin.PluginBase): condition=lambda self: self._enabled, ) def _packages(self): - self.packager.installUpdate(('tuned',)) + # self.packager.installUpdate(('tuned',)) + pass @plugin.event( stage=plugin.Stages.STAGE_MISC, diff --git a/src/plugins/ovirt-host-deploy/vdsm/bridge.py b/src/plugins/ovirt-host-deploy/vdsm/bridge.py index 3789d62..64cce40 100644 --- a/src/plugins/ovirt-host-deploy/vdsm/bridge.py +++ b/src/plugins/ovirt-host-deploy/vdsm/bridge.py @@ -595,7 +595,8 @@ class Plugin(plugin.PluginBase): stage=plugin.Stages.STAGE_INTERNAL_PACKAGES, ) def _internal_packages(self): - self.packager.install(packages=('iproute',)) + # self.packager.install(packages=('iproute',)) + pass @plugin.event( stage=plugin.Stages.STAGE_VALIDATION, @@ -771,27 +772,27 @@ class Plugin(plugin.PluginBase): interface = self._getInterfaceToInstallBasedOnDestination( address=self.environment[odeploycons.VdsmEnv.ENGINE_ADDRESS] ) - parameters = self._rhel_getInterfaceConfigParameters(name=interface) - - # The followin can be executed - # only at node as we won't reach here - # if we are not running on node - if ( - self.environment[odeploycons.VdsmEnv.OVIRT_NODE] and - self._interfaceIsBridge(name=interface) - ): - nic = interface.replace('br', '', 1) - self._removeBridge( - name=interface, - interface=nic, - ) - interface = nic - - self._createBridge( - name=self.environment[odeploycons.VdsmEnv.MANAGEMENT_BRIDGE_NAME], - interface=interface, - parameters=parameters, - ) + # parameters = self._rhel_getInterfaceConfigParameters(name=interface) + + # # The followin can be executed + # # only at node as we won't reach here + # # if we are not running on node + # if ( + # self.environment[odeploycons.VdsmEnv.OVIRT_NODE] and + # self._interfaceIsBridge(name=interface) + # ): + # nic = interface.replace('br', '', 1) + # self._removeBridge( + # name=interface, + # interface=nic, + # ) + # interface = nic + + # self._createBridge( + # name=self.environment[odeploycons.VdsmEnv.MANAGEMENT_BRIDGE_NAME], + # interface=interface, + # parameters=parameters, + # ) self._waitForRoute( host=( diff --git a/src/plugins/ovirt-host-deploy/vdsm/packages.py b/src/plugins/ovirt-host-deploy/vdsm/packages.py index d819caa..b526d4b 100644 --- a/src/plugins/ovirt-host-deploy/vdsm/packages.py +++ b/src/plugins/ovirt-host-deploy/vdsm/packages.py @@ -68,7 +68,8 @@ class Plugin(plugin.PluginBase): stage=plugin.Stages.STAGE_VALIDATION, ) def _validation(self): - result = self.packager.queryPackages(patterns=('vdsm',)) + # result = self.packager.queryPackages(patterns=('vdsm',)) + result = ({'version': '4.10.3', 'release': '1'},) if not result: raise RuntimeError( _( @@ -106,8 +107,8 @@ class Plugin(plugin.PluginBase): self.services.state('vdsmd', False) if self.services.exists('supervdsmd'): self.services.state('supervdsmd', False) - self.packager.install(('qemu-kvm-tools',)) - self.packager.installUpdate(('vdsm', 'vdsm-cli')) + # self.packager.install(('qemu-kvm-tools',)) + # self.packager.installUpdate(('vdsm', 'vdsm-cli')) @plugin.event( stage=plugin.Stages.STAGE_CLOSEUP, @@ -119,7 +120,7 @@ class Plugin(plugin.PluginBase): self.services.state('libvirt-guests', False) self.services.startup('libvirt-guests', False) - self.services.startup('vdsmd', True) + # self.services.startup('vdsmd', True) if not self.services.supportsDependency: if self.services.exists('libvirtd'): self.services.startup('libvirtd', True) diff --git a/src/plugins/ovirt-host-deploy/vdsm/pki.py b/src/plugins/ovirt-host-deploy/vdsm/pki.py index f374a99..c013527 100644 --- a/src/plugins/ovirt-host-deploy/vdsm/pki.py +++ b/src/plugins/ovirt-host-deploy/vdsm/pki.py @@ -208,7 +208,8 @@ class Plugin(plugin.PluginBase): condition=lambda self: self._enabled, ) def _packages(self): - self.packager.install(('m2crypto',)) + # self.packager.install(('m2crypto',)) + pass @plugin.event( stage=plugin.Stages.STAGE_MISC, diff --git a/src/plugins/ovirt-host-deploy/vdsm/software.py b/src/plugins/ovirt-host-deploy/vdsm/software.py index 2f0ec80..a226816 100644 --- a/src/plugins/ovirt-host-deploy/vdsm/software.py +++ b/src/plugins/ovirt-host-deploy/vdsm/software.py @@ -65,6 +65,8 @@ class Plugin(plugin.PluginBase): version=ver, ) ) + elif dist == 'Ubuntu': + pass else: raise RuntimeError( _('Distribution {distribution} is not supported').format( diff --git a/src/plugins/ovirt-host-deploy/vdsm/vdsmid.py b/src/plugins/ovirt-host-deploy/vdsm/vdsmid.py index 328ad17..465212a 100644 --- a/src/plugins/ovirt-host-deploy/vdsm/vdsmid.py +++ b/src/plugins/ovirt-host-deploy/vdsm/vdsmid.py @@ -78,7 +78,8 @@ class Plugin(plugin.PluginBase): ) def _packages(self): if platform.machine() in ('x86_64', 'i686'): - self.packager.install(('dmidecode',)) + # self.packager.install(('dmidecode',)) + pass @plugin.event( stage=plugin.Stages.STAGE_CUSTOMIZATION, -- 1.7.11.7 Hack patch for otopi. >From 3e7022b740f24d8053d3e32c20fa6d492631db80 Mon Sep 17 00:00:00 2001 From: Zhou Zheng Sheng Date: Wed, 13 Nov 2013 17:55:39 +0800 Subject: [PATCH] Ubuntu Hacks --- src/plugins/otopi/network/hostname.py | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/src/plugins/otopi/network/hostname.py b/src/plugins/otopi/network/hostname.py index bb07627..28b4866 100644 --- a/src/plugins/otopi/network/hostname.py +++ b/src/plugins/otopi/network/hostname.py @@ -63,7 +63,8 @@ class Plugin(plugin.PluginBase): stage=plugin.Stages.STAGE_INTERNAL_PACKAGES, ) def _internal_packages(self): - self.packager.install(packages=['iproute']) + # self.packager.install(packages=['iproute']) + pass @plugin.event( stage=plugin.Stages.STAGE_VALIDATION, -- 1.7.11.7 -- Thanks and best regards! Zhou Zheng Sheng / ??? E-mail: zhshzhou at linux.vnet.ibm.com Telephone: 86-10-82454397 From mskrivan at redhat.com Thu Nov 14 07:21:03 2013 From: mskrivan at redhat.com (Michal Skrivanek) Date: Thu, 14 Nov 2013 08:21:03 +0100 Subject: [Engine-devel] [UX] how to design a bar/line chart? In-Reply-To: <858746798.4081108.1384384154972.JavaMail.root@redhat.com> References: <157528892.18409921.1383645002815.JavaMail.root@redhat.com> <52790A6A.9000808@redhat.com> <1596552383.20866728.1383747975841.JavaMail.root@redhat.com> <424101873.19454345.1383749883282.JavaMail.root@redhat.com> <1306019229.17661019.1383751496579.JavaMail.root@redhat.com> <858746798.4081108.1384384154972.JavaMail.root@redhat.com> Message-ID: <5D98AD7F-83C0-48D5-9252-5CD0B220B775@redhat.com> On Nov 14, 2013, at 00:09 , Einav Cohen wrote: >> ... but we may have to see how this looks when multiple sparklines >> reside in columns next to each other. >> ... >> ... >> Is this going to fit in a row of a table? Or are we talking of a >> more detailed view? >> ... > > a concern on which I happened to briefly discuss with Eldan / Malini > and actually somewhat raised here earlier in the thread (see above): > Since we are adding another information "dimension" (time), we are > actually going to display a lot more information to the user within the > CPU/MEM/NET columns, and there is a chance that the view will become > too overloaded/confusing, and we will end up with a view that is less > clear than the current one. Well, for that we IMHO have much bigger issue already with the fact we do not hide/show columns, and many of them do not really provide much value in all use cases. If you look at the mockup and the screenshots from users I've seen - e.g. the Display column(don't care), the Cluster (not wide enough, repetition of the same info on each line), Host(repetition of domain parts of FQDN) makes it overloaded already. Since statistics do provide some value and it keeps changing based on load it IMHO looks ok ...maybe just a global setting to disable this if it gets annoying? It's a small feature and it's trivial to add such a setting. > > Just so we will have a general idea of how it will look like eventually, > so we will be able to do a slightly more educated decision, I am attaching > a mock-up of how it looks now compared to how it may look once this > feature is implemented. > > * In my mock-up, I followed Malini's guideline from earlier in the thread: > """ > One color with a dot to indicate the most recent or most relevant data > and display its value next to the sparkline > """ Thanks for the mock up, I think it looks great. Perhaps I'd consider lines instead of dots (to see the base 0, currently the line is somehow "in the air" and since the height is limited it may be difficult to distinguissh 20% from 0%), provided they are in some light color it may look ok > > * keep in mind that the view is dynamic and keeps updating once it > receives new statistics from the backend. > > Thoughts? > > > ----- Original Message ----- >> From: "Malini Rao" >> To: "Tomas Jelinek" >> Cc: "Einav Cohen" , "engine-devel" , "Eldan Hildesheim" >> , "info" , "Martin Polednik" >> 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 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? 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 at 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 at ovirt.org >>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel >>>>> >>>>> >>>>> >>>> >>> > From sbonazzo at redhat.com Thu Nov 14 07:38:03 2013 From: sbonazzo at redhat.com (Sandro Bonazzola) Date: Thu, 14 Nov 2013 08:38:03 +0100 Subject: [Engine-devel] [vdsm] daily oVirt 3.3.1 blocker status In-Reply-To: <20131111100225.GA26033@redhat.com> References: <52720B88.9080001@redhat.com> <5277553F.3010807@redhat.com> <20131104092600.GB27545@redhat.com> <5278BCD1.3030808@redhat.com> <5279EFA0.2030309@redhat.com> <932728766.19142551.1383723368752.JavaMail.root@redhat.com> <20131108002845.GP16597@redhat.com> <5280A2BB.40601@redhat.com> <20131111100225.GA26033@redhat.com> Message-ID: <52847DDB.7000403@redhat.com> Hi, Bug 1022961 - Running a VM from a gluster domain uses mount instead of gluster URI is not blocking anymore 3.3.1 release as decided in yesterday oVirt sync meeting. We have only one bug blocking 3.3.1 release: Bug 1029584 - create vm does not work with display protocol vnc and operating system linux patch is already in 3.3 branch and just need to be backported to 3.3.1 branch (now available again) so hopefully we can have the bug in modified state later today. Just after that, ovirt engine will be rebuilt. I'm not aware of other blockers. If you're aware of any other blocker, please add it to the tracker bug (Bug 1019391 - Tracker: oVirt 3.3.1 release) Thanks, -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com From ybronhei at redhat.com Thu Nov 14 09:41:17 2013 From: ybronhei at redhat.com (Yaniv Bronheim) Date: Thu, 14 Nov 2013 04:41:17 -0500 (EST) Subject: [Engine-devel] Things to be done to support Ubuntu hosts In-Reply-To: <5284744F.6010404@linux.vnet.ibm.com> References: <5284744F.6010404@linux.vnet.ibm.com> Message-ID: <1314616103.15471867.1384422077452.JavaMail.root@redhat.com> Hey, Most of the issues you mentioned in slides 11-13 (http://www.ovirt.org/images/5/57/Shanghai-VDSM-on-Ubuntu.pdf) are already solved (if not all of them), If there are more issues to solve can you please open RFE bz on them to close those gaps (like making the services' names configurable)? Thanks Yaniv Bronhaim. ----- Original Message ----- > From: "Zhou Zheng Sheng" > To: "engine-devel" > Sent: Thursday, November 14, 2013 8:57:19 AM > Subject: [Engine-devel] Things to be done to support Ubuntu hosts > > Hi, > > Recently Ubuntu support is added to VDSM, and .deb binray packages can > be downloaded from launchpad.net PPA [1]. Most of the key features such > as storage management and VM lifecycle work on Ubuntu. The cross > distribution network management patches are upstream as well. One big > piece left is making ovirt-host-deploy support Ubuntu, so that we can > manage Ubuntu hosts from Engine, thus close the gap on host side. > > In May 2013 I made some hacks to ovirt-host-deploy and otopi. I made it > skipped parts not supported on Ubuntu and configure the environment > manually, and successfully added Ubuntu host to Engine [2]. > Unfortunately I have no plans to continue on it, but I'd like to make a > summary of the things I hacked to help anyone who wants to submit > patches in future. I was to add a WIKI page but I found there were not > many items, so a mail would be enough. > > 1. Package management operations > Both otopi and ovirt-host-deploy query for dependency packages and > install them on demand. The otopi package management just supports yum, > we need to add apt-get support. Package names are different in Ubuntu, > so I made a list mapping the names. The list in in VDSM source > directory, debian/dependencyMap.txt . > > 2. Network configuration operations > ovirt-host-deploy asks VDSM's configNetwork.py to create bridge network. > Cross distribution support patches for configNetwork.py are under > review. ovirt-host-deploy supports Ubuntu bridge configuration as long > as they are merged. > > [1] https://launchpad.net/~zhshzhou/+archive/vdsm-ubuntu > [2] http://www.ovirt.org/images/5/57/Shanghai-VDSM-on-Ubuntu.pdf > > Here goes the detailed hack patch. The hack was base on v1.0.1, I > rebased it to the latest master. The rebased patch are not tested. If > you find this email useless, it's actually a good news, which means > there is not a lot of work and problems ahead ;-) > > Hack patch for ovirt-host-deploy. > > From 120493a242046d19794ef3da83b32486d372aa39 Mon Sep 17 00:00:00 2001 > From: Zhou Zheng Sheng > Date: Wed, 13 Nov 2013 18:02:26 +0800 > Subject: [PATCH] Ubuntu Hacks > > Change-Id: Ifb4ebc829101c92d06475619b1b5986e87b83d57 > Signed-off-by: Zhou Zheng Sheng > --- > src/plugins/ovirt-host-deploy/gluster/packages.py | 17 +++++---- > src/plugins/ovirt-host-deploy/tune/tuned.py | 3 +- > src/plugins/ovirt-host-deploy/vdsm/bridge.py | 45 > ++++++++++++----------- > src/plugins/ovirt-host-deploy/vdsm/packages.py | 9 +++-- > src/plugins/ovirt-host-deploy/vdsm/pki.py | 3 +- > src/plugins/ovirt-host-deploy/vdsm/software.py | 2 + > src/plugins/ovirt-host-deploy/vdsm/vdsmid.py | 3 +- > 7 files changed, 45 insertions(+), 37 deletions(-) > > diff --git a/src/plugins/ovirt-host-deploy/gluster/packages.py > b/src/plugins/ovirt-host-deploy/gluster/packages.py > index 1fecfda..eb37744 100644 > --- a/src/plugins/ovirt-host-deploy/gluster/packages.py > +++ b/src/plugins/ovirt-host-deploy/gluster/packages.py > @@ -60,13 +60,13 @@ class Plugin(plugin.PluginBase): > ), > ) > def _validation(self): > - if not self.packager.queryPackages(patterns=('vdsm-gluster',)): > - raise RuntimeError( > - _( > - 'Cannot locate gluster packages, ' > - 'possible cause is incorrect channels' > - ) > - ) > + # if not self.packager.queryPackages(patterns=('vdsm-gluster',)): > + # raise RuntimeError( > + # _( > + # 'Cannot locate gluster packages, ' > + # 'possible cause is incorrect channels' > + # ) > + # ) > self._enabled = True > > @plugin.event( > @@ -74,7 +74,8 @@ class Plugin(plugin.PluginBase): > condition=lambda self: self._enabled, > ) > def _packages(self): > - self.packager.installUpdate(('vdsm-gluster',)) > + # self.packager.installUpdate(('vdsm-gluster',)) > + pass > > @plugin.event( > stage=plugin.Stages.STAGE_CLOSEUP, > diff --git a/src/plugins/ovirt-host-deploy/tune/tuned.py > b/src/plugins/ovirt-host-deploy/tune/tuned.py > index d8e00c5..d0dcea5 100644 > --- a/src/plugins/ovirt-host-deploy/tune/tuned.py > +++ b/src/plugins/ovirt-host-deploy/tune/tuned.py > @@ -70,7 +70,8 @@ class Plugin(plugin.PluginBase): > condition=lambda self: self._enabled, > ) > def _packages(self): > - self.packager.installUpdate(('tuned',)) > + # self.packager.installUpdate(('tuned',)) > + pass > > @plugin.event( > stage=plugin.Stages.STAGE_MISC, > diff --git a/src/plugins/ovirt-host-deploy/vdsm/bridge.py > b/src/plugins/ovirt-host-deploy/vdsm/bridge.py > index 3789d62..64cce40 100644 > --- a/src/plugins/ovirt-host-deploy/vdsm/bridge.py > +++ b/src/plugins/ovirt-host-deploy/vdsm/bridge.py > @@ -595,7 +595,8 @@ class Plugin(plugin.PluginBase): > stage=plugin.Stages.STAGE_INTERNAL_PACKAGES, > ) > def _internal_packages(self): > - self.packager.install(packages=('iproute',)) > + # self.packager.install(packages=('iproute',)) > + pass > > @plugin.event( > stage=plugin.Stages.STAGE_VALIDATION, > @@ -771,27 +772,27 @@ class Plugin(plugin.PluginBase): > interface = self._getInterfaceToInstallBasedOnDestination( > address=self.environment[odeploycons.VdsmEnv.ENGINE_ADDRESS] > ) > - parameters = > self._rhel_getInterfaceConfigParameters(name=interface) > - > - # The followin can be executed > - # only at node as we won't reach here > - # if we are not running on node > - if ( > - self.environment[odeploycons.VdsmEnv.OVIRT_NODE] and > - self._interfaceIsBridge(name=interface) > - ): > - nic = interface.replace('br', '', 1) > - self._removeBridge( > - name=interface, > - interface=nic, > - ) > - interface = nic > - > - self._createBridge( > - > name=self.environment[odeploycons.VdsmEnv.MANAGEMENT_BRIDGE_NAME], > - interface=interface, > - parameters=parameters, > - ) > + # parameters = > self._rhel_getInterfaceConfigParameters(name=interface) > + > + # # The followin can be executed > + # # only at node as we won't reach here > + # # if we are not running on node > + # if ( > + # self.environment[odeploycons.VdsmEnv.OVIRT_NODE] and > + # self._interfaceIsBridge(name=interface) > + # ): > + # nic = interface.replace('br', '', 1) > + # self._removeBridge( > + # name=interface, > + # interface=nic, > + # ) > + # interface = nic > + > + # self._createBridge( > + # > name=self.environment[odeploycons.VdsmEnv.MANAGEMENT_BRIDGE_NAME], > + # interface=interface, > + # parameters=parameters, > + # ) > > self._waitForRoute( > host=( > diff --git a/src/plugins/ovirt-host-deploy/vdsm/packages.py > b/src/plugins/ovirt-host-deploy/vdsm/packages.py > index d819caa..b526d4b 100644 > --- a/src/plugins/ovirt-host-deploy/vdsm/packages.py > +++ b/src/plugins/ovirt-host-deploy/vdsm/packages.py > @@ -68,7 +68,8 @@ class Plugin(plugin.PluginBase): > stage=plugin.Stages.STAGE_VALIDATION, > ) > def _validation(self): > - result = self.packager.queryPackages(patterns=('vdsm',)) > + # result = self.packager.queryPackages(patterns=('vdsm',)) > + result = ({'version': '4.10.3', 'release': '1'},) > if not result: > raise RuntimeError( > _( > @@ -106,8 +107,8 @@ class Plugin(plugin.PluginBase): > self.services.state('vdsmd', False) > if self.services.exists('supervdsmd'): > self.services.state('supervdsmd', False) > - self.packager.install(('qemu-kvm-tools',)) > - self.packager.installUpdate(('vdsm', 'vdsm-cli')) > + # self.packager.install(('qemu-kvm-tools',)) > + # self.packager.installUpdate(('vdsm', 'vdsm-cli')) > > @plugin.event( > stage=plugin.Stages.STAGE_CLOSEUP, > @@ -119,7 +120,7 @@ class Plugin(plugin.PluginBase): > self.services.state('libvirt-guests', False) > self.services.startup('libvirt-guests', False) > > - self.services.startup('vdsmd', True) > + # self.services.startup('vdsmd', True) > if not self.services.supportsDependency: > if self.services.exists('libvirtd'): > self.services.startup('libvirtd', True) > diff --git a/src/plugins/ovirt-host-deploy/vdsm/pki.py > b/src/plugins/ovirt-host-deploy/vdsm/pki.py > index f374a99..c013527 100644 > --- a/src/plugins/ovirt-host-deploy/vdsm/pki.py > +++ b/src/plugins/ovirt-host-deploy/vdsm/pki.py > @@ -208,7 +208,8 @@ class Plugin(plugin.PluginBase): > condition=lambda self: self._enabled, > ) > def _packages(self): > - self.packager.install(('m2crypto',)) > + # self.packager.install(('m2crypto',)) > + pass > > @plugin.event( > stage=plugin.Stages.STAGE_MISC, > diff --git a/src/plugins/ovirt-host-deploy/vdsm/software.py > b/src/plugins/ovirt-host-deploy/vdsm/software.py > index 2f0ec80..a226816 100644 > --- a/src/plugins/ovirt-host-deploy/vdsm/software.py > +++ b/src/plugins/ovirt-host-deploy/vdsm/software.py > @@ -65,6 +65,8 @@ class Plugin(plugin.PluginBase): > version=ver, > ) > ) > + elif dist == 'Ubuntu': > + pass > else: > raise RuntimeError( > _('Distribution {distribution} is not supported').format( > diff --git a/src/plugins/ovirt-host-deploy/vdsm/vdsmid.py > b/src/plugins/ovirt-host-deploy/vdsm/vdsmid.py > index 328ad17..465212a 100644 > --- a/src/plugins/ovirt-host-deploy/vdsm/vdsmid.py > +++ b/src/plugins/ovirt-host-deploy/vdsm/vdsmid.py > @@ -78,7 +78,8 @@ class Plugin(plugin.PluginBase): > ) > def _packages(self): > if platform.machine() in ('x86_64', 'i686'): > - self.packager.install(('dmidecode',)) > + # self.packager.install(('dmidecode',)) > + pass > > @plugin.event( > stage=plugin.Stages.STAGE_CUSTOMIZATION, > -- > 1.7.11.7 > > > Hack patch for otopi. > > From 3e7022b740f24d8053d3e32c20fa6d492631db80 Mon Sep 17 00:00:00 2001 > From: Zhou Zheng Sheng > Date: Wed, 13 Nov 2013 17:55:39 +0800 > Subject: [PATCH] Ubuntu Hacks > > --- > src/plugins/otopi/network/hostname.py | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/src/plugins/otopi/network/hostname.py > b/src/plugins/otopi/network/hostname.py > index bb07627..28b4866 100644 > --- a/src/plugins/otopi/network/hostname.py > +++ b/src/plugins/otopi/network/hostname.py > @@ -63,7 +63,8 @@ class Plugin(plugin.PluginBase): > stage=plugin.Stages.STAGE_INTERNAL_PACKAGES, > ) > def _internal_packages(self): > - self.packager.install(packages=['iproute']) > + # self.packager.install(packages=['iproute']) > + pass > > @plugin.event( > stage=plugin.Stages.STAGE_VALIDATION, > -- > 1.7.11.7 > > -- > Thanks and best regards! > > Zhou Zheng Sheng / ??? > E-mail: zhshzhou at linux.vnet.ibm.com > Telephone: 86-10-82454397 > > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > From piotr.kliczewski at gmail.com Thu Nov 14 10:01:00 2013 From: piotr.kliczewski at gmail.com (Piotr Kliczewski) Date: Thu, 14 Nov 2013 11:01:00 +0100 Subject: [Engine-devel] OpenLdap and Kerberos for oVirt on f19 Message-ID: Hello everyone, I working on configuring OpenLdap 2.4.36 with kerberos for oVirt running on f19. I follow following instruction: https://bugzilla.redhat.com/show_bug.cgi?id=967327#c5 Please note that the instruction was written for f18. In order to have step 18 working from command line I had to set SASL_NOCANON to off. The reason was that I got: ldap_sasl_interactive_bind_s: Invalid credentials (49) additional info: SASL(-13): authentication failure: GSSAPI Failure: gss_accept_sec_context When SASL_NOCANON is off I can search the ldap but have the same issue from java code: I got javax.naming.AuthenticationException: [LDAP: error code 49 - SASL(-13): authentication failure: GSSAPI Failure: gss_accept_sec_context]. Have this when connecting using engine-manage-domains (http://gerrit.ovirt.org/gitweb?p=ovirt-engine.git;a=blob;f=backend/manager/modules/utils/src/main/java/org/ovirt/engine/core/utils/kerberos/JndiAction.java;h=467d64cb03523ba7e5144a57d6a60428f039656f;hb=refs/heads/master line 84). Can you please point me where is my config issue? I copied engine-devel for reference. Thanks, Piotr From jhernand at redhat.com Thu Nov 14 10:05:50 2013 From: jhernand at redhat.com (Juan Hernandez) Date: Thu, 14 Nov 2013 11:05:50 +0100 Subject: [Engine-devel] OpenLdap and Kerberos for oVirt on f19 In-Reply-To: References: Message-ID: <5284A07E.4020907@redhat.com> On 11/14/2013 11:01 AM, Piotr Kliczewski wrote: > Hello everyone, > > I working on configuring OpenLdap 2.4.36 with kerberos for oVirt running on f19. > > I follow following instruction: > https://bugzilla.redhat.com/show_bug.cgi?id=967327#c5 > > Please note that the instruction was written for f18. In order to have > step 18 working from > command line I had to set SASL_NOCANON to off. The reason was that I got: > > ldap_sasl_interactive_bind_s: Invalid credentials (49) > additional info: SASL(-13): authentication failure: GSSAPI Failure: > gss_accept_sec_context > > When SASL_NOCANON is off I can search the ldap but have the same issue > from java code: > > I got javax.naming.AuthenticationException: [LDAP: error code 49 - > SASL(-13): authentication failure: GSSAPI Failure: > gss_accept_sec_context]. > Have this when connecting using engine-manage-domains > (http://gerrit.ovirt.org/gitweb?p=ovirt-engine.git;a=blob;f=backend/manager/modules/utils/src/main/java/org/ovirt/engine/core/utils/kerberos/JndiAction.java;h=467d64cb03523ba7e5144a57d6a60428f039656f;hb=refs/heads/master > line 84). > > Can you please point me where is my config issue? > > I copied engine-devel for reference. > Do you have the cyrus-sasl-gssapi package installed? That should have been part of step 1. Try this: # yum -y install cyrus-sasl-gssapi I think that once that is installed you shouldn't need to set SASL_NOCANON off. -- Direcci?n Comercial: C/Jose Bardasano Baos, 9, Edif. Gorbea 3, planta 3?D, 28016 Madrid, Spain Inscrita en el Reg. Mercantil de Madrid ? C.I.F. B82657941 - Red Hat S.L. From piotr.kliczewski at gmail.com Thu Nov 14 10:19:32 2013 From: piotr.kliczewski at gmail.com (Piotr Kliczewski) Date: Thu, 14 Nov 2013 11:19:32 +0100 Subject: [Engine-devel] OpenLdap and Kerberos for oVirt on f19 In-Reply-To: <5284A07E.4020907@redhat.com> References: <5284A07E.4020907@redhat.com> Message-ID: On Thu, Nov 14, 2013 at 11:05 AM, Juan Hernandez wrote: > On 11/14/2013 11:01 AM, Piotr Kliczewski wrote: >> Hello everyone, >> >> I working on configuring OpenLdap 2.4.36 with kerberos for oVirt running on f19. >> >> I follow following instruction: >> https://bugzilla.redhat.com/show_bug.cgi?id=967327#c5 >> >> Please note that the instruction was written for f18. In order to have >> step 18 working from >> command line I had to set SASL_NOCANON to off. The reason was that I got: >> >> ldap_sasl_interactive_bind_s: Invalid credentials (49) >> additional info: SASL(-13): authentication failure: GSSAPI Failure: >> gss_accept_sec_context >> >> When SASL_NOCANON is off I can search the ldap but have the same issue >> from java code: >> >> I got javax.naming.AuthenticationException: [LDAP: error code 49 - >> SASL(-13): authentication failure: GSSAPI Failure: >> gss_accept_sec_context]. >> Have this when connecting using engine-manage-domains >> (http://gerrit.ovirt.org/gitweb?p=ovirt-engine.git;a=blob;f=backend/manager/modules/utils/src/main/java/org/ovirt/engine/core/utils/kerberos/JndiAction.java;h=467d64cb03523ba7e5144a57d6a60428f039656f;hb=refs/heads/master >> line 84). >> >> Can you please point me where is my config issue? >> >> I copied engine-devel for reference. >> > > Do you have the cyrus-sasl-gssapi package installed? That should have > been part of step 1. Try this: > > # yum -y install cyrus-sasl-gssapi > > I think that once that is installed you shouldn't need to set > SASL_NOCANON off. > You are right the package was not installed I restarted slapd, krb5kdc and kadmin after installing. I kinit one more time and tried to ldapsearch as in step 18 but with the same result. > -- > Direcci?n Comercial: C/Jose Bardasano Baos, 9, Edif. Gorbea 3, planta > 3?D, 28016 Madrid, Spain > Inscrita en el Reg. Mercantil de Madrid ? C.I.F. B82657941 - Red Hat S.L. From piotr.kliczewski at gmail.com Thu Nov 14 11:25:58 2013 From: piotr.kliczewski at gmail.com (Piotr Kliczewski) Date: Thu, 14 Nov 2013 12:25:58 +0100 Subject: [Engine-devel] OpenLdap and Kerberos for oVirt on f19 In-Reply-To: References: <5284A07E.4020907@redhat.com> Message-ID: Working closely with Juan we manged to find the issue. During the process of configuration changed the hostname and I commented old hostname in the /etc/hostname file. Removing the comment helped. On Thu, Nov 14, 2013 at 11:19 AM, Piotr Kliczewski wrote: > On Thu, Nov 14, 2013 at 11:05 AM, Juan Hernandez wrote: >> On 11/14/2013 11:01 AM, Piotr Kliczewski wrote: >>> Hello everyone, >>> >>> I working on configuring OpenLdap 2.4.36 with kerberos for oVirt running on f19. >>> >>> I follow following instruction: >>> https://bugzilla.redhat.com/show_bug.cgi?id=967327#c5 >>> >>> Please note that the instruction was written for f18. In order to have >>> step 18 working from >>> command line I had to set SASL_NOCANON to off. The reason was that I got: >>> >>> ldap_sasl_interactive_bind_s: Invalid credentials (49) >>> additional info: SASL(-13): authentication failure: GSSAPI Failure: >>> gss_accept_sec_context >>> >>> When SASL_NOCANON is off I can search the ldap but have the same issue >>> from java code: >>> >>> I got javax.naming.AuthenticationException: [LDAP: error code 49 - >>> SASL(-13): authentication failure: GSSAPI Failure: >>> gss_accept_sec_context]. >>> Have this when connecting using engine-manage-domains >>> (http://gerrit.ovirt.org/gitweb?p=ovirt-engine.git;a=blob;f=backend/manager/modules/utils/src/main/java/org/ovirt/engine/core/utils/kerberos/JndiAction.java;h=467d64cb03523ba7e5144a57d6a60428f039656f;hb=refs/heads/master >>> line 84). >>> >>> Can you please point me where is my config issue? >>> >>> I copied engine-devel for reference. >>> >> >> Do you have the cyrus-sasl-gssapi package installed? That should have >> been part of step 1. Try this: >> >> # yum -y install cyrus-sasl-gssapi >> >> I think that once that is installed you shouldn't need to set >> SASL_NOCANON off. >> > You are right the package was not installed I restarted slapd, krb5kdc > and kadmin after installing. I kinit one more time and tried to > ldapsearch as in step 18 but with the same result. >> -- >> Direcci?n Comercial: C/Jose Bardasano Baos, 9, Edif. Gorbea 3, planta >> 3?D, 28016 Madrid, Spain >> Inscrita en el Reg. Mercantil de Madrid ? C.I.F. B82657941 - Red Hat S.L. From mpastern at redhat.com Thu Nov 14 12:46:56 2013 From: mpastern at redhat.com (Michael Pasternak) Date: Thu, 14 Nov 2013 14:46:56 +0200 Subject: [Engine-devel] ovirt-cli 3.4.0.1 released In-Reply-To: <5180CF89.60400@redhat.com> References: <5180CF89.60400@redhat.com> Message-ID: <5284C640.3060508@redhat.com> - implement CLI invocation capabilities #895559 - expose api capabilities in cli #891227 - add the option to retrieve partial history #957499 - construct object using factory on update #950684 - added new state - UNAUTHORIZED - implement StateMachine - implement event driven messaging - implement visualization effects - history length was limited to 3000 records - raise CommandError on generic errors - implicitly disconnect on exit - ovirt-shell does not exit when using -f option #854519 - eliminate ambiguity by adding suffix -identifier to parent's options #1027281 - do not ask for credentials at /help in auto-connect mode #1026798 - list xxx --show all - output is not well formatted #890038 More details can be found at [1]. [1] http://wiki.ovirt.org/Cli-changelog -- Michael Pasternak RedHat, ENG-Virtualization R&D From mpastern at redhat.com Thu Nov 14 14:56:06 2013 From: mpastern at redhat.com (Michael Pasternak) Date: Thu, 14 Nov 2013 16:56:06 +0200 Subject: [Engine-devel] RSDL breakage in oVirt upstream In-Reply-To: <5284DEE8.6000501@redhat.com> References: <5284DEE8.6000501@redhat.com> Message-ID: <5284E486.7010502@redhat.com> Hi Shubhendu, On 11/14/2013 04:32 PM, Shubhendu Tripathi wrote: > Hi Michael/Ori, > > There is payload breakage for RSDL in upstream oVirt. can you elaborate a bit? [1] works for me. [1] http://localhost:8080/api?rsdl > This has happened somewhere between the patches gerrit.ovirt.org/#/c/20610/ and http://gerrit.ovirt.org/#/c/15409/. > If I try to test out with patch http://gerrit.ovirt.org/#/c/15409/, it does break. > > Not sure what could be the issue. Tried debugging but not able to figure it out. > > Kindly help me on the same figuring out what could be the issue. > > Thanks and Regards, > Shubhendu > -- Michael Pasternak RedHat, ENG-Virtualization R&D From piotr.kliczewski at gmail.com Thu Nov 14 15:18:33 2013 From: piotr.kliczewski at gmail.com (Piotr Kliczewski) Date: Thu, 14 Nov 2013 16:18:33 +0100 Subject: [Engine-devel] Consideration of the permission type Message-ID: Hello everyone, I am working on https://bugzilla.redhat.com/show_bug.cgi?id=878812 bug so I played a bit with the code to understand how permission system works and noticed few things (please correct me if I am wrong): - In order to login to admin portal user need to have one of the admin roles (role_type = 1) - system tree is built using number of queries - before running each query permission validation happens so the code checks whether the user is able to run a query - I noticed that none of the queries required to build system tree is admin query and validation depends on result of getUser().isAdmin() (Please check http://gerrit.ovirt.org/gitweb?p=ovirt-engine.git;a=blob;f=backend/manager/modules/bll/src/main/java/org/ovirt/engine/core/bll/QueriesCommandBase.java;h=42b4985830033579802c278a6bae932cf0ffa3c7;hb=refs/heads/master line 123). This statement is always true for a user which was able to log in to admin portal. I was able to come up with following ways to solve this issue (please help to find the good enough): - fix verification - filter results of query - change a bit permission model. The structure is quite flat (there are only 2 role_types) or we could go with containers as it was proposed in bug description. Thanks, Piotr From ofrenkel at redhat.com Thu Nov 14 16:14:09 2013 From: ofrenkel at redhat.com (Omer Frenkel) Date: Thu, 14 Nov 2013 11:14:09 -0500 (EST) Subject: [Engine-devel] Error message while trying to delete default cluster In-Reply-To: <52807739.30303@redhat.com> References: <52807739.30303@redhat.com> Message-ID: <1138912638.4750404.1384445649794.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Shubhendu Tripathi" > To: "engine-devel" , "michal skrivanek" , "Omer Frenkel" > , "Allon Mureinik" > Cc: "Dusmant Pati" > Sent: Monday, November 11, 2013 8:20:41 AM > Subject: Error message while trying to delete default cluster > > Hi, > > While trying to delete the Default cluster in oVirt it shows the below > error message - > > "Cannot remove default Host Cluster. > Cannot remove Cluster. One or more Template(s) are still associated with it" > > But in the case of RHSC, Templates are not used and this message is not > relevant. [1]. > > Can we opt for not installing the templates while engine setup? And > would it be having any impact/consequences ? > > Kindly provide your thoughts and possibility of the same. > > Thanks and Regards, > Shubhendu > > PS: > [1]: https://bugzilla.redhat.com/show_bug.cgi?id=1019838 > removing the blank template means the system couldn't be used to create vms at all. but blank template is not the only problem, there is an explicit check that prevent deleting the default cluster (RemoveVdsGroupCommand class, line #35), i couldn't find the commit that added this, but i /think/ its because by default host registration is done to the default cluster, so it had to exist. so this should be solved first. then, if we decide to have a 'non-virt' installation we probably could avoid default cluster and blank template. but what if user changes his mind after installation? another option is to remove the protection from DB level and make cluster-id nullable in the vm_static table, and have logic to allow removing last cluster and update template on new cluster addition. From mpastern at redhat.com Thu Nov 14 17:12:25 2013 From: mpastern at redhat.com (Michael Pasternak) Date: Thu, 14 Nov 2013 19:12:25 +0200 Subject: [Engine-devel] ovirt-cli 3.4.0.2 released In-Reply-To: <5284C640.3060508@redhat.com> References: <5284C640.3060508@redhat.com> Message-ID: <52850479.1000805@redhat.com> - added missing package descriptors in setup.py (required for easy_install deployment) More details can be found at [1]. [1] http://wiki.ovirt.org/Cli-changelog -- Michael Pasternak RedHat, ENG-Virtualization R&D From mrao at redhat.com Thu Nov 14 20:17:48 2013 From: mrao at redhat.com (Malini Rao) Date: Thu, 14 Nov 2013 15:17:48 -0500 (EST) Subject: [Engine-devel] [UX] how to design a bar/line chart? In-Reply-To: <5D98AD7F-83C0-48D5-9252-5CD0B220B775@redhat.com> References: <157528892.18409921.1383645002815.JavaMail.root@redhat.com> <52790A6A.9000808@redhat.com> <1596552383.20866728.1383747975841.JavaMail.root@redhat.com> <424101873.19454345.1383749883282.JavaMail.root@redhat.com> <1306019229.17661019.1383751496579.JavaMail.root@redhat.com> <858746798.4081108.1384384154972.JavaMail.root@redhat.com> <5D98AD7F-83C0-48D5-9252-5CD0B220B775@redhat.com> Message-ID: <750008068.23476473.1384460268160.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Michal Skrivanek" > To: "Einav Cohen" > Cc: "Malini Rao" , "Tomas Jelinek" , "Eldan Hildesheim" , > "info" , "engine-devel" > Sent: Thursday, November 14, 2013 2:21:03 AM > Subject: Re: [Engine-devel] [UX] how to design a bar/line chart? > > > On Nov 14, 2013, at 00:09 , Einav Cohen wrote: > > >> ... but we may have to see how this looks when multiple sparklines > >> reside in columns next to each other. > >> ... > >> ... > >> Is this going to fit in a row of a table? Or are we talking of a > >> more detailed view? > >> ... > > > > a concern on which I happened to briefly discuss with Eldan / Malini > > and actually somewhat raised here earlier in the thread (see above): > > Since we are adding another information "dimension" (time), we are > > actually going to display a lot more information to the user within the > > CPU/MEM/NET columns, and there is a chance that the view will become > > too overloaded/confusing, and we will end up with a view that is less > > clear than the current one. > > Well, for that we IMHO have much bigger issue already with the fact we do not > hide/show columns, and many of them do not really provide much value in all > use cases. If you look at the mockup and the screenshots from users I've > seen - e.g. the Display column(don't care), the Cluster (not wide enough, > repetition of the same info on each line), Host(repetition of domain parts > of FQDN) makes it overloaded already. Agreed and I think we should address that and some efforts in terms of designs are underway for some of these issues. However, I think Einav's point was about increasing the amount of info in each of those 3 columns exponentially since it is a trend and not a single value. Having said that, I think the trend represented as a sparkline/ trendline is not meant to give you that many more datapoints - It gives you the current value and an idea of the trend based on the 'shape' of the trend line and not the individual peaks and troughs. So I think it is not that much of a leap in terms of the cognitive overload. > Since statistics do provide some value and it keeps changing based on load it > IMHO looks ok I think the question in my mind here is if the trendline is indeed a better visualization for all these three attributes? In other words, is a trend for the memory as valuable as a trend for network or CPU? Or is it more useful for the user to see the current visualization for memory that fills the bar as it gets closer to 100% and turns red? The point I am trying to make is that the trendline/ sparkline is not necessarily a widget with cognitive overload but it is still worth considering if it is the right data visualization for the attribute. So is it possible that only one or more of these attributes is a sparkline? > ...maybe just a global setting to disable this if it gets annoying? It's a > small feature and it's trivial to add such a setting. I am averse to turning it off completely since it will be less than what they have today but may be if they are displaying a trend, they should be able to choose to only see the current value... > > > > > Just so we will have a general idea of how it will look like eventually, > > so we will be able to do a slightly more educated decision, I am attaching > > a mock-up of how it looks now compared to how it may look once this > > feature is implemented. Einav, the mockup looks awesome.. you beat me to it! :) Also, after looking at the mockup, I am less worried about the 3 sparkline columns displaying next to each other especially because the current value breaks the lines from all merging together. > > > > * In my mock-up, I followed Malini's guideline from earlier in the thread: > > """ > > One color with a dot to indicate the most recent or most relevant data > > and display its value next to the sparkline > > """ I think Sparklines lend themselves less to status/ threshold indicators that rely on color. One example that I found potentially acceptable is http://chandoo.org/img/2010/introduction-to-excel-sparklines.png. In our case, the current value dot can be red, green or any other color based on the ranges defined and the colors associated with it. If we have colored dots, we should possibly change the shape of the marker too for each color so that color blind people can still find value on this as a status indicator. > Thanks for the mock up, I think it looks great. Perhaps I'd consider lines > instead of dots (to see the base 0, currently the line is somehow "in the > air" and since the height is limited it may be difficult to distinguissh 20% > from 0%), provided they are in some light color it may look ok I am not sure I completely understand the request here. Is there a need to clearly mark the zero/baseline here? Or need multiple dots to highlight various values on the line? Or are we needing a band like this (https://www.broadbandmetrics.com/download/attachments/3768372/TufteSparklne_medical.jpg?version=1&modificationDate=1362506139000) to mark the desirable range? One thing I want to make sure we are on the same page is that the sparkline is definitely not a good widget to distinguish small or accurate changes but more the current position in relation to the overall shape. > > > > > * keep in mind that the view is dynamic and keeps updating once it > > receives new statistics from the backend. > > > > Thoughts? > > > > > > ----- Original Message ----- > >> From: "Malini Rao" > >> To: "Tomas Jelinek" > >> Cc: "Einav Cohen" , "engine-devel" > >> , "Eldan Hildesheim" > >> , "info" , "Martin Polednik" > >> > >> 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 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? 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 at 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 at ovirt.org > >>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel > >>>>> > >>>>> > >>>>> > >>>> > >>> > > > > From ecohen at redhat.com Thu Nov 14 21:10:54 2013 From: ecohen at redhat.com (Einav Cohen) Date: Thu, 14 Nov 2013 16:10:54 -0500 (EST) Subject: [Engine-devel] [UX] how to design a bar/line chart? In-Reply-To: <750008068.23476473.1384460268160.JavaMail.root@redhat.com> References: <157528892.18409921.1383645002815.JavaMail.root@redhat.com> <52790A6A.9000808@redhat.com> <1596552383.20866728.1383747975841.JavaMail.root@redhat.com> <424101873.19454345.1383749883282.JavaMail.root@redhat.com> <1306019229.17661019.1383751496579.JavaMail.root@redhat.com> <858746798.4081108.1384384154972.JavaMail.root@redhat.com> <5D98AD7F-83C0-48D5-9252-5CD0B220B775@redhat.com> <750008068.23476473.1384460268160.JavaMail.root@redhat.com> Message-ID: <356685769.5458199.1384463454334.JavaMail.root@redhat.com> > > ...maybe just a global setting to disable this if it gets annoying? It's a > > small feature and it's trivial to add such a setting. > @Michal: I am not sure what you mean by "disable"; if you mean "hide (the columns)", then I think that we should rely on the global "show/hide columns" feature, and not create a dedicated configuration value for these particular columns. Moreover, the global "show/hide columns" feature will allow customization per user/client, rather than a global-configuration-level customization, so each user will be able to define his view as he wishes. > I am averse to turning it off completely since it will be less than what they > have today but may be if they are displaying a trend, they should be able to > choose to only see the current value... @Malini, do you mean that they need the option to "fallback" to the current "bar" design (which reflects only the current value)? or something else? > ... If we have colored dots, we should possibly change the shape of the marker > too for each color so that color blind people can still find value on this as > a status indicator. I like the idea of colored dots; not sure about the different shapes though, as the dots would be pretty tiny; in the color-blind case: wouldn't it be sufficient to rely on the dot "height" + the textual value? > > Thanks for the mock up, I think it looks great. Perhaps I'd consider lines > > instead of dots (to see the base 0, currently the line is somehow "in the > > air" and since the height is limited it may be difficult to distinguissh > > 20% > > from 0%), provided they are in some light color it may look ok > > I am not sure I completely understand the request here. Is there a need to > clearly mark the zero/baseline here? Or need multiple dots to highlight > various values on the line? Or are we needing a band like this > (https://www.broadbandmetrics.com/download/attachments/3768372/TufteSparklne_medical.jpg?version=1&modificationDate=1362506139000) > to mark the desirable range? One thing I want to make sure we are on the > same page is that the sparkline is definitely not a good widget to > distinguish small or accurate changes but more the current position in > relation to the overall shape. I think that we are all on the same page here (others - please correct me if I am wrong) that only the general trend is of interest here, and not the exact values (maybe with the exception of the "last" value in each trendline). I believe that Michal was referring to axes [in particular the horizontal ('x') axis, I assume] so indeed we will have a clearer baseline for the trend. theoretically we can also have a "band", as you suggested, just need to well- define the "range" of the band so it would makes sense (not sure if easy to do). I am attaching an updated mock-up with axes (only added for the first few lines) as well as colored dots, as you (Malini) suggested above. ---- Thanks, Einav ----- Original Message ----- > From: "Malini Rao" > To: "Michal Skrivanek" > Cc: "Eldan Hildesheim" , "engine-devel" , "info" > Sent: Thursday, November 14, 2013 3:17:48 PM > Subject: Re: [Engine-devel] [UX] how to design a bar/line chart? > > ----- Original Message ----- > > From: "Michal Skrivanek" > > To: "Einav Cohen" > > Cc: "Malini Rao" , "Tomas Jelinek" , > > "Eldan Hildesheim" , > > "info" , "engine-devel" > > Sent: Thursday, November 14, 2013 2:21:03 AM > > Subject: Re: [Engine-devel] [UX] how to design a bar/line chart? > > > > > > On Nov 14, 2013, at 00:09 , Einav Cohen wrote: > > > > >> ... but we may have to see how this looks when multiple sparklines > > >> reside in columns next to each other. > > >> ... > > >> ... > > >> Is this going to fit in a row of a table? Or are we talking of a > > >> more detailed view? > > >> ... > > > > > > a concern on which I happened to briefly discuss with Eldan / Malini > > > and actually somewhat raised here earlier in the thread (see above): > > > Since we are adding another information "dimension" (time), we are > > > actually going to display a lot more information to the user within the > > > CPU/MEM/NET columns, and there is a chance that the view will become > > > too overloaded/confusing, and we will end up with a view that is less > > > clear than the current one. > > > > Well, for that we IMHO have much bigger issue already with the fact we do > > not > > hide/show columns, and many of them do not really provide much value in all > > use cases. If you look at the mockup and the screenshots from users I've > > seen - e.g. the Display column(don't care), the Cluster (not wide enough, > > repetition of the same info on each line), Host(repetition of domain parts > > of FQDN) makes it overloaded already. > > Agreed and I think we should address that and some efforts in terms of > designs are underway for some of these issues. However, I think Einav's > point was about increasing the amount of info in each of those 3 columns > exponentially since it is a trend and not a single value. Having said that, > I think the trend represented as a sparkline/ trendline is not meant to give > you that many more datapoints - It gives you the current value and an idea > of the trend based on the 'shape' of the trend line and not the individual > peaks and troughs. So I think it is not that much of a leap in terms of the > cognitive overload. > > > Since statistics do provide some value and it keeps changing based on load > > it > > IMHO looks ok > > I think the question in my mind here is if the trendline is indeed a better > visualization for all these three attributes? In other words, is a trend for > the memory as valuable as a trend for network or CPU? Or is it more useful > for the user to see the current visualization for memory that fills the bar > as it gets closer to 100% and turns red? The point I am trying to make is > that the trendline/ sparkline is not necessarily a widget with cognitive > overload but it is still worth considering if it is the right data > visualization for the attribute. So is it possible that only one or more of > these attributes is a sparkline? > > > > ...maybe just a global setting to disable this if it gets annoying? It's a > > small feature and it's trivial to add such a setting. > > I am averse to turning it off completely since it will be less than what they > have today but may be if they are displaying a trend, they should be able to > choose to only see the current value... > > > > > > > > > Just so we will have a general idea of how it will look like eventually, > > > so we will be able to do a slightly more educated decision, I am > > > attaching > > > a mock-up of how it looks now compared to how it may look once this > > > feature is implemented. > > Einav, the mockup looks awesome.. you beat me to it! :) Also, after looking > at the mockup, I am less worried about the 3 sparkline columns displaying > next to each other especially because the current value breaks the lines > from all merging together. > > > > > > > > * In my mock-up, I followed Malini's guideline from earlier in the > > > thread: > > > """ > > > One color with a dot to indicate the most recent or most relevant data > > > and display its value next to the sparkline > > > """ > > I think Sparklines lend themselves less to status/ threshold indicators that > rely on color. One example that I found potentially acceptable is > http://chandoo.org/img/2010/introduction-to-excel-sparklines.png. In our > case, the current value dot can be red, green or any other color based on > the ranges defined and the colors associated with it. If we have colored > dots, we should possibly change the shape of the marker too for each color > so that color blind people can still find value on this as a status > indicator. > > > > Thanks for the mock up, I think it looks great. Perhaps I'd consider lines > > instead of dots (to see the base 0, currently the line is somehow "in the > > air" and since the height is limited it may be difficult to distinguissh > > 20% > > from 0%), provided they are in some light color it may look ok > > I am not sure I completely understand the request here. Is there a need to > clearly mark the zero/baseline here? Or need multiple dots to highlight > various values on the line? Or are we needing a band like this > (https://www.broadbandmetrics.com/download/attachments/3768372/TufteSparklne_medical.jpg?version=1&modificationDate=1362506139000) > to mark the desirable range? One thing I want to make sure we are on the > same page is that the sparkline is definitely not a good widget to > distinguish small or accurate changes but more the current position in > relation to the overall shape. > > > > > > > > > > * keep in mind that the view is dynamic and keeps updating once it > > > receives new statistics from the backend. > > > > > > Thoughts? > > > > > > > > > ----- Original Message ----- > > >> From: "Malini Rao" > > >> To: "Tomas Jelinek" > > >> Cc: "Einav Cohen" , "engine-devel" > > >> , "Eldan Hildesheim" > > >> , "info" , "Martin Polednik" > > >> > > >> 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 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? 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 at 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 at ovirt.org > > >>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel > > >>>>> > > >>>>> > > >>>>> > > >>>> > > >>> > > > > > > > > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > -------------- next part -------------- A non-text attachment was scrubbed... Name: trendline-mockup--axes-colors.png Type: image/png Size: 700899 bytes Desc: not available URL: From zhshzhou at linux.vnet.ibm.com Fri Nov 15 02:25:32 2013 From: zhshzhou at linux.vnet.ibm.com (Zhou Zheng Sheng) Date: Fri, 15 Nov 2013 10:25:32 +0800 Subject: [Engine-devel] Things to be done to support Ubuntu hosts In-Reply-To: <1314616103.15471867.1384422077452.JavaMail.root@redhat.com> References: <5284744F.6010404@linux.vnet.ibm.com> <1314616103.15471867.1384422077452.JavaMail.root@redhat.com> Message-ID: <5285861C.4090302@linux.vnet.ibm.com> on 2013/11/14 17:41, Yaniv Bronheim wrote: > Hey, > Most of the issues you mentioned in slides 11-13 (http://www.ovirt.org/images/5/57/Shanghai-VDSM-on-Ubuntu.pdf) are already solved (if not all of them), > If there are more issues to solve can you please open RFE bz on them to close those gaps (like making the services' names configurable)? > Hi, the slide 11-13 are about VDSM on Ubuntu compatibility. I believe almost all the problems are fixed now. The remaining part is ovirt-host-deploy. Indeed standalone VDSM installs and runs on Ubuntu well, but we need otopi and ovirt-host-deploy to make a Ubuntu host under the management of Engine. As I mentioned, the things left are adding apt-get support in otopi and finishing reviewing the upsteam configNetwork.py patches in VDSM. Do you mean I should open RFE bz of otopi and ovirt-host-deploy? > Thanks > Yaniv Bronhaim. > > ----- Original Message ----- >> From: "Zhou Zheng Sheng" >> To: "engine-devel" >> Sent: Thursday, November 14, 2013 8:57:19 AM >> Subject: [Engine-devel] Things to be done to support Ubuntu hosts >> >> Hi, >> >> Recently Ubuntu support is added to VDSM, and .deb binray packages can >> be downloaded from launchpad.net PPA [1]. Most of the key features such >> as storage management and VM lifecycle work on Ubuntu. The cross >> distribution network management patches are upstream as well. One big >> piece left is making ovirt-host-deploy support Ubuntu, so that we can >> manage Ubuntu hosts from Engine, thus close the gap on host side. >> >> In May 2013 I made some hacks to ovirt-host-deploy and otopi. I made it >> skipped parts not supported on Ubuntu and configure the environment >> manually, and successfully added Ubuntu host to Engine [2]. >> Unfortunately I have no plans to continue on it, but I'd like to make a >> summary of the things I hacked to help anyone who wants to submit >> patches in future. I was to add a WIKI page but I found there were not >> many items, so a mail would be enough. >> >> 1. Package management operations >> Both otopi and ovirt-host-deploy query for dependency packages and >> install them on demand. The otopi package management just supports yum, >> we need to add apt-get support. Package names are different in Ubuntu, >> so I made a list mapping the names. The list in in VDSM source >> directory, debian/dependencyMap.txt . >> >> 2. Network configuration operations >> ovirt-host-deploy asks VDSM's configNetwork.py to create bridge network. >> Cross distribution support patches for configNetwork.py are under >> review. ovirt-host-deploy supports Ubuntu bridge configuration as long >> as they are merged. >> >> [1] https://launchpad.net/~zhshzhou/+archive/vdsm-ubuntu >> [2] http://www.ovirt.org/images/5/57/Shanghai-VDSM-on-Ubuntu.pdf >> >> Here goes the detailed hack patch. The hack was base on v1.0.1, I >> rebased it to the latest master. The rebased patch are not tested. If >> you find this email useless, it's actually a good news, which means >> there is not a lot of work and problems ahead ;-) >> >> Hack patch for ovirt-host-deploy. >> >> From 120493a242046d19794ef3da83b32486d372aa39 Mon Sep 17 00:00:00 2001 >> From: Zhou Zheng Sheng >> Date: Wed, 13 Nov 2013 18:02:26 +0800 >> Subject: [PATCH] Ubuntu Hacks >> >> Change-Id: Ifb4ebc829101c92d06475619b1b5986e87b83d57 >> Signed-off-by: Zhou Zheng Sheng >> --- >> src/plugins/ovirt-host-deploy/gluster/packages.py | 17 +++++---- >> src/plugins/ovirt-host-deploy/tune/tuned.py | 3 +- >> src/plugins/ovirt-host-deploy/vdsm/bridge.py | 45 >> ++++++++++++----------- >> src/plugins/ovirt-host-deploy/vdsm/packages.py | 9 +++-- >> src/plugins/ovirt-host-deploy/vdsm/pki.py | 3 +- >> src/plugins/ovirt-host-deploy/vdsm/software.py | 2 + >> src/plugins/ovirt-host-deploy/vdsm/vdsmid.py | 3 +- >> 7 files changed, 45 insertions(+), 37 deletions(-) >> >> diff --git a/src/plugins/ovirt-host-deploy/gluster/packages.py >> b/src/plugins/ovirt-host-deploy/gluster/packages.py >> index 1fecfda..eb37744 100644 >> --- a/src/plugins/ovirt-host-deploy/gluster/packages.py >> +++ b/src/plugins/ovirt-host-deploy/gluster/packages.py >> @@ -60,13 +60,13 @@ class Plugin(plugin.PluginBase): >> ), >> ) >> def _validation(self): >> - if not self.packager.queryPackages(patterns=('vdsm-gluster',)): >> - raise RuntimeError( >> - _( >> - 'Cannot locate gluster packages, ' >> - 'possible cause is incorrect channels' >> - ) >> - ) >> + # if not self.packager.queryPackages(patterns=('vdsm-gluster',)): >> + # raise RuntimeError( >> + # _( >> + # 'Cannot locate gluster packages, ' >> + # 'possible cause is incorrect channels' >> + # ) >> + # ) >> self._enabled = True >> >> @plugin.event( >> @@ -74,7 +74,8 @@ class Plugin(plugin.PluginBase): >> condition=lambda self: self._enabled, >> ) >> def _packages(self): >> - self.packager.installUpdate(('vdsm-gluster',)) >> + # self.packager.installUpdate(('vdsm-gluster',)) >> + pass >> >> @plugin.event( >> stage=plugin.Stages.STAGE_CLOSEUP, >> diff --git a/src/plugins/ovirt-host-deploy/tune/tuned.py >> b/src/plugins/ovirt-host-deploy/tune/tuned.py >> index d8e00c5..d0dcea5 100644 >> --- a/src/plugins/ovirt-host-deploy/tune/tuned.py >> +++ b/src/plugins/ovirt-host-deploy/tune/tuned.py >> @@ -70,7 +70,8 @@ class Plugin(plugin.PluginBase): >> condition=lambda self: self._enabled, >> ) >> def _packages(self): >> - self.packager.installUpdate(('tuned',)) >> + # self.packager.installUpdate(('tuned',)) >> + pass >> >> @plugin.event( >> stage=plugin.Stages.STAGE_MISC, >> diff --git a/src/plugins/ovirt-host-deploy/vdsm/bridge.py >> b/src/plugins/ovirt-host-deploy/vdsm/bridge.py >> index 3789d62..64cce40 100644 >> --- a/src/plugins/ovirt-host-deploy/vdsm/bridge.py >> +++ b/src/plugins/ovirt-host-deploy/vdsm/bridge.py >> @@ -595,7 +595,8 @@ class Plugin(plugin.PluginBase): >> stage=plugin.Stages.STAGE_INTERNAL_PACKAGES, >> ) >> def _internal_packages(self): >> - self.packager.install(packages=('iproute',)) >> + # self.packager.install(packages=('iproute',)) >> + pass >> >> @plugin.event( >> stage=plugin.Stages.STAGE_VALIDATION, >> @@ -771,27 +772,27 @@ class Plugin(plugin.PluginBase): >> interface = self._getInterfaceToInstallBasedOnDestination( >> address=self.environment[odeploycons.VdsmEnv.ENGINE_ADDRESS] >> ) >> - parameters = >> self._rhel_getInterfaceConfigParameters(name=interface) >> - >> - # The followin can be executed >> - # only at node as we won't reach here >> - # if we are not running on node >> - if ( >> - self.environment[odeploycons.VdsmEnv.OVIRT_NODE] and >> - self._interfaceIsBridge(name=interface) >> - ): >> - nic = interface.replace('br', '', 1) >> - self._removeBridge( >> - name=interface, >> - interface=nic, >> - ) >> - interface = nic >> - >> - self._createBridge( >> - >> name=self.environment[odeploycons.VdsmEnv.MANAGEMENT_BRIDGE_NAME], >> - interface=interface, >> - parameters=parameters, >> - ) >> + # parameters = >> self._rhel_getInterfaceConfigParameters(name=interface) >> + >> + # # The followin can be executed >> + # # only at node as we won't reach here >> + # # if we are not running on node >> + # if ( >> + # self.environment[odeploycons.VdsmEnv.OVIRT_NODE] and >> + # self._interfaceIsBridge(name=interface) >> + # ): >> + # nic = interface.replace('br', '', 1) >> + # self._removeBridge( >> + # name=interface, >> + # interface=nic, >> + # ) >> + # interface = nic >> + >> + # self._createBridge( >> + # >> name=self.environment[odeploycons.VdsmEnv.MANAGEMENT_BRIDGE_NAME], >> + # interface=interface, >> + # parameters=parameters, >> + # ) >> >> self._waitForRoute( >> host=( >> diff --git a/src/plugins/ovirt-host-deploy/vdsm/packages.py >> b/src/plugins/ovirt-host-deploy/vdsm/packages.py >> index d819caa..b526d4b 100644 >> --- a/src/plugins/ovirt-host-deploy/vdsm/packages.py >> +++ b/src/plugins/ovirt-host-deploy/vdsm/packages.py >> @@ -68,7 +68,8 @@ class Plugin(plugin.PluginBase): >> stage=plugin.Stages.STAGE_VALIDATION, >> ) >> def _validation(self): >> - result = self.packager.queryPackages(patterns=('vdsm',)) >> + # result = self.packager.queryPackages(patterns=('vdsm',)) >> + result = ({'version': '4.10.3', 'release': '1'},) >> if not result: >> raise RuntimeError( >> _( >> @@ -106,8 +107,8 @@ class Plugin(plugin.PluginBase): >> self.services.state('vdsmd', False) >> if self.services.exists('supervdsmd'): >> self.services.state('supervdsmd', False) >> - self.packager.install(('qemu-kvm-tools',)) >> - self.packager.installUpdate(('vdsm', 'vdsm-cli')) >> + # self.packager.install(('qemu-kvm-tools',)) >> + # self.packager.installUpdate(('vdsm', 'vdsm-cli')) >> >> @plugin.event( >> stage=plugin.Stages.STAGE_CLOSEUP, >> @@ -119,7 +120,7 @@ class Plugin(plugin.PluginBase): >> self.services.state('libvirt-guests', False) >> self.services.startup('libvirt-guests', False) >> >> - self.services.startup('vdsmd', True) >> + # self.services.startup('vdsmd', True) >> if not self.services.supportsDependency: >> if self.services.exists('libvirtd'): >> self.services.startup('libvirtd', True) >> diff --git a/src/plugins/ovirt-host-deploy/vdsm/pki.py >> b/src/plugins/ovirt-host-deploy/vdsm/pki.py >> index f374a99..c013527 100644 >> --- a/src/plugins/ovirt-host-deploy/vdsm/pki.py >> +++ b/src/plugins/ovirt-host-deploy/vdsm/pki.py >> @@ -208,7 +208,8 @@ class Plugin(plugin.PluginBase): >> condition=lambda self: self._enabled, >> ) >> def _packages(self): >> - self.packager.install(('m2crypto',)) >> + # self.packager.install(('m2crypto',)) >> + pass >> >> @plugin.event( >> stage=plugin.Stages.STAGE_MISC, >> diff --git a/src/plugins/ovirt-host-deploy/vdsm/software.py >> b/src/plugins/ovirt-host-deploy/vdsm/software.py >> index 2f0ec80..a226816 100644 >> --- a/src/plugins/ovirt-host-deploy/vdsm/software.py >> +++ b/src/plugins/ovirt-host-deploy/vdsm/software.py >> @@ -65,6 +65,8 @@ class Plugin(plugin.PluginBase): >> version=ver, >> ) >> ) >> + elif dist == 'Ubuntu': >> + pass >> else: >> raise RuntimeError( >> _('Distribution {distribution} is not supported').format( >> diff --git a/src/plugins/ovirt-host-deploy/vdsm/vdsmid.py >> b/src/plugins/ovirt-host-deploy/vdsm/vdsmid.py >> index 328ad17..465212a 100644 >> --- a/src/plugins/ovirt-host-deploy/vdsm/vdsmid.py >> +++ b/src/plugins/ovirt-host-deploy/vdsm/vdsmid.py >> @@ -78,7 +78,8 @@ class Plugin(plugin.PluginBase): >> ) >> def _packages(self): >> if platform.machine() in ('x86_64', 'i686'): >> - self.packager.install(('dmidecode',)) >> + # self.packager.install(('dmidecode',)) >> + pass >> >> @plugin.event( >> stage=plugin.Stages.STAGE_CUSTOMIZATION, >> -- >> 1.7.11.7 >> >> >> Hack patch for otopi. >> >> From 3e7022b740f24d8053d3e32c20fa6d492631db80 Mon Sep 17 00:00:00 2001 >> From: Zhou Zheng Sheng >> Date: Wed, 13 Nov 2013 17:55:39 +0800 >> Subject: [PATCH] Ubuntu Hacks >> >> --- >> src/plugins/otopi/network/hostname.py | 3 ++- >> 1 file changed, 2 insertions(+), 1 deletion(-) >> >> diff --git a/src/plugins/otopi/network/hostname.py >> b/src/plugins/otopi/network/hostname.py >> index bb07627..28b4866 100644 >> --- a/src/plugins/otopi/network/hostname.py >> +++ b/src/plugins/otopi/network/hostname.py >> @@ -63,7 +63,8 @@ class Plugin(plugin.PluginBase): >> stage=plugin.Stages.STAGE_INTERNAL_PACKAGES, >> ) >> def _internal_packages(self): >> - self.packager.install(packages=['iproute']) >> + # self.packager.install(packages=['iproute']) >> + pass >> >> @plugin.event( >> stage=plugin.Stages.STAGE_VALIDATION, >> -- >> 1.7.11.7 >> >> -- >> Thanks and best regards! >> >> Zhou Zheng Sheng / ??? >> E-mail: zhshzhou at linux.vnet.ibm.com >> Telephone: 86-10-82454397 >> >> _______________________________________________ >> Engine-devel mailing list >> Engine-devel at ovirt.org >> http://lists.ovirt.org/mailman/listinfo/engine-devel >> > -- Thanks and best regards! Zhou Zheng Sheng / ??? E-mail: zhshzhou at linux.vnet.ibm.com Telephone: 86-10-82454397 From shtripat at redhat.com Fri Nov 15 03:58:06 2013 From: shtripat at redhat.com (Shubhendu Tripathi) Date: Fri, 15 Nov 2013 09:28:06 +0530 Subject: [Engine-devel] RSDL breakage in oVirt upstream In-Reply-To: <5284E486.7010502@redhat.com> References: <5284DEE8.6000501@redhat.com> <5284E486.7010502@redhat.com> Message-ID: <52859BCE.6050703@redhat.com> On 11/14/2013 08:26 PM, Michael Pasternak wrote: > Hi Shubhendu, > > On 11/14/2013 04:32 PM, Shubhendu Tripathi wrote: >> Hi Michael/Ori, >> >> There is payload breakage for RSDL in upstream oVirt. > can you elaborate a bit? [1] works for me. > > [1] http://localhost:8080/api?rsdl Hi Michael, The RSDL gets displayed but there are some issues while showing the payload details for 'glustervolumes'. Current value shown in the UI is as below - POST GlusterVolume GlusterVolume Attached the RSDl file for reference. Whereas the correct value should be as below - add a new gluster volume to the cluster POST
Content-Type application/xml|json
Expect 201-created
Correlation-Id any string
GlusterVolume add a new gluster volume to the cluster at the specified gluster fs server gluster_volume.name gluster_volume.volume_type gluster_volume.bricks.brick brick.server_id brick.brick_dir gluster_volume.transport_types transport_type gluster_volume.replica_count gluster_volume.stripe_count gluster_volume.options.option option.name option.value GlusterVolume > >> This has happened somewhere between the patches gerrit.ovirt.org/#/c/20610/ and http://gerrit.ovirt.org/#/c/15409/. >> If I try to test out with patch http://gerrit.ovirt.org/#/c/15409/, it does break. >> >> Not sure what could be the issue. Tried debugging but not able to figure it out. >> >> Kindly help me on the same figuring out what could be the issue. >> >> Thanks and Regards, >> Shubhendu >> > -------------- next part -------------- A non-text attachment was scrubbed... Name: rsdl.xml Type: text/xml Size: 137250 bytes Desc: not available URL: From sbonazzo at redhat.com Fri Nov 15 07:39:46 2013 From: sbonazzo at redhat.com (Sandro Bonazzola) Date: Fri, 15 Nov 2013 08:39:46 +0100 Subject: [Engine-devel] [QE] ovirt-engine 3.3.1-2 published in beta repository Message-ID: <5285CFC2.9000903@redhat.com> Hi, ovirt-engine 3.3.1-2 has been published in beta repository and is ready for testing. Bugs fixed in this version: {{BZ|1023739}} - Cannot create same Local SD path on different Hosts {{BZ|1009391}} - Change multi-monitor setting in VM Console option dialog for 3.2 compatible cluster {{BZ|1025313}} - support relative answer file name
{{BZ|1028748}} - answer files are world-readable and contain passwords Other fixes: Fixed a bug which caused failure to run VM with VNC console -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com From sbonazzo at redhat.com Fri Nov 15 08:26:16 2013 From: sbonazzo at redhat.com (Sandro Bonazzola) Date: Fri, 15 Nov 2013 09:26:16 +0100 Subject: [Engine-devel] [Users] [QE] ovirt-engine 3.3.1-2 published in beta repository In-Reply-To: <5285CFC2.9000903@redhat.com> References: <5285CFC2.9000903@redhat.com> Message-ID: <5285DAA8.5040204@redhat.com> Il 15/11/2013 08:39, Sandro Bonazzola ha scritto: > Hi, > ovirt-engine 3.3.1-2 has been published in beta repository and is ready for testing. > > Bugs fixed in this version: > {{BZ|1023739}} - Cannot create same Local SD path on different Hosts > {{BZ|1009391}} - Change multi-monitor setting in VM Console option dialog for 3.2 compatible cluster > {{BZ|1025313}} - support relative answer file name
> {{BZ|1028748}} - answer files are world-readable and contain passwords > > Other fixes: > Fixed a bug which caused failure to run VM with VNC console This is a list of bugs on oVirt QA that should be verified with beta repository: http://red.ht/1gQAdEo If you're going to verify one of those bugs, please set yourself as QA contact and add yourself to http://www.ovirt.org/Testing/Ovirt_3.3.1_testing Thanks, -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com From sbonazzo at redhat.com Fri Nov 15 10:09:10 2013 From: sbonazzo at redhat.com (Sandro Bonazzola) Date: Fri, 15 Nov 2013 11:09:10 +0100 Subject: [Engine-devel] [Users] [QE] ovirt-engine 3.3.1-2 published in beta repository In-Reply-To: <5285DAA8.5040204@redhat.com> References: <5285CFC2.9000903@redhat.com> <5285DAA8.5040204@redhat.com> Message-ID: <5285F2C6.8030606@redhat.com> Il 15/11/2013 09:26, Sandro Bonazzola ha scritto: > Il 15/11/2013 08:39, Sandro Bonazzola ha scritto: >> Hi, >> ovirt-engine 3.3.1-2 has been published in beta repository and is ready for testing. >> >> Bugs fixed in this version: >> {{BZ|1023739}} - Cannot create same Local SD path on different Hosts >> {{BZ|1009391}} - Change multi-monitor setting in VM Console option dialog for 3.2 compatible cluster >> {{BZ|1025313}} - support relative answer file name
>> {{BZ|1028748}} - answer files are world-readable and contain passwords >> >> Other fixes: >> Fixed a bug which caused failure to run VM with VNC console > > This is a list of bugs on oVirt QA that should be verified with beta repository: http://red.ht/1gQAdEo > If you're going to verify one of those bugs, please set yourself as QA contact > and add yourself to http://www.ovirt.org/Testing/Ovirt_3.3.1_testing > Thanks, ovirt-engine 3.3.1-2 will stay in beta repository for a few days. If no blockers will be found, we're planning to release to GA next week on Tuesday. -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com From shtripat at redhat.com Fri Nov 15 16:14:29 2013 From: shtripat at redhat.com (Shubhendu Tripathi) Date: Fri, 15 Nov 2013 21:44:29 +0530 Subject: [Engine-devel] RSDL breakage in oVirt upstream In-Reply-To: <52859BCE.6050703@redhat.com> References: <5284DEE8.6000501@redhat.com> <5284E486.7010502@redhat.com> <52859BCE.6050703@redhat.com> Message-ID: <52864865.2010009@redhat.com> On 11/15/2013 09:28 AM, Shubhendu Tripathi wrote: > On 11/14/2013 08:26 PM, Michael Pasternak wrote: >> Hi Shubhendu, >> >> On 11/14/2013 04:32 PM, Shubhendu Tripathi wrote: >>> Hi Michael/Ori, >>> >>> There is payload breakage for RSDL in upstream oVirt. >> can you elaborate a bit? [1] works for me. >> >> [1] http://localhost:8080/api?rsdl I have raised the patch http://gerrit.ovirt.org/#/c/21308/ resolving the same issue. Kindly have a look and do the needful. > Hi Michael, > > The RSDL gets displayed but there are some issues while showing the > payload details for 'glustervolumes'. > Current value shown in the UI is as below - > > rel="add"> > > POST > > GlusterVolume > > > > GlusterVolume > > > > Attached the RSDl file for reference. > > Whereas the correct value should be as below - > > > add a new gluster volume to the cluster > > POST > >
> Content-Type > application/xml|json >
>
> Expect > 201-created >
>
> Correlation-Id > any string >
> > > GlusterVolume > > > add a new gluster volume to the cluster at the specified gluster fs > server > > > gluster_volume.name > > > gluster_volume.volume_type > > > gluster_volume.bricks.brick > > > brick.server_id > > > brick.brick_dir > > > > > gluster_volume.transport_types > > > transport_type > > > > > gluster_volume.replica_count > > > gluster_volume.stripe_count > > > gluster_volume.options.option > > > option.name > > > option.value > > > > > > > > GlusterVolume > > > > >> >>> This has happened somewhere between the patches >>> gerrit.ovirt.org/#/c/20610/ and http://gerrit.ovirt.org/#/c/15409/. >>> If I try to test out with patch http://gerrit.ovirt.org/#/c/15409/, >>> it does break. >>> >>> Not sure what could be the issue. Tried debugging but not able to >>> figure it out. >>> >>> Kindly help me on the same figuring out what could be the issue. >>> >>> Thanks and Regards, >>> Shubhendu >>> >> > From mrao at redhat.com Fri Nov 15 18:35:57 2013 From: mrao at redhat.com (Malini Rao) Date: Fri, 15 Nov 2013 13:35:57 -0500 (EST) Subject: [Engine-devel] [UX] how to design a bar/line chart? In-Reply-To: <356685769.5458199.1384463454334.JavaMail.root@redhat.com> References: <157528892.18409921.1383645002815.JavaMail.root@redhat.com> <1596552383.20866728.1383747975841.JavaMail.root@redhat.com> <424101873.19454345.1383749883282.JavaMail.root@redhat.com> <1306019229.17661019.1383751496579.JavaMail.root@redhat.com> <858746798.4081108.1384384154972.JavaMail.root@redhat.com> <5D98AD7F-83C0-48D5-9252-5CD0B220B775@redhat.com> <750008068.23476473.1384460268160.JavaMail.root@redhat.com> <356685769.5458199.1384463454334.JavaMail.root@redhat.com> Message-ID: <2017675394.24155723.1384540556930.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Einav Cohen" > To: "Malini Rao" , "Michal Skrivanek" > Cc: "Eldan Hildesheim" , "engine-devel" , "info" > Sent: Thursday, November 14, 2013 4:10:54 PM > Subject: Re: [Engine-devel] [UX] how to design a bar/line chart? > > > > ...maybe just a global setting to disable this if it gets annoying? It's > > > a > > > small feature and it's trivial to add such a setting. > > > > @Michal: I am not sure what you mean by "disable"; if you mean "hide (the > columns)", > then I think that we should rely on the global "show/hide columns" feature, > and > not create a dedicated configuration value for these particular columns. > Moreover, > the global "show/hide columns" feature will allow customization per > user/client, > rather than a global-configuration-level customization, so each user will be > able > to define his view as he wishes. > > > I am averse to turning it off completely since it will be less than what > > they > > have today but may be if they are displaying a trend, they should be able > > to > > choose to only see the current value... > > @Malini, do you mean that they need the option to "fallback" to the current > "bar" > design (which reflects only the current value)? or something else? My preference is to choose a suitable visualization and not have any other view options. I think the ability to add or remove that column is sufficient should a user not find value in these columns. I merely suggested the fall back option instead of having a setting to turn these columns off altogether permanently. > > > ... If we have colored dots, we should possibly change the shape of the > > marker > > too for each color so that color blind people can still find value on this > > as > > a status indicator. > > I like the idea of colored dots; not sure about the different shapes though, > as > the dots would be pretty tiny; in the color-blind case: wouldn't it be > sufficient > to rely on the dot "height" + the textual value? I am not sure it is enough - Height and text are available for all users including those that are not colorblind and the color of the dot is an additional data point that they will miss out on if we didn't do the shape. I think even at this size, it will be easy to distinguish a circle from a triangle and a square. Having more than that may be tricky.( See attached) Also, I am glad you are always presenting current and proposed together as it allows for effective comparison. I think it is safe to say that it is easier to discern the VMs that need attention in the current view than in the proposed view because there is more color there than in a small dot. As an experiment, I tried to render the entire sparkline in the color of the current value ( See attached) - It is more effective in the scannability aspect but it is painting all values in the color of the current value which is not technically accurate. What do you guys think? > > > > Thanks for the mock up, I think it looks great. Perhaps I'd consider > > > lines > > > instead of dots (to see the base 0, currently the line is somehow "in the > > > air" and since the height is limited it may be difficult to distinguissh > > > 20% > > > from 0%), provided they are in some light color it may look ok > > > > I am not sure I completely understand the request here. Is there a need to > > clearly mark the zero/baseline here? Or need multiple dots to highlight > > various values on the line? Or are we needing a band like this > > (https://www.broadbandmetrics.com/download/attachments/3768372/TufteSparklne_medical.jpg?version=1&modificationDate=1362506139000) > > to mark the desirable range? One thing I want to make sure we are on the > > same page is that the sparkline is definitely not a good widget to > > distinguish small or accurate changes but more the current position in > > relation to the overall shape. > > I think that we are all on the same page here (others - please correct me if > I am wrong) that only the general trend is of interest here, and not the > exact > values (maybe with the exception of the "last" value in each trendline). > I believe that Michal was referring to axes [in particular the horizontal > ('x') > axis, I assume] so indeed we will have a clearer baseline for the trend. > theoretically we can also have a "band", as you suggested, just need to well- > define the "range" of the band so it would makes sense (not sure if easy to > do). > > I am attaching an updated mock-up with axes (only added for the first > few lines) as well as colored dots, as you (Malini) suggested above. I am not sure how much value the axes provide as it is still pretty hard to tell the difference from 0 to 20. As long as there are no negative values, do we really need the axes? If we do, Einav's mockup is pretty good in terms of representing the axes since it is not looking cluttered. > > ---- > Thanks, > Einav > > ----- Original Message ----- > > From: "Malini Rao" > > To: "Michal Skrivanek" > > Cc: "Eldan Hildesheim" , "engine-devel" > > , "info" > > Sent: Thursday, November 14, 2013 3:17:48 PM > > Subject: Re: [Engine-devel] [UX] how to design a bar/line chart? > > > > ----- Original Message ----- > > > From: "Michal Skrivanek" > > > To: "Einav Cohen" > > > Cc: "Malini Rao" , "Tomas Jelinek" > > > , > > > "Eldan Hildesheim" , > > > "info" , "engine-devel" > > > Sent: Thursday, November 14, 2013 2:21:03 AM > > > Subject: Re: [Engine-devel] [UX] how to design a bar/line chart? > > > > > > > > > On Nov 14, 2013, at 00:09 , Einav Cohen wrote: > > > > > > >> ... but we may have to see how this looks when multiple sparklines > > > >> reside in columns next to each other. > > > >> ... > > > >> ... > > > >> Is this going to fit in a row of a table? Or are we talking of a > > > >> more detailed view? > > > >> ... > > > > > > > > a concern on which I happened to briefly discuss with Eldan / Malini > > > > and actually somewhat raised here earlier in the thread (see above): > > > > Since we are adding another information "dimension" (time), we are > > > > actually going to display a lot more information to the user within the > > > > CPU/MEM/NET columns, and there is a chance that the view will become > > > > too overloaded/confusing, and we will end up with a view that is less > > > > clear than the current one. > > > > > > Well, for that we IMHO have much bigger issue already with the fact we do > > > not > > > hide/show columns, and many of them do not really provide much value in > > > all > > > use cases. If you look at the mockup and the screenshots from users I've > > > seen - e.g. the Display column(don't care), the Cluster (not wide > > > enough, > > > repetition of the same info on each line), Host(repetition of domain > > > parts > > > of FQDN) makes it overloaded already. > > > > Agreed and I think we should address that and some efforts in terms of > > designs are underway for some of these issues. However, I think Einav's > > point was about increasing the amount of info in each of those 3 columns > > exponentially since it is a trend and not a single value. Having said that, > > I think the trend represented as a sparkline/ trendline is not meant to > > give > > you that many more datapoints - It gives you the current value and an idea > > of the trend based on the 'shape' of the trend line and not the individual > > peaks and troughs. So I think it is not that much of a leap in terms of the > > cognitive overload. > > > > > Since statistics do provide some value and it keeps changing based on > > > load > > > it > > > IMHO looks ok > > > > I think the question in my mind here is if the trendline is indeed a better > > visualization for all these three attributes? In other words, is a trend > > for > > the memory as valuable as a trend for network or CPU? Or is it more useful > > for the user to see the current visualization for memory that fills the bar > > as it gets closer to 100% and turns red? The point I am trying to make is > > that the trendline/ sparkline is not necessarily a widget with cognitive > > overload but it is still worth considering if it is the right data > > visualization for the attribute. So is it possible that only one or more of > > these attributes is a sparkline? > > > > > > > ...maybe just a global setting to disable this if it gets annoying? It's > > > a > > > small feature and it's trivial to add such a setting. > > > > I am averse to turning it off completely since it will be less than what > > they > > have today but may be if they are displaying a trend, they should be able > > to > > choose to only see the current value... > > > > > > > > > > > > > Just so we will have a general idea of how it will look like > > > > eventually, > > > > so we will be able to do a slightly more educated decision, I am > > > > attaching > > > > a mock-up of how it looks now compared to how it may look once this > > > > feature is implemented. > > > > Einav, the mockup looks awesome.. you beat me to it! :) Also, after looking > > at the mockup, I am less worried about the 3 sparkline columns displaying > > next to each other especially because the current value breaks the lines > > from all merging together. > > > > > > > > > > > > * In my mock-up, I followed Malini's guideline from earlier in the > > > > thread: > > > > """ > > > > One color with a dot to indicate the most recent or most relevant data > > > > and display its value next to the sparkline > > > > """ > > > > I think Sparklines lend themselves less to status/ threshold indicators > > that > > rely on color. One example that I found potentially acceptable is > > http://chandoo.org/img/2010/introduction-to-excel-sparklines.png. In our > > case, the current value dot can be red, green or any other color based on > > the ranges defined and the colors associated with it. If we have colored > > dots, we should possibly change the shape of the marker too for each color > > so that color blind people can still find value on this as a status > > indicator. > > > > > > > Thanks for the mock up, I think it looks great. Perhaps I'd consider > > > lines > > > instead of dots (to see the base 0, currently the line is somehow "in the > > > air" and since the height is limited it may be difficult to distinguissh > > > 20% > > > from 0%), provided they are in some light color it may look ok > > > > I am not sure I completely understand the request here. Is there a need to > > clearly mark the zero/baseline here? Or need multiple dots to highlight > > various values on the line? Or are we needing a band like this > > (https://www.broadbandmetrics.com/download/attachments/3768372/TufteSparklne_medical.jpg?version=1&modificationDate=1362506139000) > > to mark the desirable range? One thing I want to make sure we are on the > > same page is that the sparkline is definitely not a good widget to > > distinguish small or accurate changes but more the current position in > > relation to the overall shape. > > > > > > > > > > > > > > > * keep in mind that the view is dynamic and keeps updating once it > > > > receives new statistics from the backend. > > > > > > > > Thoughts? > > > > > > > > > > > > ----- Original Message ----- > > > >> From: "Malini Rao" > > > >> To: "Tomas Jelinek" > > > >> Cc: "Einav Cohen" , "engine-devel" > > > >> , "Eldan Hildesheim" > > > >> , "info" , "Martin Polednik" > > > >> > > > >> 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 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? 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 at 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 at ovirt.org > > > >>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel > > > >>>>> > > > >>>>> > > > >>>>> > > > >>>> > > > >>> > > > > > > > > > > > > _______________________________________________ > > Engine-devel mailing list > > Engine-devel at ovirt.org > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > > > > -------------- next part -------------- A non-text attachment was scrubbed... Name: Colored sparklines.fw.png Type: image/png Size: 1289740 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: shaped markers.fw.png Type: image/png Size: 1285707 bytes Desc: not available URL: From alonbl at redhat.com Fri Nov 15 18:52:46 2013 From: alonbl at redhat.com (Alon Bar-Lev) Date: Fri, 15 Nov 2013 13:52:46 -0500 (EST) Subject: [Engine-devel] Things to be done to support Ubuntu hosts In-Reply-To: <5284744F.6010404@linux.vnet.ibm.com> References: <5284744F.6010404@linux.vnet.ibm.com> Message-ID: <2084307917.16057658.1384541566676.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Zhou Zheng Sheng" > To: "engine-devel" > Cc: "Itamar Heim" , "Alon Bar-Lev" > Sent: Thursday, November 14, 2013 8:57:19 AM > Subject: Things to be done to support Ubuntu hosts > > Hi, > > Recently Ubuntu support is added to VDSM, and .deb binray packages can > be downloaded from launchpad.net PPA [1]. Most of the key features such > as storage management and VM lifecycle work on Ubuntu. The cross > distribution network management patches are upstream as well. One big > piece left is making ovirt-host-deploy support Ubuntu, so that we can > manage Ubuntu hosts from Engine, thus close the gap on host side. > > In May 2013 I made some hacks to ovirt-host-deploy and otopi. I made it > skipped parts not supported on Ubuntu and configure the environment > manually, and successfully added Ubuntu host to Engine [2]. > Unfortunately I have no plans to continue on it, but I'd like to make a > summary of the things I hacked to help anyone who wants to submit > patches in future. I was to add a WIKI page but I found there were not > many items, so a mail would be enough. > > 1. Package management operations > Both otopi and ovirt-host-deploy query for dependency packages and > install them on demand. The otopi package management just supports yum, > we need to add apt-get support. Package names are different in Ubuntu, > so I made a list mapping the names. The list in in VDSM source > directory, debian/dependencyMap.txt . Please try putting the following file on host: /etc/ovirt-host-deploy.conf.d/10-ubuntu.conf --- ODEPLOY/offlinePackager=bool:True --- This will replace the disable section of packaging in your patch. It will make host-deploy not to install any package and assume all is pre-installed. > > 2. Network configuration operations > ovirt-host-deploy asks VDSM's configNetwork.py to create bridge network. > Cross distribution support patches for configNetwork.py are under > review. ovirt-host-deploy supports Ubuntu bridge configuration as long > as they are merged. This is not happening any more at 3.3, so no need to change anything. I think that in 3.3 with the above offline packaging use, you can use vanilla otopi/host-deploy. Regards, Alon Bar-Lev > > [1] https://launchpad.net/~zhshzhou/+archive/vdsm-ubuntu > [2] http://www.ovirt.org/images/5/57/Shanghai-VDSM-on-Ubuntu.pdf > > Here goes the detailed hack patch. The hack was base on v1.0.1, I > rebased it to the latest master. The rebased patch are not tested. If > you find this email useless, it's actually a good news, which means > there is not a lot of work and problems ahead ;-) > > Hack patch for ovirt-host-deploy. > > From 120493a242046d19794ef3da83b32486d372aa39 Mon Sep 17 00:00:00 2001 > From: Zhou Zheng Sheng > Date: Wed, 13 Nov 2013 18:02:26 +0800 > Subject: [PATCH] Ubuntu Hacks > > Change-Id: Ifb4ebc829101c92d06475619b1b5986e87b83d57 > Signed-off-by: Zhou Zheng Sheng > --- > src/plugins/ovirt-host-deploy/gluster/packages.py | 17 +++++---- > src/plugins/ovirt-host-deploy/tune/tuned.py | 3 +- > src/plugins/ovirt-host-deploy/vdsm/bridge.py | 45 > ++++++++++++----------- > src/plugins/ovirt-host-deploy/vdsm/packages.py | 9 +++-- > src/plugins/ovirt-host-deploy/vdsm/pki.py | 3 +- > src/plugins/ovirt-host-deploy/vdsm/software.py | 2 + > src/plugins/ovirt-host-deploy/vdsm/vdsmid.py | 3 +- > 7 files changed, 45 insertions(+), 37 deletions(-) > > diff --git a/src/plugins/ovirt-host-deploy/gluster/packages.py > b/src/plugins/ovirt-host-deploy/gluster/packages.py > index 1fecfda..eb37744 100644 > --- a/src/plugins/ovirt-host-deploy/gluster/packages.py > +++ b/src/plugins/ovirt-host-deploy/gluster/packages.py > @@ -60,13 +60,13 @@ class Plugin(plugin.PluginBase): > ), > ) > def _validation(self): > - if not self.packager.queryPackages(patterns=('vdsm-gluster',)): > - raise RuntimeError( > - _( > - 'Cannot locate gluster packages, ' > - 'possible cause is incorrect channels' > - ) > - ) > + # if not self.packager.queryPackages(patterns=('vdsm-gluster',)): > + # raise RuntimeError( > + # _( > + # 'Cannot locate gluster packages, ' > + # 'possible cause is incorrect channels' > + # ) > + # ) > self._enabled = True > > @plugin.event( > @@ -74,7 +74,8 @@ class Plugin(plugin.PluginBase): > condition=lambda self: self._enabled, > ) > def _packages(self): > - self.packager.installUpdate(('vdsm-gluster',)) > + # self.packager.installUpdate(('vdsm-gluster',)) > + pass > > @plugin.event( > stage=plugin.Stages.STAGE_CLOSEUP, > diff --git a/src/plugins/ovirt-host-deploy/tune/tuned.py > b/src/plugins/ovirt-host-deploy/tune/tuned.py > index d8e00c5..d0dcea5 100644 > --- a/src/plugins/ovirt-host-deploy/tune/tuned.py > +++ b/src/plugins/ovirt-host-deploy/tune/tuned.py > @@ -70,7 +70,8 @@ class Plugin(plugin.PluginBase): > condition=lambda self: self._enabled, > ) > def _packages(self): > - self.packager.installUpdate(('tuned',)) > + # self.packager.installUpdate(('tuned',)) > + pass > > @plugin.event( > stage=plugin.Stages.STAGE_MISC, > diff --git a/src/plugins/ovirt-host-deploy/vdsm/bridge.py > b/src/plugins/ovirt-host-deploy/vdsm/bridge.py > index 3789d62..64cce40 100644 > --- a/src/plugins/ovirt-host-deploy/vdsm/bridge.py > +++ b/src/plugins/ovirt-host-deploy/vdsm/bridge.py > @@ -595,7 +595,8 @@ class Plugin(plugin.PluginBase): > stage=plugin.Stages.STAGE_INTERNAL_PACKAGES, > ) > def _internal_packages(self): > - self.packager.install(packages=('iproute',)) > + # self.packager.install(packages=('iproute',)) > + pass > > @plugin.event( > stage=plugin.Stages.STAGE_VALIDATION, > @@ -771,27 +772,27 @@ class Plugin(plugin.PluginBase): > interface = self._getInterfaceToInstallBasedOnDestination( > address=self.environment[odeploycons.VdsmEnv.ENGINE_ADDRESS] > ) > - parameters = > self._rhel_getInterfaceConfigParameters(name=interface) > - > - # The followin can be executed > - # only at node as we won't reach here > - # if we are not running on node > - if ( > - self.environment[odeploycons.VdsmEnv.OVIRT_NODE] and > - self._interfaceIsBridge(name=interface) > - ): > - nic = interface.replace('br', '', 1) > - self._removeBridge( > - name=interface, > - interface=nic, > - ) > - interface = nic > - > - self._createBridge( > - > name=self.environment[odeploycons.VdsmEnv.MANAGEMENT_BRIDGE_NAME], > - interface=interface, > - parameters=parameters, > - ) > + # parameters = > self._rhel_getInterfaceConfigParameters(name=interface) > + > + # # The followin can be executed > + # # only at node as we won't reach here > + # # if we are not running on node > + # if ( > + # self.environment[odeploycons.VdsmEnv.OVIRT_NODE] and > + # self._interfaceIsBridge(name=interface) > + # ): > + # nic = interface.replace('br', '', 1) > + # self._removeBridge( > + # name=interface, > + # interface=nic, > + # ) > + # interface = nic > + > + # self._createBridge( > + # > name=self.environment[odeploycons.VdsmEnv.MANAGEMENT_BRIDGE_NAME], > + # interface=interface, > + # parameters=parameters, > + # ) > > self._waitForRoute( > host=( > diff --git a/src/plugins/ovirt-host-deploy/vdsm/packages.py > b/src/plugins/ovirt-host-deploy/vdsm/packages.py > index d819caa..b526d4b 100644 > --- a/src/plugins/ovirt-host-deploy/vdsm/packages.py > +++ b/src/plugins/ovirt-host-deploy/vdsm/packages.py > @@ -68,7 +68,8 @@ class Plugin(plugin.PluginBase): > stage=plugin.Stages.STAGE_VALIDATION, > ) > def _validation(self): > - result = self.packager.queryPackages(patterns=('vdsm',)) > + # result = self.packager.queryPackages(patterns=('vdsm',)) > + result = ({'version': '4.10.3', 'release': '1'},) > if not result: > raise RuntimeError( > _( > @@ -106,8 +107,8 @@ class Plugin(plugin.PluginBase): > self.services.state('vdsmd', False) > if self.services.exists('supervdsmd'): > self.services.state('supervdsmd', False) > - self.packager.install(('qemu-kvm-tools',)) > - self.packager.installUpdate(('vdsm', 'vdsm-cli')) > + # self.packager.install(('qemu-kvm-tools',)) > + # self.packager.installUpdate(('vdsm', 'vdsm-cli')) > > @plugin.event( > stage=plugin.Stages.STAGE_CLOSEUP, > @@ -119,7 +120,7 @@ class Plugin(plugin.PluginBase): > self.services.state('libvirt-guests', False) > self.services.startup('libvirt-guests', False) > > - self.services.startup('vdsmd', True) > + # self.services.startup('vdsmd', True) > if not self.services.supportsDependency: > if self.services.exists('libvirtd'): > self.services.startup('libvirtd', True) > diff --git a/src/plugins/ovirt-host-deploy/vdsm/pki.py > b/src/plugins/ovirt-host-deploy/vdsm/pki.py > index f374a99..c013527 100644 > --- a/src/plugins/ovirt-host-deploy/vdsm/pki.py > +++ b/src/plugins/ovirt-host-deploy/vdsm/pki.py > @@ -208,7 +208,8 @@ class Plugin(plugin.PluginBase): > condition=lambda self: self._enabled, > ) > def _packages(self): > - self.packager.install(('m2crypto',)) > + # self.packager.install(('m2crypto',)) > + pass > > @plugin.event( > stage=plugin.Stages.STAGE_MISC, > diff --git a/src/plugins/ovirt-host-deploy/vdsm/software.py > b/src/plugins/ovirt-host-deploy/vdsm/software.py > index 2f0ec80..a226816 100644 > --- a/src/plugins/ovirt-host-deploy/vdsm/software.py > +++ b/src/plugins/ovirt-host-deploy/vdsm/software.py > @@ -65,6 +65,8 @@ class Plugin(plugin.PluginBase): > version=ver, > ) > ) > + elif dist == 'Ubuntu': > + pass > else: > raise RuntimeError( > _('Distribution {distribution} is not supported').format( > diff --git a/src/plugins/ovirt-host-deploy/vdsm/vdsmid.py > b/src/plugins/ovirt-host-deploy/vdsm/vdsmid.py > index 328ad17..465212a 100644 > --- a/src/plugins/ovirt-host-deploy/vdsm/vdsmid.py > +++ b/src/plugins/ovirt-host-deploy/vdsm/vdsmid.py > @@ -78,7 +78,8 @@ class Plugin(plugin.PluginBase): > ) > def _packages(self): > if platform.machine() in ('x86_64', 'i686'): > - self.packager.install(('dmidecode',)) > + # self.packager.install(('dmidecode',)) > + pass > > @plugin.event( > stage=plugin.Stages.STAGE_CUSTOMIZATION, > -- > 1.7.11.7 > > > Hack patch for otopi. > > From 3e7022b740f24d8053d3e32c20fa6d492631db80 Mon Sep 17 00:00:00 2001 > From: Zhou Zheng Sheng > Date: Wed, 13 Nov 2013 17:55:39 +0800 > Subject: [PATCH] Ubuntu Hacks > > --- > src/plugins/otopi/network/hostname.py | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/src/plugins/otopi/network/hostname.py > b/src/plugins/otopi/network/hostname.py > index bb07627..28b4866 100644 > --- a/src/plugins/otopi/network/hostname.py > +++ b/src/plugins/otopi/network/hostname.py > @@ -63,7 +63,8 @@ class Plugin(plugin.PluginBase): > stage=plugin.Stages.STAGE_INTERNAL_PACKAGES, > ) > def _internal_packages(self): > - self.packager.install(packages=['iproute']) > + # self.packager.install(packages=['iproute']) > + pass > > @plugin.event( > stage=plugin.Stages.STAGE_VALIDATION, > -- > 1.7.11.7 > > -- > Thanks and best regards! > > Zhou Zheng Sheng / ??? > E-mail: zhshzhou at linux.vnet.ibm.com > Telephone: 86-10-82454397 > > From ecohen at redhat.com Fri Nov 15 19:32:21 2013 From: ecohen at redhat.com (Einav Cohen) Date: Fri, 15 Nov 2013 14:32:21 -0500 (EST) Subject: [Engine-devel] [UX] how to design a bar/line chart? In-Reply-To: <2017675394.24155723.1384540556930.JavaMail.root@redhat.com> References: <157528892.18409921.1383645002815.JavaMail.root@redhat.com> <424101873.19454345.1383749883282.JavaMail.root@redhat.com> <1306019229.17661019.1383751496579.JavaMail.root@redhat.com> <858746798.4081108.1384384154972.JavaMail.root@redhat.com> <5D98AD7F-83C0-48D5-9252-5CD0B220B775@redhat.com> <750008068.23476473.1384460268160.JavaMail.root@redhat.com> <356685769.5458199.1384463454334.JavaMail.root@redhat.com> <2017675394.24155723.1384540556930.JavaMail.root@redhat.com> Message-ID: <1547048567.6416859.1384543941781.JavaMail.root@redhat.com> > Also, I am glad you are always presenting current and proposed together as it > allows for effective comparison. I think it is safe to say that it is easier > to discern the VMs that need attention in the current view than in the > proposed view because there is more color there than in a small dot. +1 > As an experiment, I tried to render the entire sparkline in the color of the > current value ( See attached) - It is more effective in the scannability > aspect but it is painting all values in the color of the current value which > is not technically accurate. What do you guys think? Malini, I agree with the above: it is more effective in the scannablity aspect, but misleading due to the entire trend being represented by a color that actually represents only the last reading. For better scannability without the misleading aspect, I was thinking about coloring the text next to the dot in the same color. we can also think about marking in bold this text when it is orange and/or red, for even better scannability (that will be helpful also for color-blind users). see attached "shaped-markers--colored-numbers.png" for demonstration (in this mock-up, I marked bold only the red text). thoughts? ---- Thanks, Einav ----- Original Message ----- > From: "Malini Rao" > To: "Einav Cohen" > Cc: "Eldan Hildesheim" , "engine-devel" , "info" , > "Michal Skrivanek" > Sent: Friday, November 15, 2013 1:35:57 PM > Subject: Re: [Engine-devel] [UX] how to design a bar/line chart? > > ----- Original Message ----- > > From: "Einav Cohen" > > To: "Malini Rao" , "Michal Skrivanek" > > > > Cc: "Eldan Hildesheim" , "engine-devel" > > , "info" > > Sent: Thursday, November 14, 2013 4:10:54 PM > > Subject: Re: [Engine-devel] [UX] how to design a bar/line chart? > > > > > > ...maybe just a global setting to disable this if it gets annoying? > > > > It's > > > > a > > > > small feature and it's trivial to add such a setting. > > > > > > > @Michal: I am not sure what you mean by "disable"; if you mean "hide (the > > columns)", > > then I think that we should rely on the global "show/hide columns" feature, > > and > > not create a dedicated configuration value for these particular columns. > > Moreover, > > the global "show/hide columns" feature will allow customization per > > user/client, > > rather than a global-configuration-level customization, so each user will > > be > > able > > to define his view as he wishes. > > > > > I am averse to turning it off completely since it will be less than what > > > they > > > have today but may be if they are displaying a trend, they should be able > > > to > > > choose to only see the current value... > > > > @Malini, do you mean that they need the option to "fallback" to the current > > "bar" > > design (which reflects only the current value)? or something else? > > My preference is to choose a suitable visualization and not have any other > view options. I think the ability to add or remove that column is sufficient > should a user not find value in these columns. I merely suggested the fall > back option instead of having a setting to turn these columns off altogether > permanently. > > > > > > > ... If we have colored dots, we should possibly change the shape of the > > > marker > > > too for each color so that color blind people can still find value on > > > this > > > as > > > a status indicator. > > > > I like the idea of colored dots; not sure about the different shapes > > though, > > as > > the dots would be pretty tiny; in the color-blind case: wouldn't it be > > sufficient > > to rely on the dot "height" + the textual value? > > I am not sure it is enough - Height and text are available for all users > including those that are not colorblind and the color of the dot is an > additional data point that they will miss out on if we didn't do the shape. > I think even at this size, it will be easy to distinguish a circle from a > triangle and a square. Having more than that may be tricky.( See attached) > > Also, I am glad you are always presenting current and proposed together as it > allows for effective comparison. I think it is safe to say that it is easier > to discern the VMs that need attention in the current view than in the > proposed view because there is more color there than in a small dot. As an > experiment, I tried to render the entire sparkline in the color of the > current value ( See attached) - It is more effective in the scannability > aspect but it is painting all values in the color of the current value which > is not technically accurate. What do you guys think? > > > > > > > Thanks for the mock up, I think it looks great. Perhaps I'd consider > > > > lines > > > > instead of dots (to see the base 0, currently the line is somehow "in > > > > the > > > > air" and since the height is limited it may be difficult to > > > > distinguissh > > > > 20% > > > > from 0%), provided they are in some light color it may look ok > > > > > > I am not sure I completely understand the request here. Is there a need > > > to > > > clearly mark the zero/baseline here? Or need multiple dots to highlight > > > various values on the line? Or are we needing a band like this > > > (https://www.broadbandmetrics.com/download/attachments/3768372/TufteSparklne_medical.jpg?version=1&modificationDate=1362506139000) > > > to mark the desirable range? One thing I want to make sure we are on the > > > same page is that the sparkline is definitely not a good widget to > > > distinguish small or accurate changes but more the current position in > > > relation to the overall shape. > > > > I think that we are all on the same page here (others - please correct me > > if > > I am wrong) that only the general trend is of interest here, and not the > > exact > > values (maybe with the exception of the "last" value in each trendline). > > I believe that Michal was referring to axes [in particular the horizontal > > ('x') > > axis, I assume] so indeed we will have a clearer baseline for the trend. > > theoretically we can also have a "band", as you suggested, just need to > > well- > > define the "range" of the band so it would makes sense (not sure if easy to > > do). > > > > I am attaching an updated mock-up with axes (only added for the first > > few lines) as well as colored dots, as you (Malini) suggested above. > > I am not sure how much value the axes provide as it is still pretty hard to > tell the difference from 0 to 20. As long as there are no negative values, > do we really need the axes? If we do, Einav's mockup is pretty good in terms > of representing the axes since it is not looking cluttered. > > > > > ---- > > Thanks, > > Einav > > > > ----- Original Message ----- > > > From: "Malini Rao" > > > To: "Michal Skrivanek" > > > Cc: "Eldan Hildesheim" , "engine-devel" > > > , "info" > > > Sent: Thursday, November 14, 2013 3:17:48 PM > > > Subject: Re: [Engine-devel] [UX] how to design a bar/line chart? > > > > > > ----- Original Message ----- > > > > From: "Michal Skrivanek" > > > > To: "Einav Cohen" > > > > Cc: "Malini Rao" , "Tomas Jelinek" > > > > , > > > > "Eldan Hildesheim" , > > > > "info" , "engine-devel" > > > > Sent: Thursday, November 14, 2013 2:21:03 AM > > > > Subject: Re: [Engine-devel] [UX] how to design a bar/line chart? > > > > > > > > > > > > On Nov 14, 2013, at 00:09 , Einav Cohen wrote: > > > > > > > > >> ... but we may have to see how this looks when multiple sparklines > > > > >> reside in columns next to each other. > > > > >> ... > > > > >> ... > > > > >> Is this going to fit in a row of a table? Or are we talking of a > > > > >> more detailed view? > > > > >> ... > > > > > > > > > > a concern on which I happened to briefly discuss with Eldan / Malini > > > > > and actually somewhat raised here earlier in the thread (see above): > > > > > Since we are adding another information "dimension" (time), we are > > > > > actually going to display a lot more information to the user within > > > > > the > > > > > CPU/MEM/NET columns, and there is a chance that the view will become > > > > > too overloaded/confusing, and we will end up with a view that is less > > > > > clear than the current one. > > > > > > > > Well, for that we IMHO have much bigger issue already with the fact we > > > > do > > > > not > > > > hide/show columns, and many of them do not really provide much value in > > > > all > > > > use cases. If you look at the mockup and the screenshots from users > > > > I've > > > > seen - e.g. the Display column(don't care), the Cluster (not wide > > > > enough, > > > > repetition of the same info on each line), Host(repetition of domain > > > > parts > > > > of FQDN) makes it overloaded already. > > > > > > Agreed and I think we should address that and some efforts in terms of > > > designs are underway for some of these issues. However, I think Einav's > > > point was about increasing the amount of info in each of those 3 columns > > > exponentially since it is a trend and not a single value. Having said > > > that, > > > I think the trend represented as a sparkline/ trendline is not meant to > > > give > > > you that many more datapoints - It gives you the current value and an > > > idea > > > of the trend based on the 'shape' of the trend line and not the > > > individual > > > peaks and troughs. So I think it is not that much of a leap in terms of > > > the > > > cognitive overload. > > > > > > > Since statistics do provide some value and it keeps changing based on > > > > load > > > > it > > > > IMHO looks ok > > > > > > I think the question in my mind here is if the trendline is indeed a > > > better > > > visualization for all these three attributes? In other words, is a trend > > > for > > > the memory as valuable as a trend for network or CPU? Or is it more > > > useful > > > for the user to see the current visualization for memory that fills the > > > bar > > > as it gets closer to 100% and turns red? The point I am trying to make is > > > that the trendline/ sparkline is not necessarily a widget with cognitive > > > overload but it is still worth considering if it is the right data > > > visualization for the attribute. So is it possible that only one or more > > > of > > > these attributes is a sparkline? > > > > > > > > > > ...maybe just a global setting to disable this if it gets annoying? > > > > It's > > > > a > > > > small feature and it's trivial to add such a setting. > > > > > > I am averse to turning it off completely since it will be less than what > > > they > > > have today but may be if they are displaying a trend, they should be able > > > to > > > choose to only see the current value... > > > > > > > > > > > > > > > > > Just so we will have a general idea of how it will look like > > > > > eventually, > > > > > so we will be able to do a slightly more educated decision, I am > > > > > attaching > > > > > a mock-up of how it looks now compared to how it may look once this > > > > > feature is implemented. > > > > > > Einav, the mockup looks awesome.. you beat me to it! :) Also, after > > > looking > > > at the mockup, I am less worried about the 3 sparkline columns displaying > > > next to each other especially because the current value breaks the lines > > > from all merging together. > > > > > > > > > > > > > > > > * In my mock-up, I followed Malini's guideline from earlier in the > > > > > thread: > > > > > """ > > > > > One color with a dot to indicate the most recent or most relevant > > > > > data > > > > > and display its value next to the sparkline > > > > > """ > > > > > > I think Sparklines lend themselves less to status/ threshold indicators > > > that > > > rely on color. One example that I found potentially acceptable is > > > http://chandoo.org/img/2010/introduction-to-excel-sparklines.png. In our > > > case, the current value dot can be red, green or any other color based on > > > the ranges defined and the colors associated with it. If we have colored > > > dots, we should possibly change the shape of the marker too for each > > > color > > > so that color blind people can still find value on this as a status > > > indicator. > > > > > > > > > > Thanks for the mock up, I think it looks great. Perhaps I'd consider > > > > lines > > > > instead of dots (to see the base 0, currently the line is somehow "in > > > > the > > > > air" and since the height is limited it may be difficult to > > > > distinguissh > > > > 20% > > > > from 0%), provided they are in some light color it may look ok > > > > > > I am not sure I completely understand the request here. Is there a need > > > to > > > clearly mark the zero/baseline here? Or need multiple dots to highlight > > > various values on the line? Or are we needing a band like this > > > (https://www.broadbandmetrics.com/download/attachments/3768372/TufteSparklne_medical.jpg?version=1&modificationDate=1362506139000) > > > to mark the desirable range? One thing I want to make sure we are on the > > > same page is that the sparkline is definitely not a good widget to > > > distinguish small or accurate changes but more the current position in > > > relation to the overall shape. > > > > > > > > > > > > > > > > > > > > * keep in mind that the view is dynamic and keeps updating once it > > > > > receives new statistics from the backend. > > > > > > > > > > Thoughts? > > > > > > > > > > > > > > > ----- Original Message ----- > > > > >> From: "Malini Rao" > > > > >> To: "Tomas Jelinek" > > > > >> Cc: "Einav Cohen" , "engine-devel" > > > > >> , "Eldan Hildesheim" > > > > >> , "info" , "Martin Polednik" > > > > >> > > > > >> 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 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? 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 at 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 at ovirt.org > > > > >>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel > > > > >>>>> > > > > >>>>> > > > > >>>>> > > > > >>>> > > > > >>> > > > > > > > > > > > > > > > > _______________________________________________ > > > Engine-devel mailing list > > > Engine-devel at ovirt.org > > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > > > > > > > > > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > -------------- next part -------------- A non-text attachment was scrubbed... Name: shaped-markers--colored-numbers.png Type: image/png Size: 700913 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Colored sparklines.fw.png Type: image/png Size: 1289740 bytes Desc: not available URL: From mrao at redhat.com Fri Nov 15 19:55:20 2013 From: mrao at redhat.com (Malini Rao) Date: Fri, 15 Nov 2013 14:55:20 -0500 (EST) Subject: [Engine-devel] [UX] how to design a bar/line chart? In-Reply-To: <1547048567.6416859.1384543941781.JavaMail.root@redhat.com> References: <157528892.18409921.1383645002815.JavaMail.root@redhat.com> <1306019229.17661019.1383751496579.JavaMail.root@redhat.com> <858746798.4081108.1384384154972.JavaMail.root@redhat.com> <5D98AD7F-83C0-48D5-9252-5CD0B220B775@redhat.com> <750008068.23476473.1384460268160.JavaMail.root@redhat.com> <356685769.5458199.1384463454334.JavaMail.root@redhat.com> <2017675394.24155723.1384540556930.JavaMail.root@redhat.com> <1547048567.6416859.1384543941781.JavaMail.root@redhat.com> Message-ID: <818530950.24215144.1384545320058.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Einav Cohen" > To: "Malini Rao" > Cc: "Eldan Hildesheim" , "engine-devel" , "info" , > "Michal Skrivanek" > Sent: Friday, November 15, 2013 2:32:21 PM > Subject: Re: [Engine-devel] [UX] how to design a bar/line chart? > > > Also, I am glad you are always presenting current and proposed together as > > it > > allows for effective comparison. I think it is safe to say that it is > > easier > > to discern the VMs that need attention in the current view than in the > > proposed view because there is more color there than in a small dot. > > +1 > > > As an experiment, I tried to render the entire sparkline in the color of > > the > > current value ( See attached) - It is more effective in the scannability > > aspect but it is painting all values in the color of the current value > > which > > is not technically accurate. What do you guys think? > > Malini, I agree with the above: it is more effective in the scannablity > aspect, > but misleading due to the entire trend being represented by a color that > actually represents only the last reading. > For better scannability without the misleading aspect, I was thinking about > coloring the text next to the dot in the same color. we can also think about > marking in bold this text when it is orange and/or red, for even better > scannability (that will be helpful also for color-blind users). > see attached "shaped-markers--colored-numbers.png" for demonstration (in this > mock-up, I marked bold only the red text). I like it. But to take it even further and to remove any contrast issues affecting readability, I would only change the color and bold the red numbers. Rest should all be regular text. That will truly call out the ones in the red zone which are the ones that need attention. The colored shaped markers will still accurately reveal all other values in and their associated status range. What say? > > thoughts? > > ---- > Thanks, > Einav > > ----- Original Message ----- > > From: "Malini Rao" > > To: "Einav Cohen" > > Cc: "Eldan Hildesheim" , "engine-devel" > > , "info" , > > "Michal Skrivanek" > > Sent: Friday, November 15, 2013 1:35:57 PM > > Subject: Re: [Engine-devel] [UX] how to design a bar/line chart? > > > > ----- Original Message ----- > > > From: "Einav Cohen" > > > To: "Malini Rao" , "Michal Skrivanek" > > > > > > Cc: "Eldan Hildesheim" , "engine-devel" > > > , "info" > > > Sent: Thursday, November 14, 2013 4:10:54 PM > > > Subject: Re: [Engine-devel] [UX] how to design a bar/line chart? > > > > > > > > ...maybe just a global setting to disable this if it gets annoying? > > > > > It's > > > > > a > > > > > small feature and it's trivial to add such a setting. > > > > > > > > > > @Michal: I am not sure what you mean by "disable"; if you mean "hide (the > > > columns)", > > > then I think that we should rely on the global "show/hide columns" > > > feature, > > > and > > > not create a dedicated configuration value for these particular columns. > > > Moreover, > > > the global "show/hide columns" feature will allow customization per > > > user/client, > > > rather than a global-configuration-level customization, so each user will > > > be > > > able > > > to define his view as he wishes. > > > > > > > I am averse to turning it off completely since it will be less than > > > > what > > > > they > > > > have today but may be if they are displaying a trend, they should be > > > > able > > > > to > > > > choose to only see the current value... > > > > > > @Malini, do you mean that they need the option to "fallback" to the > > > current > > > "bar" > > > design (which reflects only the current value)? or something else? > > > > My preference is to choose a suitable visualization and not have any other > > view options. I think the ability to add or remove that column is > > sufficient > > should a user not find value in these columns. I merely suggested the fall > > back option instead of having a setting to turn these columns off > > altogether > > permanently. > > > > > > > > > > > ... If we have colored dots, we should possibly change the shape of the > > > > marker > > > > too for each color so that color blind people can still find value on > > > > this > > > > as > > > > a status indicator. > > > > > > I like the idea of colored dots; not sure about the different shapes > > > though, > > > as > > > the dots would be pretty tiny; in the color-blind case: wouldn't it be > > > sufficient > > > to rely on the dot "height" + the textual value? > > > > I am not sure it is enough - Height and text are available for all users > > including those that are not colorblind and the color of the dot is an > > additional data point that they will miss out on if we didn't do the shape. > > I think even at this size, it will be easy to distinguish a circle from a > > triangle and a square. Having more than that may be tricky.( See attached) > > > > Also, I am glad you are always presenting current and proposed together as > > it > > allows for effective comparison. I think it is safe to say that it is > > easier > > to discern the VMs that need attention in the current view than in the > > proposed view because there is more color there than in a small dot. As an > > experiment, I tried to render the entire sparkline in the color of the > > current value ( See attached) - It is more effective in the scannability > > aspect but it is painting all values in the color of the current value > > which > > is not technically accurate. What do you guys think? > > > > > > > > > > Thanks for the mock up, I think it looks great. Perhaps I'd consider > > > > > lines > > > > > instead of dots (to see the base 0, currently the line is somehow "in > > > > > the > > > > > air" and since the height is limited it may be difficult to > > > > > distinguissh > > > > > 20% > > > > > from 0%), provided they are in some light color it may look ok > > > > > > > > I am not sure I completely understand the request here. Is there a need > > > > to > > > > clearly mark the zero/baseline here? Or need multiple dots to highlight > > > > various values on the line? Or are we needing a band like this > > > > (https://www.broadbandmetrics.com/download/attachments/3768372/TufteSparklne_medical.jpg?version=1&modificationDate=1362506139000) > > > > to mark the desirable range? One thing I want to make sure we are on > > > > the > > > > same page is that the sparkline is definitely not a good widget to > > > > distinguish small or accurate changes but more the current position in > > > > relation to the overall shape. > > > > > > I think that we are all on the same page here (others - please correct me > > > if > > > I am wrong) that only the general trend is of interest here, and not the > > > exact > > > values (maybe with the exception of the "last" value in each trendline). > > > I believe that Michal was referring to axes [in particular the horizontal > > > ('x') > > > axis, I assume] so indeed we will have a clearer baseline for the trend. > > > theoretically we can also have a "band", as you suggested, just need to > > > well- > > > define the "range" of the band so it would makes sense (not sure if easy > > > to > > > do). > > > > > > I am attaching an updated mock-up with axes (only added for the first > > > few lines) as well as colored dots, as you (Malini) suggested above. > > > > I am not sure how much value the axes provide as it is still pretty hard to > > tell the difference from 0 to 20. As long as there are no negative values, > > do we really need the axes? If we do, Einav's mockup is pretty good in > > terms > > of representing the axes since it is not looking cluttered. > > > > > > > > ---- > > > Thanks, > > > Einav > > > > > > ----- Original Message ----- > > > > From: "Malini Rao" > > > > To: "Michal Skrivanek" > > > > Cc: "Eldan Hildesheim" , "engine-devel" > > > > , "info" > > > > Sent: Thursday, November 14, 2013 3:17:48 PM > > > > Subject: Re: [Engine-devel] [UX] how to design a bar/line chart? > > > > > > > > ----- Original Message ----- > > > > > From: "Michal Skrivanek" > > > > > To: "Einav Cohen" > > > > > Cc: "Malini Rao" , "Tomas Jelinek" > > > > > , > > > > > "Eldan Hildesheim" , > > > > > "info" , "engine-devel" > > > > > Sent: Thursday, November 14, 2013 2:21:03 AM > > > > > Subject: Re: [Engine-devel] [UX] how to design a bar/line chart? > > > > > > > > > > > > > > > On Nov 14, 2013, at 00:09 , Einav Cohen wrote: > > > > > > > > > > >> ... but we may have to see how this looks when multiple sparklines > > > > > >> reside in columns next to each other. > > > > > >> ... > > > > > >> ... > > > > > >> Is this going to fit in a row of a table? Or are we talking of a > > > > > >> more detailed view? > > > > > >> ... > > > > > > > > > > > > a concern on which I happened to briefly discuss with Eldan / > > > > > > Malini > > > > > > and actually somewhat raised here earlier in the thread (see > > > > > > above): > > > > > > Since we are adding another information "dimension" (time), we are > > > > > > actually going to display a lot more information to the user within > > > > > > the > > > > > > CPU/MEM/NET columns, and there is a chance that the view will > > > > > > become > > > > > > too overloaded/confusing, and we will end up with a view that is > > > > > > less > > > > > > clear than the current one. > > > > > > > > > > Well, for that we IMHO have much bigger issue already with the fact > > > > > we > > > > > do > > > > > not > > > > > hide/show columns, and many of them do not really provide much value > > > > > in > > > > > all > > > > > use cases. If you look at the mockup and the screenshots from users > > > > > I've > > > > > seen - e.g. the Display column(don't care), the Cluster (not wide > > > > > enough, > > > > > repetition of the same info on each line), Host(repetition of domain > > > > > parts > > > > > of FQDN) makes it overloaded already. > > > > > > > > Agreed and I think we should address that and some efforts in terms of > > > > designs are underway for some of these issues. However, I think Einav's > > > > point was about increasing the amount of info in each of those 3 > > > > columns > > > > exponentially since it is a trend and not a single value. Having said > > > > that, > > > > I think the trend represented as a sparkline/ trendline is not meant to > > > > give > > > > you that many more datapoints - It gives you the current value and an > > > > idea > > > > of the trend based on the 'shape' of the trend line and not the > > > > individual > > > > peaks and troughs. So I think it is not that much of a leap in terms of > > > > the > > > > cognitive overload. > > > > > > > > > Since statistics do provide some value and it keeps changing based on > > > > > load > > > > > it > > > > > IMHO looks ok > > > > > > > > I think the question in my mind here is if the trendline is indeed a > > > > better > > > > visualization for all these three attributes? In other words, is a > > > > trend > > > > for > > > > the memory as valuable as a trend for network or CPU? Or is it more > > > > useful > > > > for the user to see the current visualization for memory that fills the > > > > bar > > > > as it gets closer to 100% and turns red? The point I am trying to make > > > > is > > > > that the trendline/ sparkline is not necessarily a widget with > > > > cognitive > > > > overload but it is still worth considering if it is the right data > > > > visualization for the attribute. So is it possible that only one or > > > > more > > > > of > > > > these attributes is a sparkline? > > > > > > > > > > > > > ...maybe just a global setting to disable this if it gets annoying? > > > > > It's > > > > > a > > > > > small feature and it's trivial to add such a setting. > > > > > > > > I am averse to turning it off completely since it will be less than > > > > what > > > > they > > > > have today but may be if they are displaying a trend, they should be > > > > able > > > > to > > > > choose to only see the current value... > > > > > > > > > > > > > > > > > > > > > Just so we will have a general idea of how it will look like > > > > > > eventually, > > > > > > so we will be able to do a slightly more educated decision, I am > > > > > > attaching > > > > > > a mock-up of how it looks now compared to how it may look once this > > > > > > feature is implemented. > > > > > > > > Einav, the mockup looks awesome.. you beat me to it! :) Also, after > > > > looking > > > > at the mockup, I am less worried about the 3 sparkline columns > > > > displaying > > > > next to each other especially because the current value breaks the > > > > lines > > > > from all merging together. > > > > > > > > > > > > > > > > > > > > * In my mock-up, I followed Malini's guideline from earlier in the > > > > > > thread: > > > > > > """ > > > > > > One color with a dot to indicate the most recent or most relevant > > > > > > data > > > > > > and display its value next to the sparkline > > > > > > """ > > > > > > > > I think Sparklines lend themselves less to status/ threshold indicators > > > > that > > > > rely on color. One example that I found potentially acceptable is > > > > http://chandoo.org/img/2010/introduction-to-excel-sparklines.png. In > > > > our > > > > case, the current value dot can be red, green or any other color based > > > > on > > > > the ranges defined and the colors associated with it. If we have > > > > colored > > > > dots, we should possibly change the shape of the marker too for each > > > > color > > > > so that color blind people can still find value on this as a status > > > > indicator. > > > > > > > > > > > > > Thanks for the mock up, I think it looks great. Perhaps I'd consider > > > > > lines > > > > > instead of dots (to see the base 0, currently the line is somehow "in > > > > > the > > > > > air" and since the height is limited it may be difficult to > > > > > distinguissh > > > > > 20% > > > > > from 0%), provided they are in some light color it may look ok > > > > > > > > I am not sure I completely understand the request here. Is there a need > > > > to > > > > clearly mark the zero/baseline here? Or need multiple dots to highlight > > > > various values on the line? Or are we needing a band like this > > > > (https://www.broadbandmetrics.com/download/attachments/3768372/TufteSparklne_medical.jpg?version=1&modificationDate=1362506139000) > > > > to mark the desirable range? One thing I want to make sure we are on > > > > the > > > > same page is that the sparkline is definitely not a good widget to > > > > distinguish small or accurate changes but more the current position in > > > > relation to the overall shape. > > > > > > > > > > > > > > > > > > > > > > > > > * keep in mind that the view is dynamic and keeps updating once it > > > > > > receives new statistics from the backend. > > > > > > > > > > > > Thoughts? > > > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > >> From: "Malini Rao" > > > > > >> To: "Tomas Jelinek" > > > > > >> Cc: "Einav Cohen" , "engine-devel" > > > > > >> , "Eldan Hildesheim" > > > > > >> , "info" , "Martin > > > > > >> Polednik" > > > > > >> > > > > > >> 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 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? 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 at 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 at ovirt.org > > > > > >>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel > > > > > >>>>> > > > > > >>>>> > > > > > >>>>> > > > > > >>>> > > > > > >>> > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > Engine-devel mailing list > > > > Engine-devel at ovirt.org > > > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > > > > > > > > > > > > > > _______________________________________________ > > Engine-devel mailing list > > Engine-devel at ovirt.org > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > From ecohen at redhat.com Fri Nov 15 20:26:10 2013 From: ecohen at redhat.com (Einav Cohen) Date: Fri, 15 Nov 2013 15:26:10 -0500 (EST) Subject: [Engine-devel] [UX] how to design a bar/line chart? In-Reply-To: <818530950.24215144.1384545320058.JavaMail.root@redhat.com> References: <157528892.18409921.1383645002815.JavaMail.root@redhat.com> <858746798.4081108.1384384154972.JavaMail.root@redhat.com> <5D98AD7F-83C0-48D5-9252-5CD0B220B775@redhat.com> <750008068.23476473.1384460268160.JavaMail.root@redhat.com> <356685769.5458199.1384463454334.JavaMail.root@redhat.com> <2017675394.24155723.1384540556930.JavaMail.root@redhat.com> <1547048567.6416859.1384543941781.JavaMail.root@redhat.com> <818530950.24215144.1384545320058.JavaMail.root@redhat.com> Message-ID: <1823479187.6503546.1384547170244.JavaMail.root@redhat.com> > ----- Original Message ----- > From: "Malini Rao" > Sent: Friday, November 15, 2013 2:55:20 PM > > > ----- Original Message ----- > > From: "Einav Cohen" > > To: "Malini Rao" > > Cc: "Eldan Hildesheim" , "engine-devel" > > , "info" , > > "Michal Skrivanek" > > Sent: Friday, November 15, 2013 2:32:21 PM > > Subject: Re: [Engine-devel] [UX] how to design a bar/line chart? > > > > > Also, I am glad you are always presenting current and proposed together > > > as > > > it > > > allows for effective comparison. I think it is safe to say that it is > > > easier > > > to discern the VMs that need attention in the current view than in the > > > proposed view because there is more color there than in a small dot. > > > > +1 > > > > > As an experiment, I tried to render the entire sparkline in the color of > > > the > > > current value ( See attached) - It is more effective in the scannability > > > aspect but it is painting all values in the color of the current value > > > which > > > is not technically accurate. What do you guys think? > > > > Malini, I agree with the above: it is more effective in the scannablity > > aspect, > > but misleading due to the entire trend being represented by a color that > > actually represents only the last reading. > > For better scannability without the misleading aspect, I was thinking about > > coloring the text next to the dot in the same color. we can also think > > about > > marking in bold this text when it is orange and/or red, for even better > > scannability (that will be helpful also for color-blind users). > > see attached "shaped-markers--colored-numbers.png" for demonstration (in > > this > > mock-up, I marked bold only the red text). > > I like it. But to take it even further and to remove any contrast issues > affecting readability, I would only change the color and bold the red > numbers. Rest should all be regular text. That will truly call out the ones > in the red zone which are the ones that need attention. The colored shaped > markers will still accurately reveal all other values in and their > associated status range. > What say? good idea, Malini - indeed the red ones are standing out more clearly in this case (see attached). > > > > > > thoughts? > > > > ---- > > Thanks, > > Einav > > > > ----- Original Message ----- > > > From: "Malini Rao" > > > To: "Einav Cohen" > > > Cc: "Eldan Hildesheim" , "engine-devel" > > > , "info" , > > > "Michal Skrivanek" > > > Sent: Friday, November 15, 2013 1:35:57 PM > > > Subject: Re: [Engine-devel] [UX] how to design a bar/line chart? > > > > > > ----- Original Message ----- > > > > From: "Einav Cohen" > > > > To: "Malini Rao" , "Michal Skrivanek" > > > > > > > > Cc: "Eldan Hildesheim" , "engine-devel" > > > > , "info" > > > > Sent: Thursday, November 14, 2013 4:10:54 PM > > > > Subject: Re: [Engine-devel] [UX] how to design a bar/line chart? > > > > > > > > > > ...maybe just a global setting to disable this if it gets annoying? > > > > > > It's > > > > > > a > > > > > > small feature and it's trivial to add such a setting. > > > > > > > > > > > > > @Michal: I am not sure what you mean by "disable"; if you mean "hide > > > > (the > > > > columns)", > > > > then I think that we should rely on the global "show/hide columns" > > > > feature, > > > > and > > > > not create a dedicated configuration value for these particular > > > > columns. > > > > Moreover, > > > > the global "show/hide columns" feature will allow customization per > > > > user/client, > > > > rather than a global-configuration-level customization, so each user > > > > will > > > > be > > > > able > > > > to define his view as he wishes. > > > > > > > > > I am averse to turning it off completely since it will be less than > > > > > what > > > > > they > > > > > have today but may be if they are displaying a trend, they should be > > > > > able > > > > > to > > > > > choose to only see the current value... > > > > > > > > @Malini, do you mean that they need the option to "fallback" to the > > > > current > > > > "bar" > > > > design (which reflects only the current value)? or something else? > > > > > > My preference is to choose a suitable visualization and not have any > > > other > > > view options. I think the ability to add or remove that column is > > > sufficient > > > should a user not find value in these columns. I merely suggested the > > > fall > > > back option instead of having a setting to turn these columns off > > > altogether > > > permanently. > > > > > > > > > > > > > > > ... If we have colored dots, we should possibly change the shape of > > > > > the > > > > > marker > > > > > too for each color so that color blind people can still find value on > > > > > this > > > > > as > > > > > a status indicator. > > > > > > > > I like the idea of colored dots; not sure about the different shapes > > > > though, > > > > as > > > > the dots would be pretty tiny; in the color-blind case: wouldn't it be > > > > sufficient > > > > to rely on the dot "height" + the textual value? > > > > > > I am not sure it is enough - Height and text are available for all users > > > including those that are not colorblind and the color of the dot is an > > > additional data point that they will miss out on if we didn't do the > > > shape. > > > I think even at this size, it will be easy to distinguish a circle from a > > > triangle and a square. Having more than that may be tricky.( See > > > attached) > > > > > > Also, I am glad you are always presenting current and proposed together > > > as > > > it > > > allows for effective comparison. I think it is safe to say that it is > > > easier > > > to discern the VMs that need attention in the current view than in the > > > proposed view because there is more color there than in a small dot. As > > > an > > > experiment, I tried to render the entire sparkline in the color of the > > > current value ( See attached) - It is more effective in the scannability > > > aspect but it is painting all values in the color of the current value > > > which > > > is not technically accurate. What do you guys think? > > > > > > > > > > > > > Thanks for the mock up, I think it looks great. Perhaps I'd > > > > > > consider > > > > > > lines > > > > > > instead of dots (to see the base 0, currently the line is somehow > > > > > > "in > > > > > > the > > > > > > air" and since the height is limited it may be difficult to > > > > > > distinguissh > > > > > > 20% > > > > > > from 0%), provided they are in some light color it may look ok > > > > > > > > > > I am not sure I completely understand the request here. Is there a > > > > > need > > > > > to > > > > > clearly mark the zero/baseline here? Or need multiple dots to > > > > > highlight > > > > > various values on the line? Or are we needing a band like this > > > > > (https://www.broadbandmetrics.com/download/attachments/3768372/TufteSparklne_medical.jpg?version=1&modificationDate=1362506139000) > > > > > to mark the desirable range? One thing I want to make sure we are on > > > > > the > > > > > same page is that the sparkline is definitely not a good widget to > > > > > distinguish small or accurate changes but more the current position > > > > > in > > > > > relation to the overall shape. > > > > > > > > I think that we are all on the same page here (others - please correct > > > > me > > > > if > > > > I am wrong) that only the general trend is of interest here, and not > > > > the > > > > exact > > > > values (maybe with the exception of the "last" value in each > > > > trendline). > > > > I believe that Michal was referring to axes [in particular the > > > > horizontal > > > > ('x') > > > > axis, I assume] so indeed we will have a clearer baseline for the > > > > trend. > > > > theoretically we can also have a "band", as you suggested, just need to > > > > well- > > > > define the "range" of the band so it would makes sense (not sure if > > > > easy > > > > to > > > > do). > > > > > > > > I am attaching an updated mock-up with axes (only added for the first > > > > few lines) as well as colored dots, as you (Malini) suggested above. > > > > > > I am not sure how much value the axes provide as it is still pretty hard > > > to > > > tell the difference from 0 to 20. As long as there are no negative > > > values, > > > do we really need the axes? If we do, Einav's mockup is pretty good in > > > terms > > > of representing the axes since it is not looking cluttered. > > > > > > > > > > > ---- > > > > Thanks, > > > > Einav > > > > > > > > ----- Original Message ----- > > > > > From: "Malini Rao" > > > > > To: "Michal Skrivanek" > > > > > Cc: "Eldan Hildesheim" , "engine-devel" > > > > > , "info" > > > > > Sent: Thursday, November 14, 2013 3:17:48 PM > > > > > Subject: Re: [Engine-devel] [UX] how to design a bar/line chart? > > > > > > > > > > ----- Original Message ----- > > > > > > From: "Michal Skrivanek" > > > > > > To: "Einav Cohen" > > > > > > Cc: "Malini Rao" , "Tomas Jelinek" > > > > > > , > > > > > > "Eldan Hildesheim" , > > > > > > "info" , "engine-devel" > > > > > > Sent: Thursday, November 14, 2013 2:21:03 AM > > > > > > Subject: Re: [Engine-devel] [UX] how to design a bar/line chart? > > > > > > > > > > > > > > > > > > On Nov 14, 2013, at 00:09 , Einav Cohen wrote: > > > > > > > > > > > > >> ... but we may have to see how this looks when multiple > > > > > > >> sparklines > > > > > > >> reside in columns next to each other. > > > > > > >> ... > > > > > > >> ... > > > > > > >> Is this going to fit in a row of a table? Or are we talking of a > > > > > > >> more detailed view? > > > > > > >> ... > > > > > > > > > > > > > > a concern on which I happened to briefly discuss with Eldan / > > > > > > > Malini > > > > > > > and actually somewhat raised here earlier in the thread (see > > > > > > > above): > > > > > > > Since we are adding another information "dimension" (time), we > > > > > > > are > > > > > > > actually going to display a lot more information to the user > > > > > > > within > > > > > > > the > > > > > > > CPU/MEM/NET columns, and there is a chance that the view will > > > > > > > become > > > > > > > too overloaded/confusing, and we will end up with a view that is > > > > > > > less > > > > > > > clear than the current one. > > > > > > > > > > > > Well, for that we IMHO have much bigger issue already with the fact > > > > > > we > > > > > > do > > > > > > not > > > > > > hide/show columns, and many of them do not really provide much > > > > > > value > > > > > > in > > > > > > all > > > > > > use cases. If you look at the mockup and the screenshots from users > > > > > > I've > > > > > > seen - e.g. the Display column(don't care), the Cluster (not wide > > > > > > enough, > > > > > > repetition of the same info on each line), Host(repetition of > > > > > > domain > > > > > > parts > > > > > > of FQDN) makes it overloaded already. > > > > > > > > > > Agreed and I think we should address that and some efforts in terms > > > > > of > > > > > designs are underway for some of these issues. However, I think > > > > > Einav's > > > > > point was about increasing the amount of info in each of those 3 > > > > > columns > > > > > exponentially since it is a trend and not a single value. Having said > > > > > that, > > > > > I think the trend represented as a sparkline/ trendline is not meant > > > > > to > > > > > give > > > > > you that many more datapoints - It gives you the current value and an > > > > > idea > > > > > of the trend based on the 'shape' of the trend line and not the > > > > > individual > > > > > peaks and troughs. So I think it is not that much of a leap in terms > > > > > of > > > > > the > > > > > cognitive overload. > > > > > > > > > > > Since statistics do provide some value and it keeps changing based > > > > > > on > > > > > > load > > > > > > it > > > > > > IMHO looks ok > > > > > > > > > > I think the question in my mind here is if the trendline is indeed a > > > > > better > > > > > visualization for all these three attributes? In other words, is a > > > > > trend > > > > > for > > > > > the memory as valuable as a trend for network or CPU? Or is it more > > > > > useful > > > > > for the user to see the current visualization for memory that fills > > > > > the > > > > > bar > > > > > as it gets closer to 100% and turns red? The point I am trying to > > > > > make > > > > > is > > > > > that the trendline/ sparkline is not necessarily a widget with > > > > > cognitive > > > > > overload but it is still worth considering if it is the right data > > > > > visualization for the attribute. So is it possible that only one or > > > > > more > > > > > of > > > > > these attributes is a sparkline? > > > > > > > > > > > > > > > > ...maybe just a global setting to disable this if it gets annoying? > > > > > > It's > > > > > > a > > > > > > small feature and it's trivial to add such a setting. > > > > > > > > > > I am averse to turning it off completely since it will be less than > > > > > what > > > > > they > > > > > have today but may be if they are displaying a trend, they should be > > > > > able > > > > > to > > > > > choose to only see the current value... > > > > > > > > > > > > > > > > > > > > > > > > > Just so we will have a general idea of how it will look like > > > > > > > eventually, > > > > > > > so we will be able to do a slightly more educated decision, I am > > > > > > > attaching > > > > > > > a mock-up of how it looks now compared to how it may look once > > > > > > > this > > > > > > > feature is implemented. > > > > > > > > > > Einav, the mockup looks awesome.. you beat me to it! :) Also, after > > > > > looking > > > > > at the mockup, I am less worried about the 3 sparkline columns > > > > > displaying > > > > > next to each other especially because the current value breaks the > > > > > lines > > > > > from all merging together. > > > > > > > > > > > > > > > > > > > > > > > > * In my mock-up, I followed Malini's guideline from earlier in > > > > > > > the > > > > > > > thread: > > > > > > > """ > > > > > > > One color with a dot to indicate the most recent or most relevant > > > > > > > data > > > > > > > and display its value next to the sparkline > > > > > > > """ > > > > > > > > > > I think Sparklines lend themselves less to status/ threshold > > > > > indicators > > > > > that > > > > > rely on color. One example that I found potentially acceptable is > > > > > http://chandoo.org/img/2010/introduction-to-excel-sparklines.png. In > > > > > our > > > > > case, the current value dot can be red, green or any other color > > > > > based > > > > > on > > > > > the ranges defined and the colors associated with it. If we have > > > > > colored > > > > > dots, we should possibly change the shape of the marker too for each > > > > > color > > > > > so that color blind people can still find value on this as a status > > > > > indicator. > > > > > > > > > > > > > > > > Thanks for the mock up, I think it looks great. Perhaps I'd > > > > > > consider > > > > > > lines > > > > > > instead of dots (to see the base 0, currently the line is somehow > > > > > > "in > > > > > > the > > > > > > air" and since the height is limited it may be difficult to > > > > > > distinguissh > > > > > > 20% > > > > > > from 0%), provided they are in some light color it may look ok > > > > > > > > > > I am not sure I completely understand the request here. Is there a > > > > > need > > > > > to > > > > > clearly mark the zero/baseline here? Or need multiple dots to > > > > > highlight > > > > > various values on the line? Or are we needing a band like this > > > > > (https://www.broadbandmetrics.com/download/attachments/3768372/TufteSparklne_medical.jpg?version=1&modificationDate=1362506139000) > > > > > to mark the desirable range? One thing I want to make sure we are on > > > > > the > > > > > same page is that the sparkline is definitely not a good widget to > > > > > distinguish small or accurate changes but more the current position > > > > > in > > > > > relation to the overall shape. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > * keep in mind that the view is dynamic and keeps updating once > > > > > > > it > > > > > > > receives new statistics from the backend. > > > > > > > > > > > > > > Thoughts? > > > > > > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > >> From: "Malini Rao" > > > > > > >> To: "Tomas Jelinek" > > > > > > >> Cc: "Einav Cohen" , "engine-devel" > > > > > > >> , "Eldan Hildesheim" > > > > > > >> , "info" , "Martin > > > > > > >> Polednik" > > > > > > >> > > > > > > >> 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 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? 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 at 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 at ovirt.org > > > > > > >>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel > > > > > > >>>>> > > > > > > >>>>> > > > > > > >>>>> > > > > > > >>>> > > > > > > >>> > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > Engine-devel mailing list > > > > > Engine-devel at ovirt.org > > > > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > Engine-devel mailing list > > > Engine-devel at ovirt.org > > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > > -------------- next part -------------- A non-text attachment was scrubbed... Name: shaped-markers--red-text-bold.png Type: image/png Size: 701437 bytes Desc: not available URL: From mrao at redhat.com Fri Nov 15 21:32:15 2013 From: mrao at redhat.com (Malini Rao) Date: Fri, 15 Nov 2013 16:32:15 -0500 (EST) Subject: [Engine-devel] [UX] how to design a bar/line chart? In-Reply-To: <1823479187.6503546.1384547170244.JavaMail.root@redhat.com> References: <157528892.18409921.1383645002815.JavaMail.root@redhat.com> <5D98AD7F-83C0-48D5-9252-5CD0B220B775@redhat.com> <750008068.23476473.1384460268160.JavaMail.root@redhat.com> <356685769.5458199.1384463454334.JavaMail.root@redhat.com> <2017675394.24155723.1384540556930.JavaMail.root@redhat.com> <1547048567.6416859.1384543941781.JavaMail.root@redhat.com> <818530950.24215144.1384545320058.JavaMail.root@redhat.com> <1823479187.6503546.1384547170244.JavaMail.root@redhat.com> Message-ID: <334673294.24303285.1384551135090.JavaMail.root@redhat.com> Agreed! Also just as it is inaccurate to draw the sparkline in one of the other colors based on the current value, I htink it is also inaccurate to draw the sparklines in green since it has a specific meaning. I think the lines should all be dark gray or black and only the markers and the red numbers should be the color elements. -Malini ----- Original Message ----- From: "Einav Cohen" To: "Malini Rao" Cc: "Eldan Hildesheim" , "engine-devel" , "info" , "Michal Skrivanek" Sent: Friday, November 15, 2013 3:26:10 PM Subject: Re: [Engine-devel] [UX] how to design a bar/line chart? > ----- Original Message ----- > From: "Malini Rao" > Sent: Friday, November 15, 2013 2:55:20 PM > > > ----- Original Message ----- > > From: "Einav Cohen" > > To: "Malini Rao" > > Cc: "Eldan Hildesheim" , "engine-devel" > > , "info" , > > "Michal Skrivanek" > > Sent: Friday, November 15, 2013 2:32:21 PM > > Subject: Re: [Engine-devel] [UX] how to design a bar/line chart? > > > > > Also, I am glad you are always presenting current and proposed together > > > as > > > it > > > allows for effective comparison. I think it is safe to say that it is > > > easier > > > to discern the VMs that need attention in the current view than in the > > > proposed view because there is more color there than in a small dot. > > > > +1 > > > > > As an experiment, I tried to render the entire sparkline in the color of > > > the > > > current value ( See attached) - It is more effective in the scannability > > > aspect but it is painting all values in the color of the current value > > > which > > > is not technically accurate. What do you guys think? > > > > Malini, I agree with the above: it is more effective in the scannablity > > aspect, > > but misleading due to the entire trend being represented by a color that > > actually represents only the last reading. > > For better scannability without the misleading aspect, I was thinking about > > coloring the text next to the dot in the same color. we can also think > > about > > marking in bold this text when it is orange and/or red, for even better > > scannability (that will be helpful also for color-blind users). > > see attached "shaped-markers--colored-numbers.png" for demonstration (in > > this > > mock-up, I marked bold only the red text). > > I like it. But to take it even further and to remove any contrast issues > affecting readability, I would only change the color and bold the red > numbers. Rest should all be regular text. That will truly call out the ones > in the red zone which are the ones that need attention. The colored shaped > markers will still accurately reveal all other values in and their > associated status range. > What say? good idea, Malini - indeed the red ones are standing out more clearly in this case (see attached). > > > > > > thoughts? > > > > ---- > > Thanks, > > Einav > > > > ----- Original Message ----- > > > From: "Malini Rao" > > > To: "Einav Cohen" > > > Cc: "Eldan Hildesheim" , "engine-devel" > > > , "info" , > > > "Michal Skrivanek" > > > Sent: Friday, November 15, 2013 1:35:57 PM > > > Subject: Re: [Engine-devel] [UX] how to design a bar/line chart? > > > > > > ----- Original Message ----- > > > > From: "Einav Cohen" > > > > To: "Malini Rao" , "Michal Skrivanek" > > > > > > > > Cc: "Eldan Hildesheim" , "engine-devel" > > > > , "info" > > > > Sent: Thursday, November 14, 2013 4:10:54 PM > > > > Subject: Re: [Engine-devel] [UX] how to design a bar/line chart? > > > > > > > > > > ...maybe just a global setting to disable this if it gets annoying? > > > > > > It's > > > > > > a > > > > > > small feature and it's trivial to add such a setting. > > > > > > > > > > > > > @Michal: I am not sure what you mean by "disable"; if you mean "hide > > > > (the > > > > columns)", > > > > then I think that we should rely on the global "show/hide columns" > > > > feature, > > > > and > > > > not create a dedicated configuration value for these particular > > > > columns. > > > > Moreover, > > > > the global "show/hide columns" feature will allow customization per > > > > user/client, > > > > rather than a global-configuration-level customization, so each user > > > > will > > > > be > > > > able > > > > to define his view as he wishes. > > > > > > > > > I am averse to turning it off completely since it will be less than > > > > > what > > > > > they > > > > > have today but may be if they are displaying a trend, they should be > > > > > able > > > > > to > > > > > choose to only see the current value... > > > > > > > > @Malini, do you mean that they need the option to "fallback" to the > > > > current > > > > "bar" > > > > design (which reflects only the current value)? or something else? > > > > > > My preference is to choose a suitable visualization and not have any > > > other > > > view options. I think the ability to add or remove that column is > > > sufficient > > > should a user not find value in these columns. I merely suggested the > > > fall > > > back option instead of having a setting to turn these columns off > > > altogether > > > permanently. > > > > > > > > > > > > > > > ... If we have colored dots, we should possibly change the shape of > > > > > the > > > > > marker > > > > > too for each color so that color blind people can still find value on > > > > > this > > > > > as > > > > > a status indicator. > > > > > > > > I like the idea of colored dots; not sure about the different shapes > > > > though, > > > > as > > > > the dots would be pretty tiny; in the color-blind case: wouldn't it be > > > > sufficient > > > > to rely on the dot "height" + the textual value? > > > > > > I am not sure it is enough - Height and text are available for all users > > > including those that are not colorblind and the color of the dot is an > > > additional data point that they will miss out on if we didn't do the > > > shape. > > > I think even at this size, it will be easy to distinguish a circle from a > > > triangle and a square. Having more than that may be tricky.( See > > > attached) > > > > > > Also, I am glad you are always presenting current and proposed together > > > as > > > it > > > allows for effective comparison. I think it is safe to say that it is > > > easier > > > to discern the VMs that need attention in the current view than in the > > > proposed view because there is more color there than in a small dot. As > > > an > > > experiment, I tried to render the entire sparkline in the color of the > > > current value ( See attached) - It is more effective in the scannability > > > aspect but it is painting all values in the color of the current value > > > which > > > is not technically accurate. What do you guys think? > > > > > > > > > > > > > Thanks for the mock up, I think it looks great. Perhaps I'd > > > > > > consider > > > > > > lines > > > > > > instead of dots (to see the base 0, currently the line is somehow > > > > > > "in > > > > > > the > > > > > > air" and since the height is limited it may be difficult to > > > > > > distinguissh > > > > > > 20% > > > > > > from 0%), provided they are in some light color it may look ok > > > > > > > > > > I am not sure I completely understand the request here. Is there a > > > > > need > > > > > to > > > > > clearly mark the zero/baseline here? Or need multiple dots to > > > > > highlight > > > > > various values on the line? Or are we needing a band like this > > > > > (https://www.broadbandmetrics.com/download/attachments/3768372/TufteSparklne_medical.jpg?version=1&modificationDate=1362506139000) > > > > > to mark the desirable range? One thing I want to make sure we are on > > > > > the > > > > > same page is that the sparkline is definitely not a good widget to > > > > > distinguish small or accurate changes but more the current position > > > > > in > > > > > relation to the overall shape. > > > > > > > > I think that we are all on the same page here (others - please correct > > > > me > > > > if > > > > I am wrong) that only the general trend is of interest here, and not > > > > the > > > > exact > > > > values (maybe with the exception of the "last" value in each > > > > trendline). > > > > I believe that Michal was referring to axes [in particular the > > > > horizontal > > > > ('x') > > > > axis, I assume] so indeed we will have a clearer baseline for the > > > > trend. > > > > theoretically we can also have a "band", as you suggested, just need to > > > > well- > > > > define the "range" of the band so it would makes sense (not sure if > > > > easy > > > > to > > > > do). > > > > > > > > I am attaching an updated mock-up with axes (only added for the first > > > > few lines) as well as colored dots, as you (Malini) suggested above. > > > > > > I am not sure how much value the axes provide as it is still pretty hard > > > to > > > tell the difference from 0 to 20. As long as there are no negative > > > values, > > > do we really need the axes? If we do, Einav's mockup is pretty good in > > > terms > > > of representing the axes since it is not looking cluttered. > > > > > > > > > > > ---- > > > > Thanks, > > > > Einav > > > > > > > > ----- Original Message ----- > > > > > From: "Malini Rao" > > > > > To: "Michal Skrivanek" > > > > > Cc: "Eldan Hildesheim" , "engine-devel" > > > > > , "info" > > > > > Sent: Thursday, November 14, 2013 3:17:48 PM > > > > > Subject: Re: [Engine-devel] [UX] how to design a bar/line chart? > > > > > > > > > > ----- Original Message ----- > > > > > > From: "Michal Skrivanek" > > > > > > To: "Einav Cohen" > > > > > > Cc: "Malini Rao" , "Tomas Jelinek" > > > > > > , > > > > > > "Eldan Hildesheim" , > > > > > > "info" , "engine-devel" > > > > > > Sent: Thursday, November 14, 2013 2:21:03 AM > > > > > > Subject: Re: [Engine-devel] [UX] how to design a bar/line chart? > > > > > > > > > > > > > > > > > > On Nov 14, 2013, at 00:09 , Einav Cohen wrote: > > > > > > > > > > > > >> ... but we may have to see how this looks when multiple > > > > > > >> sparklines > > > > > > >> reside in columns next to each other. > > > > > > >> ... > > > > > > >> ... > > > > > > >> Is this going to fit in a row of a table? Or are we talking of a > > > > > > >> more detailed view? > > > > > > >> ... > > > > > > > > > > > > > > a concern on which I happened to briefly discuss with Eldan / > > > > > > > Malini > > > > > > > and actually somewhat raised here earlier in the thread (see > > > > > > > above): > > > > > > > Since we are adding another information "dimension" (time), we > > > > > > > are > > > > > > > actually going to display a lot more information to the user > > > > > > > within > > > > > > > the > > > > > > > CPU/MEM/NET columns, and there is a chance that the view will > > > > > > > become > > > > > > > too overloaded/confusing, and we will end up with a view that is > > > > > > > less > > > > > > > clear than the current one. > > > > > > > > > > > > Well, for that we IMHO have much bigger issue already with the fact > > > > > > we > > > > > > do > > > > > > not > > > > > > hide/show columns, and many of them do not really provide much > > > > > > value > > > > > > in > > > > > > all > > > > > > use cases. If you look at the mockup and the screenshots from users > > > > > > I've > > > > > > seen - e.g. the Display column(don't care), the Cluster (not wide > > > > > > enough, > > > > > > repetition of the same info on each line), Host(repetition of > > > > > > domain > > > > > > parts > > > > > > of FQDN) makes it overloaded already. > > > > > > > > > > Agreed and I think we should address that and some efforts in terms > > > > > of > > > > > designs are underway for some of these issues. However, I think > > > > > Einav's > > > > > point was about increasing the amount of info in each of those 3 > > > > > columns > > > > > exponentially since it is a trend and not a single value. Having said > > > > > that, > > > > > I think the trend represented as a sparkline/ trendline is not meant > > > > > to > > > > > give > > > > > you that many more datapoints - It gives you the current value and an > > > > > idea > > > > > of the trend based on the 'shape' of the trend line and not the > > > > > individual > > > > > peaks and troughs. So I think it is not that much of a leap in terms > > > > > of > > > > > the > > > > > cognitive overload. > > > > > > > > > > > Since statistics do provide some value and it keeps changing based > > > > > > on > > > > > > load > > > > > > it > > > > > > IMHO looks ok > > > > > > > > > > I think the question in my mind here is if the trendline is indeed a > > > > > better > > > > > visualization for all these three attributes? In other words, is a > > > > > trend > > > > > for > > > > > the memory as valuable as a trend for network or CPU? Or is it more > > > > > useful > > > > > for the user to see the current visualization for memory that fills > > > > > the > > > > > bar > > > > > as it gets closer to 100% and turns red? The point I am trying to > > > > > make > > > > > is > > > > > that the trendline/ sparkline is not necessarily a widget with > > > > > cognitive > > > > > overload but it is still worth considering if it is the right data > > > > > visualization for the attribute. So is it possible that only one or > > > > > more > > > > > of > > > > > these attributes is a sparkline? > > > > > > > > > > > > > > > > ...maybe just a global setting to disable this if it gets annoying? > > > > > > It's > > > > > > a > > > > > > small feature and it's trivial to add such a setting. > > > > > > > > > > I am averse to turning it off completely since it will be less than > > > > > what > > > > > they > > > > > have today but may be if they are displaying a trend, they should be > > > > > able > > > > > to > > > > > choose to only see the current value... > > > > > > > > > > > > > > > > > > > > > > > > > Just so we will have a general idea of how it will look like > > > > > > > eventually, > > > > > > > so we will be able to do a slightly more educated decision, I am > > > > > > > attaching > > > > > > > a mock-up of how it looks now compared to how it may look once > > > > > > > this > > > > > > > feature is implemented. > > > > > > > > > > Einav, the mockup looks awesome.. you beat me to it! :) Also, after > > > > > looking > > > > > at the mockup, I am less worried about the 3 sparkline columns > > > > > displaying > > > > > next to each other especially because the current value breaks the > > > > > lines > > > > > from all merging together. > > > > > > > > > > > > > > > > > > > > > > > > * In my mock-up, I followed Malini's guideline from earlier in > > > > > > > the > > > > > > > thread: > > > > > > > """ > > > > > > > One color with a dot to indicate the most recent or most relevant > > > > > > > data > > > > > > > and display its value next to the sparkline > > > > > > > """ > > > > > > > > > > I think Sparklines lend themselves less to status/ threshold > > > > > indicators > > > > > that > > > > > rely on color. One example that I found potentially acceptable is > > > > > http://chandoo.org/img/2010/introduction-to-excel-sparklines.png. In > > > > > our > > > > > case, the current value dot can be red, green or any other color > > > > > based > > > > > on > > > > > the ranges defined and the colors associated with it. If we have > > > > > colored > > > > > dots, we should possibly change the shape of the marker too for each > > > > > color > > > > > so that color blind people can still find value on this as a status > > > > > indicator. > > > > > > > > > > > > > > > > Thanks for the mock up, I think it looks great. Perhaps I'd > > > > > > consider > > > > > > lines > > > > > > instead of dots (to see the base 0, currently the line is somehow > > > > > > "in > > > > > > the > > > > > > air" and since the height is limited it may be difficult to > > > > > > distinguissh > > > > > > 20% > > > > > > from 0%), provided they are in some light color it may look ok > > > > > > > > > > I am not sure I completely understand the request here. Is there a > > > > > need > > > > > to > > > > > clearly mark the zero/baseline here? Or need multiple dots to > > > > > highlight > > > > > various values on the line? Or are we needing a band like this > > > > > (https://www.broadbandmetrics.com/download/attachments/3768372/TufteSparklne_medical.jpg?version=1&modificationDate=1362506139000) > > > > > to mark the desirable range? One thing I want to make sure we are on > > > > > the > > > > > same page is that the sparkline is definitely not a good widget to > > > > > distinguish small or accurate changes but more the current position > > > > > in > > > > > relation to the overall shape. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > * keep in mind that the view is dynamic and keeps updating once > > > > > > > it > > > > > > > receives new statistics from the backend. > > > > > > > > > > > > > > Thoughts? > > > > > > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > >> From: "Malini Rao" > > > > > > >> To: "Tomas Jelinek" > > > > > > >> Cc: "Einav Cohen" , "engine-devel" > > > > > > >> , "Eldan Hildesheim" > > > > > > >> , "info" , "Martin > > > > > > >> Polednik" > > > > > > >> > > > > > > >> 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 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? 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 at 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 at ovirt.org > > > > > > >>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel > > > > > > >>>>> > > > > > > >>>>> > > > > > > >>>>> > > > > > > >>>> > > > > > > >>> > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > Engine-devel mailing list > > > > > Engine-devel at ovirt.org > > > > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > Engine-devel mailing list > > > Engine-devel at ovirt.org > > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > > From mpastern at redhat.com Sun Nov 17 11:20:58 2013 From: mpastern at redhat.com (Michael Pasternak) Date: Sun, 17 Nov 2013 13:20:58 +0200 Subject: [Engine-devel] move api from /api to /ovirt-engine/api In-Reply-To: <201311061010.rA6AArVf013923@gerrit.ovirt.org> References: <201311061010.rA6AArVf013923@gerrit.ovirt.org> Message-ID: <5288A69A.3090704@redhat.com> Hey Alon, i've noticed that ForwardServlet does not address URI parameters (such as query/matrix), i.e all destinations of this servlet will lack URI parameters been passed at source. On 11/06/2013 12:10 PM, Alon Bar-Lev wrote: > Alon Bar-Lev has posted comments on this change. > > -- > To view, visit http://gerrit.ovirt.org/20786 > To unsubscribe, visit http://gerrit.ovirt.org/settings> > -- Michael Pasternak RedHat, ENG-Virtualization R&D From alonbl at redhat.com Sun Nov 17 11:23:51 2013 From: alonbl at redhat.com (Alon Bar-Lev) Date: Sun, 17 Nov 2013 06:23:51 -0500 (EST) Subject: [Engine-devel] move api from /api to /ovirt-engine/api In-Reply-To: <5288A69A.3090704@redhat.com> References: <201311061010.rA6AArVf013923@gerrit.ovirt.org> <5288A69A.3090704@redhat.com> Message-ID: <515047867.16182603.1384687431216.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Michael Pasternak" > To: "Alon Bar-Lev" > Cc: "engine-devel" > Sent: Sunday, November 17, 2013 1:20:58 PM > Subject: move api from /api to /ovirt-engine/api > > > Hey Alon, > > i've noticed that ForwardServlet does not address URI parameters (such as > query/matrix), > i.e all destinations of this servlet will lack URI parameters been passed at > source. Thanks!!!! Alexander, can you please look at it? Michael... What do you mean URI parameters? just for me to be able to investigate this today? Do you mean query parameters? > > On 11/06/2013 12:10 PM, Alon Bar-Lev wrote: > > Alon Bar-Lev has posted comments on this change. > > > > -- > > To view, visit http://gerrit.ovirt.org/20786 > > To unsubscribe, visit http://gerrit.ovirt.org/settings> > > > -- > > Michael Pasternak > RedHat, ENG-Virtualization R&D > From mpastern at redhat.com Sun Nov 17 12:01:56 2013 From: mpastern at redhat.com (Michael Pasternak) Date: Sun, 17 Nov 2013 14:01:56 +0200 Subject: [Engine-devel] move api from /api to /ovirt-engine/api In-Reply-To: <515047867.16182603.1384687431216.JavaMail.root@redhat.com> References: <201311061010.rA6AArVf013923@gerrit.ovirt.org> <5288A69A.3090704@redhat.com> <515047867.16182603.1384687431216.JavaMail.root@redhat.com> Message-ID: <5288B034.4010409@redhat.com> On 11/17/2013 01:23 PM, Alon Bar-Lev wrote: > > > ----- Original Message ----- >> From: "Michael Pasternak" >> To: "Alon Bar-Lev" >> Cc: "engine-devel" >> Sent: Sunday, November 17, 2013 1:20:58 PM >> Subject: move api from /api to /ovirt-engine/api >> >> >> Hey Alon, >> >> i've noticed that ForwardServlet does not address URI parameters (such as >> query/matrix), >> i.e all destinations of this servlet will lack URI parameters been passed at >> source. > > Thanks!!!! > Alexander, can you please look at it? > > Michael... What do you mean URI parameters? just for me to be able to investigate this today? > Do you mean query parameters? actually it didn't worked for me with matrix [2] so i assumed it's true for all URI params such as query [1], but it fine afaics, so it's only about [2] [1] http://localhost:8080/api/vms?search=name%3Dtest [2] http://localhost:8080/api/events;max=2 thanks. > >> >> On 11/06/2013 12:10 PM, Alon Bar-Lev wrote: >>> Alon Bar-Lev has posted comments on this change. >>> >>> -- >>> To view, visit http://gerrit.ovirt.org/20786 >>> To unsubscribe, visit http://gerrit.ovirt.org/settings> >>> >> -- >> >> Michael Pasternak >> RedHat, ENG-Virtualization R&D >> -- Michael Pasternak RedHat, ENG-Virtualization R&D From mtayer at redhat.com Sun Nov 17 16:56:01 2013 From: mtayer at redhat.com (Mooli Tayer) Date: Sun, 17 Nov 2013 11:56:01 -0500 (EST) Subject: [Engine-devel] When is ovirt-engine expected to start supporting wildfly? In-Reply-To: <382196748.25502493.1384707358372.JavaMail.root@redhat.com> Message-ID: <1543236944.25502494.1384707361919.JavaMail.root@redhat.com> Thanks, Mooli Tayer. From alonbl at redhat.com Sun Nov 17 17:32:11 2013 From: alonbl at redhat.com (Alon Bar-Lev) Date: Sun, 17 Nov 2013 12:32:11 -0500 (EST) Subject: [Engine-devel] move api from /api to /ovirt-engine/api In-Reply-To: <5288B034.4010409@redhat.com> References: <201311061010.rA6AArVf013923@gerrit.ovirt.org> <5288A69A.3090704@redhat.com> <515047867.16182603.1384687431216.JavaMail.root@redhat.com> <5288B034.4010409@redhat.com> Message-ID: <814145376.16190355.1384709531753.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Michael Pasternak" > To: "Alon Bar-Lev" > Cc: "Alexander Wels" , "engine-devel" > Sent: Sunday, November 17, 2013 2:01:56 PM > Subject: Re: move api from /api to /ovirt-engine/api > > On 11/17/2013 01:23 PM, Alon Bar-Lev wrote: > > > > > > ----- Original Message ----- > >> From: "Michael Pasternak" > >> To: "Alon Bar-Lev" > >> Cc: "engine-devel" > >> Sent: Sunday, November 17, 2013 1:20:58 PM > >> Subject: move api from /api to /ovirt-engine/api > >> > >> > >> Hey Alon, > >> > >> i've noticed that ForwardServlet does not address URI parameters (such as > >> query/matrix), > >> i.e all destinations of this servlet will lack URI parameters been passed > >> at > >> source. > > > > Thanks!!!! > > Alexander, can you please look at it? > > > > Michael... What do you mean URI parameters? just for me to be able to > > investigate this today? > > Do you mean query parameters? > > actually it didn't worked for me with matrix [2] so i assumed it's true for > all URI > params such as query [1], but it fine afaics, so it's only about [2] > > [1] http://localhost:8080/api/vms?search=name%3Dtest > [2] http://localhost:8080/api/events;max=2 Done[3], I was not aware that this is valid and split out... Learn new thing any day :) I hope I got this right. Working for this test case as far as I can see. [3] http://gerrit.ovirt.org/#/c/21335/ > > thanks. > > > > >> > >> On 11/06/2013 12:10 PM, Alon Bar-Lev wrote: > >>> Alon Bar-Lev has posted comments on this change. > >>> > >>> -- > >>> To view, visit http://gerrit.ovirt.org/20786 > >>> To unsubscribe, visit http://gerrit.ovirt.org/settings> > >>> > >> -- > >> > >> Michael Pasternak > >> RedHat, ENG-Virtualization R&D > >> > > > -- > > Michael Pasternak > RedHat, ENG-Virtualization R&D > From iheim at redhat.com Sun Nov 17 20:31:25 2013 From: iheim at redhat.com (Itamar Heim) Date: Sun, 17 Nov 2013 22:31:25 +0200 Subject: [Engine-devel] When is ovirt-engine expected to start supporting wildfly? In-Reply-To: <1543236944.25502494.1384707361919.JavaMail.root@redhat.com> References: <1543236944.25502494.1384707361919.JavaMail.root@redhat.com> Message-ID: <5289279D.6030405@redhat.com> On 11/17/2013 06:56 PM, Mooli Tayer wrote: > > Thanks, > Mooli Tayer. > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > well, fedora 20 comes with wildfly (formerly JBoss AS8), so i think we should aim for 3.4 support on fedora 20 with wildfly, but preserving compatibility with AS7/EAP6 for other platforms. iirc, juan has been looking at wildfly compatibility implications - juan? From sbonazzo at redhat.com Mon Nov 18 09:12:02 2013 From: sbonazzo at redhat.com (Sandro Bonazzola) Date: Mon, 18 Nov 2013 10:12:02 +0100 Subject: [Engine-devel] oVirt 3.3.2 beta status Message-ID: <5289D9E2.6020802@redhat.com> Hi, we're going to branch and build oVirt 3.3.2 beta on Nov 27th. A bug tracker is available at [1] and it shows only 2 bugs blocking the release: Bug 1029792 - VDSM does not report the qemu version in capabilities, if qemu-kvm-rhev is used Bug 1029885 - cloud-init testcase does not work in engine 3.3.1 The following is a list of the bugs still open with target 3.3.2 or 3.3: Whiteboard Bug ID Summary 991267 [RFE] Add TUI information to log file. infra 987982 When adding a host through the REST API, the error message says that "rootPassword" is required, but ... infra 1017267 Plaintext user passwords in async_tasks database infra 1020344 Power Managent with cisco_ucs problem infra 1009899 exportDbSchema scripts generates output file with wrong name infra 1029792 VDSM does not report the qemu version in capabilities, if qemu-kvm-rhev is used integration 1026933 pre-populate ISO domain with virtio-win ISO integration 1026930 Package virtio-win and put it in ovirt repositories integration 1030437 RFE: Configuration of email notifications integration 1022440 AIO - configure the AIO host to be a gluster cluster/host integration 902979 ovirt-live - firefox doesn't trust the installed engine integration 1021805 oVirt Live - use motd to show the admin password 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 network 906313 [oVirt-webadmin] [setupNetworks] "No valid Operation for and Unassigned Logical Networks panel" network 1023722 [oVirt-webadmin][network] Network roles in cluster management should be radio buttons network 997197 Some AppErrors messages are grammatically incorrect (singular vs plural) storage 1016118 async between masterVersion : can't connect to StoragePool storage 987917 [oVirt] [glance] API version not specified in provider dialog storage 1029069 Live storage migration snapshot removal fails, probably due to unexpected qemu-img output ux 906394 [oVirt-webadmin] [network] Loading animation in network main tab 'hosts' and 'vms' subtab is stuck on first view... virt 1007940 Cannot clone from snapshot while using GlusterFS as POSIX Storage Domain 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 and add yourself to the testing page [2]. [1] https://bugzilla.redhat.com/1027349 [2] http://www.ovirt.org/Testing/Ovirt_3.3.2_testing -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com From danken at redhat.com Mon Nov 18 12:45:47 2013 From: danken at redhat.com (Dan Kenigsberg) Date: Mon, 18 Nov 2013 12:45:47 +0000 Subject: [Engine-devel] oVirt 3.3.2 beta status In-Reply-To: <5289D9E2.6020802@redhat.com> References: <5289D9E2.6020802@redhat.com> Message-ID: <20131118124547.GJ32249@redhat.com> On Mon, Nov 18, 2013 at 10:12:02AM +0100, Sandro Bonazzola wrote: > Hi, > > we're going to branch and build oVirt 3.3.2 beta on Nov 27th. > A bug tracker is available at [1] and it shows only 2 bugs blocking the release: > > Bug 1029792 - VDSM does not report the qemu version in capabilities, if qemu-kvm-rhev is used Backported http://gerrit.ovirt.org/21363 http://gerrit.ovirt.org/21364 to ovirt-3.3 branch to address this request. From ehildesh at redhat.com Mon Nov 18 13:12:57 2013 From: ehildesh at redhat.com (Eldan Hildesheim) Date: Mon, 18 Nov 2013 08:12:57 -0500 (EST) Subject: [Engine-devel] [UX] how to design a bar/line chart? In-Reply-To: <334673294.24303285.1384551135090.JavaMail.root@redhat.com> References: <157528892.18409921.1383645002815.JavaMail.root@redhat.com> <750008068.23476473.1384460268160.JavaMail.root@redhat.com> <356685769.5458199.1384463454334.JavaMail.root@redhat.com> <2017675394.24155723.1384540556930.JavaMail.root@redhat.com> <1547048567.6416859.1384543941781.JavaMail.root@redhat.com> <818530950.24215144.1384545320058.JavaMail.root@redhat.com> <1823479187.6503546.1384547170244.JavaMail.root@redhat.com> <334673294.24303285.1384551135090.JavaMail.root@redhat.com> Message-ID: <565287605.35193335.1384780377722.JavaMail.root@redhat.com> Hi, Those are very nice mockups :) I still think it's TOO MUCH information. I spoke with many workers here regarding this issue. First: None of the PMs here know about this new feature. Why? What we have now is a screen with too much noise. As I see it, most of the users comes to the VM?s screen for creating/modifying VMs, not for Monitoring. The extra information, completely grabs the attention. Just imagine the screen when all the data refreshes (fast and slow animations enclosed) I do think we need a Monitor or even a Trend view, we can hook on the lower tab platform and show the info per VM. Another option is rollover the vm and gaining the bar as a tooltip. We can then show a monitor or a bigger reasonable x axis scale (even 24 hrs), the data can be grabbed from Jasper as well. In case this is not enough, we can do something with the monitor tab or even create a new view dedicated for monitoring. BTW, after talking with Miky Keneth, the following issue was risen: Should we show the cpu/mem/net according to the Guest perspective or as a percentage of the Host (VMware shows both) Eldan ----- Original Message ----- From: "Malini Rao" To: "Einav Cohen" Cc: "Eldan Hildesheim" , "engine-devel" , "info" , "Michal Skrivanek" Sent: Friday, November 15, 2013 11:32:15 PM Subject: Re: [Engine-devel] [UX] how to design a bar/line chart? Agreed! Also just as it is inaccurate to draw the sparkline in one of the other colors based on the current value, I htink it is also inaccurate to draw the sparklines in green since it has a specific meaning. I think the lines should all be dark gray or black and only the markers and the red numbers should be the color elements. -Malini ----- Original Message ----- From: "Einav Cohen" To: "Malini Rao" Cc: "Eldan Hildesheim" , "engine-devel" , "info" , "Michal Skrivanek" Sent: Friday, November 15, 2013 3:26:10 PM Subject: Re: [Engine-devel] [UX] how to design a bar/line chart? > ----- Original Message ----- > From: "Malini Rao" > Sent: Friday, November 15, 2013 2:55:20 PM > > > ----- Original Message ----- > > From: "Einav Cohen" > > To: "Malini Rao" > > Cc: "Eldan Hildesheim" , "engine-devel" > > , "info" , > > "Michal Skrivanek" > > Sent: Friday, November 15, 2013 2:32:21 PM > > Subject: Re: [Engine-devel] [UX] how to design a bar/line chart? > > > > > Also, I am glad you are always presenting current and proposed together > > > as > > > it > > > allows for effective comparison. I think it is safe to say that it is > > > easier > > > to discern the VMs that need attention in the current view than in the > > > proposed view because there is more color there than in a small dot. > > > > +1 > > > > > As an experiment, I tried to render the entire sparkline in the color of > > > the > > > current value ( See attached) - It is more effective in the scannability > > > aspect but it is painting all values in the color of the current value > > > which > > > is not technically accurate. What do you guys think? > > > > Malini, I agree with the above: it is more effective in the scannablity > > aspect, > > but misleading due to the entire trend being represented by a color that > > actually represents only the last reading. > > For better scannability without the misleading aspect, I was thinking about > > coloring the text next to the dot in the same color. we can also think > > about > > marking in bold this text when it is orange and/or red, for even better > > scannability (that will be helpful also for color-blind users). > > see attached "shaped-markers--colored-numbers.png" for demonstration (in > > this > > mock-up, I marked bold only the red text). > > I like it. But to take it even further and to remove any contrast issues > affecting readability, I would only change the color and bold the red > numbers. Rest should all be regular text. That will truly call out the ones > in the red zone which are the ones that need attention. The colored shaped > markers will still accurately reveal all other values in and their > associated status range. > What say? good idea, Malini - indeed the red ones are standing out more clearly in this case (see attached). > > > > > > thoughts? > > > > ---- > > Thanks, > > Einav > > > > ----- Original Message ----- > > > From: "Malini Rao" > > > To: "Einav Cohen" > > > Cc: "Eldan Hildesheim" , "engine-devel" > > > , "info" , > > > "Michal Skrivanek" > > > Sent: Friday, November 15, 2013 1:35:57 PM > > > Subject: Re: [Engine-devel] [UX] how to design a bar/line chart? > > > > > > ----- Original Message ----- > > > > From: "Einav Cohen" > > > > To: "Malini Rao" , "Michal Skrivanek" > > > > > > > > Cc: "Eldan Hildesheim" , "engine-devel" > > > > , "info" > > > > Sent: Thursday, November 14, 2013 4:10:54 PM > > > > Subject: Re: [Engine-devel] [UX] how to design a bar/line chart? > > > > > > > > > > ...maybe just a global setting to disable this if it gets annoying? > > > > > > It's > > > > > > a > > > > > > small feature and it's trivial to add such a setting. > > > > > > > > > > > > > @Michal: I am not sure what you mean by "disable"; if you mean "hide > > > > (the > > > > columns)", > > > > then I think that we should rely on the global "show/hide columns" > > > > feature, > > > > and > > > > not create a dedicated configuration value for these particular > > > > columns. > > > > Moreover, > > > > the global "show/hide columns" feature will allow customization per > > > > user/client, > > > > rather than a global-configuration-level customization, so each user > > > > will > > > > be > > > > able > > > > to define his view as he wishes. > > > > > > > > > I am averse to turning it off completely since it will be less than > > > > > what > > > > > they > > > > > have today but may be if they are displaying a trend, they should be > > > > > able > > > > > to > > > > > choose to only see the current value... > > > > > > > > @Malini, do you mean that they need the option to "fallback" to the > > > > current > > > > "bar" > > > > design (which reflects only the current value)? or something else? > > > > > > My preference is to choose a suitable visualization and not have any > > > other > > > view options. I think the ability to add or remove that column is > > > sufficient > > > should a user not find value in these columns. I merely suggested the > > > fall > > > back option instead of having a setting to turn these columns off > > > altogether > > > permanently. > > > > > > > > > > > > > > > ... If we have colored dots, we should possibly change the shape of > > > > > the > > > > > marker > > > > > too for each color so that color blind people can still find value on > > > > > this > > > > > as > > > > > a status indicator. > > > > > > > > I like the idea of colored dots; not sure about the different shapes > > > > though, > > > > as > > > > the dots would be pretty tiny; in the color-blind case: wouldn't it be > > > > sufficient > > > > to rely on the dot "height" + the textual value? > > > > > > I am not sure it is enough - Height and text are available for all users > > > including those that are not colorblind and the color of the dot is an > > > additional data point that they will miss out on if we didn't do the > > > shape. > > > I think even at this size, it will be easy to distinguish a circle from a > > > triangle and a square. Having more than that may be tricky.( See > > > attached) > > > > > > Also, I am glad you are always presenting current and proposed together > > > as > > > it > > > allows for effective comparison. I think it is safe to say that it is > > > easier > > > to discern the VMs that need attention in the current view than in the > > > proposed view because there is more color there than in a small dot. As > > > an > > > experiment, I tried to render the entire sparkline in the color of the > > > current value ( See attached) - It is more effective in the scannability > > > aspect but it is painting all values in the color of the current value > > > which > > > is not technically accurate. What do you guys think? > > > > > > > > > > > > > Thanks for the mock up, I think it looks great. Perhaps I'd > > > > > > consider > > > > > > lines > > > > > > instead of dots (to see the base 0, currently the line is somehow > > > > > > "in > > > > > > the > > > > > > air" and since the height is limited it may be difficult to > > > > > > distinguissh > > > > > > 20% > > > > > > from 0%), provided they are in some light color it may look ok > > > > > > > > > > I am not sure I completely understand the request here. Is there a > > > > > need > > > > > to > > > > > clearly mark the zero/baseline here? Or need multiple dots to > > > > > highlight > > > > > various values on the line? Or are we needing a band like this > > > > > (https://www.broadbandmetrics.com/download/attachments/3768372/TufteSparklne_medical.jpg?version=1&modificationDate=1362506139000) > > > > > to mark the desirable range? One thing I want to make sure we are on > > > > > the > > > > > same page is that the sparkline is definitely not a good widget to > > > > > distinguish small or accurate changes but more the current position > > > > > in > > > > > relation to the overall shape. > > > > > > > > I think that we are all on the same page here (others - please correct > > > > me > > > > if > > > > I am wrong) that only the general trend is of interest here, and not > > > > the > > > > exact > > > > values (maybe with the exception of the "last" value in each > > > > trendline). > > > > I believe that Michal was referring to axes [in particular the > > > > horizontal > > > > ('x') > > > > axis, I assume] so indeed we will have a clearer baseline for the > > > > trend. > > > > theoretically we can also have a "band", as you suggested, just need to > > > > well- > > > > define the "range" of the band so it would makes sense (not sure if > > > > easy > > > > to > > > > do). > > > > > > > > I am attaching an updated mock-up with axes (only added for the first > > > > few lines) as well as colored dots, as you (Malini) suggested above. > > > > > > I am not sure how much value the axes provide as it is still pretty hard > > > to > > > tell the difference from 0 to 20. As long as there are no negative > > > values, > > > do we really need the axes? If we do, Einav's mockup is pretty good in > > > terms > > > of representing the axes since it is not looking cluttered. > > > > > > > > > > > ---- > > > > Thanks, > > > > Einav > > > > > > > > ----- Original Message ----- > > > > > From: "Malini Rao" > > > > > To: "Michal Skrivanek" > > > > > Cc: "Eldan Hildesheim" , "engine-devel" > > > > > , "info" > > > > > Sent: Thursday, November 14, 2013 3:17:48 PM > > > > > Subject: Re: [Engine-devel] [UX] how to design a bar/line chart? > > > > > > > > > > ----- Original Message ----- > > > > > > From: "Michal Skrivanek" > > > > > > To: "Einav Cohen" > > > > > > Cc: "Malini Rao" , "Tomas Jelinek" > > > > > > , > > > > > > "Eldan Hildesheim" , > > > > > > "info" , "engine-devel" > > > > > > Sent: Thursday, November 14, 2013 2:21:03 AM > > > > > > Subject: Re: [Engine-devel] [UX] how to design a bar/line chart? > > > > > > > > > > > > > > > > > > On Nov 14, 2013, at 00:09 , Einav Cohen wrote: > > > > > > > > > > > > >> ... but we may have to see how this looks when multiple > > > > > > >> sparklines > > > > > > >> reside in columns next to each other. > > > > > > >> ... > > > > > > >> ... > > > > > > >> Is this going to fit in a row of a table? Or are we talking of a > > > > > > >> more detailed view? > > > > > > >> ... > > > > > > > > > > > > > > a concern on which I happened to briefly discuss with Eldan / > > > > > > > Malini > > > > > > > and actually somewhat raised here earlier in the thread (see > > > > > > > above): > > > > > > > Since we are adding another information "dimension" (time), we > > > > > > > are > > > > > > > actually going to display a lot more information to the user > > > > > > > within > > > > > > > the > > > > > > > CPU/MEM/NET columns, and there is a chance that the view will > > > > > > > become > > > > > > > too overloaded/confusing, and we will end up with a view that is > > > > > > > less > > > > > > > clear than the current one. > > > > > > > > > > > > Well, for that we IMHO have much bigger issue already with the fact > > > > > > we > > > > > > do > > > > > > not > > > > > > hide/show columns, and many of them do not really provide much > > > > > > value > > > > > > in > > > > > > all > > > > > > use cases. If you look at the mockup and the screenshots from users > > > > > > I've > > > > > > seen - e.g. the Display column(don't care), the Cluster (not wide > > > > > > enough, > > > > > > repetition of the same info on each line), Host(repetition of > > > > > > domain > > > > > > parts > > > > > > of FQDN) makes it overloaded already. > > > > > > > > > > Agreed and I think we should address that and some efforts in terms > > > > > of > > > > > designs are underway for some of these issues. However, I think > > > > > Einav's > > > > > point was about increasing the amount of info in each of those 3 > > > > > columns > > > > > exponentially since it is a trend and not a single value. Having said > > > > > that, > > > > > I think the trend represented as a sparkline/ trendline is not meant > > > > > to > > > > > give > > > > > you that many more datapoints - It gives you the current value and an > > > > > idea > > > > > of the trend based on the 'shape' of the trend line and not the > > > > > individual > > > > > peaks and troughs. So I think it is not that much of a leap in terms > > > > > of > > > > > the > > > > > cognitive overload. > > > > > > > > > > > Since statistics do provide some value and it keeps changing based > > > > > > on > > > > > > load > > > > > > it > > > > > > IMHO looks ok > > > > > > > > > > I think the question in my mind here is if the trendline is indeed a > > > > > better > > > > > visualization for all these three attributes? In other words, is a > > > > > trend > > > > > for > > > > > the memory as valuable as a trend for network or CPU? Or is it more > > > > > useful > > > > > for the user to see the current visualization for memory that fills > > > > > the > > > > > bar > > > > > as it gets closer to 100% and turns red? The point I am trying to > > > > > make > > > > > is > > > > > that the trendline/ sparkline is not necessarily a widget with > > > > > cognitive > > > > > overload but it is still worth considering if it is the right data > > > > > visualization for the attribute. So is it possible that only one or > > > > > more > > > > > of > > > > > these attributes is a sparkline? > > > > > > > > > > > > > > > > ...maybe just a global setting to disable this if it gets annoying? > > > > > > It's > > > > > > a > > > > > > small feature and it's trivial to add such a setting. > > > > > > > > > > I am averse to turning it off completely since it will be less than > > > > > what > > > > > they > > > > > have today but may be if they are displaying a trend, they should be > > > > > able > > > > > to > > > > > choose to only see the current value... > > > > > > > > > > > > > > > > > > > > > > > > > Just so we will have a general idea of how it will look like > > > > > > > eventually, > > > > > > > so we will be able to do a slightly more educated decision, I am > > > > > > > attaching > > > > > > > a mock-up of how it looks now compared to how it may look once > > > > > > > this > > > > > > > feature is implemented. > > > > > > > > > > Einav, the mockup looks awesome.. you beat me to it! :) Also, after > > > > > looking > > > > > at the mockup, I am less worried about the 3 sparkline columns > > > > > displaying > > > > > next to each other especially because the current value breaks the > > > > > lines > > > > > from all merging together. > > > > > > > > > > > > > > > > > > > > > > > > * In my mock-up, I followed Malini's guideline from earlier in > > > > > > > the > > > > > > > thread: > > > > > > > """ > > > > > > > One color with a dot to indicate the most recent or most relevant > > > > > > > data > > > > > > > and display its value next to the sparkline > > > > > > > """ > > > > > > > > > > I think Sparklines lend themselves less to status/ threshold > > > > > indicators > > > > > that > > > > > rely on color. One example that I found potentially acceptable is > > > > > http://chandoo.org/img/2010/introduction-to-excel-sparklines.png. In > > > > > our > > > > > case, the current value dot can be red, green or any other color > > > > > based > > > > > on > > > > > the ranges defined and the colors associated with it. If we have > > > > > colored > > > > > dots, we should possibly change the shape of the marker too for each > > > > > color > > > > > so that color blind people can still find value on this as a status > > > > > indicator. > > > > > > > > > > > > > > > > Thanks for the mock up, I think it looks great. Perhaps I'd > > > > > > consider > > > > > > lines > > > > > > instead of dots (to see the base 0, currently the line is somehow > > > > > > "in > > > > > > the > > > > > > air" and since the height is limited it may be difficult to > > > > > > distinguissh > > > > > > 20% > > > > > > from 0%), provided they are in some light color it may look ok > > > > > > > > > > I am not sure I completely understand the request here. Is there a > > > > > need > > > > > to > > > > > clearly mark the zero/baseline here? Or need multiple dots to > > > > > highlight > > > > > various values on the line? Or are we needing a band like this > > > > > (https://www.broadbandmetrics.com/download/attachments/3768372/TufteSparklne_medical.jpg?version=1&modificationDate=1362506139000) > > > > > to mark the desirable range? One thing I want to make sure we are on > > > > > the > > > > > same page is that the sparkline is definitely not a good widget to > > > > > distinguish small or accurate changes but more the current position > > > > > in > > > > > relation to the overall shape. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > * keep in mind that the view is dynamic and keeps updating once > > > > > > > it > > > > > > > receives new statistics from the backend. > > > > > > > > > > > > > > Thoughts? > > > > > > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > >> From: "Malini Rao" > > > > > > >> To: "Tomas Jelinek" > > > > > > >> Cc: "Einav Cohen" , "engine-devel" > > > > > > >> , "Eldan Hildesheim" > > > > > > >> , "info" , "Martin > > > > > > >> Polednik" > > > > > > >> > > > > > > >> 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 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? 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 at 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 at ovirt.org > > > > > > >>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel > > > > > > >>>>> > > > > > > >>>>> > > > > > > >>>>> > > > > > > >>>> > > > > > > >>> > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > Engine-devel mailing list > > > > > Engine-devel at ovirt.org > > > > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > Engine-devel mailing list > > > Engine-devel at ovirt.org > > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > > -------------- next part -------------- A non-text attachment was scrubbed... Name: bar_graph_ani2.gif Type: image/gif Size: 157660 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: bar_graph_ani3.gif Type: image/gif Size: 157699 bytes Desc: not available URL: From mpastern at redhat.com Mon Nov 18 15:10:03 2013 From: mpastern at redhat.com (Michael Pasternak) Date: Mon, 18 Nov 2013 17:10:03 +0200 Subject: [Engine-devel] move api from /api to /ovirt-engine/api In-Reply-To: <814145376.16190355.1384709531753.JavaMail.root@redhat.com> References: <201311061010.rA6AArVf013923@gerrit.ovirt.org> <5288A69A.3090704@redhat.com> <515047867.16182603.1384687431216.JavaMail.root@redhat.com> <5288B034.4010409@redhat.com> <814145376.16190355.1384709531753.JavaMail.root@redhat.com> Message-ID: <528A2DCB.5060304@redhat.com> On 11/17/2013 07:32 PM, Alon Bar-Lev wrote: > > > ----- Original Message ----- >> From: "Michael Pasternak" >> To: "Alon Bar-Lev" >> Cc: "Alexander Wels" , "engine-devel" >> Sent: Sunday, November 17, 2013 2:01:56 PM >> Subject: Re: move api from /api to /ovirt-engine/api >> >> On 11/17/2013 01:23 PM, Alon Bar-Lev wrote: >>> >>> >>> ----- Original Message ----- >>>> From: "Michael Pasternak" >>>> To: "Alon Bar-Lev" >>>> Cc: "engine-devel" >>>> Sent: Sunday, November 17, 2013 1:20:58 PM >>>> Subject: move api from /api to /ovirt-engine/api >>>> >>>> >>>> Hey Alon, >>>> >>>> i've noticed that ForwardServlet does not address URI parameters (such as >>>> query/matrix), >>>> i.e all destinations of this servlet will lack URI parameters been passed >>>> at >>>> source. >>> >>> Thanks!!!! >>> Alexander, can you please look at it? >>> >>> Michael... What do you mean URI parameters? just for me to be able to >>> investigate this today? >>> Do you mean query parameters? >> >> actually it didn't worked for me with matrix [2] so i assumed it's true for >> all URI >> params such as query [1], but it fine afaics, so it's only about [2] >> >> [1] http://localhost:8080/api/vms?search=name%3Dtest >> [2] http://localhost:8080/api/events;max=2 > > Done[3], I was not aware that this is valid and split out... Learn new thing any day :) Alon, Thanks a lot for addressing this so quick, +2 > > I hope I got this right. Working for this test case as far as I can see. > > [3] http://gerrit.ovirt.org/#/c/21335/ > >> >> thanks. >> >>> >>>> >>>> On 11/06/2013 12:10 PM, Alon Bar-Lev wrote: >>>>> Alon Bar-Lev has posted comments on this change. >>>>> >>>>> -- >>>>> To view, visit http://gerrit.ovirt.org/20786 >>>>> To unsubscribe, visit http://gerrit.ovirt.org/settings> >>>>> >>>> -- >>>> >>>> Michael Pasternak >>>> RedHat, ENG-Virtualization R&D >>>> >> >> >> -- >> >> Michael Pasternak >> RedHat, ENG-Virtualization R&D >> -- Michael Pasternak RedHat, ENG-Virtualization R&D From vszocs at redhat.com Mon Nov 18 15:59:26 2013 From: vszocs at redhat.com (Vojtech Szocs) Date: Mon, 18 Nov 2013 10:59:26 -0500 (EST) Subject: [Engine-devel] Using REST API in web UI - design proposal review call In-Reply-To: <1940499195.26037445.1384789387330.JavaMail.root@redhat.com> Message-ID: <1924281566.26064524.1384790366317.JavaMail.root@redhat.com> Hi everyone, we're moving towards using REST API in web UI (i.e. WebAdmin and UserPortal) and would like to hear your opinion on the matter. The initial meeting (conference call) is scheduled on Wednesday, November 20 at 14:30 CET / 15:30 TLV / 08:30 Boston timezone. I'll send the meeting invite with details in a separate email. Everyone is welcome to join and share his (her) thoughts. Regards, Vojtech PS: don't be scared to join just because there's "web UI" in meeting name! This is mostly about the general concept and design of oVirt SDK for JavaScript. From vszocs at redhat.com Mon Nov 18 16:00:32 2013 From: vszocs at redhat.com (Vojtech Szocs) Date: Mon, 18 Nov 2013 11:00:32 -0500 (EST) Subject: [Engine-devel] REST API in web UI - design proposal review call Message-ID: <508771249.26065157.1384790432848.JavaMail.root@redhat.com> The following is a new meeting request: Subject: REST API in web UI - design proposal review call Organizer: "Vojtech Szocs" Time: Wednesday, November 20, 2013, 2:30:00 PM - 4:30:00 PM GMT +01:00 Belgrade, Bratislava, Budapest, Ljubljana, Prague Required: Optional: engine-devel at ovirt.org *~*~*~*~*~*~*~*~*~* Hi guys, we're moving towards using REST API in web UI (i.e. WebAdmin and UserPortal) and would like to hear your opinion on the matter. This is a review call to summarize and discuss "Using REST API In Web UI" feature design proposal: http://www.ovirt.org/Features/Design/Using_REST_API_In_Web_UI Meeting agenda: - review current state, i.e. using GWT RPC - review main aspects of design proposal - discussion / feel free to ask questions anytime during the meeting Estimated duration: ~2 hrs. To join this meeting, dial into the Intercall bridge and use following conference code: 712 886 7405 # [https://www.intercallonline.com/listNumbersByCode.action?confCode=7128867405] Everyone is welcome to join and share his (her) thoughts. Regards, Vojtech -------------- next part -------------- A non-text attachment was scrubbed... Name: meeting.ics Type: text/calendar Size: 2250 bytes Desc: not available URL: From tnisan at redhat.com Mon Nov 18 16:17:23 2013 From: tnisan at redhat.com (Tal Nisan) Date: Mon, 18 Nov 2013 18:17:23 +0200 Subject: [Engine-devel] Using REST API in web UI - design proposal review call In-Reply-To: <1924281566.26064524.1384790366317.JavaMail.root@redhat.com> References: <1924281566.26064524.1384790366317.JavaMail.root@redhat.com> Message-ID: <528A3D93.2080702@redhat.com> Hi Vojtech, I think it'll be helpful for us if you'll send us a draft or some bullet points of your general idea on how you think to do this change so we'll come more prepared with opinions and ideas, that is of course unless the purpose of this meeting is to design it from scratch On 11/18/2013 05:59 PM, Vojtech Szocs wrote: > Hi everyone, > > we're moving towards using REST API in web UI (i.e. WebAdmin and UserPortal) and would like to hear your opinion on the matter. > > The initial meeting (conference call) is scheduled on Wednesday, November 20 at 14:30 CET / 15:30 TLV / 08:30 Boston timezone. > > I'll send the meeting invite with details in a separate email. Everyone is welcome to join and share his (her) thoughts. > > Regards, > Vojtech > > PS: don't be scared to join just because there's "web UI" in meeting name! This is mostly about the general concept and design of oVirt SDK for JavaScript. > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel From vszocs at redhat.com Mon Nov 18 17:55:12 2013 From: vszocs at redhat.com (Vojtech Szocs) Date: Mon, 18 Nov 2013 12:55:12 -0500 (EST) Subject: [Engine-devel] Using REST API in web UI - design proposal review call In-Reply-To: <528A3D93.2080702@redhat.com> References: <1924281566.26064524.1384790366317.JavaMail.root@redhat.com> <528A3D93.2080702@redhat.com> Message-ID: <1378071699.26162554.1384797312315.JavaMail.root@redhat.com> Hi Tal! sorry for my late response, the draft is already published and ready for review as feature design wiki here: http://www.ovirt.org/Features/Design/Using_REST_API_In_Web_UI More details should be in the meeting invite: http://lists.ovirt.org/pipermail/engine-devel/2013-November/005947.html Just in case, here are the important details: Meeting agenda: - review current state, i.e. using GWT RPC - review main aspects of design proposal - discussion / feel free to ask questions anytime during the meeting Estimated duration: ~2 hrs. To join this meeting, dial into the Intercall bridge and use following conference code: 712 886 7405 # [https://www.intercallonline.com/listNumbersByCode.action?confCode=7128867405] If you have any ideas/suggestions/comments feel free to let me know anytime. In any case, I'm planning to go over the wiki page during our meeting :) Regards, Vojtech ----- Original Message ----- > From: "Tal Nisan" > To: "Vojtech Szocs" > Cc: "engine-devel" > Sent: Monday, November 18, 2013 5:17:23 PM > Subject: Re: [Engine-devel] Using REST API in web UI - design proposal review call > > Hi Vojtech, > I think it'll be helpful for us if you'll send us a draft or some bullet > points of your general idea on how you think to do this change so we'll > come more prepared with opinions and ideas, that is of course unless the > purpose of this meeting is to design it from scratch > > > On 11/18/2013 05:59 PM, Vojtech Szocs wrote: > > Hi everyone, > > > > we're moving towards using REST API in web UI (i.e. WebAdmin and > > UserPortal) and would like to hear your opinion on the matter. > > > > The initial meeting (conference call) is scheduled on Wednesday, November > > 20 at 14:30 CET / 15:30 TLV / 08:30 Boston timezone. > > > > I'll send the meeting invite with details in a separate email. Everyone is > > welcome to join and share his (her) thoughts. > > > > Regards, > > Vojtech > > > > PS: don't be scared to join just because there's "web UI" in meeting name! > > This is mostly about the general concept and design of oVirt SDK for > > JavaScript. > > _______________________________________________ > > Engine-devel mailing list > > Engine-devel at ovirt.org > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > From jhernand at redhat.com Mon Nov 18 19:08:56 2013 From: jhernand at redhat.com (Juan Hernandez) Date: Mon, 18 Nov 2013 20:08:56 +0100 Subject: [Engine-devel] When is ovirt-engine expected to start supporting wildfly? In-Reply-To: <5289279D.6030405@redhat.com> References: <1543236944.25502494.1384707361919.JavaMail.root@redhat.com> <5289279D.6030405@redhat.com> Message-ID: <528A65C8.1080806@redhat.com> On 11/17/2013 09:31 PM, Itamar Heim wrote: > On 11/17/2013 06:56 PM, Mooli Tayer wrote: >> >> Thanks, >> Mooli Tayer. > > well, fedora 20 comes with wildfly (formerly JBoss AS8), so i think we > should aim for 3.4 support on fedora 20 with wildfly, but preserving > compatibility with AS7/EAP6 for other platforms. > iirc, juan has been looking at wildfly compatibility implications - juan? At the moment I have identified two issues that will prevent us from running in WildFly 8: 1. WildFly 8 changed the default web container from JBoss Web (based on Tomcat) to Undertow. This shouldn't mean much changes in the application, as we don't use Tomcat specific APIs. But in means changes in the XML configuration that we use, including changes in how we configure connectors. 2. WildFly 8 comes with a new version of Resteasy, and we do use some Resteasy specific APIs. We will need minor changes in this area. These two aren't huge issues, but I think it isn't worth going deeper before there is a release of WildFly 8. Anyhow, one can always use JBoss AS 7 or EAP in Fedora 20, it is a matter of uncompressing the JBoss .zip in some directory and setting JBOSS_HOME=/that/directory in the engine configuration. -- Direcci?n Comercial: C/Jose Bardasano Baos, 9, Edif. Gorbea 3, planta 3?D, 28016 Madrid, Spain Inscrita en el Reg. Mercantil de Madrid ? C.I.F. B82657941 - Red Hat S.L. From ecohen at redhat.com Mon Nov 18 21:19:23 2013 From: ecohen at redhat.com (Einav Cohen) Date: Mon, 18 Nov 2013 16:19:23 -0500 (EST) Subject: [Engine-devel] Weird behavior of multiple SetVmTicket query In-Reply-To: <630563857.22230004.1384256418496.JavaMail.root@redhat.com> References: <1405029090.20090071.1384159399724.JavaMail.root@redhat.com> <1757293.UZ46spY3rU@awels> <989864807.20226412.1384181602956.JavaMail.root@redhat.com> <1416897.Cty3puulVa@awels> <630563857.22230004.1384256418496.JavaMail.root@redhat.com> Message-ID: <2103394455.7731737.1384809563452.JavaMail.root@redhat.com> engine-core maintainers - this one is mainly for you - see below. the most important question (I think) is: Is there any reason to not introduced a "sync" flavor of RunMultipleActions (i.e. one that will return from the backend only when all actions have been completed, similarly to RunAction)? ---- Thanks, Einav ----- Original Message ----- > From: "Vojtech Szocs" > To: awels at redhat.com > Cc: "engine-devel" > Sent: Tuesday, November 12, 2013 6:40:18 AM > Subject: Re: [Engine-devel] Weird behavior of multiple SetVmTicket query > > Forwarding this email to engine-devel so that backend maintainers are aware > of this issue. > > Looking at the code: > > - MultipleActionsRunner#Execute first creates and "validates" all commands: > > A. the "for" block which iterates over getParameters() > 1-> validate correlation ID, if OK create and add command, otherwise add > returnValue > > B the "if" block which tests getCommands().size() > 1-> if single command to execute, add its "canDoActionOnly" returnValue, > which is returnValue with canDoAction but without actual result object > 2-> if multi commands to execute, execute chunks of max. 10 threads > (sequentially, ThreadPoolUtil.invokeAll returns after all threads > complete), same returnValue as above > > C. the "if" block which tests canRunActions > 1-> all commands are executed within SINGLE THREAD due to > ThreadPoolUtil.execute(Runnable), which is kind of weird comapred to > how returnValues are prepared (see B2) > 2-> when executing command, code DOES NOT CARE about its returnValue, > i.e. returnValue was already prepared (see B) and command execution > should just update it > > The problem (I think) is that C1 starts a different thread (to execute all > commands) and immediately returns, i.e. code doesn't wait for thread to > complete. This is why returnValues are observed on frontend as inconsistent. > > Additionally, we're also mixing of two different things: canDoAction > processing and returnValues processing. IMHO this should be refactored to > make code easier to read. > > Changes done by Alex (patch attached): > > X1. returnValues changed to Collections.synchronizedList > -> this means all access to returnValues is now serial > -> iteration over synchronizedList should also be enclosed in > "synchronized (list)" block, so this: > > for (VdcReturnValueBase value : returnValues) ... > > should be this: > > synchronized (returnValues) { for (VdcReturnValueBase value : > returnValues) ... } > > X2. commented-out original command execution via > ThreadPoolUtil.execute(Runnable) > -> new RunCommands method invokes all commands each in separate thread > via ThreadPoolUtil.invokeAll > -> returnValues list is explicitly updated > > Guys, what do you think? > > Vojtech > > > ----- Original Message ----- > > From: "Alexander Wels" > > To: "Frantisek Kobzik" > > Cc: "Vojtech Szocs" > > Sent: Monday, November 11, 2013 9:19:08 PM > > Subject: Re: Weird behavior of multiple SetVmTicket query > > > > Hi, > > > > I did some debugging, and the problem is a race condition in the > > MultipleActions class. The whole class seems to have a lot of > > multi-threading > > issues but if I modify the code to wait for the results of the actions to > > return before returning the return value, everything works fine. > > > > I am attaching a patch that solves the issue at hand, but should not be > > considered a real patch. It is just to show the issue is in the back-end > > not > > the front-end code. The front-end code is just exposing an issue in the > > back- > > end > > > > Alexander > > > > On Monday, November 11, 2013 09:53:22 AM you wrote: > > > Ok, thank you very much! > > > > > > ----- Original Message ----- > > > From: "Alexander Wels" > > > To: "Frantisek Kobzik" > > > Sent: Monday, November 11, 2013 2:15:43 PM > > > Subject: Re: Weird behavior of multiple SetVmTicket query > > > > > > Frantisek, > > > > > > I had seen this before, let me test and fix it for you, it is very likely > > > my > > > patch broke that. > > > > > > Alexander > > > > > > On Monday, November 11, 2013 03:43:19 AM you wrote: > > > > Hi Alex, > > > > > > > > recently I noticed problems with invoking console for multiple VMs > > > > (select > > > > more VMs in webadmin and then hit the console btn). I was sure it > > > > worked > > > > in > > > > past so i git-bisected the master branch and I discovered that this > > > > problem > > > > is apparently caused by patch [1]. For single vm console invocation it > > > > works fine, but for multiple VMs it doesn't. > > > > > > > > I did some closer investigation with a debugger and it seems that > > > > getSucceeded() on the return val of SetVmTicket command returns false > > > > in > > > > case of multiple execution despite the fact SetVmTicketCommand sets > > > > this > > > > value to true. I suppose there is some problem with propagation of > > > > command > > > > return value from BE to FE. The same goes for the encapsulated > > > > returnValue > > > > attribute (it contains value of the generated ticket). When invoking > > > > multiple consoles it is null (although it has been filled on backend). > > > > Weird. > > > > > > > > Tomas told me you did some optimizations for multiple command > > > > executions, > > > > do you know it might cause it? Please let me know if you have any > > > > idea... > > > > > > > > Cheers, > > > > F. > > > > > > > > [1]: http://gerrit.ovirt.org/#/c/17356/ > > > > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > From vszocs at redhat.com Tue Nov 19 11:22:22 2013 From: vszocs at redhat.com (Vojtech Szocs) Date: Tue, 19 Nov 2013 06:22:22 -0500 (EST) Subject: [Engine-devel] Weird behavior of multiple SetVmTicket query In-Reply-To: <2103394455.7731737.1384809563452.JavaMail.root@redhat.com> References: <1405029090.20090071.1384159399724.JavaMail.root@redhat.com> <1757293.UZ46spY3rU@awels> <989864807.20226412.1384181602956.JavaMail.root@redhat.com> <1416897.Cty3puulVa@awels> <630563857.22230004.1384256418496.JavaMail.root@redhat.com> <2103394455.7731737.1384809563452.JavaMail.root@redhat.com> Message-ID: <1838941847.26714794.1384860142047.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Einav Cohen" > To: "Livnat Peer" , "Eli Mesika" , "Omer Frenkel" , "Doron > Fediuck" , "Oved Ourfalli" > Cc: awels at redhat.com, "engine-devel" , "Vojtech Szocs" > Sent: Monday, November 18, 2013 10:19:23 PM > Subject: Re: [Engine-devel] Weird behavior of multiple SetVmTicket query > > engine-core maintainers - this one is mainly for you - see below. > the most important question (I think) is: Is there any reason > to not introduced a "sync" flavor of RunMultipleActions (i.e. > one that will return from the backend only when all actions have > been completed, similarly to RunAction)? +1 (or in other words, the purpose behind MultipleActionsRunner line 91 -> ThreadPoolUtil.execute(...RunCommands...) -> actions invoked in separate thread and MultipleActionsRunner.Execute immediately returns) > > ---- > Thanks, > Einav > > ----- Original Message ----- > > From: "Vojtech Szocs" > > To: awels at redhat.com > > Cc: "engine-devel" > > Sent: Tuesday, November 12, 2013 6:40:18 AM > > Subject: Re: [Engine-devel] Weird behavior of multiple SetVmTicket query > > > > Forwarding this email to engine-devel so that backend maintainers are aware > > of this issue. > > > > Looking at the code: > > > > - MultipleActionsRunner#Execute first creates and "validates" all commands: > > > > A. the "for" block which iterates over getParameters() > > 1-> validate correlation ID, if OK create and add command, otherwise > > add > > returnValue > > > > B the "if" block which tests getCommands().size() > > 1-> if single command to execute, add its "canDoActionOnly" > > returnValue, > > which is returnValue with canDoAction but without actual result object > > 2-> if multi commands to execute, execute chunks of max. 10 threads > > (sequentially, ThreadPoolUtil.invokeAll returns after all threads > > complete), same returnValue as above > > > > C. the "if" block which tests canRunActions > > 1-> all commands are executed within SINGLE THREAD due to > > ThreadPoolUtil.execute(Runnable), which is kind of weird comapred to > > how returnValues are prepared (see B2) > > 2-> when executing command, code DOES NOT CARE about its returnValue, > > i.e. returnValue was already prepared (see B) and command execution > > should just update it > > > > The problem (I think) is that C1 starts a different thread (to execute all > > commands) and immediately returns, i.e. code doesn't wait for thread to > > complete. This is why returnValues are observed on frontend as > > inconsistent. > > > > Additionally, we're also mixing of two different things: canDoAction > > processing and returnValues processing. IMHO this should be refactored to > > make code easier to read. > > > > Changes done by Alex (patch attached): > > > > X1. returnValues changed to Collections.synchronizedList > > -> this means all access to returnValues is now serial > > -> iteration over synchronizedList should also be enclosed in > > "synchronized (list)" block, so this: > > > > for (VdcReturnValueBase value : returnValues) ... > > > > should be this: > > > > synchronized (returnValues) { for (VdcReturnValueBase value : > > returnValues) ... } > > > > X2. commented-out original command execution via > > ThreadPoolUtil.execute(Runnable) > > -> new RunCommands method invokes all commands each in separate thread > > via ThreadPoolUtil.invokeAll > > -> returnValues list is explicitly updated > > > > Guys, what do you think? > > > > Vojtech > > > > > > ----- Original Message ----- > > > From: "Alexander Wels" > > > To: "Frantisek Kobzik" > > > Cc: "Vojtech Szocs" > > > Sent: Monday, November 11, 2013 9:19:08 PM > > > Subject: Re: Weird behavior of multiple SetVmTicket query > > > > > > Hi, > > > > > > I did some debugging, and the problem is a race condition in the > > > MultipleActions class. The whole class seems to have a lot of > > > multi-threading > > > issues but if I modify the code to wait for the results of the actions to > > > return before returning the return value, everything works fine. > > > > > > I am attaching a patch that solves the issue at hand, but should not be > > > considered a real patch. It is just to show the issue is in the back-end > > > not > > > the front-end code. The front-end code is just exposing an issue in the > > > back- > > > end > > > > > > Alexander > > > > > > On Monday, November 11, 2013 09:53:22 AM you wrote: > > > > Ok, thank you very much! > > > > > > > > ----- Original Message ----- > > > > From: "Alexander Wels" > > > > To: "Frantisek Kobzik" > > > > Sent: Monday, November 11, 2013 2:15:43 PM > > > > Subject: Re: Weird behavior of multiple SetVmTicket query > > > > > > > > Frantisek, > > > > > > > > I had seen this before, let me test and fix it for you, it is very > > > > likely > > > > my > > > > patch broke that. > > > > > > > > Alexander > > > > > > > > On Monday, November 11, 2013 03:43:19 AM you wrote: > > > > > Hi Alex, > > > > > > > > > > recently I noticed problems with invoking console for multiple VMs > > > > > (select > > > > > more VMs in webadmin and then hit the console btn). I was sure it > > > > > worked > > > > > in > > > > > past so i git-bisected the master branch and I discovered that this > > > > > problem > > > > > is apparently caused by patch [1]. For single vm console invocation > > > > > it > > > > > works fine, but for multiple VMs it doesn't. > > > > > > > > > > I did some closer investigation with a debugger and it seems that > > > > > getSucceeded() on the return val of SetVmTicket command returns false > > > > > in > > > > > case of multiple execution despite the fact SetVmTicketCommand sets > > > > > this > > > > > value to true. I suppose there is some problem with propagation of > > > > > command > > > > > return value from BE to FE. The same goes for the encapsulated > > > > > returnValue > > > > > attribute (it contains value of the generated ticket). When invoking > > > > > multiple consoles it is null (although it has been filled on > > > > > backend). > > > > > Weird. > > > > > > > > > > Tomas told me you did some optimizations for multiple command > > > > > executions, > > > > > do you know it might cause it? Please let me know if you have any > > > > > idea... > > > > > > > > > > Cheers, > > > > > F. > > > > > > > > > > [1]: http://gerrit.ovirt.org/#/c/17356/ > > > > > > > _______________________________________________ > > Engine-devel mailing list > > Engine-devel at ovirt.org > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > From mpastern at redhat.com Tue Nov 19 13:15:46 2013 From: mpastern at redhat.com (Michael Pasternak) Date: Tue, 19 Nov 2013 15:15:46 +0200 Subject: [Engine-devel] When is ovirt-engine expected to start supporting wildfly? In-Reply-To: <528A65C8.1080806@redhat.com> References: <1543236944.25502494.1384707361919.JavaMail.root@redhat.com> <5289279D.6030405@redhat.com> <528A65C8.1080806@redhat.com> Message-ID: <528B6482.9020800@redhat.com> On 11/18/2013 09:08 PM, Juan Hernandez wrote: > On 11/17/2013 09:31 PM, Itamar Heim wrote: >> On 11/17/2013 06:56 PM, Mooli Tayer wrote: >>> >>> Thanks, >>> Mooli Tayer. >> >> well, fedora 20 comes with wildfly (formerly JBoss AS8), so i think we >> should aim for 3.4 support on fedora 20 with wildfly, but preserving >> compatibility with AS7/EAP6 for other platforms. >> iirc, juan has been looking at wildfly compatibility implications - juan? > > At the moment I have identified two issues that will prevent us from > running in WildFly 8: > > 1. WildFly 8 changed the default web container from JBoss Web (based on > Tomcat) to Undertow. This shouldn't mean much changes in the > application, as we don't use Tomcat specific APIs. But in means changes > in the XML configuration that we use, including changes in how we > configure connectors. > > 2. WildFly 8 comes with a new version of Resteasy, and we do use some > Resteasy specific APIs. We will need minor changes in this area. it means RESTEasy breaks backward compatibility, can you elaborate on this a bit? thanks. > > These two aren't huge issues, but I think it isn't worth going deeper > before there is a release of WildFly 8. > > Anyhow, one can always use JBoss AS 7 or EAP in Fedora 20, it is a > matter of uncompressing the JBoss .zip in some directory and setting > JBOSS_HOME=/that/directory in the engine configuration. > -- Michael Pasternak RedHat, ENG-Virtualization R&D From jhernand at redhat.com Tue Nov 19 14:08:31 2013 From: jhernand at redhat.com (Juan Hernandez) Date: Tue, 19 Nov 2013 15:08:31 +0100 Subject: [Engine-devel] When is ovirt-engine expected to start supporting wildfly? In-Reply-To: <528B6482.9020800@redhat.com> References: <1543236944.25502494.1384707361919.JavaMail.root@redhat.com> <5289279D.6030405@redhat.com> <528A65C8.1080806@redhat.com> <528B6482.9020800@redhat.com> Message-ID: <528B70DF.9070709@redhat.com> On 11/19/2013 02:15 PM, Michael Pasternak wrote: > On 11/18/2013 09:08 PM, Juan Hernandez wrote: >> On 11/17/2013 09:31 PM, Itamar Heim wrote: >>> On 11/17/2013 06:56 PM, Mooli Tayer wrote: >>>> >>>> Thanks, >>>> Mooli Tayer. >>> >>> well, fedora 20 comes with wildfly (formerly JBoss AS8), so i think we >>> should aim for 3.4 support on fedora 20 with wildfly, but preserving >>> compatibility with AS7/EAP6 for other platforms. >>> iirc, juan has been looking at wildfly compatibility implications - juan? >> >> At the moment I have identified two issues that will prevent us from >> running in WildFly 8: >> >> 1. WildFly 8 changed the default web container from JBoss Web (based on >> Tomcat) to Undertow. This shouldn't mean much changes in the >> application, as we don't use Tomcat specific APIs. But in means changes >> in the XML configuration that we use, including changes in how we >> configure connectors. >> >> 2. WildFly 8 comes with a new version of Resteasy, and we do use some >> Resteasy specific APIs. We will need minor changes in this area. > > > it means RESTEasy breaks backward compatibility, can you elaborate on this a bit? > > thanks. > Wildfly uses RESTEasy 3.x and we are currently using RESTEasy 2.x, so incompatibilities are to be expected even in the public contracts. But the problems I detected are related to some RESTEasy internal classes that we use, something like this: http://gerrit.ovirt.org/21413 Note that I didn't actually test these changes. >> >> These two aren't huge issues, but I think it isn't worth going deeper >> before there is a release of WildFly 8. >> >> Anyhow, one can always use JBoss AS 7 or EAP in Fedora 20, it is a >> matter of uncompressing the JBoss .zip in some directory and setting >> JBOSS_HOME=/that/directory in the engine configuration. >> > > -- Direcci?n Comercial: C/Jose Bardasano Baos, 9, Edif. Gorbea 3, planta 3?D, 28016 Madrid, Spain Inscrita en el Reg. Mercantil de Madrid ? C.I.F. B82657941 - Red Hat S.L. From vszocs at redhat.com Tue Nov 19 17:04:10 2013 From: vszocs at redhat.com (Vojtech Szocs) Date: Tue, 19 Nov 2013 12:04:10 -0500 (EST) Subject: [Engine-devel] Question about Engine user session timeout In-Reply-To: <528353FF.4060705@redhat.com> References: <798767402.5733756.1382363701499.JavaMail.root@redhat.com> <526618D0.9060700@redhat.com> <1591715216.6236208.1382433169405.JavaMail.root@redhat.com> <526651D6.2020900@redhat.com> <547034966.6308959.1382442271276.JavaMail.root@redhat.com> <528353FF.4060705@redhat.com> Message-ID: <1305569472.26891324.1384880650124.JavaMail.root@redhat.com> Thanks, Juan! Please see my comments inline. ----- Original Message ----- > From: "Juan Hernandez" > To: "Vojtech Szocs" , "Itamar Heim" > Cc: "engine-devel" > Sent: Wednesday, November 13, 2013 11:27:11 AM > Subject: Re: [Engine-devel] Question about Engine user session timeout > > On 10/22/2013 01:44 PM, Vojtech Szocs wrote: > > > > ----- Original Message ----- > >> From: "Itamar Heim" > >> To: "Vojtech Szocs" > >> Cc: "engine-devel" > >> Sent: Tuesday, October 22, 2013 12:22:14 PM > >> Subject: Re: [Engine-devel] Question about Engine user session timeout > >> > >> On 10/22/2013 10:12 AM, Vojtech Szocs wrote: > >>> However, as we have two distinct values for Engine session timeout, I > >>> guess > >>> my best shot is to do > >>> "min(UserSessionTimeOutInterval,UserSessionTimeOutInvalidationInterval)" > >>> and expose both via admin-only GetConfigurationValue query, but I'm not > >>> sure this is the best approach.. > >> > >> shouldn't that be sum() rather than min? > > > > IIUC, the first config value (UserSessionTimeOutInterval) represents the > > delay between Engine startup and first "cleanExpiredUsersSessions" job > > execution. The second config value > > (UserSessionTimeOutInvalidationInterval) is the delay between subsequent > > executions of this job. This is why I thought it should be min() out of > > these two; user could open WebAdmin right after Engine startup or anytime > > after that. > > > > Both config values have validValues=-1,1..100000 so -1 could disable first > > (UserSessionTimeOutInterval) or subsequent > > (UserSessionTimeOutInvalidationInterval) job execution. I'm still confused > > why we have two values, though.. > > > >> > > I may be wrong, but I would bet that the reason for having two > configuration options is that the method of the scheduler that we use > requires those two parameters. Yes, this makes sense, feels like some general pattern to have scheduled jobs (of whatever kind) parametrized via two parameters, which are just delegated to actual scheduler method. > > As far as I can tell the only real value of the first parameter > (UserSessionTimeOutInterval) is to disable completely session cleanup if > the value is negative, and that seems mostly useless, as doing so would > generate a memory leak. Agreed, "UserSessionTimeOutInterval=-1" is rather meaningless. > > I would suggest to completely remove the first parameter. I will then be > clear that for your purpose the only relevant one is the second. Sounds good to me, I'll make a separate patch to consolidate Engine user session timeout into single parameter. > > -- > Direcci?n Comercial: C/Jose Bardasano Baos, 9, Edif. Gorbea 3, planta > 3?D, 28016 Madrid, Spain > Inscrita en el Reg. Mercantil de Madrid ? C.I.F. B82657941 - Red Hat S.L. > From zhshzhou at linux.vnet.ibm.com Wed Nov 20 01:53:17 2013 From: zhshzhou at linux.vnet.ibm.com (Zhou Zheng Sheng) Date: Wed, 20 Nov 2013 09:53:17 +0800 Subject: [Engine-devel] Things to be done to support Ubuntu hosts In-Reply-To: <2084307917.16057658.1384541566676.JavaMail.root@redhat.com> References: <5284744F.6010404@linux.vnet.ibm.com> <2084307917.16057658.1384541566676.JavaMail.root@redhat.com> Message-ID: <528C160D.2030509@linux.vnet.ibm.com> on 2013/11/16 02:52, Alon Bar-Lev wrote: > > > ----- Original Message ----- >> From: "Zhou Zheng Sheng" >> To: "engine-devel" >> Cc: "Itamar Heim" , "Alon Bar-Lev" >> Sent: Thursday, November 14, 2013 8:57:19 AM >> Subject: Things to be done to support Ubuntu hosts >> >> Hi, >> >> Recently Ubuntu support is added to VDSM, and .deb binray packages can >> be downloaded from launchpad.net PPA [1]. Most of the key features such >> as storage management and VM lifecycle work on Ubuntu. The cross >> distribution network management patches are upstream as well. One big >> piece left is making ovirt-host-deploy support Ubuntu, so that we can >> manage Ubuntu hosts from Engine, thus close the gap on host side. >> >> In May 2013 I made some hacks to ovirt-host-deploy and otopi. I made it >> skipped parts not supported on Ubuntu and configure the environment >> manually, and successfully added Ubuntu host to Engine [2]. >> Unfortunately I have no plans to continue on it, but I'd like to make a >> summary of the things I hacked to help anyone who wants to submit >> patches in future. I was to add a WIKI page but I found there were not >> many items, so a mail would be enough. >> >> 1. Package management operations >> Both otopi and ovirt-host-deploy query for dependency packages and >> install them on demand. The otopi package management just supports yum, >> we need to add apt-get support. Package names are different in Ubuntu, >> so I made a list mapping the names. The list in in VDSM source >> directory, debian/dependencyMap.txt . > > Please try putting the following file on host: > > /etc/ovirt-host-deploy.conf.d/10-ubuntu.conf > --- > ODEPLOY/offlinePackager=bool:True > --- > > This will replace the disable section of packaging in your patch. > It will make host-deploy not to install any package and assume all is pre-installed. > Great! Do we have plan to implement apt-get support in ovirt-host-deploy? >> >> 2. Network configuration operations >> ovirt-host-deploy asks VDSM's configNetwork.py to create bridge network. >> Cross distribution support patches for configNetwork.py are under >> review. ovirt-host-deploy supports Ubuntu bridge configuration as long >> as they are merged. > > This is not happening any more at 3.3, so no need to change anything. > > I think that in 3.3 with the above offline packaging use, you can use vanilla otopi/host-deploy. > > Regards, > Alon Bar-Lev > >> >> [1] https://launchpad.net/~zhshzhou/+archive/vdsm-ubuntu >> [2] http://www.ovirt.org/images/5/57/Shanghai-VDSM-on-Ubuntu.pdf >> >> Here goes the detailed hack patch. The hack was base on v1.0.1, I >> rebased it to the latest master. The rebased patch are not tested. If >> you find this email useless, it's actually a good news, which means >> there is not a lot of work and problems ahead ;-) >> >> Hack patch for ovirt-host-deploy. >> >> From 120493a242046d19794ef3da83b32486d372aa39 Mon Sep 17 00:00:00 2001 >> From: Zhou Zheng Sheng >> Date: Wed, 13 Nov 2013 18:02:26 +0800 >> Subject: [PATCH] Ubuntu Hacks >> >> Change-Id: Ifb4ebc829101c92d06475619b1b5986e87b83d57 >> Signed-off-by: Zhou Zheng Sheng >> --- >> src/plugins/ovirt-host-deploy/gluster/packages.py | 17 +++++---- >> src/plugins/ovirt-host-deploy/tune/tuned.py | 3 +- >> src/plugins/ovirt-host-deploy/vdsm/bridge.py | 45 >> ++++++++++++----------- >> src/plugins/ovirt-host-deploy/vdsm/packages.py | 9 +++-- >> src/plugins/ovirt-host-deploy/vdsm/pki.py | 3 +- >> src/plugins/ovirt-host-deploy/vdsm/software.py | 2 + >> src/plugins/ovirt-host-deploy/vdsm/vdsmid.py | 3 +- >> 7 files changed, 45 insertions(+), 37 deletions(-) >> >> diff --git a/src/plugins/ovirt-host-deploy/gluster/packages.py >> b/src/plugins/ovirt-host-deploy/gluster/packages.py >> index 1fecfda..eb37744 100644 >> --- a/src/plugins/ovirt-host-deploy/gluster/packages.py >> +++ b/src/plugins/ovirt-host-deploy/gluster/packages.py >> @@ -60,13 +60,13 @@ class Plugin(plugin.PluginBase): >> ), >> ) >> def _validation(self): >> - if not self.packager.queryPackages(patterns=('vdsm-gluster',)): >> - raise RuntimeError( >> - _( >> - 'Cannot locate gluster packages, ' >> - 'possible cause is incorrect channels' >> - ) >> - ) >> + # if not self.packager.queryPackages(patterns=('vdsm-gluster',)): >> + # raise RuntimeError( >> + # _( >> + # 'Cannot locate gluster packages, ' >> + # 'possible cause is incorrect channels' >> + # ) >> + # ) >> self._enabled = True >> >> @plugin.event( >> @@ -74,7 +74,8 @@ class Plugin(plugin.PluginBase): >> condition=lambda self: self._enabled, >> ) >> def _packages(self): >> - self.packager.installUpdate(('vdsm-gluster',)) >> + # self.packager.installUpdate(('vdsm-gluster',)) >> + pass >> >> @plugin.event( >> stage=plugin.Stages.STAGE_CLOSEUP, >> diff --git a/src/plugins/ovirt-host-deploy/tune/tuned.py >> b/src/plugins/ovirt-host-deploy/tune/tuned.py >> index d8e00c5..d0dcea5 100644 >> --- a/src/plugins/ovirt-host-deploy/tune/tuned.py >> +++ b/src/plugins/ovirt-host-deploy/tune/tuned.py >> @@ -70,7 +70,8 @@ class Plugin(plugin.PluginBase): >> condition=lambda self: self._enabled, >> ) >> def _packages(self): >> - self.packager.installUpdate(('tuned',)) >> + # self.packager.installUpdate(('tuned',)) >> + pass >> >> @plugin.event( >> stage=plugin.Stages.STAGE_MISC, >> diff --git a/src/plugins/ovirt-host-deploy/vdsm/bridge.py >> b/src/plugins/ovirt-host-deploy/vdsm/bridge.py >> index 3789d62..64cce40 100644 >> --- a/src/plugins/ovirt-host-deploy/vdsm/bridge.py >> +++ b/src/plugins/ovirt-host-deploy/vdsm/bridge.py >> @@ -595,7 +595,8 @@ class Plugin(plugin.PluginBase): >> stage=plugin.Stages.STAGE_INTERNAL_PACKAGES, >> ) >> def _internal_packages(self): >> - self.packager.install(packages=('iproute',)) >> + # self.packager.install(packages=('iproute',)) >> + pass >> >> @plugin.event( >> stage=plugin.Stages.STAGE_VALIDATION, >> @@ -771,27 +772,27 @@ class Plugin(plugin.PluginBase): >> interface = self._getInterfaceToInstallBasedOnDestination( >> address=self.environment[odeploycons.VdsmEnv.ENGINE_ADDRESS] >> ) >> - parameters = >> self._rhel_getInterfaceConfigParameters(name=interface) >> - >> - # The followin can be executed >> - # only at node as we won't reach here >> - # if we are not running on node >> - if ( >> - self.environment[odeploycons.VdsmEnv.OVIRT_NODE] and >> - self._interfaceIsBridge(name=interface) >> - ): >> - nic = interface.replace('br', '', 1) >> - self._removeBridge( >> - name=interface, >> - interface=nic, >> - ) >> - interface = nic >> - >> - self._createBridge( >> - >> name=self.environment[odeploycons.VdsmEnv.MANAGEMENT_BRIDGE_NAME], >> - interface=interface, >> - parameters=parameters, >> - ) >> + # parameters = >> self._rhel_getInterfaceConfigParameters(name=interface) >> + >> + # # The followin can be executed >> + # # only at node as we won't reach here >> + # # if we are not running on node >> + # if ( >> + # self.environment[odeploycons.VdsmEnv.OVIRT_NODE] and >> + # self._interfaceIsBridge(name=interface) >> + # ): >> + # nic = interface.replace('br', '', 1) >> + # self._removeBridge( >> + # name=interface, >> + # interface=nic, >> + # ) >> + # interface = nic >> + >> + # self._createBridge( >> + # >> name=self.environment[odeploycons.VdsmEnv.MANAGEMENT_BRIDGE_NAME], >> + # interface=interface, >> + # parameters=parameters, >> + # ) >> >> self._waitForRoute( >> host=( >> diff --git a/src/plugins/ovirt-host-deploy/vdsm/packages.py >> b/src/plugins/ovirt-host-deploy/vdsm/packages.py >> index d819caa..b526d4b 100644 >> --- a/src/plugins/ovirt-host-deploy/vdsm/packages.py >> +++ b/src/plugins/ovirt-host-deploy/vdsm/packages.py >> @@ -68,7 +68,8 @@ class Plugin(plugin.PluginBase): >> stage=plugin.Stages.STAGE_VALIDATION, >> ) >> def _validation(self): >> - result = self.packager.queryPackages(patterns=('vdsm',)) >> + # result = self.packager.queryPackages(patterns=('vdsm',)) >> + result = ({'version': '4.10.3', 'release': '1'},) >> if not result: >> raise RuntimeError( >> _( >> @@ -106,8 +107,8 @@ class Plugin(plugin.PluginBase): >> self.services.state('vdsmd', False) >> if self.services.exists('supervdsmd'): >> self.services.state('supervdsmd', False) >> - self.packager.install(('qemu-kvm-tools',)) >> - self.packager.installUpdate(('vdsm', 'vdsm-cli')) >> + # self.packager.install(('qemu-kvm-tools',)) >> + # self.packager.installUpdate(('vdsm', 'vdsm-cli')) >> >> @plugin.event( >> stage=plugin.Stages.STAGE_CLOSEUP, >> @@ -119,7 +120,7 @@ class Plugin(plugin.PluginBase): >> self.services.state('libvirt-guests', False) >> self.services.startup('libvirt-guests', False) >> >> - self.services.startup('vdsmd', True) >> + # self.services.startup('vdsmd', True) >> if not self.services.supportsDependency: >> if self.services.exists('libvirtd'): >> self.services.startup('libvirtd', True) >> diff --git a/src/plugins/ovirt-host-deploy/vdsm/pki.py >> b/src/plugins/ovirt-host-deploy/vdsm/pki.py >> index f374a99..c013527 100644 >> --- a/src/plugins/ovirt-host-deploy/vdsm/pki.py >> +++ b/src/plugins/ovirt-host-deploy/vdsm/pki.py >> @@ -208,7 +208,8 @@ class Plugin(plugin.PluginBase): >> condition=lambda self: self._enabled, >> ) >> def _packages(self): >> - self.packager.install(('m2crypto',)) >> + # self.packager.install(('m2crypto',)) >> + pass >> >> @plugin.event( >> stage=plugin.Stages.STAGE_MISC, >> diff --git a/src/plugins/ovirt-host-deploy/vdsm/software.py >> b/src/plugins/ovirt-host-deploy/vdsm/software.py >> index 2f0ec80..a226816 100644 >> --- a/src/plugins/ovirt-host-deploy/vdsm/software.py >> +++ b/src/plugins/ovirt-host-deploy/vdsm/software.py >> @@ -65,6 +65,8 @@ class Plugin(plugin.PluginBase): >> version=ver, >> ) >> ) >> + elif dist == 'Ubuntu': >> + pass >> else: >> raise RuntimeError( >> _('Distribution {distribution} is not supported').format( >> diff --git a/src/plugins/ovirt-host-deploy/vdsm/vdsmid.py >> b/src/plugins/ovirt-host-deploy/vdsm/vdsmid.py >> index 328ad17..465212a 100644 >> --- a/src/plugins/ovirt-host-deploy/vdsm/vdsmid.py >> +++ b/src/plugins/ovirt-host-deploy/vdsm/vdsmid.py >> @@ -78,7 +78,8 @@ class Plugin(plugin.PluginBase): >> ) >> def _packages(self): >> if platform.machine() in ('x86_64', 'i686'): >> - self.packager.install(('dmidecode',)) >> + # self.packager.install(('dmidecode',)) >> + pass >> >> @plugin.event( >> stage=plugin.Stages.STAGE_CUSTOMIZATION, >> -- >> 1.7.11.7 >> >> >> Hack patch for otopi. >> >> From 3e7022b740f24d8053d3e32c20fa6d492631db80 Mon Sep 17 00:00:00 2001 >> From: Zhou Zheng Sheng >> Date: Wed, 13 Nov 2013 17:55:39 +0800 >> Subject: [PATCH] Ubuntu Hacks >> >> --- >> src/plugins/otopi/network/hostname.py | 3 ++- >> 1 file changed, 2 insertions(+), 1 deletion(-) >> >> diff --git a/src/plugins/otopi/network/hostname.py >> b/src/plugins/otopi/network/hostname.py >> index bb07627..28b4866 100644 >> --- a/src/plugins/otopi/network/hostname.py >> +++ b/src/plugins/otopi/network/hostname.py >> @@ -63,7 +63,8 @@ class Plugin(plugin.PluginBase): >> stage=plugin.Stages.STAGE_INTERNAL_PACKAGES, >> ) >> def _internal_packages(self): >> - self.packager.install(packages=['iproute']) >> + # self.packager.install(packages=['iproute']) >> + pass >> >> @plugin.event( >> stage=plugin.Stages.STAGE_VALIDATION, >> -- >> 1.7.11.7 >> >> -- >> Thanks and best regards! >> >> Zhou Zheng Sheng / ??? >> E-mail: zhshzhou at linux.vnet.ibm.com >> Telephone: 86-10-82454397 >> >> > -- Thanks and best regards! Zhou Zheng Sheng / ??? E-mail: zhshzhou at linux.vnet.ibm.com Telephone: 86-10-82454397 From mkolesni at redhat.com Wed Nov 20 07:07:02 2013 From: mkolesni at redhat.com (Mike Kolesnik) Date: Wed, 20 Nov 2013 02:07:02 -0500 (EST) Subject: [Engine-devel] Fwd: Custom properties per device + vNIC profile = not working (< 3.3) In-Reply-To: <5280CE6E.1060608@redhat.com> References: <1480148973.29121435.1384156173916.JavaMail.root@redhat.com> <1043647659.27242521.1384160190166.JavaMail.root@redhat.com> <391769945.27298763.1384162681266.JavaMail.root@redhat.com> <2080457776.29191617.1384163320455.JavaMail.root@redhat.com> <5280CE6E.1060608@redhat.com> Message-ID: <42910126.37500034.1384931222012.JavaMail.root@redhat.com> ----- Original Message ----- > On 11/11/2013 11:48 AM, Mike Kolesnik wrote: > > > > ----- Original Message ----- > >> Hi Mike, > >> > >> ----- Original Message ----- > >>> From: "Mike Kolesnik" > >>> To: "engine-devel" > >>> Cc: "Barak Azulay" , "Martin Perina" > >>> , "Livnat Peer" , > >>> "Itamar Heim" > >>> Sent: Monday, November 11, 2013 8:49:33 AM > >>> Subject: Custom properties per device + vNIC profile = not working (< > >>> 3.3) > >>> > >>> Hi, > >>> > >>> I came across a situation where I wanted to define custom properties on a > >>> vNIC profile sitting under a network in a 3.2 data center. > >>> From what I saw the configuration value for custom properties > >>> (CustomDeviceProperties) is split into 4, one per each version (3.0, 3.1, > >>> 3.2, 3.3). > >>> Since vNIC profile is located under the DC tree, it takes the DC version > >>> - > >>> 3.2 in this specific case. > >> > >> Custom Device Properties were designed to be specified for each cluster > >> version > >> independently, it doesn't care about DC version. AFAIK cluster version > >> defines > >> what features are available ... > >> > >>> > >>> I tried to set the config value for 3.2 but got: > >>> $ engine-config -s > >>> CustomDeviceProperties="{type=interface;prop={myProp=[a-zA-Z0-9-]+}}" > >>> --cver=3.2 > >>> Cannot set value {type=interface;prop={myProp=[a-zA-Z0-9-]+}} to key > >>> CustomDeviceProperties. Device custom properties are not supported in > >>> version 3.2 > >>> > >>> This is already not very good, since in a 3.2 DC there can be 3.3 > >>> clusters > >>> with 3.3 hosts that do support custom device properties. > >> > >> Specify your properties for 3.3 version, since they will be used in 3.3 > >> clusters ... > >> > > > > But the effective version is the DC version as I explained. > > > > In a DC 3.0-3.3 I can have clusters which the minimal version is the DC > > version, and the maximal version is 3.3. > > For example I can have the following: > > DC - version 3.0 > > + Cluster 1 - version 3.0 > > + Cluster 2 - version 3.1 > > + Cluster 3 - version 3.2 > > + Cluster 4 - version 3.3 > > > > In this constellation, I could use custom device properties only on Cluster > > 4, but it's not possible to define them since the vNIC profile is using > > the DC version 3.0. > > So effectively this feature is not usable to me unless I use a 3.3 DC. > > > >>> > >>> I also tried to alter the config value in the DB directly, but the custom > >>> properties code ignored it since custom properties are not supported in > >>> 3.2. > >>> So, de facto, I have no reasonable way as a user to define custom device > >>> properties to use for my vNIC profiles in DC < 3.3. > >> > >> There are two configuration properties for Custom Device Properties: > >> > >> 1) SupportCustomDeviceProperties > >> - defines in what version properties are supported > >> - cannot be altered by users of course > >> > >> 2) CustomDeviceProperties > >> - holds properties specification for each version > >> - can be defined using engine-config > >> > >>> > >>> I opened the bug https://bugzilla.redhat.com/show_bug.cgi?id=1028757 for > >>> this, however I also want to discuss the situation: > >> > >> I looked at the bug and the problem is, that management network profile > >> is bound to DC and not the Cluster. And that's something we never thought > >> of > >> ... > >> > >>> > >>> 1. As a user, I can't set custom properties for level < 3.3 which is not > >>> good. > >> > >> Well, it's 3.3 feature, so it looks OK for me > >> > >>> Removing the blocking, and loading custom properties for all versions > >>> would > >>> fix the bug and allow using custom device properties for older versions, > >>> the > >>> reasonable place to block this would be running a VM (or plugging a > >>> device). > >>> Basically this is the lesser issue.. > >>> > >>> 2. I just don't see the added value of splitting the definition of the > >>> properties per level.. > >> > >> The idea behind the version splitting was: > >> > >> 1) We have a device with a feature that doesn't work correctly with > >> version > >> 3.3, > >> but it's fixed in 3.4 > >> 2) By specifying custom property per version we cane disable this feature > >> for > >> 3.3 > >> and enable for 3.4 > > > > Custom properties is not for specifying which features are enabled, there > > is a whole other mechanism for that.. > > > > Custom properties is for hooks (and other possible extensions), which by > > definition are not something that is guaranteed to exist so I see no point > > to force the user to update multiple configurations and cause confusion > > for him.. > > as martin explained, we have predefined custom properties, which are > based on the vdsm version, and hence are actually features we know to > expose or not to expose. > user-defined custom properties - are up to the admin, but we let these > be at cluster level as well to allow more granularity. There are no predefined properties here, only user defined properties. > > > > >> > >>> The custom properties are extensions which might or might not be > >>> available > >>> to > >>> a certain VM, I don't see how having different sets of custom properties > >>> per > >>> version (what version, DC version, cluster version?) would make any > >>> difference - either the VM can utilize the extension given some state of > >>> the > >>> system, or it can't, but the determining factor is not the version but > >>> rather the availability of the extension. > >>> For example, I can have a hook for vNIC altering some property installed > >>> on > >>> host A and not host B, if the VM runs on host A it will get this > >>> capability > >>> and on host B it won't, regardless the DC version the VM is in. > >>> > >>> This is not to say we shouldn't block custom properties on the > >>> engine-VDSM > >>> API level since it's only available since 3.3, but this is handled by > >>> another config value (SupportCustomDeviceProperties) which is not > >>> alterable > >>> by the user. > >>> So basically, I think splitting the value per version is over > >>> complication > >>> and see no added value to the users, just more maintenance should they > >>> choose to use this feature. > >>> > >>> Your thoughts please. > >> > >> AFAIK only network and storage team wanted to use device custom properties > >> in 3.3 version, but I'm not sure what's current usage status. > >> > >> But IMHO it's too late for 3.3 to change specification ... > > > > Since I can have cluster 3.3 in a DC < 3.3, and this is the upgrade path > > for existing users, > > I'd argue that the bug is severe enough and should be fixed asap even for > > 3.3 versions. > > please note that if you expose this at cluster level and not DC level, > you need to make sure to verify it when moving a VM between clusters in > same DC. > also, if this is somehow related to logical networks, not vnic specific, > than logical networks are DC level entities. > > OK but my point was that a custom properties is not meant to be split by versions since by definition of it, a hook might or might not exist on a given host (regardless of the host version). It only imposes more strain on the user to define possible custom properties by version.. I see no value to users in this approach, only more work and unclearness.. Mind you, hook is not a "feature" that is explicitly supported on a given version, but an extension mechanism which can have 3rd party extensions that might or might not exist on a given host, but this won't stop an action from occurring (i.e. VM would still start if a hook is missing but some custom property was sent). Also the original bug still exists because even though the vNIC is sitting at VM which is in cluster (thus in effect having access to the cluster version), the profile sits under network (which, as you mention, is DC level entity). So for the user using a DC < 3.3 there is no option to use this feature even though he can have 3.3 clusters in his DC. From iheim at redhat.com Wed Nov 20 07:24:17 2013 From: iheim at redhat.com (Itamar Heim) Date: Wed, 20 Nov 2013 09:24:17 +0200 Subject: [Engine-devel] Fwd: Custom properties per device + vNIC profile = not working (< 3.3) In-Reply-To: <42910126.37500034.1384931222012.JavaMail.root@redhat.com> References: <1480148973.29121435.1384156173916.JavaMail.root@redhat.com> <1043647659.27242521.1384160190166.JavaMail.root@redhat.com> <391769945.27298763.1384162681266.JavaMail.root@redhat.com> <2080457776.29191617.1384163320455.JavaMail.root@redhat.com> <5280CE6E.1060608@redhat.com> <42910126.37500034.1384931222012.JavaMail.root@redhat.com> Message-ID: <528C63A1.8020306@redhat.com> On 11/20/2013 09:07 AM, Mike Kolesnik wrote: > ----- Original Message ----- >> On 11/11/2013 11:48 AM, Mike Kolesnik wrote: >>> >>> ----- Original Message ----- >>>> Hi Mike, >>>> >>>> ----- Original Message ----- >>>>> From: "Mike Kolesnik" >>>>> To: "engine-devel" >>>>> Cc: "Barak Azulay" , "Martin Perina" >>>>> , "Livnat Peer" , >>>>> "Itamar Heim" >>>>> Sent: Monday, November 11, 2013 8:49:33 AM >>>>> Subject: Custom properties per device + vNIC profile = not working (< >>>>> 3.3) >>>>> >>>>> Hi, >>>>> >>>>> I came across a situation where I wanted to define custom properties on a >>>>> vNIC profile sitting under a network in a 3.2 data center. >>>>> From what I saw the configuration value for custom properties >>>>> (CustomDeviceProperties) is split into 4, one per each version (3.0, 3.1, >>>>> 3.2, 3.3). >>>>> Since vNIC profile is located under the DC tree, it takes the DC version >>>>> - >>>>> 3.2 in this specific case. >>>> >>>> Custom Device Properties were designed to be specified for each cluster >>>> version >>>> independently, it doesn't care about DC version. AFAIK cluster version >>>> defines >>>> what features are available ... >>>> >>>>> >>>>> I tried to set the config value for 3.2 but got: >>>>> $ engine-config -s >>>>> CustomDeviceProperties="{type=interface;prop={myProp=[a-zA-Z0-9-]+}}" >>>>> --cver=3.2 >>>>> Cannot set value {type=interface;prop={myProp=[a-zA-Z0-9-]+}} to key >>>>> CustomDeviceProperties. Device custom properties are not supported in >>>>> version 3.2 >>>>> >>>>> This is already not very good, since in a 3.2 DC there can be 3.3 >>>>> clusters >>>>> with 3.3 hosts that do support custom device properties. >>>> >>>> Specify your properties for 3.3 version, since they will be used in 3.3 >>>> clusters ... >>>> >>> >>> But the effective version is the DC version as I explained. >>> >>> In a DC 3.0-3.3 I can have clusters which the minimal version is the DC >>> version, and the maximal version is 3.3. >>> For example I can have the following: >>> DC - version 3.0 >>> + Cluster 1 - version 3.0 >>> + Cluster 2 - version 3.1 >>> + Cluster 3 - version 3.2 >>> + Cluster 4 - version 3.3 >>> >>> In this constellation, I could use custom device properties only on Cluster >>> 4, but it's not possible to define them since the vNIC profile is using >>> the DC version 3.0. >>> So effectively this feature is not usable to me unless I use a 3.3 DC. >>> >>>>> >>>>> I also tried to alter the config value in the DB directly, but the custom >>>>> properties code ignored it since custom properties are not supported in >>>>> 3.2. >>>>> So, de facto, I have no reasonable way as a user to define custom device >>>>> properties to use for my vNIC profiles in DC < 3.3. >>>> >>>> There are two configuration properties for Custom Device Properties: >>>> >>>> 1) SupportCustomDeviceProperties >>>> - defines in what version properties are supported >>>> - cannot be altered by users of course >>>> >>>> 2) CustomDeviceProperties >>>> - holds properties specification for each version >>>> - can be defined using engine-config >>>> >>>>> >>>>> I opened the bug https://bugzilla.redhat.com/show_bug.cgi?id=1028757 for >>>>> this, however I also want to discuss the situation: >>>> >>>> I looked at the bug and the problem is, that management network profile >>>> is bound to DC and not the Cluster. And that's something we never thought >>>> of >>>> ... >>>> >>>>> >>>>> 1. As a user, I can't set custom properties for level < 3.3 which is not >>>>> good. >>>> >>>> Well, it's 3.3 feature, so it looks OK for me >>>> >>>>> Removing the blocking, and loading custom properties for all versions >>>>> would >>>>> fix the bug and allow using custom device properties for older versions, >>>>> the >>>>> reasonable place to block this would be running a VM (or plugging a >>>>> device). >>>>> Basically this is the lesser issue.. >>>>> >>>>> 2. I just don't see the added value of splitting the definition of the >>>>> properties per level.. >>>> >>>> The idea behind the version splitting was: >>>> >>>> 1) We have a device with a feature that doesn't work correctly with >>>> version >>>> 3.3, >>>> but it's fixed in 3.4 >>>> 2) By specifying custom property per version we cane disable this feature >>>> for >>>> 3.3 >>>> and enable for 3.4 >>> >>> Custom properties is not for specifying which features are enabled, there >>> is a whole other mechanism for that.. >>> >>> Custom properties is for hooks (and other possible extensions), which by >>> definition are not something that is guaranteed to exist so I see no point >>> to force the user to update multiple configurations and cause confusion >>> for him.. >> >> as martin explained, we have predefined custom properties, which are >> based on the vdsm version, and hence are actually features we know to >> expose or not to expose. >> user-defined custom properties - are up to the admin, but we let these >> be at cluster level as well to allow more granularity. > > There are no predefined properties here, only user defined properties. > >> >>> >>>> >>>>> The custom properties are extensions which might or might not be >>>>> available >>>>> to >>>>> a certain VM, I don't see how having different sets of custom properties >>>>> per >>>>> version (what version, DC version, cluster version?) would make any >>>>> difference - either the VM can utilize the extension given some state of >>>>> the >>>>> system, or it can't, but the determining factor is not the version but >>>>> rather the availability of the extension. >>>>> For example, I can have a hook for vNIC altering some property installed >>>>> on >>>>> host A and not host B, if the VM runs on host A it will get this >>>>> capability >>>>> and on host B it won't, regardless the DC version the VM is in. >>>>> >>>>> This is not to say we shouldn't block custom properties on the >>>>> engine-VDSM >>>>> API level since it's only available since 3.3, but this is handled by >>>>> another config value (SupportCustomDeviceProperties) which is not >>>>> alterable >>>>> by the user. >>>>> So basically, I think splitting the value per version is over >>>>> complication >>>>> and see no added value to the users, just more maintenance should they >>>>> choose to use this feature. >>>>> >>>>> Your thoughts please. >>>> >>>> AFAIK only network and storage team wanted to use device custom properties >>>> in 3.3 version, but I'm not sure what's current usage status. >>>> >>>> But IMHO it's too late for 3.3 to change specification ... >>> >>> Since I can have cluster 3.3 in a DC < 3.3, and this is the upgrade path >>> for existing users, >>> I'd argue that the bug is severe enough and should be fixed asap even for >>> 3.3 versions. >> >> please note that if you expose this at cluster level and not DC level, >> you need to make sure to verify it when moving a VM between clusters in >> same DC. >> also, if this is somehow related to logical networks, not vnic specific, >> than logical networks are DC level entities. >> >> > > OK but my point was that a custom properties is not meant to be split by versions since > by definition of it, a hook might or might not exist on a given host (regardless of the host version). > It only imposes more strain on the user to define possible custom properties by version.. > > I see no value to users in this approach, only more work and unclearness.. > > Mind you, hook is not a "feature" that is explicitly supported on a given version, but an extension > mechanism which can have 3rd party extensions that might or might not exist on a given host, but this > won't stop an action from occurring (i.e. VM would still start if a hook is missing but some custom > property was sent). > > Also the original bug still exists because even though the vNIC is sitting at VM which is in cluster > (thus in effect having access to the cluster version), the profile sits under network (which, as you > mention, is DC level entity). > So for the user using a DC < 3.3 there is no option to use this feature even though he can have 3.3 > clusters in his DC. > except some hooks are shipped as required, and some custom properties are supported by vdsm even without hooks. so allowing to specify they are 'there' for a specific vdsm version is useful. From mkolesni at redhat.com Wed Nov 20 07:31:04 2013 From: mkolesni at redhat.com (Mike Kolesnik) Date: Wed, 20 Nov 2013 02:31:04 -0500 (EST) Subject: [Engine-devel] Fwd: Custom properties per device + vNIC profile = not working (< 3.3) In-Reply-To: <528C63A1.8020306@redhat.com> References: <1480148973.29121435.1384156173916.JavaMail.root@redhat.com> <1043647659.27242521.1384160190166.JavaMail.root@redhat.com> <391769945.27298763.1384162681266.JavaMail.root@redhat.com> <2080457776.29191617.1384163320455.JavaMail.root@redhat.com> <5280CE6E.1060608@redhat.com> <42910126.37500034.1384931222012.JavaMail.root@redhat.com> <528C63A1.8020306@redhat.com> Message-ID: <1645947092.37516409.1384932664338.JavaMail.root@redhat.com> ----- Original Message ----- > On 11/20/2013 09:07 AM, Mike Kolesnik wrote: > > ----- Original Message ----- > >> On 11/11/2013 11:48 AM, Mike Kolesnik wrote: > >>> > >>> ----- Original Message ----- > >>>> Hi Mike, > >>>> > >>>> ----- Original Message ----- > >>>>> From: "Mike Kolesnik" > >>>>> To: "engine-devel" > >>>>> Cc: "Barak Azulay" , "Martin Perina" > >>>>> , "Livnat Peer" , > >>>>> "Itamar Heim" > >>>>> Sent: Monday, November 11, 2013 8:49:33 AM > >>>>> Subject: Custom properties per device + vNIC profile = not working (< > >>>>> 3.3) > >>>>> > >>>>> Hi, > >>>>> > >>>>> I came across a situation where I wanted to define custom properties on > >>>>> a > >>>>> vNIC profile sitting under a network in a 3.2 data center. > >>>>> From what I saw the configuration value for custom properties > >>>>> (CustomDeviceProperties) is split into 4, one per each version (3.0, > >>>>> 3.1, > >>>>> 3.2, 3.3). > >>>>> Since vNIC profile is located under the DC tree, it takes the DC > >>>>> version > >>>>> - > >>>>> 3.2 in this specific case. > >>>> > >>>> Custom Device Properties were designed to be specified for each cluster > >>>> version > >>>> independently, it doesn't care about DC version. AFAIK cluster version > >>>> defines > >>>> what features are available ... > >>>> > >>>>> > >>>>> I tried to set the config value for 3.2 but got: > >>>>> $ engine-config -s > >>>>> CustomDeviceProperties="{type=interface;prop={myProp=[a-zA-Z0-9-]+}}" > >>>>> --cver=3.2 > >>>>> Cannot set value {type=interface;prop={myProp=[a-zA-Z0-9-]+}} to key > >>>>> CustomDeviceProperties. Device custom properties are not supported in > >>>>> version 3.2 > >>>>> > >>>>> This is already not very good, since in a 3.2 DC there can be 3.3 > >>>>> clusters > >>>>> with 3.3 hosts that do support custom device properties. > >>>> > >>>> Specify your properties for 3.3 version, since they will be used in 3.3 > >>>> clusters ... > >>>> > >>> > >>> But the effective version is the DC version as I explained. > >>> > >>> In a DC 3.0-3.3 I can have clusters which the minimal version is the DC > >>> version, and the maximal version is 3.3. > >>> For example I can have the following: > >>> DC - version 3.0 > >>> + Cluster 1 - version 3.0 > >>> + Cluster 2 - version 3.1 > >>> + Cluster 3 - version 3.2 > >>> + Cluster 4 - version 3.3 > >>> > >>> In this constellation, I could use custom device properties only on > >>> Cluster > >>> 4, but it's not possible to define them since the vNIC profile is using > >>> the DC version 3.0. > >>> So effectively this feature is not usable to me unless I use a 3.3 DC. > >>> > >>>>> > >>>>> I also tried to alter the config value in the DB directly, but the > >>>>> custom > >>>>> properties code ignored it since custom properties are not supported in > >>>>> 3.2. > >>>>> So, de facto, I have no reasonable way as a user to define custom > >>>>> device > >>>>> properties to use for my vNIC profiles in DC < 3.3. > >>>> > >>>> There are two configuration properties for Custom Device Properties: > >>>> > >>>> 1) SupportCustomDeviceProperties > >>>> - defines in what version properties are supported > >>>> - cannot be altered by users of course > >>>> > >>>> 2) CustomDeviceProperties > >>>> - holds properties specification for each version > >>>> - can be defined using engine-config > >>>> > >>>>> > >>>>> I opened the bug https://bugzilla.redhat.com/show_bug.cgi?id=1028757 > >>>>> for > >>>>> this, however I also want to discuss the situation: > >>>> > >>>> I looked at the bug and the problem is, that management network profile > >>>> is bound to DC and not the Cluster. And that's something we never > >>>> thought > >>>> of > >>>> ... > >>>> > >>>>> > >>>>> 1. As a user, I can't set custom properties for level < 3.3 which is > >>>>> not > >>>>> good. > >>>> > >>>> Well, it's 3.3 feature, so it looks OK for me > >>>> > >>>>> Removing the blocking, and loading custom properties for all versions > >>>>> would > >>>>> fix the bug and allow using custom device properties for older > >>>>> versions, > >>>>> the > >>>>> reasonable place to block this would be running a VM (or plugging a > >>>>> device). > >>>>> Basically this is the lesser issue.. > >>>>> > >>>>> 2. I just don't see the added value of splitting the definition of the > >>>>> properties per level.. > >>>> > >>>> The idea behind the version splitting was: > >>>> > >>>> 1) We have a device with a feature that doesn't work correctly with > >>>> version > >>>> 3.3, > >>>> but it's fixed in 3.4 > >>>> 2) By specifying custom property per version we cane disable this > >>>> feature > >>>> for > >>>> 3.3 > >>>> and enable for 3.4 > >>> > >>> Custom properties is not for specifying which features are enabled, there > >>> is a whole other mechanism for that.. > >>> > >>> Custom properties is for hooks (and other possible extensions), which by > >>> definition are not something that is guaranteed to exist so I see no > >>> point > >>> to force the user to update multiple configurations and cause confusion > >>> for him.. > >> > >> as martin explained, we have predefined custom properties, which are > >> based on the vdsm version, and hence are actually features we know to > >> expose or not to expose. > >> user-defined custom properties - are up to the admin, but we let these > >> be at cluster level as well to allow more granularity. > > > > There are no predefined properties here, only user defined properties. > > > >> > >>> > >>>> > >>>>> The custom properties are extensions which might or might not be > >>>>> available > >>>>> to > >>>>> a certain VM, I don't see how having different sets of custom > >>>>> properties > >>>>> per > >>>>> version (what version, DC version, cluster version?) would make any > >>>>> difference - either the VM can utilize the extension given some state > >>>>> of > >>>>> the > >>>>> system, or it can't, but the determining factor is not the version but > >>>>> rather the availability of the extension. > >>>>> For example, I can have a hook for vNIC altering some property > >>>>> installed > >>>>> on > >>>>> host A and not host B, if the VM runs on host A it will get this > >>>>> capability > >>>>> and on host B it won't, regardless the DC version the VM is in. > >>>>> > >>>>> This is not to say we shouldn't block custom properties on the > >>>>> engine-VDSM > >>>>> API level since it's only available since 3.3, but this is handled by > >>>>> another config value (SupportCustomDeviceProperties) which is not > >>>>> alterable > >>>>> by the user. > >>>>> So basically, I think splitting the value per version is over > >>>>> complication > >>>>> and see no added value to the users, just more maintenance should they > >>>>> choose to use this feature. > >>>>> > >>>>> Your thoughts please. > >>>> > >>>> AFAIK only network and storage team wanted to use device custom > >>>> properties > >>>> in 3.3 version, but I'm not sure what's current usage status. > >>>> > >>>> But IMHO it's too late for 3.3 to change specification ... > >>> > >>> Since I can have cluster 3.3 in a DC < 3.3, and this is the upgrade path > >>> for existing users, > >>> I'd argue that the bug is severe enough and should be fixed asap even for > >>> 3.3 versions. > >> > >> please note that if you expose this at cluster level and not DC level, > >> you need to make sure to verify it when moving a VM between clusters in > >> same DC. > >> also, if this is somehow related to logical networks, not vnic specific, > >> than logical networks are DC level entities. > >> > >> > > > > OK but my point was that a custom properties is not meant to be split by > > versions since > > by definition of it, a hook might or might not exist on a given host > > (regardless of the host version). > > It only imposes more strain on the user to define possible custom > > properties by version.. > > > > I see no value to users in this approach, only more work and unclearness.. > > > > Mind you, hook is not a "feature" that is explicitly supported on a given > > version, but an extension > > mechanism which can have 3rd party extensions that might or might not exist > > on a given host, but this > > won't stop an action from occurring (i.e. VM would still start if a hook is > > missing but some custom > > property was sent). > > > > Also the original bug still exists because even though the vNIC is sitting > > at VM which is in cluster > > (thus in effect having access to the cluster version), the profile sits > > under network (which, as you > > mention, is DC level entity). > > So for the user using a DC < 3.3 there is no option to use this feature > > even though he can have 3.3 > > clusters in his DC. > > > > except some hooks are shipped as required, and some custom properties > are supported by vdsm even without hooks. > so allowing to specify they are 'there' for a specific vdsm version is > useful. > Seems to me you're referring to things that should be in a predefined properties list, which as I mentioned doesn't exist for this feature. From iheim at redhat.com Wed Nov 20 07:32:14 2013 From: iheim at redhat.com (Itamar Heim) Date: Wed, 20 Nov 2013 09:32:14 +0200 Subject: [Engine-devel] Fwd: Custom properties per device + vNIC profile = not working (< 3.3) In-Reply-To: <1645947092.37516409.1384932664338.JavaMail.root@redhat.com> References: <1480148973.29121435.1384156173916.JavaMail.root@redhat.com> <1043647659.27242521.1384160190166.JavaMail.root@redhat.com> <391769945.27298763.1384162681266.JavaMail.root@redhat.com> <2080457776.29191617.1384163320455.JavaMail.root@redhat.com> <5280CE6E.1060608@redhat.com> <42910126.37500034.1384931222012.JavaMail.root@redhat.com> <528C63A1.8020306@redhat.com> <1645947092.37516409.1384932664338.JavaMail.root@redhat.com> Message-ID: <528C657E.3040908@redhat.com> On 11/20/2013 09:31 AM, Mike Kolesnik wrote: > > ----- Original Message ----- >> On 11/20/2013 09:07 AM, Mike Kolesnik wrote: >>> ----- Original Message ----- >>>> On 11/11/2013 11:48 AM, Mike Kolesnik wrote: >>>>> >>>>> ----- Original Message ----- >>>>>> Hi Mike, >>>>>> >>>>>> ----- Original Message ----- >>>>>>> From: "Mike Kolesnik" >>>>>>> To: "engine-devel" >>>>>>> Cc: "Barak Azulay" , "Martin Perina" >>>>>>> , "Livnat Peer" , >>>>>>> "Itamar Heim" >>>>>>> Sent: Monday, November 11, 2013 8:49:33 AM >>>>>>> Subject: Custom properties per device + vNIC profile = not working (< >>>>>>> 3.3) >>>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> I came across a situation where I wanted to define custom properties on >>>>>>> a >>>>>>> vNIC profile sitting under a network in a 3.2 data center. >>>>>>> From what I saw the configuration value for custom properties >>>>>>> (CustomDeviceProperties) is split into 4, one per each version (3.0, >>>>>>> 3.1, >>>>>>> 3.2, 3.3). >>>>>>> Since vNIC profile is located under the DC tree, it takes the DC >>>>>>> version >>>>>>> - >>>>>>> 3.2 in this specific case. >>>>>> >>>>>> Custom Device Properties were designed to be specified for each cluster >>>>>> version >>>>>> independently, it doesn't care about DC version. AFAIK cluster version >>>>>> defines >>>>>> what features are available ... >>>>>> >>>>>>> >>>>>>> I tried to set the config value for 3.2 but got: >>>>>>> $ engine-config -s >>>>>>> CustomDeviceProperties="{type=interface;prop={myProp=[a-zA-Z0-9-]+}}" >>>>>>> --cver=3.2 >>>>>>> Cannot set value {type=interface;prop={myProp=[a-zA-Z0-9-]+}} to key >>>>>>> CustomDeviceProperties. Device custom properties are not supported in >>>>>>> version 3.2 >>>>>>> >>>>>>> This is already not very good, since in a 3.2 DC there can be 3.3 >>>>>>> clusters >>>>>>> with 3.3 hosts that do support custom device properties. >>>>>> >>>>>> Specify your properties for 3.3 version, since they will be used in 3.3 >>>>>> clusters ... >>>>>> >>>>> >>>>> But the effective version is the DC version as I explained. >>>>> >>>>> In a DC 3.0-3.3 I can have clusters which the minimal version is the DC >>>>> version, and the maximal version is 3.3. >>>>> For example I can have the following: >>>>> DC - version 3.0 >>>>> + Cluster 1 - version 3.0 >>>>> + Cluster 2 - version 3.1 >>>>> + Cluster 3 - version 3.2 >>>>> + Cluster 4 - version 3.3 >>>>> >>>>> In this constellation, I could use custom device properties only on >>>>> Cluster >>>>> 4, but it's not possible to define them since the vNIC profile is using >>>>> the DC version 3.0. >>>>> So effectively this feature is not usable to me unless I use a 3.3 DC. >>>>> >>>>>>> >>>>>>> I also tried to alter the config value in the DB directly, but the >>>>>>> custom >>>>>>> properties code ignored it since custom properties are not supported in >>>>>>> 3.2. >>>>>>> So, de facto, I have no reasonable way as a user to define custom >>>>>>> device >>>>>>> properties to use for my vNIC profiles in DC < 3.3. >>>>>> >>>>>> There are two configuration properties for Custom Device Properties: >>>>>> >>>>>> 1) SupportCustomDeviceProperties >>>>>> - defines in what version properties are supported >>>>>> - cannot be altered by users of course >>>>>> >>>>>> 2) CustomDeviceProperties >>>>>> - holds properties specification for each version >>>>>> - can be defined using engine-config >>>>>> >>>>>>> >>>>>>> I opened the bug https://bugzilla.redhat.com/show_bug.cgi?id=1028757 >>>>>>> for >>>>>>> this, however I also want to discuss the situation: >>>>>> >>>>>> I looked at the bug and the problem is, that management network profile >>>>>> is bound to DC and not the Cluster. And that's something we never >>>>>> thought >>>>>> of >>>>>> ... >>>>>> >>>>>>> >>>>>>> 1. As a user, I can't set custom properties for level < 3.3 which is >>>>>>> not >>>>>>> good. >>>>>> >>>>>> Well, it's 3.3 feature, so it looks OK for me >>>>>> >>>>>>> Removing the blocking, and loading custom properties for all versions >>>>>>> would >>>>>>> fix the bug and allow using custom device properties for older >>>>>>> versions, >>>>>>> the >>>>>>> reasonable place to block this would be running a VM (or plugging a >>>>>>> device). >>>>>>> Basically this is the lesser issue.. >>>>>>> >>>>>>> 2. I just don't see the added value of splitting the definition of the >>>>>>> properties per level.. >>>>>> >>>>>> The idea behind the version splitting was: >>>>>> >>>>>> 1) We have a device with a feature that doesn't work correctly with >>>>>> version >>>>>> 3.3, >>>>>> but it's fixed in 3.4 >>>>>> 2) By specifying custom property per version we cane disable this >>>>>> feature >>>>>> for >>>>>> 3.3 >>>>>> and enable for 3.4 >>>>> >>>>> Custom properties is not for specifying which features are enabled, there >>>>> is a whole other mechanism for that.. >>>>> >>>>> Custom properties is for hooks (and other possible extensions), which by >>>>> definition are not something that is guaranteed to exist so I see no >>>>> point >>>>> to force the user to update multiple configurations and cause confusion >>>>> for him.. >>>> >>>> as martin explained, we have predefined custom properties, which are >>>> based on the vdsm version, and hence are actually features we know to >>>> expose or not to expose. >>>> user-defined custom properties - are up to the admin, but we let these >>>> be at cluster level as well to allow more granularity. >>> >>> There are no predefined properties here, only user defined properties. >>> >>>> >>>>> >>>>>> >>>>>>> The custom properties are extensions which might or might not be >>>>>>> available >>>>>>> to >>>>>>> a certain VM, I don't see how having different sets of custom >>>>>>> properties >>>>>>> per >>>>>>> version (what version, DC version, cluster version?) would make any >>>>>>> difference - either the VM can utilize the extension given some state >>>>>>> of >>>>>>> the >>>>>>> system, or it can't, but the determining factor is not the version but >>>>>>> rather the availability of the extension. >>>>>>> For example, I can have a hook for vNIC altering some property >>>>>>> installed >>>>>>> on >>>>>>> host A and not host B, if the VM runs on host A it will get this >>>>>>> capability >>>>>>> and on host B it won't, regardless the DC version the VM is in. >>>>>>> >>>>>>> This is not to say we shouldn't block custom properties on the >>>>>>> engine-VDSM >>>>>>> API level since it's only available since 3.3, but this is handled by >>>>>>> another config value (SupportCustomDeviceProperties) which is not >>>>>>> alterable >>>>>>> by the user. >>>>>>> So basically, I think splitting the value per version is over >>>>>>> complication >>>>>>> and see no added value to the users, just more maintenance should they >>>>>>> choose to use this feature. >>>>>>> >>>>>>> Your thoughts please. >>>>>> >>>>>> AFAIK only network and storage team wanted to use device custom >>>>>> properties >>>>>> in 3.3 version, but I'm not sure what's current usage status. >>>>>> >>>>>> But IMHO it's too late for 3.3 to change specification ... >>>>> >>>>> Since I can have cluster 3.3 in a DC < 3.3, and this is the upgrade path >>>>> for existing users, >>>>> I'd argue that the bug is severe enough and should be fixed asap even for >>>>> 3.3 versions. >>>> >>>> please note that if you expose this at cluster level and not DC level, >>>> you need to make sure to verify it when moving a VM between clusters in >>>> same DC. >>>> also, if this is somehow related to logical networks, not vnic specific, >>>> than logical networks are DC level entities. >>>> >>>> >>> >>> OK but my point was that a custom properties is not meant to be split by >>> versions since >>> by definition of it, a hook might or might not exist on a given host >>> (regardless of the host version). >>> It only imposes more strain on the user to define possible custom >>> properties by version.. >>> >>> I see no value to users in this approach, only more work and unclearness.. >>> >>> Mind you, hook is not a "feature" that is explicitly supported on a given >>> version, but an extension >>> mechanism which can have 3rd party extensions that might or might not exist >>> on a given host, but this >>> won't stop an action from occurring (i.e. VM would still start if a hook is >>> missing but some custom >>> property was sent). >>> >>> Also the original bug still exists because even though the vNIC is sitting >>> at VM which is in cluster >>> (thus in effect having access to the cluster version), the profile sits >>> under network (which, as you >>> mention, is DC level entity). >>> So for the user using a DC < 3.3 there is no option to use this feature >>> even though he can have 3.3 >>> clusters in his DC. >>> >> >> except some hooks are shipped as required, and some custom properties >> are supported by vdsm even without hooks. >> so allowing to specify they are 'there' for a specific vdsm version is >> useful. >> > > Seems to me you're referring to things that should be in a predefined properties > list, which as I mentioned doesn't exist for this feature. > 1. maybe it should. 2. still, i think the granularity isn't hurting in this case - more likely a hook will be needed, or not needed, in specific compat versions as features are added/removed from the product, even for custom hooks. From mkolesni at redhat.com Wed Nov 20 07:41:45 2013 From: mkolesni at redhat.com (Mike Kolesnik) Date: Wed, 20 Nov 2013 02:41:45 -0500 (EST) Subject: [Engine-devel] Fwd: Custom properties per device + vNIC profile = not working (< 3.3) In-Reply-To: <528C657E.3040908@redhat.com> References: <1480148973.29121435.1384156173916.JavaMail.root@redhat.com> <391769945.27298763.1384162681266.JavaMail.root@redhat.com> <2080457776.29191617.1384163320455.JavaMail.root@redhat.com> <5280CE6E.1060608@redhat.com> <42910126.37500034.1384931222012.JavaMail.root@redhat.com> <528C63A1.8020306@redhat.com> <1645947092.37516409.1384932664338.JavaMail.root@redhat.com> <528C657E.3040908@redhat.com> Message-ID: <1891919433.37518165.1384933305628.JavaMail.root@redhat.com> ----- Original Message ----- > On 11/20/2013 09:31 AM, Mike Kolesnik wrote: > > > > ----- Original Message ----- > >> On 11/20/2013 09:07 AM, Mike Kolesnik wrote: > >>> ----- Original Message ----- > >>>> On 11/11/2013 11:48 AM, Mike Kolesnik wrote: > >>>>> > >>>>> ----- Original Message ----- > >>>>>> Hi Mike, > >>>>>> > >>>>>> ----- Original Message ----- > >>>>>>> From: "Mike Kolesnik" > >>>>>>> To: "engine-devel" > >>>>>>> Cc: "Barak Azulay" , "Martin Perina" > >>>>>>> , "Livnat Peer" , > >>>>>>> "Itamar Heim" > >>>>>>> Sent: Monday, November 11, 2013 8:49:33 AM > >>>>>>> Subject: Custom properties per device + vNIC profile = not working (< > >>>>>>> 3.3) > >>>>>>> > >>>>>>> Hi, > >>>>>>> > >>>>>>> I came across a situation where I wanted to define custom properties > >>>>>>> on > >>>>>>> a > >>>>>>> vNIC profile sitting under a network in a 3.2 data center. > >>>>>>> From what I saw the configuration value for custom properties > >>>>>>> (CustomDeviceProperties) is split into 4, one per each version (3.0, > >>>>>>> 3.1, > >>>>>>> 3.2, 3.3). > >>>>>>> Since vNIC profile is located under the DC tree, it takes the DC > >>>>>>> version > >>>>>>> - > >>>>>>> 3.2 in this specific case. > >>>>>> > >>>>>> Custom Device Properties were designed to be specified for each > >>>>>> cluster > >>>>>> version > >>>>>> independently, it doesn't care about DC version. AFAIK cluster version > >>>>>> defines > >>>>>> what features are available ... > >>>>>> > >>>>>>> > >>>>>>> I tried to set the config value for 3.2 but got: > >>>>>>> $ engine-config -s > >>>>>>> CustomDeviceProperties="{type=interface;prop={myProp=[a-zA-Z0-9-]+}}" > >>>>>>> --cver=3.2 > >>>>>>> Cannot set value {type=interface;prop={myProp=[a-zA-Z0-9-]+}} to key > >>>>>>> CustomDeviceProperties. Device custom properties are not supported in > >>>>>>> version 3.2 > >>>>>>> > >>>>>>> This is already not very good, since in a 3.2 DC there can be 3.3 > >>>>>>> clusters > >>>>>>> with 3.3 hosts that do support custom device properties. > >>>>>> > >>>>>> Specify your properties for 3.3 version, since they will be used in > >>>>>> 3.3 > >>>>>> clusters ... > >>>>>> > >>>>> > >>>>> But the effective version is the DC version as I explained. > >>>>> > >>>>> In a DC 3.0-3.3 I can have clusters which the minimal version is the DC > >>>>> version, and the maximal version is 3.3. > >>>>> For example I can have the following: > >>>>> DC - version 3.0 > >>>>> + Cluster 1 - version 3.0 > >>>>> + Cluster 2 - version 3.1 > >>>>> + Cluster 3 - version 3.2 > >>>>> + Cluster 4 - version 3.3 > >>>>> > >>>>> In this constellation, I could use custom device properties only on > >>>>> Cluster > >>>>> 4, but it's not possible to define them since the vNIC profile is using > >>>>> the DC version 3.0. > >>>>> So effectively this feature is not usable to me unless I use a 3.3 DC. > >>>>> > >>>>>>> > >>>>>>> I also tried to alter the config value in the DB directly, but the > >>>>>>> custom > >>>>>>> properties code ignored it since custom properties are not supported > >>>>>>> in > >>>>>>> 3.2. > >>>>>>> So, de facto, I have no reasonable way as a user to define custom > >>>>>>> device > >>>>>>> properties to use for my vNIC profiles in DC < 3.3. > >>>>>> > >>>>>> There are two configuration properties for Custom Device Properties: > >>>>>> > >>>>>> 1) SupportCustomDeviceProperties > >>>>>> - defines in what version properties are supported > >>>>>> - cannot be altered by users of course > >>>>>> > >>>>>> 2) CustomDeviceProperties > >>>>>> - holds properties specification for each version > >>>>>> - can be defined using engine-config > >>>>>> > >>>>>>> > >>>>>>> I opened the bug https://bugzilla.redhat.com/show_bug.cgi?id=1028757 > >>>>>>> for > >>>>>>> this, however I also want to discuss the situation: > >>>>>> > >>>>>> I looked at the bug and the problem is, that management network > >>>>>> profile > >>>>>> is bound to DC and not the Cluster. And that's something we never > >>>>>> thought > >>>>>> of > >>>>>> ... > >>>>>> > >>>>>>> > >>>>>>> 1. As a user, I can't set custom properties for level < 3.3 which is > >>>>>>> not > >>>>>>> good. > >>>>>> > >>>>>> Well, it's 3.3 feature, so it looks OK for me > >>>>>> > >>>>>>> Removing the blocking, and loading custom properties for all versions > >>>>>>> would > >>>>>>> fix the bug and allow using custom device properties for older > >>>>>>> versions, > >>>>>>> the > >>>>>>> reasonable place to block this would be running a VM (or plugging a > >>>>>>> device). > >>>>>>> Basically this is the lesser issue.. > >>>>>>> > >>>>>>> 2. I just don't see the added value of splitting the definition of > >>>>>>> the > >>>>>>> properties per level.. > >>>>>> > >>>>>> The idea behind the version splitting was: > >>>>>> > >>>>>> 1) We have a device with a feature that doesn't work correctly with > >>>>>> version > >>>>>> 3.3, > >>>>>> but it's fixed in 3.4 > >>>>>> 2) By specifying custom property per version we cane disable this > >>>>>> feature > >>>>>> for > >>>>>> 3.3 > >>>>>> and enable for 3.4 > >>>>> > >>>>> Custom properties is not for specifying which features are enabled, > >>>>> there > >>>>> is a whole other mechanism for that.. > >>>>> > >>>>> Custom properties is for hooks (and other possible extensions), which > >>>>> by > >>>>> definition are not something that is guaranteed to exist so I see no > >>>>> point > >>>>> to force the user to update multiple configurations and cause confusion > >>>>> for him.. > >>>> > >>>> as martin explained, we have predefined custom properties, which are > >>>> based on the vdsm version, and hence are actually features we know to > >>>> expose or not to expose. > >>>> user-defined custom properties - are up to the admin, but we let these > >>>> be at cluster level as well to allow more granularity. > >>> > >>> There are no predefined properties here, only user defined properties. > >>> > >>>> > >>>>> > >>>>>> > >>>>>>> The custom properties are extensions which might or might not be > >>>>>>> available > >>>>>>> to > >>>>>>> a certain VM, I don't see how having different sets of custom > >>>>>>> properties > >>>>>>> per > >>>>>>> version (what version, DC version, cluster version?) would make any > >>>>>>> difference - either the VM can utilize the extension given some state > >>>>>>> of > >>>>>>> the > >>>>>>> system, or it can't, but the determining factor is not the version > >>>>>>> but > >>>>>>> rather the availability of the extension. > >>>>>>> For example, I can have a hook for vNIC altering some property > >>>>>>> installed > >>>>>>> on > >>>>>>> host A and not host B, if the VM runs on host A it will get this > >>>>>>> capability > >>>>>>> and on host B it won't, regardless the DC version the VM is in. > >>>>>>> > >>>>>>> This is not to say we shouldn't block custom properties on the > >>>>>>> engine-VDSM > >>>>>>> API level since it's only available since 3.3, but this is handled by > >>>>>>> another config value (SupportCustomDeviceProperties) which is not > >>>>>>> alterable > >>>>>>> by the user. > >>>>>>> So basically, I think splitting the value per version is over > >>>>>>> complication > >>>>>>> and see no added value to the users, just more maintenance should > >>>>>>> they > >>>>>>> choose to use this feature. > >>>>>>> > >>>>>>> Your thoughts please. > >>>>>> > >>>>>> AFAIK only network and storage team wanted to use device custom > >>>>>> properties > >>>>>> in 3.3 version, but I'm not sure what's current usage status. > >>>>>> > >>>>>> But IMHO it's too late for 3.3 to change specification ... > >>>>> > >>>>> Since I can have cluster 3.3 in a DC < 3.3, and this is the upgrade > >>>>> path > >>>>> for existing users, > >>>>> I'd argue that the bug is severe enough and should be fixed asap even > >>>>> for > >>>>> 3.3 versions. > >>>> > >>>> please note that if you expose this at cluster level and not DC level, > >>>> you need to make sure to verify it when moving a VM between clusters in > >>>> same DC. > >>>> also, if this is somehow related to logical networks, not vnic specific, > >>>> than logical networks are DC level entities. > >>>> > >>>> > >>> > >>> OK but my point was that a custom properties is not meant to be split by > >>> versions since > >>> by definition of it, a hook might or might not exist on a given host > >>> (regardless of the host version). > >>> It only imposes more strain on the user to define possible custom > >>> properties by version.. > >>> > >>> I see no value to users in this approach, only more work and > >>> unclearness.. > >>> > >>> Mind you, hook is not a "feature" that is explicitly supported on a given > >>> version, but an extension > >>> mechanism which can have 3rd party extensions that might or might not > >>> exist > >>> on a given host, but this > >>> won't stop an action from occurring (i.e. VM would still start if a hook > >>> is > >>> missing but some custom > >>> property was sent). > >>> > >>> Also the original bug still exists because even though the vNIC is > >>> sitting > >>> at VM which is in cluster > >>> (thus in effect having access to the cluster version), the profile sits > >>> under network (which, as you > >>> mention, is DC level entity). > >>> So for the user using a DC < 3.3 there is no option to use this feature > >>> even though he can have 3.3 > >>> clusters in his DC. > >>> > >> > >> except some hooks are shipped as required, and some custom properties > >> are supported by vdsm even without hooks. > >> so allowing to specify they are 'there' for a specific vdsm version is > >> useful. > >> > > > > Seems to me you're referring to things that should be in a predefined > > properties > > list, which as I mentioned doesn't exist for this feature. > > > > 1. maybe it should. > 2. still, i think the granularity isn't hurting in this case - more > likely a hook will be needed, or not needed, in specific compat versions > as features are added/removed from the product, even for custom hooks. > Since it's not possible for me to predict the future, I'd argue that simplicity is the best way to begin with, and if there is such demand in the future then we can always change the code to handle the more complicated use cases. IMHO, since currently there is no usage of this feature except vNIC profiles which is half usable due to the limitations imposed, seems fair to me to go with a simple value which is version agnostic and let the admin try this feature out. If we get requests to make this more specific then a proper design, accommodating the specific requirements that will be raised, can be thought of and implemented. The current design doesn't fit the single use case for this feature that we have. From alonbl at redhat.com Wed Nov 20 08:53:29 2013 From: alonbl at redhat.com (Alon Bar-Lev) Date: Wed, 20 Nov 2013 03:53:29 -0500 (EST) Subject: [Engine-devel] Things to be done to support Ubuntu hosts In-Reply-To: <528C160D.2030509@linux.vnet.ibm.com> References: <5284744F.6010404@linux.vnet.ibm.com> <2084307917.16057658.1384541566676.JavaMail.root@redhat.com> <528C160D.2030509@linux.vnet.ibm.com> Message-ID: <42549749.17087748.1384937609691.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Zhou Zheng Sheng" > To: "Alon Bar-Lev" > Cc: "engine-devel" > Sent: Wednesday, November 20, 2013 3:53:17 AM > Subject: Re: Things to be done to support Ubuntu hosts > > on 2013/11/16 02:52, Alon Bar-Lev wrote: > > > > > > ----- Original Message ----- > >> From: "Zhou Zheng Sheng" > >> To: "engine-devel" > >> Cc: "Itamar Heim" , "Alon Bar-Lev" > >> Sent: Thursday, November 14, 2013 8:57:19 AM > >> Subject: Things to be done to support Ubuntu hosts > >> > >> Hi, > >> > >> Recently Ubuntu support is added to VDSM, and .deb binray packages can > >> be downloaded from launchpad.net PPA [1]. Most of the key features such > >> as storage management and VM lifecycle work on Ubuntu. The cross > >> distribution network management patches are upstream as well. One big > >> piece left is making ovirt-host-deploy support Ubuntu, so that we can > >> manage Ubuntu hosts from Engine, thus close the gap on host side. > >> > >> In May 2013 I made some hacks to ovirt-host-deploy and otopi. I made it > >> skipped parts not supported on Ubuntu and configure the environment > >> manually, and successfully added Ubuntu host to Engine [2]. > >> Unfortunately I have no plans to continue on it, but I'd like to make a > >> summary of the things I hacked to help anyone who wants to submit > >> patches in future. I was to add a WIKI page but I found there were not > >> many items, so a mail would be enough. > >> > >> 1. Package management operations > >> Both otopi and ovirt-host-deploy query for dependency packages and > >> install them on demand. The otopi package management just supports yum, > >> we need to add apt-get support. Package names are different in Ubuntu, > >> so I made a list mapping the names. The list in in VDSM source > >> directory, debian/dependencyMap.txt . > > > > Please try putting the following file on host: > > > > /etc/ovirt-host-deploy.conf.d/10-ubuntu.conf > > --- > > ODEPLOY/offlinePackager=bool:True > > --- > > > > This will replace the disable section of packaging in your patch. > > It will make host-deploy not to install any package and assume all is > > pre-installed. > > > > Great! Do we have plan to implement apt-get support in ovirt-host-deploy? Plans - yes. Not sure when exactly. I prefer first to handle the ovirt-engine porting to ubuntu at first opportunity. > > >> > >> 2. Network configuration operations > >> ovirt-host-deploy asks VDSM's configNetwork.py to create bridge network. > >> Cross distribution support patches for configNetwork.py are under > >> review. ovirt-host-deploy supports Ubuntu bridge configuration as long > >> as they are merged. > > > > This is not happening any more at 3.3, so no need to change anything. > > > > I think that in 3.3 with the above offline packaging use, you can use > > vanilla otopi/host-deploy. > > > > Regards, > > Alon Bar-Lev > > > >> > >> [1] https://launchpad.net/~zhshzhou/+archive/vdsm-ubuntu > >> [2] http://www.ovirt.org/images/5/57/Shanghai-VDSM-on-Ubuntu.pdf > >> > >> Here goes the detailed hack patch. The hack was base on v1.0.1, I > >> rebased it to the latest master. The rebased patch are not tested. If > >> you find this email useless, it's actually a good news, which means > >> there is not a lot of work and problems ahead ;-) > >> > >> Hack patch for ovirt-host-deploy. > >> > >> From 120493a242046d19794ef3da83b32486d372aa39 Mon Sep 17 00:00:00 2001 > >> From: Zhou Zheng Sheng > >> Date: Wed, 13 Nov 2013 18:02:26 +0800 > >> Subject: [PATCH] Ubuntu Hacks > >> From asegurap at redhat.com Wed Nov 20 11:50:46 2013 From: asegurap at redhat.com (Antoni Segura Puimedon) Date: Wed, 20 Nov 2013 06:50:46 -0500 (EST) Subject: [Engine-devel] Things to be done to support Ubuntu hosts In-Reply-To: <42549749.17087748.1384937609691.JavaMail.root@redhat.com> References: <5284744F.6010404@linux.vnet.ibm.com> <2084307917.16057658.1384541566676.JavaMail.root@redhat.com> <528C160D.2030509@linux.vnet.ibm.com> <42549749.17087748.1384937609691.JavaMail.root@redhat.com> Message-ID: <251432371.17156629.1384948246787.JavaMail.root@redhat.com> Would it make sense to leverage packagekit to abstract away the distro packaging differences? http://www.packagekit.org/pk-using.html ----- Original Message ----- > From: "Alon Bar-Lev" > To: "Zhou Zheng Sheng" > Cc: "engine-devel" > Sent: Wednesday, November 20, 2013 9:53:29 AM > Subject: Re: [Engine-devel] Things to be done to support Ubuntu hosts > > > > ----- Original Message ----- > > From: "Zhou Zheng Sheng" > > To: "Alon Bar-Lev" > > Cc: "engine-devel" > > Sent: Wednesday, November 20, 2013 3:53:17 AM > > Subject: Re: Things to be done to support Ubuntu hosts > > > > on 2013/11/16 02:52, Alon Bar-Lev wrote: > > > > > > > > > ----- Original Message ----- > > >> From: "Zhou Zheng Sheng" > > >> To: "engine-devel" > > >> Cc: "Itamar Heim" , "Alon Bar-Lev" > > >> Sent: Thursday, November 14, 2013 8:57:19 AM > > >> Subject: Things to be done to support Ubuntu hosts > > >> > > >> Hi, > > >> > > >> Recently Ubuntu support is added to VDSM, and .deb binray packages can > > >> be downloaded from launchpad.net PPA [1]. Most of the key features such > > >> as storage management and VM lifecycle work on Ubuntu. The cross > > >> distribution network management patches are upstream as well. One big > > >> piece left is making ovirt-host-deploy support Ubuntu, so that we can > > >> manage Ubuntu hosts from Engine, thus close the gap on host side. > > >> > > >> In May 2013 I made some hacks to ovirt-host-deploy and otopi. I made it > > >> skipped parts not supported on Ubuntu and configure the environment > > >> manually, and successfully added Ubuntu host to Engine [2]. > > >> Unfortunately I have no plans to continue on it, but I'd like to make a > > >> summary of the things I hacked to help anyone who wants to submit > > >> patches in future. I was to add a WIKI page but I found there were not > > >> many items, so a mail would be enough. > > >> > > >> 1. Package management operations > > >> Both otopi and ovirt-host-deploy query for dependency packages and > > >> install them on demand. The otopi package management just supports yum, > > >> we need to add apt-get support. Package names are different in Ubuntu, > > >> so I made a list mapping the names. The list in in VDSM source > > >> directory, debian/dependencyMap.txt . > > > > > > Please try putting the following file on host: > > > > > > /etc/ovirt-host-deploy.conf.d/10-ubuntu.conf > > > --- > > > ODEPLOY/offlinePackager=bool:True > > > --- > > > > > > This will replace the disable section of packaging in your patch. > > > It will make host-deploy not to install any package and assume all is > > > pre-installed. > > > > > > > Great! Do we have plan to implement apt-get support in ovirt-host-deploy? > > Plans - yes. > Not sure when exactly. > I prefer first to handle the ovirt-engine porting to ubuntu at first > opportunity. > > > > > >> > > >> 2. Network configuration operations > > >> ovirt-host-deploy asks VDSM's configNetwork.py to create bridge network. > > >> Cross distribution support patches for configNetwork.py are under > > >> review. ovirt-host-deploy supports Ubuntu bridge configuration as long > > >> as they are merged. > > > > > > This is not happening any more at 3.3, so no need to change anything. > > > > > > I think that in 3.3 with the above offline packaging use, you can use > > > vanilla otopi/host-deploy. > > > > > > Regards, > > > Alon Bar-Lev > > > > > >> > > >> [1] https://launchpad.net/~zhshzhou/+archive/vdsm-ubuntu > > >> [2] http://www.ovirt.org/images/5/57/Shanghai-VDSM-on-Ubuntu.pdf > > >> > > >> Here goes the detailed hack patch. The hack was base on v1.0.1, I > > >> rebased it to the latest master. The rebased patch are not tested. If > > >> you find this email useless, it's actually a good news, which means > > >> there is not a lot of work and problems ahead ;-) > > >> > > >> Hack patch for ovirt-host-deploy. > > >> > > >> From 120493a242046d19794ef3da83b32486d372aa39 Mon Sep 17 00:00:00 2001 > > >> From: Zhou Zheng Sheng > > >> Date: Wed, 13 Nov 2013 18:02:26 +0800 > > >> Subject: [PATCH] Ubuntu Hacks > > >> > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > From alonbl at redhat.com Wed Nov 20 12:03:05 2013 From: alonbl at redhat.com (Alon Bar-Lev) Date: Wed, 20 Nov 2013 07:03:05 -0500 (EST) Subject: [Engine-devel] Things to be done to support Ubuntu hosts In-Reply-To: <251432371.17156629.1384948246787.JavaMail.root@redhat.com> References: <5284744F.6010404@linux.vnet.ibm.com> <2084307917.16057658.1384541566676.JavaMail.root@redhat.com> <528C160D.2030509@linux.vnet.ibm.com> <42549749.17087748.1384937609691.JavaMail.root@redhat.com> <251432371.17156629.1384948246787.JavaMail.root@redhat.com> Message-ID: <1543278328.17158425.1384948985880.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Antoni Segura Puimedon" > To: "Alon Bar-Lev" > Cc: "Zhou Zheng Sheng" , "engine-devel" > Sent: Wednesday, November 20, 2013 1:50:46 PM > Subject: Re: [Engine-devel] Things to be done to support Ubuntu hosts > > Would it make sense to leverage packagekit to abstract away the distro > packaging differences? http://www.packagekit.org/pk-using.html Not really... as it is egg and chicken... How do I install this package on vanilla host? And... it does not support gentoo as far as I can see :))) > > ----- Original Message ----- > > From: "Alon Bar-Lev" > > To: "Zhou Zheng Sheng" > > Cc: "engine-devel" > > Sent: Wednesday, November 20, 2013 9:53:29 AM > > Subject: Re: [Engine-devel] Things to be done to support Ubuntu hosts > > > > > > > > ----- Original Message ----- > > > From: "Zhou Zheng Sheng" > > > To: "Alon Bar-Lev" > > > Cc: "engine-devel" > > > Sent: Wednesday, November 20, 2013 3:53:17 AM > > > Subject: Re: Things to be done to support Ubuntu hosts > > > > > > on 2013/11/16 02:52, Alon Bar-Lev wrote: > > > > > > > > > > > > ----- Original Message ----- > > > >> From: "Zhou Zheng Sheng" > > > >> To: "engine-devel" > > > >> Cc: "Itamar Heim" , "Alon Bar-Lev" > > > >> > > > >> Sent: Thursday, November 14, 2013 8:57:19 AM > > > >> Subject: Things to be done to support Ubuntu hosts > > > >> > > > >> Hi, > > > >> > > > >> Recently Ubuntu support is added to VDSM, and .deb binray packages can > > > >> be downloaded from launchpad.net PPA [1]. Most of the key features > > > >> such > > > >> as storage management and VM lifecycle work on Ubuntu. The cross > > > >> distribution network management patches are upstream as well. One big > > > >> piece left is making ovirt-host-deploy support Ubuntu, so that we can > > > >> manage Ubuntu hosts from Engine, thus close the gap on host side. > > > >> > > > >> In May 2013 I made some hacks to ovirt-host-deploy and otopi. I made > > > >> it > > > >> skipped parts not supported on Ubuntu and configure the environment > > > >> manually, and successfully added Ubuntu host to Engine [2]. > > > >> Unfortunately I have no plans to continue on it, but I'd like to make > > > >> a > > > >> summary of the things I hacked to help anyone who wants to submit > > > >> patches in future. I was to add a WIKI page but I found there were not > > > >> many items, so a mail would be enough. > > > >> > > > >> 1. Package management operations > > > >> Both otopi and ovirt-host-deploy query for dependency packages and > > > >> install them on demand. The otopi package management just supports > > > >> yum, > > > >> we need to add apt-get support. Package names are different in Ubuntu, > > > >> so I made a list mapping the names. The list in in VDSM source > > > >> directory, debian/dependencyMap.txt . > > > > > > > > Please try putting the following file on host: > > > > > > > > /etc/ovirt-host-deploy.conf.d/10-ubuntu.conf > > > > --- > > > > ODEPLOY/offlinePackager=bool:True > > > > --- > > > > > > > > This will replace the disable section of packaging in your patch. > > > > It will make host-deploy not to install any package and assume all is > > > > pre-installed. > > > > > > > > > > Great! Do we have plan to implement apt-get support in ovirt-host-deploy? > > > > Plans - yes. > > Not sure when exactly. > > I prefer first to handle the ovirt-engine porting to ubuntu at first > > opportunity. > > > > > > > > >> > > > >> 2. Network configuration operations > > > >> ovirt-host-deploy asks VDSM's configNetwork.py to create bridge > > > >> network. > > > >> Cross distribution support patches for configNetwork.py are under > > > >> review. ovirt-host-deploy supports Ubuntu bridge configuration as long > > > >> as they are merged. > > > > > > > > This is not happening any more at 3.3, so no need to change anything. > > > > > > > > I think that in 3.3 with the above offline packaging use, you can use > > > > vanilla otopi/host-deploy. > > > > > > > > Regards, > > > > Alon Bar-Lev > > > > > > > >> > > > >> [1] https://launchpad.net/~zhshzhou/+archive/vdsm-ubuntu > > > >> [2] http://www.ovirt.org/images/5/57/Shanghai-VDSM-on-Ubuntu.pdf > > > >> > > > >> Here goes the detailed hack patch. The hack was base on v1.0.1, I > > > >> rebased it to the latest master. The rebased patch are not tested. If > > > >> you find this email useless, it's actually a good news, which means > > > >> there is not a lot of work and problems ahead ;-) > > > >> > > > >> Hack patch for ovirt-host-deploy. > > > >> > > > >> From 120493a242046d19794ef3da83b32486d372aa39 Mon Sep 17 00:00:00 2001 > > > >> From: Zhou Zheng Sheng > > > >> Date: Wed, 13 Nov 2013 18:02:26 +0800 > > > >> Subject: [PATCH] Ubuntu Hacks > > > >> > > _______________________________________________ > > Engine-devel mailing list > > Engine-devel at ovirt.org > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > From asegurap at redhat.com Wed Nov 20 12:30:04 2013 From: asegurap at redhat.com (Antoni Segura Puimedon) Date: Wed, 20 Nov 2013 07:30:04 -0500 (EST) Subject: [Engine-devel] Things to be done to support Ubuntu hosts In-Reply-To: <1543278328.17158425.1384948985880.JavaMail.root@redhat.com> References: <5284744F.6010404@linux.vnet.ibm.com> <2084307917.16057658.1384541566676.JavaMail.root@redhat.com> <528C160D.2030509@linux.vnet.ibm.com> <42549749.17087748.1384937609691.JavaMail.root@redhat.com> <251432371.17156629.1384948246787.JavaMail.root@redhat.com> <1543278328.17158425.1384948985880.JavaMail.root@redhat.com> Message-ID: <1163103505.17162934.1384950604828.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Alon Bar-Lev" > To: "Antoni Segura Puimedon" > Cc: "Zhou Zheng Sheng" , "engine-devel" > Sent: Wednesday, November 20, 2013 1:03:05 PM > Subject: Re: [Engine-devel] Things to be done to support Ubuntu hosts > > > > ----- Original Message ----- > > From: "Antoni Segura Puimedon" > > To: "Alon Bar-Lev" > > Cc: "Zhou Zheng Sheng" , "engine-devel" > > > > Sent: Wednesday, November 20, 2013 1:50:46 PM > > Subject: Re: [Engine-devel] Things to be done to support Ubuntu hosts > > > > Would it make sense to leverage packagekit to abstract away the distro > > packaging differences? http://www.packagekit.org/pk-using.html > > Not really... as it is egg and chicken... > How do I install this package on vanilla host? True > And... it does not support gentoo as far as I can see :))) Yeah... I guess writing a backend for gentoo's ebuilds or for Arch's AUR would be quite a challenge. > > > > > ----- Original Message ----- > > > From: "Alon Bar-Lev" > > > To: "Zhou Zheng Sheng" > > > Cc: "engine-devel" > > > Sent: Wednesday, November 20, 2013 9:53:29 AM > > > Subject: Re: [Engine-devel] Things to be done to support Ubuntu hosts > > > > > > > > > > > > ----- Original Message ----- > > > > From: "Zhou Zheng Sheng" > > > > To: "Alon Bar-Lev" > > > > Cc: "engine-devel" > > > > Sent: Wednesday, November 20, 2013 3:53:17 AM > > > > Subject: Re: Things to be done to support Ubuntu hosts > > > > > > > > on 2013/11/16 02:52, Alon Bar-Lev wrote: > > > > > > > > > > > > > > > ----- Original Message ----- > > > > >> From: "Zhou Zheng Sheng" > > > > >> To: "engine-devel" > > > > >> Cc: "Itamar Heim" , "Alon Bar-Lev" > > > > >> > > > > >> Sent: Thursday, November 14, 2013 8:57:19 AM > > > > >> Subject: Things to be done to support Ubuntu hosts > > > > >> > > > > >> Hi, > > > > >> > > > > >> Recently Ubuntu support is added to VDSM, and .deb binray packages > > > > >> can > > > > >> be downloaded from launchpad.net PPA [1]. Most of the key features > > > > >> such > > > > >> as storage management and VM lifecycle work on Ubuntu. The cross > > > > >> distribution network management patches are upstream as well. One > > > > >> big > > > > >> piece left is making ovirt-host-deploy support Ubuntu, so that we > > > > >> can > > > > >> manage Ubuntu hosts from Engine, thus close the gap on host side. > > > > >> > > > > >> In May 2013 I made some hacks to ovirt-host-deploy and otopi. I > > > > >> made > > > > >> it > > > > >> skipped parts not supported on Ubuntu and configure the environment > > > > >> manually, and successfully added Ubuntu host to Engine [2]. > > > > >> Unfortunately I have no plans to continue on it, but I'd like to > > > > >> make > > > > >> a > > > > >> summary of the things I hacked to help anyone who wants to submit > > > > >> patches in future. I was to add a WIKI page but I found there were > > > > >> not > > > > >> many items, so a mail would be enough. > > > > >> > > > > >> 1. Package management operations > > > > >> Both otopi and ovirt-host-deploy query for dependency packages and > > > > >> install them on demand. The otopi package management just supports > > > > >> yum, > > > > >> we need to add apt-get support. Package names are different in > > > > >> Ubuntu, > > > > >> so I made a list mapping the names. The list in in VDSM source > > > > >> directory, debian/dependencyMap.txt . > > > > > > > > > > Please try putting the following file on host: > > > > > > > > > > /etc/ovirt-host-deploy.conf.d/10-ubuntu.conf > > > > > --- > > > > > ODEPLOY/offlinePackager=bool:True > > > > > --- > > > > > > > > > > This will replace the disable section of packaging in your patch. > > > > > It will make host-deploy not to install any package and assume all is > > > > > pre-installed. > > > > > > > > > > > > > Great! Do we have plan to implement apt-get support in > > > > ovirt-host-deploy? > > > > > > Plans - yes. > > > Not sure when exactly. > > > I prefer first to handle the ovirt-engine porting to ubuntu at first > > > opportunity. > > > > > > > > > > > >> > > > > >> 2. Network configuration operations > > > > >> ovirt-host-deploy asks VDSM's configNetwork.py to create bridge > > > > >> network. > > > > >> Cross distribution support patches for configNetwork.py are under > > > > >> review. ovirt-host-deploy supports Ubuntu bridge configuration as > > > > >> long > > > > >> as they are merged. > > > > > > > > > > This is not happening any more at 3.3, so no need to change anything. > > > > > > > > > > I think that in 3.3 with the above offline packaging use, you can use > > > > > vanilla otopi/host-deploy. > > > > > > > > > > Regards, > > > > > Alon Bar-Lev > > > > > > > > > >> > > > > >> [1] https://launchpad.net/~zhshzhou/+archive/vdsm-ubuntu > > > > >> [2] http://www.ovirt.org/images/5/57/Shanghai-VDSM-on-Ubuntu.pdf > > > > >> > > > > >> Here goes the detailed hack patch. The hack was base on v1.0.1, I > > > > >> rebased it to the latest master. The rebased patch are not tested. > > > > >> If > > > > >> you find this email useless, it's actually a good news, which means > > > > >> there is not a lot of work and problems ahead ;-) > > > > >> > > > > >> Hack patch for ovirt-host-deploy. > > > > >> > > > > >> From 120493a242046d19794ef3da83b32486d372aa39 Mon Sep 17 00:00:00 > > > > >> 2001 > > > > >> From: Zhou Zheng Sheng > > > > >> Date: Wed, 13 Nov 2013 18:02:26 +0800 > > > > >> Subject: [PATCH] Ubuntu Hacks > > > > >> > > > _______________________________________________ > > > Engine-devel mailing list > > > Engine-devel at ovirt.org > > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > > > > From ewoud+ovirt at kohlvanwijngaarden.nl Wed Nov 20 12:49:17 2013 From: ewoud+ovirt at kohlvanwijngaarden.nl (Ewoud Kohl van Wijngaarden) Date: Wed, 20 Nov 2013 13:49:17 +0100 Subject: [Engine-devel] Things to be done to support Ubuntu hosts In-Reply-To: <1543278328.17158425.1384948985880.JavaMail.root@redhat.com> References: <5284744F.6010404@linux.vnet.ibm.com> <2084307917.16057658.1384541566676.JavaMail.root@redhat.com> <528C160D.2030509@linux.vnet.ibm.com> <42549749.17087748.1384937609691.JavaMail.root@redhat.com> <251432371.17156629.1384948246787.JavaMail.root@redhat.com> <1543278328.17158425.1384948985880.JavaMail.root@redhat.com> Message-ID: <20131120124916.GE12810@bogey.xentower.nl> On Wed, Nov 20, 2013 at 07:03:05AM -0500, Alon Bar-Lev wrote: > Antoni Segura Puimedon wrote: > > Would it make sense to leverage packagekit to abstract away the distro > > packaging differences? http://www.packagekit.org/pk-using.html > > Not really... as it is egg and chicken... > How do I install this package on vanilla host? Plus it's still likely that package names differ. I still think some abstraction here could help. Try some autodetection on package managers and prefer packagekit, then try yum, then apt-get, then aptitude for example. > And... it does not support gentoo as far as I can see :))) As a Gentoo user, I don't find this suprising. The whole concept of USE-flags looks hard to abstract away and still be compatible with all the other distributions. Especially if there's USE-dependencies in the mix. From alonbl at redhat.com Wed Nov 20 12:56:56 2013 From: alonbl at redhat.com (Alon Bar-Lev) Date: Wed, 20 Nov 2013 07:56:56 -0500 (EST) Subject: [Engine-devel] Things to be done to support Ubuntu hosts In-Reply-To: <20131120124916.GE12810@bogey.xentower.nl> References: <5284744F.6010404@linux.vnet.ibm.com> <2084307917.16057658.1384541566676.JavaMail.root@redhat.com> <528C160D.2030509@linux.vnet.ibm.com> <42549749.17087748.1384937609691.JavaMail.root@redhat.com> <251432371.17156629.1384948246787.JavaMail.root@redhat.com> <1543278328.17158425.1384948985880.JavaMail.root@redhat.com> <20131120124916.GE12810@bogey.xentower.nl> Message-ID: <1808746682.17180221.1384952216522.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Ewoud Kohl van Wijngaarden" > To: "Alon Bar-Lev" > Cc: "Antoni Segura Puimedon" , "Zhou Zheng Sheng" , "engine-devel" > > Sent: Wednesday, November 20, 2013 2:49:17 PM > Subject: Re: [Engine-devel] Things to be done to support Ubuntu hosts > > On Wed, Nov 20, 2013 at 07:03:05AM -0500, Alon Bar-Lev wrote: > > Antoni Segura Puimedon wrote: > > > Would it make sense to leverage packagekit to abstract away the distro > > > packaging differences? http://www.packagekit.org/pk-using.html > > > > Not really... as it is egg and chicken... > > How do I install this package on vanilla host? > > Plus it's still likely that package names differ. This is another issue, which I don't think that package manager abstraction solves. But it is easy to solve by adding name mapping within current host-deploy implementation. > I still think some > abstraction here could help. Try some autodetection on package managers > and prefer packagekit, then try yum, then apt-get, then aptitude for > example. It is not that easy... we currently use the yum api to be able to participate in yum transaction, we also require to manage the version lock legacy hack and we need to know before installation if we can revert to previous version. So it is not that simple to use abstraction, well, until our product will behave better, for example it will support previous database schema so that no need to run setup for upgrade and mess up with packaging. For now, I truly think that it is easier to just execute apt-get or any other tool, otopi already built under that assumption. > > > And... it does not support gentoo as far as I can see :))) > > As a Gentoo user, I don't find this suprising. The whole concept of > USE-flags looks hard to abstract away and still be compatible with all > the other distributions. Especially if there's USE-dependencies in the > mix. > From ecohen at redhat.com Mon Nov 18 19:57:13 2013 From: ecohen at redhat.com (Einav Cohen) Date: Mon, 18 Nov 2013 14:57:13 -0500 (EST) Subject: [Engine-devel] [UX] how to design a bar/line chart? In-Reply-To: <565287605.35193335.1384780377722.JavaMail.root@redhat.com> References: <157528892.18409921.1383645002815.JavaMail.root@redhat.com> <356685769.5458199.1384463454334.JavaMail.root@redhat.com> <2017675394.24155723.1384540556930.JavaMail.root@redhat.com> <1547048567.6416859.1384543941781.JavaMail.root@redhat.com> <818530950.24215144.1384545320058.JavaMail.root@redhat.com> <1823479187.6503546.1384547170244.JavaMail.root@redhat.com> <334673294.24303285.1384551135090.JavaMail.root@redhat.com> <565287605.35193335.1384780377722.JavaMail.root@redhat.com> Message-ID: <15076338.7625026.1384804633798.JavaMail.root@redhat.com> moving this discussion to the users mailing list, to get some more oVirt users' feedback this matter. context is [1]; see attached to see comparison of current state and suggestion; see below for engine-devel correspondence so far. ---- Thanks, Einav [1] Bug 803251 - improve the resource usage graph for VM cpu/memory/network [https://bugzilla.redhat.com/show_bug.cgi?id=803251] ----- Original Message ----- > From: "Eldan Hildesheim" > To: "Malini Rao" > Cc: "info" , "engine-devel" , "Michal Skrivanek" > Sent: Monday, November 18, 2013 8:12:57 AM > Subject: Re: [Engine-devel] [UX] how to design a bar/line chart? > > Hi, > Those are very nice mockups :) > > I still think it's TOO MUCH information. > I spoke with many workers here regarding this issue. > First: None of the PMs here know about this new feature. Why? > > What we have now is a screen with too much noise. > As I see it, most of the users comes to the VM?s screen for > creating/modifying VMs, not for Monitoring. > The extra information, completely grabs the attention. Just imagine the > screen when all the data refreshes (fast and slow animations enclosed) > > I do think we need a Monitor or even a Trend view, we can hook on the lower > tab platform and show the info per VM. > Another option is rollover the vm and gaining the bar as a tooltip. > We can then show a monitor or a bigger reasonable x axis scale (even 24 hrs), > the data can be grabbed from Jasper as well. > In case this is not enough, we can do something with the monitor tab or even > create a new view dedicated for monitoring. > BTW, after talking with Miky Keneth, the following issue was risen: > Should we show the cpu/mem/net according to the Guest perspective or as a > percentage of the Host (VMware shows both) > > Eldan > > > > > > > ----- Original Message ----- > From: "Malini Rao" > To: "Einav Cohen" > Cc: "Eldan Hildesheim" , "engine-devel" > , "info" , "Michal Skrivanek" > > Sent: Friday, November 15, 2013 11:32:15 PM > Subject: Re: [Engine-devel] [UX] how to design a bar/line chart? > > Agreed! Also just as it is inaccurate to draw the sparkline in one of the > other colors based on the current value, I htink it is also inaccurate to > draw the sparklines in green since it has a specific meaning. I think the > lines should all be dark gray or black and only the markers and the red > numbers should be the color elements. > > -Malini > > ----- Original Message ----- > From: "Einav Cohen" > To: "Malini Rao" > Cc: "Eldan Hildesheim" , "engine-devel" > , "info" , "Michal Skrivanek" > > Sent: Friday, November 15, 2013 3:26:10 PM > Subject: Re: [Engine-devel] [UX] how to design a bar/line chart? > > > ----- Original Message ----- > > From: "Malini Rao" > > Sent: Friday, November 15, 2013 2:55:20 PM > > > > > > ----- Original Message ----- > > > From: "Einav Cohen" > > > To: "Malini Rao" > > > Cc: "Eldan Hildesheim" , "engine-devel" > > > , "info" , > > > "Michal Skrivanek" > > > Sent: Friday, November 15, 2013 2:32:21 PM > > > Subject: Re: [Engine-devel] [UX] how to design a bar/line chart? > > > > > > > Also, I am glad you are always presenting current and proposed together > > > > as > > > > it > > > > allows for effective comparison. I think it is safe to say that it is > > > > easier > > > > to discern the VMs that need attention in the current view than in the > > > > proposed view because there is more color there than in a small dot. > > > > > > +1 > > > > > > > As an experiment, I tried to render the entire sparkline in the color > > > > of > > > > the > > > > current value ( See attached) - It is more effective in the > > > > scannability > > > > aspect but it is painting all values in the color of the current value > > > > which > > > > is not technically accurate. What do you guys think? > > > > > > Malini, I agree with the above: it is more effective in the scannablity > > > aspect, > > > but misleading due to the entire trend being represented by a color that > > > actually represents only the last reading. > > > For better scannability without the misleading aspect, I was thinking > > > about > > > coloring the text next to the dot in the same color. we can also think > > > about > > > marking in bold this text when it is orange and/or red, for even better > > > scannability (that will be helpful also for color-blind users). > > > see attached "shaped-markers--colored-numbers.png" for demonstration (in > > > this > > > mock-up, I marked bold only the red text). > > > > I like it. But to take it even further and to remove any contrast issues > > affecting readability, I would only change the color and bold the red > > numbers. Rest should all be regular text. That will truly call out the ones > > in the red zone which are the ones that need attention. The colored shaped > > markers will still accurately reveal all other values in and their > > associated status range. > > What say? > > good idea, Malini - indeed the red ones are standing out more clearly in > this case (see attached). > > > > > > > > > > > thoughts? > > > > > > ---- > > > Thanks, > > > Einav > > > > > > ----- Original Message ----- > > > > From: "Malini Rao" > > > > To: "Einav Cohen" > > > > Cc: "Eldan Hildesheim" , "engine-devel" > > > > , "info" , > > > > "Michal Skrivanek" > > > > Sent: Friday, November 15, 2013 1:35:57 PM > > > > Subject: Re: [Engine-devel] [UX] how to design a bar/line chart? > > > > > > > > ----- Original Message ----- > > > > > From: "Einav Cohen" > > > > > To: "Malini Rao" , "Michal Skrivanek" > > > > > > > > > > Cc: "Eldan Hildesheim" , "engine-devel" > > > > > , "info" > > > > > Sent: Thursday, November 14, 2013 4:10:54 PM > > > > > Subject: Re: [Engine-devel] [UX] how to design a bar/line chart? > > > > > > > > > > > > ...maybe just a global setting to disable this if it gets > > > > > > > annoying? > > > > > > > It's > > > > > > > a > > > > > > > small feature and it's trivial to add such a setting. > > > > > > > > > > > > > > > > @Michal: I am not sure what you mean by "disable"; if you mean "hide > > > > > (the > > > > > columns)", > > > > > then I think that we should rely on the global "show/hide columns" > > > > > feature, > > > > > and > > > > > not create a dedicated configuration value for these particular > > > > > columns. > > > > > Moreover, > > > > > the global "show/hide columns" feature will allow customization per > > > > > user/client, > > > > > rather than a global-configuration-level customization, so each user > > > > > will > > > > > be > > > > > able > > > > > to define his view as he wishes. > > > > > > > > > > > I am averse to turning it off completely since it will be less than > > > > > > what > > > > > > they > > > > > > have today but may be if they are displaying a trend, they should > > > > > > be > > > > > > able > > > > > > to > > > > > > choose to only see the current value... > > > > > > > > > > @Malini, do you mean that they need the option to "fallback" to the > > > > > current > > > > > "bar" > > > > > design (which reflects only the current value)? or something else? > > > > > > > > My preference is to choose a suitable visualization and not have any > > > > other > > > > view options. I think the ability to add or remove that column is > > > > sufficient > > > > should a user not find value in these columns. I merely suggested the > > > > fall > > > > back option instead of having a setting to turn these columns off > > > > altogether > > > > permanently. > > > > > > > > > > > > > > > > > > > ... If we have colored dots, we should possibly change the shape of > > > > > > the > > > > > > marker > > > > > > too for each color so that color blind people can still find value > > > > > > on > > > > > > this > > > > > > as > > > > > > a status indicator. > > > > > > > > > > I like the idea of colored dots; not sure about the different shapes > > > > > though, > > > > > as > > > > > the dots would be pretty tiny; in the color-blind case: wouldn't it > > > > > be > > > > > sufficient > > > > > to rely on the dot "height" + the textual value? > > > > > > > > I am not sure it is enough - Height and text are available for all > > > > users > > > > including those that are not colorblind and the color of the dot is an > > > > additional data point that they will miss out on if we didn't do the > > > > shape. > > > > I think even at this size, it will be easy to distinguish a circle from > > > > a > > > > triangle and a square. Having more than that may be tricky.( See > > > > attached) > > > > > > > > Also, I am glad you are always presenting current and proposed together > > > > as > > > > it > > > > allows for effective comparison. I think it is safe to say that it is > > > > easier > > > > to discern the VMs that need attention in the current view than in the > > > > proposed view because there is more color there than in a small dot. As > > > > an > > > > experiment, I tried to render the entire sparkline in the color of the > > > > current value ( See attached) - It is more effective in the > > > > scannability > > > > aspect but it is painting all values in the color of the current value > > > > which > > > > is not technically accurate. What do you guys think? > > > > > > > > > > > > > > > > Thanks for the mock up, I think it looks great. Perhaps I'd > > > > > > > consider > > > > > > > lines > > > > > > > instead of dots (to see the base 0, currently the line is somehow > > > > > > > "in > > > > > > > the > > > > > > > air" and since the height is limited it may be difficult to > > > > > > > distinguissh > > > > > > > 20% > > > > > > > from 0%), provided they are in some light color it may look ok > > > > > > > > > > > > I am not sure I completely understand the request here. Is there a > > > > > > need > > > > > > to > > > > > > clearly mark the zero/baseline here? Or need multiple dots to > > > > > > highlight > > > > > > various values on the line? Or are we needing a band like this > > > > > > (https://www.broadbandmetrics.com/download/attachments/3768372/TufteSparklne_medical.jpg?version=1&modificationDate=1362506139000) > > > > > > to mark the desirable range? One thing I want to make sure we are > > > > > > on > > > > > > the > > > > > > same page is that the sparkline is definitely not a good widget to > > > > > > distinguish small or accurate changes but more the current position > > > > > > in > > > > > > relation to the overall shape. > > > > > > > > > > I think that we are all on the same page here (others - please > > > > > correct > > > > > me > > > > > if > > > > > I am wrong) that only the general trend is of interest here, and not > > > > > the > > > > > exact > > > > > values (maybe with the exception of the "last" value in each > > > > > trendline). > > > > > I believe that Michal was referring to axes [in particular the > > > > > horizontal > > > > > ('x') > > > > > axis, I assume] so indeed we will have a clearer baseline for the > > > > > trend. > > > > > theoretically we can also have a "band", as you suggested, just need > > > > > to > > > > > well- > > > > > define the "range" of the band so it would makes sense (not sure if > > > > > easy > > > > > to > > > > > do). > > > > > > > > > > I am attaching an updated mock-up with axes (only added for the first > > > > > few lines) as well as colored dots, as you (Malini) suggested above -------------- next part -------------- A non-text attachment was scrubbed... Name: shaped-markers--red-text-bold.png Type: image/png Size: 701437 bytes Desc: not available URL: From bob at doolittle.us.com Wed Nov 20 22:35:57 2013 From: bob at doolittle.us.com (Bob Doolittle) Date: Wed, 20 Nov 2013 17:35:57 -0500 Subject: [Engine-devel] Problem building 3.3.1 branch Message-ID: <528D394D.2080907@doolittle.us.com> Hi, I'm trying to build engine for the first time and running into a build error. I'm a seasoned Unix developer, but new to some aspects of Linux development like git and maven, so I could be doing something naive. I'm following the instructions here: http://www.ovirt.org/OVirt_Engine_Development_Environment I did a clone of the engine repository, and did "git checkout -b myengine origin/ovirt-engine-3.3.1" to create my own branch based on 3.3.1 (current - I realize it's not quite done). Then, when I did "make install-dev PREFIX=$HOME/ovirt-engine" it failed when building the "Engine Web Root", specifically in the FileServletTest. Relevant build log is here: http://pastebin.com/JRcyWvtr Can anyone suggest what I've done wrong, or whether there's a problem with the repository at the moment? I'd appreciate any guidance. Thanks, Bob From alonbl at redhat.com Wed Nov 20 22:45:00 2013 From: alonbl at redhat.com (Alon Bar-Lev) Date: Wed, 20 Nov 2013 17:45:00 -0500 (EST) Subject: [Engine-devel] Problem building 3.3.1 branch In-Reply-To: <528D394D.2080907@doolittle.us.com> References: <528D394D.2080907@doolittle.us.com> Message-ID: <1380975311.17443897.1384987500754.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Bob Doolittle" > To: engine-devel at ovirt.org > Sent: Thursday, November 21, 2013 12:35:57 AM > Subject: [Engine-devel] Problem building 3.3.1 branch > > Hi, > > I'm trying to build engine for the first time and running into a build > error. I'm a seasoned Unix developer, but new to some aspects of Linux > development like git and maven, so I could be doing something naive. > > I'm following the instructions here: > http://www.ovirt.org/OVirt_Engine_Development_Environment > > I did a clone of the engine repository, and did "git checkout -b > myengine origin/ovirt-engine-3.3.1" to create my own branch based on > 3.3.1 (current - I realize it's not quite done). > > Then, when I did "make install-dev PREFIX=$HOME/ovirt-engine" it failed > when building the "Engine Web Root", specifically in the > FileServletTest. Relevant build log is here: http://pastebin.com/JRcyWvtr > > Can anyone suggest what I've done wrong, or whether there's a problem > with the repository at the moment? There may be indeed a problem, not happening at my setup, just tried. Can you please please send the relevant file from[1] I think it should be called something with FileServletTes. [1] /home/rad/workspace/ovirt-engine/backend/manager/modules/root/target/surefire-reports > > I'd appreciate any guidance. > > Thanks, > Bob > > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > From iheim at redhat.com Wed Nov 20 23:24:00 2013 From: iheim at redhat.com (Itamar Heim) Date: Thu, 21 Nov 2013 01:24:00 +0200 Subject: [Engine-devel] Problem building 3.3.1 branch In-Reply-To: <1380975311.17443897.1384987500754.JavaMail.root@redhat.com> References: <528D394D.2080907@doolittle.us.com> <1380975311.17443897.1384987500754.JavaMail.root@redhat.com> Message-ID: <528D4490.40704@redhat.com> On 11/21/2013 12:45 AM, Alon Bar-Lev wrote: > > > ----- Original Message ----- >> From: "Bob Doolittle" >> To: engine-devel at ovirt.org >> Sent: Thursday, November 21, 2013 12:35:57 AM >> Subject: [Engine-devel] Problem building 3.3.1 branch >> >> Hi, >> >> I'm trying to build engine for the first time and running into a build >> error. I'm a seasoned Unix developer, but new to some aspects of Linux >> development like git and maven, so I could be doing something naive. >> >> I'm following the instructions here: >> http://www.ovirt.org/OVirt_Engine_Development_Environment >> >> I did a clone of the engine repository, and did "git checkout -b >> myengine origin/ovirt-engine-3.3.1" to create my own branch based on >> 3.3.1 (current - I realize it's not quite done). >> >> Then, when I did "make install-dev PREFIX=$HOME/ovirt-engine" it failed >> when building the "Engine Web Root", specifically in the >> FileServletTest. Relevant build log is here: http://pastebin.com/JRcyWvtr >> >> Can anyone suggest what I've done wrong, or whether there's a problem >> with the repository at the moment? > > There may be indeed a problem, not happening at my setup, just tried. > Can you please please send the relevant file from[1] > I think it should be called something with FileServletTes. > > > [1] /home/rad/workspace/ovirt-engine/backend/manager/modules/root/target/surefire-reports also couldn't reproduced (tried just now). anything special about the environment? - cpu/ram configuration? - not enough disk space? special file permissions? - which OS is this on? which JRE? Thanks, Itamar From bob at doolittle.us.com Thu Nov 21 00:01:46 2013 From: bob at doolittle.us.com (Bob Doolittle) Date: Wed, 20 Nov 2013 19:01:46 -0500 Subject: [Engine-devel] Problem building 3.3.1 branch In-Reply-To: <528D4490.40704@redhat.com> References: <528D394D.2080907@doolittle.us.com> <1380975311.17443897.1384987500754.JavaMail.root@redhat.com> <528D4490.40704@redhat.com> Message-ID: <528D4D6A.4040105@doolittle.us.com> This is Fedora 19 On 11/20/2013 06:24 PM, Itamar Heim wrote: > On 11/21/2013 12:45 AM, Alon Bar-Lev wrote: >> >> >> ----- Original Message ----- >>> From: "Bob Doolittle" >>> To: engine-devel at ovirt.org >>> Sent: Thursday, November 21, 2013 12:35:57 AM >>> Subject: [Engine-devel] Problem building 3.3.1 branch >>> >>> Hi, >>> >>> I'm trying to build engine for the first time and running into a build >>> error. I'm a seasoned Unix developer, but new to some aspects of Linux >>> development like git and maven, so I could be doing something naive. >>> >>> I'm following the instructions here: >>> http://www.ovirt.org/OVirt_Engine_Development_Environment >>> >>> I did a clone of the engine repository, and did "git checkout -b >>> myengine origin/ovirt-engine-3.3.1" to create my own branch based on >>> 3.3.1 (current - I realize it's not quite done). >>> >>> Then, when I did "make install-dev PREFIX=$HOME/ovirt-engine" it failed >>> when building the "Engine Web Root", specifically in the >>> FileServletTest. Relevant build log is here: >>> http://pastebin.com/JRcyWvtr >>> >>> Can anyone suggest what I've done wrong, or whether there's a problem >>> with the repository at the moment? >> >> There may be indeed a problem, not happening at my setup, just tried. >> Can you please please send the relevant file from[1] >> I think it should be called something with FileServletTes. >> >> >> [1] >> /home/rad/workspace/ovirt-engine/backend/manager/modules/root/target/surefire-reports > > also couldn't reproduced (tried just now). > anything special about the environment? > - cpu/ram configuration? > - not enough disk space? special file permissions? > - which OS is this on? which JRE? > > Thanks, > Itamar > This is Fedora 19 (updated) cpu i7-3520 mem 8GB Disk has over 26GB free for both volumes (SSD) I installed all the tools/prereqs as root. Did git clone as myself (no special permission) Running make as myself JRE 1.7.0_45 OpenJDK I have attached the requested file (not sure which you wanted, attached both likely candidates). I am running the make under my login shell, which is zsh. On occasion this has caused issues. If no better suggestions I'll double-check tomorrow by running under bash. Thanks for your assistance, Bob -------------- next part -------------- ------------------------------------------------------------------------------- Test set: org.ovirt.engine.core.FileServletTest ------------------------------------------------------------------------------- Tests run: 7, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.1 sec <<< FAILURE! testDoGet1(org.ovirt.engine.core.FileServletTest) Time elapsed: 0.075 sec <<< FAILURE! org.mockito.exceptions.verification.TooManyActualInvocations: servletOutputStream.write(, 0, ); Wanted 1 time: -> at org.ovirt.engine.core.FileServletTest.testDoGet1(FileServletTest.java:97) But was 3 times. Undesired invocation: -> at org.ovirt.engine.core.utils.servlet.ServletUtils.writeFileToStream(ServletUtils.java:129) at org.ovirt.engine.core.FileServletTest.testDoGet1(FileServletTest.java:97) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45) at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15) at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42) at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20) at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28) at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:68) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:47) at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231) at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60) at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229) at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50) at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222) at org.junit.runners.ParentRunner.run(ParentRunner.java:300) at org.mockito.internal.runners.JUnit45AndHigherRunnerImpl.run(JUnit45AndHigherRunnerImpl.java:37) at org.mockito.runners.MockitoJUnitRunner.run(MockitoJUnitRunner.java:62) at org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:35) at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:115) at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:97) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at org.apache.maven.surefire.booter.ProviderFactory$ClassLoaderProxy.invoke(ProviderFactory.java:103) at com.sun.proxy.$Proxy0.invoke(Unknown Source) at org.apache.maven.surefire.booter.SurefireStarter.invokeProvider(SurefireStarter.java:150) at org.apache.maven.surefire.booter.SurefireStarter.runSuitesInProcess(SurefireStarter.java:91) at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:69) -------------- next part -------------- A non-text attachment was scrubbed... Name: TEST-org.ovirt.engine.core.FileServletTest.xml Type: text/xml Size: 25291 bytes Desc: not available URL: From awels at redhat.com Thu Nov 21 00:06:02 2013 From: awels at redhat.com (Alexander Wels) Date: Wed, 20 Nov 2013 19:06:02 -0500 Subject: [Engine-devel] Problem building 3.3.1 branch In-Reply-To: <528D4D6A.4040105@doolittle.us.com> References: <528D394D.2080907@doolittle.us.com> <528D4490.40704@redhat.com> <528D4D6A.4040105@doolittle.us.com> Message-ID: <2583082.UTtLtr8YA6@awels> On Wednesday, November 20, 2013 07:01:46 PM Bob Doolittle wrote: > This is Fedora 19 > > On 11/20/2013 06:24 PM, Itamar Heim wrote: > > On 11/21/2013 12:45 AM, Alon Bar-Lev wrote: > >> ----- Original Message ----- > >> > >>> From: "Bob Doolittle" > >>> To: engine-devel at ovirt.org > >>> Sent: Thursday, November 21, 2013 12:35:57 AM > >>> Subject: [Engine-devel] Problem building 3.3.1 branch > >>> > >>> Hi, > >>> > >>> I'm trying to build engine for the first time and running into a build > >>> error. I'm a seasoned Unix developer, but new to some aspects of Linux > >>> development like git and maven, so I could be doing something naive. > >>> > >>> I'm following the instructions here: > >>> http://www.ovirt.org/OVirt_Engine_Development_Environment > >>> > >>> I did a clone of the engine repository, and did "git checkout -b > >>> myengine origin/ovirt-engine-3.3.1" to create my own branch based on > >>> 3.3.1 (current - I realize it's not quite done). > >>> > >>> Then, when I did "make install-dev PREFIX=$HOME/ovirt-engine" it failed > >>> when building the "Engine Web Root", specifically in the > >>> FileServletTest. Relevant build log is here: > >>> http://pastebin.com/JRcyWvtr > >>> > >>> Can anyone suggest what I've done wrong, or whether there's a problem > >>> with the repository at the moment? > >> > >> There may be indeed a problem, not happening at my setup, just tried. > >> Can you please please send the relevant file from[1] > >> I think it should be called something with FileServletTes. > >> > >> > >> [1] > >> /home/rad/workspace/ovirt-engine/backend/manager/modules/root/target/sure > >> fire-reports> > > also couldn't reproduced (tried just now). > > anything special about the environment? > > - cpu/ram configuration? > > - not enough disk space? special file permissions? > > - which OS is this on? which JRE? > > > > Thanks, > > > > Itamar > > This is Fedora 19 (updated) > cpu i7-3520 > mem 8GB > Disk has over 26GB free for both volumes (SSD) > I installed all the tools/prereqs as root. > Did git clone as myself (no special permission) > Running make as myself > JRE 1.7.0_45 OpenJDK > > I have attached the requested file (not sure which you wanted, attached > both likely candidates). > > I am running the make under my login shell, which is zsh. On occasion > this has caused issues. If no better suggestions I'll double-check > tomorrow by running under bash. > > Thanks for your assistance, > Bob Bob, do you have an unusually large /etc/hosts file? looking at the error somewhere between 8192 and 12288 bytes? If so then it is a bug in the test, I will update it in the morning. Alexander From bob at doolittle.us.com Thu Nov 21 00:08:39 2013 From: bob at doolittle.us.com (Bob Doolittle) Date: Wed, 20 Nov 2013 19:08:39 -0500 Subject: [Engine-devel] Problem building 3.3.1 branch In-Reply-To: <2583082.UTtLtr8YA6@awels> References: <528D394D.2080907@doolittle.us.com> <528D4490.40704@redhat.com> <528D4D6A.4040105@doolittle.us.com> <2583082.UTtLtr8YA6@awels> Message-ID: Yes, it's pretty large. A little over 9k. -Bob On Nov 20, 2013 7:06 PM, "Alexander Wels" wrote: > On Wednesday, November 20, 2013 07:01:46 PM Bob Doolittle wrote: > > This is Fedora 19 > > > > On 11/20/2013 06:24 PM, Itamar Heim wrote: > > > On 11/21/2013 12:45 AM, Alon Bar-Lev wrote: > > >> ----- Original Message ----- > > >> > > >>> From: "Bob Doolittle" > > >>> To: engine-devel at ovirt.org > > >>> Sent: Thursday, November 21, 2013 12:35:57 AM > > >>> Subject: [Engine-devel] Problem building 3.3.1 branch > > >>> > > >>> Hi, > > >>> > > >>> I'm trying to build engine for the first time and running into a > build > > >>> error. I'm a seasoned Unix developer, but new to some aspects of > Linux > > >>> development like git and maven, so I could be doing something naive. > > >>> > > >>> I'm following the instructions here: > > >>> http://www.ovirt.org/OVirt_Engine_Development_Environment > > >>> > > >>> I did a clone of the engine repository, and did "git checkout -b > > >>> myengine origin/ovirt-engine-3.3.1" to create my own branch based on > > >>> 3.3.1 (current - I realize it's not quite done). > > >>> > > >>> Then, when I did "make install-dev PREFIX=$HOME/ovirt-engine" it > failed > > >>> when building the "Engine Web Root", specifically in the > > >>> FileServletTest. Relevant build log is here: > > >>> http://pastebin.com/JRcyWvtr > > >>> > > >>> Can anyone suggest what I've done wrong, or whether there's a problem > > >>> with the repository at the moment? > > >> > > >> There may be indeed a problem, not happening at my setup, just tried. > > >> Can you please please send the relevant file from[1] > > >> I think it should be called something with FileServletTes. > > >> > > >> > > >> [1] > > >> > /home/rad/workspace/ovirt-engine/backend/manager/modules/root/target/sure > > >> fire-reports> > > > also couldn't reproduced (tried just now). > > > anything special about the environment? > > > - cpu/ram configuration? > > > - not enough disk space? special file permissions? > > > - which OS is this on? which JRE? > > > > > > Thanks, > > > > > > Itamar > > > > This is Fedora 19 (updated) > > cpu i7-3520 > > mem 8GB > > Disk has over 26GB free for both volumes (SSD) > > I installed all the tools/prereqs as root. > > Did git clone as myself (no special permission) > > Running make as myself > > JRE 1.7.0_45 OpenJDK > > > > I have attached the requested file (not sure which you wanted, attached > > both likely candidates). > > > > I am running the make under my login shell, which is zsh. On occasion > > this has caused issues. If no better suggestions I'll double-check > > tomorrow by running under bash. > > > > Thanks for your assistance, > > Bob > > Bob, > > do you have an unusually large /etc/hosts file? looking at the error > somewhere > between 8192 and 12288 bytes? If so then it is a bug in the test, I will > update it in the morning. > > Alexander > -------------- next part -------------- An HTML attachment was scrubbed... URL: From awels at redhat.com Thu Nov 21 00:14:38 2013 From: awels at redhat.com (Alexander Wels) Date: Wed, 20 Nov 2013 19:14:38 -0500 Subject: [Engine-devel] Problem building 3.3.1 branch In-Reply-To: References: <528D394D.2080907@doolittle.us.com> <2583082.UTtLtr8YA6@awels> Message-ID: <153892050.MIRmWBUgjf@awels> On Wednesday, November 20, 2013 07:08:39 PM Bob Doolittle wrote: > Yes, it's pretty large. A little over 9k. > > -Bob > Yes definitely a bug in the test, you can run the build without running the unit tests and it should succeed, or temporarily have a /etc/hosts file <= 4096 bytes. Looking at the test, I am not sure what I was thinking when I did that, but I will rework it soon to not have such a crazy dependency. > On Nov 20, 2013 7:06 PM, "Alexander Wels" wrote: > > On Wednesday, November 20, 2013 07:01:46 PM Bob Doolittle wrote: > > > This is Fedora 19 > > > > > > On 11/20/2013 06:24 PM, Itamar Heim wrote: > > > > On 11/21/2013 12:45 AM, Alon Bar-Lev wrote: > > > >> ----- Original Message ----- > > > >> > > > >>> From: "Bob Doolittle" > > > >>> To: engine-devel at ovirt.org > > > >>> Sent: Thursday, November 21, 2013 12:35:57 AM > > > >>> Subject: [Engine-devel] Problem building 3.3.1 branch > > > >>> > > > >>> Hi, > > > >>> > > > >>> I'm trying to build engine for the first time and running into a > > > > build > > > > > >>> error. I'm a seasoned Unix developer, but new to some aspects of > > > > Linux > > > > > >>> development like git and maven, so I could be doing something naive. > > > >>> > > > >>> I'm following the instructions here: > > > >>> http://www.ovirt.org/OVirt_Engine_Development_Environment > > > >>> > > > >>> I did a clone of the engine repository, and did "git checkout -b > > > >>> myengine origin/ovirt-engine-3.3.1" to create my own branch based on > > > >>> 3.3.1 (current - I realize it's not quite done). > > > >>> > > > >>> Then, when I did "make install-dev PREFIX=$HOME/ovirt-engine" it > > > > failed > > > > > >>> when building the "Engine Web Root", specifically in the > > > >>> FileServletTest. Relevant build log is here: > > > >>> http://pastebin.com/JRcyWvtr > > > >>> > > > >>> Can anyone suggest what I've done wrong, or whether there's a > > > >>> problem > > > >>> with the repository at the moment? > > > >> > > > >> There may be indeed a problem, not happening at my setup, just tried. > > > >> Can you please please send the relevant file from[1] > > > >> I think it should be called something with FileServletTes. > > > >> > > > >> > > > >> [1] > > > > /home/rad/workspace/ovirt-engine/backend/manager/modules/root/target/sure > > > > > >> fire-reports> > > > > > > > > also couldn't reproduced (tried just now). > > > > anything special about the environment? > > > > - cpu/ram configuration? > > > > - not enough disk space? special file permissions? > > > > - which OS is this on? which JRE? > > > > > > > > Thanks, > > > > > > > > Itamar > > > > > > This is Fedora 19 (updated) > > > cpu i7-3520 > > > mem 8GB > > > Disk has over 26GB free for both volumes (SSD) > > > I installed all the tools/prereqs as root. > > > Did git clone as myself (no special permission) > > > Running make as myself > > > JRE 1.7.0_45 OpenJDK > > > > > > I have attached the requested file (not sure which you wanted, attached > > > both likely candidates). > > > > > > I am running the make under my login shell, which is zsh. On occasion > > > this has caused issues. If no better suggestions I'll double-check > > > tomorrow by running under bash. > > > > > > Thanks for your assistance, > > > > > > Bob > > > > Bob, > > > > do you have an unusually large /etc/hosts file? looking at the error > > somewhere > > between 8192 and 12288 bytes? If so then it is a bug in the test, I will > > update it in the morning. > > > > Alexander From gouyang at redhat.com Thu Nov 21 09:07:48 2013 From: gouyang at redhat.com (ouyang guohua) Date: Thu, 21 Nov 2013 17:07:48 +0800 Subject: [Engine-devel] failed to add host into cluster In-Reply-To: References: <51FE642C.8040307@redhat.com> <1492863435.5066137.1375682766691.JavaMail.root@redhat.com> <51FF94AE.6030807@redhat.com> <307132015.5144883.1375706091754.JavaMail.root@redhat.com> Message-ID: <528DCD64.5010407@redhat.com> Hi, I encounter the same problem today. Both the engine and the node are fedora 19. 1. on engine host: engine=# select * from vdc_options where option_name ilike '%emu%'; option_id | option_name | option_value | version -----------+-------------------------+------------------+--------- 38 | ClusterEmulatedMachines | rhel6.2.0,pc-1.0 | 3.0 39 | ClusterEmulatedMachines | rhel6.3.0,pc-1.0 | 3.1 40 | ClusterEmulatedMachines | rhel6.4.0,pc-1.0 | 3.2 41 | ClusterEmulatedMachines | rhel6.4.0,pc-1.0 | 3.3 (4 rows) engine=# select name,emulated_machine from vds_groups; name | emulated_machine ---------------------+------------------ Default | fedora19-cluster | pc-1.0 fedora19-node-Local | pc-1.0 (3 rows) 2. on node: # vdsClient -s 0 getVdsCaps HBAInventory = {'iSCSI': [{'InitiatorName': 'iqn.1994-05.com.redhat:643bb46781e'}], 'FC': []} ISCSIInitiatorName = iqn.1994-05.com.redhat:643bb46781e bondings = {'bond4': {'addr': '', 'cfg': {}, 'mtu': '1500', 'netmask': '', 'slaves': [], 'hwaddr': '7e:00:7f:e7:90:4c'}, 'bond0': {'addr': '', 'cfg': {}, 'mtu': '1500', 'netmask': '', 'slaves': [], 'hwaddr': 'de:c5:12:4e:17:6f'}, 'bond1': {'addr': '', 'cfg': {}, 'mtu': '1500', 'netmask': '', 'slaves': [], 'hwaddr': '2e:ec:3b:01:ab:de'}, 'bond2': {'addr': '', 'cfg': {}, 'mtu': '1500', 'netmask': '', 'slaves': [], 'hwaddr': 'da:88:61:cb:0d:ed'}, 'bond3': {'addr': '', 'cfg': {}, 'mtu': '1500', 'netmask': '', 'slaves': [], 'hwaddr': '72:c4:9e:9d:25:c1'}} bridges = {'ovirtmgmt': {'addr': '10.66.10.186', 'cfg': {'PEERROUTES': 'yes', 'IPV6INIT': 'yes', 'TYPE': 'Bridge', 'IPV6_PEERDNS': 'yes', 'DEFROUTE': 'yes', 'ONBOOT': 'yes', 'PEERDNS': 'yes', 'IPV4_FAILURE_FATAL': 'no', 'DELAY': '0', 'NM_CONTROLLED': 'no', 'BOOTPROTO': 'dhcp', 'DEVICE': 'ovirtmgmt', 'IPV6_FAILURE_FATAL': 'no', 'IPV6_PEERROUTES': 'yes', 'IPV6_DEFROUTE': 'yes', 'IPV6_AUTOCONF': 'yes', 'UUID': '447b16c1-184a-4347-a801-ef8143c2d932'}, 'mtu': '1500', 'netmask': '255.255.252.0', 'stp': 'off', 'ports': ['em1']}} clusterLevels = ['3.0', '3.1', '3.2'] cpuCores = 4 cpuFlags = fpu,vme,de,pse,tsc,msr,pae,mce,cx8,apic,sep,mtrr,pge,mca,cmov,pat,pse36,clflush,dts,acpi,mmx,fxsr,sse,sse2,ss,ht,tm,pbe,syscall,nx,lm,constant_tsc,arch_perfmon,pebs,bts,rep_good,nopl,aperfmperf,pni,dtes64,monitor,ds_cpl,vmx,smx,est,tm2,ssse3,cx16,xtpr,pdcm,sse4_1,xsave,lahf_lm,dtherm,tpr_shadow,vnmi,flexpriority,model_Conroe,model_coreduo,model_core2duo,model_Penryn,model_n270 cpuModel = Intel(R) Core(TM)2 Quad CPU Q9400 @ 2.66GHz cpuSockets = 1 cpuSpeed = 2660.126 cpuThreads = 4 emulatedMachines = ['clipper', 'none'] guestOverhead = 65 hooks = {} kvmEnabled = true lastClient = 10.66.105.101 lastClientIface = ovirtmgmt management_ip = memSize = 3888 netConfigDirty = False networks = {'ovirtmgmt': {'iface': 'ovirtmgmt', 'addr': '10.66.10.186', 'cfg': {'PEERROUTES': 'yes', 'IPV6INIT': 'yes', 'TYPE': 'Bridge', 'IPV6_PEERDNS': 'yes', 'DEFROUTE': 'yes', 'ONBOOT': 'yes', 'PEERDNS': 'yes', 'IPV4_FAILURE_FATAL': 'no', 'DELAY': '0', 'NM_CONTROLLED': 'no', 'BOOTPROTO': 'dhcp', 'DEVICE': 'ovirtmgmt', 'IPV6_FAILURE_FATAL': 'no', 'IPV6_PEERROUTES': 'yes', 'IPV6_DEFROUTE': 'yes', 'IPV6_AUTOCONF': 'yes', 'UUID': '447b16c1-184a-4347-a801-ef8143c2d932'}, 'mtu': '1500', 'netmask': '255.255.252.0', 'stp': 'off', 'bridged': True, 'gateway': '10.66.11.254', 'ports': ['em1']}} nics = {'em1': {'addr': '', 'cfg': {'PEERROUTES': 'yes', 'BRIDGE': 'ovirtmgmt', 'DEVICE': 'em1', 'IPV6INIT': 'yes', 'IPV6_PEERDNS': 'yes', 'DEFROUTE': 'yes', 'ONBOOT': 'yes', 'PEERDNS': 'yes', 'IPV4_FAILURE_FATAL': 'no', 'NM_CONTROLLED': 'no', 'IPV6_DEFROUTE': 'yes', 'IPV6_AUTOCONF': 'yes', 'IPV6_FAILURE_FATAL': 'no', 'IPV6_PEERROUTES': 'yes', 'HWADDR': '00:23:ae:9d:85:32', 'UUID': '447b16c1-184a-4347-a801-ef8143c2d932'}, 'mtu': '1500', 'netmask': '', 'hwaddr': '00:23:ae:9d:85:32', 'speed': 1000}} operatingSystem = {'release': '4', 'version': '19', 'name': 'Fedora'} packages2 = {'kernel': {'release': '200.fc19.x86_64', 'buildtime': 1383545343.0, 'version': '3.11.7'}, 'spice-server': {'release': '3.fc19', 'buildtime': 1383130020, 'version': '0.12.4'}, 'vdsm': {'release': '18.fc19', 'buildtime': 1373484771, 'version': '4.10.3'}, 'qemu-kvm': {'release': '13.fc19', 'buildtime': 1383700301, 'version': '1.4.2'}, 'libvirt': {'release': '1.fc19', 'buildtime': 1383765188, 'version': '1.0.5.7'}, 'qemu-img': {'release': '13.fc19', 'buildtime': 1383700301, 'version': '1.4.2'}, 'mom': {'release': '1.fc19', 'buildtime': 1373298035, 'version': '0.3.1'}} reservedMem = 321 software_revision = 18 software_version = 4.10 supportedENGINEs = ['3.0', '3.1'] supportedProtocols = ['2.2', '2.3'] uuid = 44454C4C-4C00-1031-8053-CAC04F4E3258 version_name = Snow Man vlans = {} vmTypes = ['kvm'] 3. the vdsm.log is cutting to small size, if some useful logs isn't in it, please ask me to re-send it. Thanks, guohua On 08/06/2013 03:08 PM, Chen, Wei D wrote: > The issue is solved by reinstalling host OS. > > Best Regards, > Dave Chen > > >> -----Original Message----- >> From: Chen, Wei D >> Sent: Tuesday, August 06, 2013 2:44 PM >> To: 'Laszlo Hornyak'; Itamar Heim >> Cc: Zhang, Lijuan; engine-devel at ovirt.org >> Subject: RE: [Engine-devel] failed to add host into cluster >> >> Hi, >> >> >> [root at onode vdsm]# vdsClient -s 0 getVdsCaps >> HBAInventory = {'iSCSI': [{'InitiatorName': 'iqn.1994-05.com.redhat:9fb571e343'}], 'FC': []} >> ISCSIInitiatorName = iqn.1994-05.com.redhat:9fb571e343 >> bondings = {'bond4': {'addr': '', 'cfg': {}, 'mtu': '1500', 'netmask': '', 'slaves': [], 'hwaddr': '0e:00:b7:57:2c:c9'}, >> 'bond0': {'addr': '', 'cfg': {}, 'mtu': '1500', 'netmask': '', 'slaves': [], 'hwaddr': '32:b3:88:1f:ef:91'}, 'bond1': {'addr': '', >> 'cfg': {}, 'mtu': '1500', 'netmask': '', 'slaves': [], 'hwaddr': '4e:e5:80:93:ea:d9'}, 'bond2': {'addr': '', 'cfg': {}, 'mtu': >> '1500', >> 'netmask': '', 'slaves': [], 'hwaddr': '16:ab:f6:e4:f2:27'}, 'bond3': {'addr': '', 'cfg': {}, 'mtu': '1500', 'netmask': '', >> 'slaves': >> [], 'hwaddr': 'ee:55:f5:e7:31:7c'}} >> bridges = {'ovirtmgmt': {'addr': '10.239.131.217', 'cfg': {'PEERROUTES': 'yes', 'DEVICE': 'ovirtmgmt', 'IPV6INIT': 'yes', >> 'UUID': 'b6ecfa9d-0deb-4213-9348-11137f76735d', 'IPV6_PEERDNS': 'yes', 'DEFROUTE': 'yes', 'PEERDNS': 'yes', 'IPV4_FAILURE_FATAL': >> 'no', 'DELAY': '0', 'NM_CONTROLLED': 'no', 'IPV6_DEFROUTE': 'yes', 'IPV6_AUTOCONF': 'yes', 'IPV6_FAILURE_FATAL': 'no', 'TYPE': >> 'Bridge', 'ONBOOT': 'yes', 'BOOTPROTO': 'dhcp', 'IPV6_PEERROUTES': 'yes'}, 'mtu': '1500', 'netmask': '255.255.255.0', 'stp': 'off', >> 'ports': ['em1']}} >> clusterLevels = ['3.0', '3.1', '3.2'] >> cpuCores = 4 >> cpuFlags = >> fpu,vme,de,pse,tsc,msr,pae,mce,cx8,apic,sep,mtrr,pge,mca,cmov,pat,pse36,clflush,dts,acpi,mmx,fxsr,sse,sse2,ss,ht,tm,pbe,syscall,nx,r >> dtscp,lm,constant_tsc,arch_perfmon,pebs,bts,rep_good,nopl,xtopology,nonstop_tsc,aperfmperf,eagerfpu,pni,pclmulqdq,dtes64,monitor, >> ds_cpl,vmx,smx,est,tm2,ssse3,cx16,xtpr,pdcm,pcid,sse4_1,sse4_2,x2apic,popcnt,tsc_deadline_timer,aes,xsave,avx,lahf_lm,ida,arat,epb, >> xsaveopt,pln,pts,dtherm,tpr_shadow,vnmi,flexpriority,ept,vpid,model_Nehalem,model_Conroe,model_coreduo,model_core2duo,model_P >> enryn,model_Westmere,model_n270,model_SandyBridge >> cpuModel = Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz >> cpuSockets = 1 >> cpuSpeed = 3672.000 >> cpuThreads = 8 >> emulatedMachines = ['clipper', 'none'] >> guestOverhead = 65 >> hooks = {} >> kvmEnabled = true >> lastClient = 10.239.131.222 >> lastClientIface = ovirtmgmt >> management_ip = >> memSize = 7944 >> netConfigDirty = False >> networks = {'ovirtmgmt': {'iface': 'ovirtmgmt', 'addr': '10.239.131.217', 'cfg': {'PEERROUTES': 'yes', 'DEVICE': >> 'ovirtmgmt', >> 'IPV6INIT': 'yes', 'UUID': 'b6ecfa9d-0deb-4213-9348-11137f76735d', 'IPV6_PEERDNS': 'yes', 'DEFROUTE': 'yes', 'PEERDNS': 'yes', >> 'IPV4_FAILURE_FATAL': 'no', 'DELAY': '0', 'NM_CONTROLLED': 'no', 'IPV6_DEFROUTE': 'yes', 'IPV6_AUTOCONF': 'yes', >> 'IPV6_FAILURE_FATAL': >> 'no', 'TYPE': 'Bridge', 'ONBOOT': 'yes', 'BOOTPROTO': 'dhcp', 'IPV6_PEERROUTES': 'yes'}, 'mtu': '1500', 'netmask': '255.255.255.0', >> 'stp': 'off', 'bridged': True, 'gateway': '10.239.131.1', 'ports': ['em1']}} >> nics = {'em1': {'addr': '', 'cfg': {}, 'mtu': '1500', 'netmask': '', 'hwaddr': '2c:41:38:b2:d0:e8', 'speed': 100}} >> operatingSystem = {'release': '0.5', 'version': '19', 'name': 'Fedora'} >> packages2 = {'kernel': {'release': '301.fc19.x86_64', 'buildtime': 1368462984.0, 'version': '3.9.2'}, 'spice-server': >> {'release': '5.fc19', 'buildtime': 1366036951, 'version': '0.12.2'}, 'vdsm': {'release': '18.fc19', 'buildtime': 1373484771, >> 'version': '4.10.3'}, 'qemu-kvm': {'release': '4.fc19', 'buildtime': 1371653911, 'version': '1.4.2'}, 'libvirt': {'release': >> '1.fc19', >> 'buildtime': 1371074681, 'version': '1.0.5.2'}, 'qemu-img': {'release': '4.fc19', 'buildtime': 1371653911, 'version': '1.4.2'}, >> 'mom': >> {'release': '2.fc19', 'buildtime': 1374564325, 'version': '0.3.2'}} >> reservedMem = 321 >> software_revision = 18 >> software_version = 4.10 >> supportedENGINEs = ['3.0', '3.1'] >> supportedProtocols = ['2.2', '2.3'] >> uuid = 30BBC800-4F47-11E0-0000-2C4138B2D0E8 >> version_name = Snow Man >> vlans = {} >> vmTypes = ['kvm'] >> >> >> >> >> >> Best Regards, >> Dave Chen >> >> >>> -----Original Message----- >>> From: Laszlo Hornyak [mailto:lhornyak at redhat.com] >>> Sent: Monday, August 05, 2013 8:35 PM >>> To: Itamar Heim >>> Cc: Chen, Wei D; Zhang, Lijuan; engine-devel at ovirt.org >>> Subject: Re: [Engine-devel] failed to add host into cluster >>> >>> Hi, >>> >>> Dave, could you also share the vdsm log as well? >>> >>> I managed to reproduce this on the host that I am using for years and I am using it now, so it should not be a hardware problem. >>> Probably >>> some broken configuration caused some problem in vdsm before it would retrieve the capabilities information from libvirt. >>> >>> >>> >>> ----- Original Message ----- >>>> From: "Itamar Heim" >>>> To: "Laszlo Hornyak" >>>> Cc: "Wei D Chen", "Lijuan Zhang" >>>> , engine-devel at ovirt.org >>>> Sent: Monday, August 5, 2013 2:03:58 PM >>>> Subject: Re: [Engine-devel] failed to add host into cluster >>>> >>>> On 08/05/2013 09:06 AM, Laszlo Hornyak wrote: >>>>> ----- Original Message ----- >>>>>> From: "Wei D Chen" >>>>>> To: "Itamar Heim" >>>>>> Cc: "Lijuan Zhang", engine-devel at ovirt.org >>>>>> Sent: Monday, August 5, 2013 8:03:08 AM >>>>>> Subject: Re: [Engine-devel] failed to add host into cluster >>>>>> >>>>>> >>>>>> >>>>>> Best Regards, >>>>>> Dave Chen >>>>>> >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Itamar Heim [mailto:iheim at redhat.com] >>>>>>> Sent: Sunday, August 04, 2013 10:25 PM >>>>>>> To: Chen, Wei D >>>>>>> Cc: engine-devel at ovirt.org; Zhang, Lijuan >>>>>>> Subject: Re: [Engine-devel] failed to add host into cluster >>>>>>> >>>>>>> On 08/02/2013 09:34 AM, Chen, Wei D wrote: >>>>>>>> Failed to add a node into cluster. I saw follow hints, but still >>>>>>>> don't know how to fix it. OS is fedora 19 both for node and >>>>>>>> engine, anyone can help me? >>>>>>>> >>>>>>>> Host *** does not comply with the cluster *** emulated machines. >>>>>>>> The Hosts emulated machines are clipper,none and the cluster is >>>>>>>> [rhel6.4.0, pc-1.0]} >>>>>>> what Os is the host running? >>>>>> fedora 19 >>>>>>> what does 'vdsClient -s 0 getVdsCaps' returns? >>>>>> where to run this command? this command is not recognized both in >>>>>> engine and node. >>>>> After installing the host, you should have this command in the host OS. >>>>> >>>>>> _______________________________________________ >>>>>> Engine-devel mailing list >>>>>> Engine-devel at ovirt.org >>>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel >>>>>> >>>> cat /proc/cpuinfo >>>> and >>>> virsh capabilities >>>> >>>> are also interesting >>>> >>>> >>>> >>>> _______________________________________________ >>>> Engine-devel mailing list >>>> Engine-devel at ovirt.org >>>> http://lists.ovirt.org/mailman/listinfo/engine-devel -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: vdsm.log URL: From iheim at redhat.com Thu Nov 21 10:35:29 2013 From: iheim at redhat.com (Itamar Heim) Date: Thu, 21 Nov 2013 12:35:29 +0200 Subject: [Engine-devel] failed to add host into cluster In-Reply-To: <528DCD64.5010407@redhat.com> References: <51FE642C.8040307@redhat.com> <1492863435.5066137.1375682766691.JavaMail.root@redhat.com> <51FF94AE.6030807@redhat.com> <307132015.5144883.1375706091754.JavaMail.root@redhat.com> <528DCD64.5010407@redhat.com> Message-ID: <528DE1F1.4090603@redhat.com> On 11/21/2013 11:07 AM, ouyang guohua wrote: > Hi, > > I encounter the same problem today. > > Both the engine and the node are fedora 19. > > 1. on engine host: > engine=# select * from vdc_options where option_name ilike '%emu%'; > option_id | option_name | option_value | version > -----------+-------------------------+------------------+--------- > 38 | ClusterEmulatedMachines | rhel6.2.0,pc-1.0 | 3.0 > 39 | ClusterEmulatedMachines | rhel6.3.0,pc-1.0 | 3.1 > 40 | ClusterEmulatedMachines | rhel6.4.0,pc-1.0 | 3.2 > 41 | ClusterEmulatedMachines | rhel6.4.0,pc-1.0 | 3.3 > (4 rows) > > engine=# select name,emulated_machine from vds_groups; > name | emulated_machine > ---------------------+------------------ > Default | > fedora19-cluster | pc-1.0 > fedora19-node-Local | pc-1.0 > (3 rows) > > 2. on node: > # vdsClient -s 0 getVdsCaps > HBAInventory = {'iSCSI': [{'InitiatorName': > 'iqn.1994-05.com.redhat:643bb46781e'}], 'FC': []} > ISCSIInitiatorName = iqn.1994-05.com.redhat:643bb46781e > bondings = {'bond4': {'addr': '', 'cfg': {}, 'mtu': '1500', > 'netmask': '', 'slaves': [], 'hwaddr': '7e:00:7f:e7:90:4c'}, 'bond0': > {'addr': '', 'cfg': {}, 'mtu': '1500', 'netmask': '', 'slaves': [], > 'hwaddr': 'de:c5:12:4e:17:6f'}, 'bond1': {'addr': '', 'cfg': {}, 'mtu': > '1500', 'netmask': '', 'slaves': [], 'hwaddr': '2e:ec:3b:01:ab:de'}, > 'bond2': {'addr': '', 'cfg': {}, 'mtu': '1500', 'netmask': '', 'slaves': > [], 'hwaddr': 'da:88:61:cb:0d:ed'}, 'bond3': {'addr': '', 'cfg': {}, > 'mtu': '1500', 'netmask': '', 'slaves': [], 'hwaddr': '72:c4:9e:9d:25:c1'}} > bridges = {'ovirtmgmt': {'addr': '10.66.10.186', 'cfg': > {'PEERROUTES': 'yes', 'IPV6INIT': 'yes', 'TYPE': 'Bridge', > 'IPV6_PEERDNS': 'yes', 'DEFROUTE': 'yes', 'ONBOOT': 'yes', 'PEERDNS': > 'yes', 'IPV4_FAILURE_FATAL': 'no', 'DELAY': '0', 'NM_CONTROLLED': 'no', > 'BOOTPROTO': 'dhcp', 'DEVICE': 'ovirtmgmt', 'IPV6_FAILURE_FATAL': 'no', > 'IPV6_PEERROUTES': 'yes', 'IPV6_DEFROUTE': 'yes', 'IPV6_AUTOCONF': > 'yes', 'UUID': '447b16c1-184a-4347-a801-ef8143c2d932'}, 'mtu': '1500', > 'netmask': '255.255.252.0', 'stp': 'off', 'ports': ['em1']}} > clusterLevels = ['3.0', '3.1', '3.2'] > cpuCores = 4 > cpuFlags = > fpu,vme,de,pse,tsc,msr,pae,mce,cx8,apic,sep,mtrr,pge,mca,cmov,pat,pse36,clflush,dts,acpi,mmx,fxsr,sse,sse2,ss,ht,tm,pbe,syscall,nx,lm,constant_tsc,arch_perfmon,pebs,bts,rep_good,nopl,aperfmperf,pni,dtes64,monitor,ds_cpl,vmx,smx,est,tm2,ssse3,cx16,xtpr,pdcm,sse4_1,xsave,lahf_lm,dtherm,tpr_shadow,vnmi,flexpriority,model_Conroe,model_coreduo,model_core2duo,model_Penryn,model_n270 > cpuModel = Intel(R) Core(TM)2 Quad CPU Q9400 @ 2.66GHz > cpuSockets = 1 > cpuSpeed = 2660.126 > cpuThreads = 4 > emulatedMachines = ['clipper', 'none'] > guestOverhead = 65 > hooks = {} > kvmEnabled = true > lastClient = 10.66.105.101 > lastClientIface = ovirtmgmt > management_ip = > memSize = 3888 > netConfigDirty = False > networks = {'ovirtmgmt': {'iface': 'ovirtmgmt', 'addr': > '10.66.10.186', 'cfg': {'PEERROUTES': 'yes', 'IPV6INIT': 'yes', 'TYPE': > 'Bridge', 'IPV6_PEERDNS': 'yes', 'DEFROUTE': 'yes', 'ONBOOT': 'yes', > 'PEERDNS': 'yes', 'IPV4_FAILURE_FATAL': 'no', 'DELAY': '0', > 'NM_CONTROLLED': 'no', 'BOOTPROTO': 'dhcp', 'DEVICE': 'ovirtmgmt', > 'IPV6_FAILURE_FATAL': 'no', 'IPV6_PEERROUTES': 'yes', 'IPV6_DEFROUTE': > 'yes', 'IPV6_AUTOCONF': 'yes', 'UUID': > '447b16c1-184a-4347-a801-ef8143c2d932'}, 'mtu': '1500', 'netmask': > '255.255.252.0', 'stp': 'off', 'bridged': True, 'gateway': > '10.66.11.254', 'ports': ['em1']}} > nics = {'em1': {'addr': '', 'cfg': {'PEERROUTES': 'yes', 'BRIDGE': > 'ovirtmgmt', 'DEVICE': 'em1', 'IPV6INIT': 'yes', 'IPV6_PEERDNS': 'yes', > 'DEFROUTE': 'yes', 'ONBOOT': 'yes', 'PEERDNS': 'yes', > 'IPV4_FAILURE_FATAL': 'no', 'NM_CONTROLLED': 'no', 'IPV6_DEFROUTE': > 'yes', 'IPV6_AUTOCONF': 'yes', 'IPV6_FAILURE_FATAL': 'no', > 'IPV6_PEERROUTES': 'yes', 'HWADDR': '00:23:ae:9d:85:32', 'UUID': > '447b16c1-184a-4347-a801-ef8143c2d932'}, 'mtu': '1500', 'netmask': '', > 'hwaddr': '00:23:ae:9d:85:32', 'speed': 1000}} > operatingSystem = {'release': '4', 'version': '19', 'name': 'Fedora'} > packages2 = {'kernel': {'release': '200.fc19.x86_64', 'buildtime': > 1383545343.0, 'version': '3.11.7'}, 'spice-server': {'release': > '3.fc19', 'buildtime': 1383130020, 'version': '0.12.4'}, 'vdsm': > {'release': '18.fc19', 'buildtime': 1373484771, 'version': '4.10.3'}, > 'qemu-kvm': {'release': '13.fc19', 'buildtime': 1383700301, 'version': > '1.4.2'}, 'libvirt': {'release': '1.fc19', 'buildtime': 1383765188, > 'version': '1.0.5.7'}, 'qemu-img': {'release': '13.fc19', 'buildtime': > 1383700301, 'version': '1.4.2'}, 'mom': {'release': '1.fc19', > 'buildtime': 1373298035, 'version': '0.3.1'}} > reservedMem = 321 > software_revision = 18 > software_version = 4.10 > supportedENGINEs = ['3.0', '3.1'] > supportedProtocols = ['2.2', '2.3'] > uuid = 44454C4C-4C00-1031-8053-CAC04F4E3258 > version_name = Snow Man > vlans = {} > vmTypes = ['kvm'] > > 3. the vdsm.log is cutting to small size, if some useful logs isn't in > it, please ask me to re-send it. > > Thanks, > guohua > > On 08/06/2013 03:08 PM, Chen, Wei D wrote: >> The issue is solved by reinstalling host OS. >> >> Best Regards, >> Dave Chen >> >> >>> -----Original Message----- >>> From: Chen, Wei D >>> Sent: Tuesday, August 06, 2013 2:44 PM >>> To: 'Laszlo Hornyak'; Itamar Heim >>> Cc: Zhang, Lijuan;engine-devel at ovirt.org >>> Subject: RE: [Engine-devel] failed to add host into cluster >>> >>> Hi, >>> >>> >>> [root at onode vdsm]# vdsClient -s 0 getVdsCaps >>> HBAInventory = {'iSCSI': [{'InitiatorName': 'iqn.1994-05.com.redhat:9fb571e343'}], 'FC': []} >>> ISCSIInitiatorName = iqn.1994-05.com.redhat:9fb571e343 >>> bondings = {'bond4': {'addr': '', 'cfg': {}, 'mtu': '1500', 'netmask': '', 'slaves': [], 'hwaddr': '0e:00:b7:57:2c:c9'}, >>> 'bond0': {'addr': '', 'cfg': {}, 'mtu': '1500', 'netmask': '', 'slaves': [], 'hwaddr': '32:b3:88:1f:ef:91'}, 'bond1': {'addr': '', >>> 'cfg': {}, 'mtu': '1500', 'netmask': '', 'slaves': [], 'hwaddr': '4e:e5:80:93:ea:d9'}, 'bond2': {'addr': '', 'cfg': {}, 'mtu': >>> '1500', >>> 'netmask': '', 'slaves': [], 'hwaddr': '16:ab:f6:e4:f2:27'}, 'bond3': {'addr': '', 'cfg': {}, 'mtu': '1500', 'netmask': '', >>> 'slaves': >>> [], 'hwaddr': 'ee:55:f5:e7:31:7c'}} >>> bridges = {'ovirtmgmt': {'addr': '10.239.131.217', 'cfg': {'PEERROUTES': 'yes', 'DEVICE': 'ovirtmgmt', 'IPV6INIT': 'yes', >>> 'UUID': 'b6ecfa9d-0deb-4213-9348-11137f76735d', 'IPV6_PEERDNS': 'yes', 'DEFROUTE': 'yes', 'PEERDNS': 'yes', 'IPV4_FAILURE_FATAL': >>> 'no', 'DELAY': '0', 'NM_CONTROLLED': 'no', 'IPV6_DEFROUTE': 'yes', 'IPV6_AUTOCONF': 'yes', 'IPV6_FAILURE_FATAL': 'no', 'TYPE': >>> 'Bridge', 'ONBOOT': 'yes', 'BOOTPROTO': 'dhcp', 'IPV6_PEERROUTES': 'yes'}, 'mtu': '1500', 'netmask': '255.255.255.0', 'stp': 'off', >>> 'ports': ['em1']}} >>> clusterLevels = ['3.0', '3.1', '3.2'] >>> cpuCores = 4 >>> cpuFlags = >>> fpu,vme,de,pse,tsc,msr,pae,mce,cx8,apic,sep,mtrr,pge,mca,cmov,pat,pse36,clflush,dts,acpi,mmx,fxsr,sse,sse2,ss,ht,tm,pbe,syscall,nx,r >>> dtscp,lm,constant_tsc,arch_perfmon,pebs,bts,rep_good,nopl,xtopology,nonstop_tsc,aperfmperf,eagerfpu,pni,pclmulqdq,dtes64,monitor, >>> ds_cpl,vmx,smx,est,tm2,ssse3,cx16,xtpr,pdcm,pcid,sse4_1,sse4_2,x2apic,popcnt,tsc_deadline_timer,aes,xsave,avx,lahf_lm,ida,arat,epb, >>> xsaveopt,pln,pts,dtherm,tpr_shadow,vnmi,flexpriority,ept,vpid,model_Nehalem,model_Conroe,model_coreduo,model_core2duo,model_P >>> enryn,model_Westmere,model_n270,model_SandyBridge >>> cpuModel = Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz >>> cpuSockets = 1 >>> cpuSpeed = 3672.000 >>> cpuThreads = 8 >>> emulatedMachines = ['clipper', 'none'] >>> guestOverhead = 65 >>> hooks = {} >>> kvmEnabled = true >>> lastClient = 10.239.131.222 >>> lastClientIface = ovirtmgmt >>> management_ip = >>> memSize = 7944 >>> netConfigDirty = False >>> networks = {'ovirtmgmt': {'iface': 'ovirtmgmt', 'addr': '10.239.131.217', 'cfg': {'PEERROUTES': 'yes', 'DEVICE': >>> 'ovirtmgmt', >>> 'IPV6INIT': 'yes', 'UUID': 'b6ecfa9d-0deb-4213-9348-11137f76735d', 'IPV6_PEERDNS': 'yes', 'DEFROUTE': 'yes', 'PEERDNS': 'yes', >>> 'IPV4_FAILURE_FATAL': 'no', 'DELAY': '0', 'NM_CONTROLLED': 'no', 'IPV6_DEFROUTE': 'yes', 'IPV6_AUTOCONF': 'yes', >>> 'IPV6_FAILURE_FATAL': >>> 'no', 'TYPE': 'Bridge', 'ONBOOT': 'yes', 'BOOTPROTO': 'dhcp', 'IPV6_PEERROUTES': 'yes'}, 'mtu': '1500', 'netmask': '255.255.255.0', >>> 'stp': 'off', 'bridged': True, 'gateway': '10.239.131.1', 'ports': ['em1']}} >>> nics = {'em1': {'addr': '', 'cfg': {}, 'mtu': '1500', 'netmask': '', 'hwaddr': '2c:41:38:b2:d0:e8', 'speed': 100}} >>> operatingSystem = {'release': '0.5', 'version': '19', 'name': 'Fedora'} >>> packages2 = {'kernel': {'release': '301.fc19.x86_64', 'buildtime': 1368462984.0, 'version': '3.9.2'}, 'spice-server': >>> {'release': '5.fc19', 'buildtime': 1366036951, 'version': '0.12.2'}, 'vdsm': {'release': '18.fc19', 'buildtime': 1373484771, >>> 'version': '4.10.3'}, 'qemu-kvm': {'release': '4.fc19', 'buildtime': 1371653911, 'version': '1.4.2'}, 'libvirt': {'release': >>> '1.fc19', >>> 'buildtime': 1371074681, 'version': '1.0.5.2'}, 'qemu-img': {'release': '4.fc19', 'buildtime': 1371653911, 'version': '1.4.2'}, >>> 'mom': >>> {'release': '2.fc19', 'buildtime': 1374564325, 'version': '0.3.2'}} >>> reservedMem = 321 >>> software_revision = 18 >>> software_version = 4.10 >>> supportedENGINEs = ['3.0', '3.1'] >>> supportedProtocols = ['2.2', '2.3'] >>> uuid = 30BBC800-4F47-11E0-0000-2C4138B2D0E8 >>> version_name = Snow Man >>> vlans = {} >>> vmTypes = ['kvm'] >>> >>> >>> >>> >>> >>> Best Regards, >>> Dave Chen >>> >>> >>>> -----Original Message----- >>>> From: Laszlo Hornyak [mailto:lhornyak at redhat.com] >>>> Sent: Monday, August 05, 2013 8:35 PM >>>> To: Itamar Heim >>>> Cc: Chen, Wei D; Zhang, Lijuan;engine-devel at ovirt.org >>>> Subject: Re: [Engine-devel] failed to add host into cluster >>>> >>>> Hi, >>>> >>>> Dave, could you also share the vdsm log as well? >>>> >>>> I managed to reproduce this on the host that I am using for years and I am using it now, so it should not be a hardware problem. >>>> Probably >>>> some broken configuration caused some problem in vdsm before it would retrieve the capabilities information from libvirt. >>>> >>>> >>>> >>>> ----- Original Message ----- >>>>> From: "Itamar Heim" >>>>> To: "Laszlo Hornyak" >>>>> Cc: "Wei D Chen", "Lijuan Zhang" >>>>> ,engine-devel at ovirt.org >>>>> Sent: Monday, August 5, 2013 2:03:58 PM >>>>> Subject: Re: [Engine-devel] failed to add host into cluster >>>>> >>>>> On 08/05/2013 09:06 AM, Laszlo Hornyak wrote: >>>>>> ----- Original Message ----- >>>>>>> From: "Wei D Chen" >>>>>>> To: "Itamar Heim" >>>>>>> Cc: "Lijuan Zhang",engine-devel at ovirt.org >>>>>>> Sent: Monday, August 5, 2013 8:03:08 AM >>>>>>> Subject: Re: [Engine-devel] failed to add host into cluster >>>>>>> >>>>>>> >>>>>>> >>>>>>> Best Regards, >>>>>>> Dave Chen >>>>>>> >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Itamar Heim [mailto:iheim at redhat.com] >>>>>>>> Sent: Sunday, August 04, 2013 10:25 PM >>>>>>>> To: Chen, Wei D >>>>>>>> Cc:engine-devel at ovirt.org; Zhang, Lijuan >>>>>>>> Subject: Re: [Engine-devel] failed to add host into cluster >>>>>>>> >>>>>>>> On 08/02/2013 09:34 AM, Chen, Wei D wrote: >>>>>>>>> Failed to add a node into cluster. I saw follow hints, but still >>>>>>>>> don't know how to fix it. OS is fedora 19 both for node and >>>>>>>>> engine, anyone can help me? >>>>>>>>> >>>>>>>>> Host *** does not comply with the cluster *** emulated machines. >>>>>>>>> The Hosts emulated machines are clipper,none and the cluster is >>>>>>>>> [rhel6.4.0, pc-1.0]} >>>>>>>> what Os is the host running? >>>>>>> fedora 19 >>>>>>>> what does 'vdsClient -s 0 getVdsCaps' returns? >>>>>>> where to run this command? this command is not recognized both in >>>>>>> engine and node. >>>>>> After installing the host, you should have this command in the host OS. >>>>>> >>>>>>> _______________________________________________ >>>>>>> Engine-devel mailing list >>>>>>> Engine-devel at ovirt.org >>>>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel >>>>>>> >>>>> cat /proc/cpuinfo >>>>> and >>>>> virsh capabilities >>>>> >>>>> are also interesting >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Engine-devel mailing list >>>>> Engine-devel at ovirt.org >>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel > > > > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > your qemu only reports "clipper" as the support emulated machine? From shtripat at redhat.com Thu Nov 21 10:35:41 2013 From: shtripat at redhat.com (Shubhendu Tripathi) Date: Thu, 21 Nov 2013 16:05:41 +0530 Subject: [Engine-devel] IMP: Regarding an issue while translating the error messages for gluster using ErrorTranslator class In-Reply-To: <1134168809.817930.1384183092189.JavaMail.root@redhat.com> References: <527A14E6.8010809@redhat.com> <2115335.RGeYIF2D09@awels> <1082228530.20856483.1383747009016.JavaMail.root@redhat.com> <527DFB60.6020709@redhat.com> <1134168809.817930.1384183092189.JavaMail.root@redhat.com> Message-ID: <528DE1FD.4000007@redhat.com> On 11/11/2013 08:48 PM, Einav Cohen wrote: >> ----- Original Message ----- >> From: "Shubhendu Tripathi" >> Sent: Saturday, November 9, 2013 4:07:44 AM >> >> On 11/06/2013 07:40 PM, Einav Cohen wrote: >>>> ----- 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). >> There is an upstream patch according to Einav's suggestion above. >> http://gerrit.ovirt.org/#/c/21083/ > Many thanks, Shubhendu. > @Derez - any chance that you can take a look (as you probably understand best > this particular code/logic)? Daniel, any comments on the patch ? http://gerrit.ovirt.org/#/c/21083/ > >>>> 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 at ovirt.org >>>> http://lists.ovirt.org/mailman/listinfo/engine-devel >>>> >> _______________________________________________ >> Engine-devel mailing list >> Engine-devel at ovirt.org >> http://lists.ovirt.org/mailman/listinfo/engine-devel >> >> >> > From gouyang at redhat.com Thu Nov 21 10:59:31 2013 From: gouyang at redhat.com (ouyang guohua) Date: Thu, 21 Nov 2013 18:59:31 +0800 Subject: [Engine-devel] failed to add host into cluster In-Reply-To: <528DE1F1.4090603@redhat.com> References: <51FE642C.8040307@redhat.com> <1492863435.5066137.1375682766691.JavaMail.root@redhat.com> <51FF94AE.6030807@redhat.com> <307132015.5144883.1375706091754.JavaMail.root@redhat.com> <528DCD64.5010407@redhat.com> <528DE1F1.4090603@redhat.com> Message-ID: <528DE793.8060500@redhat.com> On 11/21/2013 06:35 PM, Itamar Heim wrote: > On 11/21/2013 11:07 AM, ouyang guohua wrote: >> Hi, >> >> I encounter the same problem today. >> >> Both the engine and the node are fedora 19. >> >> 1. on engine host: >> engine=# select * from vdc_options where option_name ilike '%emu%'; >> option_id | option_name | option_value | version >> -----------+-------------------------+------------------+--------- >> 38 | ClusterEmulatedMachines | rhel6.2.0,pc-1.0 | 3.0 >> 39 | ClusterEmulatedMachines | rhel6.3.0,pc-1.0 | 3.1 >> 40 | ClusterEmulatedMachines | rhel6.4.0,pc-1.0 | 3.2 >> 41 | ClusterEmulatedMachines | rhel6.4.0,pc-1.0 | 3.3 >> (4 rows) >> >> engine=# select name,emulated_machine from vds_groups; >> name | emulated_machine >> ---------------------+------------------ >> Default | >> fedora19-cluster | pc-1.0 >> fedora19-node-Local | pc-1.0 >> (3 rows) >> >> 2. on node: >> # vdsClient -s 0 getVdsCaps >> HBAInventory = {'iSCSI': [{'InitiatorName': >> 'iqn.1994-05.com.redhat:643bb46781e'}], 'FC': []} >> ISCSIInitiatorName = iqn.1994-05.com.redhat:643bb46781e >> bondings = {'bond4': {'addr': '', 'cfg': {}, 'mtu': '1500', >> 'netmask': '', 'slaves': [], 'hwaddr': '7e:00:7f:e7:90:4c'}, 'bond0': >> {'addr': '', 'cfg': {}, 'mtu': '1500', 'netmask': '', 'slaves': [], >> 'hwaddr': 'de:c5:12:4e:17:6f'}, 'bond1': {'addr': '', 'cfg': {}, 'mtu': >> '1500', 'netmask': '', 'slaves': [], 'hwaddr': '2e:ec:3b:01:ab:de'}, >> 'bond2': {'addr': '', 'cfg': {}, 'mtu': '1500', 'netmask': '', 'slaves': >> [], 'hwaddr': 'da:88:61:cb:0d:ed'}, 'bond3': {'addr': '', 'cfg': {}, >> 'mtu': '1500', 'netmask': '', 'slaves': [], 'hwaddr': >> '72:c4:9e:9d:25:c1'}} >> bridges = {'ovirtmgmt': {'addr': '10.66.10.186', 'cfg': >> {'PEERROUTES': 'yes', 'IPV6INIT': 'yes', 'TYPE': 'Bridge', >> 'IPV6_PEERDNS': 'yes', 'DEFROUTE': 'yes', 'ONBOOT': 'yes', 'PEERDNS': >> 'yes', 'IPV4_FAILURE_FATAL': 'no', 'DELAY': '0', 'NM_CONTROLLED': 'no', >> 'BOOTPROTO': 'dhcp', 'DEVICE': 'ovirtmgmt', 'IPV6_FAILURE_FATAL': 'no', >> 'IPV6_PEERROUTES': 'yes', 'IPV6_DEFROUTE': 'yes', 'IPV6_AUTOCONF': >> 'yes', 'UUID': '447b16c1-184a-4347-a801-ef8143c2d932'}, 'mtu': '1500', >> 'netmask': '255.255.252.0', 'stp': 'off', 'ports': ['em1']}} >> clusterLevels = ['3.0', '3.1', '3.2'] >> cpuCores = 4 >> cpuFlags = >> fpu,vme,de,pse,tsc,msr,pae,mce,cx8,apic,sep,mtrr,pge,mca,cmov,pat,pse36,clflush,dts,acpi,mmx,fxsr,sse,sse2,ss,ht,tm,pbe,syscall,nx,lm,constant_tsc,arch_perfmon,pebs,bts,rep_good,nopl,aperfmperf,pni,dtes64,monitor,ds_cpl,vmx,smx,est,tm2,ssse3,cx16,xtpr,pdcm,sse4_1,xsave,lahf_lm,dtherm,tpr_shadow,vnmi,flexpriority,model_Conroe,model_coreduo,model_core2duo,model_Penryn,model_n270 >> >> cpuModel = Intel(R) Core(TM)2 Quad CPU Q9400 @ 2.66GHz >> cpuSockets = 1 >> cpuSpeed = 2660.126 >> cpuThreads = 4 >> emulatedMachines = ['clipper', 'none'] >> guestOverhead = 65 >> hooks = {} >> kvmEnabled = true >> lastClient = 10.66.105.101 >> lastClientIface = ovirtmgmt >> management_ip = >> memSize = 3888 >> netConfigDirty = False >> networks = {'ovirtmgmt': {'iface': 'ovirtmgmt', 'addr': >> '10.66.10.186', 'cfg': {'PEERROUTES': 'yes', 'IPV6INIT': 'yes', 'TYPE': >> 'Bridge', 'IPV6_PEERDNS': 'yes', 'DEFROUTE': 'yes', 'ONBOOT': 'yes', >> 'PEERDNS': 'yes', 'IPV4_FAILURE_FATAL': 'no', 'DELAY': '0', >> 'NM_CONTROLLED': 'no', 'BOOTPROTO': 'dhcp', 'DEVICE': 'ovirtmgmt', >> 'IPV6_FAILURE_FATAL': 'no', 'IPV6_PEERROUTES': 'yes', 'IPV6_DEFROUTE': >> 'yes', 'IPV6_AUTOCONF': 'yes', 'UUID': >> '447b16c1-184a-4347-a801-ef8143c2d932'}, 'mtu': '1500', 'netmask': >> '255.255.252.0', 'stp': 'off', 'bridged': True, 'gateway': >> '10.66.11.254', 'ports': ['em1']}} >> nics = {'em1': {'addr': '', 'cfg': {'PEERROUTES': 'yes', 'BRIDGE': >> 'ovirtmgmt', 'DEVICE': 'em1', 'IPV6INIT': 'yes', 'IPV6_PEERDNS': 'yes', >> 'DEFROUTE': 'yes', 'ONBOOT': 'yes', 'PEERDNS': 'yes', >> 'IPV4_FAILURE_FATAL': 'no', 'NM_CONTROLLED': 'no', 'IPV6_DEFROUTE': >> 'yes', 'IPV6_AUTOCONF': 'yes', 'IPV6_FAILURE_FATAL': 'no', >> 'IPV6_PEERROUTES': 'yes', 'HWADDR': '00:23:ae:9d:85:32', 'UUID': >> '447b16c1-184a-4347-a801-ef8143c2d932'}, 'mtu': '1500', 'netmask': '', >> 'hwaddr': '00:23:ae:9d:85:32', 'speed': 1000}} >> operatingSystem = {'release': '4', 'version': '19', 'name': >> 'Fedora'} >> packages2 = {'kernel': {'release': '200.fc19.x86_64', 'buildtime': >> 1383545343.0, 'version': '3.11.7'}, 'spice-server': {'release': >> '3.fc19', 'buildtime': 1383130020, 'version': '0.12.4'}, 'vdsm': >> {'release': '18.fc19', 'buildtime': 1373484771, 'version': '4.10.3'}, >> 'qemu-kvm': {'release': '13.fc19', 'buildtime': 1383700301, 'version': >> '1.4.2'}, 'libvirt': {'release': '1.fc19', 'buildtime': 1383765188, >> 'version': '1.0.5.7'}, 'qemu-img': {'release': '13.fc19', 'buildtime': >> 1383700301, 'version': '1.4.2'}, 'mom': {'release': '1.fc19', >> 'buildtime': 1373298035, 'version': '0.3.1'}} >> reservedMem = 321 >> software_revision = 18 >> software_version = 4.10 >> supportedENGINEs = ['3.0', '3.1'] >> supportedProtocols = ['2.2', '2.3'] >> uuid = 44454C4C-4C00-1031-8053-CAC04F4E3258 >> version_name = Snow Man >> vlans = {} >> vmTypes = ['kvm'] >> >> 3. the vdsm.log is cutting to small size, if some useful logs isn't in >> it, please ask me to re-send it. >> >> Thanks, >> guohua >> >> On 08/06/2013 03:08 PM, Chen, Wei D wrote: >>> The issue is solved by reinstalling host OS. >>> >>> Best Regards, >>> Dave Chen >>> >>> >>>> -----Original Message----- >>>> From: Chen, Wei D >>>> Sent: Tuesday, August 06, 2013 2:44 PM >>>> To: 'Laszlo Hornyak'; Itamar Heim >>>> Cc: Zhang, Lijuan;engine-devel at ovirt.org >>>> Subject: RE: [Engine-devel] failed to add host into cluster >>>> >>>> Hi, >>>> >>>> >>>> [root at onode vdsm]# vdsClient -s 0 getVdsCaps >>>> HBAInventory = {'iSCSI': [{'InitiatorName': >>>> 'iqn.1994-05.com.redhat:9fb571e343'}], 'FC': []} >>>> ISCSIInitiatorName = iqn.1994-05.com.redhat:9fb571e343 >>>> bondings = {'bond4': {'addr': '', 'cfg': {}, 'mtu': >>>> '1500', 'netmask': '', 'slaves': [], 'hwaddr': '0e:00:b7:57:2c:c9'}, >>>> 'bond0': {'addr': '', 'cfg': {}, 'mtu': '1500', 'netmask': '', >>>> 'slaves': [], 'hwaddr': '32:b3:88:1f:ef:91'}, 'bond1': {'addr': '', >>>> 'cfg': {}, 'mtu': '1500', 'netmask': '', 'slaves': [], 'hwaddr': >>>> '4e:e5:80:93:ea:d9'}, 'bond2': {'addr': '', 'cfg': {}, 'mtu': >>>> '1500', >>>> 'netmask': '', 'slaves': [], 'hwaddr': '16:ab:f6:e4:f2:27'}, >>>> 'bond3': {'addr': '', 'cfg': {}, 'mtu': '1500', 'netmask': '', >>>> 'slaves': >>>> [], 'hwaddr': 'ee:55:f5:e7:31:7c'}} >>>> bridges = {'ovirtmgmt': {'addr': '10.239.131.217', 'cfg': >>>> {'PEERROUTES': 'yes', 'DEVICE': 'ovirtmgmt', 'IPV6INIT': 'yes', >>>> 'UUID': 'b6ecfa9d-0deb-4213-9348-11137f76735d', 'IPV6_PEERDNS': >>>> 'yes', 'DEFROUTE': 'yes', 'PEERDNS': 'yes', 'IPV4_FAILURE_FATAL': >>>> 'no', 'DELAY': '0', 'NM_CONTROLLED': 'no', 'IPV6_DEFROUTE': 'yes', >>>> 'IPV6_AUTOCONF': 'yes', 'IPV6_FAILURE_FATAL': 'no', 'TYPE': >>>> 'Bridge', 'ONBOOT': 'yes', 'BOOTPROTO': 'dhcp', 'IPV6_PEERROUTES': >>>> 'yes'}, 'mtu': '1500', 'netmask': '255.255.255.0', 'stp': 'off', >>>> 'ports': ['em1']}} >>>> clusterLevels = ['3.0', '3.1', '3.2'] >>>> cpuCores = 4 >>>> cpuFlags = >>>> fpu,vme,de,pse,tsc,msr,pae,mce,cx8,apic,sep,mtrr,pge,mca,cmov,pat,pse36,clflush,dts,acpi,mmx,fxsr,sse,sse2,ss,ht,tm,pbe,syscall,nx,r >>>> >>>> dtscp,lm,constant_tsc,arch_perfmon,pebs,bts,rep_good,nopl,xtopology,nonstop_tsc,aperfmperf,eagerfpu,pni,pclmulqdq,dtes64,monitor, >>>> >>>> ds_cpl,vmx,smx,est,tm2,ssse3,cx16,xtpr,pdcm,pcid,sse4_1,sse4_2,x2apic,popcnt,tsc_deadline_timer,aes,xsave,avx,lahf_lm,ida,arat,epb, >>>> >>>> xsaveopt,pln,pts,dtherm,tpr_shadow,vnmi,flexpriority,ept,vpid,model_Nehalem,model_Conroe,model_coreduo,model_core2duo,model_P >>>> >>>> enryn,model_Westmere,model_n270,model_SandyBridge >>>> cpuModel = Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz >>>> cpuSockets = 1 >>>> cpuSpeed = 3672.000 >>>> cpuThreads = 8 >>>> emulatedMachines = ['clipper', 'none'] >>>> guestOverhead = 65 >>>> hooks = {} >>>> kvmEnabled = true >>>> lastClient = 10.239.131.222 >>>> lastClientIface = ovirtmgmt >>>> management_ip = >>>> memSize = 7944 >>>> netConfigDirty = False >>>> networks = {'ovirtmgmt': {'iface': 'ovirtmgmt', 'addr': >>>> '10.239.131.217', 'cfg': {'PEERROUTES': 'yes', 'DEVICE': >>>> 'ovirtmgmt', >>>> 'IPV6INIT': 'yes', 'UUID': 'b6ecfa9d-0deb-4213-9348-11137f76735d', >>>> 'IPV6_PEERDNS': 'yes', 'DEFROUTE': 'yes', 'PEERDNS': 'yes', >>>> 'IPV4_FAILURE_FATAL': 'no', 'DELAY': '0', 'NM_CONTROLLED': 'no', >>>> 'IPV6_DEFROUTE': 'yes', 'IPV6_AUTOCONF': 'yes', >>>> 'IPV6_FAILURE_FATAL': >>>> 'no', 'TYPE': 'Bridge', 'ONBOOT': 'yes', 'BOOTPROTO': 'dhcp', >>>> 'IPV6_PEERROUTES': 'yes'}, 'mtu': '1500', 'netmask': '255.255.255.0', >>>> 'stp': 'off', 'bridged': True, 'gateway': '10.239.131.1', 'ports': >>>> ['em1']}} >>>> nics = {'em1': {'addr': '', 'cfg': {}, 'mtu': '1500', >>>> 'netmask': '', 'hwaddr': '2c:41:38:b2:d0:e8', 'speed': 100}} >>>> operatingSystem = {'release': '0.5', 'version': '19', >>>> 'name': 'Fedora'} >>>> packages2 = {'kernel': {'release': '301.fc19.x86_64', >>>> 'buildtime': 1368462984.0, 'version': '3.9.2'}, 'spice-server': >>>> {'release': '5.fc19', 'buildtime': 1366036951, 'version': >>>> '0.12.2'}, 'vdsm': {'release': '18.fc19', 'buildtime': 1373484771, >>>> 'version': '4.10.3'}, 'qemu-kvm': {'release': '4.fc19', >>>> 'buildtime': 1371653911, 'version': '1.4.2'}, 'libvirt': {'release': >>>> '1.fc19', >>>> 'buildtime': 1371074681, 'version': '1.0.5.2'}, 'qemu-img': >>>> {'release': '4.fc19', 'buildtime': 1371653911, 'version': '1.4.2'}, >>>> 'mom': >>>> {'release': '2.fc19', 'buildtime': 1374564325, 'version': '0.3.2'}} >>>> reservedMem = 321 >>>> software_revision = 18 >>>> software_version = 4.10 >>>> supportedENGINEs = ['3.0', '3.1'] >>>> supportedProtocols = ['2.2', '2.3'] >>>> uuid = 30BBC800-4F47-11E0-0000-2C4138B2D0E8 >>>> version_name = Snow Man >>>> vlans = {} >>>> vmTypes = ['kvm'] >>>> >>>> >>>> >>>> >>>> >>>> Best Regards, >>>> Dave Chen >>>> >>>> >>>>> -----Original Message----- >>>>> From: Laszlo Hornyak [mailto:lhornyak at redhat.com] >>>>> Sent: Monday, August 05, 2013 8:35 PM >>>>> To: Itamar Heim >>>>> Cc: Chen, Wei D; Zhang, Lijuan;engine-devel at ovirt.org >>>>> Subject: Re: [Engine-devel] failed to add host into cluster >>>>> >>>>> Hi, >>>>> >>>>> Dave, could you also share the vdsm log as well? >>>>> >>>>> I managed to reproduce this on the host that I am using for years >>>>> and I am using it now, so it should not be a hardware problem. >>>>> Probably >>>>> some broken configuration caused some problem in vdsm before it >>>>> would retrieve the capabilities information from libvirt. >>>>> >>>>> >>>>> >>>>> ----- Original Message ----- >>>>>> From: "Itamar Heim" >>>>>> To: "Laszlo Hornyak" >>>>>> Cc: "Wei D Chen", "Lijuan Zhang" >>>>>> ,engine-devel at ovirt.org >>>>>> Sent: Monday, August 5, 2013 2:03:58 PM >>>>>> Subject: Re: [Engine-devel] failed to add host into cluster >>>>>> >>>>>> On 08/05/2013 09:06 AM, Laszlo Hornyak wrote: >>>>>>> ----- Original Message ----- >>>>>>>> From: "Wei D Chen" >>>>>>>> To: "Itamar Heim" >>>>>>>> Cc: "Lijuan Zhang",engine-devel at ovirt.org >>>>>>>> Sent: Monday, August 5, 2013 8:03:08 AM >>>>>>>> Subject: Re: [Engine-devel] failed to add host into cluster >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Best Regards, >>>>>>>> Dave Chen >>>>>>>> >>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: Itamar Heim [mailto:iheim at redhat.com] >>>>>>>>> Sent: Sunday, August 04, 2013 10:25 PM >>>>>>>>> To: Chen, Wei D >>>>>>>>> Cc:engine-devel at ovirt.org; Zhang, Lijuan >>>>>>>>> Subject: Re: [Engine-devel] failed to add host into cluster >>>>>>>>> >>>>>>>>> On 08/02/2013 09:34 AM, Chen, Wei D wrote: >>>>>>>>>> Failed to add a node into cluster. I saw follow hints, but still >>>>>>>>>> don't know how to fix it. OS is fedora 19 both for node and >>>>>>>>>> engine, anyone can help me? >>>>>>>>>> >>>>>>>>>> Host *** does not comply with the cluster *** emulated machines. >>>>>>>>>> The Hosts emulated machines are clipper,none and the cluster is >>>>>>>>>> [rhel6.4.0, pc-1.0]} >>>>>>>>> what Os is the host running? >>>>>>>> fedora 19 >>>>>>>>> what does 'vdsClient -s 0 getVdsCaps' returns? >>>>>>>> where to run this command? this command is not recognized both in >>>>>>>> engine and node. >>>>>>> After installing the host, you should have this command in the >>>>>>> host OS. >>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Engine-devel mailing list >>>>>>>> Engine-devel at ovirt.org >>>>>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel >>>>>>>> >>>>>> cat /proc/cpuinfo >>>>>> and >>>>>> virsh capabilities >>>>>> >>>>>> are also interesting >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Engine-devel mailing list >>>>>> Engine-devel at ovirt.org >>>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel >> >> >> >> _______________________________________________ >> Engine-devel mailing list >> Engine-devel at ovirt.org >> http://lists.ovirt.org/mailman/listinfo/engine-devel >> > > your qemu only reports "clipper" as the support emulated machine? Yes, it is. Same to Chenwei's results. Could the problem be solved without re-install the os? From iheim at redhat.com Thu Nov 21 11:02:48 2013 From: iheim at redhat.com (Itamar Heim) Date: Thu, 21 Nov 2013 13:02:48 +0200 Subject: [Engine-devel] failed to add host into cluster In-Reply-To: <528DE793.8060500@redhat.com> References: <51FE642C.8040307@redhat.com> <1492863435.5066137.1375682766691.JavaMail.root@redhat.com> <51FF94AE.6030807@redhat.com> <307132015.5144883.1375706091754.JavaMail.root@redhat.com> <528DCD64.5010407@redhat.com> <528DE1F1.4090603@redhat.com> <528DE793.8060500@redhat.com> Message-ID: <528DE858.6080502@redhat.com> On 11/21/2013 12:59 PM, ouyang guohua wrote: > On 11/21/2013 06:35 PM, Itamar Heim wrote: >> On 11/21/2013 11:07 AM, ouyang guohua wrote: >>> Hi, >>> >>> I encounter the same problem today. >>> >>> Both the engine and the node are fedora 19. >>> >>> 1. on engine host: >>> engine=# select * from vdc_options where option_name ilike '%emu%'; >>> option_id | option_name | option_value | version >>> -----------+-------------------------+------------------+--------- >>> 38 | ClusterEmulatedMachines | rhel6.2.0,pc-1.0 | 3.0 >>> 39 | ClusterEmulatedMachines | rhel6.3.0,pc-1.0 | 3.1 >>> 40 | ClusterEmulatedMachines | rhel6.4.0,pc-1.0 | 3.2 >>> 41 | ClusterEmulatedMachines | rhel6.4.0,pc-1.0 | 3.3 >>> (4 rows) >>> >>> engine=# select name,emulated_machine from vds_groups; >>> name | emulated_machine >>> ---------------------+------------------ >>> Default | >>> fedora19-cluster | pc-1.0 >>> fedora19-node-Local | pc-1.0 >>> (3 rows) >>> >>> 2. on node: >>> # vdsClient -s 0 getVdsCaps >>> HBAInventory = {'iSCSI': [{'InitiatorName': >>> 'iqn.1994-05.com.redhat:643bb46781e'}], 'FC': []} >>> ISCSIInitiatorName = iqn.1994-05.com.redhat:643bb46781e >>> bondings = {'bond4': {'addr': '', 'cfg': {}, 'mtu': '1500', >>> 'netmask': '', 'slaves': [], 'hwaddr': '7e:00:7f:e7:90:4c'}, 'bond0': >>> {'addr': '', 'cfg': {}, 'mtu': '1500', 'netmask': '', 'slaves': [], >>> 'hwaddr': 'de:c5:12:4e:17:6f'}, 'bond1': {'addr': '', 'cfg': {}, 'mtu': >>> '1500', 'netmask': '', 'slaves': [], 'hwaddr': '2e:ec:3b:01:ab:de'}, >>> 'bond2': {'addr': '', 'cfg': {}, 'mtu': '1500', 'netmask': '', 'slaves': >>> [], 'hwaddr': 'da:88:61:cb:0d:ed'}, 'bond3': {'addr': '', 'cfg': {}, >>> 'mtu': '1500', 'netmask': '', 'slaves': [], 'hwaddr': >>> '72:c4:9e:9d:25:c1'}} >>> bridges = {'ovirtmgmt': {'addr': '10.66.10.186', 'cfg': >>> {'PEERROUTES': 'yes', 'IPV6INIT': 'yes', 'TYPE': 'Bridge', >>> 'IPV6_PEERDNS': 'yes', 'DEFROUTE': 'yes', 'ONBOOT': 'yes', 'PEERDNS': >>> 'yes', 'IPV4_FAILURE_FATAL': 'no', 'DELAY': '0', 'NM_CONTROLLED': 'no', >>> 'BOOTPROTO': 'dhcp', 'DEVICE': 'ovirtmgmt', 'IPV6_FAILURE_FATAL': 'no', >>> 'IPV6_PEERROUTES': 'yes', 'IPV6_DEFROUTE': 'yes', 'IPV6_AUTOCONF': >>> 'yes', 'UUID': '447b16c1-184a-4347-a801-ef8143c2d932'}, 'mtu': '1500', >>> 'netmask': '255.255.252.0', 'stp': 'off', 'ports': ['em1']}} >>> clusterLevels = ['3.0', '3.1', '3.2'] >>> cpuCores = 4 >>> cpuFlags = >>> fpu,vme,de,pse,tsc,msr,pae,mce,cx8,apic,sep,mtrr,pge,mca,cmov,pat,pse36,clflush,dts,acpi,mmx,fxsr,sse,sse2,ss,ht,tm,pbe,syscall,nx,lm,constant_tsc,arch_perfmon,pebs,bts,rep_good,nopl,aperfmperf,pni,dtes64,monitor,ds_cpl,vmx,smx,est,tm2,ssse3,cx16,xtpr,pdcm,sse4_1,xsave,lahf_lm,dtherm,tpr_shadow,vnmi,flexpriority,model_Conroe,model_coreduo,model_core2duo,model_Penryn,model_n270 >>> >>> cpuModel = Intel(R) Core(TM)2 Quad CPU Q9400 @ 2.66GHz >>> cpuSockets = 1 >>> cpuSpeed = 2660.126 >>> cpuThreads = 4 >>> emulatedMachines = ['clipper', 'none'] >>> guestOverhead = 65 >>> hooks = {} >>> kvmEnabled = true >>> lastClient = 10.66.105.101 >>> lastClientIface = ovirtmgmt >>> management_ip = >>> memSize = 3888 >>> netConfigDirty = False >>> networks = {'ovirtmgmt': {'iface': 'ovirtmgmt', 'addr': >>> '10.66.10.186', 'cfg': {'PEERROUTES': 'yes', 'IPV6INIT': 'yes', 'TYPE': >>> 'Bridge', 'IPV6_PEERDNS': 'yes', 'DEFROUTE': 'yes', 'ONBOOT': 'yes', >>> 'PEERDNS': 'yes', 'IPV4_FAILURE_FATAL': 'no', 'DELAY': '0', >>> 'NM_CONTROLLED': 'no', 'BOOTPROTO': 'dhcp', 'DEVICE': 'ovirtmgmt', >>> 'IPV6_FAILURE_FATAL': 'no', 'IPV6_PEERROUTES': 'yes', 'IPV6_DEFROUTE': >>> 'yes', 'IPV6_AUTOCONF': 'yes', 'UUID': >>> '447b16c1-184a-4347-a801-ef8143c2d932'}, 'mtu': '1500', 'netmask': >>> '255.255.252.0', 'stp': 'off', 'bridged': True, 'gateway': >>> '10.66.11.254', 'ports': ['em1']}} >>> nics = {'em1': {'addr': '', 'cfg': {'PEERROUTES': 'yes', 'BRIDGE': >>> 'ovirtmgmt', 'DEVICE': 'em1', 'IPV6INIT': 'yes', 'IPV6_PEERDNS': 'yes', >>> 'DEFROUTE': 'yes', 'ONBOOT': 'yes', 'PEERDNS': 'yes', >>> 'IPV4_FAILURE_FATAL': 'no', 'NM_CONTROLLED': 'no', 'IPV6_DEFROUTE': >>> 'yes', 'IPV6_AUTOCONF': 'yes', 'IPV6_FAILURE_FATAL': 'no', >>> 'IPV6_PEERROUTES': 'yes', 'HWADDR': '00:23:ae:9d:85:32', 'UUID': >>> '447b16c1-184a-4347-a801-ef8143c2d932'}, 'mtu': '1500', 'netmask': '', >>> 'hwaddr': '00:23:ae:9d:85:32', 'speed': 1000}} >>> operatingSystem = {'release': '4', 'version': '19', 'name': >>> 'Fedora'} >>> packages2 = {'kernel': {'release': '200.fc19.x86_64', 'buildtime': >>> 1383545343.0, 'version': '3.11.7'}, 'spice-server': {'release': >>> '3.fc19', 'buildtime': 1383130020, 'version': '0.12.4'}, 'vdsm': >>> {'release': '18.fc19', 'buildtime': 1373484771, 'version': '4.10.3'}, >>> 'qemu-kvm': {'release': '13.fc19', 'buildtime': 1383700301, 'version': >>> '1.4.2'}, 'libvirt': {'release': '1.fc19', 'buildtime': 1383765188, >>> 'version': '1.0.5.7'}, 'qemu-img': {'release': '13.fc19', 'buildtime': >>> 1383700301, 'version': '1.4.2'}, 'mom': {'release': '1.fc19', >>> 'buildtime': 1373298035, 'version': '0.3.1'}} >>> reservedMem = 321 >>> software_revision = 18 >>> software_version = 4.10 >>> supportedENGINEs = ['3.0', '3.1'] >>> supportedProtocols = ['2.2', '2.3'] >>> uuid = 44454C4C-4C00-1031-8053-CAC04F4E3258 >>> version_name = Snow Man >>> vlans = {} >>> vmTypes = ['kvm'] >>> >>> 3. the vdsm.log is cutting to small size, if some useful logs isn't in >>> it, please ask me to re-send it. >>> >>> Thanks, >>> guohua >>> >>> On 08/06/2013 03:08 PM, Chen, Wei D wrote: >>>> The issue is solved by reinstalling host OS. >>>> >>>> Best Regards, >>>> Dave Chen >>>> >>>> >>>>> -----Original Message----- >>>>> From: Chen, Wei D >>>>> Sent: Tuesday, August 06, 2013 2:44 PM >>>>> To: 'Laszlo Hornyak'; Itamar Heim >>>>> Cc: Zhang, Lijuan;engine-devel at ovirt.org >>>>> Subject: RE: [Engine-devel] failed to add host into cluster >>>>> >>>>> Hi, >>>>> >>>>> >>>>> [root at onode vdsm]# vdsClient -s 0 getVdsCaps >>>>> HBAInventory = {'iSCSI': [{'InitiatorName': >>>>> 'iqn.1994-05.com.redhat:9fb571e343'}], 'FC': []} >>>>> ISCSIInitiatorName = iqn.1994-05.com.redhat:9fb571e343 >>>>> bondings = {'bond4': {'addr': '', 'cfg': {}, 'mtu': >>>>> '1500', 'netmask': '', 'slaves': [], 'hwaddr': '0e:00:b7:57:2c:c9'}, >>>>> 'bond0': {'addr': '', 'cfg': {}, 'mtu': '1500', 'netmask': '', >>>>> 'slaves': [], 'hwaddr': '32:b3:88:1f:ef:91'}, 'bond1': {'addr': '', >>>>> 'cfg': {}, 'mtu': '1500', 'netmask': '', 'slaves': [], 'hwaddr': >>>>> '4e:e5:80:93:ea:d9'}, 'bond2': {'addr': '', 'cfg': {}, 'mtu': >>>>> '1500', >>>>> 'netmask': '', 'slaves': [], 'hwaddr': '16:ab:f6:e4:f2:27'}, >>>>> 'bond3': {'addr': '', 'cfg': {}, 'mtu': '1500', 'netmask': '', >>>>> 'slaves': >>>>> [], 'hwaddr': 'ee:55:f5:e7:31:7c'}} >>>>> bridges = {'ovirtmgmt': {'addr': '10.239.131.217', 'cfg': >>>>> {'PEERROUTES': 'yes', 'DEVICE': 'ovirtmgmt', 'IPV6INIT': 'yes', >>>>> 'UUID': 'b6ecfa9d-0deb-4213-9348-11137f76735d', 'IPV6_PEERDNS': >>>>> 'yes', 'DEFROUTE': 'yes', 'PEERDNS': 'yes', 'IPV4_FAILURE_FATAL': >>>>> 'no', 'DELAY': '0', 'NM_CONTROLLED': 'no', 'IPV6_DEFROUTE': 'yes', >>>>> 'IPV6_AUTOCONF': 'yes', 'IPV6_FAILURE_FATAL': 'no', 'TYPE': >>>>> 'Bridge', 'ONBOOT': 'yes', 'BOOTPROTO': 'dhcp', 'IPV6_PEERROUTES': >>>>> 'yes'}, 'mtu': '1500', 'netmask': '255.255.255.0', 'stp': 'off', >>>>> 'ports': ['em1']}} >>>>> clusterLevels = ['3.0', '3.1', '3.2'] >>>>> cpuCores = 4 >>>>> cpuFlags = >>>>> fpu,vme,de,pse,tsc,msr,pae,mce,cx8,apic,sep,mtrr,pge,mca,cmov,pat,pse36,clflush,dts,acpi,mmx,fxsr,sse,sse2,ss,ht,tm,pbe,syscall,nx,r >>>>> >>>>> dtscp,lm,constant_tsc,arch_perfmon,pebs,bts,rep_good,nopl,xtopology,nonstop_tsc,aperfmperf,eagerfpu,pni,pclmulqdq,dtes64,monitor, >>>>> >>>>> ds_cpl,vmx,smx,est,tm2,ssse3,cx16,xtpr,pdcm,pcid,sse4_1,sse4_2,x2apic,popcnt,tsc_deadline_timer,aes,xsave,avx,lahf_lm,ida,arat,epb, >>>>> >>>>> xsaveopt,pln,pts,dtherm,tpr_shadow,vnmi,flexpriority,ept,vpid,model_Nehalem,model_Conroe,model_coreduo,model_core2duo,model_P >>>>> >>>>> enryn,model_Westmere,model_n270,model_SandyBridge >>>>> cpuModel = Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz >>>>> cpuSockets = 1 >>>>> cpuSpeed = 3672.000 >>>>> cpuThreads = 8 >>>>> emulatedMachines = ['clipper', 'none'] >>>>> guestOverhead = 65 >>>>> hooks = {} >>>>> kvmEnabled = true >>>>> lastClient = 10.239.131.222 >>>>> lastClientIface = ovirtmgmt >>>>> management_ip = >>>>> memSize = 7944 >>>>> netConfigDirty = False >>>>> networks = {'ovirtmgmt': {'iface': 'ovirtmgmt', 'addr': >>>>> '10.239.131.217', 'cfg': {'PEERROUTES': 'yes', 'DEVICE': >>>>> 'ovirtmgmt', >>>>> 'IPV6INIT': 'yes', 'UUID': 'b6ecfa9d-0deb-4213-9348-11137f76735d', >>>>> 'IPV6_PEERDNS': 'yes', 'DEFROUTE': 'yes', 'PEERDNS': 'yes', >>>>> 'IPV4_FAILURE_FATAL': 'no', 'DELAY': '0', 'NM_CONTROLLED': 'no', >>>>> 'IPV6_DEFROUTE': 'yes', 'IPV6_AUTOCONF': 'yes', >>>>> 'IPV6_FAILURE_FATAL': >>>>> 'no', 'TYPE': 'Bridge', 'ONBOOT': 'yes', 'BOOTPROTO': 'dhcp', >>>>> 'IPV6_PEERROUTES': 'yes'}, 'mtu': '1500', 'netmask': '255.255.255.0', >>>>> 'stp': 'off', 'bridged': True, 'gateway': '10.239.131.1', 'ports': >>>>> ['em1']}} >>>>> nics = {'em1': {'addr': '', 'cfg': {}, 'mtu': '1500', >>>>> 'netmask': '', 'hwaddr': '2c:41:38:b2:d0:e8', 'speed': 100}} >>>>> operatingSystem = {'release': '0.5', 'version': '19', >>>>> 'name': 'Fedora'} >>>>> packages2 = {'kernel': {'release': '301.fc19.x86_64', >>>>> 'buildtime': 1368462984.0, 'version': '3.9.2'}, 'spice-server': >>>>> {'release': '5.fc19', 'buildtime': 1366036951, 'version': >>>>> '0.12.2'}, 'vdsm': {'release': '18.fc19', 'buildtime': 1373484771, >>>>> 'version': '4.10.3'}, 'qemu-kvm': {'release': '4.fc19', >>>>> 'buildtime': 1371653911, 'version': '1.4.2'}, 'libvirt': {'release': >>>>> '1.fc19', >>>>> 'buildtime': 1371074681, 'version': '1.0.5.2'}, 'qemu-img': >>>>> {'release': '4.fc19', 'buildtime': 1371653911, 'version': '1.4.2'}, >>>>> 'mom': >>>>> {'release': '2.fc19', 'buildtime': 1374564325, 'version': '0.3.2'}} >>>>> reservedMem = 321 >>>>> software_revision = 18 >>>>> software_version = 4.10 >>>>> supportedENGINEs = ['3.0', '3.1'] >>>>> supportedProtocols = ['2.2', '2.3'] >>>>> uuid = 30BBC800-4F47-11E0-0000-2C4138B2D0E8 >>>>> version_name = Snow Man >>>>> vlans = {} >>>>> vmTypes = ['kvm'] >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> Best Regards, >>>>> Dave Chen >>>>> >>>>> >>>>>> -----Original Message----- >>>>>> From: Laszlo Hornyak [mailto:lhornyak at redhat.com] >>>>>> Sent: Monday, August 05, 2013 8:35 PM >>>>>> To: Itamar Heim >>>>>> Cc: Chen, Wei D; Zhang, Lijuan;engine-devel at ovirt.org >>>>>> Subject: Re: [Engine-devel] failed to add host into cluster >>>>>> >>>>>> Hi, >>>>>> >>>>>> Dave, could you also share the vdsm log as well? >>>>>> >>>>>> I managed to reproduce this on the host that I am using for years >>>>>> and I am using it now, so it should not be a hardware problem. >>>>>> Probably >>>>>> some broken configuration caused some problem in vdsm before it >>>>>> would retrieve the capabilities information from libvirt. >>>>>> >>>>>> >>>>>> >>>>>> ----- Original Message ----- >>>>>>> From: "Itamar Heim" >>>>>>> To: "Laszlo Hornyak" >>>>>>> Cc: "Wei D Chen", "Lijuan Zhang" >>>>>>> ,engine-devel at ovirt.org >>>>>>> Sent: Monday, August 5, 2013 2:03:58 PM >>>>>>> Subject: Re: [Engine-devel] failed to add host into cluster >>>>>>> >>>>>>> On 08/05/2013 09:06 AM, Laszlo Hornyak wrote: >>>>>>>> ----- Original Message ----- >>>>>>>>> From: "Wei D Chen" >>>>>>>>> To: "Itamar Heim" >>>>>>>>> Cc: "Lijuan Zhang",engine-devel at ovirt.org >>>>>>>>> Sent: Monday, August 5, 2013 8:03:08 AM >>>>>>>>> Subject: Re: [Engine-devel] failed to add host into cluster >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Best Regards, >>>>>>>>> Dave Chen >>>>>>>>> >>>>>>>>> >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: Itamar Heim [mailto:iheim at redhat.com] >>>>>>>>>> Sent: Sunday, August 04, 2013 10:25 PM >>>>>>>>>> To: Chen, Wei D >>>>>>>>>> Cc:engine-devel at ovirt.org; Zhang, Lijuan >>>>>>>>>> Subject: Re: [Engine-devel] failed to add host into cluster >>>>>>>>>> >>>>>>>>>> On 08/02/2013 09:34 AM, Chen, Wei D wrote: >>>>>>>>>>> Failed to add a node into cluster. I saw follow hints, but still >>>>>>>>>>> don't know how to fix it. OS is fedora 19 both for node and >>>>>>>>>>> engine, anyone can help me? >>>>>>>>>>> >>>>>>>>>>> Host *** does not comply with the cluster *** emulated machines. >>>>>>>>>>> The Hosts emulated machines are clipper,none and the cluster is >>>>>>>>>>> [rhel6.4.0, pc-1.0]} >>>>>>>>>> what Os is the host running? >>>>>>>>> fedora 19 >>>>>>>>>> what does 'vdsClient -s 0 getVdsCaps' returns? >>>>>>>>> where to run this command? this command is not recognized both in >>>>>>>>> engine and node. >>>>>>>> After installing the host, you should have this command in the >>>>>>>> host OS. >>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> Engine-devel mailing list >>>>>>>>> Engine-devel at ovirt.org >>>>>>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel >>>>>>>>> >>>>>>> cat /proc/cpuinfo >>>>>>> and >>>>>>> virsh capabilities >>>>>>> >>>>>>> are also interesting >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Engine-devel mailing list >>>>>>> Engine-devel at ovirt.org >>>>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel >>> >>> >>> >>> _______________________________________________ >>> Engine-devel mailing list >>> Engine-devel at ovirt.org >>> http://lists.ovirt.org/mailman/listinfo/engine-devel >>> >> >> your qemu only reports "clipper" as the support emulated machine? > Yes, it is. Same to Chenwei's results. > Could the problem be solved without re-install the os? > > > what does this command returns: $ qemu-kvm -M ? From gouyang at redhat.com Thu Nov 21 11:13:41 2013 From: gouyang at redhat.com (ouyang guohua) Date: Thu, 21 Nov 2013 19:13:41 +0800 Subject: [Engine-devel] failed to add host into cluster In-Reply-To: <528DE858.6080502@redhat.com> References: <51FE642C.8040307@redhat.com> <1492863435.5066137.1375682766691.JavaMail.root@redhat.com> <51FF94AE.6030807@redhat.com> <307132015.5144883.1375706091754.JavaMail.root@redhat.com> <528DCD64.5010407@redhat.com> <528DE1F1.4090603@redhat.com> <528DE793.8060500@redhat.com> <528DE858.6080502@redhat.com> Message-ID: <528DEAE5.4030708@redhat.com> On 11/21/2013 07:02 PM, Itamar Heim wrote: > On 11/21/2013 12:59 PM, ouyang guohua wrote: >> On 11/21/2013 06:35 PM, Itamar Heim wrote: >>> On 11/21/2013 11:07 AM, ouyang guohua wrote: >>>> Hi, >>>> >>>> I encounter the same problem today. >>>> >>>> Both the engine and the node are fedora 19. >>>> >>>> 1. on engine host: >>>> engine=# select * from vdc_options where option_name ilike '%emu%'; >>>> option_id | option_name | option_value | version >>>> -----------+-------------------------+------------------+--------- >>>> 38 | ClusterEmulatedMachines | rhel6.2.0,pc-1.0 | 3.0 >>>> 39 | ClusterEmulatedMachines | rhel6.3.0,pc-1.0 | 3.1 >>>> 40 | ClusterEmulatedMachines | rhel6.4.0,pc-1.0 | 3.2 >>>> 41 | ClusterEmulatedMachines | rhel6.4.0,pc-1.0 | 3.3 >>>> (4 rows) >>>> >>>> engine=# select name,emulated_machine from vds_groups; >>>> name | emulated_machine >>>> ---------------------+------------------ >>>> Default | >>>> fedora19-cluster | pc-1.0 >>>> fedora19-node-Local | pc-1.0 >>>> (3 rows) >>>> >>>> 2. on node: >>>> # vdsClient -s 0 getVdsCaps >>>> HBAInventory = {'iSCSI': [{'InitiatorName': >>>> 'iqn.1994-05.com.redhat:643bb46781e'}], 'FC': []} >>>> ISCSIInitiatorName = iqn.1994-05.com.redhat:643bb46781e >>>> bondings = {'bond4': {'addr': '', 'cfg': {}, 'mtu': '1500', >>>> 'netmask': '', 'slaves': [], 'hwaddr': '7e:00:7f:e7:90:4c'}, 'bond0': >>>> {'addr': '', 'cfg': {}, 'mtu': '1500', 'netmask': '', 'slaves': [], >>>> 'hwaddr': 'de:c5:12:4e:17:6f'}, 'bond1': {'addr': '', 'cfg': {}, >>>> 'mtu': >>>> '1500', 'netmask': '', 'slaves': [], 'hwaddr': '2e:ec:3b:01:ab:de'}, >>>> 'bond2': {'addr': '', 'cfg': {}, 'mtu': '1500', 'netmask': '', >>>> 'slaves': >>>> [], 'hwaddr': 'da:88:61:cb:0d:ed'}, 'bond3': {'addr': '', 'cfg': {}, >>>> 'mtu': '1500', 'netmask': '', 'slaves': [], 'hwaddr': >>>> '72:c4:9e:9d:25:c1'}} >>>> bridges = {'ovirtmgmt': {'addr': '10.66.10.186', 'cfg': >>>> {'PEERROUTES': 'yes', 'IPV6INIT': 'yes', 'TYPE': 'Bridge', >>>> 'IPV6_PEERDNS': 'yes', 'DEFROUTE': 'yes', 'ONBOOT': 'yes', 'PEERDNS': >>>> 'yes', 'IPV4_FAILURE_FATAL': 'no', 'DELAY': '0', 'NM_CONTROLLED': >>>> 'no', >>>> 'BOOTPROTO': 'dhcp', 'DEVICE': 'ovirtmgmt', 'IPV6_FAILURE_FATAL': >>>> 'no', >>>> 'IPV6_PEERROUTES': 'yes', 'IPV6_DEFROUTE': 'yes', 'IPV6_AUTOCONF': >>>> 'yes', 'UUID': '447b16c1-184a-4347-a801-ef8143c2d932'}, 'mtu': '1500', >>>> 'netmask': '255.255.252.0', 'stp': 'off', 'ports': ['em1']}} >>>> clusterLevels = ['3.0', '3.1', '3.2'] >>>> cpuCores = 4 >>>> cpuFlags = >>>> fpu,vme,de,pse,tsc,msr,pae,mce,cx8,apic,sep,mtrr,pge,mca,cmov,pat,pse36,clflush,dts,acpi,mmx,fxsr,sse,sse2,ss,ht,tm,pbe,syscall,nx,lm,constant_tsc,arch_perfmon,pebs,bts,rep_good,nopl,aperfmperf,pni,dtes64,monitor,ds_cpl,vmx,smx,est,tm2,ssse3,cx16,xtpr,pdcm,sse4_1,xsave,lahf_lm,dtherm,tpr_shadow,vnmi,flexpriority,model_Conroe,model_coreduo,model_core2duo,model_Penryn,model_n270 >>>> >>>> >>>> cpuModel = Intel(R) Core(TM)2 Quad CPU Q9400 @ 2.66GHz >>>> cpuSockets = 1 >>>> cpuSpeed = 2660.126 >>>> cpuThreads = 4 >>>> emulatedMachines = ['clipper', 'none'] >>>> guestOverhead = 65 >>>> hooks = {} >>>> kvmEnabled = true >>>> lastClient = 10.66.105.101 >>>> lastClientIface = ovirtmgmt >>>> management_ip = >>>> memSize = 3888 >>>> netConfigDirty = False >>>> networks = {'ovirtmgmt': {'iface': 'ovirtmgmt', 'addr': >>>> '10.66.10.186', 'cfg': {'PEERROUTES': 'yes', 'IPV6INIT': 'yes', >>>> 'TYPE': >>>> 'Bridge', 'IPV6_PEERDNS': 'yes', 'DEFROUTE': 'yes', 'ONBOOT': 'yes', >>>> 'PEERDNS': 'yes', 'IPV4_FAILURE_FATAL': 'no', 'DELAY': '0', >>>> 'NM_CONTROLLED': 'no', 'BOOTPROTO': 'dhcp', 'DEVICE': 'ovirtmgmt', >>>> 'IPV6_FAILURE_FATAL': 'no', 'IPV6_PEERROUTES': 'yes', 'IPV6_DEFROUTE': >>>> 'yes', 'IPV6_AUTOCONF': 'yes', 'UUID': >>>> '447b16c1-184a-4347-a801-ef8143c2d932'}, 'mtu': '1500', 'netmask': >>>> '255.255.252.0', 'stp': 'off', 'bridged': True, 'gateway': >>>> '10.66.11.254', 'ports': ['em1']}} >>>> nics = {'em1': {'addr': '', 'cfg': {'PEERROUTES': 'yes', >>>> 'BRIDGE': >>>> 'ovirtmgmt', 'DEVICE': 'em1', 'IPV6INIT': 'yes', 'IPV6_PEERDNS': >>>> 'yes', >>>> 'DEFROUTE': 'yes', 'ONBOOT': 'yes', 'PEERDNS': 'yes', >>>> 'IPV4_FAILURE_FATAL': 'no', 'NM_CONTROLLED': 'no', 'IPV6_DEFROUTE': >>>> 'yes', 'IPV6_AUTOCONF': 'yes', 'IPV6_FAILURE_FATAL': 'no', >>>> 'IPV6_PEERROUTES': 'yes', 'HWADDR': '00:23:ae:9d:85:32', 'UUID': >>>> '447b16c1-184a-4347-a801-ef8143c2d932'}, 'mtu': '1500', 'netmask': '', >>>> 'hwaddr': '00:23:ae:9d:85:32', 'speed': 1000}} >>>> operatingSystem = {'release': '4', 'version': '19', 'name': >>>> 'Fedora'} >>>> packages2 = {'kernel': {'release': '200.fc19.x86_64', >>>> 'buildtime': >>>> 1383545343.0, 'version': '3.11.7'}, 'spice-server': {'release': >>>> '3.fc19', 'buildtime': 1383130020, 'version': '0.12.4'}, 'vdsm': >>>> {'release': '18.fc19', 'buildtime': 1373484771, 'version': '4.10.3'}, >>>> 'qemu-kvm': {'release': '13.fc19', 'buildtime': 1383700301, 'version': >>>> '1.4.2'}, 'libvirt': {'release': '1.fc19', 'buildtime': 1383765188, >>>> 'version': '1.0.5.7'}, 'qemu-img': {'release': '13.fc19', 'buildtime': >>>> 1383700301, 'version': '1.4.2'}, 'mom': {'release': '1.fc19', >>>> 'buildtime': 1373298035, 'version': '0.3.1'}} >>>> reservedMem = 321 >>>> software_revision = 18 >>>> software_version = 4.10 >>>> supportedENGINEs = ['3.0', '3.1'] >>>> supportedProtocols = ['2.2', '2.3'] >>>> uuid = 44454C4C-4C00-1031-8053-CAC04F4E3258 >>>> version_name = Snow Man >>>> vlans = {} >>>> vmTypes = ['kvm'] >>>> >>>> 3. the vdsm.log is cutting to small size, if some useful logs isn't in >>>> it, please ask me to re-send it. >>>> >>>> Thanks, >>>> guohua >>>> >>>> On 08/06/2013 03:08 PM, Chen, Wei D wrote: >>>>> The issue is solved by reinstalling host OS. >>>>> >>>>> Best Regards, >>>>> Dave Chen >>>>> >>>>> >>>>>> -----Original Message----- >>>>>> From: Chen, Wei D >>>>>> Sent: Tuesday, August 06, 2013 2:44 PM >>>>>> To: 'Laszlo Hornyak'; Itamar Heim >>>>>> Cc: Zhang, Lijuan;engine-devel at ovirt.org >>>>>> Subject: RE: [Engine-devel] failed to add host into cluster >>>>>> >>>>>> Hi, >>>>>> >>>>>> >>>>>> [root at onode vdsm]# vdsClient -s 0 getVdsCaps >>>>>> HBAInventory = {'iSCSI': [{'InitiatorName': >>>>>> 'iqn.1994-05.com.redhat:9fb571e343'}], 'FC': []} >>>>>> ISCSIInitiatorName = iqn.1994-05.com.redhat:9fb571e343 >>>>>> bondings = {'bond4': {'addr': '', 'cfg': {}, 'mtu': >>>>>> '1500', 'netmask': '', 'slaves': [], 'hwaddr': '0e:00:b7:57:2c:c9'}, >>>>>> 'bond0': {'addr': '', 'cfg': {}, 'mtu': '1500', 'netmask': '', >>>>>> 'slaves': [], 'hwaddr': '32:b3:88:1f:ef:91'}, 'bond1': {'addr': '', >>>>>> 'cfg': {}, 'mtu': '1500', 'netmask': '', 'slaves': [], 'hwaddr': >>>>>> '4e:e5:80:93:ea:d9'}, 'bond2': {'addr': '', 'cfg': {}, 'mtu': >>>>>> '1500', >>>>>> 'netmask': '', 'slaves': [], 'hwaddr': '16:ab:f6:e4:f2:27'}, >>>>>> 'bond3': {'addr': '', 'cfg': {}, 'mtu': '1500', 'netmask': '', >>>>>> 'slaves': >>>>>> [], 'hwaddr': 'ee:55:f5:e7:31:7c'}} >>>>>> bridges = {'ovirtmgmt': {'addr': '10.239.131.217', 'cfg': >>>>>> {'PEERROUTES': 'yes', 'DEVICE': 'ovirtmgmt', 'IPV6INIT': 'yes', >>>>>> 'UUID': 'b6ecfa9d-0deb-4213-9348-11137f76735d', 'IPV6_PEERDNS': >>>>>> 'yes', 'DEFROUTE': 'yes', 'PEERDNS': 'yes', 'IPV4_FAILURE_FATAL': >>>>>> 'no', 'DELAY': '0', 'NM_CONTROLLED': 'no', 'IPV6_DEFROUTE': 'yes', >>>>>> 'IPV6_AUTOCONF': 'yes', 'IPV6_FAILURE_FATAL': 'no', 'TYPE': >>>>>> 'Bridge', 'ONBOOT': 'yes', 'BOOTPROTO': 'dhcp', 'IPV6_PEERROUTES': >>>>>> 'yes'}, 'mtu': '1500', 'netmask': '255.255.255.0', 'stp': 'off', >>>>>> 'ports': ['em1']}} >>>>>> clusterLevels = ['3.0', '3.1', '3.2'] >>>>>> cpuCores = 4 >>>>>> cpuFlags = >>>>>> fpu,vme,de,pse,tsc,msr,pae,mce,cx8,apic,sep,mtrr,pge,mca,cmov,pat,pse36,clflush,dts,acpi,mmx,fxsr,sse,sse2,ss,ht,tm,pbe,syscall,nx,r >>>>>> >>>>>> >>>>>> dtscp,lm,constant_tsc,arch_perfmon,pebs,bts,rep_good,nopl,xtopology,nonstop_tsc,aperfmperf,eagerfpu,pni,pclmulqdq,dtes64,monitor, >>>>>> >>>>>> >>>>>> ds_cpl,vmx,smx,est,tm2,ssse3,cx16,xtpr,pdcm,pcid,sse4_1,sse4_2,x2apic,popcnt,tsc_deadline_timer,aes,xsave,avx,lahf_lm,ida,arat,epb, >>>>>> >>>>>> >>>>>> xsaveopt,pln,pts,dtherm,tpr_shadow,vnmi,flexpriority,ept,vpid,model_Nehalem,model_Conroe,model_coreduo,model_core2duo,model_P >>>>>> >>>>>> >>>>>> enryn,model_Westmere,model_n270,model_SandyBridge >>>>>> cpuModel = Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz >>>>>> cpuSockets = 1 >>>>>> cpuSpeed = 3672.000 >>>>>> cpuThreads = 8 >>>>>> emulatedMachines = ['clipper', 'none'] >>>>>> guestOverhead = 65 >>>>>> hooks = {} >>>>>> kvmEnabled = true >>>>>> lastClient = 10.239.131.222 >>>>>> lastClientIface = ovirtmgmt >>>>>> management_ip = >>>>>> memSize = 7944 >>>>>> netConfigDirty = False >>>>>> networks = {'ovirtmgmt': {'iface': 'ovirtmgmt', 'addr': >>>>>> '10.239.131.217', 'cfg': {'PEERROUTES': 'yes', 'DEVICE': >>>>>> 'ovirtmgmt', >>>>>> 'IPV6INIT': 'yes', 'UUID': 'b6ecfa9d-0deb-4213-9348-11137f76735d', >>>>>> 'IPV6_PEERDNS': 'yes', 'DEFROUTE': 'yes', 'PEERDNS': 'yes', >>>>>> 'IPV4_FAILURE_FATAL': 'no', 'DELAY': '0', 'NM_CONTROLLED': 'no', >>>>>> 'IPV6_DEFROUTE': 'yes', 'IPV6_AUTOCONF': 'yes', >>>>>> 'IPV6_FAILURE_FATAL': >>>>>> 'no', 'TYPE': 'Bridge', 'ONBOOT': 'yes', 'BOOTPROTO': 'dhcp', >>>>>> 'IPV6_PEERROUTES': 'yes'}, 'mtu': '1500', 'netmask': >>>>>> '255.255.255.0', >>>>>> 'stp': 'off', 'bridged': True, 'gateway': '10.239.131.1', 'ports': >>>>>> ['em1']}} >>>>>> nics = {'em1': {'addr': '', 'cfg': {}, 'mtu': '1500', >>>>>> 'netmask': '', 'hwaddr': '2c:41:38:b2:d0:e8', 'speed': 100}} >>>>>> operatingSystem = {'release': '0.5', 'version': '19', >>>>>> 'name': 'Fedora'} >>>>>> packages2 = {'kernel': {'release': '301.fc19.x86_64', >>>>>> 'buildtime': 1368462984.0, 'version': '3.9.2'}, 'spice-server': >>>>>> {'release': '5.fc19', 'buildtime': 1366036951, 'version': >>>>>> '0.12.2'}, 'vdsm': {'release': '18.fc19', 'buildtime': 1373484771, >>>>>> 'version': '4.10.3'}, 'qemu-kvm': {'release': '4.fc19', >>>>>> 'buildtime': 1371653911, 'version': '1.4.2'}, 'libvirt': {'release': >>>>>> '1.fc19', >>>>>> 'buildtime': 1371074681, 'version': '1.0.5.2'}, 'qemu-img': >>>>>> {'release': '4.fc19', 'buildtime': 1371653911, 'version': '1.4.2'}, >>>>>> 'mom': >>>>>> {'release': '2.fc19', 'buildtime': 1374564325, 'version': '0.3.2'}} >>>>>> reservedMem = 321 >>>>>> software_revision = 18 >>>>>> software_version = 4.10 >>>>>> supportedENGINEs = ['3.0', '3.1'] >>>>>> supportedProtocols = ['2.2', '2.3'] >>>>>> uuid = 30BBC800-4F47-11E0-0000-2C4138B2D0E8 >>>>>> version_name = Snow Man >>>>>> vlans = {} >>>>>> vmTypes = ['kvm'] >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Best Regards, >>>>>> Dave Chen >>>>>> >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Laszlo Hornyak [mailto:lhornyak at redhat.com] >>>>>>> Sent: Monday, August 05, 2013 8:35 PM >>>>>>> To: Itamar Heim >>>>>>> Cc: Chen, Wei D; Zhang, Lijuan;engine-devel at ovirt.org >>>>>>> Subject: Re: [Engine-devel] failed to add host into cluster >>>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> Dave, could you also share the vdsm log as well? >>>>>>> >>>>>>> I managed to reproduce this on the host that I am using for years >>>>>>> and I am using it now, so it should not be a hardware problem. >>>>>>> Probably >>>>>>> some broken configuration caused some problem in vdsm before it >>>>>>> would retrieve the capabilities information from libvirt. >>>>>>> >>>>>>> >>>>>>> >>>>>>> ----- Original Message ----- >>>>>>>> From: "Itamar Heim" >>>>>>>> To: "Laszlo Hornyak" >>>>>>>> Cc: "Wei D Chen", "Lijuan Zhang" >>>>>>>> ,engine-devel at ovirt.org >>>>>>>> Sent: Monday, August 5, 2013 2:03:58 PM >>>>>>>> Subject: Re: [Engine-devel] failed to add host into cluster >>>>>>>> >>>>>>>> On 08/05/2013 09:06 AM, Laszlo Hornyak wrote: >>>>>>>>> ----- Original Message ----- >>>>>>>>>> From: "Wei D Chen" >>>>>>>>>> To: "Itamar Heim" >>>>>>>>>> Cc: "Lijuan >>>>>>>>>> Zhang",engine-devel at ovirt.org >>>>>>>>>> Sent: Monday, August 5, 2013 8:03:08 AM >>>>>>>>>> Subject: Re: [Engine-devel] failed to add host into cluster >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Best Regards, >>>>>>>>>> Dave Chen >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> -----Original Message----- >>>>>>>>>>> From: Itamar Heim [mailto:iheim at redhat.com] >>>>>>>>>>> Sent: Sunday, August 04, 2013 10:25 PM >>>>>>>>>>> To: Chen, Wei D >>>>>>>>>>> Cc:engine-devel at ovirt.org; Zhang, Lijuan >>>>>>>>>>> Subject: Re: [Engine-devel] failed to add host into cluster >>>>>>>>>>> >>>>>>>>>>> On 08/02/2013 09:34 AM, Chen, Wei D wrote: >>>>>>>>>>>> Failed to add a node into cluster. I saw follow hints, but >>>>>>>>>>>> still >>>>>>>>>>>> don't know how to fix it. OS is fedora 19 both for node and >>>>>>>>>>>> engine, anyone can help me? >>>>>>>>>>>> >>>>>>>>>>>> Host *** does not comply with the cluster *** emulated >>>>>>>>>>>> machines. >>>>>>>>>>>> The Hosts emulated machines are clipper,none and the >>>>>>>>>>>> cluster is >>>>>>>>>>>> [rhel6.4.0, pc-1.0]} >>>>>>>>>>> what Os is the host running? >>>>>>>>>> fedora 19 >>>>>>>>>>> what does 'vdsClient -s 0 getVdsCaps' returns? >>>>>>>>>> where to run this command? this command is not recognized >>>>>>>>>> both in >>>>>>>>>> engine and node. >>>>>>>>> After installing the host, you should have this command in the >>>>>>>>> host OS. >>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> Engine-devel mailing list >>>>>>>>>> Engine-devel at ovirt.org >>>>>>>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel >>>>>>>>>> >>>>>>>> cat /proc/cpuinfo >>>>>>>> and >>>>>>>> virsh capabilities >>>>>>>> >>>>>>>> are also interesting >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Engine-devel mailing list >>>>>>>> Engine-devel at ovirt.org >>>>>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel >>>> >>>> >>>> >>>> _______________________________________________ >>>> Engine-devel mailing list >>>> Engine-devel at ovirt.org >>>> http://lists.ovirt.org/mailman/listinfo/engine-devel >>>> >>> >>> your qemu only reports "clipper" as the support emulated machine? >> Yes, it is. Same to Chenwei's results. >> Could the problem be solved without re-install the os? >> >> >> > > what does this command returns: > $ qemu-kvm -M ? > # qemu-kvm -M ? Supported machines are: none empty machine pc Standard PC (i440FX + PIIX, 1996) (alias of pc-i440fx-1.4) pc-i440fx-1.4 Standard PC (i440FX + PIIX, 1996) (default) pc-1.3 Standard PC pc-1.2 Standard PC pc-1.1 Standard PC pc-1.0 Standard PC pc-0.15 Standard PC pc-0.14 Standard PC pc-0.13 Standard PC pc-0.12 Standard PC pc-0.11 Standard PC, qemu 0.11 pc-0.10 Standard PC, qemu 0.10 isapc ISA-only PC q35 Standard PC (Q35 + ICH9, 2009) (alias of pc-q35-1.4) pc-q35-1.4 Standard PC (Q35 + ICH9, 2009) From michal.skrivanek at redhat.com Thu Nov 21 11:23:22 2013 From: michal.skrivanek at redhat.com (Michal Skrivanek) Date: Thu, 21 Nov 2013 12:23:22 +0100 Subject: [Engine-devel] failed to add host into cluster In-Reply-To: <528DEAE5.4030708@redhat.com> References: <51FE642C.8040307@redhat.com> <1492863435.5066137.1375682766691.JavaMail.root@redhat.com> <51FF94AE.6030807@redhat.com> <307132015.5144883.1375706091754.JavaMail.root@redhat.com> <528DCD64.5010407@redhat.com> <528DE1F1.4090603@redhat.com> <528DE793.8060500@redhat.com> <528DE858.6080502@redhat.com> <528DEAE5.4030708@redhat.com> Message-ID: On Nov 21, 2013, at 12:13 , ouyang guohua wrote: > On 11/21/2013 07:02 PM, Itamar Heim wrote: >> On 11/21/2013 12:59 PM, ouyang guohua wrote: >>> On 11/21/2013 06:35 PM, Itamar Heim wrote: >>>> On 11/21/2013 11:07 AM, ouyang guohua wrote: >>>>> Hi, >>>>> >>>>> I encounter the same problem today. >>>>> >>>>> Both the engine and the node are fedora 19. >>>>> >>>>> 1. on engine host: >>>>> engine=# select * from vdc_options where option_name ilike '%emu%'; >>>>> option_id | option_name | option_value | version >>>>> -----------+-------------------------+------------------+--------- >>>>> 38 | ClusterEmulatedMachines | rhel6.2.0,pc-1.0 | 3.0 >>>>> 39 | ClusterEmulatedMachines | rhel6.3.0,pc-1.0 | 3.1 >>>>> 40 | ClusterEmulatedMachines | rhel6.4.0,pc-1.0 | 3.2 >>>>> 41 | ClusterEmulatedMachines | rhel6.4.0,pc-1.0 | 3.3 >>>>> (4 rows) >>>>> >>>>> engine=# select name,emulated_machine from vds_groups; >>>>> name | emulated_machine >>>>> ---------------------+------------------ >>>>> Default | >>>>> fedora19-cluster | pc-1.0 >>>>> fedora19-node-Local | pc-1.0 >>>>> (3 rows) >>>>> >>>>> 2. on node: >>>>> # vdsClient -s 0 getVdsCaps >>>>> HBAInventory = {'iSCSI': [{'InitiatorName': >>>>> 'iqn.1994-05.com.redhat:643bb46781e'}], 'FC': []} >>>>> ISCSIInitiatorName = iqn.1994-05.com.redhat:643bb46781e >>>>> bondings = {'bond4': {'addr': '', 'cfg': {}, 'mtu': '1500', >>>>> 'netmask': '', 'slaves': [], 'hwaddr': '7e:00:7f:e7:90:4c'}, 'bond0': >>>>> {'addr': '', 'cfg': {}, 'mtu': '1500', 'netmask': '', 'slaves': [], >>>>> 'hwaddr': 'de:c5:12:4e:17:6f'}, 'bond1': {'addr': '', 'cfg': {}, >>>>> 'mtu': >>>>> '1500', 'netmask': '', 'slaves': [], 'hwaddr': '2e:ec:3b:01:ab:de'}, >>>>> 'bond2': {'addr': '', 'cfg': {}, 'mtu': '1500', 'netmask': '', >>>>> 'slaves': >>>>> [], 'hwaddr': 'da:88:61:cb:0d:ed'}, 'bond3': {'addr': '', 'cfg': {}, >>>>> 'mtu': '1500', 'netmask': '', 'slaves': [], 'hwaddr': >>>>> '72:c4:9e:9d:25:c1'}} >>>>> bridges = {'ovirtmgmt': {'addr': '10.66.10.186', 'cfg': >>>>> {'PEERROUTES': 'yes', 'IPV6INIT': 'yes', 'TYPE': 'Bridge', >>>>> 'IPV6_PEERDNS': 'yes', 'DEFROUTE': 'yes', 'ONBOOT': 'yes', 'PEERDNS': >>>>> 'yes', 'IPV4_FAILURE_FATAL': 'no', 'DELAY': '0', 'NM_CONTROLLED': >>>>> 'no', >>>>> 'BOOTPROTO': 'dhcp', 'DEVICE': 'ovirtmgmt', 'IPV6_FAILURE_FATAL': >>>>> 'no', >>>>> 'IPV6_PEERROUTES': 'yes', 'IPV6_DEFROUTE': 'yes', 'IPV6_AUTOCONF': >>>>> 'yes', 'UUID': '447b16c1-184a-4347-a801-ef8143c2d932'}, 'mtu': '1500', >>>>> 'netmask': '255.255.252.0', 'stp': 'off', 'ports': ['em1']}} >>>>> clusterLevels = ['3.0', '3.1', '3.2'] >>>>> cpuCores = 4 >>>>> cpuFlags = >>>>> fpu,vme,de,pse,tsc,msr,pae,mce,cx8,apic,sep,mtrr,pge,mca,cmov,pat,pse36,clflush,dts,acpi,mmx,fxsr,sse,sse2,ss,ht,tm,pbe,syscall,nx,lm,constant_tsc,arch_perfmon,pebs,bts,rep_good,nopl,aperfmperf,pni,dtes64,monitor,ds_cpl,vmx,smx,est,tm2,ssse3,cx16,xtpr,pdcm,sse4_1,xsave,lahf_lm,dtherm,tpr_shadow,vnmi,flexpriority,model_Conroe,model_coreduo,model_core2duo,model_Penryn,model_n270 >>>>> >>>>> >>>>> cpuModel = Intel(R) Core(TM)2 Quad CPU Q9400 @ 2.66GHz >>>>> cpuSockets = 1 >>>>> cpuSpeed = 2660.126 >>>>> cpuThreads = 4 >>>>> emulatedMachines = ['clipper', 'none'] >>>>> guestOverhead = 65 >>>>> hooks = {} >>>>> kvmEnabled = true >>>>> lastClient = 10.66.105.101 >>>>> lastClientIface = ovirtmgmt >>>>> management_ip = >>>>> memSize = 3888 >>>>> netConfigDirty = False >>>>> networks = {'ovirtmgmt': {'iface': 'ovirtmgmt', 'addr': >>>>> '10.66.10.186', 'cfg': {'PEERROUTES': 'yes', 'IPV6INIT': 'yes', >>>>> 'TYPE': >>>>> 'Bridge', 'IPV6_PEERDNS': 'yes', 'DEFROUTE': 'yes', 'ONBOOT': 'yes', >>>>> 'PEERDNS': 'yes', 'IPV4_FAILURE_FATAL': 'no', 'DELAY': '0', >>>>> 'NM_CONTROLLED': 'no', 'BOOTPROTO': 'dhcp', 'DEVICE': 'ovirtmgmt', >>>>> 'IPV6_FAILURE_FATAL': 'no', 'IPV6_PEERROUTES': 'yes', 'IPV6_DEFROUTE': >>>>> 'yes', 'IPV6_AUTOCONF': 'yes', 'UUID': >>>>> '447b16c1-184a-4347-a801-ef8143c2d932'}, 'mtu': '1500', 'netmask': >>>>> '255.255.252.0', 'stp': 'off', 'bridged': True, 'gateway': >>>>> '10.66.11.254', 'ports': ['em1']}} >>>>> nics = {'em1': {'addr': '', 'cfg': {'PEERROUTES': 'yes', >>>>> 'BRIDGE': >>>>> 'ovirtmgmt', 'DEVICE': 'em1', 'IPV6INIT': 'yes', 'IPV6_PEERDNS': >>>>> 'yes', >>>>> 'DEFROUTE': 'yes', 'ONBOOT': 'yes', 'PEERDNS': 'yes', >>>>> 'IPV4_FAILURE_FATAL': 'no', 'NM_CONTROLLED': 'no', 'IPV6_DEFROUTE': >>>>> 'yes', 'IPV6_AUTOCONF': 'yes', 'IPV6_FAILURE_FATAL': 'no', >>>>> 'IPV6_PEERROUTES': 'yes', 'HWADDR': '00:23:ae:9d:85:32', 'UUID': >>>>> '447b16c1-184a-4347-a801-ef8143c2d932'}, 'mtu': '1500', 'netmask': '', >>>>> 'hwaddr': '00:23:ae:9d:85:32', 'speed': 1000}} >>>>> operatingSystem = {'release': '4', 'version': '19', 'name': >>>>> 'Fedora'} >>>>> packages2 = {'kernel': {'release': '200.fc19.x86_64', >>>>> 'buildtime': >>>>> 1383545343.0, 'version': '3.11.7'}, 'spice-server': {'release': >>>>> '3.fc19', 'buildtime': 1383130020, 'version': '0.12.4'}, 'vdsm': >>>>> {'release': '18.fc19', 'buildtime': 1373484771, 'version': '4.10.3'}, >>>>> 'qemu-kvm': {'release': '13.fc19', 'buildtime': 1383700301, 'version': >>>>> '1.4.2'}, 'libvirt': {'release': '1.fc19', 'buildtime': 1383765188, >>>>> 'version': '1.0.5.7'}, 'qemu-img': {'release': '13.fc19', 'buildtime': >>>>> 1383700301, 'version': '1.4.2'}, 'mom': {'release': '1.fc19', >>>>> 'buildtime': 1373298035, 'version': '0.3.1'}} >>>>> reservedMem = 321 >>>>> software_revision = 18 >>>>> software_version = 4.10 >>>>> supportedENGINEs = ['3.0', '3.1'] >>>>> supportedProtocols = ['2.2', '2.3'] >>>>> uuid = 44454C4C-4C00-1031-8053-CAC04F4E3258 >>>>> version_name = Snow Man >>>>> vlans = {} >>>>> vmTypes = ['kvm'] >>>>> >>>>> 3. the vdsm.log is cutting to small size, if some useful logs isn't in >>>>> it, please ask me to re-send it. >>>>> >>>>> Thanks, >>>>> guohua >>>>> >>>>> On 08/06/2013 03:08 PM, Chen, Wei D wrote: >>>>>> The issue is solved by reinstalling host OS. >>>>>> >>>>>> Best Regards, >>>>>> Dave Chen >>>>>> >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Chen, Wei D >>>>>>> Sent: Tuesday, August 06, 2013 2:44 PM >>>>>>> To: 'Laszlo Hornyak'; Itamar Heim >>>>>>> Cc: Zhang, Lijuan;engine-devel at ovirt.org >>>>>>> Subject: RE: [Engine-devel] failed to add host into cluster >>>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> >>>>>>> [root at onode vdsm]# vdsClient -s 0 getVdsCaps >>>>>>> HBAInventory = {'iSCSI': [{'InitiatorName': >>>>>>> 'iqn.1994-05.com.redhat:9fb571e343'}], 'FC': []} >>>>>>> ISCSIInitiatorName = iqn.1994-05.com.redhat:9fb571e343 >>>>>>> bondings = {'bond4': {'addr': '', 'cfg': {}, 'mtu': >>>>>>> '1500', 'netmask': '', 'slaves': [], 'hwaddr': '0e:00:b7:57:2c:c9'}, >>>>>>> 'bond0': {'addr': '', 'cfg': {}, 'mtu': '1500', 'netmask': '', >>>>>>> 'slaves': [], 'hwaddr': '32:b3:88:1f:ef:91'}, 'bond1': {'addr': '', >>>>>>> 'cfg': {}, 'mtu': '1500', 'netmask': '', 'slaves': [], 'hwaddr': >>>>>>> '4e:e5:80:93:ea:d9'}, 'bond2': {'addr': '', 'cfg': {}, 'mtu': >>>>>>> '1500', >>>>>>> 'netmask': '', 'slaves': [], 'hwaddr': '16:ab:f6:e4:f2:27'}, >>>>>>> 'bond3': {'addr': '', 'cfg': {}, 'mtu': '1500', 'netmask': '', >>>>>>> 'slaves': >>>>>>> [], 'hwaddr': 'ee:55:f5:e7:31:7c'}} >>>>>>> bridges = {'ovirtmgmt': {'addr': '10.239.131.217', 'cfg': >>>>>>> {'PEERROUTES': 'yes', 'DEVICE': 'ovirtmgmt', 'IPV6INIT': 'yes', >>>>>>> 'UUID': 'b6ecfa9d-0deb-4213-9348-11137f76735d', 'IPV6_PEERDNS': >>>>>>> 'yes', 'DEFROUTE': 'yes', 'PEERDNS': 'yes', 'IPV4_FAILURE_FATAL': >>>>>>> 'no', 'DELAY': '0', 'NM_CONTROLLED': 'no', 'IPV6_DEFROUTE': 'yes', >>>>>>> 'IPV6_AUTOCONF': 'yes', 'IPV6_FAILURE_FATAL': 'no', 'TYPE': >>>>>>> 'Bridge', 'ONBOOT': 'yes', 'BOOTPROTO': 'dhcp', 'IPV6_PEERROUTES': >>>>>>> 'yes'}, 'mtu': '1500', 'netmask': '255.255.255.0', 'stp': 'off', >>>>>>> 'ports': ['em1']}} >>>>>>> clusterLevels = ['3.0', '3.1', '3.2'] >>>>>>> cpuCores = 4 >>>>>>> cpuFlags = >>>>>>> fpu,vme,de,pse,tsc,msr,pae,mce,cx8,apic,sep,mtrr,pge,mca,cmov,pat,pse36,clflush,dts,acpi,mmx,fxsr,sse,sse2,ss,ht,tm,pbe,syscall,nx,r >>>>>>> >>>>>>> >>>>>>> dtscp,lm,constant_tsc,arch_perfmon,pebs,bts,rep_good,nopl,xtopology,nonstop_tsc,aperfmperf,eagerfpu,pni,pclmulqdq,dtes64,monitor, >>>>>>> >>>>>>> >>>>>>> ds_cpl,vmx,smx,est,tm2,ssse3,cx16,xtpr,pdcm,pcid,sse4_1,sse4_2,x2apic,popcnt,tsc_deadline_timer,aes,xsave,avx,lahf_lm,ida,arat,epb, >>>>>>> >>>>>>> >>>>>>> xsaveopt,pln,pts,dtherm,tpr_shadow,vnmi,flexpriority,ept,vpid,model_Nehalem,model_Conroe,model_coreduo,model_core2duo,model_P >>>>>>> >>>>>>> >>>>>>> enryn,model_Westmere,model_n270,model_SandyBridge >>>>>>> cpuModel = Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz >>>>>>> cpuSockets = 1 >>>>>>> cpuSpeed = 3672.000 >>>>>>> cpuThreads = 8 >>>>>>> emulatedMachines = ['clipper', 'none'] >>>>>>> guestOverhead = 65 >>>>>>> hooks = {} >>>>>>> kvmEnabled = true >>>>>>> lastClient = 10.239.131.222 >>>>>>> lastClientIface = ovirtmgmt >>>>>>> management_ip = >>>>>>> memSize = 7944 >>>>>>> netConfigDirty = False >>>>>>> networks = {'ovirtmgmt': {'iface': 'ovirtmgmt', 'addr': >>>>>>> '10.239.131.217', 'cfg': {'PEERROUTES': 'yes', 'DEVICE': >>>>>>> 'ovirtmgmt', >>>>>>> 'IPV6INIT': 'yes', 'UUID': 'b6ecfa9d-0deb-4213-9348-11137f76735d', >>>>>>> 'IPV6_PEERDNS': 'yes', 'DEFROUTE': 'yes', 'PEERDNS': 'yes', >>>>>>> 'IPV4_FAILURE_FATAL': 'no', 'DELAY': '0', 'NM_CONTROLLED': 'no', >>>>>>> 'IPV6_DEFROUTE': 'yes', 'IPV6_AUTOCONF': 'yes', >>>>>>> 'IPV6_FAILURE_FATAL': >>>>>>> 'no', 'TYPE': 'Bridge', 'ONBOOT': 'yes', 'BOOTPROTO': 'dhcp', >>>>>>> 'IPV6_PEERROUTES': 'yes'}, 'mtu': '1500', 'netmask': >>>>>>> '255.255.255.0', >>>>>>> 'stp': 'off', 'bridged': True, 'gateway': '10.239.131.1', 'ports': >>>>>>> ['em1']}} >>>>>>> nics = {'em1': {'addr': '', 'cfg': {}, 'mtu': '1500', >>>>>>> 'netmask': '', 'hwaddr': '2c:41:38:b2:d0:e8', 'speed': 100}} >>>>>>> operatingSystem = {'release': '0.5', 'version': '19', >>>>>>> 'name': 'Fedora'} >>>>>>> packages2 = {'kernel': {'release': '301.fc19.x86_64', >>>>>>> 'buildtime': 1368462984.0, 'version': '3.9.2'}, 'spice-server': >>>>>>> {'release': '5.fc19', 'buildtime': 1366036951, 'version': >>>>>>> '0.12.2'}, 'vdsm': {'release': '18.fc19', 'buildtime': 1373484771, >>>>>>> 'version': '4.10.3'}, 'qemu-kvm': {'release': '4.fc19', >>>>>>> 'buildtime': 1371653911, 'version': '1.4.2'}, 'libvirt': {'release': >>>>>>> '1.fc19', >>>>>>> 'buildtime': 1371074681, 'version': '1.0.5.2'}, 'qemu-img': >>>>>>> {'release': '4.fc19', 'buildtime': 1371653911, 'version': '1.4.2'}, >>>>>>> 'mom': >>>>>>> {'release': '2.fc19', 'buildtime': 1374564325, 'version': '0.3.2'}} >>>>>>> reservedMem = 321 >>>>>>> software_revision = 18 >>>>>>> software_version = 4.10 >>>>>>> supportedENGINEs = ['3.0', '3.1'] >>>>>>> supportedProtocols = ['2.2', '2.3'] >>>>>>> uuid = 30BBC800-4F47-11E0-0000-2C4138B2D0E8 >>>>>>> version_name = Snow Man >>>>>>> vlans = {} >>>>>>> vmTypes = ['kvm'] >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> Best Regards, >>>>>>> Dave Chen >>>>>>> >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Laszlo Hornyak [mailto:lhornyak at redhat.com] >>>>>>>> Sent: Monday, August 05, 2013 8:35 PM >>>>>>>> To: Itamar Heim >>>>>>>> Cc: Chen, Wei D; Zhang, Lijuan;engine-devel at ovirt.org >>>>>>>> Subject: Re: [Engine-devel] failed to add host into cluster >>>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>> Dave, could you also share the vdsm log as well? >>>>>>>> >>>>>>>> I managed to reproduce this on the host that I am using for years >>>>>>>> and I am using it now, so it should not be a hardware problem. >>>>>>>> Probably >>>>>>>> some broken configuration caused some problem in vdsm before it >>>>>>>> would retrieve the capabilities information from libvirt. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> ----- Original Message ----- >>>>>>>>> From: "Itamar Heim" >>>>>>>>> To: "Laszlo Hornyak" >>>>>>>>> Cc: "Wei D Chen", "Lijuan Zhang" >>>>>>>>> ,engine-devel at ovirt.org >>>>>>>>> Sent: Monday, August 5, 2013 2:03:58 PM >>>>>>>>> Subject: Re: [Engine-devel] failed to add host into cluster >>>>>>>>> >>>>>>>>> On 08/05/2013 09:06 AM, Laszlo Hornyak wrote: >>>>>>>>>> ----- Original Message ----- >>>>>>>>>>> From: "Wei D Chen" >>>>>>>>>>> To: "Itamar Heim" >>>>>>>>>>> Cc: "Lijuan >>>>>>>>>>> Zhang",engine-devel at ovirt.org >>>>>>>>>>> Sent: Monday, August 5, 2013 8:03:08 AM >>>>>>>>>>> Subject: Re: [Engine-devel] failed to add host into cluster >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Best Regards, >>>>>>>>>>> Dave Chen >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>> From: Itamar Heim [mailto:iheim at redhat.com] >>>>>>>>>>>> Sent: Sunday, August 04, 2013 10:25 PM >>>>>>>>>>>> To: Chen, Wei D >>>>>>>>>>>> Cc:engine-devel at ovirt.org; Zhang, Lijuan >>>>>>>>>>>> Subject: Re: [Engine-devel] failed to add host into cluster >>>>>>>>>>>> >>>>>>>>>>>> On 08/02/2013 09:34 AM, Chen, Wei D wrote: >>>>>>>>>>>>> Failed to add a node into cluster. I saw follow hints, but >>>>>>>>>>>>> still >>>>>>>>>>>>> don't know how to fix it. OS is fedora 19 both for node and >>>>>>>>>>>>> engine, anyone can help me? >>>>>>>>>>>>> >>>>>>>>>>>>> Host *** does not comply with the cluster *** emulated >>>>>>>>>>>>> machines. >>>>>>>>>>>>> The Hosts emulated machines are clipper,none and the >>>>>>>>>>>>> cluster is >>>>>>>>>>>>> [rhel6.4.0, pc-1.0]} >>>>>>>>>>>> what Os is the host running? >>>>>>>>>>> fedora 19 >>>>>>>>>>>> what does 'vdsClient -s 0 getVdsCaps' returns? >>>>>>>>>>> where to run this command? this command is not recognized >>>>>>>>>>> both in >>>>>>>>>>> engine and node. >>>>>>>>>> After installing the host, you should have this command in the >>>>>>>>>> host OS. >>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> Engine-devel mailing list >>>>>>>>>>> Engine-devel at ovirt.org >>>>>>>>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel >>>>>>>>>>> >>>>>>>>> cat /proc/cpuinfo >>>>>>>>> and >>>>>>>>> virsh capabilities >>>>>>>>> >>>>>>>>> are also interesting >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> Engine-devel mailing list >>>>>>>>> Engine-devel at ovirt.org >>>>>>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Engine-devel mailing list >>>>> Engine-devel at ovirt.org >>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel >>>>> >>>> >>>> your qemu only reports "clipper" as the support emulated machine? >>> Yes, it is. Same to Chenwei's results. >>> Could the problem be solved without re-install the os? >>> >>> >>> >> >> what does this command returns: >> $ qemu-kvm -M ? >> > # qemu-kvm -M ? > Supported machines are: > none empty machine > pc Standard PC (i440FX + PIIX, 1996) (alias of > pc-i440fx-1.4) > pc-i440fx-1.4 Standard PC (i440FX + PIIX, 1996) (default) > pc-1.3 Standard PC > pc-1.2 Standard PC > pc-1.1 Standard PC > pc-1.0 Standard PC > pc-0.15 Standard PC > pc-0.14 Standard PC > pc-0.13 Standard PC > pc-0.12 Standard PC > pc-0.11 Standard PC, qemu 0.11 > pc-0.10 Standard PC, qemu 0.10 > isapc ISA-only PC > q35 Standard PC (Q35 + ICH9, 2009) (alias of pc-q35-1.4) > pc-q35-1.4 Standard PC (Q35 + ICH9, 2009) ok, that looks ok. Might be text parsing issue. And "virsh capabilities" output? what's the vdsm you're using? Thanks, michal > > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel From gouyang at redhat.com Thu Nov 21 11:45:37 2013 From: gouyang at redhat.com (ouyang guohua) Date: Thu, 21 Nov 2013 19:45:37 +0800 Subject: [Engine-devel] failed to add host into cluster In-Reply-To: References: <51FE642C.8040307@redhat.com> <1492863435.5066137.1375682766691.JavaMail.root@redhat.com> <51FF94AE.6030807@redhat.com> <307132015.5144883.1375706091754.JavaMail.root@redhat.com> <528DCD64.5010407@redhat.com> <528DE1F1.4090603@redhat.com> <528DE793.8060500@redhat.com> <528DE858.6080502@redhat.com> <528DEAE5.4030708@redhat.com> Message-ID: <528DF261.1020407@redhat.com> On 11/21/2013 07:23 PM, Michal Skrivanek wrote: > On Nov 21, 2013, at 12:13 , ouyang guohua wrote: > >> On 11/21/2013 07:02 PM, Itamar Heim wrote: >>> On 11/21/2013 12:59 PM, ouyang guohua wrote: >>>> On 11/21/2013 06:35 PM, Itamar Heim wrote: >>>>> On 11/21/2013 11:07 AM, ouyang guohua wrote: >>>>>> Hi, >>>>>> >>>>>> I encounter the same problem today. >>>>>> >>>>>> Both the engine and the node are fedora 19. >>>>>> >>>>>> 1. on engine host: >>>>>> engine=# select * from vdc_options where option_name ilike '%emu%'; >>>>>> option_id | option_name | option_value | version >>>>>> -----------+-------------------------+------------------+--------- >>>>>> 38 | ClusterEmulatedMachines | rhel6.2.0,pc-1.0 | 3.0 >>>>>> 39 | ClusterEmulatedMachines | rhel6.3.0,pc-1.0 | 3.1 >>>>>> 40 | ClusterEmulatedMachines | rhel6.4.0,pc-1.0 | 3.2 >>>>>> 41 | ClusterEmulatedMachines | rhel6.4.0,pc-1.0 | 3.3 >>>>>> (4 rows) >>>>>> >>>>>> engine=# select name,emulated_machine from vds_groups; >>>>>> name | emulated_machine >>>>>> ---------------------+------------------ >>>>>> Default | >>>>>> fedora19-cluster | pc-1.0 >>>>>> fedora19-node-Local | pc-1.0 >>>>>> (3 rows) >>>>>> >>>>>> 2. on node: >>>>>> # vdsClient -s 0 getVdsCaps >>>>>> HBAInventory = {'iSCSI': [{'InitiatorName': >>>>>> 'iqn.1994-05.com.redhat:643bb46781e'}], 'FC': []} >>>>>> ISCSIInitiatorName = iqn.1994-05.com.redhat:643bb46781e >>>>>> bondings = {'bond4': {'addr': '', 'cfg': {}, 'mtu': '1500', >>>>>> 'netmask': '', 'slaves': [], 'hwaddr': '7e:00:7f:e7:90:4c'}, 'bond0': >>>>>> {'addr': '', 'cfg': {}, 'mtu': '1500', 'netmask': '', 'slaves': [], >>>>>> 'hwaddr': 'de:c5:12:4e:17:6f'}, 'bond1': {'addr': '', 'cfg': {}, >>>>>> 'mtu': >>>>>> '1500', 'netmask': '', 'slaves': [], 'hwaddr': '2e:ec:3b:01:ab:de'}, >>>>>> 'bond2': {'addr': '', 'cfg': {}, 'mtu': '1500', 'netmask': '', >>>>>> 'slaves': >>>>>> [], 'hwaddr': 'da:88:61:cb:0d:ed'}, 'bond3': {'addr': '', 'cfg': {}, >>>>>> 'mtu': '1500', 'netmask': '', 'slaves': [], 'hwaddr': >>>>>> '72:c4:9e:9d:25:c1'}} >>>>>> bridges = {'ovirtmgmt': {'addr': '10.66.10.186', 'cfg': >>>>>> {'PEERROUTES': 'yes', 'IPV6INIT': 'yes', 'TYPE': 'Bridge', >>>>>> 'IPV6_PEERDNS': 'yes', 'DEFROUTE': 'yes', 'ONBOOT': 'yes', 'PEERDNS': >>>>>> 'yes', 'IPV4_FAILURE_FATAL': 'no', 'DELAY': '0', 'NM_CONTROLLED': >>>>>> 'no', >>>>>> 'BOOTPROTO': 'dhcp', 'DEVICE': 'ovirtmgmt', 'IPV6_FAILURE_FATAL': >>>>>> 'no', >>>>>> 'IPV6_PEERROUTES': 'yes', 'IPV6_DEFROUTE': 'yes', 'IPV6_AUTOCONF': >>>>>> 'yes', 'UUID': '447b16c1-184a-4347-a801-ef8143c2d932'}, 'mtu': '1500', >>>>>> 'netmask': '255.255.252.0', 'stp': 'off', 'ports': ['em1']}} >>>>>> clusterLevels = ['3.0', '3.1', '3.2'] >>>>>> cpuCores = 4 >>>>>> cpuFlags = >>>>>> fpu,vme,de,pse,tsc,msr,pae,mce,cx8,apic,sep,mtrr,pge,mca,cmov,pat,pse36,clflush,dts,acpi,mmx,fxsr,sse,sse2,ss,ht,tm,pbe,syscall,nx,lm,constant_tsc,arch_perfmon,pebs,bts,rep_good,nopl,aperfmperf,pni,dtes64,monitor,ds_cpl,vmx,smx,est,tm2,ssse3,cx16,xtpr,pdcm,sse4_1,xsave,lahf_lm,dtherm,tpr_shadow,vnmi,flexpriority,model_Conroe,model_coreduo,model_core2duo,model_Penryn,model_n270 >>>>>> >>>>>> >>>>>> cpuModel = Intel(R) Core(TM)2 Quad CPU Q9400 @ 2.66GHz >>>>>> cpuSockets = 1 >>>>>> cpuSpeed = 2660.126 >>>>>> cpuThreads = 4 >>>>>> emulatedMachines = ['clipper', 'none'] >>>>>> guestOverhead = 65 >>>>>> hooks = {} >>>>>> kvmEnabled = true >>>>>> lastClient = 10.66.105.101 >>>>>> lastClientIface = ovirtmgmt >>>>>> management_ip = >>>>>> memSize = 3888 >>>>>> netConfigDirty = False >>>>>> networks = {'ovirtmgmt': {'iface': 'ovirtmgmt', 'addr': >>>>>> '10.66.10.186', 'cfg': {'PEERROUTES': 'yes', 'IPV6INIT': 'yes', >>>>>> 'TYPE': >>>>>> 'Bridge', 'IPV6_PEERDNS': 'yes', 'DEFROUTE': 'yes', 'ONBOOT': 'yes', >>>>>> 'PEERDNS': 'yes', 'IPV4_FAILURE_FATAL': 'no', 'DELAY': '0', >>>>>> 'NM_CONTROLLED': 'no', 'BOOTPROTO': 'dhcp', 'DEVICE': 'ovirtmgmt', >>>>>> 'IPV6_FAILURE_FATAL': 'no', 'IPV6_PEERROUTES': 'yes', 'IPV6_DEFROUTE': >>>>>> 'yes', 'IPV6_AUTOCONF': 'yes', 'UUID': >>>>>> '447b16c1-184a-4347-a801-ef8143c2d932'}, 'mtu': '1500', 'netmask': >>>>>> '255.255.252.0', 'stp': 'off', 'bridged': True, 'gateway': >>>>>> '10.66.11.254', 'ports': ['em1']}} >>>>>> nics = {'em1': {'addr': '', 'cfg': {'PEERROUTES': 'yes', >>>>>> 'BRIDGE': >>>>>> 'ovirtmgmt', 'DEVICE': 'em1', 'IPV6INIT': 'yes', 'IPV6_PEERDNS': >>>>>> 'yes', >>>>>> 'DEFROUTE': 'yes', 'ONBOOT': 'yes', 'PEERDNS': 'yes', >>>>>> 'IPV4_FAILURE_FATAL': 'no', 'NM_CONTROLLED': 'no', 'IPV6_DEFROUTE': >>>>>> 'yes', 'IPV6_AUTOCONF': 'yes', 'IPV6_FAILURE_FATAL': 'no', >>>>>> 'IPV6_PEERROUTES': 'yes', 'HWADDR': '00:23:ae:9d:85:32', 'UUID': >>>>>> '447b16c1-184a-4347-a801-ef8143c2d932'}, 'mtu': '1500', 'netmask': '', >>>>>> 'hwaddr': '00:23:ae:9d:85:32', 'speed': 1000}} >>>>>> operatingSystem = {'release': '4', 'version': '19', 'name': >>>>>> 'Fedora'} >>>>>> packages2 = {'kernel': {'release': '200.fc19.x86_64', >>>>>> 'buildtime': >>>>>> 1383545343.0, 'version': '3.11.7'}, 'spice-server': {'release': >>>>>> '3.fc19', 'buildtime': 1383130020, 'version': '0.12.4'}, 'vdsm': >>>>>> {'release': '18.fc19', 'buildtime': 1373484771, 'version': '4.10.3'}, >>>>>> 'qemu-kvm': {'release': '13.fc19', 'buildtime': 1383700301, 'version': >>>>>> '1.4.2'}, 'libvirt': {'release': '1.fc19', 'buildtime': 1383765188, >>>>>> 'version': '1.0.5.7'}, 'qemu-img': {'release': '13.fc19', 'buildtime': >>>>>> 1383700301, 'version': '1.4.2'}, 'mom': {'release': '1.fc19', >>>>>> 'buildtime': 1373298035, 'version': '0.3.1'}} >>>>>> reservedMem = 321 >>>>>> software_revision = 18 >>>>>> software_version = 4.10 >>>>>> supportedENGINEs = ['3.0', '3.1'] >>>>>> supportedProtocols = ['2.2', '2.3'] >>>>>> uuid = 44454C4C-4C00-1031-8053-CAC04F4E3258 >>>>>> version_name = Snow Man >>>>>> vlans = {} >>>>>> vmTypes = ['kvm'] >>>>>> >>>>>> 3. the vdsm.log is cutting to small size, if some useful logs isn't in >>>>>> it, please ask me to re-send it. >>>>>> >>>>>> Thanks, >>>>>> guohua >>>>>> >>>>>> On 08/06/2013 03:08 PM, Chen, Wei D wrote: >>>>>>> The issue is solved by reinstalling host OS. >>>>>>> >>>>>>> Best Regards, >>>>>>> Dave Chen >>>>>>> >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Chen, Wei D >>>>>>>> Sent: Tuesday, August 06, 2013 2:44 PM >>>>>>>> To: 'Laszlo Hornyak'; Itamar Heim >>>>>>>> Cc: Zhang, Lijuan;engine-devel at ovirt.org >>>>>>>> Subject: RE: [Engine-devel] failed to add host into cluster >>>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>> >>>>>>>> [root at onode vdsm]# vdsClient -s 0 getVdsCaps >>>>>>>> HBAInventory = {'iSCSI': [{'InitiatorName': >>>>>>>> 'iqn.1994-05.com.redhat:9fb571e343'}], 'FC': []} >>>>>>>> ISCSIInitiatorName = iqn.1994-05.com.redhat:9fb571e343 >>>>>>>> bondings = {'bond4': {'addr': '', 'cfg': {}, 'mtu': >>>>>>>> '1500', 'netmask': '', 'slaves': [], 'hwaddr': '0e:00:b7:57:2c:c9'}, >>>>>>>> 'bond0': {'addr': '', 'cfg': {}, 'mtu': '1500', 'netmask': '', >>>>>>>> 'slaves': [], 'hwaddr': '32:b3:88:1f:ef:91'}, 'bond1': {'addr': '', >>>>>>>> 'cfg': {}, 'mtu': '1500', 'netmask': '', 'slaves': [], 'hwaddr': >>>>>>>> '4e:e5:80:93:ea:d9'}, 'bond2': {'addr': '', 'cfg': {}, 'mtu': >>>>>>>> '1500', >>>>>>>> 'netmask': '', 'slaves': [], 'hwaddr': '16:ab:f6:e4:f2:27'}, >>>>>>>> 'bond3': {'addr': '', 'cfg': {}, 'mtu': '1500', 'netmask': '', >>>>>>>> 'slaves': >>>>>>>> [], 'hwaddr': 'ee:55:f5:e7:31:7c'}} >>>>>>>> bridges = {'ovirtmgmt': {'addr': '10.239.131.217', 'cfg': >>>>>>>> {'PEERROUTES': 'yes', 'DEVICE': 'ovirtmgmt', 'IPV6INIT': 'yes', >>>>>>>> 'UUID': 'b6ecfa9d-0deb-4213-9348-11137f76735d', 'IPV6_PEERDNS': >>>>>>>> 'yes', 'DEFROUTE': 'yes', 'PEERDNS': 'yes', 'IPV4_FAILURE_FATAL': >>>>>>>> 'no', 'DELAY': '0', 'NM_CONTROLLED': 'no', 'IPV6_DEFROUTE': 'yes', >>>>>>>> 'IPV6_AUTOCONF': 'yes', 'IPV6_FAILURE_FATAL': 'no', 'TYPE': >>>>>>>> 'Bridge', 'ONBOOT': 'yes', 'BOOTPROTO': 'dhcp', 'IPV6_PEERROUTES': >>>>>>>> 'yes'}, 'mtu': '1500', 'netmask': '255.255.255.0', 'stp': 'off', >>>>>>>> 'ports': ['em1']}} >>>>>>>> clusterLevels = ['3.0', '3.1', '3.2'] >>>>>>>> cpuCores = 4 >>>>>>>> cpuFlags = >>>>>>>> fpu,vme,de,pse,tsc,msr,pae,mce,cx8,apic,sep,mtrr,pge,mca,cmov,pat,pse36,clflush,dts,acpi,mmx,fxsr,sse,sse2,ss,ht,tm,pbe,syscall,nx,r >>>>>>>> >>>>>>>> >>>>>>>> dtscp,lm,constant_tsc,arch_perfmon,pebs,bts,rep_good,nopl,xtopology,nonstop_tsc,aperfmperf,eagerfpu,pni,pclmulqdq,dtes64,monitor, >>>>>>>> >>>>>>>> >>>>>>>> ds_cpl,vmx,smx,est,tm2,ssse3,cx16,xtpr,pdcm,pcid,sse4_1,sse4_2,x2apic,popcnt,tsc_deadline_timer,aes,xsave,avx,lahf_lm,ida,arat,epb, >>>>>>>> >>>>>>>> >>>>>>>> xsaveopt,pln,pts,dtherm,tpr_shadow,vnmi,flexpriority,ept,vpid,model_Nehalem,model_Conroe,model_coreduo,model_core2duo,model_P >>>>>>>> >>>>>>>> >>>>>>>> enryn,model_Westmere,model_n270,model_SandyBridge >>>>>>>> cpuModel = Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz >>>>>>>> cpuSockets = 1 >>>>>>>> cpuSpeed = 3672.000 >>>>>>>> cpuThreads = 8 >>>>>>>> emulatedMachines = ['clipper', 'none'] >>>>>>>> guestOverhead = 65 >>>>>>>> hooks = {} >>>>>>>> kvmEnabled = true >>>>>>>> lastClient = 10.239.131.222 >>>>>>>> lastClientIface = ovirtmgmt >>>>>>>> management_ip = >>>>>>>> memSize = 7944 >>>>>>>> netConfigDirty = False >>>>>>>> networks = {'ovirtmgmt': {'iface': 'ovirtmgmt', 'addr': >>>>>>>> '10.239.131.217', 'cfg': {'PEERROUTES': 'yes', 'DEVICE': >>>>>>>> 'ovirtmgmt', >>>>>>>> 'IPV6INIT': 'yes', 'UUID': 'b6ecfa9d-0deb-4213-9348-11137f76735d', >>>>>>>> 'IPV6_PEERDNS': 'yes', 'DEFROUTE': 'yes', 'PEERDNS': 'yes', >>>>>>>> 'IPV4_FAILURE_FATAL': 'no', 'DELAY': '0', 'NM_CONTROLLED': 'no', >>>>>>>> 'IPV6_DEFROUTE': 'yes', 'IPV6_AUTOCONF': 'yes', >>>>>>>> 'IPV6_FAILURE_FATAL': >>>>>>>> 'no', 'TYPE': 'Bridge', 'ONBOOT': 'yes', 'BOOTPROTO': 'dhcp', >>>>>>>> 'IPV6_PEERROUTES': 'yes'}, 'mtu': '1500', 'netmask': >>>>>>>> '255.255.255.0', >>>>>>>> 'stp': 'off', 'bridged': True, 'gateway': '10.239.131.1', 'ports': >>>>>>>> ['em1']}} >>>>>>>> nics = {'em1': {'addr': '', 'cfg': {}, 'mtu': '1500', >>>>>>>> 'netmask': '', 'hwaddr': '2c:41:38:b2:d0:e8', 'speed': 100}} >>>>>>>> operatingSystem = {'release': '0.5', 'version': '19', >>>>>>>> 'name': 'Fedora'} >>>>>>>> packages2 = {'kernel': {'release': '301.fc19.x86_64', >>>>>>>> 'buildtime': 1368462984.0, 'version': '3.9.2'}, 'spice-server': >>>>>>>> {'release': '5.fc19', 'buildtime': 1366036951, 'version': >>>>>>>> '0.12.2'}, 'vdsm': {'release': '18.fc19', 'buildtime': 1373484771, >>>>>>>> 'version': '4.10.3'}, 'qemu-kvm': {'release': '4.fc19', >>>>>>>> 'buildtime': 1371653911, 'version': '1.4.2'}, 'libvirt': {'release': >>>>>>>> '1.fc19', >>>>>>>> 'buildtime': 1371074681, 'version': '1.0.5.2'}, 'qemu-img': >>>>>>>> {'release': '4.fc19', 'buildtime': 1371653911, 'version': '1.4.2'}, >>>>>>>> 'mom': >>>>>>>> {'release': '2.fc19', 'buildtime': 1374564325, 'version': '0.3.2'}} >>>>>>>> reservedMem = 321 >>>>>>>> software_revision = 18 >>>>>>>> software_version = 4.10 >>>>>>>> supportedENGINEs = ['3.0', '3.1'] >>>>>>>> supportedProtocols = ['2.2', '2.3'] >>>>>>>> uuid = 30BBC800-4F47-11E0-0000-2C4138B2D0E8 >>>>>>>> version_name = Snow Man >>>>>>>> vlans = {} >>>>>>>> vmTypes = ['kvm'] >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Best Regards, >>>>>>>> Dave Chen >>>>>>>> >>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: Laszlo Hornyak [mailto:lhornyak at redhat.com] >>>>>>>>> Sent: Monday, August 05, 2013 8:35 PM >>>>>>>>> To: Itamar Heim >>>>>>>>> Cc: Chen, Wei D; Zhang, Lijuan;engine-devel at ovirt.org >>>>>>>>> Subject: Re: [Engine-devel] failed to add host into cluster >>>>>>>>> >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> Dave, could you also share the vdsm log as well? >>>>>>>>> >>>>>>>>> I managed to reproduce this on the host that I am using for years >>>>>>>>> and I am using it now, so it should not be a hardware problem. >>>>>>>>> Probably >>>>>>>>> some broken configuration caused some problem in vdsm before it >>>>>>>>> would retrieve the capabilities information from libvirt. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> ----- Original Message ----- >>>>>>>>>> From: "Itamar Heim" >>>>>>>>>> To: "Laszlo Hornyak" >>>>>>>>>> Cc: "Wei D Chen", "Lijuan Zhang" >>>>>>>>>> ,engine-devel at ovirt.org >>>>>>>>>> Sent: Monday, August 5, 2013 2:03:58 PM >>>>>>>>>> Subject: Re: [Engine-devel] failed to add host into cluster >>>>>>>>>> >>>>>>>>>> On 08/05/2013 09:06 AM, Laszlo Hornyak wrote: >>>>>>>>>>> ----- Original Message ----- >>>>>>>>>>>> From: "Wei D Chen" >>>>>>>>>>>> To: "Itamar Heim" >>>>>>>>>>>> Cc: "Lijuan >>>>>>>>>>>> Zhang",engine-devel at ovirt.org >>>>>>>>>>>> Sent: Monday, August 5, 2013 8:03:08 AM >>>>>>>>>>>> Subject: Re: [Engine-devel] failed to add host into cluster >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Best Regards, >>>>>>>>>>>> Dave Chen >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>> From: Itamar Heim [mailto:iheim at redhat.com] >>>>>>>>>>>>> Sent: Sunday, August 04, 2013 10:25 PM >>>>>>>>>>>>> To: Chen, Wei D >>>>>>>>>>>>> Cc:engine-devel at ovirt.org; Zhang, Lijuan >>>>>>>>>>>>> Subject: Re: [Engine-devel] failed to add host into cluster >>>>>>>>>>>>> >>>>>>>>>>>>> On 08/02/2013 09:34 AM, Chen, Wei D wrote: >>>>>>>>>>>>>> Failed to add a node into cluster. I saw follow hints, but >>>>>>>>>>>>>> still >>>>>>>>>>>>>> don't know how to fix it. OS is fedora 19 both for node and >>>>>>>>>>>>>> engine, anyone can help me? >>>>>>>>>>>>>> >>>>>>>>>>>>>> Host *** does not comply with the cluster *** emulated >>>>>>>>>>>>>> machines. >>>>>>>>>>>>>> The Hosts emulated machines are clipper,none and the >>>>>>>>>>>>>> cluster is >>>>>>>>>>>>>> [rhel6.4.0, pc-1.0]} >>>>>>>>>>>>> what Os is the host running? >>>>>>>>>>>> fedora 19 >>>>>>>>>>>>> what does 'vdsClient -s 0 getVdsCaps' returns? >>>>>>>>>>>> where to run this command? this command is not recognized >>>>>>>>>>>> both in >>>>>>>>>>>> engine and node. >>>>>>>>>>> After installing the host, you should have this command in the >>>>>>>>>>> host OS. >>>>>>>>>>> >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> Engine-devel mailing list >>>>>>>>>>>> Engine-devel at ovirt.org >>>>>>>>>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel >>>>>>>>>>>> >>>>>>>>>> cat /proc/cpuinfo >>>>>>>>>> and >>>>>>>>>> virsh capabilities >>>>>>>>>> >>>>>>>>>> are also interesting >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> Engine-devel mailing list >>>>>>>>>> Engine-devel at ovirt.org >>>>>>>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Engine-devel mailing list >>>>>> Engine-devel at ovirt.org >>>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel >>>>>> >>>>> your qemu only reports "clipper" as the support emulated machine? >>>> Yes, it is. Same to Chenwei's results. >>>> Could the problem be solved without re-install the os? >>>> >>>> >>>> >>> what does this command returns: >>> $ qemu-kvm -M ? >>> >> # qemu-kvm -M ? >> Supported machines are: >> none empty machine >> pc Standard PC (i440FX + PIIX, 1996) (alias of >> pc-i440fx-1.4) >> pc-i440fx-1.4 Standard PC (i440FX + PIIX, 1996) (default) >> pc-1.3 Standard PC >> pc-1.2 Standard PC >> pc-1.1 Standard PC >> pc-1.0 Standard PC >> pc-0.15 Standard PC >> pc-0.14 Standard PC >> pc-0.13 Standard PC >> pc-0.12 Standard PC >> pc-0.11 Standard PC, qemu 0.11 >> pc-0.10 Standard PC, qemu 0.10 >> isapc ISA-only PC >> q35 Standard PC (Q35 + ICH9, 2009) (alias of pc-q35-1.4) >> pc-q35-1.4 Standard PC (Q35 + ICH9, 2009) > ok, that looks ok. Might be text parsing issue. > And "virsh capabilities" output? > what's the vdsm you're using? virsh capabilities" output is a bit long, see attachment # rpm -q vdsm vdsm-4.10.3-18.fc19.x86_64 > > Thanks, > michal >> _______________________________________________ >> Engine-devel mailing list >> Engine-devel at ovirt.org >> http://lists.ovirt.org/mailman/listinfo/engine-devel -------------- next part -------------- # virsh capabilities Please enter your authentication name: vdsm at ovirt Please enter your password: 0056beeb-d5ee-4f31-8b90-52207fbe1336 x86_64 Penryn Intel tcp 3981616 selinux 0 dac 0 hvm 64 /usr/bin/qemu-system-alpha clipper none hvm 32 /usr/bin/qemu-system-arm integratorcp z2 xilinx-zynq-a9 vexpress-a15 vexpress-a9 versatileab versatilepb tosa lm3s6965evb lm3s811evb terrier borzoi spitz akita realview-pbx-a9 realview-pb-a8 realview-eb-mpcore realview-eb cheetah sx1-v1 sx1 n810 n800 musicpal mainstone kzm highbank verdex connex smdkc210 nuri collie none hvm 32 /usr/bin/qemu-system-cris axis-dev88 none hvm 32 /usr/bin/qemu-system-i386 pc q35 isapc pc-0.10 pc-0.11 pc-0.12 pc-0.13 pc-0.14 pc-0.15 pc-1.0 pc-1.1 pc-1.2 pc-1.3 none /usr/bin/qemu-kvm pc q35 isapc pc-0.10 pc-0.11 pc-0.12 pc-0.13 pc-0.14 pc-0.15 pc-1.0 pc-1.1 pc-1.2 pc-1.3 none hvm 32 /usr/bin/qemu-system-lm32 lm32-evr milkymist lm32-uclinux none hvm 32 /usr/bin/qemu-system-m68k mcf5208evb dummy an5206 none hvm 32 /usr/bin/qemu-system-microblaze petalogix-s3adsp1800 petalogix-ml605 none hvm 32 /usr/bin/qemu-system-microblazeel petalogix-s3adsp1800 petalogix-ml605 none hvm 32 /usr/bin/qemu-system-mips malta mips mipssim pica61 magnum none hvm 32 /usr/bin/qemu-system-mipsel malta mips mipssim pica61 magnum none hvm 64 /usr/bin/qemu-system-mips64 malta mips mipssim pica61 magnum none hvm 64 /usr/bin/qemu-system-mips64el malta mips mipssim pica61 magnum fulong2e none hvm 32 /usr/bin/qemu-system-ppc g3beige prep mpc8544ds mac99 ppce500 virtex-ml507 bamboo taihu ref405ep none hvm 64 /usr/bin/qemu-system-ppc64 mac99 prep mpc8544ds g3beige ppce500 virtex-ml507 pseries bamboo taihu ref405ep none hvm 32 /usr/bin/qemu-system-ppcemb g3beige prep mpc8544ds mac99 ppce500 virtex-ml507 bamboo taihu ref405ep none hvm 64 /usr/bin/qemu-system-s390x s390 s390-ccw none hvm 32 /usr/bin/qemu-system-sh4 shix r2d none hvm 64 /usr/bin/qemu-system-sh4eb shix r2d none hvm 32 /usr/bin/qemu-system-sparc SS-5 SS-2 SS-2000 SS-1000 SPARCbook SPARCClassic SS-4 LX Voyager SS-20 SS-600MP SS-10 leon3_generic none hvm 64 /usr/bin/qemu-system-sparc64 sun4u Niagara sun4v none hvm 32 /usr/bin/qemu-system-unicore32 puv3 none hvm 64 /usr/bin/qemu-system-x86_64 pc q35 isapc pc-0.10 pc-0.11 pc-0.12 pc-0.13 pc-0.14 pc-0.15 pc-1.0 pc-1.1 pc-1.2 pc-1.3 none /usr/bin/qemu-kvm pc q35 isapc pc-0.10 pc-0.11 pc-0.12 pc-0.13 pc-0.14 pc-0.15 pc-1.0 pc-1.1 pc-1.2 pc-1.3 none hvm 32 /usr/bin/qemu-system-xtensa sim lx200 lx60 none hvm 32 /usr/bin/qemu-system-xtensaeb sim lx200 lx60 none From derez at redhat.com Thu Nov 21 12:18:42 2013 From: derez at redhat.com (Daniel Erez) Date: Thu, 21 Nov 2013 07:18:42 -0500 (EST) Subject: [Engine-devel] Weird behavior of multiple SetVmTicket query In-Reply-To: <2103394455.7731737.1384809563452.JavaMail.root@redhat.com> References: <1405029090.20090071.1384159399724.JavaMail.root@redhat.com> <1757293.UZ46spY3rU@awels> <989864807.20226412.1384181602956.JavaMail.root@redhat.com> <1416897.Cty3puulVa@awels> <630563857.22230004.1384256418496.JavaMail.root@redhat.com> <2103394455.7731737.1384809563452.JavaMail.root@redhat.com> Message-ID: <1271140188.38461697.1385036322859.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Einav Cohen" > To: "Livnat Peer" , "Eli Mesika" , "Omer Frenkel" , "Doron > Fediuck" , "Oved Ourfalli" > Cc: "engine-devel" > Sent: Monday, November 18, 2013 11:19:23 PM > Subject: Re: [Engine-devel] Weird behavior of multiple SetVmTicket query > > engine-core maintainers - this one is mainly for you - see below. > the most important question (I think) is: Is there any reason > to not introduced a "sync" flavor of RunMultipleActions (i.e. > one that will return from the backend only when all actions have > been completed, similarly to RunAction)? There's a couple of years old patch exactly for that [1]. It should allow both synchronous and asynchronous multiple actions according to a flag. Question is when do we want to use the synchronous flavor? The reasoning behind the current implementation is to return a quick response to the client, as executing multiple vdsm commands can potentially require a long wait. Do we need to introduce a sync version just for VM console connection flow? IIRC, the flow actually uses multiple calls to the singular form (RunAction) rather than RunMultipleAction? [1] http://gerrit.ovirt.org/#/c/3210/ > > ---- > Thanks, > Einav > > ----- Original Message ----- > > From: "Vojtech Szocs" > > To: awels at redhat.com > > Cc: "engine-devel" > > Sent: Tuesday, November 12, 2013 6:40:18 AM > > Subject: Re: [Engine-devel] Weird behavior of multiple SetVmTicket query > > > > Forwarding this email to engine-devel so that backend maintainers are aware > > of this issue. > > > > Looking at the code: > > > > - MultipleActionsRunner#Execute first creates and "validates" all commands: > > > > A. the "for" block which iterates over getParameters() > > 1-> validate correlation ID, if OK create and add command, otherwise > > add > > returnValue > > > > B the "if" block which tests getCommands().size() > > 1-> if single command to execute, add its "canDoActionOnly" > > returnValue, > > which is returnValue with canDoAction but without actual result object > > 2-> if multi commands to execute, execute chunks of max. 10 threads > > (sequentially, ThreadPoolUtil.invokeAll returns after all threads > > complete), same returnValue as above > > > > C. the "if" block which tests canRunActions > > 1-> all commands are executed within SINGLE THREAD due to > > ThreadPoolUtil.execute(Runnable), which is kind of weird comapred to > > how returnValues are prepared (see B2) > > 2-> when executing command, code DOES NOT CARE about its returnValue, > > i.e. returnValue was already prepared (see B) and command execution > > should just update it > > > > The problem (I think) is that C1 starts a different thread (to execute all > > commands) and immediately returns, i.e. code doesn't wait for thread to > > complete. This is why returnValues are observed on frontend as > > inconsistent. > > > > Additionally, we're also mixing of two different things: canDoAction > > processing and returnValues processing. IMHO this should be refactored to > > make code easier to read. > > > > Changes done by Alex (patch attached): > > > > X1. returnValues changed to Collections.synchronizedList > > -> this means all access to returnValues is now serial > > -> iteration over synchronizedList should also be enclosed in > > "synchronized (list)" block, so this: > > > > for (VdcReturnValueBase value : returnValues) ... > > > > should be this: > > > > synchronized (returnValues) { for (VdcReturnValueBase value : > > returnValues) ... } > > > > X2. commented-out original command execution via > > ThreadPoolUtil.execute(Runnable) > > -> new RunCommands method invokes all commands each in separate thread > > via ThreadPoolUtil.invokeAll > > -> returnValues list is explicitly updated > > > > Guys, what do you think? > > > > Vojtech > > > > > > ----- Original Message ----- > > > From: "Alexander Wels" > > > To: "Frantisek Kobzik" > > > Cc: "Vojtech Szocs" > > > Sent: Monday, November 11, 2013 9:19:08 PM > > > Subject: Re: Weird behavior of multiple SetVmTicket query > > > > > > Hi, > > > > > > I did some debugging, and the problem is a race condition in the > > > MultipleActions class. The whole class seems to have a lot of > > > multi-threading > > > issues but if I modify the code to wait for the results of the actions to > > > return before returning the return value, everything works fine. > > > > > > I am attaching a patch that solves the issue at hand, but should not be > > > considered a real patch. It is just to show the issue is in the back-end > > > not > > > the front-end code. The front-end code is just exposing an issue in the > > > back- > > > end > > > > > > Alexander > > > > > > On Monday, November 11, 2013 09:53:22 AM you wrote: > > > > Ok, thank you very much! > > > > > > > > ----- Original Message ----- > > > > From: "Alexander Wels" > > > > To: "Frantisek Kobzik" > > > > Sent: Monday, November 11, 2013 2:15:43 PM > > > > Subject: Re: Weird behavior of multiple SetVmTicket query > > > > > > > > Frantisek, > > > > > > > > I had seen this before, let me test and fix it for you, it is very > > > > likely > > > > my > > > > patch broke that. > > > > > > > > Alexander > > > > > > > > On Monday, November 11, 2013 03:43:19 AM you wrote: > > > > > Hi Alex, > > > > > > > > > > recently I noticed problems with invoking console for multiple VMs > > > > > (select > > > > > more VMs in webadmin and then hit the console btn). I was sure it > > > > > worked > > > > > in > > > > > past so i git-bisected the master branch and I discovered that this > > > > > problem > > > > > is apparently caused by patch [1]. For single vm console invocation > > > > > it > > > > > works fine, but for multiple VMs it doesn't. > > > > > > > > > > I did some closer investigation with a debugger and it seems that > > > > > getSucceeded() on the return val of SetVmTicket command returns false > > > > > in > > > > > case of multiple execution despite the fact SetVmTicketCommand sets > > > > > this > > > > > value to true. I suppose there is some problem with propagation of > > > > > command > > > > > return value from BE to FE. The same goes for the encapsulated > > > > > returnValue > > > > > attribute (it contains value of the generated ticket). When invoking > > > > > multiple consoles it is null (although it has been filled on > > > > > backend). > > > > > Weird. > > > > > > > > > > Tomas told me you did some optimizations for multiple command > > > > > executions, > > > > > do you know it might cause it? Please let me know if you have any > > > > > idea... > > > > > > > > > > Cheers, > > > > > F. > > > > > > > > > > [1]: http://gerrit.ovirt.org/#/c/17356/ > > > > > > > _______________________________________________ > > Engine-devel mailing list > > Engine-devel at ovirt.org > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > From awels at redhat.com Thu Nov 21 13:28:32 2013 From: awels at redhat.com (Alexander Wels) Date: Thu, 21 Nov 2013 08:28:32 -0500 Subject: [Engine-devel] Weird behavior of multiple SetVmTicket query In-Reply-To: <1271140188.38461697.1385036322859.JavaMail.root@redhat.com> References: <1405029090.20090071.1384159399724.JavaMail.root@redhat.com> <2103394455.7731737.1384809563452.JavaMail.root@redhat.com> <1271140188.38461697.1385036322859.JavaMail.root@redhat.com> Message-ID: <2843639.Zr1A8Fd6ET@awels> On Thursday, November 21, 2013 07:18:42 AM Daniel Erez wrote: > ----- Original Message ----- > > > From: "Einav Cohen" > > To: "Livnat Peer" , "Eli Mesika" , > > "Omer Frenkel" , "Doron Fediuck" > > , "Oved Ourfalli" Cc: > > "engine-devel" > > Sent: Monday, November 18, 2013 11:19:23 PM > > Subject: Re: [Engine-devel] Weird behavior of multiple SetVmTicket query > > > > engine-core maintainers - this one is mainly for you - see below. > > the most important question (I think) is: Is there any reason > > to not introduced a "sync" flavor of RunMultipleActions (i.e. > > one that will return from the backend only when all actions have > > been completed, similarly to RunAction)? > > There's a couple of years old patch exactly for that [1]. > It should allow both synchronous and asynchronous multiple actions according > to a flag. Question is when do we want to use the synchronous flavor? > The reasoning behind the current implementation is to return a quick > response to the client, as executing multiple vdsm commands can potentially > require a long wait. Do we need to introduce a sync version just for VM > console connection flow? IIRC, the flow actually uses multiple calls to the > singular form (RunAction) rather than RunMultipleAction? > > [1] http://gerrit.ovirt.org/#/c/3210/ > We recently introduced a patch [1] that on the front-end is smart enough to consolidate multiple query/actions into a single runMultiple(Query/Action) call to reduce the number http requests to the back-end. In the SetVMTicket case it combined two actions into one runMultipleAction call and was expected that to return once all the actions where complete, which didn't happen causing some undesired behavior on the client side. This sparked the investigation that ended in this email. So yes I would definitely like a 'synchronous' version of runMultipleAction so the frontend code can set that flag when combining multiple actions into a single call. We can only safely do this if we are combining several runActions as all of those are 'synchronous'. [1] http://gerrit.ovirt.org/#/c/17356/ > > ---- > > Thanks, > > Einav > > > > ----- Original Message ----- > > > > > From: "Vojtech Szocs" > > > To: awels at redhat.com > > > Cc: "engine-devel" > > > Sent: Tuesday, November 12, 2013 6:40:18 AM > > > Subject: Re: [Engine-devel] Weird behavior of multiple SetVmTicket query > > > > > > Forwarding this email to engine-devel so that backend maintainers are > > > aware > > > of this issue. > > > > > > Looking at the code: > > > > > > - MultipleActionsRunner#Execute first creates and "validates" all commands: > > > A. the "for" block which iterates over getParameters() > > > > > > 1-> validate correlation ID, if OK create and add command, > > > otherwise > > > add > > > returnValue > > > > > > B the "if" block which tests getCommands().size() > > > > > > 1-> if single command to execute, add its "canDoActionOnly" > > > returnValue, > > > which is returnValue with canDoAction but without actual result > > > object > > > 2-> if multi commands to execute, execute chunks of max. 10 threads > > > (sequentially, ThreadPoolUtil.invokeAll returns after all threads > > > complete), same returnValue as above > > > > > > C. the "if" block which tests canRunActions > > > > > > 1-> all commands are executed within SINGLE THREAD due to > > > ThreadPoolUtil.execute(Runnable), which is kind of weird comapred > > > to > > > how returnValues are prepared (see B2) > > > 2-> when executing command, code DOES NOT CARE about its > > > returnValue, > > > i.e. returnValue was already prepared (see B) and command execution > > > should just update it > > > > > > The problem (I think) is that C1 starts a different thread (to execute > > > all > > > commands) and immediately returns, i.e. code doesn't wait for thread to > > > complete. This is why returnValues are observed on frontend as > > > inconsistent. > > > > > > Additionally, we're also mixing of two different things: canDoAction > > > processing and returnValues processing. IMHO this should be refactored > > > to > > > make code easier to read. > > > > > > Changes done by Alex (patch attached): > > > > > > X1. returnValues changed to Collections.synchronizedList > > > > > > -> this means all access to returnValues is now serial > > > -> iteration over synchronizedList should also be enclosed in > > > > > > "synchronized (list)" block, so this: > > > for (VdcReturnValueBase value : returnValues) ... > > > > > > should be this: > > > synchronized (returnValues) { for (VdcReturnValueBase value : > > > returnValues) ... } > > > > > > X2. commented-out original command execution via > > > ThreadPoolUtil.execute(Runnable) > > > > > > -> new RunCommands method invokes all commands each in separate > > > thread > > > via ThreadPoolUtil.invokeAll > > > -> returnValues list is explicitly updated > > > > > > Guys, what do you think? > > > > > > Vojtech > > > > > > > > > ----- Original Message ----- > > > > > > > From: "Alexander Wels" > > > > To: "Frantisek Kobzik" > > > > Cc: "Vojtech Szocs" > > > > Sent: Monday, November 11, 2013 9:19:08 PM > > > > Subject: Re: Weird behavior of multiple SetVmTicket query > > > > > > > > Hi, > > > > > > > > I did some debugging, and the problem is a race condition in the > > > > MultipleActions class. The whole class seems to have a lot of > > > > multi-threading > > > > issues but if I modify the code to wait for the results of the actions > > > > to > > > > return before returning the return value, everything works fine. > > > > > > > > I am attaching a patch that solves the issue at hand, but should not > > > > be > > > > considered a real patch. It is just to show the issue is in the > > > > back-end > > > > not > > > > the front-end code. The front-end code is just exposing an issue in > > > > the > > > > back- > > > > end > > > > > > > > Alexander > > > > > > > > On Monday, November 11, 2013 09:53:22 AM you wrote: > > > > > Ok, thank you very much! > > > > > > > > > > ----- Original Message ----- > > > > > From: "Alexander Wels" > > > > > To: "Frantisek Kobzik" > > > > > Sent: Monday, November 11, 2013 2:15:43 PM > > > > > Subject: Re: Weird behavior of multiple SetVmTicket query > > > > > > > > > > Frantisek, > > > > > > > > > > I had seen this before, let me test and fix it for you, it is very > > > > > likely > > > > > my > > > > > patch broke that. > > > > > > > > > > Alexander > > > > > > > > > > On Monday, November 11, 2013 03:43:19 AM you wrote: > > > > > > Hi Alex, > > > > > > > > > > > > recently I noticed problems with invoking console for multiple VMs > > > > > > (select > > > > > > more VMs in webadmin and then hit the console btn). I was sure it > > > > > > worked > > > > > > in > > > > > > past so i git-bisected the master branch and I discovered that > > > > > > this > > > > > > problem > > > > > > is apparently caused by patch [1]. For single vm console > > > > > > invocation > > > > > > it > > > > > > works fine, but for multiple VMs it doesn't. > > > > > > > > > > > > I did some closer investigation with a debugger and it seems that > > > > > > getSucceeded() on the return val of SetVmTicket command returns > > > > > > false > > > > > > in > > > > > > case of multiple execution despite the fact SetVmTicketCommand > > > > > > sets > > > > > > this > > > > > > value to true. I suppose there is some problem with propagation of > > > > > > command > > > > > > return value from BE to FE. The same goes for the encapsulated > > > > > > returnValue > > > > > > attribute (it contains value of the generated ticket). When > > > > > > invoking > > > > > > multiple consoles it is null (although it has been filled on > > > > > > backend). > > > > > > Weird. > > > > > > > > > > > > Tomas told me you did some optimizations for multiple command > > > > > > executions, > > > > > > do you know it might cause it? Please let me know if you have any > > > > > > idea... > > > > > > > > > > > > Cheers, > > > > > > F. > > > > > > > > > > > > [1]: http://gerrit.ovirt.org/#/c/17356/ > > > > > > _______________________________________________ > > > Engine-devel mailing list > > > Engine-devel at ovirt.org > > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > > _______________________________________________ > > Engine-devel mailing list > > Engine-devel at ovirt.org > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel From iheim at redhat.com Thu Nov 21 14:01:34 2013 From: iheim at redhat.com (Itamar Heim) Date: Thu, 21 Nov 2013 16:01:34 +0200 Subject: [Engine-devel] Weird behavior of multiple SetVmTicket query In-Reply-To: <2843639.Zr1A8Fd6ET@awels> References: <1405029090.20090071.1384159399724.JavaMail.root@redhat.com> <2103394455.7731737.1384809563452.JavaMail.root@redhat.com> <1271140188.38461697.1385036322859.JavaMail.root@redhat.com> <2843639.Zr1A8Fd6ET@awels> Message-ID: <528E123E.2050706@redhat.com> On 11/21/2013 03:28 PM, Alexander Wels wrote: > On Thursday, November 21, 2013 07:18:42 AM Daniel Erez wrote: >> ----- Original Message ----- >> >>> From: "Einav Cohen" >>> To: "Livnat Peer" , "Eli Mesika" , >>> "Omer Frenkel" , "Doron Fediuck" >>> , "Oved Ourfalli" Cc: >>> "engine-devel" >>> Sent: Monday, November 18, 2013 11:19:23 PM >>> Subject: Re: [Engine-devel] Weird behavior of multiple SetVmTicket query >>> >>> engine-core maintainers - this one is mainly for you - see below. >>> the most important question (I think) is: Is there any reason >>> to not introduced a "sync" flavor of RunMultipleActions (i.e. >>> one that will return from the backend only when all actions have >>> been completed, similarly to RunAction)? >> >> There's a couple of years old patch exactly for that [1]. >> It should allow both synchronous and asynchronous multiple actions according >> to a flag. Question is when do we want to use the synchronous flavor? >> The reasoning behind the current implementation is to return a quick >> response to the client, as executing multiple vdsm commands can potentially >> require a long wait. Do we need to introduce a sync version just for VM >> console connection flow? IIRC, the flow actually uses multiple calls to the >> singular form (RunAction) rather than RunMultipleAction? >> >> [1] http://gerrit.ovirt.org/#/c/3210/ >> > > We recently introduced a patch [1] that on the front-end is smart enough to > consolidate multiple query/actions into a single runMultiple(Query/Action) > call to reduce the number http requests to the back-end. In the SetVMTicket > case it combined two actions into one runMultipleAction call and was expected > that to return once all the actions where complete, which didn't happen > causing some undesired behavior on the client side. This sparked the > investigation that ended in this email. > > So yes I would definitely like a 'synchronous' version of runMultipleAction so > the frontend code can set that flag when combining multiple actions into a > single call. We can only safely do this if we are combining several runActions > as all of those are 'synchronous'. > > [1] http://gerrit.ovirt.org/#/c/17356/ btw, how is this going to work with the REST API? > >>> ---- >>> Thanks, >>> Einav >>> >>> ----- Original Message ----- >>> >>>> From: "Vojtech Szocs" >>>> To: awels at redhat.com >>>> Cc: "engine-devel" >>>> Sent: Tuesday, November 12, 2013 6:40:18 AM >>>> Subject: Re: [Engine-devel] Weird behavior of multiple SetVmTicket query >>>> >>>> Forwarding this email to engine-devel so that backend maintainers are >>>> aware >>>> of this issue. >>>> >>>> Looking at the code: >>>> >>>> - MultipleActionsRunner#Execute first creates and "validates" all > commands: >>>> A. the "for" block which iterates over getParameters() >>>> >>>> 1-> validate correlation ID, if OK create and add command, >>>> otherwise >>>> add >>>> returnValue >>>> >>>> B the "if" block which tests getCommands().size() >>>> >>>> 1-> if single command to execute, add its "canDoActionOnly" >>>> returnValue, >>>> which is returnValue with canDoAction but without actual result >>>> object >>>> 2-> if multi commands to execute, execute chunks of max. 10 threads >>>> (sequentially, ThreadPoolUtil.invokeAll returns after all threads >>>> complete), same returnValue as above >>>> >>>> C. the "if" block which tests canRunActions >>>> >>>> 1-> all commands are executed within SINGLE THREAD due to >>>> ThreadPoolUtil.execute(Runnable), which is kind of weird comapred >>>> to >>>> how returnValues are prepared (see B2) >>>> 2-> when executing command, code DOES NOT CARE about its >>>> returnValue, >>>> i.e. returnValue was already prepared (see B) and command execution >>>> should just update it >>>> >>>> The problem (I think) is that C1 starts a different thread (to execute >>>> all >>>> commands) and immediately returns, i.e. code doesn't wait for thread to >>>> complete. This is why returnValues are observed on frontend as >>>> inconsistent. >>>> >>>> Additionally, we're also mixing of two different things: canDoAction >>>> processing and returnValues processing. IMHO this should be refactored >>>> to >>>> make code easier to read. >>>> >>>> Changes done by Alex (patch attached): >>>> >>>> X1. returnValues changed to Collections.synchronizedList >>>> >>>> -> this means all access to returnValues is now serial >>>> -> iteration over synchronizedList should also be enclosed in >>>> >>>> "synchronized (list)" block, so this: >>>> for (VdcReturnValueBase value : returnValues) ... >>>> >>>> should be this: >>>> synchronized (returnValues) { for (VdcReturnValueBase value : >>>> returnValues) ... } >>>> >>>> X2. commented-out original command execution via >>>> ThreadPoolUtil.execute(Runnable) >>>> >>>> -> new RunCommands method invokes all commands each in separate >>>> thread >>>> via ThreadPoolUtil.invokeAll >>>> -> returnValues list is explicitly updated >>>> >>>> Guys, what do you think? >>>> >>>> Vojtech >>>> >>>> >>>> ----- Original Message ----- >>>> >>>>> From: "Alexander Wels" >>>>> To: "Frantisek Kobzik" >>>>> Cc: "Vojtech Szocs" >>>>> Sent: Monday, November 11, 2013 9:19:08 PM >>>>> Subject: Re: Weird behavior of multiple SetVmTicket query >>>>> >>>>> Hi, >>>>> >>>>> I did some debugging, and the problem is a race condition in the >>>>> MultipleActions class. The whole class seems to have a lot of >>>>> multi-threading >>>>> issues but if I modify the code to wait for the results of the actions >>>>> to >>>>> return before returning the return value, everything works fine. >>>>> >>>>> I am attaching a patch that solves the issue at hand, but should not >>>>> be >>>>> considered a real patch. It is just to show the issue is in the >>>>> back-end >>>>> not >>>>> the front-end code. The front-end code is just exposing an issue in >>>>> the >>>>> back- >>>>> end >>>>> >>>>> Alexander >>>>> >>>>> On Monday, November 11, 2013 09:53:22 AM you wrote: >>>>>> Ok, thank you very much! >>>>>> >>>>>> ----- Original Message ----- >>>>>> From: "Alexander Wels" >>>>>> To: "Frantisek Kobzik" >>>>>> Sent: Monday, November 11, 2013 2:15:43 PM >>>>>> Subject: Re: Weird behavior of multiple SetVmTicket query >>>>>> >>>>>> Frantisek, >>>>>> >>>>>> I had seen this before, let me test and fix it for you, it is very >>>>>> likely >>>>>> my >>>>>> patch broke that. >>>>>> >>>>>> Alexander >>>>>> >>>>>> On Monday, November 11, 2013 03:43:19 AM you wrote: >>>>>>> Hi Alex, >>>>>>> >>>>>>> recently I noticed problems with invoking console for multiple VMs >>>>>>> (select >>>>>>> more VMs in webadmin and then hit the console btn). I was sure it >>>>>>> worked >>>>>>> in >>>>>>> past so i git-bisected the master branch and I discovered that >>>>>>> this >>>>>>> problem >>>>>>> is apparently caused by patch [1]. For single vm console >>>>>>> invocation >>>>>>> it >>>>>>> works fine, but for multiple VMs it doesn't. >>>>>>> >>>>>>> I did some closer investigation with a debugger and it seems that >>>>>>> getSucceeded() on the return val of SetVmTicket command returns >>>>>>> false >>>>>>> in >>>>>>> case of multiple execution despite the fact SetVmTicketCommand >>>>>>> sets >>>>>>> this >>>>>>> value to true. I suppose there is some problem with propagation of >>>>>>> command >>>>>>> return value from BE to FE. The same goes for the encapsulated >>>>>>> returnValue >>>>>>> attribute (it contains value of the generated ticket). When >>>>>>> invoking >>>>>>> multiple consoles it is null (although it has been filled on >>>>>>> backend). >>>>>>> Weird. >>>>>>> >>>>>>> Tomas told me you did some optimizations for multiple command >>>>>>> executions, >>>>>>> do you know it might cause it? Please let me know if you have any >>>>>>> idea... >>>>>>> >>>>>>> Cheers, >>>>>>> F. >>>>>>> >>>>>>> [1]: http://gerrit.ovirt.org/#/c/17356/ >>>> >>>> _______________________________________________ >>>> Engine-devel mailing list >>>> Engine-devel at ovirt.org >>>> http://lists.ovirt.org/mailman/listinfo/engine-devel >>> >>> _______________________________________________ >>> Engine-devel mailing list >>> Engine-devel at ovirt.org >>> http://lists.ovirt.org/mailman/listinfo/engine-devel >> >> _______________________________________________ >> Engine-devel mailing list >> Engine-devel at ovirt.org >> http://lists.ovirt.org/mailman/listinfo/engine-devel > > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > From awels at redhat.com Thu Nov 21 14:15:40 2013 From: awels at redhat.com (Alexander Wels) Date: Thu, 21 Nov 2013 09:15:40 -0500 Subject: [Engine-devel] Weird behavior of multiple SetVmTicket query In-Reply-To: <528E123E.2050706@redhat.com> References: <1405029090.20090071.1384159399724.JavaMail.root@redhat.com> <2843639.Zr1A8Fd6ET@awels> <528E123E.2050706@redhat.com> Message-ID: <2964430.ZczkeuaBWF@awels> On Thursday, November 21, 2013 04:01:34 PM Itamar Heim wrote: > On 11/21/2013 03:28 PM, Alexander Wels wrote: > > On Thursday, November 21, 2013 07:18:42 AM Daniel Erez wrote: > >> ----- Original Message ----- > >> > >>> From: "Einav Cohen" > >>> To: "Livnat Peer" , "Eli Mesika" , > >>> "Omer Frenkel" , "Doron Fediuck" > >>> , "Oved Ourfalli" Cc: > >>> "engine-devel" > >>> Sent: Monday, November 18, 2013 11:19:23 PM > >>> Subject: Re: [Engine-devel] Weird behavior of multiple SetVmTicket query > >>> > >>> engine-core maintainers - this one is mainly for you - see below. > >>> the most important question (I think) is: Is there any reason > >>> to not introduced a "sync" flavor of RunMultipleActions (i.e. > >>> one that will return from the backend only when all actions have > >>> been completed, similarly to RunAction)? > >> > >> There's a couple of years old patch exactly for that [1]. > >> It should allow both synchronous and asynchronous multiple actions > >> according to a flag. Question is when do we want to use the synchronous > >> flavor? The reasoning behind the current implementation is to return a > >> quick response to the client, as executing multiple vdsm commands can > >> potentially require a long wait. Do we need to introduce a sync version > >> just for VM console connection flow? IIRC, the flow actually uses > >> multiple calls to the singular form (RunAction) rather than > >> RunMultipleAction? > >> > >> [1] http://gerrit.ovirt.org/#/c/3210/ > > > > We recently introduced a patch [1] that on the front-end is smart enough > > to > > consolidate multiple query/actions into a single runMultiple(Query/Action) > > call to reduce the number http requests to the back-end. In the > > SetVMTicket > > case it combined two actions into one runMultipleAction call and was > > expected that to return once all the actions where complete, which didn't > > happen causing some undesired behavior on the client side. This sparked > > the investigation that ended in this email. > > > > So yes I would definitely like a 'synchronous' version of > > runMultipleAction so the frontend code can set that flag when combining > > multiple actions into a single call. We can only safely do this if we are > > combining several runActions as all of those are 'synchronous'. > > > > [1] http://gerrit.ovirt.org/#/c/17356/ > > btw, how is this going to work with the REST API? > I believe that is one of the outstanding issues with regards to the REST API transition. Before this optimization we already had code calling runMultiple(Query/Action) and we will have to figure something out for the REST API there as well. I think at the point we solve that issue we can decide if we want to keep the optimization or not. > >>> ---- > >>> Thanks, > >>> Einav > >>> > >>> ----- Original Message ----- > >>> > >>>> From: "Vojtech Szocs" > >>>> To: awels at redhat.com > >>>> Cc: "engine-devel" > >>>> Sent: Tuesday, November 12, 2013 6:40:18 AM > >>>> Subject: Re: [Engine-devel] Weird behavior of multiple SetVmTicket > >>>> query > >>>> > >>>> Forwarding this email to engine-devel so that backend maintainers are > >>>> aware > >>>> of this issue. > >>>> > >>>> Looking at the code: > >>>> > >>>> - MultipleActionsRunner#Execute first creates and "validates" all > > > > commands: > >>>> A. the "for" block which iterates over getParameters() > >>>> > >>>> 1-> validate correlation ID, if OK create and add command, > >>>> otherwise > >>>> add > >>>> returnValue > >>>> > >>>> B the "if" block which tests getCommands().size() > >>>> > >>>> 1-> if single command to execute, add its "canDoActionOnly" > >>>> returnValue, > >>>> which is returnValue with canDoAction but without actual result > >>>> object > >>>> 2-> if multi commands to execute, execute chunks of max. 10 > >>>> threads > >>>> (sequentially, ThreadPoolUtil.invokeAll returns after all threads > >>>> complete), same returnValue as above > >>>> > >>>> C. the "if" block which tests canRunActions > >>>> > >>>> 1-> all commands are executed within SINGLE THREAD due to > >>>> ThreadPoolUtil.execute(Runnable), which is kind of weird comapred > >>>> to > >>>> how returnValues are prepared (see B2) > >>>> 2-> when executing command, code DOES NOT CARE about its > >>>> returnValue, > >>>> i.e. returnValue was already prepared (see B) and command > >>>> execution > >>>> should just update it > >>>> > >>>> The problem (I think) is that C1 starts a different thread (to execute > >>>> all > >>>> commands) and immediately returns, i.e. code doesn't wait for thread to > >>>> complete. This is why returnValues are observed on frontend as > >>>> inconsistent. > >>>> > >>>> Additionally, we're also mixing of two different things: canDoAction > >>>> processing and returnValues processing. IMHO this should be refactored > >>>> to > >>>> make code easier to read. > >>>> > >>>> Changes done by Alex (patch attached): > >>>> > >>>> X1. returnValues changed to Collections.synchronizedList > >>>> > >>>> -> this means all access to returnValues is now serial > >>>> -> iteration over synchronizedList should also be enclosed in > >>>> > >>>> "synchronized (list)" block, so this: > >>>> for (VdcReturnValueBase value : returnValues) ... > >>>> > >>>> should be this: > >>>> synchronized (returnValues) { for (VdcReturnValueBase value > >>>> : > >>>> returnValues) ... } > >>>> > >>>> X2. commented-out original command execution via > >>>> ThreadPoolUtil.execute(Runnable) > >>>> > >>>> -> new RunCommands method invokes all commands each in separate > >>>> thread > >>>> via ThreadPoolUtil.invokeAll > >>>> -> returnValues list is explicitly updated > >>>> > >>>> Guys, what do you think? > >>>> > >>>> Vojtech > >>>> > >>>> > >>>> ----- Original Message ----- > >>>> > >>>>> From: "Alexander Wels" > >>>>> To: "Frantisek Kobzik" > >>>>> Cc: "Vojtech Szocs" > >>>>> Sent: Monday, November 11, 2013 9:19:08 PM > >>>>> Subject: Re: Weird behavior of multiple SetVmTicket query > >>>>> > >>>>> Hi, > >>>>> > >>>>> I did some debugging, and the problem is a race condition in the > >>>>> MultipleActions class. The whole class seems to have a lot of > >>>>> multi-threading > >>>>> issues but if I modify the code to wait for the results of the actions > >>>>> to > >>>>> return before returning the return value, everything works fine. > >>>>> > >>>>> I am attaching a patch that solves the issue at hand, but should not > >>>>> be > >>>>> considered a real patch. It is just to show the issue is in the > >>>>> back-end > >>>>> not > >>>>> the front-end code. The front-end code is just exposing an issue in > >>>>> the > >>>>> back- > >>>>> end > >>>>> > >>>>> Alexander > >>>>> > >>>>> On Monday, November 11, 2013 09:53:22 AM you wrote: > >>>>>> Ok, thank you very much! > >>>>>> > >>>>>> ----- Original Message ----- > >>>>>> From: "Alexander Wels" > >>>>>> To: "Frantisek Kobzik" > >>>>>> Sent: Monday, November 11, 2013 2:15:43 PM > >>>>>> Subject: Re: Weird behavior of multiple SetVmTicket query > >>>>>> > >>>>>> Frantisek, > >>>>>> > >>>>>> I had seen this before, let me test and fix it for you, it is very > >>>>>> likely > >>>>>> my > >>>>>> patch broke that. > >>>>>> > >>>>>> Alexander > >>>>>> > >>>>>> On Monday, November 11, 2013 03:43:19 AM you wrote: > >>>>>>> Hi Alex, > >>>>>>> > >>>>>>> recently I noticed problems with invoking console for multiple VMs > >>>>>>> (select > >>>>>>> more VMs in webadmin and then hit the console btn). I was sure it > >>>>>>> worked > >>>>>>> in > >>>>>>> past so i git-bisected the master branch and I discovered that > >>>>>>> this > >>>>>>> problem > >>>>>>> is apparently caused by patch [1]. For single vm console > >>>>>>> invocation > >>>>>>> it > >>>>>>> works fine, but for multiple VMs it doesn't. > >>>>>>> > >>>>>>> I did some closer investigation with a debugger and it seems that > >>>>>>> getSucceeded() on the return val of SetVmTicket command returns > >>>>>>> false > >>>>>>> in > >>>>>>> case of multiple execution despite the fact SetVmTicketCommand > >>>>>>> sets > >>>>>>> this > >>>>>>> value to true. I suppose there is some problem with propagation of > >>>>>>> command > >>>>>>> return value from BE to FE. The same goes for the encapsulated > >>>>>>> returnValue > >>>>>>> attribute (it contains value of the generated ticket). When > >>>>>>> invoking > >>>>>>> multiple consoles it is null (although it has been filled on > >>>>>>> backend). > >>>>>>> Weird. > >>>>>>> > >>>>>>> Tomas told me you did some optimizations for multiple command > >>>>>>> executions, > >>>>>>> do you know it might cause it? Please let me know if you have any > >>>>>>> idea... > >>>>>>> > >>>>>>> Cheers, > >>>>>>> F. > >>>>>>> > >>>>>>> [1]: http://gerrit.ovirt.org/#/c/17356/ > >>>> > >>>> _______________________________________________ > >>>> Engine-devel mailing list > >>>> Engine-devel at ovirt.org > >>>> http://lists.ovirt.org/mailman/listinfo/engine-devel > >>> > >>> _______________________________________________ > >>> Engine-devel mailing list > >>> Engine-devel at ovirt.org > >>> http://lists.ovirt.org/mailman/listinfo/engine-devel > >> > >> _______________________________________________ > >> Engine-devel mailing list > >> Engine-devel at ovirt.org > >> http://lists.ovirt.org/mailman/listinfo/engine-devel > > > > _______________________________________________ > > Engine-devel mailing list > > Engine-devel at ovirt.org > > http://lists.ovirt.org/mailman/listinfo/engine-devel From awels at redhat.com Thu Nov 21 14:19:44 2013 From: awels at redhat.com (Alexander Wels) Date: Thu, 21 Nov 2013 09:19:44 -0500 Subject: [Engine-devel] Problem building 3.3.1 branch In-Reply-To: <153892050.MIRmWBUgjf@awels> References: <528D394D.2080907@doolittle.us.com> <153892050.MIRmWBUgjf@awels> Message-ID: <5141037.BDNDarklUf@awels> On Wednesday, November 20, 2013 07:14:38 PM Alexander Wels wrote: > On Wednesday, November 20, 2013 07:08:39 PM Bob Doolittle wrote: > > Yes, it's pretty large. A little over 9k. > > > > -Bob > > Yes definitely a bug in the test, you can run the build without running the > unit tests and it should succeed, or temporarily have a /etc/hosts file <= > 4096 bytes. Looking at the test, I am not sure what I was thinking when I > did that, but I will rework it soon to not have such a crazy dependency. > I just pushed the fix to gerrit [1], hopefully it will be merged soon [1] http://gerrit.ovirt.org/#/c/21509/ > > On Nov 20, 2013 7:06 PM, "Alexander Wels" wrote: > > > On Wednesday, November 20, 2013 07:01:46 PM Bob Doolittle wrote: > > > > This is Fedora 19 > > > > > > > > On 11/20/2013 06:24 PM, Itamar Heim wrote: > > > > > On 11/21/2013 12:45 AM, Alon Bar-Lev wrote: > > > > >> ----- Original Message ----- > > > > >> > > > > >>> From: "Bob Doolittle" > > > > >>> To: engine-devel at ovirt.org > > > > >>> Sent: Thursday, November 21, 2013 12:35:57 AM > > > > >>> Subject: [Engine-devel] Problem building 3.3.1 branch > > > > >>> > > > > >>> Hi, > > > > >>> > > > > >>> I'm trying to build engine for the first time and running into a > > > > > > build > > > > > > > >>> error. I'm a seasoned Unix developer, but new to some aspects of > > > > > > Linux > > > > > > > >>> development like git and maven, so I could be doing something > > > > >>> naive. > > > > >>> > > > > >>> I'm following the instructions here: > > > > >>> http://www.ovirt.org/OVirt_Engine_Development_Environment > > > > >>> > > > > >>> I did a clone of the engine repository, and did "git checkout -b > > > > >>> myengine origin/ovirt-engine-3.3.1" to create my own branch based > > > > >>> on > > > > >>> 3.3.1 (current - I realize it's not quite done). > > > > >>> > > > > >>> Then, when I did "make install-dev PREFIX=$HOME/ovirt-engine" it > > > > > > failed > > > > > > > >>> when building the "Engine Web Root", specifically in the > > > > >>> FileServletTest. Relevant build log is here: > > > > >>> http://pastebin.com/JRcyWvtr > > > > >>> > > > > >>> Can anyone suggest what I've done wrong, or whether there's a > > > > >>> problem > > > > >>> with the repository at the moment? > > > > >> > > > > >> There may be indeed a problem, not happening at my setup, just > > > > >> tried. > > > > >> Can you please please send the relevant file from[1] > > > > >> I think it should be called something with FileServletTes. > > > > >> > > > > >> > > > > >> [1] > > > > > > /home/rad/workspace/ovirt-engine/backend/manager/modules/root/target/sur > > > e > > > > > > > >> fire-reports> > > > > > > > > > > also couldn't reproduced (tried just now). > > > > > anything special about the environment? > > > > > - cpu/ram configuration? > > > > > - not enough disk space? special file permissions? > > > > > - which OS is this on? which JRE? > > > > > > > > > > Thanks, > > > > > > > > > > Itamar > > > > > > > > This is Fedora 19 (updated) > > > > cpu i7-3520 > > > > mem 8GB > > > > Disk has over 26GB free for both volumes (SSD) > > > > I installed all the tools/prereqs as root. > > > > Did git clone as myself (no special permission) > > > > Running make as myself > > > > JRE 1.7.0_45 OpenJDK > > > > > > > > I have attached the requested file (not sure which you wanted, > > > > attached > > > > both likely candidates). > > > > > > > > I am running the make under my login shell, which is zsh. On occasion > > > > this has caused issues. If no better suggestions I'll double-check > > > > tomorrow by running under bash. > > > > > > > > Thanks for your assistance, > > > > > > > > Bob > > > > > > Bob, > > > > > > do you have an unusually large /etc/hosts file? looking at the error > > > somewhere > > > between 8192 and 12288 bytes? If so then it is a bug in the test, I will > > > update it in the morning. > > > > > > Alexander > > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel From iheim at redhat.com Thu Nov 21 14:25:49 2013 From: iheim at redhat.com (Itamar Heim) Date: Thu, 21 Nov 2013 16:25:49 +0200 Subject: [Engine-devel] Problem building 3.3.1 branch In-Reply-To: <5141037.BDNDarklUf@awels> References: <528D394D.2080907@doolittle.us.com> <153892050.MIRmWBUgjf@awels> <5141037.BDNDarklUf@awels> Message-ID: <528E17ED.2090904@redhat.com> On 11/21/2013 04:19 PM, Alexander Wels wrote: > On Wednesday, November 20, 2013 07:14:38 PM Alexander Wels wrote: >> On Wednesday, November 20, 2013 07:08:39 PM Bob Doolittle wrote: >>> Yes, it's pretty large. A little over 9k. >>> >>> -Bob >> >> Yes definitely a bug in the test, you can run the build without running the >> unit tests and it should succeed, or temporarily have a /etc/hosts file <= >> 4096 bytes. Looking at the test, I am not sure what I was thinking when I >> did that, but I will rework it soon to not have such a crazy dependency. >> > > I just pushed the fix to gerrit [1], hopefully it will be merged soon > > [1] http://gerrit.ovirt.org/#/c/21509/ that's for master. it should be backported to 3.3 stable later as well. but since 3.3.1 GA'd, not sure it makes sense to backport there (supposed to be a tag by now rather than a branch) Bob - for workaround, either just not run test, or just delete this unitest from the file (well, or trim/rename your /etc/hosts...) > >>> On Nov 20, 2013 7:06 PM, "Alexander Wels" wrote: >>>> On Wednesday, November 20, 2013 07:01:46 PM Bob Doolittle wrote: >>>>> This is Fedora 19 >>>>> >>>>> On 11/20/2013 06:24 PM, Itamar Heim wrote: >>>>>> On 11/21/2013 12:45 AM, Alon Bar-Lev wrote: >>>>>>> ----- Original Message ----- >>>>>>> >>>>>>>> From: "Bob Doolittle" >>>>>>>> To: engine-devel at ovirt.org >>>>>>>> Sent: Thursday, November 21, 2013 12:35:57 AM >>>>>>>> Subject: [Engine-devel] Problem building 3.3.1 branch >>>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>> I'm trying to build engine for the first time and running into a >>>> >>>> build >>>> >>>>>>>> error. I'm a seasoned Unix developer, but new to some aspects of >>>> >>>> Linux >>>> >>>>>>>> development like git and maven, so I could be doing something >>>>>>>> naive. >>>>>>>> >>>>>>>> I'm following the instructions here: >>>>>>>> http://www.ovirt.org/OVirt_Engine_Development_Environment >>>>>>>> >>>>>>>> I did a clone of the engine repository, and did "git checkout -b >>>>>>>> myengine origin/ovirt-engine-3.3.1" to create my own branch based >>>>>>>> on >>>>>>>> 3.3.1 (current - I realize it's not quite done). >>>>>>>> >>>>>>>> Then, when I did "make install-dev PREFIX=$HOME/ovirt-engine" it >>>> >>>> failed >>>> >>>>>>>> when building the "Engine Web Root", specifically in the >>>>>>>> FileServletTest. Relevant build log is here: >>>>>>>> http://pastebin.com/JRcyWvtr >>>>>>>> >>>>>>>> Can anyone suggest what I've done wrong, or whether there's a >>>>>>>> problem >>>>>>>> with the repository at the moment? >>>>>>> >>>>>>> There may be indeed a problem, not happening at my setup, just >>>>>>> tried. >>>>>>> Can you please please send the relevant file from[1] >>>>>>> I think it should be called something with FileServletTes. >>>>>>> >>>>>>> >>>>>>> [1] >>>> >>>> /home/rad/workspace/ovirt-engine/backend/manager/modules/root/target/sur >>>> e >>>> >>>>>>> fire-reports> >>>>>> >>>>>> also couldn't reproduced (tried just now). >>>>>> anything special about the environment? >>>>>> - cpu/ram configuration? >>>>>> - not enough disk space? special file permissions? >>>>>> - which OS is this on? which JRE? >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Itamar >>>>> >>>>> This is Fedora 19 (updated) >>>>> cpu i7-3520 >>>>> mem 8GB >>>>> Disk has over 26GB free for both volumes (SSD) >>>>> I installed all the tools/prereqs as root. >>>>> Did git clone as myself (no special permission) >>>>> Running make as myself >>>>> JRE 1.7.0_45 OpenJDK >>>>> >>>>> I have attached the requested file (not sure which you wanted, >>>>> attached >>>>> both likely candidates). >>>>> >>>>> I am running the make under my login shell, which is zsh. On occasion >>>>> this has caused issues. If no better suggestions I'll double-check >>>>> tomorrow by running under bash. >>>>> >>>>> Thanks for your assistance, >>>>> >>>>> Bob >>>> >>>> Bob, >>>> >>>> do you have an unusually large /etc/hosts file? looking at the error >>>> somewhere >>>> between 8192 and 12288 bytes? If so then it is a bug in the test, I will >>>> update it in the morning. >>>> >>>> Alexander >> >> _______________________________________________ >> Engine-devel mailing list >> Engine-devel at ovirt.org >> http://lists.ovirt.org/mailman/listinfo/engine-devel > > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > From bob at doolittle.us.com Thu Nov 21 15:27:44 2013 From: bob at doolittle.us.com (Bob Doolittle) Date: Thu, 21 Nov 2013 10:27:44 -0500 Subject: [Engine-devel] Problem building 3.3.1 branch In-Reply-To: <528E17ED.2090904@redhat.com> References: <528D394D.2080907@doolittle.us.com> <153892050.MIRmWBUgjf@awels> <5141037.BDNDarklUf@awels> <528E17ED.2090904@redhat.com> Message-ID: <528E2670.5070906@doolittle.us.com> On 11/21/2013 09:25 AM, Itamar Heim wrote: > On 11/21/2013 04:19 PM, Alexander Wels wrote: >> On Wednesday, November 20, 2013 07:14:38 PM Alexander Wels wrote: >>> On Wednesday, November 20, 2013 07:08:39 PM Bob Doolittle wrote: >>>> Yes, it's pretty large. A little over 9k. >>>> >>>> -Bob >>> >>> Yes definitely a bug in the test, you can run the build without >>> running the >>> unit tests and it should succeed, or temporarily have a /etc/hosts >>> file <= >>> 4096 bytes. Looking at the test, I am not sure what I was thinking >>> when I >>> did that, but I will rework it soon to not have such a crazy >>> dependency. >>> >> >> I just pushed the fix to gerrit [1], hopefully it will be merged soon >> >> [1] http://gerrit.ovirt.org/#/c/21509/ > > that's for master. it should be backported to 3.3 stable later as well. > but since 3.3.1 GA'd, not sure it makes sense to backport there > (supposed to be a tag by now rather than a branch) > Bob - for workaround, either just not run test, or just delete this > unitest from the file (well, or trim/rename your /etc/hosts...) Yes, I'm going to trim my /etc/hosts. Time for an fall cleaning anyway. Did 3.3.1 GA? I haven't seen it yet - thought it was held up on the sdk and cli. I assume there will be some announcement when it's ready. -Bob > > > >> >>>> On Nov 20, 2013 7:06 PM, "Alexander Wels" wrote: >>>>> On Wednesday, November 20, 2013 07:01:46 PM Bob Doolittle wrote: >>>>>> This is Fedora 19 >>>>>> >>>>>> On 11/20/2013 06:24 PM, Itamar Heim wrote: >>>>>>> On 11/21/2013 12:45 AM, Alon Bar-Lev wrote: >>>>>>>> ----- Original Message ----- >>>>>>>> >>>>>>>>> From: "Bob Doolittle" >>>>>>>>> To: engine-devel at ovirt.org >>>>>>>>> Sent: Thursday, November 21, 2013 12:35:57 AM >>>>>>>>> Subject: [Engine-devel] Problem building 3.3.1 branch >>>>>>>>> >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> I'm trying to build engine for the first time and running into a >>>>> >>>>> build >>>>> >>>>>>>>> error. I'm a seasoned Unix developer, but new to some aspects of >>>>> >>>>> Linux >>>>> >>>>>>>>> development like git and maven, so I could be doing something >>>>>>>>> naive. >>>>>>>>> >>>>>>>>> I'm following the instructions here: >>>>>>>>> http://www.ovirt.org/OVirt_Engine_Development_Environment >>>>>>>>> >>>>>>>>> I did a clone of the engine repository, and did "git checkout -b >>>>>>>>> myengine origin/ovirt-engine-3.3.1" to create my own branch based >>>>>>>>> on >>>>>>>>> 3.3.1 (current - I realize it's not quite done). >>>>>>>>> >>>>>>>>> Then, when I did "make install-dev PREFIX=$HOME/ovirt-engine" it >>>>> >>>>> failed >>>>> >>>>>>>>> when building the "Engine Web Root", specifically in the >>>>>>>>> FileServletTest. Relevant build log is here: >>>>>>>>> http://pastebin.com/JRcyWvtr >>>>>>>>> >>>>>>>>> Can anyone suggest what I've done wrong, or whether there's a >>>>>>>>> problem >>>>>>>>> with the repository at the moment? >>>>>>>> >>>>>>>> There may be indeed a problem, not happening at my setup, just >>>>>>>> tried. >>>>>>>> Can you please please send the relevant file from[1] >>>>>>>> I think it should be called something with FileServletTes. >>>>>>>> >>>>>>>> >>>>>>>> [1] >>>>> >>>>> /home/rad/workspace/ovirt-engine/backend/manager/modules/root/target/sur >>>>> >>>>> e >>>>> >>>>>>>> fire-reports> >>>>>>> >>>>>>> also couldn't reproduced (tried just now). >>>>>>> anything special about the environment? >>>>>>> - cpu/ram configuration? >>>>>>> - not enough disk space? special file permissions? >>>>>>> - which OS is this on? which JRE? >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> Itamar >>>>>> >>>>>> This is Fedora 19 (updated) >>>>>> cpu i7-3520 >>>>>> mem 8GB >>>>>> Disk has over 26GB free for both volumes (SSD) >>>>>> I installed all the tools/prereqs as root. >>>>>> Did git clone as myself (no special permission) >>>>>> Running make as myself >>>>>> JRE 1.7.0_45 OpenJDK >>>>>> >>>>>> I have attached the requested file (not sure which you wanted, >>>>>> attached >>>>>> both likely candidates). >>>>>> >>>>>> I am running the make under my login shell, which is zsh. On >>>>>> occasion >>>>>> this has caused issues. If no better suggestions I'll double-check >>>>>> tomorrow by running under bash. >>>>>> >>>>>> Thanks for your assistance, >>>>>> >>>>>> Bob >>>>> >>>>> Bob, >>>>> >>>>> do you have an unusually large /etc/hosts file? looking at the error >>>>> somewhere >>>>> between 8192 and 12288 bytes? If so then it is a bug in the test, >>>>> I will >>>>> update it in the morning. >>>>> >>>>> Alexander >>> >>> _______________________________________________ >>> Engine-devel mailing list >>> Engine-devel at ovirt.org >>> http://lists.ovirt.org/mailman/listinfo/engine-devel >> >> _______________________________________________ >> Engine-devel mailing list >> Engine-devel at ovirt.org >> http://lists.ovirt.org/mailman/listinfo/engine-devel >> > > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel From michal.skrivanek at redhat.com Thu Nov 21 16:22:35 2013 From: michal.skrivanek at redhat.com (Michal Skrivanek) Date: Thu, 21 Nov 2013 17:22:35 +0100 Subject: [Engine-devel] failed to add host into cluster In-Reply-To: <528DF261.1020407@redhat.com> References: <51FE642C.8040307@redhat.com> <1492863435.5066137.1375682766691.JavaMail.root@redhat.com> <51FF94AE.6030807@redhat.com> <307132015.5144883.1375706091754.JavaMail.root@redhat.com> <528DCD64.5010407@redhat.com> <528DE1F1.4090603@redhat.com> <528DE793.8060500@redhat.com> <528DE858.6080502@redhat.com> <528DEAE5.4030708@redhat.com> <528DF261.1020407@redhat.com> Message-ID: On Nov 21, 2013, at 12:45 , ouyang guohua wrote: > On 11/21/2013 07:23 PM, Michal Skrivanek wrote: >> On Nov 21, 2013, at 12:13 , ouyang guohua wrote: >> >>> On 11/21/2013 07:02 PM, Itamar Heim wrote: >>>> On 11/21/2013 12:59 PM, ouyang guohua wrote: >>>>> On 11/21/2013 06:35 PM, Itamar Heim wrote: >>>>>> On 11/21/2013 11:07 AM, ouyang guohua wrote: >>>>>>> Hi, >>>>>>> >>>>>>> I encounter the same problem today. >>>>>>> >>>>>>> Both the engine and the node are fedora 19. >>>>>>> >>>>>>> 1. on engine host: >>>>>>> engine=# select * from vdc_options where option_name ilike '%emu%'; >>>>>>> option_id | option_name | option_value | version >>>>>>> -----------+-------------------------+------------------+--------- >>>>>>> 38 | ClusterEmulatedMachines | rhel6.2.0,pc-1.0 | 3.0 >>>>>>> 39 | ClusterEmulatedMachines | rhel6.3.0,pc-1.0 | 3.1 >>>>>>> 40 | ClusterEmulatedMachines | rhel6.4.0,pc-1.0 | 3.2 >>>>>>> 41 | ClusterEmulatedMachines | rhel6.4.0,pc-1.0 | 3.3 >>>>>>> (4 rows) >>>>>>> >>>>>>> engine=# select name,emulated_machine from vds_groups; >>>>>>> name | emulated_machine >>>>>>> ---------------------+------------------ >>>>>>> Default | >>>>>>> fedora19-cluster | pc-1.0 >>>>>>> fedora19-node-Local | pc-1.0 >>>>>>> (3 rows) >>>>>>> >>>>>>> 2. on node: >>>>>>> # vdsClient -s 0 getVdsCaps >>>>>>> HBAInventory = {'iSCSI': [{'InitiatorName': >>>>>>> 'iqn.1994-05.com.redhat:643bb46781e'}], 'FC': []} >>>>>>> ISCSIInitiatorName = iqn.1994-05.com.redhat:643bb46781e >>>>>>> bondings = {'bond4': {'addr': '', 'cfg': {}, 'mtu': '1500', >>>>>>> 'netmask': '', 'slaves': [], 'hwaddr': '7e:00:7f:e7:90:4c'}, 'bond0': >>>>>>> {'addr': '', 'cfg': {}, 'mtu': '1500', 'netmask': '', 'slaves': [], >>>>>>> 'hwaddr': 'de:c5:12:4e:17:6f'}, 'bond1': {'addr': '', 'cfg': {}, >>>>>>> 'mtu': >>>>>>> '1500', 'netmask': '', 'slaves': [], 'hwaddr': '2e:ec:3b:01:ab:de'}, >>>>>>> 'bond2': {'addr': '', 'cfg': {}, 'mtu': '1500', 'netmask': '', >>>>>>> 'slaves': >>>>>>> [], 'hwaddr': 'da:88:61:cb:0d:ed'}, 'bond3': {'addr': '', 'cfg': {}, >>>>>>> 'mtu': '1500', 'netmask': '', 'slaves': [], 'hwaddr': >>>>>>> '72:c4:9e:9d:25:c1'}} >>>>>>> bridges = {'ovirtmgmt': {'addr': '10.66.10.186', 'cfg': >>>>>>> {'PEERROUTES': 'yes', 'IPV6INIT': 'yes', 'TYPE': 'Bridge', >>>>>>> 'IPV6_PEERDNS': 'yes', 'DEFROUTE': 'yes', 'ONBOOT': 'yes', 'PEERDNS': >>>>>>> 'yes', 'IPV4_FAILURE_FATAL': 'no', 'DELAY': '0', 'NM_CONTROLLED': >>>>>>> 'no', >>>>>>> 'BOOTPROTO': 'dhcp', 'DEVICE': 'ovirtmgmt', 'IPV6_FAILURE_FATAL': >>>>>>> 'no', >>>>>>> 'IPV6_PEERROUTES': 'yes', 'IPV6_DEFROUTE': 'yes', 'IPV6_AUTOCONF': >>>>>>> 'yes', 'UUID': '447b16c1-184a-4347-a801-ef8143c2d932'}, 'mtu': '1500', >>>>>>> 'netmask': '255.255.252.0', 'stp': 'off', 'ports': ['em1']}} >>>>>>> clusterLevels = ['3.0', '3.1', '3.2'] >>>>>>> cpuCores = 4 >>>>>>> cpuFlags = >>>>>>> fpu,vme,de,pse,tsc,msr,pae,mce,cx8,apic,sep,mtrr,pge,mca,cmov,pat,pse36,clflush,dts,acpi,mmx,fxsr,sse,sse2,ss,ht,tm,pbe,syscall,nx,lm,constant_tsc,arch_perfmon,pebs,bts,rep_good,nopl,aperfmperf,pni,dtes64,monitor,ds_cpl,vmx,smx,est,tm2,ssse3,cx16,xtpr,pdcm,sse4_1,xsave,lahf_lm,dtherm,tpr_shadow,vnmi,flexpriority,model_Conroe,model_coreduo,model_core2duo,model_Penryn,model_n270 >>>>>>> >>>>>>> >>>>>>> cpuModel = Intel(R) Core(TM)2 Quad CPU Q9400 @ 2.66GHz >>>>>>> cpuSockets = 1 >>>>>>> cpuSpeed = 2660.126 >>>>>>> cpuThreads = 4 >>>>>>> emulatedMachines = ['clipper', 'none'] >>>>>>> guestOverhead = 65 >>>>>>> hooks = {} >>>>>>> kvmEnabled = true >>>>>>> lastClient = 10.66.105.101 >>>>>>> lastClientIface = ovirtmgmt >>>>>>> management_ip = >>>>>>> memSize = 3888 >>>>>>> netConfigDirty = False >>>>>>> networks = {'ovirtmgmt': {'iface': 'ovirtmgmt', 'addr': >>>>>>> '10.66.10.186', 'cfg': {'PEERROUTES': 'yes', 'IPV6INIT': 'yes', >>>>>>> 'TYPE': >>>>>>> 'Bridge', 'IPV6_PEERDNS': 'yes', 'DEFROUTE': 'yes', 'ONBOOT': 'yes', >>>>>>> 'PEERDNS': 'yes', 'IPV4_FAILURE_FATAL': 'no', 'DELAY': '0', >>>>>>> 'NM_CONTROLLED': 'no', 'BOOTPROTO': 'dhcp', 'DEVICE': 'ovirtmgmt', >>>>>>> 'IPV6_FAILURE_FATAL': 'no', 'IPV6_PEERROUTES': 'yes', 'IPV6_DEFROUTE': >>>>>>> 'yes', 'IPV6_AUTOCONF': 'yes', 'UUID': >>>>>>> '447b16c1-184a-4347-a801-ef8143c2d932'}, 'mtu': '1500', 'netmask': >>>>>>> '255.255.252.0', 'stp': 'off', 'bridged': True, 'gateway': >>>>>>> '10.66.11.254', 'ports': ['em1']}} >>>>>>> nics = {'em1': {'addr': '', 'cfg': {'PEERROUTES': 'yes', >>>>>>> 'BRIDGE': >>>>>>> 'ovirtmgmt', 'DEVICE': 'em1', 'IPV6INIT': 'yes', 'IPV6_PEERDNS': >>>>>>> 'yes', >>>>>>> 'DEFROUTE': 'yes', 'ONBOOT': 'yes', 'PEERDNS': 'yes', >>>>>>> 'IPV4_FAILURE_FATAL': 'no', 'NM_CONTROLLED': 'no', 'IPV6_DEFROUTE': >>>>>>> 'yes', 'IPV6_AUTOCONF': 'yes', 'IPV6_FAILURE_FATAL': 'no', >>>>>>> 'IPV6_PEERROUTES': 'yes', 'HWADDR': '00:23:ae:9d:85:32', 'UUID': >>>>>>> '447b16c1-184a-4347-a801-ef8143c2d932'}, 'mtu': '1500', 'netmask': '', >>>>>>> 'hwaddr': '00:23:ae:9d:85:32', 'speed': 1000}} >>>>>>> operatingSystem = {'release': '4', 'version': '19', 'name': >>>>>>> 'Fedora'} >>>>>>> packages2 = {'kernel': {'release': '200.fc19.x86_64', >>>>>>> 'buildtime': >>>>>>> 1383545343.0, 'version': '3.11.7'}, 'spice-server': {'release': >>>>>>> '3.fc19', 'buildtime': 1383130020, 'version': '0.12.4'}, 'vdsm': >>>>>>> {'release': '18.fc19', 'buildtime': 1373484771, 'version': '4.10.3'}, >>>>>>> 'qemu-kvm': {'release': '13.fc19', 'buildtime': 1383700301, 'version': >>>>>>> '1.4.2'}, 'libvirt': {'release': '1.fc19', 'buildtime': 1383765188, >>>>>>> 'version': '1.0.5.7'}, 'qemu-img': {'release': '13.fc19', 'buildtime': >>>>>>> 1383700301, 'version': '1.4.2'}, 'mom': {'release': '1.fc19', >>>>>>> 'buildtime': 1373298035, 'version': '0.3.1'}} >>>>>>> reservedMem = 321 >>>>>>> software_revision = 18 >>>>>>> software_version = 4.10 >>>>>>> supportedENGINEs = ['3.0', '3.1'] >>>>>>> supportedProtocols = ['2.2', '2.3'] >>>>>>> uuid = 44454C4C-4C00-1031-8053-CAC04F4E3258 >>>>>>> version_name = Snow Man >>>>>>> vlans = {} >>>>>>> vmTypes = ['kvm'] >>>>>>> >>>>>>> 3. the vdsm.log is cutting to small size, if some useful logs isn't in >>>>>>> it, please ask me to re-send it. >>>>>>> >>>>>>> Thanks, >>>>>>> guohua >>>>>>> >>>>>>> On 08/06/2013 03:08 PM, Chen, Wei D wrote: >>>>>>>> The issue is solved by reinstalling host OS. >>>>>>>> >>>>>>>> Best Regards, >>>>>>>> Dave Chen >>>>>>>> >>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: Chen, Wei D >>>>>>>>> Sent: Tuesday, August 06, 2013 2:44 PM >>>>>>>>> To: 'Laszlo Hornyak'; Itamar Heim >>>>>>>>> Cc: Zhang, Lijuan;engine-devel at ovirt.org >>>>>>>>> Subject: RE: [Engine-devel] failed to add host into cluster >>>>>>>>> >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> >>>>>>>>> [root at onode vdsm]# vdsClient -s 0 getVdsCaps >>>>>>>>> HBAInventory = {'iSCSI': [{'InitiatorName': >>>>>>>>> 'iqn.1994-05.com.redhat:9fb571e343'}], 'FC': []} >>>>>>>>> ISCSIInitiatorName = iqn.1994-05.com.redhat:9fb571e343 >>>>>>>>> bondings = {'bond4': {'addr': '', 'cfg': {}, 'mtu': >>>>>>>>> '1500', 'netmask': '', 'slaves': [], 'hwaddr': '0e:00:b7:57:2c:c9'}, >>>>>>>>> 'bond0': {'addr': '', 'cfg': {}, 'mtu': '1500', 'netmask': '', >>>>>>>>> 'slaves': [], 'hwaddr': '32:b3:88:1f:ef:91'}, 'bond1': {'addr': '', >>>>>>>>> 'cfg': {}, 'mtu': '1500', 'netmask': '', 'slaves': [], 'hwaddr': >>>>>>>>> '4e:e5:80:93:ea:d9'}, 'bond2': {'addr': '', 'cfg': {}, 'mtu': >>>>>>>>> '1500', >>>>>>>>> 'netmask': '', 'slaves': [], 'hwaddr': '16:ab:f6:e4:f2:27'}, >>>>>>>>> 'bond3': {'addr': '', 'cfg': {}, 'mtu': '1500', 'netmask': '', >>>>>>>>> 'slaves': >>>>>>>>> [], 'hwaddr': 'ee:55:f5:e7:31:7c'}} >>>>>>>>> bridges = {'ovirtmgmt': {'addr': '10.239.131.217', 'cfg': >>>>>>>>> {'PEERROUTES': 'yes', 'DEVICE': 'ovirtmgmt', 'IPV6INIT': 'yes', >>>>>>>>> 'UUID': 'b6ecfa9d-0deb-4213-9348-11137f76735d', 'IPV6_PEERDNS': >>>>>>>>> 'yes', 'DEFROUTE': 'yes', 'PEERDNS': 'yes', 'IPV4_FAILURE_FATAL': >>>>>>>>> 'no', 'DELAY': '0', 'NM_CONTROLLED': 'no', 'IPV6_DEFROUTE': 'yes', >>>>>>>>> 'IPV6_AUTOCONF': 'yes', 'IPV6_FAILURE_FATAL': 'no', 'TYPE': >>>>>>>>> 'Bridge', 'ONBOOT': 'yes', 'BOOTPROTO': 'dhcp', 'IPV6_PEERROUTES': >>>>>>>>> 'yes'}, 'mtu': '1500', 'netmask': '255.255.255.0', 'stp': 'off', >>>>>>>>> 'ports': ['em1']}} >>>>>>>>> clusterLevels = ['3.0', '3.1', '3.2'] >>>>>>>>> cpuCores = 4 >>>>>>>>> cpuFlags = >>>>>>>>> fpu,vme,de,pse,tsc,msr,pae,mce,cx8,apic,sep,mtrr,pge,mca,cmov,pat,pse36,clflush,dts,acpi,mmx,fxsr,sse,sse2,ss,ht,tm,pbe,syscall,nx,r >>>>>>>>> >>>>>>>>> >>>>>>>>> dtscp,lm,constant_tsc,arch_perfmon,pebs,bts,rep_good,nopl,xtopology,nonstop_tsc,aperfmperf,eagerfpu,pni,pclmulqdq,dtes64,monitor, >>>>>>>>> >>>>>>>>> >>>>>>>>> ds_cpl,vmx,smx,est,tm2,ssse3,cx16,xtpr,pdcm,pcid,sse4_1,sse4_2,x2apic,popcnt,tsc_deadline_timer,aes,xsave,avx,lahf_lm,ida,arat,epb, >>>>>>>>> >>>>>>>>> >>>>>>>>> xsaveopt,pln,pts,dtherm,tpr_shadow,vnmi,flexpriority,ept,vpid,model_Nehalem,model_Conroe,model_coreduo,model_core2duo,model_P >>>>>>>>> >>>>>>>>> >>>>>>>>> enryn,model_Westmere,model_n270,model_SandyBridge >>>>>>>>> cpuModel = Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz >>>>>>>>> cpuSockets = 1 >>>>>>>>> cpuSpeed = 3672.000 >>>>>>>>> cpuThreads = 8 >>>>>>>>> emulatedMachines = ['clipper', 'none'] >>>>>>>>> guestOverhead = 65 >>>>>>>>> hooks = {} >>>>>>>>> kvmEnabled = true >>>>>>>>> lastClient = 10.239.131.222 >>>>>>>>> lastClientIface = ovirtmgmt >>>>>>>>> management_ip = >>>>>>>>> memSize = 7944 >>>>>>>>> netConfigDirty = False >>>>>>>>> networks = {'ovirtmgmt': {'iface': 'ovirtmgmt', 'addr': >>>>>>>>> '10.239.131.217', 'cfg': {'PEERROUTES': 'yes', 'DEVICE': >>>>>>>>> 'ovirtmgmt', >>>>>>>>> 'IPV6INIT': 'yes', 'UUID': 'b6ecfa9d-0deb-4213-9348-11137f76735d', >>>>>>>>> 'IPV6_PEERDNS': 'yes', 'DEFROUTE': 'yes', 'PEERDNS': 'yes', >>>>>>>>> 'IPV4_FAILURE_FATAL': 'no', 'DELAY': '0', 'NM_CONTROLLED': 'no', >>>>>>>>> 'IPV6_DEFROUTE': 'yes', 'IPV6_AUTOCONF': 'yes', >>>>>>>>> 'IPV6_FAILURE_FATAL': >>>>>>>>> 'no', 'TYPE': 'Bridge', 'ONBOOT': 'yes', 'BOOTPROTO': 'dhcp', >>>>>>>>> 'IPV6_PEERROUTES': 'yes'}, 'mtu': '1500', 'netmask': >>>>>>>>> '255.255.255.0', >>>>>>>>> 'stp': 'off', 'bridged': True, 'gateway': '10.239.131.1', 'ports': >>>>>>>>> ['em1']}} >>>>>>>>> nics = {'em1': {'addr': '', 'cfg': {}, 'mtu': '1500', >>>>>>>>> 'netmask': '', 'hwaddr': '2c:41:38:b2:d0:e8', 'speed': 100}} >>>>>>>>> operatingSystem = {'release': '0.5', 'version': '19', >>>>>>>>> 'name': 'Fedora'} >>>>>>>>> packages2 = {'kernel': {'release': '301.fc19.x86_64', >>>>>>>>> 'buildtime': 1368462984.0, 'version': '3.9.2'}, 'spice-server': >>>>>>>>> {'release': '5.fc19', 'buildtime': 1366036951, 'version': >>>>>>>>> '0.12.2'}, 'vdsm': {'release': '18.fc19', 'buildtime': 1373484771, >>>>>>>>> 'version': '4.10.3'}, 'qemu-kvm': {'release': '4.fc19', >>>>>>>>> 'buildtime': 1371653911, 'version': '1.4.2'}, 'libvirt': {'release': >>>>>>>>> '1.fc19', >>>>>>>>> 'buildtime': 1371074681, 'version': '1.0.5.2'}, 'qemu-img': >>>>>>>>> {'release': '4.fc19', 'buildtime': 1371653911, 'version': '1.4.2'}, >>>>>>>>> 'mom': >>>>>>>>> {'release': '2.fc19', 'buildtime': 1374564325, 'version': '0.3.2'}} >>>>>>>>> reservedMem = 321 >>>>>>>>> software_revision = 18 >>>>>>>>> software_version = 4.10 >>>>>>>>> supportedENGINEs = ['3.0', '3.1'] >>>>>>>>> supportedProtocols = ['2.2', '2.3'] >>>>>>>>> uuid = 30BBC800-4F47-11E0-0000-2C4138B2D0E8 >>>>>>>>> version_name = Snow Man >>>>>>>>> vlans = {} >>>>>>>>> vmTypes = ['kvm'] >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Best Regards, >>>>>>>>> Dave Chen >>>>>>>>> >>>>>>>>> >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: Laszlo Hornyak [mailto:lhornyak at redhat.com] >>>>>>>>>> Sent: Monday, August 05, 2013 8:35 PM >>>>>>>>>> To: Itamar Heim >>>>>>>>>> Cc: Chen, Wei D; Zhang, Lijuan;engine-devel at ovirt.org >>>>>>>>>> Subject: Re: [Engine-devel] failed to add host into cluster >>>>>>>>>> >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> Dave, could you also share the vdsm log as well? >>>>>>>>>> >>>>>>>>>> I managed to reproduce this on the host that I am using for years >>>>>>>>>> and I am using it now, so it should not be a hardware problem. >>>>>>>>>> Probably >>>>>>>>>> some broken configuration caused some problem in vdsm before it >>>>>>>>>> would retrieve the capabilities information from libvirt. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> ----- Original Message ----- >>>>>>>>>>> From: "Itamar Heim" >>>>>>>>>>> To: "Laszlo Hornyak" >>>>>>>>>>> Cc: "Wei D Chen", "Lijuan Zhang" >>>>>>>>>>> ,engine-devel at ovirt.org >>>>>>>>>>> Sent: Monday, August 5, 2013 2:03:58 PM >>>>>>>>>>> Subject: Re: [Engine-devel] failed to add host into cluster >>>>>>>>>>> >>>>>>>>>>> On 08/05/2013 09:06 AM, Laszlo Hornyak wrote: >>>>>>>>>>>> ----- Original Message ----- >>>>>>>>>>>>> From: "Wei D Chen" >>>>>>>>>>>>> To: "Itamar Heim" >>>>>>>>>>>>> Cc: "Lijuan >>>>>>>>>>>>> Zhang",engine-devel at ovirt.org >>>>>>>>>>>>> Sent: Monday, August 5, 2013 8:03:08 AM >>>>>>>>>>>>> Subject: Re: [Engine-devel] failed to add host into cluster >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Best Regards, >>>>>>>>>>>>> Dave Chen >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>>> From: Itamar Heim [mailto:iheim at redhat.com] >>>>>>>>>>>>>> Sent: Sunday, August 04, 2013 10:25 PM >>>>>>>>>>>>>> To: Chen, Wei D >>>>>>>>>>>>>> Cc:engine-devel at ovirt.org; Zhang, Lijuan >>>>>>>>>>>>>> Subject: Re: [Engine-devel] failed to add host into cluster >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 08/02/2013 09:34 AM, Chen, Wei D wrote: >>>>>>>>>>>>>>> Failed to add a node into cluster. I saw follow hints, but >>>>>>>>>>>>>>> still >>>>>>>>>>>>>>> don't know how to fix it. OS is fedora 19 both for node and >>>>>>>>>>>>>>> engine, anyone can help me? >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Host *** does not comply with the cluster *** emulated >>>>>>>>>>>>>>> machines. >>>>>>>>>>>>>>> The Hosts emulated machines are clipper,none and the >>>>>>>>>>>>>>> cluster is >>>>>>>>>>>>>>> [rhel6.4.0, pc-1.0]} >>>>>>>>>>>>>> what Os is the host running? >>>>>>>>>>>>> fedora 19 >>>>>>>>>>>>>> what does 'vdsClient -s 0 getVdsCaps' returns? >>>>>>>>>>>>> where to run this command? this command is not recognized >>>>>>>>>>>>> both in >>>>>>>>>>>>> engine and node. >>>>>>>>>>>> After installing the host, you should have this command in the >>>>>>>>>>>> host OS. >>>>>>>>>>>> >>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>> Engine-devel mailing list >>>>>>>>>>>>> Engine-devel at ovirt.org >>>>>>>>>>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel >>>>>>>>>>>>> >>>>>>>>>>> cat /proc/cpuinfo >>>>>>>>>>> and >>>>>>>>>>> virsh capabilities >>>>>>>>>>> >>>>>>>>>>> are also interesting >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> Engine-devel mailing list >>>>>>>>>>> Engine-devel at ovirt.org >>>>>>>>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Engine-devel mailing list >>>>>>> Engine-devel at ovirt.org >>>>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel >>>>>>> >>>>>> your qemu only reports "clipper" as the support emulated machine? >>>>> Yes, it is. Same to Chenwei's results. >>>>> Could the problem be solved without re-install the os? >>>>> >>>>> >>>>> >>>> what does this command returns: >>>> $ qemu-kvm -M ? >>>> >>> # qemu-kvm -M ? >>> Supported machines are: >>> none empty machine >>> pc Standard PC (i440FX + PIIX, 1996) (alias of >>> pc-i440fx-1.4) >>> pc-i440fx-1.4 Standard PC (i440FX + PIIX, 1996) (default) >>> pc-1.3 Standard PC >>> pc-1.2 Standard PC >>> pc-1.1 Standard PC >>> pc-1.0 Standard PC >>> pc-0.15 Standard PC >>> pc-0.14 Standard PC >>> pc-0.13 Standard PC >>> pc-0.12 Standard PC >>> pc-0.11 Standard PC, qemu 0.11 >>> pc-0.10 Standard PC, qemu 0.10 >>> isapc ISA-only PC >>> q35 Standard PC (Q35 + ICH9, 2009) (alias of pc-q35-1.4) >>> pc-q35-1.4 Standard PC (Q35 + ICH9, 2009) >> ok, that looks ok. Might be text parsing issue. >> And "virsh capabilities" output? >> what's the vdsm you're using? > > virsh capabilities" output is a bit long, see attachment > > # rpm -q vdsm > vdsm-4.10.3-18.fc19.x86_64 hmm, works well on my box try master, though this code didn't change since 2012 the code in vdsm/caps.py is pretty straightforward: caps = minidom.parseString(capabilities) for archTag in caps.getElementsByTagName('arch'): if archTag.getAttribute('name') == 'x86_64': return [m.firstChild.data for m in archTag.childNodes if m.nodeName == 'machine'] try to uninstall qemu Alpha support if it changes a thing or not... > >> >> Thanks, >> michal >>> _______________________________________________ >>> Engine-devel mailing list >>> Engine-devel at ovirt.org >>> http://lists.ovirt.org/mailman/listinfo/engine-devel > > From bazulay at redhat.com Thu Nov 21 17:39:21 2013 From: bazulay at redhat.com (Barak Azulay) Date: Thu, 21 Nov 2013 12:39:21 -0500 (EST) Subject: [Engine-devel] Fwd: Custom properties per device + vNIC profile = not working (< 3.3) In-Reply-To: <1891919433.37518165.1384933305628.JavaMail.root@redhat.com> References: <1480148973.29121435.1384156173916.JavaMail.root@redhat.com> <2080457776.29191617.1384163320455.JavaMail.root@redhat.com> <5280CE6E.1060608@redhat.com> <42910126.37500034.1384931222012.JavaMail.root@redhat.com> <528C63A1.8020306@redhat.com> <1645947092.37516409.1384932664338.JavaMail.root@redhat.com> <528C657E.3040908@redhat.com> <1891919433.37518165.1384933305628.JavaMail.root@redhat.com> Message-ID: <1795322697.12094958.1385055561524.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Mike Kolesnik" > To: "Itamar Heim" > Cc: engine-devel at ovirt.org > Sent: Wednesday, November 20, 2013 9:41:45 AM > Subject: Re: [Engine-devel] Fwd: Custom properties per device + vNIC profile = not working (< 3.3) > > ----- Original Message ----- > > On 11/20/2013 09:31 AM, Mike Kolesnik wrote: > > > > > > ----- Original Message ----- > > >> On 11/20/2013 09:07 AM, Mike Kolesnik wrote: > > >>> ----- Original Message ----- > > >>>> On 11/11/2013 11:48 AM, Mike Kolesnik wrote: > > >>>>> > > >>>>> ----- Original Message ----- > > >>>>>> Hi Mike, > > >>>>>> > > >>>>>> ----- Original Message ----- > > >>>>>>> From: "Mike Kolesnik" > > >>>>>>> To: "engine-devel" > > >>>>>>> Cc: "Barak Azulay" , "Martin Perina" > > >>>>>>> , "Livnat Peer" , > > >>>>>>> "Itamar Heim" > > >>>>>>> Sent: Monday, November 11, 2013 8:49:33 AM > > >>>>>>> Subject: Custom properties per device + vNIC profile = not working > > >>>>>>> (< > > >>>>>>> 3.3) > > >>>>>>> > > >>>>>>> Hi, > > >>>>>>> > > >>>>>>> I came across a situation where I wanted to define custom > > >>>>>>> properties > > >>>>>>> on > > >>>>>>> a > > >>>>>>> vNIC profile sitting under a network in a 3.2 data center. > > >>>>>>> From what I saw the configuration value for custom properties > > >>>>>>> (CustomDeviceProperties) is split into 4, one per each version > > >>>>>>> (3.0, > > >>>>>>> 3.1, > > >>>>>>> 3.2, 3.3). > > >>>>>>> Since vNIC profile is located under the DC tree, it takes the DC > > >>>>>>> version > > >>>>>>> - > > >>>>>>> 3.2 in this specific case. > > >>>>>> > > >>>>>> Custom Device Properties were designed to be specified for each > > >>>>>> cluster > > >>>>>> version > > >>>>>> independently, it doesn't care about DC version. AFAIK cluster > > >>>>>> version > > >>>>>> defines > > >>>>>> what features are available ... > > >>>>>> > > >>>>>>> > > >>>>>>> I tried to set the config value for 3.2 but got: > > >>>>>>> $ engine-config -s > > >>>>>>> CustomDeviceProperties="{type=interface;prop={myProp=[a-zA-Z0-9-]+}}" > > >>>>>>> --cver=3.2 > > >>>>>>> Cannot set value {type=interface;prop={myProp=[a-zA-Z0-9-]+}} to > > >>>>>>> key > > >>>>>>> CustomDeviceProperties. Device custom properties are not supported > > >>>>>>> in > > >>>>>>> version 3.2 > > >>>>>>> > > >>>>>>> This is already not very good, since in a 3.2 DC there can be 3.3 > > >>>>>>> clusters > > >>>>>>> with 3.3 hosts that do support custom device properties. > > >>>>>> > > >>>>>> Specify your properties for 3.3 version, since they will be used in > > >>>>>> 3.3 > > >>>>>> clusters ... > > >>>>>> > > >>>>> > > >>>>> But the effective version is the DC version as I explained. > > >>>>> > > >>>>> In a DC 3.0-3.3 I can have clusters which the minimal version is the > > >>>>> DC > > >>>>> version, and the maximal version is 3.3. > > >>>>> For example I can have the following: > > >>>>> DC - version 3.0 > > >>>>> + Cluster 1 - version 3.0 > > >>>>> + Cluster 2 - version 3.1 > > >>>>> + Cluster 3 - version 3.2 > > >>>>> + Cluster 4 - version 3.3 > > >>>>> > > >>>>> In this constellation, I could use custom device properties only on > > >>>>> Cluster > > >>>>> 4, but it's not possible to define them since the vNIC profile is > > >>>>> using > > >>>>> the DC version 3.0. > > >>>>> So effectively this feature is not usable to me unless I use a 3.3 > > >>>>> DC. > > >>>>> > > >>>>>>> > > >>>>>>> I also tried to alter the config value in the DB directly, but the > > >>>>>>> custom > > >>>>>>> properties code ignored it since custom properties are not > > >>>>>>> supported > > >>>>>>> in > > >>>>>>> 3.2. > > >>>>>>> So, de facto, I have no reasonable way as a user to define custom > > >>>>>>> device > > >>>>>>> properties to use for my vNIC profiles in DC < 3.3. > > >>>>>> > > >>>>>> There are two configuration properties for Custom Device > > >>>>>> Properties: > > >>>>>> > > >>>>>> 1) SupportCustomDeviceProperties > > >>>>>> - defines in what version properties are supported > > >>>>>> - cannot be altered by users of course > > >>>>>> > > >>>>>> 2) CustomDeviceProperties > > >>>>>> - holds properties specification for each version > > >>>>>> - can be defined using engine-config > > >>>>>> > > >>>>>>> > > >>>>>>> I opened the bug > > >>>>>>> https://bugzilla.redhat.com/show_bug.cgi?id=1028757 > > >>>>>>> for > > >>>>>>> this, however I also want to discuss the situation: > > >>>>>> > > >>>>>> I looked at the bug and the problem is, that management network > > >>>>>> profile > > >>>>>> is bound to DC and not the Cluster. And that's something we never > > >>>>>> thought > > >>>>>> of > > >>>>>> ... > > >>>>>> > > >>>>>>> > > >>>>>>> 1. As a user, I can't set custom properties for level < 3.3 which > > >>>>>>> is > > >>>>>>> not > > >>>>>>> good. > > >>>>>> > > >>>>>> Well, it's 3.3 feature, so it looks OK for me > > >>>>>> > > >>>>>>> Removing the blocking, and loading custom properties for all > > >>>>>>> versions > > >>>>>>> would > > >>>>>>> fix the bug and allow using custom device properties for older > > >>>>>>> versions, > > >>>>>>> the > > >>>>>>> reasonable place to block this would be running a VM (or plugging a > > >>>>>>> device). > > >>>>>>> Basically this is the lesser issue.. > > >>>>>>> > > >>>>>>> 2. I just don't see the added value of splitting the definition of > > >>>>>>> the > > >>>>>>> properties per level.. > > >>>>>> > > >>>>>> The idea behind the version splitting was: > > >>>>>> > > >>>>>> 1) We have a device with a feature that doesn't work correctly with > > >>>>>> version > > >>>>>> 3.3, > > >>>>>> but it's fixed in 3.4 > > >>>>>> 2) By specifying custom property per version we cane disable this > > >>>>>> feature > > >>>>>> for > > >>>>>> 3.3 > > >>>>>> and enable for 3.4 > > >>>>> > > >>>>> Custom properties is not for specifying which features are enabled, > > >>>>> there > > >>>>> is a whole other mechanism for that.. > > >>>>> > > >>>>> Custom properties is for hooks (and other possible extensions), which > > >>>>> by > > >>>>> definition are not something that is guaranteed to exist so I see no > > >>>>> point > > >>>>> to force the user to update multiple configurations and cause > > >>>>> confusion > > >>>>> for him.. > > >>>> > > >>>> as martin explained, we have predefined custom properties, which are > > >>>> based on the vdsm version, and hence are actually features we know to > > >>>> expose or not to expose. > > >>>> user-defined custom properties - are up to the admin, but we let these > > >>>> be at cluster level as well to allow more granularity. > > >>> > > >>> There are no predefined properties here, only user defined properties. > > >>> > > >>>> > > >>>>> > > >>>>>> > > >>>>>>> The custom properties are extensions which might or might not be > > >>>>>>> available > > >>>>>>> to > > >>>>>>> a certain VM, I don't see how having different sets of custom > > >>>>>>> properties > > >>>>>>> per > > >>>>>>> version (what version, DC version, cluster version?) would make any > > >>>>>>> difference - either the VM can utilize the extension given some > > >>>>>>> state > > >>>>>>> of > > >>>>>>> the > > >>>>>>> system, or it can't, but the determining factor is not the version > > >>>>>>> but > > >>>>>>> rather the availability of the extension. > > >>>>>>> For example, I can have a hook for vNIC altering some property > > >>>>>>> installed > > >>>>>>> on > > >>>>>>> host A and not host B, if the VM runs on host A it will get this > > >>>>>>> capability > > >>>>>>> and on host B it won't, regardless the DC version the VM is in. > > >>>>>>> > > >>>>>>> This is not to say we shouldn't block custom properties on the > > >>>>>>> engine-VDSM > > >>>>>>> API level since it's only available since 3.3, but this is handled > > >>>>>>> by > > >>>>>>> another config value (SupportCustomDeviceProperties) which is not > > >>>>>>> alterable > > >>>>>>> by the user. > > >>>>>>> So basically, I think splitting the value per version is over > > >>>>>>> complication > > >>>>>>> and see no added value to the users, just more maintenance should > > >>>>>>> they > > >>>>>>> choose to use this feature. > > >>>>>>> > > >>>>>>> Your thoughts please. > > >>>>>> > > >>>>>> AFAIK only network and storage team wanted to use device custom > > >>>>>> properties > > >>>>>> in 3.3 version, but I'm not sure what's current usage status. > > >>>>>> > > >>>>>> But IMHO it's too late for 3.3 to change specification ... > > >>>>> > > >>>>> Since I can have cluster 3.3 in a DC < 3.3, and this is the upgrade > > >>>>> path > > >>>>> for existing users, > > >>>>> I'd argue that the bug is severe enough and should be fixed asap even > > >>>>> for > > >>>>> 3.3 versions. > > >>>> > > >>>> please note that if you expose this at cluster level and not DC level, > > >>>> you need to make sure to verify it when moving a VM between clusters > > >>>> in > > >>>> same DC. > > >>>> also, if this is somehow related to logical networks, not vnic > > >>>> specific, > > >>>> than logical networks are DC level entities. > > >>>> > > >>>> > > >>> > > >>> OK but my point was that a custom properties is not meant to be split > > >>> by > > >>> versions since > > >>> by definition of it, a hook might or might not exist on a given host > > >>> (regardless of the host version). > > >>> It only imposes more strain on the user to define possible custom > > >>> properties by version.. > > >>> > > >>> I see no value to users in this approach, only more work and > > >>> unclearness.. > > >>> > > >>> Mind you, hook is not a "feature" that is explicitly supported on a > > >>> given > > >>> version, but an extension > > >>> mechanism which can have 3rd party extensions that might or might not > > >>> exist > > >>> on a given host, but this > > >>> won't stop an action from occurring (i.e. VM would still start if a > > >>> hook > > >>> is > > >>> missing but some custom > > >>> property was sent). > > >>> > > >>> Also the original bug still exists because even though the vNIC is > > >>> sitting > > >>> at VM which is in cluster > > >>> (thus in effect having access to the cluster version), the profile sits > > >>> under network (which, as you > > >>> mention, is DC level entity). > > >>> So for the user using a DC < 3.3 there is no option to use this feature > > >>> even though he can have 3.3 > > >>> clusters in his DC. > > >>> > > >> > > >> except some hooks are shipped as required, and some custom properties > > >> are supported by vdsm even without hooks. > > >> so allowing to specify they are 'there' for a specific vdsm version is > > >> useful. > > >> > > > > > > Seems to me you're referring to things that should be in a predefined > > > properties > > > list, which as I mentioned doesn't exist for this feature. > > > > > > > 1. maybe it should. > > 2. still, i think the granularity isn't hurting in this case - more > > likely a hook will be needed, or not needed, in specific compat versions > > as features are added/removed from the product, even for custom hooks. > > > > Since it's not possible for me to predict the future, I'd argue that > simplicity is the best > way to begin with, and if there is such demand in the future then we can > always change the > code to handle the more complicated use cases. > > IMHO, since currently there is no usage of this feature except vNIC profiles > which is half > usable due to the limitations imposed, seems fair to me to go with a simple > value which is > version agnostic and let the admin try this feature out. > > If we get requests to make this more specific then a proper design, > accommodating the specific > requirements that will be raised, can be thought of and implemented. The > current design doesn't > fit the single use case for this feature that we have. I understand your point on this option could have been used on different DC levels as well (as long as the clluster level is still 3.3), but I don't see a real reason at this point to move away from the assumption of new features exist only in the new DC level introduced by the version. Thanks Barak > > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > From vszocs at redhat.com Thu Nov 21 21:18:17 2013 From: vszocs at redhat.com (Vojtech Szocs) Date: Thu, 21 Nov 2013 16:18:17 -0500 (EST) Subject: [Engine-devel] Using REST API in web UI - review call summary In-Reply-To: <1381346638.28793358.1385065334745.JavaMail.root@redhat.com> Message-ID: <1515483885.28819526.1385068697947.JavaMail.root@redhat.com> Hi guys, this is a summary of yesterday's review call, I'll try to highlight important Q/A and things we agreed on. Feel free to add anything in case I've missed something. -- Q: Why don't we simply try to use existing Java SDK and adapt it for GWT apps? (asked by Michael & Gilad) A: This might be a viable option to consider if we wanted to skip JavaScript-based SDK altogether and target Java/GWT code directly; we could simply take Java SDK and customize its abstractions where necessary, i.e. using HTTP transport layer implementation that works with GWT. In any case, this would mean coupling ourselves to Java SDK (which has its own release cycle) and I think this would complicate things for us. As proposed on the meeting, I think it's best to aim for JavaScript SDK as the lowest common denominator for *any* web application that wants to work with REST API. oVirt GWT-based UI can simply bind to JavaScript SDK, i.e. Java/GWT code that just overlays objects and functions provided by JavaScript SDK. Another reason is ease of maintenance - I'd rather see JavaScript SDK's code generation process to be independent of any other SDK (people responsible for maintaining JavaScript SDK should have full control over generated code). -- Q: What about functionality currently used by oVirt UI but not supported by REST API? (asked by Einav) [For example, fetching VM entity over GWT RPC also returns related data such as Cluster name.] A: Based on discussion I've had with other colleagues after yesterday's review call, I don't think that separate support-like backend layer is a good idea. Instead, this is the kind of functionality that could be placed in oVirt.js library. Logical operations like "get VMs and related data" would be exposed through oVirt.js (callback-based) API and ultimately realized as multiple physical requests to REST API via JavaScript Binding. oVirt.js client would be completely oblivious to the fact that multiple physical requests are dispatched. In fact, since HTTP communication is asynchronous in nature, oVirt.js client wouldn't even notice any difference in terms of API consumption. This assumes JavaScript SDK would use callback-based (non-blocking) API instead of blocking one - after all, blocking API on top of non-blocking implementation sounds pretty much like leaky abstraction [1]. For example: sdk.getVmsWithExtraData( callbackToGetExtraDataForGivenVm, // might cause extra physical requests to REST API callbackFiredWhenAllDataIsReady // update client only when all data is ready ) [1] http://en.wikipedia.org/wiki/Leaky_abstraction -- Last but not least, where to maintain JavaScript SDK projects: low-level JavaScript Binding + high-level oVirt.js library. I agree that conceptually both above mentioned projects should go into dedicated "ovirt-engine-sdk-js" git repository and have their own build/release process. However, for now, we're just making baby steps so let's keep things simple and prototype these projects as part of "ovirt-engine" git repository. ... we can complicate things anytime, but we should know that any complex system that works has inevitably evolved from simple system that works ... (quote from http://en.wikipedia.org/wiki/Gall%27s_law) Regards, Vojtech From iheim at redhat.com Thu Nov 21 21:25:04 2013 From: iheim at redhat.com (Itamar Heim) Date: Thu, 21 Nov 2013 23:25:04 +0200 Subject: [Engine-devel] Using REST API in web UI - review call summary In-Reply-To: <1515483885.28819526.1385068697947.JavaMail.root@redhat.com> References: <1515483885.28819526.1385068697947.JavaMail.root@redhat.com> Message-ID: <528E7A30.7040503@redhat.com> On 11/21/2013 11:18 PM, Vojtech Szocs wrote: > Hi guys, > > this is a summary of yesterday's review call, I'll try to highlight important Q/A and things we agreed on. Feel free to add anything in case I've missed something. > > -- > > Q: Why don't we simply try to use existing Java SDK and adapt it for GWT apps? (asked by Michael & Gilad) > > A: This might be a viable option to consider if we wanted to skip JavaScript-based SDK altogether and target Java/GWT code directly; we could simply take Java SDK and customize its abstractions where necessary, i.e. using HTTP transport layer implementation that works with GWT. In any case, this would mean coupling ourselves to Java SDK (which has its own release cycle) and I think this would complicate things for us. > > As proposed on the meeting, I think it's best to aim for JavaScript SDK as the lowest common denominator for *any* web application that wants to work with REST API. oVirt GWT-based UI can simply bind to JavaScript SDK, i.e. Java/GWT code that just overlays objects and functions provided by JavaScript SDK. Another reason is ease of maintenance - I'd rather see JavaScript SDK's code generation process to be independent of any other SDK (people responsible for maintaining JavaScript SDK should have full control over generated code). > > -- > > Q: What about functionality currently used by oVirt UI but not supported by REST API? (asked by Einav) > [For example, fetching VM entity over GWT RPC also returns related data such as Cluster name.] > > A: Based on discussion I've had with other colleagues after yesterday's review call, I don't think that separate support-like backend layer is a good idea. Instead, this is the kind of functionality that could be placed in oVirt.js library. Logical operations like "get VMs and related data" would be exposed through oVirt.js (callback-based) API and ultimately realized as multiple physical requests to REST API via JavaScript Binding. > > oVirt.js client would be completely oblivious to the fact that multiple physical requests are dispatched. In fact, since HTTP communication is asynchronous in nature, oVirt.js client wouldn't even notice any difference in terms of API consumption. This assumes JavaScript SDK would use callback-based (non-blocking) API instead of blocking one - after all, blocking API on top of non-blocking implementation sounds pretty much like leaky abstraction [1]. > > For example: > > sdk.getVmsWithExtraData( > callbackToGetExtraDataForGivenVm, // might cause extra physical requests to REST API > callbackFiredWhenAllDataIsReady // update client only when all data is ready > ) would this also resolve RunMultipleActions? sounds like no reason to have RunMultipleQueries, although i'm still sure a single call to engine for multiple keys would be much more efficient than multiple async calls? (I understand we may not be able to model this). > > [1] http://en.wikipedia.org/wiki/Leaky_abstraction > > -- > > Last but not least, where to maintain JavaScript SDK projects: low-level JavaScript Binding + high-level oVirt.js library. > > I agree that conceptually both above mentioned projects should go into dedicated "ovirt-engine-sdk-js" git repository and have their own build/release process. However, for now, we're just making baby steps so let's keep things simple and prototype these projects as part of "ovirt-engine" git repository. > > ... we can complicate things anytime, but we should know that any complex system that works has inevitably evolved from simple system that works ... (quote from http://en.wikipedia.org/wiki/Gall%27s_law) I think the entities should just be generated from the xsd. for the rsdl, makes sense to start with clean code to see what works best, then see about generating it (but you should adhere the rsdl as guidlines i guess). lets try to plan for lightweight entities while at it - the API has a mechanism for different level of details - maybe we need a custom level where the client specifies which fields they want back or something like that. Good luck, Itamar From vszocs at redhat.com Thu Nov 21 21:56:58 2013 From: vszocs at redhat.com (Vojtech Szocs) Date: Thu, 21 Nov 2013 16:56:58 -0500 (EST) Subject: [Engine-devel] Using REST API in web UI - review call summary In-Reply-To: <528E7A30.7040503@redhat.com> References: <1515483885.28819526.1385068697947.JavaMail.root@redhat.com> <528E7A30.7040503@redhat.com> Message-ID: <1590829306.28868001.1385071018139.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Itamar Heim" > To: "Vojtech Szocs" , "engine-devel" > Cc: "Einav Cohen" > Sent: Thursday, November 21, 2013 10:25:04 PM > Subject: Re: Using REST API in web UI - review call summary > > On 11/21/2013 11:18 PM, Vojtech Szocs wrote: > > Hi guys, > > > > this is a summary of yesterday's review call, I'll try to highlight > > important Q/A and things we agreed on. Feel free to add anything in case > > I've missed something. > > > > -- > > > > Q: Why don't we simply try to use existing Java SDK and adapt it for GWT > > apps? (asked by Michael & Gilad) > > > > A: This might be a viable option to consider if we wanted to skip > > JavaScript-based SDK altogether and target Java/GWT code directly; we > > could simply take Java SDK and customize its abstractions where necessary, > > i.e. using HTTP transport layer implementation that works with GWT. In any > > case, this would mean coupling ourselves to Java SDK (which has its own > > release cycle) and I think this would complicate things for us. > > > > As proposed on the meeting, I think it's best to aim for JavaScript SDK as > > the lowest common denominator for *any* web application that wants to work > > with REST API. oVirt GWT-based UI can simply bind to JavaScript SDK, i.e. > > Java/GWT code that just overlays objects and functions provided by > > JavaScript SDK. Another reason is ease of maintenance - I'd rather see > > JavaScript SDK's code generation process to be independent of any other > > SDK (people responsible for maintaining JavaScript SDK should have full > > control over generated code). > > > > -- > > > > Q: What about functionality currently used by oVirt UI but not supported by > > REST API? (asked by Einav) > > [For example, fetching VM entity over GWT RPC also returns related data > > such as Cluster name.] > > > > A: Based on discussion I've had with other colleagues after yesterday's > > review call, I don't think that separate support-like backend layer is a > > good idea. Instead, this is the kind of functionality that could be placed > > in oVirt.js library. Logical operations like "get VMs and related data" > > would be exposed through oVirt.js (callback-based) API and ultimately > > realized as multiple physical requests to REST API via JavaScript Binding. > > > > oVirt.js client would be completely oblivious to the fact that multiple > > physical requests are dispatched. In fact, since HTTP communication is > > asynchronous in nature, oVirt.js client wouldn't even notice any > > difference in terms of API consumption. This assumes JavaScript SDK would > > use callback-based (non-blocking) API instead of blocking one - after all, > > blocking API on top of non-blocking implementation sounds pretty much like > > leaky abstraction [1]. > > > > For example: > > > > sdk.getVmsWithExtraData( > > callbackToGetExtraDataForGivenVm, // might cause extra physical > > requests to REST API > > callbackFiredWhenAllDataIsReady // update client only when all > > data is ready > > ) > > would this also resolve RunMultipleActions? Yes, I think so. There could be API to pass multiple "actions" and get notified when they complete. > sounds like no reason to have RunMultipleQueries, although i'm still > sure a single call to engine for multiple keys would be much more > efficient than multiple async calls? > (I understand we may not be able to model this). Efficiency-wise, yes, single call to get all data seems optimal. API-wise, I don't think it really matters from oVirt.js client perspective. We can proceed with simple (possibly inefficient) solution and improve as needed. We're making baby steps now.. > > > > > [1] http://en.wikipedia.org/wiki/Leaky_abstraction > > > > -- > > > > Last but not least, where to maintain JavaScript SDK projects: low-level > > JavaScript Binding + high-level oVirt.js library. > > > > I agree that conceptually both above mentioned projects should go into > > dedicated "ovirt-engine-sdk-js" git repository and have their own > > build/release process. However, for now, we're just making baby steps so > > let's keep things simple and prototype these projects as part of > > "ovirt-engine" git repository. > > > > ... we can complicate things anytime, but we should know that any complex > > system that works has inevitably evolved from simple system that works ... > > (quote from http://en.wikipedia.org/wiki/Gall%27s_law) > > I think the entities should just be generated from the xsd. +1 The JavaScript Binding (aka low-level SDK) module should follow same concepts as existing Java SDK - generated entities decorated with operations to form fluent API. Everything Java SDK currently offers should be available in JavaScript Binding. oVirt.js is our opportunity to build on top of that. > for the rsdl, makes sense to start with clean code to see what works > best, then see about generating it (but you should adhere the rsdl as > guidlines i guess). +1 The initial prototype should be written by hand, things will get generated as soon as we have better idea how the end result should look like. > > lets try to plan for lightweight entities while at it - the API has a > mechanism for different level of details - maybe we need a custom level > where the client specifies which fields they want back or something like > that. Good idea! We should definitely think about the granularity of entities. I didn't know REST API supports different level of detail per entity, is there some documentation for this feature? Since JavaScript is dynamic, one possible solution would be to let client define the entity structure (i.e. what data client needs) on the fly, during runtime :) > > Good luck, > Itamar > From iheim at redhat.com Thu Nov 21 22:00:25 2013 From: iheim at redhat.com (Itamar Heim) Date: Fri, 22 Nov 2013 00:00:25 +0200 Subject: [Engine-devel] Using REST API in web UI - review call summary In-Reply-To: <1590829306.28868001.1385071018139.JavaMail.root@redhat.com> References: <1515483885.28819526.1385068697947.JavaMail.root@redhat.com> <528E7A30.7040503@redhat.com> <1590829306.28868001.1385071018139.JavaMail.root@redhat.com> Message-ID: <528E8279.40701@redhat.com> On 11/21/2013 11:56 PM, Vojtech Szocs wrote: > > > ----- Original Message ----- >> From: "Itamar Heim" >> To: "Vojtech Szocs" , "engine-devel" >> Cc: "Einav Cohen" >> Sent: Thursday, November 21, 2013 10:25:04 PM >> Subject: Re: Using REST API in web UI - review call summary >> >> On 11/21/2013 11:18 PM, Vojtech Szocs wrote: >>> Hi guys, >>> >>> this is a summary of yesterday's review call, I'll try to highlight >>> important Q/A and things we agreed on. Feel free to add anything in case >>> I've missed something. >>> >>> -- >>> >>> Q: Why don't we simply try to use existing Java SDK and adapt it for GWT >>> apps? (asked by Michael & Gilad) >>> >>> A: This might be a viable option to consider if we wanted to skip >>> JavaScript-based SDK altogether and target Java/GWT code directly; we >>> could simply take Java SDK and customize its abstractions where necessary, >>> i.e. using HTTP transport layer implementation that works with GWT. In any >>> case, this would mean coupling ourselves to Java SDK (which has its own >>> release cycle) and I think this would complicate things for us. >>> >>> As proposed on the meeting, I think it's best to aim for JavaScript SDK as >>> the lowest common denominator for *any* web application that wants to work >>> with REST API. oVirt GWT-based UI can simply bind to JavaScript SDK, i.e. >>> Java/GWT code that just overlays objects and functions provided by >>> JavaScript SDK. Another reason is ease of maintenance - I'd rather see >>> JavaScript SDK's code generation process to be independent of any other >>> SDK (people responsible for maintaining JavaScript SDK should have full >>> control over generated code). >>> >>> -- >>> >>> Q: What about functionality currently used by oVirt UI but not supported by >>> REST API? (asked by Einav) >>> [For example, fetching VM entity over GWT RPC also returns related data >>> such as Cluster name.] >>> >>> A: Based on discussion I've had with other colleagues after yesterday's >>> review call, I don't think that separate support-like backend layer is a >>> good idea. Instead, this is the kind of functionality that could be placed >>> in oVirt.js library. Logical operations like "get VMs and related data" >>> would be exposed through oVirt.js (callback-based) API and ultimately >>> realized as multiple physical requests to REST API via JavaScript Binding. >>> >>> oVirt.js client would be completely oblivious to the fact that multiple >>> physical requests are dispatched. In fact, since HTTP communication is >>> asynchronous in nature, oVirt.js client wouldn't even notice any >>> difference in terms of API consumption. This assumes JavaScript SDK would >>> use callback-based (non-blocking) API instead of blocking one - after all, >>> blocking API on top of non-blocking implementation sounds pretty much like >>> leaky abstraction [1]. >>> >>> For example: >>> >>> sdk.getVmsWithExtraData( >>> callbackToGetExtraDataForGivenVm, // might cause extra physical >>> requests to REST API >>> callbackFiredWhenAllDataIsReady // update client only when all >>> data is ready >>> ) >> >> would this also resolve RunMultipleActions? > > Yes, I think so. There could be API to pass multiple "actions" and get notified when they complete. > >> sounds like no reason to have RunMultipleQueries, although i'm still >> sure a single call to engine for multiple keys would be much more >> efficient than multiple async calls? >> (I understand we may not be able to model this). > > Efficiency-wise, yes, single call to get all data seems optimal. API-wise, I don't think it really matters from oVirt.js client perspective. > > We can proceed with simple (possibly inefficient) solution and improve as needed. We're making baby steps now.. > >> >>> >>> [1] http://en.wikipedia.org/wiki/Leaky_abstraction >>> >>> -- >>> >>> Last but not least, where to maintain JavaScript SDK projects: low-level >>> JavaScript Binding + high-level oVirt.js library. >>> >>> I agree that conceptually both above mentioned projects should go into >>> dedicated "ovirt-engine-sdk-js" git repository and have their own >>> build/release process. However, for now, we're just making baby steps so >>> let's keep things simple and prototype these projects as part of >>> "ovirt-engine" git repository. >>> >>> ... we can complicate things anytime, but we should know that any complex >>> system that works has inevitably evolved from simple system that works ... >>> (quote from http://en.wikipedia.org/wiki/Gall%27s_law) >> >> I think the entities should just be generated from the xsd. > > +1 > > The JavaScript Binding (aka low-level SDK) module should follow same concepts as existing Java SDK - generated entities decorated with operations to form fluent API. > > Everything Java SDK currently offers should be available in JavaScript Binding. oVirt.js is our opportunity to build on top of that. > >> for the rsdl, makes sense to start with clean code to see what works >> best, then see about generating it (but you should adhere the rsdl as >> guidlines i guess). > > +1 > > The initial prototype should be written by hand, things will get generated as soon as we have better idea how the end result should look like. i can understand that for the methods and maybe for populating the entities for the first few. the entities themselves, no point in hand coding - just generated them from the api.xsd. and once you decide how you want to fill them, not worth hand coding this - either json gives this out of the box, or should be generated as well. > >> >> lets try to plan for lightweight entities while at it - the API has a >> mechanism for different level of details - maybe we need a custom level >> where the client specifies which fields they want back or something like >> that. > > Good idea! We should definitely think about the granularity of entities. > > I didn't know REST API supports different level of detail per entity, is there some documentation for this feature? > > Since JavaScript is dynamic, one possible solution would be to let client define the entity structure (i.e. what data client needs) on the fly, during runtime :) michael? > >> >> Good luck, >> Itamar >> From vszocs at redhat.com Thu Nov 21 22:08:21 2013 From: vszocs at redhat.com (Vojtech Szocs) Date: Thu, 21 Nov 2013 17:08:21 -0500 (EST) Subject: [Engine-devel] Using REST API in web UI - review call summary In-Reply-To: <528E8279.40701@redhat.com> References: <1515483885.28819526.1385068697947.JavaMail.root@redhat.com> <528E7A30.7040503@redhat.com> <1590829306.28868001.1385071018139.JavaMail.root@redhat.com> <528E8279.40701@redhat.com> Message-ID: <396929524.28875662.1385071701788.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Itamar Heim" > To: "Vojtech Szocs" > Cc: "engine-devel" , "Einav Cohen" , "Michael Pasternak" > > Sent: Thursday, November 21, 2013 11:00:25 PM > Subject: Re: Using REST API in web UI - review call summary > > On 11/21/2013 11:56 PM, Vojtech Szocs wrote: > > > > > > ----- Original Message ----- > >> From: "Itamar Heim" > >> To: "Vojtech Szocs" , "engine-devel" > >> > >> Cc: "Einav Cohen" > >> Sent: Thursday, November 21, 2013 10:25:04 PM > >> Subject: Re: Using REST API in web UI - review call summary > >> > >> On 11/21/2013 11:18 PM, Vojtech Szocs wrote: > >>> Hi guys, > >>> > >>> this is a summary of yesterday's review call, I'll try to highlight > >>> important Q/A and things we agreed on. Feel free to add anything in case > >>> I've missed something. > >>> > >>> -- > >>> > >>> Q: Why don't we simply try to use existing Java SDK and adapt it for GWT > >>> apps? (asked by Michael & Gilad) > >>> > >>> A: This might be a viable option to consider if we wanted to skip > >>> JavaScript-based SDK altogether and target Java/GWT code directly; we > >>> could simply take Java SDK and customize its abstractions where > >>> necessary, > >>> i.e. using HTTP transport layer implementation that works with GWT. In > >>> any > >>> case, this would mean coupling ourselves to Java SDK (which has its own > >>> release cycle) and I think this would complicate things for us. > >>> > >>> As proposed on the meeting, I think it's best to aim for JavaScript SDK > >>> as > >>> the lowest common denominator for *any* web application that wants to > >>> work > >>> with REST API. oVirt GWT-based UI can simply bind to JavaScript SDK, i.e. > >>> Java/GWT code that just overlays objects and functions provided by > >>> JavaScript SDK. Another reason is ease of maintenance - I'd rather see > >>> JavaScript SDK's code generation process to be independent of any other > >>> SDK (people responsible for maintaining JavaScript SDK should have full > >>> control over generated code). > >>> > >>> -- > >>> > >>> Q: What about functionality currently used by oVirt UI but not supported > >>> by > >>> REST API? (asked by Einav) > >>> [For example, fetching VM entity over GWT RPC also returns related > >>> data > >>> such as Cluster name.] > >>> > >>> A: Based on discussion I've had with other colleagues after yesterday's > >>> review call, I don't think that separate support-like backend layer is a > >>> good idea. Instead, this is the kind of functionality that could be > >>> placed > >>> in oVirt.js library. Logical operations like "get VMs and related data" > >>> would be exposed through oVirt.js (callback-based) API and ultimately > >>> realized as multiple physical requests to REST API via JavaScript > >>> Binding. > >>> > >>> oVirt.js client would be completely oblivious to the fact that multiple > >>> physical requests are dispatched. In fact, since HTTP communication is > >>> asynchronous in nature, oVirt.js client wouldn't even notice any > >>> difference in terms of API consumption. This assumes JavaScript SDK would > >>> use callback-based (non-blocking) API instead of blocking one - after > >>> all, > >>> blocking API on top of non-blocking implementation sounds pretty much > >>> like > >>> leaky abstraction [1]. > >>> > >>> For example: > >>> > >>> sdk.getVmsWithExtraData( > >>> callbackToGetExtraDataForGivenVm, // might cause extra physical > >>> requests to REST API > >>> callbackFiredWhenAllDataIsReady // update client only when > >>> all > >>> data is ready > >>> ) > >> > >> would this also resolve RunMultipleActions? > > > > Yes, I think so. There could be API to pass multiple "actions" and get > > notified when they complete. > > > >> sounds like no reason to have RunMultipleQueries, although i'm still > >> sure a single call to engine for multiple keys would be much more > >> efficient than multiple async calls? > >> (I understand we may not be able to model this). > > > > Efficiency-wise, yes, single call to get all data seems optimal. API-wise, > > I don't think it really matters from oVirt.js client perspective. > > > > We can proceed with simple (possibly inefficient) solution and improve as > > needed. We're making baby steps now.. > > > >> > >>> > >>> [1] http://en.wikipedia.org/wiki/Leaky_abstraction > >>> > >>> -- > >>> > >>> Last but not least, where to maintain JavaScript SDK projects: low-level > >>> JavaScript Binding + high-level oVirt.js library. > >>> > >>> I agree that conceptually both above mentioned projects should go into > >>> dedicated "ovirt-engine-sdk-js" git repository and have their own > >>> build/release process. However, for now, we're just making baby steps so > >>> let's keep things simple and prototype these projects as part of > >>> "ovirt-engine" git repository. > >>> > >>> ... we can complicate things anytime, but we should know that any complex > >>> system that works has inevitably evolved from simple system that works > >>> ... > >>> (quote from http://en.wikipedia.org/wiki/Gall%27s_law) > >> > >> I think the entities should just be generated from the xsd. > > > > +1 > > > > The JavaScript Binding (aka low-level SDK) module should follow same > > concepts as existing Java SDK - generated entities decorated with > > operations to form fluent API. > > > > Everything Java SDK currently offers should be available in JavaScript > > Binding. oVirt.js is our opportunity to build on top of that. > > > >> for the rsdl, makes sense to start with clean code to see what works > >> best, then see about generating it (but you should adhere the rsdl as > >> guidlines i guess). > > > > +1 > > > > The initial prototype should be written by hand, things will get generated > > as soon as we have better idea how the end result should look like. > > i can understand that for the methods and maybe for populating the > entities for the first few. > the entities themselves, no point in hand coding - just generated them > from the api.xsd. > and once you decide how you want to fill them, not worth hand coding > this - either json gives this out of the box, or should be generated as > well. OK, now I get you :) sure, entities aren't too interesting by themselves, but populating (decorating) them is something that requires more thought. > > > > >> > >> lets try to plan for lightweight entities while at it - the API has a > >> mechanism for different level of details - maybe we need a custom level > >> where the client specifies which fields they want back or something like > >> that. > > > > Good idea! We should definitely think about the granularity of entities. > > > > I didn't know REST API supports different level of detail per entity, is > > there some documentation for this feature? > > > > Since JavaScript is dynamic, one possible solution would be to let client > > define the entity structure (i.e. what data client needs) on the fly, > > during runtime :) > > michael? > > > > >> > >> Good luck, > >> Itamar > >> > > From danken at redhat.com Fri Nov 22 11:52:52 2013 From: danken at redhat.com (Dan Kenigsberg) Date: Fri, 22 Nov 2013 11:52:52 +0000 Subject: [Engine-devel] failed to add host into cluster In-Reply-To: References: <307132015.5144883.1375706091754.JavaMail.root@redhat.com> <528DCD64.5010407@redhat.com> <528DE1F1.4090603@redhat.com> <528DE793.8060500@redhat.com> <528DE858.6080502@redhat.com> <528DEAE5.4030708@redhat.com> <528DF261.1020407@redhat.com> Message-ID: <20131122115252.GT24074@redhat.com> On Thu, Nov 21, 2013 at 05:22:35PM +0100, Michal Skrivanek wrote: > > >> ok, that looks ok. Might be text parsing issue. > >> And "virsh capabilities" output? > >> what's the vdsm you're using? > > > > virsh capabilities" output is a bit long, see attachment > > > > # rpm -q vdsm > > vdsm-4.10.3-18.fc19.x86_64 > > hmm, works well on my box > try master, though this code didn't change since 2012 > > the code in vdsm/caps.py is pretty straightforward: > caps = minidom.parseString(capabilities) > for archTag in caps.getElementsByTagName('arch'): > if archTag.getAttribute('name') == 'x86_64': > return [m.firstChild.data for m in archTag.childNodes > if m.nodeName == 'machine'] > > > try to uninstall qemu Alpha support if it changes a thing or not... As Michal noted, Vdsm parses the attached capabilities as it should. Maybe it receives something else from libvirt. Could you add some logging and report? diff --git a/vdsm/caps.py b/vdsm/caps.py index 5599522..4daca46 100644 --- a/vdsm/caps.py +++ b/vdsm/caps.py @@ -136,6 +136,7 @@ def _getCpuTopology(capabilities): def _getEmulatedMachines(capabilities=None): if capabilities is None: capabilities = _getCapsXMLStr() + logging.debug('caps: %s', capabilities) caps = minidom.parseString(capabilities) for archTag in caps.getElementsByTagName('arch'): if archTag.getAttribute('name') == 'x86_64': Maybe you can add some logging From gouyang at redhat.com Fri Nov 22 12:38:33 2013 From: gouyang at redhat.com (ouyang guohua) Date: Fri, 22 Nov 2013 20:38:33 +0800 Subject: [Engine-devel] failed to add host into cluster In-Reply-To: <20131122115252.GT24074@redhat.com> References: <307132015.5144883.1375706091754.JavaMail.root@redhat.com> <528DCD64.5010407@redhat.com> <528DE1F1.4090603@redhat.com> <528DE793.8060500@redhat.com> <528DE858.6080502@redhat.com> <528DEAE5.4030708@redhat.com> <528DF261.1020407@redhat.com> <20131122115252.GT24074@redhat.com> Message-ID: <528F5049.3090307@redhat.com> On 11/22/2013 07:52 PM, Dan Kenigsberg wrote: > On Thu, Nov 21, 2013 at 05:22:35PM +0100, Michal Skrivanek wrote: >>>> ok, that looks ok. Might be text parsing issue. >>>> And "virsh capabilities" output? >>>> what's the vdsm you're using? >>> virsh capabilities" output is a bit long, see attachment >>> >>> # rpm -q vdsm >>> vdsm-4.10.3-18.fc19.x86_64 >> hmm, works well on my box >> try master, though this code didn't change since 2012 >> >> the code in vdsm/caps.py is pretty straightforward: >> caps = minidom.parseString(capabilities) >> for archTag in caps.getElementsByTagName('arch'): >> if archTag.getAttribute('name') == 'x86_64': >> return [m.firstChild.data for m in archTag.childNodes >> if m.nodeName == 'machine'] >> >> >> try to uninstall qemu Alpha support if it changes a thing or not... > As Michal noted, Vdsm parses the attached capabilities as it should. > Maybe it receives something else from libvirt. Could you add some > logging and report? > > diff --git a/vdsm/caps.py b/vdsm/caps.py > index 5599522..4daca46 100644 > --- a/vdsm/caps.py > +++ b/vdsm/caps.py > @@ -136,6 +136,7 @@ def _getCpuTopology(capabilities): > def _getEmulatedMachines(capabilities=None): > if capabilities is None: > capabilities = _getCapsXMLStr() > + logging.debug('caps: %s', capabilities) > caps = minidom.parseString(capabilities) > for archTag in caps.getElementsByTagName('arch'): > if archTag.getAttribute('name') == 'x86_64': > > Maybe you can add some logging ok, I will try it next Tuesday because I could not access the machine at this time. From alitke at redhat.com Fri Nov 22 16:52:11 2013 From: alitke at redhat.com (Adam Litke) Date: Fri, 22 Nov 2013 11:52:11 -0500 (EST) Subject: [Engine-devel] Java Newbie: Renaming some functions to fix findbugs warnings In-Reply-To: <7479768.2488462.1385139038321.JavaMail.root@redhat.com> Message-ID: <69302659.2488736.1385139131041.JavaMail.root@redhat.com> Hello, I am working on resolving some warnings produced by findbugs and am looking for some advice on how to properly resolve the problem. The Frontend class has several pairs of methods where a capitalized version is a deprecated static form and the camelCase version is the instance method. For example: @Deprecated public static void RunQuery(...) - and - public void runQuery(...) In both cases the parameters are the same so simply renaming RunQuery to runQuery will result in a conflict. Since I am new to Java and the ovirt-engine project I am looking for some advice on how to fix the function name without breaking the code or people's sense of aesthetics. Since this is a deprecated function, would it be terrible to rename it to 'runQueryStatic' or 'runQueryDeprecated'? Since the language provides syntactic annotations for 'static' and 'deprecated', both of these names feel dirty but I am not sure what would be better. Thanks for helping out a newbie! --Adam From awels at redhat.com Fri Nov 22 17:00:04 2013 From: awels at redhat.com (Alexander Wels) Date: Fri, 22 Nov 2013 12:00:04 -0500 Subject: [Engine-devel] Java Newbie: Renaming some functions to fix findbugs warnings In-Reply-To: <69302659.2488736.1385139131041.JavaMail.root@redhat.com> References: <69302659.2488736.1385139131041.JavaMail.root@redhat.com> Message-ID: <28299928.PKkqTrHgaY@awels> Adam, We are aware of this issue and we actually have a patch somewhat ready to solve the issue [1]. We made the RunQuery/RunAction/etc method deprecated to encourage people to no longer use them. We have patch ready to remove all current uses of RunQuery/RunAction/etc from the code base, but haven't gotten around to rebasing/merging the patch. Alexander [1] http://gerrit.ovirt.org/#/c/18413/ On Friday, November 22, 2013 11:52:11 AM Adam Litke wrote: > Hello, > > I am working on resolving some warnings produced by findbugs and am looking > for some advice on how to properly resolve the problem. > > The Frontend class has several pairs of methods where a capitalized version > is a deprecated static form and the camelCase version is the instance > method. > > For example: > > @Deprecated > public static void RunQuery(...) > > - and - > > public void runQuery(...) > > In both cases the parameters are the same so simply renaming RunQuery to > runQuery will result in a conflict. Since I am new to Java and the > ovirt-engine project I am looking for some advice on how to fix the > function name without breaking the code or people's sense of aesthetics. > Since this is a deprecated function, would it be terrible to rename it to > 'runQueryStatic' or 'runQueryDeprecated'? Since the language provides > syntactic annotations for 'static' and 'deprecated', both of these names > feel dirty but I am not sure what would be better. Thanks for helping out > a newbie! > > --Adam > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel From alitke at redhat.com Fri Nov 22 17:47:28 2013 From: alitke at redhat.com (Adam Litke) Date: Fri, 22 Nov 2013 12:47:28 -0500 (EST) Subject: [Engine-devel] Java Newbie: Renaming some functions to fix findbugs warnings In-Reply-To: <28299928.PKkqTrHgaY@awels> References: <69302659.2488736.1385139131041.JavaMail.root@redhat.com> <28299928.PKkqTrHgaY@awels> Message-ID: <1327017723.2494432.1385142448236.JavaMail.root@redhat.com> > Adam, > > We are aware of this issue and we actually have a patch somewhat ready to > solve the issue [1]. We made the RunQuery/RunAction/etc method deprecated to > encourage people to no longer use them. We have patch ready to remove all > current uses of RunQuery/RunAction/etc from the code base, but haven't gotten > around to rebasing/merging the patch. > > Alexander > > [1] http://gerrit.ovirt.org/#/c/18413/ Thanks for the detail! Looks like fixing this properly is far from a beginner's task. From mpastern at redhat.com Sun Nov 24 08:07:01 2013 From: mpastern at redhat.com (Michael Pasternak) Date: Sun, 24 Nov 2013 10:07:01 +0200 Subject: [Engine-devel] Using REST API in web UI - review call summary In-Reply-To: <1515483885.28819526.1385068697947.JavaMail.root@redhat.com> References: <1515483885.28819526.1385068697947.JavaMail.root@redhat.com> Message-ID: <5291B3A5.5060305@redhat.com> Hi Vojtech, First of all it was a good "presentation" of requirements + suggested solutions - well done!, few comments/questions inline. On 11/21/2013 11:18 PM, Vojtech Szocs wrote: > Hi guys, > > this is a summary of yesterday's review call, I'll try to highlight important Q/A and things we agreed on. > Feel free to add anything in case I've missed something. > > -- > > Q: Why don't we simply try to use existing Java SDK and adapt it for GWT apps? (asked by Michael & Gilad) > > A: This might be a viable option to consider if we wanted to skip JavaScript-based SDK altogether and target Java/GWT code > directly; we could simply take Java SDK and customize its abstractions where necessary, i.e. using HTTP transport layer > implementation that works with GWT. In any case, this would mean coupling ourselves to Java SDK (which has its own release cycle) > and I think this would complicate things for us. not sure i buy this one :), this is the purpose of any sdk, including the one you about to write, people that will use it, will be "coupling" to it ... > > As proposed on the meeting, I think it's best to aim for JavaScript SDK as the lowest > common denominator for *any* web application that wants to work with REST API. oVirt GWT-based > UI can simply bind to JavaScript SDK, i.e. Java/GWT code that just overlays objects and functions > provided by JavaScript SDK. Another reason is ease of maintenance - I'd rather see JavaScript SDK's code > generation process to be independent of any other SDK (people responsible for maintaining JavaScript SDK > should have full control over generated code). what do you mean by "people should have full control over generated code"? the purpose of code generation is to ease maintenance, i.e you/maintainer should not write the feature once it available in api, just run CodeGen and you'll get it for free, but this is zero control over code. > > -- > > Q: What about functionality currently used by oVirt UI but not supported by REST API? (asked by Einav) > [For example, fetching VM entity over GWT RPC also returns related data such as Cluster name.] > > A: Based on discussion I've had with other colleagues after yesterday's review call, I don't think that > separate support-like backend layer is a good idea. Instead, this is the kind of functionality that could be > placed in oVirt.js library. Logical operations like "get VMs and related data" would be exposed through oVirt.js > (callback-based) API and ultimately realized as multiple physical requests to REST API via JavaScript Binding. > > oVirt.js client would be completely oblivious to the fact that multiple physical requests are dispatched. In fact, > since HTTP communication is asynchronous in nature, oVirt.js client wouldn't even notice any difference in terms of API > consumption. This assumes JavaScript SDK would use callback-based (non-blocking) API instead of blocking one - after all, > blocking API on top of non-blocking implementation sounds pretty much like leaky abstraction [1]. > > For example: > > sdk.getVmsWithExtraData( > callbackToGetExtraDataForGivenVm, // might cause extra physical requests to REST API > callbackFiredWhenAllDataIsReady // update client only when all data is ready > ) actually this the main bottleneck in moving UI to work on top of REST, and most interesting/complex part of this project, you should think of very wise polling mechanism cause callbacks is a nice thing on paper, but behind the scene it all about polling: - the entity/s till action got accomplished - add to this updating different grids - running multiple actions - showing events - and obviously much more and don't forget that every polled entity should be marshalled from xml to the javascript entity so at the end, "callbacks" mechanism will be extremely CPU consuming. > > [1] http://en.wikipedia.org/wiki/Leaky_abstraction > > -- > > Last but not least, where to maintain JavaScript SDK projects: low-level JavaScript Binding + high-level oVirt.js library. > > I agree that conceptually both above mentioned projects should go into dedicated "ovirt-engine-sdk-js" git repository and > have their own build/release process. However, for now, we're just making baby steps so let's keep things simple and prototype > these projects as part of "ovirt-engine" git repository. > > ... we can complicate things anytime, but we should know that any complex system that works has inevitably evolved from simple > system that works ... (quote from http://en.wikipedia.org/wiki/Gall%27s_law) > > Regards, > Vojtech > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > -- Michael Pasternak RedHat, ENG-Virtualization R&D From mpastern at redhat.com Sun Nov 24 08:37:22 2013 From: mpastern at redhat.com (Michael Pasternak) Date: Sun, 24 Nov 2013 10:37:22 +0200 Subject: [Engine-devel] Using REST API in web UI - review call summary In-Reply-To: <528E8279.40701@redhat.com> References: <1515483885.28819526.1385068697947.JavaMail.root@redhat.com> <528E7A30.7040503@redhat.com> <1590829306.28868001.1385071018139.JavaMail.root@redhat.com> <528E8279.40701@redhat.com> Message-ID: <5291BAC2.9010902@redhat.com> On 11/22/2013 12:00 AM, Itamar Heim wrote: > On 11/21/2013 11:56 PM, Vojtech Szocs wrote: >> >> >> ----- Original Message ----- >>> From: "Itamar Heim" >>> To: "Vojtech Szocs" , "engine-devel" >>> Cc: "Einav Cohen" >>> Sent: Thursday, November 21, 2013 10:25:04 PM >>> Subject: Re: Using REST API in web UI - review call summary >>> >>> On 11/21/2013 11:18 PM, Vojtech Szocs wrote: >>>> Hi guys, >>>> >>>> this is a summary of yesterday's review call, I'll try to highlight >>>> important Q/A and things we agreed on. Feel free to add anything in case >>>> I've missed something. >>>> >>>> -- >>>> >>>> Q: Why don't we simply try to use existing Java SDK and adapt it for GWT >>>> apps? (asked by Michael & Gilad) >>>> >>>> A: This might be a viable option to consider if we wanted to skip >>>> JavaScript-based SDK altogether and target Java/GWT code directly; we >>>> could simply take Java SDK and customize its abstractions where necessary, >>>> i.e. using HTTP transport layer implementation that works with GWT. In any >>>> case, this would mean coupling ourselves to Java SDK (which has its own >>>> release cycle) and I think this would complicate things for us. >>>> >>>> As proposed on the meeting, I think it's best to aim for JavaScript SDK as >>>> the lowest common denominator for *any* web application that wants to work >>>> with REST API. oVirt GWT-based UI can simply bind to JavaScript SDK, i.e. >>>> Java/GWT code that just overlays objects and functions provided by >>>> JavaScript SDK. Another reason is ease of maintenance - I'd rather see >>>> JavaScript SDK's code generation process to be independent of any other >>>> SDK (people responsible for maintaining JavaScript SDK should have full >>>> control over generated code). >>>> >>>> -- >>>> >>>> Q: What about functionality currently used by oVirt UI but not supported by >>>> REST API? (asked by Einav) >>>> [For example, fetching VM entity over GWT RPC also returns related data >>>> such as Cluster name.] >>>> >>>> A: Based on discussion I've had with other colleagues after yesterday's >>>> review call, I don't think that separate support-like backend layer is a >>>> good idea. Instead, this is the kind of functionality that could be placed >>>> in oVirt.js library. Logical operations like "get VMs and related data" >>>> would be exposed through oVirt.js (callback-based) API and ultimately >>>> realized as multiple physical requests to REST API via JavaScript Binding. >>>> >>>> oVirt.js client would be completely oblivious to the fact that multiple >>>> physical requests are dispatched. In fact, since HTTP communication is >>>> asynchronous in nature, oVirt.js client wouldn't even notice any >>>> difference in terms of API consumption. This assumes JavaScript SDK would >>>> use callback-based (non-blocking) API instead of blocking one - after all, >>>> blocking API on top of non-blocking implementation sounds pretty much like >>>> leaky abstraction [1]. >>>> >>>> For example: >>>> >>>> sdk.getVmsWithExtraData( >>>> callbackToGetExtraDataForGivenVm, // might cause extra physical >>>> requests to REST API >>>> callbackFiredWhenAllDataIsReady // update client only when all >>>> data is ready >>>> ) >>> >>> would this also resolve RunMultipleActions? >> >> Yes, I think so. There could be API to pass multiple "actions" and get notified when they complete. >> >>> sounds like no reason to have RunMultipleQueries, although i'm still >>> sure a single call to engine for multiple keys would be much more >>> efficient than multiple async calls? >>> (I understand we may not be able to model this). >> >> Efficiency-wise, yes, single call to get all data seems optimal. API-wise, I don't think it really matters from oVirt.js client perspective. >> >> We can proceed with simple (possibly inefficient) solution and improve as needed. We're making baby steps now.. >> >>> >>>> >>>> [1] http://en.wikipedia.org/wiki/Leaky_abstraction >>>> >>>> -- >>>> >>>> Last but not least, where to maintain JavaScript SDK projects: low-level >>>> JavaScript Binding + high-level oVirt.js library. >>>> >>>> I agree that conceptually both above mentioned projects should go into >>>> dedicated "ovirt-engine-sdk-js" git repository and have their own >>>> build/release process. However, for now, we're just making baby steps so >>>> let's keep things simple and prototype these projects as part of >>>> "ovirt-engine" git repository. >>>> >>>> ... we can complicate things anytime, but we should know that any complex >>>> system that works has inevitably evolved from simple system that works ... >>>> (quote from http://en.wikipedia.org/wiki/Gall%27s_law) >>> >>> I think the entities should just be generated from the xsd. >> >> +1 >> >> The JavaScript Binding (aka low-level SDK) module should follow same concepts as existing Java SDK - generated entities decorated with operations to form fluent API. >> >> Everything Java SDK currently offers should be available in JavaScript Binding. oVirt.js is our opportunity to build on top of that. >> >>> for the rsdl, makes sense to start with clean code to see what works >>> best, then see about generating it (but you should adhere the rsdl as >>> guidlines i guess). >> >> +1 >> >> The initial prototype should be written by hand, things will get generated as soon as we have better idea how the end result should look like. > > i can understand that for the methods and maybe for populating the entities for the first few. > the entities themselves, no point in hand coding - just generated them from the api.xsd. > and once you decide how you want to fill them, not worth hand coding this - either json gives this out of the box, or should be generated as well. > >> >>> >>> lets try to plan for lightweight entities while at it - the API has a >>> mechanism for different level of details - maybe we need a custom level >>> where the client specifies which fields they want back or something like >>> that. >> >> Good idea! We should definitely think about the granularity of entities. >> >> I didn't know REST API supports different level of detail per entity, is there some documentation for this feature? currently it's about adding adding extra information (by supplying header [1]), this is driven by the properties that require extra query against the engine to fill them, obviously the default is [2] [1] All-Content: True [2] All-Content: False >> >> Since JavaScript is dynamic, one possible solution would be to let client define the entity structure (i.e. what data client needs) on the fly, during runtime :) we talked about this solution couple of years ago, but it was obvious that there is no real "demand" for it till UI moves to REST, btw it won't solve the problem where to fill UI entity you need combination of N REST entities, you still will have to perform N + 1 queries to API (maybe asking for entity with fewer details), - all it address is a capacity of the data being send. > > michael? > >> >>> >>> Good luck, >>> Itamar >>> > -- Michael Pasternak RedHat, ENG-Virtualization R&D From mpastern at redhat.com Sun Nov 24 08:38:45 2013 From: mpastern at redhat.com (Michael Pasternak) Date: Sun, 24 Nov 2013 10:38:45 +0200 Subject: [Engine-devel] Using REST API in web UI - review call summary In-Reply-To: <396929524.28875662.1385071701788.JavaMail.root@redhat.com> References: <1515483885.28819526.1385068697947.JavaMail.root@redhat.com> <528E7A30.7040503@redhat.com> <1590829306.28868001.1385071018139.JavaMail.root@redhat.com> <528E8279.40701@redhat.com> <396929524.28875662.1385071701788.JavaMail.root@redhat.com> Message-ID: <5291BB15.4050902@redhat.com> On 11/22/2013 12:08 AM, Vojtech Szocs wrote: > > > ----- Original Message ----- >> From: "Itamar Heim" >> To: "Vojtech Szocs" >> Cc: "engine-devel" , "Einav Cohen" , "Michael Pasternak" >> >> Sent: Thursday, November 21, 2013 11:00:25 PM >> Subject: Re: Using REST API in web UI - review call summary >> >> On 11/21/2013 11:56 PM, Vojtech Szocs wrote: >>> >>> >>> ----- Original Message ----- >>>> From: "Itamar Heim" >>>> To: "Vojtech Szocs" , "engine-devel" >>>> >>>> Cc: "Einav Cohen" >>>> Sent: Thursday, November 21, 2013 10:25:04 PM >>>> Subject: Re: Using REST API in web UI - review call summary >>>> >>>> On 11/21/2013 11:18 PM, Vojtech Szocs wrote: >>>>> Hi guys, >>>>> >>>>> this is a summary of yesterday's review call, I'll try to highlight >>>>> important Q/A and things we agreed on. Feel free to add anything in case >>>>> I've missed something. >>>>> >>>>> -- >>>>> >>>>> Q: Why don't we simply try to use existing Java SDK and adapt it for GWT >>>>> apps? (asked by Michael & Gilad) >>>>> >>>>> A: This might be a viable option to consider if we wanted to skip >>>>> JavaScript-based SDK altogether and target Java/GWT code directly; we >>>>> could simply take Java SDK and customize its abstractions where >>>>> necessary, >>>>> i.e. using HTTP transport layer implementation that works with GWT. In >>>>> any >>>>> case, this would mean coupling ourselves to Java SDK (which has its own >>>>> release cycle) and I think this would complicate things for us. >>>>> >>>>> As proposed on the meeting, I think it's best to aim for JavaScript SDK >>>>> as >>>>> the lowest common denominator for *any* web application that wants to >>>>> work >>>>> with REST API. oVirt GWT-based UI can simply bind to JavaScript SDK, i.e. >>>>> Java/GWT code that just overlays objects and functions provided by >>>>> JavaScript SDK. Another reason is ease of maintenance - I'd rather see >>>>> JavaScript SDK's code generation process to be independent of any other >>>>> SDK (people responsible for maintaining JavaScript SDK should have full >>>>> control over generated code). >>>>> >>>>> -- >>>>> >>>>> Q: What about functionality currently used by oVirt UI but not supported >>>>> by >>>>> REST API? (asked by Einav) >>>>> [For example, fetching VM entity over GWT RPC also returns related >>>>> data >>>>> such as Cluster name.] >>>>> >>>>> A: Based on discussion I've had with other colleagues after yesterday's >>>>> review call, I don't think that separate support-like backend layer is a >>>>> good idea. Instead, this is the kind of functionality that could be >>>>> placed >>>>> in oVirt.js library. Logical operations like "get VMs and related data" >>>>> would be exposed through oVirt.js (callback-based) API and ultimately >>>>> realized as multiple physical requests to REST API via JavaScript >>>>> Binding. >>>>> >>>>> oVirt.js client would be completely oblivious to the fact that multiple >>>>> physical requests are dispatched. In fact, since HTTP communication is >>>>> asynchronous in nature, oVirt.js client wouldn't even notice any >>>>> difference in terms of API consumption. This assumes JavaScript SDK would >>>>> use callback-based (non-blocking) API instead of blocking one - after >>>>> all, >>>>> blocking API on top of non-blocking implementation sounds pretty much >>>>> like >>>>> leaky abstraction [1]. >>>>> >>>>> For example: >>>>> >>>>> sdk.getVmsWithExtraData( >>>>> callbackToGetExtraDataForGivenVm, // might cause extra physical >>>>> requests to REST API >>>>> callbackFiredWhenAllDataIsReady // update client only when >>>>> all >>>>> data is ready >>>>> ) >>>> >>>> would this also resolve RunMultipleActions? >>> >>> Yes, I think so. There could be API to pass multiple "actions" and get >>> notified when they complete. >>> >>>> sounds like no reason to have RunMultipleQueries, although i'm still >>>> sure a single call to engine for multiple keys would be much more >>>> efficient than multiple async calls? >>>> (I understand we may not be able to model this). >>> >>> Efficiency-wise, yes, single call to get all data seems optimal. API-wise, >>> I don't think it really matters from oVirt.js client perspective. >>> >>> We can proceed with simple (possibly inefficient) solution and improve as >>> needed. We're making baby steps now.. >>> >>>> >>>>> >>>>> [1] http://en.wikipedia.org/wiki/Leaky_abstraction >>>>> >>>>> -- >>>>> >>>>> Last but not least, where to maintain JavaScript SDK projects: low-level >>>>> JavaScript Binding + high-level oVirt.js library. >>>>> >>>>> I agree that conceptually both above mentioned projects should go into >>>>> dedicated "ovirt-engine-sdk-js" git repository and have their own >>>>> build/release process. However, for now, we're just making baby steps so >>>>> let's keep things simple and prototype these projects as part of >>>>> "ovirt-engine" git repository. >>>>> >>>>> ... we can complicate things anytime, but we should know that any complex >>>>> system that works has inevitably evolved from simple system that works >>>>> ... >>>>> (quote from http://en.wikipedia.org/wiki/Gall%27s_law) >>>> >>>> I think the entities should just be generated from the xsd. >>> >>> +1 >>> >>> The JavaScript Binding (aka low-level SDK) module should follow same >>> concepts as existing Java SDK - generated entities decorated with >>> operations to form fluent API. >>> >>> Everything Java SDK currently offers should be available in JavaScript >>> Binding. oVirt.js is our opportunity to build on top of that. >>> >>>> for the rsdl, makes sense to start with clean code to see what works >>>> best, then see about generating it (but you should adhere the rsdl as >>>> guidlines i guess). >>> >>> +1 >>> >>> The initial prototype should be written by hand, things will get generated >>> as soon as we have better idea how the end result should look like. >> >> i can understand that for the methods and maybe for populating the >> entities for the first few. >> the entities themselves, no point in hand coding - just generated them >> from the api.xsd. >> and once you decide how you want to fill them, not worth hand coding >> this - either json gives this out of the box, or should be generated as >> well. > > OK, now I get you :) sure, entities aren't too interesting by themselves, but populating (decorating) them is something that requires more thought. you have Java-SDK that does this already, so it should be relativity easy to take it from there. > >> >>> >>>> >>>> lets try to plan for lightweight entities while at it - the API has a >>>> mechanism for different level of details - maybe we need a custom level >>>> where the client specifies which fields they want back or something like >>>> that. >>> >>> Good idea! We should definitely think about the granularity of entities. >>> >>> I didn't know REST API supports different level of detail per entity, is >>> there some documentation for this feature? >>> >>> Since JavaScript is dynamic, one possible solution would be to let client >>> define the entity structure (i.e. what data client needs) on the fly, >>> during runtime :) >> >> michael? >> >>> >>>> >>>> Good luck, >>>> Itamar >>>> >> >> -- Michael Pasternak RedHat, ENG-Virtualization R&D From asegurap at redhat.com Sun Nov 24 09:45:15 2013 From: asegurap at redhat.com (Antoni Segura Puimedon) Date: Sun, 24 Nov 2013 04:45:15 -0500 (EST) Subject: [Engine-devel] Using REST API in web UI - review call summary In-Reply-To: <5291BAC2.9010902@redhat.com> References: <1515483885.28819526.1385068697947.JavaMail.root@redhat.com> <528E7A30.7040503@redhat.com> <1590829306.28868001.1385071018139.JavaMail.root@redhat.com> <528E8279.40701@redhat.com> <5291BAC2.9010902@redhat.com> Message-ID: <1907582060.18476696.1385286315752.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Michael Pasternak" > To: "Itamar Heim" > Cc: "engine-devel" > Sent: Sunday, November 24, 2013 9:37:22 AM > Subject: Re: [Engine-devel] Using REST API in web UI - review call summary > > On 11/22/2013 12:00 AM, Itamar Heim wrote: > > On 11/21/2013 11:56 PM, Vojtech Szocs wrote: > >> > >> > >> ----- Original Message ----- > >>> From: "Itamar Heim" > >>> To: "Vojtech Szocs" , "engine-devel" > >>> > >>> Cc: "Einav Cohen" > >>> Sent: Thursday, November 21, 2013 10:25:04 PM > >>> Subject: Re: Using REST API in web UI - review call summary > >>> > >>> On 11/21/2013 11:18 PM, Vojtech Szocs wrote: > >>>> Hi guys, > >>>> > >>>> this is a summary of yesterday's review call, I'll try to highlight > >>>> important Q/A and things we agreed on. Feel free to add anything in case > >>>> I've missed something. > >>>> > >>>> -- > >>>> > >>>> Q: Why don't we simply try to use existing Java SDK and adapt it for GWT > >>>> apps? (asked by Michael & Gilad) > >>>> > >>>> A: This might be a viable option to consider if we wanted to skip > >>>> JavaScript-based SDK altogether and target Java/GWT code directly; we > >>>> could simply take Java SDK and customize its abstractions where > >>>> necessary, > >>>> i.e. using HTTP transport layer implementation that works with GWT. In > >>>> any > >>>> case, this would mean coupling ourselves to Java SDK (which has its own > >>>> release cycle) and I think this would complicate things for us. > >>>> > >>>> As proposed on the meeting, I think it's best to aim for JavaScript SDK > >>>> as > >>>> the lowest common denominator for *any* web application that wants to > >>>> work > >>>> with REST API. oVirt GWT-based UI can simply bind to JavaScript SDK, > >>>> i.e. > >>>> Java/GWT code that just overlays objects and functions provided by > >>>> JavaScript SDK. Another reason is ease of maintenance - I'd rather see > >>>> JavaScript SDK's code generation process to be independent of any other > >>>> SDK (people responsible for maintaining JavaScript SDK should have full > >>>> control over generated code). > >>>> > >>>> -- > >>>> > >>>> Q: What about functionality currently used by oVirt UI but not supported > >>>> by > >>>> REST API? (asked by Einav) > >>>> [For example, fetching VM entity over GWT RPC also returns related > >>>> data > >>>> such as Cluster name.] > >>>> > >>>> A: Based on discussion I've had with other colleagues after yesterday's > >>>> review call, I don't think that separate support-like backend layer is a > >>>> good idea. Instead, this is the kind of functionality that could be > >>>> placed > >>>> in oVirt.js library. Logical operations like "get VMs and related data" > >>>> would be exposed through oVirt.js (callback-based) API and ultimately > >>>> realized as multiple physical requests to REST API via JavaScript > >>>> Binding. > >>>> > >>>> oVirt.js client would be completely oblivious to the fact that multiple > >>>> physical requests are dispatched. In fact, since HTTP communication is > >>>> asynchronous in nature, oVirt.js client wouldn't even notice any > >>>> difference in terms of API consumption. This assumes JavaScript SDK > >>>> would > >>>> use callback-based (non-blocking) API instead of blocking one - after > >>>> all, > >>>> blocking API on top of non-blocking implementation sounds pretty much > >>>> like > >>>> leaky abstraction [1]. > >>>> > >>>> For example: > >>>> > >>>> sdk.getVmsWithExtraData( > >>>> callbackToGetExtraDataForGivenVm, // might cause extra > >>>> physical > >>>> requests to REST API > >>>> callbackFiredWhenAllDataIsReady // update client only when > >>>> all > >>>> data is ready > >>>> ) > >>> > >>> would this also resolve RunMultipleActions? > >> > >> Yes, I think so. There could be API to pass multiple "actions" and get > >> notified when they complete. > >> > >>> sounds like no reason to have RunMultipleQueries, although i'm still > >>> sure a single call to engine for multiple keys would be much more > >>> efficient than multiple async calls? > >>> (I understand we may not be able to model this). > >> > >> Efficiency-wise, yes, single call to get all data seems optimal. API-wise, > >> I don't think it really matters from oVirt.js client perspective. > >> > >> We can proceed with simple (possibly inefficient) solution and improve as > >> needed. We're making baby steps now.. > >> > >>> > >>>> > >>>> [1] http://en.wikipedia.org/wiki/Leaky_abstraction > >>>> > >>>> -- > >>>> > >>>> Last but not least, where to maintain JavaScript SDK projects: low-level > >>>> JavaScript Binding + high-level oVirt.js library. > >>>> > >>>> I agree that conceptually both above mentioned projects should go into > >>>> dedicated "ovirt-engine-sdk-js" git repository and have their own > >>>> build/release process. However, for now, we're just making baby steps so > >>>> let's keep things simple and prototype these projects as part of > >>>> "ovirt-engine" git repository. > >>>> > >>>> ... we can complicate things anytime, but we should know that any > >>>> complex > >>>> system that works has inevitably evolved from simple system that works > >>>> ... > >>>> (quote from http://en.wikipedia.org/wiki/Gall%27s_law) > >>> > >>> I think the entities should just be generated from the xsd. > >> > >> +1 > >> > >> The JavaScript Binding (aka low-level SDK) module should follow same > >> concepts as existing Java SDK - generated entities decorated with > >> operations to form fluent API. > >> > >> Everything Java SDK currently offers should be available in JavaScript > >> Binding. oVirt.js is our opportunity to build on top of that. > >> > >>> for the rsdl, makes sense to start with clean code to see what works > >>> best, then see about generating it (but you should adhere the rsdl as > >>> guidlines i guess). > >> > >> +1 > >> > >> The initial prototype should be written by hand, things will get generated > >> as soon as we have better idea how the end result should look like. > > > > i can understand that for the methods and maybe for populating the entities > > for the first few. > > the entities themselves, no point in hand coding - just generated them from > > the api.xsd. > > and once you decide how you want to fill them, not worth hand coding this - > > either json gives this out of the box, or should be generated as well. > > > >> > >>> > >>> lets try to plan for lightweight entities while at it - the API has a > >>> mechanism for different level of details - maybe we need a custom level > >>> where the client specifies which fields they want back or something like > >>> that. > >> > >> Good idea! We should definitely think about the granularity of entities. > >> > >> I didn't know REST API supports different level of detail per entity, is > >> there some documentation for this feature? > > currently it's about adding adding extra information (by supplying header > [1]), > this is driven by the properties that require extra query against the engine > to > fill them, > > obviously the default is [2] > > [1] All-Content: True > [2] All-Content: False > > >> > >> Since JavaScript is dynamic, one possible solution would be to let client > >> define the entity structure (i.e. what data client needs) on the fly, > >> during runtime :) > > we talked about this solution couple of years ago, but it was obvious > that there is no real "demand" for it till UI moves to REST, > > btw it won't solve the problem where to fill UI entity you need combination > of N REST entities, you still will have to perform N + 1 queries to API > (maybe asking for entity with fewer details), - all it address is a capacity > of the data being send. For this problem of content filtering and retrieve associated data in a "restful" way I saw Yoga http://yoga.skyscreamer.org/ some example usage: http://www.infoq.com/articles/json-yoga > > > > > michael? > > > >> > >>> > >>> Good luck, > >>> Itamar > >>> > > > > > -- > > Michael Pasternak > RedHat, ENG-Virtualization R&D > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > From iheim at redhat.com Mon Nov 25 11:10:59 2013 From: iheim at redhat.com (Itamar Heim) Date: Mon, 25 Nov 2013 13:10:59 +0200 Subject: [Engine-devel] oVirt Updates - November 2013 Message-ID: <52933043.60109@redhat.com> Case Studies - Dave Neary just published his interview with Martin Goldstone and Gary Lloyd, system administrators at the Keele university http://www.ovirt.org/Keele_University_case_study (we'd be happy to have more case studies, please contact Dave if you are willing to do one - its mostly just an interview with him) oVirt 3.3 - 3.3.1 with a slew of updates is finally out. http://www.ovirt.org/OVirt_3.3.1_release_notes - 3.3.2 beta planned once we GA 3.3.1. - sample scheduler plugins available here http://www.ovirt.org/External_Scheduler_Samples oVirt 3.4 - planning is on going, please join and help make oVirt better http://lists.ovirt.org/pipermail/users/2013-October/017451.html (clearly, only items with devel owners will make it) Conferences - Einav presented at an oVirt booth in LISA 2013 (Washington, DC) - Fosdem virt & IaaS devroom CFP[1] is open till December 1st http://bit.ly/1gMXdUH We also requested a stand/table/booth to demo oVirt (we'd love if oVirt users visiting Fosdem would volunteer to help man the stand/demo) - KVM Forum/CloudOpen sessions available http://www.ovirt.org/KVM_Forum_2013 Cross Distro - guest agent packages are now available for OpenSUSE 12.3, 13.1 and Factory, and SLES 11 SP3. (thanks Vinzenz for pushing and Ren? for testing) - Ubuntu packages pushed by Zhou Zheng Sheng. - How To: Get oVirt 3.2 All-In-One working on Scientific Linux 6.4 (With fixes!) http://bit.ly/17BstPj Related - How to manage multiple nodes with oVirt (Japanese) http://lab.space-i.com/?p=1252 - oVirt node has a new plugin, allowing it to be used for The Foreman host discovery http://www.youtube.com/watch?v=V8TugleqF64 - how to use virt-sysprep with oVirt/RHEV http://bit.ly/1hy54Xx - script to easily move VMs by name from export domain https://github.com/ppiersonbt/ovfmaker - some oVirt and Dell Equalogic issues discussions http://dell.to/1gN3TlX http://bit.ly/1cXrIH2 - Intro to oVirt on Fedora (Spanish) http://www.itrestauracion.com.ar/?p=1505 - Christophe Fergeau published libgovirt 0.3.0 (storage domains, cd-rom and certificate handling improvements) http://red.ht/HVl4U2 - helper script by Humble to print list of VMs and their nic/mac/ip http://bit.ly/1ePpMjF - Want to play with oVirt Neutron and GRE Tunneling? http://www.ovirt.org/OVirt_Neutron_GRE_Integration_-_How_To - How To: Install rhev-agents on Scientific Linux 6x http://bit.ly/1cZRydo - How To: Convert a server running on VMware ESXi 5x to oVirt 3.2 http://bit.ly/17x2X1O From gouyang at redhat.com Tue Nov 26 05:08:00 2013 From: gouyang at redhat.com (ouyang guohua) Date: Tue, 26 Nov 2013 13:08:00 +0800 Subject: [Engine-devel] failed to add host into cluster In-Reply-To: <528F5049.3090307@redhat.com> References: <307132015.5144883.1375706091754.JavaMail.root@redhat.com> <528DCD64.5010407@redhat.com> <528DE1F1.4090603@redhat.com> <528DE793.8060500@redhat.com> <528DE858.6080502@redhat.com> <528DEAE5.4030708@redhat.com> <528DF261.1020407@redhat.com> <20131122115252.GT24074@redhat.com> <528F5049.3090307@redhat.com> Message-ID: <52942CB0.30807@redhat.com> On 11/22/2013 08:38 PM, ouyang guohua wrote: > On 11/22/2013 07:52 PM, Dan Kenigsberg wrote: >> On Thu, Nov 21, 2013 at 05:22:35PM +0100, Michal Skrivanek wrote: >>>>> ok, that looks ok. Might be text parsing issue. >>>>> And "virsh capabilities" output? >>>>> what's the vdsm you're using? >>>> virsh capabilities" output is a bit long, see attachment >>>> >>>> # rpm -q vdsm >>>> vdsm-4.10.3-18.fc19.x86_64 >>> hmm, works well on my box >>> try master, though this code didn't change since 2012 >>> >>> the code in vdsm/caps.py is pretty straightforward: >>> caps = minidom.parseString(capabilities) >>> for archTag in caps.getElementsByTagName('arch'): >>> if archTag.getAttribute('name') == 'x86_64': >>> return [m.firstChild.data for m in archTag.childNodes >>> if m.nodeName == 'machine'] >>> >>> >>> try to uninstall qemu Alpha support if it changes a thing or not... >> As Michal noted, Vdsm parses the attached capabilities as it should. >> Maybe it receives something else from libvirt. Could you add some >> logging and report? >> >> diff --git a/vdsm/caps.py b/vdsm/caps.py >> index 5599522..4daca46 100644 >> --- a/vdsm/caps.py >> +++ b/vdsm/caps.py >> @@ -136,6 +136,7 @@ def _getCpuTopology(capabilities): >> def _getEmulatedMachines(capabilities=None): >> if capabilities is None: >> capabilities = _getCapsXMLStr() >> + logging.debug('caps: %s', capabilities) >> caps = minidom.parseString(capabilities) >> for archTag in caps.getElementsByTagName('arch'): >> if archTag.getAttribute('name') == 'x86_64': >> >> Maybe you can add some logging > ok, I will try it next Tuesday because I could not access the machine at > this time. my caps.py is different from above, so go to update the vdsm package, and the problem is gone after updated vdsm-4.10.3-18.fc19.x86_64 to 4.13.0-180.git5daa7fa.fc19.x86_64 # vdsClient -s 0 getVdsCaps | grep -A 15 emulatedMachines emulatedMachines = ['pc', 'q35', 'isapc', 'pc-0.10', 'pc-0.11', 'pc-0.12', 'pc-0.13', 'pc-0.14', 'pc-0.15', 'pc-1.0', 'pc-1.1', 'pc-1.2', 'pc-1.3', 'none'] guestOverhead = '65' hooks = {} so, the problem maybe exists on the old vdsm package but fixed on the new package. > > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel From mkolesni at redhat.com Tue Nov 26 06:44:34 2013 From: mkolesni at redhat.com (Mike Kolesnik) Date: Tue, 26 Nov 2013 01:44:34 -0500 (EST) Subject: [Engine-devel] Remove Comment column in main tabs In-Reply-To: <1786864902.40757991.1385448043909.JavaMail.root@redhat.com> Message-ID: <1370005434.40758795.1385448274315.JavaMail.root@redhat.com> Hi, When the comment RFE was added (in 3.3), there was also a column added to many main tabs. I would like to propose to get rid of the column (which can only house one icon or no icon), and instead if there's a comment on an entity just display the icon with the tooltip adjacent to the name. In this case the icon should probably be scaled down a bit since its huge. I think this would be a good alternative and save us some valued screen real estate. Thoughts, opinions? Regards, Mike -------------- next part -------------- An HTML attachment was scrubbed... URL: From danken at redhat.com Tue Nov 26 08:10:28 2013 From: danken at redhat.com (Dan Kenigsberg) Date: Tue, 26 Nov 2013 08:10:28 +0000 Subject: [Engine-devel] failed to add host into cluster In-Reply-To: <52942CB0.30807@redhat.com> References: <528DE1F1.4090603@redhat.com> <528DE793.8060500@redhat.com> <528DE858.6080502@redhat.com> <528DEAE5.4030708@redhat.com> <528DF261.1020407@redhat.com> <20131122115252.GT24074@redhat.com> <528F5049.3090307@redhat.com> <52942CB0.30807@redhat.com> Message-ID: <20131126081028.GA25710@redhat.com> On Tue, Nov 26, 2013 at 01:08:00PM +0800, ouyang guohua wrote: > On 11/22/2013 08:38 PM, ouyang guohua wrote: > >On 11/22/2013 07:52 PM, Dan Kenigsberg wrote: > >>On Thu, Nov 21, 2013 at 05:22:35PM +0100, Michal Skrivanek wrote: > >>>>>ok, that looks ok. Might be text parsing issue. > >>>>>And "virsh capabilities" output? > >>>>>what's the vdsm you're using? > >>>>virsh capabilities" output is a bit long, see attachment > >>>> > >>>># rpm -q vdsm > >>>>vdsm-4.10.3-18.fc19.x86_64 > > > so, the problem maybe exists on the old vdsm package but fixed on the new package. Thank Mark Wu's http://gerrit.ovirt.org/#/c/8208/! From emesika at redhat.com Tue Nov 26 09:05:37 2013 From: emesika at redhat.com (Eli Mesika) Date: Tue, 26 Nov 2013 04:05:37 -0500 (EST) Subject: [Engine-devel] Remove Comment column in main tabs In-Reply-To: <1370005434.40758795.1385448274315.JavaMail.root@redhat.com> References: <1370005434.40758795.1385448274315.JavaMail.root@redhat.com> Message-ID: <843777011.31877616.1385456737845.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Mike Kolesnik" > To: "engine-devel" > Sent: Tuesday, November 26, 2013 8:44:34 AM > Subject: [Engine-devel] Remove Comment column in main tabs > > Hi, > > When the comment RFE was added (in 3.3), there was also a column added to > many main tabs. > > I would like to propose to get rid of the column (which can only house one > icon or no icon), > and instead if there's a comment on an entity just display the icon with the > tooltip adjacent to the name. > > In this case the icon should probably be scaled down a bit since its huge. > > I think this would be a good alternative and save us some valued screen real > estate. > > Thoughts, opinions? +1 > > Regards, > Mike > > > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > From fkobzik at redhat.com Tue Nov 26 14:57:34 2013 From: fkobzik at redhat.com (Frantisek Kobzik) Date: Tue, 26 Nov 2013 09:57:34 -0500 (EST) Subject: [Engine-devel] [vdsm] Multiple graphics framebuffers - VDSM support In-Reply-To: <1442916536.18849711.1383821266707.JavaMail.root@redhat.com> References: <609587315.27211779.1385385839986.JavaMail.root@redhat.com> Message-ID: <1489098077.27937550.1385477854975.JavaMail.root@redhat.com> Hi guys, I created a wiki page with the feature: http://www.ovirt.org/Features/Multiple_Consoles It contains information about possible redesign of Engine<->VDSM communication. I'd appreciate if you take a look at it since it's not trivial change. I welcome opinions from both engine and vdsm devels. Cheers, F. ----- Original Message ----- From: "Frantisek Kobzik" To: vdsm-devel at lists.fedorahosted.org Sent: Monday, November 25, 2013 2:23:59 PM Subject: Re: [vdsm] Multiple graphics framebuffers - VDSM support Hi, it's been some time since the original mail, so I'm sending updated information. ----- Original Message ----- From: "Frantisek Kobzik" To: vdsm-devel at lists.fedorahosted.org Sent: Thursday, November 7, 2013 11:47:46 AM Subject: [vdsm] Multiple graphics framebuffers - VDSM support Dear VDSM developers, I'm working on a patch that allows running a VM with multiple graphics framebuffers. This is handy when you want to run a VM with both SPICE and VNC. It's a 3.4 feature and it will certainly need a change in vdsm. Here is a list of changes in VDSM that are needed for this funcionality: a, Sending graphics/video (engine->vdsm) - currently we send two things: 1, "display" value (qxl/vnc [wat]) - vdsm uses this for determining if the graphics server is SPICE or VNC - this attribute is not really correct - it mixes up semantics of graphic framebuffer and videocard together. I believe this attribute should only contain information about the graphics ('spice', 'vnc' or 'spice,vnc' if you want both). if this the case, do you think we should rename the attribute to, let's say, 'graphics'? Is it even possible with regard to backward compatibility? or should I reuse 'display' attribute? 2, video device (json representation of the video card) - this is correct b, Reporting graphics ports (vdsm->engine) - currently we report 2 graphic ports ('displayPort' and 'secureDisplayPort') - if we want multiple framebuffers, we must report more ports (for VNC and SPICE together that would mean 3 ports (2 for spice, one for vnc). - there are two possible solutions for this: 1, ditch 'displayPort' and 'secureDisplayPort' and add new 'spicePort', 'spiceSecurePort', 'vncPort' fields or some kind of two level dict: { protocol -> secured/unsecured -> portNumber } 2, keep 'displayPort' and 'secureDisplayPort' and introduce new 'additionalDisplayPort' This would be friendlier to backward compatibility, but it's extremely ugly because of unclear semantics of the fields (in case of SPICE+VNC 'displayPort' and 'secureDisplayPort' would be related to SPICE, 'additionalDisplayPort' would be the VNC port. In case of VNC only, the 'displayPort' would be suddendly VNC port... ewww). I'd be very happy if you share your opinion about these changes. Cheers, Franta. _______________________________________________ vdsm-devel mailing list vdsm-devel at lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel From mrao at redhat.com Tue Nov 26 16:06:17 2013 From: mrao at redhat.com (Malini Rao) Date: Tue, 26 Nov 2013 11:06:17 -0500 (EST) Subject: [Engine-devel] Remove Comment column in main tabs In-Reply-To: <843777011.31877616.1385456737845.JavaMail.root@redhat.com> References: <1370005434.40758795.1385448274315.JavaMail.root@redhat.com> <843777011.31877616.1385456737845.JavaMail.root@redhat.com> Message-ID: <575740807.31200878.1385481977247.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Eli Mesika" > To: "Mike Kolesnik" > Cc: "engine-devel" > Sent: Tuesday, November 26, 2013 4:05:37 AM > Subject: Re: [Engine-devel] Remove Comment column in main tabs > > > > ----- Original Message ----- > > From: "Mike Kolesnik" > > To: "engine-devel" > > Sent: Tuesday, November 26, 2013 8:44:34 AM > > Subject: [Engine-devel] Remove Comment column in main tabs > > > > Hi, > > > > When the comment RFE was added (in 3.3), there was also a column added to > > many main tabs. > > > > I would like to propose to get rid of the column (which can only house one > > icon or no icon), > > and instead if there's a comment on an entity just display the icon with > > the > > tooltip adjacent to the name. > > > > In this case the icon should probably be scaled down a bit since its huge. > > > > I think this would be a good alternative and save us some valued screen > > real > > estate. > > > > Thoughts, opinions? > > +1 +1. But isn't there a limitation on appending an icon to a column that already has content? Also to fully consider pros and cons - if it is possible, we have to think of where to append this icon - prefix or suffix. If we prefix, then it is likely that some names will be preceded by 2 icons because many of our lists have an icon already in the first column. If it is suffixed, the relative position on the icon will change based on how long the name is and if the object names tend to be long, then potentially, the icon is taking some room away. Also worth considering is the fact that if we prefix the icon only on the rows where it is needed, it will be in a position that will definitely grab attention. So, it may be worthwhile to see if this is the icon that we should place here or if there is any other icon that deserves this attention in a consistent manner across entities. While on the topic, it will also be a great idea IMHO to take a look at our various lists and see what columns are actually valuable for a default display. I think we are working on adding the ability to select columns for display and so the columns that we remove can be added back in by users when they want but do not sit there taking up room permanently. If anyone has ideas on what the default columns should be for one or many of the lists in our product, do send it to me. I will be willing to compile and consolidate the list and then post it back to the group for consideration. > > > > > Regards, > > Mike > > > > > > _______________________________________________ > > Engine-devel mailing list > > Engine-devel at ovirt.org > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > From ecohen at redhat.com Tue Nov 26 16:17:18 2013 From: ecohen at redhat.com (Einav Cohen) Date: Tue, 26 Nov 2013 11:17:18 -0500 (EST) Subject: [Engine-devel] Remove Comment column in main tabs In-Reply-To: <575740807.31200878.1385481977247.JavaMail.root@redhat.com> References: <1370005434.40758795.1385448274315.JavaMail.root@redhat.com> <843777011.31877616.1385456737845.JavaMail.root@redhat.com> <575740807.31200878.1385481977247.JavaMail.root@redhat.com> Message-ID: <879487894.16560459.1385482638058.JavaMail.root@redhat.com> > ----- Original Message ----- > From: "Malini Rao" > Sent: Tuesday, November 26, 2013 11:06:17 AM > > > ----- Original Message ----- > > From: "Eli Mesika" > > To: "Mike Kolesnik" > > Cc: "engine-devel" > > Sent: Tuesday, November 26, 2013 4:05:37 AM > > Subject: Re: [Engine-devel] Remove Comment column in main tabs > > > > > > > > ----- Original Message ----- > > > From: "Mike Kolesnik" > > > To: "engine-devel" > > > Sent: Tuesday, November 26, 2013 8:44:34 AM > > > Subject: [Engine-devel] Remove Comment column in main tabs > > > > > > Hi, > > > > > > When the comment RFE was added (in 3.3), there was also a column added to > > > many main tabs. > > > > > > I would like to propose to get rid of the column (which can only house > > > one > > > icon or no icon), > > > and instead if there's a comment on an entity just display the icon with > > > the > > > tooltip adjacent to the name. > > > > > > In this case the icon should probably be scaled down a bit since its > > > huge. > > > > > > I think this would be a good alternative and save us some valued screen > > > real > > > estate. > > > > > > Thoughts, opinions? > > > > +1 > > +1. But isn't there a limitation on appending an icon to a column that > already has content? Also to fully consider pros and cons - if it is > possible, we have to think of where to append this icon - prefix or suffix. > If we prefix, then it is likely that some names will be preceded by 2 icons > because many of our lists have an icon already in the first column. If it is > suffixed, the relative position on the icon will change based on how long > the name is and if the object names tend to be long, then potentially, the > icon is taking some room away. see attached two options (both comparing the current state and a suggested state in the VMs main tab) - not sure which one Mike had in mind. option #1 is easy to implement while option #2, as Malini mentioned, may be more difficult to implement. also need to keep in mind that the today, the comment column real-estate is taken mostly by the column title; therefore if we lose the title, we should indicate in some other manner that this is the comment field of the object (e.g. within the tooltip - also demonstrated in the attached). > > Also worth considering is the fact that if we prefix the icon only on the > rows where it is needed, it will be in a position that will definitely grab > attention. So, it may be worthwhile to see if this is the icon that we > should place here or if there is any other icon that deserves this attention > in a consistent manner across entities. > > While on the topic, it will also be a great idea IMHO to take a look at our > various lists and see what columns are actually valuable for a default > display. I think we are working on adding the ability to select columns for > display and so the columns that we remove can be added back in by users when > they want but do not sit there taking up room permanently. If anyone has > ideas on what the default columns should be for one or many of the lists in > our product, do send it to me. I will be willing to compile and consolidate > the list and then post it back to the group for consideration. > > > > > > > > > > > Regards, > > > Mike > > > > > > > > > _______________________________________________ > > > Engine-devel mailing list > > > Engine-devel at ovirt.org > > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > > > _______________________________________________ > > Engine-devel mailing list > > Engine-devel at ovirt.org > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > -------------- next part -------------- A non-text attachment was scrubbed... Name: move-comment-column--option-2.png Type: image/png Size: 80326 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: move-comment-column--option-1.png Type: image/png Size: 80374 bytes Desc: not available URL: From derez at redhat.com Tue Nov 26 16:24:30 2013 From: derez at redhat.com (Daniel Erez) Date: Tue, 26 Nov 2013 11:24:30 -0500 (EST) Subject: [Engine-devel] Remove Comment column in main tabs In-Reply-To: <879487894.16560459.1385482638058.JavaMail.root@redhat.com> References: <1370005434.40758795.1385448274315.JavaMail.root@redhat.com> <843777011.31877616.1385456737845.JavaMail.root@redhat.com> <575740807.31200878.1385481977247.JavaMail.root@redhat.com> <879487894.16560459.1385482638058.JavaMail.root@redhat.com> Message-ID: <134127793.41113642.1385483070675.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Einav Cohen" > To: "Malini Rao" , "Mike Kolesnik" > Cc: "engine-devel" > Sent: Tuesday, November 26, 2013 6:17:18 PM > Subject: Re: [Engine-devel] Remove Comment column in main tabs > > > ----- Original Message ----- > > From: "Malini Rao" > > Sent: Tuesday, November 26, 2013 11:06:17 AM > > > > > > ----- Original Message ----- > > > From: "Eli Mesika" > > > To: "Mike Kolesnik" > > > Cc: "engine-devel" > > > Sent: Tuesday, November 26, 2013 4:05:37 AM > > > Subject: Re: [Engine-devel] Remove Comment column in main tabs > > > > > > > > > > > > ----- Original Message ----- > > > > From: "Mike Kolesnik" > > > > To: "engine-devel" > > > > Sent: Tuesday, November 26, 2013 8:44:34 AM > > > > Subject: [Engine-devel] Remove Comment column in main tabs > > > > > > > > Hi, > > > > > > > > When the comment RFE was added (in 3.3), there was also a column added > > > > to > > > > many main tabs. > > > > > > > > I would like to propose to get rid of the column (which can only house > > > > one > > > > icon or no icon), > > > > and instead if there's a comment on an entity just display the icon > > > > with > > > > the > > > > tooltip adjacent to the name. > > > > > > > > In this case the icon should probably be scaled down a bit since its > > > > huge. > > > > > > > > I think this would be a good alternative and save us some valued screen > > > > real > > > > estate. > > > > > > > > Thoughts, opinions? > > > > > > +1 > > > > +1. But isn't there a limitation on appending an icon to a column that > > already has content? Also to fully consider pros and cons - if it is > > possible, we have to think of where to append this icon - prefix or suffix. > > If we prefix, then it is likely that some names will be preceded by 2 icons > > because many of our lists have an icon already in the first column. If it > > is > > suffixed, the relative position on the icon will change based on how long > > the name is and if the object names tend to be long, then potentially, the > > icon is taking some room away. > > see attached two options (both comparing the current state and a suggested > state in the VMs main tab) - not sure which one Mike had in mind. > option #1 is easy to implement while option #2, as Malini mentioned, may > be more difficult to implement. > also need to keep in mind that the today, the comment column real-estate is > taken mostly by the column title; therefore if we lose the title, we should > indicate in some other manner that this is the comment field of the object > (e.g. within the tooltip - also demonstrated in the attached). +1 I think that an image header might be a good solution. E.g. an image of a post-it note instead of the title. > > > > > Also worth considering is the fact that if we prefix the icon only on the > > rows where it is needed, it will be in a position that will definitely grab > > attention. So, it may be worthwhile to see if this is the icon that we > > should place here or if there is any other icon that deserves this > > attention > > in a consistent manner across entities. > > > > While on the topic, it will also be a great idea IMHO to take a look at our > > various lists and see what columns are actually valuable for a default > > display. I think we are working on adding the ability to select columns for > > display and so the columns that we remove can be added back in by users > > when > > they want but do not sit there taking up room permanently. If anyone has > > ideas on what the default columns should be for one or many of the lists in > > our product, do send it to me. I will be willing to compile and consolidate > > the list and then post it back to the group for consideration. > > > > > > > > > > > > > > > > > Regards, > > > > Mike > > > > > > > > > > > > _______________________________________________ > > > > Engine-devel mailing list > > > > Engine-devel at ovirt.org > > > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > > > > > _______________________________________________ > > > Engine-devel mailing list > > > Engine-devel at ovirt.org > > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > > > _______________________________________________ > > Engine-devel mailing list > > Engine-devel at ovirt.org > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > From ecohen at redhat.com Tue Nov 26 16:44:49 2013 From: ecohen at redhat.com (Einav Cohen) Date: Tue, 26 Nov 2013 11:44:49 -0500 (EST) Subject: [Engine-devel] Remove Comment column in main tabs In-Reply-To: <134127793.41113642.1385483070675.JavaMail.root@redhat.com> References: <1370005434.40758795.1385448274315.JavaMail.root@redhat.com> <843777011.31877616.1385456737845.JavaMail.root@redhat.com> <575740807.31200878.1385481977247.JavaMail.root@redhat.com> <879487894.16560459.1385482638058.JavaMail.root@redhat.com> <134127793.41113642.1385483070675.JavaMail.root@redhat.com> Message-ID: <851652626.16582270.1385484289757.JavaMail.root@redhat.com> > ----- Original Message ----- > From: "Daniel Erez" > Sent: Tuesday, November 26, 2013 11:24:30 AM > > > > ----- Original Message ----- > > From: "Einav Cohen" > > To: "Malini Rao" , "Mike Kolesnik" > > Cc: "engine-devel" > > Sent: Tuesday, November 26, 2013 6:17:18 PM > > Subject: Re: [Engine-devel] Remove Comment column in main tabs > > > > > ----- Original Message ----- > > > From: "Malini Rao" > > > Sent: Tuesday, November 26, 2013 11:06:17 AM > > > > > > > > > ----- Original Message ----- > > > > From: "Eli Mesika" > > > > To: "Mike Kolesnik" > > > > Cc: "engine-devel" > > > > Sent: Tuesday, November 26, 2013 4:05:37 AM > > > > Subject: Re: [Engine-devel] Remove Comment column in main tabs > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > From: "Mike Kolesnik" > > > > > To: "engine-devel" > > > > > Sent: Tuesday, November 26, 2013 8:44:34 AM > > > > > Subject: [Engine-devel] Remove Comment column in main tabs > > > > > > > > > > Hi, > > > > > > > > > > When the comment RFE was added (in 3.3), there was also a column > > > > > added > > > > > to > > > > > many main tabs. > > > > > > > > > > I would like to propose to get rid of the column (which can only > > > > > house > > > > > one > > > > > icon or no icon), > > > > > and instead if there's a comment on an entity just display the icon > > > > > with > > > > > the > > > > > tooltip adjacent to the name. > > > > > > > > > > In this case the icon should probably be scaled down a bit since its > > > > > huge. > > > > > > > > > > I think this would be a good alternative and save us some valued > > > > > screen > > > > > real > > > > > estate. > > > > > > > > > > Thoughts, opinions? > > > > > > > > +1 > > > > > > +1. But isn't there a limitation on appending an icon to a column that > > > already has content? Also to fully consider pros and cons - if it is > > > possible, we have to think of where to append this icon - prefix or > > > suffix. > > > If we prefix, then it is likely that some names will be preceded by 2 > > > icons > > > because many of our lists have an icon already in the first column. If it > > > is > > > suffixed, the relative position on the icon will change based on how long > > > the name is and if the object names tend to be long, then potentially, > > > the > > > icon is taking some room away. > > > > see attached two options (both comparing the current state and a suggested > > state in the VMs main tab) - not sure which one Mike had in mind. > > option #1 is easy to implement while option #2, as Malini mentioned, may > > be more difficult to implement. > > also need to keep in mind that the today, the comment column real-estate is > > taken mostly by the column title; therefore if we lose the title, we should > > indicate in some other manner that this is the comment field of the object > > (e.g. within the tooltip - also demonstrated in the attached). > > +1 > I think that an image header might be a good solution. > E.g. an image of a post-it note instead of the title. good idea - we can display a "comment" tool-tip when hovering on the title-icon and, like today, display only the comment value within the tool-tip when hovering on the regular-row-icon (see attached). [we already have icon-column-titles in the application, e.g. "shareable", "bootable" in the Disks grid, so it shouldn't be hard to implement] > > > > > > > > > Also worth considering is the fact that if we prefix the icon only on the > > > rows where it is needed, it will be in a position that will definitely > > > grab > > > attention. So, it may be worthwhile to see if this is the icon that we > > > should place here or if there is any other icon that deserves this > > > attention > > > in a consistent manner across entities. > > > > > > While on the topic, it will also be a great idea IMHO to take a look at > > > our > > > various lists and see what columns are actually valuable for a default > > > display. I think we are working on adding the ability to select columns > > > for > > > display and so the columns that we remove can be added back in by users > > > when > > > they want but do not sit there taking up room permanently. If anyone has > > > ideas on what the default columns should be for one or many of the lists > > > in > > > our product, do send it to me. I will be willing to compile and > > > consolidate > > > the list and then post it back to the group for consideration. > > > > > > > > > > > > > > > > > > > > > > > Regards, > > > > > Mike > > > > > > > > > > > > > > > _______________________________________________ > > > > > Engine-devel mailing list > > > > > Engine-devel at ovirt.org > > > > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > > > > > > > _______________________________________________ > > > > Engine-devel mailing list > > > > Engine-devel at ovirt.org > > > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > > > > > _______________________________________________ > > > Engine-devel mailing list > > > Engine-devel at ovirt.org > > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > > > > > _______________________________________________ > > Engine-devel mailing list > > Engine-devel at ovirt.org > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > -------------- next part -------------- A non-text attachment was scrubbed... Name: move-comment-column--option-1-improved.png Type: image/png Size: 81567 bytes Desc: not available URL: From mrao at redhat.com Tue Nov 26 19:54:00 2013 From: mrao at redhat.com (Malini Rao) Date: Tue, 26 Nov 2013 14:54:00 -0500 (EST) Subject: [Engine-devel] Remove Comment column in main tabs In-Reply-To: <851652626.16582270.1385484289757.JavaMail.root@redhat.com> References: <1370005434.40758795.1385448274315.JavaMail.root@redhat.com> <843777011.31877616.1385456737845.JavaMail.root@redhat.com> <575740807.31200878.1385481977247.JavaMail.root@redhat.com> <879487894.16560459.1385482638058.JavaMail.root@redhat.com> <134127793.41113642.1385483070675.JavaMail.root@redhat.com> <851652626.16582270.1385484289757.JavaMail.root@redhat.com> Message-ID: <246185107.31436601.1385495640948.JavaMail.root@redhat.com> This could work but I am not a big fan of simply adding iconic columns preceding the name. This is actually a good example where 2 icon columns are already there and adding another column is making the primary column ( i.e the name column) not seem like the first column the eye focuses on. I understand that it is not as easy implementation-wise but in the effort to start moving towards a more elegant solution, I am wondering if we can cash in on what users may have learned in spreadsheet software and use a dog ear image at the corner of the name cell ( See attached). This way, we are not dedicating any more space and it does not take away space allotted to the text string either. The visual details of the icon are not final and this is sent to communicate an idea only. If we agree on this, I will send the final icon to use. Thoughts? -Malini ----- Original Message ----- From: "Einav Cohen" To: "Daniel Erez" Cc: "Malini Rao" , "Mike Kolesnik" , "engine-devel" Sent: Tuesday, November 26, 2013 11:44:49 AM Subject: Re: [Engine-devel] Remove Comment column in main tabs > ----- Original Message ----- > From: "Daniel Erez" > Sent: Tuesday, November 26, 2013 11:24:30 AM > > > > ----- Original Message ----- > > From: "Einav Cohen" > > To: "Malini Rao" , "Mike Kolesnik" > > Cc: "engine-devel" > > Sent: Tuesday, November 26, 2013 6:17:18 PM > > Subject: Re: [Engine-devel] Remove Comment column in main tabs > > > > > ----- Original Message ----- > > > From: "Malini Rao" > > > Sent: Tuesday, November 26, 2013 11:06:17 AM > > > > > > > > > ----- Original Message ----- > > > > From: "Eli Mesika" > > > > To: "Mike Kolesnik" > > > > Cc: "engine-devel" > > > > Sent: Tuesday, November 26, 2013 4:05:37 AM > > > > Subject: Re: [Engine-devel] Remove Comment column in main tabs > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > From: "Mike Kolesnik" > > > > > To: "engine-devel" > > > > > Sent: Tuesday, November 26, 2013 8:44:34 AM > > > > > Subject: [Engine-devel] Remove Comment column in main tabs > > > > > > > > > > Hi, > > > > > > > > > > When the comment RFE was added (in 3.3), there was also a column > > > > > added > > > > > to > > > > > many main tabs. > > > > > > > > > > I would like to propose to get rid of the column (which can only > > > > > house > > > > > one > > > > > icon or no icon), > > > > > and instead if there's a comment on an entity just display the icon > > > > > with > > > > > the > > > > > tooltip adjacent to the name. > > > > > > > > > > In this case the icon should probably be scaled down a bit since its > > > > > huge. > > > > > > > > > > I think this would be a good alternative and save us some valued > > > > > screen > > > > > real > > > > > estate. > > > > > > > > > > Thoughts, opinions? > > > > > > > > +1 > > > > > > +1. But isn't there a limitation on appending an icon to a column that > > > already has content? Also to fully consider pros and cons - if it is > > > possible, we have to think of where to append this icon - prefix or > > > suffix. > > > If we prefix, then it is likely that some names will be preceded by 2 > > > icons > > > because many of our lists have an icon already in the first column. If it > > > is > > > suffixed, the relative position on the icon will change based on how long > > > the name is and if the object names tend to be long, then potentially, > > > the > > > icon is taking some room away. > > > > see attached two options (both comparing the current state and a suggested > > state in the VMs main tab) - not sure which one Mike had in mind. > > option #1 is easy to implement while option #2, as Malini mentioned, may > > be more difficult to implement. > > also need to keep in mind that the today, the comment column real-estate is > > taken mostly by the column title; therefore if we lose the title, we should > > indicate in some other manner that this is the comment field of the object > > (e.g. within the tooltip - also demonstrated in the attached). > > +1 > I think that an image header might be a good solution. > E.g. an image of a post-it note instead of the title. good idea - we can display a "comment" tool-tip when hovering on the title-icon and, like today, display only the comment value within the tool-tip when hovering on the regular-row-icon (see attached). [we already have icon-column-titles in the application, e.g. "shareable", "bootable" in the Disks grid, so it shouldn't be hard to implement] > > > > > > > > > Also worth considering is the fact that if we prefix the icon only on the > > > rows where it is needed, it will be in a position that will definitely > > > grab > > > attention. So, it may be worthwhile to see if this is the icon that we > > > should place here or if there is any other icon that deserves this > > > attention > > > in a consistent manner across entities. > > > > > > While on the topic, it will also be a great idea IMHO to take a look at > > > our > > > various lists and see what columns are actually valuable for a default > > > display. I think we are working on adding the ability to select columns > > > for > > > display and so the columns that we remove can be added back in by users > > > when > > > they want but do not sit there taking up room permanently. If anyone has > > > ideas on what the default columns should be for one or many of the lists > > > in > > > our product, do send it to me. I will be willing to compile and > > > consolidate > > > the list and then post it back to the group for consideration. > > > > > > > > > > > > > > > > > > > > > > > Regards, > > > > > Mike > > > > > > > > > > > > > > > _______________________________________________ > > > > > Engine-devel mailing list > > > > > Engine-devel at ovirt.org > > > > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > > > > > > > _______________________________________________ > > > > Engine-devel mailing list > > > > Engine-devel at ovirt.org > > > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > > > > > _______________________________________________ > > > Engine-devel mailing list > > > Engine-devel at ovirt.org > > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > > > > > _______________________________________________ > > Engine-devel mailing list > > Engine-devel at ovirt.org > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > -------------- next part -------------- A non-text attachment was scrubbed... Name: Comments.png Type: image/png Size: 103994 bytes Desc: not available URL: From ecohen at redhat.com Tue Nov 26 21:19:55 2013 From: ecohen at redhat.com (Einav Cohen) Date: Tue, 26 Nov 2013 16:19:55 -0500 (EST) Subject: [Engine-devel] Remove Comment column in main tabs In-Reply-To: <246185107.31436601.1385495640948.JavaMail.root@redhat.com> References: <1370005434.40758795.1385448274315.JavaMail.root@redhat.com> <843777011.31877616.1385456737845.JavaMail.root@redhat.com> <575740807.31200878.1385481977247.JavaMail.root@redhat.com> <879487894.16560459.1385482638058.JavaMail.root@redhat.com> <134127793.41113642.1385483070675.JavaMail.root@redhat.com> <851652626.16582270.1385484289757.JavaMail.root@redhat.com> <246185107.31436601.1385495640948.JavaMail.root@redhat.com> Message-ID: <128970096.16796135.1385500794982.JavaMail.root@redhat.com> Hi Malini, > This could work but I am not a big fan of simply adding iconic columns > preceding the name. This is actually a good example where 2 icon columns are > already there and adding another column is making the primary column ( i.e > the name column) not seem like the first column the eye focuses on. not sure that I completely agree with that: if I am taking my e-mail client, for example - it has a lot of icon columns that precede the primary columns ('From', 'Subject'), however I don't think that it makes the primary columns any less 'catchy' (see attached 'e-mail-client--a-lot-of-preceding-icons.png'). Having said that - it may depend on the actual content of the icon columns (i.e. in my e-mail example, the icon-columns are mostly empty, whereas in the VMs main tab example, at least the 'status' and 'vm-type' icon columns are expected to always contain some icon), so not sure. > I understand that it is not as easy implementation-wise but in the effort to > start moving towards a more elegant solution, I am wondering if we can cash > in on what users may have learned in spreadsheet software and use a dog ear > image at the corner of the name cell ( See attached). This way, we are not > dedicating any more space and it does not take away space allotted to the > text string either. The visual details of the icon are not final and this is > sent to communicate an idea only. If we agree on this, I will send the final > icon to use. this solution is nice and elegant - I like it; my main concern is that I am not sure how will we be able to sort the items by that field if we won't have a dedicated column for it (once column sorting will be available in general, of course). my other concern is indeed the implementation effort that would need to be involved in it. Question is if it is something that is worth considering if we decide that the extra-icon-column solution is acceptable. Another option (at least for the short term) for solving the real-estate problem without changing anything in the primary column area is to keep the 'Comment' column in its current location, only replace its textual title with an icon title (see attached 'move-comment-column--option-1-variation.png'). > > Thoughts? > > -Malini > > ----- Original Message ----- > From: "Einav Cohen" > To: "Daniel Erez" > Cc: "Malini Rao" , "Mike Kolesnik" , > "engine-devel" > Sent: Tuesday, November 26, 2013 11:44:49 AM > Subject: Re: [Engine-devel] Remove Comment column in main tabs > > > ----- Original Message ----- > > From: "Daniel Erez" > > Sent: Tuesday, November 26, 2013 11:24:30 AM > > > > > > > > ----- Original Message ----- > > > From: "Einav Cohen" > > > To: "Malini Rao" , "Mike Kolesnik" > > > Cc: "engine-devel" > > > Sent: Tuesday, November 26, 2013 6:17:18 PM > > > Subject: Re: [Engine-devel] Remove Comment column in main tabs > > > > > > > ----- Original Message ----- > > > > From: "Malini Rao" > > > > Sent: Tuesday, November 26, 2013 11:06:17 AM > > > > > > > > > > > > ----- Original Message ----- > > > > > From: "Eli Mesika" > > > > > To: "Mike Kolesnik" > > > > > Cc: "engine-devel" > > > > > Sent: Tuesday, November 26, 2013 4:05:37 AM > > > > > Subject: Re: [Engine-devel] Remove Comment column in main tabs > > > > > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > From: "Mike Kolesnik" > > > > > > To: "engine-devel" > > > > > > Sent: Tuesday, November 26, 2013 8:44:34 AM > > > > > > Subject: [Engine-devel] Remove Comment column in main tabs > > > > > > > > > > > > Hi, > > > > > > > > > > > > When the comment RFE was added (in 3.3), there was also a column > > > > > > added > > > > > > to > > > > > > many main tabs. > > > > > > > > > > > > I would like to propose to get rid of the column (which can only > > > > > > house > > > > > > one > > > > > > icon or no icon), > > > > > > and instead if there's a comment on an entity just display the icon > > > > > > with > > > > > > the > > > > > > tooltip adjacent to the name. > > > > > > > > > > > > In this case the icon should probably be scaled down a bit since > > > > > > its > > > > > > huge. > > > > > > > > > > > > I think this would be a good alternative and save us some valued > > > > > > screen > > > > > > real > > > > > > estate. > > > > > > > > > > > > Thoughts, opinions? > > > > > > > > > > +1 > > > > > > > > +1. But isn't there a limitation on appending an icon to a column that > > > > already has content? Also to fully consider pros and cons - if it is > > > > possible, we have to think of where to append this icon - prefix or > > > > suffix. > > > > If we prefix, then it is likely that some names will be preceded by 2 > > > > icons > > > > because many of our lists have an icon already in the first column. If > > > > it > > > > is > > > > suffixed, the relative position on the icon will change based on how > > > > long > > > > the name is and if the object names tend to be long, then potentially, > > > > the > > > > icon is taking some room away. > > > > > > see attached two options (both comparing the current state and a > > > suggested > > > state in the VMs main tab) - not sure which one Mike had in mind. > > > option #1 is easy to implement while option #2, as Malini mentioned, may > > > be more difficult to implement. > > > also need to keep in mind that the today, the comment column real-estate > > > is > > > taken mostly by the column title; therefore if we lose the title, we > > > should > > > indicate in some other manner that this is the comment field of the > > > object > > > (e.g. within the tooltip - also demonstrated in the attached). > > > > +1 > > I think that an image header might be a good solution. > > E.g. an image of a post-it note instead of the title. > > good idea - we can display a "comment" tool-tip when hovering on the > title-icon > and, like today, display only the comment value within the tool-tip when > hovering > on the regular-row-icon (see attached). > [we already have icon-column-titles in the application, e.g. "shareable", > "bootable" > in the Disks grid, so it shouldn't be hard to implement] > > > > > > > > > > > > > > Also worth considering is the fact that if we prefix the icon only on > > > > the > > > > rows where it is needed, it will be in a position that will definitely > > > > grab > > > > attention. So, it may be worthwhile to see if this is the icon that we > > > > should place here or if there is any other icon that deserves this > > > > attention > > > > in a consistent manner across entities. > > > > > > > > While on the topic, it will also be a great idea IMHO to take a look at > > > > our > > > > various lists and see what columns are actually valuable for a default > > > > display. I think we are working on adding the ability to select columns > > > > for > > > > display and so the columns that we remove can be added back in by users > > > > when > > > > they want but do not sit there taking up room permanently. If anyone > > > > has > > > > ideas on what the default columns should be for one or many of the > > > > lists > > > > in > > > > our product, do send it to me. I will be willing to compile and > > > > consolidate > > > > the list and then post it back to the group for consideration. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Regards, > > > > > > Mike > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > Engine-devel mailing list > > > > > > Engine-devel at ovirt.org > > > > > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > > > > > > > > > _______________________________________________ > > > > > Engine-devel mailing list > > > > > Engine-devel at ovirt.org > > > > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > > > > > > > _______________________________________________ > > > > Engine-devel mailing list > > > > Engine-devel at ovirt.org > > > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > > > > > > > > _______________________________________________ > > > Engine-devel mailing list > > > Engine-devel at ovirt.org > > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > > > > > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > -------------- next part -------------- A non-text attachment was scrubbed... Name: e-mail-client--a-lot-of-preceding-icons.png Type: image/png Size: 138442 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: move-comment-column--option-1-variation.png Type: image/png Size: 81392 bytes Desc: not available URL: From mrao at redhat.com Tue Nov 26 22:03:44 2013 From: mrao at redhat.com (Malini Rao) Date: Tue, 26 Nov 2013 17:03:44 -0500 (EST) Subject: [Engine-devel] Remove Comment column in main tabs In-Reply-To: <128970096.16796135.1385500794982.JavaMail.root@redhat.com> References: <1370005434.40758795.1385448274315.JavaMail.root@redhat.com> <843777011.31877616.1385456737845.JavaMail.root@redhat.com> <575740807.31200878.1385481977247.JavaMail.root@redhat.com> <879487894.16560459.1385482638058.JavaMail.root@redhat.com> <134127793.41113642.1385483070675.JavaMail.root@redhat.com> <851652626.16582270.1385484289757.JavaMail.root@redhat.com> <246185107.31436601.1385495640948.JavaMail.root@redhat.com> <128970096.16796135.1385500794982.JavaMail.root@redhat.com> Message-ID: <319931619.31531966.1385503424736.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Einav Cohen" > To: "Malini Rao" > Cc: "engine-devel" > Sent: Tuesday, November 26, 2013 4:19:55 PM > Subject: Re: [Engine-devel] Remove Comment column in main tabs > > Hi Malini, > > > This could work but I am not a big fan of simply adding iconic columns > > preceding the name. This is actually a good example where 2 icon columns > > are > > already there and adding another column is making the primary column ( i.e > > the name column) not seem like the first column the eye focuses on. > > not sure that I completely agree with that: if I am taking my e-mail client, > for example - it has a lot of icon columns that precede the primary columns > ('From', 'Subject'), however I don't think that it makes the primary columns > any less 'catchy' (see attached > 'e-mail-client--a-lot-of-preceding-icons.png'). > Having said that - it may depend on the actual content of the icon columns > (i.e. in my e-mail example, the icon-columns are mostly empty, whereas in the > VMs main tab example, at least the 'status' and 'vm-type' icon columns are > expected to always contain some icon), so not sure. Einav, I do take your point. That said, I don't think the screenshot you sent me would be considered a good example of something well designed - at least not in terms of the number of columns with icons. Also, it kind of works because the subject column which is possibly what the user will focus on is the widest. > > > I understand that it is not as easy implementation-wise but in the effort > > to > > start moving towards a more elegant solution, I am wondering if we can cash > > in on what users may have learned in spreadsheet software and use a dog ear > > image at the corner of the name cell ( See attached). This way, we are not > > dedicating any more space and it does not take away space allotted to the > > text string either. The visual details of the icon are not final and this > > is > > sent to communicate an idea only. If we agree on this, I will send the > > final > > icon to use. > > this solution is nice and elegant - I like it; > my main concern is that I am not sure how will we be able to sort the items > by that field if we won't have a dedicated column for it (once column sorting > will be available in general, of course). That is a good point. I guess the question is if sorting will be necessary on comments since it is available on hover only anyway and I am not sure an alphabetical sort would be very useful in finding a particular comment. In general, once we have that feature, it may be worthwhile to consider what columns need sorting and not necessarily have every available column in the list have that ability. What could be useful in this case is to sort by all the rows that do have a comment on them and that could potentially be incorporated into the sort sequence - for e.g, unsorted, alphanumeric Asc,alphanumeric desc, presence of comment on top, unsorted. > my other concern is indeed the implementation effort that would need to be > involved in it. > > Question is if it is something that is worth considering if we decide that > the > extra-icon-column solution is acceptable. The extra-icon-column solution is not whacky or unacceptable but it creates these empty spaces or tiled patterns depending on whether it is filled or not and it also takes up space all the time. > > Another option (at least for the short term) for solving the real-estate > problem > without changing anything in the primary column area is to keep the 'Comment' > column in its current location, only replace its textual title with an icon > title > (see attached 'move-comment-column--option-1-variation.png'). I was thinking along these lines as well. Maybe if we decide not to implement the recommendation I sent earlier, we could move the comment column to display after the name column. This way it is not lost at the very end esp because its presence is known only via a small icon. If the comment is relatively unimportant, then I think it would be reasonable to leave it where it is today. > > > > > Thoughts? > > > > -Malini > > > > ----- Original Message ----- > > From: "Einav Cohen" > > To: "Daniel Erez" > > Cc: "Malini Rao" , "Mike Kolesnik" , > > "engine-devel" > > Sent: Tuesday, November 26, 2013 11:44:49 AM > > Subject: Re: [Engine-devel] Remove Comment column in main tabs > > > > > ----- Original Message ----- > > > From: "Daniel Erez" > > > Sent: Tuesday, November 26, 2013 11:24:30 AM > > > > > > > > > > > > ----- Original Message ----- > > > > From: "Einav Cohen" > > > > To: "Malini Rao" , "Mike Kolesnik" > > > > > > > > Cc: "engine-devel" > > > > Sent: Tuesday, November 26, 2013 6:17:18 PM > > > > Subject: Re: [Engine-devel] Remove Comment column in main tabs > > > > > > > > > ----- Original Message ----- > > > > > From: "Malini Rao" > > > > > Sent: Tuesday, November 26, 2013 11:06:17 AM > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > From: "Eli Mesika" > > > > > > To: "Mike Kolesnik" > > > > > > Cc: "engine-devel" > > > > > > Sent: Tuesday, November 26, 2013 4:05:37 AM > > > > > > Subject: Re: [Engine-devel] Remove Comment column in main tabs > > > > > > > > > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > From: "Mike Kolesnik" > > > > > > > To: "engine-devel" > > > > > > > Sent: Tuesday, November 26, 2013 8:44:34 AM > > > > > > > Subject: [Engine-devel] Remove Comment column in main tabs > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > When the comment RFE was added (in 3.3), there was also a column > > > > > > > added > > > > > > > to > > > > > > > many main tabs. > > > > > > > > > > > > > > I would like to propose to get rid of the column (which can only > > > > > > > house > > > > > > > one > > > > > > > icon or no icon), > > > > > > > and instead if there's a comment on an entity just display the > > > > > > > icon > > > > > > > with > > > > > > > the > > > > > > > tooltip adjacent to the name. > > > > > > > > > > > > > > In this case the icon should probably be scaled down a bit since > > > > > > > its > > > > > > > huge. > > > > > > > > > > > > > > I think this would be a good alternative and save us some valued > > > > > > > screen > > > > > > > real > > > > > > > estate. > > > > > > > > > > > > > > Thoughts, opinions? > > > > > > > > > > > > +1 > > > > > > > > > > +1. But isn't there a limitation on appending an icon to a column > > > > > that > > > > > already has content? Also to fully consider pros and cons - if it is > > > > > possible, we have to think of where to append this icon - prefix or > > > > > suffix. > > > > > If we prefix, then it is likely that some names will be preceded by 2 > > > > > icons > > > > > because many of our lists have an icon already in the first column. > > > > > If > > > > > it > > > > > is > > > > > suffixed, the relative position on the icon will change based on how > > > > > long > > > > > the name is and if the object names tend to be long, then > > > > > potentially, > > > > > the > > > > > icon is taking some room away. > > > > > > > > see attached two options (both comparing the current state and a > > > > suggested > > > > state in the VMs main tab) - not sure which one Mike had in mind. > > > > option #1 is easy to implement while option #2, as Malini mentioned, > > > > may > > > > be more difficult to implement. > > > > also need to keep in mind that the today, the comment column > > > > real-estate > > > > is > > > > taken mostly by the column title; therefore if we lose the title, we > > > > should > > > > indicate in some other manner that this is the comment field of the > > > > object > > > > (e.g. within the tooltip - also demonstrated in the attached). > > > > > > +1 > > > I think that an image header might be a good solution. > > > E.g. an image of a post-it note instead of the title. > > > > good idea - we can display a "comment" tool-tip when hovering on the > > title-icon > > and, like today, display only the comment value within the tool-tip when > > hovering > > on the regular-row-icon (see attached). > > [we already have icon-column-titles in the application, e.g. "shareable", > > "bootable" > > in the Disks grid, so it shouldn't be hard to implement] > > > > > > > > > > > > > > > > > > > Also worth considering is the fact that if we prefix the icon only on > > > > > the > > > > > rows where it is needed, it will be in a position that will > > > > > definitely > > > > > grab > > > > > attention. So, it may be worthwhile to see if this is the icon that > > > > > we > > > > > should place here or if there is any other icon that deserves this > > > > > attention > > > > > in a consistent manner across entities. > > > > > > > > > > While on the topic, it will also be a great idea IMHO to take a look > > > > > at > > > > > our > > > > > various lists and see what columns are actually valuable for a > > > > > default > > > > > display. I think we are working on adding the ability to select > > > > > columns > > > > > for > > > > > display and so the columns that we remove can be added back in by > > > > > users > > > > > when > > > > > they want but do not sit there taking up room permanently. If anyone > > > > > has > > > > > ideas on what the default columns should be for one or many of the > > > > > lists > > > > > in > > > > > our product, do send it to me. I will be willing to compile and > > > > > consolidate > > > > > the list and then post it back to the group for consideration. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Regards, > > > > > > > Mike > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > Engine-devel mailing list > > > > > > > Engine-devel at ovirt.org > > > > > > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > > > > > > > > > > > _______________________________________________ > > > > > > Engine-devel mailing list > > > > > > Engine-devel at ovirt.org > > > > > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > > > > > > > > > _______________________________________________ > > > > > Engine-devel mailing list > > > > > Engine-devel at ovirt.org > > > > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > > > > > > > > > > > _______________________________________________ > > > > Engine-devel mailing list > > > > Engine-devel at ovirt.org > > > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > > > > > > > > > _______________________________________________ > > Engine-devel mailing list > > Engine-devel at ovirt.org > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > From mkolesni at redhat.com Wed Nov 27 05:56:15 2013 From: mkolesni at redhat.com (Mike Kolesnik) Date: Wed, 27 Nov 2013 00:56:15 -0500 (EST) Subject: [Engine-devel] Remove Comment column in main tabs In-Reply-To: <128970096.16796135.1385500794982.JavaMail.root@redhat.com> References: <1370005434.40758795.1385448274315.JavaMail.root@redhat.com> <843777011.31877616.1385456737845.JavaMail.root@redhat.com> <575740807.31200878.1385481977247.JavaMail.root@redhat.com> <879487894.16560459.1385482638058.JavaMail.root@redhat.com> <134127793.41113642.1385483070675.JavaMail.root@redhat.com> <851652626.16582270.1385484289757.JavaMail.root@redhat.com> <246185107.31436601.1385495640948.JavaMail.root@redhat.com> <128970096.16796135.1385500794982.JavaMail.root@redhat.com> Message-ID: <1080230437.41446520.1385531775825.JavaMail.root@redhat.com> ----- Original Message ----- > Hi Malini, > > > This could work but I am not a big fan of simply adding iconic columns > > preceding the name. This is actually a good example where 2 icon columns > > are > > already there and adding another column is making the primary column ( i.e > > the name column) not seem like the first column the eye focuses on. > > not sure that I completely agree with that: if I am taking my e-mail client, > for example - it has a lot of icon columns that precede the primary columns > ('From', 'Subject'), however I don't think that it makes the primary columns > any less 'catchy' (see attached > 'e-mail-client--a-lot-of-preceding-icons.png'). > Having said that - it may depend on the actual content of the icon columns > (i.e. in my e-mail example, the icon-columns are mostly empty, whereas in the > VMs main tab example, at least the 'status' and 'vm-type' icon columns are > expected to always contain some icon), so not sure. Leaving obscure open source email clients aside ;), gmail also has icon columns, although without any title or boundaries but visually it looks like a column.. > > > I understand that it is not as easy implementation-wise but in the effort > > to > > start moving towards a more elegant solution, I am wondering if we can cash > > in on what users may have learned in spreadsheet software and use a dog ear > > image at the corner of the name cell ( See attached). This way, we are not > > dedicating any more space and it does not take away space allotted to the > > text string either. The visual details of the icon are not final and this > > is > > sent to communicate an idea only. If we agree on this, I will send the > > final > > icon to use. > > this solution is nice and elegant - I like it; > my main concern is that I am not sure how will we be able to sort the items > by that field if we won't have a dedicated column for it (once column sorting > will be available in general, of course). > my other concern is indeed the implementation effort that would need to be > involved in it. Not sure how interesting it is to sort by comment, but for the sake of not blocking it - a dedicated (small) column seems good to me. > > Question is if it is something that is worth considering if we decide that > the > extra-icon-column solution is acceptable. > > Another option (at least for the short term) for solving the real-estate > problem > without changing anything in the primary column area is to keep the 'Comment' > column in its current location, only replace its textual title with an icon > title > (see attached 'move-comment-column--option-1-variation.png'). > I think if the comment is among the first to appear it serves it's purpose better since the admin can clearly see that someone left a comment there and pay attention to it, whereas if it's on the far side it can easily be missed (or even hidden on a lower res screen). P.S. I think icon columns should probably be non-resizeable as it really makes no sense to resize them (they have a minimum width anyway). From sbonazzo at redhat.com Wed Nov 27 10:29:43 2013 From: sbonazzo at redhat.com (Sandro Bonazzola) Date: Wed, 27 Nov 2013 11:29:43 +0100 Subject: [Engine-devel] [QE] oVirt 3.3.2 beta status Message-ID: <5295C997.8000000@redhat.com> Hi, we're going to branch and build oVirt 3.3.2 beta TODAY. A bug tracker is available at [1] and it shows only 3 bugs still blocking the release: Whiteboard Bug ID Summary storage 1022961 Running a VM from a gluster domain uses mount instead of gluster URI virt 1025829 sysprep floppy is not attached to Windows 2008 R2 machine - even when specifically checked in Run Once virt 1029885 cloud-init testcase does not work in engine 3.3.1 Please provide an ETA for the above bugs. The following is a list of the non-blocking bugs still open with target 3.3.2: Whiteboard Bug ID Summary infra 1017267 Plaintext user passwords in async_tasks database infra 987982 When adding a host through the REST API, the error message says that "rootPassword" is required,... infra 1020344 Power Managent with cisco_ucs problem integration 1022440 AIO - configure the AIO host to be a gluster cluster/host integration 902979 ovirt-live - firefox doesn't trust the installed engine integration 1021805 oVirt Live - use motd to show the admin password integration 1026930 Package virtio-win and put it in ovirt repositories integration 1026933 pre-populate ISO domain with virtio-win ISO network 1019818 Support OpenStack Havana layer 2 agent integration network 987999 [oVirt] [provider] Add button shouldn't appear on specific provider network 987916 [oVirt] [provider] Dialog doesn't update unless focus lost network 906313 [oVirt-webadmin] [setupNetworks] "No valid Operation for and Unassigned Logical Networks panel" network 1023722 [oVirt-webadmin][network] Network roles in cluster management should be radio buttons network 997197 Some AppErrors messages are grammatically incorrect (singular vs plural) storage 1029069 Live storage migration snapshot removal fails, probably due to unexpected qemu-img output storage 987917 [oVirt] [glance] API version not specified in provider dialog storage 1016118 async between masterVersion : can't connect to StoragePool ux 906394 [oVirt-webadmin] [network] Loading animation in network main tab 'hosts' and 'vms' subtab is stuck on first view... virt 1007940 Cannot clone from snapshot while using GlusterFS as POSIX Storage Domain Please add the bugs to the tracker if you think that 3.3.2 should not be released without them fixed. For those who want to help testing the bugs, I suggest to add yourself as QA contact for the bug and add yourself to the testing page [2]. Maintainers are welcomed to start filling release notes, the page has been created here [3] [1] https://bugzilla.redhat.com/1027349 [2] http://www.ovirt.org/Testing/Ovirt_3.3.2_testing [3] http://www.ovirt.org/OVirt_3.3.2_release_notes Thanks, -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com From alonbl at redhat.com Wed Nov 27 10:32:58 2013 From: alonbl at redhat.com (Alon Bar-Lev) Date: Wed, 27 Nov 2013 05:32:58 -0500 (EST) Subject: [Engine-devel] [QE] oVirt 3.3.2 beta status In-Reply-To: <5295C997.8000000@redhat.com> References: <5295C997.8000000@redhat.com> Message-ID: <1502472084.19548589.1385548378697.JavaMail.root@redhat.com> Please wait for this[1], to downgrade the apache-sshd for users. [1] http://gerrit.ovirt.org/#/c/21769/ ----- Original Message ----- > From: "Sandro Bonazzola" > To: "engine-devel" , Users at ovirt.org, "vdsm-devel" > Sent: Wednesday, November 27, 2013 12:29:43 PM > Subject: [Engine-devel] [QE] oVirt 3.3.2 beta status > > Hi, > > we're going to branch and build oVirt 3.3.2 beta TODAY. > A bug tracker is available at [1] and it shows only 3 bugs still blocking the > release: > > Whiteboard Bug ID Summary > storage 1022961 Running a VM from a gluster domain uses mount instead of > gluster URI > virt 1025829 sysprep floppy is not attached to Windows 2008 R2 machine - even > when specifically checked in Run Once > virt 1029885 cloud-init testcase does not work in engine 3.3.1 > > Please provide an ETA for the above bugs. > > > The following is a list of the non-blocking bugs still open with target > 3.3.2: > > Whiteboard Bug ID Summary > infra 1017267 Plaintext user passwords in async_tasks database > infra 987982 When adding a host through the REST API, the error message says > that "rootPassword" is required,... > infra 1020344 Power Managent with cisco_ucs problem > integration 1022440 AIO - configure the AIO host to be a gluster cluster/host > integration 902979 ovirt-live - firefox doesn't trust the installed engine > integration 1021805 oVirt Live - use motd to show the admin password > integration 1026930 Package virtio-win and put it in ovirt repositories > integration 1026933 pre-populate ISO domain with virtio-win ISO > network 1019818 Support OpenStack Havana layer 2 agent integration > network 987999 [oVirt] [provider] Add button shouldn't appear on specific > provider > network 987916 [oVirt] [provider] Dialog doesn't update unless focus lost > network 906313 [oVirt-webadmin] [setupNetworks] "No valid Operation for > and Unassigned Logical Networks panel" > network 1023722 [oVirt-webadmin][network] Network roles in cluster > management should be radio buttons > network 997197 Some AppErrors messages are grammatically incorrect (singular > vs plural) > storage 1029069 Live storage migration snapshot removal fails, probably due > to unexpected qemu-img output > storage 987917 [oVirt] [glance] API version not specified in provider dialog > storage 1016118 async between masterVersion : can't connect to StoragePool > ux 906394 [oVirt-webadmin] [network] Loading animation in network main tab > 'hosts' and 'vms' subtab is stuck on first view... > virt 1007940 Cannot clone from snapshot while using GlusterFS as POSIX > Storage Domain > > > Please add the bugs to the tracker if you think that 3.3.2 should not be > released without them fixed. > > For those who want to help testing the bugs, I suggest to add yourself as QA > contact for the bug and add yourself to the testing page [2]. > > Maintainers are welcomed to start filling release notes, the page has been > created here [3] > > > [1] https://bugzilla.redhat.com/1027349 > [2] http://www.ovirt.org/Testing/Ovirt_3.3.2_testing > [3] http://www.ovirt.org/OVirt_3.3.2_release_notes > > Thanks, > > -- > Sandro Bonazzola > Better technology. Faster innovation. Powered by community collaboration. > See how it works at redhat.com > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > From ecohen at redhat.com Wed Nov 27 13:18:38 2013 From: ecohen at redhat.com (Einav Cohen) Date: Wed, 27 Nov 2013 08:18:38 -0500 (EST) Subject: [Engine-devel] Remove Comment column in main tabs In-Reply-To: <319931619.31531966.1385503424736.JavaMail.root@redhat.com> References: <1370005434.40758795.1385448274315.JavaMail.root@redhat.com> <575740807.31200878.1385481977247.JavaMail.root@redhat.com> <879487894.16560459.1385482638058.JavaMail.root@redhat.com> <134127793.41113642.1385483070675.JavaMail.root@redhat.com> <851652626.16582270.1385484289757.JavaMail.root@redhat.com> <246185107.31436601.1385495640948.JavaMail.root@redhat.com> <128970096.16796135.1385500794982.JavaMail.root@redhat.com> <319931619.31531966.1385503424736.JavaMail.root@redhat.com> Message-ID: <1474811117.17678021.1385558318419.JavaMail.root@redhat.com> > That is a good point. I guess the question is if sorting will be necessary on > comments since it is available on hover only anyway and I am not sure an > alphabetical sort would be very useful in finding a particular comment what I had in mind is Boolean sorting (i.e. similar to sorting according to the 'attachment' field in e-mail - sort by existence, and not by content). > If the comment is relatively unimportant, then I think it would be reasonable > to leave it where it is today. In my view (and I think that Mike implied that on his last reply as well), the comment can be pretty important; the comment is meant for dynamic notifications on the object. So I would imagine a comment to be something like "!! do not shutdown this VM! it is being installed with xyz!!" which is probably important enough to not be "hidden" in a distant column. [my suggestion earlier to keep it in its current location was merely for doing minimal changes, without changing anything in the primary-columns area or "making things worse" comment-wise, while saving real-estate; but if we can easily do a change that will also make the 'comment' column more noticeable, it is better] > Maybe if we decide not to implement the recommendation I sent earlier, we > could move the comment column to display after the name column. This way it > is not lost at the very end esp because its presence is known only via a > small icon. I don't feel strongly one way or another; I think it is acceptable to make this column adjacent to the 'Name' column either on its left or right side (see also Mike's Gmail example from his last reply on this thread - it is really not that bad, in my view, to have another column to the left). ----- Thanks, Einav > ----- Original Message ----- > From: "Malini Rao" > Sent: Tuesday, November 26, 2013 5:03:44 PM > > > ----- Original Message ----- > > From: "Einav Cohen" > > To: "Malini Rao" > > Cc: "engine-devel" > > Sent: Tuesday, November 26, 2013 4:19:55 PM > > Subject: Re: [Engine-devel] Remove Comment column in main tabs > > > > Hi Malini, > > > > > This could work but I am not a big fan of simply adding iconic columns > > > preceding the name. This is actually a good example where 2 icon columns > > > are > > > already there and adding another column is making the primary column ( > > > i.e > > > the name column) not seem like the first column the eye focuses on. > > > > not sure that I completely agree with that: if I am taking my e-mail > > client, > > for example - it has a lot of icon columns that precede the primary columns > > ('From', 'Subject'), however I don't think that it makes the primary > > columns > > any less 'catchy' (see attached > > 'e-mail-client--a-lot-of-preceding-icons.png'). > > Having said that - it may depend on the actual content of the icon columns > > (i.e. in my e-mail example, the icon-columns are mostly empty, whereas in > > the > > VMs main tab example, at least the 'status' and 'vm-type' icon columns are > > expected to always contain some icon), so not sure. > > Einav, I do take your point. That said, I don't think the screenshot you sent > me would be considered a good example of something well designed - at least > not in terms of the number of columns with icons. Also, it kind of works > because the subject column which is possibly what the user will focus on is > the widest. > > > > > > I understand that it is not as easy implementation-wise but in the effort > > > to > > > start moving towards a more elegant solution, I am wondering if we can > > > cash > > > in on what users may have learned in spreadsheet software and use a dog > > > ear > > > image at the corner of the name cell ( See attached). This way, we are > > > not > > > dedicating any more space and it does not take away space allotted to the > > > text string either. The visual details of the icon are not final and this > > > is > > > sent to communicate an idea only. If we agree on this, I will send the > > > final > > > icon to use. > > > > this solution is nice and elegant - I like it; > > my main concern is that I am not sure how will we be able to sort the items > > by that field if we won't have a dedicated column for it (once column > > sorting > > will be available in general, of course). > > That is a good point. I guess the question is if sorting will be necessary on > comments since it is available on hover only anyway and I am not sure an > alphabetical sort would be very useful in finding a particular comment. In > general, once we have that feature, it may be worthwhile to consider what > columns need sorting and not necessarily have every available column in the > list have that ability. What could be useful in this case is to sort by all > the rows that do have a comment on them and that could potentially be > incorporated into the sort sequence - for e.g, unsorted, alphanumeric > Asc,alphanumeric desc, presence of comment on top, unsorted. > > > > my other concern is indeed the implementation effort that would need to be > > involved in it. > > > > Question is if it is something that is worth considering if we decide that > > the > > extra-icon-column solution is acceptable. > > The extra-icon-column solution is not whacky or unacceptable but it creates > these empty spaces or tiled patterns depending on whether it is filled or > not and it also takes up space all the time. > > > > > Another option (at least for the short term) for solving the real-estate > > problem > > without changing anything in the primary column area is to keep the > > 'Comment' > > column in its current location, only replace its textual title with an icon > > title > > (see attached 'move-comment-column--option-1-variation.png'). > > I was thinking along these lines as well. Maybe if we decide not to implement > the recommendation I sent earlier, we could move the comment column to > display after the name column. This way it is not lost at the very end esp > because its presence is known only via a small icon. If the comment is > relatively unimportant, then I think it would be reasonable to leave it > where it is today. > > > > > > > > > Thoughts? > > > > > > -Malini > > > > > > ----- Original Message ----- > > > From: "Einav Cohen" > > > To: "Daniel Erez" > > > Cc: "Malini Rao" , "Mike Kolesnik" > > > , > > > "engine-devel" > > > Sent: Tuesday, November 26, 2013 11:44:49 AM > > > Subject: Re: [Engine-devel] Remove Comment column in main tabs > > > > > > > ----- Original Message ----- > > > > From: "Daniel Erez" > > > > Sent: Tuesday, November 26, 2013 11:24:30 AM > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > From: "Einav Cohen" > > > > > To: "Malini Rao" , "Mike Kolesnik" > > > > > > > > > > Cc: "engine-devel" > > > > > Sent: Tuesday, November 26, 2013 6:17:18 PM > > > > > Subject: Re: [Engine-devel] Remove Comment column in main tabs > > > > > > > > > > > ----- Original Message ----- > > > > > > From: "Malini Rao" > > > > > > Sent: Tuesday, November 26, 2013 11:06:17 AM > > > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > From: "Eli Mesika" > > > > > > > To: "Mike Kolesnik" > > > > > > > Cc: "engine-devel" > > > > > > > Sent: Tuesday, November 26, 2013 4:05:37 AM > > > > > > > Subject: Re: [Engine-devel] Remove Comment column in main tabs > > > > > > > > > > > > > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > > From: "Mike Kolesnik" > > > > > > > > To: "engine-devel" > > > > > > > > Sent: Tuesday, November 26, 2013 8:44:34 AM > > > > > > > > Subject: [Engine-devel] Remove Comment column in main tabs > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > When the comment RFE was added (in 3.3), there was also a > > > > > > > > column > > > > > > > > added > > > > > > > > to > > > > > > > > many main tabs. > > > > > > > > > > > > > > > > I would like to propose to get rid of the column (which can > > > > > > > > only > > > > > > > > house > > > > > > > > one > > > > > > > > icon or no icon), > > > > > > > > and instead if there's a comment on an entity just display the > > > > > > > > icon > > > > > > > > with > > > > > > > > the > > > > > > > > tooltip adjacent to the name. > > > > > > > > > > > > > > > > In this case the icon should probably be scaled down a bit > > > > > > > > since > > > > > > > > its > > > > > > > > huge. > > > > > > > > > > > > > > > > I think this would be a good alternative and save us some > > > > > > > > valued > > > > > > > > screen > > > > > > > > real > > > > > > > > estate. > > > > > > > > > > > > > > > > Thoughts, opinions? > > > > > > > > > > > > > > +1 > > > > > > > > > > > > +1. But isn't there a limitation on appending an icon to a column > > > > > > that > > > > > > already has content? Also to fully consider pros and cons - if it > > > > > > is > > > > > > possible, we have to think of where to append this icon - prefix or > > > > > > suffix. > > > > > > If we prefix, then it is likely that some names will be preceded by > > > > > > 2 > > > > > > icons > > > > > > because many of our lists have an icon already in the first column. > > > > > > If > > > > > > it > > > > > > is > > > > > > suffixed, the relative position on the icon will change based on > > > > > > how > > > > > > long > > > > > > the name is and if the object names tend to be long, then > > > > > > potentially, > > > > > > the > > > > > > icon is taking some room away. > > > > > > > > > > see attached two options (both comparing the current state and a > > > > > suggested > > > > > state in the VMs main tab) - not sure which one Mike had in mind. > > > > > option #1 is easy to implement while option #2, as Malini mentioned, > > > > > may > > > > > be more difficult to implement. > > > > > also need to keep in mind that the today, the comment column > > > > > real-estate > > > > > is > > > > > taken mostly by the column title; therefore if we lose the title, we > > > > > should > > > > > indicate in some other manner that this is the comment field of the > > > > > object > > > > > (e.g. within the tooltip - also demonstrated in the attached). > > > > > > > > +1 > > > > I think that an image header might be a good solution. > > > > E.g. an image of a post-it note instead of the title. > > > > > > good idea - we can display a "comment" tool-tip when hovering on the > > > title-icon > > > and, like today, display only the comment value within the tool-tip when > > > hovering > > > on the regular-row-icon (see attached). > > > [we already have icon-column-titles in the application, e.g. "shareable", > > > "bootable" > > > in the Disks grid, so it shouldn't be hard to implement] > > > > > > > > > > > > > > > > > > > > > > > > Also worth considering is the fact that if we prefix the icon only > > > > > > on > > > > > > the > > > > > > rows where it is needed, it will be in a position that will > > > > > > definitely > > > > > > grab > > > > > > attention. So, it may be worthwhile to see if this is the icon that > > > > > > we > > > > > > should place here or if there is any other icon that deserves this > > > > > > attention > > > > > > in a consistent manner across entities. > > > > > > > > > > > > While on the topic, it will also be a great idea IMHO to take a > > > > > > look > > > > > > at > > > > > > our > > > > > > various lists and see what columns are actually valuable for a > > > > > > default > > > > > > display. I think we are working on adding the ability to select > > > > > > columns > > > > > > for > > > > > > display and so the columns that we remove can be added back in by > > > > > > users > > > > > > when > > > > > > they want but do not sit there taking up room permanently. If > > > > > > anyone > > > > > > has > > > > > > ideas on what the default columns should be for one or many of the > > > > > > lists > > > > > > in > > > > > > our product, do send it to me. I will be willing to compile and > > > > > > consolidate > > > > > > the list and then post it back to the group for consideration. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Regards, > > > > > > > > Mike > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > Engine-devel mailing list > > > > > > > > Engine-devel at ovirt.org > > > > > > > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > Engine-devel mailing list > > > > > > > Engine-devel at ovirt.org > > > > > > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > > > > > > > > > > > _______________________________________________ > > > > > > Engine-devel mailing list > > > > > > Engine-devel at ovirt.org > > > > > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > > > > > > > > > > > > > > _______________________________________________ > > > > > Engine-devel mailing list > > > > > Engine-devel at ovirt.org > > > > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > > > > > > > > > > > > > _______________________________________________ > > > Engine-devel mailing list > > > Engine-devel at ovirt.org > > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > From mrao at redhat.com Wed Nov 27 14:18:14 2013 From: mrao at redhat.com (Malini Rao) Date: Wed, 27 Nov 2013 09:18:14 -0500 (EST) Subject: [Engine-devel] Remove Comment column in main tabs In-Reply-To: <1080230437.41446520.1385531775825.JavaMail.root@redhat.com> References: <1370005434.40758795.1385448274315.JavaMail.root@redhat.com> <575740807.31200878.1385481977247.JavaMail.root@redhat.com> <879487894.16560459.1385482638058.JavaMail.root@redhat.com> <134127793.41113642.1385483070675.JavaMail.root@redhat.com> <851652626.16582270.1385484289757.JavaMail.root@redhat.com> <246185107.31436601.1385495640948.JavaMail.root@redhat.com> <128970096.16796135.1385500794982.JavaMail.root@redhat.com> <1080230437.41446520.1385531775825.JavaMail.root@redhat.com> Message-ID: <311302845.31882633.1385561894361.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Mike Kolesnik" > To: "Einav Cohen" > Cc: "Malini Rao" , "engine-devel" > Sent: Wednesday, November 27, 2013 12:56:15 AM > Subject: Re: [Engine-devel] Remove Comment column in main tabs > > > ----- Original Message ----- > > Hi Malini, > > > > > This could work but I am not a big fan of simply adding iconic columns > > > preceding the name. This is actually a good example where 2 icon columns > > > are > > > already there and adding another column is making the primary column ( > > > i.e > > > the name column) not seem like the first column the eye focuses on. > > > > not sure that I completely agree with that: if I am taking my e-mail > > client, > > for example - it has a lot of icon columns that precede the primary columns > > ('From', 'Subject'), however I don't think that it makes the primary > > columns > > any less 'catchy' (see attached > > 'e-mail-client--a-lot-of-preceding-icons.png'). > > Having said that - it may depend on the actual content of the icon columns > > (i.e. in my e-mail example, the icon-columns are mostly empty, whereas in > > the > > VMs main tab example, at least the 'status' and 'vm-type' icon columns are > > expected to always contain some icon), so not sure. > > Leaving obscure open source email clients aside ;), gmail also has icon > columns, > although without any title or boundaries but visually it looks like a > column.. > > > > > > I understand that it is not as easy implementation-wise but in the effort > > > to > > > start moving towards a more elegant solution, I am wondering if we can > > > cash > > > in on what users may have learned in spreadsheet software and use a dog > > > ear > > > image at the corner of the name cell ( See attached). This way, we are > > > not > > > dedicating any more space and it does not take away space allotted to the > > > text string either. The visual details of the icon are not final and this > > > is > > > sent to communicate an idea only. If we agree on this, I will send the > > > final > > > icon to use. > > > > this solution is nice and elegant - I like it; > > my main concern is that I am not sure how will we be able to sort the items > > by that field if we won't have a dedicated column for it (once column > > sorting > > will be available in general, of course). > > my other concern is indeed the implementation effort that would need to be > > involved in it. > > Not sure how interesting it is to sort by comment, but for the sake of not > blocking it - a dedicated (small) column seems good to me. > > > > > Question is if it is something that is worth considering if we decide that > > the > > extra-icon-column solution is acceptable. > > > > Another option (at least for the short term) for solving the real-estate > > problem > > without changing anything in the primary column area is to keep the > > 'Comment' > > column in its current location, only replace its textual title with an icon > > title > > (see attached 'move-comment-column--option-1-variation.png'). > > > > I think if the comment is among the first to appear it serves it's purpose > better since the admin can clearly see that someone left a comment there and > pay attention to it, whereas if it's on the far side it can easily be missed > (or even hidden on a lower res screen). > > P.S. I think icon columns should probably be non-resizeable as it really > makes > no sense to resize them (they have a minimum width anyway). > +1 on making iconic columns non-resizable. From mrao at redhat.com Wed Nov 27 14:24:21 2013 From: mrao at redhat.com (Malini Rao) Date: Wed, 27 Nov 2013 09:24:21 -0500 (EST) Subject: [Engine-devel] Remove Comment column in main tabs In-Reply-To: <1474811117.17678021.1385558318419.JavaMail.root@redhat.com> References: <1370005434.40758795.1385448274315.JavaMail.root@redhat.com> <879487894.16560459.1385482638058.JavaMail.root@redhat.com> <134127793.41113642.1385483070675.JavaMail.root@redhat.com> <851652626.16582270.1385484289757.JavaMail.root@redhat.com> <246185107.31436601.1385495640948.JavaMail.root@redhat.com> <128970096.16796135.1385500794982.JavaMail.root@redhat.com> <319931619.31531966.1385503424736.JavaMail.root@redhat.com> <1474811117.17678021.1385558318419.JavaMail.root@redhat.com> Message-ID: <178932064.31886562.1385562261282.JavaMail.root@redhat.com> --- Original Message ----- > From: "Einav Cohen" > To: "Malini Rao" > Cc: "engine-devel" , "Mike Kolesnik" > Sent: Wednesday, November 27, 2013 8:18:38 AM > Subject: Re: [Engine-devel] Remove Comment column in main tabs > > > That is a good point. I guess the question is if sorting will be necessary > > on > > comments since it is available on hover only anyway and I am not sure an > > alphabetical sort would be very useful in finding a particular comment > > what I had in mind is Boolean sorting (i.e. similar to sorting according to > the 'attachment' field in e-mail - sort by existence, and not by content). OK.. so we are on the same page and potentially, it can then be incorporated into a sort sequence of the name column. > > > If the comment is relatively unimportant, then I think it would be > > reasonable > > to leave it where it is today. > > In my view (and I think that Mike implied that on his last reply as well), > the comment can be pretty important; the comment is meant for dynamic > notifications on the object. So I would imagine a comment to be something > like "!! do not shutdown this VM! it is being installed with xyz!!" which > is probably important enough to not be "hidden" in a distant column. > > [my suggestion earlier to keep it in its current location was merely for > doing minimal changes, without changing anything in the primary-columns > area or "making things worse" comment-wise, while saving real-estate; but > if we can easily do a change that will also make the 'comment' column more > noticeable, it is better] I am sure many examples abound for good and not so god paradigms. Even though I recommend other means of displaying info that apply only to some cases instead of dedicating a column for it, to come to a consensus for the short term, I think we can all agree to place this column to the right of the name column. This way, it is separated from the other two icons but still close to the name to gather attention. > > > Maybe if we decide not to implement the recommendation I sent earlier, we > > could move the comment column to display after the name column. This way it > > is not lost at the very end esp because its presence is known only via a > > small icon. > > I don't feel strongly one way or another; I think it is acceptable to make > this column adjacent to the 'Name' column either on its left or right side > (see also Mike's Gmail example from his last reply on this thread - it is > really not that bad, in my view, to have another column to the left). For the reasons stated in my earlier comment, let's place this column to the right of the name. Thanks Malini > > ----- > Thanks, > Einav > > > > ----- Original Message ----- > > From: "Malini Rao" > > Sent: Tuesday, November 26, 2013 5:03:44 PM > > > > > > ----- Original Message ----- > > > From: "Einav Cohen" > > > To: "Malini Rao" > > > Cc: "engine-devel" > > > Sent: Tuesday, November 26, 2013 4:19:55 PM > > > Subject: Re: [Engine-devel] Remove Comment column in main tabs > > > > > > Hi Malini, > > > > > > > This could work but I am not a big fan of simply adding iconic columns > > > > preceding the name. This is actually a good example where 2 icon > > > > columns > > > > are > > > > already there and adding another column is making the primary column ( > > > > i.e > > > > the name column) not seem like the first column the eye focuses on. > > > > > > not sure that I completely agree with that: if I am taking my e-mail > > > client, > > > for example - it has a lot of icon columns that precede the primary > > > columns > > > ('From', 'Subject'), however I don't think that it makes the primary > > > columns > > > any less 'catchy' (see attached > > > 'e-mail-client--a-lot-of-preceding-icons.png'). > > > Having said that - it may depend on the actual content of the icon > > > columns > > > (i.e. in my e-mail example, the icon-columns are mostly empty, whereas in > > > the > > > VMs main tab example, at least the 'status' and 'vm-type' icon columns > > > are > > > expected to always contain some icon), so not sure. > > > > Einav, I do take your point. That said, I don't think the screenshot you > > sent > > me would be considered a good example of something well designed - at least > > not in terms of the number of columns with icons. Also, it kind of works > > because the subject column which is possibly what the user will focus on is > > the widest. > > > > > > > > > I understand that it is not as easy implementation-wise but in the > > > > effort > > > > to > > > > start moving towards a more elegant solution, I am wondering if we can > > > > cash > > > > in on what users may have learned in spreadsheet software and use a dog > > > > ear > > > > image at the corner of the name cell ( See attached). This way, we are > > > > not > > > > dedicating any more space and it does not take away space allotted to > > > > the > > > > text string either. The visual details of the icon are not final and > > > > this > > > > is > > > > sent to communicate an idea only. If we agree on this, I will send the > > > > final > > > > icon to use. > > > > > > this solution is nice and elegant - I like it; > > > my main concern is that I am not sure how will we be able to sort the > > > items > > > by that field if we won't have a dedicated column for it (once column > > > sorting > > > will be available in general, of course). > > > > That is a good point. I guess the question is if sorting will be necessary > > on > > comments since it is available on hover only anyway and I am not sure an > > alphabetical sort would be very useful in finding a particular comment. In > > general, once we have that feature, it may be worthwhile to consider what > > columns need sorting and not necessarily have every available column in the > > list have that ability. What could be useful in this case is to sort by all > > the rows that do have a comment on them and that could potentially be > > incorporated into the sort sequence - for e.g, unsorted, alphanumeric > > Asc,alphanumeric desc, presence of comment on top, unsorted. > > > > > > > my other concern is indeed the implementation effort that would need to > > > be > > > involved in it. > > > > > > Question is if it is something that is worth considering if we decide > > > that > > > the > > > extra-icon-column solution is acceptable. > > > > The extra-icon-column solution is not whacky or unacceptable but it creates > > these empty spaces or tiled patterns depending on whether it is filled or > > not and it also takes up space all the time. > > > > > > > > Another option (at least for the short term) for solving the real-estate > > > problem > > > without changing anything in the primary column area is to keep the > > > 'Comment' > > > column in its current location, only replace its textual title with an > > > icon > > > title > > > (see attached 'move-comment-column--option-1-variation.png'). > > > > I was thinking along these lines as well. Maybe if we decide not to > > implement > > the recommendation I sent earlier, we could move the comment column to > > display after the name column. This way it is not lost at the very end esp > > because its presence is known only via a small icon. If the comment is > > relatively unimportant, then I think it would be reasonable to leave it > > where it is today. > > > > > > > > > > > > > Thoughts? > > > > > > > > -Malini > > > > > > > > ----- Original Message ----- > > > > From: "Einav Cohen" > > > > To: "Daniel Erez" > > > > Cc: "Malini Rao" , "Mike Kolesnik" > > > > , > > > > "engine-devel" > > > > Sent: Tuesday, November 26, 2013 11:44:49 AM > > > > Subject: Re: [Engine-devel] Remove Comment column in main tabs > > > > > > > > > ----- Original Message ----- > > > > > From: "Daniel Erez" > > > > > Sent: Tuesday, November 26, 2013 11:24:30 AM > > > > > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > From: "Einav Cohen" > > > > > > To: "Malini Rao" , "Mike Kolesnik" > > > > > > > > > > > > Cc: "engine-devel" > > > > > > Sent: Tuesday, November 26, 2013 6:17:18 PM > > > > > > Subject: Re: [Engine-devel] Remove Comment column in main tabs > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > From: "Malini Rao" > > > > > > > Sent: Tuesday, November 26, 2013 11:06:17 AM > > > > > > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > > From: "Eli Mesika" > > > > > > > > To: "Mike Kolesnik" > > > > > > > > Cc: "engine-devel" > > > > > > > > Sent: Tuesday, November 26, 2013 4:05:37 AM > > > > > > > > Subject: Re: [Engine-devel] Remove Comment column in main tabs > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > > > From: "Mike Kolesnik" > > > > > > > > > To: "engine-devel" > > > > > > > > > Sent: Tuesday, November 26, 2013 8:44:34 AM > > > > > > > > > Subject: [Engine-devel] Remove Comment column in main tabs > > > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > > > When the comment RFE was added (in 3.3), there was also a > > > > > > > > > column > > > > > > > > > added > > > > > > > > > to > > > > > > > > > many main tabs. > > > > > > > > > > > > > > > > > > I would like to propose to get rid of the column (which can > > > > > > > > > only > > > > > > > > > house > > > > > > > > > one > > > > > > > > > icon or no icon), > > > > > > > > > and instead if there's a comment on an entity just display > > > > > > > > > the > > > > > > > > > icon > > > > > > > > > with > > > > > > > > > the > > > > > > > > > tooltip adjacent to the name. > > > > > > > > > > > > > > > > > > In this case the icon should probably be scaled down a bit > > > > > > > > > since > > > > > > > > > its > > > > > > > > > huge. > > > > > > > > > > > > > > > > > > I think this would be a good alternative and save us some > > > > > > > > > valued > > > > > > > > > screen > > > > > > > > > real > > > > > > > > > estate. > > > > > > > > > > > > > > > > > > Thoughts, opinions? > > > > > > > > > > > > > > > > +1 > > > > > > > > > > > > > > +1. But isn't there a limitation on appending an icon to a column > > > > > > > that > > > > > > > already has content? Also to fully consider pros and cons - if it > > > > > > > is > > > > > > > possible, we have to think of where to append this icon - prefix > > > > > > > or > > > > > > > suffix. > > > > > > > If we prefix, then it is likely that some names will be preceded > > > > > > > by > > > > > > > 2 > > > > > > > icons > > > > > > > because many of our lists have an icon already in the first > > > > > > > column. > > > > > > > If > > > > > > > it > > > > > > > is > > > > > > > suffixed, the relative position on the icon will change based on > > > > > > > how > > > > > > > long > > > > > > > the name is and if the object names tend to be long, then > > > > > > > potentially, > > > > > > > the > > > > > > > icon is taking some room away. > > > > > > > > > > > > see attached two options (both comparing the current state and a > > > > > > suggested > > > > > > state in the VMs main tab) - not sure which one Mike had in mind. > > > > > > option #1 is easy to implement while option #2, as Malini > > > > > > mentioned, > > > > > > may > > > > > > be more difficult to implement. > > > > > > also need to keep in mind that the today, the comment column > > > > > > real-estate > > > > > > is > > > > > > taken mostly by the column title; therefore if we lose the title, > > > > > > we > > > > > > should > > > > > > indicate in some other manner that this is the comment field of the > > > > > > object > > > > > > (e.g. within the tooltip - also demonstrated in the attached). > > > > > > > > > > +1 > > > > > I think that an image header might be a good solution. > > > > > E.g. an image of a post-it note instead of the title. > > > > > > > > good idea - we can display a "comment" tool-tip when hovering on the > > > > title-icon > > > > and, like today, display only the comment value within the tool-tip > > > > when > > > > hovering > > > > on the regular-row-icon (see attached). > > > > [we already have icon-column-titles in the application, e.g. > > > > "shareable", > > > > "bootable" > > > > in the Disks grid, so it shouldn't be hard to implement] > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Also worth considering is the fact that if we prefix the icon > > > > > > > only > > > > > > > on > > > > > > > the > > > > > > > rows where it is needed, it will be in a position that will > > > > > > > definitely > > > > > > > grab > > > > > > > attention. So, it may be worthwhile to see if this is the icon > > > > > > > that > > > > > > > we > > > > > > > should place here or if there is any other icon that deserves > > > > > > > this > > > > > > > attention > > > > > > > in a consistent manner across entities. > > > > > > > > > > > > > > While on the topic, it will also be a great idea IMHO to take a > > > > > > > look > > > > > > > at > > > > > > > our > > > > > > > various lists and see what columns are actually valuable for a > > > > > > > default > > > > > > > display. I think we are working on adding the ability to select > > > > > > > columns > > > > > > > for > > > > > > > display and so the columns that we remove can be added back in by > > > > > > > users > > > > > > > when > > > > > > > they want but do not sit there taking up room permanently. If > > > > > > > anyone > > > > > > > has > > > > > > > ideas on what the default columns should be for one or many of > > > > > > > the > > > > > > > lists > > > > > > > in > > > > > > > our product, do send it to me. I will be willing to compile and > > > > > > > consolidate > > > > > > > the list and then post it back to the group for consideration. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Regards, > > > > > > > > > Mike > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > Engine-devel mailing list > > > > > > > > > Engine-devel at ovirt.org > > > > > > > > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > Engine-devel mailing list > > > > > > > > Engine-devel at ovirt.org > > > > > > > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > Engine-devel mailing list > > > > > > > Engine-devel at ovirt.org > > > > > > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > Engine-devel mailing list > > > > > > Engine-devel at ovirt.org > > > > > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > Engine-devel mailing list > > > > Engine-devel at ovirt.org > > > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > > > > _______________________________________________ > > Engine-devel mailing list > > Engine-devel at ovirt.org > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > > > > > From ecohen at redhat.com Wed Nov 27 15:16:23 2013 From: ecohen at redhat.com (Einav Cohen) Date: Wed, 27 Nov 2013 10:16:23 -0500 (EST) Subject: [Engine-devel] Remove Comment column in main tabs In-Reply-To: <178932064.31886562.1385562261282.JavaMail.root@redhat.com> References: <1370005434.40758795.1385448274315.JavaMail.root@redhat.com> <134127793.41113642.1385483070675.JavaMail.root@redhat.com> <851652626.16582270.1385484289757.JavaMail.root@redhat.com> <246185107.31436601.1385495640948.JavaMail.root@redhat.com> <128970096.16796135.1385500794982.JavaMail.root@redhat.com> <319931619.31531966.1385503424736.JavaMail.root@redhat.com> <1474811117.17678021.1385558318419.JavaMail.root@redhat.com> <178932064.31886562.1385562261282.JavaMail.root@redhat.com> Message-ID: <1290384231.17884950.1385565383762.JavaMail.root@redhat.com> > For the reasons stated in my earlier comment, let's place this column to the > right of the name. I am OK with that. @Mike/others - any objections for placing the Comment column with an icon-ed tooltip-ed title to the right of the Name column? [are we tracking it in a BZ? is someone volunteering to take care of this?] > OK.. so we are on the same page and potentially, it can then be incorporated > into a sort sequence of the name column. Malini, I missed your earlier reference to sort sequence, I apologize. I am not familiar with sort sequence other than Ascending/Descending; do you happen to have an example for something that uses sort sequence for something other than/in addition to Ascending/Descending? It sounds interesting. ---- Thanks, Einav ----- Original Message ----- > From: "Malini Rao" > To: "Einav Cohen" > Cc: "engine-devel" > Sent: Wednesday, November 27, 2013 9:24:21 AM > Subject: Re: [Engine-devel] Remove Comment column in main tabs > > --- Original Message ----- > > From: "Einav Cohen" > > To: "Malini Rao" > > Cc: "engine-devel" , "Mike Kolesnik" > > > > Sent: Wednesday, November 27, 2013 8:18:38 AM > > Subject: Re: [Engine-devel] Remove Comment column in main tabs > > > > > That is a good point. I guess the question is if sorting will be > > > necessary > > > on > > > comments since it is available on hover only anyway and I am not sure an > > > alphabetical sort would be very useful in finding a particular comment > > > > what I had in mind is Boolean sorting (i.e. similar to sorting according to > > the 'attachment' field in e-mail - sort by existence, and not by content). > > OK.. so we are on the same page and potentially, it can then be incorporated > into a sort sequence of the name column. > > > > > > If the comment is relatively unimportant, then I think it would be > > > reasonable > > > to leave it where it is today. > > > > In my view (and I think that Mike implied that on his last reply as well), > > the comment can be pretty important; the comment is meant for dynamic > > notifications on the object. So I would imagine a comment to be something > > like "!! do not shutdown this VM! it is being installed with xyz!!" which > > is probably important enough to not be "hidden" in a distant column. > > > > [my suggestion earlier to keep it in its current location was merely for > > doing minimal changes, without changing anything in the primary-columns > > area or "making things worse" comment-wise, while saving real-estate; but > > if we can easily do a change that will also make the 'comment' column more > > noticeable, it is better] > > I am sure many examples abound for good and not so god paradigms. Even though > I recommend other means of displaying info that apply only to some cases > instead of dedicating a column for it, to come to a consensus for the short > term, I think we can all agree to place this column to the right of the name > column. This way, it is separated from the other two icons but still close > to the name to gather attention. > > > > > > Maybe if we decide not to implement the recommendation I sent earlier, we > > > could move the comment column to display after the name column. This way > > > it > > > is not lost at the very end esp because its presence is known only via a > > > small icon. > > > > I don't feel strongly one way or another; I think it is acceptable to make > > this column adjacent to the 'Name' column either on its left or right side > > (see also Mike's Gmail example from his last reply on this thread - it is > > really not that bad, in my view, to have another column to the left). > > For the reasons stated in my earlier comment, let's place this column to the > right of the name. > > Thanks > Malini > > > > ----- > > Thanks, > > Einav > > > > > > > ----- Original Message ----- > > > From: "Malini Rao" > > > Sent: Tuesday, November 26, 2013 5:03:44 PM > > > > > > > > > ----- Original Message ----- > > > > From: "Einav Cohen" > > > > To: "Malini Rao" > > > > Cc: "engine-devel" > > > > Sent: Tuesday, November 26, 2013 4:19:55 PM > > > > Subject: Re: [Engine-devel] Remove Comment column in main tabs > > > > > > > > Hi Malini, > > > > > > > > > This could work but I am not a big fan of simply adding iconic > > > > > columns > > > > > preceding the name. This is actually a good example where 2 icon > > > > > columns > > > > > are > > > > > already there and adding another column is making the primary column > > > > > ( > > > > > i.e > > > > > the name column) not seem like the first column the eye focuses on. > > > > > > > > not sure that I completely agree with that: if I am taking my e-mail > > > > client, > > > > for example - it has a lot of icon columns that precede the primary > > > > columns > > > > ('From', 'Subject'), however I don't think that it makes the primary > > > > columns > > > > any less 'catchy' (see attached > > > > 'e-mail-client--a-lot-of-preceding-icons.png'). > > > > Having said that - it may depend on the actual content of the icon > > > > columns > > > > (i.e. in my e-mail example, the icon-columns are mostly empty, whereas > > > > in > > > > the > > > > VMs main tab example, at least the 'status' and 'vm-type' icon columns > > > > are > > > > expected to always contain some icon), so not sure. > > > > > > Einav, I do take your point. That said, I don't think the screenshot you > > > sent > > > me would be considered a good example of something well designed - at > > > least > > > not in terms of the number of columns with icons. Also, it kind of works > > > because the subject column which is possibly what the user will focus on > > > is > > > the widest. > > > > > > > > > > > > I understand that it is not as easy implementation-wise but in the > > > > > effort > > > > > to > > > > > start moving towards a more elegant solution, I am wondering if we > > > > > can > > > > > cash > > > > > in on what users may have learned in spreadsheet software and use a > > > > > dog > > > > > ear > > > > > image at the corner of the name cell ( See attached). This way, we > > > > > are > > > > > not > > > > > dedicating any more space and it does not take away space allotted to > > > > > the > > > > > text string either. The visual details of the icon are not final and > > > > > this > > > > > is > > > > > sent to communicate an idea only. If we agree on this, I will send > > > > > the > > > > > final > > > > > icon to use. > > > > > > > > this solution is nice and elegant - I like it; > > > > my main concern is that I am not sure how will we be able to sort the > > > > items > > > > by that field if we won't have a dedicated column for it (once column > > > > sorting > > > > will be available in general, of course). > > > > > > That is a good point. I guess the question is if sorting will be > > > necessary > > > on > > > comments since it is available on hover only anyway and I am not sure an > > > alphabetical sort would be very useful in finding a particular comment. > > > In > > > general, once we have that feature, it may be worthwhile to consider what > > > columns need sorting and not necessarily have every available column in > > > the > > > list have that ability. What could be useful in this case is to sort by > > > all > > > the rows that do have a comment on them and that could potentially be > > > incorporated into the sort sequence - for e.g, unsorted, alphanumeric > > > Asc,alphanumeric desc, presence of comment on top, unsorted. > > > > > > > > > > my other concern is indeed the implementation effort that would need to > > > > be > > > > involved in it. > > > > > > > > Question is if it is something that is worth considering if we decide > > > > that > > > > the > > > > extra-icon-column solution is acceptable. > > > > > > The extra-icon-column solution is not whacky or unacceptable but it > > > creates > > > these empty spaces or tiled patterns depending on whether it is filled or > > > not and it also takes up space all the time. > > > > > > > > > > > Another option (at least for the short term) for solving the > > > > real-estate > > > > problem > > > > without changing anything in the primary column area is to keep the > > > > 'Comment' > > > > column in its current location, only replace its textual title with an > > > > icon > > > > title > > > > (see attached 'move-comment-column--option-1-variation.png'). > > > > > > I was thinking along these lines as well. Maybe if we decide not to > > > implement > > > the recommendation I sent earlier, we could move the comment column to > > > display after the name column. This way it is not lost at the very end > > > esp > > > because its presence is known only via a small icon. If the comment is > > > relatively unimportant, then I think it would be reasonable to leave it > > > where it is today. > > > > > > > > > > > > > > > > > Thoughts? > > > > > > > > > > -Malini > > > > > > > > > > ----- Original Message ----- > > > > > From: "Einav Cohen" > > > > > To: "Daniel Erez" > > > > > Cc: "Malini Rao" , "Mike Kolesnik" > > > > > , > > > > > "engine-devel" > > > > > Sent: Tuesday, November 26, 2013 11:44:49 AM > > > > > Subject: Re: [Engine-devel] Remove Comment column in main tabs > > > > > > > > > > > ----- Original Message ----- > > > > > > From: "Daniel Erez" > > > > > > Sent: Tuesday, November 26, 2013 11:24:30 AM > > > > > > > > > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > From: "Einav Cohen" > > > > > > > To: "Malini Rao" , "Mike Kolesnik" > > > > > > > > > > > > > > Cc: "engine-devel" > > > > > > > Sent: Tuesday, November 26, 2013 6:17:18 PM > > > > > > > Subject: Re: [Engine-devel] Remove Comment column in main tabs > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > > From: "Malini Rao" > > > > > > > > Sent: Tuesday, November 26, 2013 11:06:17 AM > > > > > > > > > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > > > From: "Eli Mesika" > > > > > > > > > To: "Mike Kolesnik" > > > > > > > > > Cc: "engine-devel" > > > > > > > > > Sent: Tuesday, November 26, 2013 4:05:37 AM > > > > > > > > > Subject: Re: [Engine-devel] Remove Comment column in main > > > > > > > > > tabs > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > > > > From: "Mike Kolesnik" > > > > > > > > > > To: "engine-devel" > > > > > > > > > > Sent: Tuesday, November 26, 2013 8:44:34 AM > > > > > > > > > > Subject: [Engine-devel] Remove Comment column in main tabs > > > > > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > > > > > When the comment RFE was added (in 3.3), there was also a > > > > > > > > > > column > > > > > > > > > > added > > > > > > > > > > to > > > > > > > > > > many main tabs. > > > > > > > > > > > > > > > > > > > > I would like to propose to get rid of the column (which can > > > > > > > > > > only > > > > > > > > > > house > > > > > > > > > > one > > > > > > > > > > icon or no icon), > > > > > > > > > > and instead if there's a comment on an entity just display > > > > > > > > > > the > > > > > > > > > > icon > > > > > > > > > > with > > > > > > > > > > the > > > > > > > > > > tooltip adjacent to the name. > > > > > > > > > > > > > > > > > > > > In this case the icon should probably be scaled down a bit > > > > > > > > > > since > > > > > > > > > > its > > > > > > > > > > huge. > > > > > > > > > > > > > > > > > > > > I think this would be a good alternative and save us some > > > > > > > > > > valued > > > > > > > > > > screen > > > > > > > > > > real > > > > > > > > > > estate. > > > > > > > > > > > > > > > > > > > > Thoughts, opinions? > > > > > > > > > > > > > > > > > > +1 > > > > > > > > > > > > > > > > +1. But isn't there a limitation on appending an icon to a > > > > > > > > column > > > > > > > > that > > > > > > > > already has content? Also to fully consider pros and cons - if > > > > > > > > it > > > > > > > > is > > > > > > > > possible, we have to think of where to append this icon - > > > > > > > > prefix > > > > > > > > or > > > > > > > > suffix. > > > > > > > > If we prefix, then it is likely that some names will be > > > > > > > > preceded > > > > > > > > by > > > > > > > > 2 > > > > > > > > icons > > > > > > > > because many of our lists have an icon already in the first > > > > > > > > column. > > > > > > > > If > > > > > > > > it > > > > > > > > is > > > > > > > > suffixed, the relative position on the icon will change based > > > > > > > > on > > > > > > > > how > > > > > > > > long > > > > > > > > the name is and if the object names tend to be long, then > > > > > > > > potentially, > > > > > > > > the > > > > > > > > icon is taking some room away. > > > > > > > > > > > > > > see attached two options (both comparing the current state and a > > > > > > > suggested > > > > > > > state in the VMs main tab) - not sure which one Mike had in mind. > > > > > > > option #1 is easy to implement while option #2, as Malini > > > > > > > mentioned, > > > > > > > may > > > > > > > be more difficult to implement. > > > > > > > also need to keep in mind that the today, the comment column > > > > > > > real-estate > > > > > > > is > > > > > > > taken mostly by the column title; therefore if we lose the title, > > > > > > > we > > > > > > > should > > > > > > > indicate in some other manner that this is the comment field of > > > > > > > the > > > > > > > object > > > > > > > (e.g. within the tooltip - also demonstrated in the attached). > > > > > > > > > > > > +1 > > > > > > I think that an image header might be a good solution. > > > > > > E.g. an image of a post-it note instead of the title. > > > > > > > > > > good idea - we can display a "comment" tool-tip when hovering on the > > > > > title-icon > > > > > and, like today, display only the comment value within the tool-tip > > > > > when > > > > > hovering > > > > > on the regular-row-icon (see attached). > > > > > [we already have icon-column-titles in the application, e.g. > > > > > "shareable", > > > > > "bootable" > > > > > in the Disks grid, so it shouldn't be hard to implement] > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Also worth considering is the fact that if we prefix the icon > > > > > > > > only > > > > > > > > on > > > > > > > > the > > > > > > > > rows where it is needed, it will be in a position that will > > > > > > > > definitely > > > > > > > > grab > > > > > > > > attention. So, it may be worthwhile to see if this is the icon > > > > > > > > that > > > > > > > > we > > > > > > > > should place here or if there is any other icon that deserves > > > > > > > > this > > > > > > > > attention > > > > > > > > in a consistent manner across entities. > > > > > > > > > > > > > > > > While on the topic, it will also be a great idea IMHO to take a > > > > > > > > look > > > > > > > > at > > > > > > > > our > > > > > > > > various lists and see what columns are actually valuable for a > > > > > > > > default > > > > > > > > display. I think we are working on adding the ability to select > > > > > > > > columns > > > > > > > > for > > > > > > > > display and so the columns that we remove can be added back in > > > > > > > > by > > > > > > > > users > > > > > > > > when > > > > > > > > they want but do not sit there taking up room permanently. If > > > > > > > > anyone > > > > > > > > has > > > > > > > > ideas on what the default columns should be for one or many of > > > > > > > > the > > > > > > > > lists > > > > > > > > in > > > > > > > > our product, do send it to me. I will be willing to compile and > > > > > > > > consolidate > > > > > > > > the list and then post it back to the group for consideration. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Regards, > > > > > > > > > > Mike > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > > Engine-devel mailing list > > > > > > > > > > Engine-devel at ovirt.org > > > > > > > > > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > Engine-devel mailing list > > > > > > > > > Engine-devel at ovirt.org > > > > > > > > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > Engine-devel mailing list > > > > > > > > Engine-devel at ovirt.org > > > > > > > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > Engine-devel mailing list > > > > > > > Engine-devel at ovirt.org > > > > > > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > Engine-devel mailing list > > > > > Engine-devel at ovirt.org > > > > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > > > > > > _______________________________________________ > > > Engine-devel mailing list > > > Engine-devel at ovirt.org > > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > > > > > > > > > > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > From michal.skrivanek at redhat.com Wed Nov 27 15:21:41 2013 From: michal.skrivanek at redhat.com (Michal Skrivanek) Date: Wed, 27 Nov 2013 16:21:41 +0100 Subject: [Engine-devel] [vdsm] Multiple graphics framebuffers - VDSM support In-Reply-To: <1489098077.27937550.1385477854975.JavaMail.root@redhat.com> References: <609587315.27211779.1385385839986.JavaMail.root@redhat.com> <1489098077.27937550.1385477854975.JavaMail.root@redhat.com> Message-ID: On Nov 26, 2013, at 15:57 , Frantisek Kobzik wrote: > Hi guys, > > I created a wiki page with the feature: http://www.ovirt.org/Features/Multiple_Consoles > > It contains information about possible redesign of Engine<->VDSM communication. > I'd appreciate if you take a look at it since it's not trivial change. > > I welcome opinions from both engine and vdsm devels. I think we indeed have to split video device from graphics device and treat it separately? Thanks, michal > > Cheers, > F. > > ----- Original Message ----- > From: "Frantisek Kobzik" > To: vdsm-devel at lists.fedorahosted.org > Sent: Monday, November 25, 2013 2:23:59 PM > Subject: Re: [vdsm] Multiple graphics framebuffers - VDSM support > > Hi, > > it's been some time since the original mail, so I'm sending updated information. > > > ----- Original Message ----- > From: "Frantisek Kobzik" > To: vdsm-devel at lists.fedorahosted.org > Sent: Thursday, November 7, 2013 11:47:46 AM > Subject: [vdsm] Multiple graphics framebuffers - VDSM support > > Dear VDSM developers, > > I'm working on a patch that allows running a VM with multiple graphics framebuffers. This is handy when you want to run a VM with both SPICE and VNC. It's a 3.4 feature and it will certainly need a change in vdsm. > Here is a list of changes in VDSM that are needed for this funcionality: > a, Sending graphics/video (engine->vdsm) > - currently we send two things: > 1, "display" value (qxl/vnc [wat]) > - vdsm uses this for determining if the graphics server is SPICE or VNC > - this attribute is not really correct - it mixes up semantics of graphic > framebuffer and videocard together. I believe this attribute should only > contain information about the graphics ('spice', 'vnc' or 'spice,vnc' if > you want both). if this the case, do you think we should rename the attribute > to, let's say, 'graphics'? Is it even possible with regard to backward > compatibility? or should I reuse 'display' attribute? > 2, video device (json representation of the video card) - this is correct > > b, Reporting graphics ports (vdsm->engine) > - currently we report 2 graphic ports ('displayPort' and 'secureDisplayPort') > - if we want multiple framebuffers, we must report more ports (for VNC and > SPICE together that would mean 3 ports (2 for spice, one for vnc). > - there are two possible solutions for this: > 1, ditch 'displayPort' and 'secureDisplayPort' and add new 'spicePort', > 'spiceSecurePort', 'vncPort' fields or some kind of two level dict: > { protocol -> secured/unsecured -> portNumber } > 2, keep 'displayPort' and 'secureDisplayPort' and introduce new 'additionalDisplayPort' > This would be friendlier to backward compatibility, but it's extremely > ugly because of unclear semantics of the fields (in case of SPICE+VNC > 'displayPort' and 'secureDisplayPort' would be related to SPICE, > 'additionalDisplayPort' would be the VNC port. In case of VNC only, the > 'displayPort' would be suddendly VNC port... ewww). > > I'd be very happy if you share your opinion about these changes. > > Cheers, > Franta. > _______________________________________________ > vdsm-devel mailing list > vdsm-devel at lists.fedorahosted.org > https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel > _______________________________________________ > vdsm-devel mailing list > vdsm-devel at lists.fedorahosted.org > https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel From mrao at redhat.com Wed Nov 27 15:41:24 2013 From: mrao at redhat.com (Malini Rao) Date: Wed, 27 Nov 2013 10:41:24 -0500 (EST) Subject: [Engine-devel] Remove Comment column in main tabs In-Reply-To: <1290384231.17884950.1385565383762.JavaMail.root@redhat.com> References: <1370005434.40758795.1385448274315.JavaMail.root@redhat.com> <851652626.16582270.1385484289757.JavaMail.root@redhat.com> <246185107.31436601.1385495640948.JavaMail.root@redhat.com> <128970096.16796135.1385500794982.JavaMail.root@redhat.com> <319931619.31531966.1385503424736.JavaMail.root@redhat.com> <1474811117.17678021.1385558318419.JavaMail.root@redhat.com> <178932064.31886562.1385562261282.JavaMail.root@redhat.com> <1290384231.17884950.1385565383762.JavaMail.root@redhat.com> Message-ID: <862270558.31958020.1385566884594.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Einav Cohen" > To: "Malini Rao" , "Mike Kolesnik" > Cc: "engine-devel" > Sent: Wednesday, November 27, 2013 10:16:23 AM > Subject: Re: [Engine-devel] Remove Comment column in main tabs > > > For the reasons stated in my earlier comment, let's place this column to > > the > > right of the name. > > I am OK with that. > @Mike/others - any objections for placing the Comment column with an icon-ed > tooltip-ed title to the right of the Name column? > [are we tracking it in a BZ? is someone volunteering to take care of this?] > > > OK.. so we are on the same page and potentially, it can then be > > incorporated > > into a sort sequence of the name column. > > Malini, I missed your earlier reference to sort sequence, I apologize. > I am not familiar with sort sequence other than Ascending/Descending; > do you happen to have an example for something that uses sort sequence > for something other than/in addition to Ascending/Descending? It sounds > interesting. Einav, I can't think of a specific example off the top of my head for a list but what I am thinking of is a sort on a secondary attribute. I think it is more common in retail ( Amazon etc.) and travel sort of websites where you can sort a list by price high to low or low to high but also by other attributes like ratings etc. I am kind of extending that here because if the name column included the comment, then the attributes available on that column are the alphanumeric values of the name and well as the availability of a comment and so I feel it is reasonable to have a sort available on all those attributes for that column. > > ---- > Thanks, > Einav > > ----- Original Message ----- > > From: "Malini Rao" > > To: "Einav Cohen" > > Cc: "engine-devel" > > Sent: Wednesday, November 27, 2013 9:24:21 AM > > Subject: Re: [Engine-devel] Remove Comment column in main tabs > > > > --- Original Message ----- > > > From: "Einav Cohen" > > > To: "Malini Rao" > > > Cc: "engine-devel" , "Mike Kolesnik" > > > > > > Sent: Wednesday, November 27, 2013 8:18:38 AM > > > Subject: Re: [Engine-devel] Remove Comment column in main tabs > > > > > > > That is a good point. I guess the question is if sorting will be > > > > necessary > > > > on > > > > comments since it is available on hover only anyway and I am not sure > > > > an > > > > alphabetical sort would be very useful in finding a particular comment > > > > > > what I had in mind is Boolean sorting (i.e. similar to sorting according > > > to > > > the 'attachment' field in e-mail - sort by existence, and not by > > > content). > > > > OK.. so we are on the same page and potentially, it can then be > > incorporated > > into a sort sequence of the name column. > > > > > > > > > If the comment is relatively unimportant, then I think it would be > > > > reasonable > > > > to leave it where it is today. > > > > > > In my view (and I think that Mike implied that on his last reply as > > > well), > > > the comment can be pretty important; the comment is meant for dynamic > > > notifications on the object. So I would imagine a comment to be something > > > like "!! do not shutdown this VM! it is being installed with xyz!!" which > > > is probably important enough to not be "hidden" in a distant column. > > > > > > [my suggestion earlier to keep it in its current location was merely for > > > doing minimal changes, without changing anything in the primary-columns > > > area or "making things worse" comment-wise, while saving real-estate; but > > > if we can easily do a change that will also make the 'comment' column > > > more > > > noticeable, it is better] > > > > I am sure many examples abound for good and not so god paradigms. Even > > though > > I recommend other means of displaying info that apply only to some cases > > instead of dedicating a column for it, to come to a consensus for the short > > term, I think we can all agree to place this column to the right of the > > name > > column. This way, it is separated from the other two icons but still close > > to the name to gather attention. > > > > > > > > > Maybe if we decide not to implement the recommendation I sent earlier, > > > > we > > > > could move the comment column to display after the name column. This > > > > way > > > > it > > > > is not lost at the very end esp because its presence is known only via > > > > a > > > > small icon. > > > > > > I don't feel strongly one way or another; I think it is acceptable to > > > make > > > this column adjacent to the 'Name' column either on its left or right > > > side > > > (see also Mike's Gmail example from his last reply on this thread - it is > > > really not that bad, in my view, to have another column to the left). > > > > For the reasons stated in my earlier comment, let's place this column to > > the > > right of the name. > > > > Thanks > > Malini > > > > > > ----- > > > Thanks, > > > Einav > > > > > > > > > > ----- Original Message ----- > > > > From: "Malini Rao" > > > > Sent: Tuesday, November 26, 2013 5:03:44 PM > > > > > > > > > > > > ----- Original Message ----- > > > > > From: "Einav Cohen" > > > > > To: "Malini Rao" > > > > > Cc: "engine-devel" > > > > > Sent: Tuesday, November 26, 2013 4:19:55 PM > > > > > Subject: Re: [Engine-devel] Remove Comment column in main tabs > > > > > > > > > > Hi Malini, > > > > > > > > > > > This could work but I am not a big fan of simply adding iconic > > > > > > columns > > > > > > preceding the name. This is actually a good example where 2 icon > > > > > > columns > > > > > > are > > > > > > already there and adding another column is making the primary > > > > > > column > > > > > > ( > > > > > > i.e > > > > > > the name column) not seem like the first column the eye focuses on. > > > > > > > > > > not sure that I completely agree with that: if I am taking my e-mail > > > > > client, > > > > > for example - it has a lot of icon columns that precede the primary > > > > > columns > > > > > ('From', 'Subject'), however I don't think that it makes the primary > > > > > columns > > > > > any less 'catchy' (see attached > > > > > 'e-mail-client--a-lot-of-preceding-icons.png'). > > > > > Having said that - it may depend on the actual content of the icon > > > > > columns > > > > > (i.e. in my e-mail example, the icon-columns are mostly empty, > > > > > whereas > > > > > in > > > > > the > > > > > VMs main tab example, at least the 'status' and 'vm-type' icon > > > > > columns > > > > > are > > > > > expected to always contain some icon), so not sure. > > > > > > > > Einav, I do take your point. That said, I don't think the screenshot > > > > you > > > > sent > > > > me would be considered a good example of something well designed - at > > > > least > > > > not in terms of the number of columns with icons. Also, it kind of > > > > works > > > > because the subject column which is possibly what the user will focus > > > > on > > > > is > > > > the widest. > > > > > > > > > > > > > > > I understand that it is not as easy implementation-wise but in the > > > > > > effort > > > > > > to > > > > > > start moving towards a more elegant solution, I am wondering if we > > > > > > can > > > > > > cash > > > > > > in on what users may have learned in spreadsheet software and use a > > > > > > dog > > > > > > ear > > > > > > image at the corner of the name cell ( See attached). This way, we > > > > > > are > > > > > > not > > > > > > dedicating any more space and it does not take away space allotted > > > > > > to > > > > > > the > > > > > > text string either. The visual details of the icon are not final > > > > > > and > > > > > > this > > > > > > is > > > > > > sent to communicate an idea only. If we agree on this, I will send > > > > > > the > > > > > > final > > > > > > icon to use. > > > > > > > > > > this solution is nice and elegant - I like it; > > > > > my main concern is that I am not sure how will we be able to sort the > > > > > items > > > > > by that field if we won't have a dedicated column for it (once column > > > > > sorting > > > > > will be available in general, of course). > > > > > > > > That is a good point. I guess the question is if sorting will be > > > > necessary > > > > on > > > > comments since it is available on hover only anyway and I am not sure > > > > an > > > > alphabetical sort would be very useful in finding a particular comment. > > > > In > > > > general, once we have that feature, it may be worthwhile to consider > > > > what > > > > columns need sorting and not necessarily have every available column in > > > > the > > > > list have that ability. What could be useful in this case is to sort by > > > > all > > > > the rows that do have a comment on them and that could potentially be > > > > incorporated into the sort sequence - for e.g, unsorted, alphanumeric > > > > Asc,alphanumeric desc, presence of comment on top, unsorted. > > > > > > > > > > > > > my other concern is indeed the implementation effort that would need > > > > > to > > > > > be > > > > > involved in it. > > > > > > > > > > Question is if it is something that is worth considering if we decide > > > > > that > > > > > the > > > > > extra-icon-column solution is acceptable. > > > > > > > > The extra-icon-column solution is not whacky or unacceptable but it > > > > creates > > > > these empty spaces or tiled patterns depending on whether it is filled > > > > or > > > > not and it also takes up space all the time. > > > > > > > > > > > > > > Another option (at least for the short term) for solving the > > > > > real-estate > > > > > problem > > > > > without changing anything in the primary column area is to keep the > > > > > 'Comment' > > > > > column in its current location, only replace its textual title with > > > > > an > > > > > icon > > > > > title > > > > > (see attached 'move-comment-column--option-1-variation.png'). > > > > > > > > I was thinking along these lines as well. Maybe if we decide not to > > > > implement > > > > the recommendation I sent earlier, we could move the comment column to > > > > display after the name column. This way it is not lost at the very end > > > > esp > > > > because its presence is known only via a small icon. If the comment is > > > > relatively unimportant, then I think it would be reasonable to leave it > > > > where it is today. > > > > > > > > > > > > > > > > > > > > > Thoughts? > > > > > > > > > > > > -Malini > > > > > > > > > > > > ----- Original Message ----- > > > > > > From: "Einav Cohen" > > > > > > To: "Daniel Erez" > > > > > > Cc: "Malini Rao" , "Mike Kolesnik" > > > > > > , > > > > > > "engine-devel" > > > > > > Sent: Tuesday, November 26, 2013 11:44:49 AM > > > > > > Subject: Re: [Engine-devel] Remove Comment column in main tabs > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > From: "Daniel Erez" > > > > > > > Sent: Tuesday, November 26, 2013 11:24:30 AM > > > > > > > > > > > > > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > > From: "Einav Cohen" > > > > > > > > To: "Malini Rao" , "Mike Kolesnik" > > > > > > > > > > > > > > > > Cc: "engine-devel" > > > > > > > > Sent: Tuesday, November 26, 2013 6:17:18 PM > > > > > > > > Subject: Re: [Engine-devel] Remove Comment column in main tabs > > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > > > From: "Malini Rao" > > > > > > > > > Sent: Tuesday, November 26, 2013 11:06:17 AM > > > > > > > > > > > > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > > > > From: "Eli Mesika" > > > > > > > > > > To: "Mike Kolesnik" > > > > > > > > > > Cc: "engine-devel" > > > > > > > > > > Sent: Tuesday, November 26, 2013 4:05:37 AM > > > > > > > > > > Subject: Re: [Engine-devel] Remove Comment column in main > > > > > > > > > > tabs > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > > > > > From: "Mike Kolesnik" > > > > > > > > > > > To: "engine-devel" > > > > > > > > > > > Sent: Tuesday, November 26, 2013 8:44:34 AM > > > > > > > > > > > Subject: [Engine-devel] Remove Comment column in main > > > > > > > > > > > tabs > > > > > > > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > > > > > > > When the comment RFE was added (in 3.3), there was also a > > > > > > > > > > > column > > > > > > > > > > > added > > > > > > > > > > > to > > > > > > > > > > > many main tabs. > > > > > > > > > > > > > > > > > > > > > > I would like to propose to get rid of the column (which > > > > > > > > > > > can > > > > > > > > > > > only > > > > > > > > > > > house > > > > > > > > > > > one > > > > > > > > > > > icon or no icon), > > > > > > > > > > > and instead if there's a comment on an entity just > > > > > > > > > > > display > > > > > > > > > > > the > > > > > > > > > > > icon > > > > > > > > > > > with > > > > > > > > > > > the > > > > > > > > > > > tooltip adjacent to the name. > > > > > > > > > > > > > > > > > > > > > > In this case the icon should probably be scaled down a > > > > > > > > > > > bit > > > > > > > > > > > since > > > > > > > > > > > its > > > > > > > > > > > huge. > > > > > > > > > > > > > > > > > > > > > > I think this would be a good alternative and save us some > > > > > > > > > > > valued > > > > > > > > > > > screen > > > > > > > > > > > real > > > > > > > > > > > estate. > > > > > > > > > > > > > > > > > > > > > > Thoughts, opinions? > > > > > > > > > > > > > > > > > > > > +1 > > > > > > > > > > > > > > > > > > +1. But isn't there a limitation on appending an icon to a > > > > > > > > > column > > > > > > > > > that > > > > > > > > > already has content? Also to fully consider pros and cons - > > > > > > > > > if > > > > > > > > > it > > > > > > > > > is > > > > > > > > > possible, we have to think of where to append this icon - > > > > > > > > > prefix > > > > > > > > > or > > > > > > > > > suffix. > > > > > > > > > If we prefix, then it is likely that some names will be > > > > > > > > > preceded > > > > > > > > > by > > > > > > > > > 2 > > > > > > > > > icons > > > > > > > > > because many of our lists have an icon already in the first > > > > > > > > > column. > > > > > > > > > If > > > > > > > > > it > > > > > > > > > is > > > > > > > > > suffixed, the relative position on the icon will change based > > > > > > > > > on > > > > > > > > > how > > > > > > > > > long > > > > > > > > > the name is and if the object names tend to be long, then > > > > > > > > > potentially, > > > > > > > > > the > > > > > > > > > icon is taking some room away. > > > > > > > > > > > > > > > > see attached two options (both comparing the current state and > > > > > > > > a > > > > > > > > suggested > > > > > > > > state in the VMs main tab) - not sure which one Mike had in > > > > > > > > mind. > > > > > > > > option #1 is easy to implement while option #2, as Malini > > > > > > > > mentioned, > > > > > > > > may > > > > > > > > be more difficult to implement. > > > > > > > > also need to keep in mind that the today, the comment column > > > > > > > > real-estate > > > > > > > > is > > > > > > > > taken mostly by the column title; therefore if we lose the > > > > > > > > title, > > > > > > > > we > > > > > > > > should > > > > > > > > indicate in some other manner that this is the comment field of > > > > > > > > the > > > > > > > > object > > > > > > > > (e.g. within the tooltip - also demonstrated in the attached). > > > > > > > > > > > > > > +1 > > > > > > > I think that an image header might be a good solution. > > > > > > > E.g. an image of a post-it note instead of the title. > > > > > > > > > > > > good idea - we can display a "comment" tool-tip when hovering on > > > > > > the > > > > > > title-icon > > > > > > and, like today, display only the comment value within the tool-tip > > > > > > when > > > > > > hovering > > > > > > on the regular-row-icon (see attached). > > > > > > [we already have icon-column-titles in the application, e.g. > > > > > > "shareable", > > > > > > "bootable" > > > > > > in the Disks grid, so it shouldn't be hard to implement] > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Also worth considering is the fact that if we prefix the icon > > > > > > > > > only > > > > > > > > > on > > > > > > > > > the > > > > > > > > > rows where it is needed, it will be in a position that will > > > > > > > > > definitely > > > > > > > > > grab > > > > > > > > > attention. So, it may be worthwhile to see if this is the > > > > > > > > > icon > > > > > > > > > that > > > > > > > > > we > > > > > > > > > should place here or if there is any other icon that deserves > > > > > > > > > this > > > > > > > > > attention > > > > > > > > > in a consistent manner across entities. > > > > > > > > > > > > > > > > > > While on the topic, it will also be a great idea IMHO to take > > > > > > > > > a > > > > > > > > > look > > > > > > > > > at > > > > > > > > > our > > > > > > > > > various lists and see what columns are actually valuable for > > > > > > > > > a > > > > > > > > > default > > > > > > > > > display. I think we are working on adding the ability to > > > > > > > > > select > > > > > > > > > columns > > > > > > > > > for > > > > > > > > > display and so the columns that we remove can be added back > > > > > > > > > in > > > > > > > > > by > > > > > > > > > users > > > > > > > > > when > > > > > > > > > they want but do not sit there taking up room permanently. If > > > > > > > > > anyone > > > > > > > > > has > > > > > > > > > ideas on what the default columns should be for one or many > > > > > > > > > of > > > > > > > > > the > > > > > > > > > lists > > > > > > > > > in > > > > > > > > > our product, do send it to me. I will be willing to compile > > > > > > > > > and > > > > > > > > > consolidate > > > > > > > > > the list and then post it back to the group for > > > > > > > > > consideration. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Regards, > > > > > > > > > > > Mike > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > > > Engine-devel mailing list > > > > > > > > > > > Engine-devel at ovirt.org > > > > > > > > > > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > > Engine-devel mailing list > > > > > > > > > > Engine-devel at ovirt.org > > > > > > > > > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > Engine-devel mailing list > > > > > > > > > Engine-devel at ovirt.org > > > > > > > > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > Engine-devel mailing list > > > > > > > > Engine-devel at ovirt.org > > > > > > > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > Engine-devel mailing list > > > > > > Engine-devel at ovirt.org > > > > > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > > > > > > > > _______________________________________________ > > > > Engine-devel mailing list > > > > Engine-devel at ovirt.org > > > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > > > > > > > > > > > > > > > _______________________________________________ > > Engine-devel mailing list > > Engine-devel at ovirt.org > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > > > > > From michal.skrivanek at redhat.com Wed Nov 27 15:42:12 2013 From: michal.skrivanek at redhat.com (Michal Skrivanek) Date: Wed, 27 Nov 2013 16:42:12 +0100 Subject: [Engine-devel] [vdsm] [QE] oVirt 3.3.2 beta status In-Reply-To: <5295C997.8000000@redhat.com> References: <5295C997.8000000@redhat.com> Message-ID: <8EE3792F-85CC-42B3-8F20-D0C0CFD04A37@redhat.com> On Nov 27, 2013, at 11:29 , Sandro Bonazzola wrote: > Hi, > > we're going to branch and build oVirt 3.3.2 beta TODAY. > A bug tracker is available at [1] and it shows only 3 bugs still blocking the release: > > Whiteboard Bug ID Summary > storage 1022961 Running a VM from a gluster domain uses mount instead of gluster URI > virt 1025829 sysprep floppy is not attached to Windows 2008 R2 machine - even when specifically checked in Run Once hopefully end of week we will know more. Should not be hard though > virt 1029885 cloud-init testcase does not work in engine 3.3.1 this is about current CentOS containing a quite dated version of cloud-init. There's little we can do except encourage people to build/use 0.7.2+ Awaiting reporter's feedback Thanks, michal > > Please provide an ETA for the above bugs. > > > The following is a list of the non-blocking bugs still open with target 3.3.2: > > Whiteboard Bug ID Summary > infra 1017267 Plaintext user passwords in async_tasks database > infra 987982 When adding a host through the REST API, the error message says that "rootPassword" is required,... > infra 1020344 Power Managent with cisco_ucs problem > integration 1022440 AIO - configure the AIO host to be a gluster cluster/host > integration 902979 ovirt-live - firefox doesn't trust the installed engine > integration 1021805 oVirt Live - use motd to show the admin password > integration 1026930 Package virtio-win and put it in ovirt repositories > integration 1026933 pre-populate ISO domain with virtio-win ISO > network 1019818 Support OpenStack Havana layer 2 agent integration > network 987999 [oVirt] [provider] Add button shouldn't appear on specific provider > network 987916 [oVirt] [provider] Dialog doesn't update unless focus lost > network 906313 [oVirt-webadmin] [setupNetworks] "No valid Operation for and Unassigned Logical Networks panel" > network 1023722 [oVirt-webadmin][network] Network roles in cluster management should be radio buttons > network 997197 Some AppErrors messages are grammatically incorrect (singular vs plural) > storage 1029069 Live storage migration snapshot removal fails, probably due to unexpected qemu-img output > storage 987917 [oVirt] [glance] API version not specified in provider dialog > storage 1016118 async between masterVersion : can't connect to StoragePool > ux 906394 [oVirt-webadmin] [network] Loading animation in network main tab 'hosts' and 'vms' subtab is stuck on first view... > virt 1007940 Cannot clone from snapshot while using GlusterFS as POSIX Storage Domain > > > Please add the bugs to the tracker if you think that 3.3.2 should not be released without them fixed. > > For those who want to help testing the bugs, I suggest to add yourself as QA contact for the bug and add yourself to the testing page [2]. > > Maintainers are welcomed to start filling release notes, the page has been created here [3] > > > [1] https://bugzilla.redhat.com/1027349 > [2] http://www.ovirt.org/Testing/Ovirt_3.3.2_testing > [3] http://www.ovirt.org/OVirt_3.3.2_release_notes > > Thanks, > > -- > Sandro Bonazzola > Better technology. Faster innovation. Powered by community collaboration. > See how it works at redhat.com > _______________________________________________ > vdsm-devel mailing list > vdsm-devel at lists.fedorahosted.org > https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel From sbonazzo at redhat.com Wed Nov 27 16:14:37 2013 From: sbonazzo at redhat.com (Sandro Bonazzola) Date: Wed, 27 Nov 2013 17:14:37 +0100 Subject: [Engine-devel] oVirt PPC status update Message-ID: <52961A6D.4090208@redhat.com> Hi, anybody can report about PPC status for 3.3.2 and 3.4.0 target releases? It would be nice having someone for PPC at ovirt-sync meeting from next week on, so please join :-) Thanks, -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com From mkolesni at redhat.com Thu Nov 28 06:03:24 2013 From: mkolesni at redhat.com (Mike Kolesnik) Date: Thu, 28 Nov 2013 01:03:24 -0500 (EST) Subject: [Engine-devel] Remove Comment column in main tabs In-Reply-To: <1290384231.17884950.1385565383762.JavaMail.root@redhat.com> References: <1370005434.40758795.1385448274315.JavaMail.root@redhat.com> <851652626.16582270.1385484289757.JavaMail.root@redhat.com> <246185107.31436601.1385495640948.JavaMail.root@redhat.com> <128970096.16796135.1385500794982.JavaMail.root@redhat.com> <319931619.31531966.1385503424736.JavaMail.root@redhat.com> <1474811117.17678021.1385558318419.JavaMail.root@redhat.com> <178932064.31886562.1385562261282.JavaMail.root@redhat.com> <1290384231.17884950.1385565383762.JavaMail.root@redhat.com> Message-ID: <1993200129.42184923.1385618604601.JavaMail.root@redhat.com> ----- Original Message ----- > > For the reasons stated in my earlier comment, let's place this column to > > the > > right of the name. > > I am OK with that. > @Mike/others - any objections for placing the Comment column with an icon-ed > tooltip-ed title to the right of the Name column? No objections, I'm actually +1 for it :) > [are we tracking it in a BZ? is someone volunteering to take care of this?] I opened a bug for this: https://bugzilla.redhat.com/show_bug.cgi?id=1035566 While at it, I also opened a BZ to fixate the icon column size: https://bugzilla.redhat.com/show_bug.cgi?id=1035567 Not sure but I think these bugs should be fixed (if and when) for user portal as well.. > > > OK.. so we are on the same page and potentially, it can then be > > incorporated > > into a sort sequence of the name column. > > Malini, I missed your earlier reference to sort sequence, I apologize. > I am not familiar with sort sequence other than Ascending/Descending; > do you happen to have an example for something that uses sort sequence > for something other than/in addition to Ascending/Descending? It sounds > interesting. > > ---- > Thanks, > Einav > > ----- Original Message ----- > > From: "Malini Rao" > > To: "Einav Cohen" > > Cc: "engine-devel" > > Sent: Wednesday, November 27, 2013 9:24:21 AM > > Subject: Re: [Engine-devel] Remove Comment column in main tabs > > > > --- Original Message ----- > > > From: "Einav Cohen" > > > To: "Malini Rao" > > > Cc: "engine-devel" , "Mike Kolesnik" > > > > > > Sent: Wednesday, November 27, 2013 8:18:38 AM > > > Subject: Re: [Engine-devel] Remove Comment column in main tabs > > > > > > > That is a good point. I guess the question is if sorting will be > > > > necessary > > > > on > > > > comments since it is available on hover only anyway and I am not sure > > > > an > > > > alphabetical sort would be very useful in finding a particular comment > > > > > > what I had in mind is Boolean sorting (i.e. similar to sorting according > > > to > > > the 'attachment' field in e-mail - sort by existence, and not by > > > content). > > > > OK.. so we are on the same page and potentially, it can then be > > incorporated > > into a sort sequence of the name column. > > > > > > > > > If the comment is relatively unimportant, then I think it would be > > > > reasonable > > > > to leave it where it is today. > > > > > > In my view (and I think that Mike implied that on his last reply as > > > well), > > > the comment can be pretty important; the comment is meant for dynamic > > > notifications on the object. So I would imagine a comment to be something > > > like "!! do not shutdown this VM! it is being installed with xyz!!" which > > > is probably important enough to not be "hidden" in a distant column. > > > > > > [my suggestion earlier to keep it in its current location was merely for > > > doing minimal changes, without changing anything in the primary-columns > > > area or "making things worse" comment-wise, while saving real-estate; but > > > if we can easily do a change that will also make the 'comment' column > > > more > > > noticeable, it is better] > > > > I am sure many examples abound for good and not so god paradigms. Even > > though > > I recommend other means of displaying info that apply only to some cases > > instead of dedicating a column for it, to come to a consensus for the short > > term, I think we can all agree to place this column to the right of the > > name > > column. This way, it is separated from the other two icons but still close > > to the name to gather attention. > > > > > > > > > Maybe if we decide not to implement the recommendation I sent earlier, > > > > we > > > > could move the comment column to display after the name column. This > > > > way > > > > it > > > > is not lost at the very end esp because its presence is known only via > > > > a > > > > small icon. > > > > > > I don't feel strongly one way or another; I think it is acceptable to > > > make > > > this column adjacent to the 'Name' column either on its left or right > > > side > > > (see also Mike's Gmail example from his last reply on this thread - it is > > > really not that bad, in my view, to have another column to the left). > > > > For the reasons stated in my earlier comment, let's place this column to > > the > > right of the name. > > > > Thanks > > Malini > > > > > > ----- > > > Thanks, > > > Einav > > > > > > > > > > ----- Original Message ----- > > > > From: "Malini Rao" > > > > Sent: Tuesday, November 26, 2013 5:03:44 PM > > > > > > > > > > > > ----- Original Message ----- > > > > > From: "Einav Cohen" > > > > > To: "Malini Rao" > > > > > Cc: "engine-devel" > > > > > Sent: Tuesday, November 26, 2013 4:19:55 PM > > > > > Subject: Re: [Engine-devel] Remove Comment column in main tabs > > > > > > > > > > Hi Malini, > > > > > > > > > > > This could work but I am not a big fan of simply adding iconic > > > > > > columns > > > > > > preceding the name. This is actually a good example where 2 icon > > > > > > columns > > > > > > are > > > > > > already there and adding another column is making the primary > > > > > > column > > > > > > ( > > > > > > i.e > > > > > > the name column) not seem like the first column the eye focuses on. > > > > > > > > > > not sure that I completely agree with that: if I am taking my e-mail > > > > > client, > > > > > for example - it has a lot of icon columns that precede the primary > > > > > columns > > > > > ('From', 'Subject'), however I don't think that it makes the primary > > > > > columns > > > > > any less 'catchy' (see attached > > > > > 'e-mail-client--a-lot-of-preceding-icons.png'). > > > > > Having said that - it may depend on the actual content of the icon > > > > > columns > > > > > (i.e. in my e-mail example, the icon-columns are mostly empty, > > > > > whereas > > > > > in > > > > > the > > > > > VMs main tab example, at least the 'status' and 'vm-type' icon > > > > > columns > > > > > are > > > > > expected to always contain some icon), so not sure. > > > > > > > > Einav, I do take your point. That said, I don't think the screenshot > > > > you > > > > sent > > > > me would be considered a good example of something well designed - at > > > > least > > > > not in terms of the number of columns with icons. Also, it kind of > > > > works > > > > because the subject column which is possibly what the user will focus > > > > on > > > > is > > > > the widest. > > > > > > > > > > > > > > > I understand that it is not as easy implementation-wise but in the > > > > > > effort > > > > > > to > > > > > > start moving towards a more elegant solution, I am wondering if we > > > > > > can > > > > > > cash > > > > > > in on what users may have learned in spreadsheet software and use a > > > > > > dog > > > > > > ear > > > > > > image at the corner of the name cell ( See attached). This way, we > > > > > > are > > > > > > not > > > > > > dedicating any more space and it does not take away space allotted > > > > > > to > > > > > > the > > > > > > text string either. The visual details of the icon are not final > > > > > > and > > > > > > this > > > > > > is > > > > > > sent to communicate an idea only. If we agree on this, I will send > > > > > > the > > > > > > final > > > > > > icon to use. > > > > > > > > > > this solution is nice and elegant - I like it; > > > > > my main concern is that I am not sure how will we be able to sort the > > > > > items > > > > > by that field if we won't have a dedicated column for it (once column > > > > > sorting > > > > > will be available in general, of course). > > > > > > > > That is a good point. I guess the question is if sorting will be > > > > necessary > > > > on > > > > comments since it is available on hover only anyway and I am not sure > > > > an > > > > alphabetical sort would be very useful in finding a particular comment. > > > > In > > > > general, once we have that feature, it may be worthwhile to consider > > > > what > > > > columns need sorting and not necessarily have every available column in > > > > the > > > > list have that ability. What could be useful in this case is to sort by > > > > all > > > > the rows that do have a comment on them and that could potentially be > > > > incorporated into the sort sequence - for e.g, unsorted, alphanumeric > > > > Asc,alphanumeric desc, presence of comment on top, unsorted. > > > > > > > > > > > > > my other concern is indeed the implementation effort that would need > > > > > to > > > > > be > > > > > involved in it. > > > > > > > > > > Question is if it is something that is worth considering if we decide > > > > > that > > > > > the > > > > > extra-icon-column solution is acceptable. > > > > > > > > The extra-icon-column solution is not whacky or unacceptable but it > > > > creates > > > > these empty spaces or tiled patterns depending on whether it is filled > > > > or > > > > not and it also takes up space all the time. > > > > > > > > > > > > > > Another option (at least for the short term) for solving the > > > > > real-estate > > > > > problem > > > > > without changing anything in the primary column area is to keep the > > > > > 'Comment' > > > > > column in its current location, only replace its textual title with > > > > > an > > > > > icon > > > > > title > > > > > (see attached 'move-comment-column--option-1-variation.png'). > > > > > > > > I was thinking along these lines as well. Maybe if we decide not to > > > > implement > > > > the recommendation I sent earlier, we could move the comment column to > > > > display after the name column. This way it is not lost at the very end > > > > esp > > > > because its presence is known only via a small icon. If the comment is > > > > relatively unimportant, then I think it would be reasonable to leave it > > > > where it is today. > > > > > > > > > > > > > > > > > > > > > Thoughts? > > > > > > > > > > > > -Malini > > > > > > > > > > > > ----- Original Message ----- > > > > > > From: "Einav Cohen" > > > > > > To: "Daniel Erez" > > > > > > Cc: "Malini Rao" , "Mike Kolesnik" > > > > > > , > > > > > > "engine-devel" > > > > > > Sent: Tuesday, November 26, 2013 11:44:49 AM > > > > > > Subject: Re: [Engine-devel] Remove Comment column in main tabs > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > From: "Daniel Erez" > > > > > > > Sent: Tuesday, November 26, 2013 11:24:30 AM > > > > > > > > > > > > > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > > From: "Einav Cohen" > > > > > > > > To: "Malini Rao" , "Mike Kolesnik" > > > > > > > > > > > > > > > > Cc: "engine-devel" > > > > > > > > Sent: Tuesday, November 26, 2013 6:17:18 PM > > > > > > > > Subject: Re: [Engine-devel] Remove Comment column in main tabs > > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > > > From: "Malini Rao" > > > > > > > > > Sent: Tuesday, November 26, 2013 11:06:17 AM > > > > > > > > > > > > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > > > > From: "Eli Mesika" > > > > > > > > > > To: "Mike Kolesnik" > > > > > > > > > > Cc: "engine-devel" > > > > > > > > > > Sent: Tuesday, November 26, 2013 4:05:37 AM > > > > > > > > > > Subject: Re: [Engine-devel] Remove Comment column in main > > > > > > > > > > tabs > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > > > > > From: "Mike Kolesnik" > > > > > > > > > > > To: "engine-devel" > > > > > > > > > > > Sent: Tuesday, November 26, 2013 8:44:34 AM > > > > > > > > > > > Subject: [Engine-devel] Remove Comment column in main > > > > > > > > > > > tabs > > > > > > > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > > > > > > > When the comment RFE was added (in 3.3), there was also a > > > > > > > > > > > column > > > > > > > > > > > added > > > > > > > > > > > to > > > > > > > > > > > many main tabs. > > > > > > > > > > > > > > > > > > > > > > I would like to propose to get rid of the column (which > > > > > > > > > > > can > > > > > > > > > > > only > > > > > > > > > > > house > > > > > > > > > > > one > > > > > > > > > > > icon or no icon), > > > > > > > > > > > and instead if there's a comment on an entity just > > > > > > > > > > > display > > > > > > > > > > > the > > > > > > > > > > > icon > > > > > > > > > > > with > > > > > > > > > > > the > > > > > > > > > > > tooltip adjacent to the name. > > > > > > > > > > > > > > > > > > > > > > In this case the icon should probably be scaled down a > > > > > > > > > > > bit > > > > > > > > > > > since > > > > > > > > > > > its > > > > > > > > > > > huge. > > > > > > > > > > > > > > > > > > > > > > I think this would be a good alternative and save us some > > > > > > > > > > > valued > > > > > > > > > > > screen > > > > > > > > > > > real > > > > > > > > > > > estate. > > > > > > > > > > > > > > > > > > > > > > Thoughts, opinions? > > > > > > > > > > > > > > > > > > > > +1 > > > > > > > > > > > > > > > > > > +1. But isn't there a limitation on appending an icon to a > > > > > > > > > column > > > > > > > > > that > > > > > > > > > already has content? Also to fully consider pros and cons - > > > > > > > > > if > > > > > > > > > it > > > > > > > > > is > > > > > > > > > possible, we have to think of where to append this icon - > > > > > > > > > prefix > > > > > > > > > or > > > > > > > > > suffix. > > > > > > > > > If we prefix, then it is likely that some names will be > > > > > > > > > preceded > > > > > > > > > by > > > > > > > > > 2 > > > > > > > > > icons > > > > > > > > > because many of our lists have an icon already in the first > > > > > > > > > column. > > > > > > > > > If > > > > > > > > > it > > > > > > > > > is > > > > > > > > > suffixed, the relative position on the icon will change based > > > > > > > > > on > > > > > > > > > how > > > > > > > > > long > > > > > > > > > the name is and if the object names tend to be long, then > > > > > > > > > potentially, > > > > > > > > > the > > > > > > > > > icon is taking some room away. > > > > > > > > > > > > > > > > see attached two options (both comparing the current state and > > > > > > > > a > > > > > > > > suggested > > > > > > > > state in the VMs main tab) - not sure which one Mike had in > > > > > > > > mind. > > > > > > > > option #1 is easy to implement while option #2, as Malini > > > > > > > > mentioned, > > > > > > > > may > > > > > > > > be more difficult to implement. > > > > > > > > also need to keep in mind that the today, the comment column > > > > > > > > real-estate > > > > > > > > is > > > > > > > > taken mostly by the column title; therefore if we lose the > > > > > > > > title, > > > > > > > > we > > > > > > > > should > > > > > > > > indicate in some other manner that this is the comment field of > > > > > > > > the > > > > > > > > object > > > > > > > > (e.g. within the tooltip - also demonstrated in the attached). > > > > > > > > > > > > > > +1 > > > > > > > I think that an image header might be a good solution. > > > > > > > E.g. an image of a post-it note instead of the title. > > > > > > > > > > > > good idea - we can display a "comment" tool-tip when hovering on > > > > > > the > > > > > > title-icon > > > > > > and, like today, display only the comment value within the tool-tip > > > > > > when > > > > > > hovering > > > > > > on the regular-row-icon (see attached). > > > > > > [we already have icon-column-titles in the application, e.g. > > > > > > "shareable", > > > > > > "bootable" > > > > > > in the Disks grid, so it shouldn't be hard to implement] > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Also worth considering is the fact that if we prefix the icon > > > > > > > > > only > > > > > > > > > on > > > > > > > > > the > > > > > > > > > rows where it is needed, it will be in a position that will > > > > > > > > > definitely > > > > > > > > > grab > > > > > > > > > attention. So, it may be worthwhile to see if this is the > > > > > > > > > icon > > > > > > > > > that > > > > > > > > > we > > > > > > > > > should place here or if there is any other icon that deserves > > > > > > > > > this > > > > > > > > > attention > > > > > > > > > in a consistent manner across entities. > > > > > > > > > > > > > > > > > > While on the topic, it will also be a great idea IMHO to take > > > > > > > > > a > > > > > > > > > look > > > > > > > > > at > > > > > > > > > our > > > > > > > > > various lists and see what columns are actually valuable for > > > > > > > > > a > > > > > > > > > default > > > > > > > > > display. I think we are working on adding the ability to > > > > > > > > > select > > > > > > > > > columns > > > > > > > > > for > > > > > > > > > display and so the columns that we remove can be added back > > > > > > > > > in > > > > > > > > > by > > > > > > > > > users > > > > > > > > > when > > > > > > > > > they want but do not sit there taking up room permanently. If > > > > > > > > > anyone > > > > > > > > > has > > > > > > > > > ideas on what the default columns should be for one or many > > > > > > > > > of > > > > > > > > > the > > > > > > > > > lists > > > > > > > > > in > > > > > > > > > our product, do send it to me. I will be willing to compile > > > > > > > > > and > > > > > > > > > consolidate > > > > > > > > > the list and then post it back to the group for > > > > > > > > > consideration. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Regards, > > > > > > > > > > > Mike > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > > > Engine-devel mailing list > > > > > > > > > > > Engine-devel at ovirt.org > > > > > > > > > > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > > Engine-devel mailing list > > > > > > > > > > Engine-devel at ovirt.org > > > > > > > > > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > Engine-devel mailing list > > > > > > > > > Engine-devel at ovirt.org > > > > > > > > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > Engine-devel mailing list > > > > > > > > Engine-devel at ovirt.org > > > > > > > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > Engine-devel mailing list > > > > > > Engine-devel at ovirt.org > > > > > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > > > > > > > > _______________________________________________ > > > > Engine-devel mailing list > > > > Engine-devel at ovirt.org > > > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > > > > > > > > > > > > > > > _______________________________________________ > > Engine-devel mailing list > > Engine-devel at ovirt.org > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > > > > > From iheim at redhat.com Thu Nov 28 07:30:06 2013 From: iheim at redhat.com (Itamar Heim) Date: Thu, 28 Nov 2013 09:30:06 +0200 Subject: [Engine-devel] [Users] [vdsm] [QE] oVirt 3.3.2 beta status In-Reply-To: <8EE3792F-85CC-42B3-8F20-D0C0CFD04A37@redhat.com> References: <5295C997.8000000@redhat.com> <8EE3792F-85CC-42B3-8F20-D0C0CFD04A37@redhat.com> Message-ID: <5296F0FE.3030602@redhat.com> On 11/27/2013 05:42 PM, Michal Skrivanek wrote: >> virt 1029885 cloud-init testcase does not work in engine 3.3.1 > this is about current CentOS containing a quite dated version of cloud-init. There's little we can do except encourage people to build/use 0.7.2+ > Awaiting reporter's feedback as rhel 6.5 GA'd and has these properly, shouldn't be an issue, and should be in CentOS 6.5 as well. From leonardo.bianconi at eldorado.org.br Thu Nov 28 12:09:25 2013 From: leonardo.bianconi at eldorado.org.br (Leonardo Bianconi) Date: Thu, 28 Nov 2013 12:09:25 +0000 Subject: [Engine-devel] oVirt Weekly Meeting Minutes Message-ID: <50EB20226B72D6419356FC320AB62B876DFDD57B@SERV070.corp.eldorado.org.br> Hi Sandro These are the PPC features and its status: Target Status Description 3.4 - Under review - Architecture support when importing/exporting VM and Templates 3.4 - Under review - Ability to specify architecture in the OSInfo file 3.4 - Under review - Ability to specify supported video cards and display protocols in the OSInfo file 3.4 - Under review - Ability to specify watch dog in the OSInfo file 3.4 - Done - Ability to specify hotplug of nic and disk in the OSInfo file 3.4 - Under review - Ability to search by architecture 3.4 - Under review - Create Cluster, VM and Templates for PPC64 3.4 - Under review - Add PPC64 Hosts 3.4 - Under review - Support for sPAPR VLAN and sPAPR VSCSI 3.4 - Under review - Run fake power hosts 3.4 - Under review - Obtain capabilities of PPC64 hosts 3.4 - Under review - Obtain the CPU topology of PPC64 hosts 3.4 - Under review - Ability to run power machines on x86 hosts Some basic patches for PPC support were merged but not enough to enable any PPC feature. We are focused on the patches 18938, 19010 and 18220 (see below), since they are the base for all PPC features. Engine 18938 (Initial support for alternative architectures) |_19010 (Architecture parameter on search backend) |_18220 (New OS for IBM POWER support) |_21503 (Architecture dependent commands) |_21522 (Avoid migration in ppc64) 20294 (Architecture dependent commands) |_18622 (sPAPR SCSI on PPC64 VMs) |_20630 (Limit the number of SCSI and VirtIO blk devices) |_17972 (Show only compatible OSes) |_18347 (OS type validation) |_20667 (Fix VM creation with blank template) |_18702 (Fill and check arch when importing VM and Template) |_19012 (OVF import for multiple architectures) |_18226 (Cluster and arch related changes) |_19132 (Prevent arch mismatches in the FE) |_18227 (Added arch support for VM and Template) |_19487 (Selection of incompatible templates) VDSM 19395 (Hardware information about POWER hosts) |_17437 (Adding ppc64 handling to getVdsCaps) |_19396 (Report fake capabilities) |_18718 (Create VMs for the POWER architecture) |_19875 (Handling topology for ppc64) Regards Leonardo Bianconi Date: Wed, 27 Nov 2013 17:14:37 +0100 From: Sandro Bonazzola To: "Users at ovirt.org" , engine-devel Subject: [Engine-devel] oVirt PPC status update Message-ID: <52961A6D.4090208 at redhat.com> Content-Type: text/plain; charset=ISO-8859-15 Hi, anybody can report about PPC status for 3.3.2 and 3.4.0 target releases? It would be nice having someone for PPC at ovirt-sync meeting from next week on, so please join :-) Thanks, -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com From vszocs at redhat.com Thu Nov 28 17:10:21 2013 From: vszocs at redhat.com (Vojtech Szocs) Date: Thu, 28 Nov 2013 12:10:21 -0500 (EST) Subject: [Engine-devel] Weird behavior of multiple SetVmTicket query In-Reply-To: <2964430.ZczkeuaBWF@awels> References: <1405029090.20090071.1384159399724.JavaMail.root@redhat.com> <2843639.Zr1A8Fd6ET@awels> <528E123E.2050706@redhat.com> <2964430.ZczkeuaBWF@awels> Message-ID: <92332642.32394333.1385658621798.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Alexander Wels" > To: "Itamar Heim" > Cc: "Oved Ourfalli" , engine-devel at ovirt.org > Sent: Thursday, November 21, 2013 3:15:40 PM > Subject: Re: [Engine-devel] Weird behavior of multiple SetVmTicket query > > On Thursday, November 21, 2013 04:01:34 PM Itamar Heim wrote: > > On 11/21/2013 03:28 PM, Alexander Wels wrote: > > > On Thursday, November 21, 2013 07:18:42 AM Daniel Erez wrote: > > >> ----- Original Message ----- > > >> > > >>> From: "Einav Cohen" > > >>> To: "Livnat Peer" , "Eli Mesika" > > >>> , > > >>> "Omer Frenkel" , "Doron Fediuck" > > >>> , "Oved Ourfalli" Cc: > > >>> "engine-devel" > > >>> Sent: Monday, November 18, 2013 11:19:23 PM > > >>> Subject: Re: [Engine-devel] Weird behavior of multiple SetVmTicket > > >>> query > > >>> > > >>> engine-core maintainers - this one is mainly for you - see below. > > >>> the most important question (I think) is: Is there any reason > > >>> to not introduced a "sync" flavor of RunMultipleActions (i.e. > > >>> one that will return from the backend only when all actions have > > >>> been completed, similarly to RunAction)? > > >> > > >> There's a couple of years old patch exactly for that [1]. > > >> It should allow both synchronous and asynchronous multiple actions > > >> according to a flag. Question is when do we want to use the synchronous > > >> flavor? The reasoning behind the current implementation is to return a > > >> quick response to the client, as executing multiple vdsm commands can > > >> potentially require a long wait. Do we need to introduce a sync version > > >> just for VM console connection flow? IIRC, the flow actually uses > > >> multiple calls to the singular form (RunAction) rather than > > >> RunMultipleAction? > > >> > > >> [1] http://gerrit.ovirt.org/#/c/3210/ > > > > > > We recently introduced a patch [1] that on the front-end is smart enough > > > to > > > consolidate multiple query/actions into a single > > > runMultiple(Query/Action) > > > call to reduce the number http requests to the back-end. In the > > > SetVMTicket > > > case it combined two actions into one runMultipleAction call and was > > > expected that to return once all the actions where complete, which didn't > > > happen causing some undesired behavior on the client side. This sparked > > > the investigation that ended in this email. > > > > > > So yes I would definitely like a 'synchronous' version of > > > runMultipleAction so the frontend code can set that flag when combining > > > multiple actions into a single call. We can only safely do this if we are > > > combining several runActions as all of those are 'synchronous'. > > > > > > [1] http://gerrit.ovirt.org/#/c/17356/ > > > > btw, how is this going to work with the REST API? > > > > I believe that is one of the outstanding issues with regards to the REST API > transition. Before this optimization we already had code calling > runMultiple(Query/Action) and we will have to figure something out for the > REST > API there as well. I think at the point we solve that issue we can decide if > we want to keep the optimization or not. Yes, UI code currently reflects (and uses) what internal Backend API offers. This is why I mentioned we will eventually have to move away from query/action concept (RPC-method-centric) to REST resource/operation concept (resource-centric). GenericApiGWTService server-side implementation (aka GWT RPC endpoint) more or less delegates to BackendLocal which exposes methods such as RunMultipleActions by itself. To emulate RunMultipleActions when using REST API, assuming there is no such support provided by REST backend, we'll have to do that via oVirt.js library. > > > >>> ---- > > >>> Thanks, > > >>> Einav > > >>> > > >>> ----- Original Message ----- > > >>> > > >>>> From: "Vojtech Szocs" > > >>>> To: awels at redhat.com > > >>>> Cc: "engine-devel" > > >>>> Sent: Tuesday, November 12, 2013 6:40:18 AM > > >>>> Subject: Re: [Engine-devel] Weird behavior of multiple SetVmTicket > > >>>> query > > >>>> > > >>>> Forwarding this email to engine-devel so that backend maintainers are > > >>>> aware > > >>>> of this issue. > > >>>> > > >>>> Looking at the code: > > >>>> > > >>>> - MultipleActionsRunner#Execute first creates and "validates" all > > > > > > commands: > > >>>> A. the "for" block which iterates over getParameters() > > >>>> > > >>>> 1-> validate correlation ID, if OK create and add command, > > >>>> otherwise > > >>>> add > > >>>> returnValue > > >>>> > > >>>> B the "if" block which tests getCommands().size() > > >>>> > > >>>> 1-> if single command to execute, add its "canDoActionOnly" > > >>>> returnValue, > > >>>> which is returnValue with canDoAction but without actual result > > >>>> object > > >>>> 2-> if multi commands to execute, execute chunks of max. 10 > > >>>> threads > > >>>> (sequentially, ThreadPoolUtil.invokeAll returns after all > > >>>> threads > > >>>> complete), same returnValue as above > > >>>> > > >>>> C. the "if" block which tests canRunActions > > >>>> > > >>>> 1-> all commands are executed within SINGLE THREAD due to > > >>>> ThreadPoolUtil.execute(Runnable), which is kind of weird > > >>>> comapred > > >>>> to > > >>>> how returnValues are prepared (see B2) > > >>>> 2-> when executing command, code DOES NOT CARE about its > > >>>> returnValue, > > >>>> i.e. returnValue was already prepared (see B) and command > > >>>> execution > > >>>> should just update it > > >>>> > > >>>> The problem (I think) is that C1 starts a different thread (to execute > > >>>> all > > >>>> commands) and immediately returns, i.e. code doesn't wait for thread > > >>>> to > > >>>> complete. This is why returnValues are observed on frontend as > > >>>> inconsistent. > > >>>> > > >>>> Additionally, we're also mixing of two different things: canDoAction > > >>>> processing and returnValues processing. IMHO this should be refactored > > >>>> to > > >>>> make code easier to read. > > >>>> > > >>>> Changes done by Alex (patch attached): > > >>>> > > >>>> X1. returnValues changed to Collections.synchronizedList > > >>>> > > >>>> -> this means all access to returnValues is now serial > > >>>> -> iteration over synchronizedList should also be enclosed in > > >>>> > > >>>> "synchronized (list)" block, so this: > > >>>> for (VdcReturnValueBase value : returnValues) ... > > >>>> > > >>>> should be this: > > >>>> synchronized (returnValues) { for (VdcReturnValueBase > > >>>> value > > >>>> : > > >>>> returnValues) ... } > > >>>> > > >>>> X2. commented-out original command execution via > > >>>> ThreadPoolUtil.execute(Runnable) > > >>>> > > >>>> -> new RunCommands method invokes all commands each in separate > > >>>> thread > > >>>> via ThreadPoolUtil.invokeAll > > >>>> -> returnValues list is explicitly updated > > >>>> > > >>>> Guys, what do you think? > > >>>> > > >>>> Vojtech > > >>>> > > >>>> > > >>>> ----- Original Message ----- > > >>>> > > >>>>> From: "Alexander Wels" > > >>>>> To: "Frantisek Kobzik" > > >>>>> Cc: "Vojtech Szocs" > > >>>>> Sent: Monday, November 11, 2013 9:19:08 PM > > >>>>> Subject: Re: Weird behavior of multiple SetVmTicket query > > >>>>> > > >>>>> Hi, > > >>>>> > > >>>>> I did some debugging, and the problem is a race condition in the > > >>>>> MultipleActions class. The whole class seems to have a lot of > > >>>>> multi-threading > > >>>>> issues but if I modify the code to wait for the results of the > > >>>>> actions > > >>>>> to > > >>>>> return before returning the return value, everything works fine. > > >>>>> > > >>>>> I am attaching a patch that solves the issue at hand, but should not > > >>>>> be > > >>>>> considered a real patch. It is just to show the issue is in the > > >>>>> back-end > > >>>>> not > > >>>>> the front-end code. The front-end code is just exposing an issue in > > >>>>> the > > >>>>> back- > > >>>>> end > > >>>>> > > >>>>> Alexander > > >>>>> > > >>>>> On Monday, November 11, 2013 09:53:22 AM you wrote: > > >>>>>> Ok, thank you very much! > > >>>>>> > > >>>>>> ----- Original Message ----- > > >>>>>> From: "Alexander Wels" > > >>>>>> To: "Frantisek Kobzik" > > >>>>>> Sent: Monday, November 11, 2013 2:15:43 PM > > >>>>>> Subject: Re: Weird behavior of multiple SetVmTicket query > > >>>>>> > > >>>>>> Frantisek, > > >>>>>> > > >>>>>> I had seen this before, let me test and fix it for you, it is very > > >>>>>> likely > > >>>>>> my > > >>>>>> patch broke that. > > >>>>>> > > >>>>>> Alexander > > >>>>>> > > >>>>>> On Monday, November 11, 2013 03:43:19 AM you wrote: > > >>>>>>> Hi Alex, > > >>>>>>> > > >>>>>>> recently I noticed problems with invoking console for multiple VMs > > >>>>>>> (select > > >>>>>>> more VMs in webadmin and then hit the console btn). I was sure it > > >>>>>>> worked > > >>>>>>> in > > >>>>>>> past so i git-bisected the master branch and I discovered that > > >>>>>>> this > > >>>>>>> problem > > >>>>>>> is apparently caused by patch [1]. For single vm console > > >>>>>>> invocation > > >>>>>>> it > > >>>>>>> works fine, but for multiple VMs it doesn't. > > >>>>>>> > > >>>>>>> I did some closer investigation with a debugger and it seems that > > >>>>>>> getSucceeded() on the return val of SetVmTicket command returns > > >>>>>>> false > > >>>>>>> in > > >>>>>>> case of multiple execution despite the fact SetVmTicketCommand > > >>>>>>> sets > > >>>>>>> this > > >>>>>>> value to true. I suppose there is some problem with propagation of > > >>>>>>> command > > >>>>>>> return value from BE to FE. The same goes for the encapsulated > > >>>>>>> returnValue > > >>>>>>> attribute (it contains value of the generated ticket). When > > >>>>>>> invoking > > >>>>>>> multiple consoles it is null (although it has been filled on > > >>>>>>> backend). > > >>>>>>> Weird. > > >>>>>>> > > >>>>>>> Tomas told me you did some optimizations for multiple command > > >>>>>>> executions, > > >>>>>>> do you know it might cause it? Please let me know if you have any > > >>>>>>> idea... > > >>>>>>> > > >>>>>>> Cheers, > > >>>>>>> F. > > >>>>>>> > > >>>>>>> [1]: http://gerrit.ovirt.org/#/c/17356/ > > >>>> > > >>>> _______________________________________________ > > >>>> Engine-devel mailing list > > >>>> Engine-devel at ovirt.org > > >>>> http://lists.ovirt.org/mailman/listinfo/engine-devel > > >>> > > >>> _______________________________________________ > > >>> Engine-devel mailing list > > >>> Engine-devel at ovirt.org > > >>> http://lists.ovirt.org/mailman/listinfo/engine-devel > > >> > > >> _______________________________________________ > > >> Engine-devel mailing list > > >> Engine-devel at ovirt.org > > >> http://lists.ovirt.org/mailman/listinfo/engine-devel > > > > > > _______________________________________________ > > > Engine-devel mailing list > > > Engine-devel at ovirt.org > > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > From vszocs at redhat.com Thu Nov 28 19:22:33 2013 From: vszocs at redhat.com (Vojtech Szocs) Date: Thu, 28 Nov 2013 14:22:33 -0500 (EST) Subject: [Engine-devel] Using REST API in web UI - review call summary In-Reply-To: <5291B3A5.5060305@redhat.com> References: <1515483885.28819526.1385068697947.JavaMail.root@redhat.com> <5291B3A5.5060305@redhat.com> Message-ID: <1131535003.32427980.1385666553819.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Michael Pasternak" > To: "Vojtech Szocs" > Cc: "engine-devel" > Sent: Sunday, November 24, 2013 9:07:01 AM > Subject: Re: [Engine-devel] Using REST API in web UI - review call summary > > > > Hi Vojtech, > > First of all it was a good "presentation" of requirements + suggested > solutions - well done!, Thank you :) > few comments/questions inline. > > On 11/21/2013 11:18 PM, Vojtech Szocs wrote: > > Hi guys, > > > > this is a summary of yesterday's review call, I'll try to highlight > > important Q/A and things we agreed on. > > Feel free to add anything in case I've missed something. > > > > -- > > > > Q: Why don't we simply try to use existing Java SDK and adapt it for GWT > > apps? (asked by Michael & Gilad) > > > > A: This might be a viable option to consider if we wanted to skip > > JavaScript-based SDK altogether and target Java/GWT code > > directly; we could simply take Java SDK and customize its abstractions > > where necessary, i.e. using HTTP transport layer > > implementation that works with GWT. In any case, this would mean coupling > > ourselves to Java SDK (which has its own release cycle) > > and I think this would complicate things for us. > > not sure i buy this one :), this is the purpose of any sdk, including the > one you about to write, people that will use it, will be "coupling" to it ... Of course, but by saying "coupling ourselves to Java SDK" I meant SDK perspective, not client perspective: - someone else (you) maintains Java SDK and therefore controls generated sources (JAR or RPM isn't relevant here) - another guy (me) maintains (fictional) Java/GWT SDK that relies on Java SDK + some (supported) customizations - the only way I can impose changes in my SDK is through supported customizations as you control original (Java SDK) sources, i.e. the whole code generation process is driven by your SDK, so my SDK is coupled to your SDK's build/release cycle For the sake of simplicity, I guess it's best to start with SDK that has no dependencies whatsoever. After all, there's no common dependency (aside from running Engine to provide XSD & RSDL) between Java & Python SDK too, if I understand correctly. In other words, building on top of something existing (just because we can do that) isn't always appropriate/flexible/efficient, it always depends on given context and requirements. > > > > > As proposed on the meeting, I think it's best to aim for JavaScript SDK as > > the lowest > > common denominator for *any* web application that wants to work with REST > > API. oVirt GWT-based > > UI can simply bind to JavaScript SDK, i.e. Java/GWT code that just overlays > > objects and functions > > provided by JavaScript SDK. Another reason is ease of maintenance - I'd > > rather see JavaScript SDK's code > > generation process to be independent of any other SDK (people responsible > > for maintaining JavaScript SDK > > should have full control over generated code). > > what do you mean by "people should have full control over generated code"? It's related to "coupling from SDK perspective" I mentioned above: "the only way I can impose changes in my SDK is through supported customizations as you control original (Java SDK) sources" (by "people" I meant "JavaScript SDK developers") Full control means ability to change generated sources in whatever way desired, but assuming the idea of reusing/customizing existing SDK code, aspect of full control is lost in favor of reusing existing code. And of course, this assumes that existing code (Java SDK) provides everything we need, which might or might not be the case. So I just vote for simplicity, generate JavaScript SDK the way like other SDKs (Java/Python) - not trying to reuse anything, just grab XSD & RSDL and generate sources. > the purpose of > code generation is to ease maintenance, i.e you/maintainer should not write > the feature > once it available in api, just run CodeGen and you'll get it for free, but > this is zero control > over code. +1 I agree with you on this. > > > > > -- > > > > Q: What about functionality currently used by oVirt UI but not supported by > > REST API? (asked by Einav) > > [For example, fetching VM entity over GWT RPC also returns related data > > such as Cluster name.] > > > > A: Based on discussion I've had with other colleagues after yesterday's > > review call, I don't think that > > separate support-like backend layer is a good idea. Instead, this is the > > kind of functionality that could be > > placed in oVirt.js library. Logical operations like "get VMs and related > > data" would be exposed through oVirt.js > > (callback-based) API and ultimately realized as multiple physical requests > > to REST API via JavaScript Binding. > > > > oVirt.js client would be completely oblivious to the fact that multiple > > physical requests are dispatched. In fact, > > since HTTP communication is asynchronous in nature, oVirt.js client > > wouldn't even notice any difference in terms of API > > consumption. This assumes JavaScript SDK would use callback-based > > (non-blocking) API instead of blocking one - after all, > > blocking API on top of non-blocking implementation sounds pretty much like > > leaky abstraction [1]. > > > > For example: > > > > sdk.getVmsWithExtraData( > > callbackToGetExtraDataForGivenVm, // might cause extra physical > > requests to REST API > > callbackFiredWhenAllDataIsReady // update client only when all > > data is ready > > ) > > actually this the main bottleneck in moving UI to work on top of REST, and > most interesting/complex part of this project, Agreed, it's because UI "got used to" using internal backend interface concepts (actions, queries etc.) in the first place.. So we'll have to emulate what we used to use to prevent regressions, maybe improve/refactor in future. > > you should think of very wise polling mechanism cause callbacks is a nice > thing on paper, but behind the scene it all about polling: > > - the entity/s till action got accomplished > - add to this updating different grids > - running multiple actions > - showing events > - and obviously much more IMHO polling is just a workaround and indicates lack of proper notification solution. Apparently, oVirt web UI isn't some CLI program for which HTTP request/response style is sufficient. oVirt web UI is dynamic, interactive web application that displays/updates data in real time. This is, in my opinion, quite a big difference. I don't think callbacks are just a nice thing on paper. Callbacks are needed because the underlying communcation is async in nature: - caller invokes API function and provides callback to execute when operation completes -> API is non-blocking - polling attempts to detect change (i.e. operation completed) and notify the caller, so it's also some sort of callback -> this is more complicated compared to simple callback > > and don't forget that every polled entity should be marshalled from xml to > the javascript > entity so at the end, "callbacks" mechanism will be extremely CPU consuming. First of all, I don't understand how callback mechanism can be CPU consuming, can you please provide some explanation or use case? Does Java SDK provide ability to poll Engine in order to get recent updates, and if yes, why? Finally, polling makes things stateful, whereas SDK code should be stateless instead. If client wants to get recent updates, it should just use (stateless) SDK code to achieve this goal. > > > > > [1] http://en.wikipedia.org/wiki/Leaky_abstraction > > > > -- > > > > Last but not least, where to maintain JavaScript SDK projects: low-level > > JavaScript Binding + high-level oVirt.js library. > > > > I agree that conceptually both above mentioned projects should go into > > dedicated "ovirt-engine-sdk-js" git repository and > > have their own build/release process. However, for now, we're just making > > baby steps so let's keep things simple and prototype > > these projects as part of "ovirt-engine" git repository. > > > > ... we can complicate things anytime, but we should know that any complex > > system that works has inevitably evolved from simple > > system that works ... (quote from > > http://en.wikipedia.org/wiki/Gall%27s_law) > > > > Regards, > > Vojtech > > _______________________________________________ > > Engine-devel mailing list > > Engine-devel at ovirt.org > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > > > -- > > Michael Pasternak > RedHat, ENG-Virtualization R&D > From vszocs at redhat.com Thu Nov 28 19:37:36 2013 From: vszocs at redhat.com (Vojtech Szocs) Date: Thu, 28 Nov 2013 14:37:36 -0500 (EST) Subject: [Engine-devel] Using REST API in web UI - review call summary In-Reply-To: <5291BAC2.9010902@redhat.com> References: <1515483885.28819526.1385068697947.JavaMail.root@redhat.com> <528E7A30.7040503@redhat.com> <1590829306.28868001.1385071018139.JavaMail.root@redhat.com> <528E8279.40701@redhat.com> <5291BAC2.9010902@redhat.com> Message-ID: <305092398.32429154.1385667456789.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Michael Pasternak" > To: "Itamar Heim" > Cc: "Vojtech Szocs" , "engine-devel" , "Einav Cohen" > Sent: Sunday, November 24, 2013 9:37:22 AM > Subject: Re: Using REST API in web UI - review call summary > > On 11/22/2013 12:00 AM, Itamar Heim wrote: > > On 11/21/2013 11:56 PM, Vojtech Szocs wrote: > >> > >> > >> ----- Original Message ----- > >>> From: "Itamar Heim" > >>> To: "Vojtech Szocs" , "engine-devel" > >>> > >>> Cc: "Einav Cohen" > >>> Sent: Thursday, November 21, 2013 10:25:04 PM > >>> Subject: Re: Using REST API in web UI - review call summary > >>> > >>> On 11/21/2013 11:18 PM, Vojtech Szocs wrote: > >>>> Hi guys, > >>>> > >>>> this is a summary of yesterday's review call, I'll try to highlight > >>>> important Q/A and things we agreed on. Feel free to add anything in case > >>>> I've missed something. > >>>> > >>>> -- > >>>> > >>>> Q: Why don't we simply try to use existing Java SDK and adapt it for GWT > >>>> apps? (asked by Michael & Gilad) > >>>> > >>>> A: This might be a viable option to consider if we wanted to skip > >>>> JavaScript-based SDK altogether and target Java/GWT code directly; we > >>>> could simply take Java SDK and customize its abstractions where > >>>> necessary, > >>>> i.e. using HTTP transport layer implementation that works with GWT. In > >>>> any > >>>> case, this would mean coupling ourselves to Java SDK (which has its own > >>>> release cycle) and I think this would complicate things for us. > >>>> > >>>> As proposed on the meeting, I think it's best to aim for JavaScript SDK > >>>> as > >>>> the lowest common denominator for *any* web application that wants to > >>>> work > >>>> with REST API. oVirt GWT-based UI can simply bind to JavaScript SDK, > >>>> i.e. > >>>> Java/GWT code that just overlays objects and functions provided by > >>>> JavaScript SDK. Another reason is ease of maintenance - I'd rather see > >>>> JavaScript SDK's code generation process to be independent of any other > >>>> SDK (people responsible for maintaining JavaScript SDK should have full > >>>> control over generated code). > >>>> > >>>> -- > >>>> > >>>> Q: What about functionality currently used by oVirt UI but not supported > >>>> by > >>>> REST API? (asked by Einav) > >>>> [For example, fetching VM entity over GWT RPC also returns related > >>>> data > >>>> such as Cluster name.] > >>>> > >>>> A: Based on discussion I've had with other colleagues after yesterday's > >>>> review call, I don't think that separate support-like backend layer is a > >>>> good idea. Instead, this is the kind of functionality that could be > >>>> placed > >>>> in oVirt.js library. Logical operations like "get VMs and related data" > >>>> would be exposed through oVirt.js (callback-based) API and ultimately > >>>> realized as multiple physical requests to REST API via JavaScript > >>>> Binding. > >>>> > >>>> oVirt.js client would be completely oblivious to the fact that multiple > >>>> physical requests are dispatched. In fact, since HTTP communication is > >>>> asynchronous in nature, oVirt.js client wouldn't even notice any > >>>> difference in terms of API consumption. This assumes JavaScript SDK > >>>> would > >>>> use callback-based (non-blocking) API instead of blocking one - after > >>>> all, > >>>> blocking API on top of non-blocking implementation sounds pretty much > >>>> like > >>>> leaky abstraction [1]. > >>>> > >>>> For example: > >>>> > >>>> sdk.getVmsWithExtraData( > >>>> callbackToGetExtraDataForGivenVm, // might cause extra > >>>> physical > >>>> requests to REST API > >>>> callbackFiredWhenAllDataIsReady // update client only when > >>>> all > >>>> data is ready > >>>> ) > >>> > >>> would this also resolve RunMultipleActions? > >> > >> Yes, I think so. There could be API to pass multiple "actions" and get > >> notified when they complete. > >> > >>> sounds like no reason to have RunMultipleQueries, although i'm still > >>> sure a single call to engine for multiple keys would be much more > >>> efficient than multiple async calls? > >>> (I understand we may not be able to model this). > >> > >> Efficiency-wise, yes, single call to get all data seems optimal. API-wise, > >> I don't think it really matters from oVirt.js client perspective. > >> > >> We can proceed with simple (possibly inefficient) solution and improve as > >> needed. We're making baby steps now.. > >> > >>> > >>>> > >>>> [1] http://en.wikipedia.org/wiki/Leaky_abstraction > >>>> > >>>> -- > >>>> > >>>> Last but not least, where to maintain JavaScript SDK projects: low-level > >>>> JavaScript Binding + high-level oVirt.js library. > >>>> > >>>> I agree that conceptually both above mentioned projects should go into > >>>> dedicated "ovirt-engine-sdk-js" git repository and have their own > >>>> build/release process. However, for now, we're just making baby steps so > >>>> let's keep things simple and prototype these projects as part of > >>>> "ovirt-engine" git repository. > >>>> > >>>> ... we can complicate things anytime, but we should know that any > >>>> complex > >>>> system that works has inevitably evolved from simple system that works > >>>> ... > >>>> (quote from http://en.wikipedia.org/wiki/Gall%27s_law) > >>> > >>> I think the entities should just be generated from the xsd. > >> > >> +1 > >> > >> The JavaScript Binding (aka low-level SDK) module should follow same > >> concepts as existing Java SDK - generated entities decorated with > >> operations to form fluent API. > >> > >> Everything Java SDK currently offers should be available in JavaScript > >> Binding. oVirt.js is our opportunity to build on top of that. > >> > >>> for the rsdl, makes sense to start with clean code to see what works > >>> best, then see about generating it (but you should adhere the rsdl as > >>> guidlines i guess). > >> > >> +1 > >> > >> The initial prototype should be written by hand, things will get generated > >> as soon as we have better idea how the end result should look like. > > > > i can understand that for the methods and maybe for populating the entities > > for the first few. > > the entities themselves, no point in hand coding - just generated them from > > the api.xsd. > > and once you decide how you want to fill them, not worth hand coding this - > > either json gives this out of the box, or should be generated as well. > > > >> > >>> > >>> lets try to plan for lightweight entities while at it - the API has a > >>> mechanism for different level of details - maybe we need a custom level > >>> where the client specifies which fields they want back or something like > >>> that. > >> > >> Good idea! We should definitely think about the granularity of entities. > >> > >> I didn't know REST API supports different level of detail per entity, is > >> there some documentation for this feature? > > currently it's about adding adding extra information (by supplying header > [1]), > this is driven by the properties that require extra query against the engine > to > fill them, > > obviously the default is [2] > > [1] All-Content: True > [2] All-Content: False OK so if I understand correctly, "All-Content: False" (default) just returns data of given entity plus IDs of related entities, whereas "All-Content: True" returns data of given entity plus (embedded) data of related entities, is that correct? > > >> > >> Since JavaScript is dynamic, one possible solution would be to let client > >> define the entity structure (i.e. what data client needs) on the fly, > >> during runtime :) > > we talked about this solution couple of years ago, but it was obvious > that there is no real "demand" for it till UI moves to REST, I assume you mean to let client selectively specify properties of given entity when making REST call, correct? If yes, are you planning to support such feature? > > btw it won't solve the problem where to fill UI entity you need combination > of N REST entities, you still will have to perform N + 1 queries to API Of course. But we can make improvements with regard to: - optimizing queries so that client receives/parses only data it needs (see my question above) - if necessary, combine such optimized queries into bigger "logical" queries (utilizing callback mechanism) > (maybe asking for entity with fewer details), - all it address is a capacity > of the data being send. Not only that, capacity of data sent goes proportionally with time needed to parse & process such data on client. (Imagine big XML marshalling on client. This is why everyone prefers JSON nowadays, JSON naturally maps to native JavaScript structures with minimal computational overhead.) > > > > > michael? > > > >> > >>> > >>> Good luck, > >>> Itamar > >>> > > > > > -- > > Michael Pasternak > RedHat, ENG-Virtualization R&D > From vszocs at redhat.com Thu Nov 28 19:39:23 2013 From: vszocs at redhat.com (Vojtech Szocs) Date: Thu, 28 Nov 2013 14:39:23 -0500 (EST) Subject: [Engine-devel] Using REST API in web UI - review call summary In-Reply-To: <5291BB15.4050902@redhat.com> References: <1515483885.28819526.1385068697947.JavaMail.root@redhat.com> <528E7A30.7040503@redhat.com> <1590829306.28868001.1385071018139.JavaMail.root@redhat.com> <528E8279.40701@redhat.com> <396929524.28875662.1385071701788.JavaMail.root@redhat.com> <5291BB15.4050902@redhat.com> Message-ID: <2014442708.32429209.1385667563466.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Michael Pasternak" > To: "Vojtech Szocs" > Cc: "Itamar Heim" , "engine-devel" , "Einav Cohen" > Sent: Sunday, November 24, 2013 9:38:45 AM > Subject: Re: Using REST API in web UI - review call summary > > On 11/22/2013 12:08 AM, Vojtech Szocs wrote: > > > > > > ----- Original Message ----- > >> From: "Itamar Heim" > >> To: "Vojtech Szocs" > >> Cc: "engine-devel" , "Einav Cohen" > >> , "Michael Pasternak" > >> > >> Sent: Thursday, November 21, 2013 11:00:25 PM > >> Subject: Re: Using REST API in web UI - review call summary > >> > >> On 11/21/2013 11:56 PM, Vojtech Szocs wrote: > >>> > >>> > >>> ----- Original Message ----- > >>>> From: "Itamar Heim" > >>>> To: "Vojtech Szocs" , "engine-devel" > >>>> > >>>> Cc: "Einav Cohen" > >>>> Sent: Thursday, November 21, 2013 10:25:04 PM > >>>> Subject: Re: Using REST API in web UI - review call summary > >>>> > >>>> On 11/21/2013 11:18 PM, Vojtech Szocs wrote: > >>>>> Hi guys, > >>>>> > >>>>> this is a summary of yesterday's review call, I'll try to highlight > >>>>> important Q/A and things we agreed on. Feel free to add anything in > >>>>> case > >>>>> I've missed something. > >>>>> > >>>>> -- > >>>>> > >>>>> Q: Why don't we simply try to use existing Java SDK and adapt it for > >>>>> GWT > >>>>> apps? (asked by Michael & Gilad) > >>>>> > >>>>> A: This might be a viable option to consider if we wanted to skip > >>>>> JavaScript-based SDK altogether and target Java/GWT code directly; we > >>>>> could simply take Java SDK and customize its abstractions where > >>>>> necessary, > >>>>> i.e. using HTTP transport layer implementation that works with GWT. In > >>>>> any > >>>>> case, this would mean coupling ourselves to Java SDK (which has its own > >>>>> release cycle) and I think this would complicate things for us. > >>>>> > >>>>> As proposed on the meeting, I think it's best to aim for JavaScript SDK > >>>>> as > >>>>> the lowest common denominator for *any* web application that wants to > >>>>> work > >>>>> with REST API. oVirt GWT-based UI can simply bind to JavaScript SDK, > >>>>> i.e. > >>>>> Java/GWT code that just overlays objects and functions provided by > >>>>> JavaScript SDK. Another reason is ease of maintenance - I'd rather see > >>>>> JavaScript SDK's code generation process to be independent of any other > >>>>> SDK (people responsible for maintaining JavaScript SDK should have full > >>>>> control over generated code). > >>>>> > >>>>> -- > >>>>> > >>>>> Q: What about functionality currently used by oVirt UI but not > >>>>> supported > >>>>> by > >>>>> REST API? (asked by Einav) > >>>>> [For example, fetching VM entity over GWT RPC also returns related > >>>>> data > >>>>> such as Cluster name.] > >>>>> > >>>>> A: Based on discussion I've had with other colleagues after yesterday's > >>>>> review call, I don't think that separate support-like backend layer is > >>>>> a > >>>>> good idea. Instead, this is the kind of functionality that could be > >>>>> placed > >>>>> in oVirt.js library. Logical operations like "get VMs and related data" > >>>>> would be exposed through oVirt.js (callback-based) API and ultimately > >>>>> realized as multiple physical requests to REST API via JavaScript > >>>>> Binding. > >>>>> > >>>>> oVirt.js client would be completely oblivious to the fact that multiple > >>>>> physical requests are dispatched. In fact, since HTTP communication is > >>>>> asynchronous in nature, oVirt.js client wouldn't even notice any > >>>>> difference in terms of API consumption. This assumes JavaScript SDK > >>>>> would > >>>>> use callback-based (non-blocking) API instead of blocking one - after > >>>>> all, > >>>>> blocking API on top of non-blocking implementation sounds pretty much > >>>>> like > >>>>> leaky abstraction [1]. > >>>>> > >>>>> For example: > >>>>> > >>>>> sdk.getVmsWithExtraData( > >>>>> callbackToGetExtraDataForGivenVm, // might cause extra > >>>>> physical > >>>>> requests to REST API > >>>>> callbackFiredWhenAllDataIsReady // update client only when > >>>>> all > >>>>> data is ready > >>>>> ) > >>>> > >>>> would this also resolve RunMultipleActions? > >>> > >>> Yes, I think so. There could be API to pass multiple "actions" and get > >>> notified when they complete. > >>> > >>>> sounds like no reason to have RunMultipleQueries, although i'm still > >>>> sure a single call to engine for multiple keys would be much more > >>>> efficient than multiple async calls? > >>>> (I understand we may not be able to model this). > >>> > >>> Efficiency-wise, yes, single call to get all data seems optimal. > >>> API-wise, > >>> I don't think it really matters from oVirt.js client perspective. > >>> > >>> We can proceed with simple (possibly inefficient) solution and improve as > >>> needed. We're making baby steps now.. > >>> > >>>> > >>>>> > >>>>> [1] http://en.wikipedia.org/wiki/Leaky_abstraction > >>>>> > >>>>> -- > >>>>> > >>>>> Last but not least, where to maintain JavaScript SDK projects: > >>>>> low-level > >>>>> JavaScript Binding + high-level oVirt.js library. > >>>>> > >>>>> I agree that conceptually both above mentioned projects should go into > >>>>> dedicated "ovirt-engine-sdk-js" git repository and have their own > >>>>> build/release process. However, for now, we're just making baby steps > >>>>> so > >>>>> let's keep things simple and prototype these projects as part of > >>>>> "ovirt-engine" git repository. > >>>>> > >>>>> ... we can complicate things anytime, but we should know that any > >>>>> complex > >>>>> system that works has inevitably evolved from simple system that works > >>>>> ... > >>>>> (quote from http://en.wikipedia.org/wiki/Gall%27s_law) > >>>> > >>>> I think the entities should just be generated from the xsd. > >>> > >>> +1 > >>> > >>> The JavaScript Binding (aka low-level SDK) module should follow same > >>> concepts as existing Java SDK - generated entities decorated with > >>> operations to form fluent API. > >>> > >>> Everything Java SDK currently offers should be available in JavaScript > >>> Binding. oVirt.js is our opportunity to build on top of that. > >>> > >>>> for the rsdl, makes sense to start with clean code to see what works > >>>> best, then see about generating it (but you should adhere the rsdl as > >>>> guidlines i guess). > >>> > >>> +1 > >>> > >>> The initial prototype should be written by hand, things will get > >>> generated > >>> as soon as we have better idea how the end result should look like. > >> > >> i can understand that for the methods and maybe for populating the > >> entities for the first few. > >> the entities themselves, no point in hand coding - just generated them > >> from the api.xsd. > >> and once you decide how you want to fill them, not worth hand coding > >> this - either json gives this out of the box, or should be generated as > >> well. > > > > OK, now I get you :) sure, entities aren't too interesting by themselves, > > but populating (decorating) them is something that requires more thought. > > you have Java-SDK that does this already, so it should be relativity easy > to take it from there. Yes, Java SDK will be our reference when developing JavaScript binding for REST API [1]: "It would contain everything currently offered by existing Java SDK". [1] http://www.ovirt.org/Features/Design/Using_REST_API_In_Web_UI#REST_API_JavaScript_Binding > > > > >> > >>> > >>>> > >>>> lets try to plan for lightweight entities while at it - the API has a > >>>> mechanism for different level of details - maybe we need a custom level > >>>> where the client specifies which fields they want back or something like > >>>> that. > >>> > >>> Good idea! We should definitely think about the granularity of entities. > >>> > >>> I didn't know REST API supports different level of detail per entity, is > >>> there some documentation for this feature? > >>> > >>> Since JavaScript is dynamic, one possible solution would be to let client > >>> define the entity structure (i.e. what data client needs) on the fly, > >>> during runtime :) > >> > >> michael? > >> > >>> > >>>> > >>>> Good luck, > >>>> Itamar > >>>> > >> > >> > > > -- > > Michael Pasternak > RedHat, ENG-Virtualization R&D > From vszocs at redhat.com Thu Nov 28 19:59:43 2013 From: vszocs at redhat.com (Vojtech Szocs) Date: Thu, 28 Nov 2013 14:59:43 -0500 (EST) Subject: [Engine-devel] Using REST API in web UI - review call summary In-Reply-To: <1907582060.18476696.1385286315752.JavaMail.root@redhat.com> References: <1515483885.28819526.1385068697947.JavaMail.root@redhat.com> <528E7A30.7040503@redhat.com> <1590829306.28868001.1385071018139.JavaMail.root@redhat.com> <528E8279.40701@redhat.com> <5291BAC2.9010902@redhat.com> <1907582060.18476696.1385286315752.JavaMail.root@redhat.com> Message-ID: <1443226802.32429921.1385668783215.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Antoni Segura Puimedon" > To: "Michael Pasternak" > Cc: "engine-devel" > Sent: Sunday, November 24, 2013 10:45:15 AM > Subject: Re: [Engine-devel] Using REST API in web UI - review call summary > > > > ----- Original Message ----- > > From: "Michael Pasternak" > > To: "Itamar Heim" > > Cc: "engine-devel" > > Sent: Sunday, November 24, 2013 9:37:22 AM > > Subject: Re: [Engine-devel] Using REST API in web UI - review call summary > > > > On 11/22/2013 12:00 AM, Itamar Heim wrote: > > > On 11/21/2013 11:56 PM, Vojtech Szocs wrote: > > >> > > >> > > >> ----- Original Message ----- > > >>> From: "Itamar Heim" > > >>> To: "Vojtech Szocs" , "engine-devel" > > >>> > > >>> Cc: "Einav Cohen" > > >>> Sent: Thursday, November 21, 2013 10:25:04 PM > > >>> Subject: Re: Using REST API in web UI - review call summary > > >>> > > >>> On 11/21/2013 11:18 PM, Vojtech Szocs wrote: > > >>>> Hi guys, > > >>>> > > >>>> this is a summary of yesterday's review call, I'll try to highlight > > >>>> important Q/A and things we agreed on. Feel free to add anything in > > >>>> case > > >>>> I've missed something. > > >>>> > > >>>> -- > > >>>> > > >>>> Q: Why don't we simply try to use existing Java SDK and adapt it for > > >>>> GWT > > >>>> apps? (asked by Michael & Gilad) > > >>>> > > >>>> A: This might be a viable option to consider if we wanted to skip > > >>>> JavaScript-based SDK altogether and target Java/GWT code directly; we > > >>>> could simply take Java SDK and customize its abstractions where > > >>>> necessary, > > >>>> i.e. using HTTP transport layer implementation that works with GWT. In > > >>>> any > > >>>> case, this would mean coupling ourselves to Java SDK (which has its > > >>>> own > > >>>> release cycle) and I think this would complicate things for us. > > >>>> > > >>>> As proposed on the meeting, I think it's best to aim for JavaScript > > >>>> SDK > > >>>> as > > >>>> the lowest common denominator for *any* web application that wants to > > >>>> work > > >>>> with REST API. oVirt GWT-based UI can simply bind to JavaScript SDK, > > >>>> i.e. > > >>>> Java/GWT code that just overlays objects and functions provided by > > >>>> JavaScript SDK. Another reason is ease of maintenance - I'd rather see > > >>>> JavaScript SDK's code generation process to be independent of any > > >>>> other > > >>>> SDK (people responsible for maintaining JavaScript SDK should have > > >>>> full > > >>>> control over generated code). > > >>>> > > >>>> -- > > >>>> > > >>>> Q: What about functionality currently used by oVirt UI but not > > >>>> supported > > >>>> by > > >>>> REST API? (asked by Einav) > > >>>> [For example, fetching VM entity over GWT RPC also returns > > >>>> related > > >>>> data > > >>>> such as Cluster name.] > > >>>> > > >>>> A: Based on discussion I've had with other colleagues after > > >>>> yesterday's > > >>>> review call, I don't think that separate support-like backend layer is > > >>>> a > > >>>> good idea. Instead, this is the kind of functionality that could be > > >>>> placed > > >>>> in oVirt.js library. Logical operations like "get VMs and related > > >>>> data" > > >>>> would be exposed through oVirt.js (callback-based) API and ultimately > > >>>> realized as multiple physical requests to REST API via JavaScript > > >>>> Binding. > > >>>> > > >>>> oVirt.js client would be completely oblivious to the fact that > > >>>> multiple > > >>>> physical requests are dispatched. In fact, since HTTP communication is > > >>>> asynchronous in nature, oVirt.js client wouldn't even notice any > > >>>> difference in terms of API consumption. This assumes JavaScript SDK > > >>>> would > > >>>> use callback-based (non-blocking) API instead of blocking one - after > > >>>> all, > > >>>> blocking API on top of non-blocking implementation sounds pretty much > > >>>> like > > >>>> leaky abstraction [1]. > > >>>> > > >>>> For example: > > >>>> > > >>>> sdk.getVmsWithExtraData( > > >>>> callbackToGetExtraDataForGivenVm, // might cause extra > > >>>> physical > > >>>> requests to REST API > > >>>> callbackFiredWhenAllDataIsReady // update client only when > > >>>> all > > >>>> data is ready > > >>>> ) > > >>> > > >>> would this also resolve RunMultipleActions? > > >> > > >> Yes, I think so. There could be API to pass multiple "actions" and get > > >> notified when they complete. > > >> > > >>> sounds like no reason to have RunMultipleQueries, although i'm still > > >>> sure a single call to engine for multiple keys would be much more > > >>> efficient than multiple async calls? > > >>> (I understand we may not be able to model this). > > >> > > >> Efficiency-wise, yes, single call to get all data seems optimal. > > >> API-wise, > > >> I don't think it really matters from oVirt.js client perspective. > > >> > > >> We can proceed with simple (possibly inefficient) solution and improve > > >> as > > >> needed. We're making baby steps now.. > > >> > > >>> > > >>>> > > >>>> [1] http://en.wikipedia.org/wiki/Leaky_abstraction > > >>>> > > >>>> -- > > >>>> > > >>>> Last but not least, where to maintain JavaScript SDK projects: > > >>>> low-level > > >>>> JavaScript Binding + high-level oVirt.js library. > > >>>> > > >>>> I agree that conceptually both above mentioned projects should go into > > >>>> dedicated "ovirt-engine-sdk-js" git repository and have their own > > >>>> build/release process. However, for now, we're just making baby steps > > >>>> so > > >>>> let's keep things simple and prototype these projects as part of > > >>>> "ovirt-engine" git repository. > > >>>> > > >>>> ... we can complicate things anytime, but we should know that any > > >>>> complex > > >>>> system that works has inevitably evolved from simple system that works > > >>>> ... > > >>>> (quote from http://en.wikipedia.org/wiki/Gall%27s_law) > > >>> > > >>> I think the entities should just be generated from the xsd. > > >> > > >> +1 > > >> > > >> The JavaScript Binding (aka low-level SDK) module should follow same > > >> concepts as existing Java SDK - generated entities decorated with > > >> operations to form fluent API. > > >> > > >> Everything Java SDK currently offers should be available in JavaScript > > >> Binding. oVirt.js is our opportunity to build on top of that. > > >> > > >>> for the rsdl, makes sense to start with clean code to see what works > > >>> best, then see about generating it (but you should adhere the rsdl as > > >>> guidlines i guess). > > >> > > >> +1 > > >> > > >> The initial prototype should be written by hand, things will get > > >> generated > > >> as soon as we have better idea how the end result should look like. > > > > > > i can understand that for the methods and maybe for populating the > > > entities > > > for the first few. > > > the entities themselves, no point in hand coding - just generated them > > > from > > > the api.xsd. > > > and once you decide how you want to fill them, not worth hand coding this > > > - > > > either json gives this out of the box, or should be generated as well. > > > > > >> > > >>> > > >>> lets try to plan for lightweight entities while at it - the API has a > > >>> mechanism for different level of details - maybe we need a custom level > > >>> where the client specifies which fields they want back or something > > >>> like > > >>> that. > > >> > > >> Good idea! We should definitely think about the granularity of entities. > > >> > > >> I didn't know REST API supports different level of detail per entity, is > > >> there some documentation for this feature? > > > > currently it's about adding adding extra information (by supplying header > > [1]), > > this is driven by the properties that require extra query against the > > engine > > to > > fill them, > > > > obviously the default is [2] > > > > [1] All-Content: True > > [2] All-Content: False > > > > >> > > >> Since JavaScript is dynamic, one possible solution would be to let > > >> client > > >> define the entity structure (i.e. what data client needs) on the fly, > > >> during runtime :) > > > > we talked about this solution couple of years ago, but it was obvious > > that there is no real "demand" for it till UI moves to REST, > > > > btw it won't solve the problem where to fill UI entity you need combination > > of N REST entities, you still will have to perform N + 1 queries to API > > (maybe asking for entity with fewer details), - all it address is a > > capacity > > of the data being send. > > For this problem of content filtering and retrieve associated data in a > "restful" > way I saw Yoga http://yoga.skyscreamer.org/ > > some example usage: http://www.infoq.com/articles/json-yoga This looks exactly what we'd like to do :) filtering entity data plus retrieving related data all in one request. Michael, what is your opinion on this? Could we integrate Yoga with our RESTEasy-based infra? > > > > > > > > > michael? > > > > > >> > > >>> > > >>> Good luck, > > >>> Itamar > > >>> > > > > > > > > > -- > > > > Michael Pasternak > > RedHat, ENG-Virtualization R&D > > _______________________________________________ > > Engine-devel mailing list > > Engine-devel at ovirt.org > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > From kmayilsa at redhat.com Fri Nov 29 08:16:08 2013 From: kmayilsa at redhat.com (Kanagaraj) Date: Fri, 29 Nov 2013 13:46:08 +0530 Subject: [Engine-devel] Using config values Message-ID: <52984D48.1070009@redhat.com> Hi All, The are some issues arising in configurations whenever we move up on the versions(3.3 => 3.4), because of the way we store and interpret them. Whenever there is a new cluster level, you will need to add a new entry for all(most) of the configuration. Mostly a copy paste if you see from 3.2 to 3.3, except some CPU/PM type related configurations. Better option would be to have the defaul config value in ConfigValues.java and the overrides will go to config.sql. In this approach you don't need a new entries to config.sql when there is a new cluster level. Lets take an exmaple, "SupportForceCreateVG" - This is supported from 3.1 onwards, If you look at config.sql, you will see following entries select fn_db_add_config_value('SupportForceCreateVG','false','3.0'); select fn_db_add_config_value('SupportForceCreateVG','true','3.1'); select fn_db_add_config_value('SupportForceCreateVG','true','3.2'); select fn_db_add_config_value('SupportForceCreateVG','true','3.3'); And in ConfigValues.java @TypeConverterAttribute(Boolean.class) @DefaultValueAttribute("false") SupportForceCreateVG, Now if there is 3.4 and 3.5, the user needs to add 2 more entries, which i feel is redundant. Instead we can make @TypeConverterAttribute(Boolean.class) @DefaultValueAttribute("true") SupportForceCreateVG, and have only the following in config.sql select fn_db_add_config_value('SupportForceCreateVG','false','3.0'); if a particular value(for a specific cluster level) is not found in Config.sql, the fallback is to use the value available in ConfigValues.java. Please share your thoughts on this. Thanks, Kanagaraj -------------- next part -------------- An HTML attachment was scrubbed... URL: From sabose at redhat.com Fri Nov 29 09:06:33 2013 From: sabose at redhat.com (Sahina Bose) Date: Fri, 29 Nov 2013 14:36:33 +0530 Subject: [Engine-devel] Using config values In-Reply-To: <52984D48.1070009@redhat.com> References: <52984D48.1070009@redhat.com> Message-ID: <52985919.2050109@redhat.com> On 11/29/2013 01:46 PM, Kanagaraj wrote: > Hi All, > > The are some issues arising in configurations whenever we move up on > the versions(3.3 => 3.4), because of the way we store and interpret them. > > Whenever there is a new cluster level, you will need to add a new > entry for all(most) of the configuration. Mostly a copy paste if you > see from 3.2 to 3.3, except some CPU/PM type related configurations. > Better option would be to have the defaul config value in > ConfigValues.java and the overrides will go to config.sql. In this > approach you don't need a new entries to config.sql when there is a > new cluster level. > > Lets take an exmaple, "SupportForceCreateVG" - This is supported from > 3.1 onwards, > > If you look at config.sql, you will see following entries > select fn_db_add_config_value('SupportForceCreateVG','false','3.0'); > select fn_db_add_config_value('SupportForceCreateVG','true','3.1'); > select fn_db_add_config_value('SupportForceCreateVG','true','3.2'); > select fn_db_add_config_value('SupportForceCreateVG','true','3.3'); > > And in ConfigValues.java > > @TypeConverterAttribute(Boolean.class) > @DefaultValueAttribute("false") > SupportForceCreateVG, > > Now if there is 3.4 and 3.5, the user needs to add 2 more entries, > which i feel is redundant. > > Instead we can make > > @TypeConverterAttribute(Boolean.class) > @DefaultValueAttribute("true") > SupportForceCreateVG, > > and have only the following in config.sql > select fn_db_add_config_value('SupportForceCreateVG','false','3.0'); > > if a particular value(for a specific cluster level) is not found in > Config.sql, the fallback is to use the value available in > ConfigValues.java. > > Please share your thoughts on this. +1 > > Thanks, > Kanagaraj > > > > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel -------------- next part -------------- An HTML attachment was scrubbed... URL: From mpastern at redhat.com Fri Nov 29 09:45:35 2013 From: mpastern at redhat.com (Michael Pasternak) Date: Fri, 29 Nov 2013 11:45:35 +0200 Subject: [Engine-devel] Using REST API in web UI - review call summary In-Reply-To: <1131535003.32427980.1385666553819.JavaMail.root@redhat.com> References: <1515483885.28819526.1385068697947.JavaMail.root@redhat.com> <5291B3A5.5060305@redhat.com> <1131535003.32427980.1385666553819.JavaMail.root@redhat.com> Message-ID: <5298623F.6080605@redhat.com> On 11/28/2013 09:22 PM, Vojtech Szocs wrote: > > > ----- Original Message ----- >> From: "Michael Pasternak" >> To: "Vojtech Szocs" >> Cc: "engine-devel" >> Sent: Sunday, November 24, 2013 9:07:01 AM >> Subject: Re: [Engine-devel] Using REST API in web UI - review call summary >> >> >> >> Hi Vojtech, >> >> First of all it was a good "presentation" of requirements + suggested >> solutions - well done!, > > Thank you :) > >> few comments/questions inline. >> >> On 11/21/2013 11:18 PM, Vojtech Szocs wrote: >>> Hi guys, >>> >>> this is a summary of yesterday's review call, I'll try to highlight >>> important Q/A and things we agreed on. >>> Feel free to add anything in case I've missed something. >>> >>> -- >>> >>> Q: Why don't we simply try to use existing Java SDK and adapt it for GWT >>> apps? (asked by Michael & Gilad) >>> >>> A: This might be a viable option to consider if we wanted to skip >>> JavaScript-based SDK altogether and target Java/GWT code >>> directly; we could simply take Java SDK and customize its abstractions >>> where necessary, i.e. using HTTP transport layer >>> implementation that works with GWT. In any case, this would mean coupling >>> ourselves to Java SDK (which has its own release cycle) >>> and I think this would complicate things for us. >> >> not sure i buy this one :), this is the purpose of any sdk, including the >> one you about to write, people that will use it, will be "coupling" to it ... > > Of course, but by saying "coupling ourselves to Java SDK" I meant SDK perspective, not client perspective: of course, but you told something different, that you want js-sdk to be aware of the client, and this is actually why you taking this path. > > - someone else (you) maintains Java SDK and therefore controls generated sources (JAR or RPM isn't relevant here) > - another guy (me) maintains (fictional) Java/GWT SDK that relies on Java SDK + some (supported) customizations > - the only way I can impose changes in my SDK is through supported customizations as you control original (Java SDK) sources, > i.e. the whole code generation process is driven by your SDK, so my SDK is coupled to your SDK's build/release cycle that's how things working in software, you always depending on the certain version of the component you're working against, as it expose set of features you need, i don't think that having control over framework features, justifying rewriting the framework ... (please note that i'm not against the js-sdk, go ahead, this is a nice initiative indeed, i just can't see the business case for not reusing existent infrastructure cause it works for all your needs and eventually both worlds would benefiting from it UI and java-sdk users cause you where extending it with additional capabilities they may also need) > > For the sake of simplicity, I guess it's best to start with SDK that has no dependencies whatsoever. so why won't you rewrite the engine in Java-script? your js-sdk eventually will be depending on it, this way you'll have control over it (and it's features) as well ;-) > After all, there's no common dependency (aside from running Engine to provide XSD & RSDL) between Java & Python SDK too, if I understand correctly. > > In other words, building on top of something existing (just because we can do that) isn't always appropriate/flexible/efficient, it always depends on given context and requirements. it would be true, if your requirements would make existing infrastructure inappropriate. > >> >>> >>> As proposed on the meeting, I think it's best to aim for JavaScript SDK as >>> the lowest >>> common denominator for *any* web application that wants to work with REST >>> API. oVirt GWT-based >>> UI can simply bind to JavaScript SDK, i.e. Java/GWT code that just overlays >>> objects and functions >>> provided by JavaScript SDK. Another reason is ease of maintenance - I'd >>> rather see JavaScript SDK's code >>> generation process to be independent of any other SDK (people responsible >>> for maintaining JavaScript SDK >>> should have full control over generated code). >> >> what do you mean by "people should have full control over generated code"? > > It's related to "coupling from SDK perspective" I mentioned above: > "the only way I can impose changes in my SDK is through supported customizations as you control original (Java SDK) sources" if you need additional functionality in java-sdk, you could do the following: 1. submit a patch to java-sdk 2. build new java-sdk locally and use it along with new feature you've added 3. make UI depending on next version of java-sdk (which includes your new feature) we (and all other SW projects) doing that day by day in engine,api,etc. (as i mentioned this would also benefit java-sdk users with additional features they might find useful as well) > > (by "people" I meant "JavaScript SDK developers") > > Full control means ability to change generated sources in whatever way desired, but assuming the idea of reusing/customizing existing SDK code, aspect of full control is lost in favor of reusing existing code. i disagree on this one, you have all control you need over java-sdk at any time as it one of indoor projects. > And of course, this assumes that existing code (Java SDK) provides everything we need, which might or might not be the case. > > So I just vote for simplicity, generate JavaScript SDK the way like other SDKs (Java/Python) - not trying to reuse anything, just grab XSD & RSDL and generate sources. > >> the purpose of >> code generation is to ease maintenance, i.e you/maintainer should not write >> the feature >> once it available in api, just run CodeGen and you'll get it for free, but >> this is zero control >> over code. > > +1 > > I agree with you on this. > >> >>> >>> -- >>> >>> Q: What about functionality currently used by oVirt UI but not supported by >>> REST API? (asked by Einav) >>> [For example, fetching VM entity over GWT RPC also returns related data >>> such as Cluster name.] >>> >>> A: Based on discussion I've had with other colleagues after yesterday's >>> review call, I don't think that >>> separate support-like backend layer is a good idea. Instead, this is the >>> kind of functionality that could be >>> placed in oVirt.js library. Logical operations like "get VMs and related >>> data" would be exposed through oVirt.js >>> (callback-based) API and ultimately realized as multiple physical requests >>> to REST API via JavaScript Binding. >>> >>> oVirt.js client would be completely oblivious to the fact that multiple >>> physical requests are dispatched. In fact, >>> since HTTP communication is asynchronous in nature, oVirt.js client >>> wouldn't even notice any difference in terms of API >>> consumption. This assumes JavaScript SDK would use callback-based >>> (non-blocking) API instead of blocking one - after all, >>> blocking API on top of non-blocking implementation sounds pretty much like >>> leaky abstraction [1]. >>> >>> For example: >>> >>> sdk.getVmsWithExtraData( >>> callbackToGetExtraDataForGivenVm, // might cause extra physical >>> requests to REST API >>> callbackFiredWhenAllDataIsReady // update client only when all >>> data is ready >>> ) >> >> actually this the main bottleneck in moving UI to work on top of REST, and >> most interesting/complex part of this project, > > Agreed, it's because UI "got used to" using internal backend interface concepts (actions, queries etc.) in the first place.. So we'll have to emulate what we used to use to prevent regressions, maybe improve/refactor in future. > >> >> you should think of very wise polling mechanism cause callbacks is a nice >> thing on paper, but behind the scene it all about polling: >> >> - the entity/s till action got accomplished >> - add to this updating different grids >> - running multiple actions >> - showing events >> - and obviously much more > > IMHO polling is just a workaround and indicates lack of proper notification solution. > > Apparently, oVirt web UI isn't some CLI program for which HTTP request/response style is sufficient. oVirt web UI is dynamic, interactive web application that displays/updates data in real time. This is, in my opinion, quite a big difference. > > I don't think callbacks are just a nice thing on paper. Callbacks are needed because the underlying communcation is async in nature: Vojtech, you've got all wrong, i told that you *do need* callbacks, but implementing them only sounds easy, while actually it will be a quite complicated task. > > - caller invokes API function and provides callback to execute when operation completes -> API is non-blocking > - polling attempts to detect change (i.e. operation completed) and notify the caller, so it's also some sort of callback -> this is more complicated compared to simple callback > >> >> and don't forget that every polled entity should be marshalled from xml to >> the javascript >> entity so at the end, "callbacks" mechanism will be extremely CPU consuming. > > First of all, I don't understand how callback mechanism can be CPU consuming, can you please provide some explanation or use case? of course, you'll have to do per call-back call: 1. request/response to the server 2. decompression of data from gzip 3. object mapping (in 99% of cases) note you'll have a lot of callback consumers that monitoring resource state, waiting for new events. > > Does Java SDK provide ability to poll Engine in order to get recent updates, and if yes, why? i was kinda hoping that you'll add it, but you've chosen to write your own sdk ;-) > > Finally, polling makes things stateful, whereas SDK code should be stateless instead. If client wants to get recent updates, it should just use (stateless) SDK code to achieve this goal. sdk cannot be stateful by definition simply because server is stateless, (also pooling != keeping state, being stateful means that you save data for request on server side) > >> >>> >>> [1] http://en.wikipedia.org/wiki/Leaky_abstraction >>> >>> -- >>> >>> Last but not least, where to maintain JavaScript SDK projects: low-level >>> JavaScript Binding + high-level oVirt.js library. >>> >>> I agree that conceptually both above mentioned projects should go into >>> dedicated "ovirt-engine-sdk-js" git repository and >>> have their own build/release process. However, for now, we're just making >>> baby steps so let's keep things simple and prototype >>> these projects as part of "ovirt-engine" git repository. >>> >>> ... we can complicate things anytime, but we should know that any complex >>> system that works has inevitably evolved from simple >>> system that works ... (quote from >>> http://en.wikipedia.org/wiki/Gall%27s_law) >>> >>> Regards, >>> Vojtech >>> _______________________________________________ >>> Engine-devel mailing list >>> Engine-devel at ovirt.org >>> http://lists.ovirt.org/mailman/listinfo/engine-devel >>> >> >> >> -- >> >> Michael Pasternak >> RedHat, ENG-Virtualization R&D >> -- Michael Pasternak RedHat, ENG-Virtualization R&D From mpastern at redhat.com Fri Nov 29 09:59:29 2013 From: mpastern at redhat.com (Michael Pasternak) Date: Fri, 29 Nov 2013 11:59:29 +0200 Subject: [Engine-devel] Using REST API in web UI - review call summary In-Reply-To: <5298623F.6080605@redhat.com> References: <1515483885.28819526.1385068697947.JavaMail.root@redhat.com> <5291B3A5.5060305@redhat.com> <1131535003.32427980.1385666553819.JavaMail.root@redhat.com> <5298623F.6080605@redhat.com> Message-ID: <52986581.6090309@redhat.com> On 11/29/2013 11:45 AM, Michael Pasternak wrote: > On 11/28/2013 09:22 PM, Vojtech Szocs wrote: >> >> >> ----- Original Message ----- >>> From: "Michael Pasternak" >>> To: "Vojtech Szocs" >>> Cc: "engine-devel" >>> Sent: Sunday, November 24, 2013 9:07:01 AM >>> Subject: Re: [Engine-devel] Using REST API in web UI - review call summary >>> >>> >>> >>> Hi Vojtech, >>> >>> First of all it was a good "presentation" of requirements + suggested >>> solutions - well done!, >> >> Thank you :) >> >>> few comments/questions inline. >>> >>> On 11/21/2013 11:18 PM, Vojtech Szocs wrote: >>>> Hi guys, >>>> >>>> this is a summary of yesterday's review call, I'll try to highlight >>>> important Q/A and things we agreed on. >>>> Feel free to add anything in case I've missed something. >>>> >>>> -- >>>> >>>> Q: Why don't we simply try to use existing Java SDK and adapt it for GWT >>>> apps? (asked by Michael & Gilad) >>>> >>>> A: This might be a viable option to consider if we wanted to skip >>>> JavaScript-based SDK altogether and target Java/GWT code >>>> directly; we could simply take Java SDK and customize its abstractions >>>> where necessary, i.e. using HTTP transport layer >>>> implementation that works with GWT. In any case, this would mean coupling >>>> ourselves to Java SDK (which has its own release cycle) >>>> and I think this would complicate things for us. >>> >>> not sure i buy this one :), this is the purpose of any sdk, including the >>> one you about to write, people that will use it, will be "coupling" to it ... >> >> Of course, but by saying "coupling ourselves to Java SDK" I meant SDK perspective, not client perspective: > > of course, but you told something different, that you want js-sdk to be aware > of the client, and this is actually why you taking this path. > >> >> - someone else (you) maintains Java SDK and therefore controls generated sources (JAR or RPM isn't relevant here) >> - another guy (me) maintains (fictional) Java/GWT SDK that relies on Java SDK + some (supported) customizations >> - the only way I can impose changes in my SDK is through supported customizations as you control original (Java SDK) sources, >> i.e. the whole code generation process is driven by your SDK, so my SDK is coupled to your SDK's build/release cycle > > that's how things working in software, you always depending on the certain version > of the component you're working against, as it expose set of features you need, i don't > think that having control over framework features, justifying rewriting the > framework ... > > (please note that i'm not against the js-sdk, go ahead, this is a nice initiative indeed, i > just can't see the business case for not reusing existent infrastructure cause it works > for all your needs and eventually both worlds would benefiting from it UI and java-sdk users > cause you where extending it with additional capabilities they may also need) > >> >> For the sake of simplicity, I guess it's best to start with SDK that has no dependencies whatsoever. > > so why won't you rewrite the engine in Java-script? your js-sdk eventually will be depending on it, > this way you'll have control over it (and it's features) as well ;-) > >> After all, there's no common dependency (aside from running Engine to provide XSD & RSDL) between Java & Python SDK too, if I understand correctly. >> >> In other words, building on top of something existing (just because we can do that) isn't always appropriate/flexible/efficient, it always depends on given context and requirements. > > it would be true, if your requirements would make existing infrastructure inappropriate. > >> >>> >>>> >>>> As proposed on the meeting, I think it's best to aim for JavaScript SDK as >>>> the lowest >>>> common denominator for *any* web application that wants to work with REST >>>> API. oVirt GWT-based >>>> UI can simply bind to JavaScript SDK, i.e. Java/GWT code that just overlays >>>> objects and functions >>>> provided by JavaScript SDK. Another reason is ease of maintenance - I'd >>>> rather see JavaScript SDK's code >>>> generation process to be independent of any other SDK (people responsible >>>> for maintaining JavaScript SDK >>>> should have full control over generated code). >>> >>> what do you mean by "people should have full control over generated code"? >> >> It's related to "coupling from SDK perspective" I mentioned above: >> "the only way I can impose changes in my SDK is through supported customizations as you control original (Java SDK) sources" > > if you need additional functionality in java-sdk, you could do the following: > > 1. submit a patch to java-sdk > 2. build new java-sdk locally and use it along with new feature you've added > 3. make UI depending on next version of java-sdk (which includes your new feature) > > we (and all other SW projects) doing that day by day in engine,api,etc. > > (as i mentioned this would also benefit java-sdk users with additional features > they might find useful as well) > >> >> (by "people" I meant "JavaScript SDK developers") >> >> Full control means ability to change generated sources in whatever way desired, but assuming the idea of reusing/customizing existing SDK code, aspect of full control is lost in favor of reusing existing code. > > i disagree on this one, you have all control you need over java-sdk at any time > as it one of indoor projects. > >> And of course, this assumes that existing code (Java SDK) provides everything we need, which might or might not be the case. >> >> So I just vote for simplicity, generate JavaScript SDK the way like other SDKs (Java/Python) - not trying to reuse anything, just grab XSD & RSDL and generate sources. >> >>> the purpose of >>> code generation is to ease maintenance, i.e you/maintainer should not write >>> the feature >>> once it available in api, just run CodeGen and you'll get it for free, but >>> this is zero control >>> over code. >> >> +1 >> >> I agree with you on this. >> >>> >>>> >>>> -- >>>> >>>> Q: What about functionality currently used by oVirt UI but not supported by >>>> REST API? (asked by Einav) >>>> [For example, fetching VM entity over GWT RPC also returns related data >>>> such as Cluster name.] >>>> >>>> A: Based on discussion I've had with other colleagues after yesterday's >>>> review call, I don't think that >>>> separate support-like backend layer is a good idea. Instead, this is the >>>> kind of functionality that could be >>>> placed in oVirt.js library. Logical operations like "get VMs and related >>>> data" would be exposed through oVirt.js >>>> (callback-based) API and ultimately realized as multiple physical requests >>>> to REST API via JavaScript Binding. >>>> >>>> oVirt.js client would be completely oblivious to the fact that multiple >>>> physical requests are dispatched. In fact, >>>> since HTTP communication is asynchronous in nature, oVirt.js client >>>> wouldn't even notice any difference in terms of API >>>> consumption. This assumes JavaScript SDK would use callback-based >>>> (non-blocking) API instead of blocking one - after all, >>>> blocking API on top of non-blocking implementation sounds pretty much like >>>> leaky abstraction [1]. >>>> >>>> For example: >>>> >>>> sdk.getVmsWithExtraData( >>>> callbackToGetExtraDataForGivenVm, // might cause extra physical >>>> requests to REST API >>>> callbackFiredWhenAllDataIsReady // update client only when all >>>> data is ready >>>> ) >>> >>> actually this the main bottleneck in moving UI to work on top of REST, and >>> most interesting/complex part of this project, >> >> Agreed, it's because UI "got used to" using internal backend interface concepts (actions, queries etc.) in the first place.. So we'll have to emulate what we used to use to prevent regressions, maybe improve/refactor in future. >> >>> >>> you should think of very wise polling mechanism cause callbacks is a nice >>> thing on paper, but behind the scene it all about polling: >>> >>> - the entity/s till action got accomplished >>> - add to this updating different grids >>> - running multiple actions >>> - showing events >>> - and obviously much more >> >> IMHO polling is just a workaround and indicates lack of proper notification solution. >> >> Apparently, oVirt web UI isn't some CLI program for which HTTP request/response style is sufficient. oVirt web UI is dynamic, interactive web application that displays/updates data in real time. This is, in my opinion, quite a big difference. >> >> I don't think callbacks are just a nice thing on paper. Callbacks are needed because the underlying communcation is async in nature: > > Vojtech, you've got all wrong, i told that you *do need* callbacks, > but implementing them only sounds easy, while actually it will be > a quite complicated task. > >> >> - caller invokes API function and provides callback to execute when operation completes -> API is non-blocking >> - polling attempts to detect change (i.e. operation completed) and notify the caller, so it's also some sort of callback -> this is more complicated compared to simple callback >> >>> >>> and don't forget that every polled entity should be marshalled from xml to >>> the javascript >>> entity so at the end, "callbacks" mechanism will be extremely CPU consuming. >> >> First of all, I don't understand how callback mechanism can be CPU consuming, can you please provide some explanation or use case? > > of course, you'll have to do per call-back call: s/"call-back call"/"polling request", e.g: 1 polling task == N * (#1+#2+#3) [where N is amount of requests you need to perform till desired state is achieved] > > 1. request/response to the server > 2. decompression of data from gzip > 3. object mapping (in 99% of cases) > > > note you'll have a lot of callback consumers that monitoring resource state, waiting for new events. > > >> >> Does Java SDK provide ability to poll Engine in order to get recent updates, and if yes, why? > > i was kinda hoping that you'll add it, but you've chosen to write your own sdk ;-) > >> >> Finally, polling makes things stateful, whereas SDK code should be stateless instead. If client wants to get recent updates, it should just use (stateless) SDK code to achieve this goal. > > sdk cannot be stateful by definition simply because server is stateless, > (also pooling != keeping state, being stateful means that you save data > for request on server side) > >> >>> >>>> >>>> [1] http://en.wikipedia.org/wiki/Leaky_abstraction >>>> >>>> -- >>>> >>>> Last but not least, where to maintain JavaScript SDK projects: low-level >>>> JavaScript Binding + high-level oVirt.js library. >>>> >>>> I agree that conceptually both above mentioned projects should go into >>>> dedicated "ovirt-engine-sdk-js" git repository and >>>> have their own build/release process. However, for now, we're just making >>>> baby steps so let's keep things simple and prototype >>>> these projects as part of "ovirt-engine" git repository. >>>> >>>> ... we can complicate things anytime, but we should know that any complex >>>> system that works has inevitably evolved from simple >>>> system that works ... (quote from >>>> http://en.wikipedia.org/wiki/Gall%27s_law) >>>> >>>> Regards, >>>> Vojtech >>>> _______________________________________________ >>>> Engine-devel mailing list >>>> Engine-devel at ovirt.org >>>> http://lists.ovirt.org/mailman/listinfo/engine-devel >>>> >>> >>> >>> -- >>> >>> Michael Pasternak >>> RedHat, ENG-Virtualization R&D >>> > > -- Michael Pasternak RedHat, ENG-Virtualization R&D From dpati at redhat.com Fri Nov 29 11:40:09 2013 From: dpati at redhat.com (Dusmant Kumar Pati) Date: Fri, 29 Nov 2013 17:10:09 +0530 Subject: [Engine-devel] Using config values In-Reply-To: <52984D48.1070009@redhat.com> References: <52984D48.1070009@redhat.com> Message-ID: <52987D19.9000203@redhat.com> On 11/29/2013 01:46 PM, Kanagaraj wrote: > Hi All, > > The are some issues arising in configurations whenever we move up on > the versions(3.3 => 3.4), because of the way we store and interpret them. > > Whenever there is a new cluster level, you will need to add a new > entry for all(most) of the configuration. Mostly a copy paste if you > see from 3.2 to 3.3, except some CPU/PM type related configurations. > Better option would be to have the defaul config value in > ConfigValues.java and the overrides will go to config.sql. In this > approach you don't need a new entries to config.sql when there is a > new cluster level. > > Lets take an exmaple, "SupportForceCreateVG" - This is supported from > 3.1 onwards, > > If you look at config.sql, you will see following entries > select fn_db_add_config_value('SupportForceCreateVG','false','3.0'); > select fn_db_add_config_value('SupportForceCreateVG','true','3.1'); > select fn_db_add_config_value('SupportForceCreateVG','true','3.2'); > select fn_db_add_config_value('SupportForceCreateVG','true','3.3'); > > And in ConfigValues.java > > @TypeConverterAttribute(Boolean.class) > @DefaultValueAttribute("false") > SupportForceCreateVG, > > Now if there is 3.4 and 3.5, the user needs to add 2 more entries, > which i feel is redundant. > > Instead we can make > > @TypeConverterAttribute(Boolean.class) > @DefaultValueAttribute("true") > SupportForceCreateVG, > > and have only the following in config.sql > select fn_db_add_config_value('SupportForceCreateVG','false','3.0'); > > if a particular value(for a specific cluster level) is not found in > Config.sql, the fallback is to use the value available in > ConfigValues.java. > > Please share your thoughts on this. > > Thanks, > Kanagaraj > > > > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel I think, this is a good suggestion... -------------- next part -------------- An HTML attachment was scrubbed... URL: From sbonazzo at redhat.com Fri Nov 29 12:18:53 2013 From: sbonazzo at redhat.com (Sandro Bonazzola) Date: Fri, 29 Nov 2013 13:18:53 +0100 Subject: [Engine-devel] [Users] oVirt Weekly Meeting Minutes -- 2013-11-27 In-Reply-To: <20131129121352.GH9681@redhat.com> References: <1839115795.18144890.1385570095111.JavaMail.root@redhat.com> <529848F2.1040508@redhat.com> <52987157.5040605@redhat.com> <20131129121352.GH9681@redhat.com> Message-ID: <5298862D.7080700@redhat.com> Il 29/11/2013 13:13, Dan Kenigsberg ha scritto: > On Fri, Nov 29, 2013 at 11:49:59AM +0100, Sandro Bonazzola wrote: >> Il 29/11/2013 09:43, Gianluca Cecchi ha scritto: >>> On Fri, Nov 29, 2013 at 8:57 AM, Sandro Bonazzola wrote: >>> >>>>> >>>>> Meeting summary >>>>> --------------- >>>>> * Agenda and roll Call (doron, 15:02:42) >>>>> * 3.3 update releases (doron, 15:04:23) >>>>> * 3.4 planning (doron, 15:04:24) >>>>> * conferences and workshops (doron, 15:04:26) >>>>> * infra update (doron, 15:04:27) >>>>> * other topics (doron, 15:04:29) >>>>> * LINK: http://gerrit.ovirt.org/#/admin/projects/ovirt-release ~ >>>>> (danken, 15:12:58) >>>>> * LINK: http://gerrit.ovirt.org/21794 (mburns, 15:15:04) >>>>> * LINK: http://jenkins.ovirt.org/job/ovirt-release/16800/ (mburns, >>>>> 15:15:48) >>>>> * mburns to add sbonazzo as a maintainer to support ovirt-release >>>>> project (doron, 15:18:17) >>>> >>>> ovirt-release-9 released yesterday >>> >>> BTW: I see that this package contains >>> /etc/yum.repos.d/fedora-virt-preview.repo >>> (and ovirt-release-fedora-8-1.noarch already did so) >>> By default all lines are disabled in it. >>> When and how this repo should be enabled? Only when using nightly or >>> only under developers/maintainers indications? >> >> I think that fedora-virt-preview should be used with nightly, stable shouldn't need it. >> However, since fedora-virt-preview contains vdsm - related packages not needed if you run only ovirt-engine (without using the same host as >> hypervisor) I think it's better to wait for VDSM guys answer. > > Vdsm is not in > http://fedorapeople.org/groups/virt/virt-preview/fedora-20/x86_64/ > > virt-preview is not needed for ovirt-3.3, and frankly, I think it should > be dropped from ovirt-release. > > It used to be needed on the nodes when vdsm required a version of > libvirt that was not yet in Fedora. Now that we have el6 as a > fully-supported platform, and given that el6 is missing from > virt-preview, virt-preview is much less helpful to us. > > Dan. > So, any objection in removing virt-preview from ovirt-release? What about nightly? Will it be needed there? -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com From danken at redhat.com Fri Nov 29 12:38:38 2013 From: danken at redhat.com (Dan Kenigsberg) Date: Fri, 29 Nov 2013 12:38:38 +0000 Subject: [Engine-devel] [Users] oVirt Weekly Meeting Minutes -- 2013-11-27 In-Reply-To: <5298862D.7080700@redhat.com> References: <1839115795.18144890.1385570095111.JavaMail.root@redhat.com> <529848F2.1040508@redhat.com> <52987157.5040605@redhat.com> <20131129121352.GH9681@redhat.com> <5298862D.7080700@redhat.com> Message-ID: <20131129123838.GK9681@redhat.com> On Fri, Nov 29, 2013 at 01:18:53PM +0100, Sandro Bonazzola wrote: > Il 29/11/2013 13:13, Dan Kenigsberg ha scritto: > > On Fri, Nov 29, 2013 at 11:49:59AM +0100, Sandro Bonazzola wrote: > >> Il 29/11/2013 09:43, Gianluca Cecchi ha scritto: > >>> On Fri, Nov 29, 2013 at 8:57 AM, Sandro Bonazzola wrote: > >>> > >>>>> > >>>>> Meeting summary > >>>>> --------------- > >>>>> * Agenda and roll Call (doron, 15:02:42) > >>>>> * 3.3 update releases (doron, 15:04:23) > >>>>> * 3.4 planning (doron, 15:04:24) > >>>>> * conferences and workshops (doron, 15:04:26) > >>>>> * infra update (doron, 15:04:27) > >>>>> * other topics (doron, 15:04:29) > >>>>> * LINK: http://gerrit.ovirt.org/#/admin/projects/ovirt-release ~ > >>>>> (danken, 15:12:58) > >>>>> * LINK: http://gerrit.ovirt.org/21794 (mburns, 15:15:04) > >>>>> * LINK: http://jenkins.ovirt.org/job/ovirt-release/16800/ (mburns, > >>>>> 15:15:48) > >>>>> * mburns to add sbonazzo as a maintainer to support ovirt-release > >>>>> project (doron, 15:18:17) > >>>> > >>>> ovirt-release-9 released yesterday > >>> > >>> BTW: I see that this package contains > >>> /etc/yum.repos.d/fedora-virt-preview.repo > >>> (and ovirt-release-fedora-8-1.noarch already did so) > >>> By default all lines are disabled in it. > >>> When and how this repo should be enabled? Only when using nightly or > >>> only under developers/maintainers indications? > >> > >> I think that fedora-virt-preview should be used with nightly, stable shouldn't need it. > >> However, since fedora-virt-preview contains vdsm - related packages not needed if you run only ovirt-engine (without using the same host as > >> hypervisor) I think it's better to wait for VDSM guys answer. > > > > Vdsm is not in > > http://fedorapeople.org/groups/virt/virt-preview/fedora-20/x86_64/ > > > > virt-preview is not needed for ovirt-3.3, and frankly, I think it should > > be dropped from ovirt-release. > > > > It used to be needed on the nodes when vdsm required a version of > > libvirt that was not yet in Fedora. Now that we have el6 as a > > fully-supported platform, and given that el6 is missing from > > virt-preview, virt-preview is much less helpful to us. > > > > Dan. > > > > So, any objection in removing virt-preview from ovirt-release? > What about nightly? Will it be needed there? Should be removed from both, since it is currently unused. We could reintroduce it if the need arises. From eedri at redhat.com Sat Nov 30 14:22:31 2013 From: eedri at redhat.com (Eyal Edri) Date: Sat, 30 Nov 2013 09:22:31 -0500 (EST) Subject: [Engine-devel] Fedora 20 support, Was: [Users] oVirt Weekly Meeting Minutes -- 2013-11-27 In-Reply-To: <1392632247.19917559.1385639713981.JavaMail.root@redhat.com> References: <494879836.10410088.1384965317482.JavaMail.root@redhat.com> <1839115795.18144890.1385570095111.JavaMail.root@redhat.com> <20131128101905.GB20978@redhat.com> <1392632247.19917559.1385639713981.JavaMail.root@redhat.com> Message-ID: <1940671359.3526222.1385821351427.JavaMail.root@redhat.com> I updated the environment to support f20, including new slave and nighlites. i will send a separate email on it soon to infra/users/devel. Eyal. ----- Original Message ----- > From: "Doron Fediuck" > To: "Dan Kenigsberg" , "David Caro Estevez" > Cc: board at ovirt.org, "users" , eedri at redhat.com, "Sandro Bonazzola" > Sent: Thursday, November 28, 2013 1:55:13 PM > Subject: Re: Fedora 20 support, Was: [Users] oVirt Weekly Meeting Minutes -- 2013-11-27 > > > > ----- Original Message ----- > > From: "Dan Kenigsberg" > > To: board at ovirt.org, "users" > > Cc: "Doron Fediuck" , eedri at redhat.com > > Sent: Thursday, November 28, 2013 12:19:05 PM > > Subject: Fedora 20 support, Was: [Users] oVirt Weekly Meeting Minutes -- > > 2013-11-27 > > > > We've forgotten to discuss an important issue: Fedora 20, which is > > expected to be out in two weeks: > > http://fedoraproject.org/wiki/Releases/20/Schedule. > > I believe that ovirt-3.4 must support it, and that ovirt-3.3.2 would > > better do so. > > > > Toni has fixed two issues regarding Vdsm-networking, and they are going > > into ovirt-3.3.2 beta. However, we must perform much more comprehensive > > testing. > > > > We'd need to have f20 Jenkins slave(s), and someone in each team > > responsible to testing functionality. Who can cover for storage, virt, > > infra and integration? > > > > Dan. > > > > Indeed so, thanks Dan. > David, is this something we have resources for? > From eedri at redhat.com Sat Nov 30 15:16:06 2013 From: eedri at redhat.com (Eyal Edri) Date: Sat, 30 Nov 2013 10:16:06 -0500 (EST) Subject: [Engine-devel] [ANN] new fedora20 nightlies rpms for oVirt are available for download In-Reply-To: <1251834692.3526325.1385821498788.JavaMail.root@redhat.com> Message-ID: <936323951.3530612.1385824566011.JavaMail.root@redhat.com> fyi, oVirt infra has added support for nighlies rpms for various oVirt projects for fedora 20. the following has be done: - All ovirt projects were added f20 nightlies on jenkins.ovirt.org. (replaced f18, which is NOT built nightly anymore). - One jenkins f19 slave (vm02) was upgraded to f20, and we also have a bare metal host running f20 as well. - Nightlies rpms can be downloaded on the repos [1] - Nightlies publish & cleanup scripts were updated on the resources.ovirt.org to support f20. I didn't update any ovirt-node* job, since i'm not familiar with them. if you would like to build f20 builds, just add the 'fedora20' label to the relevant jobs. Eyal. [1] http://resources.ovirt.org/releases/nightly/rpm/Fedora/20/ From emesika at redhat.com Sat Nov 30 20:58:35 2013 From: emesika at redhat.com (Eli Mesika) Date: Sat, 30 Nov 2013 15:58:35 -0500 (EST) Subject: [Engine-devel] Using config values In-Reply-To: <52987D19.9000203@redhat.com> References: <52984D48.1070009@redhat.com> <52987D19.9000203@redhat.com> Message-ID: <1299085692.33736696.1385845115835.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Dusmant Kumar Pati" > To: "Kanagaraj" , "engine-devel" > Sent: Friday, November 29, 2013 1:40:09 PM > Subject: Re: [Engine-devel] Using config values > > On 11/29/2013 01:46 PM, Kanagaraj wrote: > > > Hi All, > > The are some issues arising in configurations whenever we move up on the > versions(3.3 => 3.4), because of the way we store and interpret them. > > Whenever there is a new cluster level, you will need to add a new entry for > all(most) of the configuration. Mostly a copy paste if you see from 3.2 to > 3.3, except some CPU/PM type related configurations. > Better option would be to have the defaul config value in ConfigValues.java > and the overrides will go to config.sql. In this approach you don't need a > new entries to config.sql when there is a new cluster level. > > Lets take an exmaple, "SupportForceCreateVG" - This is supported from 3.1 > onwards, > > If you look at config.sql, you will see following entries > select fn_db_add_config_value('SupportForceCreateVG','false','3.0'); > select fn_db_add_config_value('SupportForceCreateVG','true','3.1'); > select fn_db_add_config_value('SupportForceCreateVG','true','3.2'); > select fn_db_add_config_value('SupportForceCreateVG','true','3.3'); > > And in ConfigValues.java > > @TypeConverterAttribute(Boolean.class) > @DefaultValueAttribute("false") > SupportForceCreateVG, > > Now if there is 3.4 and 3.5, the user needs to add 2 more entries, which i > feel is redundant. > > Instead we can make > > @TypeConverterAttribute(Boolean.class) > @DefaultValueAttribute("true") > SupportForceCreateVG, > > and have only the following in config.sql > select fn_db_add_config_value('SupportForceCreateVG','false','3.0'); > > if a particular value(for a specific cluster level) is not found in > Config.sql, the fallback is to use the value available in ConfigValues.java. > > Please share your thoughts on this. Hi First of all I think its a good idea I have 2 questions 1) Which value will be stored as default in the java class for configuration values that are not a boolean, that represents if a feature is active or not. Is that the latest version value ? sounds not obvious to me 2) There are some configuration values that are exposed to the user via the engine-config tool, how this will work, we can not remove the entries their since the user may change and override those values. I have a different suggestion: Default value will stay as is , meaning , it will reflect the value that should be used to keep the application running correctly if a value is not found in DB (which should not occur) Code of getting configuration value (getConfigValue(,) will be changed to get the closest version value to the given one. For example , if a 3.4 version is given for a given and we have in DB just values for 3.0 and 3.1 , the 3.1 value is returned. I prefer this solution since it makes the config.sql file self documented , showing only value changes and in which version each change occurred. To implement that, we should add this mechanism to the current code that caches the DB content and as I see that it should be a simple change. engine-config should be modified such that if the user change a value, this value will be inserted to the database with the current release if not exists and then the mechanism described above will get this value Example: VdsFenceType lists all the supported fencing agents for power management , it currently has the following settings option_value | version ---------------------------------------------------------------------------------------------+--------- alom,apc,bladecenter,drac5,eps,ilo,ilo3,ipmilan,rsa,rsb,wti,cisco_ucs | 3.0 alom,apc,bladecenter,drac5,eps,ilo,ilo3,ipmilan,rsa,rsb,wti,cisco_ucs | 3.1 apc,apc_snmp,bladecenter,cisco_ucs,drac5,eps,ilo,ilo2,ilo3,ilo4,ipmilan,rsa,rsb,wti | 3.2 apc,apc_snmp,bladecenter,cisco_ucs,drac5,eps,ilo,ilo2,ilo3,ilo4,ipmilan,rsa,rsb,wti | 3.3 In the proposed solution, we will have option_value | version ---------------------------------------------------------------------------------------------+--------- alom,apc,bladecenter,drac5,eps,ilo,ilo3,ipmilan,rsa,rsb,wti,cisco_ucs | 3.0 apc,apc_snmp,bladecenter,cisco_ucs,drac5,eps,ilo,ilo2,ilo3,ilo4,ipmilan,rsa,rsb,wti | 3.2 This is clear and documents only the changes done between versions and serve all values: boolean , string and complex type (those which requires any kind of parsing) What do you think? Eli > > Thanks, > Kanagaraj > > > > _______________________________________________ > Engine-devel mailing list Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > I think, this is a good suggestion... > > > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel >